# 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)).