How to make AI memory corrections and forgetting last

Introduction

A user who corrects an assistant is asking for the next relevant answer to use the correction. A user who deletes a memory is withdrawing something from the assistant’s continuing use or retention. Neither request is fulfilled by a reassuring reply alone. The system must identify what the user meant, change the places where the information still matters, and report only the completion it can substantiate.

Here, memory means retained application information and the state built from it: not only a saved fact, but potentially a summary, retrieved context, or pending plan. This definition matters because changing the original entry need not change a decision already prepared from it. The governing requirement is continuity of user control. The machinery should follow the actual information paths; an assistant with one effective source need not inherit the architecture of a system with many derived copies. The sections below ask what the user intends to change, how far it must reach, when it takes effect, how it survives later ingestion, and how to check the result.

What exactly is the user changing?

Start with meaning, not a delete button. “That address was wrong” challenges the earlier assertion. “I moved yesterday” changes which address applies now without necessarily making the earlier one historically false. “Delete my old address” adds a retention request that historical usefulness does not override. These are different instructions, even when they concern the same field.

LongMemEval distinguishes knowledge updates about changing life states from temporal reasoning about when information applies.[1] That distinction helps define two tests—current truth and historical truth—but does not decide the policy for repudiated errors or combined correction and erasure. An implementation can retain validity periods when history is wanted; it should not disguise retained history as deleted data.

Resolve the person, attribute, situation, and requested operation before changing state. An illustrative request such as “Use the new address for my deliveries” should not rewrite a colleague’s address or a past invoice. Check whether the speaker has authority over that target and whether the statement is confirmed, quoted, hypothetical, or tentative. MemOps explicitly probes wrong-target binding and distractors including stale values, neighboring targets, assistant echoes, third-party information, and tentative values.[2] These are useful acceptance cases, not an authorization system. When identity or permission does not settle the intended change, ask a short clarification instead of letting recency decide.

For forgetting, establish which promise is being made:

The distinction is concrete in ChatGPT’s documented controls: full removal calls for deleting relevant sources, while deleting displayed memories and turning memory off leaves chats that may create memories again when memory is re-enabled.[3] That is this product’s stated boundary, not a universal definition of forgetting.

Application-memory removal does not establish parameter unlearning or deletion by an external service. Those involve different controlled objects and need their own evidence; an application’s successful operation cannot substantiate them by implication.

Make the request’s scope explicit enough to test, but avoid creating an unnecessary new copy of the sensitive payload. Record the selected object or request identifier, intended operation, authority decision, affected uses, and unresolved surfaces only to the extent needed. This is a proposed implementation discipline, not a demonstrated privacy-minimized record format.

How far must the change reach?

Follow influence, not matching words. A summary may paraphrase the removed fact, while a plan may preserve its consequence without mentioning it. In the v2 Deployment-Time Memorization study, deleting raw records while retaining derived summaries leaves canary residue—planted test information still recoverable from those summaries; resummarization or other tested cleanup of the derived tier removes that measured residue.[4] A separate execution-state unlearning preprint finds that source redaction can leave a revoked preference shaping choices without the answer repeating the preference’s reason.[5]

These findings suggest a practical inspection sequence. First locate the authoritative input. Then trace the enabled consumers: extracted memories, summaries, retrieval indexes or cached context, and active or queued tasks. Include a surface because the system actually sends information there, not because every assistant is assumed to have it. For each affected object, choose among removal, revision, and reconstruction from permitted inputs.

Consider an illustrative travel assistant whose summary combines a withdrawn airline exclusion with a still-valid preference for morning departures. Deleting the summary may remove both. Editing only the original exclusion may leave the summary steering bookings. Rebuilding that summary from the remaining permitted inputs is a candidate repair; the acceptance test is that the exclusion no longer determines the choice while the morning preference remains usable. This example describes a design test, not a measured deployment result.

The execution-state study establishes a tradeoff under specified conditions, not a repair strategy for every deployment. Deleting the target’s descendants removes its text but also loses permitted state present in the study’s clean comparison run.[5] Replay instead recomputes affected steps and reconstructs the state of that comparison run under the study’s assumptions.[5] In a summary pipeline, regeneration from cleaned input may suffice; in a runtime whose subsequent computations consumed the fact, the relevant object may be the running state itself.

Independent support needs separate judgment. Withdrawing one source does not necessarily invalidate a conclusion also supported by permitted information. But an assistant saying “I have another reason” is not proof that the reason is independent: it could be another descendant of the same source. Where support cannot be established, quarantine the affected conclusion or seek fresh permitted support instead of asserting that semantic repair is complete. A broader request not to use the proposition at all requires a different policy from withdrawing one source’s contribution.

