Why an AI release calendar should point forward, not backward

The category truth, then the twist

Almost every AI release tracker points backward: it tells you which models already shipped, on which date, with which benchmarks. The twist is that builders rarely need that. The question that drives a roadmap is not "what landed" but "what is next, and when" — and a backward log cannot answer it.

A forward-looking calendar inverts the artefact. Instead of stopping at today's date, it keeps going — attaching a forecast window, blended Polymarket and Kalshi odds, and a Drop Readiness score to releases that have not happened yet. That is the difference between a museum and a weather forecast. One catalogues the past; the other helps you decide what to do this week. This is the whole premise behind the forward-looking timeline: every other tracker shows what shipped, and we show what is next.

What a backward log structurally cannot do

A log of shipped models is genuinely useful for one job — looking up history — but it is structurally incapable of supporting a forward decision. Knowing that a model launched in March tells you nothing about whether the next version lands in three weeks or three months, and that gap is exactly where planning lives.

Consider the three decisions a builder actually faces. Should you ship a feature now on the current model, or wait for the version that is rumoured to be close? Should you gate a capability behind a flag until a frontier drop lands? Should you budget engineering time this quarter for a migration that may or may not arrive? A backward log is silent on all three, because each one turns on a date that has not happened. The limitation is not a missing feature — it is the nature of a past-tense artefact.

There is a second, sharper reason forward beats backward: the past is the most crowded, least differentiated thing on the internet. Search results, model cards, vendor blogs, and dozens of trackers already record what shipped. A backward log competes in a saturated field where the answer is a single authoritative source away. The forward window — the honest, probabilistic "what is next" — is scarce, because it is hard, and that scarcity is precisely where the value sits. For a fair, feature-level look at how a forward calendar differs from a calendar of past launches, see how we differ from release logs and the side-by-side on feature contrast with RadarOnAI.

What forward-looking actually requires

Pointing a calendar forward is not a matter of adding a few "expected" rows. It requires four ingredients working together: a forecast window, prediction-market odds, graded intel, and a readiness score that fuses them — all refreshed hourly so the picture is never stale.

A forecast window, not a fake date

The honest unit of the future is a range, not a pinned day. A forecast window is the date span a model is most likely to ship in, derived by reconciling expected dates with the resolution dates of the underlying markets. When signals agree the window tightens; when they conflict it widens, rather than inventing false precision.

Odds that extend the calendar past today

Prediction markets are the fastest public consensus on timing — they reprice within minutes of a credible leak or denial. Blending Polymarket and Kalshi gives the calendar a forward-pointing probability instead of a guess. Markets are signal, not stakes: we read the odds as a forecast, never as a wager. The mechanics of why this works are covered in the odds that extend the calendar.

A single readiness score

Four signals are hard to sort a board by, so they collapse into one number. Drop Readiness combines blended odds, intel recency, deadline proximity, and market volume — DR = .45 odds + .25 intel + .20 deadline + .10 volume — into a 0–100 estimate, sorted into imminent, expected, and rumoured stages. It refreshes hourly. The full computation lives in the readiness score that powers it; treat any number you see in this post as illustrative, never live data.

How builders use a forward calendar

A forward calendar earns its keep the moment a decision hangs on a date that has not arrived. Three patterns recur: timing a launch around a frontier drop, deciding whether to wait, and pre-writing integration code against a release that is close but not out.

Timing is the obvious one. If a major model is rumoured inside a tight window, you might hold a launch a week so you ship on the new capability instead of yesterday's. Waiting is the inverse: a low, stalling readiness score is permission to stop holding your breath and ship now. And pre-writing is the quiet win — when a release climbs from rumoured to imminent over a few refresh cycles, that trajectory is your cue to draft the integration so you are merging on day one, not starting from a blank file. The tactical playbook for each of these lives in planning around drops; this post is the why, that one is the how.

See the timeline that points forward

The argument is only as good as the artefact, so the fastest way to judge it is to read the live board. It extends past today, ranks every tracked release by Drop Readiness, and shows the Polymarket and Kalshi odds behind each one — refreshed hourly.

Open the forward-looking timeline and look for the releases above today's line: those are the ones a backward log can never show you. That is the entire point of pointing forward.