Internet Engineering Task Force (IETF)                     Y. Wang
Internet-Draft                                    HJS Foundation
Intended status: Standards Track                          April 2026
Expires: October 20, 2026

                Cognition-Oriented Emergence (COE):
       A Cognitive Interaction Protocol for Shared World Models
                         draft-wang-coe-00

Abstract

   This document defines the Cognition-Oriented Emergence (COE)
   protocol, a lightweight, minimalist, narrow-waist cognitive
   interaction protocol.  COE provides a unified "cognitive interaction
   layer" for the fragmented ecosystem of world models.  Through four
   core primitives -- Judge (J), Delegate (D), Terminate (T), and
   Verify (V) -- COE enables heterogeneous world models and AI agents
   to reach verifiable consensus on shared world states within a
   traceable, auditable, and evolvable framework.

   Unlike JEP, which focuses on "accountability tracing" (post-hoc
   audit), COE focuses on "cognitive consensus" (ex-ante / in-situ
   collaboration).  COE does not depend on any specific world model
   implementation; instead, it serves as a common "trust operating
   system" and "collaboration grammar" for them.  JEP answers "who is
   responsible," and COE answers "what the world is" -- both share the
   J/D/T/V primitive gene, forming a complete "cognition‑accountability"
   dual-loop architecture.

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 October 20, 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.  Problem Statement
     1.2.  Relationship with JEP
     1.3.  Design Philosophy
     1.4.  Terminology
     1.5.  Requirements Language
   2.  Protocol Model
     2.1.  Core Cognitive Primitives
     2.2.  Narrow Waist Architecture
   3.  COE Event Format
     3.1.  General Event Structure
     3.2.  Field Description
     3.3.  Semantic Namespace and Context Isolation
     3.4.  Event Examples
   4.  Consensus Emergence Engine
     4.1.  Consensus Engine Overview
     4.2.  Consensus Policies
       4.2.1.  Simple Majority Policy
       4.2.2.  Weighted Trust Policy
       4.2.3.  Byzantine Fault Tolerance Policy
     4.3.  Consensus State Output
   5.  Versioned Audit Chain
     5.1.  Audit Chain Structure
     5.2.  Version Anchoring
     5.3.  Timestamp Anchoring
   6.  Security Considerations
     6.1.  Threat Model
     6.2.  Integrity Protection
     6.3.  Sybil Attack Defense
     6.4.  Replay Attack Defense
     6.5.  Consensus Blocking Attack
     6.6.  Privacy Protection
   7.  IANA Considerations
     7.1.  COE Primitive Registry
     7.2.  COE Consensus Policy Registry
   8.  Implementation Guide and Reference Implementation
     8.1.  Minimal Viable Implementation (COE-Lite)
     8.2.  Verification Scenario
     8.3.  Integration with Existing Standards
   9.  References
     9.1.  Normative References
     9.2.  Informative References
   Appendix A.  Complete Verification Workflow Example
   Author's Address

1.  Introduction

1.1.  Problem Statement

   The world model field is flourishing with diverse technical
   approaches (e.g., JEPA, Dreamer, World Labs, Cosmos).  However,
   these models are isolated from each other in architecture, data
   format, and interaction style, creating a severe fragmentation
   problem.  When multiple agents (including humans and AIs) need to
   collaboratively perceive and understand the same physical space,
   three core problems become unavoidable:

   - Conflict Resolution: Observations from different world models may
     contradict each other; no uniform mechanism exists to reconcile
     them.
   - Consensus Formation: No trusted way exists to agree on "what the
     world state is at this moment" across multiple observers.
   - Traceable Verification: The process by which consensus is reached
     cannot be traced or audited, eroding the trust foundation.

   COE is designed as a standardized cognitive interaction layer to
   address these three problems.

