Methodology

Someone on your side will ask how the numbers were made.

This page is for them. It covers which measurement means what, the figure we published that turned out to be wrong and why, what the scanner says when pointed at its own source, and which numbers here have a stale date. Every figure comes from a run against a real tree, with the date it was taken.

last refreshed upstream 2026-09-03 · the head-to-head benchmarks use a separate process
Start here

Two precision numbers exist, and only one of them is about your code.

One says a rule does not contradict its own documentation. The other says the rule is right about real source. If someone quotes a precision figure at you, the first question is which of these two they mean.

SELF-EXAMPLE CONSISTENCY · ENFORCED ON EVERY CHANGE
100%
3,902 of 3,902 patterns pass · 0 failing · re-run 2026-09-02

Every pattern that ships a good and a bad example has to fire on its own bad example and stay silent on its own good one. This runs on every change to a spec, so it is always current. It is also narrow: it proves a rule is internally consistent, not that it is accurate against your repository.

Two things moved here. The three patterns that used to fail their own bad example now pass. The population being checked also shrank, from 4,473 to 3,902, as detectors that could not fire were retired: a smaller library, checked completely, rather than a larger one checked loosely.

REAL-CORPUS ADJUDICATION · SLOW AND EXPENSIVE
9.0%
wrong-match on our own source · 43 of 478 judged · 2026-09-03

Findings judged against the source they point at, one at a time, rather than against a bundled example. This is the number that reflects what a rule does in the wild, and it is the one worth arguing about.

It is also the number we cannot refresh cheaply, and the one we have already had to correct in public. The next section is that correction.

A number we published and had to withdraw

We told you most of what we reported on our own code was wrong. That figure was an artefact.

This page carried 58.8% for months, as the share of findings on our own source that were factually wrong. It was measured with the judge running at its provider's default sampling temperature, unpinned. Asked the same question twice, that judge agreed with itself on 67.4% of findings. Pinned to a deterministic setting it agrees with itself on 96.4%. Roughly a third of those wrong verdicts were noise in the measurement, not a stable read of the finding.

WITHDRAWN · 2026-07-19
58.8%

Measured at an unpinned temperature, so not comparable with anything below. Left on the record rather than deleted, because a number that quietly disappears is worse than one that is explained.

RE-MEASURED · 2026-08-07
8.8%

38 wrong of 432 judged, pinned temperature, fixed seed, capped at 25 findings per detector so no noisy rule dominates. Confidence interval 6.5% to 11.8%, which does not exclude 10%.

RE-MEASURED · 2026-09-03 · DIFFERENT JUDGE
9.0%

43 wrong of 478 judged. A different judge model, because the account behind every other figure here had no balance that day. That is a judge identity change, so it sits alongside the August number rather than replacing it.

SEVERITYJUDGEDWRONGRATE
high54814.8%
medium18784.3%
low30516.7%
info2072210.6%

The overall figure clears 10% largely because the lowest-consequence tier is both the biggest bucket and the cleanest. So the bar was redefined in August to be severity-weighted, applied to medium and above, which is the part an engineer actually acts on. Under that definition our own source did not pass in August, at 10.3%, and the September re-run reads 6.6%. That is not declared a pass: the improvement could be the detector work that landed in between, or a softer judge, and one run with a different judge cannot tell those apart.

every other campaign in the repository was measured severity-blind and has not been re-audited under the current bar · those results are unaudited, not passing

Pointed at itself

What it says about its own source, including the part that scores badly.

Raw finding counts against the working tree as it actually stands, mid-refactor and dirty, measured 2026-09-02. The test tree scores worse than the source tree, which is the honest shape of a repository whose fixtures contain defect-shaped strings on purpose.

src/378 files analysed
HEALTH SCORE
95.59
FINDINGS
1,568
VS THE CITED BASELINE
−65.1%
No critical findings, 74 high, 786 medium, 33 low, 675 info. The refactor plan cited 4,490 findings on this tree as the baseline. Health moved from 92.84 partly on real reductions and partly on a scoring correction: style-tier detectors that were suppressed from the findings view had still been dragging the score down.
tests/1,027 files analysed
HEALTH SCORE
86.04
FINDINGS
9,726
VS THE CITED BASELINE
−76.2%
Nothing critical, high or medium: 1,227 low and 8,499 info, against a cited baseline of 40,911. A test tree scoring below the source tree is expected, since fixture code contains defect-shaped strings deliberately.
13.8 s
FULL SOURCE TREE · PARALLEL

Measured 2026-07-19 across 317 files. The prior measurement covered 184 files in 17.0 seconds, so the file count grew by 72% while the wall clock fell.

0.34 s
ONE FILE · NOTHING WARM

The worst realistic single-file case, with no cache to lean on.

0.26 s
ONE FILE · CACHED

A re-run of the same file, which is what an editor or a pre-commit hook actually pays for.

test suite 11,716 collected · 11,708 passing · 8 skipped, 2026-08-06 · no source file over 1,500 lines, checked by full sweep rather than sampling · library size is read from the facts file: 4,808 patterns · 146 spec files · 26 languages

Not current

What on this page has a stale date.

A measurement without a date is just a claim. These are the ones we know are behind, listed here so nobody discovers them by being wrong in a meeting.

2026-07-19

The speed figures. They were taken on a 317-file source tree, and that tree is now 378 files. They have not been re-measured since, so treat them as the last honest reading rather than today's.

2026-06-01

The ten-round real-corpus campaign that took the failing count from 1,854 to 1,362. Not re-run since, and it predates the judge-temperature correction above, so its absolute numbers carry the same inflation. A full re-run is a multi-round campaign, not a build step.

open

Every per-language campaign result in the repository was measured severity-blind, before the bar became severity-weighted. None has been re-audited under the current definition, so they are unaudited rather than passing, pending a fresh severity-split measurement per language.

open

The metrics document in the engine repository under-counts library size against the generated facts file: it was written before the library grew to 4,808 patterns across 146 specs and 26 languages. The facts file is generated and wins, and the site reads it, but the document needs regenerating upstream.

not re-profiled

The remaining-bottleneck list from the earlier speed work. The optimisation history behind it is accurate as history; the open items should be treated as stale until something is profiled again.

the corpus census (270 repositories, 259,598 files, 2,023,670 findings, 0 analysis failures, 130 of 146 surfaces firing) measures volume, not accuracy, and is dated 2026-08-14 · the rewriting guarantee and its twenty-of-twenty replay are measured separately