What Is Data Provenance? Proving Origin, Not Detecting Fakes

A photograph lands on your desk. A document arrives by email. A dataset drops into a shared folder. The first question most people ask is: is this real? The better question is: where did this come from, and has it changed since it left the source?

That shift, from suspicion to origin, is what data provenance is about.

Provenance does not inspect an artefact for signs of tampering after the fact. It records the chain of custody from the moment something is created: who made it, what process produced it, and whether anything altered it in transit. The answer is positive and verifiable. "This came from here, and every change since is accounted for." Not "we couldn't find anything wrong with it."

The W3C Provenance Working Group, formed in 2011, defines provenance as information about the entities, activities and people involved in producing a piece of data or thing, which can be used to form assessments about its quality, reliability or trustworthiness.

Three plain properties follow from that definition.

Signed at source. A record is created at the moment of capture or production, carrying a mark that ties it to its origin. Think of it as a postmark on a letter, except that digital signatures make the mark mathematically verifiable rather than merely assumed.

A tamper-evident chain of custody. Every transfer, transformation or access is logged. If something changes, the log shows it. The chain does not prevent tampering; it makes tampering visible.

Verifiable without a central database. No single custodian has to be trusted with the record. Verification rests on the structure of the record itself, and on the signing identities and key management behind it. Two parties who have never met can check the same record against the same evidence without phoning a registrar.

These three properties make provenance durable. Organisations change, authorities come and go, but a properly constructed provenance record stands on its own.

Detection tools look at an artefact and ask: does this bear the marks of forgery? The question has a structural problem. Every better detector trains a better forger. The race has no finish line.

Provenance skips the race entirely. It does not ask whether a photograph looks real. It asks: was a verifiable record created at the moment of capture, signed by the device or person who made it, and has the chain from that moment to this one remained intact?

The fraud, in most real cases, is not in the pixels. It is in the claim wrapped around them. "This image was taken at location X, on date Y, by person Z." Provenance addresses that claim directly. Detection tools address the image. The two are solving different problems.

Provenance proves a positive: "This came from here, unchanged." A detector proves a negative: "we could not find evidence of manipulation." Those are not the same thing, and under legal or regulatory scrutiny, the difference matters.

The three plain properties map onto a formal model: entity, activity and agent.

An entity is the thing itself: the document, image, dataset or record. It exists at a point in time, with specific content.

An activity is what happened: the capture, the transformation, the transfer. Activities happen over time. They take entities as input and produce entities as output.

An agent is who or what bore responsibility: the device, the person, the organisation. Agents are associated with activities.

PROV-DM, the W3C's PROV Data Model, uses exactly these three concepts. Every provenance statement, however complex, reduces to relationships between entities, activities and agents. "This file (entity) was generated by this capture process (activity) running on this device (agent)." Relationships such as "was generated by", "was attributed to" and "was associated with" connect the three.

The power of this simplicity is that it applies across almost any domain. A photograph, a clinical trial dataset, a financial instrument, a news article: all can be described in entity-activity-agent terms.

Digital signatures sit in the basement of this model. They are not the model itself; they are the mechanism that makes the relationships verifiable. A signature ties an entity to an agent at a specific point in time, and makes subsequent alteration detectable. In practice the signature often covers a fingerprint of the data, a hash, rather than the contents themselves: change one byte and the fingerprint no longer matches, so a recipient can confirm the record is intact without ever seeing the sensitive material. The identity behind that signature can itself be a verifiable credential, a signed claim about who the agent is that any party can check. The model tells you what to record. The signature mechanism tells you how to make it stick.

The two terms often appear together, though they answer different questions.

Data lineage is an internal engineering concern. It maps how data flows through a system: which table feeds which pipeline, which transformation produced which output. Lineage serves data engineers and analysts working inside a single organisation. It answers questions such as "why did this report change?" or "where does this field come from in our data warehouse?"

Data provenance addresses trust across organisational boundaries. It answers questions such as "can I verify, independently of the organisation that sent this, that the data is what they claim?" Lineage is built for internal debugging. Provenance is built for external accountability.

Two adjacent concepts are worth separating clearly.

Data governance sets the policies and responsibilities for managing data within an organisation: who can access what, how long records are kept, what classifications apply. Governance is a framework. Provenance is evidence.

Metadata is descriptive information about data: file size, creation date, author fields, tags. Metadata can be part of a provenance record, but metadata alone is not provenance. A file's "author" field in a Word document is metadata. A cryptographically signed record of who created the file, when, on which device, forming an unbroken chain to the current recipient: that is provenance.

Four related terms, kept straight:

The distinction matters most when accountability is at stake. Metadata can be edited by anyone with file access. Provenance, if properly constructed, cannot be altered without detection.

In 2011, the W3C Provenance Working Group set out to create a shared vocabulary for describing where things came from. The goal was interoperability: if organisations use different systems, a common language lets them exchange provenance information without bilateral agreements on data format.

The group released its final PROV recommendations in June 2013. The centrepiece is PROV-DM, the PROV Data Model: three concepts, entity, activity and agent; a set of relationships between them; and a formal grammar for expressing provenance statements.

