Grade Control and Mine Reconciliation Software: Why the Monthly Factor Is a Number Without a Cause

Why the monthly reconciliation meeting solves nothing

Third Tuesday of the month. The mine call factor came in at 0.93 again. Technical services presents a spreadsheet with tabs going back four years, the mill superintendent says his weightometer is calibrated, the grade control geologist says the dig lines were followed, and the mining engineer says the survey pickup was late so the depletion is in the wrong month. Everyone is partly right. The meeting ends with an action to investigate, and next month the number is 0.94 and the same conversation happens.

The reason it never resolves is structural. Reconciliation compares five measurements of the same rock, taken by five departments with five different definitions, and the differences between those definitions are usually larger than the discrepancy being investigated. The resource model reports in situ dry tonnes at a modelled bulk density. Grade control reports on a different block size after a different estimation pass. Survey reports volume, which becomes tonnes only after somebody applies a density that may or may not be the model's. The fleet management system reports truck loads in wet tonnes, or in nominal payload if the onboard scales are drifting. The mill reports dry tonnes through the weightometer with a moisture correction, sampled at a different frequency. Nobody is lying and nothing reconciles.

The money at stake is why groups fund this properly. A persistent few percent between the model and the mill is real metal, and at a mid tier operation it is a material number every year. More importantly it is unattributable, which means you cannot decide whether to spend on more grade control drilling, better dig line marking, ore loss controls at the digger or scale calibration, because you do not know which of those is costing you. The value of a reconciliation build is not the factor. It is knowing which step produced it.

Problem 1: five sources of truth that measure different things

Before any software helps, the definitions have to be pinned down, and that is a technical services decision rather than a development one: wet versus dry, in situ versus broken, which density applies where, how moisture is measured and at what point, and what the boundaries of a reconciliation period actually are when a stockpile spans the month end.

Where a build must earn its keep is by refusing to let those definitions be implicit. Every quantity in the system carries its basis, and conversions are explicit and logged. If a survey volume becomes tonnes using a density of 2.68, that density is recorded on the record with its source. This sounds pedantic until the first time a factor moves because someone changed a density assumption in a spreadsheet cell and nobody could see it. Datamine Reconcilor is genuinely purpose built for this problem and handles the framework well, provided your data lives in that ecosystem and your factor definitions fit its structure. Micromine and Hexagon MinePlan are strong planning and modelling suites where reconciliation is an adjunct rather than the point. The friction for most operations is not the maths, it is that half their inputs live in systems those tools were never intended to read.

Problem 2: the block model moves under you

Reconciliation compares against a model that is itself a moving object. Models get re estimated, reblocked, re domained and revised for new drilling. Depletion happens on a survey schedule that does not match the model update schedule. If your comparison silently uses the current model rather than the model that was current when the ore was mined, your history rewrites itself every time the resource geologist publishes.

The build must version models as first class objects with an effective date, and every reconciliation record must pin the model version it was computed against. Reruns are then reproducible: you can regenerate the March factors exactly as they were reported, and you can also rerun March against the current model deliberately to see what model change alone did to the number. Separating those two questions is exactly what a spreadsheet cannot do, and it is often the first thing that explains a drifting factor.

Problem 3: ore control at the digger is where the metal actually goes

The dig line is marked on a plan, translated to flagging or a screen in the excavator, and then reality intervenes. Blast movement shifts the ore boundary by several metres and the markup was based on pre blast positions. The operator on night shift cannot see the flagging. A truck tips to the wrong stockpile because the dispatcher was busy. Each of those is ore loss or dilution, and none of them is recorded anywhere that reconciliation can see.

What a custom build must include is a destination record per load carrying the source polygon or block, the material classification assigned by ore control, the destination as instructed and the destination actually tipped. Once mis tips are visible as a count per shift rather than as an anecdote, they get managed. Where blast movement monitoring is in use, the moved dig lines have to be the ones the digger and the reconciliation both use, otherwise you are comparing a plan nobody executed against an outcome nobody predicted. This is also the highest value integration point with a fleet management system, and it is often the only thing you need out of that system for reconciliation purposes.

Problem 4: samples and assays arrive late and unmarked

Grade control depends on sampling, and sampling depends on a laboratory. Turnaround time decides whether a dig line is based on assays or on geology. Quality control samples, meaning standards, blanks and duplicates, decide whether the assays are trustworthy at all, and at many sites the quality control review is a monthly spreadsheet check that happens well after the ore has been mined and milled.

