Follow one HVAC system through its equipment schedule, control diagram, points list, sequence, and controls specification. Resolve missing devices, inconsistent modes, and unclear interfaces before using the documents as a basis for programming or functional testing.
Assemble the review package
Gather mechanical schedules, system schematics, sequences of operation, available points lists, and the issued controls specification. Include electrical power and relevant specialist-system interfaces. Mark what is design intent and what is a later proposed controls submission, so the review does not confuse a vendor proposal with an approved change.
WBDG publishes UFGS 23 09 23.02: BACnet Direct Digital Control for HVAC and Other Building Control Systems as a public guide-specification reference (accessed September 16, 2026). Use your project’s issued specification and amendments for the actual comparison; the guide specification does not automatically govern your project. The checklist below is an original suggested review workflow, not a reproduction of the UFGS requirements.
Eight checks to run against the issued set
Use one record per location or system. The CSV contains the same eight prompts plus fields for source revisions, observed evidence, the review owner, the decision, and closure references.
| Check | Sources to compare | Question to resolve |
|---|---|---|
| Equipment identity | Schedule tags + sequence and schematic | Do all references describe the same system and equipment quantity? Resolve renamed or standby units before comparing behavior. |
| Operating modes | Sequence + controls requirements | Are the specified modes explained for this system, including the conditions that enter and leave each mode? Record contradictions without writing a replacement sequence. |
| Inputs | Sequence statements + sensor and points information | Does each described decision have an identifiable input or source? Ask how the system obtains information absent from the device list. |
| Outputs | Sequence actions + actuators and control diagram | Can each commanded action be tied to the intended device? Distinguish a monitoring point from a command or physical output. |
| Interfaces | System boundary + electrical and specialist documents | Are handoffs, signals, and responsibilities documented at equipment and system interfaces? Assign unresolved interface questions to the relevant designers. |
| Alarms and failure behavior | Alarm requirements + sequence | Do the stated alarm conditions and failure responses refer to available information and defined equipment states? |
| Naming and integration | Controls clauses + points and integration information | Is the proposed mapping traceable to the specified integration requirements? A protocol name alone does not explain the required information exchange. |
| Functional verification | Sequence + testing and trend requirements | Can the intended test be related to a stated operating condition and observable result? Flag missing acceptance references for the project team. |
Worked example: a sequence refers to a missing measurement
Illustrative example: a sequence changes the system’s operation based on a measured condition, but the control diagram and available points list do not identify a source for that measurement. The controls specification requests functional testing, yet the package does not explain how the triggering condition will be observed.
Record the exact sequence step and the corresponding diagram and points-list references. Ask whether the input is provided by a local sensor, another system, or an omitted device, and have the design team coordinate the answer into the test basis. The published equipment-consistency finding shows why operating information should be reconciled with tags and schedules.
See the published equipment and sequence finding. The illustrative scenario above is separate from that published finding.
Avoid a false conflict
A point can exist without having the behavior assumed by the sequence. Conversely, an input may be available through an interface that is documented elsewhere. Search the complete references before declaring a device missing; keep safety-related decisions with the responsible designers.
When requirements disagree, follow the project’s document-control and clarification process. Do not assume that drawings always override specifications, or the reverse. Identify the exact sources and request an authorized decision.
Close the issue across the affected documents
Record the location or tag, drawing and specification references, issue dates, observed difference, and the decision needed. Assign an owner and keep the item open until the response identifies the governing requirement. Check the revised drawings and specification references together; a response email alone may leave the issued package inconsistent.
For the overall process, use the guide to drawing and specification conflicts. Mark an inapplicable checklist row with a reason, and distinguish a verified correction from a question that still needs design information.
Where Groundbook fits
Groundbook’s drawing and specification review helps investigate potential disagreements in the documents you supply. Include the relevant specification sections and drawing references, then verify the cited evidence with the responsible reviewers before acting on a finding.