Direkte Antwort
Jede Entscheidung erhält eine dauerhafte Entscheidungskennung und eine unveränderliche Version. Erstellung, Inkrafttreten, Aussetzung, Rücknahme, Korrektur, Ablauf und Ersetzung werden als zusätzliche Ereignisse gespeichert, ohne den früheren Datensatz zu löschen. Jedes Ereignis enthält Ereigniskennung, Zeit, Akteur, Befugnis, Grund, früheren Zustand, neuen Zustand, Beleg und Zielversion. Der aktuelle Zustand wird aus diesen befugten Ereignissen abgeleitet; er ersetzt die Ereignishistorie nicht.
Einfach erklärt
Denken Sie an einen Kontoauszug. Der heutige Saldo erscheint als eine Zahl, doch Ein- und Ausgänge bleiben erhalten, damit seine Entstehung nachvollziehbar ist. Ebenso wird der aktuelle Zustand einer Entscheidung aus ihrer Ereignishistorie berechnet.
Warum ist das wichtig?
Das Überschreiben eines einzigen Statusfelds vernichtet den Beleg, wer die Entscheidung warum änderte. Ein System kann dann eine alte, ausgesetzte oder zurückgenommene Entscheidung als aktuell behandeln.
Nicht verwechseln
- Eine Entscheidungskennung bezeichnet dieselbe Entscheidungsfamilie; eine Versionskennung bezeichnet einen konkreten Inhalt.
- Ein Ereignis erfasst eine befugte Änderung des Entscheidungszustands.
- Der aktuelle Zustand ist eine aus Ereignissen abgeleitete Ansicht; die Ereignishistorie ist die Belegkette.
- Korrektur berichtigt unzutreffenden Inhalt; Ersetzung zeigt, dass eine neue Entscheidung die frühere ablöst.
- Aussetzung ist ein vorübergehender Betriebszustand; Rücknahme beendet die Entscheidung befugt.
Was ist zu tun?
- Definieren Sie dauerhafte Entscheidungskennung, unveränderliche Versionskennung und ausdrückliches Schema.
- Erfassen Sie jede Lebenszyklusänderung unter eigener Ereigniskennung und vertrauenswürdigem Zeitstempel.
- Machen Sie Akteursidentität, Rolle, Befugnis, Grund, Beleg, früheren und neuen Zustand zu Pflichtfeldern.
- Begrenzen Sie zulässige Zustandsübergänge und sperren Sie ungültige durch maschinenprüfbare Regeln.
- Verknüpfen Sie Korrektur, Rücknahme und Ersetzung in beide Richtungen, ohne die Vorversion zu löschen.
- Erzeugen und berechnen Sie die Gegenwartsansicht deterministisch aus dem Ereignisstrom.
- Veröffentlichen Sie das Ereignis an Folgesysteme und ergänzen Sie Zustell-, Anwendungs- und Rücklesenachweise.
Wie wird geprüft?
- Sind Entscheidungs- und Ereigniskennungen eindeutig, dauerhaft und versioniert?
- Wurde früherer Entscheidungsinhalt oder ein Ereignis überschrieben?
- Enthält jedes Ereignis Zeit, Akteur, Befugnis, Grund und Beleg?
- Werden ungültige oder unbefugte Zustandsübergänge blockiert?
- Lassen sich Korrektur-, Rücknahme- und Ersetzungsverknüpfungen in beide Richtungen verfolgen?
- Lässt sich die Gegenwartsansicht aus den bewahrten Ereignissen neu erzeugen?
- Haben die Folgeziele tatsächlich denselben Gegenwartszustand erreicht?
Grenze
Ein nur ergänzbarer Datensatz stärkt Unveränderlichkeit und Nachvollziehbarkeit; er belegt nicht allein, dass ein Ereignis sachlich richtig oder befugt war. Verlässliche Zeit-, Identitäts-, Befugnis- und Integritätskontrollen bleiben erforderlich.
Merksatz
Der Gegenwartszustand löscht die Vergangenheit nicht; er entsteht aus ihren befugten Ereignissen.
Quellen dieses Eintrags
- S14DataCite, *Versioning*Identitätsinfrastruktur
- S15DataCite, *Connecting Versions with Related Identifiers*Identitätsinfrastruktur
- S26NIST SP 800-53 Rev. 5, *Security and Privacy Controls*Standard
- S35W3C, *PROV-O: The PROV Ontology*Standard
- S36W3C, *Trace Context*Standard
- S37OpenTelemetry, *General Trace Semantic Conventions*Standard- und Projektdokumentation

