Decline-curve analysis is the load-bearing first step of almost every reserves number an operator reports. Yet for small and mid-size operators, the fit itself is still done in Excel — or inside heavy desktop suites whose economics and reporting machinery they may not even need for a quick look.
So we rebuilt the hard part. Auto DCA is a clean-room, dependency-free TypeScript engine that runs entirely in the browser — and it matches Equinor's production-grade, open-source decline math to 0.02 parts per million worst-case curve deviation, validated on real North Sea production data. No server. No upload. The production history never leaves your machine.
This post walks through where decline-curve analysis actually sits in the reserves workflow, why a client-side engine is a genuine architectural feature rather than a gimmick, and the three methodology choices that make an independent re-fit worth having.
Where DCA sits in the reserves workflow
Every reported reserve number flows through roughly the same pipeline. Decline-curve analysis (DCA) owns one stage of it — but that stage sets the trajectory for everything downstream.
production data ──► conditioning ──► DECLINE FIT (Arps) ──► EUR ──► remaining reserves
│
▼
economics / PV-10 ◄── volumes × price deck, net of WI/royalty/opex/capex/tax
│
▼
PRMS-2018 classification (P90/P50/P10; PDP/PUD; reserves vs resources)
│
▼
SEC reserves reporting ──► annual third-party reserve audit- Production data & conditioning. Well-level rates, back-allocated, corrected for downtime, with spikes, shut-ins, workovers, and early-time clean-up removed. The history window chosen here materially changes the EUR — this is where judgment enters first.
- The decline fit — Arps. Exponential (b = 0), hyperbolic (0 < b < 1), or harmonic (b = 1):
q(t) = qᵢ / (1 + b·Dᵢ·t)^(1/b). A b-factor near 1 produces very large, tail-sensitive EURs — which is exactly why a terminal-decline guard matters. - EUR. Integrate the rate curve to cumulative, truncated at the economic-limit rate.
- Remaining reserves. Cumulative-to-abandonment minus cumulative-to-date, split into proved / probable / possible.
- Economics / PV-10. Volumes × price deck, net of working interest, royalty, opex, capex, and taxes → net cash flow → discounted at 10%. PV-10 underwrites SEC filings, reserve-based lending covenants, and M&A.
- PRMS-2018 classification. The SPE-maintained Petroleum Resources Management System: project-based, resources vs. reserves, proved/probable/possible by uncertainty, by development status. DCA chiefly informs proved developed producing (PDP).
- SEC reporting & third-party audit. The SEC requires "reasonable certainty" under existing economic conditions; it does not mandate a specific math model, but the industry leans on Arps DCA. Public and leveraged operators engage the major independent reserve-audit firms, who re-fit and cross-check the operator's declines.
Auto DCA lives at stage 2, with honest hooks into stages 3 and 4 (EUR three ways; remaining-reserves-ready output). It does not attempt stages 5 through 7. Knowing exactly where it stops is the whole point of positioning it correctly.
The tooling landscape — and the fault line running through it
The reserves-software market is real and large, and it splits by deployment model and by how much of the pipeline each tool owns. The full-economics-and-reporting suites — ARIES, PHDWin, ComboCurve, Val Nav/Mosaic — own the expensive end. Engineering-analysis platforms like Harmony, whitson, and ResFrac feed forecasts into them. And at the bottom, ubiquitous and free, sits Excel and in-house Python for quick Arps fits and cross-checks.
Two structural facts matter for positioning anything new here:
- The fit step is the commoditized part. Standard Arps DCA is not where these suites differentiate — the economics, reporting, audit-trail, and financial-system integration are what the money buys. Governance and auditability are the product, not the curve fit.
- Deployment is bifurcating, and privacy is the fault line. Larger operators and national oil companies resist multi-tenant SaaS for production data; smaller independents are more cloud-willing. A spectrum of full-on-prem → hybrid → full-SaaS will persist.
Why client-side is a feature, not a gimmick
Well-level production histories, decline parameters, type-curve libraries, and EUR distributions are among an operator's most commercially sensitive IP. They reveal drilling-inventory quality, completion effectiveness, capital efficiency, and remaining potential — and proved reserves are financially material to securities disclosures, loan covenants, and M&A.
The documented operator concerns about cloud reserves tools are concrete: multi-tenant exposure, fear of cross-client aggregation into vendor benchmarking models, data-residency rules for multinationals and NOCs, and data governance as a first-class procurement criterion.
Auto DCA's answer is architectural, not contractual: the entire fit runs in the browser. The production data never leaves the machine — there is no server to send it to. That was a deliberate Phase 0 design decision, not an afterthought. It is the deployment model that needs no data-governance negotiation at all.
What we built
The spine of the whole exercise is a single number: a clean-room TypeScript rewrite, fit in a different parametrization, lands on the same curves as Equinor's reference scipy code to within two parts per hundred million — on real production.
Reverse-engineering how Equinor actually does DCA
The first thing the reference code makes clear is that production-grade DCA is not naive least-squares:
- Fit in log space with a robust p-norm loss (default p = 1.4), optional half-life time-decay weights so recent data counts more, and an optional Gaussian prior.
- Arps reparametrized to unbounded coordinates so the optimizer never fights box constraints — and a clean identity falls out: the EUR is recoverable directly from one of the fit parameters.
- "Auto" means cross-validating the model choice and picking the curve that forecasts the held-out tail best.
We wrote an exact math spec, stood up a Python oracle to confirm parameter recovery on synthetic Arps wells, and generated golden test cases from synthetic data plus six real Norwegian Continental Shelf fields (SODIR open data, NLOD licence): Gullfaks, Statfjord, Oseberg, Draugen, Gyda, and Varg. Two of those (Gyda, Varg) correctly collapse from hyperbolic to exponential when that fits better — a free correctness check.
The engine, and the parity result
The engine is @workollab/auto-dca-engine: Exponential, Hyperbolic, and Harmonic models, each fit over an unbounded parameter vector and mapped back to engineering (qᵢ, Dᵢ, b); the exact p-norm log-space loss; a from-scratch Nelder-Mead optimizer with multi-start; closed-form cumulative, EUR, and economic-limit time; AICc model ranking; and a residual-bootstrap confidence band. Zero runtime dependencies.
The headline result:
| Case set | Worst curve deviation |
|---|---|
| Synthetic wells | 0.006 ppm |
| Real SODIR wells | 0.019 ppm |
Worst case across everything: 0.019 ppm (1.9 × 10⁻⁶ %). b-factors match to three decimals; degenerate wells collapse identically; tests green across the board.
Watch it fit
We instrumented the optimizer so the Nelder-Mead search records its best-vertex trajectory and counts function evaluations, then replay it in the browser across all three model families — e.g. "2,259 curve evaluations across 3 families." It turns "auto" from a claim into something you watch happen, with zero impact on the parity number. The demo is a hand-rolled SVG chart (no charting library) with history, fit, forecast, the bootstrap band, an economic-limit marker, and a log/linear toggle — and it ships as a 58 KB gzipped static bundle that serves from any CDN.
The methodology that earns audit credibility
Three decisions map directly onto the documented methodology debate in the field, and each lands on the conservative, audit-friendly side.
1. Robust log-space loss, not least-squares
Production data is multiplicatively variable and riddled with shut-ins and operational artifacts. Fitting in log space with a sub-quadratic (p = 1.4) loss keeps abnormal points from skewing the fit — the same reason Equinor designed it that way.
2. Expanding-window cross-validation, not a single hold-out
This one came out of a real bug. On Gullfaks, the model selector was picking harmonic — but every robust metric prefers hyperbolic:
| Gullfaks metric | Picks |
|---|---|
| In-sample R² | hyperbolic (0.9465 vs 0.8722) |
| AICc | hyperbolic (−1099 vs −780) |
| 5-fold expanding CV | hyperbolic |
| Single 70/30 hold-out | harmonic ← the only metric that picked harmonic |
The single hold-out split was being gamed by Gullfaks's late infill-drilling uptick — it rewarded harmonic's slow decline for "predicting" a rise that isn't decline at all. The fix was to replace the single split with expanding-window cross-validation (walk-forward folds that respect the temporal order of production). Every oil field now picks a proper hyperbolic with a finite EUR. The lesson, plainly: single train/test splits are fragile on real production data; expanding-window CV is the honest way to pick a decline model — and code-level engines can do it where many commercial tools don't.
3. Modified-Arps terminal decline (the over-booking guard)
Pure hyperbolic lets nominal decline drift toward zero, inflating EUR with an unrealistically long tail. Capping it at a minimum decline and switching to exponential is the SPE-standard guard against over-booking proved reserves. We added it as a transparent, adjustable input — and the build log shows it doing exactly its job: on Gullfaks, EUR drops about 3.3% to a more defensible number, and the deep-tail confidence band tightens to bracket the terminal forecast instead of sitting an order of magnitude above it. The guard matters far more for high-b, unconventional wells.
For a reserve auditor, the combination — a fit that matches a known-good reference to two parts per hundred million, a selector that resists the classic single-split trap, and a built-in over-booking guard — is exactly the profile that makes an independent re-fit worth having.
Where it fits — and where it deliberately does not
Auto DCA is a front end for the decline step, not a reserves-and-economics suite. It earns its keep in four concrete places:
- Pre-audit and audit cross-check. An independent re-fit that is transparent and reproducible — the honest second opinion on the number that goes into the filing.
- Quick-look on a laptop, with sensitive data, no upload. When putting a well history into a vendor cloud is the friction, a browser-only tool removes the friction entirely. This is the single clearest niche.
- Private-investor and stakeholder diligence. A non-operator can pressure-test an operator's EUR without buying an enterprise reserves seat.
- A teaching and reference artifact. An open, auditable engine that provably matches a production-grade reference to 0.02 ppm is a credibility object in its own right.
What it does not do, stated plainly: no price decks, no working-interest/royalty/tax economics, no PV-10 engine, no PRMS/SEC report generation, no native project export, no multi-well portfolio aggregation. Those remain the incumbents' territory. The right framing is complement, not replacement — Auto DCA is the privacy-preserving, auditable fit you trust, feeding the suite you already file from.
Honest caveats
- The numbers here come from real public data (SODIR North Sea fields) and the actual build log — not from a private client.
- Auto DCA is single-well, fit-and-forecast. It is not a reserves-reporting system and should never be positioned as one.
- Parity is not the same as method-correctness. Matching Equinor to 0.02 ppm proves the rewrite is faithful — not that Arps DCA is the right model for any given well. That judgment still belongs to the engineer.
Auto DCA is a clean-room rebuild of Equinor's open-source decline-curve-analysis library (MIT licensed), validated against the original on public SODIR production data. The decline math is Equinor's; the browser-native, zero-backend engine is ours.
Need to turn this engineering logic into a production-ready tool? Explore custom petroleum software development.