How to Write an AI Research Brief: Scope, Sources and Stop Rules

Neutron Says Team · October 20, 2026 · 8 min read · Research, AI research, research methods, research brief

Define the question, evidence and stopping point before you start searching. A reusable brief and worked example help make research easier to review.

A research session can go wrong before the first answer appears. “Research the best way to do this” leaves the tool to choose the audience, the meaning of “best,” the sources and the point at which the work is finished. You may receive a polished answer to a different question from the one you needed answered.

Write a short research brief first. It should explain what you need to learn, what evidence would answer the question and what must remain unresolved if that evidence is missing.

The brief below is a planning tool, not a guarantee of accurate output. NIST identifies confidently false AI output, including fabricated supporting material, as a generative-AI risk. Clear instructions do not remove the need to inspect evidence. NIST's Generative AI Profile, section 2.2

1. Name the question and the reader

Start with two sentences:

Question: What exactly must this research establish?
Reader and use: Who will read the result, and what will they do with it?

“Research file exports” is a topic. “Which export formats do the current public help pages for two task trackers document, and what would our team need to test before moving its project history?” is a research question.

The second version separates a documentation check from an actual migration test. It also identifies what the result is for.

George Mason University's writing guidance emphasizes clear, focused questions and attention to the audience. Its advice is written for academic research; the useful principle here is to narrow the question enough to answer it within the work you can actually do. A practical documentation lookup does not need an arguable thesis. George Mason University Writing Center

Ask the tool to restate the question before researching. If its restatement introduces a recommendation, a new audience or an assumed outcome, correct that first.

2. Choose the kind of answer you need

Different tasks need different deliverables. Pick one primary job:

Explain: Define a concept and show how its parts relate.
Check: Establish whether a specific, verifiable claim is supported.
Compare: Apply the same criteria to several options.
Map: Identify what is known, disputed or still missing.
Plan a test: Turn unresolved claims into checks someone can perform.

A comparison does not have to end with a winner. A map of missing evidence may be more useful than a forced recommendation.

For example, a public documentation review can establish that a vendor describes a CSV export. It cannot, by itself, establish that your own account exports every field correctly. Put that distinction in the brief so the final answer does not silently turn a documented feature into a tested result.

3. Set boundaries that change the answer

Include the boundaries that matter to this question, rather than filling every possible field:

Time: A current snapshot, a historical period or changes between two dates?
Version: Which product edition, document revision or software release?
Place: Does the question depend on a country, region or institution?
Population or system: Whose experience, or which environment, is in scope?
Exclusions: Which related questions should this task leave alone?

Avoid “use recent sources” when you can say what recent means. For a current software feature, ask for the current official documentation and note any version limits. For a historical question, an older primary document may be exactly the evidence you need.

Also state what you will not supply. An initial public-source review should not need private customer records or internal credentials. Use fictional examples where real records are unnecessary.

4. Plan sources before collecting links

Decide which source types can support each kind of claim.

For the task-tracker example, the vendor's help page can support a claim about what its documentation says. A dated release note can establish when a documented change was announced. Neither is an independent test of a real export.

A reviewer's anecdote might suggest a useful test case. It should not quietly replace current documentation or become proof that every account behaves the same way.

Add a simple evidence instruction:

For each substantive finding, identify the source, the relevant passage or section, the date or version when available, and what the source does not establish. Separate documented statements, your interpretations and checks that still need to be performed.

This is an editorial structure, not a requirement to find a fixed number of links. Five pages repeating one announcement do not answer five different evidence gaps.

5. Include search terms and allow revision

List the central concepts and a few alternate terms. In our example, “export,” “download,” “backup” and “data portability” may lead to different documentation sections. They are search leads, not interchangeable feature claims.

Yale University Library recommends starting with important concepts, looking for new terms in relevant sources and refining searches as you learn. Its guidance also explains Boolean operators and filters for catalogs and databases. Check the search system's own syntax rather than assuming every tool interprets the same query identically. Yale University Library: Search Strategies

