The Cheapest Option That Does Not Work: Gate on the Physical Constraint Before You Rank on Price

Mostafa Dhouib·8 min read

The Cheapest Option That Does Not Work: Gate on the Physical Constraint Before You Rank on Price

The short answer. If your product ranks options by a number, and some options carry a risk the user cannot evaluate, then your ranking is actively sorting the traps to the top. A warning does not fix this, because the price is what the eye lands on and the warning is not. Treat every option as a candidate rather than a result until it has proved it is executable, gate on the physical constraint before ranking, and drop what fails instead of annotating it. On a self-transfer flight product, that gate caught 76 percent of the combinations that could not actually be made, cut false-viable connections from 12.4 percent to 1.9, and took the share of searches returning the cheapest genuinely valid result from 81 percent to 95.8.

Here is a problem that looks like a user-interface question and is not.

You have a product that finds cheap options. Some of those options are cheap because they carry a risk. In the case I will use, it is self-transfer flights: two separately booked tickets through an intermediate airport. The sum is often much cheaper than a nonstop. It is also, sometimes, not physically possible, because the connection is forty minutes, landside, with a bag to collect and re-check.

On separate tickets there is no protection. Miss the second leg and the traveller carries the whole loss.

So what do you do with a combination that is cheapest and might not work?

Why the warning does not work

The obvious answer is to show it and warn. Rank by price, put a caution on the tight ones, let the user decide. It preserves the best price, it is honest in a literal sense, and it transfers the risk to someone who accepted it.

It fails for a reason that has nothing to do with whether the warning is well written.

Your ranking has sorted by price. The riskiest options are systematically the cheapest ones, because the risk is what makes them cheap. So the top of your list is not a random sample of your inventory, it is specifically enriched for traps. And the top of the list is exactly where user trust is highest, because that is what being first in a sorted list means.

You have built a system that puts the most dangerous option in the position of maximum credibility and then printed a disclaimer under it.

There is a second problem. The user cannot evaluate the warning. "Short connection" means nothing without knowing the airport's terminal layout, whether the transfer is airside, whether immigration is involved, and whether bags are through-checked. You are asking for a judgement the user has no basis to make, and the thing you have given them to make it with is a price.

Candidate, not result

The reframe is small and it changes the architecture.

Every combination the system generates is a candidate, not a result. It becomes a result only when it has passed a gate that proves it is executable. The gate runs before ranking, not after, and anything that fails is dropped rather than annotated.

That ordering is the whole thing. Gate, then rank. If you rank then gate, you have already built the list that sorts traps to the top, and everything after that is mitigation.

On the flight product the gate was layered:

A buffer check per airport, because an hour means different things in different terminals and a global minimum is a guess that is wrong in both directions.

A bag and immigration check, because an airside connection with through-checked bags is a physically different act from one that requires clearing immigration, collecting a bag and checking in again. The second gets a longer buffer, and fails if it cannot clear it.

Only survivors were ranked, and ranked on true cost, so the cheapest thing on the page was the cheapest thing that actually worked.

Reject silently

The instinct is to show the user what was filtered, for transparency. Resist it.

A rejected option displayed with an explanation is still displayed, and the price is still visible, and you have reintroduced exactly the failure you removed. The transparency you want is in your telemetry, where you can see the filter rate and watch it for drift. It is not on the results page.

On the flight product the gate caught 76 percent of the combinations that could not actually be made. None of those reached a user. That sounds like a product that shows less, and it is, but what it stopped showing was the part that did not work.

What the numbers mean

Three figures are worth separating because they measure different things.

False-viable connections fell from 12.4 percent to 1.9 percent. This is the direct safety number: of the connections the product presented as makeable, how many were not. It did not reach zero, and it will not.

Invalid combinations caught: 76 percent. Of the combinations that could not actually be made, this is the share the gate removed before anything was ranked. It measures how much of the problem the rules reach. It is not a hundred, and the rules are maintained precisely because the remainder is real.

Cheapest valid result returned: 95.8 percent, up from 81. This is the one that shows the gate did not cost the product its reason to exist. A filter that removed risk by also removing the cheap options would be useless. Instead the share of searches that surfaced the genuinely cheapest workable itinerary went up, because the ranking was no longer being won by options that did not work.

That third number is the one to insist on when someone argues that gating makes the product worse. Gating made it better at its actual job.

The honest limit

The buffers are rules, derived from published guidance, and rules go stale. An airport changes a transfer process. An airline moves a schedule after the search ran. Both move a combination across the line in a way no rule anticipated.

This is why 1.9 percent is the number and not zero, and why the rules need maintaining against corridor reality rather than being written once. A gate that is not maintained degrades silently, because a stale rule still returns an answer.

Say that out loud in the product and in the proposal. A gate presented as a guarantee is a worse artefact than a gate presented as a maintained rule set with a measured residual error rate.

Where else this shape shows up

The pattern is: an option is attractive on the dimension you sort by, carries a risk on a dimension the user cannot assess, and the risk is what makes it attractive.

That describes a cheap supplier with no capacity to deliver, a fast shipping option that does not serve the destination, a low quote that excludes the thing the job actually needs, a lender's headline rate the applicant will not qualify for, a route a vehicle cannot physically take.

In every one of them the same three moves apply. Treat it as a candidate until it proves executable. Gate on the physical or contractual constraint before ranking, never after. Drop what fails rather than warning about it, and keep the rejection rate in your telemetry where it belongs.

FAQ

Why is warning the user about a risky option not enough? Because you sorted by price and the risk is what made the option cheap, so your ranking systematically puts the riskiest options at the top, which is where trust is highest. A warning competes with a price for attention and loses. The user also usually lacks the domain knowledge to evaluate the warning, so you are asking for a judgement they have no basis to make.

What does it mean to treat an option as a candidate rather than a result? It means the option is not eligible to be shown until it has passed a gate proving it is executable, and the gate runs before ranking rather than after. If you rank first and filter afterwards, you have already built the list that sorts traps to the top and everything you do next is mitigation.

Should I show users the options that were filtered out? No. A rejected option shown with an explanation is still shown, with its price still visible, which reintroduces the problem you removed. The transparency belongs in your telemetry, where you can watch the filter rate for drift, not on the results page.

Doesn't filtering most of the options make the product worse? It made it measurably better at its job. The gate caught 76 percent of the combinations that could not actually be made, and the share of searches returning the cheapest genuinely valid result rose from 81 percent to 95.8, because the ranking was no longer being won by options that did not work. A filter that removed the cheap options along with the risk would be useless, and this one did not.

Can a viability gate get the false-positive rate to zero? No. On the delivered system false-viable connections fell from 12.4 percent to 1.9, not to zero. The gate is a maintained rule set, and rules go stale when an airport changes a process or a schedule moves after the search. Present it as a maintained rule set with a measured residual rate rather than as a guarantee.

What kinds of products have this problem? Any product that ranks by a number where some options carry a risk on a dimension the user cannot assess, and the risk is what makes them rank well. Cheap suppliers without delivery capacity, fast shipping that does not serve the destination, quotes that exclude the necessary scope, headline lending rates the applicant will not qualify for, routes a vehicle cannot physically take.