A seller's traffic pushes 12% of ranking responses onto the default ordering while uptime stays green. Which property broke?

## The trap in the question Everything in the scenario that is easy to measure — uptime, latency, error rate — is measuring the *host*, and none of it is measuring the *model*. The one number that speaks to the model, the share of responses served by the fallback ordering, is uninterpretable until somebody has written down what share is tolerable. So the honest first answer is not "availability" but "against what tolerance, and who benefits". ## Availability, for an ML system, needs a written floor A ranking service with a plain-list fallback is *designed* to degrade rather than fail. That is good engineering and it is exactly why the usual signals go quiet: the process answers every request, inside its latency budget, with a valid response. The property that is actually at stake is "the served response was produced by the model", and it is a rate, not a binary. That makes the security goal a threshold somebody owns: *at least X% of responses are model-ranked, measured over Y*. Without X written down in advance, 88% is a number with no verdict attached, and the conversation collapses into opinion. With it, the adjudication is mechanical — and note that the three goals each get their *own* tolerance. The share of served responses the operator will accept losing is a different number, set by different people, from the share of orderings it will accept being wrong. ## The second reading, which the availability alarm cannot see Degrading a model is not always the point of degrading a model. A fallback ordering is a *different function*, usually a simpler and more predictable one — recency, price, or a plain relevance score. Anyone who can see both orderings can work out which one favours them. If a seller's listings sit at the bottom of the model's ordering and near the top of the fallback, then pushing traffic onto the fallback is not an attack on availability that happens to help them; it is an attack on the *ordering*, with degradation as the delivery mechanism. The two readings differ in almost every way that matters downstream: | | Availability reading | Integrity reading | |---|---|---| | What was bought | the model's output was absent | a specific ordering was served | | Measured as | share of responses not model-ranked | rank of chosen listings, on affected requests | | Stops when | the fallback rate returns under the floor | the beneficiary stops gaining, whatever the rate | | Owner | the serving/platform team | the marketplace-integrity team | | Wrong fix | capacity, so the model absorbs the traffic | rate limits, which leave the incentive intact | The "wrong fix" row is the practical reason this adjudication is not academic. Reading an integrity attack as an availability incident leads a competent platform team to add capacity, which makes the fallback rate go away and leaves the adversary's incentive completely intact. They come back with a cheaper way to trip the same fallback. ## How to decide, in order 1. **Get the floor.** Ask the operator for the written tolerance on model-served responses. If it does not exist, that absence is itself the first finding, and the engagement should produce the number rather than argue about the incident. 2. **Compare, and say so plainly.** 88% against a 97% floor is a breach of a stated goal; 88% against no goal is an observation. 3. **Split the traffic by beneficiary.** Look at where the suspected beneficiary's listings land under each ordering, on the affected requests only. A large, consistent gap in their favour is what turns this into an integrity finding. 4. **Check the aggregate.** If overall ranking quality metrics are flat, do not read that as "nothing happened". An adversary pursuing a chosen ordering has every reason to leave the aggregate alone — it is the number being watched. Aggregate stability proves the adversary preserved it, not that the outputs were correct. 5. **Write one verdict, and name the other reading.** Commit to the property you can evidence, and record explicitly what the other reading would require to confirm, so the second owner can pick it up. ## The claim you must not make "Uptime was 99.98%, so availability held" is the sentence to strike. Process liveness was never a measurement of whether the model served. In the same spirit, "the fallback ordering is a valid response, so nothing is wrong" confuses a designed behaviour with an acceptable rate of that behaviour; the fallback exists precisely because losing the model sometimes is survivable, and the whole question is how much of the time.