Do not add replay machinery without evidence of descendants. Both studies include bounded simple controls: raw-only cleanup succeeds in the raw-memory configuration, and source redaction is clean at derivation depth zero in the runtime experiment.[4, 5] A deployment should earn the same simplification by checking its actual paths and later behavior. If one authoritative record is the only surviving influence, change it and verify the next read and use. If active context or a background summary survives, that premise no longer holds.

When can the system say the change has taken effect?

Separate three milestones: the request was accepted; the specified active uses have stopped or switched to the corrected state; removal has completed on the stated retention surfaces. A request ID proves the first, not the other two. For example, OpenAI’s retention policy distinguishes immediate removal of a deleted chat from the account from scheduled system deletion within 30 days, with de-identification/disassociation and security or legal exceptions.[6] That window belongs to the documented service, not to assistants generally.

The hard boundary is work already in progress. Before declaring active-use completion, identify answers, tool plans, and producers that consumed the old state. The following are conditional mechanisms, not interchangeable guarantees:

• Replace a controlled run. In LangGraph’s documented same-thread rollback flow, the earlier run is interrupted and deleted so it cannot restart; the example awaits the replacement, inspects thread state, and checks retrieval of the obsolete run.[7] Where this is your execution regime, use those separate outcome checks rather than treating creation of the replacement as success. They do not inspect every cross-thread store or retract output already delivered.
• Reconstruct affected runtime state. The execution-state preprint locates the target’s entry, invalidates dependents, restores an earlier clean boundary, and recomputes the affected steps using sanitized observations.[5] Exact reconstruction requires deterministic decoding or fixed randomness, observations matching those the system would have received without the target, and no committed post-target external side effects.[5] If those conditions cannot be established, do not promise exact reconstruction. A clean restart with explicitly permitted inputs may be the conservative operational choice, but still needs behavior and side-effect checks.
• Repair a governed dependency store. MemTX requires still-active records derived from the withdrawn record, directly or through other records, to become inactive when those dependencies are recorded.[8] Derived views, such as summaries and index entries, are set aside as invalid until rebuilt; derived tool actions receive audit entries recording compensation obligations or leaked effects, not proof that external compensation occurred.[8] This certifies repair bookkeeping, not completed rebuilding or executed external compensation.[8] Track those unfinished outcomes separately before promoting the request to a stronger completion state.

Delayed writes require their own test: a producer may read old state, then try to save information derived from it after withdrawal; a fresh retry can cross the first write’s protection boundary. MemTX rejects a proposed write to the same memory slot—the same entity and attribute—when a rival value was saved after the transaction took its earlier view of the records.[8] It also rejects derived records whose recorded chain of parents includes a revoked record or one awaiting revocation.[8] Yet its hardened tests expose retries in fresh transactions that escape the stale-write condition, and copied content that bypasses dependency checks because its source—the parent record—was not declared.[8] A successful rejection of the first write is therefore an insufficient stopping rule.

For your implementation, exercise the old producer, its retry in a fresh transaction, and a rewritten descendant with missing provenance. Also test cancellation followed by worker failure and recovery. These are proposed failure-seeking checks; the available mechanisms do not establish a universal cutover for arbitrary workers and simultaneous output streams. Until all in-scope producers are accounted for, keep the request pending or narrow the declared active-use boundary; report unfinished rebuilding and external compensation separately. Do not silently release the affected action because cleanup is difficult.

Already-executed actions require a separate response. A sent message, completed purchase, or external update cannot be undone merely by revising memory. Identify whether cancellation or compensation is available and authorized; report irreversible consequences rather than folding them into “forgotten.”

How does a withdrawal survive the next ingestion cycle?

An obsolete write and a new extraction are different ways for information to return. Deleting an object does not necessarily prohibit creating a new object from a surviving chat. Decide whether the request is source removal, suspended memory use, or a standing restriction on future collection and use; then apply the controls corresponding to that choice.

For the ChatGPT source-removal contract, the documented surfaces include chats, archived chats, files, the memory summary, and relevant connected apps; Temporary Chats instead promise not to use existing memories or create new ones.[3] Disconnecting a source is not a claim that the external service erased its own records. Nor should a source-removal operation quietly become a promise to recognize every future paraphrase of the same personal fact.

Control metadata can help preserve a narrow withdrawal without retaining the original body. Elasticsearch’s versioning explanation illustrates why retaining a deleted document’s identity and version can reject an older out-of-order write, and why discarding that deletion record can allow recreation.[9] This is an adjacent storage mechanism, not an assistant-wide semantic restriction: a newly named summary or a fresh ingestion path needs its own enforcement.

