Sofia is a senior reviser at a language-service provider, an LSP, the kind of company a brand hires to ship its words in twenty languages, and she has just lost an afternoon to a single word. The client is a German power-tool manufacturer; the content is a product-catalog refresh, English into German; the engine, a large language model, an LLM, a general-purpose text-prediction system, has pre-translated every segment before she opened the file. Segment after segment, the model has rendered the client's flagship cordless driver as "Akkuschrauber." It reads perfectly. It is grammatical, idiomatic, the word a native speaker would reach for. It is also wrong, because this client decided years ago, in a style guide nobody told the model about, that their product line is always "Akku-Bohrschrauber," never the shorter generic term, because "Bohrschrauber" signals the drilling function that differentiates their tool from a screwdriver. The model did not invent a bad word. It invented a confident, fluent, native-sounding word that violates a decision the client made and pays Sofia's company to enforce. Multiply that across forty segments and three product families, and she is now hand-correcting the same approved-term miss the engine will make again on the next file, and the file after that, forever, because the engine has never once seen the client's approved language. It answered from everything it learned on the open web, which is to say from everyone else's German, not from this client's German. This lesson is about closing that gap at the root: feeding the engine the client's own translation memory, termbase, and style guide so that when it drafts, it drafts from the approved language instead of the average of the internet. The technique has a name borrowed from the wider AI world, and learning to use it well is what separates a linguist who cleans up after a generic engine from one who runs an engine that already knows the house style.

What Grounding Actually Means for a Linguist

Start with the word, because the rest of the lesson hangs on getting it precise. Grounding means constraining what an AI engine produces by supplying it, at the moment it works, with specific source material it must answer from, instead of letting it answer from the vast, undifferentiated mass of text it learned during training. An ungrounded model answers a translation request from its parameters: the statistical residue of everything it read on the open web, which is fluent, broad, and belongs to no one in particular. A grounded model answers the same request with your documents placed in front of it, so its output is pulled toward your approved language rather than the internet's average. The shift is from "translate this the way the web would" to "translate this the way our materials say we translate it."

The mechanism that does the grounding has a name you will hear constantly: RAG, retrieval-augmented generation. Break the phrase into its three working parts, because each names a real step. Retrieval is the act of going to a store of your own documents and pulling out the handful of pieces most relevant to the segment in front of you right now. Augmented means those retrieved pieces are added to the prompt, placed alongside the source segment as context the model can see. Generation is the model then producing its translation while looking at that context. So RAG is a three-beat loop: for this segment, find the relevant approved language, put it in front of the model, and have the model translate with it visible. The model is not retrained, not fine-tuned, not permanently changed. It is simply shown the right reference material at the right moment, the way you would hand a junior translator the client's glossary and three past translations of similar sentences before asking them to translate the fourth.

That analogy is worth holding onto, because it makes the whole concept concrete. Imagine a new freelancer joining the project. You would not sit them down and say "translate this catalog" with nothing else. You would give them the client's termbase, point them at the translation memory so they can see how the company has rendered similar sentences before, and hand them the style guide that says "always Akku-Bohrschrauber, formal register, no contractions." Grounding is doing exactly that for the engine. The freelancer's talent is their training; the client's materials are the context that points that talent in the right direction. Grounding pairs a capable generalist with your specific approved language, on every single segment, automatically.

Grounding is the difference between an engine that translates the way the internet would and one that translates the way your client's approved materials say you do. RAG is the machinery that puts those materials in front of the model at the moment it works.

The Three Assets You Are Grounding On

A linguist already owns the materials grounding needs, which is the quiet good news of this whole topic. You are not building new infrastructure; you are pointing the engine at assets you maintain anyway. Three of them carry the load, and it is worth defining each precisely, because grounding treats them differently.

A translation memory, a TM, is a database of past source segments paired with their approved, human-verified translations, accumulated across every project for a client. When the catalog says "Charge the battery fully before first use," the TM may already hold that exact sentence, or one ninety percent like it, with the German the client signed off on last year. The TM is your record of how this client's content has actually been translated, sentence by sentence, and it is the richest ground truth you have, because it is not a rule about how to translate but an example of a translation already accepted.

