Evidence and receipts

A producer result becomes a ledger receipt

A step result describes an operation: what ran, its terminal state, checks and actual observations. A completed job is useful, but it is not yet a ledger record. The ledger validates the producer result, computes declared bindings and records a create-only receipt.

The distinction prevents an authoring tool's success message from becoming the whole proof. A receipt connects a particular result with its inputs, outputs and upstream evidence. Declaring those dependencies matters: the ledger cannot detect a consumed dependency you never told it about.

Retain the bytes the claim used

Evidence binding connects the claim to actual files, versions and context. Current strict verification rehashes retained evidence and checks its bindings. Signatures authenticate exact subjects against independently selected public trust. They do not establish that the source query had the right business meaning.

Keep retained evidence in customer-controlled custody and out of git. Query results, oracle values, report exports and local atlases can contain business values. A fresh source clone may therefore lack the retained proof. Missing evidence must remain missing; recreating a plausible file later does not prove it was bound during the original run.

For an installed project with the required signed evidence and independent public trust, the brief documents this verification path:

❯node .agent-skills/data/ledger/spine.mjs verify --project <project> --evidence --strict --require-signatures --trust-store <public-trust-file>

Carry the original context when the proof is scoped. A changed binding, missing file or unknown signer requires investigation. Do not re-sign edited historical evidence and describe it as the unchanged original proof.

Let changed dependencies make the claim stale

A receipt becomes stale when an observed input, output version or upstream dependency no longer matches the evidence it used. Staleness propagates through dependent receipts. This is a local evidence relationship, not a promise that every remote asset is continuously polled.

The newest failed or refused retry supersedes an older success for evaluation. Selecting a convenient old receipt would conceal the current state. Use the failure to find the affected operation and obtain a new observation through its owning workflow.

Share qualification metadata, keep raw proof local

The exporter verifies the selected signed subject and supporting receipt chain, then emits a closed value-free attestation. It contains bounded verdicts, timestamps, signer information and keyed commitments. Private numbers, group labels, SQL, DAX, paths and raw evidence stay outside that projection.

Hosted is a protected preview. An explicitly authorised push lets it verify and retain the envelope, then return a separately signed acknowledgement. Hosted does not receive enough information to recompute the business comparison. An ACK proves acceptance of the envelope under its bindings, not a new source query.

Write a reviewable handoff

Name the declared scope, observation and expiry times, verification result and evidence-completeness limits. Keep human acceptance explicit. A valid failure attestation can be a truthful handoff; a signed green claim outside its freshness window cannot become current by changing a date. Continue with limits and boundaries before sharing a result.