Two lessons ago you learned which tools indemnify you. One lesson ago you learned why "ethically trained" needs an asterisk and how to audit imagery for bias. This lesson turns all of that into something durable: a one-page Provenance Log v1 and a Code of Conduct your whole team can follow, store in Notion or Linear, and hand to a legal reviewer without flinching. The goal is not more ethics theater. It is a written policy that answers three questions cleanly - what gets attributed, what gets disclosed to clients, and what gets stored with C2PA and Content Credentials provenance tags - so that when an asset is challenged six months from now, the answer is a record, not a memory.

Why a Written Policy Beats Good Intentions

Every designer reading this already intends to be careful. Intentions do not survive a Wednesday. On a launch deadline, with marketing waiting and four tools open, the careful mental note about where an asset came from evaporates, and six months later when a rights holder or a client asks "how was this made," nobody can reconstruct it. The graphic designer who vectorized a logo in Recraft on Monday, retouched a hero in Photoroom on Tuesday, and wrote an attribution clause for a Midjourney mark on Wednesday is generating provenance questions faster than any memory can hold them. A written log and a shared code of conduct are the only things that scale past one person's recall.

The deeper reason is that provenance is a team property, not an individual one. The asset you generate gets reused by a teammate, embedded in a deck by a PM, and shipped in a campaign by someone who never saw your prompt. If the provenance lives only in your head, it is lost the moment the asset leaves your hands. A code of conduct externalizes the discipline so it travels with the asset, which is the entire point: the record has to outlive the moment of creation and the person who created it.

Provenance you remember is provenance you will lose. Provenance you log is provenance you can defend. The difference is one row in a table, written at the moment of creation instead of reconstructed under pressure.

What C2PA and Content Credentials Actually Do

Before the policy, the plumbing. C2PA, the Coalition for Content Provenance and Authenticity, is an open technical standard for attaching tamper-evident provenance metadata to a piece of content. Content Credentials is the user-facing implementation you will meet most often, especially through Adobe tooling: a cryptographically signed record, traveling with the file, that can say what tool made it, that it was AI-generated or AI-edited, and what edits were applied. Think of it as a nutrition label that is attached to the image itself rather than written down separately, and that is hard to forge or strip without leaving a trace.

For a designer, the practical value is that Content Credentials turn provenance from a claim you make into a record the file carries. Instead of "trust me, this was generated in Firefly," the file itself can assert it. This does not solve every IP question, and it is not universally present yet, so part of your policy is deciding which assets get Content Credentials applied and preserved, and what you log separately when the standard is not available. The standard is a tool the policy uses; it is not the policy itself, and a designer who confuses "we use Content Credentials" with "we have a provenance policy" has skipped the actual work.

The Three Questions the Policy Answers

A provenance code of conduct does not need to be long. It needs to answer three questions unambiguously, because those are the three that come up when an asset is challenged.

What Gets Attributed

Attribution is about giving credit and recording origin internally, and the policy should state a clear default: every generated or AI-edited asset records the tool, the model where relevant, the date, and the human who made and finished it. This is not about plastering "made with AI" on every public pixel; it is about an internal record so the team always knows what an asset is. The policy draws the line between the internal record (always) and any public attribution (case by case, driven by client and legal requirements), so nobody has to guess in the moment.

What Gets Disclosed to Clients

Disclosure is the trickier question because it is contractual and relational. Some clients require disclosure of AI use; some contracts prohibit it or demand it; some industries are sensitive about it. The policy should establish a default disclosure posture - typically, be honest and proactive about AI involvement in deliverables when asked, and know each client's specific contractual stance before the work starts, not after. The code of conduct's job is to make disclosure a known position the team holds rather than an awkward improvisation when a client asks "wait, is this AI?" The worst answer to that question is a surprised pause.

What Gets Stored With Provenance Tags

Storage is where the standard meets the policy. The code of conduct should specify which assets get stored in the team asset library with C2PA or Content Credentials provenance tags preserved, so the record is not stripped when a file is exported, compressed, or moved. The default should be that shippable and client-facing assets retain their provenance through the pipeline, and that the asset library is the system of record where the provenance log lives alongside the files. An asset whose provenance was stripped on export is an asset you can no longer defend, so preserving the tags is not optional housekeeping; it is the difference between having a record and having a memory.

The Provenance Log v1 Template

