Settings
Every module can be switched off. This one can't.
One tool, set_modules, turns any part of the record off — decisions, deals, whatever isn't being used. Settings itself is the single exception, and it's an exception for a mechanical reason, not a policy one.
Off means offered, not erased.
The record is one database whether or not every part of it is in use. Switching a module off tells the connector to stop putting that module's tools in front of Claude in this conversation — it stops offering them, so there's nothing to accidentally reach for. It doesn't touch the rows already written. Turning deals off doesn't delete the fourteen deals sitting in the pipeline; it just means Claude isn't handed deal tools until it's switched back on.
That's a real distinction. Deleting data and hiding a tool are different decisions with different consequences, and this system keeps them as two separate acts rather than folding one into the other for convenience.
The exception
A switch that can disable its own switch is a lockout. If Settings could be turned off through the same mechanism it controls, the only way back on would be an operator editing the database by hand — the same recovery path that exists today for a stale token or a claimed account with no user left holding it.
The rule that keeps it that way.
This isn't Settings being treated as more important than everything else in the record. It's a narrower claim: any module capable of reaching itself has to stay reachable, or turning it off becomes permanent by accident rather than by intent.
- Decisions offFine. Turn decisions back on later through Settings, which is still there.
- Deals offFine, same reasoning — nothing about turning deals off touches the ability to turn deals back on.
- Settings offRefused. There would be no remaining path back to on, short of someone editing the database directly.