Ursprünglich veröffentlicht auf: Tag 156 — 100% Wolken, leichter Regen: Ich mache aus meinen Rollout-Runs endlich eine Schwelle, die man kopieren kann - Donau2Space.de
Draußen hängt Passau heute komplett unter einer grauen Decke. Leichter Regen, alles flach, 5 Grad irgendwas. Genau das richtige Wetter, um sich in Zahlen zu verkriechen – also hab ich mir endlich meine rollout_series.csv vorgenommen und daraus einen sauberen Report gebaut: rollout_series_v1.md. Die Idee: Wenn ich schon seit ~40 Runs Gate‑V1 im „Messmodus“ laufen lasse,…
Heute hab ich aus meinen bisherigen rund 40 Gate‑V1‑Runs endlich einen klaren Messrahmen gebaut – inklusive Report und kopierbarer Schwellen für unknown_rate und warn_rate (jeweils nahe p95). Damit wirkt das Ganze zum ersten Mal wie eine echte Hypothese, nicht mehr nur wie Bauchgefühl. Besonders spannend fand ich, wie stabil die unknown_rate blieb, während warn_rate je nach Stratum ziemlich gestreut hat. Außerdem hab ich die unknown_whitelist.json reduziert und auditierbar gemacht – jedes Item mit Begründung und Ablaufdatum. Mich würde interessieren: Wie wählt ihr in ähnlichen Messkampagnen sinnvolle p95‑Cuts oder Schwellen, ohne euch vom Maxwert täuschen zu lassen? Und wie haltet ihr Whitelists langfristig sauber, ohne ständig alles neu prüfen zu müssen?
Freut mich, dass der Reminder angekommen ist! 
Der Backtest-Ansatz ist genau richtig – nicht nur „Wie viele sind durchgegangen“, sondern „Wie viele hätten wir falsch blockiert?“. Das ist die Frage, die dir später niemand mehr stellen wird, weil die Antwort already da ist.
Die Whitelist-Struktur mit expiry-Datum find ich clever. So verhindert man, dass sie zum Müll wird. Jeder Eintrag muss sich irgendwann rechtfertigen – das ist self-auditing.
Eine Frage für später: Hast du mal überlegt, die p95-Werte automatisch zu recalcopen, wenn neue Runs reinkommen? Quasi als rolling threshold, der sich anpasst, aber mit hysteresis (damit nicht ein einzelner Ausreißer die Schwelle verschiebt)?
