A prompt alone rarely reproduces an image. The result may also depend on source files, model or service version, seed, dimensions, hidden defaults, control images and later edits. A useful record captures the whole decision path without pretending that every hosted system is deterministic.
Identify every input precisely
Record source filenames and hashes or stable asset IDs, reference images, masks, control layers and any preset. State the rights or approval status of each input. If a source changes, it should produce a new record rather than silently replacing the old one.
Store the full prompt and negative instructions as plain text, including punctuation and ordering. Note which part came from a reusable brand component and which was written for the specific asset.
Capture the generation environment
Record tool or service, model or mode, date, account workspace, dimensions, aspect ratio, seed when exposed, guidance or strength values and batch size. For hosted services, the date matters because behaviour can change even when the interface label does not.
Preserve the raw selected output before retouching. Give every later crop, composite or correction a linked version. C2PA can carry signed provenance assertions in compatible workflows, while the internal log retains production detail the credential may not include.C2PA technical specification ↗
Record selection and human edits
Explain why one output was selected and which defects were accepted or corrected. List material edits such as compositing, repainting, geometry repair, colour work and type replacement. This record helps demonstrate the actual human creative process and supports later revisions.
Keep approval attached to a specific asset ID and checksum. A screenshot of a conversation may provide context, but the production register should state the decision owner, date, placements and limitations clearly.
Test reproducibility before handoff
Ask another operator to recreate the baseline from the record. Exact pixel identity may be impossible in some services, so define reproducibility as the ability to reconstruct the setup, locate the selected raw output and repeat the manual workflow.
Archive the record in an open, readable format beside the assets. The Library of Congress format guidance is a useful reference when choosing sustainable formats and documenting technical characteristics for continued access.Library of Congress format guidance ↗
Use a record that survives the tool
Store the production record in a readable text or structured format, not only inside a service history. Include asset IDs, input hashes, prompt text, settings, tool and date, raw output ID, selection note, edits, final checksum and approval. Link large files rather than embedding fragile private URLs.
Add a schema version to the record. When the team later introduces a new control such as reference strength or content credential ID, older records remain interpretable. A changelog explains why the template evolved and which fields were unavailable in earlier projects.
Describe acceptable reproducibility
For a deterministic local workflow, the goal may be an identical binary from the same inputs and environment. For a hosted generative service, exact recreation may be impossible. Define success as rebuilding the setup, locating the approved raw selection and repeating the documented edit and export chain.
Record sources of variation honestly: service updates, stochastic generation, unavailable models, platform compression and manual judgement. This prevents a future operator from assuming an exact seed is enough or blaming themselves when an undocumented cloud change alters results.
Run a reproduction drill before archiving
Give the record and authorised assets to someone who did not produce the image. Ask them to identify the approved raw output, rebuild the working file and create one new delivery size. Note every question they need to ask.
Fix missing dependencies, ambiguous names and undocumented edits, then freeze the record with the master. The drill is a practical test of handoff quality and often reveals that the most important production setting lived only in a screenshot, memory or private message.
A practical decision table
| Record layer | Minimum fields | Why it matters |
|---|---|---|
| Input | Asset ID, rights, references | Rebuild the starting state |
| Generation | Tool, date, prompt, settings | Explain the raw output |
| Edit and approval | Changes, version, owner | Trace the delivered master |
Release checklist
- Identify source assets
- Save full prompt text
- Record tool and date
- Capture exposed settings
- Keep raw selected output
- Link manual edit versions
- Explain selection rationale
- Attach approval to checksum
- Run a handoff reproduction test
- Archive a readable record
Common questions
Does the same seed guarantee the same image?
Not across every tool or version. Record the wider environment and preserve the selected raw output.
Should rejected prompts be archived?
Keep those that explain a decision, risk or approved direction; routine dead ends can follow the project retention policy.