Why Deterministic Engineering Calculations and LLM Reasoning Should Coexist in Drilling

A language model is well suited to finding evidence, connecting context, and explaining engineering results. It should not replace physics models, validated calculations, or the measurements on which drilling decisions depend.

Ask a drilling engineer:

What is the expected standpipe pressure at 650 gpm?

That sounds like a question.

But it is really a calculation.

To answer it properly, we may need:

• drillstring geometry,
• casing and hole geometry,
• mud density,
• rheology,
• bit nozzles,
• flow rate,
• RPM,
• eccentricity assumptions,
• current depth.

Now ask:

Why has standpipe pressure been falling for the last two hours even though pump rate is unchanged?

That is a different problem.

The answer may require:

• the hydraulic calculation,
• actual pressure history,
• pump behavior,
• flow out,
• current rig state,
• recent equipment changes,
• sensor-quality information,
• perhaps offset or historical events.

The first problem is mostly computational.

The second requires reasoning across several forms of evidence.

This distinction is central to useful AI in drilling.

A large language model can write an equation.

It can even generate a plausible numerical answer.

But plausibility is not the engineering requirement.

The engineering requirement is that:

1. the correct data was used,
2. the correct method was applied,
3. assumptions are visible,
4. the result can be reproduced,
5. uncertainty is represented honestly.

That leads to a much more useful architecture for drilling AI:

Do not ask one model to do everything.

Use:

• sensors for measurements,
• deterministic engineering tools for calculations,
• statistical or probabilistic models for uncertain inference,
• retrieval systems for historical and documentary evidence,
• and LLMs for interpretation, synthesis, and interaction.

The intelligence comes from how those layers work together.

A reliable drilling AI architecture assigns measurement, calculation, inference, retrieval, and reasoning to different layers.

Not Every Engineering Question Is a Language Problem

Consider several common drilling questions.

What is the dogleg severity between these two surveys?

That is a deterministic calculation.

What is the modeled pick-up weight at 18,000 ft?

That is a torque-and-drag calculation.

What ECD should we expect at the casing shoe?

That is a hydraulic calculation.

Which offset wells encountered high drag near this depth?

That is primarily a data-retrieval and comparison problem.

Why might current torque be higher than on those offsets?

That requires engineering interpretation.

What should we investigate first?

That becomes a decision-support problem.

All six questions can be expressed in natural language.

That does not mean all six should be answered by a language model.

Natural language is the interface.

The underlying problem type still matters.

Deterministic Calculations Have Properties LLMs Do Not

A deterministic engineering function has a powerful property:

given the same inputs and the same implementation, it should return the same result.

Conceptually:

$$y=f(x_1,x_2,\ldots,x_n)$$

If a minimum-curvature function receives:

• MD,
• inclination,
• azimuth,

it calculates a defined trajectory.

If a hydraulic model receives a defined:

• geometry,
• fluid model,
• rheology,
• flow rate,

it returns a calculated pressure response according to that model.

The calculation may contain assumptions.

The inputs may contain uncertainty.

The model may have limitations.

But the computational path is explicit.

That makes it:

• testable,
• versionable,
• reproducible,
• auditable.

An LLM has different strengths.

Its output is generated probabilistically from context.

That is useful for language and reasoning.

It is not the property we normally want from a safety-relevant engineering equation.

A Language Model Should Call the Calculator, Not Imitate It

Suppose an engineer asks:

What is the ECD at 18,500 ft if we increase from 600 to 675 gpm?

There are two possible architectures.

Architecture A

Send the question, well description, and some mud data to the LLM.

Ask it to calculate the answer.

Architecture B

The LLM interprets the request.

It identifies:

• well,
• current BHA,
• hole section,
• mud properties,
• proposed flow.

It then calls a validated hydraulic calculation.

The calculation returns:

• modeled ECD,
• relevant assumptions,
• perhaps current versus proposed values.

The LLM explains the result.

Architecture B is much stronger.

The LLM is doing what it is good at:

understanding the engineer's intent and coordinating information.

The hydraulic engine is doing what it is good at:

solving the hydraulic problem.

The language model should invoke the validated calculation and explain its assumptions, not imitate the engineering calculator.

This Is Already How Advanced Real-Time Drilling Analytics Work

The principle predates modern LLMs.

