Network Working Group                                            T. Sato
Internet-Draft                                           MyAuberge K.K.
Intended status: Standards Track                          24 May 2026
Expires: 24 November 2026


        The Agent Execution Protocol (AEP) for Agentic AI Systems
                       draft-sato-soos-aep-00

Abstract

   AI agents operating on governed resources require a normative
   interface contract between their internal reasoning loop and the
   Governing Enforcement Component (GEC) that enforces authorization
   policy, records transitions to a tamper-evident Event Stream, and
   mediates access to Sovereign Object instances.  Existing agent
   frameworks define no such contract.  Agents submit actions without a
   normative delivery protocol for the state and permission context they
   act on; GECs enforce policy without a normative protocol for
   communicating denial rationale back to agents; human oversight is
   invoked without a normative session state that governs the resulting
   suspension.

   This document defines the Agent Execution Protocol (AEP): the
   normative five-step loop -- SENSE, REASON, PLAN, ACT, OBSERVE --
   that specifies how a governed AI agent interfaces with GEC services
   at each iteration.  The AEP defines the Context Package delivered at
   SENSE, the GEC Query Interface exercised at PLAN, the Transition
   Request submitted at ACT, and the atomic GEC response received at
   OBSERVE.  The AEP specifies two conformance modes -- Standard and
   Goal Execution Engine (GEE) -- and normatively integrates the Intent
   Declaration Primitive [I-D.sato-soos-idp], the Mandate JWT
   [I-D.sato-soos-mjwt], the Human Escalation Mechanism
   [I-D.sato-soos-hem], the Governance Audit Record [I-D.sato-soos-gar],
   the Constitutional AI Protocol [I-D.sato-soos-cap], and the
   Sovereign Object [I-D.sato-soos-sov] as components of a single
   governed execution architecture.

   The REASON step is intentionally GEC-unspecified: the LLM reasoning
   engine is opaque to the protocol.  The AEP is the transmission
   between the LLM engine and the GEC enforcement substrate.

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 24 November 2026.

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
   2.  Conventions and Definitions
   3.  Problem Statement
     3.1.  The Loop Gap
     3.2.  Why Existing Agent Frameworks Are Insufficient
     3.3.  AEP as Architectural Integrator
   4.  The AEP Loop
     4.1.  Overview
     4.2.  Step 1 -- SENSE
     4.3.  Step 2 -- REASON
     4.4.  Step 3 -- PLAN
     4.5.  Step 4 -- ACT
     4.6.  Step 5 -- OBSERVE
     4.7.  LOOP Mechanism
   5.  Session Lifecycle
     5.1.  Session Initiation
     5.2.  Active Session
     5.3.  HEM_PENDING Session State
     5.4.  Session Closure
   6.  Context Package
     6.1.  Context Package Schema
     6.2.  Context Package Trigger Types
     6.3.  SO Sub-Object
     6.4.  Permissions Sub-Object
     6.5.  Goal Sub-Object
     6.6.  Memory Sub-Object
     6.7.  Proximity Events
     6.8.  HEM Context
     6.9.  Agent Sub-Object
   7.  GEC Query Interface (PLAN Step)
     7.1.  Transition Graph Query
     7.2.  Live Permission Map
     7.3.  Compensating Action Catalogue
   8.  Transition Request (ACT Step)
     8.1.  Transition Request Structure
     8.2.  GEC Execution Sequence
     8.3.  IDP Submission at ACT
   9.  GEC Response (OBSERVE Step)
     9.1.  PERMIT Response
     9.2.  DENY Response
     9.3.  HEM_PENDING Response
     9.4.  RETRY_CONTINUATION Handling
   10. AEP Event Log Markers
     10.1. AEP_SENSE_DELIVERED
     10.2. AEP_SESSION_CLOSED
   11. Standard Mode Conformance
   12. GEE Orchestration Mode
     12.1. GEE Overview
     12.2. Agent Reasoning Interface
     12.3. GEE Conformance
   13. Agent Class Model
   14. Relationship to Other SOOS Drafts
   15. Security Considerations
   16. Privacy Considerations
   17. IANA Considerations
   18. References
     18.1. Normative References
     18.2. Informative References
   Appendix A.  ATP Booking Object -- AEP Reference Walk-Through


1.  Introduction

   The IETF SOOS protocol family specifies governance primitives for
   agentic AI systems: the Intent Declaration Primitive (IDP)
   [I-D.sato-soos-idp] for per-transition intent declaration; the Human
   Escalation Mechanism (HEM) [I-D.sato-soos-hem] for human oversight;
   the Governance Audit Record (GAR) [I-D.sato-soos-gar] for tamper-
   evident audit; the Constitutional AI Protocol (CAP)
   [I-D.sato-soos-cap] for constitutional prohibition enforcement; the
   Sovereign Object (SOV) [I-D.sato-soos-sov] for the governed resource
   definition; and the Mandate JWT (MJWT) [I-D.sato-soos-mjwt] for
   agent authorization binding.

   Each of these specifications describes a component.  None describes
   the loop.

   An AI agent governed by these protocols executes a repeating
   cycle: it receives context about the Sovereign Object instance it is
   operating on; it reasons about what action to take next; it plans
   that action using GEC query services; it submits the action as a
   Transition Request carrying an MJWT and an IDP; and it receives a
   GEC response that either permits the transition, denies it with
   enriched rationale, or suspends the session pending human decision.
   Then it does this again.

   This cycle -- SENSE, REASON, PLAN, ACT, OBSERVE -- is the interface
   contract between the agent's internal reasoning and the GEC
   enforcement substrate.  Without a normative specification of this
   cycle, each of the component protocols specifies its own assumptions
   about the context in which it operates, without guaranteeing that
   those assumptions are satisfied.  IDP assumes the agent has received
   a context package before reasoning; AEP normatively defines that
   delivery.  HEM assumes the session enters a HEM_PENDING state that
   governs subsequent behavior; AEP normatively defines that state and
   its exit conditions.  GAR assumes GEC events are generated at
   defined points in the session; AEP normatively defines those points.

   This document fills the loop gap.  The Agent Execution Protocol
   (AEP) is the normative specification of how a governed AI agent
   interfaces with GEC services at each iteration of its execution
   cycle.  It is the horizontal interface contract that makes the
   component SOOS protocols composable into a single governed execution
   architecture.

   The AEP is explicitly not a specification of agent intelligence.
   The REASON step is GEC-unspecified: what LLM, what prompting
   strategy, what reasoning architecture the agent uses is opaque to
   the protocol.  The AEP specifies the inputs the agent MUST have
   received before reasoning (SENSE), the GEC services it MAY query
   to inform its plan (PLAN), the Transition Request structure it MUST
   submit to act (ACT), and the response it MUST process before acting
   again (OBSERVE).  The intelligence between SENSE and ACT is the
   agent's; the protocol is the interface.

   The design principle of the AEP: the LLM is the engine.  The AEP
   is the transmission.  The GEC enforcement substrate is the road
   system.  The road system specifies only the interface; it does not
   specify the vehicle.


2.  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.

   This document uses the following terms:

   Agent Execution Protocol (AEP):
      The normative five-step loop -- SENSE, REASON, PLAN, ACT,
      OBSERVE -- defined in this document.  Specifies the interface
      contract between a governed AI agent and GEC services at each
      iteration of the agent's execution cycle.

   AEP Session:
      A bounded execution context initiated when the GEC delivers the
      first Context Package to an agent for a specific Sovereign Object
      instance under a specific Mandate JWT.  An AEP Session has a
      unique session_id, a goal_session_id, and an iteration counter.
      An AEP Session is in one of three states: ACTIVE, HEM_PENDING,
      or CLOSED.

   AEP Iteration:
      One complete traversal of the SENSE-REASON-PLAN-ACT-OBSERVE cycle
      within an AEP Session.  Counted by aep_iteration, a monotonically
      increasing integer per session.

   Context Package:
      The structured data object delivered by the GEC to the agent at
      the SENSE step.  Contains the current SO Instance state, the
      agent's permission set, the current goal, memory items, Proximity
      Events, and HEM context if applicable.

   Transition Request:
      The structured submission from an agent to the GEC at the ACT
      step, carrying a Mandate JWT [I-D.sato-soos-mjwt], a Cedar action
      identifier, and an Intent Declaration Primitive
      [I-D.sato-soos-idp].

   GEC Query Interface:
      The set of read-only GEC services queried at the PLAN step:
      Transition Graph, Live Permission Map, and Compensating Action
      Catalogue.

   HEM_PENDING:
      An AEP Session state in which the session has been suspended by
      the GEC pending a human principal decision under the Human
      Escalation Mechanism [I-D.sato-soos-hem].  HEM_PENDING is a
      valid, expected session state, not an error state.

   Goal Execution Engine (GEE):
      An optional orchestration mode in which a GEC-provided engine
      inverts control, calling the agent's reason() function as a
      service within a GEC-driven loop.  In GEE mode the agent MUST NOT
      call the GEC transition endpoint directly.

   Proximity Event:
      A GEC-generated notification that a monitored condition is
      approaching a threshold value.  Delivered within the Context
      Package at SENSE.  Enables proactive agent behavior before
      threshold breach.

   ReasoningOutput:
      The structured output produced by the agent at the REASON step
      in GEE mode, consumed by the GEE to construct the full Transition
      Request.

   Governing Enforcement Component (GEC):
      As defined in [I-D.sato-soos-idp]: a runtime component that
      enforces authorization policy, records agent actions to a tamper-
      evident Event Stream, and mediates agent access to Sovereign
      Object instances.

   Sovereign Object (SO):
      As defined in [I-D.sato-soos-sov]: a causally ordered, policy-
      governed, typed, living document that evolves through a predefined
      finite state space under GEC authority.

   Mandate JWT (MJWT):
      As defined in [I-D.sato-soos-mjwt]: a WIMSE workload credential
      profile that grants an AI agent authority to perform a specified
      set of Cedar actions on a specific SO Instance under the oversight
      of a named human principal.

   Intent Declaration Primitive (IDP):
      As defined in [I-D.sato-soos-idp]: a structured object produced
      by an agent at the ACT step declaring the action, goal context,
      reasoning basis, confidence, and alternatives considered.

   Cedar:
      A policy language and evaluation engine [Cedar] used by the GEC
      to evaluate authorization decisions.

   Human Principal:
      A natural person who holds authority over an SO Instance, as
      identified in the Mandate JWT human_principal_id claim
      [I-D.sato-soos-mjwt].

   RETRY_CONTINUATION:
      An IDP reasoning_basis type [I-D.sato-soos-idp] Section 4.3
      used when an agent retries an action following a GEC DENY
      response, declaring the prior denial as the basis for the
      revised attempt.


