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

Kriterien-Meta-Modell & Compliance-Tier-Architektur

Status: EINGEFROREN 2026-06-22. Änderungen an diesem Modell sind Architekturentscheidungen und erfordern eine bewusste Freigabe (DB-Owner / Produktverantwortung). Verwandt: platform_checker_matrix.md, verification_method.md, platform_validation_v1.md.

1. Motivation

Die Kalibrierung der vier Website-Compliance-Module deckte vier verschiedene dominante Fehlerursachen auf:

Modul	Dominanter Hebel
Cookie-Policy	Sufficiency (Judge)
Impressum	Scope / Routing
AGB	Decision-Method / Routing
DSE	Überladene Controls + Vermischung „gesetzliches Minimum vs. Best Practice"

Die DSE-Untersuchung (Adjudikation von 13 Judge↔GT-Disagreements) ergab: 85 % der Restfehler sind Katalog-Defekte, 15 % Prüfer. Der größte Einzeldefekt: ein Control bündelt mehrere Anforderungen unterschiedlicher Verbindlichkeit und wird nur dann als ERFÜLLT gewertet, wenn alle erfüllt sind. Folge: gesetzlich konforme Dokumente werden als „FEHLT" gemeldet, weil eine Best-Practice-Empfehlung fehlt.

Dieses Modell behebt das im Katalog — ohne den Prüfer zu ändern und ohne Controls physisch aufzuspalten.

2. Datenmodell

Ein Control bleibt stabil (UUID, Citations, GT-Historie, Kalibrierung, Statistiken). Seine pass_criteria werden von einer Stringliste zu atomaren, getypten Kriterien-Objekten:

Control                      (stabile control_uuid — NICHT splitten)
 └─ criteria: Criterion[]

Criterion
 ├─ criterion            (Text der Einzelanforderung)
 ├─ legal_basis          (z. B. "Art. 13(1)(c) DSGVO")
 ├─ verification_method  (Achse 1 — WAS wird geprüft)
 ├─ decision_method      (Achse 2 — WIE wird entschieden)
 ├─ compliance_tier      (Achse 3 — WIE VERBINDLICH)
 └─ weight               (reserviert für Reifegrad, s. §6 — heute NICHT gating)

Speicherort: canonical_controls.generation_metadata->'tiered_criteria' (jsonb). Keine Schema-Änderung. Kein physischer Control-Split (Variante A wurde verworfen: neue UUIDs → Verlust von Benchmarks/Kalibrierung/Citation/GT = Migrationsprojekt).

3. Die drei Achsen

Jedes Kriterium trägt drei unabhängige Klassifikationen:

1. verification_method — artefakt-abhängig: CONTENT · FIELD · REFERENCE · BEHAVIOR · PRESENTATION · PROCESS · TECHNICAL · CONTRACTUAL. Siehe verification_method.md.
2. decision_method — welcher Prüfer: REGEX · EMBEDDING · LLM · LINK_RESOLVER · PLAYWRIGHT · AUDIT · SCANNER. Siehe platform_checker_matrix.md.
3. compliance_tier (neu, dieses Dokument) — Verbindlichkeit:
   • LEGAL_MINIMUM — gesetzlich erforderlich. Beeinflusst den Compliance-Status.
   • BEST_PRACTICE — empfehlenswert, gesetzlich nicht erforderlich. Erscheint als Empfehlung. Beeinflusst den Status nie.
   • OPTIONAL — Komfort/Detailtiefe. Empfehlung. Beeinflusst den Status nie.

Achse 1 + 2 sind primär per Kriterium (atomar); ein Control kann Kriterien verschiedener Methoden mischen.

4. Status-Berechnung (3 Zustände) — Gating NUR auf LEGAL_MINIMUM

Sei LM die Menge der LEGAL_MINIMUM-Kriterien eines Controls und met(LM) die erfüllten darunter:

ERFÜLLT     := |LM| > 0  und  met(LM) == |LM|          (alle Pflicht-Kriterien erfüllt)
TEILWEISE   := 0 < met(LM) < |LM|                      (mind. eines erfüllt, mind. eines fehlt)
FEHLT       := |LM| > 0  und  met(LM) == 0             (kein Pflicht-Kriterium erfüllt)

BEST_PRACTICE/OPTIONAL-Kriterien gehen nicht in diese Berechnung ein. Sie werden separat als Empfehlungen ausgewiesen (§5, Ebene 2).

Invariante: Ein erfülltes gesetzliches Minimum darf NIE durch fehlende Best-Practice-/Optional-Kriterien auf FEHLT/Rot gezogen werden.

5. Reporting — drei Ebenen

