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:
pilotadmin
2026-06-28 07:32:55 +02:00
+40 -10
View File
@@ -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
- **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]]
@@ -90,13 +95,38 @@ Neben **computed, not stored** und **derived, not curated**:
> **rendered, not modeled** — Transition Pattern, Playbook-Aggregat, Roadmap, Interview, Rollen-View
> 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
konzeptionelles Datenmodell zur Entscheidung.
- **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
~90 % aus einer Journey ergeben; das Risiko liegt nur bei der Company-Kontext-Bindung (RTS) und der
Capability-Achse (Playbook), die ohnehin schon getrennt sind.
Der Playbook-Befund ist die wertvollste Erkenntnis: wir vereinheitlichen NICHT zwanghaft. Es gibt
**zwei unterschiedliche Achsen** mit getrennten Owner:
```
Atomic Requirement → Capability → Journey (Transition-Achse: „wie komme ich von A nach B?")
Capability → Playbook (Implementierungs-Achse: „wie baue ich Capability X?")
```
- **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).