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>
3.2 KiB
ADR-007: Regulatory Completeness — auditable knowledge coverage, not confidence
- Status: Accepted
- Datum: 2026-06-27
- Typ: Architektur-Entscheidung
- Bezug: ADR-006, ADR-003, 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
-
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. -
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_dataunbekannt) →query_requiredmit deciding question.
- Korpus-Lücke — kein validierter Korpus (z. B. Environmental) →
-
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." -
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
Environmentalvonunsupported/offen aufvalidated/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/completenessist 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).