1.2.  Relationship with JEP

   COE and JEP share the same J/D/T/V primitives but serve different
   protocol layers:

   - JEP (Judgment Event Protocol): Focuses on accountability tracing
     (post-hoc audit), answering "who decided what, under whose
     authority, and who verified it" -- i.e., "who is responsible."
     JEP follows the philosophy of "minimal intrusion, maximum
     compatibility."

   - COE (Cognition-Oriented Emergence): Focuses on cognitive
     consensus (ex-ante / in-situ collaboration), answering "how do we
     collectively know what the world is" -- i.e., "what is the state."

   Together they form a complete "cognition‑accountability" dual-loop
   system: COE establishes a shared understanding of the world; JEP
   traces accountability for decisions made upon that consensus.  COE
   events may be referenced by JEP as evidence.

1.3.  Design Philosophy

   COE follows the "minimal intrusion, maximum compatibility"
   philosophy and adopts a classic "narrow waist" architecture:
   - Minimal core: Only J/D/T/V semantics plus lightweight consensus
     mechanisms.
   - Decoupled layers: Heterogeneous world models produce COE events
     via adapters; upper-layer applications rely only on the stable
     cognitive interaction grammar.
   - Verifiability: All events carry digital signatures and hash
     linking; the consensus process is fully auditable.

1.4.  Terminology

   This document uses the following terms:

   - Cognitive Unit (CU): Any entity capable of initiating, receiving,
     or processing COE events (e.g., human user, AI agent, software
     service).  Each CU has a unique identifier (e.g., DID).
   - World Model (WM): A model or framework that understands and
     predicts physical world states.  COE does not prescribe its
     internal implementation.
   - Shared World State (SWS): An agreed-upon description of a physical
     or logical world state reached by multiple CUs via the COE
     consensus mechanism at a specific point in time.
   - COE Event: A digitally signed JSON object initiated by a CU,
     describing exactly one atomic operation (J/D/T/V) related to a
     world state.
   - COE Adapter: Lightweight software that translates a world model's
     internal outputs into standard COE event format.
   - Consensus Engine: Core component of a COE implementation that
     collects J/V events, resolves conflicts according to a policy,
     and produces the current Shared World State.
   - Audit Chain: A tamper-evident chain of COE events linked by
     cryptographic hashes in chronological order.

1.5.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

2.  Protocol Model

2.1.  Core Cognitive Primitives

   COE inherits the four-primitive model from JEP and HJS, extending it
   into the "world observation" context:

   - J (Judge): Initiates an observation assertion about a world state.
     A CU declares "I observe X at this time."  J events are the
     starting point of cognitive interaction and the base input for
     subsequent consensus.
   - D (Delegate): Delegates observation or confirmation authority to
     another CU.  This transfers cognitive load, stating "I request /
     authorize you to observe or confirm X."  D events can dynamically
     adjust the set of consensus participants.
   - T (Terminate): Declares that a previously initiated observation
     assertion (and its associated state) is no longer valid or should
     be terminated.  This closes the lifecycle of a state.
   - V (Verify): Cross-validates or confirms one or more observation
     assertions from other CUs.  This is the critical action for
     consensus emergence, stating "I confirm / verify that
     observation."  V events provide credibility weighting for the
     consensus engine.

   These four primitives form a complete cognitive interaction algebra:
   any complex multi-agent collaboration scenario can be decomposed
   into an ordered combination of these four atomic operations.  No
   fifth primitive is required.