A termbase, also called a glossary, is a database of approved source-to-target term pairs the client requires used exactly: "cordless driver" maps to "Akku-Bohrschrauber," "occlusion" maps to a specific clinical word, "Submit" maps to one fixed button label. Where the TM holds whole sentences, the termbase holds the load-bearing words and the one rendering each is allowed to have. It is the client's vocabulary, the small set of terms where a synonym, however fluent, is an error.

A style guide is the document of standing conventions for the client and the locale: register (formal or informal), the formality pronoun to use, treatment of dates and numbers, capitalization, tone, contractions, brand voice, and the rules that are not about individual terms but about how everything is written. Where the termbase says which word, the style guide says how to write. It is the client's voice expressed as instructions.

These three assets answer three different questions, and grounding lets the engine consult all three at once: the TM answers "how have we translated sentences like this before," the termbase answers "what is the one approved word for this thing," and the style guide answers "what register, format, and voice does this client demand." An engine grounded on all three is no longer guessing at the house style. It is reading it.

Why an Ungrounded Engine Drifts by Default

To understand why grounding helps, you have to understand precisely what an ungrounded engine is doing, because the problem is not that the engine is bad. The problem is that the engine is good at the wrong target. An LLM or a neural machine-translation engine, an NMT system, is trained to produce the most probable, fluent target text for a given source, where "probable" is computed across the enormous and generic corpus it learned from. That corpus is everyone's writing. So the engine's idea of the right German for "cordless driver" is the German that is most common across the whole internet, which is exactly the generic "Akkuschrauber" Sofia kept correcting. The engine is not making a mistake by its own lights. It is hitting its target dead center. Its target is just not your client's approved language; it is the average of all language.

This produces a characteristic failure that the whole program calls drift: the engine reaches, fluently and confidently, for the common rendering instead of the approved one. Drift is not a single dramatic error. It is a steady pull toward the generic, showing up as the wrong-but-fluent term, the slightly-off register, the date format that belongs to the wrong locale, the brand voice flattened into neutral prose. Each instance reads perfectly. None of them trips the eye, because the engine's defining strength is fluency, and a fluent error is the dangerous one precisely because it does not look like an error. Drift is the engine being excellent at producing average language when your job requires it to produce specific language.

The Asymmetry: Fluent but Unapproved

Sit with the asymmetry, because it is the heart of why this matters. The thing an ungrounded engine produces is not gibberish you would catch at a glance. It is polished, native-sounding text that happens to disagree with a decision your client made and pays you to honor. "Akkuschrauber" is not wrong German. It is wrong for this client, and the only way to know that is to have seen the client's materials, which the engine never has. The error lives in the gap between "correct language" and "approved language," and that gap is invisible to a system that only knows correct language in general.

This is why ungrounded post-editing is so expensive and so error-prone. The post-editor is the only thing in the pipeline that knows the approved language, and they are being asked to catch every place the fluent-but-unapproved rendering slipped through, on a file where everything reads fine. They are hunting for errors that, by construction, do not look like errors. They will miss some. The ones they miss ship. And the ones they catch, they catch by hand, the same correction over and over, because the engine that produced the miss has no memory of the correction and will reproduce the miss on the next file. Grounding attacks this at the source: instead of asking the post-editor to repair the drift after the fact, it puts the approved language in front of the engine before the draft exists, so the draft starts closer to approved and the post-editor's job shrinks from "catch every silent drift" to "verify a draft that already tried to honor the house style."

An ungrounded engine is not bad at German; it is excellent at the internet's German. Drift is the steady pull toward the common rendering, and it is dangerous precisely because every instance is fluent enough to pass an unaided eye.

How Grounding Feeds Your Assets Into the Engine

Now move from the why to the how, because grounding is not a single technique but a small family of them, and a linguist should know which lever applies to which asset. The unifying idea is constant: get the relevant approved language in front of the model at the moment it generates. The methods differ in how that material gets there and how forcefully it constrains the output.

TM Leverage: The Grounding You Already Do

