DumbestSmartModel
The Dumbest Smart Model In The Room
01 September 2026
Written by: Mathias Carlsen, whitson
There’s a funny problem with machine learning.
Give an ML model enough data and it will find relationships that make you feel like you’ve discovered fire.
Then you look a little closer.
And … EUR correlates with API number !?
😂
For anyone outside oil and gas, an API number is basically an identification number assigned to a well.
It should not determine how much oil that well produces.
But the machine doesn’t know that.
It doesn’t know geology.
It doesn’t know reservoir engineering.
It doesn’t know physics.
It just knows:
“When this number looks like this, EUR tends to look like that.”
And statistically, it might even be right.
That was one of the main reasons we wanted to build whitsonX.
There were already plenty of ML solutions. When we started looking at the market, we didn’t think the problem was a lack of machine learning models out there.
Quite the opposite.
There were already numerous data-driven and ML-based internal and third-party solutions for forecasting wells, estimating EUR, optimizing development, and identifying patterns across large datasets.
The algorithms were often impressive.
The problem, in our view, was that many of them did not incorporate first-principles reservoir engineering to the degree required for broad adoption by the petroleum engineering community.
And that matters.
A petroleum engineer is not just asking:
“Does this model fit the historical data?”
They are asking:
“Does this make physical sense?”
That is a much higher bar.
The model doesn’t know when it’s being stupid.
Pure ML models can discover incredibly powerful patterns.
They can process thousands of wells.
They can find interactions between variables that a human would never spot.
They can recognize nonlinear relationships.
They can do it faster than any reservoir engineer working manually.
But they have one major weakness:
They have no inherent understanding of whether a relationship makes physical sense.
Imagine you give a model production data from thousands of shale wells.
It sees:
· completion design
· well spacing
· lateral length
· geology
· pressure
· fluid properties
· production history
· GOR
· location
· API number
· operator
· vintage
The model doesn’t distinguish between a variable describing reservoir physics and a variable that simply happens to correlate with it.
To the algorithm, they are all just columns.
And correlation can be very convincing.
Here’s a better question
Take something as simple as GOR.
Suppose you have three wells:
A child well.
A tightly spaced well.
A loosely spaced well.
Should their GOR profiles evolve exactly the same way?
There’s a funny problem with machine learning.
Give an ML model enough data and it will find relationships that make you feel like you’ve discovered fire.
Then you look a little closer.
And … EUR correlates with API number !?
😂
For anyone outside oil and gas, an API number is basically an identification number assigned to a well.
It should not determine how much oil that well produces.
But the machine doesn’t know that.
It doesn’t know geology.
It doesn’t know reservoir engineering.
It doesn’t know physics.
It just knows:
“When this number looks like this, EUR tends to look like that.”
And statistically, it might even be right.
That was one of the main reasons we wanted to build whitsonX.
There were already plenty of ML solutions. When we started looking at the market, we didn’t think the problem was a lack of machine learning models out there.
Quite the opposite.
There were already numerous data-driven and ML-based internal and third-party solutions for forecasting wells, estimating EUR, optimizing development, and identifying patterns across large datasets.
The algorithms were often impressive.
The problem, in our view, was that many of them did not incorporate first-principles reservoir engineering to the degree required for broad adoption by the petroleum engineering community.
And that matters.
A petroleum engineer is not just asking:
“Does this model fit the historical data?”
They are asking:
“Does this make physical sense?”
That is a much higher bar.
The model doesn’t know when it’s being stupid.
Pure ML models can discover incredibly powerful patterns.
They can process thousands of wells.
They can find interactions between variables that a human would never spot.
They can recognize nonlinear relationships.
They can do it faster than any reservoir engineer working manually.
But they have one major weakness:
They have no inherent understanding of whether a relationship makes physical sense.
Imagine you give a model production data from thousands of shale wells.
It sees:
· completion design
· well spacing
· lateral length
· geology
· pressure
· fluid properties
· production history
· GOR
· location
· API number
· operator
· vintage
The model doesn’t distinguish between a variable describing reservoir physics and a variable that simply happens to correlate with it.
To the algorithm, they are all just columns.
And correlation can be very convincing.
Here’s a better question
Take something as simple as GOR.
Suppose you have three wells:
A child well.
A tightly spaced well.
A loosely spaced well.
Should their GOR profiles evolve exactly the same way?
A reservoir engineer immediately starts thinking about pressure depletion, communication between wells, fracture interactions, fluid behavior, and effective drainage volume.
The ML model?
It sees curves.
That’s the fundamental difference.
A good reservoir engineer asks:
“Why should this happen?”
A pure ML model asks:
“Does this usually happen?”
Those are not the same question.
This became the thesis behind whitsonX.
We didn’t want to build another black-box ML tool.
We wanted to combine two things that are individually powerful, but much more useful together:
Machine learning + reservoir engineering.
Not either/or.
Machine learning is extraordinarily good at pattern recognition.
Reservoir engineering is extraordinarily good at defining what relationships should physically exist.
The goal with whitsonX was to bring those two worlds together.
Let the machine analyze huge datasets.
Let it discover patterns.
Let it learn relationships we may not have thought to look for.
But anchor those relationships in the first-principles physics we already understand.
In other words:
Use ML to expand what the engineer can see, without asking the engineer to abandon what they know.
That distinction matters if you want engineers to actually trust and use the output.
Physics is not baggage
There has been a tendency in parts of the AI world to treat domain knowledge as something the model will eventually learn on its own.
Just give it more data.
Make the model bigger.
Add more compute.
Eventually it will figure everything out.
Maybe.
But in reservoir engineering, we already possess an enormous amount of useful information.
We know material balance.
We know fluid behavior.
We know pressure relationships.
We know nearby wells interact.
We know depletion changes how wells behave.
We know spacing matters.
And we know an identification number does not magically create hydrocarbons.
Why would we throw all of that away?
The best AI systems in technical industries probably won’t be the ones that ignore decades of engineering knowledge.
They’ll be the ones that know how to use it.
The hard part isn’t fitting the history
This is where I think a lot of discussions around AI and petroleum engineering miss the point.
Building a model that fits historical production is relatively easy.
The much harder question is:
Do you trust that model when you change the development plan?
What happens when you move from 660-ft spacing to 1,000-ft spacing?
What happens when you change completion intensity?
What happens when a parent well has already depleted part of the reservoir?
What happens when fluid behavior changes over time?
Now you are asking the model to move beyond interpolation.
You are asking it to reason about a system.
That is where first principles become critical.
And it is also where trust is either built or lost with the engineer using the software.
The future probably isn’t AI versus engineers
People love framing AI as a replacement story.
AI versus engineers.
Machine learning versus physics.
Data-driven models versus traditional reservoir engineering.
I think that’s the wrong framing.
The opportunity is to give engineers more leverage.
Let the computer analyze 50,000 wells.
Let it test thousands of relationships.
Let it identify patterns we would never find manually.
Let it run continuously.
But pair that capability with the physics and engineering relationships we already know should hold.
Because the goal isn’t to remove the reservoir engineer from the decision.
It’s to make the reservoir engineer dramatically more capable.
That’s what we set out to build with whitsonX.
And every once in a while, the machine still needs an engineer to tell it:
“No, the API number does not cause EUR.” 😂
If you’re working on unconventional development and want to see how whitsonX combines machine learning with first-principles reservoir engineering, reach out to carlsen@whitson.com to schedule a demo.
The ML model?
It sees curves.
That’s the fundamental difference.
A good reservoir engineer asks:
“Why should this happen?”
A pure ML model asks:
“Does this usually happen?”
Those are not the same question.
This became the thesis behind whitsonX.
We didn’t want to build another black-box ML tool.
We wanted to combine two things that are individually powerful, but much more useful together:
Machine learning + reservoir engineering.
Not either/or.
Machine learning is extraordinarily good at pattern recognition.
Reservoir engineering is extraordinarily good at defining what relationships should physically exist.
The goal with whitsonX was to bring those two worlds together.
Let the machine analyze huge datasets.
Let it discover patterns.
Let it learn relationships we may not have thought to look for.
But anchor those relationships in the first-principles physics we already understand.
In other words:
Use ML to expand what the engineer can see, without asking the engineer to abandon what they know.
That distinction matters if you want engineers to actually trust and use the output.
Physics is not baggage
There has been a tendency in parts of the AI world to treat domain knowledge as something the model will eventually learn on its own.
Just give it more data.
Make the model bigger.
Add more compute.
Eventually it will figure everything out.
Maybe.
But in reservoir engineering, we already possess an enormous amount of useful information.
We know material balance.
We know fluid behavior.
We know pressure relationships.
We know nearby wells interact.
We know depletion changes how wells behave.
We know spacing matters.
And we know an identification number does not magically create hydrocarbons.
Why would we throw all of that away?
The best AI systems in technical industries probably won’t be the ones that ignore decades of engineering knowledge.
They’ll be the ones that know how to use it.
The hard part isn’t fitting the history
This is where I think a lot of discussions around AI and petroleum engineering miss the point.
Building a model that fits historical production is relatively easy.
The much harder question is:
Do you trust that model when you change the development plan?
What happens when you move from 660-ft spacing to 1,000-ft spacing?
What happens when you change completion intensity?
What happens when a parent well has already depleted part of the reservoir?
What happens when fluid behavior changes over time?
Now you are asking the model to move beyond interpolation.
You are asking it to reason about a system.
That is where first principles become critical.
And it is also where trust is either built or lost with the engineer using the software.
The future probably isn’t AI versus engineers
People love framing AI as a replacement story.
AI versus engineers.
Machine learning versus physics.
Data-driven models versus traditional reservoir engineering.
I think that’s the wrong framing.
The opportunity is to give engineers more leverage.
Let the computer analyze 50,000 wells.
Let it test thousands of relationships.
Let it identify patterns we would never find manually.
Let it run continuously.
But pair that capability with the physics and engineering relationships we already know should hold.
Because the goal isn’t to remove the reservoir engineer from the decision.
It’s to make the reservoir engineer dramatically more capable.
That’s what we set out to build with whitsonX.
And every once in a while, the machine still needs an engineer to tell it:
“No, the API number does not cause EUR.” 😂
If you’re working on unconventional development and want to see how whitsonX combines machine learning with first-principles reservoir engineering, reach out to carlsen@whitson.com to schedule a demo.