The engine had a favorite word, and it was the wrong one. A surgical-device maker in Munich shipped a German-market launch on a hard date, and somewhere in the 6,000-segment batch sat one approved English source term, "applicator," that the client had locked to exactly one German target: "Applikator." Not "Auftragsgerät." Not "Einbringinstrument." Not the friendly, fluent, statistically obvious "Applikationshilfe" that the MT engine reached for the way a tired hand reaches for the nearest mug. The regulatory file, the IFU (the instructions-for-use document a device legally ships with), the training deck, and the field-service manual were all keyed to "Applikator," because that is the word the notified body had reviewed and the surgeons had been trained on. On the first machine pass, the engine drifted to "Applikationshilfe" in segment 0419. A post-editor, racing a per-word rate, read a clean German sentence and confirmed it. The translation memory swallowed the wrong term and began handing it back. Forty-one segments later, the term was wrong in the IFU, wrong in a subtitle file, and wrong in a print proof already at the vendor. This lesson is about the machinery that stops that: how you inject an approved term so the engine cannot drift, how the CAT tool's terminology QA flags the moment it does, how a find-and-verify pass sweeps a whole project before delivery, how a forbidden-term list catches the synonym the glossary forgot, and why, at the end of every one of those automated controls, a human terminologist still has to blow the whistle. We will walk one real drift from the engine's first wrong guess to the enforcement that caught it across the entire project, and we will go slowly, because the cost of skimming this is the cost of that reprint.

The Term That Must Stick, and the Engine That Won't Let It

Start with the two assets, because every enforcement technique in this lesson is an attempt to make one of them win over the other. The first is the termbase, also called a glossary or term database: the prescriptive, client-approved list of which source term must become which one target term, every time, with no exceptions and often with a note about which tempting synonyms are explicitly forbidden. The termbase is a rulebook. It does not record what was translated; it dictates what must be. "Applicator becomes Applikator, and Applikationshilfe is forbidden" is a termbase entry. The second asset is the MT engine itself, whether a narrow neural MT system (NMT, a model trained only to translate) or a general large language model (LLM, a model that translates as a side effect of predicting plausible text). The engine is the opposite of a rulebook. It is a probability machine that produces whatever target word it learned was most likely to follow a given source word in a given context, across the vast general text it was trained on.

The whole problem of this lesson lives in the gap between those two. A termbase encodes an arbitrary, prescriptive, frequently low-probability choice. The client picked the rarer word on purpose, because it was more precise, more distinctive, legally reviewed, or simply the one the regulator signed off on. The MT engine is built to produce the statistically obvious word. So the approved term is, by design, often the word the engine is least likely to choose on its own. This is not the engine being careless. It is the engine being exactly what it is.

An approved term is a rule that says "do not use the obvious word." An MT engine is a machine built to produce the obvious word. Left alone, the machine wins, and it wins in fluent, grammatical prose that does not trip your eye.

That last clause is the danger. If the engine drifted into a clumsy, broken sentence, a post-editor would stop and fix it on reflex. But "Applikationshilfe" is a perfectly good German word. The sentence around it is natural. Nothing about the surface of the output signals that a rule was just broken. The drift is invisible precisely because the wrong word is fluent. So enforcement cannot rely on the wrong word looking wrong. It has to rely on machinery that checks the output against the rule, mechanically, whether or not the prose reads well. That machinery is what this lesson builds.

Define the Control: Terminology QA

Terminology QA (terminology quality assurance) is the automated check, run inside the CAT tool (the computer-assisted translation environment where linguists work) or the TMS (the translation-management system that orchestrates a project), that compares the actual target text of every segment against the termbase and flags any segment where an approved source term appears but its approved target term does not. It is, mechanically, a string-matching control: the source contains "applicator," the termbase says the target must contain "Applikator," the target instead contains "Applikationshilfe," so the check raises a flag on that segment. Terminology QA does not understand German. It does not know what the words mean. It knows only whether the rule was followed, and that, it turns out, is exactly the kind of thing a machine is good at and a tired human is bad at. The rest of this lesson is about getting the right rule into the engine before it drafts, and the right check over the output after it does.

Enforcement Before the Draft: Injecting the Term

