A translation memory is supposed to get better as it fills. Machine-populated memories often get worse, and they do it invisibly: one wrong entry goes in, and from then on it comes back as a confident match — sometimes as an exact match, which no reviewer thinks to question.

We changed our policy after that happened to us on a customs declaration, in a way that was both specific and instructive. This post is about the rule we ended up with — nothing enters the TM until a human has reviewed it — what it costs on day one, and why it is cheaper by month three.

What a machine-written memory does to itself

The mechanism is a feedback loop with no damping.

Machine translation produces a segment. The pipeline saves it to the TM automatically, because saving is cheap and the segment might be reused. Later, a similar segment arrives, matches the saved one at some fuzzy threshold, and the saved translation is applied — possibly silently, if the match is high enough.

Every step is reasonable. The result is that an error made once becomes an error made systematically, and the reviewer who sees a "95% match from TM" is being told, by the tool, that a human once approved this.

The failure is worse on documents than on marketing copy for one reason: documents repeat. Sixteen declarations from the same shipper share most of their boilerplate. A memory that learned one wrong phrasing will apply it to all sixteen.

The incident that bought us the rule

Ours was a Chinese customs declaration, and the segment was a goods specification — the pipe-delimited strings these forms use:

source:  0|0|家用|按摩|无品牌|无型号|无编号
matched: 0|0|家用|电热|...

A 0.83 fuzzy match against an auto-saved, unreviewed TM entry. The two strings differ in one field out of seven: 按摩 is massage, 电热 is electric heating. Everything around them — the zeros, the "household", the "no brand / no model / no article number" — is identical, which is exactly why the fuzzy score was high.

The applied translation said the goods were electrically heated. They were massage devices.

What makes this the right story to tell is that the extraction was correct. The model read the page perfectly. Nothing in the translation step misunderstood anything. The wrong words came from the memory, which had been filled by an earlier machine translation nobody checked — and the complaint that reached us was "it substitutes the wrong words", which sounds like an extraction bug and is not one.

The rule, and its three parts

1. Nothing enters the TM unless a human reviewed it. Both automatic save paths are closed. The memory is populated only from the human-review promotion path and from explicit approval of a finished document.

2. Automatic application starts at 0.95. Below that and down to 0.70, a match is applied but flagged for review rather than accepted silently. Below 0.70 it goes to fresh machine translation, because a weak match on a document segment is a liability rather than a saving.

3. Lookup filters on the reviewed flag. This is the part that is easy to forget. Closing the write path does not help if the read path still returns rows written before the policy changed — so the exact-match query requires the flag, and the historical rows were purged outright.

That purge is worth naming honestly: a one-way migration that deleted every unreviewed row. A second migration cleaned up about thirty-four more that had leaked through a save path we missed on the first pass. There is no clever version of this. If you decide the memory should contain only reviewed content, the existing unreviewed content has to go.

What it costs

The trade is real and worth stating plainly, because vendors do not:

Day one: the memory is empty. Every segment is fresh machine translation. Higher cost per document, higher latency, no leverage from repetition.

It fills slowly. Only reviewed work enters, so the memory grows at the rate humans review, not at the rate the machine translates.

Some savings never arrive. Content nobody reviews never enters the memory, however often it repeats.

Against that, one benefit: every match is one a human stood behind. A reviewer looking at a TM suggestion is looking at something a person approved, which is what the "from TM" label always implied and, in a machine-written memory, silently did not.

For documents with legal consequences we consider that trade obvious. For high-volume content where errors are cheap, it may not be.

What the numbers said afterwards

Two measurements shaped how we run it.

Reuse across companies is real: 39.8%. We had assumed a document TM would be mostly per-customer — that one shipper's declarations would only help that shipper. In fact nearly two-fifths of reuse crossed company boundaries, which settled a design question about whether to namespace memories per customer. We did not.

The reused parts are not the parts you would guess. Record-like sections — the structured, repetitive rows — get reused more than the boilerplate prose. That is the opposite of the intuition that headers and standard clauses carry the value, and it argues for keeping structured segments in the memory rather than filtering them out as noise.

Importing an existing memory

If you already have a TM — from a previous tool, or a client's TMX — the policy has an obvious tension: that memory was not reviewed by you.

Our answer is that an import lands unreviewed. The segments are stored and searchable, they do not participate in matching, and a human promotes the ones they trust through the same approval path as anything else.

That is not a compromise so much as the policy applied consistently. A TMX from an unknown source is exactly the unvetted content the rule exists to keep out of matching, and "someone else reviewed it once" is not a claim the file can substantiate. Import, review, approve — in that order.

How to migrate an existing pipeline

Four steps, in this order, because doing them out of order leaves a gap:

Close the write paths. All of them. Search for every place that saves to the TM, not just the obvious one — we found a second after the first cleanup and it had already leaked rows.
Filter the read path on the reviewed flag, so historical entries stop being applied while you decide what to do with them.
Purge or quarantine the unreviewed rows. Purging is simpler; quarantining lets you review the valuable ones later.
Raise the automatic-application threshold and add a review tier below it. This is the part that limits the damage of anything that slips through in future.

Steps 1 and 2 together are what actually stops the bleeding. Step 3 is cleanup, and step 4 is insurance.

Key Takeaways

A machine-written TM decays, and it does so invisibly: one wrong entry returns forever as a confident match, labelled in a way that implies human approval.
Documents make it worse because they repeat. One bad phrasing propagates across every similar form from the same source.
Our incident was a 0.83 match differing in one field of seven — "massage" became "electric heating" on a customs declaration, from a memory nobody had checked, while the extraction was perfectly correct.
Closing the write path is not enough; the lookup has to filter on the reviewed flag too, and historical unreviewed rows have to be purged.
The cost is real and front-loaded: an empty memory, more fresh MT, slower growth. The benefit is that every match is one a human stood behind.

FAQ

Why not let the machine populate translation memory?

Because an error saved once is applied systematically afterwards, and the TM label implies a human approved it. On documents the effect compounds, since similar forms repeat: one wrong phrasing propagates to every document that fuzzy-matches it.

What fuzzy threshold should apply a match automatically?

We use 0.95 for silent application, 0.70–0.95 for apply-but-flag, and fresh machine translation below that. Our incident was a 0.83 match, which under the old 0.85 threshold was applied without review and under the current policy would be flagged.

Doesn't a reviewed-only TM start out useless?

Yes, and that is the cost. The memory begins empty, most segments get fresh machine translation, and it fills only as fast as humans review. We accept that on documents where an error is expensive; on high-volume content with cheap errors the trade may go the other way.

What do you do with an imported TMX?

Store it unreviewed. The segments are searchable and do not participate in matching until a human approves them through the normal path. A file from an unknown source is exactly the unvetted content the policy exists to keep out.

Is translation memory worth namespacing per customer?

We measured 39.8% of reuse crossing company boundaries, which argued against it. Also worth knowing: the structured, record-like sections get reused more than the boilerplate prose, so do not filter those out as noise.

Conclusion

The argument for a reviewed-only memory is not that machine translation is bad. It is that a translation memory is a claim — every match tells a reviewer that this wording has been used and accepted before. A memory the machine writes to makes that claim without anyone having checked it.

The cost is paid on day one and the benefit accrues quietly, which is a difficult shape to sell internally. What made it easy for us was the specific incident: a declaration that said "electric heating" where the document said "massage", produced by a pipeline in which every single component was working correctly.

If you want document translation where the memory contains only what a person approved, try KTTC.