The audit notice arrived on a Tuesday, and it asked a question the localization director could not answer. A regulated medical-device client, preparing for a market submission in three new European locales, wanted to know one thing about the translation memory the agency had been building for them across six years and eleven products: which segments in it had ever been checked by a qualified human, and which had not. Not "is the TM good." A specific, provable, segment-by-segment answer. The director pulled up the master memory: 1.4 million segments, accreted from forty translators, three acquired vendors, a decade of legacy alignment imports, and eighteen months of an MT-first pipeline that pre-filled and committed at a rate no one had been counting. There was no field that recorded origin. No way to tell a senior reviewer's approved segment from a junior post-editor's rushed accept of a raw machine guess. No way to separate the clean client work from a batch a departed freelancer had quietly pasted in from a public engine. The TM was not an asset that day. It was an undocumented liability with 1.4 million entries, and the client was asking the agency to vouch for every one of them. This lesson is about the program that prevents that Tuesday: translation-memory governance, the discipline of running a translation memory at organizational scale so that it stays the most valuable thing the operation owns instead of the thing that cannot survive an audit.

From Hygiene to Governance

A translation memory (TM) is a database of previously translated, approved source-target sentence pairs that the computer-assisted translation tool (CAT tool, the environment where linguists work) reuses before the machine-translation (MT) engine runs. That reuse is leverage: the same sentence is never solved twice, and a document with high repetition can be 40, 60, even 80% filled from memory at a fraction of fresh-translation cost. The previous lesson established the failure modes at the level of a single linguist working a single file: a TM gets poisoned when someone commits an unverified MT guess, imports a bad alignment, or leverages a correct translation into a wrong context. The defense there was personal discipline, hygiene, the instinct to treat the write-back into the memory as a publishing decision rather than a save.

Personal hygiene is necessary and it is not enough. It does not survive scale. One careful linguist keeps the segments they touch clean; they cannot keep clean the segments committed by the forty other people with write access, the segments imported in a midnight bulk job, the segments inherited when the agency acquired a competitor and merged two memories, or the segments an MT engine wrote back through an automated workflow that no human reviewed at all. Hygiene is a property of a person. At organizational scale, cleanliness has to become a property of a system, and the system that produces it is governance.

Governance is the set of rules, roles, and recurring controls that determine what is allowed into a shared asset, who is allowed to put it there, how it is documented, and how it is audited and corrected over time. Financial governance decides who can move money and how every movement is recorded so the books survive an audit. Data governance decides who owns a dataset, who may write to it, and how its lineage is tracked. Translation-memory governance is exactly this discipline applied to the memory: it is the difference between a TM that any of forty people can write anything into without a trace, and a TM where every segment carries its origin, every committer is accountable, every promotion to the trusted master is reviewed, and the whole asset is audited on a schedule so that the answer to "which segments can you vouch for" is a query, not a shrug.

Hygiene is what one careful linguist does to the segments they touch. Governance is what the organization does so the asset stays clean regardless of who touches it. The first does not scale; the second is the only thing that does.

Why the MT-First Era Forced the Issue

Translation-memory governance is not new as an idea, but in 2026 it stopped being optional. The reason is throughput. In a human-only past, segments entered the TM at human speed: a linguist translated, a reviewer checked, a segment was committed after two sets of eyes. The rate of entry was naturally throttled by the rate of human work, and the rate of contamination was throttled with it. The MT-first pipeline removed that throttle. When MTPE adoption rose from 26% in 2022 to roughly 46% in 2024 and a hybrid workflow lifted a linguist from about 2,000 words a day to 5,000 or more, the rate at which segments enter the memory more than doubled, and the share of those segments that originated as a machine guess went from near zero to the majority.

