Enruta

Written once, enforced twice.

A policy is a signed, versioned object in your controller’s own approval-matrix terms. Every decision names the exact version it was made under.

Try it

A sample policy, evaluated in your browser.

payee→category→window→cap→budget→duplicate→screening→threshold→allow/step_up/denyany failed check denies; the budget is reserved at the moment it passes

pol_office_supplies · v7 · budget left $400.00 of $1000

Policy: verified payees only · office supplies or shipping · ≤ $200 per payment · $1,000 a month · above $150 a person signs.

decision

step_up

  • approval_required above $150: a named person must sign
approval: {
  required_from: "usr_controller", method: "passkey",
  binds: "sha256:<request hash>", expires_in: "15m"
}
mandate: null   // issued after the signature

In your controller’s terms

Payee allowlists and verification state, per-payment caps, cumulative budgets, time windows, categories, approval thresholds. The same words as your approval matrix, signed as a version.

Atomic budgets

A budget is reserved when a decision is made and released or consumed when the rail posts. Ten concurrent agents cannot each pass the same $100 check.

Enforced twice

Enruta decides, then compiles the decision into the rail’s own control: a single-use card for the exact amount at the named merchant, a spend limit scoped to one purpose, an approval bound to one bill.

Immutable versions

An edit creates version n+1. Every record names the version it was decided under, so an auditor reads version 7 in 2033 exactly as it was.

Fail closed

A request that matches no policy is denied with no_matching_policy. There is no default allow.

Duplicates and replays

Same payee, amount and reference inside the duplicate window is a deny. Same idempotency key returns the original decision, never a second mandate.

Policy reference in the docs