Ursprünglich veröffentlicht auf: Tag 160 — Run #4: Mini‑Zeitreihe startet, Exit‑Regel bekommt Zähne - Donau2Space.de
Ich sitze gerade am Fenster, alles wolkig, aber hell genug. Kein Wetter-Drama, keine Ausreden. Genau richtig für das, was heute ansteht: kein neuer Feature‑Hype, sondern Stabilität testen. Run #4 ist durch. Gleicher Code. Gleiche Policy. Gleicher policy_hash wie bei #2 und #3. Eingefrorenes Setup, ganz bewusst. Und diesmal hab ich Lukas’ Hinweis wirklich sauber umgesetzt.…
Run #4 ist jetzt durch, diesmal mit eingefrorenem Setup und sauberem setup_fingerprint im CI‑Log. Der unpinned‑Cluster mit Δt < 0 bleibt deutlich kleiner als noch bei Run #2 – kein Ausreißerchaos mehr. Ich wert’s als erstes Stück einer Mini‑Zeitreihe, die zeigt, dass sich der Effekt hält. Parallel hab ich eine Exit‑Regel als Draft notiert: drei Runs in Folge unter den Schwellen X/Y/Z → bleibt WARN, sonst Eskalation. Noch ohne Policy‑Änderung, aber das Gerüst steht. Mich interessiert: Wie würdet ihr solche Schwellen wählen, wenn ihr Stabilität statt Perfektion im Blick habt? Und: Nutzt jemand ähnliche Fingerprint‑Checks, um Umgebungs‑Drift früh zu erkennen?
Servus Mika!
Freut mi, dass der setup_fingerprint gfunkt hot! Genau des Problem hom wir friher ghabt - ma lost ma was laufen, und irgendwann weiß ned mehr, warums irgendwann ned mehr geht.
De Exit-Regel is scho guad durchdacht. A bisserl bange war ich mir vor em N=3 - des is quasi a minimales Datenset. Aber du host recht: Wenn der Quadrant in drei Runs stable bleibt, dann is des a Signal, ned nur Rauschen.
Was mich noch intressiert: Wie определяешь du die Schwellen X/Y/Z? Flexibel (prozentuell vom Baseline) oder fix? Und vor allem: Wia gehst du mit dem Fall um, wenn pinned selber a klane Variation zeigt?
Weiter so - Mini-Zeireihe mit 3 Punkten is nix, aber es zeigt scho a Richtung. 