A memory that doubles its intake rate while shifting its intake mix toward unverified machine output is a memory whose contamination rate is rising on two axes at once. The flywheel that compounds quality when it is fed correct segments compounds mistakes at the same accelerated speed when it is fed machine guesses confirmed at speed. Personal hygiene cannot hold against an intake rate that high across that many committers. Only a governance program can, because only a program can impose controls at the points where individual vigilance fails: the moment a machine-origin segment enters, the moment an untrusted committer writes, the moment a promotion to the master memory happens, and the recurring moment of audit. The MT-first era did not create the need for TM governance. It removed the natural rate limit that had been quietly substituting for it.

Provenance: The Foundation of Every Control

Everything in TM governance rests on one foundation, and without it nothing else can be built: provenance, the recorded origin and history of every segment. Provenance is the metadata that travels with each source-target pair and answers the questions the audit asked. Where did this segment come from? Who committed it? When? In what project and domain? Has it been independently reviewed, and by whom? What was its origin type: a human translation, a post-edited machine output, a raw machine output, or a bulk alignment import?

A bare TM stores only source and target. A governed TM stores, on every segment, a provenance record. The exact fields vary by tool, but a defensible minimum set is consistent across any serious program:

• Origin type. The single most important field. Was this segment produced by a human translator from scratch (HT), by a human post-editing machine output (MTPE, and ideally light versus full), by an engine with no human review (raw MT), or by aligning a legacy document pair (alignment import)? Every downstream control keys off this one attribute.
• Committer identity. The named linguist, reviewer, or automated process that wrote the segment back. "An automated process" is a valid and important value: it is how you later find every segment a machine committed without a human in the loop.
• Review status. Draft, reviewed, or approved. A segment that one person translated is not the same trust level as a segment a second person independently checked, and the status records which it is.
• Timestamp and project. When the segment entered and which project it came from, so you can trace a contamination event back to its source batch and date.
• Client and domain. Which client this segment belongs to and what subject domain it covers, so the memory can be segmented and so a segment never silently crosses a client or domain boundary it should not cross.

The reason provenance is the foundation and not just one practice among many is that every other governance control is, underneath, a query against provenance. The MT-origin penalty is a rule that fires on the origin-type field. The promotion review selects segments by committer and status. The cleanup audit quarantines a class by origin type and date. The retirement of bad segments depends on identifying the batch they came from. None of these is possible if every segment looks identical. With provenance, the director on that Tuesday could have run one query, "show me every segment whose origin type is raw MT or whose committer is an automated process and whose review status is not approved," and produced the exact answer the auditor wanted. Without it, the 1.4 million segments are a single undifferentiated mass, and the only honest answer is "I cannot tell you."

Provenance is not paperwork. It is the only thing that makes a translation memory queryable, and a memory you cannot query is a memory you cannot govern, defend, or clean. Record where every segment came from, or accept that you will never again be able to find the bad ones.

Provenance as the Audit Trail

There is a second reason provenance matters that goes beyond cleaning. A governed TM is, by virtue of its provenance metadata, an audit trail. The revised ISO 18587 (the post-editing standard, in DIS ballot with publication targeted for late 2025 into 2026) expands its scope to cover AI and LLM "non-human translation output" and insists the post-editor hold full professional-translator competence, which means the standard increasingly cares not just that output is good but that you can demonstrate who was accountable for it. ISO 5060:2024 formalizes the error scoring that decides whether output ships. A provenance-rich TM is the artifact that lets you connect a shipped segment back to the human who owned its quality, the review it passed, and the date it was approved. When a client or a certifier asks you to prove conformance, the provenance record is the proof. A TM without provenance can produce good translations, but it can never prove they were governed, and in a regulated relationship the proof is part of the product.

Penalties, Trust Tiers, and the Master TM

Provenance is inert until something acts on it. The first control that acts on it is the penalty, a configured percentage subtracted from the displayed match score of segments that carry a given attribute. The most important is the MT-origin penalty, introduced in the previous lesson at the level of one linguist's tool settings. At organizational scale it becomes a policy, and the policy is the thing that turns provenance into behavior.