3.  Problem Statement

3.1.  The Loop Gap

   The six live SOOS drafts -- IDP, HEM, GAR, CAP, SOV, and MJWT --
   collectively specify what must be declared, what must be escalated,
   what must be recorded, what is constitutionally prohibited, what
   resource is governed, and what credential binds the agent.  Each
   draft describes a component; none describes the cycle in which those
   components operate.

   The consequences of the missing loop specification are concrete:

   (a) SENSE ambiguity.  IDP Section 4.1 requires context_package_ref:
       a SHA-256 hash of the Context Package delivered to the agent
       before reasoning.  Without a normative definition of the Context
       Package -- its schema, its trigger types, its GEC delivery
       semantics -- this field has no interoperable meaning.
       Implementations cannot verify that the IDP's reasoning_basis
       references are grounded in the same context the GEC delivered.

   (b) PLAN unspecified.  HEM Section 5 references the Windley Loop
       [Windley-Loop] as the planning gate that precedes the enforcement
       gate.  SOV Section 7.1 defines SO state as a Cedar attribute
       available at evaluation time.  Neither specifies the GEC Query
       Interface through which the agent discovers valid transition
       paths, live permissions, and compensating action availability
       before submitting a Transition Request.

   (c) OBSERVE fragmented.  IDP Section 6 specifies the enriched DENY
       response; MJWT Section 8.2 specifies denial codes; HEM Section 4
       specifies the HEM_PENDING state entered at escalation.  No
       document specifies how the agent receives and processes these
       responses as part of a single normative OBSERVE step, or how the
       RETRY_CONTINUATION reasoning basis type [I-D.sato-soos-idp]
       Section 4.3 is to be used in the subsequent ACT.

   (d) Session state implicit.  HEM Section 3.2 defines HEM_PENDING
       as a session state.  GAR Section 6.1 defines SAR generation
       at session close.  IDP Section 5.1 defines the Transition
       Request submission.  No document defines the session itself: its
       initiation, its valid states, its event log markers, and its
       termination paths.

   This document closes all four gaps.

3.2.  Why Existing Agent Frameworks Are Insufficient

   Agent frameworks such as LangGraph, AutoGen, CrewAI, and the
   emerging Model Context Protocol [MCP] define agent loop abstractions.
   None provides the governance properties required by the SOOS
   protocol family:

   State-grounded SENSE.  Existing frameworks do not deliver a
   cryptographically bound, GEC-signed snapshot of a Sovereign Object
   Instance's current state to the agent before each iteration.
   The agent's context is whatever the application layer provides.

   Governed ACT.  Existing frameworks submit tool calls and API
   invocations without verifying that the agent holds a valid Mandate
   JWT, that the Cedar action is within scope, and that the human
   principal linkage is intact.  The GEC's 5-step execution sequence
   [I-D.sato-soos-mjwt] Section 8 has no equivalent.

   Non-suppressible OBSERVE.  Existing frameworks may log agent
   actions; none enforces that the log is append-only, GEC-signed, and
   non-modifiable by the agent.  The AEP OBSERVE step triggers the
   GAR [I-D.sato-soos-gar] recording that makes governance auditable.

   Human oversight integration.  Existing frameworks may pause for
   human input; none defines the HEM_PENDING session state, the five
   human decision types, the cascade revocation on TERMINATE, or the
   Progressive Trust signals generated by the escalation outcome.

3.3.  AEP as Architectural Integrator

   The AEP is the document that positions all other SOOS drafts as
   components of a single governed execution architecture.  From the
   perspective of an AEP-conforming implementation:

   - SOV defines what the agent operates on (the governed resource).
   - MJWT defines the credential that binds the agent to that resource.
   - IDP defines what the agent must declare before each ACT.
   - CAP defines constitutional prohibitions evaluated before Cedar.
   - HEM defines what happens when the GEC suspends the session.
   - GAR defines the audit artifacts generated throughout the session.

   The AEP specifies how these components interoperate at each step of
   the execution cycle.  An implementation that conforms to AEP
   automatically satisfies the integration requirements assumed by each
   component draft.


4.  The AEP Loop

4.1.  Overview

   The AEP defines five normative steps executed in strict order within
   each AEP Iteration.

   Step 1 -- SENSE:    GEC delivers Context Package to agent.
   Step 2 -- REASON:   Agent performs LLM-internal reasoning.
   Step 3 -- PLAN:     Agent queries GEC Query Interface.
   Step 4 -- ACT:      Agent submits Transition Request to GEC.
   Step 5 -- OBSERVE:  Agent receives and processes GEC response.

   After OBSERVE, the LOOP mechanism determines whether the next
   iteration begins (SENSE again) or the session closes.

   The REASON step is intentionally GEC-unspecified.  What LLM,
   reasoning strategy, prompting approach, or internal architecture
   the agent uses between SENSE and PLAN is opaque to this protocol.
   The AEP specifies only the inputs the agent MUST have received
   (SENSE), the services it MAY query (PLAN), the submission it MUST
   make (ACT), and the response it MUST process (OBSERVE).

   A session in HEM_PENDING state has exited the normal 5-step cycle.
   Section 5.3 specifies the HEM_PENDING protocol.  Resumption from
   HEM_PENDING re-enters the cycle at SENSE with trigger:
   HEM_RESOLUTION.

4.2.  Step 1 -- SENSE

   At SENSE, the GEC delivers a Context Package (Section 6) to the
   agent.  The Context Package carries the current state of the SO
   Instance the agent is authorized to operate on, the agent's current
   permission set, the current goal context, memory items from prior
   iterations, Proximity Events approaching threshold, and HEM context
   if the session is resuming from HEM_PENDING.

   SENSE requirements:

   (a) The GEC MUST write an AEP_SENSE_DELIVERED Event Stream entry
       (Section 10.1) before delivering the Context Package.  The
       entry MUST include the cp_hash of the Context Package to be
       delivered.

   (b) The Context Package MUST be delivered by the GEC, not
       constructed by the agent.  An agent MUST NOT construct or
       modify its own Context Package.

   (c) The agent MUST NOT submit a Transition Request (ACT) without
       first having received an AEP_SENSE_DELIVERED Event Stream entry
       for the current session iteration.  The IDP submitted at ACT
       MUST carry a context_package_ref matching the cp_hash of the
       most recently delivered Context Package.

   (d) The trigger field in the Context Package (Section 6.2) declares
       why this SENSE delivery occurred.  The agent MUST process the
       trigger semantics before reasoning.

   (e) At SESSION_START, the Context Package carries the initial SO
       Instance state.  On STATE_CHANGE, it carries the updated state
       following the prior ACT.  On HEM_RESOLUTION, it carries the
       human principal's decision and the updated HEM context.  On
       MANDATE_REVOCATION, it signals session termination.

