SR&ED claim automation

Draft, score, and defend your T661 — without your code leaving the building.

Our first active product workflow: Aegis ingests your repository, generates the Part 2 narrative from your own contemporaneous artifacts, and scores the result against the standard a CRA reviewer applies — running entirely on our secure, local private AI engine.


Who it’s for

Engineering-led teams that own their git history.

Primary buyer

Engineering-led SMEs (10–200)

Defense supply chain, energy, and industrial software. Doing real experimental development, banned from pasting it into the cloud.

Channel

SR&ED consultancies

Firms that want to ground their narratives in contemporaneous evidence and de-risk the claims they put their name on.

Buying trigger

Year-end — or a review that stung

Fiscal year-end plus six months, or a CRA review that exposed weak evidence and made the next claim a liability.


The workflow, expanded

Ingest. Generate. Check. Judge. Band.

Each line of the T661 Part 2 gets its own treatment. Everything below runs locally.

Read the record you already kept

Aegis reads git history, test logs, reverted branches, and design docs over loopback — no upload. It extracts the dated artifacts that map to experimental work and preserves repo · hash · timestamp for every one.

checks: artifact timestamps inside the claim year · failed-approach artifacts present

Generate lines 242 / 244 / 246

Line 242 states the objective and the field knowledge-gap. Line 244 is written in chronological order as hypothesis → experiment → measured result → conclusion cycles, each linked to its artifact. Line 246 states the technological advancement — including what each failure eliminated.

every experimental assertion in 244 carries ≥1 citation to a dated artifact

Layer 1 — deterministic checks

Machine-enforceable, no LLM, run first. Word-count limits per line, required structural elements, chronological dating, and the banned-language lists: court-fatal Tier-1 phrases (“breakthrough”, “trial and error”, “standard web page programming”) are a hard fail that blocks release until fixed.

D-gate: any deterministic failure blocks the narrative from release

Layer 2 — LLM-judge against the five questions

An LLM-judge scores the draft against the Northwest Hydraulic five questions using a rubric where every criterion is anchored to a real winning and losing case. Each verdict is Pass / Partial / Fail with a one-line justification and the authority cited.

judged criteria mapped to Q1–Q5 · weighted Critical / High / Medium

One review-risk band, fully contestable

Deterministic failures are never averaged away; a single Critical fail dominates. Output: a HIGH / MEDIUM / LOW band, a flag list with the offending spans, and a per-criterion verdict table. Because every point cites an authority, the score is auditable — you can argue with it.

LOW = all Critical pass, score ≥ 85, all deterministic checks pass


Evidence traceability

The provenance ledger, made visible.

Hover any generated sentence to see the artifact behind it. This is the defense against the failure mode the courts police: after-the-fact reconstruction gets no weight.

Generated — T661 line 244 (illustrative)

In the May 2025 phase, we hypothesised that incremental response-buffering could hold paging latency under the 5-second target within the legacy stack. The buffered approach failed under concurrent load and was reverted after the degradation was measured; we then derived a dynamic single-column “stitching” query that returned results within 4.1s at the measured row counts, and recorded the result against the target. Work performed by named in-house staff; no contractor expenditure on this objective.

Hover or focus a sentence to reveal its backing artifact.

Backing artifact
Hover a sentence to trace its evidence — repo, hash, and timestamp.
Commit · hypothesis
repo
pts-project
hash
a1f4c2e
when
2025-05-06 09:14

“wip: buffered paging spike — target <5s response, legacy SQL Server 2000 stack”

Reverted branch + test log · failed approach
repo
pts-project
hash
7b9d0 ← revert
test
log #298 · failed

Branch spike/response-buffer reverted after concurrency degradation was measured. A documented failure satisfies the case-law expectation of a reverted-commit / abandoned-branch artifact.

Commit + test log · measured result
repo
pts-project
hash
2c8e11a
test
log #312 · 4.1s

“feat: dynamic single-column stitching query” — paired with test-log #312 recording 4.1s against the 5s target. Measured, not asserted.