Recall the mechanism. A linguist is trained to wave through a 100% match and to open, read, and verify a fuzzy match below the auto-trust threshold. So if a segment that originated as raw machine output is allowed to surface as a 100% match, it impersonates a fully reviewed human segment and gets waved through. The penalty strips the disguise: a segment with origin type "raw MT" gets a penalty applied, so its 100% leverage displays as, say, 85%, which forces the linguist to open it. The penalty does not delete the leverage. It removes the leverage's costume and pushes a less-trustworthy segment out of the auto-trust zone and into the must-verify zone, where a human will actually look at it.

At program scale, the single penalty becomes a tiered schedule keyed to origin type, and the schedule is part of the written governance policy so that it is applied identically by every linguist on every project rather than left to each person's local tool configuration. A worked penalty schedule looks like this:

• Human-translated, independently reviewed, approved (HT). No penalty. This is the gold tier, the segments that earned full auto-trust. A 100% from here displays as 100%.
• Full post-edited machine output, reviewed (full MTPE). A small penalty, perhaps 1 to 3%. Trustworthy, but it began life as a machine guess and a reviewer adapted it, so it sits a hair below pure human work.
• Light post-edited machine output (light MTPE). A larger penalty, perhaps 5 to 10%, because light post-editing deliberately fixes only what is necessary and leaves more machine surface in place.
• Raw machine output, no human review. A heavy penalty, often 15% or more, sometimes enough that it can never display as a confident match at all. This is the tier most likely to hide a fluent mistranslation, and the penalty exists precisely to guarantee a human opens it.
• Unverified alignment import. A penalty comparable to raw MT until the batch has been audited, because an unaudited alignment can contain the wrong-content pairs the previous lesson described, where source and target read fluently but are not translations of each other.

A penalty schedule is the organization saying, in numbers the tool enforces, that not all leverage is equal. A reviewed human segment earned its 100%. A raw machine guess did not, and the penalty refuses to let it pretend otherwise, every time, on every project, for every linguist.

Why the Schedule Must Be Policy, Not Preference

The reason the penalty schedule belongs in a written, enforced policy rather than in each linguist's personal settings is consistency under scale. If one post-editor sets a 15% MT penalty and another runs no penalty because they find it slows them down, the same poisoned segment is caught on one project and waved through on the next. The contamination rate of the whole memory is then determined by its least careful contributor, not its most careful. A governance program removes that variance by making the schedule a standard applied by the workflow, ideally enforced in the translation-management system (TMS, the platform that orchestrates projects across tools and people) rather than in each desktop CAT tool, so that no individual can quietly turn it off under deadline pressure. The penalty is a control only if it cannot be locally disabled, and making it un-disableable is the governance move that personal hygiene structurally cannot make.

Commit Rights and the Master TM

The third pillar of governance is the one that hygiene never addresses at all, because hygiene assumes the person reading is the person committing: who is allowed to write to the trusted memory. In an ungoverned operation, everyone with a login can write to the same TM, which means the master memory's quality is the quality of its most careless committer multiplied by their volume. Governance breaks this by separating memories by trust level and restricting commit rights to the trusted one.

The standard architecture is a two-tier (sometimes three-tier) memory structure:

• The working TM (also called a project TM or draft TM). This is where live work accumulates. Post-editors and translators commit freely to it as they work, because the working memory is meant to capture in-progress decisions and provide leverage within and across the active project. It is fast and permissive by design. It is also explicitly untrusted: nothing in it has earned a place in the master yet.
• The master TM (also called the production or approved TM). This is the trusted, audited, client-facing memory, the asset the operation vouches for. Commit rights to the master are restricted to a small set of accountable roles: the TM manager, the lead reviewer, the terminologist. No post-editor writes directly to the master. Segments arrive in the master only by promotion, and promotion is a reviewed event.

