Semantic Interoperability for the Judgment Event Protocol

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

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

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.1. Protocol-Semantic Record

A JEP event is a signed protocol statement carrying one J/D/T/V verb.¶

A semantic processor MUST distinguish:¶

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

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

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

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

A semantic processor MUST NOT synthesize a Core validation result.¶

Example:¶

{
  "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.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:¶

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

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

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

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

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"

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