Today in short

• The shaft test. On the six mines where the shaft helped the MILP most, the MILP goes from 82% → 95% → 100% of full-information NPV (blind → partial → full). The LLM stays at 83% → 81% → 86%, below greedy (87%) in every row. More information did not help it.
• Why the paper looked closer. The paper’s 27-block mine is easy for greedy (greedy reaches 93 to 98% of that MILP), the MILP there was solved to a 5% gap, and the simulator has changed since. Today’s mines were built to be hard for greedy.
• What the logs show. The LLM does use the shaft data, but it forgets what it has mined (it keeps only the last 3 calls), misreads the precedence rule, and after a rejected reply falls back to 1 t steps.
• Fix. A compact live mine state in every prompt, precedence written out, and one line explaining that partial extraction saves nothing.
• Result on decoy. The nibbling is gone (21 actions instead of 61). Blind and partial still equal greedy, but full reaches 9,793, 93% of the MILP and 42% above greedy.

The shaft test

The question was simple. If the LLM gets the shaft’s estimated grades (partial) or every grade (full), does it get closer to the MILP?

For the test set I used the six mines where the shaft helped the MILP most: waste cover, decoy, three random mines and the 3D flat seam. On the six 27-block 3D mines from the earlier runs the shaft added almost nothing even for the MILP (gains of 0.01 to 11), so they could not show anything.

The shaft data reaches the LLM by coordinates. Each extraction action carries its block’s (x, y, z), and the system prompt lists the drilled blocks the same way, for example (2, 0, 1) ~0.85. In full, the prompt lists every block’s grade instead.

Totals over the six mines (% of full-information MILP)

Greedy is the same in every row because it only ever chooses among blocks it can mine now, and those are always revealed.

Per mine

The MILP turns the shaft into 13 points of NPV. The LLM stays at greedy’s level, and in partial it is even slightly worse.

Waste cover, step by step

Waste cover shows how information can hurt. The surface is all 0.1 grade, with richer ore under it (0.6 at the edges, up to 0.9 in the middle).

In partial the LLM followed the drill data toward the 0.85 ore in the middle. But a middle block needs three surface blocks removed where an edge block needs two, and it also stripped a block that did not help. Revenue started one period later, which costs more than the higher grade earns back. The blind run took the first block in the list, which happened to be the cheapest way in.

Why the paper got close to the MILP

My earlier paper (Sim2Schedule) reported the LLM at 94.5% of the MILP. Three things explain the difference.

• The mine is easy for greedy. Almost every top-layer grade is rich, so following the immediate value already gets close to the optimum.
• The MILP was solved to a 5% gap, so the true optimum could be up to 5% higher.
• The simulator changed after the paper (the greedy rule and proportional processing). Greedy on the same mine went from 19,062 to 20,277.

Today’s mines were designed so that greedy fails. On those, an LLM that behaves like greedy is far from the MILP. That matches the paper’s own observation that without context the LLM falls back to greedy-like behaviour.

What the logs show

I read the waste-cover partial run call by call. The LLM clearly uses the drill data, since every call reasons about reaching the 0.85 block. Then it goes wrong in four ways.

1. It forgets what it has mined. In call 1 it mines block 3 fully. In call 3 it chooses block 3 again: “we should extract block 3 first”. The reply is rejected.
2. It misreads the precedence rule, differently each time. Call 2 gets it right. Call 7 decides “each block at z = 1 touches the block directly above at same x”. Call 8 looks for blocks above a surface block.
3. After a rejection it takes 1 t. “we want to minimize amount extracted to reduce cost… choose 1 ton. That is best.” Every extraction shows a loss per tonne, so the smallest amount looks best, even though it only postpones the cost and leaves blocks half-mined.
4. It does not know what ore is worth. “We don’t know processing revenue… maybe processing revenue per ton is high.”

How much it remembers

Each call sends the system prompt, the last 3 prompts with the LLM’s 3 replies, and the new prompt. Anything older is dropped. Retries take history slots too, so after two invalid replies only one real decision is left in view. The model’s own reasoning is never sent back. So “which blocks are done” survived at most three calls.

Two more things in the prompt add to the confusion. max_extractable_tons drops to the capacity left in the period (for example from 50 to 20 for every block), which the LLM reads as every block shrinking. And the original prompt line “a block is only available for processing after it has been fully extracted” is not true in the current simulator, which processes the mined share of a block straight away.

The fix. Live mine state

Three changes, as a new prompt version.

• Live mine state in every prompt, rebuilt from the simulator at each step. Only blocks whose grade is known are listed (in blind, unknown blocks are left out, since the mine size is already given). Each entry is (block, grade, tons left to extract, tons left to process). For example, in partial, (12, '~0.87', 50.0, 43).
• Precedence written out. In the coordinate version, “a block at (x, y, z) can only be extracted after every block at (x + dx, y + dy, z − 1), with dx and dy each −1, 0 or +1 and inside the mine, has been fully extracted.” I checked that this rule matches the simulator’s precedence for every block on four mines. The block-number version keeps the general sentence.
• One line on partial extraction. “Extracting part of a block costs the same per tonne as extracting all of it, but only a fully extracted block unlocks the blocks below it. A period ends only when its mining capacity is used, so extracting less now does not avoid the cost.”

To see whether naming blocks by number or by coordinates matters, I built both versions and ran them on decoy.

Decoy results (block-number version)

The nibbling is gone. The same mine takes about a third of the actions, with almost no invalid replies.

Full reaches 93% of the MILP. This is the first time the LLM moved clearly beyond greedy. Its schedule:

Block 12 sits under surface blocks 4, 5 and 6. With the true grade in front of it and the live state showing progress, the LLM paid for that waste in periods 2 to 4 to open 0.9 ore in periods 5 and 6. Greedy never makes that trade.

Partial tried the same and failed on geometry. It went for block 12 too, and even mined part of block 5 in period 1. Then:

• it worked out the layers upside down: “top layer is z = 1… block 2’s above block is block 9, so block 2 cannot be extracted until block 9 is fully extracted”,
• it thought only block 5 sits above block 12, when 4, 5 and 6 all have to go,
• it misread the state and decided block 12 was already fully extracted.

So in partial the drill data changed its intent, but without block positions it could not work out which blocks to remove. In full, with every block’s grade listed, it got the layout right.

What I take from today

• On these mines the gap to the MILP is about planning, not information. The MILP turns a shaft into 13% more NPV because it plans the whole stripping sequence.
• The LLM failed mainly because it lost track of the mine. Once it can see the live state, it stops nibbling and, with full information, makes a real multi-period trade-off.
• Partial information still needs the geometry to be clear. Five estimated blocks named only by number were not enough for it to plan the route.

Next

• Run the coordinate version on decoy (blind, partial, full). If partial with coordinates reaches block 12 in time, block naming is what held it back.
• Repeat the full run with other seeds before treating the 93% as solid.
• Then run the better of the two versions on the other five shaft mines.

Today in short

• New prompt (actions_value). Same as yesterday’s structure prompt, but each extraction’s value now includes the revenue of the ore it frees this period. That is the same number greedy ranks by.
• The waste-cover failure is fixed. It went from −2,943 yesterday to 2,500 or better for every model. No model walks past the ore any more.
• Five models, 24 runs. Three local (gpt-oss 20B, qwen3 14B, deepseek-r1 14B) and two on Groq (gpt-oss-120b, qwen3.8-27b). 20 of 24 runs land within 0.5% of greedy, 2 are clearly better and 2 clearly worse.
• A bigger model doesn’t help. gpt-oss-120b made the same mistake as the 20B model on yesterday’s prompt, and with the new prompt it matches greedy like the others.
• The LLM has become greedy. Given greedy’s own number, it mostly follows it. Beating greedy will need the LLM to plan beyond one step.

What changed in the prompt