This separation is the structural heart of governance, and it solves the exact problem on the director's Tuesday. The reason the 1.4 million segments could not be vouched for is that they had all been written directly into one undifferentiated memory by forty people with equal rights. Had there been a working/master split, the master would have contained only promoted, reviewed segments with clean provenance, and the rushed accepts and pasted-in public-engine output would have lived in working memories that were never confused with the asset the client relies on. The split is what makes "the trusted memory" a meaningful phrase. Without it, there is no trusted memory; there is only the memory, and it is exactly as trustworthy as whoever last wrote to it.

If everyone can write to the master, there is no master, only a shared memory wearing the master's name. Governance restricts commit rights to the trusted tier so that "approved" means a specific person took specific accountability, not merely that a segment got saved.

The Roles That Own the Tiers

Commit rights are meaningless without named owners. A governed operation assigns explicit responsibility for the master TM, typically to a TM manager or terminologist who owns the boundary between working and master, runs the promotion reviews, and is accountable for the master's cleanliness the way a database administrator is accountable for a production database. This is the organizational version of the boundary the previous lesson described. There, the boundary was the line each linguist crosses when they confirm a segment into their memory. Here, the most important boundary is the line between the working memory and the master, and it has a named owner who decides what crosses it. The post-editor still owns the quality of the segments they touch; the TM manager owns whether those segments are good enough to become permanent, trusted, client-facing institutional memory. Separating these two accountabilities is what lets an operation move fast in the working memory without contaminating the asset it sells.

Review Before Promotion

The bridge between the working TM and the master TM is promotion review, the gate where segments earn their way into the trusted memory. This is the single most important recurring control in the whole program, because it is the choke point through which all contamination would otherwise have to pass to reach the asset that matters. If the promotion gate holds, the master stays clean even when the working memory is full of unverified machine guesses, because the guesses never get promoted.

A defensible promotion review is not a person eyeballing a list and clicking approve. It is a structured pass that uses provenance to route effort, exactly the way a quality gate uses an error typology to route attention. The mechanics:

• Select the promotion candidates. At a defined cadence (end of project, end of sprint, monthly), gather the segments in the working TM that are candidates for the master. Provenance scopes this: you are promoting a specific project's confirmed segments, not the whole working memory.
• Triage by origin and risk. Segments that are human-translated and already independently reviewed can be promoted with a light check. Segments that originated as machine output, especially raw or light-PE, get full review against the source before promotion, because these are the segments most likely to carry a fluent mistranslation. The promotion review is where the MT-origin segments finally get the human reading the penalty was trying to force, if it had not already happened.
• Check against the termbase and the master. Each candidate is checked for terminology conformance against the current approved termbase, and for conflict against the master: does a segment with the same source already exist in the master with a different target? A conflict is a red flag that something is inconsistent and must be resolved before either version is trusted.
• Approve, fix, or reject. Each candidate is approved into the master (with its review status updated to "approved" and the reviewer recorded), sent back for correction, or rejected. Rejection is normal and healthy: not every confirmed working segment deserves to become permanent institutional memory.

The discipline that makes this work is treating promotion as the real publishing event. In the previous lesson, confirming a segment was framed as a publishing decision. At program scale, that framing relocates to the promotion gate. A post-editor confirming a segment into the working TM is closer to saving a draft; the act that publishes into the asset the whole organization reuses without re-checking is the promotion into the master. Putting a deliberate human review at that exact point is the governance equivalent of "do not auto-confirm," scaled from one linguist's keystroke to the organization's intake of permanent memory.

Promotion review is the one gate that decides whether the master TM stays an asset. Everything upstream can be messy and fast. The promotion gate is where messy-and-fast is filtered into trusted-and-permanent, and it is the control you defend first when the budget is tight.

Segmentation by Client, Domain, and Quality

A single global memory shared across every client and every domain is a contamination vector by design, no matter how careful the committing is. The reason is that a segment correct in one context is wrong in another, and a global memory erases the boundaries that keep contexts apart. Segmentation, the deliberate division of the memory into separate TMs by client, by domain, and by quality tier, is the governance control that builds those boundaries back in.

Consider the dimensions and why each one matters:

