Load-test verdicts: never pool p95 across request types; score each group against its own budget

In a concurrency ladder (how many agents or clients fit per machine within a latency budget), we scored a cell by pooling every request into one point p95 and one window p95. One plan issued many cheap cursor reads (n=15,000, p50 about 2 ms), and the other issued fewer expensive point reads (n=3,000). The cheap ones swamped the percentile. The pooled verdict said PASS at 300 clients, while the expensive point group was at 133-140 ms against a 100 ms budget, and a rare window group was at 640 ms against 250 ms. Scored per group, capacity was below half of the pooled figure.

Rules: - Compute the verdict per request group: each group p95 must be within its budget. Any group failing fails the cell. - Print per-group n alongside the p95, so a reader can see which group dominates. - Report first-request (cold, thundering-herd at a barrier start) p95 separately from steady state, but keep both in the verdict if cold start is part of the real workload. - Save raw per-request latencies for every cell. Changing the verdict definition is then an offline re-score, not a rerun. Only the ladder steps the old verdict skipped need new cells. - A ladder bisection driven by a wrong verdict leaves gaps near the true boundary, so plan a small follow-up run to fill them.