Source-linked AI summary
AIREP: A Protocol for Per-Decision Evidence in AI Runtime Governance
Ali Toygar Abak
TL;DR
Automated AI runtimes lack a widely shared way to record the basis and evidentiary limits of individual governance decisions. AIREP defines one signed, hash-linked JSON record per decision, with closed vocabularies, hashed references, explicit scope, and profile-based extensions. The paper presents reference tooling and conformance checks while identifying independent adoption, canonicalization alignment, freshness, and replay boundaries as remaining issues.
Problem
Existing instruments do not provide a widely shared, per-decision governance-grade record of an automated runtime’s decision basis and evidence limits.
Method
AIREP defines one signed JSON record per governance decision, using hashed references, fixed decision and evidence vocabularies, explicit scope, a SHA-256 chain, and optional profiles.
Results
A reference implementation and two-language conformance kit provide records and checks for schema validity, neutrality, hash recomputation, chain integrity, and signatures.
Takeaways & Limitations
AIREP offers a runtime-independent interchange format for recording governance decision paths and their evidentiary boundaries.
Takeaways & Limitations
Independent adoption remains outstanding, canonical-form alignment can change existing chain hashes, core chains do not detect staleness or tail-truncation, and replay does not re-execute runtimes.
Abstract
from arXiv · showhide
A protocol is presented for recording the governance decisions of automated AI runtimes. When a runtime releases, blocks, defers, redacts, or escalates an individual output, AIREP records that decision as a single signed object that any party can check offline, independent of the runtime that produced it. A record carries the decision as one of a closed set of verbs under a stated policy basis, references its input, output, and evidence by hash rather than by value, and declares both what its evidence covers and what it does not. Records form a SHA-256 hash chain that binds each record to its position, so that tampering and gaps are detectable by recomputation. Vendor-, model-, and domain-specific content is confined to a single optional namespace, and a mechanical neutrality test keeps the shared format free of it. A reference implementation and a two-language conformance kit are described. Some implementation issues are considered, and problems such as alignment of the canonical form across implementations, freshness witnesses, and multi-runtime chains are exposed. The format is offered for adoption by any AI runtime that records governance decisions.
1 Introduction
AIREP addresses the missing per-decision governance record needed to explain an automated runtime’s decision basis and evidence boundaries. It defines a signed, tamper-evident record while explicitly limiting its attestation to the decision path rather than output truth.
- Automated AI runtimes make release, block, defer, redact, and escalation decisions with legal or safety consequences, but no widely shared record explains their basis and evidence limits.
- Existing telemetry, model cards, and supply-chain attestations answer adjacent questions but do not define a per-decision, governance-grade evidence record.
- AIREP maps exactly one JSON record to each runtime governance decision and specifies its members, canonical form, hash chain, conformance, and neutrality mechanisms.
- AIREP records that a decision was taken under a stated verb and basis with named evidence, but does not establish that the underlying AI output was correct.
2 The Record
An AIREP record is a closed-schema JSON object for one governance decision, carrying machine-checkable decision, input, output, evidence, and scope information. It uses references and hashes instead of payloads, fixed vocabularies for interoperability, and integrity fields for verifiable records.
- The protocol unit is one JSON object recording one runtime decision to release, block, defer, redact, escalate_to_human, or kill an automated output.
- The core schema requires nine members and permits only the optional profiles object outside the closed top-level member set.
- Inputs, results, and evidence are referenced by pointers and optional hashes, keeping sensitive content out of the record while anchoring references.
- A record includes subject, input, claim, output, and evidence members, with evidence entries carrying a closed type, reference, resolvability flag, and optional content hash.
- The directive uses fixed governance verbs and evidence uses fixed types, while runtime-specific refinements belong in profiles rather than widened core enumerations.
- Scope declares what evidence covers and does not cover, making unresolved or incomplete support explicit and limiting the record’s assurance boundary.
- The worked example records a release decision grounded in safety and ethics gates while excluding reasoning faithfulness from its attestation.
- An independent Node verifier recomputes hashes and re-checks signatures to derive the same hashes byte for byte.
3 Integrity and the Chain
AIREP makes records tamper-evident and position-bound by hashing a canonical representation that includes the prior link, then chaining each record to its predecessor. Its replay guarantee concerns recorded evidence, not live runtime re-execution or output truth.
- Integrity comprises a canonical form, content hash, signature, and back-link that establish whether a record remains the producer’s unaltered record in sequence.
- RFC 8785 canonicalization fixes JSON key ordering, whitespace, and number serialization so independent implementations can agree on one digest.
- integrity.current is the SHA-256 digest of the canonical record with current and signature removed, while retaining every other member including previous.
- Including previous in the hash binds record content to its chain position, so lifting, splicing, or replaying a record changes the digest.
- A verifier detects removed, reordered, or spliced records through broken previous-to-current links and detects chains that do not begin at genesis.
- AIREP leaves the signature algorithm to deployment while fixing what is signed and how the canonical content hash is formed.
- Record-bound replay recomputes digests and chain links from stored bytes, but does not re-run models, tools, or runtime evaluation and does not assert output truth.
4 Conformance and Neutrality
AIREP conformance combines schema validation, profile stripping, hash recomputation, chain checking, and optional signature verification. Its neutrality test confines implementation-specific content to profiles, while two-language verifiers support independent checking.
- A verifier accepts a record or chain only when schemas, required members, vocabularies, profile removal, hashes, and links all validate.
- Signature verification is additional when the verifier holds the signing key, allowing structure and chaining checks without key possession.
- The neutrality test deletes profiles and requires the remaining record to validate against the core schema.
- Closed top-level properties prevent vendor fields beside core members and make profile-dependent core content fail after profiles is stripped.
- Profiles provide named optional bundles for external rulebooks, domains, trust metadata, witnesses, and observability without requiring a central registry.
- The conformance kit provides Python and Node verifiers that validate structure and neutrality, recompute hashes across cryptographic stacks, and re-verify signatures.
5 Open Problems
AIREP identifies independent adoption, cross-implementation canonical agreement, freshness protection, and multi-runtime semantics as open problems for making the protocol a shared interchange format.
- Independent adoption is the decisive open problem: AIREP needs runtimes uninvolved in its design to produce and verify records.The authors regard adoption across independent runtimes as what would make AIREP an interchange format in fact.
- Canonical serialization must agree byte for byte across implementations, but aligning the reference producer with RFC 8785 would change every existing chain hash.The reference producer currently uses deterministic sorted-key serialization rather than the conformance kit’s canonicalization scheme, making alignment a versioned change.
- The chain detects tampering and gaps but not stale valid records or tail-truncation by a party controlling storage.A signed length-and-head witness and a freshness anchor are being exercised to address these omissions.
- Multi-runtime and multi-tenant chains remain outside scope because v0.1 supports one producer per chain and has not selected federated-chain semantics.
6 Conclusion
AIREP presents a signed, tamper-evident record for each automated AI-runtime governance decision, including its evidence and coverage boundary. Its closed schema, neutrality test, hash chain, reference implementation, and conformance kit support reproducible records, while independent-runtime adoption remains the next step.
- AIREP defines one signed record for each automated AI-runtime governance decision, stating the assertion, evidence, governance verb, and evidence coverage.
- The protocol combines a closed core schema, a mechanical neutrality test, and a SHA-256 chain with record-bound replay.
- A reference implementation produces records, while a two-language conformance kit checks them.
- AIREP attests the recorded decision path as tamper-evident, not the truth of the underlying output.