Ratified by founder 2026-07-20 (CUST-WP-0060-T01, hub decision f4640f9e). Promotes the binky-control AutonomyPolicy lane model to fleet canon, unchanged in substance. binky-control's AutonomyPolicy.md remains the company-level policy instance; this standard makes the lane vocabulary and enforcement rules fleet-wide.
The rule
If the responsible human is unavailable, the system must either continue safely, prepare the next decision, or explicitly defer with evidence. It must not silently idle.
Valid states: proceeding | prepared for review | deferred by policy. Invalid state: waiting because unsure. Uncertainty triggers research, comparison, preparation, or risk classification — not paralysis. "Ask the human" is never the default.
Lanes
| Lane | Name | Agent may | Human involvement |
|---|---|---|---|
| green | Safe autonomous | research, summarize, classify, draft, organize, test, prepare | none (human-on-the-loop via logs) |
| blue | Reversible execution | internal docs, backlog updates, local scripts, reports, local commits | none, but logged |
| yellow | Deferred approval | prepare external emails, invoices, offers, releases, payments | async approval via decision records |
| orange | Time-window approval | customer/legal/accounting/banking actions needing business hours | engagement records, batched into command days |
| red | Human-only | signing, strategic commitments, bank/credential changes, sensitive legal/HR/security | always; agents prepare packages only |
Optimization target: maximize green+blue throughput, queue yellow, batch orange, protect red from automation. Risk-tiered gating (in-the-loop for irreversible actions, on-the-loop for recoverable ones) is the only oversight pattern that scales.
Lane as a spine field
lane is a mandatory field on every work record (see work-record-types_v0.1.md) and on every agent instance manifest. The chain is closed end-to-end:
work record.lane → view routing (autopilot / decision / engagement)
→ harness tool profile (enforced allow-list)
→ ops-warden credential lane (catalog access)
Declaring a lane an item does not hold is a policy violation the harness must catch (tool profile refuses the run).
Approval packages (yellow and above)
An agent hitting a lane boundary prepares a complete decision package, never a bare question: recommended action, reason, evidence links, risk level, reversibility, deadline (needed_by), attention cost, fallback if no response, options.
Human attention is a WIP-limited workstation
The responsible human's capacity is modeled like any lane capacity: attention budget (minutes/day, max decisions/day, max deep topics/day) and availability as first-class state (available | evening_window | unavailable | office_hour_day), with an explicit escalation allow-list when unavailable (critical security incident, payment failure, legal deadline). Yellow routes to the decision view, orange to the engagement view, both subject to that capacity.
Time-boxing is hub-owned: needed_by / fallback_if_no_response windows are watched by the hub → NATS → activity-core; a lapsed window raises the escalation or executes the declared fallback — never a human re-reading a file.
Raising autonomy
Autonomy per area is raised only after the system proves reliable there, by explicit human decision recorded as a decision work record. Lane assignments are auditable history; lowering a lane needs no approval.
References
binky-control/AutonomyPolicy.md(origin instance)canon/standards/work-record-types_v0.1.mdresearch/2026-07-19-work-orchestration-best-practices.md§2