Verify a dataset-bundle commitment and its Bitcoin time bound.

What a dataset receipt proves

The supplied bundle matches the anchored commitment. Verification recomputes the path-bound Merkle root. A confirmed OpenTimestamps proof establishes that this root existed no later than its attesting Bitcoin block.

Changes are detectable. Altering a file, adding or removing one, or changing a bound relative path changes the recomputed root. A match shows the supplied bundle matches the committed manifest; it does not prove uninterrupted custody.

Each file is independently verifiable. A Merkle inclusion proof lets anyone confirm that one specific file belonged to the certified set without seeing — or trusting you about — any other file in it.

What it does NOT prove

It does not prove the data was lawfully sourced, licensed, or owned. A receipt records that bytes existed at a moment; it does not establish the legal right to those bytes. That is a separate question for your counsel and the relevant forum.

It does not prove the acquisition log is truthful. The log is committed as written. A current digest/root match and confirmed proof establish the committed bytes and Bitcoin time bound, not that the log is accurate, complete, or continuously unchanged.

It does not prove authorship. A fingerprint binds a file to a date, not to an author. Provenance tooling that claims otherwise is a liability; this does not.

It does not prove training or release use. Inclusion in a committed bundle does not show that a model consumed the data, that a named model was produced from it, or that the bundle was the one approved or deployed.

How it works

1. Assemble a bundle. A folder with your dataset under data/, your license and consent documents under licenses/, and an acquisition_log describing where each source came from, when, and under what terms.

2. Hash it locally. Every file is SHA-256'd on your machine and combined into an RFC 6962-style Merkle tree. Online mode sends the manifest (literal relative paths, digests, sizes, and the root) but not dataset file bytes. Path names may be confidential and should be sanitized before submission. The bundle's --name (or --label, when given) is sent too, as the receipt's label, and a public receipt shows it to anyone with the link: use a name that is not confidential. --offline writes an unanchored certificate and manifest and makes no anchoring request.

3. Retain the outputs. The CLI writes certificate.json, certificate.txt, and manifest.json. When a calendar accepts the root, the certificate records the returned receipt identifiers. Supporting documents are represented by paths and digests; the CLI does not upload or publish their contents. See a sample certificate →

Run it in your pipeline

The reference CLI processes a bundle as a build step and emits a human-readable certificate plus a machine-verifiable manifest. Its anchor command can still exit zero with an unanchored certificate after a network or HTTP failure, or when no calendar accepted the root, so a release gate must inspect anchor.status and require anchored.

# Anchor a dataset bundle (submits manifest metadata, not file bytes)
python3 provenance.py anchor --bundle ./my-dataset --name "My Dataset v1"

# Air-gapped: build the receipt + certificate, anchor nothing
python3 provenance.py anchor --bundle ./my-dataset --name "My Dataset v1" --offline

# Re-verify any time — rebuild the root from disk, compare to the certificate
python3 provenance.py verify --cert out/certificate.json --bundle ./my-dataset

# Prove one file belongs to the certified set
python3 provenance.py verify --cert out/certificate.json --bundle ./my-dataset \
        --file data/images/cat_001.jpg

The local verifier can rebuild the Merkle root from a retained bundle and certificate. Bitcoin-time verification also requires retaining a valid OpenTimestamps proof or receipt material; a manifest alone does not establish a Bitcoin timestamp.