The five-day loop's Monday step said "verify every quote against source" as if that were a single instruction. It is not. Trusting a Claude-synthesized research readout - trusting it enough to drive a roadmap decision, to defend in a design review, to put your name on - requires a verification pattern with structure, and that structure is the subject of this lesson. There are three moves that convert an AI synthesis from a plausible draft into a trustworthy insights document: source-quote traceability (every claim links to the verbatim it rests on), contradicting-evidence callouts (the synthesis surfaces the data that cuts against its own conclusions instead of smoothing it away), and a "what I don't know yet" section (the synthesis is explicit about the questions the data cannot answer). A synthesis with these three properties is one a designer can sign. A synthesis without them is a confident story that may or may not be true, and the difference is invisible until it costs you a quarter. The artifact is an insights doc plus a verification log - the doc you ship and the record of how you made it trustworthy.

Why a Synthesis Is Dangerous Precisely When It Is Good

A Claude-synthesized readout is dangerous in a specific way: it is fluent, structured, confident, and frequently right, which is exactly what makes its errors hard to catch. A bad synthesis you would reject on sight. A good-looking synthesis that is subtly wrong - that paraphrased the one verbatim that mattered, that asserted a pattern present in three transcripts as if it were in all eight, that quietly dropped the two participants who contradicted the headline - reads as authoritative and ships as truth. The model's fluency is not evidence of its accuracy; fluency is the thing the model is best at and accuracy is the thing you have to check, and conflating the two is how a research function gets quietly degraded while feeling more productive.

The verification pattern exists to break that conflation. It does not ask "does this synthesis sound right" - it always sounds right, that is the problem. It asks three sharper questions: can I trace each claim to its source, does the synthesis show me the evidence against itself, and is it honest about its own limits? These three questions target the three specific ways an AI synthesis lies - by distortion, by suppression, and by overreach - and a synthesis that survives all three is one whose confidence is earned rather than performed. The rest of this lesson is the three moves and how to build them into a document you can defend.

Move One: Source-Quote Traceability

The first move makes every claim in the synthesis link back to the specific verbatim evidence it rests on, so the claim can be checked at its root rather than taken on the model's word. In practice this means the insights doc never says "users found the onboarding confusing" as a bare assertion; it says "users found the onboarding confusing" followed by the actual quotes, attributed to participants, with enough context to confirm the quote means what the claim says it means. The traceability is the antidote to distortion - the failure mode where the model paraphrases "I stopped using it because I couldn't tell what it just did" into "users had concerns about feedback clarity," which is not a summary, it is a different and weaker claim.

The discipline is to structure the prompt so the model produces the quotes alongside the claims from the start - a structured synthesis prompt that demands verbatim extraction, not paraphrase - and then to verify the quotes against the source. The verification is fast for the right reason: a verbatim quote is string-matchable against the transcript, so confirming the quote is real and in-context is far cheaper than confirming a paraphrase is faithful. This is the narrowing move from the verification-tax lesson applied: you assign the model the part that is cheap to verify (extract these exact words) and you keep the expensive judgment (does this evidence support this claim) for yourself.

The Orphan-Claim Test

The traceability move has a sharp diagnostic: any claim in the synthesis with no quote attached is an orphan claim, and orphan claims are where the model's invention hides. A claim with three supporting quotes is grounded; a claim with zero is the model asserting a pattern it inferred, completed, or hallucinated, and it must either be grounded by finding the evidence (sometimes it is there and the model just did not cite it) or cut (often it is not there at all). Scanning the synthesis for orphan claims is the single fastest verification pass you can run, because it surfaces exactly the assertions that have no root, which are exactly the ones most likely to be fabricated.

Move Two: Contradicting-Evidence Callouts

The second move forces the synthesis to surface the evidence that cuts against its own conclusions, rather than smoothing it into a clean narrative. This is the antidote to suppression - the failure mode where the model, asked to find patterns, finds them too well, presenting a tidy story that erases the participants who did not fit. Real research is messy; eight people rarely agree, and the disagreement is often the most important signal. A synthesis that reports "users want X" when six wanted X and two emphatically did not has not summarized the research, it has averaged it, and the two dissenters might be the early signal of the segment that will churn.

