Spend Policy and Reservations

The kernel can govern tools that declare a spend effect. A spend declaration is trusted capability metadata: it identifies the amount in integer minor units, ISO 4217 currency, merchant identity, and merchant category. Tool input and model output cannot replace the registered declaration.

Policy decisions

A host supplies a trusted operator policy with an accounting currency, period and period cap, single-action hard cap, approval threshold, categories that always require approval, and allowed merchant identities and categories. Invalid amounts, currencies, merchant identities, and categories are denied before an instrument is issued.

Hard-cap, currency, merchant, category, and period-cap denials cannot be overridden by approval. An action at or above the approval threshold, in an always-ask category, or with an unknown amount is held for the existing exact-input approval flow. An unknown amount remains held until a finite amount or a human-approved maximum is bound to that same approval. A changed request needs a new approval.

The host’s trusted operator policy is the active spend authority. The passport spend_limit remains descriptive where the explicit supersede option applies; it is not a second cumulative budget. The kernel calls SpendCeiling in live dispatch for the per-action hard cap. A durable event-log ledger serializes shared operator-period reservations across concurrent runs and retries.

Reservation and reconciliation

The kernel claims the stable task/action identity and reserves the approved amount before an issuer call. It commits an authorization hold before dispatch, so a timeout or retry cannot issue a second authorization automatically. Opaque instruments are scoped to reservations. Raw instrument material is excluded from durable events, evidence, logs, and model-visible output.

A hard-cap refusal prevents authorization and the financial effect. During recovery, a denial is terminal only when the kernel has authentic evidence that no dispatch occurred. If an earlier attempt may have reached the issuer and the durable state cannot prove otherwise, the action remains held for reconciliation; an error-code string alone is not proof that no effect occurred.

The vendor-neutral payment-instrument port reports authorization, capture, refund, and exception facts. Matching duplicate events are idempotent. Authenticated issuer facts that do not match the reservation are retained as exceptions and counted against the cap. An unresolved currency settlement blocks further reservations until a trusted reconciliation is recorded. Kernel checks constrain authorization requests; they cannot guarantee that an external issuer provides trustworthy merchant identity/category data or prevents forced capture.

Late exceptions are kept in the durable spend ledger with a pending owner-notice intent. A host-bound active observer delivers the notice through the kernel’s E3 owner-notice authority and only then marks it delivered. Retrying after a crash coalesces the notice; the completed purchase task remains terminal. The internal spend_ledger_transition and spend_operation_claimed events stay in the local ledger: public event streams, authenticated task inspection, and lifecycle Control Plane sync expose neither event nor its private ledger fields.

This page describes the kernel/reference behavior. It does not claim a hosted payment provider, hosted Cloud integration, or production issuer verification. See the policy engine for deny-wins evaluation and tool execution for the dispatch boundary.