How to Talk About Uncertainty Without Overclaiming
The language you use in a T661 narrative matters. Overstating uncertainty reads as speculative. Understating it undersells the challenge. Here's how to write about technical uncertainty in CRA-ready language.
The Goldilocks problem in every T661
Imagine explaining your technical challenge to a skeptical CRA reviewer who has never seen your codebase, knows the field well, and is looking for a reason to be precise. Too much uncertainty language — 'we weren't sure if it would work,' 'the outcome was completely unknown' — and they see a team that didn't plan. Too little, and they can't understand why systematic investigation was the necessary response rather than just applying existing knowledge.
The uncertainty section of a T661 narrative doesn't stand alone. It's the context that explains why the investigation in section C was necessary. Get it wrong in either direction and you weaken the whole narrative.
Uncertainty in SR&ED means: 'a competent practitioner in our field, applying existing published knowledge, could not resolve this technical problem without systematic investigation.' It does not mean: 'we found this challenging' or 'we weren't sure it would work commercially.'
Business uncertainty is not technical uncertainty
The most common reason a CPA sends a T661 narrative back for revision is business-outcome language masquerading as technical uncertainty. These statements describe real concerns — but not SR&ED-qualifying ones.
'We weren't sure if customers would adopt the feature.' 'We didn't know if the product would succeed in the market.' 'We were uncertain whether the business model would work at scale.' These describe commercial risk, not technological uncertainty. CRA reviewers flag them immediately.
The distinction matters because SR&ED is a program for technical investigation, not product risk. Your company may have faced enormous business uncertainty while simultaneously doing qualifying technical work — but the narrative needs to isolate and describe only the technical gap.
Language patterns: before and after
The difference between a weak and a defensible uncertainty description is almost always specificity.
"It was uncertain whether our algorithm would scale to the required load."
"Published algorithms for [specific problem type] exhibited [specific limitation] at [specific scale]. No documented approach resolved this constraint for our data characteristics. We investigated [approach A] and [approach B] through [method], which revealed [specific finding]."
"We weren't sure the model accuracy would be sufficient."
"Standard fine-tuning approaches applied to our domain-specific dataset produced [measurable result], which was insufficient for [specific requirement]. The absence of a documented solution for this data profile and constraint made systematic investigation necessary."
Every uncertainty statement needs a paired investigation
A narrative that identifies the technical gap but doesn't explain how it was investigated systematically is only half a claim. CRA expects to see both: the uncertainty context and the systematic investigation response.
CRA reviewers check whether the investigation statement answers: what hypotheses did you form, what experiments or analyses did you run, and what did you learn — including from dead ends. A narrative that describes only the final result without the investigation path raises questions about whether the investigation was actually systematic.
Failed investigations count and should be in the narrative. If you investigated an approach and discovered it wasn't viable for your constraints, that's a legitimate SR&ED finding. Don't edit out the failures — they're part of what makes the investigation systematic.
This guide is for general educational purposes only. How uncertainty should be framed in a T661 narrative depends on the specific facts of each project. All SR&ED claims should be reviewed by a qualified CPA before filing.
Turn this guide into a claim package
SREDY.IO walks you through eligibility, project narratives, supporting costs, and evidence so your CPA has a cleaner file to review.
More guides
Preparing a T661 Narrative Your CPA Can Actually Work With
A T661 project narrative covers technological advancement, systematic investigation, and the technical context that made new knowledge necessary. Here's how each part should read — and what CPAs typically flag.
EligibilityWhat Actually Makes Software Work SR&ED-Eligible?
Most software companies doing real R&D leave SR&ED credits on the table because they don't recognize their own qualifying work. Here's the eligibility distinction that matters.
DocumentationThe Evidence Habit: What to Save Before Year-End
SR&ED claims are significantly easier to defend when you've been saving the right artefacts throughout the year. A practical pre-year-end checklist for Canadian tech companies.
Ready to check if your work qualifies? Take the free eligibility assessment.
Check eligibility — free →