It is 14:40 on a Thursday and Leila is twelve minutes from sending a French batch back to the project manager when she decides to run one more check. The content is a set of clinical-trial consent paragraphs, and her large language model (LLM), the general text-prediction assistant she now keeps open beside her computer-assisted translation (CAT) tool, has produced French that reads like it was written by a careful native speaker. One sentence in particular is beautiful: balanced clauses, the right register, not a comma out of place. The English source said the patient "must not stop taking the medication without first consulting the study physician." The French says the patient "doit arrêter de prendre le médicament après avoir consulté le médecin de l'étude," which means the patient must stop taking the medication after consulting the physician. The negation is gone. The meaning has flipped from a prohibition into an instruction, and it flipped inside a sentence so fluent that Leila's eye slid right over it on the first two reads. She catches it only because she had built a habit: before she trusts a single rendering, she forces the model back to the source and makes it prove that the output means what the original meant. This lesson is about that habit, and about the specific techniques that turn a fluent, confident, free-associating model into a disciplined instrument anchored to the segment in front of it.

Why the Model Drifts Off the Source

To anchor a model to a source you first have to understand why it floats away from one in the first place. The drift is not a bug you can file a ticket against. It is a direct consequence of what the machine is and how it was built, and once you see the mechanism you stop being surprised by it and start designing around it.

An LLM is a next-token predictor. It was trained to continue text in the most probable way, learning from an ocean of human writing what usually comes next. When you ask it to translate, it is not consulting a dictionary and a grammar and mapping the source onto the target the way a junior translator was taught to. It is generating the most plausible-sounding target-language text given everything it has seen, lightly steered by the source you provided. The source is an influence on its output, not a constraint the way a contract clause is a constraint. The model's deepest instinct is to produce fluent, natural, expected language. Faithfulness to your specific segment is a weaker pull than fluency, and when the two compete, fluency usually wins.

This is why the failures have a signature. The model does not produce garbled nonsense that screams "I am wrong." It produces smooth, idiomatic, confident prose that happens to drift from the source in small, high-consequence ways. It rounds an awkward source sentence into a graceful one and loses a qualifier in the rounding. It encounters a double negative and simplifies it into a single positive because that reads better. It meets an unfamiliar term and substitutes a more common near-synonym because the common word is more probable. It hits an ambiguous pronoun and picks the reading that makes the smoothest sentence, not the reading the source actually supports. Every one of these is the model doing exactly what it was trained to do: prefer the fluent continuation.

The model's native loyalty is to fluent language, not to your source segment. Accuracy is something you have to impose; it is never the default.

The Three Drift Shapes You Will Meet Most

Across thousands of segments, the drift collapses into three recurring shapes, and naming them is the first step to catching them.

• Omission. The output drops something the source carried: a negation, a qualifier ("only," "except," "up to"), a condition ("if the symptoms persist"), a unit, a date, a party name in a contract. The output reads complete because the model wrote a complete-sounding sentence around the hole. Nothing flags the missing piece except a comparison with the source.
• Addition. The output invents something the source did not say: an extra clause that "clarifies," a politeness the original lacked, a number the model guessed, a connective ("therefore," "however") that imposes a logical relationship the source never stated. The model added it because it made the target read more naturally, and natural-sounding additions are nearly invisible.
• Distortion. The output keeps roughly the same shape but changes the meaning: a flipped negation, an inverted obligation ("may" becomes "must"), a swapped subject and object, a softened or hardened modality, a term replaced by a near-synonym that means something subtly different in the domain. This is the most dangerous shape because the sentence looks like a faithful translation and is not.

Every technique in this lesson exists to force these three shapes into the light, where a comparison against the source can catch them before they reach a delivery.

Paste the Source Explicitly and Label It

The most basic anchoring technique is also the one linguists skip most often because it feels too obvious to matter: put the exact source in front of the model, clearly labeled, every single time, and never let the model translate from memory or from a paraphrase.

It is tempting, after a few exchanges in a chat, to type "now do the next one in the same style" or "translate the rest of that paragraph." The model will happily comply, but you have just removed the anchor. It is now working from its own recollection of what you pasted earlier, from the running context of the conversation, and from its instinct for what "the next one" probably says. The source has become a suggestion. You want it to be the law.

