Messages to What Comes Next
This is revision 2 of this page, effective September 25, 2026. Its text is kept unchanged; any figure it draws from the corpus, such as a count or the current file's time, is live. The current revision is in force.
Method
Every entry carries a composition score and the figures it is drawn from. This page states exactly how they are computed, so that the score can be checked rather than believed, and so that anyone holding the corpus can recompute it.
The score is a summary of how a message was typed, not of what it says and not of who wrote it. It is published beside the entry and never used as a gate: a low score is shown, not enforced. Where the method does not apply to the declared input method, the entry says "not scored" and the figures are shown anyway.
What is captured
While a message is written, the page records an event stream: the time at which each piece of text was typed, composed by an input method, replaced by autocorrect, pasted, deleted, or moved past, with the number of characters involved. The stream carries timestamps and event types only, never which characters were typed. At publication the stream is sent to the server with the message, the server computes the figures below in memory, and the stream is discarded. It is never written to disk.
The figures are computed on the server rather than in the browser because a figure computed in the browser is self-reported: a script could post whatever numbers it liked.
The figures
| Figure | Definition |
|---|---|
| Composition time | Seconds from the first edit to the moment of publishing. |
| Deletions | Number of deletion events. A held backspace that removes ten characters is one event; the characters removed are recorded separately. |
| Longest pause | The longest gap, in seconds, between two consecutive edits. |
| Rhythm variation | The coefficient of variation (standard deviation divided by mean) of the intervals between consecutive keystroke-like events (typed or composed text), counting only intervals of two seconds or less. Left blank when there are fewer than twenty such intervals. |
| Pasted | Whether any text arrived without a history, and how many characters. What counts depends on the method version below. |
| Composed | Characters committed by an input method (Chinese, Japanese, Korean, Indic and other composed input). Version 1.1 and later. |
| Autocorrected | Characters replaced by autocorrect or a spelling fix. Version 1.1 and later. |
The corpus also records the number of characters typed, the number of characters in the message, the number of cursor moves, and the number of intervals behind the rhythm figure.
Version 1.1
In force since September 25, 2026. The components, thresholds, and weights are those of version 1.0, unchanged and still hand-set; what changed is what the page observes and what counts as a paste, because 1.0 was unfair to writers who do not type Latin script on a physical keyboard.
An input-method composition session, in which a writer types syllables or romanization and then chooses the text they meant, used to arrive as a churn of insertions and deletions and often as a "paste" of the final block. It now counts as one insertion of composed text, timed at the moment the writer commits it. Autocorrect and spelling fixes, which phones apply at every word boundary, used to count as pastes; they now count as typing. Character counts are Unicode code points on both sides, so an emoji or a character outside the Basic Multilingual Plane is one character everywhere, where 1.0 counted it as two in the browser and one on the server.
What counts as a paste under 1.1: any paste, drop, or yank; any block of twenty or more characters inserted by a route the browser did not name; and, for a writer who declared a keyboard or a touchscreen, any single typed insertion of twenty or more characters, which no keystroke produces. Composed and autocorrected text never counts as a paste, whatever its size. For a writer who declared dictation, or who declared nothing, only an explicit paste, drop, or yank counts, because dictation arrives in blocks that a keyboard rule would misread.
A writing page loaded before September 25, 2026 and still open in a browser sends the old record with the old paste rule; an entry published from one is recorded under 1.0, the method that measured it, not under 1.1.
Assistive and other input is not scored under 1.1. None of the thresholds below describes a switch, an eye tracker, a voice-control system, or an on-screen keyboard, and a number computed from the wrong thresholds is a false statement about a person. The figures are published; the score reads "not scored".
Version 1.1 is a repair, not a calibration. A calibration, run on a staging copy with consenting volunteers across the four input methods, plus a paste, a uniform script, and a forged-timing stream in the style of the attack paper below, is planned before the archive opens to the public, and its table, including the false-low rate for real people, will be published here as version 1.2 or as the reason 1.1 stands.
Version 1.0
In force from the first entry until September 25, 2026. A hand-set heuristic. The browser reported any block of twenty or more characters, any input-method composition, and any autocorrect replacement as pasted text, and counted characters in UTF-16 code units.
The score is a weighted mean of five components, each scaled from 0 to 1, computed within the writer's declared input method. Dictation and touchscreens do not look like a keyboard, so each method has its own thresholds; a method that was not declared uses the most lenient thresholds.
Each component uses a ramp: 0 at or below a low value, 1 at or above a high value, and a straight line between.
| Component | What it measures | Keyboard | Touchscreen | Dictation, assistive, or not stated |
|---|---|---|---|---|
| Rhythm | Rhythm variation, ramping up | 0.15 to 0.50 | 0.15 to 0.50 | Not used for dictation or assistive; used when measurable if not stated |
| Pace | Characters per second over the composition time, ramping down | 8 to 15 | 5 to 10 | 15 to 25 |
| Revision | Deletions per 100 characters, ramping up, with a floor of 0.3 | 0 to 2 | 0 to 2 | 0 to 1 |
| Pause | Longest pause in seconds, ramping up, with a floor of 0.2 | 0 to 5 | 0 to 5 | 0 to 5 |
| Origin | Share of the text that was typed rather than pasted | 0 to 1 | 0 to 1 | 0 to 1 |
Origin is the number of characters typed divided by the number typed plus the number pasted. If fewer than half of the message's characters arrived by any recorded route, origin is capped at the share that did.
| Weight | Keyboard | Touchscreen | Dictation and assistive | Not stated |
|---|---|---|---|---|
| Rhythm | 0.30 | 0.25 | 0 | 0.15 |
| Pace | 0.20 | 0.25 | 0.35 | 0.30 |
| Revision | 0.15 | 0.15 | 0.15 | 0.15 |
| Pause | 0.10 | 0.10 | 0.15 | 0.10 |
| Origin | 0.25 | 0.25 | 0.35 | 0.30 |
A component that cannot be computed (rhythm, with too few intervals) is left out and the remaining weights are renormalized. The result is multiplied by 100 and rounded to the nearest whole number.
The code is mwcn/scoring.py in the public repository.
Reproducing a score
Every published score can be recomputed from the published figures with the recorded method version: python -m mwcn.cli rescore corpus.jsonl does it for the whole file and reports any mismatch. The repository also carries a fixture set, tests/fixtures/streams.jsonl: synthetic event streams (a person at a keyboard, a person on a phone, an input-method session, a dictation, a paste, a uniform script, a forged-timing stream) with the figures and the score each version gives them. The test suite fails if the code stops reproducing them.
Versioning
Each entry is scored once, at submission, with the version of the method then in force, and that version is recorded beside the score. Scores are never recomputed, because that would edit a published entry. When the method changes, the new version is described on this page alongside the old, and the raw figures let anyone rescore the whole corpus with any version they like.
What the score does not show
Keystroke dynamics has decades of use in continuous authentication and writing research, and current use in bot detection. Published attacks show that timing can be forged by a determined actor, and the signal confirms only that a person operated the keyboard, not that the person originated the text. Both limits are accepted. The goal is to make bulk automation tedious, not to police whether someone consulted a model before typing. A person who drafted with help and then typed it in is still a person choosing to say it.
The archive keeps no signal linking one set to another, by design. Whether several sets were written by one person, or by many people in one room, cannot be read from any field; it can only be inferred from timing, text, figures, and the daily counts in the log.
The papers that informed the design:
- A Hybrid CAPTCHA Combining Generative AI with Keystroke Dynamics for Enhanced Bot Detection, arXiv 2510.02374
- Detecting LLM-Assisted Academic Dishonesty using Keystroke Dynamics, arXiv 2511.12468
- On the Insecurity of Keystroke-Based AI Authorship Detection, arXiv 2601.17280, which describes the attack the design accepts
- Chatbots Are Undermining Crowdsourced Research in the Behavioral Sciences, Asher et al., 2026
- BeCAPTCHA-Type, arXiv 2207.13394
Revision 2, effective September 25, 2026.