Why detection should be deterministic and explanation should not

There is an obvious way to build alerting on top of charging telemetry: stream the data to a capable language model and ask it what looks wrong. It demos extremely well. It should not be shipped.

The problem with a model that decides

Consider what an alert is actually for. A pack temperature alert may stop a charging session, dispatch a technician, and become evidence in a warranty claim or an insurance conversation. Months later somebody will ask why the session was halted.

If the answer is that a model looked at the telemetry and formed a view, there is nothing to examine. The model may have been updated. Sampling makes the output non-deterministic. The reasoning is not recoverable. An alert you cannot reproduce is not evidence — it is an anecdote.

The split

The division we settled on is narrow and strict:

• A versioned rule decides. Pack temperature at or above the ceiling across two consecutive samples. Thermal ramp above 1.8 °C per minute while the pack is already warm. The rule identifier, its version and the input values are stored with the alert.
• A model explains. Once the rule has fired, an agent writes what happened, why it matters and what to do next, and ranks the alert against everything else in the queue.

The model never sets state. It cannot raise an alert, suppress one, or change a severity. Remove the model entirely and the safety behaviour of the system is unchanged — you simply lose the readable prose.

What you get in return

Auditability, obviously. But also something less expected: the explanations get better. A model asked to both detect and explain hedges, because it is uncertain whether there is anything to explain. A model handed a fired rule and its inputs is answering a much narrower question, and answers it well.

Give a model the job it is good at, and take away the job it cannot be held to.