The Outcome Gap: Why Most Maintenance Platforms Stop One Level Short of a Result
- The outcome is written in production units before anything is installed
- The baseline is agreed while it is still uncomfortable to agree it
- The scope reaches past the critical few
- The prescription reaches the floor as an instruction
- Process data is inside the subscription boundary
- The operator validates the outcome, and the validation is the deliverable
- What the first six months look like
- What level five returns at scale
Sensors, dashboards, integrated views and predictive analytics all tell you what is wrong with a machine. None of them gets it fixed. That difference is the outcome gap, and closing it is the whole job of an outcome-based subscription.
In short: Most industrial monitoring investments stop one level short of a production outcome. An outcome subscription only delivers when it is bought, baselined and reviewed on the production result rather than on platform activity.
- There is a ceiling built into levels one to four. Describing the machine is not the same as completing a repair and measuring what it returned.
- The unit of value has to change with the level. A subscription priced on production outcomes cannot be reviewed on sensor uptime and alert counts without losing its own argument.
- The baseline decides whether value is provable. A figure agreed before installation separates a reported outcome from an argued one.
- Action rate is the operative metric. Accuracy without execution produces a healthy dashboard and an unchanged production plan.
- Validation compounds. Across the PlantOS™ install base, up to 99 % of prescriptions are acted upon, contributing to 167,837 hours of unplanned downtime saved.
The contract was written against production outcomes.
The review is being run against platform activity.
The five levels, and where most estates stop
Industrial monitoring gets bought in layers, usually over a decade and usually from different vendors. Each layer solves a real problem and each one leaves the same job unfinished.
The five levels of industrial monitoring. Levels one to four describe the machine. Only level five closes a job on the floor and records what it returned.
| Level | What it delivers | Who turns it into action | Where it stops | Priced on |
|---|---|---|---|---|
| 1Sensor data | Raw vibration and temperature plots | Your reliability engineer | A data file | Sensors purchased |
| 2Dashboard visualisation | Trends charted on a screen | Your reliability engineer | A screen to watch | Users or tags |
| 3Integrated monitoring | One view across assets and sites | Your engineer, plus analysts | A consolidated view | Assets connected |
| 4Predictive analytics | Anomaly detection and generic guidance | Your team, still interpreting | An alert to interpret | Assets monitored |
|
The outcome gap
Everything above describes the machine. None of it closes a job on the floor.
|
||||
| 5Production Outcomes as a Service | A named fault, its cause and the fix | Issued as a prescription, validated by the plant | A closed job and a recorded outcome | Production outcomes achieved |
Levels one to four are not failures. A plant at level four has genuine capability, and it detects degradation earlier than a plant at level two. What it does not have is a mechanism that converts detection into a completed repair and a measured production result. That conversion is the outcome gap.
Closing it takes three things. First, the fault gets named with its cause rather than described as a symptom. Then the job is ranked by what stopping that asset costs in production. Finally, the work closes on the floor with a signoff recording what was actually found.
An outcome-based subscription puts all three under one contract, with the provider measured on whether they happen. The six requirements below decide whether that works in practice.
REQUIREMENT 01
The outcome is written in production units before anything is installed
A subscription that promises improved reliability has promised nothing measurable. A subscription that promises a reduction in unplanned downtime hours on Line 3, measured against the trailing twelve months, has created something both parties can audit at any point.
Platform metrics
What a level-four review reports-
Prediction accuracy
-
Sensor uptime
-
Alerts raised
-
Assets monitored
-
Dashboard logins
Production units
What the contract should be written in-
Unplanned downtime hours avoided
-
Throughput on a defined line
-
Maintenance cost movement
-
Cost per tonne
-
Prescriptions closed on the floor
REQUIREMENT 02
The baseline is agreed while it is still uncomfortable to agree it
Baselines are easy to set before go-live and nearly impossible to set afterwards. Once prescriptions are flowing and hours are being saved, every historical figure becomes contested, and the value delivered turns into a negotiation rather than a record.
A workable baseline needs a defined period, usually the trailing twelve months, a defined source such as the CMMS breakdown log or the production stoppage register, and a named owner on the plant side who signs that the number is correct. Plants that skip this step often deliver strong results and still cannot prove them, which is a harder problem to fix than underperformance.
Where historical logging is thin, agree a short instrumented baseline window rather than reconstructing one. Two months of clean measurement outperforms two years of inconsistent records.
REQUIREMENT 03
The scope reaches past the critical few
Most subscriptions open on a shortlist of critical rotating assets, which is sensible for a proof phase and limiting as a permanent boundary. Recurring stoppages in a heavy plant rarely sit only on the twelve assets everyone already watches. They accumulate across balance of plant equipment, on the pumps, fans, blowers, compressors, conveyors and gearboxes excluded because each one individually looked too small to instrument.
Coverage is what converts a pilot into a plant-level outcome. Infinite Uptime’s PlantOS™ addresses this through self-powered wireless sensing that installs without gateways or plant cabling, so extending scope does not require a shutdown or a capex cycle. The commercial consequence matters more than the technical one, since a subscription that can widen its asset base can keep growing its outcome, while a fixed twelve-asset fence cannot.
REQUIREMENT 04
The prescription reaches the floor as an instruction
This is the step that separates level five from level four, and it is more procedural than technical.
A level-four alert says an asset is deviating and attaches a recommendation for someone to interpret. A prescription names the fault and its cause, states the corrective action, carries a severity and urgency rating so it can be ranked against every other open job, and reaches the operator on dashboard, email and mobile. The plant decides when to schedule it, because scheduling belongs to the people who own the production plan. What the platform removes is the interpretation step, not the plant’s authority over its own shutdown windows.
The prescription then closes with a digital signoff recording what was actually performed, with field evidence attached. Track this as action rate, meaning the percentage of issued prescriptions executed on the floor. A platform with high accuracy and a low action rate has an adoption problem rather than a modelling problem, and adoption problems are solved with workflow and governance rather than with better algorithms.
REQUIREMENT 05
Process data is inside the subscription boundary
Vibration data tells you what is happening to the machine. It does not tell you why.
Take a cement kiln main drive. The pinion bearing shows rising acceleration and a clear spectral peak, so the diagnosis is bearing degradation and the corrective action is relubrication. The work gets done and the trend flattens. Six weeks later it climbs again, because the actual driver was a coating buildup in the kiln that shifted load distribution across the girth gear. Vibration described the damage correctly every time. It could not name the operating condition creating the damage, because that condition lives in the process data.
This is the practical ceiling of a vibration-only scope, and it is why level four stops where it does. Mechanical signals are excellent at identifying which component is degrading and how fast. Process signals from the PLC and historian, covering feed rate, temperature profile, load, tension and pressure, are what explain the cause. A fault described by its symptom produces an investigation. A fault explained by its cause produces a corrective action, which is the only version that closes.
REQUIREMENT 06
The operator validates the outcome, and the validation is the deliverable
Every prescription closes with a person on the floor recording what was found and what was done. That closure carries weight in two directions, which is why it belongs at the centre of the contract rather than at the end of the workflow.
On the plant side, it is the proof. An outcome validated and signed by the customer’s own reliability and operations teams survives a budget review in a way that a provider-reported figure never does. It also settles the accuracy question honestly, because the judgement on whether a diagnosis held is made by the people who opened the machine rather than by the model that issued it. Sustaining this needs very little ceremony: a named owner on each side, a weekly touchpoint to clear open prescriptions, a monthly review of action rate and closure time, and a quarterly reconciliation against baseline.
On the model side, that same signoff is training data. When an engineer writes back what was actually found, including detail the platform did not previously hold, that note becomes a labelled outcome drawn from your assets, your operating conditions and your failure history. PlantOS™ formalises this as the 99% Trust Loop: accuracy builds trust, trust drives action, action produces validated feedback, and feedback sharpens the next prescription.
The commercial implication is worth negotiating for. A subscription running on validated feedback is worth more in year three than in year one, which argues for multi-year terms with scope expansion built in rather than annual renewals holding coverage flat.
THE SHAPE OF IT
What the first six months look like
A subscription set up against these requirements follows a recognisable rhythm. Nothing here is exotic, and each stage works because the one before it was defined properly.
ROI reported by a cement producer running Infinite Uptime’s PlantOS™, verified within six months against their own pre-subscription baseline by their reliability and operations teams.
THE PROOF
What level five returns at scale
plants live on PlantOS™
countries
prediction accuracy
downtime hours saved
Up to 99 % of prescriptions are acted upon. Customers report up to 10 % lower maintenance cost and up to 2.5 % higher throughput, with every figure signed off by their own reliability and operations teams. Hindustan Zinc Ltd of Vedanta Group reported over $700K in savings as published by Vedanta Spark, while JSW Steel runs the platform across 139 plants and Coromandel International across 27.
Define the outcome, agree the baseline, and let the first quarter prove it.
Start with your most critical line.
Try PlantOS™Frequently Asked Questions
The provider is measured and paid against a production result rather than against software access, sensor count or reports delivered. Contracted metrics are typically unplanned downtime hours avoided, throughput change on a defined line, maintenance cost movement and cost per tonne. Infinite Uptime markets this model as Production Outcomes as a Service, delivered through Infinite Uptime’s PlantOS™.
Predictive maintenance detects that an asset is degrading and estimates when it may fail. Prescriptive maintenance names the fault and its cause by reading equipment and process data together, states the corrective action, ranks it by production impact, and closes it with an operator signoff. The practical difference is that a prediction still needs interpretation, while a prescription is already an instruction.
Providers fall into four groups: sensor manufacturers selling hardware with an analytics layer, CMMS vendors adding condition modules, general industrial IoT platforms, and vertical prescriptive AI providers that contract against production outcomes. Infinite Uptime sits in the last group, operating PlantOS™ across 1,000 plants in 28 countries with outcomes validated by each customer’s own operations team.
The first fault prescription is typically issued within two weeks of installation, with a structured 90-day path to measurable production outcomes. Three things set that pace: how quickly sensing can be commissioned across the asset scope, how quickly equipment and process data are brought together so faults can be explained rather than only flagged, and whether prescriptions close on the floor once they start arriving. Commissioning needs no shutdown, so the measurement window opens immediately rather than at the next planned outage, and the 90-day checkpoint reconciles hours saved against the baseline agreed at Day 0.
Yes, and brownfield sites often see faster returns because their unplanned stoppage history provides a clear baseline to measure against. Mixed-vintage assets and multi-vendor sensor estates are handled at the analytics layer rather than by standardising hardware, so existing instrumentation does not have to be replaced first.
Heavy continuous-process manufacturing, where an hour of unplanned downtime carries a large production value. PlantOS™ operates across cement, steel, mining, tyre and rubber, chemicals, paper and pulp, food and beverage, pharmaceuticals, and energy. JSW Steel runs the platform across 139 plants and Coromandel International across 27.
Each prescription closes with an operator signoff recording what was performed, with field photographs attached, and states the downtime hours saved on the document itself at the time of closure. Those records reconcile against the pre-agreed baseline, and the customer’s own reliability and operations teams sign off the final figures. Across the install base this has accumulated to 167,837 hours of unplanned downtime saved.

