ExamFinch.com My Study

Study guide

6.5 Tracking Issues & the Resolution Workflow

Practice this exam

ASHRAE Building Commissioning Professional BCxP

Track your progress as you read

Finished sections get a check mark.

1 Introduction & Exam Overview

About the ASHRAE BCxP Certification Exam & the October 2026 Blueprint Change BCxP Blueprint, Domain Weighting & Study Strategy Core Commissioning Standards, Guidelines & Codes for the BCxP

2 Chapter 1: Commissioning Scope, Roles, Team & Budget

1.1 Commissioning Scope & Project Initiation 1.2 Commissioning Team Organization & Stakeholder Roles 1.3 Commissioning Budget, Resource Allocation & Value Engineering

3 Chapter 2: Project Management, Communication & Risk

2.1 Commissioning Schedule & Construction Coordination 2.2 Commissioning Meetings, Protocols & Communication 2.3 Risk Management, Conflict Resolution & Issue Escalation 2.4 Project Meetings, Preinstallation Conferences & Verifying Scope Obligations

4 Chapter 3: Foundational Criteria: OPR, CFR & Basis of Design

3.1 Owner's Project Requirements (OPR) Development 3.2 Basis of Design (BOD) & Current Facility Requirements (CFR) 3.3 Commissioning Specifications & Contract Requirements

5 Chapter 4: Commissioning Plans, Reviews & Process Records

4.1 The Commissioning Plan Lifecycle 4.2 Design Phase & Submittal Review Protocols 4.3 Process Tracking: Checklists, Issues Log, Systems Manual & Final Report 4.4 Defining Building Systems in Scope & the Commissioned Equipment List 4.5 Documenting Commissioning Meetings, Minutes & Records Control

6 Chapter 5: Construction Verification & Startup Readiness

5.1 Construction Site Observations & Material Verification 5.2 Pre-functional Checklists (PFC) & Equipment Startup 5.3 TAB Verification & BAS Calibration Verification 5.4 Managing Commissioning Activities Across All Project Phases

7 Chapter 6: Functional Performance Testing & Systems Integration

6.1 Functional Performance Test (FPT) Design & Scripting 6.2 HVAC & Mechanical System Functional Testing 6.3 Electrical, Emergency Power & Life Safety Integration 6.4 BAS Trend Log Analysis & Retesting Protocols 6.5 Tracking Issues & the Resolution Workflow

8 Chapter 7: Closeout Support: Training, Third-Party Documentation & Turnover

7.1 Training Plan Development & Training Needs Assessment 7.2 Training Execution, Video Documentation & Effectiveness Evaluation 7.3 Third-Party Testing Documentation & Contractor Turnover Package Review

9 Chapter 8: Post-Occupancy Operation & Warranty Phase Activities

8.1 Seasonal & Deferred Testing 8.2 End-of-Warranty Review, Trend Monitoring & Closeout

10 Chapter 9: EBCx Planning, Investigation & Facility Assessment

9.1 EBCx Process Fundamentals, Goals & CFR 9.2 Historical Data Collection, Utility Benchmarking & Operator Interviews 9.3 Detailed Field Investigation, Data Logging & Diagnostic Testing 9.4 Establishing EBCx Scope & Preparing the EBCx Plan

11 Chapter 10: EBCx Measure Selection, Implementation & Verification

10.1 Identification & Screening of Operational / Low-Cost ECMs 10.2 Energy Savings Calculation & Financial Life-Cycle Analysis 10.3 Implementation Oversight & Post-Implementation Verification 10.4 Final EBCx Reporting, Handover & Systems Manual Update 10.5 EBCx Training & Operator Knowledge Transfer

12 Chapter 11: Ongoing Commissioning & Monitoring-Based Persistence

11.1 Ongoing Commissioning Framework & Monitoring Plans 11.2 Automated Fault Detection and Diagnostics (AFDD) & Analytics 11.3 Performance Tracking, KPIs & Long-Term Persistence 11.4 Ongoing Commissioning Reporting & Stakeholder Communication

6.5 Tracking Issues & the Resolution Workflow

Key Takeaways Explain This Topic AI

Tracking issues and the resolution log is a Domain 3 task worth 5 questions, tied with witnessing test procedures as the heaviest single task in that domain and assessed separately from creating the log in Domain 2.

CORRECTED and VERIFIED are distinct states: a contractor asserting a fix moves an issue to corrected, but only the commissioning provider's observation or retest moves it to verified and permits closure.

An issue arising from a failed functional test can only be closed by a retest of the affected sequence, not by a photograph, letter, or verbal assurance.

Root-cause category distribution and retest failure rate are the two tracking metrics that change project behavior, because they expose systemic causes and cosmetic corrections rather than raw counts.

Accepted as-is is a formal owner decision recorded with signature and date after the owner is told the deficiency and its operational cost; issues must never disappear silently between log revisions.

Last updated: September 2026

6.5 Tracking Issues & the Resolution Workflow

