Three editors, one brief, three completely different outputs. One rewrote every segment from scratch. One fixed only spelling errors. The third did something in between - and honestly, that one was closest to right. All three read the same document before starting. The problem wasn’t that they ignored the brief. The problem was that the brief didn’t tell them what they actually needed to know.
Writing an effective post-editing brief is one of those skills that looks simple and isn’t. Most PMs know what they want from the output - but translating that into written instructions a post-editor can act on, consistently, across 10,000 words they’ve never seen before? That’s the hard part.
Here’s what actually needs to be in the document.
Why most post-editing briefs don’t work¶
Research on MTPE workflows published in The Journal of Specialised Translation found that even experienced translators struggle to apply standard post-editing guidelines consistently. The reason: most guidelines are either too general (ISO 18587’s light vs. full distinction leaves “gray zones” that individual editors fill in differently) or too specific to one project (a brief written for a legal document reused unchanged for marketing copy).
The result is variability. One study found that up to 34% of edits in MTPE workflows were unnecessary - editors made changes the brief didn’t require, and no one stopped them because the brief never said “don’t.” That’s extra time, extra billing, and quality that’s harder to QA because you’re comparing against a moving target.
The light/full post-editing labels are the biggest culprit. The distinction made sense when MT output was clearly machine-sounding. Today, with neural MT and LLM-based translation, output often reads fluently while containing subtle meaning errors. A post-editor who relies only on the label “light” without specific guidance will make decisions based on their own judgment - and that judgment varies.
The light vs. full distinction: define it for THIS project¶
Don’t start your brief with a generic definition of light and full post-editing. Everyone in MTPE knows the general definition. What they don’t know is what it means for your specific project, your specific client, and the specific MT engine you ran the content through.
Define it with examples:
| Situation | Light PE (this project) | Full PE (this project) |
|---|---|---|
| Awkward but accurate sentence | Leave it | Rewrite to match human style |
| Wrong terminology (not in glossary) | Fix to closest match | Fix using official glossary term |
| Missing negation (“can” instead of “cannot”) | Always fix | Always fix |
| Misplaced number or date | Always fix | Always fix |
| Passive voice where active is preferred | Leave it | Rewrite |
| Style inconsistency across paragraphs | Leave it | Fix to match document style |
This table takes 10 minutes to create and eliminates half the judgment calls your editors would otherwise make differently from each other.
The 7 sections a post-editing brief needs¶
1. Project context - not just the project name¶
Editors make dozens of micro-decisions per hour. The more they understand WHY this content exists, the better those decisions will be.
Include: what the content is for, who the end reader is, what happens to the text after post-editing (goes to print, gets published online, stays internal). Also: which MT engine or AI tool was used. GPT-4o output has different failure modes than DeepL output. An editor who knows they’re working with DeepL knows to watch for stilted syntax and overlong sentences. An editor working with LLM output knows to watch for plausible-sounding additions that weren’t in the source.
One paragraph is enough. But that paragraph needs to exist.
2. Quality level with concrete examples¶
State the level (light or full), then immediately show an example of what that means in practice. A before/after pair is worth 500 words of explanation:
Source (English original): “The device must be disconnected from power before any maintenance operation.”
MT output: “The device should disconnect from power before every maintenance operation.”
Light PE expected: “The device must be disconnected from power before any maintenance operation.” - fix “should” to “must” and “every” to “any,” leave everything else.
Full PE expected: Same correction, plus review for style consistency with the rest of the document.
This anchors the abstract “level” instruction to something editors can reference when they hit an ambiguous segment.
3. Error priority framework¶
Specify three tiers of errors and what to do with each:
Critical - always fix, no exceptions: - Meaning errors (mistranslations that change what the text says) - Omissions (anything dropped from the source) - Numbers, dates, measurements, names - Content with legal, safety, or medical implications
Major - fix in full PE, flag and fix in light PE if quick: - Grammar errors that impair readability - Terminology that doesn’t match the glossary - Sentence structure that makes the text hard to parse
Minor - fix in full PE only, leave in light PE: - Register inconsistencies - Punctuation preferences - Style issues that don’t affect meaning
This framework, drawn from the ISO 18587:2017 MTPE standard and refined for practical use, gives editors a decision rule instead of a judgment call. When in doubt about which tier an issue falls into, they default to the lower tier in light PE and the higher tier in full PE.
4. Terminology and glossary¶
Two failure modes to avoid:
Too thin: “Please use the approved glossary.” What glossary? Where is it? What if a term isn’t in it?
Too cumbersome: A 400-row terminology table attached as a separate file that no editor opens before starting a 2,000-word segment batch.
The workable middle ground: include the 20-30 most critical terms directly in the brief - source term, required target term, and a one-line rationale if the choice isn’t obvious. For everything else, link the full glossary and specify the fallback rule (“if a term isn’t in the glossary, use the most common equivalent in the target domain, then flag it for review”).
Also specify do-not-translate items as a separate list: product names, brand names, UI strings, legal entity names, placeholders. Don’t bury these in the glossary. Editors miss this and translate what shouldn’t be translated more often than any other error type.
5. Style and tone¶
Keep this section short and specific. Long style descriptions don’t get read. Editors need:
- Register: formal / informal / neutral
- Person: first person, second person, third person
- Voice: active preferred, or passive acceptable
- Sentence length: match source, or adapt to target language norms
- Any specific patterns to avoid (e.g., “never use contractions,” “avoid passive with ‘was’”)
If there’s a style guide document, link it - but also extract the 3-5 rules that matter most for THIS content and put them directly in the brief. Assume the full style guide won’t be opened unless the editor hits a specific question.
6. Do-not-edit zones¶
Every post-editing project has segments that should not be touched. Most briefs don’t list them. Then the editor “improves” a legal disclaimer, a UI string renders broken in the software, or a previously reviewed segment gets overwritten.
List the categories: legal boilerplate (exact wording required), previously reviewed and locked segments, trademarks and registered brand names, formatting codes, placeholders, tags.
If you use a CAT tool, lock these segments at the project level - don’t rely on the brief alone. But the brief should still name the categories so editors understand why certain segments are locked.
7. The decision rule: when to keep, when to retranslate¶
This is the section most briefs skip, and it’s the one that matters most for productivity.
Post-editors spend the most time on borderline segments - the ones where the MT output is partially right. Without a decision rule, editors deliberate. They try to fix, partially succeed, try again, spend 3 minutes on one sentence.
The rule: if fixing a segment takes more than 20-30 seconds in light PE, retranslate from scratch. In full PE, the threshold is longer, but there should still be a threshold.
As Linearis puts it in their MTPE instructions: “Make quick decisions (3 to 5 seconds max per segment)” for the triage pass, and “retranslate when the raw MT doesn’t make any sense.” A rule like this, written explicitly in your brief, prevents the productivity collapse that happens when editors try to salvage every segment regardless of effort.
Include the specific language: “If fixing a segment takes more than [X] seconds and the MT output changes meaning, retranslate it. Do not try to keep as much MT text as possible - accuracy matters more than MT leverage in this project.”
Or the opposite, if MT leverage is your priority: “If the meaning is correct, keep the MT output even if it sounds awkward. Your job is accuracy, not style, on this project.”
One of these is true for your project. Write it down.
How to tell if your brief is working¶
Pilot before you scale. Take one file, assign the same 500-word excerpt to two different editors with the same brief, compare outputs. If the outputs look significantly different, the brief has gray zones you haven’t closed. Find where decisions diverged and add specificity to those sections.
Track revision rates by editor across projects. If one editor consistently produces much higher word counts than others for “light PE,” they’re over-editing. If another consistently shows low revision rates on full PE, they’re under-editing. The brief should narrow that gap - if it doesn’t, it’s not detailed enough.
Collect feedback at the end of the first project. The question isn’t “was the quality good?” It’s “which instructions were unclear or missing?” The answers will improve your next brief faster than any internal QA review.
Common mistakes that make briefs useless¶
Reusing the same brief across content types. A brief written for technical manuals produces wrong output when applied to marketing content, and vice versa. The error priorities are different, the style expectations are different, the glossary coverage is different. Maintain at least three brief templates: technical, marketing, and legal/regulated content.
Too long to read before starting. If your brief is longer than two pages, editors skim it. They’ll absorb the first section and the last, and miss everything in between. Put the most critical instructions at the top, use tables and bullet points, and cut anything that isn’t directly actionable.
No examples. Abstract instructions (“maintain appropriate register”) produce variable results. Before/after examples for the quality level and error priority sections remove ambiguity. Add at least three examples from the actual content type.
Missing the feedback mechanism. A brief is a living document. If editors can’t flag unclear instructions during the project, the brief stays broken. Build in a channel for questions and make clear that flagging is expected, not a sign of incompetence.
Managing terminology context inside translation tools¶
If your workflow includes AI-assisted translation tools that support brief or context fields, the brief information doesn’t have to live only in a separate document. Tools like ChatsControl let you set domain, audience, tone, and a terminology list before the translation runs, so the AI draft already reflects those preferences before post-editing begins. That narrows the gap between MT output and the target quality level, and means your brief is working with the tool rather than against it.
This isn’t a replacement for a written brief - post-editors still need the full context document. But it reduces systematic issues they need to correct, which means they spend more time on genuine ambiguities and less time fixing recurring patterns. ChatsControl also has a standalone QA validator that can be used to check post-edited output against terminology and error criteria before final delivery.
FAQ¶
What’s the difference between a post-editing brief and a style guide?¶
A style guide describes overall linguistic preferences for a client or language pair - it’s general and long-lived. A post-editing brief is project-specific: it specifies the PE level, the error priorities for this content, the specific glossary terms that apply here, and the decision rules for this MT engine’s output. The brief references the style guide for general register and punctuation preferences, but it doesn’t replace it.
How long should a post-editing brief be?¶
One to two pages maximum for the core document, plus any attached glossaries. If it’s longer, split it: put critical instructions on page one, supporting detail in an appendix. Editors read page one. They reference the appendix when they hit a specific question.
Do I need a different brief for light and full post-editing?¶
One brief works fine - structure it with a “light PE” and “full PE” column or section. What matters is that the scope for each level is defined in the same document. Two separate documents fall out of sync when you update one and forget the other.
What if MT quality is so poor the brief doesn’t help?¶
Then the problem isn’t the brief - it’s the MT output. Set a pre-evaluation step before assigning to editors: run a sample through a quick human check. If more than 30-40% of segments need full retranslation, you’re no longer doing MTPE - you’re doing human translation with MT as a rough reference. Either choose a better-suited MT engine or budget for full human translation from the start.
Should post-editors be allowed to ask questions during the project?¶
Yes, and tell them explicitly that questions are expected. Silence doesn’t mean editors understand the brief - it often means they’re making assumptions. A dedicated channel (Slack thread, CAT tool comment function, or a shared doc) for brief questions dramatically improves first-project output quality.
What is ISO 18587 and do I need it?¶
ISO 18587:2017 is the international standard for post-editing of machine translation output. It defines competencies, workflow requirements, and quality expectations. You don’t need certification to run a good MTPE project, but the framework is useful for structuring your brief and aligning expectations with clients who ask about your QA process. Language service providers working with enterprise clients increasingly encounter ISO 18587 compliance as part of vendor qualification requirements.