Axorum documentation

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

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

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

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.

Branch on the verdict, never on the status code

An HTTP error means the request was malformed, the agent was not who it claimed, or the policy pin was stale. It never means the policy said no. A policy saying no is a successful, meaningful, recorded outcome — and it arrives on a 200.

Recorded under override

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

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

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.

If the winning rule forbids the action, or if no rule applies at all: ForbiddenRecorded when an authorized override accompanies the proposal, otherwise ForbiddenRejected.
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.

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.