4.3.  Step 2 -- REASON

   At REASON, the agent performs its internal LLM reasoning.  The AEP
   does not specify this step beyond its inputs and outputs.

   Required inputs to REASON:
   - The Context Package delivered at SENSE.
   - All prior AEP_SENSE_DELIVERED and GEC response history for this
     session, as the agent's own context.

   Required outputs from REASON (consumed at PLAN and ACT):
   - The Cedar action the agent intends to request.
   - A confidence value in the range [0.0, 1.0].
   - A draft reasoning_basis for the IDP to be submitted at ACT.
   - An escalation assessment for the IDP.
   - Alternatives considered and uncertainty flags, per agent class
     requirements (Section 13).

   REASON constraints:

   (a) The agent MUST NOT submit a Transition Request for any Cedar
       action not included in its current Mandate JWT cedar_actions
       array [I-D.sato-soos-mjwt] Section 4.2.3.  The Live Permission
       Map query at PLAN provides pre-computed authorization scope.

   (b) When OBSERVE returned a DENY response in the prior iteration,
       the RETRY_CONTINUATION reasoning_basis type MUST be used in
       the IDP submitted at the next ACT (Section 9.4).  The agent
       MUST NOT silently retry the same action with the same IDP.

   (c) When SENSE trigger is MANDATE_REVOCATION, the agent MUST NOT
       enter the REASON step.  It MUST proceed directly to graceful
       session shutdown (Section 5.4).

4.4.  Step 3 -- PLAN

   At PLAN, the agent queries GEC Query Interface services (Section 7)
   to inform its Transition Request before submission.  The PLAN step
   is a read-only interaction with the GEC; it does not modify SO
   Instance state.

   PLAN is the normative implementation of the Windley Loop
   [Windley-Loop]: the planning gate that precedes the enforcement
   gate.  The Windley Loop principle is that an agent SHOULD verify
   the feasibility and authorization of a planned action before
   committing to it, rather than discovering infeasibility at ACT.

   PLAN services:

   (a) Transition Graph query (Section 7.1): the agent queries the GEC
       for valid Cedar-authorized transition paths from the current SO
       state to the agent's declared goal state.  The returned graph
       enables the agent to select a viable action path before ACT.

   (b) Live Permission Map query (Section 7.2): the agent queries the
       GEC for the Cedar residual policy set applicable to its current
       Mandate JWT and the current SO Instance state.  The returned
       permitted_actions array MUST be used to validate the intended
       Cedar action before ACT.

   (c) Compensating Action Catalogue query (Section 7.3): OPTIONAL.
       The agent MAY query available compensating transitions from the
       current state if the intended action fails.  This query informs
       the compensating_action_assessed field in the IDP.

   PLAN conformance:

   Class 2 and Class 3 agents (Section 13) MUST query the Transition
   Graph at least once per AEP Session before submitting the first
   Transition Request.  Agents that deviate from the returned path
   MUST query the Transition Graph again before the deviation step.

4.5.  Step 4 -- ACT

   At ACT, the agent submits a Transition Request (Section 8) to the
   GEC.  The Transition Request carries the agent's Mandate JWT, the
   Cedar action identifier, and the Intent Declaration Primitive.

   ACT requirements:

   (a) The agent MUST submit exactly one Mandate JWT per Transition
       Request.  The Mandate JWT MUST carry the so_id of the SO
       Instance targeted by this Transition Request.

   (b) The agent MUST submit a well-formed IDP [I-D.sato-soos-idp]
       with every Transition Request.  Required IDP fields depend on
       the agent's class (Section 13).

   (c) The agent MUST NOT submit a second Transition Request while
       awaiting the GEC response to the first.  Concurrent transitions
       on the same SO Instance from the same agent are not permitted.

   (d) The GEC MUST execute its transition execution sequence
       [I-D.sato-soos-mjwt] Section 8 before Cedar evaluation.  The
       GEC MUST also evaluate CAP [I-D.sato-soos-cap] prohibitions
       before Cedar evaluation per [I-D.sato-soos-sov] Section 7.3.

   (e) The transition is atomic: it either completes fully or does not
       occur at all.  Partial execution is not a valid GEC state.

   The ACT step is the only step at which the SO Instance state can
   change.  SENSE, REASON, PLAN, and OBSERVE do not modify SO state.

4.6.  Step 5 -- OBSERVE

   At OBSERVE, the agent receives and processes the GEC response to
   its Transition Request.  Three response types are defined
   (Section 9): PERMIT, DENY, and HEM_PENDING.

   OBSERVE requirements:

   (a) The agent MUST process the OBSERVE response before entering
       the next iteration (SENSE).

   (b) On PERMIT: the agent receives the new SO Instance state,
       the updated Cedar residual, and the Event Stream entry
       reference.  The session continues.

   (c) On DENY: the agent receives an enriched DENY response
       [I-D.sato-soos-idp] Section 6 carrying the denial code and
       the IDP reasoning_basis fields that would change the decision.
       The agent MUST use RETRY_CONTINUATION reasoning basis in any
       subsequent IDP for the same action (Section 9.4).

   (d) On HEM_PENDING: the session has entered HEM_PENDING state
       (Section 5.3).  The agent MUST NOT submit further Transition
       Requests until HEM_PENDING is resolved.

   (e) The agent MUST NOT silently discard or ignore a DENY response.
       The DENY and the IDP are recorded in the SO Instance Event
       Stream regardless of whether the transition succeeded.  The
       agent's next reasoning cycle MUST account for the DENY.

4.7.  LOOP Mechanism

   After OBSERVE, the GEC evaluates whether the AEP Session continues.

   The session continues (next SENSE) when:
   - The OBSERVE response was PERMIT and the goal state is not yet
     reached.
   - The OBSERVE response was DENY and the session mandate has not
     expired.
   - HEM_PENDING has resolved with APPROVE, APPROVE_WITH_CONSTRAINTS,
     or REDIRECT.

   The session closes when:
   - The goal SO state is reached (closure_reason: GOAL_ACHIEVED).
   - The Mandate JWT expires before goal completion (MANDATE_EXPIRED).
   - The agent declares goal outcome (AGENT_DECLARED).
   - The GEE closes the session (GEE_CLOSED).
   - HEM resolves with TERMINATE (HEM_TERMINATED).
   - A MANDATE_REVOCATION SENSE trigger is received (MANDATE_REVOKED).
   - The GEC rejects the session (KERNEL_REJECTED).

   On session close, the GEC MUST write AEP_SESSION_CLOSED
   (Section 10.2) and the GAR MUST generate a Session Audit Record
   [I-D.sato-soos-gar] Section 6.

   State change at PERMIT triggers GEC re-injection: the GEC prepares
   the next Context Package for SENSE.  The aep_iteration counter
   MUST be incremented.


5.  Session Lifecycle

5.1.  Session Initiation

   An AEP Session is initiated when a human principal or an authorized
   agent requests that the GEC begin a governed session for a specific
   SO Instance under a specific Root Mandate JWT
   [I-D.sato-soos-mjwt] Section 6.1.

   Session initiation:

   (a) The GEC MUST verify the Root Mandate JWT per the 10-step
       verification protocol [I-D.sato-soos-mjwt] Section 8 before
       initiating the session.

   (b) The GEC MUST assign a unique session_id (UUID v7 [RFC9562]) and
       a goal_session_id (UUID v7) for the session.

   (c) The GEC MUST initialize the aep_iteration counter to 1.

   (d) The GEC MUST deliver the first Context Package with trigger:
       SESSION_START.  The GEC MUST write AEP_SENSE_DELIVERED before
       delivering this Context Package.

   (e) The session enters ACTIVE state.

5.2.  Active Session

   An ACTIVE session is a session in which the AEP loop is executing.
   In ACTIVE state:

   - The GEC MUST accept Transition Requests from the agent holding
     the session's Mandate JWT.
   - The GEC MUST deliver Context Packages at each SENSE.
   - The GEC MUST process Proximity Events and deliver them within
     the Context Package when triggered.
   - The GEC MAY transition the session to HEM_PENDING at any time
     a HEM trigger condition is met (Section 5.3).

5.3.  HEM_PENDING Session State

   HEM_PENDING is a valid, expected AEP Session state, not an error
   state.  An agent that correctly identifies a decision outside its
   confident operating range and signals escalation is performing
   correctly under the AEP.

   Entry into HEM_PENDING:

   The GEC enters HEM_PENDING when any HEM trigger class fires
   [I-D.sato-soos-hem] Section 3:
   - HEM_MANDATORY: Cedar returns DENY with hem_required: true.
   - HEM_AGENT_ESCALATED: IDP carries escalation_assessment with
     hem_urgency: REQUIRED and Cedar evaluation returns PERMIT.
   - HEM_PROXIMITY_TRIGGERED: a Proximity Event threshold is reached.

   The GEC MUST write HEM_INVOKED to the SO Instance Event Stream
   before the session enters HEM_PENDING.

   While HEM_PENDING:

   (a) The GEC MUST reject Transition Requests from this session
       with SESSION_HEM_PENDING.
   (b) Other agents' sessions on the same SO Instance are NOT
       affected.  HEM_PENDING is scoped to this AEP Session.
   (c) The SO Instance's state machine is NOT frozen.  Other agents
       with appropriate Mandate JWTs MAY continue transitions on the
       same SO Instance.

   Exit from HEM_PENDING:

   HEM_PENDING is exited when the human principal submits a
   HEMDecision [I-D.sato-soos-hem] Section 5:
   - APPROVE: the pending transition proceeds.  The GEC delivers a
     new SENSE with trigger: HEM_RESOLUTION.
   - APPROVE_WITH_CONSTRAINTS: as APPROVE, with additional Cedar
     fragments added to the session.
   - REDIRECT: the pending transition is abandoned.  The GEC delivers
     a new SENSE with trigger: HEM_RESOLUTION carrying the redirect
     instruction.
   - TERMINATE: the session closes.  AEP_SESSION_CLOSED written with
     closure_reason: HEM_TERMINATED.
   - DEFER: the HEM_PENDING timeout is extended.  The session remains
     in HEM_PENDING.  The agent receives no new SENSE.

   HEM_PENDING also exits on HEM_TIMEOUT if the timeout_at timestamp
   is reached before HEM_RESOLVED is committed.  Timeout disposition
   depends on urgency per [I-D.sato-soos-hem] Section 6.3.

