Why the hard part of route optimization is the modeling, not the algorithm

Cédric Hervet, Ph.D. — Tue, 15 Sep 2026 13:00:00 +0000

Everyone benchmarks the algorithm. Almost nobody talks about the layer that actually breaks projects: modeling.

Route optimization projects rarely fail on the algorithm. Between a business rule and a routed plan sit two other layers: whether the modeling language can express the rule at all, and whether someone stated it correctly.

The first is modeling distance, the gap between how a rule exists in an operation and how a formalism lets you write it down. It's an engineering problem, and it's countable: 61 abstract primitives producing 149 sector variants in our library as of August 2026. The second is human, and it gives no signal when it fails. It's where most of the last ten years of customer projects went, and it's what still stands between route optimization and a self-serve product.

A delivery time window is a business constraint. In almost every routing API it's also an object: set a start, set an end, done. No modeling effort at all.

A minimum daily revenue below which a subcontractor refuses a route is also a business constraint. It's an object nowhere. It has to be built from whatever the formalism offers, assuming it offers enough, and assuming somebody realized the rule existed.

Both bind the plan equally. The distance between them is the subject of this article, and it has nothing to do with the algorithm.

The layer everyone benchmarks is the one that rarely fails

Solvers get compared on speed, on gap to optimality (how far a solution sits from the mathematical best), on stops absorbed. Those comparisons are legitimate, and we run them on our own engine. They're also the wrong place to look for why a project failed.

The algorithmic problem is hard, and it's well served. Vehicle routing has been studied for sixty years, metaheuristics (general-purpose search algorithms) work, and a competent commercial solver beats experienced planners on distance or vehicle count by a wide margin. We've made that argument ourselves. That success created the blind spot: gains that large made the algorithm look like the whole product.

In ten years we haven't seen a project fail because the solver was too slow. We've seen plenty fail because the plan described an operation that didn't exist.

Three layers sit between a business rule and a solver. Only one is the algorithm.

Getting from a rule that exists in an operation to a plan that respects it takes three things:

Expressivity — Can this rule be stated in the modeling language at all? Engineering problem, inside the solver.
Formulation — Has it been stated correctly, with the right hardness and scope? Human problem, between operations and mathematics.
Search — Given a correct statement, how good a solution, how fast? Algorithmic problem.

The industry benchmarks the third layer. Projects fail in the first two.

The upper layers get collapsed into one, and the time window example shows why: when a formalism has a native object for a rule, expressing it and expressing it correctly happen in the same gesture. They come apart as soon as the rule has no native object.

They also fail differently. When you hit an expressivity limit, you notice fast: you look for a way to state your rule, you don't find one, and you know within the hour. A formulation error hides better. You state the rule easily, you state it wrong, and nothing signals it.

A third case sits between the two, and it's the one that misleads. The primitive that carries your rule exists, but it's abstract enough that the mapping isn't obvious, so the developer concludes the API can't do it. That's a translation failure dressed as an expressivity limit. It usually ends in a workaround built outside the model, where the solver can't see it and can't optimize against it.

Why a time window is free and a subcontractor floor is not

Modeling distance is the gap between how a rule exists in an operation and how the formalism lets you write it down. It's a property of the formalism, not of the rule. The same constraint carries a different modeling distance in different tools.

Zero distance — the rule has a native object. A time window in a modern routing API: two fields, nothing to translate.
Moderate distance — the rule has no native object, but the formalism offers abstract constructs that can carry it. Most real constraints live here, and the subcontractor floor is one of them. No routing API on the market exposes it as an object, ours included, so it has to be assembled from abstract primitives. We tested the rule across eleven APIs. Three could express it, each in its own way. For the other eight, we found no way to state it at all. Possibly one exists and we missed it, which is exactly the third case above.
Maximal distance — the formalism is a general mathematical language and every constraint is an engineering project. Writing a rich vehicle routing problem directly in mixed integer programming is the reference case [5]. Each rule costs days.

Reducing modeling distance is a product decision. It determines how much work lands on developers.

61 primitives, 149 sector variants: what expressivity actually costs to build

