19 — Cost and FinOps Checklist#

Verify that technology spending is attributable, visible, forecastable, and optimized for business value without compromising required quality, reliability, security, or user outcomes. FinOps is a shared product, engineering, finance, and procurement practice—not simply a directive to minimize the cloud bill.

Scope: AI-specific. This file is one part of the 19_Cost_and_FinOps.md checklist. Apply the domain-wide release gate across all applicable scope files; each checklist ID remains unique.

Review details#

• Project / product:
• Release / version / environment:
• Scope and applicable jurisdictions / markets:
• Cost scope / providers / billing currency:
• Budget, forecast, and allocation policy references:
• FinOps / product / engineering / finance owners:
• Reviewer / owner:
• Review date:
• Decision: Pending / Approved / Approved with documented exceptions / Blocked

How to use#

1. Copy this reusable checklist into project-specific review records; leave the shared template unchecked.
2. Mark [x] only after verification from provider billing data, ownership metadata, cost forecasts, approved budgets, utilization measurements, unit metrics, or documented decisions. Record failed checks and genuine N/A rationales in project-specific notes or issues using their COST IDs; do not add evidence tables to this repository template.
3. Tailor controls to the technology costs that apply: cloud resources, SaaS, licenses, data platforms, vendor APIs, AI inference, or on-premises infrastructure. Not every project uses commitments, multiple providers, chargeback, or business-unit unit economics.
4. Review ## API Checks and ## Frontend Checks independently where relevant. If one surface does not exist, document N/A and why in project records.
5. Revisit cost baselines, forecasts, allocation rules, and guardrails after major demand, architecture, provider, contract, pricing, or launch changes. Review material contractual and financial decisions with qualified stakeholders.

Forecasting and optimization#

• COST-083 Define financial guardrails for new services, experiments, generative AI workloads, and tenant-level demand spikes where relevant.

Release gate#

• The release has named product, engineering, and financial owners for its material technology costs, with an approved allocation approach for shared and direct costs.
• Budget, baseline, forecast, principal assumptions, and potential cost-impacting launch or growth scenarios are documented at an appropriate level of detail.
• Critical spending and usage reports reconcile to trusted provider or financial data within accepted tolerances, and material unallocated charges are explained or assigned for investigation.
• Budget threshold, unusual-spend, and quota alerts or equivalent guardrails have owners and a tested escalation route appropriate to release risk.
• Significant compute, storage, data-transfer, SaaS, API, and frontend cost drivers are reviewed for avoidable use without undermining performance, accessibility, security, or reliability commitments.
• Applicable API and frontend operations have controls against unbounded or duplicate billable actions, with appropriate behavior when quotas or limits are reached.
• Any material over-budget forecast, unaffordable unit economics, unapproved commitment, or other significant cost risk has an explicit authorized disposition and remediation owner.

Domain-specific approval rule: Block cost readiness approval if material spend is unowned and invisible, foreseeable high-impact cost exposure lacks acceptable bounds, or a required budget/contract approval is missing. Meeting a cost target does not justify bypassing legal, security, quality, accessibility, or reliability requirements.

Trusted references and scope#

These review questions are informed by the following primary FinOps and architectural guidance. Source recommendations are not universal compliance obligations; adapt them to the workload and commercial model.

• FinOps Foundation — FinOps Framework — cross-functional technology cost accountability, value, and operating model.
• FinOps Foundation — Allocation — cost ownership, tagging and hierarchy, shared cost treatment, and allocation coverage.
• FinOps Foundation — Anomaly Management — detection, routing, investigation, and resolution of unplanned spend.
• FinOps Foundation — Forecasting — forecast models, business drivers, scenarios, and variance tracking.
• FinOps Foundation — Unit Economics — aligning technology unit costs to product/business outcomes.
• FOCUS — FinOps Open Cost and Usage Specification 1.3 — standardized billing vocabulary and cost/usage data when compatible datasets are used.
• FOCUS — Cost and Usage dataset — distinct billed, effective, contracted, and list cost fields; billing period and metadata.
• Microsoft Azure Well-Architected — Cost Optimization checklist — financial responsibility, budgets, guardrails, unit cost, utilization, optimization, and trade-offs.
• Microsoft Azure Well-Architected — Cost Optimization — usage, rate, and continuous optimization principles.

Applicability: FOCUS 1.3 provides a published data specification, not an assertion that every provider export is FOCUS 1.3-compatible or that 1.3 is the newest version. Cloud-specific rate models and tagging practices do not apply unchanged to every SaaS, AI, data center, or on-premises product. Account for billing delays, discounts, currency, shared services, and business value before claiming realized savings.

Source review date: 2026-11-12.

Suggested testing tools#

Choose tools appropriate to the project's stack and risks; automation supports evidence but does not approve the checklist.

• Test focus: usage tagging, budget alerts, cost estimates, and anomaly scenarios; include model and dataset behaviors where applicable.
• Cross-stack: Infracost.
• Python: Cloud Custodian + pytest; for pytest-based suites, run python -m pytest -q.
• TypeScript: Vitest; for Vitest-based suites, run npx vitest run (or npx playwright test for E2E).
• JavaScript: Jest; for Jest-based suites, run npx jest --ci (or npx playwright test for E2E).
• Evidence: Save tool versions, configuration, test environment, fixtures, results, and links in project-specific review records using the existing checklist IDs. Expert review remains necessary where relevant.

Suggested AI skills for verification#

These are optional agent review aids, not automated passes or release approval. Each linked repository had at least 1,000 GitHub stars when checked on 2026-11-12; counts are per repository, not per skill, and do not indicate security or correctness.

• cost-optimization — Review resource costs and attribution (wshobson/agents, 42,437 repo stars).
• cost-analysis — Review Azure cost data when applicable (microsoft/skills, 3,198 repo stars).
• aws-cost-optimize — Review AWS spending where applicable (github/awesome-copilot, 41,073 repo stars).

How to check: In a project-specific copy, have the agent audit the AI-specific scope and map findings to this file's existing checklist IDs, with code/configuration references, reproducible test results, failed or inapplicable cases, and uncertainties. Independently verify findings; keep shared template boxes unchecked and retain human approval requirements.

Before use: Read the skill's SKILL.md, referenced scripts, license, and requested tool permissions. Only execute vetted skills with appropriate access in a controlled environment.

Important warning: reference only#

⚠️ Reference only — not a definitive or exhaustive checklist. This template is a starting point for review, not the ultimate authority or a guarantee of project safety, quality, regulatory compliance, accessibility, security, or launch readiness.

Use project-specific judgment and independent verification. Requirements and risks evolve and differ by project, technology, and jurisdiction. Adapt the checks, consult current authoritative sources, perform relevant tests, and obtain qualified specialist review or approval when appropriate. Checking every box does not replace these steps.