
The two facts I have been shown most often in the last twelve months are the 1,500 MW that disappeared from Loudoun County in 82 seconds during the July 2024 cascade and the PJM capacity price chart that ran from $28.92/MW-day in 2024/25 to $329.17 by 2026/27. Almost everyone I have talked to treats them as separate problems — one a transmission event, one a market event. I think they are the same fact at two timescales, and the reason colocation operators cannot answer either one is that the layer between facility software and the grid does not exist as a product anyone has shipped them.
That is the system we have been building at veriprajna.com/solutions/data-center-grid-interaction, and it is the thing I want to write about honestly here, because the way the industry has been talking about "grid friendly" data centers does not match what I have seen inside the actual facilities and inside the actual protocols.
The Afternoon I Matched the Load Curve to the Firmware
I had been reading the NERC incident review on the Loudoun event for a few hours when the shape of the cascade finally registered. Sixty data centers shedding load inside the same 82-second window is not a coincidence and it is not a coordination failure. It is a counting register in UPS firmware doing exactly what its vendor manual says it does — three voltage disturbances inside a minute, lock out the grid, transfer entirely to backup, and remain there until someone walks to the switchgear and flips it back. The third reclose attempt on the faulted 230 kV line and the third counted depression at the affected substations happened to land in the same instant for that fleet of facilities.
What stopped me was not the mechanism. It was the disclosure gap. No NERC standard required any of those operators to tell PJM that their UPS systems behaved this way. No IEEE document obligates voltage ride-through performance for data center loads the way PRC-024 does for generators. The NERC Large Loads Working Group, sitting under the Reliability and Security Technical Committee, only published its first gap-assessment whitepaper in March 2026, and disturbance ride-through is named in it as a priority gap. The PERC1 load model — Power Electronic Reconnecting and Ceasing — was presented at the NERC Load Modeling Task Force webinar in November 2025, but the empirical data needed to parameterize it for any specific facility cluster sits inside DCIM and BMS systems nobody has been collecting from.
I went into the question expecting a power problem. I came out understanding it was a software-disclosure problem the grid had been pricing in retroactively through its capacity market.
The Loudoun cascade was not sixty operators failing. It was sixty operators behaving exactly as documented, in a regime that had no document.
The Colocation VP Who Could Not Describe His Own Building

A few weeks after that, I spent an afternoon with a VP at a Northern Virginia colocation operator whose Dominion interconnection coordinator had recently asked for the facility's voltage ride-through curve. He did not have one. He had a procurement file with the original UPS model numbers, a BMS that could show real-time tray temperatures, and a binder of FFR commissioning paperwork from the vendor. He did not have anything that could be handed to PJM or to NERC's LLWG when those organizations formalize the disclosure requirement, which they almost certainly will by end of 2026 — that is the explicit target in NERC's Large Loads Action Plan.
The conversation was useful for one specific reason. He was not embarrassed. Nobody had ever asked the question of him before, and the people who would now be asking — the utility's interconnection coordinator, the LLWG, eventually FERC under Docket RM26-4-000 — were going to ask it of him in a regulatory shape rather than a "good to know" shape. He had a 25 MW expansion site under design and a draft GS-5 rate-class quote from Dominion that the Virginia SCC will make official January 1, 2027. The math of GS-5 plus the math of the capacity obligation plus the political math of Senate Bill 253 (which would shift capacity and grid-connection costs onto high-load users ≥25 MW) plus the Piedmont Environmental Council pushing to end the state's data center tax breaks adds up to one operational truth: by next year the same colocation buyer who could not describe his facility's ride-through behavior will have to describe it to the regulator, to the utility, and to his own community.
That is the part I keep telling early-stage colocation buyers about. The compliance regime is not "grid interaction would be nice." It is "by 2027 you cannot operate without being able to describe yourself."
The Week I Spent Inside OpenADR 3.0

Building grid interaction software for data centers means making peace with OpenADR 3.0, the protocol that has effectively won the standardization argument for automated demand response. The 3.0 specification replaced the XML-heavy 2.0b with a REST-based API. There is a maintained open-source Rust implementation (OpenLEADR) funded through 2026. The OpenADR Alliance has published the spec, and Schneider Electric is pushing it through the EPRI DCFlex initiative, which it joined in March 2026 — the same month EPRI launched the Flex MOSAIC classification framework.
The week I sat down to map OpenADR 3.0 event payloads onto a representative GPU job scheduler API was the week I stopped being polite about how far the protocol still is from data center reality. OpenADR was designed for buildings. Its event types know about lighting, HVAC, plug loads, and battery state. It has no event type for GPU cluster curtailment. It has no concept of cooling thermal shift coordinated with workload scheduling. It cannot distinguish a deferrable ML training run from a latency-sensitive inference SLA. The protocol is, today, an envelope. The letter you have to write yourself, and the letter is what brokers between the grid signal and the actual scheduler the facility's compute fabric is running.
That gap matters because PJM's curtailment hierarchy in the post-NCBL regime — Price-Responsive Demand instead of Non-Capacity-Backed Load after the NCBL proposal was panned and pulled — only pays for verifiable curtailment. The operator who can demonstrate, in real time, that the right workloads were shed against the right OpenADR signal earns capacity-market value. The operator who cannot, doesn't. EPRI's DCFlex demonstration in Phoenix in May 2025 — with NVIDIA, Oracle, and Salt River Project — proved that a real workload could sustain a 25% power reduction for three hours, with the result peer-reviewed in Nature Energy. The orchestration software that ran that demonstration is not a shipping product for the colocation market. Not from Schneider, not from Eaton, not from Lancium (whose Smart Response platform is ERCOT-only and tied to Lancium-operated facilities), and not yet from Emerald AI — which is mid-2026's most credible specialist, $68M raised in sixteen months, but optimizing for hyperscaler AI factories with NVIDIA scheduler privilege rather than for multi-tenant colocation environments where the operator does not control the workload mix.
The Math My CFO Asked Me to Defend at the Offsite