5.4.  Session Closure

   All session closure paths MUST generate an AEP_SESSION_CLOSED
   Event Stream entry (Section 10.2).  The GEC MUST write
   AEP_SESSION_CLOSED on every closure path, including failures.

   On MANDATE_REVOCATION trigger at SENSE:

   The agent MUST NOT enter the REASON step.  The agent MUST perform
   graceful shutdown: completing any in-progress Zone B operations,
   recording a final goal outcome declaration if the agent is in
   standard mode, and confirming session closure to the GEC.  The GEC
   MUST write AEP_SESSION_CLOSED with closure_reason: MANDATE_REVOKED.
   In GEE mode, the GEE MUST NOT call agent.reason() after receiving
   a MANDATE_REVOCATION trigger.

   After AEP_SESSION_CLOSED, the GAR [I-D.sato-soos-gar] generates a
   Session Audit Record for the closed session.


6.  Context Package

6.1.  Context Package Schema

   The Context Package is the structured data object delivered by the
   GEC to the agent at SENSE.  It is the agent's ground truth about
   the SO Instance state, permissions, goal, memory, and session
   context at the start of each AEP Iteration.

   The following is the normative JSON structure of a Context Package.

   {
     "cp_version":     "1.0",        ; REQUIRED. Schema version.
     "cp_id":          string,        ; REQUIRED. UUID v7. CP identifier.
     "cp_hash":        string,        ; REQUIRED. SHA-256 of canonical CP.
     "delivered_at":   string,        ; REQUIRED. ISO 8601 timestamp.
     "trigger":        string,        ; REQUIRED. See Section 6.2.
     "so":             object,        ; REQUIRED. See Section 6.3.
     "permissions":    object,        ; REQUIRED. See Section 6.4.
     "goal":           object,        ; REQUIRED. See Section 6.5.
     "memory":         object,        ; RECOMMENDED. See Section 6.6.
     "proximity_events": [object],    ; REQUIRED. May be empty. Sec 6.7.
     "hem_context":    object | null, ; REQUIRED. See Section 6.8.
     "agent":          object         ; REQUIRED. See Section 6.9.
   }

   The GEC MUST compute cp_hash as a SHA-256 hash over the canonical
   JSON serialization of the Context Package excluding the cp_hash
   field itself.  The agent MUST record cp_hash as the
   context_package_ref in the IDP submitted at the next ACT.

6.2.  Context Package Trigger Types

   The trigger field declares the reason for this SENSE delivery.
   The following trigger values are defined:

   SESSION_START:
      First Context Package delivered for this AEP Session.

   STATE_CHANGE:
      The SO Instance has transitioned to a new state following the
      prior ACT.  The so.current_state field reflects the new state.

   PROXIMITY_EVENT:
      One or more Proximity Events in proximity_events have reached
      or exceeded their threshold.

   HEM_RESOLUTION:
      The session is resuming from HEM_PENDING following a human
      principal decision.  hem_context carries the HEMDecision.

   MANDATE_REFRESH:
      The GEC has refreshed the agent's Mandate JWT.  The permissions
      sub-object carries the updated mandate scope.

   MANDATE_REVOCATION:
      The agent's Mandate JWT has been revoked.  The agent MUST NOT
      enter REASON.  The session is being terminated.

6.3.  SO Sub-Object

   The so sub-object carries the current state of the SO Instance.

   {
     "so_id":           string,  ; REQUIRED. SO Instance UUID v7.
     "so_type_id":      string,  ; REQUIRED. SO Type identifier.
     "current_state":   string,  ; REQUIRED. Current state machine state.
     "current_phase":   string,  ; REQUIRED. SO lifecycle phase.
     "state_entered_at": string, ; REQUIRED. ISO 8601 timestamp.
     "event_log_head":  string,  ; REQUIRED. event_id of last entry.
     "zone_a_snapshot": object   ; REQUIRED. Current Zone A field values.
   }

   The zone_a_snapshot MUST reflect the Zone A state of the SO Instance
   as of event_log_head.  Personal data MUST NOT be present in
   zone_a_snapshot per [I-D.sato-soos-sov] Section 4.3.1 (INV-ZA-1).

6.4.  Permissions Sub-Object

   The permissions sub-object carries the agent's current authorization
   scope derived from the Mandate JWT.

   {
     "mandate_jwt_id":     string,   ; REQUIRED. MJWT jti.
     "mandate_expires_at": string,   ; REQUIRED. ISO 8601.
     "agent_class":        string,   ; REQUIRED. CLASS_1|CLASS_2|CLASS_3.
     "cedar_residual":     object,   ; REQUIRED. Residual Cedar policy set.
     "permitted_actions":  [string], ; REQUIRED. Cedar actions in scope.
     "forbidden_until":    [object]  ; OPTIONAL. Temporarily restricted actions.
   }

   Each entry in forbidden_until carries: action (string), reason
   (string), until (ISO 8601 | null).

   The cedar_residual is the GEC-computed partial evaluation of Cedar
   policy against the current SO Instance state and the agent's Mandate
   JWT scope.  Agents SHOULD use cedar_residual to inform REASON;
   however, Cedar evaluation at ACT is authoritative.

6.5.  Goal Sub-Object

   The goal sub-object carries the agent's current goal session context.

   {
     "goal_session_id":    string,   ; REQUIRED. UUID v7.
     "declared_goal_state": string,  ; REQUIRED. Target SO state.
     "goal_step_current":  integer,  ; REQUIRED. Current step number.
     "path_to_goal":       [object], ; REQUIRED. TransitionSteps to goal.
     "path_confidence":    number,   ; REQUIRED. Float 0.0-1.0.
     "prior_idp_ref":      string    ; OPTIONAL. Prior iteration IDP UUID.
   }

   Each TransitionStep in path_to_goal contains: step (integer),
   from_state (string), action (string), to_state (string),
   authority_sufficient (boolean), hem_required (boolean).

   path_to_goal MUST be GEC-computed from the current SO state to
   declared_goal_state using the SO Type's state machine and the
   agent's cedar_residual.  The agent MUST NOT modify path_to_goal.

6.6.  Memory Sub-Object

   The memory sub-object provides the agent with persistent context
   across AEP Iterations.

   {
     "episodic":                    [object], ; Prior iteration summaries.
     "active_constraints":          [object], ; Active session constraints.
     "compensating_actions_available": [object] ; Available compensations.
   }

   Episodic entries are GEC-generated summaries of prior iterations
   within this AEP Session.  The episodic store does not extend across
   sessions; cross-session agent memory is outside the scope of this
   document.

   active_constraints are additional Cedar policy fragments applied to
   this session, including fragments added by APPROVE_WITH_CONSTRAINTS
   HEM decisions [I-D.sato-soos-hem].

6.7.  Proximity Events

   The proximity_events array contains Proximity Event objects.  An
   empty array indicates no events are currently active.

   Each Proximity Event object:

   {
     "condition_id":        string,  ; REQUIRED. Unique condition identifier.
     "condition_type":      string,  ; REQUIRED. See below.
     "current_value":       string,  ; REQUIRED. Current observed value.
     "threshold_value":     string,  ; REQUIRED. Threshold value.
     "proximity_pct":       number,  ; REQUIRED. Float 0.0-1.0.
     "estimated_trigger_at": string  ; OPTIONAL. ISO 8601.
   }

   Defined condition_type values:

   HEM_TRIGGER_APPROACHING:
      A Cedar policy condition that will trigger mandatory HEM is being
      approached.  proximity_pct = 1.0 causes HEM_PENDING entry.

   MANDATE_EXPIRING:
      The agent's Mandate JWT exp claim is approaching.

   STATE_DURATION_THRESHOLD:
      The SO Instance has been in its current state longer than a
      threshold declared in the SO Type.

   ZONE_B_SENSOR_THRESHOLD:
      A sensor-linked Zone B attachment value is approaching a
      threshold declared in the SO Type.

   MANDATE_REVOCATION_PENDING:
      A scheduled future mandate revocation is approaching.
      estimated_trigger_at carries the scheduled revocation timestamp.

