Policies & rules

A policy pack is what the rules are — you write it. A profile is which controls must exist and what must be recorded — the standard writes it. Getting these two confused makes every later sentence wrong, so they are never the same file.

The one rule about rules: they are data, never code

The pressure on this will be constant. Every sufficiently expressive policy format is eventually asked for a way to run a small snippet, and each individual request is reasonable. The answer that holds is the one above.

What a pack looks like

tesoro init writes tesoro.yaml (which profile, which pack, where evidence goes) and policies/default.yaml — the rules, which are yours to edit. JSON is accepted everywhere YAML is.

version: 1
name: default

config:
  treasury:                        # the external channel
    balance_usd: "500"
    per_transaction_usd: "10"       # a ceiling, never accumulates
    daily_usd: "50"                 # cumulative
    monthly_usd: "300"
    per_vendor_30d_usd: "100"
    per_resource_30d_usd: "50"
    emergency_reserve_usd: "10"
    velocity_60s: 10                # a rate, not a total
    velocity_1h: 100
    actions_per_day: 500            # a total. omit for no limit; 0 forbids everything
    actions_per_month: 10000

  treasury_internal:               # tokens; overrides only what it names
    per_transaction_usd: "0.04"     # one run's token budget
    daily_usd: "0.15"

rules:
  - id: deny-sanctioned
    priority: 0                    # lowest number decides first
    when:
      vendor.sanctioned: true
    then: REJECT
    reason: sanctioned counterparty

  - id: review-budget-exhausted
    priority: 10
    when:
      budget.ok: false
    then: REVIEW
    reason: outside a budget envelope

Every amount is a string. A YAML number would have lost precision before anything read it, and the test vectors check exactly this.

The fixed vocabulary

Ten comparators

eq, ne, in and not_in are null-safe; the ordering comparators are not, because “is an unknown score greater than 0.7” has no honest answer and inventing one is how the four-state rule gets broken.

Twenty facts a rule may read

rules:
  - id: unvetted-counterparty
    priority: 1
    when:
      vendor.jurisdiction_state: undeclared
    then: REVIEW
    because: nobody has said where this counterparty is

The pack is validated at load, in full, or it is not loaded. An unknown fact name, an unknown comparator or a verdict that is not one of the four is a startup error rather than a surprise at run time — because a rule that never matches never validates, and a pack could otherwise carry a verdict of MAYBE and look fine until the one request that touched it arrived.

Derived facts: composition without execution

“amount over $100 and the vendor is new” needs no new measurement, only composition. That is a derived fact — still data, built from the same fixed comparators with three fixed connectives:

derived:
  - name: risky_newcomer
    all:                          # all | any | not
      - amount_usd: {gt: "100"}
      - vendor.is_new: true

rules:
  - id: review-risky-newcomer
    priority: 20
    when:
      risky_newcomer: true
    then: REVIEW

What makes this safe is the closure: a pack that could introduce a fourth connective could introduce logic.

Envelopes: the part a per-payment cap cannot express

Rules are evaluated in order, and the first match decides

By priority, lowest number first, with the rule id as the tiebreaker so two rules at the same priority resolve the same way every time. tesoro report --html prints the rules in evaluation order with each condition in plain terms, because the question anybody actually has before a run is which rule is going to stop me — and a count of rules cannot answer it.

Pri  Rule                        When                              Then      Because
0    deny-sanctioned             vendor.sanctioned                 REJECT    sanctioned counterparty
5    deny-over-balance           not budget.ok and budget.binding  REJECT    insufficient balance
                                 is one of balance, emergency_re…
10   review-budget-exhausted     not budget.ok                     REVIEW    outside a budget envelope

Profiles: what the standard requires, not what you want

A profile is a conformance contract. It says which controls must exist and what evidence must be emitted — and it never touches a verdict, which is asserted four different ways in the test suite. Switching profile changes what is scored, never what is decided.

The distinction between the last two is load-bearing, and getting it wrong punished honesty: an earlier scorer treated intentId: null as a failure. But a stated null is an implementation saying “no intent was declared”, which is true, useful, and exactly what the four-state rule asks for. MUST_RECORD needs the key present, not non-null.

none lists every control rather than being an empty file, so the shipped manifest is the implementation's own answer to “which controls are defined” — and a profile that extends another may only tighten, checked by a tool.

Two extension points, and why there are exactly two

A registered engine can only narrow. That is not a rule it is asked to respect — the combination step takes the most severe verdict, so widening is unreachable rather than refused. A hostile engine can refuse things; it cannot approve anything.

Reference