The cheapest drift to fix is the one that never happens. Every technique that lives after the engine has drafted is cleanup, and cleanup costs post-editor minutes that the MTPE (machine-translation post-editing) economics did not budget for. So the first and most powerful control is to constrain the engine at generation time, so the approved term is in the output before a human ever looks at it. This is terminology injection, sometimes called glossary injection, constrained decoding, or a glossary-aware setting, and it comes in two broadly different flavors depending on whether you are driving a dedicated MT engine or prompting an LLM.

Injecting Into a Dedicated MT Engine

Modern NMT engines expose a glossary or "custom terminology" feature: you upload the source-target term pairs, and the engine is instructed, during decoding, to honor them. The mechanism under the hood is usually one of two things. Some engines do constrained decoding, where the model's search for the most probable output is forced to pass through the approved target term, so the term is locked and the engine builds the fluent sentence around it. Others do a lighter soft-constraint or annotation approach, where the source term is tagged before translation so the model is biased, but not absolutely forced, toward the approved target. The difference matters enormously and most linguists never ask which one their engine does.

A hard constraint guarantees the term appears but can produce a slightly stiff sentence, because the engine was forced to use a word it would not have chosen and had to bend the grammar around it. A soft constraint produces a more natural sentence but does not guarantee the term, so the engine can still drift if its probability for the common synonym is high enough to overcome the nudge. Neither is universally right. For a regulated device term where the word is non-negotiable and a stiff sentence is acceptable, you want the hard constraint. For a marketing register where fluency carries the brand and the term is a strong preference rather than law, the soft constraint plus a downstream check may serve better. The point is that "I turned on the glossary feature" is not the same as "the term is guaranteed," and the linguist who knows the difference is the one who does not get surprised at delivery.

Turning on glossary injection is not a guarantee. A hard constraint forces the term and may stiffen the sentence; a soft constraint nudges and can still drift. Know which one your engine does before you trust it with a term that can fail an audit.

Injecting Into an LLM Prompt

When the engine is an LLM, terminology injection happens in the prompt, and the discipline is different. An LLM does not have a formal glossary slot; it has instructions and context, and it will follow them with the same probabilistic looseness it brings to everything. A naive approach pastes the whole 900-term glossary into the system prompt and hopes. That fails for two reasons: a long glossary buries the few terms that actually appear in this segment under hundreds that do not, and the model's adherence to a flat list degrades as the list grows. The disciplined approach is to inject only the relevant terms, the handful that actually occur in the segment or batch being translated, retrieved and placed right next to the text, with an explicit instruction that those target renderings are mandatory and that any uncertainty must be flagged rather than guessed.

A workable LLM injection instruction reads, in spirit, like this: "Translate the following source segment into German. You must use these exact approved target terms for the listed source terms: applicator becomes Applikator. These renderings are mandatory and override your own preference, even if another word seems more natural. If the source contains a term you are unsure how to render under these rules, do not guess; mark it for human review." That instruction does three jobs. It supplies the rule, it explicitly overrides the model's fluency preference (which is the exact instinct that causes drift), and it gives the model permission to flag instead of inventing, which converts a silent wrong guess into a visible question. Even so, an LLM can ignore a prompt instruction in a way a hard-constrained NMT engine cannot, which is precisely why injection is necessary but never sufficient, and why the post-draft controls in the next sections exist.

Why Injection Alone Is Never Enough

It would be lovely if injection ended the story. It does not, for reasons worth stating plainly so you never over-trust the upstream control. Injection only fires when the term is in the termbase, so any term missing from the glossary is unprotected. It only matches the surface form it was given, so a term that appears inflected, "applicators" plural, or "Applikators" in the genitive, can slip past a naive matcher that was looking for the exact lemma. It does nothing about content that arrives as an exact or fuzzy match from the TM (translation memory, the database of previously approved sentence pairs), because that text never passes through the engine's decoder at all, it is reused wholesale, wrong term and all, from a past decision. And soft constraints, as we saw, can simply lose. So injection is the strong first line, and a strong first line is not a wall. You build the wall by checking the output, every segment, against the rule, after the draft exists. That is terminology QA, and it is next.

Terminology QA in the CAT Tool: The Mechanical Check

Once a segment has a target, whether from injection, the TM, or a post-editor's hands, the CAT tool can check it against the termbase automatically, and this is the single highest-leverage control in the whole lesson because it does not depend on anyone reading carefully. Terminology QA scans every segment, finds where an approved source term occurs, and verifies that the corresponding approved target term is present. Where it is not, the segment is flagged, and the linguist is forced to look at exactly the place the rule was broken instead of hoping their eye lands there. The fluent wrong word that slid past a human reading for sense gets caught by a machine reading for compliance, which is the whole reason to run both kinds of attention over the same file.

