Texas RRC Field Classification Codes: G, O, B, and Associated Field Numbers

Direct answer for mineral owners

Read field_class_code in og_field as the field-level G, O, or B class. Use oil_or_gas_code in og_field_info for each type-specific row: one row for oil-only or gas-only, two for both. Resolve an associated field number only through the exact source field. Preserve raw code, labels, keys, source date, pointer status, and exceptions. These codes do not prove a well, lease, tract, owner, production record, or value.

Key takeaways for mineral owners

• field_class_code is a field-level classification; oil_or_gas_code identifies a type-specific information row.
• The reviewed manual says og_field_info has one row for an oil-only or gas-only field and two rows, one oil and one gas, when a field is both.
• An associated-field value is a source-scoped pointer for related oil and gas fields that use different field numbers, not a universal database join.
• Preserve the current manual label inconsistency: associated_field_id in the table definition and associate_field_id in the narrative.
• A field code or pointer does not establish a well, lease, tract, ownership, production, reserve, valuation, offer, or transaction relationship.

Field-table interpretation, not property proof. This page explains selected Texas Railroad Commission field-data labels and row relationships. It does not identify a field boundary, county, district, well, lease, tract, unit, API number, owner, title interest, production result, reserve, private value, offer, buyer action, or transaction outcome. MRX provides educational information and resources only and does not buy mineral rights.

The direct answer is: read field_class_code in og_field as the field-level G, O, or B classification, and read oil_or_gas_code in og_field_info as the role of each type-specific row. Expect one og_field_info row when the field is oil-only or gas-only. Expect two rows, one oil and one gas, when the field is classified as both.

Resolve an associated field number only through the exact source field that defines the pointer. Preserve the raw code, table name, field label, field_id, field number, row role, source object, version or access date, pointer status, and exception. A class code or pointer is not evidence that a well, lease, tract, owner, production record, or value belongs to the field.

The field classification and row model

The RRC Oil and Gas Field Information data dictionary describes two different levels of data. The og_field table holds general field information, including field_number, field_name, field_id, and field_class_code. The og_field_info table holds information specific to a field type and includes oil_or_gas_code, field_info_id, and field_id.

That difference is the organizing rule:

Source location	Code or key	Source-scoped meaning	Safe handling
og_field.field_class_code	g	Gas field	Retain as field-level class; expect one gas-type information row
og_field.field_class_code	o	Oil field	Retain as field-level class; expect one oil-type information row
og_field.field_class_code	b	Associated field, both oil and gas	Expect separate oil and gas type-specific rows; do not collapse them
og_field_info.oil_or_gas_code	g or o	Role of one type-specific information row	Keep the role beside the row and its field_id
og_field.associated_field_id table label	Numeric column	Related-field pointer context documented for differing oil and gas field numbers	Preserve the exact label and resolve only under the reviewed source contract

The manual explains that og_field_info has one row when a field is either oil or gas and two rows when the field is both, one oil row and one gas row. That is a cardinality rule, not a suggestion to duplicate or merge records. If a field marked both has only one type-specific row in an extract, treat the record set as incomplete or out of scope until the exact export and filter are checked.

G, O, and B are field-data codes

The dictionary describes g as gas, o as oil, and b as associated or both oil and gas. It also says initial classification depends on the first well’s gas-to-oil ratio, while administrative hearings and later discoveries can affect the field relationship. That history is why a code should be carried with its source and date instead of treated as a permanent natural-law label.

For display, this article capitalizes G, O, and B. In a data pipeline, preserve the raw character exactly as delivered. If a source supplies lowercase g, retain lowercase in the raw field. A separate normalized field may use uppercase only if the transformation rule, source, and validation result are recorded.

Do not translate B into a private conclusion such as “both products are produced from this owner’s tract.” The code describes the RRC field-data relationship in the reviewed source. It does not establish a geographic or ownership connection to a private asset.

One field can require two type-specific rows

The safest mental model is one parent field record with one or two child information rows:

1. Read the parent og_field row and preserve field_id, field number, field name, and raw class code.
2. Locate og_field_info rows that use that exact field_id within the same controlled source.
3. If class is G, require a gas-role information row.
4. If class is O, require an oil-role information row.
5. If class is B, require both an oil-role row and a gas-role row.
6. Keep each row’s oil_or_gas_code and type-specific facts separate.

Do not select the first row returned by a query and discard the second. Do not average, concatenate, or overwrite type-specific values merely because the parent field_id matches. The parent key relates the records; the type code tells you why more than one child row can exist.

The current RRC Field Data page links the Oil and Gas Field Information Query separately from the Proration Schedule by Field. The RRC research-query catalog separately lists the Field Rules Query. A field-data table relationship does not prove that a particular query, schedule, or downstream extract returned the same rows.

Resolve an associated field number as a pointer

The reviewed manual’s narrative says that, for gas fields, the associated-field data item stores an eight-digit oil field number when a gas field is associated with an oil field and the two use different field numbers. The same manual explains that related oil and gas fields usually share a field number; the pointer matters when they do not.

