A metadata preservation clause for delivery
A client who re-encodes your master and strips its credentials owns the compliance gap that follows. The clause and delivery spec that assign that risk.
The clause most delivery contracts are missing has nothing to do with who owns the file. It covers what still has to be attached to the file after the client's own systems have finished with it.
Here is the sequence that creates the problem. You deliver a signed master with its provenance manifest intact. The client's CMS ingests it, transcodes it to the house profile, and writes out a new file. The manifest does not survive the transcode. The asset goes live carrying no machine-readable indication that it was generated. The obligation that gets breached is the publisher's, not yours. But your invoice is the one attached to the file, and the first email you receive will assume those two facts are connected.
Why this became a contract question in 2026
Provenance metadata moved from a nice-to-have to a thing with a date on it. The EU AI Act's Article 50 transparency obligations, which require machine-readable disclosure on AI-generated content, reached enforcement in August 2026. Independently of statute, the infrastructure got adopted fast enough that its absence became conspicuous: Adobe ships Content Credentials on by default in GenStudio for Performance Marketing, Microsoft began writing C2PA metadata into Microsoft 365 content in February 2026, and OpenAI added SynthID watermarking on top of the C2PA credentials it already attached in May 2026.
The consequence for a production shop is narrow and specific. You are no longer delivering a file. You are delivering a file plus a set of assertions about it, and those assertions have a survival problem the moment anything re-encodes the pixels. What a Content Credential actually records covers the manifest structure, and sign, strip, survive traces what happens to each binding through a real pipeline. The short version is that a hard binding breaks on the first genuine edit by design, and whether anything else survives depends entirely on the specific tools in the chain.
Which is exactly why this needs to be written down rather than assumed. A spec that depends on every downstream system behaving correctly is not a spec. It is a hope with a delivery date.
The two-sided indemnity that makes the clause fair
Practitioner drafting guidance on AI terms splits the risk in a way that is worth copying, because it is genuinely even-handed rather than a one-way shield. Numonic's clause set for agency contracts writes the client side of it out in full, and Margolis PLLC's treatment of AI indemnity in commercial contracts explains the principle underneath it: a party resists indemnifying for outcomes it does not control, and the allocation has to follow control to survive negotiation.
The producer indemnifies for using AI tools in breach of those tools' own terms of service. That is your risk, entirely inside your control, and you should carry it.
The client indemnifies for three things: distributing the work without required AI disclosure labels, stripping provenance metadata, and using the deliverable for a purpose that was not disclosed at the point of licensing. All three of those happen after the file leaves you, on systems you cannot see, following decisions you were not part of.
Written that way, the metadata clause stops reading as you covering yourself and starts reading as each party owning what they actually control. That framing is what gets it signed. A clause that only protects the supplier gets negotiated out; a clause that allocates each risk to whoever can prevent it survives legal review, because it is defensible in both directions.
The delivery spec
Metadata preservation only means something if the contract says what the metadata is. Attach a spec, name it in the clause, and keep it short enough that a client's ops team will actually read it.
| Item | What it is | Why it has to survive |
|---|---|---|
| Signed master | The delivered file with its manifest attached | The reference copy any later dispute is measured against |
| Sidecar manifest | The provenance record exported alongside the master | Recoverable if the embedded copy is lost to a transcode |
| Production record | Model names and versions, dates, operator, human modification notes | The evidence base for any disclosure or audit question |
| Disclosure copy | The exact wording and placement the deliverable requires | Stops the label becoming a guess at publish time |
| Delivery log | What was sent, when, in what format, to whom | Establishes the state of the file at handoff |
The delivery log is the row that does the actual work in a dispute. Not because anyone reads it, but because it fixes the condition the file was in when it left you. Everything after that is a question about the client's pipeline, and a dated log is what turns that from an argument into a fact.
If you already run a structured handoff, this bolts onto it. A delivery spec that earns repeat orders is mostly the same discipline pointed at a different outcome, and asset naming and version discipline is what makes the log reconstructable six months later instead of a folder of files called final_v3_ACTUAL.
Clause text
Adapt the bracketed terms, have a lawyer in your jurisdiction look at it, and put it in the delivery section rather than burying it in an annex.
Provenance and metadata. Deliverables are supplied with embedded provenance metadata and an accompanying manifest, in the form set out in the Delivery Specification. The Producer warrants that the metadata is present and accurate at the point of delivery.
Preservation. The Client is responsible for preserving the delivered provenance metadata through any subsequent processing, transcoding, hosting or distribution of the Deliverables. Where the Client's systems cannot preserve embedded metadata, the Client will apply the disclosure wording set out in the Delivery Specification at the point of publication.
Modification. Where the Client materially alters a Deliverable, the delivered provenance record no longer describes the published asset, and responsibility for provenance and disclosure of the altered asset passes to the Client.
Allocation. The Producer indemnifies the Client against claims arising from the Producer's use of third-party AI tools in breach of those tools' terms of service. The Client indemnifies the Producer against claims arising from publication without required AI disclosure, removal of provenance metadata after delivery, or use of a Deliverable outside the licensed purpose.
Records. Each party retains its own records of the above for [24] months from delivery.
The modification paragraph is the one people leave out and the one that closes the loop. Without it, a client can re-cut your delivery, publish something you have never seen, and still hold a warranty from you describing a file that no longer exists.
Running it without adding a step
The spec is only sustainable if producing it is a byproduct of how you already work rather than a separate admin job at the end of every project.
Two things make that true. First, keep the cut re-renderable rather than baked. The editor is EDL-based, so the timeline stays live and a re-export against a corrected spec is a re-render, not a rebuild. Iterating on the cut runs through preview: true, which renders a 480p pass at no credit cost with a short per-user cooldown, and the export charge lands once on the version you confirm regardless of how many clips sit on the timeline. The mechanics are in previews and the final export.
Second, capture the production record as you generate rather than reconstructing it afterwards. Model name, version, date and prompt reference are trivial to note at the moment of generation and genuinely painful to recover a quarter later. Tracking credits per client and per deliverable already asks for most of those fields for a different reason, so one sheet can serve both.
Two delivery details worth stating explicitly in the spec because clients ask: exports carry no watermark on any plan, and the default frame rate is 25 fps rather than 24, which matters the moment your master meets a house profile expecting something else.
FAQ
Does a client really breach anything by stripping metadata?
It depends on the jurisdiction, the surface and what the asset is being used for, which is precisely why the clause allocates the risk rather than asserting a legal conclusion. The commercial value is that the conversation happens at signature, when it is a paragraph, instead of after publication, when it is a dispute.
What if the client's CMS genuinely cannot preserve embedded metadata?
Then the fallback paragraph applies and they publish the disclosure wording instead. Most enterprise media pipelines re-encode on ingest as a matter of course, so plan for this as the normal case rather than the exception. Naming the fallback in the spec turns a technical limitation into a documented process, which is the only version of it that survives an audit.
Should the disclosure wording live in the contract or the spec?
The spec, so it can be updated without reopening the agreement. Platform requirements shift, and you do not want a contract amendment every time one of them changes a label. Writing an AI disclosure line nobody scrolls past covers the wording itself, and one disclosure, five destinations covers the case where the same asset needs different labels per platform.
Does this apply to still images as well as video?
Yes, and images are the harder case in practice because they pass through more hands and more resizing pipelines before they reach a viewer. The clause text works unchanged; the delivery spec needs a row for the derivative sizes the client will generate, since each resize is another chance for the embedded record to disappear.