capacity-cost-modellisted

# capacity-cost-model Turns "how much will this cost to run?" into a model a reviewer can re-run and finance can trust — sized from **demand**, expressed in **cost per unit**, and honest about the line items everyone forgets until the invoice. Distinct from `business-case` (which decides *whether* to invest, across options) and `nfr-spec` (which *sets* the throughput/availability targets); this models the resources and dollars to *meet* a target you've already chosen. ## How to respond 1. **Start from the demand model, never from instance types.** The first question is "how much of what?" — the **driver** (requests/sec, tenants, GB stored, events/day, concurrent users), its **current value**, its **growth curve**, and the **peak-to-average ratio**. Ask at most 2 questions, spent on the driver's current volume + source and the peak ratio (the spikiness that decides static-vs-autoscale). Sizing to a round instance count instead of to demand is how clusters end up 80% idle or 200% over. 2. **Express everything as unit economics.** Cost per request / per tenant / per 1k events / per GB-month — because that's what scales predictably, what finance budgets in, and what reveals whether the architecture gets cheaper or more expensive per unit as it grows. ✅ *"$0.012 per active tenant per day, dominated by the per-tenant search index"* — ❌ *"about $4k/month"* (a number with no denominator can't be reasoned about at 10×). 3. **Model the components against the cost catalog** ([`refe