Prepare for the BCxA ACP by studying commissioning as a connected decision chain rather than a list of terms. Trace every phase, test, and document back to the owner's project requirements, practice failure-handling on paper scenarios where you must decide between acting, logging, and deferring, and use a written rubric to check whether you can sequence findings through correction, retest, and closeout without notes.
Why OPR and BOD Get Confused and How to Separate Them
The Owner's Project Requirements state what the building must do and why; the Basis of Design explains how the design team's choices meet those requirements. Separate them by author, timing, and question answered, then practice reassigning statements between the two.
Train the distinction with three questions. Who wrote it: the owner or owner's representative produces the OPR, while the design team produces the BOD. When it exists: OPR content begins before design, and the BOD develops during design in response. What question it answers: the OPR asks what performance the owner expects, and the BOD asks why the selected systems, capacities, and assumptions should deliver it.
A productive exercise is rewriting statements into their correct home. 'Laboratory exhaust must maintain containment at 100 percent redundancy' belongs in the OPR as an owner expectation. 'Redundant fans were selected because a single-failure analysis showed containment loss risk' belongs in the BOD as design reasoning. If you can move a sentence to the correct document and justify the move, you understand the pair. This matters because later commissioning decisions, like what to test and what counts as compliance, are judged against these two documents in different ways.
Verification Versus Functional Performance Testing: What Each One Proves
Verification confirms that components and installations match documents before dynamic testing; functional performance testing exercises systems under operating conditions to demonstrate the sequences work together. Distinguish them by what is static versus dynamic, and by what evidence each leaves.
Verification work is largely static and item-based: checking installed equipment against submittals, confirming safeties are wired and set, completing pre-functional checklists before anything is run. Functional performance testing is dynamic and system-based: starting equipment, forcing operating conditions, and observing whether sequences, interlocks, and responses behave as the design intends. A component can pass every static check and still fail functionally because the sequence logic is wrong, which is why the two activities are sequential, not interchangeable.
In study scenarios, decide which activity a described task belongs to. 'Confirm the outdoor-air damper actuator matches the schedule and strokes fully' is verification. 'Simulate a call for economizer cooling and confirm the damper, fan, and mixed-air controls respond per sequence' is functional testing. Getting this classification right clarifies what evidence must be recorded: verification leaves completed checklists, while testing leaves measured readings under stated conditions. When you review any test description, ask whether the system was running and responding, because that single question resolves most classification confusion.
Worked Scenario: An Air-Handling Unit Fails Functional Testing
When a test result deviates from the design value, the correct sequence is to confirm the measurement itself, document the as-found condition, diagnose the cause, and route the finding through the issues log to a responsible party before any retest.
Scenario: during a labeled worked example, an air handler is tested and the measured supply airflow reads about 12 percent below the stated design value at full-speed fan operation. A plausible mistake here is to immediately adjust the fan speed or setpoint, watch the reading climb, and record a pass. This skips two decisions. First, was the measurement trustworthy: were the flow-measuring instruments calibrated and installed per their requirements? Second, what was the as-found condition, which is the baseline record that later diagnosis and any warranty discussion depend on.
The better decision treats the result as a finding. Record the as-found reading, confirm instrument calibration and placement, and diagnose before changing anything: the cause could be a loaded filter, a duct obstruction, an inaccurate flow sensor, or a genuine capacity shortfall. Enter the finding in the issues log with a responsible party, correct the confirmed cause, retest under the same conditions, and document as-found and as-left values. This matters because an undocumented adjustment erases the evidence trail: nobody can later tell whether the system failed, was fixed, or was simply measured wrong the first time.
How Commissioning Phases Change What You Write and Verify
Across pre-design, design, construction, acceptance, and occupancy phases, the commissioning professional's focus shifts from establishing requirements, to reviewing design intent, to verifying installation, to testing systems, to supporting operation. Map each phase to its dominant deliverable.
Study the phases by their central product. In pre-design work, the OPR is the deliverable and the key activity is helping the owner express measurable expectations. In design, review deliverables check whether the BOD and documents consistently address the OPR. In construction, the work shifts to submittal review, site observation relative to requirements, and pre-functional verification. In acceptance, functional performance testing dominates, and in occupancy the emphasis moves to training verification, the systems manual, and deferred items. Each phase inherits unresolved items from the previous one, which is why the issues log persists across all of them.
A useful self-test is to take any commissioning activity and place it in a phase plus name its deliverable. 'Reviewing the sequence of operations for consistency with the OPR' is design-phase review producing comments. 'Witnessing start-up and completing pre-functional checklists' is construction-phase verification. 'Confirming operators received training and can demonstrate sequences' is occupancy-phase work supporting closeout. If an activity seems to belong to two phases, that usually signals a genuine transition point, such as functional testing that begins during construction commissioning of early systems, and you should be able to say what changes at the boundary.
Worked Scenario: Scheduling Seasonal Testing When the Weather Will Not Cooperate
When a test requires conditions the current season cannot provide, the disciplined response is documented deferral: record what was completed, what remains, the reason, and the agreed plan, rather than forcing an unrepresentative test or silently dropping the item.
Scenario: a labeled worked example calls for a chilled-water plant test at a near-peak cooling load, but the test window arrives during mild weather and the load cannot be produced naturally. The plausible mistake is either to mark the test complete based on a low-load observation that does not exercise the design condition, or to let the item quietly disappear as the project closes out. Both produce the same hidden risk: an unverified design condition that nobody tracks.
The better decision is explicit deferral management. Complete everything in the test protocol that does not depend on the seasonal load, and record those partial results. Document the deferred portion in the issues log or commissioning plan with the reason, the conditions required to execute it, the responsible parties, and an agreed schedule, such as the next cooling season. This matters because the entire value of the record depends on open items staying visible: a documented deferral with an owner and a date is a planned verification, while an undocumented one is an unknown gap that surfaces only as an operating problem after occupancy.
Which Commissioning Document Answers Which Question
Each core commissioning document exists to answer a distinct question for a distinct audience. Compare them by the question answered, when they are created and updated, and what a reviewer looks for in each.
Use the table below as a recall aid, then test yourself in the opposite direction: pick a project situation, such as a change to an owner expectation or an open deficiency near completion, and identify which document must change and who maintains it. If an owner refines an expectation mid-design, the OPR updates and design documents may need follow-up. If testing finds a deficiency, the issues log carries it forward. A situation that touches several documents at once is normal, and knowing the primary home of each item is what keeps the record coherent.
A second study use for the table is spotting inconsistent scenarios. If a practice scenario claims a finding was 'closed out' but names no responsible party or retest, the issues-log row tells you what is missing. If a scenario describes testing against criteria that appear nowhere in the OPR or design documents, the criteria themselves are the problem. Practicing this critique turns document knowledge into decision-making rather than recognition.
| Document | Question it answers | Created and updated | What a reviewer checks |
|---|---|---|---|
| Owner's Project Requirements (OPR) | What must the building do, and to what standard? | Begins in pre-design; refined as owner expectations clarify | Are expectations specific, measurable, and traceable into design documents? |
| Basis of Design (BOD) | How do the design choices meet the OPR? | Developed during design by the design team | Do assumptions and selections actually address each stated requirement? |
| Commissioning Plan | How will commissioning be executed for this project? | Established early; revised as scope and schedule evolve | Are scope, roles, test approach, and deferral handling defined? |
| Issues Log | What is open, who owns it, and what is its status? | Maintained continuously through delivery and closeout | Does every finding have a responsible party, resolution, and closure evidence? |
| Systems Manual | How is the building operated and maintained as built? | Assembled near completion from prior phase records | Do operating information, sequences, and test results match the delivered systems? |
A Preparation Sequence With Readiness Checks and a Scoring Rubric
Study in passes that mirror the process itself: requirements and documents first, then verification and testing, then failure handling, then closeout, finishing with mixed timed scenarios. Use a written exercise and rubric to confirm readiness rather than a feeling of familiarity.
A realistic adaptable sequence: Pass one, map the process, writing each phase with its dominant deliverable and the documents produced or updated. Pass two, drill the verification versus functional testing distinction with classification exercises. Pass three, work failure-handling scenarios on paper, forcing a decision at every deviation: measure, log, correct, defer, or retest. Pass four, cover closeout: training, systems manual, deferred-item tracking. Pass five, mix timed scenario questions and use flashcards only for vocabulary that still trips you. Adjust the time per pass to your schedule and prior experience with building systems.
Practical exercise with expected observations: on paper, write a five-part functional test for a simple single system, such as one exhaust fan: pre-checks and prerequisites, test conditions, measurements with expected values, failure-handling steps, and documentation fields. Expected observations when you do this honestly: you will realize you must specify that instruments be calibrated, name who witnesses and who records, and add as-found and as-left fields, because without those the test cannot produce defensible evidence. Score yourself 0 to 2 on each part: prerequisites stated, conditions explicit, expected values traceable to stated requirements, failure path defined, documentation complete. A total of 8 or higher out of 10, achieved without notes, is a learning milestone indicating the underlying logic is in place; it is a self-check, not a prediction of any exam outcome.
Readiness checks before you consider preparation complete: you can state the OPR and BOD difference in two sentences without notes; you can classify a described activity as verification or functional testing and explain why; you can take a deviation through finding, log entry, correction, retest, and closure naming the responsible parties; you can explain what a documented deferral must contain; and you can pick any scenario statement and name the document it should be judged against. Any check you cannot pass tells you which pass of the sequence to repeat.
References and further reading
Use these references to explore the concepts and check the latest information from the relevant organizations.