# Correcting what Connect knows, end to end

Correcting Connect is three moves, not one: stop the wrong message, write the lesson at the right tier, then prove it on the next piece of work. Fixing the message alone changes nothing durable — rejecting a draft is a decision about one reply. The lesson is the memory row, and the proof is the next reply reading differently.

- **Status:** Available
- **Audience:** both
- **In the app:** #/inbox, #/relationships, #/autonomy-audit
- **Last verified:** 2026-09-10
- **Canonical:** https://connectbyjbrh.com/docs/workflows/memory-correction/

## The stages

1. TRIGGER — a reply, a spoken line or a decision that was wrong, noticed by a person
2. USER / EXTERNAL EVENT — they open the conversation and, beside it, the memory viewer
3. AUTH / WORKSPACE RESOLUTION — the session resolves to one workspace; an Owner session goes direct, a customer's is rewritten by `tenantAdapt`
4. INGEST / REQUEST — the correction is submitted from the viewer, the memory sheet in the grid, or as an instruction to the Connect Assistant
5. CANONICAL RECORD — a `connect_memory` row is written, edited or superseded at one named tier
6. CLASSIFICATION / RESEARCH / REASONING — the next piece of work is triaged and reasoned about as usual; nothing is replayed
7. KNOWLEDGE + MEMORY + RULES — `tiers()` resolves narrowest-first and the corrected row is now in what is read
8. AUTONOMY / APPROVAL — the channel's mode still governs; a correction does not grant permission to send
9. ACTION / PROVIDER — the reply is drafted, or the call is placed, under the corrected context
10. RESULT — the visible behaviour changes, or it does not, which is the diagnostic
11. RELATIONSHIP / TIMELINE / MEMORY — the conversation is recorded against the person like any other
12. AUDIT / USAGE / NEEDS YOU — the decision trail keeps what was decided under which rule, so the old reply stays explainable

## What happens at each stage

| Stage | What you see | What changes | What can fail |
|---|---|---|---|
| Trigger | A reply that says the wrong thing, or a call that went the wrong way | Nothing yet | Noticing late — a pattern read as one-off for weeks |
| Stop the message | Reject or edit the held draft in Needs You | That one message | Assuming this taught Connect anything. It did not |
| Write the lesson | The memory viewer, opened from the surface that implies the tier | One `connect_memory` row | Writing it at too broad or too narrow a scope |
| Resolution | Nothing — this is internal | `tiers()` now returns the corrected row | A narrower row still saying the opposite |
| Autonomy | The channel's mode, unchanged | Nothing | Expecting a correction to lift `ask_before_send` |
| Next action | The next draft or the next call | The reply reads differently | Checking a conversation that was already in flight |
| Audit | The decision log | Nothing about the past is rewritten | Expecting old replies to change retrospectively |

## Doing it

1. Deal with the message in front of you — reject the draft, edit and send, or take the conversation yourself.
   - Result: The customer is served. Nothing durable has changed yet, which is the part that is easy to forget once the immediate problem is gone.
2. Decide what the general lesson is, and at which scope it is true. "Not this customer" is contact; "not on this line" is endpoint; "not ever" is workspace.
   - Result: You now know which screen to open the viewer from, which is how the tier gets chosen correctly.
3. Write one imperative sentence. If the old claim was true and has changed, [supersede](/docs/memory/superseding/) rather than editing.
   - Result: The row is in force from the next piece of work. There is no propagation delay and nothing to publish.
4. Trigger the behaviour again and read the result.
   - Result: A changed reply is the proof. An unchanged one means the tier is wrong, a narrower row disagrees, or the budget cut it — the three causes, in that order of likelihood.

> **Careful** A correction is not a permission. If replies on that channel are held because autonomy is `ask_before_send`, they stay held after the correction — correctly. Changing what Connect knows and changing what it may do are two different screens, on purpose.

## Where corrections fail to stick

**It was written at the wrong tier** — The commonest cause by a distance. A workspace-tier correction for a one-customer problem, or the reverse.
**Something narrower disagrees** — Narrowest wins. A contact row still says the old thing and nothing announces that it is the one governing.
**It did not fit the budget** — On a call, memory is capped at 700 characters and the contact block at 600. A four-sentence correction may not survive the door.
**It was a rejection, not a memory** — Rejecting a draft records a decision about one message. The engine does not immediately redraft the same reply, and it also has not learned anything.

[Connect ignored what I told it](/docs/troubleshooting/memory-not-applied/) works through the same four in diagnostic order, with what to check for each.

## Questions

### How quickly does a correction take effect?

On the next piece of work. There is no rebuild, no cache and no approval step for the memory itself. A conversation already in flight keeps the context it started with — a call renders its brief once — so the correction shows up on the following reply or the following call.

### Do I need to correct the same thing on every channel?

No, if you write it at the right tier. A workspace-tier or contact-tier correction is read on email, WhatsApp and voice alike, because the hierarchy is shared. Only a channel or endpoint correction is deliberately limited to where you put it.

### Will the old reply be corrected too?

No. A sent message has left through the send boundary with a provider acknowledgement behind it. The decision trail keeps what was decided under which rule, so it stays explainable — that is the point of not rewriting it.

## Related

- [How a memory is created](https://connectbyjbrh.com/docs/memory/creating-memory/)
- [Editing a memory](https://connectbyjbrh.com/docs/memory/editing/)
- [Superseding a memory](https://connectbyjbrh.com/docs/memory/superseding/)
- [Connect ignored what I told it](https://connectbyjbrh.com/docs/troubleshooting/memory-not-applied/)
- [What Connect may do](https://connectbyjbrh.com/docs/autonomy/)
- [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 §6 — tiers() and narrowest-first resolution
- docs-source/sources/GENERAL.md §5 — autonomy modes and the audit trail
- docs-source/sources/PHONE.md §7 — the memory and contact-block budgets
- docs-source/sources/GENERAL.md §1 — tenantAdapt and the two audiences