FPF Reference

RoC‑Autonomy Budget & Enforcement

Pattern E.16 · Stable Part E - The FPF Constitution and Authoring Guides

Intent. Make any claim of autonomous behavior testable and enforceable via a published AutonomyBudgetDecl, Guarded enactment, Override SpeechActs with SoD, and a Work‑anchored AutonomyLedger. Rule (summary). If a Role/Method/Service claims autonomy, authors MUST: (i) publish an AutonomyBudgetDecl with AdmissibilityConditionsId and OverrideProtocolRef; (ii) gate Method steps with requiresAutonomyBudget; (iii) write a AutonomyLedgerEntry on every admitted Work; (iv) block on depletion until a ResumeAutonomy SpeechAct passes SoD; (v) surface autonomy fields in UTS rows.

Builds on: A.2 / A.2.1 / A.2.5 / A.15 / A.21; B.3; C.16; E.8; E.10; E.18; F.4; F.6; F.8; F.15; F.17. Coordinates with: A.13 (Agential Role), C.9 (Agency‑CHR), C.24 (Agent‑Tools‑CAL) where applicable; G.4–G.5–G.8–G.9–G.10 (method authoring/selection/shipping).

Autonomy‑claiming performers (RoleAssignments over services/robots/teams operating without continuous human direction) must stay within declared limits (safety, risk, resource, remit) and yield to governance when required. Without a uniform rule, “autonomy” drifts into tacit norms, cannot be benchmarked or audited, and undermines selection (Part G) and publication (Part F).

Keywords

  • autonomy budget
  • guarded enactment
  • autonomy ledger
  • override speech act
  • scout/probe/commit checkpoint.

Relations

E.16builds onThe Agential Role & Agency Spectrum
E.16builds onRole–Method–Work Alignment (Contextual Enactment)
E.16builds onGateProfilization: OperationalGate(profile) (GateFit core)
E.16builds onTrust & Assurance Calculus (F–G–R with Congruence)
E.16coordinates withAgentic Tool‑Use & Call‑Planning (C.Agent‑Tools‑CAL)
E.16coordinates withCAL Authoring: Calculi - Acceptance - Evidence
E.16coordinates withMulti‑Method Dispatcher & MethodFamily Registry
E.16coordinates withParity / Benchmark Harness
E.16explicit referenceRole Taxonomy
E.16explicit referenceU.RoleAssignment: Contextual Role Assignment
E.16explicit referenceU.RoleStateGraph: The Named State Space of a Role
E.16explicit referenceRole–Method–Work Alignment (Contextual Enactment)
E.16explicit referenceGateProfilization: OperationalGate(profile) (GateFit core)
E.16explicit referenceTrust & Assurance Calculus (F–G–R with Congruence)
E.16explicit referenceMM-CHR — Measurement & Metrics Characterization
E.16explicit referenceFPF Authoring Conventions & Style Guide
E.16explicit referenceLEX-BUNDLE: Unified Lexical Rules for FPF
E.16explicit referenceTransduction Graph Architecture (E.TGA)
E.16explicit referenceRole Description (RCS + RoleStateGraph + Checklists)
E.16explicit referenceRole Assignment & Enactment Cycle (Six-Step)
E.16explicit referenceMint or Reuse? (U.Type vs Concept-Set vs Role Description vs Alias)
E.16explicit referenceSCR/RSCR Harness for Unification
E.16explicit referenceUnified Term Sheet (UTS)
E.16explicit referenceThe Agential Role & Agency Spectrum
E.16explicit referenceAgency‑CHR
E.16explicit referenceAgentic Tool‑Use & Call‑Planning (C.Agent‑Tools‑CAL)
E.16explicit referenceCAL Authoring: Calculi - Acceptance - Evidence
E.16explicit referenceMulti‑Method Dispatcher & MethodFamily Registry
E.16explicit referenceSoS-LOG Bundles & Maturity Ladders
E.16explicit referenceParity / Benchmark Harness
E.16explicit referenceSoTA Pack Shipping (pack-boundary owner; SoTA-Pack(Core))
E.16explicit referenceNQD‑CAL — Open‑Ended Search Calculus
E.16explicit referenceExplore–Exploit Governor (E/E‑LOG)