PROV is not software. It is vocabulary. Systems can implement it differently; the vocabulary ensures they can understand each other. A provenance record expressed in PROV terms is interpretable by any system that speaks PROV, regardless of who built either system.

That interoperability is the model's lasting contribution. Provenance records that travel between organisations need a common language. PROV provides it.

The synthetic media problem has a familiar arc. New tools make it easier to generate convincing images, audio and video. The media industry, regulators and platform companies reach for detection tools. Researchers publish detection benchmarks. Then the generation tools improve, and the benchmarks expire.

The detection reflex is understandable. Provenance is less visible, more infrastructural. But the durable answer to synthetic media is provenance signed at capture, not detection applied after the fact.

Consider the workflow. A photojournalist takes a photograph. The capture device signs the image and its metadata at the moment of shutter release. The signed record travels with the image through editing, transmission and publication. Any recipient, anywhere in the chain, can verify: this image was captured by this device, on this date, and no alteration has been made to the record since.

Detection tools cannot do this. They can only say whether an image currently bears marks consistent with manipulation. They say nothing about origin, and they say nothing about what the image was before it arrived.

Several governments and media organisations have run pilots and proof-of-concept work in this direction. The approach is not without complexity: camera manufacturers, news agencies, publishers and platforms must participate in compatible ways. The standard vocabulary exists. The implementations are early. The sensible starting point is narrow: one authorised content type, such as official statements or press images, made verifiable, rather than an attempt to label everything else as false.

The same logic applies beyond media. Clinical trial data, financial records, legal documents, supply chain certificates: any domain where data crosses organisational boundaries under accountability pressure is a provenance problem, not merely a detection problem.

Provenance does not detect fakes. It proves origin. If a forger creates a record from scratch, with a fabricated signing identity, the forgery will have provenance of its own. Provenance tells you whether a chain is intact from a known origin; it cannot tell you whether that origin was legitimate if the origin itself is compromised.

Provenance does not tell you the original fact was true. A signed photograph proves the image has not changed since capture. It does not prove the caption is accurate, the scene was not staged, or the metadata reflects reality. Authenticity of origin is a separate question from accuracy of content.

Provenance does not remove the need for identity and governance. A signature is only as good as the management of the identity behind it: who may issue, approve, revoke or rotate the signing credentials is a question provenance assumes an answer to, rather than provides. When the acting agent is autonomous software rather than a person, that question becomes know your agent in its own right. If an authorised account is misused, provenance can show what happened; it cannot substitute for the access control that should have prevented it.

Provenance does not require a central register or a single custodian. This is a feature, often misread as a limitation. Records that depend on one authority to vouch for them are only as trustworthy as that authority. A properly constructed provenance record carries its own evidence: the structural properties of the record, not the goodwill of any one custodian, provide the assurance. What remains load-bearing is the identity layer behind the signatures, which is why governance belongs in the design from day one.

These clarifications matter for anyone specifying requirements. Provenance solves a specific problem: proving origin and chain of custody. Adjacent problems need adjacent tools.

The three properties of provenance are well understood. Signed at source. Tamper-evident chain of custody. Verifiable without a central database. What is scarce is infrastructure that does all three at scale and carries the sealed record across organisational boundaries.

Most organisations have some signing capability. Most have some audit logging. What fails at the seam is the handover: when a record moves from one organisation to another, the chain often breaks. The receiving organisation holds a copy, but not the evidence of how the copy relates to the original. The provenance that existed inside one organisation does not survive the crossing.

The image that fits this gap is a postman carrying a sealed envelope. The postman never looks inside. The seal travels with the envelope. The record of who touched it, and when, is legible at the other end. The recipient does not need to trust the postman; they check the seal. The postman does not need to know the contents; they carry the record.

That is the infrastructure role: sign at source at scale, move the sealed record between parties, and maintain an immutable audit trail of who checked what and when. It sits alongside existing systems. It does not replace document management platforms, content management systems or existing data governance frameworks. It adds the layer that was missing: a verifiable chain across the boundary. Where the surrounding legal process recognises the signatures, the roles and the evidence, such records can be legally binding; the infrastructure is one part of that, not the whole of it.

mintBlue builds this infrastructure. The position is modest and intentional. The property itself, provenance, has been understood since long before June 2013. What has been slow to arrive is implementation at the scale and interoperability that cross-organisational use requires. mintBlue's work is in that gap: the engineering of the handover, the audit trail, the signed record that survives the crossing from one party to the next.

Provenance infrastructure runs alongside what you already have. There is nothing to rip out. Existing systems, governance frameworks, metadata standards and signing tools remain in place. The addition is a layer that makes the chain of custody verifiable at the crossing point, the moment where most accountability failures actually occur.

The practical steps are modular. Identify where data crosses organisational boundaries under accountability pressure. Establish what signing and logging already exist on either side. Identify the gap in the handover. Then address that gap without disturbing the rest.

The question "is this real?" will not go away. But the infrastructure to answer "where did this come from, unchanged?" is buildable, step by step, alongside the systems you already run.