Internet-Draft COE September 2026
Wang Expires 30 March 2027 [Page]
Workgroup:
Network Working Group
Internet-Draft:
draft-wang-coe-02
Published:
Intended Status:
Experimental
Expires:
Author:
Y. Wang

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

Abstract

This document defines COE-2, an optional profile of the Judgment Event Protocol (JEP) [JEP] for binding shared observation records and shared-state claims across heterogeneous agents, sensors, world models, simulators, and human-operated systems.

COE-2 defines one critical JEP record-binding extension, two minimal digest-addressed record types, evidence-reference semantics, and independent COE validation checks. JEP remains authoritative for event verbs, Event Identity, Event Hash, signatures, references, extension processing, validation modes, and acceptance semantics.

COE-2 provides verifiable shared-observation infrastructure. It does not determine objective world truth, factual causality, consensus, authorization, legal effect, fairness, trust weights, or regulatory compliance. A valid COE result establishes only the cryptographic and structural properties actually checked under the selected 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 30 March 2027.

▲

Table of Contents

1. Introduction

Heterogeneous agents, sensors, simulators, world models, and human-operated systems increasingly exchange observation-derived evidence about shared operational environments. These systems may observe different projections of the same target, use different evidence formats, or derive state claims under different policies.

COE addresses a narrow interoperability problem:

Which observation or state-claim record was bound to this JEP event,
which evidence references does that record declare,
and can those bindings be independently revalidated?

COE does not define a universal world model or a truth engine.

JEP Profiles [JEP-PROFILES] defines profile selection and composition rules. JEP Conformance [JEP-CONFORMANCE] defines structured validation-result and test-harness conventions. JEP Receipt Profile [JEP-RECEIPT] MAY package COE records as evidence artifacts. JAC [JAC] MAY express declared dependencies between JEP events associated with COE records.

Where this document conflicts with JEP-Core, JEP-Core controls.

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

3. Scope and Terminology

3.1. COE-2 Defines

COE-2 defines:

  • one profile identifier;
  • one critical COE record-binding extension;
  • one Observation Record;
  • one Shared-State Claim Record;
  • one Evidence Reference structure;
  • optional semantic-profile references for observation and state-claim payloads;
  • independent COE validation checks;
  • open-world and non-inference boundaries.

3.2. COE-2 Does Not Define

COE-2 does not define:

  • new JEP verbs;
  • an independent event, signature, or hash format;
  • a replacement for Event Identity or Event Hash;
  • a universal world model;
  • a global observation ontology;
  • objective truth;
  • consensus or trust-weight algorithms;
  • factual causality;
  • complete-history semantics;
  • authorization or delegation validity;
  • adapter correctness;
  • timestamp authority;
  • determinability proofs;
  • governance or policy outcomes;
  • legal effect or regulatory compliance.

3.3. Observer

The entity identified in an Observation Record as having produced or reported the observation.

The Observer need not be the same entity as the JEP actor or signer.

3.4. Target

The object, environment, resource, entity, region, process, or other subject about which an observation or state claim is made.

3.5. Observation Record

A digest-addressed record declaring that an Observer produced or reported an observation about a Target and identifying the observation payload and supporting evidence.

An Observation Record does not establish that the observation is true, complete, unbiased, or sufficient.

3.6. Shared-State Claim

A digest-addressed record declaring a state claim about a Target under an identified synthesis profile and evidence set.

In Shared-State Claim, "shared" means that the claim is structured for exchange across systems. It does not mean that the claim is agreed, consensual, authoritative, unique, or objectively true.

A Shared-State Claim does not establish objective world state, consensus, or uniqueness.

3.7. Evidence Reference

A digest-first reference to evidence material.

A retrieval URI, when present, is a hint and is not the integrity identity of the evidence.

4. Profile and Extension Identifiers

4.1. COE-2 Profile Identifier

The profile identifier is:

https://humanjudgment.org/jep/profiles/coe/2

The label COE-2 MAY be used in documentation and user interfaces.

