Semantic Interoperability for the Judgment Event Protocol

Introduction

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. This document answers:

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.

Relationship to Profiles and Conformance JEP Profiles defines deployment-specific trust, identity, credential, acceptance, archival, chain, and policy rules. JEP Conformance defines executable conformance expectations, validation-result structure, schemas, test-vector categories, and reference-validator behavior. This document defines neither trust policy nor Core validation behavior. It defines only interpretation constraints and bridge behavior.

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.

Requirements Language The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals.

Semantic Processing Model

Protocol-Semantic Record A JEP event is a signed protocol statement carrying one J/D/T/V verb. A semantic processor MUST distinguish: Core validity does not imply external truth. Semantic interpretability does not imply Core validity.

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.

Event Identity and Artifact Identity Semantic mapping MUST distinguish: 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.

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.

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.

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.

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.

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.

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

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.

Verb Semantics

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.

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.

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.

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.

Cascade or downstream-effect semantics require an applicable profile or chain system.

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

Verification Scope Preservation

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

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.

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;
MUST define required evidence or procedure;
MUST define non-inference boundaries;
MUST NOT redefine a Core scope;
MUST remain scoped to the active profile.

Mapping External Systems to JEP

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: 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" ]]>

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.

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;
evidence provenance;
termination propagation;
human-review context;
domain-specific state semantics.

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.

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.

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
semantic_indeterminate

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.

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;
profiles, but only for explicitly selected profiles;
warnings;
information_loss;
unsupported_identifiers.

A semantic processor MUST NOT synthesize a Core validation result. Example:

Non-Inference Rules The following rules are normative.

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:

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:

Termination Does Not Delete History A T event MUST NOT be interpreted as deletion, erasure, or retroactive invalidation of historical events. Identifier:

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:

Verification Does Not Exceed Scope A V event MUST NOT be interpreted as verification beyond its declared verification_scope. Identifier:

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:

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:

Cryptographic Validity Does Not Imply Truth Cryptographic verification MUST NOT be interpreted as proof of substantive truth. Identifier:

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:

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:

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:

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:

Profile Semantics Do Not Generalize A stronger interpretation defined by one profile MUST NOT be generalized to events outside that profile. Identifier:

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.

Semantic Processor Capabilities This document defines independent semantic capabilities rather than cumulative validation levels.

Core-Semantics Processor A Core-Semantics Processor:

interprets J/D/T/V consistently with JEP-Core;
preserves the Event Identity and Event Hash distinction;
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.

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.

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.

Cross-Jurisdictional Boundary This specification is jurisdiction-neutral. It does not assign legal effect to a JEP event or semantic result. 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.

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

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.

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

Examples

Approval as Judgment Source meaning: Mapping: The mapping does not establish that R is true.

Approval as Delegation Source meaning: Mapping: Whether that delegation is authorized is profile-dependent.

Signature Verification Source meaning: Mapping: The mapping MUST NOT be interpreted as factual verification of claims inside X.

Termination Source meaning: Mapping: No cascade is implied.

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.

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