the-custodian/canon/standards/autonomy-lanes_v0.1.md

id	type	title	domain	status	version	owner	revision	last_reviewed	review_interval	created	updated	scope	related_workplans	supersedes	origin
canon-autonomy-lanes	standard	Autonomy Lanes (Fleet) v0.1	custodian	accepted	0.1	the-custodian	accepted-1	2026-08-31	6m	2026-07-20	2026-07-20	fleet	CUST-WP-0060	none	binky-control/AutonomyPolicy.md (ratified for Binky 2026-07-16, DEC-2026-001)

Autonomy Lanes (Fleet) v0.1

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.md
• research/2026-07-19-work-orchestration-best-practices.md §2