The Data Advantage: Why AI in Mine Planning Lives or Dies on Data Access

Every mining software vendor is now racing to add AI to their product, and they all face the same challenge: the hard part of AI in mining was never the model. It’s the data the model is allowed to see.

Large language models are, for practical purposes, a commodity. The frontier capabilities that matter for mine planning — reading a table, reasoning over a scenario, writing a defensible report — are available to anyone. What is not a commodity is feeding that model the block model, the optimisation run, the haulage profile, the cost build-up and the financial model together, live, and correctly attributed to a single project.

An AI assistant is only ever as good as the data it can reach. Point a brilliant model at a locked filing cabinet and you get a brilliant guess. Point an ordinary model at the full, structured planning record and you get genuine analysis. In mining, almost everyone has built the filing cabinet.

The mining industry spent thirty years perfecting tools that lock data inside files. AI rewards exactly the opposite: data that is connected, queryable and live.

The captive-data problem

Conventional mine planning runs on a chain of desktop packages, each owning its own slice of the truth in its own proprietary format:

• The geologist’s block model sits in one vendor’s binary file.
• The pit optimisation run lives in another tool’s project folder, with results exported to spreadsheets.
• The schedule is a third package, again file-based, again proprietary.
• The cost model is a spreadsheet on someone’s laptop.
• The financial model is a different spreadsheet, owned by a different team, reconciled by email.

Each of these is a silo. The data is captive — technically inside a file you nominally own, but practically unreachable by any system other than the one that wrote it. Getting a coherent picture across the whole planning path is a manual exercise in exports, re-keying and version reconciliation. It takes days, it goes stale immediately, and it is exactly the work nobody has time to do.

This is fine — barely — for human workflows, because humans tolerate friction. It is fatal for AI. You cannot give an assistant “real-time access to the mine plan” when the mine plan is fourteen files in five formats across three machines. The integration that AI needs simply does not exist, and it cannot be retrofitted by adding a chatbot to any single one of those tools — that chatbot can still only see its own silo.

A useful accident

MiningIQ and MineCost were not designed, originally, as an AI platform. They were built to solve a more mundane and more painful problem: keeping the entire mine planning path — geology, optimisation, scheduling, cost and finance — in one live, cloud-based, project-secured database instead of a scatter of files.

The motivation at the time was integration and trust: one source of truth, every number traceable to its inputs, every change versioned, every project walled off from every other. That design decision was about getting rid of spreadsheet chaos.

But in solving that problem, the platform incidentally built the one thing modern AI most needs and almost no mining system has: a single, structured, secured, queryable representation of the complete plan. The block models, the optimisation runs, the cost models and the financial models are not exported, re-keyed copies — they are the live records, related to each other, in one place.

We built a connected database to kill spreadsheet chaos. It turned out we’d built the ideal substrate for sandboxed AI — before AI made it the question it now is.

That is the accident. The data architecture that made the platform good at planning is the same architecture that makes it well-suited to AI. A captive, file-based product has to re-architect to reach this point. MiningIQ and MineCost are already built this way.

What the architecture actually enables

Because every artefact in the planning path is a related record in one secured database rather than a file in a silo, an AI agent can be granted scoped, read-only access to the entire path at once — and reason across it.

The agent doesn’t see a chatbot’s narrow view of one module. It sees the chain — and crucially, the relationships in the chain. It can trace a movement in NPV back through the financial model, into the cost build-up, back to the schedule, into the optimisation run, and down to the block model assumptions that drove it. That traversal is trivial when everything is one related dataset. It is effectively impossible when everything is a separate file.

Sandboxed AI reporting and assistance agents

With full-path data access, the agents stop being novelty chatbots and start being genuine analysts. A few of the things that become possible — in real time, against live data:

Whole-plan analysis on demand

“Why did this scenario’s NPV drop versus last week’s run?” The agent reads the current and prior financial models, identifies the deltas, walks them back to the cost and schedule changes that caused them, and explains the chain — instead of a human spending two days reconciling spreadsheets to arrive at the same answer.

Real-time, defensible reporting

Board packs, technical reports and reconciliations generated directly from live records, every figure traceable to its source. No export-and-reformat cycle, no risk that the report disagrees with the database, because the report is the database, narrated.

Cross-discipline sanity checks

The agent can flag where the cost model’s assumed mining rate is inconsistent with the schedule, or where a financial-model commodity price no longer matches the optimisation shell it was run against — the cross-silo errors that today only surface in audits, if ever.

Scenario interrogation in plain language

Planners and executives ask questions of the plan directly — “what’s our exposure if processing cost rises 10%?” — and the agent computes against the real cost and financial models rather than guessing from a summary slide.

From analysis to action: agents that update the plan

Reading the whole plan is powerful. Being able to change it — safely, traceably, in the same secured database — is what turns the assistant from analyst into planner.

Because the agent has write access to the real, live records (not a copy, not an export), it can carry out a multi-step planning operation that today consumes a skilled engineer’s afternoon — and it can do it from a single plain-language instruction. The agent doesn’t simulate the work in a sandbox spreadsheet; it operates the actual MiningIQ and MineCost engines, on the actual project data, with every step recorded as a new, named, auditable scenario.

Consider a real sensitivity request, spoken the way a planner would actually phrase it:

For a captive, file-based toolchain this is a day of careful, error-prone manual work across four or five disconnected packages. For an agent with full-path access to one live database, it is a single orchestrated sequence:

