Spectre Research 01

Most AI Forecasting Results Are Fiction

Why we built a forecaster we can't lie to, and why the only number we'll ever ask you to trust is the one we can't tune.

12 min read
Scroll to inspect

Here's a magic trick you can perform with any large language model.

Take a question that resolved last year (say, an election, a product launch, or a court ruling). Ask an LLM pipeline to “forecast” it as if it were still open. Give the pipeline a search tool. Watch it return a beautifully reasoned, supremely confident, correct answer.

Retrospective evaluationIllustrative
Question

Will measurable rain fall in Seattle on Saturday, March 15, 2025?

Forecast cutoff: Mar 14Resolution: YES · Mar 15
Pipeline forecast97%
Brier score0.001

Now check what the search tool actually retrieved. Somewhere in the evidence (often not even quoted, just quietly absorbed into the reasoning) is an article published after the question resolved. The pipeline didn't forecast anything. It looked up the answer, then wrote a rationale in the style of a forecast.

Score a few hundred of these and you get a Brier score that would embarrass a superforecaster. Publish it and you have a result. The result is fiction.

This isn't a hypothetical failure (it's the default failure). Retrospective evaluation (forecasting already-resolved questions, because live ones take months to resolve) is how every LLM forecasting system is developed, and leakage is how retrospective evaluation quietly dies. The cruelest part is that leakage doesn't look like a bug. Leaky pipelines don't crash. They just score better.

01

The two silent killers

Leakage is the first way a forecasting score becomes fiction. There's a second, and it's worse because it doesn't require anything to go wrong.

Suppose your pipeline is genuinely leak-free. You try a prompt variant, and the score improves a little. You try a different ensemble size, a new aggregation coefficient, a tweaked retrieval strategy. Fifty variants later, you report the best one.

Guarded test set

Forking-paths simulator

Illustrative
Trials disclosed01
Best observed Brier0.244
Recent variantsLower is better ↓

Same holdout. More attempts. Only the most flattering result survives.

That number is not a measurement of forecasting skill. It's a measurement of how hard you searched. Statisticians call this the garden of forking paths; quants call it backtest overfitting; everyone agrees it invalidates the result, and almost everyone does it anyway, because the alternative (spending your test set sparingly, like it's expensive) requires discipline that evaporates under deadline pressure.

And here's what's changed: LLMs made trying fifty variants free. You don't even have to do it yourself anymore. An AI coding agent will happily generate and evaluate a thousand pipeline variants overnight, unattended, and greet you in the morning with the best score of the batch. Evaluation multiplicity used to be a temptation. Now it's industrial.

Two failure modes, one common structure: in both cases, the score is real but the meaning of the score has been destroyed, and nothing in the score itself tells you. A leaked fact and a cherry-picked variant both look exactly like skill.

02

Discipline doesn't scale. Architecture does.

The standard defense against both problems is researcher virtue: be careful with timestamps, don't peek at the test set, log your experiments. We think that defense has failed, not because researchers are dishonest, but because the systems doing the developing are increasingly not researchers. When your codebase is written and iterated by AI agents optimizing for green builds and better scores, “be careful” is not a control. The controls have to be machinery the agents can't game.

