Co-Evolve Binding Profile (CEP): A JEP Profile for Evolution-Change Evidence Binding

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

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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

Table of Contents

1. Introduction

AI systems, models, autonomous agents, tool-using services, policies, and deployments can change over time. A change may involve a model update, fine-tuning step, policy update, tool-chain change, capability claim, configuration change, observed drift, mitigation step, rollback, or another deployment-defined transition.¶

Operators, counterparties, auditors, researchers, and downstream systems may need a portable record answering:¶

Which subject was declared to have changed,
which change record was bound to that declaration,
which evidence and anchors were associated with it,
and can those bindings be independently revalidated?

CEP addresses that narrow interoperability problem.¶

The term "evolution-change" in CEP is neutral. It means a declared transition or change associated with a subject. It does not imply improvement, progress, adaptation, autonomous self-modification, capability growth, or biological evolution.¶

JEP Profiles [JEP-PROFILES] defines profile selection and composition rules. JEP Conformance [JEP-CONFORMANCE] defines validation-result and test-harness conventions. JEP Receipt Profile [JEP-RECEIPT] MAY package CEP records. JAC [JAC] MAY express declared dependencies among JEP events associated with CEP records. COE [COE] MAY provide observation or shared-state evidence referenced by a CEP record.¶

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

4. Profile and Extension Identifiers

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

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

5. Relationship to JEP-Core

CEP-2 relies on JEP-Core for:¶

• J, D, T, and V semantics;¶
• required Core event members;¶
• Event Identity (who,id);¶
• Event Hash;¶
• the JEP Signing Payload;¶
• signature validation;¶
• ref;¶
• ext and ext_crit;¶
• independent validation checks;¶
• validation modes;¶
• idempotent acceptance.¶

CEP-2 MUST NOT redefine those semantics.¶

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

In particular:¶

• a D event MUST retain what.delegatee and what.scope;¶
• a T event MUST retain what.termination_scope and identify its target through JEP ref;¶
• a V event MUST retain what.verification_scope, what.result, and JEP ref.¶

CEP metadata MUST NOT replace those fields.¶

6. CEP Record-Binding Extension

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

7. Subject

A Subject MUST be a JSON object containing:¶

• type¶
• id¶

type and id MUST be non-empty strings.¶

A Subject MAY additionally contain:¶

• profile¶
• version_ref¶

profile, when present, MUST be an absolute URI identifying an external subject-identity or semantic profile.¶

If interoperable Subject identity comparison across deployments is required, the producer MUST include profile.¶

A verifier that does not understand the selected profile MAY validate the Subject structure and the enclosing CEP record, but MUST NOT claim that two Subject values identify the same logical subject across deployments.¶

version_ref, when present, MUST be an Evidence Reference.¶

id identifies the logical subject under the interpretation selected by the deployment or profile. It MUST NOT be interpreted as a JEP Event Identity unless a profile explicitly defines that representation.¶

The Subject structure separates logical subject identity from any particular model file, deployment artifact, configuration artifact, or JEP event.¶

8. Change Reference

A Change Reference MUST be a JSON object containing:¶

• digest¶

digest MUST be an algorithm-tagged digest string identifying the change description or change artifact.¶

A Change Reference MAY additionally contain:¶

• change_profile¶
• kind¶
• media_type¶
• uri¶

When present:¶

• change_profile MUST be an absolute URI;¶
• kind and media_type MUST be non-empty strings;¶
• uri MUST be an absolute URI.¶

change_profile identifies the schema, vocabulary, semantic profile, or equivalent interpretation contract for the change payload.¶

If interoperable semantic interpretation of the change payload is required outside the originating deployment, the producer MUST include change_profile.¶

A verifier that does not understand change_profile MAY still validate the CEP record binding and digest, but MUST NOT claim semantic interpretation of the change payload under that profile.¶

CEP-2 does not define before state, after state, state-transition equivalence, or state-difference semantics. A change_profile or companion profile MAY define such semantics and any rules for comparing, ordering, or validating them.¶

9. Evidence Reference

An Evidence Reference MUST be a JSON object containing:¶

• digest¶

digest MUST be an algorithm-tagged digest string.¶

An Evidence Reference MAY additionally contain:¶

• kind¶
• profile¶
• record_type¶
• media_type¶
• uri¶
• redaction¶

When present:¶

• kind, record_type, and media_type MUST be non-empty strings;¶
• profile and uri MUST be absolute URIs;¶
• redaction SHOULD be one of none, partial, digest-only, or withheld.¶

The digest is the integrity identity of the evidence object.¶

URI retrieval success MUST NOT be treated as evidence-integrity success.¶

A profile value identifies external semantics. The presence of a profile identifier does not make that profile's validation result part of CEP validity. External profile validity MUST be evaluated separately.¶

10. Anchor Reference

11. Evolution-Change Record

sha256(UTF8(JCS(evolution_change_record)))

12. JEP Verb Usage

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

