Analytics choice

SyncAI uses optional analytics and advertising measurement only after you allow it. Necessary site functions work without these trackers. Privacy details

Back to Insights
Reliability Engineering

Evidence Lineage Is Not Optional

A haul-fleet planner ranks a truck for deferral. A superintendent gets a pump family tagged “bad actor.” A reliability engineer is handed PM intervals the model wants to stretch. The dashboard is confident. The record behind it is not.

The score is not the decision. The chart is not the proof. And a recommendation that cannot show which asset configuration, which failure and maintenance records, and which human judgment produced it is not an industrial decision. It is a claim with the trail missing.

Petroleum, petrochemical, and natural-gas reliability practice has required reconstructable data for years. Mining inherited the same problem even where the plant never named the standards: work history, condition data, and inspection live in different systems, and the argument that connects them to the next authorized action is lost at the shift change.

What the public standards already require

ISO 14224:2016, Petroleum, petrochemical and natural gas industries — Collection and exchange of reliability and maintenance data for equipment, is the current international edition (third edition, 15 September 2016; ISO/TC 67). The official scope is public: a reliability language for collecting and exchanging reliability and maintenance data during the operational life of equipment, including data-quality control and assurance practices.

The minimum data it asks for is not a vibe. Three categories:

  • Equipment data — taxonomy and attributes, including a defined equipment boundary
  • Failure data — failure cause and failure consequence
  • Maintenance data — the maintenance action, resources used, maintenance consequence, and downtime

Those categories exist because reliability, availability, maintenance planning, and safety or environmental analysis need a shared object. ISO 14224 does not collect direct cost data and does not prescribe the analysis method. It is a data standard, not a decision engine. Without a common record of what failed, on which item, under what boundary, and what maintenance was actually done, later analysis is theatre.

SAE JA1011 makes the same demand from the RCM side. SAE International revised Evaluation Criteria for Reliability-Centered Maintenance (RCM) Processes as JA1011_202411 on 5 November 2024 (DOI 10.4271/JA1011_202411). Failure effects have to describe what would happen if no task were done to anticipate, prevent, or detect the failure, including what evidence, if any, that the failure has occurred. Hidden functions are separated from evident ones; safety and environmental consequences from economic ones. The analysis and the failure-management policy have to be documented in a form the asset owner or user can accept.

API Recommended Practice 580, Risk-Based Inspection, makes reconstructability a program requirement. In the fourth edition, required data shall be captured and maintained so an RBI assessment can be recreated or updated later by people who were not on the original team. Inputs and assumptions are to be validated by qualified personnel. A ranking that cannot be rebuilt is not an RBI program. It is a snapshot.

None of those documents is a SyncAI certification. They are the industrial rule: if a later reviewer cannot reconstruct what was believed, the organization does not have a decision record.

Lineage is not a data lake

Reliability teams already have data: historians, CMMS work orders, inspection reports, OEM manuals, contractor RCAs. What they often do not have is lineage — a durable chain from a named asset configuration through observed evidence to a recommendation, a named human authorization, and a verification signal.

Lineage answers questions a warehouse does not:

  • Which equipment unit, at which indenture, inside which boundary?
  • Were failure cause, mechanism, and mode kept distinct, as ISO 14224 requires of a reliability language?
  • Was the failure hidden until demand, or evident to operations?
  • Which records were observed, which were assumed, and which were missing?
  • Who accepted the recommended action, and under what operating boundary?

A data lake can store the files. It cannot, by itself, keep those distinctions. Merging tags without a boundary definition is how two pumps become one “bad actor.” Collapsing cause into mode is how a lubrication problem becomes a bearing code. Dropping the detection method is how a hidden protective function is treated as if it had been watched continuously.

ISO 14224 names the failure that is not immediately evident to operations and maintenance personnel as a hidden failure. Those failures are first revealed when the function is tested or demanded. If the record does not say how the failure was detected, a model will treat a test finding and a running failure as the same event. The recommendation that follows will look precise and be unaccountable.

