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

verification_method — die Prüfer-Routing-Achse

Status: Architektur-Achse (2026-06-19), abgeleitet aus der 3-Modul-Kalibrierung (DSE / Cookie / Impressum). Kernsatz: Nicht jede Compliance-Pflicht ist ein Textproblem. verification_method sagt einem Control, welcher Prüfer zuständig ist — damit nicht alles am LLM hängt.

1. Warum diese Achse existiert

Die Kalibrierung von drei strukturell verschiedenen Dokumentklassen zeigte drei verschiedene dominante Fehlerursachen — und alle ließen sich auf die Wahl des falschen Prüfers zurückführen:

• DSE (Prosa): LLM-Urteil zu streng → Kriterien-Kalibrierung. Prüfer war richtig (LLM), Kriterien falsch.
• Cookie (Banner ≠ Richtlinie): Controls am falschen Artefakt geprüft → artifact_type-Re-Route.
• Impressum (Faktendokument): LLM verfehlt Felder, die dastehen (Adresse, HRB) → deterministischer Feld-Matcher schlägt den LLM. Und 5 Controls waren gar nicht im Text beweisbar (Erreichbarkeit/Verfügbarkeit) → gehören an Playwright, nicht an den Text-Check.

Regel: Was im Text nicht beweisbar ist, gehört nicht in den Text-Check. Sobald die Klassen sauber getrennt sind, sinken die False Positives fast automatisch (Beleg Impressum: SCOPE+JUDGE 171 Roh-FP → Text-Check-FP 0).

2. Die fünf Klassen

verification_method	Prüfer	Leitfrage	Beispiel	Reifegrad
CONTENT	Embedding-Recall + LLM-Kaskade (OVH→Claude)	Was steht da?	DSE nennt Verarbeitungszwecke; Cookie-Richtlinie	DSE/Cookie kalibriert
FIELD	Regex / Parser (Feldmatrix)	Welche Felder existieren + sind valide?	HRB, USt-IdNr, Anschrift, E-Mail+Telefon	Impressum-Fakten ✓ (FP 0 %)
PRESENTATION	Playwright (Rendering-Sensor)	Ist es auffindbar / wahrnehmbar / erreichbar?	Impressum „leicht erkennbar", ständig verfügbar, Footer nicht verdeckt	Re-Route gemacht, Checker offen
BEHAVIOR	Playwright + API (Interaktion)	Manipuliert die UI die Entscheidung?	Reject = Accept, Cookies VOR Consent, Dark Pattern	Cookie-Banner-Matrix vorhanden
PROCESS	Audit / Nachweis	Gibt es einen internen Nachweis?	VVT, interne Richtlinie, Audit-Entscheidung	Org-Checkliste

3. PRESENTATION ≠ BEHAVIOR

Beide nutzen Playwright, prüfen aber verschiedene Rechtslogik — getrennt halten:

• PRESENTATION = Auffindbarkeit / Sichtbarkeit / Zugänglichkeit. Beispiel: Impressum-Link erreichbar, nicht in 4px-Schrift, nicht hinter display:none, nicht dauerhaft vom Cookie-Layer verdeckt.
• BEHAVIOR = Entscheidungs-Manipulation / Dark-Pattern. Beispiel: „Ablehnen" versteckt, Vorauswahl gesetzt, Consent technisch ignoriert.

4. Playwright als Compliance-Sensor (nicht Crawler)

Playwright prüft, was kein LLM kann: Der LLM sieht <a href="/impressum"> und urteilt „erfüllt"; der Sensor sieht, dass das Element verdeckt / unsichtbar / unerreichbar ist und urteilt „nicht erfüllt". Drei technische Prüfer langfristig:

• Content-Checker → LLM (CONTENT)
• Structure-Checker → Regex/Parser (FIELD)
• Presentation-Checker → Playwright (PRESENTATION + BEHAVIOR)

5. Schema-Status & Verortung

• canonical_controls.verification_method existiert, aber nur ~4 % befüllt und mit anderer, gröberer Taxonomie (document / code_review / tool / hybrid — generische Enterprise-Verifikation, nicht das Doc-Check-Routing).
• doc_check_controls hat keine verification_method-Spalte.
• → Die hier definierte Doc-Check-Routing-Achse ist neu, aber ableitbar aus den schon vorhandenen control_classification-Achsen (artifact_type / obligation_type / check_intent). Kein Schema-Eingriff nötig (DB ist eingefroren) — als abgeleitetes Tag in control_classification führen.

Heuristik für die Ableitung (Startpunkt, nicht final):

Signal	→ verification_method
artifact_type = COOKIE_BANNER, Interaktionspflicht	BEHAVIOR
Pflicht zu Erreichbarkeit / Sichtbarkeit / „ständig verfügbar"	PRESENTATION
Faktenfeld (Anschrift, Register, Kennung)	FIELD
obligation_type Prozess / Nachweis ohne Außenwirkung	PROCESS
sonst (inhaltliche Offenlegung in Prosa)	CONTENT

6. Warum das über die 3 Module hinaus zählt

Für die nächsten Module (CRA, Maschinenverordnung, NIS2, TISAX, ISO 27001) ist diese Achse vermutlich fast so wichtig wie artifact_type: viele dieser Pflichten sind PROCESS oder BEHAVIOR, kein Textinhalt. Wer sie an den LLM-Text-Check hängt, erzeugt systematische False Positives. Das ist die eigentliche Erkenntnis der Kalibrierung: nicht dass DSE/Cookie/Impressum funktionieren, sondern dass klar wurde, welcher Prüfer für welche Art von Pflicht zuständig ist.