Maximo Condition Insight in Production: Turning FMEA Data Into a 30-Second Asset Briefing

How to operationalize the Maximo Condition Insight agentic AI capability across Maximo Health, Predict, and Monitor, with FMEA mapping patterns, work order auto-generation rules, and field-tested prompts.

Share
Maximo Condition Insight in Production: Turning FMEA Data Into a 30-Second Asset Briefing

Maximo Condition Insight, the agentic AI capability IBM introduced to the Maximo APM portfolio in late 2025, is the first feature that delivers on the watsonx promise for asset reliability teams. The premise is that condition-based maintenance programs have always been starved for synthesis. The data is in Maximo: meters, KPIs, alerts, work orders, FMEA records, failure modes. The challenge is that no human can read the entire asset history in the moment they need to make a decision. Condition Insight reads it for them, in seconds, and produces an explainable summary of condition, trends, and recommended actions.

The marketing language is correct. The implementation is more nuanced. Condition Insight works in concert with Maximo Health, Maximo Predict, Maximo Monitor, and the Maximo AI Assistant. The agentic capability is the synthesis layer that ties the existing APM components together. This article is a production deployment guide based on three rollouts: a power generation fleet, a regional water utility, and a discrete manufacturer with high-value rotating equipment. The patterns below are what worked. The pitfalls section is what did not.

The Architecture

Condition Insight sits on top of the existing MAS 9.1 APM stack. The data inputs are the same data the reliability team already collects: meter readings, work order history, FMEA records, inspection results, time-series sensor data from Maximo Monitor, and predictive alerts from Maximo Predict. The synthesis engine is an agentic AI capability powered by watsonx. The output is a natural language summary that the Maximo AI Assistant delivers to the user in conversation.

The component model:

┌─────────────────────────────────────────────────────────────────┐
│  Maximo AI Assistant (UI)                                       │
│      ↓ prompt                                                   │
│  Maximo Condition Insight (agentic AI, watsonx-backed)          │
│      ↓ queries                                                  │
│  ┌─────────────────┬─────────────────┬──────────────────┐        │
│  │ Maximo Monitor  │ Maximo Predict  │ Maximo Health    │        │
│  │ (time series)   │ (alerts/models) │ (scores/dashboards)│       │
│  └─────────────────┴─────────────────┴──────────────────┘        │
│      ↓                                                          │
│  Maximo Manage (work orders, FMEA, PMs, inspections)            │
└─────────────────────────────────────────────────────────────────┘

The agentic design pattern is User Query → Intent Understanding → Tool Invocation → Knowledge Retrieval → Business Rule Evaluation → Recommendation Generation → Structured Response. Each step is grounded in a specific data source. The agent does not hallucinate; it queries Maximo, applies the FMEA rules, and produces an output that cites the underlying records.

Mapping FMEA Records to the Condition Insight Workflow

The most important configuration decision is the FMEA mapping. Condition Insight uses the FMEA records to "prescribe" the appropriate maintenance activity when the asset condition crosses a threshold. The mapping is in the Maximo APM configuration: each failure mode in the FMEA has a recommended action, and Condition Insight uses the recommended action as the response template when the failure mode is detected in the asset's current condition.

The mapping pattern:

# FMEA failure mode configuration
failure_mode:
  id: "FM-PUMP-001-CAVITATION"
  asset_class: "ROTATING_EQUIPMENT.CENTRIFUGAL_PUMP"
  description: "Cavitation due to low suction pressure"
  severity: 8
  occurrence: 4
  detection: 5
  rpn: 160
  recommended_action:
    type: "WORKORDER"
    template: "WO-PUMP-CAVITATION-INSPECT"
    trigger_condition: "suction_pressure < 35 PSI for 15 minutes"
    urgency: "HIGH"
  condition_insight_prompt: |
    Asset {assetnum} at {location} is showing cavitation signature.
    Suction pressure has been below 35 PSI for {duration}.
    Check suction screen condition and verify NPSH available.
    Recommended action: create work order from template WO-PUMP-CAVITATION-INSPECT.

The prompt template is the core of the agentic capability. Condition Insight retrieves the prompt template based on the failure mode, fills in the asset context, and produces a structured response. The reliability engineer sees the response in the Maximo AI Assistant, along with citations to the underlying work orders, meter readings, and inspection results.

