Translation governance

By 2026 the industry has settled on what "translation governance" means, and it is concrete: an approved-tool allowlist, an audit trail, risk-tiered review, and a named accountable owner (Crowdin, 2026 AI Translation Report; Bluente, How to Build an AI Translation Governance Framework in 2026). Localization OS ships the instruments for every one of these. It has since before the words were fashionable: the product was built on the idea that the operator commands the machine translation, not the reverse. The one element no software can assign is the accountable owner; that is an organizational choice. What the product supplies is the role-based access control and audit attribution that make an owner's decisions traceable.

This page maps our feature names to the industry's vocabulary, so a buyer searching for trust layer, verification, auditable AI, data sovereignty, RAG, or predictive QE can see exactly where each lives in a running install. Nothing here is a roadmap item; every claim describes behavior you can run offline today.

Auditable AI#

Mutating actions are written to an append-only, tamper-evident ledger. Each row is chained to the one before it with a keyed cryptographic hash, so a downstream verifier can prove the chain has not been rewritten. The audit chain is verifiable with material the database alone does not contain, and both edits to existing rows and truncation of the log are detected.

That row structure is a field-for-field match to the settled audit-trail definition:

• the tool or action used: recorded on every row, for example a glossary approval, an engine run, or an erasure;
• the initiator: the signed-in user, an API token, or the system itself;
• the target: the project, document, key, or user acted on;
• the timestamp: every row is time-stamped in UTC;
• whether human review occurred: human sign-off is itself an audited action, such as an approval or a vendor-quote approval, and each segment's status separates machine work from a person's.

The chain is verifiable three ways: a button on the audit page, a CLI command, and an API endpoint, and it exports as newline-delimited JSON with the hash chain on every record, so a downstream SIEM can re-verify the chain without touching this database. Operator and impersonation actions are always audited; that cannot be switched off.

The result is what the regulated-industry conversation keeps asking for: not a log you hope no one edited, but a verifiable, exportable chain.

Verification#

The industry's own framing is that in some market segments, 90 to 95 percent of human-involved volume is now verification of AI output rather than translation (Stefan Huyghe, Slator, 2026). Localization OS is built as a verification machine.

• Quality gates score each translation against a structured error typology and a per-language rulebook. A card passes only when its score clears the configured bar and it carries no major or critical error. An organization sets its own bar, and a workflow step can set its own per-step threshold.
• A failed gate routes the segment to review, the exact seam a branch step turns into a correction loop.
• The protection law is the spine of it. Machine-produced and imported text can only reach a segment's target through one sanctioned write path. At that path, a segment a human has approved or edited is refused: the write is withheld, the row is left byte-untouched, and the outcome is marked as protected. A model cannot silently overwrite a human decision, and because there is exactly one write path, this holds on every surface: the web app, plain machine translation, the CLI, the API, MCP, key import, and vendor return. It is core, default-on behavior with no kill switch, and a pinned automated test defends it.

Hard translation-memory locks ride the same path: a locked segment refuses any machine overwrite, and only a reviewer clearing the lock, itself an audited action, can change it.

Approved tools and the kill-switch law#

Governance's first component is an approved-tools allowlist: deciding which models may run. Our engine and provider registry is exactly that; the operator configures which providers and models are available, with their own keys.

The reach goes further than an allowlist. A central features admin lets the operator switch off any module in a fixed registry of non-core features. For most of those modules, a switch-off removes the feature rather than hiding it: its routes answer not-found, indistinguishable from a route that was never built, so a disabled feature cannot be discovered by probing; its CLI verbs refuse; it drops from the API surface; and its MCP tool refuses when called. A few modules switch off differently by design, stopping new writes while keeping existing records readable, and a couple ship off by default as opt-ins, but the on or off test itself is a strict match, so any unrecognized value fails toward off, the safe direction. The operator decides what the install even is.

Data sovereignty#

Bring-your-own API keys is the single most-cited enterprise requirement: 88.8 percent of teams require or prefer them (Crowdin, 2026 AI Translation Report), and a self-hosted TMS is structurally strongest here. Localization OS is self-hosted; run it yourself anywhere a container runs, on your box, your database, your keys.

• Your data stays in your store: SQLite or Postgres, whichever you control. There is no hosted service you depend on; the install is the tenant boundary.
• Bring your own provider keys, or run local, self-hosted models and go fully air-gapped: no content leaves the machine.
• GDPR subject-access export and erasure are built in, and export is one command.
• PII redaction scrubs personal identifiers out of source content on the translation and quality-review paths before it reaches an engine. It is toggleable and off by default: leave it off for local models, turn it on when routing to the cloud.
• Encryption at rest comes as two opt-in layers: full-database encryption for SQLite installs (it needs an extra database driver installed at deploy time, not just a setting flip), and encrypted uploads.
• A spend-cap kill switch is a hard financial boundary: once the ceiling you set is reached, no further paid provider calls are made, and retries or failover cannot push past it. It ships off; the local and mock engines are exempt.

This is the answer to the "platform capture" critique the industry has started naming (Emily Diamandopoulou, AI Loc Think Tank, 2026): your data is portable and your exports are one command, so the tool stays replaceable.

Context and localization RAG#

Retrieval-augmented generation for localization is not a missing feature to bolt on; it is what the translation pipeline already does. Before each translation, Localization OS retrieves and injects the relevant glossary terms, style-guide sections, the resolved context package, and translation-memory matches into the prompt. That is retrieval-injection, the same shape practitioner guides tell teams to hand-roll, built in natively.

Retrieved context is treated as data, not instructions: external metadata is allowlisted, sanitized at ingestion, and fenced at render, and the context budget is capped with ranked eviction so an over-matched termbase cannot crowd out the text being translated.

Each unit records enough to tell whether a person has signed off: its status separates machine work from a person's, and it carries a confidence score, a translation-memory match percentage, and a lock band. When a guard quarantines a suspected refusal or an off-target write, the single write path stamps which producing surface generated it onto the quality flag, so a reviewer can see which path produced the flagged output.

Predictive QE#

The market has moved past speed alone: the value is identifying which segments need human expertise before delivery, and treating random spot-checks as false security (RBB Consultancy, 2026). Our quality-threshold routing is precisely this: the gate decides, per segment, what clears automatically and what is routed to a human, so attention goes where the score says it is consequential rather than to a random sample.

Access control#

• Role-based access control with six roles (admin, manager, reviewer, linguist, translator, viewer) and per-project membership scoping; each write is gated by the matching rule, enforced on both the web UI and the API.
• Per-user API keys carry their own scopes, and the top administrative scope can only ever be minted locally, so a stolen key can never self-replicate a higher grant over the wire.
• Enterprise sign-in via SAML 2.0 and OIDC single sign-on, real LDAP or Active Directory, and SCIM 2.0 user lifecycle provisioning, layered on top of local passwords, never replacing them.
• A host-only remote-admin master switch decides whether the sharpest API admin verbs are reachable over the wire at all.

A note on compliance#

SOC 2 and ISO 27001: not yet certified. Formal gap assessments are complete against both standards, the controls are documented, and the remediation roadmap is active. Localization OS does not claim HIPAA or PCI certification and does not assert compliance with the EU AI Act or any other framework. What it provides is capability: the provenance, audit-chain, and export features here support the disclosure and audit obligations that frameworks like the EU AI Act and GDPR place on localized content. Whether a given deployment meets a given obligation is a decision for you and your compliance function; this product gives you the instruments, not the verdict.

The map: industry term to Localization OS feature#