Cognition-Oriented Emergence (COE): A JEP Profile for Shared Observation and State-Claim Evidence
draft-wang-coe-01

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

                Cognition-Oriented Emergence (COE):
     A JEP Profile for Shared Observation and State-Claim Evidence
                         draft-wang-coe-01

Abstract

   This document defines Cognition-Oriented Emergence (COE) v0.5, an
   optional profile of the Judgment Event Protocol (JEP) for binding
   observation records, validation records, shared-state claims, and
   evidence references across heterogeneous world models and cognitive
   units.

   COE provides verifiable shared-observation infrastructure.  It does
   not determine objective world truth, factual causality, governance
   consensus, legal effect, operational authority, fairness, trust
   weights, or compliance.  A valid COE record proves cryptographic
   binding and structural consistency of declared observations,
   validations, state claims, and evidence references.  It does not
   prove that a shared-state claim is true, complete, uniquely
   determined, or sufficient for any external target fact.

   COE follows a minimal-core design.  The core defines JEP-based record
   binding and validation.  State-synthesis policies, consensus methods,
   version anchoring, timestamp anchoring, determinability reports,
   adapter records, and multi-party evidence views are optional
   extensions or deployment profiles.

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 29, 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 to JEP, HJS, and JAC
     1.3.  Infrastructure Positioning
     1.4.  Requirements Language
     1.5.  Terminology
   2.  COE Model
     2.1.  Minimal Core and Optional Extensions
     2.2.  JEP Verb Usage in COE
     2.3.  Shared-State Claims
     2.4.  What COE Does Not Determine
   3.  COE-Core-1 Profile
     3.1.  Required JEP Profile
     3.2.  what/ref Semantics
     3.3.  ext and ext_crit Usage
     3.4.  COE Record Digest Binding
   4.  COE Records
     4.1.  Observation Record
     4.2.  Validation Record
     4.3.  Shared-State Claim
     4.4.  Evidence Descriptor
     4.5.  Adapter Descriptor
     4.6.  State-Synthesis Report
   5.  Optional Extensions
     5.1.  Observation Extension
     5.2.  Validation Extension
     5.3.  State-Claim Extension
     5.4.  Evidence Extension
     5.5.  Adapter Extension
     5.6.  Synthesis-Report Extension
     5.7.  Version Anchor Extension
     5.8.  Timestamp Anchor Extension
     5.9.  Determinability-Report Extension
   6.  Validation
     6.1.  JEP Validation
     6.2.  COE Structural Validation
     6.3.  Evidence Reference Validation
     6.4.  Shared-State Claim Validation
     6.5.  Archival Validation
   7.  State-Synthesis Profiles
     7.1.  Optional Nature of Synthesis Profiles
     7.2.  Non-Normative Examples
     7.3.  Synthesis Is Not Truth
   8.  Security and Privacy Considerations
     8.1.  Observation Does Not Equal Truth
     8.2.  Shared-State Claim Does Not Equal Objective World State
     8.3.  Partial Observation and Target Determinability
     8.4.  Sybil and Trust Profiles
     8.5.  Privacy and Data Minimization
     8.6.  State-Synthesis Policy Limits
   9.  IANA Considerations
   10. References
     10.1. Normative References
     10.2. Informative References
   Appendix A.  Example COE Records and JEP Events
   Appendix B.  Changes from draft-wang-coe-00
   Author's Address

1.  Introduction

1.1.  Problem Statement

   Heterogeneous world models, agents, sensors, simulators, and human
   operators increasingly need to exchange observation-derived evidence
   about a shared operational environment.  These systems may disagree,
   observe different projections of the same environment, use different
   evidence formats, or synthesize state claims under different policies.

   COE addresses a narrow interoperability problem: how to bind
   observation records, validation records, shared-state claims, and
   evidence references into verifiable records that can be exported,
   audited, and related across systems.

   COE does not try to define a universal world model.  COE also does
   not define how a deployment should decide which observations to
   trust, which synthesis policy is correct, which state claim is true,
   or which governance consequence should follow.

