Answers
Most AI memory is write-only — context goes in, retrieval comes out, and nothing is ever corrected. What closes that loop?
A correction path that belongs to the record rather than sitting beside it. When something stored here stops being true, three things happen in order and all three can be inspected afterwards. Whoever opened the source and saw the divergence writes down what the source actually says, so nobody has to go and look again. The correction is then proposed as a replacement that names the memory it contradicts — not a newer row sitting next to the old one. And a person accepts or refuses it; on acceptance the replaced statement is retired in the same act, with the reason and the author on its archived line. Until that acceptance, the earlier statement is still what gets served. The delay is deliberate: a record where an assistant retires the team's decisions on its own judgement is a log of what the last model believed.
Last updated September 21, 2026
Write-only is not a storage limitation; it is a missing act
The reason most setups never correct anything is not that editing is hard — it is that nothing in them defines what a correction IS. A store that accepts writes and returns similar text has no notion of one statement replacing another: the corrected version is simply a more recent row, and both come back when the topic comes up. Three things have to exist before correction is even expressible. Each statement needs an author, or there is nobody whose claim is being revised. The new statement needs an explicit pointer to the one it replaces, or correction is indistinguishable from duplication. And someone other than the writer has to accept it, or the assistant that wrote the wrong thing is also the one ruling that it was wrong. Better retrieval does not produce any of the three.
Correction starts where the work already is, not in a review sweep
The moment that catches a divergence is not a scheduled audit of the collection. Measured across a month, those do not happen, and a mechanism that depends on someone running them produces nothing. It is the ordinary moment when work opens the file, the query, the ticket or the page that a memory points at — for some unrelated reason — and what is on the screen does not match what is in the record. That is when it gets written down: this one matches, this source is gone, this source says something different. The last of those carries a note of what the source actually says, and it is what turns into a proposed replacement. None of it is an errand; it is bookkeeping for something that was already seen.
What ends on its own, and what has to be corrected
Two failures live under "the memory went stale", and one mechanism cannot cover both. Every entry is written with the condition that ends it — a date, a named trigger, a piece of work that would make it obsolete — and work that makes that condition true retires the entry in the same act, with the reason on it. That handles the case someone anticipated. Correction handles the case nobody did: the condition was never met, or it was met and nobody noticed, and the statement quietly stopped matching the world. Expecting expiry to catch the second is how a collection fills with entries that are technically live and factually wrong. They are separate mechanisms on purpose, and a page promising that one does both would be selling the failure it is describing.
What it looks like in practice
A project note says the welcome email goes out twenty-four hours after signup. It was written the day the delay was decided, it names the condition that would end it — the delay changes — and every assistant drafting anything about onboarding reads it first. Eight weeks later the delay moves to two hours. It moves inside an unrelated piece of work, by someone who never read the note, and the person who wrote the note is not in that conversation. The condition that was supposed to end the entry did come true; declaring it would have required somebody in that room to remember the entry exists. What catches it is not a sweep. It is the next session that opens the scheduler to answer a different question, sees two hours where the entry says twenty-four, and records the divergence right there, with what the source says. From that point the entry arrives marked as contradicted instead of arriving clean, the correction is a proposal naming the entry it replaces, and a person accepts it. The window in which the record was wrong is real and it is not zero. What is not real is the version where nobody ever finds out.
Questions people ask about this
- Who corrects a memory — the assistant that noticed, or a person?
- The assistant proposes and a person decides. The proposal has to name the memory it replaces and say what in it is contradicted, which is what stops "related topic" from being filed as "same point". Until someone accepts it, the earlier statement is still served. That is the slow part, and it is the part worth keeping: a team needs to be able to tell a decision they made from a sentence a model wrote confidently, and the only thing separating the two is that someone said yes to one of them.
- So the wrong version is served until somebody gets around to it?
- Yes, and that window is the honest cost of keeping a person in the loop. Two things keep it narrow rather than pretending it is zero. The divergence is recorded the instant it is seen, so the memory arrives marked as contradicted rather than arriving as though nothing had happened. And the proposal lands in the one place where decisions wait, not in a notification that scrolls away. What no record can do is decide faster than the team decides — and one that tried would be making the write-only mistake from the other end.
- We edit our context file when something changes. Isn't that already correction?
- It is, for the sentence you are editing, and it drops the part that makes a correction auditable later: what the line used to say, who changed it, and why. An edit leaves a diff if the file lives in a repository and nothing at all if it lives in a shared drive. What is kept here is the replaced statement itself, archived, with the replacement pointing back at it — so "when did we stop saying that, and on whose call" still has an answer six months on. That question comes up more often than people expect, usually the first time a decision is reversed twice.
Where this is verifiable
Product documentation on this site (How it works, Install), the answers on out-of-date memory being read as current and on memory without a write policy, and the verification, supersede, sanction and expiry rules in the sanctioned product spec. Everything described here is behaviour the tools apply today, not roadmap.
https://www.arroway.app/en/answers/memory-that-only-writes-never-corrects