Yesterday’s diagnosis was that the value shown for every extraction (npv_impact_per_unit) was the mining cost alone, −10 / 1.1^t per tonne, identical for ore and waste. Greedy ranks by a different number, npv_delta, which adds the discounted revenue of the ore that extraction makes processable this period (within processing capacity and the blend limits).

The new prompt keeps everything from the structure version and changes only that value. The extraction description gets one extra sentence:

Context: This action incurs a mining cost. Its npv_impact_per_unit also includes the revenue of the ore it makes ready to process in the current period.

The difference on the first decision of the decoy mine:

before: (1, 1, 0.8, 50, -9.09), (1, 2, 0.6, 50, -9.09), (1, 3, 0.0, 50, -9.09), ...
after:  (1, 1, 0.8, 50, 63.64), (1, 2, 0.6, 50, 45.45), (1, 3, 0.0, 50, -9.09), ...

Ore blocks now look worth mining, and waste still shows the bare cost.

Testing a bigger model first

Before changing the prompt, I checked whether a larger model would see past the misleading number on its own. I sent the exact waste-cover decision from yesterday (period 4, ore block 10 next to four waste blocks, all at −6.83) to gpt-oss-120b on Groq, three times at medium effort and once at low effort, and to gpt-oss-20b on Groq for comparison.

All five calls chose waste block 6, amount 1. The 120B model’s reasoning:

“block 10 has ore_concentration 0.6 vs 0.1 for others. However npv impact per unit is same −6.83 regardless of concentration… choose smallest amount: 1.”

So the problem was never the model’s size. The model trusts the number it is given. It also explains the 1 t nibbles seen yesterday. With every extraction showing a loss, “take the smallest amount” looks like the sensible choice.

Results (actions_value prompt, full information)

The missing Groq runs hit Groq’s free daily limit (see below).

• 20 of 24 runs are within 0.5% of greedy, most of them to the cent.
• 2 runs beat greedy. gpt-oss on central cone (+126%) and deepseek-r1 on waste cover (+2.5%). The central cone run took 80 actions, more than any other, so it needs repeating before I read much into it.
• 2 runs fall clearly below greedy, both on central cone. deepseek-r1 (334, −63%) and gpt-oss-120b (673, −25%).
• No model gets near the MILP where planning ahead matters. Central cone, central pipe and waste cover all stay at greedy’s level, well below the MILP.

For comparison, the same two mines across all of the prompts so far (gpt-oss 20B):

Speed

• Groq answers in under a second, but the free tier allows only 8,000 tokens per minute, so the scheduler has to pace itself. That is why Groq ends up at about the same seconds per action as my GPU.
• gpt-oss takes the most actions (66 on average, against 20 to 27 for the others), because it still splits blocks into small pieces. The other models more often take a whole block at once.
• qwen3 14B is the slowest at about 46 seconds per action, because of its long reasoning.

Groq’s daily limit

The free tier allows 200,000 tokens per model per day. The gpt-oss-120b run on central pipe used it up partway through, then got one call through roughly every 12.5 minutes. By step 112 it was still extracting 1 t at a time from the same block, where the local models finished the whole mine in 20 to 30 steps. I stopped it there. On the three mines it didn’t reach, every local model already matches greedy within 0.2%, so the missing runs are unlikely to change the picture.

Moving machines

My supervisor’s machine went offline today, so I moved to another Ubuntu machine. Everything was in GitHub apart from the run logs. Two small changes made the move painless.

• Finished runs are now recognised from results/, which is in git, instead of from the log files, which are not. The batch picked up exactly where it stopped.
• Gurobi is switched off for the LLM runs, since this machine has no academic licence. The LLM and greedy only use the simulator, and the MILP numbers come from my earlier results, so nothing is lost. Greedy reproduces the old numbers exactly, which confirms the simulator is unchanged.

What I take from today

• The right number matters more than the right model. One changed value fixed a failure that neither more prompt text nor a model six times larger could fix.
• Once the LLM is given greedy’s number, it behaves like greedy. That is a sensible floor, but it is also a ceiling for a one-step decision.
• The mines where the MILP wins (central cone, central pipe, waste cover) need several steps of planning, such as stripping waste now for ore two periods later. A value that only looks one step ahead can’t show that.

Next

• Let the simulator take the full amount, so the LLM only chooses the block. This removes the nibbling and should cut the calls, and the tokens, sharply.
• Plan once per period instead of once per step. The LLM ranks blocks or sets a target for the period, and the simulator carries it out. That gives it a chance to plan beyond one step, which is what greedy can’t do.
• Repeat the two runs that beat greedy with other seeds before treating them as real.

Today in short

• Baseline (18 runs). With the current prompt (whole mine state plus action list), the LLM behaves like greedy but is much slower. 9 of 18 runs land within 0.5% of greedy, 8 are clearly worse, and only 1 is clearly better. It never comes close to the MILP with the same information.
• More information doesn’t help it. Full, blind and partial give similar results, and sometimes full is the worst of the three.
• Prompt change 1. Actions only, grade on each extraction. Each call has about 2.6 times fewer tokens and each decision is 1.7 to 2.9 times faster (about 10 s instead of 17 to 30 s). But NPV dropped, badly on the waste-cover mine (−90% vs greedy).
• Prompt change 2. Add a short, general description of the mine structure. The decoy mine recovered fully to greedy level. The waste-cover mine got even worse and finished with a negative NPV.
• The cause. For every extraction, the number the LLM is given (npv_impact_per_unit) is the mining cost only, the same for every block. Greedy ranks by a different number that also includes the revenue of the ore the extraction frees up. The LLM noticed the rich block, then trusted the number and mined waste.

Setup

The loop is simulator → possible actions → LLM picks one → simulator applies it, repeated until the end. All runs used the six 27-block mines from my MILP experiments, with the same shafts, drilling noise and costs, and greedy reproduces my earlier numbers exactly on all six. The model is gpt-oss (20B) running locally, at temperature 0 with a fixed seed.

What the LLM was given in the baseline

Every call contained:

1. A system prompt (the same every call). Its role (“maximize NPV”), what each mine-state entry means (block, grade, tons to extract, tons to process), the two action formats and their amount rules, three rules (“process only after full extraction”, “maximize NPV”, “you do not need to track time”), and the JSON reply format.
2. The current step. Last action, current NPV, period number, the whole mine state and the list of possible actions.
3. History. The last 3 prompts and the LLM’s 3 replies.

What it was never told: revenue and cost per tonne, capacities, the number of periods, the discount rate, the blend limits, and which blocks sit above which. Its own reasoning says so: “processing revenue per ton? Not given… So we cannot compute NPV.”

Baseline results (current prompt, 18 runs)

• It mostly copies greedy. 9 of 18 runs are within 0.5% of greedy, several to the cent. 8 are clearly worse, by 8.5 to 32%. Only central cone blind is clearly better (+186%), and that run also had the most invalid replies (15), so it needs repeating before I trust it.
• It never beats the MILP with the same information, except on waste cover blind and partial. That’s because blind MILP is weak there, not because the LLM is strong. It is still 32% below greedy.
• More information doesn’t help. Central cone gives 726 with full information and 2,574 blind. Waste cover partial is identical to blind even though the shaft shows the rich layer. The LLM seems to decide from the action list and mostly ignore the mine state.
• Speed. 656 actions took about 3.9 hours, roughly 21 seconds per action. MILP and greedy take under a second per mine.

Prompt change 1. Actions only, with the grade on each extraction

Changes from the baseline:

• Mine state removed from every prompt, together with its description in the system prompt.
• Grade added to each extraction action. (1, block, ore_concentration, max_tons, npv_impact_per_unit)
• Processing rule simplified to “choose an amount between min and max”. The LLM isn’t told about grade blending, it only needs an amount within the limits.
• Numbers rounded to 2 decimals (no more 2.239999999999995).

A side effect is that full, blind and partial now produce identical prompts. A block only appears as an extraction action once the blocks above it are mined, and by then its grade is always known. Hidden blocks and shaft estimates only ever appeared in the mine state. So one run per mine is enough for this comparison.

