Custody: byte-exact storage and what the digest proves

Byte-exact means byte-exact

When a job produces an output, a worker streams it from the provider straight to storage, hashing as it goes — the bytes are never fully buffered and never rewritten. The digest recorded in the ledger is the digest of exactly what was stored, computed in the same pass that stored it.

This constraint reaches further than the storage layer. The site's image pipeline is structurally prevented from touching asset bytes, because an optimiser that re-encodes an image for display would put a different file next to the digest that describes it.

What the SHA-256 proves — and what it does not

It proves the file you hold is the file we stored

Anyone can hash a file and compare. That check depends on nothing from Wakemark: no account, no API, no trust in us. If the digests match, the bytes are identical to the ones recorded at write time.

It proves the file has not changed since

A single altered byte changes the digest. Re-encoding, cropping, re-compressing or stripping metadata all change it. That is the point.

It does not prove who made the file

A digest is an identity, not an attribution. What links the file to a model, a provider and a moment is the ledger record it is recorded against — and, where the provider embedded one, the C2PA manifest inside the file itself.

It does not prove the content is AI-generated

Wakemark records that a generation request produced this file. It cannot testify about a file it never saw, and it makes no claim about media that did not pass through it.

The sidecar

Beside every stored asset Wakemark writes a JSON metadata document at {storage_key}.wakemark.json — the custody record for that file, in the same bucket as the file.

It contains: the Wakemark build that produced it, the schema version, the job and asset ids, the asset's role, the provider and model, the job input, any seed, the original provider URL, content type, size in bytes, the SHA-256, the creation timestamp, the lineage of parent assets where the job had any, and a C2PA block carrying the detection result.

The document is deterministic: the same asset, job and transfer results always produce byte-identical output, so the copy served by the API can be rebuilt and compared against the copy in the bucket.

When storage fails

A write that fails — rotated credentials, revoked permission, a deleted bucket — fails loudly and surfaces on the asset, with the provider's own URL preserved for rescue where it is still valid. There is no silent drop and no recorded success for work that did not happen. In a custody product a quietly lost output is worse than an outage.