Who is responsible when a published claim turns out to be wrong

A post goes out on a client's account. It says the product cuts onboarding time by 60%. Nobody at the agency invented that number on purpose — it came from a deck, or a draft, or a model filling a gap in a sentence that wanted a figure. A competitor's marketing lead screenshots it. The client's legal contact asks where it came from.

Now the question arrives, and it arrives at the worst possible time: whose fault is this?

Almost every agency answers it for the first time while it is happening. That is the mistake. The answer is cheap to write down in advance and extremely expensive to negotiate under pressure.

The four places a claim breaks

Wrong claims do not come from one failure. They come from four, and they need different fixes.

1. The claim was never true. Someone made it up, or a generated draft produced a plausible number because the sentence wanted one. This is the AI-era failure mode and it is genuinely new: a model has no way to know it invented a figure, and neither does the person pasting it, because it reads exactly like the ones that are real.

2. The claim was true once. "Trusted by 400 teams" was accurate in March. It is now in a template. Nobody re-checked, because nothing marked it as perishable. Undated facts go wrong silently, which makes this the most common category by a wide margin.

3. The claim was true but not permitted. The number is real; the client's legal or compliance team had not cleared it for public use, or it belonged to a customer who never agreed to be named.

4. The claim was fine and the scope was not. One beta customer's result stated as "our customers see." The data is real, the generalisation is not. This is the most defensible-feeling error and often the most damaging, because it is deliberate rather than accidental.

Notice that only the first is about invention. The other three are about process: dating, permission and scope.

Assign responsibility before it happens

Three lines in the contract or the onboarding doc, agreed once, that decide the argument in advance.

The client owns the truth of facts about their business. They are the only ones who can. The agency cannot verify a retention number, a customer count or whether a case study is cleared. What the agency owes is that no factual claim appears in a published post unless the client supplied it or approved it.

The agency owns that nothing unsourced ships. This is the real obligation and it is a process commitment, not a knowledge one: every factual claim in a draft traces to something the client provided. If it cannot be traced, it does not go out. Missing a source is a blocker, not a style note.

Approval is a decision with a name on it. Whoever approved the post approved the claims in it. Not "marketing saw it" — a person, a timestamp, a version. Without that, responsibility is a memory contest, and memory contests end relationships.

Add one operational rule that prevents most of category two: every number carries the date it was true. Facts stored without dates rot invisibly. Facts stored with dates announce when they need re-checking.

The mechanism that actually works

Policies do not stop wrong claims. The moment of failure is a writer at 4pm with a sentence that needs a number, and no policy is present in that moment.

What works is making the unsourced version harder to produce than the sourced one:

• Keep a per-client fact file — claims permitted, with dates and sources — that sits where drafting happens rather than in a folder nobody opens.
• Keep a forbidden list alongside it: claims that may never be made, comparisons that may not be drawn, customers that may not be named. Collect it during onboarding, on day one.
• Treat a missing fact as a stop, not a gap. The instinct is to write around it with something softer, and softer usually means vaguer and larger — "customers save hours" is a worse claim than the specific one it replaced, because it silently generalises.

That third point is the one AI-assisted workflows get wrong by default. A general-purpose model will always produce something rather than refuse, because producing text is what it is for. That behaviour is fine for a first draft of an essay and unacceptable on a client's account, which is why SelfSM is built to stop instead: without a supporting fact it narrows the claim or refuses to draft and asks for evidence. The unsupported version never exists to be pasted by accident.

When it happens anyway

It will. The response matters more than the prevention, and speed is most of it.

1. Correct or delete within the hour. Deleting is not an admission of anything; leaving it up while you decide is.
2. Tell the client before they find it. Every hour they discover it independently costs more than the error did.
3. Say which of the four categories it was. Invented, stale, unpermitted or over-scoped. Each has a different fix and a different owner, and naming it stops the conversation from becoming about competence in general.
4. Show the trail. Who drafted, what it was based on, who approved. Not to deflect — to move the discussion from "how did this happen" to "which step do we change."
5. Change one step, visibly. A named process change is what converts an incident into an argument for keeping you.

Agencies that survive these have a record. Agencies that do not have a Slack thread and three people's recollections.

Why this gets worse at scale

One client, one writer, one approver — the whole thing fits in someone's head. At eight clients with juniors drafting, the facts live in eight different places, half of them are stale, and the person writing has no fast way to check whether a number is current, permitted or scoped correctly.

That is the actual argument for putting brand facts, permissions and the approval trail on the work itself rather than in documents: not tidiness, but that the safe path has to be the fast path at 4pm. If checking is slower than guessing, people guess. Roles and release permissions are the other half of the same problem.

FAQ

Who is liable if an agency publishes a false claim about a client? Contractually it depends on what was agreed, which is why it should be agreed in advance: the standard split is that the client owns the truth of facts about their business, the agency owns that nothing unsourced ships, and whoever approved a post approved the claims in it.

How do agencies prevent AI-generated posts from inventing facts? By keeping a per-client file of permitted claims with dates and sources, treating a missing fact as a blocker rather than something to write around, and using tooling that refuses to draft an unsupported claim instead of producing a plausible one. General-purpose models always produce something, because producing text is what they do.

What should be in a client fact file? Numbers you may cite with the date each was true, customers you may name and how, claims requiring legal review before publishing, and a forbidden list of claims and comparisons that may never appear.

What do you do when a wrong post is already live? Correct or delete within the hour, tell the client before they discover it, name which category of failure it was, show the drafting and approval trail, and change one named process step. Speed and specificity matter more than the apology.

Is "our customers see X" safe if one customer saw X? No. Generalising one result to a plural is the most damaging category precisely because it feels defensible. State the claim as narrowly as the evidence supports — one named result is more persuasive than a vague plural anyway.