Reading a file's own account of where it came from

Provenance lives in the file, not in the description

Every image and video carries a container: a header, a set of blocks and a stream of encoded pixels. Tools write into those blocks — camera model, editing software, colour profile, sometimes a signed manifest describing who made the file and what was done to it. The information travels with the file rather than arriving as a claim from whoever sent it.

That is the useful property. A supplier can tell you an image was photographed on a specific camera, and the file can carry a record that either supports or contradicts it. Neither is conclusive, and together they are more than a conversation.

There is a catch worth stating early. The most common thing that happens to a metadata block between creation and publication is that it is removed: social platforms rebuild files on upload, publishing pipelines re-encode images, screenshotting a file produces a file with almost no history. Absence of metadata is unproven, not forged.

What remains is often enough for the question actually being asked. Which tool produced this, was it edited, is there a signed manifest that would be worth verifying, and is the file as small as the size claims suggest.

C2PA and Content Credentials, precisely

The Coalition for Content Provenance and Authenticity publishes a specification for attaching a signed manifest to media. In practice that means an image can carry a cryptographically signed record of the tool that created it, the edits applied afterwards and the identity of the signer, where the platform supports it.

The signature is the point. A manifest without a valid signature is a claim, and a signature can be checked against a certificate. This inspector tells you whether a manifest is present, which is the first step: a file with one is worth verifying properly in a tool that can reach the certificate chain.

Absence proves nothing at all, for the stripping reason above. Most of the images on the web have no manifest and most of them were made by human beings. Reading absence as evidence of generation is the same error as reading a phrase list as evidence of authorship.

And presence proves only that somebody generated and signed a manifest. A manifest asserts an origin; whether that origin is honest is a question for the certificate and, ultimately, for whoever is accountable for the publication.

• Manifest present: worth verifying against its certificate.
• Manifest absent: unproven, and very possibly stripped.
• Tool strings present: a disclosure signal, not a defect.
• Generator names: evidence about the pipeline, not about the truth.

The tool strings are more revealing than the manifest

In practice most of what you learn comes from the ordinary metadata rather than the signed part. EXIF and XMP blocks frequently name the software: Photoshop, Lightroom, Firefly, Midjourney, DALL·E, Stable Diffusion, ComfyUI, Krea, a phone's computational pipeline.

A generator name in a file is a fact about the file that anyone can find in the same way you just did. Treat it as something the eventual audience may discover, and decide how to disclose before publication rather than after a question.

Editing history is equally useful in the other direction. A photograph of an office that claims to be candid but carries a professional colour profile, a raw processor and three rounds of export has been through a pipeline, and pipelines belong to professionals rather than to bystanders.

Resolution against claimed use is the third signal: a 480-pixel file presented as a hero asset has been through at least one lossy round trip, and an upscaled file will show softer edges and a lower effective bit depth than its dimensions suggest.

What the bytes cannot tell you

Nothing about the subject. Whether the person consented, whether the scene was real, whether the depiction is fair: none of that is in a container, and no manifest makes a fabricated image trustworthy. It only makes its origin legible.

Nothing about the truth of the accompanying text. A photograph can be authentic and the caption invented. Provenance covers the file; the claim is a separate document and needs a separate check.

Nothing that survives a hostile pipeline. Metadata is trivially rewritten, and a determined forger will simply remove it. If provenance matters legally, the record has to live somewhere the file cannot be stripped of, tied to a hash of the original that you computed and stored.

So the practical rule is: read the file, record what it says, keep the original and its hash, and decide disclosure per use. For a product mockup, usually no caption is required. For anything depicting a real person, a real event or a capability the product does not have, assume it is.

Stripping, hashing and keeping the original

Metadata is the easiest thing in the world to remove, and it happens by accident more often than on purpose. Export settings, image optimisation in a CMS, a screenshot, a messaging app's re-compression: each produces a file with clean bytes and no history.

If provenance matters to you, the record has to live somewhere the file cannot be stripped of. Keep the original, compute a hash of it, and store the hash with the record rather than with the file. A hash survives re-encoding of the published copy and lets you prove which file a claim refers to.

The retention rule worth writing down: the original is kept until the asset is retired, the published derivative is named in the record, and the hash is stored somewhere that is backed up. Everything else is optional, and these three are what a dispute will actually require.

For a supplier, ask for the original rather than the export. An export with no metadata is not evidence of anything, and the request itself tells you whether the supplier has a pipeline that keeps files rather than one that overwrites them.

Writing a disclosure rule

Provenance becomes a policy at the moment you decide when a generated asset requires a caption. That decision is easier to make once, in writing, than per asset in a hurry.

A workable default: disclose when the asset depicts a real person, a real event, or a capability the product does not have; disclose when a viewer could reasonably form a belief about the physical world from it; do not disclose for abstract decoration, textures and backgrounds where nothing is being asserted.

Write the rule as a question rather than a category, because categories drift. Could a reasonable viewer take this image as evidence of something that did not happen? That question stays useful as tools change and as the team changes.

Then make the disclosure visible in the place the asset is used rather than in a footer. A caption under the image is read; a line in a terms page is not, and the point of disclosure is to reach the person forming the belief.

Third-party assets and stock claims

When a supplier sends an image described as a photograph, the file is the only evidence available. If the metadata names a generative tool, the description was wrong; if it names a camera and a lens, the description is supported; if it names nothing, the description is unverified and should be treated as such.

Stock libraries are the awkward category. Many carry generated content, some label it, some do not, and the licence terms differ from those for photography in ways that matter for advertising. Check the library's policy rather than the file's metadata, then keep a copy of the policy you relied on.

For anything customer-facing, ask the supplier for the original file rather than the export. The request itself sorts suppliers into those with a pipeline and those who screen-shotted something.

Provenance for a whole library

Once an organisation has more than a few hundred assets, provenance becomes a question about a library rather than about a file. The useful practice is to record the fields the tool reads at intake, alongside the licence and the supplier.

That record is what makes an audit possible later. Nobody will re-open ten thousand images, but a table that says which ones carry a manifest, which name a generative tool and which arrived with no metadata at all is queryable, and queries are what audits turn into.

A five-minute provenance check

Drop the file in and read the summary: container, size, whether a C2PA block exists, what the tool strings say. Note anything that contradicts what you were told about the file, because that contradiction is the finding.

If a manifest is present, that is a queue item rather than a conclusion: verify it with a tool that resolves the certificate. If generator strings are present, decide the disclosure before you decide anything else, since that decision can change whether the asset is usable at all.

Check the dimensions against the intended placement, and the format against the pipeline it is going into. A PNG with alpha dropped into a JPEG-only slot is a small problem now and a visible one later.

Then write down the result. Provenance work is only worth doing if the finding outlives the session, and a note that says which file, which date and which tool strings is the difference between a check and a habit.