Published real-time drilling systems already separate:

measurement

from:

model

from:

inference.

SPE-191797 describes a real-time hydraulic workflow in which:

• pump strokes,
• pressure,
• RPM,
• flow-out,

are combined with:

• mud properties,
• drillstring geometry,
• casing geometry,
• rig state,

and then routed into a physical hydraulic model.

The model's predicted pressure can then be compared with actual measured pressure.

The difference between model and reality becomes evidence for subsequent event analysis.

The system does not ask one algorithm to invent:

• the measured pressure,
• the hydraulic prediction,
• and the diagnosis.

Those are separate layers.

The same architecture works extremely well when an LLM is added.

The LLM Is an Orchestrator

A useful engineering LLM can function as an orchestrator.

The engineer asks:

Compare our current lateral performance with the three best offsets and tell me whether the lower ROP looks mechanical or geological.

That request may require several steps.

Step 1 — Resolve context

Which:

• well,
• wellbore,
• lateral,
• current depth?

Step 2 — Retrieve current data

Perhaps:

• ROP,
• WOB,
• RPM,
• torque,
• differential pressure,
• rig state.

Step 3 — Find comparable offsets

Apply:

• formation,
• depth,
• hole section,
• operating-state constraints.

Step 4 — Run deterministic calculations

Possibly:

• MSE,
• DOC,
• hydraulics,
• torque and drag.

Step 5 — Retrieve historical evidence

Examples:

• offset performance,
• daily reports,
• BHA details,
• previous issues.

Step 6 — Reason across the evidence

Now the LLM can produce an engineering explanation.

The important part is that the LLM did not generate the evidence.

It assembled and interpreted it.

The reasoning layer routes an engineering question to the data, physics, context, offset, and report tools needed for an evidence-backed explanation.

Retrieval and Calculation Solve Different Problems

This distinction is sometimes blurred in RAG discussions.

Retrieval answers:

What relevant information already exists?

Calculation answers:

What follows mathematically from the current inputs?

Suppose an engineer asks:

What was our best lateral ROP on comparable wells, and what ECD would we expect if we copied the current flow program?

The first part requires historical retrieval.

The second requires a hydraulic calculation.

A vector database should not calculate ECD.

A hydraulic model should not decide which historical well is semantically relevant to the question.

The LLM can coordinate both.

Retrieving evidence and calculating physics solve different problems before LLM synthesis.

Measurements Must Stay Distinguishable from Calculations

Suppose an AI answer states:

ECD is 12.4 ppg.

What does that mean?

Possible sources:

• measured PWD,
• calculated hydraulic model,
• historical report,
• manually entered value,
• LLM-generated estimate.

Those are very different.

A useful engineering answer should say:

PWD-measured ECD: 12.4 ppg

or:

Modeled ECD: 12.4 ppg

That provenance matters.

The same is true for:

• WOB,
• torque,
• inclination,
• ROP,
• friction factor.

The earlier article on surface versus downhole parameters showed why even two legitimate values called "WOB" can represent different physical quantities.

An AI system should preserve that distinction rather than flattening everything into prose.

Measured, Calculated, Inferred, and Retrieved Should Be Separate

A useful information hierarchy is:

Measured

Directly reported by a sensor or operational data source.

Example:

Surface RPM = 120 rpm

Deterministically calculated

Produced by a defined engineering function.

Example:

Minimum-curvature TVD = 12,740 ft

Modeled

Produced by a physical model with assumptions.

Example:

Modeled ECD = 12.3 ppg

Statistically inferred

Estimated from multiple uncertain inputs.

Example:

Evidence of washout is increasing

Retrieved

A statement located in an existing document or record.

Example:

Offset DDR reports 11.8-ppg mud at this depth

LLM interpretation

An engineering synthesis of those pieces.

Example:

Current pressure loss is below the modeled expectation, while offset hydraulics were similar. The pattern warrants checking for a circulating-system change before attributing it to formation.

Those categories should not be presented as though they have equal epistemic status.

Provenance keeps measured, calculated, modeled, inferred, and retrieved information distinct before interpretation.

"AI Confidence" Is Not a Substitute for Evidence

A common interface pattern is:

Confidence: 87%

That can look reassuring.

But confidence in what?

Was 87%:

