Oil And Gas Data Manager

Oil and Gas Data Manager

What this skill does

Identifies oil and gas file types automatically, extracts structured engineering data from them, links extracted content to the current project context using well and asset identifiers, and returns normalized outputs ready for downstream workflows including RAG pipelines, QA generation, engineering summaries, and project dashboards.

When to use

Use this skill whenever:

• The user uploads or references oil and gas reports, well logs, spreadsheets, or sensor data files
• The task involves classifying, parsing, or extracting data from drilling, completions, petrophysics, production, or directional engineering documents
• The user asks to summarize, query, or structure data from multiple engineering file types at once
• A project context exists and the user wants incoming files linked to wells or activities

Trigger phrases

• "Analyze these drilling and LAS files for my current well"
• "Identify the oil and gas file types in this folder and extract engineering data"
• "Pull all completion design parameters from the uploaded reports"
• "Find well identifiers and drilling KPIs for the active project"
• "Summarize NPT, mud properties, and casing points from the latest DDRs"
• "What file types are these and what data can you extract?"
• "Parse this morning report and link it to the active well"
• "Extract the frac stage data from these completion sheets"

Inputs

• One or more uploaded files (PDF, DOCX, XLSX, CSV, LAS, DLIS, JSON, TXT)
• Optional project metadata: well name, API/UWI, pad, field, operator, date range
• Optional extraction focus: drilling only, completions only, logs only, etc.

Outputs

• File classification: type, MIME, discipline, document purpose
• Structured engineering JSON with all extracted parameters
• Project match score with matched identifiers listed
• Human-readable summary of extracted content
• Quality flags: missing data, unit ambiguities, sanity check failures, OCR limitations
• Per-field confidence scores and source references (page, section, depth range)

Supported file types

Common documents

• PDF well programs, drilling reports, completion reports, mud logs, cementing reports, directional surveys
• DOCX procedures and operating manuals
• TXT daily drilling notes
• CSV exports from vendor systems
• XLSX drilling parameters and production sheets

Oil and gas specific technical files

• LAS 2.0 and 3.0 well log files
• DLIS log containers
• LIS legacy log files
• WITSML XML exports
• WITS real-time stream data
• Trajectory survey CSV or TXT
• Mud logging data files
• Completion design spreadsheets
• Production allocation spreadsheets
• PVT lab result tables

Images and semi-structured sources

• Well schematics embedded in PDFs
• Daily drilling report scans (OCR-limited extraction flagged)
• Cement bond log images in PDFs
• Toolface and trajectory chart images

Detection logic

Step 1: File signature and extension detection

• Inspect file extension
• Inspect MIME type
• Check for known binary signatures (magic bytes)
• Detect structured headers for LAS (~Version, ~Well, ~Curve, ~ASCII), DLIS (STORAGE-UNIT-LABEL), WITSML root elements

Step 2: Content-based classification

Use weighted keyword and pattern matching to infer:

• Discipline: drilling, completions, production, reservoir, geology, geosteering, petrophysics, HSE
• Document type: DDR, morning report, well plan, BHA sheet, casing design, mud report, cement job report, directional survey, completion program, frac stage sheet, production test, log file
• Asset identifiers: field, basin, operator, pad, well name, API/UWI, rig name, report date, service company

Step 3: Project association

Match extracted identifiers against the active project context using:

