feat(programs): open Domain Knowledge Program v1 — 7-stage production line + per-domain KPI

The real bottleneck is domain MODELLING. Phase B is organized as one program with sub-programs per domain, each run through the SAME 7-stage production line. No new runtime framework, no new module (ADR-009, Freeze v1.0) — only program data + a derived reporting view. - Customer enters by INDUSTRY, not regulation: Industry -> Domain Model -> Requirement Sources -> Requirements -> Capabilities -> ... -> Completeness. - 7-stage checklist identical for every domain (Domain Model / Requirement Sources / Capability Registry / Transition Patterns / Playbooks / Reference Scenarios / Completeness) with per-stage ownership. README generalized to the framework. - Each domain lists typical_requirement_sources + typical_certifications -> pre-onboarding capability HYPOTHESIS (the ETO insight; feeds Company 2A as inferred, never confirmed). - Backlog v1 (by customer value): 1 Industrial Automation, 2 Environmental, 3 Automotive, 4 Medical, 5 Energy. Five domain-definition shells (environmental restructured to the unified shape, law-first preserved). - Per-domain KPI is DERIVED from the real corpus (computed-not-stored; sources modelled / transition patterns / playbooks / reference scenarios), NOT a curated number. Reference suite renders maturity bars: Industrial Automation 43% (3/7 sources) leads, Environmental 0% (work ahead). Backlog (value) and KPI (corpus state) are deliberately separated. - ADR-009: Domain Knowledge Program framework. Honest known refinement: regulation-ID normalization (CRA vs Cyber Resilience Act) aliased in the KPI. 7 program-contract tests (backlog order + industry-first + derived-not-stored), check-loc 0. Knowledge data + ADR + reference harness = non-runtime -> no deploy (ADR-001). Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
2026-06-27 18:49:06 +02:00
parent c737e1ad7d
commit 1a9439d013
10 changed files with 312 additions and 159 deletions
@@ -0,0 +1,53 @@
+# ADR-009: Domain Knowledge Program — one 7-stage production line per domain
+
+- **Status:** Accepted
+- **Datum:** 2026-06-27
+- **Typ:** Architektur- / Organisations-Entscheidung
+- **Bezug:** [ADR-008](ADR-008-from-architecture-to-domains.md), [ADR-007](ADR-007-regulatory-completeness.md), [ADR-005](ADR-005-knowledge-production-pipeline.md), Architektur-Freeze v1.0, [[company-intelligence-2a]]
+
+## Kontext
+
+Der Engpass ist nicht mehr Architektur, Controls oder „Wissen" allgemein, sondern präzise:
+**Domänenmodellierung.** Phase B (ADR-008) wird daher nicht als Einzel-Regelwerk-Features
+organisiert, sondern als EIN Arbeitsprogramm mit Unterprogrammen je Domäne — alle durch dieselbe
+Produktionsstraße. Kein weiteres Architektur-Epic, keine neue Runtime-Architektur.
+
+## Entscheidung
+
+1. **Einstieg über die INDUSTRIE, nicht über das Regelwerk.** Der Kunde sagt „ich baue
+   Verpackungsmaschinen / bin Automobilzulieferer / baue Parksysteme", nicht „erklär mir ISO 9001".
+   Die Pipeline beginnt davor: `Industry → Domain Model → Requirement Sources → Requirements →
+   Capabilities → … → Completeness`.
+
+2. **Eine 7-Stufen-Checkliste, identisch für JEDE Domäne:**
+   1 Domain Model · 2 Requirement Sources · 3 Capability Registry · 4 Transition Patterns ·
+   5 Playbooks · 6 Reference Scenarios · 7 Completeness. Ownership je Stufe (1 Reasoning · 2 Legal-KG ·
+   3 Execution · 4–7 Reasoning). Das ist der Skalierungsmechanismus: jede neue Domäne nutzt dieselbe
+   Straße, die bestehenden Engines erweitern sich automatisch.
+
+3. **Domänen tragen `typical_requirement_sources` + `typical_certifications` → Pre-Onboarding-HYPOTHESE
+   (ETO-Einsicht).** Vor dem Onboarding: „diese Prozesswelt ist *wahrscheinlich* vorhanden" — als
+   Hypothese, nie Wahrheit. Speist Company 2A als `inferred`, nie `confirmed`. Wir wollen nicht wissen,
+   OB ein Automobilzulieferer ISO 9001 hat (das hat jeder), sondern welche Fähigkeiten dadurch
+   wahrscheinlich schon vorhanden sind.
+
+4. **Per-Domain-KPI, reproduzierbar (computed-not-stored).** Reifegrad wird aus dem ECHTEN Korpus
+   abgeleitet (modellierte Sources / Transition Patterns / Playbooks / Reference Scenarios / bewusst
+   ausgewiesene Lücken — auf Basis der Regulatory Completeness Engine), NICHT als kuratierte Zahl.
+   Programm-Shells speichern KEINEN Stufen-Status. Keine Marketingzahl.
+
+5. **Domain Knowledge Program v1 — Backlog nach Kundennutzen** (getrennt vom KPI nach Korpusstand):
+   1 Industrial Automation · 2 Environmental · 3 Automotive · 4 Medical · 5 Energy.
+
+## Konsequenzen
+
+- **Programme statt Features:** jede Domäne ist eine maschinenlesbare Definition (`programs/*.yaml`);
+  der Reifegrad-KPI im Reference-Suite ist aus dem Korpus abgeleitet und differenziert ehrlich
+  (Industrial Automation führt, Environmental 0 % — die Arbeit liegt vor uns).
+- **Backlog ≠ KPI:** der Backlog ordnet nach Kundennutzen, der KPI misst den echten Korpusstand —
+  bewusst getrennt (z. B. eine Domäne kann hoch im Backlog, aber niedrig im KPI stehen).
+- **Arbeit verschiebt sich endgültig von Software- zu Wissensproduktion.** Wettbewerbsvorteil =
+  Qualität und Breite der modellierten Domänen.
+- **Freeze-konform:** kein neues Metamodell, kein Graph, kein neues `compliance/`-Modul. Nur
+  Programm-Daten (`knowledge/programs/`) + abgeleitete Reporting-Sicht im Reference-Suite.
+- Diese ADR ist non-runtime → kein Deploy (siehe [ADR-001](ADR-001-runtime-deploy-policy.md)).