Benjamin Admin
07e392913f
Phase A1. The real knowledge production is not writing — it is TARGETED UPDATING: when 20 documents arrive, which 5 change our knowledge and which 15 are ignorable? Before the parser, Knowledge Intake classifies a new document (no content extraction) and intersects its signals with an index of the existing knowledge to emit a Knowledge Package (an impact analysis). - compliance/knowledge_intake/: build_knowledge_index(patterns, playbooks, reference_scenarios, obligation_index) + assess_document_impact(descriptor, index) -> KnowledgePackage. Deterministic, NO content extraction, NO LLM. Surfaces affected capabilities / playbooks / transition patterns / reference scenarios / (injected) obligations, whether it is a new domain, and a triage level (HIGH / LOW / NONE / NEW_DOMAIN) with a recommendation. - ADR-006: Knowledge Intake = classify + impact before extraction; full factory Intake -> Package -> Parser -> Draft -> Review -> Published; phase order A1 Intake / A2 Draft / A3 Review. - reference suite: "Knowledge Intake" section triages 3 example documents (CRA SBOM-FAQ -> high, 14C/2PB/3RTS/2Obl; environmental guidance -> new_domain; marketing blog -> ignorable). Section lives in _helpers.py to keep generate.py under the 500-LOC budget. - Honest known refinement surfaced by intake: regulation-ID normalization (CRA vs Cyber Resilience Act). 10 intake tests (60 with the adjacent modules), mypy --strict clean (16 files), 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>
3.4 KiB
ADR-006: Knowledge Intake — classify and assess impact before extraction
- Status: Accepted
- Datum: 2026-06-27
- Typ: Architektur-Entscheidung
- Bezug: ADR-005, ADR-002, Architektur-Freeze v1.0, transition-reasoning, iace-quality-architecture
Kontext
Vier Produktionspipelines folgen demselben Muster Rohwissen → deterministischer Entwurf → Expertenreview → veröffentlichter Wissensbaustein (Obligations, Capabilities, Playbook-Drafts,
Reference-Szenarien). Aber woher kommt das Rohwissen, und wie verarbeitet man es effizient?
Heute beginnt die Pipeline beim Parser (PDF → Parser → Review). Damit startet man bei JEDEM neuen
Dokument wieder bei Null. Der eigentliche Aufwand der Wissensproduktion ist nicht das Schreiben,
sondern das gezielte Aktualisieren: wenn morgen 20 Dokumente erscheinen — welche 15 kann man
ignorieren und welche 5 verändern tatsächlich den Wissensbestand?
Entscheidung
-
Vor dem Parser steht eine neue Stufe: Knowledge Intake. Sie extrahiert KEINEN Inhalt, sondern ordnet ein neues Dokument nur ein (Klassifikation) und bestimmt seinen Impact auf den bestehenden Wissensbestand.
-
Output ist ein
KnowledgePackage(Impact-Analyse), kein Inhalt: welche bestehenden Capabilities / Playbooks / Transition Patterns / Reference-Szenarien / (injizierten) Obligations das Dokument wahrscheinlich betrifft, ob es eine neue Domäne ist, und ein Triage-Level (HIGH / LOW / NONE / NEW_DOMAIN) mit Empfehlung. -
Deterministisch, kein LLM. Intake schneidet die Dokument-Signale (deklarierte Regelwerke + Stichworte) gegen einen Index des vorhandenen Wissens. Optionale Modell-Anreicherung bleibt offline/advisory (vgl. iace-quality-architecture).
-
Vollständige Wissensfabrik:
Knowledge Intake → Knowledge Package → Parser → Draft Generator → Expert Review → Published Knowledge → Reference Suite.
Konsequenzen
- Targeted Updating statt Schreiben: statt „hier sind 200 Seiten PDF" liefert das System eine Impact-Analyse („betrifft 4 Capabilities, 2 Playbooks, RTS-003; keine neue Domäne"). Das spart enorm viel Review-Aufwand und ist die eigentliche Knowledge Production.
- Neue Quellen werden automatisch eingeordnet: CRA-FAQ, MaschinenVO-Guidance, ENISA-Empfehlung, BSI-Orientierungshilfe → je eine Impact-Analyse statt Rohtext.
- Geänderte Phasen-Reihenfolge: A1 Knowledge Intake (klassifizieren + Impact + Knowledge Package) → A2 Draft Production (Transition Patterns / Playbooks / Reference-Szenarien) → A3 Expert Review (Review / Versionierung / Veröffentlichung). Erst danach Phase B (neue Domänen).
- Freeze-konform: kein neues Metamodell, kein Graph, kein neuer Corpus.
compliance/knowledge_intakeist eine reine, deterministische Sicht (computed-not-stored); Obligations werden injiziert. Bekannte Verfeinerung: Regelwerk-ID-Normalisierung (CRA ↔ Cyber Resilience Act) — vom Intake ehrlich sichtbar. - Strategische Bedeutung: die Plattform wird von einem Compliance-Produkt zu einer kontinuierlich lernenden regulatorischen Wissensbasis — und Intake ist der Filter, der bestimmt, was überhaupt Arbeit auslöst.
- Diese ADR ist non-runtime → kein Deploy (siehe ADR-001).