A localization buyer’s guide to getting more from your linguistic validation
You’re running AI QA on your translated content. Flags come back. You send the report to your language service provider and wait for the issues to be resolved. The delivery comes back cleaner. Job done.
Except there’s a step in the middle that most projects don’t account for — and if it isn’t being done properly, your QA process is giving you the appearance of quality control without the substance of it.
That step is linguistic validation: the expert review that sits between an automated flag and a defensible resolution. Understanding what it involves, why it requires specialist judgment, and how to scope it explicitly will change what you get out of every translation quality review — faster turnarounds, fewer disputes at delivery, and an audit trail that holds up when it needs to.
This guide explains how it works and what to look for in your current setup.
Key Takeaways
- AI QA tools generate a list of flagged segments; they don’t tell you which ones are actually wrong.
- Every flag requires a trained linguist to investigate, classify, and resolve. That process is called linguistic validation.
- The true/false positive/negative framework explains why automated QA outputs are the beginning of quality review, not the end.
- Scoping it separately gives you visibility, accountability and produces a documented audit trail that holds up under compliance scrutiny and enterprise procurement requirements.
What Your AI QA Tool Is Actually Telling You
When your QA platform scans a translation and produces a report, it’s doing something specific: it’s checking each segment against a set of rules. Inconsistent terminology. Missing or transposed numbers. Punctuation anomalies. Glossary deviations. Perhaps even a fluency score.
The output is a flag list. Each entry says: *this segment triggered condition X.*
That’s it. The tool is not telling you the segment is wrong. It’s raising a hypothesis.
Think of it as a spell-checker for translation. A spell-checker flags “their” when you meant “there,” but it also flags correctly spelled technical terms it doesn’t recognise, proper nouns, intentional stylistic choices, and dialect variants. The flag is always a prompt to look again. It is never, on its own, a verdict.
Your AI QA tool works the same way. The question is: who looks again, and what do they do when they look?
The Four Outcomes Every QA Flag Can Have
To understand why linguistic validation can’t be automated, it helps to see QA the way quality professionals do. Every flag your tool produces lands in one of four categories:
| Flagged by tool | Not flagged by tool | |
| Actual error | True Positive | False Negative |
| Not an error | False Positive | True Negative |
True positives are what everyone wants to find: a real error the tool correctly caught. The linguist confirms it, drafts a correction, and the quality of your content improves. This is the case clients imagine accounts for most of the report.
False positives are far more frequent than they appear. Your tool flags a number formatted differently, but your target locale requires that format. It flags a term as inconsistent, but the translator used a contextually appropriate variant that your glossary didn’t anticipate. It flags a segment as potentially untranslated, but it’s a product name that should never be translated. Each of these takes a linguist 3 to 10 minutes to investigate, document, and close out with a written rationale.
False negatives are the ones that matter most in regulated or high-stakes content. These are errors your tool missed entirely: a translated claim that’s technically accurate but legally ambiguous in the target market, a dosage instruction that reads fluently but inverts a critical qualifier, a term that matches your glossary but carries the wrong connotation in this specific therapeutic context. No AI QA tool currently in production catches these reliably. The only mitigation is a linguist reading for meaning.
True negatives are the goal: clean segments your tool correctly left alone. A mature validation program maximizes this outcome, but you can only confirm it by doing the investigation.
Here’s the implication that most clients miss: a QA report with 200 flags and a 97% pass rate is not reassuring if the 3% includes a false negative on a safety instruction. The flag count tells you about your tool’s sensitivity. Only linguistic validation tells you about the quality of your content.
What Linguistic Validation Actually Involves
When you send a QA report to your language partner and ask for the flags to be resolved, you’re requesting a defined set of professional tasks. Most clients don’t know these tasks have names, time costs, or expertise requirements. Here’s what happens — or should happen — between the report and the corrected delivery.
Flag triage.
A qualified linguist reviews each flag, opens the segment in context, checks the source document, the translation memory, the style guide, and the project brief, and determines whether the flag is a true positive, a false positive, or needs escalation to a subject-matter expert. This is a judgement call. It can’t be delegated to an administrative assistant or done accurately by someone unfamiliar with the domain.
Disposition documentation
For any quality program with an audit trail (required under ISO 17100, essential in regulated industries, and increasingly expected in enterprise procurement), each flag needs a recorded verdict with a rationale. “False positive: client-approved abbreviation format per Style Guide v3.2, section 4.1.” That note took 90 seconds to write and required the linguist to actually look something up. Multiply it by 200 flags.
Correction drafting
Where a true positive is confirmed, the linguist drafts a replacement segment. This isn’t copy-editing: it requires understanding why the original translator made their choice, ensuring the correction doesn’t introduce a new issue, and verifying the fix against your terminology assets.
Response reporting
Many clients expect a structured response to their QA report: how many flags were reviewed, how many were valid, what the confirmed error rate is against your acceptance threshold, and a list of what was corrected. Producing that report is a separate task, not a byproduct of the corrections.
Threshold adjudication
If your QA results in an error rate that triggers a contractual quality clause, someone needs to apply your agreed severity weightings to each confirmed error, calculate the result, and advise on whether the delivery passes or fails. In projects with mixed content types (legal disclaimers alongside marketing copy, for example), this calculation can be genuinely complex.
None of these steps are included in a per-word translation rate. They weren’t before AI QA tools existed, and they aren’t now. What has changed is that you can now generate hundreds of flags in seconds. If nobody on your side or your partner’s side has been explicitly tasked with working through them, those flags are not improving your content quality. They’re just sitting in a report.
What This Means for How You Scope Your Projects
Linguistic validation delivers its full value when it’s scoped explicitly from the start. Without a defined framework, the process tends to become informal: flags are reviewed quickly, documentation is sparse, and neither side has a clear basis for evaluating the outcome.
A well-scoped validation workstream resolves this by defining the things that cause friction when they’re left unspecified: who runs the tool and when, what turnaround times apply on both sides, how findings are documented, what acceptance threshold the delivery will be judged against, and how validation work is priced — typically per-flag or hourly rather than per-word.
When these elements are agreed at briefing stage, quality reviews become faster and less contentious. You know what you’re getting. Your language partner knows what they’re accountable for. It also gives you what you need to justify the process internally: a clear cost structure and a documented outcome that regulatory affairs, legal, or procurement colleagues can evaluate on its own terms. If you ever need to demonstrate compliance, the audit trail is already there.
The QA Configuration Problem You May Not Know You Have
One more thing worth understanding: your QA tool is only as good as its configuration. A tool running against an out-of-date glossary will generate high false positive rates on terminology. A tool with the wrong language variant settings will flag every instance of British English as an error in a document destined for the UK. A tool with miscalibrated severity weightings will make minor punctuation issues look as serious as factual errors.
When you receive a QA report with an unexpectedly high flag count, the first question shouldn’t be *”what went wrong with the translation?”* It should be *”is the tool configured correctly for this project?”*
A tool configuration review at the start of any new project takes about an hour at kick-off and prevents weeks of friction at delivery. It’s a standard part of how we onboard new projects: checking that the glossary version is current, that language variant settings match your target markets, and that severity weightings reflect your content priorities. If you’re switching platforms or expanding into a new language pair, it’s worth building that review explicitly into your project timeline.
Frequently Asked Questions
What’s the difference between AI QA and linguistic validation?
AI QA tools scan translations against configurable rules and produce a list of flagged segments. Linguistic validation is the expert process of reviewing each flag, determining whether it represents a real error, classifying its severity, documenting the finding, and drafting corrections where needed. QA tools produce inputs to human judgement; they don’t replace it.
How do I know if linguistic validation should be a separate line item in my project?
If your project involves a QA review pass after translation delivery, whether run by your team or ours, then validation is already part of the workflow. The question is whether it’s been scoped and documented as such. A good indicator: if your content is regulated, or if quality disputes are a recurring friction point at delivery, validation deserves its own defined scope. Book a discovery call and we’ll walk through your current setup to advise on how to structure it.
What documentation do we provide after a validation pass?
Every validation pass includes a disposition report: a written rationale for each flag reviewed, noting whether it was confirmed, dismissed, or escalated, along with the corrected segments where applicable. This gives you a clear picture of what was found and why, and serves as your compliance record if you work in a regulated industry.
What is an acceptance threshold and should we define one together?
An acceptance threshold sets the maximum error rate at which a delivery is considered compliant, typically expressed as a number of critical, major, or minor errors per thousand words, weighted by severity. Defining it before the project starts removes ambiguity at delivery stage and makes quality reviews faster for both sides. We recommend setting it at briefing stage as part of the project scope.
Who runs the QA tool, and how does that affect the workflow?
Both models work well when they’re clearly defined upfront. When we run QA internally, we resolve most flags before delivery and hand you a pre-validated document with a summary report. When you run QA on your side, we agree at kick-off on the report format and response timeline so there are no surprises at delivery. What matters most is that the process is agreed before the project starts, not negotiated after the fact.
Conclusion
AI quality assurance tools are genuinely useful. They surface issues faster than manual review, they’re consistent, and they create a documented record of the review process. But they don’t make quality decisions, and the difference matters more than it might appear.
In a Phrase TMS Auto LQA test we ran on a patient-facing medical device document, the tool flagged a potentially serious dosage mistranslation — “1.2 mL” rendered as “2.0 mL” — at exactly the same severity level as a missing tag error that had no effect on the delivered text. Both came back as Major Accuracy errors. A report like this doesn’t tell you which flags represent real risk and which can be safely dismissed. Only a linguist can do that.
Understanding what happens between a flag and a clean document helps you ask better questions at briefing stage, scope more accurately, and get more out of every project. It also makes the relationship with your language partner more productive: less time spent on disputes, more time spent on content that actually works in your target markets.
If you’d like a clearer picture of how your QA process is performing, book a discovery call. We’ll review your current setup and show you how to get faster turnarounds, fewer disputes, and a cleaner audit trail on every project.
—
*This article references industry standards including ISO 17100:2015 (Translation services: requirements), the MQM-DQF harmonised quality framework (TAUS/QTLaunchPad), and ASTM F2575 (Standard Guide for Quality Assurance in Translation).*