Prompt change 2. Add the mine structure

Same as change 1, plus three general lines in the system prompt. The size comes from each mine, and there is no numbering or layout detail.

Mine Structure:
The mine is a 3 x 3 x 3 (x by y by z) block model.
Precedence: a block can only be extracted after every block touching it in the layer directly above has been fully extracted.
Uncertainty: extracting blocks uncovers the blocks beneath them. The grade of a lower block may be higher or lower than the grade of the blocks above it.

Results on two mines (full)

• Speed. Removing the mine state cut tokens per call from a median of about 2,700 to about 1,000, and each decision got 1.7 to 2.9 times faster. Adding the structure lines slowed it again, probably because the model reasons more and takes more, smaller steps (60 and 78 actions).
• Decoy. Three structure lines were enough to replace the whole mine state. Same NPV as the baseline with a much smaller prompt.
• Waste cover. It got worse with each change.

Why the LLM lost money on waste cover

Waste cover has a poor surface (grade 0.1 everywhere) over a rich middle layer. Period by period, against greedy:

So the LLM stripped exactly the right blocks to reach the ore, the same as greedy. Then it walked past the ore. In period 4 it was offered:

(1, 6, 0.1, 21.0, -6.83), (1, 7, 0.1, 21.0, -6.83), (1, 8, 0.1, 21.0, -6.83), (1, 9, 0.1, 21.0, -6.83), (1, 10, 0.6, 21.0, -6.83)

Its reasoning, word for word:

“All have same cost per unit. But block 10 has ore_concentration 0.6, but cost same? … extraction cost is negative NPV per unit, independent of ore concentration. So choose any. But maybe we want to extract block 10 because it might unlock processing later? But we don’t have processing actions yet. So choose block 6.”

It saw the higher grade and even guessed that block 10 might lead to processing. Then it trusted the number. With a tie, it took the first block in the list, which was waste. No processing action ever appeared to correct it, because 0.1-grade ore is below the 0.4 blend limit and can’t be processed on its own.

The real problem. Two different “values”

The LLM and greedy rank actions by different numbers.

• What the LLM sees (npv_impact_per_unit). For an extraction it is only the discounted mining cost, −10 / 1.1^t per tonne. In period 4 that’s −6.83 for every block, waste or ore.
• What greedy uses (npv_delta). The same mining cost plus the discounted revenue of the ore that extraction makes processable this period, if processing capacity and the blend limits allow.

For the period 4 choice above (approximate, worked out from the code):

For processing actions the two numbers are effectively the same, which explains why the LLM matches greedy so closely on mines where processing drives the choices. It also means the LLM’s greedy fallback, which ranks by npv_impact_per_unit, can’t tell ore from waste either.

What I take from today

• A smaller prompt is much faster and loses nothing when the obvious move is the right one (decoy).
• Describing the structure isn’t enough when the LLM has to choose between blocks that only differ in what they lead to. The number it trusts says they’re all the same.
• The LLM isn’t confused about mining. It is misled by the value it is given. Fixing that number is more important than adding more text.

Next

• New prompt version. Actions only, with each extraction’s value including the ore it frees up (the same npv_delta greedy uses) instead of the flat mining cost. Then rerun decoy and waste cover.
• Let the simulator pick the amount so the LLM only chooses the block. This stops the 1 t nibbles and cuts the number of calls.
• Soften the Uncertainty line to a plain fact, so it doesn’t read as an instruction to keep digging.
• Compare models. Try qwen3:14b and llama3.1:8b locally, and possibly gpt-oss-120b through Groq, to see whether a bigger model makes better use of the same information.

Today in short

• The MILP, greedy, blind, partial and full-information experiments are done. Next is simulator + LLM.
• The loop is simple. The simulator lists the possible actions, the LLM picks one, the simulator applies it and updates the mine, and the cycle repeats. All the rules (capacity, slopes, grades) are handled by the simulator, so the LLM only sees what it’s allowed to do.
• On a 1,000-block mine, describing the whole mine to the LLM is impossible, so only blind and partial will be run with the LLM at large scale.
• Speed is the main problem. At the current rate one large run would take about 2.5 to 3 hours. The work now is cutting the number of calls and the time per call.
• First step is a baseline. The current LLM setup runs on the six 27-block mines my MILP results came from, in full, blind and partial.
• One open question matters most. With only the action list, the LLM can’t tell one extraction from another, so it needs some extra information on each action.

How the loop works

simulator → list of possible actions → LLM picks one → simulator applies it → updated mine → ...

The simulator gives an answer instantly, so almost all of the run time is the LLM. Sending only the available actions, with no rules or full mine description, keeps the prompt short and focused on the choice that actually has to be made. On a 10 × 10 × 10 mine that’s the only option anyway, since the full mine state would not fit. That’s also why the full-information case is left to the MILP.

Fixes to make before running

1. The “actions only” design isn’t in the code yet. The no-context and partial-context notebooks are still identical to the original, and all three send the full mine state in every prompt.
2. The full mine state wouldn’t fit anyway. On a 27-block mine the first prompt was already about 956 tokens. At 1,000 blocks the state alone would be far beyond the 8,192-token context limit, and the model would silently lose part of the prompt.
3. With actions only, every extraction looks the same. An extraction action only carries its mining cost, not the block’s grade, so all extractions show the same number. In blind mode the LLM would effectively be choosing at random. In partial mode the shaft estimates would never reach it. The fix is to add a few facts to each action, such as the estimated grade, how uncertain that estimate is, the layer, and how many blocks it would unlock.
4. Use the same visibility rules as the MILP runs. The LLM code currently uses a different drilling model from the one in my MILP experiments. It has to use the same shafts and the same “surface plus what’s been revealed” rule, or the comparison isn’t fair.
5. Blind can get stuck. On the waste-cover and two-pockets mines with no minimum, blind MILP scored 0 because nothing visible looked worth mining. The LLM will face the same trap, so I need to decide up front whether to keep a minimum mining rule that forces it to dig.

Speed. What the earlier run shows

From the saved 27-block LLM run:

• 58 actions at 11.4 seconds per call on average, 11 minutes in total, finishing 1.7% below greedy.
• Call time follows how long the model “thinks”. A short reasoning took 3.5 s, and a long one took 22.4 s.

The 1,000-block runs need about 835 to 924 actions. At 11.4 s each that’s 2.5 to 3 hours per run, against 70 to 90 seconds for the rolling MILP on the same mine. A full sweep would take well over 150 GPU hours.

Design choices to settle

Other things worth doing

• Show the LLM only the top few actions. The simulator can rank the possible actions and send the best 5 to 20, with simple facts on each. A one-step look-ahead from the simulator, such as how many blocks an action unlocks, gives the LLM something greedy doesn’t consider.
• Make runs repeatable. Use a fixed random seed and no randomness in the model’s answers.
• Fall back safely. If the LLM returns an invalid action, the simulator rejects it and uses the greedy choice instead. How often that happens is a result worth reporting.
• Keep the comparison fair. The LLM must see exactly what MILP and greedy saw at the same information level. In particular, partial runs must not leak true grades through the action facts.
• Check where any gain comes from. Also run greedy and a random pick on the same short list. If the LLM only matches those, the gain came from the simulator’s ranking, not the LLM.

The main risk

An LLM choosing one action at a time only sees the present, much like greedy. If it does nothing more, it may end up equal to greedy but much slower. The look-ahead facts on each action, or letting the LLM set a strategy for each period while a fast rule picks the blocks, are the most likely ways for it to beat greedy.

First step. A baseline on the small mines

Before touching the large mines, the LLM is run on the same small mines my MILP results came from. That gives a fair starting point, with the current LLM setup exactly as it is.

