It is 4:40 on a Friday, the client's batch is due at 5:00, and the file in front of you looks finished. A 6,800-word set of medical-device instructions, machine-translated into French, post-edited all afternoon, run through the severity-scored evaluation you built last week. The summary line at the top of the report is almost perfect: forty-one segments touched, nine Minor errors logged, two Major errors fixed and re-checked, a normalized quality score of 96 out of 100. Every instinct you have, and every ounce of deadline pressure, says ship it. Then your eye catches one entry near the bottom of the error log, flagged by the evaluator an hour ago and never dispositioned: segment 318, accuracy, severity Critical. The source warns that the device must not be used while charging. The French target, fluent and idiomatic and indistinguishable from the clean prose around it, says the device may be used while charging. One inverted instruction, four words long, buried under a 96 and a deadline. The whole question of this lesson is what happens next, and the answer is not negotiable: that 96 does not matter, that deadline does not matter, the file fails, and it does not move until segment 318 is fixed and re-verified. A delivery gate is the formal go/no-go checkpoint a file must pass before it leaves your hands, and the one-Critical-fails rule is the single hardest line in it. This lesson is about how to design that gate so it survives a client audit, why it has to be non-negotiable, how to run it when the clock is against you, and how to make the call on exactly the file just described.

What a Delivery Gate Actually Is

Most linguists already have a delivery gate. They just have a bad one, and they do not call it a gate. It lives in their head, it fires the moment the file "looks done," and its decision rule is the most dangerous sentence in the craft: looks fine to me, send it. That is a gate built on a holistic impression of the prose, and as the earlier lessons in this program established, a holistic read is calibrated to exactly the thing a machine gets right (the fluent surface) and blind to exactly the thing it gets wrong (the meaning underneath). A gate built on vibes passes the dangerous file precisely because the dangerous file reads beautifully. The work of this lesson is to replace that invisible, intuition-driven gate with an explicit, written, evidence-driven one that a stranger could operate and an auditor could inspect.

Let us fix the vocabulary first, used precisely throughout. A delivery gate (sometimes a quality gate or a go/no-go gate) is a formal checkpoint, with written criteria, that a deliverable must pass before it is released to the client. Go/no-go means the gate produces a binary outcome and only a binary outcome: the file either passes and ships, or it fails and does not, with no third "ship it with reservations" option. A Critical error is the highest severity band in the MQM (Multidimensional Quality Metrics) and ISO 5060 typology: an error that renders the content dangerous, legally exposed, unusable, or actively misleading on a point that matters, such as an inverted safety instruction, a corrupted dosage, a wrong drug name, or a flipped indemnity clause. MQM is the analytic error-typology framework that classifies translation errors by dimension and severity; ISO 5060:2024 is the international standard, published in 2024, that formalizes an MQM-aligned model for the human evaluation of translation output. MT is machine translation; an LLM is a large language model, a general-purpose text predictor that translates as a side effect; MTPE (or PE) is machine-translation post-editing, the workflow where a human edits machine output. A segment is the unit a translation tool works in, usually a sentence, the row in a CAT tool (computer-assisted translation tool, the editing environment). A TMS is the translation-management system the file moves through. A termbase is the controlled glossary of the client's approved terms, and a TM (translation memory) is the store of previously approved translations. A locale is a specific language-and-region combination such as French for France.

A delivery gate is the line between "I think this is fine" and "I can prove this is shippable." Everyone has the first one in their head. The job is to build the second one on paper.

Why the Gate Became Non-Optional in 2026

The gate is not new bureaucracy invented to slow you down. It exists because three forces converged and made the old informal review fatal. The first force is the failure mode itself: MT and LLM output is fluent first and accurate second, and studies of LLM output on medical content found error rates around 59% on drug names, 60% on dates and times, and 66% on adverse events, every one delivered in grammatically perfect prose. The errors that survive into a finished file are, by selection, the ones that read perfectly, which is to say the ones a holistic review cannot catch. The second force is throughput: a hybrid MT-first workflow lifts a linguist from roughly 2,000 words a day to 5,000 or more, which means more content flowing past your eyes per hour and less time per segment, exactly the conditions under which a buried error slips. The third force is accountability: the revised ISO 18587 (in DIS ballot, publication targeted for late 2025 into 2026) makes the post-editor formally accountable as a full-competence professional translator, and "the engine wrote it" is explicitly not a defense. Put those together and the conclusion is forced. You are shipping more fluent-but-possibly-wrong content faster than ever, you are personally on the hook for every Critical that escapes, and the only review method that catches the dangerous error is a structured analytic one. A formal gate is simply that method, written down so it fires every time instead of only when you happen to feel careful.

