Why an issue tracker suits the hypothesis record
Section 355-25 of the Income Tax Assessment Act 1997 describes core R&D as experimental activities that proceed from hypothesis to experiment, observation, evaluation and logical conclusions. AusIndustry's software sector guide names spike tickets and investigation tasks among the places that record can live. business.gov.au asks for records showing the steps, test trials, dates and people involved.
A Linear issue has those properties built in. It is created on a date, started and completed on dates, owned by a person, and threaded with comments. What it lacks by default is the content: the hypothesis before, the result after.
A structure that maps to the experiment
- Parent issue: the technical question. "Can on-device transcription keep word error rate under 8% on clinic audio?" State why existing models and settings did not answer it.
- Sub-issue per experiment. One variant each. The description holds the hypothesis and what would disprove it.
- Comments as observations. One comment per run, with the numbers, written when the run finishes.
- Close with the conclusion. The last comment says whether the hypothesis held and what the next sub-issue will try.
This keeps each experiment small enough to date accurately and makes the progression readable to someone who was not there.
Good and weak issues (illustrative)
These issues are illustrative.
| Weak | Stronger |
|---|---|
| "Improve transcription" in Backlog for months | Parent "Can on-device transcription hold WER under 8% on clinic audio?" |
| Description blank, closed Cancelled | Sub-issue "Test: noise-robust front end. Expect WER under 10%; disproved above 12%", closed Done with "WER 13.4%, disproved" |
| One issue open for five months | Five sub-issues of two to four weeks each |
| Labelled chore, in the Growth team | Labelled experiment, in the ML team |
| Result only in a Slack thread | Result in the closing comment, with the dataset and run count |
Workflow habits that keep the dates honest
- Write the hypothesis before starting. Moving the issue to In Progress sets its started date. That date does not prove the description was written first, so leave the hypothesis alone once work starts and put later thinking in comments, which carry their own dates.
- Start issues when work starts. An issue that sits in Todo while work happens loses the started date that shows when it began.
- Record failures as results. Whatever state your workflow uses, the closing comment should say what was measured and why the hypothesis did not hold. To most readers Cancelled means abandoned, and Rand's first screen leaves Cancelled issues out, so if your team cancels failed experiments, flag them to whoever prepares the claim.
- Keep experiments short. Sub-issues of a few weeks date the work more precisely than one issue left open for months.
- Mark duplicates properly. Merge or mark the duplicate and keep the record on one issue.
What Rand does with these issues
If you connect Linear, Rand reads issues from the teams you select, with their comments, parent, sub-issues, related issues and attachment links. Its first screen holds Triage, Backlog and Todo issues until they start, drops cancelled and duplicate issues, and filters labels such as chore, dependencies or maintenance and teams named for business functions, unless the issue mentions R&D terms.
Each issue that passes is assessed once and proposed for placement on a core or supporting activity; your team confirms it. Under active-day time, an issue adds every working day from started to completed to its assignee's month when that window is eight weeks or less; a longer one adds only the dates it carries. A director signs the year's hours after it ends.
Pair each experiment issue with its pull requests, as in pull requests as R&D experiment records, and see the glossary entries on hypothesis and systematic progression, and the R&D Tax Incentive resources for how the work is grouped.