JEP Specification Explorer
JEP-Core 0.7
Get started: create and verify a signed event locally
JEP is a narrow signed-event layer for judgment-related statements across human, organizational, software, and autonomous-agent systems.
The Core helps identify:
- which event instance is being handled;
- which Core verb it carries;
- who is the claimed actor;
- what content was signed;
- what object or event is referenced;
- which checks were actually performed;
- whether the same Event Identity has already produced an acceptance effect in the same acceptance domain.
It deliberately does not decide substantive truth, legal effect, authority, causality, or policy consequence.
Core event object
| Field | Status | Purpose |
|---|---|---|
jep | required | wire-format major; "1" in 0.7 |
id | required | opaque event identifier |
verb | required | J, D, T, or V |
who | required | claimed actor identifier |
when | required | actor-declared Unix-seconds event time |
what | required | verb-specific claim / descriptor / permitted digest |
aud | optional | intended audience or validation context |
ref | conditional | typed reference or exact-artifact reference |
ext | optional | extension object |
ext_crit | optional | critical extension identifiers |
sig | required | signature container selected by the active profile |
Event Identity: (who, id).
The signing payload is the JCS-canonicalized event with sig omitted.
The default-profile Event Hash is the SHA-256 digest of the JCS-canonicalized full signed event.
Four Core verbs
J — Judgment
A signed judgment-related statement. what is required; ref is optional.
D — Delegation
A scoped delegation statement. what.delegatee and what.scope are required.
T — Termination
A statement that future reliance on a referenced target is terminated within a declared scope.
what.termination_scope and ref are required.
V — Verification
A scoped evaluation of a referenced target. what.verification_scope,
what.result, and ref are required.
J and V are intentionally different: J records a judgment; V records an evaluation result against an explicit verification scope.
Delivery, identity, and acceptance
A retransmission is not a new event.
JEP-Core 0.7 uses stable Event Identity and idempotent acceptance rather than a required Core nonce.
Within one acceptance domain, one Event Identity must not produce the same state-changing acceptance effect more than once.
Typical acceptance outcomes:
acceptedalready_acceptedrejectedindeterminate
A profile may add freshness, audience, challenge, nonce, sequence, timestamp, or other replay controls where needed.
Independent validation checks
Validation is not a single ladder. Checks are independently reportable.
- 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
A verifier should make clear what it did and did not determine.
Main 0.6 → 0.7 changes
idbecame a required Core field.- Event Identity is explicitly
(who, id). - Event Identity and Event Hash are separated.
- the required top-level
noncewas removed from Core; - replay handling moved to idempotent acceptance plus optional profiles;
audis optional in Core;whenis declared event time, not proof of freshness;- references can identify logical JEP Event Identity and optionally pin an exact signed artifact;
- cumulative validation levels were replaced with independent checks;
- J / D / T / V minimum semantics were tightened;
- V requires an explicit result;
- chain, cascade, and causal interpretation are outside JEP-Core.
Resources and next steps
- Get started
- Try structural validation in the Playground
- Implementer guide
- JEP Core 0.7 Internet-Draft
- First-use check and feedback
- Contributing
This Space is explanatory material. If anything here conflicts with the Internet-Draft, the Internet-Draft controls.