breakpilot-compliance/docs-src/development/platform_validation_v1.md

Plattform-Validierung der Doc-Check-Kalibrierung — platform_validation_v1

Status: Plattform-Methodik validiert über 3 strukturell verschiedene Dokumentklassen (2026-06-19). Zweck: Nicht ein Modul dokumentieren, sondern den Kalibrierungsprozess und die empirische Fehlerkarte der Engine — damit die Ursachen erhalten bleiben (nicht nur die Messwerte). Erkenntnis > Metrik.

1. Was hier validiert wurde

Vor dieser Runde war unklar, ob der Restfehler der Doc-Check-Engine aus dem LLM, dem Embedding, dem Prompt, der Applicability oder dem Control-Katalog stammt — alles vermischt. Nach DSE + Cookie + Impressum existiert eine belastbare Taxonomie der Fehlerursachen, und der Kalibrierungsprozess hat in drei sehr unterschiedlichen Domänen geliefert. Das ist die eigentliche Errungenschaft — größer als jede einzelne Zahl.

2. Der Kalibrierungsprozess (wiederverwendbarer Kern)

1. Opus-GT je (Firma × Control) über 5–9 repräsentative Firmen (stärkstes Modell, NICHT Haiku).
2. Engine-Messung (Keyword → BGE-M3-Embedding → robuster LLM-Judge) vs GT.
3. FP-Cluster — wiederkehrende Controls statt Einzel-Findings (systematisch ≠ zufällig).
4. Ursachen-Klassifikation je FP: SCOPE / ARTIFACT_TYPE / CRITERIA / JUDGE.
5. Fix der dominanten Ursache (versioniert, mit Rechtsnotiz).
6. Re-Messung — Pflicht: FP↓ und FN stabil. Plus Anti-Overfit auf ungesehenen Firmen.

3. Plattform-Fehlerkarte (Kernergebnis)

Modul	Dominante Ursache	Hebel	Ergebnis	Status
DSE	Kriterien zu streng	Kriterien-Kalibrierung (11 Controls)	FP 11 % → 6 %, FN ~7 %; generalisiert (8 Firmen; fresh FP 7 % / FN 5 %)	Release-Candidate
Cookie	artifact_type (Banner ≠ Richtlinie)	31 Banner-Controls → COOKIE_BANNER; 21 Kriterien (Kategorie statt Pro-Cookie, Zitat optional), Pro-Cookie = Best-Practice	Precision 0,81 → 0,95, Recall 0,26 → 0,44, verpasste Lücken → 0 %, abs. FP 71 → 54	Wave-1 (dev)
Impressum	Scope (GT-NA 48 %) + Feld-Extraktion + Präsentation	Scope-Gate (14 raus) + Feldmatrix-Matcher (Fakten) + PRESENTATION_CHECK-Re-Route (5)	roh: SCOPE-FP 105 / JUDGE-FP 66 → Text-Check FP 0 % / FN 2 %	Release-Candidate

4. Meta-Befunde

• Die generische Architektur bewährt sich. Jede Domäne hat ein anderes dominantes Problem — artifact_type / obligation_type / scope tragen unterschiedlich stark. Eine gute generische Architektur erzeugt nicht überall denselben Effekt, sondern löst je Domäne ein anderes Problem. Genau das ist eingetreten.
• Die Zielarchitektur ist domänen-adaptiv, nicht uniform. „Embedding → OVH → Claude" ist nicht überall richtig: bei Prosa (DSE/Cookie) ist die LLM-Kaskade der Hebel; bei strukturierten Faktendokumenten (Impressum) ist das LLM sogar schwach (es verfehlt Adressen/Felder, die dastehen) → dort schlagen Scope-Gate + deterministischer Feld-Matcher den LLM-Judge.
• Wiederkehrendes Anti-Muster: „vermeintlicher Judge-Fehler → eigentlich Katalog-Fehler" (Scope, Präsentations-statt-Inhalt, Fehl-Typisierung). Erst NACH den Katalog-Fixes ist der Rest ein echter Judge-Fehler.

4b. Die verification_method-Achse (Synthese — die eigentliche Lehre)

Nicht jede Compliance-Pflicht ist ein Textproblem. Die 5 entdeckten Fehlerklassen mappen auf 5 Prüfer-Typen — eine neue Routing-Metadaten-Achse verification_method, die einem Control sagt, welcher Prüfer zuständig ist (nicht alles an den LLM):

