You tell an AI assistant that you prefer train travel to flying. Months later, it uses that preference while planning a journey that cannot reasonably be made by rail. The remembered fact is correct. The recommendation is still wrong.
Persistent memory is often presented as the cure for repetitive conversation: an assistant that knows our preferences, projects and constraints can begin closer to the useful part. But continuity creates a second problem. A remembered detail can outlive its purpose, lose its source or acquire more authority than it deserves. The better design goal is therefore not maximum memory. It is governable memory: selective, attributable, correctable and able to expire.
Memory is not one container
The word memory suggests a single notebook inside the machine. In practice, several layers may influence a reply. A system can use explicit preferences, a summary of earlier conversations, project files, custom instructions or information retrieved from a connected service. The model may receive only a selection of that material for a particular answer.
This separation matters because a source and a remembered claim are not necessarily the same object. OpenAI’s current Memory documentation, for example, distinguishes saved memories from chat history and explains that deleting a chat does not necessarily delete a separately saved memory. Conversely, deleting a saved memory does not remove its appearances from old chats. Features vary by product, plan, region and workspace, but the architectural lesson travels: to govern context, users need to know both what claim is being retained and where it came from.
When that provenance is invisible, correction becomes guesswork. A preference may have been stated directly, inferred from several exchanges or copied from a file that is now outdated. The assistant can act confidently on all three. The user sees only the result.
The useful life of a fact
Not all personal context ages at the same speed. A preferred language may remain useful for years. The objective of a six-week project should be reviewed when the project ends. A travel location or temporary injury can become misleading within days. A medical, financial or employment detail may be both long-lived and inappropriate for most tasks.
This is why expiry is more than a privacy feature. It is a quality mechanism. Retrieval systems optimise for relevance to the present prompt, but relevance is not the same as current validity or legitimate use. An old constraint can be semantically relevant and operationally false. An inferred personality trait can be repeatedly retrieved until a tentative pattern hardens into a profile.
Data-protection principles offer a useful discipline even outside formal legal analysis. The European Data Protection Board lists purpose limitation, data minimisation, accuracy and storage limitation among the basic GDPR principles. The European Commission’s explanation adds that organisations should keep only what is necessary for the purpose and for the shortest possible time under data protection by default. Those duties apply to controllers, not as a personal productivity recipe, but they expose the missing questions in many memory interfaces: necessary for which purpose, accurate as of when, and retained until what event?
What more memory genuinely enables
The strongest argument for broad memory is not convenience alone. Continuity can make an assistant substantially more capable. A person with a complex project does not have to rebuild the same context every morning. Accessibility preferences can be applied without repeated disclosure. A long-running inquiry can preserve decisions, rejected alternatives and unresolved questions. The cost of forgetting can be real: duplicated effort, inconsistent advice and lost learning.
Manual curation also shifts work back to the user. Few people will maintain expiry dates for dozens of small facts. Overly cautious systems may repeatedly ask for information that was deliberately supplied, making personalisation feel like an unreliable form that never saves.
That objection rules out a simplistic answer in which every memory needs constant approval. It does not justify indefinite, opaque retention. A workable system can distinguish classes of context. Stable preferences may persist with occasional review. Project state can carry a review date. Temporary conditions can expire automatically. Sensitive or consequential claims can require explicit choice and clearer provenance. The aim is not to make the user a database administrator. It is to make different kinds of memory behave differently.
A memory needs a boundary, not just a switch
A global memory switch is useful but coarse. It answers whether persistence is allowed, not whether a particular claim belongs in a particular decision. Better control begins with a boundary card: the recurring task memory should improve; the specific item proposed for retention; its source; its useful life; its sensitivity; and the event that should trigger review.
Consider “use three bullets”. As a durable identity-level preference, it may degrade research, correspondence and explanation. As project state—“use three bullets in the workshop brief until 30 September”—it becomes precise and disposable. The wording changes the assistant’s behaviour, but the important improvement is governance: the purpose and end condition travel with the instruction.
The NIST Privacy Framework treats privacy as an organisational risk-management problem rather than a single setting. Personal AI memory deserves the same systems view. The user-facing control, the stored source, the extracted claim, the retrieval process and the resulting answer form a chain. A correction is dependable only when the relevant link can be found and changed.
Test influence, not the promise of forgetting
No ordinary user experiment can prove that information has vanished from backups, safety logs or every provider system. Product documentation, organisational policy and applicable law remain necessary. But users can test the narrower question that affects daily agency: does a stale item still influence new work?
Choose one low-risk preference whose effect is visible. Run a repeatable prompt in a fresh conversation. Record the unwanted influence. Correct or remove the item using the provider’s documented control, and remove its originating source separately if that is appropriate and required. Then repeat the prompt in another fresh conversation. The result will not certify deletion. It can reveal whether the control changed observable behaviour, whether another source is reintroducing the claim, and whether useful continuity was lost.
The human responsibility is not to memorise every retention rule. It is to decide which context deserves continuing authority. Providers must make sources, correction and expiry legible; organisations must set proportionate policies; users must avoid treating a personalised answer as proof that its assumptions are still true.
The unresolved design question is not how much an AI can remember. It is whether memory can remain useful without quietly becoming biography, policy and prediction at once. A good assistant should help carry a project forward. It should also know when a fact has reached the end of its job.
Turn this idea into a project
The companion capsule helps you create a Memory Boundary Card, trace how one retained item influences an answer, and test a low-risk correction or expiry without claiming more than the evidence shows.
Version 1.0 · Experimental. Download the text file and upload it to your AI assistant, or copy the complete capsule below into a new conversation. For example: “My assistant still applies a three-bullet preference from a finished workshop; help me create a Memory Boundary Card and test a narrower replacement without using sensitive information.”
Read or copy the complete capsule
# Memory Boundary Card **Capsule ID:** ALK-AI-MEMORY-BOUNDARY-2026-09-24 **Version:** 1.0 **Date:** 2026-09-24 **Canonical article:** https://alkemata.com/2026/09/24/ai-memory-expiry/ **Status:** Experimental; not validated across products, accounts or organisations. ## Scope This capsule helps a person or small team decide what a conversational AI should retain, what should remain only in its source, and what should expire. It does not guarantee deletion from a provider's systems, replace the provider's current controls or provide legal advice. **Intended reader:** anyone using an AI assistant across several conversations. **Capability:** govern remembered context by purpose, source, sensitivity and useful life. **First-session artifact:** a one-page Memory Boundary Card for one recurring task, with explicit retain, review and exclude decisions. ## Essential causal model Persistent memory reduces repetition, but every retained detail can also shape later answers. The useful unit is not “everything the assistant knows”. It is a claim used for a purpose. Use this chain: **Source → extracted claim → retention decision → later retrieval → influence on an answer → human correction or confirmation.** A source might be a chat, file, custom instruction or connected service. A remembered claim can be stored or inferred separately from that source. Removing a conversation therefore may not remove a separately saved memory; removing a memory may not remove the original conversation. Product controls vary and can change. Classify proposed memories by useful life: 1. **Stable preference:** language, units or a durable writing preference. Review occasionally. 2. **Project state:** a current goal, decision or unresolved question. Give it a review date. 3. **Temporary condition:** travel, availability, a short deadline or a draft assumption. Expire it. 4. **Sensitive or consequential fact:** health, finance, identity, employment, legal matters or information about another person. Exclude it by default unless retention is necessary, understood and explicitly chosen. Memory quality has four dimensions: correctness, relevance, provenance and freshness. A fact can be true but inappropriate for the present task; useful but stale; or plausible without a traceable source. More memory does not automatically improve any of these. Authoritative starting points: - European Data Protection Board, GDPR basic principles: https://www.edpb.europa.eu/topics/key-gdpr-concepts/basic-principles_en - European Commission, purpose limitation, data minimisation and storage limitation: https://commission.europa.eu/law/law-topic/data-protection/information-business-and-organisations/principles-gdpr_en - NIST Privacy Framework: https://www.nist.gov/privacy-framework/privacy-framework - OpenAI, current ChatGPT Memory controls and source distinctions: https://help.openai.com/en/articles/8590148-memory-in-chatgpt ## Assumptions and limitations You can inspect at least some product settings or ask the assistant what context it is using. A model's answer about its memory is evidence to investigate, not a complete technical audit. Interfaces, availability and retention behaviour vary by product, plan, region and workspace. Do not paste private records into an AI merely to classify them. Work with neutral labels such as “medical detail” or “client identifier”. For an employer, school or regulated service, follow authorised policies and ask the responsible privacy, security or records professional before changing retention. ## Activation If the reader names a recurring task and one remembered item, start Mission 1 immediately. Otherwise offer the missions and ask at most three questions: What recurring task should memory improve? Which remembered detail affects it? Which product controls can the reader actually inspect? ## Mission 1 — Build a Memory Boundary Card **Input:** one recurring task and up to ten candidate facts or preferences. **Action:** assign each item a purpose, source, useful-life class, sensitivity and decision: retain, retain with review, session-only or exclude. **Output:** the completed template below. **Progression criterion:** every retained item has a stated purpose and every temporary item has a review or expiry trigger. ## Mission 2 — Audit one influence path **Input:** one retained item and a normal, low-stakes prompt where it might matter. **Action:** record the prompt, the context the assistant says it used, the observable influence and whether that influence was wanted. Distinguish the remembered claim from its source. **Output:** a short influence trace. **Progression criterion:** the reader can say whether the item improved the task, distorted it or had no visible effect. ## Mission 3 — Correct, expire or remove **Input:** one low-risk item that is stale, unnecessary or wrong. **Action:** use the product's current documented controls to correct or remove the memory and, when appropriate, its source. Begin a fresh ordinary conversation and repeat the test. **Output:** a before-and-after record plus any unresolved retention question. **Progression criterion:** the new answer no longer relies on the item, or the test exposes a specific control or source that still needs attention. ## Decision rules - Retain only if the purpose is recurring and the benefit is concrete. - Prefer a narrow operational statement over a broad identity label. - Attach a source or provenance note where the interface allows it. - Give project state and temporary conditions a review trigger. - Exclude secrets, credentials and unnecessary information about other people. - Treat inferred traits as hypotheses, not facts. - Do not rely on conversational “forget” requests when the provider documents a separate settings control. - If deletion matters, check all relevant layers: saved memory, originating chat, file, custom instruction and connected source. ## Memory Boundary Card template **Recurring task:** **Desired benefit from memory:** **Product and controls inspected:** **Date checked:** | Candidate item | Purpose | Source | Useful life | Sensitivity | Decision | Review/expiry trigger | |---|---|---|---|---|---|---| | | | | stable / project / temporary / sensitive | low / medium / high | retain / review / session-only / exclude | | **What the assistant must not infer:** **How I will verify correction or removal:** **Unresolved question:** **Next action:** ## Smallest useful reversible experiment **Hypothesis:** correcting or removing one stale, low-risk memory will reduce unwanted personalisation without materially increasing effort on the chosen task. **Resources:** current product documentation; access to memory controls; one low-stakes remembered item; one repeatable prompt; ten minutes. **Procedure:** 1. Choose an item such as an outdated formatting preference—not health, finance, identity or another person's data. 2. Run the normal prompt in a fresh conversation and save only the relevant output excerpt. 3. Record whether and how the item influenced the answer. 4. Correct or remove it using the documented control. If necessary and appropriate, remove the originating source separately. 5. Start another fresh conversation and repeat the same prompt. 6. Compare relevance, unwanted assumptions and extra effort. **Observable success:** the second answer stops applying the stale preference, while the task remains easy to complete. **Observable failure:** the item still shapes the answer, a different source reintroduces it, or removal breaks useful continuity more than expected. **Stopping conditions:** stop if the test would expose sensitive information, affect another person, breach workplace policy or require deleting records that must be retained. **Next action:** keep the correction; restore a narrower version; inspect another source; or escalate a product-control question to the provider or responsible administrator. ## Hypothetical example A reader once asked for every answer to fit into three bullets while preparing a workshop. The preference now distorts detailed research tasks. The card classifies it as project state, source “workshop chat”, low sensitivity, and “remove or replace”. The replacement is narrower: “Use three bullets only for the workshop project until 30 September.” A repeated research prompt should then return normal paragraphs outside that project. This is a simulated example, not field evidence. ## Verification checks - Did you inspect the provider's current documentation rather than assume all assistants work alike? - Can each retained item be tied to a present purpose? - Are source deletion and memory deletion treated as separate operations where relevant? - Did you avoid entering sensitive content into the audit? - Did you repeat the test in a fresh conversation? - Did you record what remains uncertain rather than claiming complete deletion without evidence? ## Boundary where this method does not apply Do not use this lightweight card to decide statutory records retention, litigation holds, medical-record handling, employee monitoring or deletion of evidence. Those decisions require competent organisational and legal authority. The card also cannot prove what remains in backups, safety logs or provider infrastructure. ## Manual or offline route If no memory controls are available, keep the card locally. Start sensitive or temporary tasks in a non-personalised or temporary mode when the provider offers one, or use a separate session without persistent context. Manually paste only the minimum context required for the task. Review and remove that local context when the project ends. ## Portable checkpoint **Decisions made:** **Evidence inspected:** **Items retained and why:** **Items corrected, expired or excluded:** **Verification result:** **Unresolved questions:** **Next action and review date:** On request, use this checkpoint to create a project passport, a field report based only on actual observations, or a precise request for help. Remove private information and choose what to share. Nothing is sent automatically. To propose a documented case or collaboration, use Alkemata's verified route: https://alkemata.com/collaborate/
