Where AI helps your cold chain — and where it hits the Gauteng wall

We have said it before, in more than one article: artificial intelligence alone will not solve the South African cold chain. That is not a swipe at the technology. It is a statement about where a tool’s power ends and a territory’s reality begins. And there is no cleaner place to watch that line being drawn than in something that sounds almost trivially simple — working out the best way to deliver 80 frozen orders across Gauteng with three trucks.

It sounds like a problem your phone should solve before you have finished your coffee. It is, in fact, one of the hardest problems in all of computing. Understanding why is the fastest route we know to understanding exactly what AI can do for a frozen logistics operation, and exactly what it cannot.

The board the solver is asked to play

Before any algorithm runs, look at the ground. Gauteng is South Africa’s smallest province — roughly 18,178 square kilometres, about 1.4% of the country’s land. It is also the most populous, home to around 15 million people at a density above 800 per square kilometre, by a wide margin the highest in the country. The smallest footprint, the densest demand. That contradiction is the starting condition for everything that follows.

A single delivery day is not confined to one city. Gauteng is governed by three metropolitan municipalities — Johannesburg, Tshwane and Ekurhuleni — plus two district municipalities containing six local municipalities: nine service-delivery authorities in all. A routine route — Sandton in the morning, Pretoria by midday, Kempton Park in the afternoon — crosses two to four of them. Each has its own roads authority, its own signal-maintenance backlog, its own budget crisis. There is no single owner of the tar you drive on.

The road network is vast. The provincial network alone runs to roughly 5,781 kilometres of carriageway, and that figure explicitly excludes metropolitan streets and the national toll roads. Add the three metros and the total network you operate across runs into the tens of thousands of kilometres.

On that network sits the traffic. According to the Road Traffic Management Corporation, Gauteng carries about 5.04 million registered, roadworthy vehicles — 38.4% of the national total. Nearly four in ten of the country’s vehicles, on 1.4% of its land. The Ben Schoeman corridor between Johannesburg and Pretoria is the busiest road in the country; engineering counts put average daily traffic on its core sections between 120,000 and 155,000 vehicles, where seven lanes squeeze down to three.

Then there is the part no software models. South Africa runs on roughly 200,000 minibus taxis carrying about three-quarters of all daily commuter trips — on the order of 15 million trips a day — and Gauteng holds a large share. By legal definition a minibus taxi is an unscheduled service. It stops wherever a hand goes up. It receives no subsidy, runs on cash, and is largely unregulated, which is precisely why nobody can tell you where any of them are at 14:30 on a Tuesday. When the commuter rail system collapsed, even more passengers were pushed onto these taxis — a shift the state itself admits it lacks the resources to measure.

And above all of it, the signals are failing. The Johannesburg Roads Agency is responsible for 2,023 sets of traffic lights. Roughly a quarter of them were knocked out by vandalism and cable theft over a four-year stretch, leaving a backlog costed in the tens of millions of rand, while the agency fields between 20 and 65 fault reports a day. Power is worse than vandalism: the JRA’s own mobility head has stated that supply problems take out around 31% of traffic lights at any given moment, rising past 50% during load shedding. Governance makes it stickier still — roughly 60% of the dead intersections fall under provincial rather than city control, so accountability scatters.

That is the board: smallest province, densest population, five million vehicles, the continent’s busiest highway, nine municipalities, thousands of intersections with a large fraction frequently unlit, and an invisible fleet of 200,000 taxis stopping on no schedule. Now we can talk about the maths.

The combinatorial reality

Start with one truck and 80 stops. How many possible orders could it visit them in? The answer is 80 factorial — 80 × 79 × 78 × … × 1. That number is approximately 7 × 10¹¹⁸. A 7 followed by 118 zeros.

Now use all three trucks, because you must both assign each stop to a truck and sequence the stops on each truck. The count of possible route structures climbs to more than 2 × 10¹²².

