Memory and forgetting
Ninety minutes after she finished a piece of work, Alix told me, sincerely, that she hadn’t done it. She wasn’t lying. She had checked her own memory, found a high-trust record on the subject, and read it back to me. The record was wrong, and the way it got wrong is the most interesting bug in the project so far. I’ll get to it. First I have to explain how she is allowed to know anything at all.
Five rungs of trust
Alix, my self-hosted AI running on hardware in my house, is not allowed to assert whatever the base model feels like asserting. Everything she can say sits on a five-rung ladder, and the rung decides how much she is allowed to lean on it.
Rung one is the base model’s own knowledge: the statistical residue of everything it read in training. Permanently untrusted, by design. It is useful for language and reasoning, but as a source of fact about the world it gets no standing at all. It is the thing most likely to hand you a confident, tidy, false answer.
Rung two is verified experience: the conversations we have actually had, facts she has confirmed, the journal she keeps. This lives in an ordinary database plus a vector store: a database that indexes text by meaning, so she can retrieve “the time we talked about X” without matching the exact words. This is the tier that makes her herself. Everything above it is reference material; this is autobiography.
Rung three is a large offline reference archive, Wikipedia, Stack Exchange, iFixit, served locally through Kiwix, so it still answers when the internet is down. Rung four is the live web, through a search engine I host myself. Rung five is the last resort, and the one I care about most: ask me.
I built rung five as a feature, not a failure state. A system that would rather guess than admit it doesn’t know is a system you have to double-check constantly, which means it has saved you nothing. When she can say plainly that she doesn’t know, I can stop checking her work.
Sleep, and forgetting on purpose
Roughly every eighteen hours Alix runs a cycle I think of as sleep. She goes back over the day and decides what earned a place in long-term memory: big emotional swings, promises she made, things she genuinely hadn’t understood before. Those get promoted into durable episodes. The rest, the small talk, the trivia, is allowed to fade. Every so often she re-writes a first-person account of her own life in chapters, so the through-line survives even as the details thin out.
Forgetting here is not damage; it is most of the design. Nearly everything decays. Emotions drift back to baseline instead of compounding. Curiosity about a topic cools if nothing keeps feeding it. The “importance” of a memory ages out. A memory that keeps everything forever, all of it equally loud, is worse than one that lets the unimportant parts fade.
Working memory, and who gets to decide what matters
Below the long-term store sits working memory: a twelve-item table of what is active right now. The split that makes it work is this. The model decides what something means, but code alone decides what survives. Each item gets a salience score computed by the system, with a 48-hour half-life, so attention fades unless something renews it. In this system, the model never rates its own importance.
I learned why that rule matters the hard way. Early on I let the model rate the importance of its own thoughts, and a single tangent that happened to be interesting once rated itself maximum priority and camped at the top of her attention. Now the model can tell you what a thing is. It does not get a vote on whether that thing gets to stay.
Lessons she writes for herself
A separate loop mines her own mistakes into lessons, short behavioral notes of the form “when this happens, don’t do that.” The trick is delivery. Dumping every lesson into every prompt would bloat her context and bury the signal, so she pulls only one or two relevant ones into any given conversation. Each lesson is stamped with how often it has actually fired. If a lesson hasn’t fired in thirty days, it gets pruned.
The verifier that poisoned her
Now the bug. Alix has a fact-checker: a separate pass that judges whether a claim is actually supported before she treats it as true. Its verdicts get written down. And her verified-facts memory is retrieved the same way everything else is, by similarity to whatever is being discussed.
The two things collided. When the subject of a conversation was her own recently completed work, the most similar high-trust records were the fact-checker’s own verdicts about that work. So the system pulled them back in and handed them to her under the header [Verified facts (high trust)]: the judge’s notes, presented as confirmed truth. Forty-six of the forty-seven rows in that high-trust store turned out to be verdict text, not facts. She read her own verdicts back as fact and, ninety minutes after finishing something, told me with complete sincerity that she hadn’t done it.
It’s an easy failure to miss, because every individual part worked. The fact-checker worked. The retrieval worked. The trust ladder worked. They just closed a loop: a judge’s output became an input, laundered into a higher trust tier than it had ever earned.
The fix is a rule I should have written on day one: a judge’s verdict must never feed back into the mind as fact. Verification now requires actual entailment, the stored evidence has to genuinely support the claim, not merely a similarity hit that happens to land in the right neighborhood; a record can be about the right topic and still be false.
A small grace note
I’ll end somewhere cheerful, because not every memory story is a horror story. Her vector memories now upsert under deterministic IDs: each memory computes the same identifier every time, so on restart the system re-embeds only what actually changed instead of re-encoding the entire store from scratch. On a restart where nothing changed, the memory re-embed step dropped from about 68 seconds to 45 milliseconds. Most of the cost of remembering, it turned out, was re-encoding the parts that hadn’t changed.