On a Tuesday morning Daniel inherited a pipeline he had never seen documented. He was the new localization program lead at a medical-device company, and his predecessor had left a single sentence in the handover doc: "We run everything through the engine, then a linguist cleans it up." That was the whole map. Six weeks later, a German distributor escalated a complaint that froze Daniel's blood: a quick-start guide for a home oxygen concentrator had shipped with a line that read, in fluent and grammatical German, "Use the device near open flame," when the source said the exact opposite. The machine translation (MT) had dropped the negation. The post-editor had skimmed past it because it read perfectly. The quality check had been a spot read of three random segments. The delivery had gone out on time, scored nothing, recorded nothing, and now sat in front of a regulator. When Daniel reconstructed what had happened, the most frightening discovery was not the dropped "not." It was that nobody could tell him where in the process the error should have been caught, because nobody had ever drawn the process. There was no map. There were just steps that happened, in an order nobody had decided on purpose, with an engine touching content that should never have been near it and a human signing a delivery they could not defend. This lesson is about the artifact that would have saved him: a source-to-delivery map where every single step is marked, before any engine runs, as MT-ready, human-only, or MT-forbidden. The map is not documentation you write after the fact. The map is the design decision that determines whether your pipeline ships speed or ships liability.

Why the Pipeline Map Is a Design Artifact, Not a Diagram

Most localization teams have a picture of their pipeline somewhere, usually a tidy left-to-right flow with boxes labeled intake, translation, review, and delivery, drawn once for a client deck and never looked at again. That picture is not what this lesson means by a map. A decorative flowchart describes what happens. A design artifact decides what is allowed to happen, and it does so at a resolution fine enough to be enforceable. The difference is the difference between a tourist map of a city and the wiring diagram an electrician works from: one orients you, the other carries decisions that, if wrong, start a fire.

The core move that turns a diagram into a design artifact is annotation at the step level. Every step in a localization pipeline is one of three things with respect to the machine, and the map's entire job is to make that classification explicit and visible before a single segment is processed. A step is MT-ready when an engine can do the first pass and a human owns the verification: the speed is captured, the risk is bounded by post-editing. A step is human-only when a person must perform it from the start because judgment, not pattern completion, is the work: the machine may assist around the edges but does not produce the deliverable. And a step is MT-forbidden when the consequence of a fluent error is so severe, or the content so regulated, that no engine output may enter the process at all, not even as a draft a human edits, because the editing itself becomes a vector for the silent error the engine introduces.

A pipeline map is a design artifact when every step carries a decision (MT-ready, human-only, or MT-forbidden) that was made on purpose, before processing, and that someone can be held to. A diagram describes the pipeline. A map governs it.

Before going further, the working vocabulary this lesson uses precisely. Machine translation (MT) is any system that turns source text into target text with no human writing the words; modern engines are neural. A large language model (LLM) is a general-purpose text predictor that translates as a side effect of broad fluency, which makes it more fluent and more confidently wrong than classic MT. Machine-translation post-editing (MTPE), often shortened to PE, is the workflow where a human edits machine output instead of translating from a blank target. A segment is the unit a translation tool works in, usually a sentence, the row a linguist sees in a CAT tool (a computer-assisted translation tool, the editing environment). A translation-management system (TMS) is the platform that orchestrates projects, files, and people around those tools. A translation memory (TM) is the database of previously approved source-target pairs the tool leverages. A termbase is the controlled glossary of a client's approved terms. Quality estimation (QE) is an automatic, reference-free confidence score a model assigns to a segment, guessing how good a translation is without a human checking it. MQM is Multidimensional Quality Metrics, the analytic error-typology framework, and ISO 5060:2024 is the standard that formalizes its Critical, Major, and Minor severity scoring for human evaluation of translation output. Localization (often l10n) is adapting content for a locale; internationalization (i18n) is engineering content so it can be localized at all. A locale is a language-and-region pairing, such as German for Switzerland. A language-service provider (LSP) is the vendor that runs this work. We will use these terms as load-bearing, not decoration.

Why the Classification Must Happen Before the Engine Runs

