Machine learning

Wellplanner puts a failure likelihood on a tool before it ships.

A likelihood, with the runs it was drawn from, so the engineer decides and the model does not. It can do that because it holds the tool's whole life in one record: the serial that was quoted is the serial that shipped, ran, came back and was invoiced, so the run history a model needs is already there.

Why this works here

The data model is the reason, not the algorithm.

Every operator can buy the same statistical methods. What is hard is having the data in one shape. In most companies the quote lives in one system, the run report is a PDF, and the service history is a maintenance spreadsheet, so the three can never be joined on a serial with any confidence.

Wellplanner never re-keys a tool. Opportunity, job, shipment, run, return and invoice are stages of one record, which means the training set is a by-product of ordinary work rather than a data project someone has to fund.

  • Run count, failure and service interval held per serial
  • Ratings and materials on the part, with limits derived per assembly
  • Conditions recorded offshore at the time, not reconstructed afterwards
  • Models trained on your own operation before anything else

The four modules

Four capabilities, in the order they become possible.

They are separate because they have different prerequisites and different risk. Each one states where it stands, because a roadmap is not a feature list.

Data import Historical run and service records from spreadsheets and exports, with free text notes structured on the way in. It needs no corpus, so it is where a company with ten years of history starts. In beta.
Run reliability Run count, failure rate and service interval per serial. Descriptive only and fully explainable, which is the trust a prediction needs later. Useful from about 50 runs. In build.
Run risk Failure likelihood per tool and per assembly, before dispatch, so a marginal tool can be swapped on the base rather than on the rig. Needs a real corpus from a real operation first.
Fleet benchmark Reliability against an anonymised industry baseline. Needs more than one contributing company, and consent to contribute is a separate decision from permission to see it.

In the product

The worklist starts carrying a forward-looking signal.

There is no separate module to visit. Two thirds of the product is the same worklist, and the change is that a row states what is likely to happen next as well as what is true now. A tool that is due, marginal or unusually worn is visible where it is picked.

The product shows the mechanism and the evidence rather than a label. A planner reads 72 percent, based on 34 comparable runs, and decides. Wellplanner reports the situation and names the decision; people make it.

Where the history is kept

Consent and limits

What we will not do with your data.

Consent is not a feature toggle Whether a company can see the benchmark and whether its data contributes to one are two separate records. Turning on a feature can never opt an operation into a shared model.
Your data is yours Full export and a documented API, with no lock-in clause. That holds for the run history a model is trained on as much as for anything else.
No claim without evidence A figure is shown with the number of comparable runs behind it. Where there is not enough history, Wellplanner says so instead of producing a confident number.
Nothing here is oversold Two of the four modules are in build and two need a corpus first. That is stated on this page rather than discovered during procurement.

Bring ten years of run history and we will read it.

Spreadsheets, exports and service records in whatever shape they are in. The import is the first step, and it is useful before any model exists.

Book a demo See the solution