BSEE Offshore APD Permit Record Lineage Study 2026: Research question
How should a land team connect a federal offshore application for permit to drill to the correct well, lease, company, locations, approval event, and later activity?
Production and Drilling Data
A decision-grade, source-backed study of BSEE offshore application-for-permit-to-drill record lineage, with reproducible controls, limitations, and land-work applications.
10 official source routes
5 evidence layers
Checked October 2, 2026
How should a land team connect a federal offshore application for permit to drill to the correct well, lease, company, locations, approval event, and later activity?
The permit query is an event register, not a complete well file. Reliable linkage starts with the 12-digit API well number, then tests the surface and bottom area-block-lease fields, company number, permit type, receipt date, and approval date against the well and eWell datasets.
This study begins with BSEE's APD, AST and ABP query, because that interface identifies the permit event and exposes the fields that matter to an offshore drilling review. We treat the query result as one published observation, record the retrieval time, and retain its complete API number without converting it to a number. The API List query provides a separate well-identity check. BSEE's raw-data directory supplies downloadable eWell families whose file names and publication dates can be preserved for later comparison. These sources overlap, but they do not serve the same evidentiary role.
The comparison table keeps permit type, received date, approved date, company number, well name and suffix, rig, water depth, and each surface and bottom area-block-lease value in its own column. A match is proposed only after the complete API number and the relevant location roles agree. When a public result changes between retrievals, the earlier value is not erased. Both observations remain in the ledger with their access times, and the difference becomes a research question for an application, modification, or agency record.
An offshore API number is the strongest join key in this public set, but a bare number cannot explain which event a row represents. One well may have an original application, a sidetrack or bypass, and later operational submissions. Suffixes and permit types therefore remain attached to the identifier. Area and block values also require role labels. A surface location and a bottom-hole location may legitimately differ, so a database design that stores a single unlabeled block can manufacture a conflict or conceal a directional path.
Lease and company fields provide additional tests rather than replacements for the API number. The company number should be retained beside the displayed company name, since names can change in presentation while an agency identifier remains stable. The lease number helps distinguish similarly named wells or nearby locations, but it should be checked against the exact query row rather than supplied from a current map. BOEM's mapping and data resources can add lease context, while BSEE remains the source for the permit observation examined here.
For each APD result, save the query parameters or search terms, the result row, the direct source URL, and the UTC retrieval time. Export or transcribe values without stripping leading zeroes. Then open the API List result for the same complete identifier and compare well name, suffix, company, area, block, and lease. Finally, identify the corresponding raw-data family and preserve its download name, file date, row key, and checksum. A reviewer should be able to repeat those three steps without relying on a screenshot whose search context is missing.
The procedure deliberately stops short of declaring that an approved permit caused drilling. If later activity matters, it must be supported by a separately identified BSEE report or dataset. The permit row can establish that the public system displays a received or approved event with particular attributes. It cannot establish a spud date, physical location survey, completion, or current condition merely because those events might normally follow approval.
BSEE’s APD, AST and ABP query exposes permit-specific fields: permit type, received and approved dates, company number, surface and bottom area-block-lease coordinates, well name, rig, and water depth. Those fields answer a narrower question than a general well search. They document how a permit submission was indexed at the time represented by the row. They do not by themselves establish that drilling began, that every condition was satisfied, or that a later sidetrack retained identical coordinates. A useful packet therefore preserves the query row as a permit observation instead of copying its values into an undated “well master” record.
For an offshore APD, an API match is necessary but not always sufficient. The reviewer should compare surface area and block, bottom area and block, lease number, well name and suffix, and company number. A directional well can begin and end in different blocks; collapsing the two coordinate sets destroys an important part of the permit’s scope. If the lease or bottom location differs between a downloadable submission row and the well query, the variance should remain visible until a permit revision, approved modification, or agency document explains it.
Build the chronology from named events. “Received” describes agency intake. “Approved” describes the decision recorded by the permit system. A drilling activity report, spud observation, well activity report, or completion record is a later artifact. The absence of one from a public interface does not allow the researcher to infer cancellation or inactivity. The defensible sequence lists the observed dates, identifies the source of each date, and leaves a bounded gap where the public record does not supply the intervening event.
The raw-data directory is valuable because it identifies downloadable eWell submission families and their update cadence. Preserve the download name, retrieval time, file date, row key, and hash. When a refreshed file changes a field, add a new observation rather than overwriting the earlier row. That difference may reflect correction, processing, or a changed extraction, but the dataset alone does not explain which. The analysis should state only that two published versions differ and identify the document needed to resolve why.
A review-ready APD packet separates identity, geography, company, event, and later activity. Identity requires the unaltered API number. Geography retains both surface and bottom coordinates and their lease references. Company evidence retains the agency company number beside the displayed name. Event evidence keeps received and approved dates with the permit type. Later activity is sourced independently. A packet fails internal review when it silently substitutes a current company name, drops the bottom-hole location, or treats the approval date as a spud date.
Suppose the permit query lists one bottom block while a later borehole download lists an adjacent block. First confirm that both rows use the same complete API number and well suffix. Then compare update dates, coordinate labels, permit type, and any modification submission. Do not “fix” either block from map proximity. The handoff question is whether an approved modification or directional-survey record accounts for the changed bottom location. Until that artifact is found, the packet carries both values and marks the location relationship unresolved.
That conflict should also be scoped before anyone requests more records. If the surface location, lease, company number, and original approval fields agree, the open issue may concern only the bottom-hole location. The request can then name the API number, suffix, two observed block values, retrieval dates, and suspected modification period. A narrow request is easier to answer and avoids implying that the entire permit identity is uncertain when most of the published evidence is consistent.
A second researcher should reproduce the APD query, reopen the well record, and locate the same raw submission row. They should verify leading zeroes, area and block codes, lease number, company number, permit type, both event dates, and the distinction between surface and bottom locations. They should also confirm that each screenshot or export has an access time and that no narrative sentence upgrades a query observation into proof of physical operations.
This review examined public BSEE entry points, not authenticated eWell functions, internal engineering review, proprietary attachments, inspection files, or a complete administrative record for a specific well. Public datasets can update after access and may expose different slices of the same submission. The method supports document control for land and regulatory review; it does not determine compliance, operating rights, lease validity, well condition, or the legal effect of an approval.
BSEE's public permit data is most useful when each row remains tied to the event and dataset that produced it. The complete API number anchors the comparison, but the surface and bottom locations, lease, company, permit type, and named dates supply the context needed to test the link. A review-ready packet shows those fields without collapsing their roles, cites later activity separately, and carries unresolved changes forward as explicit questions. This approach respects what the public systems disclose while avoiding a false reconstruction of the well's administrative or physical history.
A decision-grade, source-backed study of Utah application-for-permit-to-drill review lineage, with reproducible controls, limitations, and land-work applications.
Verified 2026-10-05
A decision-grade, source-backed study of Utah Form 8 well completion and log lineage, with reproducible controls, limitations, and land-work applications.
Verified 2026-10-05
A decision-grade, source-backed study of Wyoming oil-and-gas sundry notice record lineage, with reproducible controls, limitations, and land-work applications.
Verified 2026-10-04