A J event MAY carry a claim concerning issuance, adoption, observation, or interpretation of an Evolution-Change Record while the CEP binding remains in the critical extension.¶

A D event MAY carry a CEP binding, but delegation meaning remains defined by JEP-Core and any applicable delegation or mandate profile.¶

A T event MAY terminate future reliance on a referenced JEP event within its declared termination scope. CEP does not define automatic rollback, retraction, or mitigation merely because a CEP record is associated with that event.¶

A V event MAY record an evaluation of a CEP record, evidence object, anchor, or external change profile under a declared verification scope.¶

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

13. Interaction with JEP Receipt Profile

JEP Receipt Profile is optional for CEP-2.¶

A CEP Evolution-Change Record MAY appear as an evidence object in a JEP Receipt Profile bundle.¶

A receipt bundle MAY include:¶

• a JEP event carrying the CEP binding extension;¶
• the bound CEP record;¶
• evidence or anchor records referenced by the CEP record;¶
• a receipt manifest referring to those artifacts.¶

Receipt Profile validity and CEP validity MUST be reported separately.¶

CEP-2 does not define a second receipt-manifest format.¶

14. Interaction with JAC

JAC is optional for CEP-2.¶

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

A CEP Evidence Reference or Anchor Reference does not automatically create a JAC dependency edge.¶

A JAC edge does not automatically create a CEP evidence or anchor relation.¶

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

JAC validity does not establish that a CEP change occurred or that its evidence is sufficient.¶

15. Interaction with COE

COE is optional for CEP-2.¶

A CEP Evidence Reference or Digest Record Anchor MAY reference a COE Observation Record or Shared-State Claim Record by digest and profile.¶

A CEP verifier MUST NOT report COE validity unless the referenced COE object was separately validated under the applicable COE profile.¶

COE validity does not establish that the CEP change occurred, caused an observed condition, or satisfies a policy.¶

16. Validation

17. Verification Events

A JEP V event MAY record a CEP evaluation.¶

The V event MUST satisfy JEP-Core V requirements.¶

CEP-2 defines the following provisional profile-specific verification scopes:¶

• https://humanjudgment.org/jep/profiles/cep/2#record-binding¶
• https://humanjudgment.org/jep/profiles/cep/2#change-reference¶
• https://humanjudgment.org/jep/profiles/cep/2#evidence-integrity¶
• https://humanjudgment.org/jep/profiles/cep/2#anchor-integrity¶
• https://humanjudgment.org/jep/profiles/cep/2#semantic-profile¶

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 CEP per-check status.¶

A V event MUST NOT imply permission, approval, safety, alignment, actual change, or policy satisfaction beyond its declared verification scope.¶

18. Partial Observation and Change Determinability

CEP-2 uses an open-world evidence model.¶

Absence of an Evolution-Change Record MUST NOT be interpreted as proof that no change occurred.¶

Absence of conflicting evidence MUST NOT be interpreted as proof that no conflicting evidence exists.¶

A collection of CEP records MUST NOT be presented as a complete history of a subject unless an explicitly selected external profile defines a complete-history assumption and its requirements were satisfied.¶

CEP-2 does not define whether an evolution or change fact is uniquely or zero-error determinable from available evidence.¶

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

19. Optional Companion Semantics

CEP-01 defined or described extension families for evolution records, anchors, change classification, binding claims, review references, rollback or mitigation references, multi-party export, and determinability reports.¶

CEP-2 removes those extension families from the narrow waist.¶

A companion profile MAY define:¶

• change taxonomies;¶
• change semantic profiles;¶
• review or approval relations;¶
• binding claims;¶
• rollback or mitigation references;¶
• deployment gates;¶
• safety or alignment evidence profiles;¶
• multi-party export views;¶
• determinability reports;¶
• subject identity profiles;¶
• time or transparency evidence;¶
• evidence-access policy.¶

Such profiles MUST NOT redefine JEP-Core semantics or present their conclusions as intrinsic CEP-Core facts.¶

20. Conformance

21. Security Considerations

A valid CEP result does not prove that a declared change occurred.¶

Implementations MUST consider:¶

• actor/signer/subject confusion;¶
• false but correctly signed change claims;¶
• false but correctly hashed change records;¶
• Event Identity/Event Hash confusion;¶
• subject identity ambiguity;¶
• record substitution;¶
• anchor substitution;¶
• URI substitution;¶
• circular binding;¶
• omitted or selectively exported evidence;¶
• misleading change classifications;¶
• unsupported semantic profiles;¶
• unsupported critical extensions;¶
• false completeness assumptions;¶
• semantic inflation from "declared change" to "actual evolution";¶
• semantic inflation from anchor association to approval or permission.¶

A verifier MUST compare the recomputed Evolution-Change Record digest with the digest inside the signed critical CEP extension.¶

A verifier MUST NOT infer actor binding, actual change, permission, approval, authorization, causality, safety, alignment, completeness, or policy compliance from successful CEP structural validation.¶

22. Privacy Considerations

CEP records can expose:¶

