The description of operation: the most undervalued document in your building

Somewhere in your O&M manuals — or, tellingly, missing from them — is a document that determines how much every future controls visit will cost: the description of operation. It states, in plain language, how each system in the building is supposed to behave: what starts what, at which setpoints, under which interlocks, and what happens when things fail. Unglamorous, and worth more than most of the hardware it describes.

Who actually depends on it

More people than write them. The commissioning engineer proves the installation against it — without a DoO, "commissioned" just means "it turned on". The maintenance team uses it to tell a fault from a feature at three in the morning. The next contractor prices work against it; ambiguity there is priced as risk, and you pay the premium. Energy assessors and auditors read it to see whether the building is even trying. And the owner relies on it as the record of what was bought — the design intent, in writing.

What a good one looks like

Plain English first, system by system: each air handler, heating circuit and pump set described in sequences a competent stranger can follow. Setpoints and schedules gathered in tables rather than buried in prose, so the values that get tuned live where they can be found. Interlocks and safeties stated explicitly — what stops what, and why. Failure behaviour written down: what the system does on sensor failure, power loss, fire signal. And revision control, because a DoO that doesn't change with the building becomes fiction with a contents page.

Write it before the software

The habit that changes everything: the DoO should be written before the control software, not reverse-engineered afterwards. Written first, it's a design tool — gaps and contradictions surface on paper, where they cost minutes, instead of during commissioning, where they cost programme. It also keeps the client in the conversation: an owner can read and challenge a sequence in plain English long before it's compiled into a controller. We hold documentation to the same standard as the systems themselves, because in the long life of a building, the paper outlasts the panels.