A client ran a decay pass on his LinkedIn archive last month. Found a post from November quoting a fee structure that changed in January, edited in one clause, moved on. Good outcome, twenty minutes well spent.
Three weeks later a prospect quoted the same wrong number back to him on a call. Not from the post. From his newsletter, where the same figure had gone out in February and now sits in an archive with a public URL. It was also in his About section, in the deck his sales team sends, and in a podcast episode from March that nobody can edit at all.
He fixed one instance of a claim that lived in five places, and he had no idea the other four existed. Not because he's disorganised. Because nothing in a normal content operation records where a claim goes after it's published.
The gap the decay pass doesn't close
We've written before about running a quarterly decay pass — reading back through the archive and asking whether each post still says something true. It's a good system and it has one structural limit: it's single-channel. You open LinkedIn, you check LinkedIn, you fix LinkedIn.
But founders don't publish into one channel. A single number — the one that makes your best argument, the one you're proudest of, the one prospects remember — typically ends up in:
- Two or three LinkedIn posts
- The About section or the headline
- A newsletter issue
- One or two podcast appearances
- The website's homepage or services page
- The pitch deck
- The first ninety seconds of every sales call
That's not a content problem. That's the claim doing its job. A load-bearing claim is supposed to travel. The problem is that it travels without leaving a forwarding address, so the day it stops being true you can fix the copy you happen to be looking at and nothing else.
What counts as a load-bearing claim
Most of what you publish does not need to be tracked. Opinions don't decay. Mechanisms mostly don't. Judgment doesn't. If you tried to register every sentence you'd have a second job and no system.
A claim belongs in the register if it meets two tests:
It's specific enough to be wrong. "Return rates matter more than founders think" can't be wrong. "We took an 11.4% return rate to 7.2% in eight weeks" can be — and can also stop being your best number the moment something changes.
It's repeated. If you've said it more than twice in more than one place, it's infrastructure. It's part of how the market understands you, which means an error in it doesn't get read as a slip, it gets read as a description of how carefully you work.
In practice most founders have somewhere between eight and twenty of these. Revenue scale. Team size. A result. A cost figure. A market statistic borrowed from somewhere. A platform mechanic. Client count. Years doing the thing.
That's the entire register. Twenty rows, not two hundred.
The five fields
One row per claim. Not per post — per claim.
The claim, written once, in its canonical form. This is the version everything else should match. Founders are frequently surprised at how much drift there already is: the same result quoted as "about 40%" in one place, "roughly a third" in another, and an exact figure in a third. All three describe the same thing. Only one of them is what you'd defend in a DM.
What it's based on. The report, the date range, the account, the source. If it came from outside your business, this field points at the source ledger entry instead. You need this because the day someone challenges the number, the useful thing is not remembering that you believed it, it's being able to produce what you believed it from.
When it was true. The window, not the publish date. A figure pulled in August describing May through July is a statement about May through July. This is the field that lets you date a claim in public without going back to check anything.
Where it's published. The whole point of the register. Every surface, listed. Post URLs, the newsletter issue, the deck slide, the page on the site, the episode. This field takes ten minutes to fill the first time and thirty seconds to maintain afterwards.
Editable or not. A binary that decides everything about what you do when the claim changes. Your website is editable. A LinkedIn post is editable. A sent newsletter is half-editable — you may be able to fix the web archive, you cannot recall the email. A podcast episode, a conference talk, a screenshot someone took, a quote in someone else's article: not editable at all, and permanently findable.
What you do when a claim changes
The register only earns its keep at the moment a number stops being true. Then it turns a vague anxiety into a short list.
On editable surfaces, edit — and date rather than delete. One clause. "When we ran this in March." "This was before the fee change." Founders resist dating a receipt because it feels like weakening it, and it does the opposite: an undated claim reads as a statement about now and gets caught, a dated one reads as a record and converts a stale number into evidence you were watching.
On uneditable surfaces, publish over the top. You cannot edit a podcast. You can publish a post that supersedes it, and you should — the correction post is one of the most credible formats available to a founder and almost nobody uses it, because they only ever notice they need it when it's too late to look organised about it.
Stop the claim at the source before it multiplies. The register's real value is upstream. A founder who knows a number is on eleven surfaces stops casually adding a twelfth. A founder who doesn't know puts it in a new deck next Tuesday.
The second job nobody expects
Founders build this for accuracy. What they end up using it for is repetition.
Once you can see that your best result has appeared in three posts, a newsletter and two podcasts, you can also see the thing nobody tracks: the reader most likely to hire you is the one who has encountered all six. Your most valuable audience member is the one experiencing the most repetition. The prospect who follows you, subscribes, and listens is getting your greatest hits on a loop.
That's not automatically a problem — repetition is how positioning works, and an owned claim only becomes owned by being said more than once. But there's a difference between reinforcing a claim and having nothing else. The register makes the ratio visible, and the fix is not to retire your best number. It's to notice that you have six placements of one claim and one placement of the other four, which is usually a supply signal rather than an editing one.
What good looks like
Two tells, neither of them a tidy spreadsheet.
You can name your three most-published claims from memory, and you know where each one is weakest. That changes how you write. Founders who run a register start hedging correctly at the point of writing — dating things, banding numbers, attributing sources — because they can feel which claims are load-bearing while they're making them.
A correction takes twenty minutes instead of a week of dread. The reason founders avoid correcting things is not ego, it's that they don't know how big the job is. An unbounded task with reputational stakes attached is a task nobody starts. A list of five surfaces with three of them editable is just Tuesday.
FAQ
How is this different from the source ledger? The source ledger tracks numbers that came from outside your business — someone else's study, a platform stat, a report — with a re-check date attached, so you don't publish a stale statistic with your name on it. The claim register tracks where your claims have been published, so a change propagates. Same discipline, opposite direction: one watches the input, one watches the output.
Isn't this what a content calendar does? No. A calendar records what you published and when. The register records what you asserted and where it now lives. You can have an immaculate calendar and still have no idea that your revenue figure is on a services page you last touched fourteen months ago.
How often do I look at it? You don't, mostly. It's a lookup table, not a routine. It gets opened when something changes — a number moves, a mechanic changes, you finish a decay pass and find an error. The one scheduled use is when your business changes shape: a raise, an exit, a new channel, a headcount change. Those events invalidate several rows at once and are exactly the moment nobody is thinking about content.
I've been publishing for two years with no register. Where do I start? Not with the archive. Write down the five claims you make most often, fill the fields for those, and add rows as claims prove themselves. Reconstructing every placement of every number you've ever used is a weekend nobody enjoys and it produces a document you'd never maintain. Five accurate rows beat forty stale ones.
Most of what makes founder content credible is not the writing. It's the fact that a stranger can check you and find the same story everywhere they look. That's an operational property, not a stylistic one — and it lasts exactly as long as somebody knows where everything is.
If you're publishing across three or four surfaces and nobody owns the version control, that's the conversation we usually have first.