How often each rule is wrong

A finding is a false positive when the flagged construct is correct as written, when the surrounding code establishes its safety, or when the context makes the flagged behavior the intended one. Confirming that the rule's pattern is present is a separate, mechanical check: it proves the span is not corrupted, never that the site is a defect. That check ran over 575 findings and confirmed 575 of them, and it measures nothing about precision.

A rate is the rate of the reviewed sample, never of the unreviewed population. Sites are drawn by a fixed stride over the findings ordered by repository, path and line, so the sample follows the distribution a user actually receives. Most rules are sampled at five sites, which resolves steps of twenty points: five sites separate a rule with no observed false positive from one that has some, and cannot place a rule against the 5% threshold. Four rules were deepened past that default. The interval on each row is what says how much the number is worth.

The rate ranks, it never penalizes. What a rule costs the score is what it reported; the rate on this page only decides what the report puts at the top of the list to repair, discounted by how often repairing it would be wasted work. A rule with no measurement is ranked from the middle of a Beta(1,1) prior rather than treated as free.

Mature, widely used Rust libraries and tools, pinned by tag or commit, scanned with the full catalog. This is code nobody wants disturbed, so a finding here is a demand on a maintainer who did not ask for it: 10 rules were wrong at every sampled site, and 5 were wrong at none.

• anyhow 1.0.104
• async-channel v2.5.0
• bytes v1.12.1
• fd v10.4.2
• hexyl v0.16.0
• log 0.4.33
• ripgrep 15.2.0
• serde_json v1.0.145
• smol v2.0.2
• thiserror 2.0.19

Rules the ten repositories never triggered are not listed: 36 of the 62 catalogued rules never fired here, which says the corpus gave them no chance rather than that they do not work.

Repositories where at least half the commits reachable from the pinned revision carry an agent authorship trailer. The criterion reads the git history alone, never code style, README claims or popularity. This population is scanned with all 37 Clippy rules switched off, because its build scripts and procedural macros are untrusted and Clippy is the one pass that compiles anything, so only the native detectors are measured here.

• claudes-c-compiler 6f1b99a
• ostendo 0284e33
• artifexprocal 2be33f7
• mdr 26e9250
• ralph-os cd6dac9
• vibesql 4d9b33d
• syncvibe ff10443
• coda cf32fbe

Structural findings are denser on the agent population than on the healthy one: 5.36 per thousand production lines against 3.55, over 988,872 and 122,044 lines. A denser population is not by itself a noisier one, which is the question the next section asks.

Four structural rules are measured on both populations, so their rates can be differenced. The interval is a Newcombe hybrid score interval at 95%, and an interval that crosses zero means the two rates are indistinguishable at this sample size rather than equal.

All 4 comparisons sit under the coverage the method nominally wants, forty sites per arm, and one of them separates anyway. The limit is the corpus rather than the sampling: the healthy scope of one of these rules holds every production family the ten repositories have, so deepening it means pinning more repositories, not reviewing more of these.

Sites added under the current protocol were judged twice, by passes blind to each other, and a disagreement is excluded from the sample and left to a human rather than settled by the judge that produced it. Cohen's kappa is undefined when neither pass varies, which is why Gwet's AC1 is published beside it. A coefficient of 1 is total agreement, 0 is what chance alone would produce, and a negative one is worse than chance: a row that reads 0 of 3 is a rule whose two passes never once agreed, and all three of those pairs are in the escalation queue rather than in any rate above.

• A rate at five reviewed sites cannot be placed against the 5% threshold. Read the interval, not the point.
• 36 catalogued rules never fired on this corpus and carry no rate at all.
• Verdicts recorded before 2026-08-21 carry no author on record and are published as they were measured rather than reattributed after the fact. A rate mixing provenances is worth its weakest one.
• Both populations are small, and neither is a random sample of Rust. They are ten repositories chosen for the shapes they exercise and eight chosen by a mechanical authorship criterion.
• Nothing here measures what the tool misses. Precision is not recall, and the record has no annotated ground truth to compute recall against.

The measurement replays from a local clone cache and never reaches the network. Both directories must sit outside the repository, and naming one without the other fails rather than half configuring a run.

RUST_DOCTOR_CORPUS_DIR=<clone cache> \
RUST_DOCTOR_CORPUS_ARTIFACTS=<scratch> \
cargo test --test corpus_precision

Every published site is anchored to a run that located it. The position proof is a blake3 digest over the identity of every reviewed site and every adjudicated pair, recomputed offline on every cargo test: a site typed in by hand, at a line no scan ever reported, fails the suite.

Position proof

2b3c827d5f910e96

Anchored sites

671

Toolchain

1.97.1

Record digest

bdc2329270dacf84

The record itself, with the verdict and the written justification behind every one of the 452 sites, is in the repository. This page publishes the rates; the record publishes the sites they were computed from.