Skip to content
The GOVENANT Standard

The GOVENANT Standard — Part 7: Earned Autonomy and Resilience

Oversight is the default; autonomy is earned per task type on evidence and revoked on one breach. Regulated actions are pinned by an immutable ceiling no track record — and no configuration value — can ever lift. Around it all: paranoid detection with governed escalation, honestly described (it detects, pauses, and escalates; recovery is a human or a higher-tier decision — never claim “self-healing”).

7.1 The three tiers

TierNameSemanticsStarting point for
2ApprovalA human authorizes every act before it executes.Every new task type (cold start keeps the gate).
1Auto + notifyExecutes, then surfaces to a human.Proven-reversible task types.
0SilentRoutine, proven work runs unattended.Earned only.
stateDiagram-v2 [*] --> Tier2 : new task type (cold start) Tier2 --> Tier1 : ≥N approvals at ≥X% rate\n(thresholds in CODE) Tier1 --> Tier0 : sustained track record\n+ calibration in range (Part 6) Tier0 --> Tier2 : ONE human correction or breach Tier1 --> Tier2 : ONE human correction or breach note right of Tier2 PINNED actions live here forever: a code constant (NEVER_AUTO set) checked AFTER every autonomy-mode gate — no config path, track record, or "full autonomy" mode can promote them. end note

Rules:

  • Promotion requires evidence: sustained approval rate over a minimum sample (e.g. ≥90% over ≥8), thresholds in code, gated behind an explicit enablement flag. Calibration (Part 6 §6.5) is an input: a role that doesn’t know its own hit-rate cannot be promoted.
  • Demotion is hair-triggered and MUST exist. One human correction or breach drops the tier and writes a demotion row (a promotion path without a demotion path is not “earned autonomy”; it is a ratchet). A cooldown reinstates the human gate.
  • Pinning is code, not config. The audit’s sharpest finding in this area: an autonomy='full' config value that auto-applied every lever, including destructive ones. The NEVER_AUTO check runs after every mode gate, so no setting can defeat it. Probe: attempt to promote a pinned action via config/UI — it must be impossible.
  • Atomicity: the decision row and its approval-queue row are written atomically; expiry writes decided_by='system:expired' + timestamp (Part 4 S7).

Autonomy is monotonic and reversible: flip a flag, raise a tier, widen a cap — with the failure cost known in advance. Autonomy you can trust is the product.

7.2 What may never be autonomous (the pinned set)

Domain-mapped examples — each deployment declares its own NEVER_AUTO set in code review:

DomainPinned forever (Tier 2)
GTMSpend-cap raises, sending to unverified recipients, contract/pricing commitments, PR-wire submission
EngineeringProduction deploy/rollback, force-push, secret rotation, dependency-source changes
LegalFiling submission, privilege determinations, client communications of record
AllDeleting ledger data (impossible anyway — S1), modifying the pinned set itself

7.3 The three monitors

Resilience is three independent watchdogs, each obeying watchdog independence (a monitor must not share the failure mode it watches — not its flag, not its schedule, not its data source, not its grader).

Circuit breakers — per external dependency

Every external dependency (LLM APIs, vendor APIs, DB, deploy targets) is wrapped: N consecutive failures open the breaker, callers fast-fail, cooldown, half-open trial. Alert on the open transition only (not every failure). A breaker table where trip_count=0 on every row and no transition has ever been exercised is a dead mechanism — test-trip each breaker at install. Field lesson: a retired model ID silently broke every LLM call for days while agents “looked busy.” A breaker that opens is also a demotion signal (§7.1) for duties depending on it.

Liveness monitor — per role

Expects output from a role only when its feature flag is ON and its dependencies are healthy — a correctly-paused agent is not a false alarm, and an alarm that cries wolf gets ignored. Alert on transitions; escalate stalls to both ops channel and the executive layer. With the roster, liveness sharpens from “did the role act at all?” to “did each due duty resolve?” — the conductor’s missed rows are the liveness signal (Part 3 §3.6). The monitor itself needs a heartbeat: if its own schedule dies, meta-health must notice (no shared substrate blind spot).

Delivery-throughput monitor — per terminal edge

The performed-autonomy detector, run daily:

  • Set-relationship invariants, not zero-counters: drafts ≫ sends? same entity re-processed N× without shipping (churn)? coverage of qualified demand < X%? An absolute-zero check missed a live churn loop (64 contacts drafted 8×, 90% blocked) for weeks — the counters were all nonzero.
  • Demand-aware silence: “demand upstream, nothing shipped at the edge in 7d” fires an alarm.
  • Blocked vs starved: distinguish real failure (work attempted, structurally prevented — reasons required) from starvation (no upstream work) — the responses differ.
  • Actuation is half the mechanism (pair rule): the monitor’s breach events MUST have a live consumer duty that responds (throttle, reroute, escalate). A detector whose alarms pile up unconsumed is AP-6, the most common monitor defect in the field.

7.4 Escalation geometry

flowchart TD B[Breaker opens] --> E[Escalation event -- typed, consumer named] M[Duty missed / SLA breach] --> E T[Throughput breach] --> E E --> D[Consumer duty acts:\npause / throttle / reroute] E --> X[Executive layer: ledgered decision\nwith falsifiable prediction] E --> H[Human channel: alert on transition,\nwith the reason and the lever] D -.demotion signal.-> TIERS[Autonomy tiers 7.1]

Every escalation lands in three places at once: an acting duty (immediate mitigation), the executive layer (a governed decision about the cause), and the human channel (transition-only, reason attached). All three are rows; none is only a log line.