Benjamin_Boenisch
38a347a82a
AGB v2 (decision_method routing, 71%FP->~0) + DSE v3 (4-layer, recovered from container) + Architektur-Tab into /sdk/agent live path. Incl CI robustness (detect-changes.sh + PR-head checkout) + security (hardcoded Qdrant key removed, gitleaks allowlist). Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
6.2 KiB
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 diedecision_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
- Route, don't uniformly-LLM — verschiedene Controls, verschiedene Prüfer.
- Eskaliere KEYWORD → EMBEDDING → LLM nur bei Bedarf (AGB: 17/21 ohne LLM).
- Embedding: per-Item-Schwellen (globale Schwelle scheitert bei juristischer Prosa — PASS/FAIL überlappen global, trennen per-Item).
- 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.
- REFERENCE (Link) ist ein eigener billiger Prüfer — keinen „siehe Datenschutzerklärung"-Verweis durch ein LLM jagen.
- SCOPE-Gate (Applicability) ist vor allen Prüfern — N/A-Controls werden nie geprüft.
- Severity → Finding vs Empfehlung (Tier, nicht droppen).
- 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.