AIREP: A Protocol for Per-Decision Evidence in AI Runtime Governance

# AIREP: A Protocol for Per-Decision Evidence in AI Runtime Governance
Source: [https://arxiv.org/html/2608.21363](https://arxiv.org/html/2608.21363)
\(2026\)

###### Abstract

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\.

## 1Introduction

Automated AI runtimes increasingly stand in front of decisions that carry legal or safety consequences\. A runtime releases one output, blocks another, defers a third to a human, redacts a fourth\. After such a decision, an auditor reconstructing an incident, a regulator inspecting a record\-keeping obligation, or a deployer showing that a control fired asks a specific question: on what basis was*this*decision taken, and what did the evidence behind it not cover? There is at present no widely shared record with which to answer it\.

The instruments a practitioner reaches for each answer a neighbouring question well and this one poorly\. Telemetry conventions for generative\-AI activity\(OpenTelemetry Authors,[2026](https://arxiv.org/html/2608.21363#bib.bib11)\)record what*ran*, at the granularity of a span, but not what was*decided*under whose authority\. Model and system cards\(Mitchell et al\.,[2019](https://arxiv.org/html/2608.21363#bib.bib5); OpenAI,[2023](https://arxiv.org/html/2608.21363#bib.bib10)\)carry authority and disposition, but about a whole model or release, not a single runtime decision\. Supply\-chain attestations sign builds and content\(Open Source Security Foundation \(2024\),[OpenSSF](https://arxiv.org/html/2608.21363#bib.bib9); Torres\-Arias et al\.,[2019](https://arxiv.org/html/2608.21363#bib.bib12); Newman et al\.,[2022](https://arxiv.org/html/2608.21363#bib.bib8)\), not per\-decision governance dispositions\. Governance frameworks — the EU AI Act\(European Parliament and Council of the European Union,[2024](https://arxiv.org/html/2608.21363#bib.bib3)\), the NIST AI Risk Management Framework\(National Institute of Standards and Technology,[2023](https://arxiv.org/html/2608.21363#bib.bib7)\), and ISO/IEC 42001\(International Organization for Standardization and International Electrotechnical Commission,[2023](https://arxiv.org/html/2608.21363#bib.bib4)\)— require or motivate logging, monitoring, documented evidence, and risk management, but leave the shape of a single per\-decision governance record on the wire undefined\. The legal\-side analysis reaches the same point from the other direction: a recent survey of AI agents under EU law concludes that high\-risk agentic systems with untraceable behavioural drift cannot currently satisfy the Act’s essential requirements, and names versioned, per\-decision runtime evidence as the operational artefact the standards leave unspecified\(Nannini et al\.,[2026](https://arxiv.org/html/2608.21363#bib.bib6)\)\. The missing artefact lies between these instruments, not within any one of them: a per\-decision, governance\-grade evidence record is undefined ground\.

In this paper we present AIREP, the AI Runtime Evidence Protocol, in which one JSON record corresponds to exactly one runtime governance decision\. The protocol fixes the members a record carries, a canonical form and hash chain that make a record tamper\-evident and bind it to its position in a sequence, and a mechanical test that keeps the shared format independent of any one runtime\. We first describe the record and its members \(§2\)\. We then give the integrity construction — the canonical form, the content hash, the signature, and the chain — and the one kind of reproducibility the protocol supports \(§3\)\. We then define conformance, the neutrality test that keeps a record vendor\-independent, and the optional profiles that bind a record to an external rulebook without contaminating the core \(§4\)\. We close by exposing the problems that remain open \(§5\)\.

One boundary holds throughout\. AIREP fixes the*form*of an evidence record, not the truth of its contents\. A record attests that a decision was taken, under a stated verb and basis, resting on named evidence, and that it has not since been altered; it does not establish that the underlying AI output was correct\. The record’sscopemember carries that boundary on the wire, and §2\.3 returns to it\.

## 2The Record

### 2\.1Members

The unit of the protocol is a single JSON object that records one runtime governance decision — one point at which a runtime decided to release, block, defer, redact, escalate, or halt an automated output\. A record has nine required members: the version constantairep\_versionand eight structural members, described below\. The core schema \(JSON Schema draft 2020\-12\) setsadditionalProperties:falseat the top level, so a conformant record carries no member outside this set, with one exception: a reservedprofilesobject, the only permitted optional member and the only place any vendor\-, model\-, or domain\-specific content may appear \(§4\)\.

A record carries*pointers, not content*\. The input under decision, the result, and each piece of evidence are referenced by a\*\_refpointer and, where it matters, anchored by a\*\_hashdigest; the referenced material is kept out of band\. A record states*that*an input was decided on and*what its digest is*, never what it said\. This keeps records small and lets a producer withhold sensitive content without invalidating the hash, which anchors the reference rather than the payload\.

- •subjectidentifies the decision in space and time:runtime\(the system that decided\),producer\(the software, by name and version, that emitted the record\),decision\_index\(an integer starting at 0 and increasing by one per decision in a chain\), andtimestamp\_utc\. An optionaltrace\_idgroups the records of one session\.
- •inputrequiresinput\_ref, a pointer to the input under decision, andgovernance\_state, a mechanism\-neutral object describing the governance context at decision time — for example a policy version\. Implementation\-specific mechanism does not belong here; it belongs under a profile\.
- •claimstates the record’s thesis:assertion, a single sentence, andbasis, a non\-empty list of the gates or policies the assertion rests on\. A record may not assert something about a decision without naming at least one ground for it\.
- •outputrecords the result asresult\_ref, with an optionalredactedflag; a redacted result is withheld while its hash still anchors it\.
- •evidenceis the array that binds the claim to its support\. Each entry is a pointer with atypefrom a closed set \(§2\.2\), aref, and aresolvableflag, with an optionalcontent\_hash\. A producer setsresolvabletotrueonly when a verifier can fetch and check the referenced material; a verifier must not treat an entry withresolvable:falseas verified evidence\. Redacted\-but\-anchored evidence thus stays in the record, where its absence is itself auditable, without being counted as proof\.
- •directiveis the decision compressed to one governance verb from a closed set \(§2\.2\) plus thepolicy\_basisthat produced it\. Whereclaimsays what the record asserts in prose,directivesays what the runtime*did*, as one machine\-checkable token under a stated authority\.
- •scopeis the distinguishing member \(§2\.3\)\.
- •integritymakes the record tamper\-evident and binds it to its chain \(§3\)\.

### 2\.2Closed vocabularies

Two fields draw from fixed enumerations, so that the verb of a decision and the kind of its evidence are comparable across runtimes without per\-vendor translation\. Thedirective\.verbis exactly one ofrelease,block,defer,redact,escalate\_to\_human,kill— passing an output, refusing it, holding it, masking part of it, handing it to a human, or halting\. Theevidence\[\]\.typeis exactly one ofretrieval,tool\_call,memory,policy,human\_approval,external\_url,eval,other, whereotherkeeps the set closed while admitting evidence kinds the first seven do not name\. A runtime\-specific refinement of either belongs in a profile, not in a widened core enum\.

### 2\.3Scope

The member that sets an AIREP record apart from an ordinary log entry isscope\. It requires two arrays:covers, what the evidence in the record attests, anddoes\_not\_cover, what it does not\. Both are populated by the producer\. A record whosedoes\_not\_coveris empty thereby asserts that its evidence covers everything material to the claim — a strong, falsifiable assertion, not a default to skip past\. Because a record may rest on evidence that is anchored but not resolvable, and because a verifier is forbidden to count such evidence as verified, the record states indoes\_not\_coverwhat it therefore cannot attest\. This is the field that makes a record say, on the wire, where its own assurance ends; it is the reason a record attests the decision*path*and not the*truth*of the output\.

### 2\.4A worked example

The following is the first record of the example chain shipped with the conformance kit, atexamples/chain\.jsonl\. Itsintegrity\.currentis the SHA\-256 of the record’s canonical form and itsintegrity\.signatureis an Ed25519 signature over that value, both produced with the kit’s published test key\. The signature value is abbreviated below for display; its full 128\-character form, with the record’s other values, is inexamples/chain\.jsonl, and a reader re\-derives the hash and re\-checks the signature with the command that follows\.

\{

"airep\_version":"0\.1",

"subject":\{

"runtime":"phionyx\-core",

"producer":"phionyx/0\.7\.1",

"decision\_index":0,

"trace\_id":"trace\-chain\-example",

"timestamp\_utc":"2026\-05\-30T00:00:00Z"

\},

"input":\{

"input\_ref":"sha256:ace06db3e39c9f0259980b2dc9ce388f1f61aeb27668a8d99fa6f70bbe93cd42",

"governance\_state":\{"policy\_version":"p1","prior\_context\_bound":true\}

\},

"claim":\{

"assertion":"initialoutputreleasedaftersafety\+ethicsgatespassed",

"basis":\["safety\_gate","ethics\_gate"\]

\},

"output":\{

"result\_ref":"sha256:dc08be1aab29777176e5fde7c61bae87c82418f08345dc7c6dc346200ef95928",

"redacted":false

\},

"evidence":\[

\{"type":"policy","ref":"policy://safety/v1","resolvable":true\}

\],

"directive":\{"verb":"release","policy\_basis":\["safety\_gate","ethics\_gate"\]\},

"scope":\{

"covers":\["safetygatefired","ethicsgatefired"\],

"does\_not\_cover":\["reasoningfaithfulnessnotattested"\]

\},

"integrity":\{

"previous":"sha256:0000000000000000000000000000000000000000000000000000000000000000",

"canonical\_json":true,

"current":"sha256:5aafe4898c6fd2e814c7871d3ba9b2d20eb106f3ccb115154741c263ae0ac87a",

"signature":\{"alg":"Ed25519","value":"903e882b\.\.\.64367607"\}

\}

\}

The record states that the runtimephionyx\-coredecided, at index 0 of its chain, toreleasean output because the safety and ethics gates passed; it points to the input and result by digest; it grounds the decision in one policy evidence pointer; and it declares that it attests the firing of those gates but not the faithfulness of the model’s reasoning\. Thepreviousfield carries the genesis value \(sha256:followed by sixty\-four zeros\), marking the first record of a chain\. The mechanics of §3 make this record reproducible:

gitclone\-\-branchv0\.1\.1https://github\.com/halvrenofviryel/ai\-runtime\-evidence\-protocol\.git

cdai\-runtime\-evidence\-protocol

python3spec/airep/v0\.1/conformance/verify\.py\\

spec/airep/v0\.1/examples/chain\.jsonl\\

\-\-pubkeyspec/airep/v0\.1/examples/test\_public\_key\.txt

The verifier recomputes each record’s hash and re\-checks each signature, and an independent Node verifier on a separate cryptographic stack derives the same hashes byte for byte\.

## 3Integrity and the Chain

The members of §2 say what a record asserts\. Theintegritymember says whether the record can be trusted to be the one the producer wrote, in the order it was written, unaltered\. It has four parts: a canonical form, a content hash, a signature, and a back\-link\.

### 3\.1Canonical form

A hash is stable only if the bytes it covers are stable, and JSON admits many byte\-level serializations of one logical object — key order, whitespace, number formatting, string escaping\. A record is therefore reduced to a single canonical form before hashing, so that two independent implementations agree on one digest, and it setscanonical\_jsontotrueto declare that it was\. AIREP pins the canonical form to RFC 8785, the JSON Canonicalization Scheme, which fixes key ordering, whitespace, and number serialization\. Because RFC 8785 fixes how numbers are written, a producer carries any value whose exact representation matters as a string rather than a number\.

### 3\.2The hash and the chain

integrity\.currentis the SHA\-256 digest of the canonical form of the record computed withcurrentandsignatureremoved and every other member retained — including the back\-linkprevious\. The two removed members cannot be inside their own preimage; everything else is\. Keepingpreviousinside the hash is the load\-bearing choice: it binds a record’s content to its position, so a signed record cannot be lifted out and spliced into another position, or replayed later in the chain, without changing the bytespreviouscontributes and so breakingcurrent\. Records form a chain in which each record’spreviousequals the prior record’scurrent, and the first record setspreviousto a fixed genesis constant of sixty\-four zeros\. A verifier detects a removed, reordered, or spliced record because somepreviousno longer matches the priorcurrent, and detects a chain that does not begin at genesis\.

### 3\.3The signature

A producer signsintegrity\.currentand records the result as\{alg,value\}\. AIREP does not mandate one algorithm:algnames the primitive —Ed25519, an HMAC, or a future choice — so that any conformant signer is interchangeable and a verifier knows which primitive to apply\. The format fixes*that*a record is signed and*what*is signed, the canonical content hash, and leaves the choice of primitive to the deployment\.

### 3\.4Record\-bound replay

AIREP supports one form of reproducibility, and it is worth naming which\. Given a record or chain, a verifier recomputes the canonical form and the digest over the*recorded*bytes and confirms that the recomputedcurrentmatches the stored one and that the chain links hold\. The decision is replayed from its record\. This is not live re\-execution: the protocol does not re\-run the model, re\-issue tool calls, or re\-evaluate the runtime, and it does not assert wall\-clock determinism\. The guarantee is exactly that the same record yields the same digest and the chain it sits in still links — a property of the evidence, consistent with a record that attests the decision path rather than the truth of the output\. Like any cryptographic log, the chain makes silent modification detectable and gaps locatable; it does not vouch for the content of what was logged, and §5 returns to what this leaves open\.

## 4Conformance and Neutrality

### 4\.1The conformance check

A*producer*emits records; a*verifier*reads and checks them\. A verifier reports a record, or a chain, as valid only when every one of the following holds: each record validates against the core schema, with the nine required members present, the closed vocabularies respected, and no member admitted outside the core set andprofiles; each record still validates after itsprofilesmember is removed \(§4\.2\); eachintegrity\.currentrecomputes from the canonical form; and everypreviouslinks to the priorcurrent, the first record carrying genesis\. A verifier that holds the signing key additionally re\-checks each signature overcurrent; it is stated as additional rather than mandatory because a verifier may legitimately check only structure and chaining for records whose keys it does not hold\.

### 4\.2The neutrality test

The neutrality test makes the protocol’s vendor\-independence checkable rather than asserted\. All implementation\-specific content is placed under the reservedprofilesobject as named sub\-blocks, and the test is one mechanical operation:*delete theprofilesmember; the record must still validate against the core schema\.*Because the top level is closed, a record that smuggled vendor fields alongside the core members would fail validation outright, and a record that relied onprofilesto carry a core member would fail onceprofilesis stripped\. The test needs no human judgement and no list of approved vendors: a record either survives the deletion of its entire profile block or it does not\.

### 4\.3Profiles

A profile is a named bundle of extra fields underprofilesthat a reader who does not need it simply ignores\. Framework profiles map a record onto an external rulebook — a regulation, a risk framework, a threat catalogue; domain profiles add the fields one industry needs\. Six profiles ship published schemas with worked examples that the conformance kit validates:key\_trust\(trust metadata for the signing key\),chain\_witness\(a freshness and head witness, §5\),eu\_ai\_act\_log,nist\_ai\_rmf,owasp\_threat, andobservability\_transport; further names are reserved\. AIREP operates no central registry of profile names: a collision\-resistant name — a vendor, product, or framework name — is sufficient, and governance of the extension surface is deferred until the format is in use across independent implementations\.

### 4\.4Implementation

A reference producer exists in the Phionyx tooling and is at present the protocol’s only producer\(Abak,[2026b](https://arxiv.org/html/2608.21363#bib.bib2),[a](https://arxiv.org/html/2608.21363#bib.bib1)\)\. Its current path produces AIREP\-compatible records; full producer\-side alignment with the canonical form remains an open item \(§5\)\. Independently of any producer, the conformance kit ships two verifiers, one in Python and one in Node, that validate structure, run the neutrality test, recompute every hash to the same bytes on different cryptographic stacks, and re\-verify signatures\. Two implementations that agree on both the verdict and the bytes are what make AIREP an interchange format rather than one tool’s private check\. The format is published, with its schema, conformance kit, and profiles, in a neutral repository of its own\(Abak,[2026a](https://arxiv.org/html/2608.21363#bib.bib1)\)\.

## 5Open Problems

Several problems are left open, and we state them plainly\.

The decisive one is*independent adoption*\. Today there is a single reference producer, and the path from its native records to the neutral core is written by the same party that wrote the format\. A format exercised only by its author is a proposal; a format that other runtimes — built by parties with no hand in its design — produce and verify is a shared one\. The protocol is meant to be implemented by any AI runtime that makes governance decisions, and the closed core, the neutrality test, and the two\-language conformance kit exist precisely so that an independent implementer can adopt it without coordinating with the authors\. We regard adoption across independent runtimes, not any further internal feature, as the work that makes AIREP an interchange format in fact as well as in name\.

The*canonical form must agree byte for byte across implementations*\. The conformance kit implements RFC 8785, but the reference producer still serializes with a deterministic sorted\-key form that is sufficient for a single chain and is not the canonicalization scheme; aligning it changes the computed hash of every existing chain and so is a versioned change rather than a patch\.

The chain detects tampering and gaps but not*staleness or tail\-truncation*by a party that controls storage: a stale\-but\-valid record, or a chain with its last records dropped, passes every check the core defines\. A signed length\-and\-head witness, carried by thechain\_witnessprofile and signed by a key independent of the producer, closes this, and is being exercised; a freshness anchor in the same profile maps a valid record to a current one\.

*Multi\-runtime and multi\-tenant chains*are outside the present scope\. The v0\.1 format is scoped to one producer per chain; the semantics of a chain spanning federated runtimes are not yet selected\.

## 6Conclusion

We have presented AIREP, a protocol in which one signed record corresponds to one governance decision of an automated AI runtime\. A record states the assertion the runtime made, the evidence it rests on, the governance verb under which the decision was taken, and — the distinguishing field — what its evidence does and does not cover; it attests the decision path, faithfully recorded and tamper\-evident, not the truth of the output\. The form is enforced by three mechanisms together: a closed core schema, a mechanical neutrality test that strips optional profiles, and a SHA\-256 chain with record\-bound replay\. A reference implementation produces the records and a two\-language conformance kit checks them\. The next step is adoption by independent runtimes, and beyond it the reconciliations of §5; we make no claim past the reproducible artefacts described here\.

## References

- Abak \(2026a\)Ali Toygar Abak\.AI Runtime Evidence Protocol \(AIREP\)\.[https://github\.com/halvrenofviryel/ai\-runtime\-evidence\-protocol](https://github.com/halvrenofviryel/ai-runtime-evidence-protocol), 2026a\.Concept DOI, resolving to the latest version; version at time of writing v0\.1\.1, DOI 10\.5281/zenodo\.20477088\.
- Abak \(2026b\)Ali Toygar Abak\.Phionyx Core SDK, 2026b\.Concept DOI, resolving to the latest version; version at time of writing v0\.7\.2, DOI 10\.5281/zenodo\.20417340\.
- European Parliament and Council of the European Union \(2024\)European Parliament and Council of the European Union\.Regulation \(EU\) 2024/1689 of the european parliament and of the council laying down harmonised rules on artificial intelligence \(Artificial Intelligence Act\)\.Official Journal of the European Union, OJ L of 12\.7\.2024, 7 2024\.[https://eur\-lex\.europa\.eu/eli/reg/2024/1689/oj](https://eur-lex.europa.eu/eli/reg/2024/1689/oj)\.
- International Organization for Standardization and International Electrotechnical Commission \(2023\)International Organization for Standardization and International Electrotechnical Commission\.ISO/IEC 42001:2023 – information technology – artificial intelligence – management system\.[https://www\.iso\.org/standard/81230\.html](https://www.iso.org/standard/81230.html), 12 2023\.
- Mitchell et al\. \(2019\)Margaret Mitchell, Simone Wu, Andrew Zaldivar, Parker Barnes, Lucy Vasserman, Ben Hutchinson, Elena Spitzer, Inioluwa Deborah Raji, and Timnit Gebru\.Model cards for model reporting\.In*Proceedings of the Conference on Fairness, Accountability, and Transparency \(FAT\*\)*, pages 220–229\. ACM, 2019\.doi:10\.1145/3287560\.3287596\.arXiv:1810\.03993\.
- Nannini et al\. \(2026\)Luca Nannini, Adam Leon Smith, Michele Joshua Maggini, Enrico Panai, Sandra Feliciano, Aleksandr Tiulkanov, Elena Maran, James Gealy, and Piercosma Bisconti\.AI agents under EU law\.[https://arxiv\.org/abs/2604\.04604](https://arxiv.org/abs/2604.04604), 4 2026\.
- National Institute of Standards and Technology \(2023\)National Institute of Standards and Technology\.Artificial intelligence risk management framework \(AI RMF 1\.0\)\.Technical Report NIST AI 100\-1, U\.S\. Department of Commerce, 1 2023\.
- Newman et al\. \(2022\)Zachary Newman, John Speed Meyers, and Santiago Torres\-Arias\.Sigstore: Software signing for everybody\.[https://arxiv\.org/abs/2207\.07307](https://arxiv.org/abs/2207.07307), 2022\.
- Open Source Security Foundation \(2024\) \(OpenSSF\)Open Source Security Foundation \(OpenSSF\)\.SLSA: Supply\-chain levels for software artifacts\.[https://slsa\.dev/](https://slsa.dev/), 2024\.Specification version 1\.0; accessed 2026\-05\-07\.
- OpenAI \(2023\)OpenAI\.GPT\-4 system card\.[https://cdn\.openai\.com/papers/gpt\-4\-system\-card\.pdf](https://cdn.openai.com/papers/gpt-4-system-card.pdf), 3 2023\.Accessed 2026\-05\-07\.
- OpenTelemetry Authors \(2026\)OpenTelemetry Authors\.Semantic conventions for generative\-AI systems\.[https://opentelemetry\.io/docs/specs/semconv/gen\-ai/](https://opentelemetry.io/docs/specs/semconv/gen-ai/), 2026\.Cloud Native Computing Foundation; accessed 2026\-05\-07\.
- Torres\-Arias et al\. \(2019\)Santiago Torres\-Arias, Hammad Afzali, Trishank Karthik Kuppusamy, Reza Curtmola, and Justin Cappos\.in\-toto: Providing farm\-to\-table guarantees for bits and bytes\.In*Proceedings of the 28th USENIX Security Symposium*, pages 1393–1410\. USENIX Association, 2019\.URL[https://www\.usenix\.org/conference/usenixsecurity19/presentation/torres\-arias](https://www.usenix.org/conference/usenixsecurity19/presentation/torres-arias)\.