The oldest form of grounding is one you have used for years without calling it that: translation-memory leverage inside the CAT tool, the computer-assisted-translation environment where a linguist edits target text segment by segment. When you open a file and the tool shows you a hundred-percent match or a fuzzy match, a partial match scored by how close the new source is to a stored one, it has performed a retrieval: it searched the TM, found the closest prior segment, and put its approved translation in front of you. That is grounding, done by the CAT tool, for the human. Modern pipelines extend the same move to the engine: before the model translates a segment, the pipeline retrieves the closest TM matches and places them in the prompt as examples, so the model drafts having just seen how the client rendered near-identical content. The model is, in effect, told "here is how this exact sentence, or one almost like it, was approved before; translate the new one consistently with that." TM-grounded MT is the engine drafting with the client's own past approved translations as its closest reference, which is a far stronger anchor than the internet's average.

Termbase Injection: The Non-Negotiable Words

The termbase grounds differently, because terms are not examples to imitate but rules to obey. Termbase grounding works by retrieving, for the segment in front of the engine, every approved term that appears in that source and injecting those mappings into the prompt as mandatory constraints: "In this segment, 'cordless driver' must be rendered 'Akku-Bohrschrauber'; do not use any synonym." The retrieval step matters here, and it is easy to overlook. You do not dump the entire termbase into every prompt, because a termbase can hold thousands of entries and most are irrelevant to any given segment. Instead the pipeline detects which approved terms actually occur in this source segment and injects only those, keeping the constraint sharp and the prompt small. The effect is that the engine drafts already knowing the one word it is allowed to use for each pinned concept, which is exactly the constraint that stops the "Akkuschrauber" drift before it happens rather than after.

Style-Guide Grounding: The Standing Voice

The style guide grounds as standing instructions rather than per-segment retrieval, because most style rules apply to every segment, not just the ones containing a particular term. Register, formality, date format, capitalization, brand voice: these hold across the whole file, so they belong in the standing layer of the prompt, the system-level instructions that frame every segment, rather than being retrieved fresh each time. A grounded setup encodes the style guide's rules as a persistent instruction the engine reads before every segment: "Use the formal register and the formal address pronoun throughout; write dates as day month year with the month spelled out; keep the brand voice confident and direct; never use contractions." Where the termbase grounds the words and the TM grounds the sentences, the style guide grounds the voice, and because the voice is constant it is supplied constantly rather than retrieved per segment. Some longer style guides also benefit from selective retrieval, pulling the specific rule relevant to an unusual segment, but the backbone is a standing instruction block that carries the conventions every segment shares.

Match the grounding method to the asset: TM as retrieved examples to imitate, termbase as per-segment mandatory constraints, style guide as standing instructions that frame every segment. The three together let the engine draft from your approved language instead of the internet's average.

What Grounding Does, and What It Pointedly Does Not

Here is where a careful linguist earns their keep, because grounding is powerful enough to be oversold, and an oversold control is a dangerous one. Grounding genuinely reduces drift and hallucination. It does not, cannot, and must never be assumed to eliminate them. Holding both halves of that sentence at once is the difference between using grounding as a tool and trusting it as a guarantee, and only one of those is professional.

What It Genuinely Improves

Start with the real gains, because they are substantial and worth the effort. Grounding on a termbase sharply reduces terminology drift: when the approved mapping is sitting in the prompt as a constraint, the engine reaches for the approved term far more often than when it is guessing from the open web. Grounding on a TM sharply improves consistency: when the engine drafts with the client's past approved renderings of similar sentences in front of it, the new translation lands closer to the established voice, and the same sentence stops being translated five different ways across five files. Grounding on a style guide improves register and locale conformance: the formal pronoun, the date format, the brand voice land more reliably when they are standing instructions than when they live only in a post-editor's memory. And grounding reduces a specific flavor of hallucination, the engine confidently producing content with no basis in the source or the approved materials, by giving the model real reference material to lean on instead of leaving it to fill gaps from its parameters. An engine looking at the right TM entry is less likely to invent a plausible-sounding rendering, because it has a real one to anchor on.

Why It Does Not Eliminate the Failure

