Before anyone builds a power plant, they file a request to plug it into the grid. Most of those requests never become anything.
I took every request still waiting in four US grid operators. Each one now has a probability of ever being built, and a date by which it must settle — built, or dead. 355 gigawatts covered.
The ledger is public. I can add rows. I cannot change one. Today it holds no results at all — the only honest state for a record that started this morning.
The four operators are MISO (the Midwest), CAISO (California), NYISO (New York) and ISO-NE (New England).
The usual way to show a model works is to test it on the past. But the past is already known. You can adjust the model until the old answers come out right.
A record written in public before the answers exist is the one kind nobody can tidy up later. So that is what this is. The bad rows will stay too.
Four rules are enforced by the code that writes the ledger, not by my good intentions:
| rule | what it prevents |
|---|---|
| Add only | A second prediction on the same project is refused. No quietly revising a number as the odds change. |
| Results written once | A settled row cannot be settled again. No re-grading a miss into a hit. |
| Deadline required | Every row carries a date it must settle by, in a column named resolves_by. No prediction that stays open forever because it never quite failed. |
| Referee named upfront | Every row names its referee, in a column called outcome_source, the day the prediction is made: the operator's own final verdict. No picking a friendly source later. |
That last rule is why there is a daily archive. Operators publish today's status and overwrite it in place, so nobody keeps yesterday's value.
If the referee is a file that can be rewritten, the record is worthless. So the archive saves each waiting list every morning, and the ledger points at it.
Arguments about AI and electricity are held in gigawatts, so the biggest requests get quoted. The model is trained on twenty years of what happened to requests like these. It will not back a single one of them.
Sizes below are in megawatts, MW. A thousand MW make one gigawatt.
| the largest requests | operator | MW | chance 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, so many of the biggest rows are blank. The ledger identifies them by county, connection point and queue date.
Now the whole set. 335 of the 1,636 requests are expected to be built. They carry 63 GW of the 355 GW queued, or 17.8% of the capacity advertised.
MISO holds 243 GW of that, with the highest average probability, 26.0%. NYISO is lowest, at 4.5%.
The model is logistic-v1. The full history holds 9,643 requests whose fate is known. It learned from 5,433 of them, about one in five of which were built — 21.4%.
It learned only from requests that had already finished, then was tested on the next group. Never the other way round.
The test it has to pass: beat a flat guess of 21.4% for every project.
Each prediction earns a penalty for how far it sat from what happened. Lower is better; zero is perfect.
| measure | value |
|---|---|
| penalty score (its name is the Brier score), the model | 0.1540 |
| penalty score, the flat guess of 21.4% | 0.1668 |
| how much smaller the model's penalty is | 7.7% |
| groups where its numbers matched reality | 2 of 7 |
So it beats the flat guess, by a little. Comparing it against guessing zero every time would have looked better and proved nothing.
Next I split the predictions into seven groups by the probability the model gave. In only 2 of the 7 did its numbers match what really happened.
Those two findings pull against each other. It beats the flat guess, yet its numbers are wrong in five groups out of seven. It gets the order right and the number wrong. Projects it rates higher do get built more often, and that ordering is worth something. But it pushes its percentages too far towards 0% and 100%.
Here are the seven groups: how many projects in each, and the share that got built. The last column is a 95% range: where that true share very likely sits.
| model says | projects | share built | very likely range | the model's number was |
|---|---|---|---|---|
| 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 | about right |
| 15–20% | 556 | 19.1% | 16.0–22.5 | about right |
| 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 |
The bottom row is the damaging one. The model promised better than a coin toss. Only 49.4% were built. Take one example: across the group it rates above 50%, projects it calls 65% are built about 49% of the time.
At the top end it claims more than the evidence supports. At the bottom end, for the same reason, it is too gloomy.
I tried rescaling its numbers (a method called isotonic regression) to fit what happened. That fixed one group and left the model worse overall. So it cannot be patched by shifting numbers. The model is simply more certain than the data allows.
I checked two other explanations first. Has the world changed underneath it? No. The build rate is flat: 22.2% before 2012, 21.3% after 2017. Using only recent history gains 0.16%, which is nothing.
The second check: are the high groups big enough to trust? They are thin, and their projects cluster in a few parts of the queue. That is my best guess so far, and the next thing to measure.
The ledger publishes the raw percentage anyway, weakness and all. A record edited down to the parts 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 operator's own proposed completion date. A stalled project keeps the date it missed.
So 62 rows carried a deadline already in the past, the earliest 2002. Their deadline was gone before the prediction existed. Nothing can prove them wrong. They were not predictions at all.
The same file had a second fault. 63 rows wrote dates as 9/2/2026 and 1,573 wrote them as 2026-09-02. The code never read them as dates; it copied the characters across.
Mixed date formats had already ruined 84% of the queue dates earlier in this project.
Both are fixed. Every date is now read on its own, and every deadline is set at least two years past the day the prediction was made. The broken file is kept in the repository, not deleted, because a correction you cannot check is just a claim.
You may rewrite a ledger like this on one day only: the day you create it, before anything is published. That day has passed. It is frozen now.
Every row gives the probability, the facts behind it, the deadline and the referee. 1,636 rows, 476 KB.