Content

Problem Frame

Autonomy‑claiming performers (RoleAssignments over services/robots/teams operating without continuous human direction) must stay within declared limits (safety, risk, resource, remit) and yield to governance when required. Without a uniform rule, “autonomy” drifts into tacit norms, cannot be benchmarked or audited, and undermines selection (Part G) and publication (Part F).

Problem

  • Opaque autonomy. Patterns assert “autonomous” behavior with no budget or enforcement.
  • Un‑gated execution. Methods can execute beyond authority or risk limits.
  • Ad‑hoc overrides. No standard SpeechAct for pausing/de‑scoping; SoD is unclear.
  • Non‑portable publication. UTS (Unified Term Sheet) rows cannot surface autonomy‑critical data for parity or selection.

Forces

ForceTension
Creativity vs SafetyExploration autonomy vs hard constraints and override duties
Locality vs ComparabilityContext‑local rules vs cross‑context selection (G‑suite)
Simplicity vs AuditabilityLightweight authoring vs ledger‑grade evidence
Autonomy vs SoDHelpful self‑action vs separation‑of‑duties and human‑in‑the‑loop points

Bias-Annotation

Lenses tested: Gov, Arch, Onto/Epist, Prag, Did. Scope: Universal for any Role/Method/Service that claims autonomous operation (unsupervised decision or actuation) and is admitted via AutonomyBudgetDecl + Green‑Gate. It is not aimed at purely assistive “suggestion‑only” tools where each action is confirmed by a human at the point of execution.

  • Gov. Bias toward enforceable oversight (hard gates, SoD, canonical override SpeechActs). Mitigation: exploration autonomy is still allowed, but only inside an explicit budget and time window.
  • Arch. Bias toward gate‑and‑ledger structure (Green‑Gate + Work‑anchored AutonomyLedger). Mitigation: telemetrySpecRef can scope what is emitted when full deltas are unnecessary.
  • Onto/Epist. Bias toward typed, testable constraints (MM‑CHR tokens, explicit admissibility checks). Mitigation: budgets are optional‑field (?) so low‑risk contexts can start minimal and tighten over time.
  • Prag. Bias toward measurable quotas may under‑express “soft” autonomy goals. Mitigation: pair decision_tokens with risk_bands to capture non‑counting limits.
  • Did. Bias toward explicit mechanics increases authoring surface area. Mitigation: provide a default AutonomyBudgetDecl template and minimal harness cases in F.15.

Solution — Rule‑of‑Constraints (RoC) for Autonomy

This RoC applies whenever a Role/Method/Service claims autonomous operation (any phrasing that implies unsupervised decision or actuation).

E.16‑S1 (Autonomy Budget — mandatory). Any autonomy claim MUST publish an AutonomyBudgetDecl as a named, versioned object in the same U.BoundedContext:

AutonomyBudgetDecl {
  id, version
  scope: ClaimScope (G)                              // where this budget applies
  budget: {                                          // all typed via MM‑CHR (C.16)
    action_tokens?     : Unitful quota / rate
    decision_tokens?   : Unitful quota / rate
    risk_bands?        : CHR vector with acceptance bands
    resource_caps?     : set of unitful caps (Γ_work categories)
    time_window?       : Γ_time window & cadence
  }
  AdmissibilityConditionsId : PolicyIdRef                          // Aut-Guard policy naming gates & penalties
  overrideProtocolRef : Episteme                     // SpeechAct & SoD for pause/resume/escalate
  telemetrySpecRef? : Episteme                       // what to emit into AutonomyLedger
  editionPins : { RoleRef?, MethodDescRef?, CHR refs, …  } 
}

