Inbox & Signals
The append-only nervous system used to deliver work, blockers, decisions and escalation.
Every Control node can have an append-only inbox. Messages and read receipts are history, read state belongs to an execution, and unread items can block consequential actions. Typed Signals add severity, time-to-consequence, impact scope and required authority so important information can escalate without granting extra authority.
Every team and worker gets a mailbox. Anyone can put a note in the right mailbox, but nobody can erase old mail. If something important is unread, the worker can be stopped from doing risky work until they read it. Emergency mail can be copied upward to the right manager without making the sender the manager.
The inbox is both a communications substrate and a safety primitive. It keeps delivery separate from chat UI, so Workspace can later show the same messages without becoming their canonical store. Typed signals make BLOCKED, RISK, HANDOFF, REVOKE and similar events machine-routable while preserving the normal parent chain.
Append-only by design
Each node has append-only items and append-only cursor/read receipts. Nothing needs to be rewritten to know what was sent or what an execution had read at a point in time.
Typed Signal vocabulary
Protocol signals require severity, time-to-consequence, scope-of-impact and authority-required metadata. This lets routing reason about urgency without pretending every message is equally important.
| Signal | Use |
|---|---|
| STATUS | State/checkpoint report |
| ASK | Request for information or help |
| BLOCKED | Work cannot continue without intervention |
| RISK | Potential harmful or consequential condition |
| DECISION | Accepted decision notification |
| HANDOFF | Transfer of operational context or responsibility |
| SPAWN_REQUEST | Request to create delegated orchestration capacity |
| ESCALATE | Raise a signal through lineage |
| REVOKE | Withdraw or fence authority/work |
| INCIDENT | Operational incident requiring attention |
| RECEIPT | Evidence that a transition/effect occurred |
Bypass notification does not bypass authority
Why unread inboxes can stop work
The Control inbox contract says a holder may not take consequential action while its held inbox has unread items. Installed hooks/gates enforce that for supported harnesses; other execution environments must use the same shared gate rather than inventing a second rule.
Related pages
Canonical sources
These pages are explanatory read models. Where wording conflicts with implementation or a Control decision, the linked implementation/decision is authoritative and this page should be corrected.