• classifier probability?
• calibrated probability?
• LLM self-assessment?
• similarity score?
• arbitrary UI output?

For engineering decisions, evidence is much more useful.

Instead of:

87% confident this is a washout

an engineer benefits more from:

• pump rate stable,
• SPP down 320 psi,
• modeled pressure unchanged,
• flow out stable,
• sensor validation normal.

Now the conclusion can be inspected.

This is the same human-factors principle discussed in the alert article:

Show why the system reached the conclusion.

An LLM Should Never Quietly Invent Missing Engineering Inputs

Suppose a torque-and-drag request is missing mud weight.

What should happen?

A poor system may assume:

12.0 ppg

because that value seems plausible.

The answer looks complete.

The engineering chain is broken.

A stronger system should either:

1. retrieve the current mud weight from an authorized source,
2. ask the engineer for it,
3. or clearly state that the calculation cannot be completed reliably.

This is where engineering AI differs from ordinary conversational assistance.

A missing input is often not a language inconvenience.

It is a calculation constraint.

Missing engineering input should trigger retrieval, clarification, or an explicit limit—not a plausible guess.

Tool Schemas Act as Engineering Guardrails

A structured engineering tool might require:

well_id
bit_depth
flow_rate
mud_weight
rheology
BHA
wellbore_geometry

The LLM cannot call the tool successfully without satisfying the input contract.

That is useful.

The schema acts as a guardrail.

Instead of letting the LLM decide casually which information matters, the engineering tool explicitly defines the required inputs.

The architecture therefore embeds domain knowledge in software rather than hoping it appears in generated reasoning.

Tool Outputs Should Also Be Structured

Suppose a hydraulic tool returns only:

12.43

The LLM must guess what that means.

A better result includes:

ecd_ppg: 12.43
depth_md_ft: 18500
flow_gpm: 675
model: Herschel-Bulkley
calculation_status: valid
input_timestamp: ...

Possibly also:

• data-quality state,
• model version,
• assumption warnings.

Structured outputs make it harder for downstream reasoning to misinterpret the result.

The LLM Can Add Value Where Equations Stop

Consider a deterministic result:

Modeled ECD rises 0.35 ppg when flow increases from 600 to 675 gpm.

The calculation is complete.

The engineering decision may not be.

The engineer may also need to know:

• current pressure margin,
• formation strength,
• whether the previous offset tolerated that ECD,
• whether hole cleaning has been marginal,
• why the higher flow is being considered.

That is where higher-level reasoning becomes valuable.

The LLM can connect:

calculated effect

with:

operational objective

and:

historical context.

It might explain:

The additional flow improves annular transport but raises modeled ECD. The tradeoff appears acceptable relative to the selected offset history, although the current section is already operating closer to the modeled pressure margin than those wells.

That is not a new equation.

It is an engineering synthesis.

Deterministic Does Not Mean Perfect

There is an important caution.

Calling a deterministic tool does not make its output ground truth.

A hydraulic model may contain error because of:

• uncertain rheology,
• washout,
• temperature assumptions,
• geometry,
• eccentricity.

SPE-191797 validates its real-time hydraulic model against PWD data and explicitly discusses the tradeoff between a computationally efficient steady-state solution and more computationally expensive transient modeling.

That is good engineering.

The model has:

• a defined purpose,
• validation,
• known limitations.

The LLM should preserve those limitations when explaining the result.

A deterministic model provides reproducibility, but its engineering validity still depends on inputs, assumptions, and validation against field behavior.

Probabilistic Models Belong Between Physics and Language

Not every drilling question has a deterministic answer.

Consider:

Is this a washout?

There is no equation:

$$Washout = Yes$$

Instead we may have evidence:

• pressure divergence,
• pump rate,
• flow out,
• trend duration,
• hydraulic-model residual.

Those observations can support a probabilistic inference.

Similarly:

Is the bit becoming ineffective?

or:

Is this overpull significant?

may require uncertain inference.

SPE-186166 and SPE-191426 show examples of measured and derived drilling parameters being transformed into probabilistic features for dysfunction or tripping-event analysis.

That creates another clean layer:

$$Measurements + Physics \rightarrow Probabilistic\ Inference$$

Then the LLM explains:

• what the probability represents,
• what evidence contributed,
• what competing interpretations remain.

