Manufacturing & Industrial
Predictive Maintenance API
You know what an hour of downtime costs on that line. What you do not know is which of forty machines is going to cause the next one.
- Industrial software vendors
- Equipment manufacturers
- Plant maintenance teams
- IIoT platforms
- Service contractors
What your customers would see
example interfaceMockupIllustrative mockup of the interface we would build. Figures shown are examples, not results from a live deployment.
The problem this solves
Maintenance in most plants runs on a calendar. Bearings get replaced every so many thousand hours whether or not they need it, which wastes parts and labour on healthy equipment while the machine that is genuinely degrading fails between intervals. Everyone involved knows this and the calendar persists because the alternative requires evidence.
The equipment is usually already instrumented. Vibration, temperature, current draw, pressure and cycle counts are being recorded, often into a historian nobody queries. The signal is frequently present: a bearing that will fail in three weeks has usually been drifting for two, and the drift is visible in the vibration spectrum if anybody looks at the right band.
The constraint is almost never sensors and almost always failure records. A model that predicts failure has to be trained on failures — dated, attributed to a specific component, with the mode recorded. What most plants have instead is a work order history saying “replaced pump, line down 4h” with no component detail and no fault mode. That gap is the single biggest reason these projects disappoint, and it should be confronted during discovery rather than at model evaluation.
Who buys this
Industrial software vendors, Equipment manufacturers, Plant maintenance teams, IIoT platforms, Service contractors
What the API returns
What comes back
- Failure probability per asset over configurable horizons, with confidence bounds
- Anomaly scores for assets with no failure history, derived from deviation rather than prediction
- Remaining useful life estimates where the degradation path is well enough observed to support one
- Fault mode indication where the signature is distinctive enough to separate modes
- Maintenance recommendations with the window, the expected intervention and the evidence
- Sensor health flags, since a drifting sensor and a degrading machine look similar
- Asset and fleet rollups for planning across a line, a site or a whole estate
- Model coverage reporting: which assets have a trained model, which are anomaly-only, and why
Endpoints
| Method | Path | Returns |
|---|---|---|
| POST | /v1/assets/{id}/predict | Failure probability and anomaly score for one asset |
| POST | /v1/telemetry/ingest | Push sensor readings in batch or stream |
| GET | /v1/assets/{id}/health | Current health state with contributing signals |
| GET | /v1/fleet/priority | Assets ranked by predicted risk and consequence of failure |
| POST | /v1/events/maintenance | Record an intervention or an observed failure as a label |
| GET | /v1/coverage | Model coverage, data sufficiency and confidence per asset class |
Request and response
illustrativeRequest
{
"asset_id": "pmp_0442",
"asset_class": "centrifugal_pump",
"horizons_days": [7, 30, 90],
"window": { "from": "2026-09-21T00:00:00Z", "to": "2026-10-21T00:00:00Z" },
"include": ["anomaly", "rul", "fault_modes", "sensor_health"]
}Response
{
"asset_id": "pmp_0442",
"asset_class": "centrifugal_pump",
"assessed_at": "2026-10-21T06:00:00Z",
"model": { "type": "trained", "failures_in_training": 41,
"class_assets": 128, "last_retrained": "2026-09-30" },
"failure_probability": [
{ "horizon_days": 7, "probability": 0.08, "ci": [0.04, 0.14] },
{ "horizon_days": 30, "probability": 0.31, "ci": [0.21, 0.44] },
{ "horizon_days": 90, "probability": 0.62, "ci": [0.48, 0.74] }
],
"anomaly": { "score": 0.78, "band": "elevated", "since": "2026-10-06" },
"remaining_useful_life": { "estimate_days": 38, "ci_days": [19, 71],
"basis": "degradation_trend" },
"fault_modes": [
{ "mode": "bearing_outer_race", "likelihood": 0.61,
"evidence": "Rising energy at 3.2x running speed since 06 Oct" },
{ "mode": "impeller_imbalance", "likelihood": 0.18,
"evidence": "1x harmonic within normal band" }
],
"sensor_health": [
{ "sensor": "vib_axial_02", "status": "ok" },
{ "sensor": "temp_bearing_01", "status": "suspect_drift",
"detail": "Baseline shifted 4.1C with no load change" }
],
"recommendation": {
"action": "inspect_bearing",
"window": "next planned shutdown, by 2026-11-20",
"consequence_if_deferred": "Line 3 stoppage, estimated 6h"
}
}Where the data comes from
| Your sensor telemetry | Vibration, temperature, current, pressure and flow from the equipment itself — usually already in a historian |
| Maintenance and work order history | Interventions, parts replaced and downtime records; the quality of this determines whether a trained model is possible at all |
| Failure records with fault mode | The scarce input. Dated failures attributed to a component and a mode are what the model learns from |
| Process and production data | Load, throughput and product mix, because degradation rate depends heavily on duty |
| Equipment reference data | Nameplate, design limits, bearing geometry and running speeds, which make spectral analysis interpretable |
| OEM service bulletins | Known failure modes and recommended intervals, useful as priors where your own history is thin |
The intelligence layer
The difference between a demo and a service is mostly in this section. These are the parts that keep the answer trustworthy once real traffic is hitting it.
- Spectral feature extraction from vibration data — band energies, envelope analysis, order-normalised harmonics — rather than raw amplitude thresholds, because fault modes live in specific bands
- Operating-condition normalisation, since the same machine vibrates differently at different loads and comparing across conditions produces nonsense
- Survival models for time-to-failure where failure labels exist, which handle the censoring that ordinary classifiers get wrong on equipment data
- Unsupervised anomaly detection as the fallback path for asset classes with too few failures, reported explicitly as deviation rather than dressed up as prediction
- Fleet-level pooling across similar assets, which is often the only way to accumulate enough failures for a usable model
- Sensor fault detection run before asset diagnosis, because an uncalibrated sensor is a far more common cause of an alarm than an actual fault
- Validation on held-out time periods with lead-time reported separately from accuracy — a model that detects failure four hours ahead is accurate and useless
- Alarm-rate budgeting and drift monitoring, since a predictive system that cries wolf gets switched off by maintenance within a month
What it changes for the business
Interventions placed in planned windows
Moving work from unplanned stoppage to scheduled shutdown is where most of the value sits.
Parts and labour not wasted
Condition-based replacement stops healthy components being changed on a calendar.
Prioritised attention
Fleet ranking by risk and consequence tells a small maintenance crew what to look at first.
A maintenance record worth having
Structured fault labelling makes the next model better and the asset history actually queryable.
How it fits into your product
How it embeds
- Telemetry ingestion from your historian, OPC UA gateway, IIoT platform or flat-file export
- Predictions pushed into your CMMS as work order candidates with evidence attached
- On-premise or edge deployment, which is normal where plant networks are segregated from the internet
- Dashboard components for control room and maintenance planning screens
- Event endpoint so every intervention and failure feeds back as a training label
- Per-site and per-line scoping for multi-plant operators and service contractors
Included in every build
- Authentication, scoped API keys and per-customer rate limiting
- Input validation with predictable, documented error responses
- Versioned endpoints so your integration never breaks without notice
- Request and response logging for audit and dispute resolution
- Latency, error-rate and usage monitoring with alerting
- OpenAPI specification, sandbox environment and client examples
- Backups, failover design and a documented recovery procedure
- An agreed support arrangement once the service is live
How we would build it
about 20 weeksDiscovery and feasibility
Weeks 1–3
This one depends heavily on data access, so we start by proving the sources exist, can be licensed for your use, and actually carry the signal the model needs. If they do not, you find out here.
Architecture and baseline model
Weeks 4–6
A written architecture and a baseline model measured against a holdout period, so you know what accuracy you are buying before the full build starts.
Production build
Weeks 7–16
Data pipelines, model training and serving, historical archive, validation harness, API, security, monitoring and documentation.
Validation and integration
Weeks 17–20
Backtesting against held-out history, accuracy reporting your team can audit, integration support and an agreed retraining cadence.
Commercial models
There is no fixed price list, because the cost is driven by data complexity, integration count, model requirements, request volume and the support level you need. Scope is agreed in writing before development starts.
Fixed-scope prototype
A defined slice of the service, built and priced as one piece of work. The usual first step when the business case needs proving internally.
Fixed-price build
An agreed scope against a written architecture, delivered for an agreed price. Best when the requirements are already clear.
Build then retainer
We build the service, then operate and improve it under a monthly agreement covering monitoring, updates and model maintenance.
White-label product
The service runs under your brand, your domain and your pricing, with MLPivot invisible to your customers.
Questions buyers ask
What if we have almost no failure records?
Then a failure-prediction model is not honestly available yet, and we would say so rather than train one on nine events and present the output as a probability. There is a real path, though. Start with anomaly detection, which needs only normal-operation data and flags deviation without claiming to predict failure. At the same time, instrument the failure recording — component, fault mode, date, downtime — as a structured field in the CMMS rather than a free-text note. Pool across similar assets in the fleet to accumulate events faster. Most plants reach a workable training set in twelve to twenty-four months of disciplined recording, and the anomaly layer earns its keep in the meantime.
How far ahead can it warn you?
It depends entirely on the fault mode. Bearing degradation is often visible weeks ahead because it progresses slowly through a recognisable sequence. Sudden mechanical breakage and electrical faults frequently have no useful precursor at all. We report lead-time distributions per fault mode from the validation rather than quoting one headline number, because a single figure hides exactly the information you need for planning.
Do you need to send plant data to the cloud?
No. On-premise or edge deployment is the usual arrangement — plant networks are commonly segregated, and that is sensible. The models run next to the historian and only results leave, or nothing leaves at all.
Can this cover equipment from many different manufacturers?
Yes, and mixed estates are the normal case. What matters is sensor coverage and reference data per asset class, not the badge. Assets with thin instrumentation get anomaly scores at best, and the coverage endpoint says plainly which assets have a trained model and which do not.
Will it tell us a machine is fine when it is not?
Sometimes, and you should plan for that. No condition-monitoring system catches every failure, particularly modes with no precursor in the instrumented signals. This reduces unplanned downtime; it does not eliminate it, and we would resist any business case written as though it did.
Related blueprints
Quality Defect Detection API
Defect classification and inspection scoring from production images and process data, built on your own labelled examples.
Factory Production Optimisation API
Bottleneck prediction, throughput forecasts and schedule recommendations from the production data a plant already records.
Industrial Parts Matching API
Cross-references equivalent components across manufacturers using part numbers, dimensions and technical specifications.
Want this built for your platform?
Tell us what your product does today and what you want another system to be able to ask it. We will come back with an approach, a scope and a price.