How to Write a Research Brief With Sources: A Copyable Template
Make this article actionable
Send the article context into Vife Agent and turn it into a plan, checklist, or draft you can keep working on.
A research brief is a short document that tells a researcher — human or AI — what question to answer, who the answer is for, what is in scope, what claims are off-limits, what counts as an acceptable source, and how you will decide the work is done. If you can't fill in those six fields, you don't have a brief yet; you have a topic.
Quick answer
Write the brief in six blocks, in this order: question, audience and decision, scope, excluded claims, source criteria, acceptance checklist. Keep it to one page. Write the acceptance checklist before you commission the research, not after you read the draft — that is the difference between a brief and a wish list.
The most common failure is not a vague question. It's a missing excluded claims section. Without it, a researcher will happily fill the gaps in your question with plausible-sounding numbers, and you'll spend your review time deleting them instead of evaluating the argument.
Turn the useful parts into next steps
Vife Agent can convert this guide into a prioritized workflow with tasks, risks, and reusable prompts.
The six blocks, and what belongs in each
1. Question
One sentence, ending in a question mark. It must be answerable with evidence and narrow enough that a "no" or "it depends" is a legitimate answer. If your question can only be answered "yes," it's a thesis, not a research question.
Weak: Is our product good?
Workable: Which of three onboarding flows produces the fewest support tickets in the first 14 days, based on our own ticket data?
2. Audience and decision
Name the person who will act on the answer and the decision they're making. This controls depth, tone, and length. A brief for a pricing decision needs different evidence than a brief for a blog post.
3. Scope
State what's included: time period, geography, product versions, segments, and the specific sub-questions you want answered. Sub-questions are where most of the value lives — they turn a broad question into a checklist the researcher can work through.
4. Excluded claims
List the claim types you do not want asserted. Typical entries: no market-size figures, no competitor revenue estimates, no adoption percentages, no performance benchmarks, no forward-looking predictions, no customer quotes without written permission. This section protects you from having to fact-check things you never asked for.
5. Source criteria
Define what you'll accept. A practical hierarchy:
- Primary and internal: your own analytics, ticket logs, sales call notes, product telemetry.
- Primary and external: official documentation, published specifications, regulatory filings, vendor release notes.
- Secondary: reputable reporting that cites its own sources.
- Not acceptable: undated blog posts, aggregator listicles, screenshots without a source, anything whose only citation is another summary.
Require that every factual claim carry a source and a date. If a claim can't be sourced, it should be labeled as an assumption, not stated as fact.
6. Acceptance checklist
A short list of yes/no tests the deliverable must pass. Write it in the imperative. Example: "Every number has a source and a date." "Every recommendation traces to a finding." "Uncertainty is stated where evidence is thin."
Step-by-step workflow
- Write the question first, alone. If you can't, the problem is upstream — you need a decision, not research.
- Add audience and decision. One line each.
- Break the question into three to six sub-questions. These become the report's sections.
- Draw the scope boundary. Write the out-of-scope list explicitly; it's as useful as the in-scope list.
- Write the excluded claims list. Be specific about the numbers you don't want invented.
- Set source criteria and a recency window. "Published in the last 18 months, or explicitly flagged as historical."
- Write the acceptance checklist. Five to eight items, all testable.
- Add output format. Length, structure, and whether you want a summary table.
- Send it and ask one question back: "What's ambiguous?" Fix that before work starts.
- Review against the checklist, not against your mood. Mark each item pass or fail, then send one consolidated revision request.
Copyable template
# Research Brief: [short title]
Prepared by: [name] | Date: [date] | Version: [n]
## Question
[One sentence, ends in a question mark.]
## Audience and decision
Audience: [who reads this]
Decision: [what they will decide with it]
## Scope
In scope: [time period, geography, segments, product versions]
Sub-questions:
1. [sub-question]
2. [sub-question]
3. [sub-question]
Out of scope: [explicitly excluded topics]
## Excluded claims
Do not assert: [e.g. market size, competitor revenue, adoption rates,
performance benchmarks, forecasts, customer quotes without permission]
If evidence is missing, write "not established" instead of estimating.
## Source criteria
Acceptable: internal data, official documentation, published specs,
reputable reporting that cites primary sources.
Not acceptable: undated posts, aggregator listicles, unsourced screenshots.
Recency window: [e.g. published within the last 18 months]
Every factual claim must include a source and a date.
## Output format
[max words], sections matching the sub-questions, plus a summary table
of findings with a confidence column (high / medium / low).
## Acceptance checklist
- [ ] Every factual claim has a source and a date
- [ ] Every recommendation traces to a stated finding
- [ ] Excluded claims are absent
- [ ] Uncertainty is labeled, not smoothed over
- [ ] Summary table matches the body text
- [ ] Length within [n] wordsFictional example: a product research brief
Everything below is invented for illustration. It is not a real study, and no results are reported.
# Research Brief: Onboarding Drop-off (FICTIONAL EXAMPLE)
Prepared by: A. Rivera | Date: 2026-09-13 | Version: 1
## Question
At which step of the three-step onboarding flow do new workspace
creators abandon most often, and what do they do immediately after?
## Audience and decision
Audience: product lead and one designer.
Decision: whether to merge steps 2 and 3 in the next release.
## Scope
In scope: accounts created in the last 90 days; web only; free tier.
Sub-questions:
1. Abandonment rate per step, by device type.
2. Median time spent on each step.
3. Most common last action before abandoning.
4. Support tickets mentioning onboarding in the same window.
Out of scope: mobile app, paid tiers, pricing, competitor onboarding.
## Excluded claims
Do not assert: market-wide onboarding benchmarks, competitor
conversion rates, revenue impact estimates, or causal claims about
the redesign. Correlation only.
## Source criteria
Acceptable: internal funnel events, ticket exports, session logs.
Not acceptable: third-party benchmark posts, vendor marketing pages.
Recency window: last 90 days of event data.
## Output format
800 words max, one section per sub-question, plus a findings table
with a confidence column.
## Acceptance checklist
- [ ] Each rate is tied to a date range and a sample size
- [ ] No causal language about the proposed redesign
- [ ] Excluded claims absent
- [ ] Findings table matches the body
- [ ] Open questions listed at the endNote what the excluded-claims block is doing: it prevents the researcher from "helpfully" adding an industry benchmark that you'd then have to verify. It also prevents a correlation from being written up as a cause.
Sample prompt for an AI research pass
If you're using an AI workspace to draft or structure the work, paste the brief rather than a topic. A prompt that works:
You are working from the attached research brief. Answer only the sub-questions in the Scope section. For every factual claim, give the source and its date; if you cannot source a claim, write "not established." Do not include anything from the Excluded claims list. Return the output in the format specified, and end with a list of open questions and any place where the evidence is thin.
Two things to check before you rely on the output. First, whether the tool you're using can actually reach the sources you specified — availability and credit costs vary by model and change over time, so check the live model selector and the quote shown before you run anything. Second, whether the draft respects the excluded-claims list; that's the item most likely to fail.
Vife's research workspace is built around this kind of brief-driven pass: you bring the question, scope, and source rules, and it handles the gathering and structuring so you can spend your time on the checklist instead of the formatting. If you want to know what a run costs before committing, the pricing page shows how credits are quoted per task.
Output review checklist
Review in this order. Stop at the first failure and send it back — don't accumulate notes.
| Check | Pass condition | Subjective or measurable |
|---|---|---|
Question answered | The opening section answers the brief's question directly | Subjective |
Sub-question coverage | Every sub-question has a corresponding section | Measurable |
Sourcing | Every factual claim has a source and a date | Measurable |
Excluded claims | None of the listed claim types appear | Measurable |
Uncertainty | Thin evidence is labeled, not smoothed over | Subjective |
Traceability | Every recommendation maps to a stated finding | Measurable |
Format | Length and structure match the brief | Measurable |
Internal consistency | Summary table matches the body text | Measurable |
The measurable rows are the ones you can hand to someone else to verify. The subjective rows — whether the answer is actually useful, whether the uncertainty labeling is honest — are yours to judge, and they're the reason you don't outsource the review entirely.
Common mistakes
Briefing a topic instead of a question. "Research our competitors" produces a survey. "Which two competitors changed their free-tier limits in the last year, and how?" produces an answer.
Leaving excluded claims implicit. If you don't say "no market-size estimates," you will get market-size estimates.
Skipping the recency window. Without one, you'll get a mix of current and obsolete facts presented in the same tense.
Writing the checklist after the draft. Then it becomes a rationalization of whatever arrived.
Accepting a source that cites another summary. Trace one hop back. If the trail ends at a summary, the claim is unsupported.
Treating a confident tone as evidence. Fluency is not accuracy. The checklist exists because confident prose and well-sourced prose look identical on a first read.
Over-briefing. A brief longer than the deliverable is a sign you're avoiding the decision. One page is usually enough.
FAQ
How long should a research brief be? One page, or roughly 300–500 words. If it runs longer, you're probably writing the report.
Can I use the same brief for a human researcher and an AI tool? Yes, and you should. The six blocks are tool-agnostic. The only addition for an AI pass is an explicit instruction about what to do when a claim can't be sourced — "write 'not established'" is better than silence.
What if I don't know the source criteria yet? Start with the rule "every factual claim needs a source and a date," then tighten it after the first draft shows you which source types are actually available.
How do I handle a claim I believe but can't source? Move it to a separate "assumptions" section and label it. Never let it sit in the findings as if it were established.
Should the brief include the answer I expect? No. State the decision and the constraints, not the conclusion. A brief that telegraphs the desired answer gets you agreement instead of evidence.
What if the research comes back and the question was wrong? That's a valid outcome. Revise the brief and note what changed. A brief is a versioned document, not a contract.
Do I need a brief for a five-minute lookup? No. The brief earns its keep when the answer will inform a decision, when more than one person will read it, or when you'll need to defend the sourcing later.