Authorship · payroll reconcile
authors
2 in-house
contractor
none
alloc
< 100%

Commit authorship reconciles to payroll; SR&ED time allocation under 100% per person, in the software norm. Contractor work, if any, is labelled in 244.

D23Every experiment cycle in 244 carries ≥1 citation to a dated artifact. Target 100%, hard floor 90%.
D26Provenance (repo, hash, timestamp) preserved per artifact — output is demonstrably derived from contemporaneous data, not retroactive write-up.
D27At least one cited artifact evidences a failed approach — a reverted commit, abandoned branch, or failed test record.

Survivability

Language that loses, beside what Aegis writes.

The same verbatim court excerpts the rubric is built on. This block is for the non-engineer reviewer who needs to know one thing: will this survive?

Loses — inflation

“This breakthrough in system flexibility created unlimited scalability.”

Highweb, 2015 TCC 137. “Most scientific research involves gradual, indeed infinitesimal, progress. Spectacular breakthroughs are rare” (Northwest Hydraulic, para. 10).

Survives — measured

“An incompatibility, not readily resolvable with existing, accessible products, which required research…”

Highweb’s one allowed sub-claim. Incremental gains, stated with measured magnitude, never grandiose.

Loses — routineness

“The process involved was standard web page programming… no advanced technology needed.”

Zeuter, 2006 TCC 597. The taxpayer’s own concession defined the work as routine. Product usefulness is irrelevant; objectives must be in technological terms.

Survives — field gap

Names why standard methods could not predictably succeed at the claimed constraints — the alternatives, and the specific reason each fails.

Per ACSIS, 2015 TCC 263: a broken state-of-the-art assumption, falsifiable uncertainties, planned testing distinguished from trial and error.

Loses — records

Weekly notes with no hypotheses, no parameter values, no results — “no way… to replicate or confirm.”

Mac & Mac, 2017 TCC 256, para. 8. Lost on records alone, despite work that looked systematic.

Survives — replicable

Parameter values, expected-versus-observed results per test, each traced to a dated artifact a knowledgeable third party could confirm.

Per CRL, 2019 TCC 65: weekly system snapshots + a wiki of “data, methods, issues and results” satisfied the records question.

Every quote is verbatim from the Tax Court of Canada decisions, collected in the Aegis SR&ED public case-law corpus and mapped to the five-question framework affirmed by the Federal Court of Appeal.


What you get

Three artifacts, exportable.

A filled T661 Part 2, the review-risk report, and the evidence ledger — ready to file, with the provenance intact.

Human review is required before export. Aegis drafts and scores; a person signs.

t661-part2.docxFilled narrative, lines 242 / 244 / 246, within CRA word limits.
review-risk.pdfBand, flag list, and per-criterion verdicts with authorities cited.
evidence-ledger.jsonRepo · hash · timestamp for every cited artifact.
Questions

About the SR&ED workflow.

Which T661 lines does Aegis draft?

The Part 2 technical narrative: line 242 (uncertainty), line 244 (the work done, in dated cycles), and line 246 (advancement), plus the project-identification and evidence lines. Each is checked against its specific CRA word-count and structural requirements.

What if my git history is messy?

Messy is normal — and often good: reverted commits and abandoned branches are exactly the failed-approach artifacts the case law rewards. Aegis surfaces them as evidence rather than hiding them. Where the record is genuinely thin, it flags the gap instead of inventing a story.

Does it replace my SR&ED consultant?

It changes what the consultant works from. Instead of reconstructing the technical story after the fact, they review a draft already grounded in contemporaneous evidence and pre-scored for review-risk. Several consultancies use it as a channel for exactly this reason.

Can my reviewer argue with the score?

Yes — by design. Every flag and every judged criterion cites the paragraph of the ruling it rests on. The score is contestable and auditable, which mirrors the standard the CRA itself must meet when rejecting a claim.

Request a pilot

Run one project, one fiscal year.

We scope a pilot against a single project. Pricing is set per pilot — not a public grid yet.

This opens your mail client to hello@aegistech.services. No data is transmitted by this page.