Use Cases
Auditable demand response for grid-interactive AI infrastructure
Grid-Interactive AI Infrastructure
When the grid asks you to curtail, prove that you did
Interconnection constraints, curtailment programs, and flexibility agreements increasingly require AI infrastructure to respond to grid signals — and to prove the response. A demand-response event that can't be reconstructed afterward isn't settlement evidence; it's an assertion. When megawatts and penalties are on the line, asserted is not enough.
Spark-XC sits above your GPU, scheduler, and facility systems. Mission Control or your scheduler executes the curtailment; Spark-XC validates it across five independent paths, carries the originating grid-event reference through the action, and commits a Power Event Record tied to that signal. The utility and the operator end up with one verifiable account of what was asked, what happened, and when. Mission Control executes. Spark-XC validates.
1 · GPU Telemetry
2 · Workload Context
3 · Facility & Grid Correlation
4 · Policy Gates
5 · Evidence Chain
17:02:00 [SIG] utility API: curtail 12MW → 9MW, ramp ≤ 0.5MW/min
17:02:00 [REF] grid_event=DR-2026-0418 · ISO program window open
17:02:01 [P1] GPU telemetry verified · fleet 11.9MW drawn
17:02:01 [P2] workload context: 3 training runs, checkpoints safe
17:02:02 [P3] facility correlated · PDU + utility meter agree
17:02:02 [P4] policy gate: DR authority confirmed, ramp limited
17:08:30 [OK] ramp complete · 9.0MW held within tolerance
[HASH] 17:08:31 b72e...10ac chained
17:08:31 [P5] PER committed · grid_event=DR-2026-0418 · replayable
100%
Actions carry a grid-event reference
5
Validation paths per action
1:1
Grid signal ↔ Power Event Record
Replayable
Settlement-ready evidence
Grid Event Lifecycle
From DR signal to a record both sides can verify
Prove you curtailed — one record both sides can verify.
Step 1
Grid DR signal
The utility issues a demand-response curtailment request.
Step 2
Scheduler curtails
The workload scheduler reduces draw to the requested setpoint.
Step 3
Spark-XC carries the grid-event reference
The action is tagged with the originating DR signal ID through validation.
Step 4
PER sealed
A tamper-evident Power Event Record commits the curtailment.
Step 5
Utility + operator reconcile
Both sides settle against the same verifiable record.
Grid Scenarios
Real situations, governed and proven
Scenario · Curtailment Event
Utility issues a curtailment signal during peak demand
The utility API dispatches a curtailment request to bring the site from 12MW to 9MW. The scheduler reduces power; Spark-XC validates the action across paths, correlates the facility meter against the request, carries the grid-event reference through every step, and commits a Power Event Record tied to that exact signal — so the response is provable, not asserted.
Curtailment delivered and proven. PER references the originating grid event.
Scenario · Ramp-Rate Compliance
Synchronized training must shed load without violating ramp limits
A flexibility agreement caps how fast the site may drop load. A synchronized training job would otherwise shed power in a single step. The policy gate enforces a ramp-rate-limited reduction, the GPU telemetry and facility paths confirm each interval, and every step lands on the chain — proving the ramp stayed inside the contracted envelope.
Ramp held within tolerance. Each interval recorded and replayable.
Scenario · Settlement Dispute
Demand-response payment is disputed after the fact
The utility questions whether the contracted megawatts were actually shed during a settlement window. Instead of reconciling fragmented logs, the operator replays the Power Event Records for that grid event — each tied to the originating signal, each independently verifiable against the tamper-evident chain — and the shed profile is settled from one shared, auditable account.
Dispute resolved by replay. Settlement grounded in verifiable evidence.
Scenario · Utility Coordination
Grid partner needs the full timeline of a flexibility window
A grid partner requests the complete record of how the site responded across a multi-hour flexibility window. Spark-XC replays the grid-event timeline — signal received, paths validated, ramp executed, power held, restoration — as an ordered sequence of Power Event Records. Operator and utility review the same independently replayable account.
One verifiable timeline, shared by operator and utility.
How It Works
Grid signals in, verifiable evidence out
Respond to Utility APIs
Spark-XC sits above the systems that execute curtailment — Mission Control, schedulers, and facility controls — so power actions can respond to utility APIs and grid program signals. Mission Control executes the action; Spark-XC governs and proves it.
Policy Gates
Grid-Event Reference on Every Action
The originating grid signal — program window, dispatch ID, requested setpoint — is carried through validation and stamped onto the Power Event Record. Every governed power action can be traced back to the exact signal that triggered it.
Evidence Chain
Facility & Grid Correlation
The facility correlation path reconciles GPU draw, PDU and UPS readings, and the utility meter against the requested setpoint. The recorded action reflects what the grid actually saw at the meter, not just what was commanded upstream.
Facility Correlation
Ramp-Rate-Limited Curtailment
Policy gates enforce contracted ramp rates so load is shed and restored within the agreed envelope. Each interval of the ramp is validated and recorded, proving the site respected the flexibility agreement step by step.
Policy · Telemetry
Settlement-Grade Evidence
Every demand-response action becomes a Power Event Record on an append-only SHA-256 tamper-evident chain (ARIV), independently replayable. The shed profile that backs a settlement claim is reconstructable and verifiable, not asserted.
Evidence Chain
One Shared Verifiable Account
Because each record ties back to the originating grid signal and verifies against the chain, the utility and the operator review the same evidence. Demand response becomes auditable rather than asserted — one account of what was asked, what happened, and when.
Grid · Evidence
Integrates Above Your Stack
From the utility API down to the meter
Path 3 · Facility & Grid Correlation
Utility APIs & grid program signals
Curtailment requests and flexibility dispatches arrive through utility APIs. Spark-XC captures the originating grid event — program window, dispatch reference, requested setpoint — and carries it through validation as the anchor for the resulting record.
DCIM · BMS · PDU / UPS
Facility correlation at the meter
Spark-XC reconciles DCIM and BMS telemetry, PDU and UPS readings, and the utility meter against the commanded setpoint — so the recorded curtailment reflects what the grid actually measured, not just what was requested upstream.
Mission Control · DCGM · Slurm · Kubernetes · Run:ai
Executes the power action
Spark-XC sits above NVIDIA Mission Control, DCGM, and your schedulers — no rip-and-replace. They execute the ramp-rate-limited curtailment; Spark-XC validates each interval and stamps the grid-event reference onto every step.
Path 5 · Tamper-Evident Evidence Chain
Settlement-ready Power Event Records
Each action commits as a Power Event Record on the append-only SHA-256 chain (ARIV), tied to the originating signal and independently replayable — the shared, verifiable account that operator and utility settle against.
Grid
Make demand response auditable, not asserted
Bring a real curtailment or flexibility event from your site and we'll replay its Power Event Record — tied to the originating grid signal, ramp-rate compliant, settlement-ready, and independently verifiable. We work with operators and grid partners to fit Spark-XC above your existing stack.