R&D Documentation Capture

The problem it solves

Ask an engineer in January what they tried in March and you will get a vague answer, a guess or silence. That is not a criticism. Memory fades, projects blur and people move on. Yet a research credit claim often depends on exactly that information: what was uncertain, what was attempted, what did not work. The documentation capture module is built on the idea that this detail is cheap to record at the time and expensive to rebuild later.

It does not ask people to keep a separate diary. It collects what they already produce in the course of work, links it to the right project and prompts for a short note only where the record would otherwise be silent.

What it does

The agent collects records from the tools your team already uses, including Jira, GitHub, Asana, timesheets, meeting notes, design files and test logs. Each record is saved against the business component it belongs to, so the file is ready for the business-component detail on Form 6765 Section G. Which connections exist for your setup is confirmed before you rely on them.

What good capture looks like

Good capture is dull. Tickets have descriptions that say what is being attempted. Test results are saved where the agent can reach them. Notes explain why a design was dropped, not only which one was chosen. The agent cannot make a team write better tickets, but it can show a manager which projects have clear records and which do not, early enough to change habits.

Teams often find that one small change helps most: asking people to add a sentence when work hits a surprise. That sentence, written at the time, is often the most persuasive evidence a claim has.

A worked example (illustrative)

This is an invented scenario. A six-person product team is building a recommendation feature. In April a developer finds that the first approach scales poorly. The ticket says only "performance issue". The agent notices the thin record and asks for a line. She writes: the first method slowed sharply with larger catalogs, so she tried two alternatives and compared their speed and accuracy. The note is saved against the project with the date and linked to the test results she uploaded. At year end the reviewer reads the project file and sees the problem, the alternatives and the results in order, with dates, instead of a reconstructed account.

Limits and privacy

The module only captures what exists. If work is done in ways that leave no record, such as a conversation at a whiteboard, the agent can prompt for a note afterwards but cannot create evidence. It also sees only what you connect, and it should not be pointed at systems that contain information unrelated to the work. We agree access in writing, limit it to what is needed and do not claim certifications we do not hold. The module does not decide whether work qualifies. A licensed CPA or enrolled agent does.

How it fits with the other modules

Documentation capture is the base the other modules read from. Screening uses it to decide what looks like research and what looks routine. Time allocation uses project activity to cross-check what people say. The defense binder links each figure to records captured here. Switching the module on first, even before the others, means the evidence is accumulating while you decide what else to add.