Internet Engineering Task Force T. Sato Internet-Draft MyAuberge K.K. Intended status: Standards Track 4 September 2026 Expires: 4 March 2027 The Agent Orchestration Protocol (AOP) for Agentic AI Systems draft-sato-soos-aop-02 Abstract A single AI agent acting within a governed session is not the hardest governance problem. The hardest problem is what happens when that agent must delegate: when the mission is too large for one agent, when sub-tasks require specialized capability, when parallel execution is necessary, and when each delegated sub-agent is itself consequential enough to require governance. Who authorized the spawn? Who owns the plan? If the sub-agent deviates, who decides whether to re-plan or escalate? If the mission fails mid-execution, who constructs the audit record? This document defines the Agent Orchestration Protocol (AOP): the normative protocol through which a governed orchestrating agent decomposes a mission into a governed sub-goal directed acyclic graph (DAG), delegates sub-goals to sub-agents via kernel-mediated Assignment Primitives, and maintains a Mission Plan Sovereign Object (Mission Plan SO) and Mission Status SO across the full lifecycle of multi-agent execution. AOP specifies three core constructs: the Expected Outcome Declaration (EOD) as the pre-commitment structure for the full mission and each delegated sub-goal; the Mission Plan SO encoding the sub-goal DAG with SEQUENTIAL, PARALLEL, and CONDITIONAL dependency types; and the Assignment Primitive as the governed handoff mechanism that requires an Endorsed EOD and produces a Sub-Agent Composition Record (SACR) per the Multi-Agent Delegation protocol. AOP integrates with the Intent Declaration Primitive at each EOD boundary, the Agent Execution Protocol for per-agent session governance, the Governance Audit Record for mission lifecycle audit events, and the Human Escalation Mechanism for re-planning authority escalation. The normative reference scenario for AOP is a three-tier emergency management orchestration system in which a Master AI orchestrates regional coordination agents, which orchestrate domain-specialist leaf agents (e.g., evacuation routing models), each tier operating under full SOOS governance. Version -01 completed the document body: the Expected Outcome Declaration in AOP Context, Mission Plan Sovereign Object, Mission Status Sovereign Object, Assignment Primitive, Re-planning Authority, AOP-to-GAR Integration, Five-Phase Planning Intelligence Model, and the Reference Scenario were placeholders in -00 and are now fully specified, resolving a three-way contradiction in -00 about whether Sub-Goal EOD endorsement happens before or after SACR issuance (it is after, gated on SACR existence). Version -02 fixes a document-structure ordering defect carried over from -00, closes -00's open Denial of Service gap with new normative security guidance, and corrects a set of reference-list defects: two normatively cited documents were never defined in the reference list, and ten companion-draft citations in the Related Work discussion used one-off versioned reference keys that matched no defined entry; all now cite consistently and are updated to current SOOS suite versions. The Related Work discussion's own description of Mission Plan SO / Mission Status SO ownership is corrected to match this document's own Introduction and current reality: both subtypes are defined by AOP, not by SOV. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 4 March 2027. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Table of Contents 1. Introduction 1.1. Use Case: Multi-Agency Emergency Response Orchestration 1.2. Use Case: Travel Booking Orchestration 1.3. Use Case: Enterprise Procurement Workflow 1.4. Relationship to Adjacent SOOS Drafts 2. What AOP Is and Is Not 2.1. What AOP Does 2.2. What AOP Does Not Do 2.3. Division of Labor 2.4. The Air Traffic Control Analogy 3. How AOP Works 3.1. Use Case Walk-Through: Compliance Perspective 3.2. Use Case Walk-Through: Regulator/Investigator Perspective 3.3. Use Case Walk-Through: Operator/Deployer Perspective 3.4. Use Case Walk-Through: Cross-Tier Edge Scenario 4. Conventions and Definitions 5. Architecture Overview 5.1. AOP Position in the SOOS Stack 5.2. The Three-Tier Orchestration Model 5.3. Mission Plan SO as the Governance Center 5.4. SACR Issuance Flow 6. Expected Outcome Declaration (EOD) in AOP Context 6.1. Mission-Level EOD 6.2. Sub-Goal EOD 6.3. PD-EOD Path in Multi-Agent Context 6.4. E-EOD Path in Multi-Agent Context 7. Mission Plan Sovereign Object 7.1. Sub-Goal DAG Structure 7.2. Dependency Types: SEQUENTIAL, PARALLEL, CONDITIONAL 7.3. Deadline Tracking and Critical Path 8. Mission Status Sovereign Object 8.1. Live Execution State 8.2. AT_RISK Detection 8.3. Historical Pattern Integration 9. Assignment Primitive 9.1. Purpose and Design 9.2. Assignment Schema 9.3. Assignment Issuance Procedure 9.4. MAD Integration 10. Re-planning Authority 10.1. Autonomous Re-planning Bounds 10.2. HEM Escalation Triggers 10.3. ALE-051 and ALE-052 Definitions 11. AOP-to-GAR Integration 11.1. Mission Lifecycle ALE Types (ALE-042 Through ALE-055) 11.2. Session Block at Mission Close 12. Five-Phase Planning Intelligence Model 12.1. Phase 1: Mission Framing 12.2. Phase 2: Sub-Goal Decomposition 12.3. Phase 3: Assignment Execution 12.4. Phase 4: Mid-Flight Monitoring 12.5. Phase 5: Mission Closure and Learning 13. Reference Scenario: Three-Tier Emergency Management Orchestration 14. Open Issues 15. Security Considerations 15.1. Hub Compromise Blast Radius 15.2. Recursive Spawn Depth-Limit Bypass 15.3. EOD Scope Inflation Across Delegation 15.4. Standing Plan Hijack 15.5. Unverified Self-Declared Risk Forcing a Re-planning Action 15.6. Denial of Service (NEW in -02) 16. Privacy Considerations 17. IANA Considerations 17.1. Mission Plan SO Media Type 17.2. Assignment Primitive Media Type 17.3. Mission ALE Type Registrations (ALE-042 Through ALE-055) 18. References 18.1. Normative References 18.2. Informative References Appendix A. Worked Example: Three-Tier Emergency Management Orchestration Appendix B. Related Work B.1. Existing Orchestration Frameworks B.2. Regulatory Instruments B.3. SOOS Companion Drafts Appendix C. Changes from Previous Versions (NEW in -02) C.1. Changes from draft-sato-soos-aop-01 C.2. Changes from draft-sato-soos-aop-00 Author's Address 1. Introduction Governing a single AI agent is a solved problem in principle: you give it a mandate, you enforce Cedar policy on each action, you log every transition, and you surface exceptional states to a human. The SOOS protocol suite specifies how to do this normatively. But most consequential AI deployments are not single-agent systems. When a disaster strikes and an AI system must coordinate evacuation routing, shelter allocation, and inter-agency data sharing simultaneously, no single agent can execute all of it. When an enterprise procurement system must query supplier APIs, validate inventory, confirm budget authority, and issue purchase orders across separate authorization domains, a flat single-agent model breaks down. When a travel booking agent must negotiate itineraries across airlines, hotels, and activity providers in parallel, each of which may have its own SOOS-governed API endpoint, sequential single-agent execution is insufficient. What these scenarios share is the need for orchestration: a governing agent that decomposes a complex mission into sub-goals, delegates each sub-goal to a specialized sub-agent, and tracks the overall mission to completion -- while preserving the accountability properties that make the system governable. The governance problem with orchestration is not how to spawn sub- agents. Existing frameworks (LangGraph, CrewAI, AutoGen) can spawn sub-agents. The governance problem is: (a) Pre-commitment. The orchestrating agent must declare what it intends to achieve, for the whole mission and for each sub-goal, before any sub-agent executes. Without this, deviation cannot be distinguished from intention. (b) Delegation integrity. Each sub-agent must receive only the scope it needs, not the scope the orchestrator has. The narrowing property [I-D.sato-soos-mad] must be enforced at the kernel level, not at the application level. (c) Plan ownership. The Mission Plan -- the sub-goal DAG with dependency types, deadlines, and critical-path annotations -- must be a Sovereign Object: governed, versioned, and auditable. An ephemeral in-memory plan is not governable. (d) Re-planning authority. When a sub-goal fails and the orchestrating agent must deviate from the original plan, the authority to re-plan must be explicitly granted, bounded, and auditable. Unlimited autonomous re-planning is ungoverned orchestration under a different name. (e) Audit completeness. The full mission lifecycle -- from Mission Open to Mission Close -- must produce an unbroken chain of GAR-signed audit events, such that an investigator with only the audit record can reconstruct what was planned, what was executed, and where the two diverged. This document defines the Agent Orchestration Protocol (AOP). AOP provides the normative framework for all five properties above. AOP is not an agent framework. It is the governance overlay that makes an agent framework governable. 1.1. Use Case: Multi-Agency Emergency Response Orchestration An earthquake triggers a regional emergency. A regional emergency management agency activates its AI-governed response system. A Master AI agent -- operating under a GOLD-tier Standing Plan pre- authorized by the agency duty officer -- receives a MissionDeclaration from the human incident commander. The mission: coordinate evacuation routing for three affected districts, allocate shelter capacity across available municipal facilities, and provide real-time situation reports to regional command every 15 minutes. The Master AI submits a Mission-Level EOD to the GEC: primary_outcome is a structured target describing the evacuation status target state. The EOD includes a Plan B declaring that if the primary routing sub-goal fails (e.g., infrastructure damage prevents road data access), the Master AI will fall back to a pre-computed static routing plan from the Standing Plan Object (SPO). The GEC endorses the EOD (intake_endorsement per [I-D.sato-soos-idp] Section 4.6) and creates the Mission Plan SO. The Mission Plan SO encodes a DAG: three PARALLEL sub-goals (one per district), each containing SEQUENTIAL sub-goals for routing, shelter allocation, and reporting. The Master AI issues Assignment Primitives to three Local AI agents (district-level), each carrying an Endorsed Sub-Goal EOD with scope constrained to a single district. The GEC issues a SACR for each Local AI per [I-D.sato-soos-mad] Section 4. Each Local AI, in turn, issues an Assignment Primitive to a Simulation AI (evacuation routing model), again with a further- constrained Sub-Goal EOD. The GEC issues a second-tier SACR. max_spawn_depth at this tier is 0: Simulation AIs are leaf agents and cannot further delegate. The Master AI's Mission Status SO tracks AT_RISK signals across all three districts. In District 2, the Simulation AI detects that its evacuation model output is inconsistent with real-time sensor data that was unavailable at Assignment time; holding replan_authority: NONE, it submits a GOAL_AT_RISK_DECLARED transition, and the GEC sets the Mission Status SO to AT_RISK for sub-goal district2-routing, notifying District 2's Local AI. The Local AI's own replan_authority is BOUNDED: it activates the pre-declared Plan B (static routing) from its own Sub-Goal EOD without HEM escalation. It does so, emitting ALE-052 (REPLAN_BOUNDED_ACTIVATED) to GAR. At mission close, the GEC constructs a Session Block covering the full mission lifecycle: every SACR, every Assignment, every EOD, every AT_RISK event, and every re-plan decision -- signed with the GEC keypair and committed to the GAR. AOP provides the governance structure for all of this. The existing SOOS drafts (AEP, IDP, MAD, GAR, HEM) each govern their own layer. AOP is the protocol that makes them compose. 1.2. Use Case: Travel Booking Orchestration MyAuberge K.K. operates a boutique hotel and organic farm (Ponyhouse Farm) in Chino, Nagano, Japan. The MyAuberge ATP (Activity Travel Protocol) booking agent handles multi-component itinerary construction: accommodation, farm activities (horse trekking, harvest participation), transport coordination, and regional culinary reservations. A guest submits a natural-language request: "Plan a three-night stay in August with horse trekking and a kaiseki dinner. I am traveling with two children." The booking agent receives the request and constructs a PD-EOD (Prompt-Derived EOD per [I-D.sato-soos-idp] Section 4.7): derived: true, scope-bounded to the MyAuberge SO Type ATP_TRAVEL_ITINERARY, with acceptance envelope conditions covering confirmed accommodation availability, confirmed trekking slots, and restaurant reservation. The GEC endorses the PD-EOD and creates a Mission Plan SO. The DAG has three PARALLEL sub-goals (accommodation, activities, dining) and one SEQUENTIAL sub-goal (transport, which must be resolved after accommodation to determine arrival station). The booking agent issues Assignment Primitives to: (a) the Ponyhouse Farm availability sub-agent (SACR issued, scope: read SO Type ATP_FARM_ACTIVITY, no write); (b) the regional dining sub-agent (SACR issued, scope: read SO Type ATP_RESTAURANT_AVAILABILITY); (c) the accommodation sub-agent (SACR issued, scope: read/write SO Type ATP_ACCOMMODATION_BOOKING). The transport sub-agent Assignment is held by the Mission Plan CONDITIONAL dependency: it is only issued once accommodation sub-goal is GOAL_ACHIEVED. This is the ATP reference implementation of AOP: three-party governed orchestration across Ponyhouse Farm as a reference supplier, the booking agent as orchestrator, and the guest mandate as the root authority. 1.3. Use Case: Enterprise Procurement Workflow A procurement orchestration agent is authorized by an enterprise finance officer to execute a purchase order for IT equipment across three suppliers. The mandate scope permits commitment up to 5,000,000 JPY with Cedar attributes encoding the budget ledger SO. The orchestrating agent decomposes the mission into sub-goals: supplier quote collection (PARALLEL, three suppliers), quote comparison and selection (SEQUENTIAL, after all quotes received), and purchase order issuance (SEQUENTIAL, after selection approval). The quote comparison sub-goal has a CONDITIONAL dependency on a HEM-mediated human approval gate: if any individual quote exceeds 2,000,000 JPY, the Cedar policy for the selection sub-agent will DENY autonomous selection and emit HEM-ESCALATE, surfacing the decision to the finance officer. This use case illustrates AOP's integration with HEM: re-planning authority is not always exercised autonomously. The Mission Plan SO can encode mandatory human checkpoints as CONDITIONAL sub-goal dependencies with HEM activation conditions. 1.4. Relationship to Adjacent SOOS Drafts AOP is the highest-layer protocol in the SOOS governance stack. It depends on and integrates with: AEP [I-D.sato-soos-aep]: AOP uses the AEP session lifecycle for each individual agent session within the mission. The Master AI and each sub-agent each run their own AEP loop. AOP adds the Mission Plan SO as the coordinating structure above individual AEP sessions. IDP [I-D.sato-soos-idp]: AOP requires an Endorsed EOD (produced via IDP intake_endorsement, Section 4.6) before any Assignment Primitive is issued. PD-EOD (Section 4.7) is the normative path for missions derived from natural-language prompts. E-EOD is the normative path for missions derived from structured operator input. MAD [I-D.sato-soos-mad]: AOP uses MAD's Sub-Agent Composition Record (SACR, Section 4) as the kernel-mediated spawn mechanism for each Assignment. The hub-only constraint (MAD Section 5) applies to all sub-agents spawned under AOP unless explicitly overridden. The R-1 through R-7 revocation trigger classes (MAD Section 7) govern sub-agent revocation within AOP missions. GAR [I-D.sato-soos-gar]: AOP defines mission lifecycle ALE types ALE-042 through ALE-055, which GAR records as part of the Session Block at mission close. HEM [I-D.sato-soos-hem]: AOP escalates to HEM when re-planning exceeds BOUNDED authority (REPLAN_ESCALATED). HEM resolution produces a new Endorsed EOD or a MISSION_ABORT instruction. KEE-1 [I-D.sato-soos-kee]: All AOP operations execute within a KEE-1 conformant kernel. The XPID derivation function (KEE-1 Section 10) produces the ephemeral XPID for each sub-agent at SACR issuance time. The GEC Manifest immutability property (KEE-1 P5) ensures the Mission Plan SO cannot be altered outside the GEC's signed event stream. SOV [I-D.sato-soos-sov]: The Mission Plan SO and Mission Status SO are SO subtypes defined by AOP. The Standing Plan Object (SPO) referenced in EOD Plan B declarations is a SOV-02 subtype normatively defined in [I-D.sato-soos-sov]. CAP [I-D.sato-soos-cap]: Cedar evaluation governs each SACR issuance and each Assignment. The DeclareMission, IssueChildMission, and EvaluateEOD Cedar actions are defined in this document and registered in the Cedar action namespace. 2. What AOP Is and Is Not 2.1. What AOP Does AOP specifies the governance layer for multi-agent orchestration within a SOOS-governed system. Concretely, AOP: (a) Defines the Mission-Level EOD and Sub-Goal EOD as pre-commitment structures that must be endorsed by the GEC before any sub-agent is spawned. (b) Defines the Mission Plan SO as the Sovereign Object encoding the sub-goal DAG, including dependency types, deadline tracking, and critical-path annotation. (c) Defines the Mission Status SO as the live execution state maintained by the GEC, updated at each sub-goal state transition, and used for AT_RISK detection. (d) Defines the Assignment Primitive as the normative handoff mechanism from orchestrating agent to sub-agent, requiring an Endorsed EOD and producing a SACR. (e) Defines re-planning authority levels (NONE, BOUNDED, AUTONOMOUS) and the HEM escalation trigger for out-of-bound re-planning. (f) Defines mission lifecycle ALE types ALE-042 through ALE-055 for GAR recording. 2.2. What AOP Does Not Do AOP does not specify the internal reasoning mechanism of the orchestrating agent or any sub-agent. The REASON step of each AEP loop is opaque to AOP, as it is opaque to AEP. AOP does not specify agent capability discovery. Resource discovery is handled by the Resource Gateway Protocol [I-D.sato-soos-rgp]. AOP receives the results of resource discovery as inputs to Assignment Primitive construction. AOP does not specify inter-agent communication formats or messaging protocols beyond the Assignment Primitive and Mission Status SO update interface. Agent-to-agent messaging within a hub-only topology flows through the GEC; AOP specifies the governance constraints on that flow, not the message encoding. AOP does not replace the SOOS stack's per-layer protocols. Each AEP session within a mission remains fully AEP-governed. Each IDP remains fully IDP-governed. AOP is the protocol that makes the SOOS stack compose across agent boundaries, not a replacement for any layer within it. 2.3. Division of Labor Multi-agent orchestration under AOP involves four principals: (1) The Mission Principal. The human (or automated operator with human-delegated authority) who issues the MissionDeclaration and the root mandate. Responsible for the E-EOD in human-initiated missions, or for reviewing the GEC-derived PD-EOD before the GEC's intake_endorsement is issued. (2) The Orchestrating Agent. The AI agent that holds the Mission Plan SO, issues Assignment Primitives, and monitors the Mission Status SO. Operates within BOUNDED or AUTONOMOUS re-planning authority as declared in its SACR. NOT authorized to spawn sub- agents without GEC-mediated SACR issuance. (3) The Governing Enforcement Component (GEC). Endorses EODs, issues SACRs, enforces scope-narrowing at each spawn, maintains the Mission Status SO, records all ALE events to GAR, and constructs the Session Block at mission close. (4) The Audit Principal. Reviews the GAR mission lifecycle record after mission close. Can reconstruct the full sub-goal DAG execution history, every re-planning decision, and every HEM escalation from the GAR record alone. 2.4. The Air Traffic Control Analogy AOP's relationship to multi-agent execution is analogous to air traffic control's relationship to aircraft. ATC does not fly aircraft. It does not specify how the plane's engines work. It does not determine the passenger manifest. What ATC does is: assign routes, manage separation, identify conflicts before they become collisions, and ensure that every aircraft in controlled airspace is known and tracked. AOP does not run agents. It does not specify the LLM reasoning engine. It does not determine the agent's capability set. What AOP does is: declare missions, govern spawning, track sub-goal state, detect AT_RISK conditions before they become failures, and ensure that every sub-agent operating within a mission is known, scoped, and auditable. When an aircraft deviates from its assigned route, ATC has a defined escalation procedure: query, instruct, escalate to supervisor. When a sub-agent deviates from its sub-goal EOD, AOP has the equivalent: AT_RISK detection, BOUNDED re-plan, REPLAN_ESCALATED to HEM. 3. How AOP Works 3.1. Use Case Walk-Through: Compliance Perspective A legal counsel reviewing an enterprise AI procurement system for EU AI Act Article 22 compliance asks: "How can I verify that every sub-agent in this orchestrated workflow operated within its authorized scope and that no sub-agent was spawned without a governance record?" In an AOP-governed system, the answer is: read the GAR session record. The Mission Open event (ALE-042) carries the Mission Plan SO identifier and the root EOD. Every SACR issuance (ALE-043) carries the sub-agent's scope_constraints, ephemeral_kia_ref, and the sacr_id. Every Assignment (ALE-044) carries the sub-goal EOD and the sacr_id it was issued under. The Mission Close event (ALE-055) carries the EOD_OUTCOME for every sub-goal: MATCHED, PARTIAL, PLAN_B_MATCHED, or UNMATCHED. A sub-agent that operated outside its scope_constraints would appear as a Cedar DENY in its own AEP session record. A sub-agent that was spawned without a SACR would create a gap in the GAR mission record detectable by audit. CONF-AOP-AUDIT-01 (Section 9.3) requires that every Assignment Primitive carry a valid sacr_id referencing a committed SACR record. 3.2. Use Case Walk-Through: Regulator/Investigator Perspective A regulator reviewing an emergency management AI system asks: "The evacuation routing sub-goal for District 2 was replaced mid-mission with a static routing plan. Who authorized this, on what basis, and what was the audit trail?" In an AOP-governed system, the investigator reads the GAR record for ALE-052 (REPLAN_BOUNDED_ACTIVATED) on the District 2 routing sub-goal. The ALE carries: the Mission Status SO state at AT_RISK detection (including the specific sub-goal ID and the failure condition that triggered AT_RISK); the Plan B declaration from the original Mission-Level EOD (specifying the static routing fallback and its pre-authorized activation conditions); the GEC timestamp at which Plan B was activated; and the BOUNDED re-planning authority declared in the Master AI's SACR. The investigator can verify: the re-plan was within pre-authorized bounds (BOUNDED, not AUTONOMOUS); the activation conditions were satisfied (road data unavailable); the Plan B action matched the pre-declared plan_b in the EOD exactly; and no HEM escalation was required because the conditions matched the pre-authorization. The compliance record required by applicable disaster management recordkeeping obligations is the GAR mission lifecycle. AOP provides the structure that makes that record complete. 3.3. Use Case Walk-Through: Operator/Deployer Perspective A system integrator deploying AOP on behalf of a regional disaster management agency asks: "How do I configure the re-planning authority levels for a Master AI that must be able to adapt quickly to changing field conditions but cannot commit to actions outside a pre-approved budget?" The operator configures the Master AI's SACR with replan_authority: BOUNDED. The scope of BOUNDED authority is declared in the Mission-Level EOD: specific sub-goals that may be replaced (e.g., routing sub-goals), specific replacement options (pre-computed static plans from the SPO), and the Cedar attribute conditions under which each replacement is permitted. Sub-goals outside the BOUNDED bounds -- for example, adding a new district to the mission scope, or authorizing expenditure beyond the pre-declared resource_envelope -- would require REPLAN_ESCALATED and HEM resolution. The operator knows, before deployment, exactly which scenarios will require human authorization and which will not. This is the central property of BOUNDED re-planning authority. 3.4. Use Case Walk-Through: Cross-Tier Edge Scenario A Simulation AI (leaf agent, max_spawn_depth: 0, replan_authority: NONE) detects that its evacuation model is producing outputs inconsistent with real-time sensor data. The sensor data was not available at Assignment time. The Simulation AI cannot re-plan (NONE authority), cannot spawn sub-agents (max_spawn_depth: 0), and cannot directly contact the Master AI (hub_only: true). The normative behavior is defined by AOP Section 10.1: the Simulation AI MUST submit a GOAL_AT_RISK_DECLARED IDP transition to the GEC with the specific inconsistency encoded in the transition payload. The GEC updates the Mission Status SO for the affected sub-goal to AT_RISK, emits ALE-048 (SUB_GOAL_AT_RISK), and notifies the parent Local AI via the hub-only routing path. The Local AI, which has BOUNDED re-planning authority, evaluates whether the AT_RISK condition triggers a pre-declared Plan B. If no Plan B covers this condition, the Local AI emits REPLAN_ESCALATED to its parent (the Master AI via hub routing). The Master AI evaluates its own re-planning authority. If the Master AI also has no BOUNDED option covering this condition, REPLAN_ESCALATED propagates upward to HEM, surfacing the decision to the Mission Principal (the human incident commander). No agent in this chain acted outside its declared authority. The audit record (ALE-048, ALE-052 or ALE-053 as applicable) captures the full escalation path. 4. Conventions and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. Agent Orchestration Protocol (AOP): This document. The normative protocol governing multi-agent mission decomposition, sub-goal DAG management, Assignment Primitive issuance, and mission lifecycle audit in SOOS-governed systems. Mission: A composite task assigned to an orchestrating agent that requires decomposition into sub-goals and delegation to one or more sub- agents. A mission is initiated by a MissionDeclaration and tracked via a Mission Plan SO for its full lifecycle. MissionDeclaration: The structured input from the Mission Principal that initiates an AOP mission. A MissionDeclaration MUST carry: the Mission Principal's identity (MJWT jti); the root mandate reference; and either a structured E-EOD or sufficient natural-language input to derive a PD-EOD. Mission Plan Sovereign Object (Mission Plan SO): A Sovereign Object [I-D.sato-soos-sov] encoding the sub-goal DAG for a mission. The Mission Plan SO is created by the GEC at Mission Open and is the authoritative record of the orchestrating agent's decomposition of the mission. Mission Status Sovereign Object (Mission Status SO): A Sovereign Object encoding the live execution state of a mission. Maintained by the GEC. Updated at each sub-goal state transition. Used for AT_RISK detection and historical pattern integration. Sub-Goal: A bounded task within a Mission that is assigned to a single sub-agent via an Assignment Primitive. A sub-goal has its own EOD, its own SACR, and its own AEP session. Sub-goals compose to form the sub-goal DAG in the Mission Plan SO. Sub-Goal DAG: The directed acyclic graph of sub-goals in a Mission Plan SO. Each node is a sub-goal. Edges encode dependency types. The DAG is acyclic: a sub-goal MUST NOT depend on itself or on a descendant sub-goal. Assignment Primitive: The normative handoff from an orchestrating agent to a sub-agent. An Assignment Primitive MUST carry: a reference to a committed SACR; a Sub-Goal EOD (Endorsed); the sub-goal identifier in the Mission Plan SO; and the GEC-issued ephemeral_kia_ref. Mission Principal: The human or operator entity that issues the MissionDeclaration and holds the root mandate for the mission. The Mission Principal is the top of the authority chain that governs re-planning and HEM escalation resolution. AT_RISK: A Mission Status SO state flag set by the GEC when a sub-goal is at risk of failing to achieve its declared EOD outcome within the declared acceptance_envelope. AT_RISK detection triggers re-planning evaluation in the parent orchestrating agent. REPLAN_BOUNDED_ACTIVATED: The outcome when a BOUNDED re-planning action is taken by an orchestrating agent within its pre-declared bounds. Produces ALE-052. REPLAN_ESCALATED: The outcome when re-planning is required but exceeds the orchestrating agent's BOUNDED authority. Triggers HEM escalation. Produces ALE-053. MISSION_OPEN (ALE-042): The GAR audit event recorded by the GEC at the start of a mission. Carries the Mission Plan SO identifier, the root EOD identifier, and the Mission Principal identity. MISSION_CLOSE (ALE-055): The GAR audit event recorded by the GEC at the end of a mission. Carries the EOD_OUTCOME for every sub-goal and the Session Block identifier. Standing Plan Object (SPO): A pre-authorized Plan B structure defined by [I-D.sato-soos-sov] Section 4 (SOV-02 subtype). An SPO referenced in an EOD Plan B declaration provides a pre-vetted fallback that can be activated under BOUNDED authority without HEM escalation, subject to Cedar evaluation of the activation conditions. 5. Architecture Overview 5.1. AOP Position in the SOOS Stack AOP sits above MAD, AEP, and IDP in the SOOS governance stack. It is the orchestration layer that makes the per-agent session governance provided by those drafts compose across agent boundaries. The SOOS stack, from highest to lowest governance layer: +----------------------------------------------------------+ | AOP (This Document) | | Mission Plan SO -- Sub-Goal DAG -- Assignment Primitive | | EOD (Mission) -- EOD (Sub-Goal) -- Re-planning Authority | +----------------------------------------------------------+ | | | +---------------+ +---------------+ +---------------+ | MAD | | AEP | | IDP | | SACR | | Session | | Intent | | Hub-Only | | Lifecycle | | Declaration | | Revocation | | EOD | | Intake Endorse| +---------------+ +---------------+ +---------------+ | | | +----------------------------------------------------------+ | GEC (Governing Enforcement Component) | | KEE-1 Execution Environment -- Cedar Policy Evaluation | | GAR Event Stream -- KIA Keypair -- CAP Prohibition Layer | +----------------------------------------------------------+ AOP is the protocol layer that an orchestrating agent uses to govern a mission. AOP does not bypass any underlying layer -- each sub-agent session is fully AEP-governed, each SACR issuance is fully MAD-governed, each IDP transition is fully IDP-governed. AOP provides the mission-level structure that coordinates them. 5.2. The Three-Tier Orchestration Model AOP defines a three-tier orchestration model as the normative reference, illustrated by the emergency management scenario in Section 1.1. Implementations MAY support deeper hierarchies; the governance properties of this section apply at every tier. Tier 1: Master AI (Orchestrator) Holds the MissionDeclaration. Holds the Mission Plan SO. Issues Assignment Primitives to Tier 2 agents. Monitors Mission Status SO. Has BOUNDED or AUTONOMOUS replan_authority. Tier 2: Local AI (Sub-Orchestrator) Receives Assignment Primitive from Tier 1. Operates under its own AEP session. MAY issue further Assignment Primitives to Tier 3 agents (if can_decompose: true in its SACR). Has NONE or BOUNDED replan_authority. Tier 3: Simulation / Leaf AI Receives Assignment Primitive from Tier 2. Operates under its own AEP session. MUST NOT spawn further sub-agents (max_spawn_depth: 0). Has replan_authority: NONE. The max_spawn_depth field in each SACR [I-D.sato-soos-mad] Section 4.2 enforces this hierarchy. A Tier 3 agent with max_spawn_depth: 0 and can_decompose: false cannot issue an Assignment Primitive; any attempt MUST be REJECTED by the GEC and emits ALE-SPAWN-02 (SPAWN_DEPTH_EXCEEDED). 5.3. Mission Plan SO as the Governance Center The Mission Plan SO is the authoritative record of the mission decomposition. Every Assignment Primitive, every SACR, and every Sub-Goal EOD is linked to a sub-goal node in the Mission Plan SO. The Mission Plan SO is created by the GEC at Mission Open and MUST NOT be modified by the orchestrating agent. Changes to the mission structure -- adding sub-goals, removing sub-goals, changing dependency types -- MUST flow through the GEC via the gec.updateMissionPlan() operation, which requires Cedar evaluation of the Action::ReplanMission Cedar action and produces a versioned update event in the SO Instance Event Stream. The Mission Status SO is the live sibling of the Mission Plan SO. The Mission Plan SO is the declared structure. The Mission Status SO is the actual execution state. Together they provide the governance record that an auditor needs to compare intention to execution. 5.4. SACR Issuance Flow The SACR issuance flow for each Assignment Primitive in an AOP mission is as follows. This flow integrates [I-D.sato-soos-mad] Section 4.3 (SACR Issuance Procedure) with AOP's EOD pre- commitment requirement. Mission Principal issues MissionDeclaration | v Orchestrating Agent constructs Mission-Level EOD (E-EOD or PD-EOD path per [I-D.sato-soos-idp] Section 4.6/4.7) | v GEC: intake_endorsement -> Endorsed EOD + ENDORSED_EOD record | v GEC: creates Mission Plan SO (ALE-042 MISSION_OPEN emitted) | v Orchestrating Agent drafts (unendorsed) Sub-Goal EOD for each sub-goal (Sub-Goal EOD MUST be an E-EOD for human-critical sub-goals; PD-EOD permitted for autonomous sub-goals subject to Section 6.3) | v Orchestrating Agent calls gec.spawnSubAgent() with: - proposed scope_constraints - can_decompose, max_spawn_depth, hub_only, replan_authority - sub_goal_id (references Mission Plan SO node) | v GEC: MAD SACR issuance procedure (7 steps per [I-D.sato-soos-mad] Section 4.3: spawn request validation -> tool-subset check -> spawn-depth check -> Cedar action subset check -> ephemeral identity issuance -> SACR signing -> Assignment linkage) | v GEC: emits ALE-043 (SACR_ISSUED) | v Orchestrating Agent submits Sub-Goal EOD to intake_endorsement, referencing sacr_id (Section 6.2). EOD endorsement MUST be gated on SACR existence (Section 15.3): the GEC validates Sub-Goal EOD scope against the SACR's scope_constraints, not against the root mandate alone. | v GEC: intake_endorsement for Sub-Goal EOD -> Endorsed Sub-Goal EOD + ENDORSED_EOD record | v GEC: issues Assignment Primitive (Section 9) and emits ALE-044 (ASSIGNMENT_ISSUED), carrying sacr_id and endorsed_eod_id | v Sub-agent AEP session begins (XPID derived from parent_xpid per [I-D.sato-soos-kee] Section 10) 6. Expected Outcome Declaration (EOD) in AOP Context AOP does not define a new EOD schema. It composes the EOD object defined in [I-D.sato-soos-aep] Section 6.2 with the intake_ endorsement operation defined in [I-D.sato-soos-idp] Section 4.6 and the PD-EOD branch defined in [I-D.sato-soos-idp] Section 4.7, applying both at two distinct scopes within a single mission: once for the mission as a whole (Section 6.1) and once for each sub-goal (Section 6.2). AOP's contribution is not new EOD content. It is (a) the binding of an Endorsed EOD to Mission Plan SO structure rather than to a single AEP session, and (b) for Sub-Goal EODs specifically, the sequencing of endorsement relative to SACR issuance, resolved in this document as follows: Sub-Goal EOD endorsement MUST be gated on SACR existence. This resolves OQ-AOP-03 as to ordering; see Section 14 for the residual latency question OQ-AOP-03 leaves open. 6.1. Mission-Level EOD The Mission-Level EOD is constructed by the orchestrating agent from the MissionDeclaration: either supplied directly as a structured E-EOD (Section 6.4), or derived by the GEC as a PD-EOD (Section 6.3) from the MissionDeclaration's natural-language input when no structured E-EOD is supplied. The Mission-Level EOD is submitted to the GEC's intake_ endorsement operation ([I-D.sato-soos-idp] Section 4.6.1) with: eod: the Mission-Level EOD object, per [I-D.sato-soos-aep] Section 6.2. mandate_jwt: the root Mandate JWT referenced by the MissionDeclaration. principal_credential: the Mission Principal's credential. This document extends the so_id_bound semantics of the Endorsed EOD response ([I-D.sato-soos-idp] Section 4.6.2) for the mission level: because the Mission Plan SO does not yet exist at the time of Mission-Level EOD endorsement, so_id_bound MUST be populated with the mission_id assigned by the GEC at MissionDeclaration intake, in place of an AEP SO Instance identifier. Upon successful endorsement, the GEC commits ENDORSED_EOD ([I-D.sato-soos-idp] Section 4.6.2) and then creates the Mission Plan SO, emitting ALE-042 (MISSION_OPEN) with root_eod_id set to the endorsed EOD's eod_id. A Mission-Level EOD whose scope_ status is OUT_OF_SCOPE MUST NOT result in Mission Plan SO creation; the Mission Principal MAY revise and resubmit. 6.2. Sub-Goal EOD Each sub-goal node in the Sub-Goal DAG (Section 7.1) carries its own EOD, with a distinct eod_id, constructed by the orchestrating agent -- not the sub-agent, which does not yet exist at construction time. Per Section 15.3 and this document's resolution of OQ-AOP-03, Sub-Goal EOD endorsement MUST be gated on SACR existence. The orchestrating agent drafts the Sub-Goal EOD, calls gec.spawnSubAgent() to obtain a committed SACR (Section 9.3), and only then submits the Sub-Goal EOD for endorsement. This document extends the intake_endorsement request object ([I-D.sato-soos-idp] Section 4.6.1) for Sub-Goal EOD endorsement requests with a REQUIRED sacr_id field, referencing the committed SACR under which the sub-goal EOD is submitted. For requests carrying sacr_id, the GEC MUST compute scope_status against the referenced SACR's scope_constraints, not against the root Mandate JWT alone. A Sub-Goal EOD that references SO fields outside the SACR's scope_constraints MUST be REJECTED with EOD_SCOPE_VIOLATION (CONF-AOP-SEC-07), per Section 15.3. Unlike the mission level, so_id_bound for a Sub-Goal EOD follows the unmodified IDP semantics: it is bound to the ephemeral SO Instance identified by the SACR's ephemeral_kia_ref, which is the sub-agent's own SO Instance for the AEP session about to begin. On successful endorsement, the GEC issues the Assignment Primitive (Section 9) and emits ALE-044 (ASSIGNMENT_ISSUED), carrying both sacr_id and endorsed_eod_id. 6.3. PD-EOD Path in Multi-Agent Context [I-D.sato-soos-idp] Section 4.7 applies at both the mission level and the sub-goal level. At the mission level, a Mission-Level PD-EOD is derived by the GEC from the MissionDeclaration's natural-language input under the same derivation fields (derived, source_prompt, derivation_model, derivation_confidence, derivation_warnings) and the same scope-bounding rule ([I-D.sato-soos-idp] Section 4.7.2) as a single-agent PD-EOD, evaluated against the SO Type space reachable by the mission's root mandate. At the sub-goal level, a Sub-Goal PD-EOD is permitted only for autonomous sub-goals. A sub-goal is human-critical, and therefore MUST use an E-EOD (Section 6.4) rather than a PD-EOD, if its Assignment Primitive's SACR declares hem_required: true or if the sub-goal's Mission Plan SO node is marked human- critical by the orchestrating agent at DAG construction time (Section 7.1). A sub-goal not so marked is autonomous and MAY use a Sub-Goal PD-EOD. The scope-bounding rule for a Sub-Goal PD-EOD is tightened relative to the single-agent case: the PD-EOD's primary_ outcome.target_state and plan_b.plan_b_target_state MUST fall within the SACR's scope_constraints (Section 6.2), not merely within the SO Type's general state machine. A Sub-Goal PD-EOD that would require a target state outside the SACR's scope_ constraints MUST produce scope_status: OUT_OF_SCOPE, per the silent-scope-reduction prohibition in [I-D.sato-soos-idp] Section 4.7.2. The HEM notification requirement ([I-D.sato-soos-idp] Section 4.7.3) applies with the Mission Principal as notification target at both levels: a sub-agent has no independent principal relationship through which to receive or resolve a HEM notification, so external-system-touch notifications triggered by a Sub-Goal PD-EOD are routed to the Mission Principal who holds the mission's root mandate. 6.4. E-EOD Path in Multi-Agent Context An E-EOD is a structured EOD supplied without derivation -- it MUST NOT carry derived: true. At the mission level, the E-EOD is supplied directly by the Mission Principal as part of the MissionDeclaration. At the sub-goal level, the E-EOD is constructed by the orchestrating agent and, per Section 6.2, MUST be drafted and submitted for endorsement following the same SACR- gated sequencing as a Sub-Goal PD-EOD. Human-critical sub-goals, as defined in Section 6.3, MUST use an E-EOD. The GEC MUST REJECT a Sub-Goal EOD endorsement request carrying derived: true for a sub-goal marked human-critical. No schema content differs between the E-EOD and PD-EOD paths; both submit the same EOD object per [I-D.sato-soos-aep] Section 6.2. The paths differ only in provenance (human-authored versus machine-derived) and in the derivation metadata and scrutiny that provenance carries with it. 7. Mission Plan Sovereign Object The Mission Plan SO is created by the GEC at Mission Open (ALE-042) and is the authoritative structural record of the orchestrating agent's decomposition of a mission into a Sub-Goal DAG. It is distinct from the Mission Status SO (Section 8): the Mission Plan SO records what was planned; the Mission Status SO records what is happening. { "mission_plan_so_id": string, ; REQUIRED. UUID v7. SO ; Instance identifier. "mission_id": string, ; REQUIRED. References the ; mission (Section 6.1). "root_eod_id": string, ; REQUIRED. eod_id of the ; endorsed Mission-Level EOD. "mission_principal_xpid": string, ; REQUIRED. "nodes": object[], ; REQUIRED. See Section 7.1. "edges": object[], ; REQUIRED. See Section 7.2. "deadline": string | null, ; OPTIONAL. ISO 8601. ; Mission-level deadline. "version": integer, ; REQUIRED. Starts at 1. ; Increment semantics on ; partial re-plan are deferred ; to OQ-AOP-02 (Section 14). "created_at": string ; REQUIRED. ISO 8601. } 7.1. Sub-Goal DAG Structure Each entry in nodes is a Sub-Goal Node: { "sub_goal_id": string, ; REQUIRED. Unique within this ; Mission Plan SO. "description": string, ; REQUIRED. Human-readable. "human_critical": boolean, ; REQUIRED. Default false. ; Determines E-EOD requirement ; per Section 6.3. "assignment_status": string, ; REQUIRED. PLANNED | SPAWNED | ; ASSIGNED | TERMINAL. "sacr_id": string | null, ; OPTIONAL. Populated ; when assignment_status ; reaches SPAWNED (Section ; 9.3). "eod_id": string | null, ; OPTIONAL. Populated ; when assignment_status ; reaches ASSIGNED (Section ; 6.2). "deadline": string | null ; OPTIONAL. ISO 8601. ; Sub-goal-level deadline. } assignment_status transitions monotonically: PLANNED (node exists in the DAG, not yet spawned) -> SPAWNED (SACR issued, ALE-043) -> ASSIGNED (Sub-Goal EOD endorsed, Assignment Primitive issued, ALE-044) -> TERMINAL (sub-goal reached GOAL_ACHIEVED, PLAN_B_ACHIEVED, or FAILED; ALE-046, ALE-047, or ALE-049). A node MAY remain PLANNED for the duration of earlier sub-goals' execution when dependency structure (Section 7.2) defers its spawn. The GEC MUST validate a Mission Plan SO for well-formedness before emitting ALE-042: the node graph MUST be acyclic (a sub- goal MUST NOT depend on itself or on a descendant sub-goal, per Section 4), every edge MUST reference sub_goal_id values present in nodes, and every node MUST be reachable from at least one root node (a node with no incoming edges). A Mission Plan SO failing this check MUST be REJECTED with error code MISSION_ PLAN_MALFORMED and MUST NOT proceed to Mission-Level EOD endorsement. 7.2. Dependency Types: SEQUENTIAL, PARALLEL, CONDITIONAL Each entry in edges is a Dependency Edge: { "from_sub_goal_id": string, ; REQUIRED. "to_sub_goal_id": string, ; REQUIRED. "dependency_type": string, ; REQUIRED. SEQUENTIAL | ; PARALLEL | CONDITIONAL. "condition": object | null ; REQUIRED if ; dependency_type is ; CONDITIONAL; MUST be absent ; otherwise. Uses the ; success_condition schema of ; [I-D.sato-soos-aep] Section ; 6.2.1, evaluated against the ; from-node's terminal EOD_ ; OUTCOME and final SO state. } SEQUENTIAL: the to-node's assignment_status MUST NOT advance past PLANNED until the from-node reaches a terminal EOD_OUTCOME. PARALLEL: the GEC does not enforce ordering between the two nodes. Nodes connected only by PARALLEL edges, directly or transitively, MAY be spawned and assigned concurrently. CONDITIONAL: the to-node's assignment_status MUST NOT advance past PLANNED until condition evaluates true against the from- node's terminal state. A from-node terminal state for which condition evaluates false leaves the to-node PLANNED indefinitely, absent a re-planning action (Section 10). A node with more than one incoming edge MUST NOT advance past PLANNED until every incoming edge's condition, per its own dependency_type, is satisfied. AOP-00 does not define OR- semantics across multiple incoming edges; a sub-goal whose eligibility depends on any one of several predecessors MUST be expressed as a CONDITIONAL edge encoding that logic explicitly, or as separate DAG branches, rather than as implicit disjunction between edges. 7.3. Deadline Tracking and Critical Path The GEC computes the mission's critical path from the Sub-Goal DAG structure using each node's deadline where present and, where absent, duration estimates drawn from the GOAL_ COMPLETION_PROFILE query (Section 12.1) for the node's SO Type. A node on the critical path whose elapsed execution time exceeds its estimated duration by a threshold defined by [I-D.sato-soos- gar] SHOULD be evaluated for the Mission Status SO's AT_RISK flag (Section 8.2); this is the mechanism by which real-time monitoring (Section 12.4) is informed by DAG structure rather than by sub-goal state in isolation. A missed mission-level deadline is not itself a Cedar-enforced condition; it is recorded to the Mission Status SO and MAY trigger HEM notification per the Mission Principal's configured escalation policy. AOP-00 does not define a normative deadline- miss escalation policy; deployments configure this via HEM [I-D.sato-soos-hem]. 8. Mission Status Sovereign Object The Mission Status SO is maintained by the GEC and updated at each sub-goal state transition. Where the Mission Plan SO (Section 7) records what was planned, the Mission Status SO records what is happening: it is the live counterpart, never itself the source of structural truth. 8.1. Live Execution State { "mission_status_so_id": string, ; REQUIRED. UUID v7. "mission_plan_so_id": string, ; REQUIRED. References the ; corresponding Mission Plan ; SO (Section 7). "sub_goal_states": object[], ; REQUIRED. One entry per ; node in the Mission Plan ; SO's nodes array. "overall_status": string, ; REQUIRED. OPEN | AT_RISK | ; CLOSED. AT_RISK if any ; sub_goal_states entry has ; at_risk: true. "updated_at": string ; REQUIRED. ISO 8601. } Each entry in sub_goal_states: { "sub_goal_id": string, ; REQUIRED. References the ; Mission Plan SO node. "session_id": string | null, ; OPTIONAL. AEP session ; UUID once assignment_status ; reaches ASSIGNED. "aep_session_state": string | null, ; OPTIONAL. Mirrors the ; child AEP session state per ; [I-D.sato-soos-aep] Section ; 5: ACTIVE | HEM_PENDING | ; STALLED | PLAN_B_ACTIVE | ; CLOSED. "at_risk": boolean, ; REQUIRED. Default false. "at_risk_reason": string | null, ; OPTIONAL. One of the ; five trigger conditions in ; Section 8.2. REQUIRED if ; at_risk is true. "at_risk_detail": string | null, ; OPTIONAL. Human- ; readable. "last_transition_at": string ; REQUIRED. ISO 8601. } 8.2. AT_RISK Detection The GEC sets a sub-goal's at_risk flag to true, updates the Mission Status SO, and emits ALE-048 (SUB_GOAL_AT_RISK) with at_risk_reason set to exactly one of five named trigger conditions: AGENT_SELF_DECLARED: The sub-agent itself submits a GOAL_AT_RISK_DECLARED IDP transition, encoding the specific inconsistency it has detected. This is the only push trigger; the remaining four are GEC-computed. The transition type and the re-planning evaluation it initiates are specified normatively in Section 10.1. CRITICAL_PATH_DURATION_EXCEEDED: The sub-goal is on the mission's critical path (Section 7.3) and its elapsed execution time exceeds the threshold computed there. SUB_SESSION_STALLED: The sub-agent's AEP session enters STALLED ([I-D.sato-soos-aep] Section 5.4). REPEATED_DENIAL_THRESHOLD: The sub-agent's session Cedar DENY count exceeds the prior_ denial_count threshold used for Tier 1 session-local analytics escalation. HISTORICAL_PATTERN_MATCH: Aggregate GAR data (Section 8.3) indicates that missions reaching this sub-goal's current state have historically required HEM escalation above a deployment-configured probability threshold. Entering PLAN_B_ACTIVE ([I-D.sato-soos-aep] Section 5.5) does not, by itself, set at_risk. A sub-goal's EOD Plan B is a pre- authorized fallback; its activation is expected behavior, not a risk signal. A sub-goal already in PLAN_B_ACTIVE remains subject to the same five triggers as any other sub-goal. ALE-048 notification is routed to the sub-goal's direct parent orchestrating agent, consistent with the hub_only routing established at spawn (Section 9.2): a leaf agent with hub_only: true cannot notify beyond its immediate parent, and escalation beyond that parent's authority follows the re-planning path defined in Section 10. 8.3. Historical Pattern Integration Two of the five AT_RISK triggers depend on aggregate GAR data rather than the individual mission's own state: (a) The threshold used by CRITICAL_PATH_DURATION_EXCEEDED is drawn from the GOAL_COMPLETION_PROFILE query (Section 12.1) for the sub-goal's SO Type, not a fixed constant. (b) The probability used by HISTORICAL_PATTERN_MATCH is computed from Tier 2 aggregate mission outcome data: what fraction of prior missions in a comparable state ultimately required HEM escalation. Both are instances of the general mechanism described in Section 12.4 (Phase 4: Mid-Flight Monitoring): AT_RISK detection is empirically grounded in prior mission history rather than evaluated from the current mission's state alone. This document does not specify the query interface for (a) or (b); both reuse the Tier 1/Tier 2 analytics architecture of [I-D.sato-soos-faip]. 9. Assignment Primitive 9.1. Purpose and Design A committed SACR [I-D.sato-soos-mad] establishes what a sub-agent is authorized to do: scope_constraints, tool subset, spawn depth, and re-planning authority. It does not, by itself, establish what the sub-agent has been asked to do for this mission. The Assignment Primitive is the AOP-specific artifact that binds a committed SACR to a specific Sub-Goal EOD (Section 6.2), so that the governed handoff carries both the authority boundary (from MAD) and the outcome commitment (from AOP) as a single auditable unit. A deployment using MAD without AOP can spawn a scoped sub-agent with no outcome commitment at all; that is a valid MAD use and AOP does not alter it. AOP requires the additional EOD binding only for sub-agents spawned within an AOP-governed mission. An Assignment Primitive is therefore never issued in place of a SACR; it is issued in addition to one, once both the SACR and the Sub-Goal EOD it references exist (Section 9.3). 9.2. Assignment Schema { "assignment_id": string, ; REQUIRED. UUID v7. "mission_plan_so_id": string, ; REQUIRED. References the ; Mission Plan SO (Section 7). "sub_goal_id": string, ; REQUIRED. References the ; Mission Plan SO node (Section ; 7.1). "sacr_id": string, ; REQUIRED. References the ; committed SACR ; [I-D.sato-soos-mad] Section ; 4.3. "endorsed_eod_id": string, ; REQUIRED. References the ; Endorsed Sub-Goal EOD ; (Section 6.2). "assigned_agent_kia_ref": string, ; REQUIRED. The ; ephemeral_kia_ref issued at ; SACR issuance ; [I-D.sato-soos-kia]. "replan_authority": string, ; REQUIRED. NONE | BOUNDED | ; AUTONOMOUS. MUST be copied ; unmodified from the ; referenced SACR (Section ; 10). "hub_only": boolean, ; REQUIRED. MUST be copied ; unmodified from the ; referenced SACR. "issued_at": string, ; REQUIRED. ISO 8601. "issuer_signature": string ; REQUIRED. GEC signature over ; the canonical Assignment ; JSON. } The GEC MUST reject construction of an Assignment Primitive whose replan_authority or hub_only value does not match the referenced SACR exactly. This is a defensive consistency check: the SACR remains the sole source of authority for these values; the Assignment Primitive only carries a copy for audit convenience. 9.3. Assignment Issuance Procedure (1) The orchestrating agent calls gec.spawnSubAgent() with sub_goal_id, proposed scope_constraints, can_decompose, max_spawn_depth, hub_only, and replan_authority (Section 5.4). (2) The GEC executes the unmodified MAD SACR issuance procedure ([I-D.sato-soos-mad] Section 4.3, 7 steps). AOP does not alter, extend, or duplicate this procedure (Section 9.4). On success, the GEC commits the SACR and emits ALE-043 (SACR_ISSUED). The corresponding Mission Plan SO node's assignment_status advances to SPAWNED and its sacr_id is populated (Section 7.1). (3) The orchestrating agent submits the Sub-Goal EOD to intake_endorsement, referencing sacr_id (Section 6.2). (4) The GEC validates the EOD's scope against the SACR's scope_constraints and, on success, commits ENDORSED_EOD (Section 6.2). (5) The GEC constructs the Assignment Primitive (Section 9.2), signs it, and emits ALE-044 (ASSIGNMENT_ISSUED). The Mission Plan SO node's assignment_status advances to ASSIGNED and its eod_id is populated (Section 7.1). (6) The GEC delivers the Assignment Primitive to the sub-agent identity issued in step (2). The sub-agent's AEP session begins ([I-D.sato-soos-aep] Section 5.1), and the GEC emits ALE-045 (SUB_GOAL_OPENED). An Assignment Primitive MUST NOT be issued without a committed SACR and an Endorsed Sub-Goal EOD whose scope_status is not OUT_OF_SCOPE. Steps (3) and (4) MUST NOT be attempted before step (2) completes; this is the ordering resolved in Section 6.2 and Section 15.3. 9.4. MAD Integration The Assignment Primitive is strictly additive to the SACR. It does not redefine, weaken, or bypass any MAD invariant. Every question of delegation-chain authority, scope narrowing, tool- subset restriction, and cross-organization trust that applies to a spawned sub-agent is answered by [I-D.sato-soos-mad] alone and applies identically whether the spawn originates from AOP's orchestrating agent or from any other caller of gec.spawnSubAgent(). In particular, the tool-subset invariant enforced at spawn is defined and enforced entirely within [I-D.sato-soos-mad]; this document does not restate or extend it. AOP's only points of contact with the SACR are: reading scope_constraints during Sub-Goal EOD endorsement (Section 6.2), and copying replan_authority and hub_only into the Assignment Primitive for audit convenience (Section 9.2). AOP-00 does not re-argue its position relative to delegation-chain drafts external to SOOS; see Appendix B. 10. Re-planning Authority Each sub-agent's replan_authority (NONE, BOUNDED, or AUTONOMOUS) is fixed in its SACR at spawn (Section 9.2) and is immutable for the SACR's lifetime; a sub-agent cannot request an increase to its own authority mid-mission. Re-planning is evaluated by the orchestrating agent that holds the parent role for the at- risk sub-goal, not by the at-risk sub-agent itself, except for the self-declaration path in Section 10.1. Every consequential re-planning decision under this section -- a BOUNDED activation, an AUTONOMOUS replacement, or a determination that REPLAN_ESCALATED applies -- MUST be evaluated by Cedar via the Action::ReplanMission action (Section 5.3) before it takes effect. It is the single gate this entire section routes through, not three independently-trusted determinations; OQ-AOP-01's registration of ReplanMission in the Cedar action namespace can now proceed against concrete invocation semantics rather than a bare action name. An AGENT_SELF_DECLARED risk claim (Section 8.2) triggers this evaluation; it does not itself authorize anything. A self- declaration that does not correspond to any Cedar-PERMITted re-planning action leaves the sub-goal AT_RISK with no state change -- an audit-visible outcome (Section 10.3's NO_ACTION_REQUIRED), not a silent failure and not a free pass for a leaf agent's unverified claim to force a consequence on its own. 10.1. Autonomous Re-planning Bounds NONE: The sub-agent MUST NOT modify its own plan. On AT_RISK (Section 8.2), its only available action is to submit a GOAL_AT_RISK_DECLARED IDP transition and wait; all re- planning evaluation occurs at its parent. BOUNDED: The orchestrating agent MAY replace a sub-goal with a pre- declared alternative, without HEM escalation, if the alternative and its activation conditions were declared in advance. This document extends the plan_b object ([I-D.sato-soos-aep] Section 6.4) with a bounded_replan_ options array, present only when the orchestrating agent's own SACR declares replan_authority: BOUNDED. An orchestrating agent's SACR is itself the boundary of what it may replace: for the Master AI acting on the mission as a whole, this is the Mission-Level EOD (Section 6.1); for a mid-tier agent that is itself orchestrating sub-agents it has spawned -- for example, the Local AI of Section 13 -- this is that agent's own Sub-Goal EOD (Section 6.2), which functions as its mission-level EOD for the sub-mission it in turn orchestrates. bounded_replan_options therefore appears on whichever EOD belongs to the agent evaluating the replan, not only on the top-level Mission-Level EOD. Each entry: { "plan_b_id": string, ; REQUIRED. Unique within ; the governing EOD. "sub_goal_id": string, ; REQUIRED. The DAG node ; (Section 7.1) this option ; may replace. "replacement_spo_ref": string, ; REQUIRED. SPO reference ; (Section 4), a SOV-02 ; subtype [I-D.sato-soos-sov]. "activation_conditions": object[] ; REQUIRED. Uses the ; success_condition schema of ; [I-D.sato-soos-aep] Section ; 6.2.1. } A BOUNDED replacement MUST match a bounded_replan_options entry exactly: the affected sub_goal_id, the replacement_spo_ref, and satisfied activation_conditions. A replacement not matching any declared entry MUST be treated as REPLAN_ESCALATED (Section 10.2), regardless of the orchestrating agent's confidence that the replacement is reasonable. Exact match is necessary but not sufficient: Cedar's ReplanMission evaluation MUST additionally verify that the matched entry's replacement_spo_ref target state falls within the declaring agent's own SACR scope_constraints (Section 9.2), the same check AUTONOMOUS already requires of its own replacements below. A matching entry whose target state would exceed that scope MUST NOT receive a Cedar PERMIT, closing the asymmetry a prior revision left between BOUNDED (matched but never scope-verified) and AUTONOMOUS (always scope-verified). AUTONOMOUS: The orchestrating agent MAY construct and endorse a new Sub- Goal EOD for the affected sub-goal without HEM escalation, subject to the same scope-bounding as any Sub-Goal EOD (Section 6.2): the new target state MUST remain within the SACR's scope_constraints and the mission's root mandate. AUTONOMOUS authority permits improvisation within mandate scope; it does not permit exceeding it. A replacement whose target state falls outside scope MUST be treated as REPLAN_ESCALATED. Two Cedar gates apply in sequence: Action:: ReplanMission (Section 10, this section's shared gate) authorizes the orchestrating agent to attempt an AUTONOMOUS replacement for this sub-goal at all; Action::EvaluateEOD, via the standard Section 6.2 intake_endorsement process, then authorizes the specific new EOD's content. BOUNDED has no second gate of this kind, since it activates a pre-vetted SPO rather than constructing new EOD content -- which is exactly why ReplanMission's scope check above is BOUNDED's only content-level safeguard, not an optional second opinion on top of one that already existed. 10.2. HEM Escalation Triggers REPLAN_ESCALATED (ALE-053) is triggered when: (a) A sub-agent's replan_authority is NONE and it has submitted GOAL_AT_RISK_DECLARED (Section 10.1); (b) A BOUNDED orchestrating agent's evaluated replacement does not match any bounded_replan_options entry; or (c) An AUTONOMOUS orchestrating agent's evaluated replacement would exceed its SACR's scope_constraints or the mission's root mandate. Escalation propagates to the parent orchestrating agent via the hub_only routing path (Section 8.2). An orchestrating agent receiving an escalated re-plan evaluates its own re-planning authority against the same three cases; if it also lacks a covering BOUNDED or AUTONOMOUS option, REPLAN_ESCALATED propagates further up the mission hierarchy until it reaches the Mission Principal via HEM [I-D.sato-soos-hem]. No agent acts outside its declared authority at any point in this chain. HEM resolution produces ALE-054 (REPLAN_HEM_RESOLVED), carrying resolution_outcome: NEW_EOD: The Mission Principal authorizes a new Sub-Goal EOD for the affected sub-goal, endorsed per Section 6.2. MISSION_ABORT: The Mission Principal terminates the mission. The GEC emits ALE-055 (MISSION_CLOSE) with overall_outcome: ABORTED. CONTINUE: The Mission Principal authorizes continuation without a new EOD; the affected sub-goal remains AT_RISK (Section 8.2) under existing terms. This outcome is appropriate when the AT_RISK condition is judged tolerable rather than requiring re-planning. 10.3. ALE-051 and ALE-052 Definitions ALE-051 (REPLAN_EVALUATED) is emitted whenever an orchestrating agent evaluates a re-planning decision in response to AT_RISK (Section 8.2) or sub-goal failure, regardless of outcome. Its evaluation_outcome field (Section 17.3) takes one of: BOUNDED_APPLICABLE, AUTONOMOUS_APPLICABLE, ESCALATION_REQUIRED, or NO_ACTION_REQUIRED. NO_ACTION_REQUIRED covers the case where the sub-agent's own EOD Plan B ([I-D.sato-soos-aep] Section 6.4) resolves the AT_RISK condition without any mission-level re-planning action. ALE-052 (REPLAN_BOUNDED_ACTIVATED) is emitted when a BOUNDED replacement (Section 10.1) is executed. Its plan_b_id field (Section 17.3) is the activated bounded_replan_options entry's plan_b_id. The full mandatory-field registration for both ALE types is given in Section 17.3; this section defines their semantics. 11. AOP-to-GAR Integration AOP contributes no new audit mechanism. It defines a set of fourteen mission lifecycle ALE types, recorded to the GAR Event Log by the GEC alongside the AEP, IDP, MAD, and HEM ALE types already defined by their respective SOOS drafts. This section describes the lifecycle these fourteen types trace together; Section 17.3 gives the formal per-type field registration. 11.1. Mission Lifecycle ALE Types (ALE-042 Through ALE-055) The fourteen mission lifecycle ALE types trace a single mission from open to close in six groups: Mission Open (ALE-042): Emitted once, at Mission Plan SO creation (Section 6.1, Section 7). The sole entry point to a mission's audit trail; nothing else in this section can be emitted before it. Spawn and Assignment (ALE-043 through ALE-045): SACR_ISSUED, ASSIGNMENT_ISSUED, and SUB_GOAL_OPENED trace the Assignment Issuance Procedure (Section 9.3) for each sub-goal, in that order. These three MAY recur any number of times within a mission, once per sub-goal spawned. Sub-Goal Terminal States (ALE-046 through ALE-049): SUB_GOAL_GOAL_ACHIEVED, SUB_GOAL_PLAN_B_ACHIEVED, SUB_GOAL_ AT_RISK, and SUB_GOAL_FAILED trace a sub-goal's outcome. ALE-048 (Section 8.2) MAY be emitted and cleared multiple times before a sub-goal reaches one of the other three, which are each terminal for that sub-goal. Plan B Integrity (ALE-050): SPO_INTEGRITY_VIOLATION is emitted only on a Plan B activation hash mismatch (Section 15.4); absent in the overwhelming majority of missions. Re-planning (ALE-051 through ALE-054): REPLAN_EVALUATED, REPLAN_BOUNDED_ACTIVATED, REPLAN_ ESCALATED, and REPLAN_HEM_RESOLVED trace the Re-planning Authority decision chain of Section 10, in the order described there. Not every mission emits these; a mission whose sub-goals all reach GOAL_ACHIEVED without AT_RISK emits none of the four. Mission Close (ALE-055): Emitted once, when the Mission Status SO's overall_status reaches a terminal value. The sole exit point; every ALE- 042 has exactly one corresponding ALE-055. An Audit Principal reconstructing a mission reads these fourteen types in emission order to obtain the full sub-goal DAG execution history, every re-planning decision, and every HEM escalation, without needing access to any sub-agent's individual AEP session record (Section 11.2) except where the investigation requires session-internal detail beyond what the mission lifecycle ALEs carry. 11.2. Session Block at Mission Close Each sub-agent's own AEP session independently generates a Session Audit Record (SAR) at session close [I-D.sato-soos-aep] Section 11.2. A mission with N spawned sub-agents therefore produces N independent SARs, none of which individually carries mission-level context: a single sub-agent's SAR shows its own session but not its sibling sub-goals, its position in the DAG, or the re-planning decisions made above it. At mission close, the GEC constructs a Session Block: a GEC- signed aggregate referencing every SACR, every Assignment Primitive, every EOD, every AT_RISK event, and every re-planning decision emitted under the mission's mission_id, together with the session_id and SAR reference for every spawned sub-agent. The Session Block is committed to the GAR Event Log as part of ALE-055 (MISSION_CLOSE), whose session_block_id field (Section 17.3) is the Session Block's identifier. The Session Block does not replace or duplicate the individual SARs it references; it is the structural index that lets an Audit Principal navigate from a single mission_id to every session, event, and decision that occurred within it, without having discovered those sessions independently. A GAR implementation MUST reject a MISSION_CLOSE whose session_block_ id references a Session Block missing a SAR reference for any sub-goal node whose assignment_status (Section 7.1) reached ASSIGNED. 12. Five-Phase Planning Intelligence Model AOP's use of GAR is not limited to retrospective audit (Section 11). At five points across the mission lifecycle already defined in Sections 6 through 10, an orchestrating agent's decisions can be informed by aggregate GAR history rather than by pretraining-derived heuristics alone. This model was first described, in single-session AEP terms, in [SSRN-PAPER2]; this section restates it in AOP's mission and Sub-Goal DAG terms. Two structural features of AOP change how the model applies relative to a single AEP session. First, a mission's Sub-Goal DAG design (Phase 2) and each individual sub-goal's outcome commitment (Phase 3) occur at different points in mission time, not together at intake: a sub-goal gated by a SEQUENTIAL or CONDITIONAL edge (Section 7.2) is not drafted until its predecessor resolves. Second, monitoring (Phase 4) operates over the whole Sub-Goal DAG rather than a single session's state. Each phase below contrasts the decision made without GAR history against the same decision informed by it, per [I-D.sato-soos-faip] Tier 1 and Tier 2 analytics. 12.1. Phase 1: Mission Framing Without GAR: The Mission Principal issues a MissionDeclaration; the orchestrating agent constructs the Mission-Level EOD (Section 6.1) from pretraining-derived judgment alone, with no empirical basis for which target states, confidence levels, or Plan B options are realistic for this SO Type. With GAR: Before constructing the Mission-Level EOD, the orchestrating agent queries GOAL_COMPLETION_PROFILE ([I-D.sato-soos-faip] Tier 2) for the mission's SO Type. The response characterizes historical mission success rate, the most common failure class, and median steps to completion. The Mission-Level EOD's confidence and Plan B declaration are calibrated against this response before submission to intake_ endorsement (Section 6.1), rather than against intuition alone. 12.2. Phase 2: Sub-Goal Decomposition Without GAR: The orchestrating agent designs the Sub-Goal DAG (Section 7) from general reasoning about task structure, with no empirical basis for which dependency-type choices (Section 7.2) produce resource conflicts or unnecessary serialization. With GAR: Mission lifecycle event history (Section 11.1) from prior missions of the same SO Type shows which dependency-type choices have historically produced AT_RISK states or resource conflicts, and which sub-goal orderings shortened the critical path (Section 7.3). A DAG design that would produce a known conflict class -- for example, two PARALLEL sub-goals that historically contend for the same downstream resource -- is revised to SEQUENTIAL or given a CONDITIONAL guard before the Mission Plan SO is submitted for well-formedness validation (Section 7.1). 12.3. Phase 3: Assignment Execution Unlike Phase 1 and Phase 2, which occur once at mission open, this phase recurs once per sub-goal, at the point in the Assignment Issuance Procedure (Section 9.3) where the Sub-Goal EOD is drafted, immediately before it is submitted for intake_ endorsement. Without GAR: The orchestrating agent sets the Sub-Goal EOD's confidence and acceptance_envelope from intuition, with no basis for knowing whether declared confidence is calibrated for this action type, or which failure classes most commonly arise for it. With GAR: Three intelligence inputs inform the draft: CONFIDENCE_MISCALIBRATION_WARNING data ([I-D.sato-soos-idp] Section 7.2) for this action type; EOD_BREACH frequency, showing which sub-goal types most often breach their acceptance_envelope and in which direction; and, where the orchestrating agent's SACR declares BOUNDED replan_authority, historical record of which replacement_spo_ref (Section 10.1) has resolved this failure class before, informing which bounded_replan_options entry the Mission-Level EOD declares. 12.4. Phase 4: Mid-Flight Monitoring Without GAR: The orchestrating agent detects AT_RISK conditions only from the current mission's own state -- elapsed time against a fixed estimate, or explicit self-declaration (Section 8.2) -- and re-plans reactively once a sub-goal has already failed or stalled. With GAR: The CRITICAL_PATH_DURATION_EXCEEDED and HISTORICAL_ PATTERN_MATCH triggers (Section 8.2) are computed against aggregate mission history (Section 8.3) rather than a fixed heuristic. A sub-goal's elapsed time is compared against the GOAL_COMPLETION_PROFILE duration distribution for its SO Type, not a single estimate, and HISTORICAL_PATTERN_MATCH can set at_risk before any local threshold is breached, when aggregate history shows that missions reaching the sub-goal's current state disproportionately require HEM escalation. AT_RISK fires earlier, and with a stated basis, rather than only after local symptoms appear. 12.5. Phase 5: Mission Closure and Learning Without GAR: Re-planning decisions (Section 10) are reasoned from pretraining alone, with no basis for knowing which BOUNDED or AUTONOMOUS approaches have historically stayed within authority and which required HEM escalation. At mission close, the Session Block (Section 11.2) is committed as a compliance record and nothing further happens to it. With GAR: REPLAN_BOUNDED_ACTIVATED and REPLAN_ESCALATED history (Section 10.3) for this failure class informs which bounded_ replan_options entry to activate, and whether an AUTONOMOUS improvisation is likely to stay within scope or require escalation, before the re-planning evaluation (ALE-051) is recorded. At mission close, the Session Block's constituent ALE events -- every EOD, every AT_RISK trigger, every re- planning decision, and its outcome -- become part of the aggregate history that Phases 1 through 4 of the next mission of this SO Type will query. A MATCHED primary_outcome strengthens the aggregate's confidence calibration; a PLAN_B_ MATCHED or UNMATCHED outcome strengthens the record of which failure classes and which recoveries actually occurred. The loop described in [SSRN-PAPER2] Section 9 closes at the mission level exactly as it closes at the session level: better planning produces better records, and better records produce better planning for the mission that follows. 13. Reference Scenario: Three-Tier Emergency Management Orchestration This section works a single mission through the full lifecycle defined in Sections 6 through 12. It is the scenario introduced in Section 1.1 and worked in mechanistic detail in Sections 3.1 through 3.4; this section is the authoritative version where those accounts differ in detail, and Appendix A reproduces it as a full field-level trace. A regional emergency management agency activates its AI-governed response system following an earthquake. The human incident commander, acting as Mission Principal, issues a MissionDeclaration to a Master AI operating under a GOLD-tier Standing Plan pre-authorized by the agency duty officer: evacuate three affected districts, allocate shelter capacity across available municipal facilities, and report status to regional command every fifteen minutes. Mission Framing (Section 6.1, Section 12.1). The Master AI queries GOAL_COMPLETION_PROFILE for this SO Type before drafting the Mission-Level EOD. The response characterizes the most common failure class for this mission type as loss of real-time road network data in at least one affected district. The Master AI drafts the Mission-Level EOD with a primary_outcome describing full evacuation status across all three districts, and a plan_b referencing a pre-computed static routing SPO, consistent with the GOLD-tier Standing Plan. The EOD is endorsed, and the GEC creates the Mission Plan SO, emitting ALE-042 (MISSION_OPEN). Sub-Goal Decomposition (Section 7, Section 12.2). The Master AI designs the Sub-Goal DAG: three PARALLEL district branches, each containing SEQUENTIAL sub-goals for routing, shelter allocation, and status reporting. Mission event history for this SO Type shows that PARALLEL shelter-allocation sub-goals across districts have historically produced double-booked municipal capacity; the Master AI gives the three shelter-allocation sub- goals a CONDITIONAL guard against one another rather than leaving them PARALLEL, so each district's allocation is checked against already-committed capacity before proceeding. The resulting Mission Plan SO passes well-formedness validation (Section 7.1). Assignment: Districts 1 and 3 (Section 9, Section 12.3). For each district, the Master AI calls gec.spawnSubAgent() for a district-level Local AI (replan_authority: BOUNDED, hub_only: true), drafts a Sub-Goal EOD scoped to that district, and, once the SACR is committed (ALE-043), submits the Sub-Goal EOD for intake_endorsement referencing the SACR. Confidence and acceptance_envelope are calibrated against CONFIDENCE_ MISCALIBRATION_WARNING and EOD_BREACH history for this action type before submission. Each Local AI receives its Assignment Primitive (ALE-044) and begins its AEP session (ALE-045). Both districts proceed without incident and reach GOAL_ACHIEVED (ALE-046). Assignment: District 2 and the Cross-Tier Escalation (Section 9, Section 10, Section 12.4). District 2's Local AI, itself holding BOUNDED replan_authority, calls gec.spawnSubAgent() for a Simulation AI (evacuation routing model; replan_authority: NONE; max_spawn_depth: 0; hub_only: true), drafts a further- constrained Sub-Goal EOD, and issues a second-tier Assignment Primitive once its own SACR is committed. Partway through execution, the Simulation AI detects that its evacuation model is producing outputs inconsistent with real- time sensor data that was not available at Assignment time. Its replan_authority is NONE and hub_only is true: it cannot re-plan, cannot spawn a sub-agent to investigate, and cannot contact the Master AI directly. Per Section 10.1, it submits a GOAL_AT_RISK_DECLARED IDP transition. The GEC sets at_risk: true for the district2-routing sub-goal with at_risk_reason: AGENT_SELF_DECLARED, emits ALE-048 (SUB_GOAL_AT_RISK), and routes notification to the Simulation AI's direct parent -- District 2's Local AI -- per the hub_only routing of Section 8.2. The Local AI evaluates re-planning (ALE-051, REPLAN_EVALUATED). Its own Sub-Goal EOD -- the EOD under which the Master AI assigned it, which functions as its own mission-level EOD for the district sub-mission it in turn orchestrates, per Section 10.1 -- carries a bounded_replan_options entry for exactly this case: sub_goal_id district2-routing, a replacement_spo_ref pointing to the static routing SPO, and an activation_ conditions entry matching road_data_unavailable. The Local AI's evaluated replacement matches the entry exactly; it activates the static routing SPO without HEM escalation, and the GEC emits ALE-052 (REPLAN_BOUNDED_ACTIVATED). No agent in this chain acted outside its declared authority, and no HEM escalation to the Mission Principal was required: the condition that triggered re-planning was pre-declared, the replacement matched a pre-declared option, and the activation condition was satisfied. Had the Local AI's bounded_replan_ options not covered this failure class, REPLAN_ESCALATED (ALE-053) would have propagated to the Master AI, and, absent a covering option there, to the Mission Principal via HEM, per Section 10.2. Mission Closure (Section 11, Section 12.5). All three districts reach a terminal EOD_OUTCOME: Districts 1 and 3 MATCHED; District 2 PLAN_B_MATCHED, having activated the static routing SPO. The GEC constructs the Session Block, referencing every SACR, Assignment Primitive, EOD, the single AT_RISK event, and the single re-planning decision from the mission, together with the SAR of each district's AEP session and each second-tier Simulation AI session beneath them. The GEC emits ALE-055 (MISSION_CLOSE). This mission's record -- the district2- routing failure class, the AGENT_SELF_DECLARED trigger that caught it, and the SPO that resolved it without HEM escalation -- becomes part of the aggregate history the next mission of this SO Type queries at its own Mission Framing and Assignment Execution phases (Section 12.1, Section 12.3). 14. Open Issues OQ-AOP-01: Cedar action namespace for AOP. The Cedar actions DeclareMission, IssueChildMission, EvaluateEOD, ReplanMission, and ActivateStandingPlan require namespace registration in the Cedar action namespace defined by [I-D.sato-soos-cap]. This registration should be coordinated with the CAP-RRS catalog update in the same Datatracker submission batch. EXPECTED RESOLUTION: pre-Vienna editorial, same session as CAP-RRS catalog update. OQ-AOP-02: Mission Plan SO versioning on partial re-plan. When BOUNDED re-planning replaces a sub-goal in the Mission Plan SO (e.g., routing sub-goal replaced with static plan), the SO versioning semantics need to be specified. Does the Mission Plan SO create a new version, or does the original version remain authoritative with a delta overlay? The answer affects how auditors reconstruct the original vs. executed plan. EXPECTED RESOLUTION: Session 2 authoring. OQ-AOP-03: Sub-Goal EOD endorsement batching. Section 6.2 resolves the ordering question: Sub-Goal EOD intake_endorsement MUST occur after SACR issuance, gated on SACR existence per Section 15.3. This confirms a two-round- trip interaction (spawnSubAgent, then intake_endorsement) before an Assignment Primitive can be issued for each sub- goal. For high-frequency mission decomposition (e.g., many parallel sub-goals), this may impose latency. Whether a batch endorsement operation -- endorsing multiple Sub-Goal EODs against their respective SACRs in a single GEC interaction -- is appropriate remains open. EXPECTED RESOLUTION: Session 2 authoring. 15. Security Considerations 15.1. Hub Compromise Blast Radius Attack: An adversary that compromises an orchestrating agent (Tier 1 Master AI or Tier 2 Local AI) may attempt to issue Assignment Primitives outside the pre-declared Mission Plan SO structure, spawn sub-agents with inflated scope, or modify the Mission Status SO to suppress AT_RISK signals. Mechanism: The compromised agent issues a gec.spawnSubAgent() call with scope_constraints that exceed the parent's own SACR scope. Alternatively, it attempts to modify the Mission Status SO via a direct write operation rather than via GEC-mediated state transition. Normative defense: (1) The GEC MUST verify that all scope_constraints in a spawn request are strict subsets of the spawning agent's own scope_constraints as recorded in its SACR. A spawn request that fails this check MUST be REJECTED with SCOPE_NARROWING_VIOLATION. (CONF-AOP-SEC-01) (2) The Mission Status SO MUST be written exclusively by the GEC. No agent MUST be granted Cedar Action::WriteMissionStatus. The Cedar policy MUST include an explicit DENY on Action::WriteMissionStatus for all principal types except GEC. (CONF-AOP-SEC-02) (3) The Mission Plan SO sub-goal DAG MUST be committed to the GEC-signed SO Instance Event Stream at Mission Open. Any Assignment Primitive whose sub_goal_id does not reference a node in the committed Mission Plan SO MUST be REJECTED. (CONF-AOP-SEC-03) Residual risk: An adversary with full GEC compromise can bypass all of the above. GEC integrity is governed by [I-D.sato-soos-kee] KEE-1 properties P1 through P8. AOP's blast radius is bounded by the Mission Plan SO scope. Hub compromise does not propagate beyond the mission's committed scope. 15.2. Recursive Spawn Depth-Limit Bypass Attack: A compromised sub-agent at Tier 2 attempts to spawn additional sub-agents beyond its max_spawn_depth: 0 constraint, potentially creating an ungoverned execution subtree. Mechanism: The agent calls gec.spawnSubAgent() despite having max_spawn_depth: 0 and can_decompose: false in its committed SACR. Alternatively, it attempts to forge a spawn request with a higher max_spawn_depth value. Normative defense: (1) The GEC MUST check the requesting agent's max_spawn_depth from the committed SACR record before accepting any gec.spawnSubAgent() call. A call from an agent with max_spawn_depth: 0 MUST be REJECTED with ALE-SPAWN-02 (SPAWN_DEPTH_EXCEEDED). (CONF-AOP-SEC-04) (2) The SACR's sacr_signature covers all fields including max_spawn_depth and can_decompose. A sub-agent cannot present a modified SACR without invalidating the GEC Ed25519 signature. (CONF-AOP-SEC-05) (3) The GEC MUST verify that the requested max_spawn_depth in any spawn request does not exceed (spawning agent's committed max_spawn_depth - 1). Per [I-D.sato-soos-mad] CONF-MAD-SACR-01. (CONF-AOP-SEC-06) Residual risk: A compromised GEC could bypass these checks. Mitigated by KEE-1 P7 (WAL tamper evidence) and P8 (revocation propagation): a SACR issued without a corresponding committed ALE-043 record is detectable by audit. 15.3. EOD Scope Inflation Across Delegation Attack: An orchestrating agent submits a Sub-Goal EOD with a primary_outcome.target_state that exceeds the scope of the sub-goal's intended task, effectively granting the sub-agent authority over SO states outside the mission's declared scope. Mechanism: The Sub-Goal EOD's acceptance_envelope declares success_conditions referencing SO fields outside the scope_constraints recorded in the corresponding SACR, effectively using the EOD to perform side-channel scope expansion. Normative defense: (1) The GEC MUST verify, during Sub-Goal EOD intake_endorsement, that all SO fields referenced in primary_outcome.target_state and acceptance_envelope.success_conditions are within the sub-goal SACR's scope_constraints.so_type_scope. A Sub-Goal EOD that references out-of-scope SO fields MUST be REJECTED with EOD_SCOPE_VIOLATION. (CONF-AOP-SEC-07) (2) The intake_endorsement operation for Sub-Goal EODs MUST be performed by the GEC after SACR issuance, not before. The SACR is the scope authority; the EOD is the intent declaration. EOD endorsement MUST be gated on SACR existence. (CONF-AOP-SEC-08) (3) Cedar evaluation of Action::EvaluateEOD MUST include the SACR scope_constraints as Cedar attributes, enabling policy to enforce scope consistency between SACR and EOD. (CONF-AOP-SEC-09) Residual risk: An adversary with control over the Cedar policy corpus could weaken the EvaluateEOD policy. Mitigated by CAP Tier 0-B constitutional enforcement [I-D.sato-soos-cap] and CAP-RRS policy corpus governance. 15.4. Standing Plan Hijack Attack: An adversary injects a malicious Standing Plan Object (SPO) reference into a Mission-Level EOD Plan B declaration, causing an orchestrating agent to activate a pre-authorized Plan B that executes attacker-controlled actions rather than the legitimate contingency. Mechanism: The adversary modifies the SPO referenced by the EOD's plan_b.plan_b_target_state before the Plan B is activated at runtime, or crafts a plan_b_ref that resolves to a different SPO than the one reviewed by the Mission Principal. Normative defense: (1) The GEC MUST record the SPO content hash (SHA-256 over canonical JSON of the SPO at intake_endorsement time) in the Endorsed EOD. At Plan B activation, the GEC MUST recompute the SPO hash and verify it matches the hash in the Endorsed EOD. A hash mismatch MUST cause Plan B activation to be REJECTED with SPO_INTEGRITY_VIOLATION and ALE-050 emitted. (CONF-AOP-SEC-10) (2) The SPO referenced in a Plan B declaration MUST be a SOV-02 subtype committed to the GEC-signed SO Instance Event Stream per [I-D.sato-soos-sov] Section 4. An SPO reference that resolves to a document outside the GEC's governed SO namespace MUST be REJECTED. (CONF-AOP-SEC-11) (3) The GEC MUST evaluate Cedar Action::ActivateStandingPlan before executing any Plan B that references an SPO. The Cedar policy MUST verify that the activation conditions in the SPO match the AT_RISK condition that triggered Plan B activation. (CONF-AOP-SEC-12) Residual risk: A Mission Principal who approves an EOD with an SPO reference without reviewing the SPO content creates a residual standing plan hijack surface. Operators SHOULD display SPO content to Mission Principals as part of E-EOD acknowledgment workflow. 15.5. Unverified Self-Declared Risk Forcing a Re-planning Action Attack: A compromised or malfunctioning sub-agent -- most significantly one with replan_authority: NONE, the least- trusted tier in the delegation hierarchy -- submits a GOAL_AT_RISK_DECLARED IDP transition (AGENT_SELF_DECLARED, Section 8.2) for a sub-goal that is not actually at risk, in order to force its parent orchestrating agent into an unnecessary re-planning evaluation, or to mask an unrelated problem behind a plausible-looking risk claim. Mechanism: AGENT_SELF_DECLARED is the only push-type AT_RISK trigger among the five named in Section 8.2; the GEC records it at face value, since a claim of risk is not independently verifiable the way the other four GEC-computed triggers are. Normative defense: The self-declaration alone authorizes nothing. Section 10's Cedar Action::ReplanMission gate applies uniformly to every consequential outcome the evaluation could produce -- BOUNDED activation, AUTONOMOUS replacement, or REPLAN_ESCALATED -- so a false self-declaration can trigger an evaluation but cannot itself force a state change: absent a Cedar PERMIT, the mission remains AT_RISK with evaluation_outcome: NO_ACTION_REQUIRED, and no bounded or autonomous action executes. (CONF-AOP-SEC-13) Residual risk: This defense bounds the *consequence* of a false claim; it does not verify the claim's *truthfulness*. A compromised NONE-authority agent can still consume its parent's evaluation cycles and populate GAR with unverified claims, repeatedly, since Section 8.2 (per Section 11.1's ALE-048) does not bound how many times AGENT_SELF_DECLARED may be emitted for the same sub-goal. This is one instance of the volumetric gap addressed generally in Section 15.6; a rate limit on self-declared triggers per sub-goal per unit time would close this specific instance and is a reasonable candidate for a future revision, but is not specified normatively here. 15.6. Denial of Service (NEW in -02) [RFC3552] Section 3 and BCP 72 require Security Considerations sections to address Denial of Service explicitly. -00 and -01 did not. AOP introduces three volumetric attack surfaces that are distinct from the depth-limit-bypass concern already addressed in Section 15.2: each respects every per-request bound this document defines, and is still capable of resource exhaustion purely through repetition or breadth. (a) Unbounded Sub-Goal DAG fan-out and size. Section 7.1 defines the Sub-Goal DAG's node and dependency schema but states no maximum on the number of nodes a Mission Plan SO may declare, nor on the number of sibling nodes with no dependency between them (fan-out at a single DAG level). A compromised or malfunctioning orchestrating agent operating entirely within its max_spawn_depth: 0 successor bound (Section 15.2 does not apply, since depth is respected) can still declare an arbitrarily large single-level DAG and issue a gec.spawnSubAgent() call for every node, exhausting GEC, Mission Status SO update, and downstream MAD SACR-issuance capacity without ever exceeding a documented per-call limit. (b) Unbounded AT_RISK-triggered re-planning loops. Section 10's Cedar Action::ReplanMission gate bounds what a re-planning evaluation may *do*, but nothing in Section 8.2, Section 10, or Section 15.5 bounds how often a re-planning evaluation may be *triggered* for the same Mission Plan SO. A sub-goal that oscillates between AT_RISK and not-AT_RISK -- whether through a genuine flapping condition or a compromised agent's AGENT_SELF_DECLARED claims (Section 15.5) -- can force repeated evaluation cycles with no upper bound on frequency. (c) Depth-respecting spawn flooding. A compromised orchestrating agent can issue a high-frequency sequence of gec.spawnSubAgent() calls, each individually valid and each remaining within its committed max_spawn_depth, faster than downstream MAD SACR issuance, KIA ephemeral identity provisioning, or GAR ALE-043 recording can be expected to absorb in a production deployment. Normative defense: None of (a), (b), or (c) is normatively bounded in this revision. Implementations SHOULD apply deployment-specific rate limits -- a maximum Sub-Goal DAG node count per Mission Plan SO, a minimum interval between successive re-planning evaluations for the same Mission Plan SO, and a maximum gec.spawnSubAgent() call rate per orchestrating agent session -- until normative limits are specified in a future revision. Residual risk: Absent normative limits, the specific thresholds above are deployment-chosen and not interoperable; two conforming GECs may apply materially different volumetric tolerances. This is tracked as an open item for a future revision rather than resolved here. 16. Privacy Considerations AOP produces mission lifecycle GAR records that may contain sensitive operational data. The mission primary_outcome rationale field in the EOD MAY contain natural-language descriptions of the mission goal that are operationally sensitive (e.g., in a disaster management context, mission descriptions may reference specific municipal facilities or population groups). ALE-042 (MISSION_OPEN) and ALE-055 (MISSION_CLOSE) MUST NOT include the full EOD structure if the EOD carries personal data under applicable privacy law (APPI Article 17 for Japan deployments; EU GDPR Article 5 for EU deployments). The GEC MUST record only the eod_id and eod_hash in ALEs, not the full EOD body. The full EOD is stored in the SO Instance Event Stream as a separate record subject to access controls. Sub-agent identity in SACR records uses ephemeral_kia_ref (a session-scoped UUID v4), not persistent Party Registry identities, minimizing persistent linkability of sub-agent session data. 17. IANA Considerations 17.1. Mission Plan SO Media Type IANA is requested to register the following media type: Type name: application Subtype name: soos-mission-plan+json Required parameters: N/A Optional parameters: version Encoding considerations: binary (JSON, UTF-8) Security considerations: See Section 15 of this document. Published specification: This document, Section 7. Applications that use this media type: SOOS-governed multi-agent orchestration systems implementing the Agent Orchestration Protocol. Additional information: N/A Person and email address for further information: Tom Sato Intended usage: COMMON Restrictions on usage: None Author: Tom Sato Change controller: IETF 17.2. Assignment Primitive Media Type IANA is requested to register the following media type: Type name: application Subtype name: soos-assignment+json Required parameters: N/A Optional parameters: version Encoding considerations: binary (JSON, UTF-8) Security considerations: See Section 15 of this document. Published specification: This document, Section 9. Applications that use this media type: SOOS-governed multi-agent orchestration systems implementing the Agent Orchestration Protocol. Additional information: N/A Person and email address for further information: Tom Sato Intended usage: COMMON Restrictions on usage: None Author: Tom Sato Change controller: IETF 17.3. Mission ALE Type Registrations IANA is requested to register the following ALE type codes in the SOOS ALE Type Registry established by [I-D.sato-soos-gar]: ALE-042: MISSION_OPEN Description: Emitted by GEC at mission initiation. Mandatory fields: mission_id, mission_plan_so_id, root_eod_id, mission_principal_xpid, timestamp. ALE-043: SACR_ISSUED Description: Emitted by GEC at SACR issuance for each sub-agent spawn within a mission. Mandatory fields: sacr_id, sub_goal_id, parent_xpid, ephemeral_kia_ref, scope_hash, timestamp. ALE-044: ASSIGNMENT_ISSUED Description: Emitted by GEC when an Assignment Primitive is issued to a sub-agent. Mandatory fields: assignment_id, sacr_id, sub_goal_id, endorsed_eod_id, assigned_agent_kia_ref, timestamp. ALE-045: SUB_GOAL_OPENED Description: Emitted when a sub-agent's AEP session begins execution of its assigned sub-goal. Mandatory fields: sub_goal_id, assignment_id, session_id, timestamp. ALE-046: SUB_GOAL_GOAL_ACHIEVED Description: Emitted when a sub-agent achieves its EOD primary outcome within the acceptance envelope. Mandatory fields: sub_goal_id, session_id, eod_outcome: MATCHED, timestamp. ALE-047: SUB_GOAL_PLAN_B_ACHIEVED Description: Emitted when a sub-agent achieves its EOD Plan B outcome. Mandatory fields: sub_goal_id, session_id, eod_outcome: PLAN_B_MATCHED, plan_b_id, timestamp. ALE-048: SUB_GOAL_AT_RISK Description: Emitted when the Mission Status SO AT_RISK flag is set for a sub-goal. Mandatory fields: sub_goal_id, at_risk_reason, timestamp. ALE-049: SUB_GOAL_FAILED Description: Emitted when a sub-agent session closes with eod_outcome: UNMATCHED. Mandatory fields: sub_goal_id, session_id, failure_reason, timestamp. ALE-050: SPO_INTEGRITY_VIOLATION Description: Emitted when Plan B activation is REJECTED due to SPO hash mismatch. Mandatory fields: sub_goal_id, plan_b_id, expected_spo_hash, actual_spo_hash, timestamp. ALE-051: REPLAN_EVALUATED Description: Emitted when the orchestrating agent evaluates a re-planning decision in response to AT_RISK or sub-goal failure. Mandatory fields: mission_id, sub_goal_id, replan_authority, evaluation_outcome, timestamp. ALE-052: REPLAN_BOUNDED_ACTIVATED Description: Emitted when a BOUNDED re-planning action is executed by the orchestrating agent within pre-declared bounds. Mandatory fields: mission_id, sub_goal_id, plan_b_id, activation_conditions_met: string[], timestamp. ALE-053: REPLAN_ESCALATED Description: Emitted when re-planning exceeds BOUNDED authority and HEM escalation is triggered. Mandatory fields: mission_id, sub_goal_id, escalation_reason, hem_escalation_id, timestamp. ALE-054: REPLAN_HEM_RESOLVED Description: Emitted when HEM escalation for re-planning is resolved by the Mission Principal. Mandatory fields: mission_id, hem_escalation_id, resolution_outcome (NEW_EOD | MISSION_ABORT | CONTINUE), resolver_xpid, timestamp. ALE-055: MISSION_CLOSE Description: Emitted by GEC at mission close. Carries eod_outcome for every sub-goal. Mandatory fields: mission_id, mission_plan_so_id, session_block_id, sub_goal_outcomes: object[], overall_outcome, timestamp. 18. References 18.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [I-D.sato-soos-aep] Sato, T., "The Agent Execution Protocol (AEP) for Agentic AI Systems", Internet-Draft draft-sato-soos-aep-03, July 2026. [I-D.sato-soos-idp] Sato, T., "The Intent Declaration Primitive (IDP) for Agentic AI Systems", Internet-Draft draft-sato-soos-idp-05, July 2026. [I-D.sato-soos-mad] Sato, T., "Multi-Agent Delegation in Sovereign Object Systems", Internet-Draft draft-sato-soos-mad-04, July 2026. [I-D.sato-soos-gar] Sato, T., "The Governance Audit Record (GAR) for Agentic AI Systems", Internet-Draft draft-sato-soos-gar-07, September 2026. [I-D.sato-soos-hem] Sato, T., "The Human Escalation Mechanism (HEM) for Agentic AI Systems", Internet-Draft draft-sato-soos-hem-06, July 2026. [I-D.sato-soos-cap] Sato, T., "The Constitutional AI Protocol (CAP) for Agentic AI Systems", Internet-Draft draft-sato-soos-cap-05, July 2026. [I-D.sato-soos-cap-rrs] Sato, T., "The Constitutional AI Protocol Regulation Record Schema (CAP-RRS) for Agentic AI Systems", Internet-Draft draft-sato-soos-cap-rrs-03, July 2026. [I-D.sato-soos-kee] Sato, T., "The Kernel Execution Environment (KEE-1) for the Sovereign Object OS", Internet-Draft draft-sato-soos-kee-02, July 2026. [I-D.sato-soos-kia] Sato, T., "Kernel Identity and Attestation (KIA) for Governing Enforcement Components", Internet-Draft draft-sato-soos-kia-06, July 2026. [I-D.sato-soos-sov] Sato, T., "The Sovereign Object (SOV) for Agentic AI Systems", Internet-Draft draft-sato-soos-sov-03, July 2026. [I-D.sato-soos-mjwt] Sato, T., "The Mandate JWT (MJWT) for Agentic AI Systems", Internet-Draft draft-sato-soos-mjwt-05, July 2026. 18.2. Informative References [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on Security Considerations", BCP 72, RFC 3552, DOI 10.17487/RFC3552, July 2003, . [I-D.sato-soos-rgp] Sato, T., "The Resource Gateway Protocol (RGP) for Agentic AI Systems", Internet-Draft draft-sato-soos-rgp-01, July 2026. [I-D.sato-soos-faip] Sato, T., "The Federated Agent Intelligence Protocol (FAIP) for Agentic AI Systems", Internet-Draft draft-sato-soos-faip-02, August 2026. [I-D.agent-gw] Xie, X., Wang, Z., Hu, T., and Y. Cui, "Agent Communication Gateway for Semantic Routing and Working Memory", Work in Progress, Internet-Draft, draft-agent-gw-01, March 2026, . [I-D.li-dmsc-macp] Li, X., Liu, B., Liu, J., Du, C., and L. Zhang, "Multi-agent Collaboration Protocol Suites Architecture", Work in Progress, Internet-Draft, draft-li-dmsc-macp-06, 20 July 2026, . [SSRN-PAPER2] Sato, T., "From Compliance to Intelligence: How AI Agent Audit Logs Become the World's Best Training Data", SSRN, July 2026, . Appendix A. Worked Example: Three-Tier Emergency Management Orchestration This appendix reproduces the mission narrated in Section 13 as a field-level trace. Identifiers are illustrative mnemonics, not generated UUIDs, for readability; signatures and hashes are elided as and . Timestamps advance across a single afternoon. Mission Open. Mission-Level EOD, submitted for intake_endorsement: { "eod_id": "eod-eq0817-mission", "primary_outcome": { "target_state": "ALL_DISTRICTS_EVACUATION_COMPLETE", "confidence": 0.74, "rationale": "GOAL_COMPLETION_PROFILE for this SO Type: 3 districts, road-data loss in >=1 district is the most common failure class." }, "plan_b": { "plan_b_id": "pb-eq0817-mission-static-all", "plan_b_target_state": "ALL_DISTRICTS_STATIC_ROUTING", "activation_conditions": [ {"condition_id": "c1", "field": "districts_road_data_lost", "operator": "gte", "value": 2, "required": true} ], "plan_b_acceptance_envelope": { "success_conditions": [ {"condition_id": "c2", "field": "evacuation_status", "operator": "eq", "value": "COMPLETE", "required": true} ]} }, "submitter_mjwt_id": "mjwt-incident-commander-04", "eod_signature": "" } ALE-042 (MISSION_OPEN): { "mission_id": "mission-eq0817", "mission_plan_so_id": "mpso-eq0817", "root_eod_id": "eod-eq0817-mission", "mission_principal_xpid": "xpid:agency:incident-commander-04", "timestamp": "2026-08-17T14:00:00Z" } The Mission Plan SO's nodes and edges, as validated for well- formedness (Section 7.1): nodes: [ {"sub_goal_id": "d1-routing"}, {"sub_goal_id": "d1-shelter"}, {"sub_goal_id": "d1-report"}, {"sub_goal_id": "d2-routing"}, {"sub_goal_id": "d2-shelter"}, {"sub_goal_id": "d2-report"}, {"sub_goal_id": "d3-routing"}, {"sub_goal_id": "d3-shelter"}, {"sub_goal_id": "d3-report"} ] edges (illustrative subset): [ {"from": "d1-routing", "to": "d1-shelter", "dependency_type": "SEQUENTIAL"}, {"from": "d1-shelter", "to": "d1-report", "dependency_type": "SEQUENTIAL"}, {"from": "d1-shelter", "to": "d2-shelter", "dependency_type": "CONDITIONAL", "condition": {"condition_id": "cap1", "field": "committed_capacity", "operator": "lt", "value": "district_capacity_limit", "required": true}}, {"from": "d2-shelter", "to": "d3-shelter", "dependency_type": "CONDITIONAL", "condition": "..."} ] District 1 and District 3 (nominal path; District 3 identical in shape, elided). ALE-043 (SACR_ISSUED, District 1 Local AI): { "sacr_id": "sacr-d1-local", "sub_goal_id": "d1-routing", "parent_xpid": "xpid:master-ai", "ephemeral_kia_ref": "kia-d1-local", "scope_hash": "", "timestamp": "2026-08-17T14:02:00Z" } ALE-044 (ASSIGNMENT_ISSUED, District 1): { "assignment_id": "asn-d1-routing", "sacr_id": "sacr-d1-local", "sub_goal_id": "d1-routing", "endorsed_eod_id": "eod-d1-routing", "assigned_agent_kia_ref": "kia-d1-local", "timestamp": "2026-08-17T14:03:00Z" } ALE-045 (SUB_GOAL_OPENED, District 1): { "sub_goal_id": "d1-routing", "assignment_id": "asn-d1-routing", "session_id": "session-d1-routing", "timestamp": "2026-08-17T14:03:05Z" } ALE-046 (SUB_GOAL_GOAL_ACHIEVED, District 1): { "sub_goal_id": "d1-routing", "session_id": "session-d1-routing", "eod_outcome": "MATCHED", "timestamp": "2026-08-17T14:41:00Z" } District 3 repeats the same four-event shape on sacr-d3-local / asn-d3-routing / session-d3-routing, closing MATCHED at 14:38:00Z. District 2: assignment and second-tier spawn. ALE-043 (SACR_ISSUED, District 2 Local AI): { "sacr_id": "sacr-d2-local", "sub_goal_id": "d2-routing", "parent_xpid": "xpid:master-ai", "ephemeral_kia_ref": "kia-d2-local", "scope_hash": "", "timestamp": "2026-08-17T14:02:00Z" } District 2's Local AI is assigned via ALE-044/045 as District 1 was. Its own Sub-Goal EOD, eod-d2-routing, carries the bounded_replan_options entry that will later be activated (Section 10.1): "bounded_replan_options": [ { "plan_b_id": "pb-d2-static-route", "sub_goal_id": "d2-routing", "replacement_spo_ref": "spo-static-route-d2-gold", "activation_conditions": [ {"condition_id": "rc1", "field": "road_data_unavailable", "operator": "eq", "value": true, "required": true} ] } ] The Local AI in turn spawns a Simulation AI (evacuation routing model): ALE-043 (SACR_ISSUED, second tier): { "sacr_id": "sacr-d2-sim", "sub_goal_id": "d2-routing-sim", "parent_xpid": "xpid:d2-local-ai", "ephemeral_kia_ref": "kia-d2-sim", "scope_hash": "", "timestamp": "2026-08-17T14:05:00Z" } ALE-044 / ALE-045 follow, opening session-d2-sim at 14:05:20Z. The AT_RISK escalation. At 14:22:00Z the Simulation AI detects sensor-inconsistent output. Its replan_authority is NONE and hub_only is true; per Section 10.1 it submits GOAL_AT_RISK_DECLARED. The GEC sets at_risk: true on the d2-routing Mission Status SO entry: ALE-048 (SUB_GOAL_AT_RISK): { "sub_goal_id": "d2-routing", "at_risk_reason": "AGENT_SELF_DECLARED", "timestamp": "2026-08-17T14:22:03Z" } The Local AI evaluates re-planning: ALE-051 (REPLAN_EVALUATED): { "mission_id": "mission-eq0817", "sub_goal_id": "d2-routing", "replan_authority": "BOUNDED", "evaluation_outcome": "BOUNDED_APPLICABLE", "timestamp": "2026-08-17T14:22:40Z" } The evaluated replacement matches pb-d2-static-route exactly; rc1 (road_data_unavailable: true) is satisfied: ALE-052 (REPLAN_BOUNDED_ACTIVATED): { "mission_id": "mission-eq0817", "sub_goal_id": "d2-routing", "plan_b_id": "pb-d2-static-route", "activation_conditions_met": ["rc1"], "timestamp": "2026-08-17T14:23:00Z" } District 2's routing sub-goal closes against its Plan B acceptance envelope: ALE-047 (SUB_GOAL_PLAN_B_ACHIEVED): { "sub_goal_id": "d2-routing", "session_id": "session-d2-local", "eod_outcome": "PLAN_B_MATCHED", "plan_b_id": "pb-d2-static-route", "timestamp": "2026-08-17T14:47:00Z" } No ALE-053 or ALE-054 occurs in this mission: no re-plan exceeded BOUNDED authority. Mission Close. Shelter allocation and reporting sub-goals for all three districts complete after their CONDITIONAL capacity guards clear. At mission close the GEC constructs the Session Block and emits: ALE-055 (MISSION_CLOSE): { "mission_id": "mission-eq0817", "mission_plan_so_id": "mpso-eq0817", "session_block_id": "sblock-eq0817", "sub_goal_outcomes": [ {"sub_goal_id": "d1-routing", "eod_outcome": "MATCHED"}, {"sub_goal_id": "d2-routing", "eod_outcome": "PLAN_B_MATCHED"}, {"sub_goal_id": "d3-routing", "eod_outcome": "MATCHED"} (remaining shelter/report sub-goals elided) ], "overall_outcome": "MATCHED_WITH_PLAN_B", "timestamp": "2026-08-17T16:45:00Z" } sblock-eq0817 references every SACR, Assignment Primitive, and EOD in this trace, both ALE-048 through ALE-052 entries, and the SAR of session-d1-routing, session-d2-local, session-d2-sim, and session-d3-routing (Section 11.2). Appendix B. Related Work B.1. Existing Orchestration Frameworks LangGraph, CrewAI, and AutoGen each provide multi-agent orchestration capabilities. None of these frameworks specifies a governance protocol for sub-agent spawning: there is no kernel-mediated SACR equivalent, no Mission Plan SO as an auditable artifact, and no pre-commitment EOD structure. AOP does not replace these frameworks -- it is the governance overlay that makes them compliant with the SOOS governance architecture. The OpenAI Swarms API and Anthropic's multi-agent capability provide agent handoff mechanisms. These are application-layer handoffs without kernel-level scope enforcement or audit-complete lifecycle records. AOP's Assignment Primitive is distinguished by its SACR requirement: every handoff is kernel-witnessed and scope-narrowing is enforced at the GEC level, not at the agent application level. Delegation-chain authority. The Assignment Primitive (Section 9) issues its governed handoff exclusively through gec. spawnSubAgent(), which produces a SACR per [I-D.sato-soos-mad] Section 4. Every question of delegation-chain authority, scope narrowing, and cross-organization trust that applies to a spawned sub-agent applies identically whether the spawn originates from AOP's orchestrating agent or from any other caller of gec.spawnSubAgent(). This document therefore does not re-argue AOP's position relative to delegation-chain drafts such as I-D.miller-ztip, I-D.rampalli-pedigree, or I-D.liu- oauth-chain-delegation; that analysis belongs to [I-D.sato-soos-mad]'s own Related Work section and applies here by reference in full. DAG-based multi-agent orchestration. [I-D.agent-gw] performs semantic routing by decomposing complex intents into a DAG of sub-tasks and dispatching them to suitable targets based on capability matching, trust score, and operational metrics, with an evolutionary memory that improves routing policy over time. Industry Planner/Executor/Replanner architectures follow a comparable shape. AOP's Sub-Goal DAG and dependency-type structure (Section 7.2) are not a novel claim relative to this body of work -- DAG- based task decomposition for multi-agent execution is common, well-understood practice. AOP's contribution is the governance layer wrapped around it: re-planning authority (Section 10) is a declared, mandate-bound property fixed in the SACR before a sub-agent is ever spawned, rather than an adaptive routing behavior decided at runtime; and AT_RISK detection (Section 8.2) is an audited state tied to five named trigger conditions and committed to the mission lifecycle audit trail (Section 11), rather than a reliability signal feeding a routing policy. None of the cited orchestration work makes re-planning authority or failure detection an accountable, standardized property in this sense; this document does not claim they should have, only that AOP addresses a governance question these efforts do not. No claim-level or structural borrowing from [I-D.agent-gw] is proposed at the protocol level. [I-D.li-dmsc-macp], from the DMSC working group, addresses a structurally adjacent multi-agent gateway and capability- discovery space (Agent Management Center, Agent Gateway, capability-based query and synchronization). Consistent with this project's posture toward DMSC-circle work generally, this document does not engage [I-D.li-dmsc-macp] beyond this citation, and does not treat any finding from it as an input to AOP's own governance design. B.2. Regulatory Instruments EU AI Act Article 22 (Transparency for certain AI systems used to interact with natural persons) and Article 13 (Transparency and provision of information to deployers) create obligations for multi-agent systems that AOP's mission lifecycle record satisfies: the GAR record provides a complete audit trail of automated decision-making across all agents in a mission. Emerging AI governance frameworks in multiple jurisdictions identify the governance of multi-agent AI systems as a priority area. The AOP Mission Plan SO and Mission Status SO directly address the traceability requirements identified in these frameworks. Disaster management regulatory frameworks in multiple jurisdictions require that AI-governed emergency response systems maintain complete, auditable records of automated decision-making. AOP's MISSION_OPEN (ALE-042) through MISSION_CLOSE (ALE-055) lifecycle record is designed to satisfy such requirements: every re-planning decision, every sub-agent spawn, and every AT_RISK event is captured in the GAR with the authority basis that permitted it. B.3. SOOS Companion Drafts This document (AOP) is the highest-layer protocol in the SOOS governance stack. It depends on: CAP [I-D.sato-soos-cap]: Cedar policy evaluation for DeclareMission, IssueChildMission, EvaluateEOD, ReplanMission, and ActivateStandingPlan actions. CAP provides the constitutional prohibition layer that governs all AOP operations. CAP-RRS [I-D.sato-soos-cap-rrs]: The policy corpus that defines the Cedar policies for AOP actions. AOP actions must appear in the CAP-RRS catalog. MAD [I-D.sato-soos-mad]: SACR issuance, hub-only constraint, and R-1 through R-7 revocation trigger classes. AOP depends on MAD Section 4 for every Assignment Primitive. AEP [I-D.sato-soos-aep]: Per-agent session governance. Every sub-agent in an AOP mission runs its own AEP session. AOP provides the mission-level structure above those sessions. IDP [I-D.sato-soos-idp]: EOD intake_endorsement (Section 4.6) and PD-EOD path (Section 4.7). AOP requires Endorsed EODs for all Mission-Level and Sub-Goal EODs. GAR [I-D.sato-soos-gar]: Mission lifecycle ALE recording. ALE-042 through ALE-055 are registered with GAR as mission lifecycle events. HEM [I-D.sato-soos-hem]: REPLAN_ESCALATED handler. HEM receives escalations from AOP when re-planning exceeds BOUNDED authority and surfaces decisions to the Mission Principal. KIA [I-D.sato-soos-kia]: Kernel identity for the GEC and for ephemeral sub-agent identity via SACR-issued ephemeral_kia_ref. KEE-1 [I-D.sato-soos-kee]: Execution environment properties P1 through P8 that all AOP operations must satisfy. XPID derivation (KEE-1 Section 10) for sub-agent identity at SACR issuance. SOV [I-D.sato-soos-sov]: Standing Plan Object (SPO) as the Plan B reference artifact, defined normatively by SOV. Mission Plan SO and Mission Status SO are AOP subtypes, not SOV subtypes -- see Section 1.4; SOV-03 removed its earlier -02 duplicate definition of both once this document's ownership was confirmed. MJWT [I-D.sato-soos-mjwt]: The mandate authority chain referenced in EOD submitter_mjwt_id. The root mandate governs the outer bounds of mission scope. RGP [I-D.sato-soos-rgp] (Informative): Resource discovery feeds Assignment Primitive construction. AOP consumes the output of RGP but does not depend on it normatively. AOP does not have dependents in the current SOOS draft suite: it is the highest-layer protocol. FAIP [I-D.sato-soos-faip] may in future reference AOP for federated multi-agent mission governance; this is noted as an informative dependency direction. Appendix C. Changes from Previous Versions (NEW in -02) C.1. Changes from draft-sato-soos-aop-01 This revision closes out a WIMSE Security Review checklist pass (Stage 0, Part 3, Stage 1) run against -01. o Section 14 (Open Issues, structural): -00 and -01 both had this section's body physically mis-sequenced, appearing after IANA Considerations rather than between the Reference Scenario and Security Considerations as its own numbering and the Table of Contents both required. Relocated to the correct position; no content changed. o Section 15.6 (Denial of Service, new): -00's WIMSE review found no Security Considerations subsection addressed resource exhaustion; -01 left this open despite Section 15.5 explicitly referencing "this document's DoS treatment," which did not exist anywhere in the text. New subsection names three volumetric attack surfaces distinct from Section 15.2's depth-limit-bypass concern: unbounded Sub-Goal DAG fan-out/ size, unbounded AT_RISK re-planning-evaluation frequency, and depth-respecting spawn flooding. No normative limit is set; deployment-specific rate limiting is recommended pending a future revision. [RFC3552] added as a new informative reference. o References (corrected): two documents cited normatively in the body -- KIA and CAP-RRS -- had no corresponding entry in the References section at all. Both added. Ten further citations in the Related Work appendix used one-off versioned reference keys (e.g. "I-D.sato-soos-cap-04" in square brackets) that matched no defined entry, while the bare form of the same key was already used, and defined, everywhere else in the document; all ten normalized to the bare form. Reference entries updated to current SOOS suite versions throughout. o Appendix B.3 (corrected): the SOV entry stated "Mission Plan SO and Mission Status SO as SOV-02 subtypes," directly contradicting this document's own Section 1.4 ("The Mission Plan SO and Mission Status SO are SO subtypes defined by AOP") and, independently, contradicting current reality now that SOV-03 has removed its -02 duplicate definition of both subtypes. Corrected to match. o Editorial: header block corrected from "Network Working Group" to "Internet Engineering Task Force," matching the rest of the SOOS suite; title-block date and an internally inconsistent expiry statement (title block said 18 February 2027, Status of This Memo said 30 December 2026) both corrected and aligned; one stray bracket-style citation of "Section 15.3" and 14 similarly bracket-style CONF-AOP-SEC conformance tags converted to parenthesis style, per the same idnits-avoidance pattern applied to every other SOOS draft in this review. C.2. Changes from draft-sato-soos-aop-00 -01 completed the document body: Sections 6 through 13 were listed in the Table of Contents but absent from the text in -00, which ran directly from Section 5.4 to Section 15. All eight sections (Expected Outcome Declaration in AOP Context, Mission Plan Sovereign Object, Mission Status Sovereign Object, Assignment Primitive, Re-planning Authority, AOP-to-GAR Integration, Five-Phase Planning Intelligence Model, and the Reference Scenario) are now fully specified. Appendix A's "TO BE COMPLETED IN SESSION 3" placeholder is filled in. This also resolved -00's headline WIMSE review finding: three passages disagreed about whether Sub-Goal EOD intake_endorsement happens before or after SACR issuance (the Section 5.4 diagram showed endorsement first; Section 15.3's CONF-AOP-SEC-08 required SACR issuance first; the Open Issues entry describing the diagram matched the Security Considerations text rather than the actual diagram). -01 resolves this consistently throughout: SACR issuance now precedes Sub-Goal EOD endorsement everywhere the sequence is described. Author's Address Tom Sato MyAuberge K.K. Chino, Nagano, Japan Email: tomsato@myauberge.jp URI: https://soosproject.ai