1. The planner asks in plain language — no clicking through five packages, no manual re-keying between them.
2. Duplicate Scenario A → Scenario B in the cost model, creating a new, named, isolated scenario. [writes]
3. Update the copper price in Scenario B from $10,000/t to $12,000/t and recalculate NSR for the run against the live block-model grades. [writes]
4. Raise fuel cost from $1.00/L to $1.20/L and run the cost model, propagating the change through every cost line that depends on diesel. [writes]
5. Create a linked financial-model scenario from Scenario B and return the unlevered NPV. [writes · reads]
6. Extract the average unit costs for ore mining and waste mining from the run. [reads]
7. Build a new pseudo-flow run using those unit costs, the updated Cu price and the recalculated NSR. [writes]
8. Compare the new run against the previous one and return the delta as a structured sensitivity — NPV, unit costs and NSR side by side. [reads]
9. Cut 5 cross-sections through the block model that informed the pseudo-flow, rendering Cu grade in the blocks with each section drawn through both the prior and the new run. [reads]
10. Email the sections to the planner on completion — the finished output delivered, not just left on screen. [acts]

Every one of those steps already exists as a capability in the platform. What changes is that the planner no longer has to perform them by hand, in the right order, across separate tools, without dropping a value in transit. The agent does it in one pass, and — because it all happened inside the one secured database — every intermediate scenario is preserved, named and fully traceable. Nothing was exported, nothing was re-keyed, and the result reconciles with the source by construction.

The same data access that lets AI explain the plan lets it build the plan — duplicate a scenario, reprice it, re-run the cost and financial models, and hand back a sensitivity, all from one sentence.

Building risk into the outcome — not bolting it on

Risk is the most topical question in mine planning today, and the hardest to do honestly. A single-point NPV is a forecast that pretends the future is known. The real question executives and financiers ask is: how wide is the range, and what drives the downside?

Answering that properly is exactly where whole-workflow data access stops being a convenience and becomes a precondition. Uncertainty in a mine plan doesn’t live in one place — a swing in the copper price changes NSR; a change in mining rate changes unit costs and the schedule; a capital revision changes the cashflow. To put a defensible probability distribution around the financial outcome, the risk engine has to see and propagate uncertainty through the entire chain at once. A risk model that can only see the final NPV line can do nothing but wobble that one number in isolation — which is not risk analysis, it is decoration.

Because MiningIQ and MineCost hold the whole plan in one connected database, the platform runs a genuine Bayesian risk engine across it. Rather than a hand-waved ±10% on the bottom line, the user defines uncertainty where it actually originates — as probability distributions on the real input parameters:

Each sample is a complete, internally consistent version of the plan — prices, NSR, costs, schedule and cashflow all moved together — not an independent jiggle of one cell. That coherence is only possible because every input is related in one model. The output is a true distribution of NPV with its percentiles, and a clear read on which inputs are actually driving the spread.

And the AI can drive the risk engine directly

Because the risk engine is part of the same data platform the agents already operate, risk analysis becomes conversational. The planner doesn’t hand-build flex tables across forms — they describe the uncertainty and the agent configures the priors, runs the sampling, and interprets the result:

The agent sets those distributions as the engine’s priors, runs the Bayesian sampling across the full model, and returns the NPV distribution with the dominant risk drivers ranked — the kind of answer that normally takes a risk specialist a day to assemble, produced in one pass against live data. Risk stops being a separate study done late and becomes something you can interrogate continuously, as the plan evolves.

Why captive systems can’t simply follow

The obvious competitive response — “we’ll add AI too” — runs straight into the captive-data wall. A chatbot bolted onto a file-based package inherits the package’s blindness. The comparison is stark:

This is not a feature gap that a sprint can close. It is an architectural gap. To give AI the whole plan, a captive vendor would have to abandon the file-and-module model their entire product is built on, migrate decades of customers off proprietary formats, and rebuild around a live integrated database. That is a multi-year, bet-the-company rewrite — and it ends with them arriving where MiningIQ already stands.

Security and isolation are the enabler, not the obstacle

Open data access raises an immediate and correct concern: a mine plan is among the most commercially sensitive data a company holds. The reason this architecture is safe to point AI at is that isolation was built in from the start, not added later.

Every project is fully secured and walled off. An agent operates inside a sandbox scoped to a single project — it can see and change that project’s records and nothing else. There is no path for one client’s data to inform another’s analysis, and no path for an agent to reach outside its assigned project. The same per-project security model that protects the data is precisely what makes it safe to give an AI agent the full breadth of one project’s plan.

Write access is held to the same boundary, and made safe by the database itself rather than by trusting the agent. Every change the agent makes lands as a new, named scenario — it duplicates and re-runs rather than overwriting, so the original is never at risk. Every action is versioned and auditable, so a human can see exactly what the agent did and roll it back. And because the agent operates the platform’s own engines through the same validated paths a user would, it cannot put the data into a state the application itself would reject. Full access within the project; nothing destructive, nothing silent, nothing beyond the wall.

The window of advantage

The lesson generalises beyond mining: in every industry, the winners of the AI era will be whoever already holds their domain’s data in a connected, queryable, secured form. The model is commoditised; the data substrate is the moat.

Mining’s incumbents built the opposite — and they built it deliberately, because file-and-module was the right design for the desktop era. That legacy is now the thing standing between them and useful AI. MiningIQ and MineCost, by solving an integration problem years ago, happen to hold the substrate the whole industry now needs.

The model is a commodity. The data substrate is the moat. We already own the substrate.

For mining teams, the practical takeaway is simpler: the value of AI in planning is decided by the data it can reach, and that is a property of the platform your plan lives on — not of the chatbot bolted on top. On MiningIQ and MineCost, that substrate already exists. Full-path, sandboxed AI analysis and action isn’t a roadmap promise; it’s a direct consequence of how the platform was built.