Why not just point Claude at your GitHub?

Setup

TL;DR

1. Claude did not produce garbage. That's what the tax advisors wouldn't want you to hear, and why the rest of this is worth reading.

What worked well:

• The big picture was there. Eight of the nine projects it proposed map onto projects we independently identified as qualifying.

• The calculation was roughly right. For 60% of people where it was able to size contributions, it landed within ±15% of our figure.

2. What it missed costs you a fifth of the claim.

The gap is not Claude being wrong about the work. It's that it never saw that certain engineers – and entire projects – existed.

Three qualifying projects were never proposed at all, and 15 of the people we sized never appear anywhere in its output. That resulted in a ~22% claim loss – reported with exactly the same confidence as the rest.

3. The narratives risk being audited.

This one is less obvious, but more expensive if you assess the risks.
Claude's narratives describe what changed, not what was technically uncertain and how that was resolved – leaving five of its nine projects with no evidence of a technological uncertainty at all.

Submitted as is, these are the kind of narratives that attract an audit, which can take up to 3 years of back-and-forth and the whole organisation being under scrutiny by tax authority for the future claims to come.

So, are the outputs usable?

Yes, if you turn a blind eye close these gaps. But closing them would mean spending time to re-design the methodology, and doing back-and-forth with tax advisors to get the narratives in a good shape. That is the part you were hoping to get done for you.

Claude's methodology

Claude's method is worth walking through – because it's a sensible workflow anyone trying to solve this could land on, and because every defect below is caused by decisions in this workflow.

If you point a capable general-purpose AI agent at your repos, you will get an answer that is often close to right on the work it finds.

1. A project can be in the claim and still be two-thirds empty

This is the core problem, and it's structural – not a prompt you can rewrite.

Claude natively works person-first. It counts each author's commits, decides which project the loudest ones "belong" to, names a handful of top people, and sets their percentage from their own commit volume. A project, to Claude, is a label it hangs on a busy author.

This explains two defects in Claude's model:

• It gives each person one project, or none. Real engineers' work scatters across projects, sometimes daily. Claude saw this for one engineer and couldn't express it: its own project write-up names that person under both projects, but the allocation sheet gives them one project with 35% — and the work for the second one evaporates.

• It is blind to the low-volume contributors. If you opened a handful of PRs inside a project that spans thousands – you're not sizable. Ranking by volume drops you. The engineer who wrote the design doc, reviewed forty PRs and shipped six commits is doing qualifying work and is invisible to a model.

Stats on the five largest projects Claude did find:

It just doesn't look like a gap, because the project is in the output with a confident number next to it.

A real claim works project-first, and this is the model that Taxnova follows to ensure the list is complete. To achieve this, you would have to process and classify not just the UK employees' contributions, but the whole mass of data.

2. Three qualifying projects were missed

Nothing in the output tells you the list is short. You wanted the projects you can claim; you got nine, and nine looks the same whether it's the whole year or two-thirds of it. There is no error bar on the number and no line anywhere saying "there may be more here I didn't reach".

A project that is never proposed is 100% lost, and the loss is shaped exactly like completeness.

The plugin platform is a good example precisely because it's hard: the work is spread thinly across many repositories, 8 people's work, and expressed mostly through review, issue design and integration commits. There is no single repo you can point at and see "this is a project". Name the plugin platform – and Claude will probably do a respectable job on it – the missing projects are mostly recoverable if you already know they're there.

Taxnova's process covers every piece of the year's work and groups it into the projects, so that it doesn't depend on anyone remembering each single project.

3. The narratives aren't defensible at audit time

The tax authority wants the technological uncertainty and how it was resolved; approaches tried, approaches discarded, and the reason for that. A commit title like "add jitter to scheduled writes" is a label on an outcome with the reasoning discarded. The trails of that often live in documents, comments and threads.

In this experiment, Claude never read a single GitHub issue or PR body, and that isn't a data-access excuse. The issue threads are fully public, sitting in the same repositories it already had open. It read the commit titles and stopped. As a result, it found zero uncertainty-related citations for five of its nine projects and mentioned it in its own notes.

