A year from now, a client's legal team will ask you a question you cannot answer from memory: "For this deliverable we are about to put on a billboard, which assets were generated by AI, by which model, from what prompt, and are any of them carrying a training-data disclosure we need to know about?" If your answer is a shrug and a scroll through your Figma version history, you have a problem that is no longer a design problem - it is a liability problem, and it is yours. The senior move is to never be in that position, because you kept a provenance log: a real, queryable record in Notion or Linear that tracks every AI-generated artifact, the prompt that made it, the model that produced it, the date, and - for outputs from tools like Adobe Firefly - a note about the disclosures that may matter when a lawyer reads them. This lesson teaches you to build that log, to keep it honestly enough that it survives a legal review, and to make it the foundation that the next two lessons - client disclosure and team trust - are built on. The artifact is a provenance template you can defend in a legal review.

Why Provenance Became the Designer's Job

For most of design history, provenance was implicit. You drew it, so you made it; the question of "where did this come from" had a trivial answer. AI broke that. Now a single deliverable might contain a hero image generated by Firefly, an icon set explored in Recraft, microcopy drafted by Claude, a background composited in Photoroom, and a layout scaffolded by Figma Make - and from the outside, the finished artifact is uniform. Nobody can tell by looking which pixels you authored and which a model produced. That opacity is convenient right up until the moment someone needs to know, and the people who need to know are exactly the people you cannot stall: a client's legal counsel before a public launch, a brand's compliance team, a procurement reviewer, or your own org's general counsel after a competitor's cease-and-desist lands.

Here is the uncomfortable shift. In 2026 the question "is this asset safe to ship commercially" frequently does not have a yes-or-no answer; it has a "it depends on which model made it and under what terms" answer. Adobe Firefly on a paid Creative Cloud plan carries commercial indemnification. Midjourney does not, and has been the defendant in the Disney and Universal lawsuit live since June 2025, joined by Warner Bros. Discovery in September 2025. Two visually identical images can carry completely different legal exposure depending solely on which tool produced them. The only way to answer the safety question is to know the origin of every asset, and the only way to know the origin after the fact is to have recorded it at the time. Memory does not survive a legal review. A log does.

This is why provenance is now a craft responsibility, not an afterthought. The senior IC operating without supervision cannot lean on a manager to remember which assets were AI-made; the record has to be built into the workflow so it exists by default. The log is that record.

What a Provenance Log Actually Records

A provenance log is not a vibe or a folder of screenshots. It is a structured table with one row per AI-generated artifact and a fixed set of columns, each of which exists because some future question depends on it. If a column would not help answer a real question from a real reviewer, it does not belong; if a question you can foresee has no column, the log is incomplete. The discipline is to design the columns around the questions, not around what is convenient to capture.

The Core Columns

Five columns are non-negotiable, because they answer the five questions every reviewer asks. Artifact: what the thing is and where it lives - a link to the asset, a name, the deliverable it belongs to. This answers "which asset are we talking about." Model: the exact tool and, where it matters, the version - "Adobe Firefly Image 3," not "an AI." This answers "what produced it," and it is the column that determines legal exposure. Prompt: the actual prompt text, including any reference images pinned, because the prompt is part of the asset's history and sometimes part of its risk. This answers "how was it made." Date: when it was generated, because terms of service and model versions change over time, and an asset made under last year's terms may carry different obligations than the same prompt run today. This answers "under what conditions." Author: who ran the generation and who finished it by hand, because a log that cannot say who is accountable for an asset is not a log a legal team trusts.

The Disclosure Column, Where the Real Work Lives

The sixth column is the one that separates a hobbyist's note-taking from a professional's defensible record: Disclosure / Notes. This is where you record anything about the asset's origin that a reviewer would want flagged rather than discovering on their own. For a Firefly output, this is where you note the model's training-data disclosure - that Adobe disclosed, in 2024 and 2025, that approximately five percent of Firefly's training set included AI-generated images, some sourced from other models including Midjourney. That fact does not make the asset unusable, and Firefly's commercial indemnification still applies, but it is exactly the kind of detail a client's legal team may want to know before the asset goes on a billboard, and discovering it from you proactively is a very different experience than discovering it from a journalist later. For a Midjourney output, this column flags the absence of indemnification and the active litigation. For an asset built on a competitor teardown, this column references the teardown's ethics note. The disclosure column is where the log stops being an inventory and becomes a risk document.

Memory does not survive a legal review. A log does. The question is never whether you can remember which assets were AI-made under deadline pressure six months ago - it is whether you wrote it down at the time, in a record someone else can read without you in the room.

Building It in Notion or Linear, Not a Spreadsheet