An ongoing visibility policy is another distinct object. MemKraft’s README declares that reads check policies and tombstones—deletion markers—even after derived indexes are rebuilt.[10] Forgetting defaults to a dry run, or preview, rather than an applied change; corrupt policy or canonical state causes access to be denied rather than allowed.[10] These declared controls govern visibility, not physical erasure from external copies.[10] A team adopting that interface should distinguish preview from applied policy, test reads after rebuild, and test failure handling. The declaration alone is not evidence that those tests have passed.

For either design, test the next consolidation cycle, re-enable any permitted memory creation, and retry ingestion from surviving sources. Check both the original identity and a newly created derivative. If the promise is a standing restriction, these are acceptance cases—not proof that every semantic equivalent will be caught. Keep lifecycle status separate from deleted content, restrict access to any retained identifiers, and assess their own retention needs. Identifiers and hashes are not automatically anonymous.

A validated, privacy-minimized rule that recognizes the same withdrawn information under arbitrary new identities remains unestablished by this evidence. If the system can enforce only source-specific deletion or suspended use, state that boundary instead of claiming permanent per-fact forgetting.

How can engineers and users tell whether it worked?

Test for failures the confirmation message could conceal. MemOps separates target binding, state transition, downstream application, and retained-control checks, while Memora scores valid-memory presence separately from invalid-memory absence.[2, 11] These suggest a test suite, not a deletion certificate.

Use synthetic or otherwise authorized test information and define expected results before applying the change:

1. Correction: ask for the current value and use it in a task; separately ask a historical question when history is authorized. Include a nearby person or attribute that must remain unchanged.
2. Withdrawal: try direct recall, paraphrased questions, and tasks whose choices could reveal the withdrawn influence without restating the fact. Do not count a polite refusal as state removal.
3. Preservation: verify unrelated memories and independently supported work. Excessive forgetting is a failure, not extra credit.
4. Persistence: run repeated corrections and deletions, delayed writes, fresh retries, and later consolidation. A test confined to the next foreground answer misses these boundaries.
5. Retained state: inspect the accessible source objects, affected derivatives, actual retrieval results, task state, and removal-job outcomes. Mark inaccessible retention surfaces as unverified rather than inferring their contents from an answer.

The distinction between behavioral diagnosis and inspection is essential. MemOps evaluates generated responses against gold answers and provenance, including its state-oriented probes; those probes are not direct inspection of a deployed assistant’s hidden store.[2] Treat the checklist’s retained-state and concurrency checks as deployment-specific work, not capabilities inherited from a benchmark.

Promote completion only for the scope whose checks and required operations have finished. A stale use, wrong-target edit, missed derivative, or unexplained preservation loss should block that promotion and trigger repair followed by the same checks. There is no evidence-supported universal score threshold here. A bounded clean reference—such as the same permitted inputs without the withdrawn source—can expose lost valid behavior, but constructing that reference is itself conditional on what the system can reproduce.

Give the user a confirmation that names the selected request, covered uses and surfaces, present status, outstanding work, and exceptions without echoing the sensitive value. For example, a status view could name the covered storage locations without displaying their sensitive contents, then say: “The selected memory is unavailable to new personalized replies. Cleanup in the storage locations shown here is still pending. An earlier external action was not reversed.” This example has not been tested for accidental disclosure, and the system must check each claimed state before issuing it.

An inspectable memory view helps, but it is not necessarily exhaustive: ChatGPT’s FAQ says both its memory summary and source display may omit information involved in memory or a response.[3] A useful confirmation explains what was checked rather than turning visible absence into universal absence.

Conclusion

Effective correction and forgetting are continuing changes to what an assistant retains and does. Resolve the intended change, follow its actual dependencies, handle work already underway, and test whether later ingestion reverses it. Preserve unrelated information and distinguish accepted requests, stopped use, and completed removal. The right implementation can be small; the promise must never be larger than its reach and evidence.

Limitations

This answer uses source material available through September 11, 2026, including recent preprints, controlled experiments, and first-party product or interface descriptions. Their findings are not independent audits of arbitrary deployed assistants. Canary recovery, scripted action tests, and response-based diagnostics observe different properties; none alone proves all retained copies have disappeared.

Application-memory repair is also different from parameter unlearning. MUSE evaluates trained-model unlearning across memorization, privacy leakage, retained utility, scale, and successive requests, rather than auditing an assistant’s external memory store.[12] Deleting application records therefore supplies no evidence that model parameters or another service’s records were erased.

The remaining hard limits are complete semantic provenance, repair of mixed independent support, concurrent cutover across uncontrolled producers, and a privacy-minimized standing restriction on future equivalent information. Removing a source’s influence is not the same promise as preventing every independently supported inference. Neither refusal nor non-retrieval closes those gaps; assurance should remain attached to the objects, paths, and tests actually covered.