The OCP Grid Resilience Spec: What AI Data Centers Now Have to Ride Through

What was published

NVIDIA's announcements for the OCP Global Summit, posted on October 12, included two facility documents written with other operators: the Open Data Center Specification v0.7, with AMD, Google and Meta, and the OCP Grid Resilience Specification, with Google, Meta and Microsoft. The second carries the most immediate operational weight. On the Open Compute Project site it is titled Interface Specification Between Hyperscalers and Utility Grid for Disturbance Performance, version 1.0.0, effective September 17, 2026, and its authors are engineers from Google, Microsoft, Meta and NVIDIA.

The document states its motivation directly. It cites a 2024 event in North America in which 1,500 MW of load dropped off the bulk electrical system at once, and a larger event in the Eastern Interconnection on July 22, 2026. When that much demand disappears together, grid frequency and voltage rise, and utilities have started writing stricter interconnection rules for large loads in response. Data Center Frontier's report from the summit quoted NVIDIA's Ian Buck: "AI factories need to be part of the grid, not just consumers but contributors."

What the specification asks of compute load

This first version covers two behaviors. Voltage ride-through means the load stays connected during a voltage dip or swell instead of tripping. Post-fault active power recovery means it returns to its earlier consumption quickly once voltage is back. The operators adopt the convention MISO proposed and say their requirements closely mirror ERCOT's NOGRR 282 proposal.

The commitment covers only the computational load, which the document puts at roughly 70 to 90 percent of a data center's total. Measured at the point of interconnection, compute must stay connected for at least 2 seconds in a moderate sag and for as little as 0.15 seconds in the deepest one, and it may reduce its power while voltage is low. Once voltage returns to the normal band, 90 percent of the pre-fault load has to be back within 2 seconds.

Ramp rates, intra-minute variation and forced oscillations, the load swings that large training runs can produce, are listed as future work for a later version.

Why it matters for an AI data center operator

The detail that matters most on the floor is what the specification leaves out. Cooling load is exempt. The authors explain that most cooling equipment runs on variable frequency drives whose ride-through behavior differs from server power supplies, and that cooling can take minutes rather than seconds to come back after a trip. They argue that compute can keep running on the thermal inertia of the facility until cooling is restored.

That argument is made for the authors' own designs. An operator with dense liquid-cooled racks should know how much inertia their halls actually have: how quickly coolant supply temperature climbs while a CDU pump or a chiller restarts, and which racks reach their thermal limits first. The same summit made the question sharper. NVIDIA's MGX 1.2 contribution describes rack deployments up to 250 kW and fanless liquid-cooled compute trays, which leaves no fans to fall back on.

The compliance work itself sits in power hardware and firmware. The document lists firmware changes to rack power supplies, medium-voltage UPS designs and grid-side reactive power support as mitigations, and warns that a firmware path cannot be assumed for every model. It also proposes that facilities already operating, or already holding interconnection agreements, on a utility's effective date stay exempt for their lifetime, while new capacity complies. Many estates will be mixed for years: new halls that ride through, older halls that switch to backup.

For the teams running training and inference, a grid event is therefore no longer only a facilities matter. A sag that the power path rides through can still appear as a dip in GPU power, a cooling restart and, at worst, a set of failed jobs. Each of those lands in a different tool unless someone has joined them up.

What the operator sees in Sensaka

Sensaka for AI Data Centers keeps power, cooling, accelerators and jobs in one inventory, which is what the morning after a grid event needs. The first questions are concrete, and the AI Cockpit takes them in plain language. Which racks or zones are near their rated power? Is the liquid-cooling loop healthy: temperature difference, flow and leaks? Which training jobs failed, and for what reason? Each question is matched locally to a preset operational question and gets its own board, and one click renders the board as a 30-second data video for the incident review. No external AI model is involved.

Behind the boards, liquid cooling monitoring reads CDU status, supply and return temperatures, pressure differential, flow and leak events from the supported CDU and facility interfaces, and places them beside UPS, PDU and circuit data. A cooling restart can then be lined up against the power event that caused it, rack by rack. This is monitoring: any control or maintenance action stays with the site's approved procedures.

On the compute side, AI workload operations lists jobs from Slurm and Kubernetes with a classified failure reason for each failed job, shows when and where the last checkpoint was written, and records the training time an interruption cost. The CMDB relationships from rack to server, accelerator, job and tenant show which projects were affected, so the follow-up is one operational ticket, synced to ServiceNow or Jira where those run, instead of three separate threads.

Sensaka does not replace the power-quality meters and protection relays at the point of interconnection, which measure voltage at the resolution utilities ask for. Its part is the side of the event the utility does not see: which racks, loops, GPUs and jobs moved, and how long each took to recover. It works with NVIDIA, AMD and other accelerators.

Takeaway

The grid now expects large AI loads to behave predictably for a few seconds at a time. Meeting that is a job for power engineers and equipment vendors. Knowing what those seconds cost an AI factory, in cooling margin, failed jobs and lost training time, is an operations job, and it is far easier when power, cooling and workload data already sit in one record before the next dip.

Frequently asked questions