A description of a software product often explains what users can do with it, the technologies it uses and why it is commercially useful. An R&D activity description needs to answer different questions. What technical outcome was uncertain, what was tested, and what did the team learn? Using artificial intelligence, integrating an API or building a new application does not answer those questions on its own.
Define the technical question
Departmental software and AI guidance applies the statutory activity criteria to the work actually performed. It distinguishes experimental activity from descriptions of a product or technology choice and identifies records that can help demonstrate the progression of the work. [R5] [R6] Begin with the technical hurdle, the relevant existing knowledge and the reason an experiment was necessary.
Avoid vague objectives such as make the model more accurate or improve performance. Explain what accuracy or performance means in the particular context and what proposition is being tested. A specific question gives the team a basis for choosing measurements and interpreting results. It also makes it easier to distinguish the experiment from ordinary implementation work surrounding it.
Show how the comparison works
Consider a hypothetical system classifying defects from photographs taken under varying lighting. The team could explain the proposed method, the reference approach, the data used and the measures chosen to compare outcomes. It should also explain why the result was not determinable in advance. This illustrates how to describe work; it does not establish eligibility for that hypothetical project.
Record changes that may affect interpretation. If data, model settings and evaluation criteria all change between runs, the team needs to explain what can reasonably be concluded from the comparison. Preserve the reasoning behind experimental choices, including limitations. A result that falls short of a target may still be informative, but the claim should describe what the observations actually support.
Use the team's existing records
Issue trackers, design notes, test outputs and technical discussions may contain useful evidence. Identify the records supporting each important statement instead of copying an entire repository into the claim file. Departmental guidance emphasises the content of records rather than a prescribed format. [R5] Preserve version information where it helps explain which implementation and test conditions produced a result.
Write the evaluation as well as the experiment. What did the results show? Which explanation was supported or challenged? What changed in the next test? A list of completed tickets may demonstrate effort without showing the logical conclusions reached. Ask a technical colleague unfamiliar with the project to follow the explanation and identify any missing steps.
Separate the wider development work
Assess deployment, interface work, customer requirements and other surrounding tasks on their own facts. Consider supporting activity requirements and relevant exclusions rather than treating the whole development budget as a single experiment. Keep the expenditure calculation aligned with the activity boundaries your technical analysis identifies.
Ardian Law assists with the legal and technical assessment of software and AI R&D claims. Call 02 8111 7700 if you need help describing the experimental work, assessing the supporting evidence or responding to questions about an existing claim.