The hardest conversation we have had about this product was internal, at a board offsite where my CFO asked me to defend the ratio of what it costs to build the orchestration layer against what a buyer would otherwise pay in capacity obligation alone. A 100 MW colocation facility at $329.17/MW-day in 2026/27 is carrying roughly $12M/year of capacity exposure. The 2027/28 auction cleared at $333.44/MW-day, effectively the cap. IEEFA attributed about 63% of the 2025/26 increase to data center demand, which is also why the Virginia SCC opened the GS-5 rate class and why the state legislature spent the 2026 session arguing about moratoriums before deferring the question to 2027.
The board's question was harder than the buyer's question, because the board has to be persuaded the buyer will choose to spend on the layer rather than absorb the obligation. I came out of that meeting with three numbers I now lean on. The first is the EPRI Phoenix 25% / three-hour demonstration, which says the flexibility exists. The second is Google's January 2026 announcement of 1 GW of integrated demand response across Entergy Arkansas, Minnesota Power, and DTE Energy — including 350 MW of a 2.7 GW contract specifically covered by DR — which says a hyperscaler with in-house tooling can monetize it. The third is the FERC ANOPR under Docket RM26-4-000, which proposes 60-day expedited interconnection studies for flexible loads, with the final action deadline at April 30, 2026. That last one is what turns the math from an internal forecasting exercise into a queue-position prerequisite.
The colocation operator with no in-house equivalent of Google's DR engineering team is the buyer we are built for. The argument I made to the board was that the orchestration layer is not a feature-bundle priced against the capacity bill; it is the artifact that turns the capacity bill from an unpriced regulatory risk into a market position.
The Question I Keep Getting Asked

The question I get most often from energy directors at colocation operators is some version of: do we wait for NERC and FERC to tell us exactly what to build, or do we build something now? The honest answer is that the operators I respect are not waiting. Microsoft's first-half 2026 "pay its way" framework, Google's 1 GW DR commitment, and the Data Center Coalition reversing its prior position on voluntary flexibility programs are all the same signal — the hyperscaler tier has decided the cost of self-regulation is lower than the cost of being regulated. Eaton's $50M Virginia manufacturing investment (beginning 2026) for static transfer switches and PDUs, the Beam Rubin DSX platform with NVIDIA's Vera Rubin reference design, and Eaton's check into Emerald AI all say the hardware side has decided the same thing. The colocation operator who waits is doing so against the consensus of the buyers and the consensus of the suppliers.
What I tell them is to start with the artifact they can build right now without depending on a finalized standard. PERC1-relevant load characterization data exists inside their BMS and DCIM systems; nobody has been collecting it, but it is there. UPS counting logic is documented in the vendor manuals they already own. Thermal storage dispatch ceilings are knowable from existing chilled-water and ice-storage capacity even when the storage was sized for a different reason. Capacity market bid evidence accumulates from existing DR program participation if it has been instrumented. The orchestration layer's first job is to make a data center able to describe itself accurately to the regulator, the utility, and the market — and almost every facility I have looked at in PJM cannot do that today.
What I'd Like to Hear
The reason I am writing this in long form rather than in a launch post is that I do not yet know which parts of what we have built will turn out to matter most when the FERC final rule lands and NERC publishes its first data center load behavior standard. The orchestration mechanics I have the most conviction about — workload-aware curtailment, OpenADR-to-scheduler brokering, thermal storage dispatch coordinated with compute scheduling, capacity market bid optimization, PERC1 data extraction from BMS — are the things I'd most like to compare notes on with operators who are already inside these problems.
If you are running energy strategy at a colocation provider in PJM, sitting on a utility large-load interconnection desk, or thinking through how your Northern Virginia footprint survives the 2027 GS-5 cutover and the FERC final rule, I'd genuinely rather have your operating-floor disagreement than a press round of agreement. The 82 seconds was the warning. The 24-month tenfold capacity-price escalation is the bill. The eighteen months from now to NERC's end-of-2026 deadline is the window in which the operators who solve this will be the operators who get to keep operating.