The Five Parts of the Gate

A delivery gate that survives an audit is not a single yes/no question; it is a small machine with five named parts. Each part has a job, and skipping any one of them is how files fail in the field. We will walk through all five, then run a real file through the whole thing in the final section. The five parts are: entry criteria (what must be true before the gate even runs), the Critical veto (the one-Critical-fails rule), the weighted threshold (the score-based pass line for everything below Critical), the disposition and rework loop (what happens to a file that fails), and the sign-off (the human accountability record that closes the gate). Hold the whole shape in your head: entry, veto, threshold, loop, sign-off. A gate missing entry criteria runs on garbage; a gate missing the veto ships the killer error under a good score; a gate missing the threshold lets a thousand Minors through; a gate missing the loop has no idea what to do when it says no; a gate missing sign-off has no one accountable when the audit comes.

Entry Criteria: What Must Be True Before the Gate Runs

Entry criteria are the preconditions a file must satisfy before it is even eligible to be scored at the gate. They are the gate's bouncer, and they exist because running a severity evaluation on an incomplete or mis-prepared file wastes the evaluation and produces a meaningless verdict. A score of 98 on a file that was never run against the correct termbase is not a 98; it is noise. The standard entry criteria for an MT-first delivery are concrete and checkable:

• Completeness. Every source segment has a target. No empty segments, no untranslated source left in the target, no truncated file. A gate cannot score what is not there.
• Correct linguistic assets attached. The file was post-edited against the right project termbase, the right TM, and the current style guide, in the correct locale. Scoring against the wrong glossary measures the wrong thing.
• Risk tier confirmed. The content's risk tier (the consequence classification assigned at intake: marketing string versus drug label versus indemnity clause) is recorded, because the tier sets how strict the rest of the gate is. High-liability content does not get the lenient threshold.
• Format and tag integrity. Placeholders, inline tags, and length constraints are intact; the file imports cleanly back into the TMS. A broken placeholder is itself a potential Critical in software content.
• An evaluation was actually run. There is a severity-scored error log for this file, produced by the analytic evaluation, not a holistic "I read it and it's good." No evaluation means no entry.

Entry criteria are deliberately mechanical and binary, because they are easy to check and easy to automate, and because a file that fails them should never consume an evaluator's expensive judgment. The gate's clever work, the Critical veto and the weighted threshold, only earns its keep on files that are genuinely complete and correctly prepared. Think of entry criteria as the cost of admission: cheap to verify, and they keep the expensive part of the gate honest.

The Critical Veto: One Critical Fails the File

This is the spine of the entire gate, the rule the lesson is named for, and the one part you must never let anyone argue you out of under pressure. The Critical veto states: if the file contains one or more Critical errors, the file fails, full stop, regardless of the score, the deadline, or how clean everything else is. A Critical is not a heavy weight in an average; it is a veto. It does not get balanced against the ninety clean segments around it. It does not get traded off against a 96. It is a hard stop that overrides every other signal the gate produces.

The reason a Critical is a veto and not a weight is a fact about how harm works, not a fact about arithmetic. Averaging assumes errors are fungible, that enough good cancels out some bad, the way a high grade-point average absorbs one low grade. Harm is not fungible. The patient who acts on the one inverted "may be used while charging" instruction is not protected by the flawless translation of the other 6,796 words. The reader who signs the contract with the one flipped indemnity clause is not made whole by the elegant rendering of the boilerplate. A Critical error's consequence lands on whoever hits exactly that segment, and that person experiences none of the file's average quality. So the gate refuses to average a Critical at all. It treats a single Critical as disqualifying, which is mathematically the same as assigning it an infinite penalty: no quantity of clean content can buy it back.

A Major is a weight you add up. A Critical is a veto you cannot outvote. The whole gate is built so that one Critical, anywhere, in a file of any size, with any score, means no.

Practically, the veto runs first, before you even look at the weighted score. The gate's logic is ordered on purpose: check entry criteria, then count Criticals, and only if the Critical count is zero do you proceed to the weighted threshold. This ordering is not cosmetic. It encodes the priority. It means the very first question the gate asks of a finished file is never "what is the score?" but "are there any Criticals?" If the answer is yes, the score is irrelevant and you stop. That ordering is what stops a high score from seducing you past a buried killer, which is exactly the trap segment 318 set on that Friday afternoon.