LLM Reasoning Is Not the Same as a Probabilistic Engineering Model

This is another important distinction.

Both may involve probabilities in some sense.

But they are not the same.

A Bayesian drilling model may contain explicitly defined:

• states,
• priors,
• conditional relationships,
• feature mappings.

An LLM generates language based on learned statistical relationships across tokens and supplied context.

A sentence such as:

Washout is likely

generated by an LLM should not be treated automatically as equivalent to:

P(washout)=0.78

from a calibrated event model.

The LLM may report the model result.

It should not quietly impersonate it.

Retrieval-Augmented Generation Helps With Evidence, Not Truth by Itself

RAG is often described as a solution to hallucination.

It helps.

But retrieval does not automatically make the final answer correct.

A retrieval system can return:

• the wrong well,
• an obsolete procedure,
• a nearby but geologically different offset,
• a morning report from the wrong BHA,
• several documents that disagree.

The LLM still has to reason about relevance.

That is why drilling RAG requires more than text similarity.

It needs engineering context.

Drilling Retrieval Has a Hierarchy Problem

Suppose an engineer asks:

What mud weight did we use on the last lateral?

The system must resolve:

• which field?
• which pad?
• which well?
• which wellbore?
• main bore or sidetrack?
• which hole section?
• which point in time?

A generic search for:

last lateral mud weight

may retrieve a technically similar sentence from the wrong well.

In drilling, entity relationships matter.

A useful hierarchy might include:

$$Field \rightarrow Pad \rightarrow Well \rightarrow Wellbore \rightarrow BHA\ Run \rightarrow Depth / Time$$

Semantic similarity alone does not encode all of that.

Technical similarity alone is not sufficient for drilling retrieval; context, engineering filters, and authorization determine relevance.

Depth Is Part of Meaning

Consider this sentence in a drilling report:

Increased mud weight to 12.0 ppg.

When?

At what depth?

Before or after casing?

Main bore or sidetrack?

A RAG system that retrieves the sentence but loses its depth/time relationship has not preserved the full engineering meaning.

This is one reason drilling knowledge systems should connect text with structured operational context.

The ideal retrieved evidence may include:

• document text,
• well identity,
• wellbore,
• timestamp,
• depth interval,
• BHA/run,
• source type.

Now the LLM can reason with the information correctly.

Current Data and Historical Knowledge Have Different Freshness

An AI drilling assistant may simultaneously use:

Live data

seconds old.

Daily report

hours old.

Survey

perhaps minutes or hours old.

BHA specification

current for the run.

Offset report

years old.

Technical paper

evergreen engineering background.

These sources should not be treated equally when answering:

What is happening right now?

Freshness and source type should be part of the reasoning.

If the live depth is 18,450 ft but the latest DDR ends at 17,900 ft, the daily report should not override the real-time source for current depth.

Source Authority Is Question-Dependent

The most authoritative source also changes by question.

Current surface RPM

live rig stream.

Current BHA configuration

validated BHA record.

Historical mud issue

DDR or operational note.

Hydraulic pressure

calculated model plus measured pressure.

General engineering guidance

technical procedure, standard, or vetted literature.

There is no universal ranking where one source always wins.

The system should choose the source appropriate to the field being answered.

A Good Engineering AI Answer Can Show Its Evidence Chain

Consider the question:

Why is ROP falling in the last two stands?

A useful answer could separate:

Measured

• rotary ROP fell from 220 to 165 ft/hr,
• WOB remained 34–36 klbf,
• RPM remained 125–130,
• torque increased approximately 12%.

Calculated

• DOC decreased,
• MSE increased.

Retrieved context

• current interval is approaching a known harder formation marker,
• comparable offsets also showed reduced ROP in this interval.

Interpretation

Much of the ROP reduction is consistent with the formation transition, although the simultaneous torque increase warrants watching for developing dysfunction. Current evidence does not isolate a unique mechanical cause.

That structure is much stronger than:

ROP is dropping because the formation is harder.

The latter may be correct.

The former shows why.

This Architecture Also Makes Errors Easier to Diagnose

Suppose the final answer is wrong.

Where did the failure occur?

Possibilities include:

• sensor,
• contextual database,
• retrieval,
• deterministic model,
• probabilistic model,
• LLM interpretation.

Separating layers allows the error to be traced.

