What is a RIO Receipt?
A RIO Receipt is a cryptographic record of an AI action, written to a tamper-evident ledger. It allows an organization to prove exactly what an AI system did, when it did it, which system was responsible, and that the record has not been altered. When a governance layer is present, receipts can also prove whether a human approved the action.
A receipt proves
Every field is real. Every hash is verifiable. If any byte changes, the chain breaks.
Any AI system can produce receipts. Any third party can verify them. The proof layer works standalone — no governance, no approval workflows required. Just cryptographic proof of what happened.
Start Building
$ git clone https://github.com/bkr1297-RIO/rio-receipt-protocol.git$ cd rio-receipt-protocol$ node examples/basic-usage.mjs # full flow demo$ node tests/conformance.test.mjs # 29/29 passing
Zero dependencies. Node.js standard library only. Works with any AI platform.
No AI system may execute any real-world action — send an email, write a file, call an API, move money — unless it has been explicitly authorized by the sovereign human authority and the authorization has been cryptographically recorded.
Three layers.
One gate.
The system is a cross-section of three horizontal layers. The top layer is where AI models think and form intents. The bottom layer is where real-world tools execute. Between them sits the gate — the only path from intent to action. Nothing passes through without authorization and a receipt.
Three powers.
Structurally separated.
No single component in the RIO system can observe, decide, and execute. The separation is enforced at the API boundary level — not by convention, but by architecture. A violation triggers an automatic system halt.
Observer
Ingests all signals — API calls, emails, webhooks, SMS. Classifies risk. Writes to the ledger. Cannot approve. Cannot execute.
Governor
Evaluates policy. Issues approval or denial. Generates single-use execution tokens. Cannot read raw data. Cannot call tools.
Executor
Calls real-world tools — Gmail, Drive, GitHub. Only acts with a valid signed token. Burns the token after use. Writes receipt to ledger.
Cross-Boundary Violation Detection
If any component attempts to call an API outside its designated power boundary, the system logs a BOUNDARY_VIOLATION event, halts the pipeline, and requires human review before resuming. This is enforced at the middleware level — not by trust, but by architecture.
Four steps. Every time.
Every action in the system follows the same four-step sequence. No shortcuts. No exceptions. The protocol is the product.
Intent
The AI agent describes what it wants to do in a structured format: who is asking, what action, on what target, with what constraints.
Governance
The gate checks the intent against policies. If the confidence score is below 90%, the system pauses and asks the human authority.
Execution
Only after authorization does the connector execute the action — send the email, save the file, call the API.
Receipt
A cryptographic receipt is generated: SHA-256 hash of the action, linked to the previous receipt in a hash chain. Immutable. Verifiable.
Rules that
never change.
These are the non-negotiable constraints of the system. They cannot be overridden by any agent, any policy, or any configuration. They are structural, not behavioral. The system is physically incapable of violating them.
Five components. Nothing more.
Ledger
Append-only database storing every receipt in a hash chain
Gateway
The server that receives intents and enforces the gate
Approval UI
The human interface — see the intent, approve or deny
Connectors
Adapters for Gmail, Drive, GitHub, Calendar, and more
Policy Engine
Learns patterns and suggests auto-approve rules over time
Five models.
One architecture.
Five independent AI systems — Manus, Claude, ChatGPT, Gemini, and Grok — were each given the same problem. Without seeing each other's work, all five converged on the same architecture: a gate, a ledger, a receipt, and a pause. The pattern is structurally true.
The system is live.
This is not a mockup. The RIO gateway is deployed on Render.com with a PostgreSQL-backed immutable ledger, Ed25519 cryptographic signing, and fail-closed enforcement. Connect below to see the real-time state.
Click "Connect to Gateway" to fetch live status from the production RIO gateway.
First connection may take ~30s (Render free tier cold start).
Verify it yourself.
Every receipt in the RIO system uses SHA-256 hashing. The same algorithm used by Bitcoin, TLS, and digital signatures worldwide. Click below to generate a real hash in your browser.
This computes a real SHA-256 hash in your browser. The same algorithm secures every RIO receipt.
{
"receipt_id": "rio-rcpt-2026-03-29-001",
"timestamp": "2026-03-29T17:48:00Z",
"actor": "manus-agent-v1",
"action": "gmail.send",
"target": "[email protected]",
"status": "AUTHORIZED",
"authorized_by": "brian.kent.rasmussen",
"content_hash": "a3f8c2d1e9b7...4f6a",
"previous_hash": "7e2b9d4c1a8f...3c5e",
"signature": "ECDSA-secp256k1"
}IBM published the first reference architecture
for quantum-centric supercomputing.
On March 12, 2026, IBM unveiled the industry's first blueprint for how quantum processors and classical supercomputers work together as one integrated system. RIO is the governance layer that ensures human sovereignty as these systems become interoperable. The same pattern. The same need. A reference architecture for hybrid systems that require governance to work together.
Recent Receipts
Every governed action produces a cryptographic receipt recorded in the immutable ledger. This feed shows the most recent receipts from the live production gateway.
Click "Load Receipts" to fetch the latest receipts from the production gateway.
This endpoint is public — no authentication required.