When a Review Comment Changes the Work

Picture a fictional panel package that comes back Approved as Noted. Comment 9 says “provide redundant power supplies with diode OR-ing module.” The spec and one-line show one supply. But the comment is in the engineer's handwriting, the panel shop needs to keep moving, and someone adds the second supply, module and extra DIN rail before asking who pays for them. The question that could have been settled first is now sitting inside a built panel.

The useful habit is simple: ask whether each comment corrects the package, clarifies an existing requirement or changes the work.

Comments that add scope

Most comments are corrections. The datasheet is unmarked, the wire numbers are missing, the enclosure rating is wrong against Part 2. You comply and move on; that obligation is covered in what Approved as Noted actually requires.

A few comments ask for something the package team cannot trace to the contract documents. They tend to look like these:

• A feature with no paragraph behind it. Redundant supplies, an extra communication port, a larger HMI, a UPS, a second Ethernet switch. If neither the section nor the drawings appear to call for it, flag the comment for scope review.
• A higher grade than specified. Stainless where the spec allows painted steel, a ten-year warranty where the spec says manufacturer's standard, NEMA 4X where the drawings show an indoor NEMA 12 panel.
• Coordination you were not scoped for. Interfacing to a package system another contractor supplies, adding I/O for equipment not on the I/O list, terminating the generator control that Division 26 owns.
• Work reaching outside the submittal. A comment on the panel drawings that requires a conduit rerouted, a field instrument relocated, or another trade's drawing changed.
• A quantity change. "Provide spare I/O of 25 percent" when the spec said 20, or a spare parts list the spec located in a different section with different quantities.

Each may be a perfectly reasonable engineering request. Reasonable is not the test. The next question is how the executed contract says that request becomes authorized work.

The test: is it in the contract documents

Start with the executed agreement, conditions, drawings, specifications, addenda and modifications for your project. They define the contract documents, the purpose and limits of submittal review, who may direct a change, and which written instrument changes cost or time. A handwritten note on a returned PDF does not answer those questions by itself.

For every scope-shaped comment, ask: can I point to the paragraph, drawing or prior modification that already requires this? If yes, the comment may be correcting the package. If no, or if the documents conflict, route it to the person responsible for contract review instead of deciding from the stamp alone.

If someone cites a "reasonably inferable" clause, read the actual clause and the surrounding documents. Whether an item is included can turn on project-specific language and facts. A change in function, cost, time or another trade's work is a good reason to stop and get that reading documented.

Some project documents require prompt written notice when a contractor considers a review comment to be a change. Find the notice clause, recipient, delivery method and deadline for your project. A response-log note is useful evidence, but it may not satisfy the formal notice requirement by itself.

Ask before the work outruns the question

The order matters: trace the requirement and use the notice path before affected work outruns the question. Notice windows vary, and missing one can affect rights. Use the period and method in the executed documents rather than a generic number from another contract.

Practically, on the day the return comes in:

1. Walk every comment and sort it: correction, clarification, or possible change. This is the same pass that builds the comment response log.
2. For each possible change, identify the affected work and ask the authorized project lead what may continue safely while the question is open.
3. Send notice through the contract's required channel and deadline. Use the response log to connect the comment to that notice.

The response log row can read "pending scope review," with the paragraph reference and the number of the separate notice, RFI or proposal. That makes the trail visible without claiming the log itself is formal notice.

The RFI that confirms it

If the project's RFI procedure is the right channel, use it to ask how the documents should be read. The question can be short: comment 9 on submittal 40 61 13-002 Rev 0 requests redundant power supplies; section 40 61 13 paragraph 2.06 and drawing E-4 appear to show one; please clarify the requirement and how the added equipment should be authorized. Attach the marked-up return. An RFI clarifies the issue; it does not replace any separate notice or change authorization the contract requires.

Three outcomes, all better than silence:

• The engineer withdraws the comment. What looked like a requirement was a preference, and the owner declines when asked to put a number on it.
• The engineer confirms the added requirement. Follow the project's change process for price, time and authorization instead of relying on the margin note alone.
• The engineer cites a paragraph you missed. Then it was a correction after all, and you learned it for one RFI instead of at closeout.

The judgment of when a question beats an interpretation is in submittal versus RFI. A comment with cost or time impact that cannot be traced to the documents deserves prompt review through the project's approved channel.

Pricing and schedule impact

Price the whole ripple, not the part. A second power supply is a part number. The change is the part, the OR-ing module, the DIN rail and wire, the drawing revision across three sheets, the added terminals, the resubmittal cycle if the engineer wants to see the revised layout, and the days the panel waited for the answer. Every one of those belongs on the change proposal, itemized, because the reviewer who asked for "just a second supply" is the same person who will review the price.

Schedule may be part of the impact. If the question affects fabrication, keep dates: comment received, notice or RFI issued, answer received, authorization received and work resumed. Use the contract's method for presenting any time effect.

Submit the proposal through the project's change process and follow written direction from someone authorized under the contract. Different forms handle disputed work, directives and interim instructions differently, so get project-specific guidance before proceeding or stopping affected work.

Logging the change order against the revision

When the change is approved, close the loop in the record:

• The response log row moves from "disputed" to "complied per CO-007," so the next reviewer sees the comment was honored and how.
• The resubmittal shows the change, clouded, with the revision block citing the change order, so the revised work and its review stay connected.
• The change order log entry cites the submittal number, the revision, the comment number, and the RFI. Two years from now, the question "why does this panel have two supplies" resolves in one lookup from any of the four records.
• The change flows to the equipment list, the O&M manual, and the as-builts, which will be wrong if it only lives in the change order.

A change order that cannot be traced back to the review comment that caused it is a change order someone will eventually dispute. Tie them together the day it is approved.

One example

This fictional example shows the record trail. A panel package for a water plant returns Approved as Noted with fourteen comments. Twelve trace back to the documents. Two need scope review:

Comment 12 closes with one clarification. Comment 9 continues through the fictional project's RFI and change process before the revised work is released. Same returned submittal, two very different answers, and a record that shows why.

How Submittal Kit handles this

A comment that should have been a change order gets absorbed because its trail lives in four places nobody connects. In Submittal Kit the comment, the RFI, and the change order sit on one project. Each comment is a row in the submittal's Comment Response Log, where the disputed or pending response you write prints in the resubmittal, and the full item carries references to RFIs and revisions. The RFI goes out with the next number and a frozen PDF, and its answer is marked Changes the work when it does. The change order log records each change with its status, dollar amount, and the RFI it grew out of, and an approved change can be allocated to budget lines and added to the SOV so you can bill it.

Disclosure: I build Submittal Kit, and the habit of asking "which paragraph" works on paper.