The repair work a stored fact creates and a retrieval hit does not

A wrong record in a memory store and a wrong passage pulled into a single answer look like the same failure from the outside. Both produce one confident, incorrect reply, and both are the system saying something untrue on the strength of something it read.

They differ in what happens afterwards, and the difference is not a matter of degree. A retrieval result exists for the duration of one request. A wrong one — a chunk of an outdated contract PDF pulled into one answer — produces a bad answer and then ceases to exist, and nobody has to find it, edit it, tell anyone about it, or delete it from a backup. A memory record is a thing you created and now own.

This chapter follows one such record from the sentence that produced it to the person who eventually had to fix it, counting the work at each stop. Between the turn that produced the record and the meeting where somebody decided who was going to fix it, eleven people-hours and a €340 service credit went by, none of which appears in any dashboard as a cost of the memory system. The interesting part is not that the record was wrong. It is the shape of the trail it left, because every stop on that trail is work that exists only because the claim was persisted.

One record, ten stops#

The record was mem_9f3a21, and it said "Contracted SLA is 99.5% monthly uptime." The customer, an industrial telemetry company on Arbor's enterprise plan, is contracted at 99.9%.

[
{"t":"2026-02-03T14:22:31Z","stop":"proposal","gate":"model_v3","turn":14,
 "quote":"we're only on the 99.5 tier aren't we, so a 20 minute blip is fine?",
 "statement":"Contracted SLA is 99.5% monthly uptime.","confidence":0.71},
{"t":"2026-02-03T14:22:31Z","stop":"admitted","checks":["durable:pass","user_stated:pass",
 "scope:global","contradiction:none","expiry:null"],"human_review":false},
{"t":"2026-02-03T14:22:33Z","stop":"stored","row":"mem_9f3a21","embedding":"emb_v4",
 "replicas":["pg_primary","pg_replica_eu","vec_index","analytics.memories"],
 "profile_blob":"rebuilt 02-04T02:10Z","backups":"7 daily + 4 weekly snapshots"},
{"t":"2026-02-24T09:51:08Z","stop":"retrieved","session":"ses_f41c","rank":2,
 "cosine":0.83,"in_prompt":true},
{"t":"2026-02-24T09:51:12Z","stop":"answered","text":"Your contracted SLA is 99.5%, so February's 22 minutes of downtime is within the allowance and no credit applies."},
{"t":"2026-02-26T11:04:00Z","stop":"disputed","channel":"csm_email"},
{"t":"2026-02-26T15:40:00Z","stop":"triage","who":"support_eng","minutes":150,
 "method":"read log -> record ids in prompt for ses_f41c"},
{"t":"2026-02-27T10:12:00Z","stop":"corrected","action":"supersede",
 "new":"mem_a4d7c2","old_state":"superseded","minutes":35},
{"t":"2026-02-27T10:12:00Z","stop":"derived_cleanup","targets":
 ["profile_blob","analytics.memories","2 second-generation records","weekly digest email"],
 "minutes":95},
{"t":"2026-03-02T16:00:00Z","stop":"blast_radius_review","responses_touched":61,
 "customers_affected":1,"credit_eur":340,"minutes":240}
]

Walking the trail in order makes the accounting concrete. The proposal cost one model call, which is the only stop with a price you can look up. Note what the quote was: a question, hedged, in which the customer was guessing at their own tier. Approval was automatic, and its cost is not the compute but the fact that no human ever saw a claim that was about to be treated as contractual truth for three weeks.

Storage is the stop where the record stops being one thing. The replicas field lists four live locations — a primary database, a European read replica, a vector index and an analytics table — and the record is also baked into a nightly profile blob and captured in seven daily plus four weekly snapshots, which is eleven backups. Those copies have different lifecycles: the replica follows the primary automatically, the vector index follows it on a rebuild schedule, the analytics table follows it whenever the pipeline next runs, and the snapshots never follow it at all. From this moment the claim is not a row you can point at; it is a set of copies that will be corrected at different times or not at all.

Then nothing happened for twenty-one days. Dormancy is worth listing as a stop precisely because it is where the cost accrues invisibly: the record was in every retrieval slate for every SLA-adjacent question during that period, and it simply did not win any of them until 24 February. There are two intervals in this trace and they are easy to conflate. The dormant interval is the three weeks from writing to the first retrieval that mattered. The exposure interval is the whole span from writing to correction, which the table below records as 24 days. A memory system's risk is not concentrated at write time or read time; it is spread over the second of those, and that interval has no natural end.