Now the limits, and they are not footnotes. They are the reason the human stays in the loop. First, retrieval can fail to find the right material. If the relevant TM entry is phrased differently from the new source, the retrieval may miss it and the engine drafts ungrounded for that segment, drifting exactly as before. The grounding is only as good as the retrieval, and retrieval is imperfect. Second, the engine can ignore the grounding. Supplying the approved term as a constraint makes the engine far more likely to use it, but the model remains a probability machine, not a rule engine, and on some segment it will, despite a perfect constraint in the prompt, reach for the fluent generic anyway. More-probable is not guaranteed. Third, grounding cannot fix a flawed asset. If the termbase contains a wrong approved term, or the TM holds a past translation that was itself an error, grounding will faithfully propagate that error into every new segment, because grounding's whole job is to make the engine answer from your materials, and it cannot tell a good entry from a bad one. A poisoned TM is an infection vector, and grounding spreads the infection efficiently. Fourth, grounding does nothing for the failures that have nothing to do with approved language: a dropped negation, an inverted number, a flipped dosage. The engine can render every approved term perfectly and still drop the "not" that reverses the meaning of a safety instruction, because that error lives in fidelity to the source, not in conformance to the termbase, and grounding the termbase does not check the source.

That fourth limit is the one most likely to lull a linguist into danger, so state it flatly. Grounding improves conformance to your approved language. It does not verify fidelity to the source. A grounded engine can produce a segment that uses every approved term, matches the house register, formats the date correctly, and still inverts the meaning of the sentence, because grounding pulls the output toward your materials and says nothing about whether the output means what the source meant. The silent critical error, the fluent rendering that means the opposite of the source, survives grounding untouched. Grounding makes the draft more on-brand; it does not make it correct, and on-brand-but-wrong is its own special trap, because the conformance can make the error look even more trustworthy.

Grounding reduces drift and hallucination; it does not eliminate them. Retrieval can miss, the engine can ignore the constraint, a poisoned asset propagates its own errors, and grounding never checks fidelity to the source. It raises the floor on conformance; it does not move accountability off the human.

A Worked Grounded Setup, End to End

Abstractions only become a skill when you can see them run, so walk through a complete grounded setup for Sofia's recurring scenario: the German power-tool client, a product-catalog refresh, English into German, with a TM, a termbase, and a style guide already maintained for the account. The goal is to design a grounding configuration that puts the approved language in front of the engine on every segment, and then to operate it knowing exactly what it does and does not buy. Read it as a blueprint you can adapt, not a vendor-specific recipe, because the assets and the principles are constant even though the buttons differ across tools.

Step One: Prepare the Assets So They Are Worth Grounding On

Grounding inherits the quality of what it grounds on, so the first move is not technical at all. It is to confirm the assets are clean, because grounding a poisoned asset multiplies the poison. Before connecting the TM to the engine, Sofia's team confirms it contains approved, verified translations and not a backlog of un-reviewed machine output that crept in over the years. Before connecting the termbase, they confirm the approved terms are actually the current client-approved ones, "Akku-Bohrschrauber" and not a stale entry from a prior naming convention. Before relying on the style guide, they confirm it reflects the client's current voice and locale rules. This sounds like overhead. It is the single highest-leverage step in the whole setup, because every later benefit of grounding is conditional on the assets being right, and every later harm of grounding flows from an asset being wrong. The asset audit is the foundation; everything above it is only as sound as the assets underneath.

Step Two: Wire the Retrieval for Each Asset

With clean assets, configure how each one reaches the engine, matching method to asset as established above. For the TM, the pipeline retrieves the closest matches to each source segment and supplies them to the engine as in-context examples, prioritizing high fuzzy matches because a ninety-percent match is a strong, specific anchor while a thirty-percent match is noise that can mislead more than it helps. The retrieval is tuned to pull only matches above a sensible threshold, so the engine is grounded on genuinely relevant prior translations and not on loose associations. For the termbase, the pipeline scans each source segment for terms present in the glossary and injects only the matching mappings as mandatory constraints for that segment, keeping the constraint sharp and the prompt focused. For the style guide, the standing conventions are encoded once as a persistent instruction block that frames every segment: the formal register, the formal address pronoun, the date format, the brand-voice notes, the no-contractions rule. The TM and termbase ground per segment through retrieval; the style guide grounds across the file through a standing instruction. Together they assemble, for each segment, a prompt that contains the source, the relevant past translations, the mandatory terms, and the standing voice rules, which is to say the engine drafts that segment looking at the same materials a well-briefed human translator would have open.

