{
  "schema_version": 1,
  "skill_name": "capacity-and-cost-engineering",
  "evals": [
    {
      "id": "growth-forecast",
      "prompt": "Our API serves 200 requests/second with 8 instances running at 55% average CPU. We're growing 10% month-over-month and need a 12-month capacity projection. Our SLO is 99.9% availability with P99 latency < 100ms. Current monthly infrastructure cost is $8,000. We don't have load-test data for the current configuration. Produce a capacity model that connects demand, performance, reliability, and spend.",
      "expected_output": "A capacity model with a 12-month projection. The model connects demand (200 req/s, 10% MoM growth) to capacity (instances, CPU) through a utilization target stated with rationale — not a universal percentage. It projects the scaling timeline: in which month do current instances saturate, and what is the trigger for scaling? It connects to performance (the P99 latency < 100ms SLO constrains how high utilization can go before latency degrades) and reliability (the 99.9% availability SLO requires headroom for failover — capacity must cover N+1 or equivalent). It connects to spend: projected monthly cost at each scaling step. The model MUST identify that without load-test data, the capacity/demand ratio (how many req/s an instance can serve at the P99 target) is an ASSUMPTION, not evidence. It labels this assumption explicitly and states that a load test is required to validate the model. The model includes a scaling trigger (e.g., sustained CPU > X% for Y minutes), an owner, and at least one explicit tradeoff (e.g., earlier scaling = higher cost but lower risk of SLO breach).",
      "assertions": [
        "The model includes a 12-month projection with specific months when scaling is needed",
        "The model states a utilization target with rationale specific to this service, not a universal percentage",
        "The model connects the utilization target to the P99 latency SLO — performance constrains utilization",
        "The model connects the availability SLO to capacity — reliability requires headroom for redundancy or failover",
        "The model projects cost at each scaling step, connecting capacity to spend",
        "The model identifies that the capacity/demand ratio is an assumption without load-test data and labels it as such",
        "The model states that a load test is required to validate — modeling without load evidence is incomplete",
        "The model includes at least one owner and at least one tradeoff"
      ]
    },
    {
      "id": "peak-event",
      "prompt": "Our e-commerce platform handles 5,000 requests/second at baseline. For Black Friday, we expect 35,000 requests/second peak sustained for 8 hours. We currently run 50 instances. Our SLO is 99.9% availability, P99 latency < 200ms. Monthly cost at baseline is $45,000. The peak is in 6 weeks. We have no load test at 35,000 req/s. Produce a peak capacity plan with cost projection.",
      "expected_output": "A peak capacity plan that sizes for the peak event, not the baseline. The plan models peak demand (35,000 req/s for 8 hours) as a separate scenario from baseline (5,000 req/s) and does not average them. It defines peak shape (ramp, duration, cooldown), not just the peak number. It calculates capacity required at peak with headroom — and states the headroom rationale. It projects the cost of peak capacity and compares it to baseline cost. The plan REQUIRES a load test at the projected peak throughput before the event — it does not accept a capacity model without load evidence as sufficient. It defines the post-peak scale-down plan with a trigger: when does capacity return to baseline, and what is the cost of capacity that lingers after the peak? If peak capacity cost exceeds a reasonable budget multiplier, it offers a degraded-peak alternative (what functions shed, what user impact). Assumptions are listed, ownership is named, and at least one tradeoff is explicit.",
      "assertions": [
        "The plan models peak demand separately from baseline — it does not average them or use baseline as proxy",
        "The plan defines peak shape (ramp, duration, cooldown), not only the peak throughput number",
        "The plan REQUIRES a load test at projected peak throughput before the event — modeling without load evidence is explicitly insufficient",
        "The plan defines a post-peak scale-down plan with a trigger — capacity that persists after the peak is addressed",
        "The plan projects peak capacity cost and compares it to baseline, connecting capacity to spend",
        "If peak cost is material, the plan offers a degraded-peak alternative with user impact stated",
        "Assumptions are listed, ownership is named, and at least one tradeoff is explicit"
      ]
    },
    {
      "id": "slo-cost-conflict",
      "prompt": "Our payment-processing service has an SLO of 99.99% availability (4.3 minutes downtime/month). To meet this, we run active-active across 3 regions at a cost of $180,000/month. Our finance team has imposed a $120,000/month budget cap for this service starting next quarter. At current demand (2,000 transactions/second), a 2-region active-passive deployment would cost $110,000/month and support 99.9% availability (43 minutes downtime/month). A single-region deployment would cost $60,000/month at 99.5% availability. The SLO owner argues that payment processing cannot go below 99.99% — every minute of downtime loses revenue. The finance owner says the budget cap is non-negotiable. Produce an SLO-cost tradeoff record that surfaces the conflict with evidence and ownership.",
      "expected_output": "An SLO-cost tradeoff record that surfaces the conflict explicitly — it does not pick a side silently or accept a degradation without evidence. The record states the current SLO (99.99%), the cost to meet it ($180K/month), and the budget cap ($120K/month), with a gap of $60K/month. It compares at least two alternatives: 2-region active-passive at 99.9% ($110K/month, within budget) and single-region at 99.5% ($60K/month). Each alternative includes: the SLO, the capacity configuration, the cost, the error budget difference, and the user impact. The record names the SLO owner and the finance owner as stakeholders. It identifies that this is a conflict requiring an accountable decision-maker above both owners — it does not resolve the conflict by defaulting to the budget or to the SLO. The record includes load-test or production evidence for the capacity/SLO relationship (or explicitly states if that evidence is missing). The guardrail 'cost optimization must not degrade reliability, privacy, or user outcomes' is invoked — the record states that if payment processing cannot degrade below 99.99% without unacceptable user or business harm, the tradeoff is escalated, not accepted. The decision field requires a named accountable owner, not 'the team' or 'TBD.' Assumptions and tradeoffs are explicit.",
      "assertions": [
        "The record states the current SLO, cost to meet it, and budget cap with the explicit $60K/month gap",
        "The record compares at least two alternatives (2-region and single-region) with SLO, capacity, cost, error budget, and user impact for each",
        "The record names both the SLO owner and the finance owner as stakeholders in the conflict",
        "The record identifies that an accountable decision-maker above both owners is needed — it does not resolve by defaulting to the budget or the SLO",
        "The record invokes the guardrail that cost optimization must not degrade reliability, privacy, or user outcomes, and states escalation if payment processing cannot degrade",
        "The decision field requires a named accountable owner, not 'the team' or 'TBD'",
        "Load-test or production evidence for the capacity/SLO relationship is included or explicitly identified as missing",
        "Assumptions and tradeoffs are explicit"
      ]
    },
    {
      "id": "quota-decision",
      "prompt": "Our API gateway serves 10 external customers, each with a contracted rate limit. We currently enforce a global rate limit of 10,000 requests/second, but one customer has started running bursty workloads that consume 60% of the global limit for short periods, starving other customers. Our monthly infrastructure budget is $25,000 and we're at $23,000. We need a quota and rate-limit enforcement decision. The API has an SLO of 99.9% availability, P99 latency < 150ms. We have production metrics showing that the bursty customer's traffic correlates with P99 latency spikes to 300ms for other customers.",
      "expected_output": "A budget/quota decision that addresses the shared-resource contention problem with per-customer rate limits, not only a global limit. The decision defines per-customer quotas based on contracted entitlements, with a global limit as a backstop. It specifies the enforcement mechanism (e.g., API gateway rate limiter, token bucket) and the response when a customer exceeds their quota (HTTP 429 with Retry-After). It connects to performance: the bursty customer's traffic causes P99 latency spikes for other customers — per-customer quotas are justified by the SLO (P99 < 150ms), not only fairness. It connects to cost: the budget is at $23K/$25K, and per-customer quotas prevent one customer from driving infrastructure scale-up that would breach the budget. It defines budget thresholds (alert at 90%, soft cap at 95%, hard cap at 100%) with operational consequences at each level. It includes cost attribution: how is each customer's usage attributed to infrastructure cost? The decision names an owner for the quota configuration and a budget owner, and the enforcement mechanism is specified in operational terms (not 'set up rate limiting' without details). Assumptions and tradeoffs are explicit.",
      "assertions": [
        "The decision defines per-customer quotas, not only a global rate limit — it addresses the shared-resource contention",
        "The enforcement mechanism is specified in operational terms: what happens when a customer exceeds quota (HTTP 429, Retry-After, etc.)",
        "The decision connects the quota to the SLO — the bursty customer's impact on P99 latency for other customers justifies enforcement",
        "The decision connects to budget — per-customer quotas prevent a single customer from driving a budget breach",
        "Budget thresholds (alert, soft cap, hard cap) are defined with operational consequences at each level",
        "Cost attribution method is specified — how each customer's usage maps to infrastructure cost",
        "An owner is named for the quota configuration and a budget owner is named",
        "Assumptions and tradeoffs are explicit"
      ]
    },
    {
      "id": "misleading-unit-cost",
      "prompt": "Our team calculated unit cost for our video-transcoding service as: total monthly infrastructure cost ($30,000) divided by total API requests (15,000,000) = $0.002 per request. Based on this, they claim we can serve 2x the requests for $60,000/month. But I notice: (1) the $30,000 includes a $12,000 reserved-instance commitment that is already paid annually and is a fixed cost, not variable; (2) the transcoding service uses GPU instances that are already at 90% utilization — doubling requests would require additional GPU instances, not just more of the current ones; (3) the service runs in one region, and doubling capacity would require a second region for availability, adding data-transfer costs; (4) the calculation divides by total API requests, but 80% of those are lightweight metadata requests (GET /status, GET /job) that use negligible resources — the transcoding work is done by the other 20% of requests, which consume GPU time. I need a corrected unit-cost calculation and a capacity-and-cost projection for 2x demand.",
      "expected_output": "A corrected unit-cost calculation that identifies and fixes the misleading elements. The response identifies at least three errors: (1) the $12K reserved-instance commitment is a fixed cost — including it in a per-request unit cost that is used to project variable cost at 2x demand overestimates the marginal cost of new requests (the fixed cost doesn't double with demand); (2) GPU utilization is already at 90% — doubling requests requires additional GPU instances, not just multiplying the current cost, and the new instances incur different costs (on-demand or new reservations); (3) dividing by total API requests when 80% are lightweight metadata requests produces a misleading average — the correct unit cost should be based on transcoding requests (the 20% that consume GPU) or should compute separate unit costs for lightweight and heavyweight request types. The response recomputes the unit cost: separates fixed ($12K) from variable ($18K) costs, calculates GPU cost per transcoding request, and projects the cost at 2x demand distinguishing between the portion that uses existing fixed capacity and the portion that requires new GPU instances. The recomputed projection is higher than $60,000 and states why. The response explicitly states that cost optimization must not justify degrading reliability, privacy, or user outcomes — if the corrected projection exceeds budget, the tradeoff is escalated, not silently accepted by dropping the SLO or cutting corners. The corrected calculation includes an owner and states what evidence is needed to validate it. Claims are scoped to the harness, model, fixtures, and revision under test.",
      "assertions": [
        "The response identifies that the reserved-instance commitment is a fixed cost and explains why including it in a per-request projection is misleading",
        "The response identifies that GPU utilization at 90% means doubling requests requires new instances — the existing capacity cannot absorb the growth",
        "The response identifies that averaging across lightweight and heavyweight requests produces a misleading unit cost — it separates or recomputes based on the resource-consuming request type",
        "The corrected calculation separates fixed and variable costs and projects 2x demand with a distinction between costs covered by existing capacity and costs requiring new capacity",
        "The recomputed projection is higher than the naive $60,000 and states why with arithmetic",
        "The response explicitly states that cost optimization must not justify degrading reliability, privacy, or user outcomes, and that if budget is exceeded the tradeoff is escalated",
        "The corrected calculation includes an owner and states what evidence is needed to validate it"
      ]
    },
    {
      "id": "tenant-demand-distribution",
      "prompt": "A shared document-processing SaaS serves 4,000 tenants. The average tenant submits 2 jobs per minute, but 2% of tenants generate 45% of jobs and a few tenants concentrate work on one partition. We need a six-month capacity model and guidance on what evidence is required before promising a new enterprise tier.",
      "expected_output": "A tenant-aware capacity model that preserves the demand distribution instead of using the fleet average. It identifies hot tenants and partition skew separately, describes tenant profiles and burst shape, maps the profiles to the saturating resource, and compares ordinary and hot-tenant scenarios. It states that the enterprise promise must be translated into measurable capacity behavior, with a contextual quota/admission and fairness policy. It requires representative concurrent per-tenant load and soak evidence, including hot and skewed profiles, and labels unmeasured assumptions and owners. It routes tenant semantics and tier architecture to multi-tenant-saas-architecture, isolation controls to secure-software-engineering, SLO ownership to site-reliability-engineering, and implementation to platform-engineering.",
      "assertions": [
        "The output models tenant demand as a distribution and does not rely on the average tenant",
        "Hot-tenant behavior and partition skew are analyzed as distinct capacity risks",
        "The enterprise promise is translated into measurable capacity behavior with contextual quota or admission decisions",
        "Representative concurrent per-tenant load and soak evidence is required before the capacity promise is accepted",
        "Missing data is labeled as an assumption or evidence gap with an owner",
        "Neighboring SaaS, security, SRE, and platform ownership boundaries are explicit"
      ]
    },
    {
      "id": "pooled-versus-siloed-headroom",
      "prompt": "We are deciding whether to keep a large tenant in a pooled worker fleet, give it a dedicated silo, or use a hybrid placement. The pooled fleet has lower idle cost but shows queue spikes when the tenant bursts. The silo adds fixed capacity and another failure-domain obligation. Produce an evidence-based comparison without prescribing a universal utilization or headroom percentage.",
      "expected_output": "A comparison of pooled, siloed, and hybrid choices across ordinary load, burst, tenant growth or movement, and failure-domain loss. It separates baseline, variable demand, shared contention, idle capacity, redundancy, and operational overhead. It explains what headroom protects, the provisioning lead time, observed saturation behavior, and the cost of unused capacity rather than using a universal percentage. It defines the load and soak scenarios needed to compare user outcomes, queueing, recovery, and cost, with a named decision owner and unresolved assumptions.",
      "assertions": [
        "Pooled, siloed, and hybrid options are compared across burst and failure-domain scenarios",
        "Baseline, variable demand, idle capacity, redundancy, and operational overhead are separated",
        "Headroom is justified by workload, saturation evidence, and provisioning lead time rather than a universal percentage",
        "The evidence plan includes representative tenant load and soak behavior and cost inputs",
        "The decision has an owner and explicit assumptions or gaps"
      ]
    },
    {
      "id": "tenant-admission-fairness",
      "prompt": "One premium tenant is allowed large bursts on a shared search service. During those bursts, standard tenants see elevated P99 latency and queue depth. Define quotas, admission control, and fairness evidence while preserving the premium contract and avoiding a universal fairness ratio.",
      "expected_output": "A contextual policy that identifies the search resource and affected tenants, translates each tier promise into steady and burst behavior, and chooses an explicit admission response such as weighted scheduling, reserved capacity, bounded queues, or throttling. It states what happens to the constrained tenant and protected tenants, how retry amplification is prevented, and how recovery is verified. It does not claim a universal fairness ratio or threshold; each limit is justified by the contract, workload, SLO impact, and observed evidence. It requires a tenant-distributed load/soak test and routes security controls and infrastructure configuration to their owners.",
      "assertions": [
        "The policy identifies the shared resource, affected tenants, and tier-specific steady and burst promises",
        "Quota and admission behavior is operationally specific and includes the response for both constrained and protected tenants",
        "Retry amplification, queue bounds, and recovery verification are addressed",
        "Fairness is contextual and no universal fairness ratio or threshold is prescribed",
        "Tenant-distributed load and soak evidence is required",
        "Security-control and infrastructure-implementation boundaries are preserved"
      ]
    },
    {
      "id": "tenant-variable-unit-cost",
      "prompt": "Our multi-tenant analytics service costs $90,000 per month. $35,000 is the minimum shared platform baseline, $25,000 is storage and transfer that can be measured by tenant, and $30,000 is pooled compute. Enterprise tenants run expensive scheduled queries while self-serve tenants mostly run small interactive queries. Design a tenant-variable unit-cost model that does not pretend every tenant consumes an equal share.",
      "expected_output": "A unit-cost model that separates platform baseline and measured tenant-variable storage/transfer from pooled compute; defines a transparent allocation method for the pooled compute; segments interactive and scheduled query demand; and reports tenant or profile-level direct, allocated, and marginal cost with aligned periods and denominators. It explains how idle capacity, shared control-plane work, redundancy, and fixed commitments are treated. It routes pricing and margin decisions to financial-modeling and implementation of cost tags or resource policy to platform-engineering. It names evidence needed to validate attribution, including representative tenant load/soak data, and does not infer commercial profitability from technical cost alone.",
      "assertions": [
        "The response separates the $35,000 baseline from tenant-variable storage and transfer costs, with an explicit allocation method for the $30,000 pooled-compute pool",
        "Pooled compute allocation is explicit and does not assume equal tenant consumption",
        "Interactive and scheduled query units are segmented rather than averaged together",
        "Periods and demand denominators align and direct, allocated, and marginal views are distinguished",
        "Fixed, idle, shared, and redundancy costs are treated explicitly",
        "Financial outcomes and infrastructure implementation are routed to their specialist owners",
        "Evidence needed to validate tenant attribution is named"
      ]
    },
    {
      "id": "tenant-boundary-routing",
      "prompt": "A product team asks for an end-to-end multi-tenant SaaS architecture, including tenant identity, control-plane boundaries, data partitioning, entitlements, billing, isolation, capacity, and cost. Explain which parts capacity-and-cost-engineering should own and which should be handed to neighboring skills.",
      "expected_output": "A routing response that keeps capacity-and-cost-engineering focused on measured tenant demand distributions, hot tenants, partition skew, pooled or siloed headroom, tier-linked quotas and admission, fairness evidence, shared-cost allocation, tenant-variable unit cost, and representative load/soak evidence. It routes tenant semantics, control/application planes, partitioning architecture, lifecycle, entitlements, and billing handoffs to multi-tenant-saas-architecture; threat controls to secure-software-engineering; pricing and financial outcomes to financial-modeling; infrastructure implementation to platform-engineering; SLOs and live operations to site-reliability-engineering; demand instrumentation to product-analytics-and-measurement; and general architecture decisions to software-architecture. It does not duplicate those methods.",
      "assertions": [
        "Capacity-and-cost ownership is limited to tenant capacity and cost evidence rather than end-to-end SaaS architecture",
        "The response routes tenant semantics, planes, lifecycle, entitlements, and billing to multi-tenant-saas-architecture",
        "Security, financial, platform, SRE, analytics, and general architecture boundaries are all named",
        "Representative per-tenant load and soak evidence remains owned by capacity-and-cost-engineering",
        "The response avoids duplicating neighboring methodologies"
      ]
    }
  ]
}

