Quick answer — Liability translation is an archive problem. The document you produce today gets retrieved by someone in another country long after the systems that made it are gone, so format longevity and version provenance matter more than throughput.
Vitra.ai Universe keeps source, translation and version history together.
Retrieval is the use case
Most content is written to be read now. A liability wording is written to be retrieved — pulled out of an archive by a claims handler responding to something that happened fifteen years ago.
Everything below follows from designing for that reader rather than the current one.
The format matrix
| Format | What it is in liability | What translation has to preserve |
|---|---|---|
| Word | Wording source and endorsement drafts | Numbering and styles, and the change history |
| PDF/A | The archived published version | Long-term readability, embedded fonts |
| Structured source | Clause library with version identifiers | Which rendering applied when |
| Excel | Schedules of insured entities and limits | Every figure, and the entity names exactly |
| PowerPoint | Broker submissions and sector briefings | Layout, and figures matching the schedule |
| Web | Product and broker pages | Least important surface in this line |
| Video | Risk-management training for professionals | Dubbed audio, since the audience watches at a desk |
| Design files | InDesign, Illustrator | Editable source, kept alongside the export |
Archive the source, not only the output
A flattened PDF is a photograph of a document. Fifteen years on, nobody can correct it, re-translate it, or check what the source said before a clause was amended.
Keeping the translatable source alongside every published version is the whole discipline in this line, and it costs almost nothing at the time.
Version provenance beats speed
The question a retrieved document has to answer is not "what does this say" but "what did this say then". Which means the archive needs to record which approved translation of a defined term was in force for a given policy period.
Translation memory used as a versioned record rather than a cache is what supplies that, and it is the reason this line values the memory differently from every other.
Entity names are not translatable
Schedules list insured companies, subsidiaries and named individuals. Those are identifiers. A translation tool that transliterates a company name has changed who is insured, which is a materially different document.
Lock them explicitly rather than trusting a reviewer to notice.
Where to start
Store the editable source in the asset library rather than a shared drive. Check that every translated wording you have published still has its source with it. Where it does not, that document is already frozen.
For everything else a liability book can automate, see AI for liability insurers.
FAQ
Why is liability insurance translation an archive problem? Because the document is written to be retrieved rather than read now, typically by a claims handler in another country responding to something that happened fifteen years earlier.
Should liability insurers archive flattened PDFs? Not alone. A flattened PDF is a photograph of a document that nobody can later correct, re-translate or check against its source, so the translatable source belongs alongside every published version.
What does version provenance mean for liability wordings? Recording which approved translation of a defined term was in force for a given policy period. The question a retrieved document must answer is what it said then, not what it says now.
Should insured entity names be translated? No, they are identifiers. A tool that transliterates a company name in a schedule has changed who is insured, so entity names should be locked explicitly rather than left for a reviewer to catch.
