21/09 edition: a budget alert does not authorise spending

The alert recipient is not necessarily the decision-maker

An SME schedules a product-description batch overnight. Its budget has an email warning, but nobody has stated whether the operator may continue the batch. The question selected here is who authorises new tasks after an internal boundary is reached.

We propose three separate states: a warning requiring investigation, a suspension preventing admission of new jobs and resumption requiring a recorded decision. This is an original design for the team to implement and test. We do not claim a cloud alert alone is an automatic cutoff or a maximum-spend guarantee.

Funding and forecasting are not the same

The FinOps Foundation frames Budgeting as approved funding and budget accountability. Forecasting supplies future-spend models to inform that funding. OWASP LLM06 recommends downstream authorisation. These three functions support our distinction between signal, decision and execution.

A boundary at the admission point

Our design places the check before admitting a new job, not after completing the batch. The budget owner approves a scope, window and allowance for work already in flight. The operator does not increase these values merely because an alert arrived.

With engineering, choose a control unit the system can observe: admitted jobs, tracked consumption or an estimated reservation per task. Record the difference between reservations and observed cost. If information arrives late or is missing, we propose suspending admissions until reconciliation. This does not promise cancellation of incurred charges or automatic interruption of every running task.

The failure that should be rehearsed

Hypothetical scenario: the alert arrives, the finance owner is absent and the queue continues growing. A tabletop exercise should ask the operator to explain behaviour without improvising authorisation. The proposed response is to maintain suspended admissions and preserve the queue, with a previously designated deputy deciding.

Another case introduces delayed consumption data. Check reservations, in-flight jobs and resubmission attempts. Do not accept a screenshot of the warning alone: require the rejected-admission record and identification of jobs that may still generate cost.

Resumption is a new, narrow authorisation

The matrix is an untested proposal. Each resumption should name the batch, reason, allowance, window and decision-maker. At expiry, the mechanism suspends new admissions again even if the queue remains non-empty. An operator can execute an approved resumption; they should not have to invent available funding.

How to close the episode

After the batch, compare reservations, observed consumption and the invoice when available. Record differences without automatically treating them as personal failures: instrumentation may be missing, an assumption may be wrong or a job duplicated. Product decides which descriptions remain necessary; finance decides funding.

For a Portuguese SME, the rule should fit a normal shift and survive the approver's absence. Retaining the decision and suspension test is more useful than adding alert recipients without authority. We do not present this design as an already effective control: the team must verify the cutoff point and state which costs remain beyond it.