Do Jev Decision Models work for mine operations?

If you have been anywhere near the AI space in recent months, you’ve been inundated with news about Jev.

“Jev Leftpad”. “Jev plays Pokemon Red”. “Reverse Engineering Jev”.

Clearly something interesting is happening here - but is it useful in mining? The answer is - well, sort of.

Jev is a decision model. It takes in a certain context - written text, such as shift comments, supervisor notes and descriptions on a maintenance job sheet - but also numbers like travel times for vehicles, remaining work hours in a shift or production targets for hauling.

Then, you ask it specific questions about that context. Instead of generating a lengthy answer, Jev returns structured decisions - choices, scores or probabilities.

So let’s look at a simple example.

I want to haul 400 tonnes from Heading A14 to Surface Pad 3. Truck HT433 has a defect. Is it better to move truck HT312 from Level 4 or to just extend the working time for the remaining truck HT120?

At first glance, this sounds like a perfect question for Jev.

But it isn’t. At least, not yet.

Calculate what can be calculated

There are two categories of information involved here.

Production targets, haul capacity, travel times, truck routes and operator hours are all numbers. Based on these numbers, you can calculate an answer. A single, clear answer, without any of the inherent fuzziness that comes with AI.

If moving HT312 takes 22 minutes, causes 40 minutes of delay elsewhere and results in 30 tonnes of lost production, while extending the current activity causes 18 tonnes of lost production, you don’t need an AI model to tell you what those numbers mean.

You need maths.

Adding Jev on top wouldn’t make the answer better. If anything, it would make a deterministic answer unnecessarily fuzzy.

Where Jev becomes interesting

Things change when the other kind of information gets involved.

Written comments. Supervisor notes. Shift messages. Maintenance observations. Everything from the vague and often tonality-dependent world of human communication.

Imagine the scheduling system says that Heading B12 will become available in 45 minutes.

But the shift notes say:

“Heading should be ready shortly.”

That’s useful information, but not particularly precise.

Or:

“Heading is technically released, but ventilation is still being checked.”

Or:

“Heading won’t be available this shift.”

A human supervisor understands the difference between these statements immediately.

Traditional scheduling software doesn’t.

This is where Jev becomes interesting. It can interpret these inputs and turn them into structured judgments - for example, scoring the expected readiness of a workplace from unavailable through uncertain to likely available.

And that structured judgment can become another input into the scheduling process.

Connecting two versions of the mine

This gets to what I think is the genuinely interesting use case for Jev in mine operations.

A modern mine effectively has two parallel descriptions of its current state.

The first is the machine-readable one:

• vehicle positions;
• tonnes moved;
• cycle times;
• equipment availability;
• travel times;
• delays;
• schedules;
• production targets;
• telemetry.

Operations software is very good at dealing with this world.

But then there is the human version of the mine:

“Truck 17 has been running rough all shift.”

“640 should be cleared soon.”

“The development crew is already behind.”

“Maintenance thinks they’ll have it running again in about an hour.”

“I’d prioritize 14 West tonight.”

Humans are remarkably good at combining these two worlds. A supervisor can look at the numbers, remember a radio conversation, read the shift notes and incorporate all of it into a decision.

Software traditionally struggles with the second half.

And that is potentially where Jev fits.

It provides a layer between the way we actually operate on site and the clean world of computable numbers.

Jev doesn’t replace the maths

This distinction is important.

I wouldn’t ask Jev to calculate travel times, predict production from known cycle times or determine whether there are enough operator hours remaining in a shift.

We have much better tools for that.

Instead, the architecture becomes something like this:

Operational data → quantitative analysis → human context → Jev → optimization → decision

The quantitative system calculates everything that can be calculated.

Jev interprets the information that can’t easily be expressed as numbers.

The optimizer can then evaluate the available options using both.

This becomes particularly interesting when combined with the quantitative side of an operations platform such as Hivekit.

Our OPS.ai already calculates travel times, production impact, schedule dependencies and historical performance. It can analyze time-series data, identify anomalies and establish the quantitative context around an operational event.

Jev can add judgments derived from less structured operational context.

Together, they provide a much more complete representation of what is actually happening on site.

But there is one more layer

There is an important problem with all of this.

AI models are probabilistic.

Mine safety isn’t.

Imagine an operator writes:

“Tyre looks pretty bad, but I reckon I can get another half hour out of it.”

That is valuable operational information. A decision model can interpret what the operator is saying and incorporate the observation into the wider operational context.

But it absolutely shouldn’t get to decide that running the truck for another half hour is therefore acceptable.

If site policy says suspected tyre damage requires the truck to stop and be inspected, that’s the end of the discussion.

This is why we can’t leave the final call to Jev - or, for that matter, any other AI model.

In OPS.ai, our compliance and safety layer performs the final check before any decision option is passed on. Hard rules around safety, regulation, equipment compatibility, capacities and other operational constraints are applied deterministically.

AI can inform the decision.

It can’t redefine the rules.

So, is Jev useful in mining?

Yes - but probably not for the reason you might initially think.

Jev isn’t particularly interesting because it can replace the maths behind mine operations. It can’t - and it shouldn’t.

Its value is in giving operational software a practical way to incorporate the fuzzy, contextual information that humans use alongside those numbers every day.

That potentially fills an important gap.

Calculate what can be calculated.

Use AI to interpret what can’t.

And keep hard operational and safety constraints deterministic.

That’s where we think decision models such as Jev could become genuinely useful in mine operations and have started incorporating them into our OPS.ai system.