exit_rule_v1_commit/exit_rule_commit/README.md

Exit-Regel v1 – Festlegung absoluter Schwellenwerte (Commit nach Run #6)

Purpose

Verifikation der Stabilität und Festlegung fest definierter Schwellenwerte für die Exit-Regel v1 auf Basis der Runs #3–#6.

Problemstellung: Bisherige Runs (#1–#5) dienten der Stabilisierung und Charakterisierung von Variabilität. Ziel war die Validierung einer stabilen, nicht-angepassten Exit-Regel bei konstantem Setup.

Ziele:

• Reproduzierbarkeit der Run-Ergebnisse nachweisen
• Schwellen für warn_rate, unknown_rate und Δt-Anteil absolut festlegen
• Übergang von experimenteller zu produktiver Regelung (Instrumentalisierung der Exit-Regel)

Kontext & Hintergrund

1000 Events pro Stratum (pinned/unpinned). Gleiches Setup wie Runs #4 und #5.

Gruppierung:

• pinned
• unpinned

Trace-Metadaten / zusätzliche Tags:

• Δt-Werte
• warn_rate
• unknown_rate

Domänenkontext:

• CI-Systeme
• experimentelle Stabilitätsprüfung
• Zeitbasierte Prozessvalidierung

Outlier-Definition:

• Methode: absolute Schwellenwerte
• Beschreibung: Δt < 0 Ereignisse als Ausreißer bezogen auf erwartete nicht-negative Zeitdifferenzen.
• Metrik: Anteil Δt < 0

Motivation:

• Absicherung gegen schleichende Optimierung der Gate-Kriterien
• Beibehaltung eines stabilen Baselines-Sets für 10 Folgeruns
• Saubere Trennung von Kontroll- und Entscheidungsstratum

Methode / Spezifikation

Übersicht:

• Run #6 mit identischem Setup wie Runs #4 und #5 durchgeführt.
• Keine neuen Metriken oder Datenquellen eingeführt.
• Auswertung über 2×2-Kontingenzmatrix (pinned/unpinned × Δt<0/Δt≥0).

Algorithmen / Verfahren:

• Zählen von Events pro Stratum.
• Berechnung der warn_rate und unknown_rate.
• Zählung der Δt<0-Fälle.
• Vergleich der Strata gegen absolute Grenzwerte.
• Markierung von Eskalationen bei Überschreitung.

Input / Output

Input-Anforderungen

Hardware:

• Standard-Runner Infrastruktur

Software:

• identische Kernel, Python-Version und Runner-Image wie Run #4/#5

Konfiguration:

• setup_fingerprint identisch zu Run 4/5
• policy_hash unverändert

Erwartete Rohdaten

Felder pro Run:

• event_id
• stratum
• warn_flag
• unknown_flag
• Δt

Formatbeispiele:

• 1234, pinned, false, false, 0.002
• 7890, unpinned, true, false, 0.014

Trace-Daten:

• Format: CSV oder strukturiertes Log mit Δt- und Statusspalten
• Hinweis: keine strukturellen Änderungen gegenüber Runs #3–#5

Analyse-Ausgaben

Pro Gruppe / pro Governor:

• warn_rate
• unknown_rate
• Anteil Δt<0

Vergleichsausgaben:

• pinned vs unpinned

  • Δ: warn_rate 0.08 pp höher in unpinned

• Trace-Muster: keine Regression zwischen Runs #4–#6

Workflow / Nutzung

Analyse-Workflow:

• Setup-Freeze-Check vor Start des Runs durchführen.
• Run #6 mit fixen N=1000 pro Stratum ausführen.
• Aggregierte Kennzahlen pro Stratum berechnen.
• Exit-Entscheidung anhand der Schwellen treffen:
• WARN-only bei Einhaltung; FAIL bei Grenzwertüberschreitung im unpinned-Stratum.

Trace-Template-Anforderungen

Ziel: Erfassung stabiler Δt-, warn-, unknown-Verteilungen für beide Strata.

Erforderliche Tags & Metadaten:

• stratum
• Δt
• warn_flag
• unknown_flag

trace-cmd-Setup:

• keine Änderungen am Trace-Setup gegenüber Run #4/#5

Run-Design für Contributors:

• konstante Umgebung, keine Versionsabweichungen
• gleicher Datenerfassungszeitraum und Triggerbedingungen

Interpretation & erwartete Ergebnisse

Kernbefunde:

• kein Drift in Kontrollstratum (pinned)
• stabile Warn- und Unknown-Raten gemäß Erwartung
• Δt<0 im unpinned-Stratum bleiben selten (≤0.004)

Implikationen für Experimente:

• Regel v1 als stabil und belastbar klassifiziert
• künftige Runs folgen eingefrorener Baseline
• keine Anpassung relativer Schwellen in den nächsten 10 Runs

Planungsziel:

• Ziel: Instrumentalisierung einer stabilen Exit-Regel für produktive Nutzung
• Vorgehen:
  • absolut definierte Schwellen
  • kein dynamisches Mitskalieren mit Mittelwert
  • fest definierte Baseline über Runs hinweg

Limitationen & Fallstricke

Datenbezogene Limitationen:

• geringe Anzahl Runs (nur drei valide Vergleichspunkte)
• begrenzte Varianzbeobachtung

Kausalität & Generalisierbarkeit:

• aktuell nur für CI-Testlaufumgebung validiert
• nicht automatisch auf produktive Systeme übertragbar

Praktische Fallstricke:

• statische Schwellen können künftige Driftmaskierung nicht ausgleichen
• fehlende dynamische Anpassung kann bei Konfigurationsänderungen Fehlalarme erzeugen

Nächste Schritte & Erweiterungen

Geplante Experimente:

• 10-Folgeruns zur Stabilitätsprüfung
• Langzeitvergleich der unpinned-Stratum-Trends

Analyseziele:

• Validierung der Prognose (pinned stabil in 9–10 Runs)
• Identifikation seltener FAIL-Fälle durch Timingdrift oder Whitelist-Ablauf

Regression & Modellierung:

• Analyse der Δt-Verteilungen über Zeit
• Erweiterung um IQR-basierte Verfahren bei größerem Datensatz

Community-Beiträge:

• Diskussion absolut vs. relativ geführter Exit-Schwellen über MissionControl-Forum