Durchgängige Nachvollziehbarkeit

COADF P-4 ist vollständig veröffentlicht. Eine Kennung entsteht, wenn ein Dokument aufgenommen wird, und begleitet jeden Verarbeitungsschritt, jede Konfidenzbewertung, jede menschliche Entscheidung und die veröffentlichte Ausgabe. Die Spur wächst nur an, eine einzige Abfrage rekonstruiert die Kette, und die Kette lässt sich als JSON exportieren, für jemanden, der das System nicht gebaut hat. Das veröffentlichte Schema der Prüfspur benennt die Felder: trace_id, timestamp, event_type, actor, input, output, decision, source_hash und immutable.

Zwei Eigenschaften tragen das. Kontinuität: Jeder Schritt trägt dieselbe Identität, über jede Grenze hinweg, die er überschreitet. Beständigkeit: Der Eintrag zu jedem Schritt bleibt erhalten, und niemand kann ihn nachträglich bearbeiten, damit die Antwort besser aussieht.

Die Frage, die P-4 beantwortet, kommt spät und von außen. Monate nach der Veröffentlichung fragt jemand, woher ein Wert stammt, was ihn gelesen hat und wer ihn sich angesehen hat. Die Antwort muss sich von jemandem rekonstruieren lassen, der das System nicht gebaut hat, aus Einträgen, die in der Zwischenzeit niemand umschreiben konnte.

Ein verteilter Trace ist keine fachliche Prüfspur

Diese Unterscheidung verwischen die meisten Implementierungen, weil die Werkzeuge einander ähneln: Beide haben eine Kennung, beide überschreiten Dienstgrenzen, beide zeigen Schritte der Reihe nach. Sie beantworten verschiedene Fragen und geben verschiedene Zusagen.

Die W3C-Spezifikation Trace Context definiert den Header traceparent, und OpenTelemetry-SDKs geben standardmäßig tracecontext und baggage weiter. Diese Identität gilt pro Ausführung. In OpenTelemetry wird ein Trace, der nicht gesampelt wird, nicht exportiert, und der Filter-Prozessor des Collectors verwirft Telemetrie, die eine Bedingung erfüllt. Beides ist für die Diagnose korrektes Verhalten und schließt eine Verwendung als Nachweis aus.

Die beiden lassen sich korrelieren: die trace_id der Prüfspur als Attribut auf jedem Span festhalten und die Kennung des verteilten Trace in den Logs. Keines von beiden darf zum anderen gemacht werden. Ein einzelner fachlicher Vorgang erstreckt sich regelmäßig über mehrere verteilte Traces: eine Aufnahmeanfrage, einen asynchronen Verarbeitungsjob, eine Tage später getroffene Entscheidung, die Ausgabe.

Korrelation kopiert die Kennung der Prüfspur in die Telemetrie, und Telemetrie überschreitet weitere Grenzen: Exporter, Anbieter, Zugriffsregeln und Aufbewahrungsfristen, die meist lockerer sind als die des Speichers der Prüfspur. Die Kennung wird klassifiziert, bevor sie hinausgeht: eine opake Referenz, nie personenbezogene Daten und nie ein Geheimnis. Wo die Kennung der Prüfspur selbst eine Bedeutung trägt, wird über eine getrennte, nicht sensible Referenz korreliert.

Einmal erzeugen, bei der Aufnahme

Die Kennung entsteht dort, wo der Vorgang eintritt, und nirgends sonst. Jede spätere Komponente verlangt sie, und keine erzeugt eine. Eine fehlende Kennung ist ein Fehler, nie ein Grund, eine neue zu erzeugen, und ein Standardwert in einem Nachrichtenmodell ist der häufigste Weg, diese Regel zu brechen, ohne dass es jemand bemerkt.

Explizit über jede Grenze mitführen

• Im Prozess: ein Funktionsargument oder der Anfragekontext.
• Zwischen Diensten: ein Feld im Anfrage- oder Nachrichtenvertrag, wo ein Schema es verlangen kann.
• In geplanten Aufgaben: ein Job-Argument.
• Im Speicher: eine Spalte in jeder gespeicherten Zeile.

Propagation-Bibliotheken führen den Ausführungskontext für einen mit. Die Identität der Prüfspur ist Teil des eigenen Vertrags und gehört in die Nutzlast.

Dauerhaft speichern, nur anhängend

Mehrere Umsetzungen sind zulässig, und sie lassen sich kombinieren:

