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

---
id: canon-autonomy-lanes
type: standard
title: "Autonomy Lanes (Fleet) v0.1"
domain: custodian
status: accepted
version: "0.1"
owner: the-custodian
revision: "accepted-1"
last_reviewed: "2026-08-31"
review_interval: 6m
created: "2026-07-20"
updated: "2026-07-20"
scope: fleet
related_workplans:
  - CUST-WP-0060
supersedes: none
origin: 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