The log lives where your team already works, which in 2026 is overwhelmingly Notion or Linear, and the choice between them is not cosmetic. A Notion database gives you a queryable, filterable, linkable table that connects to the rest of your design documentation - you can filter to "all Firefly assets in the Q3 launch" in one click, which is precisely the query a legal review generates. A Linear setup treats each AI artifact or each disclosure flag as a trackable item with an owner and a status, which suits teams that already run design ops through Linear and want provenance to live in the same accountable system as their other work. Either works; what does not work is a loose spreadsheet nobody links to and nobody updates, because the log's entire value is that it is alive and queryable at the moment someone asks, not a stale file someone has to reconstruct.

The practical setup in Notion: a database with the six columns as properties, the Model and Disclosure columns as filterable selects rather than free text where possible (so "show me everything with no indemnification" is a filter, not a manual scan), and a relation linking each artifact to its parent deliverable. In Linear: a dedicated label or project for provenance, each artifact a sub-issue under its deliverable, the disclosure flag as a property, so a deliverable's provenance is one filtered view away. The format matters less than two properties: it must be queryable, and it must be maintained as part of the workflow rather than reconstructed at audit time. A log you fill in honestly as you generate is worth ten you try to backfill from memory the night before a review.

The Firefly Synthetic-Training Detail, Handled Like a Professional

The Firefly disclosure deserves its own treatment, because how you handle it is a test of whether your provenance practice is honest or performative. The facts, plainly: Adobe has marketed Firefly as commercially safe and trained primarily on Adobe Stock and licensed or public-domain content, and Adobe offers commercial indemnification to paid users. Adobe also disclosed that roughly five percent of the training data included AI-generated images, some from other generators. Both of these are true at once. The indemnification is real and valuable; the five percent disclosure is also real and is exactly the kind of nuance a careful legal reviewer will surface on their own if you do not surface it first.

The professional move is not to hide the disclosure because it complicates the "Firefly is the safe one" story, and it is not to catastrophize it into "Firefly is tainted." It is to record it accurately in the disclosure column so that when a client's legal team asks, the answer already exists in writing: this asset was made with Firefly, which carries commercial indemnification on our plan, and here is the known training-data disclosure, noted so you can make your own assessment. That posture - here are the facts, recorded at the time, neither hidden nor inflated - is what makes a provenance log survive a legal review. A log that only records the convenient facts is not a record; it is marketing, and a lawyer will treat it as such. The five percent note in the disclosure column is small, but it is the single clearest signal that your log was built to inform a reviewer rather than to reassure yourself.

C2PA and Content Credentials: The Machine-Readable Layer

Your written log is the human-readable provenance record. There is also a machine-readable layer, and a senior practice uses both. C2PA - the Coalition for Content Provenance and Authenticity - is an open technical standard for cryptographically signed provenance metadata embedded in the asset itself, and Content Credentials is Adobe's implementation of it, the small "CR" pin you may have seen on images that carries a tamper-evident record of how the asset was made and edited. When Firefly generates an image, it can attach Content Credentials that travel with the file, stating it was AI-generated and recording its edit history.

The relationship between your log and C2PA is complementary, not redundant. Content Credentials live in the asset and answer "what does this specific file say about itself" - durable, cryptographic, but only as complete as the tools in the chain support, and strippable if an asset passes through software that does not preserve the metadata. Your provenance log lives in your system and answers "what does our team know about this asset's origin and its disclosures" - including the judgment calls, the disclosure notes, and the accountability that no embedded metadata captures. The C2PA layer is evidence; your log is the record that interprets and contextualizes that evidence. A senior IC preserves Content Credentials where the toolchain supports them and maintains the written log regardless, because the two together - the asset that can attest to itself and the team record that explains what that attestation means for this client - is a far stronger position in a review than either alone. When a reviewer asks "how do we know this was AI-made," "the file carries signed Content Credentials and our log records the model, prompt, and disclosure" is an answer that ends the conversation.

A Worked Example: Logging a Launch Deliverable

Make it concrete. You are shipping a product-launch landing page with five visual assets, and a client legal review is scheduled before go-live. As you build, you log.

Asset one, the hero image: Model, Adobe Firefly Image 3; Prompt, the full text plus the three brand-anchor reference images you pinned; Date, today; Author, you generated, you hand-finished the lighting; Disclosure, "Firefly - commercial indemnification applies on our CC plan; note Adobe's ~5% synthetic-training disclosure; Content Credentials preserved in the exported file." Asset two, an empty-state illustration: Model, Recraft; Prompt, recorded; Disclosure, "Recraft - no commercial indemnification; original generation, no third-party marks; verify before use in paid placement." Asset three, the product hero composite: Model, Photoroom for background removal over a licensed product photograph; Disclosure, "AI used for background removal only; base photograph is licensed stock, license number recorded." Asset four, the microcopy: Model, Claude; Prompt, the voice-and-tone brief; Disclosure, "AI-drafted, designer-edited; no factual claims requiring verification." Asset five, a section background: Model, Midjourney; Disclosure, "Midjourney - NO commercial indemnification, active Disney/Universal/Warner litigation; flagged for replacement before launch unless legal explicitly clears it."

