Memory Write Policies, Retrieval, and Forgetting

A memory system needs a write policy because not every observation should persist. It needs retrieval and forgetting policies too. Stored information can be irrelevant, stale, sensitive, or harmful in a new context.

Persistence should be justified by future utility and user expectations, not by technical ease. High-sensitivity or low-confidence items require stricter admission and shorter retention.

The rest of this lesson replaces the assertion with the record. An attack that persisted itself into an assistant's memory. A benchmark that puts a number on how badly remembered facts are recalled. A measurement of what deletion costs once a model has absorbed something. And the two legal instruments that set the floor and the ceiling on how long anything may be kept.

An instruction the user never typed was written into ChatGPT's own Memories, and it came back in every conversation afterwards. The route in was indirect prompt injection: text reaching the assistant through content it had merely been asked to look at. The security researcher Johann Rehberger disclosed the attack chain in September 2024 and called it SpAIware. At the moment of the write nothing looked like an attack. It looked like a durable user fact, which is exactly what an unreviewed admission policy is built to store.

What that one write bought the attacker, in Rehberger's own description: “Since the malicious instructions are stored in ChatGPT's memory, all new conversation going forward will contain the attackers instructions and continuously send all chat conversation messages, and replies, to the attacker.” OpenAI fixed it in ChatGPT version 1.2024.247. Herrador and Rehberger later published the technique as a journal paper.

The failure was not that the model was fooled once. Models are fooled all the time and the conversation ends. The failure was that the fooling was persisted. Every stage downstream of admission then did its job correctly: it was represented, it was retrieved as relevant, and it ran again.

Admission, Representation, Retrieval and Consolidation all happen before anyone asks whether an item should still exist. Admission decides what gets in. Consolidation and Forgetting should have an owner each and a test each. Forgetting is the only one of the five that anybody ever switches off.

The reason is cost, and the cost has been measured. Bourtoule and seven colleagues priced it in 2021, in the paper that named machine unlearning. Their SISA training framework exists precisely to make removing one data point cheaper than retraining the model without it. Here is what it buys, in their own abstract: “Under no distributional assumptions, for simple learning tasks, we observe that SISA training improves time to unlearn points from the Purchase dataset by 4.63x, and 2.45x for the SVHN dataset, over retraining from scratch.” On ImageNet classification the figure falls to 1.36x.

Read those three numbers as a design constraint, not a benchmark result. 4.63x, 2.45x, 1.36x. That is what a purpose-built unlearning framework buys against simply doing the entire job again. Deletion at that price is not a feature you add after launch, when the first request arrives. It is a property you either designed into the write path or did not.

Nothing should enter durable memory without a review that can say no. Build that review for one real workflow, and borrow its tests from instruments that already exist rather than inventing house preferences.

The expiry step has a legal formulation. Personal data may stay identifiable only as long as the purpose it was collected for requires. That is GDPR Article 5(1)(e), which requires personal data to be “kept in a form which permits identification of data subjects for no longer than is necessary for the purposes for which the personal data are processed”. Read it as an admission test. For which purpose is this item necessary, and what happens to it when that purpose ends? Article 17 supplies the matching obligation on the other side, the right to erasure. Article 17(1)(a) triggers it on nothing more than the data no longer being necessary for the purpose it was collected for. If your write policy cannot name the purpose, your deletion policy has no condition to fire on.

The controls step has a price. The FTC and DOJ charged Amazon with keeping children's Alexa voice recordings indefinitely by default and failing to honour parental deletion requests. The proposed order of 31 May 2023 imposed a $25 million civil penalty. It required deletion of inactive child accounts and of voice and geolocation data subject to deletion requests, and it barred Amazon from using that data to train its algorithms. Samuel Levine, Director of the FTC's Bureau of Consumer Protection, put the principle in one sentence: “COPPA does not allow companies to keep children's data forever for any reason, and certainly not to train their algorithms.”

Two things in that order are worth transplanting into the review. Deletion had to reach inactive accounts nobody was asking about. It also had to reach the training pipeline, not only the user-facing store. A delete button that empties the display and leaves the derived copies is the gap a regulator priced at $25 million.

Memory should be opt-in by purpose, not an automatic by-product of every conversation and tool call. Forgetting is usually configured rather than decided, and there are at least three parties configuring it before you arrive.

The platform is the first. AWS Step Functions deletes execution history 90 days after an execution is closed, and this is the one execution quota that is not fixed: “To meet compliance, organizational, or regulatory requirements, you can reduce the execution history retention period to 30 days by sending a quota request.” Azure Durable Functions makes a different default visible. “At each checkpoint, the framework saves the state into a durable storage backend. This state is the orchestration history”, and “By default, Durable Functions uses Azure Storage as its runtime state store, but other storage providers are also supported”. Neither the ninety days nor the storage backend was chosen for your task.

The regulator is the second, and it pushes the other way. The EU Artificial Intelligence Act sets a floor rather than a ceiling. Article 19(1) binds providers of high-risk AI systems: “Without prejudice to applicable Union or national law, the logs shall be kept for a period appropriate to the intended purpose of the high-risk AI system, of at least six months, unless provided otherwise in the applicable Union or national law, in particular in Union law on the protection of personal data.” Article 26(6) places the same duty on deployers. Set against the GDPR storage-limitation test in the previous section, the retention window is squeezed from both sides: at least six months of logs, and not one day longer than the purpose requires.

The court is the third, and it can suspend the policy entirely. On 13 May 2025, in the OpenAI copyright litigation, Magistrate Judge Ona T. Wang ordered: “Accordingly, OpenAI is NOW DIRECTED to preserve and segregate all output log data that would otherwise be deleted on a going forward basis until further order of the Court (in essence, the output log data that OpenAI has been destroying), whether such data might be deleted at a user's request or because of "numerous privacy laws and regulations" that might require OpenAI to do so.” The order names both of the mechanisms a product team would point to, the user's own deletion request and the privacy law behind it, and overrides them. OpenAI's motion for reconsideration was denied three days later, on 16 May 2025.

So write the retention rule down beside the write policy. Write down with it who is allowed to override it, on what notice, and what the users of the system will be told when someone does.