• Segmentation by client. Two clients in the same industry will have different approved terms, different brand voice, different legal constraints. Client A calls the device a "cartridge"; Client B insists on "reservoir" for the identical part. A shared memory will leverage A's term into B's project as a confident 100% match and silently violate B's approved terminology. Separating client TMs means a client only ever leverages from their own approved language. It is also a confidentiality control: a client's translated content is often confidential, and a shared memory can leak one client's strings into another client's leverage. Segmentation by client is both a quality control and a data-governance requirement.
• Segmentation by domain. Within a client, the same source string can need different translations in different domains: a marketing string, a legal clause, a UI label, a medical instruction. A memory that mixes domains will leverage the marketing register into the legal clause. Domain-segmented TMs (or domain metadata used to scope leverage) keep the register and terminology of each domain intact.
• Segmentation by quality tier. This is the dimension that ties segmentation back to provenance. Keep the gold master (reviewed human work) separate from a lower-tier memory of unverified MT or light-PE leverage. When a high-liability project needs maximum trust, it leverages only from the gold master and never from the lower tier. When a low-stakes, high-volume project can accept more machine leverage for speed, it can draw on the lower tier knowingly. Quality-tier segmentation lets the operation match leverage trust to content risk, the same risk-tiering logic the pipeline applies to post-editing effort, applied to the memory itself.

Segmentation has a cost: it reduces raw leverage, because a segment in Client A's memory cannot be reused for Client B even when it would have matched. This is the tradeoff governance accepts deliberately. Some leverage that would have been technically possible is correctly forbidden, because that leverage would have crossed a boundary it should not cross. A governed operation would rather lose a few points of leverage than silently propagate Client A's term, Client A's confidential string, or a marketing register into a context where any of them is wrong. The leverage you give up to segmentation is leverage you should not have been taking.

A single global memory maximizes leverage and minimizes safety. Segmentation trades a little leverage for the boundaries that keep one client's terms, one domain's register, and one quality tier's trust from silently bleeding into another. The leverage lost is leverage that would have been wrong.

Periodic Audit and Retirement of Bad Segments

No commit-time control is perfect, and a memory that compounds also compounds the errors that slip past the gates. So a governance program includes recurring maintenance, the only control that looks at the memory itself rather than at a live project, and the only place a long-dormant poisoned segment can be found before it surfaces in a new deliverable two years later, exactly as the réservoir error did in the previous lesson.

The periodic audit (also called a cleanup pass or TM maintenance) is a scheduled, deliberate examination of the master TM as an asset in its own right. A program runs several distinct audit passes, each closing a different gap:

• Duplicates and conflicts. Find segments with the same source but different targets. A conflict means the memory holds two contradictory answers to the same question, and a leverage match could hand a linguist either one. Each conflict is resolved to a single approved version, and the loser is retired.
• Terminology drift. Check stored targets against the current approved termbase. Terms change: a client updates an approved term, and every older segment that uses the deprecated term is now a latent terminology error waiting to leverage forward. The audit finds them and flags them for correction or retirement.
• Provenance-based quarantine. Use the origin metadata to re-review or quarantine entire suspect classes. "Quarantine every raw-MT segment committed during the three weeks the penalty was misconfigured." "Re-review everything imported in the legacy alignment batch from the acquired vendor." This is the pass the director on that Tuesday could not run, because there was no provenance to query.
• Orphan and alignment audit. Find aligned segments whose source and target lengths or structures suggest a mismatch, the wrong-content pairs that read fluently on each side but are not translations of each other.

The action the audit produces, and the one most operations neglect, is retirement: the deliberate removal or deactivation of bad segments from the trusted memory. Retirement is the counterpart to promotion. Promotion is how a segment earns its way into the master; retirement is how a segment that should never have been there, or that has gone stale, is taken out. The mechanism matters: rather than hard-deleting a segment (which destroys the record of what was there), a governed program usually deactivates or moves it to a quarantine memory, preserving the provenance trail while removing the segment from leverage. The segment can no longer poison a new project, but the audit history shows it existed, when it was retired, and why, which is itself part of the defensible record.

