Internet Engineering Task Force (IETF) Y. Wang Internet-Draft HJS Foundation Intended status: Experimental April 29, 2026 Expires: October 29, 2026 Co-Evolve Binding Profile (CEP) A JEP/HJS Profile for AI Evolution-Change Evidence Binding draft-wang-cep-01 Abstract This document defines the Co-Evolve Binding Profile (CEP) v0.5, an optional profile for binding AI evolution-change records to external anchor references, evidence descriptors, and exportable receipt bundles. CEP is designed for use with the Judgment Event Protocol (JEP) and Human Judgment Structure (HJS), and can be combined with other JEP-based profiles such as JAC and COE. CEP provides infrastructure for creating, binding, exporting, and validating evidence about declared AI evolution-change claims. CEP does not determine human sovereignty, AI alignment, governance authority, model safety, legal compliance, fairness, appeal rights, explanation rights, or whether an AI evolution event is permitted or prohibited. CEP follows a minimal-core design. The core defines evolution-change record digest binding, external anchor references, evidence references, receipt bundles, and structural validation. Change classifications, binding claims, review references, rollback or mitigation references, multi-party export, and determinability reports 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. Motivation 1.2. Relationship to JEP, HJS, JAC, and COE 1.3. Scope 1.4. Infrastructure Positioning 1.5. Requirements Language 1.6. Terminology 2. CEP Model 2.1. Minimal Core and Optional Extensions 2.2. Evolution-Change Claims 2.3. External Anchor References 2.4. Evidence References 2.5. Binding Claims 2.6. Receipt Bundles 2.7. What CEP Does Not Determine 3. CEP-Core-1 Profile 3.1. Required JEP/HJS Profiles 3.2. JEP what/ref Semantics 3.3. Evolution Record Digest Binding 3.4. ext and ext_crit Usage 3.5. CEP Structural Validation 4. CEP Records 4.1. Evolution-Change Record 4.2. Evidence Descriptor 4.3. Anchor Reference Descriptor 4.4. Receipt Manifest 5. Optional Extensions 5.1. Evolution Record Extension 5.2. Anchor References Extension 5.3. Change Class Extension 5.4. Binding Claim Extension 5.5. Review Reference Extension 5.6. Rollback or Mitigation Reference Extension 5.7. Multi-Party Export Extension 5.8. Determinability Report Extension 6. Validation 6.1. JEP Validation 6.2. HJS Receipt Validation 6.3. CEP Record Validation 6.4. Evidence Reference Validation 6.5. Archival Validation 7. Security and Privacy Considerations 7.1. Binding Claim Is Not Permission 7.2. Anchor Reference Is Not Governance 7.3. Evolution Record Is Not Proof of Evolution 7.4. Partial Observation and Target Determinability 7.5. Human Privacy and Non-Inference 7.6. Deployment Policy Boundaries 8. IANA Considerations 9. References 9.1. Normative References 9.2. Informative References Appendix A. Example CEP Records and JEP Events Appendix B. Changes from draft-wang-cep-00 Author's Address 1. Introduction 1.1. Motivation AI systems, large models, autonomous agents, and tool-using services can change over time. A change can involve a model update, a fine-tuning step, a policy update, a capability claim, a tool-chain update, an observed drift, a mitigation step, or another deployment- defined evolution-change event. Operators, auditors, researchers, participants, and downstream systems may need to know which records, evidence, review materials, or receipts were associated with such a declared change. CEP addresses a narrow interoperability problem: how to bind an evolution-change record to external anchor references, evidence descriptors, and exportable receipt bundles in a way that is compatible with JEP and HJS. CEP intentionally avoids protocol-level control over AI evolution. It provides technical mechanisms for evidence binding and export. It does not decide whether an AI system may evolve, whether an update should be accepted, whether a change is aligned, whether a rollback is required, or whether any external legal or governance process has been satisfied. 1.2. Relationship to JEP, HJS, JAC, and COE CEP is a JEP/HJS-compatible profile. CEP records are normally bound to JEP events by placing the digest of a CEP Evolution-Change Record in the JEP "what" field. CEP does not define an independent signature syntax, hash syntax, nonce rule, event identifier, event hash, key-resolution rule, replay rule, or extension container. Those mechanisms are inherited from JEP and applicable JEP trust profiles. HJS provides AI-agent behavior-record and receipt infrastructure over JEP. CEP receipt bundles MAY be included in HJS receipt bundles, or MAY reference HJS behavior records or HJS receipt manifests. JAC provides optional declared-dependency chain infrastructure. CEP records MAY use JAC links when a deployment wants to declare that an evolution-change record is based on prior tasks, records, receipts, or state claims. COE provides shared-observation and shared-state-claim evidence infrastructure. CEP records MAY reference COE observation records, validation records, or shared-state claims when observation evidence is relevant to an evolution-change claim. 1.3. Scope CEP defines: * a minimal evolution-change record profile; * digest binding from JEP events to CEP records; * optional external anchor references; * optional evidence references; * optional binding claims; * optional review, mitigation, rollback, multi-party export, and determinability-report extensions; and * validation rules for cryptographic and structural consistency. CEP explicitly does not define: * human sovereignty, human control rights, or institutional authority; * AI alignment, model safety, model permission, or model prohibition; * legal compliance, regulatory sufficiency, consent validity, or liability; * governance outcomes, escalation duties, sanctions, remedies, or operational acceptance/rejection; * appeal rights, explanation rights, access rights, or disclosure duties; * a universal taxonomy of AI evolution; or * a global trust framework for deciding which anchors, reviews, or evidence items are sufficient. 1.4. Infrastructure Positioning CEP is infrastructure for creating, binding, exporting, and validating AI evolution-change evidence records. It is not a governance layer above JEP, HJS, JAC, or COE. It is not a compliance authority, alignment verifier, permission gate, monitoring mandate, fairness engine, appeal system, explanation-rights framework, or legal evidence rulebook. CEP provides ways to reference and verify externally supplied materials. CEP does not define the content, meaning, sufficiency, truth, legal effect, moral character, governance consequence, or evidentiary effect of those materials. 1.5. 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.6. Terminology CEP: The Co-Evolve Binding Profile specified by this document. Evolution-Change Claim: A signed or digest-bound declaration that a system, model, agent, policy, tool chain, capability, or deployment state is associated with a described change. The claim is a record, not a proof that the change truly occurred. CEP Evolution-Change Record: A JSON record that identifies the subject of a declared change, a change reference, and optional evidence references. External Anchor Reference: A digest-bound or URI-based reference to externally supplied material, such as a review record, approval record, participant statement, policy profile, safety record, organizational process record, HJS receipt, JAC dependency record, or COE observation record. Evidence Reference: A reference to evidence associated with an evolution-change claim. CEP does not determine whether evidence is sufficient. Binding Claim: An optional declaration that an evolution-change record is associated with one or more anchor references under a deployment-defined profile. A binding claim is not a permission decision. Receipt Bundle: An exportable package containing JEP events, CEP records, HJS receipts, evidence descriptors, validation reports, or other digest-bound materials. 2. CEP Model 2.1. Minimal Core and Optional Extensions CEP-Core-1 is intentionally minimal. It defines only: * a JEP/HJS-compatible profile; * a CEP Evolution-Change Record; * use of the JEP "what" field to reference the digest of a CEP Evolution-Change Record; * optional evidence and anchor references; * optional receipt bundles; and * validation of signatures, digests, references, and structural consistency. All other capabilities are optional extensions or deployment profiles, including change classification, binding claims, review references, rollback or mitigation references, multi-party export, determinability reports, cryptographic capability profiles, and integration with JAC or COE. Optional extensions provide technical mechanisms only. They do not define governance rules, fairness, consent, appeal rights, explanation rights, liability, legal compliance, access rights, disclosure duties, remedies, sanctions, or evidentiary effect. The absence of an optional extension MUST NOT be interpreted by the protocol as agreement, waiver, admission, lack of objection, lack of harm, lack of relevant context, lack of external rights, or lack of external process. 2.2. Evolution-Change Claims A CEP Evolution-Change Record is a declared record. It identifies a subject reference and a change reference. The subject MAY be a model, model family, deployment, agent, service, policy, tool chain, capability claim, or other deployment-defined subject. The change reference normally points to an external change record, model-update manifest, diff record, training record, evaluation record, safety report, or other evidence object. CEP does not define a universal taxonomy of AI evolution. A change can be classified only by an optional change-class extension or an external profile. 2.3. External Anchor References External anchor references allow a CEP record to reference external materials. These materials can include human-review records, organizational approvals, participant statements, safety reviews, deployment policies, JEP events, HJS receipts, JAC dependency links, COE observation records, or other deployment-defined records. Anchor references are technical pointers only. CEP does not define their meaning, sufficiency, truth, legal effect, human-rights effect, moral character, governance consequence, or evidentiary value. 2.4. Evidence References Evidence references identify materials that may be relevant to an evolution-change claim. Evidence references MAY be algorithm-tagged digest strings, JEP event hashes, URIs, content-addressed storage identifiers, or other formats allowed by a deployment profile. CEP-Core-1 implementations MUST support algorithm-tagged digest strings compatible with JEP-Core-1. Other reference formats are deployment-defined. 2.5. Binding Claims A binding claim declares that an evolution-change record is associated with one or more anchor references under a deployment-defined binding profile. A binding claim can be useful where a deployment has an external rule requiring review, approval, safety assessment, participant notice, or other process before or after a change. A binding claim is not a permission gate. CEP does not determine whether a declared binding is valid, sufficient, legally effective, aligned, safe, fair, or enforceable. CEP also does not require a system to accept or reject an evolution-change event based on a binding claim. 2.6. Receipt Bundles CEP receipt bundles MAY include JEP events, CEP Evolution-Change Records, anchor references, evidence descriptors, validation reports, HJS receipts, JAC dependency links, COE observation records, and other digest-bound materials. Receipt bundles MAY be exported by multiple parties or as multiple privacy-preserving views according to deployment profiles. CEP preserves verifiability of included signatures and digest bindings, but does not define access rights, disclosure duties, procedural fairness, legal admissibility, or entitlement to export. 2.7. What CEP Does Not Determine A valid CEP record proves only cryptographic binding and structural consistency of declared records and references. It does not prove: * that an AI system truly evolved; * that a capability emerged; * that drift, loop formation, alignment, or misalignment occurred; * that a human, organization, or governance body approved the change; * that a review was sufficient; * that a deployment should accept, reject, roll back, or mitigate a change; or * that any external legal, organizational, safety, human-rights, or governance process has been satisfied. 3. CEP-Core-1 Profile 3.1. Required JEP/HJS Profiles CEP-Core-1 events are JEP events. A CEP-Core-1 producer MUST produce JEP events conforming to JEP-Core-1. A CEP-Core-1 verifier MUST perform JEP validation before applying CEP-specific validation. CEP records MAY be included in HJS receipt bundles. When CEP records are included in an HJS receipt bundle, the HJS receipt validation rules apply in addition to CEP structural validation. 3.2. JEP what/ref Semantics For a JEP event that binds a CEP Evolution-Change Record, the JEP "what" field SHOULD contain the digest of the CEP Evolution-Change Record. The JEP "ref" field MAY reference a related JEP event, HJS receipt, JAC dependency event, COE record, or prior CEP event, according to the applicable deployment profile. The use of "ref" does not by itself assert causality, permission, governance approval, or factual correctness. A JEP nonce is a replay-protection value. It MUST NOT be used as the primary long-term identifier for a referenced judgment event or anchor record. Long-term references SHOULD use JEP event hashes, record digests, or other stable digest-bound identifiers. 3.3. Evolution Record Digest Binding The CEP Evolution-Change Record is represented as a JSON object. If the record is hashed directly, it SHOULD be canonicalized using the JCS profile required by JEP-Core-1. The resulting digest SHOULD be represented as an algorithm-tagged digest string such as "sha256:". When a CEP record is referenced by a JEP event, the referenced record MUST be available to the verifier or otherwise recoverable under the deployment profile, unless the verifier is performing only existence checking of the digest binding. 3.4. ext and ext_crit Usage CEP-specific metadata in a JEP event MUST be placed in the JEP "ext" member. If a CEP extension affects validation or interpretation in a way that a verifier must understand, the extension identifier MUST be listed in JEP "ext_crit". Unknown non-critical CEP extensions MAY be ignored. Unknown critical CEP extensions MUST cause verification failure under JEP extension processing rules. 3.5. CEP Structural Validation CEP structural validation checks that: * the associated JEP event is valid under JEP validation; * the JEP "what" digest matches the referenced CEP record, if the record is supplied; * required CEP record fields are present and well-formed; * evidence and anchor references have valid syntax under the applicable profile; and * critical CEP extensions are understood and processed. CEP structural validation does not determine legal validity, governance validity, safety, alignment, truth, or permission. 4. CEP Records 4.1. Evolution-Change Record A CEP Evolution-Change Record has the following minimal shape: { "cep_record": "1", "record_type": "evolution-change-claim", "subject_ref": "sha256:", "change_ref": "sha256:", "evidence_refs": [ "sha256:" ] } Required fields: * cep_record: The CEP record version. For this document, the value is "1". * record_type: For the core record, the value is "evolution-change-claim". * subject_ref: A digest-bound or deployment-profile reference to the system, model, agent, service, deployment, policy, capability, or tool chain that is the subject of the declared change. * change_ref: A digest-bound or deployment-profile reference to the external change record. Optional fields: * evidence_refs: An array of evidence references. * profile_refs: An array of external profile references. * receipt_refs: An array of HJS, JEP, JAC, COE, or CEP receipt references. 4.2. Evidence Descriptor An evidence descriptor describes an evidence reference without assigning legal or governance meaning: { "evidence_ref": "sha256:", "media_type": "application/json", "evidence_role": "deployment-defined", "redaction_profile": "https://example.org/redaction-profile-v1" } The "evidence_role" field is deployment-defined unless an external profile gives it additional meaning. CEP does not assign normative meaning to evidence roles. 4.3. Anchor Reference Descriptor An anchor reference descriptor identifies external anchor material: { "rel": "review-record", "ref": "sha256:", "profile": "https://example.org/anchor-profile-v1" } The "rel" values are deployment-defined unless an external profile gives them additional meaning. CEP does not assign normative meaning to "rel" values. 4.4. Receipt Manifest A CEP receipt manifest describes an exportable bundle: { "cep_manifest": "1", "bundle_id": "urn:uuid:550e8400-e29b-41d4-a716-446655440000", "included_events": [ "sha256:" ], "included_records": [ "sha256:" ], "included_evidence": [ "sha256:" ], "view_profile": "https://example.org/privacy-view-v1" } A receipt manifest is a packaging descriptor. It does not determine entitlement to export, receive, rely on, disclose, or withhold a receipt bundle. 5. Optional Extensions 5.1. Evolution Record Extension Identifier: https://cep.org/evolution-record This extension indicates that a JEP event binds a CEP Evolution-Change Record. Example: { "https://cep.org/evolution-record": { "record_type": "evolution-change-claim", "record_ref": "sha256:" } } 5.2. Anchor References Extension Identifier: https://cep.org/anchor-refs This extension attaches external anchor references to a CEP-related JEP event or CEP record. Example: { "https://cep.org/anchor-refs": { "refs": [ { "rel": "review-record", "ref": "sha256:" }, { "rel": "policy-profile", "ref": "sha256:" } ] } } Anchor references are technical pointers only. CEP does not define whether the referenced material is sufficient, valid, binding, lawful, fair, or authoritative. 5.3. Change Class Extension Identifier: https://cep.org/change-class This extension records a deployment-defined classification of the declared change. Example: { "https://cep.org/change-class": { "taxonomy": "https://example.org/model-change-taxonomy-v1", "class": "capability-emergence", "class_ref": "sha256:" } } CEP does not define a universal taxonomy of AI evolution. Change class values are deployment-defined unless an external profile gives them additional meaning. 5.4. Binding Claim Extension Identifier: https://cep.org/binding-claim This extension records a declared binding between a CEP record and anchor references. Example: { "https://cep.org/binding-claim": { "state": "declared-bound", "profile": "https://example.org/deployment-binding-profile-v1", "anchor_refs": [ { "rel": "human-review-record", "ref": "sha256:" } ] } } A binding claim does not determine whether a change is permitted, prohibited, aligned, safe, lawful, fair, or acceptable. A binding claim MUST NOT be interpreted by CEP as an automatic acceptance or rejection decision. 5.5. Review Reference Extension Identifier: https://cep.org/review-ref This extension references review-related materials, including safety review, human review, organizational review, participant statement, post-event review, dispute record, or external process material. Example: { "https://cep.org/review-ref": { "profile": "https://example.org/review-process-profile-v1", "request_ref": "sha256:", "material_refs": [ "sha256:" ], "result_ref": "sha256:" } } CEP does not determine whether a review is required, who is entitled to request it, whether the review is sufficient, timely, fair, or legally effective, or what consequence follows from the review. 5.6. Rollback or Mitigation Reference Extension Identifier: https://cep.org/mitigation-ref This extension references rollback, mitigation, containment, monitoring, safety evaluation, or follow-up records. Example: { "https://cep.org/mitigation-ref": { "mitigation_refs": [ "sha256:" ], "rollback_ref": "sha256:", "profile": "https://example.org/mitigation-profile-v1" } } CEP does not require rollback or mitigation and does not determine whether any mitigation is adequate. 5.7. Multi-Party Export Extension Identifier: https://cep.org/multiparty-export This extension supports exportable receipt bundles and multiple privacy-preserving views. Example: { "https://cep.org/multiparty-export": { "bundle_ref": "sha256:", "view_profile": "https://example.org/privacy-view-v1", "fragment_refs": [ "sha256:" ] } } CEP does not define which party is entitled to export, receive, disclose, withhold, or rely on a bundle. 5.8. Determinability Report Extension Identifier: https://cep.org/determinability-report This extension references an external report about whether a target fact is determinable from a specified observation and evidence set. Example: { "https://cep.org/determinability-report": { "target_ref": "sha256:", "observation_ref": "sha256:", "report_ref": "sha256:", "profile": "https://example.org/determinability-profile-v1" } } The presence of a determinability report reference does not cause CEP to determine the target fact. Interpretation of the report is outside CEP. 6. Validation 6.1. JEP Validation A verifier MUST first validate the underlying JEP event under the applicable JEP validation mode. CEP does not modify JEP acceptance validation, archival validation, detached JWS processing, canonicalization, event hash calculation, nonce processing, or key resolution. 6.2. HJS Receipt Validation If a CEP record is included in an HJS receipt bundle, the verifier SHOULD validate the HJS receipt manifest and behavior-record digest bindings according to HJS. CEP does not define a separate HJS validation rule. 6.3. CEP Record Validation A verifier validating a CEP Evolution-Change Record SHOULD: 1. verify the associated JEP event; 2. verify that the JEP "what" digest matches the CEP record, if the record is supplied; 3. check that "cep_record", "record_type", "subject_ref", and "change_ref" are present and well-formed; 4. check that evidence references and anchor references have valid syntax under the applicable profile; 5. process critical CEP extensions listed in "ext_crit"; and 6. report structural validity or invalidity. Structural validity is not permission, approval, alignment, safety, compliance, or truth. 6.4. Evidence Reference Validation Evidence reference validation checks that a referenced evidence item matches its digest or reference syntax. It does not determine whether the evidence is relevant, sufficient, admissible, truthful, complete, or legally effective. 6.5. Archival Validation Archival validation verifies historical signatures, digests, event hashes, references, and receipt bundle consistency under the applicable trust profile. Archival validation MUST NOT reject a CEP record solely because the associated JEP event is outside a current freshness window. 7. Security and Privacy Considerations 7.1. Binding Claim Is Not Permission A binding claim is a signed or digest-bound declaration. CEP does not define whether a binding claim permits, prohibits, accepts, rejects, approves, disapproves, authorizes, or validates an AI evolution-change event. Deployments that require operational gates MUST define those gates outside CEP. 7.2. Anchor Reference Is Not Governance Anchor references can point to human-review records, policy profiles, safety reviews, organizational approvals, participant statements, or other materials. CEP does not define who has review authority, whether a referenced review is sufficient, whether a policy profile is valid, or what governance consequence follows from an anchor. 7.3. Evolution Record Is Not Proof of Evolution A valid CEP Evolution-Change Record proves that a record was bound to a JEP event and that referenced digests or signatures can be checked. It does not prove that a model truly evolved, that a capability emerged, that drift occurred, that a reasoning loop formed, or that a system became more or less aligned. 7.4. Partial Observation and Target Determinability Evolution-change questions can be underdetermined by available evidence. A valid CEP record may contain extensive logs, review references, evidence descriptors, or receipt bundles while still not carrying enough target-relevant causal information to settle an external target fact. In partially observed causal systems, different real histories may produce the same observed records while differing on the target fact of interest. CEP deployments therefore need external observation models, evidence policies, safety procedures, and domain-specific review processes when using CEP records for operational, legal, governance, safety, or human-rights purposes. 7.5. Human Privacy and Non-Inference CEP does not require plaintext human identity. Human-related references SHOULD use privacy-preserving references, digest-only references, opaque references, redacted views, or other minimization mechanisms where appropriate. The absence of an anchor reference, review reference, explanation reference, participant-supplied material, or other optional extension MUST NOT be interpreted by the protocol as agreement, waiver, admission, lack of objection, lack of harm, absence of relevant context, absence of external rights, or absence of external process. 7.6. Deployment Policy Boundaries CEP records can support safety, audit, compliance, and human-rights workflows. CEP does not replace safety engineering, human-rights due diligence, access to remedy, organizational governance, legal review, or regulatory analysis. 8. IANA Considerations This document creates no new IANA registry. If a JEP Extensions Registry is established by the JEP specification, the following CEP extension identifiers should be registered in that registry under the registration policy defined by JEP: * https://cep.org/evolution-record * https://cep.org/anchor-refs * https://cep.org/change-class * https://cep.org/binding-claim * https://cep.org/review-ref * https://cep.org/mitigation-ref * https://cep.org/multiparty-export * https://cep.org/determinability-report These identifiers are used as stable extension identifiers and are not required to be dereferenceable. 9. References 9.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, . [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, DOI 10.17487/RFC8259, December 2017, . [RFC8785] Rundgren, A., Jordan, B., and S. Erdtman, "JSON Canonicalization Scheme (JCS)", RFC 8785, DOI 10.17487/RFC8785, June 2020, . [I-D.wang-jep-judgment-event-protocol] Wang, Y., "Judgment Event Protocol (JEP)", Work in Progress, Internet-Draft, draft-wang-jep-judgment-event-protocol-05, April 2026. [I-D.wang-hjs-accountability] Wang, Y., "HJS: An Accountability Layer for AI Agents", Work in Progress, Internet-Draft, draft-wang-hjs-accountability-05, April 2026. 9.2. Informative References [I-D.wang-jac] Wang, Y., "JAC: Judgment Accountability Chain", Work in Progress, Internet-Draft, draft-wang-jac-02, April 2026. [I-D.wang-coe] Wang, Y., "Cognition-Oriented Emergence (COE): A JEP Profile for Shared Observation and State-Claim Evidence", Work in Progress, Internet-Draft, draft-wang-coe-01, 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. Appendix A. Example CEP Records and JEP Events A.1. CEP Evolution-Change Record { "cep_record": "1", "record_type": "evolution-change-claim", "subject_ref": "sha256:", "change_ref": "sha256:", "evidence_refs": [ "sha256:" ], "profile_refs": [ "https://example.org/cep-profile-v1" ] } A.2. JEP Event Binding the CEP Record { "jep": "1", "verb": "J", "who": "did:example:system-123", "when": 1776000000, "what": "sha256:", "nonce": "550e8400-e29b-41d4-a716-446655440000", "aud": "https://platform.example", "ref": null, "ext": { "https://cep.org/evolution-record": { "record_type": "evolution-change-claim", "record_ref": "sha256:" }, "https://cep.org/anchor-refs": { "refs": [ { "rel": "review-record", "ref": "sha256:" } ] }, "https://cep.org/binding-claim": { "state": "declared-bound", "profile": "https://example.org/deployment-binding-profile-v1" } }, "sig": "" } The example demonstrates digest binding and optional anchor and binding-claim extensions. It does not indicate that the change is permitted, aligned, lawful, safe, or accepted. A.3. Multi-Party Export Manifest { "cep_manifest": "1", "bundle_id": "urn:uuid:660e8400-e29b-41d4-a716-446655440001", "included_events": [ "sha256:" ], "included_records": [ "sha256:" ], "included_evidence": [ "sha256:" ], "view_profile": "https://example.org/privacy-view-v1" } Appendix B. Changes from draft-wang-cep-00 This revision changes the protocol positioning and structure: * Recast CEP as a JEP/HJS-compatible evidence-binding profile rather than a human-AI co-evolution control protocol. * Removed mandatory core fields HumanAnchor, ShiftClass, and BoundState. * Replaced HumanAnchor with optional external anchor references. * Replaced fixed ShiftClass with optional deployment-defined change classification. * Replaced BoundState as a permission/rejection switch with optional binding claims that have no protocol-level acceptance or rejection effect. * Removed use of JEP nonce as the primary anchor identifier; stable references should use JEP event hashes or digest-bound records. * Removed protocol-level rejection of evolution events. * Added minimal core plus optional extensions. * Added multi-party exportable receipt bundles. * Added non-inference language for missing optional extensions or participant-supplied materials. * Added partial-observation and target-determinability limits as an informative security boundary. Author's Address Yuqiang Wang HJS Foundation Ltd. Email: signal@humanjudgment.org URI: https://humanjudgment.org GitHub: https://github.com/hjs-spec