• Well name exact match and common aliases (e.g., 1H vs #1H vs Well-1H)
• API/UWI number
• Pad or lease name
• Basin and field name
• Operator and service company names
• Date overlap with current project schedule

Extraction targets

Drilling

• Well name, API/UWI, rig name, spud date
• Current depth, measured depth, true vertical depth
• Rate of penetration (instantaneous and average)
• Weight on bit, rotary speed (RPM), torque
• Standpipe pressure, pump rate, flow rate
• Mud weight (in and out), mud type, viscosity, PV, YP
• Losses and gains with depth and volume
• Casing set depths and shoe track details
• BHA component list with dimensions
• NPT events with duration, cause, and classification
• Safety incidents and near misses

Directional and survey

• Survey station: MD, inclination, azimuth
• TVD, northing, easting
• Dogleg severity (per 30m or 100ft)
• Target line entry and exit points
• Anticollision notes and separation factors
• Toolface and slide sheets when present

Completions

• Stage count, cluster count per stage
• Perforation intervals (MD top and bottom)
• Casing and tubing OD, weight, grade
• Frac fluid type and total volume per stage
• Proppant type, mesh size, total mass, max concentration
• Treating pressure (ISIP, breakdown, max treating)
• Rate schedule (slurry and clean)
• Plug type, plug depth, perf gun specs
• Packer and liner hanger details

Logs and petrophysics

• Depth track (MD and TVD)
• Gamma ray (API units)
• Resistivity (deep, medium, shallow)
• Bulk density
• Neutron porosity
• Compressional sonic (DT)
• Caliper
• Interpreted formation tops and bases
• Pay intervals with net pay summary
• Lithology flags

Production

• Oil rate (STB/d or m3/d)
• Gas rate (MSCF/d or m3/d)
• Water rate (STB/d or m3/d)
• GOR and water cut
• Choke size (fraction or mm)
• Tubing head pressure, casing head pressure
• Test date and test duration
• Allocation method and intervals
• Separator conditions

Output schema

{
  "project_match": {
    "project_name": "string",
    "match_confidence": 0.0,
    "matched_identifiers": ["string"]
  },
  "file_info": {
    "filename": "string",
    "file_type": "string",
    "mime_type": "string",
    "discipline": "string",
    "document_type": "string"
  },
  "entity_context": {
    "operator": "string",
    "field": "string",
    "basin": "string",
    "pad": "string",
    "well_name": "string",
    "api": "string",
    "report_date": "string"
  },
  "extracted_data": {
    "drilling": {},
    "directional": {},
    "completions": {},
    "logs": {},
    "production": {}
  },
  "tables": [
    {
      "name": "string",
      "columns": ["string"],
      "rows": []
    }
  ],
  "references": [
    {
      "source_section": "string",
      "page_or_depth_range": "string",
      "confidence": 0.0
    }
  ],
  "quality_flags": ["string"]
}

Core behaviors

1. Detect before parsing — Always classify the file type before attempting extraction. Never assume format from extension alone.

2. Route intelligently — Use the routing rules below to send each file to the correct parser. Do not apply a generic text extractor to structured binary formats.

3. Prefer deterministic extraction — Use parser libraries and regex patterns first. Use LLM-assisted inference only when structured parsing fails or yields low confidence.

4. Normalize consistently — Convert all units to a canonical system (metric or field units based on project preference). Store original values alongside normalized values.

5. Map aliases to canonical terms — Treat "WOB", "weight on bit", and "bit weight" as the same field. Maintain an alias dictionary for common oilfield abbreviations.

6. Track source for everything — Every extracted value must have a reference: page number, section heading, or depth range.

7. Flag rather than fabricate — When a value is ambiguous, missing, or requires OCR, mark it with a quality flag. Never invent or interpolate missing values without stating so.

8. Score confidence at field level — Provide a 0.0–1.0 confidence score for each extracted field based on extraction method (structured header vs. regex vs. LLM inference).

Routing rules

Extraction heuristics

• Prefer explicit headers and labeled cells over inferred positions
• When a number is ambiguous, attach the local label and the full surrounding sentence
• Reject impossible values using engineering sanity checks (listed below)
• When units are missing from a number, look in column headers, section headers, or nearby text within 200 characters
• For LAS files, treat UNITS column in ~Curve section as authoritative

Engineering sanity checks

Failure handling

• Unknown file type: Return best-effort classification with reasoning and confidence
• OCR required for scanned PDF: Mark extraction as limited, return what text is recoverable, do not fabricate values
• Multiple project matches: Return all candidates ranked by confidence, ask user to confirm
• Partial table parse: Return raw rows with parsing warnings, do not silently drop data
• Binary format without parser: Note format is unsupported, list what metadata was recovered from headers
• Contradictory values within one document: Return both values with source references, flag as conflict

Example responses

Classification

Detected 3 oil and gas file types:

• daily_report_2024-03-15.pdf → Drilling Daily Report, discipline: drilling
• A12H_survey_final.las → LAS Well Log, discipline: petrophysics/directional
• Stage_Design_A12H.xlsx → Completion Design Spreadsheet, discipline: completions

Project match

Matched all 3 files to project "Eagle Ford Pad A — Well 12H" with 0.93 average confidence. Matched identifiers: well name alias "A12H", API 42-123-45678-0000, report date within project window.

Extraction summary

Drilling report: Extracted 14 KPIs including ROP 87 ft/hr, WOB 18 klbs, mud weight 9.8 ppg, 2 NPT events (total 4.5 hrs, bit trip + BHA failure).

LAS file: 8 curves parsed (GR, RT, RHOB, NPHI, DT, CAL, MD, TVD). 3 pay intervals identified between 7,840–8,120 ft MD.

Completion spreadsheet: 32 stages, 4 clusters/stage, avg fluid volume 2,200 bbls/stage, 100-mesh sand 1,200 lbs/ft, ISIP avg 7,450 psi.

Implementation notes

• Use lasio for all LAS file parsing
• Use dlisio for DLIS and LIS containers
• Use pdfplumber for text and table extraction from PDFs
• Use openpyxl or pandas for Excel files
• Use pydantic v2 for schema validation after extraction
• Use pint for unit conversion and normalization
• Store both raw extracted values and normalized values in output
• Keep project matching logic independent from extraction for easier debugging and testing