AI Delay Classification in Mining
The Rule Nobody Will Touch
On most Australian processing plants, the automatic part of delay accounting is a block of C# logic that someone wrote during commissioning. It sits inside Ampla, now sold as AVEVA Production Management, and it does one job: when the plant stops, it looks at the tag states and the duration, walks a condition tree, and assigns a reason code before an operator has to. On a good day it codes more than half the events on its own, and the shift supervisor only touches the ones it could not resolve.
That logic was correct the day it was commissioned. Then the plant changed, the person who wrote it left, and nobody has opened the rule file since. It still runs. It still assigns codes. The codes are just increasingly wrong, in ways that are hard to see because the report always looks complete.
This is a guide to the decision most sites eventually face: whether to keep hand maintaining that rule logic, replace it with a model trained on the plant's own coding history, or run both. It covers what auto classification actually does inside a system like Ampla, where a trained classifier genuinely beats hardcoded rules, where rules still win and should stay, and how to tell which of your reason codes belong on which side of that line. Across 18 years of industrial data and OT work, including production and reporting systems projects delivered for BHP, Rio Tinto and Senex Energy while employed by other consulting and engineering firms, the failure pattern around auto classification has been consistent enough to write down.
What Auto Classification Does Today
Delay accounting answers one question for every hour in the calendar: what was each piece of equipment doing, and if it was not producing, why not. The machine measured half of that answer is reliable. An interface off Citect SCADA or the plant PLCs drives a running or stopped signal, Ampla opens a downtime record when the state changes and closes it when the equipment runs again, and the duration is accurate to the second.
The reason for the stop is the hard half, and that is where auto classification lives. The classic implementation is a rules engine written in C#, structured as a condition tree. It reads the equipment location, the duration, and the state of a set of surrounding tags at the moment of the stop, then maps that combination to a path through the cause and reason code tree.
How auto classification assigns a reason code
A worked example. A conveyor stops. The rule checks: was the upstream bin level low at the moment of the stop? If yes, and the stop lasted under three minutes, code it as feed starvation rather than a mechanical fault. That single rule saves an operator a decision several times a shift, and when the plant runs the way it ran at commissioning, it is right almost every time.
The trouble starts when the plant stops running that way.
Why the Rules Decay
A hardcoded rule tree does not break. It decays, and it decays in ways that keep the report looking healthy while the numbers underneath rot.
The plant changes and the rules do not. A circuit gets debottlenecked. A crusher is swapped for a different type that fails differently. A new feed source arrives with ore hardness the original rules never anticipated. Each change quietly invalidates a branch of the condition tree, but changing the tree needs someone with Ampla configuration access, an understanding of the rollups, and the authority to warn the site that this month's numbers will not compare cleanly to last month's. That person rarely exists, so the rules stay frozen against a plant that keeps moving. This is the same drift that pulls the whole model away from reality, covered in more depth in our guide to Ampla delay accounting.
The rules are brittle at the edges. A condition tree is a set of hard thresholds. Bin level below X, duration under Y seconds. Real stoppages cluster around those thresholds, and a rule cannot express "probably feed starvation, but check the chute". It commits to one code with total confidence, and when the combination is ambiguous it commits confidently to the wrong one.
Multi signal cases defeat them. When a stop has three contributing signals moving at once, the number of condition branches needed to cover the combinations grows faster than anyone will ever write or maintain. So the rule file covers the common cases and dumps everything else into a catch all bucket. That bucket, the "other" or "unclassified" code, is where the truth about a plant's losses usually goes to die.
The free text is ignored entirely. When an operator overrides the auto code and types a note, that note is the most honest data on the site. A C# rule cannot read it. It has no way to learn that operators keep re-coding a particular event type, or that a comment field keeps saying "chute blocked again" against events the rule insists are feed starvation.
Where a Trained Model Wins
A model trained on the site's own historical coding does the same job as the rule engine, from the same inputs, with three differences that matter.
It handles fuzzy, multi signal cases. A classifier trained on thousands of past events learns the combinations that no one would sit down and write as rules. It weighs bin level, motor current, upstream and downstream state, time of shift and duration together, and it produces a most likely code with a confidence score attached. High confidence codes flow straight through. Low confidence ones get flagged for a human, which is exactly the queue a supervisor should be spending attention on.
It reads the free text. A language model can take the operator's own note, "chute blocked again after the feed change", and use it as a signal alongside the tag data. The comment field stops being dead weight in the database and becomes an input. The operator note is often the only honest record of what actually happened, which is exactly why a decayed rule engine that cannot read it keeps missing the real cause.
It keeps up with the plant. When the plant changes, you do not rewrite a condition tree. You retrain on recent events, and the model absorbs the new failure modes from the coding operators are already doing. Drift becomes a retraining schedule rather than a stalled change request nobody will own.
Hardcoded rules versus a trained classifier
| Metric | C# rule tree | Trained model | Improvement |
|---|---|---|---|
| Clear single cause events | Reliable | Reliable | Tie |
| Ambiguous multi signal events | Confidently wrong | Ranked with confidence | Model |
| Operator free text notes | Ignored | Used as a signal | Model |
| Adapting after a plant change | Manual rewrite, rarely done | Retrain on recent events | Model |
| Auditable, deterministic answer | Yes, same input same output | Probabilistic, needs governance | Rules |
| Hard safety classifications | Explicit and defensible | Should not be left to a model | Rules |
Where Rules Still Win
The pitch for machine learning usually stops at the table above, which is where it becomes dangerous. There are reason codes that should never be handed to a model, and knowing which ones is the whole skill.
Anything with a safety or regulatory consequence stays deterministic. If a stop has to be classified as a reportable safety event, an environmental exceedance, or anything that feeds a statutory return, you need an answer that is the same every time, that you can trace to an explicit condition, and that you can defend in front of a regulator. A probability of 0.83 is not an answer you want to give an inspector. These classifications belong in an explicit rule, or in a human decision with a name attached, and they stay there. The reasoning is the same one that governs any AI touching regulated data, which we set out in our note on AI agent governance and human override.
Contractual and commercial boundaries stay explicit. Where a downtime code determines who pays, a maintenance contractor's availability guarantee, a take or pay threshold, a demurrage clock, the definition needs to be written down and agreed by both sides rather than inferred by a model. A model that occasionally reclassifies a contractual stop is a model that occasionally moves money, and no one signed up for that.
Anything with too little history stays on rules. A classifier needs examples. A brand new circuit, a rare failure mode that has happened four times, a code introduced last month, none of these have enough coded events to train on. Rules cover the cold start until the history builds.
Should this reason code be auto classified by a model?
The honest position is that most sites end up with both. A model handles the high volume, low stakes, genuinely ambiguous coding where it is clearly better. A rule layer sits above it and hard codes the classifications that carry safety, regulatory or commercial weight, and those rules override the model every time. The design question is not which technology, it is where the line between them sits, and that line is specific to your plant.
What the Model Needs Before It Will Work
A classifier is only as good as the data foundation under it, and this is where most attempts fail before they start. Three things have to be in place, and if they are not, fixing them is the actual project.
Coding history that is worth learning from. The model learns from your past codes, so if the past codes are the output of a decayed rule tree and rushed operator overrides, the model learns to reproduce those mistakes. You need a body of events that has been coded reasonably well, or a period of cleanup first. Garbage history trains a confident garbage model.
Asset context the model can key off. The classifier needs to know that this event happened on the secondary crusher, that the secondary crusher sits in the crushing circuit, and that the crushing circuit feeds the mill. That structure usually lives in the equipment hierarchy already, but only if the hierarchy is clean. A well maintained asset model, of the kind built on PI Asset Framework or the equivalent, is the difference between a model that generalises and one that memorises.
Tag data that is named and trustworthy. The signals feeding the classifier, bin levels, motor currents, states, have to be the right tags, correctly named, and reliable. If the tonnes coming off SCADA never reconcile against the historian and the ERP in the first place, as we covered in when SCADA and your ERP disagree on tonnes, no classifier will save you. It will just learn the discrepancy.
A realistic path to a working classifier
Shadow mode is the step people skip and regret. Before the model codes anything that reaches a report, run it silently beside the existing rules for a few weeks and compare its answers to what operators actually chose. That comparison tells you which codes it is ready for and which it is not, and it builds the trust you need before a supervisor will let a model touch their numbers.
The Value, Honestly Framed
The return on this work is not a headline percentage, and anyone quoting one has made it up. The value shows up in three specific places, and how big each is depends entirely on your plant.
Where the value actually shows up
The last one is the point. The reason delay accounting stops driving decisions is that people stop trusting the numbers, and they stop trusting them because the classification drifted away from the plant. A model that retrains keeps the numbers connected to reality, and connected numbers are the ones that end up in the shift review argument instead of being quietly ignored. Everything downstream, the Pareto, the loss attribution, the historian data flowing into Power BI, depends on that classification being trusted.
Getting the Line Right for Your Plant
Auto classification in mining is a real improvement when it is scoped honestly and a liability when it is sold as a wholesale replacement for judgement. The work is deciding, code by code, which classifications are genuinely ambiguous and high volume enough to hand to a model, which carry safety, regulatory or commercial weight and must stay explicit, and whether your coding history and asset data are clean enough to train on at all. That is a plant specific engineering decision, and it rests on understanding both the OT data and the reporting obligations sitting on top of it.
If you are looking at a decayed rule tree that nobody wants to touch, or an "other" bucket that has quietly become your largest loss category, that is the conversation worth having. Our AI consulting practice works at the join between plant data and the decisions it is supposed to support, vendor neutral on the tooling and clear about where a model belongs and where it does not. The starting point is a look at your actual coding history and asset model, because that is what decides whether any of this is worth doing.
If you want to scope where a trained classifier would earn its place on your site, start a conversation with us and we will work through your reason code tree and your data foundation before anyone writes a line of model code.