Review the diff for altered facts, not just improved prose

Freeze the two endpoints

A revision review fails when nobody can say which version is the baseline. Save or name the approved source version and the candidate revision before reviewing. Record the filenames, version labels, date, and reason for the change. Do not compare a moving collaborative document with another moving document.

Use the platform’s comparison feature when possible. Microsoft’s Word blackline guidance describes comparing an original and revised file in a third document while leaving the source documents unchanged. Google’s version-history documentation lets editors inspect who changed a file, copy an earlier version, and name versions so important checkpoints are not folded into an indistinct timeline. The interface exposes changes; it does not judge whether they are true.

Review high-risk tokens before style

Start with changes most likely to alter meaning. Search the diff for digits, currency signs, percentages, dates, units, names, product labels, quoted text, negations, and modal verbs such as may, must, can, and will. Check additions and deletions. Removing “not,” “approximately,” or “in this sample” can reverse or inflate a claim without changing the paragraph’s general shape.

Open the source for every high-risk change. A citation surviving beside the sentence is not enough; the sentence may now say something broader than the source. This is where the evidence table earns its keep: the reviewer can compare the revised claim with the stored passage and scope.

Separate editorial acceptance from factual acceptance

Mark each substantive change with one of four outcomes: accept, reject, needs source, or needs owner decision. A beautiful rewrite can remain blocked on evidence. Conversely, a clumsy but accurate sentence can be accepted factually and queued for a second style pass. Keeping those judgments separate reduces the temptation to wave through a risky change because the new version reads better.

Review tables, captions, footnotes, alt text, metadata, and link labels. Many comparison views emphasize body text while a caption or table cell carries the actual figure. If a conversion process changed the file format, also compare page count, heading order, list numbering, and whether comments or tracked changes remain visible.

Read the candidate once without markup

After resolving the diff, read the candidate cleanly from start to finish. Diffs are good at local changes and poor at detecting a broken overall argument. Confirm that references such as “this,” “the earlier result,” and “the table below” still point to the right thing. Check that a moved conclusion retains its limitations.

A hypothetical example: a revision changes “the feature can be enabled by an administrator” to “the feature is enabled by default.” The words differ only slightly, but the operational meaning is opposite. The reviewer marks “needs source,” checks current documentation, and either restores the qualified wording or updates the evidence record. This is illustrative, not a reported product test.

1. Name and preserve the baseline and candidate versions.
2. Inspect high-risk tokens and deletions first.
3. Reopen sources for every factual change.
4. Record factual and editorial decisions separately.
5. Read the accepted candidate cleanly after the diff pass.

The archive’s provenance record makes a related point: recording a process does not prove a claim is true. Version history proves that text changed; review establishes whether the change is acceptable.