Document provenance: hashes, receipts and exact-byte release

Document provenance is the record of which inputs, operation, implementation, policy, and actor produced or released a specific artifact. A SHA-256 hash is the anchor because it identifies exact bytes, but it does not prove quality or approval. A useful receipt binds that hash to named evidence and authority, while the release record states where the approved bytes actually went.

What document provenance should answer

When a generated file reaches a customer, board, auditor or downstream system, ask concrete questions:

• Which source revision and structured request produced this file?
• Which operation and implementation version ran?
• What validation was performed on the resulting bytes?
• What losses or exceptions were accepted?
• Who or what policy approved the artifact?
• Did the released bytes match the reviewed bytes?
• Which destination received them, and when?

Provenance does not require exposing confidential source text. It requires stable identities and relationships between the request, activity, artifact, evidence, and authority.

The W3C PROV-O recommendation models provenance using entities, activities, and agents. A document workflow can use a compact domain schema while preserving that separation: inputs and artifacts are entities, generation and release are activities, and services or reviewers are agents.

Begin with content-addressed identity

Hash the artifact immediately after generation or transformation. Record the algorithm, digest, byte count, and media type.

{
  "algorithm": "sha256",
  "digest": "9d…",
  "bytes": 48231,
  "mediaType": "application/vnd.openxmlformats-officedocument.presentationml.presentation"
}

This establishes one narrow fact: any later byte sequence with the same recorded digest is intended to be the same artifact under the chosen hash function. It does not say that the file opens, looks right, contains truthful content, is free of malicious features, or was approved.

Store the hash next to validation and approval records. Do not calculate it only when a user downloads the file, because the value you need is the identity at each lifecycle boundary.

Keep five evidence statements separate

This separation prevents a common escalation error: a valid package becomes “approved,” or an approved file becomes “delivered,” without the event that would justify the new state.

What belongs in a document receipt?

A candidate receipt can include:

• receipt identifier and schema version;
• artifact hash, size, and media type;
• input or source-revision hashes;
• operation name and implementation version;
• policy and operation versions;
• timestamps and runtime environment class;
• validator names, versions, and result hashes;
• diagnostics and loss-ledger references;
• signer identity and signature, if used;
• explicit lifecycle state such as candidate or approved.

Avoid embedding expiring download URLs as the only artifact locator. The receipt should survive storage relocation. A content-addressed identifier can resolve through a controlled service without becoming part of the evidence itself.

Signing changes integrity, not meaning

A digital signature can make tampering detectable and identify the signing key. It does not automatically make every claim in the receipt true or authorized.

Define what each signer is allowed to attest:

• a renderer may attest that it produced the artifact;
• a validator may attest that it ran a named ruleset;
• a policy engine may attest that machine gates passed;
• a reviewer may approve an artifact for a stated purpose;
• a release service may attest to a destination write.

The verifier must also check key status, signature scope, time, revocation policy, and receipt version. A valid signature from an obsolete or unauthorized key is not sufficient authority.

Open Packaging Conventions can carry package signatures, and Microsoft’s OPC overview notes that validating signer identity remains the consumer’s responsibility. An external receipt can be useful even when the document format also supports internal signatures, because workflow events and destination release may occur outside the package.

Prevent artifact substitution

The most important operational rule is that preview, approval, and release reference the same digest.

An artifact-swap failure looks like this:

1. candidate A is rendered and previewed;
2. the reviewer approves “the deck” without an artifact hash;
3. the system regenerates candidate B;
4. B is delivered under A’s approval record.

The interface may show the same filename and title, but the bytes differ. Approval must become stale whenever generation, repair, normalization, metadata editing, or conversion changes the hash.

Bind reviewer actions to both the artifact digest and policy version. If policy changes after approval, decide explicitly whether the approval remains valid.

Record release as its own event

Release is not a property added to a file. It is an event connecting an approved artifact to a destination under authority.

A release record should state:

• approved artifact digest;
• destination identifier and type;
• authorization decision and actor;
• delivery method and timestamp;
• idempotency key;
• provider response or immutable destination revision where available;
• final outcome: delivered, offered, rejected, or unknown.

Do not claim destination acceptance when the provider only accepted a request. A 202 Accepted can mean processing will happen later. Preserve provider status and reconcile asynchronously.

Handle replay and stale receipts

Receipts may be replayed accidentally or maliciously. Protect state-changing actions with unique identifiers, idempotency, and current authorization checks. A receipt from last quarter should not authorize release today if the reviewer lost access, the policy changed, or the destination binding was replaced.

Verification should answer:

1. Is the receipt structurally valid?
2. Does its signature verify under an authorized key?
3. Does it reference the artifact in hand?
4. Is the policy version acceptable now?
5. Is the approval still active for this purpose and destination?
6. Has this release event already occurred?

Minimize sensitive provenance data

Hashes can still reveal information when the source space is small, and identifiers can expose tenant structure. Keep public receipts minimal. Store confidential source manifests and detailed validator output in an access-controlled evidence system.

Prefer hashed or opaque references to full prompts, source text, credentials, or storage paths. Define retention independently for artifacts, receipts, previews, and logs; they have different operational and privacy value.

Rehearse substitution, replay, and correction

Provenance controls are easiest to trust when they have demonstrated the failures they claim to prevent. Start with a generated candidate, its validation record, and an approval bound to the candidate digest. Replace the downloadable file with different bytes while leaving its name and metadata unchanged. Release must fail because the observed digest no longer matches the approved identity.

Next, replay the original approval against a regenerated artifact. Even if the new document looks equivalent or contains the same visible text, different bytes require a new evidence chain unless policy explicitly governs a normalized semantic identity. Most Office and PDF workflows should use exact bytes at release because package metadata, relationships, signatures, and embedded resources can change without obvious visual differences.

Test stale policy and authority too. A receipt produced under an older validation profile may remain historically authentic while no longer satisfying the current release rule. A valid signature from a runtime evidence key should not become a reviewer approval. Record the signer’s scoped authority, key version, policy identity, and decision type so verification can distinguish integrity from permission.

Correction needs a new linked event, not a rewritten history row. Preserve the superseded artifact digest and release record, state why correction was required, validate and approve the replacement, and link the new destination action to its own idempotency key. Recipient acceptance, if measured, belongs after delivery and should identify the exact released artifact.

These exercises produce useful operational evidence: the system rejected substitution, replay, stale policy, and an unauthorized signer while preserving a complete correction chain. A statement that the system uses hashes is weaker because it does not show where those hashes are checked or which decisions they govern.

Implementation checklist

• Hash inputs and outputs at every material transformation.
• Name the hash algorithm, byte count, and media type.
• Bind validation results to the exact artifact digest.
• Treat signing keys as scoped authorities, not universal trust.
• Invalidate approval when artifact or policy identity changes.
• Record release as a destination event with idempotency.
• Distinguish request acceptance from delivery and recipient acceptance.
• Make replay and stale-policy checks explicit.
• Keep confidential content out of broadly accessible receipts.

Runstamp’s verification evidence binds each result to the exact output hash and marks evidence stale when the hash, profile, rules or renderer change; provenance operations report common/REPLAY_DETECTED and common/SIGNATURE_INVALID. The governance lifecycle separates generated candidates from reviewed and released bytes.