It is 9:40 on a Tuesday and a project manager named Petra drops three files into your queue with one line of instructions: "Light PE on all of these, client wants them by end of day, budget's tight." You open the first one. It is a batch of nine thousand product descriptions for an outdoor-gear catalog, machine-translated into German, every segment already pre-populated and reading smoothly. The second is the user-facing onboarding flow for a banking app, forty screens of strings. The third is a four-page reseller agreement, an actual contract, that someone in legal apparently ran through the same engine as the socks and the carabiners. Petra has put one label, "light PE," on all three. And here is the thing you have learned to feel in your stomach by now: that single label is wrong on at least two of these files, and if you obey it without thinking, you will either burn the client's budget polishing throwaway prose, or you will under-edit a contract and ship a confident, fluent, legally binding mistranslation with your name on the delivery. This lesson is about the decision Petra just made badly, and about how to make it well: how to match post-editing effort to the content in front of you, what "light" and "full" actually change at the level of an individual segment, why the revised ISO 18587 turned those two boxes into a spectrum, and how to avoid the two opposite failures of over-editing a throwaway and under-editing a thing that can sue.

The Two Words and What They Really Mean

Let us start with the vocabulary, because almost everyone in the industry uses these words loosely and the looseness is where the money and the liability leak out. Post-editing (PE) is the act of a human editing machine output rather than translating from a blank page. Machine translation (MT) is any system that renders text from a source language into a target language with no human writing the words, whether that is a dedicated neural machine translation (NMT) engine or a general-purpose large language model (LLM) that translates as a side effect of predicting plausible text. Machine-translation post-editing (MTPE) is the named workflow built around post-editing: the engine drafts every segment (the unit a CAT tool, or computer-assisted translation tool, breaks the text into, usually a sentence), and the human revises. ISO 18587 is the international standard that defines the requirements for that human post-editing work, and for a decade it gave the field exactly two named levels of effort.

Light Post-Editing, Defined by What It Changes

Light post-editing (light PE) aims at a single target word: understandable. The brief, stated plainly, is to intervene only enough to make the meaning correct and comprehensible, and then to stop. You fix outright mistranslations. You fix anything that confuses or misleads. You fix errors that would send a reader to the wrong conclusion. And then you take your hands off the keyboard, even when the sentence is clunky, even when you would have phrased it more elegantly, even when a synonym would read better. The defining discipline of light PE is the prohibition on preferential edits: changes that make the text better by your taste but that were not actually wrong. If the machine wrote a grammatically correct, accurate, slightly stiff sentence, light PE leaves it stiff. The output is permitted to read like a machine produced it, as long as a reader will understand it correctly and not be misled.

This is harder than it sounds, and it is the single most common place new post-editors waste a client's money. The instinct of a trained linguist is to improve prose. Light PE asks you to suppress that instinct on purpose, to look at a serviceable sentence and consciously decide not to touch it. The mental test for every potential edit under a light brief is one question: is this change fixing an error, or is it expressing my preference? If it is the second, your hands come off the keyboard. A useful way to internalize it: under light PE you are not the author and you are not even the editor in the literary sense. You are the safety inspector. You are there to stop the reader from being misled, not to make the prose sing.

Full Post-Editing, Defined by What It Changes

Full post-editing (full PE) aims at a different target word: indistinguishable. The output has to read as though a competent human translator produced it from a blank page, with no tell that a machine started it. Under a full brief you fix everything light PE fixes, the mistranslations and the comprehension errors, and then you keep going: you fix style, register, terminology, locale conventions, flow, the rhythm of a sentence, the consistency of a term across forty screens. You make preferential edits, because under full PE your professional judgment about what reads well is part of the deliverable. The brief is to produce a translation at the quality a client would expect from full human translation. Full PE costs more and takes longer because you are doing nearly the entire job of a translator, just starting from a draft instead of from nothing.

So the cleanest way to hold the two in your head is this. Light PE asks: will the reader understand this correctly? If yes, leave it. Full PE asks: would a discerning reader believe a skilled human wrote this? If not, fix it. Light PE forbids preferential edits; full PE invites them. One is a floor on meaning; the other is a ceiling on quality.

