The file that nearly ended Farah's contract with a German pharmaceutical client was, by every measure she had ever used, beautiful. It was a forty-segment batch of patient-facing dosing instructions, pre-translated from English into German by an LLM (large language model, a general text-prediction system that translates as a side effect of its broad training) and routed to her for MTPE (machine-translation post-editing, the work of editing machine output rather than translating from a blank cell). The German read like a careful human had written it: clean syntax, natural register, not one clumsy phrase in the whole batch. She post-edited it in fifty minutes, confirmed every segment, and delivered. Two days later the client's in-country reviewer flagged segment 23. The source said "Do not take more than two tablets in any twenty-four hour period." The German said the patient should take two tablets every twenty-four hours, as a standing instruction. The negation had not been mistranslated. It had simply vanished, dissolved into a sentence that was grammatically perfect and clinically dangerous, and Farah had read straight past it because it read so well. This lesson is about turning the cold feeling she had that afternoon into something better than a feeling: a repeatable scan, organized by the specific categories where confident machines fail, that catches the fluent lie before it ships rather than after.

Why Skepticism Needs a Structure

Every experienced linguist already knows, in the abstract, that machine output can be wrong. That knowledge did not save Farah, and it will not save you, because abstract skepticism is not a tool. It is a mood, and moods fade under deadline pressure exactly when you need them most. The reason segment 23 slipped through is not that Farah trusted the machine. It is that she had no specific, named, repeatable thing she was looking for. She was reading for "errors" in general, and "errors in general" is a target so vague that the eye, tired and moving fast, defaults to the only signal it can process quickly: does this sentence read well? Segment 23 read perfectly. So it passed.

The first principle of this lesson is that fluent is not correct, and it is worth stating precisely because the whole skeptic's checklist is built on it. Accuracy is not a property of the prose. It is a relationship between the target segment and two external things: the source segment it claims to render, and the approved terminology and locale rules it is supposed to honor. A sentence can be entirely fluent, entirely grammatical, entirely natural in the target language, and entirely wrong, because fluency lives inside the target text alone while accuracy lives in the comparison the target text quietly discourages you from making. The machine optimizes for the thing you can see at a glance (fluency) and does not verify the thing you have to work to check (fidelity). That asymmetry is the entire problem.

Research makes the danger concrete in exactly the domain that nearly burned Farah. Studies of LLM output on medical content found error rates around 59% on drug names, 60% on dates and times, and 66% on adverse events, and every one of those errors arrived in grammatically perfect prose. Read those numbers slowly. On the highest-consequence elements in the highest-consequence domain, a confident engine is wrong more often than it is right, and it never once sounds wrong. If your only quality check is "does this read like good German," you will catch zero of those errors, because all of them read like good German.

Abstract skepticism is a mood that fades under deadline. A category-by-category scan is a tool that does not, because it tells your eye exactly what to hunt for instead of asking it to feel uneasy in general.

The Tell and the Scan

The rest of this lesson is organized around two ideas that turn the mood into the tool. The first is the tell: a specific, recognizable signature that a particular kind of error leaves behind, the way a particular tic gives away a particular bluff. Machine errors are not random. They cluster into a small number of categories, and each category has a characteristic shape you can learn to spot. A dropped negation looks different from a swapped term, which looks different from a corrupted number. Once you know the tells, you stop reading for "errors" and start reading for these errors, which is a vastly easier and faster task.

The second idea is the scan: a fixed, ordered pass over the segment that checks each category in turn, performed the same way every time, regardless of how trustworthy the cell happens to look. The scan is what converts the tells from trivia you know into a habit you execute. A pilot does not preflight an aircraft by feeling generally careful. They run a checklist, in order, every flight, including the thousandth flight on the aircraft they know best, precisely because the day they skip it because everything looks fine is the day something is not fine and looks fine anyway. The post-editor's scan is the same instrument. The categories that follow are its checklist, and the worked examples show you what each item catches and how to catch it fast.

