Internet-Draft Y. Wang
Intended status: Experimental April 29, 2026
Expires: October 29, 2026
HJS: Accountability Receipts for AI Agents
A Minimal JEP Profile for Exportable AI Receipts
draft-wang-hjs-accountability-05
Abstract
This document defines HJS, a minimal accountability receipt
infrastructure for AI agents. HJS is a profile of the Judgment Event
Protocol (JEP) and does not define an independent event signing
protocol. HJS uses JEP events to bind signed event claims to AI-agent
behavior records, receipt manifests, optional privacy-preserving
human participant references, and optional deployment-specific
evidence references.
The HJS core is intentionally small. It defines behavior-record
digest binding, receipt manifests, receipt bundles, and validation of
cryptographic and structural consistency. All other capabilities,
including human privacy modes, participant-supplied references, post-
event review references, explanation-material references, risk
descriptors, model evidence, tool-call evidence, policy-check
evidence, multi-party export, and cryptographic capability profiles,
are optional extensions or deployment profiles.
HJS is infrastructure. It does not assign legal liability, prove
subjective intent, define governance rules, enforce monitoring,
define fairness, define appeal rights, define explanation rights,
determine authorization validity, or establish regulatory compliance.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute working
documents as Internet-Drafts. The list of current Internet-Drafts is
at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on October 29, 2026.
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document.
Table of Contents
1. Introduction
1.1. Motivation
1.2. Relationship to JEP
1.3. Scope
1.4. Minimal Core and Optional Extensions
1.5. Requirements Language
1.6. Terminology
2. HJS Model
2.1. Design Goals
2.2. Layering
2.3. Infrastructure Positioning
2.4. Machine Behavior and Human Participant Identity
2.5. HJS Events, Behavior Records, and Receipts
3. HJS-Core-1 Profile
3.1. Required JEP Profile
3.2. Use of JEP Verbs
3.3. JEP who, what, ref, ext, and ext_crit in HJS
3.4. HJS Receipt Extension
4. HJS Behavior Records
4.1. General Requirements
4.2. Required Fields
4.3. Evidence Descriptors
4.4. Human Participant References
4.5. Behavior Record Digest
5. HJS Receipt Manifests and Bundles
5.1. Receipt Manifest Structure
5.2. Receipt Bundle
5.3. Optional Multi-Party Exportable Receipt Bundles
6. HJS Optional Extensions
6.1. Extension Principles
6.2. Human Participant Privacy Extension
6.3. Identity Rotation Extension
6.4. Participant-Supplied and External Process References
6.5. Explanation Material References
6.6. Multi-Party Export Extension
6.7. Risk Extension
6.8. Model Evidence Extension
6.9. Tool Call Evidence Extension
6.10. Policy Check Evidence Extension
6.11. Use of JEP Cryptographic Profile Extension
7. Validation
7.1. JEP Validation
7.2. HJS Receipt Validation
7.3. Behavior Record Validation
7.4. Optional Extension Validation
7.5. Exported Bundle Validation
8. Security and Privacy Considerations
8.1. Signature and Chain Integrity
8.2. HJS Does Not Prove Truth, Intent, or Liability
8.3. Limits of Behavioral Determination under Partial Observation
8.4. Human Privacy and Linkability
8.5. Participant-Supplied References and Non-Inference
8.6. Governance Neutrality and Human Rights-Supporting Use
8.7. Regulatory Support, Not Regulatory Determination
8.8. Model, Tool, and Policy Evidence Limitations
9. IANA Considerations
9.1. HJS Extension Identifier Registrations
9.2. No Separate HJS Risk Level Registry
10. References
10.1. Normative References
10.2. Informative References
Appendix A. Non-Normative Examples
A.1. HJS Behavior Record Example
A.2. JEP Event Carrying an HJS Receipt Extension
A.3. HJS Receipt Manifest Example
A.4. External References and Explanation References Example
A.5. Multi-Party Export View Example
Appendix B. Changes from draft-wang-hjs-accountability-04
Author's Address
1. Introduction
1.1. Motivation
AI agents increasingly perform decision-related operations across
platforms, organizations, and jurisdictions. Such operations may
include planning, delegation, tool calls, content generation,
verification, escalation, or termination of a workflow. Operators,
affected parties, auditors, and downstream reviewers often need
evidence that a particular AI-agent behavior record was created,
bound to an accountable issuer, and not altered after signing.
HJS addresses this need by defining a minimal accountability receipt
infrastructure over JEP. HJS records observable AI-agent behavior
evidence, including inputs, outputs, tool calls, model descriptors,
policy checks, and optional human participant references. It binds
this evidence to JEP events by digest, while leaving signature
syntax, event hashes, references, replay protection, validation
modes, extension criticality, and cryptographic capability profiles
to JEP.
HJS is not intended to solve the algorithmic black-box problem in a
general philosophical or legal sense. HJS records evidence about
observable behavior. It can support audit, incident review,
explanation-material reference, and receipt export workflows, but it
does not by itself prove internal motivation, subjective intent,
causal completeness, legal responsibility, fairness, or regulatory
sufficiency.
1.2. Relationship to JEP
HJS is a profile of the Judgment Event Protocol (JEP) [I-D.wang-jep-
judgment-event-protocol]. JEP defines the minimal verifiable event
protocol: the J/D/T/V verbs, event object, algorithm-tagged digest
strings, event hash semantics, detached JWS signing over JCS-
canonicalized payloads, key resolution, validation modes, and the
ext/ext_crit extension framework.
HJS does not redefine those JEP mechanisms. An HJS event is a JEP
event with HJS-specific extension content and HJS-specific semantics
for the object referenced by the JEP what field.
JEP: minimal verifiable event protocol
HJS: minimal AI-agent receipt profile over JEP
This separation is a design requirement. HJS implementations MUST NOT
use an HJS-specific signature syntax that bypasses JEP. HJS
implementations MUST NOT reinterpret JEP event hashes, detached JWS
signatures, ext/ext_crit processing, JEP validation modes, or JEP
cryptographic profile semantics.
1.3. Scope
HJS defines:
* An AI-agent accountability receipt profile over JEP-Core-1.
* HJS behavior records for observable AI-agent behavior evidence.
* HJS receipt manifests and receipt bundles for portable validation
packages.
* HJS-specific optional extension identifiers for receipt, privacy,
identity rotation, external references, explanation-material
references, multi-party export, risk, model evidence, tool-call
evidence, and policy-check evidence.
* Validation rules for binding JEP events to HJS behavior records
and receipt manifests.
* Privacy guidance for separating machine behavior evidence from
human participant identity.
HJS explicitly does not define:
* Legal liability, culpability, fault, negligence, good faith, or
responsibility assignment.
* Authorization validity, delegation validity, permission-chain
correctness, lawful basis, consent validity, or data-subject
rights fulfillment.
* Monitoring mandates, enforcement rules, sanctions, escalation
duties, employment consequences, or penalty procedures.
* Jurisdictional policy, political constraints, regulatory
compliance determinations, procedural fairness, appeal rights,
explanation rights, access rights, disclosure duties, or
evidentiary effect.
* A global identity or trust framework.
* A new cryptographic signature container independent of JEP.
1.4. Minimal Core and Optional Extensions
HJS is infrastructure for creating, binding, exporting, and
validating AI-agent accountability receipts. The HJS core is
intentionally minimal: it defines a JEP-based receipt profile,
behavior-record digest binding, receipt manifests, receipt bundles,
and validation of cryptographic and structural consistency.
All other capabilities, including human privacy modes, participant-
supplied references, post-event review references, explanation-
material references, risk descriptors, model provenance, tool-call
evidence, policy-check evidence, multi-party export, and
cryptographic capability profiles, are optional extensions or
deployment profiles.
HJS extensions provide technical mechanisms only. They do not define
governance rules, fairness, consent, appeal rights, explanation
rights, liability, legal compliance, access rights, disclosure
duties, remedies, sanctions, or evidentiary effect.
The absence of an optional extension MUST NOT be interpreted by the
protocol as agreement, waiver, admission, lack of objection, lack of
harm, absence of relevant context, absence of external rights, or
absence of an available external process.
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, as shown here.
1.6. Terminology
HJS Event:
A JEP event that carries HJS-specific receipt or behavior
semantics.
HJS Behavior Record:
A JSON object describing observable AI-agent behavior evidence. A
behavior record is normally referenced by the JEP what field
through an algorithm-tagged digest string.
HJS Receipt Manifest:
A JSON object that packages references to JEP events, behavior
records, and external evidence needed for cross-platform
validation.
HJS Receipt Bundle:
A collection containing one or more JEP events, associated
behavior records, optional receipt manifests, optional external
evidence, and optional privacy-preserving views.
Human Participant:
A natural person or human-controlled role referenced by an HJS
behavior record. Human participants are not necessarily the JEP
signer.
External Reference:
A digest-bound or otherwise integrity-protected pointer to
externally supplied material. HJS does not define the meaning or
effect of the referenced material.
AI Agent:
A software agent or AI-enabled service whose observable behavior
is recorded by HJS.
Issuer:
The entity identified by the JEP who field and bound to the
signing key under the applicable JEP trust profile.
Deployment Profile:
An external profile that defines local policies, evidence
meanings, privacy handling, export rules, or governance processes
outside the HJS core.
2. HJS Model
2.1. Design Goals
HJS has five design goals:
Machine Evidence Integrity:
HJS binds AI-agent behavior evidence to signed JEP events. Signed
records are tamper-evident, not physically immutable.
Minimal Core:
HJS-Core-1 defines only receipt infrastructure and digest binding.
Capabilities that could imply governance, fairness, access,
explanation, appeal, risk, or disclosure outcomes remain optional
and external.
Human Participant Privacy:
HJS supports pseudonymous, digest-only, rotating, opaque, or
withheld references for human participants. These mechanisms
reduce unnecessary exposure of personal data but do not guarantee
universal anonymity or unlinkability.
Technical Neutrality:
HJS records observable event claims and evidence references. It
does not judge legality, intent, fault, liability, authorization
validity, consent validity, fairness, appeal validity, explanation
sufficiency, or compliance.
Deployment Adaptability:
HJS supports optional evidence profiles for privacy handling,
external references, multi-party export, model descriptors, tool
calls, policy checks, risk classification, and data lifecycle
management.
2.2. Layering
HJS relies on JEP for:
* JEP verbs J, D, T, and V.
* The JEP event object and top-level field definitions.
* Algorithm-tagged digest strings.
* Event hash and ref semantics.
* Detached JWS signatures over JCS-canonicalized unsigned events.
* Key resolution through trust profiles.
* Acceptance validation and archival validation.
* The ext and ext_crit extension container rules.
* JEP cryptographic profile extension semantics.
HJS defines the content and interpretation of HJS behavior records
and HJS receipt manifests. HJS-specific content MUST be carried as
external content referenced by JEP digest strings, as JEP extension
content under ext, or both.
2.3. Infrastructure Positioning
HJS is infrastructure for creating, binding, exporting, and
validating AI-agent accountability receipts. It is not an
accountability tribunal, governance framework, compliance authority,
monitoring mandate, fairness engine, appeal system, explanation-
rights framework, liability determination system, or human-conduct
interpretation system.
HJS can support fairness-oriented or rights-respecting workflows by
allowing deployments to attach, export, and verify relevant evidence
references. HJS does not define fairness, determine whether a process
is fair, prescribe remedies, assign sanctions, define appeal rights,
or determine whether any explanation is sufficient.
2.4. Machine Behavior and Human Participant Identity
HJS distinguishes machine behavior evidence from human participant
identity.
Machine behavior evidence includes observable records such as model
invocations, prompts or prompt digests, outputs or output digests,
tool-call descriptors, policy-check results, decision labels, and
workflow transitions. Such evidence SHOULD be represented in HJS
behavior records and bound to JEP events by digest.
Human participant identity includes natural-person identifiers,
account identifiers, subject identifiers, or role identifiers. Such
identity SHOULD be represented through privacy-preserving references
when possible. The JEP who field identifies the issuer or signer of
the JEP event; HJS implementations MUST NOT overload the JEP who
field to mean "human subject" unless the human participant is also
the JEP event issuer under the applicable trust profile.
2.5. HJS Events, Behavior Records, and Receipts
An HJS event is a JEP event that references an HJS behavior record,
receipt manifest, or validation report. The usual pattern is:
* Create an HJS behavior record describing observable AI-agent
behavior.
* Compute an algorithm-tagged digest string over that behavior
record.
* Place that digest in the JEP what field.
* Add the HJS receipt extension to the JEP ext object.
* Sign the JEP event according to JEP.
* Optionally package the JEP event, behavior record, and evidence
descriptors in an HJS receipt manifest or receipt bundle.
3. HJS-Core-1 Profile
3.1. Required JEP Profile
An implementation conforming to HJS-Core-1 MUST support JEP-Core-1 as
defined by [I-D.wang-jep-judgment-event-protocol].
HJS-Core-1 producers MUST generate HJS events as JEP events. HJS-
Core-1 verifiers MUST perform the appropriate JEP validation mode
before performing HJS-specific validation.
HJS-Core-1 does not define a separate cryptographic algorithm policy.
Cryptographic algorithm support, signature capability,
canonicalization profile, and hash family are inherited from JEP and
any applicable JEP cryptographic profile extension.
3.2. Use of JEP Verbs
HJS uses the JEP verbs as follows:
J (Judge):
Records a decision-related AI-agent behavior event or root receipt
event.
D (Delegate):
Records a delegation-related behavior event, such as delegation of
a task, tool authority, review responsibility, or workflow
segment. HJS does not determine whether the delegation is legally
or operationally valid.
T (Terminate):
Records a termination-related behavior event, such as closure of
an AI-agent task, workflow, audit boundary, or receipt chain. HJS
does not enforce lifecycle closure.
V (Verify):
Records a verification action or verification result concerning a
referenced HJS event, behavior record, receipt manifest, receipt
bundle, or optional external reference.
3.3. JEP who, what, ref, ext, and ext_crit in HJS
The JEP who field identifies the issuer of the HJS event. It is
resolved to a signing key according to the applicable JEP trust
profile. It SHOULD identify an AI agent, AI runtime, operator,
accountability service, organizational issuer, or other signing
authority. It SHOULD NOT contain plaintext personally identifiable
information unless required by the deployment profile and permitted
by applicable policy.
The JEP what field in an HJS event normally contains the algorithm-
tagged digest string of one of the following:
* an HJS behavior record;
* an HJS receipt manifest;
* an HJS validation report;
* another deployment-defined evidence object.
The JEP ref field SHOULD reference the event hash of a related JEP
event when an HJS event participates in a chain. For an HJS V event,
ref SHOULD reference the target JEP event being verified.
HJS-specific extension content MUST be placed under the JEP ext
object using HJS extension identifiers. If an HJS extension is
necessary for interpreting or validating the HJS event, the extension
identifier MUST be listed in ext_crit.
3.4. HJS Receipt Extension
The HJS Receipt Extension identifies a JEP event as carrying HJS
receipt semantics.
Identifier: https://hjs.org/receipt
The extension value is a JSON object. HJS-Core-1 producers SHOULD
include this extension in HJS events. When the extension is required
for validation, producers MUST list it in ext_crit.
Fields:
profile:
The HJS conformance profile. For this document, the value is "HJS-
Core-1".
record_type:
The type of object referenced by the JEP what field. Values
include "hjs-behavior-record", "hjs-receipt-manifest", and "hjs-
validation-report".
record_digest:
The algorithm-tagged digest string of the referenced record. This
value SHOULD equal the JEP what field when the JEP what field is
used for the same object.
media_type:
The media type of the referenced object. The value
"application/json" is used for JSON behavior records and receipt
manifests.
Example:
"ext": {
"https://hjs.org/receipt": {
"profile": "HJS-Core-1",
"record_type": "hjs-behavior-record",
"record_digest": "sha256:3a6eb0790f39ac87c94f3856b2dd2c5d110e6811602261a9a923d3bb23adc8b7",
"media_type": "application/json"
}
},
"ext_crit": ["https://hjs.org/receipt"]
4. HJS Behavior Records
4.1. General Requirements
An HJS behavior record is a JSON object describing observable AI-
agent behavior. When a behavior record is referenced by a JEP event,
the digest in the JEP what field MUST be computed over the behavior
record using the digest rules in Section 4.5.
HJS behavior records SHOULD avoid plaintext personally identifiable
information. Human participant references SHOULD use pseudonymous,
salted digest, opaque, rotating, or withheld identifiers unless a
deployment profile requires direct identifiers.
A behavior record MUST NOT include the event hash of the JEP event
that signs it unless a profile explicitly defines a non-circular
construction. This avoids circular dependencies between the record
digest and the event hash.
4.2. Required Fields
HJS-Core-1 behavior records MUST contain the following fields:
hjs_record:
The HJS behavior record format version. This document defines
value "1".
record_type:
The string "behavior".
agent:
A JSON object describing the AI agent or AI runtime. It MUST
contain an id field. It MAY contain role, deployment_id, or other
profile-defined fields.
action:
A JSON object describing the observed action. It MUST contain a
type field. Examples include "decision", "tool_call",
"delegation", "verification", "termination", "escalation", and
"content_generation".
created_at:
A Unix timestamp in seconds indicating when the behavior record
was created.
evidence:
A JSON object containing evidence descriptors. See Section 4.3.
HJS-Core-1 behavior records MAY contain the following fields:
* model: Model or deployment descriptor.
* policy_checks: Array of policy-check descriptors.
* human_participants: Array of human participant references.
* risk: Risk descriptor.
* context: Deployment-defined context descriptor.
* redaction: Redaction and minimization descriptor.
* external_refs: Deployment-defined references to optional external
materials.
4.3. Evidence Descriptors
Evidence descriptors identify content or metadata that supports audit
or review workflows. HJS evidence descriptors SHOULD be digest-
addressed. A descriptor MAY include a URI, but validation MUST NOT
depend solely on dereferencing the URI.
A descriptor SHOULD contain:
kind:
The kind of evidence, such as "input", "output", "prompt",
"completion", "tool_request", "tool_response", "policy_result", or
"external_context".
digest:
An algorithm-tagged digest string for the evidence object.
media_type:
The media type of the evidence object, if known.
uri:
Optional storage or retrieval location.
redaction:
Optional redaction status, such as "none", "partial", "digest-
only", or "withheld".
4.4. Human Participant References
Human participant references SHOULD be represented as structured
objects rather than as plaintext identifiers in the JEP who field.
A human participant reference MAY contain:
role:
The participant role, such as "user", "reviewer", "operator",
"subject", or "approver".
reference_type:
The identifier type, such as "opaque", "did", "public_key_hash",
"salted_digest", or "withheld".
reference:
The participant reference value. If reference_type is
"salted_digest", the reference SHOULD be an algorithm-tagged
digest string.
privacy_mode:
A value such as "plaintext", "pseudonymous", "rotating", "digest-
only", or "withheld".
salt_holder:
Optional identifier of a salt holder or escrow authority. This
field does not by itself prove that the salt holder is
trustworthy.
HJS does not guarantee that pseudonymous or rotating identifiers are
unlinkable against all observers. Timing, network metadata, device
identifiers, content similarity, or deployment context can create
correlation risks.
4.5. Behavior Record Digest
When an HJS behavior record is a JSON object, its digest is computed
over the UTF-8 octets of the JCS-canonicalized behavior record unless
a deployment profile specifies another canonicalization profile.
The textual digest representation MUST use the algorithm-tagged
digest string format defined by JEP. HJS-Core-1 implementations MUST
support sha256 behavior record digests.
5. HJS Receipt Manifests and Bundles
5.1. Receipt Manifest Structure
An HJS receipt manifest is an optional JSON object that packages the
components needed to validate an HJS receipt bundle. A manifest is
useful when an HJS receipt spans multiple JEP events, behavior
records, external evidence objects, optional external references, or
storage locations.
An HJS-Core-1 receipt manifest SHOULD contain:
hjs_receipt:
Receipt manifest format version. This document defines value "1".
profile:
HJS profile identifier, such as "HJS-Core-1".
root_event:
Event hash of the root JEP event in the receipt bundle.
events:
Array of event descriptors, each containing an event_hash and
optionally a URI or inline event.
records:
Array of behavior record descriptors, each containing a digest,
media_type, and optionally a URI or inline object.
evidence:
Array of external evidence descriptors.
external_refs:
Array of optional participant-supplied, review, correction,
contestation, or explanation-material reference descriptors.
created_at:
Unix timestamp for manifest creation.
The manifest itself MAY be referenced by a JEP event through the JEP
what field. If so, its digest is computed according to the same
behavior record digest rules for JSON objects.
5.2. Receipt Bundle
An HJS receipt bundle is a packaging concept. It MAY contain JEP
events, HJS behavior records, HJS receipt manifests, external
evidence, optional validation reports, and optional external
references. HJS does not define a mandatory archive format in this
version. Deployment profiles MAY define a ZIP, CBOR, JSON, or other
packaging format, provided that JEP event signatures and digest
values remain verifiable without trusting the packaging layer.
5.3. Optional Multi-Party Exportable Receipt Bundles
HJS supports optional exportable receipt bundles. A deployment
profile MAY allow multiple parties to export the same receipt bundle,
different views of the same receipt bundle, or separately signed
receipt fragments. Such exports are technical evidence packages. HJS
does not determine which party is entitled to export, receive, rely
on, disclose, or withhold a receipt bundle.
When multi-party export is used, each exported bundle SHOULD preserve
the verifiability of included JEP event signatures and digest
bindings. Redaction, minimization, and privacy controls MAY be
applied, provided that the remaining digest and signature
relationships are not misrepresented.
HJS does not require all parties to receive identical information.
HJS also does not define procedural fairness, discovery rights,
access rights, evidentiary privilege, confidentiality duties, legal
admissibility, or entitlement to export.
6. HJS Optional Extensions
6.1. Extension Principles
HJS extensions use the JEP ext/ext_crit framework. Unless an
extension is listed in ext_crit, a verifier that does not understand
the extension MAY ignore it according to JEP rules. If an HJS
extension is listed in ext_crit, the verifier MUST understand and
process that extension or reject the event.
HJS extensions provide technical mechanisms for referencing, binding,
exporting, minimizing, or validating external materials. They do not
define the meaning, sufficiency, truth, fairness, legality, moral
character, governance consequence, or evidentiary effect of those
materials.
6.2. Human Participant Privacy Extension
Identifier: https://hjs.org/human
Purpose: Carries privacy-preserving references to human participants
when such references need to be associated with a JEP event itself
rather than only with the HJS behavior record.
Example value:
{
"participants": [
{
"role": "user",
"reference_type": "salted_digest",
"reference": "sha256:8b39f3c7d5e9a1f2aabbccddeeff00112233445566778899aabbccddeeff00",
"privacy_mode": "digest-only",
"salt_holder": "did:example:hjs-escrow"
}
]
}
6.3. Identity Rotation Extension
Identifier: https://hjs.org/identity-rotation
Purpose: Describes rotation of pseudonymous or opaque identifiers
used for human participant references. Fields MAY include
rotation_epoch, previous_reference_digest, next_reference_digest, and
rotation_policy. Identity rotation can reduce linkability but does
not erase previously signed events.
6.4. Participant-Supplied and External Process References
Identifier: https://hjs.org/external-refs
This extension provides a mechanism for attaching integrity-protected
references to externally supplied materials, including participant
statements, correction records, dispute records, post-event review
requests, review materials, explanation requests, explanation
materials, or other deployment-defined records.
These references are technical pointers only. HJS does not define the
content, meaning, sufficiency, truth, legal effect, moral character,
governance consequence, or evidentiary effect of the referenced
materials.
The rel values used by this extension are deployment-defined unless
an external profile gives them additional meaning. HJS does not
assign normative meaning to rel values.
The absence of a participant-supplied reference MUST NOT be
interpreted by the protocol as agreement, waiver, admission, lack of
objection, absence of relevant context, or absence of external
rights.
Example value:
{
"profile": "https://example.org/external-process-profile-v1",
"refs": [
{
"rel": "participant-statement",
"ref": "sha256:aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"
},
{
"rel": "post-event-review-material",
"ref": "sha256:bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb"
}
]
}
6.5. Explanation Material References
Identifier: https://hjs.org/explanation-ref
This extension provides a mechanism for referencing explanation
requests and explanation materials associated with an HJS behavior
record, receipt manifest, receipt bundle, or JEP event.
HJS does not determine whether an explanation is legally required,
who is entitled to receive it, whether the explanation is sufficient,
clear, meaningful, timely, complete, or compliant with any legal,
organizational, human-rights, or governance framework.
An explanation reference proves only the existence of a signed or
digest-bound reference to external material. The interpretation and
legal effect of that material are outside HJS.
Example value:
{
"profile": "https://example.org/explanation-process-v1",
"request_ref": "sha256:cccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccc",
"response_ref": "sha256:dddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd",
"related_behavior_record": "sha256:5555555555555555555555555555555555555555555555555555555555555555",
"redaction_profile": "https://example.org/redaction-profile-v1"
}
6.6. Multi-Party Export Extension
Identifier: https://hjs.org/multiparty-export
Purpose: Describes optional export views or separately signed receipt
fragments for different parties. This extension supports deployments
that provide different privacy-preserving views of the same
underlying receipt bundle.
Fields MAY include export_view, view_digest, redaction_profile,
recipient_ref, fragment_ref, and export_profile. HJS does not define
access rights, disclosure duties, legal admissibility, or entitlement
to export.
6.7. Risk Extension
Identifier: https://hjs.org/risk
Purpose: Carries deployment-defined risk classification metadata.
Fields MAY include level, taxonomy, and rationale_digest. HJS does
not define universal risk semantics. A verifier MUST NOT assume that
risk levels from different taxonomies are equivalent.
6.8. Model Evidence Extension
Identifier: https://hjs.org/model
Purpose: Carries model or deployment descriptors when those
descriptors need to be attached to the JEP event. Fields MAY include
provider, model_id, deployment_id, version_identifier,
model_card_digest, and configuration_digest. HJS does not require
disclosure of proprietary model weights or secrets.
6.9. Tool Call Evidence Extension
Identifier: https://hjs.org/tool-call
Purpose: Carries digest-addressed descriptors for tool calls made by
an AI agent. Fields MAY include tool_name, tool_provider,
request_digest, response_digest, authorization_context_digest, and
result_status. HJS does not determine whether a tool call was
authorized; it records evidence relevant to that question.
6.10. Policy Check Evidence Extension
Identifier: https://hjs.org/policy-check
Purpose: Carries policy-check evidence associated with an AI-agent
behavior event. Fields MAY include policy_id, policy_version, result,
evaluator, rationale_digest, and evidence_digest. HJS does not
determine whether a policy is legally sufficient.
6.11. Use of JEP Cryptographic Profile Extension
HJS implementations MAY use the JEP Cryptographic Profile Extension
to declare issuer-level signature capability, canonicalization
profile, and hash family. HJS does not define a separate
cryptographic capability model.
In particular, post-quantum or composite signature capability is a
property of the issuer, signing identity, trust profile, or
deployment profile. It is not an HJS event type and MUST NOT multiply
the JEP verb set.
7. Validation
7.1. JEP Validation
Before HJS-specific validation, a verifier MUST perform the
applicable JEP validation mode:
* JEP acceptance validation for newly received events.
* JEP archival validation for previously recorded events.
HJS validation MUST NOT treat an event as valid if the underlying JEP
event fails the required JEP validation mode.
7.2. HJS Receipt Validation
To validate an HJS receipt, a verifier MUST:
1. Validate the relevant JEP event or event chain according to JEP.
2. Confirm that the event contains the HJS Receipt Extension or is
otherwise identified by a deployment profile as an HJS event.
3. Confirm that the extension profile is supported.
4. Obtain the referenced behavior record, receipt manifest,
validation report, or other referenced object.
5. Recompute the digest of the referenced object.
6. Confirm that the recomputed digest matches the JEP what field or
the record_digest field in the HJS Receipt Extension, as
applicable.
7. Process all HJS extensions listed in ext_crit.
8. Apply local evidence, trust, privacy, and policy rules.
Successful HJS receipt validation proves that the signed JEP event
and referenced HJS object are cryptographically bound under the
applicable trust profile. It does not prove that the referenced
content is true, complete, legally sufficient, fair, or causally
determinative.
7.3. Behavior Record Validation
A verifier validating an HJS behavior record SHOULD verify:
* Required fields are present.
* The record digest matches the JEP what field or receipt extension.
* Evidence descriptors use valid digest formats.
* Human participant references comply with the deployment privacy
profile.
* Model, tool, policy, and external-reference descriptors are
internally consistent where required by the deployment profile.
HJS behavior record validation is structural and evidentiary. It is
not a legal, forensic, scientific, or human-rights determination that
the recorded behavior is complete or that the underlying AI system
behaved correctly.
7.4. Optional Extension Validation
Optional extension validation is deployment-specific. If an optional
extension is present but not listed in ext_crit, a verifier MAY
ignore it according to JEP rules. If it is listed in ext_crit, the
verifier MUST either process it according to the applicable extension
and deployment profile or reject the event.
Processing an optional extension does not give HJS authority to
determine the legal, moral, governance, or evidentiary effect of that
extension.
7.5. Exported Bundle Validation
A verifier validating an exported HJS receipt bundle SHOULD verify
that each included JEP event signature, event hash, behavior record
digest, manifest digest, and external reference digest remains valid
after any redaction or view generation.
A redacted or partial export MUST NOT misrepresent omitted material
as nonexistent, unchanged, irrelevant, agreed, waived, or verified.
Deployment profiles MAY define redaction notices, withheld markers,
or view descriptors to avoid such misrepresentation.
8. Security and Privacy Considerations
8.1. Signature and Chain Integrity
HJS inherits signature and chain integrity from JEP. HJS signatures
are JEP signatures. HJS does not define an independent signature
string such as "Ed25519:<signature>". Producers MUST use the JEP
signature container and signing input rules.
A valid HJS receipt shows that a valid JEP event was signed by a key
resolved under an applicable trust profile and that the event is
bound to the referenced HJS object by digest. This is a tamper-
evidence property, not a guarantee of physical immutability.
8.2. HJS Does Not Prove Truth, Intent, or Liability
HJS receipt validation proves cryptographic binding and structural
consistency. It does not prove:
* that the behavior record is complete;
* that the AI agent's internal reasoning or subjective motivation
was fully captured;
* that the output was correct;
* that a delegation or tool call was authorized;
* that a human participant consented;
* that a legal duty was satisfied;
* that any party is liable or not liable;
* that a process was fair; or
* that an explanation, review, or appeal material is sufficient.
8.3. Limits of Behavioral Determination under Partial Observation
HJS is designed for audit evidence under partial observation. In many
real systems, logs, traces, explanations, measurements, and receipts
are projections of a larger causal history. Multiple real histories
may be consistent with the same observed log while differing on a
target fact of interest. This structural limitation is discussed in
[TARGET-DETERMINABILITY].
Therefore, HJS supports accountability workflows but does not replace
domain-specific evidence policies, incident response procedures,
scientific validation, forensic methods, human-rights due diligence,
or legal determinations.
8.4. Human Privacy and Linkability
HJS supports pseudonymous, rotating, digest-only, opaque, and
withheld human participant references. These mechanisms can reduce
unnecessary exposure of personal data. They do not guarantee
unlinkability against all observers.
Linkability risks can arise from timing, network metadata, repeated
content, device identifiers, account context, tool-call patterns,
storage locations, or salt reuse. Salted digest schemes are
vulnerable to dictionary attacks when the underlying identifier has
low entropy or the salt is disclosed, reused, or poorly protected.
HJS implementations SHOULD minimize plaintext personal data and
SHOULD use digest-only, pseudonymous, opaque, rotating, or withheld
references where appropriate.
8.5. Participant-Supplied References and Non-Inference
HJS MAY provide mechanisms for attaching, referencing, and verifying
externally supplied materials. These mechanisms preserve a technical
relationship between a receipt and external material; they do not
define the meaning or effect of that material.
HJS does not determine intent, negligence, fault, good faith,
coercion, reasonableness, consent, harm, liability, appeal validity,
explanation sufficiency, or compliance. Such determinations, if any,
are outside the protocol and belong to external legal,
organizational, human-rights, or governance processes.
The absence of a participant-supplied reference MUST NOT be
interpreted by the protocol as agreement, waiver, admission, lack of
objection, lack of harm, absence of relevant context, absence of
external rights, or absence of an available external process.
8.6. Governance Neutrality and Human Rights-Supporting Use
HJS is a technical evidence and receipt profile. It is designed to
support rights-respecting deployments by minimizing unnecessary
exposure of human participant identity and by preserving verifiable
records of AI-agent behavior. HJS does not impose monitoring duties,
prescribe governance outcomes, determine consent validity, assign
liability, define sanctions, or establish legal compliance.
Deployments that use HJS remain responsible for their own human-
rights, privacy, labor, safety, and regulatory obligations. HJS
records can support such processes, but they do not replace human-
rights due diligence, access to remedy, organizational governance, or
legal review.
8.7. Regulatory Support, Not Regulatory Determination
HJS can support regulatory, audit, data-minimization, incident
review, explanation-material reference, and transparency workflows by
providing portable, verifiable evidence. HJS does not determine legal
compliance, lawful basis, data-subject rights fulfillment, consent
validity, audit sufficiency, or liability.
Terms such as "risk", "policy", "review", "approval", "explanation",
"appeal", or "verification" in HJS records are technical descriptors
unless an external legal or organizational framework gives them
additional meaning.
8.8. Model, Tool, and Policy Evidence Limitations
Model identifiers, tool-call descriptors, policy-check records, and
external references can be incomplete, redacted, or deployment-
specific. Verifiers SHOULD evaluate whether referenced evidence is
sufficient for their audit question. A digest of a model descriptor
does not prove that the model behaved as described. A policy-check
result does not prove that the policy is adequate. A tool-call record
does not prove that the tool result is true or safe.
9. IANA Considerations
9.1. HJS Extension Identifier Registrations
This document does not request creation of a separate HJS Extensions
Registry. HJS-specific extensions are intended to be registered in
the JEP Extensions Registry defined by [I-D.wang-jep-judgment-event-
protocol], if that registry is created.
Initial HJS extension identifiers requested for registration are:
* https://hjs.org/receipt
* https://hjs.org/human
* https://hjs.org/identity-rotation
* https://hjs.org/external-refs
* https://hjs.org/explanation-ref
* https://hjs.org/multiparty-export
* https://hjs.org/risk
* https://hjs.org/model
* https://hjs.org/tool-call
* https://hjs.org/policy-check
Extension identifiers are stable identifiers and are not required to
be dereferenceable.
9.2. No Separate HJS Risk Level Registry
This document does not request creation of an HJS Risk Level
Registry. Risk levels are values inside the HJS Risk Extension and
are meaningful only relative to the declared risk taxonomy.
Deployments that require stable risk taxonomies MAY define them in
separate specifications.
10. References
10.1. Normative References
[I-D.wang-jep-judgment-event-protocol]
Wang, Y., "Judgment Event Protocol (JEP): A Minimal Verifiable Log
Format for Agent Decisions", Work in Progress, Internet-Draft,
draft-wang-jep-judgment-event-protocol-05, April 2026.
[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC8174]
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key
Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017,
<https://www.rfc-editor.org/info/rfc8174>.
10.2. Informative References
[TARGET-DETERMINABILITY]
Wang, Y., "Target Determinability under Partial Causal
Observation: A Faithful Reduction Framework", Zenodo, Version v1,
DOI 10.5281/zenodo.19678205, April 2026,
<https://doi.org/10.5281/zenodo.19678205>.
Appendix A. Non-Normative Examples
A.1. HJS Behavior Record Example
The following example is illustrative. Digest values are example
values and are not test vectors.
{
"hjs_record": "1",
"record_type": "behavior",
"agent": {
"id": "did:example:agent-789",
"role": "planner",
"deployment_id": "agent-runtime-42"
},
"created_at": 1743398400,
"action": {
"type": "tool_call",
"name": "calendar.create_event"
},
"model": {
"provider": "example-ai",
"model_id": "example-model-family",
"deployment_id": "example-deployment"
},
"evidence": {
"inputs": [
{
"kind": "prompt",
"digest": "sha256:1111111111111111111111111111111111111111111111111111111111111111",
"media_type": "text/plain",
"redaction": "digest-only"
}
],
"outputs": [
{
"kind": "tool_request",
"digest": "sha256:2222222222222222222222222222222222222222222222222222222222222222",
"media_type": "application/json",
"redaction": "partial"
}
]
},
"policy_checks": [
{
"policy_id": "example-policy-1",
"policy_version": "2026-04",
"result": "pass",
"rationale_digest": "sha256:3333333333333333333333333333333333333333333333333333333333333333"
}
],
"human_participants": [
{
"role": "user",
"reference_type": "salted_digest",
"reference": "sha256:4444444444444444444444444444444444444444444444444444444444444444",
"privacy_mode": "digest-only",
"salt_holder": "did:example:hjs-escrow"
}
],
"risk": {
"level": "medium",
"taxonomy": "hjs-risk-v1"
}
}
A.2. JEP Event Carrying an HJS Receipt Extension
The following example shows a JEP event that references the HJS
behavior record by digest. The sig value is illustrative and
truncated.
{
"jep": "1",
"verb": "J",
"who": "did:example:agent-789",
"when": 1743398400,
"what": "sha256:5555555555555555555555555555555555555555555555555555555555555555",
"nonce": "84d8c175-7b03-4b8d-9d27-1234abcd5678",
"aud": "https://platform.example.com",
"ref": null,
"ext": {
"https://hjs.org/receipt": {
"profile": "HJS-Core-1",
"record_type": "hjs-behavior-record",
"record_digest": "sha256:5555555555555555555555555555555555555555555555555555555555555555",
"media_type": "application/json"
},
"https://hjs.org/risk": {
"level": "medium",
"taxonomy": "hjs-risk-v1"
}
},
"ext_crit": ["https://hjs.org/receipt"],
"sig": "eyJhbGciOiJFZDI1NTE5Iiwia2lkIjoiZGlkOmV4YW1wbGU6YWdlbnQtNzg5I2tleS0xIn0..example-detached-signature"
}
A.3. HJS Receipt Manifest Example
{
"hjs_receipt": "1",
"profile": "HJS-Core-1",
"created_at": 1743398402,
"root_event": "sha256:6666666666666666666666666666666666666666666666666666666666666666",
"events": [
{
"event_hash": "sha256:6666666666666666666666666666666666666666666666666666666666666666",
"uri": "https://evidence.example/events/6666"
}
],
"records": [
{
"digest": "sha256:5555555555555555555555555555555555555555555555555555555555555555",
"media_type": "application/json",
"uri": "https://evidence.example/records/5555"
}
],
"evidence": [],
"external_refs": []
}
A.4. External References and Explanation References Example
{
"https://hjs.org/external-refs": {
"profile": "https://example.org/external-process-profile-v1",
"refs": [
{
"rel": "participant-statement",
"ref": "sha256:aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"
},
{
"rel": "correction-record",
"ref": "sha256:bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb"
}
]
},
"https://hjs.org/explanation-ref": {
"profile": "https://example.org/explanation-process-v1",
"request_ref": "sha256:cccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccc",
"response_ref": "sha256:dddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd",
"related_behavior_record": "sha256:5555555555555555555555555555555555555555555555555555555555555555"
}
}
A.5. Multi-Party Export View Example
{
"https://hjs.org/multiparty-export": {
"export_profile": "https://example.org/export-profile-v1",
"export_view": "participant-redacted-view",
"view_digest": "sha256:eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee",
"redaction_profile": "https://example.org/redaction-profile-v1",
"recipient_ref": "sha256:ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff"
}
}
Appendix B. Changes from draft-wang-hjs-accountability-04
This revision makes the following non-normative structural changes:
* Repositions HJS as a minimal profile of JEP v0.5 rather than a
separate event signing protocol.
* Removes independent HJS definitions of signature syntax,
canonicalization, event hashes, nonce replay handling, and
verification windows. These are inherited from JEP.
* Clarifies that the JEP who field identifies the event issuer, not
necessarily a human participant or decision subject.
* Replaces the prior HJS event model with HJS behavior records, HJS
receipt manifests, and HJS receipt bundles.
* Adds the Minimal Core and Optional Extensions principle.
* Adds participant-supplied and external process references as
optional technical pointers.
* Adds optional explanation-material references without defining
explanation rights or sufficiency.
* Adds optional multi-party exportable receipt bundle support
without defining access rights, disclosure duties, or evidentiary
effect.
* Replaces regulatory compliance claims with regulatory support and
technical neutrality language.
* Adds limits of behavioral determination under partial observation
as an informative security consideration.
* Removes the separate HJS Risk Level Registry request. Risk levels
are now values within the HJS Risk Extension and are interpreted
according to a declared taxonomy.
* Aligns HJS-specific extension handling with the JEP ext/ext_crit
framework.
Author's Address
Yuqiang Wang
Email: signal@humanjudgment.org
URI: https://humanjudgment.org
GitHub: https://github.com/hjs-spec