Definition
The BIS Guidelines define scientific or technological uncertainty as existing when "the outcome of a project cannot be known or deduced in advance by a competent professional working in the relevant field." The competent professional is not the claimant's own technical team. It is an objective reference point: a reasonably well-informed practitioner who keeps up with published knowledge in the discipline. If such a person, presented with the project brief, would know how to achieve the result or would know the result is achievable, the uncertainty is not genuine for R&D purposes.
HMRC's CIRD manual applies this test at CIRD81900 and emphasises that the question is objective, not subjective. The fact that the claimant's developers did not know the answer is not sufficient. The question is whether the answer was knowable from publicly available knowledge at the time the work was undertaken.
How the test is applied in an enquiry
When HMRC opens a compliance check, an officer will often ask the company to explain the uncertainty in detail and to confirm whether the solution was available in published literature or as an off-the-shelf product at the time the project began. The company must be able to show why the answer was not deducible: what knowledge existed, where it fell short, and what the team had to work out through investigation.
Where a company has submitted a vague technical narrative in its Additional Information Form, HMRC may conclude there is no evidence of a competent professional having assessed the uncertainty. A well-prepared claim states what was known, what was not known, and what attempts to find an off-the-shelf solution were made before concluding that original investigation was needed.
Example
A fintech company builds a fraud-detection model for a specific category of financial transaction. Before starting, the team checks published academic literature and available commercial APIs. No existing model meets the required accuracy threshold on their transaction type. A machine learning engineer working in the field would confirm that adapting existing models to this problem does not reliably produce the required outcome, and that novel training approaches were needed. That is a competent professional recognising genuine uncertainty.
Compare that with a company that builds a standard recommendation engine using a published architecture. A competent professional would know how to implement that architecture. The uncertainty there is commercial (will the recommendation improve conversion?) not technological.
Common mistakes
The most common mistake is writing a technical narrative from the perspective of the claimant's own team. Describing what the developers found hard is not the same as showing what a competent professional would find uncertain. A second mistake is conflating the competent professional with a generalist: the test is applied by reference to a specialist in the specific sub-field, not a generic software engineer or scientist. A specialist in a narrow domain may well recognise uncertainties that a generalist would not, which can work in the claimant's favour.
See also cosmetic vs substantive uncertainty for the practical distinction this test draws.