Your pipeline can rebuild an output.
Can it prove it was not changed?

The symptoms

• An auditor or customer asks for evidence that a stored report, dataset or model output is the one that was produced, and the answer is a screenshot of a log.
• You can tell whether an artifact matches its hash, but not when that hash existed, so a hash kept in the same database as the artifact proves little.
• The service that writes the logs is also the service that could rewrite them.
• A dispute starts weeks after the fact, and the only record of the output is in a system the other side does not trust.
• Someone edited a file in place, the hash changed, and nobody noticed until a verification failed in production.

Diagnose first: identity, integrity, or time?

These are three different problems and three different tools. Stamping fixes the third one. Buying a timestamp for a problem that needs a signature is a common and expensive mistake.

Most pipelines have the first two partly solved and the third not at all. A hash in the same mutable database as the artifact is a checksum, not evidence; the moment it is committed to a public chain, it becomes something a stranger can check. That is the leg a stamp adds, and it is the only leg it adds.

The fix, in four steps

1. Hash at write time, in the same transaction that stores the artifact. Not in a nightly job: by then the bytes may already have been rewritten by something else.
2. Build a manifest for the run: every artifact hash, plus the run id, the model or code version and the input hash. One hash of the manifest covers the set.
3. Stamp the manifest hash (or a batch of artifact hashes when each one needs its own proof). $0.05 per hash; up to 100 hashes per request.
4. Verify on read and on a schedule: recompute the hash, send it with the stored proof, and treat invalid as an incident rather than a warning.

Code: hash, stamp, store

import { createHash } from 'node:crypto'
import { writeFile } from 'node:fs/promises'

const sha256 = (b: Uint8Array | string) => createHash('sha256').update(b).digest('hex')

// 1. Hash exactly what you are about to store, and store the bytes you hashed.
const artifacts = await Promise.all(outputs.map(async (o) => {
  const bytes = new TextEncoder().encode(o.body)
  return { id: o.id, bytes, hash: sha256(bytes) }
}))

// 2. One manifest per run: what was produced, by what, from what.
const manifest = {
  run_id: run.id,
  produced_at: new Date().toISOString(),
  model: run.model,
  input_hash: run.inputHash,
  artifacts: artifacts.map(({ id, hash }) => ({ id, hash })),
}
const manifestHash = sha256(JSON.stringify(manifest))

// 3. Stamp it. (Pay via your x402 client; see /guides/agents for the wrapper.)
const res = await pay(`${BASE}/v1/stamps`, {
  method: 'POST',
  headers: { 'content-type': 'application/json' },
  body: JSON.stringify({ hashes: [manifestHash], webhook: { url: `${HOOK}` } }),
})
const { stamps, receipt } = await res.json()

// 4. Store proof, manifest and receipt together, next to the artifacts.
await writeFile(`runs/${run.id}/manifest.json`, JSON.stringify(manifest, null, 2))
await writeFile(`runs/${run.id}/manifest.ots`, Buffer.from(stamps[0].ots, 'base64'))
await writeFile(`runs/${run.id}/receipt.json`, JSON.stringify(receipt, null, 2))

The manifest is the artifact that matters. Changing any entry changes its hash, which breaks the proof: that is the property you want, and why the manifest should be written once and never edited.

Code: verify on read

async function assertUnchanged(artifact: { hash: string }, proofPath: string) {
  const hash = sha256(await readFile(artifactPath))
  const out = await fetch(`${BASE}/v1/verify`, {
    method: 'POST',
    headers: { 'content-type': 'application/json' },
    body: JSON.stringify({ hash, ots: (await readFile(proofPath)).toString('base64') }),
  }).then((r) => r.json())

  if (out.status === 'invalid') throw new IntegrityError(out.reason)
  if (out.status === 'pending') return { verified: true, pending: true }
  return { verified: true, pending: false, block: out.bitcoin.height, time: out.bitcoin.block_time }
}

Run this before an artifact is served, exported or used as an input to another step. It is free, it stores nothing, and it returns the block height and time when the proof is complete, which is exactly the sentence an auditor wants: these bytes existed by block N.

Why a manifest, and not a proof per file

A proof per artifact is the strictest option and costs $0.05 each. A manifest is one proof for a set: cheaper, atomic (a run either produced this set or it did not), and easier to hand to a third party, who can verify one .ots and then compare the manifest against the files they were given. Stamp per artifact when each file travels alone and needs its own proof; stamp the manifest when the run is the unit of meaning. Many pipelines do both: a manifest per run, and a proof for the handful of artifacts that leave the building.

Common failure modes

What this does not solve

• Authorship. A stamp does not say who produced the file. Sign it with a key you control, then stamp it.
• Tampering before the stamp. If the bytes were wrong when you hashed them, the stamp proves the wrong thing existed. Hash at the point of production, not after a queue.
• Content truth. The stamp says nothing about whether the report is accurate, only that these bytes existed by a date.
• Legal presumption of the date. That needs a qualified timestamp from a QTSP; a blockchain stamp is admissible in many places but carries no presumption. See Evidence.

Checklist

• Every artifact has a SHA-256 recorded at write time, in the same transaction that stored the bytes.
• Each run has a manifest with the artifact hashes, the model or code version and the input hash.
• The manifest is stamped, and the .ots, the manifest and the receipt are stored together.
• Verification runs on read, and an invalid answer stops the pipeline rather than logging a warning.
• Pending proofs are completed: a webhook, a poll, or /v1/verify, and the finished .ots replaces the pending one.
• The wallet key is in a secret store, and the x402 client has a maximum price it will pay.
• Somebody has written down what the stamp proves, and what it does not, for the auditor who asks.

Questions