Core concepts
The dual-law commit
Every commit enforces two laws at once. The books must balance, in every quantity they conserve, and the authority must balance. A transaction posts only if both hold, in a single atomic step, with no window between them.
Two laws, one commit
Double-entry bookkeeping has survived five hundred years because it makes a class of error impossible rather than merely detectable. If debits do not equal credits, the entry is not a bad entry; it is not an entry. The constraint is structural.
Axorum adds a second constraint of the same kind, and enforces it in the same step.
The conservative law
Finance reading
Debits equal credits, in every currency, across every line of the entry. This is the invariant your books already run on, with one deliberate widening: an entry carries as many lines as the transaction really has, not two, because real entries split across accounts.
Amounts are held in whole minor units — cents, not fractions of them. Nothing in the posting path rounds.
And money is where this law starts, not where it ends. The same books conserve three more quantities, each a running balance the engine keeps rather than a report it compiles. An agent's cumulative spending can never pass its mandate's ceiling — however many transactions it takes, refunds included. Revenue can never be recognized beyond what is still deferred. And no bill can run ahead of the meter, nor the meter ahead of what was actually delivered. A transaction that would break any of them is refused whole, in the same step.
The books balance, in every quantity they conserve, or nothing posts.
Engineering reading
Debits equal credits, per currency, across every leg of the transaction. The classical invariant, with one deliberate widening: two to thirty-two journal legs rather than exactly two, because real accounting entries split.
Amounts are integer minor units in checked 128-bit arithmetic. There is no floating point anywhere in the commit path.
The same pass conserves three more chains, each per-object and cumulative, validated fully before anything mutates: mandated ≥ executed (spending mandates, including hierarchical sub-mandate roll-up), deferred ≥ recognized (revenue/cost matching, a dynamic ceiling), and 0 ≤ billed ≤ metered ≤ consumed (usage balances: phantom usage and meterless billing are refused at the commit, not found at close). Policy-declared aggregate registers — counts and sums over committed actions — are maintained in the same commit, O(1), never recomputed at decision time.
The books balance, or nothing posts.
The normative law
Finance reading
The action was permitted under the controls in force at the moment it happened, and every commitment it touches is accounted for. Commitments it satisfies are closed. Commitments it creates are opened. Commitments that fell due are marked as exceptions, and whatever the policy requires because of the exception is opened in turn.
The authority balances, or nothing posts.
Engineering reading
The action was permitted, obligated, or forbidden under the policy in force at commit time, and every obligation the transaction touches is accounted for. Duties it discharges are closed. Duties it incurs are opened. Duties that fell due are breached, and any contrary-to-duty reparation they carry is instantiated at the breach tick.
The authority balances, or nothing posts.
Why it must be one commit
Finance reading
The obvious alternative is to check the payment against policy, and then, if it passes, write the entry. Almost every system in production works this way. It is wrong in a specific and expensive way.
Between the check and the write there is a gap. In that gap the policy can change, the approval can expire, the counterparty can drop off the approved list, or another payment can consume the budget the check just verified. The system will then post a payment its own policy forbids — and the audit trail will say it was approved, because at the moment it was checked, it was.
For a payment a person initiated, this is usually survivable: the person is still there to notice. For a payment an agent initiated, it is not. The agent is gone, nobody notices, and the books say everything was fine.
Axorum closes the gap by removing it. The decision and the entry happen together, against the same state, in one step. There is no interval in which the two can disagree, because there is no interval.
Engineering reading
The obvious alternative is to run an authorization check, and then, if it passes, write the entry. Almost every system in production does this. It is wrong in a specific and expensive way.
Between the check and the write there is a window. In that window the policy can change, the delegation can expire, the counterparty can fall off the approved list, or a concurrent transaction can consume the budget the check just verified. The system will then post an entry that its own policy forbids, and the log will say it was authorized, because at the moment it was checked, it was.
For a human-initiated transaction this is usually survivable, because a human is still around to notice. For an agent that has already exited, it is not. Nobody notices, and the books say it was fine.
Axorum closes the window by removing it. The verdict and the entry are computed in the same state transition against the same state. There is no interval in which the two can disagree, because there is no interval.
Finance reading
Engineering reading
Determinism is what makes it hold
Finance reading
The decision does not depend on which machine made it, or when it was made, or in what order the lines happened to arrive. The same transaction, against the same controls, produces the same decision — every time, on every copy of the ledger.
That is not a technical nicety. It is what makes the record evidence. An auditor holding a transaction and the version of the policy it names can re-run the decision and must arrive at the identical result, character for character. A control whose outcome could not be reproduced would not be a control; it would be an opinion that happened to be recorded.
It is also why the policy version is captured on every entry. Last March's transaction is still judged by last March's policy, permanently.
Engineering reading
The commit is a pure function of its op sequence. Policy evaluation reads no wall clock, uses no floating point, performs no external calls, iterates in no unspecified order, and has a bounded cost. Time enters as an explicit tick supplied by the substrate, never read from the machine.
This is not stylistic. It is what lets the same verdict be reached bit-for-bit on every replica in a consensus group, which is what lets the ledger be replicated at all. A ledger whose control decisions depend on which machine evaluated them is not a ledger; it is a set of opinions.
It also means an auditor holding the transaction and the policy bundle it names — by content hash — can replay the evaluation and must obtain the identical provenance record. The provenance is self-contained. Replay is meaningful because determinism makes it meaningful.
The shape of a commit
Finance reading
A request arrives carrying five things: which agent is asking and what it has been attested to do, the lines it proposes to post, the action it says it is performing, any evidence it cites, and the version of the policy it believes is in force.
Identity is settled at the door. An agent that cannot prove who it is, or that is acting outside what it was authorised to do, is turned away before the ledger ever sees the request — and that is a rejected request, not a refused payment. It never reaches the books.
What reaches the books is a proposal from an identified, authorised actor. The ledger then does exactly one thing with it: it posts, under both laws, or it does not.
Engineering reading
An intent arrives at the gateway carrying five things: who the agent is and what it is attested to do, the journal legs it proposes, the deontic action it claims to be performing, the evidence it references, and the policy it believes is in force.
The gateway is the one place where non-determinism lives. It resolves the agent:// identity, verifies the PASETO capability attestation, and joins the delegation — checking not only that the agent is who it says, but that the action it proposes falls inside the scope and window it was delegated. Authentication failures never reach the ledger, and never produce a verdict.
What reaches the ledger is a proposal, and the ledger does exactly one thing with it: it commits, atomically, under both laws, or it does not.
1{2 "verdict": "ObligatedPending",3 "posted": true,4 "policy": "b2f4e1c0a7d3...c19d",5 "obligations_pending": [6 {7 "rule": "receipt_within_48h",8 "state": "Active",9 "deadline": 144710 }11 ]12}13
The transaction posted. It also opened a commitment, and that commitment is now first-class, queryable state — the trial balance for obligations, sitting alongside the trial balance for money.
What follows
The commit resolves to exactly one of five verdicts. The rules it is judged against are written in the policy language. The commitments it opens and closes move through the obligation lifecycle.