Cost Ledger and Cost Allocation

1) The real problem: a monthly total is not a ledger

A statement such as “the platform cost 1,650 units this month” is not enough for a reproducible decision. If the source line, period, direct/shared classification, owner, allocation target, driver, and unresolved residue are hidden, the final number may look precise while depending on arbitrary apportionment. This lesson turns a cost total into Cost Ledger & Allocation Contract v1, where every allocated amount can be traced back to its source evidence and rule.

2) Boundary and deliverable

The deliverable is an auditable cost ledger, not a pricing floor, invoice, or statutory accounting policy. ARC-017 owns markup, margin, and pricing floors. Here the questions are narrower: Where did the cost come from? Which period does it belong to? Is it direct or shared? Which governed rule allocated it? What residue remains unresolved?

3) Fact: allocation is more than dividing a total

The FinOps Allocation capability describes assigning and sharing technology cost and usage through accounts, tags, labels, and other metadata so responsible groups can understand their costs. It also distinguishes direct allocation from shared-cost strategies. That fact does not authorize arbitrary splitting; it shows that allocation must remain connected to responsibility and metadata.

4) Fact: shared cost can use different strategies

Shared cost can be distributed through fixed, proportional, or proxy-metric approaches. A method name does not prove that the method is fair for a particular pool. The driver must be governed for the same pool, effective period, and policy version. Replacing a usage driver with an equal split without approval is a policy mutation, not a harmless arithmetic shortcut.

5) Lock ledger grain before allocation

The minimum grain in this lesson is a source line within a cost period. Every entry keeps an ID, period, source reference, category, effective cost, currency, and evidence reference. Direct/shared classification, owner, target, driver, and adjustment evidence are added on top. Without a stable grain, reconciliation has no unambiguous source population to reconcile against.

6) Allocate direct cost only with real ownership

A direct cost is allocable when the responsible owner and target are visible. A dedicated inference charge explicitly tied to Product-A can be posted directly to that target. If the same cost line has no owner, the learner must not guess. In this lesson, missing ownership on a direct line produces HOLD.

7) A shared pool needs a same-version driver

For shared cost, pool value and driver quantities must belong to the same context. The proportional rule is allocated_target = shared_effective_cost × target_driver_quantity / total_driver_quantity. If the pool changes from 300 to 600 while the driver evidence remains tied to an obsolete pool/version, the result is numerically neat but not defensible; the state remains DISPUTED.

8) Unallocated residue is not a failure; hiding it is

Some cost is genuinely unresolved at the time of reconciliation: an untagged resource, an adjustment without ownership, or an incomplete source line. That amount stays in unallocated_amount. The goal is an honest ledger, not artificial 100% allocation. A visible residue can produce PARTIAL while preserving the allocations that are supported by evidence.

9) Baseline: 1,650 units of source cost

The baseline fixture has 600 units of dedicated inference cost for Product-A, 300 units of direct storage for Product-B, and 150 units of security cost assigned to Central. A 300-unit monitoring pool is allocated by request volume at 70/30, and a 200-unit support pool is allocated at 60/40. One 100-unit resource is still unowned. Source total is 1,650, allocated total is 1,550, and unallocated residue is 100. The correct state is PARTIAL, not “almost reconciled.”

10) Reject an unapproved equal split

Suppose monitoring was governed by request volume. Replacing that driver with an equal split merely because it is easy produces DISPUTED when no new approval or policy version exists. The problem is not the math. A 50/50 split can reconcile the total while misrepresenting accountability.

11) A late adjustment expires the previous reconciliation

If an 80-unit monitoring adjustment arrives after the period was reconciled, the prior snapshot cannot remain the oracle. The new source total becomes 1,730 and affected allocations must be recomputed. Until the new source population, allocations, and residue reconcile, the state is HOLD. A historic “reconciled” label cannot override new evidence.

12) Core evidence contract

The table is an evidence contract, not decoration. Source, period, direct/shared classification, owner, target, driver, driver quantity, effective cost, allocated amount, unallocated amount, adjustment, reconciliation, dispute, and evidence lineage must agree. Every period must satisfy source_total = allocated_total + unallocated_total.

13) What the typed states mean

RECONCILED means the visible source population is completely accounted for with valid allocation evidence and zero delta. PARTIAL means defensible allocations coexist with explicit unresolved residue. DISPUTED means the driver, pool scope, or policy version is contested or stale, so the allocation must not be consumed as final. HOLD means decisive evidence such as ownership or driver quantity is missing, or fresh source evidence has invalidated the prior reconciliation.

14) Transfer: changed context requires recomputation

Customer A doubles request volume while storage usage does not change; the monitoring contract changes from fixed fee to usage-based pricing; and the previously untagged 100-unit resource is traced to Product-B. Monitoring must be recomputed with the new usage quantities, direct storage must not move merely because requests grew, and the formerly unresolved line can now be direct. In the transfer fixture, source total becomes 1,690 and all visible evidence reconciles, so the state is RECONCILED.

15) Lab, assessment, and source freshness

The lab is fully offline and synthetic. It needs no credentials, provider account, or customer billing data. Eight fixtures cover the baseline, fully traced residue, unapproved equal split, late adjustment, missing direct owner, missing shared-driver quantity, stale driver after pool change, and the transfer scenario. The FinOps Framework Allocation source was rechecked on 2026-09-15. External facts stay separate from MAKNOW design choices: FinOps describes allocation patterns; this lesson owns its ledger fields, typed states, and acceptance rules.