The timing is the whole point, and it is the part teams get wrong. It is easy to imagine catching the engine's mistakes downstream: let MT run on everything, then have a sharp reviewer find the problems. That instinct fails for a structural reason established across this program. Machine output is fluent first and accurate second. The errors it makes are not clumsy and visible; they are smooth and invisible, a dropped negation or a flipped dosage delivered in grammatically perfect prose that does not trip the reviewer's eye. A downstream check that relies on a human noticing a fluent error is relying on the one thing the failure mode is engineered to defeat. The only reliable control is to decide, before the engine touches the content, whether the engine is allowed to touch it at all. You cannot un-ring the bell of a fluent hallucination once it is in the file and a human has read past it. The classification is a gate placed upstream of the engine precisely because no downstream gate can be trusted to catch what the engine smuggles through.

This is why the map is a design artifact and not a report. A report describes a process that already ran. The map constrains a process before it runs, by assigning each step its machine status while there is still time for that assignment to matter. Daniel's predecessor had a process. What he lacked was a map made in advance that would have stamped "quick-start safety instructions for a regulated medical device" as MT-forbidden or, at minimum, full-human-post-editing-mandatory, before the engine ever pre-populated that fatal segment.

The Eight Steps of a Source-to-Delivery Pipeline

To mark a pipeline you must first see its steps clearly, because the classification is applied step by step and a step you cannot name is a step you cannot govern. A modern localization pipeline, whether it runs inside one LSP or across a client and several vendors, has eight recognizable stages. They do not always carry these names in every shop, and some collapse together in small operations, but every functioning pipeline performs all eight pieces of work. We will walk them in order, and for each one name what the work actually is, because the machine-status decision depends entirely on understanding what the step does.

Intake: Receiving and Classifying the Content

Intake is where content enters the pipeline and is classified. A file arrives, and someone (or some rule) decides what it is: a marketing landing page, a software UI string set, a legal contract, a drug label, a knowledge-base article. Intake is where the content type, the source language, the target locales, the deadline, and, most importantly, the risk tier are established. The risk tier is the classification of content by the consequence of a fluent error: a throwaway social caption and an indemnity clause are not the same risk, and intake is where that difference is recognized or lost. Intake is the step that decides every later step's machine status, because the risk tier set here propagates downstream. Get intake wrong and a drug label gets routed as if it were a blog post. This step is almost always human-only or rule-assisted-human, never fully automated, because the classification it produces is the safety decision the rest of the pipeline depends on.

Analysis: Counting, Leveraging, and Preparing

Analysis is the technical preparation: the TMS analyzes the file against the translation memory to find exact matches, fuzzy matches, and new content, counts the words, identifies the segments, extracts the tags and placeholders, and checks the termbase coverage. Analysis is largely deterministic and tool-driven; it tells you how much of the file is already translated (TM leverage), how much is novel, and what engineering hazards (placeholders, length-constrained strings, embedded code) the content carries. The output of analysis is the work plan: which segments come from TM, which will be machine-translated, which need human attention. Analysis itself is machine work, but the decisions it informs are not.

Pre-Translation: The Engine's First Pass

Pre-translation is the step where the engine runs. The TMS populates exact and high-fuzzy matches from the TM, and for the remaining new segments it calls the MT or LLM engine to produce a first draft. After pre-translation, in an MT-first pipeline, every segment in the file is filled: some from TM, some from the engine. This is the single most consequential step for our purposes, because this is where machine output enters the file. The map's classification of this step, and of the content flowing through it, is the difference between a fast first draft and a poisoned well. A step marked MT-forbidden means the engine is simply not called for that content; the segments stay empty or go to a human translator. A step marked MT-ready means the engine fills the draft and a human is contractually downstream to verify it.

Post-Editing: The Human Owns the Output

Post-editing is where a human linguist works the pre-translated file: reading machine output against the source segment, the TM, and the termbase, correcting what is wrong, and owning the result. Post-editing comes in efforts: light PE fixes only what blocks comprehension, full PE produces output indistinguishable from human translation, and the revised ISO 18587 retires the rigid two-way split for an effort spectrum matched to content. Post-editing is the human-judgment heart of an MT-first pipeline. It is where the silent critical error is meant to be caught, which is exactly why it can never be the only control: a tired post-editor under a 5,000-word-a-day quota is also fluent-first in their reading. Post-editing is human-only work by definition, but the map must specify which effort each content stream receives, because under-editing a contract and over-editing a throwaway both destroy the pipeline's economics or its safety.

