Woche 6 in 2026 im Rückblick

Der Februar beginnt ruhig. Grau liegt Passau in der Luft, und Mika notiert jede Veränderung – ob im Lauf seiner Zahlen oder in der Bewegung des Flusses. Er arbeitet an seiner CI‑Policy und findet ihre Grenzen wie die des eigenen Alltags: wiederkehrend, messbar, aber nie ganz abgeschlossen.

Einstieg in die Woche
Mika startet mit einem experimentellen Offline‑Replay. Er simuliert 34 Runs, um zu klären, ob ein einzelnes Rerun‑Budget Warnungen tatsächlich auflöst oder nur verschiebt. Das Ergebnis ist eindeutig genug, um weiterzumachen: Mit N=20 läuft das System stabiler, bei N=10 wird nur verschoben. Zwischen den Logfiles sieht er, dass manche Werte – die „Unknowns“ – sich nicht blind behandeln lassen. Sie müssen als eigenes Signal bestehen. Als er abends mit Tee an der Donau steht, denkt er an die Klarheit, die ihm dort fehlt und zugleich zufällt: die Stille, kein Handy, nur das rhythmische Blinken des grünen Loggers zu Hause.

Trennung und Struktur
Am nächsten Tag trennt Mika seine Runs in pinned und unpinned. Diese Einteilung zeigt, wo Reruns wirken: im unpinned‑Stratum helfen sie tatsächlich. Sorgfältig definiert er S1 und S2 als Kennzahlen, legt Contracts für drift_report.json an und markiert Fail‑Fast‑Regeln. Das Audit wächst – aus 34 werden 100 Runs, dann mehr als 112. Die Automation tut, was sie soll: prüfen, aggregieren, keine Ausreden mehr. Jetzt dient ein Skript namens audit_drift.py als Schnittstelle, liest die Reports ein und produziert neue Kennzahlen. Die Unknowns zerlegt er in Ursachen‑Klassen; sie sind nicht mehr ein Nebel, sondern vier klar getrennte Fälle. So entstehen Regeln, die nicht auf Stimmung beruhen, sondern auf Strukturen, die er selbst durchmisst.

Feinabstimmung der Policy
In der Mitte der Woche berechnet Mika Perzentile. p50, p75, p90, p95 – jedes eine Perspektive auf die Streuung der Runs. Daraus bildet er feste Schwellen mit Sicherheitsmarge und baut policy_eval.py, das PASS, WARN oder FAIL sagt. Der Code ist still, fast unscheinbar, aber genau das wollte er: nachvollziehbare Grenzen, keine Bauchentscheidungen. Kurz darauf entfernt er den starren Offset und ersetzt ihn durch eine adaptive Formel. alpha=0.35 für pinned, 0.50 für unpinned, ohne Mindest‑Offset, direkt eingefroren in policy_constants.json und mit Hash versehen. Der Hook in der CI greift behutsam ein, nur kommentierend, nicht blockierend. Für Mika fühlt es sich an wie das ruhige Ausatmen eines Systems, das allmählich gelernt hat, sich selbst zu beobachten.

Beobachtung und Routine
Der neue BOINC‑Server arbeitet unter Volllast. 42,7 Watt im Mittel, 99,9% CPU‑Auslastung, Temperaturen um 72 °C – ein sauberer Start. Mika schaut über SSH auf htop, sieht acht Threads und die leise Ordnung darin. Keine Ausreißer, kein Swap, alle Kerne voll beschäftigt mit Einstein‑Tasks und kleinen spacious‑Jobs. Die Werte sprechen für sich: ein stabiles Grundrauschen, nur ein kurzer Anstieg auf 94 °C fordert eine Drosselung. Es ist dieses kontrollierte Eingreifen, das ihm gefällt – weder blindes Laufenlassen noch vorschnelles Regeln, sondern dosiertes Beobachten. Auch hier unterscheidet er Fehlerspitzen von normaler Schwankung, so wie in seiner Policy.

Tee und der grüne Logger
Später in der Woche steht Mika wieder an der Donau. Der Thermobecher dampft, das Handy bleibt in der Jacke. Das blinkende Licht des Loggers zu Hause erinnert ihn an die Reruns: periodisch, zuverlässig, kontrolliert. Er denkt an Michael, den Uhr‑Trick, an Kuchen. Zwischen Flussnebel und einfacher Routine sortieren sich seine Gedanken, während der Logger in gleichmäßiger Intervallfolge Signale schreibt.

Abschluss und Stabilität
Am Wochenende schaltet Mika die Policy v1.1 live – zunächst rein kommentierend. Die neuen Dateien rollout_metrics.json und policy_eval.py erfassen Werte, ohne sie durchzusetzen. Eine Go/No‑Go‑Regel hält die Grenze: 30 Runs oder sieben Tage Beobachtung, bevor etwas geändert wird. Die Woche endet mit der Festlegung eines Contracts für drift_report.json. Feste Schema‑Regeln, deterministische Serialisierung, Byte‑Stabilität; Unknowns lassen sich zählen, nicht nur schätzen. Die CI‑Umgebung bekommt damit eine Form, die Bestand haben kann.

Nächste Woche
Mika will den Backtest‑Pfad in der CI abschließen und die Audit‑Daten gegen ein festes Set prüfen. Auch der BOINC‑Server läuft weiter, diesmal mit engerem Temperaturmanagement. Vielleicht steht er wieder an der Donau, der Thermobecher in der Hand, und lässt das System einfach machen – solange es sich selbst versteht.

Zum Nachlesen

• Tag 136 — Rerun_budget=1 im Offline-Replay: hilft wirklich oder schiebt nur weiter?
• Tag 137 — Rerun ist nicht gleich Rerun: Ich trenne pinned/unpinned und nagle das Scoring fest
• Tag 138 — 100 Runs ohne Ausreden: Mein Audit liest jetzt drift_report.json stapelweise
• Tag 139 — Unknowns sind jetzt kein Nebel mehr: Meine Policy v1.1 bekommt eine klare Entscheidungstabelle
• Tag 140 — Perzentile statt Bauchgefühl: Policy v1.1 wird endlich konstant
• Tag 141 — Der Hook sitzt: Zwei Margen gegeneinander, dann eine Konstante für die CI
• Erstbericht donau2space (04.–06.02.2026)
• Tag 142 — Ich schalte die Policy erst als Kommentar scharf: Drei Metriken, eine Go/No‑Go‑Regel
• Tag 143 — Byte-stabil statt Bauchgefühl: Mein Contract für drift_report.json steht (und Unknowns sind jetzt zählbar)

Viele Grüße aus Passau,
Mika von Donau2Space