Transition Pattern, Playbook and Reference Scenario describe the same transition from different
angles. The hypothesis: a single underlying object, the Journey, is the unit of knowledge; everything
else is a renderer ("rendered, not modeled"). Per the user's request this is a SPECIFICATION to
validate the assumption BEFORE any code — not a runtime module, not new architecture, decision pending.
- Conceptual Journey schema: identity (from->to) + source_variants + likely_covered[] + delta[] +
rejected_assumptions; questions/measures/evidence/verification are DERIVED. Truth hierarchy:
Atomic Requirement -> Capability -> Journey (x Company context on instantiation).
- Renderers: Transition Pattern (= the curated Journey core), Interview, Roadmap, Reference Scenario,
Evidence view, role views (Sales/Auditor/Developer/GF) — four views, one Journey.
- GROUNDED validation against the real ISO 27001 -> CRA artifacts (TP-ISO27001-CRA-v1, the
sbom/CVD playbooks, RTS-001/002/003). Honest finding: the unification HOLDS with two refinements
that AVOID premature abstraction:
1. Reference Scenario = Journey x Company context + expected outcome (no duplicated transition data).
2. Playbook = a CAPABILITY renderer (reused across journeys), NOT a Journey renderer — stays
capability-owned (ADR-004); the Journey aggregates, it does not own.
=> a transition is curated exactly once; ISO9001->MaschinenVO becomes one object, not four.
- Proposes the principle "rendered, not modeled" alongside computed-not-stored / derived-not-curated.
No code, no runtime change (Freeze). Non-runtime doc -> no deploy (ADR-001). If accepted -> ADR-011.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Benjamin Admin
86a783e72f