How to decide from your inbox

Open the inbox

/me/inbox groups items as Signatures, Approvals, Questions, Hand-offs, Mentions, Information, then by program. Each row shows the kind, the record title where the thread rule allows it (otherwise “From a private thread”), the twin that proposed it (“Maya N.’s twin (agent) · scientist”, illustrative), its age and the permission it needs. With focus in the list, j and k move, Enter opens, e opens edit, Esc opens the decline dialog, x toggles selection; the keys are remappable or can be turned off in Settings.

Read the four panes

An item page (/me/inbox/[itemId]) shows Why now (the trigger: “entry EXP-0421 closed”, “SOP-BA-012 v4.0 became effective”), What it read (the run rail: tool calls, sources, documents fetched), What it will write (the proposal with its permission_exercised, sources and citation coverage) and What happens next (the consequence). A proposal whose record changed since it was filed is marked “Changed since proposed” with the diff and cannot be approved as it stands (409 stale_proposal).

Approve, edit then approve, or decline

Approve calls POST /me/inbox/{item_id}/resolve with {decision: "approve"}. The API checks that the item is yours (or routed to you under an active delegation), that you hold the write’s permission and, on a twin run, that you are the bound person; it then recomputes basis_hash, executes the write server-side from the stored arguments, recomputes approved_hash and writes the record and the audit row in one transaction. Edit then approve applies your edits before the hash and the record page later reads “edited before approval” with the diff. Decline needs a reason (“Declining needs a reason; it is stored as evaluation data.”). Nothing here resumes a container: a twin’s proposal is a stored write waiting for your decision.

Resolve a batch by selection

A batch_approval item (at most 10 proposals of one tool and target type) lists each item with an expanded summary and a checkbox. Tick the rows you want, choose Approve selected, and read the confirm sheet “Approve 8 checks with review.sops.manage” before confirming; the request carries items[{tool_call_id, decision, edits?, reason?}]. Every item is checked and audited on its own: one you may not approve fails with batch_item_forbidden while the rest proceed; approved items are written at once; declined items need a reason each; undecided items stay open until expiry and the card then reads “5 approved and written, 5 expired”. There is no “Approve all”. The result is announced (“4 approved, 1 declined”) and focus moves to the next item.

From the phone or the e-mail

The digest e-mail carries the record type, the program name, the id and a link only: no titles, no agent text, no token that acts, no approve-by-reply. The link opens the item after sign-in. At 390 px the inbox is the page: approve, decline with a reason and resolve batch items one at a time (“item k of N”); editing is desktop-only and the button says so; signing works after re-authentication.

Read what changed

The record carries origin = agent and the footer “Proposed by Maya N.’s twin (agent); decided by Maya N. on <date>” (illustrative). Setup › Audit shows the write with actor_kind = agent, interrupt_id, approved_by_user_id, permission_exercised, proposal_hash, approved_hash, twin_id, trigger_id and, for a batch, batch_id. The item is done and the twin panel’s count of accepted, edited or declined proposals moves by one.