Scope
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
External actuation: commands to physical devices or cyber-physical systems (robots, valves, motors, relays, spacecraft subsystems)…