Identifying technical uncertainty in R&D

After this module you will be able to state the technical uncertainty in a project in two sentences, separate it from commercial risk, project risk and hard but known work, and find it in your own backlog, lab notebook or test programme.

What this module covers

What uncertainty means for tax purposes, and the competent professional standard behind every definition.
The difficulties confused with it: commercial risk, project risk and hard but known work.
A five step method for finding uncertainty in your own work.
Where the uncertainty starts and ends, and why that sets the boundary of the claim.

What uncertainty means for tax purposes

The seven schemes phrase their definitions differently; the table at the end gives each in its own words. Underneath they ask the same two questions. Was the outcome, or the way to achieve it, unknown at the start? And could a competent professional in the field have known it, or worked it out, from the knowledge available at the time? Yes to the first and no to the second means there was scientific or technological uncertainty.

It is judged at the start, not in hindsight. A result that looks obvious once found was still uncertain if nobody could have predicted it, and a predictable result does not become uncertain because the work was difficult.
It is measured against the field, not against you. Something new to your company is not uncertain if it is documented elsewhere or a competent peer could have deduced it. The question is whether the knowledge was available, not whether you had it.
Failure counts. An approach that fails still resolves the uncertainty: you now know it does not work under those conditions. The records of the failure are often the best evidence that the uncertainty was real.

The uncertainty must sit in a field of science or technology. Not knowing how a market, a regulator or a customer will respond is a real business problem, but not a scientific or technological one.

What it is not

The table separates the cases engineers most often confuse.

What you faced	Kind of difficulty	Counts?	Why
"We did not know whether customers would adopt the feature"	Commercial risk	No	Market knowledge, not science or technology
"We did not know whether we could ship by the launch date"	Project risk	No	Schedule and resourcing, not a technical unknown
"The integration took three months because the vendor's API was badly documented"	Hard but known work	No	A competent professional could have done it given time; nothing new was found out
"We did not know whether the model could reach 95% recall under 50 milliseconds on our data; no published approach had"	Technical uncertainty (whether)	Yes	Feasibility unknown and not deducible
"We knew it was possible in principle but not how to make it work at production scale under our constraints"	Technical uncertainty (how)	Yes	The method was unknown in practice, even though the goal was known to be achievable
"We did not know how the sensor would behave in that environment, so we tested it"	Depends	Sometimes	Yes if the behaviour could not be predicted from the data sheets and known physics; no if the test was routine validation

The last row needs most care. Testing is part of the work to resolve an uncertainty when the behaviour could not be predicted and the test is designed to find out. It is routine when it checks that something behaves as the specification or data sheet already says it will.

The authorities that have published software guidance say the same thing: building a new product by applying known techniques, frameworks and documented interfaces does not resolve a technological uncertainty, however commercially new the product. The uncertainty has to be in computer science or software engineering, not in the company's product set.

Finding it in your own work

Do not start from the project list. Start from the moments of doubt.

List the moments you did not know whether, or how. Where in the last year did your team genuinely not know whether something could be done, or how, and have to find out? Bring three. Do not read the legal definition first; it makes people self-censor.
Write each one in two sentences. "We did not know whether [approach or system] could achieve [measurable result] under [constraints]. The known approaches [A and B] could not, because [reason]." If you cannot fill the brackets, you have not yet found the uncertainty.
Apply the competent professional test honestly. Could a peer in your field, with the normal literature and tools, have looked this up or worked it out without experimenting? If yes, it is good engineering and it is out. Expect to lose a third of the list here.
Look for the signatures. Several approaches tried. Prototypes or branches abandoned. A test rig or benchmark built to find out. A hypothesis stated before the test.
Check the field. Is the unknown in science or technology, or in the business? If the sentence contains "customers", "market", "price" or "deadline", rewrite it or drop it.

Record the answers, dated, in a half-page project note.

Where it starts and ends

The uncertainty sets the boundary of the claim in time as well as scope. The work to resolve it starts when you recognise the unknown and begin to address it: the literature search, the design of the experiment and the first prototype are inside. It ends when the uncertainty is resolved or you stop working on it. Everything after that, including productisation, interface work, documentation and routine bug fixing, is outside. Record both dates for every window; the boundary decides the size of the claim more than any other judgement, and it is yours to make.

Illustrative example

Illustrative example. Kestrel Analytics Ltd, a hypothetical company, sets out to build a payment fraud scoring service over 12 months at a cost of 600,000. Asked what was not known at the start, the technical lead lists three things: whether a model could reach 95% recall at a 2% false positive rate with a scoring latency under 50 milliseconds on the company's transaction data, when the published approaches reached that accuracy only in batch; whether merchants would pay; and whether a team of five could ship within the year. Only the first is technical uncertainty; the second is commercial risk and the third is project risk. Work on the first ran four months: three model families and two feature pipelines were tried, two abandoned with the reasons recorded, and the work ended when the test harness met all three targets on held-out data. The four engineers involved cost 200,000 over those months. The remaining 400,000, spent on the merchant dashboard, onboarding, billing and cloud scaling, is not claimed. The benefit at that country's rate applies to 200,000.

Across the seven countries

Each scheme's definition in its own words, with the eligibility page that explains how it is applied.

Country	The definition in that scheme's words	Eligibility page
United States	At the outset, you must have been uncertain about capability, method or appropriate design. Uncertainty is judged before the work starts, not after it succeeds.	Eligibility: United States
United Kingdom	Scientific or technological uncertainty exists when knowledge of whether something is scientifically possible or technologically feasible, or how to achieve it in practice, is not readily available or readily deducible by a competent professional working in the field.	Eligibility: United Kingdom
Ireland	Qualifying activities must involve the resolution of scientific or technological uncertainty; uncertainty exists only where a competent professional in the field could not readily resolve the matter from existing knowledge.	Eligibility: Ireland
Canada	A scientific or technological uncertainty that could not be resolved by standard practice, addressed through a systematic investigation or search by means of experiment or analysis, involving a hypothesis, testing and conclusions.	Eligibility: Canada
Australia	Core R&D activities are experimental activities whose outcome cannot be known in advance from current knowledge.	Eligibility: Australia
New Zealand	Scientific or technological uncertainty exists if knowledge of whether something is scientifically possible or technologically feasible, or how to achieve it in practice, is not publicly available or deducible by a competent professional in the relevant field.	Eligibility: New Zealand
Singapore	R&D involves novelty or technical risk. Technical risk exists where the probability of achieving the technical objective cannot be known or determined in advance by a competent professional based on current knowledge, and novelty is something that is new in the field rather than new to the business.	Eligibility: Singapore

Module 2: Identifying uncertainty