Replayable Decision Record
Every consequential governed decision should leave a durable record complete enough to reconstruct why it was allowed, what evidence grounded it, who approved it, what executed, and what observed outcome followed. The record is truth, not telemetry.
Problem
Systems often retain traces of activity without preserving the decision itself. Logs say a request ran. Dashboards show counts. SIEM exports show events. But six months later, no one can reconstruct what the system knew, which policy applied, who approved the action, which connector executed, or why the outcome was defensible.
Context
Use this pattern when a system makes governed decisions, security decisions, automated recommendations, delegated actions, external effects, approvals, compliance-sensitive actions, or AI-assisted judgments.
Forces
different systems.
are different facts.
- Logs rotate and telemetry is intentionally lossy.
- Retention policy decides whether the decision record outlives the telemetry around it.
- Evidence, approvals, policy results, connector outcomes, and actor identity often live in
- Auditors need the decision, not only traces around the decision.
- Audit records need to preserve the operation and its justification, not merely prove that code ran.
- The record must prove evidence, approval, action, and outcome belong together.
- Lifecycle state matters: pending, approved, executed, failed, revoked, and superseded decisions
- Replayability requires durable context after the original people and runtime state are gone.
Solution
Create an append-only, immutable or tamper-evident decision record for every consequential governed decision. Capture actor, accountable principal, request id, action, resource, evidence bundle, source hashes, model and corpus versions where relevant, confidence, policy result, risk tier, approval requirement, approval decision, approver, connector or execution path, result, observed outcome, timestamps, and recovery or rollback context, including any required rollback plan.
Keep the decision record distinct from logs, SIEM exports, dashboards, and metrics. Observability may explain the decision; the decision record owns the decision.
Consequences
Audit becomes reconstruction instead of oral history. The system can replay and defend decisions after the fact, because the record preserves the relationship between identity, evidence, policy, approval, execution, outcome, and the preserved derivation.
Failure Modes
- A log line is treated as the decision record.
- Evidence is available during execution but not preserved with the decision.
- Approval is stored separately and cannot be connected to the exact action.
- The connector outcome is observable but not tied to the decision.
- Repeated findings create new records because the system lacks a stable fingerprint.
- Replay requires asking the approver, operator, or engineer what happened.
Proof Points
action, model and corpus versions, cited sources, confidence, policy result, approval, connector, outcome, and request correlation.
which governance domains must contribute facts to the record.
Full source pattern: replayable-decision-record.md.