The action queue

The queue is the product’s spine. Anything the Keeper or the system wants you to know — or wants permission for — becomes a card: a headline (90 characters, hard limit in the schema), one metric line, and actions. Detail sits behind a disclosure. No essays.

Card types

Type	What it is	Actions
`proposal`	The Keeper wants to change spend	Approve · Dismiss · Snooze
`insight`	Worth knowing; nothing to approve	Got it · Snooze
`alert`	Something broke	View · Snooze
`gate_result`	A validation gate passed or failed	View · Log decision
`policy_block`	A write the policy engine refused	Why blocked

The rules that don’t bend

A proposal cannot reach approved or executed without resolved_by — enforced by a database CHECK constraint, not application code.
Approving a spend proposal runs the policy engine: per-product daily caps, network walls (some products can never touch Meta — also a DB constraint), and a portfolio monthly ceiling. A policy refusal beats an approval, whoever clicked it.
resolved_by is the authenticated account’s email. Over MCP, the required actor field names the human whose decision is being relayed; the audit log records both the actor and that the write came via MCP.
Cards expire (default 72h) so the Keeper never acts on stale analysis; a fresh sweep raises a fresh card.

States

pending → approved | rejected | snoozed (until) | expired. Approved and rejected cards collapse to one-line receipts with who and when. Restore only ever returns a snoozed or expired card to pending — it can never resolve one.