1.2.  Relationship to JEP, HJS, and JAC

   COE is a profile of JEP.  COE events are JEP events conforming to
   JEP-Core-1.  COE does not define an independent event format,
   signature syntax, canonicalization rule, nonce rule, event hash,
   replay rule, extension container, or key-resolution rule.

   HJS defines an AI-agent accountability receipt and behavior-record
   profile over JEP.  COE records MAY be referenced from HJS receipt
   bundles when observation evidence is relevant to AI-agent behavior.

   JAC defines an optional declared-dependency chain profile over JEP
   and HJS.  COE records MAY use JAC dependency links when a deployment
   needs to express declared dependencies between observations,
   validation records, state claims, tasks, or receipt elements.

   COE, HJS, and JAC are complementary profiles.  JEP provides the
   minimal verifiable event substrate.  HJS provides AI-agent receipt
   infrastructure.  JAC provides declared-dependency chain
   infrastructure.  COE provides shared-observation and state-claim
   evidence infrastructure.

1.3.  Infrastructure Positioning

   COE is infrastructure for creating, binding, exporting, and
   validating shared-observation evidence and shared-state claims.  COE
   is not a governance framework, truth engine, consensus authority,
   liability system, trust-weight registry, fairness engine, appeal
   system, explanation-rights framework, or legal evidence rulebook.

   COE provides ways to reference and verify externally supplied
   records.  COE does not define the meaning, sufficiency, truth,
   legal effect, moral character, governance consequence, or
   evidentiary effect of those records.

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

1.5.  Terminology

   Cognitive Unit (CU):  An entity that emits, validates, receives, or
      processes COE-related JEP events.  A CU can be an AI agent,
      robot, sensor system, simulator, human-operated service, or other
      system component.  COE does not define a global identity system
      for CUs.

   World Model (WM):  A model, simulator, sensing pipeline, environment
      representation, or other system that produces observations or
      state estimates.  COE does not prescribe internal WM design.

   Observation Record:  A deployment-defined record describing an
      observation claim and its evidence references.

   Validation Record:  A deployment-defined record describing a
      validation claim, cross-observation check, consistency check, or
      other verification-related claim.

   Shared-State Claim (SSC):  A signed or digest-bound claim derived
      from one or more observation records, validation records, or
      evidence descriptors under a declared synthesis profile.  An SSC
      is not a protocol-level determination of objective world state.

   Evidence Descriptor:  A record identifying evidence material by
      digest, URI, storage reference, redaction profile, media type, or
      deployment-defined evidence reference.

   Adapter Descriptor:  A record describing how a world model, sensor,
      simulator, or agent output was translated into a COE record.

   State-Synthesis Profile:  A deployment-defined policy or procedure
      used to derive an SSC from evidence.  COE does not define which
      synthesis profile is correct for any deployment.

2.  COE Model

2.1.  Minimal Core and Optional Extensions

   COE-Core-1 is intentionally minimal.  It defines:

   *  use of JEP-Core-1 events for COE record binding;

   *  digest binding between a JEP event's what field and a COE record;

   *  optional COE extension identifiers carried in JEP ext;

   *  structural validation of COE record references; and

   *  boundary rules stating that COE records are claims and evidence
      references, not protocol-level truth or governance determinations.

   All other capabilities, including state-synthesis policies,
   consensus methods, version anchoring, timestamp anchoring, adapter
   records, determinability reports, multi-party evidence views, trust
   weighting, and privacy-specific evidence views, are optional
   extensions or deployment profiles.

   The absence of an optional COE extension MUST NOT be interpreted by
   the protocol as agreement, waiver, admission, lack of objection,
   absence of conflicting observations, absence of relevant context,
   absence of external rights, or proof that a target fact is
   determined.

2.2.  JEP Verb Usage in COE

   COE uses the four JEP verbs without changing their core JEP event
   semantics.  In a COE profile, the verbs can be used as follows:

   J:  Records an observation claim, validation claim, shared-state
      claim, synthesis report, or other COE record issuance.

   D:  Records a delegation request, delegation claim, or delegation
      reference related to observation, validation, synthesis, or
      evidence handling.  COE does not determine whether the delegation
      is legally, organizationally, operationally, epistemically, or
      technically valid.

   V:  Records a validation claim, cross-observation check, or
      verification-related record.  COE does not determine whether the
      underlying observation is true, complete, or sufficient to settle
      any external target fact.

   T:  Records a termination, supersession, retraction, or lifecycle
      boundary claim concerning a COE record or state claim.  COE does
      not by itself enforce state termination.

   COE MUST NOT register new JEP verbs for observation, state, or
   synthesis semantics.  Such semantics are expressed through COE
   records and optional extensions.

2.3.  Shared-State Claims

   A Shared-State Claim is a declared state claim derived under a
   deployment-defined synthesis profile.  An SSC MAY reference
   observations, validations, evidence descriptors, adapter descriptors,
   or synthesis reports.

   An SSC is not a protocol-level representation of objective world
   truth.  It is a signed or digest-bound statement that a CU, system,
   or synthesis process has declared a state claim under some profile.

