Route by policy and enforce a budget

Verifiedon 2026-07-292026.7.1

Routing is a policy decision

A route should answer, in plain language: which work qualifies; what must never take this route; the quality and service thresholds; what budget applies; what happens at a limit; and who can make an exception. “Use local first” is not a policy. It lacks a data boundary, a quality gate, and an owner.

Build the decision ledger

Use observed measurements where you have them and label estimates as estimates. Keep cost/resource calculations legible: quantity, unit basis, time window, assumptions, and source of each number. For local capacity, include the operational costs you chose to count and state what is excluded. A spreadsheet can be honest; a single blended “savings” number often is not.

Lab: write a budget scenario

Take a fixed monthly ceiling and a conservative volume assumption. Show the arithmetic in your ledger, then test three cases: normal use, a volume spike, and a failing preferred route. For each, decide whether the system pauses, degrades to a smaller safe task, requires approval, or rejects work. A quota that cannot explain its failure mode is just a surprise waiting for a Friday.

Checkpoint

A provider invoice differs from a planning estimate. What should the team change first?

The ledger’s assumptions and the decision policy, after checking the measurement basis. Do not retrospectively call the old estimate a fact. Preserve the variance; it is evidence for the next review.

Learner artifact — policy gate: Draw input classification → data-policy check → quality eligibility → capacity/service check → budget check → selected route or human escalation. Add a visible audit event after every branch, including rejected work.

Boundary note

No OpenClaw-specific configuration keys are supplied here. Apply a policy only after the implementation path has been verified against the current primary documentation and tested in a non-production environment.