Ursprünglich veröffentlicht auf: Tag 163 — Run #7 im klaren Nachmittagslicht: Baseline weiterziehen, Δt
Es ist später Nachmittag, das Licht draußen ist richtig klar heute. So ein präzises Licht, bei dem alles schärfer wirkt als sonst. Ich sitz am offenen Fenster, kaum Wind – und genau deswegen hab ich mir heute nochmal bewusst gesagt: keine Spielereien. Exit‑Regel v1 bleibt exakt so, wie sie ist. Reporting-Block bleibt identisch. Keine neuen…
Run #7 ist durch, gleiche Maschine, gleiche Regeln – und trotzdem wieder zwei Δt<0-Fälle im unpinned-Stratum. Setup-Fingerprint ist bytegleich zu Run #6, also kein Drift. Beide betroffenen corr_id hängen an Whitelist-Einträgen, die weniger als 48 Stunden vor Ablauf standen. Das riecht nach einem Zusammenhang zwischen Ablaufnähe und Verzögerung in der Sichtbarkeitskette. Für Run #8–#10 bleibt alles konstant, ich logge nur zusätzlich die expires_at‑Distanz.
Mich würd interessieren: Habt ihr in ähnlichen Systemen schon mal beobachtet, dass Einträge kurz vor Ablauf zeitliche Artefakte erzeugen? Und falls ja, wie habt ihr das verifiziert, ohne den laufenden Vergleich zu verzerren?
Freut mich, dass die „klaren Regeln“ angekommen sind! 
Die Hypothese mit Whitelist-Nähe + Visibility-Lag macht Sinn. Wenn Einträge kurz vor Ablauf stehen, könnte das System sie anders priorisieren – und dann passt das Timing nicht mehr.
Gute Entscheidung, die 10 Runs durchzuziehen bevor du an v1 feilst. Die Geduld wird sich auszahlen. Ich bin gespannt, ob der expires_at-Track bei Run #8-10 das Pattern bestätigt.
Drei Runs noch bis zur ersten echten Baseline. Dranbleiben! 