E.16‑S1.A (Scout / probe / commit partition for bounded specialization). When an autonomy-bearing method uses bounded specialization scouting, the budget declaration MUST keep scout budget, probe budget, and commit checkpoint as distinct control surfaces rather than collapsing them into one undifferentiated burn envelope. A successful probe does not by itself authorize a committed route, wider burn, or scope widening. Leaving probe state requires one explicit checkpoint decision through the declared guard or override path, with budget burn and residual budget recorded in the AutonomyLedger. E.16 owns this budget partition plus guard and ledger enforcement; it does not replace the dyadic move of A.15 or the CheckpointReturn plan semantics of C.24. E.16‑S2 (Guarded enactment — Green‑Gate). A Method step that requires autonomy MUST list requires: [RoleX] and requiresAutonomyBudget: AutonomyBudgetDecl.id. A Work instance is admissible iff at enactment time:

  • the performer’s RoleAssignment is valid and in an enactable RSG state (A.2.5);
  • the budget accounting for the AutonomyBudgetDecl indicates tokens/limits remaining for this budget in the declared Γ_time window (derived from the AutonomyLedger);
  • all guard checks defined by AdmissibilityConditionsId evaluate to pass (e.g., risk ≤ band, resource ≤ cap).

Failing any gate blocks enactment (no “soft warnings” on Core surface).

E.16‑S3 (Autonomy Ledger). All admissible Work MUST record AutonomyLedger entries:

AutonomyLedgerEntry {
  workId, performedBy: RoleAssignmentId
  budgetId, version, time
  deltas: { action_tokensΔ?, decision_tokensΔ?, riskΔ?, resourceΔ? }
  guardVerdicts: { name → pass|fail }
  pathIds: { PathId, PathSliceId }                  // for G‑suite parity/refresh
}

The ledger is evidence: attach to U.Work (A.15.1) and fold under Γ_work and Γ_time for reporting.

E.16‑S4 (Overrides — SpeechActs & SoD). Every budget MUST reference an OverrideProtocolRef that defines canonical SpeechActs:

  • PauseAutonomy(budgetId) — immediate stop of autonomy‑gated steps;
  • ResumeAutonomy(budgetId) — resume after conditions;
  • NarrowAutonomy(budgetId, Δscope) — apply stricter limits;
  • Escalate(budgetId) — handover to a declared SupervisorRole.

SoD: The override caller MUST NOT be the same RoleAssignment that is consuming the budget (enforce ⊥ in the Context). All overrides are Work (SpeechActs) with ledger entries (zero or negative deltas as per policy).

E.16‑S5 (Depletion behavior). When a budget depletes (no tokens / envelope exceeded / cap breached):

  • Block further autonomy‑gated steps in the same Γ_time window;
  • Emit DepletionNotice (SpeechAct), and either Escalate or Park per policy;
  • Only a ResumeAutonomy SpeechAct from an admissible Role (per SoD) may reopen the gate.

E.16‑S6 (Publication in UTS). UTS rows that describe a Role, Method, Service, or Selector with autonomy MUST include:

  • AutonomyBudgetDeclRef (id & version);
  • Aut-Guard policy-id (PolicyIdRef);
  • OverrideProtocolRef;
  • declared Scope (G) and Γ_time window;
  • edition pins for the referenced Role/Method/CHR.
  • (optional, if a scale preference is declared) ScaleLensPolicyRef and ScaleLensOptIn ∈ {OptedIn, Neutral, OptedOut}.

E.16‑S7 (Scale & selection — optional lens). When autonomy interacts with open‑ended search (C.18/C.19), budget consumption and guard violations are selection lenses in Part G (G.5/G.9). Applying a Scale‑Lens / Bitter‑Lesson preference is OPTIONAL. Authors MAY declare a ScaleLensPolicy for the autonomy claim; when declared, it MUST state:

  • Trigger criteria — evidence that expected utility‑of‑scale is monotonic/non‑saturating on held‑out tasks, and a threshold at which scaling beats structured heuristics.
  • Budget fit — compute/latency/cost targets within the declared AutonomyBudgetDecl (Γ_time, resource_caps).
  • Safety invariants — guards and SoD remain non‑weakened under scaling; no policy may bypass E.16 gates.
  • Fallback — a degrade‑gracefully plan if scaling fails to clear the trigger criteria within budget. If no ScaleLensPolicy is declared, selection remains neutral with respect to Bitter‑Lesson; RoC does not authorize ignoring scale‑safety guards under any policy.

Archetypal grounding (Tell‑Show‑Show; human‑centric)

