Revise and Resubmit Without Rebuilding the Whole Package

When a package comes back Revise and Resubmit, treat Rev 1 as an edit of what you sent, not a new package. Start from the exact file that went out, change only the sheets the comments touched, mark those changes, recheck only what changed, and send it under the same number with the next revision. The reviewer already approved most of Rev 0 in their head. Don't make them read it twice.

The stamp comes back with six comments. Two are on the drive datasheets, one wants the SCCR on the nameplate, one asks for a different surge protector, and two are questions you can answer without touching a page. Six comments, maybe eight pages that need to change.

So naturally the whole package gets rebuilt. Someone opens the working folder, which has drifted since Rev 0 went out. A datasheet on a part nobody commented on got swapped for a newer version. The cover picked up a new date format. The tabs renumbered because a section moved. Two days later Rev 1 goes out, 212 pages that are almost the same as the last 210, and the reviewer has to read every one of them to find out which "almost" matters.

That's how a six-comment return turns into a second Revise and Resubmit.

Start from what you sent, not from the working folder

Rev 0 is the only version the reviewer has seen. Open that exact file, the one on the transmittal, not the folder you've been editing since. Every comment refers to a page in it, and every change you make should be measured against it.

If you can't say with confidence which file went out, that's the first problem to fix, and it's covered in submittal numbering and revision schemes. "VFD_submittal_final_v2" is not a revision.

Map each comment to the pages it touches

Before anyone edits anything, go down the comments and write next to each one which pages it changes:

• Swap a sheet. A different product, a newer datasheet, a corrected drawing.
• Mark a sheet. The right sheet is already there, but the highlight was on the wrong row or the value wasn't marked.
• No page change. The answer is a clarification or a dispute, and it lives in the response log.

Now you know the real size of the job. Six comments came back, eight pages change, and the other 200 stay exactly as they were. Answering each comment row by row has its own method, and it's in answering review comments on a resubmittal.

Same number, next revision

Rev 1 is the same submittal, so it keeps the same number. Bump the revision, keep the title, and keep the spec section. When Rev 1 shows up as a fresh number, the reviewer's log now has two open items for one package, and the history of what was asked and answered is split across both. The engineer reviews Rev 1 against their comments on Rev 0. Make it easy for them to put the two side by side.

Swap only what the comments touched

This is where the time goes, and where it's saved. Replace the sheets on your map and leave everything else alone. That includes the datasheet that got a newer version last week. If it isn't on a comment and nothing about it changed, Rev 1 isn't the place to slip it in.

Some changes do have to ride along: a part went obsolete, a vendor revised a drawing. Those are fine, as long as you list each one with its reason. The engineer is reviewing the comments, and an unlisted change is one they won't go looking for and won't count as approved.

Then make the changes impossible to miss. Cloud the revised values on drawings, update the revision block on each sheet you touched, and mark the new values on swapped cut sheets the same way you marked the originals (how to mark up cut sheets has the details). A reviewer who can flip straight to the clouds finishes your Rev 1 in one sitting. A reviewer who has to compare 212 pages by eye schedules it for later.

Recheck what changed, then stop

Your first package got a full pass before it went out. Rev 1 doesn't need another full pass. It needs a hard look at the parts that are new:

• Every swapped product against the spec. A new surge protector answers comment 4, and it can still fail the voltage rating in Part 2. Check the replacement as carefully as you checked the original.
• Every tag the reviewer named. If they couldn't find it last time, open the new package cold and make sure they can find it now. That's the three-tag test, run on their tags.
• The comment count. Six comments in, six rows out, each with an answer.

Then send it. Whether the spec wants the whole package again or only the revised sheets is in its resubmittal paragraph, so read it before you choose.

File the return against the revision it answers

When Rev 1 comes back stamped, file the stamped PDF next to the exact Rev 1 you sent, not in a general "returns" folder. Do the same for Rev 0's return, even though it was a rejection.

Closeout is where this pays off. The owner wants the approved submittal: the issued file plus the stamp that approved it. Months from now, "which one was approved?" should take ten seconds to answer, not a morning in the inbox. The rest of that list is in the control system closeout checklist.

How Submittal Kit handles this

You shouldn't have to guess what went out in Rev 0, and in Submittal Kit you never do. Mark as submitted freezes the exact package you sent as a permanent submission, while the working submittal stays editable for the next round. When the review comes back, answer each comment in the Comment Response Log, swap the datasheet on just the parts the comments named, and compile again. Everything you didn't touch comes out the same. Mark Rev 1 as submitted keeps the submittal's number and continues the revision sequence, labeled Rev 1 or Rev A to match your numbering setting.

Each submission's Since line says what it added, replaced or removed compared to the one before, with Show changes listing every document by name and role. Page numbers move on every compile, so they're deliberately not counted. On the transmittal, Draft note can start the cover note from the files that changed and the comments the package answers. When you swap a datasheet, the Spec Check panel marks the last run out of date so you know to re-run it, and your own marks carry over to the revision.

When the stamp comes back, drop it under Returned documents on the submission it answers. The outcome stamp, reviewer and return date are read off the page for you to confirm, and Upload correction keeps every earlier version on the record. Clouding the drawings is still yours. See Issue a submission and Returned reviews.

Disclosure: I build Submittal Kit, and every step above works with a PDF editor and a folder named for each revision.