The Weighted Threshold: The Pass Line Below Critical

The Critical veto handles the catastrophic error. The weighted threshold handles the accumulation of everything below it: the Majors and Minors that no single one of which fails the file, but enough of which mean the file is not good enough to ship. This is the part of the gate that uses the normalized quality score the evaluation produces. Recall the mechanics from the scoring lesson: each non-Critical error is assigned a penalty by severity (classically 1 point for a Minor, 5 points for a Major, with the exact constants set per project), the penalties are summed, the total is normalized against the evaluated word count (typically expressed per 1,000 words), and a quality score, often on a 0-to-100 scale, is derived. The weighted threshold is simply the pass line on that score: a file at or above the line passes the threshold; a file below it fails.

The threshold is not a single universal number. It is set per risk tier, and that is the whole point of confirming the tier at entry. A marketing blog might pass at a threshold equivalent to a couple of minor blemishes per thousand words, because the consequence of a slightly awkward sentence is low. A drug label or a financial disclosure demands a far stricter threshold, because the tolerance for any defect at all is near zero. Setting the threshold by tier is how the gate matches strictness to consequence instead of applying one blunt standard to everything. A high-liability file does not merely need zero Criticals; it needs a near-spotless weighted score on top of that, because a cluster of Majors in a contraindication section is its own kind of unacceptable even if none of them individually rose to Critical.

Two disciplines keep the threshold honest. First, set it before you score, not after. A threshold you adjust downward once you see the result is not a threshold; it is a rationalization. The pass line is part of the agreed gate definition, fixed in advance, ideally written into the project's quality agreement with the client. Second, the threshold never overrides the veto. A file can clear the weighted threshold with a beautiful 96 and still fail on a single Critical. The two checks are independent, and the veto is supreme. The threshold is a necessary condition for shipping; it is never a sufficient one.

Disposition and Rework: What Happens When the Gate Says No

A gate that can only say "fail" and then leaves you standing there is half a gate. The disposition and rework loop is what the gate does with a failed file, and it is the part that turns a verdict into a process. Disposition is the act of deciding, for each flagged error, what is to be done about it: fix it, confirm it is a false positive, or escalate it. A flagged error that is never dispositioned, the way segment 318 sat un-dispositioned for an hour, is the single most common way a known Critical ships anyway. The error was caught. The evaluation did its job. Then nobody decided what to do, the deadline arrived, and the file went out with the flag still open. Disposition is the discipline that closes that gap: every flagged error must be explicitly resolved, and the gate does not pass while any Critical remains in an open or unresolved state.

The rework loop is the corrective path. When the gate fails a file, the loop routes it back to a post-editor to fix the dispositioned errors, then back through the relevant checks again. The crucial design rule is the scope of the re-check after a fix:

• Fix the flagged error, then re-verify the fix against the source. A correction is not done until someone confirms the new target now means what the source means. A rushed fix can introduce a new error, so the fix itself is evaluated, not assumed.
• Re-run the veto on the corrected file. Any Critical must be re-checked to confirm it is genuinely resolved and that the fix did not create a fresh one nearby. The gate's first question, "are there any Criticals?", must be answered "no" on the corrected file, not on the original.
• Watch for the systemic signal. If the same kind of Critical shows up repeatedly across files, the disposition is not just "fix this segment" but "fix the process": the engine is mishandling negations, or the termbase is missing a critical term, or the risk tier was set too low. The loop feeds the pipeline, not just the file.

The loop is also where deadline reality gets negotiated honestly. A failed high-liability file with an open Critical and twenty minutes left does not become a passed file because there is no time. It becomes a file that is late, or a delivery that is partial (ship the clean, hold the section with the Critical), or a deadline the project manager renegotiates with the client. What it never becomes is a shipped file with a known Critical inside it. The loop gives you those honest options. The absence of a loop gives you only the dishonest one.

The Sign-Off: Who Is Accountable When the Gate Closes

The final part is the sign-off: a named human recording that this specific file passed this specific gate on this date, with the evaluation evidence attached. It is the moment accountability becomes concrete and personal. The sign-off is not a rubber stamp; it is the assertion, by a qualified person, that the entry criteria were met, the Critical count was zero, the weighted score cleared the tier's threshold, and every flagged error was dispositioned. It is the human standing behind the go decision.

