When a rewrite changes your facts: how to check AI edits

On October 4, 2026 we ran three short source texts through a popular commercial humanizer, in both its basic and its deep mode, and kept all eight raw outputs. The sources were synthetic process documents written for the test: an editorial brief, a studio’s appointment-change policy and a warehouse returns procedure. Each output was checked two ways: for protected strings that had to survive word for word (numbers, names, durations), and by a separate review of meaning against the source.

All eight failed. Some of the changes:

• A threshold changed unit. “Escalate after 14 days” became 14 weeks.
• A proposal became a deadline. A suggested end-of-day review window of 20 minutes became a rule to review each return within 20 minutes of arrival.
• Two different checks were merged. Comparing a carton’s item code with the authorised item code became comparing the item code with the return authorisation number.
• Names and counts went missing. The supplier’s name, “three photographs” and “six weeks” disappeared from one output.
• Options became requirements. Formats the brief offered as optional were rewritten as things the reader must do.
• A careful claim became a different claim. “No measured improvement is claimed” became “no guarantee of improvement”. Those say different things.
• Claims were invented. One output said the process “works” and suits any supply chain. The source made no such claim.

Two of the failing outputs scored above 99% “human” on the same company’s AI detector. A high score said nothing about whether the text was still true.

A rewriting model writes the most plausible next words given its instructions, and “14 weeks” is as plausible a phrase as “14 days”. Tools sold to lower detector scores are pushed to change as much wording as they can, and numbers, units and small qualifiers get changed along with everything else. These errors also pass every check people usually run. Spelling is fine, grammar is fine, the tone is better. Only a comparison with the source catches them.

Check each kind of fact separately. Reading the whole thing “for meaning” in one pass misses exactly the small changes listed above.

Steps

1. 1List the protected facts before you rewrite. Copy every number with its unit, every name and every link from the source into a short list.
2. 2Search the rewrite for each one. Anything you can’t find is either deleted or changed. Decide which.
3. 3Diff the two texts word by word. With git installed, git diff --no-index --word-diff source.txt rewrite.txt shows every changed word inline, with no repository needed. Any online diff checker does the same.
4. 4Read the diff for modal verbs, qualifiers and scope. These don’t show up in a search for numbers, and they change obligations.
5. 5Reject outputs with more than one changed fact. Patching a rewrite fact by fact tends to leave one behind. Start again from the source with a lighter setting, or edit the original by hand.

IntactVoice Rewrite compares every number, unit, name and link in its output with your source, plus any exact strings you list. In strict mode, the default, a changed fact fails the request, the response lists what changed, and it uses no words from your allowance. It doesn’t judge modal verbs, qualifiers or scope for you, so steps 4 and 5 above still apply to our output and to anyone else’s.

• It’s small and uncontrolled: three synthetic sources, one vendor, eight outputs, on one day.
• The meaning review was done by an AI model with a fixed checklist, plus exact-string checks. No blind human review was run.
• It can’t tell you how often any tool changes facts in general. It shows that it happens, and that a reading for tone won’t catch it.

Pick the most recent piece that went through any AI rewrite before it was published. Pull the original draft, list its numbers, units, names and links, and search the live version for each one. If one has changed, fix the live page first, then add step 1 above to your publishing checklist.