🤖 AI

RAILS: Verification-Native Clearing For Agentic Commerce

This paper introduces RAILS, a verification-native clearing protocol for agentic commerce that establishes a formal, falsifiable soundness property ensuring no financially material settlement occurs without evidence meeting the obligation's admissibility floor, thereby filling the critical gap between autonomous agent actions and neutral obligation verification.

Original authors: Adrian de Valois-Franklin, Alex Bogdan

Published 2026-06-09

📖 5 min read🧠 Deep dive

CC BY 4.0

Original authors: Adrian de Valois-Franklin, Alex Bogdan

Original paper licensed under CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ This is an AI-generated explanation of the paper below. It is not written or endorsed by the authors. For technical accuracy, refer to the original paper. Read full disclaimer

Imagine a world where AI agents are like highly skilled, independent contractors. They can write code, buy parts, sign contracts, and move money without a human needing to press "approve" every step of the way.

The problem, according to this paper, is that we have built the roads for these agents to drive on (payment systems, communication tools, authorization checks), but we haven't built the traffic court to decide who is actually right when things go wrong.

If an AI agent buys a $40,000 part that turns out to be the wrong model, or if a coding agent fixes a bug but accidentally introduces a security hole, current systems can't automatically figure out: Did the agent actually do what they promised? Is the evidence good enough to release the payment? Who is to blame?

The paper introduces RAILS (Real-Time Agent Integrity & Ledger Settlement) as the missing "traffic court" for the AI economy.

Here is how it works, using simple analogies:

1. The Core Problem: "Authorization" isn't "Clearing"

Think of Authorization as a boss giving an employee a credit card and saying, "Go buy a new chair."

Current Systems: They check if the employee had the card (Authorization) and if the money moved (Payment).
The Gap: They don't check if the employee bought a chair, or if they bought a chair that collapses immediately.
The Paper's Claim: Just because the agent was allowed to act and the money moved doesn't mean the job was done correctly. We need a system that verifies the outcome, not just the permission.

2. The Solution: The RAILS Protocol

RAILS is a seven-step "integrity layer" that acts as a neutral referee. It doesn't just ask "Did you do it?" It asks, "Can you prove you did it, and is that proof strong enough to release the money?"

Here are the seven "primitives" (tools) RAILS uses, explained as a story:

The Obligation Object (The Contract): Before the work starts, the human and the AI sign a digital contract. It's not just "Fix the bug." It's "Fix the bug, don't add new libraries, and prove it with a specific test log." This sets the rules of the game.
The Evidence Envelope (The Evidence Box): After the AI finishes, it packs up its work. It doesn't just say "I did it." It puts the code changes, the test logs, and the security scans into a sealed, unchangeable digital box. Crucially, every item in the box gets a "trust tag" (e.g., "This came from a secure server" vs. "This is just the AI saying so").
The Verification Mesh (The Jury): Instead of one judge, RAILS uses a panel of different "jurors."
- The Robot Judge: Checks if the code follows strict rules (like "Did you add a new library?").
- The Receipt Checker: Looks at logs from external systems (like a CI server).
- The Human Arbiter: A real person who steps in if the robots are confused.
- The Semantic Judge: An AI that reads the code to see if it actually solves the problem.
The Clearing Decision (The Verdict): The system combines the jury's votes. But here is the magic rule: The verdict is only valid if the evidence is strong enough.
- The "Floor" Rule: If the contract says, "We need proof from a secure server (High Trust)," but the AI only provides a self-report (Low Trust), the system rejects the verdict, even if the AI says it did a good job. It refuses to pay out on weak evidence.
The Settlement Instruction (The Check): Once the verdict is valid, the system tells the bank or payment processor: "Release the money," "Refund the money," or "Penalize the agent."
The Clearing Passport (The Reputation Score): Every agent gets a scorecard. If they keep passing with strong evidence, their score goes up. If they try to cheat or use weak evidence, their score drops. This score determines how much trust they get in the future.
Finality Rules (The Gavel): This is the timer. The decision starts as "Provisional" (temporary). If no one appeals within a set time, and the evidence is still strong, it becomes "Final" (permanent).

3. The "Soundness" Guarantee

The paper makes a very specific claim: RAILS guarantees that no money changes hands unless the evidence meets a minimum "trust floor."

Imagine a casino.