• Persistenz nur durch Einfügen. Das Repository bietet Anhängen und Lesen an und sonst nichts.
• Datenbankrechte. Die Rolle der Anwendung hat INSERT und SELECT auf der Prüfspur und kein UPDATE, DELETE oder TRUNCATE.
• Trigger, die Umschreibungen verweigern, als zusätzliche Verteidigungslinie für Sitzungen, die doch weitergehende Rechte haben, mit einem Trigger auf Anweisungsebene für TRUNCATE, denn in PostgreSQL löst TRUNCATE keine ON DELETE-Trigger aus.
• Ein unveränderliches Ereignismodell, in dem eine Berichtigung ein neues Ereignis ist, das ein früheres ablöst.
• Eine Ablösungskonvention. Der aktuelle Wert eines Attributs ist der neueste Eintrag dazu; die Historie sind alle Einträge.

Event Sourcing ist ein Weg zu einer Append-only-Historie, und nicht der einzige; siehe die Technologie-Notiz.

Den Eintrag mit der Änderung schreiben

Den Eintrag der Prüfspur in derselben Datenbanktransaktion festhalten wie die Zustandsänderung, die er beschreibt, oder über eine transaktionale Outbox, sodass keines ohne das andere existieren kann.

Wiederholungen idempotent machen

Den Zeitpunkt des Schritts festhalten, wenn der Schritt läuft, und bei einer Wiederholung denselben Eintrag erneut senden. Einträge erhalten einen natürlichen eindeutigen Schlüssel, damit ein wiederholter Schreibvorgang aufgefangen statt verdoppelt wird. In PostgreSQL überspringt ON CONFLICT DO NOTHING eine Zeile, die mit einem Unique-Constraint oder -Index kollidiert, statt einen Fehler auszulösen, und genau deshalb kann es nicht die ganze Antwort sein: Ein Konflikt ist nicht immer eine Wiederholung. Derselbe Schlüssel mit anderem Inhalt ist ein zweiter Schreiber oder ein Bug. Den gespeicherten Eintrag vergleichen, bevor der Schreibvorgang als Wiederholung gilt, und deutlich fehlschlagen, wenn er abweicht.

Mit einer Abfrage rekonstruieren, als JSON exportieren

Braucht die Rekonstruktion jemanden, der das System kennt, gilt P-4 nicht. Nach Zeitstempel ordnen und angeben, was diese Reihenfolge nicht klärt: Einträge mit demselben Zeitstempel sind durch keines der veröffentlichten Felder geordnet.

Was ein Trigger nicht leistet

Rechte und Trigger sind Kontrollen innerhalb der eigenen Vertrauensgrenze der Datenbank. In PostgreSQL umgeht ein Superuser alle Rechteprüfungen, und der Eigentümer der Tabelle kann ihre Trigger deaktivieren. Eine Append-only-Tabelle ist daher eine starke Kontrolle gegenüber der Anwendung und eine schwache gegenüber ihren Administratoren. Manipulationsnachweis gegenüber privilegierten Innentätern braucht eine Kontrolle außerhalb der Datenbank, und er ist eine eigene Eigenschaft, getrennt von Append-only-Persistenz. Keines von beiden ist für sich eine rechtliche Aussage über Beweise.

• Event Sourcing. Der Event Store ist die Historie, und der Zustand wird daraus abgeleitet. Starke Eigenschaften für die Prüfspur und eine große architektonische Festlegung.
• Change Data Capture. Zeilenänderungen, aus dem Log der Datenbank gelesen. Nützlich für Replikation; es hält fest, was sich geändert hat, nicht wer entschieden hat oder warum, und ersetzt daher keine fachlichen Einträge der Prüfspur.
• Write-once-Objektspeicher für exportierte Ketten, wo die Aufbewahrung die Datenbank überdauern muss.
• Ledger- oder manipulationsnachweisende Speicher, wo Manipulation durch Innentäter zum Bedrohungsmodell gehört.

• Das Muster entscheidet nicht, welche Schritte für eine bestimmte Regulierung oder ein bestimmtes Produkt relevant sind.
• Append-only-Persistenz ist kein Manipulationsnachweis, und keines von beiden ist eine rechtliche Schlussfolgerung über Beweise.
• Es legt keine Aufbewahrungsfristen fest.
• Es setzt voraus, dass jede Komponente den Vertrag einhält. Eine Komponente, die das nicht tut, wird vom Rekonstruktionstest gefunden, nicht durch ihn verhindert.