Action Provenance: The Runtime as the Audit Trail

There's a pattern we keep running into in autonomous systems built by teams who took auditability seriously from the start: a real-time execution engine doing the actual work, and beside it, a separate audit log — sometimes a database table, sometimes a whole logging service — that a piece of application code writes to whenever someone remembered to add the write call. The two are supposed to describe the same reality. In practice they drift apart within months, because the audit log is a second system that has to be kept in sync by hand, and hand-kept things fall out of sync in exactly the moments they're needed most — during an incident, when the engineer patching the bug under pressure forgets the audit write, or during a refactor, when the code path that used to log an action gets restructured and the logging call quietly doesn't make it into the new version.

The fix is not a better process for keeping the two systems aligned. It's not having two systems.

The runtime already knows what happened

An autonomous system's own execution trace — what it evaluated, what it decided, what action it took, what the result was — is a more complete and more trustworthy record of what actually happened than any log a human or a side-channel process constructs afterward, for a simple reason: it's generated by the same code path that performed the action, at the moment it performed it, rather than reconstructed or summarized by a separate piece of logic that has to correctly infer what to record. Treating that execution trace as the primary audit artifact — rather than as internal debugging data that a separate compliance log is built to summarize — means the audit trail is exactly as complete as the system's actual behavior, because it is the system's actual behavior, not someone's description of it.

This requires taking the trace seriously as a durable artifact rather than an ephemeral debugging convenience, which is where most teams' instincts run the wrong way. Application logs get truncated, rotated, and sampled down under storage pressure, because they're treated as operationally useful but not load-bearing. An action-provenance record can't be sampled — a system that logs 10% of its autonomous actions for cost reasons has, for audit purposes, no record of the other 90%, and "we sample our logs" is a materially different, weaker claim than "we have a complete record," even if it's fine for debugging latency.

What has to be true for the runtime log to actually serve as the record

It has to capture the decision, not just the action. A log entry that says "transferred case #4471 to review queue" is an action record. One that also carries the evidence the system evaluated, the policy version active at the time, and the specific rule or model output that triggered the transfer is a provenance record — and the difference is exactly the difference between "we know what happened" and "we know why." We've written elsewhere about instrumenting individual decisions as spans for this reason; provenance is the retention and integrity half of that same practice.

It has to be tamper-evident, not just append-only by convention. An audit trail that a sufficiently privileged engineer can quietly edit isn't actually serving as an audit trail, whatever its intent. Cryptographic hash-chaining of the log — each entry's hash incorporating the previous entry's hash — is a well-understood, unglamorous technique that turns "we don't typically edit this" into "an edit would be detectable," and it costs very little to add if it's designed in from the start rather than retrofitted onto a log format that wasn't built for it.

It has to survive the system it describes. Retention policy has to be a deliberate decision tied to the actual regulatory or contractual retention requirement, not an artifact of however long the database happens to keep rows before a cleanup job deletes them. We've seen provenance data that would have answered a contested-decision question perfectly well, except it aged out of a database with a 90-day retention default nobody had reviewed against a five-year regulatory requirement.

The organizational shift this actually requires

The hardest part of this isn't technical. It's convincing a compliance function that the engineering team's execution logs — not a separate system compliance owns and controls — are the audit trail of record. That's a real transfer of ownership, and it's uncomfortable for a compliance team that's used to being the one who defines and controls the record. It's worth the discomfort, because the alternative — a parallel, hand-maintained log that's structurally guaranteed to drift from what the system actually did — isn't actually safer for anyone, including compliance. It just delays the moment the gap gets discovered from a routine audit to a contested case, which is the worst possible time to find out the record and reality don't match.