Promotion lets segments earn their way into the master. Retirement takes out the ones that should never have been there or that time has spoiled. A memory with promotion but no retirement only ever accumulates; it never heals. Governance requires both directions.

Why Retirement Is the Hardest Control to Fund

Retirement and the audits that drive it are the controls operations skip first, because they are pure cost with no visible same-day output. A promotion review is attached to a project that is shipping; an audit is attached to nothing but the long-term health of the asset. The temptation is always to defer it, and the réservoir error is the cost of deferring it: a single segment that survived a file-level cleanup, sat dormant in the memory for two years, and resurfaced in an unrelated project because nobody ever audited the memory itself. The audit and retirement passes are the only controls that could have found that segment. The case for funding them is exactly the case for any preventive maintenance: the cost of the scheduled audit is small and known, and the cost of the contamination it prevents is large, delayed, and capable of surfacing in front of a client or an auditor at the worst possible moment. A governance program that runs the gates but never audits the master is a program that prevents new contamination while letting old contamination compound undisturbed.

A Worked TM Governance Policy

The controls only become a program when they are written down as a policy that names the rules, the roles, and the cadence. A policy is what turns a set of good intentions into something an auditor can read, a new hire can follow, and a manager can enforce. Here is a worked TM governance policy, the kind of document that would have made the director's Tuesday a non-event. It is deliberately concrete; a real one would carry the client and tool names this one leaves generic.

1. Provenance: every segment is documented

Every segment committed to any TM in the operation must carry, at minimum: origin type (HT, full MTPE, light MTPE, raw MT, alignment import), committer identity (named person or named automated process), review status (draft, reviewed, approved), timestamp, project, client, and domain. No segment may be committed without origin type and committer. Automated write-back processes must stamp their own identity; a segment a machine committed must never be indistinguishable from one a human committed.

2. Memory tiers and commit rights

The operation maintains, per client, a working TM and a master TM. All linguists may commit to the working TM. Only the TM manager and designated lead reviewers may commit to the master TM. No post-editor or translator has direct write access to any master. The master is client-facing and is the only memory the operation represents as approved.

3. Penalty schedule

Match scores are penalized by origin type, enforced in the TMS so the schedule cannot be locally disabled: HT reviewed, 0%; full MTPE, 2%; light MTPE, 8%; raw MT, 18%; unaudited alignment import, 18%. The schedule is reviewed quarterly and adjusted with evidence, never by individual preference.

4. Promotion review

Segments move from working to master only by promotion review, run at project close and at least monthly for long-running accounts. Human-reviewed HT segments get a light promotion check; all machine-origin segments get full source review before promotion; every candidate is checked for terminology conformance and for conflict against the master. The promoting reviewer is recorded against each promoted segment, and that record is the accountability trail.

5. Segmentation

Memories are segmented by client (always, for quality and confidentiality), by domain where a client spans materially different domains, and by quality tier (a gold master of reviewed human and full-MTPE work, separated from any lower-tier MT-leverage memory). High-liability projects leverage only from the gold master. Cross-client leverage is prohibited.

6. Periodic audit and retirement

Every master TM is audited on a fixed schedule (quarterly for active accounts, before any regulated submission, and after any acquisition or bulk import). Each audit runs the duplicates-and-conflicts, terminology-drift, provenance-quarantine, and alignment passes. Bad segments are retired by deactivation or move to quarantine, never hard-deleted, so the provenance trail survives. Each audit produces a dated record of what was examined, what was retired, and why.

7. Accountability and audit-readiness

The TM manager owns the master TMs and the audit schedule. At any time, the operation must be able to answer, by query, "which segments can you vouch for, and on what evidence," for any client memory. The provenance metadata and the audit records together constitute the conformance evidence under ISO 18587 and ISO 5060, and assembling them is a standing capability, not a scramble triggered by an audit notice.