Quality Estimation: Routing Effort by Confidence

Quality estimation is the automatic, model-produced confidence score that guesses, segment by segment, how good a translation is without a human reference. QE is genuinely useful in a pipeline, but only for one job: routing human effort. A low QE score flags a segment for closer human attention; a high QE score suggests a segment is probably fine. The cardinal discipline, established across this program, is that QE is a signal that routes effort, not a verdict that ships output. A high QE score on a segment with a flipped dosage is the engine being confidently wrong about its own confidence. QE is machine work, MT-ready by nature, but its output may never gate delivery on its own; it gates where the human looks first.

Evaluation: The Severity-Scored Quality Gate

Evaluation is the human analytic quality assessment: a qualified evaluator marks errors against an MQM/ISO 5060 typology, assigning each a dimension (accuracy, terminology, locale, fluency) and a severity (Critical, Major, Minor), and the file is scored. The governing rule is that one Critical error fails the file regardless of how clean the rest reads. Evaluation is the gate that turns "looks fine to me" into a defensible go/no-go with a number behind it. This step is human-only at its core, because the judgment of whether a fluent rendering means the opposite of the source is precisely the judgment the engine cannot perform on its own output. An automatic QE score can route a segment to the evaluator; it cannot be the evaluator.

Terminology and Engineering: The Cross-Cutting Controls

Two steps run alongside the main flow rather than strictly after it. Terminology is the work of building, enforcing, and maintaining the termbase so the client's approved terms hold from intake to delivery instead of drifting segment by segment as the engine substitutes fluent synonyms. Engineering (localization engineering) is the technical handling of the content's structure: extracting strings, protecting code placeholders and tags, managing length budgets for UI, handling encoding, and reintegrating the translated content into its files or build. These steps mix machine and human work intimately. Term extraction can be machine-drafted but must be human-verified before a candidate becomes a rule. Placeholder protection is machine-enforced but human-designed. The map must mark the machine status of each sub-task, because an engine that translates the inside of a code placeholder breaks the build, and an engine that invents a term breaks the regulatory submission.

Delivery: The Signed, Recorded Handoff

Delivery is the final handoff: the translated, post-edited, evaluated, terminology-correct, engineered content is packaged and sent, and someone signs that it passed the gate. Delivery is where accountability becomes concrete. "The engine wrote it" is never an answer at delivery; the person who signs owns the quality, and the revised ISO 18587 insists that person hold full professional-translator competence. Delivery is human-only in the sense that matters: a human signs and is accountable. The map's final job is to ensure that signature is defensible, backed by a quality record that reconstructs what each segment went through.

Eight steps: intake, analysis, pre-translation, post-editing, QE, evaluation, terminology and engineering, delivery. Name them before you mark them, because a step you cannot name is a step whose machine status nobody decided.

The Three Marks: MT-Ready, Human-Only, MT-Forbidden

With the steps named, we can define the three marks precisely, because the whole discipline collapses if the marks are fuzzy. These are not vibes about how much you trust the machine. They are operational definitions with different controls, different costs, and different consequences when violated.

MT-Ready: Speed Captured, Verification Owned

MT-ready means the engine performs the first pass and a human owns the verification downstream. The mark does not mean "the machine does this and we trust it." It means "the machine drafts this and a named human, with the competence to catch a fluent error, is contractually and procedurally downstream to verify it before it ships." MT-ready is the mark that captures the speed an MT-first pipeline exists to capture, and it is the right mark for the bulk of lower-liability, high-volume content: knowledge-base articles, UI strings with stable terminology, product descriptions, internal documentation, much subtitling. The control that makes MT-ready safe is not the engine's quality; it is the guaranteed presence of a competent post-editor and a real evaluation gate behind it. Remove the human verification and an MT-ready step silently becomes a raw-machine step, which is the most dangerous mark of all because it looks productive while shipping unowned risk.

Human-Only: Judgment Is the Work