A monolithic AI answer does not.

This matters enormously for engineering improvement.

If the wrong BHA was retrieved, changing the language prompt does not solve the problem.

If hydraulic inputs were stale, retraining the LLM does not solve the problem.

If the physics model itself is biased, better RAG does not solve the problem.

Architecture makes root-cause analysis possible.

A Practical Example: "Can We Increase Flow?"

Consider a hypothetical question:

We're at 18,600 ft in the lateral at 625 gpm. Hole cleaning has been marginal. Can we go to 675?

A robust workflow might proceed as follows.

1. Resolve current state

Retrieve:

• well,
• wellbore,
• current depth,
• rig state.

2. Retrieve equipment limits

Identify:

• BHA,
• motor,
• pump limits,
• surface pressure constraints.

3. Retrieve current mud context

• MW,
• PV/YP or rheological model,
• temperature context if applicable.

4. Run hydraulics

Calculate current versus proposed:

• SPP,
• ECD,
• annular velocity or other relevant outputs.

5. Retrieve historical context

Find comparable offsets:

• same hole size,
• similar lateral depth,
• similar mud,
• perhaps similar flow.

6. Check current measured response

Compare:

• measured SPP,
• modeled SPP,
• returns,
• hole-cleaning indicators.

7. LLM synthesis

Now explain the tradeoff.

For example:

Increasing to 675 gpm raises modeled ECD by 0.3 ppg and modeled SPP by approximately 420 psi. Those values remain within the currently supplied operating limits. Comparable offsets used 650–675 gpm in this interval. Given the current hole-cleaning concern, the higher flow is mechanically plausible, but verify the actual SPP response after the change because measured pressure has recently been running above model.

The numbers come from tools.

The interpretation comes from reasoning.

That division is the point.

A flow-change question becomes defensible only after current data, equipment limits, mud context, hydraulics, and offset evidence are assembled.

The LLM Should Be Able to Say "I Cannot Calculate That Yet"

This is a feature, not a weakness.

An engineering system should be allowed to say:

The latest mud rheology is unavailable, so I cannot calculate a defensible ECD for the proposed flow increase.

or:

I found two conflicting BHA records; I need the active run resolved before calculating torque and drag.

That response is much safer than constructing a plausible answer from incomplete context.

The system's usefulness is not measured by how often it produces an answer.

It is measured by how often the answer deserves engineering confidence.

Guardrails Should Exist in Code, Not Only in Prompts

A prompt can tell an LLM:

Never invent mud weight.

That helps.

But a stronger system also:

• requires the field for the engineering tool,
• validates units,
• checks data freshness,
• confirms well identity,
• restricts tool permissions.

Prompts guide behavior.

Software constraints enforce behavior.

High-value engineering systems should use both.

Tool Access Should Be Authorized and Scoped

An AI agent may be able to retrieve:

• live well data,
• historical wells,
• reports,
• engineering calculations.

That power needs boundaries.

The tool layer should control:

• which wells the user can access,
• which functions are read-only,
• which data sources are authorized.

The LLM should not determine access simply because the user can phrase a request.

Security belongs below the reasoning layer.

AIDE as an Implementation Example

A natural implementation example is AIDE, the AI Drilling Expert architecture used with DrillingMetrics.

At a high level, the approach connects an LLM to authorized:

• live drilling data,
• historical wells,
• reports,
• domain knowledge,
• deterministic engineering calculations.

The important design principle is not the brand name.

It is the separation of roles.

The LLM acts as the conversational and reasoning layer.

The underlying drilling platform remains responsible for the structured engineering data and calculations.

That is a much more defensible architecture than asking the language model to recreate drilling engineering from memory.

AIDE uses an authorized KPI query tool to retrieve the maximum recorded SPP for the specified drill-pipe size and presents the supporting record.

AIDE decomposes a lateral-performance comparison into scoped KPI queries and a chart task, then returns the retrieved well-level records.

The Goal Is Not to Replace the Engineer

This architecture produces an interesting result.

The better the underlying tools become, the less the LLM needs to pretend to be the source of engineering truth.

Its role becomes clearer:

• translate intent,
• find information,
• invoke calculations,
• connect evidence,
• identify conflicts,
• explain tradeoffs,
• preserve uncertainty.

