Direct Block Scheduling — Schedule the Orebody, Not the Pushbacks You Drew First

Get the extraction sequence and the cut-off policy right and you can move project NPV by tens of percent without touching the resource, the price deck or the plant. The strategic open-pit schedule is the single largest lever on the value of a mining asset — and for thirty years the industry has pulled that lever the same way.

You optimise an ultimate pit, generate a set of nested shells by revenue-factor analysis, and bin those into pushbacks (stages) that a scheduler then sequences. Modern MILP schedulers are genuinely good at that last step, and can mine across several shells at once. But the precedence the scheduler obeys still comes from the shell nesting — a by-product of the price ramp and the binning — not from the block-level slope geotechnics. The shape of the solution space is set before the value is optimised.

Direct Block Scheduling removes the middle. It schedules every block of the deposit directly, constrained only by real geotechnical slope precedence and your real capacities — and every plan ships with a number that says how close to optimal it is.

1. Where the way we’ve always done it leaks value

Why bin at all? Because scheduling every block directly — every block a decision variable across every period — is an enormous integer program, historically beyond what solvers could handle at real-mine scale. So the industry made the problem smaller: collapse the orebody into a few dozen shell-and-bench panels the scheduler can chew. That compression is a modelling convenience, and it costs you in two specific places.

The partition is committed before value is optimised. Shell boundaries come from geometry and a chosen revenue factor — no discounting, no capacity. A MILP does recover some boundary freedom by choosing where to merge fine shells into pushbacks, so with enough small shells it approaches block-level flexibility. But that freedom is only ever as fine as the shells you generated in advance, and it is the same partition for every period and every price case.

Selectivity is only as fine as the bins you commit to in advance. Binning can be rich — twenty or more grade classes spanning different element combinations, not merely ore and waste — and a well-binned model is genuinely selective. But that resolution is chosen once, before value is optimised; it is the same for every period and every price case; and every extra shell and bin enlarges the program the MILP has to solve. Refine the resolution far enough and you converge on scheduling the blocks themselves — which is the tell: that limit is precisely the problem DBS solves directly.

2. What Direct Block Scheduling actually is

DBS schedules every block (or reblocked super-block) of the deposit directly. The only hard constraints are real geotechnical slope precedence — derived block-to-block from the slope regions, not inherited from shell nesting — and your real capacities: mining movement, mill feed, dump space, fleet ramp rates, blend and stockpile limits, period by period. Subject to those, the optimiser chooses any mineable sequence and any cut-off policy that maximises discounted cash flow. No shells. No pre-binned stages.

The enabling idea is to aggregate precedence, not blocks: the block-level slope arcs are projected onto super-blocks that stay provably acyclic, so the problem becomes tractable without merging blocks into fixed-proportion panels — panels mined as a single unit, which surrender the within-panel selectivity that finer binning exists to protect. Stockpiles are scheduled inside the optimisation as active blend buffers — diverted to and reclaimed from to hold mill-feed grade and capacity — not bolted on as a passive low-grade dump.

3. The thing only DBS gives you: a provable bound

The method solves a Bienstock–Zuckerberg LP relaxation of the full block-level problem first. That relaxation is a genuine upper bound on the best achievable NPV of the actual integer schedule — so every DBS plan is reported as a measured gap below a real optimum, not a number with no reference.

This matters more than it sounds. A shell-and-pushback MILP can only bound itself against the binned problem it was given — it has no way to tell you how much value the binning left on the table. A DP cut-off optimiser cannot bound its answer at all. DBS is the only one of the three that can hand you a plan and, in the same breath, tell you it is within a stated few percent of the theoretical best.

4. Field results — a large-scale copper sulphide project

MiningIQ’s DBS engine has been run end-to-end on a large-scale copper sulphide project: a multi-million-block deposit with a decadal mine life, a mill bottleneck, a nine-stockpile blending strategy and a hard haul-fleet constraint. The runs were benchmarked head-to-head against an independent full-MILP plan built for the same operation, with both plans revalued through identical economics so the comparison is apples-to-apples.

Held to the reference plan’s own per-period truck-hour envelope — the fleet build-up, the plateau, and the late-life wind-down as trucks retire — the DBS schedule kept 26 of 27 mining years at or under cap, several packed to it exactly, the way a fleet is actually run. Stockpile physicals matched the reference almost exactly (83 Mt banked and reclaimed against its 84), every block was scheduled with none stranded, and the whole solve ran on burst cloud in under an hour.

