Co-Evolve Binding Profile (CEP) A JEP/HJS Profile for AI Evolution-Change Evidence Binding
draft-wang-cep-01

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:<lowercase-hex-digest>".

   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:<digest-of-system-or-model-reference>",
     "change_ref": "sha256:<digest-of-change-record>",
     "evidence_refs": [
       "sha256:<digest-of-evidence-record>"
     ]
   }

   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:<digest-of-evidence>",
     "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:<digest-of-review-record>",
     "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:<jep-event-hash>"
     ],
     "included_records": [
       "sha256:<cep-record-digest>"
     ],
     "included_evidence": [
       "sha256:<evidence-digest>"
     ],
     "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:<digest-of-cep-record>"
     }
   }

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:<digest-of-review-record>"
         },
         {
           "rel": "policy-profile",
           "ref": "sha256:<digest-of-policy-profile>"
         }
       ]
     }
   }

   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:<digest-of-classification-record>"
     }
   }

   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:<digest-of-review-record>"
         }
       ]
     }
   }

   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:<digest-of-review-request>",
       "material_refs": [
         "sha256:<digest-of-review-material>"
       ],
       "result_ref": "sha256:<digest-of-review-result>"
     }
   }

   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:<digest-of-mitigation-record>"
       ],
       "rollback_ref": "sha256:<digest-of-rollback-record>",
       "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:<digest-of-receipt-manifest>",
       "view_profile": "https://example.org/privacy-view-v1",
       "fragment_refs": [
         "sha256:<digest-of-signed-fragment>"
       ]
     }
   }

   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:<digest-of-target-definition>",
       "observation_ref": "sha256:<digest-of-observation-model>",
       "report_ref": "sha256:<digest-of-determinability-report>",
       "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,
              <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>.

   [RFC8259]  Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
              Interchange Format", STD 90, RFC 8259,
              DOI 10.17487/RFC8259, December 2017,
              <https://www.rfc-editor.org/info/rfc8259>.

   [RFC8785]  Rundgren, A., Jordan, B., and S. Erdtman, "JSON
              Canonicalization Scheme (JCS)", RFC 8785,
              DOI 10.17487/RFC8785, June 2020,
              <https://www.rfc-editor.org/info/rfc8785>.

   [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:<subject-digest>",
     "change_ref": "sha256:<change-digest>",
     "evidence_refs": [
       "sha256:<evidence-digest>"
     ],
     "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:<cep-record-digest>",
     "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:<cep-record-digest>"
       },
       "https://cep.org/anchor-refs": {
         "refs": [
           {
             "rel": "review-record",
             "ref": "sha256:<review-record-digest>"
           }
         ]
       },
       "https://cep.org/binding-claim": {
         "state": "declared-bound",
         "profile": "https://example.org/deployment-binding-profile-v1"
       }
     },
     "sig": "<detached-jws>"
   }

   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:<event-digest>"
     ],
     "included_records": [
       "sha256:<record-digest>"
     ],
     "included_evidence": [
       "sha256:<evidence-digest>"
     ],
     "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