Here is the artifact this lesson exists to give you: a provenance log you can build in Notion or Linear in ten minutes, with one row per asset. It is deliberately minimal, because a log nobody fills in is worthless, and the way to make a log get filled in is to make each row trivial. The columns are the questions the future challenge will ask.

1. Asset name and link. What it is and where it lives in the library.
2. Tool and model. Firefly, Midjourney, Recraft, Photoroom, FLUX, and the model or plan where relevant.
3. Generation type. Fully generated, AI-edited, or AI-assisted-but-human-finished, which matters for both attribution and disclosure.
4. Prompt summary and IP-targeting flag. A short note on the prompt and an explicit yes/no on whether it steered toward known IP - the field that protects your indemnity claim.
5. Indemnity status. Indemnified (and on which plan) or not, pulled straight from the IP Map decision tree.
6. Bias-audit status. Whether people-imagery passed the audit and was matched to the actual audience, from the previous lesson's checklist.
7. Content Credentials. Applied and preserved, or not available, so you know which assets carry their own record.
8. Disclosure posture. What this client requires and what was disclosed, so the contractual stance is recorded, not remembered.

Eight columns, one row per asset, filled in at the moment of creation. That single discipline converts every prior lesson - indemnity, bias, provenance honesty - into a durable, auditable record. When the challenge comes, you open the row.

Making It Survive Legal Review

The brief specifies that this policy must survive a legal review, which is a useful constraint because it forces precision over posture. A legal reviewer is not impressed by "we take IP seriously." They are reassured by specifics: a default tool with a known indemnity, a prompt-hygiene rule against IP targeting, a provenance log with the right fields, a disclosure posture aligned to contracts, and preserved Content Credentials on shippable assets. The policy survives legal review precisely because it is concrete and honest, including about its limits - it does not claim to make infringement impossible, it claims to make the team's process defensible and its records complete.

The honesty matters as much as the completeness. A policy that overclaims - "all our AI assets are fully legally safe" - will be torn apart by a careful reviewer and will give the team false confidence. A policy that states the real posture - "we default to indemnified tooling, we log provenance, we flag IP-targeting prompts, here are the residual risks we accept and why" - reads as the work of professionals who understand the terrain. Legal reviewers trust precision and distrust absolutes, so write the policy the way you would talk in the legal conversation: specific, sourced, and clear about its edges.

A Worked Example: Logging a Launch Campaign

The brand team runs a launch with three generated assets. Asset one is a hero image generated in Firefly. The row records: Firefly, paid plan, fully generated, generic prompt, IP-targeting no, indemnified yes, bias-audited and audience-matched yes, Content Credentials applied and preserved, client requires no public AI label but disclosure on request. Defensible, complete, done in ninety seconds. Asset two is a logo vectorized in Recraft from the client's own art. The row records: Recraft, AI-edited from client-supplied source, no IP targeting, indemnity per Recraft's plan terms (checked, not assumed), no people so no bias audit, Content Credentials where available, disclosure per contract. Asset three is a Midjourney concept used only as internal reference and redrawn before shipping. The row records: Midjourney, internal reference only, not shipped, redrawn final logged separately, indemnity not applicable because not shipped.

Three assets, three honest rows, and a complete record of how a launch was made. Six months later, when a question arrives about any one of them, the answer is a row, not a scramble. That is the entire value of the code of conduct: it makes the future challenge boring, because the work was already done at the moment of creation.

The Three Disclosure Conversations the Log Prepares You For

A provenance log is not just a defensive record; it is the thing that lets you answer three specific questions calmly, and each one comes from a different direction. The first is the client conversation. A client asks, mid-project or after delivery, "was any of this made with AI?" Without a log, the honest answer is a nervous "some of it, I think," which reads as evasive even when it is not. With a log, the answer is precise: "Yes - the hero was generated in Firefly on a paid plan, the logo was AI-vectorized from your own artwork, and per our contract here is what was disclosed." Precision reads as professionalism; vagueness reads as something to hide, even when there is nothing to hide.

The second is the legal conversation, when a rights holder or an internal counsel asks "can you defend how this asset was made?" The log answers in the language legal trusts: tool, plan, indemnity status, whether the prompt steered toward known IP, and whether Content Credentials are preserved. A scramble through old files and fading memories is the opposite of defensible; a row written at the moment of creation is exactly what turns an anxious meeting into a five-minute confirmation. The third is the internal conversation, when a teammate reuses your asset months later and a PM asks "wait, where did this come from?" Because the provenance traveled with the asset in the library rather than living in your head, the teammate can answer without ever finding you. The log is what makes provenance a team property instead of a personal one, which is the whole point.

