The Psychology
of Insight.

This guide takes the next step. The detection of faults has improved. The reasoning that interprets them has improved. Yet buildings still consume materially more than they should, faults persist for months, and recommendations accumulate unread. The bottleneck has moved.

Where it has moved to is harder to see, because it does not look like a technical problem. It looks like a presentation problem, a writing problem, a user-experience problem. It is none of those. It is a structural problem in how a finding is encoded for the person who has to act on it. And the psychology that governs it has been studied for forty years.

This guide sets out a three-layer cognitive framework for diagnostic systems. Each layer addresses a distinct psychological problem: what to notice, how to interpret, and how to encode. Together, they describe the journey a finding has to make to produce an action.

If you are designing a diagnostic system, commissioning one, or operating one, the question this guide tries to answer is: where in this journey is your bottleneck, and what does it cost you to leave it there?

Reasoning has improved too. The better platforms no longer just list deviations: they trace them, cost them, ratio them, and suggest causes. The journey from raw sensor data to a defensible interpretation is shorter than it has ever been.

Action has not.

Despite all of this, industry studies consistently find that operational HVAC systems run 15 to 30 per cent above where they should. Faults persist for months. Recommendations accumulate. The performance gap, the subject of FG/02, remains stubbornly open.

The natural assumption is that detection and reasoning need to improve further. What's failing is the last bit of the chain. The corrective action does not happen because the encoding of the finding does not motivate it. The operator looks at the alert, agrees it is real, and does not act. It is exactly that, and that is the problem this guide will examine.

Consider the most common failure mode. A diagnostic platform produces a list of faults, each with an estimated avoidable cost. The list is correct. The estimates are defensible. The operator looks at the list. None of it is acted upon. Not because the operator disagrees, and not because they are too busy, but because the encoding of the finding has not given them a reason to act now rather than later.

This is the problem the rest of this guide addresses. Not by improving detection, which is already there; not by improving reasoning, which is already there; but by improving the communication of a finding as part of the diagnostic system, subject to the same engineering rigour as the layers that produce it.

What makes a deviation worth attending to. The relevant question is which signals among thousands warrant further attention. The cognitive analogue is the moment a skilled operator notices that something is off before they can articulate why. The psychology of this layer is most fully described by Gary Klein's work on naturalistic insight: curiosities, coincidences, and contradictions are the triggers that prompt productive attention.

Whether a deviation is what it appears to be. The relevant question is whether the obvious explanation survives examination, or whether the visible symptom is the consequence of a different upstream cause. The psychology here, Daniel Kahneman's, is well known: a fast, automatic mode of thinking (System 1) produces a default interpretation; a slower, deliberative mode (System 2) tests whether that interpretation is consistent with everything else has been observed.

How the result of interpretation is communicated to the person who must act. The relevant question is whether the encoding produces engagement and action, or merely comprehension. The psychology, drawing on Tversky and Kahneman's work on framing, Trope and Liberman's on construal level theory, and Vallacher and Wegner's on action identification, points to the same underlying property of cognition: the encoding of a finding determines its behavioural fate.

Most analytics platforms have the first layer. Some have the second. The third has been almost absent from the field as a structural component of the system, even though it has been studied for forty years. This guide brings it back.

Klein identifies three kinds of noticing.

Something is happening that does not fit any available explanation, but it is not yet a contradiction. A piece of equipment is running when nothing is asking it to: the operational picture says it should be. The fact does not yet fit any pattern; that is what makes it interesting because no one has asked what it is doing here, and that is enough.

Two or more observations are happening at the same time, and their co-occurrence is not predicted by the current understanding of the system. The chiller's efficiency drops at the same moment a pump's flow stabilises. Either alone is unremarkable. Together, they suggest a relationship that the model does not yet describe.

An observation is incompatible with what is held to be true. The valve is commanded shut. Yet the temperature behaves as if it is open. One of the two assumptions, the command or the behaviour, is wrong. The contradiction forces a re-examination.

A detection layer designed around Klein's triggers does not fire on the loudest deviations. It looks for the deviations that come paired: contradictions, coincidences with structural consistency, and curiosities that recur. It treats the beginning of the act, not the end. A trigger is not a diagnosis. It is a request for one.

When a fault signature is recognised, System 1 produces an interpretation almost immediately. The valve is leaking. The sensor is failing. The schedule is wrong. The candidate explanation arrives without effort, which is its strength and its danger. It is also where most diagnostic mistakes begin.

System 2 does not generate interpretations on its own. Its job is to test the interpretation System 1 has already produced. It asks: what would have to be true for that explanation to hold? Does the evidence support it? What does the surrounding system look like, and is it consistent with this story?

The difficulty is that System 2 is effortful, and effort is expensive. Under time pressure, an experienced operator will substitute recognition for analysis: the fault looks like one they have seen, so they treat it as that one. Sometimes they are right. When they are wrong, the consequences propagate.