Numbers, Units, and the Corrupted Quantity

Start with numbers, because numbers are where the machine's failure is most consequential and, paradoxically, easiest to catch once you decide to look. A number is the rare element in a translation that is supposed to survive completely unchanged. "2.5 mg" is "2.5 mg" in every target language on earth; the digit and the unit are language-independent facts that the translation must carry across intact. This makes numbers the one category where you do not need to be a native speaker of the target to verify correctness. You need only line up the source figure and the target figure and confirm they are the same figure. And yet this is precisely where confident engines corrupt content constantly, because to the model a number is just another token to predict, and a plausible-looking number is, statistically, as good a prediction as the correct one.

The tells in this category are specific. Watch for a transposed or altered digit: the source says 1,500 and the target says 1,050 or 15,000, a corruption that reads completely naturally because 1,050 is a perfectly plausible number to find in a sentence. Watch for a silently changed unit: the source says "5 ml" and the target says "5 mg," a one-letter shift that in a dosing context is the difference between a volume and a mass and can be the difference between a dose and an overdose. Watch for decimal and thousands separators flipping or vanishing: in many European locales the comma and period reverse their roles, so "1,250" (one thousand two hundred fifty in English) can be read as "1.250" meaning one point two five in a German rendering, a thousand-fold error hiding in a punctuation mark. Watch for invented precision, where the engine rounds "about 30%" into a confident "30.0%," manufacturing a certainty the source never claimed.

How to Catch a Number Error Fast

The technique is mechanical and it is fast, which matters because you will do it on every segment that carries a figure. Do not read the number in context. Reading "take 5 ml twice daily" as a sentence invites your brain to process the meaning and skim the digit. Instead, isolate every number and unit in the source, then find its twin in the target, and compare them as bare tokens, ignoring the words around them. Source: 5, ml, twice, 24. Target: does each of those appear, unchanged, in the right place? You are not reading German at this moment. You are doing a clerical reconciliation that a bilingual ten-year-old could perform, and that is exactly its strength: it bypasses the fluency that fools your linguistic instinct.

Consider the worked example. Source segment: "Administer 0.5 mg per kilogram of body weight, up to a maximum of 40 mg per dose." The LLM returns fluent German that, scanned for numbers alone, yields: 0,5 mg, kilogram, 40 mg. Lined up against the source (0.5 mg, kg, 40 mg), three checks: does 0,5 equal 0.5? Yes, the decimal comma is correct German locale, good. Does the dosing logic survive (per kilogram, maximum per dose)? Yes. Does 40 equal 40? Yes. The segment passes the number scan in under ten seconds, and crucially, those ten seconds are spent on the only part of the segment that could kill someone. Now flip it: if the target had said "4,0 mg" as the maximum, the fluency of the surrounding sentence would not change at all, but the bare-token comparison would catch the missing zero instantly, because 4,0 does not equal 40 and you are looking at the tokens, not the prose.

• Treat every digit and unit as a fact that must arrive unchanged. Translation transforms words; it does not transform quantities. A number that differs between source and target is an error until proven a deliberate, documented locale conversion.
• Verify unit conversions are intended, not accidental. Sometimes a locale genuinely requires converting miles to kilometers or Fahrenheit to Celsius, and the engine may do it, or fail to, or do it wrong. A converted unit is a decision that needs the project's locale rules behind it, not a thing to let the model improvise.
• Check separators against the target locale explicitly. The decimal comma versus decimal point, and the thousands separator, are locale facts. A number that is "right" in source punctuation can be a hundredfold wrong in target punctuation, and the digits will look identical at a glance.

Negations: The Error That Deletes Itself

Farah's segment 23 was a negation failure, and negation is the single most dangerous category on the checklist because of one property no other category shares: a dropped negation does not leave a gap. When the machine omits a word, you might expect a hole in the sentence, an awkwardness, a missing piece your eye snags on. A negation failure is the opposite. The machine drops "not" or "do not" or "never" and then produces a sentence that is perfectly fluent, perfectly grammatical, and means the exact reverse of the source. There is no awkwardness, because the engine has fluently rewritten the sentence around the absence. The error is not visible as damage. It is visible only as a meaning, and a meaning that is wrong looks identical to a meaning that is right unless you are holding the source in your head to compare against.