• Six 27-block mines (3 × 3 × 3) from my earlier configs: 3D decoy, 3D central pipe, 3D blend lower limit, 3D central cone, 3D waste cover and dipping orebody.
• Each in full, blind and partial, so 18 LLM runs. Here the mine is small enough that the full-information case fits in the prompt.
• Same mines, same shaft, same drilling noise and cost as the MILP runs. As a check, greedy reproduces my earlier spreadsheet numbers exactly on all six, so the instances match.
• Prompts are about 500 tokens, well within the model’s limit.
• At about 11 seconds per call, each run takes roughly 10 to 30 minutes, so a few hours for all 18. Each result is printed next to my existing MILP and greedy numbers for the same mine.

Then the first large test

Once the baseline is in, try one large mine and one setting before any sweep.

• Settings. The simulator picks the amount, processing happens automatically, the LLM returns only an action number, low reasoning effort, no step memory, a fixed answer format, and grade estimates on each action.
• Mine. Opposite gradient, no minimum, in both blind and partial.
• What would count as success. Landing between greedy (509,329) and the rolling blind MILP (672,628), at a few minutes per run. If it does, scale up to the full set of mines.

What to report for each run

NPV gap to the MILP, total run time, number of LLM calls, words (tokens) used per decision, and how often the LLM gave an invalid answer. All of these for both blind and partial.

Next

• Run the 18-run baseline on the 27-block mines and compare with the MILP and greedy results.
• Fix the prompt so it sends only the available actions, with the extra facts on each.
• Switch the LLM code to the same shaft and visibility rules as the MILP runs.
• Decide on the minimum mining rule for blind.
• Run the first test on the opposite-gradient mine.

Today in short

• I set up five large mines (10 × 10 × 10 = 1,000 blocks, 6 periods), one for each of my main small-mine designs, and ran every scenario on all of them. That’s 30 partial runs plus blind, full MILP and greedy.
• At this size blind is already strong. The re-planning blind MILP reaches about 95 to 98% of perfect information on most mines, so a shaft has little left to add. Gains are mostly 0 to 2,600, against drill costs of 575 to 1,813.
• Greedy falls well behind everywhere, at about 68 to 82% of full information.
• One result stands out. On the dipping orebody with a minimum, two shafts did 35,000 to 53,000 worse than blind. The cause is the minimum mining rule, not the information the shafts gave.

The five mines

Each mine is 10 × 10 × 10 (1,000 blocks) over 6 periods, with the same economics: 4,000 t of mining and 2,000 t of processing per period, and drilling at 125 per block plus 10% per layer of depth. The surface is kept poor everywhere, so information always has some value. Each mine was run with no minimum and with a 1,200 t minimum.

The same three shafts are used on every mine so the results compare directly.

The shafts don’t always hit ore. The shallow shaft finds nothing on the dipping and two-pockets mines, and on the dipping mine only the diagonal reaches the deep ore. I kept that on purpose, since a badly placed shaft that is pure cost is a useful case for the thesis.

One run crashed (two pockets, shallow shaft, no minimum). That shaft passes only through waste, so the planner correctly mined nothing, and the notebook failed when saving an empty schedule. I fixed the empty case in the code and reran that one mine. The result is NPV 0, the same as blind.

Results

NPV, rounded to the nearest unit. Bold marks the best partial result in each row.

What the table says

1. Blind is already close to perfect on large mines. On most mines blind reaches about 95 to 98% of full information (dipping is lower, about 88%). With that little gap left, shafts gain only 0 to about 2,600, and once drill cost is taken off, most are a small net loss. The clear net wins are vertical on dipping with the minimum (+3,820), shallow on two pockets with the minimum (+1,403) and diagonal on opposite with no minimum (+835).

2. Rows where blind is 0 aren’t really wins for the shaft. On waste cover and two pockets with no minimum, the whole surface is waste, so blind sees nothing worth digging and never starts. The huge “gain” there just means the shaft persuaded the planner to dig at all. Greedy, with no shaft, gets 548k and 239k on those mines. These rows are better compared with greedy, or reported separately.

3. Greedy is far behind everywhere, at about 68 to 82% of full information. It mines at full speed from the best-looking surface blocks, which is exactly what these layouts punish. Its result doesn’t change with the minimum, because it always mines at full capacity, so 1,200 t never binds.

4. Two small oddities that are fine. The full MILP is sometimes slightly higher with the minimum (693,342 against 692,556 on opposite). Adding a rule can’t truly raise the optimum, but both are within the solver’s 0.1 to 0.4% tolerance.

The dipping orebody. The minimum, not the shaft

On the dipping mine with the 1,200 t minimum, the diagonal shaft finished 52,758 below blind (only 53% of full information) and shallow 34,341 below. Nowhere else does information hurt by more than about 2,000. Adding up each period’s mining shows why.

Period 1 is the minimum’s fault. With the minimum, every run, blind included, mines exactly 1,200 t in period 1 even though it could mine 4,000 t. Almost the whole surface is waste and everything underneath is hidden, so the planner values it at nothing. Because the minimum applies to every period of its plan, it reasons, “I must mine 1,200 t in each of the next periods, and the only rock I can see is this surface waste, so I’ll spread it out and pay later, when it’s cheaper after discounting.” It can’t see that stripping the surface is what uncovers the orebody. This is the same waste rationing I found on the small lens mine. Even for blind it costs about 60,000 on this mine compared with no minimum.

Period 2 is where two shafts make it worse. Blind and vertical stop rationing in period 2 and mine at full rate. Diagonal and shallow ration for one more period. Their estimates near the surface show only waste (grades 0.08 to 0.17), which adds to the rock the planner thinks it must save for future minimums. On a dipping deposit with only 6 periods, that one-period delay means the deep ore is never reached.

So the code is right, but the result isn’t about the value of information. It shows the every-period minimum interacting with a mine whose ore is all hidden. Without the minimum, all three shafts are within about 450 of blind on this mine.

Next

• Decide how to handle the dipping result. Either report it as a finding (a hard minimum in every period makes a rolling MILP ration stripping when the ore is hidden), or soften the minimum in future periods only, keeping it hard for the current period so the schedule still meets 1,200 t every period, and rerun the dipping mine.
• Report the blind = 0 rows against greedy, not blind.
• Tighten the full MILP’s solver tolerance if the with/without-minimum comparison needs to be exact.

Today in short

• I moved from small generated mines to newman1, a real mine from the public MineLib library, with published best-known results to check against.
• Grade means something different here. It’s grams of gold per tonne of rock, not the share of a block that is ore. A block goes wholly to the mill or wholly to waste.
• The dataset can’t satisfy all of my model’s rules. Capacities, precedence and “mine before you process” carry over. Stockpiling, splitting a block across periods and grade blending don’t.
• I use newman1 only as a mine. My model keeps its own rules, and MineLib’s published results are for reference, not targets.
• First runs. Full MILP 22,386,899, greedy 21,800,955, blind 4,243,334.
• Blind stalls on this mine. It can’t see the ore under the waste, so it stops digging early.
• newman1 is shelved for now. Later it will be placed in a full cube and scaled down by merging blocks into small, medium and large instances.
• A misleading surface makes drilling shine. On a small mine where the surface is richer on one side and the ore underneath is richer on the other, every shaft gets within 2.5% of perfect information for under 100 of drilling, greedy falls 40% behind, and the minimum mining rule barely matters.

Why a real dataset

Small generated mines are good for understanding why a method behaves the way it does, but they’re easy to tune without meaning to. A public benchmark gives a fixed, realistic test that other researchers have already solved, so my results can be compared directly with theirs.

MineLib is a standard library of open-pit mining problems, and newman1 is one of its smaller instances. Source pages: MineLib datasets and newman1.

The mine at a glance

Blocks don’t all weigh the same. Most full blocks weigh 5,664 t. Full oxide ore blocks weigh 5,184 t because oxide rock is lighter. 182 blocks are partial (from 74 t up), mostly where the ground surface cuts through the top of a column. My code already uses each block’s own weight.

