Google Docs Has Been Recording How You Wrote This the Whole Time

Google Docs keeps a private log behind every document, the same data that drives its own Version History panel. Almost nobody opens that panel, and almost nobody realizes the log underneath it can be read directly, not just replayed through Google's own slider.

That log records something an AI detector never sees. A detector scores finished prose. The log records the actual act of writing it, every keystroke, every paste, every pause, each one timestamped to the millisecond as it happened.

What the log actually contains

Each entry in Docs' internal changelog carries an operation (an insert, a deletion, a batch of both), a timestamp, and whose account made it. Inserts and deletions are logged individually rather than per revision, which means the gap between one keystroke and the next is recoverable, not just the fact that an edit happened at some point in a session.

That distinction matters more than it sounds like it should. A real capture of one hand-typed document showed genuine typing arriving in bursts of one to five characters at a time, spaced a few hundred milliseconds apart. A block of text arriving as a single 400-character insert is a different shape entirely, since nobody's fingers produce that in one motion. A paste does. Twenty characters is the threshold before an insert counts as a paste rather than fast typing, set four times higher than what real keystrokes ever produced in that capture, on purpose, since a missed paste costs far less than falsely telling a writer they pasted something they typed.

The same capture drew a second, sharper line. Real pauses inside a writing session ran a few hundred milliseconds to maybe two minutes of thinking. Real breaks between sessions ran twenty-six minutes, sixteen hours, two days. Nothing sat in between. A five-minute gap is the boundary between "still writing" and "came back later," and it holds up because the data doesn't blur at that edge, it jumps.

What you can actually build from that

Read enough of these entries and a few things fall out for free. How much of the document was typed versus pasted in. How many separate sittings it took, and how long each one ran. Every paste event, with the pasted text attached, so a person can read what was pasted rather than trust a raw count. And because every op carries its own timestamp, the whole thing can be played back. Watch a document assemble itself in the order it actually happened, sped up so a week of writing plays in a few minutes.

Our Chrome extension does exactly this for anyone editing a Google Doc. It turns the log into a plain writing-process summary (typed share, session count, paste history, a rhythm reading) and, separately, into a scrubbable playback of the whole draft being written, which we call Writer Replay. Neither one touches the words themselves, they both just describe how the document came to exist.

The trap that almost broke this

Here's the part worth knowing before you trust any of it. Google periodically compacts old history into a single synthetic entry that carries the entire document as one giant insert, wiping out everything before it. On the actual capture that revealed this, a naive reading of the log would have flagged a genuinely hand-written document as a single massive paste, because structurally, that's exactly what a compaction entry looks like.

The fix isn't a size cutoff. A real paste can be just as large as a compacted document, so size alone can't tell them apart. What separates a compaction from a real paste is structural. A compaction entry carries no session id, or carries an origin timestamp far older than the entry's own clock, artifacts a genuine paste never has. Get that distinction wrong and the tool accuses the wrong thing, which is precisely why it's checked for on every read rather than assumed away.

That trap is also why this can't do something it would be convenient to promise. The log only reaches back as far as the surviving record goes, and Google's own compaction means that's frequently not the document's actual creation, so a document with no visible pastes wasn't proven to be hand-typed, and a short observation window wasn't proven to cover the document's whole life either. Both of those are just silence, and silence is not evidence either way.

What this is not, on purpose

None of this scores whether AI wrote anything, and it's built that way deliberately. A high score on the writing-process side says the record looks like drafting in place, typed steadily, revised, worked across more than one sitting. It does not say a person wrote the sentences, because someone can draft in place and still lean on AI for individual lines, and someone can paste in a block of entirely their own writing pulled from an earlier draft or a notes doc. Pasting is not evidence of AI use. Typing every character by hand is not evidence that none of it came from a model.

That's also why this number is never folded into an AI-detection score, on either side of the math. Averaging the two would let a clean writing-process reading quietly launder a document that a real detection scan flagged, or the reverse, and both directions would misrepresent what either signal actually measured. A detection score reads the prose. A process reading reads the record of how it was assembled. They're answering different questions, and stacking them into one number hides that instead of respecting it.

What this gives you instead is something a percentage never can. A paste you can actually read, a timeline you can actually watch, sessions you can point to and say when they happened. Our full report format walks through comparing versions and seeing exactly what changed between them, which is the same instinct in a different, complementary form. Detection tells you what a scan noticed in the words. A writing-process reading tells you what the record shows about how those words got there. Keep both. Don't average them into one.