Notice that all three conversations share a structure: someone asks how an asset was made, and the quality of your answer depends entirely on whether you wrote it down at creation or are reconstructing it under pressure. The log is the difference between an answer and a guess, and in each of the three rooms - client, legal, internal - an answer is trust and a guess is doubt.

A Common Mistake: The Log That Overclaims or the Log Nobody Fills

There are two opposite ways a provenance practice fails, and a careful team guards against both. The first failure is the log that overclaims. A team, wanting to look responsible, writes "all AI assets verified fully legally safe" in every row. This is worse than useless, because it is false, and the first careful legal reviewer who reads it loses all trust in the entire log. Provenance records earn their value from honesty, including honesty about limits. A row that says "indemnified per Firefly paid plan, no IP-targeting prompt, residual trademark risk accepted by marketing" is defensible precisely because it does not pretend the risk is zero. The overclaiming log gives false confidence and collapses on contact with scrutiny; the honest log survives because it never claimed more than it could prove.

The second failure is the opposite: the log so heavy that nobody fills it in. A team that demands twenty fields per asset, in a separate tool, with mandatory approvals, has built a system that designers route around on every deadline, and a log with gaps is worse than no log because it implies records exist where they do not. The cure for both failures is the same discipline: keep the log minimal and honest. Eight columns, filled at the moment of creation, stating the real posture including its asterisks. A log that is fast enough to actually use and honest enough to actually defend is the only kind worth having, and it sits exactly between the two failure modes - not so ambitious it goes unfilled, not so flattering it goes unbelieved.

The tell that you have struck the right balance is simple: a stranger to the project can read a row in fifteen seconds and know exactly what the asset is, how it was made, and what risk the team accepted, with no marketing gloss and no missing fields. If a row reads like a confident, boring fact, the log is working. If it reads like a reassurance or trails off into blanks, one of the two failure modes has crept in.

How to Roll It Out Without Killing Velocity

The failure mode of any policy is that it becomes a bureaucratic tax everyone routes around. Avoid it by keeping the log minimal, embedding it where the work already happens (in Linear next to the ticket, or in Notion next to the asset library), and making the default path the easy path. If logging a row takes ninety seconds and lives where the designer already is, it gets done. If it requires opening a separate system and filling twenty fields, it gets skipped, and a skipped log is worse than no log because it creates false confidence that records exist. Roll out the eight-column v1, prove it is fast, and only add fields when a real challenge shows you a gap. Version it - this is v1 - so the team expects it to evolve rather than treating the first draft as gospel.

The cultural move is to make logging a mark of professionalism rather than a punishment. The designer who can answer "how was this made" with a row is the designer who gets trusted with the high-stakes client work, the brand-critical launch, the asset that legal actually cares about. Frame the log as the thing that lets the team move fast on risky work because the records make the risk legible, not as the thing that slows them down. Provenance discipline is a competitive advantage, not a compliance chore, and the teams that internalize that ship bolder work with less anxiety.

Key Takeaways

• Provenance you remember is provenance you will lose. A written log and shared code of conduct are the only things that scale past one person's recall, because the asset outlives the moment and the maker.
• C2PA is the open provenance standard; Content Credentials is the user-facing implementation that attaches a tamper-evident, signed record to the file itself, turning provenance from a claim you make into a record the file carries.
• A provenance code of conduct answers three questions unambiguously: what gets attributed (internal record always, public attribution case by case), what gets disclosed to clients (a known posture aligned to contracts), and what gets stored with preserved provenance tags (shippable assets, in the asset library).
• The Provenance Log v1 is eight columns - asset, tool and model, generation type, prompt and IP-targeting flag, indemnity status, bias-audit status, Content Credentials, disclosure posture - one row per asset, filled at the moment of creation.
• The policy survives legal review by being concrete and honest about its limits: it does not claim to make infringement impossible, it makes the process defensible and the records complete. Reviewers trust precision and distrust absolutes.
• Roll it out without killing velocity: keep the log minimal, embed it in Notion or Linear where work already happens, make the default the easy path, and version it so it evolves.
• Frame provenance discipline as a competitive advantage - the designer who can answer "how was this made" with a row gets trusted with the high-stakes work - not as a compliance chore.