The recall notice went out on a Wednesday, and the sentence that caused it was, by every surface measure, beautiful. A consumer-electronics company had shipped a lithium battery pack into a dozen markets, and the safety section of the quick-start guide carried one instruction the legal team had fought over for a week in English: "Do not charge the unit above 45 degrees Celsius." In the German file the machine had produced a clean, confident, idiomatic rendering that any reviewer skimming for grammar would have waved through. It said the unit should be charged above 45 degrees Celsius. The "nicht" had evaporated. No tag flagged it, no fuzzy-match warning fired, no spell-checker underlined it, because nothing was misspelled and nothing was ungrammatical. The sentence was a perfect-reading lie. Three weeks and roughly four hundred thousand euros of reprinted packaging later, the localization manager sat in a conference room trying to explain to a furious client how a single dropped word had survived machine translation, a translation memory leverage check, an automatic quality-estimation pass, and a human reviewer who had read the segment and felt nothing was wrong. The answer is the subject of this entire lesson. The engine had not made a mistake the way a tired human makes a mistake. It had done exactly what it was built to do, and what it was built to do is the problem.

Two Different Crimes: Invention and Erasure

Before we catalogue the failures, we have to separate two words that get used interchangeably and should not be, because they fail in opposite directions and you catch them with opposite habits. Hallucination is the machine adding meaning that is not in the source: a number that was never there, a clause the author never wrote, a confident assertion the engine improvised to fill a gap. Omission is the machine subtracting meaning that is in the source: a dropped "not," a missing qualifier, a clause that simply did not make it into the target. One is invention. The other is erasure. Both produce output that reads perfectly, which is why both are dangerous, but they leave different fingerprints and you hunt them differently.

Here is the asymmetry that makes omission the more frightening of the two. When the engine hallucinates, it adds material, and added material at least has a chance of looking out of place. A number that does not belong, a sentence that runs slightly long, a claim that sits oddly against its neighbors: invention sometimes leaves a seam. Erasure leaves nothing. When a clause is omitted, there is no scar tissue in the target, no gap, no stray punctuation. The sentence closes up smoothly around the wound like water over a stone. You are not reading a sentence that looks wrong. You are reading a sentence that is missing, and the only way to know it is missing is to have the source open beside it and count. The battery sentence was an omission. Nothing was added. One small word was removed, and the removal was invisible because the result was still a complete, grammatical, fluent German sentence that happened to instruct the reader to do the one thing the original forbade.

Hallucination is the machine adding what was never there. Omission is the machine removing what was. You catch invention by reading the target; you catch erasure only by comparing it to the source.

Why Fluency Hides Both

The reason both crimes go undetected is a single mechanical fact that this program returns to in every lesson: a machine-translation (MT) engine, whether a narrow neural machine-translation (NMT) system trained only to translate or a large language model (LLM) translating as a side effect of general text prediction, is optimizing for fluent, probable target-language text. It is not optimizing for faithful transfer of the source. Faithfulness is an emergent side effect that usually, but not always, coincides with fluency. The engine's entire competence is making the next word sound right. When fluency and accuracy point the same way, you get a correct translation. When they diverge, the engine follows fluency every single time, because fluency is the only thing it can actually measure about its own output. It has no separate faculty that checks the target back against the source's meaning. That check is the job it handed to you, and it did not tell you it was handing it over.

The "Not" That Disappears: Dropped Negation

Start with the failure mode that has killed people and triggered recalls, because it is the purest illustration of why a confident engine is more dangerous than an honest one. Negation is the linguistic feature that carries the most meaning per character and the least statistical weight. A single "not," "no," "never," "ne...pas," "kein," or "nicht" inverts the entire truth value of a sentence, but to a next-token prediction system it is a small, low-information word that the surrounding fluent context can easily overwhelm.

Consider the mechanics concretely. The engine generates the target one token at a time, each token chosen because it is the most probable continuation given everything before it and the source. In a sentence like "the device must not be used on patients with an active pacemaker," the overwhelmingly common pattern in the training data is "the device must be used," "the device is intended for," "the device is suitable for." Affirmative medical instructions vastly outnumber the specific negated one. So when the engine reaches the point where the "not" should appear, the probability mass piled up behind the affirmative continuation is enormous, and the probability mass behind preserving a negation it has half-forgotten in its internal state is thin. The fluent path and the faithful path fork, and the engine takes the fluent one. It produces "the device should be used on patients with an active pacemaker," a sentence that is grammatically immaculate and clinically lethal.