Give the researcher permission to revise the brief, but require the revision to be visible:

If the initial terms miss relevant material, propose better terms and explain why. If the question is too broad or cannot be answered with the allowed evidence, say so before expanding the scope.

That instruction lets the research evolve without quietly changing its purpose.

6. Define completion and a useful stopping point

A deadline and a completed answer are different things. Set both when needed.

Completion conditions describe what the result must contain. For a documentation comparison, you might require the same fields for each product, source links beside the findings and an explicit list of unresolved questions.

Stop conditions describe when to report a limit rather than keep trying to fill a gap. Examples include required evidence you cannot access, conflicting version information or a question that needs an account-level test you have not authorized. Record an inaccessible page and continue reviewing other useful, in-scope sources; stop the affected part when the missing evidence prevents an answer.

A time limit can end a research pass, but it should not convert missing evidence into certainty. Ask for a partial result labeled with its limits.

Avoid instructions such as “keep searching until you prove this.” They preselect the conclusion. A better instruction is: “Look for evidence that would change the initial interpretation, and preserve meaningful disagreements.”

A copyable AI research brief template

Use this as a starting point. Delete fields that do not matter.

Question: What specific question should the research answer?

Reader and use: Who needs the answer, and how will they use it?

Task type: Explain, check, compare, map evidence or plan a test.

Scope: Relevant dates, versions, places and systems. State exclusions.

Evidence plan: Which source types can support the claims? Which sources are leads only? Identify unavailable evidence.

Search terms: Main concepts, alternate terms and likely official sources. Propose revisions when needed.

Output: Requested length and structure. Keep sourced findings, interpretations and unknowns distinct. Link the supporting sources beside the findings.

Completion: What must be covered for the task to be answered?

Stop and report: What should trigger an incomplete result, a narrower question or a request for a separately authorized test?

Review: Restate the question and flag unsupported assumptions before starting. Do not invent a missing source, result or test.

The template deliberately does not ask for a confidence percentage. A number without a defined assessment method may communicate more precision than the evidence supports.

Worked example: a public-documentation comparison

The following example is fictional. “Tracker A” and “Tracker B” are placeholders, and no feature findings or model test results are being reported.

Question: What do the current public help pages for Tracker A and Tracker B say about exporting tasks, comments and attachments?

Reader and use: A project coordinator preparing an internal migration test plan. The result will identify checks to run, not select a vendor.

Scope: Public documentation as of the research date. Record plan or version restrictions when stated. Exclude pricing, security certification, legal compliance and actual account exports.

Evidence plan: Use each vendor's official help pages and relevant release notes. Label every finding as a documented statement. If a field is not addressed, write “not established by the pages reviewed,” rather than “unsupported by the product.”

Search terms: Product name plus export, download, backup, tasks, comments and attachments. Keep a short list of pages reviewed so another person can repeat the review.

Output: A short summary, the same three content categories for each product, source links and a separate test checklist. Do not rank the products.

Completion and stopping: Cover each category or identify the missing evidence. If a page is inaccessible or contradicts another current page, report the issue. Do not sign in, upload data or run exports as part of this research pass.

Notice the most important result this brief permits: “We do not yet know.” If attachment behavior is unclear, the handoff can propose a future authorized test using synthetic files. It does not have to fill the gap with a guess.

Review the answer against the brief

Before sharing the result, ask:

Does it answer the original question for the intended reader?
Did the scope or date range change without being stated?
Are claims about documentation clearly separate from observed tests?
Are missing evidence and meaningful disagreements still visible?
Does the next step follow from the result, without implying permission to take it?

Then inspect the sources. Our guide to verifying AI-generated citations covers the checks after an answer has been produced; this brief helps define the work before that answer exists.

If you use Neutron for the research, first review its current sourcing and limitations information. Use the brief to make your question explicit, and check the returned evidence before relying on the result. A good brief gives you a standard for reviewing the work. It does not replace that review.