5. DBS and a full MILP are better together

Where does a full-blown commercial MILP scheduler sit against this? We do not position DBS to replace it. Standalone and given unlimited time, a full MILP keeps a real — but single-digit — edge: on the benchmark above it finished a few percent richer than DBS under identical fleet and economics, because global integer optimisation re-times whole pushback chains at once. That is a genuine strength. The right way to use it is with DBS, not instead of it.

DBS feeds the MILP better iterations. The classic pipeline hands a MILP static shells — units drawn by geometry and a revenue factor before value was seen. DBS produces something better to feed it: a block-level, value- and time-aware schedule, each year’s production a real, selectivity-preserving increment. Hand those increments to the MILP as its starting units and sequence, let it polish to global optimality, feed the result back, and iterate. DBS-fed-MILP beats shells-fed-MILP, because the units the solver optimises already respect the value-optimal order rather than a static price ramp. DBS is the fast, integrated front end; the MILP is the optimality polish; the loop between them lands higher than either alone.

And one thing only DBS can do in that partnership. As our companion paper Risk, Measured sets out, the defensible object is not a single plan but a distribution — which requires the whole chain, schedule included, to re-run under every scenario. A full MILP is a separate, licensed desktop tool a planner drives by hand; it is re-run plenty while refining a base case, but each solve takes hours and it sits outside the cost and financial models, so it cannot be wired into an automated risk loop across thousands of coupled price worlds. DBS lives inside the same live database, the risk engine calls it directly as one coupled step, and it solves in under an hour — so the schedule itself re-optimises under each sampled world, automatically, each plan carrying its own bound. The MILP polishes the committed plan; DBS carries the distribution.

Use them together: DBS proposes value-aware, block-level units and carries the risk distribution; a full MILP polishes the committed plan to global optimality. One perfect base case, and a defensible distribution of real plans around it — not one or the other.

6. Why now — a decade-long goal, finally shippable

If this is so clearly better, and the theory has existed for years, why has a workable, scalable DBS been out of reach until now? No single thing unlocked it — several had to mature at once.

• The maths got solved. Bienstock & Zuckerberg (2010) introduced a decomposition that solves the LP relaxation of exactly this problem efficiently; Rivera Letelier, Espinoza, Goycoolea & Moreno (2020) made it practical. That published lineage — the same authors who founded Alicanto Labs, whose engine sits under Deswik.GO — made a provably near-optimal block schedule computable rather than theoretical. MiningIQ is built on it.
• Max-closure pricing got an order of magnitude faster. Modern pseudoflow / parametric max-flow in C++ moves the inner min-cut loop from “overnight” to “over a coffee.” We reuse the same fast max-closure engine we built for pit limits.
• Open solvers caught up. The integer refinement that once needed a five- or six-figure commercial licence is now done at production quality by the open-source HiGHS solver — no licence wall.
• Cloud changed the economics of the solve. A full-resolution solve is memory-hungry and bursty. We spin up a very large instance on demand, memory-map the tens-of-gigabytes arc files rather than load them whole, run the solve, and tear it down — dollars of compute, not capex on a workstation idle 95% of the time.
• Reblocking and warm starts made it interactive. Reblocking collapses millions of blocks into tens of thousands; warm-started re-solves turn a re-run into seconds when only a price or a capacity changes — which is what makes a slider-driven “what if copper is lower?” workflow feel live.

It isn’t that anyone finally had the idea — it’s that the algorithm, the solvers and the cloud all became good enough in the same year.

7. The limits

Every method has boundaries. Here are this one’s, drawn plainly — a technical audience trusts a tool more when it knows where the tool stops.

• Full-resolution exact DBS is not sub-second. Nobody’s is. The realistic workflow is interactive at reblocked resolution, with a full-resolution exact refine on commit. The commercial tools work the same way.
• A full MILP keeps a few-percent edge on a single deterministic plan. Global integer optimisation re-times whole chains at once. That is a reason to run the two together — DBS feeds value-aware units into the MILP’s polish — not a reason to pick one; and it is DBS, not the desktop MILP, that runs inside the automated risk loop.
• Mineability is constraints, not magic. Contiguous faces and fleet rate-ramp caps keep the dig buildable, but a strategic DBS is a strategic tool — it does not design the physical access ramps or haul roads, and is no substitute for detailed short-term design.
• Garbage in, garbage out. DBS optimises harder against the block model, slope regions and cost model — which makes getting the inputs right more important, not less.