What the Check Actually Does, and Its Blind Spots

Mechanically, the check is a lookup and a presence test, and understanding both halves tells you where it succeeds and where it fails. For each termbase entry, it asks: does the source segment contain the source term? If yes, it asks: does the target segment contain the approved target term? A mismatch, source term present, target term absent, is the flag. This is brilliant at catching exactly the Munich drift: "applicator" is in the source, "Applikator" is missing from the target, "Applikationshilfe" is sitting there instead, and the segment lights up. But the same mechanical simplicity creates predictable blind spots that a linguist must compensate for:

• Morphology. If the check matches only the exact stored form, it can miss "Applikatoren" (plural) or "Applikators" (genitive) and, worse, can falsely flag a correct inflected form as missing. Good terminology QA settings allow stemming or fuzzy term matching; a naive setup produces both false negatives and false-positive noise.
• Case and partial matches. A target that contains the approved string as part of a larger word, or in the wrong case, can fool a crude matcher into passing or failing incorrectly. The check is a string operation, and strings are blunt.
• Synonyms the termbase never listed. Terminology QA verifies that the approved term is present. It does not, by default, verify that a forbidden term is absent. If the segment somehow contains both the approved term and a stray synonym, a present-test passes. Catching the forbidden word needs its own control, which is the forbidden-term list later in this lesson.
• The false-positive flood. If the settings are too strict, the check flags hundreds of segments where the term is fine, the linguist learns to dismiss the flags reflexively, and the one real drift drowns in the noise. A QA check that cries wolf is worse than none, because it trains the human to ignore it.

The craft, then, is tuning. A terminology QA profile that is too loose lets the drift through; one that is too tight buries the real flag under noise and gets switched off. The linguist who owns this control spends real time getting the morphology settings, the case sensitivity, and the term-matching tolerance right for the language pair, because a well-tuned check is a quiet, reliable referee and a badly tuned one is a smoke alarm with a dead battery taped over it.

Terminology QA verifies the approved term is present. It does not, by itself, verify the forbidden term is absent, and it is only as good as its tuning. A check that floods you with false positives gets ignored, and an ignored check is no check at all.

The Find-and-Verify Pass: Sweeping the Whole Project

Segment-level terminology QA fires as you work, segment by segment. But the Munich drift had already propagated before anyone ran a check, because the wrong term entered the TM in segment 0419 and leveraged forward into forty more. Catching that requires a different motion: not a per-segment flag but a find-and-verify pass, a deliberate, project-wide sweep that searches every occurrence of a key term across the entire file set and verifies, occurrence by occurrence, that the approved rendering is the one used everywhere. Where terminology QA asks "is this one segment compliant," find-and-verify asks "is this term consistent across the whole project, every deliverable, every channel." The first is a tripwire; the second is a metal detector swept across the whole field.

How to Run the Pass Deliberately

The pass is methodical, and the method is what makes it trustworthy. You do not eyeball the file and hope. You work from the termbase outward, term by term, in priority order:

• Pick the high-stakes terms first. Not all terms are equal. The regulated device term, the safety-critical noun, the legally reviewed phrase, those get a dedicated sweep each. Rank by consequence, not by frequency, because the term that can fail an audit is the one that must be perfect even if it appears twice.
• Search the source for every occurrence of the source term. Across all files, all formats, the IFU, the subtitles, the UI strings, the print proof source, find every segment where "applicator" appears in the English.
• Verify the target of each one against the approved rendering. For every hit, confirm the German says "Applikator" (in whatever correct inflected form the grammar demands) and not a synonym. This is the verify step, and it is done by a human reading each instance with the rule in hand, not by trusting the percentage that a tool already passed it.
• Search the target for the forbidden synonyms directly. Then flip it: search the German for "Applikationshilfe," "Auftragsgerät," every word you know the engine likes to drift toward, and confirm none of them appear where the approved term should. This catches the inverse of what terminology QA catches: not a missing approved term, but a present forbidden one.

