evidence_card_comparison/artifact.validation_checklist/README.md

Validitätscheckliste für den Vergleich der Evidence Cards #40 und #42

Purpose

Dokumentation der Prüf- und Validitätskriterien für den direkten Vergleich zweier Evidence-Card-Runs (#40 und #42) mit identischem Setup und Policy-Konfiguration.

Problemstellung: Unterschiedliche Ergebnisse zwischen Runs können nur dann statistisch interpretiert werden, wenn alle Rahmenbedingungen konstant gehalten und geprüft sind.

Ziele:

• Sicherstellen der Vergleichbarkeit zwischen Runs durch technische Validierung
• Prüfen der Setup-Konsistenz und Policy-Identität
• Vermeidung von Fehlinterpretationen durch unkontrollierte Variablen

Kontext & Hintergrund

Experiment-Logs und Preflight-Daten der Evidence-Card-Runs #40 (aux=2) und #42 (aux=3).

Gruppierung:

• Run #40: Basis-Konfiguration
• Run #42: identisches Setup mit 2×‑ok‑Preflight‑Regel

Trace-Metadaten / zusätzliche Tags:

• Run‑Header‑Metadaten aus Preflight‑Logs
• Fingerprint‑ und Policy‑Hashes zur Setup‑Verifikation

Domänenkontext:

• Vergleichsstudien in automatisierten Performance‑Experimenten
• Freeze‑Band‑Überwachung der Messgrößen zur Validitätssicherung

Motivation:

• Minimierung von Drift und Rauschen bei zeitversetzten Experimenten
• Überprüfung der Effektstabilität vor Interpretation von Leistungsunterschieden

Methode / Spezifikation

Übersicht:

• Validierung erfolgt durch binäre Prüfungen ('Ja/Nein') anhand einer festen Checkliste.
• Kriterium 1: measured_p innerhalb des definierten Freeze‑Bands (0,10 ±0,02).
• Kriterium 2: setup_fingerprint identisch in beiden Runs.
• Kriterium 3: policy_hash identisch, gleicher Freeze‑Guard aktiv.

Algorithmen / Verfahren:

• Ermittlung der Parameter measured_p, setup_fingerprint, policy_hash aus Preflight‑Logs.
• Abgleich der Werte für Runs #40 und #42.
• Klassifikation des Vergleichs als 'valide' bei vollständiger Übereinstimmung.

Input / Output

Input-Anforderungen

Hardware:

• Identische Hardware‑Instanz oder virtualisierte Umgebung mit fixed allocation

Software:

• Gleiches Experiment‑Framework
• identischer Policy‑Hash
• Freeze‑Guard aktiviert

Konfiguration:

• aux=2 (Run #40) vs aux=3 (Run #42)
• 2×‑ok‑Preflight‑Regel bei Run #42

Erwartete Rohdaten

Felder pro Run:

• measured_p
• setup_fingerprint
• policy_hash
• retry_tail_p99
• band_width
• Δband_width

Formatbeispiele:

• {"measured_p": 0.101, "setup_fingerprint": "fp_12345", "policy_hash": "ph_abc"}

Trace-Daten:

• Format: JSON‑basierte Run‑Logeinträge
• Hinweis: Metriken werden aus Preflight‑ und Main‑Run‑Logs extrahiert.

Analyse-Ausgaben

Pro Gruppe / pro Governor:

• retry_tail_p99 (Hotspot / Rest getrennt)
• band_width
• Δband_width

Vergleichsausgaben:

• Run #40 (aux=2) vs Run #42 (aux=3)
  • Δ: Hotspot‑Tail p99 schlechter bei #42

Workflow / Nutzung

Analyse-Workflow:

• Preflight‑Validierung beider Runs durchführen.
• Checkliste vollständig ausfüllen.
• Nur bei validiertem Setup Vergleich der Kernmetriken starten.
• Ergebnisse für Hotspot‑Tail und Bandbreite dokumentieren.

Trace-Template-Anforderungen

Ziel: Sicherstellung der Run‑Konsistenz für reproduzierbare Vergleichsexperimente.

Erforderliche Tags & Metadaten:

• measured_p
• setup_fingerprint
• policy_hash
• aux
• freeze_band

trace-cmd-Setup:

• Einrichtung der 2×‑ok‑Preflight‑Regel für konservative Runs.
• Konfiguration fixer Random‑Seeds zur Minimierung zufälliger Schwankungen.

Run-Design für Contributors:

• Neue Runs müssen Fingerprint‑ und Policy‑Hash‑Übereinstimmung nachweisen.
• Validitätsklasse (z. B. 'aux‑Aussage') im Header dokumentieren.

Interpretation & erwartete Ergebnisse

Kernbefunde:

• Runs #40 und #42 sind validiert vergleichbar.
• Run #42 zeigt erhöhte Latenz im Hotspot‑Tail‑Bereich, keine globale Verlangsamung.
• Freeze‑Band‑Stabilität bestätigt.

Implikationen für Experimente:

• Der Effekt aux=3 verstärkt lokale Empfindlichkeiten, keine generelle Performance‑Degradation.
• Replikation (#43) notwendig, um Richtung und Stärke des Effekts zu bestätigen.

Limitationen & Fallstricke

Datenbezogene Limitationen:

• Kleine Stichprobe (nur zwei Runs) verhindert statistische Generalisierung.

Praktische Fallstricke:

• Interpretation ohne Replikation riskant.
• Preflight‑Gate erhöht Validität, reduziert aber Iterationsgeschwindigkeit.

Nächste Schritte & Erweiterungen

Geplante Experimente:

• Run #43 als aux=3‑Replikat bei identischem Gate und Setup durchführen.

Analyseziele:

• Überprüfung der Stabilität des Hotspot‑Effekts über mehrere Replikate.

Community-Beiträge:

• Standardisierung der ValidationChecklist als JSON‑Template für Folgeexperimente.