Suppose a client asks whether the approved product image used a particular photographer’s reference. Your producer finds that reference attached to the shot, alongside a prompt and a model name. That helps answer where to look. It does not, on its own, establish whether the reference was submitted to the generator, added later as a note, or licensed for this use.
A team member’s declaration, a generation receipt, an unchanged file and a licence document are different things. Keeping them together helps a producer review the delivery without treating one as a substitute for another.
Start with the claim, not the badge
In production, AI provenance describes the record of an asset’s declared inputs, generation tools, edits and subsequent handling. Model provenance concerns the model itself, including its provider, version and whatever reliable information is available about its origin. Recording a model name does not establish its training history or the permissions covering that training data.
A provenance-aware workflow preserves this information rather than losing it at handoff. The label does not tell you whether a value was manually entered, read from a file or independently verified. Ask that question for each claim you intend to make to a client.
- For a declared input, identify who recorded it and what supports its association with this output.
- For an integrity claim, identify the earlier trusted value or copy against which the current record was checked.
- For a date claim, distinguish the asserted generation time, the application’s recording time and any independent time evidence.
- For permission to use material, inspect the underlying permission and its scope separately from the production history.
A declaration tells you what someone recorded
A producer can record that reference A was used for shot 12. That is a useful, attributable statement. It does not become an independently observed generation event because the application stores it, hashes it or gives it a timestamp.
Where available, retain the original source file, exported workflow or provider receipt alongside the declaration. Note what that evidence actually contains. A tool-generated receipt may support that certain inputs were submitted in a particular job; a screenshot may show the settings visible when it was taken. Neither should silently inherit stronger claims about completeness or authenticity.
Capture details while working when practical. If you reconstruct an older project, record when you added the information, who supplied it and which original files or messages support it. Leave uncertain fields unknown instead of backdating the entry or presenting a remembered seed as a captured fact.
A hash needs a trustworthy comparison point
A cryptographic hash is a fingerprint of specific bytes. Comparing an asset with a previously retained hash can detect a change, assuming an appropriate algorithm and a trustworthy earlier value. It does not tell you whether the original content was accurate or when it was created.
Linking entries through hashes makes changes detectable against a known earlier chain state. But an operator who can replace the entire history and all its hashes can recompute an internally consistent chain. A hash chain alone is not proof that history cannot be rewritten.
Stronger checks need a trusted anchor, such as an authenticated snapshot retained by another party, and a way to compare later records against it. Signed records also depend on control of the signing key. The Certificate Transparency standard illustrates this with comparisons between published log states and independent monitoring. It also discusses logs presenting inconsistent histories to different clients. Those controls must be implemented and checked; naming a cryptographic technique is not enough.
A saved date is not an independent timestamp
A creation date entered by a user is a declared date. A server timestamp records what the application’s clock reported for an operation. Its reliability depends on that system’s clock, access controls and logging. Ordering entries in a chain does not by itself anchor them to a real-world date.
An independent timestamp is different. Under RFC 3161, a time-stamping authority issues a signed token associated with a hash. A verified token can support that matching data existed no later than the attested time, within the authority’s accuracy and trust assumptions. Verification must check the matching hash, signature and relevant certificate information; a displayed date is not enough.
Timestamping a file today does not establish that it was generated last Tuesday. It establishes a boundary on when those bytes existed, not the truth of the events described inside them. If no independently verifiable time evidence accompanies your export, do not describe the application’s date as one.
What a C2PA validation result means
A C2PA Content Credential is a signed manifest containing assertions about an asset. Validation checks matters such as the signature, the manifest’s binding to the asset and the signer’s trust status under the verifier’s policy. The C2PA 2.2 explainer separates these checks from deciding whether the assertions or depicted events are true.
A valid signature is not automatically a verified human creator, and trust in a signing implementation is not agreement with every statement in its manifest. Provenance can also be incomplete or removed. Missing credentials do not establish that an asset is false or unlawfully made.
Read the assertions and the validation result together. A credential describing AI generation can support a statement about the declared production process. It does not grant a licence, clear a likeness or prove how a reference influenced particular pixels.
Keep production history separate from rights clearance
A reference-to-output link documents an association. It is not a measurement of that reference’s causal contribution inside the model. Do not turn a saved prompt, seed or reference list into a claim that the exact origin of every pixel has been established.
Similarly, a field marked “licensed” records a rights status; it does not supply the licence itself. Retain the supporting agreement, its source and the intended use for review. A client approving a visual and a rights holder granting permission are different decisions. One should not automatically mark the other complete.
Documentation can support a client or legal review, but this guide does not establish a universal documentation duty or guarantee compliance. The relevant requirements depend on the use, agreements, jurisdiction and parties involved. When clearance is uncertain, take the underlying evidence to a qualified adviser rather than relying on a provenance badge.
Could a spreadsheet do this job?
For a small project, a well-maintained sheet with stable asset links, named owners and retained source files can be a sensible record. It is incorrect to say that spreadsheets have no history. Microsoft documents version history in OneDrive and SharePoint, including restoration of earlier file versions. Check the actual settings and retention rather than assuming history is always available.
The production question is whether the team can retrieve the right evidence for the right delivered version without rebuilding the links. Can someone other than the original producer find its prompt, references, changes and approval? A dedicated workspace earns its place if it makes that job easier. It does not win the comparison merely by calling a record sealed.
What this means when using Behind The Workflow
In BTW, you can add generation details and references beside an asset, keep related iterations together and connect the selected version to review and delivery decisions. Feature availability depends on your plan. There is still manual work. People need to supply missing details, check imported information and associate evidence with the correct asset. The application does not automatically observe everything that happened in another generation tool.
Treat manually entered inputs as declarations. Where a source credential is available, inspect its actual validation and trust status separately. Do not assume every record has an independently verified timestamp or independently anchored history because this guide explains those mechanisms. Make a stronger claim only when the particular record contains evidence that supports it and that evidence has been checked.
Test that distinction on one real handoff. Ask a teammate to open a delivered shot and retrieve the supporting record without asking its producer to reconstruct it. Then check the following together.
- Identify the exact delivered file and version, not just a similarly named asset.
- Separate manually declared inputs from information present in source files or receipts, and label missing evidence.
- Check who recorded each approval and which version it concerns. Keep separate permission documents available for review.
- If claiming integrity or time verification, inspect the actual hash comparison, trust anchor or timestamp token and its result.
- Inspect the handoff before sharing it. Include what the client needs and exclude private references or internal notes they should not receive.
This test shows both the useful evidence and the gaps. For the fields to capture on that asset, use the prompt and model documentation checklist.