Decision Logging

Kurzzusammenfassung

• Decision Logging definiert den verbindlichen Mindestdatensatz für nachvollziehbare Fach- und Betriebsentscheidungen.
• Logs sind unveränderbar, revisionssicher gespeichert und mit klarer Retention-Regel versehen.
• Ein expliziter Endzustand mit SLA bis EndEvent_DecisionLogged schliesst den Traceability-Nachweis.
• Ohne vollständigen Log-Eintrag gilt eine Entscheidung prozessual als nicht abgeschlossen.

Ziel

Business-Nutzen: Einheitliches Decision Logging reduziert Audit-Risiko, verkürzt Nachweiszeiten und schafft eine belastbare Entscheidungsbasis für Governance, Risk und Betrieb.

Mindestschema für Decision Records (verbindlich)

Feld	Pflicht	Beschreibung
decision_id	ja	Eindeutige ID des Entscheidungsereignisses
decision_timestamp_utc	ja	UTC-Zeitpunkt der finalen Entscheidung
decision_outcome	ja	z. B. accept, reject, override, retrain, rollback
decision_rationale	ja	Fachliche/technische Begründung (frei + codiert)
severity_or_risk_class	ja	Risiko-/Severity-Einstufung zum Entscheidungszeitpunkt
model_version_ref	ja	Referenz auf Modellversion/Artifact
feature_set_ref	ja	Referenz auf Feature-Set oder Data Snapshot
run_ref	ja	Referenz auf mlflow_run_id/prefect_flow_run_id o. ä.
actor_role	ja	Rolle des Entscheiders (z. B. PM, MLOps, Risk)
approver_ref	bedingt	Pflicht bei Override/Exception
evidence_links	ja	Dashboard, Ticket, Report, Incident-ID
record_hash	ja	Integritätsnachweis des geschriebenen Datensatzes

Unveränderbarkeit und Integrität

• Decision Records werden als append-only gespeichert; Updates erfolgen ausschliesslich als neuer Korrektur-/Folgedatensatz mit Verweis auf decision_id.
• Jeder Datensatz enthält einen Hash (record_hash) und Write-Audit-Metadaten (Writer, Zeit, Source-System).
• Löschungen sind im Primärspeicher unzulässig; Korrekturen erfolgen nachvollziehbar über Versionierung.

Retention (Mindeststandard)

Datentyp	Aufbewahrung	Begründung
Decision Record inkl. Rationale	7 Jahre	Audit- und Governance-Nachweis
Verlinkte Evidenz (Tickets/Reports)	mindestens 3 Jahre oder synchron zur Policy des Quellsystems	Reproduzierbarkeit der Entscheidungsgrundlage
Integritätsnachweise (Hash/Audit-Meta)	7 Jahre	Nachweis der Unveränderbarkeit

SLA bis EndEvent_DecisionLogged

• SLA-Definition: Zwischen fachlicher Entscheidung (Decision Captured) und erreichtem Endzustand EndEvent_DecisionLogged dürfen maximal 15 Minuten liegen.
• SLA-Messpunkt Start: decision_timestamp_utc (fachlicher Entscheid steht fest).
• SLA-Messpunkt Ende: persistierter, validierter und unveränderbarer Decision Record mit bestätigtem record_hash.
• SLA-Verstoss: automatische SEV-2-Meldung an Risk Ops + Platform Ops, inklusive Incident-Ticket.

Endzustand (Matrix-Gap geschlossen)

EndEvent_DecisionLogged gilt nur als erreicht, wenn alle Bedingungen erfüllt sind:

1. Pflichtfelder des Mindestschemas sind vollständig validiert.
2. Record wurde unveränderbar gespeichert (append-only + Integritätsnachweis).
3. Referenzierbare Evidence-Links sind auflösbar.
4. SLA (≤ 15 Minuten) ist eingehalten oder als Verstoss dokumentiert eskaliert.

Damit ist der bisherige Matrix-Gap für den Endknoten prozessual geschlossen: Der Endzustand ist explizit definiert, messbar und auditierbar.

Kontrollen

Governance- und Risiko-Aspekte

• Ohne vollständigen, unveränderbaren Decision Record ist keine finale Prozessschliessung zulässig.
• SLA-Verstösse bis EndEvent_DecisionLogged sind meldepflichtig und im Monatsreport auszuweisen.
• Retention und Integritätsnachweise werden quartalsweise stichprobenartig geprüft.

Operative Checks

Check	Monitoring	Verantwortlich	Eskalation
Vollständigkeit Mindestschema	je Decision Event automatisiert	Platform Ops	Risk Ops
Integritätsprüfung (record_hash)	je Write + täglicher Konsistenzjob	Platform Ops + Security	Incident Commander
SLA bis EndEvent eingehalten	kontinuierlich, täglicher SLA-Report	Risk Operations	Governance Board

Entscheidung

• Decision Record erfüllt das Mindestschema vollständig.
• Unveränderbarkeit, Integrität und Retention sind systemseitig sichergestellt.
• EndEvent_DecisionLogged wurde innerhalb SLA erreicht (oder Verstoss eskaliert).

BPMN-Detailansicht

⋮⋮⋮

BPMN-Kontext

• IDs: ServiceTask_LogDecision, EndEvent_DecisionLogged
• Input-Bezug: Entscheidungsereignis inkl. Rationale, Risikoeinstufung und Evidenzreferenzen.
• Entscheidungsbezug: Validierung auf Pflichtschema, Integrität und SLA-Konformität.
• Output-Bezug: Unveränderbarer Decision Record und expliziter Prozessabschluss im Endevent.