A claims register is one document that lists what your content can say: current product facts and figures in their approved wording, retired claims with the date they stopped being true, and competitor facts with a source and the date someone last checked them. Writers, AI tools and sales decks all pull from it, so you fix a stale claim once instead of in five places. This piece covers what goes in it, who owns it and how to wire it into AI drafting, and there’s a free template at the end.
Every content team needs a claims register, and the more writers and AI workflows you run, the sooner you need one. It’s a single, owned list of every factual claim your content makes, each with its approved wording, a source, a last-checked date and a status. When a feature or price changes, or a competitor rewrites their pricing page, you change one row and everything that reads from the register picks up the new version. Without one, the same fact lives in a blog post, two landing pages, a sales deck and an AI prompt, and it goes stale in all five on its own schedule.
What goes in a claims register?
There are four kinds of entry, and each has its own tab in the template.
Current claims. These are product facts and figures, integrations, pricing and positioning lines, each in the exact wording writers should use. Every row carries a claim ID, a source (product docs, a release note, a signed-off case study), an owner, the date someone last verified it, and a review date the sheet works out for you. “Supports SSO” on its own isn’t enough, so write “SSO via SAML on the Business plan and above, per the security docs, checked 1 October”, which is a claim someone can stand behind.
Retired claims. This is anything that used to be true, with the date it stopped and the claim that replaced it. Never delete these, because your old content still says them and the retired tab is how you find where. I’d argue this tab is worth more than the current one, since nobody remembers to hunt for the old free plan in a 2024 blog post until a customer quotes it at sales.
Competitor facts. This is what a competitor charges, ships or claims, with the source URL and the date someone checked it. These go stale fastest, so the template flags them as due after 30 days by default, since competitor pricing pages change without asking you first. If you publish comparison content (and you should, as I argued in the B2B comparison page piece), this tab is what keeps it fair.
A change log. This logs the date, claim ID, what changed, who changed it and who approved it. It’s boring, of course, and it’s exactly what you’ll want the first time someone asks why the website says one thing and last quarter’s deck says another.
Why do advertising rules make this more than tidiness?
Because “we’ll check it later” isn’t how advertising law works. The FTC’s 1984 policy statement on substantiation says:
“advertisers and ad agencies have a reasonable basis for advertising claims before they are disseminated.”
That’s from the FTC’s Policy Statement Regarding Advertising Substantiation. The UK’s CAP Code is just as direct: “before distributing or submitting a marketing communication for publication, marketers must hold documentary evidence” (ASA, rule 3.7). The EU only allows comparative advertising if it “objectively compares one or more material, relevant, verifiable and representative features” (Directive 2006/114/EC, Article 4).
You don’t need a lawyer in every review for any of that, just the evidence sitting somewhere you can point at before the post goes live. Regulated industries worked this out years ago: pharma teams run whole claims management systems so every promotional statement links back to its reference. A B2B SaaS team can build the same habit with a spreadsheet.
Who owns the claims register, and how do updates get in?
One named person owns it, and everyone else suggests. Usually that’s the content lead or product marketing, whoever already sits between product and the people writing about it. I made the same call when building brand consistency from scratch. Shared ownership sounds collaborative, but in practice it means nobody updates it.
Each kind of update needs its own trigger. Product changes arrive through release notes, so reading those goes on the owner’s weekly list. Competitor facts get a scheduled re-check (the Status column turns to “Due” when the date passes). And anyone who spots a wrong claim in the wild, whether in sales, support or a reader comment, sends it to the owner, who fixes the row and logs the change. That’s the same discipline as the editorial standards I built from zero, applied to facts instead of style.
How do you wire a claims register into AI workflows?
Give the AI the register and tell it to use only what’s in it, and to say so when a claim is missing. Anthropic’s own guidance on reducing hallucinations lists three basic moves: allow the model to say “I don’t know”, use direct quotes for factual grounding, and verify with citations. On direct quotes, it says: “This grounds its responses in the actual text, reducing hallucinations” (Claude docs).
In practice I export the Current claims and Competitor facts tabs to CSV and load them as context in every drafting workflow, with these instructions:
- Use only claims from the register, in their approved wording.
- Put the claim ID in a comment next to each factual sentence, so review turns into a quick lookup.
- If a sentence needs a fact the register doesn’t have, write “[CLAIM NEEDED]” and keep going.
The last instruction is the important one, because a model that’s allowed to flag a gap stops making up stats to close it. It also helps your public pages, since product documentation already beats blogs in AI answers when the facts in it are current. I wrote about the wider setup in context engineering for content marketers, and about which tasks I hand to AI; the register is the context file that stops those tasks going wrong quietly.
How is a claims register different from a source register or a source of truth?
They overlap, but each does a different job.
| Document | What it holds | Who reads it | Question it answers |
|---|---|---|---|
| Claims register | What your content may say about your product and competitors, with dates | Writers, AI tools, sales | Can we say this, in these words, today? |
| Source register | The external research and stats you cite, with links and editions | Writers, editors | Where did this stat come from, and is it current? |
| Source of truth | Everything the company knows: positioning, personas, docs, policies | Everyone | What’s the full picture? |
The register is the narrowest of the three, which is why it works: it’s small enough to load into every AI prompt and check in every review. A source of truth is too big to paste anywhere, and a source register covers other people’s stats instead of yours. I’ll write up both of those separately; for now, the AI readiness audit covers how to check a library for the stale facts all three exist to prevent.
What does a claims register catch in its first month?
More than you’d like, since the first month is mostly cleanup: building the retired tab means going back through everything the library already says. These are the kinds of catches I’ve seen when setting one up (nothing dramatic, though all of them embarrassing in front of a prospect):
- A plan or price that changed, still sitting in older blog posts and a one-pager.
- A feature renamed in the product and still called by its old name in half the content.
- A competitor fact that was true when written and isn’t now, in a comparison page.
- A stat cited from a report that’s since had a newer edition with a different figure.
- An AI draft repeating a retired claim, because the old wording was all over the library it learned the house style from.
That last one is why you should do this before you scale AI drafting, since a model trained on your old content will happily bring back everything you’ve stopped saying. Careful prompting alone won’t fix that; you need a register that tells the model what’s current and what’s dead.
What would I do differently?
I’d start the retired tab on day one instead of building it backwards. Writing down a claim the moment it stops being true takes a minute, while rebuilding six months of changes from release notes takes an afternoon and still misses some. I’d also put the competitor re-check in a calendar from the start, because a 30-day review date in a spreadsheet only works if somebody opens the spreadsheet.
Download the template
The template has six tabs: How to use, Current claims, Retired claims, Competitor facts, Change log and Settings. Pink cells are yours to fill and off-white cells are formulas. Review dates and Due flags work out automatically from the periods on the Settings tab. Delete the example rows before you start.
Frequently asked questions
It’s a single document listing every factual claim a company’s content makes, each with approved wording, a source, an owner and a last-verified date. It also keeps retired claims with the date they stopped being true, and competitor facts with a source and a check date. Writers, AI tools and sales materials pull from it, so you only make a change once.
One named person should own it, usually the content lead or product marketing manager, because they sit between product changes and the people writing about them. Anyone can suggest an update, but only the owner edits current claims and logs each change. Shared ownership tends to mean nobody keeps the register current.
Load the current claims and competitor facts as context and tell the model to use only those claims, in their approved wording. Ask it to put the claim ID next to each factual sentence and to write a placeholder when a needed fact isn’t in the register. That turns review into a lookup and stops the model inventing figures to fill gaps.
Review product claims every 90 days or on every release, whichever comes first, and competitor facts every 30 days, because pricing pages change without notice. Retired claims don’t need reviewing, but each one should list where it might still appear so you can clean up old content.
