Files
breakpilot-compliance/docs-src/architecture/adr/ADR-005-knowledge-production-pipeline.md
T
Benjamin Admin b6cfc0a503 feat(knowledge-production): Playbook Draft Generator — prepare the corpus deterministically
The bottleneck is not content, it is knowledge PRODUCTION. Instead of writing 200 playbooks by
hand, generate drafts deterministically from data the software already owns, then have an expert
review them. Mirrors the legal pipeline (Gesetz -> Parser -> Obligation -> Review) for BreakPilot's
own knowledge: new Capability -> Registry -> Transition Pattern -> Playbook Draft Generator ->
Expert Review -> versioned Playbook.

- compliance/knowledge_production/: generate_playbook_draft(capability, requirement, control_links)
  + drafts_from_pattern(pattern) -> one PlaybookDraft per delta capability. Owned fields (why /
  closes_regulations / expected_evidence / typical_controls) are assembled with per-field provenance;
  the practitioner know-how (tools / process_steps / how_others) is left as an explicit TODO.
- DraftStatus lifecycle (Freigabestatus): draft_generated -> in_review -> reviewed -> validated ->
  proven. Deterministic, NO LLM in the core (any model enrichment stays offline/advisory/propose-only).
- ADR-005: extends "the engine does not change, the corpus grows" with "and the corpus is not written
  by hand — it is deterministically prepared, then curated".
- reference suite: "Knowledge Production" section turns the convergence pattern into 12 auto-assembled
  drafts (why/closes/evidence filled, tools/steps TODO) -> review 12 drafts, don't write 12 playbooks.

10 tests (50 with playbook/optimization/transition/company), mypy --strict clean, check-loc 0.
Product code with no app caller + ADR/reference = non-runtime -> no deploy (ADR-001). Freeze-safe.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
2026-06-27 13:31:31 +02:00

3.4 KiB

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

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