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

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 defines profile selection and composition rules. JEP Conformance defines validation-result and test-harness conventions. JEP Receipt Profile MAY package CEP records. JAC MAY express declared dependencies among JEP events associated with CEP records. COE MAY provide observation or shared-state evidence referenced by a CEP record. Where this document conflicts with JEP-Core, JEP-Core controls.

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 when, and only when, they appear in all capitals.

Scope and Terminology

CEP-2 Defines CEP-2 defines:

one profile identifier;
one critical CEP record-binding extension;
one Evolution-Change Record;
one Subject structure;
one Change Reference structure;
one Evidence Reference structure;
one Anchor Reference structure;
independent CEP validation checks;
explicit non-inference boundaries.

CEP-2 Does Not Define CEP-2 does not define:

new JEP verbs;
an independent event, signature, or hash format;
a replacement for Event Identity or Event Hash;
a universal taxonomy of AI evolution or change;
baseline before / after state-transition semantics;
model safety or alignment;
capability-emergence truth;
autonomous-evolution detection;
authorization or delegation validity;
approval or permission;
review authority or review sufficiency;
rollback or mitigation policy;
causal-chain semantics;
shared-observation semantics;
complete-history semantics;
consensus or governance outcomes;
human rights, appeal rights, or explanation rights;
legal effect or regulatory compliance.

Evolution-Change Record A digest-addressed record declaring that a Subject is associated with a described Change Reference and optional evidence or anchors. It is a record of a declared change claim. It is not proof that the change occurred.

Subject The logical system, model, model family, agent, service, deployment, policy, tool chain, capability object, or other deployment-defined entity associated with the declared change.

Change Reference A digest-first reference to a change record, update manifest, diff, training record, configuration record, evaluation record, mitigation record, rollback record, or other object describing the declared change.

Evidence Reference A digest-first reference to evidence associated with the Evolution-Change Record. CEP does not determine whether referenced evidence is relevant, sufficient, truthful, complete, admissible, or authoritative.

Anchor Reference A typed reference associating an Evolution-Change Record with an external JEP event or digest-addressed record. An anchor is a technical association. It is not an approval, permission, governance decision, or legal conclusion.

Profile and Extension Identifiers

CEP-2 Profile Identifier The CEP-2 profile identifier is: https://humanjudgment.org/jep/profiles/cep/2 The label CEP-2 MAY be used in documentation and user interfaces. The identifier is a publisher-controlled HTTPS URI. Dereferencing it is not required for validation.

CEP Record-Binding Extension Identifier The critical CEP record-binding extension identifier is: https://humanjudgment.org/jep/extensions/cep-record-binding/2 A JEP event claiming CEP-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 CEP-2 validation.

Version Boundary CEP-2 is not wire-compatible with CEP-Core-1 from draft-wang-cep-01. CEP-Core-1 commonly placed an Evolution-Change Record digest in JEP what, used pre-JEP-0.7 nonce and reference assumptions, and defined HJS-based receipt integration. CEP-2 moves CEP record binding into one critical JEP extension, uses JEP Event Identity for logical event references, treats Event Hash only as an exact signed-artifact pin, and uses JEP Receipt Profile for optional portable receipt packaging. Historical CEP-Core-1 records and events MUST NOT be silently rewritten as CEP-2 records or events.

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.

CEP Record-Binding Extension

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/cep/2. record_type MUST equal evolution-change. 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 CEP-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 CEP-2 event binds exactly one primary Evolution-Change Record through this extension.

Extension Example { "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" ] } The example digest is illustrative.

Binding-Event Circularity An Evolution-Change 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 a back-reference.

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.

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.

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.

Anchor Reference

Anchor Shape An Anchor Reference MUST be a JSON object containing:

relation
reference

relation MUST be a non-empty string. For local deployment semantics, relation MAY be deployment-defined. For cross-deployment interoperable relation semantics, relation MUST be an absolute URI whose semantics are defined by an explicitly selected profile or published specification. Two different relation identifiers MUST NOT be treated as equivalent merely because their human-readable labels are similar. reference MUST be one of the reference forms defined below.

JEP Event Anchor A JEP event anchor MUST contain:

kind equal to jep-event
event_identity

event_identity MUST contain non-empty string members who and id. A JEP event anchor MAY also contain:

event_hash
uri

event_hash, when present, pins one exact signed JEP artifact. The logical event reference is Event Identity, not Event Hash. uri, when present, is a retrieval hint only.

Digest Record Anchor A digest record anchor MUST contain:

kind equal to digest-record
digest

digest MUST be an algorithm-tagged digest string. A digest record anchor MAY additionally contain:

profile
record_type
media_type
uri