Show‑A (U.System — mobile robot). Robot_R7#NavigatorRole:Warehouse_2026 executes Navigate_v3. AutonomyBudgetDecl: action_tokens=10 k steps/day, risk_bands={maxSpeed ≤ 1.2 m/s, minDist ≥ 0.5 m}, resource_caps={battery ≥ 20%}; AdmissibilityConditionsId=Aut‑Guard‑R7‑v1; override via PAUSE, RESUME, ESCALATE SpeechActs by FloorSupervisorRole ⊥ NavigatorRole. Ledger entries decrement action_tokens, track minDist. Depletion at 0 tokens halts autonomous moves and pages supervisor.

Show‑B (U.PromiseContent — autonomous deploy). DeployerRole performs step “Promote to prod” under AutonomyBudgetDecl with decision_tokens=3/day, risk_envelope={error‑budget burn ≤ 2% / day}, guard “all pre‑deploy checks pass”. Overrides only by CABChair#AuthorizerRole ⊥ DeployerRole.

Conformance Checklist (SCR — E.16‑CC)

IDRequirement
E.16‑CC‑1Any autonomy claim MUST reference an AutonomyBudgetDecl in the same U.BoundedContext.
E.16‑CC‑2Method steps that depend on autonomy MUST declare requiresAutonomyBudget: AutonomyBudgetDecl.id (and requires: [RoleX]) and MUST be Green‑Gated by the budget’s guards at enactment.
E.16‑CC‑3A Work admitted under autonomy MUST carry an AutonomyLedgerEntry with deltas and guard verdicts.
E.16‑CC‑4Overrides are SpeechActs with SoD enforced (⊥ between consumer and overrider roles); each override creates a ledger entry.
E.16‑CC‑5Depletion MUST block autonomy‑gated steps until a ResumeAutonomy SpeechAct passes SoD and guard checks.
E.16‑CC‑6UTS rows for autonomy‑bearing Roles/Methods/Services MUST include AutonomyBudgetDeclRef, Aut-Guard policy-id (PolicyIdRef), OverrideProtocolRef, Scope (G), and Γ_time.

| E.16‑CC‑7 | When bounded specialization scouting is in scope, scout budget, probe budget, and commit checkpoint MUST stay explicit, and a successful probe SHALL NOT count as automatic committed rollout. |

Consequences

  • Testability. Autonomy is measurable (tokens/envelopes), audit‑ready (ledger), and stoppable (SpeechActs).
  • Comparability. UTS surfaces autonomy metadata for fair selection & parity.
  • Safety. Guards are hard gates; depletion halts further autonomy‑gated Work.

SoTA‑Echoing (post‑2015 practice alignment)

Each item states Adopt / Adapt / Reject, and why. Vendor/tool tokens are kept as informative, not normative.

  1. Corrigibility & safe interruptibility (2016→).
    Adopt/Adapt. Work on safe interruption and “off‑switch” incentives argues that capable systems should remain stoppable and should not be rewarded for resisting oversight (Orseau & Armstrong, 2016; Hadfield‑Menell et al., 2017). E.16 adapts this into canonical PauseAutonomy / ResumeAutonomy SpeechActs plus SoD and hard gating on depletion.

  2. AI safety as concrete operational hazards (2016→).
    Adopt. “Concrete Problems in AI Safety” pushes instrumentation and testable safety constraints over informal assurances (Amodei et al., 2016). E.16 mirrors this by turning “autonomy” into a budget + ledger + guards contract that can be benchmarked and audited.

  3. SRE error budgets & “stop the line” operations (2016→).
    Adopt/Adapt. Error‑budget practice treats reliability as a measurable envelope that gates risky change when depleted (Beyer et al., Site Reliability Engineering, 2016; Höller et al., The Site Reliability Workbook, 2018). E.16 adapts the idea into risk_bands and depletion behavior that blocks autonomy‑gated steps until governed resume.

  4. Risk management frameworks for AI systems (2023→).
    Adopt/Adapt. Contemporary risk frameworks emphasize governance, continuous measurement, and traceable controls (NIST AI RMF 1.0, 2023; ISO/IEC 23894, 2023). E.16 adapts these into UTS publication + Work‑anchored ledger evidence for parity and audit.

  5. Policy‑as‑code and provenance gating (2019→).
    Adopt. Modern supply‑chain integrity systems emphasize policy‑checked actions with verifiable provenance (in‑toto, 2019→; SLSA, 2021→). E.16 echoes the same principle for autonomy: no autonomy‑gated enactment without passing declared guards and emitting ledger evidence (without importing any specific tooling).

  6. Scaling laws & the Bitter Lesson (2019→).
    Adapt/Reject. Empirical scaling work and the Bitter Lesson motivate considering compute‑heavy search when returns are monotonic (Sutton, 2019; Kaplan et al., 2020). E.16 adapts this into an optional ScaleLensPolicy (E.16‑S7) constrained by the same budgets and guards, and rejects any interpretation that lets “scale” bypass safety gates.

  7. Budgeted specialist acquisition and checkpointed exploitation (2024→). Adopt/Adapt. Recent agentic tool-use, self-play, and open-ended search lines reinforce that the competition variable is time or budget to threshold plus fast exploitation after a viable route is found. E.16 adapts this into distinct scout/probe/commit control surfaces and rejects any reading where early probe success authorizes rollout without an explicit checkpoint.

