Who should be allowed to approve expanding a live cluster under traffic, and on what stated evidence should they refuse?

## Why this needs a standing rule at all Adding capacity feels benign. Nothing is being deleted, nobody is being downgraded, and the request usually arrives with good intentions and a spreadsheet. That is exactly why it slips through with less scrutiny than a version change, and why organisations end up with clusters that grew on a Tuesday afternoon because somebody felt uneasy about a graph. A standing rule costs one page and removes the argument from the moment, which is the only moment at which it cannot be had calmly. It also protects the requester: a refusal against a written gate is a refusal they can answer, rather than a matter of who was in the room. ## The three gates | Gate | Evidence that satisfies it | What its absence looks like | | --- | --- | --- | | A dated risk of waiting | What runs out, on what date, and what happens on that date | "Headroom feels low" with no date and no consequence | | A schedule for the benefit | When the added capacity begins carrying work, and what that depends on | A machine count presented as if it were relief | | An answer for the partial state | What is true if the work is interrupted, and who may call a stop | A start time and an estimate, and nothing else | The second gate is the one most often missed, and it is the one that changes the size of the decision. Where consumers compete for work on a shared queue, capacity that becomes reachable is capacity in use, and the request is as small as it looks. Where a stream is split into owned parts, a joined member earns nothing until parts are assigned to it — so the request is really asking for that assignment, and it must be reviewed as the longer, heavier thing it is rather than as the join. ## Who holds the pen Two signatures, for two different consequences. - **The cluster's operating owner** answers for the thing being changed: whether the work can be performed safely now, who will watch it, and who may stop it. - **The owner of the affected workloads** answers for the consequence: whether a degraded or partly redistributed cluster is acceptable during the work, and on whose behalf that is being agreed. Three tempting shortcuts are all wrong for the same reason — the person signing does not carry the consequence: 1. **The requesting team alone.** They own the deadline, not the cluster. Self-approval on capacity is how an estate grows without anybody able to say why. 2. **The on-call engineer, mid-incident.** Pressure work under traffic is exactly what an on-call rotation should not be authorised to invent alone. Emergency authority should exist, but it should be explicit, narrow, and reviewed the next morning. 3. **Whoever happens to hold administrative access.** Access is a capability, not a mandate. The two must be separated deliberately, because they drift together by default. ## What a refusal sounds like A good refusal is specific and short. It names the missing gate, not a mood. "There is no date on the risk of waiting, so there is nothing to weigh the work against — come back with what runs out and when." Or: "the relief you need arrives only after parts are assigned, which is a different and longer piece of work; ask for that, with its duration." Or: "there is no answer for what stands if this is interrupted, so nobody can say what they are accepting." None of these is a judgement about competence, and all of them can be satisfied within a day, which is why the rule makes people faster rather than slower once they know it. ## Deferral is a decision, and it is costed The standing rule has to make deferral a first-class outcome, or approvers will approve in order to avoid looking obstructive. - Name the cost of waiting in the same terms as the risk: what is more likely, by when, and how bad. - Attach a review date, so that deferral is not a way of never deciding. - Have the cost **accepted by someone who can carry it** — usually the workload owner, sometimes a level above. An accepted risk has an owner; an unspoken one has a victim. - Record it where the next person will find it. The most common failure is not a bad deferral but an invisible one, rediscovered three months later by whoever is on call when the date arrives. ## The estate view At the scale of an estate, the interesting question stops being any one cluster. It becomes: how many of these decisions should be reaching a human at all? Capacity requests that arrive without dated risks are a sign that nothing is forecasting; expansions whose benefit needs an assignment nobody scheduled are a sign that the request template asks the wrong question. Both are fixable in the template rather than in the meeting — which is the principal-level version of this answer, and the one that scales past the first dozen clusters.