The worked example and its consequence. Source: "Do not exceed the recommended dose." Machine output: "Exceed the recommended dose." The target is two words shorter, perfectly grammatical, and instructs the patient to overdose. A reviewer reading for flow, register, and grammar finds nothing to flag, because there is nothing ungrammatical to flag. The error is not in the prose; it is in the relationship between the prose and the source, and that relationship is invisible unless you are looking directly at it. In a localization quality framework this is a Critical error, the single most severe category, defined as an error that creates a health, safety, legal, or financial risk, and one Critical error fails the entire file no matter how clean the other nine hundred segments are. The dropped negation is the canonical Critical error because it is maximally severe and minimally visible at the same time.

Why Negation Is Mechanically Fragile

It helps to understand that this is not random. Three forces conspire against the negation specifically. First, the fluency prior, the engine's learned bias toward the most common, most probable phrasing, which in most domains is affirmative. Second, the information density mismatch: the "not" is doing enormous semantic work while occupying almost no textual space, so it is easy for the model to under-weight. Third, distance: in many language pairs the negation and the verb it negates sit far apart, and across that distance the engine's grip on "this clause is negated" weakens as it generates intervening tokens. Languages with split or doubled negation, or where negation is marked by a particle that migrates to the end of a clause, are especially prone. The practical consequence for you is simple and non-negotiable: in any high-consequence content, every negation in the source is a mandatory checkpoint. You do not read the target sentence and ask whether it sounds right. You find the negation in the source and confirm, word by word, that its polarity survived the crossing.

Invented Numbers and Flipped Units

Numbers are where hallucination and corruption meet, and they are uniquely dangerous because a wrong number reads exactly as confidently as a right one. There is no grammatical signal that distinguishes "2.5 mg" from "25 mg." Both are valid. Only the source tells you which is correct, and the engine does not consult the source the way you must.

Several distinct failures hide under the single word "numbers," and a careful linguist separates them.

• Digit transposition and decimal drift. The engine renders "1,250" as "1,520" or "2.5" as "25" or "0.5" as "5." This is a corruption of an existing number, technically closer to omission-of-precision than pure invention, but the effect is the same: a fluent sentence wrapped around a wrong quantity.
• Unit flips and failed conversions. The source says "45 degrees Celsius" and the target says "45 degrees Fahrenheit," or the engine "helpfully" converts a measurement and gets the conversion wrong, or fails to convert when conversion was required by the target locale. "Locale" here means the full set of regional conventions, the language plus the country plus the formatting rules for dates, numbers, units, and currency.
• Pure number hallucination. Fed thin or fragmentary input, a heading, a table cell, a list item with no surrounding context, the engine invents a number that corresponds to nothing in the source at all, because a plausible-looking sentence in that slot tends to contain a number and the engine fills the slot with what looks right.
• Separator inversion. The comma and the period swap roles between locales. "1,000" meaning one thousand in English becomes a catastrophe in a locale where the comma is the decimal separator, turning one thousand into one. The engine, optimizing for fluent output, does not always reason about which convention the target locale demands.

The worked example and its consequence. A dosing table in a German source reads "2,5 mg" (where the comma is the German decimal separator, so the value is two and a half milligrams). The English machine output reads "2,5 mg," preserved verbatim, which an English-reading clinician parses as twenty-five hundred, or "2.5 mg" rendered as "25 mg" through a decimal drop. Either way a pharmacist mixing the compound reads ten times the intended dose. This is not a hypothetical class of error: studies of LLM-generated medical content found error rates of roughly 60% on dates and times and a comparably high rate on numeric and dosage information, every error delivered in grammatically perfect prose with no warning marker. The number is the place where the engine's confidence is most decoupled from its correctness, and it is therefore the place where your verification must be most mechanical. You do not read the number and judge whether it feels plausible. You put the source number and the target number side by side and confirm they are the same number expressed in the right locale convention.

A wrong number reads with exactly the same confidence as a right one. Grammar cannot save you here. Only a digit-by-digit comparison against the source can.

The "Preferred" Term That Overrides the Approved One

The third failure mode is subtler and more insidious because it is not a single dramatic error but a quiet, consistent substitution that propagates across an entire file. The client has an approved term, recorded in the termbase, the controlled glossary of mandatory approved terms for this account. The engine, trained on general text where a more common synonym dominates, "prefers" that synonym and substitutes it segment after segment, calmly, fluently, and uniformly.

Understand why this happens mechanically and you will stop being surprised by it. The engine has no knowledge of your client's termbase unless that termbase has been engineered into its process. Left to its own statistics, it reaches for the term that appears most often in its training data, because that is the most probable token. If the client's approved term for their product is an uncommon coinage or a deliberately specific word chosen to avoid a competitor's trademark or a regulatory ambiguity, the engine has seen the common synonym ten thousand times more often and will reach for it every time. This is not the engine making an error in the way the negation was an error. It is the engine being statistically correct about general language and specifically wrong about your client's rules. The two are not the same thing, and the engine cannot tell the difference because it does not know the rules exist.

