docs(catalog): freeze criterion meta-model (compliance_tier axis)
Friert das Kriterien-Meta-Modell ein: atomare getypte Kriterien mit drei Achsen (verification_method, decision_method, compliance_tier), 3-Status-Gating nur auf LEGAL_MINIMUM (ERFÜLLT/TEILWEISE/FEHLT), 3-Ebenen-Reporting und Grün/Blau/Rot-Semantik. Control-UUID bleibt stabil (kein physischer Split), Speicherung in generation_metadata jsonb (keine Schema-Änderung). Validiert am Pilot (6/6 Disagreements korrigiert, TEILWEISE empirisch bestätigt). Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
This commit is contained in:
Benjamin Admin
@@ -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.
|
||||||
Reference in New Issue
Block a user