From engineering records to an evidence pack you can check
ClaimEvidence does the reading, sorting and quoting. You do the judging and the writing. Here is each step, what it produces and the safeguards behind it.
What goes in
Ticket history
An export of the client's Jira or Azure DevOps issues for the claim period, with comments and dates. A standard CSV or Excel export is enough; we never need live access to their systems.
Design documents
Specifications, architecture notes, test reports and similar, in Word or Excel. If most of the material is PDF, tell us first and we'll be straight about how well that route works today.
Your scope
The accounting period, which part of the business, and anything you already know, such as projects you plan to claim or exclude. Source code isn't needed.
What happens
Read and clean the record
Every ticket, comment and document is extracted, cleaned and indexed with its date and its place in the source, so anything quoted later can be traced back to the exact item.
Group work into candidate projects
Related tickets and documents are grouped by subject and time into candidate projects. Nothing is merged away: five attempts at the same problem stay as five records, because together they show experimentation.
Draft the evidence for each project
For each candidate project, the pack sets out the starting knowledge, what the team couldn't resolve, the approaches tried in date order, and the outcome, using only what the records say. Each statement cites the item it rests on.
Check every quote against the source
A separate, rule-based check compares every quoted passage with the original text. If a quote doesn't match exactly, it is removed and the statement it supported is marked as unsupported. Nothing reworded slips through as a quote.
Mark gaps and routine work
Where a point you'd need to make isn't supported, the pack says "insufficient evidence" and writes a specific question for the engineer. Work that looks routine, such as integration, configuration, interface changes and ordinary fixes, is listed as excluded with a reason, for you to confirm or overrule.
Hand you the pack
You receive an editable document per claim, a question list for the client's engineers, and a source index. Answers from engineers can be fed back in as new evidence, and the pack updated.
Inside an evidence pack
Each candidate project follows the questions you have to answer on the AIF and in a technical report:
- Project summary and the period it covers
- Baseline: what was known or available at the start
- The advance sought, as recorded by the team
- Uncertainties, each with when it arose and when it was resolved or abandoned
- Approaches tried, results and changes of direction, in date order
- Work excluded as routine, with reasons
- Open questions, marked "insufficient evidence"
- Source index: every item cited, with dates
Your part
The pack is a draft for professional review. You decide which projects qualify, what the advance in the field was, and whether a competent professional could have resolved the uncertainty. You write and sign the narrative and the AIF, and you decide what goes to HMRC.
Because each statement shows its source, review is checking rather than rewriting. Where you disagree with a grouping or an exclusion, change it; your decision stands.
ClaimEvidence doesn't apportion staff time or calculate qualifying expenditure, and it doesn't decide eligibility. Those remain with you and your client's finance team.
The safeguards, in plain terms
Source-locked
The model works only from the records supplied. It isn't asked to add context from its own knowledge, and the instructions forbid filling gaps.
Checked by rules, not by the model
Quote checking is ordinary code comparing text, not a second AI opinion. A quote either matches the source or it doesn't.
Gaps are a valid answer
"Insufficient evidence" is a normal result, not a failure. The system isn't rewarded for making every project look strong.
Routine work shown, not hidden
Exclusions are listed with reasons, so you can see what was set aside and why, and so a claim isn't quietly inflated.
Run records kept
Each pack records which inputs it used and when it was produced, so you can show how the evidence was assembled if asked.
No training on client data
Client content is processed in the EU on Amazon Bedrock and isn't used to train AI models. Details.
Later: evidence captured as the work happens
Our SprintReady engine already writes development tickets for regulated software teams. A planned extension would let teams record the hypothesis, the uncertainty and the outcome on tickets during the year, so next year's evidence exists before anyone asks for it. It isn't available yet; we'll build it once the back-tests show which fields advisers actually need.
Where it fits first
Software and digital product claims, where the evidence lives in ticketing systems and design documents. We're starting with UK claims under the merged scheme and ERIS, and with advisers who want to cut the time spent collecting evidence without lowering the standard of what they file.
See it on one of your own projects
A back-test on a claim you've already filed is the quickest way to judge whether this saves you time.