Dormancy also explains why a record's danger cannot be assessed at write time. Whether a record wins a retrieval slate depends on what else is in the slate, and what else is in the slate depends on every other record written for that user since. A record that was harmless in February because three better matches always outranked it becomes dangerous in April when two of those three are deleted, and nothing about the record changed. The write decision is therefore made without access to the quantity that determines the outcome.

Triage is the stop that surprises teams. Going from "the assistant said something wrong on 24 February" to "record mem_9f3a21 caused it" took two and a half hours, and it was only possible because Arbor logs which record ids entered the prompt for each response. Without that log, the investigation has no bounded shape: it is a person re-running similar queries and hoping the same records come back, and since the retrieval depends on the exact wording, each attempt samples a different slate and none of them proves anything about the response that was complained about. It does not converge. The usual outcome is that nobody finds the record and the ticket is closed as a model hallucination. That misdiagnosis is common enough to be worth naming: a wrong memory looks exactly like a confabulation from the outside, and the wrong fix — prompt hardening, a stronger model, a warning about not stating facts it cannot verify — gets applied to a system that was doing what it was told.

Correction itself was the cheapest stop at 35 minutes. Everything downstream of it was not, and the reason is the fan-out from the storage stop. The profile blob had baked the claim into a paragraph of prose and needed regenerating; the analytics copy had been queried into a dashboard; two later records had been extracted from conversations in which the assistant had asserted 99.5% and the customer had not contradicted it, so those had to be found and removed as well; and a weekly digest email had already gone out quoting the figure. Ninety-five minutes went into chasing copies of a sentence, and the two second-generation records are the part that would have recurred: they were produced by the system reading its own output back as evidence, so they would have been regenerated indefinitely if nobody had traced them.

The last stop is the one product asks about, and it is the blast radius review, meaning the count of outputs the record had already shaped before anyone knew it was wrong. Sixty-one responses had touched the record, and someone had to read enough of them to decide whether any other commitment had been made on the strength of it. That was four hours, and it ended with a €340 credit issued to close the dispute.

Add the minutes up and the total is the identity this chapter is built on. A hundred and fifty for triage, thirty-five for the correction, ninety-five for derived cleanup and two hundred and forty for the blast radius review comes to a little over eight and a half hours, which the trail records as 8.6 hours of engineering and support time. On top of that sit roughly two and a half hours from the customer success manager, the CSM who owns the commercial relationship with that account, giving eleven people-hours for one row.

That sum licenses a specific claim: the end-to-end price of one wrong record, in the unit a staffing conversation happens in, for a system with this instrumentation. The condition at the end is the residual and it is a large one. Triage cost two and a half hours because a read log existed; without one, the triage term is not larger by some factor, it is unbounded, because the search does not converge. So eleven hours is a lower bound conditional on machinery a lot of teams have not built, and a team without it should not read this trail as an estimate of their own costs.

The same error at read time costs one bad answer#

Set the persisted record beside the equivalent read-time mistake — a retrieval that pulls the wrong contract clause into a single answer — and the difference is not a matter of degree.

The asymmetry in every row of that table has one cause, which is worth stating once rather than reading nine times: a retrieval result has no independent existence. It is derived from a source of record on every request, so correcting the source corrects every future answer at once, and there is no copy to find because the copy was never kept. A memory record is a new source of truth that you have created, and once it exists it must be maintained like any other source of truth, with all the invalidation, provenance and deletion machinery that implies — machinery most teams do not budget for, because the write itself was one line of code.

Read down the two columns as gaps rather than as descriptions and one row is unlike the others. On lifetime, blast radius, correction and deletion the gap is between "nothing" and "something", which is the same gap restated in four units. On second-generation risk the gap is between "nothing" and "a loop", which is a different kind of difference: a wrong retrieval result cannot cause another wrong retrieval result, whereas a wrong record can cause a later extraction pass to write a second record asserting the same thing, and that second record can do it again. The only row where the two columns are close is freshness, and they are close there for opposite reasons — a retrieval result is exactly as fresh as its source, and a memory record is exactly as fresh as the day it was written, so they coincide only on the day of writing.

One caveat keeps the comparison honest, because the left-hand column is cheap partly by borrowing. A wrong retrieval result is cheap to recover from because the corpus behind it is somebody else's problem — the contract PDF has an owner, a review process and a publication date, and that machinery is paid for whether or not an agent reads it. Retrieval borrows a maintained source; memory creates an unmaintained one. If the source document is itself stale, retrieval inherits the staleness and the cost lands on whoever owns the document, which is still a better position than owning a private copy nobody has ever audited.

