The loop ends in a room. You have a verified synthesis, a hi-fi flow, and a Figma Make prototype, and on Friday you walk into a conversation with a CPO who can greenlight the direction or send you back a week. This lesson is about that conversation, and specifically about a problem the prior six lessons created: you used AI throughout, the AI provenance is real and documented, and now you have to decide how visible to make it without letting it hijack the discussion. Lead with the provenance and the meeting becomes a referendum on whether AI did good work - the exact wrong conversation, the one you watched derail a design review when nobody could agree if the side-nav was intentional or hallucinated. Hide the provenance and you are concealing how the work was made, which fails the disclosure standard and burns trust when it surfaces. The senior move is to make the provenance available but not central: the design choice is the subject, the provenance is the appendix that defends it when asked. The artifact is a CPO-ready decision memo plus a Figma Make prototype URL, structured so the conversation stays about the design.

The Wrong Conversation, and How AI Provenance Causes It

There is a failure mode that L3 designers create for themselves, and it comes from being proud of the AI-augmented workflow. You built something good fast, the provenance is clean, you verified everything, and you want the room to know - so you open with "I used Claude to synthesize the research, UX Pilot for the flows, Figma Make for the prototype." And in that instant you have lost control of the meeting. The CPO is now thinking about AI, not about the design. The skeptical eng manager wants to know if the prototype is "real." Someone asks whether the synthesis can be trusted. The conversation that should have been "is this the right direction for the product" has become "did the AI do this correctly," which is a conversation you cannot win because it is the wrong question.

This is the same dynamic as the insider-brief design review where the room spent twenty minutes arguing about whether the side-nav pattern was intentional or hallucinated instead of whether it was right. The presence of AI in the workflow, once made salient, magnetizes the discussion toward AI. People who would never interrogate a hand-drawn mock's provenance will interrogate an AI-assisted one, because AI triggers a verification reflex. So the first principle of the Friday conversation is: do not make AI salient unless asked. The design choice is what you are there to discuss, and every minute spent on how the sausage was made is a minute not spent on whether the sausage is good.

But You Cannot Hide It Either

The opposite error is to conceal the AI's role, and it is worse, because it fails both ethics and self-interest. The disclosure standard - what you tell stakeholders about AI's role in a deliverable - exists for good reason: stakeholders are making decisions based on your work, and they are entitled to know how it was made, especially when AI's failure modes (a distorted synthesis, a drifted prototype) bear on how much to trust it. Concealing the provenance is not a neutral act of focus; it is a misrepresentation, and when it surfaces - and it surfaces, because someone always asks how you turned two weeks into five days - the trust cost is severe. You do not get to be both the designer who compressed the timeline with AI and the designer who implied it was all hand-made.

So the Friday conversation threads a real needle. You cannot lead with the provenance (it hijacks the meeting) and you cannot hide it (it fails disclosure and burns trust). The resolution is structural, not rhetorical: you make the provenance available but not central. It lives in the memo as a clearly-labeled appendix and in the prototype's documentation, ready to be pointed to the instant anyone asks "how did you make this" or "can I trust the research," but it does not open the conversation. The design choice opens the conversation; the provenance defends it. Available-but-not-central is the only position that honors disclosure without surrendering the meeting.

Lead with the provenance and the meeting becomes a referendum on the AI. Hide it and you fail disclosure. The senior move is available-but-not-central: the design choice is the subject, the provenance is the appendix that defends it when asked.

Structuring the CPO-Ready Decision Memo

The memo is the instrument that enforces the structure, and its ordering is the whole design. It opens with the decision: here is the direction I am recommending and the one specific thing I need from you (greenlight to build, a choice between two options, a budget). A CPO reads for the decision first, so you lead with it. Then the rationale: here is the user problem, the key insight that drives the design, and why this direction serves it - grounded in the research but stated as a design argument, not a research dump. Then the prototype: here is the Figma Make URL, here is what to click, here is the moment that demonstrates the core idea. Only then, as a clearly-labeled appendix, the provenance: how the work was made, which tools, what was AI-generated and what was verified, with the verification log available.

