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

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:

1. Pattern · Interview · Roadmap · Evidence · Rollen-Views = dieselbe Journey (Pattern = kuratierter Kern; der Rest derived). → rendered, not modeled gilt für die abgeleiteten Sichten.
2. Reference Scenario = Journey × Company-Kontext + Expected Outcome — kein zweites Transitionsmodell, sondern die Journey instanziiert für ein Referenz-Unternehmen (Regression).
3. 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.

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