The identifier is a publisher-controlled HTTPS URI. Dereferencing it is not required for validation.

4.2. COE Record-Binding Extension Identifier

The critical COE record-binding extension identifier is:

https://humanjudgment.org/jep/extensions/coe-record-binding/2

A JEP event claiming COE-2 conformance MUST carry this extension in ext and MUST list the extension identifier in ext_crit.

A verifier that cannot process this critical extension cannot claim successful COE-2 validation.

4.3. Version Boundary

COE-2 is not wire-compatible with COE-Core-1 from draft-wang-coe-01.

COE-Core-1 commonly bound a COE record by placing its digest in JEP what. That cannot serve as a generic JEP-Core 0.7 binding rule because D, T, and V have verb-specific required what members.

COE-2 moves record binding to one critical extension and leaves Core what semantics entirely under JEP-Core.

Historical COE-Core-1 records and events MUST NOT be silently rewritten as COE-2 records or events.

5. Relationship to JEP-Core

COE-2 relies on JEP-Core for:

COE-2 MUST NOT redefine those semantics.

A producer MUST satisfy the selected JEP verb's Core requirements before COE record binding is considered.

In particular:

COE metadata MUST NOT replace those fields.

6. COE Record-Binding Extension

6.1. Extension Value

The extension value MUST be a JSON object containing:

  • profile
  • record_type
  • record_digest
  • media_type

profile MUST equal https://humanjudgment.org/jep/profiles/coe/2.

record_type MUST be one of:

  • observation
  • shared-state-claim

record_digest MUST be an algorithm-tagged digest string conforming to JEP digest-string rules.

media_type MUST be a non-empty string. The baseline COE-2 record encoding is application/json.

The extension MAY contain record_uri. If present, it MUST be an absolute URI and is a retrieval hint only.

Each COE-2 event binds exactly one primary COE record through this extension.

6.2. Extension Example 

{
  "ext": {
    "https://humanjudgment.org/jep/extensions/coe-record-binding/2": {
      "profile": "https://humanjudgment.org/jep/profiles/coe/2",
      "record_type": "observation",
      "record_digest": "sha256:aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa",
      "media_type": "application/json"
    }
  },
  "ext_crit": [
    "https://humanjudgment.org/jep/extensions/coe-record-binding/2"
  ]
}

The example digest is illustrative.

6.3. Binding-Event Circularity

A COE record MUST NOT contain the Event Hash of the JEP event that binds that record.

The record MAY contain that event's Event Identity when a companion profile requires such a back-reference, because Event Identity is stable independently of the event signature.

7. Evidence Reference

An Evidence Reference MUST be a JSON object containing:

digest MUST be an algorithm-tagged digest string.

An Evidence Reference MAY additionally contain:

When present:

The digest is the integrity identity. URI resolution success MUST NOT be treated as digest-integrity success.

If an Evidence Reference identifies an object governed by another profile, such as JEP Receipt Profile, validity under that other profile MUST be evaluated and reported separately from COE validity.

8. Observation Record

8.1. Required Shape

A COE-2 Observation Record MUST be a JSON object containing:

  • coe_record
  • record_type
  • observer
  • target
  • observed_at
  • observation
  • evidence

coe_record MUST equal "2".

record_type MUST equal "observation".

observer MUST be an object containing a non-empty string id. observer.type MAY be a non-empty string.

target MUST be an object containing non-empty string members type and id.

observed_at MUST be a non-negative integer representing declared Unix seconds. It is not trusted time or proof of freshness.

observation MUST be an Evidence Reference whose digest identifies the observation payload.

evidence MUST be an array of zero or more Evidence References.

8.2. Optional Members

An Observation Record MAY additionally contain:

  • observation_profile
  • world_model
  • adapter
  • context

observation_profile, when present, MUST be an absolute URI identifying the schema, vocabulary, semantic profile, or equivalent interpretation contract for the observation payload.

