Looking for design partners

Your GPUs cut power.
Can you prove it?

When a grid operator, an auditor, or your own finance team asks what your GPUs actually did, a dashboard screenshot won't hold up. Spark-XC keeps a signed, hash-chained record of each GPU power-cap change: the limit before, the limit after, and when. Anyone with a copy can check it. Spark-XC keeps an attested, tamper-evident record of GPU power-cap changes, whoever makes them.

Per change
One signed record
Ed25519
Signed records
SHA-256
Hash chain
Each record holds GPU & time Limit before Limit after Signature Chain link

The grid asks for less power. Then someone asks you to prove it.

Utilities and grid operators ask large AI loads to cut back when the grid is tight. Cutting GPU power is the easy part. Weeks later, someone asks what your GPUs actually did, and all you have is a log anyone with access could have edited. That's hard to put in front of a grid counterparty, an auditor, or your finance team.

What you usually have
Logs anyone with access can edit
Power changes spread across scheduler, driver, and facility tools
No way to show a log hasn't changed since
What a Power Event Record gives you
One record per power-cap change, whoever made it
The limit before and after, as the GPU reports it
Signed and hash-chained, so an edit shows up on recompute

Records anyone can check

Teams running GPUs are told their power is under control. Few can show it: not to the grid operator asking whether you curtailed, not to the auditor rebuilding what happened, not to finance.

Spark-XC closes that gap. It keeps a Power Event Record for each GPU power-cap change it records: which GPU, when, the limit before, and the limit after as the GPU reports it. It records changes made by other tools, not just its own.

Each record is signed and hash-chained when it's written, so anyone with a copy can check it. The claim stops being "trust us." It becomes "check it yourself."

Before, after, and when The facts people ask about later, kept together in one record
Fits your stack Works alongside the GPU management, scheduling, and facility tools you already run. Nothing to rip out.
Tamper-evident Edit a stored record and the chain stops checking out
W
#
✓
SPARK-XC

Where Spark-XC sits

GPU power limits change for many reasons: schedulers, operators, facility tools, grid events. Spark-XC doesn't replace any of those tools.

It sits alongside them and keeps one record of the changes: which GPU, when, the limit before, and the limit after.

Records changes from other tools
Records power-limit changes made by other tools, not just its own.
Fits your stack
Works alongside the GPU management, scheduling, and facility tools you already run. Nothing to rip out.
Signed and chained
Every record is signed with Ed25519. Auditors only need the public key. Each record is hash-chained to the one before.
AI Infrastructure Power Stack
SPARK-XC
Power Event Records · signed · hash-chained
RECORD
Your GPU, scheduler & facility tools
GPU management · schedulers · operators
CHANGE
Facility & grid
DCIM · BMS · grid programs
FACILITY
GPU hardware
Data-center GPUs
HARDWARE
"Power limits change for many reasons, from many tools. Spark-XC keeps one record of them."

From a power-cap change to a record

Follow one change from request to GPU, and see what Spark-XC writes down along the way. Illustrative, not a real event.

Scheduler or operator
asks for a new
GPU power limit
request
issued
GPU management tool
Spark-XC or
another tool
limit
applied
Driver / OS
passes the change
to the GPU
change
reaches GPU
SPARK-XC RECORD
PER
1 · GPU & time
which GPU,
when it changed
device + time
RECORDED
2 · Limit before
as the GPU
reported it
limit before
RECORDED
3 · Limit after
read back
from the GPU
readback
RECORDED
4 · Signature
Ed25519
signature
signed
ATTACHED
5 · Chain link
SHA-256 link to
the previous record
PER
SEALED · CHAINED
GPU — illustrative
Limit 350W
350W
Limit before
—
Limit after
—
Record
Power limit350W
Before the change
New limit applied
Values are illustrative

One change. One record.

Each record answers four questions: Which GPU, and when? What was the limit before? What did the GPU report after? Has the record been edited since?

GPU & time Limit before Limit after (read back) Signature + chain link PER POWER EVENT RECORD
Each recorded change → one Power Event Record.
01
Which GPU, and when
Each record names the GPU and the time of the change.
✓ RECORDED
DEVICE
> gpu: recorded
> time: recorded
02
Limit before
The power limit the GPU reported before the change.
✓ RECORDED
LIMIT_BEFORE
> source: GPU
> value: recorded
03
Limit after, read back
The limit the GPU reported back after the change, with its telemetry. Records power-limit changes made by other tools, not just its own.
✓ RECORDED
READBACK
> source: GPU
> value: recorded
04
Signed and chained
Every record is signed with Ed25519. Auditors only need the public key. Each record is SHA-256 hash-chained to the one before, so an edit to a stored record breaks the chain on recompute.
✓ SEALED
EVIDENCE_CHAIN
> SIG: Ed25519
> HASH: SHA-256
What a record doesn't claim
Spark-XC records the GPU's own reported power limits and telemetry. It does not include facility or utility meter data. If a record can't be written, Spark-XC flags it, so a Power Event Record doesn't claim more than it holds.

Built to be checked

Public key
All an auditor needs
Ed25519
Signed records
SHA-256
Tamper-evident hash chain
PER
Power Event Record

Asked to prove what your GPUs did? With just the public key, anyone holding your Power Event Records can check them themselves: the signatures are valid, the chain is unbroken, and no record is missing or out of order. Try it on the sample record →

Built for the people who get asked

AI sites with grid obligations
When a utility or grid operator calls a curtailment, show what your GPUs' power limits were, and when they changed. Grid & curtailment →
GPU clouds
One record of power-limit changes across the GPUs you run, whoever made them.
Audit & compliance
A record they can recompute themselves. Every record is signed with Ed25519. Auditors only need the public key.
Finance
Power figures that trace back to a record, not a spreadsheet.
Facilities
GPU-side records of power-limit changes. Facility and meter data aren't included today.
Infrastructure teams
Works alongside the GPU management, scheduling, and facility tools you already run. Nothing to rip out.

What a record answers

A Power Event Record is a small, signed entry written when a GPU power cap changes. It answers the questions people ask later:

  • ✓
    Which GPU, and when? The device and the time of the change
  • ✓
    What was the limit before? As the GPU reported it
  • ✓
    What did the GPU report after? The limit read back from the GPU itself
  • ✓
    Has it been edited since? Recompute the SHA-256 chain and check the Ed25519 signature

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.

SPARK-XC POWER EVENT STREAM · ILLUSTRATIVE
09:14:01.001[REQ] power-limit change requested
09:14:01.004[LIM] limit before · recorded
09:14:01.010[READ]GPU readback · recorded
09:14:01.012[SIG] record signed · Ed25519
09:14:01.013[HASH]a3f8...d291 chained
09:20:44.300[EXT] limit changed by another tool · detected
09:20:44.306[READ]GPU readback · recorded
09:20:44.309[SIG] record signed · Ed25519
09:20:44.310[HASH]f33c...8b02 chained
_

Send us one
power event

We're looking for design partners among AI sites and GPU clouds with grid or curtailment obligations. Send us one power event or curtailment scenario and we'll show you the record Spark-XC would keep for it.

Attested records Tamper-evident chain Recomputable by anyone with a copy