Compute Demand Ledger

Two things can be true about the same month: the machine was pinned for a twenty-hour round, and the project has barely used any compute all year. From inside the week that round happened in, they feel like one fact. Only the second one has anything to say about whether you should buy hardware.

Keeping them apart is this ledger's whole job. It is the append-only record of the compute you actually used and paid for — device-hours and spend, owned and rented, month over month, including honest NOT-RUN rows — which is what this playbook calls a demand ledger. It separates within-run busyness from sustained fleet demand, and it must predate the wanting of any hardware it might eventually be used to justify buying.

When to use / when not to use#

• MUST start this ledger before wanting the hardware — a purchase trigger defined after the wanting starts is a rationalization, not a control.
• MUST log every month a project consumes owned or rented device-hours beyond ad hoc single-session exploration — training runs, evaluation runs, serving-capacity tests, anything that could eventually be cited to justify capital spend.
• MUST log NOT-RUN months honestly: a month with zero owned/rented usage still gets a row, so idle capacity stays visible rather than silently absent.
• SHOULD keep one ledger per fleet/lab, not per project — the decision this feeds (buy or don't) is about shared capacity, and one ledger per project only ever shows a fraction of it.
• Do not treat this as a substitute for a performance autopsy — this ledger is the cross-run monthly rollup; a single run's critical path and cost-bucket attribution belong in PERFORMANCE_AUTOPSY.md.
• Mark the whole template N/A only if literally no owned or rented device-hours are ever consumed (managed-API-only projects) — state that explicitly rather than omitting the file, because nobody can tell a missing ledger from an unconsidered one.

Rigor-tier applicability#

Rigor attaches to the purchase decision's consequence, not the project's declared tier: capital spend is a consequential decision wherever it originates, and the ledger requirement follows the decision, not the originating project's stated tier. See chapter 00 §6 (rigor dial) and PROJECT_PROFILE.md.

---

The Ledger#

Fill every section below. Placeholders in [brackets] carry inline guidance in italics — replace the placeholder, keep or delete the guidance. No section may be silently omitted; see "Delete no section" at the end of this document.

1. Ledger Table#

One row per milestone, written as the work happens. A ledger reconstructed from invoices six months later is a story about the past; this one is evidence.

Filling a row:

• Node — name the device class, generically enough to survive a hardware refresh: owned, single-GPU workstation, rented, multi-GPU node. Precise SKUs belong in a private inventory, not in this ledger's portable structure — the rows have to still mean something after the hardware underneath them changes.
• Device-hours — the hours, plus which clock they came from. Wall-clock reservation time and device-busy time diverge, sometimes by a lot, and the purchase decision needs to know which one it is reading. So name the authoritative clock in the cell: write 6.0 (device-busy), not 6.0. See dual-clock telemetry.
• Spend — what it actually cost, $0 for owned or idle capacity. Never blank; a blank cell reads as unknown rather than as zero.
• A NOT-RUN row still needs a date and a node. "Which capacity sat idle, when" is exactly what a busy-sprint illusion hides, and a month with no row at all cannot tell a reviewer whether nothing ran or nobody logged it.

2. Monthly Rollup#

The trigger in §3 reads this table, not the raw rows.

Once a month, sum §1 into one line: owned hours, rented hours, rented spend. Then update the running count — how many consecutive months so far have met §3's condition. Because the condition is consecutive, a month below the threshold resets that count to zero. That count is the reason this section exists: a trigger phrased as "K consecutive months" cannot be read off a pile of dated rows.

3. Purchase Trigger#

1. Trigger not met → continue renting or using owned capacity as-is; no purchase discussion is licensed by this ledger alone.
2. Trigger met → open a benchmark-first sizing pass: run the actual (or representative) workload across candidate configurations and select the minimal configuration that clears the stated latency/throughput/cost target — not the largest affordable one [SCENARIO: SCENARIO-05].

---

Delete No Section#

Every numbered section above MUST appear in a filled ledger. If a project genuinely has zero owned/rented device-hours (managed-API-only), write the section header with the body N/A — API-only, no device-hours to ledger under §1, and N/A — no purchase decision in scope under §2–§3, rather than omitting them. Absence is a decision, and a reviewer needs to see that it was considered, not skipped.

---

Miniature Filled Example#

Illustrative example — synthetic. Invented project: the invoice-triage assistant from EXPERIMENT_CONTRACT.md's worked example, Tier 2, periodic adapter fine-tuning plus eval runs.

§1 Ledger table:

§2 Monthly rollup:

§3 Purchase trigger evaluation: trigger = 3 consecutive months ≥ $300/mo rented spend OR ≥ 200 sustained device-hours/month. Neither condition is met through 2026-03 (max monthly spend $47; max monthly hours 16.5) — trigger not fired; no purchase discussion licensed.

---

Governing chapters: 11. Economics, Hardware and Cloud · 06. Inference Performance and Capacity

Related templates: EXPERIMENT_CONTRACT.md · PERFORMANCE_AUTOPSY.md · PROJECT_PROFILE.md

Index · Glossary