What makes a document contemporaneous
business.gov.au says records should be created at the time the activity is conducted, kept for five years after claiming the expenditure, and show the steps, trials, dates and people involved. It lists experimental plans, project plans and meeting records among the records that support core R&D. AusIndustry's software sector guide adds design notes and architecture decision records. The ATO's ruling TR 2018/2 says electronic records, including those stored in the cloud, carry the same record keeping requirements as paper records and must be in a form the ATO can access and understand.
So the format is fine. What matters is timing and content: the expectation written down before the work, and the outcome recorded after it, without one overwriting the other.
A page template that keeps the sequence
- Status and dates. Started, owner, linked tickets and pull requests.
- Problem. The technical hurdle, with the measurement that shows it.
- What we checked first. Published methods, vendor documentation or prior attempts, and why they did not answer the question.
- Hypothesis. What you expect, and the result that would prove it wrong.
- Options considered. Each option and why it was chosen or rejected.
- Log. A dated heading for each experiment or week, with what was run and what was observed.
- Conclusion. Whether the hypothesis held, what was learned and what comes next.
Sections 2 to 5 are written before the work and afterwards changed only by dated additions. Sections 6 and 7 grow as the work happens.
Good and weak design docs (illustrative)
These pages are illustrative examples.
| Weak | Stronger |
|---|---|
| "Sync engine design", last edited in July, describing only the final design | "Offline sync conflict resolution", created in February with the hypothesis, plus dated log entries to June |
| Hypothesis section rewritten to match the result | Original hypothesis kept; a dated entry records that it was disproved |
| Results pasted as a chart image | Results as text with the chart below it |
| One page covering three years of work | One page per experiment cycle, linked from a project index |
| Tidied by a manager last, author unknown | Authors named at the top; reviewers comment rather than rewrite |
| Deleted when the project shipped | Moved to an R&D records space and kept |
Habits that protect the record
- Date everything inside the page. Notion records created and edited times, but dated headings show the order within the page.
- Add to the hypothesis rather than rewriting it. If it changes, add a dated entry saying why. A silently rewritten hypothesis reads as hindsight.
- Keep the history. Notion's page history shows what changed and when, but how far back it goes depends on your plan. Export the page when the hypothesis is set and when the work concludes if you need a longer record.
- Prefer a new page over a renamed old one. A new cycle with a new hypothesis is a new page, linked to the last.
- Keep text as text. Diagrams help, but write the numbers and conclusion in the page body.
What Rand does with design docs
If you connect Notion and share these pages, Rand reads their text, including nested blocks and captions, but not the contents of images, PDFs or embeds. It assigns each page to the financial year it was created and attributes it to its last editor. A page started in an earlier year is not read for the current one, which is one more reason to start a fresh page for a new cycle. Pages in the trash, which Notion reports to Rand as archived, are skipped.
Each page becomes a record that Rand's AI proposes to place on a core or supporting activity, for your team to confirm. The Jira worklogs guide covers the time side of the same work, and the contemporaneous evidence glossary entry and R&D Tax Incentive resources cover the rest.