Benjamin Admin
18f5d0cb05
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>
51 lines
3.3 KiB
Markdown
51 lines
3.3 KiB
Markdown
# 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)).
|