For example, an AI-assisted enrichment change estimates $100 per day, permits up to $160 under its controls, and has only $40 per day authorized. The implementation passes correctness and security checks, but each imported record triggers four paid operations, plus possible retries.
A passing test does not authorize a recurring bill.
Expected cost, controlled maximum, and authorized allowance answer different questions: what spending is likely, what the implementation permits, and what the budget owner has approved. Release approval needs to reconcile all three.
The policy boundary is the new spending commitment, not whether an AI tool wrote the code. Apply the same boundary to human-written changes: recurring costs need budget authorization distinct from technical approval, supported by enforceable workload limits.
Review the billable behavior, not the size of the diff
A short change can alter the economics of an entire workload. Reviewers need to identify what starts being billed, what multiplies it, and what stops it.
| Change | Cost driver to examine | Boundary to establish |
|---|---|---|
| Paid API integration | Requests, payload size, billable failures, retries | Allowed operations, usage ceiling, and behavior when exhausted |
| Background job | Schedule frequency, records scanned, overlapping runs | Maximum work per run, concurrency, and cancellation behavior |
| Storage retention | Data growth, copies, retention duration | Retention rule, deletion behavior, and treatment of existing data |
| Workload fan-out | Child tasks per input, recursive expansion, reprocessing | Maximum expansion and a shared work budget |
An existing integration is not automatically within budget. A change from one request per account to one request per event can create a new commitment without adding a new vendor.
Likewise, a configurable limit is useful only if it constrains the billable behavior. A per-worker request cap does not bound aggregate usage when the worker count can grow.
Calculate both expected use and the controlled maximum
The enrichment example uses these inputs:
- 10,000 eligible records per day.
- Four paid operations per record.
- An average of 1.25 billable attempts per operation, including retries.
- A price of $0.002 per attempt.
Its estimated daily API cost is:
10,000 × 4 × 1.25 × $0.002 = $100
At the same workload for 30 days, that is $3,000 in API charges. It excludes compute, storage, network charges, and any other fees.
Now suppose the implementation permits one retry per operation. With a fixed daily input ceiling and no other request paths, the maximum is two attempts per operation:
10,000 × 4 × 2 × $0.002 = $160 per day
The $100 estimate helps plan spending. The $160 bound describes exposure under the stated controls. Against the existing $40 daily authorization, neither amount is approved. The team must obtain additional authority or reduce the workload.
One option is a shared limit of 20,000 billable attempts per day, corresponding to $40 at the assumed price. That limit is meaningful only if every relevant request path reserves capacity before sending, retries consume the same allowance, and exhaustion stops further calls. Pricing changes or additional fees require a separate allowance.
With those controls, the API exposure fits the existing daily allowance. But some enrichment work must be deferred or skipped. The cost owner approves the spending; the service owner accepts that consequence.
A cap is also a product behavior decision.
Separate technical approval from spending authority
Assign two responsibilities, even when one person is authorized to hold both:
- Technical verifier: checks the cost model, workload evidence, enforcement mechanism, and failure behavior.
- Cost owner: has authority over the affected budget, accepts the proposed operating range, and decides what happens when demand exceeds it.
The code author should supply the evidence. The reviewer should challenge it. The cost owner should authorize the commitment.
A name in a pull request is not enough. The owner needs authority over the relevant budget and a defined path for responding to breaches. Where a change affects several budgets, assign a lead owner and record any additional approvals required by company policy.
Every allowance should specify its authorization period, such as a daily ceiling, a bounded trial, or a defined operating term.
| Decision | Conditions | Required action |
|---|---|---|
| Proceed within an existing envelope | Aggregate exposure stays within a documented allowance for its authorization period; existing controls still apply | Record the evidence and cite the prior authorization |
| Obtain new spending approval | Exposure is bounded for the period, but adds a commitment or exceeds the existing allowance | Obtain cost-owner approval of the range, limits, period, and service trade-off before release |
| Hold the release | Ownership or authority is missing, exposure is unbounded, or evidence is insufficient to assess it | Narrow scope, add controls, gather evidence, or obtain authorization |
A low expected bill does not establish maximum exposure. When a hard spending cap is unavailable, finite inputs or an enforced duration can bound billable work if the controls also constrain retries, fan-out, and other relevant cost drivers. Access restrictions help define which workloads can consume the allowance.
Concurrency limits the spending rate, not cumulative spending.
Pair it with a finite workload, enforced duration, or aggregate allowance to establish a bound for the authorization period. Account for in-flight work and delayed shutdown. If the remaining exposure cannot be assessed or authorized, the release should wait.
Deployment permissions: An AI workflow that proposes reviewed patches can use the normal release gate, adding cost review when relevant. Permission to deploy, create scheduled jobs, or modify quotas requires approval checks before those actions take effect. The requirement follows the workflow's permissions, not the fluency of its generated explanation. Formatting changes and local refactors do not need a full cost review unless they introduce or materially alter billable behavior.
Use a spending approval checklist
Copy this checklist into the change record so the commitment, controls, and authority can be reviewed alongside the implementation.
| Group | Required fields |
|---|---|
| Billable behavior | Billing unit, affected budget, workload assumptions, evaluation period |
| Cost and exposure | Expected cost, high-use case, controlled maximum, price source |
| Enforcement | Limit location, exhaustion behavior, residual exposure, responder |
| Evidence | Workload results, billable-unit counts, billing mapping, limitations |
| Authorization | Budget owner, approved allowance and period, additional approvals, reapproval triggers |
Workload assumptions should cover input volume, fan-out, retries, concurrency, and retention where relevant. Record calculations for expected use and a high-use case, plus maximum work or spending during the authorization period, including in-flight requests.
Specify whether exhaustion stops, queues, or degrades work, or requires manual approval. Name who responds and how escalation works.
Billing evidence should connect application activity to observed billable units and identify the source of prices. Record excluded charges, untested bursts, simulated billing, and assumptions awaiting validation. Reapproval is required when changes in price, volume, fan-out, retries, retention, or enforcement invalidate the earlier authorization.
For a representative check, exercise ordinary inputs, large inputs, and failures that trigger retries in an isolated environment. Use synthetic data and mocked paid services where appropriate. Count attempted billable operations, not just successful business transactions.
Mocks can validate request accounting and stop behavior, but they cannot establish how a provider will bill real requests. Where that distinction matters, reconcile against applicable billing documentation or a separately authorized, bounded trial before widening access. Without usage evidence, treat the calculation as a planning estimate. A restricted trial can collect that evidence under its own approved allowance; it should not silently become an unrestricted rollout.
For a five-minute start, take one pending change and fill in four fields: billable unit, workload multiplier, stopping condition, and budget owner. A blank field identifies a decision still needed before release. Completing the fields identifies missing decisions; it does not itself authorize spending.