Ebene	Inhalt	Quelle
1 — Compliance-Status (rechtlich)	ERFÜLLT / TEILWEISE / FEHLT	NUR LEGAL_MINIMUM
2 — Optimierungspotenzial	„Empfehlungen: N · Best-Practice-Abdeckung X %"	BEST_PRACTICE + OPTIONAL
3 — Risiko-Reifegrad (optional, später)	„Reifegrad Y %" für CRA/NIS2/ISO 27001/TOM	gewichtet, s. §6

Anti-Pattern (verboten): kein „Compliance-Score = 72 %", wenn alle gesetzlichen Anforderungen erfüllt sind. Das erzeugt „welche 28 % fehlen?" → „eigentlich keine Pflicht" → der Score wird wertlos.

Farb-Semantik (Bedeutung, nicht Wertung)

• Grün = gesetzliche Anforderungen erfüllt (Pflicht erfüllt)
• Blau = empfohlene Verbesserungen vorhanden (Optimierung möglich)
• Rot = gesetzliche Anforderungen fehlen (Pflichtverletzung)

TEILWEISE ist visuell ein eigener Zustand (z. B. Gelb/Amber): Pflicht teilweise erfüllt. Verbindet sich mit der BreakPilot-Tonalität (kein Panik-Rot) und dem 3-Tier-Obligation-Modell (Pflicht/Empfehlung/Kann).

6. weight

Wird heute gespeichert, aber nicht für das Gating verwendet (bewusste Entscheidung: Gewichte erzeugen sofort „warum 0.3 und nicht 0.4?"-Diskussionen). Es ist die Reserve für Ebene 3 (Reifegrad): später lässt sich daraus ein gewichteter Best-Practice-/Reifegrad-Prozentwert berechnen. Richtwerte: LEGAL_MINIMUM 1.0 · BEST_PRACTICE ~0.3 · OPTIONAL ~0.1.

7. compliance_tier ist eine PLATTFORM-Achse

Nicht nur ein DSE-Fix. Dasselbe Muster tritt überall auf — DSE (Minimum vs. BP), Cookie (Offenlegung vs. Transparenz), Impressum (Pflicht- vs. Komfortfelder), AGB (erforderlich vs. empfehlenswert) und perspektivisch CRA/NIS2/Maschinenverordnung. Ein einzelnes Kriterium trägt überall compliance_tier; die Plattform wertet Compliance / Empfehlungen / Reifegrad regulierungsunabhängig aus.

8. Validierungsnachweis (Pilot, 2026-06-22)

Geschrieben auf macmini (generation_metadata.tiered_criteria, prod-guarded), gemessen gegen Opus-GT (ikea/ob/teamviewer):

• 5 Pilot-Controls (SEC-7285-A03, SEC-3257-A01, Portabilitäts-Cluster DATA-1613/DATA-2552/COMP-2087): alle 6 Disagreement-Fälle (vormals falsch-FEHLT) wandern zu ERFÜLLT + Empfehlungen; echte Lücken bleiben korrekt FEHLT — ohne Prüfer-Änderung.
• TEILWEISE-Validierung (DATA-1445-A02, SEC-4752-A02): der 3. Status tritt real auf (1 ERFÜLLT / 5 TEILWEISE), Splitter durchgängig „Speicherdauer pro Zweck" (Art. 13(2)(a)).
• Lehre: selbst Pilot-Kriterien können Minimum + Best-Practice vermischen („Speicherdauer pro Zweck"). Die LM/BP-Linie ist eine Produktpolitik-Entscheidung (Mensch), kein NLP-Problem. Das Modell ist korrekt; die Kriterien-Schärfe ist Kurationsarbeit.

9. Invarianten (nicht verletzen)

1. Control-UUID bleibt stabil — kein physischer Split.
2. Status (Grün/Gelb/Rot) hängt ausschließlich an LEGAL_MINIMUM.
3. BEST_PRACTICE/OPTIONAL erzeugen Empfehlungen, nie einen FEHLT-Status.
4. Kein Prozent-Compliance-Score, wenn alle gesetzlichen Anforderungen erfüllt sind.
5. Speicherung in generation_metadata (jsonb) — keine Schema-Migration.

10. Rollout (nach diesem Freeze)

1. 10–15 der schlimmsten überladenen DSE-Controls tiern (nicht alle 49 auf einmal).
2. 3-Status-Logik in die Live-DSE-Engine verdrahten (heute nur Mess-Harness).
3. Benchmark erneut: FP / FN / Precision / Recall + Status-Verteilung.
4. Erst bei stabilem Effekt: Rollout auf alle 49 überladenen Controls.