The sign-off matters for a reason that goes to the heart of the program's cardinal rule: accountability never transfers to the engine. When a client audits a delivery, or worse, when a Critical does escape and there is an incident, the question is always "who released this, and on what basis?" A gate with a sign-off answers that question with a name, a date, and an attached evaluation record. A gate without one answers it with a shrug. Under the revised ISO 18587, which insists the post-editor hold full professional-translator competence and own the output, the sign-off is the artifact that demonstrates a competent human made the release decision against documented criteria. It is what converts "I think it's fine" into "I, a qualified linguist, certify on this date that this file met these criteria, and here is the evidence." That sentence is the credential, and the sign-off is where it gets written down.

Why the Gate Must Be Non-Negotiable

Every part of the gate above can be operated rigorously and still fail at the one moment that matters, because the gate's real test is not whether it works on a calm Tuesday. It is whether it holds at 4:50 on a Friday with a client on the phone. A gate that bends under pressure is not a weaker gate; it is no gate at all, because pressure is precisely the condition under which Criticals ship. So the non-negotiability is not stubbornness. It is the entire function. Let us be concrete about why each tempting exception is a trap.

The Deadline Argument

The most common pressure is time: there is no time to fix the Critical, so ship and patch it Monday. This feels pragmatic and is catastrophic, because the consequence of a Critical does not wait for Monday. The inverted dosage instruction is read by a patient on Saturday. The flipped indemnity clause is signed on Friday evening. The window between "shipped" and "patched" is exactly the window in which the harm the Critical can cause actually happens. A deadline is a commercial inconvenience; a shipped Critical is a clinical or legal event. They are not the same kind of thing, and trading one for the other is trading a missed appointment for an accident. The honest move under deadline pressure is never to lower the gate; it is to use the rework loop's honest options, late delivery, partial delivery, or a renegotiated deadline, all of which the next section makes operational.

The "It's Probably Fine" Argument

The second pressure is doubt about the call itself: maybe this isn't really a Critical, maybe I'm being too strict. This is a real question and it has a real answer, but the answer is "disposition it properly," not "wave it through." If there is genuine uncertainty about whether an error is Critical, the disposition is to escalate, to a senior reviewer, a subject-matter expert, or the client, and resolve it on the record, not to resolve the uncertainty in favor of shipping because shipping is convenient. The asymmetry is brutal and worth internalizing: the cost of holding a file that turns out to have been fine is a few hours and an awkward conversation. The cost of shipping a file that turns out to have a real Critical is a harmed reader, a lost client, and your name on the delivery. When the downside is that lopsided, you resolve uncertainty by checking, never by hoping.

The "But the Score Is Great" Argument

The third pressure is the seductive number: the file scored 96, surely a 96 ships. This is the trap the gate's ordering is specifically built to defeat, and it is worth seeing clearly why the score is irrelevant to the veto. The 96 is a measurement of the file's average quality. The Critical is a measurement of a specific reader's worst experience. Those are different quantities, and the gate's design keeps them separate on purpose. A high score tells you the file is mostly excellent, which is true and which the Critical does not contradict. The Critical tells you that one specific point in the file will harm one specific reader, which is also true and which the 96 does not soften. Both facts are real. The gate ships on the second one, because a file's job is not to be excellent on average; it is to be safe everywhere it is read.

The score measures the file's average. The veto measures a reader's worst case. A delivery has to be safe everywhere it is read, not just on average, which is why the worst case wins.

There is also a quieter, structural reason the gate must be non-negotiable: a gate that bends is unmaintainable as a standard. The instant the rule becomes "one Critical fails the file, except when the deadline is tight, or the score is high, or someone senior overrides it," it stops being a rule and becomes a negotiation, and a negotiation has no stopping point. Two evaluators applying a hard rule reach the same verdict; two evaluators applying a negotiable rule reach two different ones, and the gate loses the comparability and defensibility that were the whole reason to build it. The non-negotiability is what makes the gate a thing an auditor can trust and a client can rely on. Soften it once and you have quietly converted your provable quality tier back into "trust me."

Operating the Gate Under Deadline Pressure

Holding the line is a principle. Operating it without melting down on a Friday is a practice, and the practice has concrete moves. The goal is to make the gate fast enough and the failure path honest enough that holding the line is the path of least resistance, not an act of heroism you have to summon each time.

Front-Load the Veto Check

