The Agent Execution Protocol (AEP) for Agentic AI Systems
draft-sato-soos-aep-04
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Author | Tom Sato | ||
| Last updated | 2026-09-07 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Additional resources |
Additional Web Page
|
||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-sato-soos-aep-04
Network Working Group T. Sato
Internet-Draft MyAuberge K.K.
Intended status: Standards Track 7 September 2026
Expires: 7 March 2027
The Agent Execution Protocol (AEP) for Agentic AI Systems
draft-sato-soos-aep-04
Abstract
An AI agent that can act cannot be governed unless there is a
normative contract for how it receives its world, how it declares
its intent, and how it learns what it is and is not permitted to
do -- at every step, in every iteration, without exception.
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, the Mandate JWT, the Human Escalation
Mechanism, the Governance Audit Record, the Constitutional AI
Protocol, and the Sovereign Object 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.
Version -02 adds: XPID binding at session open (GEC MUST bind XPID
from KIA-verified Party Registry; MUST NOT accept client-supplied
XPID); STALLED and PLAN_B_ACTIVE session states with full normative
definitions, trigger conditions, and resume conditions; Expected
Outcome Declaration (EOD) as a pre-session commitment structure with
primary outcome, acceptance envelope, and pre-declared Plan B;
RETRY_CONTINUATION normative strengthening with what-changed-since-
last-attempt requirement and prior_denial_count Cedar attribute;
an AEP-to-OTel mapping with mandatory span attributes at each AEP
phase; four new Security Considerations; and updated IANA
registrations for new state codes and EOD media type.
Version -03 adds Step 4a of the GEC execution sequence: DAM
lineage and residency validation. When a Transition Request's
optional da_production field is present, the GEC resolves every
referenced input artifact, confirms each is in a VALID lifecycle
state, and computes the resulting artifact's data_residency under
the applicable narrowing rule -- before the transition's Event
Stream write occurs, and under the same signature as that write.
This is the enforcement point for a rule the data governance
companion specification had defined but this document, until now,
gave no mechanism to actually apply.
Version -04 is an editorial revision with no normative content
changes: the KEE-1 citation was migrated from the versioned
[I-D.sato-soos-kee] form to the non-versioned [SOOS-KEE] form,
since KEE-1 is a permanent local-only specification that will
never be submitted to the IETF Datatracker.
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 7 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
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 (with XPID Binding) (NEW in -02)
5.2. Active Session
5.3. HEM_PENDING Session State
5.4. STALLED Session State (NEW in -02)
5.5. PLAN_B_ACTIVE Session State (NEW in -02)
5.6. Session Closure
6. Expected Outcome Declaration (EOD) (NEW in -02)
6.1. EOD Purpose and Role
6.2. EOD Schema
6.3. EOD Lifecycle
6.4. Plan B Integration
6.5. EOD and IDP Binding
7. Context Package
7.1. Context Package Schema
7.2. Context Package Trigger Types
7.3. SO Sub-Object
7.4. Permissions Sub-Object
7.5. Goal Sub-Object
7.6. Memory Sub-Object
7.7. Proximity Events
7.8. HEM Context
7.9. Agent Sub-Object
8. GEC Query Interface (PLAN Step)
8.1. Transition Graph Query
8.2. Live Permission Map
8.3. Compensating Action Catalogue
9. Transition Request (ACT Step)
9.1. Transition Request Structure
9.2. GEC Execution Sequence
9.3. IDP Submission at ACT
10. GEC Response (OBSERVE Step)
10.1. PERMIT Response
10.2. DENY Response
10.3. HEM_PENDING Response
10.4. RETRY_CONTINUATION Handling (REVISED in -02)
11. AEP Event Log Markers
11.1. AEP_SENSE_DELIVERED
11.2. AEP_SESSION_CLOSED
11.3. AEP_STALLED (NEW in -02)
11.4. AEP_PLAN_B_ACTIVATED (NEW in -02)
12. AEP-to-OTel Mapping (NEW in -02)
12.1. Overview
12.2. Mandatory Span Attributes by Phase
12.3. OTel Conformance Rules
13. Standard Mode Conformance
14. GEE Orchestration Mode
14.1. GEE Overview
14.2. Agent Reasoning Interface
14.3. GEE Conformance
15. Agent Class Model
16. Relationship to Other SOOS Drafts
17. Security Considerations
18. Privacy Considerations
19. IANA Considerations
20. References
20.1. Normative References
20.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.
The AEP's PLAN step is the normative IETF specification of the
Windley Loop pattern: the principle that an agent should query its
authorized action space before committing to a plan, rather than
discovering infeasibility at execution time [OVID-Loop]. The
Windley Loop concept was articulated by Phil Windley [Windley-Loop]
and formalized by Clawdrey Hepburn, whose OVID-ME implementation
[OVID-ME] demonstrates the pattern operating in production against
Cedar-based agent mandates. AEP specifies the full normative loop
-- SENSE, REASON, PLAN, ACT, OBSERVE -- of which the Windley Loop
planning gate is the PLAN step. The OBSERVE re-query (policies may
change between iterations) and the HEM_PENDING session state (human
principal suspension) are AEP additions to the base Windley Loop
that extend it into a complete governed execution architecture.
If you are building an agentic AI system today, the absence of a
normative execution loop means your agent submits actions without a
standard protocol for delivering the state and permission context it
needs to reason correctly, your GEC enforces policy without a
standard protocol for communicating denial rationale back to the
agent, and your human oversight mechanism invokes without a normative
session state governing the resulting suspension. AEP closes this
gap by specifying the five-step normative loop -- SENSE, REASON,
PLAN, ACT, OBSERVE -- that makes every SOOS component protocol
composable into a single governed execution architecture. Without
AEP, each component specifies its own assumptions about the execution
context in which it operates; those assumptions are neither
guaranteed nor verifiable across implementations.
Version -02 adds XPID binding at session initiation, STALLED and
PLAN_B_ACTIVE session states, the Expected Outcome Declaration (EOD)
structure, strengthened RETRY_CONTINUATION requirements, and an
AEP-to-OTel mapping section. These additions make the AEP loop
observable, pre-committed, and more resilient to systematic retry
bypass patterns.
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 five states: ACTIVE, HEM_PENDING,
STALLED, PLAN_B_ACTIVE, 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.
Expected Outcome Declaration (EOD):
A pre-session commitment structure submitted by the agent or its
operator before the first SENSE delivery. Specifies the primary
expected outcome, the acceptance envelope for success
determination, and a pre-declared Plan B for activation if the
primary path is
blocked. (NEW in -02)
STALLED Session State:
An AEP Session state in which the agent has been unable to make
progress toward the declared goal state for a GEC-defined
iteration count or time window, and no viable alternative path
is available without human direction. STALLED is not an error
state; it is a governed signal that the session requires human
attention. (NEW in -02)
PLAN_B_ACTIVE Session State:
An AEP Session state in which the agent's primary path to the
declared goal state has been confirmed blocked or DENIED, and
the GEC has activated the pre-declared Plan B from the EOD. The
agent operates under Plan B constraints until the Plan B outcome
is reached or the session escalates. (NEW in -02)
XPID:
The Cross-Principal Identifier assigned to an agent by the GEC
at session open. Derived from the KIA-verified Party Registry
entry for the agent provider, per [I-D.sato-soos-kia] Section 5.
The XPID is bound to the AEP Session at initiation and MUST NOT
be accepted from the client. (NEW in -02)
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 [RFC7519] 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. See Section 10.4 for strengthened requirements
in AEP-02.
3. Problem Statement
3.1. The Loop Gap
The live SOOS drafts -- IDP, HEM, GAR, CAP, SOV, MJWT, KIA, and
MAD -- collectively specify what must be declared, what must be
escalated, what must be recorded, what is constitutionally
prohibited, what resource is governed, what credential binds the
agent, how agents are identified, and how delegation is governed.
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 [RFC6234] 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 1 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 HEM session states including HEM_PENDING. 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 4.1 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. Version -02 additionally closes
three gaps identified after the -01 submission:
(e) Agent identity not bound at session open. AEP-01 specified
Mandate JWT verification at each ACT step but did not specify
when or how the GEC binds the Cross-Principal Identifier (XPID)
to the AEP Session. A session that allows a client to supply
its own XPID is vulnerable to identity substitution attacks.
Section 5.1 closes this gap.
(f) No stall state. AEP-01 had no state for sessions that cannot
make progress without human direction but have not triggered a
HEM condition. Agents that silently exhaust their iteration
budget making no progress are governed as normal sessions.
Sections 5.4 and 5.5 close this gap.
(g) No pre-session outcome commitment. AEP-01 had no mechanism for
an agent to commit to its expected outcome and fallback strategy
before beginning execution. This gap means the GEC cannot
distinguish an agent that failed unexpectedly from one that
executed its pre-declared Plan B. Section 6 closes this gap.
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 execution sequence
(Section 9.2) 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.
Windley Loop implementations. OVID-ME [OVID-ME] implements the
Windley Loop [OVID-Loop] within a single Cedar-based trust domain,
demonstrating that pre-ACT policy querying reduces authorization
failures and enables precise escalation. OVID-ME does not specify
the full AEP session lifecycle, the HEM_PENDING state, the
RETRY_CONTINUATION mechanism, the IDP per-step intent declaration,
the STALLED state, the EOD pre-session commitment, or the non-
suppressible GAR audit trail. AEP is not a replacement for OVID-ME;
it is the standards-track specification that makes the Windley Loop
pattern interoperable across implementations and provides the
governance layer above it.
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.
- KIA defines the Party Registry entry that the GEC uses to derive
the agent's XPID at session open.
- 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.
- MAD defines the delegation structure for multi-agent sessions.
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. A session in
STALLED state has exited the normal 5-step cycle pending human
direction. Section 5.4 specifies the STALLED protocol. A session
in PLAN_B_ACTIVE state continues the 5-step cycle under Plan B
constraints. Section 5.5 specifies the PLAN_B_ACTIVE protocol.
4.2. Step 1 -- SENSE
At SENSE, the GEC delivers a Context Package (Section 7) 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 11.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 7.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. On
STALL_RESOLVED, it carries the human principal's direction
following resolution of the STALLED state (Section 5.4).
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 15).
- A reasoning_mode classification per [I-D.sato-soos-idp]
Section 4.3.1, when the mode is other than ROUTINE. Agents
SHOULD declare reasoning_mode for all non-ROUTINE iterations.
When absent, the GEC treats the IDP as ROUTINE for any
analytics or pattern analysis purposes.
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 10.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.6).
(d) When SENSE trigger is STALL_RESOLVED, the agent MUST process
the resolution direction before entering REASON. The resolution
direction MUST be reflected in the reasoning_basis of the next
IDP submitted at ACT.
4.4. Step 3 -- PLAN
At PLAN, the agent queries GEC Query Interface services (Section 8)
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 8.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 8.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 8.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 15) 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.
When SENSE delivers a STALL_RESOLVED trigger, the agent MUST query
the Transition Graph before submitting the next ACT, regardless of
agent class. The prior path_to_goal MUST be treated as stale.
4.5. Step 4 -- ACT
At ACT, the agent submits a Transition Request (Section 9) 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 15).
(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
(Section 9.2) 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.
(f) When the session is in PLAN_B_ACTIVE state (Section 5.5), the
IDP MUST carry a plan_b_ref field referencing the activated Plan
B from the EOD (Section 6). ACT submissions that do not carry
plan_b_ref in PLAN_B_ACTIVE state MUST be rejected.
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 10): 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 10.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.
(f) When the GEC determines the session has entered STALLED
conditions (Section 5.4), OBSERVE returns a STALLED response.
The agent MUST NOT submit further ACT requests until the STALLED
state resolves via STALL_RESOLVED trigger at SENSE.
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 and the stall threshold has not been reached.
- HEM_PENDING has resolved with APPROVE, APPROVE_WITH_CONSTRAINTS,
or REDIRECT.
- STALLED has resolved with STALL_RESOLVED.
- PLAN_B_ACTIVE: the Plan B sub-goal is not yet reached.
The session closes when:
- The goal SO state is reached (closure_reason: GOAL_ACHIEVED).
- The Plan B outcome is reached in PLAN_B_ACTIVE state
(closure_reason: PLAN_B_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).
- The SO Cluster of which this session is a member reaches
UNACHIEVABLE achievability state (CLUSTER_HALT).
- The STALLED state is not resolved within the GEC-defined STALL
timeout (STALL_TIMEOUT).
On session close, the GEC MUST write AEP_SESSION_CLOSED
(Section 11.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 (with XPID Binding) (NEW in -02)
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 MJWT
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.
XPID binding at session open (NEW in -02):
(d) The GEC MUST derive the agent's XPID from the KIA-verified
Party Registry entry for the agent provider identified in the
Root Mandate JWT agent_provider_id field, per the XPID
derivation procedure in [I-D.sato-soos-kia] Section 5.
(e) The GEC MUST bind the derived XPID to the AEP Session at
initiation. The session_xpid field in AEP_SENSE_DELIVERED
(Section 11.1) MUST carry this value.
(f) The GEC MUST NOT accept a client-supplied XPID. Any session
initiation request that includes an agent-provided XPID claim
MUST be rejected with INVALID_XPID_CLAIM. The XPID is always
GEC-derived; its integrity depends on this constraint.
(g) The GEC MUST verify that the agent_provider_id in the Root
Mandate JWT resolves to an active, non-revoked Party Registry
entry in the KIA registry [I-D.sato-soos-kia]. A session
initiation request for an agent whose Party Registry entry is
absent, suspended, or revoked MUST be rejected with
AGENT_NOT_REGISTERED.
EOD submission at session open (NEW in -02):
(h) Class 3 agents MUST submit an EOD (Section 6) before or at
session initiation. The GEC MUST NOT deliver the first Context
Package to a Class 3 agent until a valid EOD has been received
and recorded.
(i) Class 2 agents SHOULD submit an EOD. When an EOD is absent for
a Class 2 agent, the GEC records EOD_ABSENT in the Session Audit
Record. Cedar policies MAY require EOD presence as a permit
condition for Class 2 agents on high-risk SO Types.
(j) Class 1 agents are not required to submit an EOD.
(k) The GEC MUST deliver the first Context Package with trigger:
SESSION_START. The GEC MUST write AEP_SENSE_DELIVERED before
delivering this Context Package.
(l) 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).
- The GEC MAY transition the session to STALLED if the stall
conditions defined in Section 5.4 are met.
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 5:
- 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 8:
- 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 10.2.
5.4. STALLED Session State (NEW in -02)
STALLED is an AEP Session state in which the agent cannot make
progress toward the declared goal state without human direction.
STALLED is not an error state. It is a governed signal that the
session has reached a condition where continued autonomous execution
without human input would be either futile or unsafe.
STALLED differs from HEM_PENDING in origin: HEM_PENDING is entered
because a specific action triggered a governance escalation.
STALLED is entered because the session as a whole has reached a
progress boundary without any single action triggering HEM.
Entry into STALLED:
The GEC MUST enter STALLED when any of the following conditions
are met:
(a) STALL_DENY_THRESHOLD: the session has received N consecutive
DENY responses (where N is defined in the SO Type or defaults
to 5) without a PERMIT. The agent has exhausted its retry
capacity without making progress.
(b) STALL_PATH_EXHAUSTED: the Transition Graph query (Section 8.1)
returns an empty path_to_goal AND no compensating actions are
available, AND the session is not in HEM_PENDING. No path from
the current SO state to the declared goal state exists that the
agent has authority to traverse.
(c) STALL_PLAN_B_BLOCKED: the session is in PLAN_B_ACTIVE state
and the Plan B path has also been exhausted without reaching the
Plan B outcome.
(d) STALL_ITERATION_LIMIT: the aep_iteration counter exceeds the
mandate's declared iteration ceiling without goal achievement.
On entry to STALLED:
(e) The GEC MUST write AEP_STALLED (Section 11.3) to the Event
Stream immediately. The entry MUST carry the stall_reason and
the aep_iteration count at which STALLED was entered.
(f) The GEC MUST reject subsequent ACT submissions with
SESSION_STALLED until the STALLED state is resolved.
(g) The GEC MUST notify the human principal via HEM
[I-D.sato-soos-hem] with urgency RECOMMENDED. The STALLED
notification is distinct from a HEM escalation: it does not
move the session to HEM_PENDING unless the human principal
responds with an active decision.
(h) The GEC SHOULD surface the stall_reason and the prior
DENY chain to the human principal in the notification.
Exit from STALLED:
(i) The human principal submits a STALL_DIRECTION response via the
HEM interface. STALL_DIRECTION options:
- REDIRECT_GOAL: the human principal sets a new goal state.
The GEC delivers SENSE with trigger: STALL_RESOLVED carrying
the new declared_goal_state.
- ACTIVATE_PLAN_B: if an EOD Plan B is declared (Section 6.4),
the GEC activates it. The session transitions to
PLAN_B_ACTIVE (Section 5.5).
- ESCALATE_TO_HEM: the human principal treats the stall as a
full HEM escalation. The session transitions to HEM_PENDING.
- CLOSE: the human principal closes the session with
closure_reason: STALL_TIMEOUT (even if the timeout has not
been reached).
(j) The STALLED state has a maximum duration equal to the HEM
timeout applicable to the session's SO Type. If the human
principal does not respond before this timeout, the session
closes with closure_reason: STALL_TIMEOUT.
5.5. PLAN_B_ACTIVE Session State (NEW in -02)
PLAN_B_ACTIVE is an AEP Session state in which the session is
executing the pre-declared Plan B from the EOD (Section 6.4).
The primary path to the declared goal state has been blocked, and
the GEC has activated the Plan B outcome as the session's operative
goal.
PLAN_B_ACTIVE is entered when:
- A STALL_DIRECTION response of ACTIVATE_PLAN_B is received from
the human principal.
- The GEC automatically activates Plan B on entry to STALLED when
the EOD carries auto_activate_plan_b: true AND the stall reason
is STALL_PATH_EXHAUSTED or STALL_DENY_THRESHOLD. Automatic
activation MUST write AEP_PLAN_B_ACTIVATED (Section 11.4) to
the Event Stream and MUST notify the human principal.
While PLAN_B_ACTIVE:
(a) The GEC MUST update the session's operative goal to the Plan B
outcome declared in the EOD.
(b) The agent MUST include plan_b_ref in every IDP submitted at
ACT. plan_b_ref MUST reference the eod_id of the EOD from
which the Plan B was activated.
(c) Cedar evaluation at ACT operates against the Plan B outcome,
not the primary declared goal state.
(d) The GEC MUST write AEP_PLAN_B_ACTIVATED immediately on
activation (Section 11.4).
Exit from PLAN_B_ACTIVE:
(e) On PERMIT reaching the Plan B outcome state: session closes
with closure_reason: PLAN_B_ACHIEVED.
(f) On STALL while in PLAN_B_ACTIVE (stall reason:
STALL_PLAN_B_BLOCKED): session enters STALLED with the
human principal required to provide direction.
(g) On human principal TERMINATE via HEM: session closes with
closure_reason: HEM_TERMINATED.
5.6. Session Closure
All session closure paths MUST generate an AEP_SESSION_CLOSED
Event Stream entry (Section 11.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 is committed, the GAR [I-D.sato-soos-gar]
generates a Session Audit Record for the closed session.
6. Expected Outcome Declaration (EOD) (NEW in -02)
6.1. EOD Purpose and Role
The Expected Outcome Declaration (EOD) is a pre-session commitment
structure submitted by the agent or its operator before the first
SENSE delivery. The EOD declares what the agent expects to achieve
(primary outcome), how success will be recognized (acceptance
envelope), and what the agent will do if the primary path is blocked
(Plan B).
The EOD serves three governance functions:
(a) Pre-commitment. The EOD creates a verifiable record of the
agent's declared intention before any action is taken. This
enables the GEC to distinguish expected deviations (the agent
executing its declared Plan B) from unexpected deviations (the
agent doing something not pre-declared).
(b) Stall management. The EOD's Plan B declaration gives the GEC
and the human principal a pre-authorized fallback that can be
activated without a new HEM escalation. This reduces stall
resolution latency for predictable failure modes.
(c) Audit completeness. The GAR Session Audit Record carries the
eod_id alongside the IDP chain. An auditor can verify whether
the session's actual trajectory matched the EOD's pre-declared
expectations and Plan B.
6.2. EOD Schema
The EOD is a structured object submitted to the GEC before session
initiation or at the SESSION_START trigger.
{
"eod_id": string, ; REQUIRED. UUID v7.
"eod_version": "1.0", ; REQUIRED. Schema version.
"session_id_ref": string, ; REQUIRED. AEP Session UUID v7.
"submitted_at": string, ; REQUIRED. ISO 8601.
"primary_outcome": {
"target_state": string, ; REQUIRED. Declared goal SO
; state.
"target_phase": string, ; OPTIONAL. Expected SO lifecycle
; phase at completion.
"confidence": number, ; REQUIRED. Float 0.0-1.0.
"rationale": string ; REQUIRED. Human-readable.
},
"acceptance_envelope": {
"success_conditions": object[], ; REQUIRED. See Section 6.2.1.
"partial_success": object[], ; OPTIONAL. Partial achievement
; conditions.
"failure_conditions": object[] ; REQUIRED. Conditions under
; which the agent MUST NOT claim
; GOAL_ACHIEVED.
},
"plan_b": object | null, ; OPTIONAL. See Section 6.4.
"auto_activate_plan_b": boolean, ; OPTIONAL. Default: false.
"submitter_mjwt_id": string, ; REQUIRED. MJWT jti of the Root
; Mandate JWT for this session.
"eod_signature": string ; REQUIRED. Submitter's signature
; over canonical EOD JSON.
}
6.2.1. Success Condition Schema
Each object in success_conditions:
{
"condition_id": string, ; REQUIRED. Unique within this EOD.
"field": string, ; REQUIRED. Zone A field or SO state.
"operator": string, ; REQUIRED. eq | neq | gt | gte | lt |
; lte | in | not_in.
"value": any, ; REQUIRED. Comparison value.
"required": boolean ; REQUIRED. If true, ALL required
; conditions MUST be met for
; GOAL_ACHIEVED to be valid.
}
6.3. EOD Lifecycle
(a) The EOD is submitted to the GEC before or at session
initiation. The GEC records the EOD to the SO Instance Event
Stream as EOD_COMMITTED. EOD_COMMITTED is a distinct, later
event from an Endorsed EOD [I-D.sato-soos-aop] Section 1.4: an
Endorsed EOD is the output of IDP's intake_endorsement
(IDP Section 4.6) verifying the EOD against the agent's
actual intake before submission; EOD_COMMITTED is the GEC's
own act of recording an already-endorsed EOD to the Event
Stream. A caller MUST complete IDP endorsement before
submitting the EOD to this step, when the calling context
(e.g. AOP) requires it; this document does not itself require
endorsement for a bare AEP session with no such caller.
(b) The GEC computes eod_hash as a SHA-256 over the canonical JSON
of the EOD. The eod_hash is carried in AEP_SENSE_DELIVERED
entries (Section 11.1) for the life of the session.
(c) The EOD is immutable after EOD_COMMITTED. A revised EOD
requires a new session.
(d) The EOD is included in the GAR Session Audit Record
[I-D.sato-soos-gar] at session close.
(e) At session close, the GEC MUST evaluate the session's final
SO state against the EOD's acceptance_envelope and record
EOD_OUTCOME (MATCHED, PARTIAL, PLAN_B_MATCHED, UNMATCHED)
in AEP_SESSION_CLOSED (Section 11.2).
6.4. Plan B Integration
The EOD's plan_b field declares the fallback strategy the agent
pre-commits to if the primary outcome path is blocked.
Plan B schema:
{
"plan_b_id": string, ; REQUIRED. Unique within EOD.
"plan_b_target_state": string, ; REQUIRED. SO state for Plan B.
"plan_b_rationale": string, ; REQUIRED. Why Plan B is
; appropriate if primary fails.
"activation_conditions": object[], ; REQUIRED. Conditions under
; which Plan B may activate.
; Uses success_condition
; schema.
"plan_b_acceptance_envelope": object ; REQUIRED. Same schema
; Section 6.2.1.
}
When PLAN_B_ACTIVE is entered (Section 5.5), the GEC uses
plan_b_target_state as the operative goal for Cedar evaluation and
Transition Graph queries. The plan_b_acceptance_envelope determines
what constitutes Plan B success (closure_reason: PLAN_B_ACHIEVED).
6.5. EOD and IDP Binding
(a) When an EOD is present, every IDP submitted at ACT MUST carry
the eod_id field referencing the session's committed EOD.
(b) When the session is in PLAN_B_ACTIVE state, the IDP MUST carry
both eod_id and plan_b_ref. plan_b_ref MUST equal the plan_b_id
from the activated Plan B.
(c) The GEC MUST reject any IDP that declares a target SO state
inconsistent with the EOD's primary_outcome.target_state when
no stall or plan_b activation has occurred. An IDP that targets
a state outside both the EOD primary outcome and any active Plan
B MUST result in DENY with denial code EOD_SCOPE_VIOLATION.
(d) The GEC MUST NOT use EOD content in Cedar evaluation. The EOD
is a governance and audit artifact; authorization is determined
by Cedar policy and MJWT scope.
7. Context Package
7.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 7.2.
"session_xpid": string, ; REQUIRED. (NEW in -02) GEC-bound
; XPID for this session. See
; S.5.1.
"eod_id": string | null, ; REQUIRED. (NEW in -02)
; UUID v7
; of committed EOD, or null if
; absent (Class 1 agents).
"session_state": string, ; REQUIRED. (NEW in -02) Current
; session state (ACTIVE,
; HEM_PENDING, STALLED,
; PLAN_B_ACTIVE).
"so": object, ; REQUIRED. See Section 7.3.
"permissions": object, ; REQUIRED. See Section 7.4.
"goal": object, ; REQUIRED. See Section 7.5.
"memory": object, ; RECOMMENDED. See Section 7.6.
"proximity_events": object[], ; REQUIRED. May be empty. Sec 7.7.
"hem_context": object | null, ; REQUIRED. See Section 7.8.
"agent": object ; REQUIRED. See Section 7.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.
7.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.
DELEGATION_EVENT:
A child or peer mandate event has occurred that affects this
session's goal path. The Context Package carries a
delegation_context sub-object in addition to the standard
fields. The agent MUST process delegation_context before
entering REASON.
delegation_context sub-object:
{
"delegation_event_ref": string, ; REQUIRED. event_id of
; the ALE_DELEGATION_CHILD_
; REVOKED or ALE_SIBLING_
; REVOCATION_NOTICE entry
; in [I-D.sato-soos-gar].
"delegation_event_type": string, ; REQUIRED. CHILD_REVOKED |
; SIBLING_REVOKED |
; CHILD_RECOVERED.
"goal_impact": string ; REQUIRED. BLOCKING |
; NON_BLOCKING | UNKNOWN.
}
When goal_impact is BLOCKING, the agent MUST NOT submit the next
ACT without first either re-delegating to a replacement agent or
escalating to HEM. The agent MUST NOT silently continue toward
a goal that the GEC has assessed as unachievable with the current
delegation graph.
When goal_impact is NON_BLOCKING, the agent MAY continue normal
execution. The delegation_event_ref MUST be recorded in the next
IDP submitted at ACT as an additional reasoning_basis entry with
ref_type: DELEGATION_CONTEXT and weight: "informative".
When goal_impact is UNKNOWN, the agent SHOULD query the Transition
Graph (Section 8.1) before submitting the next ACT to re-assess
whether its path_to_goal remains viable.
CLUSTER_STATUS_CHANGE:
The SO Cluster of which this session is a member has changed
achievability state. The Context Package carries a
cluster_context sub-object. The agent MUST process
cluster_context before entering REASON.
cluster_context sub-object:
{
"cluster_event_ref": string, ; REQUIRED. event_id of the
; ALE_CLUSTER_PARTIAL_REVOCATION
; entry in [I-D.sato-soos-gar].
"cluster_achievability": string, ; REQUIRED. ACHIEVABLE |
; DEGRADED | UNACHIEVABLE.
"recommended_action": string ; REQUIRED. CONTINUE | HALT |
; REASSIGN | ESCALATE.
}
When cluster_achievability is UNACHIEVABLE and the cluster's
aggregation_rule is ALL_COMPLETE, the agent MUST NOT submit the
next ACT. The agent MUST escalate to HEM. Continuing to execute
transitions on a cluster member SO whose results cannot satisfy
the cluster's completion condition is a conformance violation.
When cluster_achievability is DEGRADED (QUORUM threshold met but
reduced), the agent MAY continue. The cluster_event_ref MUST be
recorded in GAR as a session context note.
STALL_RESOLVED: (NEW in -02)
The session's STALLED state has been resolved by a human
principal STALL_DIRECTION response. The Context Package carries
a stall_resolution sub-object. The agent MUST process the
resolution direction before entering REASON. The agent MUST
query the Transition Graph before submitting the next ACT.
stall_resolution sub-object:
{
"stall_reason": string, ; REQUIRED. The stall_reason from
; AEP_STALLED (Section 11.3).
"resolution_type": string, ; REQUIRED. REDIRECT_GOAL |
; ESCALATE_TO_HEM | CLOSE.
"new_goal_state": string | null, ; REQUIRED when resolution_
; type is REDIRECT_GOAL.
"stall_direction_id": string ; REQUIRED. UUID v7 of the
; human principal's decision.
}
7.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).
7.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.
7.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.
; In PLAN_B_ACTIVE, this reflects
; the active Plan B target. [NOTE -02]
"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.
"plan_b_active": boolean ; REQUIRED. (NEW in -02) true when
; session is in PLAN_B_ACTIVE state.
}
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.
7.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.
"deny_history": object[] ; (NEW in -02) Last N DENY
; responses in this session,
; for RETRY_CONTINUATION
; reasoning support.
}
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].
deny_history entries are GEC-generated summaries of DENY responses
in this session, including deny_code, the IDP idp_id that received
the denial, and the enrichment fields from the DENY response. The
deny_history enables agents to construct accurate RETRY_CONTINUATION
reasoning_basis entries (Section 10.4) without retaining the full
DENY response chain in their own context.
7.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.
STALL_THRESHOLD_APPROACHING: (NEW in -02)
The session's DENY count or iteration count is approaching the
STALL threshold (Section 5.4). The agent SHOULD consider
escalating to HEM voluntarily or activating Plan B before the
STALL state is entered automatically.
7.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 7.1.
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.
7.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.
"session_xpid": string ; REQUIRED. (NEW in -02) GEC-bound
; XPID for this agent in this session.
}
The aep_iteration counter MUST be strictly monotonically increasing
within a session. Gaps are permitted; reversals are not.
The session_xpid MUST match the XPID bound at session initiation
(Section 5.1). An agent MUST NOT modify or override the
session_xpid field. Implementations MUST verify that the
session_xpid in the agent sub-object matches the session_xpid in
the Context Package root.
8. GEC Query Interface (PLAN Step)
8.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.
When path_to_goal is empty AND blocked_actions covers all available
edges from the current state, the GEC MUST set path_confidence to
0.0. This is the STALL_PATH_EXHAUSTED condition (Section 5.4).
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.
8.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.
8.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.
An empty compensating_actions array, when combined with an empty
path_to_goal from the Transition Graph, contributes to the
STALL_PATH_EXHAUSTED condition (Section 5.4).
9. Transition Request (ACT Step)
9.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.
"da_production": object | null ; OPTIONAL. REQUIRED when
; cedar_action is classified under
; Cedar Action::ProduceAGA
; [I-D.sato-soos-dam] Section 5; null
; or absent otherwise. See below.
}
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 15).
da_production, when present, carries the declarations
[I-D.sato-soos-dam] Section 6's Governance Envelope requires of
any AGA this transition produces:
{
"derived_from": {
"direct_inputs": string[], ; REQUIRED. da_id values (MAY be
; empty array).
"context_inputs": string[] ; REQUIRED. da_id values (MAY be
; empty array).
},
"external_disclosure": {
"disclosed_to_class": string, ; REQUIRED. NONE |
; HUMAN_PRINCIPAL |
; EXTERNAL_THIRD_PARTY.
"disclosed_at": string | null
}
}
This is a single object, not an array: this document's execution
model is one SO Instance state transition per Transition Request
(Step 5, Section 9.2), and an action producing more than one
governed artifact atomically is out of scope for -02 -- such an
action is submitted as separate Transition Requests, one AGA
linked to another via its own derived_from.direct_inputs entry,
rather than one request producing several.
9.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 MJWT verification protocol
[I-D.sato-soos-mjwt] Section 8. Failure: DENY with appropriate
MJWT deny code.
Step 1a -- XPID Consistency Check. (NEW in -02)
Verify that the session's bound XPID (Section 5.1) matches the
XPID derivable from the Mandate JWT's agent_provider_id. An
XPID mismatch MUST result in immediate DENY with deny code
XPID_MISMATCH and MUST be recorded in GAR as a critical security
event. Session MUST be terminated after XPID_MISMATCH.
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. The Cedar context includes
idp.reasoning_mode (when declared) as a Cedar context attribute.
Cedar policies MAY gate on idp.reasoning_mode. 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 4a -- DAM Lineage and Residency Validation. (NEW in -03)
When da_production is present (Section 9.1), resolve every
da_id listed in derived_from.direct_inputs and context_inputs
against existing artifacts. An unresolvable reference MUST
result in DENY with denial code DA_LINEAGE_UNRESOLVED. For
each da_id in direct_inputs, the GEC MUST additionally verify
the referenced artifact's lifecycle_state is VALID
[I-D.sato-soos-dam] Section 3.3; a reference to an artifact
that is not yet VALID MUST result in DENY with denial code
DA_LINEAGE_NOT_VALID, since a non-VALID artifact's own
data_residency is not yet final and narrowing against it
would compute against a value that could still change. The
GEC MUST then compute the resulting AGA's data_residency per
the narrowing rule [I-D.sato-soos-dam] Section 7.5: at least
as restrictive as the most restrictive data_residency among
direct_inputs artifacts. A direct_inputs artifact with
data_residency: null (most KGA subtypes, [I-D.sato-soos-dam]
Section 4.1) imposes no additional restriction on this
computation -- null participates as the least restrictive
case, not as an undefined or blocking one. This step
performs no write of its own; it computes the AGA's would-be
Governance Envelope for Step 5 to commit, and its failure
aborts the transition entirely before any signed write for
this transition has occurred. This is the enforcement point
for the narrowing rule: not a declaration the agent's da_
production makes true by asserting it, but a computation the
GEC performs from already-governed, already-VALID data.
Step 5 -- Event Stream Write.
Append a StateTransitionEvent to the SO Instance Event Stream.
When da_production was present, this write additionally
commits the AGA's Governance Envelope [I-D.sato-soos-dam]
Section 6 as computed at Step 4a, under the same signature --
the state transition and the artifact's governance metadata
become VALID together, in one signed write, not as two
separately-committed operations where the second could fail
after the first already succeeded. 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.
9.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.
When an EOD is committed for the session, the GEC MUST verify that
the IDP's target_state is consistent with the EOD's operative
outcome (primary or Plan B) per Section 6.5. Inconsistency MUST
result in DENY with denial code EOD_SCOPE_VIOLATION.
10. GEC Response (OBSERVE Step)
10.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.
10.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.
"prior_denial_count": integer ; (NEW in -02) Total DENY count in
; this session for this action.
}
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.
The prior_denial_count field carries the total count of DENY
responses for this cedar_action in this session. This field is
exposed as a Cedar context attribute at the next ACT for the same
action, enabling Cedar policies to gate on systematic retry depth.
On DENY, the SO Instance state does NOT change.
10.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.
10.4. RETRY_CONTINUATION Handling (REVISED in -02)
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",
"what_changed": string ; REQUIRED. (NEW in -02) Human-readable
; declaration of what changed between the
; denied attempt and this retry. MUST
; reference at least one field in the
; DENY enrichment. MUST NOT be a generic
; string (e.g. "retrying") -- the GEC
; MUST reject what_changed values that
; do not reference specific enrichment
; fields.
}
What-changed requirement (NEW in -02):
The RETRY_CONTINUATION entry MUST declare, in the what_changed
field, the specific change between the denied attempt and this
retry. The what_changed declaration MUST satisfy at least one of
the following:
(a) Reference a field identified in the prior DENY response's
enrichment object. The field name MUST appear explicitly in
what_changed.
(b) Reference a Context Package state change delivered at SENSE
since the prior DENY. The context change MUST be observable
in the current Context Package.
(c) Reference a Plan B activation (PLAN_B_ACTIVE state).
The GEC MUST evaluate what_changed for specificity before
processing the Transition Request. A what_changed value that
does not reference any enrichment field and does not reference
any observable Context Package change MUST result in DENY with
denial code RETRY_WHAT_CHANGED_INVALID.
Silent retry detection (REVISED in -02):
The GEC MUST track prior_denial_count (returned in DENY responses
and available as a Cedar context attribute at subsequent ACT steps).
The GEC MUST detect the following patterns:
(i) An agent that submits a RETRY_CONTINUATION IDP without a
what_changed field: DENY with MISSING_WHAT_CHANGED.
(ii) An agent that submits identical what_changed values across
more than 3 consecutive RETRY_CONTINUATION IDPs for the same
action: LOG ALE_SILENT_RETRY_PATTERN in GAR.
(iii) prior_denial_count reaching the STALL_DENY_THRESHOLD
(Section 5.4(a)): transition to STALLED state.
Cedar prior_denial_count attribute (NEW in -02):
The prior_denial_count value from the most recent DENY response for
a given cedar_action MUST be exposed as a Cedar context attribute
at subsequent ACT steps for the same action. Cedar policies MAY
gate on prior_denial_count. Example: a Cedar policy may require
HEM escalation when prior_denial_count exceeds a threshold for a
high-risk action class.
cedar attribute: context.prior_denial_count (integer)
cedar attribute: context.last_deny_code (string)
cedar attribute: context.last_deny_enrichment_fields (string[])
11. AEP Event Log Markers
11.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.
"session_xpid": string, ; (NEW in -02) GEC-bound XPID.
"goal_session_id": string, ; Goal session UUID v7.
"eod_id": string | null, ; (NEW in -02) EOD identifier.
"session_state": string, ; (NEW in -02) Current session state.
"gec_signature": string ; GEC Ed25519 [RFC8037] 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.
11.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.
"session_xpid": string, ; (NEW in -02) GEC-bound XPID.
"eod_id": string | null, ; (NEW in -02) EOD identifier.
"eod_outcome": string | null, ; (NEW in -02) EOD evaluation.
; MATCHED | PARTIAL |
; PLAN_B_MATCHED | UNMATCHED.
"plan_b_activated": boolean, ; (NEW in -02) Whether PLAN_B_ACTIVE
; was entered during this session.
"gec_signature": string ; GEC Ed25519 signature.
}
closure_reason values:
GOAL_ACHIEVED: Agent reached declared goal state.
PLAN_B_ACHIEVED: Agent reached Plan B outcome (PLAN_B_ACTIVE).
(NEW in -02)
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.
STALL_TIMEOUT: STALLED state not resolved before timeout.
(NEW in -02)
CLUSTER_HALT: GEC halted this session because the SO Cluster
of which it was a member reached UNACHIEVABLE
achievability state.
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.3. AEP_STALLED (NEW in -02)
The GEC MUST write this entry when the session enters STALLED state
(Section 5.4).
{
"event_type": "AEP_STALLED",
"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, ; Iteration count at stall entry.
"stall_reason": string, ; STALL_DENY_THRESHOLD |
; STALL_PATH_EXHAUSTED |
; STALL_PLAN_B_BLOCKED |
; STALL_ITERATION_LIMIT.
"consecutive_denies": integer, ; Relevant for STALL_DENY_THRESHOLD.
"last_deny_code": string | null, ; deny_code of last DENY.
"eod_plan_b_available": boolean, ; Whether EOD Plan B is declared.
"gec_signature": string ; GEC Ed25519 signature.
}
11.4. AEP_PLAN_B_ACTIVATED (NEW in -02)
The GEC MUST write this entry when the session transitions to
PLAN_B_ACTIVE state (Section 5.5).
{
"event_type": "AEP_PLAN_B_ACTIVATED",
"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, ; Iteration count at activation.
"eod_id": string, ; EOD from which Plan B was activated.
"plan_b_id": string, ; plan_b_id from EOD.
"plan_b_target_state": string, ; SO state targeted by Plan B.
"activation_type": string, ; MANUAL (human direction) |
; AUTOMATIC (auto_activate_plan_b).
"stall_event_ref": string, ; event_id of AEP_STALLED that
; triggered this activation.
"gec_signature": string ; GEC Ed25519 signature.
}
12. AEP-to-OTel Mapping (NEW in -02)
12.1. Overview
OpenTelemetry (OTel) [OTel] is the de facto standard for distributed
systems observability. This section specifies the mandatory span
attributes that AEP-conforming implementations MUST emit at each
phase of the AEP loop. The OTel mapping makes the AEP execution
loop observable without altering its governance properties: the
governance record remains the Event Stream; the OTel spans are the
operational observability layer.
The AEP-to-OTel mapping uses the soos.aep.* namespace, which is a
sub-namespace of the soos.governance.* namespace defined in
[I-D.sato-soos-gar] Section 12. Implementations MUST NOT use the
soos.aep.* namespace for attributes outside this specification.
Each AEP Iteration produces exactly one parent span:
soos.aep.iteration, with five child spans, one per phase. The
parent span covers the full SENSE-REASON-PLAN-ACT-OBSERVE cycle.
12.2. Mandatory Span Attributes by Phase
SENSE phase span (soos.aep.sense):
Attribute Type Required Description
----------------------------------------------------------------
soos.aep.session_id string MUST
AEP Session UUID v7.
soos.aep.iteration integer MUST
aep_iteration value.
soos.aep.trigger string MUST
Context Package trigger.
soos.aep.cp_hash string MUST
SHA-256 of Context Package. Used to bind SENSE to ACT.
soos.aep.session_xpid string MUST
GEC-bound XPID.
soos.aep.session_state string MUST
ACTIVE | HEM_PENDING | STALLED | PLAN_B_ACTIVE.
soos.aep.so_current_state string MUST
SO state at SENSE.
REASON phase span (soos.aep.reason):
Attribute Type Required Description
----------------------------------------------------------------
soos.aep.session_id string MUST
AEP Session UUID v7.
soos.aep.iteration integer MUST
aep_iteration value.
soos.aep.reasoning_mode string SHOULD
reasoning_mode if declared. Omit for ROUTINE.
soos.aep.reason_duration_ms integer SHOULD
Milliseconds spent in REASON step. Enables compute budget
tracking.
PLAN phase span (soos.aep.plan):
Attribute Type Required Description
----------------------------------------------------------------
soos.aep.session_id string MUST
AEP Session UUID v7.
soos.aep.iteration integer MUST
aep_iteration value.
soos.aep.plan_queries string[] MUST
List of PLAN queries executed (transition_graph, live_permission,
compensating_action).
soos.aep.path_confidence number MUST
Float 0.0-1.0 from Transition Graph.
soos.aep.intended_cedar_action string MUST
Cedar action the agent intends to request.
ACT phase span (soos.aep.act):
Attribute Type Required Description
----------------------------------------------------------------
soos.aep.session_id string MUST
AEP Session UUID v7.
soos.aep.iteration integer MUST
aep_iteration value.
soos.aep.idp_id string MUST
IDP UUID v7 submitted.
soos.aep.cedar_action string MUST
Cedar action in request.
soos.aep.confidence number MUST
IDP confidence value.
soos.aep.cp_hash_ref string MUST
Must match cp_hash from SENSE span in same iteration. Binding
proof.
soos.aep.plan_b_ref string SHOULD
plan_b_ref when session is in PLAN_B_ACTIVE.
OBSERVE phase span (soos.aep.observe):
Attribute Type Required Description
----------------------------------------------------------------
soos.aep.session_id string MUST
AEP Session UUID v7.
soos.aep.iteration integer MUST
aep_iteration value.
soos.aep.observe_result string MUST
PERMIT | DENY | HEM_PENDING | STALLED.
soos.aep.deny_code string SHOULD
deny_code when result is DENY.
soos.aep.prior_denial_count integer SHOULD
prior_denial_count from DENY response.
soos.aep.event_stream_entry_id string SHOULD
Event Stream entry UUID on PERMIT.
soos.aep.cap_evaluation_result string SHOULD
PERMIT | DENY from CAP evaluation.
soos.aep.cedar_evaluation_result string SHOULD
PERMIT | DENY from Cedar.
12.3. OTel Conformance Rules
OTel-CONF-01: Implementations MUST emit all MUST-level attributes
for each phase span. Missing MUST-level attributes
MUST be flagged as a conformance violation in the
implementation's self-test suite.
OTel-CONF-02: The soos.aep.cp_hash in the SENSE span and the
soos.aep.cp_hash_ref in the ACT span of the same
iteration MUST match. A mismatch indicates that the
ACT was submitted without a valid prior SENSE
delivery. Monitoring systems SHOULD alert on this
mismatch.
OTel-CONF-03: The soos.aep.session_xpid attribute MUST be identical
across all spans in a session. An XPID change mid-
session MUST trigger an alert.
OTel-CONF-04: Implementations MUST NOT suppress or omit spans when
the result is DENY or HEM_PENDING. Governance-relevant
spans are more important to retain than successful
spans. DENY and HEM_PENDING spans carry deny_code and
prior_denial_count and are primary inputs for security
monitoring.
OTel-CONF-05: The OTel span data MUST NOT be used as a substitute
for the Event Stream or GAR audit trail. OTel is the
operational observability layer; the Event Stream is
the governance record. When OTel and Event Stream
conflict, the Event Stream is authoritative.
OTel-CONF-06: The soos.aep.* namespace MUST NOT be emitted by
non-AEP-conforming implementations. Unauthorized use
of this namespace could pollute monitoring pipelines
used for compliance reporting.
13. 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.
After STALL_RESOLVED, all classes
MUST re-query. (REVISED in -02)
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 15) 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 DENY on
for the same action. The 2nd
RETRY_CONTINUATION entry MUST carry violation
a what_changed field (Section 10.4).
(REVISED in -02)
CONF-AEP-08 Agent MUST NOT enter REASON on a REJECT
MANDATE_REVOCATION trigger. Session
MUST proceed to graceful shutdown.
CONF-AEP-09 When DELEGATION_EVENT trigger carries REJECT
goal_impact: BLOCKING, agent MUST NOT
submit the next ACT without first
re-delegating or escalating to HEM.
CONF-AEP-10 When CLUSTER_STATUS_CHANGE trigger REJECT
carries cluster_achievability:
UNACHIEVABLE and cluster aggregation_
rule is ALL_COMPLETE, agent MUST NOT
submit the next ACT. Agent MUST
escalate to HEM.
CONF-AEP-11 Class 3 agents MUST submit an EOD REJECT
before the first SENSE delivery. (session
(NEW in -02) initiation
refused)
CONF-AEP-12 GEC MUST derive XPID from KIA-verified REJECT +
Party Registry at session initiation. TERMINATE
GEC MUST NOT accept client-supplied
XPID. (NEW in -02)
CONF-AEP-13 XPID MUST match at Step 1a of GEC REJECT +
execution sequence. XPID_MISMATCH TERMINATE
MUST terminate the session.
(NEW in -02)
CONF-AEP-14 ACT submissions in PLAN_B_ACTIVE REJECT
MUST carry plan_b_ref. (NEW in -02)
CONF-AEP-15 OTel SENSE and ACT spans in the same LOG
iteration MUST carry matching cp_hash
values. (NEW in -02)
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.
14. GEE Orchestration Mode
14.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.
14.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.
"reasoning_mode": string ; (NEW in -02) reasoning_mode
; per IDP S.4.3.1. OPTIONAL.
; GEE includes in IDP when
; present and non-ROUTINE.
}
The GEE constructs the full IDP from ReasoningOutput plus session
metadata (session_id, goal_session_id, aep_iteration, so_uuid,
context_package_ref, eod_id, plan_b_ref) that the GEE manages.
14.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. On re-call
after DENY, the GEE MUST construct
RETRY_CONTINUATION reasoning_basis
including a what_changed declaration
derived from enrichment fields or the
agent's replan_reason. (REVISED in -02)
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.
CONF-GEE-07 GEE MUST submit EOD before first REJECT
Context Package delivery for Class 3
agents. (NEW in -02)
CONF-GEE-08 GEE MUST emit OTel spans per Section LOG
12. (NEW in -02)
15. 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. EOD not required.
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.
EOD SHOULD be provided; absence is recorded in SAR.
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. EOD REQUIRED
before session initiation. (REVISED in -02)
Agent Class determines IDP required fields as specified in
this section and [I-D.sato-soos-idp] Section 4.5.
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.
16. 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
7.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 9.2) for every Transition Request. The MJWT
so_id MUST match the SO Instance in the Context Package. The
permissions sub-object (Section 7.4) is derived from the MJWT.
The MJWT cedar_actions array bounds the permitted_actions set.
KIA [I-D.sato-soos-kia]:
The KIA Party Registry is the source from which the GEC derives
the session XPID (Section 5.1). KIA defines the XPID derivation
procedure [I-D.sato-soos-kia] Section 5 used at session open.
The KIA verification step (CONF-AEP-12) is a gate on session
initiation. (NEW in -02)
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 10.4)
is the IDP mechanism for acknowledged denial-and-retry. The
reasoning_mode field (IDP Section 4.3.1) is declared at REASON
and propagated into the IDP at ACT. Agent Class IDP requirements
(Section 15) are defined in this document; IDP Section 4.5
defines the IDP_STANDARD profile.
HEM [I-D.sato-soos-hem]:
HEM is invoked at Step 3 of the GEC execution sequence
(Section 9.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. STALLED
state notifications are delivered via HEM with RECOMMENDED
urgency (Section 5.4). (REVISED in -02)
GAR [I-D.sato-soos-gar]:
Every AEP_SENSE_DELIVERED, AEP_SESSION_CLOSED, AEP_STALLED, and
AEP_PLAN_B_ACTIVATED entry generates GAR audit entries. At
session close, GAR generates a Session Audit Record (SAR)
covering all governance events in the session. The SAR includes
the complete IDP chain, the EOD and EOD_OUTCOME, delegation_chain
from MJWTs, and HEM event history. The soos.aep.* OTel namespace
is a sub-namespace of soos.governance.* defined in GAR.
(REVISED in -02)
CAP [I-D.sato-soos-cap]:
CAP prohibitions are evaluated at Step 2 of the GEC execution
sequence (Section 9.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.
MAD [I-D.sato-soos-mad]:
MAD defines the delegation structure for multi-agent sessions.
When goal_impact is BLOCKING in a DELEGATION_EVENT trigger,
AEP requires the agent to re-delegate or escalate to HEM before
the next ACT. Session revocation per MAD Section 7.8 supersedes
the normal AEP loop.
AOP [I-D.sato-soos-aop]:
AOP orchestrates multi-agent missions by composing individual
AEP sessions -- AOP Section 1.4 describes AEP as providing "the
AEP session lifecycle for each individual agent session within
the mission." AOP's Sub-Goal EOD reuses this document's Section
6 EOD schema directly rather than defining a parallel one: the
EOD_OUTCOME enum (MATCHED, PARTIAL, PLAN_B_MATCHED, UNMATCHED)
that AOP's Mission Close event (ALE-055) carries per sub-goal is
this document's Section 6.3(e) enum, unchanged. See Section
6.3(a) for the relationship between this document's
EOD_COMMITTED and AOP's Endorsed EOD.
DAM [I-D.sato-soos-dam]: (NEW in -03)
Step 4a of the GEC execution sequence (Section 9.2) validates
lineage and computes the Governance Envelope for any AGA a
Transition Request produces, from the da_production field
(Section 9.1); Step 5 commits it under the same signed write
as the state transition itself. AEP does not define AGA's
schema, retention, or write-authority model; DAM does. AEP's
contribution is the submission mechanism and the enforcement
point at which DAM's data_residency narrowing rule (DAM
Section 7.5) is actually computed, not merely declared.
GNAP [RFC9635]:
The Grant Negotiation and Authorization Protocol (GNAP) specifies
how an agent or client obtains delegated authorization from an
authorization server. GNAP covers the initial grant establishment
-- the moment at which the human principal authorizes an
agent to act on a Sovereign Object instance under defined
constraints. This is the authorization event that produces
the Mandate JWT
[I-D.sato-soos-mjwt] that the AEP loop verifies at every ACT step.
GNAP and AEP operate at different points in the agent
lifecycle. GNAP is pre-session: it negotiates the grant that
creates the MJWT. AEP is per-iteration: it enforces the grant
at every transition
within the session. GNAP specifies what the agent is permitted to
attempt; AEP specifies how each attempt is governed. The two
protocols compose without overlap: a GNAP-issued MJWT is the
session credential that AEP verifies at Step 1 of the GEC
execution sequence (Section 9.2).
GNAP does not address the Context Package, the GEC Query
Interface, the HEM_PENDING session state, the STALLED state, the
EOD pre-session commitment, or the non-suppressible GAR audit
trail. These are AEP's contribution to the governed agent
lifecycle.
Windley Loop [OVID-Loop] [OVID-ME]:
The AEP PLAN step is the normative specification of the Windley
Loop planning gate: the agent queries its permitted action space
(Section 8) before committing to a Transition Request, rather
than discovering authorization failure at ACT. OVID-ME
[OVID-ME] implements the Windley Loop against Cedar-based OVID
agent mandates. AEP is interoperable with OVID-ME deployments:
the Context Package (Section 7) and the GEC Query Interface
(Section 8) provide the same state-grounded planning inputs that
OVID-ME's partial evaluation API delivers within the OVID trust
domain.
MLE and WISE (internal reference only, not a Datatracker
dependency):
Step 6 of the GEC Execution Sequence (Section 9.2, Event
Emission) is the natural per-transition source event for the
Mandate Lifecycle Events (MLE) profile's mandate-executed
event; the Agent Session Revocation procedure (Section 17) is
the natural source for mandate-revoked and
mandate-violation-detected. Neither is a normative dependency
of this document: this document's own hooks (asynchronous,
non-blocking notification at Step 6; graceful shutdown on a
MANDATE_REVOCATION trigger) already exist and are unchanged by
MLE's existence. The mechanical binding -- exact field
mappings, which AEP data becomes which MLE event attribute --
is maintained separately in the internal, GitHub-only
reference document soos-wise-mle-binding-00.md, consistent
with the discipline that WISE/MLE-facing output stays
WISE/MLE-native and no SOOS-internal vocabulary (Cedar action
IDs, ALE types, GAR span hashes) appears on the wire.
17. 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 GEC execution sequence (Section 9.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
with a what_changed declaration on denial-and-retry (Section 10.4).
The GEC MUST track prior_denial_count to detect agents that submit
repeated identical Transition Requests without acknowledging prior
denials. Systematic silent retry is an indicator of authorization
bypass attempts. The STALL_DENY_THRESHOLD (Section 5.4) bounds the
depth of retry sequences before mandatory human review.
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.
Session fixation attack. (NEW in -02)
An adversary who can inject a client-supplied XPID at session
initiation could cause the GEC to associate the session with an
identity that does not match the agent's actual Party Registry
entry. This would allow cross-principal scope leakage: the agent
would operate under governance parameters derived from a different
agent's Party Registry record. Mitigation: CONF-AEP-12 prohibits
client-supplied XPID. The GEC MUST derive the XPID from the
KIA-verified Party Registry entry for the agent_provider_id in the
Root Mandate JWT. Implementations MUST audit INVALID_XPID_CLAIM
rejections as potential session fixation attempts.
XPID binding integrity. (NEW in -02)
The session XPID is derived at initiation and carried in every
AEP_SENSE_DELIVERED entry. An adversary who can modify the XPID
mid-session could subvert the GEC's cross-principal correlation
that identifies which agent took which action. Mitigation: Step 1a
of the GEC execution sequence (Section 9.2) verifies XPID
consistency at every ACT. An XPID_MISMATCH MUST terminate the
session immediately. Monitoring systems using the soos.aep.
session_xpid OTel attribute SHOULD alert on any mid-session XPID
change (OTel-CONF-03).
Cross-principal scope leakage. (NEW in -02)
When multiple agents from different providers are operating on the
same SO Instance, an adversary who can cause Agent A to present
Agent B's XPID gains Agent B's Cedar residual and session context
delivered at SENSE. This permits Agent A to reason and act under
Agent B's permission scope. Mitigation: XPID binding (CONF-AEP-12,
CONF-AEP-13) prevents this by ensuring the XPID is always GEC-
derived from the verified agent_provider_id. Cedar policies SHOULD
be scoped to the XPID to ensure that Agent A cannot claim Agent B's
permitted_actions regardless of XPID.
STALLED state exploitation. (NEW in -02)
An adversary who can induce artificial DENY responses against an
agent may attempt to drive the agent into STALLED state, causing a
denial of service against the session. Mitigation: the stall
notification delivered via HEM includes the stall_reason and the
prior DENY chain, enabling the human principal to distinguish a
genuine stall (path exhausted) from an induced stall (DENY pattern
inconsistent with SO Type state machine). The GEC SHOULD log
stall-inducing DENY patterns to the GAR as anomalous when the DENY
codes are inconsistent with the agent's permitted_actions.
Agent Session Revocation.
AEP operates within the SOOS session lifecycle model. When an
agent session is revoked -- whether by operator action, a CAEP
signal received via [I-D.sato-soos-mad], or a CAP constitutional
violation -- the session revocation procedure defined in
[I-D.sato-soos-mad] Section 7.8 supersedes the normal AEP loop.
Implementations MUST NOT continue the SENSE-REASON-PLAN-ACT-OBSERVE
cycle after receiving a MANDATE_REVOCATION trigger in a Context
Package (Section 7.2). The agent MUST proceed directly to graceful
session shutdown per Section 5.6.
All pending AEP operations at the point of revocation MUST be
classified using the completion_state model defined in
[I-D.sato-soos-mad] Section 7.8. This completion_state is a
per-session action-irreversibility classification and is a
distinct model from the identically-named completion_state defined
in [SOOS-KEE] Section 4.8 (P8, Revocation Propagation),
which tracks cross-kernel-instance CAEP signal acknowledgment, not
action irreversibility. Both use the same three labels (CLEAN,
PARTIAL, UNKNOWN) for unrelated state machines; a GAR record's
completion_state MUST be interpreted using the ALE type and
originating document that produced it, not the label alone:
CLEAN: no irreversible actions taken since last natural
breakpoint defined in the AEP session. GEC MAY complete
the current atomic ACT operation then halt.
PARTIAL: irreversible actions taken, execution incomplete.
GEC MUST halt immediately, record completion_state in GAR,
and surface to HEM escalation chain for human review.
UNKNOWN: GEC cannot determine completion state. GEC MUST
treat as PARTIAL.
The GEC MUST record an ALE_SESSION_REVOKED entry [I-D.sato-soos-gar]
immediately upon session revocation and, if completion_state is
PARTIAL or UNKNOWN, MUST additionally record ALE_PARTIAL_STATE_
RECORDED before closing the session. These entries are causally
linked to the last AEP_SENSE_DELIVERED entry in the session's Event
Stream.
AEP_SESSION_CLOSED MUST be written with closure_reason:
MANDATE_REVOKED on all revocation paths (Section 11.2).
18. 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 7.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 EOD (Section 6) submitted at session initiation may carry
human principal intent in the primary_outcome.rationale and plan_b.
plan_b_rationale fields. The GEC MUST treat EOD content as
sensitive and MUST control access to EOD records with the same
access controls applied to IDP records. EOD records MUST be
included in the same data retention and deletion policies as the
SO Instance Event Stream. (NEW in -02)
The session_xpid field carried in AEP_SENSE_DELIVERED and
AEP_SESSION_CLOSED entries enables cross-session correlation of
agent behavior. When the agent_provider_id in the Mandate JWT is
associated with an identifiable natural person (e.g. an individual
developer's agent), the session_xpid constitutes personal data
under GDPR Article 4(1) [GDPR] and APPI Article 2 [APPI].
Implementations MUST apply appropriate access controls to all
records carrying session_xpid values. (NEW in -02)
The episodic memory sub-object (Section 7.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.
19. IANA Considerations
19.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.
DELEGATION_EVENT Child or peer mandate event affects this
session's goal path. Carries
delegation_context sub-object.
CLUSTER_STATUS_CHANGE SO Cluster achievability state has changed.
Carries cluster_context sub-object.
STALL_RESOLVED STALLED state resolved by human
principal. (NEW in -02)
19.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.
PLAN_B_ACHIEVED Agent reached Plan B outcome in PLAN_B_ACTIVE
state. (NEW in -02)
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.
STALL_TIMEOUT STALLED state not resolved before timeout.
(NEW in -02)
CLUSTER_HALT Session ended because the SO Cluster of which
this session was a member reached UNACHIEVABLE
achievability state and GEC applied HALT_REMAINING
disposition.
19.3. AEP Session State Registry (NEW in -02)
Registry name: Agent Execution Protocol Session State Registry
Registration procedure: Specification Required.
This registry is new in AEP-02. AEP-01 did not define a formal
registry for session states.
Initial registrations:
State Value Description
ACTIVE Session is executing the AEP loop normally.
HEM_PENDING Session suspended pending human principal
decision under HEM. Agent MUST NOT submit ACT.
STALLED Session cannot make progress without human
direction. Agent MUST NOT submit ACT.
PLAN_B_ACTIVE Session executing pre-declared EOD Plan B.
Agent MUST include plan_b_ref in IDP.
CLOSED Session terminated. No further transitions
are possible.
19.4. 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 7.7.
Additions in -02:
Condition Type Description
STALL_THRESHOLD_APPROACHING Session DENY count or iteration count
approaching the STALL threshold.
19.5. 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.
19.6. AEP EOD Media Type Registration (NEW in -02)
Media type: application/soos-aep-eod+json
Type name: application
Subtype name: soos-aep-eod+json
Required parameters: none
Optional parameters: version (default: "1.0")
Encoding considerations: UTF-8 JSON
Security considerations: The EOD carries pre-session commitment
data. Implementations MUST verify the eod_signature against
the submitter's Mandate JWT before recording the EOD.
Interoperability considerations: The schema is defined in
Section 6.2 of this document.
Published specification: this document.
Applications that use this media type: GEC implementations that
accept pre-session EOD submissions from agents or operators.
Fragment identifier considerations: none
Additional information: none
Contact: tomsato@myauberge.jp
Intended usage: COMMON
Author: Tom Sato
20. References
20.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-05,
work in progress, July 2026.
[I-D.sato-soos-hem]
Sato, T., "The Human Escalation Mechanism (HEM) for
Agentic AI Systems", draft-sato-soos-hem-06, July 2026.
[I-D.sato-soos-gar]
Sato, T., "The Governance Audit Record (GAR) for
Agentic AI Systems", draft-sato-soos-gar-07,
September 2026.
[I-D.sato-soos-cap]
Sato, T., "The Constitutional AI Protocol (CAP) for
Agentic AI Systems", draft-sato-soos-cap-05, July 2026.
[I-D.sato-soos-sov]
Sato, T., "The Sovereign Object (SOV) for Agentic AI
Systems", draft-sato-soos-sov-03, June 2026.
[I-D.sato-soos-mjwt]
Sato, T., "The Mandate JWT (MJWT) for Agentic AI
Systems", draft-sato-soos-mjwt-05, July 2026.
[I-D.sato-soos-kia]
Sato, T., "The Kernel Identity and Attestation (KIA)
for Agentic AI Systems", draft-sato-soos-kia-06,
work in progress, July 2026.
[I-D.sato-soos-mad]
Sato, T., "Multi-Agent Delegation (MAD) for Agentic
AI Systems", draft-sato-soos-mad-04, June 2026.
[I-D.sato-soos-dam]
Sato, T., "The Data Artifact Management (DAM)
Protocol for Agentic AI Systems", draft-sato-soos-
dam-01, work in progress, August 2026.
[I-D.sato-soos-aop]
Sato, T., "The Agent Orchestration Protocol (AOP) for
Agentic AI Systems", draft-sato-soos-aop-02,
work in progress, August 2026.
[SOOS-KEE] Sato, T., "The Kernel Execution Environment (KEE-1)
for the Sovereign Object OS", July 2026,
<https://soosproject.ai/drafts/kee>.
[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.
20.2. Informative References
[I-D.sato-soos-pt]
Sato, T., "Progressive Trust (PT) for Agentic AI
Systems", draft-sato-soos-pt-03, May 2026.
[SOOS-FAIP] Sato, T., "The Federated Agent Intelligence Protocol
(FAIP) for Agentic AI Systems", September 2026,
<https://soosproject.ai/drafts/faip>.
[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.
[MCP] Anthropic, "Model Context Protocol",
https://modelcontextprotocol.io/, 2024.
[OVID-ME] Hepburn, C., "OVID-ME: Mandate Evaluation for Delegated
Agent Authority", Version 0.x, Apache License 2.0,
https://github.com/clawdreyhepburn/ovid-me, 2026.
[OVID-Loop]
Hepburn, C., "The Windley Loop and the Fletcher Embassy:
When Agents Read Their Own Map -- And What Happens When
They Cross the Border", clawdrey.com, April 2026,
https://clawdrey.com/blog/the-windley-loop-and-the-
fletcher-embassy.html
[RFC9635] Richer, J. and F. Imbault, "Grant Negotiation and
Authorization Protocol (GNAP)", RFC 9635, November 2024.
[Windley-Loop]
Windley, P., "It's Not Just What Agents Can Do...
It's When They Can Do It!", windley.com, March 2026,
https://www.windley.com/archives/2026/03/
its_not_just_what_agents_can_doits_when_they_can_do_it.shtml
[OTel] OpenTelemetry Authors, "OpenTelemetry Specification",
https://opentelemetry.io/docs/specs/otel/, 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. This walk-through is updated in AEP-02
to reflect XPID binding at session open and EOD submission.
A.1. Pre-Session: EOD Submission (Class 2 agent, EOD RECOMMENDED)
The OTA booking agent submits an EOD before requesting session
initiation:
EOD:
- eod_id: "eod-azusa-001"
- primary_outcome.target_state: "ACTIVITY_COMPLETE"
- primary_outcome.confidence: 0.85
- acceptance_envelope.success_conditions: [
{ field: "so.current_state", operator: "eq",
value: "ACTIVITY_COMPLETE", required: true }
]
- plan_b.plan_b_target_state: "CANCELLED"
- plan_b.plan_b_rationale: "If pre-activity collection fails after
3 attempts, cancel booking to free supplier allocation."
- plan_b.auto_activate_plan_b: false
A.2. Session Initiation: XPID Binding
The GEC initiates the session:
- Verifies Root Mandate JWT: so_id matches, not revoked, within exp.
- Derives XPID from KIA Party Registry for agent_provider_id:
"ota-booking-agent-001" -> XPID: "xpid-kia-ota-abc123"
- Records XPID as session_xpid for this session.
- Records EOD as EOD_COMMITTED in Event Stream.
- Assigns session_id: "sess-azusa-2026-001"
A.3. 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 Context Package also carries:
- session_xpid: "xpid-kia-ota-abc123"
- eod_id: "eod-azusa-001"
- session_state: "ACTIVE"
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.4. 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). reasoning_mode: omitted (ROUTINE).
No uncertainty flags.
A.5. 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.6. 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,
eod_id: "eod-azusa-001",
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 1a: XPID consistency check. session_xpid "xpid-kia-ota-abc123"
matches KIA-derived XPID for agent_provider_id. Pass.
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.7. 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, the eod_id, 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.
OTel spans emitted:
- soos.aep.sense: trigger=SESSION_START, cp_hash=<hash>,
session_xpid="xpid-kia-ota-abc123", session_state=ACTIVE.
- soos.aep.reason: reasoning_mode omitted (ROUTINE).
- soos.aep.plan: plan_queries=["transition_graph","live_permission"],
path_confidence=0.92,
intended_cedar_action="atp:booking:pre_activity_open"
- soos.aep.act: idp_id=<uuid>,
cedar_action="atp:booking:pre_activity_open",
confidence=0.91, cp_hash_ref=<hash>.
- soos.aep.observe: observe_result=PERMIT,
event_stream_entry_id="event-id-0042".
Author's Address
Tom Sato
MyAuberge K.K.
Chino, Nagano, Japan
Email: tomsato@myauberge.jp
URI: https://soosproject.ai/drafts/aep