• subject identifiers;¶
• model or deployment version relationships;¶
• change timing;¶
• internal update or rollback structure;¶
• evidence and review relationships;¶
• organizational processes;¶
• capability or configuration changes;¶
• safety or policy review references.¶

Implementations SHOULD minimize plaintext personal, proprietary, security- sensitive, or operationally sensitive data.¶

Evidence and anchors SHOULD be referenced by digest when embedding their content is unnecessary.¶

Digest references can still enable correlation and dictionary attacks.¶

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

CEP does not determine access rights, consent, lawful basis, retention periods, trade-secret rights, disclosure duties, or entitlement to export evidence.¶

23. Non-Inference Boundary

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

• that an AI, model, agent, policy, tool chain, or deployment actually changed;¶
• that a capability emerged or disappeared;¶
• that drift occurred;¶
• that the subject improved, degraded, evolved, or self-modified;¶
• that a change was caused by a referenced event or evidence item;¶
• that a human or organization approved the change;¶
• that a review was sufficient;¶
• that a change was authorized;¶
• that a rollback or mitigation is required;¶
• that a change is safe, aligned, fair, or lawful;¶
• that all relevant evidence was disclosed;¶
• that a change is uniquely determinable;¶
• that a policy or governance outcome should follow;¶
• that any legal or regulatory requirement was satisfied.¶

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

24. IANA Considerations

This document requests no IANA actions.¶

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

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

25. Examples

{
  "cep_record": "2",
  "record_type": "evolution-change",
  "subject": {
    "type": "model-deployment",
    "id": "urn:example:deployment:alpha",
    "profile": "https://example.org/subjects/model-deployment/v1"
  },
  "change": {
    "digest": "sha256:1111111111111111111111111111111111111111111111111111111111111111",
    "change_profile": "https://example.org/changes/model-update/v1",
    "kind": "model-update-manifest",
    "media_type": "application/json"
  },
  "evidence": [
    {
      "digest": "sha256:2222222222222222222222222222222222222222222222222222222222222222",
      "kind": "evaluation-report",
      "media_type": "application/json"
    }
  ],
  "anchors": [
    {
      "relation": "review-record",
      "reference": {
        "kind": "digest-record",
        "digest": "sha256:3333333333333333333333333333333333333333333333333333333333333333",
        "profile": "https://example.org/review/v1",
        "media_type": "application/json"
      }
    }
  ],
  "declared_at": 1790424000
}

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

{
  "relation": "prior-change-event",
  "reference": {
    "kind": "jep-event",
    "event_identity": {
      "who": "did:example:deployment-service",
      "id": "urn:uuid:018f4f8d-0000-7000-8000-000000000111"
    },
    "event_hash": "sha256:bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb"
  }
}

26. Changes from -01

Major changes from draft-wang-cep-01:¶

• aligned CEP with JEP-Core 0.7, JEP Profiles-01, and JEP Conformance-01;¶
• introduced CEP-2 as an incompatible profile revision;¶
• removed the HJS technical dependency and aligned optional portable receipt packaging with JEP Receipt Profile;¶
• moved Evolution-Change Record binding from JEP what to one critical CEP record-binding extension so D, T, and V retain their Core what semantics;¶
• removed pre-JEP-0.7 nonce assumptions;¶
• changed logical JEP event references from Event Hash to Event Identity;¶
• retained Event Hash only as an optional exact signed-artifact pin;¶
• narrowed CEP to one Evolution-Change Record plus Subject, Change Reference, Evidence Reference, and Anchor Reference structures;¶
• replaced raw subject and change reference strings with explicit typed structures;¶
• added change_profile as a semantic-profile hook for cross-deployment interpretation without defining a universal change taxonomy;¶
• separated logical subject identity from model or deployment artifact identity;¶
• required a Subject profile when cross-deployment identity comparison is required and prohibited unsupported verifiers from claiming identity equivalence;¶
• required absolute-URI Anchor relation identifiers for cross-deployment interoperable relation semantics while retaining local deployment-defined relations;¶
• clarified that before / after state-transition semantics are outside the CEP-2 baseline and belong to change_profile or companion profiles;¶
• removed the CEP-specific receipt manifest in favor of JEP Receipt Profile;¶
• removed change-class, binding-claim, review, rollback/mitigation, multi-party-export, and determinability-report extension families from the CEP narrow waist;¶
• moved those semantics to companion profiles;¶
• aligned optional dependency-graph semantics with JAC-2;¶
• aligned optional observation and state evidence with COE-2;¶
• defined a binding-event circularity rule;¶
• made JEP archival the required and default repeatable CEP validation mode when no other JEP validation mode is explicitly requested;¶
• replaced structural-validity-only output with independent CEP checks and valid / invalid / indeterminate status;¶
• added explicit external-profile result separation;¶
• clarified the neutral meaning of "evolution-change";¶
• strengthened open-world, privacy, security, and non-inference boundaries;¶
• changed identifiers to publisher-controlled HTTPS URIs;¶
• changed IANA language to request no action.¶

Author's Address