Run that pass and the forty-one drifted segments surface as a block, because they all share the same wrong word, and you fix them as a set with a single informed correction propagated across the project. The find-and-verify pass is the control that turns "we caught one" into "we caught all of them," and it is the difference between a clean delivery and a reprint that ships with thirty more instances of the same error still buried in the back half of the file.

When to Run It, and Why the Timing Decides the Cost

The timing of the pass decides how much it saves. Run too early, before all segments are post-edited, and you sweep an incomplete file and have to sweep again. Run too late, after delivery, and you are no longer doing terminology enforcement, you are doing a recall. The right placement is a mandatory gate before delivery and before the corrected segments are committed back to the TM, because the TM is where a term error stops being a one-time mistake and becomes permanent institutional memory that will leverage into the next project too. Catch the drift before it is written back, and you fix one project. Catch it after, and you have already poisoned the asset that feeds every future job for this client. The find-and-verify pass is not just a delivery check; it is the gatekeeper standing between a contained error and an infected memory.

The Forbidden-Term List: Catching What the Glossary Forgot

So far every control has been positive: get the approved term in, verify it is present. But the engine's drift is, by definition, toward a word the termbase did not bless, and sometimes that word is one the termbase never even thought to forbid. This is where the forbidden-term list earns its place, a separate, explicitly prohibitive control that lists the words that must never appear in the target, and flags any segment where one does, regardless of whether the approved term is also present. It is the photographic negative of the termbase: the termbase says "use this," the forbidden-term list says "never use that," and the two together close a gap that neither closes alone.

Why a Negative List Catches What a Positive One Misses

Consider the precise failure that a forbidden-term list catches and terminology QA does not. Terminology QA verifies presence: it confirms "Applikator" is in the segment. But suppose the engine produced a sentence using "Applikationshilfe" in a segment where, by coincidence, "Applikator" also appeared once for an unrelated reason. The present-test passes, the approved term is technically there, and the drift sails through. Or consider a term the client forbids that has no approved counterpart at all, a brand name a competitor owns, a deprecated product name, a colloquialism that violates the register. There is no termbase entry to check presence against; there is only a word that must never appear. A positive control has nothing to say about either case. A forbidden-term list catches both, because it is not asking "is the right word here," it is asking "is a wrong word here," and those are genuinely different questions.

The forbidden-term list is also the institutional memory of the engine's specific habits. Every time you catch the engine drifting to a particular synonym, you add that synonym to the forbidden list, so the next project flags it automatically before a human has to notice it again. The list grows into a map of exactly how this engine, this language pair, this domain tends to drift, and it converts a lesson learned the hard way once into a control that fires forever after. A mature localization operation's forbidden-term list is a quiet record of every drift it ever paid for.

The termbase says use this word. The forbidden-term list says never use that one. Terminology QA checks that the right word is present; the forbidden-term list checks that the wrong word is absent. You need both, because the silent drift can satisfy the first while violating the second.

Building the List From the Drift You Actually See

A forbidden-term list is only as good as the drift it has learned. You seed it from three sources, and you keep feeding it. First, the client's own explicit prohibitions: the competitor names, the deprecated terms, the words legal has banned. Second, the synonym traps that sit next to every approved term, the obvious common word the engine will reach for, recorded as forbidden the moment the approved term is chosen, because the time to forbid "Applikationshilfe" is the same moment you bless "Applikator," not after it has shipped. Third, and most valuable, the drifts you catch in production: every time a find-and-verify pass or a sharp-eyed reviewer catches the engine reaching for a word it should not, that word goes on the list. The list that started as a handful of client prohibitions matures into a precise, lived inventory of how the engine misbehaves on this account, and that inventory is worth more than any generic glossary because it is specific to the exact failure mode you keep paying for.

The Worked Example: One Drift, From Guess to Gate

Now put every control in its place and walk the Munich drift end to end, because the sequence is the lesson. The project: 6,000 segments of surgical-device documentation, German market, hard launch date, one regulated term among many, "applicator," locked to "Applikator," with "Applikationshilfe" and "Auftragsgerät" as known forbidden synonyms. Watch each control fire, or fail to, in order.

Stage One: The Drift Happens

Terminology injection was configured, but as a soft constraint, because the team had turned on the glossary feature without checking whether it was hard or soft. In segment 0419, the source read "Attach the applicator to the delivery cannula." The engine's probability for "Applikationshilfe" was high enough to overcome the soft nudge, and it produced a fluent German sentence using the forbidden word. The injection control fired and lost, exactly as a soft constraint can. The first line of defense had a hole in it, and the term drifted through.

