This page describes the detection engine that is running in production today, engine V3, released 5 September 2026. It is written from the deployed system rather than from marketing copy. Every number on it comes from the sealed confirmation run and the frozen configuration files, and the engine’s own history is at the bottom rather than mixed into the description. For the plain-language version, read how the detector analyzes text.
What the tool produces
For a submitted English text of at least 100 words, AI Detector Checker returns six things and nothing else:
- A 0-100 AI-writing signal score. It is an estimate of how strongly the passage matches the writing patterns the classifier learned, not a percentage of AI-written words and not the chance that AI wrote the text.
- A score stability range: how far that number moves when the source families behind the display mapping are resampled.
- One of three bands — Likely human-written, Uncertain or Likely AI-written.
- The length band the text fell into (100–149, 150–299, 300–599 or 600+ words).
- The measured false-flag rate for that length, from the sealed test.
- Patterns observed in this text: deterministic observations about the passage. They are descriptions, never causal explanations of the score.
Below 100 words it returns “More text is needed for a meaningful analysis”. There is no per-sentence output, no highlighting, no model identification and no percentage of the document. The result is evidence for review, never proof of authorship.
How the score is produced
One scoring path, four stages, all of them frozen before the sealed test.
- The document signal. Three classical text models — a word n-gram model, a character n-gram model and a set of stylometric features — each produce a calibrated score, and a small logistic model fuses them into one internal decision score. This is the V2 fusion core, unchanged since 4 September 2026 (model file
b7d17ee5…). No neural encoder is used: a programme of high-capacity encoder experiments was closed after each candidate failed its pre-registered safety bars on unseen human sources. No classifier was newly trained for V3. - Length-banded frozen thresholds. The internal score is compared with two cut points chosen for the text’s length band. Crossing the upper one gives Likely AI-written; between the two gives Uncertain; below the lower one gives Likely human-written.
- The display map. A frozen monotonic (isotonic) mapping turns the internal value into the 0-100 displayed score, separately per length band.
- The stability range. The 5th to 95th percentile over 1,000 bootstrap resamples of the source families behind that mapping, with a minimum half-width of 3 points.
The band is decided on the raw internal value alone. The displayed integer is a presentation of that value and never changes which band you get — which is why a score can sit one point below a band edge and still be reported in the band the raw comparison chose. Input is canonicalised before scoring (whitespace, quotes and dashes are normalised). Deliberately obfuscated text, for example text containing look-alike or invisible characters, is outside the validated scope.
The frozen thresholds, by length band
Both columns describe the same two cut points: the internal values the decision actually uses, and where those values land on the 0-100 scale you see. Shorter texts are held to a stricter bar because short human writing is easier to misread.
| Length band | Uncertain from (internal) | Likely AI-written from (internal) | Uncertain from (displayed) | Likely AI-written from (displayed) |
|---|---|---|---|---|
| 100–149 words | 0.3782 | 0.8030 | 53 | 93 |
| 150–299 words | 0.4053 | 0.9089 | 72 | 98 |
| 300–599 words | 0.3542 | 0.8841 | 68 | 97 |
| 600+ words | 0.6020 | 0.8740 | 80 | 97 |
The internal values are the L and thr entries of the frozen thresholds file; the displayed cut points are the corresponding entries of the frozen display map. Neither has moved since they were set, and neither is tuned on live traffic.
Why the setting is conservative
The thresholds were chosen to keep wrong AI signals on human writing rare across many kinds of source, at the cost of missing much AI-written text. The design point was 1 in 100 or better on texts of 150 words or more, and 2 in 100 on 100–149-word texts, with no single human source type above 3 in 100.
Two of those bars were not met. On human texts of 100 to 149 words the measured rate was about 2.4 in every 100 (14 of 586) against a bar of 2 in 100, and the hardest single human source type — issue-tracker text written by developers — came in at about 4.8 in every 100 (11 of 229) against a bar of 3 in 100. The publisher released the engine anyway, with both shortfalls published on every short-text result card and on the evidence page, rather than re-tuning against a test set that had already been opened. The full figures, with raw counts and Wilson intervals for every human source type, are on the evidence page.
Reading the result
| Band | Condition (displayed, by length band) | What it means | What it does not mean |
|---|---|---|---|
| Likely human-written | below 53 / 72 / 68 / 80 for 100–149 / 150–299 / 300–599 / 600+ words | No strong match to the measured patterns was found. | Not evidence a person wrote it. In the sealed test a large share of AI-written text also landed here. |
| Uncertain | from those figures up to 93 / 98 / 97 / 97 | The evidence is mixed. Edited, partly drafted, formal and second-language English land here often. | Not a weak accusation. Treat it as “no useful answer”. |
| Likely AI-written | 93 / 98 / 97 / 97 and above | The writing matches the measured AI patterns strongly at that length. | Not proof of AI use, and it names no model. It is never enough on its own for a decision about a person. |
The displayed conditions are the same two cut points as the table above, in the units the card shows. The band itself is always decided on the internal value.
Known limitations
- Short text is weak evidence. The 100-word floor refuses input that cannot carry a signal, and the 100–149-word band is still the least reliable one at about 2.4 wrong AI signals in every 100 human texts.
- Formal and formulaic human writing is the main false-positive risk. Technical writing such as software bug reports was the hardest source type in the sealed test at about 4.8 in every 100. Academic prose, legal and administrative text, templated documents and English written by a second-language writer are all more exposed.
- Assistant-style volunteer replies are reported separately. They are excluded from the published false-flag rate because they are not ordinary human writing; on the development surface about 12.9 in every 100 such texts (62 of 482) received a wrong AI signal. That figure is reported, not binding.
- Editing and paraphrasing degrade detection. Machine text that a person has rewritten, translated or heavily edited becomes progressively harder to identify, and can become genuinely undetectable.
- Recall is uneven across model families. About 55 in every 100 texts from the tested current models received a strong AI-writing signal (221 of 400), and about 42 in every 100 from one model lineage the engine had never seen (251 of 602). Neither is a general rate, and some families are almost never flagged.
- Non-English text is unsupported. The form does not block it, but the current detector has been validated on English only and its behaviour on other languages is unknown.
History
Dated history only. The paragraphs above describe the engine in production today; nothing in this section does.
- 27 August 2026 — previous-generation detector. An earlier engine, evaluated on 880 English texts from the public RAID training subset. Retired; its figures are not comparable to anything above and are archived on the evidence page’s history section.
- 4 September 2026 — V2, a three-band flagger with no displayed score. It used the same fusion core at a single pair of thresholds on the internal scale: 0.9485 and above was reported as a strong signal, 0.90 up to 0.9485 as inconclusive, below 0.90 as no strong signal, and no number was shown. Those two figures describe V2 only and have not applied to any result since 5 September 2026.
- 5 September 2026 — V3, the current engine. The same frozen fusion core with new frozen length-banded thresholds, the frozen 0-100 display map and a new product contract. Release
rel-v3-stage1-2026-09-05-308f3a03fb05.
Read next
- How the detector analyzes text — the same pipeline in plain language.
- Training and validation methodology — the corpus, the split discipline and what a change must prove before it ships.
- Evidence — the sealed test in full, with the model card and every human source type.
- Model update history — what changed in production, and when.