JEP: Judgment Event Protocol

Version 0.1 – Public Draft · IETF Internet-Draft: draft-wang-hjs-judgment-event-00

Status of This Memo

This document defines a structural specification for recording responsibility relationships in AI-mediated decision systems.

This document is a public draft maintained by the HJS Foundation.

1. Introduction

As AI systems increasingly participate in decision-making processes, structural binding of responsibility becomes necessary for traceability and verification.

This specification defines a minimal structural model for representing responsibility relationships.

This document does not define legal liability or ethical policy.

It defines structural relationships.

2. Terminology

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", and "MAY" in this document are to be interpreted as described in RFC 2119.

3. Core Primitives

The protocol defines four primitives that together form the minimum record of responsibility — capable of answering any court’s four core questions about an AI decision:

Why was this decided? (Judgment) · Who is responsible? (Delegation) · What actually happened? (Termination) · How can it be proven? (Verification)

1

Judgment

Records the basis of an AI decision.

MUST include:

  • Model identifier or version
  • Key parameter configuration
  • Cryptographic commitment to input data (optional)
2

Delegation

Records who delegated to whom, scope of authority, and time — forming a traceable chain of responsibility.

MUST include:

  • Delegator identifier
  • Delegate identifier
  • Delegation time
  • Scope or constraints

MUST adhere to:

  • Delegation chains MUST remain traceable.
  • Cyclic delegation chains are INVALID.
  • Chain length SHOULD NOT exceed a reasonably defined upper limit.
3

Termination

Records the final outcome of a task.

MUST include:

  • Status (success / failure / abort)
  • Cryptographic commitment to output data (optional)
  • Duration (optional)
4

Verification

Records who verified the result and how.

MUST include:

  • Verifier identifier
  • Verification method
  • Verification time
  • Verification result

4. Structural Model

The protocol defines a directed graph structure.

Nodes represent primitives.

Edges represent structural references.

All references MUST be resolvable.

5. Invariants

A structure MUST satisfy:

  1. All required fields are present.
  2. Delegation chains remain acyclic.
  3. Termination references existing nodes.
  4. Validation is deterministic.

6. Validation

A structure is VALID if:

  • Structural invariants are satisfied.
  • No prohibited cycles exist.
  • Time references do not conflict.
  • Authority chains remain continuous.

Validation MUST be deterministic.

7. Security Considerations

Improper delegation chains, unresolved references, or structural cycles may compromise responsibility traceability.

Implementations SHOULD validate structures prior to persistence.

8. Versioning

Backwards-incompatible changes require a major version increment.

Minor revisions MUST preserve structural invariants.