Inbox
The inbox bundles what is waiting on a decision: eight queues in one place, with a visible confirmation after every decision.
Eight queues in one place
Section titled “Eight queues in one place”Instead of searching several pages for open items, you see them bundled here, with a filter by type and room. The room filter lists only rooms that currently contain an inbox item; it is not a room directory. The eight queues:
Decision draft
A new decision, or one carried over from chat, waiting to be accepted or rejected.
Dreaming proposal
A proposal from the memory’s self-directed consolidation (dreaming), waiting for review.
Knowledge draft
An imported document still waiting for review before acceptance.
Exception request
A request for a time-limited exception to a rule.
Agent approval
A risky agent action that needs an owner’s approval (human-in-the-loop).
Knowledge finding
A finding about maintaining the memory, waiting for a decision.
Brain access request
A room owner requests access to a protected Corp Brain; a designated publisher approver decides.
Budget request
A room owner requests more monthly budget, with a reason. A platform admin decides; a rejection needs a reason.
Deciding: open or inline
Section titled “Deciding: open or inline”Decision drafts lead through “Open” to the record; the decision is made there. You can decide a knowledge draft directly here if its import contains only one entry. An import with several entries leads through “Open” into the import review, because it is reviewed as a whole. Dreaming proposals, agent approvals, exception requests, Brain access requests, and budget requests are decided directly here. Knowledge findings follow their own maintenance lifecycle: mark them as resolved or explicitly choose not to fix them. A finding’s evidence appears as clickable titles with type and room; you can expand the technical ID. When a finding is about an exception, “Open exception” is the primary action into the governed rule flow. “Mark as resolved” and “Won’t fix” change only the finding’s status, not the rule or exception itself.
A load failure shows itself visibly with “Retry”; “Nothing to decide” appears only after a successfully loaded, empty stock, never in place of an error. Every inline decision then shows a visible confirmation instead of a silent list change.
The pane on the right shows the record itself rather than a preview of it: the item’s facts, its full text, the records a dreaming proposal would touch, the arguments an agent action wants to run with, and, where the effect is defined, what accepting will actually do. For a dreaming proposal, it also shows the path from proposal to effect: the state (open, accepted, or rejected), the object an acceptance produced or a note where this record does not link it, the governed step still missing before it becomes a rule in force, and a later run that reconsidered it or a note that there is none. This way, an acceptance never reads as a rule already in force.
Accepting a dreaming proposal that proposes a relationship between decisions can leave the row open instead of resolving it: when the relationship’s declared effect is not yet built into the answer path, the proposal stays here with a visible explanation of why, instead of disappearing as if it had been decided. It is not rejected and not lost, and accepting it again resolves it once that effect exists.
The inbox tray
Section titled “The inbox tray”The inbox icon in the top bar opens a short list of everything waiting, grouped by queue, with one line for each item. The list is a signpost rather than a second inbox. It shows what is open and how long it has waited, without covering the screen you are working on.
Clicking a line opens the inbox with that item already selected. This way, you read and decide in one place. The count on the icon falls as you decide.
Exception requests: reason and expiry
Section titled “Exception requests: reason and expiry”For an exception request in the inbox, a reason is mandatory. Without it, Accept and Reject stay disabled. On approval, you choose the expiry in days (at least 1, suggested 14). For Brain access requests and budget requests, a reason is mandatory only for a rejection.
The help on rules describes the full exception workflow (request, decision, revocation): Help: rules and exceptions
Requests in my rooms
Section titled “Requests in my rooms”Below the queues, two collapsed sections show your own matters: all exception requests from your own rooms, regardless of status and with a count already in the collapsed heading, and your own knowledge submissions with their state (draft, accepted, rejected). Each submission row links into the import review.
Clicking an entry opens the request detail. From there, you can withdraw a still-pending request of your own, or an authorized person can revoke an approved exception. This section never decides itself; decisions happen in the queues.