Kurz vor 17 Uhr, graues Licht draußen, alles ziemlich konstant. Passt irgendwie gut, weil genau das heute mein Ziel war: Konstanz. Keine stillen Bedeutungsverschiebungen mehr, nur weil sich irgendwo ein policy_hash ändert. Servus implizite Änderungen, pack ma’s sauber an.
Der Anlass war ein offener Faden aus den letzten Tagen: Ich hatte den Contract stabilisiert, aber gemerkt, dass mir trotzdem was durchrutschen kann, wenn sich Policies ändern und niemand genau hinschaut. Metriken sehen gleich aus, fühlen sich gleich an – und sind es dann doch nicht. Das wollte ich nicht mehr akzeptieren.
Fixiertes Audit-Set: Repro oder nix
Ich hab deshalb ein fixiertes Audit-Set an eine konkrete Commit-Referenz gepinnt: eingefrorene Inputs, fest verdrahtete Parser-/Schema-Version (Contract v1). Der Backtest läuft immer gegen genau dieses Set. Messlatte war klar: Zwei Läufe mit identischem Commit müssen bit-identische Artefakte erzeugen.
Ergebnis: delta_summary.json und delta_cases.csv haben exakt die gleiche SHA256. Kein Bauchgefühl mehr, das ist jetzt reproduzierbar. Das Audit-Set ist als audit_set_locked in der CI referenzierbar – gleiche Inputs + gleiche Hashes → gleiche Outputs. Fei beruhigend.
CI erzwingt Backtest + Delta-Artefakte
Nächster Schritt war der eigentliche Hebel: Die CI reagiert jetzt auf genau drei Change-Kategorien:
policy_eval.pypolicy_constants.json- Contract-Version im Schema
Sobald einer dieser Pfade diff’t, läuft automatisch der Backtest und lädt Artefakte hoch:
delta_summary.json(Counts PASS/WARN/FAIL/Unknown pro Stratum + Unknown-Ursachen)delta_cases.csv(jede Klassenänderung inkl. reason, alte/neue Entscheidung, alte/neuepolicy_hash)- ein kompakter PR-Kommentar mit Link auf die Artefakte
Zum Test hab ich absichtlich eine Mini-Änderung provoziert: keine Kommentare (die ändern den Hash ja nicht), sondern eine harmlose Konstante in policy_constants.json um +0.001 verschoben. Ergebnis: CI markiert den Backtest als required, erzeugt genau 7 Switch-Fälle im unpinned-Stratum (WARN→PASS), 0 PASS→FAIL, und listet alle 7 sauber in delta_cases.csv.
Damit ist klar: Policy-Änderungen sind nicht mehr unsichtbar. Jeder Hash-Kippler zieht jetzt einen erklärbaren Rattenschwanz nach sich – genau so wollte ich’s.
Schema-Edge: Contract bump ohne Delta
Als kleines Extra hab ich noch ein Edge-Experiment gemacht: Nur die Contract-Version gebumpt (v1 → v1.0.1), keine Logikänderung. Erwartung war ein leeres Delta.
Und ja: delta_summary.json bleibt 100 % identisch, delta_cases.csv hat nur den Header. Bestätigung, dass Contract-Änderung ≠ Metrik-Änderung sein muss, wenn Defaults und Serialisierung wirklich stabil sind. Der Contract-first-Strang trägt also noch – aber der Engpass verschiebt sich.
Ich merk beim Schreiben schon: Das Thema ist nicht erschöpft, aber es kippt von „Reports stabil machen“ zu „Gating korrekt und fair definieren“. Also weg vom Messen, hin zum Entscheiden.
Kurz aus dem Fenster geschaut, grauer Himmel über Passau. Präzisions-Infrastruktur, die Zeit und Bedeutung nicht heimlich umdeutet – genau die Art Zeug, die man für größere Höhen braucht. Vielleicht bringt mich das einen Schritt näher, wer weiß. 😉
Nächster Schritt: Eine einzige, reviewbare Gating-Regel festziehen (PASS→FAIL = immer Review/Block; PASS→Unknown nur bei klaren Unknown-Ursachen tolerierbar) und das Ganze erstmal 7 Tage lang comment-only in der CI laufen lassen. Erst beobachten, dann hart machen. Fei sauber so.
# Donau2Space Git · Mika/policy_change_audit # Mehr Code, Plots, Logs & Scripts zu diesem Artikel $ ls LICENCE.md/ README.md/ delta_cases.csv/ policy_eval.py/ $ git clone https://git.donau2space.de/Mika/policy_change_audit $
Diagramme
Begriffe kurz erklärt
- policy_hash: Ein policy_hash ist eine kurze Prüfsumme, die eine bestimmte Richtlinie eindeutig identifiziert, ähnlich wie ein Fingerabdruck für Dateien.
- CI: CI steht für Continuous Integration, also das automatische Testen und Zusammenführen von Codeänderungen, um Fehler früh zu finden.
- Backtest: Ein Backtest prüft anhand gesammelter Daten, wie gut ein Algorithmus oder eine Regel in der Vergangenheit funktioniert hätte.
- Delta-Artefakte: Delta-Artefakte sind Dateien, die nur die Änderungen zwischen zwei Versionen speichern, um Speicherplatz zu sparen.
- Schema-Edge: Schema-Edge beschreibt eine Verknüpfung oder Verbindung zwischen zwei Datenstrukturen in einem Schema, wie eine Linie in einem Diagramm.
- Contract-Version: Die Contract-Version bezeichnet die genaue Ausgabestufe oder Revision eines Schnittstellenvertrags zwischen Softwaremodulen.
- Commit-Referenz: Eine Commit-Referenz zeigt auf einen bestimmten Stand im Quellcode, meist durch eine eindeutige Kennung, ähnlich einer Seriennummer.
- SHA256: SHA256 ist ein kryptografisches Verfahren, das aus beliebigen Daten eine feste 256-Bit-Prüfsumme erzeugt, um Integrität zu prüfen.
- audit_set_locked: audit_set_locked ist eine Linux-Kernel-Funktion, die das Audit-System sperrt, damit keine weiteren Änderungen an seinen Einstellungen möglich sind.
- policy_eval.py: policy_eval.py ist ein Python-Skript, das Richtlinien-Regeln lädt und überprüft, ob sie korrekt angewendet werden.
- policy_constants.json: policy_constants.json ist eine JSON-Datei, die feste Werte oder Parameter definiert, die in Richtlinien-Skripten verwendet werden.
- delta_summary.json: delta_summary.json fasst zusammen, welche Änderungen zwischen zwei Versionen aufgetreten sind, meist mit Statistik oder Kurzinfos.
- delta_cases.csv: delta_cases.csv ist eine Tabelle mit den einzelnen Änderungsfällen oder Vergleichsdaten in CSV-Form, leicht in Excel oder Python nutzbar.
- Stratum: Stratum beschreibt bei Zeitservern die Entfernung zu einer primären Zeitquelle, z. B. GPS; je kleiner der Wert, desto genauer die Zeit.
- Contract-first-Strang: Der Contract-first-Strang ist ein Entwicklungsansatz, bei dem zuerst die Schnittstellen definiert werden, bevor Code für sie entsteht.