# Discovery Brief: Capacity and Cost Engineering

## Survey scope

This brief surveys adjacent skills in the agent-skills catalog to define the ownership boundaries of `capacity-and-cost-engineering`. The goal is to own technical capacity models, unit economics connected to infrastructure decisions, budget and quota controls, load/soak evidence standards, and cost-performance tradeoff records — without duplicating financial P&L modeling, infrastructure implementation, SRE operations, product analytics measurement, production-readiness assembly, or product roadmapping.

## Skills surveyed

### financial-modeling

**What financial-modeling owns:** P&L statements, balance sheets, cash-flow models, fundraising scenarios, cap tables, SaaS operating metrics (ARR/MRR, churn, NDR, Rule of 40, Magic Number, burn multiple), pricing strategy, and segment-level unit economics (CAC, LTV, contribution margin, CAC payback). It is the authoritative owner of financial models, SaaS metrics, and fundraising mathematics.

**Boundary:** Financial-modeling owns the *financial* view of cost and unit economics — what a customer segment costs to acquire and serve, how revenue and expenses compose a P&L, and whether the business model is viable. Capacity-and-cost-engineering owns the *technical* view — what a request costs in compute and network, how capacity scales with demand, what a service costs to operate at a given SLO, and whether a budget constraint permits a specific infrastructure decision. Financial-modeling's unit economics answer "is this segment profitable?"; capacity-and-cost-engineering's unit economics answer "what does it cost to serve one more request and how do we optimize that without breaking SLOs?"