That makes pointer resolution a controlled lookup, not a fuzzy match:

1. Identify the exact source table and field label that supplied the value.
2. Preserve the originating gas field’s field_id and field number.
3. Preserve the raw associated-field value as text so all eight positions remain visible.
4. Label the target as a related oil field number only because the reviewed dictionary says so.
5. Search the same controlled field-number domain for an exact target.
6. Record resolved_exact, unresolved, ambiguous, blank, or out_of_scope.
7. Keep the source and target records separate even when the pointer resolves.

A resolved pointer does not authorize a join to a wellbore API number, oil lease number, gas well ID, deed, tax account, royalty statement, or owner record. The RRC explanation of oil and gas queries says each query is one slice of the larger system and distinguishes wellbore, completion, API, lease or well ID, field, district, and operator contexts. Each identifier lane needs its own evidence.

Preserve the manual’s label inconsistency

The table definition on the reviewed manual endpoint uses associated_field_id. The narrative data dictionary uses associate_field_id. The difference is one letter, but silent normalization would erase useful provenance.

Use two fields in the audit record:

Audit field	Example role
source_field_label	Exact spelling copied from the table definition or narrative
canonical_mapping_label	Internal label approved by a documented schema contract
source_location	Document, page, table, or dictionary section
mapping_status	exact, reviewed_alias, unresolved, or conflict

Do not infer from spelling alone that the two labels are interchangeable in every RRC delivery. The reviewed document supports recording the inconsistency. A production mapping still needs the exact export schema, data dictionary, and version that govern the file being processed.

Current endpoint does not erase document age

The Oil and Gas Field Information manual is available from the current RRC download catalog, while its PDF metadata and export description are historical. The article therefore records two separate facts: the endpoint was accessible on August 31, 2026, and the manual describes an older Oracle export.

The current Data Sets Available for Download page lists Oil and Gas Field Name and Numbers and Oil and Gas Field Rules as separate monthly products. That catalog supports current product identity and cadence. It does not prove that every older column, data type, or relationship is unchanged.

The legacy Field Information tape-layout manual separately documents G, O, and B class values and associated-gas-field pointer records. It is useful corroboration that these concepts have historical continuity. It is not a substitute for a current schema contract, and its tape record layout must not be presented as current Oracle-table parity.

Build a field-code evidence row

For each reviewed field record, keep enough context to reproduce the interpretation:

Evidence field	Entry rule	Failure state
source_object	Exact file, query export, or controlled document	Missing source identity
source_sha256	Hash the retrieved object when available	Bytes changed or unavailable
source_version	Stated version, export date, or access date	Undated source
table_name	Exact source table	Unknown table
source_field_label	Exact source spelling	Label drift
raw_code	Preserve G, O, B, blank, or other value	Invalid or unmapped code
field_id	Preserve source key without treating it as public property proof	Missing or duplicate key
field_number	Preserve exact eight-position value as text	Truncated or malformed
row_role	Parent field, oil information, gas information, or pointer target	Role unresolved
pointer_status	Exact, unresolved, ambiguous, blank, or out of scope	Review required
exception_note	Explain mismatch, missing row, alias, or version drift	Never leave a silent fallback

This row design creates information gain because it exposes where a parser can fail. It also keeps a future reviewer from mistaking a normalized result for the original source.

Reconcile the parent, child rows, and pointer

A deterministic review can use these checks:

1. Fingerprint the source object and attach its exact data dictionary.
2. Count parent og_field rows by raw class code.
3. Count child og_field_info rows by field_id and oil_or_gas_code.
4. Require one expected child role for G and O and two distinct roles for B.
5. Record duplicate, missing, unexpected, and filtered-out rows separately.
6. Resolve nonblank associated-field values only in the documented field-number domain.
7. Count exact, unresolved, ambiguous, blank, and out-of-scope pointers.
8. Compare all classified parent rows to the total reviewed population.
9. Stop when totals, roles, source versions, or target domains do not reconcile.

Useful controls are:

reviewed parents = G parents + O parents + B parents + unmapped parents

and:

reviewed pointers = exact + unresolved + ambiguous + blank + out of scope

These controls validate the parsing workflow. They do not validate a field boundary, property match, ownership chain, production record, reserves, or value.

What the codes and pointer do not prove

Texas RRC field classification codes do not independently establish:

• a geographic field boundary, county assignment, district mapping, or surface location;
• that a wellbore, API number, completion, lease, gas well ID, tract, unit, or deed belongs to the same private asset;
• mineral ownership, title quality, signing authority, royalty entitlement, or payment responsibility;
• production completeness, product mix for a particular owner, forecast, reserves, decline, or future development;
• tax treatment, appraisal result, mineral value, offer quality, buyer qualification, or sale outcome; or
• that two records describe the same interest because their field names, numbers, codes, or pointers appear related.

For the broader distinction among RRC identifiers, use Texas RRC District, County, and Field Codes: A Source-Label Crosswalk. Article 299 owns that non-equivalence boundary. For query inputs, retrieval time, result filters, and downloaded evidence, use the Texas RRC Field Search Retrieval Provenance Worksheet. Article 301 does not replace either job.

