The 2024–26 reservoir engineering literature has converged on the diagnosis: small and mid-cap operators, family offices, and mineral acquisition funds run modern capital on a workflow stack that hasn't changed since the 1990s. The reason isn't algorithmic. It's that the enterprise tools that close the gap — PHDWin, ARIES, Mosaic, OGRE, the surveillance platforms — are priced for organizations with dedicated reserves teams and IT budgets to match. The new fact in 2026 is that an open-source, modular replacement is buildable at the component level, runs on infrastructure that fits a five-person family office, and replaces 80% of what most small operators actually do with their spreadsheet patchwork. This post describes the reference architecture.

This is the third post in a three-part series. The first post walked through the three workflow gaps the recent literature has documented. The second post covered what super-majors have actually built — Equinor's Johan Sverdrup digital twin and the SLB/ONGC agentic AI framework — and the architectural pattern both share.

Why this hasn't been built for the bottom of the market

The honest answer: the economics didn't work for incumbent vendors.

PHDWin, ARIES, Mosaic, OGRE — these are excellent tools. They're priced for organizations with dedicated reserves teams and the IT budgets to match. The data ingestion and surveillance layers, if you buy them, are typically separate platforms with their own license fees. The integration work to connect them into a coherent pipeline is consulting time on top.

For a five-person family office managing $30M of mineral assets, a twelve-person E&P operator with 80 wells, or a fund underwriting an acquisition over six weeks, the all-in cost of a full enterprise reserves stack lands somewhere between impossible and six months of due diligence with the wrong CFO. So they don't buy it. They keep the spreadsheets, the once-a-year PDF TPR, and the institutional knowledge in one or two analysts' heads.

The new fact in 2026 is that the buildable, modular open-source replacement now exists at the component level. PostgreSQL+PostGIS handles the spatial and well-master data. SciPy handles the curve fitting. FastAPI handles the API surface. Pandas, NumPy, and numpy_financial handle the economics. The agentic AI patterns SLB demonstrated for large-scale well modeling are publicly architectable. The cost is engineering integration time, not vendor licensing.

The reference architecture

Three modules, sharing a common Postgres backbone:

┌────────────────────┐    ┌─────────────────────┐    ┌──────────────────────┐
│ Ingestion          │    │ Model / forecast    │    │ Reporting + audit    │
│                    │ →  │ layer               │ →  │ layer                │
│ - State agency     │    │ - Batch DCA engine  │    │ - PRMS 2018 classify │
│   (TX RRC, NM OCD, │    │ - Monte Carlo P10/  │    │ - SEC-ready outputs  │
│   OK OCC, ND DMR)  │    │   P50/P90           │    │ - Versioned audit    │
│ - Operator portals │    │ - Physics + ML      │    │   trail              │
│ - SCADA / IoT      │    │   hybrid forecasts  │    │ - TPR-ready exports  │
│ - Division orders  │    │ - Simulation post-  │    │ - Sensitivity tables │
│ - Type curve libs  │    │   processing        │    │ - Anomaly alerts     │
└────────────────────┘    └─────────────────────┘    └──────────────────────┘
       PostgreSQL/PostGIS · FastAPI · scipy/Pandas · scheduled jobs · React UI

Each module is independently testable, replaceable, and deployable. That's the principle. Build one in isolation, validate it against the existing workflow it replaces, then build the next.

Module 1 — Ingestion

The data layer that everything else builds on. Three jobs:

  • Pull state agency permit and production data on a schedule. The Texas Railroad Commission publishes monthly P-1 production data via public ArcGIS REST and CSV. New Mexico OCD, Oklahoma OCC, and North Dakota DMR all publish on similar terms. Build adapters per agency, cache to Postgres, refresh on a schedule.
  • Pull SCADA and IoT streams via standard protocols. Either OPC UA / MQTT / REST polling against the operator's own SCADA, or via vendor APIs (Variable Energy, Tachyus, etc.) where the operator already pays for that integration.
  • Maintain a canonical well registry. Reconciles RRC permit IDs, operator-internal IDs, API numbers, and division order references. The lack of this single reconciliation layer is the number-one cause of "we have three different numbers for the same well" cleanup work — and it's the foundation everything else depends on.

The validation pattern at this layer is straightforward: every well ID flows through a single normalization step, every production reading flows through a sanity check (rate ≥ 0, monotonic time series, allowed unit conversions), and every conflict between sources surfaces as a flagged record rather than a silent overwrite.

Module 2 — Model / forecast

The numerical layer. Four capabilities:

  • Batch DCA engine. scipy.optimize.curve_fit for Arps (transient, hyperbolic, exponential), with configurable parameter bounds and automatic regime segmentation. Runs across the full well population in parallel, not one well at a time interactively.
  • Probabilistic forecasts. Monte Carlo across price, decline rate, terminal decline, and operational uptime to produce P10/P50/P90 distributions per well, rolled up to project and portfolio level. Tens of thousands of simulations per well is trivial on a small VPS in modern Python.
  • Optional ML uplift. Feature engineering over completion variables (lateral length, proppant intensity, frac stages, spacing) to adjust type curves for similar offsets — the hybrid ML+DCA pattern the TWA / Novi Labs reporting describes. ML doesn't replace the physics-based DCA; it parameterizes it more intelligently from observable completion data.
  • Physics post-processing. Ingests simulation output (Eclipse .UNRST, CMG outputs, ARIES forecasts, PHDWin exports) and converts to a consistent internal forecast representation that the reserves and economics layers can consume. The architecture pattern is exactly the one SLB+ONGC used for their Pipesim wrapper: leave the physics engine alone, build a Python adapter that turns its output into a standard shape.

