Commissioning readiness checklist: prerequisites, test records and open items

Make the readiness decision visible

A system can be installed while the evidence required for its next test is incomplete. The missing item might be a startup record, a prerequisite review or the outcome of an earlier coordination issue. A broad installed status can hide that gap until the commissioning team reaches the scheduled window and cannot identify who owns the next action.

Start with the actual commissioning plan, specifications, approved procedures and designated project roles. Use those sources to identify the required evidence and the person who can make each readiness decision. This article is an administrative tracking framework. It does not provide operating instructions, functional-test steps, acceptance criteria or permission to energize equipment.

WBDG's archived commissioning-documentation guidance emphasizes project-specific documentation, assigned responsibilities and review or acceptance processes. It also describes readiness checklists as records of preparation for testing. Use that as general documentation context, not a substitute for current project requirements or an assertion that an archived standard governs your job.

Sources: WBDG archived guidance: Commissioning Documents, Process, Contents and Acceptance

Choose the asset or system level that supports action

Create a stable asset or system ID and connect it to the current project references. A single equipment item may belong to a larger system whose readiness depends on other work. The register should preserve that relationship rather than let an equipment-level green cell imply readiness of the entire system.

Record the location, responsible contractor, relevant plan or package version and the next milestone being reviewed. Use the project's actual naming structure so the commissioning lead can match the row to the equipment and documents. If two buildings both have a pump called P-2, the building and system references must prevent an accidental match.

Do not use the register to invent an asset list or technical scope. Ask the responsible project team to confirm what belongs in the review and how shared prerequisites are tracked. A common control-related record may support several assets; link it deliberately rather than copying an unresolved status into several rows with no owner.

Translate requirements into specific evidence requests

Each prerequisite needs a source reference, defined deliverable or decision, preparer and reviewer. Startup paperwork missing is more actionable when it identifies the asset, required record and governing package. Avoid asking a contractor for a generic complete commissioning packet when the team cannot specify which component is outstanding.

Keep evidence requirements separate from the technical conclusion the evidence may support. A coordinator may check whether a required file was supplied and can be opened. The designated reviewer determines whether it satisfies the relevant requirement. Record the scope of each check so administrative collection does not appear to be professional acceptance.

When a requirement is unclear or disputed, keep the question and source visible for resolution. Do not invent a universal prerequisite from another project's checklist. The actual team may need to clarify the plan, responsibility or document version before a meaningful request can go out. Assign that clarification rather than repeatedly chasing an undefined item.

Worked example: an installed pump with two missing records

The following asset, plan references and records are fictional. Pump P-2 is recorded as installed in the North building. The project's commissioning register, based on its approved plan revision B, calls for a startup evidence record and a prerequisite controls-check outcome before the designated lead reviews readiness for the stated test milestone. Both records are missing from the submitted packet.

The coordinator records installation evidence as received, startup evidence missing and controls outcome missing. The mechanical contractor owns the startup-record request, and the controls contractor owns its required record. The readiness decision remains open with the commissioning lead. The coordinator does not mark test-ready merely because the equipment is physically present or the installation photo looks complete.

If the two records later arrive, their states become received for review. The designated lead then records the actual review result under the project process. That may include corrections or a readiness decision with a defined scope. The example supplies no technical acceptance criteria and does not claim that receipt alone authorizes operation or testing.

Keep the test packet connected to its basis

A packet should identify the asset or system, milestone, governing plan version, required records and related open issues. Link the actual controlled procedures and supporting documents where the project requires them. Do not replace a controlled procedure with an informal summary that loses its revision or approval status.

Use a contents list to distinguish missing files, superseded versions and records awaiting review. A large attachment count is not a completeness test. The reviewer needs the specific item required by the current package, not several older documents with similar names. Preserve the submission history while making the current review set identifiable.

If a shared prerequisite supports several packets, maintain one authoritative reference and show which assets depend on it. A correction to that record may require rechecking several readiness decisions. The register should expose the relationship so the team can identify the affected scope rather than assume every previous green status still applies.

Make open issues specific enough to resolve

An issue row should identify the asset or system, observation or missing requirement, source, owner, next action and review state. Keep the issue linked to the relevant packet. Avoid using a generic commissioning incomplete note that forces the contractor or lead to rediscover what is actually blocking the next milestone.

