Ask your predictive maintenance vendor these 7 questions

Every predictive maintenance demo works. The vendor brings a dataset where the bearing failed, the model flags it four days early, and everyone in the room nods.

Then you buy it, and six months later your maintenance lead has stopped opening the alerts.

The gap between those two moments is almost never the detection maths. It’s everything nobody asked about in the demo. Here’s what to ask instead, and what a good answer sounds like.

1. Show me how this specific score was calculated

Not the methodology slide. Pick a machine on the screen, point at its number, and ask where it came from.

A good answer names the events that moved it and the points each one cost. A bad answer describes a model. If the vendor can’t decompose one number in front of you, your reliability engineer won’t be able to either, and neither will the auditor who asks in eighteen months.

For what it’s worth, ours is health_score = (1 − w) × alert_score + w × anomaly_score, and the per-event deductions are published. A critical alert in the last seven days costs 15 points, capped at three occurrences. You can check our arithmetic on paper, which is the entire point.

Here’s a machine sitting at 66. Two critical alerts inside the last week, one of them still unacknowledged, and every subtraction on the page.

2. How long until the first useful alert, and what happens before that?

Anything that learns needs data before it’s worth anything. That’s fine. What’s not fine is discovering the length of that window after the PO is signed.

Ask for the number in weeks, and ask what the system does in the meantime. Silence? Alerts you’re told to ignore? A dashboard of zeros?

Ours needs 24 to 72 hours to establish a rolling baseline, because a z-score needs a mean and a standard deviation to compare against. That’s a statistics window, not model training, and nothing about it drifts afterwards.

3. What’s your false positive rate?

This is a trap question, and you should ask it anyway.

Nobody can honestly give you a number without your data. Any vendor who quotes one is quoting a different plant’s asset mix. What you’re listening for is whether they say so, and what they offer instead.

The useful answer is per-asset tunability plus a reason attached to every alert. Your team can live with a detector that fires too often if they can see why and adjust the threshold themselves. They cannot live with a black box that cried wolf three times and won’t explain any of them.

4. Who holds the key to your audit log?

Ask where the signing key lives. If the answer is “in the database”, then anyone with database access can rewrite history and re-sign it, and your audit trail proves nothing.

Then ask the follow-up: can you delete a row? The honest answer involves retention policy and right-to-erasure, not a flat no.

Ours signs each row with HMAC-SHA256 over its canonical payload plus the previous row’s hash, with a monotonic per-tenant sequence so a gap means deletion. The key sits in application config, not the database. A Postgres trigger blocks deletes outside the retention sweep. The verifier source is published so you can recompute the chain yourself, offline, without us.

5. What happens when the network drops?

Plants lose WAN links. Ask how long the edge agent can run disconnected, and what happens to the readings taken during the outage.

“It buffers” is not an answer. Ask for the duration, where the buffer lives, and whether the backlog flushes in order when the link returns. A buffer that holds fifteen minutes in RAM is a different product from one that survives a weekend on disk.

6. Can you write to my PLCs?

The answer you want is no.

A monitoring platform with write access to control systems is a safety and security problem wearing a convenience feature. Ask whether the connection is outbound only, whether there’s any reverse tunnel or remote shell, and whether the vendor will state in writing that the product is out of IEC 61511 scope.

If they hesitate on that last one, your OT security team is going to have a long month.

7. What does leaving look like?

Ask this in the first meeting, not the last. It tells you more about the vendor than any feature question.

You want a specific export format, a specific window after termination, and confirmation that the export includes history rather than a snapshot. If the answer is a support ticket and a maybe, you’re not buying a platform. You’re renting access to your own data.

The pattern

Six of these seven have nothing to do with detection accuracy. That’s not an accident.

Detection is the part every vendor has already solved well enough. What separates the platform your team still opens in month six is whether they can see why it said what it said, and whether you can walk away with your data when you want to.

If a vendor gets defensive about any question on this list, that’s your answer.

The Buyer’s Guide has the longer version, including a pre-answered SIG Core and CAIQ Lite, a sample RFP and a rollback checklist.