RIO — Runtime Intelligence Orchestration
Governance infrastructure for AI systems
Receipt Protocol · Gateway Status · Live Demo · Architecture · White Paper
RIO is a governed execution system that sits between AI agents, humans, and real-world actions. It translates goals into structured intent, evaluates risk against policy, requires human approval when necessary, controls execution through single-use tokens, and generates cryptographically signed receipts recorded in a tamper-evident ledger.
AI proposes. Human approves. System executes. System records.
The system enforces the rules — not the AI. Execution without approval is structurally impossible.
Organizations deploying AI agents face a fundamental gap: the AI can reason and propose, but there is no structural guarantee that it cannot act without authorization. Prompt-level guardrails are bypassable. Policy documents are advisory. Audit logs can be incomplete or fabricated after the fact.
Without a governance layer that is architecturally separate from the AI itself, every deployed agent is a liability — capable of taking actions that no human approved, with no cryptographic proof of what happened. As AI systems gain access to email, payments, databases, and APIs, the cost of ungoverned execution scales with capability.
RIO closes this gap by making governance structural, not advisory. The execution gate is locked by default. Every action requires a signed approval, a single-use token, and produces a verifiable receipt. The ledger is append-only and hash-chained. There is no code path from intent to execution that bypasses governance.
RIO is designed for any environment where AI agents take real-world actions that carry risk, require accountability, or must comply with policy.
| Use Case | Description |
|---|---|
| Governed AI Assistants | Personal or enterprise AI agents that propose actions (send email, schedule meeting, make payment) but cannot execute without human approval |
| Enterprise Compliance | AI systems in regulated industries (finance, healthcare, legal) that need provable audit trails for every automated decision |
| Multi-Agent Orchestration | Coordination layers where multiple AI agents propose actions through a single governance pipeline with unified policy enforcement |
| Autonomous Workflow Automation | Automated business processes where low-risk actions execute automatically while high-risk actions pause for human review |
| AI Safety Research | A reference implementation of structural AI containment — fail-closed execution with cryptographic proof |
For enterprise deployment models, ROI analysis, and case studies, see the Enterprise Overview.
RIO enforces separation of powers at the architectural level. No single component can both decide and act.
Observer (Mantis) — Ingests goals, structures intent, assesses risk, and monitors outcomes. The Observer sees everything but controls nothing. It cannot approve or execute.
Governor — Evaluates intent against policy, applies risk thresholds, and issues or denies approval. The Governor decides but cannot execute. Approval produces a signed token; denial produces a signed record.
Executor — Receives approved intents with single-use execution tokens. The Executor acts but cannot approve. It verifies the token, executes the action, and produces a cryptographic receipt. If the token is missing, expired, or already used, execution is structurally blocked.
For the full specification, see Three-Power Separation.
Every action flows through a deterministic pipeline:
Intake → Observation → Policy Evaluation → Approval → Execution → Verification → Ledger
- Intake — Goal is received and structured into a typed intent with metadata
- Observation — Mantis assesses risk level, classifies the action, and enriches context
- Policy Evaluation — Governor evaluates the intent against the loaded policy set
- Approval — Human approves or denies (or auto-approval for low-risk actions per policy)
- Execution — Executor validates the single-use token and performs the action
- Verification — Outcome is verified against the original intent
- Ledger — Cryptographic receipt is generated and appended to the hash-chained ledger
For the complete architecture document, see Architecture v2.7.
The interactive demo site demonstrates the complete RIO governance flow:
The demo shows three perspectives: the AI agent proposing actions, the human approving or denying, and the system recording cryptographic proof.
The production gateway is deployed on Render with a PostgreSQL-backed ledger:
# Check gateway health
curl -s https://rio-gateway.onrender.com/health | python3 -m json.tool
# View the ledger (append-only, hash-chained)
curl -s https://rio-gateway.onrender.com/api/ledger | python3 -m json.tool
# Verify chain integrity
curl -s https://rio-gateway.onrender.com/api/verify-chain | python3 -m json.toolAutomated security testing confirms 11 of 12 tests passing, with all critical attack vectors blocked:
| Test | Description | Result |
|---|---|---|
| V-001 | Unsigned request blocked | PASS |
| V-002 | Tampered payload rejected | PASS |
| V-003 | Replay attack blocked | PASS |
| V-004 | Expired timestamp rejected | PASS |
| V-005 | Approved intent executes | PASS |
| V-006 | Denied intent blocked | PASS |
| V-007 | Ledger hash chain integrity | PASS |
| V-008 | Receipt signature valid | PASS |
| V-009 | Forged signature rejected | PASS |
| V-010 | Direct access without approval blocked | PASS |
| EG-001 | Execution gate full flow | PASS |
| EG-002 | Receipt lookup verification | PARTIAL |
See VERIFICATION_RESULTS.md for detailed results and THREAT_MODEL.md for the complete threat analysis.
| Document | Description |
|---|---|
| Architecture v2.7 | System architecture, invariants, module map, deployment topology |
| Three-Power Separation | Observer / Governor / Executor specification with permission matrix |
| API Catalog v2.7 | Complete 43-endpoint catalog with auth requirements and examples |
| White Paper v2 | Technical white paper on governed execution |
| White Paper (Formal) | Formal specification of the RIO protocol |
| Enterprise Overview | Enterprise FAQ, deployment models, ROI, and case studies |
| Receipt Specification v2.1 | Receipt schema with ingestion provenance and identity binding |
| Threat Model | 12 threat vectors (T-001 to T-012) with mitigations |
| Deployment Guide | Production deployment on Render with PostgreSQL |
| Gateway Architecture | Gateway internals, route map, and middleware chain |
| Mantis Component | Observer/ingestion layer component definition |
| Demo Walkthrough | Step-by-step demo with curl commands |
rio-system/
├── gateway/ # Production governance gateway (Node.js, deployed on Render)
│ ├── config/ # Policy and constitution configuration
│ ├── execution/ # Execution gate and token validation
│ ├── governance/ # Policy evaluation, approval logic, kill switch
│ ├── ledger/ # PostgreSQL-backed append-only hash-chained ledger
│ ├── receipts/ # Cryptographic receipt generation (Ed25519)
│ ├── routes/ # API routes (intake, signers, sync, proxy)
│ ├── security/ # Signature verification, replay prevention
│ └── tests/ # Gateway integration tests
├── demo-site/ # Interactive demo site (3-perspective walkthrough)
├── corpus/ # Governing corpus (policies, directives, agent definitions)
├── docs/ # Documentation
│ ├── architecture/ # Architecture diagrams and wiring docs
│ ├── whitepapers/ # White papers (v1, v2, Formal, The Structural Read)
│ ├── guides/ # Deployment, verification, and handoff guides
│ ├── enterprise/ # Enterprise positioning and FAQ
│ ├── security/ # Security policies, invariants, roles spec
│ └── reference/ # System overview, master document, code audit
├── spec/ # Formal specifications
│ ├── THREE_POWER_SEPARATION.md
│ ├── MANTIS_COMPONENT.md
│ ├── Receipt_Specification_v2.1.json
│ └── [component schemas]
├── internal/ # Working notes and development artifacts
├── archive/ # Historical code iterations (preserved for reference)
├── CONTRIBUTING.md
├── THREAT_MODEL.md
├── VERIFICATION_RESULTS.md
└── DEMO_WALKTHROUGH.md
RIO implements a fail-closed enforcement model. The default state is deny. Execution is structurally blocked unless every condition is met.
Ed25519 Cryptographic Signatures. Every receipt is signed with Ed25519. Signatures are generated server-side and can be independently verified. The signing key never leaves the server.
SHA-256 Hash-Chained Ledger. Every ledger entry includes the hash of the previous entry. Any modification to a historical record breaks the chain and is immediately detectable. The ledger is append-only — there is no update or delete operation.
Single-Use Execution Tokens. Every approved action receives a unique token. The token is consumed on execution and cannot be reused. Replay attacks are blocked at the structural level.
Fail-Closed Execution Gate. The execution gate requires a valid approval, a valid token, and a valid signature. If any element is missing, expired, or invalid, the gate does not open. There is no fallback, no override, and no bypass.
Server-Side Enforcement. All governance logic runs server-side. The frontend cannot bypass policy evaluation, forge approvals, or skip the execution gate. The client is a view layer — the server is the authority.
11 of 12 security verification tests pass. See VERIFICATION_RESULTS.md and THREAT_MODEL.md.
The cryptographic receipt and ledger layer has been extracted into a standalone open standard:
rio-receipt-protocol — Receipt schema, tamper-evident ledger, verifier CLI, and conformance test suite. Zero dependencies. Any AI system can implement RIO Receipts to produce verifiable audit trails without adopting the full RIO gateway.
git clone https://github.com/bkr1297-RIO/rio-receipt-protocol.git
cd rio-receipt-protocol
node examples/basic-usage.mjs # Complete flow demo
node tests/conformance.test.mjs # 45 conformance tests
node cli/verify.mjs remote https://rio-gateway.onrender.com # Verify live gatewayThis repository (rio-system) is the reference implementation and full governance platform built on top of that protocol.
- Governance pipeline: 7-stage intake-to-ledger flow, production-deployed
- Gateway: Node.js reference implementation on Render with PostgreSQL
- Cryptography: Ed25519 signatures, SHA-256 hash chains, single-use tokens
- Three-Power Separation: Observer, Governor, Executor with enforced boundaries
- Demo site: Interactive 3-perspective walkthrough at riodemo-ux2sxdqo.manus.space
- Formal specifications: Receipt protocol v2.1, component schemas, policy definitions
- Open standard: RIO Receipt Protocol extracted as standalone repo
- Security: 100+ verification tests, threat model with 12 vectors, 11/12 passing
- Governing corpus: Policy definitions, agent roles, witness records
- Agent adapter layer for multi-AI orchestration (Claude, GPT, Gemini)
- Enterprise SSO integration
- On-premise deployment option
- SDK for third-party integrations
- Advanced policy engine with conditional approval workflows
See CONTRIBUTING.md for guidelines on reporting issues, suggesting improvements, and submitting code.
You set the rules. The system enforces them. Every decision is visible, traceable, and provable.