AINEWS
A draft protocol turns each AI release, block, defer, redact, or escalate decision into a signed record, where each new entry is cryptographically linked to the last, so any auditor can verify it offline.
When a content filter blocks a chatbot's reply, a recruiter's screening tool defers a hiring decision, or a moderation system redacts a post, the vendor's log is usually the only record that exists. A draft protocol called AIREP proposes to change that: it would turn each of those governance decisions into a single signed object that any auditor can verify offline, without needing the system that produced it.
"Runtime" here means any AI system that produces outputs one decision at a time: a chat assistant, a moderation classifier, an agent that escalates to a human reviewer. AIREP defines a closed set of decision verbs for those runtimes: release, block, defer, redact, escalate. Every time a compliant runtime makes one of those calls, it must emit a record. Each record carries hashes (short cryptographic fingerprints) of the inputs, outputs, and any evidence the runtime relied on, rather than the values themselves, and declares both what its evidence covers and what it does not. Because the records are bound to one another by position in a SHA-256 hash chain, a sequence where each new record's identifier is computed from the previous one, a gap or a forged entry becomes visible the moment anyone recomputes the chain from scratch. An outside party can detect tampering without ever contacting the vendor.
A vendor-hosted log can be edited before the regulator sees it; a recomputed chain held by a third party cannot, at least not without the forgery showing. The protocol requires each record to cite its policy basis, the rule the runtime applied when it decided, so the auditor can match a decision to the rule it invoked, not just to the system's opaque self-report. A release decision under a "no medical advice" rule and a block decision under the same rule are two different records, and the chain preserves that distinction.
The design also fences off where vendors can hide proprietary behavior. Anything model-, vendor-, or domain-specific has to live in a single optional namespace, separated from the shared format. A mechanical neutrality test enforces that fence: it checks the shared portion of each record to make sure no such content has leaked across. That keeps the audit log portable across competing runtimes, so a regulator or auditor does not need a vendor's cooperation to read what a system actually decided and on what basis. It is the difference between a vendor-hosted log that may be edited and a portable receipt the vendor cannot rewrite.
A reference implementation and a two-language conformance kit ship with the paper, which gives the proposal something to test against. But the authors are explicit about what the chain does not bind. It records what the runtime said it decided. It does not prove the model was correct, the policy fair, or the optional namespace truthful. Three problems stay open: aligning the canonical form across independent implementations, attaching freshness witnesses so a record can prove when it was emitted, and chaining records across multiple runtimes rather than just within one. Each of those gaps is also a place where a vendor that wanted to evade the audit could exploit the protocol's silence.
AIREP is an arXiv preprint, not a peer-reviewed standard, and there is no public record of adoption or independent interoperability testing. The structural choice on the table, a portable, third-party-verifiable receipt on every governance decision in a form the vendor does not control, is what would shift the institutional question of AI audit from "what did the vendor log?" to "what can an outside party prove?" The conformance kit is now public. The next signal is whether any other lab builds to it.