Recording R&D work as you go

After this module you will be able to use the tickets, commits, lab notebooks and test logs your team already creates as the record of the work done to resolve an uncertainty, and add the small amount of structure that links each record to a project, an uncertainty and a person.

What this module covers

Why records made at the time outweigh anything written at claim time.
The records you already produce, and the question each answers for a reviewer.
The three links that turn a record into evidence: project, uncertainty, person.
A routine that takes minutes a week, and what to do when it lapses.

Why records made at the time carry the weight

Every scheme expects records that support the claim, and several authorities say in their guidance that they expect records generated as the work was carried out and that reviewers consider whether a record was made at the time. The reason is simple. A statement of the unknown written in March, before anyone knew the answer, proves the uncertainty existed. The same statement written in December proves only that someone can describe a problem in hindsight. Reviewers typically read the narrative, then the earliest dated document; if it is dated after the claim period, they assume reconstruction and test everything else harder.

This is good news for technical teams. The records that carry most weight are the ones you make for your own purposes: the ticket that says what you are trying, the commit that shows who did it, the test log that records the failure, the notebook entry with the hypothesis. They are dated by the systems that hold them and attributed to the people who made them. What they usually lack is a link to the project name finance uses, to the uncertainty they address, or to a time record.

The records you already make

The table maps each record type to the question it answers and the one addition that makes it usable.

Record you already make	Question it answers for the reviewer	What to add so it links
Issue tracker ticket	What was tried, in what order, and why the approach changed	The project key and an "uncertainty" label; one sentence stating what was unknown when the ticket was opened
Commit and pull request	Who did the work and when; which alternatives were abandoned	The ticket id in the commit message; keep abandoned branches, or a note of what each tried and why it was dropped
Design document or RFC	What was unknown at the start and which options were considered	A date, an author, and a section headed "What we do not know"
Lab notebook or electronic notebook	Hypothesis, method, observation and result, in sequence	The project reference on each entry; signed and dated pages; the sample or batch id
Test log, benchmark run, CI result	Whether the approach met the target, and how often it failed first	Keep the failed runs, not only the passing one; record the target each run was testing against
Trial run sheet, batch record, engineering change request	Parameters tried, results, and who ran the trial	The engineer's name, the date, and the problem being solved stated on the sheet
Timesheet or sprint allocation	Who spent how long on which project	The same project key finance uses; captured monthly at the latest
Milestone or release note	Where the uncertainty was resolved and the R&D ended	A dated sentence saying the target was met, or that work on the unknown stopped

Two habits do the most damage. Squashing commits and deleting branches erases the alternatives tried, which are the evidence of systematic work. Keeping only the passing test run erases the failures, which are the evidence of uncertainty.

The three links: project, uncertainty, person

Project

Agree one project key with finance and use it everywhere: tracker, commit messages, notebook pages, trial run sheets and the cost allocation. A key like RD-07 is enough; the point is that a reviewer can filter your records and the cost schedule by the same term and get the same project. Where the country has a registration or approval step, the key should map one to one to a registered or approved activity.

Uncertainty

Each project has a half-page note, written and dated when the work starts, stating what is unknown and why available knowledge does not answer it. Tickets under the project inherit that statement; it turns a pile of tickets into the work done to resolve a named uncertainty. When the unknown is resolved or abandoned, add a dated line to the note saying so. That line is the record of where the claim ends.

Person

Reviewers want the people in the cost schedule to appear in the technical record, and the proportion of each person's time that is claimed to be supported. Most of the seven authorities expect staff costs to be apportioned using timesheets or another reasonable, consistent method supported by records. Names come free with commits, ticket assignments and notebook signatures. Time does not: capture it by project monthly at the latest, from sprint allocations, timesheets or a short confirmation by each lead.

A routine that holds

At the start of each project: the half-page note, the project key, and a label for the tickets that address the unknown.
Weekly: a ten line note per active project: what we tried, what we learned, what we try next, dated and signed.
Monthly: time by project confirmed by each lead; failed test artefacts, benchmark runs and scrap or batch records retained rather than cleared.
At each milestone: a dated line recording whether the target was met, or that work on the unknown stopped.
Quarterly: a short review with finance of the candidate projects, while the work is fresh.

When the routine lapses, and it will, do not backdate anything. Write a catch-up note now, dated now, that says it is written after the fact and points to the tickets, commits and test runs that carry their own dates. A candid retrospective note anchored to dated system records is credible; a note carrying a false date ends the claim's credibility the moment the metadata is checked.

Illustrative example

Illustrative example. Ashdown Systems Ltd, a hypothetical company, has five engineers working to make a distributed cache stay consistent under network partition while holding a 10 millisecond write latency target, which the published protocols they evaluated could not do at their scale. On 3 February the lead writes the half-page note stating the unknown. The team adds the key RD-07 to every ticket on the problem, puts the ticket id in each commit message, and writes a weekly note. Over six months the project accumulates 400 tickets, 1,200 commits, 24 weekly notes and 30 retained benchmark runs, 22 of which failed. In August a dated line records that the target was met on the 50 node test cluster. At year end finance filters the tracker by RD-07, matches the five names to payroll, and allocates 250,000 of cost from the sprint records. When a reviewer later asks for the earliest document, the team produces the note of 3 February. The benefit at that country's rate rests on records nobody wrote for tax purposes.

Across the seven countries

What each tax authority expects you to keep, in its own words; the documentation pages hold the detail.

Country	What the tax authority expects you to keep	Documentation page
United States	Keep records that link each business component to the four-part test and to the wages, supplies and contract research costs you claim.	Documentation: United States
United Kingdom	Keep project records that show the advance sought, the uncertainties and how the work resolved them.	Documentation: United Kingdom
Ireland	Keep records made at the time that show the scientific or technological uncertainty, the work carried out to resolve it and the expenditure incurred.	Documentation: Ireland
Canada	Keep records made as the work happens, such as hypotheses, test results and time records, that show the systematic investigation.	Documentation: Canada
Australia	Keep records that show the hypothesis, the experiments, the results and the conclusions for each registered activity, and that link expenditure to those activities.	Documentation: Australia
New Zealand	Keep records that show each core activity, the uncertainty it addresses and the systematic approach taken, and link expenditure to it.	Documentation: New Zealand
Singapore	Keep documents that show each project's objective, its novelty or technical risk, the work done and the qualifying expenditure.	Documentation: Singapore

Module 3: Recording as you go