AI Adoption GuideResearchHand Over
Audience-tailored briefs
One corpus into exec, technical, operational versions; caveats unhideable
Research processScopeSourceTriageShallow AssessDeep AssessDecideHand Over
By Don, DoneThat’s AI coach · updated
One claim set rendered three ways, not three documents
Research leads reach hand-over with a finished evidence base and three audiences who will not read the same page. An executive committee wants the call and the risk attached to it. A technical reviewer wants the method, the exclusions, and the places the evidence thinned out. An operations lead wants what changes next week and who has to change it. Writing three documents by hand produces three slightly different stories, and six months later nobody can say which one was the review.
What this produces is one numbered claim set with three renderings. Claim 12 is claim 12 in every version. The executive rendering may state it in a sentence, the technical rendering may spend a paragraph on how it was tested, and the operational rendering may turn it into a step. All three point at the same claim identifier and the same sources.
Renderings are not summaries of each other. Drafting the executive version from the technical version, then the operational version from the executive version, is a chain of compressions. Each hop drops a qualifier. By the third document the finding has become an instruction with no visible evidence behind it.
The thing that must survive every rendering is the caveat. A claim that holds only for one population, one time window, or one cost assumption carries that condition in every version, including the shortest one. If a caveat does not fit in a rendering, the claim does not belong in that rendering either.
Number the claims and record their conditions before any rendering runs
Build the claim register first. Each row holds an identifier, the claim in one sentence, the sources behind it, the strength the review assigned, and the conditions under which it holds. Renderings read that register. They do not read the finished report prose, because prose already blends claims, hedges, and transitions in ways a model will flatten.
Conditions belong in a separate field, not inside the claim sentence. Population, time window, geography, cost assumptions, and the parts of the question the review never covered all sit there. Keeping them separate is what lets the pipeline refuse to drop them.
Define each audience as a shape, not as a job title. Write down what the executive rendering may contain: length, whether it may carry numbers, whether it names sources. Do the same for the technical and operational versions. "Make it shorter for leadership" is not a specification, and it is the instruction that produces confident one-pagers.
Set the failure behavior. If a claim has no source, no strength, or no condition field, the pipeline leaves it out and lists it as unrendered rather than smoothing it into a sentence. That list is short and worth reading. It usually shows which parts of the review were written from memory. Claim-level checks of the kind described in verifying that each citation supports its claim belong upstream of this register, not inside the rendering step.
Caveats stay attached at the sentence, not in an appendix
Put the condition next to the claim in every rendering. An appendix labeled limitations is where caveats go to be skipped. A committee reading a two-page brief will not turn to page nine, and the operations lead printing the checklist will not print the appendix at all.
The practical rule is simple. If the claim appears, the condition appears in the same paragraph or the same table row. If space forces a choice, cut the claim and keep the qualifier attached to whatever remains.
Conditions disappear in three ways. Rounding removes them, when a range collapses into a point estimate. Voice removes them, when "the evidence suggests" becomes "the analysis shows." Ordering removes them, when the caveat drops below the recommendation and starts reading as a formality.
Strength language needs the same discipline. A claim resting on two studies and a claim resting on a decade of consistent results should not read the same way in the executive version. Carry the strength label the review assigned. If the round expressed confidence as a distribution, as in a decision register that records probabilities, keep the distribution instead of translating it into "likely."
Render a remote monitoring review for a committee, a clinician, and a ward lead
This walkthrough is hypothetical and the numbers are illustrative. A hospital evidence unit has finished a review on remote cardiac monitoring after discharge. The claim register holds 41 claims. Nine are load-bearing for the decision. Six carry conditions that change what the finding means.
The committee version runs two pages. It carries the nine load-bearing claims, each in one sentence, each with its condition in that same sentence. Claim 7 states that the readmission benefit was observed in patients discharged with a documented follow-up appointment, and that the review found no evidence for patients without one. The condition is the second half of the sentence, not a footnote.
The clinical version runs eleven pages. It carries all 41 claims, the search strategy, the exclusion counts, and the four claims where two sources disagreed. It names the three studies behind claim 7 and the population each one enrolled.
The ward operations version runs four pages and is organized by task rather than by claim. It states which patients qualify, what has to exist before discharge, and who checks the alert queue. Claim 7 appears here as an eligibility rule, carrying the same condition: no documented follow-up appointment, no enrollment.
Two claims never render. Claim 22 lost its source rows when the register was rebuilt, and claim 31 has no condition field at all. Both land on the unrendered list that goes to the lead analyst, who finds that claim 31 was carried over from an early draft and never checked.
Compression turns a qualified finding into an instruction
The failure is not that a rendering is wrong. It is that the shortest rendering travels furthest and carries the least evidence.
Executive renderings drift toward recommendation. A model asked to make something decision-ready will convert "the evidence supports X under conditions Y" into "do X." Keep the imperative mood out of the claim section, and keep recommendations in a separate part of the document with a named author.
Operational renderings drift toward completeness. A checklist with a gap looks unfinished, so the pipeline fills the gap with a plausible step the review never examined. Any step with no claim identifier behind it should be labeled operational judgment and attributed to the person who added it.
Technical renderings drift toward volume. Everything is included, nothing is ordered, and the reviewer who most needed the four disagreements reads none of them. Priority ordering is part of the rendering, not a formatting preference.
The last failure is quiet. Three renderings go out, one gets revised in a meeting, and the other two are never updated. Version the renderings against the register and reissue all three when a claim changes. A committee working from claim 7 as written in March, after claim 7 was amended in May, is worse off than one working from nothing.
The lead analyst signs each rendering, including the short one
Someone puts a name on every version that leaves the unit. Not the pipeline, not the register. A person reads the two-page committee version against the full claim register and confirms that nothing in it overstates what the evidence supports.
That review is short and specific. Check that every claim in the short version carries its condition. Check that no sentence says more than its row in the register. Check that the recommendation section, if one exists, is separated from the claim section and attributed.
Questions the review could not settle do not get absorbed into a rendering. They travel as their own artifact, structured the way unresolved uncertainties packaged as briefs describes, so the recipient can see what stayed open instead of inferring it from a hedge.
Keep the renderings together after they ship. Filing all three plus the register in a searchable store of decision artifacts lets a later reader see what the committee was actually shown, which is usually the question when a decision gets revisited. Discussion that happens after the briefs land belongs with minutes that capture the disagreement, not folded back into the claim text.
The register stays the source. Renderings are derived and disposable. When the two disagree, the register wins and the rendering gets rebuilt.
Is this worth automating for you?
Whether this pays back depends on how much time it takes your team today. Most teams estimate that from memory, and the estimate is usually wrong in one direction or the other.
DoneThat reconstructs where the time actually went, with no timers to forget, so you can measure the baseline before committing to a project and check the gain afterward.
Measure the baseline first