Old Way: The dealer (AI) says, "I won," and the machine pays out.
RAILS Way: The dealer must show their cards. If the cards are blurry or drawn on a napkin (weak evidence), the machine refuses to pay, even if the dealer insists they won. The machine only pays if the cards are clearly visible and verified by the security cameras (strong evidence).

4. Why This Matters

The paper argues that without this "Clearing" layer, the AI economy cannot scale safely.

Payment rails (like Visa or crypto) move money, but they don't know if the service was delivered.
Escrow holds money, but it needs a judge to say when to release it.
LLM Judges (AI judging AI) are prone to bias and can be tricked.

RAILS solves this by creating a neutral process that grades the quality of the proof before any money moves. It ensures that an AI cannot trick the system into paying it for a job it didn't actually do, simply by saying "I did it."

Summary

RAILS is the missing "trust layer" for AI. It turns the messy question of "Did the AI do a good job?" into a strict, mathematical process of "Is the proof strong enough?" It ensures that in a world of autonomous agents, you don't just pay for the attempt; you only pay for the verified result.

Technical Summary: RAILS – Verification-Native Clearing for Agentic Commerce

1. The Problem: The Agentic Clearing Gap

The paper identifies a critical structural gap in the emerging infrastructure of autonomous agent commerce. While existing protocols effectively handle authorization (granting permission), execution (tool calls and communication), and payment (value transfer), none provide a neutral mechanism to determine performance fulfillment.

Current systems face the "agentic clearing problem":

Authorization $\neq$ Clearing: An agent may be authorized to act but still perform the wrong action (e.g., booking a flight for the wrong week).
Payment $\neq$ Clearing: A payment rail can cryptographically validate a transfer even if the service was defective or undelivered.
LLM-as-Judge $\neq$ Clearing: While LLMs can evaluate semantic performance, they suffer from biases (position, verbosity, self-enhancement) and lack a formal, falsifiable guarantee that their verdicts are based on admissible evidence.
Escrow $\neq$ Clearing: Escrow and underwriting are settlement mechanisms that consume a determination; they do not produce the determination itself.

The core issue is that no existing layer answers the composite question: What was promised, what happened, what evidence is admissible, who is responsible, what loss occurred, and what settlement action is final? Without this, settlement systems either ignore risk or impose it on the wrong party.

2. Methodology: The RAILS Protocol

RAILS (Real-Time Agent Integrity & Ledger Settlement) is proposed as a verification-native clearinghouse protocol. It sits between the execution layer (agents, tools, MCP, A2A) and the settlement layer (payment rails, escrow, risk standards).

2.1 The Seven Primitives

The protocol is defined by seven data structures and functions that convert signed intent into a settleable decision:

Obligation Object ( $O$ ): A signed, machine-clearable contract compiling natural-language intent into a structured tuple containing parties, task statements, acceptance criteria, evidence requirements, and an admissibility floor ( $\phi_O$ ).
Evidence Envelope ( $E$ ): A hash-anchored container of execution artifacts (git diffs, logs, receipts, self-reports). Each item carries a provenance chain and an admissibility class.
Verification Mesh: A configured set of heterogeneous verifiers (constraint checkers, receipt verifiers, semantic judges, human arbiters). Each returns a verdict, confidence, and a declared evidence basis ( $B_i$ ).
Clearing Decision ($CD$): The structured verdict aggregating mesh outputs. It includes performance/policy status, fault assignment, loss estimates, and the aggregated evidence basis.
Settlement Instruction ( $S$ ): A structured action list (fee, principal, collateral, penalty actions) derived from the Clearing Decision, targeted at specific execution rails.
Clearing Passport: A cross-transaction reliability record for agents, tools, and verifiers, updated after every clearing event to inform future pre-clearance and verifier selection.
Finality Rules: A predicate determining when a Settlement Instruction transitions from PROVISIONAL to FINAL, based on admissibility floors, confidence thresholds, conflict resolution, and appeal windows.

2.2 The Admissibility-Graded Verification Mesh

The core innovation is the admissibility partial order ( $\Lambda$ ). Evidence is not ranked by a scalar score but by a partial order of six classes:

SELF: Unverified self-report.
SIGN: Cryptographic signature (non-repudiation, not truth).
WIT: Third-party witness signature.
REC: Non-interested external receipt.
ATT: Attestation from a Trusted Execution Environment (TEE).
PROOF: Cryptographic proof of correctness (e.g., zk-SNARK).

