Project PACE — optimising the track, not just the trains

Rail networks had poured their optimisation effort into what trains do, and almost none into what track does. Coal moves money. Track work doesn't. So the industry built sophisticated models for one and treated the other as overhead. By 2012, that asymmetry was getting expensive.

Aurizon Network, the owner of Australia's largest export coal rail network, was on a path from 210 Mtpa to a 310 Mtpa contracted target. More throughput meant more wear, and more wear meant more maintenance. The existing planning method couldn't absorb that cleanly. It ran on a manual cadence of fortnightly and monthly system-wide shutdowns, set independent of asset state.

The symptom showed up in the numbers. More than half of stationary maintenance (54%) was happening outside the scheduled shutdowns anyway, slotted in opportunistically between train jobs. Track work was consuming 23% of network capacity while 25% sat unutilised. The schedule and the assets weren't talking to each other.

Aurizon Network commissioned a tool that didn't really exist yet. They wanted to evaluate any proposed maintenance schedule against three objectives that compete with each other: keep the assets reliable, keep the resources affordable, and keep the contracts honoured.

The Operations Research literature was full of train-scheduling models, and optimisation models for coal-rail infrastructure maintenance were virtually nonexistent. There was nothing to buy, so the brief was also a research program: a three-way collaboration between Aurizon Network, the University of Newcastle (under an ARC Linkage grant), and a then-emerging Brisbane optimisation house called Polymathian.

Our remit was to lead the program, choose the vendor, harness the academic partners, and act as the bridge between operations-research mathematics and a planning team that needed to use the output. The non-negotiables were academic rigour (the work had to be publishable), planner-grade defensibility (the tool had to survive scrutiny inside Aurizon's network planning team), and a delivery rhythm that respected three different working cadences at once.

Set the credibility loop before optimising anything

Polymathian's method gave the program its spine: build the model, run existing schedules through it, and compare what it produced with what Aurizon's planners had actually executed. That comparison was the validation loop, and it was also the trust loop. Is the model's plan realistic? Is it better? Worse? How? Until someone can ask and answer those questions concretely, no planner trusts the output of a black box.

Working backwards from the comparison, we extracted the operational constraints that were sweatable and designed the upstream process the model needed: how to marshal complex inputs from maintenance crews, asset owners, contract managers, and above-rail operators into a form the optimiser could ingest. That intake process was the real deliverable.

Run the cadence three ways

This was a three-handed program: Aurizon Network operations on one side, the University of Newcastle and the ARC Linkage structure on another, Polymathian on a third. Each ran on a different clock: operational quarters, semester-paced research, and vendor sprints. Reconciling those cadences was hard, and it didn't always work.

Research deliverables dominated the visible output. Aurizon's larger enterprise systems-integration programs, with bigger budgets and louder stakeholders, competed for the time and oxygen the program needed to productionise. We banked the lesson. Novel work needs governance that actively protects it from louder programs.

Maths was the easy part

The maths, a multi-commodity network flow optimisation, was demanding but contained. The harder problem was translating it back into language and tools that planners could use, trust, and defend. These were people who managed millions of dollars of remote maintenance, crews, machinery, access contracts, and regulator-facing cost cases by rule of thumb.

The failure mode of a program like this is never the model. It's change, adoption, and commercials.

When things went sideways

The tool was technically validated. The research paper was published. And it didn't make it into production planning.

It happened gradually. The program ran out of money, larger enterprise initiatives drew the available time and attention, and the operating environment of the day wasn't structured to take a novel R&D output and turn it into “this is how we plan, here.” Aurizon was concurrently maturing optimisation capability through more traditional simulation- and stochastic-modelling tools that fit the organisation's existing planning conversation more naturally. PACE was ahead of the productionisation pathway around it.

This is the load-bearing lesson. Novel optimisation is a technology problem, an adoption problem, and a commercial problem in roughly equal measure. Skip any of the three and you'll get a great research paper. The program still achieved what it was funded to achieve, and its influence travelled further than the tool did.

The tool was shelved. Three things survived it, and one of them is this case study.

Polymathian was proven. PACE was the calling card for the optimisation-of-complex-coordination method that Polymathian later productised as six software products spanning mining, rail, maritime, energy, and maintenance: ORB (mining operations), BOLT (bulk supply chains), RACE (rail supply chains), GEAR (maintenance), SOLO (maritime), and VOLT (energy and utilities). In November 2022, Sandvik announced its acquisition of Polymathian, with the business integrated into Sandvik Mining and Rock Solutions' Deswik unit on the strength of exactly this category of work. The category itself, constraints-based optimisation for heavy-industry value chains, is now a mature segment with multiple competitors.

The maths went into the literature. The paper, Possession assessment and capacity evaluation of the Central Queensland Coal Network, was published open-access in the EURO Journal on Computational Optimization (Springer, 2014). It brought to network-scale maintenance scheduling the kind of modelling the field had reserved for rolling stock.

The thinking influenced Aurizon's planning practice, even though the tool didn't go into production as a daily-use system. The frame of evaluating any candidate schedule against three competing objectives (asset reliability, resource requirements, and contract compliance) became part of how the network planning conversation was structured. Parts of the input-marshalling discipline we designed to feed the model survived after the model itself was shelved.

Could the client run this without us today? They never were running it with us. The transfer was always the point.

Novel optimisation is a technology problem, an adoption problem, and a commercial problem in roughly equal measure. We knew that in 2012. We design for it now.

If we were running PACE today, we'd structure the program around the productionisation pathway from day one: who in the planning team owns the tool, what its first non-research use case is, where it sits in next year's operating budget, and what the planning conversation looks like after it lands.

The maths is necessary. It is not sufficient. The frontier and the floor have to be commissioned together, or the floor stays where it is.

How we structure novel work today

Whether the work is truly novel to the world or just novel to the client, we run it the same way: a small, cross-functional team kept structurally separate from the BAU enterprise technology function. Separate, so it can move at the speed novel work needs, free of the friction of enterprise guardrails designed (correctly) for the systems that run the business today.

The separation lasts only as long as the work needs it. Once the work is viable, we strike an explicit, incremental deployment path back into the enterprise: who in the operational backbone takes ownership, how maintenance and support windows are absorbed, how the novel team transitions out, either back into the BAU function for ongoing care or on to the next novel problem.

Ross, Beath, and Mocker describe this pattern rigorously in Designed for Digital (MIT Press, 2019), which separates the operational backbone (efficient, reliable, hierarchical) from the digital platform (autonomous, empowered, fast-iterating) and prescribes a different management framework for each. PACE was operating on those principles before they were named that way. The principles only deliver when someone also designs the deployment path off the platform and back into the backbone. All of our engagements today build change and adoption assessments into the initial planning phase, so the path to BAU, or the off-ramp the investment criteria call for, is clear from the start.