Deleting history the summary already absorbed

A user removes a conversation. The turns are gone from the store. On the next message the character refers to something that was only ever in those turns, because the summary that absorbed them is still being carried and the fact store built from them is still being included.

Nothing malfunctioned. Deletion removed the original and left every derivative in place, and on a persona product the derivatives are what the character is actually made of.

Continuity state is derived state

Everything you built to make the character remember is a copy of the conversation in a different shape. The running summary is a compression of it. The fact store is an extraction from it. Any cached assembled state is a snapshot of it. Responses already produced are conditioned on it and are themselves part of the history.

Deleting a source turn therefore has no effect on the character’s behaviour unless you also invalidate everything computed from it, and most systems have no record of what was computed from what. A summary is a text field with no lineage. A stored fact usually has no pointer to the turn that produced it. The dependency graph exists in the architecture and not in the data, so the deletion cannot be propagated.

The second-order case is the one that surprises people. Suppose a fact is deleted correctly and cleanly. Later, the summary is rebuilt from history that contains responses written while the fact was present. The fact re-enters the summary from the model’s own past output, and it will not be traceable to any user statement at all. Derived state can regenerate what you removed, which means one-time deletion is not sufficient — the removal has to hold across every subsequent rebuild.

Four ways to handle it, in ascending order of honesty

Delete the originals only. The character carries on knowing everything until the next rebuild, and after the rebuild it knows whatever survived in derivative form. Trivial to implement and the behaviour is indefensible if anyone looks.

Delete the originals and drop the derived state. Clear the summary and the facts along with the turns. The character genuinely stops knowing, immediately. What it costs is everything else in that state: dropping a summary to remove one exchange takes the whole conversation’s continuity with it, so a narrow deletion request produces a total memory loss. Users notice this far more than they notice the thing they deleted.

Delete and rebuild from what survives. Remove the turns, then reconstruct the summary and facts from the remaining originals. Correct, and it requires retaining originals and paying a full rebuild at delete time. It is also the only option where a narrow deletion stays narrow, which makes the retention it depends on worth the storage.

Track lineage and invalidate selectively. Keep, per stored fact, which turns support it, and per summary, which turn range it covers. Then a deletion knows exactly what to remove or recompute. Best behaviour, highest schema cost, and the cost is paid on every write rather than at delete time — which is the trade, because writes are constant and deletions are rare.

Whatever you choose, the seam between what the character knows and what your records say it should know is where this surfaces, and it surfaces as a bug report about the character remembering something impossible.

The turn

THE TURN — deletion

  · Delete the source turns
                    → simple, and changes nothing about what
                      the character knows.

  · Derived state is independent
                    → the summary, the facts and every past
                      response still carry the deleted content.

  · Drop all derived state instead
                    → deletion is genuinely effective, and one
                      narrow removal wipes the whole
                      relationship's continuity.

  · Rebuild from surviving originals
                    → keeps deletion narrow, needs originals
                      retained and a full rebuild at delete
                      time.

  · Lineage per fact and per summary
                    → PAID EVERY TURN — you pay provenance on
                      every write, forever, so that rare
                      deletions are correct.

  · Deletion is not one-time
                    → a later rebuild can re-derive the removed
                      content from responses written under it.

Detection

The direct test is a plant-and-delete probe, and it should run continuously rather than once. Insert a distinctive fact into a synthetic conversation, delete the turn that carried it, then ask about it — before the next rebuild, after the next rebuild, and after a rebuild that follows several more turns. Three different answers are normal on a system without lineage, and the third is where re-derivation shows up.

Instrument what serves each response. If you log which summary version and which fact identifiers were included in each turn’s input, a report of the character knowing something deleted becomes a lookup instead of an investigation. Without that, the same report is unfalsifiable.

Count derived artifacts per conversation and their ages. A conversation whose summary predates its last deletion is a conversation in an inconsistent state, and that comparison is a single query. The number of such conversations is a real operational metric and it is usually not zero.

Sample your fact store for orphans — facts whose supporting turns no longer exist. On a lineage-tracking system that count should be zero by construction; on any other system it is the size of the problem, and it is the same audit that catches facts that were never supported by a turn at all.

What this costs and what it doesn’t fix

Lineage is provenance, and provenance is paid on every write to make a rare operation correct. That is an unusual shape for a cost and it is why it gets deferred: the payoff is invisible until the first deletion that matters, and by then the historical data has no lineage to add. Rebuilding from originals moves the cost to delete time instead, at the price of retaining originals — the cheaper choice for most products, and it constrains what else you can do with storage.

None of it makes deletion instantaneous in behaviour. There is a window between a deletion and the next rebuild in which the character still knows, unless you invalidate the carried state immediately and accept the continuity loss that comes with it. That is the actual tradeoff — deletion latency against relationship continuity — and it is worth deciding deliberately rather than inheriting from whatever your rebuild cadence happens to be.