Grounding Check Validation

Grounding Check Validation beantwortet die Frage: „Die gp.*-Checks im Grounding Audit sind eine Theorie über LLM-Citation-Readiness. Stimmt diese Theorie bei MEINEN Seiten?" Das Modul prüft pro Check, ob zitierte Seiten den Check signifikant häufiger bestehen als Vergleichsseiten (SERP-Counterfactuals aus der Citation-Causality-Engine).

Mathematisch: lift = P(check besteht | zitiert) / P(check besteht | counterfactual). Lift > 1 = der Check kommt bei zitierten Seiten häufiger vor.

Zwei Phasen

Phase 1 — Reporting (always-on, read-only). Ein Validation-Lauf samplet n zitierte URLs und n Counterfactual-URLs (Default 150 pro Seite), rendert sie durch alle gp.*-Checks und liefert pro Check lift, p-Wert, verdict. Ergebnis im Admin-Dashboard unter /admin/grounding-check-validation. Keine Auswirkung auf laufende Audits.

Phase 2 — Feedback-Loop (opt-in, gated). Signale mit signifikant positivem Lift landen als candidate in einer Observation-Tabelle. Ein Admin promotet oder verwirft sie. Promotete Signale werden — sofern feedback_loop_enabled = true in config/grounding.php — vom Engine Capability Matrix als „observed" Tier A geführt. Per Default ist das Gate AUS. Du entscheidest, wann (oder ob) deine Validation-Daten in die globale Matrix einfließen.

Wann nutzen

• Du willst beweisen (für DEIN Team / DEINE URLs), welche GEO-Theorien tatsächlich greifen.
• Du willst Tier-B-Signale aus der Engine Capability Matrix empirisch absichern, bevor du Roadmap-Entscheidungen darauf baust.
• Du betreibst regelmäßige Validation-Läufe (Default-Schedule: jeden 17. des Monats um 04:00) und nutzt sie als Audit-Signal für deine GEO-Strategie.

Workflow

1. Run starten — POST /v1/grounding/check-validations mit optional {sample_size: 150} (Max 400). 0 Credits. Antwort: 202 + run_id.
2. Polling — GET /v1/grounding/check-validations/{run} bis status=completed (typisch 2-5 min bei Default-Sample).
3. Ergebnis lesen — results[] mit pro Check: check_id, signal, dimension, n_cited, cited_pass_rate, cf_pass_rate, lift, p_value, verdict (positive / neutral / negative / insufficient_data). Sortiert nach Lift.
4. Phase 2 (Admin) — Review-Queue — Unter /admin/grounding-check-validation siehst du offene Candidate-Observations mit Promote-/Reject-Buttons. Oder via API: POST /v1/grounding/signal-observations/{id}/promote und POST .../reject.
5. Phase 2 aktivieren (optional) — Setze GROUNDING_VALIDATION_FEEDBACK=true in der .env. Erst dann wirken promotete Signale in der Engine Capability Matrix. Empfehlung: VOR der Aktivierung die Candidates kuratieren.

API

Throttling: start 10/min, Promote/Reject 30/min, GET 60-120/min.

Wie Lift gelesen werden muss

Niemals lift isoliert. Immer im Kontext lesen:

• lift = 3.4 bei n_cited = 2 → statistisches Rauschen, kein Signal.
• lift = 1.8 bei n_cited = 78 und p_value = 0.001 → echtes Signal, Promote-Kandidat.
• lift = NULL (statt 999.0) → Counterfactual-Pass-Rate war 0, Lift ist mathematisch undefiniert. Wird in der UI als — dargestellt. (Das ist die bewusste Lehre aus dem CCE-Sentinel-Bug — wir führen den Sentinel-Wert gar nicht erst ein.)

Bekannte Limits

• CCE-Pflicht — ohne aktive Citation-Causality-Pipeline für dein Team gibt es keine Counterfactual-Pages → alle Verdicts werden insufficient_data.
• At-least-once-unsafe. Der Job hat tries = 1 — bei transientem Fehler scheitert er laut, statt zu retryen und Counts zu verdoppeln. Manueller Re-Run via php artisan grounding:validate-checks --team={id}.
• Keine per-Engine-Aufschlüsselung — der Validator misst „wurde zitiert" binär, nicht „wurde von ChatGPT vs. Perplexity vs. Claude zitiert".
• Phase-2-Promotion ist global — eine promotete Observation hebt das Signal in der Matrix für ALLE Teams an. Per-Team-Overrides gibt es nicht. (Die Matrix ist SSOT.)

Verwandte Module

• Grounding Audit — produziert die gp.*-Checks, die hier validiert werden.
• Engine Capability Matrix — Ziel der Phase-2-Promotions.
• AI Visibility Tracking — liefert die Citation-Rohdaten, die das CCE-Modul aggregiert.