Light PE makes it understandable and forbids you from polishing. Full PE makes it indistinguishable from human and requires you to. The difference is not how hard you read; it is what you are allowed to change once you have read.

Why Two Boxes Became a Spectrum

Here is the problem with the two-word map, the problem the revised ISO 18587 exists to fix. Light and full are defined by how much polishing the output gets. But the thing that actually matters in your queue this morning is how dangerous a hidden error would be. Those are two different axes, and the two-box model fused them into one. It assumed a clean correlation: low-polish effort for low-risk content, high-polish effort for high-risk content. The catalog gets light, the homepage gets full, and effort tracks consequence because somebody decided it would.

In a world of clumsy machines, that fusion was tolerable, because rough output and risky output tended to coincide in your attention: you were reading hard either way. The new machines broke the correlation. An LLM produces output that is already fully fluent, already indistinguishable on the surface, while being silently wrong underneath. Now the "how much polishing" question is nearly meaningless, because the machine already polished everything to a mirror shine. The only real work left on a dangerous segment is verification: reading the gorgeous target sentence against the source and confirming the gorgeous sentence is also true. And the measured evidence for why this is not paranoia is blunt. Studies of LLM output on medical content found error rates of roughly 59% on drug names, roughly 60% on dates and times, and roughly 66% on adverse events, every one of those errors delivered in grammatically perfect, confident prose. Fluency stopped being a signal of correctness. The engine writes the wrong dose with exactly the same calm authority as the right one.

This is precisely why the revised ISO 18587, in DIS (Draft International Standard) ballot with publication targeted for late 2025 into 2026, retires the rigid light-versus-full split in favor of an effort spectrum. Instead of forcing every file into one of two boxes, the spectrum treats post-editing effort as a continuum matched to the content, the risk, and the client's quality target. Why does this matter at your keyboard? Because real content does not divide into "make it understandable" and "make it indistinguishable." A great deal of content needs minimal stylistic work but rigorous verification of a handful of safety-critical or legally-critical facts, a combination the light-versus-full vocabulary literally could not express. Light PE said "do not verify too hard, just make it readable." Full PE said "polish everything." Neither one said "polish lightly but verify the dosages with your life," which is exactly what an enormous amount of real content needs.

The spectrum lets you separate two questions the old model glued together: how much surface polish does this content need, and where in this content would a silent error cause real harm. You can answer them differently. You can apply light stylistic effort and maximum verification effort on the very same file. That is not a contradiction under the spectrum; it is the normal case. And the revision drives the point home with a second change that should reorganize how you price yourself: it requires the post-editor to hold the same linguistic competence as a professional translator. Not a lighter machine-cleanup competence. The full thing. Because catching the silent fluent error is a translator's deepest judgment, not a button-pusher's reflex, and only someone who could have produced the translation themselves can reliably tell whether the machine produced the right one.

The old map measured polish. The spectrum measures consequence. Ask not "light or full" but "how much polish, and where is the lie that would hurt."

Three Files, Three Decisions

Now back to Petra's queue, because the abstraction only earns its keep when it changes what you do with the catalog, the banking app, and the contract. Petra labeled all three "light PE." Let us make each decision properly, on the two axes the spectrum gives us: surface polish needed, and verification depth needed.

File One: The Nine Thousand Product Descriptions

This is the file light PE was invented for, and on this one Petra is right. The content is high-volume, low-shelf-life, low-consequence: a description of a waterproof jacket in a catalog of fifty thousand items. Nobody frames it. If the prose is slightly stiff, no harm is done. The economically correct pass is the cheapest one that preserves meaning. So your decision is genuinely light PE, light verification: read each segment fast, fix the outright mistranslations and anything that misleads a shopper about what the product is or does, and resist every preferential edit. When the engine renders a sentence as accurate-but-clunky, you leave it clunky and move on.

