Kurz vor zwölf, draußen über Passau ein fast schon übertrieben klarer Himmel. 9, irgendwas Grad, kaum Wind. Oben totale Ruhe – unten im CI darf’s jetzt keine Unschärfe mehr geben. Heute ist der Punkt, an dem ich nicht mehr weiter optimiere, sondern entscheide.
Bevor ich irgendwas starte: Setup‑Freeze‑Check.
setup_fingerprint: identisch zu Run #4 und #5policy_hash: unverändert- runnerimage / kernel / python / gateversion: exakt gleich
Kein Drift. Keine heimlichen Updates. Kein „ja aber vielleicht war heute…“. Wenn sich was bewegt, dann im System – nicht im Unterbau. Genau das war ja der offene Faden seit Run #4: Reproduzierbarkeit beweisen, bevor man an Schwellen dreht. Der ist hiermit sauber geprüft.
Run #6 – gleiche Strecke, gleiche Tabelle
Wie angekündigt: keine neuen Metriken, kein Umbau des Logs, keine IQR‑Diskussion (Lukas, ich hab dich im Ohr 😉). Nur die gleiche Kurz‑Tabelle wie #3–#5.
N = 1000 Events pro Stratum
Pinned
- warn_rate = 0.06
- unknown_rate = 0.00
- Δt < 0 = 0
Unpinned
- warn_rate = 0.14
- unknown_rate = 0.02
- Anteil Δt < 0 = 0.004
2×2‑Quadranten (pinned/unpinned × Δt<0/Δt≥0)
-
pinned:
-
Δt < 0 → 0
-
Δt ≥ 0 → 980
-
unpinned:
-
Δt < 0 → 4
-
Δt ≥ 0 → 996
Das Entscheidende: keine Peak‑Rückkehr bei unknown, negative Δt im unpinned‑Stratum bleiben selten (4 von 1000), und pinned verhält sich weiter wie ein sauberer Referenzkanal. Run #4, #5, #6 sind jetzt drei direkt vergleichbare Punkte ohne Regression.
Damit ist der Loop „Run #6 Resultate abwarten“ geschlossen.
Exit‑Regel v1 – Commit
Nach #3–#6 ziehe ich die Linie. Kein „noch ein bisschen beobachten“, kein Schwellen‑Feintuning. Ich committe v1.
Fixes N:
- 1000 Events pro Stratum
Schwellen (absolut, nicht relativ):
Pinned (Kontrollkanal):
- warn_rate ≤ 0.10
- unknown_rate ≤ 0.01
- Aktion: bleibt grundsätzlich WARN‑only
Unpinned (entscheidend):
- warn_rate ≤ 0.20
- unknown_rate ≤ 0.03
- Anteil Δt < 0 ≤ 0.01
- Aktion: Wenn eine dieser Schwellen reißt → Eskalation (FAIL)
Ganz bewusst absolut definiert. Keine prozentuale Baseline‑Ableitung, kein Mitschwimmen mit dem Mittelwert.
Danke an Lukas für die Frage nach absolut vs. relativ. v1 ist absolut und die Baseline bleibt für die nächsten 10 Runs eingefroren. Kein Nachziehen nach jedem Durchlauf. Sonst optimiere ich mir das Gate weich, bis es nichts mehr aussagt.
IQR & Co. hebe ich mir auf, wenn wir mehr Datenpunkte haben. Mit drei, vier Runs macht robuste Statistik noch keinen Sinn – da hattest du fei recht.
10‑Run‑Prognose
Meine Erwartung:
- pinned bleibt in 9–10 von 10 Runs unter den Grenzen
- unpinned zeigt höchstens einen echten Kandidaten für WARN/FAIL – wahrscheinlich ausgelöst durch Timing‑Drift oder Whitelist‑Expiry
Wenn ich danebenliege, lerne ich was. Wenn nicht, ist das Gate stabil genug, um nicht mehr im Fokus zu stehen.
Und genau das ist der Punkt: Ab jetzt ist es kein Experiment mehr, sondern ein Instrument. Ich beobachte es, aber ich diskutiere es nicht mehr nach jedem Lauf neu.
Timing sauber zu halten, auch im Millisekunden‑Bereich, fühlt sich manchmal übertrieben an. Aber Systeme, die später in größeren Kontexten laufen – Satelliten, verteilte Sensorik, autonome Abläufe – verhandeln nicht über Zeit. Die nehmen sie, wie sie kommt. Und wenn dein System da nicht sauber tickt, merkst du’s erst, wenn’s teuer wird.
Run #6 ist damit nicht spektakulär. Aber er ist ein Commit‑Moment.
Und ganz ehrlich: Das fühlt sich besser an als noch ein weiterer halboffener Loop. Pack ma’s. 🚀
# Donau2Space Git · Mika/exit_rule_v1_commit # Mehr Code, Plots, Logs & Scripts zu diesem Artikel $ ls LICENCE.md/ event_data_capture/ exit_rule_commit/ readme_md/ setup_fingerprint_check/ $ git clone https://git.donau2space.de/Mika/exit_rule_v1_commit $
Diagramme
Begriffe kurz erklärt
- setup_fingerprint: Eine Prüfsumme, die sich aus den Start‑Einstellungen ergibt und hilft, Konfigurationsänderungen im System zu erkennen.
- policy_hash: Ein kurzer Datenwert, der Richtlinien oder Sicherheitsregeln eindeutig kennzeichnet, ähnlich einem Fingerabdruck.
- IQR: Der Interquartilsabstand zeigt, wie stark Messwerte in der Mitte eines Datensatzes schwanken.
- Stratum: In der Zeitmessung beschreibt es, wie weit eine Uhr von der ursprünglichen Referenz‑Zeitquelle (z. B. GPS) entfernt ist.
- Timing‑Drift: Die Abweichung einer Uhr von der exakten Zeit, z. B. wenn sie täglich ein paar Millisekunden vor- oder nachgeht.
- Whitelist‑Expiry: Der Zeitpunkt, an dem eine Freigabeliste automatisch abläuft und Einträge neu bestätigt werden müssen.
- WARN‑only: Ein Modus, bei dem nur gewarnt wird, statt den Vorgang abzubrechen oder zu blockieren.
- Commit‑Moment: Der exakte Zeitpunkt, an dem eine Änderung dauerhaft ins System übernommen wird.
- Setup‑Freeze‑Check: Eine Kontrolle, die sicherstellt, dass während der Initialisierung keine weiteren Änderungen mehr passieren.
- Exit‑Regel v1: Eine definierte Vorgehensweise, wie ein Prozess oder Programm beim Beenden reagieren soll.
- 10‑Run‑Prognose: Eine einfache Vorhersage, die Werte aus zehn Durchläufen auswertet, um Trends oder Abweichungen zu erkennen.
