What content provenance is, how signed manifests and C2PA work, and why provenance — not watermarking — is what makes AI consent enforceable.
Photo via Unsplash
Ask ten platforms how they prove an AI-generated image was authorised and you will get ten answers about watermarking. Watermarking is not the answer. Content provenance is — and the difference decides whether your consent claims survive contact with a regulator, an acquirer or a court.
This explainer covers what a provenance record contains, how signing makes it tamper-evident, why licence status and signature validity must be reported separately, and what breaks when platforms get that last part wrong. We got it wrong ourselves in an early build, which is the most useful part of the story.
In brief
- Watermarks mark pixels. Provenance records circumstances. Different jobs.
- A manifest names creator, boundary-set version, requester and timestamp — signed.
- Signature valid ≠ still licensed. Report both, always.
- Stripping metadata destroys a true record; it cannot forge a false one.
- Provenance is what makes a 48-hour takedown duty achievable instead of aspirational.
Provenance, in the art-world sense, is the chain of custody: who owned this, when, and how do we know. Content provenance applies the same idea to a file. Not "is this image real?" — a question that gets harder every year — but "what does the record say about how it came to exist?"
That reframing is the whole trick. You are not trying to detect synthetic content by inspection. You are attaching a durable, verifiable statement at the moment of creation, when you still know everything worth knowing.
A useful manifest for a licensed-likeness platform carries at least:
| Field | What it answers | Why it matters later |
|---|---|---|
| Creator identifier | Whose likeness is this? | The starting point of any complaint |
| Boundary-set version | Which rules applied? | Rules change; the output must not float |
| Permitted scope snapshot | What was allowed then? | Avoids reconstructing history |
| Requester identifier | Who commissioned it? | Abuse patterns, and refunds |
| Age-assurance state | Was the requester verified? | Card networks and Ofcom both ask |
| Timestamp | When? | Statutory windows are date-anchored |
| Engine version | Which enforcement logic ran? | Lets you scope a fix to affected output |
| Signature | Has this been altered? | Makes the rest worth reading |
Table: the fields a provenance manifest needs to answer the questions that actually get asked, and who asks them.
Engine version is the field people leave out and then wish they had. When we shipped an enforcement fix and moved from engine 1.0.0 to 1.1.0, that field is what would let anyone identify precisely which outputs were authorised under the older logic. Without it, "which images are affected?" has no answer that is not a guess.
A manifest anyone can edit is a rumour. Signing turns it into evidence.
The mechanism is unremarkable and that is a virtue: canonicalise the record, compute a signature with a key only the platform holds, publish a verification endpoint. Change one character and verification fails. You cannot forge a valid record without the key.
Two implementation details worth insisting on. Compare signatures in constant time, or you leak information through timing. And canonicalise properly — if reordering keys in the JSON changes the signature, your verification is brittle in a way that will eventually be reported as a bug by someone who reserialised the record innocently.
What signing does not give you is durability against stripping. Anyone can remove metadata from a copy. The asymmetry is what saves this: a stripped copy is unverifiable, which is the same state as every unlabelled image on the internet. What matters is that a forged authorisation is not producible.
Here is the failure we shipped, found in our own hardening pass, and fixed.
Revocation worked — a creator withdrawing consent stopped all future generation immediately. But every image already issued still resolved through the public provenance endpoint as a live licence, signature valid, no indication that anything had changed.
Technically correct. The signature was valid; the record had not been altered. And completely useless, because anyone checking a copy after the creator withdrew consent would be told, in effect, that it was fine.
That gap made the 48-hour removal duty unmeetable in the case that matters most: the creator changing their mind. A platform that cannot tell you which outputs are no longer authorised cannot act on a report in two days.
The fix separates two things that were quietly conflated:
signatureValid — has this record been altered since issue?licensed — is the permission it records still in force?Revoking a creator, or resolving a takedown, now marks outstanding generations revoked. The verification endpoint returns a licence object with status, timestamp and reason; it withholds the output URL; and it caches nothing. The manifest stays readable so distributed copies remain traceable back to a record that now says withdrawn.
"A signature answers a question about the document. People kept reading it as an answer about the permission. Those come apart the moment someone changes their mind — which is the only moment any of this exists for." — LikeWard engineering desk, hardening review
We also updated our OpenAPI spec and llms.txt to document the distinction, because an agent integrator with no reason to re-check a record will cache the first answer forever.
The Coalition for Content Provenance and Authenticity publishes the open standard, marketed as Content Credentials. It specifies how assertions are bound to media, how signing works and how a chain survives editing. Camera makers and editing tools have been shipping support, and NIST has engaged with provenance as part of its AI work.
If you want a credential other people's tools can read, C2PA is the target. Being honest about what you have built matters more than the choice, though. LikeWard issues a signed JSON manifest, not a C2PA-conformant embedded credential. It answers every operational question — what was authorised, under which rules, still in force? — and it is not the standard. Calling it C2PA because it rhymes would be the kind of claim that unravels in exactly the meeting where it counts.
Three separate pressures, one artifact:
None of them mandate a specific format. All of them need the same underlying facts. Build the record once and you have answered three institutions — which is the argument we made in the card network consent rules guide.
Reporting signature validity as though it means "authorised". The mistake above. Report both fields, name them unambiguously.
Caching verification responses. A revocation must take effect on the next check, not after a TTL expires.
Omitting the engine version. Then a bug fix has no blast radius you can compute.
Requiring an account to verify. The person most likely to check a suspicious image is the person depicted, who has no account.
Calling a proprietary manifest "C2PA". See above.
Treating stripping as fatal. It is not. Understand the asymmetry and stop worrying about it.
Continue with the watermark versus provenance comparison, or see how the record is used in practice in the TAKE IT DOWN Act compliance guide. You can check any LikeWard output yourself on the verification page.