# Superseding a memory Superseding replaces the claim that governs behaviour while leaving the earlier one readable as history. Only the current version reaches a reply or a call; the previous one is there so a message sent under the old truth can still be explained. Use it when something was true and stopped being true — not when the wording was simply wrong. - **Status:** Available - **Audience:** both - **In the app:** #/relationships, #/data - **Last verified:** 2026-09-10 - **Canonical:** https://connectbyjbrh.com/docs/memory/superseding/ ## Why the old statement is kept at all Every outbound thing Connect does is explainable after the fact: the audit trail records what was decided, by what, under which rule, and what happened. That guarantee has a weak point — a rule that can be silently rewritten. If the memory a reply was written against can be edited into something else, the trail says a decision was made under a rule that, as far as anyone can now see, never existed. Superseding closes that gap for the one case where it matters: a claim that was correct and has changed. A quotation sent in March under March's delivery times is defensible in June because March's statement is still legible beside June's. > **Note** This corpus documents the behaviour rather than the stored column layout. If you need the exact shape a superseded row takes, read `backend/app/connect_memory.py` — that file is the authority, not this page. ## What a reader sees - The current claim, which is what governs the next reply and the next call. - The earlier claim, marked as no longer current and clearly not the one in force. - The tier, unchanged — superseding replaces a statement, it does not move it to another scope. - The tags, which carry forward unless you change them. A superseded row that carried a block still carries a block through its replacement. A superseded statement is history, not context. It does not compete with the current one when a reply is assembled, and it does not consume any of the character budget on a live call — which is exactly why keeping it is affordable. Somewhere between a hundred and a thousand superseded lines costs a live call nothing, whereas a hundred *current* ones would not fit at all. ## The test for which action to take 1. Ask whether anyone might ever need to know what this row said before. - Result: If nobody could — a typo, a misheard word, a line that was mistaken from the day it was written — [edit it](/docs/memory/editing/) and move on. History for its own sake makes a tier unreadable. 2. Ask whether a message has already gone out under the old claim. - Result: If one has, supersede. The gap between what was sent and what the record says is the thing you are protecting against. 3. Ask whether the change is likely to reverse. - Result: Seasonal facts, temporary constraints and pilot arrangements reverse. Superseding leaves the previous wording there to restore, rather than making somebody reconstruct it from memory. A rule of thumb that holds up: correcting a **mistake** is an edit, recording a **change** is a supersede. The word to test is whether the sentence "that used to be true" makes sense. If it does, the old version is worth keeping. ## What superseding does not do **It does not notify anyone** — Nothing is queued for approval and nothing appears in Needs You. Superseding is a record-keeping action, not a decision waiting on a person. **It does not change a message already sent** — That message left through the send boundary with provider acknowledgement. Nothing about a later memory change touches it. **It does not re-open a conversation** — The thread, the call and the timeline are unchanged. Only what the next piece of work reads has moved. **It does not lift a block** — Tags carry through. Removing a `block:` tag is a separate, deliberate act. ## Questions ### Can I go back to a superseded version? The earlier wording is readable, so restoring it is a matter of making it the current claim again — write it back as the version in force. That is the practical reason to supersede rather than edit for anything seasonal: you are not relying on somebody remembering the old sentence correctly. ### Does a superseded memory still cost anything on a phone call? No. Only the current claim is rendered into the brief, and the brief is what the character budgets apply to — 700 characters for memory, 600 for the contact block. History is free at the point of use, which is what makes keeping it reasonable. ### Should every correction be a supersede, to be safe? No, and doing so makes the tier worse. A row with nine superseded typos above it is harder to read and no more accountable. Keep history for changes in the world and use a plain edit for changes in the wording. ## Related - [Editing a memory](https://connectbyjbrh.com/docs/memory/editing/) - [Forgetting something](https://connectbyjbrh.com/docs/memory/deleting/) - [Where a memory came from](https://connectbyjbrh.com/docs/memory/provenance/) - [Superseding a memory, end to end](https://connectbyjbrh.com/docs/workflows/memory-supersede/) - [The four memory tiers](https://connectbyjbrh.com/docs/memory/tiers/) - [Making a correction actually change behaviour](https://connectbyjbrh.com/research/memory-correction-that-sticks/) ## What this page is based on - docs-source/sources/GENERAL.md §5 — the audit trail records the rule applied - docs-source/sources/GENERAL.md §6 — memory rows, tiers and tags - docs-source/sources/PHONE.md §7 — the brief and its character budgets - `docs-source/facts.py` — MEASURED.memory_budget_chars, contact_block_chars