The key engineering decision at this layer is choosing the canonical forecast representation. A defensible choice is a monthly oil and gas rate forecast per well, with parameters versioned alongside (decline coefficients, b, Di, segmentation breakpoints, source — DCA fit vs. ML uplift vs. simulator output). Every downstream consumer reads the same shape.

Module 3 — Reporting + audit

The output layer. Five things it produces:

  • PRMS 2018 classification logic encoded as rules. Project maturity, commercial criteria, technical uncertainty bounds — leading to consistent 1P/2P/3P or P1/P2/P3 categorization across the book. No analyst-by-analyst judgment-call drift.
  • Versioned input snapshots. Every reserves number links back to the exact input data version, assumption set, and code commit that produced it. When an auditor or a buyer challenges a number eighteen months later, the answer is queryable in seconds rather than reconstructable in weeks.
  • TPR-ready exports. PDF and structured data outputs that an outside reserves auditor can ingest directly. The audit trail becomes a database, not a folder of PDFs.
  • Sensitivity tables on every output. Price ±20%, decline curve ±20%, discount rate ±300 bps. The output any buyer in diligence asks for first.
  • Anomaly surveillance. Change-point detection on water cut, GOR, and rate. The 2025 SPE ATCE paper on real-time water-cut and GOR anomaly detection describes this exact pattern — the pipeline produces alerts when a well's behavior deviates from its forecast envelope by more than a configurable threshold.

This is where the cumulative value of the stack shows up. A small operator running this pipeline has the same auditability and reproducibility a super-major has — at a fraction of the budget. The reserves report stops being a six-week stitch-up. It becomes a query.

Cost and timeline

The realistic numbers for a modest, focused build of the three-module pipeline:

ComponentEstimate
Build time (one ingestion module, batch DCA engine, PRMS-compliant reserves output)4–8 weeks of focused engineering
Hosting infrastructure (managed Postgres + small VPS + scheduled job runner)$40–80 per month on Hetzner / DigitalOcean / similar
Vendor licensing$0 — open-source components throughout
Ongoing maintenance1–3 days per quarter for routine updates; an extra day or two when a state agency changes its data format

The ~$40–80/month infrastructure cost is real and defensible. A Hetzner CX22 dedicated VPS handles the compute. A managed Postgres+PostGIS on Supabase or a self-hosted Postgres on the same VPS handles the database. The scheduled jobs (DCA runs, ingestion refreshes, anomaly checks) are cron entries or a simple rq+Redis queue, both of which sit comfortably on a single small box for the volumes most small operators are running.

The 4–8 week build estimate is for a focused first scope: one ingestion adapter (e.g., Texas RRC), a batch DCA engine, a PRMS-compliant reserves output, and a simple analyst-facing UI. Adding more state-agency adapters, ML uplift, or simulation post-processing extends the timeline linearly per component.

What integration with existing reservoir engineers looks like

This pipeline isn't a replacement for reservoir engineers. The engineers know the reservoirs — the geology, the completion practice, the operator behavior, the basin idiosyncrasies. Nothing in the software stack replicates that judgment.

What the software does is move the work the engineer's time was wasted on:

  • DCA fits that took two days now run in minutes across the whole portfolio
  • New production data triggers an automatic re-forecast and flags any wells where the new data conflicts with the prior forecast envelope
  • The PRMS classification logic is consistent across the whole book, audit trail attached
  • The TPR is a query, not a six-week stitch-up
  • The engineer's time goes to interpretation — judging the physics, the operator quality, the basin-specific risk — not to data assembly

The published research is unanimous on this point. The productivity gain is in the workflow infrastructure, not in displacing the engineer. The 2024 Al-Mubarak TWA article is direct about it: petroleum engineers in 2026 need to work with data and automation tooling, and the operators who get there first will be the ones whose reserves estimates are defensible, fast, and consistently classified.

The takeaway

The reference architecture above is a sketch, not a blueprint. The actual build for any specific operator depends on their existing tools (PHDWin? ARIES? MineralWare? a spreadsheet?), their existing data sources (which state agencies, which operator portals, which SCADA system), and what they want the first deliverable to be (batch DCA replacing one-well-at-a-time? Reserves report generator replacing the once-a-year PDF? Anomaly surveillance on production data?).

But the principle is general. Each module is independently testable. Each can be built in weeks rather than quarters. The infrastructure runs at double-digit monthly cost on a single small VPS. The architectural pattern is the same one the SLB+ONGC paper describes — a legacy physics engine wrapped in a modern automation layer — applied to the specific stack a small operator actually runs.

The 2024–26 literature has converged on the diagnosis. The super-majors have built the reference implementations. The components for the open-source replacement at the bottom of the market are off the shelf. What's left is the integration engineering — and for a portfolio of any meaningful size, the math on doing that work yourself rather than continuing to bridge it manually is unambiguous.

Reading list

Sources

Need help operating this kind of stack securely in production? Explore self-hosted open source alternatives.