The gaps aren’t holes. Every (x, y) column is a solid stack. The gaps in the picture are just columns that start lower down, so the space above them is air. The model only knows the 1,060 real blocks. One side effect is that near the pit edges some slope links point to rock MineLib left out of the instance, so the wall slopes there are only approximate. That’s a property of the dataset, not my code. In the blind setting, the scheduler starts by seeing the top block of each of the 170 columns.

What “grade” means here

In my generated mines, grade was the share of a block that is ore (0 to 1), and only that share was processed. In newman1, grade is grams of gold per tonne of rock, which is why values go up to 3.7. MineLib doesn’t name the metal, but it fits. The price term of 19.29 per gram works out to $600 per troy ounce.

Each block is sent wholly to the mill or wholly to waste. Its processing value is

(19.29 × recovery × grade − processing cost) × tonnage

with different costs and recoveries for oxide ore (cheaper to process, better recovery) and fresh rock. That gives a break-even (cutoff) grade.

So a block can contain some gold and still be waste. Block 115, for example, is fresh rock at 0.76 g/t, below its cutoff. The 91 blocks of type “0” have zero grade and are treated as plain waste.

Because the value follows a formula, hidden blocks can be re-valued from an estimated grade, which is exactly what the blind and partial (drilling) schedulers need.

Where my model and newman1 don’t match

The last four rows mean my model is a little looser than MineLib’s, so its NPV can come out slightly higher than their published values.

Decision. I use newman1 only as a mine, meaning its blocks, values, slopes and capacities. My thesis model stays as it is, with blocks that can be mined over several periods and ore that can be processed later. MineLib’s published results follow different rules, so they’re kept for reference only and are not targets to match.

First results

My NPVs below use my own discounting (from period 1).

The full MILP solved in 14 seconds. Greedy gets within about 3% of it. Blind collapses to less than a fifth.

For reference against MineLib. Converted to MineLib’s discounting, my full MILP is 24,177,851, about 2% above their best listed schedule (23,658,230) and still below their upper bound (24,486,549). That’s expected, partly because my model is looser, and MineLib’s listed value comes from an older heuristic. Only 2 blocks were actually split across periods and no ore was held over, so most of the difference is just a better schedule. Since MineLib’s rules aren’t targets, I don’t need to match their number.

What each method does in period 1

• Full MILP digs the full 2 Mt, 196 ore blocks and 211 waste blocks. Every waste block sits above ore it processes in periods 1 and 2. Block 271, for example, is worthless rock on the top bench, but 133 ore blocks of 1.5 to 2 g/t lie under it. The MILP pays to strip it now so the rich ore reaches the mill early.
• Greedy grabs the best block on offer each step, starting with blocks 103 and 102 (2.0 and 2.9 g/t), which have little on top. It strips waste only when nothing better is available, so its period-1 ore is lower grade.
• Blind sees only the top of each column. Blocks 82 and 118 sit low on the side of the pit and look profitable, but block 118 barely beats its cutoff. Blind can’t justify stripping a block like 271, because it can’t see the ore underneath. So it stops after 679,000 t in period 1 and never sees 785 of the blocks. That’s the same stall as on my generated decoy mines.

The order of actions inside a period doesn’t affect NPV. Everything in a period is discounted the same, and the replay simply does all digging first, largest blocks first.

Back on the small mine. A surface that misleads

The last run of the day went back to the 4 × 5 × 4 mine (10 t blocks, 7 periods, my usual capacities) with a new grade layout built to test the shaft idea cleanly. The surface points one way and the ore underneath points the other.

• Surface. Richest at the far corner (row 4, column 3), poorest at the near corner (row 0, column 0), but nowhere pure waste. It stays below 0.5, so surface ore can’t fill the 40 t plant on its own. Only the two far-corner blocks (0.40 and 0.45) reach the 0.4 cutoff alone. The rest can only be processed blended with richer ore.
• Layers 1 and 2. The reverse. Richest under the near corner (up to 1.00), poorest under the far one.
• Layer 3. Waste.

Surface (layer 0)              Layer 1
richer toward far corner       richer toward near corner
 0.05 0.12 0.18 0.25            1.00 0.87 0.73 0.60
 0.10 0.17 0.23 0.30            0.90 0.77 0.63 0.50
 0.15 0.22 0.28 0.35            0.80 0.67 0.53 0.40
 0.20 0.27 0.33 0.40            0.70 0.57 0.43 0.30
 0.25 0.32 0.38 0.45            0.60 0.47 0.33 0.20

All three shafts start on the poor side of the surface, so they sample the rich ore underneath. Earlier versions with a richer surface made every shaft worthless, because the surface ore alone already filled the plant. The parameters are saved as cleaned/runs/params_4x5x4_opposite_p7.yaml.

Results

Drill costs are 92 (diagonal), 66 (shallow) and 46 (vertical).

1. The minimum no longer distorts partial. With and without the 20 t minimum, partial changes by at most 1.8% (vertical), and diagonal barely moves (12,589 against 12,582). On the lens layout the minimum cost partial up to 20%. The difference is that this surface has some value, especially blended with the rich ore below, so the planner never sees its future periods as forced waste mining and has no reason to ration its stripping.

2. Every shaft gets partial close to perfect information. Partial lands within 2.5% of full information in every case. With no minimum each shaft gains about 11,600 over blind for under 100 of drilling. With the minimum the gain is about 3,700 to 3,900, because blind digs further on its own when forced to.

3. All three shafts are nearly equal. The rich zone is broad, not a small lens, so any shaft that hits it is enough. Net of cost, the cheapest shaft wins with no minimum (vertical, 12,543), and diagonal and shallow tie with the minimum. Differences of a few hundred are within the near-tie noise seen before.

4. Greedy falls far behind (8,874). It takes whatever looks best right now, which is the richer far side of the surface. That’s exactly the trap this layout sets, because the real ore is under the other side. Partial beats greedy by about 40%.

5. Blind with no minimum stops almost at once (891). It mines the two processable surface blocks at the far corner, finds poor ore below them, and stops. With the minimum it’s forced to keep digging and reaches part of the rich zone (8,641).

Why vertical works here but failed on the lens

The vertical shaft goes straight down through blocks 10, 30, 50 and 70 (row 2, column 1).

It starts on the poor side and finds good ore one layer down, under blocks the scheduler can already see.

• Stripping is cheaper. On the lens, the 9 surface blocks above vertical’s ore were pure waste, so clearing them for one rich block only broke even and the MILP never started. Here those blocks grade 0.10 to 0.33. They carry some ore that can be processed blended with the richer ore below, so stripping partly pays for itself.
• The rich zone is broad. Once digging starts at row 2, column 1, every block uncovered nearby is good, and each reveal leads the scheduler toward the richest corner. That’s why vertical with no minimum ends with exactly the same NPV as diagonal (12,588.60). Once digging starts on the near side, the rest of the schedule is the same, and vertical is the cheapest shaft.

How these runs plan

All periods at once, with re-planning. Each solve plans the whole remaining horizon (from now to period 7) as one MILP, with the 20 t minimum on every period of the plan. The loop carries out one action, reveals any newly exposed blocks, and solves the whole remaining horizon again. So every decision comes from a full multi-period plan, redone as new blocks appear. This is the method I settled on yesterday, and it’s part of why these results improved.

The full-information value (12,675) is the one-shot MILP. It knows every grade and solves all 7 periods once, with no re-planning.

What this means for the thesis

This layout gives the clearest support for the shaft approach. When the surface misleads about what’s below, one cheap shaft through the poor-looking side recovers almost all the value of perfect information. It works with and without a minimum, and it avoids the waste-rationing problem. The lens layout is the counter-case. When the surface over the ore is pure waste and a minimum applies, the same method rations its stripping.

Plan. newman1 is shelved for now

newman1 is on hold until the rest of the framework is complete. When I come back to it, the plan is as follows.

