Every interconnection request still active in four US grid operators now has a probability of ever being built, written down before the outcome, each with a date it must settle by. 355 gigawatts under call. The ledger is public, append-only, and today it is completely empty of results — which is the only honest state for a record that started this morning.
MISO, CAISO, NYISO, ISO-NE. Model logistic-v1, trained on 5,436 resolved requests, base rate 21.4%.
Because the alternative is what everyone else does. A backtest is a claim about a past you already saw. The only version of a forecasting record that cannot be edited into looking good is one where the predictions are timestamped in public and the outcomes have not happened yet.
So the interesting part of this page is not the numbers. It is that the numbers are fixed now and I cannot touch them. Come back in 2028 and the same rows will be here with results attached, including the ones that went badly.
Four constraints are enforced by the code that writes the ledger, not by my good intentions:
| rule | what it prevents |
|---|---|
| Append-only | A second call on the same project is refused. No quietly revising a number as the odds change. |
| Outcomes written once | A resolved row cannot be re-resolved. No re-grading a miss into a hit. |
| Deadline required | Every row carries resolves_by. No prediction that stays open forever because it never quite failed. |
| Referee named upfront | Each row names its outcome_source at prediction time — the ISO's own terminal status, captured daily. No choosing the friendly source afterwards. |
The last one is the reason for the daily snapshot archive. Grid operators publish current state and overwrite it in place; nobody keeps yesterday's value. If the referee is a file that can be rewritten, the record is worthless, so the archive captures each queue every morning and the ledger points at it.
The AI buildout story is told entirely in gigawatts. The model, trained on twenty years of what actually happened to requests like these, will not back a single one of them.
| the largest requests under call | ISO | MW | built? |
|---|---|---|---|
| ATLAS COMPLEX — solar + storage | CAISO | 3,200 | 7.9% |
| unnamed — gas | MISO | 2,220 | 26.6% |
| unnamed | MISO | 2,220 | 7.1% |
| unnamed | MISO | 2,015 | 1.4% |
| unnamed — gas | MISO | 1,540 | 10.1% |
| HOLMAN — hybrid | CAISO | 1,500 | 2.1% |
| all 31 requests of 1,000 MW or more | — | — | 12.2% avg |
MISO does not publish project names, which is why so many of the biggest rows are blank. They are identified in the ledger by county, interconnection point and queue date instead.
Across the whole book: 335 of 1,636 requests expected to be built, delivering 63 GW of the 355 GW queued — 17.8% of the advertised capacity. MISO holds 243 GW of that and carries the highest average probability, 26.0%; NYISO the lowest at 4.5%.
Validated walk-forward by queue vintage — trained only on cohorts that had already resolved, tested on the next one, never the reverse. Scored against quoting the base rate, which is the honest benchmark; scoring against zero would flatter it for free.
| measure | value |
|---|---|
| Brier score, model | 0.1540 |
| Brier score, quoting the base rate | 0.1668 |
| skill over the base rate | +7.7% |
| calibration bins covering | 2 of 7 |
Those two rows disagree, and the disagreement is the finding. It ranks well and it quantifies badly. Projects it rates higher do get built more often — that ordering is real and it is worth something. But the numbers themselves are too spread out:
| model says | n | actually built | 95% CI | ok? |
|---|---|---|---|---|
| 0–5% | 794 | 4.3% | 3.1–5.9 | too low |
| 5–10% | 959 | 10.7% | 8.9–12.9 | too low |
| 10–15% | 629 | 14.6% | 12.1–17.6 | ✓ |
| 15–20% | 556 | 19.1% | 16.0–22.5 | ✓ |
| 20–30% | 999 | 27.7% | 25.0–30.6 | too low |
| 30–50% | 809 | 35.0% | 31.8–38.3 | too high |
| above 50% | 352 | 49.4% | 44.2–54.6 | far too high |
When it says 65% it means about 49%. Its confidence outruns its evidence at the top end, and the same over-spreading makes it too gloomy at the bottom. Isotonic recalibration fixed one bin and cost skill, so this is not a mapping that can be patched — it is the model being more certain than the data supports.
Two things I checked before believing that. Non-stationarity: ruled out, the build rate is flat from 22.2% before 2012 to 21.3% after 2017, and a trailing base rate gains 0.16%. And the high bins are thin and concentrated in a few segments, which is the live hypothesis for the over-spreading and the next thing to measure.
The ledger publishes the raw number anyway, because a record that only keeps the parts of the model that work is not a record.
The first version of this ledger was written and thrown away the same morning. Every deadline came straight from the ISO's own proposed completion date — and a stalled project keeps the date it missed. 62 rows carried a deadline already in the past, the earliest 2002. A prediction that was due to settle before it was made cannot be falsified, so those 62 were not predictions at all.
Alongside it, the same mixed-date-format trap that had already
destroyed 84% of the queue dates earlier in this project: 63 rows in
M/D/YYYY among 1,573 in ISO-8601, because the value was
passed through as a string instead of parsed.
Both fixed by parsing each date individually and flooring every deadline two years past the day the call was made. The broken file is kept in the repository rather than deleted, because a correction you cannot check is just a claim. Rewriting an append-only ledger is defensible exactly once — on the day it was created, with nothing resolved and nothing published. From here it is frozen.
Every row, with the probability, the features it was computed from, the deadline and the named referee. 1,636 rows, 476 KB.