The worked example and its consequence. A medical-device client mandates the term "infusion set" for their product and has built that term into every piece of regulatory documentation, every prior translation in the translation memory (the TM, the database of approved past translations), and every marketing asset. The engine, fluent and confident, renders it as "drip line" or "IV tubing" because those are the common terms in its training data. Across a four-hundred-segment file the wrong term appears two hundred times, perfectly grammatical every time, and the file now contradicts the client's regulatory filings, fails their terminology conformance check, and forces a full re-edit. In a quality framework this registers as a terminology error, and depending on the regulatory context it can escalate from a Major to a Critical, because in a regulated submission an inconsistent device name is not a stylistic nuisance, it is a compliance failure. The defense is not vigilance, because two hundred fluent substitutions will wear down any reader's attention. The defense is enforcement: the approved term is checked against the termbase programmatically and every deviation is surfaced, so that consistency is a control rather than a hope.

Why Term Drift Is Worse Than a Single Error

A dropped negation is one error in one segment. Term drift is the same error replicated everywhere the term appears, which means it scales with the size of the file and it poisons the translation memory if the file is accepted, so that the wrong term leverages into future projects and the contamination compounds. A single Critical error fails one file. A drifted term that enters the TM fails files you have not even received yet. That is why terminology fidelity is treated as a pipeline-level control and not a per-segment judgment call. You are not protecting one delivery. You are protecting every future delivery that will draw on the same memory.

Dropped Clauses and Added Content

The remaining failures are the clause-level versions of omission and hallucination, and they are where the legal consequence lives. A negation flips a sentence; a dropped clause changes a contract.

The Omitted Clause

An engine optimizing for a fluent path can find a route through a complex sentence that simply skips a subordinate clause, a qualifier, a condition, or an exception. The result is a shorter, cleaner, grammatical target that is missing part of the source's meaning. Nothing announces the loss. The worked example and its consequence. A liability clause reads "The supplier shall be liable for direct damages, except where such damages result from the customer's misuse of the product." The engine, finding a fluent path, renders only "The supplier shall be liable for direct damages." The exception, the entire protection the supplier negotiated, is gone. The sentence is grammatical, confident, and complete-looking. It has also stripped a carve-out worth potentially millions in a dispute, and no reviewer reading the target alone would sense that anything is absent, because absence has no shape. This is why the discipline for legal and obligation-bearing content is mandatory back-translation against the source clause by clause: you confirm that every condition, every exception, every "provided that" and "subject to" in the source has a counterpart in the target. You are not reading for sense. You are taking inventory.

The Added Clause

Hallucination at the clause level is the engine adding a qualifier, a condition, or an entire assertion that the source never contained, usually because the engine is "completing" the sentence in the most probable way and the most probable completion in its training data contained material your specific source did not. The worked example and its consequence. A source instruction reads "Store the medication in a cool place." The engine, having seen the storage instructions for thousands of medications, renders "Store the medication in a cool, dry place away from direct sunlight and out of reach of children." Three conditions appeared that were never in the source. In a marketing string this might be harmless padding. In a regulated drug label it is unapproved content, a deviation from the authority-approved text, and it can invalidate the label and trigger a regulatory hold, because in regulated content you may translate only what was approved, not what is generally true. The engine cannot tell the difference between "faithful to this source" and "consistent with similar sources it has seen," and it defaults to the latter because the latter is more probable. Added content is the failure mode that catches linguists who trust an engine that is "usually right," because the addition is usually plausible and occasionally fatal.

A dropped clause has no shape in the target and a hallucinated clause looks like helpfulness. The only defense for obligation-bearing content is a clause-by-clause inventory against the source, never a read for sense.

The Shared Mechanical Root

Step back and notice that every failure in this catalogue, the dropped negation, the corrupted number, the swapped term, the omitted clause, the added clause, traces to the same two mechanical causes. Understanding them is what turns a checklist into judgment, because once you understand the cause you can predict where the next error will hide.

The first cause is next-token prediction. The engine builds the target one token at a time, each token chosen as the most probable continuation given everything generated so far plus the source. It does not plan the whole sentence and verify it against the source. It commits to each word as it goes, and once it has committed to a fluent path it follows that path even when the path diverges from the source, because reversing would require a faculty it does not have: a comparison of the finished output back against the source's meaning. The engine is a brilliant improviser with no editor.

The second cause is the fluency prior, the deep statistical bias toward the most common, most probable, most natural-sounding phrasing. This bias is the engine's greatest strength and the exact source of every failure mode in this lesson. The fluency prior is why the negation drops, because affirmative phrasing is more common. It is why the term drifts, because the common synonym is more probable. It is why the clause gets added, because the fuller, more typical version of the sentence is what the engine has seen most. The engine is not malfunctioning when it produces these errors. It is functioning perfectly. The errors are the fluency prior doing precisely what it was trained to do, applied to a case where the most probable output and the faithful output are not the same thing.