We ingested the whole public record and used it: PR bodies and issue threads included.

That translated in better technical depth and quality of documentation: Taxnova's narrative for the alerting project cites the engineering team's own stated rationale for how they staggered a burst of writes across the available window, and pins it to a production-scale scenario – hundreds of thousands of concurrent alert instances – that a user had quantified in an issue thread. Those are the sentences that survive an audit.

The sheer volume of data is roughly 40x too big to read in one sitting even for Fable.
You can overcome this with a multi-step / sub-agent workflow and better prompting requiring evidence-based documentation. This also means you are no longer pointing Claude at your GitHub – you are building the thing.

Where we incorporated learnings from Claude Fable

Two cases where Claude was right and we learned something new – disclosed for transparency.

1. A qualifying project we excluded because we considered it done overseas.
One UK Engineer's most valuable 2025 work went into a large metrics-storage project (0.93 FTE) that our pipeline classed as non-significant for the UK – because 98% of the work was done elsewhere. Therefore, it was never assessed for qualification at all.

Claude didn't get allocation for that Engineer right either. But it did something better than being wrong: it refused to size the person at all, flagging that the commit count badly understated the work and should not be filed without an interview. That's a genuine advantage of how Claude reported it, and we're adopting it: by introducing per-person confidence tiering.

We have also adjusted our thresholds and correctly assessed the project as qualifying in the end, because even 2% of a large project matters.

2. The direct qualifying activity portion is where we rely on human review.
Our apportionment measures contribution on a project – not whether a person's contribution was direct resolution of technological uncertainty or qualifying indirect activity, which are treated differently.

It shows as two post-sales Technical Support Engineers carrying 12% and 16% in our sheet, which Claude excluded as non-R&D eligible roles. These roles are rarely R&D, but this isn't necessarily wrong – they could have still been involved in direct R&D work, we just don't have enough information at hand to confirm it.

This is why Taxnova's project decisions and assumptions are recorded with a written rationale and aren't final until a human signs each one off. To facilitate those checks, now we're adding an explicit flag-and-confirm step on role and activity type – and stating it here for transparency.

Summary

• Triaging: quickly determining if the claim is worth doing, particularly in a new market.

• Making a claim where the exercise costs more than it recovers: a small team and a handful of projects that you remember. Run it, improve the output with the context you have, and honestly, spend your money elsewhere. You don't need Taxnova for this.

• Cross-checking a claim you already have: independent convergence within 15% on 12/21 people is exactly the validation an advisor should want – and it's how we caught the case above.

Its output is delivered with full confidence, and no signal that twelve employees, three quarters of the claim's contribution links and at least one substantial workstream are absent.

The narratives it did write carry no such signal either – nothing marks the five projects it could not evidence, and those are exactly the pages a tax authority reaches for first.

• Your engineers work across multiple projects. Claude's person-first model will only assign one project per person, leaving the rest of their work unaccounted for. In our benchmark example, 75% of the claim's value was delivered by multi-functional teams, which the model can't represent.

• You want defensible and grounded technical narratives. The tax authorities want the technological uncertainty and how it was resolved. It's in the record, but never inside a single context window – which is the problem we already solve.

• You claim in more than one country. Everything above is a UK exercise. Running it again for the US means a second rulebook you have no way to check, and every defect above a second time. Taxnova is a one-stop shop, wherever your engineers are.

• Someone has to put their name to it. AI can't be your competent professional; at best it prepares work for one. We built explicit reviews and confirmations into the process, and track each one as evidence – so every project decision reaches filing with a written rationale behind it.

• You want to turn a once-a-year scramble into a systematic process. We monitor R&D projects continuously – not just once a year, proactively collecting data that wouldn't otherwise be captured in any engineering system.

It is the result of months of engineering time invested into building the methodology that finds every single project and person, managing disparate and messy data sources at scale, and incorporation of local tax domain expertise from professionals – which is something even the smartest model can't keep up with.