A Global Minimum Is Wrong in Both Directions: Feasibility Rules Belong Per Location

Mostafa Dhouib·8 min read

A Global Minimum Is Wrong in Both Directions: Feasibility Rules Belong Per Location

The short answer. When a system has to decide whether something is physically possible, the first implementation is almost always one threshold applied everywhere. That threshold is wrong twice over. Set high enough to be safe in the hardest conditions, it rejects options that were perfectly fine in the easiest ones. Set at a sensible average, it admits options that cannot work where conditions are hard. Both errors are invisible, because a rejected option leaves no trace and an admitted one fails later at somebody else's expense. The fix is rules per location, and the cases differ in kind rather than in degree: an airside connection with through-checked bags and a landside connection requiring immigration and a bag re-check are different physical acts, not the same act with a different duration.

A product needs to decide whether a connection can be made, whether a delivery window is achievable, whether a schedule is possible. The simplest version is a number: at least this much time, or reject.

It ships quickly and it is hard to argue with, because any number you propose is defensible with a story.

The double error

One threshold, two failure modes, and the two pull in opposite directions so no single value fixes both.

Too strict where conditions are easy. A small airport with one terminal, no immigration between arrival and departure, and bags handled through can be transited in far less time than a large multi-terminal hub. A global minimum set to be safe at the hub rejects entirely workable options at the small airport. Those rejections are completely silent. Nobody sees a result that was never generated, and the product looks like it has thin coverage rather than a conservative rule.

Too loose where conditions are hard. The same threshold at a hub requiring a terminal change, immigration, a baggage claim and a re-check admits connections that cannot be made. Those failures surface later, to a user, with real consequences, and the product gets blamed for the outcome rather than for the rule.

Tuning the number trades one for the other. There is no setting that solves both, because the problem is not the value. It is that the value is a single scalar standing in for conditions that vary by an order of magnitude.

Kind, not degree

The deeper error is treating the harder case as a longer version of the easier one.

Walking between adjacent gates is one action with one duration. Clearing immigration, waiting at a carousel, collecting a bag, re-checking it, passing security again and walking to a different terminal is a sequence of actions, each with its own distribution, several of which have queues whose length depends on time of day and on how many other flights landed in the same window.

Those are different kinds of thing. The first has a tight distribution around a short time. The second has a long tail and is correlated with exactly the conditions that make the whole situation harder.

So a rule that says "allow more time for a landside transfer" is still modelling it as the same act with a bigger number, which means it is wrong in the tail, which is where the failures live.

The rule has to branch on the case first, then apply a threshold appropriate to that case. Airside with through bags. Airside with a terminal change. Landside with immigration. Landside with a bag re-check. Each is its own rule with its own threshold, and the question "which case is this" is answered before any number is consulted.

Rules as data, not code

Once you accept per-location, per-case rules, there are hundreds of them and they change.

An airport reconfigures. A new terminal opens. An immigration arrangement changes. A carrier moves its operation. None of those should be a code change, a deployment and a regression pass, because they happen continuously and each one is a row.

So the rules live in data: location, case, threshold, effective date, source. The engine reads them. Adding a location is a row, and correcting a threshold after a field report is a row.

This also gives you something the hard-coded version cannot have: the ability to say where a rule came from and when it was last confirmed. A rule set that cannot say how old its entries are is a rule set that degrades silently, because a stale threshold still returns an answer.

What to do with the unknown case

A location with no rule is not a location with a default rule.

Applying a global fallback reintroduces the original problem in the one place you have the least information. The honest options are to reject, which costs coverage, or to flag, which costs the user a decision they may not be equipped to make.

For anything where the consequence lands on the user rather than on the business, rejection is usually right. The cases with no rule are disproportionately the unusual ones, and unusual correlates with difficult.

Measuring a rule set

Two numbers, and they move in opposite directions so both are needed.

The false-admit rate. Of the options presented as feasible, how many were not. On the flight product this was 1.9 percent after the rules were in place, down from 12.4 percent. It did not reach zero and it was not expected to.

The rejection rate, with sampling. How many candidates are being rejected, and a periodic check of whether some of them were actually fine. Without this, over-strict rules look like good behaviour forever, because rejections are invisible by construction.

A rule set reported without the second number is reporting only its safe-looking half.

Where else this lands

Delivery windows against depot locations and traffic patterns. Installation scheduling against site access constraints. Manufacturing changeovers against line configurations. Clinical appointment slots against room and equipment availability. Field service routing against access hours.

In all of them the pattern is the same: a scalar threshold that is really a stand-in for conditions, applied uniformly across conditions that differ in kind.

The honest limit

Per-location, per-case rules reduce both errors and eliminate neither. They are rules, derived from published information and field experience, and the world moves. A process change at one location, or a schedule change arriving after the rule was applied, moves an option across the line in a way no rule anticipated.

That is why the false-admit rate is a number rather than zero, and why the rules need maintaining against reality rather than being written once. 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.

FAQ

Why is a single global minimum threshold wrong? Because it is wrong in both directions at once. Set safely for the hardest conditions it silently rejects workable options where conditions are easy, and set at a sensible average it admits options that cannot work where conditions are hard. Tuning trades one error for the other, since the problem is using one scalar for conditions that vary by an order of magnitude.

Why can't I just allow more time for the harder case? Because the harder case is a different kind of act, not a longer one. A sequence involving immigration, a baggage carousel, a re-check and a security queue has a long tail correlated with the same conditions that make the situation hard, so a bigger number is still wrong in the tail, which is where the failures are.

How should feasibility rules be structured? Branch on the case before consulting any number. Determine which situation applies, then apply the threshold belonging to that situation at that location. Store the rules as data with their location, case, threshold, effective date and source, so adding or correcting one is a row rather than a deployment.

What should happen at a location with no rule? Reject rather than fall back to a default, at least where the consequence lands on the user. Locations with no rule are disproportionately the unusual ones, and unusual correlates with difficult, so a global fallback reintroduces the original problem exactly where you have the least information.

How do I know whether my rules are too strict? Sample the rejections and check whether some were actually fine. Rejections are invisible by construction, so without sampling an over-strict rule set looks like good behaviour indefinitely. Report the rejection rate alongside the false-admit rate, because reporting only the latter shows the safe-looking half.

Can a feasibility gate get the false-admit rate to zero? No. On one delivered system it went from 12.4 percent to 1.9 percent, not to zero. The rules are derived from published guidance and field experience, and a process change or a schedule change arriving after the decision moves options across the line. Present it as a maintained rule set with a measured residual rate rather than as a guarantee.