Operating · Lesson 35 — Research isn't done until the handoff brief is written
O35Operating
Operating · Lesson 35● live

Research isn't done until the handoff brief is written

The QC physics audit produced runnable models, a dozen figures, and a stack of CSVs. The artifact that mattered three weeks later was none of them — it was a short brief written for the engineers who have to act on the findings.

10 min read · 25 min applycompanion: Run a falsification session before you trust your own asset

Findings die in the chat log

The July session that audited Quantum Caddy's throw simulator produced a dozen figures, a stack of CSVs, and two runnable physics models. An impressive pile, and a pile that lives where analysis goes to die: a session transcript and an outputs folder whose meaning depends on remembering the conversation that produced it. Six months from now that transcript will be as useful to us as someone else's lab notebook.

The artifact that survived contact with the following weeks was different in kind. After the analysis was done, the session wrote a separate brief addressed to the people who have to act on the results: the engineering side of QC, who are building the vision pipeline and, eventually, the scoring predictor. The brief says what must be measured, what may be built now, what numbers to use in the meantime, and what cannot be trusted yet. Nobody has reopened the transcript since. The brief gets opened every time we plan work.

The distinction is worth stating plainly. Findings are the residue of work you did. A handoff brief is an instruction set for work someone else must do. Research that stops at findings has quietly decided its only consumer is the researcher.

Five parts, in the order the reader needs them

I'm going to describe the structure of our brief rather than its contents, partly because the contents are the IP-sensitive core of QC and partly because the structure is the transferable part.

  • Status: one line, with the honest validation state built in. Ours opens by saying that the physics is understood and a corrected model exists, but no real throws have ever been measured, so everything below is priors and structure rather than ground truth. That sentence sets the trust level for every number that follows. Most research summaries bury this qualifier on page four; putting it in line one is the single highest-value habit here.
  • Requirements: what the downstream team must produce, phrased as requirements rather than suggestions. Ours states which physical quantities the vision pipeline has to recover from each throw and why each one matters to scoring. I'm deliberately not reproducing that list; the point is the phrasing. "Must recover X" gives an engineer something to build against. "X would be useful" gives them permission to defer it forever.
  • Priors: the numbers to use until measurement replaces them, each with an uncertainty band. This is the table that stops the downstream team from either inventing their own constants or treating research estimates as truth. Every entry carries an implicit expiry date: the moment a real measurement lands, the prior retires.
  • Do-not list: what must not be built or trained yet, with the reason attached to each line. The strongest sentence in our brief is a prohibition: never train an outcome head on simulated labels. It carries a number, because the audit showed 48.3 percent of the simulator's outcomes flip under corrected physics. A prohibition with a number survives arguments that a warning does not.
  • Measurements: a prioritized list of what to measure next, each item tied to the uncertainty it retires. Ours is a ranked list of six experiments. It can rank them honestly because the sensitivity analysis showed one coefficient driving about three times more scoring error than any other, which is how a brief earns the right to say measure friction first.

Two honest limits. A brief inherits the authority ceiling of the analysis behind it: ours rests on a model-versus-model audit with zero real measurements, and if the status line didn't say so, the priors table would read as more validated than it is. The format makes overclaiming legible; it doesn't prevent it. And I have exactly one data point on the format itself, three weeks of one consumer using one brief. Ask me in six months whether the requirements section survived contact with actual measurement work.

A findings document faces backward

The two documents can contain identical information and still do different jobs.

  • Audience: a findings document is written for the author and the author's future self, so it assumes the room. A handoff brief is addressed to a named consumer who wasn't there, so every claim has to stand without the conversation around it.
  • Tense: findings are written in the past tense, reporting what was compared and found. A handoff brief is written in the imperative: measure this, hold off on that. The tense shift forces decisions. To write "measure friction first," someone has to actually decide friction comes first.
  • Shelf life: findings decay as the context that produced them fades. A handoff brief stays operative until its requirements are met, and it expires line by line as each measurement retires a prior and crosses off a queue item.

The test I now run at the end of any research push, whether it's a physics audit, a demand model for Mile High Golf, or a competitive sweep for a pitch: could someone who never saw the analysis act correctly this week using only the final document? If answering requires the transcript, the research isn't done.

Apply this

Take your last research effort that ended in findings: a demand forecast, a risk model, a pricing study, a game simulation. Write its missing handoff brief today, in this order.

  • Name the consumer at the top. A role or a person, never "stakeholders." If no honest name exists, you've learned the research had no customer, which is a finding in itself.
  • Write the status line. One sentence with the validation state stated plainly, in the shape of:

[What exists and works], but [what has never been validated]. Treat the numbers below as priors until [the missing measurement] replaces them.

  • List the requirements. Three to seven statements of what the consumer must produce or measure, each phrased as must. If everything wants to be a "could," the analysis hasn't reached a conclusion yet.
  • Build the priors table. Every number the consumer should use in the meantime, each with an uncertainty band and the measurement that will retire it.
  • Write the do-not list. What must not be built, shipped, or trained yet, each entry carrying its reason and, wherever possible, its number.
  • Rank the measurements. Order by how much uncertainty each one retires, never by how easy it is to collect. The top item is the sentence your consumer will remember.

Budget about twenty-five minutes for a first pass, and expect the requirements section to be the slow part, because that's where analysis turns into commitment. Then send the brief to the named consumer and ask one question: what would you do differently this week because of this? If the answer is nothing, either the brief needs another pass or the research does.

Operating tier · what's next

After this lesson