# ADR-010: Operational Knowledge — the transition is the unit of knowledge

- **Status:** Accepted
- **Datum:** 2026-06-27
- **Typ:** Produkt- / Wissens-Strategie-Entscheidung
- **Bezug:** [ADR-009](ADR-009-domain-knowledge-program.md), [ADR-002](ADR-002-transition-is-data-not-architecture.md), [[transition-reasoning]], [[strategy-requirements-intelligence]]

## Kontext

Aus allen Kundengesprächen ergibt sich dieselbe Frage: nicht „was steht im CRA?", sondern
**„ich habe heute ISO 27001 und TISAX — welche drei Dinge fehlen mir noch für den CRA?"**. Die
verkaufte Einheit ist damit weder das Gesetz noch die Capability, sondern die **Transition**
(`Ausgangszustand → Zielzustand`). Den Domänen-Backlog nach „jetzt EMV modellieren" zu ordnen,
verfehlt das — niemand kauft eine „EMV-Domain", Kunden kaufen „ISO 9001 → CRA".

## Entscheidung

1. **Die Wissenseinheit ist die TRANSITION.** Der Operational-Knowledge-Backlog
   (`knowledge/programs/transitions.yaml`) listet die ~20–30 tatsächlich nachgefragten Transitionen
   (von ~N·(N−1) theoretisch möglichen) mit Priorität. Das ist der eigentliche Verkaufs-Backlog.

2. **Drei Wissensebenen, die ineinandergreifen:**
   `Regulatory Knowledge` (Gesetze/Normen/Leitlinien) → **`Operational Knowledge`** (Transition
   Patterns · Playbooks · Capability-Deltas) → `Verification Knowledge` (Code · SBOM · Doku ·
   Architektur · Prozesse; = Vision V2 / Requirements Verification). Die **mittlere Ebene ist der
   größte Differenzierer**: sie beantwortet nicht nur *was* gefordert ist, sondern *wie ein Unternehmen
   mit seinem heutigen Reifegrad dorthin kommt*.

3. **Zweiter, stärkerer KPI: Transition Coverage.** Pro Top-Transition ein Status, DERIVED aus dem
   Transition-Pattern-Korpus (`reviewed/validated/proven → ✅`, `draft → 🟡`, `none → ⚪`),
   computed-not-stored. „ISO 9001 → MaschinenVO ⭐⭐⭐⭐⭐ aber ⚪" ist ein viel stärkerer Produktindikator
   als „EMV ist zu 30 % modelliert".

4. **Eine Domäne ist ein TRANSITION PROGRAM mit zwei parallelen Tracks:**
   - **Track A (Breite):** verbleibende Requirement Sources der Domäne modellieren (EMV, RED,
     IEC 62443, NIS2 …) — Korpus wächst (Stufe 2–3, @Legal-KG/@Execution).
   - **Track B (Produkt):** für jede neu modellierte Source sofort die wichtigsten Transition Patterns
     + Playbooks + Reference Scenarios erzeugen — verkaufbares/einsetzbares Wissen (Stufe 4–6, @Reasoning).

## Konsequenzen

- **Backlog ist transition-getrieben, nicht regelwerk-getrieben.** Die höchstpriorisierte Lücke
  (z. B. `ISO 9001 → MaschinenVO`, ⭐⭐⭐⭐⭐, ⚪) ist die nächste Track-B-Arbeit — nicht „EMV".
- **Task #49 wird zum „Industrial Automation Transition Program"** (Track A + Track B parallel), sodass
  wachsendes Domänenwissen unmittelbar in Produktwert übersetzt wird.
- **Operational Knowledge = der Moat.** Regulatory ist Commodity (jeder kann Gesetze lesen),
  Verification ist Vision V2; die Transition dazwischen ist der differenzierende Asset.
- **Freeze-konform:** kein neues Metamodell/Graph/Modul. Nur Daten (`transitions.yaml`) + eine
  abgeleitete Reporting-Sicht; Status aus dem vorhandenen Pattern-Korpus berechnet.
- Diese ADR ist non-runtime → kein Deploy (siehe [ADR-001](ADR-001-runtime-deploy-policy.md)).