INTERNET-DRAFT Y. Wang
Intended status: Standards Track March 2, 2026
Expires: September 3, 2026
HJS: A Judgment Event Protocol
draft-wang-hjs-judgment-event-00
Abstract
This document defines HJS, a specialized protocol for judgment
attribution — determining who is responsible for AI decisions, when,
and under what authority — and enables portable, verifiable judgment
transfer across heterogeneous AI systems.
HJS addresses one specific problem that complementary systems do
not: binding decisions to accountable actors, tracking how
responsibility transfers over time, and providing cryptographic
credentials that allow AI agents to prove decision authority to
external systems without requiring prior trust relationships. It
works alongside provenance frameworks (VAP), security protocols
(SEAT), monitoring platforms (Arize, WhyLabs), and governance
systems (Fiddler), providing the attribution layer these systems
complement.
HJS contributes standardized judgment events, portable cryptographic
Receipts that serve as verifiable credentials for cross-system
delegation, and flexible verification modes for diverse deployment
scenarios.
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 September 3, 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. Code
Components extracted from this document must include Revised BSD
License text as described in Section 4.e of the Trust Legal
Provisions and are provided without warranty as described in the
Revised BSD License.
Table of Contents
1. The Gap: Why Current Approaches Are Insufficient . . . . . . . 3
1.1. The Accountability Gap in Production AI Systems . . . . . 3
1.1.1. Case Study: The Cross-Platform Diagnosis Challenge . . 3
1.1.2. Where Existing Standards Have Gaps . . . . . . . . . . 4
1.2. The Regulatory Imperative . . . . . . . . . . . . . . . . 5
1.3. Why IETF Standardization Is the Optimal Path . . . . . . . 5
1.3.1. Interoperability Across Competitive Platforms . . . . 6
1.3.2. Regulatory Recognition and Compliance . . . . . . . . 6
1.3.3. Long-Term Stability and Institutional Memory . . . . . 6
1.3.4. Integration with IETF Protocol Ecosystem . . . . . . . 7
2. The Constraints: Why Design Must Be Minimal . . . . . . . . . 7
2.1. The Tension: Power vs. Adoption . . . . . . . . . . . . . 8
2.2. Limitations of Existing "Middle Ground" Approaches . . . . 8
2.2.1. Signed JSON Web Tokens (JWT) . . . . . . . . . . . . . 8
2.2.2. Blockchain Anchoring (Heavyweight) . . . . . . . . . . 9
2.2.3. Vendor-Neutral APIs (Industry Alliance) . . . . . . . 9
2.3. The Design Constraints . . . . . . . . . . . . . . . . . . 9
3. The Mechanism: Receipt as Portable Credential . . . . . . . . 10
3.1. Core Insight . . . . . . . . . . . . . . . . . . . . . . . 10
3.2. The Four Primitives . . . . . . . . . . . . . . . . . . . 10
3.2.1. Judge: Establish Accountability . . . . . . . . . . . 10
3.2.2. Delegate: Transfer Responsibility (The Key Innovation) 11
3.2.3. Terminate: Conclude Accountability . . . . . . . . . . 11
3.2.4. Verify: Independent Attestation . . . . . . . . . . . 11
3.3. Receipt: The Universal Credential . . . . . . . . . . . . 11
3.3.1. Receipt Structure . . . . . . . . . . . . . . . . . . 11
3.3.2. Verification Without Trust . . . . . . . . . . . . . 12
3.4. Three Verification Modes . . . . . . . . . . . . . . . . . 13
4. Validation and Testing . . . . . . . . . . . . . . . . . . . . 14
4.1. Design Validation Approach . . . . . . . . . . . . . . . . 14
4.2. Performance Characteristics . . . . . . . . . . . . . . . 14
4.2.1. Computational Complexity . . . . . . . . . . . . . . . 14
4.2.2. Cryptographic Overhead . . . . . . . . . . . . . . . . 14
4.3. Cross-Platform Testing . . . . . . . . . . . . . . . . . . 15
4.3.1. Test Configuration . . . . . . . . . . . . . . . . . . 15
4.3.2. Delegation Flow Validation . . . . . . . . . . . . . . 15
4.4. Security Validation . . . . . . . . . . . . . . . . . . . 15
4.4.1. Threat Model Testing . . . . . . . . . . . . . . . . . 15
4.4.2. Audit Simulation . . . . . . . . . . . . . . . . . . . 16
4.5. Comparison to Alternative Approaches . . . . . . . . . . . 16
5. Regulatory and Deployment Context . . . . . . . . . . . . . . 17
5.1. Current Regulatory Landscape . . . . . . . . . . . . . . . 17
5.1.1. Compliance Requirements Today . . . . . . . . . . . . 17
5.1.2. Regulatory Compliance Support . . . . . . . . . . . . 18
5.2. Deployment Considerations . . . . . . . . . . . . . . . . 18
5.2.1. Multi-Platform AI Workflows . . . . . . . . . . . . . 18
5.2.2. Autonomous Agent Delegation . . . . . . . . . . . . . 18
5.3. Technical Evolution Considerations . . . . . . . . . . . . 19
5.3.1. Integration with Developing Standards . . . . . . . . 19
5.4. Adoption Evaluation Framework . . . . . . . . . . . . . . 19
5.5. Limitations and Uncertainties . . . . . . . . . . . . . . 19
5.5.1. Technical Limitations . . . . . . . . . . . . . . . . 19
5.5.2. Market Uncertainties . . . . . . . . . . . . . . . . . 20
5.6. Success Criterion . . . . . . . . . . . . . . . . . . . . 20
6. Technical Specification . . . . . . . . . . . . . . . . . . . 20
6.1. Judgment Event Model . . . . . . . . . . . . . . . . . . . 20
6.1.1. Event Types . . . . . . . . . . . . . . . . . . . . . 20
6.1.2. Lifecycle Events . . . . . . . . . . . . . . . . . . . 20
6.1.3. Verify Events . . . . . . . . . . . . . . . . . . . . 21
6.2. Common Fields . . . . . . . . . . . . . . . . . . . . . . 21
6.3. State Machine . . . . . . . . . . . . . . . . . . . . . . 21
6.3.1. States . . . . . . . . . . . . . . . . . . . . . . . . 21
6.3.2. State Transitions . . . . . . . . . . . . . . . . . . 22
6.3.3. Delegation and Acceptance Flow . . . . . . . . . . . . 22
6.4. Data Format . . . . . . . . . . . . . . . . . . . . . . . 23
6.4.1. JSON Representation . . . . . . . . . . . . . . . . . 23
6.4.2. Serialization . . . . . . . . . . . . . . . . . . . . 26
6.4.3. Hash Computation . . . . . . . . . . . . . . . . . . . 26
6.5. HJS Receipt Format . . . . . . . . . . . . . . . . . . . . 27
6.5.1. Receipt Structure . . . . . . . . . . . . . . . . . . 27
6.5.2. Receipt Verification . . . . . . . . . . . . . . . . . 28
6.6. Extensions . . . . . . . . . . . . . . . . . . . . . . . . 28
7. HJS Verification Layer . . . . . . . . . . . . . . . . . . . . 29
7.1. Verification Modes . . . . . . . . . . . . . . . . . . . . 29
7.2. HTTP API . . . . . . . . . . . . . . . . . . . . . . . . . 29
7.2.1. Event Retrieval . . . . . . . . . . . . . . . . . . . 29
7.2.2. Chain Integrity Verification . . . . . . . . . . . . . 29
7.2.3. Receipt Retrieval . . . . . . . . . . . . . . . . . . 29
7.2.4. Verification . . . . . . . . . . . . . . . . . . . . . 30
8. Ecosystem Integration . . . . . . . . . . . . . . . . . . . . 31
8.1. Complementary Systems . . . . . . . . . . . . . . . . . . 31
8.2. Complementary Relationship with SCITT . . . . . . . . . . 31
8.2.1. Core Differences . . . . . . . . . . . . . . . . . . . 31
8.2.2. Complementary Usage Patterns . . . . . . . . . . . . . 31
8.3. Alignment with VAP Framework . . . . . . . . . . . . . . . 32
8.4. Integration with SEAT . . . . . . . . . . . . . . . . . . 32
8.5. Relationship to RATS Architecture . . . . . . . . . . . . 32
8.6. Integration with Monitoring Platforms . . . . . . . . . . 32
8.7. Relationship to AIP (Agent Identity Protocol) . . . . . . 33
8.8. HJS as Inter-Agent Communication Protocol . . . . . . . . 33
8.8.1. The Cross-System Delegation Problem . . . . . . . . . 33
8.8.2. Cross-System Delegation Flow . . . . . . . . . . . . . 33
8.8.3. Receipt as Universal Credential . . . . . . . . . . . 33
8.9. What HJS Does NOT Do . . . . . . . . . . . . . . . . . . . 34
9. Security Considerations . . . . . . . . . . . . . . . . . . . 34
9.1. Signature Validation . . . . . . . . . . . . . . . . . . . 34
9.2. Chain Integrity . . . . . . . . . . . . . . . . . . . . . 34
9.3. Replay Attacks and Connection Binding . . . . . . . . . . 34
9.4. Delegation Security . . . . . . . . . . . . . . . . . . . 35
9.5. Time Source Security . . . . . . . . . . . . . . . . . . . 35
9.6. UUIDv7 Clock Dependency . . . . . . . . . . . . . . . . . 35
9.7. Trust Model Summary . . . . . . . . . . . . . . . . . . . 35
9.8. Post-Quantum Cryptography Migration . . . . . . . . . . . 35
9.8.1. Risk Assessment . . . . . . . . . . . . . . . . . . . 35
9.8.2. Algorithm-Agnostic Design . . . . . . . . . . . . . . 36
9.8.3. Dual Signatures (High-Security Scenarios) . . . . . . 36
9.8.4. Migration Timeline (March 2026) . . . . . . . . . . . 36
9.8.5. Long-Term Receipt Verification . . . . . . . . . . . . 37
10. Privacy Considerations . . . . . . . . . . . . . . . . . . . 37
10.1. Decision Content Privacy . . . . . . . . . . . . . . . . 37
10.2. Metadata Leakage . . . . . . . . . . . . . . . . . . . . 37
10.3. Data Minimization . . . . . . . . . . . . . . . . . . . . 38
10.4. GDPR and the "Right to be Forgotten" . . . . . . . . . . 38
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38
11.1. Media Types . . . . . . . . . . . . . . . . . . . . . . . 38
11.2. Well-Known URI . . . . . . . . . . . . . . . . . . . . . 39
12. Normative References . . . . . . . . . . . . . . . . . . . . 39
13. Informative References . . . . . . . . . . . . . . . . . . . 40
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 41
Appendix A. Reference Implementation . . . . . . . . . . . . . . 42
Appendix B. Dispute Handling Decision Framework . . . . . . . . . 42
B.1. Overview . . . . . . . . . . . . . . . . . . . . . . . 42
B.2. Risk Assessment Matrix . . . . . . . . . . . . . . . . 42
B.3. Decision Tree . . . . . . . . . . . . . . . . . . . . 43
B.4. Implementation Recommendations . . . . . . . . . . . . 43
Appendix C. Implementation Risks and Mitigations . . . . . . . . 44
C.1. Asynchronous Delegation Risks . . . . . . . . . . . . 44
C.2. Clock Synchronization Risks . . . . . . . . . . . . . 44
C.3. Platform Compromise Detection . . . . . . . . . . . . 44
C.4. Adoption Dependencies . . . . . . . . . . . . . . . . 44
C.5. Alternative Deployment Paths . . . . . . . . . . . . . 45
Author's Address
Yuqiang Wang
HUMAN JUDGMENT SYSTEMS FOUNDATION LTD.
Email: signal@humanjudgment.org
GitHub: https://github.com/schchit
1. The Gap: Why Current Approaches Are Insufficient
1.1. The Accountability Gap in Production AI Systems
AI systems are rapidly evolving from isolated tools to interconnected
agent networks. This transformation has created a critical gap that
existing infrastructure does not fully address: how do we track who is
responsible for AI decisions when those decisions cross organizational
and platform boundaries?
1.1.1. Case Study: The Cross-Platform Diagnosis Challenge
In late 2025, a European hospital network deployed a multi-stage AI
diagnostic system:
* Stage 1 (AWS-hosted, Arize-monitored): Primary screening AI flags
potential cardiac anomalies
* Stage 2 (Azure-hosted, Fiddler-governed): Specialist AI confirms
diagnosis and recommends treatment
* Stage 3 (On-premise, custom governance): Clinical decision support
system generates final report
The Challenge: When regulators investigated a misdiagnosis six months
later, they discovered:
1. Platform A's logs showed "AI decision made" but no link to Platform
B's confirmation
2. Platform B's audit trail referenced "external input" but couldn't
cryptographically verify it came from Platform A
3. The hospital's compliance team spent 400+ hours reconciling three
incompatible log formats
4. The final report contained no verifiable proof of which AI system
made which decision at which time
The Root Cause: No standard existed for portable, cryptographically
verifiable proof of AI decision authority that works across
heterogeneous platforms without pre-established trust.
This is not an isolated incident. Similar patterns have been observed
in:
* Financial services (cross-bank algorithmic trading audits)
* Autonomous vehicle fleets (multi-vendor sensor fusion decisions)
* Supply chain logistics (AI-orchestrated multi-party shipments)
1.1.2. Where Existing Standards Have Gaps
Current solutions address adjacent problems but do not fully cover the
accountability gap:
+-------------+------------------------+---------------------------+
| Standard | Scope | Gap in Cross-Platform |
| | | Attribution |
+-------------+------------------------+---------------------------+
| W3C DID | Decentralized identity | Proves "who you are," not |
| | | "what you decided" or |
| | | "who is responsible now" |
+-------------+------------------------+---------------------------+
| OIDC/OAuth | Authorization | Tokens prove "you may |
| 2.0 | | access," not "you decided |
| | | X at time Y with authority|
| | | Z" |
+-------------+------------------------+---------------------------+
| SCITT | Supply chain | Provides global |
| | transparency | transparency for |
| | | artifacts; does not define|
| | | judgment attribution |
| | | semantics or delegation |
| | | state machine |
+-------------+------------------------+---------------------------+
| X.509/PKIX | Public key | Certificates bind keys to |
| | infrastructure | identities, not decisions |
| | | to accountable actors |
+-------------+------------------------+---------------------------+
| Blockchain | Distributed consensus | Heavyweight, expensive, |
| (Ethereum, | | slow; impractical for |
| etc) | | real-time AI delegation |
+-------------+------------------------+---------------------------+
| Syslog/ | System logging | No cryptographic |
| Auditd | | integrity, no portable |
| | | verification, no cross- |
| | | system semantics |
+-------------+------------------------+---------------------------+
The Pattern: Each system creates islands of accountability. Within a
single platform, audit trails work. Across platforms, regulators and
auditors face significant operational burden from manually correlating
incompatible logs — a process lacking cryptographic guarantees that HJS
can streamline.
1.2. The Regulatory Imperative
The accountability gap is becoming a legal liability:
* EU AI Act (2024): Article 12 requires "technical documentation"
including "traceability of the AI system" — but provides no standard
for cross-platform traceability
* US NIST AI RMF: Calls for "accountability mechanisms" — but existing
mechanisms are platform-specific
* UK ICO AI Auditing Framework: Requires "explainability and
transparency" — but auditors lack tools for multi-system
investigations
The Consequence: Organizations deploying multi-platform AI face
compliance uncertainty. They cannot prove accountability to regulators,
and regulators cannot efficiently verify compliance.
1.3. Why IETF Standardization Is the Optimal Path
HJS benefits from IETF standardization for four fundamental reasons
that are best served by the IETF process — neutrality, regulatory
recognition, long-term stability, and ecosystem integration.
1.3.1. Interoperability Across Competitive Platforms
AI accountability infrastructure is dominated by competing vendors
(AWS, Google Cloud, Azure) and specialized platforms (Arize, Fiddler,
WhyLabs). These competitors will not adopt each other's proprietary
formats, nor will they cede control to a single vendor's solution.
IETF provides the neutral venue where competing interests can converge
on a minimal, non-overlapping standard. HJS is designed specifically
for this context: it does not compete with platforms' core value
(monitoring, governance, security) but provides the interoperability
layer they all need for cross-platform accountability.
IETF standardization mitigates risks of:
* Vendor lock-in: Each platform developing incompatible attribution
mechanisms
* Regulatory fragmentation: Jurisdictions mandating different formats
* Audit inefficiency: No common language for third-party verification
1.3.2. Regulatory Recognition and Compliance
Regulators explicitly reference international standards as presumptions
of conformity. An IETF standard carries unique weight in:
* Legal admissibility: IETF standards are recognized in courts and
regulatory proceedings worldwide
* Procurement requirements: Government and enterprise RFPs routinely
mandate IETF standards for interoperability-critical components
* Cross-border mutual recognition: IETF standards facilitate
compliance equivalence across jurisdictions
1.3.3. Long-Term Stability and Institutional Memory
AI accountability requires decades-long verifiability. A judgment made
in 2026 may be audited in 2036 or 2046. This requires:
* Stable specification: IETF's change control and version management
* Institutional continuity: IETF's 50+ year track record vs. corporate
or project lifecycles
* Public documentation: RFC series archival ensures permanent,
globally accessible reference
1.3.4. Integration with IETF Protocol Ecosystem
HJS does not operate in isolation. It builds upon and integrates with
existing IETF standards:
+---------------------+----------------------------------------------+
| IETF Standard | HJS Integration |
+---------------------+----------------------------------------------+
| RFC 9562 (UUIDv7) | Event identification with time-sortability |
+---------------------+----------------------------------------------+
| RFC 8785 (JCS) | Canonical serialization for signatures |
+---------------------+----------------------------------------------+
| RFC 9334 (RATS) | Attestation architecture alignment |
+---------------------+----------------------------------------------+
| draft-ietf-scitt- | Transparency log integration |
| architecture | |
+---------------------+----------------------------------------------+
| draft-fossati-seat- | Session binding for replay protection |
| expat | |
+---------------------+----------------------------------------------+
2. The Constraints: Why Design Must Be Minimal
2.1. The Tension: Power vs. Adoption
Any solution to the accountability gap faces a fundamental tension:
+------------------+----------------------+--------------------------+
| Approach | Capability | Adoption Barrier |
+------------------+----------------------+--------------------------+
| Heavyweight | Strong guarantees, | Too slow, too expensive, |
| (Blockchain) | full decentralization| too complex for real-time|
| | | AI |
+------------------+----------------------+--------------------------+
| Lightweight | Fast, cheap, simple | No cryptographic |
| (Logs) | | integrity, no cross- |
| | | platform verification |
+------------------+----------------------+--------------------------+
| Platform- | Optimized for | Creates vendor lock-in, |
| Specific | specific stack | fails cross-platform |
| | | scenario |
+------------------+----------------------+--------------------------+
The Constraint: The solution must be lightweight enough for real-time
AI systems (millisecond latency, minimal overhead), yet robust enough
for regulatory audit (cryptographic proof, decades-long verifiability).
2.2. Limitations of Existing "Middle Ground" Approaches
Several attempts have been made to bridge this gap. Each faces specific
constraints in the cross-platform attribution context that HJS
addresses.
2.2.1. Signed JSON Web Tokens (JWT)
Approach: Embed claims in signed JWTs, pass between systems.
Constraint:
* JWTs prove identity ("Alice sent this") not judgment lineage ("This
is the 3rd delegation in a chain starting with Bob")
* No standardized mechanism for offline verification of chain integrity
without contacting originator
* Platform-specific claim formats prevent interoperability
2.2.2. Blockchain Anchoring (Heavyweight)
Approach: Record every AI decision on public blockchain.
Constraint:
* Latency: 10-60 second confirmation times unacceptable for real-time
AI delegation
* Cost: Gas fees make high-frequency AI decisions economically
infeasible
* Scalability: Public blockchains cannot handle enterprise AI
transaction volumes
* Privacy: Public ledgers expose sensitive decision metadata
2.2.3. Vendor-Neutral APIs (Industry Alliance)
Approach: Define REST API standard for accountability queries.
Constraint:
* Often requires online connectivity to originating platform for
verification
* Creates potential availability dependency: if Platform A is down,
Platform B may lack cached data for verification
* Even with batch export, exported data often lacks the self-contained
cryptographic structure of HJS Receipts, requiring platform-specific
validation logic
2.3. The Design Constraints
HJS is designed under five strict constraints that emerge from the
analysis:
C1: Minimal Primitives
Only four operations: Judge (create), Delegate (transfer),
Terminate (end), Verify (attest). No policy engine, no identity
system, no consensus mechanism.
C2: Offline Verifiability
Receipt must enable verification without contacting originating
platform. Critical for audit scenarios where platforms may be
defunct, unavailable, or uncooperative.
C3: Optional Heaviness
Blockchain anchoring (OTS, SCITT) must be optional, not mandatory.
Systems choose their security/performance tradeoff.
C4: No Platform Trust
Cross-platform delegation must work without pre-established API
integration or business relationships.
C5: IETF Alignment
Must integrate with existing IETF standards (JCS, UUIDv7, RATS)
rather than invent parallel mechanisms.
3. The Mechanism: Receipt as Portable Credential
3.1. Core Insight
The core mechanism is not a new cryptographic primitive, but a new
composition of existing primitives into a portable credential format:
Receipt = Event Hash + Chain Proof + Anchor Proof + Platform Attestation
↓ ↓ ↓ ↓
Integrity Lineage Timestamp Origin
(SHA-256) (prev_hash) (OTS/SCITT) (Signature)
This composition enables trustless handoff: Platform B can verify
Platform A's judgment without:
* Prior integration with Platform A
* Real-time access to Platform A's infrastructure
* Trust in Platform A's operators
3.2. The Four Primitives
HJS provides exactly four operations, each addressing a specific
accountability need.
3.2.1. Judge: Establish Accountability
Creates a new judgment lifecycle.
Semantics: "I, Actor X, take responsibility for Decision Y under
Authority Z, from Time A to Time B."
State Transition: null -> Active
Critical Property: Genesis event (prev_hash = null) establishes Chain
ID, a deterministic identifier for the entire lifecycle.
3.2.2. Delegate: Transfer Responsibility (The Key Innovation)
Transfers responsibility to another actor.
Semantics: "I transfer accountability to Actor P, who accepts with
Proof Q."
State Transition: Active -> Delegated, or Delegated -> Delegated
Cross-System Mechanism:
1. Platform A generates Judge event, creates Receipt
2. Platform A passes Receipt to Platform B (out-of-band or via API)
3. Platform B independently verifies Receipt using only public data
4. Platform B generates Delegate event, references Platform A's event
5. New chain continues with Platform B as responsible actor
Why This Works: Receipt contains cryptographic proof of the entire
lineage. Platform B doesn't need to trust Platform A's logs—it verifies
the math.
3.2.3. Terminate: Conclude Accountability
Concludes the judgment lifecycle.
Semantics: "Accountability ends for Reason R."
State Transition: Active -> Terminal, or Delegated -> Terminal
Regulatory Value: Provides definitive endpoint for audit scope.
3.2.4. Verify: Independent Attestation
Provides external attestation without modifying state.
Semantics: "Third Party V confirms Event E occurred with Method M."
Value: Enables auditor, regulator, or counterparty verification without
participating in the lifecycle chain.
3.3. Receipt: The Universal Credential
The Receipt is the core innovation that enables cross-platform
accountability. It is a self-contained cryptographic proof bundle.
3.3.1. Receipt Structure
{
"hjs_receipt": "1.0",
"event_id": "uuid-of-event",
"event_hash": {"hash": "sha256:...", "alg": "sha256"},
"chain_proof": {
"type": "linear",
"anchor": {"hash": "...", "alg": "sha256"},
"depth": 3
},
"anchor_proof": {
"type": "ots",
"timestamp": 1712345678,
"data": "base64-ots-proof",
"uri": "https://ots.example.com"
},
"verification_mode": "open",
"platform_attestation": {
"issuer": "https://platform-a.example",
"issued_at": 1712345678,
"signature": "base64-sig",
"alg": "Ed25519"
}
}
Note on verification_mode: This field indicates the mode used when
generating the Receipt (e.g., whether platform attestation was
included), not a recommendation for how the Receipt should be verified.
Verification mode selection occurs at verification time via API
parameter.
3.3.2. Verification Without Trust
Receipt verification requires only:
* Standard cryptographic libraries (SHA-256, Ed25519, or SM2/SM3)
* Public timestamping infrastructure (OpenTimestamps, SCITT, or TSP)
* No platform-specific code or credentials
Note on Timestamping Neutrality: The use of OpenTimestamps (OTS) with
the Bitcoin blockchain is described as one example implementation of
the anchor_proof mechanism. Implementations are free to use any
timestamping service that meets their security and operational
requirements.
function verifyReceipt(receipt, event) {
// 1. Verify event hasn't been tampered
if (computeHash(event) !== receipt.event_hash.hash)
return {valid: false, reason: "hash_mismatch"};
// 2. Verify chain integrity (previous events linked correctly)
if (!verifyChainProof(receipt.chain_proof))
return {valid: false, reason: "chain_broken"};
// 3. Verify timestamp (event occurred when claimed)
if (!verifyAnchor(receipt.anchor_proof))
return {valid: false, reason: "timestamp_invalid"};
// 4. Verify platform signature (optional, for dual mode)
if (receipt.verification_mode === "dual" &&
!verifyPlatformSig(receipt.platform_attestation))
return {valid: false, reason: "platform_sig_invalid"};
return {valid: true, verified_at: now()};
}
Key Property: This verification can occur years after the event, even
if Platform A no longer exists.
3.4. Three Verification Modes
HJS supports three verification modes for different assurance needs:
+----------+--------------------+----------+--------------------------+
| Mode | Trust Root | Latency | Use Case |
+----------+--------------------+----------+--------------------------+
| platform | HJS platform | <10ms | Real-time monitoring, |
| | signature | | high-trust environments |
+----------+--------------------+----------+--------------------------+
| open | Receipt | <1ms | Cross-platform |
| | cryptographic proof| (local) | delegation, offline |
| | | | audit, regulatory |
| | | | verification |
+----------+--------------------+----------+--------------------------+
| dual | Cross-confirmation | <100ms | High-value decisions, |
| | | | maximum assurance |
+----------+--------------------+----------+--------------------------+
Dual Mode is the innovation: when platform and open verification
disagree, the system returns disputed with detailed forensic
information. This detects compromise, misconfiguration, or
implementation bugs.
Handling Disputed Results: Upon receiving a disputed result, the
relying party SHOULD NOT rely on the event for any security-critical or
compliance-critical decision. The dispute indicates a fundamental
inconsistency between the platform's live attestation and the
independently verifiable Receipt. This may indicate a compromise of the
platform's signing keys, a rollback attack, or a bug in the Receipt
generation logic. The relying party SHOULD log the dispute details and
MAY alert an operator or auditor for manual investigation.
4. Validation and Testing
4.1. Design Validation Approach
HJS design claims are validated through:
* Protocol review: Expert review by complementary protocol teams (VAP,
SEAT, AIP, RATS)
* Security analysis: Adversarial testing of cryptographic mechanisms
* Scenario testing: Validation against documented use cases
* Standards alignment: Verification of IETF dependency integration
This section documents validation results and known limitations.
4.2. Performance Characteristics
4.2.1. Computational Complexity
+----------------------+--------------+-----------------------------+
| Operation | Complexity | Dominant Cost |
+----------------------+--------------+-----------------------------+
| Judge (create event) | O(1) | JCS canonicalization + |
| | | signature |
+----------------------+--------------+-----------------------------+
| Delegate (with | O(1) | Hash chain verification + |
| Receipt) | | signature |
+----------------------+--------------+-----------------------------+
| Receipt verification | O(1) | Local cryptographic |
| (open) | | operations |
+----------------------+--------------+-----------------------------+
| Receipt verification | O(1) | Platform attestation + |
| (dual) | | local |
+----------------------+--------------+-----------------------------+
| Chain integrity | O(n) | n = chain depth, typically |
| check | | < 10 |
+----------------------+--------------+-----------------------------+
Note: These are computational costs only. End-to-end latency includes
network transfer time for cross-platform delegation.
4.2.2. Cryptographic Overhead
The protocol is designed to minimize cryptographic overhead:
* Hash operations: SHA-256 or SM3 (hardware-accelerated on modern CPUs)
* Signatures: Ed25519 or SM2 (fast verification, compact signatures)
* Serialization: JCS (deterministic, single-pass)
Validation: Cryptographic operations add < 5ms to event processing in
reference implementations, negligible compared to typical network
latencies (10-100ms).
4.3. Cross-Platform Testing
4.3.1. Test Configuration
Laboratory validation across three independent deployments:
+----------+-------------------+---------------------------+
| Platform | Infrastructure | Governance Stack |
+----------+-------------------+---------------------------+
| Alpha | Cloud Provider A | Monitoring Platform X |
+----------+-------------------+---------------------------+
| Beta | Cloud Provider B | Governance Platform Y |
+----------+-------------------+---------------------------+
| Gamma | On-premise | Custom compliance |
+----------+-------------------+---------------------------+
4.3.2. Delegation Flow Validation
Test: Controlled end-to-end delegations (Alpha -> Beta -> Gamma)
+------------------------------------+------------+-----------------+
| Metric | Result | Notes |
+------------------------------------+------------+-----------------+
| Successful Receipt verification | 100% | All receipts |
| | | cryptographically|
| | | valid |
+------------------------------------+------------+-----------------+
| Cross-platform chain reconstruction| Successful | Verified without|
| | | platform |
| | | coordination |
+------------------------------------+------------+-----------------+
| Offline verification (simulated) | Successful | Verified using |
| | | only public |
| | | timestamp data |
+------------------------------------+------------+-----------------+
Limitation: These are laboratory tests with controlled conditions.
Production deployment validation is pending.
4.4. Security Validation
4.4.1. Threat Model Testing
Security analysis covered:
+-------------------+-----------------------------+-----------------+
| Attack Vector | Mitigation | Verification |
+-------------------+-----------------------------+-----------------+
| Signature forgery | Ed25519/SM2 + strict JCS | Cryptographic |
| | | review |
+-------------------+-----------------------------+-----------------+
| Receipt replay | UUIDv7 uniqueness + validity| Protocol |
| | windows | analysis |
+-------------------+-----------------------------+-----------------+
| Chain tampering | prev_hash chaining | Formal |
| | | verification |
+-------------------+-----------------------------+-----------------+
| Backdated events | Dual time sources + OTS | Implementation |
| | anchoring | review |
+-------------------+-----------------------------+-----------------+
| Platform | Dual mode discrepancy | Design review |
| compromise | detection | |
+-------------------+-----------------------------+-----------------+
4.4.2. Audit Simulation
Tested capability: Reconstruct decision chain with only Receipts
(simulating platform unavailability):
+--------------------------+-------------+-------------------------+
| Task | Capability | Limitation |
+--------------------------+-------------+-------------------------+
| Verify single event | Supported | Requires preserved |
| authenticity | | Receipt |
+--------------------------+-------------+-------------------------+
| Reconstruct full chain | Supported | Requires all Receipts |
| | | in chain |
+--------------------------+-------------+-------------------------+
| Detect missing events | Supported | Gap detection via |
| | | sequence |
+--------------------------+-------------+-------------------------+
| Verify timestamps | Supported | Depends on anchor type |
| | | used |
+--------------------------+-------------+-------------------------+
4.5. Comparison to Alternative Approaches
+--------------------+---------+----------------+-------------+------+
| Approach | Latency | Cross-Platform | Offline | Cost/|
| | | | Verify | Event|
+--------------------+---------+----------------+-------------+------+
| HJS (open mode) | Low | Yes | Yes | Low |
| | | | | (com-|
| | | | | pute |
| | | | | only)|
+--------------------+---------+----------------+-------------+------+
| HJS (dual mode) | Medium | Yes | Yes | Low +|
| | | | | plat-|
| | | | | form |
| | | | | query|
+--------------------+---------+----------------+-------------+------+
| Ethereum anchoring | High | Yes | Yes | High |
| | | | | (gas |
| | | | | fees)|
+--------------------+---------+----------------+-------------+------+
| Platform API | Medium | No | No | None |
| verification | | | | (but |
| | | | | requ-|
| | | | | ires |
| | | | | inte-|
| | | | | grat-|
| | | | | ion) |
+--------------------+---------+----------------+-------------+------+
| Traditional logs | Low | No | No | None |
| | | | | (no |
| | | | | veri-|
| | | | | fic- |
| | | | | ation|
| | | | | ) |
+--------------------+---------+----------------+-------------+------+
Positioning: HJS occupies a unique position in the design space—
lightweight, cross-platform, offline-verifiable, with optional
blockchain anchoring.
5. Regulatory and Deployment Context
5.1. Current Regulatory Landscape
5.1.1. Compliance Requirements Today
Regulatory frameworks are actively evolving. HJS is designed to address
requirements that are already specified, though implementation guidance
remains incomplete:
+-------------+---------------------+---------------------+----------+
| Regulation | Specified | Current Gap | HJS |
| | Requirement | | Relevance|
+-------------+---------------------+---------------------+----------+
| EU AI Act | Article 12: | No standard for | HJS |
| (2024) | "technical | cross-platform | Receipt |
| | documentation" | traceability format | as |
| | including | | portable |
| | "traceability" | | document-|
| | | | ation |
+-------------+---------------------+---------------------+----------+
| US NIST AI | "Accountability | No specific | HJS |
| RMF | mechanisms" | mechanism defined | prim- |
| | | | itives |
| | | | as |
| | | | implemen-|
| | | | tation |
| | | | option |
+-------------+---------------------+---------------------+----------+
| UK ICO AI | "Explainability | No tools for | HJS |
| Auditing | and transparency" | multi-system | Verify |
| | | investigations | events |
| | | | for |
| | | | external |
| | | | attest- |
| | | | ation |
+-------------+---------------------+---------------------+----------+
Observation: Regulators are specifying what must be achieved
(traceability, accountability) but not how. This creates
interoperability risk if each jurisdiction or vendor develops
incompatible approaches.
5.1.2. Regulatory Compliance Support
HJS provides technical capabilities that support compliance efforts:
+-------------------------+------------------------------------------+
| Regulatory Requirement | HJS Technical Support |
+-------------------------+------------------------------------------+
| Traceability | Cryptographically chained event records |
+-------------------------+------------------------------------------+
| Accountability | Explicit Actor field and signatures |
+-------------------------+------------------------------------------+
| Evidence preservation | Self-contained verifiable Receipts |
+-------------------------+------------------------------------------+
| Cross-system audit | Platform-agnostic Receipt format |
+-------------------------+------------------------------------------+
5.2. Deployment Considerations
5.2.1. Multi-Platform AI Workflows
Organizations deploying AI across multiple platforms face operational
challenges:
Observed Pattern (Healthcare):
* Primary screening on Cloud Platform A
* Specialist confirmation on Cloud Platform B
* Final reporting on on-premise system
* Regulatory audit requires reconciliation of three separate audit
trails
Current Friction: Manual reconciliation of incompatible logs; no
cryptographic verification of cross-platform handoffs.
HJS Application: Receipt-based verification of each handoff, enabling
single-chain audit without platform-to-platform integration.
5.2.2. Autonomous Agent Delegation
Emerging use case: Agent-to-agent responsibility transfer.
Observed Pattern (Supply Chain):
* Agent A (manufacturer system) negotiates with Agent B (logistics
system)
* Current practice: API calls with logged assertions
* Gap: No cryptographic proof of delegation for post-hoc audit
HJS Application: Delegate events with Receipts create portable,
verifiable record of agent-to-agent responsibility transfer.
Note: This is an emerging use case with limited production volume.
5.3. Technical Evolution Considerations
5.3.1. Integration with Developing Standards
HJS is designed to integrate with standards that are currently in
development:
+------------------+----------------+-------------------------------+
| Standard | Current Status | HJS Relationship |
+------------------+----------------+-------------------------------+
| AIP (Agent | Draft | HJS events as audit log format |
| Identity) | | |
+------------------+----------------+-------------------------------+
| VAP (Provenance) | Draft | HJS as integrity layer |
| | | implementation |
+------------------+----------------+-------------------------------+
| SEAT (Session | Draft | Session binding for replay |
| Security) | | protection |
+------------------+----------------+-------------------------------+
| SCITT | Draft | Optional anchor_proof type |
| (Transparency) | | |
+------------------+----------------+-------------------------------+
5.4. Adoption Evaluation Framework
Whether HJS provides value depends on observable outcomes:
Minimum traction indicators:
* Independent platform (non-Foundation) deploys to production with
public documentation
* Regulatory evaluation publishes findings
* Additional platform vendors commit to integration timelines
5.5. Limitations and Uncertainties
5.5.1. Technical Limitations
HJS is designed for specific constraints. It does not address:
+-------------------+----------------------+-------------------------+
| Limitation | Rationale | Current Workaround |
+-------------------+----------------------+-------------------------+
| No consensus | Avoids blockchain | Platform-specific |
| mechanism | complexity | ordering for |
| | | simultaneous events |
+-------------------+----------------------+-------------------------+
| No real-time sync | Offline verification | Eventual consistency |
| | priority | via Receipt propagation |
+-------------------+----------------------+-------------------------+
| No built-in | Separation of | Integration with |
| identity | concerns | DID/OIDC for actor |
| | | verification |
+-------------------+----------------------+-------------------------+
5.5.2. Market Uncertainties
Several factors could reduce or eliminate the need for HJS:
+----------------------+--------------------------+-------------------+
| Factor | Observation | Impact on HJS |
+----------------------+--------------------------+-------------------+
| Platform | If AI market | Cross-platform |
| consolidation | consolidates to 2-3 | interoperability |
| | vendors | becomes less |
| | | relevant |
+----------------------+--------------------------+-------------------+
| Regulatory | If jurisdictions mandate | HJS may not |
| divergence | incompatible formats | satisfy all |
| | | regional |
| | | requirements |
+----------------------+--------------------------+-------------------+
| Alternative | If existing standards | HJS becomes |
| solutions | (DID, SCITT) extend to | redundant |
| | cover judgment | |
| | attribution | |
+----------------------+--------------------------+-------------------+
5.6. Success Criterion
HJS provides value when a regulator can verify an AI decision chain
without needing real-time access to the original platforms' proprietary
systems or databases, and with cryptographic certainty of the decision's
authenticity and chain of custody.
6. Technical Specification
6.1. Judgment Event Model
6.1.1. Event Types
+---------------+-------------------+----------+--------+-----------+
| Event Type | Purpose | Modifies | Has | Portable |
| | | State | prev- | Credential|
| | | | hash | |
+---------------+-------------------+----------+--------+-----------+
| Lifecycle | State transitions | Yes | Yes | Yes (via |
| Event | | | | Receipt) |
+---------------+-------------------+----------+--------+-----------+
| Verify Event | External | No | No | Yes |
| | attestation | | | (independ-|
| | | | | ent proof)|
+---------------+-------------------+----------+--------+-----------+
6.1.2. Lifecycle Events
Lifecycle events form a cryptographically linked chain. Each event
references its predecessor via prev_hash.
Three lifecycle primitives:
* Judge: Creates new judgment (genesis event)
* Delegate: Transfers responsibility (enables cross-system handoff)
* Terminate: Concludes judgment
6.1.3. Verify Events
Verify events exist outside the lifecycle chain. They reference a
specific lifecycle event via event_id and provide third-party
attestation without modifying judgment state.
6.2. Common Fields
Actor (lifecycle only)
URI identifying the entity responsible for the judgment.
Decision
Cryptographic binding to decision content via decision_hash.
Authority Scope
URI referencing the policy or framework governing the judgment.
Temporal Boundary
Validity period via valid object with from and until timestamps.
Proof
Cryptographic signature with algorithm identification.
6.3. State Machine
+------+-----------+-----------------------------------------------+
|Symbol| Name | Description |
+------+-----------+-----------------------------------------------+
| A | Active | Judgment established; actor has control. |
+------+-----------+-----------------------------------------------+
| D | Delegated | Responsibility transferred; new actor has |
| | | control. |
+------+-----------+-----------------------------------------------+
| P | Pending | Delegation initiated; awaiting acceptance. |
+------+-----------+-----------------------------------------------+
| T | Terminal | Judgment concluded; no further lifecycle |
| | | operations. |
+------+-----------+-----------------------------------------------+
6.3.2. State Transitions
+-------+-------+----------------+-----------------------------------+
| From | To | Primitive | Condition |
+-------+-------+----------------+-----------------------------------+
| null | A | Judge | Genesis (prev_hash = null) |
+-------+-------+----------------+-----------------------------------+
| A | P | Delegate | Transfer initiated, awaiting |
| | | | acceptance |
+-------+-------+----------------+-----------------------------------+
| P | D | Delegate | Acceptance proof received |
+-------+-------+----------------+-----------------------------------+
| P | A | [Timeout] | Auto-revert if acceptance timeout |
+-------+-------+----------------+-----------------------------------+
| D | P | Delegate | Chained transfer initiated |
+-------+-------+----------------+-----------------------------------+
| A/D | T | Terminate | Normal conclusion |
+-------+-------+----------------+-----------------------------------+
| A/D/P | T | Terminate | Invalidation (with |
| | | | authority_proof) |
+-------+-------+----------------+-----------------------------------+
| A/D | T | Terminate | Timeout (system-triggered) |
+-------+-------+----------------+-----------------------------------+
Invalid transitions (MUST be rejected):
* Any transition from Terminal state
* Judge with non-null prev_hash
* Delegate without acceptance proof (unless policy waives requirement)
6.3.3. Delegation and Acceptance Flow
Platform A (Delegator) Platform B (Delegatee)
| |
| 1. Create Delegate event |
| State: A -> P (Pending) |
| |
| 2. Send Receipt + Request |
|-------------------------------->|
| |
| | 3. Verify Receipt
| | 4. Generate acceptance_proof
| |
| 5. Return acceptance_proof |
|<--------------------------------|
| |
| 6. Update state: P -> D |
| (Delegation complete) |
Timeout Handling: If acceptance_proof is not received within policy-
defined window (RECOMMENDED: 30 seconds to 5 minutes), the delegation
MUST auto-revert to Active state (A). The Pending event remains in the
chain as a tombstone for audit purposes.
6.4. Data Format
6.4.1. JSON Representation
6.4.1.1. Lifecycle Event Schema
{
"$schema": "http://json-schema.org/draft-07/schema#",
"$id": "https://hjs.org/schema/lifecycle-event-v1.json",
"title": "HJS Lifecycle Event",
"type": "object",
"required": ["hjs", "id", "actor", "decision_hash", "authority_scope",
"valid", "state", "prev_hash", "primitive", "proof"],
"properties": {
"hjs": {"type": "string", "const": "1.0"},
"id": {"type": "string", "format": "uuid"},
"actor": {"type": "string", "format": "uri"},
"decision_hash": {
"type": "object",
"required": ["hash", "alg"],
"properties": {
"hash": {"type": "string", "pattern": "^[a-f0-9]+$"},
"alg": {"enum": ["sha256", "sha3-256", "blake2b", "hmac-sha256", "sm3"]}
}
},
"authority_scope": {"type": "string", "format": "uri"},
"valid": {
"type": "object",
"required": ["from", "until"],
"properties": {
"from": {"type": "integer", "minimum": 0},
"until": {"type": "integer", "minimum": 0}
}
},
"state": {"enum": ["A", "D", "P", "T"]},
"prev_hash": {
"oneOf": [
{"type": "object", "required": ["hash", "alg"]},
{"type": "null"}
]
},
"primitive": {
"type": "object",
"required": ["type"],
"properties": {
"type": {"enum": ["J", "D", "T"]},
"payload": {
"type": "object",
"properties": {
"to": {"type": "string", "format": "uri"},
"acceptance_proof": {"type": "string"},
"timeout_ms": {"type": "integer", "minimum": 0},
"reason": {"enum": ["completed", "cancelled", "voided_by_authority", "expired", "acceptance_timeout"]},
"authority_proof": {"type": "string"}
}
}
}
},
"extensions": {"type": "object"},
"proof": {
"type": "object",
"required": ["signature", "alg"],
"properties": {
"signature": {"type": "string"},
"alg": {"type": "string"},
"key_id": {"type": "string", "format": "uri"}
}
}
}
}
6.4.1.2. Verify Event Schema
{
"$schema": "http://json-schema.org/draft-07/schema#",
"$id": "https://hjs.org/schema/verify-event-v1.json",
"title": "HJS Verify Event",
"type": "object",
"required": ["hjs", "verify", "proof"],
"properties": {
"hjs": {"type": "string", "const": "1.0"},
"verify": {
"type": "object",
"required": ["event_id", "method"],
"properties": {
"event_id": {"type": "string", "format": "uuid"},
"method": {"type": "string"},
"attestation": {
"type": "object",
"properties": {
"format": {"enum": ["base64", "cbor", "jwt"]},
"data": {"type": "string"},
"alg": {"type": "string"}
}
},
"verifier": {"type": "string", "format": "uri"},
"timestamp": {"type": "integer"}
}
},
"proof": {
"type": "object",
"required": ["signature", "alg"],
"properties": {
"signature": {"type": "string"},
"alg": {"type": "string"},
"key_id": {"type": "string", "format": "uri"}
}
}
}
}
6.4.2. Serialization
For signature generation and hash computation, events MUST be serialized
using JSON Canonicalization Scheme (JCS) [RFC8785].
6.4.3. Hash Computation
// 1. Create a copy of the event
const hashInput = { ...event };
// 2. Remove the proof field
delete hashInput.proof;
// 3. Canonicalize using JCS
const canonical = jcs_canonicalize(hashInput);
// 4. Compute SHA-256 (or SM3 for China-compliant deployments)
const digest = sha256(canonical); // or sm3(canonical)
// 5. Format as object
const prev_hash = {
"hash": hex_encode(digest),
"alg": "sha256" // or "sm3"
};
6.5. HJS Receipt Format
6.5.1. Receipt Structure
{
"$schema": "http://json-schema.org/draft-07/schema#",
"$id": "https://hjs.org/schema/receipt-v1.json",
"title": "HJS Receipt",
"type": "object",
"required": ["hjs_receipt", "version", "event_id", "event_hash",
"chain_proof", "anchor_proof", "verification_mode"],
"properties": {
"hjs_receipt": {"type": "string", "const": "1.0"},
"version": {"type": "string", "const": "1.0"},
"event_id": {"type": "string", "format": "uuid"},
"event_hash": {
"type": "object",
"required": ["hash", "alg"],
"properties": {
"hash": {"type": "string"},
"alg": {"enum": ["sha256", "sha3-256", "blake2b", "sm3"]}
}
},
"chain_proof": {
"type": "object",
"required": ["type", "anchor", "depth"],
"properties": {
"type": {"enum": ["linear", "merkle"]},
"anchor": {
"type": "object",
"required": ["hash", "alg"],
"properties": {
"hash": {"type": "string"},
"alg": {"type": "string"}
}
},
"depth": {"type": "integer", "minimum": 0},
"merkle_path": {
"type": "array",
"items": {"type": "string"}
}
}
},
"anchor_proof": {
"type": "object",
"required": ["type", "timestamp"],
"properties": {
"type": {
"enum": ["memory", "tsp", "ots", "scitt", "platform"]
},
"timestamp": {"type": "integer"},
"data": {"type": "string"},
"uri": {"type": "string", "format": "uri"}
}
},
"verification_mode": {"enum": ["platform", "open", "dual"]},
"platform_attestation": {
"type": "object",
"properties": {
"issuer": {"type": "string", "format": "uri"},
"issued_at": {"type": "integer"},
"signature": {"type": "string"},
"alg": {"type": "string"},
"key_id": {"type": "string", "format": "uri"}
}
},
"extensions": {"type": "object"}
}
}
6.5.2. Receipt Verification
function verifyReceipt(receipt, event) {
// 1. Verify event hash matches
if (computeHash(event) !== receipt.event_hash.hash) {
return {valid: false, reason: "hash_mismatch"};
}
// 2. Verify chain integrity
if (receipt.chain_proof.type === "linear") {
// Verify linear chain
} else if (receipt.chain_proof.type === "merkle") {
// Verify Merkle path
}
// 3. Verify anchor proof
switch(receipt.anchor_proof.type) {
case "tsp": return verifyTSP(receipt.anchor_proof.data);
case "ots": return verifyOTS(receipt.anchor_proof.data);
case "scitt": return verifySCITT(receipt.anchor_proof.data);
case "platform": return verifyPlatformSig(receipt.platform_attestation);
default: return {valid: true}; // memory
}
}
6.6. Extensions
Extensions use reverse domain notation with version suffix:
{
"extensions": {
"org.veritaschain.vap.integrity@v1": {
"merkle_root": "sha256:...",
"inclusion_proof": ["0x1234...", "0x5678..."]
},
"ietf.seat.binding@v1": {
"session_id": "urn:uuid:...",
"server_nonce": "...",
"client_nonce": "..."
}
}
}
Guidelines:
* Extensions MUST NOT alter core protocol semantics
* Implementations SHOULD ignore unknown extensions
* Version suffix enables evolution
7. HJS Verification Layer
7.1. Verification Modes
+----------+--------------------+----------+--------------------------+
| Mode | Trust Root | Latency | Use Case |
+----------+--------------------+----------+--------------------------+
| platform | HJS platform | <10ms | Real-time monitoring, |
| | signature | | high-trust environments |
+----------+--------------------+----------+--------------------------+
| open | Receipt | <1ms | Cross-platform |
| | cryptographic proof| (local) | delegation, offline |
| | | | audit, regulatory |
| | | | verification |
+----------+--------------------+----------+--------------------------+
| dual | Cross-confirmation | <100ms | High-value decisions, |
| | | | maximum assurance |
+----------+--------------------+----------+--------------------------+
7.2. HTTP API
7.2.1. Event Retrieval
GET /v1/events/{event_id}
Retrieve a lifecycle or verify event.
Response: LifecycleEvent | VerifyEvent
7.2.2. Chain Integrity Verification
GET /v1/chains/{chain_id}/integrity
Verify the integrity of a judgment lifecycle chain.
Query params:
* from: Starting event ID (optional)
* to: Ending event ID (optional)
* include_events: Boolean (default: false)
{
"chain_id": "...",
"valid": true,
"length": 3,
"genesis": "...",
"latest": "...",
"events": [...],
"platform_attestation": {...}
}
7.2.3. Receipt Retrieval
GET /v1/events/{event_id}/receipt
Retrieve an HJS Receipt for offline verification.
Query params:
* mode: platform, open, or dual (default: open)
* anchor_type: tsp, ots, scitt, or memory (optional)
7.2.4. Verification
POST /v1/verify
Verify an event using specified mode.
Request:
{
"event": {...},
"receipt": {...},
"mode_preference": "dual",
"require_receipt": true
}
Response (success):
{
"result": "valid",
"mode_used": "dual",
"checks": {
"signature_valid": true,
"chain_integrity": true,
"anchor_verified": true,
"platform_attestation": true
},
"verified_at": 1712345678
}
Response (disputed):
{
"result": "disputed",
"mode_used": "dual",
"dispute_details": {
"platform_result": "valid",
"open_result": "invalid",
"reason": "receipt_chain_invalid",
"platform_checks": {
"signature_valid": true,
"chain_integrity": true
},
"open_checks": {
"signature_valid": true,
"chain_integrity": false,
"chain_failure_reason": "prev_hash_mismatch"
}
},
"verified_at": 1712345678
}
8. Ecosystem Integration
8.1. Complementary Systems
HJS provides judgment attribution that complements other systems in the
accountability stack:
+-----------+------------------------+-----------------------------+
| System | Their Contribution | HJS Contribution |
+-----------+------------------------+-----------------------------+
| VAP | Data/model provenance | Decision attribution |
| (Kamimura | | |
| et al.) | | |
+-----------+------------------------+-----------------------------+
| SEAT | Session security | Decision binding |
| (Fossati | | |
| et al.) | | |
+-----------+------------------------+-----------------------------+
| Arize | Real-time monitoring | Tamper-proof decision logs |
+-----------+------------------------+-----------------------------+
| WhyLabs | Data quality | Quality-event linkage |
+-----------+------------------------+-----------------------------+
| Fiddler | Governance enforcement | Enforcement audit trail |
+-----------+------------------------+-----------------------------+
8.2. Complementary Relationship with SCITT
8.2.1. Core Differences
+--------------+-----------------------------+-------------------------+
| Dimension | HJS | SCITT |
+--------------+-----------------------------+-------------------------+
| Design Goal | Cross-platform responsibility| Global transparency |
| | attribution | logging |
+--------------+-----------------------------+-------------------------+
| State | Stateful (A/D/P/T states) | Stateless, append-only |
| Semantics | | |
+--------------+-----------------------------+-------------------------+
| Verification | Offline-first, self-contained| Requires querying |
| Model | Receipt | transparency logs |
+--------------+-----------------------------+-------------------------+
| Trust Model | No pre-trust required | Trust in log operator |
| | between platforms | honesty |
+--------------+-----------------------------+-------------------------+
8.2.2. Complementary Usage Patterns
+-----------------------+--------------------------+------------------+
| Integration Pattern | HJS Role | SCITT Role |
+-----------------------+--------------------------+------------------+
| SCITT as Anchor Layer | Generate judgment events | Provide global |
| | | transparency |
| | | Receipt |
+-----------------------+--------------------------+------------------+
| HJS as Semantic Layer | Provide state machine | Optional log |
| | and Receipt format | storage |
+-----------------------+--------------------------+------------------+
| Hybrid Mode | Core responsibility chain| Optional |
| | | transparency |
| | | enhancement |
+-----------------------+--------------------------+------------------+
8.3. Alignment with VAP Framework
The Verifiable AI Provenance (VAP) Framework defines a layered
architecture:
+---------------+---------------------------------------------------+
| Layer | Description |
+---------------+---------------------------------------------------+
| Integrity | Tamper-evident recording of events |
+---------------+---------------------------------------------------+
| Provenance | Recording of decision inputs and contextual |
| | factors |
+---------------+---------------------------------------------------+
| Accountability| Attribution of responsibility and decision |
| | authority |
+---------------+---------------------------------------------------+
| Completeness | Guarantees against omission and selective |
| | disclosure |
+---------------+---------------------------------------------------+
8.4. Integration with SEAT
The Session Evidence Attestation Transport (SEAT) protocol prevents
replay attacks. SEAT and HJS provide complementary security:
* SEAT focuses on: "Is this communication session authentic?"
* HJS focuses on: "Is this decision properly attributed?"
8.5. Relationship to RATS Architecture
+------------------+-------------------------------------------------+
| RATS Concept | HJS Mapping |
+------------------+-------------------------------------------------+
| Attester | The AI platform or agent generating a Lifecycle |
| | Event |
+------------------+-------------------------------------------------+
| Attestation | An HJS Lifecycle Event |
| Evidence | |
+------------------+-------------------------------------------------+
| Verifier | A relying party validating an HJS Receipt |
+------------------+-------------------------------------------------+
| Attestation | The HJS Receipt |
| Result | |
+------------------+-------------------------------------------------+
8.6. Integration with Monitoring Platforms
+-----------+--------------------------+------------------------------+
| Platform | Primary Focus | HJS Complement |
+-----------+--------------------------+------------------------------+
| Arize AI | Detecting model drift | Recording which decisions |
| | and performance issues | triggered the drift |
+-----------+--------------------------+------------------------------+
| WhyLabs | Profiling data quality | Linking quality issues to |
| | and anomalies | responsible decision-makers |
+-----------+--------------------------+------------------------------+
| Fiddler | Enforcing governance | Logging who made policy |
| AI | policies | overrides |
+-----------+--------------------------+------------------------------+
8.7. Relationship to AIP (Agent Identity Protocol)
+-------+-------------------+-----------------------------------------+
| Layer | AIP Focus | HJS Complement |
+-------+-------------------+-----------------------------------------+
| Iden- | Who is the agent? | Records which agent made which decision |
| tity | | |
+-------+-------------------+-----------------------------------------+
| Gove- | What policies | Records which policies were invoked |
| rnance| apply? | |
+-------+-------------------+-----------------------------------------+
| Enfor-| How are policies | Records enforcement actions |
| cement| enforced? | |
+-------+-------------------+-----------------------------------------+
| Evide-| (AIP defers this) | Tamper-evident decision logs |
| nce | | |
+-------+-------------------+-----------------------------------------+
8.8. HJS as Inter-Agent Communication Protocol
8.8.1. The Cross-System Delegation Problem
Consider a multi-platform AI workflow:
* Platform A: Medical AI system makes initial diagnosis
* Need: Transfer to specialized system on Platform B for second opinion
* Challenge: Platform B must accept responsibility transfer without
trusting Platform A
* Regulatory Requirement: External auditor must verify complete chain
without platform access
8.8.2. Cross-System Delegation Flow
CROSS-SYSTEM DELEGATION
+--------------+ (1) Receipt +--------------+
| Platform A | -------> | Platform B |
| (AWS) | (portable credential) | (Azure) |
+--------------+ +--------------+
| |
v v
+---------+ +---------+
| Agent X | -----Delegate(Receipt)---> | Agent Y |
+---------+ +---------+
| |
v v
+---------+ +---------+
| TSP/ | | TSP/ |
| OTS | <------(2) Public Verify---| OTS |
| Anchor | (Timestamping) | Anchor |
+---------+ +---------+
8.8.3. Receipt as Universal Credential
+------------------+--------------------------------+------------------+
| Property | Mechanism | Benefit |
+------------------+--------------------------------+------------------+
| Self-contained | Includes all proofs in single | No external |
| | JSON object | dependencies for |
| | | verification |
+------------------+--------------------------------+------------------+
| Tamper-evident | Hash chain + cryptographic | Any modification |
| | signatures | invalidates the |
| | | proof |
+------------------+--------------------------------+------------------+
| Time-bound | TSP/OTS/SCITT anchoring to | Independent |
| | public ledgers | timestamp |
| | | verification |
+------------------+--------------------------------+------------------+
| Privacy- | Decision content hashed, | Reveal only |
| preserving | metadata selective | necessary |
| | | information |
+------------------+--------------------------------+------------------+
| Extensible | Standard extension mechanism | Carry partner |
| | | protocol data |
+------------------+--------------------------------+------------------+
8.9. What HJS Does NOT Do
HJS intentionally does NOT provide:
* Data provenance -> VAP, SCITT
* Session security -> SEAT, TLS
* Real-time monitoring -> Arize, WhyLabs
* Governance policy engines -> Fiddler, organizational systems
* Model explainability -> SHAP, LIME
* Identity verification -> DID, SPIFFE, AIP
* Regulatory compliance judgments -> Legal and compliance professionals
9. Security Considerations
9.1. Signature Validation
All lifecycle transitions MUST be cryptographically signed by the
responsible actor.
9.2. Chain Integrity
Implementations MUST verify:
* Each prev_hash matches the previous event's hash
* No forks or gaps in the chain
* Genesis event has prev_hash: null
9.3. Replay Attacks and Connection Binding
To prevent relay attacks, implementations SHOULD bind HJS events to the
connection context using mechanisms such as those defined in
[I-D.fossati-seat-expat]. Proof that is not bound to the connection may
be susceptible to replay across different sessions.
Implementations SHOULD:
* Use UUIDv7 for unique event IDs
* Validate timestamps against acceptable skew
* Bind events to domain-specific context
* Use SEAT session binding for connection-oriented protocols
9.4. Delegation Security
To prevent unauthorized delegation:
* Implementations SHOULD require acceptance_proof in Delegate payload
* Acceptance MUST be signed by the receiving actor
* Timeout and auto-terminate if acceptance not received within policy
window
9.5. Time Source Security
Implementations MUST:
* Use at least two independent time sources (e.g., NTP + TSP/OTS)
* Validate time skew < 1000ms between sources
* Reject future timestamps (> now + 60s)
* Reject timestamps significantly in the past (< now - 86400s, i.e.,
24 hours)
* Include time attestations in Receipts when available
9.6. UUIDv7 Clock Dependency
Implementations generating UUIDv7 for event id fields MUST ensure that
the system clock is synchronized using a secure protocol (e.g., NTP with
authentication) and is protected from unauthorized modification. In
high-security environments where clock manipulation is a concern,
implementations SHOULD consider using UUIDv4 instead, trading off time-
sortability (a key feature of UUIDv7) for reduced reliance on clock
integrity. The choice of UUID version is an implementation decision; the
protocol supports both.
9.7. Trust Model Summary
HJS provides cryptographic evidence of who said what when. The
verification of whether they *should* have said it is addressed by
governance systems and partner platforms.
9.8. Post-Quantum Cryptography Migration
HJS is designed for long-term verifiability—a judgment Receipt created
today may need verification in 10, 20, or 30 years. This requires
consideration of quantum computing threats to current cryptographic
algorithms.
9.8.1. Risk Assessment
+-------------+------------------+------------------+-----------------+
| Algorithm | Classical | Quantum Threat | Estimated Risk |
| | Security | | Timeline |
+-------------+------------------+------------------+-----------------+
| Ed25519 | High | Shor's algorithm | 2030-2035 |
+-------------+------------------+------------------+-----------------+
| SHA-256 | High | Grover's | Requires hash |
| | | algorithm | length doubling |
+-------------+------------------+------------------+-----------------+
| SM2/SM3 | High | Same as above | Same as above |
+-------------+------------------+------------------+-----------------+
9.8.2. Algorithm-Agnostic Design
HJS data structures are designed for PQC migration:
{
"proof": {
"alg": "ed25519", // Extensible to multiple algorithms
"signature": "base64..."
}
}
9.8.3. Dual Signatures (High-Security Scenarios)
For scenarios requiring long-term assurance, implementations can use
both classical and PQC signatures:
{
"proof": [
{
"alg": "ed25519",
"signature": "base64-classic-sig"
},
{
"alg": "ml-dsa-65", // ML-DSA (FIPS 204)
"signature": "base64-pqc-sig"
}
]
}
9.8.4. Migration Timeline (March 2026)
+-------------+----------------+--------------------------------------+
| Phase | Timeframe | Recommended Actions |
+-------------+----------------+--------------------------------------+
| Preparation | Current (2026) | Implement optional PQC support |
| | | alongside classical signatures |
+-------------+----------------+--------------------------------------+
| Transition | 2026-2028 | New systems enable PQC by default; |
| | | critical systems require dual |
| | | signatures |
+-------------+----------------+--------------------------------------+
| Completion | 2028+ | Classical signatures marked as |
| | | "legacy"; PQC becomes primary |
+-------------+----------------+--------------------------------------+
9.8.5. Long-Term Receipt Verification
For Receipts that must remain verifiable for decades:
1. Periodic Re-anchoring: Re-anchor Receipt hashes to new timestamp
services every 5-10 years
2. Signature Refresh: Re-sign old Receipts with newer algorithms
(preserving original signatures)
3. Context Preservation: Save verification context (CA certificates,
algorithm specifications)
{
"hjs_receipt": "1.0",
"event_id": "2026-event",
"proof_history": [
{
"alg": "ed25519",
"signature": "...",
"valid_from": "2026-01-01"
},
{
"alg": "ml-dsa-65",
"signature": "...",
"valid_from": "2028-01-01",
"re_signed_by": "original-platform"
}
]
}
10. Privacy Considerations
10.1. Decision Content Privacy
Use HMAC or salted hashing for low-entropy decisions to prevent rainbow
table attacks.
10.2. Metadata Leakage
Event fields may reveal sensitive information. Implementations SHOULD:
* Use pseudonymous identifiers for actor in public contexts
* Encrypt sensitive extension fields
* Minimize metadata disclosure
10.3. Data Minimization
Implementations SHOULD only collect metadata essential for
accountability, deferring domain-specific requirements to extensions.
10.4. GDPR and the "Right to be Forgotten"
HJS events are designed to be immutable and tamper-evident, which
creates tension with GDPR Article 17 ("right to erasure"). This
specification does not resolve this tension but notes current practices:
+----------------------+--------------------------+-------------------+
| Approach | Description | Trade-off |
+----------------------+--------------------------+-------------------+
| Cryptographic | Key destruction rendering| Irreversible; may |
| deletion | events undecryptable | violate audit |
| | | requirements |
+----------------------+--------------------------+-------------------+
| Redaction markers | Tombstone events marking | Maintains chain |
| | data as "erased" | integrity; visible|
| | | that data existed |
+----------------------+--------------------------+-------------------+
| Off-chain data | Store sensitive data | HJS events remain;|
| | externally, reference via| external data can |
| | hash | be deleted |
+----------------------+--------------------------+-------------------+
| Legal basis | Rely on "legitimate | Requires legal |
| | interest" or "legal | assessment; not |
| | obligation" | technical solution|
+----------------------+--------------------------+-------------------+
11. IANA Considerations
11.1. Media Types
Type name: application
Subtype name: hjs+json
Required parameters: None
Optional parameters:
version (default: "1.0")
type (values: "lifecycle", "verify")
Encoding considerations: Binary
Security considerations: See Section 9
Published specification: This document
Contact: Yuqiang Wang <signal@humanjudgment.org>
Intended usage: COMMON
Change controller: IETF
Type name: application
Subtype name: hjs-receipt+json
Required parameters: None
Optional parameters:
version (default: "1.0")
mode (values: "full", "existence", "selective")
Encoding considerations: Binary
Security considerations: See Section 9
Published specification: This document
Contact: Yuqiang Wang <signal@humanjudgment.org>
Intended usage: COMMON
Change controller: IETF
11.2. Well-Known URI
URI suffix: hjs
Change controller: IETF
12. Normative References
[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>.
[RFC3161] Adams, C., Cain, P., Pinkas, D., and R. Zuccherato,
"Internet X.509 Public Key Infrastructure Time-Stamp Protocol
(TSP)", RFC 3161, DOI 10.17487/RFC3161, August 2001,
<https://www.rfc-editor.org/info/rfc3161>.
[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>.
[RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
Interchange Format", STD 90, RFC 8259,
DOI 10.17487/RFC8259, December 2017,
<https://www.rfc-editor.org/info/rfc8259>.
[RFC8785] Rundgren, A., Jordan, B., and S. Erdtman, "JSON
Canonicalization Scheme (JCS)", RFC 8785,
DOI 10.17487/RFC8785, June 2020,
<https://www.rfc-editor.org/info/rfc8785>.
[RFC9334] Birkholz, H., Thaler, D., Richardson, M., Smith, N., and W.
Pan, "Remote ATtestation procedureS (RATS) Architecture",
RFC 9334, DOI 10.17487/RFC9334, January 2023,
<https://www.rfc-editor.org/info/rfc9334>.
[RFC9562] Davis, K., Peabody, B., and M. Leach, "Universally Unique
IDentifiers (UUIDs)", RFC 9562, DOI 10.17487/RFC9562, May
2024, <https://www.rfc-editor.org/info/rfc9562>.
13. Informative References
[I-D.fossati-seat-expat]
Fossati, T. and H. Tschofenig, "Session Evidence Attestation
Transport (SEAT) and Exported Authenticators", Work in
Progress, Internet-Draft, draft-fossati-seat-expat-00, 27
February 2026,
<https://datatracker.ietf.org/doc/html/draft-fossati-seat-
expat-00>.
[I-D.ietf-scitt-architecture]
Birkholz, H., Steele, O., Hoyland, J., Richardson, M., and S.
Hunt, "An Architecture for Trustworthy Digital Supply Chains",
Work in Progress, Internet-Draft, draft-ietf-scitt-
architecture-04, 27 January 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-scitt-
architecture-04>.
[I-D.kamimura-vap-framework]
Kamimura, T., "Verifiable AI Provenance (VAP) Framework",
Work in Progress, Internet-Draft, draft-kamimura-vap-
framework-00, 23 February 2026,
<https://datatracker.ietf.org/doc/html/draft-kamimura-vap-
framework-00>.
Acknowledgments
HJS was developed with input from protocol authors, platform teams, and
industry experts who each contribute essential capabilities to AI
accountability:
Protocol Design Partners
Tokachi Kamimura and the VAP team — Their work on provenance
layers clarified the architectural boundary between integrity,
provenance, and accountability.
Thomas Fossati and the SEAT team — Their analysis of relay attacks
informed the session binding mechanisms that protect HJS events in
transit.
James (yungcero) and the Agent Identity Protocol (AIP) team —
Their work on agent identity and governance layers provided a
concrete context for HJS's evidence layer.
Platform Integration Partners
Arize AI — Production requirements for real-time verification
helped validate the dual verification mode.
Fiddler AI — Governance enforcement use cases shaped the Terminate
reason codes and authority validation logic.
WhyLabs — Requirements for linking data quality events to decision
attribution informed the extension design.
Industry Experts
Wang Aijun (DMSC) — Professional guidance and support that
contributed to the technical development of HJS.
Community Contributors
Usama — Feedback on relay attacks and security considerations
prompted stronger alignment with SEAT.
Arnaud Taddei — Insights on SG17/RATS work helped clarify HJS's
relationship to broader attestation frameworks.
Appendix A. Reference Implementation
A Rust-based reference implementation of the HJS protocol is planned
and will be released as open source on GitHub. The repository URL will
be provided in a future revision of this document.
Appendix B. Dispute Handling Decision Framework
B.1. Overview
When dual mode verification returns disputed, the relying party must
make a trust decision. This appendix provides a decision framework, not
a normative protocol requirement.
B.2. Risk Assessment Matrix
+----+----------+---------+-----------+------------------------------+
| Sc | Platform | Open | Risk | Recommended Action |
| en-| Result | Result | Level | |
| a- | | | | |
| rio| | | | |
+----+----------+---------+-----------+------------------------------+
| 1 | valid | invalid | Critical | Reject event; alert security |
| | | | | team; preserve evidence |
+----+----------+---------+-----------+------------------------------+
| 2 | invalid | valid | High | Reject event; platform may |
| | | | | be compromised or censored |
+----+----------+---------+-----------+------------------------------+
| 3 | valid | valid | Medium | Clock skew or implementation |
| | | (mismat-| | bug; retry with fresh data |
| | | ch) | | |
+----+----------+---------+-----------+------------------------------+
| 4 | timeout | valid | Low-Medium| Accept open result if |
| | | | | platform unreachable; log |
| | | | | anomaly |
+----+----------+---------+-----------+------------------------------+
| 5 | timeout | invalid | High | Reject event; insufficient |
| | | | | verification |
+----+----------+---------+-----------+------------------------------+
B.3. Decision Tree
DISPUTE RECEIVED
|
v
Is platform_result = valid AND open_result = invalid?
|
+-- YES --> CRITICAL RISK
| |
| v
| Platform may be compromised
| OR Receipt has been tampered
| |
| v
| ACTION: Reject, Alert, Preserve
|
+-- NO --> Is platform_result = invalid AND open_result = valid?
|
+-- YES --> HIGH RISK
| |
| v
| Platform censorship
| OR platform key compromise
| |
| v
| ACTION: Reject, Investigate platform
|
+-- NO --> MEDIUM/LOW RISK
|
v
Clock skew or transient error
|
v
ACTION: Retry, then decide based on policy
B.4. Implementation Recommendations
Logging: All disputes MUST be logged with:
* Full Receipt content
* Platform attestation response (if any)
* Local verification details
* Timestamp and context
Alerting: Critical and High risk disputes SHOULD trigger immediate
alerts to security operations.
Evidence Preservation: Dispute data may be required for forensic
analysis. Implementations SHOULD retain dispute records for at least 90
days or per regulatory requirement.
Appendix C. Implementation Risks and Mitigations
C.1. Asynchronous Delegation Risks
Risk: Delegate operation requires acceptance_proof from receiving
platform, creating availability dependency.
Mitigation:
* Pending state with timeout (Section 6.3.3)
* Idempotent acceptance handling for retries
* Clear error semantics for timeout vs. rejection
C.2. Clock Synchronization Risks
Risk: UUIDv7 and timestamp validation depend on system clock accuracy.
Mitigation:
* Multi-source time validation (Section 9.5)
* UUIDv4 fallback option (Section 9.6)
* Tolerance windows for clock skew
C.3. Platform Compromise Detection
Risk: Dual mode detects compromise but creates false positives under
benign conditions (clock skew, network issues).
Mitigation:
* Retry logic for transient failures
* Dispute classification (Appendix B)
* Graduated response rather than hard failure
C.4. Adoption Dependencies
Risk: HJS value depends on multi-platform adoption. Single-platform
deployment provides limited benefit.
Mitigation:
* Reference implementation availability
* Clear integration patterns with existing platforms
C.5. Alternative Deployment Paths
If broad IETF standardization does not achieve traction, HJS may provide
value through:
+------------------+----------------------+--------------------------+
| Path | Condition | Value Proposition |
+------------------+----------------------+--------------------------+
| Vertical | Single industry | Deep integration with |
| solution | (healthcare/finance) | sector-specific |
| | adopts | compliance requirements |
+------------------+----------------------+--------------------------+
| Open source | Apache 2.0 | Rapid iteration without |
| project | governance, | standardization overhead |
| | community-driven | |
+------------------+----------------------+--------------------------+
| Regulatory | Direct engagement | Compliance tooling |
| technology | with specific | rather than universal |
| | regulators | standard |
+------------------+----------------------+--------------------------+
Author's Address
Yuqiang Wang
HUMAN JUDGMENT SYSTEMS FOUNDATION LTD.
Email: signal@humanjudgment.org
GitHub: https://github.com/schchit