Quick answer: More measurements do not necessarily mean more independent evidence. If 500 readings all come from the same prototype, batch, device or production run, they may describe that experimental unit very precisely without showing that the result will recur independently. Where a technically uncertain outcome is being investigated, the experimental design should distinguish repeated measurements within an experimental unit from independent replication at the level relevant to the hypothesis.
20 October 2026 — This article describes the current R&D Tax Incentive (R&DTI) rules. The Australian Government has announced changes that will start from 1 July 2028. Until then, the program continues to operate under the current rules.
Research Completion and Engineering Readiness Are Different Decisions
An R&D project may successfully investigate its original technical question without producing a system that is ready for commercial operation.
Consider a company investigating whether a new scheduling algorithm can maintain acceptable performance when production conditions change unpredictably.
The research team develops a hypothesis, tests alternative approaches and identifies a configuration that performs better under the experimental conditions.
That may represent a meaningful research outcome.
However, the engineering team still needs to determine how the algorithm behaves within the existing software environment, what monitoring is required, how failures will be handled and whether the operational infrastructure can support it.
These are related questions, but they are not identical.
Research establishes what the evidence supports about a defined technical uncertainty.
Engineering readiness concerns whether that evidence is sufficient to support integration, reliability, maintainability and operation within the intended environment.
A technically successful experiment may establish that a mechanism works under specified conditions. It does not automatically establish that the mechanism will remain reliable when integrated with other systems, exposed to different inputs or operated at a larger scale.
The distinction also matters under the Australian R&D Tax Incentive.
Under section 355-25 of the Income Tax Assessment Act 1997, a core R&D activity must involve an outcome that cannot be known or determined in advance on the basis of current knowledge, information or experience, but can only be determined through a systematic progression of work based on principles of established science, proceeding from hypothesis to experiment, observation and evaluation and leading to logical conclusions. The activity must also be conducted for the purpose of generating new knowledge.
Routine implementation following the resolution of a technical uncertainty does not automatically qualify as core R&D simply because it forms part of the same commercial project. Conversely, integration or scale-up may expose a new technical uncertainty that requires further experimentation.
The important distinction is between what the research has established and what the engineering team still needs to establish before deployment.
What Should Be Included in a Research Handover?
A useful handover allows another technically competent team to understand not only what worked, but why the research team believes it worked and where that conclusion applies.
1. The original technical question and conclusion
The handover should identify the uncertainty that prompted the investigation, the hypothesis tested and the conclusion supported by the evidence.
It should distinguish between what was demonstrated, what remains an assumption and what could not be resolved.
A research project does not have to produce a successful outcome to reach a valid conclusion. A hypothesis may be rejected, the result may remain inconclusive, or the investigation may establish that a proposed approach works only within narrower limits than expected.
Engineering needs to understand which of these outcomes occurred before deciding how to proceed.
2. The experimental evidence and configuration
The handover should identify the important experiments, the configurations tested, the conditions under which the results were obtained and the basis for evaluating them.
Relevant technical information may include:
• software, firmware or model versions;
• hardware configurations and component specifications;
• input data characteristics and preparation methods;
• test conditions and measurement methods;
• reference configurations or comparison results;
• significant failures, anomalies and deviations; and
• the reasoning behind changes made during the investigation.
The aim is not necessarily to transfer every experimental file into a single document. It is to give the receiving team enough traceability to review the conclusions, locate the supporting evidence and understand the limitations of the work.
Where source data, code or specialised tools remain with another team or provider, the handover should also identify where they are held and what access is available.
3. The operating envelope and known limitations
Experimental findings apply to the conditions investigated. Engineering therefore needs to know which operating conditions were tested, which were excluded and where uncertainty remains.
A prototype evaluated using controlled test data may not have established performance under production data quality, unexpected user behaviour or infrastructure interruptions.
A material tested under a defined temperature range may not have been evaluated under repeated thermal cycling.
A process demonstrated at low throughput may not have been investigated at production scale.
The handover should distinguish between demonstrated performance and assumptions about future performance.
This is particularly important when engineering must decide whether additional validation is necessary before deployment.
4. Technical dependencies and implementation risks
Research outputs often depend on conditions that are easy to overlook once the preferred solution has been selected.
These may include particular libraries, software versions, equipment tolerances, material specifications, environmental conditions or supporting systems.
The handover should identify dependencies that could affect implementation, together with known failure modes and conditions that may invalidate the experimental conclusion.
For example, an algorithm may perform well only when a particular input-quality threshold is maintained. Engineering may need to implement data-quality checks or monitoring to preserve the conditions under which the result was demonstrated.
In this case, the research finding informs the engineering requirement. It does not remove the need to implement and verify that requirement.
5. Unresolved questions and the next verification work
The handover should make clear what remains unknown and what work is needed before the system can be accepted for its intended use.
Some items may require routine engineering verification, integration testing or operational preparation.
Others may expose a new technical uncertainty that cannot be resolved using established knowledge and methods.
The two should not be conflated.
A practical handover can identify each outstanding issue, the evidence currently available, the proposed next action and the person or team responsible for resolving it.
This gives engineering a starting point without implying that every outstanding task requires further R&D.
Design the Handover Before Research Ends
The most effective handovers are prepared throughout the research project rather than reconstructed after the research team has moved on.
Australian Government R&DTI record-keeping guidance states that records should be created at the time the activity is conducted. Records should show relevant background research and what was done, how the work was performed, when it occurred, who carried it out and the resources used. Examples of records that may demonstrate the systematic progression include experimental plans, records of trial runs and test reports showing results and evaluation.
These records support the assessment of R&DTI eligibility, but they also have an operational benefit: they make technical findings easier to transfer between research teams, engineering teams and external specialists.
The engineering handover should be a curated, implementation-focused summary built from that underlying evidence. It should not replace the original experimental records or rely solely on a retrospective account of what happened.
Before the research phase closes, the receiving team should be able to answer five practical questions:
• What has been demonstrated?
• Under which conditions does the evidence support the conclusion?
• What limitations or dependencies could affect implementation?
• Which uncertainties remain unresolved?
• What additional verification or engineering work is required before deployment?
If these questions cannot be answered, the handover may reveal a gap in the evidence, the documentation or the technical work itself.
That gap should be identified explicitly rather than hidden by a polished final report.
Keep Research Completion and Deployment Acceptance Separate
The end of a research investigation does not necessarily mean the end of technical uncertainty.
Engineering may discover a previously unexamined problem during integration or scale-up. The appropriate response depends on the nature of that problem.
If established engineering methods can resolve the issue, the work may be conventional implementation or verification.
If the issue involves an outcome that cannot be determined in advance using available knowledge and competent professional judgement, further systematic investigation may be appropriate. The team should define the new technical question and assess the subsequent activities against the applicable R&DTI requirements rather than automatically extending the original research description.
Research completion and deployment readiness should therefore be treated as separate decisions.
The research phase can reach a documented conclusion when the defined investigation has been evaluated, even if the hypothesis was not supported or further questions remain.
Deployment readiness, by contrast, depends on whether the system satisfies its intended engineering, operational, safety and commercial requirements.
Those decisions may occur at different times and involve different accountable people.
A strong handover makes the distinction visible. It allows the business to preserve the value of its experimental work without assuming that technical discovery and commercial readiness are the same achievement.
Conclusion
A research project should not hand engineering only a preferred solution. It should hand over the evidence that supports the solution, the conditions under which it was demonstrated, the limitations that remain and the work still required before implementation.
The objective is not to make engineering repeat the research unnecessarily. It is to give engineering enough information to reuse what has been learned, verify what still needs to be established and identify when a genuinely new technical uncertainty requires further investigation.
Research is complete when the investigation has reached a reasoned, documented conclusion. Engineering readiness is a separate judgement about whether the resulting knowledge is sufficient for the intended application.
Sources & Further Reading
Australian Government — Conducting core R&D activities for the R&D Tax Incentive
Australian Government — Record keeping for the R&D Tax Incentive
Australian Government — Software development sector guide for the R&D Tax Incentive
Federal Register of Legislation — Income Tax Assessment Act 1997, Division 355
Talk to Ignition Research if your team is transferring experimental findings into software, manufacturing or engineering implementation and needs to identify what the evidence establishes, what limitations remain and what technical questions still require investigation. As a Registered Research Service Provider, Ignition Research assists businesses with research question definition, experimental design, technical investigations and contemporaneous supporting records within its registered research fields.
RSP registration confirms that the provider has met the relevant registration requirements for its registered research fields. It does not constitute government endorsement of a project or guarantee R&DTI eligibility.
We do not determine R&DTI eligibility or provide tax advice. The R&D Tax Incentive is a self-assessment program, and companies remain responsible for assessing their activities, expenditure and circumstances and obtaining appropriate tax advice.
This article provides general information only and is not tax, legal or financial advice.
Working on a project like this?
Tell us what you're building and the part you're not sure will work. A researcher from our Adelaide team (registered Research Service Provider RSP000047) reads every enquiry and replies within two business days. No documents needed.
