North Dakota Change of Operator Record Lineage Study 2026: Research question and study design
A change-of-operator file combines two puzzles: who purported to transfer responsibility, and which wells were included? This study adopts a population-reconciliation design. It tests the party evidence and the affected-well schedule separately before examining disposition and later public displays.
That design rejects the tempting shortcut of treating a current operator field as the history of a transfer. The field says what an interface displayed when viewed. It does not by itself identify the transferor, show signatory authority, establish financial assurance, reproduce the submitted population, or state the agency’s action date.
Define the transfer population
Begin with the well schedule attached to or referenced by the transfer material. Give every listed item a row and retain its native identifier, name, field, and any schedule notation. Then compare that declared population with the intake population. Classify outcomes as included, omitted, or unresolved; do not force unmatched wells into the transaction because their names look related.
Population control catches split transfers, duplicate lines, missing pages, and assumptions that an operator conveyed everything it operated. Totals are useful checksums, but a matching count does not prove that the same wells are present. Reconciliation occurs at the identifier level.
Test each party in its own compartment
Record transferor and transferee exactly as written, including organization identifiers when displayed. Preserve signature blocks, capacities, signature dates, and any authority attachments as distinct evidence. A recognizable company name does not establish that the signer had authority, that similarly named entities are identical, or that a corporate change occurred.
Maintain an alias table only as an analytical aid. Each proposed alias should cite the artifact supporting it and carry a review state. Never replace the literal names in source observations with a preferred internal name.
Separate security from disposition
Bond or financial-assurance references deserve their own compartment because their presence, acceptance, and sufficiency are not the same proposition. Transcribe the reference and the language surrounding it. Route any determination about adequacy to the appropriate regulatory or legal reviewer.
Likewise, submission, receipt, deficiency notice, approval, rejection, stated effective date, and public-display change are separate events. Build the chronology from labeled dates. A generic “transfer date” column conceals whether the value came from a signature, filing stamp, agency action, or internal assumption.
Reconcile against later displays
After the documentary population is stable, query the public well interface using native identifiers. Capture operator wording, well status, access time, and locator for each result. Classify the comparison as consistent, inconsistent, or not observed. A consistent display is corroboration; an inconsistent display is a research exception; no result is a bounded negative.
Do not copy the current party backward into historic rows. Nor should a current mismatch be labeled agency error. Lag, subsequent transactions, identifier problems, or incomplete public coverage may be possible, but the evidence must identify the cause before the report does.
Illustrative three-well transfer
Imagine a filing schedule lists wells A and B, while the client roster lists A, B, and C. The current map names the transferee for A, the transferor for B, and returns no result for C. The proper output is not “two of three transferred.” It is a reconciliation table: A is scheduled and currently consistent; B is scheduled but currently inconsistent; C is absent from the captured schedule and not observed in the documented query.
The next actions differ. B calls for chronology and subsequent-record research. C calls for verification of the source schedule and identifier. Keeping those paths separate prevents an ambiguous total from driving a land decision.
Research packet assembly
Arrange the handoff in the order a reviewer will use it: declared population first, unmatched roster items second, literal party evidence third, security references fourth, and dated agency events fifth. Place current-interface results in a final annex so their recency is obvious. Each exception should name one question, one owner, and the next source likely to resolve it.
This organization also supports sampling. A checker can select all omitted wells, all party-name variances, and a risk-based sample of consistent rows. The review record should show whether the checker reopened the source, inspected a saved copy, or reproduced the query. Those are different assurance levels.
Limits and operational conclusion
This study reviewed public official routes on October 6, 2026. It did not authenticate signatures, inspect confidential bond records, contact parties, or decide regulatory responsibility. Public interfaces may lag or omit historical steps. Affected schedules may contain continuations or attachments that must be preserved as a complete set.
The reliable deliverable is a compartmented packet: transaction population, party proof, authority material, security reference, agency chronology, and later observations. Only after those compartments are complete should a qualified professional determine operating authority or the legal effect of the change.
Field protocol
The transferor legal name test asks three things: where the value appeared, which transaction stage it describes, and whether another record corroborates it. An unresolved mismatch stays visible and receives an owner; resemblance alone does not authorize a merge. Include the query conditions and access timestamp because later interface results may reflect another transaction or a newer agency observation.
The transferee legal name test asks three things: where the value appeared, which transaction stage it describes, and whether another record corroborates it. An unresolved mismatch stays visible and receives an owner; resemblance alone does not authorize a merge. Include the query conditions and access timestamp because later interface results may reflect another transaction or a newer agency observation.
The organization identifier test asks three things: where the value appeared, which transaction stage it describes, and whether another record corroborates it. An unresolved mismatch stays visible and receives an owner; resemblance alone does not authorize a merge. Include the query conditions and access timestamp because later interface results may reflect another transaction or a newer agency observation.
The signatory capacity test asks three things: where the value appeared, which transaction stage it describes, and whether another record corroborates it. An unresolved mismatch stays visible and receives an owner; resemblance alone does not authorize a merge. Include the query conditions and access timestamp because later interface results may reflect another transaction or a newer agency observation.
The signature date test asks three things: where the value appeared, which transaction stage it describes, and whether another record corroborates it. An unresolved mismatch stays visible and receives an owner; resemblance alone does not authorize a merge. Include the query conditions and access timestamp because later interface results may reflect another transaction or a newer agency observation.
The affected-well API test asks three things: where the value appeared, which transaction stage it describes, and whether another record corroborates it. An unresolved mismatch stays visible and receives an owner; resemblance alone does not authorize a merge. Include the query conditions and access timestamp because later interface results may reflect another transaction or a newer agency observation.
The schedule page test asks three things: where the value appeared, which transaction stage it describes, and whether another record corroborates it. An unresolved mismatch stays visible and receives an owner; resemblance alone does not authorize a merge. Include the query conditions and access timestamp because later interface results may reflect another transaction or a newer agency observation.
The security reference test asks three things: where the value appeared, which transaction stage it describes, and whether another record corroborates it. An unresolved mismatch stays visible and receives an owner; resemblance alone does not authorize a merge. Include the query conditions and access timestamp because later interface results may reflect another transaction or a newer agency observation.
The submission date test asks three things: where the value appeared, which transaction stage it describes, and whether another record corroborates it. An unresolved mismatch stays visible and receives an owner; resemblance alone does not authorize a merge. Include the query conditions and access timestamp because later interface results may reflect another transaction or a newer agency observation.
The agency disposition test asks three things: where the value appeared, which transaction stage it describes, and whether another record corroborates it. An unresolved mismatch stays visible and receives an owner; resemblance alone does not authorize a merge. Include the query conditions and access timestamp because later interface results may reflect another transaction or a newer agency observation.
The stated effective date test asks three things: where the value appeared, which transaction stage it describes, and whether another record corroborates it. An unresolved mismatch stays visible and receives an owner; resemblance alone does not authorize a merge. Include the query conditions and access timestamp because later interface results may reflect another transaction or a newer agency observation.
The current operator observation test asks three things: where the value appeared, which transaction stage it describes, and whether another record corroborates it. An unresolved mismatch stays visible and receives an owner; resemblance alone does not authorize a merge. Include the query conditions and access timestamp because later interface results may reflect another transaction or a newer agency observation.
Sources
Frequently asked questions
Does the current operator field prove approval?
No. It documents a later display and should be paired with the transaction and disposition evidence.
Should totals drive reconciliation?
No. Counts are checksums; well-level identifiers establish which items actually match.
What happens to an omitted well?
Place it in an exception queue and verify the complete schedule before drawing a scope conclusion.
If your team needs a review-ready north dakota change of operator record lineage study packet, Book a free consultation.
