AI optimisation decision record
Template, authored 22 October 2026. Proposed management tool, not a statement about Knauf policy. Use one record for one bounded use case or optimisation intervention. Retain rejected options and evidence gaps so the next team can understand the decision.
1. Decision requested
- Use case / service ID:
- Business/product owner:
- Engineering/service owner and on-call:
- Finance/FinOps partner:
- Sponsor / decision authority:
- Decision date and next review:
- Requested action: scale / optimise / redesign / hold for evidence / pause / stop
- Specific change and expected business effect, in one sentence:
- Funding envelope, expiry, commitment exposure and rollback authority:
2. What work are we buying?
- Business outcome and why it matters:
- Acceptance criteria and rubric version:
- Unit counted in the denominator:
- Eligible task population and workload strata:
- Rework/reopening horizon; pending or unknown outcome treatment:
- Required quality, availability and latency limits:
- Evidence that the outcome has value; owner who can validate it:
- Current alternative or counterfactual if AI is not used:
- Constraints that cannot be traded away:
A generated answer or successful HTTP response is not automatically an accepted business outcome. Document when it is sufficient and who agrees.
3. Baseline and comparator
| Evidence | Baseline | Candidate | Source / observation period / uncertainty |
|---|---|---|---|
| Input tasks and workload mix | |||
| Accepted outcomes | |||
| Rejected / pending / unknown | |||
| Quality by relevant risk/complexity/language group | |||
| Model / API / metered service cost | |||
| Retrieval / tool / hosting cost | |||
| Human review / rework cost | |||
| Shared operating allocation | |||
| Cost per accepted outcome | |||
| End-to-end p50 / p95 latency; timeout rate | |||
| p95 / maximum task cost and retry/fan-out pattern | |||
| Metered estimate versus reconciled bill gap |
- Cohort selection and representativeness:
- Fixed prompt/workflow/model/rubric versions:
- Comparable currency, FX, discounts and cost scope:
- Sample size, uncertainty and important failure cases:
- Timing differences between execution, invoice and acceptance:
- Known missing data or sources that cannot be reconciled:
Do not roll out a candidate merely because mean cost falls. Check quality and service limits first. Unknown outcomes remain visible.
4. Economics of the intervention
Define an explicit horizon H reflecting expected workload life, contractual obligations and confidence. Use low/base/high scenarios; no fabricated precision.
| Economic input | Low | Base | High | Evidence / owner |
|---|---|---|---|---|
| Eligible accepted demand over H | ||||
| Avoidable cost reduction at matched workload | ||||
| Validated additional business benefit (separate) | ||||
| Implementation / migration / evaluation cost | ||||
| Added operations and maintenance over H | ||||
| Transition and risk allowance | ||||
| Net benefit over H | ||||
| Time until positive benefit |
net benefit_H = avoidable run-cost reduction_H + validated additional benefit_H − one-time change cost − added operations_H − transition/risk allowance_H
simple payback_months = one-time change cost / monthly net avoidable reduction
If monthly net reduction is zero/negative, payback is undefined. Use a proper discounted valuation where scale/horizon warrants it. Keep sunk cost separate from forward decisions.
- Which reduced costs will actually leave cash/contract outflow, and when?
- Which costs remain committed or become idle capacity?
- Which labour effect is released capacity rather than payroll saved?
- Which benefits are counterfactual cost avoidance?
- What important alternative work would the same engineers postpone?
- Are benefits overlapping with another proposed optimisation?
- What would falsify the forecast?
5. Feasible options and prioritisation
Reject any option failing required quality, security/operating constraints or service levels. Then compare feasible options.
| Option | Conservative net benefit | Engineering/evaluation effort | Time to benefit | Risk and reversibility | Evidence strength | Decision |
|---|---|---|---|---|---|---|
| Keep current approach | ||||||
| Small reversible change | ||||||
| Larger architectural change | ||||||
| Pause / stop / use alternative |
An aggregate weighted score is optional. It should not hide a failed quality gate or treat uncertain hypothetical savings as established cash benefits. The choice may be a short evidence-gathering experiment.
6. Runtime and funding controls
- Financial budget and funding review interval:
- Task limits: estimated spend, tokens, steps, retries, wall-clock duration:
- Fan-out / subagent / external tool allowances:
- Concurrency and in-flight allowance:
- Action at limit: queue / degrade / request approval / cancel:
- Critical-service fallback and incident contact:
- Test showing actual stop/fallback behavior, including concurrent requests:
- Known overshoot and unmetered-cost exposure:
- Rollback test and criteria:
Budgets and runtime caps are separate controls. Provider billing delays and post-response checks can allow overshoot; test the deployed configuration rather than relying on its setting name.
7. Thirty-day evidence plan
| Window | Owner | Observable output | Gate |
|---|---|---|---|
| Days 1–5 | Product + sponsor + finance + engineering | Outcome, cohort, baseline, owner and envelope agreed | Is the decision measurable and material? |
| Days 6–10 | Engineering + FinOps | Usage/cost/outcome joins and reconciliation | Is cost coverage sufficient for the claim? |
| Days 11–15 | Engineering + product | Driver analysis and ranked options | Is an intervention worth testing? |
| Days 16–23 | Service owner | Comparable evaluation; control and rollback tests | Does it preserve constraints and improve economics? |
| Days 24–30 | Sponsor | Written decision and benefit classification | Scale / optimise / redesign / hold / pause / stop |
8. Recorded decision and benefit follow-through
- Decision and concise rationale:
- Rejected options and why:
- What remains uncertain:
- Benefit classification: cash reduction / consumption efficiency / cost avoidance / capacity / quality:
- Finance-validated baseline and method:
- Named delivery owner and due date:
- Named benefit owner and first verification date:
- Next review and explicit stop/sunset condition:
- Evidence links and version IDs:
Supporting sources
This template is our synthesis. It is informed by FinOps Unit Economics, Allocation, Usage Optimization and Managing AI Value. Provider-control examples are documented in Azure budgets, AWS Budgets, and the Claude Agent SDK loop. These sources do not mandate this template or its pilot duration.