PAN Lab example
UPS delivery route optimization
A hundred million miles saved and the discretion it cost
UPS's ORION system sets each driver's delivery route, saving miles and fuel. Vehicle data show whether drivers follow it, so the saving comes with monitoring.
See more
ORION, short for On-Road Integrated Optimization and Navigation, is UPS's in-house route-optimization system. It computes the order and path of each driver's deliveries to cut distance and fuel, for about 55,000 drivers in the United States. The computed route is given to the driver as the route to run.
How it is used
ORION produces each driver's delivery route for the day. The case file says the route is dictated to the driver. The vehicle's telematics, its own sensor and location data, show whether the driver followed it.
The case file says the telematics show where the truck went, in what order, how long each stop took, and whether the driver followed the sequence.
The sources record that UPS added what they call dynamic re-optimization around 2021. They do not describe it.
What it saved
The case file reports savings on the order of 100 million miles and about 10 million gallons of fuel a year. It treats the benefit as real and measured, not a vendor claim.
The method and results were published in 2017 in Interfaces, a peer-reviewed operations-research journal. Operations research applies mathematics to planning problems such as routing. The paper reports more than $320 million saved by the end of 2015.
It projects $300 million to $400 million a year at full deployment, and about 100,000 metric tons less carbon dioxide a year. The work won the 2016 Franz Edelman Award.
Routes that could be run
Early versions of ORION produced routes that could not actually be run. Business customers needed routine consistency the optimizer disregarded.
UPS nearly cancelled the project in 2007, because, in the sources' words, the optimizer's output "couldn't be implemented". The routes had to become ones drivers could run, and UPS had to win drivers' acceptance. The sources credit the drivers' corrections from the field, and the customers' need for routine consistency, with shaping the optimizer.
What it costs the driver
The case file finds that the saving is captured only by dictating the route and monitoring whether it was followed. So the same system that saves the miles removes the driver's discretion over how to run the day.
The judgment it replaces includes which streets to take in bad weather, and which order makes sense for a customer the driver knows. It includes when a shortcut the system cannot see is the better call.
The case file's sources include Levy's book Data Driven, on workplace surveillance in trucking. That research documents that the same telematics that optimize the work also discipline the worker. The book studies truck drivers. The sources do not say it studied UPS.
What the efficiency figures cannot see
The case file reads the efficiency as real and the cost as real, borne by the driver. Miles and fuel are on the operations dashboard. The driver's lost autonomy and the burden of being monitored are not.
The case file names two checks that would show that cost. One asks whether the best route on paper is one a real driver can reasonably run on a real day. The other asks whether the monitoring that enforces the route is proportionate, bounded, and accountable. The sources describe neither one at UPS.
None of this makes the optimization a bad deployment, the case file says. It makes it a two-sided one.
What the available tools can and cannot address
A failure pathway is a link between two parts of the network where a mistake made by one part can be passed on to the other. A tool closes a pathway when mistakes stop passing along it. The work along it goes on.
This case has a budget of 10 units. Every tool costs the same at every target level. Contained means the network's mistakes are corrected rather than building on each other.
Explore (No Targets) sets no targets. There, two tools costing 5 of the 10 units keep the mistakes contained. One pair is Gate record entries with Escalate checks. The other is Assign a challenger at its stronger setting with Escalate checks.
Under Service Targets Only, the targets can be met. That level asks for the mistakes to be contained, and for ORION to be helping the work. The same two pairs are the cheapest ways, at 5 units.
The Lab starts with its Dynamics setting at Both, where side-effects and lingering effects are both on. At that setting, 250 different combinations of tools and settings meet these targets within the budget. They use 79 different sets of tools. At that setting, every way that costs 6 units or less includes Escalate checks. It stops mistakes in the route passing along to the driver.
With Dynamics at Off, two more pairs also meet them at 5 units. They are Peer sharing rules at its stronger setting, or Store less data, each with Escalate checks.
Under Service and Safety Targets and All Governance Targets, the targets are not fully addressable with the available tools. Both levels ask you to close every failure pathway, among other targets. Every combination within the budget was checked, and none meets them.
Money is not what stands in the way. With every tool at its stronger setting, four failure pathways stay open. They are Driver corrections to ORION, Records used for the next routes, Route read from the record, and Vehicle data used in routing.
No tool offered here acts on any of them. They are how the deployment works: drivers read and run the route, and ORION uses the vehicle data and the records in routing. That is a finding about the deployment, not a gap in your approach.
That combination also costs service. With every tool at its stronger setting, the mistakes are contained, but ORION is no longer helping the work enough to meet the service target.
Open this example in PAN Lab v0.1 to apply pressures and levers and watch what the system does.
What this models
This example runs on the Route-optimization-class that is also worker surveillance network: 6 components and 11 pathways between them. Every context in the Lab is a stylized model, never a reconstruction of any actual deployment, and each assumption behind it carries a provenance label.
Evidence base: 3 assumed · 2 published baseline. In the Lab, the shaded evidence band behind each headline readout draws its width from the least-established class below.
Show all 5 assumptions
- assumed
This example draws two parts of the deployment as their own elements. The vehicle telematics are a source of data in their own right. The same data help compute routes and show whether drivers followed them. So, in this example, nobody has to decide to monitor drivers for the monitoring to happen. The routine-consistency rules are the second part. The sources say UPS nearly cancelled ORION in 2007, because its routes could not be run. This example assumes a heavy workload for a national fleet, against limited capacity to plan the routes by hand. Drivers did end up with routes they could run, which the sources give as the reason ORION worked.
- baseline
This example follows the pattern of optimization and monitoring documented in the Lab's case file. It is not a reconstruction of ORION itself. ORION was reported to save about 100 million miles and 10 million gallons of fuel a year. Those figures are the peer-reviewed operations-research result, entered as reported. The case file finds that ORION is also a tool for monitoring workers. The saving is captured only by dictating the route and using the vehicle's telematics, its sensor and location data, to check that it was followed.
- assumed
This example draws the optimization and the monitoring as one system, shown as ORION's link to itself. The saving needs the route enforced, and enforcing it needs the driver monitored. So the output that saves the miles also removes the driver's discretion and requires the monitoring. The driver is the person ORION directs, and the person who bears its cost. Two pathways are marked as carrying personal data: the driver's movements written to the record, and the record's use for the next routes.
- baseline
This example draws two checks the case file says would show the cost to the driver. The first asks whether ORION's best route is one a real driver can reasonably run, so that an unworkable route is caught, not imposed. The second asks whether the monitoring that enforces the route is governed as a cost, or treated as a free byproduct of routing. The efficiency figures measure neither. Miles and fuel are on the dashboard. The driver's autonomy and the monitoring are not.
- assumed
This example does not show what happens to drivers. It shows how mistakes move among ORION, the drivers, and the records. The miles and fuel saved, the monitoring, and the lost autonomy come from the case file. The savings are the peer-reviewed operations-research result, and the cost to drivers is a research finding. None of them is computed from anything in this network.
What this example does not show
Show all 2 limitations
- This example does not show what happens to drivers. It draws the driver as the person ORION directs. The miles and fuel saved, the monitoring, and the cost to drivers' autonomy come from the case file. None of them is computed on this network.
- This example computes no harm. The figures of about 100 million miles and 10 million gallons a year are the peer-reviewed operations-research result, entered as reported. The cost of the monitoring and of lost autonomy is a research finding. The route feasibility check and the proportionality review are drawn as two checks, not as a measured harm.
Sources and evidence
What this example rests on, claim by claim. Every entry resolves to the same ledger the Evidence Registry publishes.
A parcel carrier's route-optimization system is a documented operations-research success: it re-optimizes delivery routes across the fleet and was reported to save on the order of 100 million miles and about 10 million gallons of fuel a year, a genuine and peer-reviewed efficiency gain. The same system that computes the efficient route also dictates it to the driver and monitors adherence through vehicle telematics, so the efficiency is enforced through workplace surveillance — the optimization and the monitoring are one system, and the driver's discretion over how to run the route is what it replaces. The benefit is real and measured in miles and fuel; the cost is the driver autonomy the enforcement removes and the surveillance the enforcement requires.
empirical- Academic Holland, C., Levis, J., Nuggehalli, R., Santilli, B., & Winters, J. (2017). UPS Optimizes Delivery Routes. Interfaces, 47(1), 8-23. https://doi.org/10.1287/inte.2016.0875
- Academic Levy, K. (2023). Data Driven: Truckers, Technology, and the New Workplace Surveillance. Princeton University Press. https://press.princeton.edu/books/hardcover/9780691175300/data-driven
The lesson the case carries is that an optimization which manages the worker executing it couples the efficiency gain to a cost the efficiency metric does not see: the worker's autonomy, and the surveillance required to enforce the plan. The system measures miles and fuel, not whether the pace it sets is feasible for a person or whether the monitoring it requires is proportionate — so the governable surfaces are whether the optimization internalizes the human executing it, meaning a route that is feasible and humane rather than merely optimal on paper, and whether the surveillance that enforces it is governed rather than treated as a free byproduct of routing. An optimization is a success on its own terms and can still externalize a cost onto the worker that never appears in the miles-and-fuel number it reports.
empirical- Academic Levy, K. (2023). Data Driven: Truckers, Technology, and the New Workplace Surveillance. Princeton University Press. https://press.princeton.edu/books/hardcover/9780691175300/data-driven
- Academic Holland, C., Levis, J., Nuggehalli, R., Santilli, B., & Winters, J. (2017). UPS Optimizes Delivery Routes. Interfaces, 47(1), 8-23. https://doi.org/10.1287/inte.2016.0875
Where this connects
Institutional pressures in this domain
- Austerity & recovery incentives — Cost-cutting and overpayment-recovery targets tilt the system toward denial and enforcement errors.
- Reviewer bottleneck — One fixed-capacity checking stage sits between AI output and consequence; everything queues behind it.
- Data & policy drift — The world, the intake process, and the rules change under a system trained on how things used to be — two mechanisms with different remedies: the statistical properties of what the system processes move (concept drift), or the mixture of inputs arriving in deployment differs from the mixture it was trained on (covariate shift).
- Vendor opacity — The deploying institution cannot inspect the model, data, or update pipeline it is accountable for.
- Compliance over substance — Paper controls (sign-offs, checklists) satisfy audits while the behavior they describe erodes.
All of them in context on the Logistics dispatch & scheduling AI domain page.
Levers available here and the patterns behind them
- Store less data — Data minimization
- Gate record entries — Human-in-the-loop write gating
- Keep skills sharp — Deskilling-arrest mandate
- Peer sharing rules — Peer-edge governance
- Review on schedule — Oversight cadence & retrospectives
- Assign a challenger — Structured dissent
- Check copied records — Reconcile copied records
- Escalate checks — State-feedback vigilance
- Upgrade model — Improve the model