# Connect did something without asking

Every action Connect takes is written to the decision log with what was decided, by what, under which rule, and what happened. Start there: the entry names the scope that permitted it. In practice the answer is one of four — a wider scope than you checked, a standing instruction, a colleague's approval, or the Connect Assistant acting on somebody's request.

- **Status:** Available
- **Audience:** both
- **In the app:** #/autonomy-audit, #/autonomy, #/activity
- **Last verified:** 2026-09-10
- **Canonical:** https://connectbyjbrh.com/docs/troubleshooting/unexpected-autonomous-action/

## What the symptom looks like

A message, a reply or a call happened and nobody remembers approving it. The conversation shows it as sent, with evidence from the provider. Nothing failed; the surprise is that it succeeded without a decision you recognise.

This is a question with a definite answer rather than a mystery. Autonomy is not probabilistic: an action is permitted by exactly one rule at exactly one scope, and that rule is recorded alongside the action.

## Reading the entry

A decision log entry answers four questions, and reading them in order gets you to the cause faster than reading the conversation.

**What was decided** — The action, in the same shape whether it was taken, held or refused.
**By what** — A person, the engine, or the Connect Assistant acting on a person's instruction. These are not interchangeable, and the entry does not blur them.
**Under which rule** — The mode and the scope that permitted it. This is the field that answers the question you are actually asking.
**What happened** — The provider's outcome, including a failure. An entry is written whether or not the action succeeded.

> **Note** The log records refusals in the same shape as actions. That matters here in reverse: if you are trying to prove Connect did *not* do something, the absence of an entry is weaker evidence than the presence of a refusal.

## The four causes, in order of likelihood

| Cause | What the entry shows | How to change it |
|---|---|---|
| A wider scope was `autonomous` | The rule named is at channel or workspace scope, not the contact you were thinking of | Set the narrower scope explicitly; the narrowest applicable rule wins, so a contact rule overrides the channel's |
| A standing instruction covered it | The instruction is named as the authority | Review the standing instructions; one written broadly authorises more than its author usually intended |
| A colleague approved it | A person and a time | Nothing to fix. The queue is the workspace's, and this is the system working as designed |
| The Assistant was asked to do it | The Assistant as the actor, with the person who asked | Its rights are already narrower than a person's — it cannot quote a price or clear a do-not-contact entry — but within them it acts on request |

## What Connect did complete

- It evaluated the autonomy rules for the channel at all four scopes and applied the narrowest one that matched.
- It applied the gates that hold whatever the mode says: suppression, unsubscribe, do-not-contact and any memory block on that contact.
- It handed the action to the provider through the same send boundary a person's own send uses, and recorded the provider's acknowledgement as the evidence.
- It wrote the action, its authority and its outcome to the decision log, and put the result on the person's timeline.

## What Connect did not complete

- It did not ask, because no applicable rule required asking. Nothing was skipped; the requirement was not there.
- It did not exceed a gate. If a suppression or a do-not-contact entry applied, the action would have been refused rather than taken, whatever the mode said.
- It did not recall the message afterwards, and cannot. Once a provider accepts an action it has left, which is why the control lives before the send rather than after it.
- It did not change any setting as a result. The rule that permitted this action is still in force for the next one.

## What to do next, and when to escalate

1. Narrow the scope rather than switching the workspace off.
   - Result: The specific contact or mailbox stops, and the rest of the business keeps working. A whole-workspace stop is available if you need it now, but it is a blunt answer to a specific question.
2. If a standing instruction was the authority, read it as written rather than as remembered.
   - Result: Instructions are applied literally. 'Always confirm bookings by email' authorises email that somebody may not have pictured.
3. Record what should have happened as memory at the right tier.
   - Result: The next draft is written knowing it, which is a durable fix rather than a one-off correction.

Escalate when the log names a rule you can demonstrate was not in force, or shows an action with no authority recorded at all. Both are genuine defects rather than configuration, and both are worth reporting with the timestamp and the channel.

## Questions

### Can Connect act outside the mode I set?

Not through autonomy. What it can do is act under a rule set at a scope you were not looking at, or under a standing instruction, or on a person's request through the Assistant. All three are recorded, and each names its authority.

### Does an autonomous channel bypass suppression or do-not-contact?

No. The gates apply whatever the mode says, which is what makes them gates rather than defaults. An action against a suppressed recipient is refused and the refusal is logged with its origin.

### Can I see everything that went out without an approval?

The decision log carries the authority for each action, so filtering to actions whose authority was a mode rather than a person answers exactly that question, for whichever period you need.

## Related

- [The decision log](https://connectbyjbrh.com/docs/autonomy/audit-trail/)
- [Autonomy scopes](https://connectbyjbrh.com/docs/autonomy/scopes/)
- [Standing instructions](https://connectbyjbrh.com/docs/autonomy/standing-instructions/)
- [The gates that always apply](https://connectbyjbrh.com/docs/autonomy/explicit-gates/)
- [Changing what Connect may do, end to end](https://connectbyjbrh.com/docs/workflows/autonomy-change/)
- [Connect Assistant](https://connectbyjbrh.com/docs/assistant/)
- [Separating the agent's authority from the person's](https://connectbyjbrh.com/research/authority-separation/)

## What this page is based on

- Connect source pack §5 — the audit trail records the rule and the refusal (`docs-source/sources/GENERAL.md`)
- Connect source pack §8 — the Assistant's rights are narrower than a person's
- Connect capability registry (`docs-source/facts.py`) — `audit_trail`, `autonomy_modes`, `suppression_dnc`