If interoperable semantic interpretation of the observation payload is required outside the originating deployment, the producer MUST include observation_profile.

A verifier that does not understand observation_profile MAY still validate the COE record binding and digest, but MUST NOT claim semantic interpretation of the observation payload under that profile.

world_model, when present, MUST be an Evidence Reference.

adapter, when present, MUST be an Evidence Reference.

context, when present, MUST be a JSON object whose semantics are defined by the deployment or an explicitly selected companion profile.

COE-2 does not define confidence scores, trust weights, or accuracy metrics. A companion profile MAY define them.

8.3. Observation Record Digest

The Observation Record Digest uses JCS [RFC8785] and is:

sha256(UTF8(JCS(observation_record)))

COE-2 producers and verifiers MUST support sha256 for Observation Record digests.

A companion profile MAY permit additional digest algorithms.

9. Shared-State Claim Record

9.1. Required Shape

A COE-2 Shared-State Claim Record MUST be a JSON object containing:

  • coe_record
  • record_type
  • target
  • claim
  • evidence
  • synthesis_profile

coe_record MUST equal "2".

record_type MUST equal "shared-state-claim".

target MUST be an object containing non-empty string members type and id.

claim MUST be an Evidence Reference identifying the state-claim payload.

evidence MUST be a non-empty array of Evidence References.

synthesis_profile MUST be an absolute URI identifying the procedure or policy under which the claim was derived.

9.2. Optional Members

A Shared-State Claim Record MAY contain:

  • claim_profile
  • synthesis_report
  • validity
  • context

claim_profile, when present, MUST be an absolute URI identifying the schema, vocabulary, semantic profile, or equivalent interpretation contract for the state-claim payload.

If interoperable semantic interpretation of the claim payload is required outside the originating deployment, the producer MUST include claim_profile.

A verifier that does not understand claim_profile MAY still validate the COE record binding and digest, but MUST NOT claim semantic interpretation of the state-claim payload under that profile.

synthesis_report, when present, MUST be an Evidence Reference.

validity, when present, MUST be an object that MAY contain valid_from and valid_until.

valid_from and valid_until, when present and non-null, MUST be non-negative integers representing declared Unix seconds.

If both are present and non-null, valid_until MUST NOT precede valid_from.

These times are declared claim intervals. They are not trusted timestamps or proof that the external world had the claimed state during that interval.

context, when present, MUST be a JSON object defined by the deployment or an explicitly selected companion profile.

9.3. Shared-State Claim Digest

The Shared-State Claim Record Digest uses JCS [RFC8785] and is:

sha256(UTF8(JCS(shared_state_claim_record)))

COE-2 producers and verifiers MUST support sha256 for Shared-State Claim digests.

9.4. Synthesis Is External

COE-2 does not define a state-synthesis algorithm.

A synthesis profile MAY define aggregation, filtering, conflict resolution, confidence handling, voting, weighting, model comparison, or other methods.

A COE verifier MUST NOT infer that a synthesis profile is correct, unbiased, complete, authoritative, or suitable merely because its identifier is present.

10. JEP Verb Usage

COE-2 does not assign new meanings to J/D/T/V.

A J event MAY carry a claim concerning issuance, adoption, or interpretation of a COE record while the COE binding remains in the critical extension.

A D event MAY carry a COE binding, but its delegation meaning remains entirely defined by JEP-Core and any applicable delegation profile.

A T event MAY terminate future reliance on a referenced JEP event within its declared termination scope. COE-2 does not define a state-claim retraction or cascade rule merely because a COE record is associated with that event.

A V event MAY record evaluation of a COE record or COE evidence under a declared verification scope.

COE record type MUST NOT be inferred solely from the JEP verb.

11. Interaction with JEP Receipt Profile

JEP Receipt Profile is optional for COE-2.

A COE record MAY appear as an external evidence object in a JEP Receipt Profile bundle.

A receipt bundle MAY include:

Receipt Profile validity and COE validity MUST be reported separately.

