Audit Log Retention: What Happens at Zero

Audit log retention is the one governance property every vendor in this market can put a number on, because it is the one they can sell. Which makes it the best place to ask the question that never comes up in a demo: what does this platform do when the meter empties?

Every meter has a floor, and almost nobody documents it

Procurement asks three questions. What does it do. What does it cost. Who is it for. The fourth one — what happens when the meter empties — is the one that decides what you can prove eighteen months from now, and it is usually not on the page at all. Where a vendor does document it, the answer tends to be one line in a FAQ, past the fold, phrased as a reassurance.

A metered model is not a swindle. Pay-for-what-you-use is fair, and a light user pays less. The objection is not that something is metered. It is that the floor is undocumented — and that in an account a regulator can ask about, the floor is the same question as whether the evidence exists. It is sharpest in the Telegram lane, where the thing on the meter is the conversion itself: we keep a head-to-head on TG Tracker for that reason, and the same pattern runs through it.

Four things a platform can do at zero

• Fail closed. The action does not happen. It costs you an outage and it buys you a guarantee: nothing ran that you did not authorise.
• Fail open. The action runs and the invoice arrives later. Your busiest month becomes your most expensive one, and nobody was asked.
• Fail undefined. The vendor has not said. This is the most common answer in the cohort, and the easiest one to write into a contract by accident.
• Fail silent. The write reports success and nothing changed. No vendor documents this, which is precisely why a record that only the platform holds is not evidence — the only way to catch it is to reconcile against the ad platform.

Synter is the only vendor here that publishes two of the four on one page. Credit what it has shipped first, because it is the strongest safety documentation in this cohort: a budget hard cap “enforced server-side before any platform API call”, a conversion-tracking gate that blocks launches when verified tracking is not active, and “Unknown operations require approval — regardless of the workspace’s autonomy level.” New campaigns are coerced to paused before they reach the platform API. Defaults like that are worth more than any compliance page.

Then the floor. “Unpriced tools fail closed at 10 credits” is the right call, and it is the right call for a good reason: an unpriced tool is exactly the tool whose cost you cannot forecast. Now the same page’s FAQ, asked what happens when the included monthly credits run out:

“Your AI agents continue running without interruption. Additional usage beyond your credit balance is metered at the catalog rates (from $0.05 reads to $27.50 video) and billed automatically at month-end on the Developer Usage meter.”

So the safety-critical class fails closed and the spending class fails open, eleven lines apart, on the page you read to decide what the software costs. Both behaviours are defensible. Which one is the governance answer depends entirely on whose money is at risk when the meter hits zero — and that is a question a price list cannot answer.

The record has a floor too

Start with the good version, because it exists. Synter’s activity record is the best-documented of the cohort: log entries are “immutable” and include a timestamp, an actor, the entity, what was created or changed or blocked, before and after values, and “Decision — Allowed, coerced, blocked, or pending approval.” A Decision field is more than most platforms publish, and it is the field a client dispute actually turns on.

Now the numbers, on the vendor’s own two pages. The security page says audit logs are “retained for 2 years.” The governance page says the trail is kept “for the life of the workspace” and “never purged on a timer.” And the same governance page publishes the control:

Keep the object boundaries intact, because they are what make the rest of this unfalsifiable: the 0/30/90 setting governs API request/response logs, which is a different object from the audit trail, and the retention figure you would write into a client contract is published for neither. That is the finding. Not a contradiction you can prove — three lifetimes, two pages, one control with a zero position, and no published field list that tells you which record the setting governs.

The form is the part to remember. Every vendor will give you a sentence about retention. Only one in this cohort gives you a dropdown, and the dropdown goes to zero.

The gate has a floor too

Supermetrics documents its approval gate better than anyone: four named options, then a promise that “every campaign change is recorded in Campaign History, so teams can see what changed and undo supported actions where needed.” Here is the menu, verbatim:

• “No human approval: Changes apply immediately.”
• “Going live: Approve before a campaign goes live, including unpausing one.”
• “Budget + going live: Approve before budget changes on live campaigns and before a campaign goes live.”
• “All live changes: Approve any change to a live campaign (including enabling the campaign).”

Option one is the floor, and it is the whole argument in eleven words. Select it and Campaign History still records the change — but there is no authorisation event to record, because no authorisation happened. The log keeps its completeness and loses its meaning. Every governance property in the write era is a setting, and every setting has a position that produces no evidence. This one is published, which is what makes it quotable rather than accusatory.

The log is not the record

Two gaps sit underneath all of this. The first is that a capability documented in a blog post can have no address in the product. Since 10 September, Supermetrics’ blog has claimed you can “create, copy, pause, and modify campaigns” across six platforms including ChatGPT Ads. Re-read eleven days later, the MCP product page still contains zero occurrences of “write”, “create” or “pause”, and still describes the integration as asking a question and getting a real answer from live data. You cannot ask what a feature does at zero when the feature has no settings page.

The second is that a log explains itself differently depending on which page you read. Synter’s Change Journal documents seven fields, including “Rationale — why the agent made this change” from the model’s own reasoning. The security page documents six, including the Decision field. Neither list contains anything resembling “approved by”, and a model’s stated reason is not an authorisation. That distinction is not pedantry in a financial promotion file; it is the difference between a record that answers the question and one that restates the machine’s opinion of itself.

Which is why the storage location matters more than the field list. Meta restricts an account and Meta’s own change history goes with it. The activity log we ship carries four fields on every change — timestamp, actor, before-and-after values, linked object — and keeps them in our own database rather than in Meta’s. For the longer version of that argument, see what a real audit trail requires.

The floor test

Four questions, and ask them in writing, because the answer in the demo and the answer in the documentation tend to differ.

Ott’s floor, in our own words

Our meter is brands and seats, and the pricing page says so plainly: “No charges per ad account, data source, or Telegram join. Limits are by brands and seats so teams know exactly what they get.” An extra brand slot is CHF 39 a month. None of that governs the activity record, and that is the only claim being made here. The floor test applies to us as well, so here are our four exceptions.

• We do have a spend-scaling element. Our own page says: “Pricing scales with your ad spend… At 1% of ad spend above included amounts, the platform pays for itself.” Anyone describing our model as flat with no spend component is describing a different page.
• We meter API requests. “REST API & MCP access — 500,000 requests/month included” on Agency, and “generous usage (per agreement)” on Agency Pro. We are not the vendor with no meter. We are the vendor whose meter is not pointed at the record.
• Starter excludes things. Telegram conversion tracking and REST API & MCP access are Agency-tier items, not every-plan items. On Agency, Telegram tracking arrives as one channel mapping, with extra mappings at CHF 199 a month. If you are quoting Starter to a client, quote the exclusions with it.
• We publish no retention number. The word “retention” appears zero times on our pricing page and zero times on our activity-log page. The narrow claim is the only one available: the record is not a billable unit, and it is not gated behind a plan row. We do not have a retention clause to quote, and that is its own unfinished answer.

One scope note, because precision is the point. Ott’s activity log is populated from Meta’s ad-activity events and stored in our own database. The storage is what lets the trail survive a restriction — Meta going down does not erase our copy of what it reported — but the source is Meta’s. If Meta never saw the change, we cannot invent it.

A price list tells you what you pay. A meter tells you what gets more expensive as you grow. Only the floor tells you what will still exist when someone asks — so ask for it before you sign, and ask for it in writing. The vendor who can answer in one sentence has already told you something about how the record is built.