1. Place the mine in a full cube. A real mine sits inside solid ground, so the irregular pit will be put into a complete rectangular block model, with the empty cells filled in as blocks. This matches how my own code represents a mine, and it also fixes the approximate pit walls, since the rock MineLib left out will now exist.
2. Shrink it by combining blocks. Filling the cube increases the block count a lot, so the problem will be scaled down by merging neighbouring blocks into larger ones. That gives three sizes of the same mine.

This gives one real mine at three sizes, so I can see how each method (MILP, greedy, blind, partial and Sim + LLM) holds up as the problem grows.

Next

When newman1 comes back

• Place newman1 in a full cube and build the small, medium and large instances by merging blocks.
• Get blind past the stall, with a minimum mining rule or a larger reveal bonus.
• Adapt the partial (drilling) code. It finds “the block underneath” by ID arithmetic, which only works on a full grid (the cube will help here), and estimated blocks need the newman1 value formula.
• Add exploratory shafts and run partial on all three sizes.

Today in short

• The blind scheduler works in a loop. Plan the whole future, do only the first step, look again, re-plan.
• Every re-plan starts from an exact snapshot of the mine, so nothing already done is counted twice or forgotten.
• A simple check confirms this. The plan’s total value stays fixed between steps and only jumps when digging reveals new ore.
• One gap found. When deciding whether the 20 t minimum can be met, the blind code counts rock it can see rather than rock it can reach. The partial code already fixes this. Blind should get the same fix so the two are compared fairly.
• Why one period at a time. Applying the minimum to every future period made partial ration its stripping. My supervisor preferred not to change the rule, so we added a new baseline instead, full information planned one period at a time.
• On the lens layout, that baseline loses only 3 to 4% against full planning. A good shaft with planning ahead (10,167) beats knowing everything without it (9,792).
• Decision. The main method goes back to planning over the full horizon, since that’s what the MILP is built for and one period at a time adds complexity on larger instances.

Today was mostly about making sure I understand exactly what my code does before running more tests. This post explains the blind scheduler using one real run.

The example mine

A small vertical slice, 7 blocks wide and 3 layers deep (blocks 1 to 21), over 6 periods, with a mill that can process 60 t per period. Each number is the block’s grade.

At the start, the blind scheduler sees only the top row. A block below becomes visible only once the block directly above it is fully dug out.

The loop. Plan everything, do one thing, look again

Think of a site manager with a map that only shows what’s been uncovered so far. Every time something changes, they redraw the full plan for the rest of the job, but they only carry out the very first item on it. Then they look at the mine again and redraw.

Each turn of the loop has six steps.

1. Ask the mine what’s allowed right now. The simulator lists every legal move, taking into account which blocks are uncovered, how much capacity is left this period, and the ore grade limits at the mill.
2. Re-plan if anything changed. A fresh optimisation model is built using only the visible blocks, from the current period to the end. Hidden blocks simply don’t exist in the model, so anything under them is off limits.
3. Pick one move from the plan. From this period’s part of the plan, it takes one action, digging before processing and bigger amounts first, and trims it to what the mine allows.
4. Carry it out. The move goes through the same simulator code that the greedy and LLM schedulers use, so every method is scored the same way.
5. Reveal. If a block is now fully dug, the block below it becomes visible.
6. End the period when there’s nothing left to do. When the plan has nothing more for this period, the clock moves on. Periods end because the plan runs out, not because of a counter.

What that looked like in the real run

27 actions took 27 re-plans, one per action. Each took about 0.01 seconds, so re-planning every time is cheap at this size.

The first plan expected to earn only 7,569 in total, because it could only see the surface. The run finished at 11,915 because every reveal showed ore it didn’t know about, and it re-planned around it. Full information reached 12,029, so blind lost under 1%. Greedy reached 11,286.

Two design details

Why digging comes before processing. The mine only offers a processing move once ore has been dug. If it processed first, there would be less ore ready than the plan assumed, and the move would get cut short.

Why there’s a small “reveal bonus”. Block 7 was only partly dug after period 2 and finished in period 3, so block 14 underneath stayed hidden until then. When several visible blocks are equally valuable, the model has no reason to finish any one of them, and it can chip at several without uncovering anything. A tiny bonus for fully clearing a block that sits above a hidden one breaks those ties towards finishing blocks early. The bonus is not counted in the NPV.

How each re-plan stays consistent with the past

Each re-plan starts from a snapshot of the mine. Past periods are dropped entirely, because their money is already banked. Only the current period and the future are planned. The snapshot has five parts. As an example, take the 4th re-plan, in period 1, right after steps 1 to 3 above.

1. How much of each block is already dug and processed. Block 7 is 79.26% dug and 79.26% processed. Block 3 is 60.74% dug and 0% processed. The plan can only touch what’s left.
2. Capacity already used this period. 70 t has been dug in period 1, which is the full limit, so the plan can’t dig anything more this period. The mill has used 32.50 t of its 60 t, leaving 27.50 t.
3. The grade mix already at the mill this period. The 32.50 t of 0.83-grade ore puts the mill comfortably above its 0.4 minimum average grade. That leaves room to blend in up to about 55.9 t of low-grade (0.15) ore this period and still stay above 0.4. Without remembering this, the plan could pick a mix that breaks the limit once combined with what’s already been processed.
4. Only process what’s been dug. Block 7 can’t be dug further this period, so none of it can be processed further either. That’s why the 4th re-plan processes block 3 instead. Exactly 21.26 t of it was dug and ready, and that’s what step 4 processed.
5. Money is always counted in today’s terms. Discounting uses the real period number, so every plan’s value is in the same units as the money already banked.

e = {n: 1.0 if mine.mine_extraction[n] >= 1.0 else 1 - mine.To_be_extracted[n] / tt[n] for n in blocks}
p = {n: 1.0 if (o[n] == 0 or mine.mine_process[n] >= 1.0) else 1 - mine.To_be_processes[n] / o[n] for n in blocks}

def mined_by(n, t):
    if n not in visible:
        return mine.mine_extraction[n]      # hidden: a constant (0)
    return e[n] + gp.quicksum(y[n, j] for j in range(t0, t + 1))

done_ub = sum((g - G_ub[t]) * amt for amt, g in blend)   # (0.83 − 1.0) × 32.50 = −5.52
done_lb = sum((g - G_lb[t]) * amt for amt, g in blend)   # (0.83 − 0.4) × 32.50 = +13.97

The check that proves it works

If the snapshot is right, then money already banked plus the money the new plan expects should stay exactly the same from one re-plan to the next, as long as nothing new is revealed. Doing a step just moves value from “planned” to “banked”. It should only jump when a reveal shows the model new ore.

That’s exactly what happens. If any part of the snapshot were wrong, the total would drift between steps even without a reveal. This makes a good automatic test, and a good figure for the thesis.

A gap found. “Can see” isn’t the same as “can reach”

My mining rule says the mine should dig at least 20 t per period, as long as enough rock is available. Before applying that rule, the code checks how much rock is left.

In the blind code, that check counts every visible block that isn’t dug yet. But a block can be visible without being reachable yet. In this mine, block 12 becomes visible as soon as block 5 above it is cleared. It still can’t be dug until its neighbours 4 and 6 are also cleared, because of the pit slope.

Here’s how that can go wrong. Say the check finds

• 10 t of rock it can actually reach, and
• 50 t of rock it can see but can’t reach yet.

It concludes 60 t is available, so it insists on the 20 t minimum. Only 10 t is really reachable, so the plan becomes impossible to satisfy. The code’s fallback then drops the minimum for that whole re-plan, which means the mine might dig less than 20 t that period.

The partial code already fixes this. It counts only rock that is currently reachable. The blind code still uses the old count.

Has it affected any results so far? No. I checked all 15 saved blind runs, and none of them ever had to drop the minimum. The 20 t default is low enough that the problem never showed up. It could show up with a higher minimum (for example 100 t), or on wider mines where more blocks have to be cleared to reach the ones underneath.

