Use Cases
When the grid asks you to curtail, keep the record
Sites with grid obligations
Cutting power is easy. Proving it is the hard part.
Grid operators and utilities ask large AI loads to cut back when the grid is tight. Cutting is the easy part. Afterward, someone asks what your GPUs actually did, and when.
Spark-XC records each GPU power-cap change it sees, whether your scheduler, your GPU tools, or anything else made it, and seals it into a Power Event Record. Each record is timestamped, so it lines up with the curtailment window. Settlement runs on meters. A Power Event Record backs up the meter; it never replaces it. Spark-XC keeps an attested, tamper-evident record of GPU power-cap changes, whoever makes them.
GPU & time
Limit before
Limit read back
Ed25519 signature
SHA-256 chain
17:00:00 [WIN] curtailment window 17:00–19:00 (from your utility notice)
17:00:04 [CHG] example-node-01:gpu:0–7 limit 700W → 450W
17:00:04 [READ] readback 450W · power draw + temperature recorded
17:00:05 [SIGN] Ed25519 signature added
17:00:05 [HASH] b72e...10ac chained
17:21:40 [CHG] example-node-02:gpu:3 limit changed by another tool · recorded
17:21:40 [READ] readback 500W · recorded
— [NOTE] facility & utility meter data: not included
1
Record per recorded change
Ed25519
Signed records
SHA-256
Hash-chained
Replayable
Next to your meter data
A curtailment, step by step
From curtailment call to a record both sides can check
Show what your GPUs did, in one record both sides can check. Settlement runs on meters. A Power Event Record backs up the meter; it never replaces it.
Step 1
Grid asks to curtail
The utility or grid operator calls a curtailment window.
Step 2
Your tools cut power
Your scheduler or GPU tools lower GPU power caps.
Step 3
Spark-XC records each change
Each change it sees gets the limit before, the limit read back, and a timestamp.
Step 4
PER sealed
Each record is signed with Ed25519 and hash-chained.
Step 5
Utility + operator review the same record
Both sides can line the records up against the window and recompute the chain.
Example scenarios
Example scenarios (illustrative)
Example · Curtailment window
The utility calls a curtailment during peak demand
The utility asks the site to cut load for two hours. Your scheduler lowers GPU power caps. Spark-XC records each change it sees with the limit before, the limit read back, and the time.
What the records would show: each GPU power change in the window, and the readback.
Example · Ramp steps
Load has to come down in steps
A flexibility agreement limits how fast the site may drop load, so the scheduler steps power caps down over several minutes. Each step gets its own Power Event Record.
What the records would show: each step of the ramp, timed.
Example · Settlement question
A curtailment is questioned after the fact
The utility asks whether the site really cut back during a window. The operator pulls the Power Event Records for that window. Anyone with a copy can recompute the chain.
What the records would show: a sequence both sides can recompute, next to the meter data settlement actually runs on.
Example · Utility coordination
A grid counterparty asks for the timeline of a flexibility window
A grid counterparty wants to see how the site's GPUs responded across a multi-hour window. The operator shares the Power Event Records for that window, in order.
What the records would show: one timeline, shared by operator and utility.
How It Works
Power-cap changes in, checkable records out
Alongside the tools that cut power
Works alongside the GPU management, scheduling, and facility tools you already run. Nothing to rip out. Records power-limit changes made by other tools, not just its own.
Your stack
A timestamp on each record
Each record is timestamped, so it lines up with the curtailment window it belongs to.
Evidence chain
Facility & meter data
Spark-XC records the GPU's own reported power limits and telemetry. It does not include facility or utility meter data. Settlement runs on meters. A Power Event Record backs up the meter; it never replaces it.
GPU-side
Ramp steps recorded
Each step of a ramp gets its own record, with the limit the GPU read back.
Telemetry
Evidence for settlement review
Tamper-evident and replayable. Anyone with a copy can recompute the chain. Anchors go to a local write-once directory by default, and can be sent to off-site storage you control.
Evidence chain
One shared account
The utility and the operator can review the same records and recompute the same chain.
Grid · Evidence
Where it fits
From the grid signal to the record
Outside Spark-XC
Grid signal
The curtailment call reaches you from your utility or grid program, through your own process. Records are timestamped so you can line them up against it.
DCIM · BMS · PDU / UPS
Facility data
Spark-XC records the GPU's own reported power limits and telemetry. It does not include facility or utility meter data. You can compare records against your facility data by timestamp.
Your GPU, scheduler & facility tools
Make the change
Works alongside the GPU management, scheduling, and facility tools you already run. Nothing to rip out. Records power-limit changes made by other tools, not just its own.
Spark-XC
Power Event Record
Each recorded change is sealed as a Power Event Record: tamper-evident and replayable. Every record is signed with Ed25519. Auditors only need the public key.
Grid
Send us one curtailment
We're looking for design partners among AI site operators and GPU clouds with grid obligations. Send us one power event or curtailment scenario and we'll show you the record Spark-XC would keep for it.