Find out why Connect did something
Open the decision log and find the action. Each entry records what was decided, by what, under which rule, and what happened — refusals included, because a refusal is a decision. That chain is what turns "why did it do that" from a theory about settings into a fact you can read, months after the settings have changed.
What is recorded#
- What was decided
- The action: a reply drafted, a message sent, a call placed, a follow-up scheduled, an approval released.
- By what
- The actor. The engine and a person are distinguished, which settles most disputes on its own — a good proportion of "why did Connect do this" turns out to be a colleague.
- Under which rule
- The autonomy rule or directive in force at the moment of the decision, which is not necessarily the one in force now.
- What happened
- The outcome, including the provider's own acknowledgement where one applies.
Refusals are entries in their own right. When Connect declines to answer a commercial question Knowledge does not support, or a send is refused because the recipient is suppressed, or a call is refused because the budget cannot cover it, each of those is recorded rather than passing silently. A log that records only the things that happened cannot answer "why did nothing happen", which is the more common question.
Working backwards from an action#
Start from the artefact rather than the date. Open the message, the call or the follow-up you are asking about.
Result You have the record the log entry attaches to, which is faster than scrolling a day.
Read the actor first. Decide whether you are investigating the engine or a person before you investigate anything else.
Result Half of these end here, correctly.
Read the rule the decision was taken under, and compare it with what is set now.
Result If they differ, the behaviour is explained: somebody changed the rule between then and now, and the old entry is a record rather than a contradiction.
If the rule looks wrong for the scope, check the narrower tiers. Autonomy and memory both resolve workspace, channel, endpoint, contact, with the narrowest winning.
Result The usual answer is a forgotten contact-level rule that is doing exactly what it was written to do.
Confirm the outcome rather than assuming it followed from the decision.
Result This is the step people skip. A decision to send and a confirmed send are different facts, and the gap between them is where the interesting failures live.
Reading an outcome honestly#
| State | Means | Do not read it as |
|---|---|---|
| Sent | The provider acknowledged it | Delivered, opened or read |
| Uncertain | No acknowledgement arrived either way | Failed — and never re-send on a maybe, which is how a customer gets the same reply twice |
| Refused | A rule declined it, and the rule is named | A fault |
| Held | Waiting for a person, or for an allowance to reset | Slow — nothing has been sent, so the recipient sees nothing |
| A call's engine outcome | What the engine concluded happened | What a person concluded — the human disposition is a separate field on purpose |
What the log will not tell you#
It records decisions, not deliberation. There is no transcript of the model's reasoning to inspect, and asking for one is asking for something that would be reconstructed rather than recorded. What you get instead is the evidence a decision was made under: the rule, the actor, the grounded material, and the result.
- The entry names a rule you do not recognise
- Look at the tier. A rule at a narrower scope than you were thinking about is the common case, and the memory viewer shows every tier for the person or channel involved.
- Two entries look contradictory
- Check the times against when settings changed. The log is a record of what was true then, not a description of what is true now.
- An action has no entry
- Check whether it was an action at all. Mail arriving, a provider retrying its own delivery and a person reading a screen are not decisions.
- You need it for a dispute months later
- That is what it is for. The entries persist, which is why approvals are recorded against the person who gave them.
Questions#
Can I see who approved a particular reply?
Yes. An approval is recorded against the person who gave it, and that is specifically so "who released this" has an answer long after everyone has forgotten the afternoon it happened.
Does the log show why a call ended?
The call record carries the engine's outcome — including whether the call was never a conversation, meaning either nobody picked up or it never rang — alongside a separate human disposition. Attribution of the hang-up is part of the call record rather than a guess in the log.
Is there an audit entry when Connect refuses to answer something?
Yes, and it is one of the more useful kinds. A refusal to invent a price or a term Knowledge does not support is a decision, recorded as one, which is how you tell a designed refusal from a gap.
Can a customer workspace read its own decision log?
Yes. Both audiences have it over the same implementation; a customer sees their workspace's decisions and nobody else's, which is enforced by the same isolation that governs every other read.