Step Three: Draft, Then Verify, Because Grounding Is Not the Gate

Now the engine drafts every segment grounded, and the draft that lands in front of the post-editor is markedly closer to approved than an ungrounded draft would be. "Akku-Bohrschrauber" appears where the termbase pinned it. The register is formal where the style guide demanded it. Sentences that matched the TM read like the client's established voice. The drift that cost Sofia an afternoon last month is sharply reduced, and her file starts from a much better place. This is the real payoff, and it is large.

And then the post-editor does the thing that grounding never replaces: they verify. They read each grounded segment against the source, because grounding improved conformance to the approved language and said nothing about fidelity to the meaning. They check that the approved term that appears is approved and correct in context, because a grounded term can still be the wrong sense of a word. They confirm no negation was dropped, no number inverted, no clause omitted, because those failures live in the source relationship that grounding does not touch. They watch specifically for the on-brand-but-wrong segment, the one whose perfect conformance makes the underlying error more convincing, not less. The grounded draft is a better starting point, not a finished product, and the post-editor owns the finished product. "The engine was grounded on our termbase" is no more an answer when a Critical error ships than "the engine wrote it." Accountability stays with the human whose name is on the delivery, exactly as it did before grounding existed, because grounding changed where the draft starts and changed nothing about who is responsible for where it ends.

Step Four: Close the Loop So the Assets Improve

The final step is what makes a grounded setup compound instead of stagnate. When the post-editor finalizes a segment, the verified approved translation flows back into the TM, so the next file's retrieval has a richer, more accurate store to ground on. When the post-editor finds a term the client cares about that the termbase did not yet hold, it gets added, so the next file's term injection covers it. When a style decision recurs, it gets written into the style guide, so the next file's standing instructions enforce it. Grounding is not a one-time configuration; it is a loop in which the engine grounds on the assets, the human verifies and corrects, and the corrections enrich the assets the engine grounds on next time. A well-run grounded pipeline gets better at the client's voice with every file, because every file's verified output is tomorrow's ground truth, which is the opposite of an ungrounded pipeline that makes the same drift error forever because it never learns the client's approved language at all.

What Sofia Gains, Concretely

Return to the afternoon Sofia lost. With the grounded setup running, the engine drafts the catalog with "Akku-Bohrschrauber" already in place, the formal register already applied, the dates already in the client's format, and the recurring sentences already rendered in the client's established voice from the TM. The drift that forced forty hand-corrections is mostly gone before she opens the file, because the engine drafted from the client's German instead of the internet's. Her job has not disappeared; it has moved up. She is no longer the person who retypes "Akku-Bohrschrauber" forty times. She is the person who verifies that the grounded draft is not only on-brand but faithful, who catches the on-brand-but-wrong segment grounding cannot catch, who feeds her corrections back so the assets get richer, and who owns the delivery with a clear account of what the grounding did and what she verified on top of it. That is the linguist whose role the engine cannot replace, because the engine can be grounded on the approved language but it cannot be made accountable for the meaning, and accountability for the meaning is the whole job.

Grounding in the Pipeline and the Standards

Grounding does not live in isolation; it sits inside the risk-tiered pipeline the previous lessons built, and it interacts with the standards the program is organized around, so place it correctly before you deploy it. Grounding is a control that improves the quality of the draft. It is not a control that decides what the engine is allowed to touch in the first place. That decision belongs to risk-tiered intake, the step that classifies content by consequence and routes high-liability material, medical, legal, life-safety, financial, to full human translation or full post-editing regardless of how good the grounding is. Grounding makes the engine's draft better; it does not make a drug label safe to machine-translate. A grounded engine on MT-forbidden content is still an engine on MT-forbidden content, and grounding's improvement does not change the routing decision, because the routing decision is about consequence, not about draft quality.

