The rewrite diff viewer: what humanising a draft actually changes

Humanising tools edit meaning as well as tone

A rewrite is instructed to make text sound human, and the fastest way to do that is to remove the qualifiers. Hedges read as machine-like, so out they go: up to, approximately, in most cases, subject to. Every one of those deletions makes the sentence more confident and, sometimes, less true.

Read the new version on its own and it looks better. That is the whole problem with judging a rewrite by reading it: fluency is exactly what the tool optimises for, so the improvement is guaranteed and tells you nothing. Read the two versions side by side and you can see the sentence that lost its qualifier, which is a different and more useful observation.

The same comparison catches the opposite failure, which is more common than people expect: a rewrite that changes nothing structurally. A wall of word-level substitutions with no sentence split, no paragraph reordered and no idea added means the text has been reworded rather than improved, and the original shape is still under the new paint.

A diff makes both failures cheap to spot, because it shows the operations rather than the result. Deletions of numbers, dates and caveats are the ones that need a decision from a person who understands the subject.

What to check, in priority order

Claims first. Every deleted figure, date, percentage and qualifier is a decision you are now making by inheritance. If the rewrite removed an up to, the sentence has become a promise. If it rounded 18.4 to 18, the precision of the source is gone. Confirm each one deliberately rather than accepting the diff because it reads smoothly.

Meaning second. Words like may, most, typically and generally carry the weight of an entire claim, and rewrites drop them because they are the least human-sounding part of a sentence. A paragraph that went from may cause to causes has made a stronger assertion than anything in its source material.

Voice third. If the rewrite introduced phrasing you would not use in conversation, the costume has changed rather than been removed, and the reader will notice a different kind of unnaturalness. Compare the new text against something you wrote unaided; the gap is the honest measure.

Structure last, and only to ask whether anything actually moved. A diff where every line is a substitution and no line is split, merged or reordered is evidence that the rewrite operated on vocabulary alone.

• Deleted number, date or unit — did the source support the new value?
• Deleted qualifier — has the sentence become a stronger claim?
• New absolute — always, never, guaranteed: who is accountable for that?
• No structural change at all — was this an edit or a restyling?

Side-by-side or inline, and when each helps

Side-by-side puts two complete sentences in front of you and is the right view for judging whether a sentence still means what it meant. You read left, then right, and the difference in meaning is often something no highlight would flag, because every individual word is defensible.

Inline is the right view for judging how a sentence was edited. Insertions and deletions appear in the order they occur inside the line, so you can see that a clause was moved rather than cut, or that a comma was added that changes the reading of a list.

In practice: inline while you are accepting or rejecting changes, side-by-side when you are worried about meaning. Both views show the same operations, so switching costs nothing but a click, and the second look regularly overturns the first.

One pair at a time is a constraint worth respecting. For a chain of edits — draft, humanised, editor pass, final — compare the original against the final version to see the net effect, then the final against its immediate predecessor if you need to know who introduced something.

Keeping the record

For client work the comparison is the deliverable's audit trail. It answers the question a client asks three months later: what did you actually change, and why. A saved diff turns an argument about quality into a review of specific decisions, which is a much shorter conversation.

Practically that means not overwriting the original. Keep the source file, the rewritten version and the final text as three artefacts, and keep the diff alongside them. Storage is cheap; reconstructing what a document looked like before an edit is not.

There is a compliance angle too. When a piece of published work is challenged, the ability to show that a human pass removed a guarantee, added a source or restored a qualifier is the difference between a process and an assertion. The diff is evidence that a person made those calls.

And it disciplines the writer. Knowing that the comparison is being kept changes how you accept a rewrite: you stop approving a wall of changes and start approving specific ones, because each one will be visible to someone else later.

Drift in tables, lists and headings

A diff treats a paragraph as a line, so a paragraph that was reflowed at a different width reads as a wholesale replacement even when almost every word survived. That is noise, and it is the main reason a diff looks catastrophic on a heavily edited draft: not because the changes are large but because the line breaks moved.

Tables are worse. A reordered row shows as multiple edits, a moved column shows as every cell changing, and a unit changed in the header cell can leave the body numbers untouched and meaningless. Compare a table row by row rather than trusting the highlighted block, and check the header cells explicitly because they carry the units.

Headings deserve their own pass. Renaming a heading is a small editorial improvement and a functional break: anchors, internal links, table-of-contents entries and cross-references elsewhere in the document all point at the old text. If the document is published on a site, a renamed heading is a broken link waiting for a reader.

Lists lose numbering in most diffs. If the original had an ordered list whose steps were merged, the change appears as text edits and the loss of sequence appears as nothing at all. Count the items in both versions before you accept the rewrite.

Showing a client what actually changed

A four-hundred-line diff is not a report, it is an exhibit. The useful version is three or four annotated examples: the sentence that gained a specific, the claim that lost its qualifier, the paragraph that was cut. Those communicate the judgement, and the full diff is available if anyone wants to audit it.

Frame the accepted changes in the handoff note rather than leaving them to be inferred. A line that says we kept two hedges because the trial size does not support a stronger claim is the kind of note that stops a future argument, and it takes ten seconds to write while the reasoning is still in your head.

Keep the three artefacts together: the original, the rewrite and the final text, plus the comparison. Storage is cheap and reconstruction is not, and the version history is what makes a claim about your editing process checkable six months later.

For regulated work, add one more habit: record which changes were made by a person and which by a tool. The distinction is invisible in a diff and it is the first thing an auditor asks about.

The three-version habit

Keep three files rather than one: the original, the rewrite and the final text. The middle version is the one people delete, and it is the one that answers the question about what the tool changed on its own.

Name them so the order is unambiguous, with a date in the filename and never the word final in two of them. The comparison is only possible while all three survive, and the fastest way to lose one is to save over it in the same folder under the same name.

Send the client the final text, the annotated comparison and a short note on what changed and why. The other two files stay in your archive until the invoice is paid and, for regulated work, considerably longer.

When you reject a rewrite

A rejected rewrite is worth keeping. It documents what the tool thought was wrong with the draft, which is often more interesting than a rewrite that worked: the model's edits show which sentences it found unnatural, and unnatural to a model usually means long, specific or hedged.

That is a useful signal in reverse. If the rewrite consistently removes the qualifiers and the specifics, then the humanising pass is optimising away exactly the parts that make the copy defensible, and the correct response is to stop using it for that kind of work rather than to check its output harder.

What a diff cannot tell you

It cannot tell you whether the new text is better, only what is different. Better is a judgement about audience, purpose and truth, and a diff has no access to any of them. A rewrite that removes three hedges may be an improvement or a libel risk, and the diff will look identical in both cases.

It also cannot see what both versions share. If the original invented a statistic and the rewrite kept it, the diff is silent, because nothing changed. The most dangerous sentence in a document is usually the one both drafts agree on.

Neither version is checked against a source by this tool. For that, compare the summary against the document it summarises, or run the claims through the console, and read the figures yourself.