How to prove a student wrote it
Short answer: you cannot prove it from the finished text. You can only prove things about how the text was produced, and only if something was recording while it was produced. Everything below is about the difference.
What is actually evidence
Four kinds of observation hold up in a conversation with a student, a parent, or an assistant principal, because none of them is an opinion about the writing:
- Typing cadence. Real drafting is uneven. A sentence goes in, a word comes back out, there is a nine-second pause before the next clause. A timestamp per keystroke shows that shape directly. Text that arrives at a flat 6 characters per second with almost no deletions was produced some other way — copied from a second screen, or dictated, or typed by someone who already had the finished sentence in front of them.
- Paste attempts. "The student tried to paste 1,480 characters at 10:14, and it was blocked" is a fact with a time on it. It is not the same as proving what was in the clipboard, and you should not pretend it is. But it moves the conversation from "this doesn't sound like you" to a specific event.
- Tab-aways. A window losing focus is observable from inside a web page. Fourteen focus losses in a thirty-minute period is not proof of anything on its own; combined with a burst of text right after each one, it is a pattern you can describe out loud.
- Insert size. The most useful and least known one. Human typing arrives one to three characters at a time, and so do autocorrect and phone predictive text. A block of 200 characters landing in a single edit did not come from fingers. Splitting the character count into "typed" and "inserted" separates ordinary writing from text that appeared at once, with no judgment about the words themselves.
What AI detectors do instead
A detector reads the finished text and scores how predictable it is to a language model. It never saw the writing happen. You get a percentage, the student says "I wrote it", and you are holding a probability against a denial. Detectors also misfire on second-language writers and on students who write in short plain sentences. The tell is that a detector cannot answer the question that matters: when did this text come into existence, and how.
A three-step protocol teachers described
Not my idea — the pattern that kept coming up in an r/Teachers thread in April 2026 asking for a paste-blocked, no-login place to write, and in the "AI proof assignments" threads since:
- Move the reading home, move the writing into the room. Annotation, notes, and sources are homework. The draft is written in class, in one sitting, where you can see the room.
- Reveal the prompt in class. Not the unit, not the topic — the actual question, that day. A prompt a student has had for a week is a prompt a chatbot has had for a week.
- Record the session, and tell them you are recording it. Say plainly what is logged: paste attempts, tab switches, and the timing of typing. Several teachers reported that saying this out loud, once, did more than any detector, because the students who were going to paste simply stopped.
The third step is the one that used to need a tool nobody could name.
Where WrittenLive fits
WrittenLive is the recording part, and nothing else. You type a title and get two links: one for students, one private dashboard for you. Students open the link, type a name, and write. No accounts, on either side. Paste, drop and drag-in are blocked and counted. Every insert, delete, cursor jump, focus change and idle gap is timestamped, so afterwards you get a scrubbable keystroke replay, a class table, and a one-page printable report per student.
There is no model anywhere in it guessing whether text sounds like AI. Every number on the report is something the editor observed. That is a deliberate limit, not a missing feature: an observation survives being argued with, and a guess does not.
The limits, said plainly
A student can open the assignment on a laptop and retype from a phone; the record will say "typed", because it was. The tool cannot see other screens, other devices, or who is sitting at the keyboard. Bursts and idle gaps are patterns, not intent — a long gap can be a chatbot in another tab, or a kid staring out the window, and the replay cannot tell you which. Anything an extension or an accessibility tool inserts shows up as a large insertion, which is worth noticing but is not the same as catching someone. Treat the report as the thing you put on the table at the start of a conversation, not the end of one.
Try it in one field
Or look at a real dashboard first: the public demo has one clean sample session and one with paste attempts, a large insertion, and machine-speed bursts.
Read next
- Running a paste-proof writing assignment — the mechanics on Chromebooks and phones, with no student logins.
- The AI-proof in-class essay — the reading-at-home, writing-in-class split, and an honest FAQ.
- Keystroke replay for student essays — what a replay is, the exact fields on the report, and what is stored.
- An AI detector flagged my student's essay — why detectors misfire and what actually settles it.
- Google Docs version history vs a process replay — what version history shows and what it misses.
- In-class writing assignments that can't be pasted — six designs that work in one period.
- Process-based writing assessment — a rubric for drafting evidence, and how to show it to parents.