That belief is the entire design of Supermike, our general-purpose forecasting system. A question about the future goes in; a calibrated probability comes out, with its reasoning, its evidence, and its receipts. The product is an API, not a chatbot. And the LLMs inside it are deliberately not the forecaster (they're researchers, estimators, and reasoners operating inside deterministic machinery that enforces the properties the scores depend on).

Four pieces of that machinery do the work.

Forecast code physically cannot see the future.

Every Supermike forecast is formed “as of” an explicit timestamp, and forecast-forming code has exactly one way to read the world: a point-in-time facade that refuses to return anything dated after that timestamp. There is no clock inside forecast code, and the as-of time is always passed in, so nothing can accidentally anchor to the present. Documents without trustworthy dates are dropped as unsafe rather than admitted optimistically. And every search is snapshotted, so the exact evidence behind any forecast can be replayed, byte for byte, later. This isn't a convention we follow; it's the only read path that exists.

An auditor checks every forecast, and we audit the auditor.

Structural enforcement can't catch everything: a document dated before the deadline can still describe the outcome (timestamps lie; articles get edited). So an automated leakage judge reads every forecast's full trace and flags anything that smells like post-deadline knowledge. Every score we report comes with its audited leakage rate attached, along with a worst-case number where every flagged forecast is scored as a coin flip. Because the judge is itself an LLM, we don't just trust it: we plant synthetic leaks in clean traces at known rates and measure how often the judge catches them. An audit you haven't validated is a vibe.

Every peek at the test set is counted (publicly).

Supermike has a trials ledger: a global, append-only count of every evaluation run against any guarded question set, enforced across every experiment and every agent. It doesn't prevent us from trying variants. It makes trying variants visible and countable, so that “we evaluated against the holdout N times” is a number we publish next to our results. We know of no other forecasting system that discloses this. We think, once you've internalized why it matters, its absence should bother you everywhere you look.

The evaluation harness is the house, and the house doesn't take edits.

The scoring code, the calibration data, and the holdout set are architecturally quarantined from the code being scored. The harness may only ever be modified to become stricter. Our own AI coding agents (which write most of this system) are treated as adversaries of the harness: weakening a test to make a build green is classed as the same offense as reading the holdout. It sounds paranoid until you remember what those agents are optimizing for.

None of this makes Supermike accurate. That's the point worth sitting with: these mechanisms don't add a single basis point of skill. What they do is make the skill measurable, guaranteeing that whatever number comes out means what it appears to mean. We'd rather publish an honest mediocre score than a fictional great one, because only one of those can compound.

03

What a forecast actually looks like

Inside the machinery, the forecasting itself is a faithful mechanization of the superforecasting playbook, the process Tetlock's research found separates good forecasters from pundits. Take a question like “Will SpaceX reach orbit with Starship before 2027?” Supermike's pipeline anchors on reference classes and base rates first (how often do programs at this stage hit dates like this?), decomposes the question into estimable parts, reasons about the specific case using only evidence admitted by the as-of facade, then fans out an ensemble of deliberately diverse estimators (base-rate-heavy, inside-view-heavy, market-anchored, and extrapolative) whose disagreement is the raw material. The estimates are pooled in log-odds space, extremized and recalibrated using coefficients learned on a dedicated calibration split (never the test set, as noted above), and the ensemble's spread becomes an honest confidence band.

One model call is a sample. A forecast is what you get when a pipeline turns many decorrelated samples into a calibrated number.

And what comes back over the API is not a naked probability. Every response carries (numbers below illustrative):

POST /v1/forecast200
Probability

0.XX, with a confidence band

Rationale

the decomposition, the reference classes used, the key evidence, and the red team's strongest argument against the forecast

Provenance

every source, with the timestamp of when it was knowable

Calibration context

how well-calibrated our forecasts have historically been in this question's domain

Resolution criteria

exactly what we understood the question to mean

A reproducibility handle

everything needed to replay this forecast exactly (as-of time, model versions, evidence snapshots)

A probability without receipts is an opinion with a decimal point. The envelope is the product as much as the number is.

04

The scoreboard

Everything above still describes retrospective evaluation (useful for development, and always “suspect until leakage-audited” in our own house style). So here is the stance the whole system builds toward:

The only number we'll ever ask you to trust is the live one.

Every night, Supermike harvests genuinely open questions (questions whose answers do not exist yet), forecasts them, and registers each forecast immutably at the moment it's formed. When a question resolves, the forecast gets scored. Nothing in this loop can be tuned to the answers, because there are no answers to tune to. No retroactive edits, no quiet deletions of embarrassing calls: the registry only appends.

Public registry

Append-only forecast log

Illustrative
Live writer connectededits_allowed=false
Q-91AF
0.63Open
Q-2C7D
0.28Open
Q-44BE
0.71Open
Q-7E03
0.46Open

The live loop is running now, and the track record is accumulating. We'll publish it on a public dashboard, including every forecast, every resolution, and every score, flattering or not.

One more commitment about how we'll report it. On questions where a liquid market or crowd forecast exists, we will not claim “we beat the market,” because cherry-picked victories over a consensus are noise, and everyone in this field should stop publishing them. The honest, decision-relevant question is whether Supermike carries additional information: does blending Supermike with the consensus beat the consensus alone? That's the test we'll run and report, and we'll publish the result whichever way it comes out.

05

What we're not claiming

In the spirit of the whole exercise:

We are not claiming Supermike beats human superforecasters (we don't have the live sample size yet to claim anything, and we won't pretend otherwise). Parts of the system are honestly unfinished: a learned orchestration layer is designed but deliberately deferred until the corpus of scored forecasts is large enough to train it honestly; forecast memory (“have I forecast something like this before, and how did it resolve?”) is built but not yet wired into the forecast path. A Supermike forecast is also materially more expensive than a chat completion (it's an ensemble plus supervisory passes), and we'll publish the cost-versus-accuracy frontier rather than hiding it. And retrospective evaluation has one problem no retrieval discipline can fix: a model whose training data postdates a question may simply know the outcome. It's one more reason the live number is the only real one.

06

Where this goes

Supermike is open source (Apache-2.0) at github.com/jzyzak/delphi. The full methodology, including the leakage-judge validation protocol and the trials-ledger accounting, is in our forthcoming paper.

If you want a probability you can act on, the question to ask any forecaster (human or machine) is not “what's your best score?” It's: what would have stopped you from fooling yourself? This post is our answer. The scoreboard will tell you whether it worked.