Merge pull request 'docs: Journey model — Accepted as Concept, Pending Canonicalization (Rule of Three)' (#26) from docs/journey-provisional-acceptance into main
This commit is contained in:
@@ -1,6 +1,11 @@
|
|||||||
# Journey Model — specification (PROPOSAL v1, decision pending)
|
# Journey Model — specification (ACCEPTED AS CONCEPT, pending canonicalization)
|
||||||
|
|
||||||
- **Status:** PROPOSAL / draft — to be VALIDATED before any code. Not an accepted ADR yet.
|
- **Status:** **ACCEPTED AS CONCEPT, PENDING CANONICALIZATION** (User 2026-06-28, Rule of Three).
|
||||||
|
Journey ist ab sofort die bevorzugte **Denkweise**; das PERSISTIERTE Artefakt heißt vorerst weiter
|
||||||
|
`Transition Pattern`. **KEIN Rename, KEINE Migration, KEINE Runtime-Änderung.** Kanonisierung
|
||||||
|
(`Transition Pattern → Journey` + ADR-011) erst, NACHDEM sich die Journey an **≥ 3 unterschiedlichen
|
||||||
|
Transitionen** bewährt hat (siehe §9). Schützt vor zu früher Abstraktion — wie bei Master Controls/
|
||||||
|
Capabilities: erst beweisen, dann kanonisieren.
|
||||||
- **Datum:** 2026-06-28
|
- **Datum:** 2026-06-28
|
||||||
- **Typ:** Konzeptionelles Datenmodell (KEIN Runtime-Modul, KEINE neue Architektur)
|
- **Typ:** Konzeptionelles Datenmodell (KEIN Runtime-Modul, KEINE neue Architektur)
|
||||||
- **Bezug:** [ADR-003](adr/ADR-003-capability-delta-engine-with-renderers.md), [ADR-004](adr/ADR-004-implementation-playbooks.md), [ADR-009](adr/ADR-009-domain-knowledge-program.md), [ADR-010](adr/ADR-010-operational-knowledge-transition-unit.md), [[transition-reasoning]]
|
- **Bezug:** [ADR-003](adr/ADR-003-capability-delta-engine-with-renderers.md), [ADR-004](adr/ADR-004-implementation-playbooks.md), [ADR-009](adr/ADR-009-domain-knowledge-program.md), [ADR-010](adr/ADR-010-operational-knowledge-transition-unit.md), [[transition-reasoning]]
|
||||||
@@ -90,13 +95,38 @@ Neben **computed, not stored** und **derived, not curated**:
|
|||||||
> **rendered, not modeled** — Transition Pattern, Playbook-Aggregat, Roadmap, Interview, Rollen-View
|
> **rendered, not modeled** — Transition Pattern, Playbook-Aggregat, Roadmap, Interview, Rollen-View
|
||||||
> sind keine eigenständigen Modelle, sondern Sichten auf Journey (+ Capability + Company-Kontext).
|
> sind keine eigenständigen Modelle, sondern Sichten auf Journey (+ Capability + Company-Kontext).
|
||||||
|
|
||||||
## 8. Was das NICHT ist / nächste Schritte
|
## 8. Zwei Achsen (durable — die wichtigste Präzisierung)
|
||||||
|
|
||||||
- **Kein Code, kein Runtime-Modul, keine neue Architektur** (Freeze unberührt). Diese Spec ist ein
|
Der Playbook-Befund ist die wertvollste Erkenntnis: wir vereinheitlichen NICHT zwanghaft. Es gibt
|
||||||
konzeptionelles Datenmodell zur Entscheidung.
|
**zwei unterschiedliche Achsen** mit getrennten Owner:
|
||||||
- **Wenn akzeptiert:** der „Transition Pattern" wird zum *Journey-Dokument* (gleiche YAML-Struktur,
|
|
||||||
präziserer Name); Renderer bleiben abgeleitet; Playbook bleibt capability-owned. Dann ggf. ADR-011.
|
```
|
||||||
- **Wenn verworfen:** die drei Artefakte bleiben getrennt — aber dieser Befund zeigt, dass sie sich zu
|
Atomic Requirement → Capability → Journey (Transition-Achse: „wie komme ich von A nach B?")
|
||||||
~90 % aus einer Journey ergeben; das Risiko liegt nur bei der Company-Kontext-Bindung (RTS) und der
|
Capability → Playbook (Implementierungs-Achse: „wie baue ich Capability X?")
|
||||||
Capability-Achse (Playbook), die ohnehin schon getrennt sind.
|
```
|
||||||
|
|
||||||
|
- **Journey** gehört der **Transition** (eine Journey je `from→to`).
|
||||||
|
- **Playbook** gehört der **Capability** (eine je Capability), von beliebig vielen Journeys referenziert.
|
||||||
|
Das ist eine stabile Trennung — Requirements gehören Requirements, Capabilities gehören Capabilities,
|
||||||
|
Journeys gehören Transitionen.
|
||||||
|
|
||||||
|
## 9. Provisional Acceptance + Kanonisierungs-Hürde (Rule of Three)
|
||||||
|
|
||||||
|
**Entscheidung (User 2026-06-28): „Accepted as Concept, Pending Canonicalization".** Journey ist die
|
||||||
|
bevorzugte Denkweise; das persistierte Artefakt bleibt vorerst `Transition Pattern`. Kein Rename, keine
|
||||||
|
Migration, keine Runtime-Änderung.
|
||||||
|
|
||||||
|
Die Journey wird erst zur offiziellen Primärentität, wenn sie sich an **≥ 3 unterschiedlichen
|
||||||
|
Transitionen** bewährt (konsistent Pattern + Interview + Roadmap + Reference Scenario erzeugt):
|
||||||
|
|
||||||
|
1. ✅ **ISO 27001 → CRA** (validiert, §5).
|
||||||
|
2. ⏳ **ISO 9001 → MaschinenVO** (offen).
|
||||||
|
3. ⏳ **TISAX → CRA** (offen).
|
||||||
|
|
||||||
|
Erst nach diesem Rule-of-Three-Nachweis: `Transition Pattern → Journey` umbenennen, **ADR-011**
|
||||||
|
ratifizieren, Renderer offiziell daraus ableiten, Prinzip *rendered, not modeled* aufnehmen.
|
||||||
|
|
||||||
|
## 10. Was das NICHT ist
|
||||||
|
|
||||||
|
- **Kein Code, kein Runtime-Modul, keine neue Architektur** (Freeze unberührt). Konzeptionelles Modell.
|
||||||
- Non-runtime → kein Deploy (ADR-001).
|
- Non-runtime → kein Deploy (ADR-001).
|
||||||
|
|||||||
Reference in New Issue
Block a user