An Audit Trail for AI-Driven Ad Spend: What It Should Include

A defensible audit trail for AI-driven ad spend records seven things per change: who or what proposed it, the hypothesis it was proposed under, the before and after state of the setting, who approved it and when, when it executed, how it was graded against that hypothesis, and whether it was reverted. Anything less is a change log. A change log tells you what moved. An audit trail tells you why it moved, who is answerable, and whether it worked. The second survives a finance review. The first doesn't.

Here's the part that catches buyers out. Every vendor in this category can produce a list of changes, because the platforms hand that over for free, Google Ads has a change history, Meta has an account activity log. The hard fields are the ones no platform generates: the prediction made before the change, the named human who approved it, and the verdict rendered after. Those three have to be captured at the moment of the decision; you cannot reconstruct them later. So the question to ask a vendor isn't "do you log changes", everyone does, but "show me one change with its hypothesis, its approver, and its verdict attached."

What's the difference between a change log and an audit trail?

A change log is a list of events. Bid changed from $4.20 to $4.83 at 14:07 UTC. Budget moved from $600/day to $750/day on Tuesday. Useful for debugging, and it's what the platforms give you natively.

An audit trail is a list of decisions, each with its reasoning and consequence attached. The change is one field in the record, not the whole record.

The difference shows up under pressure. A change log tells your CFO that 47 things changed last month. It can't tell her which were deliberate, which a machine proposed, which a human signed off on, and which ones worked. The gap gets filled by whoever remembers most confidently.

The middle column is where most teams live, and it's the most dangerous of the three. A change log looks like governance. It has timestamps and exports to CSV. It just lacks every field anyone needs when the conversation gets serious.

What are the seven fields a defensible change record has to carry?

Hold a vendor to this list, field by field. If one is missing, ask where it's captured instead. "It's in the notes" is not an answer, free-text notes aren't queryable and they're the first thing to erode when the team gets busy.

1. Who or what proposed the change

Not "the system." A named agent, person, or automated rule. This matters more as AI proposal volume rises, because the interesting failure is a class of proposal going wrong, not a single change, and you can only see that if proposals are attributable to a source you can group by.

Edge case: platform-native automation. Smart Bidding, Performance Max asset rotation, and Advantage+ placement shifts change your account without appearing as a proposal anywhere. A complete trail marks that boundary, where our record stops and the platform's black box begins, rather than implying the account only changes when someone clicks something.

2. The stated hypothesis

A falsifiable prediction, written before execution. "Raising the tCPA on this campaign by 15% should lift conversion volume without dropping ROAS below 3.1x within 14 days" is a hypothesis. "Optimizing bids" is a task description.

This is the field that converts a log into evidence. Without it, every after-the-fact result is unfalsifiable, you can always find a story that makes the outcome look intended. With it, the record can say the prediction was wrong, which is the only thing that makes it mean anything when the prediction was right.

3. The before and after state

Both sides. "Budget increased" is a log field. "Daily budget: $600 to $750, campaign X, account Y" is an audit field, because it's the only version you can reverse from without guessing. Include scope: a change applied at account level and one applied to a single ad group are different exposures, and a record that flattens both to "budget change" hides the one that mattered.

4. Who approved it, and when

A named human, with a timestamp. Not a role. Not a shared login. Not "auto-approved per policy."

This field carries the accountability, and it's the one most often quietly weakened. The usual degradation: a vendor supports named approval, the team finds clicking tedious, and within a quarter everything routes through a single service account or a standing rule. The field is still populated. It no longer means anything.

Adlyse's position is deliberately rigid, nothing executes without a human approval click, and there's no autonomous mode that skips it. That's a constraint, not a feature. If your team wants unattended execution at 2am, this is the wrong tool.

5. When it executed

Separate from when it was approved. The gap is where a surprising number of incidents live: a change approved Friday that executes Monday into a different auction environment, or a queued change landing after someone else already paused the campaign. Record both timestamps and the platform's timezone for the account, because Google Ads and Meta each report on their own clock, a change stamped "March 3" in one system and "March 2" in another is the same change.

6. The graded verdict

Improved, hurt, or neutral, judged against the hypothesis, in a window defined before the change shipped.

What this is not: the platform's own reported result. The platform tells you the campaign's ROAS for the period. That number includes seasonality, competitor behavior, your other eleven changes, and modeled conversions. A verdict is a comparison against a specific prior claim. A vendor that shows you a performance chart when you ask for a verdict is answering a different question. And "neutral" needs to be a real, frequently used outcome, a grading system that only returns "improved" is a marketing surface, not a measurement.

