# ADR-006: Knowledge Intake — classify and assess impact before extraction

- **Status:** Accepted
- **Datum:** 2026-06-27
- **Typ:** Architektur-Entscheidung
- **Bezug:** [ADR-005](ADR-005-knowledge-production-pipeline.md), [ADR-002](ADR-002-transition-is-data-not-architecture.md), 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

1. **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.

2. **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.

3. **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]]).

4. **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_intake`
  ist 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](ADR-001-runtime-deploy-policy.md)).