Protocol

JEP-Core defines a compact signed JSON event format for judgment-related statements.

The narrow core

The core is intentionally small. Identity, policy, evidence, archival, trust, freshness, and chain-composition semantics are externalized to profiles and extensions.

JEP-Core focuses on interoperability. Profiles define deployment-specific trust and acceptance rules.

Core event object

A JEP event defines 11 standard top-level members. Seven are unconditionally required; the remaining members are conditional or optional depending on the event.

jepREQUIRED
Wire-format major version. Current value "1".
idREQUIRED
Opaque event identifier. Event Identity is (who, id).
verbREQUIRED
One of "J", "D", "T", "V".
whoREQUIRED
Actor identifier claimed by the event.
whenREQUIRED
Actor-declared event time in Unix seconds.
whatREQUIRED
Verb-specific claim, descriptor, or permitted digest.
audOPTIONAL
Intended audience or validation context.
refCONDITIONAL
Typed reference or exact-artifact reference.
extOPTIONAL
Extension object.
ext_critOPTIONAL
Critical extension identifier list.
sigREQUIRED
Signature container defined by the applicable signature profile.

The seven unconditionally required members are jep, id, verb, who, when, what, and sig. Members inside what — such as claim, subject, scope, result, evidence, and context — are semantic subfields, not additional JEP top-level members.

Event Identity

Event Identity = (who, id)

Event Identity identifies one logical JEP event instance. The same Event Identity represents the same event across retransmission, storage, export, and re-verification.

Event Identity
(who, id)

Identifies the logical event.

Event Hash
sha256:JCS(full signed event)

Identifies one exact signed artifact.

Re-signing otherwise identical unsigned content may produce a different Event Hash without creating a different Event Identity.

Declared time

when is an actor-declared event time. It does not by itself prove trusted wall-clock time, liveness, or freshness.

Stronger time evidence may come from timestamping, receipt, archival, transparency, challenge-response, transport, or storage profiles.

Four event verbs

J — Judgment

The signed statement that an actor expressed or adopted a judgment about a claim, choice, classification, recommendation, or proposed result. It does not by itself prove the judged claim is true, authorized, or externally effective.

D — Delegation

The signed statement that an actor declared a delegation to a delegatee within an explicit scope (delegatee + scope). It does not by itself establish authority to delegate.

T — Termination

The signed statement that an actor declared a referenced target no longer eligible for future reliance within a stated termination scope (ref + termination_scope). It does not delete history or retroactively invalidate an event.

V — Verification

The signed statement that an actor evaluated a referenced target under a declared verification scope and recorded the result (ref + verification_scope + result). It must not imply verification beyond its declared scope.

References without overclaiming

A JEP event reference primarily identifies another event by its Event Identity. An optional hash can pin one exact signed artifact.

{
  "type": "jep:event",
  "value": {
    "who": "did:example:actor-123",
    "id": "urn:uuid:..."
  }
}
{
  "type": "jep:event",
  "value": {
    "who": "did:example:actor-123",
    "id": "urn:uuid:..."
  },
  "hash": "sha256:..."
}

The value identifies the event. The optional hash pins one exact signed artifact.

Reference is linkage, not automatic causality. A reference does not by itself prove causality, authorization, endorsement, truth, completeness, or legal effect.

Independent validation checks

JEP-Core does not define cumulative validation levels. A verifier reports independent checks and their individual outcomes.

JEP-Core
syntaxcryptographicevent_identityreference_integrityextension_processing
Trust / acceptance profile
actor_bindingfreshnessaudience
Companion / external
chain_integritypolicy
Check statuses
passfailnot_checkednot_applicableunsupportedindeterminate
Overall validation status
validinvalidindeterminate

An unperformed check must never be reported as pass.

Safe retry and idempotent acceptance

Network retry, queue redelivery, storage import, export, or replication of an existing signed event does not create a new JEP event.

Within one acceptance domain, the same Event Identity must not apply the same state-changing acceptance effect more than once.

acceptedalready_acceptedrejectedindeterminate

already_accepted is not a cryptographic validation failure.

JEP-Core does not require a nonce. Deployments that need stronger guarantees may use profiles containing:

nonce, challenge-response, sequence number, trusted timestamp, counter, ledger position, transaction identifier

Trust profiles define deployment context

JEP-Core does not define a global identity or trust framework.

Profiles may define: supported actor identifier forms, key discovery, actor/key binding, accepted algorithms, revocation, historical validity, credential use, audience requirements, freshness requirements, challenge-response, acceptance-domain rules, policy hooks.

DID, VC, X.509, OAuth, RATS, blockchain anchoring, and specific AI identity systems remain optional.

What JEP can determine — and what it cannot

Protocol-observable

JEP can support determination of:

  • —the asserted Event Identity
  • —whether signed content changed
  • —whether a signature verifies
  • —whether an exact artifact hash matches
  • —whether references were processed
  • —whether critical extensions were processed
  • —which validation checks were actually performed
  • —whether an Event Identity was already accepted in an acceptance domain
External facts

JEP alone does not determine:

  • —whether a real-world claim is true
  • —whether an actor had legal authority
  • —whether a delegation is legally enforceable
  • —whether an actor is legally liable
  • —whether a human understood something
  • —whether every relevant event was logged
  • —whether downstream systems honored termination
  • —whether external effects occurred

Privacy and deployment considerations

JEP events may reveal actor identity, subject identity, decision timing, delegation structure, workflow, tool usage, or audit relationships.

Deployments should consider: data minimization, retention policy, redaction, access control, audience separation, identifier unlinkability.

JEP can support privacy-preserving deployments when profiles apply appropriate minimization, retention, redaction, and access-control policies.

Complementary protocols

JEP is not positioned as competing with transport, communication, identity, or runtime protocols.

JEP can complement: HTTP-based systems, MCP, A2A, ACP, AGTP, agent runtimes, audit systems, archival systems.

Transport protocols move messages. Runtime protocols coordinate actions. JEP structures judgment-related event records.