Predictive analytics in mining, forecasting haul cycles with Vertex AI

The shift you only understand once it’s over

An open-cut mining operator runs on one repeated motion. A truck loads at the face, hauls to the crusher or dump, tips, and returns for the next pass. Multiply that by a fleet across a shift and the haul cycle is the operation. It sets how many tonnes move, how well the dig plan holds, and whether the day hits its target.

The frustration is timing. Dispatch and fleet-management systems record every cycle in detail, down to the load, haul, dump and return segments. Yet most of that data is read backwards. The shift closes, the numbers are tallied, and the planning meeting the next morning works out why the tonnes came in light. By then the trucks have already run. The information existed all shift. It just never turned into a prediction anyone could act on while the shift was live.

Off-the-shelf reporting does not close that gap. A dashboard is good at the rear-view mirror, showing what cycle times and production were. It cannot tell a dispatcher that the next shift is tracking below target, because that needs a model of how this pit, this fleet and today’s conditions move cycle times. Haul-cycle times are also genuinely volatile. Weather changes the haul roads, the pit deepens as you dig, the crusher queues, and one operator runs a different cycle to the next. A site that wants to plan ahead needs a forecast, not another report of the shift it has already lost.

Why a bespoke Vertex AI forecasting model, not a report

The goal is a forecast a planner trusts enough to move trucks on. That is a prediction problem about this specific operation, so we build a bespoke forecasting model rather than reach for a packaged dashboard. We headline these builds on Vertex AI, Google Cloud’s machine learning platform, for three practical reasons. It handles the model training and tuning on this site’s own cycle history without a large in-house ML team. It serves the forecast back to the planning tools on a schedule that matches the shift cycle. And it tracks model versions and performance, so when accuracy drifts as the pit changes, that shows up rather than rotting quietly.

The model is only as good as the data beneath it, so the architecture shapes that first. Raw cycle, dispatch, weather and pit data lands in Snowflake, where we reconstruct clean haul cycles from noisy dispatch logs and engineer the features the forecast learns from. We segment each cycle into load, haul, dump and return, and encode the conditions that move them, pit state, weather, crusher queueing, and truck and operator detail. Vertex AI trains on that history to forecast cycle times and shift production, and crucially returns a range with an uncertainty band rather than a single false-precise number. The forecast then feeds Power BI, so planners and dispatch read it where they already work, alongside the actuals.

We separate the data layer from the model on purpose. Cycle data at this scale punishes shortcuts, and a clean modelled layer in Snowflake can feed other forecasts later, maintenance, grade or scheduling, not just today’s haul-cycle model. The forecast is bespoke because the relationship between pit, weather, queueing and cycle time belongs to this operation. That is the part no off-the-shelf product carries.

Building it, and where it got hard

The model was rarely the hard part. The friction lived in the cycle data, and it was bad enough that a first naive model was confidently wrong.

The trouble was that haul-cycle times vary wildly and the dispatch data describing them is messy. Cycle times swing with weather, pit conditions, the queue at the crusher and which operator is driving. On top of that, the raw dispatch logs had gaps and mislabelled cycles, a load event missing here, a dump attributed to the wrong location there, partial cycles at shift change. A model trained straight on that learned the noise. It produced a single tidy number that looked authoritative and was often well off the actual tonnes, which is the worst way to be wrong on a planning call.

The fix was careful work on the data and the way the forecast was expressed, not a cleverer algorithm. First, we reconstructed cycles from the noisy logs, repairing or discarding broken ones and validating each against the expected load-haul-dump-return shape. Then we engineered features that captured the real drivers, segmenting the cycle, encoding pit and weather state, and representing the crusher queue. Then we modelled the uncertainty explicitly, so the forecast came back as a range, and a volatile day produced an honestly wider band rather than false precision. Finally we validated against held-out shifts the model had never seen, so the accuracy we reported was the accuracy on shifts it had not been tuned to, not on data it had memorised.

Two constraints shaped the rest. Forecasts had to land before the shift they covered, so the pipeline was scheduled to the shift cycle rather than run on demand. And because operational data carries safety and personnel context, operator-level detail was handled carefully, kept to legitimate operational use and held within the operator’s own environment, in line with its data-handling obligations.

What changed

In a representative build the shift-production forecast tracked actual tonnes within a single-digit error band, close enough that planners acted on it before the shift ran. Likely shortfalls surfaced hours ahead rather than at the post-shift review, which gave the dispatcher a genuine window to move trucks, change a haul route or re-sequence the dig. And because every forecast carried an uncertainty band, planners saw a credible spread of tonnes and trusted it, instead of dismissing a single number they knew the volatility could not support.

These figures are illustrative. They describe the pattern we see rather than a published result for a named operator. The shift is the point. The cycle data that was always there starts arriving as a forecast the planning team can act on, while the shift can still change, rather than as a report of the tonnes already lost. That is the difference between explaining a light shift and preventing one.

Where this fits

A haul-cycle forecast is one application of our Tailored Solutions service, built on Vertex AI, for the realities of Australian open-cut mining. It suits this problem because the data already exists in dispatch and fleet systems, and the value comes from modelling it properly and getting the forecast in front of planners before the shift, not after. If your production numbers only make sense the morning after, the place to start is to map your cycle, dispatch and pit data and decide the handful of shifts where seeing the shortfall early would change the call.