This is why negation is the category that most punishes target-only reading and most rewards source-first reading. You physically cannot catch an inverted meaning by reading the target alone, because the target is internally consistent. "Take two tablets every twenty-four hours" is a coherent, sensible, fluent instruction. Nothing about it announces that the source said the opposite. The only way to catch it is to have read the source first, registered that it is a prohibition ("do not exceed two tablets"), and then noticed that the target is a prescription rather than a prohibition. The error lives in the gap between source and target, which is precisely the gap the fluent target invites you to ignore.

The Tells of a Flipped Meaning

Negation errors hide in a wider family of polarity failures, where the logical direction of a statement inverts. The tells are worth naming individually because the family is larger than just the word "not."

• The vanished prohibition. A "do not," "never," "must not," or "avoid" in the source becomes a neutral or positive instruction in the target. Source: "Patients with liver impairment should not take this medication." A polarity failure renders it as "Patients with liver impairment should take this medication," with the entire safety logic reversed and no surface trace.
• The flipped conditional. "Unless," "only if," "except when," and similar logical operators are fragile. "Do not operate the machine unless the guard is in place" can collapse into "operate the machine when the guard is in place," which sounds reasonable and inverts the safety condition.
• The double-negative collapse. Sources sometimes carry "not uncommon" or "cannot be ruled out." An engine smoothing the prose may render these as "common" or "is present," changing a hedge into a claim. The fluency improves; the meaning shifts.
• The scope error. A negation can land on the wrong part of the sentence. "The device does not require calibration before every use" (it needs occasional calibration) versus "the device requires no calibration before every use" can drift into "the device does not work before calibration," with the "not" attaching to the wrong clause.

The technique to catch these is a single deliberate question asked on every segment that carries a logical operator: does the source permit, forbid, or require this, and does the target do the same? Reduce the segment to its polarity skeleton. Source says forbid. Target says... permit. Stop. You do not need to evaluate the whole sentence; you need to evaluate one bit of information, the direction, and a direction is a yes-or-no check you can run in seconds. Farah's fifty-minute pass had time for that check forty times over. What it lacked was the habit of running it at all, because nothing in the fluent target prompted it. The scan is what supplies the prompt the fluency removes.

A dropped negation is the only error that improves the prose while reversing the meaning. You cannot read your way to it in the target; you can only compare your way to it from the source.

Approved Terms Versus the Confident Synonym