When legal asks "what are we exposed on," you do not scramble. You filter the log to the deliverable and hand them five rows. They see immediately that asset five is the risk and asset one carries a disclosure worth noting, and the conversation is a focused ten minutes about two assets instead of a panicked reconstruction of five. That is the entire value of the log: it converts a frightening open-ended question into a short, answerable one, because you did the recording when the answering was easy.

Keeping the Log Honest Under Deadline

The hardest part of a provenance log is not designing it; it is maintaining it on the Wednesday afternoon when marketing needs fifteen variants by five and logging each one feels like friction. This is where most provenance practices die, and the failure is predictable: the log is pristine for two weeks and then has a six-week gap that exactly coincides with the launch crunch, which is precisely when the riskiest, most-rushed assets were made. A log with a hole where the deadline was is worse than no log, because it implies a discipline you did not actually keep, and a legal reviewer who finds the gap will trust nothing else in the record.

The fix is to make logging cheap enough to survive the deadline. Three moves do this. First, log at generation, not in a separate session - the moment you save an asset, you add the row, because the prompt and model are in front of you and will never be cheaper to capture than right now. Second, template the disclosure notes so the common cases ("Firefly - indemnified, ~5% note") are a one-click select, not a sentence you rewrite each time. Third, treat the log as a definition-of-done for any AI-generated asset: an asset is not finished until its row exists, the same way a component is not done until its tokens are mapped. When logging is a thirty-second reflex built into saving, it survives the deadline; when it is a chore you do later, it does not, and "later" is exactly when the highest-risk assets get made. The honest log is the one that is most boring to keep, because it is kept constantly, in small increments, by reflex.

The Foundation for Client Disclosure and Team Trust

This lesson is the first of three for a reason. The provenance log is the substrate that the next two skills require. The disclosure scripts you will draft for a client, a CPO, and your team - the next lesson - are only credible if there is a real record behind them; "we used AI responsibly" is a claim, but "here is our provenance log showing exactly what AI made and what disclosures apply" is evidence, and the difference between a claim and evidence is the difference between a client who trusts you and one who audits you. Team trust, likewise, is built on a shared record rather than individual memory: when every designer logs, the team can answer for its work collectively, and a junior's rushed Firefly asset is visible and discussable rather than a hidden liability nobody knew about until it shipped.

So treat the log not as paperwork but as the thing that makes everything else in this chapter possible. A senior IC operating without supervision needs an internal safety system, and provenance is the load-bearing piece of it: the record that lets you disclose honestly, defend your work in a legal review, and coach a junior toward the same discipline. Build it once, keep it honestly, and the questions that frighten designers who did not keep one become, for you, a filtered view and a ten-minute conversation. That is what it means to operate at senior-IC quality without a manager checking your work: the check is built into how you work, and the log is where it lives.

Key Takeaways

• Provenance is now a craft responsibility because a single deliverable mixes assets from many models, and from the outside the result is uniform - nobody can tell which pixels were AI-made. The safety of an asset often depends entirely on which model produced it (Firefly carries commercial indemnification; Midjourney does not and faces active litigation), so origin must be recorded at the time, because memory does not survive a legal review.
• A provenance log is a structured table with six columns, each answering a reviewer's question: Artifact, Model (the column that determines legal exposure), Prompt, Date, Author, and Disclosure/Notes. Design the columns around the questions, not around what is convenient to capture.
• The disclosure column is where the log becomes a risk document. For Firefly, record that it carries commercial indemnification and that Adobe disclosed roughly five percent of training data was AI-generated - both facts, neither hidden nor catastrophized. Recording it proactively is the single clearest signal the log was built to inform a reviewer, not reassure yourself.
• Build it in Notion or Linear where it is queryable and maintained as part of the workflow, never a loose spreadsheet backfilled from memory. The value is that it is alive at the moment someone asks - filter to a deliverable and hand over the rows.
• Use C2PA and Content Credentials as the complementary machine-readable layer: the asset attests to itself cryptographically, your log interprets what that attestation means for this client. Preserve Content Credentials where the toolchain supports them and keep the written log regardless; together they end the "how do we know this was AI-made" conversation.
• The log dies under deadline if logging is a chore. Make it cheap: log at generation, template the common disclosure notes, and treat an asset as not-done until its row exists. A log with a gap where the launch crunch was is worse than none, because it implies a discipline you did not keep. The log is the foundation the next two skills - client disclosure and team trust - are built on.