`gold_well_completions`

One row per completion event (the initial completion and each later recompletion) as filed with the regulator. Carries the completion date, the wellbore configuration produced by the event (formation, depths, lateral length, trajectory), and interval details. Plug-and-abandon events are not completions; they live on the well register (plugged_date).

Access tier: portal Portal. These rows are well-level or producing-unit-level data, or our modelled output at cohort or grid grain. They open with a Portal, Pro or Enterprise plan. The website shows aggregates built from them, never the rows.
Primary key: completion_id
Region codes: ak, ar, argentina, bc, co, la, mt, nd, nm, oh, ok, pa, tx, ut, wv, wy

Columns

Column	Type	Nullable	Description
`completion_id`	string	no	Globally unique completion identifier (opaque string) - this table's primary key. Never parse substrings out of it.
`well_id`	string	no	Join key to the well register. Always populated.
`completion_date`	date	yes	Date this completion was finalized per the regulatory filing. Every row is a completion - plug-and-abandon events are not in this table. Where a source dates completions at well grain rather than per event (Wyoming; most Ohio rows), every completion row of a well carries the well's date - real well-level information, but it does not order that well's completions.
`event_type`	string	yes	The kind of completion event: initial_completion (the well's first completion on record) or recompletion (a later completion of the same well). Classified from the source's own event typing or sequence numbering where published, else from completion-date order. NULL where the records carry no order evidence for the event (an undated completion among others), so first-vs-later is unknown. A well can carry more than one initial_completion where the source records the first completion as several records - dual completions, or the perforation intervals of one job. A well whose record set contains exactly one completion is labeled initial_completion on that single-record basis alone. Where a source publishes no per-completion dates or event typing (Wyoming today), that is the only basis in use: every labeled row there is a single-record well, and multi-record wells are NULL. Values: `initial_completion` · `recompletion`.
`operator`	string	yes	The operator responsible for this completion, as a canonical company name. Where the source's completion record names an operator, this is the operator at the time of the completion - a point-in-time fact. Where it does not (many regulators publish completion records without an operator), we carry the well's current operator of record instead. This table carries the name only; for a stable company identifier, join the well register via well_id, or resolve the raw operator_entity through the organization name mappings. (This styled display is an output - it is not guaranteed to normalize back to a mapping key.)
`operator_entity`	string	yes	Raw filing entity name from the source - a historical fact, preserved without normalization.
`trajectory`	string	yes	Wellbore trajectory produced by this completion: horizontal, vertical, or directional. NULL = not available. Values: `horizontal` · `vertical` · `directional`.
`formation`	string	yes	Best-available target/producing formation. formation_method, where populated, records how the value was determined (reported = from the operator's filing). The value is normalized to the same canonical vocabulary as the well register where the region's formation mapping covers it; elsewhere it is carried as the source publishes it.
`zone`	string	yes	Landing zone within the formation - a named bench or sand, e.g. Middle Bakken. Derived from the operator's reported formation, pool, or sand naming in the source data; for North Dakota, extracted from the narrative text of the well file. Same zone vocabulary as the well register.
`formation_reported`	string	yes	Raw reported formation from the completion filing (uppercased, trimmed) - the original filing text before normalization, always preserved. Where the well filed a formation or pool code rather than a name, this is the source's own register label for that code, verbatim. Populated even when formation is NULL.
`formation_method`	string	yes	How the formation value was determined: reported = derived from source-reported formation or pool information (normalization, decoding, or selection between reported values may apply); survey = directional-survey-based placement; modeled = filled from the formation surface model; stratigraphic_pick = assigned from the deepest published stratigraphic pick on this wellbore - a third-party geological-survey pick rather than an operator declaration, and an estimate of the deepest formation penetrated rather than a declared target or producing formation. Values: `reported` · `survey` · `modeled` · `stratigraphic_pick`.
`tvd`	int32	yes	True vertical depth to the producing zone, in feet.
`md`	int32	yes	Total measured depth, surface to total depth, in feet.
`lateral_length`	int32	yes	Lateral length in feet for this completion. Usually the completed or perforated interval, but not always: where the completion record carries no interval the value is the drilled lateral measured along a directional survey or along the mapped wellbore path, or a geometric estimate of it (straight-line heel-to-toe or surface-to-bottom-hole distance, or measured depth minus vertical depth). lateral_length_source says which. NULL for vertical wells.
`lateral_length_source`	string	yes	How lateral_length was determined: perf_interval = the perforated interval (preferred); treatment = the stimulated interval; survey = the directional survey's along-hole length; wellpath_polyline = the length of the mapped wellbore path; heel_toe_geodesic = the straight-line distance between the lateral's heel and toe; surface_bhl_geodesic = the straight-line distance from surface to bottom hole, less a region-calibrated build-section correction where one exists (uncorrected it includes the build-section step-out); operator_reported = a single reported length; md_minus_tvd = measured depth minus vertical depth - a crude estimate and the lowest-confidence tier. Values: `perf_interval` · `treatment` · `survey` · `wellpath_polyline` · `heel_toe_geodesic` · `surface_bhl_geodesic` · `operator_reported` · `md_minus_tvd`.
`perf_top`	int32	yes	Top of the perforated interval, in feet measured depth.
`perf_bottom`	int32	yes	Bottom of the perforated interval, in feet measured depth.
`hydraulic_fracking_used`	boolean	yes	Whether any hydraulic fracturing was used, including conventional small frac jobs. Three-valued: TRUE = a frac is recorded (the frac records carry the treatment detail); FALSE = confirmed not fracked - asserted only where the regulator's own filing says so: the operator answered no to the completion report's hydraulic-fracturing question (e.g. TX), or a mandatory frac/stimulation register records no treatment (e.g. WY, OH); NULL = unknown (voluntary or incomplete reporting, e.g. FracFocus-only regions). NULL is never "not fracked".

Region-specific columns

Extra columns a single region's source adds.

ar (6 columns)

Column	Type	Description
`ar_well_key`	string
`wellbore_type`	string
`wellbore_status`	string
`completion_type`	string
`field`	string
`permit_number`	string

bc (2 columns)

Column	Type	Description
`wa_number`	string
`completion_event_seq`	string

co (2 columns)

Column	Type	Description
`formation_code`	string
`sidetrack`	string

la (1 column)

Column	Type	Description
`la_well_serial`	string

nd (2 columns)

Column	Type	Description
`file_no`	int64
`source`	string

nm (4 columns)

Column	Type	Description
`pool_idn`	int64
`pool_name`	string
`bhl_latitude`	float64
`bhl_longitude`	float64

ok (3 columns)

Column	Type	Description
`bhl_latitude`	float64
`bhl_longitude`	float64
`completion_no`	int32

pa (1 column)

Column	Type	Description
`unconventional`	boolean

tx (12 columns)

Column	Type	Description
`district`	string
`county`	string
`field_name`	string
`well_type`	string
`operator_no`	string
`plug_back_depth_tvd`	int32
`plug_back_depth_md`	int32
`is_multiple_completion`	boolean
`commingled`	boolean
`latest_completion_date`	date
`n_reports`	int32
`n_intervals`	int32

How these numbers are built is on methodology; the machine twin of this page is data-dictionary.json.