Why this needs its own service
The first generation of machine translation failed loudly. Word order was wrong, phrasing was stiff, and a reviewer could find the problems by reading for awkwardness. The awkwardness was a signal.
Large language models removed the signal. They produce text that is fluent in every sentence, including the sentences that are wrong. A reviewer reading for style will pass a confident fabrication without pausing, because nothing in the surface of the language flags it.
That is a different job, and it needs a different method: systematic comparison against the source, not a read-through of the target.
What goes wrong with LLM translation
- Fluent fabrication. The model produces a plausible term, name, dosage or figure that is not in the source. It reads perfectly. It is invented.
- Silent omission. A clause, a caveat, a conditional or a negation that is missing from the target, in a sentence that still parses as complete and sensible.
- Register drift. Formality that wanders across a document — polite in one paragraph, blunt in the next — because nothing anchored it.
- Unrequested improvement. The model tidies the source: shortens a legally load-bearing clause, resolves an ambiguity that was deliberate, drops a hedge. In legal and regulatory content, this is the dangerous one.
- Instruction leakage. Fragments of prompt, commentary, or "here is the translation:" surfacing in deliverable text.
- Inconsistent terminology across a run. The model does not remember what it decided three files ago unless something makes it.
- Negation and polarity flips. Rare, catastrophic, and invisible to anyone who does not read the target language.
Where the human is supposed to be
The workflow your suppliers are building looks like this: the engine translates, a quality-estimation model scores every segment for risk, an automated routing step decides which segments a person ever sees, and a human edits only what was flagged.
It is a sensible design. It has one structural weakness: the system that decides what a human should look at is the same kind of system that produced the errors. Nothing in that loop checks the segments it decided were fine.
We work at both points. We post-edit what your pipeline flags, and — where the content justifies it — we sample what it passed. When a routing model is letting real errors through, that is a fact worth knowing before a regulator or a customer finds it.
What we deliver
- The reviewed file, edited to the level agreed.
- An error report scored against MQM, categorised by type and severity, so you can see whether your pipeline's problem is accuracy, terminology, register or something structural.
- Pass-through findings. Where we sampled segments your system did not flag, what we found there, and at what rate.
- A named reviewer with qualifications on record, and a separate second pass by a different person.
That second output — the report on what your pipeline is failing at — is usually worth more than the corrected file. A corrected file fixes today's job. The report tells you where the system will fail again.
Engine and model comparison
Because we do not sell an engine, we can compare them.
The strongest independent evidence available says there is no universal winner. In a 2025 benchmark, the system that ranked first in German, French, Italian and Chinese ranked ninth in Korean and eighth in Arabic. The researchers' own conclusion was that no single solution serves every language.
Most companies have standardised on one engine across their whole language set, usually on the strength of how it performed in European languages. If that describes you, there is a good chance it is the wrong engine for at least one pair you rely on, and it is a cheap thing to find out.
Send us source content and we will run it through more than one system, score the output by language pair and content type using the same error framework, and hand you the comparison. What you do with it is your business — we do not take a commission from any of them.
Common questions
How is this different from ordinary post-editing?
The failure modes are different. Classic engine errors announced themselves — clumsy phrasing told a reviewer where to look. LLM output is fluent everywhere, including where it is wrong, so errors have to be found by checking against the source systematically rather than by reading for awkwardness.
Which models do you work with?
All of them, and we have no preference. We work with output from the frontier LLMs, from dedicated translation engines, and from the agentic pipelines that chain several of them together. We do not sell an engine, so we have nothing to defend.
Can you review output from our internal pipeline?
Yes. If your pipeline already flags segments by risk, we can work to your flags and audit them — including checking a sample of what the flagging system passed, which is the part most companies never check.