Benjamin Admin
d44f3672be
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>
133 lines
8.4 KiB
Markdown
133 lines
8.4 KiB
Markdown
# 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/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]]
|
||
|
||
## 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).
|