the arithmetic of a wrong flag
false-positive rates, base rates, and what they mean for the person on the wrong end of a flag. every number here is cited or committed, and the arithmetic is worked in the open. measurements, not advice.
a rate is not a probability
on gaige’s reference receipt, at a 5% false-positive operating point and a pool that is 99% human, 84.5% of flags land on humans. that number surprises most people who read “5% false-positive rate” as “a flag is 95% likely to be right”, and the gap between those two readings is this whole page.
a false-positive rate answers one narrow question: of the humans, how many get flagged. it says nothing about the question the flagged person actually faces, which runs the other way: of the flags, how many are humans. the second number depends on the base rate, meaning how much machine text is really in the pool, and when machine text is rare, even a small false-positive rate makes humans the majority of what gets flagged. the arithmetic is three lines long and almost nobody who quotes a detector’s headline number has done it.
what the record shows at published defaults
open-source detectors at their published default thresholds produced 47 to 100% false-positive rates in the RAID benchmark study (GLTR 100%, LLMDet 97.9%, Fast-DetectGPT 47.3% at threshold 0.25), against commercial tools shipped factory-calibrated at 1.7% or lower. the study’s own recommendation, quoted on the front page of this site, is to calibrate detectors on in-domain data before using them.
across a separate fifteen-variant evaluation, every detector fell to near-chance on at least one evaluation set, and 12 of 15 showed at least 15% false-positive rates on human text. rankings reorder when the dataset or metric changes. none of this says detectors are useless. it says their error rates are properties of a corpus and a threshold, and travel badly without them.
what it looks like inside institutions
a fourteen-detector academic study concluded the tools were “neither accurate nor reliable”. Vanderbilt disabled Turnitin’s AI flag “for the foreseeable future”, citing among other things a volume problem: at their published 75,000 submissions per year, a 1% false-positive rate prices out to roughly 750 wrong flags a year, and a 5% rate to 3,750. those two products are computed in gaige’s reference receipt using Vanderbilt’s published volume as the default worked example.
a newsroom test flagged 1 to 2% of 500 essays that were guaranteed human. a grammar-polishing pass flipped fully human text to a fully-AI classification. each of those cases is cited on the front page; together they are why “the tool said so” has stopped surviving appeals committees.
who gets flagged more
error rates are not spread evenly. the subgroup analysis cited on the front page found short human texts carry substantially higher false-positive rates, with score distributions that shift by length and style (KSmax 0.3081, p < 0.01). subgroup error rates are a measurement, not a footnote, and a single averaged number can hide a group whose experience is far worse.
aggregates hide inside corpora too. in gaige’s committed RAID run, one
aggregate number contained a 87.6% versus 39.7% true-positive split
between greedy and sampled decoding at the same threshold. and when a stratum is
too small to support a rate at all, the reference receipt withholds it
(rate_withheld: true) rather than printing noise. both behaviors
follow the same rule: report what the data supports, stratified, or say plainly
that it cannot.
one operating point, worked
the reference receipt’s 5% row reads: true-positive rate 91% (interval 85 to 96), false-positive rate 5%, both measured on the pinned hc3-mini pile. put that operating point in a pool that is 1% machine text and the receipt’s own base-rate table answers: precision 15.5%, meaning about five of every six flags land on a human. tighten to the 1% operating point and precision rises to 46.5%: better, and still a coin flip against the person flagged. at a 10% machine share the same 1% point reaches 90.5%.
none of those numbers is a property of the detector alone. they are properties of the detector, the threshold, and the pool together, which is why the thresholds page works the full table and why every gaige receipt carries its base-rate arithmetic instead of leaving it as an exercise for the accused.
what honesty looks like instead
the honest form of a detector deployment is short to state. operating points disclosed, with the corpus they were calibrated on. subgroup rates published with intervals, including the ones that look bad. refusals where the sample cannot carry the guarantee, like the reference receipt’s alpha=.005 refusal quoted on the corpus page. and receipts a flagged person could take to an appeal: the fingerprint of the instrument, the threshold family, and the exact command that reproduces the number.
six questions worth asking about any flag
each of these is answerable from a receipt, and unanswerable from a score alone.
1. what threshold produced this flag, and was it an empirical point or one with a finite-sample guarantee.
2. what corpus was the detector calibrated on, and how close is it to my kind of writing, in register and length.
3. what base rate was assumed, and what does the precision arithmetic say at that base rate.
4. what are the error rates for people who write like me, with intervals.
5. what instrument produced the score: model, quantization, versions, and has it changed since calibration.
6. what exact command would reproduce this number, and does it.
a flag that survives those six questions is evidence. a flag that cannot answer them is a score wearing a costume.
adjacent: thresholds, worked · corpus · receipts · why gaige · faq