# Functional Performance Tests: What the Commissioning Agent Needs From Controls

What a commissioning agent expects from controls, from prefunctional checklists to trend data and issue log answers, when each is due, and how to avoid failing on paperwork.

The commissioning agent's issue log has forty open items against controls. You read through it and maybe six are about the system. The rest say some version of "documentation not received": prefunctional checklists for three air handlers, the point-to-point for the chiller plant, trend logs that were never set up, a sequence that doesn't match what was programmed. The building runs fine. On paper, controls is the trade holding up commissioning, and the GC's weekly meeting treats it that way.

Commissioning is a verification process, and verification runs on evidence. This article lists what the CxA needs from the integrator, roughly when, and the paperwork failures that make a working system fail its tests.

## What the CxA is actually checking

The commissioning agent verifies that the systems meet the owner's project requirements and the design. They do not do your startup, write your program, or check out your points. They check that you did, and they check it from your records and by watching the system perform. ASHRAE Guideline 0 describes the commissioning process most specs build on, and the requirements usually live in Division 01 at 01 91 13 General Commissioning Requirements, with trade-specific sections such as 23 08 00 for HVAC and, on some jobs, 25 08 00 for integrated automation. The commissioning plan the CxA issues early in construction turns those sections into a schedule of deliverables.

Read the plan as soon as it is issued. It names the forms, the systems, the sampling rate for tests, and who must attend what. It is the closest thing you will get to an answer key.

## The deliverables, in order

Each deliverable has a natural moment. Miss the moment and it turns into reconstruction.

| Deliverable | When it is due | What it proves |
|---|---|---|
| Controls submittal, copied to the CxA | Design review | The design intent can be verified against what you will build |
| Sequence of operations as programmed | Before FPT scripts are written | The CxA tests the sequence you actually wrote |
| Prefunctional checklists | During installation and startup | Each piece of equipment is installed and ready |
| Point-to-point checkout records | After termination, before FPT | Every point works from device to graphic |
| Trend logs configured and exported | Ahead of FPT, for the period the plan sets | The sequence holds over time, not just while someone watches |
| FPT participation | Test days | The system performs every mode the sequence describes |
| Issue log responses | Continuous | Each finding has a cause, an action, and a date |
| Systems manual and training input | Closeout | The owner can operate what was verified |

The exact names change between specs. Prefunctional checklists are often called construction checklists, and FPTs may be called functional tests or system performance tests. The order rarely changes.

## Prefunctional checklists

These are the CxA's forms, filled out by the installing contractors, confirming that each piece of equipment is installed, powered, and ready for functional testing. Controls usually owns lines on many of them: sensors installed and located per drawings, wiring terminated, the controller online, points mapped. On a large job a single air handler checklist can involve the mechanical, electrical, and controls contractors.

Fill your lines as the work happens, not in a batch at the end. A checklist completed the week of the FPT is a checklist the CxA reasonably doubts, and a missing checklist usually means the FPT for that unit does not get scheduled at all.

## Point-to-point checkout

The point-to-point record shows every point verified end to end: the field device, the controller input or output, the value in the BAS, and the graphic. For inputs, the check compares the BAS value with a reference reading. For outputs, it commands the device and confirms the response at the device. The method is the same I/O checkout a panel gets at site acceptance, described in [FAT and SAT for control panels](/learn/fat-and-sat-for-control-panels), and the sheet should look like it: one row per point, expected and observed values, pass or fail, initials, and date.

Use the points list you submitted as the row source. If the record carries points that are not on the approved [BACnet points list](/learn/bacnet-points-list-and-pics), or misses points that are, expect an issue log item for each.

## Trend data

Trends let the CxA see whether a sequence behaves over days rather than during one witnessed hour: whether the economizer actually modulates, whether the static pressure reset ever resets, whether a valve hunts overnight. The commissioning plan or the spec sets which points to trend, at what interval, and for how long. Check both.

Set the trends up early, as soon as the points are online and the sequence is loaded. Confirm the controller or server has the storage for the interval and duration requested, because a trend log that silently overwrote itself after two days is a retest. Agree on the export format with the CxA before the first export, and label every file with the system, the date range, and the program version running at the time.

## FPT participation

The CxA usually writes the functional test scripts from the sequence of operations. You operate the BAS during the test: overriding points, changing setpoints, simulating failures, and putting things back. Three habits make test day short.

1. **Review the scripts before test day.** Compare each step with the sequence as programmed. If the script tests a mode your program handles differently because of an approved change, raise it now with the change document attached. A clear, unambiguous [sequence of operations](/learn/sequence-of-operations) is what prevents this, and it is a lot cheaper to fix at submittal than at FPT.
2. **Run the test yourself first.** Walk the script with your own tech a few days ahead. Every failure you find is one the CxA doesn't log.
3. **Release every override.** Before you leave the test, return every point you touched to automatic. An override left in hand is the classic way to pass the FPT and fail the trend review a week later.

## The issue log

Every finding goes on the CxA's issue log, and every item needs a written response from the responsible party: the cause, the corrective action, the date it was done, and a statement that it is ready for re-verification. Respond on the log itself or in the format the plan requires, not in a side email that never makes it back to the log.

Disagree on the log too. If an item is a design question rather than an installation defect, say so with the reference, and let the CxA route it to the engineer. Some specs charge the contractor for retesting after a failed test, so check yours; a quick written response is cheaper than a second test day.

## Failing on paperwork

Failed or rescheduled FPTs on the controls side often come down to a short list of avoidable gaps:

- Prefunctional checklists not returned, so the unit was not ready to test.
- The sequence in the submittal does not match the program, so the script tests the wrong thing.
- Point-to-point records missing for points the test depends on.
- Trends not configured, too short, or exported without labels.
- Graphics missing points the script expects the operator to see.
- Calibration records for critical sensors not on file.
- Issue log items closed in conversation but still open on the log.

Each item is cheap to finish when the work happens and expensive to recover weeks later. The broader list of what closeout needs, and when each item should start, is in [closeout checklist for a control system project](/learn/control-system-closeout-checklist).

## How Submittal Kit handles this

The pain is a commissioning issue log that grows with paperwork items while your own tracking lives in three spreadsheets. Submittal Kit has no commissioning module, but its [punch list](/help/punch-lists) handles the tracking: each CxA finding becomes a numbered item with a source, owner, severity, and your response, and **They raised it again** starts a new round when an item comes back. An existing log comes in through import, and a Punch List for Record freezes the status at each milestone and exports to XLSX. Upload the spec book and [claim the commissioning sections](/help/upload-specifications) so every deliverable they demand is answered beside the section text and counted on the [Submittal Log](/features/submittal-log) instead of found at closeout.

*Disclosure: I build Submittal Kit. The deliverables and their timing are set by your spec and the commissioning plan, whatever you track them in.*

---
Submittal Kit · Field Guides · Updated 2026-10-04
Canonical: https://submittalkit.com/learn/commissioning-functional-performance-tests