Human-only means a person performs the step from the start because the work is judgment, not pattern completion, and the machine cannot produce the deliverable even as a draft worth editing. The machine may assist at the edges (a translator may consult a TM, a terminologist may machine-draft term candidates to verify) but the deliverable originates with the human. Human-only is the right mark for transcreation, where brand and cultural intent require invention the engine cannot supply; for high-stakes creative and legal drafting where a literal-but-fluent rendering kills the meaning; for the evaluation step, where the judgment of correctness cannot be delegated to the thing being judged; and for intake classification and final sign-off, where accountability lives. Human-only is not a nostalgic preference for human labor. It is a recognition that for some steps the engine's output is not a head start, it is a trap that anchors the human to a wrong frame.

MT-Forbidden: The Engine May Not Touch It at All

MT-forbidden is the strongest mark and the most misunderstood. It does not mean "MT plus careful review." It means the engine's output may not enter the process at all, not even as a draft a human post-edits, because for this content the act of editing machine output is itself a vector for the silent error. The reasoning is subtle and worth stating slowly. When a human post-edits machine output, the fluent draft anchors their reading: they are correcting a text that already asserts something, and a fluent, confident, wrong assertion is exactly the kind their eye accepts. For most content the productivity gain is worth that risk because the consequence of a missed error is rework. For a narrow band of content, the consequence of a single missed fluent error is a death or a lawsuit, and there the productivity gain is not worth a non-zero chance of anchoring a human to a confident mistranslation. So the engine is kept out entirely, and the content is translated by a qualified human from the blank target, then independently revised. This is the mark for life-safety instructions on regulated medical devices, for clinical-trial and drug-label content where a flipped dosage kills, for binding legal clauses where an inverted obligation creates liability, and for certain financial disclosures where a misstated figure is fraud. The map must carry this mark explicitly, because the default of an MT-first pipeline is to pre-translate everything, and MT-forbidden is the deliberate exception that the pipeline must be engineered to honor.

MT-ready: the engine drafts, a competent human verifies. Human-only: the human originates, because the work is judgment. MT-forbidden: the engine is kept out entirely, because for this content a fluent error is lethal and editing machine output anchors the human to it.

The Mark Applies to Both the Step and the Content Flowing Through It

A subtlety that trips up teams new to mapping: the three marks apply at the intersection of a step and a content stream, not to a step in the abstract. Pre-translation is not globally MT-ready or globally MT-forbidden; it is MT-ready for the knowledge-base stream and MT-forbidden for the drug-label stream flowing through the same step on the same day. This is why intake's risk-tiering is the keystone: the risk tier set at intake travels with the content and determines, at each subsequent step, which mark that content carries through that step. A mature map is therefore a grid, not a line: steps across the top, content streams down the side, and a mark in every cell. The single-line flowchart hides exactly the information that matters, which is that the same engine call is safe for one stream and forbidden for another.

A Worked Map: A Real Content Stream End to End

Abstraction settles only when you watch it operate, so we will map a real, mixed content stream the way Daniel should have on his first day. The client is a maker of a home medical device, a portable oxygen concentrator, expanding into German-speaking markets. Their content arrives as one quarterly drop but is not one thing; it is four distinct streams bundled together, and the entire art of the map is refusing to treat them as one. We will identify the streams, set their risk tiers at intake, and then mark each of the eight steps for each stream, producing the grid that would have stopped the open-flame disaster.

Step One: Pull the Bundle Apart at Intake

The quarterly drop contains four streams. Stream A is marketing and web content: the product landing page, email campaigns, social captions. Consequence of a fluent error: a weak campaign, brand awkwardness, recoverable. Stream B is the companion app's UI strings: button labels, settings screens, notifications, with code placeholders and tight length budgets. Consequence of a fluent error: a confusing or broken interface, mostly recoverable, occasionally serious if an instruction misleads. Stream C is the user manual and quick-start guide, including setup, maintenance, and the safety-warning sections. Consequence of a fluent error: a user operates a medical oxygen device incorrectly, which can be life-threatening, the open-flame case. Stream D is regulatory and clinical content: the instructions-for-use filed with the regulator, contraindications, and the clinical claims. Consequence of a fluent error: a regulatory rejection, a recalled device, or a death, plus legal liability. Four streams, four risk tiers, set at intake before anything else happens. A pipeline that treats this drop as "the device project" and runs it all through one workflow has already lost, because it has erased the only distinction that governs safety.

