One record. Everyone who asks can check it.

Grid counterparties, auditors, finance, facilities: each one asks what your GPUs did in a different way. Spark-XC hands each of them the same tamper-evident Power Event Record. Spark-XC keeps an attested, tamper-evident record of GPU power-cap changes, whoever makes them.

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

One record, for everyone who asks

Lead · Sites with grid obligations
Show what your GPUs did during a curtailment
AI sites and GPU clouds with grid or curtailment obligations get asked, after the fact, what their GPUs actually did. Each recorded GPU power-cap change gets a Power Event Record, 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.
What this team gets
⏱
Timestamped records — line up against the curtailment window
Δ
Limit before and after — as the GPU reported it
✓
Power Event Record — signed and hash-chained
Explore grid & curtailment →
Audit & Compliance
A change trail you can recompute
Auditors need evidence of what changed and that it hasn't been edited since. Power Event Records sit on an append-only, SHA-256 hash chain; anyone with a copy can recompute it with standard tools.

Every record is signed with Ed25519. Auditors only need the public key.
What this team gets
#
Append-only hash chain — an edit breaks the chain on recompute
✎
Ed25519 signature — check with the public key
✓
Power Event Record — one per recorded change
Explore audit & compliance →
Finance
Figures that trace back to a record
Finance teams get asked to stand behind power figures they can't trace. A Power Event Record shows which GPU changed, when, and to what limit, so a figure in a report can point back to the records it came from.
What this team gets
Δ
Limit before and after — per GPU, per change
⏱
Timestamps — to match against billing periods
✓
Power Event Record — tamper-evident
Facilities
GPU-side records, by timestamp
Facility teams own power and cooling, but rarely see what changed on the GPUs. Power Event Records give them the GPU side, with timestamps they can line up against their own facility data.

Spark-XC records the GPU's own reported power limits and telemetry. It does not include facility or utility meter data.
What this team gets
⏱
GPU-side changes — with timestamps
Δ
Read-back limits — what the GPU reported
✓
Power Event Record — one shared record across teams
Operators
Keep your stack. Add the record.
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 isn't in your workloads' data path. If it goes offline, your GPUs and schedulers carry on, and no Power Event Records are written for that window.
What this team gets
↔
Alongside your tools — nothing to rip out
↺
Changes by other tools — recorded too
✓
Power Event Record — for each recorded change
Explore enterprise →
AI Infrastructure Leaders
One account of GPU power changes
Leaders accountable for AI infrastructure get asked about power from several directions. Power Event Records give one checkable account of which GPU power caps changed, when, and to what.
What this team gets
⏱
Which GPU, when — for each recorded change
Δ
Before and after — as the GPU reported it
✓
Power Event Record — checkable by anyone with a copy
Explore AI & ML →

What auditors get

Each recorded change is a Power Event Record on a tamper-evident chain. 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.

Power-cap change records
Each recorded GPU power-cap change is a Power Event Record on the tamper-evident chain. Anyone can recompute the chain with standard tools.
Power Event Record
Changes by other tools
Records power-limit changes made by other tools, not just its own. Changes made outside your normal process show up in the record.
Out-of-band changes
Incident timelines
Recorded power-cap changes give incident responders a timestamped sequence of what changed on the GPUs. If a record can't be written, Spark-XC flags it.
Timestamped sequence
Signed records
Every record is signed with Ed25519. Auditors only need the public key.
Ed25519
Change management trail
For each recorded change: when, which GPU, the limit before, the requested value where known, and what the GPU read back, recorded as a Power Event Record on the tamper-evident chain.
Tamper-evident chain
Explore audit & compliance →

Send us one power event

We're looking for design partners among AI site operators, GPU clouds, and the audit and finance teams around them. Send us one power event or curtailment scenario and we'll show you the record Spark-XC would keep for it.

Show me the record → Explore the Pipeline