A lawyer changes an extracted date from 14 March to 4 March. The next answer should not recreate the original error. That sounds obvious. Many AI workflows have no clear place for the correction to live. The change may affect one response, one conversation or one user's preferences without changing the matter itself. The lawyer then repeats the work. The correction is made once, another task begins and the same mistake returns.

Four things that are often called memory

Legal AI products increasingly describe themselves as having memory or persistent context. The word can refer to several different things. The product should distinguish:

Conversation context: the material available inside one chat or run, which may disappear when the conversation ends or the context window changes.
User preference: how a person likes work presented, such as drafting style, formatting or level of detail.
Matter context: the documents, parties, tasks, permissions and history associated with a project or matter.
Reviewed factual state: the legal team's current treatment of a factual proposition, including its source, correction, status and approval history.

Those categories can overlap, but they should not be treated as interchangeable. A preference that a user likes short answers should follow the user. A correction to the date of a disputed meeting belongs to the matter. A confidential correction should not automatically appear in another matter because the same lawyer made it.

A correction starts as a proposal

The system first needs to know what changed. A lawyer may alter a date, merge two names, split one entity into two, change the status of an allegation, reject an inference or add a missing source. Each correction has a different object and may affect several later facts. The correction should initially be stored as a proposed change with:

the original value;
the proposed value;
the user who made it;
the source or reason for the change;
the date and time;
the part of the record it may affect.

That gives another authorised reviewer something concrete to assess. It also avoids silently replacing prior work before the consequence is understood.

Approval changes the matter state

Once approved, the correction should become part of the reviewed factual state. Approval does not mean the underlying evidence has become objectively true. It means the firm has adopted a particular representation for its current work. For example, the team may approve:

"4 March" as the date stated by the contemporaneous email;
"14 March" as the date alleged in the later witness statement;
a conflict flag showing that both accounts remain relevant.

A useful record can preserve all three decisions. Simply overwriting 14 March with 4 March would remove the disagreement that may matter in cross-examination. The approval should identify its scope. Some corrections apply to the whole matter. Others belong to one issue, one workstream or one user's private analysis.

Later work should use the approved version

Correction persistence is tested in the next task. If a lawyer approves the entity name "ABC Holdings Pty Ltd", a later chronology, witness brief and bank analysis should use that entity unless the user deliberately chooses an earlier or alternative view. The system should not require the lawyer to include the correction in every prompt. It should also avoid feeding every historical correction into every generation. The current approved state and the relevant source are usually what the next task needs.

Where a change is still pending, the system should make that visible. A draft based on a disputed fact should not present the matter as settled merely because the model selected one version.

The history still matters

A current value without its history can hide why the team changed position. The audit record should answer:

what the system originally proposed;
which source supported that proposal;
what the lawyer changed;
who approved the change;
which later outputs used it;
whether it was subsequently reversed.

That history supports supervision and handover. It also lets the team revisit an earlier decision when new evidence arrives. NIST's AI Risk Management Framework treats documentation, accountability and ongoing monitoring as parts of managing AI across its lifecycle. A correction log is a practical application of the same idea at matter level.

Corrections across several tools

The problem becomes harder when the matter moves between systems. A lawyer may correct a fact in a factual-analysis product, draft in another AI application and save the output in the DMS. If the drafting tool independently rereads the raw documents, it may recreate the rejected interpretation. There are several possible designs:

the drafting tool reads the approved factual record;
the correction is exposed through an API or MCP resource;
the generated work is checked against the approved record before it is returned;
the user receives a warning where the draft conflicts with reviewed matter state.

The MCP article explains how systems can exchange data and tools. The protocol can carry the correction. It does not decide whether the correction was authorised or how broadly it should apply.

Conflicting corrections need governance

Two lawyers may disagree. An associate may correct a transaction date based on one document. A partner may later decide that the pleaded date should remain in a particular draft because it reflects the client's case. An expert may use a third date for a calculation. The system should not reduce that disagreement to whichever user edited last.

It needs a governance model that can preserve competing views, distinguish evidence from litigation position and show which version applies to which work product. This is where role and permission design becomes concrete. A user may be allowed to propose a change without being authorised to alter the reviewed record for the whole team. The agent-permissions model applies the same distinction to AI actions.

Questions to ask a vendor

A product demonstration should show the correction lifecycle rather than simply claim that the system learns. Ask:

What exactly is being changed?
Does the change affect this answer, this user or the matter?
Who can approve it?
Can another user see the pending change?
Does the approved correction affect later outputs?
Can the team inspect and reverse it?
What happens when two corrections conflict?
Can the approved state move into another authorised tool?

The answer should be visible in the product, not left to inference from the word "memory". Mary's view is that reviewed facts, provenance and corrections should persist as part of the matter. A lawyer should be able to see both the current record and the history that produced it.

Verification in Legal AI Is a Design Problem

When a Lawyer Corrects the AI, Where Does the Correction Go?

A practical model for storing lawyer corrections as governed matter state rather than letting them disappear inside one AI conversation.