2.4.  What COE Does Not Determine

   COE does not determine:

   *  objective world truth;

   *  factual causality or complete causal history;

   *  whether a shared-state claim is correct or fair;

   *  whether a state-synthesis profile is appropriate;

   *  legal effect, liability, authorization, or compliance;

   *  who is entitled to rely on, disclose, or withhold evidence;

   *  whether evidence is admissible in any legal or organizational
      proceeding; or

   *  whether a target fact is zero-error determinable from available
      observations.

3.  COE-Core-1 Profile

3.1.  Required JEP Profile

   A COE-Core-1 implementation MUST use JEP events conforming to
   JEP-Core-1.  COE-Core-1 does not define independent signature,
   canonicalization, hash, nonce, replay, key-resolution, trust-anchor,
   or event-hash rules.

   COE record content MAY be embedded in a signed JEP event, but the
   RECOMMENDED pattern is to bind a COE record by digest using the JEP
   what field and to carry record-type metadata in the JEP ext field.

3.2.  what/ref Semantics

   In COE, the JEP what field normally contains the algorithm-tagged
   digest of a COE record.  The referenced record can be an observation
   record, validation record, shared-state claim, evidence descriptor,
   adapter descriptor, or synthesis report.

   The JEP ref field MAY reference the event hash of a related JEP
   event.  If a deployment needs to express dependency links between
   records or events, it SHOULD use the JAC declared-dependency profile
   or a COE evidence reference, rather than defining a new top-level
   field.

3.3.  ext and ext_crit Usage

   COE-specific metadata is carried in the JEP ext object.  If a COE
   extension is critical to validation or interpretation, its extension
   identifier MUST be listed in JEP ext_crit.  A verifier that does not
   understand or cannot process a critical COE extension MUST reject the
   event according to JEP extension rules.

   Non-critical COE extensions MAY be ignored by a verifier that does
   not understand them.  Ignoring a non-critical extension MUST NOT be
   interpreted as accepting the truth, sufficiency, or policy effect of
   the underlying record.

3.4.  COE Record Digest Binding

   A COE record is bound to a JEP event when the event's what field
   equals the digest of the canonicalized COE record under the digest
   algorithm identified by the what field.

   COE does not require any particular storage location for COE
   records.  Records can be embedded, stored out-of-band, included in a
   receipt bundle, or referenced through storage profiles, provided
   that the digest binding remains verifiable.

4.  COE Records

4.1.  Observation Record

   An observation record is a deployment-defined claim that some CU,
   world model, sensor, simulator, human-operated system, or adapter
   produced an observation-related output.

   Example:

   {
     "coe_record": "1",
     "record_type": "observation",
     "observer": "did:example:robot-a",
     "target": "warehouse-zone-3",
     "observed_at": 1776000000,
     "observation_ref": "sha256:<digest-of-observation-payload>",
     "world_model_ref": "sha256:<digest-of-world-model-descriptor>",
     "adapter_ref": "sha256:<digest-of-adapter-descriptor>",
     "confidence_label": "deployment-defined"
   }

   The confidence_label field is a deployment-defined label.  COE does
   not assign a mathematical or governance meaning to such labels.

4.2.  Validation Record

   A validation record is a deployment-defined claim that one or more
   observations, state claims, or evidence records were checked under a
   validation method.

   Example:

   {
     "coe_record": "1",
     "record_type": "validation",
     "validator": "did:example:robot-b",
     "validates": ["sha256:<observation-record-digest>"],
     "method_ref": "sha256:<validation-method-descriptor>",
     "result_label": "declared-consistent",
     "validation_ref": "sha256:<validation-report-digest>"
   }

   COE does not define whether result_label values imply correctness,
   sufficiency, or truth.

4.3.  Shared-State Claim

   A shared-state claim is a deployment-defined state claim associated
   with a target, scope, evidence set, and synthesis profile.

   Example:

   {
     "coe_record": "1",
     "record_type": "shared-state-claim",
     "target": "warehouse-zone-3",
     "claim_ref": "sha256:<state-claim-payload-digest>",
     "evidence_refs": [
       "sha256:<observation-record-digest>",
       "sha256:<validation-record-digest>"
     ],
     "synthesis_profile": "https://example.org/coe-synthesis-v1",
     "synthesis_report_ref": "sha256:<synthesis-report-digest>",
     "valid_from": 1776000000,
     "valid_until": null
   }

   A shared-state claim is evidence-bound.  It is not a COE-level
   determination that the external world has that state.