When present, profile and uri MUST be absolute URIs and record_type and media_type MUST be non-empty strings. An anchor to another profile does not import that profile's validity or policy conclusions into CEP.

Anchor Non-Inference An Anchor Reference declares association only. The presence of an anchor MUST NOT be interpreted by CEP as:

approval;
authorization;
consent;
review sufficiency;
policy satisfaction;
safety;
alignment;
legal validity;
governance acceptance.

A companion profile MAY define a stronger relation, but that conclusion belongs to that profile and MUST be reported separately.

Evolution-Change Record

Required Shape A CEP-2 Evolution-Change Record MUST be a JSON object containing:

cep_record
record_type
subject
change

cep_record MUST equal "2". record_type MUST equal "evolution-change". subject MUST be a Subject. change MUST be a Change Reference.

Optional Members An Evolution-Change Record MAY additionally contain:

evidence
anchors
declared_at
context

evidence, when present, MUST be an array of zero or more Evidence References. anchors, when present, MUST be an array of zero or more Anchor References. declared_at, when present, MUST be a non-negative integer representing declared Unix seconds. It is not trusted time and is not proof that the change occurred at that time. context, when present, MUST be a JSON object whose semantics are defined by the deployment or an explicitly selected companion profile. No other top-level members are defined by the CEP-2 baseline.

Record Digest The Evolution-Change Record Digest uses JCS and is: sha256(UTF8(JCS(evolution_change_record))) CEP-2 producers and verifiers MUST support sha256 for Evolution-Change Record digests. A companion profile MAY permit additional digest algorithms.

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.

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.

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.

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.

Validation

Layer Separation A CEP validation result separates:

underlying JEP validation status;
CEP checks;
CEP overall status;
external profile results, when evaluated.

CEP MUST NOT overwrite the JEP validation result or merge external-profile results into CEP validity.

Baseline Validation Mode A CEP-2 verifier MUST support JEP archival validation mode. If no JEP validation mode is explicitly requested, CEP validation MUST use archival mode. Archival CEP validation MUST NOT consume JEP acceptance state. A deployment MAY explicitly request another JEP validation mode when needed.

CEP Checks The initial CEP-2 check identifiers are:

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

Check statuses use the JEP conformance vocabulary:

pass
fail
not_checked
not_applicable
unsupported
indeterminate

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

Required Checks For every CEP-2 event, the required checks are:

profile-binding
record-binding
record-structure
subject-reference
change-reference

evidence-reference is required when evidence is present. anchor-reference is required when anchors is present. external-integrity is required only for external evidence or anchors that the requested validation context requires to be resolved and checked. semantic-profile is required only when the requested validation context requires semantic interpretation of subject.profile, change.change_profile, or another external profile identifier. If semantic interpretation is required but the selected profile is unsupported or cannot be evaluated, semantic-profile MUST NOT be reported as pass.

CEP Overall Status The CEP overall status is one of:

valid
invalid
indeterminate

For the requested CEP validation context:

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

valid means structurally and cryptographically valid under the selected checks. It does not mean the declared change occurred or was acceptable.

Validation Procedure A CEP verifier SHOULD:

validate the JEP event under the requested JEP mode and selected profiles;
process the critical CEP record-binding extension;
verify the CEP profile identifier;
obtain the bound Evolution-Change Record;
canonicalize and hash the record;
compare the recomputed digest with record_digest;
validate the record structure;
validate Subject and Change Reference structure;
validate Evidence References and Anchor References when present;
resolve and verify required external digests or exact-artifact pins;
evaluate semantic profiles only when required by the requested context;
return JEP status, CEP checks, CEP overall status, and external-profile results separately.

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.

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.

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.

Conformance

CEP-2 Producer A conforming CEP-2 Producer MUST:

produce a JEP event conforming to applicable JEP Producer requirements;
preserve the selected JEP verb semantics;
include the critical CEP record-binding extension;
list the extension in ext_crit;
use the CEP-2 profile identifier;
bind exactly one Evolution-Change Record by digest;
produce that record according to this specification;
use Event Identity, not Event Hash, for logical JEP event anchors;
avoid circular binding through the binding event's Event Hash.

CEP-2 Verifier A conforming CEP-2 Verifier MUST:

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

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.

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.

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.

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.

Examples

Evolution-Change Record { "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 } The review-record relation in this example is local and deployment-defined; it is not a cross-deployment interoperable relation identifier and does not imply approval.

JEP Event Carrying a CEP Binding { "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": "..." }

JEP Event Anchor with Artifact Pin { "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" } } The Event Identity identifies the logical event. The Event Hash pins one exact signed artifact.

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.