# ADR-007: Regulatory Completeness — auditable knowledge coverage, not confidence

- **Status:** Accepted
- **Datum:** 2026-06-27
- **Typ:** Architektur-Entscheidung
- **Bezug:** [ADR-006](ADR-006-knowledge-intake.md), [ADR-003](ADR-003-capability-delta-engine-with-renderers.md), Architektur-Freeze v1.0, [[transition-reasoning]], [[reasoning-vs-compliance-boundary]]

## Kontext

Die Engine beantwortet inzwischen *Was gilt? · Was fehlt? · Wie umsetzen?*. Es fehlt eine
übergeordnete Fähigkeit: **„Wie sicher sind wir, dass diese Antwort VOLLSTÄNDIG ist?"** Das ist
NICHT Confidence (Vertrauen in eine einzelne Aussage), sondern Abdeckung (welche Teile des Problems
haben wir überhaupt bewertet).

Der Übergang von Feature- zu Produktentwicklung verlangt, dass der Kunde — gerade in regulierten
Branchen — sehen kann, was die Plattform NICHT weiß und warum sie dazu keine Aussage trifft.

## Entscheidung

1. **Eine Regulatory Completeness Engine** (`compliance/completeness`, interne Qualitätsmaschine,
   non-runtime) trennt für eine Beratung **IDENTIFIZIERT** (getriggerte Regelwerke) von **BEWERTET**
   (validierter Korpus UND geklärte Anwendbarkeit) und **begründet jede Lücke**.

2. **Zwei Arten „offen", je mit Begründung:**
   - **Korpus-Lücke** — kein validierter Korpus (z. B. Environmental) → `future_corpus`.
   - **Anwendbarkeits-Unsicherheit** — Korpus vorhanden, aber Anwendbarkeit unklar (Data Act,
     `generates_usage_data` unbekannt) → `query_required` mit deciding question.

3. **Die Metrik sind ZÄHLUNGEN, keine einzelne Prozentzahl.** Nicht „87 %", sondern
   `Identifiziert N · bewertet M · offen K · Unsicherheiten U · Begründung ja`. Plus ein ehrlicher
   **Audit-Satz**: „Wir bewerteten M von N Domänen; K sind nicht im validierten Korpus / anwendungs-
   unsicher und wurden bewusst nicht bewertet."

4. **Annahmen und begründete Ausschlüsse sind explizit** (z. B. „kein Funkmodul",
   „keine personenbezogenen Nutzungsdaten").

## Konsequenzen

- **Auditierbar + ehrlich:** das System behauptet KEINE Vollständigkeit, es macht den eigenen
  Wissensstand transparent. Direkte Fortsetzung der Welt-1-Disziplin ([[reasoning-vs-compliance-boundary]])
  auf Produktebene.
- **Fortschritt je Domäne wird automatisch dokumentiert:** landet der Umwelt-Korpus (ISO 14001),
  kippt `Environmental` von `unsupported`/offen auf `validated`/bewertet — die Engine zeigt, WARUM
  sich die Antwort verändert hat.
- **Verkaufsargument:** „Wir sagen Ihnen nicht nur, was wir wissen — wir zeigen transparent, was wir
  noch nicht wissen und warum wir dazu keine Aussage treffen." Transparenz = Vertrauen.
- **Freeze-konform:** kein neues Metamodell, kein Graph, kein neuer Corpus. `compliance/completeness`
  ist eine reine, deterministische Aggregation (computed-not-stored); Corpus-Status + Obligation-Zahl
  werden injiziert (Execution-/Kuratoren-owned).
- **Phasen-Reihenfolge:** **A Wissensfabrik** (Intake ✓ / Draft ✓ / Review) → **A½ Regulatory
  Completeness** (diese ADR) → **B neue Domänen** (ISO 14001 / REACH / CLP / IATF 16949 / IEC 62443).
  Completeness VOR den Domänen, damit jeder Domänen-Zuwachs sofort messbar wird.
- Diese ADR ist non-runtime → kein Deploy (siehe [ADR-001](ADR-001-runtime-deploy-policy.md)).