Why audit trails matter
AI systems change production faster than humans can track. Without a complete audit trail, incident response turns into guesswork. An audit trail is also the foundation for compliance and trust.
What to record
- - Job and run identifiers with timestamps.
- - Policy decision and decision reason.
- - Policy snapshot hash and approval event details.
- - Constraints applied during execution.
- - Result pointers and status transitions.
Append-only timeline
The audit trail must be append-only. If entries can be modified, trust collapses. A single timeline with immutable events keeps evidence consistent.
Audit entry example
Every decision should capture the policy snapshot, the reason, and the constraints that were enforced.
{
"run_id": "run_8f9a",
"event": "policy_decision",
"timestamp": "2026-01-21T15:22:09Z",
"decision": "REQUIRE_APPROVAL",
"reason": "prod write requires approval",
"policy_snapshot": "7f3d...9c2b",
"constraints": {
"max_lines_changed": 500
}
}Audit queries that matter
- - Which runs touched production in the last 24 hours?
- - Which policy snapshot approved a given run?
- - Who approved a risky change and what constraints applied?
GET /api/v1/runs/run_8f9a/timeline
200 OK
{
"run_id": "run_8f9a",
"events": [
{ "event": "run_started", "timestamp": "2026-01-21T15:21:40Z" },
{ "event": "policy_decision", "decision": "REQUIRE_APPROVAL" },
{ "event": "approval_granted", "approver": "secops@cordum.io" },
{ "event": "step_completed", "step_id": "remediate" }
]
}How Cordum records runs
Cordum records an append-only run timeline with policy decisions, approvals, and results. The timeline is tied to the workflow engine and is queryable for audit and compliance.
When auditors ask, "Who approved this change and under what policy?", the answer is already in the timeline.
See the workflow engine docs for the run model.