Why This Makes the Error Silent

Put the two causes together and you get the defining property of every failure in this lesson: it is silent. The engine has no uncertainty signal that fires when fluency and faithfulness diverge, because the engine cannot perceive the divergence. From inside the generation process, producing "the device should be used" is exactly as confident an act as producing "the device should not be used." Both are high-probability continuations. There is no flicker of doubt, no asterisk, no change in tone or register between the correct output and the catastrophic one. This is the deepest reason "the engine wrote it" is never a defense and accountability never transfers to the machine: the machine is structurally incapable of knowing when it is wrong, so the knowing is your job, and a job you cannot delegate to the thing that cannot do it is a job you own completely.

Reading for the Lie, Not the Flow

Everything above converges on a single change in how you read machine output, and it is the hardest habit in this profession to build because it runs against twenty years of trained instinct. You were taught to read for flow, for register, for the music of natural language, and your eye learned to treat fluent prose as a signal of competence. That instinct is now a liability. The fluent surface is exactly the camouflage the dangerous error hides behind. The discipline is to stop reading the target as prose and start reading it as a claim about the source that must be verified.

Concretely, this means a different reading protocol for high-consequence content. You do not read the target sentence and ask "does this sound right?" You read the source sentence, identify its load-bearing elements, every negation, every number, every unit, every approved term, every clause and condition and exception, and then you confirm each one survived the crossing into the target. You are auditing, not appreciating. The fluency of the target is not evidence of its correctness; if anything it is a reason for heightened suspicion, because the smoother the prose, the more completely a buried error is hidden. The linguist who internalizes this stops being the machine's cleanup crew and becomes the one thing the machine structurally cannot be: the faculty that compares the output back against the source and the rules, and refuses to ship the perfect-reading lie.

Where to Aim Your Attention

You cannot audit every token of every segment with equal intensity under a real deadline, and you do not have to. The mechanical understanding tells you where to spend your scarce attention. Negations, numbers, units, dosages, dates, approved terms, and obligation-bearing clauses are the high-density, high-consequence, low-visibility elements where fluency and faithfulness are most likely to have quietly diverged. A marketing adjective that drifts costs you nothing. A dropped "not" in a contraindication costs a life. You aim your scrutiny at the elements whose corruption is both likely and catastrophic, and you let the engine's fluency carry the low-stakes prose. That triage, knowing which elements to check mechanically and which to read for sense, is the difference between a verifier who is fast and safe and one who is merely fast.

Key Takeaways

• Hallucination and omission are opposite crimes. Hallucination is the engine adding meaning the source never contained, an invented number or an unrequested clause. Omission is the engine removing meaning the source did contain, a dropped "not" or a vanished exception. You catch invention by reading the target, but you catch erasure only by comparing the target against the source, because a deleted clause leaves no scar.
• The dropped negation is the canonical silent Critical error, an error severe enough to fail the entire file, because a single low-weight "not" inverts a sentence's truth value while the fluency prior, the engine's bias toward common affirmative phrasing, smooths right over it. Every negation in high-consequence content is a mandatory checkpoint.
• Numbers fail through digit transposition, decimal drift, unit flips, failed or wrong conversions, separator inversion across locales, and pure hallucination on thin input. A wrong number reads with exactly the same confidence as a right one, so grammar cannot catch it and only a digit-by-digit comparison against the source can. LLM medical-content studies found roughly 60% error rates on dates and times.
• Term drift is the engine substituting a common synonym for the client's approved termbase term, fluently and uniformly, across an entire file. It is worse than a single error because it scales with file size and poisons the translation memory, contaminating future projects. The defense is programmatic enforcement against the termbase, not human vigilance.
• Dropped clauses and added clauses are the legal-consequence failures. An omitted exception strips a negotiated protection invisibly; an added condition inserts unapproved content into a regulated label. The only defense for obligation-bearing content is a clause-by-clause inventory against the source, never a read for sense.
• Every failure traces to two mechanical causes: next-token prediction, which commits to a fluent path word by word with no editor to verify it against the source, and the fluency prior, the statistical bias toward the most probable phrasing. The errors are not malfunctions; they are the engine working perfectly in cases where the most probable output and the faithful output differ.
• The defining property of all of these errors is silence. The engine has no uncertainty signal when fluency and faithfulness diverge, because it cannot perceive the divergence, so it produces the catastrophic output with exactly the confidence of the correct one. That is why accountability cannot transfer to a machine that is structurally incapable of knowing when it is wrong.
• Stop reading machine output for flow and start reading it as a claim about the source that must be verified. Aim your scarce attention at the high-density, high-consequence, low-visibility elements, negations, numbers, units, terms, and clauses, and audit them mechanically against the source, because the smoother the prose, the more completely a buried error is hidden.