A pilot takes a single priority decision — a blast design, a stockpile draw, a maintenance call — and proves whether connected evidence changes the answer. Narrow on purpose, and reviewable by the people who make that decision today.
These are the kinds of decisions a pilot is shaped around. Each one is a live operating question with a downstream consequence — pick the one that is costing you most.
Compare a compliant design against fragmentation, crusher load, grinding energy, and recovery before it is fired.
See the full use case →Operational controlWeigh grade, hardness, age, and routing flexibility against plant stability and product quality.
See the full use case →Operational controlFrame asset condition against production exposure and the operating windows actually available.
See the full use case →Business and governanceMake the trade-off between kWh/t, recovery, throughput, and cost explicit before it is committed.
See the full use case →Your decision is not on this list? That is a normal starting point — the pathway below is the same regardless.
A stage is finished when its exit condition is met, not when a duration elapses. Stage five is a decision point, not a foregone conclusion — a pilot that ends with a documented reason to stop has still done its job.
Agree the one decision the pilot has to improve.
From your side: A working session with the decision owner and technical services.
Name the decision, the operating question behind it, the constraint it runs into, and the measure that would show it improved. Everything after this stage is scoped to that decision only.
Stage is done when: A signed-off decision scope: one decision, one owner, one success measure.
Stand up the decision view on your data.
From your side: Read-only extracts from the systems that hold the signals.
Map the available signals to material, asset, time, and operating state. Configure the models and KPIs the decision depends on, and build the baseline operating view that alternatives get compared against.
Stage is done when: A baseline view your team recognises as their operation, with gaps stated.
Let site experts attack the assumptions.
From your side: Review time from the engineers who own the decision today.
Compare scenarios against the baseline, back-test against historical periods where the outcome is known, and put the assumptions, sensitivities, and confidence ranges in front of the people best placed to challenge them.
Stage is done when: An evidence pack the site is willing to defend, including where it is weak.
Put the workflow into a routine that already exists.
From your side: A decision forum or review meeting to attach the workflow to.
Fit the decision workflow to an existing review cadence rather than creating a new one. Assign the owner, the reviewer, and the record the decision leaves behind.
Stage is done when: The decision gets made this way without OreNeda in the room.
Extend only once the first decision holds.
From your side: A decision on whether the evidence justifies going wider.
Extend to adjacent decisions, further value-chain modules, or additional sites — reusing the mappings, models, and governance already proven. This stage is a choice, not an assumption.
Stage is done when: A scoped second decision, or a documented reason not to continue.
A pilot fails for predictable reasons: no accountable owner, no history to test against, or no expert willing to challenge the output. These are the entry conditions, stated up front.
Someone accountable for the outcome who can say whether the pilot improved it. Without a named owner, a pilot produces analysis nobody has to act on.
Typically fleet management, dispatch, plant historian, laboratory, block model, planning, maintenance, or energy data. Extracts are enough — no live integration is required to run a pilot.
Enough past periods to back-test against, including periods where the outcome was poor. A pilot validated only on good months proves very little.
The engineers and metallurgists who make this decision today. Their challenge is what turns model output into evidence anyone will act on.
Not a transformation programme. Four artefacts that stay useful whether or not the pilot continues — including the record of what the data could not support.
The decision, its boundary, the systems in scope, the success measure, and the named owner.
Your signals, time windows, and definitions in one view — including an explicit list of the gaps found.
Operating alternatives ranked against the agreed KPIs and constraints, with the trade-offs visible.
Assumptions, model confidence, sensitivities, constraints, and review notes, in a form built to be challenged.
OreNeda does not replace fleet management, historian, planning, automation, or specialist modelling platforms. The value is in connecting their signals into a decision workflow someone can review and sign.
A bounded way to test one high-value decision before committing to broader deployment.
A decision layer that sits above existing systems rather than competing with them.
A structured route from models and site data to recommendations that survive review.
A staged validation path with explicit scope, evidence, and adoption milestones.
The first conversation covers the decision, its owner, the systems holding the relevant signals, and the history available to test against. If a pilot is not the right next step, that is a useful answer too.
Validate a decision workflow.
Request a demo