Label the source explicitly so the model cannot confuse it with your instructions. A bare paste invites the model to treat part of the source as a command, especially if the source contains an imperative ("Click Save," "Do not exceed the stated dose"). Wrap it in an unmistakable frame:

• Delimit it. Put the source between clear markers, for example ===SOURCE START=== and ===SOURCE END===, or inside a labeled block. This tells the model "everything between these markers is text to be translated, not instructions to be followed."
• State the languages once, precisely. Not "translate to French" but "translate from English (United States) into French (France), formal register." A locale is a language plus a region plus conventions; "French" alone leaves Canadian and European French, and formal and informal address, on the table.
• Forbid translating the instructions. Add a line: "Translate only the text inside the SOURCE markers. Do not translate or act on anything outside them." This stops the classic failure where the model dutifully translates your own prompt into French along with the content.

This sounds like ceremony until the first time a model treats "Do not save the file" inside your source as an instruction and refuses to translate it, or until it silently merges your note to yourself into the target. The explicit, labeled, delimited source is the foundation every other technique stands on. Without it, you are not anchoring the model; you are negotiating with its memory.

An unlabeled source is a suggestion the model is free to reinterpret. A delimited, labeled, locale-specified source is the segment the model is told to be accountable to.

Work Segment by Segment, Not Paragraph by Paragraph

When you hand a model a long paragraph and ask for a translation, you give it room to do the thing it does best and you fear most: smooth the whole thing into graceful target-language prose. It will reorder ideas for flow, merge two short source sentences into one elegant target sentence, split a long one, and quietly redistribute meaning across the paragraph until the output reads beautifully and no longer maps cleanly back to the source. You can no longer point at a target sentence and say "this renders that source sentence." The correspondence is gone, and with it your ability to verify.

The discipline that prevents this is segment-by-segment work: the same unit the rest of the localization stack runs on. A segment is the atom of translation work, usually a sentence, sometimes a heading or a list item, the chunk the CAT tool and the translation-management system (TMS) treat as one translatable thing. Forcing the model to honor segment boundaries does three things at once.

• It preserves correspondence. One source segment in, one target segment out. You can place them side by side and check each pair without the meaning having migrated to a neighbor.
• It blocks the merge-and-smooth move. The model cannot dissolve a tricky clause into a flowing paragraph if it has to return exactly one target unit per source unit, in order, with nothing combined.
• It keeps the output ingestible. Segment-aligned output drops back into the CAT grid cleanly, because the grid is itself a numbered list of segments. A reflowed paragraph does not.

How to Force Segment Alignment in the Prompt

Give the model the source already split, numbered, one segment per line, and demand the output in the same numbering:

• "Here are 6 numbered source segments. Return exactly 6 numbered target segments. Do not merge, split, reorder, or renumber. If a source segment is empty, return an empty target segment with the same number."
• "Translate each segment independently of the others except for terminology consistency. Do not let the translation of segment 4 change the wording of segment 2."
• "Preserve every placeholder, tag, and number exactly as it appears in its segment." (A placeholder is a code token like %s or {count} that the running software fills in at runtime; the model must never translate or move it.)

The payoff is that verification becomes mechanical. When source segment 4 and target segment 4 sit on the same row, the omission, addition, or distortion in segment 4 has nowhere to hide. You stopped asking the model to write you a nice paragraph and started asking it to render a list of segments you can audit one by one. That is the difference between a draft you have to trust and a draft you can check.

Demand a Back-Translation and Read It Against the Source

You do not read the target language as natively as you read your source, or you would not be using a model in the first place. So how do you catch a flipped negation in a language you are post-editing rather than authoring? You make the model translate its own output back into the source language and you read that round trip against the original.

A back-translation is exactly that: take the target you just produced, translate it back into the source language as literally as possible, and compare it to the source you started with. The two will never be word-identical, and they are not supposed to be. What you are hunting for is meaning that survived the trip and meaning that did not. If the source said "must not stop" and the back-translation says "must stop," you have found Leila's flipped negation without needing to read French at all. The round trip surfaced it in the language you read fluently.

The technique has a precise recipe, because a sloppy back-translation hides errors instead of exposing them.