Set against the standards, grounding is a means, not a credential. The revised ISO 18587, the post-editing standard whose update expands its scope to AI and LLM output and insists the post-editor hold full professional-translator competence, is satisfied by the human who verifies the grounded draft, not by the grounding itself. ISO 5060, which formalizes the MQM-aligned, Multidimensional Quality Metrics, Critical/Major/Minor error scoring that decides whether output ships, scores the verified output, and a grounded segment that conforms to the termbase but inverts a number still earns a Critical and still fails the file. Grounding is upstream of the gate; it makes the draft more likely to pass, but it does not pass the draft, and it does not lower the bar the gate enforces. The clean way to hold the relationship is this: grounding raises the floor on what the engine drafts, risk-tiered intake decides what the engine may draft at all, the post-editor verifies what the engine drafted, and the severity-scored gate decides what ships. Grounding is one disciplined control among several, valuable precisely because it does its one job well and is never asked to do the jobs that belong to the human and the gate.

Grounding improves the draft; it does not decide what the engine may touch, and it does not pass the quality gate. Risk-tiered intake routes by consequence, the post-editor verifies fidelity, and the severity-scored gate decides delivery. Grounding raises the floor; it never moves the ceiling or the accountability.

Key Takeaways

• Grounding constrains an engine to answer from specific material you supply at generation time instead of from the generic web text it learned in training; RAG (retrieval-augmented generation) is the machinery that does it, in a three-beat loop, retrieve the relevant approved language for this segment, augment the prompt with it, and have the model generate while looking at it. The model is not retrained; it is shown the right reference at the right moment, the way you would brief a new freelancer with the client's glossary and past translations.
• The three assets you ground on answer three different questions: the translation memory (TM, a database of past source-target segment pairs, human-verified) answers "how have we translated sentences like this before"; the termbase (the database of approved source-to-target term pairs) answers "what is the one approved word"; and the style guide (the standing conventions for register, locale, and voice) answers "how does this client write." An engine grounded on all three reads the house style instead of guessing it.
• An ungrounded engine drifts by default because it is excellent at producing the internet's average language, not your client's approved language; drift is the steady, fluent pull toward the common rendering, dangerous precisely because every instance reads perfectly. The error lives in the gap between "correct language in general" and "approved language for this client," a gap invisible to a system that has never seen the client's materials.
• Match the grounding method to the asset: TM grounds as retrieved examples to imitate (prioritize high fuzzy matches, drop low ones as noise); the termbase grounds as per-segment mandatory constraints (detect the approved terms present in this source and inject only those); and the style guide grounds as a standing instruction block that frames every segment, because register, formality, date format, and voice hold across the whole file.
• Grounding genuinely reduces terminology drift, improves consistency and locale conformance, and curbs one flavor of hallucination by giving the model real reference material to lean on instead of leaving it to fill gaps from its parameters. These are substantial, real gains, and they shrink the post-editor's job from "catch every silent drift" to "verify a draft that already tried to honor the house style."
• Grounding does not eliminate the failure: retrieval can miss the relevant material, the engine can ignore a perfect constraint because it is a probability machine, a poisoned TM or termbase propagates its own errors efficiently, and grounding does nothing for source-fidelity failures, a dropped negation or an inverted number survives grounding untouched. Grounding improves conformance to your approved language; it never verifies fidelity to the source meaning.
• The on-brand-but-wrong segment is grounding's special trap: a grounded draft can use every approved term, match the register, format the date, and still invert the meaning of the sentence, and its perfect conformance can make the underlying error look more trustworthy, not less. Verify grounded drafts against the source with extra care, precisely because they read more convincingly.
• Operate a grounded setup as a loop, not a one-time config: audit the assets first because grounding multiplies whatever it grounds on, wire retrieval to each asset, let the engine draft grounded, have the post-editor verify against the source and own the delivery, and feed verified corrections back so the TM, termbase, and style guide get richer every file. Grounding sits upstream of the quality gate and downstream of risk-tiered intake: it raises the floor on the draft, it does not decide what the engine may touch, it does not pass the ISO 5060 gate, and it never moves accountability off the human whose name is on the file.