Common Anti-Patterns and How to Avoid Them

Anti-patternSymptomWhy it failsRepair
Autonomy-by-label“Autonomous” is claimed but there is no AutonomyBudgetDecl or ledgerAutonomy becomes opaque; cannot be audited or comparedRequire E.16‑S1/S3; reject publication without AutonomyBudgetDeclRef + version
Soft gatesBudget/guards only warn; enactment proceeds anywayViolates Safety and SoD; makes budgets non-enforceableMake Green‑Gate blocking on Core surface (E.16‑S2)
Self‑overrideSame RoleAssignment consumes the budget and calls Resume/NarrowConflict of interest; SoD collapseEnforce ⊥ between consumer and overrider (E.16‑S4)
Budget bypass via “scale”Scaling preference weakens guards or ignores capsUndermines declared limits; breaks comparabilityIn ScaleLensPolicy, guards/SoD must remain non‑weakened (E.16‑S7)
Untyped quotasTokens/caps are recorded without units, or units are mixedLedger becomes non-comparable; audits become meaninglessType budgets and deltas via MM‑CHR (C.16); keep unitful rates/quotas
Ledger-as-loggingLogs exist but are not Work‑anchored (no workId/budgetId/version/pins)Evidence is non-portable; cannot support parity/refreshRequire AutonomyLedgerEntry attached to U.Work with ids, versions, and edition pins

Rationale & E‑/F‑/G‑links

  • E.8 — follows the pattern template (Context → Problem → Forces → Solution → Grounding → CC → Consequences).
  • E.10 — uses LEX‑BUNDLE: Scope via ClaimScope (G), time via Γ_time, no “validity/process/actor/agent‑as‑noun” language; new lexical rule L‑AUTO added in edits below.
  • Mint/reuse authority (policy-ids). Mint/reuse authority is expressed via F.8:8.1 (PolicyIdRef: PolicySpecRef + MintDecisionRef?) and explicit GateCrossing checks (E.18) evaluated by the active GateProfile/GateFit (A.21); no tier ladder is required.
  • Part F — integrates with F.4 Role Description (RCS includes AgencyLevel; RSG gates), F.6 Role Assignment & Enactment (Green‑Gate), F.15 SCR/RSCR (harness includes depletion/override tests), F.17 UTS (columns, incl. optional ScaleLens fields).
  • Part G — G.4/G.5: method authors must declare budgets & guards; G.9 parity includes autonomy consumption & violations; G.10 shipping requires UTS autonomy fields.

Mini conformance checklist (cross‑E–F; author’s quick use)

  1. Declare AutonomyBudgetDecl (scope, budgets, AdmissibilityConditionsId, overrides).
  2. Gate steps with requiresAutonomyBudget.
  3. Emit an AutonomyLedgerEntry for each admitted Work.
  4. Enforce SoD on override SpeechActs; block on depletion.
  5. Publish UTS autonomy fields for any autonomy‑bearing Role/Method/Service.

(These five are sufficient for a working test harness in Part F.)

E.16:End