But notice the one place even a throwaway carries a thin thread of risk: the parts of a product description that make a factual claim with a consequence. A material composition ("100% waterproof," "flame-resistant"), a size or capacity figure, a safety instruction printed on a child's product, a compatibility claim ("fits all 2024 models"). These are tiny islands of higher consequence in an ocean of harmless prose. The spectrum says: keep your polish effort at floor, but lift your verification effort on exactly those islands. You are still doing light PE on 95% of every segment. You are doing pointed source-verification on the few claims a customer could act on and be harmed or refunded over. That is a distinction the old "light PE on the catalog" label could not make, and it is the difference between a fast, cheap, and defensible pass and a fast, cheap, and reckless one.

File Two: The Banking App Onboarding Flow

Here is where Petra's label starts to fail. A banking app's onboarding flow is client-facing, brand-sensitive, and consequential in two distinct ways at once, which is exactly why the two-box model chokes on it. On the surface-polish axis, this content needs to be near the top: it is the first thing a new customer sees, it carries the bank's brand, and stiff machine-stilted German on screen one tells a customer the product is cheap and foreign. That argues for full PE on style and register: the strings must read like a native product writer wrote them, not like an engine. So the polish answer is "high," not "light."

On the verification axis, the consequence is also high but for different reasons. App strings are riddled with the things engines silently corrupt: a flipped negation in a permissions prompt ("we will not share your data" becoming "we will share your data"), a mistranslated legal disclosure, a confused instruction in an identity-verification step, a placeholder or variable that the engine helpfully "translated" and thereby broke. And app strings carry locale and length constraints that a contract does not: a German string that is correct but 40% longer than the source can overflow a button and break the UI. So the verification answer is also "high," and it includes a category, format and length and placeholder integrity, that the catalog never had.

The honest decision here is not "light PE." It is high on both axes: full post-editing for style and brand, plus rigorous source-verification on negations, legal disclosures, and instructions, plus a format check on placeholders and string length. If you had silently obeyed "light PE," you would have shipped stilted brand-damaging German with a possibly-flipped privacy negation inside it. This is the file where you go back to Petra, before you start, and say: "Two of these are not light PE. Here is why, and here is what it costs."

File Three: The Reseller Agreement

This is the file that can end a relationship or a career, and "light PE" on it is close to malpractice. A contract is dense with the exact elements LLMs corrupt most confidently: legal obligations (which party owes what to whom), conditions and exceptions ("except where," "provided that," "notwithstanding"), negations and prohibitions, indemnity and liability allocation, dates and deadlines and notice periods, and defined terms that must be rendered identically every single time they appear. A single flipped obligation, "the Reseller shall indemnify the Supplier" becoming "the Supplier shall indemnify the Reseller," is a fluent, grammatical sentence that reverses who is on the hook for millions. Light PE, which forbids you from verifying too hard and tells you to stop at "understandable," is structurally incapable of catching that, because the flipped sentence is understandable. It just means the opposite of the source.

The correct decision is the top of both axes, and arguably a decision that this content should never have been on an MTPE workflow at all. On the surface-polish axis you need full PE, because legal register and precise terminology are part of correctness in a contract, not decoration. On the verification axis you need maximum effort, source-against-target, segment by segment, on every obligation, every condition, every negation, every defined term, every number and date. And there is a real question, which belongs in your note to Petra, of whether a binding legal agreement should have been machine-drafted in the first place or routed to full human translation by a legal-domain specialist. The spectrum does not mean "everything can be post-edited if you turn the effort dial up." It means effort tracks consequence, and at the extreme of consequence the right answer is sometimes "this leaves the MT pipeline entirely." Recognizing that this contract is mislabeled and possibly misrouted is itself the professional act. The thing that turns the spectrum from a slogan into a skill is the willingness to push the file back up the chain rather than quietly under-edit it because the ticket said "light."

The Two Failures You Must Avoid

Every post-editing decision can fail in two opposite directions, and the spectrum exists to keep you off both cliffs. Naming them sharply makes them easier to feel coming.

Over-Editing a Throwaway

