Architecture

One change, one Power Event Record

Spark-XC reads each GPU power-cap change from the GPU itself and seals what it finds into a Power Event Record: signed, hash-chained, and checkable by anyone with a copy. Spark-XC keeps an attested, tamper-evident record of GPU power-cap changes, whoever makes them.

Explore the Pipeline → Show me the record
Stack Position

Where Spark-XC sits

Your schedulers, GPU management tools, and facility systems already change GPU power limits. Spark-XC doesn't replace them.

It keeps the record of each change it sees: which GPU, when, the limit before, and the limit after as the GPU reports it. Records power-limit changes made by other tools, not just its own.

Key architectural property
Spark-XC records alongside your tools: each recorded change becomes a signed, hash-chained Power Event Record, without replacing anything you run.
SPARK-XC Record
1 · GPU & time
DEVICE
2 · Limit before
BEFORE
3 · Limit after (read back)
AFTER
4 · Ed25519 signature
SIGN
5 · SHA-256 chain link (PER)
CHAIN
Power-cap changes
CHANGE
Your GPU management & scheduler tools
YOUR TOOLS
Facility & grid tools
FACILITY
GPU Hardware
PCIe x16
If Spark-XC goes offline

Spark-XC keeps the record. Your stack keeps running.

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. If a record can't be written, Spark-XC flags it.

Spark-XC writes a Power Event Record for each power-cap change it records. It isn't in your workloads' data path.

Spark-XC offline: your tools and GPUs carry on, but no Power Event Records are written for that window.

Inside a record

What each part of a record holds

PART 01
GPU and time
Names the GPU and the time of the change, so a record lines up with the event it belongs to, such as a curtailment window.
DEVICE · TIME
PART 02
Limit before
The power limit the GPU reported before the change, read from the GPU through its management interface.
LIMIT BEFORE
PART 03
Limit after, read back
The limit the GPU reports back after the change, with its power draw and temperature. Records power-limit changes made by other tools, not just its own. Spark-XC records the GPU's own reported power limits and telemetry. It does not include facility or utility meter data.
READBACK · TELEMETRY
PART 04
Ed25519 signature
Every record is signed with Ed25519. Auditors only need the public key.
ED25519
PART 05
SHA-256 chain link
Each record is hash-chained to the one before, so an edit to a stored record breaks the chain on recompute. 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.
PER · SHA-256 chain
When things fail

Designed to say when it can't

Spark-XC assumes things will fail. When it can't write a record, it says so, so a gap isn't mistaken for a quiet period.

Missing data is marked
If a value can't be read from the GPU, the record shows it as missing rather than guessing.
Records it can't write are flagged
If a record can't be written, Spark-XC flags it.
Offline means no records
If Spark-XC itself goes offline, no Power Event Records are written for that window.
Your stack keeps running
Spark-XC isn't in your workloads' data path. If it goes offline, your GPUs and schedulers carry on. Records power-limit changes made by other tools, not just its own.
Local anchors by default
Records are anchored to a local write-once directory by default, and anchors can be sent to off-site storage you control.
Checkable by anyone with a copy
Anyone with a copy can re-verify the chain. Rewrites become detectable once anchors sit somewhere the operator can't change.
Technical Detail

The Power Event Record, concretely

Each recorded change becomes one Power Event Record. It holds a timestamp, the GPU, the limit before and after as the GPU reported it, and a SHA-256 hash computed over the entry and the previous entry's hash, which links it into an append-only, tamper-evident chain. Every record is signed with Ed25519. Auditors only need the public key. The example below is schematic: field names are simplified and the values are made up.

// SPARK-XC Power Event Record — schematic, illustrative values { "seq": 14820, "timestamp_us": "2026-01-15T14:02:11.118Z", "device": "example-node-01:gpu:3", "action": "SET_POWER_LIMIT", "limit_before_w": 350, "requested_w": 300, "readback_w": 300, "delta_w": 0, "signature": "ed25519:9c1e...07ab", "prev_hash": "2e57a3...419f", "entry_hash": "f33c91...8b02" // SHA-256(entry || prev_hash) }
Operational Scenario

Recording fast power swings

Large training jobs can swing racks between near-idle and full draw in seconds, and some grid and facility agreements set limits on how fast load can change. When power limits are stepped to smooth a ramp, the hard part is showing afterward how the ramp actually ran.

Each power-cap step in a ramp gets its own Power Event Record, with the time and the limit the GPU reported, so the sequence can be replayed later.

One record per step
Each power-cap step in a ramp is recorded on its own, in order, with its timestamp.
GPU readback on each step
Each record holds the limit the GPU reported back. Spark-XC records the GPU's own reported power limits and telemetry. It does not include facility or utility meter data.
A sequence anyone can check
The steps sit on the tamper-evident chain, so the ramp can be replayed and checked by anyone with a copy.
Go Deeper

Follow one change end to end

Walk a single power-cap change from the GPU to a sealed Power Event Record, and check the record yourself.

View Pipeline Details → Show me the record