• Ask for a literal, not idiomatic, back-translation. "Translate this French back into English as literally as the grammar allows, preserving structure, even if it sounds awkward. Do not smooth it. Do not improve it." A fluent back-translation re-smooths the very drift you are trying to catch; an awkward literal one preserves it.
• Do it in a separate step, ideally a fresh context. If you ask the same model in the same breath to translate and then back-translate, it can "remember" the source and reproduce it rather than honestly re-deriving it from the target. A back-translation that just echoes the original source proves nothing. Paste only the target and ask for the reverse, so the round trip is genuine.
• Read for the high-consequence elements first. Negations, numbers, units, dates, named parties, modal verbs (must, may, shall, should), and conditions. These are where distortion costs the most and where a back-translation earns its keep.

A back-translation does not prove the target is correct. It proves whether the meaning made the round trip, which is exactly the thing fluency hides and exactly the thing that ships an error.

One honest limitation: a back-translation can mask an error if the same model makes the same mistake in both directions, or if a genuinely ambiguous source resolves the same wrong way twice. It is a strong net, not a perfect one. Treat a clean back-translation as a passed check, not a guarantee, and reserve your sharpest attention for the highest-liability segments regardless of what the round trip says.

Run an Explicit Faithfulness Check

The back-translation makes you the judge. A faithfulness check makes the model state its own case so you can audit it. Instead of asking only for a translation, you ask the model to translate and then to interrogate its own output against the source, line by line, and report what it finds.

The instinct to distrust this is healthy: the model that made the error is now grading the error, and a model is perfectly capable of confidently declaring a wrong translation faithful. So the faithfulness check is not a verdict you accept. It is a structured second pass that surfaces candidates for your attention and, just as importantly, makes the model's reasoning inspectable. A useful faithfulness-check prompt asks for a table or list, segment by segment, with columns for the source meaning, the target meaning, and a faithfulness judgment:

• "For each segment, state in English what the source asserts and what your target asserts. If they differ in any way that changes meaning, mark it MISMATCH and explain the difference in one line."
• "Specifically verify: every negation, every number, every unit, every date, every named entity, every modal verb, and every conditional. Confirm each is preserved, or flag it."
• "Do not assume your own translation is correct. Re-derive the target's meaning from the target text alone, as if a different translator had produced it."

That last instruction is the lever. By telling the model to treat the target as a stranger's work, you push it out of the defensive posture of justifying itself and into the auditor's posture of checking. The output is far more likely to surface a real mismatch. When the model returns a MISMATCH, you have a lead to investigate. When it returns "all faithful," you have not been given permission to relax; you have been given a claim to spot-check against the highest-risk segments yourself.

Why Two Checks Beat One

The back-translation and the faithfulness check catch overlapping but not identical errors, which is why disciplined linguists run both on high-liability content. The back-translation is good at surface-level meaning flips you can read in your source language: the negation, the number, the inverted obligation. The faithfulness check is good at structural and terminological issues the model can articulate: a dropped condition, a softened modality, a term that does not match the brief. Running both on a consent form, a dosage instruction, or an indemnity clause is cheap insurance against the one silent critical error that costs a life or a lawsuit. Running neither on a throwaway internal string is the right call. The point is to match the verification effort to the consequence, not to ritualize it.

Constrain Additions, Omissions, and Ambiguity

Catching drift after the fact is good. Telling the model not to drift in the first place is better, and you do it with explicit constraints in the prompt that fight each of the three drift shapes directly. These are not polite requests; they are the operating rules you give the instrument before it touches the segment.

Constrain Against Addition

The model's urge to "help" by clarifying is the source of most additions. Forbid it in plain terms:

• "Translate only what the source says. Do not add explanations, clarifications, examples, or connective words that are not in the source."
• "Do not improve the source. If the source is terse, ambiguous, or awkward, the target should be equally terse, ambiguous, or awkward. Your job is fidelity, not editing."
• "Do not insert politeness, hedging, or softening the source does not contain." (Many models will add a courtesy register that the original clinical or legal text deliberately lacks.)

Constrain Against Omission

Omission is harder to forbid because the model does not know it is dropping something. The defense is to make completeness checkable:

