What "on the record" means in your ERP — the anatomy of an AI audit trail

Every AI vendor's deck has the word "audit" on it somewhere. Fewer products can survive the question my team asks when we sign off a release: show me the row for the thing that didn't happen. An audit trail that only remembers successes is a highlight reel, and highlight reels are how systems lie politely. This piece is the anatomy of a trail that actually deserves the name — what each row must carry, why refusals belong in it, and the checks worth running on any product's log, ours included.

#One decision, one row — no exceptions clause

The unit of an AI audit trail is the decision, not the action. The distinction matters: actions are what happened; decisions include what was prevented, held, and refused. A complete row carries the timestamp, the person (or the agent acting for a person — named either way), the channel the request came through, the model and action touched, the outcome — allowed, blocked, held-then-approved — and the rule that produced it. Remove any one of those and a future question becomes unanswerable: without the channel you cannot trace an injection path; without the rule you cannot tell policy from accident; without the person you have a service account shrugging.

#Why sampling is lying

Traditional logging samples for cost: keep some events, drop the rest, keep the aggregate honest. That logic collapses for AI decisions, for a reason auditors state plainly: the row you need later is, almost by definition, the anomaly — and anomalies are what sampling drops. If a trail keeps one write in ten, the answer to "did the agent touch this pricing table in March" is not no; it is we kept 10% of the answer. We design and test for exactly this: one decision, one row, with our release checks detecting missing rows on every decision path we cover — a missing row is treated as a failing build. One decision, one row is not a feature tier. It is what the word audit means.

#Refusals are the half that earns trust

The rows that make an AI trail different from an ordinary application log are the refusals: the read that was out of scope, the write above the cap, the request the injection screen killed. They matter twice. Operationally, they are your early-warning surface — a cluster of declined reads against one model is a story worth hearing before it becomes an incident. And evidentially, they are the proof your controls exist: anyone can print a list of successes; only a governed system can show you, in the same list, the things it stopped. When the buyers' objections piece says an assistant is only safe if it can be refused, this is where that refusal has to land.

#The four checks to run on any product's trail

My team's release sign-off, offered as your evaluation script. Existence of refusals: ask the assistant for something out of scope, then find the row — a trail with only green rows fails. Named attribution: every row ties to a person, not a service account. Independence: your auditor can filter and export the trail without the vendor on the call. Completeness under load: run a burst of requests and count rows against requests — sampling shows up here. Ten minutes, four checks, and you know more about a product's governance than its whitepaper will ever tell you. The full 20-check version extends these to the rest of the stack; how the trail is produced in Odient — one row per decision through the same five-gate path for every channel, as enumerated on the security page.

#Frequently asked questions