AI delay classification in mining means using a model trained on a site's own coding history to assign downtime reason codes, alongside or instead of the hardcoded rules inside Ampla (AVEVA Production Management). For delay accounting in mining, a model wins on ambiguous, high-volume stops; explicit rules must stay for safety, statutory and contractual codes.
Key takeaways
- Most Ampla auto classification is a C# condition tree written at commissioning. It does not break, it decays as the plant changes.
- A trained classifier handles fuzzy, multi-signal stops, reads operator free text and adapts by retraining.
- Safety, regulatory and contractual reason codes stay on explicit rules or a named human decision. The model never overrides them.
- Clean coding history, a clean asset hierarchy and trustworthy tags come first. Without them, the model learns your mistakes.
- Run the model alongside the existing rules for several weeks before it codes anything that reaches a report.
The rule nobody will touch
On most Australian processing plants, the automatic part of delay accounting is a block of C# logic written during commissioning. It sits inside Ampla, now sold as AVEVA Production Management. When the plant stops, it reads tag states and duration, walks a condition tree and assigns a reason code before an operator has to.
That logic was correct on 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 and still assigns codes. The codes are just increasingly wrong, in ways that are hard to see because the report always looks complete.
This guide covers the decision most sites eventually face: keep hand-maintaining the rule logic, replace it with a model trained on the plant's own coding history, or run both. Across our consultants' careers, including production and reporting systems work in BHP and Rio Tinto environments, the failure pattern around auto classification has been consistent enough to write down.
What does auto classification do in delay accounting 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 measured half of that answer is reliable. An interface from 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, 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 surrounding tags at the moment of the stop, then maps that combination to a path through the cause and reason code tree.
- State changeSCADA or PLC signal says the equipment stopped
- Event openedAmpla creates a downtime record with a measured duration
- Rule firesC# condition tree reads tag states and duration
- Code assignedA path through the reason code tree is chosen automatically
- Operator reviewsSupervisor confirms, overrides, or codes the leftovers
- RollupTime Usage Model turns codes into availability and loss
A worked example. A conveyor stops. The rule checks whether the upstream bin level was low at the moment of the stop. If yes, and the stop lasted under three minutes, it codes feed starvation rather than a mechanical fault. That single rule saves an operator a decision several times a shift, and while 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 do delay accounting rules decay?
A hardcoded rule tree decays quietly. The report keeps looking healthy while the numbers underneath drift.
The plant changes and the rules do not. A circuit gets debottlenecked. A crusher is swapped for a type that fails differently. A new ore source arrives with hardness the original rules never anticipated. Each change invalidates a branch of the tree. Fixing it needs someone with Ampla configuration access, an understanding of the rollups, and the authority to tell the site this month will not compare cleanly to last month. That person rarely exists. Our guide to Ampla delay accounting covers this drift in more depth.
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. A rule cannot say "probably feed starvation, but check the chute". It commits to one code with total confidence, and when the case is ambiguous it commits confidently to the wrong one.
Multi-signal cases defeat them. When three contributing signals move at once, the number of branches needed grows faster than anyone will write or maintain. The rule file covers common cases and dumps the rest into a catch-all "other" or "unclassified" code. That bucket is where the truth about a plant's losses usually disappears.
Free text is ignored. When an operator overrides the auto code and types a note, that note is often the most honest data on site. A C# rule cannot read it, so it never learns that operators keep writing "chute blocked again" against events it insists are feed starvation.
Where does a trained model beat the rules?
A model trained on the site's own historical coding does the same job from the same inputs, with three differences that matter.
It handles fuzzy, multi-signal cases. A classifier trained on thousands of past events learns combinations nobody would write as rules. It weighs bin level, motor current, upstream and downstream state, time of shift and duration together, and returns a most likely code with a confidence score. High-confidence codes flow through. Low-confidence ones are flagged for a supervisor, which is exactly the queue that deserves their attention.
It reads the free text. A language model can take the operator's note, "chute blocked again after the feed change", and use it as a signal alongside the tag data. The comment field becomes an input instead of dead weight in the database.
It keeps up with the plant. When the plant changes, you retrain on recent events instead of rewriting a condition tree. The model absorbs new failure modes from the coding operators are already doing. Drift becomes a retraining schedule that someone actually owns.
| C# rule tree | Trained model | Impact | |
|---|---|---|---|
| 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 should rules still win in mining delay accounting?
Some reason codes should never be handed to a model, and knowing which ones is the whole skill.
Safety and regulatory classifications stay deterministic. If a stop must be classified as a reportable safety event, an environmental exceedance, or anything feeding a statutory return, you need the same answer every time, traceable to an explicit condition and defensible to a regulator or inspector. A probability of 0.83 is not that answer. These codes belong in an explicit rule or a named human decision. The same reasoning governs any AI touching regulated data, as set out in our note on AI agent governance and human override.
Contractual and commercial boundaries stay explicit. Where a downtime code decides who pays, such as a maintenance contractor's availability guarantee, a take-or-pay threshold or a demurrage clock, the definition must be written down and agreed by both sides. A model that occasionally reclassifies a contractual stop occasionally moves money.
Codes with little history stay on rules. A classifier needs examples. A new circuit, a failure mode that has happened four times, or a code introduced last month has too few coded events to train on. Rules cover the cold start until history builds.
What kind of classification is it?
- Feeds a safety or statutory reportKeep it on explicit rules or a named human decision
- Determines who pays under a contractKeep it explicit and agreed
- Fuzzy, multi signal, lots of historyStrong candidate for a trained model
- New code or rare event, little historyRules now, revisit once history builds
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 where the line between them sits, and that line is specific to your plant.
What does the model need before it will work?
A classifier is only as good as the data foundation under it. If these three things are not in place, fixing them is the real project.
- Coding history worth learning from. If past codes are the output of a decayed rule tree and rushed overrides, the model learns to reproduce those mistakes. You need a period of reasonably coded events, or a cleanup first.
- Asset context. The classifier needs to know the event happened on the secondary crusher, which sits in the crushing circuit, which feeds the mill. A well-maintained equipment hierarchy, such as one built on PI Asset Framework or an equivalent, is the difference between a model that generalises and one that memorises.
- Named, trustworthy tags. Bin levels, motor currents and states have to be the right tags, correctly named and reliable. If SCADA tonnes never reconcile against the historian and ERP, as covered in when SCADA and your ERP disagree on tonnes, the classifier will simply learn the discrepancy.
- Weeks 1-2Assess the historyPull the coded event history, measure how clean it is, find the codes worth automating
- Weeks 3-4Fix the foundationClean the asset hierarchy and confirm the input tags are named and trustworthy
- Weeks 5-7Train and run alongsideTrain on history, run the model beside the existing rules without writing codes, compare
- Week 8+Cut over selectivelyMove the fuzzy high volume codes to the model, keep safety and contractual codes on rules
Running the model alongside the rules is the step people skip and regret. Before it codes anything that reaches a report, let it run silently for a few weeks and compare its answers to what operators actually chose. That comparison shows which codes it is ready for, and it builds the trust a supervisor needs before letting a model touch their numbers.
What is the value of AI delay classification?
Anyone quoting a headline percentage without seeing your data has made it up. The value shows up in three places, and the size of each depends on your plant.
- Supervisor time returned from coding leftoversHours per shift
- Losses moved out of the 'other' bucket into real causesBetter decisions
- Classification that keeps up with plant changesNumbers stay trusted
The last one matters most. Delay accounting stops driving decisions when people stop trusting the numbers, and they stop trusting them because classification drifted away from the plant. A model that retrains keeps the numbers connected to reality. Everything downstream depends on that: the Pareto, the loss attribution and the historian data flowing into Power BI.
Getting the line right for your plant
Auto classification is a real improvement when scoped honestly and a liability when sold as a wholesale replacement for judgement. The work is deciding, code by code, which classifications are ambiguous and high-volume enough for a model, which 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. It rests on understanding both the OT data and the reporting obligations on top of it, which is why the starting point is always your actual coding history and asset model.
How Solve8 can help
Our consultants and engineers work at the join between plant data and the decisions it supports, vendor neutral on tooling. We start with your reason code tree, coding history and asset model before anyone writes model code, through our mining and manufacturing data practice and custom AI development. Talk to us about where a trained classifier would earn its place on your site.