A valid receipt does not make a COE state claim true, and a valid COE record does not by itself make a receipt complete.

12. Interaction with JAC

JAC is optional for COE-2.

A JEP event associated with a COE record MAY also carry JAC dependency metadata.

A COE Evidence Reference does not automatically create a JAC graph edge.

A JAC edge between events does not automatically create a COE evidence relationship.

If both profiles are used, implementations MUST preserve their independent semantics and validation results.

JAC validity does not establish observation truth, state-claim truth, or COE evidence sufficiency.

13. Validation

13.1. Layer Separation

A COE validation result separates:

  • underlying JEP validation status;
  • COE checks;
  • COE overall status.

COE MUST NOT overwrite the underlying JEP validation result.

13.2. Baseline Validation Mode

A COE-2 verifier MUST support JEP archival validation mode.

If no JEP validation mode is explicitly requested, COE validation MUST use archival mode.

Archival COE validation MUST NOT consume JEP acceptance state.

A deployment MAY explicitly request another JEP validation mode when needed.

13.3. COE Checks

The initial COE-2 check identifiers are:

  • https://humanjudgment.org/jep/profiles/coe/2#profile-binding
  • https://humanjudgment.org/jep/profiles/coe/2#record-binding
  • https://humanjudgment.org/jep/profiles/coe/2#record-structure
  • https://humanjudgment.org/jep/profiles/coe/2#target-consistency
  • https://humanjudgment.org/jep/profiles/coe/2#evidence-reference
  • https://humanjudgment.org/jep/profiles/coe/2#evidence-integrity
  • https://humanjudgment.org/jep/profiles/coe/2#synthesis-reference
  • https://humanjudgment.org/jep/profiles/coe/2#validity-interval

Check statuses use the JEP conformance vocabulary:

  • pass
  • fail
  • not_checked
  • not_applicable
  • unsupported
  • indeterminate

A verifier MUST NOT report an unperformed COE check as pass.

13.4. Required Checks

For any COE-2 event, the required checks are:

  • profile-binding
  • record-binding
  • record-structure

target-consistency is required when the requested validation context contains an external target identifier to compare against the COE record.

The presence of observation_profile or claim_profile does not make semantic interpretation part of baseline COE structural validation. A deployment or companion profile that requires semantic interpretation MUST define the supported profile identifiers and the validation procedure for them.

evidence-reference is required when the COE record contains evidence references.

evidence-integrity is required only for evidence objects that the requested validation context requires to be resolved and checked.

synthesis-reference and validity-interval are required for Shared-State Claim Records when the corresponding fields are present.

13.5. Target Consistency

COE-2 does not define a universal target-comparison algorithm.

A domain profile that requires target matching MUST define normalization and comparison rules.

Absent such a domain rule, a verifier MUST NOT claim semantic target equality merely from string similarity.

13.6. COE Overall Status

The COE overall status is one of:

  • valid
  • invalid
  • indeterminate

For the requested COE validation context:

  • invalid means the underlying required JEP validation is invalid or at least one required COE check failed;
  • indeterminate means no required check failed, but the underlying required JEP validation is indeterminate or at least one required COE check is unsupported, not checked, or indeterminate;
  • valid means the underlying required JEP validation is valid and every required COE check passed or was not applicable.

valid means structurally and cryptographically valid under the selected checks. It does not mean objectively true.

13.7. Validation Procedure

A COE verifier SHOULD:

  • validate the JEP event under the requested JEP mode and selected profiles;
  • process the critical COE record-binding extension;
  • verify the COE profile identifier;
  • obtain the bound COE record;
  • canonicalize and hash the record;
  • compare the recomputed digest with record_digest;
  • validate the record structure for record_type;
  • evaluate target consistency when required;
  • validate evidence-reference structure;
  • resolve and verify required evidence digests;
  • validate synthesis-profile and optional synthesis-report references for a Shared-State Claim;
  • validate the declared validity interval when present;
  • return JEP status, COE checks, and COE status separately.

