docs(spec): Journey model — Accepted as Concept, Pending Canonicalization (Rule of Three)

User decision (2026-06-28): provisional acceptance. Journey is now the preferred way of THINKING, but
the persisted artifact stays "Transition Pattern" — NO rename, NO migration, NO runtime change. Per the
Rule of Three, Journey becomes the official primary entity only after it proves itself on >=3 distinct
transitions (1. ISO27001->CRA done, 2. ISO9001->MaschinenVO, 3. TISAX->CRA). Only then: rename to
Journey, ratify ADR-011, derive renderers officially. Erst beweisen, dann kanonisieren — as with Master
Controls/Capabilities.

Also makes the two-axis separation durable (the most valuable finding): Atomic Requirement -> Capability
-> Journey (transition axis) vs Capability -> Playbook (implementation axis). Journey belongs to the
transition; Playbook stays capability-owned, referenced by any number of journeys. We do NOT force-unify.

Non-runtime doc -> no deploy (ADR-001).

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>

docs-src/architecture/journey-model-spec-v1.md

@@ -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
+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).