2.2.  Narrow Waist Architecture

   COE adopts a classic "narrow waist" architecture:

   ┌─────────────────────────────────────────────────────────────┐
   │  Upper Layer: Diverse Multi-Agent Collaboration Scenarios    │
   │  (robot collaboration, AR/VR co-presence, distributed sci-   │
   │   entific consensus, cognitive economy transactions, etc.)   │
   └─────────────────────────────────────────────────────────────┘
                                │
                                │ COE Events (J/D/T/V)
                                ▼
   ┌─────────────────────────────────────────────────────────────┐
   │            COE Core (Narrow Waist) — Standardized Only Here │
   │  ┌─────────────┐  ┌─────────────┐  ┌─────────────────────┐  │
   │  │ J/D/T/V     │  │ Lightweight │  │ Versioned Audit     │  │
   │  │ Primitives  │  │ Consensus   │  │ Chain (Git-like     │  │
   │  │ (cognition  │  │ Engine      │  │ version control)    │  │
   │  │ grammar)    │  │ (conflict   │  │                     │  │
   │  │             │  │ resolution) │  │                     │  │
   │  └─────────────┘  └─────────────┘  └─────────────────────┘  │
   └─────────────────────────────────────────────────────────────┘
                                │
                                │ COE Adapters
                                ▼
   ┌─────────────────────────────────────────────────────────────┐
   │  Lower Layer: Heterogeneous World Model Implementations      │
   │  (JEPA, Dreamer, World Labs, Cosmos, game engines, physics   │
   │   simulators, etc.)                                          │
   └─────────────────────────────────────────────────────────────┘

   Key advantages of the narrow waist:
   - Independent evolution: Lower-layer world models can evolve from
     JEPA to quantum physics engines without changing the COE core;
     upper-layer applications can evolve from simple collaboration to
     global cognitive economy networks while the core protocol remains
     stable.
   - Interoperability: Any world model capable of emitting J/D/T/V
     events can join the COE network.
   - Minimized trust base: The COE core is sufficiently small
     (reference implementation ~2000-3000 lines of code), making it
     easy to audit and formally verify.

3.  COE Event Format

3.1.  General Event Structure

   A COE event is a JSON object.  All implementations MUST support the
   following fields:

   {
     // Required Fields
     "event_id": "<UUID>",
     "protocol": "COE",
     "primitive": "J" | "D" | "T" | "V",
     "issuer": "<CU_ID>",
     "timestamp": "<RFC3339>",

     // World Model Context Fields
     "target": "<WM_ID>",

     // J Primitive Fields (REQUIRED when primitive="J")
     "assertion": {
       "subject": "<OBJECT_ID>",
       "predicate": "<PROPERTY>",
       "value": "<VALUE>",
       "confidence": <0.0-1.0>   // OPTIONAL
     },

     // D Primitive Fields (REQUIRED when primitive="D")
     "delegate_to": "<CU_ID>",
     "delegation_scope": "<SCOPE>",   // OPTIONAL

     // T Primitive Fields (REQUIRED when primitive="T")
     "terminate_of": "<event_id>",
     "terminate_reason": "<REASON>",

     // V Primitive Fields (REQUIRED when primitive="V")
     "verify_of": ["<event_id>", ...],
     "verification_result": "confirmed" | "rejected" | "partial",

     // Audit Chain Fields
     "prev_event_id": "<event_id>",
     "hash": "<SHA256>",
     "signature": "<SIGNATURE>"
   }

3.2.  Field Description

   - event_id: Globally unique event identifier; MUST be a UUID v4
     [RFC4122].
   - protocol: Protocol identifier; MUST be "COE".  This distinguishes
     COE events from JEP or other protocols sharing the primitives.
   - issuer: Identifier of the CU that initiated the event; SHOULD be
     a W3C Decentralized Identifier (DID) [DID-CORE] or other URI.
   - timestamp: Event creation time; MUST conform to RFC 3339.
   - target: Identifier of the target world model or scene; used to
     associate all events pertaining to the same physical space.
   - assertion: Observation assertion object; REQUIRED when
     primitive="J".
     - subject: Identifier of the observed object.
     - predicate: Name of the observed property.
     - value: Value of the property; can be string, number, boolean,
       or JSON object.
     - confidence: OPTIONAL; CU's confidence in the observation,
       0.0 to 1.0.
   - delegate_to: Identifier of the delegatee CU; REQUIRED when
     primitive="D".
   - delegation_scope: OPTIONAL; describes the scope of delegation
     (e.g., "continuous_observation", "one_time_confirmation").
   - terminate_of: event_id of the J event being terminated; REQUIRED
     when primitive="T".
   - terminate_reason: Reason for termination (e.g.,
     "observation_expired", "state_changed").
   - verify_of: Array of event IDs being verified; REQUIRED when
     primitive="V".
   - verification_result: MUST be "confirmed", "rejected", or
     "partial".
   - prev_event_id: event_id of the previous COE event in the chain;
     may be null for the genesis event.
   - hash: SHA-256 hash of the canonical JSON serialization [RFC8785]
     of the event excluding the signature field.
   - signature: Digital signature over the hash field using the
     issuer's private key; MUST be Ed25519 [RFC8032] or ECDSA with
     SHA-256.

