# Connect remembers something wrong

Almost always the correction was made at a wider tier than the one that is actually being read. Memory resolves narrowest-first — contact beats endpoint beats channel beats workspace — so a workspace-level edit does nothing while a contact-level row says otherwise. Open the memory viewer on the contact, check every tier, and forget the row at the tier that owns it.

- **Status:** Available
- **Audience:** both
- **In the app:** #/relationships, #/knowledge, #/inbox
- **Last verified:** 2026-09-10
- **Canonical:** https://connectbyjbrh.com/docs/troubleshooting/wrong-memory/

## What it looks like

The symptom is repetition. Connect greets somebody by a name they do not use, describes a service the business stopped offering, quotes an old delivery time, or keeps treating a contact as a prospect after they became a customer. You correct it in a reply or on a call, the next conversation is right, and two days later the same wrong sentence is back.

The tell that separates this from an ordinary mistake is consistency. A model that has simply got something wrong gets it wrong differently each time. A stored fact comes back word for word, in the same shape, across channels — which is exactly what memory is designed to do.

## What it means

Something Connect is *supposed* to remember is being remembered correctly, and it is wrong. Memory holds what the business has told Connect and what Connect has learned, at four tiers resolved narrowest-first: **workspace → channel → endpoint → contact**. An endpoint is one mailbox or one phone number. Everything that applies to a piece of work is assembled from all four, and the narrowest one wins.

That hierarchy is the reason a correction can look like it did nothing. Editing the workspace tier while a contact-tier row contradicts it leaves the contact row in charge, and the contact row is the one being read.

## The likely causes, in the order worth checking

1. **A narrower tier still holds the old value.** The commonest cause by a wide margin, because the memory viewer opens at whichever tier you reached it from and a workspace-level edit feels like the general fix. Check the contact tier first, then endpoint, then channel.
2. **It is not memory at all — it is Knowledge.** A price list, a policy or a service description usually lives as a Knowledge source with facts extracted from it. Forgetting a memory row will never change an answer grounded in a Knowledge fact. The wording is the clue: a grounded answer tends to be a fuller sentence, closer to the source document.
3. **It is on the record, not in memory.** A wrong company name, lifecycle stage or job title is a field on the Person or Company row. Memory does not own those, and editing memory leaves the record untouched.
4. **The artefact predates the correction.** A held draft, a call summary or a relationship story written before you made the change still contains the old fact. The correction is in place; the old text is not retroactive.
5. **The row exists at two tiers.** A fact learned from a call can be written against the contact while an older workspace-level instruction says something similar. Forgetting one leaves the other.
6. **The body was edited but the tag was not.** Directives — a block on a channel, for example — are read from the tag list and nowhere else. Rewriting the body of such a row changes what a person reads and changes nothing about behaviour.
7. **It is the right fact in the wrong workspace.** Rare, and worth one look if you administer more than one: a correction made while signed in to another workspace is correctly invisible here.

> **Note** The first two causes account for most reports. If you are about to escalate after checking only the workspace tier, check the contact tier first — it takes seconds and it is usually the answer.

## What Connect completed

- The correction you made was written and is audited: who changed it, when, and at which tier.
- A forgotten row stops being assembled into future work immediately — there is no cache to wait for.
- The tier list still returns every tier, including the empty ones, so nothing-is-set-here remains a visible answer rather than a silence.
- Any directive tag you removed stops applying to future conversations on that channel.

## What Connect did not complete

- It did not rewrite anything already written. Sent messages, call summaries, relationship stories and drafts generated before the change keep the old fact.
- It did not propagate the correction to Knowledge. A fact extracted from a Knowledge source is corrected in Knowledge, at the source.
- It did not update the Person or Company record. Those are edited on the relationship, not through memory.
- It did not remove the same fact from a different tier. Each tier is edited on its own, deliberately, so that a broad instruction is never deleted by a narrow correction.

## What you can do

1. Open the memory viewer from the contact panel of the person the wrong fact is about — not from the channel screen.
   - Result: You see all four tiers at once, with the tier that owns each row named beside it.
2. Find the row carrying the wrong fact and forget it, or edit it to the correct value.
   - Result: The change is recorded against you and takes effect on the next piece of work, not on work already drafted.
3. Search the other tiers for the same claim before you close the panel.
   - Result: If a second tier repeats it, the narrower one was winning, and the wider one becomes visible the moment you remove it.
4. If nothing in memory matches, check Knowledge for a source or fact that says the same thing.
   - Result: Correcting the source and letting the fact be re-extracted fixes every answer grounded in it, not just this conversation.
5. Regenerate any held draft that still contains the old fact.
   - Result: Regenerating gives the model the corrected memory; editing the draft by hand fixes only that one message.

## What an administrator can do

- Record the correct value as a standing instruction at the widest tier that is true, and delete the narrow rows contradicting it — one true statement in one place beats four corrections.
- Review the Knowledge sources the wrong fact could have come from, and retire a superseded document rather than leaving two sources that disagree.
- Check the decision log for the conversation the fact was learned in. A fact learned from a caller who was mistaken is worth removing at the source as well as at the contact.
- Where a name is involved, confirm the Person record itself is right. Connect refuses to store a form of address as a name, but an incorrect real name entered by a person is stored exactly as given.

## When to escalate

Escalate when the fact returns after you have removed it from every tier and confirmed it is not in Knowledge — that means something is writing it again, and which conversation wrote it is the useful question. Escalate immediately if a fact about one contact appears in work for a different contact, or if you can see a row belonging to another workspace, because that is an isolation question rather than a memory one.

Include the tier you edited, the exact wording that keeps coming back, and one conversation where it appeared after the correction. Those three make the write traceable; a description of the wrong behaviour without them usually does not.

## Questions

### I corrected Connect in the conversation itself. Why did that not stick?

Telling Connect something inside one conversation is not the same as storing it. Some corrections are captured as memory and some are understood only for that exchange. If it matters beyond the conversation, write it in the memory viewer or as a standing instruction, where you can see it and somebody else can find it later.

### Does forgetting a memory row delete the conversation it came from?

No. The messages, the call and the timeline are untouched; only the stored fact is removed. That is deliberate — the record of what a customer actually said should not change because a conclusion drawn from it was wrong.

### How do I tell a memory from a Knowledge fact without guessing?

Open the memory viewer on the contact and search for the claim. If it is not at any of the four tiers, it is not memory. Knowledge facts are listed against the source they were extracted from, which also tells you which document to correct.

## Related

- [Memory in Connect](https://connectbyjbrh.com/docs/memory/)
- [Knowledge in Connect](https://connectbyjbrh.com/docs/knowledge/)
- [Relationships in Connect](https://connectbyjbrh.com/docs/relationships/)
- [Making a correction actually change behaviour](https://connectbyjbrh.com/research/memory-correction-that-sticks/)
- [Structured business memory instead of a longer prompt](https://connectbyjbrh.com/research/structured-business-memory/)
- [Troubleshooting](https://connectbyjbrh.com/docs/troubleshooting/)

## What this page is based on

- Connect source pack §6 — memory, four tiers and `directives()` (`docs-source/sources/GENERAL.md`)
- Connect source pack §10 — name protection on the voice path (`docs-source/sources/PHONE.md`)
- Connect capability registry (`docs-source/facts.py`) — `memory_tiers`, `memory_editing`, `block_directive`, `facts_editor`