This ordering does the work rhetorically. By the time a reader reaches the provenance appendix, they have already engaged with the decision, the rationale, and the prototype - the design is the established subject of the conversation, and the provenance arrives as supporting documentation rather than as the headline. A CPO who wants to interrogate the AI can flip to the appendix, and the fact that it is there, thorough and unflinching, signals confidence rather than concealment. The structure communicates "I am happy to show you exactly how this was made, and also, the point is the design." That is the posture you want: transparent and undefensive about the AI, but clear that it is not the topic.

The Provenance Appendix as a Trust Signal

Counterintuitively, the thoroughness of the provenance appendix is what lets you keep it out of the main conversation. A vague or defensive provenance note invites suspicion and pulls the topic toward AI; a thorough, confident one - here is every artifact, here is what AI did, here is how I verified it, here is the log - closes the question before it opens. When the appendix obviously contains the answer to "can I trust this," the CPO does not need to spend meeting time extracting it; they can trust that it is handled and stay on the design. Paradoxically, the most complete disclosure is the one least likely to derail the meeting, because completeness removes the doubt that derails it.

The Prototype in the Room: Figma Make Without the Framing Trap

The Figma Make prototype is the most persuasive and most dangerous object in the meeting. Persuasive because a working, clickable prototype lets the CPO feel the design instead of imagining it, which is worth more than any number of static frames. Dangerous because of the framing trap from the L2 Lovable lesson: a polished, app-like prototype can read as "this is two weeks from shipping" when it is actually an exploratory artifact, and a CPO who mistakes a prototype for a commitment makes decisions on a false premise. The Friday conversation has to get the persuasion without the misframing.

You do this by framing the prototype's status explicitly and early, the moment you put it on screen: "this is a working prototype to make the direction concrete - it is not a build, the engineering work is still to be scoped." That one sentence prevents the CPO from reading clickability as completeness. Then you direct the interaction: rather than handing over the prototype and letting them wander into the unfinished edges (where Figma Make's drift lives - the breakpoints, the states you did not build), you guide them to the moment that demonstrates the core idea. You are using the prototype as evidence for a specific design argument, not as a demo of a finished thing, and the framing sentence plus the guided path keeps it in that role. The prototype serves the design conversation; it does not become the conversation about whether it is real.

When the AI Question Comes Anyway

Sometimes a stakeholder asks the AI question directly: "did you just have AI do all this?" This is the moment the structure pays off, because you have a clean, confident answer ready and it does not rattle you. The answer has three parts. First, name what AI did, plainly and without defensiveness: "AI drafted the synthesis and generated the prototype, yes." Second, name what you did: "and I verified every research quote against source, hand-designed the hi-fi against our design system, and checked the prototype's behavior - it is in the appendix." Third, redirect to the design: "the provenance is all documented if you want to dig in, but the question I actually need your read on is whether this direction is right for the user problem."

That three-part answer - what AI did, what I did, back to the design - is non-defensive, honest, and re-centering. It does not minimize the AI (which would be dishonest) or apologize for it (which would cede the frame). It treats the AI's involvement as a settled, documented fact and moves the conversation back to where it belongs. A designer who can give that answer smoothly has internalized the whole point of this lesson: the AI is not a secret to hide or a badge to flaunt, it is a documented part of how the work was made, and the work is what is up for discussion. Rehearse the three-part answer, because the AI question will come, and the difference between fumbling it and handling it cleanly is the difference between losing the meeting to a provenance debate and keeping it on the design.

Why This Is the Capstone of the Loop

This lesson closes the chapter because it is where the compressed, verified, AI-augmented workflow meets the only judgment that ultimately matters: a stakeholder's. All the rigor of the prior six lessons - the sprint map, the verification tax, the HITL patterns, the reversibility test, the five-day loop, the verified synthesis - exists to produce a design decision that a CPO can confidently greenlight. If that final conversation derails into an AI referendum, the rigor was wasted, because the design never got its hearing. The available-but-not-central structure is what protects the rigor by keeping the meeting on the design, and the memo plus prototype is the instrument that enforces it.

