User 2026-06-28: canonicalization is NOT just "3 transitions built". Two conditions:
1. >= 3 deliberately DIFFERENT transitions (the more different the character, the stronger the
evidence — not three similar security transitions): ISO27001->CRA (security->cyber), ISO9001->
MaschinenVO (QM->product safety), TISAX->CRA (automotive security->cyber).
2. NO structural extension of the Journey model in the last two transitions (or only clearly
justified, general extensions). Per-transition maturity test: "did the MODEL need extending, or
were only DATA added?" — tracked as a balance sheet.
Only when both hold (3 diverse + model stable in the last two) -> rename Transition Pattern -> Journey,
ratify ADR-011, derive renderers. Matches the pattern at Compiler / Layout families / Master Controls:
become the standard only after proving stable under DIFFERENT loads. Non-runtime -> no deploy.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
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>
Benjamin Admin