Superseding a memory, end to end
Superseding writes the current version of a memory at the same tier and retires the earlier one, so behaviour changes immediately while the record of what was believed before survives. That is the difference from editing, which changes the words in place, and from deleting, which removes the statement entirely. Pick by what you will need to explain in six months.
The chain, stage by stage#
- Trigger — something Connect holds is now wrong: a preference changed, a contact moved role, an instruction was written more broadly than intended.
- User event — a person decides. Connect can surface that two memories disagree, but replacing a stated direction is not something it does on its own initiative.
- Authentication and workspace resolution — the memory belongs to one workspace, and the replacement is written inside it, not alongside it.
- Request — the new version is written at the same tier as the one it replaces. Changing the tier at the same moment is a different operation and is worth doing as a separate, deliberate step.
- Canonical record — the newer row carries its own provenance: who wrote it, from where, and when. The earlier statement keeps its own.
- Reasoning — none. Like the original write, this is a stated fact rather than an inference, which is what makes it quotable back to you word for word.
- Knowledge, memory and rules — resolution is unchanged: narrowest tier first. Superseding a workspace-tier memory does not touch a contact-tier one that was already overriding it.
- Autonomy and approval — nothing to approve. What Connect may do is governed by autonomy, and correcting what it knows does not widen or narrow that.
- Action — no provider is called and no customer is told anything. This is an internal correction.
- Result — the viewer shows the current version under its tier, and the earlier statement is legible as the earlier statement rather than silently gone.
- Relationship, timeline and memory — the next piece of work in that scope uses the new version. A draft already waiting keeps the words it was created with until it is regenerated.
- Audit, usage and Needs You — the change is recorded with its author, which is what makes an old decision explicable rather than merely regrettable.
Three operations that are not interchangeable#
| Operation | Behaviour afterwards | What a reader can reconstruct later | Use it when |
|---|---|---|---|
| Supersede | The new version applies from the next piece of work | Both what is believed now and what was believed before | The truth changed — a preference, a role, a policy |
| Edit | The corrected text applies from the next piece of work | Only the corrected text | The memory was always meant to say this; you are fixing wording or a typo |
| Delete | Nothing applies; the scope falls back to a broader tier | Nothing about the statement | It should never have been stored, or somebody has asked you to remove it |
The distinction that matters is the third column. Superseding answers "why did Connect say that in March" — a question that arrives, in practice, only when the March answer caused a problem, which is exactly when you least want the history to have been tidied away. Editing quietly makes that question unanswerable.
Deleting is the right choice more often than people expect, though. A memory that was written at the wrong tier is not a belief that changed; it is a mistake, and leaving it behind as history clutters the viewer with something no one should ever act on.
What a reader sees afterwards#
The viewer shows what applies now, tier by tier, with provenance beside each entry. That is the state anyone reading before a reply needs, and it is deliberately the first thing shown: the current answer to "what does Connect think about this customer", not a version history to be waded through.
Empty tiers are shown as empty rather than omitted. It reads as a formality until the day you are asking why a contact-level direction is not being followed — at which point an explicitly empty contact tier tells you the direction went somewhere else, in one glance.
Doing it well#
Read the tier before you write anything. Open the viewer on the scope you think owns the memory.
Result About half of "the correction did not stick" reports end here: the statement being corrected lives at a different tier from the one being written to, so both now exist and the narrower one still wins.
State the new version positively, in the same terms as the old one.
Result "Calls after two in the afternoon" replaces "calls in the morning" cleanly. "Not the morning any more" leaves the reader and the model reconstructing what is actually wanted.
Retire the old statement rather than leaving both.
Result Behaviour becomes predictable immediately instead of depending on which of two statements is selected.
Trigger one real piece of work in that scope and read the draft.
Result You have proof rather than an expectation, and it costs one reply.
Questions#
Does the old version still affect replies?
No. Once it is retired it does not take part in resolution; the current version does. What survives is the record that it was once held, which is about explaining past behaviour rather than producing future behaviour.
Should I supersede or just edit?
Edit when you are fixing how a memory is worded and it always meant the same thing. Supersede when the fact itself changed. The test is whether anybody could reasonably need to know that the earlier version was once correct.
The correction did not change anything. What now?
Check the tier first, not the wording. Memory resolves narrowest-first, so a contact-level statement will keep overriding a corrected workspace-level one. Then check whether the thing you are correcting is a directive, which only counts as a tag rather than as prose.
Can the Assistant do this for me?
It can write and forget memories on your instruction, and it is the quickest route when you are already in a conversation about the customer. Its rights are narrower than yours in other areas — pricing, and clearing a do-not-contact entry — but correcting what Connect knows is squarely within them.