Paths and names
- Action: lowercase, dot-separated segments. Each segment starts with a letter and continues with lowercase letters, digits, or underscores:
flight.book,payout.release,compute.reserve. Maximum 100 characters. - Attribute names: start with a letter, then letters, digits, or underscores, up to 64 characters. A proposed action carries at most 32 attributes.
- Constraint paths:
attributes.<name>,payment.amount, orpayment.currency. A policy carries 1 to 32 constraints, at most one per path. - Attribute values: strings, integers, or booleans. Dates are
YYYY-MM-DDstrings.
Operators
All constraints use logical
AND, and exactly one constraint may target each path. There is no coercion, case folding, wildcard, regex, locale processing, timezone conversion, floating point input, or Unicode normalization.
Fail-closed evaluation
- A present value that violates a constraint produces
DENY. - Missing, incorrectly typed, or unsupported data produces
INDETERMINATE. - Neither result creates a reservation, and
can_executeis false for both. - A different valid action name produces
DENYwithout evaluating unrelated constraints.
Payment authority
A policy either has no payment paths, or exactly one positivepayment.amount with operator max (a cap) or eq (an exact amount), plus one uppercase three-letter payment.currency with operator eq. Amounts use integer minor units, so 15000 means EUR 150.00. A policy with no payment paths authorizes only proposed actions that carry no payment.
Example: booking
One city, a check-in window, and a price cap. The dates are inclusive, so2026-11-01 and 2026-11-30 are both inside the window.
Example: payout
One contractor from an allowlist, one milestone, and the exact agreed amount.eq on the amount means a different amount is refused, even when it is lower.
Example: recurring budget
A subscription budget caps each purchase here; the monthly cadence and the per-period budget are Mandate terms, not policy constraints. See Core model for the full RECURRING request.in constraints.
