Getting started
Introduction
Axorum is an accounting and control substrate for agent-driven payments. It sits between an agent's decision to spend and the rail that settles it, and it records or refuses the transaction at the moment it happens.
Finance reading
You are reading this in the finance register: plain compliance English, in the vocabulary of controls, commitments, exceptions, and reconciliation. Every page states the same facts in both registers, and the selector in the header switches between them. Nothing is hidden from one reading that the other is told — they are two renderings of one system, not two levels of detail.
Engineering reading
You are reading this in the engineering register: formal names, wire shapes, and the mechanisms underneath. The selector in the header switches the whole site to the finance register — the same facts, stated the way a controller would state them. It is the product's own principle applied to its documentation: the same fact, two readings.
Quickstart
Stand up a node, activate a policy, and submit your first intent.
Core concepts
The dual law, the five verdicts, policies, obligations, and agent identity.
Architecture
How the ledger is replicated, made durable, and read — and what leaves it.
SDKs
The Rust, TypeScript, and Python clients for the agent plane.
The problem
When a human initiates a transaction, the audit trail anchors in human intent. Somebody approved it, and that person can be asked why.
When an agent initiates it, the actor is stateless. It finishes its task and disappears. There is nobody left to ask. After-the-fact logging cannot govern an actor that no longer exists, because by the time the log is read, the only thing left of the decision is its consequences.
Payment rails answer a narrow question: is this payment cryptographically authorized to move value? That is a real question and they answer it well. It is not the question a controller asks. The controller asks whether the payment was semantically aligned with the buyer's policy and the seller's obligations, and no signature can answer that.
So the check has to happen at the moment of the transaction, on the participant's own books, or it does not happen at all.
What Axorum does
Finance reading
Axorum enforces two things at once, in a single step, at the moment the payment is proposed.
The first is the invariant your books already run on: debits equal credits. The money balances.
The second is the one the rails leave out: the payment was permitted under the controls in force at that moment, and every commitment it touches is accounted for.
A payment cannot post unless both hold. There is no gap between the two checks in which the books and the authority can disagree, because there are not two checks — there is one posting that satisfies both, or fails.
Every posted transaction carries its own record of authority: who authorised it, which commitments it settled, which prohibitions were tested, and the exact version of the policy that governed the decision. Intent becomes something you can query. Not "what happened," but "on whose authority, and settling what."
Engineering reading
Axorum enforces two invariants atomically, in one state machine, in one commit.
The conservative law is the classical accounting invariant: debits equal credits. The money balances.
The normative law is the one the rails leave out: the action was permitted, obligated, or forbidden under the policy in force at commit time, and every obligation it touches is accounted for.
A transaction cannot post unless both hold. There is no window between the two checks in which the books and the authority disagree, because there are not two checks. There is one commit that satisfies both laws or fails.
Every posted transaction carries a deontic provenance record: the authority invoked, the obligations discharged, the prohibitions checked, and the policy bundle, by content hash, that governed the verdict. Intent becomes queryable. Not "what happened," but "under whose authority, discharging which obligation."
Finance reading
Engineering reading
What it is not
It is not a payment rail. It does not move money, hold funds, or settle anything. It sits underneath the rails, on each participant's own books, and decides whether the movement should be permitted before the rail is asked to perform it.
Finance reading
It is not an approval workflow with a ledger bolted on. An allow/deny list cannot express "if a purchase exceeds five hundred dollars, obtain manager approval within two business days" — the commitment and the purchase that triggers it are different things, and the commitment outlives the transaction that created it. Axorum tracks commitments through their whole life, including what is owed when one is missed, and every agent's authority traces back to a named person who granted it.
Engineering reading
It is not an authorization service with a ledger bolted on. An allow/deny list cannot express "if a purchase exceeds five hundred dollars, obtain manager approval within two business days" — the duty and the action that triggers it are different things, and the duty outlives the transaction that created it. Axorum's normative side is a full deontic model with an obligation lifecycle, contrary-to-duty repair, defeasible rules, and a delegation chain that terminates at a human principal.
It is not an app. It is infrastructure. The correctness and the neutrality are the product; there is nothing clever on the surface by design.
Where to start
Read the dual-law commit for the mechanism, then verdicts for the five outcomes an intent can resolve to. Those two pages carry the model; everything else is detail hanging off them.
If you would rather see it run, install from source and work through the quickstart.