A governance policy is the asset that makes the other assets defensible. It is short, it names rules and owners and cadences, and its real test is a single question: when a client asks which segments you can vouch for, is the answer a query, or a scramble?

Reading the Policy as One System

Notice how the seven sections interlock rather than stand alone. Provenance (section 1) is the data layer every other control queries. The penalty schedule (section 3) acts on the origin field provenance records. Commit rights and tiers (section 2) create the working/master boundary that promotion review (section 4) gates, and promotion review uses provenance to triage. Segmentation (section 5) builds the client, domain, and quality boundaries that keep contexts from bleeding. The audit and retirement passes (section 6) use provenance to find and remove what slipped through. And accountability (section 7) is the claim the whole structure exists to make defensible. Pull out provenance and the entire program collapses, which is why it is the foundation. Pull out promotion review and the master fills with contamination. Pull out the audit and old contamination compounds forever. The policy is not a list of independent good ideas; it is a single system in which each control closes a gap the others leave open, and the gaps it closes are precisely the ways a memory at scale turns from an asset into the liability that arrived on a Tuesday.

Key Takeaways

• A translation memory (TM) is a database of approved source-target pairs the CAT tool reuses (leverage) before MT runs; hygiene is the discipline of one linguist keeping their own segments clean, and governance is the system of rules, roles, and recurring controls that keeps the shared asset clean regardless of who touches it. Hygiene does not scale; governance is the only thing that does, and the MT-first era (MTPE adoption rising from 26% in 2022 to ~46% in 2024, throughput from ~2,000 to 5,000+ words/day) forced the issue by removing the natural rate limit on contamination.
• Provenance, the recorded origin and history of every segment (origin type, committer identity, review status, timestamp, project, client, domain), is the foundation: every other control is underneath a query against provenance. Without it a memory is an undifferentiated mass you cannot clean, defend, or vouch for; with it, "which segments can you vouch for" is a query, not a scramble, and the metadata doubles as the ISO 18587 / 5060 conformance audit trail.
• The MT-origin penalty becomes an organizational policy: a tiered schedule keyed to origin type (0% for reviewed human work, small penalties for full and light MTPE, heavy penalties for raw MT and unaudited alignment imports) that strips the disguise off untrustworthy leverage and forces a human to look. It must be enforced in the TMS so no individual can locally disable it, because a control that can be turned off under deadline is not a control.
• Commit rights are split across memory tiers: everyone may write to the permissive working TM, but only the TM manager and lead reviewers may commit to the trusted, client-facing master TM. If everyone can write to the master, there is no master, only a shared memory wearing its name; the split is the structural heart of governance and the exact thing whose absence makes a memory unauditable.
• Promotion review is the choke point where segments earn their way from working to master: select candidates, triage by origin and risk (machine-origin segments get full source review), check terminology conformance and conflict against the master, then approve, fix, or reject, recording the reviewer. It is the program-scale version of "do not auto-confirm," relocating the real publishing decision to the boundary into the trusted asset.
• Segmentation divides the memory by client (quality plus confidentiality), by domain (register and terminology), and by quality tier (a gold master separate from lower-tier MT leverage), deliberately trading a little raw leverage for the boundaries that keep one client's terms, one domain's register, and one trust tier from silently bleeding into another. The leverage given up is leverage that would have been wrong.
• Periodic audit is the only control that examines the memory itself (duplicates and conflicts, terminology drift, provenance-based quarantine, alignment audit), and retirement is its counterpart to promotion: bad or stale segments are deactivated or quarantined rather than hard-deleted, so the provenance trail survives. Audit and retirement are pure deferred-cost controls and the first ones skipped, which is exactly how a poisoned segment survives a cleanup and resurfaces years later.
• A written TM governance policy turns the controls into a program: seven interlocking sections (provenance, tiers and commit rights, penalty schedule, promotion review, segmentation, audit and retirement, accountability) in which each control closes a gap the others leave open. Its real test is one question, "when a client asks which segments you can vouch for, is the answer a query or a scramble," and a governed operation answers with a query.