Anveeksha compares what happened in GitHub with what Jira reports. On our own project it found 49 pieces of work merged in code while the plan still said they were not done. Half had waited more than two weeks, eight for over a month, one for 97 days, and every report built on that plan was wrong for as long as the gap stood. Here is how it spotted them and what it showed as evidence.
Two sources that should agree
Every delivery team keeps two records of the same work. The code records what has actually been built and merged. The plan records what the team says is done. Status reports, burn-downs and forecasts are built on the plan, so when the two disagree, the reports inherit the error.
We run Anveeksha on Anveeksha: the first workspace the product ingested was our own Jira, Confluence, GitHub and Slack. So the first place we checked whether code and plan agree was our own project.
How it spotted them
Anveeksha matches merged work in GitHub to its Jira ticket and compares the two. When a change has been merged but its ticket still shows as not done, it raises an unreported-progress finding.
The check is deterministic. The finding is computed from the activity itself against the project’s own normal; no language model decides whether something counts or how serious it is. The model only writes the explanation afterwards.
What it showed as evidence
Each finding links to the merged change and the ticket it belongs to, so anyone can check it in seconds. A typical explanation reads: “ANV-446 merged in git (2026-10-17) but the Jira plan still shows it as ‘todo’, unmoved for 11 days.”
That is the standard we hold the product to: the AI writes the explanation, and the evidence it was computed from is one click away.
What the numbers say
Across our own project, 49 pieces of work had been merged in code while the plan still said they were not done. Counted per ticket, the median gap was 18 days, so half had waited more than two weeks. Eight of the 49 had waited more than a month, and the longest gap was 97 days.
We report the median rather than the average on purpose. A handful of very long gaps pull the average up, and the median is the honest picture of a typical ticket.
Part of the gap was our own process
Not all of this was neglect. In our workflow a ticket moves to done when the work has been validated, not when the code merges, so some lag between merge and status is expected by design.
That is exactly why the finding matters. The plan was not telling anyone that validation was the step holding work back, and every report built on it treated finished code as unfinished work.
What this means for a client
If your reports are built on a plan, the first question is whether the plan agrees with the code. Anveeksha answers it continuously, from the tools your teams already use, and shows the evidence for every gap it finds.
Sources
- Anveeksha findings on our own project (internal), data to Oct 28, 2026.