# 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.

- **Status:** Available
- **Audience:** both
- **In the app:** #/autonomy-audit, #/activity, #/timeline
- **Last verified:** 2026-09-10
- **Canonical:** https://connectbyjbrh.com/docs/how-to/audit-a-decision/

## 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

1. 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.
2. 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.
3. 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.
4. 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.
5. 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 |

> **Note** That last row exists because of a real hazard. A late callback from a provider arriving after somebody has recorded their own view of a call must not overwrite it, so the engine's outcome and the human's disposition are kept apart on the call record. When the two disagree, both are true about different things.

## 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.

## Related

- [What Connect may do](https://connectbyjbrh.com/docs/autonomy/)
- [Proof that a message was sent](https://connectbyjbrh.com/docs/email/send-evidence/)
- [Call outcomes and dispositions](https://connectbyjbrh.com/docs/phone/call-outcome/)
- [Correct something Connect got wrong](https://connectbyjbrh.com/docs/how-to/correct-a-mistake/)
- [Find out why a reply was held](https://connectbyjbrh.com/docs/how-to/find-why-a-reply-was-held/)
- [Why uncertainty is a valid answer from a business agent](https://connectbyjbrh.com/research/uncertainty-is-an-answer/)

## What this page is based on

- docs-source/sources/GENERAL.md §5 — the audit trail, including refusals
- docs-source/sources/CHANNELS.md §1 — sent, uncertain, and provider evidence
- docs-source/sources/PHONE.md §1 — outcome and disposition kept separate
- Connect capability registry (docs-source/facts.py) — `audit_trail`