A review is a human-in-the-loop checkpoint: an item someone must clear before the work moves on. The Review Policy Console is where you decide what fires one. Rather than mark each sensitive action by hand, you configure the rules once, per lane, and the right work starts arriving in the queue automatically. The console is the configuration face over the same review_policy store the kernel reads at decision time, so the rules you set here are the rules that actually govern routing.
What it does
Four review lanes, one typed queue. Every “needs a human” item lands in one of four lanes: IDENTITY (a low-confidence party merge the human must decide), ESCALATION (an agent asking to act above its ceiling), TRIAGE (general human review), and EXTRACTION (a low-confidence document extraction held for a person to confirm). They are one queue with a lane discriminator, not four separate systems, so the console configures all of them from one place and the queue reads them from one place.
A policy per lane. Each lane carries its own configuration: whether it is enabled, the confidence threshold below which an item routes to review, the SLA in minutes, the time-to-live in days before a stale item expires, the triage types the lane accepts, the routing, and the authority required to reassign. Set a lane’s policy once and the kernel applies it consistently: an identity match below the floor opens an IDENTITY item instead of folding automatically, an extraction below its confidence threshold opens an EXTRACTION item rather than committing silently. The structure decides; you set the structure.
Setting a policy is authoring a control. Editing a lane’s policy is not a casual preference change. Because a change can disable a lane, raise a threshold, or relax an SLA - each of which weakens what gets routed to a human - the write is treated as authoring a human-oversight control. It carries the same Owner-tier, fail-closed authority as authoring a file-retention policy, and every change is recorded with who made it and when on the tamper-evident audit chain. You cannot quietly turn off oversight; turning it off is itself a governed, attributed act.
Review routes, it never re-decides. The queue is the triage surface, not a second decision engine. When a review is resolved, the resolution routes back to the owning primitive’s canonical verb: a confirmed identity merge runs the real party-merge, an approved escalation flows to the real gate. Review opens, routes, and records; it does not re-merge, re-grant, or re-apply on its own. That keeps one source of truth for every decision and stops the queue from becoming a back channel around the rules.
The queue, with aging and SLA. Alongside the policy, the console reads the live queue: items by lane, who claimed each one, how long it has been waiting, and where it stands against its SLA. A claim is atomic - exactly one reviewer wins under contention - and a duplicate open for an item already in the queue dedups to the existing row, so a re-firing trigger never spams the lane. Stale items expire on the lane’s TTL rather than lingering forever.
Separate from the authorization policy. This console governs the review queue. The kernel also carries a distinct policy.* domain - the authorization rules that decide what an actor is allowed to do, authored and evaluated separately. The two work together (a policy can route work into review), but they are different surfaces: one decides who may act, the other decides what gets a second pair of eyes.
How you use it
Open the console. Read the per-lane configuration for the workspace: each lane and its current policy, side by side. This is an admin view, scoped to your workspace.
Tune a lane. Pick a lane and adjust its policy: enable or disable it, move the confidence threshold, set the SLA and the expiry window, choose which triage types it accepts. The change saves one lane at a time as an idempotent upsert, so editing IDENTITY never disturbs EXTRACTION.
Watch the queue. Read the live queue filtered by lane, status, or claimant, with computed aging and SLA, to see what is waiting and what is overdue. From here a reviewer claims an item, works it, and resolves it - and the resolution routes to the owning verb.
Reassign or hand back. Move another person’s claimed review to a new reviewer when ownership needs to change, or hand back your own claim so someone else can pick it up. Reassignment is sensitivity-gated and ownership-only: it changes who holds the item, never the item’s effect.
The kernel verbs behind it
Each goes through the one front door - permission-checked and audited before it runs (see Security and permissions). These are the verbs most specific to configuring review policy and working the queue.
Setting the policy:
review.policy.get- read the workspace’s per-lane review-policy configuration, one entry per lane.review.policy.set- upsert one lane’s policy (enabled, threshold, SLA, TTL, triage types, routing); authored as an Owner-tier human-oversight control.
Working the queue:
review.list- read the queue by lane and status, with computed aging and SLA.review.open- enqueue a typed item into a lane (idempotent dedup on lane and subject).review.claim- take ownership of an open item atomically (exactly one claimant wins).review.unclaim- hand your own claimed review back to the queue.review.reassign- move another reviewer’s claimed item to a new reviewer (ownership-only).review.resolve- close out an item; the resolution routes to the owning primitive’s verb.review.expire- terminally expire a stale item on the lane’s TTL.
The authorization-policy domain (distinct from review policy):
policy.evaluate- apply the authorization rules to a request.policy.get- read one policy record.policy.list- list the authored policies.policy.validate- check a policy is sound.policy.create- author a new policy (admin-side).policy.edit- edit an existing policy.policy.set- set a named policy configuration value.policy.publish- publish a policy version.
Where reviews meet held changes, the gate verbs carry it forward:
gate.propose- stage a change as a gate that waits for a human.gate.apply- replay an approved gate’s staged change (fail-closed, at most once).gate.get- open one gate with its proposed change and history.gate.list- see the pending gates, filtered by state, category, or reviewer.
See the full set in the review verb reference.