diff --git a/docs-src/architecture/journey-model-spec-v1.md b/docs-src/architecture/journey-model-spec-v1.md
index 41c1fd02..ea3213f6 100644
--- a/docs-src/architecture/journey-model-spec-v1.md
+++ b/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
-  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).