Ask a founder what their R&D was and they will describe the product: an end-to-end platform that does forecasting, scheduling, quoting and compliance in one place; a marketplace with a rating engine nobody else has. All of it may be true, and all of it may be new to the market. Neither fact answers the question an R&D incentive regulator is asking.
The question is narrower. Was there a point in the work where a competent professional in the field, with everything that was publicly known at the time, could not have said in advance whether it would succeed or how to make it succeed? That point is the unknown outcome. It is what makes an activity R&D rather than development, and it is the thing most software submissions describe least well.
Where the unknown actually sits
In software it is rarely the product and almost never the feature list. Building a platform with established frameworks on a cloud provider is a known quantity; that is precisely why those frameworks exist. The unknown sits in a specific technical proposition inside the build, and it tends to live in one of a few places:
- A performance envelopeA latency or error-rate target that has to hold under load the benchmarks don't cover.
- Model behaviour on real dataWhether the accuracy the business needs holds on data the model has never seen.
- An interaction between known partsComponents that are predictable alone, and unknown when they compete for the same time budget.
- Whether the target can be met at allA research question, as distinct from the project plan to build the thing.
The discipline is to find that point and state it on its own, separated from the product around it.
"Whether a real-time, user-weighted ranking can be recomputed across the full data set within a hundred milliseconds while the same data is being written to by other users" is a technical proposition. "Develop a platform with a new rating algorithm" is a product description.
Stating it so it can be recognised
Once the unknown is isolated, three things make it recognisable to someone assessing it on paper.
Say what was known. An unknown outcome is defined against the state of knowledge at the time, worldwide. The strongest submissions show the work: what literature and vendor documentation was investigated, what it established, and exactly where it stopped short of the proposition in hand. Published systems that achieve similar results by a different method are especially useful, because the difference in method is the gap.
Give your advisor the technical proposition. "The platform will sustain the target performance" is a project objective. The technical proposition underneath it reads "this specific approach will achieve this specific result, for these reasons", with the reasons drawn from the state of knowledge. Your R&D advisor builds the hypothesis and the activity description on that proposition; the expert's job is to make sure the proposition is real, specific and defensible.
Say who holds the view, and why they are qualified to. The test is framed around a competent professional in the field. If the submission is silent on who that is, the regulator will ask. When the answer is someone whose expertise is in the relevant field and who can attest to the state of knowledge, the whole submission reads differently.
Why this is worth doing early
The best time to isolate the unknown outcome is while your advisor is writing the registration, when the novel problem, the state of knowledge and the new knowledge sought can be stated together. If a regulator later asks for more technical detail and clarity, the same work gives your advisor the expert answer.
Novelty gets a product to market. The unknown outcome, stated precisely and evidenced, is what gets the work recognised as R&D.