When a critical bearing fails — in a marine propulsion system, a railway axle, an industrial gearbox, or a wind turbine drivetrain — the mechanical failure is rarely the most costly part of what follows. The bearing itself is replaceable. The downtime is quantifiable. What is often far more expensive, and far more protracted, is the dispute about why it failed.
In high-value failure scenarios, multiple parties share the loss and the liability: the equipment operator, the bearing manufacturer, the OEM who specified the bearing, the maintenance provider who most recently serviced it, and the insurer who underwrites the risk. Each party has incentives to reconstruct the failure narrative in ways that minimize their exposure. Without an authoritative record of what actually happened at the bearing in the moments before and during failure, these disputes are settled by leverage rather than physics — by which party can sustain the longest legal engagement, not by what the evidence shows.
Why Standard Monitoring Data Is Insufficient
Most installed bearing monitoring systems generate operational data: trend logs, health scores, alarm histories, periodic vibration spectra. This data is genuinely useful for maintenance planning. It is not, in general, useful as forensic evidence in a contested failure investigation, for several reasons.
The Data Resolution Problem
Trend data is averaged and compressed. A daily or hourly health score tells you that something changed, but the raw high-frequency vibration record — the actual physical signal from which defect frequencies are computed — is typically not stored. By the time a failure occurs, the detailed signal that would allow a forensic analyst to determine the fault type, progression rate, and sequence of events has been discarded as part of normal data management.
The Survivability Problem
Industrial data historians and monitoring gateways are not designed to survive catastrophic failures. A bearing failure that takes out a gearbox may also take out the sensor, the local data concentrator, and the power supply for the monitoring system. The standard failure mode is that the most critical data — from the final moments before failure — is precisely what is unavailable because the monitoring infrastructure did not survive the event it was monitoring.
The Integrity Problem
Even when data exists and is accessible, standard monitoring data typically lacks the integrity properties required for adversarial legal use. Anyone with administrative access to a monitoring platform can alter or delete records. The data has no cryptographic signature binding it to the specific sensor at the specific time. An opposing expert can reasonably argue that the data has been selectively presented, manipulated, or is not actually from the sensor claimed. Without a chain of custody that can be independently verified, the data’s evidentiary weight is severely limited.
The Timing Problem
Determining what the bearing was doing before the failure requires data from before the failure. Standard monitoring systems record data in real time and transmit or store it on a continuous basis — but they do not specifically preserve a bounded window of high-resolution data centered on the failure event. Pre-event data may exist in logs, but its relationship to the failure moment is imprecise, and the log entries nearest the failure are often corrupted or missing because the failure disrupted the logging system.
What Forensic-Grade Bearing Failure Evidence Requires
A bearing failure record suitable for legal or insurance purposes needs to satisfy requirements that standard monitoring systems do not address.
Pre-Event and Post-Event Capture Windows
A forensic recorder must continuously buffer high-resolution vibration data and, upon detecting a terminal event (a physical discontinuity consistent with catastrophic bearing failure), preserve a fixed window of data from before and after the event. The pre-event window captures the defect progression leading to failure; the post-event window captures the acoustic and vibration signature of the failure itself. Together, they provide the complete failure chronology.
The pre-event buffer must be stored locally on the sensor — not in a remote data system — because the failure event may disrupt connectivity and power before transmission can occur. Local battery-backed storage with no dependency on external infrastructure is the minimum survivability requirement.
Cryptographic Sealing
Evidence integrity must be provable without requiring trust in the party who preserved it. Cryptographic hashing of the evidence package — SHA-256 or better — produces a fingerprint that changes if any single bit of the evidence is altered. When the evidence is sealed on-device at the moment of capture, before any transmission or human access, the hash can be verified at any subsequent time by any party with a copy of the data. If the hash matches, the data is unaltered.
Sealing must occur on-device, not in a cloud system, because cloud systems are accessible to the vendor and therefore cannot demonstrate independence. A tamper-evident record must be sealed by a system that no single party controls.
Multi-Party Key Control
If the evidence is encrypted, the encryption key structure must prevent any single party from unilaterally accessing or suppressing the evidence. A two-key architecture — where decryption requires both a device key (generated on the sensor hardware and stored in tamper-resistant memory) and a custodian key (held by the asset owner or designated evidence custodian) — means that neither the vendor nor the operator can access the evidence without the other’s participation. This structural neutrality eliminates the possibility of one party suppressing evidence that is adverse to their interests.
Chain-of-Custody Metadata
Every access event — extraction, verification, inspection — must be logged immutably within the evidence package itself. The chain-of-custody log records that access occurred, when it occurred, and which key was presented. This log is sealed with the evidence and cannot be altered. In a dispute, any party can inspect the custody log to verify that the evidence was not accessed, altered, or selectively disclosed prior to the point where they received it.
Use Cases: Where Forensic Evidence Matters
Warranty Disputes
An OEM claims the bearing failed because of improper installation or operation outside rated parameters. The operator claims the bearing was defective from manufacture. Without a high-fidelity record of what the bearing was doing in the hours before failure — whether defect frequencies consistent with a manufacturing defect (inner race or ball defects) were present prior to any overload event — the dispute is resolved by assertion. A forensic record of the pre-failure vibration signature can often distinguish between a defect that originated in the bearing (present from early operation) and a defect that resulted from an operational event (appearing suddenly with overload signatures).
Insurance Claims
Marine hull and machinery insurers typically require evidence that the insured asset was operated and maintained within prescribed conditions. A tamper-evident failure record provides this evidence in a form that the insurer cannot reasonably dispute: it was captured by an independent device, sealed before anyone could access it, and the sealing can be cryptographically verified. This accelerates claims settlement and reduces the need for extended expert investigation.
Regulatory Investigations
In rail transport and aviation, catastrophic bearing failures trigger regulatory investigations that may involve subpoena of all available data. A forensic bearing failure recorder that produces a tamper-evident, chain-of-custody evidence package is specifically designed for this scenario: the data is preserved in a form that meets evidentiary standards without requiring after-the-fact reconstruction.
The Architecture That Delivers This
The requirements above — local pre-event buffering, on-device sealing, multi-party key control, immutable custody logging — are architectural requirements, not feature additions. They cannot be retrofit onto a standard monitoring platform. They require a system designed from the outset around forensic evidence as the primary deliverable, not operational trending.
Fault Ledger is built around exactly this architecture. It is not a predictive maintenance system, a health scoring platform, or a condition monitoring dashboard. It is a forensic recording system: it buffers high-frequency vibration data continuously, detects terminal events, seals a bounded evidence package on-device using multi-key cryptography, and maintains an immutable chain-of-custody log — all without requiring network connectivity or external power at the moment of failure.
For operators of high-value rotating machinery where bearing failure triggers multi-party disputes — marine propulsion, rail axles, wind turbines, industrial drivetrains — the question is not whether bearing failures will generate contested claims, but whether the evidence needed to resolve those claims efficiently will exist. Standard monitoring systems answer that question with a gap. Fault Ledger is designed to close it.