3.3.  Semantic Namespace and Context Isolation

   COE and JEP share the J/D/T/V primitives but with different
   semantics.  To avoid conflicts, all COE events MUST include the
   protocol field with value "COE".  Implementations MUST select the
   appropriate semantic parser based on the protocol field:
   - If protocol="COE", interpret according to the "world observation"
     semantics defined herein.
   - If protocol="JEP", interpret according to the "accountability
     tracing" semantics defined in the JEP specification.

   A single CU MAY process both COE and JEP events, provided they are
   validated within their respective semantic contexts.

3.4.  Event Examples

   Example 1: Robot A observes that a door is open (J event)
   {
     "event_id": "550e8400-e29b-41d4-a716-446655440000",
     "protocol": "COE",
     "primitive": "J",
     "issuer": "did:example:robotA",
     "timestamp": "2026-04-19T10:30:00Z",
     "target": "warehouse-zone-3",
     "assertion": {
       "subject": "door_01",
       "predicate": "status",
       "value": "open",
       "confidence": 0.95
     },
     "prev_event_id": null,
     "hash": "sha256:...",
     "signature": "..."
   }

   Example 2: Robot B confirms Robot A's observation (V event)
   {
     "event_id": "660e8400-e29b-41d4-a716-446655440001",
     "protocol": "COE",
     "primitive": "V",
     "issuer": "did:example:robotB",
     "timestamp": "2026-04-19T10:30:05Z",
     "target": "warehouse-zone-3",
     "verify_of": ["550e8400-e29b-41d4-a716-446655440000"],
     "verification_result": "confirmed",
     "prev_event_id": "550e8400-e29b-41d4-a716-446655440000",
     "hash": "sha256:...",
     "signature": "..."
   }

4.  Consensus Emergence Engine

4.1.  Consensus Engine Overview

   The consensus engine is the core component of a COE implementation,
   responsible for:
   1. Collection: Listening for and collecting J and V events targeting
      the same world model (target).
   2. Conflict Resolution: When different CUs issue conflicting
      assertions about the same subject, resolving the conflict
      according to the configured consensus policy.
   3. Emergence: Producing the current Shared World State (SWS) and
      recording its generation process.

4.2.  Consensus Policies

   A COE consensus engine MUST support at least one of the following
   policies and SHOULD allow pluggable configuration.

4.2.1.  Simple Majority Policy

   Suitable for scenarios with a small number of CUs and equal trust.
   - Rule: Collect V events for a given assertion; the assertion is
     confirmed when the number of "confirmed" V events exceeds 50% of
     all V events received for that assertion.
   - Convergence condition: Evaluation begins after receiving at least
     3 V events; a configurable timeout applies.

4.2.2.  Weighted Trust Policy

   Suitable for scenarios with heterogeneous CU capabilities and
   reliability.
   - Rule: Each CU is assigned a trust weight w in [0, 1].  For an
     assertion, calculate confirmed_weight = Σ(w_i * confidence_i) for
     all confirming V events.  The assertion is confirmed when
     confirmed_weight > threshold.
   - Weight management: Weight assignments MUST be managed in an
     auditable manner (e.g., recorded via JEP events) to prevent
     centralized manipulation.

4.2.3.  Byzantine Fault Tolerance Policy

   Suitable for high-security scenarios where malicious CUs may exist.
   - Rule: A lightweight BFT variant requiring at least 2f+1 V events
     (where f is the number of tolerable Byzantine nodes), with more
     than f+1 being "confirmed".
   - Applicability: Recommended when the total number of CUs is at
     least 4.

