Raising the Core Rule Set to paranoia level 3 across a shared ingress tier needs replicas finance will not fund - what do you propose?

## The ask is a purchase, so price it properly When a paranoia raise turns into a replica-count request, the argument has left engineering and entered budgeting - and the reason it usually loses is that it is presented as a posture ('we should be at PL3') rather than as a purchase with a unit price and a measurable return. Reframing it is most of the work. There are two prices, and only one of them is on the invoice. **The capacity price.** Higher paranoia means more rules evaluated per request, and the expensive families are regular-expression heavy and run over request bodies. That cost is per inspected request and per byte inspected, so it lands very unevenly: a route serving small JSON bodies at high rate and a route accepting multi-megabyte uploads are not the same customer. This must be measured on your own traffic - a mirrored or replayed sample at each candidate level - because a published figure for someone else's mix will be wrong in either direction. **The refusal price.** Every level costs legitimate requests, and that cost also lands per route, on teams who did not choose the level. It never appears in the capacity request, which is why the capacity request looks like the whole cost and is not. Producing a per-route count of what PL3 would have refused, from a non-enforcing measurement run, is what turns this from an opinion into a line item. ## Why the fleet-wide raise is usually the wrong thing to fund Both prices scale with the traffic you inspect harder. The benefit does not scale the same way, because the routes worth the extra scrutiny are a small minority: the ones handling money, the administrative surfaces, the upload endpoints, anything reachable before authentication. The rest of the estate is paying full price for a marginal band of evasion coverage on routes nobody is targeting. The Core Rule Set's configuration lets the level be set per route, so the shape of the counter-proposal is straightforward: PL3 on the routes that justify it, PL1 or PL2 elsewhere, with the capacity ask reduced to the traffic actually being inspected harder. That proposal usually costs a fraction of the original and is far easier to defend, because each route on the list has a named reason. ## The limit that decides what the money bought One fact belongs in this conversation and is routinely omitted: the engine inspects request bodies only up to a configured limit - `SecRequestBodyLimit` and its no-files variant - and content beyond that limit is not scored at any paranoia level. Raising the limit to inspect more is itself a capacity decision, because it is precisely the expensive part. So the deployment has a stated boundary: an attacker who places the payload beyond the inspected body size is unaffected by whether you bought PL1 or PL4. Saying this out loud is not undermining your own request. It is the difference between selling a control and selling a control whose limits you can state, and it is what stops a future incident being read as the rule set having failed when in fact it was never in the path of the bytes concerned. ## Presenting the choice Give the budget owner two or three priced options rather than one ask and a warning: - PL3 on a named set of routes: the replica delta, and the count of legitimate requests per week the change will refuse on those routes. - PL3 fleet-wide: the full replica delta, and the fleet-wide refusal count with the affected teams named. - No change: what specifically remains uncovered, stated as behaviour rather than as a scare. Attach the refusal number to every option, because it is the cost the owner will otherwise discover from an angry route owner in a fortnight. A decision maker who chooses the cheaper option knowing the refusal count has made a legitimate call; one who chooses it because nobody told them has not. ## The failure to avoid The destructive outcome is the compromise nobody wrote down: take the partial funding, deploy PL3 across the fleet anyway, and absorb the resulting breakage by raising the shared anomaly threshold until the complaints stop. That combination has the configuration of a hardened tier and the behaviour of a weaker one than you started with, because the higher level's extra rules are contributing to totals that now need far more evidence to act on, while every attacker gained the same headroom. If the money is not there for the fleet, the answer is a smaller deployment, not the same deployment with the acting threshold moved. ## What you should not claim A rule set is a compensating control. Whatever level you fund, it is standing in front of application behaviour owned by other teams, and buying a higher level is buying time and coverage, not correctness. Overstating it in the funding conversation is how a platform team ends up owning an application's risk without owning its code.