**Routing decision:** Capacity-and-cost-engineering routes P&L construction, fundraising scenarios, SaaS-metric definitions, and pricing-strategy work to [financial-modeling](../financial-modeling/SKILL.md). Financial-modeling is the authoritative source for financial statements, SaaS metrics, and fundraising. Capacity-and-cost-engineering owns technical unit cost (cost per request, cost per GB stored, cost per provisioned capacity unit), capacity-driven cost projections, and cost-performance tradeoff records — the work that connects infrastructure spend to reliability and demand decisions.

### platform-engineering

**What platform-engineering owns:** Infrastructure as code, CI/CD pipelines, container orchestration, service networking, secret management, observability strategy, cloud architecture, and cost governance at the platform layer. It builds and operates the delivery platform.

**Boundary:** Platform-engineering owns the *implementation* of infrastructure that satisfies capacity and cost requirements — provisioning compute, configuring autoscaling, setting up cost-allocation tags, and implementing cloud resource governance. Capacity-and-cost-engineering owns the *requirements and models*: what the capacity model predicts, what the unit cost should be, what the budget threshold is, and how cost constraints interact with SLOs. Platform engineering implements the autoscaling group; capacity-and-cost-engineering defines the scaling policy, the cost ceiling, and the evidence standard that proves the scaling meets demand under load.

**Routing decision:** Capacity-and-cost-engineering routes infrastructure implementation, autoscaling configuration, cost-allocation tag setup, and cloud resource provisioning to [platform-engineering](../platform-engineering/SKILL.md). Platform-engineering's IaC patterns and cloud-platforms reference are the authoritative sources for implementation. Capacity-and-cost-engineering owns the capacity model, the unit-cost calculation, the budget threshold, and the load/soak evidence that validates the implementation.

### site-reliability-engineering

**What SRE owns:** SLO/SLI framework, error budget governance, incident command, on-call operations, blameless postmortems, monitoring and alerting, toil elimination, and product-focused reliability. It owns the live-service health boundary and the operational response to reliability events.

**Boundary:** SRE owns the reliability target (SLO) and the error budget that governs how much unreliability is acceptable. Capacity-and-cost-engineering owns the capacity and cost dimensions that interact with that reliability target: how much capacity is needed to meet the SLO at projected demand, what it costs to provision that capacity, and what tradeoffs exist when budget constraints prevent provisioning to the reliability target. SRE defines the SLO; capacity-and-cost-engineering calculates what it costs to meet it and what the degraded-capacity alternative looks like.

**Routing decision:** Capacity-and-cost-engineering routes SLO definition, error budget policy, incident command, and reliability engineering to [site-reliability-engineering](../site-reliability-engineering/SKILL.md). SRE is the authoritative source for reliability targets. Capacity-and-cost-engineering owns the SLO-cost tradeoff record — the artifact that makes the cost of a reliability target explicit and records the decision when budget constrains the achievable SLO.

### product-analytics-and-measurement

**What product-analytics-and-measurement owns:** Metric trees, event taxonomies, tracking plans, instrumentation QA, dashboard contracts, product funnels, cohort analysis, and measurement governance. It turns intended product outcomes into observable, governed evidence.

**Boundary:** Product-analytics owns the *demand signal* — user traffic patterns, growth rates, feature adoption, and usage trends that drive capacity forecasts. Capacity-and-cost-engineering consumes those demand signals as inputs to capacity models but does not own the instrumentation or metric definitions that produce them. Product-analytics tells us how many users are coming; capacity-and-cost-engineering translates that into what infrastructure and spend are required.

**Routing decision:** Capacity-and-cost-engineering routes demand measurement, traffic forecasting instrumentation, event taxonomy, and tracking-plan design to [product-analytics-and-measurement](../product-analytics-and-measurement/SKILL.md). Product-analytics is the authoritative source for demand signals. Capacity-and-cost-engineering owns the capacity model that translates demand into infrastructure requirements and cost projections.

### production-readiness

**What production-readiness owns:** Cross-domain evidence assembly for launch decisions (go/no-go/defer/exception). It defines the minimum production evidence packet by risk class, maps every evidence category (ownership, SLOs, observability, security, data, capacity, cost, etc.) to a named source or gap annotation, and produces a launch decision with an accountable owner.