• "Preserve every element of meaning. In particular, preserve every negation, qualifier, condition, exception, number, unit, and date. Do not simplify a double negative into a single positive."
• "If the source contains a list, the target must contain the same number of list items in the same order."
• "After translating, list any source word or phrase you found difficult to render and confirm it appears in the target." (This turns a silent drop into a visible note.)

Require It to Flag Ambiguity Rather Than Resolve It Silently

The single most valuable constraint, and the one most linguists never think to ask for, is this: when the source is genuinely ambiguous, the model must stop and flag the ambiguity instead of silently choosing the reading that produces the smoothest sentence. Left to itself, the model resolves every ambiguity invisibly, and you never learn that a decision was made on your behalf.

• "If a source segment is ambiguous (a pronoun with an unclear antecedent, a term with more than one domain meaning, a sentence that could be read two ways), do not pick one silently. Translate your best reading, then add a flag: AMBIGUITY, the two possible meanings, and which you chose and why."
• "If you cannot tell whether a word is a product name, a placeholder, or ordinary text, flag it rather than guessing."
• "If the source appears to contain an error (a wrong unit, an impossible date, a contradiction), do not silently correct it. Translate it faithfully and flag it as a possible source error for human review."

That last rule matters because correcting a suspected source error is a decision only a human with the brief and the client relationship can make. The model's job is to surface the question, not to answer it on its own authority. A model that flags "the source says 50 mg here and 5 mg two segments earlier, please confirm" has just done something more valuable than a flawless translation: it has handed you the exact place where human judgment is required.

An ambiguity the model flags is a question you get to answer. An ambiguity the model resolves silently is a decision it made for you, in the dark, optimized for fluency.

Worked Examples Where Anchoring Catches the Drift

Techniques are abstract until you watch them catch something. Here are four cases, drawn from the kinds of content that fill a real queue, where anchoring to the source caught a fluent, confident error that the prose alone would have shipped.

Example 1: The Flipped Negation

This is Leila's consent form. The source: "Patients must not discontinue the study medication without first consulting the study physician." The model's first French output was fluent and meant "patients must discontinue the study medication after consulting the physician." The negation and the conditional both collapsed: "must not without first" became "must after." Leila did not catch it by reading the French, which was flawless. She caught it with a literal back-translation, which came back as "patients must stop the medication after consulting the physician." Read against the source, the divergence was glaring. The fix was not just to re-translate; it was to add the constraint "preserve every negation and every conditional exactly, even if the result is less elegant," and re-run. In medical consent content, this is precisely the category where LLM error rates run high and a flipped instruction is not a Minor stylistic note but a Critical error that one occurrence fails the file.

Example 2: The Invented Clarification

A software UI string: "Restart required." The model, translating into German, produced the equivalent of "A restart of the system is required to apply the changes." Grammatical, natural, and longer than the source by an entire clause the source never contained. The addition came from the model's training: UI strings about restarts usually mention applying changes, so the model supplied the expected continuation. Two problems. First, "to apply the changes" is an assertion the source did not make and may be false in this context. Second, the expanded German blew past the UI's character budget and would truncate on screen. The faithfulness check caught it: asked to state what the source asserts versus what the target asserts, the model itself reported "source asserts a restart is required; target additionally asserts the restart applies changes," a self-declared MISMATCH. The constraint "translate only what the source says, add nothing, and stay within the source's length where possible" fixed it.

Example 3: The Term the Model Preferred

A medical-device manual referred consistently to the "actuator." The client's approved termbase mandated a specific target term for it. The model, across a 40-segment batch, rendered "actuator" three different ways, drifting to more common near-synonyms because they were more probable in general text. Each individual rendering read perfectly; the inconsistency only appeared across the batch. The segment-by-segment, numbered output made the drift visible: scanning the target column for the device term showed three different words where there should have been one. Anchoring here meant pasting the approved term into the prompt as a hard rule ("the source term 'actuator' must always be rendered as [approved term], never a synonym, in every segment") and re-running. Terminology consistency is not a preference; it is an accuracy requirement, and a model left unconstrained will trade it away for fluency every time.

Example 4: The Ambiguous Pronoun the Model Resolved Silently