4.3.  Consensus State Output

   Whenever the consensus engine confirms or updates an assertion, it
   MUST produce a Shared World State (SWS) record:

   {
     "sws_id": "<UUID>",
     "target": "<WM_ID>",
     "timestamp": "<RFC3339>",
     "assertions": [
       {
         "subject": "<OBJECT_ID>",
         "predicate": "<PROPERTY>",
         "value": "<VALUE>",
         "confidence": <0.0-1.0>,
         "based_on": ["<event_id>", ...],
         "consensus_policy": "<POLICY_NAME>",
         "confirmations": <COUNT>
       }
     ],
     "previous_sws_id": "<sws_id>",
     "hash": "<SHA256>"
   }

   The consensus state output SHOULD be anchored to the audit chain
   (see Section 5).

5.  Versioned Audit Chain

5.1.  Audit Chain Structure

   All COE events MUST be cryptographically linked via the
   prev_event_id field, forming a tamper-evident event chain.
   Integrity verification algorithm:

   def verify_chain(events):
       for i in range(1, len(events)):
           assert events[i].prev_event_id == events[i-1].event_id
           computed_hash = sha256(canonical_json(events[i] without signature))
           assert computed_hash == events[i].hash
           assert verify_signature(events[i].signature, events[i].hash, events[i].issuer)

5.2.  Version Anchoring

   Whenever the consensus engine produces a new SWS (Section 4.3), the
   SWS and all COE events upon which it depends MUST be packaged as a
   "version" and anchored to the audit chain.

   Version record format:

   {
     "version_id": "<UUID>",
     "sws": { ... },                         // SWS from Section 4.3
     "dependent_events": ["<event_id>", ...],
     "anchor_event_id": "<event_id>",        // Position in the audit chain
     "timestamp": "<RFC3339>",
     "previous_version_id": "<version_id>",
     "hash": "<SHA256>"
   }

5.3.  Timestamp Anchoring

   For high-security scenarios, COE implementations SHOULD support
   submitting version hashes to a public trusted timestamp service
   (e.g., RFC 3161) or a blockchain (e.g., via OpenTimestamps).
   Timestamp anchoring provides an independent time proof, further
   strengthening non-repudiation.

6.  Security Considerations

6.1.  Threat Model

   COE assumes the following threat model:
   - An attacker may control a subset of CUs and attempt to inject
     false observation assertions.
   - An attacker may attempt to tamper with published event records.
   - An attacker may attempt denial-of-service by flooding events.
   - An attacker may attempt to collude to manipulate consensus
     outcomes.

   COE does not assume full trust among CUs, nor does it assume
   infallibility of underlying world models.

6.2.  Integrity Protection

   Each COE event contains a hash of its content and the issuer's
   digital signature.  Any tampering with event content will invalidate
   the hash and thus the signature.  The audit chain's hash linking
   ensures event order cannot be altered.  Implementations MUST verify
   signatures and hashes upon event receipt.

6.3.  Sybil Attack Defense

   A Sybil attacker may create many fake CU identities to manipulate
   consensus.  Defenses:
   - Implementations SHOULD require CUs to undergo trusted
     registration (e.g., endorsement mechanisms in DID methods).
   - Under weighted trust policy, newly registered CUs SHOULD start
     with low weight, increasing only with demonstrated trustworthy
     behavior.
   - Byzantine fault tolerance policy inherently resists Sybil attacks
     (provided the attacker controls no more than f nodes).

6.4.  Replay Attack Defense

   An attacker may capture valid COE events and replay them later.
   Defenses:
   - Each event contains a unique event_id and timestamp.
     Implementations MUST maintain a cache of processed event IDs and
     reject duplicates.
   - Implementations SHOULD reject events with timestamps deviating
     excessively (e.g., more than 5 minutes).

