Network Working Group Y. Wang Internet-Draft 26 September 2026 Intended status: Experimental Expires: 30 March 2027 Semantic Interoperability for the Judgment Event Protocol draft-wang-jep-semantic-interoperability-01 Abstract This document defines semantic interoperability requirements for the Judgment Event Protocol (JEP) [JEP]. JEP-Core defines signed J/D/T/V event semantics, Event Identity, Event Hash, references, validation checks, validation modes, extension processing, and idempotent acceptance. This document does not redefine those mechanisms. Instead, it defines the minimum shared interpretation rules required for independent systems to map, display, translate, and consume JEP events without silently changing their meaning. The core rule is that a JEP event records a signed protocol statement with defined verb semantics. It does not by itself establish external truth, authority, legality, causality, completeness, policy consequence, or external effect. Stronger conclusions require an explicitly selected profile or external evidence rule. 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 JEP Semantic Interoperability 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 1.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Relationship to JEP-Core . . . . . . . . . . . . . . . . 4 1.3. Relationship to Profiles and Conformance . . . . . . . . 4 1.4. Non-Goals . . . . . . . . . . . . . . . . . . . . . . . . 5 1.5. Requirements Language . . . . . . . . . . . . . . . . . . 5 2. Semantic Processing Model . . . . . . . . . . . . . . . . . . 5 2.1. Protocol-Semantic Record . . . . . . . . . . . . . . . . 5 2.2. Minimum Semantic Invariant . . . . . . . . . . . . . . . 6 2.3. Event Identity and Artifact Identity . . . . . . . . . . 6 2.4. Open-World Default . . . . . . . . . . . . . . . . . . . 7 2.5. Profile-Bounded Interpretation . . . . . . . . . . . . . 7 3. Semantic Projection . . . . . . . . . . . . . . . . . . . . . 7 3.1. Core-Derived Roles . . . . . . . . . . . . . . . . . . . 8 3.2. Context- or Profile-Derived Roles . . . . . . . . . . . . 8 3.3. Core-Derivable Relations . . . . . . . . . . . . . . . . 8 3.4. Profile- or Extension-Declared Relations . . . . . . . . 9 4. Verb Semantics . . . . . . . . . . . . . . . . . . . . . . . 9 4.1. J - Judgment . . . . . . . . . . . . . . . . . . . . . . 9 4.2. D - Delegation . . . . . . . . . . . . . . . . . . . . . 10 4.3. T - Termination . . . . . . . . . . . . . . . . . . . . . 10 4.4. V - Verification . . . . . . . . . . . . . . . . . . . . 11 5. Verification Scope Preservation . . . . . . . . . . . . . . . 11 5.1. Core Ownership . . . . . . . . . . . . . . . . . . . . . 11 5.2. Preservation Rule . . . . . . . . . . . . . . . . . . . . 12 5.3. Unsupported or Profile-Defined Scopes . . . . . . . . . . 12 6. Mapping External Systems to JEP . . . . . . . . . . . . . . . 13 6.1. Mapping Rule . . . . . . . . . . . . . . . . . . . . . . 13 6.2. Ambiguity . . . . . . . . . . . . . . . . . . . . . . . . 13 6.3. Information Loss . . . . . . . . . . . . . . . . . . . . 13 6.4. Reverse Mapping . . . . . . . . . . . . . . . . . . . . . 14 6.5. JEP Output Conformance . . . . . . . . . . . . . . . . . 14 Wang Expires 30 March 2027 [Page 2] Internet-Draft JEP Semantic Interoperability September 2026 7. Semantic Processing Result . . . . . . . . . . . . . . . . . 14 7.1. Status Meanings . . . . . . . . . . . . . . . . . . . . . 15 7.2. Minimal Result Model . . . . . . . . . . . . . . . . . . 15 8. Non-Inference Rules . . . . . . . . . . . . . . . . . . . . . 17 8.1. Judgment Does Not Imply Truth . . . . . . . . . . . . . . 17 8.2. Delegation Does Not Imply Authority Validity . . . . . . 18 8.3. Termination Does Not Delete History . . . . . . . . . . . 18 8.4. Termination Does Not Imply Cascade . . . . . . . . . . . 18 8.5. Verification Does Not Exceed Scope . . . . . . . . . . . 18 8.6. Reference Does Not Imply Relation . . . . . . . . . . . . 18 8.7. Absence Does Not Imply Non-Occurrence . . . . . . . . . . 19 8.8. Cryptographic Validity Does Not Imply Truth . . . . . . . 19 8.9. Actor Binding Does Not Imply Authority . . . . . . . . . 19 8.10. Chain Integrity Does Not Imply Completeness or Causality . . . . . . . . . . . . . . . . . . . . . . . 19 8.11. Policy Compliance Does Not Imply Lawfulness . . . . . . . 19 8.12. Human Review Does Not Imply Review Quality . . . . . . . 20 8.13. Profile Semantics Do Not Generalize . . . . . . . . . . . 20 9. Semantic Identifier Rules . . . . . . . . . . . . . . . . . . 20 10. Semantic Processor Capabilities . . . . . . . . . . . . . . . 20 10.1. Core-Semantics Processor . . . . . . . . . . . . . . . . 20 10.2. Profile-Aware Semantic Processor . . . . . . . . . . . . 21 10.3. Bridge Semantic Processor . . . . . . . . . . . . . . . 21 11. Cross-Jurisdictional Boundary . . . . . . . . . . . . . . . . 21 12. Security Considerations . . . . . . . . . . . . . . . . . . . 22 13. Privacy Considerations . . . . . . . . . . . . . . . . . . . 23 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 15. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 24 15.1. Approval as Judgment . . . . . . . . . . . . . . . . . . 24 15.2. Approval as Delegation . . . . . . . . . . . . . . . . . 24 15.3. Signature Verification . . . . . . . . . . . . . . . . . 24 15.4. Termination . . . . . . . . . . . . . . . . . . . . . . 25 15.5. Reference Without Dependency . . . . . . . . . . . . . . 25 16. Changes from -00 . . . . . . . . . . . . . . . . . . . . . . 25 17. References . . . . . . . . . . . . . . . . . . . . . . . . . 26 17.1. Normative References . . . . . . . . . . . . . . . . . . 26 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 27 1. Introduction 1.1. Purpose Syntactic and cryptographic interoperability do not guarantee semantic interoperability. Two systems may both process the same JEP event while assigning different meaning to local words such as approve, verify, revoke, review, or delegate. Wang Expires 30 March 2027 [Page 3] Internet-Draft JEP Semantic Interoperability September 2026 This document answers: When independent systems interpret the same JEP event, what meaning must they preserve, and what conclusions must they not add? 1.2. Relationship to JEP-Core JEP-Core is authoritative for: * the Core event object; * the four event verbs J, D, T, and V; * Event Identity (who,id); * Event Hash; * JEP Signing Payload and signature semantics; * reference semantics; * extension processing; * independent validation checks; * validation modes; * idempotent acceptance. This document MUST NOT redefine any of those semantics. Semantic interoperability operates after or alongside Core processing. A semantic processor MAY interpret a Core-valid event, a Core-invalid event for diagnostic purposes, or an event whose Core status is indeterminate, but it MUST report Core status separately from semantic interpretation status. 1.3. Relationship to Profiles and Conformance JEP Profiles [JEP-PROFILES] defines deployment-specific trust, identity, credential, acceptance, archival, chain, and policy rules. JEP Conformance [JEP-CONFORMANCE] defines executable conformance expectations, validation-result structure, schemas, test-vector categories, and reference-validator behavior. Wang Expires 30 March 2027 [Page 4] Internet-Draft JEP Semantic Interoperability September 2026 This document defines neither trust policy nor Core validation behavior. It defines only interpretation constraints and bridge behavior. 1.4. Non-Goals This document does not define: * legal liability; * moral responsibility; * regulatory compliance; * contractual validity; * runtime authorization; * access-control decisions; * complete workflow semantics; * truth of external factual claims; * evidence sufficiency for an external target; * causal-chain computation; * delegation-chain enforcement; * termination cascade; * profile selection. 1.5. Requirements Language The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals. 2. Semantic Processing Model 2.1. Protocol-Semantic Record A JEP event is a signed protocol statement carrying one J/D/T/V verb. A semantic processor MUST distinguish: Wang Expires 30 March 2027 [Page 5] Internet-Draft JEP Semantic Interoperability September 2026 what the event says at the protocol layer from what an external system chooses to conclude from that statement Core validity does not imply external truth. Semantic interpretability does not imply Core validity. 2.2. Minimum Semantic Invariant A conforming semantic processor MUST preserve: * the event verb; * the claimed actor identified by who; * Event Identity when available; * verb-specific Core fields; * declared references; * declared verification scope and result for V; * active profile context when explicitly selected; * the distinction between logical Event Identity and exact-artifact Event Hash. A processor MUST NOT add an authority, causal, legal, policy, completeness, or truth conclusion that is not licensed by JEP-Core or an explicitly selected profile. 2.3. Event Identity and Artifact Identity Semantic mapping MUST distinguish: Event Identity = (who,id) = which JEP event Event Hash = which exact signed artifact A bridge referring to the logical event SHOULD preserve Event Identity. A bridge that needs byte-specific or signature-specific identity MAY also preserve Event Hash. A processor MUST NOT use Event Hash as a substitute for stable Event Identity when the semantic question concerns which event instance is referenced. Wang Expires 30 March 2027 [Page 6] Internet-Draft JEP Semantic Interoperability September 2026 2.4. Open-World Default Unless an explicitly selected profile states otherwise, semantic interpretation is open-world. Therefore: * absence of an event from an observed log does not prove non- occurrence; * a reference does not imply that all relevant objects are referenced; * an observed chain does not imply that the chain is complete; * a termination declaration does not prove that all downstream reliance stopped; * a verification result does not imply checks outside its declared scope. A complete-log or closed-world assumption MUST be explicit and belongs to the profile or chain system that defines it. 2.5. Profile-Bounded Interpretation Profiles MAY define stronger or domain-specific interpretation. Such interpretation MUST remain scoped to the selected profile. A semantic processor MUST NOT generalize a profile-local conclusion into a global JEP conclusion. Profile selection MUST follow the explicit-selection rules of JEP Profiles. This document MUST NOT infer a profile merely from actor syntax, credential presence, aud, or extension shape. 3. Semantic Projection A semantic projection is a machine-readable interpretation derived from a JEP event and explicitly selected context without changing the Core event. A semantic projection is not a new signed JEP object and MUST NOT be presented as part of the signed payload unless an extension or profile explicitly defines such a representation. Wang Expires 30 March 2027 [Page 7] Internet-Draft JEP Semantic Interoperability September 2026 3.1. Core-Derived Roles The following provisional roles can be derived directly from Core semantics: * jep:role:actor: the entity claimed by who. This does not establish actor/key binding, authority, competence, or legal capacity. * jep:role:delegatee: for D, the entity identified by what.delegatee. * jep:role:verifier: for V, the actor in its role as the entity recording the scoped evaluation. This does not imply competence beyond the declared verification scope. 3.2. Context- or Profile-Derived Roles The following roles require context beyond the minimum Core event: * jep:role:signer: the key holder that produced the event signature. The signer is not necessarily the actor; actor/key binding is profile-defined. * jep:role:subject: an object or entity about which a J/D/T/V statement is made when such a subject is explicitly represented by the event, extension, or active profile. A processor MUST NOT invent a subject. * jep:role:relying_party: an entity that consumes or acts on a JEP event. This is processing context and is not necessarily encoded in the event. A semantic result MUST identify the source of a context- or profile- derived role. 3.3. Core-Derivable Relations The following provisional relations can be derived from Core verb or field semantics: * jep:relation:references: the event explicitly references another object through ref. This does not imply causality, dependency, support, endorsement, authorization, or completeness. * jep:relation:judges: a J event expresses or adopts a judgment about the claim, choice, classification, recommendation, or proposed result represented by the event. Wang Expires 30 March 2027 [Page 8] Internet-Draft JEP Semantic Interoperability September 2026 * jep:relation:delegates_to: a D event declares a scoped delegation from its actor to what.delegatee. This does not establish authority to delegate. * jep:relation:terminates_future_reliance_on: a T event declares that the target identified by ref is no longer eligible for future reliance within what.termination_scope. This does not delete history or establish cascade effects. * jep:relation:verifies: a V event records that its actor evaluated the target identified by ref under what.verification_scope and recorded what.result. This does not imply verification beyond the declared scope. 3.4. Profile- or Extension-Declared Relations The following relations MAY be used by profiles or extensions but MUST NOT be derived from ref alone: * jep:relation:depends_on * jep:relation:supports * jep:relation:supersedes * jep:relation:challenges A profile defining one of these relations MUST specify its exact meaning, required fields, and non-inference boundaries. 4. Verb Semantics 4.1. J - Judgment J means that the actor expressed or adopted a judgment. Typical mappings include: * approval or rejection of a proposed result; * classification; * risk judgment; * selection among alternatives; * adoption of a recommendation. Wang Expires 30 March 2027 [Page 9] Internet-Draft JEP Semantic Interoperability September 2026 A J event MUST NOT be interpreted as proof that the judged claim is true, authorized, lawful, safe, or externally effective. A bridge MUST NOT map an action to J merely because a source system uses the word approved. It MUST determine whether the source semantics are actually a judgment rather than delegation or verification. 4.2. D - Delegation D means that the actor declared a delegation to the delegatee within an explicit scope. The Core semantic anchors are: * what.delegatee; * what.scope. A D event MUST NOT be interpreted as proof that the actor possessed legal, organizational, or technical authority to delegate. Downstream authorization, permission-chain enforcement, mandate consumption, and legal effect belong to profiles or external systems. 4.3. T - Termination T means that the actor declared a referenced target no longer eligible for future reliance within a stated termination scope. The Core semantic anchors are: * target through ref; * what.termination_scope. A T event MUST NOT be interpreted as: * deletion of the target; * retroactive invalidation of historical events; * proof that all downstream systems stopped relying on the target; * automatic termination of descendants; * proof that prior actions were invalid. Wang Expires 30 March 2027 [Page 10] Internet-Draft JEP Semantic Interoperability September 2026 Cascade or downstream-effect semantics require an applicable profile or chain system. 4.4. V - Verification V means that the actor evaluated a referenced target under an explicitly declared verification scope and recorded the result. The Core semantic anchors are: * target through ref; * what.verification_scope; * what.result. A V event MUST NOT imply verification beyond its declared scope. A local statement such as "I reject proposal X" maps to J unless the source semantics specifically mean "I evaluated X under scope S and obtained result R". 5. Verification Scope Preservation 5.1. Core Ownership JEP-Core is the authoritative source for Core verification-scope identifiers and their meanings. This document does not create a second Core scope registry and does not redefine the meanings of Core scopes. The initial JEP-Core 0.7 scope identifiers include: * syntax * cryptographic * actor_binding * freshness * audience * event_identity * reference_integrity * extension_processing Wang Expires 30 March 2027 [Page 11] Internet-Draft JEP Semantic Interoperability September 2026 * chain_integrity * credential_status * policy_compliance * human_review * external_evidence * factual_claim * archival_integrity This list is reproduced only to describe preservation behavior. JEP- Core controls if the list or meanings change. 5.2. Preservation Rule A semantic processor MUST preserve the exact verification-scope identifier and the associated result carried by the V event. A semantic processor MUST NOT: * rename a scope in a way that changes its meaning; * merge multiple distinct scopes into a stronger aggregate meaning; * infer that a passing result for one scope implies a passing result for another scope; * treat a profile-local scope as a global JEP-Core scope. For example, cryptographic does not imply actor_binding, policy_compliance, or factual_claim. 5.3. Unsupported or Profile-Defined Scopes A processor that does not implement the meaning of a recognized or profile-defined scope MUST preserve the identifier when possible and report semantic_unsupported rather than fabricating an interpretation. A profile-defined scope: * MUST use a collision-resistant identifier; * MUST define its semantic meaning; Wang Expires 30 March 2027 [Page 12] Internet-Draft JEP Semantic Interoperability September 2026 * MUST define required evidence or procedure; * MUST define non-inference boundaries; * MUST NOT redefine a Core scope; * MUST remain scoped to the active profile. 6. Mapping External Systems to JEP 6.1. Mapping Rule A bridge MUST map according to source semantics, not source labels. The same local label MAY map to different JEP verbs in different contexts. For example: approve report -> J, when it means "adopt this result" approve tool access -> D, when it means "delegate scoped authority" approve verification result -> V, only when it means "evaluate target under declared scope and result" 6.2. Ambiguity When more than one JEP verb is consistent with the available source semantics, a bridge MUST report semantic_ambiguous unless an explicitly selected profile or source field resolves the ambiguity. A bridge MUST NOT resolve ambiguity by assuming authority, verification, causality, or legal effect. 6.3. Information Loss A bridge translating from another system into JEP MUST declare known semantic information loss when the source carries semantics that are not represented in the JEP event and active profile set. Examples include loss of: * authority scope; * verification method; Wang Expires 30 March 2027 [Page 13] Internet-Draft JEP Semantic Interoperability September 2026 * evidence provenance; * termination propagation; * human-review context; * domain-specific state semantics. 6.4. Reverse Mapping A bridge translating JEP into another system MUST NOT emit a stronger destination meaning than the JEP event and selected profiles support. If the destination schema cannot preserve a required distinction, the bridge MUST either: * report information loss; * choose a weaker destination representation; * or refuse the mapping. 6.5. JEP Output Conformance If a bridge emits a JEP event, that output MUST independently satisfy the applicable JEP-Core Producer requirements. Semantic mapping does not waive Core field, verb, canonicalization, or signature requirements. A bridge MAY construct an unsigned intermediate representation, but it MUST NOT present that intermediate representation as a conforming signed JEP event. 7. Semantic Processing Result Semantic processing status is independent from JEP-Core validation status. The initial semantic_status values are: * semantic_conformant * semantic_ambiguous * semantic_unsupported * semantic_nonconformant Wang Expires 30 March 2027 [Page 14] Internet-Draft JEP Semantic Interoperability September 2026 * semantic_indeterminate 7.1. Status Meanings semantic_conformant means the reported interpretation conforms to this document and the explicitly selected profile semantics. It does not mean that the JEP event is Core-valid. semantic_ambiguous means multiple permitted interpretations remain and the available context does not select one. semantic_unsupported means the event uses a semantic identifier, scope, or profile semantics that the processor does not implement. semantic_nonconformant means the proposed interpretation contradicts JEP-Core verb semantics or a mandatory non-inference rule. semantic_indeterminate means the processor implements the relevant semantic rule but lacks required context to complete the interpretation. 7.2. Minimal Result Model A semantic processor SHOULD return a structured result. If it returns a structured result, the result MUST contain semantic_status. When available from the parsed event, the result SHOULD contain: * event_identity; * verb. Derived semantic interpretations SHOULD be carried in interpretations. Each interpretation MUST identify: * kind, such as role or relation; * semantic id; * source, identifying the Core field, verb, profile, extension, or bridge rule from which it was derived. The result MAY include: * core_status, but only when copied from an actual Core validation result; Wang Expires 30 March 2027 [Page 15] Internet-Draft JEP Semantic Interoperability September 2026 * profiles, but only for explicitly selected profiles; * warnings; * information_loss; * unsupported_identifiers. A semantic processor MUST NOT synthesize a Core validation result. Example: Wang Expires 30 March 2027 [Page 16] Internet-Draft JEP Semantic Interoperability September 2026 { "semantic_status": "semantic_conformant", "core_status": "valid", "event_identity": { "who": "did:example:verifier-123", "id": "urn:uuid:018f4f8d-a1d5-7633-9b6c-63d4928819e2" }, "verb": "V", "profiles": [], "interpretations": [ { "kind": "role", "id": "jep:role:actor", "source": "core.who" }, { "kind": "role", "id": "jep:role:verifier", "source": "core.verb" }, { "kind": "relation", "id": "jep:relation:references", "source": "core.ref" }, { "kind": "relation", "id": "jep:relation:verifies", "source": "core.verb" } ], "warnings": [ "jep:non_inference:no_truth_from_cryptographic" ], "information_loss": [], "unsupported_identifiers": [] } 8. Non-Inference Rules The following rules are normative. 8.1. Judgment Does Not Imply Truth A J event MUST NOT be interpreted as proof of truth, correctness, legality, safety, or evidentiary sufficiency of its claim. Identifier: Wang Expires 30 March 2027 [Page 17] Internet-Draft JEP Semantic Interoperability September 2026 jep:non_inference:no_truth_from_judgment 8.2. Delegation Does Not Imply Authority Validity A D event MUST NOT be interpreted as proof that the delegator had authority to delegate or that the delegatee has unlimited authority. Identifier: jep:non_inference:no_authority_validity_from_delegation 8.3. Termination Does Not Delete History A T event MUST NOT be interpreted as deletion, erasure, or retroactive invalidation of historical events. Identifier: jep:non_inference:no_history_deletion_from_termination 8.4. Termination Does Not Imply Cascade A T event MUST NOT be interpreted as automatically terminating downstream or derived objects unless an applicable profile defines that effect. Identifier: jep:non_inference:no_cascade_from_termination 8.5. Verification Does Not Exceed Scope A V event MUST NOT be interpreted as verification beyond its declared verification_scope. Identifier: jep:non_inference:no_verification_beyond_scope 8.6. Reference Does Not Imply Relation A ref MUST NOT be interpreted as causality, dependency, support, endorsement, authorization, or completeness unless an explicit relation or profile defines that meaning. Identifier: jep:non_inference:no_relation_from_reference Wang Expires 30 March 2027 [Page 18] Internet-Draft JEP Semantic Interoperability September 2026 8.7. Absence Does Not Imply Non-Occurrence Absence from an observed log MUST NOT be interpreted as proof of non- occurrence unless an applicable complete-log assumption is explicitly in force. Identifier: jep:non_inference:no_nonoccurrence_from_absence 8.8. Cryptographic Validity Does Not Imply Truth Cryptographic verification MUST NOT be interpreted as proof of substantive truth. Identifier: jep:non_inference:no_truth_from_cryptographic 8.9. Actor Binding Does Not Imply Authority A passing actor-binding evaluation MUST NOT be interpreted as proof of authority to perform the claimed act. Identifier: jep:non_inference:no_authority_from_actor_binding 8.10. Chain Integrity Does Not Imply Completeness or Causality A passing chain-integrity evaluation MUST NOT be interpreted as proof that the observed chain is complete or that its edges are causal unless the active chain profile establishes those properties. Identifier: jep:non_inference:no_completeness_or_causality_from_chain 8.11. Policy Compliance Does Not Imply Lawfulness A policy-compliance result MUST NOT be generalized to legal or regulatory compliance outside the identified policy/profile. Identifier: jep:non_inference:no_lawfulness_from_policy Wang Expires 30 March 2027 [Page 19] Internet-Draft JEP Semantic Interoperability September 2026 8.12. Human Review Does Not Imply Review Quality A human-review result MUST NOT be interpreted as proof of expertise, independence, completeness, correctness, or legal sufficiency unless an applicable profile establishes those properties. Identifier: jep:non_inference:no_review_quality_from_human_review 8.13. Profile Semantics Do Not Generalize A stronger interpretation defined by one profile MUST NOT be generalized to events outside that profile. Identifier: jep:non_inference:no_globalization_of_profile_semantics 9. Semantic Identifier Rules Identifiers defined by this document are provisional identifiers of this Experimental Internet-Draft. They are not IANA-registered. A semantic identifier defined here MUST NOT be repurposed within this draft series. A future incompatible meaning MUST use a new identifier. Profile-defined identifiers SHOULD be collision-resistant and SHOULD identify their controlling profile. Semantic processors MUST preserve unknown identifiers when possible and MUST NOT replace them with a guessed known identifier. 10. Semantic Processor Capabilities This document defines independent semantic capabilities rather than cumulative validation levels. 10.1. Core-Semantics Processor A Core-Semantics Processor: * interprets J/D/T/V consistently with JEP-Core; * preserves the Event Identity and Event Hash distinction; Wang Expires 30 March 2027 [Page 20] Internet-Draft JEP Semantic Interoperability September 2026 * derives only the Core-derived roles and relations defined here; * preserves verification-scope identifiers without broadening them; * applies the non-inference rules; * produces a semantic processing result. 10.2. Profile-Aware Semantic Processor A Profile-Aware Semantic Processor additionally: * consumes an explicitly selected profile; * interprets profile-defined semantic identifiers; * may derive context- or profile-derived roles; * preserves profile-local boundaries; * reports unsupported or missing profile semantics; * does not generalize profile conclusions. 10.3. Bridge Semantic Processor A Bridge Semantic Processor: * maps external-system semantics to JEP; * reports ambiguity; * reports information loss; * preserves required Core distinctions; * refuses or weakens mappings that would otherwise overstate meaning. An implementation MAY support any combination of these capabilities. It MUST declare which capabilities it implements. 11. Cross-Jurisdictional Boundary This specification is jurisdiction-neutral. It does not assign legal effect to a JEP event or semantic result. Wang Expires 30 March 2027 [Page 21] Internet-Draft JEP Semantic Interoperability September 2026 A jurisdiction, regulator, court, organization, contract, or governance system MAY define how JEP events are used as evidence. Such rules belong to an explicitly selected profile or external policy. A jurisdiction-specific profile SHOULD identify: * jurisdiction or domain; * issuing or controlling authority; * exact semantic additions; * whether legal effect is claimed; * evidence assumptions; * conflict-handling rules. A semantic processor MUST NOT infer those properties from jurisdiction, organization, or actor identifiers alone. 12. Security Considerations Semantic interoperability introduces security risks even when cryptographic processing is correct. Implementations MUST consider: * verb inflation: mapping a local action into a J/D/T/V meaning not supported by source semantics; * scope inflation: presenting a narrow V result as a broader verification; * actor/signer confusion; * reference laundering: treating ref as dependency, support, or causality; * Event Identity / Event Hash confusion; * profile confusion or silent profile switching; * false complete-log assumptions; * termination-cascade overreach; Wang Expires 30 March 2027 [Page 22] Internet-Draft JEP Semantic Interoperability September 2026 * semantic downgrade through information loss; * registry or identifier confusion. A bridge MUST NOT silently strengthen meaning. A semantic processor SHOULD retain provenance for every derived role, relation, and bridge mapping. 13. Privacy Considerations Semantic metadata can reveal sensitive relationships even when evidence payloads are not disclosed. Potentially sensitive metadata includes: * who judged a claim; * who delegated to whom; * verification targets and scopes; * termination targets; * evidence relationships; * organization or workflow relationships; * profile and policy context. Implementations SHOULD minimize semantic metadata, avoid unnecessary stable cross-context identifiers, and use controlled references instead of embedded sensitive evidence where appropriate. A semantic processor SHOULD NOT require disclosure of external evidence merely to interpret Core J/D/T/V semantics. 14. IANA Considerations This document requests no IANA actions. A future standards-track or registry specification may request registries for: * semantic role identifiers; * semantic relation identifiers; Wang Expires 30 March 2027 [Page 23] Internet-Draft JEP Semantic Interoperability September 2026 * non-inference identifiers; * semantic processing status identifiers. Any future registry MUST preserve the JEP-Core semantic boundary and MUST NOT permit registration to redefine J/D/T/V, Event Identity, Event Hash, or Core verification-scope semantics. 15. Examples 15.1. Approval as Judgment Source meaning: Reviewer accepts proposed result R. Mapping: J The mapping does not establish that R is true. 15.2. Approval as Delegation Source meaning: Principal permits agent A to act within scope S. Mapping: D what.delegatee = A what.scope = S Whether that delegation is authorized is profile-dependent. 15.3. Signature Verification Source meaning: Artifact X was checked cryptographically and the check passed. Mapping: V ref = X what.verification_scope = "cryptographic" what.result = "pass" Wang Expires 30 March 2027 [Page 24] Internet-Draft JEP Semantic Interoperability September 2026 The mapping MUST NOT be interpreted as factual verification of claims inside X. 15.4. Termination Source meaning: Actor declares that future reliance on delegation D is terminated within scope S. Mapping: T ref = D what.termination_scope = S No cascade is implied. 15.5. Reference Without Dependency A J event references report R. The semantic projection contains jep:relation:references. It MUST NOT add jep:relation:depends_on unless the event or selected profile explicitly declares dependency. 16. Changes from -00 Major changes from draft-wang-jep-semantic-interoperability-00: * aligned the document with JEP-Core 0.7; * replaced "event class" terminology with Core "event verb" terminology; * removed cumulative validation-level semantics; * removed Core anti-replay-field semantics; * aligned replay-related interpretation with Event Identity and idempotent acceptance; * made Event Identity versus Event Hash a normative semantic distinction; * aligned J/D/T/V wording with the minimum Core verb semantics; Wang Expires 30 March 2027 [Page 25] Internet-Draft JEP Semantic Interoperability September 2026 * removed semantic requirements that implied fields not required by Core; * made JEP-Core the sole authority for Core verification-scope meanings; * reduced this document's scope handling to preservation and non- inference; * separated Core-derived roles from context- or profile-derived roles; * separated Core-derived relations from profile- or extension- declared relations; * required bridge mappings to preserve information loss and ambiguity; * required JEP output from a bridge to independently satisfy JEP- Core Producer requirements; * renamed semantic_valid to semantic_conformant to avoid confusion with Core validation status; * defined a minimal semantic result model with provenance for every derived interpretation; * replaced cumulative S1/S2/S3 framing with independent semantic processor capabilities; * changed semantic identifiers to provisional identifiers and requested no IANA actions in this Experimental revision; * tightened profile-selection boundaries to match JEP Profiles; * updated examples to use JEP-Core 0.7 fields and verification scopes. 17. References 17.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, . Wang Expires 30 March 2027 [Page 26] Internet-Draft JEP Semantic Interoperability September 2026 [JEP-CONFORMANCE] Wang, Y., "JEP Conformance and Test Suite", Work in Progress, Internet-Draft, draft-wang-jep-conformance-01, 26 September 2026, . [JEP-PROFILES] Wang, Y., "JEP Profiles and Interoperability", Work in Progress, Internet-Draft, draft-wang-jep-profiles-01, 26 September 2026, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, May 2017, . Author's Address Yuqiang Wang Email: signal@humanjudgment.org URI: https://github.com/hjs-spec Wang Expires 30 March 2027 [Page 27]