AI/ML engineering · Oil and gas
AI for well log and seismic interpretation
We build AI for well log and seismic interpretation for operators, national oil companies and regulators: automated quality control of logs, facies classification, prediction of missing curves, detection of faults and horizons in seismic volumes, and consistent interpretation across large data sets. Geoscientists review and correct the output, and the models, the training data and the code are yours.
Checklist · Exploration data
Subsurface data management and OSDU readiness checklist
A checklist for exploration and subsurface data management projects: inventory, standards, quality, entitlements, data rooms, migration and the interfaces an OSDU data platform expects.- 01Eight areas to assess before you choose or build a subsurface data platform.
- 02The metadata and identifiers that make wells, surveys and licences findable.
- 03Entitlement and data room items that legal and partners ask about.
- 04Seven questions to put to any vendor or development partner.
Free download
Get it on screen in a few seconds.
What the system does, module by module.
- 01
Log data preparation
Standardisation of curve names and units, depth reference checks and merging of runs into continuous logs with the history of every change. - 02
Log quality control
Detection of spikes, flat lines, depth shifts, calibration problems and bad hole effects, with flags and suggested corrections for a petrophysicist to approve. - 03
Missing log prediction
Estimation of missing or damaged curves, such as sonic or density, from other logs and offset wells, labelled as predicted and with uncertainty. - 04
Facies and lithology classification
Supervised and semi-supervised classification of facies from logs and cores, with confidence and the training wells that support each result. - 05
Well correlation and tops picking
Suggested formation tops and correlations across wells, adjustable by the geologist, with consistent definitions across a field. - 06
Seismic enhancement
Noise attenuation and resolution enhancement models applied to seismic volumes, compared with conventional processing on test data. - 07
Fault and horizon detection
Segmentation models for faults, horizons and salt bodies, with probability volumes interpreters can threshold and edit. - 08
Uncertainty and QC
Confidence and disagreement measures for each prediction, and tests on blind wells and held-out areas before results are used. - 09
Interpretation integration
Results exchanged with interpretation applications and the subsurface data platform using open formats and standard interfaces.
Reference architecture.
Standards and interfaces
What we design against.
- OSDU Data Platform
- Schemas and services for well logs, seismic and interpretations, used for reading input and publishing results.
- LAS, DLIS and WITSML
- Well log and well data formats read and written by the pipeline.
- SEG-Y and open seismic formats
- Seismic data formats and chunked cloud formats for large volumes.
- RESQML
- Energistics standard for exchanging interpreted surfaces and models.
- Machine learning validation practice
- Spatial and well-based cross-validation, blind tests and uncertainty quantification suited to geoscience data.
- Data rights and licensing
- Terms on use of seismic and well data for training, which the pipeline tracks per dataset.
Data model
The core entities.
- Well and log
- Well, run, curve, unit, depth reference and the processing history.
- QC flag
- Curve, interval, issue, severity, suggestion and the reviewer's decision.
- Prediction
- Target, model, input data, value or class, confidence and the training set used.
- Seismic volume and attribute
- Survey, geometry, processing version, derived volumes and location in storage.
- Interpretation object
- Horizon, fault or body, source (manual or model), version and approval.
- Training dataset
- Wells or volumes included, labels, rights and the date frozen.
- Model version
- Architecture, training run, test results by blind well and area, and approval.
When custom development is the right call.
Controls designed in, not added later.
Geoscientist accountability
Predicted curves, picks and interpretations are marked as predictions and become interpretation only when a geoscientist approves them.Data rights tracking
Training on partner or licensed data follows the contracts, and lineage records which data trained which model.Model governance
Models are versioned, tested on blind wells and areas and monitored, with limits of use documented.Access control
Entitlements follow licence and partner, and results inherit the access of their inputs.Reproducibility
A prediction can be reproduced from the model version and the input data.
From discovery to a system you run.
- 01
Data and objective review
We review the data, existing interpretations and the geoscience decisions the AI should support, with geologists, petrophysicists and data managers. - 02
Data preparation and baselines
Logs and seismic are standardised, and baseline methods and metrics are set so models can be judged. - 03
Model development and blind testing
Models are trained on part of the data and tested on blind wells and areas, with results reviewed by geoscientists. - 04
Assisted interpretation
Geoscientists use the outputs as suggestions in a project, and their corrections are captured. - 05
Integrate and scale
Results flow to interpretation tools and the data platform, and the models extend to more of the data.
Relevant work
Where to see our work.
Common questions.
- Can AI replace the geoscientist's interpretation?
- No. It speeds up the routine parts, such as quality control, first-pass picks and consistent classification, and gives interpreters more time for judgement. Results are suggestions until a geoscientist approves them.
- How do you test whether a model is trustworthy?
- By training on some wells or areas and testing on others it has never seen, comparing with interpreters' work, and showing confidence with each result.
- Does it work for our basin?
- Models trained on generic data often need adaptation. We train and test on your own data, and show where a model should not be used.
- How do results get back into our interpretation tools?
- Through open formats and standard interfaces, such as OSDU and RESQML, and the interfaces the interpretation applications offer.
- Who owns the models and the training data?
- You do, subject to the licences on the underlying data. The models, the code and the labels stay yours.