Earl’s List Is the Objective Function
The first article in the Earl's List series on transport optimisation: objective functions, weighted trade-offs, and deciding what the system should improve.
12 min read →Article
Before a route can exist, something has to decide which orders belong together, and that clustering decision constrains everything downstream.
By Richard Faint · 12 June 2026 · 11 min read
Order clustering decides which deliveries belong together before the routing algorithm draws a route. Geography, time windows, vehicle capacity and driver skills all shape that decision, so a poor grouping can limit every optimisation step that follows.
The title is a sitcom joke. The subject is order clustering, the stage where a transport optimiser decides which orders belong together before it routes any of them.
Earl’s List and the Problem of Grouping Orders Discussions about transport optimisation usually start in the wrong place because they start with the route. We picture a depot in the middle of a map, a collection of orders scattered around it, and an algorithm drawing a set of elegant lines that tell each vehicle where to go.
In reality, optimisation begins much earlier. Before the system can decide which road a vehicle should take, it must answer a more fundamental and surprisingly difficult question: which orders belong together?
Belonging means that two orders share enough operational structure that treating them together reduces complexity rather than increasing it.
This is where Earl Hickey becomes useful. After winning the lottery and discovering karma, Earl writes a list containing every bad thing he can remember doing and every person he believes he has wronged, then spends the series attempting to make amends one item at a time.
Earl initially treats the list as though it is a simple sequence of independent tasks. He assumes he can choose an item, put it right, cross it off and then move on to the next one, but the world around Camden County is rarely that cooperative.
One apology reveals another problem, one stolen possession turns out to have affected several people, and one attempt to repair a friendship brings back consequences from something Earl did years earlier. The challenge is not merely completing the list because Earl must first understand its structure.
Transport optimisers face much the same problem. A collection of orders may look like a list, but underneath it sits a network of locations, capacities, time windows, vehicle requirements, customer promises, trailer movements, driver skills and operational dependencies.
Before the route exists, the optimiser must decide what belongs together. The quality of that decision will influence almost everything that follows.
Imagine that a planner receives one hundred delivery orders at the start of the day. A completely naïve optimiser could attempt to examine every possible combination and every possible sequence, but the number of alternatives grows so quickly that exhaustive searching soon becomes impractical.
Even five stops can be arranged in 120 different sequences. Ten stops can be arranged in more than three and a half million sequences, and that is before we add vehicle capacities, time windows, driver hours, collection dependencies, site restrictions and the possibility of using several vehicles.
The optimiser therefore needs a shortcut — or what Randy might call a cheat mode. The more respectable mathematical term is a heuristic, which means using a structured method to find a good answer without attempting to examine every answer that could possibly exist.
Grouping is one of the most important of those shortcuts. Rather than immediately trying to solve one enormous routing problem, the optimiser first reduces the search space by identifying smaller sets of orders that appear likely to work together.
Earl would recognise the logic. If five items on his list involve people who live near the Crab Shack, Randy would probably suggest dealing with them on the same day, although his reasoning might involve free appetisers rather than computational efficiency.
Joy would insist that anything involving her should take priority regardless of what the model says. Catalina might notice that several items involve the same people or the same workplace, while Darnell would quietly identify a connection that everyone else had missed.
Those different viewpoints resemble the information a transport optimiser must combine. Geography matters, but so do shared customers, compatible vehicles, delivery times, legal restrictions, commercial priorities and relationships between one movement and the next.
The system is not simply looking for nearby dots on a map. It is trying to discover meaningful operational structure.
Before grouping orders by geography or similarity, the optimiser usually needs to remove combinations that cannot work at all. Some characteristics represent preferences, while others represent absolute constraints.
Two deliveries might be close together, but that does not mean they belong on the same vehicle. One may require a refrigerated trailer while the other requires specialist lifting equipment. One site may refuse articulated vehicles while another order may need a driver with a particular qualification.
Time creates another boundary. Two customers may sit on neighbouring streets, but if one must be delivered at eight in the morning and the other cannot accept the vehicle until late afternoon, geographical proximity alone does not make them a sensible pair.
Capacity matters in the same way. Twenty‑six pallets travelling in the same direction may form an attractive geographical group, but they cannot become one load if the available vehicle can carry only fourteen.
A sensible optimisation process therefore begins by identifying incompatible combinations. Only after those combinations have been removed should the system attempt to find the strongest patterns among the remaining feasible orders.
Earl also learns this lesson. He cannot resolve every item whenever he chooses because some people are unavailable, some situations depend on another item being completed first, and some attempts to help are immediately blocked by Joy, the police, a lack of money or Randy misunderstanding the plan.
These are not weak preferences. They are constraints that define what is possible.
Once impossible combinations have been removed, geography is often the most obvious place to begin. Experienced planners frequently group orders by postcode, town, region or familiar delivery area because customers that are physically close are more likely to form an efficient load.
If Earl needs to apologise to three people who all live in the same trailer park, it probably makes sense to visit them during the same trip.
Many transport systems begin with a similar assumption. Nearby orders are treated as potential partners because grouping them may reduce mileage, travelling time and duplicated movement across the network.
Geography is useful, but it is not neutral. The way distance is measured, the number of groups requested and the shape of the road network can all change the result.
One of the best known methods of geographical grouping is K‑Means clustering. The algorithm begins by selecting a predetermined number of groups, represented by the value k, and placing a centre point inside each group.
Every order is then assigned to the nearest centre. Once all orders have been assigned, the centre of each group is recalculated using the average position of the orders inside it.
The process repeats until the assignments stop changing significantly.
μ = (1/n) × Σ x_i
Earl always skipped maths, but the idea is straightforward: the algorithm repeatedly moves the centre of each group and asks which orders now appear to belong around it.
This is simply the mathematical formula for finding a regular average (the mean), applied to map coordinates.
Imagine telling four delivery drivers to meet at a central spot to swap packages. To find the fairest location, you take the average of their latitudes and longitudes.
In the algorithm: The system picks a spot, gathers the orders closest to it, calculates their average centre point, and shifts the group accordingly. It repeats this tug‑of‑war until the centre stops moving.
In Earl’s terms: If Earl has five people to apologise to, he averages out where they live to find the “middle” location. If three of them live in the trailer park, the average gets dragged toward the trailer park.
K‑Means can produce useful initial groupings, particularly when customers are distributed across compact areas. It is also relatively easy to explain.
However, K‑Means has limitations. The number of groups must be chosen in advance, the method prefers neat shapes, and it may create tidy answers that ignore the road network or operational realities.
Camden County would probably cause problems because Earl’s world is not arranged into neat circles.
Density‑based clustering begins from a different assumption. Instead of deciding in advance how many groups must exist, it searches for areas where orders are already concentrated.
DBSCAN is a common example. It examines the neighbourhood around each order and asks whether enough nearby orders exist within a selected radius to form a meaningful cluster.
Dense areas become groups, while isolated orders may remain outside the main clusters as noise or exceptions.
Earl’s problems are often distributed in exactly this way: clusters around the trailer park, the Crab Shack, and his childhood haunts, with isolated incidents elsewhere.
DBSCAN asks which orders already appear connected through proximity. It searches for communities rather than forcing every point into a tidy territory.
The result depends heavily on the selected radius and the number of neighbours required. Poor settings can merge everything into one giant cluster or leave most orders ungrouped.
Experienced planners adjust these boundaries instinctively because the meaning of distance varies with traffic, road quality, access restrictions and local knowledge.
Geography is only one way in which orders can belong together. Two orders may be far apart but still share important characteristics, while two neighbouring orders may require completely different operating conditions.
Suppose Earl has three items involving Joy. They may have happened in different places and times, but they share the same person and require the same emotional context.
Orders can be described using features such as:
A simplified order might be:
Order = Location, Time, Capacity, Vehicle Type, Customer
A similarity model measures how closely two profiles resemble each other. A common method is Euclidean distance:
d(x, y) = √Σ(x_i − y_i)²
The smaller the distance, the more similar the orders appear. “Count the differences to see how much two things look alike.”In school, this formula (the Pythagorean theorem) is used to find the straight-line distance between two points on a flat graph. But in data science, it is used to measure the distance between two profiles.Instead of measuring miles on a map, it measures the “distance” between characteristics.Imagine comparing two delivery orders across a few checkboxes:Is it refrigerated?Does it need a tail-lift truck?Is the delivery window in the morning?The formula takes the differences between these checkboxes, squares them (so negative numbers don’t mess up the math), and adds them together.The Rule: The smaller the final number (), the closer the two orders are in similarity. If the number is zero, the orders are identical operational twins.In Earl’s terms: This formula doesn’t care where the items are on a map; it cares what they feel like. If Item A is “stole a wallet from a guy” and Item B is “stole a car from a girl,” the formula looks at the “theft” characteristic, sees a match, and decides these two items belong in the same psychological category, even if the victims live on opposite sides of town.
The difficulty is deciding how much each feature should matter. If geography dominates, customer commitments may be ignored. If customer similarity dominates, loads may travel unnecessary distances.
Features also operate on different scales, so the data must be transformed carefully.
This is where optimisation becomes more than mathematics. The model must embody operational judgement.
Similarity is not enough to describe every reason orders belong together. Sometimes the important connection comes from the wider network in which they operate.
Graph models represent each order as a node and each relationship as a connection:
shared customers
common collection points
trailer dependencies
delivery sequences
commercial commitments
equipment flows
The optimiser searches for parts of the network where internal connections are stronger than external ones a process known as graph partitioning or community detection.
This is different from similarity. A graph asks which orders are connected strongly enough to form a natural operational community?
Earl’s list works the same way. Some items are similar; others are connected through chains of consequences.
Transport networks contain the same hidden structure.
Experienced planners perform this grouping instinctively. They recognise patterns that algorithms attempt to uncover.
They know:
which customers travel well together
which delivery areas create hidden delays - the M62 is always a nightmare
which combinations usually fail
which customers hold vehicles - delivery point A are awful at tipping
which drivers excel at difficult sites - Kylie can always get tipped quickly
This knowledge is rarely stored in a single field. It comes from experience, conversations, failures and observations.
Earl becomes more effective for the same reason he learns the structure behind the list.
Grouping is not only an algorithmic problem, it is a product design problem.
A product team must decide:
what a “good group” means
which constraints are rules vs preferences
how to provide explainability
how to treat overrides as learning signals
The best design creates a conversation between optimiser and planner.
This is partly an epistemological problem: deciding what evidence matters, which relationships are meaningful and what knowledge is required before two orders belong together.
Before an optimiser calculates a route, it has already made decisions about:
compatibility
constraints
similarities
relationships
Poor grouping creates poor routes. Once the wrong orders are placed together, the optimiser is simply arranging a bad decision efficiently.
Good grouping reduces complexity without removing operational structure.
Earl eventually learns the same lesson. His list is not a sequence of independent jobs it is a network of people, places, promises, grudges, debts and consequences.
Crossing an item off the list matters, but understanding what it is connected to matters more.
In transport optimisation, the route may be the visible output, but the real work begins much earlier when the system decides what belongs together.
Try it interactively. Open the order clustering simulation on its own page → — full-width, with a walkthrough of what each control does.