Oracle Services
When a Research Clarification Becomes a Scope Change
2026-09-10
A scope change occurs when a request alters what must be established, the data required, the operating conditions or the promised deliverable. Asking where a number came from is a clarification. Correcting a wrongly implemented agreed metric is defect correction. Requiring the result to hold in a new population or support a causal claim is new research. Record the distinction before continuing so both the scientific record and the commercial agreement stay clear.
The dangerous word is also
A computational review is nearly finished when somebody asks whether the method also works for a second market, another archive or a different failure condition. The request sounds small because it adds one sentence. Scientifically, it can change the target population, available measurements and evaluation design.
This does not mean the researcher should resist useful questions. It means the extra question deserves to be made visible. Hidden scope growth can damage both parties: the client thinks an important claim was covered, while the supplier treats it as an informal aside. Later, the report circulates without that distinction and the unsupported extension becomes part of the story.
Use a three-way classification
Consider a hypothetical retrospective demand-forecasting commission. Its agreed output is a comparison on one public regional archive. The requests below look similar in an email thread but create different obligations. The classification should follow the written scope rather than the supplier's convenience.
| Request | Classification | Action |
|---|---|---|
| Explain the baseline equation | Clarification | Explain and link the existing implementation |
| Fix the agreed metric calculated incorrectly | Defect correction | Correct affected outputs and document impact |
| Evaluate a second country's archive | Scope change | Assess compatibility, effort and new acceptance criteria |
| Show the method causes lower operating costs | New claim | Define what additional evidence could address it |
Freeze the identity of the question
A short scope record should identify the decision, dataset version, principal metric, comparison, expected output and limitations. If these are vague, every later request becomes an argument about what was implied. Precision at the start is usually kinder than a long dispute at the end.
NASA's configuration-management guidance describes controlling changes to established technical baselines. The lightweight adaptation here is a numbered scope version and a change log. This is a project-management recommendation, not a claim that a small consultancy follows NASA's full engineering process or that the example creates enforceable contract terms.
Sources: NASA: Crosscutting Technical Management.
Keep discovery open without rewriting history
Exploration may reveal a genuinely better question. Preserve that opportunity by opening a clearly labelled branch rather than altering the original analysis until it tells a more attractive story. The original result still matters, particularly when it was disappointing. A new direction can be promising while the first hypothesis remains unsupported.
The Center for Open Science's planning guidance distinguishes analyses specified in advance from later exploration. For an existing-data project, record what was already known when each choice was made. A newly discovered subgroup or revised metric should not be described as a prior prediction simply because it now fits neatly into the final report.
Sources: Center for Open Science: Lifecycle Open Science.
Use a compact change note
A useful change note fits on one screen: the new request, why it matters, which earlier assumptions it alters, what extra work is needed, its cost or timing implications, and who approves it. Include the option not to proceed. Not every interesting extension deserves a new commission.
For example: the second archive uses weekly rather than daily labels, so the original metric cannot be transferred unchanged. The next step is a compatibility review, not an immediate performance promise. That sentence prevents an apparently simple rerun from becoming a misleading comparison.
End each milestone with a status for both the original and revised questions. The client should never have to infer whether a result was delivered, superseded, corrected or left open. Fast collaboration becomes easier when scientific curiosity can expand without silently expanding the bill or the claim.
Questions this raises
Is every new client question billable?
No. Clarifications and agreed defect corrections differ from new research. The written scope and commercial terms determine how each is handled.
What if the original question turns out to be unanswerable?
Document why and what was checked. Propose a narrower or different question separately, with explicit approval before treating it as the replacement commission.
Sources and their limits
- NASA: Crosscutting Technical Management. Supports the concept of controlled technical baselines and configuration changes; the commercial examples are original.
- Center for Open Science: Lifecycle Open Science. Supports transparent distinction between planned analyses, deviations and later exploration.
Prepared with AI assistance. The linked sources support the specified technical points; they do not validate applied psionics as a whole or guarantee a result for a client.
Read the editorial and evidence standard.
Continue reading
Explore Scientific Oracle consultingfor a scoped review of an existing-data research decision. Start with a non-confidential outline of the question, available evidence and the decision it needs to inform.