Trial on demand
Don't watch a demo. Measure a pilot.
A SolvxAI pilot is built as a series of tests, not a walkthrough. We run your workflows under five checks — reproducibility, derivation review, refusal, memory, and elapsed time — and every response is evaluated against your data and success criteria written down before anything starts. Your pilot, your data, your results: confidential by default. You keep the numbers either way.
The five tests.
Each one is cheap, takes an afternoon or less, and targets a failure a demonstration cannot show you. They come straight from our research series, and they work on any vendor — not just us.
Run it twice.
Exposes: Systems whose output depends on which attempt you happened to observe.
Same inputs, different days. Compare the numbers, not the impressions. Our answers come from deterministic, cited engineering functions, so identical inputs give an identical answer — this test takes an afternoon and settles the reproducibility question for good.
Ask for the derivation.
Exposes: Right answers reached by routes nobody can follow into an audit.
Hand the output to a qualified engineer who wasn't in the room, and time how long it takes them to check it. Every figure we return carries its method, units, validity band and sources — review should be inspection, not re-derivation.
Give it something it should refuse.
Exposes: Systems that will always answer, because answering is all they can do.
Too little pressure history. A correlation outside the envelope it was fitted on. A question the data cannot settle. A system that answers anyway has failed the test that matters most. Ours declines — and names the condition that failed and what would make the analysis valid.
Come back in a month.
Exposes: Assistants that start every conversation from nothing.
Ask what it concluded, on what evidence, and what has been superseded since. Work here lands in a durable decision memory — superseded findings are retained, not overwritten, so the system can tell you what was believed on the date a decision was made.
Measure time, not impressions.
Exposes: Pilots that succeed in the survey and fail in the timesheet.
Score the pilot on elapsed time against comparable work — with a control, and preferably not collected by whoever sponsored the pilot. Self-reported productivity is unreliable in both directions, and we hold ourselves to this standard because it comes from our own research.
How a pilot runs.
- 1
A 30-minute scoping call
We pick one or two bounded workflows where hours measurably go today — surveillance, screening across your well count, data reconciliation, first-pass diagnostics.
- 2
Success criteria, written down first
Before anything runs: which workflows, measured how, against what baseline. If we can't agree what success looks like on paper, the pilot shouldn't start — that protects your time as much as ours.
- 3
Your data, under the boundary
The pilot runs on your data inside an isolated instance — access scoped per project, revocable, every action audited. The same guarantees on the trust page apply from day one.
- 4
The five tests, run for real
Reproducibility, derivation review, a refusal case, memory, and elapsed time. You choose the refusal case; we won't know what's coming.
- 5
A decision on numbers
You get the measurements either way — including the ones that didn't flatter us. If the pilot doesn't clear the criteria we wrote down together, that's the answer, and it's yours to keep.
What you're probably thinking.
- What happens to our data during a pilot?
- The pilot runs in an isolated instance — never on your machines or file systems. Access is granted per project and revocable at any time, every action is attributed and audited, and your originals are never modified. The full guarantees are on our Trust & Security page, and they apply to pilots exactly as they do to customers.
- What happens when it's wrong?
- Two things make errors survivable. Established physics runs in deterministic, cited engineering functions, so a number can be checked against the method that produced it — every figure carries its method, units and sources. And where a method doesn't apply to your data, the system declines and says why, rather than producing a plausible number. There's a full paper on why that refusal behaviour matters — White Paper No. 02 in our research library.
- We're two engineers and a few hundred wells. Are we too small?
- You're exactly who this is built for. The typical US independent runs a technical team small enough that every engineer wears several hats — the point of the operating system is to carry the surveillance, screening and reporting load those teams can't staff for. Small operators are our development-partner focus, not an afterthought.
- We already have a decline tool and spreadsheets that work.
- Keep them. A pilot doesn't ask you to replace anything — it runs alongside what you have, on the same data, and the elapsed-time test tells you whether it earns a place. If your current stack wins the measurement, you'll have the numbers that prove it.
- Can we self-host?
- Yes — if you want the data boundary absolute, the platform can be deployed in your own environment. Whether that's the right fit gets settled in the scoping call, not after you've committed.
- What does a pilot cost?
- Pilots are scoped per engagement — the price depends on well count and which workflows we measure, and you'll have a number at the end of the scoping call, not after a sales cycle. The scoping call itself costs thirty minutes.
Thirty minutes to scope it. An afternoon to run test one.
If the system doesn't survive the protocol, you'll have learned something worth knowing about every other vendor too — the tests work on anyone.