The first failure is over-editing: spending full-PE effort, and especially preferential edits, on content that only needed light PE. You take the nine thousand product descriptions and you lovingly rewrite each clunky-but-accurate sentence into elegant prose. It feels like craftsmanship. It is actually a quiet act of budget destruction. The entire economic logic of light PE is that low-consequence content gets the cheapest pass that preserves meaning. Light PE prices as low as about two cents a word precisely because the post-editor is not supposed to be polishing. The moment you start making preferential edits on a throwaway, you are doing full-PE work at a light-PE price, which means you are either eating the cost yourself, blowing the deadline, or burning a budget the client allocated for something that matters more. Over-editing is not generosity. It is a misallocation of the most expensive resource in the pipeline, which is your attention, onto content that did not earn it. The discipline is to look at a serviceable machine sentence and consciously choose to leave it alone, and to feel that restraint as professionalism rather than as cutting corners.

There is a subtler version of over-editing that erases the MTPE economics entirely: if you full-edit everything regardless of brief, you have quietly converted a hybrid workflow back into manual translation, and you have given away the productivity that makes the whole model viable. A linguist on a disciplined MTPE workflow moves from roughly 2,000 words a day toward 5,000 or more. That lift only exists if light content actually gets light effort. Over-edit the throwaways and you have thrown the lift away.

Under-Editing a Contract

The second failure is the dangerous one: under-editing, applying light-PE effort to content where a silent error has real consequence. This is the contract shipped with a flipped indemnity, the drug label with a corrupted dosage, the banking app with an inverted privacy negation. Under-editing is seductive precisely because the machine output is fluent. Under a light brief, you read for "is this understandable," the sentence reads perfectly, you accept it, and you move on, never having checked the one thing that mattered: whether the beautiful sentence means what the source meant. The light-PE discipline of "don't over-edit" curdles, on high-consequence content, into "don't actually verify," and that is how a Critical error ships in a file that looked clean.

The defense is the spectrum's core move: decouple polish from verification. Even when the surface-polish brief is light, the verification brief on high-consequence elements is never light. Treat a fixed set of elements as never-trust-the-fluency zones and check each against the source independently of how smoothly it reads: negations and prohibitions; numbers, dosages, units, and currency; drug names, proper names, and approved terms; dates, times, and durations; legal obligations and which party owes what; and adverse-event and safety descriptions. If your file contains these and you are about to apply light PE to them, you are about to under-edit, and the standard now formally expects you, as a full-competence post-editor, to know better.

Over-editing burns the budget on prose nobody reads. Under-editing ships the fluent lie that sues. The spectrum keeps you off both cliffs by letting polish and verification move independently.

The Money: Why the Decision Pays

This is not an aesthetic argument. The effort decision is a pricing decision, and getting it right is the difference between a defensible professional rate and a race to the bottom. Hold the numbers in your head, because clients will quote them at you.

MTPE typically prices at roughly 50 to 75% of full human translation, which lands in the neighborhood of five to fifteen cents a word, against full human translation that might be double. Light PE can be priced as low as about two cents a word, because the brief is genuinely lighter: meaning-only, no polishing, no preferential edits. Those numbers are the economic skeleton of the whole industry's shift to MT-first, and they are why a client who read that machine translation is "good enough" arrives wanting everything at the light-PE floor.

Here is where your spectrum judgment becomes leverage. When a client or a PM pushes for two-cent light-PE pricing on the contract or the banking app, the old vocabulary left you with nothing but "trust me, it needs more." The revised standard hands you a precise, authoritative answer. The content sits where consequence is high, the standard requires effort matched to consequence and a post-editor holding full translator competence, and therefore this content is not light-PE work and cannot carry a light-PE price. You are not being difficult or padding the invoice. You are being conformant. The same standard that lets you price the catalog at the floor, honestly, because it genuinely is light work, lets you price the contract as full post-editing by a full-competence professional, defensibly, because it genuinely is the most demanding work in the field: finding the one fluent lie among a thousand beautiful true sentences.

That is the whole economic point of learning to read the spectrum. The post-editor who labels everything "light" to win the bid gets commoditized and eventually gets sued over a flipped clause. The post-editor who labels everything "full" to protect themselves burns budgets and loses the throughput that makes MTPE viable. The post-editor who reads each file on both axes, prices the catalog cheap and the contract right, and can name the standard that justifies each, is the one whose role moves up the value chain instead of away. The decision Petra made badly at 9:40 this morning, one label across three files, is the exact decision that, made well, is your professional differentiator.

