In our Polyglot project, we built a translation workflow for an agency in Latvia handling documents such as passports, court files and medical reports. The platform brings scan recognition, translation memory, AI translation, a second model's quality check and human approval into a nine-stage process.
The engineering problem starts before translation: deciding which data crosses the boundary between the agency's server and a cloud model. We placed personal-data masking, the recovery mapping and document reconstruction on the agency's server. Here is how those responsibilities connect through the workflow.
1. Keep masking and the recovery map local
The system detects names, addresses, passport numbers and account numbers, then replaces them with masks before sending text to a cloud model. The published case also describes recognizers for local document formats with checksums. Detection quality needs its own evaluation across the document types and languages a deployment handles.
The cloud model translates the masked text using the client's glossaries. The encrypted table connecting masks to original values stays on the agency's server. That table is what lets the workflow recover the original values during reconstruction.
This separation gives the data-flow review a concrete object to follow: the recovery map. Translation needs the surrounding text and terminology; reconstructing the final document needs the original values. Keeping those responsibilities separate makes the outbound boundary easier to describe and inspect.
It also makes the local side of the workflow important. The public case describes an access-log entry whenever an original personal value is displayed. Reviewing who can see a value becomes part of reviewing the product's actual operator actions.
2. Include the second model in the data-flow review
Polyglot uses a second model from a different vendor to check the first model's translation. It flags doubtful segments and suggests corrections, giving the editor a queue of decisions to work through. The published workflow keeps personal-data recovery on the agency's server after the cloud stages.
That means a useful architecture review follows both model calls: the translation request and the checking request. For each, the team needs to understand what text, instructions and context are sent, and where the result goes next. Adding a checking model adds another external processing step to that review.
One screen in our case study shows four flagged segments out of 209. It illustrates the editor's interface and decision queue. The human still owns the approval decision; a flag count on one screen does not establish an overall translation error rate.
3. Reconstruct the document and preserve human responsibilities
After the cloud stages, original values are restored locally and the document is rebuilt with its formatting. The published deliverables include DOCX, PDF and an electronic-signature package. Reconstruction connects the translated segments back to something the agency can actually deliver.
The surrounding workspaces matter here. Project managers coordinate orders and pending decisions. Translators work with segments, translation memory, glossaries and comments. In-house editors check recognized scans and approve delivery. The server prevents someone from closing a review of their own work, making that separation part of the workflow itself.
Existing language assets also stay in the process: the case reports a migration of 1.5 million translation-memory segments and support for 24 languages. Delivered orders add to their client's memory, with separate client databases. Those details make the model calls part of a larger translation system with explicit ownership and handoffs.
Six questions for a similar engineering review
These are general review questions to bring to a team designing this kind of workflow:
- Which document types, languages and entity formats does detection cover?
- What else can leave the server: filenames, extracted scan content, metadata or error messages?
- How are repeated values and values embedded in images handled?
- What exactly do the translation model and the checking model each receive?
- Who can recover or display original values, and what access evidence remains?
- How does an incomplete reconstruction reach a human before delivery?
Source: Our published Polyglot case study.
Disclosure: drafted using AI from March Code's published project materials. Project figures are company-reported.
Top comments (1)
Keeping the recovery map on the agency's server is the detail that makes this work. If the mapping travels with the masked text, the masking is mostly cosmetic. Curious how you handle context that identifies someone without matching any pattern, like a rare job title plus a small town in a court file? That's where pattern-based detection tends to miss. We went the other way with ERIS and keep the model itself on the company's own servers, so nothing needs to cross the boundary at all, but for translation quality I can see why a cloud model is tempting.