How to write a sequence of operations
How to write a control sequence as explicit states, triggers, and setpoints rather than narrative prose, so it can actually be verified during commissioning.
What this means
A sequence of operations written as narrative prose describing what a system should do leaves the specific triggers, setpoints, and transition conditions to the controls contractor's interpretation, and different interpretations produce different installed behaviour from the same document. A sequence written as explicit states, each with the exact condition that triggers entry and exit, and the exact setpoint or output each state commands, can be checked directly during functional performance testing against what the document actually specified.
Equipment and model context
- HVAC control sequences for packaged, split, and central plant systems of any scale
- Worked figures illustrate the method and are not a rating for any product
This explains the structure that makes a sequence verifiable and the gap narrative prose leaves. It does not write a sequence for a specific system. That requires the actual equipment capabilities, the building's operational requirements, and coordination with the specific controls platform's programming constraints.
What this covers
- Why narrative prose leaves triggers and setpoints open to interpretation.
- What an explicit state, trigger, and output structure actually specifies.
- How functional performance testing depends on the sequence being written this way.
- Why the same narrative sequence installed by two different contractors can behave differently.
What changes the result
- Writing a sequence as prose describing intended behaviour rather than as explicit states with named entry and exit triggers.
- Leaving setpoints and timing values as vague terms rather than specific numbers, forcing the controls contractor to select a value themselves.
- Omitting the transition conditions between states, so what actually causes the system to move from one mode to another is undefined.
- Writing a sequence that cannot be checked item by item during functional performance testing because it never states a specific, verifiable condition.
Why narrative prose fails as a specification
A sequence describing a system in flowing prose, the unit shall run in occupied mode during business hours and shall modulate to maintain comfort, reads as plain English to a person and specifies almost nothing to a controls programmer. Business hours, comfort, and modulate are all terms a reader understands intuitively and a programmer has to convert into an actual schedule, an actual setpoint, and an actual control loop, each of which the narrative left as their decision rather than the design's.
This gap is invisible until two different contractors install the same narrative sequence and produce two different actual behaviours, both arguably consistent with the words on the page, neither necessarily matching what the designer had in mind. The narrative was never actually specific enough to fail against, which is different from being correct.
What an explicit sequence actually states
An explicit sequence names each distinct operating state the system can be in, and for each state gives the exact condition that triggers entry, the exact condition that triggers exit to another named state, and the exact setpoint, output, or control loop that state commands. Occupied cooling mode is not enough; occupied cooling mode enters when the schedule reads occupied and space temperature exceeds the occupied cooling setpoint by a stated deadband, and while active commands the cooling valve or compressor to maintain that setpoint, is a specification a programmer implements rather than interprets.
Every number that matters, setpoints, deadbands, timers, minimum run times, and staging delays, appears as an actual value in the sequence rather than as a descriptive word. Where the design genuinely wants a value determined during commissioning rather than fixed in advance, the sequence should say so explicitly, stating the range and the criteria for selecting within it, rather than leaving the value unstated and letting silence stand in for open-ended discretion.
Why this structure is what functional performance testing needs
Functional performance testing, covered in the article on commissioning tolerances, runs the installed system through its actual operating modes and checks that it behaves as specified. That check is only meaningful against a sequence specific enough to fail: a stated trigger condition can be forced and the resulting state verified, while a narrative description offers no specific condition to force or verify against.
A sequence written explicitly becomes the actual test script, item by item, for functional performance testing, and a deficiency found during that testing is unambiguous, the system entered or failed to enter a specifically named state under a specifically stated condition, rather than a judgment call about whether narrative prose was satisfied.
Where explicit sequences still need judgment
Writing a sequence explicitly does not remove every design decision from the document; it moves the decisions into the open where they can be reviewed, rather than leaving them implicit for a controls contractor to resolve without the designer's input. A designer still decides what the occupied cooling setpoint should be, what deadband prevents excessive cycling, and what staging delay protects the compressor, and those decisions belong in the sequence as stated values precisely because they are decisions worth reviewing before installation, not after a functional test reveals what the contractor assumed.
The goal is not exhaustive detail for its own sake; a sequence with more specified states and conditions than the system actually needs becomes as hard to verify as a vague one, just in the opposite direction. The right level of detail is whatever makes every operating condition the system will actually encounter checkable against a stated trigger and a stated response, the same standard an economizer changeover sequence needs to meet when it states its own dry-bulb or enthalpy threshold explicitly.
| Element | What it states | Why functional testing needs it |
|---|---|---|
| Entry trigger | The exact condition that moves the system into this state | Gives the tester a specific condition to force and check against |
| Commanded output | The exact setpoint, valve position, or stage this state commands | Gives the tester a specific value to measure once the state is entered |
| Exit trigger | The exact condition that moves the system to a different named state | Prevents a state from running indefinitely on an undefined condition |
| Fail-safe or default behaviour | What the system does outside every named, anticipated condition | Closes the gap a sequence cannot otherwise leave open |
| Narrative version | What it leaves undefined | Explicit equivalent states |
|---|---|---|
| Runs in occupied mode during business hours | Exact schedule times and what happens outside them | Occupied state entered by schedule, with the exact time range and the unoccupied state's own setpoint stated |
| Modulates to maintain comfort | The actual setpoint, deadband, and which sensor governs it | Named setpoint value, deadband, and the specific sensor point the loop reads |
| Stages up when needed | The exact condition and timing that triggers the next stage | Stage two enters when space temperature exceeds setpoint by a stated margin for a stated minimum duration |
| Economizer engages when conditions allow | Which changeover strategy and what threshold defines allowed conditions | Named changeover strategy, dry bulb or enthalpy, with the exact threshold value stated |
Questions people ask about this
Does an explicit sequence take longer to write than a narrative one?
It takes more time at the writing stage, because every state, trigger, and setpoint has to be decided and stated rather than left implicit, but that time is spent once during design rather than repeatedly during installation disputes, commissioning ambiguity, and post-occupancy troubleshooting where an unclear narrative sequence otherwise resurfaces the same undecided questions.
Can an explicit sequence still be readable to someone who is not a controls programmer?
An explicit sequence organised by named state, with each state's trigger and output stated in plain language around the specific values, remains readable to an owner or a reviewer who is not a programmer, since the structure itself, when does this happen and what does the system do, is intuitive even where the individual values are technical. Clarity and specificity are not in tension when the document is organised around named states.
How does an explicit sequence handle a condition the designer did not anticipate?
No sequence anticipates every possible condition, and a well-structured explicit sequence should include a defined default or fail-safe state for conditions outside its named states, so the system has a specified, if conservative, behaviour rather than undefined behaviour when it encounters something the sequence did not explicitly address.
Should setpoints in the sequence be fixed values or ranges?
Either can be appropriate depending on the decision: a value the design has already settled belongs as a fixed number, while a value genuinely intended to be tuned during commissioning belongs as a stated range with the criteria for selecting within it, so the commissioning process has an actual, bounded decision to make rather than an open one the sequence never addressed.
Evidence recordSource verification pending
standards body publication · editorial review
This page is awaiting source verification against the documentation in its evidence record: ASHRAE technical literature. Its documentation class and intended scope are shown here while that check is pending.
- Documentation class
- standards body publication
- Scope of the definition
- Confirm against the exact model manual