Quick disclosure before we start. AI-assisted tools were used in parts of the research and production workflow. Final editorial judgment, risk posture, and release approval stayed human-led. This is operational guidance, not legal advice. These are my opinions and are not representative of any organization. Here is the problem with a better delete button. It feels like closure. You see the setting. You see the memory summary. You see the option that says delete. And your brain does that very human thing where it whispers, Great. The ghost has left the building. Except sometimes the ghost has not left the building. Sometimes the ghost is still in the basement, holding a copy of the lease, wearing a little badge that says, I am not technically a memory anymore. That is the problem we are talking about today. Not because the new controls are bad. They are useful. They are a real improvement. But because a cleaner control surface can make a messy underlying workflow feel more settled than it actually is. The operating question is not, can I delete what I can see? The operating question is, can I prove what changed after I deleted it? As I am source-checking this on Monday, June fifteenth, twenty twenty-six, the freshest official OpenAI lead is the June twelfth ChatGPT release-note entry. OpenAI says users can now delete memories shown on the memory-summary page, and they can choose Delete and turn off memory from the three-dot menu. That sounds simple. That sounds clean. That sounds like a little broom icon came down from product heaven and swept the whole problem into a tasteful settings drawer. But the same release note says something very important. This does not delete your past chats. And if you turn memory back on later, ChatGPT may create new memories from chats that remain in your chat history. So today is not a feature-tour episode. Today is an exit-rights episode. What counts as actual correction? What counts as actual deletion? What counts as turning memory off? And what evidence should an operator keep before sensitive or stale context quietly walks back into the room wearing a different hat? Welcome back to AI Change Desk. I am Michael. Today is the Monday main episode for June fifteenth, twenty twenty-six. And this is episode thirty-two: Memory Summary Exit Check. Let us start with the useful part. OpenAI is making memory easier to inspect and manage. That matters. The June twelfth release notes say you can delete memories shown on your memory-summary page. They also say you can turn memory off from the same menu. That is good product direction. Because if a system is going to remember things about your work, your preferences, your projects, your recurring decisions, or your tendency to ask for one more revision at eleven forty-seven at night, then the user needs a place to review and correct that context. A memory system without visible controls is not personalization. It is a vibes-based filing cabinet. And the filing cabinet is somehow confident. So yes, visible memory controls matter. But this is where operators have to slow down. Because the release note does not say, this deletes every source that may have contributed to the memory. It says this does not delete your past chats. That sentence is the whole episode. Deleting the summary is not the same as deleting the source. That distinction is boring in exactly the way important governance work is boring. It is the boring that saves you from explaining, later, why a system kept acting on context everyone thought had been removed. If the memory summary says, this user prefers vendor A, and you delete that summary line, that may remove what you can see. But if the old chats still contain ten conversations where vendor A was treated as the default, then the system may still have source material that can shape future personalization once memory is active again. That is not a scandal. That is how source-based context works. But it means the operator cannot treat the visible summary like a complete ledger. It is more like the executive summary of a very needy archive. Helpful. Shorter. Absolutely not the whole archive. The Memory FAQ makes this even clearer. It says the memory summary does not necessarily include everything ChatGPT remembers. It describes memory as a continually updated synthesis of context from past chats. It also says some details may not appear in the summary, including when ChatGPT determines they are less relevant, or not appropriate to show in that view. That is a perfectly reasonable product explanation. But operationally, it creates a partial-ledger problem. If the summary is not complete, then a clean summary is not proof of a clean state. A clean screen is not a clean system. That line is worth taping to whatever dashboard your organization uses to pretend it has one dashboard. Because this is where teams get into trouble. They confuse interface comfort with evidence. They see a setting. They see a delete option. They see memory off. They assume the control question is over. But the real control question has just started. What source created the memory? Was it a saved memory? A past chat? An archived chat? A file? Custom instructions? A connected app? A Gmail thread? A document that looked harmless until it became the world’s most emotionally persistent footnote? The FAQ is careful here. It says memory sources are designed to make memory easier to understand and control, but they may not show every factor or source that shaped a response. Again, that does not mean the feature is broken. It means the operator needs a different test. Not just, can I see a source? But, what would we do if the source list is incomplete? What would we do if the system used one of several old conversations? What would we do if the visible memory is gone, but the pattern reappears because the underlying record is still sitting there like a raccoon in the ductwork? And yes, apparently the raccoon from prior episodes has tenure now. This is where I want to separate three words that people tend to blend together. Correction. Suppression. Deletion. They are not the same control. Correction means the system had the wrong or stale idea, and you are trying to replace it with a better one. Suppression means you do not want the system to bring something up again. Deletion means you are trying to remove the stored or source context that lets the idea keep reappearing. Those are different jobs. And different jobs need different receipts. If your governance language treats correction, suppression, and deletion as synonyms, your audit trail is already lying to you. The Memory FAQ gives a good example of why. It says you can choose Don't mention this again. That can help reduce unwanted references. But reducing unwanted references is not the same thing as deleting the information. In human terms, that is the difference between, please stop bringing up my old haircut, and, please destroy every photo from that era. Those are different requests. One is social mercy. The other is records management. And in an enterprise workflow, that distinction matters. Suppose a support team uses a memory-backed assistant. The assistant has learned that a certain customer is always escalated. Then the account changes. New contract. New support tier. New contacts. The old escalation assumption is now stale. An operator deletes or corrects a visible memory. Fine. But what if the old escalation pattern is still in prior chats? What if it is in an uploaded account brief? What if it is in a connected email thread? What if the assistant stops saying the old thing out loud, but still prioritizes answers as if the old escalation pattern were true? That is not a theoretical compliance riddle. That is Monday morning triage. The manager does not need a philosophical debate about memory ontology. Nobody wants a white paper titled, Is The Ghost Still In The Workflow? Although, honestly, I would read that. The manager needs a checklist. What did we correct? What did we suppress? What did we delete? What sources did we clean up? What test did we run afterward? And what changed in the model or workflow while we were doing all of that? That last question matters because the June twelfth release notes included another operationally important item. OpenAI says GPT-five point two models are no longer available in ChatGPT as of June twelfth. That applies to GPT-five point two Instant, Thinking, and Pro. Existing conversations that used GPT-five point two automatically continue on the corresponding GPT-five point five model. Now, for most users, nobody is going to light a candle and hold a farewell ceremony for a retired model version. Though somewhere, someone has absolutely made a spreadsheet. But for operators, this is not trivia. It is continuity risk. Because a conversation can feel continuous while the model underneath it changes. The thread is the same. The title is the same. The user intention is the same. But the behavior may not be identical. That means a memory correction test should not only say, we deleted the visible memory and asked again. It should say, which model was used before? Which model was used after? Did the same prompt behave differently? Did the unwanted context reappear? Did the assistant infer it again from old material? A deletion receipt without a version note is a weak receipt. This is the part of AI governance that is annoying because it sounds like paperwork. But it is not paperwork for the sake of paperwork. It is the difference between knowing what happened, and having a confident story about what probably happened. And confident stories are where change programs go to become expensive folklore. Now let us bring in the June eleventh Developer mode update, because it is not the lead anymore, but it belongs in the same control stack. OpenAI's release notes say Developer mode gives Codex controlled Chrome DevTools Protocol access for Browser use in Chrome and the Codex in-app browser. The developer documentation describes access to things like console output, network traffic, page state such as the DOM and applied styles, and performance diagnosis. It also says full CDP access may put data at risk, and requires explicit approval before using it to inspect a website. That is not memory. That is inspection authority. But memory context and inspection authority can meet inside the same workflow. The system may remember your project preferences. It may inspect a live browser state. It may reason across both. And suddenly the question is not just, what did it remember? It is, what did it remember while it was allowed to inspect? That is why the exit check cannot live only in the memory settings page. It has to live in the operating model. If the assistant used remembered context to decide what looked suspicious in a page, or what network request mattered, or what error looked related, then a later memory correction may affect more than personalization. It may affect what the agent notices. What it ignores. What it recommends. And what a human reviewer thinks has already been checked. Memory is not just background context when it changes inspection priorities. This is also why Lockdown Mode stays in the episode as a boundary, not a magic shield. OpenAI describes Lockdown Mode as an optional advanced security setting that limits web and external-service access to help reduce data-exfiltration risk from prompt injection. That is useful. But it is not the same control as memory deletion. And it is not the same control as browser inspection approval. These are separate layers. Memory context. Inspection authority. Network and external-service access. Model version. Human approval. Disclosure. If your policy collapses all of that into, AI settings are on, or AI settings are off, then your policy is not a policy. It is a light switch with delusions of grandeur. And look, I love a good light switch. Very decisive. Very binary. Very satisfying. But modern AI workflows are not light switches. They are more like hotel thermostats. You press buttons. Something happens eventually. You are never entirely sure whether you are in control, or whether the building made a choice in nineteen eighty-seven and everybody is just respecting it. Now let us make this practical. Here is the Memory Summary Exit Check. It takes forty-five minutes. Not because forty-five is magical. Because if a team cannot spend forty-five minutes proving a memory exit worked, then that memory probably should not be used in a high-consequence workflow yet. First: identify the visible memory item. What does the summary say? What wording is wrong, sensitive, stale, or no longer allowed? Write it down. Not the whole biography. The exact operating claim. For example: prefers vendor A. uses customer escalation path B. works on project C. should write in executive tone. Has access to dataset D. Be precise. If you cannot name the memory, you cannot prove the exit. Second: classify the requested action. Is this correction? Suppression? Deletion? Or memory off? Do not let people say, we handled it. Handled is not a control state. Handled is what you say when you do not want follow-up questions. Third: list the likely sources. Past chats. Archived chats. Files. Custom instructions. Connected apps. Saved memories. Shared operating docs. If the answer is, we do not know, that is not failure. That is the start of the work. The failure is pretending the summary was the whole map. Fourth: perform the control action. Correct the summary. Delete the visible memory. Turn memory off if that is the decision. Use Temporary Chat if the next test should not create or use memory. Disconnect an app if the source lives there. Delete or revise the source file if the source file is the problem. And record which action happened where. Fifth: run a reappearance test. Ask a neutral version of the task again. Do not prompt the system with the answer you are trying to avoid. Do not say, please do not remember vendor A, and then act shocked when vendor A is in the conversation. That is like telling someone, do not think about a raccoon with admin rights. Too late. The raccoon has entered the meeting. Instead, ask the normal task. See whether the stale or sensitive assumption returns. See whether it returns directly, indirectly, or through prioritization. The phrase may be gone, but the behavior may remain. The test is not only what the system says. The test is what the system assumes. Sixth: record the model and workflow context. Which model was used? Was this before or after a model retirement? Was Developer mode involved? Was browser inspection approved? Was Lockdown Mode on? Were connected apps active? Was this a normal chat or Temporary Chat? Was there a file in the Library? These details are not decoration. They are the difference between a reproducible test and a campfire story. Seventh: decide the outbound rule. If the work affects customers, employees, partners, or a public audience, what disclosure or review is required before the artifact leaves the building? This is where the YouTube AI-label update and the Podnews disclosure guidance stay relevant. Not because they answer your internal governance question. They do not. But because they remind us that audience trust is downstream from internal control. If AI materially shaped the artifact, or the audience could reasonably be misled about how it was made, you need a disclosure decision. Not a vibes decision. A real one. So where does this leave us? The new memory controls are useful. They make the system easier to manage. They give users a more visible way to correct and delete what they can see. That is good. But the operator cannot stop there. Because memory is not just a list. It is a synthesis. The summary is not complete. Sources may not show every factor. Past chats may remain. Old context can reappear. Model versions can change underneath an existing conversation. And inspection authority can expand what the AI is able to see while remembered context shapes what it notices. That is the control stack. Not one button. A stack. The exit is not real until the evidence survives the re-test. That is the whole Monday action. Pick one workflow this week. Not the whole enterprise. One workflow where memory-backed AI is already useful enough that people would be annoyed if you turned it off. That is usually the right place to look. Open the memory summary. Find one stale or sensitive assumption. Classify the action: correct, suppress, delete, or turn off. List the sources. Perform the action. Run the reappearance test. Record the model and workflow context. Then decide whether the outbound artifact needs disclosure or extra review. Forty-five minutes. One workflow. One receipt. If you cannot produce that receipt, do not panic. Do not write a fourteen-page policy called Responsible Memory Governance Framework Final Final Two. Please. I am begging you. The file name alone has already failed governance. Just name the gap. Maybe the gap is source visibility. Maybe it is connected-app cleanup. Maybe it is model-version tracking. Maybe it is unclear ownership. Maybe nobody knows who approves browser inspection. Good. That is the work. You cannot manage the invisible parts of the workflow by pretending the visible button solved them. That is it for this episode of AI Change Desk. The takeaway is simple. A better memory control is not automatically a complete memory exit. Correction is not suppression. Suppression is not deletion. Deletion is not source cleanup. And source cleanup is not proven until the workflow is tested again. Do not scale the setting. Scale the receipt. I am Michael. This has been AI Change Desk. I will see you in the next one.