A client wrote in February that the 75-character title cap would be "the biggest CTR event of the year for anyone in a crowded category." Good post. Specific, dated, arguable. It did fine.
In late July the cap landed. Roughly 984 million titles changed inside seven weeks. Every search card in his category re-rendered at once. He was, in the plainest possible sense, right, and he had the receipt sitting on his own profile with a February date on it.
He did not write the follow-up. Not because he decided against it. Because he did not remember he had made the prediction. We found it during a decay pass three weeks after the event, when the post that would have done the most for him that quarter was already late.
That is the gap a prediction ledger closes. It is the smallest bank in the content system and, for the two posts it produces, the one with the highest return per entry.
Predictions are the only claims with a built-in second post
Most of what a founder publishes is a claim about now. A number, a mechanism, an opinion about how something works. Those claims decay, which is what the decay pass is for, but they do not resolve. Nothing happens later that settles them.
A prediction is different. It carries its own appointment. "By Q4 this will be table stakes." "This fee change will push the low end of the category out within a year." "Nobody will be running that placement by spring." Each of those has a date attached, and on that date one of two things is true.
Either you were right, and you own a dated receipt that proves you saw something before the people now writing about it. Or you were wrong, and you own the raw material for the most credible format available to a founder: the post that says what you thought, what happened instead, and what you missed.
Both are excellent posts. Both are almost never written. The reason is not courage. It is that nobody schedules the resolution, so the date arrives and passes and the prediction sits in the archive in present tense, quietly doing the one thing a stale prediction does, which is make a careful reader wonder whether you noticed.
Why the archive doesn't do this job for you
Founders assume they will remember. They will not. A prediction made in February about a July event is, by July, one of a hundred posts, and the founder is busy living through the event rather than checking who called it.
The archive also fails in a specific way. LinkedIn has no search worth using across your own posts, no reminder, no way to attach a date to a claim. A prediction post looks exactly like every other post. The only thing marking it as a claim with a resolve date is the founder's memory, and the founder's memory is the least reliable component in the system.
The claim register tracks where a claim is published. The source ledger tracks where an external number came from and when to re-check it. Neither of them asks the question that matters here: when does this get settled, and what would settle it?
Five fields, one line each
The ledger is a table. Most founders run it at ten to twenty rows. It is not a place for every opinion; it is a place for claims about the future that are specific enough to be wrong.
The prediction, in canonical form. One sentence, stated the way you would want to be quoted. Founders discover on the first pass that they have published the same prediction three ways at three strengths. Pick the one you would defend.
Where it's published. Post link, newsletter issue, podcast episode. The same claim usually lives in more than one place and you will want to point at the strongest one when it resolves.
The resolve date. The date by which the world will have answered. If the prediction has no date, give it one now. "Eventually" is not a prediction, it is a mood, and it should not have been published as a prediction in the first place.
What you'd have to see. This is the field that separates a ledger from a list. Write down, at the time of the prediction, what evidence would count as right and what would count as wrong. "Category average title length under 80 characters in Brand Analytics" is checkable. "Things will be different" is not. Writing the test in advance is what stops you grading yourself generously later, which every founder does and every careful reader can smell.
Status. Open, right, wrong, or partly. Partly is a legitimate outcome and produces the most interesting post of the four.
The two posts it produces
When a row resolves right, the post is not "I was right." Nobody enjoys that post and it does no positioning work. The post is the mechanism you saw that other people didn't, with the February date attached as a clause rather than a headline. "When I wrote in February that the cap would move CTR more than any creative change that year, the reasoning was X. Here's what actually happened and where the reasoning held." The date does the bragging. You do the explaining.
When a row resolves wrong, the post is the correction, and it is worth more than the win. A founder who says in public "I predicted X, Y happened, here is the variable I underweighted" has just demonstrated the one thing no amount of confident content demonstrates: that they update. A prospect reading that post at 11pm on a Sunday learns you will tell them the truth when it costs you something. There is no other format that proves that in under 200 words.
We have watched correction posts underperform on reach and outperform on inbound quality more times than any other single format. They do not travel. They convert the reader who was already deciding.
The scheduled use
The ledger has one recurring job and one triggered job.
Monthly, ten minutes: sort by resolve date, look at anything due in the next six weeks, and put the follow-up in the running order now. This is how the post ships the week the event lands instead of three weeks later when everyone has moved on and the date on your original post has stopped being impressive.
Triggered, the day something structural changes: open the ledger before you open the drafting doc. A platform change, a fee announcement, a competitor exit. Half the rows in your ledger were about exactly this kind of event, and the founder who checks the ledger first publishes "here is what I said in March, here is what happened" while everyone else is publishing the announcement.
That second use is where the ledger pays for itself. The announcement post is the most crowded format on the platform on the day it matters. The dated-prediction post is empty, because nobody else has the receipt.
What it changes about the next prediction
After two or three passes, founders start writing predictions differently. They add the date at the point of writing. They state the test. They stop publishing predictions they would not want to be held to, which removes a category of post that was never doing any work anyway.
The tell that the ledger is working is not a post. It is a founder who can say, without looking, which three of their open predictions are most likely to resolve wrong. That founder is thinking in claims with consequences, which is the entire difference between a person with opinions and a person with a track record.
FAQ
Isn't this the decay pass? The decay pass asks whether a claim is still true. The ledger asks when a claim will be settled and what will settle it. A prediction can pass a decay pass for a year and still be sitting there un-resolved on the date the world answered it.
What if a prediction never cleanly resolves? Then the resolve date is the post. "I said X by Q4. Q4 is here. It's ambiguous, and here's why the question was harder than I thought" is a real post with a real date on it. What you do not do is leave the row open forever.
How many predictions should I be making? Fewer than you think and more than you currently are. One dated, testable prediction a month is enough to build a visible track record over a year. Ten a week is a horoscope.
I've been publishing for two years with no ledger. Do I back-fill? Only the ones you can still find. Spend twenty minutes, pull the five predictions you remember making, give each a resolve date and a test, and start there. Two of them have probably already resolved, which means you have two posts you did not know you owned.
If you are a founder who has been making calls in public and never cashing them, we can build the ledger from your archive in a single voice sync. It is usually the fastest way we know to find a founder's best unpublished post.