Auditable

The property

Auditable asks whether people can reconstruct decisions and outcomes. Not immediately, by asking whoever was involved, but months later, from records, by someone who was not there.

It is the property with the most asymmetric cost profile in the openness test. Building it costs a modest amount of ongoing discipline. Not having it costs nothing at all until the day it costs a great deal, and on that day it cannot be acquired.

How it differs from inspectable

The two overlap in the recording and differ in almost everything else, and conflating them produces systems that are debuggable and not accountable.

A system can have excellent traces with a seven-day retention and be entirely unauditable. That combination is common, and it looks fine until the first question arrives about something from last quarter.

The questions an audit answers

Designing for auditability is easier when you know what will be asked. The questions are predictable.

• What did this agent do? The complete sequence, not a summary.
• On whose behalf? Which person or process requested it, and under whose authority it ran.
• What was it permitted to do? The authority in force at that moment, not the current one.
• Who approved the parts that required approval? And what exactly did they see when they approved?
• Where did this number come from? Which source, which version of it.
• Why did it decide that? What was in front of the model when it chose.
• What changed as a result? Which systems, which records.
• Has this happened before? Which requires records that span more than one incident.

Every one of these has to be answerable from records made at the time. None can be reconstructed by asking the system to explain itself afterwards, because a model asked to explain a past decision produces a plausible rationalization rather than a record.

What has to be recorded

The list is longer than typical logging and each item earns its place by mapping onto one of the questions above.

• The request and the requester. What was asked, by whom, through which channel.
• The identity and authority in force. Which agent, which profile revision, which permissions. Recording the revision matters because permissions change.
• Every step. Context sent, tool called, arguments, result, including failures.
• Model and version per call. So behavior can be attributed when a provider changes something.
• Data provenance. Which tables, which snapshots, which queries. Snapshot identifiers turn a claim into something reproducible.
• Approvals. What was proposed, what was displayed, who decided, when, bound to that specific action.
• Changes made. What was written where, ideally with a way to identify the resulting records.
• Termination reason. Completed, limit reached, denied, cancelled, errored.
• Artifacts produced. With a checksum, so a document found later can be tied back to the run that made it.

Audit is a delivery problem

Treating audit as logging is the most common way it fails quietly, and the distinction is worth being precise about.

A log is written locally. It is lost when the machine is, ignored when nobody aggregates it, and truncated when a process exits unexpectedly. None of those failures announce themselves.

An audit record has to arrive somewhere durable, which makes it a delivery problem with the properties delivery problems have: buffering, retry, backpressure, and verification. A pipeline that stopped working three weeks ago is worse than none at all, because it produces confidence without coverage.

The practical requirements follow directly. Bounded buffering, so a delivery outage does not consume the machine. Retry, so a transient failure does not lose records. Diagnostics, so someone can check that delivery is healthy. And an explicit flush, so a shutting-down process does not discard what it has not yet sent.

Provenance and artifacts

Traces record what an agent did. Provenance connects what an agent did to the thing that resulted, and it is the direction the question is usually asked from.

Generated artifacts leave the system. A document produced by an agent gets emailed, filed, and cited. Six months later someone is looking at that document and wants to know where it came from. A trace does not help unless something connects the two.

A provenance record bound by checksum closes that loop. Given the artifact, you can identify the run that produced it, the sources it drew on, and the approvals that preceded it. Without one, the origin of an artifact is whatever someone remembers.

The same reasoning applies to data written by agents. A row inserted into a table should be traceable to the run that inserted it, which usually means carrying a run identifier into the write rather than reconstructing it from timestamps afterwards.

Attribution requires identity

An audit trail that attributes everything to a service account has recorded that something happened and not who is accountable for it.

This is the most common structural gap. Agents run with their own credentials, so every action is attributed to the agent. The person who asked, the authority under which the work ran, and the reason the work was permitted are all absent, and none can be added later.

Carrying a real principal through the run fixes it, and it also makes the record useful to people outside engineering. An audit trail naming people and roles can be read by whoever is responsible for the process. One naming service accounts requires a translation step that only the engineering team can perform, which undermines the point of having it.

A question arriving nine months later

The abstract case for auditability is unpersuasive until you walk through a concrete question, so here is one that is entirely ordinary.

A customer disputes a pricing decision made nine months ago. The decision was produced by an agent that analyzed usage data and applied a discount tier. The customer says the tier was wrong. Nobody involved at the time still works on the team.

In a system without auditability, the reconstruction goes like this. Traces were retained for thirty days, so the run is gone. The billing record shows the tier applied and not why. The data the agent read has been updated many times since, so re-running the analysis produces a different answer, which proves nothing. The best available response is that the system applied its rules correctly, which is an assertion rather than an answer, and it is the answer that loses disputes.