The move is to explicitly prompt for and then verify a contradicting-evidence section: for each major finding, what evidence in the data argues against it, and how strong is that counter-evidence? A finding that says "users want a simplified dashboard (6 of 8), but 2 power users explicitly wanted more density, and they were the highest-value segment" is a finding you can actually make a decision with, because it shows you the trade-off instead of hiding it. The verification here is to read the sources looking specifically for the dissent the synthesis should have surfaced - if you find contradicting evidence in the transcripts that the synthesis did not call out, the synthesis suppressed it, and you add it back. A synthesis that contains no contradicting evidence across eight messy interviews is not clean; it is incomplete, and its cleanliness is the warning sign.

An AI synthesis lies in three ways: distortion (paraphrasing away the quote that matters), suppression (smoothing away the evidence against itself), and overreach (asserting beyond what the data supports). Traceability, contradicting-evidence callouts, and a "what I don't know yet" section are the three antidotes.

Move Three: The "What I Don't Know Yet" Section

The third move makes the synthesis explicit about its own limits - the questions the data cannot answer, the segments it did not reach, the conclusions that are hypotheses rather than findings. This is the antidote to overreach, the failure mode where the model answers questions the data does not support because it was asked to produce a synthesis and producing confident conclusions is what synthesis looks like. A model will rarely volunteer "we don't actually know this yet" unless you force it, because hedging reads as a worse synthesis, and the model optimizes for the synthesis that reads well.

The "what I don't know yet" section is where you reinsert the epistemic honesty the model strips out. It names the boundaries: we interviewed eight existing users, so we know nothing about people who churned or never signed up; the data tells us users find the dashboard confusing but not whether a simpler dashboard would retain them, which is a hypothesis we would need to test; we have strong signal on the onboarding pain and weak signal on the pricing concern, which appeared in only one interview. This section is not a weakness in the document; it is the most senior thing in it, because it is the part that prevents the synthesis from being over-trusted downstream. A readout that knows what it does not know is one a CPO can build on safely; a readout that projects certainty across its blind spots is a trap, and the trap springs when someone bets a roadmap on the part you never actually learned.

Building the Insights Doc and the Verification Log

The artifact is two paired documents. The insights doc is what you ship: findings, each with traceable quotes, each with its contradicting evidence called out, and a clear "what we don't know yet" section. It is structured so a reader can see not just the conclusions but the evidence and the limits, which is what makes it trustworthy rather than merely confident. The verification log is the record of how you made the doc trustworthy: which quotes you checked against source and what you found (including the distortions you corrected), which contradicting evidence you added back that the model had suppressed, and which overreaching claims you demoted to hypotheses or cut.

The verification log is the part that earns the trust, and it is the part that survives the interrogation. When someone asks "how do I know this synthesis is reliable," the insights doc shows them the grounded conclusions and the log shows them the work - here are the seven quotes I corrected because the model paraphrased them, here is the dissent I restored, here is the claim I cut because it had no evidence. The log converts "trust me, I verified it" into "here is the verification," which is the difference between a designer asserting reliability and a designer demonstrating it. It is the same move as the provenance log in the five-day loop, focused specifically on the synthesis step where the model's failure modes are most dangerous and most invisible.

The Log Is Also a Prompt-Improvement Tool

A useful side effect: the verification log tells you where your synthesis prompt is weak. If you find yourself correcting the same kind of error every time - the model consistently paraphrases away emotional verbatims, or consistently suppresses minority views - that is a signal to harden the prompt against that specific failure, demanding verbatim emotional quotes, demanding a dissent section. The log turns each verification pass into data about how to make the next synthesis need less verification, which is how the verification tax on this step goes down over time without lowering your standards. You are not just catching the model's errors; you are learning its error patterns and pre-empting them.

Why This Is the Research Function's Survival Skill

The pressure on research synthesis in 2026 is brutal and specific: the PM wants the readout Friday, you used to have two weeks, and "you have AI for that" is said as if it settled the matter. The naive response is to ship the AI synthesis fast and hope. The cynical response is to refuse AI and miss the deadline. The senior response is this verification pattern: use the AI to produce the draft synthesis fast, then run the three moves to make it trustworthy, and ship a readout that is both fast and defensible. The verification pattern is what lets you say yes to the speed without saying yes to the degradation, which is the only sustainable answer to the pressure.

