Six Days Behind: What the Permit Lag Costs You
A subsurface engineering director at a PE-backed E&P sat down for a demo last month. He didn't want a tour. He wanted to know one thing: how fresh was our Texas permit data?
His incumbent feed was running about six days behind the RRC. Six days, on a basin where rig assignments and competitor moves can flip the math on an offset deal. He'd been quietly running the comparison for weeks.
That single number is why he took the meeting.
The pattern across calls
He's not alone. We heard the same complaint from three different buyers in recent weeks. An operator with assets in Lea, Andrews, and Elm Coulee. A Fort Worth mineral interest manager working Permian acquisitions. A two-person Permian E&P running side-by-side trials against their incumbent.
All of them flagged it independently. Permit and pre-permit data shows up too late to act on.
The mineral manager described the workflow plainly. A client tells her one major has acquired a package from another. She needs to reset the asset list in her engineering tool today, not next week. If her permit feed is stale, she's working from yesterday's map of the world while the operator has already moved.
The two-person E&P put it more bluntly. Their entire model is farm-ins and joint development. Pre-permit visibility is the difference between landing a position and watching someone else land it.
What "live" actually means
Energy Domain scrapes Texas RRC submissions the day they hit the filing system, before an API14 is assigned. Those show up as pre-permits in the platform. It's the earliest signal available that something is moving on a tract.
In the engineering director's words, his incumbent feed was lagging ours by several days on the same wells. We've seen the same delta in head-to-head comparisons run by other prospects.
The downstream effect matters. AOI alerts fire on the day of submission, not the day the permit gets cleaned and republished by an aggregator. Daily digest emails surface pre-permits, permits, rigs on location, SPUDs, and completions across every AOI a user has built.
Why aggregators lag
The honest answer is that incumbent pipelines were built around manual processes a decade or more ago. Records get scraped, then queued, then hand-checked, then normalized through workflows designed when filings came in by fax. Those steps don't get faster by adding seats. They add days, every time.
We built the pipeline from scratch on modern infrastructure. State filings flow in directly, get parsed and structured automatically, and land in the platform the same day. The data isn't rougher because it's faster. It's faster because the architecture isn't carrying twenty years of legacy tooling behind it.
That's why the gap exists. It's not a tradeoff. It's the difference between a system designed for today's filing cadence and one retrofitted from yesterday's.
What this looks like in practice
The director scheduled a follow-up demo with our engineering lead the following week. He's asking his incumbent account manager about his contract end date, quietly, then setting up a parallel test database to stream a subset of our data into Spotfire and run his existing workflows against ours.
He's not switching on the strength of one demo. He's switching because the lag is real, the price gap is roughly 40 percent, and he can prove both to himself in his own environment.
That's the bar. If the speed claim doesn't survive a parallel run on a buyer's own workflows, it doesn't matter how good the marketing copy is.
See it on your own AOI
If you want to test this against your own data, the fastest path is a side-by-side. We'll set up a pilot, give your team broad access, and let you run it next to your incumbent for a few weeks. You'll see the lag for yourself.
Request a pilot or email us to scope one. Bring an AOI you care about and we'll show you what we're seeing on it today.
Next in this series: why building an AOI shouldn't require a GIS team, and what happens when it does.
