Airbender ARCAgentic Rail Controller

Evidence · Post 4 of 5

Evidence you can replay

An audit log tells you what happened. A replayable verdict lets an auditor run the decision again and get the same answer. Why ARC stores the second kind.

Airbender team6 min read

Most governance products keep logs. Logs are written by the system being audited, in a table that system can update, describing decisions made by code that has since changed. When an auditor asks why an agent was allowed to issue a refund in March, a log gives you a row that says "allowed". It can't show you the reasoning.

ARC treats evidence as the platform's single source of truth about the past, and holds it to three rules.

1. Append-only, enforced by the database

Evidence rows are never updated or deleted. A resolution is a new event that refers to the original, never a column flipped on it. ARC doesn't rely on application discipline for this: the evidence table carries a trigger that refuses UPDATE, DELETE and TRUNCATE for every role, including the platform's own.

=> DELETE FROM evidence WHERE seq = 3;
ERROR:  evidence is append-only: DELETE refused

2. Hash-chained per tenant

Each event carries a sequence number, the hash of the previous event, and its own hash over the exact canonical body that was written. A verification pass walks the chain and recomputes every link. An inserted row, a rewritten field or a gap in the sequence breaks it at a specific seq, and the console tells you where.

The chain covers four kinds of event: verdicts, enforcement actions, change events (every publish, release, approval and operator action), and platform events, the ARC server's own self-checks. That last kind matters more than it sounds. The original Airbender platform once lost 13 days of ingest to a skew between applied database grants and a running image, silently. In ARC, a service that can't verify its own permissions at startup refuses to report ready, and the result lands in the same ledger as everything else.

3. Every verdict carries its own snapshot

This is the rule that makes evidence replayable. A verdict event doesn't just record the outcome. It embeds the deciding rail exactly as it was, the observation the kernel saw, the postures in force, the bundle version's content hash and the kernel version:

{
  "kind": "verdict",
  "railKey": "refund_budget_per_session",
  "bundleVersionHash": "sha256:525acf3f…",
  "kernelVersion": "0.1.0",
  "snapshot": {
    "rail": { "class": "budget", "rung": "R2", "flags": { "critical": true },
              "predicate": { "ceiling": 2000, "hardMax": 5000 } },
    "observation": { "current": 800, "increment": 1300 },
    "postures": { "safety": "failClosed" }
  },
  "verdict": { "band": "risk", "severity": "critical",
               "rungDemanded": "R2", "rungApplied": "R2", "measureValue": 2100 }
}

Current configuration is never consulted to explain a past decision. Because the decision kernel is a pure function, with no I/O, no clock and no hidden state, an auditor can feed the snapshot back through it and compare. ARC exposes this as one endpoint and one button. The replay itself is recorded as an access event.

In the blueprint's first production run, all 36 recorded verdicts replayed to identical results.

Two kernels, one truth

ARC's data plane is written in Rust and its control plane in Go, and each embeds a kernel. Two implementations of governance logic is exactly the class of bug the original platform fought, where TypeScript and Go evaluators drifted apart. ARC handles it in two ways:

  • Both kernels are pinned to the same 83 language-neutral conformance vectors. A semantic change requires a vector change in the same commit.
  • In production, the control plane re-derives every verdict the Rust data plane records using the Go kernel. A disagreement is written to the platform stream as a kernel divergence alarm before anyone has to notice it in an audit.

What auditors get

For a given period, the questions an assessor asks are concrete. Which rails were released, and who approved them? What tripped, and what did the platform do? Which hazard cells were covered, and which waivers were live? Where was evidence incomplete? ARC answers each from the ledger, and each answer can be re-derived by running the decision again rather than by trusting a summary.

Compliance packs that turn this into framework-shaped reports, mapped to the EU AI Act's high-risk obligations, ISO/IEC 42001, the NIST AI RMF and SOC 2 change management, are next on our roadmap. The ledger they will read from is running today.