Why Your SR&ED Claim Fails: A Chat Log Is Not a Record
Canada's funding problem isn't discovery. It's the third question.
Founders are told the hard part of non-dilutive funding is finding the programs. It isn't. SR&ED, IRAP, and OCI all ask the same three things: what are you building, why was it technically uncertain, and what record did you keep while you built it. Applications die on the third one.
The first two questions are a pitch. Founders are good at pitching — it's the muscle they've trained for two years across investor meetings, demo days, and accelerator interviews. Describing an ambitious build and explaining why it was hard is a story you can tell cold, at a table, with no preparation.
The third question is not a pitch. It's an audit. Nobody is asking whether you believe the work was novel. They're asking what exists, in writing, from the period when the work happened.
And that's the part almost nobody has.
Why AI-assisted development leaves no paper trail
The last two years of AI-assisted development produced an enormous amount of running code and almost no explainable systems. That's not a criticism of the tools — Cursor, Lovable, Replit, and the rest are extremely good at the thing they were built for. It's an observation about what they leave behind.
Think about where the artifacts of a modern build actually live. The requirements are in a chat log. The architecture is whatever the schema became after the eleventh refactor. The design decisions — why Postgres over the queue, why the sync job runs the way it does, why the first three approaches to the matching logic didn't work — were reasoned through in a conversation with a model, resolved in an afternoon, and never exported.
That last item is the expensive one. Technical uncertainty is the exact thing an SR&ED claim rests on. It is the reason the work qualifies as experimental development rather than routine engineering. And in an AI-assisted workflow, uncertainty gets identified and resolved inside a single session, leaving behind a working commit and no trace of the problem it solved.
The teams these programs were designed to fund are the ones least equipped to substantiate a claim — they did the R&D, and they can't prove it.
Meanwhile, the team that built the same product slowly, with a Jira board and a design doc and a Slack channel full of arguments, walks into a review with a file folder.
What actually counts as a record — and what reviewers do with it
Be precise here, because anyone who has worked on a claim will catch an overstatement. Contemporaneous documentation is not, strictly speaking, mandatory. The Tax Court has accepted credible testimony in cases where the written record was thin, and claims have survived on the strength of a witness who could explain the work.
Concede that. Then look at what it costs. Winning on testimony means you have already lost the fast path: you're in review, you're paying an advisor, your refund is deferred by quarters rather than weeks, and the outcome turns on how one person performs under questioning about work they did eighteen months ago. CRA's review practice leans hard on evidence created while the work happened, because that's the evidence that can't be reconstructed to fit the claim. Testimony is a road that exists. It's not a road you want to be on.
So what does a record look like when it's doing its job? Not volume. Not a wiki nobody reads. Five things, kept as you go:
-
The hypothesis — what you set out to build and what you expected would work
-
The uncertainty — the specific thing you did not know was achievable, written down while it was still unknown
-
The attempts — including, especially, the ones that failed and why they failed
-
The people and the period — who did the work, roughly when, against which problem
-
The link to the spend — how the technical work connects to the costs you're claiming
Read that list again and notice something: it is almost exactly what a good specification contains before you write any code. The hypothesis, the unknowns, the constraints, the decisions. Nothing on that list is bureaucratic overhead invented by a funding agency. It's the same document that stops your team from building the wrong thing.
This is Codalio's whole argument, applied to a case founders don't usually connect to it. Vibe coding ships prototypes; spec-driven work ships products — and it also ships the record that proves what you built.
What to do Monday if you're claiming next spring
Four things, none of which require hiring anyone.
Export what you still have. Chat histories rotate, workspaces get deleted, and seats get reassigned when someone leaves. If your reasoning from the last six months lives in a tool's session history, it is one billing change away from gone. Pull it into a repo this week.
Write the uncertainty down before you resolve it. One page, at the start of each hard problem: what we don't know, what we're going to try, what would count as failure. It takes twenty minutes and it is the single highest-value artifact in a review, because it can only have been written before the answer existed.
Make the specification the source of truth, in both directions. A spec that drifts from the code is worse than no spec, because it looks authoritative and isn't. When the requirements document and the implementation stay in sync — spec informs code, code changes update the spec — the record becomes a by-product of building instead of a project you run in April with three weeks to the deadline. The same artifact answers a procurement questionnaire, an enterprise security review, and a new engineer's first week.
Date everything. Commits, decisions, documents. A record without timeline is an assertion.
Codalio won't write your application, and it won't make an ineligible project eligible — say that plainly, because the alternative is another vendor claim you'd be right to discount. What it does is make the documentation exist without a separate documentation habit. Codalio is the only AI platform that takes non-technical founders from idea to PRD to working prototype — without the rebuild cycles that come from skipping the spec.
Where this leaves you
If you're building with AI and planning to claim SR&ED, IRAP, or a provincial program next cycle, the gap isn't your engineering. It's that your engineering left no evidence it happened.
Book a strategy call with Codalio and we'll walk through your current build — where the requirements actually live, and what it would take to turn them into a spec that holds up in front of a reviewer. Start at codalio.com. You'll leave with a clear read on what's documented, what isn't, and what's recoverable.
References
-
CRA guidance on SR&ED supporting evidence and review practice
-
Tax Court decisions accepting oral testimony where records were incomplete
-
NRC IRAP project reporting requirements
-
Ontario Centre of Innovation program criteria