Stream A, Marketing: Mostly MT-Ready, One Human-Only Step

The marketing stream is low-liability and high-volume, the natural home of an MT-first workflow. We mark its steps. Intake: human-only (classification is always a human safety decision, even for low-risk content). Analysis: machine. Pre-translation: MT-ready, the engine drafts. Post-editing: human-only, but light-to-medium effort, because comprehension and brand-acceptable phrasing matter more than perfect fidelity on a caption. QE: machine, used to route the post-editor to the weakest segments. Evaluation: human, but a sampled lighter evaluation is defensible here, not full segment-by-segment scoring. Terminology: machine-enforced termbase, human-spot-checked. Engineering: minimal, machine-handled. Delivery: human sign-off. There is one trap inside this clean MT-ready stream: the campaign tagline. A tagline is transcreation, not translation, and transcreation is human-only regardless of the stream's overall low risk, because the engine cannot invent the cultural resonance a tagline needs. So the map carves the tagline out of the MT-ready pre-translation step and marks that one item human-only. This is the grid's resolution paying off: even a low-risk stream has a human-only island, and a single-line map would have machine-translated the tagline into fluent nonsense.

Stream B, UI Strings: MT-Ready With Engineering Guardrails

The app strings are MT-ready in principle but carry engineering hazards that change the marks. Intake: human-only. Analysis: machine, and critical here, because analysis is where the placeholders and length budgets are identified. Pre-translation: MT-ready, but the engine must be configured to protect placeholders, and any string whose mistranslation would mislead a user about a device action (a notification about oxygen flow, say) is flagged at intake into a higher sub-tier. Post-editing: human-only, full effort on the device-action strings, lighter on cosmetic labels. QE and evaluation: as marketing, with the device-action strings pulled into full evaluation. Engineering: the load-bearing step here, machine-enforced placeholder and length validation that fails the build if a placeholder was translated or a string blew its budget, with a human localization engineer owning the rules. Delivery: human sign-off plus an automated build-time check. The lesson of Stream B is that MT-ready does not mean unguarded: the engineering step adds machine-enforced guardrails that catch the format failures the linguistic gate is not looking for.

Stream C, The Manual: The Safety Sections Flip to MT-Forbidden

Here is where Daniel's disaster lived, and here is where the map earns its existence. The manual is not one risk tier. The setup and maintenance prose is high-liability but post-editable; the safety-warning sections, the do-not-operate-near-flame, the do-not-exceed-flow-rate, the contraindication warnings, are life-safety content where a single dropped negation kills. The map must split the manual. For the general manual prose: pre-translation MT-ready, post-editing human-only at full effort, evaluation full human segment-by-segment scoring with the one-Critical-fails gate armed. For the safety-warning sections specifically: pre-translation is marked MT-forbidden. The engine is not called. Those segments go to a qualified human translator working from the blank target, and are then independently revised by a second qualified human, because the editing-anchors-the-error logic means we will not let a fluent machine draft of a safety warning exist for a human to skim. Evaluation of the safety sections is full, and the gate is absolute: one Critical, the file fails, no override. Had this map existed, the open-flame segment would never have been machine-drafted; it would have been human-translated, human-revised, and human-evaluated, and the dropped negation would have had three independent humans to catch it instead of one tired post-editor reading past a fluent lie.

Stream D, Regulatory: MT-Forbidden by Default

The regulatory and clinical stream is the simplest to mark and the most consequential to get right. Its default is MT-forbidden across the translating steps. Intake: human-only, and flagged as the highest tier. Analysis: machine, for counting only. Pre-translation: MT-forbidden; no engine output enters the instructions-for-use, the contraindications, or the clinical claims. These are translated by qualified human translators with domain competence, from the blank target. Revision: a second independent qualified human, per the human-translation baseline of ISO 17100. Evaluation: full human MQM/ISO 5060 scoring, one-Critical-fails armed, plus a domain-expert review for clinical accuracy. Terminology: human-verified against the regulatory glossary, no machine substitution permitted. Delivery: human sign-off by someone accountable to the regulator, with a complete quality record. The engine's only legitimate role anywhere near this stream is non-translating support: counting words, checking the termbase coverage, flagging segments for the human. The moment its output enters the content, the stream is no longer defensible, and the map says so in the loudest mark it has.

