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:". 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, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 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, . 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