Domain Atlas / Industrial QA & operations AI
The maintenance contract that prices every miss
Explore this deployment in the PAN Lab ↗
A rail service provider operates sensor-based predictive maintenance on a high-speed fleet under a priced availability contract: roughly 300 sensors per train read at five-minute intervals (on the order of a million readings per train-year), overlaid with human-written failure reports, maintained against a promise that refunds the full fare if a journey is delayed more than fifteen minutes. The documented results are only one noticeably delayed journey in 2,300 (by five minutes) and discovered failure signatures such as an engine-temperature pattern preceding failure by three days. The fleet outcome is documented in a vendor-side trade case study; the analytics' own precision is not published, so the model-level figures remain unstated while the operational outcome is on the record.[†]
What happened
A high-speed rail fleet is maintained under an unusual arrangement: the manufacturer maintains its own trains as a service, for an operator whose flagship promise is a full refund if a journey arrives more than fifteen minutes late. Inside that arrangement runs sensor-based predictive maintenance - roughly 300 sensors per train, read at five-minute intervals, producing on the order of a million readings per train-year, overlaid with the failure reports maintenance crews write.
The documented results are the strongest operational numbers in this domain's record: only one journey in 2,300 noticeably delayed, and by five minutes - against the fifteen the refund promise prices. And the analytics found things people had not known to look for: failure signatures, like an engine-temperature pattern that precedes a particular failure by three days, discovered by joining the sensor streams to the crews' written failure reports.
The governance shape is the case's real content. In most of this domain, the party that tunes the model and the party that bears the cost of its misses are different organizations - a vendor sells, a deployer suffers. Here they are the same: the service provider operates the analytics, schedules the interventions, and pays when the refund promise triggers. Every missed failure has a price, and the bill goes to the desk that holds the model levers. That is why the response side of this deployment is resourced in a way the domain's other cases only aspire to - the contract does the resourcing.
Two dependencies temper the picture, both documented. The discovery loop runs on human documentation: the signatures were found by overlaying sensor data with failure reports crews wrote for their own purposes, so the quality of what the analytics can learn is bounded by the quality of what people keep writing down. And the sensor stream is the analytics' only view of the machine - a failing sensor and a failing train arrive looking exactly the same, until someone goes to the train and looks.
The honest reading is that this is the domain's best-aligned deployment - the incentive to prevent failure priced into the organization that can prevent it - with an operational outcome on the record, a model precision that is not, and a discovery loop that quietly depends on crews continuing to write honest failure reports.
The sociotechnical reading
This case is the industrial-QA domain's incentive-alignment portrait. Everywhere else the map watches a seam - a vendor who tunes and a deployer who suffers, each holding half of what the other needs. Here the contract closes the seam: the party operating the analytics pays for its misses, so the map's usual question (who is accountable for the model's errors?) has a documented answer with a price on it. The instruction the case carries is that alignment is a designable property of the CONTRACT, not a virtue of the model - the same analytics under a sell-and-walk-away arrangement would be a different governance object entirely.
The load-bearing dependencies are the two the record names. The discovery loop runs on failure reports written by crews - human documentation produced for human purposes, which the analytics joins to its sensor streams to find signatures. That makes documentation quality a model input: if reports thin out or drift toward blame-safe phrasing, the signature discovery quietly starves. And the sensor stream is the model's only sense of the machine, so sensor faults and machine faults are indistinguishable from inside - the check that separates them is a person at the train, which is exactly the kind of check a well-performing system tempts an organization to trim.
The map draws both as the deployment's latent checks: the discrimination between a failing sensor and a failing machine, and the standing physical-inspection cadence that keeps ground truth flowing into a loop that otherwise reads only its own instruments. The refund-promise accounting - every delayed journey counted against the contract - is drawn PRESENT, because it demonstrably runs; it is the rare case of an external, priced measure of the whole system's performance that no one inside can massage.
The Lab network models only the deploying operation: its analytics, its planners, its joined sensor-and-report record, and the refund-promise accounting over it. No passenger outcome is computed on any diagram. The fleet outcome figures and the discovered signatures live in this case file, entered as the vendor-side trade record they are; the analytics' own precision is unpublished and no number here stands in for it.
The concepts used in this reading are defined in the Field Guide; the governance responses live in the Practice Library. The model organization for this case can be stress-tested in the PAN Lab.