The Sovereign Object (SOV) for Agentic AI Systems
draft-sato-soos-sov-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-sov-04
Internet Engineering Task Force T. Sato
Internet-Draft MyAuberge K.K.
Intended status: Standards Track 7 September 2026
Expires: 7 March 2027
The Sovereign Object (SOV) for Agentic AI Systems
draft-sato-soos-sov-04
Abstract
When an AI agent acts on your behalf, it acts on something: a
document, a booking, a contract, a financial instruction. No
existing IETF specification defines what that something is, what
states it can be in, who governs it, or how it is irreversibly
erased when the relationship ends.
Agentic AI governance protocols -- including intent declaration,
human escalation, audit recording, and constitutional prohibition --
all require a normative definition of the governed resource that
agents operate on: the structured, stateful, policy-carrying entity
to which agent authority is bound and upon which governed transitions
execute. No existing IETF specification defines this primitive.
This document defines the Sovereign Object (SO): a causally ordered,
policy-governed, typed, living document that evolves through a
predefined finite state space under Governing Enforcement Component
(GEC) authority. The SO is the unit of governance in the SOOS
protocol family: the thing agents operate on, the GEC governs, and
human principals reason about.
This document specifies the SO's five-layer structure (Identity,
State, Event Stream, Typed Graph, Attachment Index), its Zone A /
Zone B boundary model, its five-phase lifecycle, its SO Type system,
its Cedar policy context model, and the binding model by which a
Mandate JWT binds an agent to a specific SO instance.
Version -02 extends SOV-01 with: (a) SO Type registry governance
including a SOV-02 subtype model for structured SO Type composition;
(b) the Standing Plan Object (SPO) as a normative SOV-02 subtype,
specifying declarative scope constraints, Cedar bundle reference,
CAP-RRS catalog reference, and IDP structural validation integration;
(c) event stream integrity normative requirements including
GEC-signed append-only guarantees, kernel_id binding, and
OpenTelemetry integration for observability bridging; (d) expanded
Security Considerations addressing SO state manipulation, event
stream tampering, SO Type spoofing, and stale state_constraint
exploitation; and (e) IANA registrations for the SO Type code
namespace and SPO media type.
Version -03 removes the Mission Plan SO and Mission Status SO
subtypes, which -02 defined normatively alongside a SOV-01 SO
Type Registry Governance and SOV-02 Subtype Model that already
generalizes to them. These subtypes are now owned exclusively
by the Agentic Orchestration Protocol (AOP), which defines a
materially more complete Sub-Goal DAG model
(typed dependency edges, deadline tracking, critical-path
annotation) than -02's; duplicating them here created a
cross-draft inconsistency this revision resolves by deferring
entirely to AOP. Version -03 also reorders the Cedar policy
evaluation sequence to place Mandate JWT verification before
SO Type Cedar policy evaluation, matching the Mandate JWT
draft's own explicit verification-sequencing requirement, and
updates cross-draft version references
throughout to the current suite versions.
The Sovereign Object is the architectural foundation referenced
normatively by the other SOOS governance drafts.
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 Missing Governed Resource Primitive
3.2. Why Existing Primitives Are Insufficient
3.3. Relationship to Thomas Howe's Agent Architecture Layering
4. The Sovereign Object
4.1. Definition
4.2. Five-Layer Structure
4.2.1. Layer 1 -- Identity Layer
4.2.2. Layer 2 -- State Layer
4.2.3. Layer 3 -- Event Stream
4.2.4. Layer 4 -- Typed Graph
4.2.5. Layer 5 -- Attachment Index
4.3. Zone A / Zone B Boundary
4.3.1. Zone A -- Protocol Core
4.3.2. Zone B -- Attached Periphery
4.3.3. Zone Boundary Invariants
5. SO Type System
5.1. SO Type Declaration
5.2. SO Type Registry
5.3. SO Type Discovery
5.4. SO Type Registry Governance
5.5. SOV-02 Subtype Model
6. Standing Plan Object (SPO)
6.1. SPO Role and Motivation
6.2. SPO SO Type Declaration
6.3. Declarative Scope Constraints
6.4. Cedar Bundle Reference
6.5. CAP-RRS Catalog Reference
6.6. IDP Structural Validation Integration
6.7. SPO Lifecycle
6.8. SPO Use Case -- Disaster Response Activation
7. SO Lifecycle
7.1. Five Lifecycle Phases
7.2. Phase Transition Rules
7.3. Cryptographic Erasure
8. Event Stream Integrity
8.1. GEC-Signed Append-Only Requirement
8.2. kernel_id Binding
8.3. OpenTelemetry Integration
9. Cedar Policy Context
9.1. SO State as Cedar Attribute
9.2. Zone Access Policy Model
9.3. Policy Evaluation Order (UPDATED in -03)
10. Mandate JWT Binding
10.1. Binding Model
10.2. Narrowing Property at the SO Level
10.3. Binding Verification
11. GEC Association
11.1. GEC-SO Association Model
11.2. Multi-GEC Coordination
12. Relationship to Other SOOS Drafts
12.1. Relationship to DAWN and Adjacent Work
13. Security Considerations
13.1. SO State Manipulation
13.2. Event Stream Tampering
13.3. SO Type Spoofing
13.4. Stale state_constraint Exploitation
13.5. Agent Session Revocation
13.6. Infrastructure Security
14. Privacy Considerations
15. IANA Considerations
15.1. SO Type Registry
15.2. SO Type Code Namespace
15.3. SO Lifecycle Phase Registry
15.4. SO Event Type Registry
15.5. SPO Media Type
16. References
16.1. Normative References
16.2. Informative References
Appendix A. ATP Booking Object -- Reference Implementation
A.1. SO Type Registration
A.2. State Machine
A.3. Zone A / Zone B Application
A.4. SO Lifecycle Mapping
Appendix B. Disaster Response SPO -- Reference Implementation
B.1. SPO Registration
B.2. Scope Constraints
B.3. Cedar Bundle Reference
B.4. Activation Scenario
Appendix C. Vibe Coding Assets
C.1. Protocol Summary
C.2. Key Identifiers
C.3. Canonical Reference
Appendix D. Changes from Previous Versions (NEW in -03)
Acknowledgements
Author's Address
1. Introduction
The IETF community has made significant progress in specifying how AI
agents authenticate [I-D.ietf-wimse-arch], how they express intent
before acting [I-D.sato-soos-idp], how human oversight is enforced
[I-D.sato-soos-hem], and how agent actions are recorded for audit
[I-D.sato-soos-gar]. Each of these specifications refers, explicitly
or implicitly, to a governed resource: the entity that the agent is
acting upon, that the authorization policy applies to, and that the
human principal is reasoning about.
None of them defines that resource.
If you are building an agentic AI system today, the absence of a
normative governed resource definition means that your authorization
system authorizes actions in the abstract -- not actions on a
specific, stateful, auditable object under a specific human
principal's authority. SOV closes this gap by defining the
Sovereign Object: the typed, stateful, policy-carrying primitive
that makes authorization binding specific, delegation revocable, and
erasure obligations satisfiable. Without it, "authorized to perform
action X" has no normative referent -- any resource will do, and no
audit trail is structurally required.
The Intent Declaration Primitive [I-D.sato-soos-idp] requires an
agent to declare what governed object its action targets. The Human
Escalation Mechanism [I-D.sato-soos-hem] triggers escalation events
bound to the state of a specific governed object instance. The
Governance Audit Record [I-D.sato-soos-gar] records transitions on
governed objects. The Mandate JWT specification
[I-D.sato-soos-mjwt] binds agent authority to a specific governed
object instance. In every case, the governed resource is assumed
but not specified.
This document fills that gap. The Sovereign Object (SO) is the
unit of governance in the SOOS protocol family: a causally ordered,
policy-governed, typed, living document that evolves through a
predefined finite state space under GEC authority. It is the
thing agents operate on, the GEC governs, and human principals
reason about.
The SO is not a database record. A database record is a passive
data container. The SO carries its own state machine, its own Cedar
policy context, its own tamper-evident event history, and its own
lifecycle -- including eventual cryptographic erasure. It is the
architectural resource that gives SOOS its coherence: the
abstraction layer below which protocol-specific implementation
details vary and above which governance, authorization, audit, and
human oversight operate uniformly.
The SO is also the primitive that gives Mandate JWT binding its
specificity. An agent is not authorized to perform actions of type
X in the abstract. It is authorized to perform actions of type X on
SO instance Y, in lifecycle phase P, under human principal H. That
binding is what makes the authorization auditable, revocable, and
scoped.
Version -01 of this document defined the core Sovereign Object
primitive: five-layer structure, Zone A / Zone B boundary, five
lifecycle phases, SO Type system, Cedar policy context model, and
Mandate JWT binding.
Version -02 extends the SO Type system with structured type registry
governance and the SOV-02 subtype model, introduces the Standing Plan
Object (SPO) as the first normative SOV-02 subtype for declarative
operational planning, strengthens event stream integrity
requirements, expands Security Considerations, and registers the
SO Type code namespace and SPO media type with IANA. (-02 also
introduced the Mission Plan SO and Mission Status SO as normative
subtypes for multi-agent task orchestration; -03 removes them --
see below.)
Version -03 removes the Mission Plan SO and Mission Status SO
subtypes introduced in -02. These are now owned exclusively by
the Agentic Orchestration Protocol [I-D.sato-soos-aop], which
defines a materially more complete Sub-Goal DAG model than -02's
version did; -02's duplicate definition created a cross-draft
inconsistency (divergent DAG dependency-type vocabularies) that
this revision resolves by deferring entirely to AOP. Version -03
also corrects Section 9.3's Cedar policy evaluation order to place
Mandate JWT verification before SO Type Cedar policy evaluation,
matching [I-D.sato-soos-mjwt] Section 8.1's explicit requirement,
and updates stale cross-draft version references throughout.
Version -04 is an editorial revision with no normative content
changes: eight sibling-draft citations had gone stale against
those drafts' current live versions and are updated to
draft-sato-soos-idp-06, draft-sato-soos-hem-07,
draft-sato-soos-gar-08, draft-sato-soos-cap-06,
draft-sato-soos-mjwt-06, draft-sato-soos-kia-07,
draft-sato-soos-mad-05, and draft-sato-soos-aop-03 respectively;
and the FAIP citation is migrated from the versioned
[I-D.sato-soos-faip] form to the non-versioned [SOOS-FAIP] form,
since FAIP is a Class B specification that will not be submitted
to the IETF Datatracker.
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:
Sovereign Object (SO):
A causally ordered, policy-governed, typed, living document that
evolves through a predefined finite state space under GEC
authority. The unit of governance in the SOOS protocol family.
SO Instance:
A specific instantiation of an SO Type with a globally unique
identifier, its own event stream, and its own current lifecycle
state. An SO Instance is the entity to which a Mandate JWT
binds agent authority.
SO Type:
A declaration that specifies the state machine, Zone A schema,
Cedar policy set, and permissible attachment types for a class of
Sovereign Objects. SO Types are registered in the SO Type
Registry.
SOV-02 Subtype:
An SO Type that conforms to the SOV-02 Subtype Model
(Section 5.5): it extends a registered parent SO Type, inherits
its state machine
and Cedar policy set, and adds subtype-specific Zone A fields and
attachment types declared in a subtype extension declaration.
SO Type Registry:
A registry of SO Type declarations, analogous to the IANA MIME
type registry, that enables interoperating implementations to
discover and validate SO Type definitions.
Standing Plan Object (SPO):
A normative SOV-02 subtype that carries a declarative operational
plan as a first-class Sovereign Object. An SPO instance specifies
scope constraints, a Cedar bundle reference, a CAP-RRS catalog
reference, and IDP structural validation parameters. The SPO
governs how agents activate and execute against a standing plan.
Zone A:
The Protocol Core zone of an SO. GEC-governed. Schema
determined by the SO Type state machine. Required nodes enforced
as invariants. Personal data MUST NOT be stored in Zone A.
Zone B:
The Attached Periphery zone of an SO. Agent-accessible, GEC-
referenced, but not directly GEC-governed. Arbitrarily complex
external content referenced by integrity-verified attachment
records in the Attachment Index.
SO Lifecycle Phase:
One of five phases that every SO Instance traverses: ACTIVE,
OPERATIONALLY_COMPLETE, ADMINISTRATIVELY_CLOSED, ARCHIVED, and
CRYPTOGRAPHICALLY_ERASED.
Event Stream:
The append-only, causally ordered, tamper-evident log of all
transitions executed against an SO Instance. The Event Stream
is the ground truth of the SO's history.
Typed Graph:
The current materialization of an SO Instance's Event Stream as
a labeled property graph. Derived from the Event Stream; in
case of conflict, the Event Stream is authoritative.
Attachment Index:
The set of integrity-verified references to Zone B content
associated with an SO Instance.
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 Log, and mediates agent access to governed objects.
Mandate JWT:
As defined in [I-D.sato-soos-mjwt]: a JSON Web Token that binds
an agent's authorization to a specific SO Instance.
Cedar:
A policy language and evaluation engine [Cedar] used by the GEC
to evaluate authorization decisions against SO Instance state and
agent intent.
Human Principal:
A natural person who holds authority over an SO Instance, as
identified in the Mandate JWT human_principal_id field.
Narrowing Property:
The invariant by which a child Mandate JWT is always a strict
subset of its parent in all authorization dimensions.
kernel_id:
The GEC's globally unique, cryptographically stable identifier
bound to the GEC signing key. Recorded in Event Stream entries
as soos.governance.kernel_id. Enables cross-entry verification
that all entries in an Event Stream were produced by the same GEC
instance.
3. Problem Statement
3.1. The Missing Governed Resource Primitive
SOOS governance protocols -- IDP, HEM, GAR, CAP, and MJWT -- are
built around the concept of a governed resource: a typed, stateful
entity that agents operate on under GEC authority. The governance
properties of the SOOS stack -- auditability, revocability, human
oversight, constitutional prohibition, and federated trust -- all
derive their coherence from the properties of this governed resource.
As of the submission of this document, no IETF specification defines
this resource normatively. The existing SOOS drafts use the term
"governed object" descriptively but without a formal definition.
This creates three concrete problems:
(a) Binding ambiguity. The Mandate JWT binds agent authority to a
governed object instance. Without a formal definition of what
a governed object is -- what properties it has, what state it
can be in, what lifecycle phases it traverses -- the binding has
no normative referent. Implementations cannot interoperate on
the meaning of the binding.
(b) Policy imprecision. Cedar policies evaluated by the GEC can
reference SO Instance state attributes. Without a normative
definition of what state attributes are available and how they
are derived from the SO's event history, policy authors cannot
write portable policies and evaluators cannot evaluate them
consistently.
(c) Lifecycle opacity. Regulatory obligations on governed data --
including data minimization, erasure on request, and audit
retention -- apply to the governed resource and its event
history. Without a normative definition of the SO's lifecycle,
including its Cryptographic Erasure phase, implementations
cannot demonstrate compliance with these obligations.
3.2. Why Existing Primitives Are Insufficient
Three existing primitive types might appear to serve the role of the
Sovereign Object. Each is insufficient for distinct reasons.
URI-addressed API endpoints. Generic REST endpoints are passive:
they accept requests and return responses. They have no state
machine, no causal event history, no Cedar policy context, and no
lifecycle. An agent authorized to invoke an endpoint is not
authorized to perform a specific state transition on a specific
stateful resource under human principal oversight. The
authorization semantics are categorically different.
Database records. A database record is a passive data container.
It may carry a status field that approximates state, but that field
is not enforced by a GEC, is not derived from a tamper-evident
event history, and does not carry Cedar policy context. The
record's "state" can be overwritten without triggering HEM
escalation, without generating a GAR audit entry, and without
verifying that the agent holds a valid Mandate JWT authorizing the
transition.
vCon [I-D.ietf-vcon-vcon-container]. The vCon container records
the history of a completed conversation or interaction. vCon is
retrospective: it captures what happened after the fact in a
portable, shareable format.
The Sovereign Object is prospective: it carries the Cedar policy
context, lifecycle state, and mandate tree that governs agent
behavior before and during execution.
The SO does not replace vCon; the two primitives compose. A vCon
carrying IDP, GAR, and HEM records can be produced from an SO's
Event Stream after a session completes. The SO is the structured
source of those records during execution; vCon is the portable
container for them after the fact. For applications that need both
governed execution and portable post-session record packaging,
implementations SHOULD use SO during execution and produce a vCon
at OPERATIONALLY_COMPLETE phase transition.
Thomas Howe's work on vCon and on agentic architecture layering
informs the SOV design. The vCon / SO composition pattern is the
implementation answer to his observation that agent action records
must be both machine-auditable during execution and human-portable
after completion.
3.3. Relationship to Thomas Howe's Agent Architecture Layering
Howe (personal communication, May 2026) proposes an eight-layer
architecture for agentic AI systems covering transport, identity,
credential issuance, authorization, orchestration, tool invocation,
audit, and oversight. This layering correctly identifies the major
functional concerns of agentic governance but does not identify the
governed resource as a distinct architectural primitive. In Howe's
model, the Mandate JWT binds to an unspecified resource -- an
implicit target of authorization that his layers do not define.
The Sovereign Object is that missing primitive. It sits below the
authorization and delegation layer as the structured, stateful,
policy-carrying resource that the Mandate JWT refers to and that
Cedar policy governs access to. Without the SO, authorization
binding is generic: an agent is authorized to perform actions of
type X. With the SO, the binding is specific: an agent is
authorized to perform actions of type X on SO Instance Y, in
lifecycle phase P, under human principal H, while the SO's state
machine is in state S. That specificity is what makes the
authorization auditable and revocable.
4. The Sovereign Object
4.1. Definition
A Sovereign Object (SO) is a causally ordered, policy-governed,
typed, living document that evolves through a predefined finite state
space under Governing Enforcement Component authority.
"Causally ordered" means that every state transition recorded in the
Event Stream is causally linked to its predecessor: no transition
can be inserted between two existing entries, and no transition
can reference a future state.
"Policy-governed" means that every state transition MUST be
evaluated by a Cedar policy set defined in the SO's Type declaration
before execution. The GEC MUST reject transitions that do not
satisfy the applicable Cedar policy.
"Typed" means that every SO Instance MUST conform to a declared SO
Type that specifies its state machine, Zone A schema, and Cedar
policy set.
"Living" means that the SO's current state is always derived from
its Event Stream. The Typed Graph is a materialization of the Event
Stream at a given point in time, not an independent data store. The
Event Stream is authoritative.
"Finite state space" means that the set of states the SO can occupy
is declared in the SO Type and is finite. The GEC MUST reject any
transition that would move the SO to a state not declared in its
SO Type.
4.2. Five-Layer Structure
Every Sovereign Object Instance has five layers. Layers 1 through 3
are mandatory. Layers 4 and 5 are RECOMMENDED for production
implementations.
4.2.1. Layer 1 -- Identity Layer
The Identity Layer provides the globally unique, immutable identifier
for an SO Instance.
so_id:
REQUIRED. A UUID v7 [RFC9562] identifier. UUID v7 is selected
for its time-ordered property, which enables efficient range
queries over SO Instances by creation time. The so_id MUST NOT
change for the lifetime of the SO Instance, including after
Cryptographic Erasure.
so_type_id:
REQUIRED. The identifier of the SO Type this instance conforms
to. MUST reference a registered entry in the SO Type Registry.
created_at:
REQUIRED. ISO 8601 timestamp of SO Instance creation.
human_principal_id:
REQUIRED. The identifier of the human principal who holds
authority over this SO Instance.
gec_id:
REQUIRED. The identifier of the GEC currently associated with
this SO Instance. See Section 11.1.
The Identity Layer MUST be committed to the Event Stream as the
first entry when an SO Instance is created. The entry MUST be
GEC-signed.
4.2.2. Layer 2 -- State Layer
The State Layer records the SO Instance's current position in its
SO Type's state machine.
current_state:
REQUIRED. The current state of the SO Instance. MUST be a
state declared in the SO Type's state machine.
current_phase:
REQUIRED. The current SO Lifecycle Phase. One of: ACTIVE,
OPERATIONALLY_COMPLETE, ADMINISTRATIVELY_CLOSED, ARCHIVED,
CRYPTOGRAPHICALLY_ERASED. See Section 7.
state_entered_at:
REQUIRED. ISO 8601 timestamp of the most recent state transition.
The State Layer is derived from the Event Stream. The GEC MUST
maintain a current-state cache for performance, but MUST treat the
Event Stream as authoritative in any conflict.
4.2.3. Layer 3 -- Event Stream
The Event Stream is the append-only, causally ordered, tamper-
evident log of all transitions executed against an SO Instance.
The Event Stream is the ground truth of the SO's history.
Section 8 specifies Event Stream integrity requirements.
Every Event Stream entry MUST include:
event_id:
A UUID v7 identifier for this entry, assigned by the GEC at
commitment.
event_type:
One of the event types defined in Section 15.4.
prior_event_id:
The event_id of the preceding entry. MUST be null for the
SO_CREATED entry. MUST NOT be null for all subsequent entries.
This field enforces causal ordering.
occurred_at:
ISO 8601 timestamp.
gec_signature:
The GEC signature over this entry, covering event_id, event_type,
prior_event_id, occurred_at, and all event-type-specific fields.
The signing key and label MUST conform to the GEC's conformance
level as defined in [I-D.sato-soos-idp] Section 9.
soos.governance.kernel_id:
The kernel_id of the GEC that produced this entry. MUST be
present in every Event Stream entry. Enables cross-entry
verification per Section 8.2.
agent_id:
The identifier of the agent that triggered this event, if
applicable. NULL for GEC-initiated events.
mandate_id:
The Mandate JWT identifier authorizing this event, if applicable.
NULL for GEC-initiated events.
Event Stream entries MUST be written to a SCITT transparency log
[I-D.ietf-scitt-architecture] at Level 3 conformance. At Level 1
and Level 2 conformance, SCITT submission is RECOMMENDED.
4.2.4. Layer 4 -- Typed Graph
The Typed Graph is the current materialization of the Event Stream
as a labeled property graph. It provides efficient query access to
the SO Instance's current state without requiring full Event Stream
replay.
The Typed Graph schema is defined by the SO Type. The GEC MUST
update the Typed Graph atomically with each Event Stream commitment.
In any conflict between the Typed Graph and the Event Stream, the
Event Stream is authoritative.
The Typed Graph MUST expose the following minimum node set:
- The SO Instance identity (Layer 1 fields).
- The current state and phase (Layer 2 fields).
- The set of currently bound Mandate JWTs.
- The current Attachment Index (Layer 5).
4.2.5. Layer 5 -- Attachment Index
The Attachment Index is the set of integrity-verified references to
Zone B content associated with an SO Instance.
Every Attachment Index entry MUST include:
attachment_id:
A UUID v7 identifier.
attachment_type:
A type declared in the SO Type's attachment type list.
content_uri:
The URI of the Zone B content.
content_hash:
A SHA-256 [RFC6234] hash of the Zone B content at attachment time.
The GEC MUST verify content integrity on access.
attached_at:
ISO 8601 timestamp.
gec_signature:
GEC signature over this Attachment Index entry.
Attachment and detachment operations MUST generate ZONE_B_ATTACHED
and ZONE_B_DETACHED Event Stream entries.
4.3. Zone A / Zone B Boundary
4.3.1. Zone A -- Protocol Core
Zone A is the Protocol Core of an SO Instance. It is the set of
data fields governed directly by the GEC and constrained by the SO
Type's schema.
Properties of Zone A:
- Schema determined by the SO Type state machine.
- Required nodes enforced as invariants by the GEC.
- All writes mediated by the GEC.
- All transitions subject to Cedar policy evaluation.
- All transitions recorded to the Event Stream.
Zone A Invariant (INV-ZA-1):
Personal data as defined under GDPR Article 4(1) [GDPR], APPI
Article 2 [APPI], and equivalent jurisdictional definitions
MUST NOT be stored in Zone A. Zone A contains only identifiers,
state references, and policy-relevant metadata. Personal data
is always Zone B content, referenced from Zone A via the
Attachment Index.
This invariant enables Zone A and the Event Stream to be retained
for audit purposes after a Cryptographic Erasure event (Section 7.3)
while Zone B content is irreversibly erased.
4.3.2. Zone B -- Attached Periphery
Zone B is the Attached Periphery of an SO Instance. It contains
external content referenced by the Attachment Index.
Properties of Zone B:
- Arbitrarily complex external content.
- Not directly governed by the GEC.
- Accessible to agents holding appropriate Zone B read capability
in their Mandate JWT.
- Content integrity verified by the GEC on access via content_hash.
Zone B content includes, but is not limited to: documents, images,
consent records, health declarations, identity verification results,
and any other personal data associated with the SO Instance.
4.3.3. Zone Boundary Invariants
INV-ZA-1: Personal data MUST NOT be stored in Zone A.
INV-ZA-2: Zone A fields MUST be defined in the SO Type schema.
The GEC MUST reject writes to undefined Zone A fields.
INV-ZB-1: Zone B content MUST be referenced from Zone A via a
signed Attachment Index entry.
INV-ZB-2: The GEC MUST verify Zone B content integrity on every
access. Content failing integrity verification MUST NOT
be returned to the requesting agent.
5. SO Type System
5.1. SO Type Declaration
An SO Type declaration is a JSON object with the following fields:
{
"so_type_id": "<string: unique SO Type identifier>",
"so_type_name": "<string: human-readable name>",
"so_type_version": "<string: semantic version>",
"parent_so_type_id": "<string: parent SO Type id, or null>",
"state_machine": {
"states": ["<state_name>", ...],
"initial_state": "<state_name>",
"transitions": [
{
"from": "<state_name>",
"to": "<state_name>",
"cedar_action": "<action_name>",
"requires_hem": <boolean>
}
]
},
"zone_a_schema": {
"<field_name>": {
"type": "<json_schema_type>",
"required": <boolean>,
"personal_data": false
}
},
"cedar_policy_set_uri": "<URI of Cedar policy set>",
"attachment_types": ["<attachment_type_name>", ...],
"registrant": "<organization name>",
"registered_at": "<ISO 8601 timestamp>"
}
The zone_a_schema MUST NOT define fields with personal_data: true.
The GEC MUST reject SO Type registration requests that include
personal data fields in the Zone A schema.
The cedar_policy_set_uri MUST resolve to a Cedar policy set that
defines permit and forbid rules for all cedar_action values
referenced in the state machine transitions.
The parent_so_type_id field MUST be null for root SO Types. For
SOV-02 subtypes (Section 5.5), it MUST reference the registered
parent SO Type identifier.
5.2. SO Type Registry
The SO Type Registry is the authoritative catalog of registered SO
Types. It is analogous to the IANA MIME type registry in function.
IANA Considerations are specified in Section 15.1.
SO Type identifiers use a hierarchical naming convention:
<registrant-prefix>/<type-name>/<version>
Example: "atp/booking-object/1.0"
SO Type identifiers MUST be globally unique within the registry.
5.3. SO Type Discovery
A GEC MAY expose an SO Type Discovery endpoint returning the set of
SO Types it supports, as a JSON array of SO Type declarations.
The discovery endpoint URI is implementation-defined.
5.4. SO Type Registry Governance
The SO Type Registry operates under the following governance model.
Registration Authority:
IANA is the registration authority for the SO Type Registry.
Registration of an SO Type requires a Designated Expert review
per [RFC8126] Section 4.5.
Registration Requirements:
An SO Type registration submission MUST include: (a) a unique
so_type_id in the form <registrant-prefix>/<type-name>/<version>;
(b) a complete SO Type declaration as specified in Section 5.1;
(c) a cedar_policy_set_uri resolving to a published Cedar policy
set; (d) the name and contact information of the registrant
organization; (e) for SOV-02 subtypes, the parent_so_type_id of
the registered parent type.
Expert Review Criteria:
The Designated Expert MUST verify: (a) the so_type_id is globally
unique; (b) the zone_a_schema contains no personal_data fields;
(c) the Cedar policy set at cedar_policy_set_uri is accessible
and syntactically valid; (d) for SOV-02 subtypes, the subtype
extension does not contradict the parent type's Cedar
prohibitions.
Registry Updates:
A registered SO Type MAY be updated by the original registrant
by incrementing the version component of the so_type_id. The
prior version remains in the registry and MUST NOT be deleted.
Deprecation is indicated by adding a deprecated_at field to the
registry entry.
Conflict Resolution:
If two registration submissions claim the same so_type_id, the
Designated Expert MUST reject the later submission and notify the
submitter. The registrant-prefix namespace is maintained by IANA
to prevent prefix conflicts.
5.5. SOV-02 Subtype Model
The SOV-02 Subtype Model enables structured composition of SO Types.
A SOV-02 subtype is an SO Type that:
(a) Declares a parent_so_type_id referencing a registered SO Type.
(b) Inherits the parent SO Type's state machine. A SOV-02 subtype
MUST NOT remove states or transitions defined in its parent.
A SOV-02 subtype MAY add states and transitions, subject to the
constraint that new transitions MUST NOT violate the parent
type's Cedar policy prohibitions.
(c) Inherits the parent SO Type's Cedar policy set and MUST
declare its own cedar_policy_set_uri pointing to a Cedar policy
set that extends the parent. The subtype Cedar policy set MUST
be evaluated after the parent policy set. A DENY from the
parent policy set MUST NOT be overridden by the subtype policy
set.
(d) MAY declare additional Zone A fields in zone_a_schema beyond
those declared by the parent. Inherited Zone A fields MUST NOT
be redefined or narrowed.
(e) MAY declare additional attachment types beyond those declared
by the parent.
The inheritance chain MAY have at most three levels: root type,
SOV-02 subtype, and SOV-02 sub-subtype. Deeper inheritance chains
are NOT RECOMMENDED and MUST NOT exceed five levels.
The SOV-02 subtype model is the mechanism by which the Standing
Plan Object (Section 6) is defined as a normative subtype, and
the mechanism [I-D.sato-soos-aop] builds upon to define the
Mission Plan SO and Mission Status SO (see Section 12).
6. Standing Plan Object (SPO)
6.1. SPO Role and Motivation
An operational plan is a first-class governance artifact in agentic
AI deployments. Plans declare what agents are permitted to do, in
what sequence, under what constraints, and subject to what
constitutional restrictions. Without a Sovereign Object to carry
the plan, agents execute against informal instructions that are not
GEC-governed, not Cedar-evaluable, and not auditable.
The Standing Plan Object (SPO) closes this gap. An SPO instance is
a Sovereign Object that carries a declarative operational plan. It
specifies the scope within which agents may act when the plan is
activated, references the Cedar policy bundle governing plan
execution, references the CAP-RRS catalog governing plan
constitutional compliance, and specifies the IDP structural
validation constraints that all Intent Declarations submitted under
the plan must satisfy.
The reference use case is disaster response activation: when a
government agency activates a disaster response plan, the activation
creates an SPO instance that carries the operational authority for
all agents acting under the plan. Every agent action in the
disaster response is governed by the SPO. Every HEM escalation is
bound to the SPO instance. Every GAR record references the SPO
so_id.
6.2. SPO SO Type Declaration
The Standing Plan Object is a SOV-02 subtype of the root SO Type
"soos/sovereign-object/1.0". Its so_type_id is:
soos/standing-plan-object/1.0
SPO state machine:
States: DRAFT, APPROVED, ACTIVE, SUSPENDED, COMPLETED, REVOKED
Transitions:
DRAFT -> APPROVED: cedar_action: spo.approve
requires_hem: true
APPROVED -> ACTIVE: cedar_action: spo.activate
requires_hem: false
ACTIVE -> SUSPENDED: cedar_action: spo.suspend
requires_hem: true
SUSPENDED -> ACTIVE: cedar_action: spo.resume
requires_hem: true
ACTIVE -> COMPLETED: cedar_action: spo.complete
requires_hem: false
ACTIVE -> REVOKED: cedar_action: spo.revoke
requires_hem: true
APPROVED -> REVOKED: cedar_action: spo.revoke
requires_hem: true
The APPROVED -> ACTIVE transition (spo.activate) does not require
HEM because activation by an authorized agent is within the scope
of the approval already granted. All other transitions that
change the plan's operative status require HEM.
SPO Zone A schema (in addition to inherited fields):
plan_name: REQUIRED. String. Human-readable plan name.
plan_version: REQUIRED. String. Semantic version of the plan.
activating_authority: REQUIRED. String. Identifier of the authority
whose approval moves the plan to APPROVED.
scope_constraints: REQUIRED. Object. See Section 6.3.
cedar_bundle_ref: REQUIRED. URI. See Section 6.4.
cap_rrs_catalog_ref: REQUIRED. URI. See Section 6.5.
idp_validation_ref: REQUIRED. URI. See Section 6.6.
activation_at: CONDITIONAL. ISO 8601 timestamp. Set when the
SPO transitions to ACTIVE.
completion_at: CONDITIONAL. ISO 8601 timestamp. Set when the
SPO transitions to COMPLETED or REVOKED.
6.3. Declarative Scope Constraints
The scope_constraints object in the SPO Zone A schema defines the
boundary within which agents operating under this plan are permitted
to act. The GEC MUST enforce scope constraints at the Transition
Request level: a Transition Request that would act outside the scope
defined by scope_constraints MUST be denied before Cedar evaluation.
scope_constraints structure:
{
"geographic_scope": [
{ "jurisdiction": "<ISO 3166-1 alpha-2 code>",
"sub_jurisdiction": "<region/prefecture code or null>" }
],
"so_type_scope": [
"<so_type_id>", ...
],
"agent_role_scope": [
"<role_identifier>", ...
],
"temporal_scope": {
"not_before": "<ISO 8601 timestamp or null>",
"not_after": "<ISO 8601 timestamp or null>"
},
"max_delegation_depth": <integer>
}
geographic_scope:
The set of jurisdictions within which agents may take governed
actions under this plan. MUST be non-empty for plans with
jurisdiction-specific restrictions. An empty array indicates
no geographic restriction.
so_type_scope:
The set of SO Types against which agents may execute Transition
Requests under this plan. Agents MUST NOT execute Transition
Requests against SO Types not listed. An empty array indicates
no SO Type restriction.
agent_role_scope:
The set of agent roles permitted to operate under this plan.
An agent whose Mandate JWT does not carry a listed role MUST NOT
receive an activation mandate scoped to this SPO.
temporal_scope:
The time window within which the plan is operative. The GEC
MUST reject Transition Requests submitted outside the temporal
scope even if the SPO is in ACTIVE state.
max_delegation_depth:
The maximum number of mandate delegation levels permitted for
agents operating under this plan. MUST NOT exceed the
max_delegation_depth declared in the applicable MAD cluster
[I-D.sato-soos-mad].
6.4. Cedar Bundle Reference
The cedar_bundle_ref field references the Cedar policy bundle
governing all agent transitions executed under this SPO. The
referenced Cedar bundle MUST be a versioned, content-addressed
artifact: the URI MUST resolve to a Cedar policy set whose SHA-256
hash matches the hash recorded in the SPO Event Stream entry at
activation time.
The GEC MUST load the Cedar bundle at cedar_bundle_ref at SPO
activation and MUST use that bundle for all Cedar evaluations for
Transition Requests governed by this SPO until the SPO is completed,
revoked, or superseded.
Cedar bundle update:
If the Cedar bundle must be updated during an active SPO (for
example, to incorporate a regulatory change), the update MUST be
authorized by a human principal with plan authority and MUST
generate a CEDAR_BUNDLE_UPDATED Event Stream entry recording the
prior bundle URI and hash and the new bundle URI and hash.
6.5. CAP-RRS Catalog Reference
The cap_rrs_catalog_ref field references the CAP-RRS policy catalog
[I-D.sato-soos-cap] applicable to this plan. The GEC MUST apply
the CAP-RRS catalog at cap_rrs_catalog_ref as the constitutional
constraint layer for all Transition Requests governed by this SPO.
The CAP-RRS catalog reference enables plan-specific constitutional
constraints. A disaster response plan may activate a CAP-RRS
catalog that permits actions that are prohibited in normal operation
(for example, access to medical records under disaster exception
provisions), provided those permissions are within the Tier 0
prohibitions defined in [I-D.sato-soos-cap]. CAP Tier 0 prohibitions
MUST NOT be relaxed by any SPO CAP-RRS catalog.
6.6. IDP Structural Validation Integration
The idp_validation_ref field references an IDP structural validation
schema [I-D.sato-soos-idp] that all Intent Declarations submitted
under this SPO MUST satisfy.
The IDP structural validation schema specifies:
(a) Required IDP fields that MUST be present in all IDPs submitted
under this plan.
(b) Permitted action types. IDPs whose action_type is not listed
MUST be rejected by the GEC before Cedar evaluation.
(c) Context reference requirements. IDPs MUST include context_refs
pointing to specified classes of antecedent events (for example,
the activating SPO Event Stream entry).
The GEC MUST apply IDP structural validation before Cedar policy
evaluation for all Transition Requests submitted under a governed
SPO.
6.7. SPO Lifecycle
An SPO instance follows the SOV five-phase lifecycle (Section 7)
with the additional constraint that the SPO MUST transition to
OPERATIONALLY_COMPLETE when its state machine reaches COMPLETED
or REVOKED.
The GEC MUST record an SPO_ACTIVATED Event Stream entry when the
SPO transitions to ACTIVE, including the activating agent_id,
the mandate_id of the activating mandate, and the activation_at
timestamp.
The GEC MUST record an SPO_DEACTIVATED Event Stream entry when the
SPO transitions out of ACTIVE state, including the deactivating
agent_id, the mandate_id (or human_principal_id for human-initiated
deactivation), and the reason code.
6.8. SPO Use Case -- Disaster Response Activation
The following narrative illustrates the SPO in the disaster response
context (see Appendix B for a worked implementation).
When an M7.2 earthquake strikes, a prefectural government activates
its standing disaster response plan. The activation creates an SPO
instance with so_type_id "soos/standing-plan-object/1.0". The SPO
Zone A records: the plan name ("北海道 地震対応計画 rev.3"), the
activating authority (北海道知事), the scope constraints (geographic:
Hokkaido prefecture; SO types: DisasterEventSO, ShelterSO,
ResourceRequestSO; temporal: not_after 30 days from activation),
the Cedar bundle governing disaster response agent authorities, and
the CAP-RRS catalog that activates the disaster exception profile.
Every agent action in the disaster response -- from DMAT deployment
authorization to shelter occupancy management to victim relief
payment initiation -- is governed by the SPO. Every HEM escalation
references the SPO so_id. Every GAR record references the SPO
so_id as the governing plan identifier. When the disaster response
concludes, the SPO transitions to COMPLETED and then to
OPERATIONALLY_COMPLETE, sealing the complete governance record.
7. SO Lifecycle
7.1. Five Lifecycle Phases
Every SO Instance progresses through a sequence of lifecycle phases.
Phase transitions are irreversible.
Phase 1 -- ACTIVE:
Normal operation. All Cedar-governed state transitions permitted,
subject to the SO Type's state machine and Cedar policy set.
Phase 2 -- OPERATIONALLY_COMPLETE:
Terminal operational state reached. Agent-initiated state
transitions are prohibited. Administrative transitions for
billing, audit, and dispute resolution remain permitted subject
to Cedar policy and human principal authority.
Phase 3 -- ADMINISTRATIVELY_CLOSED:
All state transitions prohibited except DISPUTE_OPENED, if
defined by the SO Type. Only human principals with explicit
dispute authority may initiate transitions.
Phase 4 -- ARCHIVED:
All write operations prohibited. The SO Instance is read-only.
The Event Stream is retained. Zone B content retention is
governed by the data_residency policy and applicable law.
Phase 5 -- CRYPTOGRAPHICALLY_ERASED:
Zone B content has been irreversibly erased per Section 7.3.
Zone A data and the Event Stream are retained for audit. No
further phase transitions are possible.
7.2. Phase Transition Rules
Phase transitions MUST be initiated by the GEC, not by agents
directly. Phase transitions MUST generate a PHASE_TRANSITIONED
Event Stream entry recording the prior phase, the new phase, the
authorizing human principal (if applicable), and the GEC signature.
Phase transition rules:
ACTIVE -> OPERATIONALLY_COMPLETE:
When the SO Type's state machine reaches a declared terminal
state. The GEC MAY initiate this transition automatically.
OPERATIONALLY_COMPLETE -> ADMINISTRATIVELY_CLOSED:
After the administrative tail period declared in the SO Type has
elapsed. MUST be authorized by a human principal with lifecycle
authority.
ADMINISTRATIVELY_CLOSED -> ARCHIVED:
After all dispute resolution windows and applicable regulatory
retention requirements have elapsed. MUST be authorized by a
human principal with lifecycle authority.
ARCHIVED -> CRYPTOGRAPHICALLY_ERASED:
At any time after ARCHIVED phase, subject to regulatory retention
requirements. MUST be authorized by a human principal with
erasure authority, or initiated automatically by the GEC when
data_residency.retention_days has elapsed.
7.3. Cryptographic Erasure
Cryptographic Erasure irreversibly erases Zone B content by
destroying the encryption keys protecting it.
Cryptographic Erasure MUST:
(a) Destroy all encryption keys protecting Zone B content for this
SO Instance.
(b) Generate an ERASURE_INITIATED Event Stream entry before beginning
key destruction.
(c) Generate an ERASURE_COMPLETED Event Stream entry after key
destruction is confirmed.
(d) Retain Zone A data and the complete Event Stream intact.
(e) Update current_phase to CRYPTOGRAPHICALLY_ERASED.
Cryptographic Erasure satisfies the right to erasure under GDPR
Article 17 [GDPR] for Zone B content while preserving the Event
Stream as an audit record.
8. Event Stream Integrity
8.1. GEC-Signed Append-Only Requirement
The Event Stream is the ground truth of an SO Instance's history.
Its integrity properties MUST be enforced as follows.
(a) The GEC MUST sign every Event Stream entry using the GEC's
Governance Identity Key (GIK) as defined in [I-D.sato-soos-kia].
The signature MUST cover: event_id, event_type, prior_event_id,
occurred_at, soos.governance.kernel_id, and all event-type-
specific fields.
(b) The Event Stream MUST be append-only. No entry MUST be modified,
deleted, or reordered after commitment. An implementation MUST
treat any request to modify a committed Event Stream entry as a
security incident requiring HEM escalation (Section 13.2).
(c) Every Event Stream entry MUST include prior_event_id referencing
the immediately preceding entry. A verifier MUST be able to
construct the complete causal chain from the SO_CREATED entry
to the most recent entry by following prior_event_id links and
verifying each GEC signature.
(d) The GEC MUST reject any attempt to commit an Event Stream entry
whose prior_event_id does not match the current head of the
Event Stream. This prevents concurrent write races and ensures
linearizability of the causal chain.
8.2. kernel_id Binding
The soos.governance.kernel_id attribute is the GEC's globally
unique, cryptographically stable identifier bound to the GEC's
Governance Identity Key. It is defined in [I-D.sato-soos-kia].
Every Event Stream entry MUST carry the soos.governance.kernel_id
of the GEC that signed it. A verifier MUST:
(a) Confirm that all entries in an Event Stream carry the same
kernel_id, or carry a different kernel_id only in a
GEC_TRANSITIONED entry that documents a legitimate GEC
migration.
(b) Verify the GEC signature on each entry against the public key
published by the GEC identified by kernel_id at entry commitment
time, retrievable via the KIA attestation record
[I-D.sato-soos-kia].
An Event Stream containing kernel_id values that do not correspond
to documented GEC_TRANSITIONED entries MUST be treated as a tampered
record and reported as a critical security incident.
8.3. OpenTelemetry Integration
Event Stream entries SHOULD be surfaced as OpenTelemetry [OTel]
trace spans to enable integration with standard observability
infrastructure. The following mapping applies:
OTel Span Attributes:
soos.so.so_id: The SO Instance identifier (so_id).
soos.so.so_type_id: The SO Type identifier.
soos.governance.kernel_id: The GEC kernel_id.
soos.event.event_id: The Event Stream entry identifier.
soos.event.event_type: The Event Stream entry type.
soos.event.prior_event_id: The prior_event_id for causal linking.
OTel Span Naming:
Spans SHOULD be named "soos.so.<event_type>" using the Event
Stream event_type value in snake_case.
OTel Causality:
The OTel parent span SHOULD reference the span corresponding to
the prior_event_id entry, enabling visualization tools to render
the causal Event Stream as a trace tree.
Implementations MAY export Event Stream entries to an OTel collector
in addition to SCITT transparency log submission. OTel export does
NOT substitute for SCITT submission. The GEC MUST complete SCITT
submission before considering an Event Stream entry committed.
9. Cedar Policy Context
9.1. SO State as Cedar Attribute
The GEC MUST make the following SO Instance attributes available as
Cedar context attributes during policy evaluation:
so.so_id: The SO Instance identifier. Type: String.
so.so_type_id: The SO Type identifier. Type: String.
so.current_state: Current state machine position. Type: String.
so.current_phase: Current lifecycle phase. Type: String.
so.human_principal_id: Human principal identifier. Type: String.
so.prior_denial_count: Count of GEC DENY responses targeting this
SO Instance in the current session.
Type: Long. Composes with the
prior_denial_count attribute in
[I-D.sato-soos-idp] Section 5.4.
so.mandate_count: Number of active Mandate JWTs bound to this SO
Instance. Type: Long.
For SPO instances, the following additional Cedar attributes MUST
be available:
spo.plan_name: String.
spo.activation_at: String (ISO 8601) or null.
spo.temporal_scope.not_after: String (ISO 8601) or null.
9.2. Zone Access Policy Model
Zone B read access and Zone B write access are separate Cedar action
types and MUST be declared separately in the SO Type's Cedar policy
set. A Cedar policy permitting a state transition MUST NOT
implicitly permit Zone B access.
9.3. Policy Evaluation Order (UPDATED in -03)
The GEC MUST evaluate Cedar policies in the following order.
(UPDATED in -03) -02 placed Mandate JWT scope verification last,
after SO Type Cedar policy evaluation. This directly contradicted
[I-D.sato-soos-mjwt] Section 8.1, which requires all thirteen MJWT
verification steps to complete before Cedar policy evaluation runs
at all -- so that Cedar never evaluates using SO Instance state
attributes (Section 9.1) or IDP intent attributes populated on the
assumption of a validated principal/mandate relationship the
pipeline had not actually confirmed yet. Mandate JWT verification
now runs first, ahead of CAP Tier 0, since CAP's own Section 6.2
CEE protocol does not itself depend on MJWT validity, while
Cedar's SO Type policy evaluation (per Section 9.1's attribute
list, and per [I-D.sato-soos-cap] Section 5.4's requirement to
populate Cedar context from the session MJWT's consent_scope
claim) explicitly does.
(1) Mandate JWT verification, full protocol [I-D.sato-soos-mjwt]
Section 8.1 (all thirteen steps). A verification failure
results in immediate DENY before any Cedar evaluation begins.
(2) CAP Tier 0 (constitutional) prohibitions [I-D.sato-soos-cap].
A Tier 0 prohibition results in immediate DENY.
(3) CAP Tier 1 (jurisdictional) prohibitions [I-D.sato-soos-cap].
(4) SPO scope constraint enforcement (Section 6.3), if the
Transition Request is governed by an active SPO. A scope
violation results in immediate DENY before Cedar evaluation.
(5) SO Type Cedar policy (and SOV-02 subtype Cedar policy, if
applicable), with SO Instance state attributes per Section 9.1
and IDP intent attributes per [I-D.sato-soos-idp] Section 5.4.
For SOV-02 subtypes, parent Cedar policy is evaluated before
subtype Cedar policy. A DENY from parent policy MUST NOT be
overridden by subtype policy.
A PERMIT requires all five layers to permit the action. A DENY at
any layer results in immediate DENY without proceeding further.
10. Mandate JWT Binding
10.1. Binding Model
A Mandate JWT [I-D.sato-soos-mjwt] binds agent authority to a
specific SO Instance with the following properties:
Instance specificity:
A Mandate JWT MUST reference the so_id of a specific SO Instance.
A Mandate JWT MUST NOT authorize actions against an SO Type in
general.
State awareness:
The Mandate JWT MAY declare the set of SO states in which the
authorized Cedar actions may be performed. The GEC MUST reject
Transition Requests referencing Cedar actions outside the state-
restricted set for the SO Instance's current state.
Phase restriction:
The Mandate JWT MAY declare lifecycle phase restrictions. The
GEC MUST reject Transition Requests targeting an SO Instance in
a phase not permitted by the Mandate JWT.
Temporal validity:
The Mandate JWT MUST carry a standard JWT exp claim. The GEC
MUST reject expired Mandate JWTs.
Human principal linkage:
The Mandate JWT MUST carry the human_principal_id of the SO
Instance's human principal. The GEC MUST verify that this
value matches the human_principal_id in the SO Instance's
Identity Layer.
10.2. Narrowing Property at the SO Level
The Narrowing Property is a normative invariant: a child Mandate JWT
MUST be a strict subset of its parent in all authorization
dimensions. At the SO level:
(a) SO Instance scope: A child mandate MUST reference the same
so_id or a subset of SO Instances covered by its parent.
(b) Cedar action scope: A child mandate's authorized action set
MUST be a subset of its parent's.
(c) State restrictions: A child mandate's permitted SO states MUST
be a subset of its parent's.
(d) Phase restrictions: A child mandate's permitted lifecycle phases
MUST be a subset of its parent's.
(e) Temporal validity: A child mandate's exp claim MUST NOT be
later than its parent's.
The GEC MUST verify the Narrowing Property when a child Mandate JWT
is presented. A violation MUST result in a NARROWING_VIOLATION deny
code.
10.3. Binding Verification
On receiving a Transition Request, the GEC MUST verify before Cedar
evaluation:
(a) The Mandate JWT signature MUST be valid.
(b) The Mandate JWT MUST NOT be expired.
(c) The so_id in the Mandate JWT MUST match the targeted SO Instance.
(d) The human_principal_id MUST match the SO Instance Identity Layer.
(e) The Mandate JWT MUST NOT appear in the revocation registry.
(f) If a child mandate, the Narrowing Property MUST be verified.
Binding verification failure MUST result in a DENY response recorded
in the SO Instance's Event Stream.
11. GEC Association
11.1. GEC-SO Association Model
Every SO Instance MUST be associated with exactly one GEC at any
given time, recorded as gec_id in the Identity Layer. The GEC is
responsible for: evaluating all Transition Requests, maintaining the
Event Stream, enforcing Cedar policy, executing HEM escalation,
generating GAR audit records, enforcing CAP prohibitions, and
managing Mandate JWT revocation.
A GEC transition MUST generate a GEC_TRANSITIONED Event Stream entry
signed by both the outgoing and incoming GEC. During a GEC
transition, the SO Instance MUST be placed in a non-transitionable
state until the new GEC confirms association.
11.2. Multi-GEC Coordination
A single SO Instance MUST NOT be governed by more than one GEC
simultaneously. A trust domain MAY designate shadow GECs for
resilience; shadow GECs MUST receive Event Stream entries in real
time but MUST NOT accept Transition Requests except following formal
failover. Multi-GEC coordination protocols are outside the scope of
this document.
12. Relationship to Other SOOS Drafts
IDP [I-D.sato-soos-idp]:
The "governed object" in IDP is an SO Instance as defined in
this document. The IDP context_refs field may reference SO Event
Stream entries by event_id. The so.prior_denial_count Cedar
attribute (Section 9.1) composes with the prior_denial_count
attribute defined in [I-D.sato-soos-idp] Section 5.4. The SPO's
idp_validation_ref (Section 6.6) provides plan-specific IDP
structural validation constraints.
HEM [I-D.sato-soos-hem]:
HEM events are bound to SO Instances. HEM_TRIGGERED and
HEM_RESOLVED events MUST be recorded in the SO Instance's Event
Stream. The HEM_PENDING state prohibits all agent-initiated
Transition Requests against the SO Instance until a human
principal provides a decision.
GAR [I-D.sato-soos-gar]:
Governance Audit Records are generated from SO Instance Event
Stream entries. The SO's Cryptographic Erasure event MUST be
recorded in the GAR Event Log as an ERASURE_COMPLETED entry
and generates a SAR entry at session close per
[I-D.sato-soos-gar] Section 6.
CAP [I-D.sato-soos-cap]:
CAP prohibitions are enforced at the SO level before Cedar
evaluation per Section 9.3. The SPO's cap_rrs_catalog_ref
(Section 6.5) enables plan-specific CAP-RRS policy activation.
MJWT [I-D.sato-soos-mjwt]:
The Mandate JWT binds agent authority to a specific SO Instance
per Section 10. The Mandate JWT's so_id field is the normative
reference to the SO Instance Identity Layer.
KIA [I-D.sato-soos-kia]:
The GEC's Governance Identity Key (GIK) used to sign Event Stream
entries is attested via KIA. The soos.governance.kernel_id field
in Event Stream entries references the KIA-attested GEC identity.
Event Stream integrity verification per Section 8 depends on KIA
attestation.
MAD [I-D.sato-soos-mad]:
MAD cluster governance operates over shared SO instances.
so_authority_principal is declared at cluster formation.
The SPO's max_delegation_depth (Section 6.3) MUST NOT exceed the
max_delegation_depth declared in the applicable MAD cluster.
AOP [I-D.sato-soos-aop]: (NEW in -03)
The Mission Plan SO and Mission Status SO are SO subtypes
defined normatively by AOP, using the SOV-02 subtype model
(Section 5.5) this document defines. -02 duplicated these
subtype definitions; -03 removes the duplicate and defers to
AOP as the sole owner, including AOP's Sub-Goal DAG dependency-
type vocabulary (SEQUENTIAL, PARALLEL, CONDITIONAL). AOP's
Mission Plan SO DAG enforcement coordinates with MAD for
multi-agent sub-goal assignment; HEM escalation triggered by
Mission Plan SO failures (HEM_CLASS_GOVERNANCE_INCONSISTENCY)
is specified in AOP, not here.
FAIP [SOOS-FAIP]:
The Federated Agent Intelligence Protocol specifies cross-domain
federated analytics derived from SO Instance Event Streams. The
data_residency field declared in [I-D.sato-soos-idp] Section 4.2
controls per-IDP-record FAIP tier eligibility; this field is
carried in Event Stream entries generated from IDP records.
Zone B content is excluded from FAIP analytics by the Zone A
Invariant (INV-ZA-1).
12.1. Relationship to DAWN and Adjacent Work
The Decentralized Agent Workload Networking (DAWN) BoF at IETF 126
addresses requirements for how AI agents discover, negotiate, and
operate across distributed workload environments. SOV is directly
relevant to DAWN's requirements in one specific dimension: the
governed resource that agent authority is bound to.
DAWN addresses agent-to-agent communication and workload routing.
SOV addresses what agents operate on when they arrive at a workload:
the structured, stateful, policy-carrying resource that authorization
policy governs. These are complementary, not competing.
SOV's DAWN written comment will address three points:
(a) The SO as the normative binding target for agent authorization
in multi-workload topologies. Any DAWN agent capability
discovery mechanism that produces authorization grants SHOULD
reference a specific SO Instance, not an abstract capability
type. SOV provides the structural definition for that referent.
(b) The Zone A / Zone B boundary as a portable interoperability
surface. Zone A fields are SO-Type-defined and interoperable
across GEC implementations. Zone B content is implementation-
specific. DAWN workload routing can use Zone A state to make
routing decisions without touching personal data.
(c) The SO Type Registry as an IANA-analogous coordination point
for governed resource type definitions across DAWN workloads.
The SPO (Section 6) is directly relevant to DAWN's orchestration
requirements: it defines the governance container for a
cross-workload operational plan. The Mission Plan SO's
DAG-structured task graph that DAWN agents traverse is now
defined in [I-D.sato-soos-aop] rather than in this document
(Section 12); the relevance to DAWN is unchanged, only the
normative home of the definition.
Adjacent IETF work:
draft-ietf-wimse-arch:
WIMSE defines workload identity; SOV defines what the GEC
governs.
draft-ietf-scitt-architecture:
Event Stream entries are committed to a SCITT transparency log
at Level 3 conformance. SOV is an event-centric SCITT
application: SCITT is artifact-centric; SOV is governance-
event-centric.
draft-ietf-vcon-vcon-container:
Composition: SO governs during execution; vCon packages the
resulting records for portable post-session use. See Section 3.2.
draft-singla-agent-identity-protocol et al.:
Identity drafts establish what identity an agent presents.
SOV operates after identity is established: the SO defines
what the authorized agent acts upon, not who the agent is.
13. Security Considerations
This section documents the principal attack surfaces against the
Sovereign Object model. Implementers MUST address all attack
vectors documented here.
13.1. SO State Manipulation
Attack:
An adversary with application-layer access (but without GEC
authority) attempts to write the current_state field of an SO
Instance directly to the underlying data store, bypassing the
GEC and Cedar policy evaluation.
Mechanism:
If the SO's state store is accessible to application-layer
processes independently of the GEC, an adversary who compromises
an application process can overwrite current_state, causing
the GEC's next Cedar policy evaluation to use the false state
and potentially permitting a transition that would otherwise
be denied.
Defense:
The GEC MUST be the sole writer of Zone A fields. The SO state
store MUST be access-controlled such that only the GEC process
can write Zone A data. The GEC MUST verify SO state consistency
on every Transition Request by replaying the Event Stream head
against the cached current_state and MUST treat any divergence
as a critical security incident.
Residual risk:
If the GEC process itself is compromised, state manipulation
is not detectable by the GEC alone. Defense in depth requires
SCITT transparency log submission of all Event Stream entries:
an external verifier can detect state manipulation by comparing
the transparency log with the SO state store.
13.2. Event Stream Tampering
Attack:
An adversary attempts to modify, delete, or reorder committed
Event Stream entries to alter the apparent history of SO
transitions -- for example, to remove evidence of a prohibited
transition.
Mechanism:
Entry deletion removes the GAR and SCITT records of a
transition. Entry modification changes the transition record.
Entry reordering changes the apparent causal sequence.
Defense:
The GEC MUST sign every Event Stream entry (Section 8.1). The
prior_event_id chain MUST be verifiable from SO_CREATED to head.
SCITT transparency log submission (Section 8.1) provides external
verifiability. The GEC MUST treat any request to delete or
modify a committed Event Stream entry as a critical security
incident, immediately triggering HEM escalation with class
HEM_CLASS_INTEGRITY_VIOLATION.
The GEC MUST NOT serve an Event Stream with a broken
prior_event_id chain. A broken chain MUST be reported as
INTEGRITY_VIOLATION.
Residual risk:
An adversary with access to both the SO state store and the
SCITT transparency log submission endpoint could attempt to
suppress SCITT submission while manipulating the Event Stream.
Defense requires that SCITT submission be performed by an
independent process, not by the GEC, to prevent single-point
suppression.
13.3. SO Type Spoofing
Attack:
An adversary submits a Transition Request claiming an SO Type
that grants broader Cedar permissions than the SO Instance's
actual registered type, causing the GEC to evaluate the request
against a more permissive policy set.
Mechanism:
If the GEC resolves the SO Type's Cedar policy set from the
so_type_id field in the Transition Request (rather than from
the SO Instance's registered type), an adversary can substitute
a more permissive so_type_id.
Defense:
The GEC MUST resolve the SO Type and Cedar policy set exclusively
from the SO Instance's Identity Layer (Layer 1) so_type_id field,
as committed to the Event Stream at SO_CREATED. The GEC MUST NOT
accept the so_type_id from the Transition Request itself. The
GEC MUST verify that the SO Instance's so_type_id matches a
registered entry in the SO Type Registry at policy evaluation
time.
For SOV-02 subtypes, the GEC MUST resolve the complete Cedar
policy inheritance chain from the registry, not from the
Transition Request, and MUST verify that no link in the chain
has been tampered with since the SO Instance was created.
Residual risk:
If the SO Type Registry is compromised and a malicious Cedar
policy set is substituted at the registered URI, the GEC would
evaluate against the malicious policy. Defense requires that
the cedar_policy_set_uri be content-addressed: the GEC MUST
verify the SHA-256 hash of the Cedar policy set against a hash
committed to the Event Stream at SO_CREATED or most recent
CEDAR_BUNDLE_UPDATED entry.
13.4. Stale state_constraint Exploitation
Attack:
An adversary presents a Mandate JWT with a state_constraint
(permitted SO states) that was valid at the time the JWT was
issued but no longer matches the SO Instance's current state.
The adversary hopes the GEC will evaluate the JWT's
state_constraint against a cached (stale) SO state rather than
the current Event Stream head.
Mechanism:
If the GEC uses a cached current_state for Mandate JWT
state_constraint evaluation and the cache is stale, a transition
to state B may have occurred after the JWT was issued that renders
the JWT's state_constraint invalid. The adversary times the
Transition Request to exploit the cache staleness window.
Defense:
The GEC MUST evaluate state_constraint against the current Event
Stream head state, not a cached state. The GEC MUST acquire
a read lock on the Event Stream before reading current_state for
Mandate JWT validation and MUST NOT release the lock until the
Transition Request is either committed or denied.
The GEC SHOULD set Mandate JWT lifetimes (exp claims) short
enough that the probability of state divergence during a JWT's
validity window is minimal. Mandate JWTs with state_constraint
fields SHOULD have exp claims no longer than the expected
duration of the constrained state.
Residual risk:
In distributed GEC deployments where shadow GECs may have
slightly delayed Event Stream views, stale state evaluation
remains possible even with locking. Implementations MUST ensure
that Transition Requests are always processed by the primary GEC,
not shadow GECs, when state_constraint validation is required.
13.5. Agent Session Revocation
The Sovereign Object operates within the SOOS session lifecycle
model. When an agent session is revoked -- whether by operator
action, CAEP signal, or CAP constitutional violation -- ongoing
Transition Requests against the SO Instance are superseded by the
MAD session revocation procedure [I-D.sato-soos-mad] Section 3.6.
Implementations MUST NOT process agent-initiated Transition Requests
against an SO Instance after receiving a session revocation signal
for the agent session that bound the active Mandate JWT.
All pending Event Stream entries at point of revocation MUST be
marked with completion_state PARTIAL or CLEAN per
[I-D.sato-soos-mad] Section 3.6.3. The SO Instance MUST remain in
a non-transitionable state until a human principal with lifecycle
authority clears the revocation condition.
13.6. Infrastructure Security
SO Instance identifiers (so_id) are UUID v7 values carrying timing
information. Implementations that consider SO creation timing
sensitive MUST treat so_id values as sensitive and avoid exposing
them in unauthenticated contexts.
Zone B content integrity depends on the security of the Zone B
storage system. Implementations MUST ensure Zone B storage
provides integrity guarantees appropriate to the sensitivity of
stored content.
The GEC-SO association model (Section 11) creates a single point of
authority over an SO Instance. Implementations MUST protect GEC
signing keys at the conformance level declared by the GEC per
[I-D.sato-soos-idp] Section 9.
The Narrowing Property (Section 10.2) is a security invariant. Any
implementation permitting a child mandate to exceed its parent's
scope creates an authorization escalation vulnerability.
14. Privacy Considerations
Zone A Invariant INV-ZA-1 prohibits personal data in Zone A. This
is the primary privacy protection in the SO design: it ensures that
Zone A data and the Event Stream can be retained for audit after
Cryptographic Erasure without retaining personal data.
Zone B content MUST be encrypted at rest. Cryptographic Erasure
(Section 7.3) satisfies erasure obligations under GDPR Article 17
[GDPR] and APPI Article 19 [APPI] by destroying Zone B encryption
keys.
The human_principal_id field is a persistent identifier for a
natural person. Access MUST be controlled by Cedar policy.
The Event Stream may contain agent identifiers and action records
that constitute personal data under applicable law. Implementations
MUST apply appropriate access controls to Event Stream queries and
ensure retention periods comply with applicable data retention law.
The SPO scope_constraints.geographic_scope field (Section 6.3) is
a structured jurisdiction declaration. It does not constitute
personal data but MUST be treated as operationally sensitive, as
it reveals the jurisdictions in which an operator's agents are
permitted to act.
The same operational-state sensitivity applies to any SOV-02
subtype carrying live execution state -- for example, AOP's
Mission Status SO (Section 12) -- whether or not that subtype is
defined in this document: access to such fields MUST be governed
by Cedar policy and restricted to authorized monitoring principals.
15. IANA Considerations
15.1. SO Type Registry
Registry name: Sovereign Object Type Registry
Registration procedure: Specification Required per [RFC8126]
Section 4.6. Registration requests must include all fields
defined in Section 5.1 and satisfy the Expert Review Criteria
specified in Section 5.4.
Designated Expert: To be assigned by IANA.
Initial registrations: None. The first registration is expected
from the ATP Foundation following RFC publication, registering
"atp/booking-object" as the reference implementation SO Type.
The second registration is expected from SOOS Project, registering
"soos/standing-plan-object" as a normative SOOS subtype defined
in this document. Registration of "soos/mission-plan" and
"soos/mission-status" is expected from [I-D.sato-soos-aop], which
normatively defines those subtypes.
15.2. SO Type Code Namespace
IANA is requested to reserve the "soos/" prefix in the Sovereign
Object Type Registry for SO Types defined in SOOS specifications.
Third-party registrants MUST NOT use the "soos/" prefix.
IANA is requested to reserve the "ietf/" prefix for SO Types
defined in IETF Standards Track documents.
All other prefixes are open for registration by any registrant,
subject to the registration procedure in Section 15.1.
15.3. SO Lifecycle Phase Registry
Registry name: Sovereign Object Lifecycle Phase Registry
Registration procedure: Specification Required.
Initial registrations:
Phase Name Description
ACTIVE Normal operation phase.
OPERATIONALLY_COMPLETE Terminal operational state reached.
ADMINISTRATIVELY_CLOSED Administrative closure phase.
ARCHIVED Read-only retention phase.
CRYPTOGRAPHICALLY_ERASED Zone B content erased.
15.4. SO Event Type Registry
Registry name: Sovereign Object Event Type Registry
Registration procedure: Specification Required.
Initial registrations:
Event Type Description
SO_CREATED SO Instance created.
STATE_TRANSITIONED State machine transition executed.
ZONE_B_ATTACHED Zone B content attached.
ZONE_B_DETACHED Zone B content detached.
MANDATE_BOUND Mandate JWT bound to SO Instance.
MANDATE_REVOKED Mandate JWT revoked.
HEM_TRIGGERED HEM escalation triggered.
HEM_RESOLVED HEM escalation resolved.
PHASE_TRANSITIONED Lifecycle phase transition.
ERASURE_INITIATED Cryptographic erasure initiated.
ERASURE_COMPLETED Cryptographic erasure completed.
GEC_TRANSITIONED GEC association transferred.
SPO_ACTIVATED Standing Plan Object activated.
SPO_DEACTIVATED Standing Plan Object deactivated.
CEDAR_BUNDLE_UPDATED SPO Cedar bundle updated mid-plan.
(REMOVED in -03) SUBGOAL_COMPLETED, SUBGOAL_FAILED,
MISSION_COMPLETE, MISSION_FAILED, MISSION_STATUS_BOUND, and
MISSION_STATUS_DIVERGENCE were registered here in -02 for the
Mission Plan SO / Mission Status SO subtypes. Those subtypes are
now defined exclusively by [I-D.sato-soos-aop] (Section 12), which
registers their event types in its own IANA Considerations rather
than in this registry.
15.5. SPO Media Type
IANA is requested to register the following media type:
Type name: application
Subtype name: soos-standing-plan-object+json
Required parameters: None.
Optional parameters: version (string, semantic version of the
SPO specification).
Encoding considerations: Binary (UTF-8 encoded JSON).
Security considerations: See Section 13 of this document.
Interoperability considerations: The SPO JSON structure is defined
in Section 6.2 of this document.
Published specification: This document.
Applications that use this media type: SOOS GEC implementations,
disaster response systems, multi-agent
orchestration platforms, and any system
implementing the Standing Plan Object
governance model.
Fragment identifier considerations: None.
Restrictions on usage: None.
Author: Tom Sato, tomsato@myauberge.jp
Change controller: IETF
16. References
16.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, May 2017.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs",
BCP 26, RFC 8126, June 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-06, September
2026.
[I-D.sato-soos-hem]
Sato, T., "The Human Escalation Mechanism (HEM) for
Agentic AI Systems", draft-sato-soos-hem-07, September
2026.
[I-D.sato-soos-gar]
Sato, T., "Governance Audit Record (GAR) for Agentic
AI Systems", draft-sato-soos-gar-08, September 2026.
[I-D.sato-soos-cap]
Sato, T., "Constitutional AI Protocol (CAP) for Agentic
AI Systems", draft-sato-soos-cap-06, September 2026.
[I-D.sato-soos-mjwt]
Sato, T., "The Mandate JWT (MJWT) for Agentic AI Systems",
draft-sato-soos-mjwt-06, September 2026.
[I-D.sato-soos-kia]
Sato, T., "Kernel Identity Attestation (KIA) for Agentic
AI Systems", draft-sato-soos-kia-07, September 2026.
[I-D.sato-soos-mad]
Sato, T., "Multi-Agent Delegation (MAD) for Agentic
AI Systems", draft-sato-soos-mad-05, September 2026.
[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.
[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.
16.2. Informative References
[I-D.ietf-wimse-arch]
Salomoni, D., et al., "WIMSE Architecture",
draft-ietf-wimse-arch, work in progress.
[I-D.ietf-vcon-vcon-container]
Howe, T., et al., "The vCon Container",
draft-ietf-vcon-vcon-container, work in progress.
[SOOS-FAIP] Sato, T., "Federated Agent Intelligence Protocol (FAIP)",
September 2026, <https://soosproject.ai/drafts/faip>.
[I-D.sato-soos-aop]
Sato, T., "Agentic Orchestration Protocol (AOP) for
Agentic AI Systems", draft-sato-soos-aop-03,
September 2026.
[OTel] OpenTelemetry Authors, "OpenTelemetry Specification",
https://opentelemetry.io/docs/specs/otel/
[ATP] ATP Foundation, "Activity Travel Protocol -- Layer 3
Specification", https://activitytravel.pro/layer3/
Appendix A. ATP Booking Object -- Reference Implementation
The ATP Booking Object is the reference implementation of the
Sovereign Object primitive. It is the SO Type that the Activity
Travel Protocol [ATP] defines for governing travel transactions
across AI agents, operators, and travellers. It has been operational
as a reference implementation at MyAuberge K.K. (Chino, Nagano,
Japan) since early 2026.
A.1. SO Type Registration
so_type_id: "atp/booking-object/1.0"
registrant: ATP Foundation (activity-travel-protocol.org)
specification: https://activitytravel.pro/layer3/
A.2. State Machine
The ATP Booking Object has eleven canonical states:
State Description
INQUIRY Booking intent declared; no commitment.
FEASIBILITY_CHECK Async feasibility validation in progress.
AWAITING_CONFIRMATION Feasibility passed; supplier confirmation
pending.
CONFIRMED All parties confirmed; booking live.
PRE_ACTIVITY Pre-activity collection phase.
IN_JOURNEY Traveller in experience; tracks sub-phases.
COMPLETED Journey finished; duty-of-care met.
CANCELLED Booking cancelled.
EXPIRED Booking lapsed without confirmation.
BOOKING_SUSPENDED Cross-cutting disruption state; overlays
any other state.
DISPUTED Dispute opened post-completion.
The IN_JOURNEY state carries eight sub-phases: PRE_DEPARTURE,
TRANSIT, ARRIVAL, ORIENTATION, ACTIVITY, POST_ACTIVITY, RETURN,
POST_JOURNEY.
BOOKING_SUSPENDED is a cross-cutting state modifier that may overlay
any non-terminal state. When active, all agent-initiated transitions
are prohibited until a human principal resolves the suspension.
A.3. Zone A / Zone B Application
Zone A fields: so_id, so_type_id, current_state, booking_reference,
operator_id, supplier_id, activity_id, journey_date, policy_version.
Zone B attachments: traveller identity documents, health
declarations, consent records, insurance certificates, and all
other personal data
associated with the booking.
This separation enables the ATP Booking Object Event Stream to be
retained for audit after Cryptographic Erasure of traveller personal
data, satisfying GDPR Article 17 erasure obligations without
destroying the governance audit record.
A.4. SO Lifecycle Mapping
The ATP Booking Object's eleven operational states exist entirely
within SO Lifecycle Phase 1 (ACTIVE). The SO Lifecycle Phase
transitions of Section 7 govern the Booking Object's progression
from active operation through archival and eventual Cryptographic
Erasure of traveller personal data.
The two-axis model -- Booking Object state (operational) and SO
Lifecycle Phase (governance) -- are orthogonal. A booking in
IN_JOURNEY state is simultaneously in SO Phase 1 (ACTIVE). A
booking in COMPLETED state transitions to SO Phase 2
(OPERATIONALLY_COMPLETE) after billing and duty-of-care obligations
are satisfied.
Appendix B. Disaster Response SPO -- Reference Implementation
This appendix illustrates the Standing Plan Object (Section 6) in
the context of the 北海道 M7.2 disaster response scenario. This
is an informative reference implementation.
B.1. SPO Registration
so_type_id: "soos/standing-plan-object/1.0"
registrant: SOOS Project (soosproject.ai)
specification: This document, Section 6.
B.2. Scope Constraints
The disaster response SPO for the 北海道 M7.2 scenario carries
the following scope_constraints:
{
"geographic_scope": [
{ "jurisdiction": "JP", "sub_jurisdiction": "JP-01" }
],
"so_type_scope": [
"soos/disaster-event/1.0",
"soos/shelter-resource/1.0",
"soos/resource-request/1.0",
"soos/victim-relief/1.0"
],
"agent_role_scope": [
"disaster_response_coordinator",
"shelter_operator",
"logistics_agent",
"medical_dispatch_agent"
],
"temporal_scope": {
"not_before": "2026-07-07T00:00:00Z",
"not_after": "2026-08-07T00:00:00Z"
},
"max_delegation_depth": 3
}
B.3. Cedar Bundle Reference
cedar_bundle_ref: "https://soosproject.ai/cedar/
disaster-response-jp/hokkaido-m72-
2026-07-07.cedar"
The Cedar bundle activates the disaster exception profile for
DMAT deployment authorization, medical data access under disaster
provisions (経路B/C per the medical data governance framework), and
対口支援 external personnel access with scoped CAP-RRS permissions.
B.4. Activation Scenario
At T+130s (disaster scenario timeline), the SOOS GEC activates the
disaster response SPO. The activation sequence:
(1) SPO Instance created with state DRAFT; so_id assigned.
(2) 北海道知事 approves the plan: SPO transitions DRAFT -> APPROVED;
HEM escalation HEM-004 resolved; APPROVED Event Stream entry
GEC-signed.
(3) Authorized agent activates the plan: SPO transitions
APPROVED -> ACTIVE; SPO_ACTIVATED Event Stream entry generated;
Cedar bundle loaded; CAP-RRS disaster profile activated.
(4) All subsequent agent Transition Requests in the disaster
response reference the SPO so_id. Every HEM escalation
(HEM-001 through HEM-013 in the disaster demo timeline)
references the SPO so_id as the governing plan identifier.
(5) At disaster response conclusion, authorized agent completes
the plan: SPO transitions ACTIVE -> COMPLETED; SPO_DEACTIVATED
Event Stream entry generated.
Appendix C. Vibe Coding Assets
This appendix provides structured machine-readable references to
support AI-assisted implementation of SOV. Informative.
C.1. Protocol Summary
Protocol: Sovereign Object (SOV)
Version: draft-sato-soos-sov-03
Family: SOOS protocol suite
Role: Governed resource primitive -- the typed, stateful,
policy-carrying entity that agents operate on, the GEC
governs, and human principals reason about
Stack position: Foundation layer. All SOOS governance protocols
(IDP, HEM, GAR, CAP, MJWT, MAD, AEP, KIA) operate
on SO Instances. The SO is the missing normative
referent that gives Mandate JWT binding its
specificity and makes authorization auditable,
revocable, and scoped.
-02 additions: SPO (Standing Plan Object), SO Type registry
governance, SOV-02 subtype model, event stream
integrity, OTel integration, IANA SO Type code
namespace, SPO media type.
-03 changes: removed Mission Plan SO / Mission Status SO
(now owned by [I-D.sato-soos-aop]); reordered
Section 9.3 Cedar policy evaluation to verify
Mandate JWT before Cedar; updated cross-draft
version references.
C.2. Key Identifiers
SO Instance identifier: so_id (UUID v7, time-ordered)
SO lifecycle phases: ACTIVE, OPERATIONALLY_COMPLETE,
ADMINISTRATIVELY_CLOSED, ARCHIVED, CRYPTOGRAPHICALLY_ERASED
Five layers: Identity (Layer 1), State (Layer 2), Event Stream
(Layer 3), Typed Graph (Layer 4), Attachment Index (Layer 5)
Zone model: Zone A (Protocol Core, no personal data, GEC-governed),
Zone B (Attached Periphery, personal data, integrity-verified)
Zone invariants: INV-ZA-1 (no personal data in Zone A),
INV-ZA-2 (Zone A fields must be schema-defined),
INV-ZB-1 (Zone B referenced via Attachment Index),
INV-ZB-2 (GEC verifies Zone B integrity on access)
Cedar context attributes (Section 9.1):
so.so_id, so.so_type_id, so.current_state, so.current_phase,
so.human_principal_id, so.prior_denial_count, so.mandate_count
SPO additional Cedar attributes:
spo.plan_name, spo.activation_at,
spo.temporal_scope.not_after
IANA registries: SO Type Registry, SO Type Code Namespace,
SO Lifecycle Phase Registry, SO Event Type Registry,
SPO Media Type (Section 15)
Normative SOOS subtypes: soos/standing-plan-object/1.0. (REMOVED
in -03: soos/mission-plan/1.0 and soos/mission-status/1.0 are
now defined and registered by [I-D.sato-soos-aop], not here.)
Reference implementations: atp/booking-object/1.0 (Appendix A),
disaster response SPO (Appendix B)
C.3. Canonical Reference
Specification: https://soosproject.ai/drafts/sov
Datatracker: https://datatracker.ietf.org/doc/draft-sato-soos-sov/
Stack overview: https://soosproject.ai/stack
Appendix D. Changes from Previous Versions (NEW in -03)
D.1. Changes from draft-sato-soos-sov-02
This revision closes out a WIMSE Security Review checklist pass
(Stage 0 through Stage 2) run against -02, cross-checked against
[I-D.sato-soos-mad] and [I-D.sato-soos-aop].
o Section 7 (removed, was "Mission Plan SO and Mission Status
SO"): -02 normatively defined the Mission Plan SO and Mission
Status SO as SOV-02 subtypes, duplicating subtypes
[I-D.sato-soos-aop] also normatively defines -- AOP's own
Section 1 states plainly that "the Mission Plan SO and Mission
Status SO are SO subtypes defined by AOP." The duplication
produced a genuine cross-draft inconsistency: -02's DAG model
had no typed dependency edges at all, while AOP Section 7.2
defines a materially more complete model (SEQUENTIAL, PARALLEL,
CONDITIONAL dependency types, deadline tracking, critical-path
annotation, well-formedness validation). This revision removes
-02's duplicate definition entirely and defers to AOP as sole
owner, including AOP's dependency-type vocabulary. All other
references to Section 7 throughout this document (Terminology,
Section 5.5, Section 9.1 Cedar attributes, Section 12
Relationship to Other SOOS Drafts, Section 14 Privacy
Considerations, Section 15 IANA Considerations, Appendix C) are
updated accordingly, and Section 12 gains a new AOP relationship
paragraph. Sections 8 through 16 are renumbered down by one
(old Section 8 "SO Lifecycle" is now Section 7, and so on)
to close the gap left by Section 7's removal.
o Section 9.3 (Policy Evaluation Order, updated): -02 placed
Mandate JWT scope verification last, as layer 5, after SO Type
Cedar policy evaluation at layer 4. This directly contradicted
[I-D.sato-soos-mjwt] Section 8.1, which requires all thirteen
MJWT verification steps to complete before Cedar policy
evaluation runs at all. Read literally, -02's ordering allowed
Cedar to evaluate -- and reach PERMIT -- using SO Instance state
attributes (Section 9.1) and IDP intent attributes populated on
the assumption of an already-validated principal/mandate
relationship the pipeline had not actually confirmed yet; a
Stage 2 scenario confirmed this trace-level consequence directly
(Cedar evaluation ran and returned PERMIT on an invalid-signature
MJWT, even though the overall pipeline still reached the
correct final DENY in that scenario). Mandate JWT verification
is now layer 1, ahead of CAP Tier 0, since CAP's own Section 6.2
CEE protocol does not itself depend on MJWT validity while
Cedar's SO Type policy evaluation explicitly does (per
[I-D.sato-soos-cap] Section 5.4's requirement to populate Cedar
context from the session MJWT's consent_scope claim).
o Cross-draft version references (editorial): eight normative
and informative references to sibling SOOS drafts were stale,
citing versions as old as draft-sato-soos-mjwt-02 and
draft-sato-soos-kia-03 against current suite versions of -05
and -06 respectively. All updated to current versions
(Section 16.1, Section 16.2). [I-D.sato-soos-aop] added as a
new informative reference, reflecting its role as sole owner
of the Mission Plan SO / Mission Status SO subtypes.
o Editorial: title-block date and expiry updated; no bracket-tag
or Abstract section-reference cleanup was needed for this
document (neither pattern was present in -02).
Acknowledgements
The Sovereign Object design synthesizes patterns from multiple IETF
working groups. The Event Stream causal ordering model draws on
the SCITT architecture [I-D.ietf-scitt-architecture]. The Zone A
/ Zone B boundary model was developed through structured
architectural review of the SOOS Cluster 1 Examination sessions
and informs the FAIP analytics surface boundary. The vCon / SO
composition pattern (Section 3.2) builds on Thomas Howe's work on
agentic architecture layering and the vCon container
specification. The ATP Booking Object reference implementation
(Appendix A) has been operational at
MyAuberge K.K. since early 2026 and serves as the primary validation
surface for the SOV design. The disaster response SPO reference
implementation (Appendix B) is grounded in real Japanese government
disaster response law and the 防災AX architecture developed for the
Cabinet Office AX initiative engagement.
Author's Address
Tom Sato
MyAuberge K.K.
Chino, Nagano, Japan
Email: tomsato@myauberge.jp
URI: https://soosproject.ai/drafts/sov