Security & Trust

Evidence built to survive an audit

Each Power Event Record is written to an append-only, SHA-256 hash-chained ledger and signed with Ed25519. Anyone with a copy can recompute the chain with standard tools.

How the evidence is protected

Tamper-evident by construction, not by promise

Each recorded change is written once to an append-only, SHA-256 hash-chained ledger. Each entry binds the previous entry's hash, 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.

…or check the example yourself →
Append-only, hash-chained
Each Power Event Record links to the prior record's SHA-256 hash. An edit to a stored record breaks the chain on recompute, and a broken chain shows.
Checkable by anyone with a copy
Integrity is checked by recomputing the chain, with no privileged access required. You can try it on an example in your browser.
Signed with Ed25519
Every record is signed with Ed25519. Auditors only need the public key. The SHA-256 hash chain is always present.
Fixed in sequence
Each record's position is pinned by the chain. Editing, reordering, or dropping a stored record produces hashes that no longer match on recompute. Catching a rewrite of the whole chain needs an anchor the operator can't change. Anchors go to a local write-once directory by default, and can be sent to off-site storage you control.
Control mapping

How a Power Event Record maps to control families

A Power Event Record can supply evidence relevant to specific controls in SOC 2 Type II, ISO 27001, and NIST SP 800-53. For each, here's the property that does the work.

SOC 2 Type II
CC6.1
Logical access controls
Records include power-limit changes made by other tools, not just Spark-XC's own, so changes made outside your normal process show up in the record.
SOC 2 Type II
CC7.2
System monitoring
Recorded changes carry the limit before and the limit the GPU read back after, supporting evidence that power-limit changes are monitored. If a record can't be written, Spark-XC flags it.
SOC 2 Type II
CC8.1
Change management
Each recorded power-limit change is sealed with the limit before, the requested value where known, and the GPU's read-back value, providing a tamper-evident change trail.
ISO/IEC 27001
A.12.1
Operational procedures & responsibilities
Records document operational power-limit changes with the GPU, time, and outcome, so you can compare what happened against your defined procedures.
NIST SP 800-53
AU-10
Non-repudiation
The Ed25519 signature and the hash chain bind each record to its place in a tamper-evident sequence. An edit to a stored record is detectable on recompute.
NIST SP 800-53
AU-9
Protection of audit information
Because the ledger is append-only and hash-chained, edits to stored records break 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.
Status

What "maps to" means

Spark-XC hasn't been audited against SOC 2, ISO 27001, or NIST SP 800-53. \"Maps to\" means a Power Event Record can supply evidence relevant to a control, nothing more.

Data handling

Records stay where your hardware is

Spark-XC runs on your own hardware, where your GPUs already are.

Runs on your hardware
Runs on your own hardware. Records are anchored to a local write-once directory by default.
Recorded in place
Records are created next to the hardware they describe. The evidence stays under your control, in your environment.
No required data egress
Spark-XC doesn't need to send your telemetry or records off-site to work. Off-site anchoring is optional and goes to storage you control.

Don't take our word for the integrity — verify it

Recompute an example Power Event Record's hash chain in your browser, or talk to us about how records map to your controls.

Check an example record → Talk to us