4.4.  Evidence Descriptor

   An evidence descriptor identifies external material used by a COE
   record.

   Example:

   {
     "coe_record": "1",
     "record_type": "evidence-descriptor",
     "evidence_ref": "sha256:<evidence-digest>",
     "media_type": "application/json",
     "storage_ref": "https://storage.example/object/123",
     "redaction_profile": "https://example.org/redaction-profile-v1",
     "access_profile": "deployment-defined"
   }

   COE does not determine who is entitled to access evidence material.

4.5.  Adapter Descriptor

   An adapter descriptor describes a transformation from a world model,
   sensor, simulator, or agent output into a COE record.

   Example:

   {
     "coe_record": "1",
     "record_type": "adapter-descriptor",
     "adapter_id": "https://example.org/adapters/robot-v1",
     "source_system_ref": "sha256:<source-system-descriptor>",
     "input_ref": "sha256:<adapter-input-digest>",
     "output_ref": "sha256:<adapter-output-digest>",
     "profile": "https://example.org/coe-adapter-profile-v1"
   }

   Adapter descriptors are evidence records.  They do not prove that an
   adapter is accurate, safe, lawful, or appropriate.

4.6.  State-Synthesis Report

   A state-synthesis report records how a deployment-defined process
   derived a shared-state claim from one or more evidence references.

   Example:

   {
     "coe_record": "1",
     "record_type": "synthesis-report",
     "synthesis_profile": "https://example.org/coe-synthesis-v1",
     "inputs": [
       "sha256:<observation-record-digest>",
       "sha256:<validation-record-digest>"
     ],
     "output_claim": "sha256:<shared-state-claim-digest>",
     "parameters_ref": "sha256:<synthesis-parameters-digest>",
     "report_ref": "sha256:<full-report-digest>"
   }

   COE does not define whether a synthesis report is correct or
   sufficient.

5.  Optional Extensions

5.1.  Observation Extension

   Identifier: https://coe.org/observation

   Purpose: Identifies that a JEP event's what field binds an
   observation record.

   Example:

   {
     "https://coe.org/observation": {
       "record_type": "coe-observation-record",
       "target": "warehouse-zone-3"
     }
   }

5.2.  Validation Extension

   Identifier: https://coe.org/validation

   Purpose: Identifies that a JEP event's what field binds a validation
   record.

5.3.  State-Claim Extension

   Identifier: https://coe.org/state-claim

   Purpose: Identifies that a JEP event's what field binds a
   shared-state claim.

5.4.  Evidence Extension

   Identifier: https://coe.org/evidence

   Purpose: Identifies evidence descriptors associated with a COE
   record or JEP event.

5.5.  Adapter Extension

   Identifier: https://coe.org/adapter

   Purpose: Identifies adapter descriptors used to translate world-model
   output into COE records.

5.6.  Synthesis-Report Extension

   Identifier: https://coe.org/synthesis-report

   Purpose: Identifies state-synthesis reports and their deployment-
   defined synthesis profiles.

5.7.  Version Anchor Extension

   Identifier: https://coe.org/version

   Purpose: Identifies a versioned bundle of shared-state claims,
   observation records, validation records, and evidence descriptors.
   Version anchoring is optional and does not imply a linear global
   history.

5.8.  Timestamp Anchor Extension

   Identifier: https://coe.org/timestamp-anchor

   Purpose: Identifies external timestamp evidence, such as an RFC 3161
   timestamp token or other deployment-defined timestamp proof.  COE
   does not require any particular timestamp authority.

5.9.  Determinability-Report Extension

   Identifier: https://coe.org/determinability-report

   Purpose: Identifies an external determinability analysis, finite
   model-checking result, counterexample pair, decision table, or
   evidence-coverage report concerning whether a target fact is
   determinable from available observations.

   A determinability-report extension is a technical reference.  COE
   does not determine that the report is correct, complete, legally
   sufficient, or applicable to an external system.

6.  Validation

6.1.  JEP Validation

   A verifier MUST first perform JEP validation according to the
   applicable JEP validation mode and trust profile.  If the JEP event
   is invalid, the COE record binding is invalid.

