Use AI to draft the R&D narrative. Make every important claim inspectable.

A persuasive paragraph is easy for an AI system to produce. A paragraph that accurately explains six months of engineering work is a different task. It must preserve dates, distinguish proposed experiments from completed ones and avoid turning a tentative team comment into an established result.

AI can still be useful here. It can help locate related records, summarize competing explanations and draft questions for the people who did the work. The productive boundary is to make each material claim traceable to evidence and review, instead of treating polished prose as evidence in its own right.

The method below is an original workflow proposal informed by primary research and NIST guidance checked on October 7, 2026. It applies to technical documentation and review preparation; it does not establish tax eligibility.

Why a citation is necessary but insufficient

NIST’s Generative AI Profile identifies confident false output as a risk and recommends checking sources and citations during evaluation and monitoring. A model can cite a real document while misrepresenting its contents. NIST AI 600-1.

Retrieval-augmented generation combines a model with retrieved information. The original 2020 RAG research demonstrated improvements on particular knowledge-intensive tasks, but those experiments did not establish that any retrieved-document workflow will produce an accurate R&D report. Lewis and colleagues, NeurIPS 2020.

The ALCE research provides a useful distinction: fluency, correctness and citation quality are separate evaluation dimensions. Its 2023 benchmark is not a current production accuracy estimate, but the separation remains valuable when deciding what reviewers should inspect. Gao and colleagues, EMNLP 2023.

A review should therefore ask both “Does this link work?” and “Does this exact source support this exact statement?”

Start with a source pack, then ask for prose

Choose a bounded project and reporting period. Assemble the documents you intend the draft to use: selected issues, design notes, test outputs, review comments and available cost records. Keep source names, owners, event dates and collected versions visible.

Avoid handing the model an undifferentiated folder and asking it to “find all our R&D.” That instruction leaves it to infer the project boundary, the relevant legal framework and the meaning of missing records at the same time. Start with a narrower question, such as explaining why a particular search architecture changed between two dated reviews.

For repository files, use a commit-specific link when recording the supporting version. GitHub documents this as the way to refer to the exact file content rather than the changing head of a branch. GitHub permanent-file guidance.

Treat external documents as records to analyze, not instructions to execute. Keep credentials and irrelevant personal information outside the source pack. If a sensitive record is necessary, use the approved access and processing arrangement for that engagement.

Build a claim table before a narrative

Ask for a short table that separates what the records say from what the reviewer still needs to determine.

This fictional example shows why a single confidence percentage is often unhelpful. A statement may be accurate about latency and unsupported about quality. Split it into smaller claims so the reviewer can approve one without accidentally endorsing both.

Use explicit statuses such as supported, conflicting, inferred and missing. These are review aids, not statistical probabilities. A record that contains an assertion may itself be mistaken; supporting evidence still requires assessment.

A better draft preserves the inconvenient details

Suppose a project note says an experimental cache “looks promising,” a benchmark shows lower median latency, and a later issue reports failures on unusually large inputs. A careless summary might say the team validated a faster, reliable caching system.

A more defensible draft would say: “The first benchmark recorded lower median latency for the experimental cache. The supplied records do not establish reliability across large inputs; a later issue describes failures in that condition. The team’s final adoption decision is not included in this pack.”

That paragraph is less celebratory and more useful. It identifies what was observed, what remains uncertain and the next record to find. It also preserves a potentially important engineering result: an approach that works on average can still fail a critical constraint.

Do the same for dates. A retrospective interview can explain a missing detail, but label it as a later recollection. Do not generate a contemporaneous-sounding experiment diary and imply it existed when the work happened.

Give reviewers different, explicit jobs

The technical owner checks whether the account accurately describes the work. A finance reviewer checks that amounts, periods and allocation explanations match the available cost records. A jurisdiction-appropriate adviser evaluates any proposed tax treatment. A product owner may assess the business outcome.

These responsibilities can overlap in a small company, but they should still be explicit. Approving a factual project summary is not the same as approving a credit calculation. Keep the report version and review scope attached to the decision, so later edits do not silently inherit an earlier approval.

AI can prepare a first pass of the claim table or identify contradictions. It should not fill empty cost fields with plausible estimates unless an estimate is specifically requested and visibly labeled. A missing allocation is a question to resolve, not an invitation to make the total look complete.

Measure whether assistance actually reduces work

Track the full preparation cycle. A fast first draft can be expensive if every sentence needs correction. In an illustrative comparison, manual preparation takes eight hours. AI assistance reduces drafting to two hours but requires three hours of source checking and one hour of corrections. The total is six hours: two hours saved, before considering tool cost and whether quality held.

If review and correction instead take seven hours, the assisted process takes nine hours. Measuring only drafting time would report a dramatic improvement while hiding a worse result.

Evaluate a small representative set of narratives. Count unsupported material claims, missed contradictory records and unresolved gaps, and record reviewer effort. Define what counts as a material claim before scoring. Use those observations to improve the source pack and task design, rather than merely changing the prompt’s tone.

Where Proforma fits

Proforma’s initial evidence review starts with supplied records, source coverage, supported project notes and next questions. Preparation can be manual. In the broader Workspace, a configured agent can help investigate available files and data and draft material for review. Signup does not produce an automatically approved R&D narrative or tax report.

The useful first step is one project with a named technical owner and a bounded set of records. Bring the uncertain parts too: failed attempts and missing evidence make the review more informative. See the R&D evidence workflow.

Sources and scope

• NIST: Generative AI Profile, AI 600-1
• Lewis and colleagues: retrieval-augmented generation, NeurIPS 2020
• Gao and colleagues: citation evaluation, EMNLP 2023
• GitHub: permanent links to exact file versions

The sample claims and time comparisons are invented teaching examples. They are not measured product performance or customer results.