Design the audit trail for an agent operating on business systems.

The dispute file sits in a single folder on Elin Marsh's desk, thicker than it should ever have needed to be. Vantry Industrial's agent writes to the company's ERP system about 140 times a day: placing purchase orders, rescheduling production runs, adjusting reorder points. Elin leads operations and compliance there.

How to answer this, stage by stage

Nobody's grading whether you can define "audit trail." They're grading whether you can name the one entry that would have actually settled a real dispute.

Let's learn

Here is what happens when a system changes 140 things a day, and only one of those changes ever gets a lawyer's attention, months later, long after anyone remembers the details.

Vantry Industrial's procurement agent writes to the ERP system directly: placing purchase orders with approved vendors, rescheduling production runs, adjusting reorder points, based on live demand and vendor-performance signals.

Before the agent, a scheduling analyst made these calls by hand, and every change carried an informal but real trail: an email to the vendor, a meeting note, a memory of why. Slower, but reconstructable months later if it had to be.

The agent's own system log kept a record too, just a thinner one: field, old value, new value, timestamp, changed by "SchedulingAgent." Nothing about why, nothing about which signal triggered it, nothing proving any contractual duty had been met.

At its worst: Vantry's agent cancelled a $340,000 purchase order with Corrigan Components after the vendor's own lead time crept past 45 days, triggering an auto-cancel rule. Corrigan disputed it, citing a contract clause requiring ten days' notice on cancellations above $100,000.

What I would leave alone: routine reorder-point adjustments with no dollar threshold and no contractual duty attached. A basic what-and-why entry is enough there; they don't need verified evidence behind them.

The lesson: a system that changes things quickly isn't automatically a system anyone can explain later. Speed and explainability are two different features, and only one of them shipped by default.

Now here is the same thing as a story

The short version above is what you'd say briefing Vantry's general counsel. Read this one for how the gap actually surfaced.

The dispute file on Elin Marsh's desk started as three printed emails from Corrigan Components. It grew to forty pages within a month.

Before the agent, the trail was informal, but it existed, scattered across inboxes a person could still search.

For the agent's first year, nobody questioned a single one of its roughly 140 daily changes. The system log looked complete: every field change, timestamped, attributed. Elin's team had no reason to build anything more.

The cancellation itself took the agent a fraction of a second. Untangling it took three weeks.

Then Corrigan's lead time crept past 45 days, a supplier-performance rule fired, and the agent cancelled the $340,000 order. Weeks later, Corrigan's counsel wrote to Vantry, claiming the required ten-day notice never went out.

The old system treated every action the same. The fix was letting the dollar value and the contract terms decide how much detail an entry earns.

Elin's team pulled the system log. It showed the cancellation, the timestamp, and nothing else: no link to the lead-time signal, no record of any notice being sent, no policy reference. Three weeks of digging through email servers and a separate notification system's own logs still couldn't conclusively prove notice had gone out.

The notification system claimed to have sent the notice. Nothing had ever checked whether that claim was actually true.

Vantry settled with Corrigan at a real discount to preserve the relationship, and lost three weeks of shipments while the account sat frozen during the dispute.

The redesigned entry carries all four of these. The old one carried exactly one: what changed.

Replayed with the redesign in place: the same lead-time shift fires the same cancellation rule, but the entry now reads "Cancelled: lead time exceeded 45 days, policy PROC-19, notice sent to Corrigan at 9:14am, delivery receipt confirmed at 9:16am." A dispute over the same order resolves in about fifteen minutes, with a receipt, not a guess.

Once sorted this way, it's obvious which actions were always going to need more than a field-change log.

We trusted the platform's default log because it looked thorough on the surface, every field change, every timestamp. It took a vendor's lawyer, not an internal review, to show that "thorough" and "answerable" were never the same claim.

SPARK, the audit trail as one design decisionNot a compliance checklist. SPARK is what turns "log everything" into one buildable, defensible anchor.

The recap, one line per letter: situation is a field-change log with no reasoning behind it, payoff is a reviewer who actually checks instead of assuming, anchor is what-why-and-verified-evidence scaled to impact, risk is a false "verified" flag being worse than none, and keep out is skipping raw reasoning traces and a natural-language query layer for now.

And if you want to be sure it really works, try it somewhere elseSame anchor, a pharmacy instead of a factory floor. No purchase orders in sight, and the same design decision still holds.

Nora Vasquez oversees medication management at a pharmacy chain where an agent reviews prescription renewal requests and can authorize refills directly in the health record system. Mapped onto SPARK: the situation is a system log that shows a refill was authorized, with no record of which renewal criteria were checked. The payoff is a pharmacist actually able to verify a specific refill decision when a patient or a physician's office questions it, instead of assuming the system got it right. The anchor: every refill logs which criteria were checked and the specific prescription rule that applied; any refill that required physician confirmation also stores a verified confirmation receipt, not just a note that one was requested. The risk: a "physician confirmed" flag that was actually just an unanswered fax request would be far more dangerous here than in a procurement system, since it could mean an unauthorized refill of a controlled medication. Keep out: no full clinical reasoning trace logged verbatim, since it would store more sensitive patient detail than the compliance need actually requires.

Swap "dollar impact" for "medication risk" and the same sorting logic decides which refills need verified evidence.

Swap the trigger and it still runs.
Speed: an interviewer caps you at sixty seconds. Say "log what, why, and verified evidence where a real duty exists," and stop.
Cost: there's no budget this quarter for a full evidence-verification pipeline. Start with the single highest-impact action type, the one most likely to end up disputed, and expand from there.
The model gets better, for real: if the agent's decisions get more accurate overall, that's still not a reason to skip verified evidence on duty-bound actions. A more accurate agent can still fail to confirm a notice actually arrived.

Where people run it wrong.
They assume a platform's default change log counts as an audit trail, when it only ever answers "what," never "why."
They log a self-reported "notification sent" flag and treat it as proof, without ever verifying it against real delivery evidence.
They try to log everything, in full detail, from day one, and end up with a system too expensive and too risky to actually ship.

How to use it live. When someone asks you to design an audit trail, don't start by listing what to log. Start by picking one plausible future dispute and asking what single entry would have settled it in minutes.

Flashcards (tap any card to flip it)

Check yourself Score: 0 / 0