6.5.  Consensus Blocking Attack

   Malicious CUs may deliberately withhold V events or emit
   contradictory V events to block consensus.  Defenses:
   - Consensus engine MUST implement a timeout mechanism, ignoring
     unresponsive CUs after timeout.
   - For contradictory V events, the consensus engine resolves
     according to policy (e.g., majority or weight) and does not stall
     due to individual malicious CUs.

6.6.  Privacy Protection

   The assertion field may contain sensitive information (e.g.,
   precise location data).  Implementations MAY support selective
   encryption of the assertion field, making it readable only to
   designated verifiers holding the decryption key.  Hybrid encryption
   schemes (e.g., ECDH + AES-GCM) are recommended.

   Furthermore, COE's three-layer privacy architecture (consistent
   with JEP) allows implementations to place sensitive payloads in a
   private payload layer, exposing only necessary public governance
   information to the audit chain.

7.  IANA Considerations

   This document may require IANA to establish the following
   registries:

7.1.  COE Primitive Registry

   - Registry Name: COE Primitives
   - Registration Policy: Specification Required [RFC8126]
   - Initial Contents: J (Judge), D (Delegate), T (Terminate),
     V (Verify)

7.2.  COE Consensus Policy Registry

   - Registry Name: COE Consensus Policies
   - Registration Policy: Expert Review [RFC8126]
   - Initial Contents: simple_majority, weighted_trust, bft

8.  Implementation Guide and Reference Implementation

8.1.  Minimal Viable Implementation (COE-Lite)

   To facilitate community validation and adoption, a minimal reference
   implementation, COE-Lite, is recommended:

   - Core functionality:
     * J/D/T/V event generation and verification (including Ed25519
       signatures)
     * In-memory audit chain maintenance
     * Simple majority consensus engine
     * HTTP REST API interface
   - Code size: Approximately 2000-3000 lines (Python or Go)
   - Excluded: Actual world model integration, persistent storage,
     distributed communication

   COE-Lite aims to demonstrate protocol feasibility, not production-
   grade readiness.

8.2.  Verification Scenario

   The following scenario verifies the correctness of COE-Lite:

   Scenario: Three simulated robots (A, B, C) collaboratively confirm
   the state of a door.

   1. A issues J event: assertion={door: open, confidence: 0.9}
   2. B issues V event: verify_of=[A.J], verification_result="confirmed"
   3. C issues V event: verify_of=[A.J], verification_result="confirmed"
   4. Consensus engine (simple majority) outputs SWS: door=open
   5. A observes door closed; issues T event (terminate_of=A.J), then
      new J event: door=closed
   6. B and C confirm the new state sequentially
   7. Consensus engine updates SWS: door=closed

   Verification checkpoints:
   - Audit chain integrity (all events correctly hash-linked)
   - Signature verification (all signatures valid)
   - Consensus convergence (both state transitions correctly output)
   - Version traceability (complete evolution from open to closed
     queryable)

8.3.  Integration with Existing Standards

   - Identity: W3C DID [DID-CORE] or OAuth 2.0 [RFC6749] RECOMMENDED
     for CU identity management.
   - Environmental Trust: RATS [RFC9334] MAY be integrated to attest
     that a world model runs in a trusted execution environment.
   - Accountability: COE events MAY be referenced as evidence in JEP
     events, enabling seamless linkage from cognitive consensus to
     accountability tracing.

9.  References

9.1.  Normative References

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

   [RFC4122]  Leach, P., Mealling, M., and R. Salz, "A Universally
              Unique IDentifier (UUID) URN Namespace", RFC 4122,
              July 2005.

   [RFC8032]  Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital
              Signature Algorithm (EdDSA)", RFC 8032, January 2017.

   [RFC8785]  Rundgren, A., Jordan, B., and S. Erdtman, "JSON
              Canonicalization Scheme (JCS)", RFC 8785, June 2020.

   [RFC9334]  Birkholz, H., et al., "Remote ATtestation procedureS
              (RATS) Architecture", RFC 9334, December 2022.

