feat(programs): Operational Knowledge — the transition is the unit + Transition Coverage KPI

Customers don't buy "EMV domain"; they buy "we have ISO 9001, help us with the CRA". The sellable
unit of knowledge is the TRANSITION (from -> to), not the law and not the capability. This reframes
the backlog from "model EMV next" to "the top demanded transitions". No new runtime framework (ADR-010).

- knowledge/programs/transitions.yaml: the Operational Knowledge backlog — the ~20-30 actually demanded
  transitions (of ~N*(N-1) possible) with priority. ISO27001->CRA, ISO9001->CRA, ISO9001->MaschinenVO
  (all 5-star), IEC62443->CRA, TISAX->CRA, ISO27001/IEC62443->NIS2, ISO14001->Umweltrecht.
- Transition Coverage KPI (reference suite, computed-not-stored): per transition a status DERIVED from
  the transition-pattern corpus (reviewed/validated/proven -> Gold, draft -> 🟡, none -> ⚪). Honest
  current state: ISO27001->CRA ✅ reviewed, ISO9001->CRA 🟡 draft, rest ⚪. Highest-priority gap =
  ISO9001->MaschinenVO (the next Track-B work) — a far stronger product indicator than "EMV 30% modelled".
- Three knowledge layers documented: Regulatory -> Operational (transitions/playbooks/deltas, the
  biggest differentiator) -> Verification (Vision V2). A domain is a TRANSITION PROGRAM with two tracks:
  Track A breadth (model sources, @Legal-KG/@Execution) + Track B product (transitions/playbooks/RTS
  per source, @Reasoning).
- ADR-010: the transition is the unit of knowledge; Transition Coverage KPI; three layers; two tracks.

10 program/transition-contract tests, check-loc 0. Knowledge data + ADR + reference harness =
non-runtime -> no deploy (ADR-001). No new module, no runtime change.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>

docs-src/architecture/adr/ADR-010-operational-knowledge-transition-unit.md

@@ -0,0 +1,50 @@
+# 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)).