Benjamin Admin
4a7412e4f2
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>
9.4 KiB
Journey Model — specification (ACCEPTED AS CONCEPT, pending canonicalization)
- 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-004, ADR-009, ADR-010, transition-reasoning
1. Problem
Wir produzieren drei Artefakte je Transition: Transition Pattern, Playbook, Reference Scenario. Alle drei beschreiben dieselbe Geschichte aus verschiedenen Blickwinkeln. Wird derselbe Übergang (z. B. ISO 9001 → MaschinenVO) in Pattern + Playbook + Szenario + Interview je separat modelliert, duplizieren wir die Transition — genau das Problem, das wir bei Controls/Capabilities/ Requirements mit der Identitätsmaschine gelöst haben.
Damals: Controls nicht duplizieren. Heute: Transitionen nicht duplizieren.
2. Hypothese
Es gibt unter den Artefakten ein gemeinsames Objekt — die Journey — als Wissenseinheit; alles andere ist ein Renderer (rendered, not modeled). Diese Spezifikation prüft die Hypothese an der vorhandenen Transition ISO 27001 → CRA, bevor irgendetwas gebaut wird.
3. Die Wissenseinheit: Journey (Vorschlag)
Journey
identity: from (Ausgangszustand) → to (Zielzustand) # = transition_goal
source_variants: certified | introduced | expired | limited_scope # Start-Zustands-Varianten
likely_covered[]: { capability, relationship, confidence_source, verification, rationale, reviewable_claim, expected_evidence }
delta[]: { capability, why_missing, needed_information, expected_evidence, priority, dropped_if }
rejected_assumptions[]
# ── alles darunter ist ABGELEITET, nicht gespeichert ──
(derived) questions ← delta (RS-005)
(derived) measures ← delta × leverage (Optimization)
(derived) evidence_needs ← likely_covered.expected_evidence + delta.expected_evidence
(derived) verification ← evidence × Reality (Vision V2, künftig)
Wahrheits-Hierarchie: Atomic Requirement → Capability → Journey (× Company-Kontext bei Instanz).
Alles andere wird gerendert.
4. Renderer (rendered, not modeled)
| Renderer | Was er zeigt | Quelle |
|---|---|---|
| Transition Pattern | die KURATIERTE generische Journey (likely_covered + delta + rationale) | = der authored core der Journey (gespeichert/kuratiert) |
| Interview | fehlende Informationen → Fragen | Journey.delta (RS-005) |
| Roadmap | Maßnahmen nach regulatorischem Hebel | Journey.delta × Leverage (Optimization) |
| Reference Scenario | erwartetes Ergebnis für ein Referenz-Unternehmen | Journey × Company/Product-Kontext + Expected Outcome |
| Evidence-View | welche Nachweise erfüllen die Anforderung | Journey.evidence_needs × Reality |
| Rollen-Views | Sales→Executive Summary · Auditor→Capability Delta · Developer→Evidence · GF→Roadmap | gefilterte Projektionen DER EINEN Journey |
Vier Rollen-Views, aber nur eine Journey.
5. Validierung an ISO 27001 → CRA (grounded, nicht hypothetisch)
Geprüft gegen die echten Artefakte: TP-ISO27001-CRA-v1.yaml, die Playbooks sbom_creation/
coordinated_vulnerability_disclosure, die Reference Scenarios RTS-001/002/003.
| Artefakt | Felder | projiziert aus der Journey? |
|---|---|---|
| Transition Pattern | transition_goal, source_state_variants, likely_covered[] (relationship/rationale/reviewable_claim/expected_evidence), delta_requirements[] (why_asked/needed_information/expected_evidence/priority/dropped_if), rejected_assumptions |
JA — IST der authored core der Journey (1:1). |
| Interview (RS-005) | question_requests aus delta |
JA — derived. Kein eigenes Primärdatum. |
| Roadmap (Optimization) | Maßnahmen nach Leverage aus delta |
JA — derived. |
| Reference Scenario | reference_company{sector, certs, product_traits} + expected_outcome{cra, maschinenvo, data_act, convergence} |
TEILWEISE — Journey × Company-Kontext. Die Transition-Erkenntnis (likely_covered/delta) ist DIESELBE wie im Pattern; NEU ist nur der gebundene Company/Product-Kontext + die Expected-Outcome-Assertion (Regression). Kein dupliziertes Transitionswissen. |
| Playbook | capability_id, why, tools, process_steps, expected_evidence, how_others_do_it |
NEIN — pro CAPABILITY, nicht pro Journey. sbom_creation wird von JEDER Journey wiederverwendet, deren Delta SBOM enthält. Bleibt capability-owned (ADR-004); die Journey aggregiert die Playbooks ihrer Delta-Capabilities, besitzt sie nicht. |
6. Befund (ehrlich)
Die Vereinheitlichung HÄLT — mit zwei Präzisierungen, die eine voreilige Abstraktion VERMEIDEN:
- Pattern · Interview · Roadmap · Evidence · Rollen-Views = dieselbe Journey (Pattern = kuratierter Kern; der Rest derived). → rendered, not modeled gilt für die abgeleiteten Sichten.
- Reference Scenario =
Journey × Company-Kontext+ Expected Outcome — kein zweites Transitionsmodell, sondern die Journey instanziiert für ein Referenz-Unternehmen (Regression). - Playbook = Capability-Renderer, NICHT Journey-Renderer (andere Achse: Capability, nicht Transition). Die Journey aggregiert, besitzt nicht. → das ist die früh erkannte Grenze, die verhindert, dass wir Playbooks fälschlich in die Journey zwingen.
Konsequenz: Die Transition wird genau EINMAL kuratiert (heute „Transition Pattern" = der Journey-
Kern). Interview/Roadmap/Reference-Outcome/Rollen-Views werden daraus gerendert. Playbooks bleiben
capability-owned und werden referenziert. Damit ist ISO 9001 → MaschinenVO (und jede weitere
Transition) ein EINZIGES kuratiertes Objekt, kein vierfach gepflegtes.
7. Neues Prinzip (Vorschlag)
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. Zwei Achsen (durable — die wichtigste Präzisierung)
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.
Kanonisierung an ZWEI Bedingungen (nicht nur „3 gebaut", User 2026-06-28)
-
≥ 3 BEWUSST UNTERSCHIEDLICHE Transitionen erfolgreich modelliert (konsistent Pattern + Interview + Roadmap + Reference Scenario). Je unterschiedlicher der Charakter, desto stärker die Evidenz — NICHT drei ähnliche Security-Transitionen wählen:
Transition Charakter ✅ ISO 27001 → CRA Security → Cyber-Regulierung ⏳ ISO 9001 → MaschinenVO Qualitätsmanagement → Produktsicherheit ⏳ TISAX → CRA Automotive Security → Cyber-Regulierung -
KEINE strukturelle Erweiterung des Journey-Modells in den letzten beiden Transitionen (oder nur klar begründete, ALLGEMEINGÜLTIGE Erweiterungen). Reifeindikator je Transition: „Musste das Modell ERWEITERT werden, oder wurden nur DATEN ergänzt?" Bilanz:
Transition Modelländerung erforderlich? ISO 27001 → CRA Ja (Erstentwurf) ISO 9001 → MaschinenVO (offen — eintragen) TISAX → CRA (offen — eintragen)
Erst wenn BEIDE Bedingungen erfüllt sind (3 diverse Transitionen + Modell in den letzten zwei stabil):
Transition Pattern → Journey umbenennen, ADR-011 ratifizieren, Renderer offiziell daraus ableiten,
Prinzip rendered, not modeled aufnehmen. Das entspricht dem Muster bei Compiler / Layout-Familien /
Master Controls: erst stabil unter UNTERSCHIEDLICHEN Belastungen, dann Standard.
10. Was das NICHT ist
- Kein Code, kein Runtime-Modul, keine neue Architektur (Freeze unberührt). Konzeptionelles Modell.
- Non-runtime → kein Deploy (ADR-001).