It is also what protects the research function's credibility, which is the thing actually at stake. A research function that ships fast AI syntheses that turn out to be subtly wrong loses the trust of the product team, and once research is not trusted it is not consulted, and once it is not consulted it is cut. The verification pattern is how research stays trustworthy under speed pressure, and trustworthiness is the only thing that keeps research in the room. A designer who can produce a verified insights doc with its log is not just doing good synthesis; they are defending the legitimacy of evidence-based design at a moment when "we have AI for that" threatens to replace evidence with confident-sounding average. The three moves - traceability, contradicting evidence, known limits - are how you keep the synthesis honest, and an honest synthesis is the only kind worth shipping fast.

What the Pattern Cannot Do: Verifying a Study That Should Not Be Trusted

There is a limit to the verification pattern that you must hold in view, or the pattern becomes a way to launder bad research into credible-looking findings. The three moves check that the synthesis faithfully represents the data. They do not check that the data is any good. A perfectly verified synthesis of a biased study - a leading interview guide, eight participants who all came from one acquisition channel, a sample that excludes the users who churned - is a trustworthy representation of biased evidence, which is more dangerous than an obvious mess precisely because the verification makes it look sound.

The fix lives upstream of synthesis, in study design, and it surfaces in the "what I don't know yet" section as a stated limit. When all eight participants came from paid search, the honest synthesis does not present its findings as representative of all users; it names the boundary - "we know nothing about organic or referral users, and the sample skews toward a single acquisition channel." So the pattern's honest output for a flawed study is not a confident readout but a synthesis whose limits section discloses the sampling and design weaknesses, which is exactly what prevents the laundering. The lesson is that verification ensures faithful representation, and study-design awareness, surfaced as a limit, prevents faithfully representing the wrong thing. A designer who runs the three moves but never asks whether the study itself was sound has a sharp tool pointed at possibly-rotten wood, and the verification log will record a clean process that produced a trustworthy-looking but ungrounded result.

Who Authors the Insight, the Model or You

Underneath the three moves is a question about authorship that is worth making explicit, because it reframes why the pattern matters. Authorship of an insight is not about who generated the words; it is about who is accountable for the claims being true. When you trace every claim to evidence, you take responsibility for each claim's grounding. When you surface contradicting evidence, you take responsibility for the synthesis being complete rather than merely convenient. When you state the limits, you take responsibility for the scope of what is asserted. The model produced a draft, but it is your verification that converts the draft into an insight someone can act on, and the corrections, restorations, and cuts in the verification log are the literal marks of your authorship - the places where your judgment overrode the model's.

This is why a synthesis shipped unverified is, in the only sense that matters, authored by the model: no human stands behind its truth. A synthesis that passed the three moves is authored by you, because you have made yourself accountable for it. The verification pattern is therefore not a check imposed on the model's authorship; it is the mechanism by which you claim authorship. That distinction is what keeps research a human discipline rather than a model output, and it is what lets you put your name on a forty-minute synthesis without flinching. You did not write every word, but you are accountable for every claim, and accountability, not keystrokes, is what authorship has always meant.

Key Takeaways

• An AI synthesis is dangerous precisely when it is good: fluent, confident, and frequently right, which makes its subtle errors read as authoritative and ship as truth. Fluency is what the model is best at; accuracy is what you must check.
• A synthesis lies in three ways: distortion (paraphrasing away the quote that matters), suppression (smoothing away evidence against itself), and overreach (asserting beyond what the data supports). The three verification moves are the antidotes.
• Source-quote traceability: every claim links to its verbatim evidence; the orphan-claim test (any claim with no quote attached) is the fastest pass for finding the model's invention. Verbatim quotes are cheap to verify by string-match; the expensive judgment of whether the evidence supports the claim stays yours.
• Contradicting-evidence callouts: for each finding, surface the evidence against it. A synthesis with no contradicting evidence across eight messy interviews is not clean, it is incomplete - and the two dissenters are often the most important signal.
• The "what I don't know yet" section is the most senior part of the document, not a weakness: it names the blind spots so the synthesis cannot be over-trusted downstream, where betting a roadmap on the part you never learned is how the trap springs.
• Ship the insights doc plus a verification log. The log converts "trust me, I verified it" into "here is the verification," doubles as a prompt-improvement tool, and is how the research function stays trustworthy - and therefore stays in the room - under "you have AI for that" pressure.