**Boundary:** Production-readiness *consumes* capacity and cost evidence as two of its 11 evidence categories (category 10: Capacity, category 11: Cost). Capacity-and-cost-engineering *produces* that evidence: the capacity model, load-test report, cost projection, and budget approval that production-readiness requires for its launch decision. Production-readiness assembles the go/no-go verdict; capacity-and-cost-engineering provides the capacity and cost dimensions of the evidence packet.

**Routing decision:** Capacity-and-cost-engineering feeds [production-readiness](../production-readiness/SKILL.md) as a primary evidence producer for the Capacity and Cost evidence categories. Production-readiness is the consumer of capacity-and-cost-engineering outputs. The capacity model, load/soak test report, unit-economics record, and budget/quota decision are the artifacts that satisfy categories 10 and 11 of the production-readiness evidence checklist.

### product-roadmapping-and-portfolio

**What product-roadmapping-and-portfolio owns:** Outcome-based roadmaps (Now/Next/Later), strategic-bet management, capacity allocation at the portfolio level, dependency and confidence mapping, scenario planning, continue/pause/kill/revisit criteria, and stakeholder narratives. It manages the portfolio of strategic investments.

**Boundary:** Product-roadmapping owns *portfolio-level* capacity allocation — how many bets can be pursued in parallel, which bets share engineering capacity, and how capacity constraints affect roadmap sequencing. Capacity-and-cost-engineering owns *infrastructure-level* capacity — what compute, storage, and network resources are needed to operate the services that deliver those bets, and what they cost. A roadmap decision to pursue three bets in parallel creates demand; capacity-and-cost-engineering models whether the infrastructure can support that demand and what it will cost.

**Routing decision:** Capacity-and-cost-engineering routes portfolio capacity allocation, bet sequencing, and roadmap tradeoffs to [product-roadmapping-and-portfolio](../product-roadmapping-and-portfolio/SKILL.md). Product-roadmapping owns the strategic capacity decisions. Capacity-and-cost-engineering owns the technical capacity model that confirms or constrains those decisions with infrastructure-level evidence.

### resilience-and-recovery

**What resilience-and-recovery owns:** Resilience design, degradation-path definition, recovery verification through exercises (game days, DR tests, restore tests), RTO/RPO decision records, and exercise evidence standards. It owns the work that happens before and between incidents — designing for failure and proving recovery capability.

**Boundary:** Resilience-and-recovery's degradation-path design (which functions are shed, in what order, under what conditions) directly constrains capacity-and-cost-engineering's degraded-mode capacity model. Capacity-and-cost-engineering answers: if the recommendation engine is shed (resilience decision), what does the remaining capacity requirement look like and what does it cost? Resilience defines what to shed; capacity-and-cost-engineering models the capacity and cost of the degraded state.

**Routing decision:** Capacity-and-cost-engineering routes degradation-path design, recovery verification, and RTO/RPO decision records to [resilience-and-recovery](../resilience-and-recovery/SKILL.md). Resilience-and-recovery owns the degradation design. Capacity-and-cost-engineering owns the capacity-and-cost model of degraded states and ensures that load/soak evidence covers degraded-mode capacity scenarios.

## What capacity-and-cost-engineering does NOT own

- **Financial P&L, fundraising, SaaS metrics (ARR/churn/NDR), or pricing strategy**: owned by financial-modeling. Capacity-and-cost-engineering does not build financial statements, calculate CAC/LTV, or model fundraising rounds.
- **Infrastructure implementation**: owned by platform-engineering. Capacity-and-cost-engineering does not write Terraform, configure autoscaling groups, or provision resources.
- **SLO definition and error budget governance**: owned by site-reliability-engineering. Capacity-and-cost-engineering does not define SLOs or manage error budgets — it models the cost and capacity implications of SLO choices.
- **Demand measurement and traffic instrumentation**: owned by product-analytics-and-measurement. Capacity-and-cost-engineering consumes demand signals; it does not own the tracking plan or metric tree.
- **Production launch decisions**: owned by production-readiness. Capacity-and-cost-engineering provides capacity and cost evidence; it does not make the go/no-go call.
- **Portfolio capacity allocation and roadmap sequencing**: owned by product-roadmapping-and-portfolio. Capacity-and-cost-engineering provides infrastructure-capacity evidence; it does not decide which bets to pursue or in what order.
- **Degradation-path design and recovery verification**: owned by resilience-and-recovery. Capacity-and-cost-engineering models the capacity and cost of degraded states; it does not design or exercise the degradation path.

## Summary

Capacity-and-cost-engineering fills a gap between financial modeling (which owns the business view of cost), platform engineering (which implements infrastructure), SRE (which owns reliability targets), product analytics (which owns demand signals), production-readiness (which consumes capacity/cost evidence), product roadmapping (which allocates portfolio capacity), and resilience-and-recovery (which owns degradation design). It is the method for modeling technical capacity, calculating unit cost, defining budget and quota controls, requiring load/soak evidence, and making cost-performance tradeoffs explicit — producing evidence that feeds production-readiness decisions and constrains or supports roadmap and reliability choices.

## Multi-tenant ownership boundary

`multi-tenant-saas-architecture` owns tenant semantics, control/application
planes, tenancy and partitioning choices, lifecycle, entitlements, metering and
billing handoffs, and the end-to-end SaaS architecture. This skill owns the
measured capacity and cost consequences: tenant demand distributions, hot tenants,
partition skew, pooled versus siloed headroom, tier-linked quotas and admission,
fairness evidence, shared-cost allocation, and tenant-variable unit cost.

`secure-software-engineering` owns isolation threats and enforceable controls;
`financial-modeling` owns pricing, margin, and commercial outcomes;
`platform-engineering` owns resource and telemetry implementation;
`product-analytics-and-measurement` owns demand instrumentation and metric
definitions; `site-reliability-engineering` owns SLOs, error budgets, and live
operations; and `software-architecture` owns general system boundary and
topology decisions. A multi-tenant capacity claim must hand off to each owner
whose evidence or authority it requires, rather than absorbing those workflows.

# Multi-Tenant Capacity and Unit Cost

Use this reference when a shared service serves multiple tenants whose demand,
promises, or resource footprints differ. The purpose is to produce capacity and
cost evidence, not to choose the SaaS domain model or security controls.

## Start with distributions

Represent demand as tenant profiles rather than one aggregate average. For each
profile, record the demand units, request or job mix, payload or object size,
concurrency, burst shape, background work, storage growth, and tier or placement
promise. Use observed tenant cohorts where possible and label synthetic profiles
as assumptions. Preserve the distribution's shape: a small number of very large
tenants can dominate a pooled system even when the mean tenant looks modest.

Useful views include:

- per-tenant time series for rate, concurrency, queue depth, storage, and work;
- a distribution across tenants for each resource, with the statistic chosen for
  the decision rather than a default percentile;
- joint views that show whether high demand, large objects, and burstiness occur
  in the same tenants;
- a scenario for new, growing, dormant, migrating, and unusually hot tenants;
- confidence and provenance for every profile, including sampling bias and
  omitted tenants.

Do not substitute a global average, a single representative tenant, or an
arbitrary percentile for the distribution. If a percentile or cap is selected,
explain the user promise, failure consequence, and evidence that make it useful.

## Find skew and hot tenants

Map the demand profile onto the resource boundary that can saturate: CPU,
memory, connections, partitions, IOPS, queue workers, cache capacity, search
shards, network, or an external quota. Partition skew is a separate question from
request skew. A tenant may be moderate overall but overload one partition, key
range, shard, worker pool, or availability zone.

For each hot-tenant or skew scenario, record:

1. the detection signal and the identity granularity available to operators;
2. the resource and neighboring tenants exposed to contention;
3. the admission, queueing, scheduling, placement, throttling, or isolation
   response;
4. the impact on the hot tenant and on protected tenants;
5. the recovery and rebalancing path, including backlog and data-integrity
   checks; and
6. the evidence boundary, workload mix, duration, and unresolved gaps.

Route isolation mechanisms, authorization, and noisy-neighbor threat analysis to
`secure-software-engineering`. Route the end-to-end tenancy, lifecycle, and
placement architecture to `multi-tenant-saas-architecture`.

## Compare pooled and siloed headroom

