Project PACE — optimising the track, not just the trains

Rail networks spent thirty years optimising what trains do. They spent almost none optimising 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 — which the existing planning method, a manual cadence of fortnightly and monthly system-wide shutdowns set independent of asset state, couldn't accommodate cleanly.

The visible symptom: 54% of stationary maintenance 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 genuinely compete: keep the assets reliable, keep the resources affordable, keep the contracts honoured.

The Operations Research literature had been busy modelling rolling stock for thirty years and rail infrastructure barely at all. There was nothing to buy. The brief was therefore also a research programme — 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: 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, 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 those questions can be asked and answered concretely, no planner trusts the output of a black box.

Working backwards from the comparison, we extracted the constraints that were genuinely sweatable — not the academic ones, the operational ones — 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. The plan wasn't the deliverable. The process for assembling the plan was.

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 one ran on a different clock — operational quarters, semester-paced research, vendor sprints. Reconciling those cadences was hard, and we'll be honest that it didn't always work.

Research deliverables dominated the visible output. Aurizon's larger enterprise systems-integration programs — bigger budgets, louder stakeholders — competed for the time and oxygen the program needed to productionise. The lesson banked: cutting-edge work needs governance that protects it from being deprioritised by louder ones, and that protection is a program-design decision, not a status-report decision.

Maths was the easy part

The hardest sub-problem wasn't the multi-commodity network flow optimisation. The maths was demanding but contained. The hard part was translating that maths back into language and tools that planners — people who managed millions of dollars of remote maintenance, crews, machinery, access contracts and regulator-facing cost cases by rule of thumb — could use, trust, and defend.

The failure mode of a program like this is never the model. It's change, adoption, and commercials. We knew it then. We design for it now.

When things went sideways

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

There wasn't a single catastrophic moment — 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 org's existing planning conversation more naturally. PACE was ahead of the productionisation pathway around it.

We name this not as a regret — the program achieved what it was funded to achieve, and the influence travelled further than the tool did — but because it's 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.

What landed wasn't a tool sitting on a planner's desk. What landed was three other things — and one of them is the case study itself.

Polymathian was proven. PACE was the calling card for the optimisation-of-complex-coordination methodology 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. PACE helped invent it.

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 remains one of the few papers that treats rail-infrastructure maintenance scheduling at network scale with the modelling sophistication 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, 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 would 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 — without the friction of enterprise guardrails designed (correctly) for the systems that run the business today.

The separation is not the end state. It is the staging ground. 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.

This isn't a private opinion. The pattern is described rigorously in Ross, Beath and Mocker's 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 lesson banked is that the principles only deliver when the deployment path off the platform and back into the backbone is also designed — not assumed.