Why fix it anyway. Blind and partial should use the same rule for deciding whether the minimum can be met. Otherwise a difference between them could come from this code detail instead of from the drilling information, which is what I’m actually trying to measure.

remaining = used + gp.quicksum(tt[n] * (1 - e[n] - ...) for n in blocks)

Why we ended up planning one period at a time

This took several steps, each one a response to something odd in the results.

1. The minimum rule had already caused one problem. On the 10 × 10 lens with the 10 → 91 shaft, partial sat idle for 5 periods. The minimum was counting deep drilled blocks the plan couldn’t reach yet, so every plan was impossible and the minimum got dropped. That was fixed by counting only reachable rock (the same gap described above for blind).

2. Then the 4 × 5 × 4 lens showed a subtler problem. At realistic capacities, with 10 t blocks, the shafts worked, but the 20 t minimum made partial worse, not better.

Partial knew where the ore was and the whole surface was open, yet it dug only 20 t in period 1. Why?

3. The first plan showed the reason. With the minimum, the plan spread the stripping out at exactly 20 t per period, reaching ore block 26 in period 4 and block 31 in period 7, instead of periods 2 and 3. Each plan applied the 20 t minimum to every future period too, and in those future periods the plan could only see waste. It believed “I’ll have to mine 20 t of waste every period anyway”, so it saved the stripping to cover those future minimums instead of stripping fast. It couldn’t know that mining would uncover more ore and fill those periods.

4. That led to the idea of applying the minimum only to the current period. Each plan enforces the minimum only for the period being carried out now. Every period still meets it when its turn comes, but the plan no longer assumes a future of forced waste. On the lens layout, partial went from 8,489 to 10,221 and blind from 5,861 to 8,489.

5. My supervisor felt this approach might not be feasible. So it stays in the code as a switch, CURRENT_PERIOD_MINIMUM_ONLY, but it is now off by default, which keeps my original method. Instead, we followed the supervisor’s suggestion and added a new baseline. Full information, solved one period at a time. Its plan only ever contains the current period, so it can’t have the future-minimum problem. It also shows how much planning ahead is worth when every grade is known.

An everyday version of the problem

The situation. You’re a freelancer, and your contract says you must bill at least 2 hours every day.

• On your desk is a pile of unpaid admin work (the waste), 8 hours of it.
• A friend tells you there’s a well-paid project waiting behind that admin work. You can only start it once the admin is cleared. This is the shaft showing ore under the waste.
• What you don’t know yet is that finishing that project will lead the client to send you more paid projects. This is the rest of the ore lens, revealed as you mine.

Every morning you plan the rest of the week, using only the work you can see right now.

Old rule. Minimum in every planned day. Each morning you plan so that every day this week has at least 2 hours of work. Looking at your desk, the only work you can see for later days is the admin pile. So you think

“If I clear all 8 hours of admin today and tomorrow, I’ll have nothing left for Thursday and Friday, and then I’d need to find more unpaid filler to meet my 2-hour minimum. Better to stretch the admin out, 2 hours a day, so it covers every day.”

So you do 2 hours of admin a day, and the paid project doesn’t start until the end of the week. In reality, the moment you’d finished the admin and started the paid project, new paid work would have arrived to fill Thursday and Friday. You delayed the money to protect against an empty week that was never going to happen.

New rule. Minimum only for today. Each morning you only make sure today has at least 2 hours. Future days are planned freely.

“Admin today and tomorrow at full speed, then start the paid project.”

You clear the admin fast and start earning early. When Thursday comes, you plan again, and by then the new paid work is there, so the minimum is easily met.

Both ways, you work at least 2 hours every single day. The only difference is whether your plan assumes the future holds nothing but admin.

The old rule made the planner treat its blind spot (future ore it couldn’t see) as if it were certain emptiness. The new rule lets it plan only today’s commitment and leave the future open for when it knows more.

The new baseline. Full information, one period at a time

Lens layout (4 × 5 × 4), with the switch off, so partial uses the original method and matches the earlier runs exactly.

1. Planning one period at a time costs full information only about 3 to 4% here. Knowing every grade but planning only the current period gives 9,792 to 9,907, against 10,223 when the whole schedule is planned at once. On this layout, with 10 t blocks and 70 t of digging per period, the plan can often strip waste and dig the ore underneath in the same period, so not looking ahead costs little. On the Decoy layout it was very different, about 29%.

2. With no minimum, a good shaft plus planning ahead beats knowing everything but not planning ahead. Diagonal and shallow reach 10,167, above full information planned one period at a time (9,792). A cheap shaft is worth more than perfect knowledge if the planner can’t look ahead. Planning ahead matters as much as the information.

3. With the 20 t minimum, partial falls below full one-period (8,489 and 8,151 against 9,907). This is the rationing effect from step 3 above. Full one-period can’t have it, because its plan only ever contains one period. So the gap shows what that rationing costs partial, about 1,400 to 1,750.

4. Full one-period does better with the minimum than without it (9,907 against 9,792). Without a minimum, a one-period planner sometimes skips stripping that only pays off next period, because it can’t see next period. The minimum forces it to dig anyway, which helps. That’s the same reason blind improves with the minimum.

5. The shafts behave as before. Diagonal and shallow pay well in both settings. Vertical pays only with the minimum (+816 against a cost of 46) and is worthless without it.

Where the value comes from

With no minimum, the gap from blind to full information splits into two parts.

On this layout almost all the value comes from the information. On Decoy it was the other way round, with look-ahead worth far more. That contrast is worth showing my supervisor.

Decision. Back to planning over the full horizon

After looking at these results, I’m going back to giving the MILP the full planning horizon, all remaining periods at once, as the main method.

• The MILP is built to work on the full horizon. Its strength is weighing what happens now against what happens later. Cutting it down to one period at a time throws that away, and these results show look-ahead can be worth a lot (about 29% on Decoy).
• One period at a time doesn’t scale. On larger instances it means many more separate solves and extra bookkeeping between them, which increases the complexity of the method instead of reducing it.

So full information planned one period at a time stays as a comparison on these small cases, to show how much of the value comes from the information and how much from planning ahead. The main results use the full-horizon MILP.

What this means for the thesis

• The current-period-only rule is off. All main results use the original method, where each plan applies the minimum to every period.
• Partial’s shortfall under the minimum (8,151 to 8,489 against 9,907) is a known, explained effect of that method. It can be described in the thesis, or fixed later if my supervisor agrees.
• The main method plans over the full horizon. Full information planned one period at a time is used only as a comparison, to separate the value of knowing the grades from the value of planning ahead.

Next

Tomorrow

• A new mine shape. Test a convex block model instead of a cube, so the pit narrows with depth the way a real open pit does.
• Sim + LLM on the shaft approach. Run the simulator with the LLM scheduler on the partial (drilled shaft) setting, and compare it with the MILP results.

Also on the list

• Port the reachability fix into the blind code (rolling_milp.py, run_configs.py).
• Re-run the saved blind runs and confirm the results don’t change.
• Test cases where it could matter, such as a 100 t minimum and a wider mine.
• Turn the “banked + planned stays constant” check into an automatic test.
• Keep the full-horizon MILP as the main method for all batch runs.
• Run full information one period at a time on the small batch instances only (Decoy, Dipping orebody and the rest), as a comparison, and build the “information vs planning ahead” split for each.
• Show my supervisor the lens vs Decoy contrast and agree whether to address partial’s rationing under the minimum.
• Label every results table with the minimum rule it used.

Where things are

The simulator plus LLM scheduler is working for the blind and full information settings. Last week I added the partial setting, where the scheduler sees noisy grade estimates along exploratory drillholes, and ran a batch of rolling-horizon MILP experiments on it (rolling_milp_partial.py).

I also cleaned up the codebase into the cleaned/ folder and built a block model viewer notebook to inspect what each scheduler actually extracts period by period.

