Key Points
- When fully understood, preventive, predictive, and condition-based maintenance are layers within a single program, not alternatives. Each answers a different question, assigned by asset criticality and failure profile.
- Preventive maintenance covers compliance and low-criticality work. It cannot detect degradation between service intervals, which is where critical assets quietly fail.
- Predictive maintenance forecasts when a fault will progress to failure. Condition-based maintenance sees what is happening on the asset right now. They cover complementary positions on the P-F curve.
- Synthesis becomes operational only when condition data, forecasts, and PM schedules reach the same execution layer.
Sit through a maintenance strategy conversation around program design, and the three terms are typically present. They are commonly represented and three approaches to maintenance: preventive, predictive, and condition-based.
If you’re still in the conversation, you’ll see that many teams move in one of two directions. The common path treats these three as alternatives, or three competing programs, where committing to one means setting the others aside. The other path treats them as essentially the same thing, swapping the labels in casual conversation as if the differences were academic.
The problem is that neither of these sees the underlying logic by which they fit together and complement one another. They’re not ‘separate,’ but they're not ‘interchangeable.’
For sure, these three approaches are strategically distinct. Each was developed to solve a different operational problem, and each succeeds where the others structurally cannot.
- Preventive maintenance prevents what schedules can prevent.
- Predictive maintenance forecasts what data can forecast.
- Condition-based maintenance detects what real-time sensing can detect.
Treat any one as a substitute for the others, and you give up the gap coverage that only the missing layer provides. Treat all three as the same thing, and you blur the operational distinctions that determine where each one earns its place.
The synthesis that actually works isn't merging them into a single approach. It's running them as layers, each assigned by asset criticality, each addressing a different position on the failure timeline, each feeding the same execution system, so the team isn't reconciling three versions of the same shift.
Deloitte estimates that unplanned downtime costs industrial manufacturers around $50 billion a year. The share of that figure attributable to a mis-assigned maintenance strategy doesn't appear in any single report. Right now, this only shows up in the form of a difference. A difference between what your maintenance program is and what it could be. Even though hard numbers don’t exist, it’s tangible and squarely impacts the bottom line, as well as whether the maintenance program is framed as an expense or a revenue driver.
This article walks through what each of the three approaches is built to do well, where each one runs out on its own, and what changes when they're treated as layers in one program rather than alternatives on a shelf.
Three layers, one program
Preventive Maintenance and the Calendar Limit
Preventive Maintenance (PM) is scheduled work triggered by time, usage, or meter readings. Service the gearbox every 90 days. Replace the filter every 500 operating hours. Whatever the asset is doing right now does not enter the decision. The calendar drives the work.
The strength of this approach is predictability. Teams know what's coming, plan resources accordingly, stock the parts they'll need, and meet the compliance schedules auditors and insurers expect. For low-criticality assets and known wear patterns, preventive maintenance earns its keep. Time-based maintenance on equipment where failure costs are modest and replacement parts are commodities, is often the most economical strategy a facility can use.
Where PM stops being enough is at the interval itself. A bearing serviced on Tuesday can fail on Thursday because of a contaminated lubricant, a misinstalled seal, or an operational stress the schedule never anticipated. PM has no mechanism to see degradation between service windows. Run that gap across a critical asset, and the failure modes the schedule was supposed to prevent are the ones that take the line down.
There's a second cost most teams don't track, in that every intervention is an exposure. For example, an over-torqued fastener, a contaminated reassembly, a misseated component. PM creates some of the failure modes it exists to prevent, and at scale, the labor spent on assets that didn't need it is labor not spent on the ones that did.
None of that argues against PM. It argues against PM as the only layer.
Predictive Maintenance and the Forecast-to-Action Gap
Predictive Maintenance (PdM) starts from a different question. Not "when is the schedule next" but "when will this asset fail." PdM uses real-time and historical condition data, run through analytics or machine learning models, to forecast how a developing fault will progress toward failure.
The outputs are a failure mode identification, a severity rating, and often a Remaining Useful Life (RUL) estimate. A schedule says "service at 90 days." A PdM forecast says "this bearing has roughly six weeks of usable life remaining at current load and speed."
What that buys is planning room. A forecast with weeks of lead time gives the planner space to schedule the repair into a maintenance window, order the parts ahead of failure, and avoid the cascade costs that follow emergency intervention. It also lets the team intervene precisely, not early.
Where many PdM programs run into trouble is the seam between the forecast and the work itself. The analytics layer can be sound, and the model can correctly identify the fault. Yet the diagnosis still ends up on a dashboard in a different system from where the work order is created, assigned, and tracked. A forecast that doesn't reliably move work is a forecast that doesn't reliably prevent failure.
Many predictive programs that get reported as implemented have failed at exactly this handoff. The model produces the right answer. The execution layer never receives it cleanly. The cost is in the gap between detection and the technician's hands at the point of work.
Condition-Based Maintenance and the Detection-to-Execution Gap
Condition-Based Maintenance (CbM) answers a third question. Not "when is the schedule next," not "when will this asset fail," but "what is this asset doing right now." CbM uses continuous sensor data to track the live state of equipment, triggering action when a measured parameter (vibration, temperature, ultrasound, current draw) crosses a threshold or registers an anomaly that the system has been trained to recognize.
Where CbM earns its place is on short P-F intervals. The P-F curve maps the lead time between when a fault first becomes detectable and when the asset stops doing its job. For failure modes that develop in hours rather than weeks, no periodic inspection route arrives in time. Electrical insulation breakdown on a motor winding. Sudden cavitation on a pump. Continuous monitoring is the only way to catch them while there's still room to act.
The limit of CbM on its own is that it produces alerts, not direction.
A threshold-crossing alert tells the team that something changed. It doesn't say what the failure mode is, how severe it is, how urgent the response needs to be, or what to do about it. Stack enough undifferentiated alerts in front of a maintenance crew, and the response shifts from investigate to ignore. The sensors keep working. The program loses internal sponsorship anyway.
CbM is the detection layer, but it needs the layer above it, forecasting, prioritization, and diagnostic specificity, to convert real-time state changes into action a technician can take.
One Program, Three Layers
The reason these three approaches get framed as alternatives in vendor materials is that they answer different questions about the same asset. The reason they aren't actually alternatives is that the questions stack.
PM is the foundation.
For low-criticality assets, well-characterized wear, and compliance-driven routines, calendar logic is the most economical strategy a plant can run. The schedule remains the right answer for a meaningful share of the asset base, and there's no reliability program in any industry without a PM layer underneath it.
CbM is the detection layer over the critical assets.
The ones where failure costs are high, and the P-F window is too short for periodic inspection. Continuous data is what makes the moment of change visible while there's still time to act.
PdM is the analytical layer over the detection.
It converts raw condition signals into specific failure-mode identifications, severity ratings, and forecasts that tell the team not just what is happening but when it will progress and how urgent the response should be. It's also what makes criticality analysis operational rather than theoretical, because forecast horizons allow planners to trade off response priorities across the asset base in real time.
Where each approach lives on the P-F curve
What the standards already say
The formal industry standard already takes this position. Reliability-Centered Maintenance, as defined in SAE JA1011, treats these as complementary task strategies assigned based on failure consequence and detectability, not as competing programs to choose between.
The U.S. Department of Energy's O&M Best Practices Guide explicitly identifies reliability-centered O&M as the strategic combination of reactive, preventive, and predictive approaches. The synthesis frame the article is arguing for is the position that the standard already holds.
In practice, synthesis requires that condition data, forecasts, and PM schedules reach the same execution layer where work orders are created and tracked. Without that, the three approaches generate three parallel streams of information, leaving the team to reconcile versions of the same shift across systems that don't talk to each other. The layering is a design idea until the infrastructure makes it operational.
How Tractian Delivers the Synthesis
Tractian combines real-time condition sensing, AI-driven diagnostic intelligence, and enriched CMMS capabilities to the maintenance execution platform that a plant already uses. These three layers operate against the same set of asset decisions.
Real-time sensing on critical assets
The Smart Trac sensor captures continuous vibration, ultrasound, temperature, and magnetic field data on rotating assets through a wireless, battery-powered device that installs in minutes. Sub-GHz wireless to a Smart Receiver, 4G/LTE to the cloud, no dependency on plant Wi-Fi.
AI diagnostics that direct, not flood
Tractian's AI-driven diagnostic intelligence converts raw sensor data into specific fault identifications, severity ratings, and prescriptive next steps. The model is trained on more than 3.5 billion samples and covers all major failure modes, with criticality-based prioritization built into the alert logic, so the team gets directed rather than flooded with vague, uninterpreted threshold alerts.
Execution that enriches what's already there
Tractian doesn't displace the preventive maintenance schedules and work order workflows already in place. The intelligence layer sits between sensing and execution, feeding condition-validated diagnostics and prescriptive actions into whichever system the plant already runs. Any maintenance execution platform can receive data via an open API, a native SQL connector, or a pre-built integration.
PM workflows continue to run on the schedule that best fits the asset base. Work orders for critical assets are enriched with real-time condition data, so the schedule reflects what the asset is actually doing rather than what the calendar assumed.
Completed work feeds back into the diagnostic model through a human-in-the-loop mechanism. When a technician verifies a fix and the vibration signature returns to baseline, that outcome refines future diagnostics for that asset and similar equipment across the facility.
Learn more about Tractian's intelligence layer for preventive, predictive, and condition-based maintenance to see how high-quality, decision-grade IoT data transforms your program into AI-powered closed-loop workflows.
FAQs about Preventive, Predictive, and Condition-Based Maintenance
Is condition-based maintenance the same as predictive maintenance?
No. Condition-based maintenance detects what is happening on the asset right now using real-time sensor data. Predictive maintenance uses that data, along with historical patterns and analytical models, to forecast when a developing fault will progress to failure. The two answer different questions, and most mature reliability programs use them together.
Do I have to choose one of the three approaches for my facility?
No, and choosing one is usually the wrong move. The three are layers of a single program, assigned by asset criticality and failure profile. Most facilities perform preventive maintenance on a large share of assets, condition-based monitoring on the critical ones, and predictive analytics on the data both produce.
Can I add predictive and condition-based capabilities without replacing my existing CMMS?
Yes. The intelligence layer can sit between sensing and execution, feeding condition-validated diagnostics into whichever maintenance execution platform is already in place via an open API, a native SQL connection, or a pre-built integration. Existing workflows stay intact.
Which assets should move first from preventive to condition-based or predictive maintenance?
Critical assets with detectable failure modes, costly consequences of failure, and P-F intervals long enough for the team to act on the warning. Lower-criticality assets are often better served by preventive schedules or run-to-failure, depending on replacement cost and lead time.
What ROI evidence supports moving beyond preventive maintenance alone?
The U.S. Department of Energy's O&M Best Practices Guide documents 8 to 12 percent maintenance cost savings when adding predictive capabilities to a preventive program, with higher returns when reactive work is being displaced.