6.2.  COE Structural Validation

   A COE structural validator checks that:

   *  the JEP what field is a well-formed digest reference;

   *  the referenced COE record is available when required by the
      verification context;

   *  the COE record digest matches the JEP what field;

   *  the COE record_type is consistent with any COE extension present
      in ext; and

   *  critical COE extensions listed in ext_crit are understood and
      processed.

   Structural validation does not prove truth, sufficiency, or external
   legal effect.

6.3.  Evidence Reference Validation

   Evidence reference validation checks whether evidence references are
   well formed, whether available evidence matches its declared digest,
   and whether redaction or storage descriptors are structurally
   consistent with the deployment profile.

   COE does not determine whether evidence is complete, admissible,
   accessible to a particular party, or sufficient to settle a target.

6.4.  Shared-State Claim Validation

   Shared-state claim validation checks digest binding, evidence
   references, declared synthesis profile references, and structural
   consistency of the SSC record.

   COE validation does not prove that the state claim is objectively
   true, fair, complete, unique, or action-guiding.

6.5.  Archival Validation

   Archival validation of COE records follows archival validation of
   the underlying JEP events.  Freshness checks used for real-time
   acceptance MUST NOT by themselves cause rejection of historical COE
   records during archival validation.

7.  State-Synthesis Profiles

7.1.  Optional Nature of Synthesis Profiles

   COE-Core-1 does not require any particular consensus, voting,
   weighting, trust, or state-synthesis policy.  A deployment MAY define
   a state-synthesis profile that derives SSCs from observation records,
   validation records, and evidence descriptors.

   Such profiles are external to COE-Core-1.  They can be referenced by
   digest, URI, profile identifier, or deployment-defined descriptor.

7.2.  Non-Normative Examples

   Non-normative synthesis profiles could include:

   *  simple majority over validation records;

   *  weighted validation using deployment-defined CU weights;

   *  Byzantine-fault-tolerant agreement among a fixed membership;

   *  sensor-fusion profiles;

   *  human-supervised review profiles; or

   *  domain-specific scientific evidence profiles.

   COE does not require or endorse any of these profiles.

7.3.  Synthesis Is Not Truth

   A state-synthesis profile produces a declared shared-state claim, not
   objective truth.  A verifier MAY accept, reject, rank, or ignore a
   synthesis profile according to local policy or an external trust
   framework.

8.  Security and Privacy Considerations

8.1.  Observation Does Not Equal Truth

   A valid COE observation record proves that an observation claim was
   bound to a valid JEP event and associated evidence references.  It
   does not prove that the observation is true, complete, unbiased, or
   sufficient for any external decision.

8.2.  Shared-State Claim Does Not Equal Objective World State

   A valid SSC proves digest binding and structural consistency of a
   declared shared-state claim.  It does not prove that the claim is
   the objective world state or that other possible histories are ruled
   out.

8.3.  Partial Observation and Target Determinability

   COE deployments often operate under partial observation.  In such
   systems, different real histories can produce the same observed COE
   records while differing on a target fact of interest.  Logs,
   measurements, explanations, validation claims, or shared-state
   claims therefore do not by themselves guarantee that a target fact is
   determinable.

   When a deployment needs to decide whether available evidence is
   sufficient to settle a target fact, it SHOULD use an external
   observation model, target model, evidence policy, or determinability
   report.  COE can bind and export such reports but does not determine
   their correctness or effect.

8.4.  Sybil and Trust Profiles

   COE does not define a global trust framework for CUs.  Deployments
   using state-synthesis profiles that depend on participant identity,
   membership, or trust weights MUST define their own trust profile.
   COE does not determine whether a CU is trustworthy or whether a
   trust-weight assignment is fair.

8.5.  Privacy and Data Minimization

   Observation records and evidence descriptors can reveal sensitive
   information, including location, behavior, device state, operational
   context, or human-related data.  Deployments SHOULD minimize
   plaintext sensitive data, use digest-bound references where
   appropriate, and apply redaction, encryption, access control, and
   retention policies according to external requirements.

   COE does not require disclosure of all evidence to all parties.
   Multi-party exports and privacy-preserving evidence views are
   deployment-defined.

8.6.  State-Synthesis Policy Limits

   State-synthesis policies can be attacked or misused through Sybil
   identities, manipulated weights, biased evidence collection,
   selective disclosure, conflicting observations, stale evidence, or
   adversarial adapters.  COE provides record binding and exportability;
   it does not guarantee that a synthesis policy is robust, fair,
   lawful, or suitable.