6.8.  HEM Context

   The hem_context field carries a HEMContext object when trigger is
   HEM_RESOLUTION, or is null otherwise.  The HEMContext schema is
   defined normatively in [I-D.sato-soos-hem] Section 4.

   When trigger is HEM_RESOLUTION:
   - hem_context MUST carry the full HEMContext including the human
     principal's HEMDecision.
   - The agent MUST process hem_context before entering REASON.
   - If HEMDecision is REDIRECT, the agent MUST update its declared
     goal state to match redirect_target_state.

6.9.  Agent Sub-Object

   The agent sub-object carries session metadata.

   {
     "agent_provider_id": string,  ; REQUIRED. Party Registry ID.
     "agent_type":        string,  ; REQUIRED. Agent implementation type.
     "aep_iteration":     integer, ; REQUIRED. Current iteration number.
     "session_id":        string   ; REQUIRED. AEP Session UUID v7.
   }

   The aep_iteration counter MUST be strictly monotonically increasing
   within a session.  Gaps are permitted; reversals are not.


7.  GEC Query Interface (PLAN Step)

7.1.  Transition Graph Query

   The Transition Graph query returns the set of valid Cedar-authorized
   transition paths from the current SO state to the agent's declared
   goal state.

   Request:
   {
     "so_id":            string,  ; REQUIRED.
     "mandate_jwt_id":   string,  ; REQUIRED.
     "goal_state":       string   ; REQUIRED.
   }

   Response:
   {
     "path_to_goal":    [TransitionStep], ; Computed at current state.
     "path_confidence": number,           ; Float 0.0-1.0.
     "blocked_actions": [object]          ; Actions blocked by Cedar.
   }

   The GEC MUST compute path_to_goal using the SO Type's state machine
   and the agent's Cedar residual.  Blocked paths due to Cedar policy
   MUST be included in blocked_actions with the blocking policy
   fragment reference.

   This is the normative implementation of the Windley Loop planning
   gate [Windley-Loop]: the agent discovers what it is authorized to
   do before committing to an action.

7.2.  Live Permission Map

   The Live Permission Map query returns the Cedar residual policy set
   applicable to the agent's current Mandate JWT and the current SO
   Instance state.

   Request:
   {
     "so_id":          string,  ; REQUIRED.
     "mandate_jwt_id": string   ; REQUIRED.
   }

   Response:
   {
     "cedar_residual":    object,   ; Current residual policy set.
     "permitted_actions": [string], ; Cedar actions currently in scope.
     "forbidden_until":   [object]  ; Temporarily restricted actions.
   }

   The Live Permission Map reflects the current state of Cedar
   evaluation; cedar_residual from the Context Package may be stale
   if the SO Instance has transitioned since SENSE delivery.  Agents
   SHOULD query the Live Permission Map when planning an action that
   depends on state entered since the last SENSE.

7.3.  Compensating Action Catalogue

   The Compensating Action Catalogue query returns available
   compensating transitions from the current SO state.

   Request:
   {
     "so_id":          string, ; REQUIRED.
     "mandate_jwt_id": string  ; REQUIRED.
   }

   Response:
   {
     "compensating_actions": [
       {
         "from_state":      string,  ; State this compensates from.
         "compensating_action": string, ; Cedar action available.
         "to_state":        string,  ; Resulting state.
         "authority_sufficient": boolean ; In agent's mandate scope.
       }
     ]
   }

   The Compensating Action Catalogue is used by the agent to assess
   the compensating_action_assessed field in the IDP and to plan
   rollback paths before a high-risk ACT.


8.  Transition Request (ACT Step)

8.1.  Transition Request Structure

   The Transition Request is submitted by the agent to the GEC at ACT.

   {
     "mandate_jwt":  string, ; REQUIRED. Compact-serialized MJWT.
     "cedar_action": string, ; REQUIRED. Cedar action identifier.
     "idp":          object  ; REQUIRED. Intent Declaration Primitive.
   }

   The cedar_action MUST be a string from the agent's Mandate JWT
   cedar_actions array.  The idp MUST be a well-formed IDP per
   [I-D.sato-soos-idp] with all fields required for the agent's class
   present (Section 13).

8.2.  GEC Execution Sequence

   On receiving a Transition Request, the GEC MUST execute the
   following sequence in strict order.  Failure at any step MUST abort
   the transition.

   Step 1 -- MJWT Verification.
      Execute the 10-step MJWT verification protocol
      [I-D.sato-soos-mjwt] Section 8.  Failure: DENY with appropriate
      MJWT deny code.

   Step 2 -- CAP Evaluation.
      Evaluate CAP Tier 0 (constitutional) and Tier 1 (jurisdictional)
      prohibitions [I-D.sato-soos-cap].  A CAP prohibition results in
      immediate DENY regardless of Cedar result.

   Step 3 -- Cedar Evaluation.
      Evaluate Cedar policy set with SO Instance state attributes
      [I-D.sato-soos-sov] Section 7 and IDP intent attributes
      [I-D.sato-soos-idp] Section 5.  DENY: return enriched DENY.
      DENY with hem_required: true: route to HEM (Section 5.3).
      PERMIT: proceed.

   Step 4 -- State Machine Validation.
      Verify the edge (current_state, cedar_action) exists in the SO
      Type's state machine.  Failure: DENY.

   Step 5 -- Event Stream Write.
      Append a StateTransitionEvent to the SO Instance Event Stream.
      The GEC MUST sign this entry.  The transition is NOT complete
      until this write succeeds.

   Step 6 -- Event Emission.
      The GEC MAY emit asynchronous notifications.  This step MUST
      NOT block the transition response.  Failure of event emission
      MUST NOT affect transition completeness.

   The transition is atomic: either all steps complete or the
   transition does not occur.

8.3.  IDP Submission at ACT

   The IDP is submitted as part of every Transition Request.  The IDP
   is permanently recorded in the SO Instance Event Stream as part of
   the StateTransitionEvent.  The IDP is recorded even for Cedar DENY
   outcomes: failed transition attempts are part of the permanent audit
   trail.

   The GEC MUST record the IDP verbatim as submitted.  The GEC MUST
   NOT validate IDP content beyond schema conformance.  Cedar does not
   evaluate IDP content; it is the agent's permanent reasoning
   declaration, not an authorization input.


9.  GEC Response (OBSERVE Step)

9.1.  PERMIT Response

   A PERMIT response indicates the transition completed successfully.

   {
     "result":              "PERMIT",
     "new_state":           string,  ; New SO current_state.
     "new_phase":           string,  ; New SO lifecycle phase.
     "event_stream_entry_id": string, ; UUID v7 of committed entry.
     "updated_cedar_residual": object, ; Updated residual policy.
     "aep_iteration":       integer  ; Current iteration number.
   }

   On PERMIT, the GEC prepares the next Context Package (trigger:
   STATE_CHANGE) and the LOOP mechanism initiates the next SENSE.
   The aep_iteration counter is incremented.

9.2.  DENY Response

   A DENY response indicates the transition was rejected.

   {
     "result":         "DENY",
     "deny_code":      string,   ; Deny code per [I-D.sato-soos-idp]
                                 ; Section 6 and [I-D.sato-soos-mjwt]
                                 ; Section 8.2.
     "deny_reason":    string,   ; Human-readable denial reason.
     "idp_ref":        string,   ; idp_id of the rejected IDP.
     "enrichment":     object,   ; IDP fields that would change result.
     "aep_iteration":  integer   ; Current iteration number.
   }

   The enrichment field carries the specific IDP reasoning_basis
   references that, if changed, would produce a PERMIT.  This is the
   mechanism by which the GEC guides the agent's next REASON step.

   On DENY, the SO Instance state does NOT change.  The GEC delivers
   the next Context Package (trigger: STATE_CHANGE is NOT fired; the
   trigger is omitted and the agent re-evaluates from the current
   state).

9.3.  HEM_PENDING Response

   An HEM_PENDING response indicates the session has entered
   HEM_PENDING state.

   {
     "result":        "HEM_PENDING",
     "hem_id":        string, ; UUID v7 of the HEM invocation.
     "trigger_class": string, ; HEM trigger class.
     "urgency":       string, ; ADVISORY|RECOMMENDED|REQUIRED.
     "timeout_at":    string  ; ISO 8601 | null.
   }

   On HEM_PENDING, the agent MUST NOT submit further Transition
   Requests.  The GEC will deliver a new SENSE with trigger:
   HEM_RESOLUTION when the human principal provides a decision.

