The Provenance File

A hash is not a history

A matching file fingerprint answers one question. It does not tell you who made the file, what changed, or whether its claims are true.

Draft for review. Not published. This page is excluded from the public feed and sitemap.

By Sonny Saggar · Drafted 2026-09-22 · Updated 2026-09-22

Two people arrive at a meeting with a file called final.pdf. The pages look the same. One contains a revised number buried in a table. Which copy was approved?

This is a hypothetical document dispute, but the question exposes three separate jobs: identifying bytes, explaining their history, and establishing authority. A system that does the first well can still leave the other two unanswered.

Start with the object

A cryptographic digest is useful for comparing an exact sequence of bytes. Record the algorithm and the digest alongside the file. If a later copy produces a different result, something changed. That comparison does not tell you whether the change was a corrected typo, a different export setting, or a substituted claim. Nor does a matching digest independently establish who approved the content. NIST describes secure hash functions as generating message digests that can detect whether messages have changed. [2]

The operational mistake is asking one technical result to carry the whole argument. A successful integrity check should be presented as an integrity check, with the object and comparison clearly identified. It should not quietly become a green badge saying the document is true.

Give the change a history

W3C's PROV model distinguishes entities, activities, and agents, including relations that describe derivation and responsibility. That vocabulary lets an implementation represent a document, a revision process, and the people or systems involved as separate things. The model represents provenance; it does not establish the truth of every recorded assertion. [1]

Here is an editorial design proposal for the disputed table: retain both versions, identify the changed cells, record the revision activity, and link the approval to the exact version approved. If the approval record is missing, display that gap. Do not substitute the most recent timestamp for evidence of approval.

Make disagreement inspectable

A useful review screen would show the old value, the new value, the source supporting the correction, and the approval state. The reader should be able to open the preserved original from the same screen. Those are proposed acceptance criteria, not a claim that every document tool already provides them.

The distinction matters most when the file leaves its original application. A screenshot of a green check may travel further than the evidence behind it. A portable record needs enough context for a second reader to understand what was checked and what remains unknown.

Before trusting the next final.pdf, ask three questions: Which exact object is this? What events produced it? What establishes authority for this version? A blank answer is useful information. Hiding it behind a single confidence score is not.