# Federal FinOps practice playbook

**Federal FinOps practice playbook · Draft reusable advisory playbook · 6 October 2026**

Use one repeatable process across clients. **Foundations supplies the variables, evidence and entry points; this book supplies the operating procedures.** Existing client personnel use those procedures to establish ownership, understand costs, evaluate choices and reconcile decisions with financial evidence. Our advisory role is to identify requirements, options, trade-offs and recommendations, then help the receiving team understand the proposed practice. Software acquisition, integration, operational execution and accounting changes require their own scope and authority. A client with established capabilities begins at its evidenced gaps, using the same book. The common process supports different applicable policies, allocation choices and targets; it does not prescribe identical answers regardless of evidence.

This unpacks the existing **FinOps / service catalog / chargeback / showback** catalog group: FIN-1 acquisition, ordering, funding and reversibility; FIN-2 consumption policy, budget structure and tagging; FIN-3 showback/chargeback and mission-owner visibility; FIN-4 commitments and anomalies; FIN-5 the continuous optimization loop. It creates no additional offering, contractual deliverable or assessment-engine change. **30 requests / 51 positions / 10 domains / 53 workstreams remain unchanged.** Foundations and the four extensions—Application Dependency Mapping, Enterprise Architecture & Operations, Zero Trust Preparation and Service-AIOps Readiness—share the resulting ownership and decision evidence.

## 1. Keep the method stable; populate the client facts

### Practice basis and authority

The FinOps Foundation is a Linux Foundation project. Its Framework is the practice basis for this book: collaborative technology value management, adapted to mission outcomes and the client's authority. The Framework is flexible rather than a prescribed implementation. Linux Foundation is the institutional home, not a second competing operating method. ([Foundation](https://www.finops.org/about/), [Framework](https://www.finops.org/framework/))

