Provable decisions for AI agents.
CoorRe is a verifiability engine: it turns the evidence and decisions of a process into signed, anchored proof that anyone can check. On Solana, the program enforces who can act and the limit of autonomy; above the limit, only the human approver can release the payment.
Select a step to see it in a real devnet case.
Each step is signed by the key of the role that owns it.
Runs the seven checks in this browser against the chain.
Check an audit trail without trusting whoever produced it. The evidence, signatures and hashes are checked in this browser with the same Rust code as the command line; only public account addresses are sent to a Solana RPC to read what the chain recorded.
Anyone checks a trail on this page or on the command line, with no login and no account. Whoever holds an audit bundle and its documents can verify it; the chain holds only hashes, keys, states and amounts.
Views by role and viewing keys, so each party sees only what its role needs. Not part of this build.
Cases from the devnet demos of 2026-10-08 and 2026-10-10 (synthetic data).
Drop bundle.json and the artifact files here, or choose them. Add accounts.json from docs/evidence/devnet-snapshot to verify with no network request.
The expected program never comes from the bundle: a bundle could name a program written by anyone.
| Step | Actor | Decision | Signed at | On-chain |
|---|
Every case that ran on Solana devnet, with synthetic documents. Choose one to see each signed step, the amount against its mandate and its state on the chain now.
Bars show the payment; the tick marks how far the rule engine may approve alone. Anything past the tick needs a person.
| Case | Rule | Payee | Amount | Limit | Outcome | Run |
|---|
The rules the verifier ships. A rule approves only when every condition holds; otherwise it escalates with one reason per failed condition, and the mandate check always comes last. A decision that names any other rule, version or hash fails check 7.
Reasons recorded by the rule engine across every escalated case.
The program that enforces the mandate, read live from devnet, and what each recorded run cost.
Payments released to payees and the network cost of each run: rent kept by the case records and evidence anchors, plus transaction fees. Escrow refunded after a rejection returned to the creator.
What each control checks, and what this build does not claim. The full threat model is in docs/SECURITY.md.
| Threat | Control | Where it holds |
|---|---|---|
| An automated actor approves above its mandate | The program rejects it with MandateExceeded; only the approver key can take an escalated case further | On-chain |
| One key plays several roles | The four role keys of a case must be distinct (RolesNotDistinct) | On-chain |
| A transition signed by the wrong key | Every signer is checked against the role stored in the case record | On-chain and check 4 |
| Evidence replayed or reordered | Each step must point to the hash of the previous one | On-chain and check 5 |
| A rule engine approves what the rule would not | The verifier re-runs the rule named in the evidence on the documents and compares the result | Check 7 |
| A bundle that names its own program or rule | The expected program and the rule registry ship with the verifier and never come from the bundle | Checks 6 and 7 |
| An edited document | Its digest no longer matches the evidence, and the decision can no longer be reproduced | Checks 1 and 7 |
| Hostile bundle content in the browser | Rendered as text only, under a strict content security policy | This page |