Prompt and model documentation: a practical checklist for studios

The moment documentation matters is never the moment you are generating. It is three months later, when the client asks which parts of the campaign were AI generated and what the model was given. It is the day a deliverable needs to be reproduced at a new aspect ratio and nobody can find the prompt. It is the week an invoice is disputed, or a broadcaster sends a disclosure form, or a rights question lands and the only evidence is a folder of finals with names like final_v3_REAL.png.

This guide is the checklist we recommend to studios, and it is deliberately short. It lists eight fields per shot, each earning its place because it answers a question someone will actually ask later, and it closes with a workflow that a small team can sustain without turning documentation into a second job.

The eight fields worth recording per shot

1. The prompt. Record the final prompt verbatim, exactly as it produced the accepted image, not a paraphrase and not the first attempt. The prompt is the closest thing generative work has to a source file. You will need it to reproduce the shot, to iterate on it for the next deliverable, and to answer the most common client question of all, which is what the model was actually told. A paraphrase fails at all three, because small wording changes produce different images.
2. The negative prompt, if the tool has one. In tools that support it, the negative prompt carries a real share of the creative decision, since it defines everything the image was steered away from. Reproduction fails without it, and a record that contains the positive prompt alone quietly misrepresents how the image was directed.
3. The tool. Name the product or service the shot was generated in. The same underlying model is reachable through different tools that apply different preprocessing, default parameters and upscaling, so the model name alone does not describe the pipeline. Licence terms and terms of service also attach to the tool, and when a rights question arrives, which tool generated the asset is one of the first facts anyone asks for.
4. The model and version. Record the exact model name and its version or checkpoint, not the brand family. Models change under stable product names, and two versions of the same model given the same prompt and seed can produce visibly different output. Commercial terms and permitted uses can also differ by model and version. A record that says only which product was used will not answer the question a lawyer or a platform actually asks.
5. The seed and core settings. Record the seed, the aspect ratio, and whichever core parameters the tool exposes, such as steps or guidance strength. The seed is the difference between a similar image and the same image. When a client approves a shot and later needs a wider crop, a cleaner variant or a higher resolution pass, the seed plus the prompt is what makes the new render a sibling of the approved one instead of a stranger.
6. The references used. Record every reference that went into the generation: image prompts, style references, pose or depth inputs, and any other conditioning material. For each one, record where it came from and what its rights status is, whether it is owned by the studio, licensed, provided by the client, or generated earlier in the project. This is the field disputes are made of, because references are where other people’s work can enter your pipeline. Be aware of what this field can and cannot establish. Recording a reference at generation time proves that you declared it then, which is a strong, contemporaneous statement. It does not prove what the model did with it internally, and no record can. We explain that boundary in our guide on what provenance can prove.
7. The human edits. Record what a person changed after generation: retouching, compositing, paint work, grading, upscaling and cleanup, in one or two honest sentences per shot. The human contribution is the part of the work that is unambiguously yours, and it is exactly what the US Copyright Office expects applicants to describe when registering work that contains AI material, alongside a duty to disclose the AI generated parts. It is also the part clients undervalue until they see it written down, which makes this field commercial self-defense as much as compliance.
8. The approval decision. Record who approved the shot, when, in which review round, and what exactly was approved. Netflix tells its production partners to share any intended use of generative AI and that written approval is required before proceeding with final deliverables, and client contracts increasingly contain similar language. Internally, this field ends the oldest argument in production, which is whether the version that shipped was the version that was signed off.

Why these eight and not thirty

Every field on this list answers a question that arrives from outside: a client question, a reuse request, a dispute, or a compliance obligation. That external pressure is worth taking seriously, because it is no longer hypothetical.

The German agency association GWA tells its members that when agencies use AI tools, their co-responsibility covers the labelling obligation and the documentation of use. The EU AI Act’s Article 50 requires providers of generative systems to ensure outputs are marked in a machine readable format and detectable as artificially generated, and requires deployers to disclose artificially generated or manipulated content in the deep fake case. Non-compliance with those transparency obligations carries fines of up to 15 million euros or 3 percent of total worldwide annual turnover, whichever is higher, under Article 99. The US Copyright Office ties registration to disclosure. Netflix ties final delivery to written approval.

None of these obligations can be met from memory. All of them can be met in seconds from a per-shot record containing the eight fields above. That is also the test for adding a ninth field: if it does not answer a question that someone outside the team will ask, it is ballast, and ballast is what kills documentation habits.

A workflow a small team will actually sustain

The best checklist fails if it depends on discipline nobody has in week six of a production. These rules keep the habit alive.

Capture at generation time, inside the flow. The person who generates the shot records it, in the same minute, and a shot without a record is not done. Documentation written at the moment of creation is also worth more as evidence, because it predates any dispute it might one day serve in.

Automate what a tool can know. Prompt, negative prompt, model, version, seed and settings are all machine readable at generation time, and a capture integration should write them for you. Reserve human typing for the three things software cannot know: where a reference came from, what was edited by hand, and who approved what.

Keep one record per shot, attached to the asset. A project-level document decays because nobody knows which paragraph belongs to which file. A record that lives with the asset survives renames, handoffs and exports, and it follows the shot through its iterations.

Make approval an entry, not a chat message. A thumbs up in a messaging thread is unfindable in a year. An approval recorded on the shot, with a name and a date, is the difference between an awkward search and a one-click answer.

Spot-check briefly every week. Once a week, someone spends ten minutes opening the records of the shots marked final and checking that the eight fields are filled. This is the entire quality process, and it is enough.

Do not over-engineer. A record that is consistently complete at eight fields beats a forty-field form that the team abandons in the second week. Completeness and consistency are what make a record credible, not length.

What this record can and cannot prove

One honest note to close, because it determines how you should talk about your documentation to clients. A record like the one above proves what was written down, that it has not been changed since, and when it existed. Those three properties are checkable, and they are what audits, registrations and client questions actually require. What no record can prove is what happened inside the model, including which reference causally shaped which output. Keep your claims inside that line and your documentation will hold up exactly when it is needed most. The full argument is in our companion guide on AI provenance and what you can prove.