Why Jira Tickets Don't Pass CRA Technical Review

The New Pitch: "Skip the Interview"

A growing number of SR&ED tools promise to generate your claim automatically by connecting to Jira, GitHub, and Slack. No interviews. No surveys. No disrupting your engineering team.

The pitch is built on a real insight: after-the-fact interviews are imperfect. Engineers forget details. Timelines blur. These tools argue that passive data pulled from engineering systems is superior because it's contemporaneous: created in real time, during the work itself.

It's an appealing narrative. It's also wrong, at least for SR&ED.

The data captured in engineering tools was never designed to answer the questions CRA actually asks. The gap between what Jira captures and what CRA requires isn't a formatting problem. It's a fundamental mismatch in what's being documented.

CRA Doesn't Ask What You Built. CRA Asks What You Didn't Know.

The SR&ED program is built on three pillars that CRA evaluates in every technical review, codified in IC86-4R3 and T4088:

Now consider what a typical Jira ticket contains: a title, a feature description, an assignee, a status, and some comments. A GitHub commit says "refactored conflict resolution module." A Slack thread might contain an architecture debate.

None of these artifacts answer the question: what didn't you know when you started?

Technological uncertainty is the single most important eligibility criterion in SR&ED and it's the primary reason claims get denied. You cannot extract uncertainty from a commit log because engineers don't write commit messages about what they didn't know. They write about what they did.

What Engineering Data Captures and What It Misses

"Contemporaneous" Doesn't Mean "Compliant"

CRA does prefer contemporaneous documentation, and this is a legitimate advantage of passive data. But the argument conflates when something was documented with what was documented.

A Jira ticket created during the work is contemporaneous documentation of what the team planned to build. It is not contemporaneous documentation of what uncertainties existed, what hypotheses were formed, or what was learned.

Consider an analogy: a surgeon's operating room schedule is contemporaneous proof that a procedure occurred. But it tells you nothing about the diagnosis or why the surgeon chose one technique over another. The operative report, written after the procedure, documents the clinical reasoning. Both are valuable. Only one answers the important questions.

CRA policy requires that claimed work involve technological uncertainty not resolvable through standard practice, distinguishing eligible SR&ED from routine engineering. A passive system that treats all Jira tickets as potential SR&ED input has no mechanism for making this distinction. It relies on AI inference, which is precisely the kind of unsupported claim generation that creates audit risk.

What CRA Reviewers Actually Look For

CRA Research and Technology Advisors aren't looking for evidence that development occurred. That's assumed. They evaluate a specific chain of reasoning:

1. 1

   Was the uncertainty genuine?

   Could the answer have been found through standard practice? Passive data provides no evidence. It doesn't document what was known vs. unknown at the outset.

2. 2

   Was the investigation hypothesis-driven?

   CRA requires evidence the team formed a hypothesis and designed work to test it. Commit logs don't contain hypotheses.

3. 3

   Is the advancement framed as new knowledge?

   An RTA will reject 'we built a faster API.' They want: 'We established that approach X achieves Y performance under Z constraints, which was previously unknown.'

RTAs are also trained to spot red flags: generic uncertainty language, systematic investigation that describes a standard dev process rather than hypothesis testing, and advancement claims that restate project scope. Passively generated claims are susceptible to all three.

Why We Interview, and How We Do It Differently

SR&EDgpt uses structured interviews not because we can't ingest engineering data, but because interviews are the only reliable method for extracting what CRA evaluates: uncertainty, hypothesis, and advancement.

Our interviews are structured around CRA's eligibility framework:

Interviews are inherently reconstructive, and CRA rightly values contemporaneous documentation. That's why SR&EDgpt pairs structured interviews with engineering tool data. The interviews capture what CRA evaluates (uncertainty, hypothesis, advancement), while the tool data provides the contemporaneous corroboration that strengthens the claim's credibility. Neither is sufficient alone.

We're not against engineering data. It's excellent for time allocation (Part 4), corroborating timelines, and building a supporting evidence index. But it should support the claim, not generate it.

The strongest SR&ED claims combine both: structured interviews for what CRA evaluates, backed by tool data for corroboration.

What Happens When Passive Claims Get Reviewed

The real test isn't whether a tool produces a claim. It's whether that claim survives CRA technical review. When an RTA reviews a passively generated claim, three problems surface:

The Bottom Line

Passive data ingestion solves a real problem: reducing the burden on engineering teams. But it solves the wrong problem for SR&ED.

CRA doesn't deny claims because timelines were poorly documented. CRA denies claims because the uncertainty wasn't genuine, the investigation wasn't hypothesis-driven, or the advancement wasn't articulated as new knowledge.

These are fundamentally human assessments. They require asking engineers what they didn't know, why they chose a particular approach, and what they learned. No commit log, Jira ticket, or Slack thread captures this.

Engineering tools are powerful supporting evidence. Combined with structured interviews, they produce claims that are both contemporaneous and complete. But alone, they are not a substitute for understanding what your team actually went through.