Limits

What you can bound

• Who can be paid, and who cannot, whatever the reason given.
• How much, over what period, and until when.
• How much of that may go to payments that cannot be reversed.
• What the money is for, so a budget for one thing is not spent on another.

The one most stacks do not have

A budget can allow a large payment that can be reversed and refuse a much smaller one that cannot, because those are not the same risk. A card charge you can dispute at $4,200 and an on-chain transfer at $50 are different exposures, and treating them as the same number is how agent budgets quietly fail.

outcome: "deny"
reasons: ["Only $50 of this budget can go to payments that cannot be
          reversed. It is already used."]
checks:  [{ id: "irreversible_outlay", passed: false }]

Standing authority, in detail

A single monthly cap is the version everyone builds. The real model carries a per-payment ceiling, a validity window, and up to six periodic allowances at once, one for each period type: day, week, fortnight, month, half-year and year. Six is not a chosen number; it is one per type, and two of the same type is a validation error.

Anniversary or calendar

Each allowance sits on one of two alignments. On the consent anniversary, a month runs from the day authority was granted. On the calendar, it runs from the first of the month, and the first period is pro-rated by the days actually available, counted as whole local days.

That is why a time zone is required and never defaulted, even when no allowance is calendar-aligned. Pro-rating rounds down exactly once, so rounding can only ever shrink an allowance rather than quietly grow it. Calendar fortnights are refused outright, because the calendar defines no fortnight boundary and inventing one would be us guessing.

Totals are not the only shape

Two dimensions a total cannot express, because they are different harms:

• A burst ceiling over a rolling window. Rolling, not resetting: a window that resets admits twice the ceiling across the boundary and publishes a schedule to concentrate against.
• A sustained rate, as a bucket that refills. It opens full, which is deliberate, and it can go into deficit.

Every dimension binds independently and each charges the full amount. There is no combined utilisation score, and that is a decision rather than an omission: collapsing them costs throughput and produces the worst possible refusal, the one that fires while you are under every limit you actually set.

A refusal names the parameter

A refusal reports every breach rather than the first, and each one names the exact parameter and field that tripped, with the limit, what is spent, and what remains. An allowance carries headroom as a report, not as a budget: nothing is ever charged against it.

The whole model fails closed. An unreadable history, an unparseable instant, a mismatched asset or any validation problem denies everything rather than falling back to a permissive default. The validity window is exclusive at the end, so a payment at the closing instant is refused.

They travel, and they narrow

When your agent hands work to another agent, the limits go with it. The second agent can be given less than the first had, never more, and nothing it says about itself changes that. Delegation that widens authority is the failure mode that makes multi-agent systems dangerous with money, so it is not expressible here.

Where they are enforced

Outside the agent, in the decision point the agent calls but does not control. That is the whole design: an agent can be wrong, be confused, or be compromised, and the limit still holds because the agent was never the thing holding it.

Stopping everything

There is a stop, it needs the operator credential, and it takes effect before the next decision rather than after the current batch. Use it when something is wrong and work out what afterwards, using the record.

gl kill-switch engage --rationale "investigating unexpected spend"