# ADR-005: Knowledge Production — prepare deterministically, then curate

- **Status:** Accepted
- **Datum:** 2026-06-27
- **Typ:** Architektur-Entscheidung
- **Bezug:** [ADR-004](ADR-004-implementation-playbooks.md), [ADR-002](ADR-002-transition-is-data-not-architecture.md), Architektur-Freeze v1.0, [[transition-reasoning]], [[iace-quality-architecture]]

## Kontext

Mit Capability Delta, Optimization und Playbooks ist die Diagnose weitgehend fertig. Der nächste
Engpass ist NICHT „Content" (mehr Playbooks schreiben), sondern **Wissensproduktion**: würde man
200 Playbooks (und je Domäne neue Patterns/Reference-Szenarien) von Hand schreiben, verlagerte sich
der Engpass dauerhaft vom Engineering auf manuelle Wissenspflege.

Der entscheidende Grundsatz war: **„Die Engine ändert sich nicht. Der Corpus wächst."** Diese ADR
ergänzt ihn:

> **„Und der Corpus wird nicht manuell geschrieben. Er wird deterministisch vorbereitet und
> anschließend fachlich kuratiert."**

## Entscheidung

1. **BreakPilot produziert künftig keine fertigen Wissensartefakte, sondern ENTWÜRFE.** Ein Draft
   Generator strukturiert deterministisch aus Daten, die die Software bereits besitzt
   (Capability, Transition Pattern, Controls, Evidence, Regulatory Map / Leverage), einen Entwurf —
   und überlässt das Fachwissen der menschlichen Kuratierung.

2. **Spiegelung der Legal-Pipeline.** Wie `Gesetz → Parser → Obligation → Review` gilt jetzt
   `neue Capability → Registry → Transition Pattern → Playbook Draft Generator → Expert Review →
   versioniertes Playbook`. Dieselbe Logik für jedes Wissensartefakt (Playbooks, später Transition
   Patterns, Reference-Szenarien).

3. **Deterministisch-first (kein LLM im Kern).** Der Generator assembliert nur, was die Software
   besitzt; weiche Felder (Tools / Prozessschritte / „wie machen das andere") werden als **TODO**
   ausgewiesen. Optionale Modell-Anreicherung bleibt **offline, advisory, propose-only** — nie im
   deterministischen Kern (vgl. [[iace-quality-architecture]]).

4. **Freigabestatus.** Jedes Artefakt trägt einen Lifecycle
   `draft_generated → in_review → reviewed → validated → proven` plus **Provenance je Feld**
   (woraus es assembliert wurde) — Voraussetzung für Review-Workflow und Versionierung.

## Konsequenzen

- **Review statt Schreiben:** der Experte reviewt N Entwürfe statt N Artefakte zu schreiben — der
  manuelle Aufwand sinkt massiv, ohne fachliche Kontrolle aufzugeben.
- **Neue Domänen werden billig:** sobald ein Domänen-Corpus (z. B. Umwelt) existiert, erzeugt
  derselbe Generator erste Entwürfe — ISO 14001 wird ein Draft-+-Review-Problem, kein Schreibprojekt.
- **Internes Werkzeug:** die wertvollste Maschine ist nicht nur das Kunden-OS, sondern die
  **Produktionsmaschine für das eigene regulatorische Wissen** — sie wird mit jeder Domäne wertvoller.
- **Freeze-konform:** kein neues Metamodell, kein Graph, kein neuer Corpus. `compliance/knowledge_production`
  ist eine reine, deterministische Vorbereitung (computed-not-stored); Execution-Controls werden injiziert.
- **Phase A (Wissensproduktion) VOR Phase B (neue Domänen):** Draft-Generatoren (Playbook ✓, dann
  Transition-Pattern, Reference-Szenario) + Review-Workflow + Versionierung + Freigabestatus, dann
  ISO 14001 / IATF 16949 / IEC 62443.
- Diese ADR ist non-runtime → kein Deploy (siehe [ADR-001](ADR-001-runtime-deploy-policy.md)).