diff --git a/docs-src/development/criterion_meta_model.md b/docs-src/development/criterion_meta_model.md new file mode 100644 index 00000000..d0e08291 --- /dev/null +++ b/docs-src/development/criterion_meta_model.md @@ -0,0 +1,155 @@ +# 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`](platform_checker_matrix.md), +> [`verification_method.md`](verification_method.md), [`platform_validation_v1.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`](verification_method.md). +2. **`decision_method`** — welcher Prüfer: REGEX · EMBEDDING · LLM · LINK_RESOLVER · + PLAYWRIGHT · AUDIT · SCANNER. Siehe [`platform_checker_matrix.md`](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.