This is not marketing hyperbole. It is the defining property of a class of problems mathematicians call NP-hard — problems where the number of possibilities explodes so fast that no computer, however powerful, can examine them all. The travelling salesman problem and its bigger sibling, the vehicle routing problem, are the textbook examples. Eighty stops is not an unusually large day for us. It is an ordinary one. And it already sits far beyond what brute force can ever touch.

So the optimiser does not find the best route. For a problem this size, nothing on Earth can prove it has found the best route. It finds a very good route, fast. That distinction matters more than any feature on a sales sheet, and we will come back to it.

A large, confident, crowded market

There is real money chasing this problem. The global route-optimisation software market was valued at roughly 8.5 billion US dollars in 2023 and is forecast to more than double by 2030. Analysts describe it as highly fragmented — a long list of vendors from established enterprise players to specialist start-ups, dozens of platforms all promising to tame the same combinatorial monster.

Their flagship claim, almost without exception, is continuous real-time re-optimisation: the engine does not just build a route at dawn, it rebuilds it through the day as traffic shifts, as drivers fall behind, as new orders arrive. Some advertise routing engines trained on hundreds of millions of deliveries. The pitch is seductive and, in the right environment, entirely real.

It is worth naming what is true here before we name what is not. These tools work. The maths behind them is sound. In a first-world city with clean data, they save fuel, time and money every single day. We are not about to argue otherwise.

Where AI wins

Here is the half that deserves full credit. A good routing engine breaks the impossible problem into two tractable ones. First it clusters — deciding which stops belong together, so Sandton work lands on one truck and Pretoria work on another, rather than sending three trucks crisscrossing the same suburbs. Then it sequences — ordering the stops within each cluster.

To sequence, it does not try every possibility. It builds a sensible route quickly using a construction heuristic, then improves it with local search: small, clever moves like 2-opt, which spots a route that crosses over itself and uncrosses it, or or-opt, which lifts a stop and drops it into a better slot. To avoid getting stuck on a mediocre solution that merely looks good locally, it uses metaheuristics — methods like simulated annealing, tabu search, and especially Adaptive Large Neighbourhood Search, which deliberately rips out a chunk of the route and reinserts it differently to escape dead ends.

Think of a treasure hunter on a vast mountain range who cannot survey every peak. Construction gets them to a decent hilltop fast. Local search checks the slopes nearby for anything higher. Metaheuristics are the discipline to occasionally climb down and march to a distant range, rather than declaring the first hill the summit.

No human dispatcher can do this for 80 stops. The arithmetic is beyond any of us. On the pure problem of turning a scattered list of addresses into three tight, sensible loops, the machine wins, decisively, and we use it for exactly that. Conceding this is not a weakness in the argument. It is the argument. Because once you grant how good the engine is at the maths, the only honest question left is why it still cannot be trusted to run our operation blind. The answer is in five walls.

Wall 1 — the data South Africa does not have

A routing engine is only as good as the numbers it is fed. To decide that one road is faster than another, it needs an accurate travel time for every segment — and to re-optimise in real time, it needs that travel time updated live. In the developed cities these tools were built for, that data is abundant and cheap.

In Gauteng it is neither. Granular, reliable real-time traffic data is expensive and patchy; the global platforms themselves carry a known dependency on third-party traffic feeds, and industry analysis is blunt that in developing regions poor road data and unreliable signals limit how well these tools work beyond the major arteries. Every engine leans on imported map and traffic layers that were never built around an afternoon when a third of the robots are dark and an unscheduled taxi has just stopped across two lanes to load.

Recall the board. Five million private vehicles in unpredictable congestion. The continent’s busiest highway running at capacity. A third to a half of signals potentially out. Two hundred thousand taxis that no feed tracks. The single most important input to route optimisation — a trustworthy travel time for each segment — is precisely the thing this country cannot reliably supply. The optimiser is not wrong. It has been handed a map of a city that does not exist that afternoon. Garbage in, gospel out.

Wall 2 — the model the headline feature does not fit