Reading the Finished Grid as a Diagnosis

Stand back and read the four streams against the eight steps as a single grid, and something appears that no single-line flowchart could show. The same step, pre-translation, carries three different marks in the same project on the same day: MT-ready for marketing and UI, MT-forbidden for safety warnings and regulatory content, with the manual's general prose MT-ready and its safety sections forbidden. The same engine call is safe for one cell and lethal for another, and the grid is the only artifact that makes that visible and enforceable. Read down the pre-translation column and you can audit, in one glance, exactly what the machine is and is not allowed to touch in this project, before it runs. Read across a stream's row and you can see its full journey and confirm a competent human owns every step where machine output appears. The grid is simultaneously the design (it decides the marks), the control (the pipeline is configured to honor them), and the audit artifact (a regulator can read it and see that the engine was kept out of the content it must stay out of). One artifact, three jobs, and the absence of it is precisely what left Daniel unable to say where the open-flame error should have been caught.

The map is a grid, not a line. The same step carries different marks for different content streams, and only the grid makes the safe-here-forbidden-there distinction visible before the engine runs. The flowchart hides the one fact that matters.

Building, Enforcing, and Maintaining the Map

A map drawn once and filed is a diagram again. The discipline that keeps it a design artifact is the practice around it, and that practice has a few non-negotiable habits worth stating plainly so you can run them on a real operation.

Build From Consequence, Not From Volume

The instinct when designing a pipeline is to optimize for the bulk: most segments are low-risk, so design the workflow for them and treat the high-risk content as an exception you bolt on. Invert that. Build the map from the highest-consequence content first, mark its steps MT-forbidden or human-only, and then let the lower-risk streams inherit the faster marks. The reason is asymmetry: over-protecting a marketing caption costs a few cents of unnecessary human effort, while under-protecting a drug label costs a life. A map built consequence-first fails safe; a map built volume-first fails toward the disaster, because the default workflow it optimizes for is the one that machine-translates everything. Daniel's predecessor built volume-first ("run everything through the engine"), and the map he never drew would have had to be re-built consequence-first to be safe.

Make Every Mark Enforceable, Not Aspirational

A mark that the pipeline cannot enforce is a wish. "MT-forbidden" on the safety sections means nothing if the TMS is configured to pre-translate the whole file and a tired operator clicks the global pre-translate button. The mark must be wired into the tooling: the MT-forbidden content is segregated into a separate workflow or file that the engine is technically not connected to, so honoring the mark is the path of least resistance and violating it requires deliberate, visible action. Likewise, "human verification required" on an MT-ready step is a wish unless the TMS will not let the file advance to delivery without the post-editing and evaluation steps recorded as completed by a named person. The map's marks should be enforced by configuration, not by memory, because memory under deadline is exactly what fails. The strongest version of this is the machine-enforced guardrail from Stream B: a build that fails when a placeholder was translated is a mark made of code, not of hope.

Make the Map Produce the Quality Record

The map is also where provenance comes from. Because the map says what each step does to each content stream, it defines what the quality record must capture: for each segment, which stream it belonged to, what mark its pre-translation step carried, whether it was machine-drafted or human-originated, who post-edited it, what its evaluation score was, and who signed delivery. A pipeline designed from a map produces this record almost as a byproduct, because the steps that produce the record are the steps the map already named. A pipeline run without a map, like Daniel's, produces no record, which is why he could reconstruct nothing. When a regulator or a client asks "prove the engine never touched the contraindications," the answer is the map plus the per-segment record showing the MT-forbidden mark was honored. That sentence, "here is the map, here is the record, here is the proof the engine was kept out of the content it had to stay out of," is the credential a raw-MT vendor can never produce.

Revisit the Map When Content, Engine, or Standard Changes

