# Performance Budget Definition Turns what a system must feel like into thresholds a pipeline can enforce — and refuses to supply a number that nobody has agreed to. ## Deliverable One Markdown document, `performance-budget.md`, in the structure set out under **Output** below. It is the standard **Performance Investigation** measures against, and the condition the release pipeline checks. ## Required inputs - **What the system must feel like to its users** — which interactions matter, stated by whoever owns the experience. - **The threshold for each one, from the requester** — the number the interaction must stay under. This skill records thresholds; it does not choose them. - **The conditions the users are in** — the devices, the networks and the data volumes the budget has to hold under. If the thresholds are absent, produce the document with every threshold written `unknown — required from `, and report that the budget cannot be enforced until they are supplied. Never substitute a number of your own. ## Optional inputs - Existing measurements of the interactions in scope, with where and how they were taken - The measurement tooling available, and what it can observe in each environment - The pipeline stages that could enforce a budget, and what they are allowed to block - Contractual or regulatory commitments about responsiveness or availability - The traffic pattern the budget must hold across, including its peaks - Previous budgets, and the reason any of them was changed An absent optional input never softens a budget. Each one becomes an entry under **Open questions**, and any budget whose measurement point is unknown is recorded as unenforceable. ## Execution **1 — List the interactions that have to be fast.** One line per interaction, each of them something a user actually waits for, named from the user's side rather than from the call graph. An interaction nobody waits for does not get a budget. **2 — Attach the supplied threshold to each one.** Record the number as it was given, the unit as it was given, and the person who gave it. Where none was given, write `unknown — required from ` and carry the interaction forward unbudgeted. A threshold invented at this step becomes the system's real target by accident. **3 — Fix the percentile.** State the percentile each threshold is measured at, supplied by the same owner who supplied the threshold. A budget held to an average passes while a share of users sits outside it, and the document can only name that share once the percentile is stated. **4 — Fix the conditions.** Per budget: the device class, the network conditions, the data volume and the cache state under which it must hold. A budget that holds only on the fastest case is recorded as holding only on that case, in the same line as the threshold. **5 — Name the measurement point.** Where the number is read: which environment, which instrument, which event opens the interval and which closes it, and how often it is sampled. A budget with no measurement point is recorded `unenforceable`, because nothing can ever fail it. **6 — Decide what exceeding it does.** Per budget: which pipeline stage checks it, whether a breach warns or blocks, who is notified, and the documented route for shipping past it anyway. A budget that cannot fail anything is a preference with a number attached. **7 — Give each budget an owner and a review point.** The person who answers when the budget is breached and who may change it, and the milestone at which the budget is reconsidered. A budget nobody owns is quietly raised the first time it is inconvenient. ## Output `performance-budget.md`, in this order: - **1. Scope and date** — which system, whose requirements, gathered by whom, and when - **2. Interactions** — one line each: the interaction, who waits for it, and why it matters - **3. Budgets** — per interaction: the metric, the threshold as supplied, the unit, the percentile, and who supplied them - **4. Conditions** — per budget: device class, network, data volume, cache state - **5. Measurement** — per budget: environment, instrument, the events that open and close the interval, sampling frequency - **6. Enforcement** — per budget: the pipeline stage, warn or block, who is notified, the documented route past it - **7. Owners and review** — per budget: the owner, and the point at which it is reconsidered - **8. Unbudgeted interactions** — those carried forward with no threshold, and who must supply one - **9. Open questions** — the question, what it blocks, who can answer it ## Validation The budget is ready when all of these hold: - Every interaction in section 2 appears in section 3 or section 8, and in exactly one of them - Every threshold in section 3 names the person who supplied it - Every budget in section 3 states a unit and a percentile - Every budget has a measurement point in section 5 or is marked `unenforceable` - Every budget names an owner in section 7 - No threshold appears in the document that was not supplied by the requester Fail the run if a threshold, a unit or a percentile appears without the person who supplied it, or if any number in the document originated with this skill. ## Failure handling - **No thresholds supplied** — produce every section, list all interactions in section 8, mark the document `NOT ENFORCEABLE`, and name who must supply the numbers. - **Nothing can be measured in the environment that matters** — record the budget with its measurement point `unknown`, mark it `unenforceable`, and state what instrumentation would make it enforceable. - **The thresholds contradict the stated conditions** — record both, name both sources, and raise the conflict as a decision the owner must make. Do not relax one of them to fit the other. - **The pipeline cannot block** — record the enforcement as `warn only`, name who receives the warning, and state that a warning nobody owns is a budget in name only. - **Partial material** — budget the interactions the material supports, list the rest in section 8, and deliver. A short budget that is enforced is worth more than a complete one that is aspirational.