Connect ignored what I told it
Four things cause this, and they are worth checking in order: the row is at the wrong tier, a narrower row disagrees with it, it did not fit the character budget on a call, or what you did was not a memory at all. A fifth possibility is that it worked and the conversation you looked at was already in flight when you wrote it.
What the symptom looks like#
A reply, a drafted email or a spoken line that contradicts something written in the memory viewer — usually politely and confidently. Nothing errors, nothing appears in Needs You, and the row is still there when you go back to look at it. That combination is what makes this frustrating: every screen says the instruction exists and the behaviour says it does not.
It is almost never a fault in the sense of something being broken. It is resolution working exactly as specified against a row that says something slightly different from what you meant, or somewhere different from where you meant it.
The four causes, most likely first#
| Cause | How to confirm it | The fix |
|---|---|---|
| Wrong tier | Open the viewer from the surface the work arrived on. The row is in a group you did not expect, or is not shown at all | Rewrite it at the tier where it is true, and forget the original |
| A narrower row disagrees | Read the groups below the one you wrote in. Contact beats endpoint beats channel beats workspace | Correct the narrower row; adding a third row makes it worse |
| It did not fit the budget | Only on the phone. Memory is capped at 700 characters and the contact block at 600 | Shorten to the sentence that changes what is said; move background to Knowledge |
| It was never a memory | Check what you actually did. Rejecting a draft, editing a reply, or writing a note in a message body records no lasting claim | Write it as memory at the right tier |
The fifth cause is timing. A call renders its brief once at the start, and a draft already written is unchanged by a later row. If the correction was written during the conversation you are judging it by, it applies to the next one and nothing is wrong.
What Connect completed#
- It read the memory that applied at each of the four tiers, including the empty ones.
- It resolved them narrowest-first, exactly as documented, and used what won.
- It wrote and — depending on the channel's autonomy mode — sent or held a reply.
- It recorded the decision: what was decided, by what, under which rule, and what happened.
So the outbound work is done and the record is intact. On email, a reply the customer has already read cannot be recalled; on the phone, a spoken line has been spoken. Correcting the memory changes what happens next, not what has happened.
What Connect did not complete#
- It did not apply the row you had in mind, because a narrower one or a different tier governed.
- It did not warn you. There is no signal for "a broader row was outranked" — that is ordinary resolution, not an anomaly.
- It did not learn anything from your having rejected or rewritten the reply. That was a decision about one message.
- On a call, it did not carry anything written after the brief was rendered.
What you can do#
Open the memory viewer from the same surface the work arrived on — the contact for a personal reply, the mailbox row for an endpoint problem.
Result You are reading the same four groups the reply read, in the same order.
Read from the narrowest group upwards, and stop at the first row that speaks to the subject.
Result That is the row that governed. If it is not the one you wrote, you have your answer without changing anything yet.
Correct that row, or move yours to the tier that governs.
Result In force from the next piece of work — no rebuild, no approval, no delay.
Trigger the behaviour again and read the result.
Result A changed reply is the proof. An unchanged one sends you back to the table above, one row further down.
What an administrator can do#
Read the whole tier rather than one row. The memory sheet in the Data grid groups and filters the workspace's rows, and contradictions between colleagues' entries are visible there in a way they are never visible one contact at a time. Where two rows genuinely conflict, supersede one rather than deleting it, so the reply that was sent under it stays explainable.
Check the decision log for the message in question. It records the rule that applied, which settles arguments about whether a behaviour was a memory problem or an autonomy one — a held reply and an ignored instruction look identical from the outside and have nothing in common.
When to escalate#
Escalate when the four causes are all excluded and the behaviour repeats: the row is at the tier the work resolves to, no narrower row contradicts it, it is short enough for the budget, and it is genuinely a memory row rather than a note. At that point the useful evidence is the contact, the channel, the endpoint and the approximate time — enough to find the decision in the log without quoting anybody's message content.
Questions#
Why does nothing tell me a broader row was outranked?
Because being outranked is normal. Narrowest-first resolution exists so that a rule about one customer can override a rule about the business, and flagging every such case would make the queue useless. The viewer's grouping is the signal: it shows you which tier holds what, so an override is visible when you go looking.
The instruction works on email but not on the phone. Why?
Almost always length. Voice has hard character budgets — 700 for memory, 600 for the contact block — because instruction size is measurably a latency decision. Written channels have no equivalent cap. Shortening the row usually fixes the phone without changing the email.
Could this be an autonomy problem rather than a memory one?
Yes, and they look alike. If the reply was correct but never went out, that is autonomy holding it, not memory being ignored. The decision log names the rule that applied, which separates the two in one reading.