# Exceptions to a rule

An exception is an autonomy setting attached to one contact or one endpoint instead of a whole channel. Because the narrowest level wins, it overrides the channel in either direction and survives every later change to it. Use one when the *permission* for a particular counterpart should differ; use memory or a standing instruction when it is the *wording* that should.

- **Status:** Available
- **Audience:** both
- **In the app:** #/autonomy, #/relationships
- **Last verified:** 2026-09-10
- **Canonical:** https://connectbyjbrh.com/docs/autonomy/exceptions/

## The four instruments, and which problem each solves

| You want | Use | Because |
|---|---|---|
| This customer's replies read by a person first | An `ask_before_send` setting on the contact | It changes permission, and nothing else |
| This customer never contacted again on any channel | A block on the contact | A block is a tagged memory entry, so it holds everywhere and afterwards |
| Connect to stop offering this customer a discount | A standing instruction | It changes what is written, not whether it may be sent |
| Connect to know this customer's account manager changed | A memory entry at contact tier | It is knowledge, and it should shape every channel's wording |

Reaching for an exception where the real need is a standing instruction is the usual mistake, and it is expensive: it converts a wording problem into a permanent queue of approvals that a person then has to work through forever. Ask what would change if the setting worked perfectly. If the answer is "the reply would say something different", it is not an override you need.

## When an exception earns its keep

- **A named account under negotiation.** Everything to that organisation is read before it goes, while the rest of the mailbox runs at full speed.
- **A customer who asked for a human.** Honouring that is a permission change, and it belongs at contact scope so it follows them across email, WhatsApp and voice.
- **A mailbox with a different audience.** A `careers@` or `legal@` address held at `ask_before_send` while `hello@` runs `autonomous` — that is endpoint scope, not contact.
- **A pilot in reverse.** One trusted contact set to `autonomous` inside a channel that is otherwise supervised, to see how the unattended path behaves on a small surface.

## Exceptions outlive their reasons

> **Careful** An exception has no expiry. The negotiation that justified holding one account's mail ends; the setting does not. Months later the symptom is "Connect is slow on this account" and the cause is a setting nobody remembers making. Review the list whenever you change a channel, and delete the ones whose reason has gone.

This is also why the reason is worth writing down somewhere durable at the moment you set it — as a note on the relationship, or as a standing instruction sitting beside it. The autonomy screen records what is set; it is not the place that remembers why.

The decision log answers the question from the other end. Every action and every refusal carries the rule it ran under, so an override still firing is visible in the log long before anybody thinks to audit the settings themselves.

## Setting and removing one

1. Decide the level first — this contact, or this mailbox or number.
   - Result: Contact scope follows a person across channels; endpoint scope stays with the address.
2. Set the mode on that level from the autonomy screen.
   - Result: It takes effect on the next piece of work; anything already held stays held under the rule that held it.
3. Record why, beside the relationship.
   - Result: The next person to review the list can tell a live override from an expired one.
4. To remove it, delete the exception rather than changing the channel.
   - Result: Changing the wider level does nothing while the narrower one exists — removing the workspace or channel default leaves the contact-level one firing.

## Questions

### Can an exception be looser than the channel, not just stricter?

Yes, and that catches people out. Narrowest wins in both directions, so a contact set to `autonomous` inside an `ask_before_send` channel sends without asking. Check which way round it is set before relying on a channel-wide promise.

### Does an exception on a contact cover their colleagues at the same company?

No. It is attached to that contact. If the whole organisation should be handled differently, set it on each person you correspond with, or hold the endpoint they write to instead.

### What happens to exceptions when two duplicate people are merged?

The surviving record keeps its own settings. Re-check the exceptions after a merge rather than assuming the ones on the absorbed record carried across.

## Related

- [Autonomy scopes](https://connectbyjbrh.com/docs/autonomy/scopes/)
- [The four autonomy modes](https://connectbyjbrh.com/docs/autonomy/modes/)
- [Standing instructions](https://connectbyjbrh.com/docs/autonomy/standing-instructions/)
- [The decision log](https://connectbyjbrh.com/docs/autonomy/audit-trail/)
- [Memory in Connect](https://connectbyjbrh.com/docs/memory/)
- [Relationships in Connect](https://connectbyjbrh.com/docs/relationships/)

## What this page is based on

- Connect source pack §5 — scopes, narrowest first (`docs-source/sources/GENERAL.md`)
- Connect source pack §6 — memory tiers and tagged directives
- Connect capability registry (`docs-source/facts.py`) — `autonomy_modes`, `block_directive`, `duplicate_merge`
- `backend/app/autonomy.py`, `backend/app/connect_memory.py`