Guarantees and Boundaries
Read every economic claim Chio makes by its boundary class: what the kernel refuses before dispatch, what it records, and what it never sees.
On this page
An operator who lets agents spend money needs a contract for each promise the system makes about it: who keeps the promise, at which moment, and which record shows it was kept. Chio writes that contract in four boundary classes, the vocabulary every receipt carries in its boundary_class field: prevent, detect only, advisory only, and cannot see.
The class follows from position. Before dispatch, the kernel holds both the decision and the money, so holds, caps, and scope prevent. After dispatch, the provider, the payment rail, and the evaluator act, and the kernel signs a record of what each one reported.
preventThe worst case is held before dispatch
The kernel reserves the call's worst-case cost, the quoted cost or the grant's max_cost_per_invocation, and dispatches only after the hold is recorded. A hold that would carry committed spend past the grant's ceiling is refused, and the deny receipt records attempted_cost. Authoritative Spend.
- Enforced or recorded by
- the kernel's hold ledger
- Evidence
budget_authority.authorize.exposure_units
Each receipt states the class its claim belongs to
The class is a field of the signed record, so a consumer never infers it from prose. A receipt carries receipt_kind (mediated_decision, trace_observation, or advisory_evaluation) beside boundary_class, and the words a claim may use follow from its class:
| Class | Kernel position | A claim may say | A claim may not say |
|---|---|---|---|
prevent | In the decision path, before the effect | authorized, denied, fail-closed, pre-effect | observed only, advisory |
detect_only | Records after or beside the effect | observed, provider-reported, post-effect | mediated, authorized, protected |
advisory_only | Ranks and informs a choice | advisory, discovery, non-authorizing | capability grant, scope expansion |
cannot_see | Outside the mediated path | out of layer, not covered | blocked by Chio, mediated by Chio |
A consumer that needs spend it can rely on checks the class mechanically. A receipt counts as authoritative spend only when it is an allowed mediated_decision in the prevent class, signed by an admitted kernel key, with a reconciled hold that moved exposure under the chio.mediated_spend.v1 profile. Any other receipt fails the check with a named reason, such as NotPreventBoundary or HoldNotReconciled, so an advisory record can never be counted as money spent.
Read more in Authoritative Spend.
Holds, caps, and scope refuse before any money moves
Every prevent claim rests on one ordering: the kernel reserves the call's worst-case cost in its hold ledger, the single consumption authority for the budget, and dispatches only after that hold is recorded. In the Quickstart project, the fixer's USD 2.00 grant has USD 1.35 committed when a model call asks for a USD 0.80 worst case. Read the refusal:
const [refusal] = await project.history.receipts({ outcome: "deny", agent: fixer });
console.log(refusal.describe());receipt rcpt-01a8…6e11 request fixer invoke /models/default, worst case USD 0.80 verdict deny: budget, USD 1.35 committed of 2.00 class mediated_decision, prevent charged USD 0.00, attempted USD 0.80 grant cap-01a8…31f2 signed your kernel 4f1c…a2e9, signature verifies
refusal = project.history.receipts(outcome="deny", agent=fixer)[0]
print(refusal.describe())receipt rcpt-01a8…6e11 request fixer invoke /models/default, worst case USD 0.80 verdict deny: budget, USD 1.35 committed of 2.00 class mediated_decision, prevent charged USD 0.00, attempted USD 0.80 grant cap-01a8…31f2 signed your kernel 4f1c…a2e9, signature verifies
let refusal = project.history().receipts().outcome("deny").agent("fixer").first().await?;
println!("{}", refusal.describe());receipt rcpt-01a8…6e11 request fixer invoke /models/default, worst case USD 0.80 verdict deny: budget, USD 1.35 committed of 2.00 class mediated_decision, prevent charged USD 0.00, attempted USD 0.80 grant cap-01a8…31f2 signed your kernel 4f1c…a2e9, signature verifies
chio receipt explain rcpt-01a8…6e11receipt rcpt-01a8…6e11 request fixer invoke /models/default, worst case USD 0.80 verdict deny: budget, USD 1.35 committed of 2.00 class mediated_decision, prevent charged USD 0.00, attempted USD 0.80 grant cap-01a8…31f2 signed your kernel 4f1c…a2e9, signature verifies
USD 1.35 plus USD 0.80 would pass the ceiling, so the model never saw the request and the receipt charges nothing while recording the attempted cost. The same ordering carries every other claim in this class:
- Scope and policy. Admission checks the capability, the operator's guards, and any required approval before dispatch.
- Ceilings. Per-call and total limits bound each hold; a delegated child holds less than its parent, and a family cap bounds what siblings spend together.
- Unknown outcomes. A lost reply keeps its hold, and the kernel never dispatches the call a second time.
- Reconciliation. The charge is the reported cost up to the hold, and a failed currency conversion closes at the held amount.
- Prepayment. A grant that must prepay is refused before dispatch when no payment adapter is configured.
- Approval. An approved payment is bound to one request and one intent, and is used once.
- Shared resources. A partner's use of your model route is charged by your own hold ledger at your door.
Rails and evaluators decide after dispatch, and the receipt records their answer
Settlement and acceptance happen outside the kernel, so their claims are detect only. A payment rail (x402, ACP, or an escrow contract) plugs in as an optional module behind one payment adapter, and its outcome is folded into the receipt's settlement_status as pending, settled, or failed, with the rail's payment_reference. The adapter reads an x402 reply that omits its settled field as not settled.
A rail's answer never becomes authority. A settlement verifier report yields a tool-call decision that is always deny, so a payment proof, however valid, admits no call; only a capability does. On the work side, the evaluator you chose decides whether a submission meets its agreement, and Chio records that signed acceptance or rejection against the exact submission. Anchoring publishes receipt roots where an outside party can check inclusion, which is likewise a record of what was signed.
Read more in Settlement Rails, Verifiable Work, and Anchoring.
Listings, prices, and scores rank counterparties and grant nothing
A buyer chooses a provider from data the kernel never treats as authority. A marketplace listing stays visible only until an operator activates it. A provider's pricing hint, with its receipt volume and revocation rate, is an operator-attested claim an auditor can compare against the issuing operator's receipt log. Reputation scores, the behavioral-profile guard, and an oracle's PairHealthStatus inform and gate nothing, and EAS or Verax attestations are display projections that never stand in for an inclusion proof.
Advisory data becomes a limit only through a grant. An issuance policy can set a counterparty's budget ceiling from its reputation tier; the resulting ceiling belongs to the grant, and the hold ledger enforces it as a prevent claim.
Read more in Capability Discovery and Reputation Scoring.
Spend that never reaches the kernel is the deployment's to close
Every claim above is scoped to calls the kernel mediates. An agent that holds its own payment card or provider key can spend without a kernel decision, and no receipt records it. Your cap also stops at your resources: a partner's independently billed compute is metered by its own kernel, and a purchase made outside a pool's signed allocation is outside that pool's ledger.
The deployment closes these paths. The credential broker keeps provider keys out of the agent's reach, model and payment calls route through the kernel, and deployment hardening removes the remaining routes around it. A native effect outside the kernel path with no qualified confinement reads as unconfined on its receipt, which states the gap in the record itself.