HAAP / Non-Normative Technical Overview
Hiroshima AI Assurance
Protocol
in one sentence.
HAAP is a proposed assurance and interoperability layer that enables organizations to formally adopt an AI-assisted decision only after predefined conditions have been verified against the required evidence, while preserving the requirements, accountability-relevant information, evidence, verification results, adoption state, and transition authorization as a verifiable record.
AI判断を採用する前に、事前に定めた条件を必要な証拠に照らして検証し、要求・責任情報・証拠・検証結果・採用状態・状態遷移許可を再検証可能な記録として残すための、アシュアランスと相互運用の共通レイヤーです。
This page presents the current non-normative HAAP model. A future normative specification will define the wire format, mandatory fields, signing policy, trust anchors, error handling, and interoperability requirements.
A
Business Profile
Business Rules
B
HAAP Assurance and
Interoperability Layer
Assurance Records
C
A2A / MCP
Agent and Tool Protocols
D
HTTP / gRPC
Transport Protocols
3-Line Summary
The protocol defines
what must travel together.
Task Requirements Packet
What must be true for this operation?
A Task Requirements Packet binds the target operation, applicable profile and ruleset versions, evidence requirements, thresholds, authority, evaluation time, validity window, and permitted tolerances.
Accountability-Relevant Information Packet
What accountability-relevant information and evidence are available?
Accountability-Relevant Information Packets link claims, evidence references, responsible actors, authority, and unverified conditions for the relevant operation.
Verification and Authorization
What state transition is permitted?
The verifier records a verification outcome, adoption state, and transition authorization for the specified operation.
Position
A proposed layer for
making AI-assisted decisions formally adoptable.
Transport protocols move messages. Agent and tool protocols connect systems and capabilities. HAAP addresses what they do not: whether an AI-assisted decision meets the predefined conditions and required evidence needed to be formally adopted as an organizational decision.
01
Agent2Agent (A2A) / Model Context Protocol (MCP)
Useful for agent and tool interaction. They do not by themselves define adoption conditions or accountability records.
02
HTTP / gRPC
Useful for transport. They do not define evidence semantics, verification outcomes, or transition authorization.
03
Business profiles
Contain reusable business rules, while Task Requirements Packets bind those rules to a specific operation, evaluation time, and evidence set.
Protocol Records and Messages
Proposed protocol records
and their distinct functions.
Each record category serves a distinct function in the assurance lifecycle. The PoC column shows which functions have been exercised through completed proof-of-concept projects.
"Functional precursor exercised" means that a comparable function was implemented in the Phase 1 reference PoC. It does not mean that the current HAAP record category, serialization, signature model, or domain-independent state separation was implemented.
CATEGORY
Phase 1 Evidence
Purpose
Capability Declaration
Not exercised
Exchange supported profiles, evidence formats, and signing methods.
Task Requirements Packet
Functional precursor exercised: profile and charter binding
Bind the target operation, applicable profile and ruleset versions, adoption conditions, evidence requirements, evaluation criteria, and validity window.
Accountability-Relevant
Information Packet
Not exercised
Submit responsibility scope, execution capability, claims, and evidence references for the relevant actor or system.
Evidence Package
Functional precursor exercised: input and evidence fields
Provide evidence fields for verification, under trust requirements defined by the applicable profile.
Verification Result
Functional precursor exercised: recalculated metrics and disposition
Record recalculated values, missing evidence, satisfied conditions, and result digest.
Adoption State Record
Not implemented as a HAAP record
Assign a domain-independent adoption state from the verification result and applicable profile rules.
Transition Authorization
Functional precursor only: RELEASE continues; non-RELEASE halts
Record whether the specified state transition is AUTHORIZED, REQUIRES_REVIEW, or NOT_AUTHORIZED.
Transition Receipt
Not exercised
Record the actual state change after execution.
Status Update
Not exercised
Record expiry, revocation, supersession, or evidence updates as append-only entries.
State Separation
Do not collapse
verification, adoption, and authorization.
Verification outcome: SATISFIED, UNSATISFIED, or INDETERMINATE.
Adoption state: ADOPTABLE, CONDITIONALLY_ADOPTABLE, NOT_ADOPTABLE, or PENDING_EVIDENCE.
Transition authorization: AUTHORIZED, REQUIRES_REVIEW, or NOT_AUTHORIZED.
Accountability-Relevant Information is preserved inside the Accountability-Relevant Information Packet: who confirmed what, who remains responsible, which conditions remain unverified, and which state transition the record concerns.
AUTHORIZED is a protocol-level state for a specified operation. It does not create legal, regulatory, contractual, safety, or organizational authority that did not otherwise exist.
Reference PoC-01 | Pharmaceutical Cold-Chain Handoff — Phase 1
Functional precursors:
implemented and tested.
This Phase 1 reference PoC exercised functional precursors that inform HAAP in a pharmaceutical cold-chain handoff scenario. It did not implement the current HAAP record schema or domain-independent state separation.
Agent2Agent (A2A) / Model Context Protocol (MCP)
Profile and ruleset binding through cryptographic digests.
Inspection of custody, seal, logger-calibration, and temperature-record evidence.
Independent recalculation of temperature-excursion metrics.
Generation of Logistics Profile dispositions: RELEASE, HOLD, QA_REVIEW, or REJECT.
Chain-stop control and last-good / first-fail investigation anchors.
Deterministic replay and certificate verification.
Not Covered by This PoC
The normative HAAP record schema and serialization format.
Domain-independent Adoption State Records.
Separate HAAP Transition Authorization records.
Sensor and evidence-source authenticity.
Production-system or cross-company API integration.
Multi-implementation interoperability.
RELEASE, HOLD, QA_REVIEW, and REJECT are domain-specific operational dispositions defined by the Logistics Profile. They do not replace HAAP’s domain-independent verification outcomes, adoption states, or transition-authorization states.
View Implementation on GitHub
Reference Implementation-02 | Evaluation OS — Claim-to-Evidence Evaluation
Evaluation-assurance precursors:
implemented and tested.
This public reference implementation exercised functional precursors that inform HAAP when the object to be assured is an evaluation itself. It did not implement the current HAAP record schema, prospective temporal blind commitment, or an independent third-party audit.
Functions Implemented and Tested
Evaluation Charter and source-universe binding
through cryptographic digests.
Investigation-sufficiency gating
before numerical finality.
Declared review of uncontrolled sources
and adverse-evidence candidates.
Interval treatment
of evidence uncertainty.
Closure across admissible mappings,
weights, and decision thresholds.
Deterministic replay
and certificate verification.
Not Covered by This Implementation
The normative HAAP record schema
and serialization format.
Prospective temporal
blind commitment.
Independent verification of
public-source truth or authenticity.
Fully automated assignment
of evidence intervals.
Independent third-party audit
of ONZALINX.
Production-system or
multi-implementation interoperability.
ROBUST is an implementation-specific result meaning that the conclusion remained invariant within the declared evaluation universe. It does not certify source truth or company performance, and it does not replace HAAP’s domain-independent verification outcomes, adoption states, or transition-authorization states.
View Implementation on GitHub
Technical Evidence
Public technical materials
enable independent inspection.
The Council publishes formal foundations, verification materials, and completed PoC results so that the technical basis, implemented scope, and known limitations can be independently examined.
Lean 4 formalization of evidence preservation, responsibility traces, and inspectability under composed operations.
Responsibility OS Kernel
Lean 4 formalization of policy-relevant responsibility preservation and faithful inspectability.
Completed and ongoing proof-of-concept projects, including implementation scope, test results, and known limitations.
The linked Lean repositories formalize mathematical structures supporting HAAP. They do not, by themselves, establish the safety, regulatory compliance, or correctness of any real-world deployment.
Contribute
Review, validate,
or propose a new PoC.
HAAP deepens as new proof-of-concept projects test additional requirements, verification methods, and record formats. Contributions to review and new PoC proposals are welcome.