Mineral Rights Offer Version-Control and Deadline Register

Direct answer for mineral owners

Give every written offer artifact its own register row. Preserve the received time and timezone, issuer or offer ID, version label or displayed date, stated deadline and timezone exactly as written, source filename, controlled retained reference, current/superseded/unclear state, and changed-field locator. An optional SHA-256 digest can show that file bytes differ; it cannot prove authorship, authenticity, legal validity, fairness, ownership, or fraud.

Key takeaways for mineral owners

• One row represents one exact written offer artifact; a revised attachment receives a new row instead of overwriting the earlier one.
• Transcribe deadline text and timezone exactly as received without calculating, normalizing, extending, or interpreting it.
• Use consistent descriptive filenames and preserve the original source filename separately.
• An optional SHA-256 digest detects byte differences only; it does not authenticate a party or document.
• Keep the register separate from buyer comparison, fairness, value, contract interpretation, negotiation, ownership, and accept-or-reject decisions.

Records-control boundary. This article explains a neutral administrative register for written offer artifacts. It does not rank a buyer or offer; determine fairness, value, legitimacy, ownership, property scope, or legal effect; interpret a contract; recommend acceptance or rejection; negotiate; calculate or normalize a deadline; authenticate a document; detect fraud; or provide legal, title, land, tax, accounting, appraisal, investment, or financial advice. General consumer sources cited below are not mineral-rights law. MRX provides educational information and resources only and does not buy mineral rights.

Mineral rights offer version control means preserving each written offer artifact as a separate record before anyone compares terms or makes a decision. The register answers administrative questions: What file arrived? When did it arrive? Which version label did the sender use? What deadline text appeared? Where is the retained copy? Which fields changed?

It does not answer whether an offer is fair, whether a deadline is enforceable, whether a party is legitimate, or whether an owner should sign. Those are different jobs.

Start the register before evaluating an offer

Email threads, portal downloads, text-message attachments, and revised PDFs can create several artifacts with similar names. Overwriting an earlier file removes the cleanest way to show what was available at a particular point in the correspondence.

Add a row when a written artifact first arrives. Preserve the original file in an authorized controlled location and assign a neutral register ID. If a revised file arrives later, add another row. Do not replace the earlier artifact, silently rename it as the new one, or merge details from different versions.

Keep this register separate from the offer correspondence index. The correspondence index locates messages and contacts across a communication history. This version register identifies exact written offer artifacts and the administrative relationship among them. A message may point to an attachment, but the message and attachment remain separate evidence objects.

Give every exact artifact its own row

One row should describe one exact file or other fixed written artifact. Record:

• a neutral register ID;
• received date, clock time, and timezone from the receiving system;
• delivery channel;
• sender-displayed organization or contact label, stored by controlled reference when private;
• sender-displayed offer ID, revision label, or document date, if present;
• original source filename exactly as received;
• controlled retained-reference location;
• stated response deadline text and timezone exactly as written;
• administrative state: current, superseded, or unclear;
• a locator for each observed changed field; and
• the person responsible for a bounded follow-up.

Do not fill a missing value from memory or from another file. Use not displayed, not captured, or unclear, as appropriate. A later correction should be traceable rather than silently replacing the original entry.

The register may use a neutral internal identifier for a party or property. A public template should not expose an owner name, buyer contact, tract description, account number, price, signature, private filename, private deadline, or the document itself.

Preserve deadline text without computing it

A sender may place time-related language in an email, attachment, portal, or more than one location. Copy each relevant statement exactly into a controlled reference and identify where it appeared. Record any displayed timezone. If the timezone is absent, record not displayed; do not infer one from the owner’s location, the sender’s address, or a device setting.

Do not calculate a response date, normalize one timezone into another, decide which conflicting statement controls, or state that a deadline is binding, extended, expired, waived, or invalid. Those conclusions can depend on facts and law outside the register. Preserve the conflict as written and open a bounded question for a qualified reviewer.

This is also why received at and stated deadline are different fields. One comes from the receiving record. The other is text presented by the sender. Neither field interprets the other.

Use a consistent filename while preserving the original

The National Archives and Records Administration’s file-naming guidance recommends descriptive, meaningful names, a consistent structure, and dates or version numbers in consistent positions. That federal records-management guidance is not a mineral-rights requirement, but the administrative principle is useful here.

Keep two filename fields:

1. Original source filename: the name exactly as received.
2. Controlled retained filename: a consistent internal name that begins with the neutral register ID and uses an approved date and version pattern.

Never change the original-file field merely because its spelling, date order, or version label looks inconsistent. The controlled name helps retrieval; the original name preserves provenance.

Avoid real owner names, tract names, prices, tax identifiers, or account numbers in filenames that may appear in backups, screenshots, logs, or shared directories. Use access controls appropriate to the underlying documents.

Add an optional digest only for byte-change detection

NIST FIPS 180-4 specifies secure hash algorithms that produce message digests. When an authorized workflow supports it, the register can store a SHA-256 digest for the exact retained file. Recomputing a different digest is evidence that the bytes differ.

That is the limit of the claim. A matching digest does not prove:

• who created, signed, or sent the document;
• that the sender’s identity is genuine;
• that the file contains every page or term;
• that the offer, deadline, or agreement is valid;
• that the document applies to a particular property or owner; or
• that a party or transaction is legitimate or fraudulent.

