0
wells in one model
Reservoir to export · one solve
The physics and the data, from the sandface to the boardroom.
GraphSolve Energy solves your production system from first principles and carries measurement uncertainty all the way through the solve — to the allocated barrel, and to the optimisation case built on it. The number that decides ownership arrives with a range, and with the name of the instrument driving it.
reservoir → export, one solvesolving…
0
km of pipeline
0
graph nodes, solved together
<0 s
for the whole-field solve
One production model, solved as a single object on cloud infrastructure — under 30 MB on disk. Not a benchmark network: a field.
The idea underneath it
Everyone models the parts. Almost nobody solves the whole.
Your asset is a stack of models — reservoir, wells, network hydraulics, fluids, equipment, metering, allocation, contracts — that were never designed to talk to each other. Today they're wired together: numbers passed one at a time, through connectors somebody built by hand. We don't wire models together. We put them in one object and solve them at once — and the uncertainty travels with them.
Why it matters
Almost nothing you call a measurement was measured.
Fields are more instrumented and less certain than they have ever been. More sensors, noisier data, older assets, tighter margins — and decisions made in hours that used to take a week. The tools were built for a world where an engineer had a week to build a case file.
01
The numbers are already models
A rate off an orifice run is a correlation and an equation of state evaluated on a gas sample. A stock tank barrel is a volume multiplied by a shrinkage factor. They are model outputs presented as measurements — and the model's own uncertainty isn't carried forward.
02
And the errors aren't random
A meter that reads a little rich reads a little rich every day. That's not noise you can average away — it's a bias, and it quietly moves barrels from one owner to another.
03
One number, no warning
A well test from three weeks ago and a live pressure reading look identical on the screen. Nothing tells you which is a solid number and which is an educated guess.
04
The uncertainty is computed where it can't help
Your metering team quantifies uncertainty properly, to a standard, every year. Then the number goes into the allocation — and the uncertainty doesn't.
Sandface to boardroom
The number travels the whole way. Its uncertainty doesn't.
Your metering team quantifies uncertainty properly, to a standard, every year. Above that layer nothing represents it at all — not in the surveillance data, not in the allocation, and not in the optimisation case that decides what to change. We solve all four together and carry it the whole way.
One object, not a layer. Spanning these means joining modelling worlds that were never designed to meet — a metering uncertainty budget, a fluid model, a network hydraulic model, an allocation ruleset and an optimisation objective. Five formats, five owners, five solvers. The graph is what makes them one object.
What we believe
You should never have to guess how much to trust a number — and you should always know which instrument to go and check.
We solve the real physics of your system, and we solve the uncertainty in the same object. Not because a production network is unknowable — pipe ID, elevation, equipment curves and topology are all known — but because what you measured it with isn't perfect. A number you can act on should look different from one you should go and verify.
That is the opposite of a reservoir argument. Reservoir models are probabilistic because the rock can't be seen, and no instrument closes that gap. Ours can: go and fix the meter. We're precise about the physics and honest about the instruments.
What it does
One model, from the sandface to the sales meter.
Physics-first, defined properly: the conservation equations are solved when you ask the question, on your data — not baked into weights at training time.
Coverage
The whole system, one model
Reservoir inflow, tubing, choke, flowline, separator, compression and export — solved together, with consistent fluid physics the whole way. Change one thing and see what it does everywhere.
reservoir → export
Confidence
A range on every value — with a name attached
Measurement error, fluid uncertainty and modelling choice are carried through the solve. You get a range, and you see which instrument or assumption is driving it — so the uncertainty isn't a disclaimer, it's a work order.
range + attribution
Access
Built to be asked questions
Every calculation is available to your engineers, your scripts and your AI assistants. No desktop seat, no dongle, no waiting for a licence to free up. Ask it a thousand what-ifs before lunch.
~80 calculations, callable
Underneath: fluid & PVT behaviour · well inflow & nodal analysis · pressure drop through pipe and choke · compressors, turbines, pumps and valves · production allocation & meter reconciliation · decline, RTA and forecasting · debottlenecking and what-if screening.
Measured, not claimed
What we can show you today.
Two things are measured and shipped: the span the solver covers at real field scale, and uncertainty travelling across a join that a coupled model would have passed as a bare number.
Coverage and scale, measured. The reservoir-to-export span in one engine, at a size the desktop model estate was never built for — and it needs no benchmark to be true.
Uncertainty crosses the joins. Carrying a distribution across a subsystem boundary is the thing the co-simulation literature calls rarely supported. It runs in the engine today, and the looped-network case is covered — which is the sharpest technical objection, pre-empted.
And what we won't claim yet
We don't say "calibrated" until we've earned it.
We carry uncertainty through the whole solve today. What we have not yet published is a coverage test on real, biased field data: when we say 90%, does the truth land inside 90% of the time? That benchmark is running. Until it lands, we won't use the word calibrated on this page — and we'd rather tell you that now than have you discover it in a pilot. On the grid side, where the equivalent benchmark is published, the same method holds up: see the Power results →
Works with your model estate
Your existing models are an input, not an obstacle.
If it has a documented file schema or an API, it comes into the graph. Ingestion is schema-driven, so the models you already own and the data your historian already holds become nodes in the same object — rather than another migration project with a business case attached.
your model estate PVT & fluid studies historians & SCADA metering data allocation rules well tests your own scripts
Our view on AI
Give AI better tools —
don't train it on other models' output and call it physics.
AI is a superb interface. It makes a powerful system approachable and puts an expert beside every engineer — and we lean into that: ask about your field in plain language and the assistant reaches for the solver.
But upstream has a specific problem with learning the physics from data: the training data is itself model output. An orifice rate is a correlation and an equation of state evaluated on a sample. A multiphase rate is a fluid model plus a slip model plus a flow-regime model. Fit to that and you are fitting a model to the output of other models — and those errors are systematic, not random, so more data doesn't average them away.
A surrogate is also only valid where it was trained. The day you change the choke you're extrapolating, and nothing tells you that you are. Physics doesn't have a training envelope. The AI is the copilot; the physics is the source of truth.
How we compare
A different job entirely.
Two honest foils. Neither is a bad tool — they answer different questions, and one of them isn't asking about the instruments at all.
Deterministic simulators
AI & surrogate platforms
GraphSolve Energy
What it is
A solver, run case by case
A model trained on the output of other models
A solver over your whole system, run when you ask
Where the physics lives
In the solve
In the weights, fixed at training time
In the solve, on your data
Uncertainty
None — the inputs are assumed exact
On the fit, where there is any
Carried through the solve, and attributed to a source
A field with no history
Works
Cold start — nothing to learn from
Works: no operating history required
Change the topology
Rebuild the case
Retrain
It just solves — there's nothing to retrain
Metering & allocation
Outside the model, in spreadsheets
Outside the model
Nodes in the same graph as the pipe
How you reach it
A desktop seat and a licence queue
An API
An API, agent-callable, concurrent, no seat
Where we sit in the landscape
Plenty of tools model the field. Almost none tell you how far to trust the answer on the live production system.
Read the bottom-left corner correctly. Reservoir models are probabilistic because the rock is unknowable, and that's the right posture for that question. A production system is knowable — which is why we hold ourselves to a different standard on this one.
| Capability | GraphSolve Energy | Integrated asset modelling | Flow-assurance & process sim | AI production surveillance | Virtual flow metering | Reservoir & planning |
|---|---|---|---|---|---|---|
| Physics solved on your data, when you ask | ✓ | ✓ | ✓ | — | ◐ | ✓ |
| Reservoir to export in one engine | ✓ | ✓ | ◐ | — | — | — |
| A range on every value | ✓ | — | — | ◐ | ◐ | ✓ |
| Uncertainty attributed to an instrument | ✓ | — | — | — | — | — |
| Metering & allocation inside the model | ✓ | — | — | — | ◐ | — |
| Works with no production history | ✓ | ✓ | ✓ | — | ◐ | ✓ |
| Topology change without retraining | ✓ | ✓ | ✓ | — | ◐ | ✓ |
| Whole-field scale, tens of thousands of nodes | ✓ | ◐ | ◐ | ◐ | — | ◐ |
| Agent- and API-callable, no desktop seat | ✓ | — | ◐ | ✓ | ◐ | — |
✓ full · ◐ partial · — none Categories, not specific vendors. Reservoir platforms carry uncertainty too — about the rock, which no instrument reduces. Different question.
Who's behind it
Same method, different corpus.
GraphSolve Energy is built on the Data Insights AI engine — the same engine behind GraphSolve Power, where the calibration benchmark is already published. One method, held to the same standard in two industries.
PM
Dr Peter Mann
Founder. A renowned physicist, mathematician and graph-theory pioneer — computer scientist and lecturer, and author of Lagrangian & Hamiltonian Dynamics (Oxford University Press, 2018). The research mind behind the engine.
AT
Dr Alan Tominey
Founder. Scientific software developer, numerical-modelling specialist and optimisation expert, with a career spent inside production-network solvers — the engineering depth that turns the research into a product an operator can run.
In production on industrial systems in the North Sea · GCC · LATAM
Get started
Solve the network. Know the error bar.
Bring us a network — yours or a public one — and we'll solve it end to end, put a range on every value, and tell you which instrument is driving it.