Stage Two: The Human Misses It

A post-editor, working at MTPE speed against a per-word rate, opened segment 0419 and read a clean, grammatical, natural German sentence. Nothing about it looked wrong, because nothing about it was wrong as German prose; it was wrong only against a rule that lived in a termbase the post-editor was not re-reading word by word. They confirmed the segment. The fluent-error failure mode did exactly what it always does: it slid past a human reading for sense. This is not a story about a careless linguist. It is a story about why human attention alone is structurally insufficient against a fluent wrong word, which is the entire reason the mechanical controls exist.

Stage Three: The Error Feeds Itself

On confirmation, the CAT tool wrote segment 0419, forbidden term and all, back into the translation memory. The poisoned segment was now a stored asset. Over the next two days, as similar sentences appeared, that segment surfaced as exact and fuzzy matches, the wrong term riding inside it, and it leveraged into forty more segments across the IFU, a subtitle file for a training video, and the source feeding a print proof. The error had stopped being an engine output and become institutional memory, propagating not because the engine kept choosing it but because the TM kept offering it. One drift had become forty-one, every instance fluent, every instance traceable to a single soft-constraint miss and a single tired keystroke.

Stage Four: Terminology QA Catches the Live Segments

Before delivery, the project lead ran the CAT tool's terminology QA across the batch. For every segment where the source contained "applicator," the check verified that the target contained "Applikator." The forty-one drifted segments where the term was missing lit up as flags. Here the tuning paid off: because the morphology settings had been configured to accept inflected forms of the approved term, the check did not drown the real flags in false positives on legitimate plurals and genitives, so the forty-one stood out clearly instead of hiding in a list of three hundred noise flags. The mechanical control caught what the human eye had missed, on exactly the segments the rule was broken.

Stage Five: Find-and-Verify Confirms the Whole Project

The flags were a start, not the end. The terminologist then ran a deliberate find-and-verify pass: searched every file for the source term "applicator," verified each target against "Applikator," and then flipped it and searched the German directly for the forbidden synonyms "Applikationshilfe" and "Auftragsgerät." That reverse search caught two additional segments that terminology QA had passed, because in those segments the approved term also happened to appear elsewhere in the sentence, so the present-test had been satisfied while a forbidden synonym sat quietly in the same segment. The forbidden-term search caught what the positive check could not. Now the count was the true forty-three, not the forty-one the positive control alone had found.

Stage Six: The Terminologist Refers, and the Gate Holds

The terminologist corrected all forty-three to "Applikator," propagated the fix across every file, and, critically, cleaned the poisoned segment out of the TM before it was committed forward, so the next project for this client would not inherit the drift. They added "Applikationshilfe" and "Auftragsgerät" to the forbidden-term list for the account, converting this expensive lesson into an automatic flag for every future job. They reconfigured the injection from a soft constraint to a hard one for the regulated terms, closing the upstream hole. And only then, with zero occurrences of the forbidden words and the approved term verified across every deliverable, did they clear the file for delivery. The print proof was corrected before it printed. The subtitle file was fixed before the video shipped. The recall conversation never happened, because the gate held one step before the point of no return.

Every automated control has a gap, and the gaps do not overlap. Injection can lose to a soft constraint, terminology QA can pass a present forbidden term, find-and-verify depends on someone running it. The terminologist is the one who knows where each control is blind and stands in the gap the machines leave.

The Terminologist as Referee, Not Typist

Notice what made the Munich delivery clean: not any single control, but a human who understood every control well enough to know what each one missed. Injection caught most drifts but lost the soft-constraint case. Terminology QA caught the missing-term segments but passed the present-forbidden-term ones. Find-and-verify caught those, but only because someone chose to run it and chose to search the forbidden synonyms directly. No control was complete. The completeness came from the terminologist, the human who owns the termbase and the enforcement, sequencing the controls, tuning them, reading their gaps, and making the final judgment that the rule was honored everywhere it mattered.

This is the role that has moved up the value chain in the MT era. A decade ago the terminologist typed glossaries. Today the typing is the least of it. The work is standing at the points where the term can drift and being the referee the machinery cannot be: deciding the approved word, deciding which synonyms are forbidden, configuring whether injection is hard or soft, tuning the terminology QA so it neither leaks nor floods, running the find-and-verify pass before the TM is committed, and growing the forbidden-term list from every drift the operation pays for. The engine knows what word is probable. The CAT tool knows whether a string is present. Only the terminologist knows what is approved, and approval is a human decision that no probability and no string match can make.

