Files
breakpilot-compliance/docs-src/architecture/adr/ADR-010-operational-knowledge-transition-unit.md
T
Benjamin Admin 18f5d0cb05 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>
2026-06-27 23:48:45 +02:00

3.3 KiB
Raw Blame History

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

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 ~2030 tatsächlich nachgefragten Transitionen (von ~N·(N1) 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 23, @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 46, @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).