Benjamin Admin
b6cfc0a503
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>
56 lines
3.4 KiB
Markdown
56 lines
3.4 KiB
Markdown
# 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)).
|