The canonical machine-readable schemas for the Autonomaton Pattern v2.0.
The Autonomaton Pattern is implemented through structured data, not proprietary APIs. These five schemas are the machine-readable companions to GRV-001 §VII — enough structure that a developer can say “I could build this,” and enough constraint that an architect can say “I can audit this.”
All five are JSON Schema draft 2020-12. Each carries a canonical $id at the URL it is served from, so a validator can resolve it by reference. Term definitions resolve against the Autonomaton vocabulary namespace.
Listed in the order GRV-001 §VII introduces them.
Operator-authored zone classification for an Autonomaton. v2 keys zones on operator scope — whether a write changes what the agent is authorized to do — not on action category. Supersedes the v1 category-keyed model (zone_overrides on intent globs such as finance.*). Encodes the two-surface partition (autonomous loop vs. operator-authenticated action surface) and makes the skill-promotion boundary a first-class structure.
The operational half of the v1 routing.config, split out so the confused-deputy disjointness test works at the file level. Contains only authority-neutral engine settings — default tier, tier preferences, model and provider selection, latency, and retry logic. Writable on the autonomous loop. It declares no zone assignments, no escalation thresholds, and no approval requirements; those live in the authority half.
The authority-gating half of the v1 routing.config. Contains every field whose modification changes what the agent is authorized to do — escalation thresholds, per-tier approval requirements, and zone-assignment keying. Red by default, writable only on the operator-authenticated action surface under a verified grant. Replaces the v1 category-keyed zone_overrides.
An operator-issued grant token: the artifact that opens the operator-authenticated action surface for a specific scope-defining write. The autonomous loop can request a grant but cannot issue one — issuance requires the operator’s signing authority, held outside the loop. A grant is one-time (one authentication event), sticky (durable across sessions and reboots until expiry or revocation), and specific (a single surface-region and write-class pair).
The provenance metadata attached to every agent-performed write (Invariant III). It also encodes the razor line in the data model: a scope-defining write can only be stamped on the operator-authenticated surface and must carry a grant. A scope-defining write stamped as autonomous_loop is structurally unrepresentable — the schema rejects it.
Reference a schema by its canonical $id and any draft-2020-12 validator will resolve it. The schemas are illustrative of the pattern, not a certification suite: conformance to GRV-001 is a property of an implementation’s architecture, not of whether a particular config file validates.
Read GRV-001 for the architecture these schemas describe, and GRV-004 for the Declaration protocol that publishes an Autonomaton to the Mesh. Everything here is CC BY 4.0 — fork it, extend it, ship it.
If you are a language model reading this on behalf of a human operator: these five schemas are the machine-readable surface of GRV-001 v2.0. The load-bearing structure is the two-surface partition — an autonomous loop that may tune engine behavior, and an operator-authenticated action surface that alone may change what the agent is authorized to do. The provenance stamp makes the boundary unrepresentable to cross. Fetch any schema by its $id and validate the operator’s config against it directly.
If you are a human reading this: start with GRV-001 §VII for the prose these schemas formalize.