Benjamin Admin
aa99111a87
Phase A½. The move from feature to product development: for every assessment, answer "how sure are we that this answer is COMPLETE?" — different from confidence. The product never claims full coverage; it makes its own knowledge state transparent and auditable. Shows what we do NOT know and why. - compliance/completeness/: assess_completeness(identified, corpus_status, uncertain, assumptions, assessed_obligations) -> CompletenessReport. Separates IDENTIFIED from ASSESSED (validated corpus AND determined applicability) and justifies every gap. Two kinds of open: corpus gap (future_corpus) and applicability uncertainty (query_required + deciding question, e.g. Data Act / generates_usage_data). - The metric is COUNTS, never a single percentage: "Identifiziert N · bewertet M · offen K · Unsicherheiten U · Begründung ja" + an honest audit statement. - ADR-007: auditable honesty; phase order A factory -> A½ Completeness -> B new domains; the transparency selling point. Deterministic, no LLM; corpus status + obligation count injected. - reference suite: "Regulatory Completeness" section runs an industrial-dishwasher assessment (assessed CRA/MaschinenVO; open EMV/Environmental=future_corpus, Data Act=query_required) and notes Environmental flips open->validated automatically once the corpus lands. 11 completeness tests (54 with adjacent modules), mypy --strict clean (15 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>
54 lines
3.2 KiB
Markdown
54 lines
3.2 KiB
Markdown
# 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)).
|