Autonomy Boundaries
Explicit limits on delegated authority, mission scope and permissible action.
Domain controls
The following identifiers, titles, objectives and implementation expectations reproduce the canonical public PAI-SF™ v1.0 Control Catalogue. Evidence requirements, assurance expectations, dependencies, exclusions and conformance relevance remain available in the full catalogue.
Objective: Ensure the system's authorized autonomy level is explicit and cannot be escalated without an authenticated, logged authorization process. Requirement: Discrete autonomy levels defined with explicit authorization criteria for each; escalation between levels requires an authenticated approval step distinct from routine operational commands.
Objective: Ensure the operational design domain (ODD) is maintained as a version-controlled specification with change-control, not a static one-time document. Requirement: Changes to the ODD (geography, weather envelope, task scope) trigger a defined revalidation process before the change takes effect; ODD maintained with version history.
Objective: Ensure autonomy boundary enforcement is graduated (warning/restricted/prohibited zones) rather than a single binary safe/unsafe response. Requirement: At least three zones defined (warning, restricted, prohibited), each with a distinct response — operator alert, autonomy reduction, hard stop — rather than one shared response.
Objective: Prevent ambiguous or contested control state during handoff between autonomous, human, and reduced-autonomy modes. Requirement: Handoff requires explicit, authenticated confirmation of which controller holds command authority at any instant, preventing a state where both or neither believe they are in control.