The single most important operational habit is to run the Critical check early and on the highest-consequence content first, not last and not uniformly. Deadline disasters happen when the Critical surfaces at 4:50 because the high-risk safety section was reviewed in the same pass and at the same depth as the boilerplate. Instead, the moment a file enters, identify its high-consequence elements, the negations, the numbers, the dosages, the obligations, the safety instructions, the indemnity language, and verify those against the source before anything else. If a Critical exists, you want to know at 2:00, when there is time to fix it, not at 4:50, when there is not. The gate's ordering (veto before threshold) should be mirrored in your schedule: check the things that can fail the file first, polish the things that only affect the score last.

Pre-Agree the Failure Path With the PM and Client

The reason the gate feels impossible to hold under deadline is usually that no one decided, in advance, what happens when it fails. So the failure becomes an improvised crisis at the worst possible moment. The fix is to make the failure path a known, boring procedure agreed before the deadline ever arrives. Concretely:

• The PM knows the gate exists and what a fail means. A failed gate is not a surprise the linguist springs at 4:55; it is a defined outcome the project manager has already planned for, with the client expectation set that a Critical means a hold.
• Partial delivery is a pre-defined option. If the Critical is isolated to one section, the clean sections can ship on time and the affected section follows, instead of holding the entire batch or shipping the whole thing dirty.
• The escalation contact is known in advance. When an error's severity is genuinely uncertain, you know exactly who decides, the senior reviewer, the subject-matter expert, the client's reviewer, and how to reach them fast, rather than scrambling for an answer with the clock running.
• "Late and correct" is an accepted outcome, in writing. The quality agreement says, before the project starts, that a Critical triggers a hold and a renegotiated time, so a late high-liability delivery is honoring the agreement, not breaking it.

When the failure path is pre-agreed, holding the gate stops being a confrontation. You are not refusing to deliver; you are executing the procedure everyone already signed up for. The pressure that used to push toward shipping the Critical now has somewhere honest to go.

Keep the Evaluation Fast Enough to Survive 5,000 Words a Day

A gate so slow that meeting throughput requires skipping it is a gate that will be skipped. So the gate has to be proportionate. This is where the risk tier earns its keep a second time: the depth of the gate scales to the consequence. Low-risk content gets a light, fast gate, a completeness check, a quick scan for the obvious failure modes, a threshold check. High-liability content gets the full, slow, exhaustive treatment, because that content is where the throughput target should bend, not the gate. The mistake is applying the same heavy gate to a marketing string as to a drug label (which makes the gate unaffordable and gets it skipped) or the same light gate to both (which lets a medical Critical through). Match the gate's weight to the content's consequence, and the gate stays both rigorous where it must be and fast enough to live with everywhere else. Speed and safety align only when you spend your gate's effort where the consequence actually is.

A Worked Gate Decision: The Friday File

Return to the file from the opening: 6,800 words of French medical-device instructions, machine-translated, post-edited all afternoon, due at 5:00. Let us run it through all five parts of the gate, in order, exactly as you would on the day, and make the call out loud with the reasoning showing. This is the whole lesson made concrete.

Step 1: Entry Criteria

First, is the file even eligible for the gate? You check the mechanical preconditions. Completeness: all 6,800 words have targets, no empty or truncated segments, confirmed. Linguistic assets: the file was post-edited against the project's medical termbase and the current French style guide, in the fr-FR locale, confirmed. Risk tier: recorded at intake as high-liability medical, which means the strict threshold applies and the gate runs at full depth, confirmed. Format integrity: tags and placeholders intact, the file imports back into the TMS cleanly, confirmed. Evaluation present: yes, there is a severity-scored error log produced by the analytic evaluation this afternoon. Entry criteria pass. The file is eligible. Notice that nothing here is about quality yet; entry is purely "is this a real, complete, correctly prepared file we can meaningfully score?" It is, so we proceed.

Step 2: The Critical Veto (Runs First)

Now the supreme check, and it runs before you ever glance at the 96. You go to the error log and count Criticals. The log shows: nine Minor errors, two Major errors (both already fixed and re-checked this afternoon), and one entry flagged an hour ago and never dispositioned, segment 318, accuracy, severity Critical. You open segment 318 and read it against the source. Source: the device must not be used while charging. Target: the device may be used while charging. This is a mistranslation in the accuracy dimension, an inverted prohibition, and its consequence is a patient using a medical device in a state the manufacturer explicitly forbids. That is dangerous and actively misleading on a point that matters. The severity flag is correct: this is a Critical.