The SLA case has a second sting. The contracted SLA lives in Arbor's contracts service, where it is authoritative, current, and one query away. A read-time lookup on that field would have been right on 24 February, right after the customer renegotiated in April, and right forever, without a record, an expiry, a triage or a credit. That whole class of fact is the subject of chapter 8; here it is enough to notice that the eleven hours were spent maintaining a copy of something nobody needed a copy of.

Answering "remember everything the user tells it"#

The argument that does not work is that storage is expensive. Arbor's entire memory store, half a million records with embeddings, costs under $30 a month, and everyone in the room knows it, so leading with cost concedes the argument in the first sentence and invites the reply that storage is cheap and getting cheaper.

It is worth seeing why that reply is so effective, because the same shape recurs. The storage bill is a quantity that stays almost constant as the store grows, since bytes are the cheapest thing in the system. The quantity that actually varies is human hours, and human hours are driven by the number of records that are retrieved often — a record nobody retrieves generates no dispute, no triage and no blast radius review. So the metric being offered as a defence is one that barely moves while the dangerous property moves a great deal, and anyone reasoning from the storage bill will conclude that a store of five million records is fifty times a store of a hundred thousand in cost when it may be five hundred times.

The argument that works is the trail above. Every fact admitted to the store creates four durable obligations that a read-time retrieval does not: invalidation, because the fact has to be kept true or expired; provenance, because a fact that shapes answers must be attributable when someone disputes it; repair, because a wrong fact needs a path from a bad answer back to the record and out through every derived copy; and deletion, because the user can demand its removal from every one of those copies. Those obligations are paid in human hours, and the hours scale with the number of records that are retrieved often, not with the number that exist. At a 31% write rate this is not a policy anyone can staff.

The four are worth keeping separate rather than collapsing into "maintenance", because each has a different trigger and a different owner, and a team can have three of them and still be exposed. Invalidation is triggered by the world changing and is owned by whoever decides expiry policy. Provenance is triggered by a dispute and is owned by whatever wrote the record, which means it has to be paid for at write time or not at all. Repair is triggered by a complaint and needs a read log that somebody decided to keep months earlier. Deletion is triggered by a request with a legal clock on it and reaches every derived copy, which is the only one of the four whose cost is set by systems outside the memory team entirely. Missing any single one converts a recoverable wrong record into a permanent one, by a different route each time.

That framing turns "remember everything" into a proposal with a price attached rather than a preference to be argued about, and it lets you say what you are willing to remember instead of only what you are not. A scoped list — durable preferences that change presentation, project-scoped facts with no system of record, corrections the user has stated in general terms — is a proposal that can be evaluated. "Everything" cannot, because it includes the SLA, the region, the seat count and the refund authorisation, each of which has an owner elsewhere.

Being specific about what would change your mind is the part that makes the conversation productive rather than obstructive, and there are three things that would, one for each of the terms in the price. First, an evaluation on held-out tasks showing that task success with the write policy live beats a re-retrieval baseline by a margin worth having; that answers whether the benefit exists at all, it is the subject of the final chapter, and it is the piece of evidence that settles the question. Second, retrieval-weighted precision above roughly 0.9 sustained over several weeks of sampling, which bounds how many wrong records the policy generates, since the whole repair burden scales with the wrong-record rate. Third, a correction path with a measured cost per bad record — a read log, a supersession action, a derived-copy sweep — small enough that the store can be kept clean by the people you actually have, which bounds the price of each one. Given those three, the argument for writing more is straightforward, and the ask stops being "remember everything" and becomes "remember these classes of thing, at this precision, with this repair budget".

The trail is worth keeping in mind as the shape of what a write commits you to, rather than as a set of figures. One sentence in one conversation became a row, then four copies and eleven snapshots, then a dormant liability, then a disputed answer, then a search that only converged because somebody had built a log, then a correction, then a hunt for derived copies, then a review of everything the record had already shaped. The write itself was the cheapest step by several orders of magnitude, which is exactly why nothing about the write path signals what it is committing to.

Two of the three things that would change your mind depend on machinery that has been assumed rather than described. The trail above spent 150 minutes getting from a complaint to a record id and then chose supersession over editing and deletion without saying why, and that choice determines what history survives and what the user sees. Building the path backwards from a wrong answer to the record that caused it, and choosing among the repair actions, is the next chapter.