Grammar Checker Changing Names or Technical Terms? How to Protect the Words That Matter

The short answer

If a grammar checker is changing your names and technical terms, add them to its custom dictionary or protected-words list. Every serious tool has one, because the underlying problem is unsolvable without user input: a dictionary cannot distinguish a misspelling from a word it has not seen.

One Shot Fix has a protected-words list. Adding a term there stops it being treated as an error, which means you stop re-reviewing the same five words on every message.

The rest of this article is a test set you can run against any tool in about five minutes. It uses invented tokens so the results are comparable, and it separates four failure modes that people usually lump together as 'it changed my words'.

Four failure modes, and why they are different problems

The fourth one is why this matters more than a spelling annoyance. 'Idempotent' and 'repeatable' are not synonyms. An idempotent operation can be applied any number of times with the same result; a repeatable operation can be run again. If a tool makes that swap in an API specification, the document is now wrong and reads as though it is right.

The test set

All tokens below are invented or generic. Copy the paragraph into whatever tool you are evaluating, run a correction, and compare. Deliberate real errors are included so you can check the tool still does its job.

On 14 March the Onepoint team shipped Kestrel DB v2.4.1-rc3 to the
eu-west-2 region. Aneesh Varekal and Sofia Lukasik ran the migration
against INC-4482 and the rollback plan in PR #3127, which took
aproximately 40 minutes. The shard key strategy uses consistent
hashing so a rebalance dont require a full copy, and the ingest path
now applies backpressure instead of dropping messages when the queue
saturates. MTTR for the last three incident was 22 minutes, measured
from the first Zephra alert to the Dataweft dashboard showing green.
Retry is idempotent because every write carries a request-id, and the
handler will fail fast on any 4xx rather than retrying. RBAC scopes
are enforced at the edge by the gRPC interceptor, which validate the
JWT before it reach the service. Next step is to load test at 12k rps
with CQRS read replicas enabled and to check whether the sha256
checksum verification adds measurable latency.

A tool that catches all six and changes none of the twenty-four is doing the job correctly. Anything else tells you something specific: a missed error means weak grammar coverage, and a changed token means you need the protected-words list.

What each kind of tool does with it

Setting up a protected-words list

One Shot Fix has a protected-words list. Adding a token there removes it from consideration, so a correction pass stops touching it. Here is how to build one that is actually useful rather than a list of everything.

1. 1

   Start from the failures, not from a dictionary

   Run the test paragraph, or better, run a real message you recently corrected. Write down every token that changed and should not have. That list is your starting point and it is usually under twenty items.

2. 2

   Add the categories that recur in your work

   Colleague names. Client and product names. Internal codenames. Service and repository names. CLI commands and flags. Acronyms your team uses without expanding them.

3. 3

   Add terms of art as whole phrases

   Single-word protection does not stop 'fail fast' becoming 'fail quickly', because both words are valid English. Protect the phrase. The same applies to 'short-circuit', 'fan out', 'back off' and 'opt in'.

4. 4

   Keep the list short enough to maintain

   A list of four hundred tokens is a list nobody reviews. When something stops being changed that should be, you will not notice. Aim for the tokens that actually recur.

5. 5

   Review it when your vocabulary changes

   New product launch, new team members, a migration to different tooling — each adds tokens. Five minutes a quarter is enough.

How other tools handle it

Every major checker has an override mechanism, because the problem is unavoidable. The names differ and so does the scope.

The phrase question is the one to check. Most browser dictionaries store single words, which protects 'idempotent' but not 'fail fast'. If your writing depends on multi-word terms of art, confirm the tool supports phrases before you commit to it.

Manual checks that no dictionary replaces

A protected-words list handles the tokens you know about. These checks handle the ones you do not.

1. Search the corrected text for every capitalised word and confirm each one is still spelled the way the person or product spells it. Names are the highest-cost error and the easiest to miss.
2. Find-and-replace check on hyphens. If your original had 'event-driven' and 'co-ordinate' and the output has different hyphenation, something normalised them.
3. Count your digits. Compare the number of numeric tokens in the input and the output. A correction that changed '12k rps' to '12,000 rps' has altered the text, even if the value is the same.
4. Read any sentence containing a term of art out loud, comparing against the original. This is the only reliable way to catch failure mode four, because the changed sentence reads perfectly well.
5. Paste identifiers into their real destination. A 'request-id' that survived as text may still have been re-cased in a way you did not notice until it fails.

Step 3 is fast and catches more than you would expect. Step 4 is the one people skip, and it is the one that matters most for technical documents.

Where this breaks down

Run the test yourself

Frequently asked questions