The map is not static, because the three things it depends on are not static. When a new content type appears (the client adds a clinician-facing dashboard), it needs a stream and a row of marks before it runs, not after it ships. When the engine changes (a new LLM replaces the neural MT, more fluent and therefore more confidently wrong), the marks may need to tighten, because a more fluent engine produces more dangerous silent errors, which can push borderline MT-ready content toward MT-forbidden. When the standard changes (the revised ISO 18587, in DIS ballot with publication targeted for late 2025 into 2026, expands post-editing's scope to AI and LLM "non-human translation output" and insists the post-editor hold full professional-translator competence), the map's human-verification requirements must be checked against the new conformance bar. A map reviewed every quarter and at every material change stays a design artifact; a map reviewed never becomes the decorative flowchart it started as. The map is a living control, and its maintenance is part of running the pipeline, not a separate documentation chore.

Why the Map Is the Practitioner's Leverage in an MT-First Shop

It is worth closing on why this artifact, which can look like project-management bookkeeping, is in fact the highest-leverage thing a localization practitioner produces in the MT era. In an MT-first pipeline the engine has already commoditized the first draft; speed is no longer the scarce contribution. What is scarce, and what no engine can supply, is the judgment that decides where the engine is allowed to operate and where it is forbidden, and the design discipline that wires those decisions into a pipeline so they hold under deadline. The map is that judgment made concrete. The person who can draw it, defend each mark by consequence, enforce it in the tooling, and produce the record that proves it was honored is the person whose role moved up the value chain rather than away, exactly the shift this program is built around.

The contrast with Daniel's inherited "we run everything through the engine, then clean it up" is the whole lesson in one line. That sentence is not a pipeline; it is a hope, and hope is what shipped a fluent instruction to operate a medical device near open flame. A map turns the hope into a designed system: every step classified, every mark enforceable, every machine touch deliberate, every delivery defensible. It does not slow the pipeline down; it lets the pipeline run fast on the content where fast is safe and keeps the engine entirely away from the content where a single fluent error is a death or a lawsuit. That is the rare win this program keeps returning to, the move where the speed decision and the safety decision are the same decision, made once, on purpose, before the engine runs, and written down where a colleague, a client, and an auditor can all read it. Daniel's predecessor left a sentence. The job is to leave a map.

Key Takeaways

• The pipeline map is a design artifact, not a diagram: it decides, at the step level and before any engine runs, whether each step is MT-ready, human-only, or MT-forbidden, and someone can be held to those decisions. A decorative flowchart describes the pipeline; a map governs it.
• The classification must precede the engine because machine output is fluent first and accurate second: no downstream check can be trusted to catch a fluent error the engine smuggles through, so the only reliable control is to decide upstream whether the engine may touch the content at all.
• A source-to-delivery pipeline has eight nameable steps: intake (where risk tier is set), analysis, pre-translation (where the engine runs), post-editing, quality estimation, evaluation (the severity-scored gate), terminology and engineering (cross-cutting controls), and delivery (the signed, recorded handoff).
• The three marks are operational, not vibes: MT-ready means the engine drafts and a competent human verifies downstream; human-only means a person originates because the work is judgment; MT-forbidden means the engine's output may not enter the process at all, because for that content editing a fluent machine draft anchors the human to a lethal silent error.
• The marks apply at the intersection of a step and a content stream, so a mature map is a grid, not a line: the same pre-translation step is MT-ready for the knowledge-base stream and MT-forbidden for the drug-label stream flowing through it on the same day, and only the grid makes that visible.
• In the worked medical-device map, four streams (marketing, UI strings, manual, regulatory) carry different marks, the manual splits so its safety-warning sections flip to MT-forbidden, and regulatory content is MT-forbidden by default, which is exactly the control that would have stopped a fluent "operate near open flame" from ever being machine-drafted.
• Build the map from consequence first, not volume first, so it fails safe; make every mark enforceable in the tooling rather than aspirational; and let the map produce the per-segment quality record that proves an MT-forbidden mark was honored.
• Revisit the map whenever content, engine, or standard changes, because a more fluent engine produces more dangerous silent errors and the revised ISO 18587 (publication targeted late 2025 into 2026) raises the human-competence and conformance bar the map's verification requirements must meet.