Benjamin Admin
9d79cf1576
Know-how-Freeze der Website-Compliance-Runde (DSE/Cookie/Impressum/AGB). docs: platform_evidence_v1 (Evidenz-/Qualitaetsnachweis, echte Zahlen), nutzungsbedingungen_mapping (neues Modul = Mapping, empirisch belegt), platform_checker_matrix (Meta-Modell verification_method x decision_method), verification_method, platform_validation_v1. code: checkers/ (reusable Pruefer-Library base+reference+embedding+llm, im Container validiert), agb/ (decision_method-Routing + Checker-Prototypen, 71% FP -> ~0 validiert). Dev-only, kein Prod-Push; Benchmark-GTs/Korpora im internen Archiv (data-retention). Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
88 lines
6.2 KiB
Markdown
88 lines
6.2 KiB
Markdown
# Prüfer-Matrix — Meta-Modell der Doc-Check-Plattform
|
||
|
||
> **Status:** Plattformkonzept, **eingefroren 2026-06-21**. Abgeleitet aus 4 kalibrierten Modulen (DSE, Cookie, Impressum, AGB). Erweitert `verification_method.md` (5→8 Klassen) und fügt die `decision_method`-Achse hinzu.
|
||
> **Kernsatz:** *Nicht jedes Control braucht denselben Richter.* Der **Kontrolltyp bestimmt den Prüfer** — nicht alles ist ein Text-/LLM-Problem.
|
||
|
||
## 0. Die Architektur-Verschiebung
|
||
|
||
**Vorher (implizit):** `Control → Embedding → LLM → Finding`.
|
||
|
||
**Jetzt (empirisch bewiesen):**
|
||
```
|
||
Control → [scope-gate] → artifact_type → verification_method → decision_method
|
||
→ passender Prüfer → Evidence → Finding (severity-getiert)
|
||
```
|
||
|
||
Vier strukturell verschiedene Dokumenttypen führten immer wieder auf dieselbe Meta-Struktur. Das ist größer als jeder Einzel-Fix: es ist mit hoher Wahrscheinlichkeit das Routing-Prinzip für alle ~14.000 Master Controls.
|
||
|
||
## 1. Empirische Basis (4 Module)
|
||
|
||
| Modul | dominanter Prüfer | Beleg |
|
||
|---|---|---|
|
||
| DSE | CONTENT (LLM/Embedding) | Kriterien-Kalibrierung, FP 11→6 % |
|
||
| Cookie-Banner | BEHAVIOR | Enforcement / Dark-Pattern (Playwright) |
|
||
| Cookie-Policy | CONTENT + REFERENCE | Inhalt + Verweise |
|
||
| Impressum | FIELD + PRESENTATION (+ SCOPE-Gate) | Feld-Matcher FP 0 %, Präsentation re-routed |
|
||
| AGB | CONTENT (KEYWORD→EMBEDDING→LLM) + REFERENCE (+ SCOPE-Gate) | 71 % FP → ~0; LLM nur 2/21 Items |
|
||
|
||
## 2. Achse 1 — `verification_method` (welcher Prüfer-TYP)
|
||
|
||
| verification_method | Prüfer | Leitfrage | Beleg | Reifegrad |
|
||
|---|---|---|---|---|
|
||
| **CONTENT** | Embedding + LLM-Kaskade | Was steht (als Offenlegung) im Text? | DSE, Cookie-Policy | kalibriert |
|
||
| **FIELD** | Regex / Extraktion (Feldmatrix) | Welche Pflichtfelder existieren + sind valide? | Impressum (HRB, USt-IdNr, Anschrift) | ✓ FP 0 % |
|
||
| **REFERENCE** | Link-Resolver | Gibt es einen klaren Verweis/Link, löst er auf? | AGB `data_protection` | ✓ 7/7 |
|
||
| **BEHAVIOR** | Playwright + API | Manipuliert die UI die Entscheidung? | Cookie-Banner (Reject=Accept, Pre-Consent-Cookies) | Matrix vorhanden |
|
||
| **PRESENTATION** | Playwright UI-Sensor | Auffindbar / sichtbar / erreichbar? | Impressum „leicht erkennbar" | re-routed |
|
||
| **PROCESS** | Audit / Evidence | Gibt es einen internen Nachweis? | VVT, TOM, interne Richtlinie | Checkliste |
|
||
| **TECHNICAL** | Scanner (Repo / Netz / Config) | Ist die technische Maßnahme implementiert? | geplant: CRA, NIS2, ISO 27001 | offen |
|
||
| **CONTRACTUAL** | Clause-Engine | Ist die Klausel vorhanden + rechtskonform? | AGB (delivery/warranty; Defekte → Stage 3) | teilweise |
|
||
|
||
**CONTENT vs CONTRACTUAL:** CONTENT = Offenlegungs-Prosa (DSE nennt Zwecke). CONTRACTUAL = Vertragsklauseln (AGB-Haftung/Lieferung). Beide können Embedding+LLM nutzen — die Trennung ist die Rechtsnatur + die spätere Defekt-Prüfung (Klausel rechtswidrig?).
|
||
|
||
**PRESENTATION ≠ BEHAVIOR:** beide Playwright, andere Rechtslogik. PRESENTATION = Auffindbarkeit/Sichtbarkeit; BEHAVIOR = Entscheidungs-Manipulation/Dark-Pattern.
|
||
|
||
## 3. Achse 2 — `decision_method` (WIE innerhalb CONTENT/CONTRACTUAL entschieden wird)
|
||
|
||
Die AGB-Entdeckung: **Controls INNERHALB eines Prüfer-Typs brauchen verschiedene Entscheider.** Eskalation nur bei Bedarf (Kostendisziplin):
|
||
|
||
| decision_method | Mechanismus | Wann | Beleg (AGB) |
|
||
|---|---|---|---|
|
||
| **KEYWORD** | Regex-Match | Pflicht eindeutig formuliert | Keyword-Layer |
|
||
| **EMBEDDING** | per-Item-Cosinus-Schwelle (Doc-Chunks × Item-Paraphrasen) | Prosa, semantisch trennbar | 13/21 Items, 0 Fehl-Rescue |
|
||
| **LLM** | Clause-Retrieval (**ganze §-Abschnitte**) + starkes Modell, present/absent | semantisch eng (Embedding trennt nicht) | 2/21 Items (delivery/warranty), 14/14 |
|
||
|
||
`CONTENT_SIMPLE` = KEYWORD/EMBEDDING reicht; `CONTENT_COMPLEX` = LLM nötig. AGB-Bilanz: **81 % deterministisch, 19 % LLM-fähig**, LLM real nur bei Keyword-Miss.
|
||
|
||
## 4. Durable Per-Control-Metadaten (das Routing-Vokabular)
|
||
|
||
| Feld | Zweck |
|
||
|---|---|
|
||
| `artifact_type` | gegen welches Artefakt geprüft wird → Scanner-Routing |
|
||
| `obligation_type` | Rechtsnatur: Pflicht / Empfehlung / Kann → Tier |
|
||
| `check_intent` | was die Prüfung bezweckt |
|
||
| `reference_allowed` | darf per Verweis erfüllt werden → REFERENCE statt CONTENT |
|
||
| `scope` / `scope_requires` | Applicability-Gate (Geschäftsmodell, Rechtsform) — **vor** allen Prüfern |
|
||
| `verification_method` | Achse 1 (Prüfer-Typ) |
|
||
| `decision_method` | Achse 2 (Entscheider innerhalb CONTENT/CONTRACTUAL) |
|
||
| `severity` | HIGH / MEDIUM / LOW → Finding vs Empfehlung |
|
||
|
||
## 5. Hart erarbeitete Plattform-Prinzipien
|
||
|
||
1. **Route, don't uniformly-LLM** — verschiedene Controls, verschiedene Prüfer.
|
||
2. Eskaliere **KEYWORD → EMBEDDING → LLM nur bei Bedarf** (AGB: 17/21 ohne LLM).
|
||
3. Embedding: **per-Item-Schwellen** (globale Schwelle scheitert bei juristischer Prosa — PASS/FAIL überlappen global, trennen per-Item).
|
||
4. LLM-Judge: **ganze §-Abschnitte** schlagen Top-k-Chunks; **starken Tier pinnen** (billig-zuerst-Kaskade eskaliert selbstbewusst-falsche Antworten NICHT, weil die Confidence-Heuristik genauigkeits-blind ist); **present/absent** trennen von der Defekt-Prüfung.
|
||
5. **REFERENCE (Link) ist ein eigener billiger Prüfer** — keinen „siehe Datenschutzerklärung"-Verweis durch ein LLM jagen.
|
||
6. **SCOPE-Gate (Applicability) ist vor allen Prüfern** — N/A-Controls werden nie geprüft.
|
||
7. **Severity → Finding vs Empfehlung** (Tier, nicht droppen).
|
||
8. *Was im Text nicht beweisbar ist, gehört nicht in den Text-Check.*
|
||
|
||
## 6. Schema-Status
|
||
|
||
Kein DB-Eingriff (DB eingefroren). `verification_method` + `decision_method` als **abgeleitete Tags** in `control_classification` (aus `artifact_type` / `obligation_type` / `check_intent` + Item-Kalibrierung). `canonical_controls.verification_method` existiert (~4 % befüllt, gröbere Enterprise-Taxonomie) — **nicht** das Doc-Check-Routing.
|
||
|
||
## 7. Verbindlichkeit
|
||
|
||
Dies ist der **Vertrag**, gegen den implementiert wird. Die AGB-Integration und die nächsten Module (Nutzungsbedingungen, Widerruf, CRA, MaschVO, DORA, NIS2, ISO 27001, AI-Act, VVT, TOM) bauen **dieselbe** Routing-Schicht — nicht modul-lokal. Reihenfolge: **(1) diese Matrix einfrieren → (2) AGB integrieren → (3) Nutzungsbedingungen → (4) Widerruf.**
|