How to Write a Strong SR&ED Technical Narrative

The technical narrative is your claim's foundation

When CRA reviews an SR&ED claim, the technical report (Form T661) is their primary window into your work. Financial schedules tell them *how much* you spent; the narrative tells them *why* it was SR&ED. A weak or vague narrative invites scrutiny, requests for additional information, and potential disallowances.

Strong narratives are not literary masterpieces. They are precise, structured, and evidence-backed accounts of systematic experimentation. This guide walks through each section CRA expects and how to write for reviewers who may not share your domain expertise.

Start with the right project boundaries

Before writing prose, define your SR&ED projects correctly. A project should group work aimed at resolving related technological uncertainties—not every sprint in your roadmap.

Good project boundary: "Real-time fraud scoring under 50ms latency on edge devices" — a coherent technical challenge with linked experiments.

Poor project boundary: "Platform improvements Q3" — too broad, mixes routine and experimental work.

Each project in your claim should map to a distinct uncertainty and a body of experimental work. Most startup claims contain two to six projects; quality matters more than quantity.

Section 1: Technological uncertainty

This is the most critical paragraph in your report. You must show that knowledgeable practitioners in your field could not determine at the outset:

• Whether the objective was achievable at all, or
• How to achieve it using standard practice

Weak example: "We were uncertain if the feature would work."

Strong example: "Existing off-the-shelf anomaly detection models achieved 92% accuracy on our dataset but required 800ms inference time on our target hardware. Industry practitioners typically addressed latency by scaling cloud infrastructure, but our deployment constraint required on-device inference under 50ms without sacrificing precision below 90%. No established approach in the literature or our prior systems combined these constraints. We could not determine at the outset whether model compression techniques would preserve sufficient accuracy."

Notice the strong example names constraints, explains why standard practice failed, and anchors uncertainty in technical parameters.

Section 2: Standard practice limitation

CRA wants to understand what you tried from conventional knowledge before experimentation was necessary. Reference:

• Vendor documentation and its gaps
• Published papers or open-source approaches and why they were insufficient
• Internal legacy systems and their limitations

Avoid dismissing standard practice without evidence. If a library almost worked, explain the specific gap—memory footprint, API incompatibility, accuracy regression—that forced experimental work.

Section 3: Hypotheses tested

List hypotheses in testable form. Each hypothesis should propose a causal link between your experimental approach and the uncertainty.

Example hypotheses:

1. "Quantizing the model to INT8 with per-channel calibration will reduce inference time below 50ms while maintaining accuracy above 88%."

2. "A distilled student model trained on the full model's outputs will achieve 90% accuracy with 40% fewer parameters."

3. "Pruning attention heads below 20% density will not degrade F1 score on our fraud subclass."

Number hypotheses so you can reference results cleanly in the next section.

Section 4: Experiments and analysis

This section should read like a lab notebook, not a product changelog. For each hypothesis:

• Method — What you built, changed, or measured
• Dataset or conditions — Representative production data, hardware, load conditions
• Results — Quantitative outcomes, including failures
• Conclusion — Whether the hypothesis was confirmed, refuted, or partially supported

Include failed experiments. CRA recognizes that failure demonstrates genuine uncertainty and systematic investigation. A narrative where every experiment succeeds looks fabricated.

Tip: Tables and bullet points improve readability. Reviewers appreciate concise metrics over lengthy prose.

Section 5: Technological advancement

Advancement does not require a scientific breakthrough. It means you gained new technical knowledge—capabilities, constraints, or performance characteristics that were not known or readily available before your work.

Frame advancement as knowledge acquired:

• "We determined that INT8 quantization alone reduced accuracy to 84%, below acceptable thresholds, but combined with distillation recovered 91% accuracy at 47ms inference."
• "We established that standard OAuth flows could not meet our latency requirements without a custom token validation cache architecture."

Avoid marketing language ("best-in-class," "industry-leading"). CRA reviewers respond to specific, measurable knowledge gains.

Section 6: Supporting evidence

List evidence that corroborates your narrative:

• Source control history for experimental branches
• Architecture decision records (ADRs)
• Benchmark scripts and output logs
• Design documents for prototypes
• Test results and CI artifacts
• Meeting notes from technical design reviews

You do not submit all evidence with the initial claim, but CRA may request it. Organize evidence by project and hypothesis so you can respond within deadlines.

Writing style guidelines

Use plain language. Assume the reviewer is technically competent but not a specialist in your niche. Define acronyms on first use.

Be specific with numbers. Latency, throughput, error rates, dataset sizes, and hardware specs anchor credibility.

Maintain tense consistency. Uncertainty is described at project outset (past tense). Experiments are described as completed work (past tense).

Avoid eligibility arguments. State facts; let the structure speak to eligibility. Phrases like "this clearly qualifies as SR&ED" waste word count.

Keep project descriptions within CRA limits. Line 200 and associated fields have character limits. Draft in a document first, then compress without losing technical precision.

How ELEMONT structures narratives

Our platform breaks the technical report into guided sections—technological uncertainty, standard practice, hypotheses, experiments, advancement, and evidence—mirroring CRA's review framework. Teams draft incrementally throughout the year rather than scrambling at filing time.

AI-assisted review can flag vague uncertainty statements, missing hypotheses, and sections that read like product marketing instead of experimentation logs. Expert technical review adds a human CRA-experienced lens before submission.

Red flags that trigger deeper review

From our experience supporting audits, these patterns increase CRA scrutiny:

• Identical narrative text copied across fiscal years with minor date changes
• Uncertainty statements that describe business risk, not technical uncertainty
• No failed experiments or dead ends
• 100% of engineering time allocated to SR&ED
• Narratives that describe only successful feature launches

Checklist before filing

• [ ] Each project has a distinct, well-bounded uncertainty
• [ ] Standard practice limitations are explained with specifics
• [ ] Hypotheses are numbered and testable
• [ ] Experiments include quantitative results and failures
• [ ] Advancement is framed as knowledge gained
• [ ] Evidence is indexed and retrievable
• [ ] A technical reviewer unfamiliar with your codebase can follow the logic

Final thought

The best SR&ED narratives are honest engineering records written for a technical audience. If your team already practices thoughtful experimentation, the narrative is a structured export of decisions you made—not a creative writing exercise invented at year-end.

This article is general information only and does not constitute tax, legal, or accounting advice. CRA acceptance of any narrative approach is not guaranteed.