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.
The stages#
- TRIGGER — a reply, a spoken line or a decision that was wrong, noticed by a person
- USER / EXTERNAL EVENT — they open the conversation and, beside it, the memory viewer
- AUTH / WORKSPACE RESOLUTION — the session resolves to one workspace; an Owner session goes direct, a customer's is rewritten by
tenantAdapt - INGEST / REQUEST — the correction is submitted from the viewer, the memory sheet in the grid, or as an instruction to the Connect Assistant
- CANONICAL RECORD — a
connect_memoryrow is written, edited or superseded at one named tier - CLASSIFICATION / RESEARCH / REASONING — the next piece of work is triaged and reasoned about as usual; nothing is replayed
- KNOWLEDGE + MEMORY + RULES —
tiers()resolves narrowest-first and the corrected row is now in what is read - AUTONOMY / APPROVAL — the channel's mode still governs; a correction does not grant permission to send
- ACTION / PROVIDER — the reply is drafted, or the call is placed, under the corrected context
- RESULT — the visible behaviour changes, or it does not, which is the diagnostic
- RELATIONSHIP / TIMELINE / MEMORY — the conversation is recorded against the person like any other
- 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#
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.
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.
Write one imperative sentence. If the old claim was true and has changed, supersede rather than editing.
Result The row is in force from the next piece of work. There is no propagation delay and nothing to publish.
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.
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 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.