Forgetting

Forgetting

People ask an agent to forget. Laws in many places require it. A memory you cannot delete is a liability. In session 8 the user says "Please forget my phone number."

A correct forget has to do three things, and the experiment checks each one.

1. Remove every version. Not only the current value: the history rows too, and anything quarantined under that key.
2. Remove copies elsewhere. If the number is quoted in a session summary, a procedure or a decision, deleting the fact row leaves it behind. forget_fact scrubs the value from the other tables (replacing it with [removed]).
3. Make the delete real. A DELETE in SQLite marks space as free but does not overwrite it, so the bytes can stay in the file. I turn on PRAGMA secure_delete, which overwrites deleted content, and the test reads the raw file.

The experiment builds two worlds: the number is stated on an ordinary line, or it is the first line of a session so that the summary quotes it. Then it asks whether the number is still in the database file.

The last row is the realistic failure: the fact row is gone and the user's number is still sitting in a summary, in the file. A raw transcript and a flat note list cannot do any of this: the number is a line in a log, and removing it means rewriting history. In the same experiment the flat policy leaks the number every time, and transcript leaks it as soon as the budget is big enough to include session 1.

Cost: what each approach stores and reads

After twelve sessions the raw transcript is 6,093 tokens and the typed memory, dumped as text, is 292 tokens. The transcript grows with every turn; the typed memory grows with every distinct fact, decision and procedure, which is much slower, and it stops growing for a user whose life is stable.

Reading costs follow storage: typed reads 39 tokens a question here. Two things to keep in mind. First, the typed memory is only small because this user's world is small (six facts, one procedure, three decisions); a real one has hundreds of facts and the "include all facts every time" shortcut stops working, at which point facts need selecting too, which is retrieval (module 4). Second, writing costs tokens as well: a real extractor is a model call per turn or per session, and that is a cost this example does not show.

Planted defects

The suite has 131 tests. They pin the store (replace, history, forget, scrub, versions, quarantine, ordering, persistence to a file, the overwrite pragma and the file-byte check), every extraction pattern and the paraphrases it must miss, the gate for each source and each kind of write, the world's own invariants (every answer is somewhere in the transcript, the planted events happen in the right sessions), the five policies, the judge, and the headline claims of the experiments.

As in module 1, I wrote down before the first run whether I expected each of 28 one-line defects to be caught or to escape.

• 25 of 28 caught; 3 escaped, exactly the 3 I predicted. Every prediction held. (I wrote the tests, so I knew where they were thin; that is a weaker claim than it sounds.)
• Caught: forgetting that only hides the fact (a soft delete), forgetting that keeps the history, secure_delete switched off, copies surviving by default, procedure text surviving a scrub, quarantined rows surviving, an old value left current beside the new one, history erased by an update, unsorted facts and episodes, procedure versions that never increase, a tool treated as trusted, a gate that guards facts only, blocked writes dropped without a trace, a phone pattern that needs a capital letter, an extractor that suddenly understands the paraphrase, summaries that lose their decisions or are cut to 20 characters, a replay that takes the oldest turns or overshoots its budget, typed recall without the fact table, every procedure or every decision shown whatever the question, and a judge that ignores a stale value or a leak.
• Escaped, and each one is a real hole, not a quirk: 1. gate_default_open: the write function's default gate becomes "open". All my tests pass the gate explicitly. Anyone who calls apply() without the argument gets the dangerous behaviour. The safe default has no test. 2. assistant_can_write: the assistant's own lines are allowed to write memory as if the user had said them. No test feeds the extractor an assistant line that contains a pattern. 3. procedure_not_demoted: an old procedure version stays marked current beside the new one. It escapes only because of an accident of SQLite and Python: both rows come back, and the dictionary keeps the last. A change in ordering would break it silently.

All three are closable in a few lines; medium exercise 1 asks you to do it and to show the mutants are then caught. I left them open on purpose, as I did in module 1, so you can see the shape of a suite that passes and is still not enough.

What the example does not do

• No real extractor or summariser. Both are patterns, so they are predictable and brittle (section 7).
• Word overlap, not meaning. Recall of episodes and procedures works because the question repeats words from the record. A question like "what money did we set aside for the Lisbon trip?" would miss. Module 4 fixes this.
• Always includes all facts. Fine for six, impossible for six thousand.
• No expiry. "This week I am in Berlin" is a fact that should disappear. Medium exercise 2 adds it.
• No conflicts between two trusted sources. If the user says one thing and a calendar says another, which wins? Here the user always wins by being the only trusted writer.
• One user, no isolation. A real service keeps each user's memory strictly apart; a bug here is a data leak between customers.
• No consent or privacy design: what is worth remembering, how long, and how the user sees it, are product and legal questions that code cannot settle.
• The forgetting claim is narrow (section 9): one database file, checked by scanning its bytes on one filesystem.

A checklist for "memory across sessions"

1. Say what you remember, in which kind (fact, episode, procedure), and give each kind an update rule.
2. Decide who may write. Untrusted text never changes memory; its proposals wait for review.
3. Store the source of every record.
4. Keep history for facts if you need audit; know that history is also a copy to delete.
5. Write a real forget: every version, every derived copy, and check the bytes.
6. List every place the data lives (store, summaries, logs, backups, indexes, providers) so "forgotten" means something.
7. Measure extraction recall on paraphrases and on over-eager writes, with real model outputs.
8. Keep a searchable raw log as the fallback for what extraction misses, under the same deletion rules.
9. Let the user read and edit their memory.
10. Plant defects in the store and the gate and see whether the tests notice, including the defaults.

For the curious Forgetting has to be checked at the byte level

A delete that removes a row but leaves the text in an old summary, an index, or a file backup has not forgotten anything. The example removes every version and scrubs the copies, then searches the database file bytes to prove it. A real system must do the same across every copy it makes.