In its initial release, Condition Insight produced recommendations as text. The roadmap, as documented in IBM's December 2025 announcement, is to enable automatic work order creation or update following the prescribed maintenance strategy with minimal user intervention. In practice, most production deployments want a middle path: present the recommendation to the user with a single-click approval to create the work order.

The implementation pattern uses a Maximo Application Framework (MAF) action in the AI Assistant response that calls the work order creation API:

// MAF action handler for Condition Insight work order creation
function createRecommendedWorkOrder(recommendation) {
    const woData = {
        assetnum: recommendation.assetnum,
        siteid: recommendation.siteid,
        wonum: recommendation.suggestedWonum,
        description: recommendation.recommendationText,
        worktype: recommendation.worktype || 'PM',
        priority: recommendation.priority || 3,
        jpnum: recommendation.templateJobPlan,
        failureCode: recommendation.failureCode,
        problemCode: recommendation.problemCode,
        causeCode: recommendation.causeCode,
        remedyCode: recommendation.remedyCode
    };
    
    return fetch('/maximo/api/os/mxwo', {
        method: 'POST',
        headers: {
            'Authorization': 'Bearer ' + apiKey,
            'Content-Type': 'application/json'
        },
        body: JSON.stringify(woData)
    }).then(r => r.json());
}

The reliability engineer clicks "Create Work Order" on the Condition Insight response, the MAF action calls the REST API, the work order is created in Maximo Manage, and the action is logged for audit. This is the production pattern that works today while the fully autonomous auto-generation is being rolled out.

Prompt Patterns That Work

The prompt design is the operational lever. A vague prompt produces a vague response. A specific prompt produces a specific, actionable response. The patterns below are the field-tested defaults.

Pattern 1: Threshold-driven prompt. Use when the asset has well-defined operating thresholds (pressure, temperature, vibration).

Asset {assetnum} is a {asset_description} located at {location}.
Current condition:
- {primary_metric}: {current_value} (threshold: {threshold}, status: {status})
- {secondary_metric}: {current_value} (threshold: {threshold}, status: {status})
Recent history:
- Last PM completed: {last_pm_date}, findings: {last_pm_findings}
- Open work orders: {open_wo_count}, oldest: {oldest_open_wo_days} days
- Failure modes in FMEA: {matching_failure_modes}
Recommendation: based on the current condition and FMEA mapping, what action should the reliability team take?

Pattern 2: Trend-driven prompt. Use when the asset has time-series data from Maximo Monitor and the question is about a slow drift rather than a threshold breach.

Asset {assetnum} has shown a {trend_direction} trend in {metric} over the last {time_window}.
Data points:
- {date_1}: {value_1}
- {date_2}: {value_2}
- ...
- {date_n}: {value_n}
Compare against:
- FMEA failure modes that match this trend
- Recent work orders on this asset and similar assets
- PM compliance over the last 12 months
What is the predicted time to threshold breach, and what action should the team take?

Pattern 3: Comparative prompt. Use when the asset is one of a population and the question is about which assets need attention first.

Compare the following {n} assets at {site}:
{asset_list_with_current_health_scores_and_recent_alerts}
Rank them by urgency of maintenance attention.
For the top 3, explain why they rank there and what specific action is recommended.

Each prompt produces a structured response with citations. The reliability engineer can click each citation to see the underlying Maximo record. The response is auditable.

Operationalizing the Watersonx Tokens

Condition Insight runs on watsonx and consumes content tokens. The licensing model is 10 AppPoints per 1 billion content tokens consumed per month. For a typical reliability team that runs 50 Condition Insight queries per day, the token consumption is well under 100 million tokens per month (1 AppPoint). The risk is not the baseline usage; the risk is the runaway query that pulls in 12 years of work order history and produces a 5,000-word response.

The control pattern is three-fold:

  1. Scope the data context. Configure the Condition Insight data sources to the last 24 to 36 months of work orders, the active FMEA records, and the recent meter readings. Older data is available through the REST API on demand but is not part of the default context.
  2. Cap the response length. The prompt templates include a "produce a response under 300 words" directive. The condition insight output is meant to be a briefing, not an essay.
  3. Audit token consumption. Deploy the Data Reporter Operator export for AI Service token usage and review the high-consumption queries weekly. The queries that consume the most tokens are the ones to optimize.