The industry’s proudest capability is continuous, live re-optimisation. Our operation barely touches it — by design. We finalise routes the night before, off confirmed bookings. Customers confirm what is going where, and only then are the next day’s loops locked.

There is a hard operational reason for this. A frozen route is not a stream of orders trickling in through the day. It is a planned manifest built around what has actually been booked, collected and loaded. The flashiest, most-marketed AI feature in the entire market — the live re-shuffle as new orders arrive — is the one we deliberately do not use, because our model is batch-planned, not on-demand.

This is not a limitation we are apologising for. It is a structural fact of doing frozen properly. You cannot keep re-optimising a truck’s afternoon around walk-in orders when the truck is a moving freezer on a fixed thermal budget and the manifest was sealed at the cold-store door. The result is plain: the feature the vendors lead with is largely irrelevant to a serious frozen courier, and a buyer dazzled by it is paying for capability that does not match the work.

Wall 3 — constraints that actively fight optimisation

An optimiser craves predictability. It wants to learn that Tuesdays look like other Tuesdays, that this loop is efficient, that this sequence repeats. South African security demands the opposite.

For driver and cargo safety, routes are deliberately varied. We do not run the same predictable pattern that a watcher could learn and exploit, and we do not commit to fixed delivery time slots — the order is planned the day before and intentionally varied. That single discipline is, in optimisation terms, sabotage of the engine’s deepest instinct. The algorithm wants to converge on the one repeatable best loop; the territory says never run the same loop twice.

On top of that sit hard exclusions the maths would otherwise ignore. Certain areas are simply off the map for distance and hijack risk — the engine, left alone, would happily route a truck straight through a no-go zone because it is 1.2 kilometres shorter. In parts of the country, unsafe and safe suburbs even share postal codes, so a clean machine-readable boundary does not exist; it takes suburb-level human knowledge to draw the line. The optimiser is solving for distance. Reality is solving for not getting hijacked. Those are different problems, and only one of them is in the software.

Wall 4 — the layer the distance solver cannot see

Even with perfect data and no security constraints, a pure routing engine would still get a frozen route wrong, because distance-optimal is not the same as cold-chain-optimal.

A distance solver treats every stop as identical: arrive, drop, leave. A frozen route is nothing like that. Every door opening is a thermal event — warm air floods a freezer that must then claw the temperature back down before the next stop. A route that minimises kilometres but bunches long door-open collections back to back can quietly cook the load even as the map shows a perfect loop.

Our operating standard is −15 °C, which peer-reviewed evidence supports as sufficient for frozen safety — see why we run at −15 °C. The point holds at either temperature: the solver does not know the freezer is fighting physics between stops.

There is also sequence logic the engine does not inherently understand. You cannot deliver a merchant’s orders before you have collected them. Pickups must precede their dependent drops, collections must flow sensibly into the deliveries they feed, and a route that is beautiful on distance can be impossible in practice because it asks a truck to deliver stock it has not yet loaded. The engine optimises a graph of points; it does not, on its own, grasp that point 14 cannot happen before point 3.

Which is why a human still reviews every route, visually, before it goes out. A dispatcher who knows the ground looks at the proposed loops and checks that the flow makes sense — that collections precede deliveries, that the sequence is sane, that no truck has been sent somewhere it should not go. The optimiser proposes. The dispatcher disposes. That visual sanity check is not nostalgia for the old way; it is the step that catches the things the maths was never equipped to see.

Wall 5 — the plan is brittle, and the map has profit traps

An optimised route is a tightly coupled chain. Stop 2 assumes stop 1 finished on time; stop 14 assumes the thirteen before it all ran to plan. The tighter the optimisation, the less slack there is between the links — and the harder a single failure hits everything downstream.