9.2.  Informative References

   [DID-CORE] Sporny, M., et al., "Decentralized Identifiers (DIDs)
              v1.0", W3C Recommendation, July 2022.

   [RFC6749]  Hardt, D., "The OAuth 2.0 Authorization Framework",
              RFC 6749, October 2012.

   [JEP]      Wang, Y., "JEP: A Judgment Event Protocol",
              draft-wang-jep-judgment-event-protocol, March 2026.

   [HJS]      Wang, Y., "HJS: An Accountability Layer for AI Agents",
              draft-wang-hjs-accountability, February 2026.

   [AIGA]     Aylward, E., "AI Governance and Accountability Protocol",
              draft-aylward-aiga, January 2026.

   [MACP]     Li, X., et al., "Multi-agent Collaboration Protocol
              Suite", draft-li-dmsc-macp, February 2026.

Appendix A.  Complete Verification Workflow Example

   This appendix presents an end-to-end example with a complete COE
   verification workflow, suitable as a reference test case for proof-
   of-concept implementations.

   A.1.  Initial Setup
       - CU-A: Robot A (JEPA world model, trust weight 0.9)
       - CU-B: Robot B (Dreamer world model, trust weight 0.8)
       - CU-C: Human supervisor (trust weight 1.0)
       - Target: warehouse-zone-3
       - Consensus Policy: weighted_trust (threshold=1.5)

   A.2.  Event Sequence

       Step 1: CU-A observes door is open
       Event#1 (J): A -> COE: { assertion: {subject: "door",
                            predicate: "status", value: "open",
                            confidence: 0.95} }

       Step 2: CU-B delegates continuous observation to CU-A (optional,
               demonstrates D primitive)
       Event#2 (D): B -> COE: { delegate_to: "A",
                            delegation_scope: "continuous_observation" }

       Step 3: CU-B confirms A's observation
       Event#3 (V): B -> COE: { verify_of: [Event#1],
                            verification_result: "confirmed" }

       Step 4: CU-C (human) also confirms A's observation
       Event#4 (V): C -> COE: { verify_of: [Event#1],
                            verification_result: "confirmed" }

       Consensus calculation:
       - confirmed_weight = 0.8 (B) + 1.0 (C) = 1.8 > threshold 1.5
       - Output SWS#1: door = "open"

       Step 5: CU-A observes door is closed
       Event#5 (T): A -> COE: { terminate_of: Event#1,
                            terminate_reason: "state_changed" }
       Event#6 (J): A -> COE: { assertion: {subject: "door",
                            predicate: "status", value: "closed",
                            confidence: 0.95} }

       Step 6: CU-B confirms new state
       Event#7 (V): B -> COE: { verify_of: [Event#6],
                            verification_result: "confirmed" }

       Step 7: CU-C confirms new state
       Event#8 (V): C -> COE: { verify_of: [Event#6],
                            verification_result: "confirmed" }

       Consensus calculation:
       - confirmed_weight = 0.8 + 1.0 = 1.8 > 1.5
       - Output SWS#2: door = "closed"

   A.3.  Verification Checkpoints

       1. Audit chain integrity:
          - Verify all prev_event_id links are correct
          - Verify all hash calculations
          - Verify all signatures are valid

       2. Consensus correctness:
          - Verify SWS#1 is based on Event#1, confirmed by Event#3 and
            Event#4
          - Verify SWS#2 is based on Event#6, confirmed by Event#7 and
            Event#8
          - Verify the door state transition from open to closed is
            correctly recorded

       3. Version traceability:
          - Query history for "door" should return two versions
          - Each version can be traced back to its dependent J/V events

       4. Fault injection tests:
          - Inject event with invalid signature; verify rejection
          - Inject event breaking hash chain; verify detection
          - Inject contradictory V events; verify consensus resolves
            correctly per policy

Author's Address

   Yuqiang Wang
   HJS Foundation Ltd.
   Email: yuqiang@humanjudgment.org