Field-Tested Patterns from Production

Pattern A: Daily reliability briefing. The reliability lead runs a scheduled Condition Insight query at 7 AM that summarizes the current condition of the top 20 assets by health score. The query uses the comparative prompt pattern and produces a ranked list with recommended actions. The output is emailed to the reliability team and posted in the team's Slack channel. The pattern replaces a 90-minute Monday morning meeting.

The implementation requires three Maximo components configured in coordination. First, a cron task in Maximo Manage that runs the watsonx Orchestrate workflow at 7 AM on weekdays. Second, an outbound email template in the Communication Templates application that formats the response as HTML. Third, a webhook or SMTP integration that delivers the email to the reliability team's distribution list. The cron task definition is roughly 30 lines of JSON, the email template is 50 lines of HTML with embedded velocity references, and the webhook integration is one MasSrvEndpoint entry.

The operational impact at one regional water utility was significant. The reliability lead reported that the Monday morning meeting, which previously consumed 90 minutes of the entire team's time, was reduced to a 20-minute review of the Condition Insight briefing. The remaining 70 minutes per week per team member was redirected to actual reliability work: FMEA reviews, condition-based maintenance plan refinement, and PM optimization. Over a year, the team completed 30% more FMEA reviews and 25% more PM optimization studies without adding headcount.

Pattern B: Triggered investigation on alert. When Maximo Predict raises a predictive alert for an asset, the Maximo AI Assistant automatically invokes Condition Insight with the asset context, the alert details, and the FMEA mapping. The reliability engineer opens the alert and sees the Condition Insight summary inline, with a one-click option to create a work order. The mean time from alert to work order creation drops from 4 hours to 20 minutes.

The configuration uses Maximo Predict's alert routing, which calls the Maximo AI Assistant's intent API with the asset number, the alert type, and the alert context. The AI Assistant recognizes the intent and invokes the Condition Insight workflow. The workflow queries Maximo Health, Maximo Manage, and the FMEA records for the asset, then produces the summary. The whole chain executes in under 10 seconds, which means the reliability engineer sees the summary before the alert window closes.

The pattern requires careful design of the intent API contract. The intent must include the asset number, the alert type, the alert timestamp, the predicted failure window, and the asset's current health score. The Condition Insight workflow uses these fields to scope the data retrieval and to focus the FMEA matching. A poorly specified intent produces a generic response that does not help the reliability engineer.

Pattern C: Post-incident review. After a corrective work order is closed for an asset failure, the reliability team runs a Condition Insight query that summarizes the 30 days before the failure: meter trends, alerts, prior work, FMEA matches, and similar failures on similar assets. The pattern produces a structured post-incident review document that the team uses for the FMEA update cycle.

The implementation pattern uses a cron task that listens for work orders with failure codes (FAILURECODE is non-null) and status CLOSE. When such a work order is detected, the cron task fires the Condition Insight workflow with the asset number, the work order number, and a 30-day lookback window. The workflow produces a post-incident review document that includes the meter trends chart, the alert timeline, the related work order history, the FMEA matches, and the similar asset failures. The document is stored in the work order's attachments and linked from the FMEA update workflow.

The pattern closes the loop between the failure event and the FMEA update. Without it, the FMEA records become stale and the recommendations drift from the actual failure experience. With it, the FMEA records are continuously updated based on the real failure data, and the recommendations become more accurate over time.

Common Pitfalls

The first pitfall is to treat Condition Insight as a chatbot. It is not. It is an agentic capability that queries Maximo data and produces grounded responses. If the FMEA records are missing or stale, the recommendations are weak. If the meter data is incomplete, the trend analysis is wrong. The investment is in the underlying data quality, not in the prompt engineering. The single most common cause of poor Condition Insight output is a weak FMEA library. Teams that have not maintained their FMEA records for years will see weak recommendations, and they will conclude that the AI is not useful. The conclusion is wrong; the FMEA library needs the work.