Now feed in a Gauteng afternoon. A robot is dark at a key intersection and the crossing that should take 40 seconds takes six minutes. A taxi stops across two lanes to load. A collection runs 20 minutes long. Or — the quiet killer — one address is wrong or incomplete, which is common where addressing is informal and a GPS pin lands in the wrong street or the wrong estate gate. Any one of these sends a domino through the rest of the day: every remaining stop slips, the tight loop unravels, and for a frozen load each slip eats into the thermal budget. A badly missed stop becomes a failed delivery and a costly re-delivery tomorrow. The engine built a plan that assumes everything goes right. Reality propagates the first thing that goes wrong through the entire afternoon.

Here is the irony at the heart of it: the more aggressively you optimise, the more fragile the result. A theoretically perfect route has no buffer. A route a human has loosened slightly — clustered a little tighter, left some slack — survives contact with the road. In this territory, robustness beats optimality. The vendor’s mid-day re-optimisation is meant to absorb exactly these shocks, but in a model where the route is sealed the night before and the recovery options are boxed in by security, sequence and thermal limits, there is far less room to re-shuffle than the sales sheet implies.

And then there is the trap the engine walks into willingly, because it is optimising the wrong number. It minimises distance and time for the stops it is handed. It has no concept of contribution margin. So it will cheerfully route a truck to the edge of the board — Carletonville out west in Merafong, Heidelberg down in Lesedi, Vereeniging in the Vaal — to serve one or two drops, because that is the shortest path to those particular stops. What it cannot see is that the run consumes the kilometres and the hours of eight to ten dense stops to deliver one. In the core, a truck averages little more than ten kilometres between drops; a single peripheral stop can sit sixty to ninety kilometres from the depot, a round trip that swallows a whole route’s worth of running. The map says efficient. The books say dead route.

Deciding which far-flung orders to accept, which to hold for a scheduled weekly far-zone day, and which to price as a premium so the density maths still works is a commercial judgement the optimiser is structurally incapable of making. It is the entire difference between a route that is distance-optimal and one that is profit-positive. We batch and price the periphery deliberately. The engine, left to run blind, would quietly turn a profitable day into a dead one and report it as a success.

What this means for operators

Strip away the marketing and the picture is clear, and it is not anti-technology. It is this:

• Route optimisation is a powerful, legitimate tool. On the raw combinatorial problem, it beats any human, and we rely on it.
• “AI-powered” as a badge is not the same as value delivered. The headline feature — continuous live re-optimisation — is largely beside the point for a batch-planned frozen operation.
• The engine is only as good as the data, and South African data is thin where it matters most: live, trustworthy travel times across a network where a third of the signals may be dark.
• Security, exclusions and cold-chain physics are constraints the solver cannot see, and they are not edge cases here. They are the daily reality.
• Geography is a profit trap the engine cannot read. A distance-optimal route to the edge of the province can be a dead route on the books, and a tightly optimised plan is brittle to the first delay or wrong address — both of which are routine here.

What delivers a good frozen route in practice is not the algorithm alone. It is a solid optimisation engine plus confirmed day-before bookings, plus local knowledge of which roads and suburbs to avoid, plus the thermal discipline of cold-chain physics, plus the commercial judgement of which far orders to accept, batch to a scheduled far-zone day, or surcharge so the density maths still holds, plus a human eye on every loop before it leaves. Take any one of those away and the route degrades, no matter how clever the software.

The same lesson, again

We have made this point about telematics — that data without physics is just a fancy logbook. Routing is the same lesson from a different angle. Artificial intelligence wins the maths and loses the territory. It can compute, in seconds, what no human could compute in a lifetime. It cannot see the dark robot, the unscheduled taxi, the hijack zone, or the warming load. Those are not in the dataset, and in South Africa they never will be.

AI alone cannot solve the South African cold chain. The simple act of routing 80 stops proves it precisely because the maths is so impressively hard — and yet solving the maths is the easy part. The hard part is the territory. The optimiser is a tool inside the cold chain. It is not an oracle over it. We use it for what it is good at, and we put a human, a freezer, and three decades of road knowledge around it for everything else.

Companion reading: The Smart Fleet Delusion — why telematics without physics is just a fancy logbook. Figures in this article reflect publicly reported South African data current at the time of writing; treat them as orientation, not a quote.