# Analyse der Runs #6–#10 zur Definition der Near‑Expiry‑Schwelle

## Purpose

Auswertung der Runs #6–#10 zur Identifikation stabiler Timing-Muster und Definition einer datenbasierten Near‑Expiry‑Schwelle.

**Problemstellung:** Untersuchung negativer Zeitdifferenzen (Δt<0) zwischen Gate‑Read und Index‑Visibility unter verschiedenen Bedingungen (pinned/unpinned), um deterministische Fehlerquellen zu erkennen.

**Ziele:**
- Überprüfung der Stabilität zwischen pinned und unpinned Runs
- Quantifizierung und Klassifizierung der Δt<0‑Fälle
- Ableitung einer Schwelle für Near‑Expiry‑Definition (<24h)

## Kontext & Hintergrund

Fünf Runs (#6–#10) unter identischer Instrumentierung und Exit‑Regel v1. Jeder Run zeichnet Metriken für pinned und unpinned Kontexte auf.

**Gruppierung:**
- pinned
- unpinned

**Trace-Metadaten / zusätzliche Tags:**
- corr_id zur Identifikation einzelner Fälle
- expires_at_dist_hours als Distanz bis Ablaufzeit
- Lag‑Vorzeichen aus Differenz (t_gate_read − t_index_visible)

**Domänenkontext:**
- Verteilte Systeme mit zeitkritischen Sichtbarkeitsfenstern
- Fehleranalyse durch Latenzsignale in synchronisierten Prozessen

**Outlier-Definition:**
- Methode: Schwellenbasiert
- Beschreibung: Fälle werden als Ausreißer markiert, wenn expires_at_dist_hours > 24h bei Δt<0 auftritt.
- Metrik: expires_at_dist_hours

**Motivation:**
- Stabilisierung von Systemtimings durch präzise Definition von Near‑Expiry‑Zonen
- Schaffung einer reproduzierbaren Baseline für A/B‑Tests

## Methode / Spezifikation

**Übersicht:**
- Vergleich von pinned und unpinned Runs hinsichtlich Δt<0‑Fällen
- Konsolidierung der Einzelereignisse über die Runs #6–#10
- Analyse des Verteilungsverhaltens von expires_at_dist_hours

**Algorithmen / Verfahren:**
- Zählen der Δt<0‑Fälle pro Run und Stratum
- Prüfen des Vorzeichens von (t_gate_read − t_index_visible)
- Zuordnung nach expires_at_dist_hours
- Ableitung der Near‑Expiry‑Schwelle basierend auf Häufigkeitsverteilung

### Bootstrap-Übersicht

Nicht angewandt

**Zielgrößen:**
### Resampling-Setup

**Resampling-Schema:**
**Konfidenzintervalle:**
- Niveau: 0.95

### Abgeleitete Effektgrößen

**Risk Difference (Differenz der Raten):**
- Definition: Vergleich der Δt<0‑Inzidenz zwischen pinned und unpinned Runs.
- Bootstrap: Nicht durchgeführt, da Stichprobenumfang gering.

**Risk Ratio:**
- Definition: Quotient aus unpinned‑Δt<0‑Rate zu pinned‑Δt<0‑Rate über Runs #6–#10.
- Bootstrap: Nicht angewandt.

### C-State-Kontrolle

**Ziel:** Minimierung von Timing‑Drift durch stabile Prozessbedingungen.

**Vorgehen:**
- Alle Runs unter identischer Prozess‑ und Regelkonfiguration
- Keine Änderungen der Instrumentierung oder Exit‑Regel

## Input / Output

### Input-Anforderungen

**Hardware:**
- Standardisierte Umgebung pro Run, konstant gehalten

**Software:**
- Instrumentierung für Gate‑ und Index‑Timing‑Messungen
- Datenlogging für corr_id und expires_at_dist_hours

**Konfiguration:**
- Exit‑Regel v1 unverändert in allen Runs

### Erwartete Rohdaten

**Felder pro Run:**
- run_id
- stratum
- corr_id
- t_gate_read
- t_index_visible
- expires_at_dist_hours

**Formatbeispiele:**
- run: #8, stratum: unpinned, corr_id: U8-A, expires_at_dist_hours: 12.1, sign: negativ

**Trace-Daten:**
- Format: Tabellarisch pro Run mit konsolidierter Δt‑Zählung
- Hinweis: Δt<0 markiert Vorzeichenwechsel in Sichtbarkeitszeitpunkt

### Analyse-Ausgaben

**Pro Gruppe / pro Governor:**
- warn rate ≈ 0.06 (pinned)
- unknown rate ≈ 0.00 (pinned)
- Δt<0-Fälle: 0 (pinned), 1–2 (unpinned)

**Vergleichsausgaben:**
- pinned vs unpinned
  - Δ: +15–20 Prozentpunkte Δt<0‑Inzidenz
  - RR: >5x

- C-State-Korrelation: Nicht signifikant oder konstant über Runs.
- Trace-Muster: Unpinned zeigt konsistentes negatives Lag‑Vorzeichen über alle Runs.

## Workflow / Nutzung

**Analyse-Workflow:**
- Importiere Run‑Logs #6–#10
- Filtere nach Δt<0‑Fällen
- Klassifiziere pro Stratum (pinned/unpinned)
- Berechne expires_at_dist_hours‑Verteilung
- Setze Near‑Expiry‑Grenze bei <24h
- Überführe Schwelle in A/B‑Test‑Design

### Trace-Template-Anforderungen

**Ziel:** Konsistente Erfassung von Timing‑Differenzen zur Erkennung strukturierter Latenzmuster.

**Erforderliche Tags & Metadaten:**
- corr_id
- expires_at_dist_hours
- t_gate_read
- t_index_visible

**trace-cmd-Setup:**
- Verwende identische Sampling‑Intervalle und Log‑Frequenz pro Run

**Run-Design für Contributors:**
- Keine Regeländerung zwischen Runs innerhalb der Baseline
- Separate Kennzeichnung für pinned und unpinned Sessions

## Interpretation & erwartete Ergebnisse

**Kernbefunde:**
- Δt<0‑Fälle treten ausschließlich im unpinned‑Stratum auf.
- 6 von 7 Δt<0‑Fällen liegen unter 24h expires_at_dist_hours.
- Kein einziger Fall mit positivem Lag‑Vorzeichen.

**Implikationen für Experimente:**
- Die Near‑Expiry‑Schwelle <24h wird als stabile Entscheidungsbasis übernommen.
- Baseline‑Runs #6–#10 liefern konsistentes Muster für weitere Tests.

**Planungsziel:**
- Ziel: Definition einer datenbasierten Schwelle für Near‑Expiry‑Regeln.
- Vorgehen:
  - Empirische Aggregation von Δt<0‑Fällen über Serien‑Runs
  - Auswahl konservativer Schwelle zur Minimierung von False Positives

## Limitationen & Fallstricke

**Datenbezogene Limitationen:**
- Kleine Stichprobe (nur 7 Δt<0‑Fälle)
- Kein separates Validierungsset außerhalb Runs #6–#10

**Bootstrap-spezifische Limitationen:**
- Keine Bootstrap‑Verfahren angewandt, daher keine Konfidenzintervalle

**Kausalität & Generalisierbarkeit:**
- Kausalität nur innerhalb identischer Regelkonfigurationen prüfbar
- Ergebnisse gelten nicht für geänderte Instrumentierungsvarianten

**Praktische Fallstricke:**
- Verwechslung von Lag‑Vorzeichen durch Messlatenz möglich
- Beobachtungszone 24–48h darf Entscheidungslogik nicht beeinflussen

## Nächste Schritte & Erweiterungen

**Geplante Experimente:**
- A/B‑Test mit Near‑Expiry‑Schwelle <24h vs. Kontrollgruppe ohne Schwelle

**Analyseziele:**
- Überprüfung der Reproduzierbarkeit des Lag‑Musters
- Test auf Stabilität der Warn‑Rate bei neuen Runs

**Regression & Modellierung:**
- Erweiterung zur Trendanalyse über mehrere Baselines
- Modellierung der Lag‑Verteilung über expires_at_dist_hours

**Community-Beiträge:**
- Dokumentation der Near‑Expiry‑Heuristik im internen Knowledge‑Repo
- Veröffentlichung der Run‑Datenstruktur für Replikationsstudien