A supply chain for data

Ship datasets like signed binaries.

A .surx container is a queryable dataset with an Ed25519 signature, encrypted columns, and an audit trail. Verification names the exact file that changed — and a public transparency log makes the proof independent of you.

Apache-2.0 · Python 3.10+ · verify is free, forever · read the threat model

log entry #1042 VERIFIED
dataset
finetune-v3.surx · 3,000 rows
root
9f2a…c41e (sha-256, 11 entries)
changed
chunks/source=vendor/part-000001.parquet
signer
data-team@release-v3
identity
possession of signing key proved
sealed
2026-07-08T14:02:11Z · registry seal
chain
prev 55c1…09be → this 8e7d…f210
This is what your CI sees. Try to sneak a change past it.
The problem

“Which dataset actually trained this model?”

You trained on a dataset a vendor sent you in March. In May, someone edited three rows and re-sent the “same” file.

Nothing in your pipeline noticed. The checksum you kept was for the old version — and even if it had failed, it would only have told you something changed. Not what. Not when. Not who.

Can you prove which file trained your model to an auditor who has no reason to trust your infrastructure?

Why this exists

Data ships naked. Software never does.

Provenance that survives the handoff

Training sets, evals and client deliverables move through vendors, buckets and laptops. A signature proves that whoever holds a given key produced exactly these bytes — long after they left your infra. Publish that key once and it becomes an identity.

Failure that names itself

Checksum mismatch tells you nothing. surx verify reports the exact entry modified, added or removed — and whether the audit log was rewritten. Exit 1 stops the pipeline.

PII travels sealed, data stays usable

Encrypt columns, not files. Recipients query everything else without the passphrase; sidecars are cryptographically bound so they can't be spliced between containers.

Three commands

From DataFrame to public proof.

01 · sign

Seal it locally

Write the container, encrypt sensitive columns, sign with your key.

surx write data.csv trainset.surx surx encrypt trainset.surx pii_col surx sign trainset.surx --key team.key
02 · notarize

Anchor it publicly

One call appends it to the transparency log. The proof no longer depends on trusting you.

surx seal trainset.surx # → seal sf-00001042 · log #1042 # → https://…/s/sf-00001042
03 · verify

Anyone checks, free

Consumers and CI verify offline against the seal, online against the log.

surx check-seal trainset.surx --text # container ✓ content ✓ issuer ✓ bound ✓ registry ✓ # tampered → names the chunk, exit 1
Honest comparison

Why not just a SHA-256?

A checksum answers one question: are these exact bytes unchanged? That is genuinely useful, and if it is all you need, use it — it ships with your OS.

It names the file

A checksum says something changed. surx verify names the exact entry inside the container, and tells you if the audit log was rewritten.

It travels with the data

A detached .sha256 gets separated from its file in real pipelines. Here the signature, manifest and audit trail live inside the artifact.

It proves authorship

A hash says nothing about who produced the data. An Ed25519 signature ties the container to a key you chose to trust.

These tools solve different problems

VersioningLarge-file storageSigned by author Offline third-party verifyColumn-level encryption Evidence inside the artifact
SHA-256 checksum bytes only
Git LFS
DVC
LakeFS
Parquet / Iceberg / Delta
sigstore model-signing detached bundle
SURFRAME

Read that table honestly: SURFRAME is not a versioning or storage layer, and it is not trying to be. Version a .surx container in DVC, store it in LakeFS.

About sigstore, which is the closest thing to this

If you are signing model weights in a Kubernetes pipeline, use sigstore/model-signing instead of this. It is an OpenSSF project with Google and NVIDIA behind it, it signs models represented as directory trees — so it already signs a dataset folder today — and its keyless mode binds a signature to an OIDC identity such as a CI workflow, which is stronger identity than a self-managed Ed25519 key you have to distribute yourself. Rekor is a free public transparency log with real infrastructure behind it. Those are genuine advantages, and a comparison that left them out would not deserve the word honest.

Three differences decide whether you want a .surx instead. The signature is a detached bundle that travels next to the model, where a container carries signature, manifest, indexes, audit log and registry receipt inside one file you can attach to an email. sigstore does not encrypt anything, so PII either ships in the clear or does not ship. And a .surx is a queryable dataset format rather than a signature over opaque bytes: verification names the exact chunk that changed, and the evidence pack maps to Art. 10, 11 and 12. Different jobs. If yours is model weights, the answer above is sigstore.

Pricing

Verification is free. Sealing is the product.

Monthly subscription, cancel anytime. Verification stays free and offline forever — you never need an account, or the registry, to verify a container.
Already purchased? Activate your license key.

Open

$0 forever
  • Unlimited local signing & verifying
  • 10 notarized seals / month
  • Public verification pages & README badges
  • Apache-2.0 library & CLI
Start on GitHub

Pro

$19 / month
  • 500 notarized seals / month
  • Signed log checkpoints (anti-rollback)
  • Email support
Get Pro

Business

$99 / month
  • 5,000 notarized seals / month
  • Everything in Pro
  • Self-hosting support & onboarding
  • Priority fixes
Get Business
Received a .surx file?

Check a seal.

Or offline: surx check-seal file.surx