Different bytes also do not explain what changed or why. A file may differ because of content, metadata, export software, image compression, or another byte-level change. Use a changed-field locator for human-readable differences and keep the digest as a narrow technical aid.

Label version state without claiming legal effect

Use only three administrative states:

• current: the retained correspondence identifies this artifact as the present version;
• superseded: retained correspondence identifies a later artifact as replacing this one; or
• unclear: the written evidence does not support either label.

Record the controlled reference that supports current or superseded. If the relationship is ambiguous, use unclear and preserve the question. Never infer a state from a later filename alone.

These labels do not decide amendment, revocation, acceptance, enforceability, or any other legal effect. A file can be administratively marked superseded while its legal significance remains outside this workflow.

Locate changed fields without interpreting them

For each later artifact, record the page, section heading, paragraph, table row, or other stable locator for an observed change. Use a neutral field category such as property description, payment text, closing condition, deadline text, signature block, or other.

Describe the change only far enough for an authorized reviewer to find it. Do not score the change, call it favorable or unfavorable, determine its monetary effect, or explain what it means legally. A changed-field record is a locator, not an evaluation.

When a comparison is needed, the fair-offer guide and purchase-agreement guide describe separate review questions. Keep any analysis they produce outside the version register.

Preserve pressure communications without labeling a party

Texas Attorney General pages advise consumers in other transaction contexts to read written terms, keep copies, and recognize high-pressure or limited-time tactics. See How to Avoid Home Improvement Scams and How to Spot and Report Phone Scams.

Those pages provide general consumer guidance; they do not establish a mineral-rights rule or prove that a mineral-rights offer, deadline, or party is improper. Use them only to support careful preservation and bounded questions. Do not convert a short response window, repeated contact, or changed file into a fraud or legitimacy conclusion.

Blank version-control register

Field	What to preserve
Register ID	Neutral identifier for one exact artifact
Received at	Date, clock time, and timezone from the receiving record
Delivery channel	Email, portal, text attachment, mail scan, or other documented route
Issuer or offer reference	Controlled pointer to the sender-displayed label or ID
Displayed version or date	Exact source-displayed label, or not displayed
Original source filename	Exact filename as received
Controlled retained filename	Approved descriptive name using a consistent date/version pattern
Retained reference	Authorized controlled location for the exact artifact
SHA-256 digest	Optional byte-change aid, or not captured
Stated deadline text	Controlled exact transcription with source locator
Displayed deadline timezone	Exact displayed timezone, or not displayed
Version state	current, superseded, or unclear, with supporting reference
Prior-version relationship	Controlled pointer to the earlier artifact, when supported
Changed-field locator	Page, section, paragraph, table row, or other stable locator
Open question	Bounded factual or professional-review question
Handoff owner	Authorized next reviewer and narrow task

Keep the public template blank. Do not add real parties, properties, amounts, terms, signatures, filenames, deadlines, or conclusions merely to make the example look complete.

Close the records job before opening a decision job

The version-control job is complete when every received written offer artifact has its own retained reference, timestamps, original filename, optional digest state, exact deadline-text reference, administrative version state, changed-field locator, limitations, and responsible next owner.

At that point, hand the controlled record to the appropriate separate workflow. A factual question can go to the sender. Contract language and deadlines can go to a qualified attorney. Ownership and property scope can go to the appropriate land or title professional. Value and offer comparison can go to an independent valuation or offer-review process.

Do not record those later judgments as if they were facts produced by the register. The register’s value is narrower: it keeps the exact written versions from being mixed, overwritten, or detached from their provenance.

Sources reviewed for this article

• National Archives, NARA Bulletin 2015-04 Appendix B
• NIST, FIPS 180-4 Secure Hash Standard
• Texas Attorney General, How to Avoid Home Improvement Scams
• Texas Attorney General, How to Spot and Report Phone Scams

Frequently asked questions

Should I replace an older offer file when a revised one arrives?

No. Preserve the earlier artifact under its own controlled reference and add a new row for the revised file. Mark the relationship as current, superseded, or unclear only when the written evidence supports that state.

Should the register calculate how much time remains?

No. Preserve the stated deadline and timezone exactly as written. Deadline calculation, extension, enforceability, and contract interpretation belong with a qualified professional.

Does a matching SHA-256 digest prove that an offer is authentic?

No. Matching digests indicate that the compared bytes match. They do not prove who created or sent the file, whether it is complete, whether terms are valid, or whether a transaction is legitimate.

Does superseded mean the earlier offer has no legal effect?

No. It is only an administrative relationship in this register. The label does not determine amendment, revocation, enforceability, acceptance, or any other legal effect.

Can this register tell me which offer is fair or which buyer to choose?

No. It preserves versions and provenance only. Fairness, value, buyer comparison, contract review, negotiation, ownership, and transaction decisions require separate analysis.

Sources reviewed for this article

• National Archives, NARA Bulletin 2015-04 Appendix B (accessed 2026-08-25)
• NIST, FIPS 180-4 Secure Hash Standard (accessed 2026-08-25)
• Texas Attorney General, How to Avoid Home Improvement Scams (accessed 2026-08-25)
• Texas Attorney General, How to Spot and Report Phone Scams (accessed 2026-08-25)