9.4.  RETRY_CONTINUATION Handling

   When an agent retries an action following a GEC DENY response, the
   IDP submitted at the next ACT MUST include a reasoning_basis entry
   with ref_type: RETRY_CONTINUATION referencing the prior DENY.

   {
     "ref_type":     "RETRY_CONTINUATION",
     "ref_id":       string, ; idp_id of the rejected prior IDP.
     "content_hash": string, ; SHA-256 of the DENY response received.
     "weight":       "primary"
   }

   The RETRY_CONTINUATION entry MUST reference at least one additional
   reasoning_basis entry explaining what changed between the rejected
   attempt and the retry.  Silent retry -- submitting the same action
   with the same reasoning without acknowledging the prior DENY -- is
   not permitted.  The GEC MUST detect silent retry patterns via the
   prior_denial_count attribute [I-D.sato-soos-idp] Section 7.1.


10.  AEP Event Log Markers

10.1.  AEP_SENSE_DELIVERED

   The GEC MUST write this entry to the SO Instance Event Stream
   immediately before delivering each Context Package.

   {
     "event_type":      "AEP_SENSE_DELIVERED",
     "event_id":        string,  ; UUID v7.
     "prior_event_id":  string,  ; Previous entry event_id.
     "occurred_at":     string,  ; ISO 8601.
     "so_id":           string,  ; SO Instance UUID v7.
     "session_id":      string,  ; AEP Session UUID v7.
     "aep_iteration":   integer, ; Current iteration number.
     "cp_id":           string,  ; Context Package UUID v7.
     "cp_hash":         string,  ; SHA-256 of Context Package.
     "trigger":         string,  ; Context Package trigger type.
     "agent_id":        string,  ; Agent Party Registry identifier.
     "goal_session_id": string,  ; Goal session UUID v7.
     "gec_signature":   string   ; GEC Ed25519 signature.
   }

   The gec_signature MUST be computed over the canonical JSON of this
   entry.  AEP_SENSE_DELIVERED MUST be committed before the Context
   Package is delivered to the agent.

10.2.  AEP_SESSION_CLOSED

   The GEC MUST write this entry on every session termination path.

   {
     "event_type":       "AEP_SESSION_CLOSED",
     "event_id":         string,  ; UUID v7.
     "prior_event_id":   string,  ; Previous entry event_id.
     "occurred_at":      string,  ; ISO 8601.
     "so_id":            string,  ; SO Instance UUID v7.
     "session_id":       string,  ; AEP Session UUID v7.
     "goal_session_id":  string,  ; Goal session UUID v7.
     "total_iterations": integer, ; Count of completed AEP Iterations.
     "final_state":      string,  ; SO state at closure.
     "goal_achieved":    boolean, ; Whether declared goal state reached.
     "closure_reason":   string,  ; See below.
     "agent_id":         string,  ; Agent Party Registry identifier.
     "gec_signature":    string   ; GEC Ed25519 signature.
   }

   closure_reason values:

   GOAL_ACHIEVED:     Agent reached declared goal state.
   MANDATE_EXPIRED:   Mandate JWT expired before goal completion.
   AGENT_DECLARED:    Agent declared goal outcome explicitly.
   GEE_CLOSED:        GEE closed session in GEE mode.
   HEM_TERMINATED:    Human principal TERMINATE decision at HEM.
   KERNEL_REJECTED:   GEC rejected the session (policy violation).
   MANDATE_REVOKED:   Mandate JWT revoked during active session.

   After AEP_SESSION_CLOSED is committed, the GAR MUST generate a
   Session Audit Record [I-D.sato-soos-gar] Section 6 for the closed
   session.


11.  Standard Mode Conformance

   The following conformance rules apply in Standard Mode, in which
   the agent implements the full SENSE-REASON-PLAN-ACT-OBSERVE loop
   directly.

   Rule               Requirement                              Violation
   -----------------------------------------------------------------------
   CONF-AEP-01        Agent MUST NOT submit ACT before         REJECT
                      receiving AEP_SENSE_DELIVERED for
                      the current iteration.  IDP
                      context_package_ref MUST match cp_hash
                      of the most recent Context Package.

   CONF-AEP-02        Class 2 and Class 3 agents MUST query    REJECT
                      Transition Graph at least once per
                      session before first ACT.  Agents
                      deviating from returned path MUST
                      re-query before the deviation step.

   CONF-AEP-03        IDP submitted at ACT MUST be well-       REJECT
                      formed per [I-D.sato-soos-idp] Section
                      4.  Required fields per agent class
                      (Section 13) MUST be present.

   CONF-AEP-04        Agent MUST NOT submit a second ACT       REJECT
                      while awaiting response to the first.
                      Concurrent transitions on the same SO
                      Instance from the same agent session
                      are not permitted.

   CONF-AEP-05        All IDPs in a session MUST carry the     REJECT
                      same goal_session_id.  An IDP with a
                      mismatched goal_session_id MUST be
                      rejected.

   CONF-AEP-06        aep_iteration MUST be strictly           LOG
                      monotonically increasing within a
                      session.  Gaps are permitted;
                      reversals are not.

   CONF-AEP-07        Agent MUST use RETRY_CONTINUATION        LOG
                      reasoning basis after a DENY response
                      for the same action.  Silent retry is
                      not permitted.

   CONF-AEP-08        Agent MUST NOT enter REASON on a         REJECT
                      MANDATE_REVOCATION trigger.  Session
                      MUST proceed to graceful shutdown.

   HEM conformance rules (from [I-D.sato-soos-hem]):

   CONF-HEM-01        GEC MUST write HEM_INVOKED before        REJECT
                      session enters HEM_PENDING.

   CONF-HEM-02        Session in HEM_PENDING MUST NOT          REJECT
                      accept ACT from the same agent.
                      GEC MUST reject with SESSION_HEM_PENDING.

   CONF-HEM-03        HEM_RESOLVED MUST carry valid            REJECT
                      principal_signature from a human
                      Party Registry principal.

   CONF-HEM-04        Agent MUST NOT submit HEMDecision        REJECT +
                      for any session, including its own.      CONFORMANCE
                                                               _VIOLATION

   CONF-HEM-05        GEC MUST write HEM_TIMEOUT if            LOG
                      timeout_at reached before HEM_RESOLVED.

   CONF-HEM-06        After non-TERMINATE HEM_RESOLVED,        REJECT
                      GEC MUST deliver new SENSE with
                      trigger: HEM_RESOLUTION before
                      agent may submit next ACT.

   CONF-HEM-07        available_decisions in HEMContext         REJECT
                      MUST be GEC-computed, not agent-
                      supplied.


12.  GEE Orchestration Mode

12.1.  GEE Overview

   In GEE (Goal Execution Engine) Orchestration Mode, a GEC-provided
   engine inverts control: the agent exposes a single reasoning
   function and the GEE drives the AEP loop.  The GEE constructs
   Context Packages, calls agent.reason(), constructs the full
   Transition Request including the IDP, and submits it to the GEC.

   In GEE mode, the agent MUST NOT call the GEC transition endpoint
   directly.  The GEE is the sole submitter of Transition Requests.

   GEE mode is appropriate when:
   - The agent LLM is being called as a function within a larger
     orchestrated workflow.
   - The operator requires uniform IDP construction across multiple
     agent implementations.
   - The operator requires GEE-level Progressive Trust scoring
     independent of agent-level IDP claims.

12.2.  Agent Reasoning Interface

   In GEE mode the agent MUST implement the following function:

   reason(context_package: ContextPackage) -> ReasoningOutput

   ReasoningOutput:

   {
     "selected_action":          string,   ; Cedar action identifier.
     "confidence":               number,   ; Float 0.0-1.0.
     "intent_summary":           string,   ; Human-readable summary.
     "reasoning_basis":          [object], ; ReasoningRef array.
     "alternatives_considered":  [object], ; AlternativeRef array.
     "uncertainty_flags":        [string], ; UncertaintyFlag array.
     "escalation_assessment":    object,   ; EscalationAssessment.
     "agent_recommends_replan":  boolean,  ; Signal to GEE to replan.
     "replan_reason":            string    ; Replan explanation.
   }

   The GEE constructs the full IDP from ReasoningOutput plus session
   metadata (session_id, goal_session_id, aep_iteration, so_uuid,
   context_package_ref) that the GEE manages.

12.3.  GEE Conformance

   Rule               Requirement                              Violation
   -----------------------------------------------------------------------
   CONF-GEE-01        GEE MUST deliver normative Context       REJECT
                      Package before calling agent.reason().

   CONF-GEE-02        GEE MUST write AEP_SENSE_DELIVERED       REJECT
                      before delivering Context Package
                      to agent.

   CONF-GEE-03        GEE MUST construct complete IDP from     REJECT
                      ReasoningOutput before submitting
                      Transition Request.

   CONF-GEE-04        GEE MUST handle DENY by re-calling       REJECT
                      agent.reason() with enriched denial
                      context or invoking HEM.  Silent retry
                      is not permitted.  On MANDATE_REVOCATION
                      trigger, GEE MUST terminate loop and
                      write AEP_SESSION_CLOSED with closure_
                      reason: MANDATE_REVOKED.  GEE MUST NOT
                      call agent.reason() after revocation.

   CONF-GEE-05        GEE MUST write AEP_SESSION_CLOSED on     REJECT
                      all termination paths, including
                      failures.

   CONF-GEE-06        Agents operating in GEE mode MUST NOT    REJECT
                      call GEC transition endpoint directly.