The engineer remains responsible for the operational decision.

This is not a limitation.

It is a useful allocation of responsibilities.

The Most Important Question Is "Where Did This Answer Come From?"

When an engineering assistant provides:

13.1 ppg

the user should be able to determine whether that number came from:

• sensor,
• report,
• calculation,
• historical record,
• model,
• generated reasoning.

When it says:

washout is possible

the user should see:

• which evidence supports that conclusion,
• which alternative explanations remain.

When it recommends:

review higher RPM

the engineer should know whether that guidance came from:

• operating history,
• a dysfunction model,
• technical procedure,
• or generic LLM reasoning.

Provenance is not merely a citation feature.

It is part of engineering meaning.

A Practical Reliability Hierarchy

A strong AI drilling workflow can be thought of as a hierarchy:

1. Do not generate measurements

Retrieve them.

2. Do not generate deterministic calculations

Run them.

3. Do not invent historical facts

Retrieve them with provenance.

4. Do not convert uncertainty into false certainty

Preserve it.

5. Use the LLM where synthesis is actually required

Explain:

• relationships,
• conflicts,
• consequences,
• next investigative steps.

This keeps the language model inside the part of the problem where its flexibility provides the most value.

Engineering reliability starts with measurements and validated calculations; language reasoning belongs at the synthesis layer.

From Conversational AI to Engineering Intelligence

A generic chatbot is optimized to produce a useful response to a question.

An engineering intelligence system has a more demanding objective:

produce a response whose evidence and computation can withstand engineering scrutiny.

That requires architecture.

The strongest drilling AI will therefore probably not be the system with the largest language model.

It will be the system with the best connection between:

• trustworthy live data,
• well context,
• validated calculations,
• historical evidence,
• domain models,
• and language-based reasoning.

The LLM is extremely valuable because it makes those systems accessible through natural engineering questions.

But natural language should be the interface to the engineering system.

It should not become a substitute for the engineering system.

Conclusion

Drilling already contains many types of intelligence.

A hydraulic model understands fluid pressure relationships.

A torque-and-drag model understands mechanical load transfer.

A rig-state classifier understands operational activity.

A historical database contains what happened on previous wells.

A technical document contains engineering knowledge.

An LLM contributes something different:

the ability to interpret an engineer's intent and reason across those sources in natural language.

The strongest architecture therefore does not ask:

Should we use physics or AI?

It asks:

Which parts of this engineering question should be measured, calculated, inferred, retrieved, and reasoned about?

Once those roles are separated, the answer becomes clearer.

Use deterministic tools where the physics is defined.

Use probabilistic models where uncertainty must be quantified.

Use retrieval where evidence already exists.

Use the LLM to connect those pieces into an explanation an engineer can inspect and act on.

That is a much stronger definition of drilling AI than asking a language model to know everything itself.

---

References

1. Shahri, M., Kutlu, B., Thetford, T., Nelson, B., Wilson, T., Behounek, M., Ambrus, A., and Ashok, P. Adopting Physical Models in Real-Time Drilling Application: Wellbore Hydraulics. SPE-191797-MS, SPE Liquids-Rich Basins Conference—North America, Midland, Texas, 2018.

2. Shahri, M., Wilson, T., Thetford, T., Nelson, B., Behounek, M., Ambrus, A., D'Angelo, J., and Ashok, P. Implementation of a Fully Automated Real-Time Torque and Drag Model for Improving Drilling Performance: Case Study. SPE-191426-MS, SPE Annual Technical Conference and Exhibition, Dallas, Texas, 2018.

3. Ambrus, A., Ashok, P., Chintapalli, A., Ramos, D., Behounek, M., Thetford, T. S., and Nelson, B. A Novel Probabilistic Rig Based Drilling Optimization Index to Improve Drilling Performance. SPE-186166-MS, SPE Offshore Europe Conference & Exhibition, Aberdeen, United Kingdom, 2017.

4. Behounek, M., Thetford, T., Yang, L., Hofer, E., White, M., Ashok, P., Ambrus, A., and Ramos, D. Human Factors Engineering in the Design and Deployment of a Novel Data Aggregation and Distribution System for Drilling Operations. SPE/IADC-184743-MS, SPE/IADC Drilling Conference and Exhibition, The Hague, Netherlands, 2017.