Research to Executive Report

A documented method with reusable assets, not an import file.

You have research notes — excerpts, URLs, margin comments, three half-formed conclusions — and you need an executive report by Thursday. The failure mode is well known: you paste everything into a chat window, get fluent prose with invented confidence, and spend longer fact-checking than writing.

This page is the method we use. It has seven steps and four reusable assets: a copyable prompt, a report skeleton, an acceptance checklist, and a worked example whose input you can read in full. The prompt's job is not to write beautifully; it is to make gaps visible — an AI-drafted report that declares what it does not know is the only kind worth editing.

One-line conclusion: the bottleneck is not generation, it is evidence discipline. Only one of the seven steps is generation; the other six are selection, verification, and approval.

Who this is for — and who should skip it

For you if:

• you control the material (notes, links, data) and the deadline is in days, not hours;
• your readers can say yes or no to something (a purchase, a policy, a direction) — the method is built around a decision request;
• you will personally read every claim before it ships, or can name the human who will.

Skip it if:

• you need a literature review, not a decision document — the skeleton will fight you (rightly);
• the output is prose for its own sake (an essay, a post) — our Journal workflow is the better fit;
• nobody will read past page one — then write page one and stop; do not manufacture sections 3–6 to fill a template.

The method: seven steps

Step 1 — Freeze the question (10 minutes)

Write two sentences: who reads this, and what they will be asked to decide. Not "inform leadership about portability" but "get engineering leadership to approve or reject a portability policy for AI-generated documents by Sept 30". If you cannot write the decision, you are not ready for the notes — this is the single most common cause of dead reports.

Step 2 — Grade your sources (20 minutes)

Go through the notes and mark each source: primary (vendor doc, spec, your own measurement), secondary (coverage citing primaries), or opinion. In the worked example below, the Cloudflare redirect semantics are primary; a blog complaining about them is secondary. The grade goes into the evidence table later — an executive report that mixes vendor claims with vendor complaints at equal confidence is a liability.

Step 3 — Pick the skeleton, not the format (5 minutes)

Download report-skeleton.md. The section order — bottom line, decision request, evidence, self-verified claims, risks, options, recommendation — is the order executives read, which is the reverse of the order writers write. Work with the grain: fill section 3 (evidence) before section 1 (bottom line), even though it prints after it.

Step 4 — Draft with the prompt, not from a blank page (15 minutes)

Copy prompt.md, paste your notes between the <notes> tags untouched — the messiness is signal; cleaned-up inputs hide gaps — fill audience and goal, and run it. The prompt forces three things a default draft will not: one evidence row per claim, a why behind every confidence rating, and a "what we did NOT verify" section. Contradictions in your notes must surface as risks, not be smoothed over.

We run this step in AtomStorm Studio, which is what the button below pre-fills — with your material it takes one generation pass. The prompt is tool-agnostic and works in any capable assistant; wherever you run it, you own every claim it prints.

Step 5 — Attack the draft yourself (20 minutes)

Read only the evidence table. For each row: does the link open, does the source actually say this, and is the confidence grade honest? Delete or downgrade everything that fails. Then check the section-1 claims one by one against the surviving rows — a bottom line resting on a deleted row is how hallucinated confidence reaches an executive.

Step 6 — Human approval gate (one other person, 15 minutes)

Someone who was not in the notes reads sections 1, 5, and 7 and asks two questions: "what would change your recommendation?" and "which claim, if wrong, kills this?" Record the gate: who read it, when, which sections, and what they flagged. A read that surfaces nothing must say what was checked — "looks fine" alone is not a gate. Our own production notes live in the page footer.

Step 7 — Acceptance checklist, then ship (15 minutes)

Run all 18 lines of acceptance-checklist.md. Binary pass/fail, no partial credit; an unchecked box sends it back a step. Two lines deserve their reputations: "a 'what we did NOT verify' list is present, or the absence of gaps is itself justified" (a report listing zero gaps must say what was checked, not merely claim cleanliness) and "the exported file opens cleanly outside the authoring tool" — the portability smoke test. Keep the checked list with the report; six months from now it is your audit trail.

The worked example: real input, real output

Input — sample-input-research-notes.md: a genuine research-notes file on AI output portability — eight sourced excerpts (Cloudflare redirect semantics, template ecosystems, crawler policy layers, deliverability contracts), three synthesis observations, two open questions. Each excerpt notes the archive file it was drawn from; its Facts stay within what that source says, while the My note lines are the researcher's interpretation — the distinction this workflow exists to preserve. The notes are deliberately messy, the way real ones are.

The run — the step-4 prompt with AUDIENCE: engineering leadership and GOAL: approve or reject a portability policy for AI-generated documents by Sept 30, executed in AtomStorm Studio (Agentic mode, deepseek-v4-flash via our gateway) on 2026-09-08. Two generation passes (83s and 54s; about 17,000 output tokens total) produced the full report — unedited except for table formatting.

What the example shows — the model returned a conditional recommendation ("approve, but only after two checks we run ourselves pass") instead of a blanket verdict; it built a 20-row evidence table where every inference is labeled against its archive source; it cross-checked the Bing claim across two separate blog posts; and it listed nine things it did NOT verify. It also made one confident-looking mistake: risk R5 claims an input excerpt was truncated, but the source file is complete — exactly the kind of plausible-sounding claim step 5 exists to catch. This is what "gaps visible" looks like in practice: the report is trustworthy precisely where it admits uncertainty, and the reader's job is checking the flagged rows — including the checks the model says it already did.

What we verified — and what we did not

• Verified: the worked example was really run — its input excerpts were checked against their archived source files in our sample library (fetched 2026-09-04), and the output was generated in AtomStorm Studio on 2026-09-08 and recorded verbatim. The skeleton and checklists are the ones our own docs pass before they ship.
• Not verified: cross-model consistency of the step-4 prompt (we run it in one environment); long-run revision fidelity — regenerating a report after review comments — is exercised as a step but not benchmarked here.
• Not verifiable by us: whether your readers act on the report. That is your loop, and the decision request in step 1 is how you close it.

Limitations

The four we carry are declared in the page metadata and repeated where they bite: English-first publication; a single recorded run as the example, not a benchmark; a checklist tuned to an evidence-first editorial culture (teams with lighter review may find items 4 and 8 heavy); revision fidelity covered as practice, not measurement — the portability field test addresses it separately.

Take the assets

| Asset | What it is | |---|---| | Prompt | The step-4 generation prompt, copyable, tool-agnostic | | Report skeleton | Section order, per-section rules, acceptance hints | | Acceptance checklist | 18 binary gates; the ship/return decision | | Sample input | The real research notes behind the worked example | | Worked-example output | The real Studio-generated report, recorded verbatim |

The next action

Run the prompt on your own notes with your own audience line. The button opens AtomStorm Studio with this workflow's skeleton pre-filled — same method, your material, one generation pass to a draft you can attack.