Key takeaway: A T661 form example only teaches you something if it shows the actual sentences that go into lines 242, 244, and 246, not just the structure. Those three questions, capped at 350, 700, and 350 words, are the entire technical case for every project you claim. This post walks through one in full: a hypothetical software company's uncertainty, the work it did, and the advancement it reached, so you can see what a narrative built from real project records looks like next to one that isn't.
Most T661 guidance stops at "here are the ten parts of the form." That's useful for orientation and useless for the actual writing, because the part that decides your claim (Part 2, Section B, lines 242 through 246) isn't a checklist. It's three short essays, and the CRA reads them looking for specific things: a real uncertainty, chronological work, and an honest account of what you learned.
This post is a worked T661 form example built around one hypothetical project, with full example answers to lines 242, 244, and 246, so you can see the difference between a narrative that reads like an engineer wrote it from real records and one that reads like it was reverse-engineered from a pitch deck eighteen months later.
What does a real T661 form example look like?
A real T661 form example is not a template you copy and relabel — it's your own uncertainty, your own work, and your own result, written in the CRA's three-question structure. The scenario below is fictional, built only to demonstrate structure and tone; your narrative has to come from what your team actually tried, tested, and found out.
For the mechanics of every part of the form — the ten parts, the 55% proxy method, the filing deadline, the full breakdown of what each part asks for — we cover that separately. This post is only about the three hardest lines to write well: the technical narrative in Part 2, Section B.
What's the scenario for this T661 example?
The scenario: a small SaaS team building a real-time collaborative document editor hits a wall merging concurrent edits to formatted content — not plain text, but tables, embedded images, and nested comment threads edited simultaneously by multiple users.
Their existing approach used a standard operational-transformation library that works fine for plain-text merges. Under concurrent edits to structured, nested content, it started silently corrupting document state: a comment thread would disappear, or a table's column count would desync between two users' views, with no error thrown. The team didn't know whether the fix was a configuration problem, a fundamental limitation of OT for nested structures, or something that needed a different merge algorithm (CRDTs) entirely. That's the uncertainty. Everything below flows from it.
Line 242: what uncertainty were you trying to resolve? (350-word cap)
Line 242 asks what scientific or technological uncertainty you attempted to overcome, and the strongest answers name the specific unknown, not the general problem area. Here's an example answer:
"Our product allows multiple users to simultaneously edit documents containing nested structured content: tables, embedded images, and threaded comments. We used an established operational-transformation (OT) library to merge concurrent edits, which handles plain-text conflicts correctly. Under concurrent edits to nested structures (for example, one user resizing a table while another edits a comment thread anchored inside it), we observed silent state corruption: desynced column counts, orphaned comment anchors, and occasional data loss, with no error surfaced to either client.
We could not determine, from the OT library's documentation or from published literature on collaborative editing, whether this failure mode was: (a) an implementation or configuration defect in how we applied the library to nested structures, (b) an inherent limitation of OT-based merge algorithms when operations are hierarchically dependent, or (c) a problem that required a fundamentally different conflict-resolution model, such as a conflict-free replicated data type (CRDT) adapted for tree-structured documents. Existing CRDT literature we reviewed addressed flat text and simple JSON trees, not documents with cross-referencing structural elements like ours. We did not know, at the outset, which of these three explanations was correct, or whether a viable fix existed within our performance and consistency constraints."
Notice what this does that a weak version wouldn't: it states a specific, falsifiable unknown (which of three explanations is correct) instead of a vague problem statement like "collaborative editing is hard." The T661 form guide covers exactly this expectation — the CRA's own guidance says vague or non-technical answers increase the odds of further review.
Line 244: what work did you do to try to resolve it? (700-word cap)
Line 244 asks for the actual work performed in the tax year, in roughly chronological order, and the strongest answers read like a lab notebook: hypothesis, test, result, next hypothesis. A shortened version of that same project's line 244:
"We began by isolating the failure with a minimal reproduction: two clients editing a table with a comment anchored to one cell, applying operations in a controlled order. This confirmed the corruption was reproducible and not caused by network timing, ruling out our first hypothesis (a race condition in our WebSocket transport layer).
Hypothesis 2: the OT library's transform functions did not account for parent-child operation dependencies (a comment anchor depends on the table cell it's attached to; a table resize is a parent operation that can invalidate a child anchor). We instrumented the library's transform step and confirmed that when a parent-structural operation (table resize) and a child-content operation (comment edit) were transformed against each other, the library treated them as independent, producing an invalid combined state. This confirmed part of hypothesis 2, but didn't yet tell us whether a fix was possible within OT or required a different model.
We spent several weeks attempting an OT-based fix: extending the transform functions with explicit parent-child dependency tracking, so a child operation would be re-validated against its parent's post-transform state. This reduced corruption in the two-level case (table → comment) but did not generalize to three or more levels of nesting (table → cell → comment thread → reply), because the number of dependency paths grows combinatorially with nesting depth, and our extended transform functions became too complex to verify for correctness. We concluded, at this point, that a general fix within our existing OT model was not practical at our target performance budget.
We then evaluated a CRDT-based approach, specifically a tree-structured CRDT where each node carries a stable identity independent of its position, so structural moves and content edits can be resolved independently rather than transformed against each other. We built a prototype implementing this for our three levels of nesting (table, cell, comment thread) and ran the same reproduction cases that broke the OT approach. The tree-CRDT prototype resolved the two- and three-level nesting cases correctly, including the specific table-resize-plus-comment-edit case that started this investigation. We then load-tested the prototype against our production edit volume to check whether the CRDT's larger per-operation metadata overhead would create unacceptable latency; initial results showed a moderate increase in payload size that we deemed acceptable at current usage but flagged as a scaling risk to revisit."
The chronological structure matters more than the prose style. Per the T661 form guide's reading of the CRA's own guidance, this line asks specifically for hypotheses tested, results, and conclusions, not a narrative summary of the finished feature. If your line 244 could be rewritten as marketing copy for the shipped product, it's answering the wrong question.
Line 246: what technological advancement did you achieve? (350-word cap)
Line 246 asks what advancement you achieved or attempted to achieve. Most founders miss the detail that a project that didn't fully succeed can still be a strong answer, because eliminating a wrong approach is itself an advancement. An example closing answer:
"We determined that operational-transformation-based conflict resolution does not generalize to documents with more than two levels of structural nesting without a combinatorial increase in transform complexity that becomes impractical to verify or maintain. This limitation is not documented in the OT library's own materials or in the collaborative-editing literature we reviewed, which focused on flat or shallow structures. This is itself an advancement: it eliminates OT as a viable path for our document model and any similar deeply-nested collaborative structure, a negative result that saves future engineering effort down a path we've now shown doesn't work.
We further advanced our own technical knowledge base by building and validating a tree-structured CRDT prototype that correctly resolves concurrent structural and content operations for our three-level nesting case, something we could not do reliably with our starting approach. We have not yet validated this at full production scale or beyond three nesting levels, so the advancement achieved this year is the demonstrated viability of the tree-CRDT model for our structure, not a completed production migration."
That last sentence is doing real work: it's honest about what wasn't finished. The T661 form guide covers this directly — the CRA's guidance states that novelty or features alone don't demonstrate advancement, but a documented failure or partial result, reached through systematic investigation, does.
What makes a T661 narrative weak instead of strong?
A weak T661 narrative describes the finished feature; a strong one describes the uncertainty and the investigation that resolved (or didn't resolve) it. Some contrasts that show up constantly in real claims:
- Weak: "We built a robust real-time collaboration engine that handles complex document structures." Strong: the version above, naming the specific merge failure, the three competing explanations, and which one turned out to be correct.
- Weak: "We researched several approaches and implemented the best one." Strong: naming the approaches, what specifically was tested about each, and why the rejected ones failed.
- Weak: listing the tech stack (React, WebSockets, a CRDT library) as if the tools themselves were the uncertainty. Strong: treating the tools as given and describing the unknown that using them didn't resolve.
- Weak: writing the narrative as a project retrospective, after the feature shipped, from memory. Strong: writing it from tickets, commit messages, design docs, and test results generated while the work was happening — which is also your supporting evidence if the claim gets reviewed later, a subject we cover in what a SR&ED review actually looks like.
Where does this narrative fit in the rest of the T661 form?
This narrative is only Part 2, Section B of ten parts — the technical case, not the financial one. The dollar side (Part 3's proxy or traditional method election, Part 4's qualified expenditures, Part 5's prescribed proxy calculation) runs on a separate track, using the salaries, contractor payments, and materials tied to the same project. We cover that full structure, plus the filing deadline and what gets claims denied, in the complete T661 form guide.
One thing this example deliberately doesn't show: how much of the underlying eligible work actually qualifies before you even get to writing the narrative. If you're unsure whether a project like this one clears the bar, start with what actually counts as SR&ED-eligible work — the two-part "why" and "how" test the CRA applies — before spending time writing narratives for projects that won't survive the eligibility question at all.
What should you do differently than this example?
You should not reuse this example's structure as a fill-in-the-blank template. Per the T661 form guide, the CRA's guidance explicitly rewards narratives written in the language of the people who did the work, and a narrative that reads like it was copied from a blog post reads exactly that way to a reviewer. Use this as a demonstration of the kind of specificity and honesty the form wants, then build yours from your own tickets, pull requests, design docs, and test logs.
If you have one small project, wrote the code yourself, and can still remember the actual dead ends without digging through six months of Slack history, you may not need help writing this — the form is demanding, not mystical, and a technically fluent founder can write a compliant narrative directly from the T4088 guide. Where this gets genuinely hard is at more than one or two projects, with engineers who've since left, or when the "why we tried X and it failed" detail only exists in a closed pull request nobody will reread unprompted.
That's the specific gap Glauq is built to close. Our AI drafts these narratives continuously from the tickets, commits, and design discussions your team already produces, so the uncertainty-work-advancement structure gets built from contemporaneous records instead of a scramble eighteen months later. A qualified, independent SR&ED expert then reviews and edits every narrative before it's filed and stands behind it if the CRA asks questions: the automation gets the narrative written, and the named human is who defends it.
Frequently asked questions
What should a T661 line 242 answer include? Line 242 should name the specific scientific or technological uncertainty your team faced, not the general problem area, and explain why existing knowledge, tools, or published approaches couldn't resolve it in advance. The strongest answers state a falsifiable unknown, the way the example above frames three competing explanations for a merge failure, rather than a broad statement like "the problem was technically challenging."
Does a T661 narrative have to describe a successful project? No. Per the T661 form guide and the CRA's own T4088 guidance, a project that failed to achieve its objective can still be a strong advancement, because ruling out an approach is itself new knowledge. The example's line 246 above shows this directly: the team didn't finish a production migration, but it did establish that OT-based merging doesn't scale past two nesting levels, which is a real, claimable result.
How long should a T661 form example narrative actually be? As long as it needs to be within the caps (350 words for line 242, 700 for line 244, 350 for line 246) and no longer. Padding a narrative to fill the cap without adding technical specificity works against you; the CRA's guidance flags unnecessarily lengthy answers as a risk factor the same way it flags vague ones.
Can I write one narrative and reuse it for multiple similar projects? No. Per the T661 form guide, Part 2 must be completed per project, and a narrative copied across projects with only surface details changed reads as generic rather than technical — the opposite of what the form rewards. If you have many similar-sounding projects, the differentiation has to be in the actual uncertainty and work performed for each one, which is exactly why teams with more than a couple of projects tend to need more structured help capturing it.
Where do I write the financial side of a project like this example? Not in Part 2. The technical narrative in lines 242–246 only establishes that the project is SR&ED; the dollar figures (salaries, contractor costs, your proxy or traditional overhead election) are calculated separately in Parts 3 through 5. The T661 form guide walks through that full financial side and the filing deadline that applies to the whole form.
A T661 form example is only useful if it shows you the sentences, not just the boxes. Build yours from what your team actually tried and actually learned, keep it inside the word caps, and it will read like exactly what it is: a technical account written by people who did the work.
See what a claim like this could be worth — estimate your refund or check your eligibility.