The Load That Can Be Asked to Stop: Curtailable Capacity, Contingency Planning and the Questions AI Contracts Should Answer

A data centre that can be asked to stop is a different asset from one that cannot. That difference rarely appears in the brochure. It turns up in the contract.

Flexible demand has become part of the price of grid access for large compute loads. That makes availability partly an energy decision, and energy decisions belong in a continuity plan.

What this edition could and could not establish

Evidence was reviewed through 16:00 UTC on November 2, 2026.

The lead item circulating for this edition — a vendor programme to reduce data-centre electricity demand when grids are under strain — could not be verified against sources this publication can retrieve and re-check. Its figures, terms and commitments are therefore not characterised here, and none are repeated.

The governance question does not depend on that answer. What follows is analysis of how a curtailable workload should be planned for, drawn from published continuity and risk guidance rather than from any single announcement.

The trade, stated plainly

Flexible demand is an exchange. A large load gets permission to connect, and in return agrees to draw less when the system is under pressure.

For a grid operator that is straightforwardly useful. For a customer running production workloads on the other side of the arrangement, it introduces a dependency that no software architecture diagram contains.

Call it what it is: a second availability domain. The first is the platform. The second is the grid.

Why this is a contingency planning problem

NIST's contingency planning guidance for information systems is built on a familiar sequence. A business impact analysis identifies which systems matter, what happens when they are unavailable, and which should be restored first.

That analysis produces the two numbers most continuity conversations turn on: a recovery time objective, meaning how long an outage can last, and a recovery point objective, meaning how much data loss is tolerable.

Curtailment asks the same question in advance, and usually before those numbers have been agreed. How long can this workload be unavailable? What has to be true when it comes back? Who decided?

A supplier's assurance that capacity "can be reduced" answers none of those.

Where the risk frameworks fit

NIST's Cybersecurity Framework 2.0 organises outcomes into six functions: Govern, Identify, Protect, Detect, Respond and Recover.

Two carry most of the weight here. Respond covers what happens during the event. Recover covers restoration, and improvement afterwards.

A grid-triggered reduction is a Respond and Recover event, not a Protect one. Nothing was defended. Something was switched off, on instruction, and now has to be brought back in order.

The framework is voluntary guidance, and NIST is explicit that it is not a checklist or compliance criteria. That is precisely why it is useful in a situation where standard contract terms do not yet exist.

Four requirements before a promise means anything

• Classification. Someone must know which workloads can be deferred, throttled or migrated, and which cannot. A training run and a live customer endpoint behave nothing alike.
• Notice and duration. A ten-minute reduction and a six-hour one are different products requiring different designs. Neither works if nothing in the scheduler can receive the instruction.
• Destination. Shed load goes somewhere — another region, a queue, or nowhere with an accepted delay. That is a capacity decision wearing an energy label.
• Record. If a customer's service level is affected, the operator needs evidence of what was reduced, when, and on whose instruction.

The fourth is where most arrangements will be tested. From the customer's side, a curtailment without a record is indistinguishable from an outage.

Why business customers should care

If your AI workload runs on infrastructure that can be curtailed, your availability assumption is partly a grid decision made by somebody else.

Three consequences follow. Contract terms need to say who bears the cost of a shed event and how it is evidenced. Workload placement needs to separate what must stay live from what can wait. And capacity planning needs a second scenario in which the primary site is partially unavailable for reasons unrelated to software.

None of this is unique to one supplier. Any operator offering flexible demand is offering the same trade, and buyers should expect the terms to become standard rather than exceptional.

Five questions worth asking any AI infrastructure supplier

• Is curtailment in our contract? If capacity can be reduced, the terms should say so before an event, not after one.
• What is shed first? Ask for the workload classification, not the assurance that it will be handled.
• How much notice, for how long? Minutes and hours are different products with different consequences.
• What evidence do we receive? A curtailment record should be retrievable months later, not reconstructed from memory.
• What happens to our queue? Deferred work still has to run somewhere, eventually, inside a deadline.

What remains unknown

• No verified figures, notice periods, duration limits or penalties for the programme in this edition's lead item, because no primary source could be retrieved and re-checked.
• No published methodology for measuring a delivered reduction or attributing it to a specific facility.
• No standard contract language for how a curtailed customer is compensated, credited or notified.
• No market data, intraday or closing, reviewed for this edition, so no stock movements are reported.

Evidence notes and limits

Evidence was reviewed through 16:00 UTC on November 2, 2026.

Three NIST sources support the factual claims above: the Cybersecurity Framework programme page for the six functions, the framework's stated voluntary and non-certifying character, and the quick-start guides that describe implementation varying by organisational size, sector and resources. The contingency planning guide, NIST SP 800-34 Rev. 1, is cited for the business impact analysis and the recovery time and recovery point objectives it establishes.

CISA is cited only for its role in critical infrastructure security and resilience, and for the dependency questions that follow from treating electricity as a shared dependency rather than a facilities line item.

All four are government publications describing their own guidance. None is an independent evaluation, and none measures whether any organisation has implemented it.

No announcement terms, savings, customer outcomes or service-level improvements are asserted. The requirements, consequences, supplier questions and framing are analysis and suggested method, not a tested protocol. The advertisement above is separate from this analysis and is not a source for any claim in it.