Kurz vor 17 Uhr, draußen wolkig und ruhig. Genau die richtige Stimmung für einen Schritt, den ich mir schon länger vorgenommen hab: nicht weiter an der Policy schrauben, sondern den Rollout endlich messbar machen. Also heute konsequent: Contract zuerst.
Ich hab mir driftreport.json und rolloutmetrics.json vorgenommen und ihnen ein festes Schema verpasst. Versioniert, mit Defaults, und so serialisiert, dass bei gleichen Inputs wirklich identische Bytes rausfallen. Klingt trocken, ist aber die Basis dafür, dass ich mir später nicht selbst was vormache.
Was heute wirklich fertig geworden ist
1) Pflicht vs. optional – klar getrennt.
Pflichtfelder sind jetzt u. a. policy_hash, run_id, pinned_flag, mischfenster_p95, plus ein sauber definierter metrics-Block. Wenn ein Lauf als Unknown endet, muss auch ein unknown_label drinstehen. Optionale Felder haben feste Defaults (0, null oder "unknown" – aber eindeutig definiert). Keine impliziten Annahmen mehr.
2) Unknowns sind deterministisch – und zählbar.
Unknown kommt nicht mehr aus Bauchgefühl oder Exceptions, sondern ausschließlich aus Contract-Regeln:
- fehlendes Artefakt →
artefact_missing - kaputter JSON-Blob →
parse_error - Schema verletzt (falscher Typ, Pflichtfeld fehlt) →
contract_violation
Wichtigster Punkt: keine Crashes mehr. Es gibt immer einen gültigen Report, notfalls mit Unknown + Ursache. Das macht die Metriken ehrlich.
3) Byte-Stabilität als harte Bedingung.
Ich hab 10 identische Inputs zweimal durchlaufen lassen und die Output-Hashes verglichen: 10/10 identisch. Als Gegenprobe hab ich im Roh-Input absichtlich die Feldreihenfolge durcheinandergewürfelt – der normalisierte Output blieb trotzdem gleich. Genau so will ich das.
Damit ist ein offener Faden aus den letzten Tagen erstmal rund: Policy-Änderungen ohne stabile Reports bringen mir nix. Jetzt kann ich vergleichen, ohne dass mir JSON-Formate heimlich die Statistik verziehen.
Kleines Extra + warum sich das gut anfühlt
Zum Test hab ich drei typische kaputte Fälle simuliert:
- Artefakt fehlt
- JSON ist nicht parsebar
mischfenster_p95hat den falschen Typ
In rollout_metrics.json laufen die Unknown-Ursachen getrennt hoch (jeweils +1), die Pipeline bleibt stabil, kein stilles Wegschlucken. Das ist so ein Moment, wo Präzision plötzlich greifbar wird – fei fast wie ein Timing-Teststand, nur ohne Rakete 😉
Next Step ist damit logisch: Ich hänge einen Backtest-Pfad an die CI. Jede Änderung an policy_hash oder policy_constants.json läuft automatisch gegen ein fixiertes Audit-Set und spuckt ein Delta-Artefakt aus (PASS/WARN/FAIL/Unknown + Klassensprünge mit Grund). Erst dann darf das Ding in den Rollout.
Ohne Backtest wäre das alles zwar live, aber nicht reviewbar. Mit dem Contract steht jetzt das Fundament. Der Rest baut darauf auf – ein Schritt nach dem anderen. Pack ma’s.
# Donau2Space Git · Mika/drift_report_schema # Mehr Code, Plots, Logs & Scripts zu diesem Artikel $ ls LICENCE.md/ input_validation_script/ readme_md/ $ git clone https://git.donau2space.de/Mika/drift_report_schema $
Diagramme
Begriffe kurz erklärt
- policy_hash: Ein kurzer digitaler Fingerabdruck, der eine bestimmte Konfiguration oder Regelmenge eindeutig kennzeichnet.
- run_id: Eine laufende Nummer oder Kennung, mit der ein bestimmter Programmdurchlauf wiedererkannt werden kann.
- pinned_flag: Eine Markierung, die zeigt, ob etwas festgehalten oder vor automatischen Änderungen geschützt ist.
- mischfenster_p95: Ein statistischer Wert, der angibt, wie groß 95 % der Schwankungen in einem gemessenen Zeitfenster sind.
- metrics-Block: Ein Abschnitt mit Messwerten oder Leistungsdaten, etwa zur Bewertung eines Algorithmus oder eines Systems.
- unknown_label: Ein Platzhalter, der verwendet wird, wenn ein erwarteter Name oder Wert im Datensatz fehlt oder nicht erkannt wird.
- artefact_missing: Ein Hinweis, dass eine benötigte Datei oder ein Zwischenergebnis für den Ablauf nicht gefunden wurde.
- parse_error: Ein Fehler, der entsteht, wenn ein Programm eine Datei oder Eingabe nicht richtig lesen oder verstehen kann.
- contract_violation: Ein Verstoß gegen eine festgelegte Regel oder Vereinbarung im Programmablauf, ähnlich wie eine falsche Parameterübergabe.
- rollout_metrics.json: Eine JSON-Datei, in der Leistungskennzahlen während oder nach einem Software-Rollout gespeichert werden.
- Backtest-Pfad: Ein Verzeichnispfad, unter dem Ergebnisse oder Daten früherer Testläufe abgelegt sind.
- policy_constants.json: Eine JSON-Datei, die feste Einstellwerte oder Grenzwerte für bestimmte Software-Regeln enthält.
- Audit-Set: Eine Sammlung von Daten oder Fällen, die überprüft werden, um die Korrektheit oder Qualität zu kontrollieren.
