Answering Review Comments on a Resubmittal

Rev 1 came back Revise and Resubmit with thirty comments. The team fixes what it agrees with, quietly ignores two comments it thinks are wrong, changes a part while they're in there, and sends Rev 2 with a fresh transmittal. Rev 2 comes back Revise and Resubmit: "comment 14 not addressed," "comment 22 not addressed," and a new comment asking why the relay changed. That second cycle was avoidable. The cure is a discipline written into many submittal procedures and skipped by busy teams.

Read every comment, then count them

Comments arrive in three places: the stamp page, the margins of the returned PDF, and sometimes a separate comment sheet where the engineer compiled the owner's remarks alongside their own. Someone whose job it is pages through the whole return, every page, and writes down every comment as a numbered item. Not the ones that look important. All of them. A comment on page 47 that nobody transcribed is the comment Rev 2 bounces on.

The count is the deliverable of this step. "Thirty-one comments on Rev 1" is a fact the resubmittal will be checked against, by you before it goes out and by the engineer after.

One row per comment

The response log is a table with one row per comment, and its columns are fixed: item number, where the comment was (page or sheet), the comment in the reviewer's words, your response, and the status. The reviewer's words go in verbatim; paraphrasing a comment is how a response ends up answering a different question than the one asked.

Number the rows in the order the comments appear in the return, and never renumber. The engineer will refer to "comment 14" in the next round, and so will you.

This log is not an internal tracking sheet. It goes in the resubmittal as its own section, usually right after the transmittal. A reviewer opening Rev 2 wants to see, before anything else, that every comment on Rev 1 was received and what was done about it. The log is that proof, and it converts the engineer's review of Rev 2 from a re-read of the whole package into a walk down thirty-one rows.

The three response types

Every row gets one of three responses, and the word matters.

Complied. You did what the comment asked. Say where: "Complied. Sheet E03 revised, wire numbers added to terminal strip TB2." A bare "complied" forces the reviewer to hunt for the change, and a reviewer who cannot find it marks the comment unaddressed.

Clarified. The comment rests on a misreading, or the package already contained what was asked for, or the requested item is not applicable to this scope. Explain, with a reference: "Clarified. The 24 VDC supply is rated 10 A; see datasheet page 2, highlighted. No change." Clarified is legitimate and common. It is also the response most often abused as a polite way of not complying, so back every one with a reference the reviewer can check in ten seconds.

Disputed. You are not going to do it, and you are saying so. Either the comment contradicts the contract documents, or it asks for something the contract does not include. State which, cite the paragraph, and say what you propose. A disputed comment left silent is not a dispute; it is an unaddressed comment and the package bounces. Some project documents require separate formal notice when you believe a correction changes the work. The response log keeps the issue visible, but it may not satisfy that notice clause by itself. Read the project's procedure and send notice through the required channel. The follow-through is covered in when a review comment changes the work.

What a stamp obligates you to do in the first place, before any of this, is in what Approved as Noted actually requires.

What changes between revisions

A resubmittal changes only what the comments require, plus anything you must change for reasons you state. That second category is the one that generates the "why did the relay change" comment.

The rule appears in spec after spec in nearly the same words: on resubmittals, direct specific attention, in writing or on the resubmitted drawings, to revisions other than the corrections requested by the engineer on previous submissions. The engineer reviewed Rev 1 in full and intends to review Rev 2 against the comments. Any change outside the comments is one they did not ask for and may not look for. Do not assume approval of Rev 2 covers a change you never identified.

So the resubmittal carries a second list after the response log: changes not driven by a comment, each with a reason. "Relay K7 changed from model A to model B: model A discontinued by manufacturer, replacement is form-fit-function equivalent, datasheet attached." Now it is on the record and reviewed.

Mark the changes on the drawings too. Revision clouds and a revision block entry per sheet are the drawing-side version of the same rule, and a reviewer comparing Rev 1 to Rev 2 sheet by sheet is doing it because you didn't cloud.

When a comment needs an RFI first

Some comments cannot be answered by any of the three responses, because the answer depends on a decision that is not yours to make. The comment asks for a feature the spec's Part 2 forbids. The comment conflicts with the drawings. Two comments contradict each other. Resolving that by picking the reading you prefer and marking the row "complied" plants the contradiction in the approved record.

The right move is to write the RFI, and to answer the row "Pending RFI-0xx, issued on such date; will comply per response." If review timing allows, hold the resubmittal for the answer. If it doesn't, send Rev 2 with the row marked pending, so the engineer sees the question is in their court. The judgment call of when to ask is covered in submittal versus RFI.

The resubmittal transmittal

Rev 2 goes out under its own transmittal, and three things distinguish it from the first one:

1. It is marked as a resubmittal, with the original number and the suffix the spec requires (Rev 1, or a letter). Most Division 01 sections require both the marking and the suffix.
2. It names the return it answers, by date, and states the comment count and the response summary: "answers 31 comments returned on such date; 27 complied, 3 clarified, 1 disputed, see response log."
3. It lists what is enclosed and what is unchanged. Some engineers want the complete package again; others want only the revised sheets. The spec's resubmittal paragraph says which. One conformed spec I hold distinguishes a full resubmittal (after Revise and Resubmit) from a partial one (after a "corrected, confirm" disposition), and charges the owner's review costs back to the contractor if a package needs more cycles than the spec allows.

The rest of the transmittal is the same as the first issue: what a transmittal has to say.

One example

Six rows from a real-shaped log, panel package, Rev 1 returned with twelve comments:

Row 4 and row 7 are the ones that would have bounced Rev 2 if they had simply been left silent. Written down with a citation, they are a conversation the engineer can finish with one line.

How Submittal Kit handles this

The second Revise and Resubmit usually comes from a comment nobody answered. In Submittal Kit, a submittal that carries a Comment Response Log section lists every comment raised against its equipment, and each row says where its answer stands: No response yet, Written, not sent, or Submitted for review. Next unanswered walks you to the next row that still needs words. Comments read from a returned PDF arrive as rows, and Import a workbook files a returned comment spreadsheet in one pass. The log compiles as its own section of the package: item number, their comment, your response, status. On a resubmittal, Draft note can start the transmittal's cover note from the files that changed and the comments the package answers. See Configure sections.

Disclosure: I build Submittal Kit, and a spreadsheet log with the same columns does the same job.