Most condition monitoring programs stop at the alert. This journal explains how to connect the Decide stage, where an alert becomes a recommended and approved work order, through shared asset data, reliable integrations, and AI that keeps people in control of every maintenance decision.
.jpg)
.jpg)
Condition monitoring is a mature discipline. Sensors, historians, and analytical models can identify a developing bearing fault or a motor running hot weeks before it fails. In many operations, however, the process that follows still depends on a technician reading the alert, opening several systems, and assembling the work by hand.
A connected maintenance workflow closes that gap. It is the combination of data models, integrations, and approval controls that carries an equipment alert from the monitoring platform into the maintenance system as a planned, resourced, and approved work order. This journal explains how that workflow is structured, where established standards apply, and which technical decisions determine whether it holds up in production.
Investment in detection has outpaced investment in execution. A 2026 survey of more than 2,200 maintenance and operations leaders found that most now use AI in some form, yet 79% reported that unplanned downtime held steady or increased over the previous year.
The established standards show where the break occurs. ISO 13374, the reference architecture for machine condition monitoring, defines six processing blocks that end with advisory generation: a recommendation for maintenance action. ISA-95 (IEC 62264) Part 3 defines maintenance operations management, covering maintenance definitions, resources, dispatching, and execution, which a CMMS or EAM system typically handles. Each standard is well understood on its own. The handoff between them, from an advisory to a dispatched work order, is rarely specified, and it is where alerts tend to stall.
A connected maintenance workflow links the two standards through five stages: Sense, Predict, Decide, Human Gate, and Transact. Each stage has a defined function, a corresponding standard reference, and a system of record.
Stage | Function | Standard reference | Typical system |
Sense | Acquire readings, validate quality, and attach asset and operating context | ISO 13374 data acquisition and data manipulation | IIoT platform, edge gateway, historian |
Predict | Detect an abnormal state, assess health, and estimate time to failure | ISO 13374 state detection, health assessment, and prognostic assessment | Analytics and machine learning models |
Decide | Combine procedure, parts, labor, and schedule into a service recommendation | ISO 13374 advisory generation; ISA-95 maintenance definition and resource management | Orchestration layer drawing on CMMS, ERP, and scheduling data |
Human Gate | Review, revise, or approve the recommendation against an authorization policy | Site approval policy | Approval interface |
Transact | Create the work order, reserve parts, and dispatch the job | ISA-95 maintenance dispatching and execution management | CMMS or EAM, ERP |
Why Is the Decide Stage the Key to a Connected Maintenance Workflow?
The Decide stage is the bridge between monitoring and execution. It is also the stage most implementations leave to people, because it requires data from systems that were never designed to share a common view of the asset.
Monitoring platforms handle sensing and prediction, and the CMMS handles execution. The Decide stage usually has no system of its own, so a maintenance technician assembles history, procedure, parts, and schedule by hand. This is where most of the delay between an alert and a repair accumulates.
Connecting this stage does not remove human oversight. A qualified person remains accountable for safety, production impact, and cost, and will continue to approve the work. What changes is what they receive: a complete, verified recommendation to judge, rather than an alert to research.
A connected maintenance workflow requires three shared data structures: a common asset identity, a common failure vocabulary, and a reliable link between assets and their spare parts. Without them, every alert needs manual interpretation before planning can begin.
Asset identity. Each system names equipment differently. Controls engineers identify a motor by its PLC tag path, the CMMS by an equipment number within a functional location, and the ERP by a material and serial number. An asset registry, or a maintained crosswalk between these identifiers, is the first integration dependency. The ISA-95 equipment hierarchy of enterprise, site, area, work center, and work unit provides a neutral reference structure for it. The model should also separate the functional location, meaning the position in the process, from the installed equipment, meaning the physical unit. When a motor is swapped, its condition history and repair history must follow the correct object.
Failure vocabulary. A model that reports "anomaly score 0.87" gives a planner little to act on. Model outputs should be expressed as failure modes drawn from the same code set that technicians use when closing work orders. ISO 14224, developed for the petroleum and gas industries and widely adopted elsewhere, offers a structured taxonomy of failure modes, mechanisms, and causes. A shared vocabulary makes the recommendation readable and makes it possible to compare what the model predicted with what the technician found.
Parts linkage. The equipment bill of materials connects each asset to its compatible spares. An availability check should use unrestricted stock net of open reservations rather than total stock on hand, and it should carry a timestamp so the reviewer knows how current the figure is.
A reliable maintenance workflow treats each alert as an event, tracks it through an explicit lifecycle, and makes every write to a downstream system idempotent. An idempotent write can be sent more than once and still produce a single result. If a request to create a work order is retried after a network timeout, the maintenance system recognizes it and returns the original order rather than creating a second one. This applies to the records the workflow creates, not to the alerts it raises, so an alert can still fire again when it needs to. These patterns prevent the two most common failures: duplicate work orders and requests that disappear between systems.
Explicit lifecycle. Each maintenance request moves through defined states: detected, assessed, recommended, pending approval, approved, work order created, completed, and verified. Every transition is recorded with a timestamp, the actor responsible, and a correlation identifier that follows the request across all connected systems. Planners, operators, and engineers can then see where any request stands without checking each system separately.
Deduplication and idempotency. Condition alerts recur, often every few minutes while a fault develops. A deduplication key built from the asset, the failure mode, and the presence of an open request ensures that new readings update the existing request rather than create a new one. Calls that create work orders or reservations should carry idempotency keys, so a retry after a timeout does not produce a second order.
Alerts that need to fire again, such as those not acknowledged within a set time or where the condition worsens, are handled as escalation rules. The alert re-notifies the responsible people and raises the priority of the existing request, without creating a duplicate. If the condition returns after the work is complete, the workflow opens a new request linked to the previous one.
Reliable publishing and confirmation. A transactional outbox, where the state change and the outgoing event are committed together, prevents a request from being marked approved without the corresponding message ever reaching the CMMS. The integration should treat a transaction as complete only after it reads back the work order number from the receiving system.
Freshness and degraded operation. Every data element in a recommendation should carry its source and retrieval time. If a parts check is older than an agreed threshold when the reviewer approves, the workflow should refresh it before transacting. When a downstream system is unavailable, approved requests should queue with a visible status rather than fail silently.
Different stages call for different kinds of intelligence. Predictive models handle detection and prognosis, language models and agents assemble context and draft recommendations, and deterministic software handles authorization and transactions.
This division is one of the most consequential design decisions in the workflow. Each type of intelligence suits one stage and is a poor fit for the others. Assigning each task correctly keeps errors contained to the stage where they can be caught: a language model never decides whether equipment is failing, and no model holds the authority to commit parts, labor, or spend.
Predict: predictive models. Time-series anomaly detection and classification models evaluate condition data. These models should be validated against historical failures, versioned, and monitored for drift. Their outputs should state the failure mode, the supporting evidence, and a confidence level. They are reliable at recognizing patterns in sensor data, but they cannot interpret a procedure or a technician’s notes.
Decide: language models and agents. A language model or agent is well suited to gathering and summarizing context: the asset’s recent work orders, the applicable procedure, relevant sections of the equipment manual, and candidate parts. This works best when the agent receives a structured context package assembled by the integration layer, instead of searching open-endedly across systems. Solvative refers to this discipline as context engineering.
The agent’s output then passes through validation before any person sees it. Every part number must exist and be compatible according to the bill of materials. The procedure reference must be valid, and the labor craft must exist in the scheduling system. Free text retrieved from manuals and historical work order notes should be treated as untrusted input, since it can carry content that attempts to redirect the model. Recommendations that fail validation are flagged for review rather than corrected silently.
Transact: deterministic software. Deterministic software follows fixed rules and produces the same output for the same input every time, so its behavior can be tested and audited before it goes live. That makes it the right place to enforce approvals and execute work orders and reservations. No model output reaches the maintenance system without passing through it.
AI agents should operate with the minimum permissions required, with authorization enforced by deterministic software outside the model, and with each approval bound to the exact scope that was reviewed.
Enterprise maintenance and ERP platforms increasingly expose interfaces built for AI agents, including servers based on the Model Context Protocol. Rather than granting broad API access, the integration should expose narrow, named tools, such as retrieving asset history, checking part availability, or drafting a work order. Permissions can then be assigned in three tiers: reading records, drafting recommendations and work orders, and executing transactions.
For transactions, the approval service can issue a token bound to a hash of the approved payload: the asset, task list, parts, labor estimate, and schedule window. The transaction tool accepts only a matching token. If the scope, cost, or parts change after approval, the hash no longer matches, and the request returns to review. This enforces the principle that an approval applies to the work that was actually reviewed.
The authorization policy itself should reflect asset criticality and cost. Routine inspections on non-critical equipment may need only a planner's approval, while component replacements on bottleneck assets may require a supervisor. Every step should be written to an audit record that captures the model version, the context provided, the recommendation, the reviewer's decision, any changes, and the resulting work order.
A first implementation should cover one asset class that has adequate sensor coverage, a reliable asset master, and several years of work order history with usable failure codes. A data readiness review comes before any build. It confirms crosswalk coverage between monitoring tags and maintenance records and the quality of historical failure coding, since both directly limit what the workflow can do.
The first release should produce recommendations and draft work orders, with transactions executed only after approval. Expanding to automatic parts reservation, scheduling integration, or supplier and dealer coordination can follow once the team has evidence of performance. Maintenance, operations, and IT should share ownership from the start. Our journal on IT/OT convergence discusses why defined ownership at that boundary matters as much as the architecture.
A baseline should be recorded before launch. The most informative measures are time from alert to approved work order, the rate at which reviewers accept or revise recommendations (with revisions captured as coded reasons), the share of jobs with all parts available at start, repeat work on the same asset, and unplanned downtime for the asset class. Technician completion codes, compared against the predicted failure mode, provide the labeled outcomes needed to evaluate and retrain the models under change control.
Solvative’s Industrial IoT services unify equipment monitoring, systems integration, and maintenance execution. Built on our five-stage Collaborative AI approach: Sense, Predict, Decide, Human Gate, Transact. We combine context engineering for data quality with harness engineering for deterministic controls and human oversight.
We deliver the complete ecosystem: unified asset models, robust CMMS/ERP integrations, planner approval interfaces, and fine-grained agent governance. We also provide long-term operational support to ensure your system performs as reliably in Year 3 as it does on Day 1.
Reach out to our team to see how we can connect your equipment data to your maintenance operations.