verification_method	Prüfer	Frage	Beispiel	Status
CONTENT	Embedding + LLM-Kaskade (OVH→Claude)	Was steht da?	DSE nennt Zwecke; Cookie-Policy	DSE/Cookie kalibriert
FIELD	Regex/Parser (Feldmatrix)	Welche Felder existieren?	HRB, USt-IdNr, Adresse	Impressum-Fakten ✓ (FP 0 %)
PRESENTATION	Playwright (Sichtbarkeit/Erreichbarkeit)	Ist es auffindbar/wahrnehmbar?	Impressum leicht erkennbar, ständig verfügbar; Footer nicht verdeckt	Re-Route gemacht; Check offen
BEHAVIOR	Playwright + API (Interaktion)	Manipuliert es die Entscheidung?	Reject = Accept, Consent VOR Cookie, kein Dark Pattern	Cookie-Banner-Matrix existiert
PROCESS	Audit/Nachweis	Gibt es internen Nachweis?	VVT, interne Richtlinie, Audit-Entscheidung	Org-Checkliste

PRESENTATION ≠ BEHAVIOR (beide Playwright, andere Rechtslogik): Präsentation = Auffindbarkeit/Sichtbarkeit/Zugänglichkeit (Impressum leicht erkennbar); Behavior = Entscheidungs-Manipulation/Dark-Pattern (Reject versteckt). Getrennt halten.

Playwright wird damit vom Crawler zum Compliance-Sensor: es prüft, was kein LLM kann — display:none, font-size:4px, Cookie-Layer verdeckt den Footer. LLM sieht <a href="/impressum"> und sagt „erfüllt"; Playwright sieht die Verdeckung und sagt „nicht erfüllt".

Kern-Regel der Architektur: Was im Text nicht beweisbar ist, gehört nicht in den Text-Check. → route per verification_method. Sobald die Klassen sauber getrennt sind, sinken die FP fast automatisch (Impressum: SCOPE+JUDGE 171 → Text-Check-FP 0).

Schema-Status: canonical_controls.verification_method existiert (nur ~4 % befüllt, andere/gröbere Taxonomie document/code_review/tool/hybrid), doc_check_controls hat sie nicht. Die hier definierte Doc-Check-Routing-Achse ist aus control_classification (artifact_type/obligation_type/check_intent) ableitbar → kein Schema-Eingriff (eingefroren) nötig; als abgeleitetes Tag in control_classification führen.

5. Mess-Disziplin (prove-don't-handwave)

• GT mit dem stärksten Modell (claude-opus-4-8), nicht Haiku (zu lasch).
• Robust gegen LLM-Leerantworten: Retry + INSUFFICIENT_EVIDENCE/Eskalation statt FEHLT (ein realer Produktions-Bug, der die FP künstlich aufblähte).
• Anti-Overfit: Kriterien am Gesetz kalibrieren, dann auf ungesehenen Firmen gegenprüfen (DSE: 5 Original + 3 frische → stabile Zahlen = kein Overfit).
• OVH ist stochastisch (±~Rauschen je Lauf) und strenger als Opus → der Rest-FP konvergiert über Module auf OVH-Über-Strenge.
• Zirkularitäts-Leitplanke: Claude = Opus-GT-Modell → ein Claude-Tier-Sim misst die Kaskaden-Reichweite (erreicht Opus-Niveau), nicht eine unabhängige Validierung.

6. Offen (Reihenfolge)

1. Claude-Tier-Sim (DSE + Cookie): quantifiziert den verbleibenden reinen Judge-Fehler nach allen Katalog-Fixes — die letzte große unbekannte Variable. Erwartung: kleiner als roh, weil viel „Judge" sich als Katalog entpuppte.
2. Impressum-Fix: Rechtsform-Scope-Gate (#33) verdrahten + deterministischer Feld-Matcher + Re-Messung.
3. Cookie Wave-2 (Cluster-E) + Produktions-Re-Route der 31 Banner-Controls (control_classification).
4. Produktivschaltung DSE + Cookie (zuletzt; verify-first DB-Write).

7. Artefakte

• DSE: docs-src/development/dse_v1_validation.md, dse_criteria_changelog.json/dse_criteria_backup.json.
• Cookie: cookie_criteria_changelog.json/cookie_criteria_backup.json/cookie_best_practice.json (Container /tmp), Cluster-Map.
• Impressum: impressum_fp_by_cause.json (SCOPE/JUDGE-Split).
• Gedächtnis: project_engine_quality.md (Detail je Modul). Werkzeuge: cc_gt_opus_*, cc_engine_*, cc_*_candidates* (alle macmini /tmp).
• Alle Control-Änderungen nur auf macmini-dev, versioniert, reversibel; Prod-Schaltung ausstehend.