What is technical uncertainty

Every R&D incentive in the seven countries this library covers turns on the same idea: there was something a capable specialist in the field could not know or work out in advance, and the company set out to find out. The schemes name it differently (scientific or technological uncertainty, technical risk, an outcome that cannot be known in advance) and test it with slightly different yardsticks, but the idea is the same, and so is the mistake most claims make: confusing a hard, risky or expensive project with a technically uncertain one.

What this guide covers

• What the schemes mean by scientific or technological uncertainty, and what they do not.
• The competent professional test and how reviewers apply it.
• How technical uncertainty differs from commercial, project and financial risk.
• How to find the uncertainty in your own projects and write it down.
• Where the uncertain work begins and ends, and why the boundary matters.

What the schemes mean by uncertainty

For tax purposes, uncertainty is not a feeling. It is a gap in knowledge: either nobody in the field knows whether a result is scientifically possible or technologically feasible, or nobody knows how to achieve it in practice. Both kinds count. The first is uncertainty of capability: can this be done at all? The second is uncertainty of method or design: we know it can be done, but not how. A team experimenting to find a design that works is resolving technical uncertainty as much as one unsure whether the result is achievable.

It is judged at the outset

Uncertainty is assessed by what was known when the work started, not by how hard the work turned out to be or whether it succeeded. A project that failed can be R&D. A project that succeeded easily, because the answer was already available, is not. This is why records made at the time matter: a dated note stating what was unknown in the first month is worth more than any explanation written afterwards.

It is measured against the field, not the company

The question is not whether your team knew the answer but whether the answer was available in the field: in published literature, in standard practice, in the knowledge a competent specialist would bring. Learning something that is new to you but well established elsewhere is training, not R&D.

The competent professional test

Most of the schemes name the yardstick directly: a competent professional in the field, a specialist with the relevant knowledge and experience, asked at the start of the project whether this can be done and how. If the answer is yes, or could be looked up or deduced from what is already known, there is no uncertainty. If the honest answer is "not without trying it", there is.

Applying the test well means doing three things.

• Name the professional. Identify the discipline (process metallurgy, distributed systems, formulation chemistry) and the level of experience that counts as competent. A claim that cannot say whose knowledge was tested cannot show that the test was applied.
• State what that professional already knew. Record the baseline: the methods, published results, supplier data and prior projects consulted. Uncertainty is defined against this baseline, so it has to be visible.
• State what they could not deduce. Write the gap as a question a specialist would recognise: "whether this alloy can be cast at a 2 mm wall without porosity at production cycle times", not "how to make a better casting".

Two things usually go wrong. The professional is set too low, so anything the team did not personally know becomes uncertain, or too high, so only work worthy of a journal counts. Neither is the test.

Technical uncertainty versus other kinds of risk

Almost every development project is risky; only one kind of risk is technical uncertainty.

The other risks produce language that sounds like uncertainty. "We did not know if it would work" can mean the market might reject it, the budget might run out, or the physics might not allow it. Only the last is relevant. Ask which kind of risk each statement refers to, and keep only the technical ones in the claim.

Finding uncertainty in your own work

Technical uncertainty appears where a plan broke: the sprint that was re-planned three times, the batch that was scrapped, the supplier who said it could not be done. A practical method:

1. List the problems that took longer than expected, with the people who worked on them. Delay is not proof of uncertainty, but it is where to look.
2. For each, ask the technical lead what they did not know at the start, in one sentence. If they cannot say, the problem was probably hard rather than uncertain.
3. Ask what they did to find out: what was tried, what failed, what was measured. If the answer is "we looked it up" or "we called the supplier", the uncertainty was not technical.
4. Ask whether a competent specialist elsewhere in the field could have told them the answer. Record the answer either way.
5. Write the result as a dated project note, half a page, before anyone calculates a cost.

The project identification workshop guide gives a format for doing this with a whole technical team.

Where the uncertain work begins and ends

The uncertainty defines the boundary of the claim in two directions. In time, the work done to resolve the uncertainty begins when the team starts trying to resolve it and ends when it is resolved or abandoned. Work before that point (deciding to do the project, gathering requirements, commercial feasibility) is outside. Work after it (building out the product on the resolved design, commercial production, routine release) is outside too, even when it costs far more.

In scope, only the activities that contribute to resolving the uncertainty are inside. A large project may contain a small uncertain core, and claiming the whole project because part of it was uncertain is the most common reason claims are reduced on review. Name the component or process that was uncertain, the dates between which it was being resolved, and the people who worked on it. Everything else is routine work; the guide to qualifying versus non-qualifying activities sets out where that line sits.

Illustrative example

Illustrative example. Corran Castings Ltd, a hypothetical company, spends 300,000 over a year developing a thin-walled aluminium housing for a customer. The commercial risk (the customer may not place the volume order) and the project risk (a tight deadline) are real, but neither is technical uncertainty. The technical question is whether the chosen alloy can fill a 2 mm wall section without porosity at production cycle times. The foundry's metallurgist, the supplier's data sheets and the published literature do not settle it, and the supplier says it has not been done at that wall thickness. That is the uncertainty, and the competent professional test is met. Resolving it takes four months of trials on gating design, mould temperature and alloy modification, costing 120,000 in engineer time and scrapped castings. The remaining 180,000 (tooling the production mould, commissioning, first production runs, customer approval) is routine work on the resolved design. The claim is built on the 120,000, and the benefit is calculated at that country's rate. A record that states the question in month one, the trials in months two to five, and the resolved design in month five draws the boundary for any reviewer.

Country differences

Each scheme states the test in its own words; the country pages explain how it is applied.

Related pages

• Qualifying versus non-qualifying activities: where the line really sits
• The four-part test for qualified research (United States)
• How to run a project identification workshop with your technical team
• Technical Teams Program, Module 2: Identifying uncertainty
• Eligibility hub

Educational material, not advice. Eligibility and treatment depend on the scheme and the facts.