# 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](https://www.finops.org/framework/capabilities/unit-economics/), [Allocation](https://framework.finops.org/framework/capabilities/allocation/), [Usage Optimization](https://www.finops.org/framework/capabilities/usage-optimization/) and [Managing AI Value](https://www.finops.org/wg/managing-ai-value-finops-practice-operations/). Provider-control examples are documented in [Azure budgets](https://learn.microsoft.com/en-us/azure/cost-management-billing/costs/tutorial-acm-create-budgets), [AWS Budgets](https://docs.aws.amazon.com/cost-management/latest/userguide/budgets-managing-costs.html), and the [Claude Agent SDK loop](https://code.claude.com/docs/en/agent-sdk/agent-loop). These sources do not mandate this template or its pilot duration.