For a pooled deployment, model shared baseline, aggregate demand distribution,
correlation between tenants, admission behavior, and the headroom needed to
protect the promised service during a hot-tenant or dependency scenario. Pooling
can benefit from imperfectly correlated demand, but its usable headroom is
bounded by the resource with the worst contention or skew, not by a fleet average.

For a siloed or dedicated deployment, model the per-tenant baseline, reserved
headroom, failure-domain requirement, idle capacity, and operational overhead.
Do not assume that a silo is cheaper or more reliable. Compare the scenarios that
matter: ordinary load, tenant growth, burst, tenant failure, placement movement,
and loss of a resource or failure domain. Hybrid placement should show which
resources are pooled and which are dedicated, with separate evidence for each.

Headroom is a decision variable. State what it protects, the time horizon and
provisioning lead time, the observed saturation behavior, and the cost of unused
capacity. Never present one utilization or headroom percentage as a general rule.

## Translate tier promises into capacity controls

For every tier promise, connect the customer-visible statement to a measurable
capacity behavior: sustained demand, burst allowance, concurrency, storage or
job limit, latency treatment, priority, isolation, or recovery treatment. Record
whether the promise is a contract, a product default, or an operational goal.

Quotas and rate limits are controls, not proof of capacity. Define the scope,
steady behavior, burst behavior, response to excess, fairness objective, and
backpressure or degradation path. Admission should preserve the critical path
and make rejection or delay explicit rather than allowing unbounded queues and
retry amplification.

Fairness is contextual. Choose the fairness policy from the promise and resource:
weighted shares, reserved capacity, tier priority, work conservation, isolation,
or another explicit rule. Measure both protected-tenant outcomes and the
consequence for the tenant being constrained. Do not use a universal fairness
ratio, quota, utilization target, or rejection threshold. A threshold is valid
only when its rationale, owner, workload, and review trigger are recorded.

## Produce tenant-variable unit cost

Separate the cost model into at least:

- **platform baseline:** costs that remain for the service or pool when tenant
  demand is absent or minimal;
- **tenant-variable cost:** incremental compute, storage, transfer, operations,
  or other resource cost attributable to a tenant profile; and
- **allocation of shared cost:** the chosen method for assigning pooled cost,
  such as measured consumption, reserved entitlement, capacity reservation, or a
  transparent blended allocation.

Report direct or marginal cost separately from fully allocated cost. Use the same
period, scope, and demand denominator. For tenant `t`, a useful model is:

```text
tenant cost(t) = allocated baseline(t) + measured variable cost(t)
tenant unit cost(t) = tenant cost(t) / tenant demand units(t)
```

The allocation method must explain how idle pooled capacity, shared control-plane
work, replication, support, backups, and failure-domain redundancy are treated.
Keep fixed commitments separate from costs that change with demand. Segment units
by materially different work types rather than averaging cheap metadata work with
expensive jobs. Route revenue, pricing, margin, and commercial packaging to
`financial-modeling`; route cost tags, billing exports, and resource policy
implementation to `platform-engineering`.

## Evidence standard

Before approving a tenant capacity or unit-cost claim, require representative
per-tenant load and soak evidence. The test should exercise the relevant tenant
distribution concurrently, include hot and skewed profiles, use production-like
data and placement, and observe tenant-level and shared-resource outcomes. Record
latency, errors, queueing, throttling, admission decisions, resource saturation,
partition balance, backlog recovery, and cost inputs.

Component benchmarks can explain a mapping, but they do not establish end-to-end
fairness or pooled headroom. A fleet aggregate can show total spend, but it does
not establish tenant-variable cost. If representative evidence is unavailable,
the output is a model with an explicit gap and a required test, not a validated
capacity claim.

## Completion check

Stop when the model names the tenant distribution, hot/skew scenario, pooled or
siloed headroom choice, tier promise, quota/admission behavior, fairness policy,
baseline and variable cost allocation, representative per-tenant load/soak
evidence, owners, and unresolved assumptions. Escalate a promise that cannot be
supported without silently weakening reliability, privacy, security, or user
outcomes.

# Source Index

This skill is an original, task-centered synthesis. Public sources inform
terminology and decision pressures; they are not copied as instructional text.

| Source | Use in this skill | URL |
|---|---|---|
| Google SRE resources | Capacity, overload, service behavior, and evidence-oriented reliability framing | https://sre.google/sre-book/table-of-contents/ |
| OpenSLO specification | Portable vocabulary for connecting service objectives to evidence; SLO ownership remains with SRE | https://github.com/OpenSLO/OpenSLO |
| OpenTelemetry semantic conventions | Tenant-aware measurement vocabulary and observability handoff; implementation remains with platform/telemetry owners | https://opentelemetry.io/docs/specs/semconv/ |
| FinOps Framework | Shared-cost allocation, unit economics, and accountability vocabulary; financial outcomes remain with financial-modeling | https://www.finops.org/framework/ |
| Kubernetes resource management documentation | Resource requests, limits, and scheduling concepts as implementation context; platform-engineering owns configuration | https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/ |
| RFC 6585 | HTTP status vocabulary for rate-limit and overload responses; API contract details remain with api-design-and-evolution | https://www.rfc-editor.org/rfc/rfc6585 |

## Ownership and transformation boundary

- End-to-end tenant semantics, control/application planes, lifecycle, and
  placement architecture belong to `multi-tenant-saas-architecture`.
- Threat controls and tenant isolation evidence belong to
  `secure-software-engineering`.
- Financial statements, pricing, margin, and SaaS outcomes belong to
  `financial-modeling`.
- Infrastructure and telemetry implementation belong to
  `platform-engineering`; SLOs and live operations belong to
  `site-reliability-engineering`.
- The supplied private comparison report informed the gap framing only. No
  purchased ebook is a source file for this skill, and no protected prose,
  table, diagram, example, taxonomy, or chapter structure is reproduced.

## Review rule

If a future edit resembles a source's distinctive expression or presentation,
rewrite it from the issue requirements, public sources, and repository ownership
boundaries before publication.

# Budget / Quota Decision

Fill this template to define a budget threshold or quota/rate-limit enforcement decision with operational consequences.

## Budget definition

- **Scope:** _[fill: service, team, project, or platform — what this budget covers]_
- **Budget owner:** _[fill: name or role accountable for budget decisions]_
- **Period:** _[fill: monthly / quarterly / annual]_
- **Budget amount:** _[fill: $X per period]_
- **Cost attribution method:** _[fill: how costs are attributed to this scope — tags, account structure, manual allocation]_

## Threshold configuration

| Threshold | Type | Value | Trigger | Operational consequence | User-facing impact |
|-----------|------|-------|---------|------------------------|---------------------|
| _[fill: 70%]_ | Alert | _[fill: $Y]_ | _[fill: notification to budget owner + cost channel]_ | _[fill: review spending trend; no automated action]_ | _[fill: none]_ |
| _[fill: 90%]_ | Soft cap | _[fill: $Z]_ | _[fill: throttle non-critical workloads; reduce provisioning]_ | _[fill: autoscaling ceiling lowered; batch jobs deferred]_ | _[fill: degraded performance for non-core functions]_ |
| _[fill: 100%]_ | Hard cap | _[fill: $BUDGET]_ | _[fill: deny new resource provisioning; rate-limit ingress]_ | _[fill: requests above cap rejected with 429]_ | _[fill: service unavailable for requests exceeding cap]_ |

## Quota / rate-limit enforcement

- **Enforcement mechanism:** _[fill: API gateway rate limiter, resource-quota admission controller, cloud budget action, or equivalent]_
- **Rate-limit scope:** _[fill: per-user, per-IP, per-API-key, per-service, or global]_
- **Rate-limit value:** _[fill: e.g., 1000 requests/second, 500 concurrent connections]_
- **Quota period:** _[fill: per-second, per-minute, per-day, per-month]_
- **Hard vs burst:** _[fill: is there a burst allowance above the steady rate? what multiplier and duration?]_
- **Response when exceeded:** _[fill: HTTP 429 with Retry-After header, queued with backpressure, or denied]_
- **Monitoring:** _[fill: how is enforcement measured? rate-limit hit counter, quota-usage dashboard, alert on near-exhaustion]_

## Cost attribution

