Business Finland

How to write the R&D uncertainty section of a Business Finland application

A tactical guide to writing the section applicants struggle with most: how to state R&D uncertainty in a Business Finland application so an evaluator believes it.

This is the section that carries the application. If an evaluator believes the uncertainty is real, most other things are forgivable. If they don’t, nothing else saves it. Yet it is the section teams write worst — usually because they either assert uncertainty without showing it, or describe how hard the work is instead of why the outcome is genuinely in doubt.

Assuming you have already confirmed your project is R&D, here is how to write the section so it lands.

What the evaluator is looking for

The reader is trying to answer one question: is there a real technical question here whose answer nobody currently knows? They want to see the question named precisely, evidence that existing approaches don’t already answer it, and a credible reason to believe the work could genuinely fail. “Difficult” is not the target. “Not knowable in advance” is.

The structure that works

Write the section in four moves:

1. State the specific technical goal. Not the business goal — the technical one. “Achieve reliable extraction of structured data from inconsistent, low-quality domain documents at a level usable in production.” Concrete, measurable, bounded.

2. Name the uncertainty precisely. The single sentence the whole section exists to deliver: what specifically is not known, and why. “It is not known whether acceptable accuracy is achievable on this data without large labelled datasets, which do not exist for this domain, and standard approaches degrade below usable thresholds in our preliminary tests.”

3. Show why existing solutions don’t already solve it. This is the step teams skip, and it is what separates believable uncertainty from asserted uncertainty. Explain what the off-the-shelf or state-of-the-art options are and precisely where they fall short for your constraints. If you can’t articulate why the obvious solution fails, the evaluator assumes it works.

4. Describe how you’ll resolve the uncertainty. The research and development approach — the experiments, methods, and milestones through which the unknown becomes known. This turns “we don’t know” into “here is how we’ll find out,” which is what makes it a fundable plan rather than a shrug.

Language that helps and language that hurts

Hurts:

“This is a highly innovative and cutting-edge project.” (Assertion, no content.)
“AI is a complex and rapidly evolving field.” (True and irrelevant.)
“We will leverage advanced machine learning to…” (Describes activity, not uncertainty.)

Helps:

Specific technical thresholds (“below 80% accuracy in preliminary tests, where the use case requires…”).
Named constraints (“without labelled data at scale,” “within the latency budget of…”).
Honest failure conditions (“if the method cannot generalise beyond curated samples, the approach does not hold”).

Naming how the project could fail is not a weakness. It is the strongest possible evidence that the uncertainty is real. Applications that admit a genuine failure mode read as more fundable, not less.

The test before you submit

Read your uncertainty section and ask: could a skeptical engineer read this and say “no, that’s actually a solved problem”? If yes, you haven’t shown why existing solutions fall short — fix step 3. Then ask: does this describe a question that could genuinely be answered “no” at the end of the project? If not, you’ve described implementation, and the section can’t be rescued by wording — the project needs rethinking.

A compact template

Our technical goal is to [specific, measurable capability]. The core uncertainty is whether [precise unknown] is achievable given [specific constraint], because [why standard approaches fall short here — with evidence]. We will resolve this uncertainty through [experiments / methods / milestones]. If [failure condition], the approach does not hold, which is the genuine risk the project addresses.

Fill that in with real specifics and you have a section that does its job: it makes an evaluator believe there is a real question worth public funding to answer.