Daily Drilling Reports for AI: Activity Codes, Time Logs and NPT Narratives

What a daily drilling report contains

A daily drilling report (DDR, also called a morning report) is a per-rig, per-day record that combines structured time accounting with narrative remarks. The classic contractor format is the IADC daily drilling report, while operators typically keep their own versions in a well-operations reporting system and export them as relational tables, spreadsheets or PDFs. Field names vary, so treat the list below as a buyer's checklist rather than a standard.

• Header: report date, report number, rig, well and wellbore identifiers, spud date, days from spud, start and end measured depth, true vertical depth.
• Time log: one row per interval with from/to times, duration in hours, phase (surface, intermediate, production hole, completion), operation and activity code, depth at start and end, and an activity description.
• NPT and lost time: productive/non-productive flag, NPT cause code (equipment failure, wellbore stability, waiting on weather, waiting on materials), responsible party and a short incident narrative.
• Mud and hydraulics: mud type, density, viscosity, filtrate and pit volumes, often at a reported depth and time.
• BHA and bit records: bit number, size, type, nozzles, run in and out depths, IADC dull grade, hours on bottom.
• Remarks and 24-hour summary: the free text that NLP and LLM work actually depends on, plus the plan for the next 24 hours.

Invisible lost time (ILT) rarely appears as a code. It has to be inferred by comparing activity durations against offset-well or technical-limit benchmarks, so buyers who want ILT labels need many comparable wells, not just more days.

Public DDR data and where it falls short

Open drilling report data exists, but it covers a handful of wells and mostly non-oil settings, which limits its use for production NPT models. Equinor's public Volve release is the best-known oil example, but it covers a single North Sea field, and drilling reports must be located inside a large file tree rather than in a labeled DDR table. Check its open data licence terms before any commercial use.

US geothermal research wells add a second public source. The McGinness Hills Well 27A-10 package on the Geothermal Data Repository is a single-well set under a Creative Commons licence and points users to a daily drilling record available from the contact [1]. Utah FORGE Well 16A(78)-32 publishes daily reports alongside 1-second and 10-second drilling CSVs and rig sensor data [2].

These sets are good for building parsers and schema prototypes. They are weak for training: one basin or one well, one operator's coding habits, and few NPT events per class.

WITSML, operator exports and the formats to request

Ask for structured exports first and PDFs second, because code fields extracted by OCR create label noise you cannot audit. WITSML, developed by Energistics, is the common XML standard for exchanging wellsite data objects such as wells, wellbores, logs and trajectories. Version 2.0 moved transport to the Energistics Transfer Protocol (ETP), although as of October 2026 many sites still run 1.4.1.x servers, so ask which version a supplier holds.

In practice, the operations report and time log often come from the operator's reporting database rather than a WITSML store, while depth and time logs come from WITSML or rig-contractor sensor feeds. Request each table separately with stable keys (well ID, wellbore ID, report date, interval sequence) so text can be joined to sensor data. For pairing remarks with high-frequency channels, see paired time-series and text data, and for raw rig sensor sources, the sensor and IoT data owner page.

Normalize every timestamp to ISO 8601 with an explicit offset, because rigs report in local time and reports often cut over at midnight or 06:00. The timestamps and time zones guide covers the failure modes.

NPT labeling: code mapping comes before any model

NPT classification fails most often because codes mean different things across operators, rigs and years, not because models are weak. One operator's "waiting on orders" may be another's "rig repair" sub-code, and the same supervisor can code a stuck-pipe event as "fishing" one day and "reaming" the next. Agree a target taxonomy, map each source code to it, and keep the original code in its own column.

Budget for a relabeled gold set. Label errors are common even in curated benchmarks, with an estimated average of at least 3.3% in widely used test sets [3], and hand-coded drilling remarks are likely to be noisier. Have two drilling engineers label a stratified sample of intervals, adjudicate disagreements, and measure agreement per class before trusting the source codes.

Split by well, not by day. Adjacent days from one well share depth, BHA and crew language, so random row splits leak; event-log research makes the same point and favors temporal, case-level splits [4]. Hold out whole wells, and ideally whole fields or rigs, for evaluation. The point-in-time correct training data guide explains as-of handling when reports are revised after the fact.

Rights, partners and de-identification

Well data often belongs to more than the company holding the files, so check ownership before pricing. Joint operating agreements can give non-operating partners rights in well data, drilling contractors may own their own report formats and sensor feeds, and service-company data inside remarks may carry confidentiality terms. Ask each supplier who owns the reports, which agreements restrict disclosure, and whether partner consent is needed.

Remove personnel names, phone numbers, contractor rates and commercial terms, and injury details before delivery. Injury narratives also overlap with safety records, covered on the HSE incident and near-miss reports page. Licensing gaps are common in public AI data generally; one audit found license omission above 70% on popular dataset hosts [5], so do not treat a public download as permission for commercial training without reading its terms.

Request template for a DDR dataset

Describe the records, codes and use, not the companies, and state what you will do with the remarks.

Illustrative example: invented to show structure; it does not describe an available dataset.

An illustrative time-log record might look like this:

{"well_id":"W-7731","report_date":"2024-03-14","seq":12,"from":"2024-03-14T13:30:00-05:00","to":"2024-03-14T17:00:00-05:00","hours":3.5,"phase":"INTERMEDIATE","activity_code":"TRIP_OUT","npt":true,"npt_cause":"DOWNHOLE_TOOL_FAILURE","md_start_ft":8412,"md_end_ft":8412,"remarks":"POOH to change MWD after loss of pulse signal. [NAME] on tour."}

How SourceX handles drilling report requests

SourceX sources operational datasets such as engineering records and documents from US companies on request; drilling reports are a category to request, not inventory, and a request does not guarantee a match. Every dataset is rights-reviewed for ownership and consents, personal details are removed or replaced with the method recorded and a sample checked, and every release is approved by the supplying company. Related owner pages cover enterprise document archives and workflow task histories; you can describe the drilling data you need to start.

For neighboring records, see well files, completion reports and workover histories, shift handover logs and the full industry-specific operational data hub.

Source daily drilling report data for your NPT model

SourceX looks for US businesses that hold the drilling reports you describe and runs the process from finding and assessing data through a license that defines records, uses, term and delivery. Nothing is contracted until a supplier agrees, and delivery runs through private, access-controlled workflows after an executed agreement. Describe your daily drilling report requirements.