14. Verification Events

A JEP V event MAY record a COE evaluation.

The V event MUST satisfy JEP-Core V requirements.

COE-2 defines the following provisional profile-specific verification scopes:

A V event MUST identify the evaluated target through JEP ref.

what.result records the semantic result of the declared verification scope. It MUST NOT be confused with the independent per-check status vocabulary used by a COE validator.

A V event MUST NOT imply truth, completeness, or determinability beyond its declared verification scope.

15. Partial Observation and Determinability

COE-2 uses an open-world observation model.

Absence of an Observation Record MUST NOT be interpreted as proof that an observation did not occur.

Absence of a conflicting observation MUST NOT be interpreted as proof that no conflicting observation exists.

A set of COE records MUST NOT be presented as complete unless an explicitly selected external profile defines a complete-observation assumption and the requirements of that profile were satisfied.

COE-2 does not define whether a target fact is uniquely or zero-error determinable from available evidence.

A determinability report MAY be referenced as evidence under an external profile, but COE validity MUST NOT be presented as proof that the report is correct or that the target fact is determinable.

16. Optional Companion Semantics

COE-01 defined or described adapter, synthesis-report, version-anchor, timestamp-anchor, determinability-report, and multiple record-type-specific extensions.

COE-2 removes those elements from the narrow waist.

A companion profile MAY define:

Such profiles MUST NOT redefine JEP-Core semantics or the COE-2 baseline record types.

17. Conformance

17.1. COE-2 Producer

A conforming COE-2 Producer MUST:

  • produce a JEP event conforming to the applicable JEP Producer requirements;
  • preserve the selected JEP verb semantics;
  • include the critical COE record-binding extension;
  • list the extension in ext_crit;
  • use the COE-2 profile identifier;
  • bind exactly one Observation Record or Shared-State Claim Record by digest;
  • produce that record according to this specification;
  • avoid circular binding through the binding event's Event Hash.

17.2. COE-2 Verifier

A conforming COE-2 Verifier MUST:

  • perform or consume an actual JEP validation result;
  • support JEP archival validation mode;
  • process the critical COE extension;
  • support JCS plus SHA-256 record digest calculation;
  • perform all COE checks required by its validation context;
  • preserve independent check statuses;
  • distinguish JEP validity from COE validity;
  • return indeterminate rather than success when a required check cannot be completed.

18. Security Considerations

A valid COE result does not prove observation truth or objective state.

Implementations MUST consider:

A verifier MUST compare the recomputed COE record digest with the digest inside the signed critical COE extension.

A verifier MUST NOT infer actor binding, authority, causality, truth, completeness, or policy compliance from successful COE structural validation.

19. Privacy Considerations

COE records can expose:

Implementations SHOULD minimize plaintext personal or sensitive data.

Evidence SHOULD be referenced by digest when embedding it is unnecessary.

Digest references may still support correlation or dictionary attacks.

Partial export and redaction MAY reduce disclosure, but omitted material MUST NOT be presented as nonexistent or irrelevant.

COE does not determine access rights, consent, lawful basis, retention periods, or entitlement to disclose evidence.

20. Non-Inference Boundary

A successful COE validation MUST NOT be presented, by itself, as proof:

External profiles MAY use COE evidence when making those determinations, but those conclusions remain outside COE-2.

21. IANA Considerations

This document requests no IANA actions.

The COE-2 profile identifier, record-binding extension identifier, COE check identifiers, and COE verification-scope identifiers are publisher-controlled HTTPS URI identifiers.

Future specifications MAY define registries if deployment experience shows that stable shared registries are needed.

22. Examples

22.1. Observation Record 