The third category is the quiet one, the one that does not threaten a life but routinely fails a file and damages a client relationship: terminology drift. Every serious localization project carries a termbase (the database of approved terms, the client's mandated word for each concept) and a style guide, and the central fact about a machine engine is that it does not know your termbase exists unless it has been explicitly given it, and even then it tends to wander. The engine was trained on the entire internet, where a given concept is expressed a dozen different ways, and at generation time it reaches for the most statistically common phrasing, not the one specific phrasing your client has decided is the only acceptable one.

Picture a client who manufactures a medical device they have decided, across every market, to call by one specific name, say their device is officially "the infusion set" in English and has a single mandated German equivalent in the termbase. The source says "infusion set" forty times across the file. The engine, being fluent and helpful and trained on a world where people call such things many things, renders it as the mandated term twenty times, as a common synonym fifteen times, and as a slightly different technical phrasing five times, each of them perfectly natural German, each of them wrong by the only standard that matters, which is the client's approved term. No single instance reads as an error. Read in isolation, every one of those renderings is fine German for a device. The error is only visible as inconsistency against the termbase, which is a comparison the fluent target, once again, gives you no reason to make.

Why the Synonym Is Not a Synonym

The instinct that defeats post-editors here is the writerly one: a good synonym makes prose less repetitive, so an engine that varies the term reads, to a literary ear, as more elegant than a human who repeats the approved term forty times. In general-purpose writing that instinct is correct. In terminology-controlled localization it is a defect. The approved term is approved precisely because consistency carries meaning: a regulator, a technician, a search index, or a downstream translation memory may depend on the same concept always appearing as the same string. A "synonym" that varies the term is not a stylistic improvement; it is a failure to honor a constraint the client has paid to enforce. The engine cannot tell the difference between elegant variation and terminological drift, because to the engine both are simply fluent, and fluent is the only thing it measures.

The tells are recognizable. Watch for the same source term rendered differently across segments, the hallmark of an engine reaching for variety. Watch for a plausible near-synonym that is not the termbase entry, especially for product names, feature names, UI labels, and regulated terms where the client's word is non-negotiable. Watch for the engine translating a term that should not be translated at all, such as a brand name or a product name that must stay in English, rendered helpfully into the target language. And watch for the reverse: a term left in English that the termbase requires localized.

The technique is to let the termbase do the looking. This is the category where tooling earns its keep: a CAT tool (computer-assisted translation environment) with the termbase loaded will flag, in real time, when the target segment fails to contain the approved term for a source term present in the segment. That flag is your scan for this category, and it is far more reliable than your eye, because your eye reads for fluency and the flag reads for the constraint. Where the tooling is not available, the manual version is a terminology pass: build or open the glossary, and for each approved term, search the whole target file for the source concept and confirm every instance carries the mandated rendering. Catching term drift segment by segment is hard; catching it with a file-wide search keyed to the termbase is fast and near-total. The worked discipline is to stop trusting that a fluent rendering of a controlled term is the right rendering, and to verify every controlled term against the list rather than against your sense of good prose.

The Subtler Categories: Register, Silent Edits, and Surface Confusion

The first three categories (numbers, negations, terminology) are the loud ones, the failures that flip a dosage, reverse an obligation, or break a client's controlled vocabulary. The remaining categories are subtler, but subtle does not mean safe. Each one fails a file in a different way: register failures betray the brand's voice, silent edits change the quantity of meaning, and false friends and locale slips produce output that looks right and is wrong underneath. We take them in turn, because each carries its own tell and its own fast check.

Tone, Register, and the Wrong Formality

The fourth category is subtler than a flipped dosage but every bit as capable of failing a file in the eyes of a client who cares about voice: tone and register. Register is the level of formality and the relationship a text assumes with its reader, and many languages encode it grammatically in ways English does not. The German "Sie" versus "du," the French "vous" versus "tu," the Japanese honorific levels, the Spanish "usted" versus "tú": these are not optional stylistic flourishes. They are mandatory grammatical choices that the translator must make on every sentence, and the wrong choice is not a minor blemish. A consumer brand that has decided to address its German customers with the warm, informal "du" will be horrified to find half its app strings using the distant, formal "Sie," and a legal notice that should be impeccably formal will be undermined by a sudden lapse into the casual register.

The machine's failure here has two shapes. The first is inconsistency: the engine, lacking any persistent sense of the brand's chosen register, drifts between formal and informal across a file, addressing the user as "du" in one string and "Sie" in the next, because each segment is generated in isolation and the model has no memory of the formality decision it made three segments ago. The second is defaulting: absent explicit instruction, the engine reaches for whatever register is statistically most common in its training data for that text type, which may be exactly the opposite of what the brand wants. Marketing copy defaulting to stiff formality, or a formal regulatory text drifting into approachable casualness, are both common, and both are fluent, and both are wrong by the client's brief.

Catching Register Without a Native Ear

This is the one category on the checklist that genuinely requires target-language competence to judge fully, because perceiving register is a native-or-near-native skill. But the scan still helps even here, because two of the most damaging failures are mechanical and do not require fine judgment to catch. The first is the consistency check: does the formality marker stay constant across the file? You can search a German file for "Sie" and "du" and their inflected forms and see immediately whether the file mixes them, which is almost always an error regardless of which register is correct. Mixed register is a defect you can detect without deciding which register the brand wanted; you only need to notice that the file cannot decide.

The second is the brief check: does the chosen register match the documented instruction? A good localization brief states the target register explicitly ("address the user informally, second person, du-form"). The scan is to confirm the file obeys that instruction. Where it does, move on; where it does not, you have a concrete, defensible defect to flag, not a vague feeling that the tone is off. The tell to watch for is the register lurch: a passage that suddenly shifts how it addresses the reader, which signals the engine generated those segments without carrying the formality decision forward. The worked habit is to treat register as a project-level constraint, fixed once in the brief and verified for consistency across the file, rather than a per-segment aesthetic judgment, which keeps the cost of the check low and its reliability high.

Added and Dropped Content: The Silent Edits

The fifth category covers the two complementary ways a machine alters the quantity of meaning: it adds content the source never contained, or it drops content the source required. Both are insidious because both produce fluent output, and the LLM is especially prone to them because, unlike a narrower neural MT engine that tends to map source to target more conservatively, an LLM is a confident author by nature. It is willing to smooth a confusing source by guessing intent, to add a clause that "should" be there to complete a thought, or to quietly omit a phrase it found redundant or hard to render. The narrow engine mistranslates; the LLM edits, and it edits with the authority of fluent prose.

Addition, also called hallucination when the added content is invented, shows up as material in the target that has no source. The engine, asked to render a terse source, produces a fuller, more explanatory target because fuller and more explanatory is what its training rewarded. A source list item that says "Store below 25C" becomes a target that says "Store below 25 degrees Celsius, away from direct sunlight and moisture," with the sunlight and moisture invented out of the model's general knowledge of how things are stored. Every added word reads naturally. None of it is in the source, and in a regulated document, content that is not in the approved source is content the client did not approve and may be legally responsible for.

Omission is the mirror image: the target says less than the source. A qualifying clause, a condition, a second sentence, a parenthetical caveat, simply does not appear in the target, and because the engine reconstructs a fluent sentence around the absence, there is no grammatical seam where the missing piece was. This is the same mechanism as the dropped negation but applied to any unit of meaning: a warning, an exception, a date, a cross-reference. The fluent target closes seamlessly over the gap.

The Length and Mapping Check

The fast technique for this category exploits a useful imperfect signal: gross length mismatch. Languages expand and contract by predictable ratios in translation (German typically runs longer than English, for instance), so a target segment that is dramatically shorter or longer than its expansion ratio would predict is a flag worth a closer look. A target that is half the length of its source is a strong candidate for an omission; a target noticeably longer than the language pair's typical expansion is a candidate for an addition. Length is not proof, because legitimate restructuring changes length too, but it is a cheap trigger that tells you which segments deserve the slower check.

The slower check, reserved for flagged segments and all high-consequence ones, is the mapping pass: walk the units of meaning in the source and confirm each one has a counterpart in the target, and walk the units in the target and confirm each one has a source. This is two-directional on purpose. Reading source-to-target catches omissions (a source unit with no target). Reading target-to-source catches additions (a target unit with no source). Doing only one direction catches only one failure. The worked example: source says "Contact your physician if symptoms persist beyond three days." Source units: contact physician, condition (symptoms persist), threshold (three days). Confirm all three appear in the target, and confirm the target contains nothing else, no invented advice, no added timeframe. Three units in, three units out, nothing extra. The segment is clean on this axis. The discipline is to count meaning, not just to read it.

An LLM does not just mistranslate; it edits. It adds what it thinks should be there and drops what it thinks is redundant, both in fluent prose, which is why you count the units of meaning in and out rather than trusting the sentence to tell you it changed.

False Friends and the Locale Slip

The final two categories are the connoisseur's tells, the ones that separate a careful post-editor from a fast one, and they share a quality: both are errors the engine makes with total confidence because both involve surface-level patterns that look right and are wrong underneath.

A false friend is a word in the target language that resembles a source word but means something different. The English "actual" and the Spanish "actual" (which means "current"), the English "sensible" and the French "sensible" (which means "sensitive"), the English "library" and the French "librairie" (which means "bookshop"), the English "eventually" and the German "eventuell" (which means "possibly"): these are traps that catch human translators too, but a machine engine falls into them in a particular way. Because the words look alike, a low-quality engine or an LLM working too literally may render the source word with its look-alike rather than its meaning-alike equivalent, producing a target that contains a real, fluent target-language word that means the wrong thing. The tell is a word in the target that is suspiciously close in form to a source word, especially in a context where the meanings could plausibly diverge. The technique is to maintain a mental or written list of the false friends in your language pair (every experienced linguist has one) and to treat any cognate-looking rendering of a known false-friend source word as a flag to verify against meaning, not form.

Locale Slips: The Wrong Conventions

A locale is the full set of regional conventions a target audience expects: not just the language but the country variant, and with it the date format, the number format, the currency, the units, the address format, the quotation marks, the spelling conventions, and the formality defaults. A locale slip is when the engine produces the right language but the wrong regional conventions, and these are easy to miss because the language is correct; only the conventions underneath are off.

The classic locale slip is the date. The source "03/04/2026" is ambiguous (is it March 4 or April 3?), and an engine may carry it across unchanged into a locale that reads it the other way, silently shifting the date by a month. A date written in numeric form is a locale landmine, and the safe move is to confirm the target uses an unambiguous format appropriate to the target locale. The next is currency and units: a dollar figure carried into a Eurozone document without conversion or clarification, a temperature left in Fahrenheit for a Celsius audience, an imperial measurement left imperial for a metric one. The engine may convert, may not, or may convert wrongly, and any of those is a locale slip unless it matches the documented locale rules. Then there are the typographic conventions: German uses different quotation marks than English, French inserts a space before certain punctuation, and an engine that carries the source's punctuation conventions into the target has produced fluent words in malformed local dress.

The most damaging locale slip is the one between variants of the same language. Spanish for Spain is not Spanish for Mexico; Portuguese for Portugal is not Portuguese for Brazil; French for France is not French for Canada. An engine asked for "Spanish" without a specified variant defaults to some blend or to the variant most common in its training data, and the result can be fluent Spanish that is subtly, persistently wrong for the actual target market: wrong vocabulary, wrong formality defaults, wrong regional idiom. This is a locale slip that no amount of fluency reading will catch, because the output is genuinely fluent in a Spanish, just not the Spanish the project requires. The technique is to confirm, before trusting any of the rendering, that the engine was targeted at the exact locale (es-MX, pt-BR, fr-CA, not just "Spanish" or "Portuguese" or "French"), and to scan for the variant-specific vocabulary and conventions that mark the correct market.

Assembling the Scan Into a Habit

You now have seven categories of tell, and a category-by-category list is useful as a reference but useless as a workflow until it becomes a single, ordered, fast pass you run the same way every time. The point of organizing the tells into categories was never to make you stop on every segment and consciously walk through seven headings; that would destroy the MTPE economics that make the work viable and earn you a reputation for being slow. The point is to compress the categories into a scan so practiced that it runs almost automatically, the way an experienced driver checks mirrors without narrating the act to themselves.

The scan has a natural order, from the checks that are fastest and highest-consequence to the ones that are slower and more judgment-bound. First, the mechanical reconciliations, because they are fast and catch the deadliest errors: isolate and compare every number and unit; reduce every logical operator to its polarity and confirm source and target agree. These two checks are clerical, language-light, and catch the corrupted quantity and the flipped meaning, the two errors most likely to cost a life or a lawsuit. Second, the constraint checks: confirm every controlled term matches the termbase, and confirm the register matches the brief and stays consistent. These lean on tooling (term flags, formality searches) and catch the failures that fail a file with a client. Third, the meaning-quantity check: on flagged and high-consequence segments, run the two-directional mapping pass to catch additions and omissions. Fourth, the connoisseur's pass: watch for the false-friend cognate and the locale slip, the surface-right, underneath-wrong errors.

Spending the Attention Budget Where the Risk Is

The scan is not applied with uniform intensity to every segment, because attention is a finite budget and spending it evenly is the same as spending it carelessly. The intensity of the scan should rise with the consequence of the content. A throwaway marketing tagline gets a light pass; a dosing instruction, an indemnity clause, a safety warning, or a financial figure gets the full scan, every category, every time, no matter how fluent and trustworthy the cell appears. This is the crucial inversion: the fluency of a segment is not evidence of its safety, and on high-consequence content the smoothest cell deserves the most scrutiny, not the least, because the smooth cell is exactly where the silent critical error hides. The engine's competence is fluency, so its errors arrive fluent, so reading for fluency is structurally guaranteed to miss them. Only the source-anchored, category-keyed scan catches the error the prose is designed to hide.

Return one last time to Farah. The cost of the segment-23 negation failure was not just the rework; it was a frightened client, a flagged delivery, and a quiet question over whether her files could be trusted on regulated content. The fix was not "be more careful," which is the advice that fails because it has no shape. The fix was to install the polarity check as a fixed step: on every segment carrying a "not," a "never," an "unless," a "do not," reduce it to forbid-permit-require and confirm the target agrees with the source, before confirming the segment, every time, regardless of how clean it reads. That single habit, costing a few seconds per segment, would have caught segment 23 in her first pass. The skeptic's checklist is not a counsel of paranoia or a demand to distrust everything equally. It is the conversion of a vague, fade-prone unease into a small set of specific, fast, repeatable checks aimed at the precise places confident machines fail, so that the error which reads perfectly is caught by the one process that does not read for perfection.

Key Takeaways

• Fluent is not correct: accuracy is a relationship between the target segment and its source plus the approved terminology and locale rules, not a property of the prose. The engine optimizes the thing you see at a glance (fluency) and does not verify the thing you must work to check (fidelity), which is why a perfectly readable segment can be completely wrong.
• Abstract skepticism fades under deadline; a category-by-category scan does not. Machine errors cluster into a small set of categories, each with a recognizable tell, so you stop reading for "errors" in general and start hunting for these specific errors, which is faster and far more reliable.
• Numbers and units must arrive unchanged: isolate every digit and unit and compare source and target as bare tokens, ignoring the surrounding prose. Watch for transposed digits, silently swapped units (ml to mg), flipped decimal and thousands separators, and invented precision, every one of which reads naturally.
• Negations are the deadliest category because a dropped "not" leaves no gap; the engine fluently rewrites the sentence into its opposite. You cannot catch an inverted meaning by reading the target alone, so reduce every logical operator to forbid-permit-require and confirm source and target agree.
• Approved terms drift into confident synonyms because the engine reaches for the statistically common phrasing, not the client's mandated one. Elegant variation is a defect in terminology-controlled work; let a termbase-loaded CAT tool or a file-wide glossary search catch every controlled term rather than trusting your sense of good prose.
• Register failures (Sie versus du, vous versus tu) and locale slips (date formats, currency, units, typographic conventions, and the wrong language variant such as es-ES served for es-MX) are fluent and wrong: verify register consistency across the file against the brief, and confirm the engine was targeted at the exact locale, not a generic language.
• An LLM does not just mistranslate, it edits, adding content the source never had and dropping content it judged redundant, both in seamless prose. Use gross length mismatch as a cheap trigger, then run a two-directional mapping pass (source-to-target for omissions, target-to-source for additions) on flagged and high-consequence segments, counting units of meaning in and out.
• Run the scan in order from fastest and highest-consequence (numbers, polarity) to slower and judgment-bound (terminology, register, meaning-quantity, false friends, locale), and scale its intensity to the content's consequence. The smoothest cell on high-stakes content deserves the most scrutiny, not the least, because manufactured fluency is exactly where the silent critical error hides.