A case worth reporting: waste cover

A uniform low-grade surface with no visible signal of where the ore is, and a rich zone underneath.

Greedy beats blind MILP by a wide margin here. Greedy fills the available capacity in every period. The blind MILP can’t see the lower levels, so it spreads extraction across every surface block at once and never commits to digging down to the ore.

Next

• Run the partial (drilling) case on the same instance and see how much of the gap a few drillholes close.
• Add drilling cost to the NPV comparison so the trade-off is honest.
• Write up the remaining cases for the report.

Today in short

• A minimum mining rule (dig at least so many tonnes every period) is what keeps the blind scheduler from giving up early. Without it, blind can lose most of the mine’s value.
• A drill shaft pays only when two things are true. The mine has to dig below the surface within the plan, and the surface has to be a poor guide to what’s underneath.
• On a mine with a good, honest surface, no shaft was worth its cost. On the same mine with ore hidden under waste, a shaft costing under 100 added about 8,800 and got within 0.6% of perfect information.
• The minimum mining rule helps blind but hurts the scheduler that drilled, because of how the rule is applied to future periods. Tomorrow I test a fix.

Background in plain words

An open-pit mine is modelled as a 3D grid of blocks. Each block has a grade, the share of it that is valuable ore. Each period the scheduler decides which blocks to dig and whether each one goes to the mill (ore) or the waste dump. A block can only be dug once the blocks above it are gone. The goal is the highest NPV (net present value), which is total profit with money earned sooner counted as worth more.

The question is how much it helps to know what’s underground before you start. I compare schedulers that know different amounts.

Blind, partial and full all use a rolling MILP, an optimisation model that re-plans after every step using only what it can currently see.

A minimum mining rule (also called the lower limit) says the mine must dig at least a set tonnage every period, as a real operation would.

The gap between blind and full information is the most any drilling can ever be worth. A shaft only pays if it closes enough of that gap to cover its own cost.

Experiment 1. Blind depends on the minimum mining rule

A 10 × 10 vertical slice of a mine (blocks 1 to 100), with two different shafts (outlined in blue).

What it shows. With no minimum, blind earns only 13,090, about a fifth of what’s possible. It digs what it can see, finds nothing worth chasing, and stops. With a minimum of 250, blind is forced to keep digging, stumbles onto the ore, and jumps to 65,652. The minimum rule alone is worth more than 50,000 to blind. With no minimum, the shaft through the ore band rescues partial (66,946), but the shaft that misses it leaves partial no better than blind.

A second test on a 5 × 5 × 5 mine (blocks 1 to 125) with a shaft cost of 120 tells the same story.

Without a minimum, only the shaft that finds shallow ore pays, and it pays hugely. With a 200 t minimum, blind reaches 59,669 on its own and every shaft either adds nothing or makes things worse.

Experiment 2. Realistic capacity, honest surface. Drilling is worthless

Next, a mine closer to real production limits.

• Mine. 4 × 5 × 4 = 80 blocks of 50 t each, 7 periods.
• Economics. Mining costs 10 per tonne, ore earns 100 per tonne, 10% discount rate.
• Capacity. Dig 20 to 70 t per period, process up to 40 t per period.
• Drill cost. 50 per block drilled, plus 10% for each layer deeper, paid once before mining.
• Minimum mining. Each case run with no minimum and with a 20 t minimum.

No shaft paid for itself. The reasons are simple.

• Blind was already perfect. It matched full information, so there was no gap for drilling to close.
• The mill was the bottleneck. At 40 t per period the mill takes about 280 t over 7 periods, only five or six blocks. The surface alone had 20 blocks of good ore (grades 0.54 to 0.75), all visible from the start. The best plan never needed to go deep.
• Deep information went unused. Most lower blocks were never even uncovered, so knowing their grades changed nothing.
• The surface told the truth. Rich surface sat over rich ground, so there was nothing misleading for a shaft to correct.

Experiment 3. Same mine, hidden ore. Now drilling pays

Same mine, capacities and costs. Only the grades change. The surface now shows a small decoy of ore surrounded by waste, while a rich lens of ore sits just below, under most of the waste.

Shaft costs here are 92 (diagonal), 66 (shallow) and 46 (vertical).

No minimum. Blind digs the decoy and stops, because everything else it can see is waste (1,273). The diagonal and shallow shafts each spot two rich blocks just under the surface. That’s enough to make clearing the waste worthwhile, and once digging starts the rest of the lens comes into view. Both finish within 0.6% of perfect information for a shaft costing under 100. The vertical shaft finds only one rich block, which isn’t worth clearing nine waste blocks for, so it ends up exactly like blind.

20 t minimum. Blind is forced to dig and finds part of the lens on its own (5,861), so there’s less left for a shaft to add. All three shafts still pay, in the order of how much shallow ore they find. Diagonal and shallow are effectively tied. An earlier run had shallow ahead, which is normal sensitivity in the rolling MILP when two options are this close.

Greedy nearly matches perfect information here (10,174). It always digs at full speed, and the lens lies under most of the waste, so wherever it digs it soon hits ore. On the decoy layouts in Experiment 1 the same habit wasted effort.

Why the minimum helps blind but hurts the scheduler that drilled

One result looked odd. With the lens layout, the diagonal shaft earned less with the 20 t minimum (8,489) than without it (10,167), even though it dug well over 20 t each period in both runs. Comparing the two runs period by period:

With the minimum, it reached the ore about two periods later, and that delay cost about 1,700.

The cause is how the minimum is written into the plan. Each time the MILP re-plans, it makes a full plan for all remaining periods, and the minimum currently applies to every period in that plan, not just the one it’s about to carry out.

Picture a site manager who can see some rock now and will discover more as they dig. If they must promise in advance to dig at least 20 t in every future period, and the only rock they can see for those future periods is waste, they’ll think, “I’ll need waste to fill those future quotas anyway, so I’ll save the waste above the ore for later.” That spreads the stripping out and delays reaching the ore. What they don’t know yet is that the moment they start digging, the ore lens will appear and fill those later periods on its own.

If instead the minimum only applied to the current period, the manager would think, “I know where the ore is. I’ll clear the waste now, meet this period’s 20 t, and decide next period when I can see more.” The rule is still met every period, because each period becomes the current one in turn. It just isn’t pre-committed into a future the model can’t see yet.

Illustrative only. Actual digging still depends on grades, access and mill capacity. The future plan must still respect what is physically possible to dig.

Why this cuts opposite ways.

• Blind doesn’t know where the hidden ore is. The minimum forces it to dig and discover valuable blocks it would otherwise never reach. So the minimum helps.
• Partial already knows where the ore is, from the shaft. Applying the minimum to every future period makes it spread out the waste removal instead of going straight for that known ore. So the minimum hurts.

In one sentence, “minimum in every planned period” means plan to dig at least 20 t every period, including the future, while “minimum in the current period only” means meet this period’s target now, then re-plan the future once you can see more.

This is a limit of planning only over visible blocks, not a problem with the shaft itself.

What this means

Drilling pays only when two conditions hold together.

1. The mine must actually dig below the surface within the plan. That needs enough capacity compared with the mine’s size, or a long enough horizon.
2. The surface must be a poor guide to what’s below. If the surface is honest, blind already does as well as anyone.

When both hold, one well-placed shallow shaft can be worth many times its cost. When either fails, the same shaft is wasted money. The value of drilling comes from the decision it changes, not from the information itself.

Next (tomorrow)

• Test the minimum in every period vs the minimum in the current period only. Change the rolling MILP so the 20 t minimum applies only to the period being carried out, re-run the lens layout for blind and all three shafts, and compare with today’s numbers. Expect partial to recover towards 10,167 with the minimum. Check that blind still benefits and that every period still meets 20 t when it actually runs. Also handle any period where 20 t isn’t reachable.
• Change from block structure format and a very large instance.