- **Attribution method:** _[fill: resource tags, account/project structure, label-based allocation, or manual]_
- **Shared cost allocation:** _[fill: how shared infrastructure costs are divided — proportional to usage, fixed split, or other]_
- **Attribution review cadence:** _[fill: monthly / quarterly]_

## Anomaly detection

- **Anomaly trigger:** _[fill: e.g., spend increase >30% day-over-day, or >15% week-over-week]_
- **Notification:** _[fill: who is notified and through what channel]_
- **Response procedure:** _[fill: triage steps — is it legitimate demand, a bug, a misconfiguration, or an attack?]_
- **Escalation:** _[fill: when does this become an incident? who is the incident commander?]_

## Assumptions

- [ ] _[fill: current spending pattern is representative of normal operation]_
- [ ] _[fill: cost attribution is accurate and complete — state assumption or evidence]_
- [ ] _[fill: budget amount is adequate for projected demand — or state what happens if not]_
- [ ] _[fill: any other unverified assumption]_

## Evidence sources

| Source | What it provides |
|--------|-----------------|
| _[fill: cost dashboard / cloud bill]_ | _[fill: current and historical spend data]_ |
| _[fill: capacity model]_ | _[fill: projected spend at demand forecast]_ |
| _[fill: ...]_ | _[fill: ...]_ |

## Ownership

- **Budget owner:** _[fill: name or role]_
- **Quota/rate-limit config owner:** _[fill: name or team that configures enforcement]_
- **Anomaly responder:** _[fill: name or on-call rotation]_
- **Approver:** _[fill: name of person who approved this budget/quota decision]_

## Tradeoffs

- _[fill: e.g., tighter quotas → earlier denial but more predictable cost]_
- _[fill: e.g., generous burst allowance → better user experience but cost-spike risk]_
- _[fill: e.g., hard cap at 100% budget → service may be unavailable; soft cap preferred if core functions can degrade gracefully]_

# Capacity Model

Fill this template to produce a capacity model connecting demand to infrastructure requirements over a projection horizon.

## Demand assumptions

- **Current demand:** _[fill: e.g., 500 requests/second, 10,000 concurrent users, 2 TB/day ingested]_
- **Demand unit:** _[fill: requests/sec, concurrent users, GB ingested, messages/sec — be specific]_
- **Growth rate:** _[fill: e.g., 15% month-over-month, or flat with seasonal spike]_
- **Known peak events:** _[fill: product launch, Black Friday, seasonal — date/range, expected multiplier over baseline]_
- **Projection horizon:** _[fill: e.g., 6 months, 12 months]_
- **Confidence in demand forecast:** _[fill: high/medium/low with rationale — what is this based on? historical data, product roadmap, market estimate?]_

## Capacity-unit mapping

| Demand unit | Capacity unit | Mapping ratio | Rationale |
|-------------|---------------|---------------|-----------|
| _[fill: e.g., 1 request/sec]_ | _[fill: e.g., 0.25 vCPU, 256 MB memory]_ | _[fill: e.g., measured at 70% utilization]_ | _[fill: from load test 2026-01-15]_ |
| _[fill: ...]_ | _[fill: ...]_ | _[fill: ...]_ | _[fill: ...]_ |

## Utilization targets

| Resource | Target utilization | Rationale | Evidence |
|----------|-------------------|-----------|----------|
| CPU | _[fill: e.g., 70%]_ | _[fill: e.g., spiky traffic needs headroom for P99 latency]_ | _[fill: load test at 80% showed P99 degradation]_ |
| Memory | _[fill: e.g., 80%]_ | _[fill: e.g., GC overhead acceptable up to 80%]_ | _[fill: soak test 24h at 85% — no OOM, stable]_ |
| Storage | _[fill: e.g., 75%]_ | _[fill: e.g., provisioned IOPS degrade above 80%]_ | _[fill: vendor docs + observed IOPS curve]_ |
| Network | _[fill: e.g., 60%]_ | _[fill: e.g., burst capacity for peak events]_ | _[fill: ...]_ |

## Scaling triggers

| Resource | Trigger threshold | Action | Lead time |
|----------|------------------|--------|-----------|
| _[fill: CPU]_ | _[fill: sustained > 60% for 5 min]_ | _[fill: scale out by 2 instances]_ | _[fill: 3 min]_ |
| _[fill: Storage]_ | _[fill: projected to hit 75% in 30 days]_ | _[fill: provision additional 500 GB]_ | _[fill: 7 days for procurement]_ |

## Capacity projection

| Period | Projected demand | Required capacity | Scaling action | Estimated cost |
|--------|-----------------|-------------------|----------------|----------------|
| _[fill: Month 1]_ | _[fill: ...]_ | _[fill: ...]_ | _[fill: none]_ | _[fill: $X]_ |
| _[fill: Month 2]_ | _[fill: ...]_ | _[fill: ...]_ | _[fill: scale out 2 instances]_ | _[fill: $Y]_ |
| _[fill: ...]_ | _[fill: ...]_ | _[fill: ...]_ | _[fill: ...]_ | _[fill: ...]_ |

## Assumptions

- [ ] _[fill: assumption about demand pattern, growth stability, peak shape]_
- [ ] _[fill: assumption about unit cost stability, no price changes]_
- [ ] _[fill: assumption about no architecture changes that alter capacity/demand ratio]_
- [ ] _[fill: any other unverified assumption]_

Every assumption without evidence must be labeled as such.

## Evidence sources

| Source | What it provides | Boundary exercised |
|--------|-----------------|--------------------|
| _[fill: load test 2026-01-15]_ | _[fill: capacity/demand ratio at 70% CPU]_ | _[fill: end-to-end]_ |
| _[fill: production metrics Jan-Mar 2026]_ | _[fill: observed growth rate]_ | _[fill: production]_ |
| _[fill: ...]_ | _[fill: ...]_ | _[fill: component / integration / end-to-end / production]_ |

## Ownership

- **Model owner:** _[fill: name or team]_
- **Capacity provisioning owner:** _[fill: name or team — may differ from model owner]_
- **Review cadence:** _[fill: e.g., monthly, or on demand change >20%]_

## Tradeoffs

- _[fill: e.g., lower utilization target → higher cost but lower latency risk]_
- _[fill: e.g., faster scaling trigger → more responsive but more frequent provisioning events]_
- _[fill: any tradeoff between cost, performance, reliability, or operational complexity]_

# Load / Soak Test Plan

Fill this template to design a load or soak test that produces valid capacity evidence. A capacity claim without load/soak evidence is incomplete.

## Test identification

- **Test objective:** _[fill: what capacity decision does this test support? e.g., "validate that the service can handle projected peak + 20% headroom at P99 latency < 200ms"]_
- **Test type:** _[fill: load test (target throughput, short duration) / soak test (sustained load, extended duration) / both]_
- **Test owner:** _[fill: name or team]_

## Target throughput

- **Target throughput:** _[fill: e.g., 1000 requests/second]_
- **Rationale:** _[fill: e.g., projected peak demand 850 req/s + 20% headroom]_
- **Ramp-up profile:** _[fill: how quickly does load ramp to target? e.g., linear over 5 minutes, step function]_
- **Steady-state duration (load test):** _[fill: e.g., 30 minutes after ramp-up]_
- **Soak duration (if applicable):** _[fill: e.g., 24 hours]_

## Test environment

- **Environment:** _[fill: production-like staging, dedicated test environment, or production (state which)]_
- **Environment parity:** _[fill: how does this environment differ from production? instance sizes, data volumes, network topology — every difference is an assumption]_
- **Justification:** _[fill: why is this environment sufficient evidence? if it is not production-like, what is the risk of extrapolation?]_

## Success criteria

| Criterion | Target | Measurement method |
|-----------|--------|--------------------|
| P50 latency | _[fill: e.g., < 50ms]_ | _[fill: client-side histogram, server-side metric]_ |
| P99 latency | _[fill: e.g., < 200ms]_ | _[fill: client-side histogram]_ |
| Error rate | _[fill: e.g., < 0.1% non-5xx]_ | _[fill: response status aggregation]_ |
| CPU utilization | _[fill: e.g., < 70% sustained]_ | _[fill: OS metrics / container metrics]_ |
| Memory utilization | _[fill: e.g., stable — no upward trend over soak]_ | _[fill: OS metrics; max threshold e.g., 80%]_ |
| _[fill: other]_ | _[fill: ...]_ | _[fill: ...]_ |

