The EU’s Text and Data Mining exception (CDSM Directive Article 4) lets a rightsholder reserve their works from mining “in an appropriate manner, such as machine-readable means.” A Dutch court has already held that a reservation which is not properly machine-readable does not bind (Rechtbank Amsterdam, 30 Oct 2024, ECLI:NL:RBAMS:2024:6563 — a TDM / media-monitoring case, currently under appeal). So the open question is no longer whether reservations must be machine-readable. It is what the machine reads.
There are two ways to answer that, and the choice is load-bearing for every layer built on top.
Two designs
Payload. The reservation contains the terms. The robots-adjacent file, the TDMRep record, the metadata field — each carries the conditions inline: who may use the work, for what, at what price, under which jurisdiction, until when. The reader parses the terms out of the file.
Pointer. The reservation references a separate, signed record where the terms actually live. The file carries a stable URI; the reader dereferences it to a verifiable artifact — a credential, signed by an identifiable issuer, that states what was reserved or granted, to whom, on what date, with a revocation path.
Both satisfy “machine-readable.” They diverge on everything that happens next.
Why payload doesn’t hold up
A reservation is not a static fact. It changes — terms get renegotiated, a licence is granted to one counterparty and withheld from another, a grant is revoked. Inline payload has no good answer to any of that:
- No counterparty binding. An inline term says “this work is available under these conditions.” It cannot say “this work was licensed to this specific party on this date.” The thing a downstream auditor actually needs — proof of a specific grant to a specific user — is exactly the thing payload can’t express.
- No revocation. Once the terms are inline in a published file, withdrawing or amending them means re-publishing and hoping every cache and every prior reader notices. There is no status to check.
- No signature that survives. An inline term in a fetched file carries the authority of “whoever served the file.” A grant that has to stand up in a regulatory review or a court five years later needs to carry the authority of who issued it, independent of where it was hosted.
- It freezes the schema. If the terms are inline, the format that carries them has to standardise the full vocabulary of licensing — pricing, duration, jurisdiction, attribution, downstream obligations — and freeze it. Every future term is a spec revision.
Why pointer is the robust default
Point the reservation at a verifiable credential — a W3C VC, signed with a key resolvable from the issuer’s domain (did:web), revocation-tracked via a status list, verifiable offline in milliseconds — and each of those problems dissolves:
- The credential is bound to a counterparty and time-anchored: it states the specific grant, not just the standing offer.
- It is revocable without re-publishing anything: the verifier checks a status list.
- Its authority travels with the signature, not the host. Move it, cache it, archive it — it still verifies.
- The reservation format stays tiny and stable: it standardises a URI and a way to verify what’s behind it, not the entire licensing vocabulary. The terms can evolve inside the credential without touching the reservation standard.
- Updates are centralized, not per-asset: because the terms live in the referenced record rather than baked into each file, you change them in one place — re-issue the credential, or flip one bit in the status list — instead of re-editing every work that carries them. Payload forces a per-asset edit; pointer makes rights management bulk-capable, the same way re-pointing a DNS record updates every host that references it.
This is the same architectural choice the web already made elsewhere. DNS points to records, it doesn’t inline them. Crossref and DataCite resolve a DOI to rich, evolving metadata rather than freezing the metadata into the identifier. rightsURI in the DataCite schema is already a pointer. TDMRep’s reservation record is already a place to put one. The machine-readable rights reservation should follow the same instinct: standardise the pointer; let the payload live in a signed, revocable, counterparty-bound record behind it.
Provenance is not a licence
It is worth heading off a common conflation: doesn’t C2PA already do this? No — and the reason is the same asset-versus-transaction distinction.
C2PA (and Content Credentials built on it) describes the asset: who made it, when, with which tools, what its edit history is. That manifest is baked into the file at creation and is the same for everyone who ever opens it. It answers what is this and where did it come from.
A licence is not a property of the asset. It is a relationship between two parties at a point in time — this rightsholder granted this user these specific rights, on this date, under these terms, revocable here. None of that lives in a provenance manifest, and none of it can: the grantee, the bundle of permitted uses, the scope and term, the revocation state, the consideration, the obligations, the lawful basis — all of it is transactional, not a fact about the asset’s origin.
The structural clincher is multiplicity. One asset has one provenance but many licences. The same article can be licensed to one lab for training, to another for retrieval-only, to a third for evaluation — each a different grant with different scope, term, and price. You cannot embed N counterparty-specific, revocable grants into a single manifest stamped into the file. The licensing record has to be a separate, per-transaction object — exactly the signed credential the pointer points to.
So provenance and the receipt compose rather than compete: C2PA proves this is the real thing; the credential proves you are allowed to use it. A C2PA manifest can even carry the pointer — a reference to the rights credential — so the asset and its licence travel together while still living in the objects each belongs in. And none of this is specific to AI training: it is the general shape of any content transaction where the same asset is sold to different buyers under different terms. AI training is simply the first market where the absence of a verifiable receipt grew expensive enough to force the receipt into existence.
What this asks of the standards community
Nothing exotic. The reservation layers — TDMRep, the Article 4 mechanisms, the metadata schemas that carry rightsURI — should treat a verifiable-credential URI as a first-class value of the rights-reservation field, and define how a reader dereferences and verifies it. The credential formats already exist (W3C VC 2.0 reached Recommendation in 2025; did:web and Status List are widely implemented). The work is the seam: agreeing that the reservation points, and that what it points at verifies.
Get the seam right once, and every layer above it — preference signals, transaction protocols, provenance manifests — composes cleanly on top of the same signed record, instead of each re-inventing a way to inline terms it was never designed to hold.
The author runs LicenseFoundry, a Netherlands-incorporated open-infrastructure layer for issuing, verifying, and auditing content-licence credentials. This note argues a standards-design position, not a product; the credential formats it references are open W3C standards. Comments and critique welcome.