The Inbox is the opposite instinct. It holds only the decisions that cannot be deferred, delegated to a machine, or made without a human in the room. A routine that emitted a clarification question, found a potential improvement, hit an unexpected failure, or discovered a gap—any of those lands here. A routine that silently succeeded, that logged its work, that made a prediction the owner will review later if they want—that goes to the audit log or the tracker, not the Inbox. The Inbox is a decision queue, not a log stream. Every item there is a knot that needs untying.
The five kinds of decisions that land in your Inbox are clarifications—questions about ambiguous input or conflicting constraints that a routine cannot resolve on its own—improvements, suggestions for how a workflow could be strengthened or a gap in the current process closed—approvals, gates where a human sign-off is required before the next step can proceed—failures, when a routine cannot complete its work and needs someone to decide whether to retry, abort, or patch the data—and exceptions, rare events outside the normal shape of a workflow that suggest either a bug in the system or a change in the world that the system should know about. These kinds are not a rigid taxonomy. They overlap. An approval might hide a clarification inside it. A failure might be an exception in disguise. But each one represents a different kind of thinking, and the Inbox sorts them so that the right person can apply the right kind of attention.
What an item carries#
Every Inbox item arrives with a shape: a kind, which tells you what type of thinking it needs; a status—new, snoozed, resolved, or dismissed—that tracks the lifecycle of the decision; an owner, either a user or a group resolved through your routing rules, so you know whose desk it landed on; a payload that describes what's at stake, often with links to the tracker issue, the pull request, the routine that made the decision, or the data that prompted it; and a trail of evidence—the audit rows that record not just what you decided, but when, why, and who made the call.
That trail is the difference between an Inbox item and a notification. A notification arrives, you act, it vanishes. An Inbox item leaves a scar. Years later, when you ask why a workflow was built that way, or what changed in a decision that seems strange now, the trail is there. It says: we decided this on this day with this reasoning, and here is who signed it.
This is why there is a rule: if there is nothing to decide, the item should not be here. A routine that finishes its work cleanly has a place—the audit log, the tracker, maybe a report you read at a different time. But an Inbox item implies a question. It implies ambiguity. It implies someone, somewhere, needs to think. The moment you resolve an item, the decision is recorded and the item moves out of the way. The moment you dismiss it, same thing. The Inbox is not a graveyard of finished work. It is a queue.
Items also carry a freshness signal—fresh, warn, or err—that tracks how long a decision has gone unmade. A clarification answered the same day is normal. A clarification left in the Inbox for a week is a problem. The freshness badge gets your attention before age does damage. It is the difference between "we have one thing to decide today" and "we have a backlog of stale decisions that nobody is paying attention to." Stale items are a signal that either the routing rules sent a decision to the wrong person, or the right person has too much on their plate, or the decision itself is impossible to make without more information. Any of those is a problem worth fixing.
The Inbox is not a system that makes decisions for you. It is a system that makes sure the decisions that matter do not get buried. Every item you see there is real work. Every item you resolve leaves a mark. The five item types walk each kind in turn, with examples from the workflows you will build.