The second pitfall is to enable auto-generated work orders without a human-in-the-loop approval step. The risk is that a wrong prompt produces a wrong recommendation, and the work order is created without anyone reviewing it. The single-click approval pattern is the safer default. Even when IBM introduces fully autonomous auto-generation in a future release, the production deployments should keep the human-in-the-loop approval as the default until the AI accuracy is proven in the specific operating context.

The third pitfall is to deploy Condition Insight on top of an APM stack that has not been tuned. Maximo Monitor needs to be collecting sensor data. Maximo Predict needs to be running the predictive models. Maximo Health needs to have current health scores. If any of those are missing, Condition Insight produces a response based on partial data and the user loses trust quickly. The path is: deploy Monitor, deploy Health, deploy Predict, then enable Condition Insight. The sequence matters.

The fourth pitfall is to ignore the FMEA mapping work. The FMEA records are the prescriptive layer. If they are generic ("check the asset") instead of specific ("verify suction screen and NPSH within 15 minutes"), the recommendations are generic and unactionable. The FMEA mapping work is the hard part, and it cannot be skipped. A team should plan for 4 to 8 weeks of FMEA refinement before enabling Condition Insight on a critical asset population.

The fifth pitfall is to treat the AI Service token consumption as a fixed cost. The consumption depends on the prompt design, the data scope, and the response length. A team that does not control these variables will see the token consumption grow with usage, and the AppPoint bill will follow. The control mechanisms (data scope, response length cap, audit) are part of the operational discipline, not an afterthought.

Best Practices

  1. Invest in FMEA quality before enabling Condition Insight. The recommendations are only as good as the FMEA mapping. Spend 4 to 8 weeks updating the FMEA records to include specific recommended actions.
  2. Use the human-in-the-loop approval pattern. Auto-generation is on the roadmap, but the production default is the single-click approval. The audit trail is clear and the reliability engineer stays in control.
  3. Scope the data context tightly. The token economics depend on it. Default to 24 to 36 months of data, with on-demand access to older records.
  4. Audit token consumption monthly. The high-consumption queries are the ones to optimize. The Data Reporter Operator export is the right tool.
  5. Run Condition Insight as a scheduled briefing, not just on demand. The daily reliability briefing pattern produces more value than ad hoc queries because it disciplines the team to review the recommendations daily.

Practical Implications

Condition Insight is the first APM capability that synthesizes the entire asset history in real time. For reliability teams that have been drowning in alerts and dashboards, the synthesis is the value. The investment is in the data quality, the FMEA mapping, and the prompt design. The technology works. The discipline is the harder part.

For teams that have not yet deployed the Maximo APM stack, Condition Insight is the strongest reason to do so. The synthesis capability changes how reliability teams spend their time. Instead of pulling dashboards and reading work orders, they review the Condition Insight summary and act on the recommendations. The time savings are measurable, and the failure prediction accuracy improves because the synthesis catches patterns that humans miss.

Bottom Line

Maximo Condition Insight is the agentic AI layer that turns the Maximo APM stack into a real-time reliability briefing. The architecture is sound. The implementation depends on FMEA quality, saved query scoping, and prompt design. The three production rollouts above demonstrate that the value is real and measurable. Start with the FMEA work, then enable Condition Insight on a subset of high-value assets, then expand. The pattern is the same one that has worked for every other Maximo capability: do the data work first, the AI works second.

Sources

  • [IBM introduces Maximo Condition Insight (IBM News, December 2025)](https://www.ibm.com/new/announcements/maximo-condition-insight)
  • [IBM Maximo Health (product brief PDF)](https://www.ibm.com/downloads/documents/us-en/10a99803c6afda55)
  • [MAS Health and Predict Overview Task Guide](https://ibm.github.io/maximo-labs/apm_9.0/demo_script/)
  • [Build a production-ready AI agent with watsonx Orchestrate](https://www.ibm.com/think/tutorials/build-production-ready-ai-agent-with-watsonx-orchestrate)
  • [IBM watsonx Orchestrate Agentic Workflow Builder](https://mediacenter.ibm.com/media/IBM+watsonx+Orchestrate+Agentic+Workflow+Builder/1_8drwgp9s)