Maximo Health 9.0.20 and Condition Insight: From FMEA Spreadsheet to 30-Second Asset Briefing in 90 Days
A practical 90-day rollout playbook for Maximo Health 9.0.20 + Condition Insight at a brownfield site, with concrete health contributor formulas, condition insight prompt patterns, the IoT-to-Monitor wiring, and the data quality gates that prevent garbage-in-garbage-out.
Most reliability programs at industrial sites are not starting from zero. They are starting from somewhere worse than zero: a pile of FMEA spreadsheets from 2018 that have not been updated, a reliability engineer's notebook with handwritten failure mode observations, and a Maximo Manage instance with 30,000 assets where the health score field is either null or stuck at 100. The 90-day rollout of Maximo Health 9.0.20 with the new Condition Insight capability is the playbook that moves the program from that starting state to a state where a planner can ask "what is the health of pump P-104?" and get a defensible answer in under 30 seconds. The playbook is not theoretical. It is the result of three brownfield deployments between November 2025 and May 2026, at sites with 8,000 to 42,000 assets, mixed IoT and manual data sources, and reliability programs ranging from "informal" to "RCM-certified but not data-driven."
This article walks the playbook with the precision a senior reliability engineer needs: the health contributor scoring math, the condition insight prompt patterns, the IoT-to-Monitor-to-Health data flow, the data quality gates that prevent garbage-in-garbage-out, and the change management pattern that gets the operations team to actually use the health scores.
Why Maximo Health 9.0.20 and Why Now
Maximo Health 9.0.20 was released on May 27, 2026 (Reference # 7274026). The release is significant for two reasons that are independent of each other. The first is that Health is now bundled with the Condition Insight capability as a single MAS 9.1 managed component, replacing the standalone Condition Insight package that was available as a separate install in earlier versions. The second is that Health now uses the AI Service for the Condition Insight feature, which means the underlying language model and reasoning engine is the same one that powers the Maximo AI Assistant. The integration is not superficial. The Condition Insight feature shares the AI Service's prompt context, its tool-use capabilities, and its evaluation pipeline.
The practical implication is that a site deploying Maximo Health for the first time in 9.0.20 gets Condition Insight as a feature rather than as a separate deployment. The deployment surface is simpler (one component instead of two), the licensing is consolidated (the AI Service AppPoints cover both), and the operational footprint is smaller (one AI Service deployment instead of two).
The Condition Insight feature itself is what the industry has been waiting for since the original Maximo Health launch. In the pre-Condition Insight architecture, the health score was a number between 0 and 100 that a planner had to interpret manually. The planner would see "Health: 62" and have to dig into the contributor breakdown to understand why. In the Condition Insight architecture, the planner asks "why is pump P-104 at health 62?" and the AI Service generates a 3-5 sentence natural language briefing that explains the contributors, the recent trend, the failure modes that are most likely, and the recommended next actions. The briefing is grounded in the health contributor data, the work order history, and the reliability strategies attached to the asset. The briefing is not generated by a generic language model; it is generated by a model that has been fine-tuned on the asset's specific contributor structure.
The Health Score Math
The Maximo Health score is a weighted average of health contributors. Each contributor is a metric that is scored on a 0-100 scale, where 100 means "fully healthy" and 0 means "completely failed." The contributor weights are configured per asset class or per asset, with the weights summing to 100. The health score is the weighted average of the contributors, recomputed on a configurable schedule (typically hourly for IoT-driven contributors, daily for manually-updated contributors).
The contributor types that are most useful in a brownfield deployment are:
Condition contributor. Derived from IoT sensor data, vibration analysis, oil analysis, thermography, or ultrasonic readings. The score is computed from the deviation of the latest reading from the expected baseline. The baseline is either a static threshold or a dynamic baseline computed from the asset's historical readings.
Work history contributor. Derived from the work order history. The score is computed from the failure frequency, the mean time between failures (MTBF), and the mean time to repair (MTTR). The score drops when failures are more frequent than expected and rises when the asset is operating without failures.
Reliability strategy contributor. Derived from the reliability strategies (PMs, PdMs, condition-based tasks) attached to the asset. The score is computed from the coverage of the failure modes identified in the FMEA: each failure mode that has a corresponding reliability strategy contributes positively, each failure mode that is uncovered contributes negatively.
Inspection contributor. Derived from inspection results. The score is computed from the percentage of inspections that pass without findings, weighted by the criticality of the inspection.
Meter contributor. Derived from the asset's meter readings. The score is computed from the deviation of the latest reading from the expected trajectory. For a meter-based PM, the meter reading drives the PM generation, and the meter contributor in the health score mirrors the PM trigger logic.
# Health contributor configuration example (asset class level)
# Deployed via Manage > Health > Contributor Templates
contributor_templates:
- name: "PUMP_CENTRIFUGAL_VIBRATION"
type: CONDITION
metric_source: "iot://device/P-104/vibration_rms"
baseline: DYNAMIC
dynamic_window_days: 90
scoring:
green_threshold: 0.0 # baseline or below
yellow_threshold: 1.5 # 1.5x baseline
red_threshold: 2.5 # 2.5x baseline
weight: 30
- name: "PUMP_CENTRIFUGAL_HISTORY"
type: WORK_HISTORY
metric_source: "workorder://asset/P-104/failures/365d"
scoring:
green: failures_per_year <= 1
yellow: failures_per_year <= 3
red: failures_per_year > 3
weight: 25
- name: "PUMP_CENTRIFUGAL_RCM"
type: RELIABILITY_STRATEGY
metric_source: "fmea://asset/P-104/coverage"
scoring:
green: coverage_percent >= 90
yellow: coverage_percent >= 70
red: coverage_percent < 70
weight: 25
- name: "PUMP_CENTRIFUGAL_INSPECTION"
type: INSPECTION
metric_source: "inspection://asset/P-104/pass_rate/180d"
scoring:
green: pass_rate >= 95
yellow: pass_rate >= 80
red: pass_rate < 80
weight: 20
The contributor configuration above is for a centrifugal pump, with four contributors summing to 100 weight. The vibration contributor (weight 30) is derived from IoT data, with dynamic baseline and standard 1.5x/2.5x thresholds for yellow/red. The work history contributor (weight 25) is derived from the work order history, with green being less than or equal to one failure per year. The RCM contributor (weight 25) is derived from the FMEA coverage, with green being greater than or equal to 90% coverage. The inspection contributor (weight 20) is derived from the inspection pass rate.
The 90-Day Rollout
The 90-day rollout is divided into three phases, each 30 days. The phases are designed to deliver value incrementally, with the value compounding across the phases.
Phase 1 (Days 1-30): Data quality and contributor wiring. The first 30 days are spent on data quality, not on the health score itself. The deliverables are: (1) a complete asset-to-asset-class mapping for the assets that will be in scope (typically 500-2,000 assets, the critical asset subset), (2) the contributor configuration for each asset class, (3) the IoT-to-Monitor wiring for the assets that have IoT data, (4) the reliability strategies attached to the assets that are RCM-defined, and (5) the inspection forms configured for the inspection-driven contributors.
The data quality gate at the end of Phase 1 is that every asset in scope has at least two contributors configured (one condition or meter contributor, one work history or inspection contributor) and that the contributor data is flowing. The health score itself is not yet accurate; what matters is that the contributor data is arriving.
Phase 2 (Days 31-60): Health score calibration. The second 30 days are spent on calibrating the health score. The deliverables are: (1) the contributor scoring thresholds tuned to the asset class, (2) the weight distribution adjusted to reflect the operational priorities, (3) the health score recomputation schedule configured, and (4) the planner-facing dashboard configured to show the health score and the contributor breakdown.
The data quality gate at the end of Phase 2 is that the health score is recomputing on schedule and that the score distribution across the asset population is bimodal (a clear cluster of healthy assets and a clear cluster of unhealthy assets, with few assets in the middle). A flat distribution (most assets at 50) indicates that the contributor thresholds are not differentiating between healthy and unhealthy assets.
Phase 3 (Days 61-90): Condition Insight rollout. The third 30 days are spent on rolling out the Condition Insight feature. The deliverables are: (1) the AI Service configured for the Maximo Health integration, (2) the Condition Insight prompt patterns tuned for the asset classes, (3) the planner training delivered, and (4) the feedback loop established for planners to flag briefings that are inaccurate.
The data quality gate at the end of Phase 3 is that planners are using the Condition Insight briefings as part of their daily planning workflow and that the briefings are rated as accurate or mostly accurate by the planners in greater than 70% of cases. Below 70%, the prompt patterns need further tuning; above 90%, the rollout is complete.
The IoT-to-Monitor-to-Health Data Flow
The data flow that brings IoT data into the health score is the part of the architecture that most teams underestimate. The pattern is:
- The IoT device publishes data to a broker (typically MQTT for new deployments, Modbus or OPC-UA for legacy deployments).
- Maximo Monitor subscribes to the broker and ingests the data into the Monitor time-series store.
- A Monitor processing rule (or a Monitor data pipeline) computes the rolling statistics (mean, standard deviation, RMS, peak-to-peak) over a configurable window.
- The rolling statistics are exposed as Monitor API endpoints.
- A Maximo Health cron task (or the real-time contributor evaluation) calls the Monitor API and updates the contributor value.
- The health score recomputation evaluates the contributor against the configured thresholds and updates the health score.
The latency target for the entire flow is 5-10 minutes for IoT-driven contributors. Latency above 15 minutes means the health score is operating on stale data, which means the planner is acting on a briefing that is 15 minutes out of date. For most operations, 5-10 minutes is acceptable. For operations where a rapid degradation can lead to a safety incident (high-speed rotating equipment, high-pressure systems), the target should be sub-minute, which requires a different architecture (direct IoT-to-Health without the Monitor intermediate layer).
# Monitor processing rule for vibration RMS computation
# Deployed via Monitor > Processing Rules
processing_rule:
name: "VIBRATION_RMS_5MIN"
source:
device_type: "VIBRATION_SENSOR"
metric: "acceleration_rms_g"
computation:
type: RMS
window: 5m
output_metric: "vibration_rms_5min"
destination:
api_endpoint: "/api/v2/datalake/data"
cache_ttl: 60s
The processing rule above computes the 5-minute rolling RMS of the vibration sensor's acceleration reading. The output is exposed via the datalake API, which is the endpoint that the Health contributor configuration references. The cache TTL is 60 seconds, which means the Health contributor evaluation sees a value that is at most 60 seconds old. Combined with the 5-minute rolling window, the worst-case staleness in the health score is 5 minutes 60 seconds.
The Condition Insight Prompt Pattern
The Condition Insight feature uses a prompt pattern that is tuned to the asset's contributor structure. The prompt is constructed dynamically based on the asset's contributor configuration and the contributor values. The prompt includes: the asset's identifier and class, the contributor values and weights, the recent work order history, the attached reliability strategies, and the recent trend in the health score.
The prompt pattern is not user-editable in the standard deployment. IBM maintains the prompt patterns as part of the AI Service and updates them through the AI Service patch cycle. Site administrators can adjust the tone and the level of detail through the Health configuration UI, but the underlying prompt structure is managed by IBM.
The practical implication for sites deploying Condition Insight is that the quality of the briefings depends primarily on the quality of the contributor data, not on the prompt engineering. A site with well-tuned contributors and a clean asset hierarchy will get accurate briefings out of the box. A site with poorly tuned contributors or a dirty asset hierarchy will get briefings that reflect the data quality issues. The 90-day rollout is designed to address the data quality issues before the Condition Insight feature is enabled.
Practical Implications
For sites considering the move to Maximo Health 9.0.20 with Condition Insight, the 90-day rollout is the recommended pattern. Sites that try to enable Health and Condition Insight simultaneously at the start of the deployment typically see the Condition Insight briefings flag the same data quality issues that the rollout should have addressed, which undermines planner confidence in the feature.
For sites already operating Maximo Health without Condition Insight, the upgrade path is straightforward: upgrade to Health 9.0.20, configure the AI Service integration, enable Condition Insight, and tune the prompt patterns. The upgrade does not require a re-deployment of the contributor configuration.
For sites operating Maximo Health with the legacy standalone Condition Insight package, the upgrade path involves uninstalling the standalone package and migrating to the integrated package. The migration is a one-time operation that requires a maintenance window.
The change management pattern that has worked at the three brownfield deployments is to start with a single asset class (typically the most critical, like rotating equipment in a power plant or pumps in a water utility), get the planners using the health score for that asset class, then expand to the next asset class. Sites that try to roll out to all asset classes simultaneously typically see planner adoption stall at 20-30% because the planners cannot learn the patterns at scale.
Bottom Line
Maximo Health 9.0.20 with Condition Insight is the most consequential reliability capability IBM has shipped since the original Health launch. The 90-day rollout playbook is the pattern that has worked at three brownfield deployments, and it is the pattern that we recommend for sites approaching the deployment.
The underlying principle is that the data quality gates come first, the health score calibration comes second, and the Condition Insight rollout comes third. Sites that follow this sequence get accurate briefings, planner adoption, and measurable improvement in the planner's ability to prioritize work. Sites that try to skip the sequence get inaccurate briefings, planner rejection, and a reliability program that is harder to resurrect than it would have been to deploy correctly the first time.
For sites planning the second half of 2026, the recommended sequence is: start the 90-day rollout in July, complete the rollout by the end of September, and use the Q4 window to expand the rollout to the next asset class. Sites that follow this timeline will have a fully operational Condition Insight capability by year-end and will be positioned to take advantage of the next AI Service capability when it ships in 2027.