When a detection event arrives, the System 2 layer traces the implied fault upstream and downstream. It asks whether the behaviour at adjacent nodes is consistent with the candidate explanation. If the obvious answer is the valve is leaking, the system tests whether the rest of the circuit is behaving as a leaking valve would imply. If not, the explanation is reframed.

Reframing is the part of interpretation that conventional fault detection rarely does. Most platforms produce a single hypothesis and stop. A System 2 layer treats the first hypothesis as a starting point, not a conclusion.

Tversky and Kahneman, in 1981, showed that the same outcome described in terms of a loss produces different decisions from the same outcome described in terms of a gain. The mechanism is called reference-dependent valuation. A gain frame engages people; a loss frame, especially one describing a loss already incurred, disengages them.

A finding encoded as waste is a loss already booked. The money has gone. There is nothing to recover, only something to have lost. A finding encoded as recoverable value is a gain still on the table. The same number, framed differently, produces engagement instead of resignation.

Trope and Liberman, working in construal level theory, showed that abstract descriptions are processed as psychologically distant. They feel as if they pertain to some other time, place, or person. Concrete descriptions feel close. They feel as if they pertain to the person reading them, now.

“Significant savings opportunity identified” is abstract. It describes a category. “£187 recoverable on the primary chiller” is concrete. It describes a thing, in a place, with a number. The literature is consistent: the concrete version produces action; the abstract version produces deferral.

Vallacher and Wegner showed that tasks identified at high levels of abstraction tend to be deferred or delegated, while tasks identified at the level of the act tend to be done. “Address sensor performance issues” is a category. “Calibrate the supply air sensor on the third-floor unit” is an act. Same intervention, different language, different probability of completion.

The communication layer is not a presentational concern, to be addressed by writers and designers after the engineering work is done. It is part of the engineering. A finding that is correctly detected, correctly interpreted, and incorrectly encoded is a finding that does not close the gap.

In practice this means writing findings in a defined lexicon: gain-framed, concretely specified, identified at the level of the act. Findings are framed as recoverable value, not avoidable cost. They are quantified at a specific asset, not in a category. They are paired with an action that can be taken now, not an investigation that may, eventually, lead to one.

Something is wrong. The basement equipment is reporting that the air it is sending up is much warmer than it should be. The valve that would let in heat is firmly closed. So the only explanation, from the equipment's point of view, is that the valve has failed and is leaking heat anyway.

Three things are happening at once. The supply air is unexpectedly warm (a curiosity). The cooling system is working harder than it should need to (a coincidence). And the smaller units on the floors above are quietly heating the rooms back up (a contradiction, because if the air arriving is already warm, why would they need to add more heat?).

All three triggers are mild. Individually, none would warrant attention. Together, they describe a system that does not make sense, and the noticing layer flags them as a single linked event.

The fast, default interpretation is the one the equipment itself is offering: the heat valve must be leaking. The interpreting layer tests this. If the valve were leaking, the heat circuit would show signs of it: warmer return temperatures, more pump activity. Neither is happening.

Looking wider: the cooling system is working overtime, far more than the conditions outside justify. The smaller units upstairs are reheating air the basement equipment has just sent up as cold as it can. That is not how a leaking heat valve behaves.

The cost of this fight: about £40 a day, distributed across the basement equipment, the cooling plant working too hard upstream, and the smaller units reheating downstream. None of the individual costs is large. The total is significant, and it has been running for some time.

Now the finding has to travel from the diagnostic system to the person who can act on it. There are two ways to do it.

The conventional version: “Supply air sensor anomaly detected. Recommend investigation. Estimated avoidable cost: £39.66/day.”

This is correct. It is also unlikely to produce action. The frame is loss-oriented (avoidable cost). The action is abstract (investigation). The intervention is at the level of a category (anomaly).

The briefing-shaped version, encoded by the third layer:

Same data. Different encoding. Different probability that an action is taken today. The first is a description. The second is a briefing.

For two decades, the analytics industry has spent its budget on the first two layers, and treated the third as a presentational afterthought. The persistence of the performance gap, in the face of widespread analytics deployment, suggests this allocation of attention has been wrong.

Where in the chain is your bottleneck? If you are detecting well but not interpreting deeply, the second layer is your limit. If you are interpreting deeply but not seeing action, the third layer is. The diagnosis of a diagnostic system is the same as the diagnosis of a building: trace the impact upstream and downstream, find the place the value is leaking, and act at the leak.

ABIE is GRIOTech's embodiment of this framework. It detects according to Klein's triggers, interprets through the dual-process test, and encodes findings according to a lexicon designed to produce action. A System 2 layer that does the interpreting work for a building, a briefing that does the encoding work for a finding, and a verification step that closes the loop.