Dashboards classify. They do not reconstruct.

A ranked list is a classification. At best it is a consistent ordering of risk or remaining life. At worst it is the fastest way to fill a morning meeting. Either way, the list answers a different question than the plant has to answer.

The list asks: How do we sequence attention?

The plant asks: What are we allowed to change, on what evidence, and who is accountable if the evidence was wrong?

Those questions diverge under production pressure. Stretching a PM interval or extending an inspection can be the right call. It can also be a call made on a rescaled historian tag, a work history that does not share the current asset configuration, or an inspection technique that cannot detect the damage mechanism in play. API RP 580 requires that inspection effectiveness be evaluated against the identified mechanism. A dashboard that cannot show that evaluation is not doing RBI. It is sorting.

If the record does not separate observed evidence from hypothesis, the rank is a story the system will treat as fact. More sensors increase the volume of the archive. They do not add a governor. Nobody is forced to say what is proven, what is assumed, and what is still missing before the next action is approved.

Recommend ≠ authorize

The gap gets wider when analysis is fast. A reliability engineer, a contractor, or a model can draft a recommendation in minutes. Drafting is cheap. Authorization is not — not on a haul fleet, a processing plant, or any asset whose failure has safety, environmental, or production consequence.

Recommend ≠ authorize. A recommendation is an argument. Authorization is an act by a person who can be named.

SAE JA1011 already treats the documented analysis as something the asset owner or user must be able to accept. That is an accountability design, not a user-interface pattern. If the system cannot show who accepted, rejected, escalated, or returned the recommended action, the organization has a suggestion trail, not a governed decision.

Unsupervised plant execute is the wrong default for the same reason. Writing a recommendation into a CMMS or a control-system workflow is not being allowed to change the plant. A tool that blurs recommend and authorize will look efficient in a demo and unaccountable on the night shift.

A practical test for evidence lineage

A useful test for any mining, energy, or oil-and-gas reliability workflow — CMMS module, RCM workbook, RBI tool, or model output — is whether a later reviewer can reconstruct the recommendation without calling the original engineer.

If the record cannot answer these, lineage is still missing

  • 1Which equipment unit, taxonomy level, and boundary was this about?
  • 2Which failure and maintenance records were used — cause, mechanism, mode, detection method, and downtime kept distinct?
  • 3What was observed versus hypothesized, and what was missing?
  • 4What action was recommended, and what was actually authorized?
  • 5Who approved it, and under what operating boundary?
  • 6What verification would show the action worked — and was it checked?

Those questions do not require a new standard. They are ISO 14224 data discipline, SAE JA1011 acceptance discipline, and API RP 580 reconstructability applied to the object plants already have. The missing piece is usually not another dashboard tile. It is a decision record that can carry evidence grade, approval state, and verification across shifts and systems of record.

When that record exists, ranks become inputs instead of conclusions. Work orders become the authorized work, not the argument. A Reliability Assessment that cannot support a conclusion says so, instead of decorating a gap. How SyncAI treats that difference is a product choice: recommend from approved evidence; a named human decides.

What this article is not claiming

This is an educational argument about common reliability-data practice, not a customer case study. It does not report named plants, testimonials, or savings percentages. It does not treat a recommendation engine as live plant execution. Direct plant execute is not a capability being marketed here. Self-guided onboarding is not claimed as a live product path.

The public sources are ISO 14224:2016 (ISO/TC 67; current international edition for RM data collection and exchange in petroleum, petrochemical, and natural-gas operations), SAE JA1011_202411 (RCM evaluation criteria, revised 5 November 2024), and API RP 580 documentation practice for risk-based inspection (reconstructability of the assessment by people who were not on the original team). They are cited as reliability-program context, not as SyncAI certifications.

Bring a real reliability question

If you want to see how a decision record keeps evidence, hypothesis, and named human approval distinct, start in the Reliability Engineer workspace or request a Reliability Assessment. A bounded Strategic Pilot is the path when a specific workflow is ready to be operationalized with verification.