The six Foundation principles anchor the procedures: cross-functional collaboration, business value, distributed consumption accountability, timely and reliable information, central enablement, and use of variable-consumption economics. In this federal adaptation, value includes mission outcomes. **Inform → Optimize → Operate** is a repeating cycle: establish evidence, assess choices, then have empowered client owners act and measure. Different capabilities can move at different speeds; our advisory work prepares decisions and proposed procedures without claiming to operate the client practice. ([Principles](https://www.finops.org/framework/principles/), [Phases](https://www.finops.org/framework/phases/))

The September 24, 2024 **DoD Cloud FinOps Strategy explicitly builds on the FinOps Foundation framework**. It addresses IaaS, PaaS and SaaS, component alignment, reporting aligned with FOCUS, and connections to budgeting, governance, cybersecurity and portfolio decisions. These strategic directions do not prove that subsequent component policy is issued or that a universal tagging schema exists. DAF's 2024 CTO presentation places FinOps within its cloud direction; it is evidence of direction, not proof that every Air Force organization implements every practice. ([DoD strategy](https://dowcio.war.gov/Portals/0/Documents/Library/DoDCloudFinOpsStrategy.pdf), [DAF presentation, p.5](https://www.dafcio.af.mil/Portals/64/Documents/Strategy/TWICS%20Future%20of%20DAF%20IT%202024.pdf?ver=tfXX7wsCW7h6OczO9AEcSA%3D%3D))

**All exact procedures, fields, gates, templates and proposed cadence below are Cloud Waypoint recommendations.** Client owners adopt or amend them through existing authority. They are not Foundation mandates, government policy, demonstrated client controls or guarantees of savings. Foundation concepts are adapted under [CC BY 4.0](https://creativecommons.org/licenses/by/4.0/); source links identify the underlying guidance. This is not an official or endorsed Foundation or government publication.

### Stable core versus Foundations variables

| Keep stable across clients | Populate from Foundations and validate with client owners |
|---|---|
| Evidence precedes financial conclusions | Service boundary, accounts, technology categories, period, currency and exclusions |
| Every decision has an owner and an escalation route | Existing people, delegated authority, available capacity and accepted review calendar |
| Every cost has a treatment, including unresolved costs | Approved identifiers, financial mappings, direct/shared/central/unallocated rules |
| Historical attribution survives resource retirement | Available lifecycle records, ownership changes, source limitations and approved retention |
| Estimates, actual bills, allocation and drawdown stay distinct | Export versions, invoices, contracts, close procedures, corrections and eligible offers |
| Recommendations disclose benefit, risk and reversal conditions | Mission priorities, dependencies, funding constraints, risk tolerances and planned changes |
| Tools serve an agreed capability | Existing approved systems, manual workarounds, gaps and optional product evaluations |

Record each variable with **source, effective date, responsible validator and evidence state**: unknown, stated, evidenced or validated for the named scope/period; retain disputed and superseded states. These are book-level working labels, not new assessment scores. Mark a dependency assumed, observed or confirmed rather than upgrading an assumption through repetition.

### Choose the entry point independently for each procedure

| Entry | Evidence that supports it | Advisory result |
|---|---|---|
| Define | Missing owner, rule or source | Proposed decision, evidence request and unresolved gap |
| Rehearse | Proposed rule plus permitted sample | Completed fictional or separately authorized case, including an exception |
| Validate existing practice | Completed client record and traceable source evidence | Findings on arithmetic, lineage, authority and exceptions; retain sound local practice |
| Improve | Repeated comparable evidence | Prioritized recommendation and measurable acceptance criteria |

Reliable invoice reconciliation does not imply reliable ephemeral ownership. Start each procedure where its evidence permits. Foundation maturity is capability-specific; reaching Run everywhere is unnecessary, and sample maturity percentages are not universal thresholds. **No maturity rating authorizes spending, a change, data access or deployment.** ([Maturity model](https://www.finops.org/framework/maturity-model/))

### Connect the book to the current Framework

The four domains run concurrently; they are not four sequential project stages. The table maps this book to current capability names without requiring equal investment in all of them. ([Framework domains](https://www.finops.org/framework/domains/))

| Framework domain | Relevant capabilities | Procedures in this book |
|---|---|---|
| Understand Usage & Cost | Data Ingestion; Allocation; Reporting & Analytics; Anomaly Management | 2–5, 7 |
| Quantify Business Value | Planning & Estimating; Forecasting; Budgeting; KPIs & Benchmarking; Unit Economics | 2, 6, 10 |
| Optimize Usage & Cost | Architecting & Workload Placement; Rate Optimization; Usage Optimization; Sustainability; Licensing & SaaS | 8–10, where evidenced |
| Manage the FinOps Practice | FinOps Practice Operations; Governance, Policy & Risk; FinOps Assessment; Automation, Tools, & Services; FinOps Education & Enablement; Invoicing & Chargeback; Intersecting Disciplines; Executive Strategy Alignment | 1, 5, 11 and governance throughout |

## 2. Give existing people clear decisions and usable records

Start with functions, not a proposed new department. A virtual practice using existing finance and engineering staff is consistent with Foundation practice guidance; reuse governance and clarify who decides versus advises. ([FinOps Practice Operations](https://www.finops.org/framework/capabilities/finops-practice-operations/))

| Client function | Owns or decides | Supplies or reviews |
|---|---|---|
| Sponsor/program leadership | Scope, priorities, accountable owners and resources within delegated authority | Mission value and unresolved cross-team decisions |
| Service/mission owner | Demand assumptions, outcomes and service decisions within authority | Dependencies, acceptable quality, lifecycle and business impact |
| Finance/accounting | Financial dictionary, cost basis, allocation policy, close, corrections and authorized posting | Budget references, financial controls and reconciliation acceptance |
| Acquisition/contracting | Contract interpretation and purchasing route with counsel as appropriate | Executed terms, offers, eligibility and renewal/exit conditions |
| Platform/engineering/operations | Technical evidence and authorized operational execution | Creation paths, lifecycle records, feasibility, resilience and rollback |
| Security/data authority | Permitted access, handling and disclosure within its authority | Approved boundaries and metadata restrictions |
| FinOps coordinator | Convening, record quality, follow-up and escalation | Explainable analysis and recommendation register |
| Our advisory team | Requirements analysis and recommendation quality | Options, trade-offs, evidence gaps, rehearsal and handover |

A coordinator does not inherit another role's approval rights. Name people or existing teams in the client copy, identify delegates, and record the receiving team's capacity. Unfilled roles remain visible gaps.

### Proposed rhythm and measures

Use event-driven intake and ownership reviews; anomaly review aligned with data freshness and staff availability; financial review aligned with the client's actual close; forecast revision after material demand changes; and commitment review sufficiently before renewal for the acquisition process. A weekly action review and quarterly practice review are useful starting proposals, **not support SLAs or delivery promises**.

For each measure, record numerator, denominator, cost basis, period, source, owner and accepted threshold. Begin with allocated dollars and unresolved dollars; source freshness; reconciliation differences and aging; forecast variance with cause; recommendation disposition; and cost per meaningful outcome. Do not reward apparent allocation coverage achieved by hiding unknown ownership. Leadership and finance approve materiality and escalation thresholds.

## 3. Run the same numbered procedures at the evidenced entry point

### Procedure 1 — Establish scope, authority and the applicable overlay

**Owner:** Client sponsor, with finance and security/data authorities. **Inputs:** Foundations evidence, existing policy, roles, source inventory and current practices.

1. Bound one useful service or portfolio slice, period and decision question.
2. Name decision owners, data stewards, delegates and escalation recipients.
3. Complete the source/applicability register below. Separate practice guidance, strategy, binding requirements and contract terms.
4. Confirm where evidence may be accessed and stored before collecting it. Use fictional examples while real-data admission is unresolved.
5. Select entry points and agree the receiving team's review capacity.

**Output/exit evidence:** Scope/decision card, authority map and explicit unresolved issues. **Escalation:** Sponsor resolves ownership; finance resolves financial policy; authorized security/data officials resolve handling. Missing authority permits draft design or fictional rehearsal only.

For applicable acquisitions, DFARS 239.76 addresses cloud contracting, authorization, data and related requirements. Contracting and counsel establish applicability to the actual acquisition; a commercial product feature cannot establish permission. ([DFARS 239.76](https://www.acquisition.gov/dfars/subpart-239.76-cloud-computing))

### Procedure 2 — Connect approved intake to attribution readiness

**Owner:** Service owner; platform steward and finance validate their fields. **Inputs:** Approved demand/request, service identity, financial mapping, expected lifecycle and architecture alternatives.

1. Capture purpose, expected useful outcome, accountable owner and durable service/project identifier.
2. Record approved financial reference, environment, expected lifetime, dependencies and estimated cost range with assumptions.
3. Compare feasible architecture/consumption choices, including shared services and support. Distinguish the estimate from budget approval.
4. Specify where metadata originates, who validates it, and how each creation path preserves it.
5. At proposed handover, check a sample resource/run against the service and financial mapping; record missing fields and exception ownership.

**Output/exit evidence:** Completed intake, dictionary and attribution-readiness checklist. **Escalation:** Missing or disputed owner/map goes to its authority; never invent a cost center. Passing establishes readiness to attribute future evidence, **not invoice reconciliation**. Planning should make scope and assumptions explicit and consider alternatives. ([Planning & Estimating](https://www.finops.org/framework/capabilities/planning-estimating/))

**Optional capability flow:** approved intake → approval and metadata validation → client provisioning/change process → operational handover → lifecycle evidence → invoice reconciliation. Jira/ServiceNow are possible intake surfaces; a selected CloudBolt/Morpheus-type CMP could coordinate validation and propagation; Terraform, OpenTofu or CloudFormation could execute approved infrastructure changes. These are illustrative role mappings, not required products, verified deployments or purchase recommendations. Include autoscaling, pipelines and native creation paths in requirements. Initial intake alone cannot cover later creation.

### Procedure 3 — Preserve ownership through change and retirement

**Owner:** Platform/operations steward; service owner validates ownership. **Inputs:** Resource/run identity, parent service, creation/change/retirement events and effective-dated mappings.

1. Link each in-scope resource/run to a stable parent service and approved owner mapping.
2. Record valid-from/to times when ownership or financial mapping changes; retain original evidence references.
3. When the resource disappears, preserve the permitted lifecycle record under the client's approved retention policy.
4. Map late charges to the owner for the usage interval, not automatically today's owner.
5. At retirement, identify surviving storage, network, licenses, commitments and shared dependencies; route any action through client authority.

**Output/exit evidence:** Historical lifecycle record that allows a deleted sample job to be traced when billing arrives. **Escalation:** Missing history stays explicitly unknown/unallocated; disputed ownership goes to service owner and finance. An expiry date triggers review, not deletion. Account or landing-zone placement alone is insufficient evidence of historical ownership. Foundation allocation guidance supports combining hierarchy, metadata and shared-cost information. ([Cloud allocation guide](https://www.finops.org/wg/cloud-cost-allocation/))

### Procedure 4 — Allocate shared costs and issue explainable showback

**Owner:** Finance policy owner; service owners validate beneficiaries. **Inputs:** Named cost view, source totals, pool boundaries and driver evidence.

1. Separate direct, shared, centrally funded and unresolved amounts.
2. For each shared pool, compare central funding, fixed shares and measured-consumption drivers. Recommend the simplest defensible method that changes a useful decision.
3. Document beneficiaries, weights, evidence, period, exclusions and residual treatment; secure the appropriate policy decision.
4. Apply each charge/pool once. Confirm allocations plus central/unallocated residual equal the scoped source total for each currency.
5. Publish the explanation, rule version and dispute route alongside service totals.

**Output/exit evidence:** Allocation rule card and reproducible showback. **Escalation:** Missing or contested drivers go to finance; use an explicit temporary treatment, never an unexplained equal split. Central funding avoids false precision but weakens consumption signals; fixed shares are simple but can drift; measured allocation improves causality at an evidence/maintenance cost. The Foundation treats allocation targets, metadata and shared costs as connected strategies. ([Allocation](https://www.finops.org/framework/capabilities/allocation/))

### Procedure 5 — Reconcile invoices, correct differences and close

**Owner:** Finance/accounting. **Inputs:** Authoritative invoice/export revisions, account/issuer/period/currency, approved mappings and correction policy.

1. Inventory expected sources and distinguish provisional from final evidence.
2. Aggregate invoice and usage records independently before joining; preserve native identifiers and source revision. Avoid duplicating provider/reseller invoices or multiplying invoice headers across line items.
3. Perform two separate checks. First, reconcile the issued invoice payable total to the complete billing-export billed total at matching issuer/account/period/currency, documenting supported reconciling items such as tax or late credits. Second, reconcile the scoped source total to direct + shared + centrally funded + unallocated amounts. Record each variance separately: missing export charges and missing ownership are different defects. Investigate support, Marketplace items and missing periods in the appropriate check.
4. Explain estimates and analytical effective cost separately. Never add estimated and actual cost, or billed and effective cost, into one total.
5. Record correction semantics—replacement, delta or reversal/re-entry—and obtain finance's disposition. Keep unresolved differences provisional with an owner and next review.
6. Issue the close pack; reopen corrected periods under the client's policy.

**Output/exit evidence:** Traceable reconciliation, differences and approved-or-provisional close state. **Escalation:** Finance owns estimates, true-ups and posting; contracting/provider channels handle applicable disputes. Never use a silent balancing plug. The Foundation distinguishes showback from official chargeback and assigns accounting decisions to finance. ([Invoicing & Chargeback](https://www.finops.org/framework/capabilities/invoicing-chargeback/))

FOCUS supplies common data semantics, not invoice validity, provider conformance or contract rights. Record the actual export/specification version, supported datasets and mapping gaps. Billed Cost and Effective Cost serve distinct views. ([Billed Cost](https://focus.finops.org/docs/specification/v1-4/columns/cost-and-usage/billed-cost/), [Effective Cost](https://focus.finops.org/docs/specification/v1-4/columns/cost-and-usage/effective-cost/))

Managerial allocation, accounting posting and legal transfer/reimbursement are separate decisions. An allocation worksheet creates no authority to transfer appropriation funds; obtain the client's controlling finance/legal determination. ([31 USC 1532](https://www.govinfo.gov/content/pkg/USCODE-2023-title31/pdf/USCODE-2023-title31-subtitleII-chap15.pdf))

### Procedure 6 — Forecast demand and explain variance

**Owner:** Service owner with finance. **Inputs:** Comparable actuals, roadmap/demand changes, prices/terms, shared costs and planning horizon.

1. Freeze a dated baseline and cost basis.
2. Build low/base/high scenarios with volume, rate, mix, one-time events and uncertain assumptions separated.
3. Compare scenarios with the authorized budget reference; identify decisions rather than implying funds are available.
4. Compare later actuals with the frozen forecast, explain causes and update prospectively.
5. Record absolute variance; define percentage convention and report percentage as undefined when its denominator is zero.

**Output/exit evidence:** Reproducible forecast and variance explanation. **Escalation:** Finance/program authority resolves material funding or priority changes. Forecasting uses historical evidence and expected changes; acceptable variance belongs to the organization. ([Forecasting](https://www.finops.org/framework/capabilities/forecasting/))

### Procedure 7 — Triage anomalies without bypassing operations

**Owner:** Service/operations owner; FinOps coordinates. **Inputs:** Report/alert, timestamps, data freshness, owner mapping and planned events.

1. Validate the signal and affected interval; check for delayed or corrected data.
2. Distinguish data defect, expected launch/change and unexpected consumption.
3. Assess cost exposure alongside mission, reliability and security impact.
4. Route the issue through the existing incident/change process with a named action owner.
5. Record disposition, verification and follow-up; improve routing or detection where useful.

**Output/exit evidence:** Acknowledged owner, rationale and outcome evidence. **Escalation:** Follow accepted routes for unknown owners or increasing exposure. No automatic shutdown, resizing or deletion is implied. Use blameless investigation while retaining accountability for decisions and follow-up. Foundation guidance includes manual review, routing and false-positive handling; automation is not an entry requirement. ([Anomaly Management](https://www.finops.org/framework/capabilities/anomaly-management/))

### Procedure 8 — Recommend optimization with mission trade-offs

**Owner:** Service owner; engineering assesses feasibility and finance validates economics. **Inputs:** Cost baseline, observed utilization, dependency evidence and mission requirements.

1. Identify the decision: usage reduction, placement, scheduling, licensing, rate or another evidenced opportunity.
2. Compare the current state and alternatives, including effort, resilience, security, operational capacity and exit costs.
3. State expected benefit as a range with assumptions, approving authority and evidence that would reverse the recommendation.
4. Identify the client's change path, prerequisites and rollback considerations.
5. If the client later implements, compare like-for-like outcomes and record side effects.

**Output/exit evidence:** Accepted, deferred or rejected recommendation with rationale and next owner. **Escalation:** Service/change authority resolves risk; finance validates claimed benefit. Keep realized savings, avoided cost and forecast variance distinct. Reduced staff time is capacity released unless an evidenced financial change makes it cash savings. No implementation or saving is promised by the advisory record.

### Procedure 9 — Evaluate commitments and Marketplace transactions separately

**Owner:** Acquisition/contracting plus finance. **Inputs:** Executed agreement/version, offer/channel, demand scenarios, existing coverage and renewal/exit dates.

1. Compare no-commitment and commitment options under low/base/high demand; expose unused coverage, lock-in and reversibility.
2. Identify eligible entity/accounts, offer, deployment, term, recognition timing and cap/rate from governing evidence.
3. Keep purchase, usage attribution, invoice reconciliation and confirmed enterprise drawdown as separate records.
4. Track eligibility as confirmed eligible/excluded/unknown; track recognition as candidate/awaiting confirmation/confirmed/reversed.
5. Reconcile provider-confirmed recognition with expectations; revisit refunds, renewals and corrections.

**Output/exit evidence:** Recommendation with downside and separate eligibility/recognition evidence. **Escalation:** Unclear terms go to acquisition/provider confirmation; unknown amounts remain outside confirmed drawdown. Purchasing requires actual authority.

Our recommendation is to verify AWS drawdown against the executed agreement; this research establishes no universal Marketplace percentage. Government eligibility and commitment treatment require the receiving organization’s executed agreement and procurement authority. Azure MACC depends on eligible offers and purchase/deployment conditions. Google's eligible-spend rate differs from its cumulative cap; apply the actual governing policy/agreement. Commercial eligibility, Government availability and workload authorization are separate checks. ([Azure benefit](https://learn.microsoft.com/en-us/marketplace/azure-consumption-commitment-benefit), [Google policy](https://cloud.google.com/terms/marketplace/commit-policy))

### Procedure 10 — Measure useful outcomes, including AI work

**Owner:** Service/product owner defines acceptance; finance validates cost scope. **Inputs:** Comparable cohort/period, acceptance criteria, all attempts, allocated costs and review effort.

1. Define the useful outcome and who accepts it before comparing alternatives.
2. Link outcomes to attempts and billing evidence; include retries, failed work and approved shared-cost allocation.
3. Inventory tools, retrieval/storage, capacity, support and human review/rework; label each included, bundled, excluded with reason or unknown.
4. Separate measured bills from estimated labor and telemetry-derived estimates. Avoid duplicate costs for covered usage or bundled components.
5. Divide total in-scope cohort cost by distinct accepted outcomes; report quality, acceptance rate, review effort and uncertainty beside the result.

**Output/exit evidence:** Reproducible unit-cost record with matched numerator and denominator. **Escalation:** Missing acceptance evidence goes to the service owner; incomplete costs remain partial. Zero accepted outcomes means **undefined unit cost**, with spend still disclosed. Token counters measure consumption; they do not establish useful outcomes, and provider meter semantics need separate validation. Foundation unit economics supports organizational outcome measures beyond resource consumption. ([Unit Economics](https://www.finops.org/framework/capabilities/unit-economics/), [FinOps for AI](https://www.finops.org/framework/technology-categories/ai/))

### Procedure 11 — Review the practice and hand it to its owners

**Owner:** Sponsor and designated FinOps coordinator. **Inputs:** Procedure records, exceptions, capacity and recommendation backlog.

1. Review unresolved ownership, source and policy gaps before expanding scope.
2. Ask a second staff member to reproduce one allocation, one close difference and one recommendation from the records.
3. Confirm receiving owners, location of approved records, review dates and escalation routes.
4. Prioritize improvements by decision value and effort. Evaluate tools only against a documented capability gap.
5. Record what is adopted, pending, declined or outside scope; obtain the client's acceptance through its existing process.

**Output/exit evidence:** Handover record and bounded next-decision list. **Escalation:** Sponsor resolves staffing or ownership gaps. A successful rehearsal is evidence of comprehensibility, not release acceptance or operational effectiveness. Foundation tools guidance begins with existing capabilities and gaps. ([Automation, Tools, & Services](https://www.finops.org/framework/capabilities/automation-tools-services/))

## 4. Reuse these dictionaries and fill-in records

Use existing approved client records where they already cover the required evidence. These templates describe information, not a demand for a new worksheet, system or tag on every resource.

### Minimum metadata dictionary

For **every field**, add allowed values/type, sensitivity, authoritative system, steward, native representation, validation rule, missing-value treatment and effective date.

| Proposed field | Meaning and required condition | Validator / exception treatment |
|---|---|---|
| Service/project ID | Durable parent identity for in-scope consumption | Service owner; unresolved parent remains unknown |
| Accountable owner/team | Responsibility with valid-from/to dates | Sponsor/service owner; escalate orphaned scope |
| Financial reference | Existing approved cost-center/project/funding mapping | Finance; no invented or inferred fiscal authority |
| Request/change/run ID | Link to approved intent and ephemeral activity where relevant | Platform steward; retain evidence gap |
| Resource identity/parent | Native identity and service relationship where supplied | Platform steward; never assume all charges expose it |
| Environment/lifecycle | Approved environment category and planned/actual timestamps | Service/platform owner; retirement triggers review |
| Allocation rule/version | Direct/shared/central/unallocated treatment and effective period | Finance; disputed treatment explicitly provisional |
| Source/period/currency | Evidence origin, billing versus usage interval and currency | Finance/data steward; no mixed-currency total without approved conversion |
| Policy/exception reference | Applicable decision and permitted deviation | Relevant authority; expiry prompts reassessment |

### Copy-ready record templates

**A. Scope and recommendation**  
Scope/service: ___ · Period/currency: ___ · Included/excluded: ___ · Decision question: ___ · Owner/delegate: ___ · Consulted: ___ · Evidence/status/date: ___ · Options: ___ · Recommendation: ___ · Trade-offs/downside: ___ · Reversal condition: ___ · Approval state/date: ___ · Next review: ___

**B. Allocation rule**  
Pool/source total: ___ · Boundaries/exclusions: ___ · Cost basis: ___ · Beneficiaries: ___ · Driver/source/weights: ___ · Period: ___ · Central/residual treatment: ___ · Version/effective date: ___ · Approver: ___ · Dispute/correction route: ___ · Allocations + residual = source total: ___

**C. Lifecycle attribution**  
Request/run: ___ · Stable service: ___ · Resource/parent: ___ · Creation/change/retirement: ___ · Owner valid-from/to: ___ · Financial mapping version: ___ · Usage interval: ___ · Evidence location: ___ · Billing arrival: ___ · Confidence/gap: ___

**D. Close and correction**  
Issuer/account/invoice: ___ · Period/currency: ___ · Source revision/status: ___ · Invoice payable total: ___ · Complete export billed total: ___ · Supported reconciling items: ___ · Invoice-to-export variance/cause: ___ · Scoped source total: ___ · Direct/shared/central/unallocated totals: ___ · Source-to-allocation variance/cause: ___ · Adjustment/supersession: ___ · Preparer/reviewer: ___ · Unresolved items/owner/date: ___ · Final/provisional state: ___

**E. Forecast and anomaly**  
Frozen forecast version/date: ___ · Scope/period/cost basis: ___ · Baseline: ___ · Demand/rate/mix assumptions: ___ · Low/base/high: ___ · Actual/absolute variance: ___ · Percentage convention: ___ · Explanation: ___ · Observation/detection/source times: ___ · Freshness/planned event check: ___ · Impact: ___ · Owner/disposition: ___ · Authorized action reference: ___ · Verification/follow-up: ___

**F. Commitment decision**  
Agreement/version/buyer: ___ · Offer/channel/deployment: ___ · Period/currency: ___ · No-commitment alternative: ___ · Coverage and downside: ___ · Verified rate/cap: ___ · Eligibility evidence/state: ___ · Recognition evidence/state: ___ · Renewal/exit: ___ · Authority/decision: ___

**G. Unit and AI economics**  
Use case/cohort: ___ · Accepted-outcome definition/reviewer: ___ · Attempts/retries: ___ · Provider/other execution costs: ___ · Shared allocation: ___ · Review effort/rate basis: ___ · Measured versus estimated: ___ · Accepted count: ___ · Unit cost: ___ · Quality/uncertainty: ___

**H. Source, applicability and exceptions**  
Source/title/issuer/version: ___ · Requirement or recommendation: ___ · Component/program/contract: ___ · Section/clause: ___ · Applicable procedure: ___ · Evidence/status: ___ · Decision owner: ___ · Exception authority: ___ · Temporary treatment: ___ · Currency/review date: ___ · Resolution/superseded record: ___

### Fictional tabletop: make uncertainty visible

All numbers below are invented teaching inputs, not prices, client data or expected savings. Reuse the existing synthetic cost rehearsal for detailed ledger practice.

| Situation | Required treatment |
|---|---|
| Shared pool is $1,000; approved weights assign $600 and $300, leaving $100 unresolved | Preserve $100 residual; allocated plus residual equals $1,000. Do not hide it in another service. |
| Ephemeral job is deleted before its $40 charge arrives | Use its effective-dated lifecycle mapping; without history, show $40 as unresolved. |
| $500 estimate becomes a $540 bill, followed by a $20 credit | Keep estimate comparison separate; recognize the correction under finance's policy. Final net is $520 if the credit belongs to this scope/period. |
| Launch causes an expected spike | Confirm planned-event evidence and owner; close the anomaly with rationale rather than initiate shutdown. |
| Ten AI tasks produce twelve attempts and eight accepted outcomes; complete scoped cost is $24 | Cost per accepted outcome is $3, including failed/retried work. Show the acceptance count and cost boundary. |
| Marketplace purchase appears on the invoice but drawdown evidence is absent | Reconcile the invoice while recognition remains awaiting confirmation. |

### Bounded adoption and handover checklist

- [ ] Foundations variables have sources, dates, validators and unresolved states.
- [ ] Each applicable procedure has an owner and an evidence-supported entry point.
- [ ] Financial, data, operational and acquisition authority remain separately identified.
- [ ] One permitted case and one exception have been rehearsed; another staff member can reproduce them.
- [ ] Allocation conserves totals; late billing and corrections retain history; cost views are distinct.
- [ ] Recommendations state trade-offs, authority and reversal conditions.
- [ ] Client receiving owners have the records, review dates and escalation route.
- [ ] Adoption, client acceptance and any later implementation are explicitly recorded as completed or pending.

## 5. Maintain the book without turning assumptions into policy

Research cutoff is **6 October 2026**. This book synthesizes the accompanying foundation, federal and process research plus the earlier FinOps/AI economics and Marketplace reports. The current federal research resolves the earlier DoD strategy retrieval gap through its official alternate host. It does not establish every component's current implementing policy, a universal DoD tag schema, an Air Force-wide adoption order, a client's contract rights or permitted data boundary. Full current DoD financial-management chapter retrieval was unavailable; finance must supply controlling policy rather than inherit guessed appropriation treatment.

Before applying a policy-sensitive recommendation, update its applicability register against the actual component, acquisition, agreement and authorized environment. Keep publication, demonstrated implementation and client entitlement/authorization as separate evidence. Review this reusable core when Foundation terminology changes or a recurring defect warrants correction; change client variables when ownership, policy, contracts, evidence or demand changes. That preserves one method while allowing different starting points and defensible recommendations for each client.