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 is an engineering problem and it is countable: 61 abstract primitives producing 149 sector variants in our library as of August 2026. The second is human. It gives no signal when it fails, it is where most of the last ten years of customer projects went, and it is 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 is 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 is 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 algorithm is the layer everyone benchmarks and 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 are also the wrong place to look for why a project failed.
The algorithmic problem is hard and it is 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 have 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 have not seen a project fail because the solver was too slow. We have seen plenty fail because the plan described an operation that did not exist.
Between a business rule and a solver sit two more layers
Getting from a rule that exists in an operation to a plan that respects it takes three things. Only one is the algorithm.
The industry benchmarks the third row. 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. An expressivity limit is loud: you look for a way to state your rule, you do not find one, and you know within the hour. A formulation error is silent: you state the rule easily, you state it wrong, and nothing signals it.
A third case sits between the two, and it is the one that misleads. The primitive that carries your rule exists, but it is abstract enough that the mapping is not obvious, so the developer concludes the API cannot do it. That is a translation failure dressed as an expressivity limit. It usually ends in a workaround built outside the model, where the solver cannot see it and cannot optimize against it.
Modeling distance: 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 is a property of the formalism, not of the rule. The same constraint carries a different modeling distance in different tools.
At distance zero, the rule has a native object. A time window in a modern routing API: two fields, nothing to translate.
At 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 and at its own translation cost. 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.
At 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, and the literature has documented for two decades how far these formulations stay from the operations they describe[3][4].
Reducing modeling distance is a product decision. It determines how much work lands on developers.
61 primitives, 149 sector variants: what expressivity costs to build
Reducing modeling distance means turning constraints that would be engineering projects into native constructs. That is a solver problem, and it is the central engineering challenge of any optimization engine whatever its domain or solving technique[5]. Adding expressivity is not the hard part. Adding it without degrading solver performance is, because 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 cannot express the subcontractor floor. Not an oversight on their side, but a trade they made. A formalism that carries many such rules without slowing down says something about the architecture underneath it.
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 have encountered. It is 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 have never seen before are the minority case, and when they do appear, most turn out to be expressible with primitives that already exist. That is also the clearest case of the two layers coming apart: the rule was new, expressing it was easy, and recognizing which primitive carried it was not.
Expressivity is also the one layer an outsider can compare, using nothing but public documentation. We have 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 are not a neutral party in it, which is why the constraint list and the scoring method are published rather than summarized.
A perfect formalism does not make the model correct
There is 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 to 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. None gets easier with a better object.
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 does not 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 do not plan around it. Or inside the vendor.
We built the second. Our solution engineers do this work and they are why our projects converge. They are also a bottleneck hiring does not remove: the profile is rare, and every project consumes one of them from first workshop to production.
Workable for enterprise projects, impossible for a self-serve API.
Which leaves this category with one open question, and it is not an algorithmic one. The expertise that turns an operation into a correct formulation exists, it is written down almost nowhere a machine can read, and today it walks into every project on two legs. Whether it can be encoded, and whether an agent can apply it well enough to stand in, is the subject of the next article: AI agents can call your optimization API. Here is how we got them to model the problem.
Frequently asked questions
No, they are two separate failures. GIGO is about the instance: the addresses, weights and service durations that populate a given run. Bad data ruins a correct model, and no amount of modeling work fixes it. A formulation error is the opposite case, where every number is right and the model describes a different operation from yours. You can have either without the other, and they need different work.
Volume is the wrong axis. A fleet of eight vehicles with certification rules, site access windows and precedence between jobs carries more modeling risk than four hundred vehicles doing uniform residential delivery. The signal is how many rules constrain who can do what, when, and in which order.
It happens regularly and it is usually less of a problem than it sounds. A rule nobody has stated before is rarely a formalism nobody has built before, so most novel constraints turn out to be expressible with existing primitives. The genuinely new ones are the interesting part of this work, and they are the minority.
For low modeling distance constraints, yes, and that covers more ground than most people assume. The difficulty starts where a concrete rule has to be carried by an abstract construct, because choosing between two valid encodings requires knowing what each does to the plan. That knowledge is documentable. It is not currently in any API reference we know of, including ours until recently. See the modeling guides we publish.