What an operator decision support system has to do to get used

Most published decision-support research describes nuclear control rooms, and that is not an accident. Nuclear control rooms have been studied intensively because the consequence of an operator error is unusual, and the human factors work funded on the back of that is deep.

Some of it transfers directly. Situation awareness, workload, trust in automation and the way people behave under alarm floods are properties of operators rather than of reactors. Some of it does not: the staffing levels, the procedural rigidity, the regulatory framing and the assumption of a large team in a purpose-built room describe an environment a gas peaker or a battery site does not have.

The plants being built now are variable, lightly staffed and increasingly remote-operated, so they inherit the human factors without inheriting the staffing. The findings that do transfer therefore have to carry more weight, not less.

Four things, and the order matters. What has changed, stated in the vocabulary of the plant rather than of the model. Why it matters, which means the consequence if nothing is done. How long there is, because the response to a two-hour window is different from the response to a two-week one. And what to do, named specifically enough to act on.

Most systems deliver the first and stop. A score that moved from 0.73 to 0.81 satisfies none of the four, and the honest description of it is a display rather than a decision aid.

The fourth is where the difficulty concentrates. Naming an action requires knowing the mechanism, the plant's constraints and what is operationally available today, which is a considerably harder problem than detecting a departure. Systems that cannot do it should say so and route the finding to engineering rather than to the control room.

The counter-intuitive finding from the human factors literature is that assistance can reduce an operator's understanding of the plant. If the system builds the picture, the operator does not, and the operator who has not built the picture is the one least able to take over when the system is wrong.

This is not an argument against decision support. It is an argument for a specific kind: one that shows its reasoning rather than only its conclusion. An output that names the readings it relied on, the mechanism it inferred and the alternatives it rejected keeps the operator in the loop of understanding rather than in the loop of compliance.

It also has a practical benefit. An operator who can see the reasoning can catch the case where the reasoning is wrong, which is the case that matters most and the one a confidence score cannot surface.

Process industries learned this lesson expensively in the 1990s. Distributed control made alarms nearly free to configure, and plants configured them until operators faced more than they could act on. The result was not that operators became more responsive. It was that alarms stopped functioning as information.

The standards that followed set limits on alarm rates precisely because the failure was behavioural rather than technical. A system can be correct at a rate no human can absorb and still make things worse.

Analytics deployments inherit that lesson and routinely ignore it. A model producing several unexplained alerts a day during commissioning teaches a control room that the new system cries wolf, and that lesson is very hard to unteach. The mechanism is set out in reducing false positives in industrial anomaly detection.

The number worth agreeing before a pilot starts is how many notifications a shift will accept. Every tuning decision follows from it, and discovering it afterwards means discovering it by losing the room.

Trust in a new system is established in the first fortnight and rarely revised afterwards. A system that is right about something visible early is believed for a long time. One that raises three alerts nobody can explain in week one is finished, regardless of how good it becomes later.

That argues for a deliberately narrow start. One asset, one failure mode, one decision, tuned conservatively, expanded only after it has been right in front of witnesses. It is slower and it is how these systems survive.

It also argues for explicit uncertainty. A system that says it is unsure, and says why, is trusted more over time than one that is always confident and occasionally wrong. Operators are experienced at working with imperfect information and are not asking for certainty; they are asking to know which information is which.

Accuracy is the wrong headline measure, because a system can be accurate and ignored. The useful measures are behavioural.

What proportion of notifications are acted on. What proportion are dismissed without action, and does that proportion rise over time, which is the leading indicator of the system being switched off in people's heads before it is switched off in fact.

How often an operator does something different at the end of a shift than they would have done. This is the closest available proxy for the thing the system is for, and it can be sampled by asking rather than instrumented.

And whether the plant changed as a result: fewer unplanned stops, earlier interventions, better operating point selection. Those are the outcomes, they take longer to measure, and they are what the business case was written against.