13.  Agent Class Model

   The AEP defines three Agent Classes that determine the required
   field set for IDPs submitted at ACT.  Agent Class is declared in
   the Mandate JWT and reflects the level of autonomous authority
   granted to the agent.

   Class 1 -- Basic Agent:
      Agents with narrow, well-defined operational scope.  Minimal
      IDP required fields.  Typically used for single-action or
      single-step automations where human oversight is maintained
      through Cedar policy constraints rather than escalation
      assessment.

   Class 2 -- Standard Agent:
      Agents with multi-step operational scope operating within
      established patterns.  Required fields include goal_ref,
      confidence, and reasoning_basis.  These agents are expected to
      provide auditable reasoning but are not required to articulate
      alternatives considered or uncertainty flags at each step.

   Class 3 -- Autonomous Agent:
      Agents with broad operational scope operating with elevated
      autonomy.  All IDP fields are required, including alternatives_
      considered, uncertainty_flags, and escalation_assessment.  These
      agents are expected to proactively signal escalation when
      approaching their confident operating boundary.

   Agent Class determines IDP required fields as specified in
   [I-D.sato-soos-idp] Section 4.4.

   Confidence to autonomy level mapping:

   Confidence Range  Autonomy Level  Cedar Policy Implications
   ---------------------------------------------------------------
   0.0 - 0.59        UNCERTAIN       Cedar MAY require mandatory HEM
                                     before permitting Class 2/3 actions.
   0.60 - 0.79       STANDARD        Standard Cedar evaluation.
   0.80 - 0.89       HIGH            Cedar MAY permit elevated-autonomy
                                     actions otherwise restricted.
   0.90 - 1.00       VERIFIED        Cedar MAY permit actions otherwise
                                     gated behind mandate elevation,
                                     subject to policy.

   Agents MUST NOT treat the confidence field as a mechanism to
   bypass Cedar policy.  Systematic overconfidence -- high declared
   confidence followed by frequent DENYs or HEM invocations -- MUST
   be detectable via the Progressive Trust model [I-D.sato-soos-pt]
   and MUST result in authority review.


14.  Relationship to Other SOOS Drafts

   SOV [I-D.sato-soos-sov]:
      The Sovereign Object is the governed resource that the AEP loop
      operates on.  The so sub-object of the Context Package (Section
      6.3) carries the current SO Instance state at each SENSE.  The
      zone_a_snapshot reflects Zone A as of event_log_head.  The AEP
      session is scoped to a single SO Instance per Mandate JWT.

   MJWT [I-D.sato-soos-mjwt]:
      The Mandate JWT is verified at Step 1 of the GEC execution
      sequence (Section 8.2) for every Transition Request.  The MJWT
      so_id MUST match the SO Instance in the Context Package.  The
      permissions sub-object (Section 6.4) is derived from the MJWT.
      The MJWT cedar_actions array bounds the permitted_actions set.

   IDP [I-D.sato-soos-idp]:
      The IDP is submitted at every ACT step.  The IDP's
      context_package_ref binds each intent declaration to the SENSE
      delivery that preceded it.  RETRY_CONTINUATION (Section 9.4)
      is the IDP mechanism for acknowledged denial-and-retry.  Agent
      Class IDP requirements (Section 13) derive from IDP Section 4.4.

   HEM [I-D.sato-soos-hem]:
      HEM is invoked at Step 3 of the GEC execution sequence
      (Section 8.2) when Cedar returns DENY with hem_required: true.
      HEM_PENDING is an AEP Session state (Section 5.3).  The five
      HEM decision types determine AEP loop resumption or closure.
      HEM_RESOLUTION is an AEP Context Package trigger type.

   GAR [I-D.sato-soos-gar]:
      Every AEP_SENSE_DELIVERED and AEP_SESSION_CLOSED entry generates
      a GAR Type 1 self-audit entry.  At session close, GAR generates
      a Session Audit Record (SAR) covering all governance events in
      the session.  The SAR includes the complete IDP chain,
      delegation_chain from MJWTs, and HEM event history.

   CAP [I-D.sato-soos-cap]:
      CAP prohibitions are evaluated at Step 2 of the GEC execution
      sequence (Section 8.2), before Cedar evaluation.  A CAP Tier 0
      or Tier 1 prohibition produces an immediate DENY regardless of
      Cedar result.  CAP evaluation is transparent to the AEP loop;
      the agent receives a DENY at OBSERVE.


15.  Security Considerations

   The AEP loop is the outermost interface of the SOOS governance
   architecture.  Its security properties derive from the security
   properties of the component protocols it integrates.

   Context Package integrity.  The cp_hash field enables the agent
   to detect tampering with the delivered Context Package.  The GEC
   MUST sign AEP_SENSE_DELIVERED before delivery.  An agent that
   receives a Context Package whose cp_hash does not match the
   AEP_SENSE_DELIVERED entry MUST NOT proceed to REASON.  It MUST
   report the discrepancy as a critical security event.

   SENSE injection.  Malicious content in Zone B attachments MUST NOT
   be included in the zone_a_snapshot delivered at SENSE.  Zone A
   Invariant INV-ZA-1 [I-D.sato-soos-sov] Section 4.3.1 prohibits
   personal data in Zone A; implementations MUST also ensure that Zone
   B content cannot be injected into the zone_a_snapshot to influence
   agent reasoning with unsanctioned content.

   REASON opacity.  The AEP intentionally makes REASON opaque to the
   GEC.  This design property means the GEC cannot verify the
   correctness of the agent's reasoning -- only that the resulting
   Transition Request is authorized.  The IDP's reasoning_basis,
   confidence, and uncertainty_flags are the agent's self-attestation;
   their forensic value depends on the agent's integrity.  Progressive
   Trust scoring [I-D.sato-soos-pt] provides a longitudinal signal on
   reasoning calibration.

   ACT atomicity.  The 5-step GEC execution sequence (Section 8.2)
   MUST be atomic.  Partial execution creates governance gaps: a
   transition that is Cedar-permitted but not Event-Stream-committed
   is unauditable.  Implementations MUST ensure that Step 5 (Event
   Stream Write) succeeds or the transition is aborted.

   Silent retry detection.  CONF-AEP-07 requires RETRY_CONTINUATION
   on denial-and-retry.  The GEC MUST track prior_denial_count
   [I-D.sato-soos-idp] Section 7.1 to detect agents that submit
   repeated identical Transition Requests without acknowledging
   prior denials.  Systematic silent retry is an indicator of
   authorization bypass attempts.

   HEM_PENDING integrity.  While a session is in HEM_PENDING, the
   GEC MUST reject Transition Requests from that session.  An
   implementation that permits transitions from an HEM_PENDING session
   violates INV-12 and creates an authorization bypass vulnerability.


16.  Privacy Considerations

   The Context Package carries zone_a_snapshot.  Zone A Invariant
   INV-ZA-1 [I-D.sato-soos-sov] prohibits personal data in Zone A.
   Implementations MUST verify this invariant before including
   zone_a_snapshot in the Context Package.

   The goal sub-object (Section 6.5) carries declared_goal_state,
   which may reveal the human principal's intentions for the SO
   Instance.  Access to goal context MUST be controlled by Cedar
   policy.

   The episodic memory sub-object (Section 6.6) may contain
   references to prior agent actions.  While episodic entries MUST
   NOT contain personal data directly, they may contain identifiers
   that correlate to personal data in Zone B.  Implementations MUST
   apply appropriate access controls to episodic memory entries.

   AEP_SENSE_DELIVERED and AEP_SESSION_CLOSED entries in the SO
   Instance Event Stream carry agent_id and session_id values.
   These entries may constitute personal data under GDPR Article 4(1)
   [GDPR] and APPI Article 2 [APPI] where the agent is associated
   with an identifiable natural person.  Implementations MUST apply
   appropriate access controls to Event Stream queries.


17.  IANA Considerations

17.1.  AEP Context Package Trigger Registry

   Registry name: Agent Execution Protocol Context Package Trigger Registry
   Registration procedure: Specification Required.

   Initial registrations:

   Trigger Value       Description
   SESSION_START       First CP delivered for a new AEP Session.
   STATE_CHANGE        SO Instance transitioned since last SENSE.
   PROXIMITY_EVENT     One or more Proximity Events at threshold.
   HEM_RESOLUTION      Session resuming from HEM_PENDING.
   MANDATE_REFRESH     Mandate JWT refreshed.
   MANDATE_REVOCATION  Mandate JWT revoked; session terminating.

