Why the person who wrote the program cannot audit it
· Reading time 4 min
On the left, what the installation does; on the right, what it was meant to do. An audit is the act of placing the two side by side.
It is not a question of competence, still less of honesty. It is a question of position.
Auditing a control system means comparing observed operation with the original intent. Whoever programmed the installation does not have the distance that work requires: for them, observed operation is the intent. That is a structural constraint, not a professional failing.
An audit sets two versions of the same installation side by side
On one side, the intent: the control concept, the functional descriptions, the HVAC specification, the design assumptions. What the building owner ordered and paid for.
On the other, reality: what the installation actually does today. The setpoints currently in service, the schedules as they have been edited over the years, the loops left in manual, the overrides never cleared, the alarms masked, the trend curves across a full season.
An audit is the act of bringing those two versions together and explaining every gap. And there are always gaps. Each has a perfectly rational history: a commissioning rushed to meet handover, a user complaint dealt with by lowering a setpoint on a Friday evening, a field fault worked around in software while waiting for a call-out that never came. None of those decisions is absurd taken on its own. Their accumulation, however, produces an installation nobody can describe any more.
An audit lives entirely in the gap between these two columns — and that gap cannot be measured from inside the program.
What the author of the program sees
They read their own code with the intent in mind. They do not read what is written, they read what they meant to write — the best-documented bias in software work, and the only known remedy remains review by someone else.
The override set three years ago no longer registers as a gap: it is part of normal operation. The alarm disabled to stop the phone ringing is filed as a problem solved. There are no longer two versions to compare, only one: the one that is running.
An audit is worth most for its naive questions. Why does this pump run continuously? Why does this unit start at 4 a.m.? Why is this setpoint at 55 °C and not 45? Whoever set the system up answered those questions long ago, often for a good reason — a reason that has sometimes since ceased to exist. They do not ask them again, and no one would hold that against them.
The second slope is economic
To this a simple reality is added. A systems integrator earns a living selling hardware, licences and integration. Faced with a problem, their natural slope leads towards a solution that involves a piece of equipment.
Often rightly so: the valve genuinely is undersized sometimes, the controller genuinely is out of support sometimes. Not always. A significant share of the malfunctions we come across is fixed in a parameter, a sequence, a time schedule or the position of a sensor — with no hardware line on the invoice.
This is not an accusation. It is the observation that nobody should be asked to referee their own offer. Behind it lies the question of who really holds the keys to your building.
What an outside view produces
In practice, the method comes down to a few principles:
Read the concept before looking at the installation. The other way round, you inherit the very bias you came to correct: you start justifying what is already there.
Work on continuous operating data, not on one-off screenshots. A control system is not judged at a single moment but over a cycle — a night, a weekend, a shoulder season. Provided the measurement itself can be trusted: a clogged pressure switch lies without knowing it.
Rank the gaps by what they cost: energy, comfort, equipment life, availability. A list of thirty observations with no hierarchy is not an audit report.
Separate what belongs to settings, to software, to hydraulics or air handling, and to hardware. That distinction is what determines the budget — and it is rarely made.
It is the same reasoning we apply during commissioning and site supervision, or when taking over a BMS supervision project: start from what the installation does, not from what the drawing says it should do.
“There is nothing to change here”
An independent engineering office has neither the constraint of position nor the economic slope. We install nothing, represent no brand, and sell neither controllers nor licences. Our only product is advice to the building owner — which means the recommendation “there is nothing to change here” costs us exactly as much as any other.
That is not a posture. It is the condition for every other recommendation to carry weight.
None of this takes anything away from the integrator's work. A well-run audit often does them a favour: it puts a written frame around trade-offs they had to make alone, under time pressure, with no mandate to document them. What changes is not the expertise involved — it is who asks the questions, and to whom the answers are owed.
An installation that “works” without anyone knowing exactly why is precisely the starting point of an energy audit and MCR/BMS consulting assignment. And when that outside view arrives early enough, it avoids the sentence we hear far too often: “we should have called you sooner”.