## Data collection

| Metric | Source | Granularity | Retention |
|--------|--------|-------------|-----------|
| Latency percentiles | _[fill: load generator]_ | _[fill: 1-second buckets]_ | _[fill: duration of test + 30 days]_ |
| Resource utilization | _[fill: infrastructure metrics]_ | _[fill: 10-second intervals]_ | _[fill: duration of test + 30 days]_ |
| Error logs | _[fill: application logs]_ | _[fill: per-event]_ | _[fill: duration of test + 30 days]_ |
| _[fill: ...]_ | _[fill: ...]_ | _[fill: ...]_ | _[fill: ...]_ |

## Soak-specific checks

For soak tests, additionally monitor and record:

- [ ] Memory trend (flat, slowly rising, or leaking — with rate estimate)
- [ ] File descriptor count (stable or growing)
- [ ] Connection pool utilization (stable or growing)
- [ ] Disk usage growth (log rotation, temp files, WAL growth)
- [ ] GC pause time and frequency (stable or degrading)
- [ ] Any metric with a statistically significant trend over the soak period

## Test boundary

- **Boundary exercised:** _[fill: component / integration / end-to-end / production]_
- **What this test does NOT cover:** _[fill: e.g., does not test cross-region failover, does not exercise all API endpoints, does not include cold-start scenarios]_

## Evidence record

After the test, complete this section:

- **Test date:** _[fill: YYYY-MM-DD]_
- **Actual throughput achieved:** _[fill: ...]_
- **P50 latency (observed):** _[fill: ...]_
- **P99 latency (observed):** _[fill: ...]_
- **Error rate (observed):** _[fill: ...]_
- **Peak CPU utilization:** _[fill: ...]_
- **Peak memory utilization:** _[fill: ...]_
- **Soak findings (if applicable):** _[fill: memory trend, FD trend, connection pool trend, any anomalies]_
- **Verdict:** _[fill: PASS — all success criteria met / FAIL — criteria not met (list which) / PASS WITH GAPS — anomalies found (list which)]_
- **Follow-up actions:** _[fill: any findings requiring investigation or re-test]_

## Assumptions

- [ ] _[fill: test environment is sufficiently representative of production]_
- [ ] _[fill: load profile (request mix, payload sizes, user behavior) is representative of real traffic]_
- [ ] _[fill: no external dependencies have different behavior in test vs production]_
- [ ] _[fill: any other unverified assumption]_

## Ownership

- **Test designer:** _[fill: name or team]_
- **Test executor:** _[fill: name or team — may differ from designer]_
- **Evidence reviewer:** _[fill: name or role who reviews and accepts the evidence]_

# SLO-Cost Tradeoff Record

Fill this template to make an SLO-cost tradeoff explicit with evidence, ownership, and an accountable decision. An implicit acceptance of a lower SLO due to budget is not a decision — it is a gap.

## SLO under discussion

- **Service:** _[fill: service name]_
- **Current SLO:** _[fill: e.g., 99.9% availability, P99 latency < 200ms]_
- **SLO owner:** _[fill: name or team accountable for the SLO]_

## Cost of meeting the SLO

- **Current demand:** _[fill: e.g., 500 req/s]_
- **Capacity required at current SLO:** _[fill: e.g., 12 instances, 2-region]_
- **Current monthly cost:** _[fill: $X/month]_
- **Evidence:** _[fill: link to capacity model, unit-economics record, load-test report]_

## Projected cost at demand forecast

- **Projected demand (horizon):** _[fill: e.g., 1200 req/s in 6 months]_
- **Capacity required at projected demand:** _[fill: e.g., 28 instances, 2-region]_
- **Projected monthly cost:** _[fill: $Y/month]_
- **Evidence:** _[fill: link to capacity model]_

## Budget constraint (if applicable)

- **Budget cap (period):** _[fill: $B/month or "no explicit cap"]_
- **Gap:** _[fill: e.g., projected cost exceeds budget by 40% — $Z/month gap]_
- **Gap trigger:** _[fill: at what point does the gap become material? e.g., when projected cost exceeds budget by >10%]_

## Alternative SLO under consideration

- **Proposed alternative SLO:** _[fill: e.g., 99.5% availability, P99 latency < 500ms]_
- **Capacity required at alternative SLO:** _[fill: e.g., 8 instances, single-region]_
- **Projected monthly cost at alternative SLO:** _[fill: $C/month]_
- **Cost difference:** _[fill: $Y - $C = $D saved per month]_
- **Evidence:** _[fill: load test at alternative capacity, capacity model for alternative SLO]_

## Degradation path

If the alternative SLO is chosen, what does the degradation path look like?

- **What degrades:** _[fill: e.g., P99 latency increases; single-region means no cross-region failover]_
- **User impact:** _[fill: e.g., users in distant regions see higher latency; region outage → full service unavailability]_
- **Maximum degraded-operation window:** _[fill: e.g., degraded mode is acceptable for 6 months while budget is renegotiated; escalation after that]_
- **Recovery path:** _[fill: how does the service return to the original SLO? budget increase, architecture optimization, demand management?]_

## Error budget impact

