Does your AI project contain R&D? An Australian evidence walkthrough

An AI project can include research, routine engineering, procurement and customer delivery in the same sprint. The useful question for Australia’s R&D Tax Incentive is what happened inside those activities. A model invoice, a large pull request or a novel product pitch cannot answer that alone.

Official AI guidance makes the starting point clear: using unfamiliar AI technology does not itself establish eligibility. A potential core activity needs a technical hurdle and a proposed solution whose outcome requires experimentation. The technology label does not change the test. Australian government AI-related activity guidance.

The following example is fictional. Its purpose is to show how an engineering record can support a review, not to pronounce the work eligible.

Start with the technical question

Imagine a team building an acoustic fault detector for industrial pumps. The detector works in the laboratory but becomes unreliable when a second machine starts nearby. The team needs acceptable detection performance on an edge device with a fixed memory limit.

“Make the detector production ready” is too broad to explain what the team needed to discover. A more useful investigation record says:

We will test whether the proposed adaptation method can distinguish the target fault from overlapping machine noise without exceeding the device’s memory limit. Existing baselines fail the agreed false-alarm threshold on the held-out noisy recordings.

That statement gives a reviewer a question to investigate. It still needs support. Record the baselines tried, the available knowledge consulted, the expert’s reasoning and why the outcome could not be determined in advance. Under the core-activity guidance, the relevant perspective is that of a competent professional with access to reasonably available knowledge; personal unfamiliarity is insufficient. Core R&D activity requirements.

A week of integration trouble may disappear after reading a vendor’s deployment guide. A difficult and expensive problem can still have an established solution. The review should preserve that discovery rather than reframe it as an experiment after the fact.

Make the proposed experiment inspectable

For our fictional detector, the team creates a short experiment note before running comparisons. It records the proposed method, two baselines, a held-out recording set, the false-alarm definition, the memory ceiling and the measurement script version. It explains how the evaluation set differs from the training set.

The note also states what would change the team’s mind. If the method reduces false alarms only by missing most faults, the proposed solution has not met the objective. If it succeeds only after the memory limit is relaxed, the result answers a different question.

During the work, preserve the experiment configuration and observed output together. An evaluation screenshot without its dataset and configuration cannot explain which version produced it. A code diff without the test result cannot show what was learned. The goal is a connected chain that another engineer can follow.

The software sector guide recognizes several ordinary engineering records as potentially useful evidence, including investigation tasks, design notes, test outputs and technical communications. It also warns that ordinary integration, configuration and interface work generally involves known approaches. Software development sector guide.

Separate work by its actual role

The example project contains four different work streams. Classify them provisionally before asking a specialist to assess them:

Under current supporting-activity rules, a direct relationship to a core activity is required. Additional dominant-purpose requirements apply to specified activities, including activities producing or directly related to producing goods or services and activities excluded from being core. Record the relationship rather than assuming everything in the project qualifies. Supporting R&D activity guidance.

Also check exclusions. Australian rules exclude software developed predominantly for the internal administration of the developer or specified related entities from core R&D activities. Supporting-activity treatment may still be possible under the applicable tests. A reviewer must assess the actual use and relationship to core work; “AI” does not override those rules. Excluded R&D activities.

Connect compute costs without treating the invoice as the experiment

Suppose the team’s cloud invoice is A$12,000 for the month. The invoice establishes a billed amount, but the account also serves production inference, internal demos and unrelated development.

Our proposed evidence worksheet preserves the invoice total and groups usage by known experiment references. Assume A$4,800 can be linked to the detector’s recorded runs, A$3,600 to production, A$1,800 to other projects and A$1,800 remains unresolved. The groups reconcile to A$12,000. The A$4,800 is an amount to review, not an eligible expenditure conclusion.

Investigate the unresolved amount separately. It may need better usage exports, credit treatment or a different allocation method. Do not distribute it evenly across the known experiments merely to make the worksheet appear complete.

Likewise, a source-control author name does not settle payroll participation or time allocation. Ask the technical lead to explain roles and the finance owner to provide the relevant cost support. The department’s record guidance links the activity record to the resources and expenditure used, including support for apportionment. R&DTI record keeping.

Give AI bounded jobs in the review

A useful AI task is to suggest records that appear to refer to experiment PUMP-17 and explain why. Another is to compare the experiment note with the conclusion and list missing measurements. In each case, a reviewer can inspect the cited records and accept, correct or reject the suggestion.

A poor task is to invent the hypothesis the team “must have had” from its final code. NIST identifies confidently false generated content as a generative-AI risk. An evidence workflow should therefore preserve the distinction between a source fact, a model suggestion and a human judgment. NIST Generative AI Profile.

Proforma starts with collecting supplied records and producing an initial view of coverage, supported notes, costs and gaps, with manual preparation supported. Bring the experiment the team actually ran, including the failed approaches. That is a stronger foundation for review and future engineering decisions than a polished narrative written from the successful release alone.