Reducing modeling distance means turning constraints that would be engineering projects into native constructs. That's a solver problem, and it's the central engineering challenge of any optimization engine whatever its domain or solving technique [5]. Adding expressivity isn't the hard part; adding it without degrading solver performance is. Every construct you make native is one the engine has to handle efficiently inside the search, which is likely why eight of the eleven APIs we tested can't express the subcontractor floor. Not an oversight on their side, but a trade they made.

As of August 2026, Kardinal's library holds 61 abstract primitives in 11 categories, producing 149 concrete constraints across the 7 sectors we work in. Those are the ones we've encountered. It's an inventory of what ten years of projects surfaced, not a claim about the boundaries of the problem.

The duplication is deliberate: one formalism carries different operational meanings by sector. Maximizing preferential assignment between stops and resources means matching a driver to their home zone in parcel delivery, and matching a junior technician to easy interventions in field service. Same mathematics, different conversation, different ways of getting it wrong.

Which is why a new business rule rarely means a new primitive. Constraints we've never seen before are the minority case, and when they do appear, most turn out to be expressible with primitives that already exist.

Expressivity is also the one layer an outsider can compare, using nothing but public documentation. We've been publishing that comparison since 2024, and we know of no equivalent from anyone else. Our 2026 benchmark of eleven routing APIs tests them against a constraint list we rebuilt from scratch. We're not a neutral party in it, which is why the constraint list and the scoring method are published rather than summarized.

A perfect formalism still doesn't make the model correct

There's a tempting conclusion here: keep pushing expressivity and the modeling problem disappears. Give every rule a native object and nothing is left to translate.

The time window shows why not. The object is native, the modeling distance is zero, and these questions are all still open. Is the window hard or penalized? Does it apply to arrival or end of service? Is a five-minute overrun a failure or a degradation? Does it hold when the customer is absent? Each answer changes the plan, and none of them gets easier just because the object is well-defined.

Expressivity lowers the cost of translation. It rarely lowers the cost of specification.

Operations research named this failure long before routing software existed: the Type III error Kimball described in 1957, giving the right answer to the wrong problem [1]. How a problem gets framed in the first place is among the strongest determinants of the solution you end up with [2].

Our subcontractor case is exactly that. A shipper pays an internal fleet per kilometer and subcontractors per task. Optimize that cost model and the solver rationally hands dense routes to the internal fleet and thin ones to subcontractors. The plan is optimal and unrunnable, because a subcontractor still pays for a full driver shift and declines anything below a certain daily revenue. That floor was written down nowhere. Planners had applied it for years without ever stating it. No amount of expressivity would have helped, because nobody had asked the question.

Who can actually do this, and why it doesn't scale

Formulation requires holding two things at once: how the operation actually runs, and what the formalism will do with a given statement of it. The same need can be modeled several ways with different side effects, and knowing which one produces which behavior is the entire skill.

That person sits in one of two places. Inside the customer, an operations profile with an unusually analytical turn of mind, rare enough that we don't plan around it. Or inside the vendor.

We built the second. Our solution engineers do this work and they're why our projects converge. They're also a bottleneck hiring doesn't remove: the profile is rare, and every project consumes one of them from first workshop to production. That's workable for enterprise projects. It's impossible for a self-serve API.

Which leaves this category with one open question, and it's not an algorithmic one. The expertise that turns an operation into a correct formulation exists, but it's written down almost nowhere a machine can read. Today it only exists inside the people who do this work project after project.

Curious how others here have dealt with this. If you've built domain expertise into a system, an agent, a rules engine, whatever, how did you get that tacit knowledge out of someone's head and into something a machine could actually use? Did it work, or did you hit the same wall we did?

Sources

Kimball, A. W., Errors of the Third Kind in Statistical Consulting, Journal of the American Statistical Association, 52(278), 1957, pp. 133–142.
Mitroff, I. I. and Featheringham, T. R., On Systemic Problem Solving and the Error of the Third Kind, Behavioral Science, 19(6), 1974, pp. 383–393.
Caceres-Cruz, J. et al., Rich Vehicle Routing Problem: Survey, ACM Computing Surveys, 47(2), 2014.
Drexl, M., Rich Vehicle Routing in Theory and Practice, Technical Report LM-2011-04, Johannes Gutenberg University Mainz, 2011.
A Review of Approaches to Modeling Applied Vehicle Routing Problems, arXiv:2105.10950, 2021.

DEV Community: Cédric Hervet, Ph.D.