Network Working Group Y. Wang Internet-Draft Independent Intended status: Experimental Expires: December 3, 2026 June 1, 2026 Semantic Interoperability for the Judgment Event Protocol draft-wang-jep-semantic-interoperability-00 Abstract This document defines semantic interoperability requirements for the Judgment Event Protocol (JEP). JEP-Core defines the event syntax, event classes, signatures, hashes, references, extension processing, and validation levels for signed judgment-related events. This document does not modify those mechanisms. Where this document restates JEP-Core semantics, JEP-Core remains authoritative. Instead, this document defines the minimum shared semantic invariants required for independent systems to interpret JEP events consistently across implementations, profiles, organizations, and jurisdictions. The document specifies core semantic roles, core semantic relations, event- class interpretation rules for Judgment, Delegation, Termination, and Verification events, verification-scope semantics, semantic identifiers, profile-extension constraints, semantic validation results, non-inference rules, semantic conformance requirements, initial semantic registry requirements, and cross-jurisdictional boundaries. It defines semantic registry contents and constraints, but does not define operational registry governance beyond the requirements stated here. This document does not define legal effect, moral responsibility, regulatory compliance, runtime enforcement, access-control decisions, domain-specific workflows, or external truth. A JEP event is a protocol- semantic record. Whether that record is sufficient to support an external target claim is outside the scope of this document and must be determined by an applicable profile, evidence policy, domain rule, or target-support analysis. 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 3 December 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 1.1. Purpose 1.2. Relationship to JEP-Core 1.3. Relationship to JEP Profiles and JEP Conformance 1.4. Non-Goals 1.5. Boundary Summary 1.6. Normative and Informative Content 1.7. Terminology 2. Semantic Model 2.1. JEP Events as Protocol-Semantic Records 2.2. Minimum Semantic Invariant 2.3. Profile-Bounded Interpretation 2.4. Open-World Default 2.5. Semantic Validity Is Not Target Sufficiency 2.6. Runtime and Enforcement Boundary 3. Core Semantic Roles 4. Core Semantic Relations 5. Event-Class Semantics 5.1. Judgment 5.2. Delegation 5.3. Termination 5.4. Verification 6. Verification Scope Semantics 6.1. Scope Declaration and Semantic Interpretation 7. Semantic Identifiers 8. Profile Extension Rules 9. Semantic Ambiguity 9.1. Ambiguous Local Actions 9.2. Ambiguity Reporting 9.3. Information Loss in Mapping 10. Semantic Validation 10.1. Separation from JEP-Core Validation 10.2. Semantic Validation Status 10.3. Semantic Validation Result Object 10.4. Failure Conditions 10.5. Semantic Validation and External Targets 11. Non-Inference Rules 12. Semantic Conformance 12.1. Conformance Classes 13. Cross-Jurisdictional Considerations 14. Security Considerations 15. Privacy Considerations 16. IANA Considerations 16.1. JEP Semantic Role Registry 16.2. JEP Semantic Relation Registry 16.3. JEP Verification Scope Registry 16.4. JEP Semantic Validation Status Registry 16.5. JEP Non-Inference Rule Registry 16.6. JEP Profile Semantic Extension Registry 17. Registry Governance Boundary 18. Compatibility with Other JEP Documents 19. Examples 19.1. Approval as Judgment 19.2. Approval as Delegation 19.3. Verification Scope Mismatch 19.4. Termination and Future Reliance 19.5. Reference Without Dependency 20. Invalid Inference Examples References Author's Address A. Initial Semantic Identifier Registry A.1. Roles A.2. Relations A.3. Verification Scopes A.4. Semantic Validation Statuses A.5. Non-Inference Rules B. Minimal Semantic Validation Result Example C. Summary 1. Introduction 1.1. Purpose JEP-Core defines a compact event layer for judgment-related acts. Its four event classes are: J - Judgment D - Delegation T - Termination V - Verification JEP-Core defines how these events are represented, signed, hashed, referenced, extended, and validated. However, syntactic and cryptographic interoperability do not guarantee semantic interoperability. Two systems can both produce valid JEP events while interpreting their meaning differently. For example: approved = true verified = true revoked = true reviewed = true can mean different things in different systems. One system can treat approved as a Judgment. Another can treat it as a Delegation. A third can treat it as Verification. Similarly, verified can mean syntax validation, signature validation, actor binding, chain integrity, human review, policy compliance, external evidence review, factual-claim checking, or target-support checking. This document defines the common semantic layer needed to prevent such divergence. It answers the following question: When independent systems receive the same JEP event, what must they agree that the event means, and what must they not infer from it? 1.2. Relationship to JEP-Core This document is a companion semantic layer for JEP-Core. It does not modify: * JEP-Core event syntax * JEP-Core event classes * JEP-Core signature semantics * JEP-Core event-hash semantics * JEP-Core reference semantics * JEP-Core validation levels * JEP-Core anti-replay fields * JEP-Core critical-extension processing Where this document appears to restate JEP-Core event semantics, JEP-Core remains authoritative. This document constrains cross-system and cross-profile interpretation of JEP-Core events. A conforming implementation of this document MUST interpret JEP-Core events in a way that is consistent with JEP-Core. 1.3. Relationship to JEP Profiles and JEP Conformance JEP Profiles define profile-specific trust, identity, credential, deployment, archival, domain, and interoperability bindings. JEP Conformance defines implementation conformance classes, test vectors, reference-validator behavior, and validation-result expectations. This document does not replace either one. The relationship is: JEP-Core event syntax, event classes, signatures, hashes, references, validation levels. JEP Semantic Interoperability shared semantic invariants, event-class interpretation, verification-scope semantics, non-inference rules, semantic roles, semantic relations, semantic validation statuses. JEP Profiles trust profiles, identity bindings, domain bindings, deployment-specific semantics. JEP Conformance implementation conformance, validation behavior, schemas, test vectors. Profiles MAY refine the semantics defined here, but they MUST NOT redefine the core meaning of Judgment, Delegation, Termination, or Verification. This document defines semantic registry requirements and initial registry contents for the semantic identifiers it introduces. Operational registry maintenance procedures, registry operator selection, appeals, deprecation workflows, ecosystem policy, and namespace delegation MAY be specified by a separate JEP registry-governance document. Such a document MUST preserve the semantic invariants and non-inference rules defined here. 1.4. Non-Goals This document does not define: * legal liability * moral responsibility * regulatory compliance * contractual validity * runtime authorization enforcement * access-control decisions * complete governance workflows * domain-specific approval processes * truth of external factual claims * sufficiency of evidence for external targets A JEP event MAY be used as evidence in such contexts, but it does not by itself settle them. 1.5. Boundary Summary This document defines semantic interoperability constraints only. It does not assign operational authority, legal effect, governance status, runtime permission, evidentiary sufficiency, or factual truth. The following boundaries are normative: JEP-Core boundary JEP-Core remains authoritative for event syntax, event classes, signatures, hashes, references, validation levels, and extension processing. Profile boundary Profiles MAY define stronger or domain-specific interpretations, but those interpretations apply only within the declaring profile and MUST NOT be generalized to all JEP events. Governance boundary This document supports governance interoperability by defining semantic invariants, but it does not define governance outcomes, institutional authority, legal liability, or regulatory compliance. Runtime boundary This document does not authorize, deny, execute, block, revoke, or enforce runtime actions. Runtime behavior is profile- or deployment-specific. Evidence boundary This document defines how evidence references and support relations may be interpreted semantically. It does not determine whether referenced evidence is sufficient for an external target. Registry boundary This document defines initial semantic registries and identifier stability rules. Operational registry governance MAY be specified separately and MUST preserve the semantic invariants defined here. 1.6. Normative and Informative Content The following sections are normative: , , , , , , , , , , , and . The following sections are informative unless otherwise stated: , , , , , , and appendices. 1.7. Terminology 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, as shown here. Event class One of Judgment, Delegation, Termination, or Verification. Semantic role A function played by an entity in the interpretation of a JEP event. Semantic relation A declared relationship between an event, actor, subject, evidence item, prior event, claim, state object, receipt, or profile. Verification scope The declared boundary of what a Verification event checks. Semantic validation The process of determining whether a JEP event is semantically interpretable under this document and any applicable profiles. Non-inference rule A rule prohibiting implementations or relying parties from deriving claims that are not licensed by the event semantics. 2. Semantic Model 2.1. JEP Events as Protocol-Semantic Records A JEP event is a signed protocol record declaring that an actor, under a stated event class and applicable profile context, performed or asserted a judgment-related act. A JEP event is not, by itself: * a proof of external truth * a proof of legal authority * a proof of moral responsibility * a proof of regulatory compliance * a proof of target sufficiency * a proof of complete causal history 2.2. Minimum Semantic Invariant For any JEP event, a conforming implementation MUST preserve the following invariant: The event class, actor, subject, declared scope, declared references, and declared semantic relations MUST NOT be interpreted beyond their declared meaning without an applicable profile. At minimum: * Judgment records a judgment-related act. * Delegation records a bounded grant, transfer, assignment, or delegation * context. * Termination records closure, revocation, expiry, replacement, or end of * future reliance. * Verification records a check under a declared verification scope. 2.3. Profile-Bounded Interpretation A profile MAY refine event interpretation. A profile MAY say: In this profile, a D event creates a mandate-validity claim. A profile MUST NOT say: A D event always proves legal authorization in all domains. 2.4. Open-World Default Unless an applicable profile declares otherwise, JEP interpretation is open- world. In particular: * Absence of a JEP event in an observed log does not prove that the * corresponding real-world event did not occur. * A reference to an object does not prove that all relevant objects have been * referenced. * A structurally valid chain does not prove that the chain is complete. A closed-world or complete-log interpretation MUST be explicitly declared by profile. 2.5. Semantic Validity Is Not Target Sufficiency A semantically valid event is one that can be interpreted under JEP semantic rules and any applicable profile. Semantic validity does not imply that the event, chain, receipt, or evidence bundle is sufficient to support an external target claim. A target-support analysis MAY be performed by a separate profile or method. Such analysis MAY include target-determinability analysis, evidence- sufficiency analysis, risk-bound analysis, domain-specific evidentiary review, human expert review, or another registered target-support method. This document does not require any particular target-support method. 2.6. Runtime and Enforcement Boundary This document is record-semantic, not execution-semantic. A semantic validation result under this document MUST NOT be interpreted as an authorization decision, access-control decision, tool-call permission, execution approval, revocation command, rollback instruction, or enforcement action unless an applicable runtime or enforcement profile explicitly defines that behavior. Implementations that use JEP events in runtime decision-making MUST identify the applicable runtime profile, policy engine, mandate profile, or access- control mechanism. This document alone does not provide such a mechanism. 3. Core Semantic Roles A semantic role is a function played by an entity in the interpretation of a JEP event. Each role identifier SHOULD be registered in the JEP Semantic Role Registry. jep:role:actor The entity represented as performing or asserting the event. Actor identity does not by itself prove authority, correctness, legal capacity, or competence. jep:role:issuer The entity or system that issued, serialized, or signed the event record. The issuer MAY be the actor, but need not be. Implementations MUST distinguish actor identity from issuer identity when both are present. jep:role:subject The claim, action, mandate, evidence item, workflow, prior event, state object, receipt, or target to which the event applies. jep:role:principal The entity on whose behalf authority, task scope, or responsibility context is granted. A principal identifier does not by itself prove legal authority. jep:role:delegatee The entity receiving delegated authority, task scope, capability, action mandate, or responsibility context. jep:role:verifier The entity or system performing a declared Verification event. The verifier role does not imply competence for every possible verification scope. jep:role:relying_party An entity that consumes, interprets, or acts upon a JEP event. A relying party MUST NOT infer semantics beyond the event class, declared fields, declared verification scope, applicable profiles, and registered semantic identifiers. jep:role:evidence_holder An entity or system that stores, controls, or can disclose evidence referenced by a JEP event. A referenced evidence holder does not imply that evidence has been disclosed, verified, or is sufficient. jep:role:profile_authority An entity that defines or maintains a profile used to interpret JEP events in a particular deployment, trust framework, domain, organization, or jurisdictional context. 4. Core Semantic Relations A semantic relation is a declared relationship between an event, actor, subject, evidence item, prior event, claim, state object, receipt, or profile. Each relation identifier SHOULD be registered in the JEP Semantic Relation Registry. jep:relation:references An event references another object, event, claim, state, mandate, receipt, or evidence item. A reference alone MUST NOT be interpreted as causality, endorsement, approval, dependency, support, completeness, truth, or authorization unless an applicable profile declares such meaning. jep:relation:judges A Judgment event records a decision-related position about its subject. The relation does not imply that the judged subject is true, correct, safe, legally valid, or sufficiently evidenced. jep:relation:delegates_to A Delegation event grants, transfers, assigns, or delegates a bounded authority, task, capability, mandate, or responsibility context from a principal or delegating actor to a delegatee. The relation does not imply legal validity unless an applicable profile establishes that effect. jep:relation:terminates A Termination event closes, revokes, expires, replaces, cancels, suspends, or ends future reliance on its declared subject. The relation does not delete historical events. jep:relation:verifies A Verification event records that a declared verification procedure was applied to a declared subject under a declared verification scope. The relation does not imply verification beyond that declared scope. jep:relation:depends_on An event, claim, receipt, or state object declares dependency on another event, evidence item, state, receipt, or claim. A dependency relation MUST be explicit. A reference alone is not dependency. jep:relation:supports An event or evidence item is declared by the emitting system or applicable profile to support a claim, target, judgment, receipt, or state object. This relation records a declared support relationship only. It does not imply evidentiary sufficiency, truth, endorsement, causality, target support, or legal effect unless an applicable profile, evidence policy, domain rule, or target-support analysis establishes those additional conclusions. jep:relation:supersedes An event or record declares that it replaces or supersedes a prior event, record, mandate, state, or claim. Supersession does not imply deletion of the prior record. jep:relation:bounds An event declares a scope, time interval, usage limit, capability limit, policy limit, resource limit, or audience boundary. jep:relation:challenges An event or record declares that a prior claim, event, verification, mandate, judgment, receipt, or state claim is disputed, incomplete, invalid under a profile, or requires further evidence. This relation does not by itself settle the challenge. 5. Event-Class Semantics 5.1. Judgment A Judgment event records that an actor made, accepted, rejected, classified, selected, approved, disapproved, committed to, or otherwise recorded a decision-related position concerning a declared subject. A Judgment event establishes only that the judgment-related act was recorded under JEP. A Judgment event MUST NOT be interpreted as proof that the judged claim is true, that the decision is legally valid, that the decision is morally correct, that the decision is supported by sufficient evidence, or that the decision is target-sufficient unless an applicable profile, evidence policy, domain rule, or target-support analysis establishes those additional conclusions. Minimum semantic fields for a Judgment interpretation SHOULD include actor, subject, judgment relation, event time or event timestamp, and profile context if any. 5.2. Delegation A Delegation event records a bounded grant, transfer, assignment, or authorization context from a principal or delegating actor to a delegatee. A Delegation event establishes only that a delegation-related act was recorded under JEP. A Delegation event SHOULD declare, directly or through an applicable profile, principal, delegatee, scope, validity interval, constraints, termination conditions, permitted uses, relying parties, and profile context. A Delegation event MUST NOT be interpreted as proof of legal authorization, organizational legitimacy, correct action by the delegatee, downstream action validity, or unlimited authority unless an applicable profile establishes those effects. 5.3. Termination A Termination event records closure, revocation, expiry, cancellation, suspension, replacement, or end of future reliance concerning a declared subject. A Termination event SHOULD declare, directly or through an applicable profile, terminated subject, termination mode, termination time, scope of termination, future reliance effect, replacement reference if any, and downstream revalidation requirement if any. A Termination event MUST NOT be interpreted as deletion of historical records, proof that all downstream reliance has ended, proof that legal, social, or organizational obligations are resolved, proof that prior actions were invalid, or proof that all child delegations are terminated unless an applicable profile explicitly provides such semantics. 5.4. Verification A Verification event records that a declared check was applied to a declared subject under a declared verification scope. A Verification event MUST declare a verification scope, either directly or through an applicable profile. A Verification event establishes only that the declared verification procedure was recorded under the declared scope. A Verification event MUST NOT be interpreted as verification beyond its declared scope. Minimum semantic fields for a Verification interpretation SHOULD include verifier, subject, verification scope, verification method or profile reference, and event time or event timestamp. 6. Verification Scope Semantics Verification scopes MUST be registered or profile-defined. A Verification event with an unknown non-critical scope MAY be treated as semantically uninterpretable. A Verification event with an unknown critical scope MUST fail semantic validation. The scopes listed in this section are initial registered identifiers. Implementations are REQUIRED to preserve their meanings when used, but are not REQUIRED to support every scope unless required by a declared profile. 6.1. Scope Declaration and Semantic Interpretation JEP-Core remains authoritative for how verification scopes are represented, carried, and processed as part of JEP events. This document defines the semantic interpretation of registered scopes when those scopes are used. If a future version of JEP-Core or an applicable profile defines event-processing requirements for a scope, those event-processing requirements remain outside this document unless explicitly incorporated here. A scope identifier registered here does not require every implementation to perform the corresponding verification procedure. It only requires that implementations preserve the registered meaning when they emit, translate, validate, display, or rely on that scope. jep:scope:syntax Establishes that the checked object conforms to a declared syntax or schema. Does not establish cryptographic validity, actor binding, truth, legal validity, or target sufficiency. jep:scope:cryptographic_signature Establishes that a declared signature verification procedure succeeded. Does not establish truth of the signed claim. jep:scope:actor_binding Establishes that a declared actor-binding procedure succeeded under an applicable identity or trust profile. Does not establish that the actor had authority to act. jep:scope:credential_status Establishes that a declared credential-status check was performed. Does not establish legal authority beyond the credential profile. jep:scope:chain_integrity Establishes that a declared event, receipt, or dependency chain is structurally intact under the declared chain profile. Does not establish that every external event occurred or that the chain proves an external target. jep:scope:policy_compliance Establishes that a declared policy-compliance check was applied. Does not establish legal liability, moral correctness, factual truth, or regulatory compliance unless an applicable profile establishes those conclusions. jep:scope:mandate_validity Establishes that a declared action mandate satisfies an applicable mandate- validity profile. Does not establish that the resulting action is factually correct, safe, lawful, or externally sufficient. jep:scope:human_review Establishes that a human-review process was recorded under the declared profile. Does not establish review quality, expertise, independence, completeness, correctness, or legal sufficiency unless a profile defines those properties. jep:scope:external_evidence Establishes that external evidence was checked or referenced under the declared evidence policy. Does not establish that the evidence is sufficient for the target unless a target-support, evidence, or domain profile establishes such sufficiency. jep:scope:source_provenance Establishes that a provenance check was applied to the declared source. Does not establish source truthfulness. jep:scope:factual_claim Establishes that a factual-claim verification procedure was applied. The level of support, evidence policy, uncertainty, and domain validity MUST be declared by profile. jep:scope:target_support Establishes that a target-support analysis, evidence-sufficiency analysis, target-determinability analysis, risk-bound analysis, or another registered target-support procedure was referenced or checked. Does not establish that the analysis is correct unless its profile, model assumptions, evidence policy, and required verification procedure are also validated. jep:scope:archival_integrity Establishes that an archival-integrity check was applied. Does not establish target truth. jep:scope:redaction_integrity Establishes that a redacted view is linked to a declared source object under a declared redaction proof or policy. Does not establish that the redacted view is sufficient for all relying-party purposes. 7. Semantic Identifiers Semantic identifiers SHOULD use stable namespaced identifiers. Examples include jep:role:actor, jep:relation:delegates_to, jep:scope:chain_integrity, and jep:status:semantic_valid. Profiles MAY define additional identifiers, but they MUST NOT redefine identifiers registered by this document. Once registered, a semantic identifier MUST NOT be repurposed to mean a different semantic role, relation, scope, status, or rule. If a semantic meaning changes, a new identifier MUST be registered. Deprecated identifiers MUST remain resolvable. A profile defining a new semantic identifier SHOULD use a namespaced identifier controlled by the profile authority. A profile MUST NOT define an identifier that is visually or semantically confusable with a registered JEP identifier unless it is explicitly declared as a subtype or constrained interpretation of that registered identifier. 8. Profile Extension Rules A JEP profile MAY extend the semantic model by defining additional roles, relations, verification scopes, domain-specific subject types, domain-specific evidence descriptors, domain-specific conformance requirements, or domain- specific semantic validation results. A profile MUST NOT redefine Judgment, Delegation, Termination, or Verification; reinterpret a Verification event beyond its declared scope; erase non-inference rules defined by this document; treat references as causality without declaring a relation; treat references as dependency without declaring dependency; or treat absence of an event as proof of absence without a complete-log assumption. A profile that refines a core semantic identifier MUST declare whether it is a subtype, constraint, domain binding, profile-specific interpretation, or jurisdiction-specific interpretation. Profiles SHOULD declare whether their semantics are closed-world or open- world, complete-log dependent or partial-log tolerant, jurisdiction-neutral or jurisdiction-specific, record-only or runtime-enforcing, and legal-effect claiming or non-legal-effect. A profile defining stronger semantics than this document MUST state that those stronger semantics apply only within that profile and MUST NOT be generalized to JEP events outside that profile. A profile MUST clearly distinguish profile-local effects from JEP-global semantics. Statements such as legal validity, regulatory sufficiency, contractual effect, runtime authorization, organizational approval, or domain- specific evidentiary sufficiency MUST be explicitly scoped to the declaring profile. A profile MUST NOT register or use a semantic identifier in a way that conflicts with the registered meaning of an identifier defined by this document. If a profile needs a stronger, narrower, or domain-specific meaning, it MUST define a new identifier or an explicit subtype relation. 9. Semantic Ambiguity 9.1. Ambiguous Local Actions A local action may not map unambiguously to one JEP event class. For example, approve may map to Judgment if it records acceptance of a claim, Delegation if it grants action authority, or Verification if it validates a record or evidence chain. A bridge processor MUST mark a mapping as semantic_ambiguous unless an applicable profile disambiguates it. 9.2. Ambiguity Reporting When semantic ambiguity is detected, a processor SHOULD report the source local action, candidate JEP event classes, missing disambiguating fields, required profile if known, information loss if any, and recommended mapping if profile-defined. 9.3. Information Loss in Mapping A bridge processor translating from an external system into JEP events MUST declare known semantic information loss when the source event contains semantics that cannot be represented using the target JEP event class and declared profiles. Examples of information loss include loss of authority scope, verification method, evidence provenance, termination effect, human-review context, or target-support status. 10. Semantic Validation 10.1. Separation from JEP-Core Validation Semantic validation is distinct from JEP-Core syntactic, cryptographic, hash, reference, and validation-level checks. Failure of semantic validation under this document does not necessarily imply failure of JEP-Core syntactic or cryptographic validation. An event may be cryptographically valid but semantically uninterpretable, syntactically valid but semantically ambiguous, semantically valid under one profile but not another, or semantically valid but insufficient for an external target. 10.2. Semantic Validation Status A semantic validator SHOULD output one of: semantic_valid semantic_valid_with_profile semantic_ambiguous profile_required unsupported_scope unsupported_relation unsupported_role nonconformant out_of_scope 10.3. Semantic Validation Result Object A semantic validation result SHOULD include fields such as semantic status, event class, declared profiles, roles detected, relations detected, verification scopes, non-inference warnings, required profiles, and semantic failures. { "semantic_status": "semantic_valid_with_profile", "event_class": "D", "declared_profiles": ["jep-profile:amp"], "roles_detected": [ "jep:role:principal", "jep:role:delegatee" ], "relations_detected": [ "jep:relation:delegates_to", "jep:relation:bounds" ], "verification_scopes": [], "non_inference_warnings": [ "jep:non_inference:no_legal_authority_from_delegation" ], "required_profiles": [], "semantic_failures": [] } 10.4. Failure Conditions A semantic validator MUST return nonconformant if an event claims a core JEP class but contradicts its core semantics; a Verification event lacks a required scope; an unknown critical semantic identifier is present; a profile attempts to redefine a core event class; or a profile attempts to override a non-inference rule. 10.5. Semantic Validation and External Targets A semantic validator MAY report that an event is semantically valid while also reporting that the event is insufficient for an external target. Such insufficiency MUST NOT be treated as semantic nonconformance unless the applicable profile requires target sufficiency as part of semantic validation. 11. Non-Inference Rules This section is normative. Judgment does not imply truth A JEP Judgment event MUST NOT be interpreted as proof of the truth, correctness, legality, or sufficiency of the judged subject. Delegation does not imply legal authority A JEP Delegation event MUST NOT be interpreted as proof of legal, regulatory, contractual, or organizational authority unless an applicable profile explicitly establishes such effect. Termination does not delete history A JEP Termination event MUST NOT be interpreted as deletion, erasure, or invalidation of historical records unless a profile explicitly defines that effect. Termination does not automatically end all downstream reliance A JEP Termination event MUST NOT be interpreted as ending all downstream reliance unless the applicable profile defines the scope and propagation of such termination. Verification does not exceed scope A JEP Verification event MUST NOT be interpreted as verification beyond its declared verification scope. Reference does not imply causality A reference from one event to another MUST NOT be interpreted as causality, endorsement, dependency, support, or completeness unless an explicit semantic relation or profile declares that meaning. Absence does not imply non-occurrence The absence of a JEP event in an observed log MUST NOT be interpreted as proof that the corresponding real-world event did not occur unless a complete-log profile is in force. Chain integrity does not imply target sufficiency A structurally valid event chain MUST NOT be interpreted as sufficient evidence for an external target unless an applicable target-support, evidence, or domain profile establishes such sufficiency. Support does not imply sufficiency A supports relation MUST NOT be interpreted as sufficient support for an external target unless an applicable profile, evidence policy, domain rule, or target-support analysis establishes sufficiency. Human review does not imply review quality A human-review Verification event MUST NOT be interpreted as proof that the review was correct, independent, expert, complete, unbiased, or legally sufficient unless an applicable profile establishes those properties. Policy compliance does not imply lawfulness A policy-compliance Verification event MUST NOT be interpreted as legal compliance unless the applicable legal or regulatory profile explicitly defines that mapping. Target support does not imply universal truth A target-support Verification event MUST NOT be interpreted as proof of universal truth, complete evidence, or applicability outside the declared target, evidence policy, model assumptions, and profile. Profile semantics do not generalize globally A stronger interpretation defined by a profile MUST NOT be generalized to JEP events outside that profile unless another applicable profile explicitly adopts that interpretation. 12. Semantic Conformance 12.1. Conformance Classes This document defines three semantic conformance classes: S1: Core Semantic Processor Identifies event-class semantics, registered roles, registered relations, declared verification scopes, applies non-inference rules, produces semantic validation results, and rejects core semantic redefinition. S2: Profile-Aware Semantic Processor Additionally supports profile resolution, profile-specific semantic identifiers, profile-specific validation rules, profile-specific failure mapping, and profile-specific non-inference constraints. S3: Bridge Semantic Processor Additionally supports mapping external events into JEP semantic roles and relations, declaring information loss, declaring unsupported semantic features, declaring required profiles, and declaring semantic ambiguity where mapping is not unique. 13. Cross-Jurisdictional Considerations JEP semantic interoperability is jurisdiction-neutral. This document does not assign legal effect to JEP events. A jurisdiction, regulator, court, organization, contract, or governance domain MAY define how JEP events are used as evidence, but such use is outside this document. Profiles that define jurisdiction-specific effects MUST identify the jurisdiction, identify the authority of the profile, identify the semantic changes from JEP-Core, state whether legal effect is claimed, state whether relying parties may infer legal consequence, state whether event semantics are evidentiary or dispositive, and state conflict-handling rules. A JEP event that is semantically valid under this document may still have no legal effect in a given jurisdiction. Semantic interoperability is therefore evidentiary and interpretive, not dispositive. A jurisdiction-specific profile MAY state how JEP events are used as evidence, but this document does not decide whether such evidence is sufficient, admissible, binding, or legally conclusive. 14. Security Considerations Implementations MUST consider at least the following risks. Semantic downgrade An attacker may cause a system to treat a high-assurance event as a lower- assurance event, or a lower-assurance event as sufficient for a higher- assurance claim. Mitigations include explicit verification scopes, profile identifiers, semantic validation results, and non-inference warnings. Verification scope inflation An attacker or careless system may present V(scope=cryptographic_signature) as if it were V(scope=factual_claim). Implementations MUST prevent scope inflation. Role confusion An attacker may confuse issuer, actor, principal, delegatee, verifier, and relying-party roles. Implementations SHOULD display and validate semantic roles separately. Reference laundering An attacker may use references to imply causality, endorsement, dependency, support, or completeness. Implementations MUST enforce explicit semantic relations. Even when a supports relation is explicit, systems MUST NOT treat it as sufficient support without an applicable profile, evidence policy, domain rule, or target-support analysis. Profile confusion An attacker may cause an event valid under one profile to be interpreted under another profile with stronger semantics. Implementations SHOULD bind semantic validation to declared profiles. Termination ambiguity Ambiguous Termination semantics may cause systems to rely on expired or revoked mandates. Profiles SHOULD define future-reliance effects explicitly. False complete-log assumption A system may treat an observed partial log as complete and infer non- occurrence from absence. Implementations MUST NOT assume log completeness without an applicable complete-log profile. Registry poisoning A malicious or careless registration may introduce confusing semantic identifiers. Registries SHOULD require expert review, collision checks, security review, and change-control procedures. Evidence reference substitution An attacker may substitute an evidence reference while preserving the surrounding semantic event structure. Profiles SHOULD bind evidence references cryptographically when evidence integrity is required. Ambiguous local-action mapping An attacker may exploit ambiguity in local actions such as approve, review, or verify to cause a bridge processor to map an event into a stronger JEP semantic class. Bridge processors MUST report ambiguity unless disambiguated by profile. 15. Privacy Considerations Semantic metadata can reveal sensitive organizational, legal, medical, financial, operational, or personal relationships even when evidence payloads are not disclosed. Sensitive semantic relationships may include who judged a claim, who delegated authority, who received delegated authority, who verified evidence, which mandate was terminated, which evidence holder controls evidence, which workflow depends on which prior event, and which state claim was challenged. Implementations SHOULD support data minimization, role minimization, pseudonymous actor references, digest references, selective disclosure, audience-bound semantic views, redaction integrity, encrypted evidence references, and unlinkability where appropriate. A semantic validator SHOULD NOT require disclosure of sensitive evidence unless the applicable profile requires it. 16. IANA Considerations This document requests IANA to create the initial semantic registries listed in this section upon publication as an RFC. The registration policy for each registry is Specification Required with Expert Review, as described in . Each registry entry SHOULD include identifier, name, description, defining document, status, security considerations, privacy considerations, profile dependencies, and change controller. Registered identifiers MUST NOT be repurposed. Deprecated identifiers MUST remain resolvable. New semantics require new identifiers. 16.1. JEP Semantic Role Registry This registry records semantic role identifiers used to interpret entities participating in JEP events. Initial entries are listed in . 16.2. JEP Semantic Relation Registry This registry records semantic relation identifiers used to interpret relationships among events, actors, subjects, evidence items, receipts, state objects, and profiles. Initial entries are listed in . 16.3. JEP Verification Scope Registry This registry records verification scope identifiers. Implementations are REQUIRED to preserve the registered meaning of a scope when that scope is used, but are not REQUIRED to support every registered scope unless required by a declared profile. Initial entries are listed in . 16.4. JEP Semantic Validation Status Registry This registry records machine-readable semantic validation status identifiers. Initial entries are listed in . 16.5. JEP Non-Inference Rule Registry This registry records non-inference rule identifiers. Non-inference rules registered by this document MUST NOT be overridden by profiles. Initial entries are listed in . 16.6. JEP Profile Semantic Extension Registry This registry records profile-defined semantic extensions, including additional roles, relations, scopes, validation statuses, and profile-specific constraints. 17. Registry Governance Boundary This document defines semantic registries and initial contents for the identifiers introduced here. It does not define all operational procedures for long-term registry maintenance, registry operator selection, appeals, deprecation workflow, ecosystem policy, or namespace delegation. A future registry-governance specification MAY define those operational procedures. Such a specification MUST NOT repurpose identifiers registered by this document, weaken the non-inference rules or boundary constraints defined here, or authorize profiles to redefine the core semantics of Judgment, Delegation, Termination, or Verification. 18. Compatibility with Other JEP Documents This document is compatible with JEP-Core, JEP Profiles, JEP Conformance, JEP- AMP, HJS, JAC, COE, CEP, and CTP. It does not replace their profile-specific semantics. It defines cross-profile semantic invariants and non-inference constraints. JEP-Core remains authoritative for event syntax, event classes, signatures, hashes, references, validation levels, and extension processing. This document is authoritative only for the semantic interoperability constraints defined herein. If a profile defines a stronger interpretation, that interpretation is valid only within that profile and MUST NOT be generalized to JEP events outside that profile. JEP-Core defines event syntax, event classes, signatures, hashes, references, validation levels, and extension rules. This document defines semantic interoperability rules for interpreting JEP-Core events. JEP Profiles define trust profiles, identity bindings, credential bindings, deployment profiles, and domain-specific interpretations. Profiles MUST conform to this document when extending JEP event semantics. JEP Conformance defines implementation conformance and test behavior. Semantic conformance tests SHOULD be added for this document. JEP-AMP defines action mandates using JEP Delegation events. JEP-AMP MUST conform to the Delegation semantics and non-inference rules defined here. HJS and JAC define receipt and dependency-chain infrastructure over JEP events. They MUST NOT infer semantics beyond registered JEP relations, profiles, and verification scopes. COE , CEP , and CTP may reference JEP events to bind observations, state claims, evolution records, or temporal claims. Such references MUST NOT imply truth, causality, authority, or completeness unless declared by profile. 19. Examples 19.1. Approval as Judgment A system records approved = true. If this means a reviewer accepted a report, it SHOULD be represented as a Judgment event. The event MUST NOT be interpreted as proof that the report is true. 19.2. Approval as Delegation A system records approved tool access. If this grants tool-use authority to an agent, it SHOULD be represented as a Delegation event, preferably under an action-mandate profile. The event SHOULD declare or reference principal, delegatee, scope, validity interval, constraints, and termination conditions. 19.3. Verification Scope Mismatch A system records verified = true. If the system verified only the signature, the JEP event MUST use V(scope=cryptographic_signature). It MUST NOT be interpreted as V(scope=factual_claim). 19.4. Termination and Future Reliance A Termination event closes an action mandate. Unless a profile specifies cascade behavior, the event MUST NOT be interpreted as automatically terminating every downstream child mandate. 19.5. Reference Without Dependency A Judgment event references a prior report. That reference alone does not imply that the Judgment depends on the report. A dependency MUST be declared using jep:relation:depends_on or an applicable profile. 20. Invalid Inference Examples Signature verification to factual truth Input: V(scope=cryptographic_signature). Invalid inference: the signed factual claim is true. Reason: cryptographic signature verification does not imply factual correctness. Delegation to legal authority Input: a D event granting an agent tool access. Invalid inference: the delegatee has legal authority in all contexts. Reason: legal authority requires an applicable profile or external rule. Parent termination to child termination Input: a T event terminating a parent mandate. Invalid inference: all child mandates are automatically terminated. Reason: cascade termination requires an applicable profile. Judgment to truth Input: a J event approving a report. Invalid inference: the report is true and fully evidenced. Reason: Judgment records a decision-related position; it does not prove truth or evidential sufficiency. Support to sufficiency Input: Event A declares jep:relation:supports for Claim B. Invalid inference: Claim B is sufficiently supported for all targets. Reason: support does not imply sufficiency without an applicable profile, evidence policy, domain rule, or target-support analysis. Reference to causality Input: Event A references Event B. Invalid inference: Event B caused Event A. Reason: reference does not imply causality unless an explicit relation or profile declares it. References Normative References [RFC2119] Scott Bradner. "Key words for use in RFCs to Indicate Requirement Levels." March 1997. https://www.rfc-editor.org/info/rfc2119 [RFC8174] Barry Leiba. "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words." May 2017. https://www.rfc-editor.org/info/rfc8174 [RFC8126] Michelle Cotton, Barry Leiba, Thomas Narten. "Guidelines for Writing an IANA Considerations Section in RFCs." June 2017. https://www.rfc-editor.org/info/rfc8126 [I-D.wang-jep-judgment-event-protocol] Yuqiang Wang. "Judgment Event Protocol." May 2026. https://datatracker.ietf.org/doc/draft-wang-jep-judgment-event- protocol/ [I-D.wang-jep-profiles] Yuqiang Wang. "Profiles for the Judgment Event Protocol." 2026. https://datatracker.ietf.org/doc/draft-wang-jep-profiles/ [I-D.wang-jep-conformance] Yuqiang Wang. "Conformance for the Judgment Event Protocol." 2026. https://datatracker.ietf.org/doc/draft-wang-jep-conformance/ Informative References [I-D.wang-jep-action-mandate-profile] Yuqiang Wang. "Action Mandate Profile for the Judgment Event Protocol." 2026. https://datatracker.ietf.org/doc/draft-wang-jep-action-mandate- profile/ [I-D.wang-hjs-accountability] Yuqiang Wang. "Human-Judgment Structured Accountability Receipts." 2026. https://datatracker.ietf.org/doc/draft-wang-hjs-accountability/ [I-D.wang-jac] Yuqiang Wang. "Judgment Accountability Chains." 2026. https://datatracker.ietf.org/doc/draft-wang-jac/ [I-D.wang-coe] Yuqiang Wang. "Claim Observation Evidence for JEP-Based Systems." 2026. https://datatracker.ietf.org/doc/draft-wang-coe/ [I-D.wang-cep] Yuqiang Wang. "Change Evidence Profile for JEP-Based Systems." 2026. https://datatracker.ietf.org/doc/draft-wang-cep/ [I-D.wang-ctp-definition] Yuqiang Wang. "Cognitive Time Protocol Definition." 2026. https://datatracker.ietf.org/doc/draft-wang-ctp-definition/ Appendix A. Initial Semantic Identifier Registry A.1. Roles jep:role:actor jep:role:issuer jep:role:subject jep:role:principal jep:role:delegatee jep:role:verifier jep:role:relying_party jep:role:evidence_holder jep:role:profile_authority A.2. Relations jep:relation:references jep:relation:judges jep:relation:delegates_to jep:relation:terminates jep:relation:verifies jep:relation:depends_on jep:relation:supports jep:relation:supersedes jep:relation:bounds jep:relation:challenges A.3. Verification Scopes jep:scope:syntax jep:scope:cryptographic_signature jep:scope:actor_binding jep:scope:credential_status jep:scope:chain_integrity jep:scope:policy_compliance jep:scope:mandate_validity jep:scope:human_review jep:scope:external_evidence jep:scope:source_provenance jep:scope:factual_claim jep:scope:target_support jep:scope:archival_integrity jep:scope:redaction_integrity A.4. Semantic Validation Statuses jep:status:semantic_valid jep:status:semantic_valid_with_profile jep:status:semantic_ambiguous jep:status:profile_required jep:status:unsupported_scope jep:status:unsupported_relation jep:status:unsupported_role jep:status:nonconformant jep:status:out_of_scope A.5. Non-Inference Rules jep:non_inference:no_truth_from_judgment jep:non_inference:no_legal_authority_from_delegation jep:non_inference:no_history_deletion_from_termination jep:non_inference:no_global_downstream_termination_without_profile jep:non_inference:no_verification_beyond_scope jep:non_inference:no_causality_from_reference jep:non_inference:no_absence_from_missing_event jep:non_inference:no_target_sufficiency_from_chain_integrity jep:non_inference:no_sufficiency_from_support jep:non_inference:no_review_quality_from_human_review jep:non_inference:no_lawfulness_from_policy_compliance jep:non_inference:no_universal_truth_from_target_support jep:non_inference:no_globalization_of_profile_semantics Appendix B. Minimal Semantic Validation Result Example { "event_id": "jep-event-123", "event_class": "V", "semantic_status": "semantic_valid", "declared_scope": "jep:scope:cryptographic_signature", "roles_detected": [ "jep:role:actor", "jep:role:verifier", "jep:role:subject" ], "relations_detected": [ "jep:relation:verifies", "jep:relation:references" ], "non_inference_warnings": [ "jep:non_inference:no_verification_beyond_scope" ], "semantic_failures": [] } Appendix C. Summary This document defines semantic interoperability requirements for JEP. It ensures that independent systems can interpret JEP events consistently while avoiding over-inference. The core principle is: A JEP event records a declared protocol-semantic act. It does not prove external truth, legal authority, factual correctness, target sufficiency, or complete causal history unless an applicable profile, evidence policy, domain rule, or target-support analysis establishes that result. This document provides the minimum semantic foundation required for JEP to serve as a public accountability event layer across agent systems, audit systems, governance systems, workflow systems, and future profiles. Author's Address Yuqiang Wang Independent Email: signal@humanjudgment.org URI: https://github.com/hjs-spec