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
Reference PoC-03 | Civic AI Answer Adoption Assurance
Answer-adoption precursors:
implemented and tested.
Joint PoC conducted by Crowdsien Inc. and AI Assurance, Inc., this public reference PoC tested the adoption of AI-generated answer candidates against predefined conditions and evidence in synthetic municipal scenarios. The implementation also evaluated 24 recorded OpenAI API responses. It does not implement HAAP's proposed protocol records.
Functions Implemented and Tested
Binding of adoption conditions and source versions to fixed requirements.
Inspection of municipality, eligibility, amounts, citations, and claim-to-evidence consistency.
PASS / HOLD / REJECT gating before answer candidates are released for staff review.
Recalculation and integrity checking of saved decision records.
Evaluation of 24 recorded AI-generated answers under predefined criteria.
Lean 4 model proof checks (45 theorems) and implementation comparisons.
Not Covered by This PoC
Normative HAAP record serialization and signing.
Separate domain-independent Adoption State and Transition Authorization records.
Authenticity or legal validity of real municipal source materials.
General natural-language accuracy or actual administrative decisions.
Production deployment or multi-implementation interoperability.
PASS means that an answer candidate satisfies the PoC's predefined conditions for staff review. It does not establish benefit eligibility, administrative approval, or a HAAP adoption state.
View Implementation on GitHub
Reference PoC-04 | Civic AI Privacy Assurance
Privacy-assurance precursors:
implemented and tested.
Joint PoC conducted by Crowdsien Inc. and AI Assurance, Inc., this public reference PoC tested disclosure controls before simulated AI processing and separate checks before output adoption. All resident information, recipients, and processing conditions are synthetic.
Functions Implemented and Tested
Inspection of purpose, authority, destination, and permitted information fields.
Data minimization before simulated disclosure.
Sequential tracking of cumulative disclosure under fixed test constraints.
Separate gating of simulated transmission and output adoption.
Detection of predefined identifiers reintroduced into simulated outputs.
Record replay, implementation comparisons, and Lean 4 model proof checks (55 theorems).
Not Covered by This Implementation
Real resident-data processing or external AI transmission.
General personal-data detection or anonymization.
Legal privacy compliance or quantitative re-identification-risk assessment.
Persistent cross-system disclosure tracking and production authorization.
Normative HAAP records or multi-implementation interoperability.
The cumulative disclosure score is a synthetic test constraint, not a measured privacy risk. PASS, HOLD, and REJECT are PoC-specific control results, not HAAP adoption or transition-authorization states.
View Implementation on GitHub
Reference PoC-05 | Civic AI Derived-Information Lifecycle Assurance
Lifecycle-assurance precursors:
implemented and tested.
Joint PoC conducted by Crowdsien Inc. and AI Assurance, Inc., this public reference PoC tested how usage restrictions attached to source information are preserved through AI-generated derivatives, subsequent use, conditional changes, and termination. A separate experiment also tested a recorded OpenAI API output through 16 lifecycle operations.
Agent2Agent (A2A) / Model Context Protocol (MCP)
Origin-specific inheritance of usage conditions and audit obligations.
Purpose- and authority-based gating of downstream information use.
Scoped changes to permissions without removing unrelated source restrictions.
Detection of remaining copies and unresolved operations before termination.
Revalidation of termination evidence after changes in state or generation.
Deterministic history replay and Lean 4 model proof checks (70 theorems).
Not Covered by This PoC
Discovery or deletion of unmanaged copies.
External AI-provider retention or physical data erasure.
Authentication of real approvers or legal authority.
Production-wide enforcement or distributed transaction control.
Normative HAAP records or multi-implementation interoperability.
Termination is verified only for the local usage paths tracked by this reference implementation. It does not prove deletion of all copies or replace HAAP's domain-independent verification, adoption, or authorization states.
View Implementation on GitHub
Reference Implementation-06 | Integrated Civic AI Assurance — Gennai API Format
Cross-stage assurance precursors:
implemented and tested.
Joint PoC conducted by Crowdsien Inc. and AI Assurance, Inc. This public reference implementation connects the three existing civic-assurance engines without modifying their original decision logic. It links pre-disclosure checks, answer adoption, and subsequent use for the same synthetic case and answer. The interface targets selected synchronous fields of the publicly documented Gennai OSS API format; connection to a running Gennai environment has not been tested.
Functions Implemented and Tested
Integration of three existing assurance engines under a common synthetic profile.
Pre-call blocking and answer-adoption gating within a connected workflow.
Binding of the evaluated answer text to subsequent usage conditions.
Execution and deterministic replay of 31 synthetic integration scenarios.
Local HTTP request / response handling using selected Gennai synchronous API fields.
Lean 4 integration-model proof checks (18 theorems) and a separate 24-case OpenAI API experiment.
Not Covered by This Implementation
Verified operation in a running Gennai OSS or government environment.
Asynchronous APIs, file handling, or future-version compatibility.
Real resident-data processing or production administrative deployment.
Normative HAAP records and domain-independent state separation.
Production-grade security or multi-implementation interoperability.
Independent replay of the real-AI experiment from the published aggregate alone.
The 31 synthetic integration records are publicly replayable. In the separate real-AI experiment, 18 responses were evaluated and six requests were stopped before an API call. The public aggregate is not a substitute for the retained original evidence. Neither result establishes government approval or operational integration with Gennai.
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.
Independent Technical Demonstration | Cold-Chain Cyber Assurance | AI Assurance, Inc.
Execution-control precursors:
implemented and tested.
Developed solely by AI Assurance, Inc., this public technical demonstration tested execution-control functions for a simulated cold-chain handoff. It examined predefined conditions, authorization status, evidence availability, execution-stage changes, and outcome verification through formal proofs and reproducible tests. It is not a joint Council PoC and does not implement HAAP's proposed protocol records or domain-independent state separation.
Functions Implemented and Tested
Pre-execution and execution-stage checks of quality status, receiver authorization, evidence conditions, and upstream holds, with rejection or HOLD when requirements are not satisfied.
Recovery from HOLD after missing records are supplied, allowing valid simulated operations to proceed.
Lean 4 proof of at-most-once simulated effects across arbitrary-length sequential operations within the retained abstract state.
Post-execution quarantine of result mismatches without incorrectly confirming successful completion.
Deterministic replay of public-model records and separate signature and consistency verification of archived evidence covering 50 earlier simulated-WMS cases.
Lean 4 formal proof checks (37 theorem declarations), 768 concrete model-to-implementation correspondence checks, and Python/JavaScript testing.
Not Covered by This Implementation
Proposed HAAP assurance records, domain-independent adoption states, transition authorization, or multi-implementation interoperability.
Product-specific temperature thresholds, direct sensor-data evaluation, or temperature-excursion calculations.
Real shipments, physical equipment, production WMS integration, cross-company APIs, or live AI-model interactions.
Independent authentication of receiver authority, sensor-source authenticity, or the truth of signed observations.
Formal verification of the complete software runtime, concurrent operations, or duplicate prevention across independent sessions.
Third-party certification, regulatory compliance, or production-system security assurance.
Formal proofs apply to a limited abstract model with seven input conditions and two state bits, not the complete software system. The separately archived 50-case evidence originates from an earlier simulation under the same administrator. Signature verification does not establish the truth of observations, and post-execution quarantine does not reverse an effect already performed.
View Implementation on GitHub
Independent Technical Demonstration | Physical Internet Cyber Assurance |
AI Assurance, Inc.
Inter-company handoff-control precursors:
implemented and tested.
Developed solely by AI Assurance, Inc., this public technical demonstration tested authorization, execution-outcome handling, and destination switching for a synthetic handoff.notice operation in a Physical Internet setting. Three simulated organizations operated as separate local processes with their own SQLite databases and Ed25519 signing keys. It is not a joint Council PoC and does not implement HAAP's proposed assurance records or domain-independent state separation.
Functions Implemented and Tested
Binding of notification content, destination, and condition versions to signed approvals across simulated organizations.
Source authorization at grant issuance and receiver-side rechecks before local commit, rejecting unauthorized or outdated requests.
Durable outcome reconciliation after lost responses, process interruptions, and concurrent retries, with HOLD for unresolved results.
Controlled switching from destination B to C only after signed cancellation at B is confirmed, preventing duplicate local effects for the same test intent.
Separate offline verification of signed events, hash-linked records, authorization sequences, execution outcomes, and cancellation evidence.
Forty local HTTP scenarios, bounded exhaustive-state exploration with five negative controls, and Lean 4 formal checks (29 theorem declarations and 6,204 concrete examples).
Not Covered by This PoC
HAAP's proposed assurance records, domain-independent adoption and authorization states, or multi-implementation interoperability.
Real enterprises, production logistics platforms, actual cargo movements, or delivery-route optimization.
Physical execution, temperature management, production WMS integration, live AI-model interactions, or network infrastructure switching.
Multi-host security, distributed PKI, hardware-protected keys, or resilience against compromised participating nodes.
Independent authentication of organizational identities, truthfulness of signed observations, or completeness of undisclosed histories.
Formal verification of the complete HTTP/SQLite implementation, physical exactly-once execution, third-party certification, or regulatory compliance.
Lean 4 proofs cover a reduced abstract model, not the complete software implementation. The 40 HTTP scenarios use simulated organizations on a single machine, and bundled keys and checkpoints do not establish independent provenance. Previously issued, unexpired source permissions may remain valid after revocation. The packaged sample was generated without Lean; successful formal verification is documented separately through GitHub Actions.
View Implementation on GitHub
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.