In a seller-abuse review queue, what goes wrong when cases are worked in expected-loss order rather than arrival order?

## Two orders, two failure modes A human review queue has to be worked in some order, and the two obvious ones fail in opposite directions. | Ordering | What it optimises | How it fails | |---|---|---| | Arrival order (first in, first out) | Fairness and a predictable wait for every seller | An analyst spends 7.5 minutes on a trivial case while a large pending payout waits behind it | | Expected-loss order | Loss prevented per analyst hour | Cheap cases are outranked by every new arrival and never come up | Expected loss is the sensible default key: roughly the risk score multiplied by **value at risk** — pending payout, open orders, the exposure the platform carries if the account really is abusive. Working that order first means the shift's fixed hours buy the most prevented loss. ## Why pure expected-loss order starves the tail The key is **static with respect to waiting**. A case scored yesterday with a small exposure has the same priority tomorrow, and tomorrow brings a fresh batch of arrivals, some of which outrank it. Because the queue is sized to be worked, not emptied, the bottom of the ranking is never reached. Three things follow: - **An honest seller sits in limbo indefinitely.** Their listing is demoted, their payout held, and no one has decided anything. From the seller's side that is indistinguishable from a silent penalty. - **Time to decision at p95 becomes meaningless.** The median case looks healthy while a long tail ages without bound, which is exactly the shape a mean hides. - **Expiry becomes the real policy.** If nothing defines what happens to an unworked case, the queue's overflow behaviour — usually "it stays as it is" — is emitting the platform's action, and nobody chose it. ## The ageing fix Add a term that makes waiting raise priority, and a hard lane for cases at their deadline: 1. Compute the base key from expected loss. 2. Multiply it by an ageing factor that grows with how far the case has travelled toward its time-to-decision target. 3. Once the target is breached, move the case into a **deadline lane** that preempts the ranked queue and is worked oldest first. The ageing weight is the dial between the two pure orders: at zero you have expected-loss order and starvation; very large, you have arrival order and wasted analyst hours. Tune it by watching p95 time to decision and prevented loss per shift together, since moving it trades one against the other. ## Expiry has to be a decision Every case needs a rule for what fires if it reaches its deadline unworked, and that rule should be an action, not a shrug. The usual choices, in increasing severity: release to normal (accept the loss), keep the limit in place while the case ages further, or apply the automatic action for its score band. Two things make it a real decision rather than an accident: - **Record it as a decision**, with the reason "expired unworked", so the volume of expiries is visible in the same place as analyst verdicts. - **Alarm on the rate.** A rising expiry count is the earliest honest signal that the band is sized above the shift, and it appears days before anyone complains. ## Reserving capacity as a backstop Ageing is a soft guarantee — under a heavy enough spike, even an aged case can be outranked. A harder version reserves a fixed slice of the shift (say one analyst-hour in ten) for strict arrival order, so the oldest cases drain at a floor rate whatever the ranking does. It costs a little prevented loss for a bounded worst-case wait, which is usually the right trade when the queue holds decisions about honest sellers. ## What to measure - Time to decision at p50 and **p95**, per band and per ordering lane. - The age of the oldest open case, watched as a level rather than an average. - Expiries per day, by the action that fired. - Prevented loss per analyst hour, so that tightening the ageing weight shows its cost instead of looking free.