Core concepts
Verdicts
Every commit resolves to exactly one of five outcomes. The verdict is the atomic object of the system: what Axorum produces, what the audit trail records, and what an agent has to reason about.
The five outcomes
Finance reading
Each outcome is a decision about a payment and the authority behind it. Every one of them is recorded, including the ones where nothing moved.
Engineering reading
Each outcome is stated below in the register a controller would use, followed by the formal name it carries on the wire and the shape it arrives in.
Permitted
Finance reading
The payment was allowed and posted. The person or system that authorised it had the standing to do so, nothing prohibited it, and it left no commitment outstanding.
This is the quiet case. The books moved and the matter is closed.
Engineering reading
Permitted — HTTP 200, posted: true, no obligation effects.
The policy in force had a rule permitting this actor to perform this action, no prohibition survived defeat, and the commit created no obligation instance. The provenance names the winning rule and the norms that applied.
Refused
Finance reading
The payment was declined, and the decline is on the record: who asked, under what authority, and why it was refused. Nothing crossed the books.
Either a control forbade it, or — just as often — no control permitted it. Nothing is allowed by default, so a payment nobody authorised is a payment nobody may make.
This is the point most easily missed, so it is worth stating flatly: a refusal is a control, not a failure. Nothing went wrong. The system did precisely what it exists to do, and the record of it is evidence — a preventive control, on the books, naming the rule that stopped it. This is what you show a risk committee. It is not an alarm reporting a loss; it is proof that a loss did not occur.
Engineering reading
ForbiddenRejected — HTTP 200, posted: false, the refusal record persisted with full provenance.
A rule forbade the action, or no rule applied at all: the policy is deny-by-default, so an unmatched action is refused rather than allowed. The transaction reached the commit point, was evaluated, and produced a record; it simply produced no entries.
The recording of the refusal is the product. Do not treat it as an exception path.
Finance reading
Engineering reading
Recorded under override
Finance reading
The payment was forbidden, an authorised approver overrode the control, and it posted with the exception on the record. The approver is named.
Organisations override their own controls. A system that refuses to model that does not prevent the override; it pushes it off the ledger, into a phone call or a spreadsheet, where it cannot be reviewed. Here the exception is a first-class entry: it is on the books, attributed, and it stays there.
An agent cannot approve its own exception. The authority to override comes from outside it.
Engineering reading
ForbiddenRecorded — HTTP 200, posted: true, the violation recorded in the provenance alongside the authorising party.
A prohibition won the verdict, but the proposal carried an authorised override marker. The entries post and the violation is retained. The override's authoriser is recorded for audit; who may override is a substrate privileged-path concern, not something the proposing agent can supply for itself.
Obligation processing still runs: a forbidden-but-recorded commit discharges, breaches, and incurs duties, because it committed.
Duty now open
Finance reading
The payment posted, and in posting it, it created a commitment that is now outstanding. A receipt is owed, an approval is due, a report has to be filed.
The money side is settled. The authority side is not, and it will not settle itself: the commitment has a due date, and if nothing satisfies it, it becomes an exception.
Engineering reading
ObligatedPending — HTTP 200, posted: true, one or more obligation instances left in the open set.
The commit instantiated a duty. obligations_pending on the outcome carries every open obligation for this actor after the commit, each with its state and deadline. The duty is now queryable state and will breach on the deadline sweep if nothing discharges it.
Duty discharged
Finance reading
The payment posted, and it satisfied a commitment that was outstanding. The receipt was filed; the approval came through. The loop an earlier transaction opened is now closed, and the ledger records which transaction closed it.
Engineering reading
ObligatedFulfilled — HTTP 200, posted: true, one or more open obligation instances transitioned to Discharged.
The committed action matched the discharging action of an open duty. The instance is terminal, and the discharging transaction id is the link between the duty and its resolution.
Precedence
Exactly one outcome is chosen, in this order.
Finance reading
- If a control forbids the payment, or if no control permits it: it is recorded under override when an authorised approver has overridden the control, and otherwise it is refused.
- Otherwise, if the payment left a commitment outstanding: duty now open.
- Otherwise, if the payment satisfied an outstanding commitment: duty discharged.
- Otherwise: permitted.
The order matters. A payment can both settle one commitment and create another; it reports as duty now open, because the new commitment is the fact that still requires something of somebody.
Engineering reading
- If the winning rule forbids the action, or if no rule applies at all:
ForbiddenRecordedwhen an authorized override accompanies the proposal, otherwiseForbiddenRejected. - Otherwise, if this commit left an obligation open:
ObligatedPending. - Otherwise, if this commit discharged an obligation:
ObligatedFulfilled. - Otherwise:
Permitted.
The order matters. A commit can both discharge one duty and open another; it reports as ObligatedPending, because the open duty is the fact that still requires something of somebody.
Finance reading
A refusal has no effect on outstanding commitments at all: nothing was satisfied, nothing was incurred, nothing fell due, because nothing happened. An exception that posts under override does affect them — it happened, and commitments follow what actually happened, not what was permitted.
Engineering reading
Obligation processing runs if and only if the transaction commits. A ForbiddenRejected verdict carries no obligation effects and leaves the open set unchanged. A ForbiddenRecorded commit does discharge, breach, and incur duties: duties follow committed actions, not the modality of the winning norm.
The two readings
The verdict is one fact with two renderings, and neither is a summary of the other. This page has been showing you one of them.
The controller's reading is plain compliance English, in the vocabulary of their own chart of accounts, counterparties, and periods: "Refused. The clerk may not purchase from a counterparty outside the approved set." The engineer's reading is the formal record: the winning rule, its priority, the norms that applied and were defeated, the obligation instances that transitioned, and the content hash of the policy bundle that governed all of it.
Both are generated from the same typed structure the evaluator decided on, under a faithfulness contract: every semantic element is rendered, and nothing is overclaimed. The English is not a caption written next to the decision. It is the decision, said in words.
The selector in the header switches this site between the same two registers. It is the product's own principle, applied to its documentation.
What follows
The rules that produce these outcomes are written in the policy language. The commitments that the last two outcomes turn on move through the obligation lifecycle.