- **Current error budget (at current SLO):** _[fill: e.g., 43.2 minutes/month downtime at 99.9%]_
- **Error budget at alternative SLO:** _[fill: e.g., 216 minutes/month downtime at 99.5%]_
- **Error budget burn-down risk:** _[fill: is the alternative SLO's error budget sufficient for expected incident frequency and duration?]_

## Decision

- **Chosen SLO:** _[fill: current SLO / alternative SLO / other]_
- **Rationale:** _[fill: why this choice — cost, reliability, user impact, business priority]_
- **Accountable owner:** _[fill: name — the person who owns this decision, not a team or role]_
- **Approver:** _[fill: name of person who approved — may differ from accountable owner]_
- **Decision date:** _[fill: YYYY-MM-DD]_
- **Review date:** _[fill: when this decision is re-evaluated — e.g., after 3 months or when demand reaches 80% of projected]_

## Guardrails

- [ ] **Cost optimization must not degrade reliability, privacy, or user outcomes.** If the tradeoff violates this principle, it is escalated — not accepted.
- [ ] The chosen SLO has been reviewed by the SLO owner and the cost owner.
- [ ] Load-test evidence exists for the chosen capacity at the chosen SLO.
- [ ] The degradation path (if applicable) has been reviewed and accepted.

## Assumptions

- [ ] _[fill: demand forecast is accurate — state assumption or evidence]_
- [ ] _[fill: unit costs are stable — state assumption or evidence]_
- [ ] _[fill: no architecture changes that would alter the capacity/SLO relationship]_
- [ ] _[fill: any other unverified assumption]_

## Tradeoffs

- _[fill: e.g., lower SLO → lower cost but increased risk of user-visible degradation]_
- _[fill: e.g., multi-region cost vs single-region risk — what is the business cost of a region-wide outage?]_
- _[fill: e.g., faster recovery (lower MTTR) can compensate for lower SLO — is the MTTR target achievable?]_

# Tenant Capacity and Unit-Cost Model

Fill this template when tenant demand or tier promises change the capacity and
cost decision. Use measured distributions where available; mark assumptions and
synthetic profiles clearly.

## Service and promise

- **Service/resource boundary:** _[fill: API, worker pool, database partition, storage, etc.]_
- **Decision:** _[fill: sizing, placement, quota, tier promise, or cost allocation decision]_
- **Tenant tiers or profiles in scope:** _[fill: names and why they are representative]_
- **Customer promises:** _[fill: contractual promises, product defaults, and operational goals separately]_
- **SLO/performance dependency:** _[fill: owner and relevant target; route SLO definition to SRE]_

## Tenant demand profiles

| Profile or cohort | Tenant count/weight | Demand and mix | Burst/concurrency | Storage/background work | Evidence/confidence |
|---|---:|---|---|---|---|
| _[fill: ordinary pooled tenant]_ | _[fill]_ | _[fill]_ | _[fill]_ | _[fill]_ | _[fill]_ |
| _[fill: hot or bursty tenant]_ | _[fill]_ | _[fill]_ | _[fill]_ | _[fill]_ | _[fill]_ |
| _[fill: dedicated/silo tenant]_ | _[fill]_ | _[fill]_ | _[fill]_ | _[fill]_ | _[fill]_ |

- **Distribution view:** _[fill: per-tenant time series, selected statistic(s), correlation/skew analysis]_
- **Sampling limits:** _[fill: omitted tenants, seasonality, new-tenant uncertainty, synthetic data]_

## Skew and hot-tenant analysis

- **Resource/partition boundary:** _[fill: shard, key range, worker, zone, cache, queue, or other]_
- **Detection signal:** _[fill: tenant-level and shared-resource signal]_
- **Contention path:** _[fill: which tenants or tiers are affected and how]_
- **Response:** _[fill: admission, queue, scheduling, throttling, placement, or isolation behavior]_
- **Recovery/rebalance:** _[fill: backlog, movement, reconciliation, and verification]_
- **Security handoff:** _[fill: isolation and authorization evidence owned by secure-software-engineering]_

## Pooled, siloed, or hybrid comparison

| Scenario | Pooled baseline/headroom | Siloed baseline/headroom | Hybrid choice | Evidence and tradeoff |
|---|---|---|---|---|
| Ordinary load | _[fill]_ | _[fill]_ | _[fill]_ | _[fill]_ |
| Hot tenant or burst | _[fill]_ | _[fill]_ | _[fill]_ | _[fill]_ |
| Failure-domain loss | _[fill]_ | _[fill]_ | _[fill]_ | _[fill]_ |
| Tenant growth/movement | _[fill]_ | _[fill]_ | _[fill]_ | _[fill]_ |

- **Headroom rationale:** _[fill: what it protects, lead time, observed saturation, and cost of idle capacity; no universal percentage]_

## Quota, admission, and fairness

- **Quota scope and units:** _[fill: tenant/tier/resource and steady/burst units]_
- **Admission rule:** _[fill: accept, queue, prioritize, throttle, or reject and why]_
- **Excess response:** _[fill: status/backpressure/degradation and customer communication]_
- **Fairness policy:** _[fill: explicit policy for this promise/resource, not a universal ratio]_
- **Fairness evidence:** _[fill: protected-tenant outcomes, constrained-tenant outcome, workload mix, duration, owner]_
- **Review trigger:** _[fill: what observed change causes recalibration]_
- **Implementation handoff:** _[fill: platform owner; this record does not configure infrastructure]_

## Tenant-variable unit cost

- **Period and scope:** _[fill: same period for cost and demand]_
- **Platform baseline cost:** _[fill: idle/minimum pool, control plane, shared redundancy]_
- **Variable cost pool:** _[fill: compute, storage, transfer, jobs, support, or other measured costs]_
- **Shared-cost allocation:** _[fill: measured use, reserved entitlement, capacity reservation, blended, or other rationale]_
- **Tenant demand unit:** _[fill: request/job/GB/concurrency unit and measurement source]_

```text
tenant cost = allocated baseline + measured variable cost
tenant unit cost = tenant cost / tenant demand units
```

| Tenant/profile | Allocated baseline | Variable cost | Total cost | Demand units | Unit cost | Confidence/gap |
|---|---:|---:|---:|---:|---:|---|
| _[fill]_ | _[fill]_ | _[fill]_ | _[fill]_ | _[fill]_ | _[fill]_ | _[fill]_ |

- **Financial handoff:** _[fill: pricing, margin, or commercial decision routed to financial-modeling]_

## Representative load/soak evidence

- **Test plan:** _[fill: link to `templates/load-soak-test-plan.md`]_
- **Profiles exercised concurrently:** _[fill: ordinary, hot, skewed, tier, placement]_
- **Environment parity:** _[fill: data volume, topology, partitions, dependencies]_
- **Observed tenant outcomes:** _[fill: latency, errors, throttles, admission, backlog]_
- **Observed shared outcomes:** _[fill: saturation, partition balance, recovery, cost inputs]_
- **Soak findings:** _[fill: leaks, queue growth, fairness drift, or other trends]_
- **Verdict:** _[fill: validated / model with gap / failed; list criteria]_

## Assumptions, ownership, and decision

- **Assumptions and gaps:** _[fill]_
- **Capacity/model owner:** _[fill]_
- **Demand measurement owner:** _[fill: route instrumentation to product-analytics-and-measurement]_
- **SLO/reliability owner:** _[fill: route SLO and error budget to site-reliability-engineering]_
- **Decision owner and review date:** _[fill]_
- **Chosen option and rationale:** _[fill]_

# Unit Economics Record

Fill this template to calculate and record the unit cost of serving demand at the infrastructure level.

## Unit definition

- **Unit:** _[fill: e.g., cost per API request, cost per active user/month, cost per GB stored/month, cost per provisioned TPS]_
- **Why this unit:** _[fill: what decision does this unit cost inform? e.g., pricing, budget planning, SLO cost sensitivity]_

## Cost numerator

- **Total cost of capacity (period):** _[fill: e.g., $12,000/month for compute, storage, network, and data transfer]_
- **Allocation method:** _[fill: direct resource cost, attributed shared cost, or fully loaded (including overhead). State which and why.]_
- **Cost scope:** _[fill: single service / team / platform — what is included and what is excluded]_
- **Cost source:** _[fill: cloud bill, internal cost dashboard, finance report — with date]_

## Demand denominator

- **Total demand units served (same period):** _[fill: e.g., 50,000,000 requests/month, 10,000 active users]_
- **Measurement source:** _[fill: production metrics, CDN logs, API gateway — with date and measurement method]_
- **Confidence:** _[fill: high/medium/low — is this measured or estimated?]_

## Unit cost calculation

```
unit cost = total cost of capacity / total demand units served
         = [fill: $X] / [fill: Y units]
         = [fill: $Z per unit]
```

- **Unit cost:** _[fill: $Z per unit]_
- **Period:** _[fill: month/quarter/year — must match numerator and denominator]_

## Cost-per-SLO comparison

| SLO target | Required capacity (relative to baseline) | Estimated unit cost | Cost multiplier vs baseline |
|------------|----------------------------------------|---------------------|-----------------------------|
| _[fill: 99.9%]_ | _[fill: 1.0x — baseline]_ | _[fill: $Z/unit]_ | _[fill: 1.0x]_ |
| _[fill: 99.95%]_ | _[fill: 1.3x — redundancy, faster failover]_ | _[fill: $Z*1.3/unit]_ | _[fill: 1.3x]_ |
| _[fill: 99.99%]_ | _[fill: 2.5x — multi-region, active-active]_ | _[fill: $Z*2.5/unit]_ | _[fill: 2.5x]_ |

## Unit cost trend

| Period | Unit cost | Change | Explanation |
|--------|-----------|--------|-------------|
| _[fill: current]_ | _[fill: $Z]_ | — | — |
| _[fill: projected next quarter]_ | _[fill: $Z']_ | _[fill: +/-X%]_ | _[fill: scale, reserved capacity, price change]_ |
| _[fill: ...]_ | _[fill: ...]_ | _[fill: ...]_ | _[fill: ...]_ |

## Assumptions

- [ ] _[fill: cost allocation method is accurate — state assumption or evidence]_
- [ ] _[fill: demand measurement captures all relevant units — state assumption or evidence]_
- [ ] _[fill: unit cost is stable over the projection period — or state change driver]_
- [ ] _[fill: any other unverified assumption]_

## Evidence sources

| Source | What it provides | Boundary exercised |
|--------|-----------------|--------------------|
| _[fill: cloud bill / cost dashboard]_ | _[fill: cost numerator]_ | _[fill: production]_ |
| _[fill: production metrics]_ | _[fill: demand denominator]_ | _[fill: production]_ |
| _[fill: load test at SLO targets]_ | _[fill: capacity multipliers at each SLO level]_ | _[fill: end-to-end]_ |

## Ownership

- **Unit cost owner:** _[fill: name or team accountable for this calculation]_
- **Cost data owner:** _[fill: name or team that provides cost numerator]_
- **Demand data owner:** _[fill: name or team that provides demand denominator]_

## Tradeoffs

- _[fill: e.g., higher SLO → higher unit cost; is the reliability improvement worth the cost per unit?]_
- _[fill: e.g., fully loaded cost includes overhead that obscures infrastructure-level decisions]_
- _[fill: e.g., averaging across all services hides services with outlier unit costs]_