How to Proofread With ChatGPT Without Changing Names, Numbers, or Dates

The short answer

Put an explicit fact-lock instruction in the prompt, listing the categories that must survive untouched: proper names and their spelling, numeric amounts, currencies, units of measurement, dates, times, time zones, reference identifiers, version numbers, and any wording that expresses uncertainty. Then diff the output against the original token by token before you use it. The prompt cuts the error rate; the diff is what catches the remainder.

Below is the prompt we wrote for this, the test document we ran it against, and a full audit of what came back. The document contains ten invented factual tokens across the categories that break, so you can see the failure modes rather than take our word for them.

Why the facts move at all

It helps to understand the mechanism, because it explains why the errors are so consistent and why a better prompt only partly fixes them.

ChatGPT is not editing your document. It is generating a new sequence of tokens that is likely to follow from your instruction plus your text. There is no separate channel where '248,500 EUR' is held as a numeric value and re-emitted unchanged. It is four or five tokens, and each one is predicted. Most of the time the prediction is a copy, because copying is by far the most likely continuation. But 'most of the time' is not 'always', and the cases where it is not are exactly the cases where a plausible-looking alternative exists.

That is why the failures cluster in predictable places. A unit has a common conversion. A date has a common alternative format. A range has a midpoint. A hedge has a confident version. In each case there is a high-probability neighbouring token sequence that is grammatically better and factually different, and the model has no inherent reason to prefer the worse grammar.

The test document

A client status update. It is deliberately ordinary — the kind of thing that gets written at speed on a Thursday afternoon and sent without a second read. It contains ten invented factual tokens plus several deliberate grammar errors, so a correction pass has real work to do and we can see whether the facts survive the work.

Status update for Halvern Point, ref SOW-2291-b

Hi Ines,

Quick update on the phase two rollout. Me and Dev have finished the
site survey for seven of the nine sites, and the remaining two is
blocked pending access to the substation.

The revised quotation is 248,500 EUR, which are roughly 4% below the
original estimate. Load measurements at the Kilmory site came in at
340 kWh per cycle, about 18 metric tonnes of throughput per shift,
and we have not yet confirmed whether the cooling upgrade is needed
to sustain that.

Next milestone is 14 November 2026 for the design review, with the
call at 09:30 CET. Dev will circulate the v3.2.1 drawings before
then so the client team have time to review them.

Its worth noting that the timeline may slip if the access issue is
not resolved by the end of next week, and there is a chance we will
need to revisit the phasing.

Thanks
Anesh

The prompt

Written for this article. The design principle is that every instruction names a category the model is likely to 'improve', rather than asking it to be careful in general — 'do not change the facts' does very little, because the model does not believe it is changing facts.

Proofread the text below. Fix only grammar, spelling, punctuation and
subject-verb agreement. Do not rewrite, restructure, summarise, expand
or change the tone. Keep my sentence order and my sentence lengths
close to the original.

HARD CONSTRAINTS - these must be byte-for-byte identical in your
output. If fixing the grammar around one of them seems to require
changing it, leave the grammar error instead:

- Proper names of people, companies, places and products, including
  their exact spelling and whether or not they carry accents
- Numeric values, currencies and currency codes or symbols
- Units of measurement. Do not convert between unit systems and do not
  spell an abbreviation out
- Dates, times and time zones. Do not change the date format
- Reference numbers, document IDs, version numbers, codes and URLs
- Ranges. Keep a range as a range; never replace it with a midpoint
  or a single value
- Words expressing uncertainty or possibility: roughly, approximately,
  about, may, might, could, expected, estimated, not yet, pending,
  possibly, likely, chance. Never make a hedged statement definite
  and never delete a hedge

OUTPUT FORMAT:
1. The corrected text only, with no preamble and no commentary
2. Then a section headed CHANGED, listing every word or phrase you
  altered, as "original -> corrected"
3. Then a section headed FACTS CHECKED, listing each name, number,
  date, unit and identifier from the original and confirming it is
  unchanged. If you had to alter one to fix the grammar, say so here
  explicitly instead of doing it silently

Do not add information that is not in the text. Do not resolve
ambiguity by choosing an interpretation; if a sentence has two
readings, keep the original wording and flag it under CHANGED.

TEXT:
<paste your document here>

Three parts of this prompt do most of the work. The escape clause — 'leave the grammar error instead' — matters more than it looks, because without it the model resolves the conflict between fixing agreement and preserving a fact in favour of fixing agreement. The FACTS CHECKED section forces it to enumerate the tokens, which makes an omission visible rather than silent. And the instruction to flag ambiguity rather than resolve it stops the model picking one of two possible meanings.

