BlogAI & Innovation How to document the technical uncertainty in your R&D project
If one concept decides whether your project qualifies under the R&D Law, it’s scientific or technological uncertainty. The law mentions it explicitly, and most rejections happen because the project fails to demonstrate it. See Why Corfo rejects projects.
The good news is that documenting it well is mostly a matter of method.
What technical uncertainty is
There is technical uncertainty when, at the start of the project, it isn’t known whether the result can be achieved or how, and the answer isn’t available from existing knowledge: publications, products on the market or the experience of a competent professional in the field.
It isn’t technical uncertainty when:
- You don’t know whether the product will sell (that’s commercial uncertainty).
- You don’t know how much it will cost to implement with known technology.
- Your company has never done it, if others already know how.
In the application: four elements
1. The state of the art. What exists today: solutions, technologies, publications. And why none of them solves your problem.
2. The uncertainty. Frame it as a question. For example: “Can we detect the failure at least 24 hours in advance using only data from existing sensors?”.
3. The hypotheses. What you think could work and why. For example: “A model combining these three variables could anticipate the failure”.
4. The method. How you’ll test the hypotheses: experiments, prototypes, lab tests, success metrics and criteria for dropping a path.
While the project runs: the log
What you promise in the application has to be backed up later. Corfo can audit the technical execution and, at close-out, asks for technical and financial documentation. An R&D log is the best evidence. For each experiment, record:
| Field | Example |
|---|---|
| Date and owners | 12 Mar, data team |
| Hypothesis | Model A beats model B on noisy data |
| What was done | Training on 3 datasets |
| Result | Model A doesn’t improve; noise dominates |
| Learning | Data must be filtered before modelling |
| Next step | Test three filtering methods |
Failures are evidence too. An experiment that didn’t work shows there was uncertainty. A project where everything worked first time may raise doubts that it ever was R&D.
Connect the technical work to costs
Every experiment uses hours, materials or services. If the log shows who worked on what and when, it’s much easier to support the declared staff time and expenses. See How to build your budget.
Tools
You don’t need a sophisticated system. These work well:
- A shared document or wiki with one template per experiment.
- Project-management tickets, as long as they record hypotheses and results, not just tasks.
- Code repositories with versioned experiment notes and results.
What matters is that the record is contemporaneous (written as things happen, not reconstructed at the end) and organized.
This article is for information only and is not tax advice. Sources: Law 20,241, Certification Regulation (Supreme Decree 102/2012) and Corfo’s FAQ.
Innovation is not the same as R&D (and for Corfo, the difference matters)
All R&D is innovation, but not all innovation is R&D. That distinction explains most R&D Law rejections. Here's a practical test to tell them apart.