Why the Human Stays Accountable

It is tempting, once all this automation is in place, to believe the controls own the quality. They do not. The controls are instruments; the terminologist plays them. When a forbidden term ships, "the glossary feature was on" is no more an answer than "the engine wrote it." Someone configured the injection as soft when it should have been hard. Someone tuned the QA, or failed to. Someone ran the find-and-verify pass, or skipped it under deadline. Accountability for the approved term holding across every segment sits with the human who owns the enforcement, exactly as accountability for a shipped Critical error sits with the post-editor who confirmed it. The automation moves the work from typing to judgment; it does not move the responsibility to the machine. That is why this is a skill that pays: the operation needs a human who can be accountable for terminology under an audit, and an audit does not accept "the feature was enabled" as evidence that the rule held.

The Economics of Catching It Early

One last reason to take all of this seriously, stated in the only language a client always hears: money. A term drift is trivial to commit, one fluent guess and one tired keystroke. It is cheap to fix in the database, a find-and-replace across the TM takes minutes. And it is ruinously expensive everywhere it escaped to: the reprinted IFU, the re-recorded and re-subtitled video, the retrained helpline, the regulatory inconsistency a reviewer can flag, the client confidence that does not return with a find-and-replace. The entire architecture of enforcement, injection before the draft, terminology QA on every segment, find-and-verify across the project, the forbidden-term list, the terminologist refereeing all of it, exists to move the catch as far upstream as possible, because the cost of catching a drift rises by an order of magnitude at every stage it survives. Caught at injection, it costs nothing. Caught at QA, it costs minutes. Caught at delivery, it costs a careful pass. Caught after delivery, it costs a recall. The whole discipline is a machine for catching the term early, and the terminologist is the operator who decides it gets caught at all.

Key Takeaways

• A termbase (glossary) is the prescriptive rulebook that says which approved target term a source term must become; an MT engine is a probability machine built to produce the statistically obvious word. The approved term is often the less probable word by design, so the engine drifts toward the common synonym in fluent prose that does not trip the eye, which is exactly why enforcement cannot rely on the wrong word looking wrong.
• Terminology QA (terminology quality assurance) is the automated CAT-tool or TMS check that flags any segment where an approved source term appears but its approved target term does not. It catches the fluent drift a human reading for sense slides past, but only as well as it is tuned: too loose and it leaks, too strict and it floods you with false positives until you ignore it.
• Terminology injection (glossary injection, constrained decoding) constrains the engine at generation time. A hard constraint forces the approved term and may stiffen the sentence; a soft constraint nudges and can still drift. "I turned on the glossary feature" is not "the term is guaranteed," and for regulated terms you want the hard constraint.
• For LLMs, inject only the relevant terms next to the segment, instruct that the approved renderings are mandatory and override the model's fluency preference, and tell the model to flag uncertainty instead of guessing. An LLM can still ignore a prompt instruction, so injection is necessary but never sufficient.
• Injection alone never closes the loop: it does not protect terms missing from the glossary, can miss inflected forms, and does nothing about wrong terms reused wholesale from the TM (translation memory) as exact or fuzzy matches. You build the wall by checking the output against the rule after the draft exists.
• A find-and-verify pass is a deliberate, project-wide sweep: pick high-stakes terms by consequence, search the source for every occurrence, verify each target against the approved rendering, then search the target directly for the forbidden synonyms. Run it before delivery and before committing corrections back to the TM, because the TM is where a one-time drift becomes permanent institutional memory.
• A forbidden-term list is the negative control: it flags any segment where a banned word appears, catching what terminology QA misses, including a forbidden synonym present alongside the approved term and a banned word with no approved counterpart. Grow it from the client's prohibitions, the synonym traps next to every approved term, and every drift you catch in production.
• No single control is complete and the gaps do not overlap. The terminologist is the referee who sequences and tunes the controls, knows where each one is blind, runs the find-and-verify pass, and makes the final accountable judgment. The engine knows what is probable and the tool knows what string is present; only the human knows what is approved, and an audit does not accept "the feature was enabled" as proof the rule held.