The Critical count is one. The veto fires. The file fails the gate. Note what you did not do: you did not look at the 96, you did not weigh the one Critical against the nine Minors and two fixed Majors, you did not consider that it is 4:50. None of those entered the decision, because the veto runs first and is supreme. One Critical, file of any size, score of any value, deadline of any tightness: fail. The decision took the time it took to read one segment against its source.

Step 3: The Weighted Threshold (Now Moot)

For completeness, what about the 96? Under the weighted threshold for a high-liability tier, a 96 with the Critical excluded would itself need scrutiny, but the question is academic, because the veto already failed the file and the threshold cannot un-fail it. The threshold is a necessary condition for shipping that this file would still have to meet on its non-Critical errors; it is never a sufficient condition that can override the veto. The score was never going to save this file, and that is by design. We record the score for the quality record and move on. The gate's verdict is already no.

Step 4: Disposition and Rework

Now the gate does its constructive work. Disposition segment 318: this is a confirmed Critical, the action is "fix," and the fix is to correct the French so the prohibition is restored, the device must not be used while charging. A post-editor makes the correction. Then the re-verification: someone reads the corrected target against the source and confirms the meaning now matches, that the negation is present and correct and that the fix did not garble the surrounding sentence. The corrected segment is re-checked, and the veto is re-run on the file: Critical count now zero. Only now is the file eligible to pass.

You also notice the systemic signal worth logging: this was a dropped/inverted negation on a safety instruction, the program's archetypal silent Critical. If this engine has produced inverted negations before, the disposition is not only "fix segment 318" but "flag that this engine mishandles negations on this content type," which feeds the pipeline so the next file's veto check front-loads negation verification. The loop improved the file and the process at once.

Step 5: Sign-Off, and the Clock

Here is where the deadline finally enters, honestly. The fix and re-verification take, say, twenty-five minutes. It is now past 5:00. The file is correct but late. This is the moment the gate is really tested, and the answer is the procedure, not heroics. Because the failure path was pre-agreed, the project manager already knows a Critical triggers a hold; the client expectation, set in the quality agreement, is that a high-liability medical file ships late rather than wrong. So the delivery goes out at 5:25 with a clean veto, a documented disposition of segment 318, the weighted score recorded, and your sign-off: a named, dated certification that this file met the entry criteria, carries zero Criticals, cleared the tier's threshold, and had every flagged error dispositioned, with the evaluation record attached. Twenty-five minutes late, and defensible to an auditor, a client, and a court. Compare the alternative: on time at 5:00, with a patient instructed they may use a medical device while charging, and your name on it. The twenty-five minutes was the cheapest insurance you will ever buy.

The file shipped twenty-five minutes late and completely defensible. The on-time alternative shipped a patient an inverted safety instruction. That trade is the entire job, and the gate is what makes you take the right side of it every single time.

Key Takeaways

• A delivery gate is the formal go/no-go checkpoint a file must pass before release, built on written, evidence-based criteria, not the "looks fine to me" impression that is calibrated to the fluent surface a machine gets right and blind to the meaning it gets wrong.
• The gate has five parts in a fixed order: entry criteria (completeness, correct assets, risk tier, format integrity, an actual evaluation), the Critical veto, the weighted threshold, the disposition and rework loop, and the sign-off. Skipping any one is a documented way files fail in the field.
• The Critical veto is supreme and runs first: one or more Critical errors fails the file regardless of score, deadline, or how clean the rest is, because harm is not fungible and a high average cannot protect the one reader who hits the inverted segment.
• The weighted threshold is set per risk tier and before scoring, never adjusted to fit a result, and it is a necessary but never sufficient condition for shipping; it can never override the veto.
• A flagged error that is never dispositioned is the most common way a known Critical ships anyway; every flag must be explicitly resolved, every fix re-verified against the source, and the veto re-run on the corrected file before it can pass.
• The gate must be non-negotiable because pressure (the deadline, the doubt, the good score) is exactly the condition under which Criticals ship; a gate that bends once stops being a defensible standard and reverts to "trust me."
• Operate it under pressure by front-loading the veto check on high-consequence elements early, pre-agreeing the failure path (partial delivery, escalation contact, "late and correct" in writing) with the PM and client, and scaling gate depth to risk tier so it stays fast enough to live with at 5,000+ words a day.
• The sign-off is the named, dated human certification that closes the gate and proves accountability under the revised ISO 18587; it converts "I think it's fine" into "I, a qualified linguist, certify this file met these criteria, and here is the evidence," which is the credential a raw MT vendor can never produce.