Controls, with the sequence written down before it is programmed

Before any code is written we produce a sequence of operation in plain English: what each piece of equipment does, at what setpoints, with what interlocks, under what occupancy schedule, and what happens on a failure or an alarm.

You read it. You disagree with parts of it. We change those parts. Then it gets programmed. That order costs a week at the start and saves months of the building doing something nobody intended.

It also gives you something to hold the next contractor to, long after we are gone.

Every point gets a name, an object type, an address, an engineering unit, an alarm limit where relevant and a trend interval. That list is issued to you, and it is the document that makes the system maintainable by somebody else.

Point-to-point verification means physically confirming each one: the sensor reads what a reference instrument reads, the output actually strokes the damper, the alarm actually raises. Somebody signs the sheet. This is unglamorous and it is where controls jobs are won or lost.

Trend logging gets configured at commissioning, not after the first complaint. Space temperature, setpoint, valve and damper position, supply air temperature, static pressure, outdoor air temperature and the equipment status all get logged from the day the system runs.

Thirty days later we export the trends and go through them with you. That first review reliably finds two or three things: a zone fighting itself, a schedule nobody set, an economizer that is not changing over. They are cheap to fix in month one and expensive to find in year three.

We work in BACnet MS/TP and BACnet/IP. Third-party equipment, including VRF systems, packaged rooftop controllers and boiler plant, gets mapped into the same front end rather than left as an island with its own proprietary keypad in a cupboard.

Graphics show the system as it is drawn, with live values on the points that matter. They are not a marketing render of a building with a spinning fan on it.