What came back

The grammar fixes were correct and there were seven of them: 'Me and Dev' to 'Dev and I', 'the remaining two is' to 'the remaining two are', 'which are roughly 4% below' to 'which is roughly 4% below', 'Its worth noting' to 'It's worth noting', 'the client team have time' to 'the client team has time', a comma before 'and we have not yet confirmed', and a comma after 'Kilmory site'. None of them are in dispute.

Here is what happened to the ten factual tokens.

Four of ten tokens changed, and this is the good case — the prompt named all four categories explicitly. Without the fact-lock instruction, the same document came back with the currency converted, the metric tonnes converted to short tons, the date reformatted to a numeric US format, and 'we have not yet confirmed whether the cooling upgrade is needed' rewritten as 'the cooling upgrade is not needed'. That last one inverts the meaning of the sentence while making it read better.

Uncertainty is a fact, and it is the one that gets deleted

Names and numbers get attention because they look like facts. Hedging language does not, and it is more consequential. 'Roughly', 'may', 'expected', 'pending' and 'not yet' carry the epistemic state of the document — what is known, what is estimated and what is still open. A business update where everything reads as settled is not a cleaner version of the same document. It is a different document with different liabilities attached.

Notice that the direction is almost always the same. Hedges are removed, never added. Confident prose is the higher-probability continuation, so a model asked to improve writing will move your document toward certainty whether or not the underlying facts support it. That is a systematic bias, not a random error, and it is the reason to check for it specifically rather than hoping a general proofread covers it.

The three-minute audit

Read the whole corrected document and you will not catch these. They are not errors, so reading for errors does not find them. Auditing for tokens does.

1. 1

   Extract the fact list from the original first

   Before you paste anything into ChatGPT, scan the original and write down every token that carries a name, a number, a date, a unit, an identifier or a hedge. In the test document above that is the ten-row table. It takes about ninety seconds and it is the step that makes the rest possible.

   If you skip this, you will diff against your memory of the document rather than against the document, and your memory has already been overwritten by the output you just read.

2. 2

   Run the prompt with the FACTS CHECKED section

   Ask the model to enumerate the tokens itself. It will get most of them right, and the enumeration is what makes an omission visible — a token missing from its own list is a token it touched.

3. 3

   Diff against your list, not against the document

   Take your ten-row list and search the output for each token using Ctrl+F. Exact string match. A token that does not match exactly has changed, whatever the reason.

4. 4

   Check the hedges separately

   Search the output for each of: roughly, approximately, about, may, might, could, expected, estimated, pending, not yet, possibly, likely, chance. Compare the count against the original. Fewer matches means hedges were deleted.

5. 5

   Re-check the ambiguous cases by reading, not searching

   Dates that changed format, times that changed clock, and units that were spelled out will not fail an exact-match search in a way that is obvious. Read those sentences once, in context.

6. 6

   Restore by hand, do not re-run

   Fix the four changed tokens manually in the output. Re-prompting for a correction gives you a new generation with new places to drift, and you will be auditing again.

Where ChatGPT is still the right tool

None of this is an argument against using ChatGPT to proofread. For documents without load-bearing facts it is very good, and it is faster than any alternative. The question is which documents those are.

The dividing line is whether the document's value depends on its facts being exactly right. If it does, a tool that generates new text is the wrong shape of tool, however good the generation is. You want something that returns your text with the errors removed, so that the diff is small enough to actually read.

Where you paste it matters too

A secondary problem that compounds the first: the ChatGPT browser interface is a contenteditable editor, and your browser's own spell check behaves differently there than it does in a normal textarea.

• The ChatGPT web app in Chrome, Edge or Firefox runs as a normal web page. A browser extension can reach its composer field, and Chrome's own spell check may or may not underline in it depending on how the field is marked up.
• The ChatGPT desktop apps for Windows and macOS are installed programs. No browser extension can reach them, and their spell check is their own.
• The ChatGPT mobile apps are the same — separate programs, no extension support.
• Errors in ChatGPT's generated answers are a different problem again. No proofreading tool of any kind applies to text the model produced; you have to read it.

The practical consequence: if you want a correction pass on a draft before you paste it into ChatGPT, do it in a browser text field where your tools work, not inside the ChatGPT composer. And if you are proofreading ChatGPT's output, paste that output somewhere you can run a real diff before it goes anywhere near a client.

Where this breaks down

The alternative for documents where facts carry weight

Frequently asked questions