Co-Evolve Binding Profile (CEP): A JEP Profile for Evolution-Change Evidence Binding
draft-wang-cep-02
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Author | yuqiang wang | ||
| Last updated | 2026-09-26 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-wang-cep-02
Network Working Group Y. Wang
Internet-Draft 26 September 2026
Intended status: Experimental
Expires: 30 March 2027
Co-Evolve Binding Profile (CEP): A JEP Profile for Evolution-Change
Evidence Binding
draft-wang-cep-02
Abstract
This document defines CEP-2, an optional profile of the Judgment
Event Protocol (JEP) [JEP] for binding declared AI, model, agent,
policy, tool-chain, or deployment changes to independently verifiable
evidence and external anchor references.
CEP-2 defines one critical JEP record-binding extension, one minimal
Evolution-Change Record, Subject and Change semantics, digest-first
evidence references, typed external anchor references, and
independent CEP validation checks. JEP remains authoritative for
event verbs, Event Identity, Event Hash, signatures, references,
extension processing, validation modes, and acceptance semantics.
CEP-2 records declared change evidence. It does not determine
whether a change actually occurred, whether a system improved or
degraded, whether a capability emerged, whether a change was
authorized, safe, aligned, fair, lawful, approved, reversible, or
acceptable, or whether any governance or regulatory process was
satisfied.
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.
Wang Expires 30 March 2027 [Page 1]
Internet-Draft CEP September 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 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 . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4
3. Scope and Terminology . . . . . . . . . . . . . . . . . . . . 4
3.1. CEP-2 Defines . . . . . . . . . . . . . . . . . . . . . . 4
3.2. CEP-2 Does Not Define . . . . . . . . . . . . . . . . . . 5
3.3. Evolution-Change Record . . . . . . . . . . . . . . . . . 5
3.4. Subject . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.5. Change Reference . . . . . . . . . . . . . . . . . . . . 6
3.6. Evidence Reference . . . . . . . . . . . . . . . . . . . 6
3.7. Anchor Reference . . . . . . . . . . . . . . . . . . . . 6
4. Profile and Extension Identifiers . . . . . . . . . . . . . . 6
4.1. CEP-2 Profile Identifier . . . . . . . . . . . . . . . . 6
4.2. CEP Record-Binding Extension Identifier . . . . . . . . . 6
4.3. Version Boundary . . . . . . . . . . . . . . . . . . . . 7
5. Relationship to JEP-Core . . . . . . . . . . . . . . . . . . 7
6. CEP Record-Binding Extension . . . . . . . . . . . . . . . . 8
6.1. Extension Value . . . . . . . . . . . . . . . . . . . . . 8
6.2. Extension Example . . . . . . . . . . . . . . . . . . . . 9
6.3. Binding-Event Circularity . . . . . . . . . . . . . . . . 9
7. Subject . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
8. Change Reference . . . . . . . . . . . . . . . . . . . . . . 10
9. Evidence Reference . . . . . . . . . . . . . . . . . . . . . 11
10. Anchor Reference . . . . . . . . . . . . . . . . . . . . . . 12
10.1. Anchor Shape . . . . . . . . . . . . . . . . . . . . . . 12
10.2. JEP Event Anchor . . . . . . . . . . . . . . . . . . . . 12
10.3. Digest Record Anchor . . . . . . . . . . . . . . . . . . 13
10.4. Anchor Non-Inference . . . . . . . . . . . . . . . . . . 13
11. Evolution-Change Record . . . . . . . . . . . . . . . . . . . 14
11.1. Required Shape . . . . . . . . . . . . . . . . . . . . . 14
11.2. Optional Members . . . . . . . . . . . . . . . . . . . . 14
11.3. Record Digest . . . . . . . . . . . . . . . . . . . . . 15
12. JEP Verb Usage . . . . . . . . . . . . . . . . . . . . . . . 15
Wang Expires 30 March 2027 [Page 2]
Internet-Draft CEP September 2026
13. Interaction with JEP Receipt Profile . . . . . . . . . . . . 15
14. Interaction with JAC . . . . . . . . . . . . . . . . . . . . 16
15. Interaction with COE . . . . . . . . . . . . . . . . . . . . 16
16. Validation . . . . . . . . . . . . . . . . . . . . . . . . . 16
16.1. Layer Separation . . . . . . . . . . . . . . . . . . . . 17
16.2. Baseline Validation Mode . . . . . . . . . . . . . . . . 17
16.3. CEP Checks . . . . . . . . . . . . . . . . . . . . . . . 17
16.4. Required Checks . . . . . . . . . . . . . . . . . . . . 18
16.5. CEP Overall Status . . . . . . . . . . . . . . . . . . . 19
16.6. Validation Procedure . . . . . . . . . . . . . . . . . . 19
17. Verification Events . . . . . . . . . . . . . . . . . . . . . 20
18. Partial Observation and Change Determinability . . . . . . . 20
19. Optional Companion Semantics . . . . . . . . . . . . . . . . 21
20. Conformance . . . . . . . . . . . . . . . . . . . . . . . . . 22
20.1. CEP-2 Producer . . . . . . . . . . . . . . . . . . . . . 22
20.2. CEP-2 Verifier . . . . . . . . . . . . . . . . . . . . . 22
21. Security Considerations . . . . . . . . . . . . . . . . . . . 23
22. Privacy Considerations . . . . . . . . . . . . . . . . . . . 24
23. Non-Inference Boundary . . . . . . . . . . . . . . . . . . . 24
24. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
25. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 25
25.1. Evolution-Change Record . . . . . . . . . . . . . . . . 25
25.2. JEP Event Carrying a CEP Binding . . . . . . . . . . . . 26
25.3. JEP Event Anchor with Artifact Pin . . . . . . . . . . . 27
26. Changes from -01 . . . . . . . . . . . . . . . . . . . . . . 27
27. References . . . . . . . . . . . . . . . . . . . . . . . . . 29
27.1. Normative References . . . . . . . . . . . . . . . . . . 29
27.2. Informative References . . . . . . . . . . . . . . . . . 30
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 30
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.
Wang Expires 30 March 2027 [Page 3]
Internet-Draft CEP September 2026
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
3.1. 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.
Wang Expires 30 March 2027 [Page 4]
Internet-Draft CEP September 2026
3.2. 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.
3.3. 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.
Wang Expires 30 March 2027 [Page 5]
Internet-Draft CEP September 2026
3.4. 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.
3.5. 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.
3.6. 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.
3.7. 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.
4. Profile and Extension Identifiers
4.1. 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.
4.2. CEP Record-Binding Extension Identifier
The critical CEP record-binding extension identifier is:
https://humanjudgment.org/jep/extensions/cep-record-binding/2
Wang Expires 30 March 2027 [Page 6]
Internet-Draft CEP September 2026
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.
4.3. 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.
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.
Wang Expires 30 March 2027 [Page 7]
Internet-Draft CEP September 2026
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
6.1. Extension Value
The extension value MUST be a JSON object containing:
* profile
* record_type
* record_digest
* media_type
profile MUST equal https://humanjudgment.org/jep/profiles/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.
Wang Expires 30 March 2027 [Page 8]
Internet-Draft CEP September 2026
6.2. 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.
6.3. 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.
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.
Wang Expires 30 March 2027 [Page 9]
Internet-Draft CEP September 2026
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.
Wang Expires 30 March 2027 [Page 10]
Internet-Draft CEP September 2026
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.
Wang Expires 30 March 2027 [Page 11]
Internet-Draft CEP September 2026
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
10.1. 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.
10.2. 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.
Wang Expires 30 March 2027 [Page 12]
Internet-Draft CEP September 2026
10.3. 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.
10.4. 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;
Wang Expires 30 March 2027 [Page 13]
Internet-Draft CEP September 2026
* governance acceptance.
A companion profile MAY define a stronger relation, but that
conclusion belongs to that profile and MUST be reported separately.
11. Evolution-Change Record
11.1. 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.
11.2. 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.
Wang Expires 30 March 2027 [Page 14]
Internet-Draft CEP September 2026
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.
11.3. Record Digest
The Evolution-Change Record Digest uses JCS [RFC8785] 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.
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:
Wang Expires 30 March 2027 [Page 15]
Internet-Draft CEP September 2026
* 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
Wang Expires 30 March 2027 [Page 16]
Internet-Draft CEP September 2026
16.1. 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.
16.2. 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.
16.3. 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
Wang Expires 30 March 2027 [Page 17]
Internet-Draft CEP September 2026
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.
16.4. 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.
Wang Expires 30 March 2027 [Page 18]
Internet-Draft CEP September 2026
16.5. 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.
16.6. 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;
Wang Expires 30 March 2027 [Page 19]
Internet-Draft CEP September 2026
* 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.
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.
Wang Expires 30 March 2027 [Page 20]
Internet-Draft CEP September 2026
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.
Wang Expires 30 March 2027 [Page 21]
Internet-Draft CEP September 2026
Such profiles MUST NOT redefine JEP-Core semantics or present their
conclusions as intrinsic CEP-Core facts.
20. Conformance
20.1. 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.
20.2. 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;
Wang Expires 30 March 2027 [Page 22]
Internet-Draft CEP September 2026
* preserve external-profile validation results separately;
* return indeterminate rather than success when a required check
cannot be completed.
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.
Wang Expires 30 March 2027 [Page 23]
Internet-Draft CEP September 2026
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;
Wang Expires 30 March 2027 [Page 24]
Internet-Draft CEP September 2026
* 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
25.1. Evolution-Change Record
Wang Expires 30 March 2027 [Page 25]
Internet-Draft CEP September 2026
{
"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.
25.2. JEP Event Carrying a CEP Binding
Wang Expires 30 March 2027 [Page 26]
Internet-Draft CEP September 2026
{
"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": "..."
}
25.3. 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.
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;
Wang Expires 30 March 2027 [Page 27]
Internet-Draft CEP September 2026
* 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;
Wang Expires 30 March 2027 [Page 28]
Internet-Draft CEP September 2026
* 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.
27. References
27.1. Normative References
[JEP] Wang, Y., "Judgment Event Protocol (JEP)", Work in
Progress, Internet-Draft, draft-wang-jep-judgment-event-
protocol-07, 26 September 2026,
<https://datatracker.ietf.org/doc/html/draft-wang-jep-
judgment-event-protocol-07>.
[JEP-CONFORMANCE]
Wang, Y., "JEP Conformance and Test Suite", Work in
Progress, Internet-Draft, draft-wang-jep-conformance-01,
26 September 2026, <https://datatracker.ietf.org/doc/html/
draft-wang-jep-conformance-01>.
[JEP-PROFILES]
Wang, Y., "JEP Profiles and Interoperability", Work in
Progress, Internet-Draft, draft-wang-jep-profiles-01, 26
September 2026, <https://datatracker.ietf.org/doc/html/
draft-wang-jep-profiles-01>.
Wang Expires 30 March 2027 [Page 29]
Internet-Draft CEP September 2026
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, May 2017,
<https://www.rfc-editor.org/rfc/rfc8174>.
[RFC8785] Rundgren, A., Jordan, B., and S. Erlandsson, "JSON
Canonicalization Scheme (JCS)", RFC 8785, June 2020,
<https://www.rfc-editor.org/rfc/rfc8785>.
27.2. Informative References
[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-02, 26
September 2026,
<https://datatracker.ietf.org/doc/html/draft-wang-coe-02>.
[JAC] Wang, Y., "JAC: Declared Dependency Graphs for JEP Events
and Receipts", Work in Progress, Internet-Draft, draft-
wang-jac-03, 26 September 2026,
<https://datatracker.ietf.org/doc/html/draft-wang-jac-03>.
[JEP-RECEIPT]
Wang, Y., "JEP Receipt Profile: Verifiable Behavior and
Evidence Receipts", Work in Progress, Internet-Draft,
draft-wang-jep-receipt-profile-00, 26 September 2026,
<https://datatracker.ietf.org/doc/html/draft-wang-jep-
receipt-profile-00>.
Author's Address
Yuqiang Wang
Email: signal@humanjudgment.org
URI: https://github.com/hjs-spec
Wang Expires 30 March 2027 [Page 30]