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:", "world_model_ref": "sha256:", "adapter_ref": "sha256:", "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:"], "method_ref": "sha256:", "result_label": "declared-consistent", "validation_ref": "sha256:" } 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:", "evidence_refs": [ "sha256:", "sha256:" ], "synthesis_profile": "https://example.org/coe-synthesis-v1", "synthesis_report_ref": "sha256:", "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:", "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:", "input_ref": "sha256:", "output_ref": "sha256:", "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:", "sha256:" ], "output_claim": "sha256:", "parameters_ref": "sha256:", "report_ref": "sha256:" } 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, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [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, . [DID-CORE] Sporny, M., Longley, D., Sabadello, M., Reed, D., Steele, O., and C. Allen, "Decentralized Identifiers (DIDs) v1.0", W3C Recommendation, July 2022, . 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:", "world_model_ref": "sha256:", "adapter_ref": "sha256:" } A.2. JEP Event Binding the Observation Record { "jep": "1", "verb": "J", "who": "did:example:robot-a", "when": 1776000001, "what": "sha256:", "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:", "evidence_refs": [ "sha256:", "sha256:" ], "synthesis_profile": "https://example.org/coe-synthesis-v1", "synthesis_report_ref": "sha256:", "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