# Go/No-Go-Kriterien für Replikationsruns #15–#16

## Purpose

Dokumentation der Go/No-Go-Entscheidungslogik auf Basis der stabilen Latenz- und Heilungsmetriken aus Runs #14–#16.

**Problemstellung:** Bestimmen, ob die beobachtete Performance und Heilungsstabilität der near-expiry-unpinned-Fälle konsistent genug ist, um als Freigabekriterium zu dienen.

**Ziele:**
- Definieren reproduzierbarer Grenzwerte für Latenzverhalten
- Formalisieren der Go/No-Go-Regel zur Produktionsfreigabe
- Evaluieren der Stabilität von Heilungsraten

## Kontext & Hintergrund

Metriken der Runs #14–#16 mit identischem Setup (near-expiry-unpinned, Δt<0, fixed delay, 1 Retry).

**Gruppierung:**
- Run #14
- Run #15
- Run #16

**Trace-Metadaten / zusätzliche Tags:**
- retry_total_overhead_ms
- warn_rate
- unknown_rate
- healing_rate

**Domänenkontext:**
- Backend-Latenzmessung
- Retry-Mechanismusüberwachung
- Replikationsvalidierung

**Motivation:**
- Sicherstellen der Reproduzierbarkeit vorheriger Verbesserungen (#13/#14)
- Überführen experimenteller Resultate in belastbare Release-Kriterien

## Methode / Spezifikation

**Übersicht:**
- Analyse der Δt<0-Fälle und Heilungsraten pro Run.
- Berechnung von Latenzquantilen (p50, p95, p99, min, max).
- Aggregierte Auswertung der Runs #14–#16 zur Stabilitätsprüfung.
- Herleitung einer quantitativen Go/No-Go-Regel (Gate V1).

**Algorithmen / Verfahren:**
- Zähle alle Fälle mit Δt<0 pro Run.
- Berechne p50, p95, p99, min, max aus retry_total_overhead_ms.
- Berechne warn_rate, unknown_rate und Heilungsrate.
- Vergleiche die Kennzahlen über Runs hinweg.
- Prüfe die definierten Grenzwerte gemäß Go/No-Go-Regel.

## Input / Output

### Erwartete Rohdaten

**Felder pro Run:**
- run_id
- delta_t
- retry_total_overhead_ms
- warn_rate
- unknown_rate
- healing_rate

**Formatbeispiele:**
- {run_id:15, delta_t:-3.2, retry_total_overhead_ms:44, warn_rate:0.061, unknown_rate:0.00, healing_rate:1.00}

### Analyse-Ausgaben

**Pro Gruppe / pro Governor:**
- p50_overhead_ms
- p95_overhead_ms
- p99_overhead_ms
- min_overhead_ms
- max_overhead_ms
- healing_rate
- warn_rate
- unknown_rate

**Vergleichsausgaben:**
- Run #15 vs Run #16
  - Δ: warn_rate_diff=0.002

## Workflow / Nutzung

**Analyse-Workflow:**
- Runs laden (#14–#16).
- Relevante Metriken extrahieren (Δt<0, retry_total_overhead_ms, warn_rate, ...) pro Run.
- Quantile über retry_total_overhead_ms berechnen.
- Vergleichstabellen erstellen und aggregiert auswerten.
- Validierung gegen definierte Go/No-Go-Kriterien durchführen.

### Trace-Template-Anforderungen

**Ziel:** Gleichbleibende Messstruktur zur Replikationsvalidierung.

**Erforderliche Tags & Metadaten:**
- run_id
- delta_t
- retry_total_overhead_ms
- warning_class
- retry_success_flag

**trace-cmd-Setup:**
- Alle Runs mit identischem Retry-Setup und fixer Delay-Konfiguration ausführen.
- Keine Änderungen an Kontrollparametern zwischen Runs #14–#16.

## Interpretation & erwartete Ergebnisse

**Kernbefunde:**
- Δt<0 tritt nur im near-expiry-unpinned-Stratum auf.
- Heilungsrate in allen Runs 100%.
- warn_rate bleibt stabil (≈0.06).
- Overhead-Verteilung eng und unter 80 ms (p95/p99).

**Implikationen für Experimente:**
- Reproduzierbarkeit der Abhilfe bestätigt.
- Definierte Grenzen für Produktionsfreigabe belastbar.

**Planungsziel:**
- Ziel: Einheitliche Freigabekriterien (Gate V1).
- Vorgehen:
  - Festlegung quantitativer Latenzschwellen (p95≤80 ms, p99≤90 ms).
  - Toleranzprüfung gegen warn_rate und unknown_rate.
  - Validierung der Heilungsrate ≥99%.

## Limitationen & Fallstricke

**Datenbezogene Limitationen:**
- Nur drei Runs betrachtet; keine Langzeitvalidierung.
- Keine Variation anderer Strata oder Parameter.

**Kausalität & Generalisierbarkeit:**
- Resultate nur für near-expiry-unpinned-Kontext gültig.
- Keine Aussage zu anderen Retry-Strategien.

**Praktische Fallstricke:**
- Zu knappe Schwellen könnten bei Systemlast ungewollte No-Go-Ergebnisse erzeugen.
- Messrauschen bei Latenzen <50 ms kann Einfluss auf p95/p99 haben.

## Nächste Schritte & Erweiterungen

**Geplante Experimente:**
- Run #17 mit veränderter Delay-Strategie für Belastungstest.
- Langzeitserie über 10 Replikationen zur Stabilitätsmessung.

**Analyseziele:**
- Bootstrap-Konfidenzintervalle für Latenzquantile berechnen.
- Variabilität der warn_rate unter Produktionslast prüfen.

**Community-Beiträge:**
- Diskussion optimaler Schwellenwerte (80/90 vs. 70/80 ms).
- Integration der Go/No-Go-Regel in CI-Pipeline.