The difference between R&D and engineering is usually explained with an org chart: researchers discover, engineers build. That picture is not wrong, but it fails the first time someone outside the team has to classify the work. A funding body, a tax authority or a contract partner does not care which department a person sits in. It asks one question about each task: was the answer already knowable?
This article gives the line as the three rulebooks that put money on it draw it, and then walks one applied AI control programme across that line.
The short answer
Practitioners have described the split for decades. Jack Ganssle put it bluntly: research cannot be scheduled, while development is taking known ideas and using them to build products. A more recent formulation is sharper still: an engineering team exists to reduce execution uncertainty, an R&D team exists to reduce knowledge uncertainty.
The operational version, the one that survives an audit, comes from the UK guidelines. Scientific or technological uncertainty exists when whether something is possible, or how to achieve it in practice, is not readily available or deducible by a competent professional working in the field. If a competent engineer in your field could sit down and work it out, it is engineering. If they could not, and the task exists to find out, it is R&D.
Everything else in this article is a refinement of that sentence.
Why the everyday definitions break when money depends on them
Two assumptions cause most misclassification.
The first is that a project is either R&D or it is not. HMRC is explicit that a company developing a new product will often consider the whole project to be R&D, and that this is not necessarily correct: only the elements that seek an advance qualify, and eligibility is determined by the nature of the work, not by the individual's job title. A research engineer writing a deployment script is doing engineering. A production engineer who hits a failure mode nobody in the field can explain may be doing research.
The second assumption is that the label is harmless. One long essay on AI organisations names the failure precisely: engineering work gets labelled research to attract talent or justify budget, nothing new gets built, but everything sounds impressive. Inside a company that costs morale. In a funding claim it costs the claim.
Where three rulebooks draw the line
UK: an advance a competent professional could not readily reach
The UK guidelines define the boundary in a handful of paragraphs, and each one closes a specific loophole:
- The advance is measured against the field, not the company. It must be an advance in overall knowledge or capability, not the company's own state of knowledge alone. Doing something new to you is not enough.
- Using science is not advancing it. A product does not become an advance simply because science or technology is used in its creation.
- Copying is out. The routine analysis, copying or adaptation of an existing product, process or material is not an advance.
- Tuning is out. Improvements, optimisations and fine-tuning which do not materially affect the underlying technology do not count.
- Integration can be in. System uncertainty, where components behave predictably but nobody knows how to combine them for the overall effect, is genuine uncertainty. Assembling components to an established pattern is not.
- R&D has a start and an end. It begins when work to resolve the uncertainty starts and ends when the uncertainty is resolved or the work stops.
That last rule is the one engineers underestimate. The same person, on the same project, crosses from R&D into engineering on the day the question is answered.
OECD Frascati: prototypes, pilot plants and trial production
The Frascati Manual, the OECD's reference definition of R&D, has handled this boundary since its early editions, and the 1976 text still reads as a checklist for engineering organisations. Its criterion is the presence of an appreciable element of novelty, and it applies that criterion to exactly the artefacts engineers produce:
- Prototypes are R&D. But once any necessary modifications have been made and testing is satisfactorily complete, the boundary of R&D has been reached. Building copies afterwards is not R&D, even if R&D staff build them.
- Pilot plants are R&D as long as the principal purpose is to obtain experience and compile engineering data. The moment one switches to normal commercial production, it is no longer R&D, whatever it is still called.
- Trial production and tooling up are excluded, because the objective is no longer to improve the product but to get the production process going.
- Design and drawing are divided: design required during R&D is in, design for the production process is out.
- Troubleshooting is excluded, except for "feedback" R&D when a production problem genuinely needs new work.
- Routine tests are excluded even when R&D staff run them.
Read those rules again and a pattern appears. Frascati does not classify people or even activities. It classifies the purpose of an activity at a point in time.
Germany: the R&D phase ends with the test of a prototype
The German research allowance puts the same line into administrative practice. The BSFZ, the body that certifies projects before any tax claim, quotes the EU block exemption rule directly in its review guideline: experimental development does not include routine or periodic changes to existing products, production lines, processes or services, even if those changes represent improvements. The guideline then states the boundary in one line: the certifiable R&D phase of a product development ends with the test of a prototype.
What it excludes after that point is a list any engineering manager will recognise: manufacturing a pre-series batch, production preparation, commissioning of machines, work to reach market readiness, and test campaigns run only to generate data for certification or approval. Feasibility studies are listed as not certifiable too. The guideline also sets a useful test for novelty: at least one of the starting point, the path, or the goal must differ enough from earlier work that further development under uncertainty is needed.
For software, the German practice is concrete. Configuration of existing software or hardware, porting, template-based solutions and routine development such as requirements analysis, testing and debugging are not R&D.
Three jurisdictions, three vocabularies, one line: R&D ends when the uncertainty is resolved, and in hardware that usually means when the prototype passes its test.
One programme, both kinds of work
Abstract rules are easy to agree with. Here is how they cut through a real applied AI control stack, using the figures published for Equation Labs' own control work: a growth model with R-squared above 0.95, a safety layer running in under 2 ms, end-to-end edge latency reduced from 1.2 s to 285 ms, validated on a 500 L pilot basin with zero safety violations across 400 simulated years.
Walk each piece through the tests as questions, not conclusions.
The model. Whether a continuous-time neural model can represent a living process accurately enough to control it is not something a competent practitioner can look up. That is the shape of a research question. Retraining the same model on next quarter's data, once the architecture is proven, is tuning.
The safety layer. Proving that a controller acting on a live biological process never leaves its safe set, within a latency budget measured in milliseconds, is a system uncertainty in the UK sense. Wrapping an already-validated safety filter around a second, similar controller may not be.
The edge deployment. Here the line runs through the middle of the task. Moving a model to edge hardware is, on its face, porting, and porting is explicitly not R&D in German practice. But if nobody knows whether the model can meet the control loop's timing at all, and the work is to find out, the question changes. Getting from 1.2 s to 285 ms is either routine optimisation or the resolution of a genuine uncertainty, and only the contemporaneous record of what was known at the start can say which. The same question sits under every sim-to-real transfer and every stage of an edge AI deployment pipeline.
The pilot basin. A 500 L pilot operated to gather data that validates the controller is the Frascati pilot plant case. The same basin run as a production unit afterwards is not.
The 400 simulated years. A validation campaign that decides whether the controller is safe is part of resolving the uncertainty. The same simulations rerun only to produce paperwork for a certification body sit on the BSFZ exclusion list.
None of this makes the engineering less valuable. It makes it a different category of work, with a different funding treatment and a different definition of done.
Signals table: engineering or R&D
| Signal | Points to engineering | Points to R&D |
|---|---|---|
| Can a competent professional in the field say how to do it? | Yes, with effort | No, not from available knowledge |
| Is the outcome schedulable? | Yes, with normal estimation error | No, it may fail |
| Is the novelty relative to the company or to the field? | The company | The field |
| What happens after the prototype passes its test? | Everything from here | Stops here, unless new uncertainty appears |
| Is the work integrating known parts in a known pattern? | Yes | No, the combination itself is uncertain |
| Is the test routine QC or conformance? | Yes | No, it tests a hypothesis |
| Is the software task configuration, porting or debugging? | Yes | Only if a technical hurdle is being overcome |
| Does the job title say "research"? | Irrelevant | Irrelevant |
Draw the line in the documents before the work starts
Every rulebook above makes the same practical demand: show what was uncertain at the start, and when it stopped being uncertain. The BSFZ requires the project to be planned and documented, and the UK start and end rule means a claim without dated evidence of the open question is a claim about memory.
The cheapest way to meet that is structural, not clerical. Split the plan so that each uncertainty is its own work package with a stated hypothesis, and the engineering that follows is a separate package. That is how our contract programmes are run: OptiVX was accounted across 29 work phases, and IntelliBot closed with more than 400 pages of transfer documentation. A record at that granularity lets anyone, a client, an auditor or a certifier, see where the research ended and the engineering began. Equation Labs research work is eligible under the German FZulG, and that eligibility rests on exactly this separation.
If the work is being commissioned from outside, the classification also decides who can claim. Start with what contract research and development actually is, then the 70 percent rule for contract R&D in Germany, and the mechanics of claiming the allowance on work you contract out.
FAQ
Is software development R&D or engineering?
It can be either. Software work that overcomes a genuine technical hurdle can qualify as experimental development. Configuring existing systems, porting code to a new platform and routine requirements analysis, testing and debugging are engineering, however difficult they feel in the moment.
Does a failed project still count as R&D?
Yes. The UK guidelines state that R&D still takes place even if the advance sought is not achieved or only partly realised. What counts is that the work set out to resolve an uncertainty, which is why the record of the attempt matters more than the result.
Is testing R&D?
Only when the test resolves a defined technical uncertainty, such as experimental evaluation of a prototype. Routine quality control, acceptance or conformance testing of production output is not R&D, even if the same lab and the same people run it.
Is a feasibility study R&D?
It depends on the jurisdiction. The BSFZ lists feasibility studies as not certifiable under the German research allowance. The UK guidelines, by contrast, treat assessing scientific or technological feasibility as a planning activity that directly contributes to R&D. Check the regime before scoping the study.