Quick Summary: The blueprint separates creating the issues log (Domain 2, 3 questions) from tracking issues and the resolution log (Domain 3, 5 questions). Section 4.3 covered the log's structure and required fields; this section covers what the commissioning provider does with it every week for the life of the project. At 5 questions, tracking is tied with witnessing test procedures as the heaviest single task in Domain 3. The exam tests it through closure-evidence scenarios: when may an issue be closed, who may close it, and what happens to issues nobody will own.

1. The Issue Lifecycle

An issue moves through defined states, and the provider controls the transitions: IDENTIFIED -> ASSIGNED -> IN PROGRESS -> CORRECTED (contractor asserts) ->

  • VERIFIED (CxP confirms) -> CLOSED
  • |
  • or -> DISPUTED -> ESCALATED -> RESOLVED
  • |
  • or -> DEFERRED (trigger + owner acceptance)
  • |
  • or -> ACCEPTED AS-IS (owner signs off on the risk)

The state that matters most is CORRECTED versus VERIFIED . A contractor asserting that an item is fixed moves it to CORRECTED. Only the commissioning provider, having observed the corrected condition or retested it, moves it to VERIFIED. Collapsing those two states — closing on a contractor's assertion — is the most common failure in commissioning issue management and a reliable exam distractor.

Evidence Standards for Closure

  • Issue type Evidence required to close
  • Physical installation defect Photograph of the corrected condition, or field observation with date
  • Sequence or programming defect Retest of the affected sequence , plus a trend log confirming stable operation
  • Calibration error Post-correction field comparison against a calibrated reference
  • Documentation deficiency Receipt and review of the corrected document
  • Performance shortfall Re-executed test with recorded values meeting the acceptance criterion

Rule: an issue arising from a failed functional test can only be closed by a retest . Not by a photograph, not by a contractor's letter, and not by a verbal assurance in a meeting. If the sequence failed, the sequence must be run again.

2. Weekly Triage: What the Provider Actually Does

Managing an issues log is a weekly discipline, not an end-of-project activity.

Age the log. Sort by days open. Issues older than the specified correction window are exceptions requiring action, not background noise.

Sort by severity, then by schedule impact. A severity-1 life-safety item outranks everything. Below that, prioritize issues blocking downstream tests, because an unresolved blocker multiplies into idle testing days.

Confirm ownership. Every open issue has a named responsible party. Issues with no owner are the ones that survive to closeout.

Check for orphans and duplicates. The same defect reported by three parties should be one issue with three references, not three issues that close independently.

Publish the exception report. A short list of overdue, disputed, and unowned issues, distributed to the owner and construction manager. This is the mechanism that makes the log matter.

Tracking Metrics That Actually Inform

  • Metric What it reveals
  • Open issues by severity Immediate risk posture
  • Mean age of open issues Whether the correction process is functioning
  • Issues opened vs. closed per week Whether the project is converging or diverging
  • Open issues by responsible party Which contractor is the bottleneck
  • Issues by root-cause category (design / installation / controls / documentation) Where the systemic problem is
  • Retest failure rate Whether corrections are real or cosmetic

The last two are the ones that change project behavior. A root-cause distribution showing 60% controls-programming issues tells the owner that the controls contractor needs more supervision far more persuasively than a raw count. A rising retest failure rate says corrections are being asserted without being made.

3. Disputed Attribution: The Hard Cases

Issues stall when nobody accepts responsibility. The typical dispute: a coil cannot reach its leaving-air setpoint. The mechanical contractor says the coil matches the submittal. The controls contractor says the valve responds correctly. The engineer says the design is adequate.

The provider's role in a dispute is narrow and specific :

Report the observed condition against the documented criterion , with data. Not opinion, not blame.

Isolate variables to narrow the cause: verify entering conditions, verify flow, verify valve position against command, verify the sensor.

Do not adjudicate contract responsibility. Assigning financial responsibility between contracting parties is an owner and construction manager decision.

Escalate on a defined trigger — an issue disputed beyond the specified correction window goes up, with the data package, rather than circulating indefinitely.

Exam pattern: in a disputed-attribution scenario the correct answer gathers and presents objective data and escalates through the defined path. Answers where the provider assigns fault, directs a contractor to perform work, or performs the diagnostic repair are wrong.

4. Closing the Log

At each project milestone the log must be dispositioned — never simply abandoned.

Before substantial completion: all severity-1 and code-required items closed and verified. Remaining items are individually dispositioned as open with a date, deferred with a trigger, or accepted as-is with written owner sign-off.

In the final commissioning report: the complete log is included, with a summary of totals opened, closed, deferred, and accepted as-is. An owner reading the report must be able to see exactly what remains outstanding on the day they take the building.

Into the warranty period: open and deferred items carry forward into the warranty punch list and are reviewed at the end-of-warranty meeting.

"Accepted as-is" is a formal owner decision, not a provider convenience. It means the owner has been told what the deficiency is, what it will cost operationally, and has chosen to accept it. It is recorded with the owner's signature and date. An issue that quietly disappears from a log between two report revisions is a governance failure that will surface as an operational complaint after occupancy — with no record of who decided to let it go.