Controlled source record

Six official RRC source objects were retrieved on August 31, 2026 and retained as 1,727,228 controlled bytes.

Source object	Bytes	SHA-256 prefix	Bounded role
Oil and Gas Field Information data dictionary	74,568	b140a481947d	Schema, class codes, row cardinality, and pointer semantics
Legacy Field Information tape layout	1,397,759	0c0a14e30b93	Legacy corroboration only
Data Sets Available for Download	114,876	ba615bbe5eeb	Current product identity and cadence
Field Data	41,902	c4fdbaacb24b	Current field-level entry points
RRC Online Research Queries	51,438	92d30a3d9216	Query-system separation
About Oil and Gas Data Queries	46,685	93b8dabdfa94	Identifier and system-slice boundaries

Claim ledger and stop conditions

Claim ID	Supported statement	Allowed evidence label	Stop condition
C301-01	og_field stores general field information and field_class_code	RRC-FIELD-PARENT	Do not extend the field class into a private property conclusion
C301-02	G, O, and B mean gas, oil, and associated or both in the reviewed manual	RRC-FIELD-CLASS	Preserve the raw source character and document context
C301-03	og_field_info has one type row for oil-only or gas-only and two for both	RRC-FIELD-CARDINALITY	Stop on missing, duplicate, or unexpected type rows
C301-04	oil_or_gas_code identifies a type-specific row	RRC-FIELD-ROW-ROLE	Do not collapse oil and gas rows
C301-05	The associated-field item points to a related oil field number when paired numbers differ	RRC-ASSOCIATED-FIELD-POINTER	Do not use the pointer as a universal join
C301-06	The reviewed manual uses two spellings for the associated-field label	RRC-SOURCE-LABEL-VARIANT	Do not silently normalize an unreviewed schema
C301-07	Current catalog and query pages separate field products and query systems	RRC-CURRENT-SYSTEM-BOUNDARY	Do not represent a catalog page as row-level evidence
C301-08	The legacy tape layout corroborates concepts but not current schema parity	RRC-LEGACY-CORROBORATION	Do not copy legacy positions into a current parser without a current contract

Research scope and review boundaries

Before using a field code in an owner-specific workflow, verify the exact source object, table, field label, source date or version, raw code, field_id, field number, row role, pointer status, and exception. Questions about field boundaries, wells, leases, geology, engineering, title, tax, accounting, production, valuation, or a transaction belong with the responsible official source and qualified advisers.

Sources reviewed for this article

• Texas RRC: Oil and Gas Field Information data dictionary
• Texas RRC: legacy Field Information tape layout
• Texas RRC: Data Sets Available for Download
• Texas RRC: Field Data
• Texas RRC: Online Research Queries
• Texas RRC: About Oil and Gas Data Queries

Related mineral-rights research guides

• Texas Mineral Rights Guide
• Texas RRC District, County, and Field Codes: A Source-Label Crosswalk
• Texas RRC Field Search Retrieval Provenance Worksheet
• How to Build a Texas Mineral Production Record Locator Sheet

Educational information only. This article explains source-scoped regulatory field-data labels, row cardinality, pointer handling, and evidence boundaries. It is not legal, title, land, tax, appraisal, accounting, engineering, geological, investment, or financial advice; it is not a field delineation, property match, ownership opinion, production conclusion, valuation, offer, or transaction recommendation. Verify owner-specific facts with the responsible office and qualified advisers. MRX provides educational information and resources only and does not buy mineral rights.

Frequently asked questions

What do G, O, and B mean in Texas RRC field data?

In the reviewed Oil and Gas Field Information manual, G means gas field, O means oil field, and B means associated or both oil and gas. Preserve the raw source character and the exact table and field that supplied it.

Why can one field have two og_field_info rows?

The manual says an oil-only or gas-only field has one og_field_info row. A field that is both has two type-specific rows, one for oil and one for gas. Do not collapse those rows without preserving their oil_or_gas_code roles.

What does an associated field number prove?

It supports a narrow source-defined pointer between related oil and gas field records when their field numbers differ. It does not prove that a private well, lease, tract, owner, production record, or valuation belongs to either field.

Are associated_field_id and associate_field_id interchangeable?

Do not assume that silently. The reviewed manual uses associated_field_id in its table definition and associate_field_id in its narrative dictionary. Preserve the exact label and document location, then map labels only through a reviewed schema contract.

Can I use a field classification code to value mineral rights?

No. A regulatory field classification is not acreage, title, production, reserves, a price deck, or an offer. Those questions require their own owner-specific evidence and qualified review.

Sources reviewed for this article

• Texas RRC Oil and Gas Field Information data dictionary (accessed 2026-08-31)
• Texas RRC legacy Field Information tape layout (accessed 2026-08-31)
• Texas RRC Data Sets Available for Download (accessed 2026-08-31)
• Texas RRC Field Data (accessed 2026-08-31)
• Texas RRC Online Research Queries (accessed 2026-08-31)
• Texas RRC About Oil and Gas Data Queries (accessed 2026-08-31)