You deleted the conversation. The product still knows what was in it. This issue is about where that knowledge lives, and why "delete" means something different in each place.

Where we've been - Part 1 — It predicts the next word. That is the whole machine. A language model guesses the next word, then does it again. There is no step in that loop where it consults a source. → https://buttondown.com/the_desk/archive/it-predicts-the-next-word-that-is-the-whole/ - Part 2 — Where your draft actually goes. Which account you were logged into decides whether your text is used for training, and whether any processor relationship exists at all. → https://buttondown.com/the_desk/archive/where-your-draft-actually-goes/

This issue assumes you know nothing about how these systems work. Every term is explained before it is used.

Start here

After Part 2, you did the careful thing. You found the conversation where you had pasted three paragraphs of a draft (the client's name, the disputed sum, the argument) and you deleted it.

Two weeks later you open a fresh chat and ask something unrelated. The answer arrives already knowing what kind of matter you are working on.

That is not a malfunction. One vendor gives its own example of exactly this behaviour: hand it a task, it says, and "it already knows who that is and how they like updates written."

You deleted the conversation. How does it still know?

Because the thing that remembers is neither the conversation nor the model. It is a third record: a note the product wrote about you while you were talking. That note has its own delete button. Deleting the conversation does not press it. Both of the two major vendors say so in terms, and they are quoted below.

So "delete my chat" and "delete my data" are two different requests. This issue explains why, and what each one actually reaches.

What Part 2 left open

Part 2 used two nouns and kept them strictly apart.

THE MODEL is the next-word predictor from Part 1. It holds nothing. It reads what it is handed, produces an answer, and keeps no record of you.

THE PRODUCT is what you log into and pay for: ChatGPT, Claude, Gemini. The model is one component inside it.

Part 2 ended on a consequence of that split. If the model keeps nothing, then everything that looks like memory is built by the product, outside the model. The history you can scroll back through. The fact that it knows your job. The document you uploaded last month.

Part 3 opens that box. To do it, one more term is needed.

One new term: the context window

THE CONTEXT WINDOW is the text the model is given for a single reply. It is the only thing the model can see. Anything inside the window exists for the model. Anything outside it does not.

The developer documentation calls it "a 'working memory' for the model". Here is the fact most people never hear. The model does not follow your conversation as it goes along. Each time you press enter, the product sends the model the conversation again — as much of it as still fits in the window — and the model reads it as though for the first time.

"The Messages API is stateless, which means that you always send the full conversational history to the API." — Anthropic, Working with the Messages API

What stateless means, one turn at a time

Stateless means it carries nothing over from one request to the next. Nothing at all. It is worth walking through an ordinary exchange slowly, because everything else in this issue follows from it.

Your first message. You type a question and attach a photograph of a document. The product sends the model that question and that image together. The model reads them, writes its answer, and stops. It now retains nothing — not your question, not the image, not the answer it has just given you.

Your second message. You type three words: "and the deadline?" On their own those three words mean nothing to anybody. So the product does not send them on their own. It sends your first message, the image, the model's first answer, and then your three words — the whole pile, again, in order. The model reads all of it as though it had never seen any of it before, and answers.

Your tenth message. The same thing happens, except that the pile now holds nine earlier exchanges. Every turn re-sends what came before it, and the pile gets longer every time — until it gets too long, which is the next thing to understand.

Products differ in how an attachment is carried forward — the file itself, a text extraction of it, or nothing once it has been read. The principle does not differ: whatever the model is to know on this turn, the product has to put in front of it again on this turn.

That pile has a name. It is the transcript: the written record of the conversation so far — your messages and the model's replies, in the order they were written, together with anything you attached. It is what you are looking at when you scroll up, and the developer documentation describes the same pile from the machine's side: each turn's input "contains all previous conversation history plus the current user message".

So what feels like the machine remembering you is the product handing it the transcript again, every single time.

And this is where length starts to cost you

The window is finite. Keep a conversation going long enough and the transcript stops fitting, and something has to give. There are two ways products deal with that, and both matter to a lawyer.

One — the oldest turns may simply be dropped. Anthropic says of its own chat interface that it "can also manage the context window on a rolling 'first in, first out' basis." First in, first out means the beginning of your conversation falls off the front.

Two — the older stretch is replaced by a summary of itself. The trade name for this is compaction:

"…as a conversation grows, response quality degrades, so compaction replaces older content with a concise summary." — Anthropic, Compaction

Read that twice. What reaches the model after compaction is not what you wrote. It is a machine-written précis of what you wrote, made without your sight of it, and your original words are gone from the window.

Context rot

There is a second effect, and it begins long before the window is anywhere near full: performance does not hold steady as the input grows. The vendor's own documentation states it as a known property, and names it.

"More context isn't automatically better. As token count grows, accuracy and recall degrade, a phenomenon known as context rot." — Anthropic, Context windows

The measurement behind that is public: a July 2025 study of eighteen models across the Anthropic, OpenAI, Google and Alibaba families found that "models do not use their context uniformly; instead, their performance grows increasingly unreliable as input length grows" (Kelly Hong, Anton Troynikov and Jeff Huber, Context Rot: How Increasing Input Tokens Impacts LLM Performance, Chroma, 14 July 2025).

Put those together and the working rule writes itself. A very long chat is not a better-informed assistant. It is a longer document, re-read from scratch every turn, with its earliest parts the first to be dropped or summarised away. A fact you gave it in the first ten minutes may not be in front of it an hour later — and nothing on the screen will tell you it has gone. If it matters, put it in the message you are sending now. Do not rely on its having been said earlier.

That also gives a clean way to ask the whole question of this issue. If the model itself keeps nothing between turns, "what does it remember about me?" really means: what does the product choose to put into the window, and where does it keep that material between times?

The four places the product keeps what you said

There are four, and each one is a separate record with its own controls.

One — the conversation history. The transcript described above — your messages and its replies, kept in order. The product stores it so that you can scroll back through it, and re-sends it to the model each time you continue that conversation.

Two — the memory. This is the one that surprises people. It is not your words. It is the product's notes about you, written while you talk and fed into future conversations. One vendor calls its version a memory summary — "a high-level view of information that ChatGPT may use to personalize responses". Another saves memory "as a set of individual topics as you chat" and lists what it keeps, including "Your role, projects, and professional context" and "The people and places in your work and life". For a lawyer, the people in your work are your clients.

Two further details from the vendors' own pages matter here:

• It may be on without anyone switching it on. One vendor states that memory "is on by default for Free, Pro, and Max plans", and off by default on its business plans until an owner enables it.
• The page that shows your memory does not show all of it. The other vendor puts the question to itself — "Does the memory summary include everything ChatGPT remembers?" — and answers: "No. The summary is a high-level view and may omit details that are less relevant, unsuitable for the summary, or derived from sources that are not displayed individually." Its advice: "You can also ask ChatGPT what it remembers about you."

Three — search across your past chats. Some products can look through your old conversations and copy the relevant parts into the window before the model sees your question. One vendor says these searches "use Retrieval-Augmented Generation (RAG)". Retrieval simply means: search a store of material, pick out what looks relevant, paste it into the window. (How that search actually works is a later part of this series.)

Four — files and connected apps. Documents you uploaded, project files, and connectors into a mailbox or a drive. One vendor lists the sources its memory may draw on: "past chats", "saved memories", "custom instructions", "files in Library" and "content from connected apps, such as Gmail".

And there is a fifth store that is not yours at all: the copies the vendor keeps for its own reasons, such as safety review, feedback, and legal obligations. You have no delete button for that one. It is covered below.

The sentence both vendors publish

Here is the point on which "delete my chat" and "delete my data" come apart, in each vendor's own words.

"When a conversation expires or is deleted, related memory entries generated from it won't be removed, but you can delete individual memories at any time." — Claude Help Center, Use Claude's chat search and memory to build on previous context

"Saved memories are stored separately from chat history. Deleting the original chat does not automatically delete a separate saved memory." — OpenAI Help Center, Memory in ChatGPT

It also runs in the other direction. Delete the memory and the chat survives: the same vendor explains that deleting a saved memory "prevents it from being used in future personalization, but it does not remove mentions of that information from past conversations."

And OpenAI's own instruction for removing something completely is a list, not a button:

"To remove information saved as a memory, delete the saved memory and the chat where you first shared it. Also remove the information from any other sources where it appears: the memory summary; saved memories; regular and archived chats; files in Library; connected apps." — OpenAI Help Center, Memory in ChatGPT

Not every product is built this way. Google's page says the opposite for its own memory feature, which works by referencing your saved chats: "To stop Gemini from personalizing your experience using info from a past chat, delete that chat."

Same button, different consequence, depending on how the product was built. That is the first reason deletion is contested rather than simple.

What each button actually reaches

Every line of this table was read first-hand and re-read on 20 September 2026, the day this issue went out: OpenAI Help Centre, "Memory in ChatGPT" and "Chat and file retention policies in ChatGPT" and "Temporary chat in ChatGPT"; Anthropic Privacy Centre, "How long do you store my data?"; Claude Help Center, "Use Claude's chat search and memory…"; Google, Gemini Apps Privacy Hub (last updated 10 August 2026). These pages change. Check them before relying on this table.

That last sentence is not boilerplate. Here is what happened to this issue.

This issue was drafted on 17 September 2026 and every vendor quotation in it was read first-hand that day. It was checked again before publication on 20 September 2026.

In those three days, OpenAI rewrote its memory help page. When the page was opened at 16:51 IST on 20 September 2026 it carried the line "Updated: 13 hours ago" — placing the rewrite in the early hours of that same morning. The article had also been renamed, from Memory FAQ to Memory in ChatGPT.

Nine sentences that had been quoted from it on 17 September were no longer on the page. Gone with them: the "notepad" metaphor for saved memories, the instruction to "delete every source where it appears", and the admission that the summary page "will not include everything that ChatGPT remembers based on your chats".

Every one of those points still survives on the new page, in new words — and on two of them the new page is blunter than the old one. That is why this issue reads as it does: the quotations above are the ones live on 20 September 2026, not the ones drafted three days earlier.

The practical lesson is the one worth carrying. A vendor help page is not a statute. It is not dated in the way a gazette is, it is not versioned where you can see it, and no one tells you when it changes. If you are advising a client on what a product does with their data, a screenshot with a date on it is worth more than a link — because the link will keep resolving long after the sentence you relied on has gone.

One correction, not merely a rewording, came out of that re-check, and it is in the table above. On 17 September the position recorded for a temporary chat was that it is deleted after thirty days. The live pages on 20 September say OpenAI "may keep a copy of a temporary chat for up to 30 days for safety purposes." Kept, not deleted. If you took the earlier reading from anywhere, take this one instead.

Why deletion is contested rather than simple

Reason one: there is no single copy. The conversation, the memory, the search across past chats, the files and connectors are separate records. Each has its own control, and pressing one does not press the others.

Reason two: the memory is not your words. It is what the product concluded about you. A request framed as "delete what I gave you" does not obviously reach "what you wrote down about me", and, as the next section shows, the law does not answer that the same way everywhere.

Reason three: other duties outrank the button. All three vendors reserve copies they keep for themselves: for safety review, for feedback, or for legal obligations. One says it may retain chats "as required by law, to resolve disputes, or as necessary to combat violations of our Usage Policy."

That last reservation is not theoretical. In 2025, for a little over four months, a chat deleted on a personal ChatGPT account was not actually deleted: it was kept under a court order. On 13 May 2025, Magistrate Judge Ona T. Wang made an order in In re: OpenAI, Inc., Copyright Infringement Litigation, No. 25-md-3143 (SHS)(OTW) (S.D.N.Y.) — the consolidated copyright proceeding — on the docket of the newspaper's own action, The New York Times Company v. Microsoft Corporation et al., No. 23-cv-11195. It directed OpenAI "to preserve and segregate all output log data that would otherwise be deleted on a going forward basis until further order of the Court", and it said so expressly of data that would be deleted "at a user's request or because of 'numerous privacy laws and regulations' that might require OpenAI to do so." In OpenAI's own description, the demand was "that we retain even deleted ChatGPT chats". On 9 October 2025 the court released OpenAI from that obligation going forward, and OpenAI states that its obligations "ended on September 26, 2025". The same page says it "will securely store limited historical April–September 2025 user data." The litigation is continuing, and nothing further about it is stated here.

And one copy no button reaches: the model itself. Part 2 explained why training cannot simply be reversed. Anthropic's retention page puts the consequence plainly: even after you opt out or delete, "Your data will still be included in model training runs that are already in progress, or in models that have been trained."

Where the law grips: three laws, three different objects

Every right to erasure has to say what it erases. The three regimes lawyers most often meet answer that question in different words, and a memory (a note the product wrote about someone) sits exactly on the line between them.

Europe: data concerning the person

"The data subject shall have the right to obtain from the controller the erasure of personal data concerning him or her without undue delay…" — Article 17(1), GDPR

Concerning is not limited to what the person supplied. A note a product wrote about someone is data concerning them.

Europe also states the limits, in the same article. Erasure does not apply where processing is necessary "for compliance with a legal obligation which requires processing by Union or Member State law" (Article 17(3)(b)), or "for the establishment, exercise or defence of legal claims" (Article 17(3)(e)). Keeping material for a pending dispute is the obvious case of the second.

California: information collected from the consumer

"A consumer shall have the right to request that a business delete any personal information about the consumer which the business has collected from the consumer." — California Civil Code §1798.105(a)

The statute separately treats "Inferences drawn … to create a profile about a consumer" as personal information (§1798.140(v)(1)(K)). In Opinion No. 20-303 (10 March 2022), California's Attorney General held that inferences a business generates internally must be disclosed on request, reasoning that the law gives consumers "the right to receive all information collected 'about' the consumer, not just information collected from the consumer."

Read the two rights side by side. The right to know reaches information about you. The right to delete reaches information collected from you. The opinion decided the first. It did not decide whether a deletion request reaches a profile the business wrote, and the statute uses different words for the two.

India: her personal data, processed on consent

"A Data Principal shall have the right to correction, completion, updating and erasure of her personal data for the processing of which she has previously given consent…" — Section 12(1), Digital Personal Data Protection Act, 2023

"Personal data" is defined in s.2(t) as "any data about an individual who is identifiable by or in relation to such data": about, like California's right to know, not from. On that definition, a note a product wrote about a person is her personal data.

The duty on receiving the request, in s.12(3), has two exceptions: the Data Fiduciary "shall erase her personal data unless retention of the same is necessary for the specified purpose or for compliance with any law for the time being in force."

The Act never mentions derived information. The words infer, derived and memory appear nowhere in the Act, and infer and derived appear nowhere in the Rules. So the open question is not whether the note is her personal data. It is whether that note is her personal data "for the processing of which she has previously given consent", and the text leaves that to be argued.

What to do next

Three things for yourself, this week.

1. Read what the product has already written about you. ChatGPT: Settings → Personalization → Memory. Claude: Settings → Memory. Read it the way you would read a file note somebody else made about a meeting you were in — not "is this flattering" but "is this accurate, and who can see it now". On ChatGPT, ask it directly in a chat as well — the vendor answers its own question "Does the memory summary include everything ChatGPT remembers?" with "No", and suggests: "You can also ask ChatGPT what it remembers about you."
2. Delete in both directions, not one. The memory entry and the conversation it was written from. Then the archived chats, the uploaded files, and any connected mailbox or drive. Pressing one of these does not press the others — which is why the vendor's own instruction for removing something completely names five places: "the memory summary; saved memories; regular and archived chats; files in Library; connected apps."
3. Know the difference between pausing and deleting. Pausing memory keeps everything already written. Turning memory off and clearing it can still leave behind the chats from which new memories will be rebuilt the moment it is switched back on.

Three things about how you use it at all.

4. For anything touching a client on a personal account, use a temporary or incognito chat — and read "temporary" as "not kept in your history", not as "not kept". One vendor says it "may keep a copy of a temporary chat for up to 30 days for safety purposes"; the other retains it "with your account for 72 hours". A temporary chat creates no memory. It is not a shredder.
5. Do not let one chat run long on a matter that matters. For the reasons set out in the context-window section above, a long conversation may be truncated or summarised before the model sees your next message, and reliability falls as it lengthens either way. Start a fresh chat and restate the facts that count. Restating is cheap; assuming it still holds them is not.
6. Treat "delete" as a request with a timetable, not an event. Roughly thirty days as standard. Years, where a conversation was flagged or human-reviewed. And, in principle, for as long as a court says so.

Two things before a client ships a product that remembers its users.

7. Make them map every copy before you draft a line of the privacy policy. Where does each copy live — the transcript, the derived notes, the search index over past conversations, the uploaded files, the server logs? Which of those does a deletion request actually reach today, as the thing is built? What must be kept anyway, and under which law? And who answers the user who writes in and says "I deleted that"?
8. Then check that the promise matches the plumbing. A deletion promise the architecture cannot keep is not a drafting problem to be tidied up in the terms. It is a build problem that the terms will eventually expose — and from May 2027 in India, Rule 8(3) fixes part of the answer whatever the interface says.

If you have come in at Part 3, the two issues before it are free, need no account, and take about ten minutes each:

• Part 1 — It predicts the next word. That is the whole machine. What a language model actually does, and why it invents things. → https://buttondown.com/the_desk/archive/it-predicts-the-next-word-that-is-the-whole/
• Part 2 — Where your draft actually goes. Which account you were logged into decides whether your text is used for training, and whether any processor relationship exists at all. → https://buttondown.com/the_desk/archive/where-your-draft-actually-goes/

India Desk

From May 2027, the Rules themselves put a floor under deletion. Rule 8(3) of the Digital Personal Data Protection Rules, 2025 requires a Data Fiduciary to retain, "in respect of any processing of personal data undertaken by it or on its behalf by a Data Processor, such personal data, associated traffic data and other logs of the processing for a minimum period of one year from the date of such processing, for the purposes as specified in the Seventh Schedule", and only then to cause them to be erased.

The Rules' own illustration makes the point directly. After an e-book sale, the platform "must retain the order details, personal data, and logs of the processing … for at least one year from the date of the transaction, even if X deletes her account." A second illustration carries it down the chain: a company using a cloud provider as its processor must ensure the provider "also retains the data and associated logs for at least one year before erasure."

Three things follow for anyone advising on a product that remembers.

• The purposes are the State's. The Seventh Schedule lists uses by the State and its instrumentalities, including "in the interest of sovereignty and integrity of India or security of the State". The year-long floor is kept for those State purposes. It is not a general licence for the business to go on using the data.
• It meets s.12(3) at its second exception. A request to erase under s.12(3) yields where retention is necessary "for compliance with any law for the time being in force". Rule 8(3) is such a requirement for the logs and data it covers.
• So the honest answer to an Indian user who deletes their account may well be: held for a year for the purposes the Rules specify, then erased. A product that promises "instant, permanent deletion" to Indian users from May 2027 will need to reconcile that promise with Rule 8(3). Rule 8 is among the provisions that commence eighteen months after the Rules were published on 13 November 2025.

Global: one word decides the reach

Europe erases what concerns you. California deletes what was collected from you, while letting you know what is held about you. India erases your data processed on your consent, with personal data defined as data about you.

Memory features are, by design, machines for turning what a person said into what a product concludes about them. The more a product remembers, the more of what it holds is derived rather than supplied. Which of those words a statute chose, concerning, from or about, decides how much of that derived record a deletion request can reach.

PRACTITIONER'S VERDICT

What to tell a colleague this week. Deleting the conversation is not deleting what the product learned from it. On both of the two major products, the memory is a separate record with its own delete control, and each vendor says so in terms. So the check has three steps: read the memory page, delete the memory and the conversation, and use a temporary chat for anything you would not want written down about you — remembering that a temporary chat is not kept in your history but a copy may be kept anyway. Then remember what no button reaches: copies held for safety review, for feedback, under a court order, and, once training has happened, the model itself. For clients building these products, the question is not whether they offer deletion. It is what their deletion reaches, what it cannot reach, and whether their users have been told the difference. In India, from May 2027, part of that answer is fixed by Rule 8(3): a year's retention of logs, whatever the user presses.

WHERE WE ARE GOING

Next — Part 4: how it searches what you gave it. When a product "reads your documents", it does not read them the way you do. It converts them into long lists of numbers and searches those. Whether those numbers are still personal data is the question Part 4 takes up.

This issue is written for lawyers and is general in nature. It is not legal advice and no lawyer-client relationship arises from reading it.

Every statutory reference and every date in this issue was checked against at least two independent sources before it went out. Vendor terms were read first-hand on the dates stated. Where a claim could not be verified to that standard it does not appear, or it is stated as an absence of record rather than as a fact. The archive, and everything else I have been building, is at wolfgangrush.github.io

This issue as a PDF (14 pages, 3 figures, page-numbered) https://wolfgangrush.github.io/assets/The-Primer-Part-03-2026-09-20.pdf

Every free document — no email wall https://wolfgangrush.github.io/resources/