7. Whether it was reverted, and when

Linked to the original change, not filed as an unrelated event. Adlyse reverts "hurt" verdicts automatically and logs the revert inside the same record, so the trail reads as one decision with an outcome rather than two changes a reader has to pair up mentally.

The gap to watch: manual reverts done outside the system. Someone spots a problem and fixes it directly in the platform UI, and the trail now shows a change that was never undone. The record is wrong, which is worse than thin.

What does a spend ledger add that a change log doesn't?

A change log is denominated in settings. A spend ledger is denominated in money.

Those diverge fast. Twelve budget increases of $50/day each look like twelve small changes in a log. In a ledger they're a $600/day increase, $18,000 a month, and if your cap was $15,000 you crossed it four changes ago without any single change looking unusual.

That's the argument for a ledger as a separate object. Budget caps are cumulative constraints, and you can't enforce one by inspecting individual events. The ledger is the running total the cap is checked against. It also produces the one view a change log structurally can't: spend attributable to agent-proposed changes versus spend already running, usually what an executive sponsor is really asking for.

Who actually needs to read this record, and when?

Four scenarios, each asking for a different slice, which is why a single "activity feed" screen satisfies none of them.

A finance review. Finance wants the money view over a fixed period, reconciled to invoices: the ledger, cap adherence, whether any change moved budget outside the approved envelope. Individual hypotheses don't interest them. What they will ask: "was any of this spend authorized by someone without budget authority?" That's field 4, and it's answerable in seconds or not at all.

An agency-client dispute. The scenario this record is most valuable in and least often built for. Client says performance dropped after the agency took over optimization; agency says the account was already declining. Both open the same dashboard and read it differently, because a performance chart supports either story. What settles it is a dated prediction, written in advance it's evidence, written afterward it's an argument.

A post-mortem on a bad month. Order the trail by verdict, not by date. Pull the "hurt" verdicts and look for pattern, same change type, same account, same proposal source. A cluster on one kind of change means the reasoning is wrong, a far more useful finding than any individual change being wrong.

A compliance or legal request. Rare and highly variable, if you're in financial services or health, your requirements are specific and this post isn't them. What's generally true: a defined date range, exportable, showing human authorization.

What should you ask a vendor about retention and export?

Three questions, answered in writing before signing rather than during offboarding.

How long is the record kept? Not "indefinitely", get the number in the contract, then compare it to your own review cycles. If finance reviews annually and the vendor retains 90 days, the governance record expires before it's ever read.

Can you export it, and in what format? A record you can only view inside the vendor's UI is one you lose when the subscription lapses. Ask for machine-readable export, CSV or JSON with all seven fields, not a PDF report, and ask whether it's self-serve or a support ticket.

What happens to the record if you leave? Does the trail belong to you or the vendor? This cuts straight into the build vs. buy calculation, one genuine argument for building in-house is that the record sits in your own warehouse by construction.

Test the export in month one, while you still have leverage and attention. If it's missing the hypothesis field or the approver name, you've found out cheaply.

Why does most "AI reporting" fail this test?

Because it reports on the account, not on the decisions.

Open most AI ad-tool dashboards and you get account-level totals: spend, conversions, ROAS, a trend line, maybe a "changes made this month" count. That's a performance report with an automation badge on it. It shows the aggregate result of everything that happened, your changes, the agent's, the platform's own algorithmic adjustments, and the market, and invites you to read causation into a line going up.

The tell is simple. Ask the tool to show you one change and what it did. Not the month. One change. If the answer is a filtered version of the same account chart, there's no verdict layer underneath, just a log and a dashboard sitting next to each other.

"AI-powered insights" copy should raise rather than lower your guard. An insight generated after the fact from account-level data is the same unfalsifiable story-fitting a human does, faster. The governance value is in the prediction being on record before the outcome was known, which is what Agents Run It. Humans Lead. is really claiming about where the record belongs.

What should trigger a closer look at the trail?

Most of the time this is infrastructure you don't read. Three patterns deserve an actual review.

• A cluster of "hurt" verdicts on one change type. One bad change is noise. Five of the same shape is a wrong model, a conversation about reasoning, not execution.
• Approvals concentrating in one person. Especially on high-budget changes. Not because that person is doing anything wrong, but because single-approver concentration is how shared-login degradation starts, and it's real key-person risk when they take two weeks off.
• Any gap in the record. A change with no hypothesis. An approver field reading "system." A revert with no linked original. Treat these as process failures, not data-entry noise, a trail with holes fails in exactly the moment you need it, and the holes are always discovered under pressure.

FAQ