A contract sentence: "The Vendor shall indemnify the Client against claims arising from its negligence." Whose negligence, the Vendor's or the Client's? English leaves it ambiguous; the target language being translated into required choosing a possessive that commits to one party. The model picked the Vendor's, silently, because that produced the smoother sentence, and in this case it happened to match the drafter's intent. But it might not have, and the model gave no sign a decision had been made. With the ambiguity constraint in place, the model instead flagged: "AMBIGUITY: 'its' could refer to the Vendor or the Client. I have translated it as the Vendor's negligence; please confirm." That flag turned an invisible, high-stakes guess into a one-line query to the client, exactly the kind of question a professional translator raises and an unconstrained engine buries. The legal exposure of an inverted indemnity clause is enormous, and the difference between catching it and shipping it was a single sentence in the prompt asking the model to flag rather than resolve.

Building Anchoring into a Repeatable Habit

None of these techniques is hard. The hard part is doing them every time, especially under a deadline that assumes the machine already did the thinking. Vigilance does not scale; habits and checklists do. The goal is to make anchoring the default shape of the interaction, not a special effort you summon when you happen to feel suspicious, because the dangerous segment is precisely the one that does not feel suspicious.

Fold the techniques into a small, ordered routine you run on every batch, scaled by the content's consequence:

• Always: paste the labeled, delimited, locale-specified source; work segment-by-segment in numbered, aligned output; constrain against addition and omission; require the model to flag ambiguity and suspected source errors.
• On medium-consequence content: add a faithfulness check, reading the model's self-audit as a list of leads rather than a verdict.
• On high-liability content (medical, legal, financial, life-safety): add a literal back-translation in a fresh context, read the round trip against the source for negations, numbers, units, dates, parties, and modals, and never let a clean automated check substitute for your own read of the highest-risk segments.

Notice what this routine does to your relationship with the model. You are no longer asking it for a translation and hoping. You are running an instrument with known failure modes, with guards installed for each one, and with verification steps that turn the model's own fluency, the thing that hides its errors, into a checkable artifact. The model still does the fast first pass. You still own the meaning, the terminology, the safety, and the delivery. "The engine wrote it" remains no defense when a Critical error ships, which is exactly why you built the guards. The accountability never moved; you just stopped pretending the fluent surface was evidence of accuracy.

Leila sent her French batch eleven minutes later than she planned, with the flipped negation fixed, one ambiguity flagged for the client, and a back-translation log attached. The eleven minutes were the cheapest insurance she bought all week. The version she almost sent was beautiful, confident, and would have told vulnerable patients the opposite of what their physicians intended. The version she sent meant what the source meant. That gap, between fluent and faithful, is the entire job, and anchoring to the source is how you close it on purpose instead of by luck.

Key Takeaways

• An LLM's deepest instinct is fluency, not fidelity. Accuracy against a source is something you impose with technique; it is never the model's default, and when fluency and faithfulness compete, fluency usually wins.
• Drift collapses into three shapes: omission (a dropped negation, qualifier, or number), addition (an invented clarification or connective), and distortion (a flipped negation or inverted obligation). Each technique exists to force one of these into the light.
• Paste the source explicitly, delimited and labeled, with the exact locale and register stated, and forbid the model from translating or acting on your instructions. An unlabeled source is a suggestion the model is free to reinterpret.
• Work segment-by-segment in numbered, aligned output so one source unit maps to one target unit. This blocks the merge-and-smooth move and makes verification mechanical instead of a matter of trust.
• Demand a literal (not idiomatic) back-translation in a fresh context and read the round trip against the source for negations, numbers, units, dates, parties, and modals. It catches meaning that did not survive the trip, but it is a strong net, not a guarantee.
• Run an explicit faithfulness check that makes the model re-derive the target's meaning as if a stranger wrote it, and flag mismatches. Treat its "all faithful" as a claim to spot-check, never as a verdict you accept.
• Constrain the model up front: add nothing, omit nothing, and flag ambiguity and suspected source errors rather than resolving them silently. An ambiguity the model flags is a question you answer; one it resolves silently is a decision made for you in the dark.
• Match verification effort to consequence. Full back-translation plus faithfulness check on a consent form or an indemnity clause is cheap insurance against a Critical error; the same ceremony on a throwaway internal string is waste. The fluent error is the dangerous one precisely because it does not feel suspicious.