The build should ingest laboratory results directly, evaluate quality control samples automatically as each batch arrives, and flag a failed standard within hours rather than weeks, because a failed batch that has already driven dig lines is an expensive problem discovered late. Sample chain of custody from collection to result should be a record, not a courier docket. For operations reporting publicly under JORC or NI 43-101, having that chain in a system rather than in a folder also makes the competent person's or qualified person's job substantially easier at year end.

Problem 5: the factor arrives without a cause

Producing a number is the easy part. The output that changes behaviour is an attribution: of the 7 percent gap, roughly this much is explained by mis tipped loads, this much by the difference between survey depletion timing and model depletion, this much by stockpile balance movement, this much by scale drift evidenced by the payload distribution shift on 12 trucks, and this much remains unexplained. The unexplained residual is the honest headline, and it should shrink as instrumentation and discipline improve.

Getting there requires the daily version, not just the monthly one. A monthly factor is a post mortem. A daily factor with attribution is a control system, and it means a scale drifting on three trucks is caught in a week instead of at quarter end. This is also the one place where machine learning is worth funding here: anomaly detection over payload distributions and assay distributions surfaces instrument drift and sampling bias earlier than a scheduled calibration will. It is a narrow, testable use, and it is far more valuable than any grade prediction model sold on top of a data set this messy.

What this costs and how long it takes

Across the 2,000 plus projects Digital Heroes has delivered, this is the honest shape. A reconciliation engine, meaning ingestion from the resource and grade control models, survey, fleet and mill historian, explicit basis and conversion handling, versioned model pinning, and monthly plus daily factors with attribution, runs $70,000 to $150,000 and ships in 10 to 16 weeks. A full platform adding ore control markup and digger destination capture, laboratory ingestion with automated quality control evaluation, stockpile balances by material type, and multi site rollups runs $180,000 to $420,000 over 6 to 12 months.

What drives the price up specifically here: the number of source systems and their openness, since a plant historian, a laboratory system and a mine planning package are three different integration problems. Stockpile modelling, because tracking grade through rehandled stockpiles with partial reclaim is genuinely difficult and every site does it differently. Multi commodity or multi site scope, where factor definitions must be normalised before they can be compared, which is a technical services workshop rather than a coding task. And underground scope, since development and stope reconciliation carry their own logic that does not transfer from open pit.

What keeps it down: agree the definitions before the project starts. The single biggest cost driver we see is a team that begins building while the meaning of a tonne is still contested between departments. Two workshops in advance saves more than any technology decision.

Build versus buy, and when buying is the right call

Buy if you are a single site, single commodity operation already standardised on Datamine, with disciplined data and a stable factor framework. Reconcilor is purpose built, it will get you there faster, and we would tell you that before quoting. The same logic applies if you are already committed to Micromine or Hexagon MinePlan and your reconciliation needs are modest relative to your planning needs.

Build when two or more of these are true. Your factors are computed in a spreadsheet only one person can run, and that person is not junior. Your inputs live across systems your modelling suite cannot read, particularly a plant historian or a laboratory system. Your factor has been persistently off for more than two quarters with no attributed cause. You operate several sites whose factor definitions differ enough that group comparison is currently meaningless. Or you want daily reconciliation rather than monthly, which is where the operational value actually sits and which is beyond what most packages are configured to deliver.

How to choose a developer for reconciliation software

Ask them to whiteboard the quantity model before you sign anything. The right answer has every quantity carrying its basis, meaning wet or dry, in situ or broken, and the density and moisture assumptions used to convert it, with those assumptions stored as data rather than embedded in code. A developer who treats tonnes as a single number will produce a system that argues with the mill in a different way than the spreadsheet did.

Ask how they will version the block model and pin historical reconciliations to it. If reruns are not reproducible, the system cannot be used in an audit or in a public reporting context, which removes most of its value.

Ask what they have integrated. A plant historian over OPC UA, a laboratory information management system and a mine planning file format are three distinct problems, and the answer should name specific products and specific difficulties rather than describing integration in general terms.

Ask who owns the code and the data, and get it in writing before kickoff. You should own the repository, the cloud accounts and the right to hire anyone else to continue the work. At Digital Heroes the code is yours from the first commit. Reconciliation history is evidence supporting public reporting, and it should never sit in a system you cannot get it out of.