Benjamin Admin
1a9439d013
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>
54 lines
3.4 KiB
Markdown
54 lines
3.4 KiB
Markdown
# 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)).
|