Distinguish a reported correction from verified closure. A contractor saying the item is fixed is useful progress information, but the required evidence and review may remain open. Record the response and route it to the designated reviewer. The register should show which decision is still needed rather than automatically close the issue when somebody replies.

WBDG's archived guidance describes issues-and-resolution records as part of commissioning documentation. The useful principle is traceability through the project-specific process. This article does not copy its matrix or prescribe a universal issue hierarchy. Use the actual commissioning team's accepted format and closure responsibilities.

Sources: WBDG archived guidance: Commissioning Documents, Process, Contents and Acceptance

Separate a test booking from readiness

A date on a calendar can reserve people or resources without establishing that every prerequisite is satisfied. Record the planned test window, scheduling owner and readiness decision separately. If a prerequisite is still open, identify who will resolve it and when the scheduling decision must be revisited under the project's process.

When a window moves, preserve the reason and affected records. A reschedule may require updated attendance, access arrangements or packet review. Do not silently carry a prior readiness statement forward if its basis has changed. The designated lead determines what needs rechecking, and the register should retain that instruction and its scope.

Use clear communication about the current state. Planned, confirmed on the schedule, ready under a recorded decision and test completed are different events. The coordination record can connect them, but it should not infer one from another. A completed booking task should not erase an unresolved technical or documentation issue.

Record who accepted what and on which version

The review outcome should identify the reviewer, date, packet or record version and the decision's actual scope. If the reviewer accepts part of the packet and returns another part, preserve both results. A single accepted label can hide a correction needed before a particular test or later handover.

Keep test performance and results in their authorized process. The tracker can link the resulting record and show that review is pending, but it does not determine whether a system passed. Technical criteria, instrumentation, operating conditions and safety controls belong to the qualified project team and approved procedures.

At handover, connect the accepted records and unresolved items to the required closeout or systems-manual structure. A preliminary package may have a different scope from the final accepted record. Use the actual project decisions and requirements to label it accurately, rather than calling every transmitted folder final.

Use the asset-to-prerequisite tracker

The free CSV above includes project, asset or system ID, location, plan version, milestone, prerequisite source, required record, preparer, receipt reference, review state, decision owner, issue reference, next action and test-event record. Use one row per defined prerequisite or clearly related review item, linked through the asset and packet IDs.

Populate P-2 from the example and check that installation does not close startup or controls requirements. Then add the missing files as received. The readiness decision should remain open until the designated review is recorded. That test helps separate collection automation from the technical authority the project retains.

Try a changed packet revision and a shared prerequisite used by two assets. Ask the commissioning lead and coordinator whether the affected records and next owners are clear. If the register cannot show what needs rechecking, improve the links and decision fields before applying it across a larger equipment list.

Reopen the review when the asset or supporting packet changes

Suppose the team replaces the originally listed P-2 after a readiness packet has been reviewed. Keep the earlier packet attached to its original asset identity and revision. Create a linked change record that names the replacement, the source describing the change, the affected packet references and the person asked to assess its effect. Do not silently relabel the earlier startup record as evidence for the replacement.

The coordinator's task is to make that change visible. The designated project lead decides which existing records still apply and what further review is required under the project plan. Until that decision is recorded, display the affected readiness item as awaiting review, even when every expected filename appears in the folder. File presence cannot settle whether the evidence applies to this asset.

At the next meeting, report the change separately from ordinary missing documents. Show the old packet, the new identity reference, the open applicability question and its owner. That gives the qualified team a clear decision to make without the administrative tracker prescribing tests, operating steps or acceptance criteria.

Coordinate missing packet responses with Buildalytic

Buildalytic's custom-workflow page describes requesting information, logging replies, waiting and holding steps for named approvals. Bring a redacted readiness packet or the fictional P-2 example to a demo. Ask how the missing startup record and controls response are routed to different owners and connected to the same asset.

Keep controlled procedures and commissioning decisions in their authorized systems. Review the supported document connections and permissions for your setup. Do not assume a follow-up workflow supplies an engineering review, a test procedure or an automatic readiness certification. The useful demonstration shows where the workflow waits for the designated person.

Start with one packet and one upcoming milestone. Inspect the request, response, review queue and unresolved issue history with the people who will use it. The examples do not promise a passed test, a safe operating condition or an accelerated commissioning outcome; they provide a concrete way to evaluate the administrative handoff.

Sources: Buildalytic custom construction workflows