{
  "coe_record": "2",
  "record_type": "observation",
  "observer": {
    "id": "did:example:robot-a",
    "type": "sensor-system"
  },
  "target": {
    "type": "warehouse-zone",
    "id": "warehouse-zone-3"
  },
  "observed_at": 1790424000,
  "observation": {
    "digest": "sha256:1111111111111111111111111111111111111111111111111111111111111111",
    "kind": "sensor-output",
    "media_type": "application/json"
  },
  "observation_profile": "https://example.org/coe/observations/temperature/v1",
  "evidence": [
    {
      "digest": "sha256:2222222222222222222222222222222222222222222222222222222222222222",
      "kind": "sensor-calibration",
      "media_type": "application/json"
    }
  ]
}

22.2. Shared-State Claim 

{
  "coe_record": "2",
  "record_type": "shared-state-claim",
  "target": {
    "type": "warehouse-zone",
    "id": "warehouse-zone-3"
  },
  "claim": {
    "digest": "sha256:3333333333333333333333333333333333333333333333333333333333333333",
    "kind": "state-claim-payload",
    "media_type": "application/json"
  },
  "claim_profile": "https://example.org/coe/claims/warehouse-state/v1",
  "evidence": [
    {
      "digest": "sha256:aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa",
      "profile": "https://humanjudgment.org/jep/profiles/coe/2",
      "record_type": "observation",
      "media_type": "application/json"
    }
  ],
  "synthesis_profile": "https://example.org/coe-synthesis/v1",
  "validity": {
    "valid_from": 1790424000,
    "valid_until": 1790427600
  }
}

22.3. JEP Event Carrying a COE Binding 

{
  "jep": "1",
  "id": "urn:uuid:018f4f8d-0000-7000-8000-000000000101",
  "verb": "J",
  "who": "did:example:observer-service",
  "when": 1790424000,
  "what": {
    "claim": "observation-record-issued"
  },
  "ext": {
    "https://humanjudgment.org/jep/extensions/coe-record-binding/2": {
      "profile": "https://humanjudgment.org/jep/profiles/coe/2",
      "record_type": "observation",
      "record_digest": "sha256:aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa",
      "media_type": "application/json"
    }
  },
  "ext_crit": [
    "https://humanjudgment.org/jep/extensions/coe-record-binding/2"
  ],
  "sig": "..."
}

23. Changes from -01

Major changes from draft-wang-coe-01:

24. References

24.1. Normative References

[JEP]
Wang, Y., "Judgment Event Protocol (JEP)", Work in Progress, Internet-Draft, draft-wang-jep-judgment-event-protocol-07, , <https://datatracker.ietf.org/doc/html/draft-wang-jep-judgment-event-protocol-07>.
[JEP-CONFORMANCE]
Wang, Y., "JEP Conformance and Test Suite", Work in Progress, Internet-Draft, draft-wang-jep-conformance-01, , <https://datatracker.ietf.org/doc/html/draft-wang-jep-conformance-01>.
[JEP-PROFILES]
Wang, Y., "JEP Profiles and Interoperability", Work in Progress, Internet-Draft, draft-wang-jep-profiles-01, , <https://datatracker.ietf.org/doc/html/draft-wang-jep-profiles-01>.
[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, , <https://www.rfc-editor.org/rfc/rfc2119>.
[RFC8174]
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, , <https://www.rfc-editor.org/rfc/rfc8174>.
[RFC8785]
Rundgren, A., Jordan, B., and S. Erlandsson, "JSON Canonicalization Scheme (JCS)", RFC 8785, , <https://www.rfc-editor.org/rfc/rfc8785>.

24.2. Informative References

[JAC]
Wang, Y., "JAC: Declared Dependency Graphs for JEP Events and Receipts", Work in Progress, Internet-Draft, draft-wang-jac-03, , <https://datatracker.ietf.org/doc/html/draft-wang-jac-03>.
[JEP-RECEIPT]
Wang, Y., "JEP Receipt Profile: Verifiable Behavior and Evidence Receipts", Work in Progress, Internet-Draft, draft-wang-jep-receipt-profile-00, , <https://datatracker.ietf.org/doc/html/draft-wang-jep-receipt-profile-00>.

Author's Address

Yuqiang Wang
URI: https://github.com/hjs-spec