Models do not know your traffic — but they are excellent at structuring how you reason about it. This playbook has AI build the capacity worksheet: traffic model, bottleneck inventory, scaling units, and the assumptions register — with every number left blank until your load tests and production data fill it.
Tier: Core · Hands-on time: ~25 minutes
The sibling lesson to estimation critique (pb-02) applies: an LLM asked "how many instances do we need?" will produce a confident, groundless answer. Asked instead to build the worksheet a capacity model needs — what drives load, what saturates first, what the scaling unit is, which assumptions are load-bearing — it does structural work models are genuinely good at. The worksheet ships with named blanks; your load-test data and the vendor's documented limits fill them; and the difference between those two sources of numbers is the whole discipline.
Skip AI when a mature capacity model already exists — update its inputs with real data; regenerating structure loses accumulated calibration.
Have AI enumerate the demand drivers. "For orbit-docs-copilot (B2B SaaS documentation copilot, per-tenant corpora), list the demand drivers a capacity model must include: user-driven (queries/user/day, concurrency curves, tenant onboarding bursts), system-driven (embedding pipeline runs, index rebuilds), and AI-specific (tokens per query in and out, retrieval fan-out per query, cache hit rate). For each: unit, what it multiplies with, and where a real value would come from." The AI-specific drivers are where experienced architects new to AI workloads have blind spots — token throughput and context length behave like no traffic dimension they have modeled before.
Build the bottleneck inventory from the diagram.
Here is the component list and edges from our verified architecture
diagram [paste]. For each component, produce a bottleneck worksheet row:
- Saturation dimension: what runs out first (connections, IOPS, TPM
quota, worker pool, queue depth)?
- Scaling unit: what do we add to get more (replica, shard, provisioned
capacity increment)?
- Scaling latency: how long does adding one take (seconds, minutes,
a support ticket)?
- Ceiling: is there a hard documented limit? Write LOOKUP — never a
number from memory.
- Coupling: which other component's scaling does this one force?
Do not estimate any numeric value. Structure only.
Transfer to the spreadsheet and fill the LOOKUPs from vendor docs. Every ceiling cell gets a documented value with URL and date — the capacity model is a claims register with arithmetic on top. The LLM gateway's TPM quota, the database's connection limit, the vector store's per-index ceiling: all from today's docs pages, none from the model, none from memory.
Fill demand numbers from data — and label the ones you guessed. Real numbers from load tests and production metrics go in plainly. Where no data exists, enter your estimate with an ESTIMATE tag and a planned source ("replace after week-2 load test"). The sheet must render the difference visibly — a capacity model that hides which numbers are measured and which are hoped is a pb-05 violation in spreadsheet form.
Model the scenarios in the sheet, not the chat. Baseline, peak, 10x, and the AI-specific nasty case (viral tenant + cold cache + longest-context queries). The spreadsheet computes utilization against each ceiling; the first cell to cross its ceiling in each scenario is your headline. Chat arithmetic is not auditable; sheet formulas are.
Close with an assumptions register and a review date. Ask the model: "Given this worksheet structure, list the assumptions that would most change the conclusions if wrong, ranked by sensitivity." Convert to a register with owners and re-check dates. Capacity models are perishable — tie the review date to the next load test and to quarterly vendor-limit re-verification.
Traffic figures and system topology are commercially sensitive; BFSI and client engagements often restrict both. The structural steps (1–2) work fully redacted — demand drivers and bottleneck taxonomy need component roles, not client names or real volumes. Run them against a client-tenancy endpoint or local Ollama where required; the model never needs your real numbers in any environment, because numbers enter only in the spreadsheet, from docs and measurements. That property makes this playbook one of the safest in the track: the AI touches structure, and structure rarely violates an MSA — but confirm against the pb-03 register before pasting topology.
The model structures the reasoning; the load test and the vendor docs supply the numbers. A capacity model is trustworthy exactly in proportion to how visibly it separates the two.