ISO 13374 separates signals from maintenance decisions

A condition pipeline contains different evidence states

The lifecycle associated with ISO 13374-1 moves from acquisition and manipulation of condition data through detection, assessment, prognosis, and presentation. Those stages should remain distinguishable in a maintenance system. A raw observation, derived feature, anomaly, diagnosis, predicted horizon, recommendation, and approved work decision do not carry the same certainty or authority.

Each state needs its source, asset and component identity, timestamp basis, units, transformation, method version, confidence or limitation, responsible actor, and supersession history. When a corrected sensor value changes a later conclusion, the system should preserve the original chain and identify which assessments or decisions require review rather than silently rewriting them.

Data quality precedes diagnostic confidence

A standards-aligned information flow cannot repair missing context, poor placement, drift, aliasing, incorrect units, bad asset mapping, or unavailable operating-state data. Buyers should test how the product detects and communicates those conditions before comparing anomaly or failure-prediction claims. A plausible graph is not proof that the underlying observation is fit for purpose.

A useful demonstration should include a sensor outage, calibration change, asset replacement, operating-regime shift, and corrected metadata. The product should show which downstream calculations are invalidated, how users are notified, and whether historical decisions remain reconstructable. Data-health and model-health indicators should remain separate from asset-health conclusions.

Interoperability is a configured outcome

The ISO record gives teams a structure for software specifications, but a vendor's reference to the standard does not prove that its deployed stack exchanges complete and correctly interpreted information. Protocol support, tag mapping, timestamps, units, semantics, identity, error handling, version compatibility, and round-trip behavior all require tests in the intended environment.

Procurement teams should ask for interface contracts and test cases that cover normal, missing, duplicated, delayed, corrected, and out-of-range data. Evidence should show what was sent, received, transformed, rejected, retried, and acknowledged. A connector list is orientation; it is not a lossless-interoperability or production-readiness verdict.

Maintenance authority remains human and site-specific

Detection and prognosis can support prioritization, but they do not determine whether equipment should continue, slow, stop, be inspected, or be repaired. Safety, process criticality, redundancy, operating context, work controls, parts, labor, and qualified judgment shape that decision. Systems should preserve recommendations as inputs and record the authorized action separately.

Buyers should evaluate decision lineage from condition evidence through risk review, approval, work execution, verification, and learning. They should test false positives, missed detections, late data, and changed models alongside successful cases. ISO 13374-1 can organize the information boundary without certifying diagnostic accuracy or promising reliability outcomes.

Enterprise buyer test

Translate this change into the exact population, record type, workflow stage, decision owner, effective date, and evidence that could be affected. Ask current or prospective providers to demonstrate the named workflow with representative data and an exception—not a polished feature tour. Record what official documentation establishes, what a provider states, what the team observes, and what remains unresolved.

A defensible review also identifies the dependency outside the product. Authority interpretation, policy configuration, data quality, integrations, human judgment, approval rights, release governance, training, and retained evidence may remain customer or service responsibilities. The evaluation should preserve those boundaries instead of treating a technology claim as the complete operating model.

What we will watch next

Maintenance Operations Ledger will watch the named source and affected market records for later evidence that changes status, scope, availability, implementation timing, workflow consequence, or the limits of the initial report. A later announcement does not silently overwrite this dated account; the change ledger preserves the sequence.