Who approves what: autonomy levels and hard stops

Stamped's authority at a plant is whatever the plant grants, per action class and per asset, in an AutonomyPolicySigned grants, envelopes, expiry (direction; L5 owns engine). Today the default is AL1Autonomy levels (direction; fast-loop stages 1–3 = AL1–AL3): the system recommends and a person decides and acts. Some action classes can never be granted at all.

flowchart TB
    %% house-style: tour-autonomy
    subgraph levels["Autonomy levels"]
        direction LR
        al0["AL0 Inform: shows state and evidence"] --> al1["AL1 Recommend: ranked card, a person acts"]
        al1 --> al2["AL2 Confirm to act: a person confirms a prepared write in a short window"]
        al2 --> al3["AL3 Standing policy: acts inside a signed envelope for a shift"]
        al3 -.-> al45["AL4, AL5: out of scope"]
    end
    subgraph grant["How a level is granted"]
        direction LR
        wins["Same-condition wins in the value ledger"] --> pol{{"AutonomyPolicy: action class, asset, envelope, stop conditions, expiry"}}
        plant["Person at the plant signs the grant"] --> pol
    end
    deny{{"Never grantable: safety or critical-equipment tags, quality holds, maintenance authorisation, dispatch sequence"}}
    pol --> al2
    pol --> al3
    deny -. "AL1 advice only" .-> al1

    classDef govc fill:#fff4d6,stroke:#c99a2e,color:#000
    classDef agentc fill:#e8f0ff,stroke:#5b7bd5,color:#000
    classDef loopc fill:#eef7ee,stroke:#4f9a4f,color:#000
    class pol,deny govc
    class plant agentc

The levels in practice#

At AL1 a card might say "fill head 7 is running 2 g heavy, trim it down". A person reads it and makes the change. That is where Stamped runs today and where most cards will stay.

AL2 prepares one specific write, for example a header pressure set point, and a person confirms it inside a token window of about two minutes. Only then does the writer send it. AL3 is a standing procedure for one shift: per-head trims within one step, each action reported, and a person can stop it at any time. These line up with the staged authority in the fast-loop docs, where stage 1 is messages, stage 2 a confirmed write and stage 3 a standing procedure.

AL4 (supervised autonomy) is not in scope for the next 12 months. AL5 is not in scope at all.

How a grant works#

An AutonomyPolicy names the asset, the action class, the level and an operating envelope: which tags, their minimum and maximum, the step size, the rate and the operating states in which writes are allowed. It lists preconditions (a minimum number of same-condition wins, calibrated coverage, a pinned model version, good data quality) and stop conditions (an operator touch, a lost heartbeat, a state change, a drop in coverage).

Switching a grant on needs a person at the plant. The cloud can revoke a grant or let it expire, but it cannot switch writes on. Every standing grant has an expiry, and a WAN outage never extends it, so the safe state arrives on its own.

Hard stops in code#

The master document's hard stops are enforced in the schema, not left to policy. No AutonomyPolicy can name a safety or critical-equipment tag, a quality hold, a maintenance authorisation or a dispatch sequence. Those classes exist only as AL1 advice that a named person acts on. The AutonomyPolicy and WriteRequestPlant Box write path request (direction; closure/action-intent.json retired) schemas, with those classes deny-listed and a CI test that fails if a policy names one, must ship before any write leaves shadow.

Two more boundaries hold at every level. Safety instrumented systems and existing interlocks stay outside Stamped's envelope by design; when Stamped writes, it writes only to set points the basic control system already accepts from operators. And agents never hold an AutonomyPolicy. They can draft one for a person to sign.

Go deeper: autonomy levels · AutonomyPolicy contract · security and tenancy