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>
3.4 KiB
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-007, ADR-005, 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
-
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. -
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.
-
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 alsinferred, nieconfirmed. Wir wollen nicht wissen, OB ein Automobilzulieferer ISO 9001 hat (das hat jeder), sondern welche Fähigkeiten dadurch wahrscheinlich schon vorhanden sind. -
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.
-
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).