Your predictive maintenance vendor can't testify

A pump fails. Somebody gets hurt, or a warranty claim gets denied, or a line sits dead for eleven days and the insurer wants to know why nobody acted sooner.

Fourteen months later, in a room with a lawyer in it, you get one question:

Your system scored this pump 71 on March 3rd. Show me why.

Most predictive maintenance platforms cannot answer that. Not because the model was wrong. Because nothing about March 3rd still exists.

What that question is actually asking

It’s two questions wearing one coat.

The first is reproduction. Given the sensor data as it stood on March 3rd, can you produce 71 again, today, and show the steps? The second is integrity. Can you prove that the record saying 71 is the record written on March 3rd, and not something edited afterwards by somebody with database access and a reason?

Fail either half and you don’t have an answer. “Our system output 71” is a claim about a log file. The question is whether that log file is worth anything.

Why can’t a retrained model reproduce an old score?

Because the thing that produced the score is gone. A well-run ML system retrains on a rolling window, so the version that scored 71 left production months ago, and unless the team pinned and archived every version alongside its training set, it isn’t anywhere at all.

The training data has rolled off too. Telemetry retention is usually measured in months, because storing high-frequency sensor data for years is expensive and nobody budgets for the lawsuit.

And the inference was logged as a number. Not the input vector, the model hash, the feature transforms, and the threshold in force that day. Just 71, a timestamp, and an asset ID.

So the honest answer becomes: we can tell you the system said 71, we can describe roughly how the model family works, and we cannot rebuild that specific decision. In a deposition, that sentence does a great deal of damage, and it does it to you rather than to your vendor.

Can you reproduce a health score from fourteen months ago?

You can, but only if the system was built for it long before anyone asked. It takes detectors that are deterministic rather than trained, a scoring formula that’s published rather than inferred, and retention measured in years rather than months.

Haltless takes the boring path deliberately. The three detectors are deterministic: a static-baseline z-score, an exponentially weighted moving average, and a rate-of-change check. Same inputs, same output, every time, with no training state to drift out from under you. The health score is a published formula, (1 − w) × alert_score + w × anomaly_score, and every deduction that moved it traces back to a specific event through a documented table.

March 3rd is therefore recomputable on paper. Not explainable in the sense of a feature-importance chart that gestures at what the model probably weighed. Recomputable, by your reliability engineer, by your auditor, or by the other side’s expert witness, with the deduction table and a calculator.

How do you prove a record wasn’t edited afterwards?

You sign each row, chain it to the one before it, and keep the signing key somewhere the database can’t reach. An edit is still possible after that, but an edit that verifies is not, and that’s the only version of the guarantee which survives an insider holding write access.

Every row in the audit chain carries three protective fields. A sequence that increases monotonically per tenant, so a gap means a deletion. A prev_hash pointing at the row before it, so a broken link means an insertion or a reorder. And a row_hash, an HMAC-SHA256 over the canonical serialization of the row, signed with a key held by the application rather than by the database.

That last detail is the one that carries the weight, and it’s the easiest one to skim past. If the signing key lives in the database, then anybody who can edit a row can re-sign it, and the entire chain is decoration. Holding the key outside means a DBA with full write access can still change a row, but cannot make the change verify. A PostgreSQL trigger blocks deletion outside the retention sweep, and the verifier writes its own results back into the chain as audit events, so even the checking is on the record.

Retention runs 2,555 days. Seven years isn’t an arbitrary round number. It’s chosen to outlast the window in which somebody turns up asking about March 3rd.

The part that isn’t a sales pitch

None of this makes the detection more accurate.

A deterministic z-score is not smarter than a well-trained model. On raw detection performance, on the right dataset, a good ML system may well beat it. That’s a genuine trade, and pretending otherwise would be the same dishonesty this post is complaining about.

What you get instead is a system whose every output can be reconstructed and whose every record can be proven unedited, seven years on, by somebody who has no reason to trust you. It’s why the detectors sit outside the EU AI Act’s high-risk obligations by design, and why the chain carries the attributable, contemporaneous, original, accurate and time-stamped properties that 21 CFR Part 11 §11.10(e) asks for. We publish formulas, not models.

Ask a vendor to reproduce a specific score from a year ago and watch which half of the question they answer. There’s a version of this as question four in seven questions worth asking before you sign.

Because it reduces to one thing, and it’s cheaper to settle before you sign than fourteen months afterwards. Which of the two would you rather be holding in a deposition?