Docs · Features

Memory

Memory is the notebook Localization OS keeps about one customer: terminology decisions and style rules it applies to every future run, some written by you directly, some learned from the corrections people make in the editor.

What it does#

Every memory entry belongs to exactly one customer: there is no shared, cross-customer memory. The most useful entry is a term decision, "when the source says X, the translation uses Y," which also doubles as the way to say a name should never be translated: make X and Y the same word. Beyond terms, you can write down a tone rule or style constraint in free text, such as addressing a reader formally, or a project-scoped note giving context for one project only.

Not every entry starts as something you typed. A correction pattern is a recurring, non-term edit that reviewers keep making, distilled from evidence rather than authored by hand. A manual note you write is trusted and active immediately. A learned entry starts as a candidate and needs enough consistent evidence before it is trusted, and every learned entry cites the before/after evidence it was drawn from, so you can see exactly why it exists. Entries move through a lifecycle: candidate, active, conflicted (when two entries disagree and a person must decide), invalidated (revoked but kept for the record), or purged (content erased, with a tombstone left so the audit trail has no hole).

Turning corrections into memories is a deterministic pass with no model call involved: it only admits new entries, supersedes old ones, and flags conflicts. It never summarizes or rewrites anything, and it is safe to re-run.

Getting started#

Most of what memory does for you takes one note.

  1. Go to Memories and pick the customer.
  2. Add a note. A term decision names the source term and the target term; a tone or style rule is free text, optionally scoped to one project.
  3. The next run for that customer picks it up automatically. There is nothing else to wire up.

From the command line, the same two shapes look like this:

memory add-note --customer ID --kind term_decision --source-term X --target-term Y
memory add-note --customer ID --kind tone_rule --body "Formal register: address the reader as usted."

If you would rather describe what you want in plain words than fill in a form, the "Describe what you want" box on the Memories page drafts one or more pre-filled notes for you to review. Nothing is saved until you confirm.

Note

To confirm memory is actually reaching a run, open the LLM Ledger after the run finishes. A record carrying a memory marker shows exactly which memories were injected into which segment's prompt.

Works with#

  • Workflows: active memories for a run's customer are injected into Translate steps' prompts automatically, at most two term decisions and one style note per segment.
  • Glossary: the glossary is the terminology authority; memory is a softer notebook underneath it. If a term matters contractually, put it in an approved glossary, not in memory.
  • Documents: correcting a translation in the editor and saving it is what produces the evidence memory later learns from.
  • Engines: memory injection happens inside the prompt an engine receives, which is why the LLM Ledger is the place to verify it.

Current limits#

Current limits

A term decision only applies where the term actually appears in the source segment: matching is lexical, not semantic, so a rule for a word that never appears in the run simply does nothing.

Conflicting entries are not resolved automatically. They stay in a conflicted state until a person invalidates one side.

Recall into a prompt is deliberately small, at most two term decisions and one style note per segment. Memory is not a place to store a full style manual.

Purging an entry is irreversible. Invalidating one is the reversible option: the content stays readable, it just stops being used.

Capture and recall are independent switches. With recall off, memory can keep accumulating from new corrections while none of it reaches a prompt.