Execution Governance Infrastructure

Architecture

RIO is not a model. It is a governed execution protocol that sits between an agent and the real world. It does not advise. It gates.

Version 2.0 — Reference implementation: 143 tests, 0 failures

Design principle: fail-closed. If any condition cannot be positively verified, the execution gate remains locked. This is the inverse of most AI systems ("proceed unless blocked").

What RIO Guarantees

No execution without authorization

The execution gate is fail-closed. Without a valid, signed, unexpired, unreplayed token, nothing executes.

Past records cannot be altered

The hash-chained ledger means modifying any entry invalidates all subsequent hashes. Tampering is detectable by any independent party.

Approvals cannot be forged

Ed25519/ECDSA signatures on receipts. Forgery is detectable without access to the signing key.

Tokens cannot be replayed

Single-use nonce registry. Every token is consumed on first use and rejected on any subsequent attempt.

1. The 8-Stage Execution Pipeline

Every action passes through an 8-stage pipeline before execution is permitted. The pipeline is enforced by the Execution/Governance Loop:

Intake

Raw goal or agent request received

Discovery & Refinement

Vague requests translated into a structured intent (action, target, parameters, requester identity). AI refinement is advisory; a human/system confirms the final intent.

Classification

Action type identified, risk category assigned

Policy & Risk Evaluation

Policy engine checks active rules; 4-component risk score calculated

Authorization

If risk exceeds threshold, human approver is notified. Upon approval, an Execution Token is generated (signed, TTL-bound, single-use nonce)

Execution Gate

Verifies token signature, timestamp, nonce, and kill switch before releasing the action. FAIL-CLOSED.

Post-Execution Verification

Computes three SHA-256 hashes: intent_hash (what was authorized), action_hash (what was executed), verification_hash (what was observed)

Receipt & Ledger

Signed v2 receipt created and recorded in the signed hash-chained ledger

Denials are first-class: Blocked or denied actions generate denial receipts and are recorded in the ledger. The audit trail covers every decision, not just successes.

Three-Loop Architecture

Intake Loop

Goal → structured intent (Universal Grammar Layer)

Governance Loop

Risk → policy → approval → token → gate → verify → receipt → ledger

Learning Loop

Analyzes audit trail, proposes policy updates via replay/simulation. Cannot bypass governance or execute actions directly.

2. Receipts — The Three-Hash Binding

A v2 receipt is a cryptographically signed record of a single decision (approval or denial). The three hashes cryptographically bind what was intended, what was executed, and what actually happened. A mismatch proves drift, tampering, or execution error.

Receipt v2 Contents:
├── intent_hash    (SHA-256)  — what was authorized
├── action_hash    (SHA-256)  — what was executed
├── verification_hash (SHA-256) — what was observed
├── risk_score     (4-component)
├── policy_decision
├── timestamps     (requested, authorized, executed/denied)
├── requester_id + approver_id
├── policy_version + packet_references
└── signature      (Ed25519 / ECDSA)

Receipts are signed with Ed25519/ECDSA. Forgery is detectable without access to the signing key.

3. Ledger — Tamper-Evident History

The v2 ledger is a signed hash chain. Each entry references the previous entry's hash. Any modification to any entry invalidates all subsequent hashes.

Hn = SHA256( En.data + H(n-1) )

Each entry also carries its own signature for independent verification. The ledger is append-only. Current implementation is single-node (distributed ledger is future work).

4. Verification — Independent Audit

RIO provides two standalone verification tools. No trust in the runtime is required:

Receipt Verifier

Validates signature, recomputes hashes, checks TTL/nonce

Ledger Verifier

Recomputes the hash chain and verifies per-entry signatures

How to verify (no access to RIO needed):

Recompute Hn = SHA256(En.data + H(n-1)) — mismatch = tampering

Verify Ed25519 signature against public key

Submit a used nonce → system rejects (replay protection)

Submit expired token → system rejects (TTL default 300s)

Attempt execution without token → gate remains locked

Test harness: 143 automated tests across 12 suites — Core Pipeline, Cryptographic Verification, v2 Receipt System, Denial & Edge Cases, Audit & Traceability, Governance Model, Conformance, Gateway, Independent Verifier, SDK, and Simulator.

5. Threat Model

RIO mitigates execution-layer threats in autonomous AI environments:

Threat	Mitigation
Unauthorized execution	Fail-closed gate — no token = no execution
Replay attacks	Nonce registry — single-use tokens
Stale authorization	TTL expiry (default 300s)
Audit tampering	Hash-chained ledger + per-entry signatures
Forgery	Ed25519/ECDSA signatures on receipts
Silent denials	Denial receipts — blocked actions are auditable

Out of scope (by design):

Data governance (training data quality/bias)Model transparency/explainabilityAccuracy/robustnessContent safety/guardrailsFull lifecycle logging beyond executionGDPR retention/minimizationHSM key management

RIO governs what AI systems do, not what they are trained on or what they say.

Full Threat Model

6. Trust Model

Who you must trust

The signing key holder

For the authenticity of approvals. Keys are currently software-managed (HSM integration is future work).

The policy author

For the correctness of rules. Policies are versioned and recorded on receipts.

Who you do NOT need to trust

The runtime operator

Receipts and ledger are independently verifiable.

The agent

It cannot execute without a valid token.

The audit system

Hash chain + signatures detect tampering.

Full Trust Model

7. Regulatory Alignment

RIO provides the infrastructure for a specific, demonstrable requirement: a verifiable, cryptographic record that a specific action was authorized by a specific human, executed under a specific policy, verified against its stated intent, and recorded in a tamper-evident ledger that any independent party can audit.

Framework	Articles	RIO Mechanism
EU AI Act	Art. 12, Art. 14, Art. 9	Receipts/ledger (record-keeping), fail-closed gate (human oversight), risk engine (risk management)
NIST AI RMF	GOVERN, MAP, MEASURE, MANAGE	Policy engine, intake loop, risk scoring, approval gate
ISO 42001	A.6.2.8	Automatic signed receipts (event logging)

Full EGI Technical Assessment (PDF)

Explore the full specification, schemas, and conformance tests on GitHub.

Protocol Specification →Position Paper →