Memory
Memory is how a project gets better at its own documents over time. When a transaction is reviewed and approved, the system can keep it as a sample: the document text paired with the field values a person confirmed. Later, when a similar document arrives, the closest samples are placed into the extraction prompt so the AI sees a real, corrected example of exactly this kind of document before it answers.
The effect is cumulative. A project with a handful of good samples for an unusual supplier layout stops making the same mistake on that layout.
Memory lives on the Memory page, under Design.
Where samples come from
There are three ways a sample enters memory:
| Source | When |
|---|---|
| Playground | Always. Anything you process and correct in the playground is captured. The playground is never capped and is not affected by the production settings below. |
| Production | Only when all the conditions in What production needs in order to learn are met. |
| Manually | A user with the "System can learn from user" permission can add a transaction to memory directly, or copy transactions into memory from another dataset. |
What production needs in order to learn
Production learning is deliberately conservative, because it retains reviewed customer documents. Four conditions must all hold. If any one fails, the transaction completes normally and nothing is captured, silently.
- Document examples are enabled for the project.
- Accumulate samples from production is on in the published configuration.
- Learning is not paused by an operator (see Pausing learning).
- The person who reviewed the transaction has the "System can learn from user" permission.
Condition 4 is the one that catches people out. The built-in Reviewer role does not include "System can learn from user". If your reviewers hold only that role, every transaction they approve is discarded and memory stays permanently empty, with no error shown anywhere.
The fix is a permissions change, not a memory setting: add the System can learn from user grant to the reviewing role in Team → Roles. Among the built-in roles, Admin, Designer, and Supervisor already have it.
Condition 2 has its own trap: project settings are saved to the draft, and production runs the published version. Turning accumulation on and not publishing changes nothing in production.
Who can do what
| Capability | Permission | Built-in roles |
|---|---|---|
| Open the Memory page, view and manage samples, change memory settings | Manage memory | Admin, Designer |
| Cause learning: transactions this person approves may be captured. Also allows adding transactions to memory by hand | System can learn from user | Admin, Designer, Supervisor |
| See whether a project is still learning, and why it is not | View memory learning status | Admin, Designer, Supervisor |
| Pause and resume learning without publishing | Pause and resume memory learning | Admin, Designer, Supervisor |
| Edit a similar transaction opened from memory | Edit similar transactions in memory | Admin, Designer, Supervisor |
Custom roles can be given any of these. Note that "View memory learning status" and "Pause and resume memory learning" are operational permissions: they let a supervisor watch and stop learning from the Monitoring page without being handed the design-time Memory page.
The Memory page
Three tabs:
- Dataset lists the transactions held in memory, with the same table controls as any other transaction list (views, filters and custom columns all apply). Open one to inspect or correct the values it teaches.
- Similarity plots the samples as a cluster map, so you can see which document types are densely covered and which are represented by a single sample.
- Settings holds the production learning controls described below.
Memory versions
Memory is versioned along with the project. The version selector next to the page title switches which set of samples you are looking at:
- Draft is your working set. Adding, editing, or deleting samples here does not affect production.
- Production is the set production is retrieving from right now.
- A release number is the frozen set that shipped with that published version.
Publishing the project publishes the memory draft along with it. Rolling back a version rolls memory back too.
The Settings tab has no version selector, because settings are not per memory version: they are ordinary project settings that are saved to the draft and take effect when you publish.
Golden samples
A sample can be marked golden. Golden samples are never evicted when a cap is reached and are never dropped automatically. Use it for the handful of examples that represent a difficult document type correctly, so routine churn cannot push them out.
Settings
On the Memory page
The Settings tab carries the three controls that matter day to day. Changes save as you make them, to the project draft.
| Setting | What it does |
|---|---|
| Accumulate samples from production | When on, completed production transactions reviewed by authorized users are captured as new samples. When off, production stops adding samples and everything already stored is kept and still used. The playground is captured either way. |
| Max samples per document class | Cap on production samples stored for each document class. |
| Max samples overall | Cap on total production samples across all document classes. |
In the Extract step
The full set of options lives in the workflow designer, in the Extract step's configure panel under Document Examples. This is where you enable the feature and tune how samples are used:
| Setting | What it does |
|---|---|
| Enable | Master switch for document examples. |
| Apply examples | Whether stored samples are injected into extraction prompts. Turning this off keeps memory intact but stops using it, which is a useful way to test whether memory is helping. |
| Auto-accumulate | The same setting as "Accumulate samples from production" on the Memory page. |
| Max examples in prompt | How many samples go into each extraction, from 1 to 3. More samples means more tokens and higher cost per document. |
| Similarity threshold | How close a stored sample must be to the incoming document before it is used. Raise it if irrelevant samples are being pulled in. |
| Dedup threshold | How similar a new document must be to an existing sample before it is treated as a duplicate and not stored. Lower it if memory is filling with near-identical documents. |
| Page selection, First pages, Last pages | Which pages of the sample document are stored and shown to the model. |
| Send example images, Max image pages | Whether page images of the sample are included alongside its text. |
| Include field groups | Whether group and repeating-group fields are part of the stored sample. |
| Training dimensions | Fields that split the caps and retrieval into separate buckets, for example one bucket per supplier. |
Settings save to the draft
All of the above are project settings. They are saved to the draft and production keeps running the published configuration until you publish a new version. If you change a cap or turn accumulation on and nothing happens in production, publishing is almost always the missing step.
Caps and what happens when memory is full
The two caps bound how large production memory can grow. They apply to production samples only; the playground is never capped.
When a cap is reached, memory does not stop working and does not stop accepting new samples. Each new sample evicts an existing one, choosing the least useful first: samples that are rarely or never retrieved go before samples that are used often, and among unused samples the oldest goes first. Golden samples are never evicted.
A project sitting at its cap looks, from the outside, exactly like a project that has stopped learning: the sample count stops rising. It is not a fault. If memory should hold more, raise the cap and publish.
Lowering a cap does not just stop growth. The next time capture runs, samples above the new limit are permanently removed. Mark anything you cannot afford to lose as golden first.
Pausing learning without publishing
Sometimes you need learning to stop now, for example when a batch of bad extractions is being approved and you do not want it taught. Publishing a project just to stop learning would also ship every other unfinished draft change.
Instead, pause it. On the Monitoring page, the Memory learning section has a Pause button for anyone with the "Pause and resume memory learning" permission. Pausing:
- takes effect immediately, with no publish;
- stops new samples being captured, and leaves everything already stored in place and still in use;
- survives a publish, so shipping a new version will not silently restart it;
- stays in effect until somebody resumes it.
While a project is paused, the Memory page's Settings tab shows a notice saying so, so the two pages cannot appear to contradict each other.
Resume returns the project to its published configuration. It does not turn learning on. If the published configuration has document examples disabled or accumulation switched off, resuming changes nothing, and the settings plus a publish are what you actually need. This is deliberate: retaining reviewed customer documents is a decision that should carry a published version, so there is no runtime switch that can start it.
Why is memory empty?
Work through these in order. The first one that is true explains everything below it.
- Is learning paused? The Monitoring page's Memory learning section shows the state, who paused it, and when.
- Is accumulation on in the published configuration? Check the Memory Settings tab, then check that the project has been published since you last changed it.
- Can your reviewers teach memory? This is the most common cause. See the warning in What production needs in order to learn.
- Is memory at its cap? Then it is working, not broken. Raise the cap or prune.
- Is anyone actually reviewing? Memory only learns from transactions a person approved. Unattended and API-submitted transactions that complete without a review step are never captured. That is expected behaviour, but it does mean memory stays empty until the workflow has a review step.
The Memory learning section on Monitoring answers 1, 3, and 5 directly: it counts, per reason, why each completed transaction of the last seven days was or was not captured. See Monitoring.
Ask the assistant
The in-app assistant can do all of this. Useful things to ask:
- "Why is memory empty for this project?" It runs the full checklist above and names the cause.
- "Is this project still learning into memory?"
- "Pause memory learning, we are getting bad approvals."
- "Raise the total sample cap to 5000."
It reads the published configuration rather than the draft, so its answer reflects what production is actually doing, and it will tell you when a change needs publishing.