9.  IANA Considerations

   This document does not request creation of a separate COE Primitives
   Registry.  COE uses the JEP verbs J, D, T, and V.

   COE-specific extensions are intended to be registered in the JEP
   Extensions Registry defined by [JEP].  Initial registrations are:

   *  https://coe.org/observation

   *  https://coe.org/validation

   *  https://coe.org/state-claim

   *  https://coe.org/evidence

   *  https://coe.org/adapter

   *  https://coe.org/synthesis-report

   *  https://coe.org/version

   *  https://coe.org/timestamp-anchor

   *  https://coe.org/determinability-report

   Extension identifiers are stable identifiers and are not required to
   be dereferenceable.

10.  References

10.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/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>.

   [JEP]      Wang, Y., "Judgment Event Protocol (JEP)", Work in
              Progress, Internet-Draft,
              draft-wang-jep-judgment-event-protocol-05,
              April 2026.

10.2.  Informative References

   [HJS]      Wang, Y., "HJS: Accountability Receipts for AI Agents",
              Work in Progress, Internet-Draft,
              draft-wang-hjs-accountability-05, April 2026.

   [JAC]      Wang, Y., "JAC: Judgment Accountability Chain", Work in
              Progress, Internet-Draft, draft-wang-jac-02,
              April 2026.

   [TARGET-DETERMINABILITY]
              Wang, Y., "Target Determinability under Partial Causal
              Observation: A Faithful Reduction Framework", Zenodo,
              Version v1, DOI 10.5281/zenodo.19678205,
              April 2026.

   [RFC3161]  Adams, C., Cain, P., Pinkas, D., and R. Zuccherato,
              "Time-Stamp Protocol (TSP)", RFC 3161,
              DOI 10.17487/RFC3161, August 2001,
              <https://www.rfc-editor.org/info/rfc3161>.

   [DID-CORE]
              Sporny, M., Longley, D., Sabadello, M., Reed, D.,
              Steele, O., and C. Allen, "Decentralized Identifiers
              (DIDs) v1.0", W3C Recommendation, July 2022,
              <https://www.w3.org/TR/did-core/>.

Appendix A.  Example COE Records and JEP Events

A.1.  Observation Record

   {
     "coe_record": "1",
     "record_type": "observation",
     "observer": "did:example:robot-a",
     "target": "warehouse-zone-3",
     "observed_at": 1776000000,
     "observation_ref": "sha256:<observation-payload-digest>",
     "world_model_ref": "sha256:<world-model-digest>",
     "adapter_ref": "sha256:<adapter-digest>"
   }

A.2.  JEP Event Binding the Observation Record

   {
     "jep": "1",
     "verb": "J",
     "who": "did:example:robot-a",
     "when": 1776000001,
     "what": "sha256:<observation-record-digest>",
     "nonce": "550e8400-e29b-41d4-a716-446655440000",
     "aud": "https://warehouse.example",
     "ref": null,
     "ext": {
       "https://coe.org/observation": {
         "record_type": "coe-observation-record",
         "target": "warehouse-zone-3"
       }
     },
     "sig": "detached-jws-example"
   }

A.3.  Shared-State Claim Record

   {
     "coe_record": "1",
     "record_type": "shared-state-claim",
     "target": "warehouse-zone-3",
     "claim_ref": "sha256:<state-claim-payload-digest>",
     "evidence_refs": [
       "sha256:<observation-record-digest>",
       "sha256:<validation-record-digest>"
     ],
     "synthesis_profile": "https://example.org/coe-synthesis-v1",
     "synthesis_report_ref": "sha256:<synthesis-report-digest>",
     "valid_from": 1776000001,
     "valid_until": null
   }

Appendix B.  Changes from draft-wang-coe-00

   This version makes the following changes:

   *  Repositions COE as a JEP profile rather than an independent event
      protocol.

   *  Replaces objective "world state" and "cognitive consensus"
      language with shared-observation evidence and shared-state claim
      language.

   *  Removes independent COE signature, hash, nonce, event-id, and
      primitive registry mechanisms; these are inherited from JEP.

   *  Moves consensus and state-synthesis logic out of the core and
      into optional profiles.

   *  Replaces linear audit-chain requirements with evidence references
      and optional JAC dependency links.

   *  Adds explicit boundary text for partial observation, target
      determinability, and non-truth claims.

   *  Changes the intended status to Experimental.

Author's Address

   Yuqiang Wang
   HJS Foundation Ltd.
   Email: yuqiang@humanjudgment.org
   URI:   https://humanjudgment.org
   GitHub: https://github.com/hjs-spec