Crucially, WIT and REC are incomparable, reflecting different trust assumptions. The class of an aggregate basis is the join of its components, while the class of a single verifier's basis is the meet of the items it relied on.

2.3 The Aggregator and Soundness

The Mesh Aggregator ( $\Gamma$ ) combines verifier outputs using an admissibility-weighted majority.

Floor Enforcement: Verifiers whose declared evidence basis ( $B_i$ ) falls below the obligation's admissibility floor ( $\phi_O$ ) are assigned zero weight.
Declared Basis Contract: Verifiers must honestly declare which evidence items they used. Misreporting (basis laundering) is an adversarial class.
Soundness Property: The protocol enforces a falsifiable property: No financially material Settlement Instruction is emitted unless the aggregate evidence basis class meets or exceeds the obligation's admissibility floor.
$\text{Emit}(S) \implies \text{cls}(B) \succeq \phi_O$

2.4 Exposure-Driven Intensity

At the Pre-Clearance stage, the protocol computes an Exposure Score ( $X$ ) based on authority risk, value at risk, intent ambiguity, irreversibility, agent history, and domain sensitivity. This score maps to a stepped policy ( $K$ ) that determines:

Verifier Set: From single deterministic verifiers (LOW) to mesh + human arbiter (CRITICAL).
Settlement Timing: From instant to delayed finality.
Margin Requirement: From none to full collateralization.

3. Key Contributions

Formal Specification of Clearing: The paper defines clearing not as a score or a boolean pass, but as a determination graded by the admissibility of its evidence.
Soundness Guarantee: It introduces a falsifiable soundness property ensuring that no material settlement rests on inadmissible evidence. This distinguishes RAILS from "pass/fail" systems, numeric scoring, or game-theoretic equilibria.
Admissibility Partial Order: It proposes a non-scalar, partial-order model for evidence that respects structural differences in trust (e.g., distinguishing between a witness and a receipt).
Lifecycle State Machine: It specifies a ten-stage lifecycle (Discovery to Finality) with explicit reversibility boundaries and escalation paths (Human Arbiter, Appeal Window).
Integration with Existing Stack: RAILS is designed to consume inputs from existing protocols (MCP, A2A, AP2, x402) and feed outputs into settlement-risk standards, acting as the missing "clearing layer" in the agentic stack.

4. Results and Validation

The paper validates the protocol through a canonical worked scenario: a software delivery clearing event where an autonomous coding agent fixes a bug but violates a dependency policy.

Scenario Dynamics: The agent adds an unauthorized dependency. A semantic LLM-judge is fooled by the agent's self-report (a SELF-class evidence) and returns a PASS.
Protocol Execution: Because the LLM-judge honestly declares its basis (the SELF report), the floor-enforcement gate detects that the basis is below the required ATT (TEE-attested) floor.
Outcome: The LLM-judge's verdict is assigned zero weight. The aggregator relies on other verifiers (constraint checkers using ATT-class git diffs) which correctly identify the policy violation. The result is a policy FAIL verdict, preventing the release of funds.
Significance of Result: This demonstrates that the protocol's soundness holds even when a verifier is "fooled," provided the verifier adheres to the contract of declaring its evidence basis honestly. The system does not require the verifier to be omniscient, only honest about its inputs.

5. Significance and Claims

The paper claims that autonomous-agent commerce cannot scale without a neutral mechanism that converts execution traces into admissible evidence and emits sound settlement instructions.

Distinction from Prior Work: Unlike "verify-then-pay" systems that emit a boolean pass, or "challenge-game" systems that rely on rational equilibria, RAILS emits a falsifiable claim about the admissibility of the evidence supporting a settlement.
Scope of Soundness: The paper is modest about what soundness provides. It guarantees that the protocol will not emit a settlement based on inadmissible evidence. It does not guarantee ground truth, verifier correctness (calibration), or attester honesty. It bounds what the protocol can be made to emit, not what is true in the world.
Positioning: RAILS is presented not as a replacement for existing protocols (MCP, A2A, payment rails) but as the necessary clearing layer that binds them, converting "what happened" into "what should be settled."

The paper concludes that by enforcing an admissibility floor and requiring honest basis declaration, RAILS provides the structural integrity required for agentic commerce to move from experimental benchmarks to real-world, financially material obligations.