What track changes does not capture about AI edits
The old complaint about AI writing tools was that you could not see what they changed. That complaint has largely been answered: Word tracks Copilot's edits, Google Docs hands you Gemini's changes as suggestions to accept or reject, Grammarly works a card at a time. The diff is no longer the missing piece. What is missing is everything a diff was never able to hold, and a record that quietly expires before you need it.
Everyone shows the diff now
Read off each vendor's own documentation on 11 August 2026. The interesting column is the second one.
| Tool | What it shows you | Where it stops |
|---|---|---|
| Word with Copilot | "Edit with Copilot will respect Track Changes, and if Track Changes is enabled then Edit with Copilot changes will be tracked in the document." | Tracking is a document setting. Copilot "cannot turn on/off or accept/reject tracked changes", so in a file where nobody enabled it there is no record. A comment anchored to a paragraph Copilot edits may be deleted. |
| Google Docs with Gemini | Suggested edits in the document. You click Show suggestion, then Accept suggestion or Reject suggestion, one at a time or all at once. | Suggestions work only within the tab you are in, and Google's own note is that Gemini "may suggest inaccurate or inappropriate information". |
| Grammarly | A card per suggestion that you accept or dismiss, and alternatives to accept or dismiss on a rewritten passage. | A paragraph rewrite is one decision over a block of prose, not a decision per change inside it. |
| A chatbot reply | Nothing. You get finished text and compare it against your own copy yourself. | There is no before, so there is no scope. You cannot see whether it touched one clause or rebuilt the argument. |
So the market solved the visibility problem in about two years, and the honest reading of that is that "we show you a diff" is now table stakes rather than a reason to pick anything. The question worth asking has moved: given that you can see the change, what can you actually conclude from looking at it?
A tracked change records the text, not the evidence
Open the file format and a tracked change is a small thing: a span of text, marked inserted or deleted, with an author name and a timestamp. That is the whole payload. It is a faithful record of what the document became, and it is silent on every question you actually have.
It carries no evidence. A tracked insertion reading "rooftop solar cut peak grid demand by 14% (Marsh, 2021)" is stored in exactly the same way whether Marsh 2021 exists, says something else, or was never a paper at all. The markup tells you the sentence is new. Nothing in it, and nothing in the review pane, distinguishes a number the tool read from a number the tool produced. This is the failure mode that costs people marks, and it survives a careful review, because reading a diff feels like verification. You did read the words. You just had no way to check them from where you were standing.
It carries no provenance. Microsoft's page tells you Copilot's edits are tracked when tracking is on. It does not say whose name the revision carries. That is a small gap with a large consequence: the one thing you would want a provenance record to answer, human or machine, is the thing the format was never designed to hold. Track changes was built so two people could see each other's work, and a model is not a second person with an account.
It carries no reason. A revision shows a hedge removed and gives you nothing about why. Was the claim overstated, or was the hedge the only honest part of the sentence? You are left inferring intent from a text delta, which is the same work as re-reading the paragraph cold.
Put those together and the shape of the problem is clear. A diff is necessary and it is not sufficient. It narrows what you have to read from a chapter to a sentence, which is real and valuable. It cannot tell you whether that sentence is true, and no amount of better highlighting will make it able to.
Regenerating is not reviewing
The most common way people handle an AI edit they dislike is to ask for it again. That feels like control and it is the opposite of review, for three reasons worth separating.
Regenerating destroys the comparison. Review is a decision about a specific change: this stays, that goes. Re-rolling replaces the thing you were about to judge with a different thing you have not judged yet, and the version you were unhappy with is gone, so you cannot even say whether the new one is better.
The second answer is not a correction of the first. The model was not told what was wrong. It was told to try again, which in practice samples a different route through the same material, with the same gaps, and none of the specific defect you noticed carried across. If the problem was an unsupported claim, re-rolling has roughly the chance of fixing it that shuffling has of dealing you a different card you did not ask for either.
And re-rolling terminates on the wrong signal. You stop when the output stops annoying you, which is a judgement about fluency, not accuracy. The version of this that goes furthest wrong is re-running text against a score until the score moves, which we looked at in do AI humanizers actually work. The mechanism is identical: repeated sampling until a surface number changes, with nothing underneath it changing at all.
The practical rule is small. When an edit is wrong, say what is wrong with it rather than asking for another one. That turns a re-roll into an instruction, and an instruction is something you can check the result of.
The record expires, and it expires quietly
The second half of "you cannot review what you cannot see" is time. A drafting record is worth something on the day somebody questions your work, which is usually weeks after you wrote it, and every system here is quietly compressing that record while you are not looking.
Google is explicit about it. On its version history page, Google states that "the revisions for your file may occasionally be merged", and that "you can create a named version to track your version history and make sure your versions aren't merged", with a ceiling of 40 named versions per document. Read that carefully: the fine-grained history, the part that would show a chapter growing paragraph by paragraph over four evenings, is exactly the part Google is free to compress. The versions that survive intact are the ones you named while you were working, and nobody names versions while they are working.
Uploaded files are stricter, and it is a separate rule that people miss because it lives on a different page. Google says a version of a file in Drive "might be permanently deleted after 30 days or if there are 100 newer versions" unless you mark it Keep forever, and it says outright that version history for Docs, Sheets and Slides is different from history for other files stored in Drive. So the .docx you dragged into Drive and kept editing does not have the history you think it has.
Word has a different exposure. Tracking is a setting anyone with the file can switch off, unless it is locked: Microsoft documents Review, then Track Changes, then Lock Tracking, with a password. A record you can turn off at will is a record that proves less than it looks like it does, because the interesting question at a meeting is not what the marks show, it is what happened during the stretch with no marks.
None of this matters until it does, and then it matters a great deal. If you are already in that situation, the first hour is about preserving what still exists, which we set out in accused of using AI on an essay, and the reason a drafting record is worth more than any score is that the score is not evidence about you, which is the argument in will AI detectors flag my writing. What you can do today costs one click: name a version at the end of every working session, in whatever tool you use. A named version is the only part of the history you are promised.
What our own model costs you
We built CiteOwl around this problem, so here is our side of it with the costs stated rather than buried.
Every edit the agent makes is written as a pending change holding the old text and the new, grouped by the run that produced it, and rejecting one actively reverts it rather than leaving you to undo by hand. The part that answers section two is separate from the diff: a cited claim carries the quote from the source it came from, so the check that a tracked insertion cannot support happens in the same place as the review. That is the whole design argument, and it is the only claim on this page we are making for ourselves.
Four things it costs you.
Accepting is a no-op. The edit is already in your document; accepting only clears the marker. We chose that so a long run does not stall waiting for you, and the price is that inattention defaults to yes. A change you scroll past is a change you kept.
Your own typing is not reviewable. Manual edits apply directly, with no pending change. Recovery is undo, plus a pre-edit snapshot taken at most once every ten minutes. Only the agent proposes; you commit.
Our history expires too, and here is the number. We keep 50 automatic revisions per document and prune the oldest beyond that. Checkpoints you star yourself are never pruned. Automatic snapshots also drop image bytes and stored source full text so the table cannot grow without bound, which makes a starred checkpoint the only lossless one. That is the same trade Google makes, with a smaller number and a page saying so.
The record lives in CiteOwl, not in the file you hand in. Exports carry the finished text. They do not carry the change history, so if you need a drafting record for a meeting, star checkpoints as you go and keep your own copies. No tool's internal history is a document you can hand somebody.
And an opinion, offered against our own interest. Given a choice between a tool that surfaces every edit and one that surfaces fewer and argues for each, we would take the second, and our own product sits on the wrong side of that line on a long run. A review surface only works while attention lasts, and attention is the scarce thing here, not screen space. Fifty diffs is not fifty decisions. It is one decision to trust the tool, made fifty times, and the unverified claim goes in somewhere around the fortieth, when you have learned that the changes are usually fine. Any tool that shows you more changes than you will genuinely read is selling the appearance of review, and we would rather say that out loud than pretend a longer list of diffs is a stronger guarantee.