Enruta

Docs · preview

Policy

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

What a policy expresses

RuleExampleEnforced by
Payee allowlist and verification statestore.enruta.ai, verified payee onlyEnruta; merchant lock on a single-use card
Per-payment cap≤ $200Enruta; card amount = mandate amount
Cumulative budget≤ $1,000 per calendar monthEnruta, reserved atomically at decision time
Time windowBusiness hours, expiry 15 minutesEnruta; card expiry
CategoryOffice supplies (MCC 5943, 5111)Enruta; rail MCC controls where offered
Approval threshold> $150 needs the controllerEnruta step-up; nothing is minted before the approval
Duplicate and idempotency checksSame payee, amount and reference inside 24 hEnruta
Sanctions screeningPayee against current listsEnruta

Atomic budgets

Budgets are reserved when a decision is made and released or consumed when the rail posts. Ten concurrent agents cannot each pass the same $100 check, because the first reservation lowers the budget the others see.

Enforced twice

Enruta decides first, then compiles the decision into the control the rail itself offers: 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. If Enruta is wrong, the rail still refuses anything outside the mandate. If the rail is loose, Enruta already refused.

Versions

Policies are immutable once signed. An edit creates version n+1; mandates issued under n remain valid until they expire or are consumed, and every record names the version it was decided under. Your auditor can read version 7 in 2033 exactly as it was in 2026.

Fail closed

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