Why can one latency pass rule not judge a long steady hold, a sudden step in arrival rate and a deliberate overload run?

## Three shapes, three questions A pass rule encodes the question a run is asking. Three run shapes ask three different questions, so one rule cannot judge all three, however convenient a shared report format makes that look. | Run shape | What it is asking | What the rule must say | | --- | --- | --- | | Long steady hold | Does behaviour survive time and accumulation? | The bound holds in the closing intervals as strictly as the opening ones | | Abrupt increase in arrival rate | How is a sudden change absorbed? | How far the bound may be exceeded, and by when it must hold again | | Deliberate overload | What happens past the rate it is built for? | Excess work is refused rather than queued forever, and normal service returns | ## The long steady hold Load is applied at a rate the system is meant to sustain and held there for hours. The interesting failure is not the first minute; it is deterioration - memory that is never returned, a cache that grows without bound, a table that gets slower as it fills, a pool that leaks a handle on each error path. So the rule has to be written about the end of the run, not the start: - The bound must hold in the closing intervals, judged exactly as the opening ones are. - The relationship between the opening and closing figures should itself be bounded: the closing figure may not exceed the opening one by more than a stated amount. - The volume of data accumulated by the end belongs in the rule, because a hold that finishes with a small dataset has not exercised what the shape exists to exercise. Reusing this rule for the other two shapes looks harmless and is not, because in both of them a breach is expected and this rule forbids it. ## The abrupt increase in arrival rate Arrival rate jumps sharply - say from one hundred to five hundred per second with no gradual increase. Every real system breaches briefly here: pools grow, caches hold nothing for the new mix, extra capacity arrives late. Judging the run with the steady bound makes it unpassable and, worse, hides the property under test, which is the **transient**. The rule needs three agreed numbers: 1. The **ceiling** response time may reach during the excursion. 2. The **recovery time** within which the steady bound must hold again. 3. The **interval size** the check is read at, since a ninety-second excursion is invisible in five-minute intervals. "Recovers quickly" is not a clause. "Never above three times the steady bound, and back under it within two minutes, read in fifteen-second intervals" is a clause, because two people can apply it to the same result and agree. ## The deliberate overload Load is pushed past the rate the system is built for, on purpose. Latency clauses become unwinnable - the system is being asked to do more than it can, and the honest expectation is not that it stays fast but that it stays **controlled**. The pass rule changes subject: - Work that is accepted is still served within a stated bound. - Work beyond capacity is **refused promptly** rather than queued indefinitely; a fast refusal is a better outcome for a caller than an unbounded wait. - Nothing already accepted is lost or corrupted while the excess is applied. - Once load returns to normal, the system returns under the steady bound within a stated time, with no manual intervention. That final clause catches the most common real failure. A system behaves acceptably during the excess and then never comes back: pools stay exhausted, queues stay full, retries generated during the excess keep arriving, and only a restart clears it. A rule that stops at the moment the load stops never sees any of that. ## Writing three rules without triplicating everything The parts that do not vary - which operation is timed, where timings are taken, how intervals are reported, who may accept a breach - can be written once and shared across the three. What has to be per shape is the **judgement clause**: what this run must show for a pass. A useful habit is to open each shape's rule with the question that shape asks, so no reader has to reconstruct the intent from the numbers alone. The failure this prevents is quiet. A team runs all three shapes diligently, judges them all against the steady bound, and concludes that the system fails under a sudden increase and fails under overload. Both conclusions are consequences of the rule rather than facts about the system: the run with the abrupt increase was behaving exactly as designed, and the overload run was never in scope for that bound at all. The reverse error is just as common - passing an overload run because response time stayed inside the bound, while every request beyond capacity sat in an unbounded queue that nobody measured.