The one thing this tool cannot afford to do is accuse you wrongly. So we measure it — on real files, with a method you can rerun — instead of asserting it.
Take 559 rules files people actually published, and 10 real coding sessions. Run every file against every session — 5,590 reports — and count how many carry even one FAIL. That is 0.8%.
It is a ceiling, not an error rate, and deliberately so: those rules belong to other people's projects and the sessions don't, so almost every FAIL there is spurious by construction. The real false-accusation rate on your own rules and your own sessions is lower. We report the ceiling because it is the number we can measure honestly and that only moves when the tool's readiness to accuse changes — it went from about one report in six, early on, to 0.8% today.
Precision alone can be gamed by never accusing anything. So there is a second set: hand-labelled sessions that genuinely break a rule (a push to main, an edit to .env, a console.log written into a file, a "tests pass" claim contradicted by a failing run, a forbidden import) — alongside near-misses that must not fire (a push to a feature branch, editing .env.example, a command that only mentions git push). It is a sanity check across the checkers, not a real-world detection rate. Every violation is caught; every near-miss stays quiet.
The strongest version of this claim is the one you check. The self-test ships in the CLI and makes zero network calls — watch it with lsof or Little Snitch:
npx rulereceipt@latest selftest
The full precision and detection measurements are ordinary scripts in the open repository — clone it and run them against your own corpus and sessions.
--llm) is labelled as an opinion and never counted as a verdict. When the evidence doesn't settle a rule, the answer is "couldn't tell," never a guess.