Engineering insights

Why drilling engineering software keeps losing context.

This page sets out how Atlas WellTech thinks about drilling engineering software — the problems we consider structural, the language we use precisely, and the boundaries we do not cross. It is a position, not a promise.

Spreadsheets
Specialist applications
Vendor / manufacturer information
Engineering reports
Historical well data
Company procedures
Individual engineering workflows
Operational information

Integrated environment

One governed engineering context

ATLAS is designed so engineering inputs, analysis, assumptions and evidence sit in the same place, with their origin intact.

Perspective 01

Fragmentation is a data-governance problem wearing a workflow costume.

Engineers rarely lack tools. What they lack is one place where the design, the analysis and the basis for both agree with each other.

A well is planned in one application, analysed in another, documented in a third and reported from a fourth. Each step is individually defensible. The cost appears in the joins: values are re-entered, assumptions are re-stated informally, and the reasoning that connected them stays in the head of whoever did the work.

Treated as a workflow problem, this invites more integrations. Treated as a governance problem, it invites a different answer: hold the engineering information once, under control, and let the workflow read from it. That is the premise ATLAS is built on.

Perspective 02

Available data is not governed data.

A shared drive can make information available. Only control makes it usable as engineering evidence.

The practical test is simple: can you say where a value came from, which revision applied when it was used, and who accepted it? If any of those answers requires asking a person, the information was available rather than governed.

This is why source, version, status and decision are treated as structure in ATLAS rather than as metadata added for tidiness. Company-approved standards and current authorised vendor data always take precedence over repository content.

01
Source
Where the value originates
02
Evidence
What supports it
03
Version
Which revision applies
04
Decision
What the engineer concluded

Lineage is retained so a reviewer can reconstruct how an engineering conclusion was reached.

Perspective 03

Intelligence should sharpen judgement, not imitate it.

The useful contribution of software here is context, comparison and evidence — not a verdict.

Combining engineering models, governed information, operational context and historical results genuinely shortens the distance to a well-informed decision. It does not transfer engineering responsibility, and a platform that implies otherwise creates risk rather than removing it.

So the boundary is stated everywhere it applies: ATLAS suggests, records and evidences. The engineer verifies and decides.

Terminology

The words we use, defined.

These terms recur across this website. They are defined here so they are read the way they are meant.

Engineering context: The objectives, constraints, assumptions and inputs that make an engineering result meaningful. Without it, a number is just a number.
Governed engineering data: Information whose source, revision and status are known and controlled — as opposed to information that is merely available.
Traceability: The ability to follow an engineering conclusion back through its inputs to where each value originated.
Assurance: The combination of retained evidence, recorded reasoning and explicit human verification that lets engineering work withstand review.
Decision support: Information and analysis offered to inform an engineering decision, without carrying the authority to make it.
Operational learning: The structural capture of well outcomes so the next well begins with more than the last team's recollection.

Discuss this with us The assurance model