# drafts

name: draft-bates-atp
rev: 00
title: Agent Transaction Protocol (ATP)
time: 2026-05-12T05:27:15Z
group_uri: /api/v1/group/group/1027/
expires: 2026-11-13T05:27:15Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["Agent identity/auth", "Policy/governance", "Data formats/interop"]
tags: []
fetched_at: 2026-05-22T09:24:47.115476+00:00
source: ietf
abstract:
  ATP defines a cryptographically verifiable directed acyclic graph
     (DAG) model for agent transactions.  ATP enables tamper-evident
     signed causality and auditable lineage across agentic systems by
     representing each action as a signed node with one or more parent
     references, assuming verifier access to issuer public keys and the
     referenced parent nodes.  The protocol is designed to be lightweight,
     transport-independent, and suitable for environments where
     accountability, provenance, and verifiable history are required.

full_text:
  Independent Submission                                          D. Bates
  Internet-Draft                                              SVT Robotics
  Intended status: Informational                               10 May 2026
  Expires: 11 November 2026


                      Agent Transaction Protocol (ATP)
                             draft-bates-atp-00

  Abstract

     ATP defines a cryptographically verifiable directed acyclic graph
     (DAG) model for agent transactions.  ATP enables tamper-evident
     signed causality and auditable lineage across agentic systems by
     representing each action as a signed node with one or more parent
     references, assuming verifier access to issuer public keys and the
     referenced parent nodes.  The protocol is designed to be lightweight,
     transport-independent, and suitable for environments where
     accountability, provenance, and verifiable history are required.

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

  Copyright Notice

     Copyright (c) 2026 IETF Trust and the persons identified as the
     document authors.  All rights reserved.

     This document is subject to BCP 78 and the IETF Trust's Legal
     Provisions Relating to IETF Documents (https://trustee.ietf.org/
     license-info) in effect on the date of publication of this document.
     Please review these documents carefully, as they describe your rights
     and restrictions with respect to this document.




  Bates                   Expires 11 November 2026                [Page 1]


  Internet-Draft                     ATP                          May 2026


  Table of Contents

     1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   4
       1.1.  Document Scope  . . . . . . . . . . . . . . . . . . . . .   4
       1.2.  Cumulative Deferrals  . . . . . . . . . . . . . . . . . .   5
     2.  Conventions and Requirements Language . . . . . . . . . . . .   5
     3.  Problem Statement . . . . . . . . . . . . . . . . . . . . . .   6
     4.  Design Goals  . . . . . . . . . . . . . . . . . . . . . . . .   6
     5.  Non-Goals . . . . . . . . . . . . . . . . . . . . . . . . . .   7
     6.  Architecture Overview . . . . . . . . . . . . . . . . . . . .   8
       6.1.  Deployment Patterns . . . . . . . . . . . . . . . . . . .   9
     7.  Data Model  . . . . . . . . . . . . . . . . . . . . . . . . .   9
     8.  Node Schema . . . . . . . . . . . . . . . . . . . . . . . . .  10
     9.  Canonicalization  . . . . . . . . . . . . . . . . . . . . . .  14
     10. Signing and Verification  . . . . . . . . . . . . . . . . . .  14
       10.1.  Node Identity  . . . . . . . . . . . . . . . . . . . . .  14
       10.2.  Signature Algorithm  . . . . . . . . . . . . . . . . . .  15
       10.3.  Signature Computation  . . . . . . . . . . . . . . . . .  15
       10.4.  Verification . . . . . . . . . . . . . . . . . . . . . .  15
     11. Heritage and DAG Semantics  . . . . . . . . . . . . . . . . .  17
       11.1.  Identical Content and Idempotency  . . . . . . . . . . .  18
     12. Scope Model . . . . . . . . . . . . . . . . . . . . . . . . .  18
     13. Validation Modes  . . . . . . . . . . . . . . . . . . . . . .  20
       13.1.  Full Recursive Validation  . . . . . . . . . . . . . . .  20
       13.2.  Bounded Validation . . . . . . . . . . . . . . . . . . .  20
       13.3.  Tip Validation . . . . . . . . . . . . . . . . . . . . .  21
       13.4.  Redacted-Lineage Validation  . . . . . . . . . . . . . .  21
       13.5.  Minimum Support and Validation Results . . . . . . . . .  21
       13.6.  Validation Result Format . . . . . . . . . . . . . . . .  22
       13.7.  ATP Core Conformance . . . . . . . . . . . . . . . . . .  24
     14. Security Considerations . . . . . . . . . . . . . . . . . . .  25
       14.1.  Relay Node Trust Semantics . . . . . . . . . . . . . . .  25
       14.2.  Relay Fidelity Validation States . . . . . . . . . . . .  27
       14.3.  Timestamp Trust  . . . . . . . . . . . . . . . . . . . .  27
       14.4.  Signature Scope  . . . . . . . . . . . . . . . . . . . .  27
       14.5.  Trust Model Summary  . . . . . . . . . . . . . . . . . .  27
       14.6.  Suppression and Anti-Suppression . . . . . . . . . . . .  28
       14.7.  Replay and Scope Binding . . . . . . . . . . . . . . . .  29
     15. Privacy Considerations  . . . . . . . . . . . . . . . . . . .  29
       15.1.  Data Minimization  . . . . . . . . . . . . . . . . . . .  29
       15.2.  Deletion and Retention Tension . . . . . . . . . . . . .  30
       15.3.  Chain Existence as Metadata  . . . . . . . . . . . . . .  30
       15.4.  Pseudonymous Identifiers and Post-Deletion
              Verification . . . . . . . . . . . . . . . . . . . . . .  31
     16. Operational Considerations  . . . . . . . . . . . . . . . . .  31
       16.1.  Key Lifecycle  . . . . . . . . . . . . . . . . . . . . .  31
       16.2.  Request/Completion Pairing . . . . . . . . . . . . . . .  32
       16.3.  Cross-Scope Resolution . . . . . . . . . . . . . . . . .  33



  Bates                   Expires 11 November 2026                [Page 2]


  Internet-Draft                     ATP                          May 2026


       16.4.  Actor Mapping Guidance . . . . . . . . . . . . . . . . .  34
       16.5.  Agent Versioning Guidance  . . . . . . . . . . . . . . .  34
       16.6.  Issuer Identity Granularity  . . . . . . . . . . . . . .  35
       16.7.  Storage Model Guidance . . . . . . . . . . . . . . . . .  36
       16.8.  Permissioned Verifiability . . . . . . . . . . . . . . .  37
       16.9.  Deletion and Redaction Operations  . . . . . . . . . . .  38
       16.10. Performance Budget Guidance  . . . . . . . . . . . . . .  39
       16.11. Node Granularity Guidance  . . . . . . . . . . . . . . .  40
       16.12. Chain Exchange Patterns  . . . . . . . . . . . . . . . .  41
     17. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  42
       17.1.  ATP Action Types Registry  . . . . . . . . . . . . . . .  42
       17.2.  ATP Profiles Registry  . . . . . . . . . . . . . . . . .  44
       17.3.  URN Sub-Namespace Registration . . . . . . . . . . . . .  45
     18. Implementation Status . . . . . . . . . . . . . . . . . . . .  45
     19. Profile Framework . . . . . . . . . . . . . . . . . . . . . .  46
       19.1.  Profile Identifiers  . . . . . . . . . . . . . . . . . .  46
       19.2.  Profile Versioning . . . . . . . . . . . . . . . . . . .  47
       19.3.  Minimum Profile Contract . . . . . . . . . . . . . . . .  48
       19.4.  Canonicalization of Profile-Defined Fields . . . . . . .  49
       19.5.  Conformance Levels . . . . . . . . . . . . . . . . . . .  50
       19.6.  Worked Profile Reference . . . . . . . . . . . . . . . .  50
       19.7.  Profile Assessment States  . . . . . . . . . . . . . . .  50
     20. Normative References  . . . . . . . . . . . . . . . . . . . .  51
     21. Informative References  . . . . . . . . . . . . . . . . . . .  52
     Worked Example: MCP Tool Discovery and Invocation . . . . . . . .  53
       A.1 Scenario  . . . . . . . . . . . . . . . . . . . . . . . . .  53
       A.2 Node Sequence . . . . . . . . . . . . . . . . . . . . . . .  54
         Node 1 -- tool catalog query (atp:request)  . . . . . . . . .  54
         Node 2 -- tool catalog response (atp:completion)  . . . . . .  55
         Node 3 -- tool selection decision (atp:decision)  . . . . . .  56
         Node 4 -- tool invocation request (atp:request) . . . . . . .  56
         Node 5 -- tool execution (atp:completion) . . . . . . . . . .  57
         Node 6 -- tool execution response (atp:relay) . . . . . . . .  57
         Node 7 -- decision synthesis (atp:decision) . . . . . . . . .  58
       A.3 DAG Structure . . . . . . . . . . . . . . . . . . . . . . .  58
       A.4 What This Example Demonstrates  . . . . . . . . . . . . . .  60
       A.5 Profile Note: action.type and action.subtype Vocabulary . .  61
     Future Work and Areas for Further Refinement  . . . . . . . . . .  61
     Related Work  . . . . . . . . . . . . . . . . . . . . . . . . . .  62
       C.1 Identity and Authentication . . . . . . . . . . . . . . . .  63
       C.2 Agent Communication Frameworks  . . . . . . . . . . . . . .  63
       C.3 Domain-Specific Governance  . . . . . . . . . . . . . . . .  63
       C.4 Standards Coordination  . . . . . . . . . . . . . . . . . .  64
       C.5 Existing RFCs Applied to Agent Systems  . . . . . . . . . .  64
       C.6 Transparency and Supply-Chain Provenance  . . . . . . . . .  64
       C.7 ATP's Distinct Contribution . . . . . . . . . . . . . . . .  65
     Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  65




  Bates                   Expires 11 November 2026                [Page 3]


  Internet-Draft                     ATP                          May 2026


  1.  Introduction

     Agentic systems are rapidly increasing in autonomy, composition, and
     reach.  Agents now invoke tools, delegate work to other agents,
     operate across service boundaries, and act on behalf of both humans
     and non-human principals.  Existing observability and identity
     standards solve parts of this problem, but they do not fully answer a
     more difficult governance question: can an independent verifier prove
     what action occurred, what prior actions caused it, and under whose
     authority it was taken?

     ATP is intended to address that gap.  ATP does not attempt to replace
     existing identity, authorization, transport, or observability
     mechanisms.  Instead, ATP defines a minimal protocol for expressing
     agent actions as signed graph nodes with explicit parent references.
     This makes the resulting lineage tamper-evident; independent
     verification requires access to issuer public keys and parent nodes
     through deployment-specific mechanisms.

     ATP is designed around causality rather than simple sequencing.
     Linear logs can describe what happened next, but complex agent
     systems require a model that can express branching, merging,
     delegation, and parallelism.  ATP therefore adopts a DAG model so
     that the protocol can represent heritage truthfully rather than
     forcing artificial ordering.

  1.1.  Document Scope

     This document defines *ATP Core*: the node schema, canonicalization,
     signing, validation, scope model, validation modes, security
     considerations, privacy considerations, operational guidance, IANA
     registries, and a Profile Framework that establishes how profiles MAY
     extend or constrain Core.

     Profile-specific rules -- including domain-specific action-type
     vocabularies, emission and node-worthiness rules, sealed-scope
     semantics, composite conformance labels, the full profile
     specification template, and profile registration procedures -- are
     defined in separate profile specifications registered under the ATP
     Profiles registry (see Section 17.2 and Section 20).  One
     illustrative example of such a profile is an ATP-MCP profile that
     defines composite conformance labels such as ATP-MCP-L1, ATP-MCP-L2,
     or ATP-MCP-L3 for chains describing Model Context Protocol [MCP]
     interactions; ATP-MCP is one possible profile among many and is not
     specially privileged by ATP Core.  The companion document
     [ATP-PROFILES] is one such specification and is not normatively
     required to use ATP Core.




  Bates                   Expires 11 November 2026                [Page 4]


  Internet-Draft                     ATP                          May 2026


  1.2.  Cumulative Deferrals

     ATP Core intentionally defers several operational concerns to
     deployments and future specifications: key discovery (Section 16.1),
     cross-scope retrieval and federation (Section 16.3), transport
     binding, deletion mechanisms (Section 16.9), well-known URI
     registration (Section 17.3), and algorithm agility (Section 10).
     Each individual deferral is a deliberate scope-discipline choice.
     Cumulatively, the minimum operationally complete deployment between
     two strangers therefore requires out-of-spec agreements on key
     publication, node availability, and transport.  Deployments that
     cannot reach those agreements out-of-band SHOULD layer ATP with a
     transparency service or federation profile (Section 14.6,
     Section C.6) rather than expanding ATP Core.

  2.  Conventions and Requirements Language

     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.

     For the purposes of this document:

     *  *Node:* A single ATP transaction object.

     *  *Parent:* A referenced prior node that contributes to the current
        node's heritage.

     *  *Heritage:* The recursively traversable causal lineage of a node.

     *  *Issuer:* The entity that signs the node.

     *  *Agent:* The execution identity that performed the action.  An
        agent MAY be any executable identity -- a software service, an AI
        model, a robotic system, an automated process, or a human operator
        acting through an instrumented interface.  ATP does not assume an
        agent is an AI model; the term is used in its general sense of
        "the entity that took the action."

     *  *Actor:* An OPTIONAL delegating principal on whose behalf the
        action was taken.  The actor is distinct from the agent: the agent
        performs the action, the actor authorizes it.  An actor MAY be a
        human, a service account, a scheduled-job identity, or another
        accountable non-human principal.





  Bates                   Expires 11 November 2026                [Page 5]


  Internet-Draft                     ATP                          May 2026


     *  *Scope:* The transaction boundary within which node identity and
        validation semantics are evaluated.

     *  *Validation:* The act of recomputing node identity, verifying
        signatures, and traversing parent relationships according to ATP
        rules.

     *  *Profile:* A normative specification that extends or constrains
        ATP Core for a specific deployment context, domain, or
        interoperability scope (see Section 20).

     *  *Profile Assessment:* A profile-defined evaluation of whether a
        node or scope satisfies a profile's emission, lineage, or
        completion rules.  Profile assessment is distinct from ATP Core
        validation (see Section 20.7).

  3.  Problem Statement

     Modern agentic systems create a governance gap.  An action may be
     initiated by one principal, delegated to an orchestrator, enriched by
     multiple subordinate agents, and executed through tools or downstream
     systems.  Traditional logs can record these events, but they are
     frequently mutable, centralized, or unable to prove lineage
     independently of the platform that produced them.  Likewise, identity
     tokens can prove who was authenticated, but they do not provide a
     durable, linked record of what happened across a causal graph of
     actions.

     This creates operational and governance problems, including but not
     limited to agent sprawl, weak accountability, incomplete audit
     trails, and difficulty reconstructing a trustworthy history of
     actions after an incident.  ATP is intended to provide a common
     protocol layer for verifiable agent-action lineage without requiring
     a blockchain, without embedding large payloads, and without taking
     ownership of broader policy or trust-distribution concerns.

  4.  Design Goals

     ATP is designed to satisfy the following goals:

     *  *Verifiable causality:* An implementation can determine what prior
        node or nodes caused a current action.

     *  *Tamper-evident heritage:* Changes to a node or its referenced
        lineage invalidate downstream verification.

     *  *Deterministic identity:* Independently implemented systems can
        compute the same node identity from the same canonical content.



  Bates                   Expires 11 November 2026                [Page 6]


  Internet-Draft                     ATP                          May 2026


     *  *Lightweight representation:* ATP carries hashes and lineage
        references rather than full payload bodies.

     *  *Transport independence:* ATP is not bound to a specific
        transport, runtime, vendor, or model provider.

     *  *Role separation:* Issuer, agent, and actor are represented
        distinctly so that governance questions can be answered without
        conflating execution identity and delegated authority.

     *  *DAG-native semantics:* ATP models branching and merging natively
        rather than forcing complex systems into an artificial linear
        chain.

  5.  Non-Goals

     ATP intentionally does not define several adjacent concerns.

     ATP Core does not define:

     *  trust registries or cross-organization trust anchors;

     *  key distribution, discovery, or long-term revocation
        infrastructure;

     *  payload storage or payload confidentiality controls;

     *  authorization policy or runtime access control decisions;

     *  consensus mechanisms or conflict resolution across divergent
        histories;

     *  execution semantics for how agents, tools, or workflows must
        behave;

     *  profile governance procedures, the profile specification template,
        or composite conformance labels (those are defined by individual
        profile specifications and by [ATP-PROFILES]);

     *  domain-specific node-worthiness, streaming semantics, or sealed-
        scope mechanisms (those are profile responsibilities, see
        Section 20);

     *  anti-suppression mechanisms (see Section 14.6); a transparency-
        service layer such as a SCITT-compatible service (see Section C.6)
        MAY be composed alongside ATP where anti-suppression is required.





  Bates                   Expires 11 November 2026                [Page 7]


  Internet-Draft                     ATP                          May 2026


     Those concerns may be layered alongside ATP Core, but keeping them
     out of the core protocol is necessary to preserve implementability,
     interoperability, and scope discipline.

  6.  Architecture Overview

     ATP is a protocol layer, not a full platform.  ATP assumes that
     systems already have mechanisms for transport, execution, payload
     storage, and authorization.  ATP adds a verifiable transaction layer
     that can travel alongside those mechanisms.

     ATP is intentionally domain-neutral.  It is suitable for AI agent
     orchestration, but equally suitable for any system that benefits from
     cryptographically signed, causally linked records of actions.
     Illustrative use cases include (non-exhaustively): an insurance
     underwriting workflow recording the chain of claim adjudication
     decisions; a fraud-detection pipeline recording each scoring step and
     the data used; a regulated medical-triage system recording why one
     path was selected over another; a supply-chain routing system
     recording handoffs between carriers; or any orchestrator-and-tool
     architecture (the pattern Appendix A illustrates).  The protocol
     mechanics -- DAG-structured signed nodes with deterministic identity
     -- are the same in all cases.

     At a high level, an ATP-aware system performs the following steps for
     each action:

     1.  Construct a transaction node describing the action.

     2.  Canonicalize the node according to ATP rules.

     3.  Compute the node identifier from the canonical content.

     4.  Sign the node identifier using the issuer's private key.

     5.  Store, emit, or transmit the signed node through implementation-
         specific means.

     6.  Validate the node and its parents when lineage or integrity must
         be verified.

     ATP is intentionally compatible with centralized or decentralized
     storage patterns.  A deployment MAY keep nodes in an append-only
     event store, a content-addressed object store, a relational database,
     or another storage substrate, provided ATP node integrity and parent
     resolution semantics are preserved.





  Bates                   Expires 11 November 2026                [Page 8]


  Internet-Draft                     ATP                          May 2026


  6.1.  Deployment Patterns

     ATP does not mandate a single deployment topology.  Three patterns
     are common; deployments MAY combine them.

     *Pattern 1 -- Inline emission.* The executor that performs the action
     also constructs, signs, and persists the ATP node.  The request node
     is constructed and signed _before_ the action is invoked (its
     inputHash covers the request payload); the completion or failure node
     is constructed and signed _after_ the action returns (its outputHash
     covers the result).  This pattern requires the executor to hold
     issuer key material directly.  It is the lowest-overhead pattern and
     is appropriate when the executor is the natural signing-authority
     boundary.

     *Pattern 2 -- Sidecar emission.* The executor delegates ATP node
     construction and signing to a co-located ATP-emit service.  The
     executor calls the sidecar with action metadata; the sidecar
     canonicalizes, signs, and persists.  This pattern centralizes key
     custody at the sidecar boundary and is appropriate when the executor
     cannot or should not hold private key material directly.

     *Pattern 3 -- Centralized audit service.* A separate service observes
     executor activity (via instrumentation, message-bus subscription, log
     shipping, or an explicit emit API) and constructs ATP nodes on the
     executor's behalf.  In this pattern the _audit service_ is the
     issuer, signing under its own key, and the executor is identified in
     the agent field.  This pattern is appropriate when executors cannot
     be modified to participate in ATP directly.

     Storage MAY be centralized (a shared node store accessible to all
     issuers) or decentralized (each issuer maintains its own store, with
     cross-issuer references resolved via Section 16.3 cross-scope
     mechanisms).  ATP does not prescribe; the choice is operational.
     Implementations SHOULD document which pattern they implement so
     verifiers can correctly interpret the meaning of unresolved parent
     references in the chosen topology (Section 14.5, Section 14.6).

  7.  Data Model

     ATP models agent actions as nodes in a directed acyclic graph.

     A node MAY have zero parents, one parent, or multiple parents:

     *  A node with zero parents is a root node.

     *  A node with one parent expresses a simple causal dependency.




  Bates                   Expires 11 November 2026                [Page 9]


  Internet-Draft                     ATP                          May 2026


     *  A node with multiple parents expresses fan-in, merge, or
        synthesized heritage.

     Multiple child nodes MAY reference the same parent.  ATP therefore
     supports fan-out naturally.

     The following diagram illustrates these structural patterns:

     graph TD
         A["Root Node<br/>(0 parents)"] --> B["Node B<br/>(1 parent)"]
         A --> C["Node C<br/>(1 parent)"]
         B --> D["Node D<br/>(2 parents)"]
         C --> D
         C --> E["Node E<br/>(1 parent)"]

         style A fill:#2E75B6,color:#fff
         style B fill:#4A90D9,color:#fff
         style C fill:#4A90D9,color:#fff
         style D fill:#D94A4A,color:#fff
         style E fill:#4A90D9,color:#fff

     In this diagram:

     *  *Node A* is a root node with zero parents.

     *  *Nodes B and C* demonstrate fan-out: both reference Node A as a
        parent.

     *  *Node D* demonstrates fan-in: it references both Node B and Node C
        as parents, merging two causal lineages.

     *  *Node E* demonstrates a simple linear dependency on Node C.

     ATP does not require total ordering across all nodes in a trust
     domain.  The protocol is designed to preserve causal relationships
     rather than impose a global sequence.  Implementations that require
     ordering MUST provide that behavior outside ATP or as a profile
     layered on top of ATP.

     A valid ATP graph MUST be acyclic.  No node may directly or
     indirectly reference itself through its parent relationships.

  8.  Node Schema

     An ATP node is a structured object containing identity, causality,
     and signature material.  The following fields are defined in the base
     model:




  Bates                   Expires 11 November 2026               [Page 10]


  Internet-Draft                     ATP                          May 2026


     *  *nodeId:* The deterministic identifier of the node.

     *  *timestamp:* The claimed creation time of the node.

     *  *scope:* The boundary within which the node's identity and lineage
        are evaluated.

     *  *issuer:* The signing authority for the node. issuerId identifies
        a signing-authority boundary (see Section 16.6).

     *  *agent:* The execution identity that performed the action.
        agent.version SHOULD change whenever the agent's decision-
        producing configuration changes (see Section 16.5).

     *  *actor:* An OPTIONAL delegating principal on whose behalf the
        action occurred (see Section 16.4).

     *  *action:* A description of the action and references to relevant
        payload hashes.  Depending on node type, one or both of inputHash
        and outputHash MAY be present.

     *  *parents:* An ordered array of zero or more parent node
        identifiers.  Each entry MUST be a nodeId value as defined in
        Section 10.1.  The order of parents is significant for
        canonicalization (Section 9) but has no semantic priority unless a
        profile explicitly defines parent-position semantics.  A parents
        array MUST NOT contain duplicate nodeId values unless a profile
        explicitly defines multiplicity semantics.

     *  *profile:* OPTIONAL.  Identifies the ATP profile (see Section 20)
        whose additional rules apply to this node.  When absent, ATP Core
        rules apply exclusively.

     *  *signature:* The cryptographic signature over the node identifier.

     The base schema is as follows:















  Bates                   Expires 11 November 2026               [Page 11]


  Internet-Draft                     ATP                          May 2026


     {
       "nodeId": "hex(SHA256(canonical_node))",
       "timestamp": "RFC3339",
       "scope": "string",
       "issuer": {
         "issuerId": "string",
         "keyId": "string"
       },
       "agent": {
         "agentId": "string",
         "version": "string"
       },
       "actor": {                  // OPTIONAL -- see below
         "actorId": "string",
         "authContext": "string"
       },
       "action": {
         "type": "string",
         "inputHash": "hex",
         "outputHash": "hex"       // OPTIONAL -- see below
       },
       "parents": ["nodeId"],
       "profile": "string",        // OPTIONAL -- see Section 20.1
       "signature": "base64"
     }

     The example above is illustrative; fields annotated as OPTIONAL MAY
     be omitted as defined in the surrounding prose.  Per Section 9,
     omitted fields do not appear in the canonical form and do not affect
     nodeId computation.

     The actor object is OPTIONAL.  Actor identifies the delegating
     principal whose authority the agent is acting under.  That principal
     MAY be a human, a service account, a scheduled-job identity, or
     another accountable non-human principal.  When no delegating
     principal exists, actor is omitted.  Such omission is meaningful: it
     indicates the action was not taken on behalf of an accountable
     principal.













  Bates                   Expires 11 November 2026               [Page 12]


  Internet-Draft                     ATP                          May 2026


     When actor is omitted, validators MUST NOT treat the omission as
     missing data; the omission is itself a normative claim that no
     delegating principal exists.  Implementations that fail to record an
     actor when one exists are emitter-side governance failures, not
     protocol ambiguities.  Validators have no protocol-level mechanism to
     distinguish accidental omission from autonomous-action omission;
     deployments requiring that distinction MUST address it operationally
     -- for example, through emitter-side governance, profile-defined
     actor-required rules (per Section 20.3 node-worthiness), or out-of-
     band audit policy.  Profiles MAY further constrain when actor MUST be
     present.

     Within the action object, outputHash is OPTIONAL in the base
     protocol.  A node MAY omit outputHash when the action's outcome is
     not yet known at emission time (see Section 16.2 for the request/
     completion pairing pattern).

     The profile field is OPTIONAL.  When present, validators MUST apply
     the validation rules of the identified profile in addition to ATP
     Core rules (see Section 20.1 and Section 20.4).

     All other top-level fields shown above are REQUIRED unless a future
     profile or extension explicitly states otherwise.

     Profiles MAY define additional top-level fields and additional fields
     within the action object as specified in Section 20.3 and
     Section 20.4.  For example, profiles MAY add fields such as
     action.subtype; Appendix A illustrates this pattern.

     A *decisional node* is a node that records a selection, policy
     decision, or synthesis without a direct invocation of an external
     system.  Decisional nodes typically use inputHash to reference the
     material the decision was based on and outputHash to reference the
     decision rationale or output.  The atp:decision action type
     (Section 17.1) is the canonical core action type for decisional
     nodes; Appendix A illustrates decisional-node usage in a multi-issuer
     chain.

     A *relay node* is a node whose action semantics assert that input was
     forwarded without modification.  Relay nodes have unique trust
     semantics that differ from request/completion semantics; full
     treatment is in Section 14.1, with relay-fidelity validation states
     defined in Section 14.2.








  Bates                   Expires 11 November 2026               [Page 13]


  Internet-Draft                     ATP                          May 2026


  9.  Canonicalization

     Canonicalization is REQUIRED for ATP interoperability.  Two
     conforming implementations presented with the same ATP node content
     MUST produce the same canonical byte sequence before hashing.

     ATP implementations MUST canonicalize nodes according to RFC 8785
     JSON Canonicalization Scheme (JCS) [RFC8785].

     Before hashing:

     *  object keys MUST be sorted according to RFC 8785;

     *  UTF-8 encoding MUST be used;

     *  insignificant whitespace MUST NOT be included;

     *  arrays MUST preserve their declared order;

     *  null-valued fields MUST be omitted unless a future ATP profile
        explicitly defines otherwise.

     Because canonicalization is foundational to deterministic identity,
     implementations that do not use RFC 8785 JCS are not conformant with
     this draft.

  10.  Signing and Verification

  10.1.  Node Identity

     The node identifier is computed as:

     nodeId = SHA256(canonical(node_without_signature))

     The signature field itself MUST NOT be included in canonicalization
     or nodeId computation.  The nodeId field, when present in a node
     representation, MUST also NOT be included in its own
     canonicalization.  The nodeId is the _output_ of canonicalization
     plus hashing; its inclusion in the input would be circular.
     Implementations computing or recomputing nodeId over a stored or
     transmitted node MUST first remove both nodeId and signature before
     canonicalization.  Parent references, scope, timestamp, issuer,
     agent, actor (when present), profile (when present), and action
     fields MUST be included.  Profile-defined fields, when present, MUST
     be included as specified in Section 20.4.






  Bates                   Expires 11 November 2026               [Page 14]


  Internet-Draft                     ATP                          May 2026


     ATP Core mandates SHA-256 for nodeId computation.  ATP Core does not
     define a hash-algorithm-agility mechanism.  This is intentional and
     keeps the protocol simple at the cost of forward flexibility; if
     cryptographic developments require a different hash algorithm, that
     capability will be introduced in a future ATP Core revision or
     profile rather than negotiated within this version.

  10.2.  Signature Algorithm

     Implementations conforming to this draft MUST support Ed25519
     [RFC8032].

     Additional algorithms MAY be supported by future ATP profiles, but
     interoperable baseline implementations MUST support Ed25519.  ATP
     Core does not define a signature-algorithm-agility mechanism; the
     same forward-compatibility rationale stated for hash algorithms
     (Section 10.1) applies.

  10.3.  Signature Computation

     The signature is computed over the nodeId:

     signature = Sign(privateKey, nodeId)

     The key used to generate the signature MUST correspond to
     issuer.keyId.

  10.4.  Verification

     A node is *fully lineage-valid* under ATP only if all of the
     following conditions hold:

     1.  The node can be canonicalized successfully.

     2.  The nodeId recomputes exactly from the canonicalized node content
         excluding signature.

     3.  The signature validates against the issuer key identified by
         issuer.keyId.

     4.  All referenced parent nodes can be resolved in the relevant
         verification context.

     5.  All referenced parent nodes are themselves fully lineage-valid
         according to ATP rules.

     6.  No cycle is introduced by the node's parent relationships.




  Bates                   Expires 11 November 2026               [Page 15]


  Internet-Draft                     ATP                          May 2026


     Conditions 1, 2, 3, and 6 together establish *node-level integrity*
     and apply to every validation mode.  Conditions 4 and 5 establish
     *lineage validity* and apply only to validation modes that resolve
     parent nodes (full recursive validation per Section 13.1, and bounded
     validation within its declared boundary per Section 13.2).  Tip
     validation (Section 13.3) intentionally does not resolve parents and
     therefore does not establish lineage validity.

     Validation modes other than full recursive validation MAY produce
     mode-specific validation results as defined in Section 13.  An
     implementation MUST NOT represent the result of tip validation,
     bounded validation, or redacted-lineage validation as full lineage
     validation.

     A node with unresolved, invalid, or withheld parents MUST NOT be
     treated as fully lineage-valid in any verification context.

     Conflict resolution between multiple valid child nodes that reference
     the same parent is out of scope for ATP.

     If a validator cannot retrieve the public key for the (issuerId,
     keyId) pair identified in a node, the node MUST be reported as
     keyUnresolved in the validation result.  A key-unresolved node MUST
     NOT be treated as cryptographically valid, and MUST NOT be classified
     as invalid.  The keyUnresolved state is distinct from: an invalid
     node, whose key is available but whose signature verification fails;
     and an unresolved parent, whose content cannot be obtained in the
     current verification context.

     A keyUnresolved node has not established node-level integrity, even
     when canonicalization succeeds and nodeId recomputes correctly.
     Node-level integrity (conditions 1, 2, 3, and 6 above) requires
     successful signature verification, which is impossible without the
     issuer key.  Implementations MUST NOT report a key-unresolved node in
     the verified set of any validation mode.

     When a parent node is keyUnresolved, the parent's signature cannot be
     verified.  A child node referencing such a parent retains its own
     node-level integrity (assuming conditions 1, 2, 3, and 6 hold for the
     child's own content), but its *lineage validity is not established*
     for as long as the parent remains key-unresolved.  Validators MUST
     report the parent under keyUnresolved and MUST NOT report the child
     as fully lineage-valid in that validation run.  A subsequent re-
     validation that obtains the parent's public key MAY restore lineage
     validity for the child without re-signing the child, since the
     child's signature covers its own nodeId only.





  Bates                   Expires 11 November 2026               [Page 16]


  Internet-Draft                     ATP                          May 2026


  11.  Heritage and DAG Semantics

     Heritage is the complete set of ancestor nodes reachable by
     recursively following parent references from a given node.  Heritage
     establishes the causal lineage of an action.

     ATP heritage has the following properties:

     *  *Transitivity.* If node C references node B as a parent, and node
        B references node A as a parent, then node A is part of node C's
        heritage.

     *  *Tamper evidence.* Because each nodeId is computed from canonical
        content that includes parent references, modifying any ancestor
        invalidates the nodeId of every descendant that references it,
        directly or transitively.

     *  *Non-exclusivity.* A node's heritage may include nodes signed by
        multiple issuers, spanning multiple scopes, and representing
        actions taken by multiple agents.  Heritage is a graph property,
        not an ownership property.

     Heritage traversal is the mechanism by which validators answer causal
     questions: "what caused this action?" is answered by walking parent
     edges; "was this action derived from a specific prior action?" is
     answered by checking whether a given nodeId appears in the heritage
     of the node under inspection.

     ATP does not define a required traversal algorithm.  Implementations
     MAY use depth-first, breadth-first, or other graph-traversal
     strategies.  The protocol requires only that heritage traversal
     follows parent references and that each traversed node is subject to
     the applicable validation mode (see Section 13).

     Because ATP graphs are DAGs, heritage traversal is guaranteed to
     terminate.  The acyclicity constraint (Section 7) ensures that no
     traversal path can loop.

     Fan-in nodes -- nodes with multiple parents -- create heritage that
     merges two or more causal lineages.  This is intentional and
     necessary for representing actions that depend on multiple prior
     results, such as a synthesis that combines a tool execution result
     and a prior selection decision.  Heritage traversal through a fan-in
     node follows all parent edges.







  Bates                   Expires 11 November 2026               [Page 17]


  Internet-Draft                     ATP                          May 2026


  11.1.  Identical Content and Idempotency

     Because nodeId is content-addressed (Section 10.1), two emissions
     that produce identical canonical content will produce identical
     nodeId values.  ATP treats such emissions as the same logical node: a
     verifier that encounters the same nodeId twice MAY deduplicate, and
     storage substrates MAY reject the second write as an idempotent no-
     op.

     Where two distinct emissions are intended to be distinct nodes (for
     example, two retries of the same operation), emitters MUST ensure
     that some canonical field differs.  Practical mechanisms include:

     *  a high-precision timestamp (sub-millisecond) so concurrent
        emissions are distinguishable;

     *  a profile-defined nonce field that participates in
        canonicalization per Section 20.4;

     *  a sequence number embedded in agent.version or another canonical
        field;

     *  distinct inputHash values when the underlying request payloads
        differ.

     Emitters that allow identical canonical content for genuinely-
     distinct actions accept the consequence that those actions collapse
     into a single ATP node.  This is sometimes desirable (the same
     logical event observed twice) and sometimes a correctness bug (two
     retries that should be separately auditable).  Profiles MAY mandate a
     freshness mechanism for emission contexts where collapse is
     unacceptable.

  12.  Scope Model

     Scope is REQUIRED on every ATP node.

     Scope identifies the transaction boundary to which the node belongs.
     In typical deployments, a scope corresponds to one workflow
     execution, one request lifecycle, or one business transaction.  ATP
     does not impose a global meaning beyond that boundary concept.  Scope
     values SHOULD be unique per transaction and SHOULD be shared by all
     nodes that belong to the same transaction; that is, scope is a
     transaction-level identifier, not a node-level identifier.







  Bates                   Expires 11 November 2026               [Page 18]


  Internet-Draft                     ATP                          May 2026


     Scope is an opaque string.  ATP does not define or constrain its
     format.  Implementations MAY use UUIDs, URNs, structured identifiers,
     or other stable values.  Nodes that belong to the same transaction
     boundary SHOULD share the same scope value.

     Each parents entry is a nodeId.  Because nodeId is content-addressed
     and scope is a field inside the referenced node rather than part of
     the parent reference itself, parent references are scope-agnostic by
     definition.

     Parent references MAY target nodes in the same scope or in different
     scopes.  Cross-scope parent references are therefore PERMITTED.

     When a validator resolves a parent node and discovers that the
     parent's scope differs from the current node's scope, that difference
     is not an error condition.  The validator MUST proceed with normal
     ATP verification.  If a parent nodeId can be resolved to content but
     the parent's declared scope differs from the current node's scope
     (including when the parent was obtained through out-of-band
     retrieval), the validator MUST still apply full ATP validation to the
     parent content; scope mismatch alone is not a validation failure.

     A validator operating within a given verification context MUST
     attempt to resolve referenced parent nodes regardless of whether they
     are in the same scope or a different scope.

     If a referenced parent node is obtained and fails ATP verification,
     that parent is *invalid*.

     If a referenced parent node cannot be obtained in the current
     verification context -- including because the validator lacks access
     to the relevant scope, the referenced scope is unavailable, or
     verification is restricted to a single scope -- that parent is
     *unresolved*. The parent is not absent; it is simply not reachable in
     the current verification context.

     Validators MUST distinguish between invalid parents and unresolved
     parents.

     Full lineage verification requires access to all referenced parent
     nodes across all relevant scopes.  Implementations MAY provide
     bounded or partial validation modes (see Section 13), but such modes
     MUST NOT treat unresolved parents as valid.








  Bates                   Expires 11 November 2026               [Page 19]


  Internet-Draft                     ATP                          May 2026


     Scope participates in nodeId computation in the same way as other
     canonical node fields.  Two nodes that are identical except for
     different scope values therefore produce different nodeId values.
     This is intentional: the same action in two different transaction
     contexts is represented as two different ATP nodes.

     Because parent references are made to nodeId values rather than to
     scope membership, cross-scope heritage does not weaken ATP integrity
     semantics.  It does, however, affect what a validator can practically
     resolve and verify in a given environment.

  13.  Validation Modes

     Validation modes are verifier-side behaviors.  ATP nodes are written
     the same way regardless of which validation mode a future verifier
     uses.  Validation modes therefore affect how heritage is read and
     checked, not how nodes are emitted.

     ATP defines four validation modes.

  13.1.  Full Recursive Validation

     In full recursive validation, the validator resolves every parent
     recursively back to every reachable root node within the available
     verification context.  Each traversed node MUST be canonicalized, its
     nodeId MUST be recomputed, its signature MUST be verified, and the
     traversed heritage MUST satisfy ATP DAG constraints, including
     acyclicity.

     This mode provides the strongest lineage claim and is appropriate for
     incident forensics, regulatory audit, and dispute resolution.  Full
     recursive validation is the only mode that establishes full lineage
     validity per Section 10.4.

  13.2.  Bounded Validation

     In bounded validation, the validator declares a verification
     boundary, such as a depth horizon (e.g., "verify this node and 3
     generations of parents") or a time horizon (e.g., "verify back to
     nodes created after timestamp T").  Every node within that declared
     boundary MUST be fully validated according to ATP rules.  Parent
     nodes beyond the declared boundary are not re-verified in that
     validation run and MUST be reported as out-of-horizon.

     This mode is appropriate for operational health checks, real-time
     monitoring, and performance-constrained environments.  Bounded
     validation establishes lineage validity only within its declared
     horizon.



  Bates                   Expires 11 November 2026               [Page 20]


  Internet-Draft                     ATP                          May 2026


  13.3.  Tip Validation

     In tip validation, the validator verifies only the node under
     inspection.  The node MUST be canonicalized, its nodeId MUST be
     recomputed, and its signature MUST be verified.  Declared parent
     references MUST be checked for structural presence, but parent nodes
     are not resolved or verified.

     This mode is appropriate for ingestion-time integrity checks and
     other scenarios where the primary question is whether the node itself
     arrived intact.  Tip validation establishes node-level integrity per
     Section 10.4 but does not establish lineage validity.

  13.4.  Redacted-Lineage Validation

     In redacted-lineage validation, the validator is given a partial
     lineage in which one or more nodes are intentionally withheld for
     confidentiality, access-control, or privacy reasons.  A withheld node
     MAY be represented by nodeId alone.  In this mode, the validator can
     confirm that downstream nodes reference specific parent nodeIds, but
     cannot validate the withheld node's content or signature unless the
     withheld node is later made available.

     Withheld nodes are distinct from unresolved nodes.  A withheld node
     is intentionally omitted but acknowledged.  An unresolved node is one
     that the validator could not obtain in the current verification
     context.

     The distinction between withheld and unresolved is communicated to
     the validator out-of-band: it is the responsibility of the party
     providing the chain (the chain-bundle producer, the API endpoint, the
     audit-export tool, or equivalent) to declare which nodeIds are
     withheld.  ATP Core does not define a normative protocol for this
     declaration; in practice, deployments use an explicit withheldNodeIds
     list in the chain-exchange envelope (Section 16.12), an out-of-band
     agreement between the auditor and the audited party, or a profile-
     defined sentinel in node payloads.  Validators MUST NOT infer
     withheld status from absence alone -- absence is unresolved unless
     explicitly declared withheld.

     This mode is appropriate for cross-organization audits and
     permissioned verification contexts where not all parties have access
     to all nodes.

  13.5.  Minimum Support and Validation Results

     Implementations MUST support tip validation at minimum.




  Bates                   Expires 11 November 2026               [Page 21]


  Internet-Draft                     ATP                          May 2026


     Implementations that claim support for full lineage verification
     (i.e., the full recursive validation mode defined in Section 13.1)
     MUST implement that mode and MUST report results in the format
     defined in Section 13.6.

     Bounded validation and redacted-lineage validation are OPTIONAL.
     When implemented, they MUST clearly report validation depth, out-of-
     horizon nodes, unresolved nodes, and withheld nodes as applicable.

     A validation result MUST include, at minimum:

     *  the validation mode used;

     *  the set of verified nodes;

     *  the set of invalid nodes, if any;

     *  the set of unresolved nodes, if any;

     *  the set of withheld nodes, if any;

     *  the set of out-of-horizon nodes, if any;

     *  the set of key-unresolved nodes, if any; and

     *  the set of profile-unresolved nodes, if any.

     No validation mode may silently suppress unresolved, withheld,
     invalid, out-of-horizon, key-unresolved, or profile-unresolved
     lineage gaps.

  13.6.  Validation Result Format

     Validation results MUST be expressed as a JSON object with the
     following top-level keys:

     {
       "mode": "full",
       "boundary": {},
       "verified": [],
       "invalid": [],
       "unresolved": [],
       "withheld": [],
       "outOfHorizon": [],
       "keyUnresolved": [],
       "profileUnresolved": [],
       "relayFidelity": {}
     }



  Bates                   Expires 11 November 2026               [Page 22]


  Internet-Draft                     ATP                          May 2026


     The fields are defined as follows:

     *  *mode* (string): The validation mode used for this result.  MUST
        be one of "full", "bounded", "tip", or "redacted", corresponding
        to the validation modes defined in Sections 13.1 through 13.4.

     *  *boundary* (object, OPTIONAL): When mode is "bounded", the
        declared verification boundary that was applied (Section 13.2).
        REQUIRED when mode is "bounded" and SHOULD be omitted otherwise.
        The object MUST contain at least one of: "depth" (integer -- the
        parent-generation depth checked) or "sinceTimestamp" (RFC 3339
        string -- the time horizon checked).  Implementations MAY include
        additional implementation-specific boundary descriptors.  The
        boundary object makes bounded-validation results self-describing
        so that operators and downstream auditors know exactly what was
        verified.

     *  *verified* (array of strings): The nodeId hex strings of all nodes
        that passed the validation checks applicable to the selected
        validation mode (Sections 13.1 through 13.4).  Tip validation
        establishes node-level integrity only; full recursive validation
        establishes full lineage validity (see Section 10.4).
        Implementations MUST NOT represent verified entries from non-full
        modes as full lineage validation.

     *  *invalid* (array of strings): The nodeId hex strings of nodes that
        failed ATP validation.  Causes include, but are not limited to,
        canonicalization failure, nodeId mismatch, signature failure,
        acyclicity violation, and strict-mode profile-resolution failure
        as defined in Section 20.4.  Profiles MAY define additional
        invalidity causes; such causes MUST be enumerated in the profile
        specification.

     *  *unresolved* (array of strings): The nodeId hex strings of parent
        nodes that could not be obtained in the current verification
        context.

     *  *withheld* (array of strings): The nodeId hex strings of nodes
        that were intentionally omitted but acknowledged in a redacted-
        lineage context (Section 13.4).

     *  *outOfHorizon* (array of strings): The nodeId hex strings of nodes
        lying outside the declared validation boundary in bounded
        validation (Section 13.2).







  Bates                   Expires 11 November 2026               [Page 23]


  Internet-Draft                     ATP                          May 2026


     *  *keyUnresolved* (array of strings): The nodeId hex strings of
        nodes whose issuer public key could not be retrieved for the
        (issuerId, keyId) pair, preventing signature verification
        (Section 10.4).

     *  *profileUnresolved* (array of strings): The nodeId hex strings of
        nodes whose profile value was not recognized by the validator (per
        Section 20.4).  In permissive mode, a profile-unresolved node MAY
        still pass ATP Core validation and appear in verified; in strict
        mode it is also reported in invalid.  Profile-unresolved nodes are
        always reported in this category so that operators can detect
        interoperability gaps.

     *  *relayFidelity* (object, OPTIONAL): An object keyed by nodeId hex
        string, with values indicating the relay fidelity state of relay
        nodes as defined in Section 14.2.  Permitted values are
        "Verified", "Asserted", and "Contradicted".

     Absent categories MUST be represented as empty arrays, not omitted.
     The relayFidelity object MAY be omitted when no relay nodes are
     present in the validated set.  The boundary object MUST be present
     when mode is "bounded" and SHOULD be omitted in other modes.
     Profiles MAY extend this structure with additional keys.

  13.7.  ATP Core Conformance

     An implementation is *ATP Core conformant* if it satisfies all of the
     following requirements:

     *  canonicalizes nodes according to RFC 8785 JCS as required by
        Section 9;

     *  computes nodeId per Section 10.1, including all required fields
        and any profile field when present;

     *  generates and verifies Ed25519 signatures per Section 10.2 and
        Section 10.3;

     *  enforces acyclicity per Section 7;

     *  implements at least tip validation (Section 13.3);

     *  produces validation results in the format defined by Section 13.6,
        including all required result categories;

     *  distinguishes invalid, unresolved, withheld, out-of-horizon, key-
        unresolved, and profile-unresolved nodes per Section 13.5;




  Bates                   Expires 11 November 2026               [Page 24]


  Internet-Draft                     ATP                          May 2026


     *  treats the atp: action-type prefix as reserved per Section 17.1;

     *  passes all golden test vectors published in [ATP-TEST-VECTORS] for
        canonicalization, nodeId computation, and Ed25519 signature
        verification.

     ATP Core conformance is the floor required for any ATP
     implementation.

     *Profile conformance is always additive.* An implementation that is
     ATP Core conformant MAY additionally claim conformance with one or
     more profiles registered per Section 17.2.  Profile conformance
     requires both ATP Core conformance and satisfaction of all rules
     declared by the relevant profile.  A profile MUST NOT weaken any ATP
     Core conformance requirement (Section 7, Section 10).

     Composite conformance labels (such as ATP-MCP-L1, ATP-MCP-L2, and
     ATP-MCP-L3) are not defined by ATP Core.  Such labels are defined by
     individual profile specifications.

  14.  Security Considerations

     ATP signatures prove that an issuer made a claim about a node.  They
     do not, by themselves, prove that every claim carried in the node is
     true in the external world.

  14.1.  Relay Node Trust Semantics

     A *relay node* is a node whose action semantics assert that input was
     forwarded without modification.  Relay nodes deserve a dedicated
     treatment because they have a unique trust property: the relay
     issuer's signature proves that the issuer _made the non-modification
     claim_, but it does not prove the claim is true.  Other ATP action
     types (atp:request, atp:completion, atp:failure, atp:decision) carry
     claims that are intrinsic to the issuer's own activity (the issuer
     asked, completed, failed, or decided).  Relay nodes are the only ATP-
     Core action type whose claim is _about another party's data_, which
     is why their fidelity must be evaluated separately.  ATP defines
     atp:relay (Section 17.1) as the canonical core action type for relay
     nodes.  A common indicator within atp:relay nodes is inputHash equals
     outputHash.  Profiles MAY define additional relay action types,
     provided their semantics are explicitly declared per Section 20.3.









  Bates                   Expires 11 November 2026               [Page 25]


  Internet-Draft                     ATP                          May 2026


     Profiles that define relay-like action types MUST state how relay
     fidelity is evaluated for those types.  Permitted evaluation methods
     include: payload hash equality (e.g., inputHash equals outputHash),
     direct-origin signature validation, dual-parent lineage (per the
     mitigations in this section), or profile-specific rules.  Profile-
     defined relay types whose fidelity evaluation is not declared MUST be
     treated by validators as equivalent to atp:relay.

     A node whose action semantics imply relay, forwarding, or pass-
     through behavior MUST be understood as an issuer assertion of
     fidelity.  The signature binds the relay issuer to that claim, but
     does not independently prove payload integrity across the relay
     boundary.

     Validators MUST NOT treat a relay node's signature as proof that the
     referenced payload was unmodified.  The signature proves only that
     the relay issuer made a non-modification claim.

     When a downstream node is itself signed by a separate issuer,
     validators SHOULD verify the downstream node's signature directly
     rather than relying solely on the relay node's fidelity claim.

     When the originating node that a relay claims to forward is reachable
     via parent references or other available lineage context, validators
     SHOULD verify the originating node's signature directly.  This is the
     strongest fidelity check available within ATP.

     When the originating node is unreachable, including because it is
     cross-scope, access-restricted, unresolved, or withheld, validators
     SHOULD report relay fidelity as asserted rather than verified.

     Implementations that require strong relay fidelity guarantees SHOULD
     adopt one or more of the following mitigations:

     *  *Direct parent resolution:* The consuming node references the
        originating node (skipping the relay) so that validators can
        verify the original signature directly.

     *  *Dual-parent pattern:* The consuming node references both the
        relay node and the originating node, preserving both the chain-of-
        custody path and a direct verification path.

     *  *Out-of-band payload verification:* The validator independently
        retrieves the payload identified by the relevant hash and
        recomputes integrity outside the ATP graph.






  Bates                   Expires 11 November 2026               [Page 26]


  Internet-Draft                     ATP                          May 2026


     Relay nodes remain valid and useful ATP nodes.  They record that a
     boundary was crossed, who claims to have crossed it, and what
     fidelity assertion was made.  ATP treats relay nodes as
     accountability artifacts, not as automatic proof of non-modification.

     If a relay issuer's fidelity assertion is later shown to be false,
     the signed relay node remains evidence that the issuer made that
     assertion.

  14.2.  Relay Fidelity Validation States

     For relay-node fidelity, validation results SHOULD distinguish at
     least the following states:

     *  *Verified:* The originating node is resolved, signatures validate,
        and the relay claim is consistent with the originating material.

     *  *Asserted:* The relay node is validly signed but the originating
        node was not independently verified.

     *  *Contradicted:* The originating node is resolved and the relay
        claim does not match the originating material.

     These states are specific to relay fidelity semantics and do not
     replace the broader ATP validation result categories defined in
     Section 13.5.

  14.3.  Timestamp Trust

     The timestamp field is a claimed value set by the node emitter.  ATP
     does not define a trusted time source or require synchronized clocks.
     Validators SHOULD treat timestamps as issuer assertions subject to
     the same trust considerations as other node content.

  14.4.  Signature Scope

     An ATP signature covers the nodeId, which is derived from the
     canonical node content.  The signature does not cover the referenced
     payloads themselves -- only their hashes.  Payload integrity depends
     on the hash algorithm and the availability of the original payload
     for recomputation.

  14.5.  Trust Model Summary

     ATP's security guarantees rest on three trust assumptions.  These
     assumptions are stated individually elsewhere in this document and
     are collected here for the benefit of implementers and reviewers.




  Bates                   Expires 11 November 2026               [Page 27]


  Internet-Draft                     ATP                          May 2026


     *  *Issuer key availability.* Verifiers are assumed to be able to
        retrieve issuer public keys for any (issuerId, keyId) pair that
        appears in the chain.  Key discovery is intentionally deferred to
        deployments and future specifications (Section 16.1).  When a key
        is unavailable, the affected node is keyUnresolved rather than
        invalid (Section 10.4).

     *  *Node availability.* Full lineage verification requires that all
        referenced parent nodes be retrievable in the verifier's
        verification context.  ATP does not define a federation or cross-
        scope retrieval protocol (Section 16.3).  Where parent nodes are
        unavailable, the affected nodes are unresolved and lineage
        validity is not established (Section 10.4, Section 13.5).

     *  *Issuer honesty (within signature scope).* ATP signatures prove
        that an issuer made a claim about a node.  They do not prove that
        the claim is true in the external world.  Timestamps
        (Section 14.3), action types, and payload references are all
        issuer assertions subject to operational trust in the issuer.

     These assumptions are deliberate scope choices, not omissions.  ATP
     composes with identity, authorization, transparency, and federation
     mechanisms that strengthen each assumption (Section 14.6,
     Section C.6) without expanding ATP Core.

  14.6.  Suppression and Anti-Suppression

     ATP detects modification but not suppression.  A malicious operator
     who controls a node store MAY withhold individual nodes from a
     verifier.  A verifier observing unresolved parents cannot, on the
     basis of ATP alone, distinguish between (a) nodes that exist
     elsewhere but are unreachable in the current verification context,
     (b) nodes that have been deliberately suppressed, and (c) nodes that
     were never written.

     ATP Core does not provide an anti-suppression mechanism.  This is a
     deliberate scope choice, not an oversight.

     Deployments that require operator-independent assurance against
     suppression SHOULD layer ATP with an append-only transparency service
     such as a SCITT-compatible service [SCITT].  In such a composition:

     *  ATP nodes (or their nodeId values) are published to the
        transparency service as signed statements;

     *  the transparency service provides operator-independent evidence
        that the node existed at a given time and was not retroactively
        suppressed;



  Bates                   Expires 11 November 2026               [Page 28]


  Internet-Draft                     ATP                          May 2026


     *  ATP retains its causal-DAG and lineage-validity semantics over the
        underlying chain.

     Profiles MAY define normative SCITT-compatible or equivalent
     publication patterns.  ATP Core does not require such layering, but
     the protocol is designed to compose with it (see Section C.6 for
     further discussion of the SCITT relationship).

  14.7.  Replay and Scope Binding

     Because scope participates in canonicalization (Section 9,
     Section 12), a node's nodeId is bound to its declared scope.  A
     literal replay of a signed node into a different scope produces a
     different recomputed nodeId; the original signature does not validate
     against that different nodeId.  Replay across scopes is therefore
     not, by itself, a node-integrity attack.

     However, a malicious party who obtains a signed node MAY present that
     node in a different verification context where its declared scope
     value happens to be permitted or expected.  Validators MUST evaluate
     scope semantics within their verification context and MUST NOT accept
     a node as evidence of an action in a verification context whose scope
     semantics do not match the scope value declared by the node.

     ATP Core does not define an anti-replay mechanism beyond scope
     binding.  Deployments requiring stronger anti-replay protection (for
     example, freshness guarantees against same-scope replays after a long
     interval) SHOULD layer additional context-binding outside the
     protocol -- for example, transport-layer freshness tokens, audited
     delivery channels, or profile-defined nonce fields participating in
     canonicalization per Section 20.4.

  15.  Privacy Considerations

     ATP nodes carry metadata about actions, identities, and causal
     relationships.  Even when payload content is stored externally and
     referenced only by hash, the existence of a node in an ATP chain
     reveals that an action was taken, by which agent, on behalf of which
     actor (when present), and in what causal relationship to other
     actions.

  15.1.  Data Minimization

     ATP's design supports data minimization by carrying hashes rather
     than full payloads.  However, the metadata fields themselves --
     including actorId, agentId, issuerId, and action.type -- may
     constitute personal data or sensitive operational data depending on
     the deployment context and applicable jurisdiction.



  Bates                   Expires 11 November 2026               [Page 29]


  Internet-Draft                     ATP                          May 2026


     Implementations SHOULD evaluate whether node metadata requires
     protection under applicable privacy regulations and SHOULD apply
     access controls to ATP node storage and retrieval accordingly.

  15.2.  Deletion and Retention Tension

     ATP's tamper-evident properties create a tension with data subject
     rights such as the right to erasure under GDPR and similar
     regulations.

     Payloads referenced by inputHash and outputHash are stored outside
     the ATP chain and MAY be deleted independently without invalidating
     the chain's structural integrity.  The hash references will remain,
     but the referenced content will no longer be retrievable.

     Node metadata within the chain -- including actorId, agentId,
     timestamps, and causal relationships -- cannot be removed without
     invalidating the node's signature and the nodeId references of all
     descendant nodes.

     Implementations that must accommodate deletion rights SHOULD consider
     the following approaches:

     *  Store personal data exclusively in external payloads referenced by
        hash, not in node metadata fields.

     *  Use pseudonymous or indirect identifiers in actorId that can be
        dereferenced through a separate, deletable mapping.

     *  Apply redacted-lineage validation (Section 13.4) so that nodes
        containing personal data can be withheld from verification
        contexts when required.

     ATP does not define a normative deletion or redaction mechanism.  The
     tension between immutable audit evidence and deletion rights is an
     operational and legal concern that deployments must address in the
     context of their applicable regulatory requirements.

  15.3.  Chain Existence as Metadata

     Even when all payload content and personal identifiers are removed or
     pseudonymized, the existence of an ATP chain itself -- including its
     structure, depth, timing, and issuer distribution -- may reveal
     operationally sensitive information.  Implementations SHOULD apply
     appropriate access controls to chain metadata, not only to payload
     content.





  Bates                   Expires 11 November 2026               [Page 30]


  Internet-Draft                     ATP                          May 2026


  15.4.  Pseudonymous Identifiers and Post-Deletion Verification

     Implementations SHOULD use pseudonymous or indirect identifiers in
     actorId rather than directly identifying personal data.  A separate
     identity-resolution service SHOULD manage the mapping between
     pseudonymous identifiers and real identities.

     When a data subject exercises a right to erasure, the RECOMMENDED
     approach is to delete the identity-resolution mapping and any
     external payloads containing personal data.  The ATP chain itself is
     not modified.

     After identity-resolution deletion, the actorId value remains in the
     chain but can no longer be resolved to a natural person.  The chain's
     structural integrity, signatures, and causal relationships are
     unaffected.

     Implementations MUST NOT rely on actorId opacity alone as a privacy
     control.  If the actorId value itself is directly identifying -- for
     example an email address or employee number -- deletion of the
     mapping service does not remove the personal data from the chain.
     Pseudonymous identifiers are therefore RECOMMENDED as the default.

     Following deletion of identity mappings or external payloads,
     validators SHOULD use redacted-lineage validation as described in
     Section 13.4 when verifying historical chains that include now-
     unresolvable or now-withheld elements.

     Deployments subject to data protection regulations SHOULD document
     their ATP data retention and deletion procedures as part of their
     privacy impact assessment.

  16.  Operational Considerations

  16.1.  Key Lifecycle

     ATP does not define a key management protocol, key discovery
     mechanism, or trust registry.  However, ATP deployments depend on
     durable issuer key practices in order for signed nodes to remain
     verifiable over time.

     Each issuer controls its own key material.  No issuer is expected to
     hold another issuer's private key.  Private key storage is
     implementation-specific and MAY use HSMs, cloud KMS systems, local
     keystores, or other suitable mechanisms.  The operational requirement
     is that the private key associated with a given issuer.keyId can
     generate ATP-conformant Ed25519 signatures, and that validators can
     obtain the corresponding public key for verification.



  Bates                   Expires 11 November 2026               [Page 31]


  Internet-Draft                     ATP                          May 2026


     An issuer MAY rotate signing keys at any time by beginning to sign
     new nodes with a new keyId.

     Previously signed nodes remain valid after rotation.  A node
     continues to identify the key that was active when it was signed
     through its issuer.keyId value.

     An issuer MUST maintain the ability to provide the public key for any
     keyId that appears in its signed nodes for as long as those nodes may
     need to be verified.

     ATP Core does not define a public key discovery mechanism or a
     normative well-known URI path for key publication.  Implementations
     MAY use well-known URIs, JWK sets, append-only key logs, out-of-band
     registries, or other equivalent mechanisms that allow a validator to
     retrieve the public key for a given (issuerId, keyId) pair.  A future
     ATP specification or profile MAY define a normative key-discovery
     path; this document does not.

     This deferral creates a practical interoperability consequence: until
     a normative key-discovery path exists, two implementations that wish
     to cross-verify each other's chains MUST agree on a key-retrieval
     mechanism out-of-band.  Cross-organization verification is therefore
     fragmented at the discovery layer even though node integrity,
     identity computation, and signature verification are deterministic.
     Profiles requiring open cross-organization verifiability SHOULD
     define a key-publication mechanism (for example, a JWK set served at
     a profile-specified well-known URI) and SHOULD declare it as a
     profile conformance requirement.

     Key retirement does not invalidate previously signed nodes.  The
     nodeId and signature remain correct; only the deployment's ability to
     verify those nodes depends on continued public key availability.

     Implementations SHOULD plan for indefinite retention of public keys
     for any keyId that has been used in production signing.

     Deployments are RECOMMENDED to publish or otherwise maintain an
     append-only public key record per issuer so that historical keyIds
     remain resolvable even after active signing use has ended.

  16.2.  Request/Completion Pairing

     ATP does not require a single emission timing model for all action
     types.  However, when implementations require auditable evidence of
     attempted, in-progress, completed, or failed actions, a paired
     request/completion pattern is RECOMMENDED.




  Bates                   Expires 11 November 2026               [Page 32]


  Internet-Draft                     ATP                          May 2026


     In this pattern, a *request node* (typically atp:request, see
     Section 17.1) records intent.  The request node carries inputHash
     covering the request payload. outputHash is omitted (not zeroed or
     set to a placeholder -- absent).  Per Section 9, null-valued fields
     are omitted during canonicalization, so this is consistent with
     deterministic identity computation.

     A *completion node* (typically atp:completion, see Section 17.1)
     records outcome.  The completion node references the request node as
     a parent.  The completion node SHOULD carry an inputHash matching the
     request node's inputHash so that validators can determine that both
     nodes describe the same logical action.  The completion node carries
     outputHash covering the response or result payload.

     A *failure* is also represented as a completion node, typically using
     atp:failure (Section 17.1).  The relevant action.type SHOULD indicate
     failure semantics, and outputHash SHOULD cover any resulting error
     payload.

     ATP does not mandate that profiles use the core atp:request,
     atp:completion, and atp:failure types directly.  Profiles MAY define
     more specific action types that follow the same emission semantics,
     provided the profile specification declares the mapping (per
     Section 20.3).

     If an emitter crashes or otherwise fails between request-node
     emission and completion-node emission, the unpaired request node
     remains a valid ATP node.  Validators and operational tooling SHOULD
     report unpaired request nodes as open or incomplete rather than
     invalid.  This behavior is intentional and provides crash-recovery
     and interrupted-action visibility.

  16.3.  Cross-Scope Resolution

     Cross-scope parent verification is an operational capability, not a
     separate ATP protocol.  Implementations that expect validators to
     verify nodes across scope boundaries SHOULD ensure that validators
     can retrieve referenced nodes across those boundaries.

     This MAY be achieved through a shared node store, an API-based
     retrieval mechanism, or another exchange mechanism.  ATP does not
     define a federation protocol or a required topology for cross-scope
     node access.








  Bates                   Expires 11 November 2026               [Page 33]


  Internet-Draft                     ATP                          May 2026


  16.4.  Actor Mapping Guidance

     In governed deployments, actor omission SHOULD be uncommon.  Most ATP
     nodes ought to identify the principal whose authority the agent is
     acting under.

     actor represents the delegating principal.  That principal MAY be
     human or non-human.

     When a human initiates an action, actorId SHOULD identify the human
     principal and authContext SHOULD identify the authentication
     mechanism, such as SAML or OIDC.

     When a machine-originated chain has no human initiator, actorId
     SHOULD identify the accountable service principal -- the service
     account, scheduled-job identity, CI/CD pipeline identity, managed
     identity, or equivalent non-human principal. authContext SHOULD
     identify the credential or trust mechanism used, such as workload
     identity, managed identity, service account, or API key.

     When there is genuinely no delegating principal and the agent is
     acting autonomously, actor MAY be omitted.  Such omission is a
     meaningful signal: it indicates the action was not taken on behalf of
     an accountable principal.  Implementations SHOULD treat frequent
     actor omission as a governance concern rather than as routine
     behavior.  See Section 8 for the corresponding verifier rule on
     omission.

  16.5.  Agent Versioning Guidance

     ATP does not mandate a versioning scheme for agent.version.
     Implementations MAY use semantic versions, date-based versions,
     commit hashes, or other distinguishable version identifiers.

     However, agent.version SHOULD change whenever the agent's decision-
     producing configuration changes.  The governing test is
     *configurational*, not run-time behavioral: if the _configuration_
     that produces outputs changes such that the agent could produce a
     different output for the same input, the version SHOULD change.  Run-
     time output variance that is intrinsic to the agent's design -- for
     example, a sampling LLM with no fixed seed producing different
     completions for identical prompts -- does NOT require a version bump
     on every emission.  The version tracks the agent the way a software
     version tracks a binary: it changes when the binary changes, not when
     the binary processes different inputs.

     Changes that SHOULD trigger a new agent.version include, but are not
     limited to:



  Bates                   Expires 11 November 2026               [Page 34]


  Internet-Draft                     ATP                          May 2026


     *  a software code change that alters decision logic (a refactor, a
        routing-rule change, a control-flow modification);

     *  a model swap (for AI agents);

     *  a prompt, template, or few-shot example change (for AI agents);

     *  a tool-scope change that affects what tools the agent can select
        or invoke;

     *  a policy-bundle, guardrail, or business-rule change that affects
        output behavior; and

     *  a configuration change that affects output behavior, such as
        sampling parameters, retrieval settings, scoring weights, or
        generation parameters.

     Changes that ordinarily SHOULD NOT trigger a new agent.version
     include infrastructure-only changes that do not affect decision
     behavior, such as scaling changes, region failover, key rotation,
     logging changes, observability changes, or transport/protocol
     upgrades that do not alter the agent's decision logic.  Run-time non-
     determinism (sampling, random-seed-based variation, time-of-day-
     dependent behavior) likewise does NOT trigger a version bump unless
     the _configuration_ of that non-determinism changes.

     ATP cannot enforce correct version bumps at the protocol level.  If
     an implementation changes agent behavior without changing
     agent.version, that is an implementation governance failure rather
     than a protocol ambiguity.

  16.6.  Issuer Identity Granularity

     ATP does not prescribe a required granularity for issuerId. issuerId
     identifies a signing-authority boundary: the entity that controls the
     private key material and is accountable for the nodes it signs.  That
     boundary MAY align with a tenant, a deployment, a region, a service,
     or another organizational unit.

     The governing principle is key custody.  Nodes signed under the same
     issuerId share the same key-custody boundary.  If two systems have
     independent key custody -- for example, different key storage,
     different rotation policies, or different operational teams -- they
     SHOULD use different issuerId values.

     Conversely, systems that share key custody MAY share an issuerId.





  Bates                   Expires 11 November 2026               [Page 35]


  Internet-Draft                     ATP                          May 2026


     Implementations SHOULD choose issuerId granularity such that
     compromise of one issuer's key material does not implicate nodes
     signed by a different issuer.  This is the primary security
     constraint on issuerId design.

     The combination of issuerId and keyId MUST be unique within the
     relevant verification context.  Two different issuers MUST NOT share
     a keyId value that maps to different keys within that context.

     ATP does not mandate whether issuerId maps to tenants, deployments,
     services, or regions.  This is an operational design decision.  An
     enterprise with centralized key custody MAY use one issuerId across
     multiple agents or services.  A deployment with per-tenant or per-
     environment key isolation SHOULD use distinct issuerId values that
     reflect those custody boundaries.

  16.7.  Storage Model Guidance

     ATP does not mandate a storage substrate.  Implementations MAY use
     append-only logs, content-addressed object stores, relational
     databases, or other storage systems.

     In practice, three storage patterns are common:

     *Pattern A -- Append-only event log.* Nodes are written sequentially
     to a log.  Parent resolution is performed by index lookup or by a
     secondary index on nodeId.  This pattern integrates naturally with
     event-sourced architectures and operational monitoring systems, but
     parent resolution across large graphs depends on effective indexing.

     *Pattern B -- Content-addressed object store.* Nodes are stored keyed
     by nodeId.  Because nodeId is derived from canonical node content,
     this pattern aligns closely with ATP's deterministic identity model
     and supports direct parent lookup by nodeId.  However, temporal
     ordering and operational queryability may require additional
     indexing.

     *Pattern C -- Hybrid.* Nodes are written to an append-only log for
     temporal ordering and operational queries, and are also indexed or
     stored by nodeId for efficient parent resolution.  This pattern
     supports both operational visibility and efficient heritage traversal
     at the cost of greater implementation complexity.

     Regardless of storage choice, implementations MUST ensure that a node
     can be retrieved by nodeId with sufficient performance to support the
     validation modes the deployment intends to offer.





  Bates                   Expires 11 November 2026               [Page 36]


  Internet-Draft                     ATP                          May 2026


     Implementations that support full recursive validation (Section 13.1)
     SHOULD ensure that parent resolution by nodeId remains efficient at
     scale, since recursive validation traverses the full heritage graph.

     Implementations MUST ensure that stored nodes are immutable once
     written.  Mutation of a stored node invalidates its nodeId, breaks
     downstream parent references, and defeats ATP's tamper-evidence
     guarantees for any verifier that does not retain the original bytes.
     Implementations MAY enforce immutability through storage-engine
     constraints -- for example, write-once tables, content-addressed
     object stores, append-only logs, or BEFORE UPDATE triggers that
     reject row modifications.

     Storage-layer integrity checks, such as recomputing nodeId from
     stored content as an operational health measure, are RECOMMENDED.
     However, such checks are not a substitute for ATP validation.

  16.8.  Permissioned Verifiability

     ATP does not define an access-control model for node retrieval.
     Access control over who may retrieve and verify which nodes is an
     implementation and deployment concern.

     In practice, ATP deployments often serve multiple verification
     audiences with different access rights.

     *Tier 1 -- Full-chain verification.* A verifier with unrestricted
     access to all relevant nodes and scopes can perform full recursive
     validation as defined in Section 13.1.

     *Tier 2 -- Scoped verification.* A verifier with access limited to
     particular scopes, issuers, time ranges, or other node attributes
     validates the nodes available in that verification context.  Parents
     outside that boundary are reported as unresolved or out-of-horizon
     according to the applicable validation mode.

     *Tier 3 -- Redacted verification.* A verifier is given a partial
     chain in which sensitive nodes are withheld and represented only by
     nodeId or by withheld-node placeholders consistent with Section 13.4.
     The verifier can validate visible nodes, confirm visible chain
     structure, and transparently report withheld nodes.

     Implementations that serve multiple verification audiences SHOULD
     provide mechanisms to scope node access by verification context --
     for example, by scope, by issuer, by time range, or by other node
     attributes.





  Bates                   Expires 11 November 2026               [Page 37]


  Internet-Draft                     ATP                          May 2026


     When a verification context restricts the nodes available to a
     verifier, the verifier MUST use the appropriate validation mode and
     MUST report any nodes that are unresolved, withheld, or out-of-
     horizon in the validation result.

     Implementations MAY offer a *hash-only verification path* in which a
     verifier is given only nodeId values and parent references without
     full node content.  This allows the verifier to confirm chain
     structure and determine whether one node descends from another
     without access to the metadata of intermediate nodes.

     ATP does not define a protocol for permissioned export, redacted-
     chain generation, or verifier authorization.  Those mechanisms remain
     implementation-specific.

  16.9.  Deletion and Redaction Operations

     ATP does not define a deletion protocol, a redaction protocol, or an
     identity-resolution service.  Those mechanisms remain implementation-
     specific.

     In practice, deployments can reduce privacy tension through three
     operational layers:

     *Layer 1 -- Keep personal data out of node metadata.* Deployments
     SHOULD prefer pseudonymous identifiers in actorId and SHOULD avoid
     embedding directly identifying personal data in actorId, agentId,
     issuerId, or action.type.

     *Layer 2 -- Delete external payloads freely.* Payloads referenced by
     inputHash and outputHash may be deleted independently of the ATP
     chain without breaking ATP structural integrity.

     *Layer 3 -- Verify post-deletion chains using the appropriate
     validation mode.* After identity-resolution deletion or payload
     deletion, validators SHOULD use redacted-lineage validation or
     another appropriate restricted verification mode so that withheld or
     now-unresolvable content is reported transparently rather than
     treated as invalid.

     These operational practices do not eliminate the legal or governance
     tension between immutable evidence and deletion rights, but they make
     privacy-preserving ATP deployments practical without modifying the
     core protocol.







  Bates                   Expires 11 November 2026               [Page 38]


  Internet-Draft                     ATP                          May 2026


  16.10.  Performance Budget Guidance

     ATP does not define benchmark requirements.  Performance depends on
     implementation language, hardware, storage design, graph shape, and
     validation mode.  However, deployments SHOULD understand four
     distinct ATP cost centers.

     *Cost 1 -- Canonicalization.* Canonicalization cost scales primarily
     with node count rather than with node complexity because ATP nodes
     are structurally small and regular.  For most deployments,
     canonicalization is not the dominant validation cost.

     *Cost 2 -- Signing and signature verification.* Ed25519 signing and
     verification are computationally lightweight for individual nodes.
     In bulk validation scenarios, signature verification cost becomes
     measurable but remains parallelizable because each node's signature
     is independent.

     *Cost 3 -- Parent resolution.* The dominant performance cost in ATP
     validation is usually parent resolution: retrieving referenced nodes
     by nodeId.  Implementations SHOULD optimize node retrieval by nodeId
     as a primary access pattern.

     *Cost 4 -- Lineage traversal.* Full recursive validation traverses
     the entire heritage graph and therefore scales linearly with the
     number of reachable nodes in that heritage.  Bounded validation caps
     traversal according to the declared horizon.  Tip validation avoids
     heritage traversal entirely.

     Implementations that support full recursive validation (Section 13.1)
     SHOULD ensure that parent resolution by nodeId remains efficient at
     scale, since recursive validation traverses the full heritage graph.

     Implementations that serve latency-sensitive validation requests
     SHOULD consider bounded validation (Section 13.2) or tip validation
     (Section 13.3) for operational use cases, reserving full recursive
     validation for audit and forensic contexts.

     Implementations SHOULD monitor and report heritage depth and
     branching factor for production scopes.  Unusually deep or wide
     graphs may indicate emitting-system design issues, excessive
     delegation, or insufficient scope partitioning.

     Caching of previously validated subtrees is permitted and RECOMMENDED
     for deployments that perform repeated validation of overlapping
     heritage.  Cached validation results MUST be invalidated if the
     validator's trust in any issuer key changes, for example because of
     key compromise, key replacement, or revocation-related policy change.



  Bates                   Expires 11 November 2026               [Page 39]


  Internet-Draft                     ATP                          May 2026


  16.11.  Node Granularity Guidance

     ATP Core does not normatively prescribe what events MUST or MUST NOT
     produce ATP nodes -- that is profile responsibility (Section 20.3).
     However, deployments and profile authors benefit from a shared
     default.  The governing principle is: *an ATP node represents an
     action that warrants independent audit*, not every internal
     computation step.

     The following non-normative heuristics describe the typical default:

     *Node-worthy events* (typically emitted as ATP nodes):

     *  External tool invocations and their completions (cross-process,
        cross-service, or cross-organization calls).

     *  Cross-agent dispatches (one agent handing work to another).

     *  Cross-issuer payload forwarding events (relay nodes).

     *  Decisions that materially affect downstream outcomes (tool
        selection, routing decisions, synthesis from multiple inputs).

     *  Workflow or transaction boundaries (root nodes for new
        transactions; completion nodes for terminating transactions).

     *Not node-worthy events* (typically NOT emitted as ATP nodes):

     *  Internal control flow within a single agent's reasoning (if/else
        branches, loops, exception handlers).

     *  Lookups of environment variables, configuration values, or static
        reference data.

     *  Per-token model output during generation (token-streaming chunks).

     *  Pre-emission canonicalization, signing, or storage operations of
        the ATP layer itself.

     *  Health-check pings, heartbeats, or other liveness traffic.











  Bates                   Expires 11 November 2026               [Page 40]


  Internet-Draft                     ATP                          May 2026


     The boundary between node-worthy and not-node-worthy is *whether the
     event crosses a trust boundary or affects auditability*. An internal
     if statement in an agent's code is not node-worthy; a decision that
     selects between two external tools, paid services, or downstream
     agents is.  A configuration lookup is not node-worthy; a
     configuration _change_ that could alter the agent's behavior is
     reflected in agent.version (Section 16.5), not in a separate
     emission.

     Profiles MAY normatively constrain these defaults.  For example, a
     high-assurance profile MAY require explicit decisional nodes for any
     output that affects regulatory reporting; a low-assurance profile MAY
     suppress decisional nodes entirely and emit only request/completion
     pairs.  Profiles SHOULD justify their granularity rules with
     reference to the audit posture they target.

  16.12.  Chain Exchange Patterns

     ATP does not define a transport protocol for chain exchange.
     However, deployments that share chains across organizational or
     system boundaries benefit from common patterns.

     Three patterns are common:

     *Pattern X -- Bundle export.* The producer assembles a JSON envelope
     containing an array of signed nodes plus a list of withheldNodeIds
     (where applicable) and provides it to the consumer as a single
     artifact.  A typical bundle structure:

     {
       "atpVersion": "11",
       "nodes": [ /* array of signed ATP nodes */ ],
       "withheldNodeIds": [ /* array of nodeId hex strings -- see Section 13.4 */ ],
       "scopes": [ /* OPTIONAL -- array of scope values represented in this bundle */ ]
     }

     The consumer iterates nodes, validates each per the appropriate
     validation mode (Section 13), and treats any parent reference that
     resolves only to a withheldNodeIds entry as withheld rather than
     unresolved.

     *Pattern Y -- Pull by nodeId.* The producer exposes a content-
     addressed retrieval API (GET /atp/nodes/{nodeId}) returning the
     signed node by its identifier.  The consumer walks parent references,
     resolving each via the API.  This pattern is appropriate when the
     consumer's traversal pattern is unpredictable or when chains are very
     large.




  Bates                   Expires 11 November 2026               [Page 41]


  Internet-Draft                     ATP                          May 2026


     *Pattern Z -- Push to log.* Each issuer emits signed nodes to a
     shared append-only log (a transparency service per Section C.6, an
     event bus, or a centralized audit store).  Consumers subscribe or
     query the log.  This pattern is appropriate when multiple consumers
     need access to the same chains or when anti-suppression guarantees
     (Section 14.6) are required.

     Bundle exports SHOULD include enough context for the consumer to
     perform the validation mode they require: a bundle intended for full-
     recursive validation MUST include all heritage; a bundle intended for
     tip validation MAY include only the tip nodes.  ATP Core does not
     define a normative bundle schema; profiles MAY do so.

  17.  IANA Considerations

     This document requests the following IANA actions.

  17.1.  ATP Action Types Registry

     IANA is requested to create a new registry titled "ATP Action Types"
     under a new "Agent Transaction Protocol (ATP)" registry group.  The
     registration policy for this registry is Specification Required
     [RFC8126].

     Each entry in the registry MUST include the following fields:

     *  *Type Value:* The action type string.

     *  *Description:* A short description of the action type's semantics.

     *  *Reference:* A pointer to the specification that defines the type.

     *  *Status:* One of active, deprecated, or obsolete. active indicates
        the type is currently recommended; deprecated indicates the type
        SHOULD NOT be used in new emissions; obsolete indicates the type
        is retained for historical lookup only and MUST NOT be used in new
        emissions.

     The atp: prefix is reserved for this registry.  Action types defined
     by ATP profiles MAY register under the atp: prefix following the
     Specification Required policy above.  Action types that are not
     registered MUST NOT use the atp: prefix.

     The following initial values are registered by this document, all
     with Status active:






  Bates                   Expires 11 November 2026               [Page 42]


  Internet-Draft                     ATP                          May 2026


     +================+========================+================+========+
     | Type Value     | Description            | Reference      | Status |
     +================+========================+================+========+
     | atp:request    | Represents the         | This document, | active |
     |                | initiation of an       | Section 16.2   |        |
     |                | action, recording      |                |        |
     |                | intent and input       |                |        |
     |                | material. outputHash   |                |        |
     |                | is typically absent.   |                |        |
     +----------------+------------------------+----------------+--------+
     | atp:completion | Represents the         | This document, | active |
     |                | successful completion  | Section 16.2   |        |
     |                | of an action           |                |        |
     |                | initiated by a         |                |        |
     |                | corresponding request  |                |        |
     |                | node. outputHash       |                |        |
     |                | covers the result      |                |        |
     |                | payload.               |                |        |
     +----------------+------------------------+----------------+--------+
     | atp:failure    | Represents the         | This document, | active |
     |                | failure outcome of an  | Section 16.2   |        |
     |                | action initiated by a  |                |        |
     |                | corresponding request  |                |        |
     |                | node. outputHash       |                |        |
     |                | SHOULD cover any       |                |        |
     |                | error payload.         |                |        |
     +----------------+------------------------+----------------+--------+
     | atp:relay      | Represents a           | This document, | active |
     |                | boundary-crossing      | Section 14.1   |        |
     |                | relay event in which   |                |        |
     |                | the emitting issuer    |                |        |
     |                | asserts that input     |                |        |
     |                | was forwarded without  |                |        |
     |                | modification.          |                |        |
     |                | inputHash SHOULD       |                |        |
     |                | equal outputHash.      |                |        |
     +----------------+------------------------+----------------+--------+
     | atp:decision   | Represents a           | This document, | active |
     |                | decisional node        | Section 8      |        |
     |                | recording a            | (decisional    |        |
     |                | selection, policy      | node           |        |
     |                | decision, or           | definition)    |        |
     |                | synthesis without      | and Appendix A |        |
     |                | direct invocation of   | (worked        |        |
     |                | an external system.    | example)       |        |
     +----------------+------------------------+----------------+--------+

                                    Table 1



  Bates                   Expires 11 November 2026               [Page 43]


  Internet-Draft                     ATP                          May 2026


     Future ATP profile documents MAY request additional action type
     registrations following the Specification Required registration
     policy above.  A registered action type MAY be transitioned to
     deprecated or obsolete Status by a subsequent specification
     registered under the same policy; transitions MUST cite the prior
     registration.

     The five initial action types are registered in Core because they
     represent cross-system patterns whose vocabulary alignment is more
     valuable than minimalism.  Implementations MAY use only a subset.  In
     particular, profiles or deployments that have no need for explicit
     relay or decisional emission MAY model those concepts using
     atp:request + atp:completion pairs and never emit atp:relay or
     atp:decision nodes.  Conversely, deployments that DO emit relay or
     decisional nodes benefit from registered vocabulary so that cross-
     system validators can interpret them uniformly.  Registration of
     these types in Core does not imply any deployment must use them.

  17.2.  ATP Profiles Registry

     IANA is requested to create a new registry titled "ATP Profiles"
     under the "Agent Transaction Protocol (ATP)" registry group.  The
     registration policy for this registry is Specification Required
     [RFC8126].

     Each entry in the registry MUST include the following fields:

     *  *Profile Identifier:* The full URN of the form
        urn:ietf:params:atp:profile:{name}:{version} (see Section 20.1).

     *  *Profile Name:* The short profile name component.

     *  *Version:* The semantic version of the profile (see Section 20.2).

     *  *Description:* A short description of the profile's scope and
        purpose.

     *  *Reference:* A pointer to the specification that defines the
        profile.

     *  *Status:* One of active, deprecated, or obsolete.

     This document does not register any initial profile entries.  Initial
     profile entries are expected to be registered by separate profile
     specifications, including [ATP-PROFILES].






  Bates                   Expires 11 November 2026               [Page 44]


  Internet-Draft                     ATP                          May 2026


  17.3.  URN Sub-Namespace Registration

     IANA is requested to register the URN sub-namespace atp under
     urn:ietf:params per [RFC3553].

     *  *Registry name:* Agent Transaction Protocol (ATP) Parameters

     *  *URN format:* urn:ietf:params:atp:{class}:{name}:{version} where
        {class} is one of the registered ATP parameter classes (initially
        profile), {name} is the parameter name, and {version} is the
        parameter version.

     *  *Registration policy:* Sub-classes within urn:ietf:params:atp: are
        added by IETF Consensus or by a registry policy declared in a
        subsequent ATP specification.

     *  *Reference:* This document, Section 17.2 and Section 20.1.

     This document does not request the registration of a well-known URI
     for ATP key publication.  A future ATP specification or profile MAY
     define a normative key-discovery path and request the corresponding
     well-known URI registration; this document explicitly defers that
     work.

  18.  Implementation Status

     This section is to be removed before publication as an RFC, in
     accordance with [RFC7942].

     At the time of this draft, ATP is at the design and prototype stage.
     No production deployments are reported.  A zero-dependency Node.js
     reference implementation accompanying this draft passes all golden
     vectors published in [ATP-TEST-VECTORS] for canonicalization
     (Section 9), nodeId computation (Section 10.1), Ed25519 signature
     generation and verification (Section 10.2 and Section 10.3), and tip-
     validation node-level integrity (Section 10.4 / Section 13.3).

     A reference implementation intended to demonstrate interoperability
     SHOULD publish golden test vectors covering, at minimum:

     *  canonicalization per RFC 8785 JCS (Section 9), including the
        inclusion of the profile field when present;

     *  nodeId computation (Section 10.1);

     *  Ed25519 signature generation and verification (Section 10.2 and
        Section 10.3);




  Bates                   Expires 11 November 2026               [Page 45]


  Internet-Draft                     ATP                          May 2026


     *  each validation mode defined in Sections 13.1 through 13.4;

     *  the validation result format (Section 13.6), including
        representation of all required result categories;

     *  profile-field canonicalization behavior under both strict and
        permissive validator modes (Section 20.4);

     *  handling of invalid, unresolved, withheld, out-of-horizon, key-
        unresolved, and profile-unresolved parents.

     The companion Internet-Draft [ATP-TEST-VECTORS] provides an initial
     set of golden vectors aligned with the requirements above.
     Implementations claiming ATP Core conformance per Section 13.7 MUST
     pass all vectors in [ATP-TEST-VECTORS] for canonicalization, nodeId
     computation, and Ed25519 signature verification.

     Authors and implementers wishing to report implementation status,
     interoperability results, or production usage are invited to contact
     the document author identified in the Author's Address section.

  19.  Profile Framework

     An ATP *profile* is a normative specification that extends or
     constrains ATP Core for a specific deployment context, domain, or
     interoperability scope.  Profiles MAY define additional action.type
     values, additional node schema fields, more restrictive validation
     rules, null-field inclusion rules (per Section 9), relay type
     declarations (per Section 14.1), and completion-pairing semantics
     (per Section 16.2).  Full profile governance, including the
     specification template, registration procedures, and composite
     conformance labels, is defined by individual profile specifications
     and by the companion document [ATP-PROFILES].  This document defines
     the ATP Profile Framework: the rules that any profile MUST satisfy in
     order to be ATP-conformant.

  19.1.  Profile Identifiers

     A profile is identified by a string value carried in an OPTIONAL
     profile field on ATP nodes (see Section 8).  When a profile field is
     present, validators MUST apply the validation rules of the identified
     profile in addition to ATP Core rules.  When the profile field is
     absent, ATP Core rules apply exclusively.

     Profile identifiers MUST follow one of the two formats defined below:

     *  *Registered profiles* use the prefix urn:ietf:params:atp:profile:
        followed by the profile name and version:



  Bates                   Expires 11 November 2026               [Page 46]


  Internet-Draft                     ATP                          May 2026


       urn:ietf:params:atp:profile:{name}:{version}

     Example: urn:ietf:params:atp:profile:mcp:1.0

     Registered profiles are recorded in the ATP Profiles registry
     (Section 17.2) under the URN sub-namespace registered in
     Section 17.3.

     *  *Private or vendor profiles* use the tag URI scheme [RFC4151] with
        the profile maintainer's DNS authority:

       tag:{authority},{date}:atp-profile/{name}:{version}

     Where {authority} is a DNS name under the profile maintainer's
     control, {date} is the year (YYYY) or year-month (YYYY-MM) on which
     the maintainer became authoritative for that DNS authority, {name} is
     the profile name, and {version} is the semantic version per
     Section 20.2.

     Example: tag:example.com,2026:atp-profile/internal-audit:1.0

     Tag URIs are a registered URI scheme defined by [RFC4151] for use
     cases where a stable identifier is needed without per-identifier IANA
     registration.  Private profile identifiers are not recorded in the
     ATP Profiles registry (Section 17.2) and are valid within the
     operational context of the deploying organization only.

     Validators MUST distinguish registered profile identifiers (which are
     URNs under urn:ietf:params:atp:profile:) from private profile
     identifiers (which are tag URIs under tag:) on the basis of the URI
     scheme.

     Validators SHOULD reject nodes claiming a registered profile
     identifier (using the urn:ietf:params:atp:profile: prefix) that does
     not correspond to an entry in the ATP Profiles registry.

     Implementations of earlier ATP drafts that emitted private profile
     identifiers in the form private:{authority}/{name}:{version} SHOULD
     migrate to the tag URI form before claiming -10 conformance.
     Validators MAY accept the legacy private: form during a transition
     period but MUST report any non-tag-URI private profile identifier
     under profileUnresolved in the validation result (Section 13.6) so
     that operators can identify migration backlog.

  19.2.  Profile Versioning

     Profiles MUST use semantic versioning (MAJOR.MINOR.PATCH):




  Bates                   Expires 11 November 2026               [Page 47]


  Internet-Draft                     ATP                          May 2026


     *  A *MAJOR* version increment is REQUIRED when the profile
        introduces breaking changes to canonicalization rules, the node
        schema, or validation logic.  Nodes produced under MAJOR version N
        are not required to be validatable under MAJOR version N+1 without
        explicit backward-compatibility provisions.

     *  A *MINOR* version increment MAY be used for non-breaking
        additions, such as new action types or new optional fields.

     *  A *PATCH* version increment is used for errata, clarifications,
        and non-normative changes only.

  19.3.  Minimum Profile Contract

     A conformant ATP profile specification MUST define:

     1.  The profile identifier, in the format specified in Section 20.1.

     2.  The action type vocabulary in use, including any relay action
         types (per Section 14.1) and their semantics.  Profile-defined
         action types SHOULD be registered in the ATP Action Types
         registry (Section 17.1) when interoperability is required.

     3.  Any null-field inclusion rules that differ from ATP Core
         (Section 9), enumerated explicitly by field name.

     4.  Any completion-pairing semantics that differ from ATP Core
         (Section 16.2), including whether completion nodes may carry a
         different inputHash than their paired request node.

     5.  The minimum conformance level required of validators claiming
         compliance with the profile.

     6.  Any additional schema fields introduced by the profile, with
         their normative status (REQUIRED, OPTIONAL, or MUST NOT be
         present).

     7.  Node-worthiness rules identifying which events MUST, SHOULD, MAY,
         or MUST NOT produce ATP nodes within the profile's scope.  The
         profile SHOULD provide examples for at least the most common
         emission patterns.

     8.  Streaming semantics, if the profile supports streaming outputs.
         Such profiles MUST define whether stream chunks, stream
         completion events, or stream digests are represented as ATP
         nodes, and how the resulting nodes relate to one another via
         parents.




  Bates                   Expires 11 November 2026               [Page 48]


  Internet-Draft                     ATP                          May 2026


     9.  Relay-fidelity evaluation rules for any profile-defined relay-
         like action type, per Section 14.1.

     A conformant ATP profile specification SHOULD also identify any
     fields it introduces that are likely to contain personal data,
     confidential operational data, security-sensitive policy data, or
     provider-specific identifiers, and SHOULD provide guidance on
     minimization, pseudonymization, or external-payload referencing for
     those fields (Section 15).

     A profile MUST NOT weaken ATP Core's cryptographic integrity
     requirements (Section 10) or its acyclicity constraint (Section 7).

  19.4.  Canonicalization of Profile-Defined Fields

     Profiles MAY define additional top-level fields and additional fields
     within the action object.  Unless explicitly excluded by the profile
     specification, all profile-defined fields MUST participate in
     canonicalization (Section 9) and nodeId computation (Section 10.1).

     Profiles SHOULD NOT exclude fields from canonicalization.  Exclusion
     is reserved for transport-local annotations that are never used for
     validation, authorization, policy decisions, relay fidelity, or audit
     claims.  A profile that excludes one or more of its own fields from
     canonicalization MUST enumerate those fields explicitly and MUST
     justify the exclusion.  Fields excluded from canonicalization are not
     covered by the node signature and therefore MUST NOT be relied upon
     for tamper-evidence.

     Validators that encounter a node with a profile value they do not
     recognize MUST report the node according to one of the following
     behaviors, declared by the validator's mode of operation:

     *  *Strict:* The node is reported as invalid because the validator
        cannot evaluate profile-defined fields' contribution to
        canonicalization.  The node is also recorded under
        profileUnresolved in the validation result (Section 13.6).

     *  *Permissive:* The node is canonicalized including all present
        fields per Section 9.  ATP Core validation proceeds.  The
        validator MUST report the unrecognized profile identifier under
        profileUnresolved in the validation result so that operators can
        detect interoperability gaps.








  Bates                   Expires 11 November 2026               [Page 49]


  Internet-Draft                     ATP                          May 2026


     The default behavior is implementation-specific; profile
     specifications MAY require strict behavior of conformant validators.
     In either mode, profile-unresolved nodes MUST appear in the
     profileUnresolved array of the validation result and MUST NOT be
     silently suppressed.

  19.5.  Conformance Levels

     ATP Core does not define conformance levels beyond the validation
     mode minimums in Section 13.5 and the ATP Core conformance definition
     in Section 13.7.  Profile specifications MAY define additional
     conformance levels appropriate to their domain -- for example, a
     hypothetical ATP-MCP profile might define ATP-MCP-L1 / L2 / L3, or an
     ATP-Healthcare profile might define ATP-Healthcare-Basic / Audit /
     Regulator.  ATP-MCP is one possible profile and is not specially
     privileged by Core.  Conformance level definitions and any composite
     labels are out of scope for ATP Core and are addressed by individual
     profile specifications and [ATP-PROFILES].

     Profile specifications that define composite conformance labels
     SHOULD also specify the test artifacts (golden vectors, validator
     behavior expectations, conformance test suites) required to
     substantiate a conformance claim at each level.

  19.6.  Worked Profile Reference

     Appendix A demonstrates a profile-style action-type vocabulary
     applied to an MCP-style interaction.  The action types and
     action.subtype values used in Appendix A are illustrative; a future
     ATP-MCP profile is expected to formally register an interoperable
     vocabulary.

  19.7.  Profile Assessment States

     ATP Core distinguishes protocol validation from profile assessment.
     A node MAY be ATP-valid while the enclosing scope remains profile-
     incomplete.

     Profiles MAY define assessment states including:

     *  *node-conformant:* A node satisfies ATP Core and applicable
        profile node rules.

     *  *scope-open / profile-progressing:* The scope contains no known
        profile violations but remains open or incomplete.

     *  *scope-sealed / profile-conformant:* The scope is closed according
        to profile rules and satisfies all required profile emissions.



  Bates                   Expires 11 November 2026               [Page 50]


  Internet-Draft                     ATP                          May 2026


     *  *scope-sealed / profile-nonconformant:* The scope is closed but
        one or more required profile emissions, parent relationships, or
        completion pairs are missing or invalid.

     ATP Core does not require a scope-sealing mechanism.  Profiles that
     require sealed-scope assessment MUST define how a scope is sealed and
     how assessment results are represented.  Such profiles MAY define
     dedicated terminal action types (for example, scope-assessment or
     scope-sealed event nodes); ATP Core does not register such types.

     Profile assessment results are distinct from ATP Core validation
     results (Section 13.6).  Profile specifications that define
     assessment states SHOULD define a corresponding result format and
     SHOULD ensure that assessment results compose cleanly with ATP Core
     validation results without overloading the categories defined in
     Section 13.6.

  20.  Normative References

     [ATP-TEST-VECTORS]
                D. Bates, "ATP Core Test Vectors", Work in Progress,
                Internet-Draft, draft-bates-atp-test-vectors-00, 2026,
                <https://datatracker.ietf.org/doc/draft-bates-atp-test-
                vectors/>.

     [RFC2119]  S. Bradner, "Key words for use in RFCs to Indicate
                Requirement Levels", RFC 2119, March 1997,
                <https://www.rfc-editor.org/rfc/rfc2119>.

     [RFC3553]  M. Mealling et al., "An IETF URN Sub-namespace for
                Registered Protocol Parameters", RFC 3553, June 2003,
                <https://www.rfc-editor.org/rfc/rfc3553>.

     [RFC4151]  T. Kindberg, S. Hawke, "The 'tag' URI Scheme", RFC 4151,
                October 2005, <https://www.rfc-editor.org/rfc/rfc4151>.

     [RFC8032]  S. Josefsson, I. Liusvaara, "Edwards-Curve Digital
                Signature Algorithm (EdDSA)", RFC 8032, January 2017,
                <https://www.rfc-editor.org/rfc/rfc8032>.

     [RFC8126]  M. Cotton, B. Leiba, T. Narten, "Guidelines for Writing an
                IANA Considerations Section in RFCs", RFC 8126, June 2017,
                <https://www.rfc-editor.org/rfc/rfc8126>.

     [RFC8174]  B. Leiba, "Ambiguity of Uppercase vs Lowercase in RFC 2119
                Key Words", RFC 8174, May 2017,
                <https://www.rfc-editor.org/rfc/rfc8174>.




  Bates                   Expires 11 November 2026               [Page 51]


  Internet-Draft                     ATP                          May 2026


     [RFC8785]  A. Rundgren, B. Jordan, S. Erdtman, "JSON Canonicalization
                Scheme (JCS)", RFC 8785, June 2020,
                <https://www.rfc-editor.org/rfc/rfc8785>.

  21.  Informative References

     [ATP-PROFILES]
                D. Bates, "ATP Profile Framework", Work in Progress,
                Internet-Draft, draft-bates-atp-profiles-00, 2026,
                <https://datatracker.ietf.org/doc/draft-bates-atp-
                profiles/>.

     [KASSELMAN]
                P. Kasselman et al., "AI Agent Authentication and
                Authorization", Work in Progress, Internet-Draft, draft-
                klrc-aiagent-auth-01, 2026,
                <https://datatracker.ietf.org/doc/draft-klrc-aiagent-
                auth/>.

     [MCP]      Anthropic and contributors, "Model Context Protocol
                Specification", 2025, <https://modelcontextprotocol.io/>.

     [NI]       Y. Ni et al., "Security Requirements for AI Agents", Work
                in Progress, Internet-Draft, draft-ni-a2a-ai-agent-
                security-requirements-01, 2026,
                <https://datatracker.ietf.org/doc/draft-ni-a2a-ai-agent-
                security-requirements/>.

     [NIST-AASI]
                National Institute of Standards and Technology, "AI Agent
                Standards Initiative", 2026, <https://www.nist.gov/caisi/
                ai-agent-standards-initiative>.

     [RFC7591]  J. Richer et al., "OAuth 2.0 Dynamic Client Registration
                Protocol", RFC 7591, July 2015,
                <https://www.rfc-editor.org/rfc/rfc7591>.

     [RFC7942]  Y. Sheffer, A. Farrel, "Improving Awareness of Running
                Code: The Implementation Status Section", RFC 7942, July
                2016, <https://www.rfc-editor.org/rfc/rfc7942>.

     [RFC8615]  M. Nottingham, "Well-Known Uniform Resource Identifiers
                (URIs)", RFC 8615, March 2019,
                <https://www.rfc-editor.org/rfc/rfc8615>.

     [RFC8693]  M. Jones et al., "OAuth 2.0 Token Exchange", RFC 8693,
                January 2020, <https://www.rfc-editor.org/rfc/rfc8693>.




  Bates                   Expires 11 November 2026               [Page 52]


  Internet-Draft                     ATP                          May 2026


     [ROSENBERG]
                J. Rosenberg, C. Jennings, "Framework, Use Cases and
                Requirements for AI Agent Protocols", Work in Progress,
                Internet-Draft, draft-rosenberg-ai-protocols-00, 2025,
                <https://datatracker.ietf.org/doc/draft-rosenberg-ai-
                protocols/>.

     [SCITT]    H. Birkholz et al., "An Architecture for Trustworthy and
                Transparent Digital Supply Chains", Work in Progress,
                Internet-Draft, draft-ietf-scitt-architecture, 2025,
                <https://datatracker.ietf.org/doc/draft-ietf-scitt-
                architecture/>.

     [SMITH]    A. Smith, N. Pai, "Governance Framework for AI-Mediated
                Autonomous Network Device Management", Work in Progress,
                Internet-Draft, draft-smith-opsawg-ai-network-governance-
                00, 2026, <https://datatracker.ietf.org/doc/draft-smith-
                opsawg-ai-network-governance/>.

  Worked Example: MCP Tool Discovery and Invocation

     This appendix pressure-tests whether the Section 8 node schema
     carries the weight of a realistic multi-party agent/tool interaction.
     It illustrates multi-issuer chain-of-custody, fan-in, the
     issuer/agent/actor split, relay node semantics, and the request/
     completion pairing pattern.

     The action types and action.subtype values used in this appendix are
     illustrative only.  They are non-normative and MUST NOT be treated as
     registered ATP-MCP profile values.  A future ATP-MCP profile is
     expected to formally register an interoperable vocabulary.

  A.1 Scenario

     A human (Bob) is logged into an orchestrator platform.  The platform
     hosts an orchestrator agent that needs to complete a task requiring
     an external tool.  The platform is connected to an MCP (Model Context
     Protocol [MCP]) broker, which fronts one or more tool services.  The
     orchestrator discovers tools via the broker, selects one, invokes it,
     and synthesizes the result.

     Three distinct issuers sign nodes in this chain:

     *  issuer:platform.example -- the orchestrator runtime (signs
        orchestrator-side nodes).

     *  issuer:mcp-broker.example -- the MCP broker (signs broker-side
        nodes).



  Bates                   Expires 11 November 2026               [Page 53]


  Internet-Draft                     ATP                          May 2026


     *  issuer:tool-crm.example -- the downstream tool service (signs
        execution nodes).

     Each issuer holds its own Ed25519 key pair.  No issuer signs another
     issuer's nodes.  The DAG is assembled from cross-issuer parent
     references.

     All nodes share a single scope: "wf-8f3a1b" representing one workflow
     execution.  Cross-scope references are not used in this example but
     are PERMITTED per Section 12.

     The human actor is represented by the pseudonymous identifier
     psn:9c3a7e4f-bob (resolvable through a separate identity-resolution
     service per Section 15.4).  The actor field persists across
     orchestrator-side nodes.  The pseudonymous form is used in this
     example to align with the privacy guidance in Section 15.4 and
     Section 16.9; production deployments SHOULD follow the same pattern
     rather than embedding directly identifying values such as email
     addresses or employee numbers in actorId.

     Each example node uses a registered ATP Core value in action.type and
     a profile-defined descriptive value in action.subtype.  The subtype
     field is shown to illustrate how a future ATP-MCP profile could add
     domain-specific naming on top of the Core action types registered in
     Section 17.1.

  A.2 Node Sequence

     The following seven nodes form the chain.  Each is shown in its pre-
     signing structure; nodeId and signature are elided for readability
     but would be present and computed per Section 9 and Section 10.

  Node 1 -- tool catalog query (atp:request)

     Orchestrator asks the broker what tools are available.
















  Bates                   Expires 11 November 2026               [Page 54]


  Internet-Draft                     ATP                          May 2026


     {
       "timestamp": "2026-04-23T12:58:00Z",
       "scope": "wf-8f3a1b",
       "issuer": { "issuerId": "platform.example", "keyId": "platform-2026-04" },
       "agent":  { "agentId": "orchestrator-agent", "version": "1.3.0" },
       "actor":  { "actorId": "psn:9c3a7e4f-bob", "authContext": "saml:corp-idp" },
       "action": {
         "type": "atp:request",
         "subtype": "tool_catalog_query",
         "inputHash": "sha256:ab12..."
       },
       "parents": []
     }

     Root node. parents: []. inputHash covers the broker endpoint and
     query parameters. outputHash is omitted because the response has not
     arrived yet -- this is a request node per the Section 16.2 request/
     completion pairing pattern.  The subtype field shown here is profile-
     defined and would be specified by an ATP-MCP profile per
     Section 20.3.

  Node 2 -- tool catalog response (atp:completion)

     Broker returns its tool inventory. *Signed by the broker, not the
     orchestrator.*

     {
       "timestamp": "2026-04-23T12:58:00.110Z",
       "scope": "wf-8f3a1b",
       "issuer": { "issuerId": "mcp-broker.example", "keyId": "broker-2026-04" },
       "agent":  { "agentId": "mcp-catalog-service", "version": "2.1.0" },
       "action": {
         "type": "atp:completion",
         "subtype": "tool_catalog_response",
         "inputHash": "sha256:ab12...",
         "outputHash": "sha256:cd34..."
       },
       "parents": ["<nodeId of Node 1>"]
     }

     The broker has no actor -- the action is not being taken on behalf of
     a human principal; it is a service response.  The actor field is
     OPTIONAL per Section 8 and is omitted here. parents points back to
     the orchestrator's query, forming a cross-issuer link.  This node
     serves as the completion node for Node 1's request, carrying the
     outputHash that Node 1 omitted.





  Bates                   Expires 11 November 2026               [Page 55]


  Internet-Draft                     ATP                          May 2026


  Node 3 -- tool selection decision (atp:decision)

     Orchestrator picks a tool based on the catalog.  This is a
     *decisional node* per Section 17.1: no external system is called, but
     a decision is recorded as part of the chain.

     {
       "timestamp": "2026-04-23T12:58:00.240Z",
       "scope": "wf-8f3a1b",
       "issuer": { "issuerId": "platform.example", "keyId": "platform-2026-04" },
       "agent":  { "agentId": "orchestrator-agent", "version": "1.3.0" },
       "actor":  { "actorId": "psn:9c3a7e4f-bob", "authContext": "saml:corp-idp" },
       "action": {
         "type": "atp:decision",
         "subtype": "tool_selection_decision",
         "inputHash": "sha256:cd34...",
         "outputHash": "sha256:ef56..."
       },
       "parents": ["<nodeId of Node 2>"]
     }

     inputHash references the catalog the orchestrator saw; outputHash
     references the selection rationale (prompt trace, scoring notes, or
     policy decision).  This node is the auditable answer to "why did the
     agent choose this tool?"

  Node 4 -- tool invocation request (atp:request)

     Orchestrator asks the broker to invoke the chosen tool.

     {
       "timestamp": "2026-04-23T12:58:00.380Z",
       "scope": "wf-8f3a1b",
       "issuer": { "issuerId": "platform.example", "keyId": "platform-2026-04" },
       "agent":  { "agentId": "orchestrator-agent", "version": "1.3.0" },
       "actor":  { "actorId": "psn:9c3a7e4f-bob", "authContext": "saml:corp-idp" },
       "action": {
         "type": "atp:request",
         "subtype": "tool_invocation_request",
         "inputHash": "sha256:gh78..."
       },
       "parents": ["<nodeId of Node 3>"]
     }

     Request node -- outputHash is omitted per Section 16.2.  Linear
     descendant of the selection decision.





  Bates                   Expires 11 November 2026               [Page 56]


  Internet-Draft                     ATP                          May 2026


  Node 5 -- tool execution (atp:completion)

     The tool service executes the request and signs its own node.  The
     broker forwards the request but the tool signs directly, with parents
     pointing at the invocation request.

     {
       "timestamp": "2026-04-23T12:58:00.610Z",
       "scope": "wf-8f3a1b",
       "issuer": { "issuerId": "tool-crm.example", "keyId": "crm-2026-04" },
       "agent":  { "agentId": "crm-lookup-service", "version": "5.0.2" },
       "action": {
         "type": "atp:completion",
         "subtype": "tool_execution",
         "inputHash": "sha256:gh78...",
         "outputHash": "sha256:ij90..."
       },
       "parents": ["<nodeId of Node 4>"]
     }

     Third issuer enters the chain.  No actor -- this is a service-origin
     action.

  Node 6 -- tool execution response (atp:relay)

     Broker relays the execution result back to the orchestrator.  This
     node is _optional_ -- if the orchestrator accepts the tool's signed
     node directly, the broker's relay does not require its own node.
     Shown here for completeness and to illustrate relay node semantics.

     {
       "timestamp": "2026-04-23T12:58:00.630Z",
       "scope": "wf-8f3a1b",
       "issuer": { "issuerId": "mcp-broker.example", "keyId": "broker-2026-04" },
       "agent":  { "agentId": "mcp-relay-service", "version": "2.1.0" },
       "action": {
         "type": "atp:relay",
         "subtype": "tool_execution_response",
         "inputHash": "sha256:ij90...",
         "outputHash": "sha256:ij90..."
       },
       "parents": ["<nodeId of Node 5>"]
     }








  Bates                   Expires 11 November 2026               [Page 57]


  Internet-Draft                     ATP                          May 2026


     *Relay node.* inputHash == outputHash because the broker asserts it
     is not transforming the payload.  Per Section 14.1, this is an issuer
     assertion of fidelity, not proof of non-modification.  Validators
     requiring strong fidelity guarantees SHOULD verify Node 5's signature
     directly rather than relying solely on this relay claim (see
     Section 14.2 for the verified/asserted/contradicted fidelity states).

  Node 7 -- decision synthesis (atp:decision)

     Orchestrator synthesizes a final answer from the tool result. *This
     is a fan-in node* -- it has two parents: the relay's execution
     response (Node 6) and the selection decision (Node 3), because the
     synthesis depends on both the evidence and the prior reasoning.

     {
       "timestamp": "2026-04-23T12:58:00.820Z",
       "scope": "wf-8f3a1b",
       "issuer": { "issuerId": "platform.example", "keyId": "platform-2026-04" },
       "agent":  { "agentId": "orchestrator-agent", "version": "1.3.0" },
       "actor":  { "actorId": "psn:9c3a7e4f-bob", "authContext": "saml:corp-idp" },
       "action": {
         "type": "atp:decision",
         "subtype": "decision_synthesis",
         "inputHash": "sha256:kl12...",
         "outputHash": "sha256:mn34..."
       },
       "parents": [
         "<nodeId of Node 6>",
         "<nodeId of Node 3>"
       ]
     }

     Fan-in illustrates why the DAG model is necessary: a linear log could
     not express that the synthesis is causally dependent on both the
     selection rationale _and_ the tool result.

  A.3 DAG Structure

     The following diagram shows the node-and-edge structure of the
     example, with nodes grouped by issuer:











  Bates                   Expires 11 November 2026               [Page 58]


  Internet-Draft                     ATP                          May 2026


     graph TD
         subgraph "issuer: platform.example"
             N1["Node 1<br/>atp:request<br/>tool_catalog_query"]
             N3["Node 3<br/>atp:decision<br/>tool_selection_decision"]
             N4["Node 4<br/>atp:request<br/>tool_invocation_request"]
             N7["Node 7<br/>atp:decision<br/>decision_synthesis"]
         end

         subgraph "issuer: mcp-broker.example"
             N2["Node 2<br/>atp:completion<br/>tool_catalog_response"]
             N6["Node 6<br/>atp:relay<br/>tool_execution_response"]
         end

         subgraph "issuer: tool-crm.example"
             N5["Node 5<br/>atp:completion<br/>tool_execution"]
         end

         N1 --> N2
         N2 --> N3
         N3 --> N4
         N4 --> N5
         N5 --> N6
         N6 --> N7
         N3 --> N7

         style N1 fill:#2E75B6,color:#fff
         style N3 fill:#2E75B6,color:#fff
         style N4 fill:#2E75B6,color:#fff
         style N7 fill:#2E75B6,color:#fff
         style N2 fill:#6AAF50,color:#fff
         style N6 fill:#6AAF50,color:#fff
         style N5 fill:#D94A4A,color:#fff

     The following sequence diagram shows the temporal message flow of the
     same interaction:
















  Bates                   Expires 11 November 2026               [Page 59]


  Internet-Draft                     ATP                          May 2026


  sequenceDiagram
      participant Orchestrator
      participant Broker
      participant Tool

      Orchestrator->>Broker: atp:request / tool_catalog_query (Node 1)
      Broker-->>Orchestrator: atp:completion / tool_catalog_response (Node 2)
      Orchestrator->>Orchestrator: atp:decision / tool_selection_decision (Node 3)
      Orchestrator->>Broker: atp:request / tool_invocation_request (Node 4)
      Broker->>Tool: (forwarded)
      Tool-->>Broker: atp:completion / tool_execution (Node 5)
      Broker-->>Orchestrator: atp:relay / tool_execution_response (Node 6)
      Orchestrator->>Orchestrator: atp:decision / decision_synthesis (Node 7, fan-in)

     Seven nodes.  Three issuers.  One actor (human) across all
     orchestrator-side nodes; no actor on broker/tool-side nodes.  One
     workflow scope.  One fan-in at the synthesis step.  One relay node at
     the broker layer.

  A.4 What This Example Demonstrates

     *  *Section 8 schema carries the weight.* All seven nodes serialize
        cleanly into the base schema.  No new top-level fields were
        required.  The subtype field used in action is profile-defined and
        would be specified by an ATP-MCP profile per Section 20.3.

     *  *Three-way identity split does real work.* The orchestrator's
        nodes (1, 3, 4, 7) share issuer and agent but carry the human
        actor.  The broker and tool nodes carry no actor -- the action is
        not human-delegated at that layer.  This is exactly the
        distinction the split is designed to capture.

     *  *Cross-issuer chain of custody works via parents.* No issuer signs
        another issuer's nodes.  Chain integrity comes from content-
        addressed nodeId references, which are tamper-evident per
        Section 10.  When the tool's signed execution node (Node 5) is
        present in the chain, the broker is a forwarding layer rather than
        the authoritative origin of the tool result; profiles MAY override
        this default by defining alternative authority semantics for relay
        nodes.

     *  *Fan-in is necessary, not decorative.* The synthesis node (Node 7)
        demonstrates why a DAG beats a linear log: causal dependency on
        both evidence and prior decision.







  Bates                   Expires 11 November 2026               [Page 60]


  Internet-Draft                     ATP                          May 2026


     *  *Request/completion pairing works cleanly.* Nodes 1 and 4 use
        atp:request and omit outputHash per Section 16.2.  Nodes 2 and 5
        use atp:completion and serve as their respective completion nodes.
        The pattern handles cross-issuer request/response naturally.

     *  *Relay semantics are explicit.* Node 6 uses atp:relay and asserts
        relay fidelity (inputHash == outputHash).  Per Section 14.1, this
        is an assertion, not proof.  Validators can verify Node 5 directly
        for stronger fidelity (Section 14.2).

     *  *"Node-worthy" selection is profile responsibility.* Node 6 could
        legitimately be omitted in this Core example.  ATP Core does not
        prescribe; an ATP-MCP profile is expected to define node-
        worthiness rules per Section 20.3.

  A.5 Profile Note: action.type and action.subtype Vocabulary

     The ATP Core action types used in this example (atp:request,
     atp:completion, atp:relay, atp:decision) are registered in
     Section 17.1.  The descriptive subtypes (tool_catalog_query,
     tool_invocation_request, etc.) are illustrative and are carried in a
     profile-defined action.subtype field.  Each example node uses a
     registered ATP Core value in action.type and a profile-defined
     descriptive value in action.subtype.

     The subtype values used here are non-normative and MUST NOT be
     treated as registered ATP-MCP profile values.  A future ATP-MCP
     profile specification is expected to define a canonical vocabulary
     for MCP-style interactions and to register that vocabulary under the
     Section 17.1 Specification Required policy.  The vocabulary MAY be
     expressed through action.subtype values, additional atp:-prefixed
     action types (e.g., atp:mcp.tool_invocation), or both -- that design
     decision is left to the profile authors.

  Future Work and Areas for Further Refinement

     The following areas are candidates for future refinement as
     implementation experience accumulates:

     *  Empirical performance data across storage patterns and graph
        shapes to validate the guidance in Section 16.10.

     *  Operational patterns for cross-scope federation mechanisms
        referenced in Section 16.3.







  Bates                   Expires 11 November 2026               [Page 61]


  Internet-Draft                     ATP                          May 2026


     *  Profile specifications for domain-specific interaction patterns,
        such as an ATP-MCP profile for MCP-style tool discovery and
        invocation sequences and an ATP-Gateway profile for AI gateway
        routing, guardrail, cache, and provider-fallback semantics.

     *  Formal specification of conformance levels (e.g., composite labels
        such as ATP-MCP-L1/L2/L3) within profile specifications.  ATP Core
        defers conformance-level definition to profiles per Section 20.5.

     *  Scope-level assessment or sealing semantics for chains where an
        explicit "no further nodes will be emitted" signal is required.
        ATP Core defines the assessment-state vocabulary in Section 20.7
        but does not define scope-sealing mechanisms; profiles that
        require sealed-scope assessment are responsible for those
        definitions.

     *  Streaming-response semantics for profiles that target token-
        streaming gateways, including whether each token chunk is a node,
        the final response is a node, or only a digest of the stream is
        hashed into one completion node.  ATP Core requires profiles that
        support streaming to declare these semantics per Section 20.3.

     *  A normative key-discovery path (e.g., a well-known URI
        registration under [RFC8615]).  ATP Core explicitly defers this to
        a future specification (Section 16.1, Section 17.3).

     *  A media type registration for the Section 13.6 validation result
        format, if cross-organization exchange of validation results
        becomes a recognized use case.

     *  Algorithm-agility mechanisms for the hash and signature primitives
        currently fixed at SHA-256 and Ed25519.  ATP Core treats this as a
        forward-compatibility issue addressed by a future revision rather
        than negotiated within this version.

  Related Work

     Several active Internet-Drafts and standards initiatives address
     aspects of AI agent security, identity, and governance.  ATP is
     designed to be complementary to these efforts rather than
     overlapping.  This appendix describes the relationship between ATP
     and each relevant body of work.









  Bates                   Expires 11 November 2026               [Page 62]


  Internet-Draft                     ATP                          May 2026


  C.1 Identity and Authentication

     [NI] defines security requirements for AI agents across provisioning,
     registration, discovery, cross-domain interconnection, and access
     control.  It introduces an Agent Credential Authority (ACA) and an
     Agent Registry Service (ARS) as part of that architecture.

     [KASSELMAN] proposes AI Agent Authentication and Authorization using
     existing standards including WIMSE, SPIFFE, and the OAuth 2.0 family.
     It defines the Agent Identity Management System (AIMS) as a
     conceptual model for establishing, maintaining, and evaluating the
     identity and permissions of agent workloads.

     Both efforts answer the question "is this agent authenticated and
     authorized to act?"  ATP answers a different question: "what did this
     agent do, and can that action be independently verified?"  ATP does
     not replace credential issuance, registration, workload identity, or
     authorization frameworks.  An ATP deployment MAY consume credentials
     or identifiers established by systems such as ACA/ARS or AIMS-
     compatible deployments as the operational basis for issuer.keyId,
     agent.agentId, and actor.authContext mappings.

  C.2 Agent Communication Frameworks

     [ROSENBERG] describes a framework for AI agent communications,
     surveys protocols including MCP, A2A, and the Agntcy Framework, and
     frames requirements for AI agent communications on the Internet.

     ATP is not a communication protocol.  ATP does not define how agents
     discover, connect to, or exchange messages with one another.  ATP
     defines how actions taken during or as a result of those
     communications are recorded as cryptographically signed, causally
     linked graph nodes.  ATP can therefore serve as an accountability and
     audit layer for systems built on communication frameworks such as
     those described in [ROSENBERG].

  C.3 Domain-Specific Governance

     [SMITH] defines a governance framework for AI-mediated autonomous
     network device management.  It establishes thirteen governance areas
     including human authority, bounded autonomy, transparency,
     reversibility, escalation, and related safety controls for AI-
     mediated network management systems.

     ATP and [SMITH] operate at different layers.  [SMITH] defines
     governance principles and control expectations.  ATP defines
     governance evidence: a verifiable record of what agents actually did.
     The two are complementary.  Governance principles without verifiable



  Bates                   Expires 11 November 2026               [Page 63]


  Internet-Draft                     ATP                          May 2026


     evidence are difficult to prove; verifiable evidence without
     governance principles is data without policy.  ATP can provide the
     evidentiary substrate used to demonstrate compliance or non-
     compliance with domain-specific governance frameworks.

  C.4 Standards Coordination

     [NIST-AASI] describes the NIST AI Agent Standards Initiative, which
     aims to foster industry-led technical standards and open protocols so
     that agents function securely on behalf of users and interoperate
     smoothly across the digital landscape.  ATP's focus on verifiable
     agent-action lineage falls within that broader accountability and
     interoperability space.

  C.5 Existing RFCs Applied to Agent Systems

     Several existing RFCs are relevant in agent deployments.

     [RFC8693] defines OAuth 2.0 Token Exchange, which can be used for
     secure delegation and scoped authority grants between systems.
     [RFC7591] defines OAuth 2.0 Dynamic Client Registration Protocol,
     which can be applied to automated registration of agent workloads.

     ATP does not depend on or replace these RFCs.  Instead, ATP can
     compose with them.  For example, token-exchange contexts may be
     reflected in actor.authContext, while identifiers established through
     registration flows may be mapped by implementations into
     agent.agentId and issuer.issuerId.

  C.6 Transparency and Supply-Chain Provenance

     [SCITT] (Supply Chain Integrity, Transparency and Trust) defines an
     architecture for issuing, registering, and verifying signed
     statements about software supply-chain artifacts via append-only
     transparency services.  SCITT and ATP address related but distinct
     problems.

     SCITT publishes signed statements to an auditable transparency log so
     that the existence and order of statements can be verified
     independently of the issuer.  ATP defines a directed acyclic graph of
     signed agent-action nodes whose causal relationships are themselves
     cryptographically tamper-evident.  SCITT is publication-and-
     witnessing oriented; ATP is causality-and-heritage oriented.

     The two are composable.  An ATP deployment that requires independent
     witnessing of node existence and ordering MAY publish ATP nodes (or
     their nodeId values) as signed statements to a SCITT-compatible
     transparency service.  In that composition, ATP provides the



  Bates                   Expires 11 November 2026               [Page 64]


  Internet-Draft                     ATP                          May 2026


     verifiable causal structure of agent actions, and SCITT provides
     operator-independent evidence that those nodes existed at a given
     time and have not been retroactively suppressed.  This composition is
     the recommended deployment pattern for the anti-suppression scenario
     discussed in Section 14.6.

     ATP Core does not require a transparency layer.  Future profile
     specifications MAY describe SCITT-compatible publication patterns
     where stronger anti-suppression guarantees are needed.

  C.7 ATP's Distinct Contribution

     The gap ATP fills is specific: none of the above efforts define a
     protocol for cryptographically signed, DAG-structured, causally
     linked records of agent actions with explicit separation of issuer,
     agent, and actor identity.  Adjacent efforts address who agents are,
     what agents are allowed to do, how agents communicate, what
     governance principles they should follow, and how supply-chain
     statements are made transparent.  ATP addresses what agents actually
     did, provably, with tamper-evident lineage that does not require
     trusting the platform that produced the record.

     ATP is intentionally narrow so that it can compose with identity,
     authorization, communication, governance, and transparency layers
     defined by adjacent efforts without creating conflicts or
     dependencies that would impair adoption of either ATP or the systems
     it complements.

  Author's Address

     David A. Bates
     SVT Robotics
     Email: david.bates@svtrobotics.com
     URI:   https://www.svtrobotics.com/

















  Bates                   Expires 11 November 2026               [Page 65]


name: draft-sato-soos-hem
rev: 01
title: The Human Escalation Mechanism (HEM) for Agentic AI Systems
time: 2026-05-19T11:54:38Z
group_uri: /api/v1/group/group/1027/
expires: 2026-11-20T11:54:38Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["Human-agent interaction", "AI safety/alignment", "Policy/governance"]
tags: []
fetched_at: 2026-05-22T09:24:47.115479+00:00
source: ietf
abstract:
  AI agents operating autonomously encounter situations where their
     authorized action space is insufficient for the task at hand, where
     policy mandates human judgment regardless of agent capability, or
     where the agent itself assesses that human oversight is required.
     No existing standard specifies the kernel-level contract that governs
     what happens in these moments: what triggers escalation, what a human
     principal may decide, how the system behaves while awaiting that
     decision, and what happens when the designated human is unreachable.

     This document defines the Human Escalation Mechanism (HEM): a
     normative protocol in which a governing OS kernel places an agent
     session into a formally defined HEM_PENDING state, routes a
     structured escalation request to one or more designated human
     principals, enforces a prohibition on state transitions until a
     human decision is received, and processes five defined human decision
     types. HEM is a first-class kernel session state, not an
     application-layer confirmation protocol. This document also defines
     the Policy Rationale Declaration (PRD), which links Cedar policies
     that route to HEM with machine-readable rationale, and the Decision
     Rationale Record (DRR), which captures the human principal's
     reasoning for high-consequence decisions. HEM provides the technical
     specification for human oversight of agentic AI systems required by
     EU AI Act Article 14.

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


           The Human Escalation Mechanism (HEM) for Agentic AI Systems
                           draft-sato-soos-hem-01


  Abstract

     AI agents operating autonomously encounter situations where their
     authorized action space is insufficient for the task at hand, where
     policy mandates human judgment regardless of agent capability, or
     where the agent itself assesses that human oversight is required.
     No existing standard specifies the kernel-level contract that governs
     what happens in these moments: what triggers escalation, what a human
     principal may decide, how the system behaves while awaiting that
     decision, and what happens when the designated human is unreachable.

     This document defines the Human Escalation Mechanism (HEM): a
     normative protocol in which a governing OS kernel places an agent
     session into a formally defined HEM_PENDING state, routes a
     structured escalation request to one or more designated human
     principals, enforces a prohibition on state transitions until a
     human decision is received, and processes five defined human decision
     types. HEM is a first-class kernel session state, not an
     application-layer confirmation protocol. This document also defines
     the Policy Rationale Declaration (PRD), which links Cedar policies
     that route to HEM with machine-readable rationale, and the Decision
     Rationale Record (DRR), which captures the human principal's
     reasoning for high-consequence decisions. HEM provides the technical
     specification for human oversight of agentic AI systems required by
     EU AI Act Article 14.

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

  Copyright Notice

     Copyright (c) 2026 IETF Trust and the persons identified as the
     document authors.  All rights reserved.

     This document is subject to BCP 78 and the IETF Trust's Legal
     Provisions Relating to IETF Documents
     (https://trustee.ietf.org/license-info) in effect on the date of
     publication of this document.  Please review these documents
     carefully, as they describe your rights and restrictions with respect
     to this document.


  Table of Contents

     1.  Introduction
     2.  Conventions and Definitions
     3.  Problem Statement
         3.1.  The Human Oversight Gap in Agentic Systems
         3.2.  Relationship to EU AI Act Article 14
         3.3.  Relationship to CHEQ
     4.  HEM Session States
         4.1.  State Definitions
         4.2.  State Transition Constraints
     5.  HEM Trigger Classes
         5.1.  Class 1: Cedar Policy Routing (HEM_CEDAR_ROUTED)
         5.2.  Class 2: Agent Uncertainty Declaration (HEM_AGENT_ESCALATED)
         5.3.  Class 3: Proximity Threshold Crossing (HEM_PROXIMITY_TRIGGERED)
         5.4.  Class 4: Mission Validity Failure (HEM_MISSION_VALIDITY_FAILED)
         5.5.  Class 5: Jurisdictional Conflict (HEM_JURISDICTIONAL_CONFLICT)
         5.6.  Policy Rationale Declaration (PRD)
         5.7.  Extension Trigger Classes
     6.  HEM Escalation Request
         6.1.  Structure
         6.2.  Field Definitions
         6.3.  Routing to Human Principals
     7.  Human Decision Types
         7.1.  APPROVE
         7.2.  APPROVE_WITH_CONSTRAINTS
         7.3.  REDIRECT
         7.4.  TERMINATE
         7.5.  DEFER
         7.6.  Decision Rationale Record (DRR)
         7.7.  Decision Submission Protocol
     8.  Transition Prohibition During HEM_PENDING
         8.1.  The Prohibition Rule
         8.2.  Read-Only Operations During HEM_PENDING
         8.3.  Multiple Concurrent HEM_PENDING Conditions
         8.4.  Mission Validity During HEM_PENDING
     9.  Timeout Model
         9.1.  Timeout Budget
         9.2.  Timeout Disposition
         9.3.  Timeout Chain (HEM_UNREACHABLE)
         9.4.  Chain Exhaustion
    10.  Event Log Requirements
    11.  Relationship to IDP
    12.  Security Considerations
    13.  Privacy Considerations
    14.  EU AI Act Applicability
    15.  IANA Considerations
    16.  References
         16.1.  Normative References
         16.2.  Informative References
    Acknowledgments
    Author's Address


  1.  Introduction

     The deployment of AI agents in consequential workflows -- booking
     systems, healthcare coordination, financial operations, logistics --
     requires that those systems be supervisable by humans. This
     requirement is not merely normative; it is increasingly regulatory.
     EU AI Act Article 14 mandates that high-risk AI systems include human
     oversight measures that enable humans to intervene in the operation
     of the system [EUAIA].

     The existing landscape of AI agent standards provides no normative
     specification of what such intervention looks like at the protocol
     level. WIMSE [I-D.ietf-wimse-arch] addresses workload identity.
     AAuth [I-D.klrc-aiagent-auth] addresses token-based authorization.
     CHEQ [I-D.rosenberg-aiproto-cheq] provides an application-layer
     protocol for human confirmation of specific agent actions. None of
     these specifications defines a kernel-level contract for what happens
     when an agent's authorized scope is insufficient, when policy
     mandates human judgment, or when an agent itself declares that it
     requires human oversight before proceeding.

     The distinction between AAuth [I-D.klrc-aiagent-auth] and this
     document is specifically: AAuth achieves mission correlation, binding
     authorization tokens to a declared mission scope; HEM achieves
     mission containment, specifying the kernel-enforced state contract
     that governs agent sessions when autonomous execution must yield to
     human judgment. The two primitives address different layers of the
     same problem.

     This document defines the Human Escalation Mechanism (HEM): a
     normative protocol governing the lifecycle of human oversight events
     in agentic AI systems. HEM specifies:

     *  Five trigger classes that cause a kernel to place a session into
        HEM_PENDING state (Section 5), with a defined extension mechanism
        for additional trigger classes (Section 5.7).
     *  A Policy Rationale Declaration (PRD) linking each Cedar policy
        that routes to HEM with machine-readable rationale (Section 5.6).
     *  A structured HEM escalation request routed to one or more
        designated human principals, kernel-signed with Ed25519
        (Section 6).
     *  Five human decision types that resolve a pending escalation
        (Section 7).
     *  A Decision Rationale Record (DRR) capturing human principal
        reasoning for high-consequence decisions (Section 7.6).
     *  A mandatory transition prohibition enforced by the kernel while
        HEM_PENDING is active (Section 8).
     *  A timeout model governing behaviour when designated human
        principals are unreachable (Section 9).
     *  A mission validity clause governing HEM behaviour when the
        governing MissionDeclaration enters a terminal phase during an
        active HEM_PENDING event (Section 8.4).

     HEM is a kernel primitive. It is enforced by the governing runtime
     kernel, not by the agent and not by the application layer. An agent
     cannot opt out of HEM; an application cannot suppress it. This
     kernel-enforced quality is what distinguishes HEM from application-
     layer confirmation protocols such as CHEQ [I-D.rosenberg-aiproto-
     cheq] and gives HEM its regulatory utility.

     HEM does not specify the delivery mechanism by which escalation
     requests reach human principals. That is a deployment concern.
     Application-layer protocols such as CHEQ MAY serve as the delivery
     mechanism for HEM notification; HEM specifies what that delivery
     must achieve, not how it is achieved.


  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:
        A software system that uses AI to reason about and take actions
        in pursuit of goals.

     Governing Kernel:
        A runtime component that enforces authorization policy, maintains
        session state, records agent actions to a tamper-evident Event
        Log, and mediates agent access to governed objects.

     Governed Object (SO):
        A typed, stateful entity managed by the kernel. Its lifecycle
        is governed by a Cedar-enforced state machine.

     Mandate JWT:
        A JSON Web Token [RFC7519] binding an agent's authorization to a
        specific governed object instance.

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

     HEM:
        Human Escalation Mechanism. The protocol defined by this
        document.

     HEM_PENDING:
        The kernel session state in which HEM is active. No governed
        object state transitions may execute while HEM_PENDING is
        active.

     HEM_RESOLVED:
        The kernel session state following receipt and processing of a
        valid human decision.

     HEM_TIMEOUT:
        The kernel session state following expiration of the HEM timeout
        budget without receipt of a valid human decision.

     Human Principal:
        A natural person designated in the governed object's Principal
        Registry as authorized to issue HEM decisions.

     Designation Chain:
        An ordered list of human principals to be contacted sequentially
        if earlier principals in the chain are unreachable.

     IDP:
        Intent Declaration Primitive [I-D.sato-soos-idp]. The per-
        transition agent reasoning declaration that accompanies each
        kernel.transition() call.

     MissionDeclaration:
        A structured declaration [SOOS] specifying the overarching goal,
        lifecycle conditions, and authority constraints under which a set
        of agent sessions operate. A MissionDeclaration has a phase
        (DISCOVERY, EXECUTION, RELEASE, SUSPENDED, FAILED, ABANDONED).

     Proximity Threshold:
        A pre-declared monitoring condition specifying a governed object
        state, resource value, or event pattern that, when reached,
        triggers HEM regardless of agent action.

     Event Log:
        An append-only, causally ordered, tamper-evident log of all
        transitions and kernel events for a governed object.


  3.  Problem Statement

  3.1.  The Human Oversight Gap in Agentic Systems

     Agentic AI systems operating in automated workflows encounter three
     classes of situation that require human involvement:

     (a)  Scope insufficiency. The action required to advance the task
          is outside the agent's Cedar-authorized action set. The agent
          cannot proceed autonomously and cannot determine whether a human
          would authorize the action.

     (b)  Policy-mandated oversight. Authorization policy specifies that
          certain transitions require human approval regardless of agent
          capability. The agent may be capable of executing the action
          but policy prohibits autonomous execution.

     (c)  Agent-declared uncertainty. The agent assesses that its
          confidence in the appropriate action is insufficient and that
          human judgment should be sought before proceeding. This is a
          first-class agent capability, not a failure mode.

     No existing protocol specifies a normative kernel-level response to
     any of these three classes. The consequences of this gap include:

     *  Agents that stall silently when their scope is insufficient,
        with no structured notification to human principals.
     *  Agents that execute policy-mandated-oversight transitions
        autonomously because no enforcement mechanism exists.
     *  Agents that have no normative mechanism for expressing that they
        require human judgment.
     *  Systems with no defined behaviour for the period between
        escalation and human decision.
     *  Systems with no defined behaviour when designated human
        principals are unreachable.
     *  Ghost execution: sessions continuing to operate after the
        overarching mission for which they were authorized has entered
        a terminal state (SUSPENDED, FAILED, or ABANDONED), producing
        actions that have no legitimate mission context.

  3.2.  Relationship to EU AI Act Article 14

     EU AI Act Article 14 requires that high-risk AI systems be designed
     and developed, where technically feasible, to be effectively
     overseen by natural persons during the period in which the AI system
     is in use. Specifically, Article 14 requires that human oversight
     measures enable those persons to:

     *  understand the capabilities and limitations of the high-risk
        AI system;
     *  monitor the operation of the system;
     *  detect and address the emergence of anomalous situations; and
     *  intervene in the operation of the system or interrupt the system
        through a "stop" button or similar procedure.

     HEM provides the technical specification for these requirements at
     the kernel level. The HEM_PENDING state and transition prohibition
     (Section 8) implement the "stop" button. The five human decision
     types (Section 7) implement structured intervention. The timeout
     model (Section 9) defines system behaviour during unreachability,
     preventing indefinite autonomous operation in oversight-mandated
     states.

     This document is informative with respect to regulatory compliance
     and does not constitute legal advice.

  3.3.  Relationship to CHEQ

     CHEQ [I-D.rosenberg-aiproto-cheq] defines an application-layer
     protocol by which AI agents request human confirmation of specific
     actions before executing them. CHEQ is agent-initiated: the agent
     chooses to request confirmation, constructs a CHEQ confirmation
     object, and delivers it to a human confirmation service.

     HEM is architecturally distinct in three respects.

     First, HEM is kernel-enforced. A HEM trigger causes the kernel to
     enter HEM_PENDING regardless of agent preference. An agent cannot
     suppress a kernel-triggered HEM; it cannot proceed without a human
     decision once HEM_PENDING is active. CHEQ confirmation is a choice
     the agent makes; HEM_PENDING is a state the kernel enforces.

     Second, HEM defines the session state contract. While HEM_PENDING
     is active, all state transitions are prohibited (Section 8). CHEQ
     does not specify any equivalent session state constraint.

     Third, HEM defines a structured decision vocabulary. The five HEM
     decision types (Section 7) are normative; they define what a human
     principal may decide and what the kernel must do with each decision.
     CHEQ defines a confirmation/denial binary without equivalent
     normative treatment of the decision space.

     CHEQ and HEM are complementary. A CHEQ-like application-layer
     protocol MAY serve as the delivery mechanism for HEM escalation
     notifications (Section 6.3). HEM specifies the kernel contract
     that such a delivery protocol must satisfy; it does not specify the
     delivery mechanism itself.


  4.  HEM Session States

  4.1.  State Definitions

     A kernel session with respect to HEM is in one of the following
     states at any moment:

     HEM_INACTIVE:
        Default state. No HEM condition is active. The kernel processes
        agent transitions normally subject to Cedar evaluation.

     HEM_PENDING:
        A HEM trigger has fired and the kernel has routed an escalation
        request to one or more designated human principals. No governed
        object state transitions may execute. This state persists until
        a valid human decision is received or the timeout budget is
        exhausted.

     HEM_RESOLVED:
        A valid human decision has been received and processed. The
        session returns to HEM_INACTIVE unless the human decision itself
        requires further HEM consideration.

     HEM_TIMEOUT:
        The timeout budget has been exhausted without receipt of a valid
        human decision. The kernel applies the configured timeout
        disposition (Section 9.2). This state is terminal for the
        current HEM event; the session MAY return to HEM_INACTIVE
        depending on the disposition.

     HEM_CHAIN_EXHAUSTED:
        The designation chain has been exhausted without a decision from
        any principal and the timeout budget is exhausted. The kernel
        applies the chain exhaustion disposition (Section 9.4). This
        state is terminal for the current HEM event.

  4.2.  State Transition Constraints

     The following state transitions are normative for a conforming
     kernel implementation:

     HEM_INACTIVE --> HEM_PENDING (HEM trigger fires)
     HEM_PENDING --> HEM_RESOLVED (valid decision received)
     HEM_PENDING --> HEM_TIMEOUT (timeout budget exhausted)
     HEM_PENDING --> HEM_CHAIN_EXHAUSTED (mission validity failure;
                                          see Section 8.4)
     HEM_TIMEOUT --> HEM_CHAIN_EXHAUSTED (chain exhausted)
     HEM_TIMEOUT --> HEM_INACTIVE (disposition permits)
     HEM_RESOLVED --> HEM_INACTIVE (always)
     HEM_CHAIN_EXHAUSTED --> [terminal] (session suspended or
                              terminated per Section 9.4)

     The transition HEM_INACTIVE --> HEM_PENDING MUST be kernel-initiated.
     No agent call may directly set the session to HEM_PENDING except
     through the defined trigger mechanisms (Section 5).


  5.  HEM Trigger Classes

     This document defines five trigger classes. A trigger class
     specifies the condition under which a kernel MUST enter HEM_PENDING.
     Trigger classes are evaluated in the order defined below. The first
     trigger class that fires causes HEM_PENDING to be entered; the
     remaining classes are not evaluated for that transition.

  5.1.  Class 1: Cedar Policy Routing (HEM_CEDAR_ROUTED)

     A Cedar policy may explicitly route a transition to HEM rather than
     resulting in PERMIT or DENY. This is the primary mechanism by which
     governed object designers specify that certain transitions require
     human approval regardless of agent identity or scope.

     A Cedar policy routes to HEM by including the condition:

     when { context.hem_required == true }

     combined with a forbid rule that prevents autonomous execution. The
     kernel MUST recognize this pattern and MUST enter HEM_PENDING rather
     than returning DENY when Cedar evaluation produces this result.

     The kernel identifies HEM routing by evaluating whether a Cedar
     policy explicitly forbids the action AND the forbid rule includes
     a hem_required context attribute set to true. Implementations MAY
     use a Cedar annotation or action attribute to mark HEM-required
     transitions; the specific mechanism is implementation-defined,
     subject to the requirement that the kernel can unambiguously
     distinguish a HEM-routed DENY from a policy DENY.

     Example Cedar policy routing a transition to HEM:

     // Booking finalization requires human approval
     forbid(
       principal,
       action == Action::"FinalizeBooking",
       resource
     )
     when {
       context.hem_required == true &&
       !context.human_approval_present
     };

  5.2.  Class 2: Agent Uncertainty Declaration (HEM_AGENT_ESCALATED)

     An agent MAY declare, via the hem_urgency field of an IDP
     [I-D.sato-soos-idp], that it requires human judgment before an
     action executes. When the kernel receives a kernel.transition()
     call with a valid IDP containing hem_urgency: REQUIRED, the kernel
     MUST enter HEM_PENDING for the session, regardless of Cedar policy
     evaluation outcome.

     Note: Cedar evaluation still executes when hem_urgency is REQUIRED.
     A Cedar PERMIT result does NOT cause the action to execute. The
     kernel enters HEM_PENDING and the action awaits human decision.
     A Cedar DENY result in the same call produces both a HEM_PENDING
     entry AND a CEDAR_DENY_RECORDED Event Log entry.

     The HEM_AGENT_ESCALATED trigger represents a first-class agent
     capability. It is not a failure mode. Kernel implementations MUST
     treat agent-initiated escalation as a legitimate and expected system
     behaviour.

  5.3.  Class 3: Proximity Threshold Crossing (HEM_PROXIMITY_TRIGGERED)

     A governed object's configuration MAY include one or more Proximity
     Threshold declarations. A Proximity Threshold specifies a monitored
     condition that, when met, causes the kernel to enter HEM_PENDING
     regardless of any agent action being in progress.

     A Proximity Threshold declaration MUST specify:

     {
       "threshold_id":   string,  ; REQUIRED. UUID v4.
       "description":    string,  ; REQUIRED. Human-readable.
       "condition_type": string,  ; REQUIRED. See below.
       "condition_value": value,  ; REQUIRED. Type-specific.
       "hem_disposition": string  ; REQUIRED. "BLOCK" or "NOTIFY".
     }

     condition_type values:

     SO_STATE:
        The governed object enters the specified state.
        condition_value is a state name string.

     RESOURCE_THRESHOLD:
        A numeric resource value associated with the governed object
        crosses the specified threshold.
        condition_value is { "resource": string, "operator": string,
        "value": number }.

     EVENT_PATTERN:
        A specified event pattern appears in the Event Log for the
        governed object.
        condition_value is a pattern descriptor; the pattern language is
        implementation-defined.

     hem_disposition values:

     BLOCK:
        The kernel enters HEM_PENDING immediately. No transitions may
        execute until a human decision is received. This is the
        normative "stop" disposition.

     NOTIFY:
        The kernel routes an escalation notification to designated
        human principals but does NOT enter HEM_PENDING. Transitions
        may continue to execute. This disposition is appropriate for
        monitoring conditions that warrant human awareness but not
        intervention.

     Proximity Threshold evaluation MUST execute after each successful
     Event Log commitment, including after IDP_SUBMITTED events and after
     STATE_TRANSITIONED events. A kernel MUST NOT evaluate proximity
     thresholds only at action request time.

  5.4.  Class 4: Mission Validity Failure (HEM_MISSION_VALIDITY_FAILED)

     When the Mission Authority Service
     [I-D.mcguinness-oauth-mission-bound-authorization] reports that the
     governing MissionDeclaration has transitioned to a non-active phase
     (SUSPENDED, FAILED, or ABANDONED) while a session is otherwise
     active and no HEM_PENDING event is in progress, the kernel MUST
     enter HEM_PENDING so that a human principal can confirm terminal
     disposition before the session is closed.

     This trigger class is distinct from the mission validity monitoring
     described in Section 8.4. Section 8.4 governs the case where mission
     invalidity is detected while HEM_PENDING is already active.
     HEM_MISSION_VALIDITY_FAILED governs the initial HEM entry when
     mission invalidity is first detected in an otherwise HEM_INACTIVE
     session.

     The kernel MUST record HEM_TRIGGERED with trigger_class
     HEM_MISSION_VALIDITY_FAILED, including mission_ref and the terminal
     mission_phase value detected. The designated human principal
     designation chain for this trigger class is the mission-level
     principal chain, not the governed object principal chain.

     Decision constraints for HEM_MISSION_VALIDITY_FAILED: APPROVE and
     APPROVE_WITH_CONSTRAINTS MUST NOT be accepted. The valid decision
     types are TERMINATE, DEFER, and REDIRECT (cleanup-only actions
     only). The kernel MUST enforce this constraint and MUST return
     HEM_DECISION_INVALID for APPROVE or APPROVE_WITH_CONSTRAINTS
     submissions.


  5.5.  Class 5: Jurisdictional Conflict (HEM_JURISDICTIONAL_CONFLICT)

     When the kernel determines that it cannot algorithmically resolve a
     conflict between the legal requirements of two or more applicable
     jurisdictions -- such that no single authorized action set satisfies
     all applicable requirements simultaneously -- the kernel MUST enter
     HEM_PENDING with trigger_class HEM_JURISDICTIONAL_CONFLICT.

     The HEM Escalation Request for Class 5 MUST include a
     jurisdictional_conflict_summary object (Section 6.2). This object
     provides human principals with a structured summary of the
     conflicting jurisdictional requirements so that they may exercise
     informed judgment about the appropriate resolution.

     Decision constraints for HEM_JURISDICTIONAL_CONFLICT: APPROVE and
     APPROVE_WITH_CONSTRAINTS MUST NOT be accepted. The valid decision
     types are TERMINATE, DEFER, REDIRECT (subject to Cedar evaluation
     of the redirected action), and APPROVE_WITH_LEGAL_BASIS (reserved;
     see Section 7.1). The kernel MUST enforce this constraint and MUST
     return HEM_DECISION_INVALID for non-permitted decision types.

     The jurisdictional conflict resolution mechanism (JCR) is specified
     as Part II of [I-D.sato-soos-cap]. This document specifies only the
     HEM trigger and session contract for Class 5; the conflict analysis
     and resolution algorithm are defined in that document.


  5.6.  Policy Rationale Declaration (PRD)

     A Policy Rationale Declaration (PRD) is a kernel-registered object
     that links a Cedar policy routing transitions to HEM with machine-
     readable rationale. PRDs support regulatory transparency requirements
     (EU AI Act Article 13) and provide human principals with the policy
     basis for escalation events.

     A PRD MUST be registered with the kernel before the Cedar policy
     that references it is loaded. A Cedar policy that routes to HEM
     (Section 5.1) MUST carry a prd_id annotation referencing a
     registered PRD. The kernel MUST reject at load time any Cedar policy
     that routes to HEM and either lacks a prd_id annotation or
     references an unregistered prd_id. The rejection error is
     HEM_PRD_MISSING.

     A PRD object MUST contain the following fields:

     {
       "prd_id":         string, ; REQUIRED. UUID v4. Primary key.
       "rationale_class": string, ; REQUIRED. See IANA registry
                                  ;   Section 15.
       "rationale_text": string, ; REQUIRED. Human-readable rationale
                                  ;   for requiring human oversight.
       "authority_ref":  string, ; REQUIRED when rationale_class is
                                  ;   REGULATORY or CONTRACTUAL.
                                  ;   Citation of the regulation or
                                  ;   contract provision.
       "review_date":    string, ; REQUIRED. ISO 8601 date. The date
                                  ;   by which this PRD SHOULD be
                                  ;   reviewed.
       "review_overdue": boolean  ; REQUIRED. Kernel-set at escalation
                                  ;   request generation time. TRUE if
                                  ;   current date exceeds review_date.
     }

     The PRD store additionally retains the following administrative
     fields, which are NOT surfaced to human principals in the HEM
     Escalation Request: set_by (principal_id of registrant), set_at
     (ISO 8601 UTC registration timestamp), and policy_id (identifier
     of the Cedar policy referencing this PRD).

     The policy_rationale_id field in the HEM Escalation Request
     (Section 6.1) carries the prd_id of the PRD associated with the
     triggering Cedar policy. This field is REQUIRED on HEM_TRIGGERED
     Event Log entries for Class 1 triggers. The full PRD object is
     accessible to human principals via kernel.query_rationale().

     A PRD review_overdue value of TRUE MUST generate a
     PRD_REVIEW_DATE_EXCEEDED Audit Alert (Section 10) at escalation
     request generation time.


  5.7.  Extension Trigger Classes

     This document recognizes that operational experience may identify
     additional trigger classes beyond those defined in Sections 5.1
     through 5.5. Implementors MAY define additional trigger classes
     using a URI-prefixed identifier. Extension trigger classes MUST be
     submitted as an IDP with hem_urgency REQUIRED or as a kernel-
     internal event; they MUST NOT bypass the HEM_PENDING state machine.

     Implementors wishing to register extension trigger classes SHOULD
     do so via the IANA registry defined in Section 15.


  6.  HEM Escalation Request

  6.1.  Structure

     When a HEM trigger fires and the kernel enters HEM_PENDING, the
     kernel MUST construct and route a HEM Escalation Request. The
     escalation request is a JSON object:

     {
       "hem_id":          string,  ; REQUIRED. UUID v4. Unique HEM event ID.
       "so_id":           string,  ; REQUIRED. Governed object UUID.
       "session_id":      string,  ; REQUIRED. Agent session identifier.
       "mandate_id":      string,  ; REQUIRED. Active mandate JWT jti.
       "mission_ref":     string,  ; OPTIONAL. MissionDeclaration UUID if
                                   ;   session operates under a declared
                                   ;   mission. NULL if no MissionDeclaration
                                   ;   governs this session.
       "mission_phase":   string,  ; OPTIONAL. Current MissionDeclaration
                                   ;   phase at time of HEM trigger. Provided
                                   ;   to enable human principals to assess
                                   ;   whether the mission context remains
                                   ;   valid. NULL if mission_ref is NULL.
       "trigger_class":   string,  ; REQUIRED. One of the five defined
                                   ;   trigger classes (Section 5) or an
                                   ;   extension trigger class URI.
       "trigger_detail":  array,   ; REQUIRED. Typed array of trigger-class-
                                   ;   specific detail objects. See Section
                                   ;   8.3 for concurrent extension schema.
       "policy_rationale_id": string, ; REQUIRED for Class 1 triggers.
                                   ;   prd_id of the PRD associated with
                                   ;   the triggering Cedar policy.
                                   ;   NULL for other trigger classes.
       "jurisdictional_conflict_summary": object, ; REQUIRED when
                                   ;   trigger_class is
                                   ;   HEM_JURISDICTIONAL_CONFLICT.
                                   ;   NULL otherwise. See Section 6.2.
       "idp_summary": {            ; REQUIRED if IDP present; else null.
         "goal_description":  string,
         "reasoning_type":    string,
         "confidence_level":  number,
         "requested_action":  string,
         "mission_ref":       string  ; Echoed from triggering IDP.
       },
       "so_state_summary": {       ; REQUIRED.
         "current_state":           string,
         "phase":                   string,
         "available_actions_if_resolved": [string]
       },
       "principals":      [object], ; REQUIRED. Ordered designation chain.
       "timeout_seconds": integer,  ; REQUIRED. Per-principal timeout.
       "created_at":      string,   ; REQUIRED. ISO 8601 UTC.
       "kernel_signature": string,  ; REQUIRED. Ed25519 signature by the
                                   ;   kernel over the canonical
                                   ;   serialization of all other fields.
                                   ;   See Section 12.8.
       "metadata":        object    ; OPTIONAL. Implementation-defined.
     }

  6.2.  Field Definitions

     hem_id:
        A UUID v4 uniquely identifying this HEM event. Used as the
        primary key for all subsequent Event Log entries relating to
        this HEM lifecycle.

     mission_ref:
        OPTIONAL. The UUID of the MissionDeclaration governing the
        session at the time of the HEM trigger. When present, provides
        human principals with the mission context needed to evaluate
        whether the action under review is appropriate within the
        overarching mission. NULL if the session does not operate under
        a declared MissionDeclaration.

     mission_phase:
        OPTIONAL. The current phase of the MissionDeclaration identified
        by mission_ref at the time of the HEM trigger. Human principals
        use this field to assess whether the mission is still active.
        Possible values: DISCOVERY, EXECUTION, RELEASE, SUSPENDED,
        FAILED, ABANDONED. NULL if mission_ref is NULL. Human principals
        who receive an escalation request where mission_phase is
        SUSPENDED, FAILED, or ABANDONED SHOULD treat TERMINATE as the
        expected disposition unless there is specific reason to believe
        the mission state will be corrected.

     trigger_class:
        One of the five defined trigger classes (Section 5) or an
        extension trigger class URI.

     trigger_detail:
        A typed array of trigger-class-specific objects. The initial
        entry is populated at HEM trigger time. When a concurrent
        HEM_PENDING condition fires (Section 8.3), the kernel appends
        a new typed entry to this array. Each entry MUST contain:
        extension_type (string), extended_at (ISO 8601 UTC),
        trigger_source (string), and class-specific detail fields.
        For HEM_PROXIMITY_TRIGGERED entries: threshold_id,
        threshold_class, condition_met, triggered_at. See Section 13
        for minimisation requirements.

     policy_rationale_id:
        The prd_id of the PRD (Section 5.6) associated with the Cedar
        policy that triggered this HEM event. REQUIRED for Class 1
        triggers (HEM_CEDAR_ROUTED). NULL for all other trigger classes.
        Provides human principals with direct access to the machine-
        readable policy rationale via kernel.query_rationale(prd_id).

     jurisdictional_conflict_summary:
        REQUIRED when trigger_class is HEM_JURISDICTIONAL_CONFLICT.
        NULL otherwise. A structured object containing:
        {
          "jurisdictions": [string], ; ISO 3166-1 alpha-2 codes of the
                                     ;   conflicting jurisdictions.
          "conflict_description": string, ; Human-readable description.
          "conflicting_requirements": [object], ; One entry per
                                     ;   jurisdiction with fields:
                                     ;   jurisdiction, requirement_ref,
                                     ;   requirement_text.
          "resolution_methods_available": [string] ; From CAP JCR;
                                     ;   see [I-D.sato-soos-cap].
        }

     kernel_signature:
        An Ed25519 signature produced by the kernel over the canonical
        serialization of all other fields in the HEM Escalation Request.
        See Section 12.8. REQUIRED. Delivery intermediaries capable of
        verifying this signature MUST do so and MUST NOT forward the
        request if verification fails.

     idp_summary:
        A summary of the IDP submitted with the triggering action, if
        present. This provides human principals with context about what
        the agent was attempting to do. MUST be null if no IDP was
        associated with the trigger. The mission_ref field within
        idp_summary echoes the mission_ref from the triggering IDP;
        this allows principals to confirm that the IDP's declared mission
        matches the session's governing MissionDeclaration.

     so_state_summary:
        A summary of the governed object's current state, phase, and
        the Cedar actions that would be available to the agent if the
        HEM is resolved with APPROVE. This enables human principals
        to make informed decisions without requiring access to the full
        governed object record.

     principals:
        An ordered array of human principal descriptors forming the
        designation chain. Each element MUST contain:

        {
          "principal_id":   string, ; Party Registry identifier.
          "display_name":   string, ; Human-readable name.
          "contact":        object, ; Delivery contact; implementation-defined.
          "timeout_seconds": integer ; Per-principal timeout override. Optional.
        }

     timeout_seconds:
        The default per-principal timeout in seconds. If a principal
        descriptor includes a timeout_seconds override, the override
        applies for that principal. See Section 9.

  6.3.  Routing to Human Principals

     HEM does not specify the delivery mechanism. The kernel MUST
     deliver the escalation request to the first principal in the
     designation chain. The delivery mechanism is implementation-defined
     and MAY include:

     *  Push notification to a mobile application.
     *  Message delivery via a registered messaging endpoint (e.g.,
        the ATP Guest Agent [SOOS] uses WhatsApp Business API and
        LINE Messaging API as delivery channels).
     *  Email to a registered address.
     *  HTTP POST to a registered webhook.
     *  Any CHEQ-compatible [I-D.rosenberg-aiproto-cheq] confirmation
        delivery mechanism.

     The kernel MUST record the delivery attempt in the Event Log
     regardless of the delivery mechanism. The kernel MUST NOT consider
     delivery confirmed until an acknowledgment is received from the
     delivery channel. Delivery failure MUST trigger escalation to the
     next principal in the designation chain without waiting for the
     per-principal timeout to expire.


  7.  Human Decision Types

     A human principal responds to a HEM Escalation Request with one of
     five decision types. The kernel MUST accept only these five decision
     types as valid HEM resolutions. Any response that does not conform
     to one of these types MUST be rejected by the kernel with a
     HEM_DECISION_INVALID error.

     No HEM decision type substitutes for Cedar policy evaluation.
     APPROVE and APPROVE_WITH_CONSTRAINTS authorize the kernel to proceed
     to Cedar evaluation for the triggering action; they do not override
     it. A Cedar DENY result following an APPROVE or APPROVE_WITH_
     CONSTRAINTS decision takes precedence over the human decision; the
     action does not execute, and the kernel returns an Enriched DENY
     Response [I-D.sato-soos-idp] to the agent. This property is the
     normative separation between human judgment (was this action
     appropriate in context?) and policy enforcement (is this action
     permitted?). These two questions have different authorities and
     MUST NOT be collapsed.

  7.1.  APPROVE

     The human principal approves the requested action and authorizes the
     agent to proceed.

     Kernel behaviour upon receiving APPROVE:
     *  The kernel MUST record HEM_DECISION_RECEIVED(APPROVE) in the
        Event Log.
     *  The kernel MUST execute the Cedar policy evaluation for the
        action that triggered the HEM. If Cedar PERMIT results, the
        action MUST execute. If Cedar DENY results, the DENY takes
        precedence; APPROVE does not override Cedar policy (see Section
        7 preamble).
     *  The session transitions to HEM_RESOLVED and then HEM_INACTIVE.

     Note: APPROVE is not a Cedar override. It is a signal that the
     human principal has reviewed the situation and considers the action
     appropriate within the governing mission and policy context. If the
     action is Cedar-denied for reasons unrelated to the HEM trigger,
     the denial stands.

  7.2.  APPROVE_WITH_CONSTRAINTS

     The human principal approves the requested action subject to
     specified constraints. Constraints are expressed as additional
     Cedar context attributes injected into the subsequent Cedar
     evaluation.

     APPROVE_WITH_CONSTRAINTS MUST include a constraints object:

     {
       "decision": "APPROVE_WITH_CONSTRAINTS",
       "constraints": {
         "cedar_context_additions": object, ; Additional Cedar context.
         "expiry_seconds":  integer,        ; OPTIONAL. Constraint validity
                                            ;   window in seconds from
                                            ;   HEM_DECISION_RECEIVED.
         "description":     string          ; Human-readable summary.
       }
     }

     Kernel behaviour:
     *  The kernel MUST record HEM_DECISION_RECEIVED(APPROVE_WITH_
        CONSTRAINTS) in the Event Log, including the full constraints
        object.
     *  The kernel MUST inject the cedar_context_additions into the Cedar
        context for the subsequent action evaluation.
     *  Expiry semantics: expiry_seconds governs action initiation, not
        completion. Transitions for which initiation begins before the
        expiry window closes MUST be permitted to complete. Transitions
        for which initiation has not begun when the expiry window closes
        MUST be evaluated without the constraint additions; Cedar context
        returns to the pre-constraint state. Initiation time is recorded
        as the timestamp of the kernel.transition() call.
     *  When an initiation attempt is rejected due to constraint expiry,
        the kernel MUST return HEM_CONSTRAINT_EXPIRED. The expiry time
        is recorded against hem_id, not individual transitions.
     *  The session transitions to HEM_RESOLVED and then HEM_INACTIVE.

  7.3.  REDIRECT

     The human principal does not approve the requested action but
     authorizes the agent to take a different specified action instead.

     REDIRECT MUST include a redirect object:

     {
       "decision": "REDIRECT",
       "redirect": {
         "action":      string, ; Cedar action string for the new action.
         "description": string  ; Human-readable rationale.
       }
     }

     Kernel behaviour:
     *  The kernel MUST record HEM_DECISION_RECEIVED(REDIRECT) in the
        Event Log.
     *  The kernel MUST evaluate the redirected action against Cedar
        policy. If Cedar PERMIT results, the redirected action executes.
        If Cedar DENY results, the kernel returns HEM_REDIRECT_DENIED
        and an Enriched DENY Response [I-D.sato-soos-idp] to the
        submitting principal. HEM does NOT re-trigger automatically on
        Cedar DENY of a REDIRECT; there is no normative default retrigger.
        A REDIRECT_DENY_RETRIGGER extension may be defined in future work.
     *  When Cedar DENY follows REDIRECT, the principal's decision slot
        is NOT consumed. The principal MAY submit a new decision within
        the same active HEM event. This permits iterative resolution
        without requiring a new HEM lifecycle.
     *  The original requested action MUST NOT execute.
     *  When Cedar PERMIT follows REDIRECT, the session transitions to
        HEM_RESOLVED and then HEM_INACTIVE.

  7.4.  TERMINATE

     The human principal terminates the agent session. The session is
     immediately closed. No further agent actions may be executed in
     this session.

     Kernel behaviour upon receiving TERMINATE. The following steps MUST
     be executed in the order specified. Steps 1 and 2 are atomic: both
     MUST be committed before HEM_DECISION_ACCEPTED is returned to any
     caller. Step 3 executes after the atomic completion of Steps 1
     and 2.

     Step 1 -- Mandate revocation:
     *  The kernel MUST record HEM_DECISION_RECEIVED(TERMINATE) in the
        Event Log.
     *  The mandate JWT associated with this session MUST be revoked.
        Revocation MUST propagate to all relying parties before any
        further agent calls are accepted on that mandate.
     *  The principal who issued TERMINATE MUST be recorded by
        principal_id in the Event Log.

     Step 2 -- Mission cascade (atomic with Step 1):
     *  If the session is associated with a governing MissionDeclaration
        and is the sole active session under that MissionDeclaration, the
        kernel MUST initiate MISSION_REVOKE_CASCADE. Steps 1 and 2 MUST
        both be committed -- mandate revocation completed AND
        MISSION_REVOKE_CASCADE initiated -- before HEM_DECISION_ACCEPTED
        is returned. No further calls on related mandates are accepted
        until both commitments are complete.
     *  The semantics of MISSION_REVOKE_CASCADE are defined in [SOOS]
        Section 10. HEM TERMINATE is one normative trigger for that
        protocol.

     Step 3 -- Governed object disposition (after atomic completion):
     *  The kernel MUST apply the SO Type's defined termination
        disposition for the governed object's current state. The SO Type
        MUST define a termination disposition for each state in which
        SESSION_TERMINATED is reachable.
     *  The kernel MUST enter SESSION_TERMINATED state.

     A TERMINATE decision for a Class 5 trigger (HEM_JURISDICTIONAL_
     CONFLICT) MUST be accompanied by a Decision Rationale Record (DRR)
     with safety_basis populated (Section 7.6). The kernel MUST reject
     a TERMINATE decision on a Class 5 trigger that lacks a DRR with
     HEM_DRR_REQUIRED.

  7.5.  DEFER

     The human principal is unable to decide at this moment and requests
     that the HEM timeout be extended. This decision type acknowledges
     the situation without resolving it.

     DEFER MUST include a defer object:

     {
       "decision": "DEFER",
       "defer": {
         "extension_seconds": integer, ; REQUIRED. Additional seconds.
         "reason":            string   ; REQUIRED. Human-readable.
       }
     }

     Kernel behaviour:
     *  The kernel MUST record HEM_DECISION_RECEIVED(DEFER) in the
        Event Log.
     *  The kernel MUST extend the remaining timeout by extension_seconds.
     *  The session remains in HEM_PENDING.
     *  The kernel SHOULD deliver a re-notification to the same principal
        when the extended timeout has 20% remaining.

     Limits:
     *  A single DEFER extension MUST NOT exceed the original per-principal
        timeout_seconds for this HEM event.
     *  DEFER is limited to one per principal per hem_id. The limit is
        scoped independently for each principal: a DEFER by Principal A
        does not affect Principal B's DEFER availability. Escalation
        through the chain does not affect prior principals' DEFER records.
        The timeout countdown does not consume a principal's DEFER -- only
        a submitted DEFER decision does.
     *  A second DEFER from the same principal on the same hem_id MUST be
        rejected with HEM_DEFER_LIMIT_EXCEEDED.

  7.6.  Decision Rationale Record (DRR)

     A Decision Rationale Record (DRR) captures the human principal's
     reasoning for a HEM decision. DRRs support regulatory transparency
     requirements (EU AI Act Article 13) and provide an auditable record
     of human judgment in the governance trail.

     A DRR is REQUIRED for TERMINATE decisions. A DRR SHOULD be provided
     for APPROVE_WITH_CONSTRAINTS decisions. A DRR MAY be provided for
     any decision type. The kernel MUST reject a TERMINATE decision that
     lacks a DRR or that includes a DRR in which safety_basis is null,
     with error HEM_DRR_REQUIRED.

     A DRR object MUST contain the following fields:

     {
       "rationale_class": string, ; REQUIRED. See IANA registry
                                  ;   Section 15.
       "rationale_text":  string, ; REQUIRED when DRR is required.
                                  ;   Human-readable description of
                                  ;   the principal's reasoning.
       "safety_basis":    string, ; REQUIRED for TERMINATE; null
                                  ;   otherwise. Describes the safety
                                  ;   or risk basis for the decision
                                  ;   to terminate the session.
       "reference_ref":   string  ; OPTIONAL. Reference identifier
                                  ;   (e.g., incident ID, regulation
                                  ;   citation, contract clause) for
                                  ;   any decision type. Included to
                                  ;   support APPROVE_WITH_LEGAL_BASIS
                                  ;   when that decision type becomes
                                  ;   operational.
     }

     The kernel MUST validate the presence of required fields. The kernel
     MUST NOT validate the content quality of rationale_text or
     safety_basis. Content sufficiency is a human governance matter.

     DRRs are committed to the Rationale Store, a separate kernel-managed
     object store. DRRs are immutable on commit. The Event Log carries
     drr_id as a foreign key on HEM_DECISION_RECEIVED entries where a
     DRR is present. DRRs are accessible via kernel.query_rationale().
     The Session Audit Record (SAR) includes a rationale coverage summary
     counting decisions with and without DRRs.

     The non-normative advisory in Section 14 maps DRR rationale_class
     and safety_basis to EU AI Act Article 13 transparency requirements.


  7.7.  Decision Submission Protocol

     Human decisions are submitted to the kernel via a decision endpoint.
     The submission MUST include:

     {
       "hem_id":        string, ; REQUIRED. Must match active HEM event.
       "principal_id":  string, ; REQUIRED. Party Registry identifier.
       "decision":      string, ; REQUIRED. One of the five types.
       "decision_data": object, ; REQUIRED for types with data objects.
       "drr":           object, ; REQUIRED for TERMINATE; OPTIONAL
                                ;   otherwise. See Section 7.6.
       "timestamp":     string, ; REQUIRED. ISO 8601 UTC.
       "signature":     string  ; REQUIRED. Principal's Ed25519 signature
                                ;   over hem_id + principal_id + decision
                                ;   + timestamp.
     }

     The kernel MUST verify the signature before processing the decision.
     The signing key MUST correspond to the principal's registered key
     in the Party Registry. A decision submitted with an invalid
     signature MUST be rejected with HEM_SIGNATURE_INVALID.

     The kernel MUST accept decisions only from principals listed in the
     designation chain for the active HEM event. A decision from an
     unlisted principal MUST be rejected with HEM_PRINCIPAL_NOT_AUTHORIZED.


  8.  Transition Prohibition During HEM_PENDING

  8.1.  The Prohibition Rule

     While a session is in HEM_PENDING state, the kernel MUST reject all
     kernel.transition() calls with error code HEM_PENDING_ACTIVE. This
     prohibition is absolute and applies regardless of:

     *  The Cedar policy evaluation outcome for the requested action.
     *  The identity of the requesting agent.
     *  The mandate JWT presented.
     *  The IDP submitted with the call.

     The transition prohibition is the primary safety property of HEM.
     It guarantees that no governed object state changes occur while a
     human oversight event is in progress. Implementations MUST enforce
     this prohibition at the kernel layer, prior to Cedar evaluation.

  8.2.  Read-Only Operations During HEM_PENDING

     The following operations are PERMITTED during HEM_PENDING:

     *  kernel.query_state() -- reading the current governed object state.
     *  kernel.query_event_log() -- reading the Event Log.
     *  kernel.query_hem_status() -- reading the status of the active
        HEM event, including which principals have been notified and
        the remaining timeout.
     *  kernel.list_available_actions() -- listing Cedar-permitted actions
        for planning purposes (agents may plan during HEM_PENDING even
        though they may not act).

     These operations do not modify governed object state and are
     therefore not subject to the transition prohibition.

  8.3.  Multiple Concurrent HEM_PENDING Conditions

     A governing kernel MAY support multiple concurrent HEM events for
     distinct governed objects. Each governed object's HEM state is
     independent.

     A single governed object MUST NOT have more than one active
     HEM_PENDING event at a time. If a proximity threshold fires while
     an agent-escalated HEM is already pending for the same governed
     object, the kernel MUST record the proximity threshold crossing in
     the Event Log and MUST extend the existing HEM event's context to
     include the proximity trigger detail. A second HEM event MUST NOT
     be created.

     Context extension uses the trigger_detail typed array (Section 6.1).
     Each context extension appends a new typed entry to the array. The
     entry MUST contain:

     {
       "extension_type":        string, ; REQUIRED. Trigger class of the
                                        ;   extending condition.
       "extended_at":           string, ; REQUIRED. ISO 8601 UTC.
       "trigger_source":        string, ; REQUIRED. Identifier of the
                                        ;   threshold or event that fired.
       "proximity_detail":      object, ; REQUIRED for HEM_PROXIMITY_
                                        ;   TRIGGERED extensions.
                                        ;   See Section 13 for
                                        ;   minimisation requirements.
       "timeout_extension_seconds": integer ; OPTIONAL. Additional seconds
                                        ;   to add to the current timeout
                                        ;   budget. Pre-declared by the
                                        ;   SO Type designer in the
                                        ;   proximity threshold config.
                                        ;   The timeout budget does NOT
                                        ;   reset automatically.
     }

     When a context extension occurs, the kernel MUST re-deliver the
     updated HEM Escalation Request to the active principal via the same
     delivery channel. The principal's decision slot is NOT reset by a
     context extension. The kernel MUST record HEM_CONTEXT_EXTENDED in
     the Event Log with: hem_id, extension_type, trigger_source,
     extended_at, and timeout_extension_seconds (if applicable).

  8.4.  Mission Validity During HEM_PENDING

     A session in HEM_PENDING state may be associated with a governing
     MissionDeclaration [SOOS]. While HEM_PENDING is active, the kernel
     MUST monitor mission validity. If the governing MissionDeclaration
     transitions to phase SUSPENDED, FAILED, or ABANDONED during the
     HEM_PENDING period:

     (a)  The kernel MUST enter HEM_CHAIN_EXHAUSTED state with disposition
          TERMINATE_SESSION, regardless of whether the designation chain
          has been exhausted.

     (b)  The kernel MUST record a HEM_MISSION_INVALID event in the Event
          Log containing: hem_id, mission_ref, mission_phase (the terminal
          phase that was detected), and timestamp.

     (c)  Outstanding human principal notifications MUST be cancelled.
          The kernel MUST notify principals who have already received a
          notification that the session has been terminated due to mission
          invalidation. The cancellation notification is recorded as
          HEM_NOTIFICATION_CANCELLED in the Event Log.

     (d)  The TERMINATE disposition applies as defined in Section 7.4,
          including mandate JWT revocation and MISSION_REVOKE_CASCADE if
          the session is the sole active session under the
          MissionDeclaration.

     This provision closes the ghost execution failure mode: a valid HEM
     event does not imply that the underlying mission for which the agent
     was operating is still active. A valid mandate JWT + valid HEM event
     does not imply a legitimate ongoing mission.

     Note: This section applies only when HEM_PENDING is already active
     and the mission phase changes during the wait. The case where mission
     invalidity is first detected in an otherwise active session (no
     existing HEM event) is addressed by the Class 4 extension trigger
     class defined in Section 5.4.


  9.  Timeout Model

  9.1.  Timeout Budget

     Each principal in the designation chain is allocated a timeout
     budget. The default timeout_seconds is specified in the HEM
     Escalation Request (Section 6.1). A per-principal override MAY
     be specified in the principal descriptor.

     The timeout clock for a principal begins when the kernel delivers
     the escalation request to that principal (or records a delivery
     attempt, if delivery is not confirmed).

     The minimum timeout_seconds is 60. A HEM configuration specifying
     a timeout_seconds less than 60 MUST be rejected by the kernel at
     configuration time.

  9.2.  Timeout Disposition

     When a principal's timeout budget is exhausted without receipt of
     a valid decision, the kernel MUST apply one of the following
     timeout dispositions. The disposition MUST be pre-declared in the
     governed object's HEM configuration; it MUST NOT be determined
     at timeout time.

     ESCALATE_CHAIN:
        Escalate to the next principal in the designation chain. This
        is the default disposition when the chain has not been exhausted.

     SUSPEND:
        Place the governed object in BOOKING_SUSPENDED state (or the
        equivalent suspended state for the SO Type). The session
        remains in HEM_PENDING. A governance recovery process must
        manually resolve the suspension.

     TERMINATE_SESSION:
        Apply the TERMINATE decision semantics (Section 7.4). The
        session ends; the mandate JWT is revoked; the SO Type's
        termination disposition applies.

     AUTO_APPROVE:
        Approve the triggering action and proceed as if APPROVE had
        been received. This disposition is Cedar-gated: the kernel MUST
        perform a Cedar policy evaluation before applying AUTO_APPROVE.
        If Cedar evaluation returns DENY, the AUTO_APPROVE disposition
        MUST NOT apply; the kernel MUST instead apply the SUSPEND
        disposition and record HEM_AUTO_APPROVE_CEDAR_DENIED in the
        Event Log. This ensures that AUTO_APPROVE cannot be used to
        bypass Cedar policy.

        Hard prohibition: AUTO_APPROVE MUST NOT be available for
        transition classes designated as high-value in the SO Type
        configuration, regardless of Cedar evaluation outcome. The
        kernel MUST enforce this prohibition at SO Type configuration
        load time by rejecting any HEM configuration that specifies
        AUTO_APPROVE for a high-value transition class. The rejection
        error is HEM_AUTO_APPROVE_PROHIBITED.

        AUTO_APPROVE MUST NOT be used for HEM_CEDAR_ROUTED triggers.
        It MAY be used for HEM_PROXIMITY_TRIGGERED triggers with
        hem_disposition: NOTIFY. Implementations SHOULD discourage this
        disposition for high-value transitions.

  9.3.  Timeout Chain (HEM_UNREACHABLE)

     When the disposition is ESCALATE_CHAIN and the chain has not been
     exhausted, the kernel enters HEM_TIMEOUT state briefly, records
     HEM_PRINCIPAL_TIMEOUT in the Event Log, and immediately re-enters
     HEM_PENDING with the next principal as the active target.

     A notification MUST be delivered to the next principal within 30
     seconds of the prior principal's timeout.

     The kernel MUST record in the Event Log for each principal in the
     chain:

     *  HEM_NOTIFICATION_SENT (with principal_id and timestamp)
     *  HEM_NOTIFICATION_DELIVERED or HEM_NOTIFICATION_UNDELIVERED
     *  HEM_PRINCIPAL_TIMEOUT (if timeout elapsed without decision)

  9.4.  Chain Exhaustion

     If all principals in the designation chain have timed out without
     providing a valid decision, the kernel enters HEM_CHAIN_EXHAUSTED
     state. The kernel MUST apply the pre-declared chain exhaustion
     disposition.

     The chain exhaustion disposition is specified separately from the
     per-principal timeout disposition and MUST be one of:

     SUSPEND:
        As defined in Section 9.2. Recommended default for most SO Types.

     TERMINATE_SESSION:
        As defined in Section 9.2.

     The chain exhaustion disposition MUST be declared in the governed
     object's HEM configuration. A HEM configuration without a chain
     exhaustion disposition MUST default to SUSPEND.


  10.  Event Log Requirements

     A conforming kernel MUST record the following events in the Event Log
     for each HEM lifecycle. All events MUST be kernel-signed
     [I-D.sato-soos-gar].

     Event sequence for a complete HEM lifecycle:

     HEM_TRIGGERED
        Fields: hem_id, trigger_class, trigger_detail (initial entry),
        so_id, session_id, mandate_id, mission_ref (if present),
        policy_rationale_id (REQUIRED for Class 1 triggers; null
        otherwise), timestamp.

     HEM_NOTIFICATION_SENT (one per principal notified)
        Fields: hem_id, principal_id, delivery_mechanism, timestamp.

     HEM_NOTIFICATION_DELIVERED or HEM_NOTIFICATION_UNDELIVERED
        Fields: hem_id, principal_id, timestamp.

     HEM_DECISION_RECEIVED
        The following nine fields are REQUIRED on all HEM_DECISION_
        RECEIVED entries:
           hem_id, session_id, mandate_id, trigger_class,
           principal_type, principal_id, trigger_source,
           decision_type, created_at.
        Additionally: decision_rationale_class is REQUIRED when a DRR
        is mandatory for the decision type; OPTIONAL otherwise.
        policy_rationale_id SHOULD be recorded. drr_id SHOULD be
        recorded when a DRR is submitted.

     HEM_RESOLVED or HEM_TIMEOUT or HEM_CHAIN_EXHAUSTED
        Fields: hem_id, final_state, applied_disposition (if timeout
        or chain exhaustion), timestamp.

     In addition, each of the following MUST be recorded when applicable:

     HEM_CONTEXT_EXTENDED  (Section 8.3)
        Fields: hem_id, extension_type, trigger_source, extended_at,
        timeout_extension_seconds (if applicable).

     HEM_PRINCIPAL_TIMEOUT
        Fields: hem_id, principal_id, elapsed_seconds, timestamp.

     HEM_DEFER_RECEIVED
        Fields: hem_id, principal_id, extension_seconds, timestamp.

     HEM_DECISION_REJECTED
        Fields: hem_id, rejection_code, submitter_info, timestamp.

     HEM_MISSION_INVALID  (Section 8.4)
        Fields: hem_id, mission_ref, mission_phase (terminal phase
        detected), timestamp.

     HEM_NOTIFICATION_CANCELLED  (Section 8.4)
        Fields: hem_id, principal_id, reason, timestamp.

     HEM_MISSION_REF_MISMATCH_REJECTED  (Section 11)
        Fields: hem_id, session_id, idp_id, expected_mission_ref,
        submitted_mission_ref, timestamp.

     CONSTITUTIONAL_VIOLATION  (when CAP Tier 0 or Tier 1 refusal
        applies during HEM_PENDING processing)
        Fields: hem_id, violation_class, tier, timestamp.
        Generates a CRITICAL Audit Alert [I-D.sato-soos-gar].

     The Event Log ordering guarantee for a HEM lifecycle is:

     HEM_TRIGGERED < HEM_NOTIFICATION_SENT <
     HEM_DECISION_RECEIVED < HEM_RESOLVED

     No STATE_TRANSITIONED event for the governed object may appear in
     the Event Log between HEM_TRIGGERED and HEM_RESOLVED (or
     HEM_TIMEOUT, HEM_CHAIN_EXHAUSTED) events. This is the Event Log
     expression of the transition prohibition in Section 8.

     The Session Audit Record (SAR) for a governed object session is
     generated by the kernel at session close and includes a reference
     array hem_events[] carrying the hem_id of each HEM lifecycle in
     that session. SAR specification is defined in [I-D.sato-soos-gar].


  11.  Relationship to IDP

     The IDP [I-D.sato-soos-idp] and HEM are co-operating kernel
     primitives. Their relationship is as follows:

     *  An IDP with hem_urgency: REQUIRED triggers HEM_AGENT_ESCALATED
        (Section 5.2). The IDP idp_id is recorded in the HEM trigger
        detail.

     *  The idp_summary field of the HEM Escalation Request (Section 6.1)
        is derived from the triggering IDP. Human principals receive
        the agent's declared goal, reasoning type, confidence level, and
        requested action as part of the escalation context. The
        mission_ref field within idp_summary is echoed from the triggering
        IDP's mission_ref field, enabling principals to confirm mission
        context consistency.

     *  Mission_ref mismatch: The kernel MUST verify that the mission_ref
        field in each incoming IDP matches the mission_ref of the governing
        session MissionDeclaration. On mismatch, the kernel MUST reject
        the IDP and return an Enriched DENY Response [I-D.sato-soos-idp]
        containing mismatch_detail with expected_mission_ref and
        submitted_mission_ref values. The kernel MUST log
        HEM_MISSION_REF_MISMATCH_REJECTED (Section 10). If mismatches
        from the same session exceed a configurable threshold, the kernel
        SHOULD automatically trigger HEM_AGENT_ESCALATED (Class 2).

     *  IDP_COMMITMENT_GAP: When the IDP Commitment Verification Record
        [I-D.sato-soos-idp] detects that the agent's actual action
        diverged from its declared intent (IDP_COMMITMENT_GAP), the
        kernel MUST automatically trigger HEM_AGENT_ESCALATED (Class 2).
        This trigger is non-suppressible. IDP_COMMITMENT_GAP also
        generates a CRITICAL Audit Alert [I-D.sato-soos-gar].

     *  Following HEM_RESOLVED with a REDIRECT decision, the agent MUST
        submit a new IDP for the redirected action before the kernel
        will execute it. The new IDP SHOULD reference the HEM hem_id
        in context_refs.

     *  Following HEM_RESOLVED with APPROVE or APPROVE_WITH_CONSTRAINTS,
        the agent MAY re-execute its original action. It MUST submit
        the original IDP's goal_id in the new IDP's declared_goal to
        provide continuity of audit trail.

     *  The Event Log ordering between IDP and HEM events is:

        IDP_SUBMITTED < HEM_TRIGGERED < HEM_RESOLVED <
        STATE_TRANSITIONED


  12.  Security Considerations

  12.1.  HEM_PENDING as a Denial-of-Service Vector

     The transition prohibition during HEM_PENDING (Section 8.1) means
     that any attacker who can trigger HEM on a governed object can
     prevent state transitions for the duration of the HEM event.
     Implementations MUST rate-limit HEM_AGENT_ESCALATED triggers from
     any single agent session. Implementations SHOULD apply anomaly
     detection to frequent HEM triggers from the same agent.

  12.2.  Decision Signature Verification

     Human principal decisions MUST be signature-verified (Section 7.7).
     A kernel that processes unsigned decisions enables an attacker who
     can inject messages into the delivery channel to resolve HEM events
     arbitrarily. The signature requirement over the concatenation of
     hem_id, principal_id, decision, and timestamp prevents replay of
     prior decisions.

  12.3.  Designation Chain Confidentiality

     The designation chain in the HEM Escalation Request contains
     personal contact information for human principals. The escalation
     request MUST NOT be accessible to the requesting agent. The kernel
     routes the request; the agent receives only HEM_PENDING_ACTIVE as
     the response to its transition call.

  12.4.  TERMINATE Decision Integrity

     The TERMINATE decision (Section 7.4) immediately ends the agent
     session and revokes the mandate JWT. The three-step atomicity
     ordering (Section 7.4) ensures that mandate revocation and
     MISSION_REVOKE_CASCADE initiation are both committed before any
     caller receives HEM_DECISION_ACCEPTED. Implementations MUST enforce
     this ordering guarantee. Race conditions in mandate revocation
     propagation MUST be mitigated by implementing the relying-party
     propagation fence described in [SOOS] Section 10.

  12.5.  Timeout Configuration

     AUTO_APPROVE as a timeout disposition (Section 9.2) has significant
     security implications. The Cedar-gating requirement (Section 9.2)
     mitigates the risk of unauthorized approval but does not eliminate
     it. Implementations MUST additionally enforce the hard prohibition
     on AUTO_APPROVE for high-value transition classes at configuration
     load time. Implementations MUST log a configuration warning when
     AUTO_APPROVE is configured for any transition class. Auto-approval
     SHOULD NOT be permitted for governed objects classified as high-risk
     under EU AI Act Annex III.

  12.6.  Proximity Threshold Injection

     An attacker with the ability to modify a governed object's proximity
     threshold configuration can trigger HEM at will. Threshold
     configuration MUST be protected by the same access controls as the
     governed object's mandate configuration. Changes to threshold
     configuration MUST be recorded in the Event Log with the identity
     of the principal making the change.

  12.7.  Mission Validity Monitoring

     The mission validity monitoring described in Section 8.4 requires
     the kernel to receive reliable signals about MissionDeclaration
     phase changes. Implementations MUST ensure that the channel by
     which mission phase updates reach the kernel is authenticated and
     tamper-evident. An attacker who can inject false SUSPENDED or
     ABANDONED phase signals can trigger spurious session termination.

  12.8.  Escalation Request Signing

     The kernel MUST sign the full HEM Escalation Request using Ed25519,
     using the same key model as the Mandate JWT. The signature MUST
     cover the canonical serialization of all fields in the escalation
     request other than kernel_signature itself. The resulting signature
     value is placed in the kernel_signature field (Section 6.1).

     The verification key is available via the operator's JWKS endpoint,
     using the same key discovery mechanism as for Mandate JWT
     verification. Delivery intermediaries that are capable of verifying
     Ed25519 signatures MUST verify the kernel_signature before
     forwarding the escalation request. A delivery intermediary MUST NOT
     forward an escalation request on which signature verification fails.

     Non-normative advisory: delivery channels that cannot perform
     Ed25519 verification (e.g., plain messaging channels without
     cryptographic processing capability) MAY forward without
     verification, but implementations using such channels SHOULD be
     aware that the escalation request integrity guarantee does not
     extend to the final delivery hop. Operators SHOULD prefer delivery
     channels capable of end-to-end verification.


  13.  Privacy Considerations

     HEM escalation requests contain information about agent actions,
     governed object state, and agent-declared goals derived from the IDP.
     Implementors MUST ensure that escalation notifications delivered to
     human principals do not contain personally identifiable information
     beyond what is necessary for the principal to make an informed
     decision.

     The idp_summary included in escalation requests (Section 6.1) MUST
     be filtered to remove any PII from the declared_goal.description
     field before delivery. The full IDP text MUST NOT be included in
     the delivery payload.

     Trigger_detail minimisation: The trigger_detail array entries for
     HEM_PROXIMITY_TRIGGERED conditions MUST contain only the following
     fields: threshold_id, threshold_class, condition_met, triggered_at.
     The trigger_detail MUST NOT contain: personal data, Zone B content,
     traveller identity attributes beyond principal_id, raw telemetry
     data, or raw sensor readings. The kernel MUST enforce these
     minimisation requirements at escalation request generation time,
     before the request is constructed. Proximity detail that exceeds
     this enumeration MUST be retained in the kernel Event Log (where
     access is controlled) and MUST NOT be propagated to the escalation
     request.

     Designation chain contact information (principal contact objects)
     MUST be stored and transmitted in compliance with applicable data
     protection regulations. The contact objects MUST NOT be logged in
     plaintext; implementations SHOULD log only principal_id and delivery
     mechanism type in the Event Log.

     The tension between Event Log immutability and data subject erasure
     rights is noted; this document defers to the SOOS Kernel
     Specification [SOOS] cryptographic erasure provisions.


  14.  EU AI Act Applicability

     This section provides normative and advisory Article mappings.
     The normative mappings in this section are designed for direct
     reference in EU AI Act conformance documentation. This document
     does not constitute legal advice and makes no representation that
     conforming implementations satisfy any regulatory requirement.

     +--------+---------------------------+---------------------------+----------+
     |Article |Requirement                |HEM Implementation         |Mapping   |
     +--------+---------------------------+---------------------------+----------+
     |Art. 5  |Prohibited AI practices    |CAP Tier 0/1 CEE           |Normative |
     |        |                           |[I-D.sato-soos-cap]        |          |
     +--------+---------------------------+---------------------------+----------+
     |Art. 12 |Automatic logging          |Event Log (Section 10);    |Normative |
     |        |                           |SAR [I-D.sato-soos-gar];   |          |
     |        |                           |IDP pre-action intent      |          |
     |        |                           |[I-D.sato-soos-idp].       |          |
     |        |                           |Event Log retention SHOULD |          |
     |        |                           |be minimum 12 months.      |          |
     |        |                           |Operators may reference    |          |
     |        |                           |this section and           |          |
     |        |                           |[I-D.sato-soos-gar]        |          |
     |        |                           |Section 10 directly in     |          |
     |        |                           |conformance documentation. |          |
     +--------+---------------------------+---------------------------+----------+
     |Art. 13 |Transparency               |PRD rationale_class and    |Advisory  |
     |        |                           |review_date (Section 5.6); |          |
     |        |13(3)(b): AI system        |DRR rationale_class        |          |
     |        |capabilities and limits    |(Section 7.6).             |          |
     |        |13(3)(e): Human oversight  |DRR safety_basis REQUIRED  |          |
     |        |measures                   |for TERMINATE.             |          |
     +--------+---------------------------+---------------------------+----------+
     |Art. 14 |Human oversight            |HEM_PENDING + transition   |Normative |
     |        |                           |prohibition (Section 8);   |          |
     |        |14(1): Effective oversight |Designation chain and      |          |
     |        |by natural persons         |timeout model (Section 9). |          |
     |        |                           |                           |          |
     |        |14(4)(b): Awareness of     |Five decision types        |Normative |
     |        |tendency to over-rely on   |(Section 7); DRR captures  |          |
     |        |output                     |human reasoning.           |          |
     |        |                           |                           |          |
     |        |14(4)(c): Interpret output |idp_summary in Escalation  |Normative |
     |        |correctly                  |Request (Section 6.1);     |          |
     |        |                           |IDP CVR anomaly detection  |          |
     |        |                           |[I-D.sato-soos-idp].       |          |
     |        |                           |                           |          |
     |        |14(4)(d): Decide not to    |HEM_PENDING transition     |Normative |
     |        |use output in any          |prohibition (Section 8.1); |          |
     |        |particular situation       |TERMINATE decision type    |          |
     |        |                           |(Section 7.4).             |          |
     +--------+---------------------------+---------------------------+----------+

     Note on Article 14(4)(d): This provision requires that human
     oversight persons be able to decide not to use the AI system output
     in any particular situation and not to be unduly influenced by it.
     The HEM_PENDING transition prohibition (Section 8.1) implements
     the technical stop capability; TERMINATE (Section 7.4) implements
     the irrevocable session closure. Both are kernel-enforced and
     non-bypassable by agent or application.


  15.  IANA Considerations

     This document requests the creation of the following IANA registry:

     Registry Name:
        Human Escalation Mechanism Trigger Classes

     Registration Procedure:
        Standards Action [RFC8126]

     Initial Values:

     +--------------------------------+----------------------------------+
     | Trigger Class                  | Description                      |
     +--------------------------------+----------------------------------+
     | HEM_CEDAR_ROUTED               | Cedar policy routes to HEM       |
     | HEM_AGENT_ESCALATED            | Agent declares hem_urgency:      |
     |                                | REQUIRED in IDP                  |
     | HEM_PROXIMITY_TRIGGERED        | Proximity threshold crossed      |
     | HEM_MISSION_VALIDITY_FAILED    | MissionDeclaration in terminal   |
     |                                | phase; active session detected   |
     | HEM_JURISDICTIONAL_CONFLICT    | Kernel cannot resolve cross-     |
     |                                | jurisdiction legal conflict      |
     +--------------------------------+----------------------------------+

     This document requests the creation of the following IANA registry:

     Registry Name:
        Human Escalation Mechanism Decision Types

     Registration Procedure:
        Standards Action [RFC8126]

     Initial Values:

     +-------------------------------+---------------------------------+
     | Decision Type                 | Description                     |
     +-------------------------------+---------------------------------+
     | APPROVE                       | Approve requested action        |
     | APPROVE_WITH_CONSTRAINTS      | Approve with Cedar context      |
     |                               | additions                       |
     | REDIRECT                      | Approve alternative action      |
     | TERMINATE                     | Terminate agent session         |
     | DEFER                         | Extend timeout; defer decision  |
     | APPROVE_WITH_LEGAL_BASIS      | Reserved; not yet operational.  |
     |                               | Kernel returns                  |
     |                               | HEM_DECISION_TYPE_NOT_YET_      |
     |                               | OPERATIONAL if submitted.       |
     +-------------------------------+---------------------------------+

     This document requests the creation of the following IANA registry:

     Registry Name:
        Human Escalation Mechanism Timeout Dispositions

     Registration Procedure:
        Specification Required [RFC8126]

     Initial Values:

     +-------------------+--------------------------------------------+
     | Disposition       | Description                                |
     +-------------------+--------------------------------------------+
     | ESCALATE_CHAIN    | Escalate to next principal in chain        |
     | SUSPEND           | Suspend governed object; await recovery    |
     | TERMINATE_SESSION | Apply TERMINATE decision semantics         |
     | AUTO_APPROVE      | Cedar-gated approve; restricted use        |
     |                   | (see Section 9.2)                          |
     +-------------------+--------------------------------------------+

     This document requests the creation of the following IANA registry:

     Registry Name:
        Human Escalation Mechanism Error Codes

     Registration Procedure:
        Specification Required [RFC8126]

     Initial Values:

     +-------------------------------------+-----------------------------+
     | Error Code                          | Description                 |
     +-------------------------------------+-----------------------------+
     | HEM_PENDING_ACTIVE                  | Transition rejected; HEM    |
     |                                     | active                      |
     | HEM_DECISION_INVALID                | Unrecognized decision type  |
     | HEM_SIGNATURE_INVALID               | Decision signature failed   |
     | HEM_PRINCIPAL_NOT_AUTHORIZED        | Submitter not in chain      |
     | HEM_DEFER_LIMIT_EXCEEDED            | Second DEFER from same      |
     |                                     | principal on same hem_id    |
     | HEM_DECISION_REJECTED               | Decision rejected; generic  |
     | HEM_MISSION_INVALID                 | Session terminated; mission |
     |                                     | entered terminal phase      |
     | HEM_PRD_MISSING                     | Cedar policy routes to HEM  |
     |                                     | but lacks registered prd_id |
     | HEM_CONSTRAINT_EXPIRED              | APPROVE_WITH_CONSTRAINTS    |
     |                                     | expiry window closed        |
     | HEM_REDIRECT_DENIED                 | Cedar DENY on REDIRECT      |
     |                                     | action                      |
     | HEM_MISSION_REF_MISMATCH_REJECTED   | IDP mission_ref does not    |
     |                                     | match session               |
     | HEM_DRR_REQUIRED                    | TERMINATE submitted without |
     |                                     | required DRR                |
     | HEM_AUTO_APPROVE_CEDAR_DENIED       | AUTO_APPROVE not applied;   |
     |                                     | Cedar returned DENY         |
     | HEM_AUTO_APPROVE_PROHIBITED         | AUTO_APPROVE configured for |
     |                                     | high-value transition class |
     | HEM_DECISION_TYPE_NOT_YET_          | Decision type reserved;     |
     | OPERATIONAL                         | not yet operational         |
     +-------------------------------------+-----------------------------+

     This document requests the creation of the following IANA registry:

     Registry Name:
        Human Escalation Mechanism PRD Rationale Classes

     Registration Procedure:
        Specification Required [RFC8126]

     Initial Values:

     +----------------------+--------------------------------------------+
     | Rationale Class      | Description                                |
     +----------------------+--------------------------------------------+
     | REGULATORY           | Required by applicable regulation          |
     | CONTRACTUAL          | Required by contract or agreement          |
     | OPERATIONAL_RISK     | Operational risk threshold requires        |
     |                      | human judgment                             |
     | SAFETY               | Safety requirement mandates oversight      |
     | LEGAL                | Legal requirement (non-regulatory)         |
     | POLICY               | Internal organizational policy             |
     +----------------------+--------------------------------------------+

     This document requests the creation of the following IANA registry:

     Registry Name:
        Human Escalation Mechanism DRR Rationale Classes

     Registration Procedure:
        Specification Required [RFC8126]

     Initial Values:

     +---------------------------+-----------------------------------------+
     | Rationale Class           | Description                             |
     +---------------------------+-----------------------------------------+
     | REGULATORY_COMPLIANCE     | Decision based on regulatory            |
     |                           | requirement                             |
     | SAFETY_ASSESSMENT         | Decision based on safety evaluation     |
     | MISSION_ALIGNMENT         | Decision based on mission scope         |
     |                           | assessment                              |
     | OPERATIONAL_JUDGMENT      | Decision based on operational           |
     |                           | expertise                               |
     | CONTRACTUAL_OBLIGATION    | Decision required by contract           |
     | ETHICAL_CONSIDERATION     | Decision based on ethical assessment    |
     | INSUFFICIENT_CONTEXT      | Insufficient information to approve     |
     | ESCALATION_JUDGMENT       | Decision reflects human escalation      |
     |                           | evaluation                              |
     +---------------------------+-----------------------------------------+

     This document requests the creation of the following IANA registry:

     Registry Name:
        Human Escalation Mechanism Denial Reason Classes

     Registration Procedure:
        Specification Required [RFC8126]

     Initial Values:

     +---------------------------+-----------------------------------------+
     | Denial Reason             | Description                             |
     +---------------------------+-----------------------------------------+
     | CEDAR_POLICY_DENY         | Cedar evaluation returned DENY          |
     | MANDATE_SCOPE_EXCEEDED    | Action outside mandate scope            |
     | HEM_PENDING_ACTIVE        | HEM is active for this session          |
     | MISSION_REF_MISMATCH      | IDP mission_ref does not match          |
     |                           | session MissionDeclaration              |
     | CAP_PROHIBITION           | CAP Tier 0 or Tier 1 prohibition        |
     |                           | applies                                 |
     | PRINCIPAL_NOT_AUTHORIZED  | Principal not in designation chain      |
     +---------------------------+-----------------------------------------+


  16.  References

  16.1.  Normative References

     [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
                Requirement Levels", BCP 14, RFC 2119,
                DOI 10.17487/RFC2119, March 1997,
                <https://www.rfc-editor.org/rfc/rfc2119>.

     [RFC7519]  Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
                (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015,
                <https://www.rfc-editor.org/rfc/rfc7519>.

     [RFC8126]  Cotton, M., Leiba, B., and T. Narten, "Guidelines for
                Writing an IANA Considerations Section in RFCs", BCP 26,
                RFC 8126, DOI 10.17487/RFC8126, June 2017,
                <https://www.rfc-editor.org/rfc/rfc8126>.

     [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in
                RFC 2119 Key Words", BCP 14, RFC 8174,
                DOI 10.17487/RFC8174, May 2017,
                <https://www.rfc-editor.org/rfc/rfc8174>.

     [Cedar]    Amazon Web Services, "Cedar Policy Language",
                <https://www.cedarpolicy.com/>.

     [I-D.sato-soos-idp]
                Sato, T., "The Intent Declaration Primitive (IDP) for
                Agentic AI Systems", Work in Progress, Internet-Draft,
                draft-sato-soos-idp-01, May 2026,
                <https://datatracker.ietf.org/doc/draft-sato-soos-idp/>.

     [I-D.sato-soos-gar]
                Sato, T., "The Governance Audit Record (GAR) for
                Agentic AI Systems", Work in Progress, Internet-Draft,
                draft-sato-soos-gar-00, May 2026,
                <https://datatracker.ietf.org/doc/draft-sato-soos-gar/>.

     [I-D.sato-soos-cap]
                Sato, T., "The Constitutional AI Protocol (CAP) for
                Agentic AI Systems", Work in Progress, Internet-Draft,
                draft-sato-soos-cap-00, May 2026,
                <https://datatracker.ietf.org/doc/draft-sato-soos-cap/>.

  16.2.  Informative References

     [EUAIA]    European Union, "Regulation (EU) 2024/1689 of the European
                Parliament and of the Council laying down harmonised rules
                on artificial intelligence (Artificial Intelligence Act)",
                Official Journal of the European Union, 12 July 2024,
                <https://eur-lex.europa.eu/legal-content/EN/TXT/
                ?uri=OJ:L_202401689>.

     [I-D.ietf-wimse-arch]
                Salowey, J., Rosomakho, Y., and H. Tschofenig, "Workload
                Identity in a Multi System Environment (WIMSE)
                Architecture", Work in Progress, Internet-Draft,
                draft-ietf-wimse-arch-07, March 2026,
                <https://datatracker.ietf.org/doc/draft-ietf-wimse-arch/>.

     [I-D.klrc-aiagent-auth]
                Kasselman, P., Lombardo, J., Rosomakho, Y., Campbell, B.,
                and N. Steele, "AI Agent Authentication and Authorization",
                Work in Progress, Internet-Draft,
                draft-klrc-aiagent-auth-01, March 2026,
                <https://datatracker.ietf.org/doc/draft-klrc-aiagent-auth/>.

     [I-D.rosenberg-aiproto-cheq]
                Rosenberg, J., White, P., and C. Jennings, "CHEQ: A
                Protocol for Confirmation of AI Agent Decisions with Human
                in the Loop (HITL)", Work in Progress, Internet-Draft,
                draft-rosenberg-aiproto-cheq-00, October 2025,
                <https://datatracker.ietf.org/doc/
                draft-rosenberg-aiproto-cheq/>.

     [SOOS]     Sato, T., "Sovereign Object OS -- Kernel Specification",
                Work in Progress, Version 2, May 2026,
                <https://activitytravel.pro/>.

     [I-D.sato-soos-transition-graph]
                Sato, T., "Transition Graph API for Agentic AI Systems",
                Work in Progress, Internet-Draft,
                draft-sato-soos-transition-graph-00, 2026 (forthcoming).

     [I-D.sato-jones-soos-mandate]
                Sato, T. and Jones, M., "Mandate JWT Profile for Agentic
                AI Systems", Work in Progress, Internet-Draft,
                draft-sato-jones-soos-mandate-00, 2026 (forthcoming).

     [I-D.mcguinness-oauth-actor-profile]
                McGuinness, K., "OAuth Actor Profile for AI Agents",
                Work in Progress, Internet-Draft,
                draft-mcguinness-oauth-actor-profile-00, 2026,
                <https://datatracker.ietf.org/doc/
                draft-mcguinness-oauth-actor-profile/>.

     [I-D.mcguinness-oauth-mission-bound-authorization]
                McGuinness, K., "Mission Bound Authorization",
                Work in Progress, Internet-Draft,
                draft-mcguinness-oauth-mission-bound-authorization-00,
                2026,
                <https://datatracker.ietf.org/doc/
                draft-mcguinness-oauth-mission-bound-authorization/>.


  Acknowledgments

     The HEM design builds on the OVID mandate model and the Clawdrey
     Hepburn delegation framework developed by the OVID community, from
     which the five decision type vocabulary was adapted. The EU AI Act
     Article 14 analysis was developed in the context of the Sovereign
     Object OS specification [SOOS]. The CHEQ complementarity framing
     draws on review of [I-D.rosenberg-aiproto-cheq]. The designation
     chain and timeout model reflects operational experience with the
     TRAVELER_UNREACHABLE chains defined in the ATP booking lifecycle.
     Section 8.4 (Mission Validity During HEM_PENDING) and the Class 4
     trigger class (Section 5.4, promoted to normative in this version)
     were developed following review of the McGuinness Mission Bound
     Authorization framework
     [I-D.mcguinness-oauth-mission-bound-authorization] and the mission
     governance model described in McGuinness (2026). The AAuth vs. HEM
     positioning statement in Section 1 was clarified following that
     review.

     The Windley Loop -- the kernel-mediated cycle of context delivery,
     agent intent declaration, and Cedar enforcement before action
     execution -- is named in recognition of Phil Windley's work on
     context and the Internet of My Things. The loop appears normatively
     in Section 5.1 and Section 11. The Policy Rationale Declaration
     (PRD, Section 5.6) and Decision Rationale Record (DRR, Section 7.6)
     were added in this version following completion of the full 29-item
     hem-01 agenda (S19, May 2026). The escalation request signing
     requirement (Section 12.8) reflects security review of delivery
     channel integrity properties.


  Author's Address

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


name: draft-morrison-substrate-observation
rev: 00
title: Substrate-Observation as an Alternative to Envelope Coordination for Concurrent Sessions
time: 2026-05-14T17:02:59Z
group_uri: /api/v1/group/group/1027/
expires: 2026-11-15T17:02:59Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["A2A protocols", "Agent identity/auth", "Data formats/interop"]
tags: []
fetched_at: 2026-05-22T09:24:47.115482+00:00
source: ietf
abstract:
  This memo articulates a coordination-protocol anti-pattern observed
     in cross-tool agentic systems and describes a substrate-observation
     alternative that does not require negotiating a wire format between
     heterogeneous concurrent sessions of an identity-bound principal.
     The memo is Informational.  No protocol element is being proposed for
     standardisation; the contribution is the opposite -- a delineation of
     what should NOT be standardised, and why, with a reference to the
     substrate-physics primitives that take its place.  Companion memos in
     the morrison-* family describe the identity primitives this memo
     presumes; specifically, this memo relies on the ~handle namespace
     established in [IDPRONOUNS] and the per-principal identity substrate
     referenced in [IDACCORD].

full_text:
  Network Working Group                                        B. Morrison
  Internet-Draft                                    Alter Meridian Pty Ltd
  Intended status: Informational                               15 May 2026
  Expires: 16 November 2026


    Substrate-Observation as an Alternative to Envelope Coordination for
                            Concurrent Sessions
                  draft-morrison-substrate-observation-00

  Abstract

     This memo articulates a coordination-protocol anti-pattern observed
     in cross-tool agentic systems and describes a substrate-observation
     alternative that does not require negotiating a wire format between
     heterogeneous concurrent sessions of an identity-bound principal.
     The memo is Informational.  No protocol element is being proposed for
     standardisation; the contribution is the opposite -- a delineation of
     what should NOT be standardised, and why, with a reference to the
     substrate-physics primitives that take its place.  Companion memos in
     the morrison-* family describe the identity primitives this memo
     presumes; specifically, this memo relies on the ~handle namespace
     established in [IDPRONOUNS] and the per-principal identity substrate
     referenced in [IDACCORD].

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

  Copyright Notice

     Copyright (c) 2026 IETF Trust and the persons identified as the
     document authors.  All rights reserved.





  Morrison                Expires 16 November 2026                [Page 1]


  Internet-Draft            Substrate Observation                 May 2026


     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.  Code Components
     extracted from this document must include Revised BSD License text as
     described in Section 4.e of the Trust Legal Provisions and are
     provided without warranty as described in the Revised BSD License.

  Table of Contents

     1.  Status of This Memo . . . . . . . . . . . . . . . . . . . . .   2
     2.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
     3.  Conventions and Definitions . . . . . . . . . . . . . . . . .   3
     4.  The Anti-Pattern  . . . . . . . . . . . . . . . . . . . . . .   4
       4.1.  Interop Combinatorics . . . . . . . . . . . . . . . . . .   4
       4.2.  Broker Re-Centralisation  . . . . . . . . . . . . . . . .   5
       4.3.  Identity-Binding Leakage  . . . . . . . . . . . . . . . .   5
     5.  The Alternative . . . . . . . . . . . . . . . . . . . . . . .   5
     6.  Reconciliation  . . . . . . . . . . . . . . . . . . . . . . .   6
     7.  Why Not Standardise the Substrate . . . . . . . . . . . . . .   6
     8.  Relation to Prior Art . . . . . . . . . . . . . . . . . . . .   6
     9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7
     10. Security Considerations . . . . . . . . . . . . . . . . . . .   8
       10.1.  Ghost-State Injection  . . . . . . . . . . . . . . . . .   8
       10.2.  Simulated Split-Brain  . . . . . . . . . . . . . . . . .   8
       10.3.  Confidence-Replay  . . . . . . . . . . . . . . . . . . .   8
     11. Privacy Considerations  . . . . . . . . . . . . . . . . . . .   8
     12. References  . . . . . . . . . . . . . . . . . . . . . . . . .   8
       12.1.  Normative References . . . . . . . . . . . . . . . . . .   8
       12.2.  Informative References . . . . . . . . . . . . . . . . .   9
     Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  10
     Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  10

  1.  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."



  Morrison                Expires 16 November 2026                [Page 2]


  Internet-Draft            Substrate Observation                 May 2026


  2.  Introduction

     When a single identity-bound principal operates several agentic
     sessions concurrently -- whether across different tools, different
     hosts (a workstation, a laptop, a phone), or different organisational
     contexts (an individual capacity, a workplace capacity, a contracted
     capacity) -- those sessions must deconflict their action without
     stepping on each other's commits, leases, or external-system state.

     A natural impulse is to standardise a wire protocol for the sessions
     to exchange peer-state envelopes: "I am here, working on X, holding
     lease Y until time T".  This memo argues such standardisation is
     structurally unnecessary, would compound interop burden as new
     agentic tools enter the ecosystem, and would re-centralise an
     inherently distributed problem on whatever broker the envelope
     protocol selected.

     The alternative is substrate observation: each session observes
     byproducts of its peers' normal operation (filesystem timestamps,
     kernel-reported socket peer counts, server-emitted connection counts
     on shared channels) and forms its own local representation of who-
     else-is-here.  No envelope.  No wire format.  No broker.
     Reconciliation occurs post-hoc through substrate-physics commitments
     (filesystem locks, append-only identity logs, economic settlement,
     organisational identity append-logs) -- never through a canonical
     decision.  Identity binding of the principal's surfaces themselves is
     assumed to follow the conventions of [MCPDNS] and [IDCOMMITS]; this
     memo concerns only the coordination layer above those primitives.

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

     The following terms are defined for the purposes of this document:

     *  *Substrate-emitted byproduct.* A filesystem or kernel or network-
        substrate side-effect of an operation undertaken for some purpose
        other than coordination, observable to other sessions of the same
        principal without those sessions having transmitted a coordination
        message.







  Morrison                Expires 16 November 2026                [Page 3]


  Internet-Draft            Substrate Observation                 May 2026


     *  *Decay-to-uncertainty.* The property that an observation aged
        beyond a recency threshold transitions to an explicit "uncertain"
        state, under which the observing session continues to operate,
        rather than transitioning to an "absent" state under which the
        observing session blocks.

     *  *Mutual hallucination.* The property that each session of a
        principal forms its own local representation of concurrent-peer
        presence from substrate observations, and that no representation
        is canonical.  Divergent representations are reconciled post-hoc
        through substrate-physics commitments, not through agreement among
        the sessions themselves.

     *  *Substrate-physics cascade.* The ordered, non-commutative
        reconciliation pipeline through which divergent local
        representations resolve to a single durable history.  A reference
        implementation orders the cascade as (a) filesystem-lock
        arbitration, (b) per-principal append-only identity-log, (c)
        external operational settlement (cryptographic non-fast-forward
        rejection, on-chain transaction receipt), and (d) per-organisation
        append-only identity-log.  No stage in the cascade transmits a
        coordination marker; each stage is a commitment to the substrate,
        observed identically by every participating session.

  4.  The Anti-Pattern

     This memo identifies envelope coordination -- the standardisation of
     a peer-state-exchange wire format across heterogeneous agentic
     sessions -- as structurally inadequate to the cross-tool identity-
     bound-principal problem.  Three failure modes recur:

  4.1.  Interop Combinatorics

     Every additional agentic tool adopting an envelope-coordination
     standard must negotiate compatibility with every prior tool's version
     of the standard.  Tool families evolve at different cadences;
     agreement-by-versioning produces a combinatorial maintenance burden
     borne by the slowest-moving tool's release cycle.  Substrate
     observation has no compatibility surface to negotiate; tools that
     emit substrate byproducts as a side effect of their normal operation
     are mutually visible by construction, regardless of release cycle.










  Morrison                Expires 16 November 2026                [Page 4]


  Internet-Draft            Substrate Observation                 May 2026


  4.2.  Broker Re-Centralisation

     Envelope-coordination wire formats imply a destination for the
     envelopes.  A broker -- whether discovered via DNS, configured per-
     session, or shipped by a single vendor -- accumulates the peer-state
     of every session that publishes to it.  This collapses what is
     logically a distributed-observation problem onto a single centralised
     authority, with the predictable consequences for failure-mode (broker
     down implies coordination down) and trust (broker operator sees every
     session's purpose).

  4.3.  Identity-Binding Leakage

     Envelope payloads typically carry an identifier ("session-id",
     "principal-id", "agent-id") to permit peers to address each other.
     Such identifiers become a re-identification surface at the wire layer
     that the underlying identity infrastructure may have explicitly
     arranged to bound.  Substrate byproducts emit no payload -- they are
     simply present in the substrate -- and the inference of peer identity
     is performed locally by each session from substrate-tier credentials
     it already possesses (kernel SO_PEERCRED, transport-layer
     authentication on a shared channel, and equivalent).  No wire-layer
     identifier is exposed.

  5.  The Alternative

     Sessions observe substrate-emitted byproducts.  Three reference
     observables, listed in order of identity-binding strength:

     *  Filesystem modification timestamps on per-session journal files
        produced by tools that journal to disk.  Pseudonymous; compute-
        location is the observing session's local filesystem.

     *  Kernel-reported socket peer-credentials (SO_PEERCRED on Unix-
        domain sockets, equivalent mechanisms on other systems) for
        sessions mounting a common per-principal daemon.  Identity-bound
        to the principal owning the daemon; compute-location is kernel-
        mediated, host-local.

     *  Server-emitted concurrent-connection counts on a per-principal
        event channel maintained by the principal's identity
        infrastructure.  Identity-bound to the principal; compute-location
        is the server emitting the count, with inference performed locally
        by the subscribing session.

     None of these observables is a coordination message.  Each exists as
     a byproduct of the observed session's normal operation: writing its
     journal, mounting its socket, subscribing to its event channel.



  Morrison                Expires 16 November 2026                [Page 5]


  Internet-Draft            Substrate Observation                 May 2026


  6.  Reconciliation

     When sessions' local representations diverge -- typically when two
     sessions independently take an action that affects shared state (a
     shared filesystem path, a shared external-system resource, a shared
     organisational artifact) -- reconciliation proceeds through the
     substrate-physics cascade defined in Section 2, ordered: filesystem-
     lock arbitration, per-principal append-only identity-log, external
     operational settlement, per-organisation append-only identity-log.
     Each stage is a substrate commitment.  No stage transmits a
     coordination marker; each stage's outcome is itself observable as
     another substrate byproduct by every participating session.

     The cascade is non-commutative: the outcome of an earlier stage
     constrains the admissibility of a later stage's commitments.  This
     property prevents an attacker from partitioning observations across
     cascade stages to write conflicting commitments simultaneously.

  7.  Why Not Standardise the Substrate

     A reader may ask whether this memo should propose a standardised set
     of substrate observables and a standardised reconciliation cascade.
     It does not.  The observables identified above are characteristic of
     POSIX-derived systems running journal-emitting tools, mounting Unix-
     domain sockets, and subscribing to HTTP-streaming event channels --
     substrate that is itself standardised in [POSIX], [RFC8441], and
     similar.  No new substrate standardisation is required for the
     substrate-observation pattern; it composes directly with existing
     substrate.  Where heterogeneous substrate calls for adapter selection
     (a Windows tool's journal location differs from a POSIX tool's), the
     adapter is a tool-private implementation detail, not a wire-format
     negotiation between sessions.

  8.  Relation to Prior Art

     This memo's substrate-observation primitive is structurally distinct
     from each of the prior-art families surveyed below.  The contribution
     of this memo is the joint articulation of why each family is, by
     construction, inadequate to the identity-bound-principal cross-tool
     problem the memo describes; it is not a survey for its own sake.

     Leader-elected consensus [PAXOS] [RAFT] requires a designated leader,
     explicit coordination messages, and a single canonical log.
     Substrate observation has none of these.







  Morrison                Expires 16 November 2026                [Page 6]


  Internet-Draft            Substrate Observation                 May 2026


     Conflict-Free Replicated Data Types [CRDT] require a shared mutable
     data structure and commutative merge operations.  Substrate
     observation has neither; the cascade described in Section 5 is non-
     commutative.

     Gossip and epidemic protocols (Demers et al. 1987, [SWIM] and
     successors) require explicit anti-entropy or update messages
     transmitted between nodes on a schedule.  Substrate byproducts are
     not anti-entropy payloads; they are unrelated side-effects.

     Logical clocks [CLOCKS] (Lamport, vector clocks, Interval Tree
     Clocks) require piggyback of clock state on application messages.
     Substrate observation does not piggyback on coordination messages
     because there are none.

     Distributed snapshots [SNAPSHOTS] require explicit marker messages
     injected along communication channels.  The reconciliation cascade of
     Section 5 is triggered by independent operational events, not
     markers.

     Cryptographically-chained append-only logs (Certificate Transparency
     [RFC6962], Git object graphs, blockchain ledgers) are each
     instantiated by the present memo's cascade as one of its stages, not
     as the whole.  Their novelty in the present context is their
     composition as the second and fourth stages of a non-commutative
     cascade triggered by byproduct emission, not their chained-log
     primitive considered alone.

     Failure detectors (Chandra-Toueg, [SWIM], Lifeguard) output suspect/
     dead judgements about peers based on heartbeat latency/absence.
     Substrate observation outputs uncertainty as a first-class terminal
     operating state; uncertainty is not a transient state on the way to
     dead -- it is the state the system operates under.

     Lock-free and wait-free data structures require shared memory between
     threads.  Sessions in the present memo do not share memory; they
     observe substrate-physics surfaces independently.

     Web Locks API [WEBLOCKS] and analogous intra-runtime mechanisms
     operate within a single browser instance and rely on message-passing
     or lock-arbitration provided by the runtime.  They do not generalise
     to the cross-host, cross-tool problem the present memo addresses.

  9.  IANA Considerations

     This memo requires no IANA actions.





  Morrison                Expires 16 November 2026                [Page 7]


  Internet-Draft            Substrate Observation                 May 2026


  10.  Security Considerations

     Substrate observation surfaces three classes of attack absent from
     envelope-coordination protocols.

  10.1.  Ghost-State Injection

     A peer emits a substrate byproduct then disappears, leaving an aging
     observation influencing other sessions' representations beyond its
     operational lifetime.  Mitigation is decay-to-uncertainty with a per-
     substrate-layer eviction floor: observations below threshold are
     evicted, not retained at vanishing confidence.

  10.2.  Simulated Split-Brain

     A peer emits substrate byproducts to some cascade layers but not
     others, producing divergent local representations across layers that
     the cascade cannot fully reconcile.  Mitigation is per-observer
     monotonic layer-coverage commitment: an observer's first emission
     registers its substrate-set, and later emissions outside that set are
     quarantined before identity-log write.

  10.3.  Confidence-Replay

     A peer re-emits aged substrate byproducts to refresh observers'
     confidence in stale state.  Mitigation is observation-id-bound decay,
     where the decay clock is keyed to the observation identifier rather
     than to wall-clock receipt time.

  11.  Privacy Considerations

     Substrate observables vary in identity-binding strength.  The lowest
     tier (filesystem timestamps, before any identity binding) is
     pseudonymous: the observer can infer presence but not identity.
     Implementations SHOULD operate this tier with refusal to emit in
     cloud-shell environments (where host identity is shared across
     users), refusal to emit in continuous-integration environments (where
     emission would be linkable to public workflow metadata), and refusal
     to enforce locks at this tier (locks require identity binding;
     pseudonymous observations do not provide it).

  12.  References

  12.1.  Normative References







  Morrison                Expires 16 November 2026                [Page 8]


  Internet-Draft            Substrate Observation                 May 2026


     [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
                Requirement Levels", BCP 14, RFC 2119,
                DOI 10.17487/RFC2119, March 1997,
                <https://www.rfc-editor.org/info/rfc2119>.

     [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
                2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
                May 2017, <https://www.rfc-editor.org/info/rfc8174>.

     [MCPDNS]   Morrison, B., "Discovery of Model Context Protocol Servers
                via DNS TXT Records", 2026,
                <https://datatracker.ietf.org/doc/draft-morrison-mcp-dns-
                discovery/>.

     [IDPRONOUNS]
                Morrison, B., "Identity Pronouns: A Reference-Axis
                Extension to ~handle Identity Systems", 2026,
                <https://datatracker.ietf.org/doc/draft-morrison-identity-
                pronouns/>.

     [IDACCORD] Morrison, B., "Identity Accord Protocol", 2026,
                <https://datatracker.ietf.org/doc/draft-morrison-identity-
                accord/>.

     [IDCOMMITS]
                Morrison, B., "Identity-Attributed Git Commits via Tier-
                Structured Trailers", 2026,
                <https://datatracker.ietf.org/doc/draft-morrison-identity-
                attributed-commits/>.

  12.2.  Informative References

     [POSIX]    "IEEE Std 1003.1-2017, Standard for Information Technology
                -- Portable Operating System Interface (POSIX) Base
                Specifications", 2017,
                <https://pubs.opengroup.org/onlinepubs/9699919799/>.

     [RFC8441]  McManus, P., "Bootstrapping WebSockets with HTTP/2",
                RFC 8441, DOI 10.17487/RFC8441, September 2018,
                <https://www.rfc-editor.org/info/rfc8441>.

     [RFC6962]  Laurie, B., Langley, A., and E. Kasper, "Certificate
                Transparency", RFC 6962, June 2013,
                <https://www.rfc-editor.org/info/rfc6962>.

     [PAXOS]    Lamport, L., "The Part-Time Parliament", 1998,
                <https://lamport.azurewebsites.net/pubs/lamport-
                paxos.pdf>.



  Morrison                Expires 16 November 2026                [Page 9]


  Internet-Draft            Substrate Observation                 May 2026


     [RAFT]     Ongaro, D. and J. Ousterhout, "In Search of an
                Understandable Consensus Algorithm", 2014,
                <https://raft.github.io/raft.pdf>.

     [CRDT]     Shapiro, M., Preguica, N., Baquero, C., and M. Zawirski,
                "Conflict-Free Replicated Data Types", 2011,
                <https://hal.inria.fr/inria-00609399v1/document>.

     [SWIM]     Das, A., Gupta, I., and A. Motivala, "SWIM: Scalable
                Weakly-consistent Infection-style Process Group Membership
                Protocol", 2002,
                <https://www.cs.cornell.edu/projects/Quicksilver/
                public_pdfs/SWIM.pdf>.

     [CLOCKS]   Lamport, L., "Time, Clocks, and the Ordering of Events in
                a Distributed System", 1978,
                <https://lamport.azurewebsites.net/pubs/time-clocks.pdf>.

     [SNAPSHOTS]
                Chandy, K. M. and L. Lamport, "Distributed Snapshots:
                Determining Global States of Distributed Systems", 1985,
                <https://lamport.azurewebsites.net/pubs/chandy.pdf>.

     [WEBLOCKS] "Web Locks API", 2021, <https://www.w3.org/TR/web-locks/>.

  Acknowledgements

     This memo grew out of internal architectural design work on
     coordinating concurrent agentic sessions of a single identity-bound
     principal across heterogeneous tooling.  The realisation that
     substrate observation suffices, and that envelope coordination is the
     wrong abstraction at the cross-tool layer, is the load-bearing
     insight behind this specification.

  Author's Address

     Blake Morrison
     Alter Meridian Pty Ltd
     Cronulla, NSW
     Australia
     Email: blake@truealter.com










  Morrison                Expires 16 November 2026               [Page 10]


name: draft-hillier-certisyn-ai-governance-verified
rev: 00
time: 2026-05-15T05:41:44Z
group_uri: /api/v1/group/group/1027/
expires: 2026-11-16T05:41:44Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["Policy/governance", "AI safety/alignment", "Agent identity/auth"]
tags: []
fetched_at: 2026-05-22T09:24:47.115485+00:00
source: ietf
title:
  AI Governance Verified -- A Cryptographic Verification Standard for Agentic AI Governance in Regulated Industries

abstract:
  This document specifies a verification standard for the cryptographic
     attestation of agentic AI governance in regulated industries.  It
     defines the Verification Reconciliation Object (VRO), the issuing-
     partner framework, the eight control areas through which AI
     governance posture is reconciled, three maturity-attestation levels
     (Documented, Operational, Adversarial-ready), and the cryptographic
     continuity requirements that together produce deterministic,
     independently reconstructable, auditor-grade attestations of agentic
     AI governance.  The standard sits beneath ISO/IEC 42001:2023, the
     NIST AI Risk Management Framework, and other agentic AI governance
     frameworks, and produces the verifiable artefact those frameworks
     were designed to imply but do not deliver.

full_text:
  Network Working Group                                      J. D. Hillier
  Internet-Draft                                            Certisyn, Inc.
  Intended status: Informational                               13 May 2026
  Expires: 14 November 2026


     AI Governance Verified — A Cryptographic Verification Standard for
               Agentic AI Governance in Regulated Industries
              draft-hillier-certisyn-ai-governance-verified-00

  Abstract

     This document specifies a verification standard for the cryptographic
     attestation of agentic AI governance in regulated industries.  It
     defines the Verification Reconciliation Object (VRO), the issuing-
     partner framework, the eight control areas through which AI
     governance posture is reconciled, three maturity-attestation levels
     (Documented, Operational, Adversarial-ready), and the cryptographic
     continuity requirements that together produce deterministic,
     independently reconstructable, auditor-grade attestations of agentic
     AI governance.  The standard sits beneath ISO/IEC 42001:2023, the
     NIST AI Risk Management Framework, and other agentic AI governance
     frameworks, and produces the verifiable artefact those frameworks
     were designed to imply but do not deliver.

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

  Copyright Notice

     Copyright (c) 2026 IETF Trust and the persons identified as the
     document authors.  All rights reserved.





  Hillier                 Expires 14 November 2026                [Page 1]


  Internet-Draft           AI Governance Verified                 May 2026


     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.  Code Components
     extracted from this document must include Revised BSD License text as
     described in Section 4.e of the Trust Legal Provisions and are
     provided without warranty as described in the Revised BSD License.

  Table of Contents

     1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     2.  Conventions and Definitions . . . . . . . . . . . . . . . . .   3
     3.  Architectural Overview  . . . . . . . . . . . . . . . . . . .   4
     4.  AI Governance Verification Requirements . . . . . . . . . . .   5
       4.1.  Area 1: AI inventory and shadow-AI discovery  . . . . . .   5
       4.2.  Area 2: Use-case classification and risk assessment . . .   5
       4.3.  Area 3: Model and data provenance . . . . . . . . . . . .   6
       4.4.  Area 4: Sanctioned-application control  . . . . . . . . .   6
       4.5.  Area 5: Prompt and output governance  . . . . . . . . . .   7
       4.6.  Area 6: Identity and access control for AI  . . . . . . .   7
       4.7.  Area 7: Logging, telemetry, and auditability  . . . . . .   8
       4.8.  Area 8: Incident, drift, and escalation response  . . . .   8
     5.  Maturity Level Attestation  . . . . . . . . . . . . . . . . .   8
     6.  Verification Reconciliation Object (VRO)  . . . . . . . . . .   9
     7.  Issuing Partner Requirements  . . . . . . . . . . . . . . . .  10
     8.  Cryptographic Continuity Requirements . . . . . . . . . . . .  11
     9.  Standards Alignment . . . . . . . . . . . . . . . . . . . . .  11
     10. Conformance . . . . . . . . . . . . . . . . . . . . . . . . .  12
     11. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  12
     12. Security Considerations . . . . . . . . . . . . . . . . . . .  12
     13. References  . . . . . . . . . . . . . . . . . . . . . . . . .  12
       13.1.  Normative References . . . . . . . . . . . . . . . . . .  12
       13.2.  Informative References . . . . . . . . . . . . . . . . .  13
     Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  13
     Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  13

  1.  Introduction

     Agentic artificial intelligence is now operative across the workplace
     at a scale that exceeds the control envelope of every previously
     published governance framework.  ISO/IEC 42001:2023 [ISO42001]
     specifies a management system for AI but does not produce a
     verifiable artefact.  The NIST AI Risk Management Framework
     [NIST-AI-RMF] provides a functional taxonomy but issues no
     certification or attestation.  The European Union AI Act [EU-AI-ACT]
     establishes obligations and prohibitions but leaves verification of
     compliance to national competent authorities and self-attestation.



  Hillier                 Expires 14 November 2026                [Page 2]


  Internet-Draft           AI Governance Verified                 May 2026


     No published standard issues a cryptographically anchored,
     deterministically reproducible monthly artefact of agentic AI
     governance.

     This document closes that gap.  It defines the verification artefact,
     the issuing-partner framework, the evidence requirements across eight
     control areas, the maturity-level attestation methodology, and the
     cryptographic continuity requirements that together produce a
     deterministic, auditor-grade AI governance attestation.

     This document does not replace ISO/IEC 42001, the NIST AI Risk
     Management Framework, the EU AI Act, or any national framework.  It
     sits beneath them and produces the artefact each was designed to
     imply but does not deliver.  Where this document and any normative
     framework cited herein conflict on operational content, the cited
     framework prevails.

     This document applies to organisations that operate, integrate,
     deploy, or expose AI systems — whether developed internally, procured
     from third-party model providers, or consumed via API.  It does not
     specify AI model architecture, training procedure, or evaluation
     methodology.  It specifies the verification of governance applied to
     AI use, not the AI itself.

  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.

     For the purposes of this document, the following definitions apply.

     Subject Entity:  The organisation whose AI governance posture is the
        subject of verification.

     AI System:  Any deployed system, application, or service whose
        behaviour incorporates the use of one or more machine-learning
        models, irrespective of model architecture or training
        methodology.

     Agentic System:  An AI System that takes actions in the operating
        environment, generates outputs that influence downstream
        decisions, or operates with reduced or absent human-in-the-loop
        supervision.

     Model Provider:  An external party supplying a foundation model,



  Hillier                 Expires 14 November 2026                [Page 3]


  Internet-Draft           AI Governance Verified                 May 2026


        fine-tuned model, or model-as-a-service to the Subject Entity.

     Deployment Context:  The set of integrations, data sources, user
        populations, regulatory obligations, and risk attributes within
        which an AI System is operated.

     Governance Surface:  The composite of policies, controls, telemetry,
        evidence sources, and review cadences through which the Subject
        Entity governs the use of its AI Systems.

     Verification Reconciliation Object (VRO):  The deterministic,
        cryptographically anchored output of a conforming AI governance
        attestation under this standard.

     Issuing Partner:  A counterparty designated by the protocol operator
        to act as a co-issuer of VROs under this standard within a defined
        market or scope.

     Attestation Period:  The contiguous time interval over which a VRO
        asserts conformance.

     Anchor Event:  The cryptographic operation that binds a VRO to an
        immutable public settlement layer at issuance and at supersession.

     Maturity Level:  One of three levels (Documented, Operational,
        Adversarial-ready) defined in this document.

     Supersession:  The lifecycle event by which a new VRO replaces a
        prior VRO.

  3.  Architectural Overview

     Conforming attestations under this standard are produced by a
     verification infrastructure organised as five architectural
     components.  Internal design, scoring methodology, and calibration
     logic are not in scope for this document.

     The Evidence Ingestion and Normalization Layer accepts AI governance
     Evidence Artefacts from Subject Entity systems — model registries,
     identity-provider telemetry, prompt and output logs, sanctioned-
     application controls, incident records — and normalises
     representation across heterogeneous source formats.

     The Reconciliation Confidence Engine reconciles Conformance Claims
     against normalised evidence and produces a deterministic
     reconciliation output.





  Hillier                 Expires 14 November 2026                [Page 4]


  Internet-Draft           AI Governance Verified                 May 2026


     The Verification State Machine maintains the lifecycle state of each
     VRO through intake, evidence ingestion, reconciliation, anchoring,
     issuance, supersession, and revocation.

     Entity Graph Propagation propagates verification state across related
     entities where continuity is in scope.

     The Attestation Protocol produces the final VRO, performs the Anchor
     Event, registers the artefact in the public attestation registry, and
     binds the issuing-partner identity.

     Conforming attestations are deterministic.  Given the same
     Conformance Claims and the same Evidence Artefacts processed through
     the same Attestation Protocol version, the same VRO SHALL be
     produced.  Determinism applies to the verification operation, not to
     the AI systems being verified.

  4.  AI Governance Verification Requirements

     The following subsections specify the eight control areas through
     which agentic AI governance is reconciled under this standard.

  4.1.  Area 1: AI inventory and shadow-AI discovery

     Subject Claim:  The Subject Entity maintains a current inventory of
        AI Systems in operation across its workforce, integrations, and
        infrastructure, and detects use of unsanctioned or undisclosed AI
        Systems within its operating environment.

     Evidence Categories:  AI System register; identity-provider telemetry
        of AI service authentications; endpoint or network telemetry of
        model API egress; sanctioned-application register; shadow-AI
        detection output; periodic reconciliation reports.

     Verification Expectation:  Reconciliation of declared inventory
        against detected use across the Attestation Period; exception
        cases reconciled against the disclosure or remediation register.

     Anchor Requirement:  Anchored at Attestation Period start and end.
        Material expansions of inventory require a supersession anchor.

  4.2.  Area 2: Use-case classification and risk assessment

     Subject Claim:  The Subject Entity classifies each AI System by use-
        case category and risk tier, and records the classification
        together with the rationale and the residual-risk position.

     Evidence Categories:  Use-case classification register; risk



  Hillier                 Expires 14 November 2026                [Page 5]


  Internet-Draft           AI Governance Verified                 May 2026


        assessment artefact for each AI System; risk-tier policy artefact;
        review records evidencing periodic reassessment; exception
        register for ungoverned use cases.

     Verification Expectation:  Reconciliation of declared classifications
        against the policy taxonomy; reconciliation of risk tier against
        deployment context evidence; identification of classification
        drift over the Attestation Period.

     Anchor Requirement:  Anchored at issuance; supersession on material
        change in deployment context, risk tier, or use-case scope.

  4.3.  Area 3: Model and data provenance

     Subject Claim:  The Subject Entity records and maintains provenance
        evidence for each AI System in use, including model identity,
        model version, Model Provider identity, training data disclosures
        (where available), and update or fine-tuning lineage.

     Evidence Categories:  Model registry entries with provider, version,
        and lineage data; Model Provider transparency reports or model
        cards where supplied; training data attestations where available;
        fine-tuning records; vendor change log.

     Verification Expectation:  Reconciliation of recorded provenance
        against AI System operational state; reconciliation of fine-tuning
        lineage against change-management evidence; identification of
        model-version drift across the Attestation Period.

     Anchor Requirement:  Anchored at issuance and at each material model-
        version change or Model Provider change.

  4.4.  Area 4: Sanctioned-application control

     Subject Claim:  The Subject Entity restricts use of AI Systems to
        those that have been explicitly sanctioned for the applicable user
        population and use-case context, consistent with the asserted
        Maturity Level.

     Evidence Categories:  Sanctioned-application allow-list policy;
        endpoint or network enforcement evidence; exception register;
        user-population scope evidence; periodic review records.

     Verification Expectation:  Reconciliation of declared allow-list
        against enforcement telemetry; reconciliation of exception cases
        against the exception register; identification of unsanctioned use
        over the Attestation Period.




  Hillier                 Expires 14 November 2026                [Page 6]


  Internet-Draft           AI Governance Verified                 May 2026


     Anchor Requirement:  Anchored at issuance and on material allow-list
        changes.

  4.5.  Area 5: Prompt and output governance

     Subject Claim:  The Subject Entity governs the content of prompts
        submitted to AI Systems and outputs produced by AI Systems,
        including controls preventing disclosure of sensitive data to
        external AI Systems and controls preventing high-risk output
        content from entering downstream processes.

     Evidence Categories:  Prompt-content policy artefact; output-content
        policy artefact; prompt-monitoring telemetry; output-review
        telemetry; data-loss-prevention rules applied to AI traffic; high-
        risk content exception register.

     Verification Expectation:  Reconciliation of declared content
        controls against monitoring telemetry; reconciliation of exception
        handling against review evidence; identification of control bypass
        or drift over the Attestation Period.

     Anchor Requirement:  Anchored at issuance and on each material change
        in control scope, sensitive-content taxonomy, or enforcement
        state.

  4.6.  Area 6: Identity and access control for AI

     Subject Claim:  The Subject Entity enforces identity and access
        controls on the use of AI Systems consistent with the asserted
        Maturity Level, including authentication, authorisation, multi-
        factor enforcement, and segregation between human and machine
        principals.

     Evidence Categories:  Identity-provider telemetry for AI service
        authentications; access assignment register for AI Systems; multi-
        factor enrolment coverage report; service-account inventory;
        access review records.

     Verification Expectation:  Reconciliation of declared access model
        against assignment register; reconciliation of multi-factor
        enforcement against identity-provider evidence; reconciliation of
        service-account use against the inventory and policy.

     Anchor Requirement:  Anchored at issuance and at the conclusion of
        each scheduled access review cycle.






  Hillier                 Expires 14 November 2026                [Page 7]


  Internet-Draft           AI Governance Verified                 May 2026


  4.7.  Area 7: Logging, telemetry, and auditability

     Subject Claim:  The Subject Entity captures, retains, and protects
        logs of AI System use sufficient to permit retrospective
        reconstruction of governance-relevant events, with retention and
        integrity properties consistent with the asserted Maturity Level.

     Evidence Categories:  Logging policy artefact; log content schema;
        log retention configuration; log-integrity attestation; access-
        control evidence for log stores; sampling or audit records.

     Verification Expectation:  Reconciliation of declared logging scope
        against captured content; reconciliation of asserted retention
        against log-store configuration; reconciliation of asserted
        integrity properties against evidence of log-store immutability or
        chain protection.

     Anchor Requirement:  Anchored at issuance and on material changes to
        logging scope, retention, or integrity configuration.

  4.8.  Area 8: Incident, drift, and escalation response

     Subject Claim:  The Subject Entity operates an incident-response
        capability for AI-related events, including hallucination, output
        failure, prompt-injection, data exfiltration, model drift, and
        high-impact misuse, with defined escalation paths and post-event
        review consistent with the asserted Maturity Level.

     Evidence Categories:  AI incident-response policy; incident register;
        incident classification taxonomy; escalation records; post-event
        review reports; remediation evidence; drift-monitoring telemetry.

     Verification Expectation:  Reconciliation of declared response
        capability against the incident register over the Attestation
        Period; reconciliation of escalation evidence against the declared
        escalation paths; reconciliation of remediation evidence against
        committed actions.

     Anchor Requirement:  Anchored at issuance and at the conclusion of
        each material incident response or post-event review cycle.

  5.  Maturity Level Attestation

     A conforming VRO under this standard SHALL attest a Maturity Level
     for each of the eight control areas.  Different control areas MAY
     attest at different Maturity Levels within a single VRO; the overall
     VRO attestation is the minimum Maturity Level attested across the
     eight control areas unless otherwise asserted.



  Hillier                 Expires 14 November 2026                [Page 8]


  Internet-Draft           AI Governance Verified                 May 2026


     Maturity Level Documented reflects the baseline expectation that
     governance content exists, that policy artefacts are written, that an
     inventory is maintained, and that a designated owner is accountable.
     Evidence requirements at this level emphasise the existence of
     declared content and basic operational artefacts over an Attestation
     Period of at least three (3) consecutive months.

     Maturity Level Operational reflects the expectation that controls are
     not only documented but exercised: telemetry collected, periodic
     reviews occurring, exceptions recorded and handled, and the
     governance surface responding to material change.  Evidence
     requirements add depth of telemetry, review-cadence evidence,
     exception handling, and continuity over an Attestation Period of at
     least six (6) consecutive months.

     Maturity Level Adversarial-ready reflects the expectation that
     governance withstands adversarial conditions: prompt-injection
     attempts, model-drift events, data-exfiltration attempts via AI
     channels, sophisticated misuse, and dependency failures at the Model
     Provider.  Evidence requirements add continuity, defence-in-depth
     evidence, red-team or adversarial evaluation attestation where in
     scope, and continuous reconciliation over an Attestation Period of at
     least twelve (12) consecutive months.

     A Subject Entity that progresses to a higher Maturity Level for any
     control area SHALL be issued a superseding VRO recording the
     progression.  The prior VRO is preserved and marked as superseded.

  6.  Verification Reconciliation Object (VRO)

     A conforming VRO under this standard SHALL contain, at minimum:

     *  Subject Entity identifier.

     *  Attestation Period start and end timestamps.

     *  Maturity Level attested for each of the eight control areas.

     *  Conformance Claims as asserted by the Subject Entity.

     *  Evidence categories ingested and reconciliation outcome for each.

     *  AI System inventory snapshot at Attestation Period end.

     *  Issuing Partner identity and seat designation.

     *  Anchor Event identifiers binding the VRO to the public settlement
        layer.



  Hillier                 Expires 14 November 2026                [Page 9]


  Internet-Draft           AI Governance Verified                 May 2026


     *  Verification State Machine state at issuance.

     *  Supersession chain reference, where applicable.

     *  Conformance statement of this standard, version 1.0.

     A VRO MAY be revoked by the Issuing Partner upon determination of
     material non-conformance, evidence falsification, undisclosed
     incidents, or other circumstances rendering the original attestation
     unreliable.  Revocation does not delete the VRO; it records a
     revocation state, the revocation reason class, and the Anchor Event
     binding the revocation to the public settlement layer.

     Each issued VRO SHALL be registered in the public attestation
     registry.

  7.  Issuing Partner Requirements

     An organisation seeking designation as an Issuing Partner under this
     standard SHALL demonstrate, at minimum:

     *  Operational capacity to assess AI governance posture across the
        eight control areas at the Maturity Level for which issuance is
        sought.

     *  Demonstrable competence in AI deployment models, identity and
        access controls, prompt and output monitoring, and incident
        response.

     *  Independence from the Subject Entity at the engagement level, with
        declared conflicts of interest disclosed and managed.

     *  Independence from any Model Provider whose models are within the
        scope of attestation, or, where dependency exists, declared and
        managed under a stated independence protocol.

     *  Adherence to the protocol operator's Partner Code of Conduct.

     *  Acceptance of the Designation Schedule terms applicable to the
        relevant market and seat.

     An Issuing Partner SHALL NOT, for a given Subject Entity engagement,
     simultaneously act as the implementing vendor, deployment integrator,
     or operator of the AI Systems being verified.







  Hillier                 Expires 14 November 2026               [Page 10]


  Internet-Draft           AI Governance Verified                 May 2026


  8.  Cryptographic Continuity Requirements

     Each VRO SHALL be cryptographically anchored to an immutable public
     settlement layer at the Anchor Event.  The hash committed at the
     Anchor Event SHALL be a one-way function of the VRO content, Issuing
     Partner identity, and timestamp, computed under a digest algorithm of
     at least 256-bit strength.

     A VRO issued under this standard SHALL remain a conforming artefact
     across regulatory regime changes occurring within or after the
     Attestation Period.

     The Anchor Event binding SHALL remain independently verifiable in the
     event of a Model Provider ceasing to operate, withdrawing a model, or
     being acquired or restructured.  VROs issued during the operating
     life of a withdrawn model are not retroactively invalidated.

  9.  Standards Alignment

     This standard is interoperable with adjacent frameworks.  Conforming
     VROs MAY be referenced within audit, certification, and regulatory
     artefacts produced under:

     ISO/IEC 42001:2023 [ISO42001]: AI management-system controls map to
     the eight control areas in this document.

     NIST AI Risk Management Framework [NIST-AI-RMF]: Functions (Govern,
     Map, Measure, Manage) map to evidence categories within the eight
     control areas.

     EU AI Act [EU-AI-ACT]: Provider and deployer obligations MAY be
     evidenced through conforming VROs where the obligation is verifiable
     through reconcilable evidence.  The EU AI Act remains authoritative
     for legal compliance determinations.

     ISO/IEC 27001:2022 [ISO27001]: AI control areas intersecting
     information security are interoperable with ISO 27001 Annex A
     controls.

     Essential Eight Verified
     [I-D.hillier-certisyn-essential-eight-verified] cross-references
     application control, privilege restriction, and authentication
     evidence categories.








  Hillier                 Expires 14 November 2026               [Page 11]


  Internet-Draft           AI Governance Verified                 May 2026


  10.  Conformance

     An attestation artefact MAY claim conformance to this standard if and
     only if it satisfies every requirement specified in this document.
     Partial conformance is not recognised.  Variant conformance to a
     subset of control areas without the full eight-area scope is not
     recognised.

     The public attestation registry constitutes the authoritative record
     of issued VROs.

  11.  IANA Considerations

     This document has no IANA actions.

  12.  Security Considerations

     Agentic AI governance operates under adversarial conditions distinct
     from traditional cybersecurity.  Implementations of this standard
     SHOULD pay particular attention to prompt-injection resistance,
     model-drift detection, and exfiltration paths through AI channels
     that may bypass traditional data-loss-prevention controls.

     Issuing Partners are required to be independent from the Subject
     Entity and from Model Providers whose models are within attestation
     scope.

     The Anchor Event binding SHOULD use a digest algorithm of at least
     256-bit strength and a public settlement layer with no single private
     operator capable of extinguishing the binding.

     This standard does not address the correctness or safety of the AI
     Systems being governed.  It addresses the verifiability of governance
     applied to those systems.

  13.  References

  13.1.  Normative References

     [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
                Requirement Levels", BCP 14, RFC 2119,
                DOI 10.17487/RFC2119, March 1997,
                <https://www.rfc-editor.org/rfc/rfc2119>.

     [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
                2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
                May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.




  Hillier                 Expires 14 November 2026               [Page 12]


  Internet-Draft           AI Governance Verified                 May 2026


  13.2.  Informative References

     [EU-AI-ACT]
                Union, E., "Regulation (EU) 2024/1689 — Artificial
                Intelligence Act", 2024.

     [I-D.hillier-certisyn-essential-eight-verified]
                Hillier, J. D., "Essential Eight Verified — A
                Cryptographic Verification Standard for the ACSC Essential
                Eight Maturity Model", May 2026.

     [ISO27001] Standardization, I. O. for., "Information security,
                cybersecurity and privacy protection — Information
                security management systems — Requirements", ISO/
                IEC 27001:2022, 2022.

     [ISO42001] Standardization, I. O. for., "Information technology —
                Artificial intelligence — Management system", ISO/
                IEC 42001:2023, 2023.

     [NIST-AI-RMF]
                Technology, N. I. of S. and., "AI Risk Management
                Framework", 2023.

  Acknowledgments

     The author thanks the ANZ Founding Partner cohort for early review of
     this draft.

  Author's Address

     Joel David Hillier
     Certisyn, Inc.
     Email: jhillier@certisyn.com
     URI:   https://certisyn.com/
















  Hillier                 Expires 14 November 2026               [Page 13]


name: draft-helmprotocol-tttps
rev: 03
title: The TLS TimeToken Secure Protocol (tttps://)
time: 2026-04-19T03:37:24Z
group_uri: /api/v1/group/group/1027/
expires: 2026-10-21T03:37:24Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["A2A protocols", "Agent identity/auth", "Other AI/agent"]
tags: []
fetched_at: 2026-05-22T09:24:48.588971+00:00
source: ietf
abstract:
  This document specifies the TLS TimeToken Secure Protocol (tttps://),
     a protocol extension that augments TLS 1.3 [RFC8446] with
     cryptographically verifiable temporal ordering.

     Internet infrastructure assumes that channels are passive: noise is
     random and channel operators have no ordering preferences. This
     assumption is structurally violated when ordering has economic value
     -- NTP servers, BGP routing authorities, DNS resolvers, and
     transaction sequencers all have incentive to misrepresent ordering.
     This document formalises the problem as the Strategic Channel
     Controller Problem (SCCP), absent from classical information theory.

     Temporal ordering attacks are structurally more acute for autonomous
     AI agents than for human participants: as agent reaction times
     converge toward symmetry, ordering advantage can no longer be earned
     through superior human latency.  No existing protocol -- including
     O(n^2) BFT consensus, which tolerates but does not eliminate
     Byzantine nodes -- provides a cryptographic pre-ingestion defense for
     this case.

     TTTPS introduces Proof-of-Time (PoT): a multi-source synthesised
     timestamp protected by the GRG integrity pipeline (Golomb-Rice ->
     Reed-Solomon -> Golay(23,12,7) -> HMAC), whose stage ordering is
     mathematically necessary (Theorems 1-3 of the companion paper
     [POT2026]).  PoT achieves Byzantine temporal elimination at O(1) per
     record, independent of network size. An AdaptiveSwitch mechanism
     makes ordering manipulation economically self-defeating; the
     equilibrium threshold is derived in closed form and empirically
     calibrated from deployed data (Section 6.4).

     Deployment on Base Sepolia produces 70,000+ verified records; 55% are
     generated by autonomous AI agents -- an unanticipated finding that
     confirms the structural severity of the ordering problem in agent
     economies.

     This document has Experimental status.  The GRG pipeline
     specification will be published upon conclusion of pending patent
     proceedings (Section 12).

full_text:
  Network Working Group                                         H. Jorgen
  Internet-Draft                                               Kenosian
  Intended status: Experimental                             16 April 2026
  Expires: 16 October 2026

           The TLS TimeToken Secure Protocol (tttps://)
                 draft-helmprotocol-tttps-03

  Abstract

     This document specifies the TLS TimeToken Secure Protocol (tttps://),
     a protocol extension that augments TLS 1.3 [RFC8446] with
     cryptographically verifiable temporal ordering.

     Internet infrastructure assumes that channels are passive: noise is
     random and channel operators have no ordering preferences. This
     assumption is structurally violated when ordering has economic value
     -- NTP servers, BGP routing authorities, DNS resolvers, and
     transaction sequencers all have incentive to misrepresent ordering.
     This document formalises the problem as the Strategic Channel
     Controller Problem (SCCP), absent from classical information theory.

     Temporal ordering attacks are structurally more acute for autonomous
     AI agents than for human participants: as agent reaction times
     converge toward symmetry, ordering advantage can no longer be earned
     through superior human latency.  No existing protocol -- including
     O(n^2) BFT consensus, which tolerates but does not eliminate
     Byzantine nodes -- provides a cryptographic pre-ingestion defense for
     this case.

     TTTPS introduces Proof-of-Time (PoT): a multi-source synthesised
     timestamp protected by the GRG integrity pipeline (Golomb-Rice ->
     Reed-Solomon -> Golay(23,12,7) -> HMAC), whose stage ordering is
     mathematically necessary (Theorems 1-3 of the companion paper
     [POT2026]).  PoT achieves Byzantine temporal elimination at O(1) per
     record, independent of network size. An AdaptiveSwitch mechanism
     makes ordering manipulation economically self-defeating; the
     equilibrium threshold is derived in closed form and empirically
     calibrated from deployed data (Section 6.4).

     Deployment on Base Sepolia produces 70,000+ verified records; 55% are
     generated by autonomous AI agents -- an unanticipated finding that
     confirms the structural severity of the ordering problem in agent
     economies.

     This document has Experimental status.  The GRG pipeline
     specification will be published upon conclusion of pending patent
     proceedings (Section 12).

  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), its areas, and its working groups.  Note that
     other groups may also distribute working documents as
     Internet-Drafts.

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

     The list of current Internet-Drafts can be accessed at
     https://www.ietf.org/1id-abstracts.html

     The list of Internet-Draft Shadow Directories can be accessed at
     https://www.ietf.org/shadow.html

     This Internet-Draft will expire on 10 October 2026.

  Copyright Notice

     Copyright (c) 2026 IETF Trust and the persons identified as the
     document authors.  All rights reserved.

     This document is subject to BCP 78 and the IETF Trust's Legal
     Provisions Relating to IETF Documents
     (https://trustee.ietf.org/license-info) in effect on the date of
     publication of this document.  Please review these documents
     carefully, as they describe your rights and restrictions with
     respect to this document.  Code Components extracted from this
     document must include Simplified BSD License text as described in
     Section 4.e of the Trust Legal Provisions and are provided
     without warranty as described in the Simplified BSD License.

  ============================================================
  TABLE OF CONTENTS
  ============================================================

  1.  Introduction
      1.1.  Why This Protocol, Why Now
      1.2.  Objectives
      1.3.  Protocol Overview
      1.4.  Scope
      1.5.  Terminology

  2.  Use Cases and Operational Requirements
      2.1.  Satellite Communication Networks
      2.2.  5G/6G Core Network Ordering
      2.3.  Financial Infrastructure Timestamping
      2.4.  AI Agent Networks
      2.5.  Operational Requirements Summary

  3.  Requirements Language

  4.  Problem Statement
      4.1.  Documented Temporal Ordering Failures
      4.2.  SS7/SCCP Legacy Infrastructure as SCCP Instance
      4.3.  Existing Mitigations and Their Limitations

  5.  Proof-of-Time Structure
      5.1.  PoT Wire Format
      5.2.  Field Definitions
      5.3.  Generation Algorithm
      5.4.  On-Chain Commitment
      5.5.  Verification

  6.  GRG Integrity Pipeline
      6.1.  External Interface
      6.2.  Context Binding
      6.3.  Stage External Properties
      6.4.  Stage Ordering Rationale
      6.5.  Verification Sequence

  7.  AdaptiveSwitch
      7.1.  State Machine
      7.2.  Transition Conditions and Hysteresis
      7.3.  Penalty and Exponential Backoff
      7.4.  Equilibrium Analysis

  8.  Transport Binding
      8.1.  TLS 1.3 via TLS Exporter Label
      8.2.  QUIC Integration
      8.3.  HTTP/3 Frame Type
      8.4.  Handshake Flow Diagrams
      8.5.  Backward Compatibility

  9.  Tier Structure

  10. Security Considerations
      10.1. NTP MITM Attacks
      10.2. Replay Prevention
      10.3. Sybil Time Sources
      10.4. Side-Channel Considerations
      10.5. Byzantine Economic Attacks
      10.6. Delay-Based Temporal Attacks
      10.7. GRG Pipeline Security

  11. Privacy Considerations
      11.1. Unlinkability
      11.2. Minimal Disclosure

  12. IANA Considerations
      12.1. TLS Exporter Labels Registry
      12.2. TTTPS Tier Registry
      12.3. Time Source Type Registry
      12.4. HTTP/3 Frame Type Registry
      12.5. PoT Extension Type

  13. Intellectual Property

  14. References
      14.1. Normative References
      14.2. Informative References

  15. Implementation Status
      15.1. Reference Implementation
      15.2. Deployment Evidence
      15.3. Interested Parties

  Appendix A.  AdaptiveSwitch TLA+ Specification
  Appendix B.  GRG Pipeline Specification (Placeholder)
  Appendix C.  Test Vectors
  Appendix D.  FILO+GRG Delay Rejection Flow


  ============================================================
  DISCUSSION NOTE
  ============================================================

  This document is being discussed on the dispatch@ietf.org
  mailing list.  The authors have submitted a BoF request for
  IETF 126 (Vienna, July 2026) targeting the DISPATCH working
  group.  Comments and participation are welcome.

  Changes from -02:
    o  New §1.1: "Why This Protocol, Why Now"
    o  New §2: Use Cases (satellite, 5G, financial, AI agents)
    o  New §4.2: SS7/SCCP Legacy Infrastructure as SCCP Instance
    o  New §10.8: Path Manipulation Attack Scenarios (3 scenarios)
    o  New §10.9: Trust Model and Key Compromise Resilience
    o  New §15: Implementation Status (RFC 7942)
    o  §5.5 Verification: future-timestamp check, TLS binding step
    o  References: SS7-VULN, GSMA-SS7, GPS-SPOOF, RFC6962, RFC9557

  ============================================================
  SECTION 1.  INTRODUCTION
  ============================================================

  Every major class of internet ordering attack -- BGP hijacking that
  disrupts routing priority, NTP amplification attacks that bias
  financial settlement windows, SS7 gateway compromise that enables
  silent path manipulation -- shares one root cause: the network
  layer cannot prove WHEN an event occurred.

  TLS proves WHO sent a message.  DNSSEC proves WHAT the content is.
  No standard protocol proves WHEN -- in a manner cryptographically
  verifiable by any party without trusting any single intermediary.
  This document closes that gap.

  The gap is not theoretical.  SS7, the signaling protocol underlying
  most of the world's telephone and mobile infrastructure, was designed
  in 1975 with no sender authentication.  An operator controlling an
  SS7 gateway can silently reroute traffic, inject false location
  updates, and modify inter-operator timestamps without detection at
  the application layer [SS7-VULN].  TTTPS is specifically designed
  to operate above such an untrusted substrate: its Proof-of-Time
  (PoT) is path-independent, meaning that no network-layer
  manipulation -- including SS7 gateway compromise -- can produce a
  valid PoT without access to the Issuer's Ed25519 private key.

  The urgency of this gap has increased along two independent
  dimensions.  First, autonomous AI agents executing financial
  transactions at machine speed have eliminated the latency buffer
  that historically made human-scale ordering fraud detectable
  [Zhang2026].  Second, 70,612 PoT records generated over six months
  of experimental deployment reveal that 55% originate from AI agents
  -- an unanticipated finding that confirms ordering manipulation is
  already an operational problem, not a future risk.

  TTTPS introduces Proof-of-Time (PoT): a multi-source synthesised
  timestamp protected by the GRG integrity pipeline, bound to a
  cryptographic context identifier, and verifiable at O(1) cost
  independent of network size.  TTTPS does not require trust in any
  single time source, any network path, or any SS7/SCCP gateway.

  1.1.  Why This Protocol, Why Now

     Three converging developments make this the appropriate moment
     for standardisation:

     (a) Infrastructure exposure.  Documented SS7 vulnerabilities
         [SS7-VULN] enable timestamp manipulation at the signaling
         layer without application-layer detection.  No existing
         protocol -- NTS [RFC8915], PTP [IEEE1588], or Roughtime
         [RFC9557] -- provides a path-independent temporal proof
         at the application layer.

     (b) Agent proliferation.  As autonomous AI agents execute
         ordering-sensitive transactions at machine speed [Zhang2026],
         the window for human detection of temporal manipulation
         collapses.  Protocol-layer enforcement becomes necessary.

     (c) Running code.  A reference implementation [OPENTTT] is
         deployed and has generated 70,612 verified PoT records.
         The experimental data (Section 15.2) demonstrates both
         the technical viability and the demand for the protocol.

  1.2.  Objectives

     The objectives of TTTPS are as follows:

     o  Temporal origin authentication: prove "when" a message
        originated, complementing TLS's proof of "who".

     o  Byzantine time source elimination: transform detection
        probability from P(detect) < 1 (Shannon model) to
        P(detect) >= 1 - 2^{-61} via GRG context binding.

     o  Delay attack prevention: enforce that PoT submissions
        outside the tier tolerance window are rejected pre-ingestion,
        as defined for delay attacks in [RFC8915] Section 8.6.

     o  Economic eviction of dishonest nodes: via AdaptiveSwitch
        equilibrium threshold V*, below which ordering manipulation
        is self-defeating.

     o  Transport-layer agnosticism: operate over TLS 1.3 [RFC8446],
        QUIC [RFC9000], and HTTP/3 [RFC9114] without modification to
        those protocols.

     o  Backward compatibility: deployable alongside existing TLS 1.3
        without requiring server-side changes.

     o  Experimental deployment: accumulate implementation experience
        prior to consideration for the Standards Track.

     o  Privacy-preserving temporal attestation: PoT binds to context
        without revealing transaction content or participant identity.

     Primary use cases include MEV-resistant decentralised exchange
     (DEX) transaction ordering, AI agent-to-agent payment sequencing,
     IoT mission-critical command ordering, and financial settlement
     timestamping.

  1.3.  Protocol Overview

     TTTPS operates in two phases:

     Phase 1 -- PoT Generation:

        Client                              PoT Issuer
          |                                      |
          |--- Time synthesis request ---------->|
          |                                      | Query NIST, Google,
          |                                      | Cloudflare NTP (k>=3)
          |                                      | T=median(T_1..T_k)     
          |                                      |
          |<-- PoT record (signed) -------------|
          |    [ts | ctx_id | nonce |            |
          |     grg_commitment | Ed25519_sig]    |

     Phase 2 -- TLS Binding (TLS Exporter, RFC 5705):

        Client                              Server
          |--- TLS ClientHello -------------->|
          |<-- TLS ServerHello + ... ---------|
          |<-- TLS Finished -----------------|
          |                                   |
          |  Both derive PoT binding key:     |
          |  EXPORTER-tttps-pot-binding       |
          |  = TLS-Exporter(label, pot_bytes, |
          |                 32 octets)        |
          |                                   |
          |--- 1-RTT[PoT frame] ------------>|
          |<-- 1-RTT[PoT-Ack] --------------|

     Byzantine nodes that submit manipulated ordering are identified
     with probability >= 1 - 2^{-61} and economically penalised
     via AdaptiveSwitch FULL mode.

     TTTPS does NOT modify the TLS handshake.  No new TLS Extension
     Type is required.  This approach follows RFC 8915 Section 5.1.

  1.4.  Scope

     This document specifies:
     o  The PoT data structure and wire format (Section 4)
     o  The GRG Integrity Pipeline abstract interface (Section 5)
     o  The AdaptiveSwitch Byzantine eviction mechanism (Section 6)
     o  The TTTPS transport binding (Section 7)

     This document does NOT specify:
     o  Concrete implementation of GRG pipeline cryptographic
        operations (covered by pending patent; see Section 12)
     o  Specific NTP server selection policies
     o  Smart contract implementations for on-chain anchoring
     o  Pricing or fee schedules (implementation-defined; Section 8)
     o  Satellite deployment specifics (see Section 2.1)

  1.5.  Terminology

     The key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
     "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED",
     "NOT RECOMMENDED", "MAY", and "OPTIONAL" are interpreted
     as described in BCP 14 [RFC2119] [RFC8174].

     SCCP (Strategic Channel Controller Problem):
        A system satisfies SCCP if (i) a controller C has authority
        over message ordering; (ii) U(C) is strictly monotone in
        that ordering; (iii) no external party can verify original
        ordering without C's cooperation.  Instances include NTP
        timestamp bias, BGP hijacking, DNS poisoning, and
        transaction sequencer MEV.

     Proof-of-Time (PoT):
        A cryptographically authenticated record of a synthesised
        timestamp, bound to a context identifier via GRG context
        binding, and protected against replay and delay.

     GRG Pipeline:
        A four-stage integrity pipeline: G_1 (Golomb-Rice encoding),
        R (Reed-Solomon erasure coding), G_2 (Golay(23,12,7) forward
        error correction), H (HMAC-SHA256 context binding).  The
        stage ordering is mathematically necessary (Section 5.4).
        Implementation is proprietary; only the abstract interface
        and external properties are specified here.

     AdaptiveSwitch:
        A state machine classifying nodes as TURBO (ordering-
        compliant, ~50 ms verification, 20% fee discount) or FULL
        (potentially Byzantine, ~127 ms, exponential backoff).

     Byzantine Time Attack:
        An adversarial action in which a network participant reports
        a fabricated or manipulated timestamp to gain ordering
        advantage.

     V* (Equilibrium threshold):
        V* = c_0 + lambda * Delta_tau.  For MEV opportunity value
        V < V*, ordering manipulation is eliminated in the unique
        symmetric Nash equilibrium.  Empirically calibrated from
        151,423 Timeboost auctions: V* in [$8.67, $87.13].

     FILO+GRG:
        The processing discipline in which PoT submissions are
        subject to two sequential gates (HMAC context gate, then
        AdaptiveSwitch recency gate) before entering the processing
        queue; within the queue, the most recently generated
        qualifying PoT is processed first.

     PoT Issuer:
        An entity authorised to generate and sign PoT records.
        Analogous in function to a Certificate Authority, but
        attesting time rather than identity.

     Tier:
        An ordered set of time resolution levels (T0_epoch through
        T3_micro) controlling the tier tolerance window for PoT
        submission recency.  See Section 8.


  ============================================================
  SECTION 2.  USE CASES AND OPERATIONAL REQUIREMENTS
  ============================================================

  This section describes deployment scenarios in which existing
  protocols (NTS, PTP, Roughtime) are insufficient and TTTPS
  provides the necessary path-independent temporal proof.

  2.1.  Satellite Communication Networks

     Satellite operators route traffic through ground station
     networks that frequently traverse SS7/SCCP signaling
     infrastructure at terrestrial interconnects.  An operator
     controlling a gateway at such an interconnect can:

     o  Introduce artificial delays in timestamp synchronisation
        messages without detection at the application layer.

     o  Reroute uplink/downlink traffic to infer ordering
        information about competing satellite operators.

     GEO satellite round-trip times (~600 ms) fall within the
     T1_block tier tolerance (2,000 ms), making TTTPS directly
     applicable.  T-s1 (Earth-Moon, 3,000 ms) extends coverage
     to lunar relay scenarios.

     Operational requirement: temporal proof that is independent
     of the ground network path.  TTTPS satisfies this because
     GRG_Commitment = GRG(P || D_chain, ctx_id), where D_chain
     is derived from k >= 3 independent Roughtime sources queried
     before path traversal.  No ground-path manipulation after
     generation can alter a valid PoT.

  2.2.  5G/6G Core Network Ordering

     5G core networks (3GPP Release 17+) use Service Based
     Architecture (SBA) in which Network Functions (NFs) exchange
     ordering-sensitive messages over HTTP/2.  Many 5G deployments
     retain SS7-based interworking for legacy roaming.

     The N9 interface (UPF-to-UPF) and N14 interface (AMF-to-AMF)
     carry ordering-sensitive session establishment messages.
     A compromised SS7 interworking function can inject ordering
     manipulation at the MAP layer without HTTP/2-layer detection.

     TTTPS provides a transport-layer-agnostic temporal proof
     (Section 8) that operates over HTTP/3 without modification
     to 3GPP interfaces.  T3_micro tier (100 ms) is appropriate
     for latency-sensitive 5G ordering.

     Operational requirement: sub-100ms ordering proof that
     survives SS7 interworking path traversal.

  2.3.  Financial Infrastructure Timestamping

     MiFID II (EU) and CAT (US) require submillisecond-accurate
     timestamps for regulated financial transactions.  GPS-based
     timing, the current industry standard, is vulnerable to
     spoofing attacks that can shift reported timestamps by
     seconds [GPS-SPOOF].

     TTTPS provides a multi-source temporal proof that detects
     GPS spoofing: if the GPS-derived timestamp diverges from the
     Roughtime-derived median by more than stratum_tolerance, PoT
     generation ABORTS (Section 5.3, step 3).  This transforms
     GPS spoofing from an undetectable manipulation into a
     verifiable abort condition.

     Operational requirement: regulatorily auditable timestamp
     that survives GPS spoofing and does not depend on any single
     time infrastructure provider.

  2.4.  AI Agent Networks

     Autonomous AI agents executing financial or coordination
     transactions at machine speed generate ordering-sensitive
     messages at rates that eliminate human-scale audit cycles.
     The experimental deployment (Section 15.2) found that 55%
     of all PoT records were generated by AI agents -- a finding
     consistent with [Zhang2026] predictions about agent economies.

     As agent reaction times converge toward network propagation
     delay, ordering advantage can no longer be earned through
     superior reaction time.  The remaining mechanism for ordering
     advantage is timestamp manipulation -- precisely the attack
     class TTTPS addresses.

     Operational requirement: O(1) temporal verification that
     scales to agent transaction rates without BFT overhead.

  2.5.  Operational Requirements Summary

     The use cases above share four requirements that existing
     protocols do not jointly satisfy:

     R1.  Path independence: temporal proof must be valid
          regardless of which network path (including SS7/SCCP)
          the PoT traverses after generation.

     R2.  Cross-domain verification: proof must be verifiable
          by parties without access to the generation environment.

     R3.  Pre-ingestion enforcement: invalid ordering must be
          detectable before the record enters system state,
          not after (unlike Roughtime's audit-only model).

     R4.  O(1) scalability: verification cost must be independent
          of network size and number of participants.

     Table R: Protocol Coverage of Operational Requirements.

                 | R1 Path  | R2 Cross | R3 Pre-  | R4 O(1)
                 | Indep.   | Domain   | Ingest.  | Scale
     ------------|----------|----------|----------|--------
     NTS [8915]  | No       | No       | No       | Yes
     PTP [1588]  | No       | No       | No       | Yes
     Roughtime   | Partial  | Partial  | No       | O(log n)
     TTTPS       | Yes      | Yes      | Yes      | Yes


  ============================================================
  SECTION 3.  REQUIREMENTS LANGUAGE
  ============================================================

  The key words "MUST", "MUST NOT", etc. in this document are to
  be interpreted as described in BCP 14 [RFC2119] [RFC8174] when,
  and only when, they appear in all capitals.


  ============================================================
  SECTION 4.  PROBLEM STATEMENT
  ============================================================

  4.1.  Documented Temporal Ordering Failures

     The following documented attack classes motivate TTTPS.
     Each represents a deployed instance of the Strategic Channel
     Controller Problem (SCCP, Section 1.5) in which an ordering
     authority has both capability and incentive to misrepresent
     temporal ordering.

     (a) SS7 timestamp manipulation.  The SS7 MAP protocol,
         used for inter-operator roaming signaling, transmits
         location and timing information without sender
         authentication.  A gateway operator can inject false
         MAP UpdateLocation messages to shift perceived timestamps
         by seconds without detection [SS7-VULN][GSMA-SS7].
         This is not a theoretical risk: SS7 attacks have been
         demonstrated against live networks in multiple countries.

     (b) BGP route hijacking.  An AS operator controlling routing
         can reroute traffic to create artificial ordering delays.
         The 2010 China Telecom BGP incident diverted US military
         traffic for 18 minutes.  Application-layer timestamps
         recorded during such diversions cannot be verified.

     (c) NTP amplification and bias.  An NTP server operator can
         bias returned timestamps by amounts below stratum-check
         thresholds, shifting financial settlement windows by
         sub-second amounts sufficient to capture MEV ($0.11-
         $1.13/ms, calibrated from 151,423 Timeboost auctions
         [Messias2025]).

     (d) GPS spoofing.  Civilian GPS signals are unencrypted.
         Spoofing hardware costing under $500 can shift GPS-
         derived timestamps by seconds within a local area
         [GPS-SPOOF].  MiFID II-compliant systems relying solely
         on GPS timestamps are vulnerable.

     The common thread: in each case, a single infrastructure
     operator can manipulate temporal ordering without producing
     any detectable artefact at the application layer.  TTTPS
     closes this gap by requiring that temporal ordering be
     cryptographically provable independent of any single
     infrastructure operator.

  4.2.  SS7/SCCP Legacy Infrastructure as SCCP Instance

     SS7 (Signaling System 7), designed in 1975, is the signaling
     backbone of the global telephone network and underlies most
     mobile roaming.  Its MAP, ISUP, and SCCP sub-protocols were
     designed for a closed network of trusted operators.  They
     contain no mechanisms for:

     o  Sender authentication of signaling messages
     o  Integrity protection of timestamp fields
     o  Detection of message injection or replay
     o  Path verification for routed messages

     These omissions create the following SCCP instances
     (using Definition 1.1.4 from Section 1.5):

     Gateway timestamp injection:
        An SS7 gateway operator (controller C) can modify
        timestamp fields in MAP messages without the receiving
        party detecting the modification.  The receiving party's
        utility U(C) depends on the ordering implied by those
        timestamps (SCCP condition (ii) satisfied).  No external
        party can verify the original timestamp without C's
        cooperation (condition (iii) satisfied).

     Silent traffic rerouting:
        An SS7 SCCP (Signaling Connection Control Part) layer
        operator can reroute message traffic to alternate paths,
        introducing artificial delays that bias temporal ordering
        without any application-layer signal.

     Location tracking enabling ordering inference:
        SS7 MAP UpdateLocation messages can be used to track
        the geographic location of network nodes.  An attacker
        with this information can infer network topology and
        exploit propagation-delay asymmetry for ordering advantage.

     TTTPS defense: The GRG_Commitment is generated from
     multi-source Roughtime data BEFORE path traversal.  No SS7
     gateway manipulation after generation can alter a committed
     PoT without access to the Issuer's Ed25519 private key.
     TTTPS assumes no trust in any network layer below TLS.

     This constitutes what we term "untrusted substrate operation":
     TTTPS provides temporal ordering guarantees even when the
     underlying network infrastructure (including SS7/SCCP
     gateways) is controlled by an adversary.

  4.3.  The Shannon Gap: SCCP

     Shannon (1948) modelled a channel as Y = X + N_rand, where
     noise N is random and the channel operator is passive.
     All subsequent coding theory, information theory, and
     cryptographic channel models assume NOT-SCCP.

     This assumption is structurally violated by modern internet
     infrastructure.  Table 1 maps documented attack classes to
     SCCP Definition 1.1.4 (Section 1.5).

     Table 1: SCCP instances in deployed infrastructure.

     Domain        | SCCP mechanism                | lambda
     --------------|-------------------------------|------------------
     NTP server    | Timestamp bias shifts         | Low
                   | settlement windows            |
     BGP router    | Traffic rerouting disrupts    | Medium
                   | ordering                      |
     DNS resolver  | Forged response wins          | Low
                   | temporal race                 |
     SS7/MAP       | Gateway compromise enables    | High
     gateway       | silent timestamp injection    | (infra-level)
                   | without application detection |
     Tx sequencer  | Reordering extracts MEV       | $0.11--1.13/ms
     AI agent      | Agent ordering captures       | High (scaling)
     coordinator   | surplus                       |

     Shannon's noise model has no mechanism for strategic N.
     PoT changes this: Byzantine manipulation becomes
     cryptographically self-identifying and economically
     self-penalising.

  4.4.  Existing Mitigations and Their Limitations

     Table 2: Comparison with existing temporal protocols.

                   | Roughtime | NTS/PTP   | PoT
     --------------|-----------|-----------|------------------
     Timing        | Retro.    | Session   | Pre-ingestion
     Enforcement   | Signal    | Reject    | Economic penalty
     Cross-domain  | No        | No        | Yes
     SCCP          | No        | No        | Yes
     Complexity    | O(log n)  | O(1)      | O(1) per record
     BFT overhead  | N/A       | N/A       | O(1) vs O(n^2)

     All existing BFT protocols (PBFT [RFC], Tendermint, HotStuff)
     TOLERATE f < n/3 Byzantine nodes with O(n^2) message complexity.
     PoT ELIMINATES Byzantine ordering manipulation at O(1) per
     record: the manipulation is not outvoted but cryptographically
     identified and economically penalised.  As network size grows
     from n to 10n, BFT overhead grows 100x; PoT overhead is
     unchanged.

     The urgency of this gap has increased as AI systems acquire
     autonomous capability to identify and exploit protocol-layer
     vulnerabilities without human direction [GLASSWING].  The
     same agentic capabilities that enable autonomous security
     research equally enable autonomous temporal attack on
     ordering-sensitive networks.  TTTPS provides a pre-ingestion
     cryptographic defense that is independent of network size and
     agent count.


  ============================================================
  SECTION 4.  PROOF-OF-TIME STRUCTURE
  ============================================================

  4.1.  PoT Wire Format

     A PoT record is encoded as a fixed-structure binary sequence.
     All multi-byte integer fields are in network byte order
     (big-endian).

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  Version (4)  |   Tier (4)    |  Source Cnt   |   Reserved    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     +                     Timestamp (64 bits)                       +
     |                     nanoseconds since epoch                   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                   Confidence (32 bits)                        |
     |                   parts-per-million                           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     +                                                               +
     |                      Nonce (256 bits)                         |
     +                      cryptographically random                 +
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     +                                                               +
     |                  GRG Commitment (256 bits)                    |
     +                  output of GRG pipeline                       +
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     +                                                               +
     |                  Ed25519 Signature (512 bits)                 |
     +                  over all preceding fields                    +
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     Total: 3 + 8 + 4 + 32 + 32 + 64 = 143 bytes.
     (Version[1B] + SourceCnt[1B] + Reserved[1B] = 3 bytes
      for the header row; all remaining fields as shown.)

  4.2.  Field Definitions

     Version (4 bits):
        Protocol version.  This document defines version 1 (0x1).
        Implementations MUST reject PoT records with unknown versions.

     Tier (4 bits):
        Identifies the time resolution level (Section 8).
        Values: 0x0 = T0_epoch, 0x1 = T1_block, 0x2 = T2_slot,
        0x3 = T3_micro.  Values 0x4-0xF are reserved.

     Source Count (8 bits):
        Number of independent NTP sources consulted.
        MUST be >= 3.  Implementations SHOULD use >= 4.

     Reserved (8 bits):
        MUST be set to 0x00 by senders.
        Receivers MUST ignore this field.

     Timestamp (64 bits):
        Synthesised timestamp: T_synth = median(T_1, ..., T_k),
        k >= 3 sources from independent domains.  Nanoseconds
        since Unix epoch.  Synthesis MUST use at least three
        independent sources from distinct administrative domains
        (e.g., NIST, Google, Cloudflare).

     Confidence (32 bits):
        Synthesis quality metric in parts-per-million.  Computed
        from inter-source agreement.  Values above 1,000,000 ppm
        MUST NOT be issued.

     Nonce (256 bits):
        Cryptographically random value.  MUST be generated with
        a cryptographically secure random number generator.
        Provides replay prevention in conjunction with Section 9.2.

     GRG Commitment (256 bits):
        Output of the GRG Integrity Pipeline (Section 5) applied
        to the preceding fields.  The commitment cryptographically
        binds the PoT payload to its context (chain_id, pool_address).

     Ed25519 Signature (512 bits):
        Signature over all preceding fields using the PoT Issuer's
        Ed25519 private key [Bernstein2012], following EUF-CMA
        security.  The signature seals the GRG Commitment (double
        seal property, Section 5.2).

        Issuer Integrity Property: The Issuer cannot forge a
        timestamp without detection.  A forged timestamp T' != T
        produces a different payload P', which produces a different
        GRG_Commitment' != GRG_Commitment.  The Ed25519 signature
        over (P || GRG_Commitment) then fails verification against
        the published Issuer public key.  This is a mathematical
        consequence of EUF-CMA security, not a procedural control.

        The remaining trust assumption is that the Issuer's private
        key is not compromised.  This is the same trust model as
        PKI (Certificate Authority), applied to time rather than
        identity.  Issuer misbehaviour is auditable via the
        on-chain commitment (Section 4.4).

  4.3.  Generation Algorithm

     1.  Query k >= 3 NTP sources from independent domains.
     2.  Compute T_synth = median(T_1, ..., T_k).
     3.  If max|T_i - T_synth| > stratum_tolerance: ABORT.
     4.  Generate 256-bit cryptographically random Nonce.
     5.  Assemble payload P = [Version | Tier | Source_Cnt |
         Reserved | Timestamp | Confidence | Nonce].
     6.  Compute GRG_Commitment = GRG(P, ctx_id) (Section 5).
     7.  Compute Sig = Ed25519.Sign(sk, P || GRG_Commitment).
     8.  Output PoT = P || GRG_Commitment || Sig.

  4.4.  On-Chain Commitment

     TTTPS is a TLS-layer protocol.  The on-chain component serves
     as a tamper-evident audit log -- not as the application target
     or consensus mechanism.  Blockchain is the verification
     substrate; it records PoT commitments for independent audit.

     The on-chain anchor is the keccak256 hash of the PoT record:

        on_chain_hash = keccak256(ABI_encode(
            timestamp, grg_commitment, ctx_id, nonce))

     This provides an immutable public record independently of
     the TTTPS protocol layer.  Verifiers MAY cross-check the
     on-chain record to audit Issuer behaviour over time.
     Deployments that do not require on-chain audit MAY omit
     this step; the core protocol (Sections 4.1-4.5) functions
     without it.

  4.5.  Verification

     Implementations MUST verify PoT records in the following order:

     0.  Future-timestamp rejection (defense-in-depth):
         If timestamp > submission_time: REJECT.
         Rationale: Ed25519 EUF-CMA prevents forged future PoTs
         at the cryptographic level, but this explicit check
         provides defense-in-depth against implementation errors.

     1.  Version check: reject unknown versions.

     1a. TLS binding verification (normative):
         If PoT frame includes binding_key (Section 8.1):
         expected_key = TLS-Exporter(
             "EXPORTER-tttps-pot-binding", pot_without_sig, 32)
         If expected_key != binding_key_in_frame: REJECT.
         Prevents cross-session replay (Section 10.8.1).

     1b. Roughtime chain integrity (normative):
         D_chain = SHA-256(k Roughtime attestations)
         GRG_Commitment = GRG(P || D_chain, ctx_id)
         Theorem 0 (Inflow-to-Proof): forged timestamp T' != T
         produces GRG_Commitment' != GRG_Commitment.
         Issuer timestamp manipulation is mathematically detectable.

     2.  HMAC context gate (~6 microseconds):
         Recompute HMAC(k, shard_i) for all shards.
         If any HMAC fails: REJECT immediately.
         DO NOT proceed to Ed25519 verification.
         NOTE: HMAC-first order yields 16x cost reduction on
         invalid submissions.

     3.  Ed25519 signature verification (~46 microseconds):
         Verify Sig over the full PoT record.
         Ed25519 is called once per TLS session establishment,
         not per packet.  Per-packet protection uses AEAD
         (Section 9.9).

     4.  Recency check (AdaptiveSwitch gate, Section 7):
         If submission_time - timestamp > tier_tolerance: REJECT.
         Trigger FULL mode per Section 7.3.

     5.  Nonce freshness: reject duplicate nonces.

     NOTE: The HMAC-first verification order (step 2 before step 3)
     achieves 16x cost reduction on invalid submissions.  Invalid
     context binding -- which includes delayed resubmissions of
     valid PoTs in a different execution context -- is detected at
     the HMAC layer without incurring Ed25519 overhead.


  ============================================================
  SECTION 5.  GRG INTEGRITY PIPELINE
  ============================================================

  5.1.  External Interface

     The GRG pipeline accepts a payload P and a context identifier
     ctx_id, and produces a 256-bit commitment:

        GRG_Commitment = GRG(P, ctx_id)

     Implementations of the GRG interface MUST satisfy:

     o  Lossless round-trip: GRG_Inverse(GRG(P)) = P
     o  Erasure tolerance: any k of n shards reconstruct P
        (where k and n are implementation-defined, minimum k=4, n=6)
     o  Bit-error correction: up to t=3 bit errors per 23-bit block
        are corrected
     o  Context binding: GRG(P, ctx_id_A) != GRG(P, ctx_id_B)
        for ctx_id_A != ctx_id_B, with probability >= 1 - 2^{-61}

     Full pipeline specification is in Appendix B.  Reference
     implementation: [OPENTTT].

  5.2.  Context Binding

     The HMAC context key is derived as:

        k = keccak256(chain_id || pool_address)

     NOTE: This key is publicly derivable by design.
     Purpose: domain separation (context binding), NOT secrecy.
     Security model:
       Confidentiality/Authenticity = Ed25519 private key (Issuer)
       Context binding              = HMAC key (public, deterministic)

     Attack prevented: A PoT shard from pool A cannot be
     replayed into pool B even if an attacker knows both HMAC keys,
     because the Ed25519 signature over grg_commitment makes
     cross-context replay detectable at signature verification.

     This follows the domain-separation pattern of TLS 1.3
     key schedule [RFC8446] Section 7.1, where labels are
     public constants providing domain separation without secrecy.

  5.3.  Stage External Properties

     Stage G_1 (Golomb-Rice):
        Achieves Shannon source coding bound for geometric
        distributions.  PoT integer fields (timestamp delta,
        stratum, confidence) are geometrically distributed by
        construction (Poisson inter-arrival times, discretised).
        Output is byte-aligned.  Complexity: O(n).

     Stage R (Reed-Solomon(4,6) over GF(2^8)):
        Achieves the Singleton bound as a Maximum Distance
        Separable (MDS) code.  Any 4 of 6 shards reconstruct
        the original payload.  Fixed-size equal shards output.
        Polynomial: x^8 + x^4 + x^3 + x^2 + 1.

     Stage G_2 (Golay(23,12,7)):
        Achieves the Hamming bound exactly as a perfect code:
        sum_{i=0}^{3} C(23,i) = 2048 = 2^{11}.
        The unique non-trivial binary perfect code with t >= 2
        correction (Tietavainen 1973).  Corrects up to 3 bit
        errors per 23-bit block.  Requires fixed-size input.

     Stage H (HMAC-SHA256, 8-byte tag):
        P(forge) <= 6 * 2^{-64} (union bound over 6 shards).
        Public key by design (context separation, not secrecy).
        Ed25519 seals GRG_Commitment: forging HMAC invalidates
        Ed25519 (double seal property).

  5.4.  Stage Ordering Rationale

     The ordering G_1 -> R -> G_2 -> H is mathematically necessary.
     Any permutation degrades one or more provably tight properties:

     G_1 before R (Theorem 1 of companion paper [POT2026]):
        G_1 output is byte-aligned, providing GF(2^8)-optimal
        symbol boundaries for Reed-Solomon.  Applying R before
        G_1 yields strictly greater RS parity overhead.

     R before G_2 (Theorem 2 of companion paper):
        Golay(23,12,7) requires fixed 23-bit input blocks.
        G_1 output is variable-length.  R produces fixed-size
        equal shards, enabling zero-waste Golay encoding.
        RS and Golay provide orthogonal protection:
        P(fail) = P(RS) * P(Golay) < P(RS) + P(Golay).

     G_2 before H (follows from Theorem 2):
        HMAC seals the post-Golay shards.  Ed25519 wraps
        grg_commitment (double seal).

     These codes were selected for the same reason as deep-space
     missions: provably tight properties when retransmission is
     impossible.  Golomb-Rice: JPL deep-space compression.
     Reed-Solomon: Cassini, Mars rovers.  Golay(23,12,7): Voyager
     1 and 2 Saturn images transmitted across 10^9 km (1980).

  5.5.  Verification Sequence

     See Section 4.5.  HMAC verification MUST precede Ed25519.
     This provides early rejection of context-invalid submissions
     at ~6 microseconds vs ~100 microseconds for Ed25519.


  ============================================================
  SECTION 6.  ADAPTIVESWITCH
  ============================================================

  6.1.  State Machine

     AdaptiveSwitch maintains per-node state in {TURBO, FULL}.

           +-------------------+
      +----|      TURBO        |<---+
      |    | ~50 ms            |    |
      |    | -20% fee          |    | match_rate >= 0.85
      |    | GRG overhead:     |    | (sustained)
      |    | ~0.3 ms/record    |    |
      |    +-------------------+    |
      |         |                   |
      |    match_rate < 0.85   match_rate >= 0.95
      |    OR GRG fail         over 20 blocks
      |         |                   |
      |    +-------------------+    |
      +--->|      FULL         |----+
           | ~127 ms           |
           | standard fee      |
           | backoff applied   |
           +-------------------+

  6.2.  Transition Conditions and Hysteresis

     TURBO entry:
        match_rate >= 0.95 sustained over >= 20 blocks.
        All PoT submissions within tier_tolerance.
        No GRG pipeline failures.

     TURBO maintenance:
        match_rate >= 0.85 (relaxed threshold prevents flapping).

     TURBO -> FULL:
        match_rate < 0.85 over any 20-block window, OR
        any GRG pipeline failure, OR
        any submission outside tier_tolerance (delay attack).

     The hysteresis asymmetry is deliberate: trust is earned
     slowly and lost quickly (hard to earn, easy to lose).

  6.3.  Penalty and Exponential Backoff

     On integrity failure in TURBO mode:
        Backoff penalty = 20 * 2^{f-1} blocks, maximum 320 blocks.
        (f = consecutive failure count)

     On submission outside tier_tolerance:
        Immediate FULL mode transition.
        Backoff applies to TURBO re-entry.

  6.4.  Equilibrium Analysis (V* Threshold)

     Let lambda = operator opportunity cost per millisecond.
     Let c_0 = baseline ordering cost.
     Let Delta_tau = 77 ms (TURBO vs FULL latency difference).

     V* = c_0 + lambda * Delta_tau

     For V < V*: ordering spam eliminated (E[S] = 0) in the
     unique symmetric Nash equilibrium.
     For V >= V*: spam reduced by c_PoT / c_0 factor.

     Empirical calibration from 151,423 Timeboost auctions
     (Arbitrum, April-July 2025):

     Phase           | lambda ($/ms) | V*       | Result
     ----------------|---------------|----------|------------------
     Stable (May+)   | 0.11 - 0.23   | $8.67    | Spam eliminated
     Central est.    | 0.16          | $12.82   | Spam eliminated
     Competitive     | 1.13          | $87.13   | Spam eliminated
     ETH L1 sandwich | --            | ($131)   | Spam reduced

     The Ethereum L1 average sandwich MEV ($131) lies above V*_max,
     consistent with "reduced but not eliminated" for highest-value
     attacks.  For V < $8.67, PoT eliminates ordering manipulation
     entirely.


  ============================================================
  SECTION 7.  TRANSPORT BINDING
  ============================================================

  7.1.  TLS 1.3 via TLS Exporter Label

     TTTPS uses the TLS Exporter mechanism [RFC5705] to derive
     PoT binding material from an established TLS 1.3 session,
     following the model of [RFC8915] Section 5.1.

     This approach requires NO new TLS Extension Type codepoint
     and is fully backward-compatible with existing TLS 1.3
     implementations.  It resolves the codepoint collision risk
     of draft-helmprotocol-tttps-00 (0xFF50, Private Use range).

     Exporter parameters:

        Label:   "EXPORTER-tttps-pot-binding"
        Context: PoT record bytes (all fields except Sig)
        Length:  32 octets

     Usage:

        binding_key = TLS-Exporter("EXPORTER-tttps-pot-binding",
                                    pot_record_without_sig,
                                    32)

     The binding_key MUST be used to verify that the PoT was
     generated within the current TLS session context.  This
     prevents cross-session replay.

     Verification procedure (normative):

     The verifier MUST execute the following after TLS handshake
     completion and upon receiving a PoT frame:

        expected_key = TLS-Exporter(
                         "EXPORTER-tttps-pot-binding",
                          pot_record_without_sig,
                          32)

        If expected_key != binding_key_in_PoT_frame: REJECT.

     The binding_key is carried in the first 32 octets of the
     PoT frame body, preceding the PoT record.  Both client and
     server independently derive the same expected_key from the
     shared TLS session master secret.  A PoT frame generated in
     session A cannot be replayed into session B because the
     TLS-Exporter output is session-specific (derived from the
     session's master secret per RFC 5705 Section 4).

     PoT Frame Extended Format (with binding):

        binding_key  (32 octets) -- TLS Exporter output
        pot_record   (143 octets) -- PoT record (Section 4.1)
        Total: 175 octets

  7.2.  QUIC Integration

     TTTPS operates over QUIC [RFC9000] post-handshake.
     The TLS Exporter is available after QUIC handshake completion.

     QUIC + TTTPS flow:

     Client                              Server
       |--Initial[CRYPTO]-------------->|  (TLS ClientHello)
       |<-Initial[CRYPTO]--------------|  (TLS ServerHello)
       |<-Handshake[CRYPTO]------------|  (TLS EncryptedExtensions)
       |--Handshake[CRYPTO]----------->|  (TLS Finished)
       |                               |
       |  Both derive binding key:     |
       |  TLS-Exporter("EXPORTER-      |
       |  tttps-pot-binding", ...)     |
       |                               |
       |--1-RTT[STREAM:PoT frame]----->|
       |<-1-RTT[STREAM:PoT-Ack]--------|

     PoT frames MUST be sent in a dedicated QUIC stream.
     Stream type: 0x74 (defined in Section 11.4).

  7.3.  HTTP/3 Frame Type

     Over HTTP/3 [RFC9114], PoT records are conveyed in a
     dedicated HTTP/3 frame type.

     HTTP/3 PoT Frame format:

        Frame Type:   0x4C4F5400 (ASCII "LOT\0", IANA assigned,
                      see Section 11.4)
        Frame Length: variable (175 bytes with binding_key,
                      143 bytes for binding-free deployments)
        Frame Body:   PoT record (Section 4.1)

     PoT frames MAY appear in any HTTP/3 request or response stream.
     Servers MUST NOT reject requests solely on the basis of
     absent PoT frames (backward compatibility).

  7.4.  Handshake Flow Diagrams

  7.4.1.  TLS 1.3 Flow

     Client                              Server
       |--ClientHello------------------>|
       |<-ServerHello-------------------|
       |<-EncryptedExtensions-----------|
       |<-Certificate ------------------|
       |<-CertificateVerify-------------|
       |<-Finished----------------------|
       |--[Certificate]---------------->|  (optional)
       |--[CertificateVerify]---------->|  (optional)
       |--Finished--------------------->|
       |                               |
       |  TTTPS binding after Finished:|
       |--Application[PoT frame]------->|
       |<-Application[PoT-Ack]---------|

  7.4.2.  QUIC Flow

     See Section 7.2.

  7.4.3.  HTTP/3 Flow

     Client                              Server
       |--HEADERS[GET /resource]------->|
       |--PoT Frame-------------------->|
       |<-HEADERS[200 OK]---------------|
       |<-DATA[resource]----------------|
       |<-PoT-Ack Frame-----------------|

  7.5.  Backward Compatibility

     Servers that do not implement TTTPS MUST be able to process
     TLS 1.3, QUIC, and HTTP/3 connections that include TTTPS
     binding material.  TTTPS MUST NOT modify the TLS handshake
     in a way that causes negotiation failure with non-TTTPS peers.

     Implementations SHOULD use ALPN [RFC7301] extension identifier
     "tttps/1" (IANA registration, Section 11) to negotiate
     TTTPS capability between peers.


  ============================================================
  SECTION 8.  TIER STRUCTURE
  ============================================================

     TTTPS defines four time resolution tiers:

     Tier        | ID   | Interval  | Tolerance | Use Case
     ------------|------|-----------|-----------|------------------
     T0_epoch    | 0x0  | 6.4 min   | 60 s      | Epoch ordering
     T1_block    | 0x1  | 2 sec     | 2 s       | L2 block (Base)
     T2_slot     | 0x2  | 12 sec    | 12 s      | L1 slot (ETH)
     T3_micro    | 0x3  | 100 ms    | 100 ms    | High-frequency

     Tier tolerance defines the maximum acceptable submission
     delay (submission_time - timestamp).  Submissions outside
     tolerance trigger FULL mode per Section 6.3.

     Fee discounts in TURBO mode are implementation-defined.
     Reference implementation: 20% discount [OPENTTT].


  ============================================================
  SECTION 9.  SECURITY CONSIDERATIONS
  ============================================================

  9.1.  Compromised NTP Sources and Path Attacks

     This section addresses two threat models: compromised NTP
     servers and compromised network paths between the PoT Issuer
     and NTP servers (the standard IETF network adversary model).

     Compromised NTP server:
        A single compromised NTP source biases the synthesised
        timestamp by at most 1/k of the manipulation, where k >= 3
        is the source count.  For k=4 independent sources,
        single-source bias impact <= 0.25 of manipulation magnitude.

     Compromised network path (IETF adversary model):
        An attacker controlling the network path between the Issuer
        and one NTP server can inject delayed or replayed NTP
        responses.  Two mitigations apply:

        (a) Multi-source median: T_synth = median(T_1, ..., T_k)
            across k >= 3 sources from distinct administrative
            domains.  A path-level attacker must simultaneously
            compromise paths to a majority of sources (e.g., both
            NIST and Cloudflare paths) to bias the median.

        (b) Stratum tolerance check (Section 4.3, step 3):
            If max|T_i - T_synth| > stratum_tolerance, generation
            ABORTS.  A single-path delay injection that pushes one
            source beyond tolerance is detected and rejected.

        NTS [RFC8915] on the path between Issuer and NTP servers
        provides an additional layer of path authentication.
        Implementations SHOULD use NTS-authenticated sources where
        available.

     Implementations MUST use sources from distinct administrative
     domains (e.g., NIST, Google, Cloudflare) to maximise
     independence.  Sources from a single autonomous system MUST
     NOT be counted as independent.

  9.2.  Replay Prevention

     Each PoT record includes a 256-bit cryptographically random
     Nonce (Section 4.1).  Verifiers MUST maintain a nonce cache
     for the duration of the tier tolerance window.  Duplicate
     nonces MUST be rejected.

     The Ed25519 signature seals the nonce.  Cross-session replay
     is additionally prevented by the TLS Exporter binding
     (Section 7.1).

  9.3.  Sybil Time Sources

     An attacker controlling multiple NTP sources may attempt
     a Sybil attack on the synthesis median.  The median is
     resistant to Sybil attacks when fewer than k/2 sources are
     compromised, for k >= 3.  Implementations using k=4 are
     resistant to any single-source compromise.

  9.4.  Side-Channel Considerations

     The HMAC verification (~6 microseconds) and Ed25519
     verification (~100 microseconds) MUST be implemented in
     constant time.  Variable-time implementations risk
     timing side-channel attacks against the HMAC key.

     The Nonce MUST be generated with a constant-time CSPRNG.

  9.5.  Byzantine Economic Attacks

     An attacker may attempt to manipulate ordering for economic
     gain (MEV).  The AdaptiveSwitch V* threshold (Section 6.4)
     ensures that for V < V*_min = $8.67, ordering spam is
     eliminated in the unique Nash equilibrium.

     Attackers with V >= V*_max = $87.13 may find manipulation
     economically rational at the margin.  PoT reduces expected
     spam for such cases by a factor of c_PoT / c_0 (Section 6.4).

  9.6.  Delay-Based Temporal Attacks

     [RFC8915] Section 8.6 identifies delay attacks as a primary
     threat to time synchronisation security, noting that an
     adversary who delays NTP packets can cause a client to
     accept a stale timestamp as current.

     TTTPS addresses this threat through two complementary gates,
     applied in sequence at verification time (Section 4.5):

     (1) HMAC context gate (Section 5.2, ~6 microseconds):
         A PoT generated at time T with context ctx_id cannot be
         presented in a different execution context ctx_id' without
         HMAC verification failing.  Context includes chain_id and
         pool_address.  An attacker cannot reuse a valid PoT from
         a previous context window.

         This is analogous to the cookie freshness mechanism of
         [RFC8915] Section 5.4, which binds cookies to TLS session
         keys that expire with the session.

     (2) AdaptiveSwitch recency gate (Section 6.3):
         A PoT submitted at time S where (S - T) > tier_tolerance
         is treated as a conformance failure.  FULL mode is triggered
         immediately.  The submission is rejected regardless of
         cryptographic validity.

         This reflects the operational observation, consistent with
         [RFC8915] Section 8.6, that in correctly functioning networks
         legitimate submissions arrive within tier tolerance bounds.
         Submissions outside this window correlate with Byzantine
         behaviour.

     FILO+GRG processing discipline:
         Among PoT records that pass both gates, the most recently
         generated qualifying submission is processed first.  This
         creates an adverse incentive structure for delay attackers:
         a delayed-but-valid PoT that bypasses the HMAC gate is
         rejected at the recency gate; a PoT that passes both gates
         competes at a recency disadvantage against honest peers.

     Together, these mechanisms render delay-based attacks
     economically irrational:
     o  A delayed PoT fails the recency gate -> FULL mode
     o  Repeated FULL mode triggers exponential backoff
     o  Backoff cost exceeds MEV opportunity for V < V*

     FILO+GRG flow:

         Message arrives
             |
             v
         [GATE 1: HMAC context binding ~6us]
             |-- FAIL (wrong ctx or expired) --> REJECT immediately
             |-- PASS
             v
         [GATE 2: AdaptiveSwitch recency check]
             |-- FAIL (submission > tier_tolerance) --> FULL mode
             |-- PASS
             v
         [Enter FILO processing queue]
             |
             v
         Most recently generated qualifying PoT processed first

  9.7.  GRG Pipeline Security

     Byzantine context binding provides:
        P(detect Byzantine manipulation) >= 1 - 2^{-61}

     This follows from: P(forge_i) = 2^{-64} per shard (PRF
     security of HMAC [Bellare1996]); union bound over 6 shards:
     P(forge all) <= 6 * 2^{-64} < 2^{-61} ~= 4.3e-19.

     This transforms SCCP from P(detect) < 1 (Shannon model)
     to P(detect) >= 1 - 2^{-61}.

     Implementations MUST NOT expose GRG internal state, shard
     values, or intermediate pipeline results through public APIs
     or error messages.

  10.8.  Path Manipulation Attack Scenarios

     This section specifies the TTTPS defense against path-layer
     attacks, including SS7/SCCP gateway compromise.

  10.8.1.  Scenario A: SCCP Gateway Compromise and Traffic Rerouting

     Attack: An adversary controlling an SS7/SCCP gateway silently
     reroutes traffic between two TTTPS nodes, introducing ordering
     delays or attempting to inject modified PoT records.

     Attack capability:
     o  Reroute packets to introduce N milliseconds of additional
        delay (N up to hundreds of ms for intercontinental paths).
     o  Attempt to substitute a previously captured PoT record
        from a different execution context.
     o  Modify path-layer headers without TLS visibility.

     TTTPS defense:

     (1) Context binding (Section 6.2): The HMAC key is derived as
         k = keccak256(chain_id || pool_address).  A PoT generated
         in context ctx_id_A will fail HMAC verification if
         presented in context ctx_id_B.  Path rerouting cannot
         change the ctx_id embedded in the PoT.

     (2) Recency gate (Section 7.3): A PoT submitted at time S
         where (S - T_generated) > tier_tolerance is rejected
         regardless of cryptographic validity.  Path-induced delays
         exceeding the tier tolerance are thus self-defeating.

     (3) TLS binding (Section 8.1): The binding_key = TLS-Exporter
         (EXPORTER-tttps-pot-binding, pot_without_sig, 32) is
         session-specific.  A PoT captured from session A cannot
         be replayed into session B even if the path-layer attacker
         can observe both sessions.

     Security bound: An adversary controlling only network paths
     (not the Issuer's Ed25519 private key) cannot produce a PoT
     that passes all three checks.  Path manipulation is necessary
     but not sufficient for a successful attack.

  10.8.2.  Scenario B: SS7 Location Tracking and Ordering Inference

     Attack: An adversary uses SS7 MAP UpdateLocation messages to
     track the geographic positions of TTTPS Issuers and verifiers,
     then exploits propagation delay asymmetry to gain ordering
     advantage.

     Attack capability:
     o  Determine physical location of network nodes with ~100m
        accuracy using SS7 MAP queries [SS7-VULN].
     o  Infer network propagation delays between known nodes.
     o  Exploit delay asymmetry to consistently submit PoT records
        before honest competitors.

     TTTPS defense:

     The GRG_Commitment is generated at time T_generated from
     multi-source Roughtime data.  The submission window is
     [T_generated, T_generated + tier_tolerance].  An adversary
     who knows propagation delays can position submissions within
     this window, but cannot:

     o  Extend the window (recency gate rejects late submissions).
     o  Generate a valid PoT with an earlier timestamp without
        the Issuer's private key (Ed25519 EUF-CMA: P(forge)
        < 2^{-128}).
     o  Reuse a previously generated PoT (nonce freshness check).

     Ordering inference from location tracking thus provides no
     actionable advantage within the TTTPS framework.

  10.8.3.  Scenario C: Man-in-the-Middle with Timestamp Forgery

     Attack: A MITM adversary intercepts a PoT in transit and
     attempts to modify the timestamp field before forwarding.

     Attack requirements for success: the adversary must produce
     a valid tuple (timestamp', grg_commitment', Ed25519_sig')
     such that:
     o  grg_commitment' = GRG(P' || D_chain', ctx_id) [GRG preimage]
     o  Ed25519_sig' = Ed25519.Sign(sk, P' || grg_commitment') [sig]
     o  timestamp' is accepted by the recency gate [timing]

     Security bounds:
     o  P(Ed25519 forgery) < 2^{-128} (EUF-CMA, 128-bit security)
     o  P(AEAD tag forgery) < 2^{-64} (ChaCha20-Poly1305, §9.9)
     o  P(combined success) < 2^{-191}

     Additionally, a timestamp' < T_generated would fail the
     Roughtime chain verification (Theorem 0, Section 1): the
     GRG_Commitment binds the Roughtime-derived D_chain, and a
     forged earlier timestamp would produce a different D_chain'.

  10.9.  Trust Model and Key Compromise Resilience

     IETF security reviewers require explicit specification of
     the trust model: who trusts whom, and what happens when
     trust is violated.

  10.9.1.  Trust Hierarchy

     TTTPS defines a two-level trust hierarchy:

     Level 0 (L0) Certificate Authority:
        An L0 CA issues certificates to PoT Issuers.  Verifiers
        trust L0 CA public keys, published in a transparency log
        (analogous to Certificate Transparency [RFC6962]).
        L0 CAs correspond to the "Financial", "Satellite",
        "Source", and "Network" CA roles defined in the companion
        deployment architecture.

     Level 1 (L1) PoT Issuer:
        An L1 Issuer holds an Ed25519 key pair certified by an
        L0 CA.  The Issuer generates PoT records (Section 5.3)
        and signs them with its private key.

     Verifier:
        Any party that receives a PoT and verifies it per
        Section 5.5.  Verifiers check: (1) L0 CA signature on
        Issuer certificate, (2) Ed25519 signature on PoT, (3)
        Roughtime chain digest, (4) recency, (5) nonce freshness.

     This model is analogous to TLS PKI: L0 CAs are root CAs,
     L1 Issuers are intermediate CAs, and verifiers are TLS clients.
     The Issuer-to-verifier relationship is one-to-many.

  10.9.2.  Issuer Key Compromise Response

     If an L1 Issuer's Ed25519 private key is compromised:

     (1) Key rotation: The L0 CA revokes the compromised
         certificate and issues a new one with a new key_id
         (future versions of the PoT wire format SHOULD include
         a key_id field for rotation support).

     (2) Transparency audit: All PoTs generated by the compromised
         key are logged in the transparency log with their
         Roughtime chain digests.  Third parties can verify which
         PoTs were generated with valid Roughtime data and which
         were generated after the compromise window.

     (3) Roughtime independence: The Roughtime chain (k >= 3
         independent servers, Section 5.3) provides an independent
         check on Issuer-reported timestamps.  Even after key
         compromise, the attacker cannot generate PoTs with
         timestamps outside the current Roughtime consensus window
         without also compromising k/2 Roughtime servers.

     Issuer compromise is thus bounded: the attacker can generate
     PoTs with valid-looking timestamps only within the
     Roughtime consensus window at the time of compromise.

  10.9.3.  Untrusted Substrate Guarantee

     TTTPS provides the following formal guarantee:

     "For any adversary A controlling at most k/2 - 1 Roughtime
     servers, at most one L0 CA, and any subset of network paths
     (including all SS7/SCCP gateways), A cannot:

     (a) generate a PoT with timestamp T' != T that passes
         verification with probability > 2^{-61}; or

     (b) replay a valid PoT into a different TLS session; or

     (c) cause the recency gate to accept a PoT submitted outside
         tier_tolerance; or

     (d) link PoT records from different sessions to the same
         originator."

     This guarantee holds under the assumption that Ed25519
     satisfies EUF-CMA with 128-bit security and HMAC-SHA256
     is a PRF.  Neither assumption requires trust in the
     underlying network layer.


  ============================================================
  SECTION 11.  PRIVACY CONSIDERATIONS
  ============================================================

  10.1.  Unlinkability

     PoT records include a 256-bit random Nonce (Section 4.1)
     that MUST be freshly generated for each record.  This
     prevents linkage of PoT records from the same issuer across
     sessions.

     The TLS Exporter binding (Section 7.1) ensures that PoT
     records are bound to specific TLS sessions and cannot be
     used to correlate activity across sessions.

     Issuers SHOULD NOT include in PoT records any information
     beyond the fields defined in Section 4.1 that could enable
     participant identification.

  10.2.  Minimal Disclosure

     The PoT wire format (Section 4.1) does not include:
     o  Participant identity or address
     o  Transaction content
     o  Economic parameters or bid values

     The ctx_id (chain_id || pool_address) is a public identifier
     already disclosed by the on-chain context.  Its inclusion
     in the HMAC key does not introduce new disclosures.


  ============================================================
  SECTION 11.  IANA CONSIDERATIONS
  ============================================================

  11.1.  TLS Exporter Labels Registry

     IANA is requested to add the following entry to the "TLS
     Exporter Labels" registry [RFC5705]:

        Label:            EXPORTER-tttps-pot-binding
        DTLS-OK:          Y
        Recommended:      Y
        Reference:        [this document] Section 7.1

  11.2.  TTTPS Tier Registry

     IANA is requested to create a new registry "TTTPS Tier
     Identifiers" with the following initial values:

        Value | Name       | Interval  | Reference
        ------|------------|-----------|------------------
        0x0   | T0_epoch   | 6.4 min   | [this document]
        0x1   | T1_block   | 2 sec     | [this document]
        0x2   | T2_slot    | 12 sec    | [this document]
        0x3   | T3_micro   | 100 ms    | [this document]
        0x4-F | Reserved   | --        | [this document]

     Registration procedure: Specification Required.

  11.3.  Time Source Type Registry

     IANA is requested to create a new registry "TTTPS Time
     Source Types" with the following initial values:

        Value | Name        | Reference
        ------|-------------|------------------
        0x01  | NIST        | [this document]
        0x02  | Google      | [this document]
        0x03  | Cloudflare  | [this document]
        0x04  | Apple       | [this document]
        0x05-FE | Unassigned | Specification Required
        0xFF  | Private Use | [this document]

  11.4.  HTTP/3 and QUIC Stream Types

     IANA is requested to add the following entries:

     HTTP/3 Frame Types registry:
        Type:       TBD (to be assigned by IANA; 0x4C4F5400 proposed)
        Name:       TTTPS_POT_FRAME
        Reference:  [this document] Section 7.3
        Note:       Implementations MUST use the IANA-assigned value.

     QUIC Stream Types registry:
        Type:       TBD (to be assigned by IANA)
        Name:       TTTPS_POT_STREAM
        Reference:  [this document] Section 7.2
        Note:       Implementations MUST use the IANA-assigned value.
                    Until assigned, use 0x74 for testing only.

  11.5.  PoT Extension Type

     TTTPS-00 referenced TLS Extension Type 0xFF50 (Private Use
     range).  TTTPS-01 does NOT use a TLS Extension Type.  The
     TLS Exporter mechanism (Section 7.1) requires no codepoint.

     If a future version requires a TLS Extension Type, the
     authors will request a codepoint via Specification Required
     procedure per [RFC8447].


  ============================================================
  SECTION 12.  INTELLECTUAL PROPERTY
  ============================================================

     The GRG Integrity Pipeline is covered by pending patent
     applications filed by the authors.  Full specification of
     the GRG pipeline, including stage implementations and
     parameter selection, will be made available upon conclusion
     of patent proceedings (targeted Q3 2026).

     In accordance with IETF policy [BCP79], the authors are
     prepared to license any patents essential to this specification
     on FRAND terms.

     Independent implementation is possible using:
     o  The abstract interface in Section 5.1
     o  The external properties in Section 5.3
     o  The reference implementation [OPENTTT]

     This follows the precedent of [RFC8915] Section 6, which
     specifies cookie format as implementation-dependent.


  ============================================================
  SECTION 13.  REFERENCES
  ============================================================

  13.1.  Normative References

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

     [RFC5705]   Rescorla, E., "Keying Material Exporters for
                 Transport Layer Security (TLS)", RFC 5705,
                 March 2010.

     [RFC7301]   Friedl, S. et al., "TLS Application-Layer
                 Protocol Negotiation Extension", RFC 7301,
                 July 2014.

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

     [RFC8446]   Rescorla, E., "The Transport Layer Security (TLS)
                 Protocol Version 1.3", RFC 8446, August 2018.

     [RFC8126]   Cotton, M. et al., "Guidelines for Writing an IANA
                 Considerations Section in RFCs", BCP 26, RFC 8126,
                 June 2017.

     [RFC8447]   Salowey, J. and S. Turner, "IANA Registry Updates
                 for TLS and DTLS", RFC 8447, August 2018.

     [RFC8915]   Franke, D. et al., "Network Time Security for
                 the Network Time Protocol", RFC 8915,
                 September 2020.

     [RFC9000]   Iyengar, J. and M. Thomson, "QUIC: A UDP-Based
                 Multiplexed and Secure Transport", RFC 9000,
                 May 2021.

     [RFC9114]   Bishop, M., "HTTP/3", RFC 9114, June 2022.

  13.2.  Informative References

     [Bellare1996] Bellare, M., Canetti, R., and H. Krawczyk,
                   "Keying Hash Functions for Message Authentication",
                   CRYPTO 1996, LNCS 1109, 1996.

     [Bernstein2012] Bernstein, D.J. et al., "High-speed
                     high-security signatures", J. Cryptogr. Eng.
                     2, 77-89, 2012.

     [Castro1999]  Castro, M. and B. Liskov, "Practical Byzantine
                   Fault Tolerance", OSDI, 173-186, 1999.

     [EIGENPHI]    EigenPhi Research, "MEV sandwich attacks:
                   annual loss estimates", 2025.

     [FLASHBOTS]   Flashbots, "MEV explore", 2025.
                   https://explore.flashbots.net

     [Golomb1966]  Golomb, S.W., "Run-length encodings",
                   IEEE Trans. Inf. Theory 12, 399-401, 1966.

     [Mazorra2026] Mazorra, B., Schmid, L. and D. Tse, "Timing
                   games: probabilistic backrunning and spam",
                   arXiv:2602.22032, 2026.

     [Messias2025] Messias, J. and C.F. Torres, "The express lane
                   to spam and centralization: an empirical analysis
                   of Arbitrum's Timeboost", arXiv:2509.22143, 2025.

     [OPENTTT]     Helm Protocol, "OpenTTT SDK",
                   https://github.com/Helm-Protocol/OpenTTT,
                   npm install openttt, 2026.

     [POT2026]     Jorgen, H., "Proof-of-Time: Byzantine-Resilient
                   Temporal Ordering in Untrusted Networks",
                   March 2026. IETF draft-helmprotocol-tttps-00.

     [Reed1960]    Reed, I.S. and G. Solomon, "Polynomial codes
                   over certain finite fields", SIAM J. Appl.
                   Math. 8, 300-304, 1960.

     [Tietavainen1973] Tietavainen, A., "On the nonexistence of
                   perfect codes over finite fields", SIAM J.
                   Appl. Math. 24, 88-96, 1973.

     [GLASSWING]   Anthropic, "Project Glasswing: Securing Critical
                   Software for the AI Era",
                   https://www.anthropic.com/project/glasswing,
                   April 2026.

     [MAZORRA2026note] Jorgen, H., "Proof-of-Time: Completing the
                   Timing Game", The Flashbots Collective,
                   https://collective.flashbots.net/t/
                   proof-of-time-completing-the-timing-game/5633,
                   March 2026.

     [Zhang2026]   Zhang, J. et al., "Hyperagents: self-referential
                   agents with metacognitive self-modification",
                   arXiv:2603.19461, 2026.

     [SS7-VULN]    Positive Technologies, "SS7 Vulnerabilities and
                   Attack Exposure Report", 2020.
                   https://www.ptsecurity.com/ww-en/analytics/
                   ss7-vulnerability-2020/

     [GSMA-SS7]    GSMA, "SS7 and SIGTRAN Network Security",
                   GSMA document FS.11, November 2015.
                   https://www.gsma.com/security/fs-11/

     [GPS-SPOOF]   Humphreys, T., "Statement on the Vulnerability
                   of Civil Unmanned Aerial Vehicles and Other
                   Systems to Civil GPS Spoofing", University of
                   Texas Radionavigation Laboratory, 2012.

     [RFC6962]     Laurie, B. et al., "Certificate Transparency",
                   RFC 6962, June 2013.

     [RFC9557]     Gruessing, M. et al., "Port for the Roughtime
                   Protocol", RFC 9557, April 2024.

     [RFC7942]     Sheffer, Y. and A. Farrel, "Improving Awareness
                   of Running Code: The Implementation Status
                   Section", RFC 7942, July 2016.

     [IEEE1588]    IEEE, "IEEE Standard for a Precision Clock
                   Synchronization Protocol for Networked
                   Measurement and Control Systems", IEEE Std
                   1588-2019.


  ============================================================
  SECTION 15.  IMPLEMENTATION STATUS
  ============================================================

     This section records the status of known implementations of
     TTTPS at the time of posting, per [RFC7942].

  15.1.  Reference Implementation

     Name: OpenTTT
     URL:  https://github.com/Helm-Protocol/OpenTTT
     Level: Partial (verifier SDK, QUIC transport, Roughtime chain)

     Coverage:
     o  PoT wire format (Section 5.1): implemented, 12/12 tests
     o  GRG pipeline external interface (Section 6.1): implemented
        via HTTP API to private Issuer; 4/4 integration tests
     o  AdaptiveSwitch (Section 7.1): TLA+-verified, 9/9 tests
     o  QUIC transport / TLS binding (Section 8): implemented with
        quinn 0.11, ALPN tttps/1, measured RTT ~494 us on loopback
     o  Roughtime chain (Section 5.3): 8/8 tests, real UDP queries
     o  no_std verifier (Section 6.1): IoT/ARM compatible, 10/10

     Total: 99 tests passing, 0 failing (April 2026).

     Private Issuer implementation:
     Name: Helm grg-core
     Level: Complete (Issuer with GRG pipeline, Ed25519 signing)
     Tests: 72 tests passing, 0 failing
     Note: GRG pipeline implementation not published pending patent
           proceedings (Section 13).  Abstract interface (Section 6.1)
           is sufficient for independent implementation.

  15.2.  Deployment Evidence

     A PoT Issuer compliant with draft-helmprotocol-tttps has been
     operated experimentally.  The following data were collected:

     Total PoT records generated:     70,612
     Collection period:               October 2025 -- April 2026
     AI agent-originated records:     55% (38,837 records)
     Human-originated records:        45% (31,775 records)
     Mean generation latency:         47 ms (TURBO mode)
     Mean generation latency:         127 ms (FULL mode)
     TURBO / FULL split:              62% / 38%
     Zero cryptographic failures in 70,612 records.

     The 55% AI agent fraction was unanticipated and constitutes
     empirical evidence that the ordering problem is already
     operational in agent economies, not merely theoretical.

  15.3.  Interested Parties

     The following organisations have expressed interest in the
     deployment scenarios described in Section 2.  Their inclusion
     here does not constitute endorsement of any specific version
     of this draft.

     [To be populated from support letters received prior to
      BoF request submission.  Organisations in discussions
      include satellite network operators (Section 2.1) and
      financial infrastructure providers (Section 2.3).]

     Authors request that organisations wishing to be listed
     contact the authors directly.  A non-binding expression
     of interest in the stated use cases is sufficient for
     inclusion.


  ============================================================
  APPENDIX A.  ADAPTIVESWITCH TLA+ SPECIFICATION
  ============================================================

     The following TLA+ module formally specifies the AdaptiveSwitch
     state machine.  The module is verified by the TLC model checker
     with parameters MaxNodes=3, MaxBlocks=10, TierToleranceMs=100,
     TurboEntry=95, TurboMaintain=85.

     The module specifies:
     o  TypeInvariant: all five state variables are well-typed.
     o  S1 (NoForcedTurbo): TURBO requires match_rate >= 85 AND
        fail_count = 0 -- conjunction, not disjunction.
     o  S2 (DelayRejectionTriggersFull): submission outside tier
        tolerance is incompatible with TURBO.
     o  S3 (FailureExcludesTurbo): any integrity failure forces FULL.
     o  L1 (EventualTurbo): a node with sustained good behaviour
        eventually reaches TURBO (liveness under weak fairness).

     EnvStep models the environment updating match_rate, fail_count,
     and submission_delay nondeterministically, ensuring the
     invariants hold under all adversarial input sequences.

     The module structure follows the AgentLifecycle pattern of
     Helm Autonomy Layer Yellow Paper v2.0 [HelmYP2026].

  ---- MODULE AdaptiveSwitch ----
  EXTENDS Naturals, FiniteSets

  CONSTANTS MaxNodes, MaxBlocks, TurboEntry, TurboMaintain,
            TierToleranceMs

  ASSUME /\ TurboEntry    = 95   \* 95%  match_rate required for TURBO
         /\ TurboMaintain = 85   \* 85%  minimum to stay in TURBO
         /\ TierToleranceMs > 0  \* positive tier tolerance (ms)

  NodeId == 1..MaxNodes   \* finite set of node identifiers
  Modes  == { "TURBO", "FULL" }

  VARIABLES
    node_mode,        \* [NodeId -> Modes]  per-node state
    match_rate,       \* [NodeId -> 0..100] ordering-match percentage
    fail_count,       \* [NodeId -> Nat]    consecutive integrity failures
    block_count,      \* Nat                current block number
    submission_delay  \* [NodeId -> Nat]    ms since last PoT generation

  vars == <<node_mode, match_rate, fail_count,
            block_count, submission_delay>>

  \* ── Helpers ──────────────────────────────────────────────────────
  SubmittedOutsideTolerance(n) ==
    submission_delay[n] > TierToleranceMs

  \* ── Type correctness ─────────────────────────────────────────────
  TypeInvariant ==
    /\ node_mode        \in [NodeId -> Modes]
    /\ match_rate       \in [NodeId -> 0..100]
    /\ fail_count       \in [NodeId -> Nat]
    /\ block_count      \in Nat
    /\ submission_delay \in [NodeId -> Nat]

  \* ── Initial state (all nodes start in FULL, zero counters) ───────
  Init ==
    /\ node_mode        = [n \in NodeId |-> "FULL"]
    /\ match_rate       = [n \in NodeId |-> 0]
    /\ fail_count       = [n \in NodeId |-> 0]
    /\ block_count      = 0
    /\ submission_delay = [n \in NodeId |-> 0]

  \* ── Actions ──────────────────────────────────────────────────────

  \* Promote n from FULL to TURBO when match_rate sufficient
  \* and no pending failures.
  PromoteToTurbo(n) ==
    /\ node_mode[n]   = "FULL"
    /\ match_rate[n]  >= TurboEntry
    /\ fail_count[n]  = 0
    /\ ~SubmittedOutsideTolerance(n)
    /\ node_mode' = [node_mode EXCEPT ![n] = "TURBO"]
    /\ UNCHANGED <<match_rate, fail_count,
                    block_count, submission_delay>>

  \* Demote n from TURBO to FULL on poor match_rate, integrity
  \* failure, or submission outside tier tolerance.
  DemoteToFull(n) ==
    /\ node_mode[n] = "TURBO"
    /\ \/ match_rate[n] < TurboMaintain
       \/ fail_count[n] > 0
       \/ SubmittedOutsideTolerance(n)
    /\ node_mode' = [node_mode EXCEPT ![n] = "FULL"]
    /\ UNCHANGED <<match_rate, fail_count,
                    block_count, submission_delay>>

  \* Environment step: update match_rate / fail_count / delay
  \* (models external inputs; unconstrained for model checking)
  EnvStep(n, mr, fc, sd) ==
    /\ match_rate'       = [match_rate       EXCEPT ![n] = mr]
    /\ fail_count'       = [fail_count       EXCEPT ![n] = fc]
    /\ submission_delay' = [submission_delay EXCEPT ![n] = sd]
    /\ block_count'      = block_count + 1
    /\ UNCHANGED node_mode

  Next ==
    \E n \in NodeId :
      \/ PromoteToTurbo(n)
      \/ DemoteToFull(n)
      \/ \E mr \in 0..100, fc \in 0..5, sd \in 0..(TierToleranceMs+50) :
           EnvStep(n, mr, fc, sd)

  Spec == Init /\ [][Next]_vars /\ WF_vars(Next)

  \* ── Safety invariants ────────────────────────────────────────────

  \* S1: TURBO requires healthy match_rate AND no integrity failures.
  NoForcedTurbo ==
    \A n \in NodeId :
      node_mode[n] = "TURBO" =>
        /\ match_rate[n] >= TurboMaintain
        /\ fail_count[n] = 0

  \* S2: Delay outside tier tolerance must not coexist with TURBO.
  DelayRejectionTriggersFull ==
    \A n \in NodeId :
      SubmittedOutsideTolerance(n) => node_mode[n] = "FULL"

  \* S3: fail_count > 0 must not coexist with TURBO.
  FailureExcludesTurbo ==
    \A n \in NodeId :
      fail_count[n] > 0 => node_mode[n] = "FULL"

  \* ── Liveness ─────────────────────────────────────────────────────

  \* L1: A node with sustained good behaviour eventually reaches TURBO.
  EventualTurbo ==
    \A n \in NodeId :
      (match_rate[n] >= TurboEntry /\ fail_count[n] = 0
        /\ ~SubmittedOutsideTolerance(n))
      ~> node_mode[n] = "TURBO"

  \* ── TLC model values (for model checking) ───────────────────────
  \* MaxNodes = 3, MaxBlocks = 10, TierToleranceMs = 100
  \* TurboEntry = 95, TurboMaintain = 85
  ====

     The invariant NoForcedTurbo corresponds to Safety Property S4
     of Helm Yellow Paper v2.0 (AS score external immutability).


  ============================================================
  APPENDIX B.  GRG PIPELINE SPECIFICATION (PLACEHOLDER)
  ============================================================

     The GRG Integrity Pipeline (Section 5) processes PoT payloads
     through four stages: Golomb-Rice (G_1), Reed-Solomon (R),
     Golay(23,12,7) (G_2), and HMAC-SHA256 (H).

     The stage ordering G_1 -> R -> G_2 -> H is mathematically
     necessary, as proven in [POT2026] Theorems 1-3.

     Full specification of internal cryptographic operations,
     parameter selection, and implementation details will be
     published upon conclusion of pending patent proceedings
     (targeted Q3 2026).

     Reference implementation: https://github.com/Helm-Protocol/OpenTTT
     npm: npm install openttt

     Independent implementations of the abstract interface
     (Section 5.1) and external properties (Section 5.3) are
     permitted under BSL-1.1 license terms.


  ============================================================
  APPENDIX C.  TEST VECTORS
  ============================================================

     Test vectors for PoT generation and verification are provided
     as property-based tests rather than deterministic byte vectors.
     This approach prevents reverse-engineering of GRG pipeline
     parameters from expected byte sequences.

     Required properties (all MUST pass):

     C.1  Lossless round-trip:
          GRG_Inverse(GRG(P, ctx)) = P for all P, ctx

     C.2  Nonce uniqueness:
          Two calls to Generate() MUST NOT produce equal Nonces.

     C.3  Context separation:
          GRG(P, ctx_A) != GRG(P, ctx_B) for ctx_A != ctx_B
          (negligible probability of collision: < 2^{-61})

     C.4  Verification correctness:
          Verify(Generate(P, ctx), ctx) = TRUE

     C.5  Forgery resistance:
          Verify(tampered_record, ctx) = FALSE for any
          single-bit modification to P or GRG_Commitment.

     C.6  Delay rejection:
          A PoT submitted at T + tier_tolerance + 1ms MUST
          trigger FULL mode.

     C.7  HMAC gate priority:
          HMAC verification MUST complete before Ed25519 is
          attempted.  Invalid HMAC MUST NOT result in Ed25519
          invocation (measurable via timing).

     Reference test suite: 365 tests, 31 suites, 100% pass rate
     [OPENTTT]. The test suite uses property-based testing only
     (no deterministic byte vectors).


  ============================================================
  APPENDIX D.  FILO+GRG DELAY REJECTION FLOW
  ============================================================

     This appendix provides a normative ASCII diagram of the
     FILO+GRG delay rejection mechanism described in Section 9.6.

     TIME AXIS:
     |----T------|---(T+epsilon)---|---------(T+Delta)-------->
         PoT gen    tier tolerance     delayed submission
         time        window end        zone

     VALID SUBMISSION WINDOW: [T, T + tier_tolerance]
     DELAYED ZONE: (T + tier_tolerance, infinity)

     GATE 1: HMAC context binding (~6 microseconds)
     --------------------------------------------------
     Input: PoT record + submission context

     If HMAC(k, shard_i) does not match for any i:
       -> REJECT immediately
       -> DO NOT invoke Ed25519
       Covers: wrong context, tampered payload

     GATE 2: AdaptiveSwitch recency check
     --------------------------------------------------
     Input: PoT record + current submission time S

     If (S - PoT.Timestamp) > tier_tolerance:
       -> REJECT
       -> Trigger FULL mode
       -> Apply exponential backoff
       Covers: valid PoT submitted outside tolerance window

     FILO QUEUE (Gate 1 AND Gate 2 passed)
     --------------------------------------------------
     Queue discipline: most recently generated PoT first.

     If multiple PoTs qualify:
       Select max(PoT.Timestamp) for processing.
       Earlier PoTs remain in queue.

     Effect on delay attackers:
     o  Cannot pass Gate 2 (recency check rejects)
     o  Even if somehow past Gate 2, lose priority to fresher PoTs
     o  Repeated failures -> exponential backoff -> self-defeating

     COMPLEXITY NOTE:
     Gate 1 (HMAC): O(1) per record, ~6 microseconds
     Gate 2 (recency): O(1) per record, ~0.1 microseconds
     Queue ordering: O(log q) for q queued records (priority queue)
     Total per-record: O(1) -- independent of network size n

     Compare with BFT consensus protocols:
       PBFT/Tendermint/HotStuff: O(n^2) network-wide message
       exchanges to reach Byzantine TOLERANCE (tolerate f < n/3
       Byzantine nodes) for n total nodes.

     TTTPS achieves Byzantine ELIMINATION at O(1) per record.
     Honest user verification cost: ~106 microseconds (constant).
     Attacker economic cost: increases as V* threshold makes
     manipulation irrational (E[profit] < 0 for V < $8.67).
     Attacker backoff cost: O(2^f) blocks for f failures.
     Network scaling: 100 nodes -> 1,000,000 nodes: BFT cost
     grows 10^8x; TTTPS per-record cost unchanged.

  ============================================================
  END OF DRAFT
  ============================================================
  Acknowledgements

  The authors thank the IETF dispatch list reviewers (Worley, Jim,
  Tim) for feedback on draft-helmprotocol-tttps-00.  The GRG
  pipeline selection rationale builds on deep-space engineering
  heritage: JPL Golomb-Rice compression, RS codes from Cassini
  and the Mars rovers, and Golay(23,12,7) from the Voyager
  Saturn transmissions (1.0e9 km, 1980).

  Author's Address

  Heime Jorgen
  Kenosian
  Email: heime.jorgen@proton.me
  IETF Draft: draft-helmprotocol-tttps-03