It also models the mature relationship to AI that the whole program points toward. The anxious designer hides the AI or flaunts it; the integrated designer documents it thoroughly and then talks about the design, because they understand that AI is a tool in the workflow, not the story of the workflow. The CPO does not need a lecture on your AI process; they need a design decision they can trust, and the provenance is there to earn that trust quietly, not to be the headline. Walk in with the decision first, the design argument second, the prototype framed as exploratory, and the provenance ready in the appendix. Keep the conversation on the design. Answer the AI question cleanly if it comes. Get the greenlight. That is what five days of verified, AI-augmented work was for.

When the AI's Reliability Is Load-Bearing for the Recommendation

There is a subtle case the available-but-not-central rule has to bend for, and recognizing it is the mark of fluency rather than rote application. Sometimes the design recommendation does not just happen to use an AI-drafted synthesis; it rests on it. The CPO's confidence in greenlighting the direction legitimately depends on their confidence in the research, and their confidence in the research depends on the verification. In that case, burying the synthesis verification in the appendix is wrong, because you have hidden a load-bearing part of the rationale.

The resolution is to distinguish two things the appendix usually bundles together: tooling provenance and evidence-quality verification. The tooling provenance - which model generated the prototype, which tool drew the flows - stays in the appendix, because it is defensive documentation that does not bear on the decision. The evidence-quality verification - here are the lead findings, here are the verbatim quotes that support them, here is the log confirming those quotes against source - moves up into the rationale when the decision depends on it, but framed as evidence quality rather than as "the AI did this." You say "the recommendation rests on eight interviews; here are the findings with their verbatim support, verified against source," which foregrounds the evidence and its rigor (what the CPO needs to trust the decision) without foregrounding the AI tool (which would trigger the referendum). The principle still holds - the design and its evidence are central, the AI tooling is not - but when AI reliability is load-bearing, the verification of the evidence becomes part of the central argument while the fact that a model produced the draft stays peripheral. Getting this distinction right is what separates a designer applying a rule from one who understands why the rule exists.

The Positioning Stakes Across Many Meetings

The available-but-not-central structure is usually taught as a per-meeting tactic, but its deepest consequence is cumulative and career-level. A designer who consistently leads with the AI workflow builds, meeting by meeting, a reputation as an AI-process person - someone whose contribution is notable for the tooling rather than the judgment. That reputation has two costs: it invites repeated AI referendums that slow every decision, and it quietly signals that the designer operates tools rather than makes design calls, which erodes their standing as a design authority. This is precisely the prompt-monkey perception the entire program is built to help a designer escape, and leading with AI walks straight into it while feeling like confidence.

The designer who consistently uses available-but-not-central builds the opposite reputation over the same meetings: someone whose meetings are about design decisions, whose work is reliably trustworthy and provable on demand from the always-present appendix, and who is undefensive and transparent about AI without being defined by it. Over time, the first designer is remembered for their AI use and the second for their judgment, and in a market where judgment is the scarce, rewarded, hard-to-commoditize capability, that difference compounds into very different career trajectories. The structural choice you make in each Friday meeting is therefore not just about winning that meeting; it is a small repeated vote on whether you are known as the person who runs the tools or the person whose taste decides what ships. Choose the structure that compounds into design authority, because the tools will change every quarter and the reputation is what lasts.

Key Takeaways

• The Friday conversation threads a needle: lead with AI provenance and the meeting becomes a referendum on whether the AI did good work (the wrong conversation); hide the provenance and you fail the disclosure standard and burn trust when it surfaces.
• AI, once made salient, magnetizes the discussion toward itself - people interrogate an AI-assisted mock's provenance when they would never interrogate a hand-drawn one's. So do not make AI salient unless asked.
• The resolution is structural, not rhetorical: make the provenance available but not central. The design choice opens the conversation; the provenance is a thorough, clearly-labeled appendix that defends it when asked.
• Order the CPO memo: decision first, then rationale (a design argument, not a research dump), then the framed prototype, then the provenance appendix. By the time the reader reaches the provenance, the design is the established subject.
• The thoroughness of the provenance appendix is what keeps it out of the main conversation - a complete disclosure closes the trust question before it opens, while a vague one invites the suspicion that derails the meeting.
• Frame the Figma Make prototype's status explicitly and early ("a working prototype, not a build") to avoid the commitment-framing trap, and rehearse the three-part answer to the AI question: what AI did, what you did, back to the design.