The paperwork file every campaign needs
A per-job records structure for generated work: what to capture at delivery, which three records everyone skips, and a retention clock that starts on use.
The rights question never arrives during the project. It arrives fourteen months later, from someone who was not on the project, usually in the form of "legal is asking about the woman in the second shot." By then the person who wrote the prompt has left, the model has shipped two versions, and nobody in the building can say under what terms that shot was made.
Studios that get through that conversation cleanly did one boring thing at delivery: they wrote down what made the asset, under what terms, with whose permission, and kept it next to the file. Studios that do not get through it cleanly are re-deriving all of that from memory while a brand lawyer waits.
This is the job-level file: what belongs in it, and how long to keep it. Per-generation logging is a separate layer underneath it.
What a rights question actually asks
Every version of this query reduces to five questions. Build the file to answer these and you have built the right file.
- What made this? Which model, which version, on which date. Not "an AI video tool."
- What were we allowed to do with the output? The terms in force at generation time, not the terms on the vendor's site today.
- Whose face, voice, likeness or property is in it? And what did they sign.
- What did we tell the audience? Whether the asset carried a disclosure, and where.
- Who approved it going out? A name and a date, not a Slack reaction.
Everything else is production trivia you can reconstruct. These five you cannot.
Why the model version is load-bearing. Output terms and output behaviour both move with the version, and they move silently. A seed is only meaningful against the exact weights that produced it, so a model update quietly invalidates every reproduction you thought you had banked. That is a production problem and a rights problem at once, because the version determines which terms applied. Seeds and reproducibility covers the mechanics; the records consequence is that "model" and "model version" are two fields, not one.
The copyright layer sits underneath. Platform terms of service from major providers assign contractual ownership of outputs to the user, and people read that as settled. It is not the same thing as copyright. The US Copyright Office position is that protection attaches to human contribution — substantial modification, human-created elements, and the creative selection and arrangement of generated material. A contract cannot manufacture a right that statute declines to grant.
The practical consequence for the file: record what the human did. Which shots were re-cut, which frames were retouched, what the selection process was across takes. That record is what a copyright claim would eventually rest on, and it is unrecoverable a year later.
The file itself
One folder per job. Not per client, not per quarter — per job, because that is the unit a rights question arrives about.
2026-08_northfield_autumn-launch/
00_manifest.md
01_brief/ approved brief + rejected directions
02_generation/ prompt log, model versions, seeds, settings
03_licences/ terms in force at generation, per model
04_releases/ talent, voice, property, music
05_disclosure/ label text, where it ran, screenshots
06_approvals/ who signed off on what, dated
07_delivered/ the exact files handed over, checksummed
The manifest at the top is the only part anyone will read under pressure. Keep it to one screen.
| Field | Example entry | Why it is there |
|---|---|---|
| Job ID | 2026-08_northfield_autumn-launch |
Matches invoices and the file tree |
| Delivered | 2026-08-14 |
Starts nothing; see retention below |
| Models used | video model + version, image model + version, voice model + version | Terms and behaviour both track the version |
| Terms captured | 03_licences/ — dated PDF or archive link per model |
Terms in force then, not now |
| Human contribution | "Re-cut from 31 takes; shots 2 and 5 retouched; end card designed in-house" | The copyright basis |
| Likeness present | Yes / No / Synthetic-only | Routes the hardest question fast |
| Releases held | Talent (2), voice (1), location (0 — none needed) | Gaps are visible rather than assumed |
| Disclosure | Label text, and the placements it ran in | Answers the regulator question |
| Approved by | Name, role, date | Ends the "who said yes" thread |
| Usage granted | Territory, channels, duration, exclusivity | The clause the client will misremember |
Usage is the field most often left blank and most often disputed. If your rate card sells rights in tiers, the tier sold belongs here in words, not as a reference to a proposal that has since been superseded. Usage rights in creator contracts and the usage rights definition cover how to write that tier so it survives being read by a third party.
The three records everyone skips
Terms as they stood, not as they stand. Screenshot or archive the licence page on the day you generate. Vendor terms change without a version number and without notice, and "we complied with the terms" is not a defensible sentence unless you can produce the terms you complied with. One PDF per model per job. It takes a minute.
The disclosure record. EU AI Act Article 50 enforcement began in August 2026, requiring machine-readable disclosure on AI-generated content, and the provenance stack around it consolidated fast: the C2PA adoption tracker puts C2PA past 6,000 members and affiliates as of January 2026, Adobe ships Content Credentials by default in GenStudio for Performance Marketing, Microsoft began adding C2PA metadata to Microsoft 365 content in February 2026, and OpenAI shipped layered C2PA and SynthID provenance in May 2026.
The operational trap is that a client who re-encodes your delivery for their CMS can strip credentials without anyone noticing. That is why metadata preservation now belongs in the contract as well as the file — and why the sensible indemnity split makes the client responsible for stripping provenance or distributing without required labels, while you stay responsible for using tools in breach of their own terms. What C2PA records on design files is the detail layer, and writing a disclosure line nobody scrolls past is the copy half.
The rejected directions. Not for compliance — for the follow-up job. Six months on, someone will propose the exact concept the client killed in week one, and without a record you will spend a meeting rediscovering it. One line per killed direction, with the reason.
Retention: a clock that starts on use, not on delivery
The common mistake is dating retention from delivery. Delivery is not when exposure begins; publication is, and the asset can sit unpublished for a quarter and then run for two years.
A clock that behaves:
- Manifest, licences, releases, approvals — keep for the life of the usage grant plus the limitation period that applies to you, then review rather than auto-delete. These are small text files. Storage is not the constraint; finding them is.
- Generation log (prompts, model versions, seeds, settings) — same as above. It is text.
- Source generations and unused takes — keep through the campaign plus one renewal cycle, then prune to the approved masters. This is where the volume is, and most of it will never be looked at again.
- Delivered files — keep indefinitely, checksummed, because "is this the version we approved" is a real question with a cheap answer if you hashed it.
Two rules make the policy survive a busy quarter. Retention is per job, so one expiry decision covers a whole folder. And the file is never the only copy of the delivered asset — the client has that. You are keeping the evidence, which is text, not the material, which is heavy.
Version control for brand creative assets covers the asset side of that split, and legal and licensing basics for AI business content covers the clause set the manifest is designed to satisfy.
Making it a step, not a discipline
Records habits fail when they depend on remembering. Two things stop that.
Keep the working set together while the job is live rather than reassembling it at the end. Asking the agent to save generations to a named project as you go means the keepers and the near-misses are already grouped when you write the manifest, and finding something you made before by description rather than filename is what makes a fourteen-month-old query answerable at all.
Then make the manifest a delivery gate. The invoice does not go out until the manifest has no blank fields. Not because anyone will audit you this quarter, but because a blank field at delivery is a blank field forever, and the only cheap moment to fill it is while the job is still in your head.
FAQ
Do I need this for small jobs?
The manifest, yes. The full folder tree, no. A single dated markdown file with the ten fields above is about five minutes of work and covers the questions that actually get asked. The folder structure earns its keep once a job has talent releases, multiple models, or paid placement behind it.
What if the client generated some of the assets themselves?
Record it as a separate line with the same fields, and mark the ones you cannot verify as unverified rather than leaving them blank. A file that honestly says "client-supplied, terms not seen by us" is far more useful in a dispute than one that implies you checked. It also tends to prompt the client to go and check, which is the outcome you want.
Does any of this change if the work is never publicly disclosed as AI-generated?
Not to the file. Whether a disclosure was required and whether one was made are two separate fields, and both get recorded either way. A campaign that carried no label because none was required still needs that decision written down with the reasoning, because the person asking in a year will want to know it was a decision rather than an oversight.