“No seats” is a claim, not a default

Run a search, get an empty page. What actually happened? There are two possibilities, and they could not be more different. Either the program answered and the answer was no — no award seats on that route, that day, in that cabin. Or something between you and the program failed: a timeout, a changed page, a refused request, a parser that no longer understands the response.

Most tools render both as the same empty page. That single design decision is, we think, the largest source of wasted decisions in award travel: people book positioning flights, transfer points, or give up on routes entirely on the strength of an empty screen that actually meant “we could not look”.

An error page that looks like an empty result converts “we failed” into “there is nothing” — silently, at scale.

The rule we build under

Inside this product, an empty answer is only ever called confirmed when the program itself returned an explicit empty result — its own marker, in its own response, saying the search ran and found nothing. Everything else is unknown, and unknown renders as what it is: a failure, with the reason attached, visually distinct from an answer.

This rule is enforced in code, not editorial policy. A parser that cannot read a response raises an error rather than returning an empty list; a partially readable response is forbidden from claiming emptiness, because the unreadable part might have held the seat you asked about. There is a test suite whose only job is proving that no failure path anywhere becomes a zero.

How to tell if your tool does this

• Search a route during an outage or with the airline’s site down. Does the tool say it failed, or does it show serene emptiness?
• Does an empty result name the program that reported it and when?
• Does the tool ever distinguish “no seats” from “we did not look”? If every miss looks identical, some of them are failures in disguise.