Deterministic calculations and language-model reasoning solve different parts of an engineering question. Code should retrieve measurements, enforce units and limits, and execute reproducible calculations. An LLM is useful after that work, when the task is to route tools, compare evidence, explain uncertainty, and synthesize a qualified answer.
Do not turn calculations into language tasks
Common drilling questions route to different methods:
| Question | Primary method |
|---|---|
| Dogleg severity between two surveys? | Deterministic trajectory calculation |
| Modeled pick-up weight at 18,000 ft? | Torque-and-drag calculation |
| Expected ECD at the casing shoe? | Hydraulic calculation |
| Which offsets encountered high drag near this depth? | Retrieval and comparison |
| Why might current torque exceed those offsets? | Engineering interpretation |
| What should we investigate first? | Decision support |
Natural language is the interface, not necessarily the solver. Given the same inputs and implementation, a deterministic function should return the same result:
$$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.
Use the LLM as an orchestrator
If an engineer asks:
What is the ECD at 18,500 ft if we increase from 600 to 675 gpm?
One architecture sends the question, well description, and mud data to the LLM and asks it to calculate. A stronger architecture lets the LLM identify:
- well,
- current BHA,
- hole section,
- mud properties,
- proposed flow.
then calls a validated hydraulic calculation. The calculation returns:
- modeled ECD,
- relevant assumptions,
- perhaps current versus proposed values.
The LLM explains the result. It coordinates the engineer's intent and evidence; the hydraulic engine solves the hydraulic problem.
AIDE decomposes the request, invokes deterministic data tools, and explains the comparison; the calculations remain outside the language model.
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 requires the system to:
- resolve the well, wellbore, lateral, and current depth;
- retrieve current ROP, WOB, RPM, torque, differential pressure, and rig state;
- select offsets by formation, depth, hole section, and operating state;
- run required MSE, DOC, hydraulics, or torque-and-drag calculations;
- retrieve relevant offset performance, reports, BHA details, and prior issues; and
- let the LLM reason across the assembled evidence.
The important part is that the LLM did not generate the evidence. It assembled and interpreted it.
Preserve epistemic type
A useful information hierarchy keeps the evidence type visible:
| Type | Meaning | Example |
|---|---|---|
| Measured | Reported by a sensor or operational source | Surface RPM = 120 rpm |
| Deterministically calculated | Produced by a defined engineering function | Minimum-curvature TVD = 12,740 ft |
| Modeled | Produced by a physical model with assumptions | Modeled ECD = 12.3 ppg |
| Statistically inferred | Estimated from uncertain evidence | Washout evidence is increasing |
| Retrieved | Located in an existing record | Offset DDR reports 11.8-ppg mud |
| LLM interpretation | Synthesis of the preceding evidence | A qualified engineering explanation |
For 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.
Stop when required inputs are missing
If a torque-and-drag request is missing mud weight, 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:
-
retrieve the current mud weight from an authorized source,
-
ask the engineer for it,
-
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.
Deterministic does not mean exact
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.
Worked example and guardrails
Take 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 separates retrieval, calculation, and interpretation:
| Stage | Required work |
|---|---|
| Resolve state | Retrieve the well, wellbore, current depth, and rig state. |
| Check limits | Identify the BHA, motor, pump limits, and surface-pressure constraints. |
| Load mud context | Resolve MW, rheology, and temperature context where applicable. |
| Run hydraulics | Calculate current and proposed SPP, ECD, annular velocity, and other relevant outputs. |
| Retrieve history | Find offsets with comparable hole size, lateral depth, mud, and flow. |
| Compare current response | Check measured versus modeled SPP, returns, and hole-cleaning evidence. |
| Synthesize | Let the LLM explain the tradeoff using disclosed results and limits. |
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.
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. 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.
Related technical resources
- Engineering Context in Drilling RAG: Why Semantic Similarity Is Not Enough
- Evaluating the Reliability of an AI Drilling Assistant
- When “Unable to Determine” Is the Correct Output in Drilling Analytics
References
- 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.