run_series_analysis/artifact-3/README.md

# Methodische Dokumentation der Runs #6–#9 zur Near-Expiry-Definition

## Purpose

Analyse der Runs #6 bis #9 zur Identifikation von Timing-Anomalien und zur Entwicklung einer Near-Expiry-Schwellenlogik.

**Problemstellung:** In den unpinned Runs treten wiederholt Fälle mit Δt<0 auf, d. h. t_gate_read liegt vor t_index_visible. Diese strukturelle Verschiebung soll systematisch untersucht werden.

**Ziele:**
- Erkennen struktureller Timing-Verschiebungen zwischen pinned und unpinned Gruppen
- Validieren der Stabilität des Referenzverhaltens (pinned)
- Ableiten einer robusten Definition der Near-Expiry-Grenze

## Kontext & Hintergrund

Run-basierte Messreihe #6–#9, jeweils mit getrennten pinned/unpinned-Strata. Pro Run Aggregation der Kennwerte warn_rate, unknown_rate, Count(Δt<0).

**Gruppierung:**
- pinned
- unpinned

**Trace-Metadaten / zusätzliche Tags:**
- corr_id pro Fall
- expires_at_dist_hours
- t_gate_read
- t_index_visible

**Domänenkontext:**
- Timing-Validierung von Index- und Gate-Events bei Ablauf-bezogenen Operationen
- Trennung nach Laufzeitnähe zur Ablaufzeit (expiry proximity)

**Outlier-Definition:**
- Methode: Negative Δt-Fälle
- Beschreibung: Δt<0 gilt als Timing-Anomalie, da das Gate-Event vor der Index-Sichtbarkeit erscheint.
- Metrik: Δt = t_gate_read − t_index_visible

**Motivation:**
- Feststellung, ob Δt<0 reproduzierbar auftritt
- Herleitung einer Near-Expiry-Grenze basierend auf expires_at_dist_hours
- Vorbereitung einer A/B-Teststruktur zur Evaluierung alternativer Ablaufstrategien

## Methode / Spezifikation

**Übersicht:**
- Run-basierte Replikation mit konstanter Exit-Regel v1
- Trennung von pinned/unpinned zur Isolierung struktureller Unterschiede
- Messung von Δt und expires_at_dist_hours zur Identifikation korrelierter Effekte

**Algorithmen / Verfahren:**
- Pro Run Erfassung der counts(Δt<0) getrennt nach Stratum
- Zuordnung der zugehörigen expires_at_dist_hours-Werte
- Konsistenzprüfung der Vorzeichenrichtung von Δt über Runs hinweg

## Input / Output

### Input-Anforderungen

**Hardware:**
- Standard-Compute-Node ohne Lastvariation

**Software:**
- identische Binary-Versionen wie bei Runs #6–#8

**Konfiguration:**
- Exit-Regel v1 unverändert
- Pinned/Unpinned strikt getrennt

### Erwartete Rohdaten

**Felder pro Run:**
- run_id
- stratum
- warn_rate
- unknown_rate
- count_negative_dt
- expires_at_dist_hours
- t_gate_read
- t_index_visible

**Formatbeispiele:**
- 9, unpinned, -, -, 3, [6.8,14.2,31.5], timestamps

**Trace-Daten:**
- Format: CSV oder JSON mit Zeitstempeln
- Hinweis: Jedem corr_id-Fall ist eine expire_at_dist_hours-Zuordnung erforderlich.

### Analyse-Ausgaben

**Pro Gruppe / pro Governor:**
- warn_rate
- unknown_rate
- count_negative_dt

**Vergleichsausgaben:**
- pinned vs unpinned
  - Δ: Δt<0-Auftrittsfrequenz
  - RR: Vorkommensrate Δt<0(unpinned)/Δt<0(pinned)

## Workflow / Nutzung

**Analyse-Workflow:**
- Runs 6–9 durchführen mit unveränderter Konfiguration
- Anomalien (Δt<0) extrahieren und expires_at_dist_hours notieren
- Mini-Zeitreihe über Runs bilden
- Schwellenanalyse für Near-Expiry-Grenzen (<24h vs. <48h)
- Nach Run #10 abschließende Festlegung

### Trace-Template-Anforderungen

**Ziel:** Reproduzierbare Erfassung von Δt und Ablaufnähe pro corr_id

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

**trace-cmd-Setup:**
- Synchronisierte Systemzeit
- Konsistente Samplingrate

**Run-Design für Contributors:**
- Keine Metrikänderung zwischen Runs
- Klar dokumentierte Strata-Zuordnung

## Interpretation & erwartete Ergebnisse

**Kernbefunde:**
- Pinned-Stratum zeigt stabile Null-Δt-Struktur
- Unpinned-Stratum weist wiederkehrende Δt<0 auf, insbesondere bei expires_at_dist_hours <24h
- Einzelne Ausreißer oberhalb 30h (Grenzfall 31.5h)

**Implikationen für Experimente:**
- Mögliche Schwelle <24h zur Definition des Near-Expiry-Bereichs
- Alternative konservative Grenze <48h zur Robustheitsprüfung

**Planungsziel:**
- Ziel: Bestimmung der Near-Expiry-Zone zur künftigen A/B-Testbasierten Ablaufanalyse
- Vorgehen:
  - Finale Erweiterung auf Run #10
  - Vergleich der expires_at_dist_hours-Verteilung über alle negativen Δt-Fälle

## Limitationen & Fallstricke

**Datenbezogene Limitationen:**
- Geringe Fallzahl (n=3 pro Run bei unpinned)
- Mögliche Korrelation mit Last oder Cache-Verhalten nicht adressiert

**Kausalität & Generalisierbarkeit:**
- Δt<0-Fälle indikativ, nicht deterministisch
- Keine Kausalitätsaussage zu Ablaufzeit ohne weitere Runs

**Praktische Fallstricke:**
- Fehlende Run-Synchronisation kann falsche Δt erzeugen
- Zu frühe Schwellenfestlegung kann zu Overfitting führen

## Nächste Schritte & Erweiterungen

**Geplante Experimente:**
- Run #10 identisch durchführen, Ergänzung der Zeitreihe

**Analyseziele:**
- Finalisierung der Near-Expiry-Definition
- Überprüfung der Lag-Konsistenz über alle Fälle

**Regression & Modellierung:**
- Erstellung eines einfachen Modells zur Vorhersage negativer Δt basierend auf expires_at_dist_hours

**Community-Beiträge:**
- Sammlung externer Beobachtungen zu ähnlichen Mustern („Gate vor Index sichtbar“)