6.5 Tracking Issues & the Resolution Workflow

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

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.

1. Age the log. Sort by days open. Issues older than the specified correction window are exceptions requiring action, not background noise.
2. 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.
3. Confirm ownership. Every open issue has a named responsible party. Issues with no owner are the ones that survive to closeout.
4. 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.
5. 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

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.