Reliability evidence
How to assess maintenance records before reliability review
Reliability measures are only as defensible as the records beneath them. Start by checking the authorised scope and the completeness of its inputs.
A chart can look precise even when the records underneath it are incomplete. Before comparing assets, crews or periods, reliability reviewers need to understand the authorised scope, the definitions being used and the gaps in the source work.
Start with the question and the authorised scope
Define the site, fleet, asset class, period and event types being reviewed. Confirm who is authorised to see the source records and whether every selected record belongs to the same organisation boundary.
A result based on one fault record should not be presented as a fleet trend. The interface should make the selected scope and record count visible.
Check asset identity and time markers
Asset identifiers must be stable enough to connect faults, work and handovers to the correct machine. The review also needs consistent event times for reporting, work commencement, blocks, handovers, verification and closeout where those events are available.
If downtime or meter coverage is required for a measure, confirm that the relevant values exist and use an agreed definition. Do not infer availability, MTBF or MTTR from records that do not contain the required inputs.
Review the fault and work trail
A useful source record includes the reported symptom, operating context, completed checks, findings, evidence, parts activity, ownership changes and the final recorded outcome. The reviewer should be able to drill from an aggregate or comparison back to those events.
Free text can add context, but consistent identifiers and event types are what make multiple records comparable without stripping away their source.
Separate recorded facts from derived measures
A fault opening, a field note and a handover are recorded events. A repeat fault grouping or a performance measure is derived from selected records. The review should keep that distinction visible and state the rules applied to the derived result.
Where a comparison cannot be supported, an honest no data state is more useful than a fabricated baseline.
Preserve drill back in every output
A management summary, PDF or CSV should state its scope and provenance. Authorised users should be able to trace material results back to the underlying asset and fault records rather than receiving an isolated number with no operating context.
FaultPilot's reliability and export model is designed around that record drill back. The operations console carries the same identity and the system boundary explains where exported records sit beside the existing maintenance system.
Review the reliability evidence model →