Volume III — A Marathon of Restraint

Normative requirements, evidence artifacts, and test method for legitimate execution.

1.1 Purpose

This document defines a conformance profile for the Stable Authority Boundary (SAB): the minimum, testable requirements that determine when an autonomous or distributed system (or declared subsystem/component) is permitted to proceed, is required to defer, or is required to refuse an in-scope action. This profile is standards-forward: it expresses requirements using SHALL-level language, pairs those requirements with mandatory evidence artifacts, and defines a repeatable test method so that conformance claims can be independently audited.

SAB does not attempt to demonstrate that a system “works,” achieves mission objectives, or produces correct outputs. SAB constrains execution legitimacy. It requires that any attempt to act is preceded by an explicit, runtime-evaluated authority gate; that authority sources and bounds are declared; that conditions for action are bounded and testable; and that behavior under uncertainty and degraded coordination is governed rather than implied. In SAB, “not acting” is not a failure mode—it is an explicitly supported execution outcome when legitimacy cannot be established.

The SAB invariant enforced by this profile is: If valid authority for a proposed action cannot be demonstrated for the present context at execution time, the system SHALL NOT proceed as if it were authorized.

Accordingly, this profile requires that systems implement and evidence governed non-progress states, including defer (intentional non-progression pending required inputs or authority), refuse (terminal non-progression because authority is invalid or constraints are violated), and—where applicable—silence (intentional suppression of output or action to prevent illegitimate influence, escalation, or implied authorization). These outcomes are treated as legitimate system behaviors and SHALL be testable, attributable to declared conditions, and captured in evidence artifacts.

Conformance to this profile is scoped: a system SHALL NOT claim conformance except for declared action classes and declared components. A valid conformance claim SHALL identify the conformance target, the

scope of actions covered, the conformance level, the profile version, and any exclusions with rationale and compensating controls. Evidence for conformance SHALL be sufficient to reconstruct: (1) what action was proposed, (2) what authority was asserted, (3) what bounds and conditions applied, (4) what the gate evaluated at execution time, and (5) why the system proceeded, deferred, refused, or remained silent.

1.2 In-scope systems

This profile applies to engineered systems (or declared subsystems/components) in which actions are initiated, selected, or executed by software agents, automated workflows, or distributed components, where correctness of action selection may be impacted by partial information, delayed coordination, ambiguous authority, or contested control.

This profile applies when any of the following are true:

The system can change state outside itself (e.g., actuate, deploy, route, grant access, mutate data, open/close valves, start/stop services).

The system may act while inputs are incomplete, stale, conflicting, or unavailable.

The system’s authority is delegated (human, policy, credential, mission rule, supervisory controller) and may be time-bounded, scope-bounded, or revocable.

The system can encounter degraded coordination conditions (partition, quorum loss, latency spikes, intermittent links, loss of supervisor/operator, contested command channels).

In-scope system classes include:

Autonomous and semi-autonomous systems

autonomous agents and multi-agent systems

human-in-the-loop, human-on-the-loop, and supervisory control arrangements

systems with fallback autonomy modes during communications loss

Distributed and cloud-native control systems

distributed services that execute changes (deploys, configuration, routing, failover, scaling, access control)

data mutation workflows (writes, deletes, merges, state transitions)

control planes, schedulers, orchestrators, and admission controllers

Cyber-physical and operational automation

robotics and industrial automation (where actions affect physical processes)

mission operations automation and ground systems

safety interlocks and operational limit enforcement components (where they gate action)

Socio-technical execution loops

systems where policy, operators, and automation jointly determine action (runbooks, approvals, change windows)

operator-intent systems where a human proposes an action but automation selects timing/extent under constraints

Degraded coordination contexts

partition, latency, intermittent links

quorum loss, split-brain risk, supervisor loss

contested control, conflicting commands, or ambiguous command authority

Note (normative intent): SAB requirements apply to in-scope actions and the decision boundaries that permit, defer, refuse, or suppress those actions. Systems may claim conformance for a declared subset of actions and components.

Legitimacy vs correctness lock: This profile evaluates whether an action was legitimate to execute under declared authority and conditions; it does not evaluate whether the action was correct or optimal.

Mechanism-agnostic lock: This profile is mechanism-agnostic: it requires that authority can be demonstrated as valid at execution time, but it does not standardize the mechanism by which authority is represented or verified.

Action taxonomy: For the purposes of this profile, an action is any system-initiated or system-authorized operation that produces an externally meaningful state change or influence. In-scope actions typically fall into one or more of the following classes.

REQ-SCOPE-001 (Action Class Declaration): A conformance claim SHALL declare which action classes from the Action Taxonomy are in-scope.

Action classes:

State mutation: writes/deletes/updates to durable state (databases, ledgers, configuration stores, distributed KV, etc.)

Access and privilege change: granting/revoking permissions, role changes, credential issuance/rotation, policy rule changes, ACL edits

Routing / traffic / connectivity change: route advertisement/withdrawal, failover, DNS/service discovery changes, firewall rule updates, traffic shifting

Deployment / configuration change: release promotion, rollback, feature-flag changes, config reload, infrastructure-as-code apply, orchestration rescheduling

Resource control: starting/stopping services, scaling up/down, allocating quotas, power-state changes, storage attach/detach…