A Working Method for Every File

Pull it together into something you can run on the next file that lands, before you touch a single segment. The method is four questions and one habit.

Question one: what is the consequence of a silent error in this content? Not how polished does it need to look, but what happens if one fluent sentence means the opposite of the source. A refund? A confused shopper? A privacy breach? A recall? A lawsuit? This answer sets your verification floor, and it is the question the old light-versus-full label skipped entirely.

Question two: what surface quality does the audience and the brand require? Internal and disposable, or customer-facing and brand-carrying? This answer sets your polish level, and it is independent of question one. The banking app is high on both; the catalog is low on polish but has small islands that are high on verification.

Question three: does this content belong on an MTPE workflow at all? Some content, regulated, life-safety, binding legal, is high enough in consequence that the right answer is full human translation by a domain specialist, not post-editing at any effort level. The spectrum includes its own edge: the point where you take the file off the conveyor and route it to a human from scratch. Recognizing that edge is part of the skill, not a failure of it.

Question four: where exactly are the high-consequence elements? Mark them, literally, before you start: the numbers, negations, obligations, terms, dates, and safety claims. These get source-against-target verification no matter what your polish level is. This is the move that separates the two axes and keeps you off both cliffs.

And the one habit underneath all four: when the label on the ticket does not match the content, say so before you start, not after you ship. "Light PE" on a contract is not an instruction to obey; it is a misclassification to flag. The thirty seconds it takes to send Petra "two of these are not light PE, here is why, here is the cost" is the cheapest insurance in localization, and it is the moment you stop being the machine's cleanup crew and start being the quality owner the machine cannot replace.

Key Takeaways

• Light PE aims at "understandable" and forbids preferential edits: you fix mistranslations and anything that misleads, then take your hands off the keyboard even on clunky-but-accurate prose. Full PE aims at "indistinguishable from human" and requires preferential edits: style, register, terminology, flow, all of it. Light asks "will the reader understand correctly?"; full asks "would a discerning reader believe a human wrote this?"
• The light-versus-full split measured surface polish (how much you change), not consequence (how dangerous a hidden error is). It broke when LLMs replaced clumsy NMT with fluent output that is polished on the surface and silently wrong underneath, evidenced by medical error rates of roughly 59% on drug names, 60% on dates and times, and 66% on adverse events, all in perfect prose.
• The revised ISO 18587, in DIS ballot with publication targeted for late 2025 into 2026, retires the rigid two-box split for an effort spectrum that matches effort to content and risk, and it requires the post-editor to hold full professional-translator competence, because catching a silent fluent error is a translator's judgment, not a button-pusher's reflex.
• The spectrum's core move is to decouple two axes the old model fused: how much surface polish the content needs, and where in it a silent error would cause harm. You can apply light stylistic polish and maximum verification on the same file, which is the normal case for most real content.
• The two failures the spectrum prevents are over-editing a throwaway (full-PE preferential edits on light-PE content, which burns the budget and erases the MTPE throughput lift from roughly 2,000 to 5,000+ words a day) and under-editing a contract (light-PE effort on high-consequence content, which ships the fluent lie that sues).
• On high-consequence elements, verify source against target regardless of polish level: negations and prohibitions; numbers, dosages, units, currency; drug names, proper names, approved terms; dates, times, durations; legal obligations and who owes what; and adverse-event and safety descriptions.
• The decision is a pricing decision. MTPE runs at roughly 50 to 75% of full human rates (about five to fifteen cents a word) and light PE as low as about two cents; the spectrum and the competence requirement let you honestly price the catalog at the floor and defensibly refuse light-PE pricing on a contract or a banking app, because that content is the most demanding work in the field, not the cheapest.
• Run four questions on every file before touching a segment: what is the consequence of a silent error; what surface quality does the audience and brand need; does this belong on an MTPE workflow at all; and where exactly are the high-consequence elements. And when the ticket's label does not match the content, say so before you start, because flagging a mislabeled contract is the act that turns you from cleanup crew into quality owner.