AI can act. ARIA decides what gets through.
Every decision is linked to the one before it. When ARIA admits an action, it is bound to its history, and that history can be re-derived and verified on demand.
Decision 1 · arrivedACCEPTREASONpolicy satisfiedCASEcase-ins-0911-0042STEPclaim_receivedJURISGB · InsuranceRECORDa7f3…c912LATENCY0.509 msLINK first in caseDecision 2 · arrivedACCEPTREASONpolicy satisfiedCASEcase-ins-0911-0042STEPclaim_validatedJURISGB · InsuranceRECORD8b2c…e417LATENCY0.509 msLINK → a7f3…c912VERIFIEDAll sample views are synthetic, not real recorded data.
One event tells you what happened. The chain tells you why.
You can't insert history. The chain proves what happened.
CASE sample-2026-0911-0042Insurance · UK-FCAreceivedACCEPTclaim_submittedref a7f3…c912first in case LINK VERIFIED✓ VERIFIEDvalidatedACCEPTclaim_validatedref 8b2c…e417links to a7f3…c912 ✓ LINK UNVERIFIED✗ UNVERIFIEDpaidREJECTclaim_paid · attempted insertionref c7a0…39d1SYS_001The claimed connection to this case cannot be found in the recorded history. LINK VERIFIED✓ VERIFIEDapprovedACCEPTclaim_approvedref d4e1…f293links to 8b2c…e417 ✓ LINK VERIFIED✓ VERIFIEDpaidACCEPTclaim_paidref f9a7…b156links to d4e1…f293 ✓Six industries. One chain of proof.
ARIA protects systems of record in any industry running autonomous AI. One kernel does the same job everywhere — the rules come from configuration, not re-engineering, so a new vertical is a policy decision, not a product change.
Six sample chains below — each one a set of steps against a real industry workflow:
K · 65.12Insurance & UnderwritingClaim lifecycle: received → validated → approved → paid4-step
receivedACCEPTclaim_submittedvalidatedACCEPTclaim_validatedapprovedACCEPTclaim_approvedpaidACCEPTclaim_paidSample chain from Insurance & Underwriting. Each row shows a step and its link to the one before it.
C · 28.99Supply Chain & ManufacturingShipment lifecycle: created → confirmed → packed → collected → in transit → exit cleared → arrived → import cleared → delivered → closed10-step
createdACCEPTshipment_createdconfirmedACCEPTsupplier_confirmedpackedACCEPTgoods_packedcollectedACCEPTcarrier_pickupin transitACCEPTshipment_in_transitexit clearedACCEPTexport_customs_clearedarrivedACCEPTarrival_confirmedimport clearedACCEPTimport_customs_cleareddeliveredACCEPTdelivery_confirmedclosedACCEPTshipment_closedSample chain from Supply Chain & Manufacturing. Each row shows a step and its link to the one before it.
O · 25.40Aerospace & DefenseMission lifecycle: requested → authorized → validated → assigned → rules verified → reviewed → closed7-step
requestedACCEPTmission_requestedauthorizedACCEPTmission_authorizedvalidatedACCEPTpre_mission_validatedassignedACCEPTasset_assignedrules verifiedACCEPTroe_verifiedreviewedACCEPTmission_reviewedclosedACCEPTmission_closedSample chain from Aerospace & Defense. Each row shows a step and its link to the one before it.
D · 35.11Energy & Grid InfrastructureGrid rebalancing: forecast issued → constraint cleared2 chains
forecast issuedACCEPTforecast_generatedconstraint clearedACCEPTconstraint_management_resolvedtrade openedACCEPTtrade_initiatedtariff acceptedACCEPTtariff_acceptedSample chain from Energy & Grid Infrastructure. Each row shows a step and its link to the one before it.
K · 64.19Banking & Financial ServicesCredit application: submitted → identity verified → screening cleared → closed4-step
submittedACCEPTcredit_request_submittedidentity verifiedACCEPTkyc_completedscreening clearedACCEPTaml_screening_completedclosedACCEPTcase_closedSample chain from Banking & Financial Services. Each row shows a step and its link to the one before it.
F · 41.20Construction & Heavy IndustryArrival check: arrival detected → identity requested → identity verified2 chains
arrival detectedACCEPTworker_arrival_detectedidentity requestedACCEPTidentity_verification_requestedidentity verifiedACCEPTidentity_verification_completedaccess requestedACCEPTworker_access_requestzone entry requestedACCEPTworker_zone_entry_requestshift startedACCEPTworker_shift_startedSample chain from Construction & Heavy Industry. Each row shows a step and its link to the one before it.
Bridging the AI Liability Gap
Guardrails watch the words. Sandboxes guard the machine. ARIA guards the action. That is the point where an AI actually does something. If policy says no, it doesn't happen.
| Capability Dimension | Advisory Guardrails | Infrastructure Sandboxes | ARIA Micro-Hypervisor |
|---|---|---|---|
| Primary Focus | Content & Prompt Filtering | OS Memory & Syscall Security | The Action Itself |
| Execution Point | In-Process / Sidecar HTTP Proxy | VM / Kernel Hypervisor Barrier | Hardware & API Boundary |
| Failure Mode | Fail-Open (Text Fallback) | VM Crash / OOM Kill | Fail-Closed (POL_002/AUTH_001 Block) |
| Audit Trail | Cloud Log Analytics | OS Syslogs / stderr | Ed25519 Signed WORM Ledger |
| Privacy & Retention | Single Payload Log (GDPR Risk) | Unstructured Disk Writes | CAS Dual-Layer (GDPR Art. 17 + SOX) |
| Capital Impact | Tooling Expense | Infrastructure Overhead | £200M–£500M Capital Reserve Release |
Three steps. No extra infrastructure.
A potential action — a claim update, a mission order, a shipment move — arrives at the boundary. Only well-formed, identifiable actions proceed.
A fixed pipeline checks the action against identity, policy, jurisdiction, and licence. Same input + same conditions → same decision. ~0.5 ms.
The decision — accepted or rejected — is written to a tamper-evident record, linked to the case's history, and survives as the system's native output: an audit receipt.
Show a regulator. It already reads itself.
Months of decision history. Reconstructed on demand. Chain-checked and tamper-evident. Regulator-ready.
RECONSTRUCTION — case sample-2026-0911-0042 Vertical: Insurance · Jurisdiction: UK-FCA History: 4 steps · 18 months step 1 received ACCEPT ref a7f3…c912 · first in case step 2 validated ACCEPT ref 8b2c…e417 · links back to a7f3…c912 ✓ VERIFIED step 3 approved ACCEPT ref d4e1…f293 · links back to 8b2c…e417 ✓ VERIFIED step 4 paid ACCEPT ref f9a7…b156 · links back to d4e1…f293 ✓ VERIFIED CHAIN INTEGRITY VERIFIED RECONSTRUCTION PASS (the case was re-derived from the recorded history) SIGNED RECEIPT <synthetic signature marker>
All sample views are synthetic, not real recorded data. Hash values are display markers only.
What regulators seeUnable to verify is a rejection. Not a maybe.
If a decision cannot be fully checked — missing policy, missing identity, missing case history — it is rejected. There is no silent pass.
There is no shortcut path and no quiet fallback.
Regulators do not accept “probably”. Neither does the kernel.
Every rejection is itself recorded, with its plain-language reason — the record carries the “no”.
POL_002
The proposed action exceeds the limits set in the governing policy.
AUTH_001
The identity of the actor could not be verified.
SYS_001
The action references a prior step the system has not recorded.
LIC_001
The deployment licence could not be validated for this jurisdiction.
TTL_005
The recorded time of the action falls outside the accepted window.
ESC_004
The proposed action goes beyond the agreed operating boundaries.
Sub-millisecond adjudication on a 15-watt device.
Measured on a constrained reference platform with the full pipeline active — the boundary is fast enough to sit in front of every action.
Benchmarks re-run on each release and published in the technical registry. Sample figures — not site claims in isolation.
One system, mapped to seven regimes.
All statuses are self-assessed architectural alignment against requirement-by-requirement mappings — not a live certification. The alignment papers live in the Library and the statuses are re-checked on every release.
The Ordinis Library
Straight answers.
01What exactly does ARIA do?
It is the boundary where AI-proposed actions are checked against identity, policy, jurisdiction, and licence before they are allowed to happen — and the record of that check is the product.
02How is this different from an AI gateway or an LLM security layer?
Gateways route traffic and manage spend; input-screening layers inspect a prompt and score it. ARIA sits below them at the state layer: it adjudicates and chains every decision into a reconstructible, verified history. They are complementary, not competing — see /layers.
03What does decision chaining give me that a log store doesn't?
Logs are claims. ARIA links each decision to the ones before it in the case, re-derives the state of any case from its recorded history, and detects any attempt to change the past.
04Can ARIA reconstruct a decision from months ago?
Yes. The system re-derives the case from its recorded history and confirms the result matches what was recorded. This runs continuously as the governance report's verification step.
05What happens when ARIA cannot fully evaluate a decision?
It fails closed. A decision that cannot be fully checked is rejected with a plain-language reason, and that rejection is itself recorded.
06Which industries and jurisdictions does it cover?
ARIA can be deployed to govern AI systems of record in any enterprise industry (Healthcare, Banking, Defense, Telecom, Supply Chain, Insurance, Energy, Construction, and custom internal runtimes). Adding a vertical, domain schema, or jurisdiction is 100% policy configuration, requiring zero kernel code modifications.
07What does a regulator actually see?
A signed, chain-checked reconstruction receipt for any decision: the full history from the first step, each link's verified status, and the re-derivation result. See the forensics page.
Book an evaluation. Bring a real deployment. Leave with a record you can verify.
In-person talks for risk officers, security researchers, and audit teams. No account. No browser scripts.