A sequence of operations is supposed to be the authoritative description of how a system behaves. In practice it is frequently ambiguous, occasionally contradictory, and often describes a building slightly different from the one that got built.
That isn't necessarily anyone's fault. Sequences are written during design, before equipment selection is final. Value engineering changes things. Substitutions happen. The sequence rarely gets updated to match. What arrives on site is a document describing intent, not installed reality — and the gap between those two is where your service calls come from.
The questions a sequence usually fails to answer
What happens on sensor failure?
If the discharge air sensor fails, does the loop drive to full heating, full cooling, or hold last position? A sequence that doesn't say has left the answer to whoever wrote the code, and different programmers make different choices. This is worth knowing before a sensor fails.
What happens on communication loss?
A VAV box that loses its supervisor: does it hold last setpoint, revert to a local default, or fail to a fixed position? On a network that occasionally drops, this determines whether an outage is invisible or a comfort event.
What are the exact changeover conditions?
“Economizer shall operate when outdoor conditions are suitable” is not a sequence, it's an aspiration. Suitable by what measurement, at what setpoint, with what deadband, and what prevents it hunting at the boundary?
What are the interlocks and their priority?
When freeze protection, smoke control, occupancy and demand limiting all want different things, which wins? Sequences often list interlocks without ever stating precedence. On a BACnet system this maps directly onto priority array levels, and getting it wrong produces points that look stuck for reasons nobody can explain.
What happens at start-up?
Many sequences begin at steady state and never describe the transition into it. Start-up is when integral wind-up dumps, when dampers are in the wrong place, and when a large fraction of nuisance alarms fire.
What are the actual setpoints and where do they live?
A sequence that says “maintain space temperature setpoint” without saying where that setpoint comes from — fixed, scheduled, reset, or occupant-adjustable within a range — leaves the most-touched value in the building undefined.
Verifying that installed logic matches
Reading the sequence tells you what should happen. It tells you nothing about what does. These are separate questions and they need separate work.
Test the transitions, not the steady state
Steady-state operation almost always works — it's what got commissioned and what everyone looks at. Force the transitions instead: drive setpoints to force a changeover, override an input to simulate a failure, cycle occupancy to watch the mode change. That's where the divergence shows up.
Trend across a mode change
Set a fine-interval trend that brackets an occupancy transition or a changeover, then compare what the trend shows against what the sequence describes, line by line. Discrepancies are usually obvious once you look at them side by side.
Read the code where you can
On platforms where the programming is visible to you, the logic is the ground truth and the sequence is a claim about it. Where they disagree, the code is what the building is actually doing.
When the sequence and the building disagree
The right move is usually to document the discrepancy, establish which behaviour is actually correct for the building as it exists now, and get agreement before altering anything. Then update the sequence — because the next technician will read the same document and reach the same confusion you did.
A practical reading checklist
| Ask | Why it matters |
|---|---|
| Does it define every setpoint numerically? | Vague setpoints get filled in by whoever programmed it |
| Does it describe failure modes for each input? | Determines behaviour on the day something breaks |
| Does it state interlock precedence? | Maps directly to command priority in the field |
| Does it describe start-up and shutdown? | Where transient faults and nuisance alarms originate |
| Does it match the equipment actually installed? | Design-era documents often describe substituted equipment |
| Does it define comms-loss behaviour? | Determines whether a network blip becomes a comfort event |
A sequence that answers all six is rare and worth keeping a copy of. One that answers none is not unusual, and tells you the real sequence lives in the code and in whatever the last technician remembered.
Go deeper
The method behind this, chapter by chapter
Every sensor, drive and control loop in the building — how it works, how to prove it with a meter, and how it fails. BAS Field Fundamentals is the method this article uses, with 20 field cases and a browser diagnostic simulator to practice on.
Get BAS Field FundamentalsFound a wrong number or a broken link? Tell me and I’ll fix it.