In a system with auditability, the same reconstruction is a lookup. The run identifier is on the billing record. The record shows the request, the requester, the agent and profile revision in force, the tables and snapshots read, the query issued, the tier computed, and the approval that released it, with what the approver saw. Reading the snapshot shows exactly the data the agent had. If the tier was wrong, the record shows whether the error was in the data, the definition, or the decision, which determines who owes what.

Notice that the second version required nothing exotic. It required a run identifier carried into the write, a snapshot identifier recorded with the read, an approval bound to the action, and retention matched to the period over which disputes arise. Each of those is a small decision made at build time. None of them can be made afterwards.

Retention as a deliberate decision

Retention is where auditability is usually lost, and it is lost by default rather than by decision.

Storage defaults are set for operational logging, typically days or weeks. Audit questions arrive on a different timescale entirely: a quarter-end review, an annual audit, a dispute about something from last year. A record deleted on day thirty cannot answer a question asked on day ninety.

Retention also pulls against privacy, and pretending otherwise leads to bad outcomes in both directions. A complete record contains everything that flowed through the system, including sensitive material a tool returned.

A workable resolution is tiering. Keep full detail for a period matched to debugging needs. Keep structured metadata, meaning who, what, when, which sources, which approvals, and what changed, for as long as questions can plausibly be asked. Most audit questions are answerable from metadata, and metadata is far less sensitive than full content.

Integrity of the record

For some purposes it matters that a record has not been altered, and this requirement is easy to miss because it does not arise in ordinary logging.

Where it matters, the mechanisms are ordinary: append-only storage, access control separating who can write records from who can modify them, checksums over artifacts, and delivery to a system the agent runtime cannot edit. Versioned record formats help too, so a change in what is recorded is visible rather than silent.

The judgment call is how far to go. Full tamper-evidence is real engineering effort and unnecessary for most internal use. Delivering records to a separate system the agent cannot write to is a large fraction of the benefit for a small fraction of the cost, and it is worth doing by default.

Practices that preserve it

1. Record from the first day. The past cannot be instrumented. This is the one item with no recovery.
2. Carry a real identity through every run. Attribution to a service account is not attribution.
3. Record snapshot identifiers with data reads. The cheapest way to make an answer reproducible.
4. Bind approvals to specific actions. Including what was displayed, so the approval covers what was actually seen.
5. Deliver rather than log. With buffering, retry, and a way to verify delivery is working.
6. Attach provenance to artifacts. So a document found later can be traced back.
7. Set retention deliberately, in tiers. Full detail briefly, metadata for as long as questions can be asked.
8. Test it. Pick a task from three months ago and try to answer the eight questions. What you cannot answer is your gap.

Designing for who will read it

Audit records are usually designed by engineers and read by people who are not engineers, and that mismatch is why many audit trails technically contain the answer and cannot produce it.

The likely readers are worth thinking about explicitly, because they need different things.

The process owner

Someone responsible for the work the agent was doing, checking whether it went correctly. They need the sequence in business terms: what was requested, what the agent concluded, what it changed. They do not need token counts, and they cannot use a record that names service accounts instead of people.

The investigator

Someone establishing what happened in a specific case, often under time pressure, often months later. They need to find the run from an external artifact, such as a document or a database row, which means the identifier has to travel with the output rather than living only in the trace store.

The reviewer of authority

Someone asking whether the agent should have been able to do this at all. They need the permissions in force at the time, not the current ones, and the approvals with what the approver actually saw.

The engineer

The reader the records are usually designed for, needing full technical detail. Well served by most implementations, and the only one who is.

The practical implication is to produce a readable summary alongside the technical record, generated at the time from the structured data rather than written later. A run summary naming the requester, the action, the sources, the approvals, and the outcome, in plain language, is what makes the record usable by three of the four audiences. It costs very little and it is the difference between a trail that answers questions and one that requires an engineer to interpret every time anyone asks.

What it is not

Auditable is not the same as compliant. Compliance regimes have specific requirements that auditability supports and does not satisfy on its own.

Auditable is not the same as explainable. A record shows what a model was sent and what it returned. It does not explain why the model produced that output. Asking a model to explain a past decision produces a plausible story rather than a record, and treating that story as an audit artifact is worse than having nothing, because it looks like an answer.

Auditable is not free, and its cost is ongoing rather than one-time: storage, delivery infrastructure, and the discipline of recording things nobody has asked for yet. That is the trade, and the reason to make it is that the alternative is not a smaller record but no answer at all.