GitHub is a starting point for R&D evidence, not the whole story
A practical evidence chain from technical questions to experiments, decisions and costs, including GitHub’s October 2026 retention change.
A repository is good at recording that software changed. A reviewer usually needs to understand much more: what the team was trying to learn, what was uncertain, which alternatives it investigated and what the results actually supported.
That gap is why exporting every commit rarely produces a useful R&D evidence pack. The aim is to connect selected records into an explanation that an engineer, finance lead and adviser can inspect without pretending they are answering the same question.
There is also a timely reason to inspect your retention settings. GitHub’s documentation states that, starting October 1, 2026, configured retention applies to checks, workflow runs and commit statuses as well as artifacts and logs. The documented default is 90 days. Teams relying on a year-end reconstruction should check what will still exist. GitHub retention documentation.
This guide reflects sources checked on October 7, 2026. Its suggested record structure is an operating method, not a determination that any project qualifies for a tax incentive.
Begin with a question a record can answer
Consider an illustrative search team trying to reduce response latency without degrading answer quality. A pull request titled “Improve retrieval” tells a reviewer little. A design note can instead establish the baseline, the performance target, the constraint and why the proposed approach was uncertain.
The team might compare two indexing strategies on the same held-out workload. A useful record would identify the dataset version, code revision, configuration, observed latency distribution, quality metric and decision. If neither strategy meets the target, that failure still explains what the team learned and why it changed direction.
Do not rewrite ordinary maintenance as an experiment after the fact. A dependency update, a production defect and a technical investigation can all be valuable work. Their documentation should describe what happened accurately, with later eligibility analysis handled separately.
Build a chain that crosses the tools you already use
Use a stable project reference across the issue tracker, design documents, repository and cost workpaper. The reference creates a join; it does not need to become a new application or an elaborate internal taxonomy.
| Step | Useful record | Important limit |
|---|---|---|
| Question | Dated design note or investigation issue | A broad product objective may not identify a technical uncertainty |
| Attempt | Branch, pull request or experiment configuration | A code change alone does not explain why it was tried |
| Observation | Benchmark output, test result or analysis | A passing test may verify known behavior rather than new learning |
| Decision | Review comment or architecture decision | A merge approval may concern code quality only |
| Participation | Responsible people and corroborating work records | Commit count is not a time allocation |
| Cost | Invoice, payroll support and allocation explanation | Project attribution is not tax qualification |
GitHub supports links between pull requests and issues, including manual links and supported closing keywords. Use that existing connection to make the work navigable, while checking whether the linked issue contains the relevant context. An automatic “closed” status is not a research conclusion. GitHub issue and pull-request linking.
Freeze the version a reviewer actually saw
A link to a file on the default branch can display different content next month. GitHub’s permanent file links use a commit ID; its keyboard shortcut can convert a branch-based file URL into that version-specific reference. GitHub permanent links.
Apply the same idea to non-code records. Retain the selected design-note version, the exported benchmark results and the issue discussion as collected. Record collection time separately from the date of the underlying work. Preserve the original source address so a reviewer can understand both provenance and scope.
For the search example, a concise evidence index might connect project SEARCH-17 to issue 842, two selected code revisions, experiment outputs RUN-31 and RUN-32, and decision note ADR-19. The decision can cite the exact result cells supporting it. Those fictional identifiers illustrate the structure; they are not customer records.
An evidence index should also say what is absent: perhaps the baseline output expired, a contractor’s contribution is not yet explained, or a shared inference charge lacks a project reference. That makes the next request specific.
Treat retention as part of the workflow
Repository code, pull-request discussions and transient workflow data have different lifecycles. Confirm which records your collector actually retrieves; do not assume that repository access includes every historical log or artifact.
GitHub’s July 2026 announcement describes the broader retention scope and explains that the policy also covers relevant data created by third-party integrations. Review organization and repository settings, then arrange appropriate preservation before needed records expire. GitHub’s change announcement.
Choose retention according to your business, contractual and legal requirements. A provider’s default is a storage setting, not a tax-record retention opinion. Preserve necessary records with their permissions, and avoid broad exports of secrets, unrelated customer data or personal information merely to increase the file count.
Keep US and Australian assessments distinct
For a US federal credit review, apply the qualified-research tests to the relevant business components. A repository’s “R&D” label cannot substitute for that analysis. IRS Form 6765 instructions.
Australia’s software sector guide discusses records of technical hurdles, hypothesis-led experiments, observations and conclusions. It also points to the legislative criteria against which activities are assessed. A US credit narrative should not be recycled as an Australian R&DTI assessment simply by changing the heading. Australian software-sector guidance.
The evidence chain can support both kinds of review, but the legal analysis, activity definitions and cost treatment remain jurisdiction-specific. Preserve the underlying facts before deciding which report format they need.
Start with one representative project
Choose a project that includes real alternatives and a recorded decision. Ask its technical owner to explain the work using only the proposed evidence pack. Ask someone outside the project to locate the source behind each important statement. The places where that exercise breaks are more informative than a raw count of collected files.
Proforma’s initial workflow combines uploaded records with selected work connections where configured. GitHub authorization and collection scope remain explicit, and collected records need review. A first evidence review can identify source coverage, supported project notes and outstanding questions before a more formal workpaper is prepared. Explore the collection workflow.
Sources and scope
Put the records to work
Start with a clearer evidence picture.
Bring project records and costs into an initial review. See what supports the story, what is missing and what to ask next. Preparation can be manual.