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判断を採用する前に、事前に定めた条件を必要な証拠に照らして検証し、要求・責任情報・証拠・検証結果・採用状態・状態遷移許可を再検証可能な記録として残すための、アシュアランスと相互運用の共通レイヤーです。The protocol defines
what must travel together.
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 Packets link claims, evidence references, responsible actors, authority, and unverified conditions for the relevant operation.
The verifier records a verification outcome, adoption state, and transition authorization for the specified operation.
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.
Useful for agent and tool interaction. They do not by themselves define adoption conditions or accountability records.
Useful for transport. They do not define evidence semantics, verification outcomes, or transition authorization.
Contain reusable business rules, while Task Requirements Packets bind those rules to a specific operation, evaluation time, and evidence set.
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. |
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.
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.
Functions Implemented and Tested
- 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.
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.
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.
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.