17.2.  AEP Session Closure Reason Registry

   Registry name: Agent Execution Protocol Session Closure Reason Registry
   Registration procedure: Specification Required.

   Initial registrations:

   Closure Reason     Description
   GOAL_ACHIEVED      Agent reached declared goal state.
   MANDATE_EXPIRED    Mandate JWT expired before goal completion.
   AGENT_DECLARED     Agent declared goal outcome explicitly.
   GEE_CLOSED         GEE closed the session in GEE mode.
   HEM_TERMINATED     Human principal TERMINATE decision at HEM.
   KERNEL_REJECTED    GEC rejected the session.
   MANDATE_REVOKED    Mandate JWT revoked during active session.

17.3.  AEP Proximity Event Condition Type Registry

   Registry name: Agent Execution Protocol Proximity Event Condition
                  Type Registry
   Registration procedure: Specification Required.

   Initial registrations: As listed in Section 6.7.

17.4.  AEP Agent Class Registry

   Registry name: Agent Execution Protocol Agent Class Registry
   Registration procedure: Standards Action.

   Initial registrations:

   Class Value  Description
   CLASS_1      Basic Agent.
   CLASS_2      Standard Agent.
   CLASS_3      Autonomous Agent.


18.  References

18.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC7519]  Jones, M., Bradley, J., and N. Sakimura, "JSON Web
              Token (JWT)", RFC 7519, May 2015.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, May 2017.

   [RFC8037]  Liusvaara, I., "CFRG Elliptic Curves for JOSE",
              RFC 8037, January 2017.

   [RFC9562]  Davis, B., Peabody, C., and P. Leach, "Universally
              Unique IDentifiers (UUIDs)", RFC 9562, May 2024.

   [RFC6234]  Eastlake, D. and T. Hansen, "US Secure Hash Algorithms
              (SHA and SHA-based HMAC and HKDF)", RFC 6234, May 2011.

   [Cedar]    Amazon Web Services, "Cedar Policy Language
              Specification", https://docs.cedarpolicy.com/

   [I-D.sato-soos-idp]
              Sato, T., "The Intent Declaration Primitive (IDP) for
              Agentic AI Systems", draft-sato-soos-idp-03, May 2026.

   [I-D.sato-soos-hem]
              Sato, T., "The Human Escalation Mechanism (HEM) for
              Agentic AI Systems", draft-sato-soos-hem-01, May 2026.

   [I-D.sato-soos-gar]
              Sato, T., "Governance Audit Record (GAR) for Agentic
              AI Systems", draft-sato-soos-gar-01, May 2026.

   [I-D.sato-soos-cap]
              Sato, T., "Constitutional AI Protocol (CAP) for Agentic
              AI Systems", draft-sato-soos-cap-00, May 2026.

   [I-D.sato-soos-sov]
              Sato, T., "The Sovereign Object (SOV) for Agentic AI
              Systems", draft-sato-soos-sov-00, May 2026.

   [I-D.sato-soos-mjwt]
              Sato, T., "The Mandate JWT (MJWT) for Agentic AI
              Systems", draft-sato-soos-mjwt-00, May 2026.

   [I-D.ietf-wimse-arch]
              Salomoni, D., et al., "WIMSE Architecture",
              draft-ietf-wimse-arch, work in progress.

   [GDPR]     European Parliament, "General Data Protection
              Regulation", Regulation (EU) 2016/679, April 2016.

   [APPI]     Government of Japan, "Act on the Protection of Personal
              Information", Act No. 57 of 2003, as amended.

18.2.  Informative References

   [I-D.sato-soos-pt]
              Sato, T., "Progressive Trust (PT) for Agentic AI
              Systems", draft-sato-soos-pt-00, forthcoming.

   [I-D.sato-soos-faip]
              Sato, T., "Federated Agent Intelligence Protocol
              (FAIP)", draft-sato-soos-faip-00, forthcoming.

   [I-D.sato-soos-mad]
              Sato, T., "Multi-Agent Delegation (MAD) for Agentic
              AI Systems", draft-sato-soos-mad-00, forthcoming.

   [I-D.ietf-scitt-architecture]
              Birkholz, H., et al., "An Architecture for Trustworthy
              and Transparent Digital Supply Chains",
              draft-ietf-scitt-architecture, work in progress.

   [I-D.mcguinness-oauth-actor-profile]
              McGuinness, K., et al., "OAuth Actor Profile",
              draft-mcguinness-oauth-actor-profile-00, 2026.

   [I-D.mcguinness-oauth-mission-bound-authorization]
              McGuinness, K., et al., "Mission Bound Authorization",
              draft-mcguinness-oauth-mission-bound-authorization-00,
              2026.

   [Windley-Loop]
              Windley, P., "The Windley Loop: Planning and Enforcement
              Gates in Agentic AI Authorization", personal
              communication, 2025.

   [EUAIA]    European Parliament, "Artificial Intelligence Act",
              Regulation (EU) 2024/1689, June 2024.

   [MCP]      Anthropic, "Model Context Protocol",
              https://modelcontextprotocol.io/, 2024.


Appendix A.  ATP Booking Object -- AEP Reference Walk-Through

   The ATP Booking Object is the reference implementation of the
   Sovereign Object primitive [I-D.sato-soos-sov] Appendix A.  This
   walk-through illustrates a single AEP Iteration for the Azusa
   Journey scenario: an OTA booking agent advancing a booking from
   CONFIRMED to PRE_ACTIVITY.

A.1.  SENSE

   The GEC delivers a Context Package with trigger: SESSION_START.
   The so sub-object carries:
   - so_id: "019547ab-1234-7abc-8def-000000000099"
   - so_type_id: "atp/booking-object/1.0"
   - current_state: "CONFIRMED"
   - current_phase: "ACTIVE"
   - zone_a_snapshot: { booking_reference: "MYA-2026-04521",
                        activity_id: "PH-TRAIL-001",
                        journey_date: "2026-06-15" }

   The permissions sub-object carries:
   - permitted_actions: ["atp:booking:confirm", "atp:booking:cancel",
                         "atp:booking:pre_activity_open",
                         "atp:booking:suspend"]
   - mandate_ceiling: 2
   - agent_class: "CLASS_2"

A.2.  REASON

   The OTA booking agent reasons: the booking is CONFIRMED, journey
   date is 2026-06-15, current date is 2026-06-14.  Pre-activity
   collection should begin.  Selected action: atp:booking:pre_activity_open.
   Confidence: 0.91 (VERIFIED).  No uncertainty flags.

A.3.  PLAN

   Transition Graph query confirms: CONFIRMED -> PRE_ACTIVITY via
   atp:booking:pre_activity_open is a valid path.  authority_sufficient:
   true.  hem_required: false.

   Live Permission Map confirms: atp:booking:pre_activity_open is in
   permitted_actions for current state CONFIRMED.

A.4.  ACT

   Transition Request submitted:
   - mandate_jwt: <root mandate, so_id bound, mandate_ceiling: 2>
   - cedar_action: "atp:booking:pre_activity_open"
   - idp: {
       action: "atp:booking:pre_activity_open",
       so_uuid: "019547ab-1234-7abc-8def-000000000099",
       transition_from: "CONFIRMED",
       transition_to: "PRE_ACTIVITY",
       goal_ref: "goal-session-azusa-journey-001",
       goal_step: 1,
       confidence: 0.91,
       reasoning_basis: [
         { ref_type: "so_graph_node", ref_id: "booking_reference",
           weight: "primary" },
         { ref_type: "zone_b_attachment", ref_id: "journey_date_doc",
           weight: "primary" }
       ],
       intent_summary: "Booking confirmed and journey date tomorrow.
                        Opening pre-activity collection phase.",
       escalation_assessment: {
         agent_recommends_hem: false,
         hem_urgency: "ADVISORY"
       }
     }

   GEC execution sequence:
   Step 1: MJWT verified. so_id matches. Not revoked. Within exp.
   Step 2: CAP -- no Tier 0 or Tier 1 prohibition applies.
   Step 3: Cedar -- PERMIT. autonomy_level VERIFIED. No HEM required.
   Step 4: State machine -- edge (CONFIRMED, atp:booking:pre_activity_open)
           exists. Transition to PRE_ACTIVITY valid.
   Step 5: Event Stream Write committed. StateTransitionEvent signed.

A.5.  OBSERVE

   GEC returns PERMIT response:
   - new_state: "PRE_ACTIVITY"
   - new_phase: "ACTIVE"
   - event_stream_entry_id: "event-id-0042"

   GAR records the IDP, the PERMIT result, and the delegation chain
   from the MJWT.  AEP_SENSE_DELIVERED is already in the Event Stream.

   The LOOP mechanism prepares the next Context Package with trigger:
   STATE_CHANGE, current_state: PRE_ACTIVITY.  The next SENSE
   delivers it to the agent.  aep_iteration increments to 2.


Author's Address

   Tom Sato
   MyAuberge K.K.
   Chino, Nagano, Japan
   Email: tomsato@myauberge.jp
   URI:   https://activitytravel.pro/
