What Approved as Noted Actually Requires You to Do

The package comes back. There's a stamp on it. Now what?

Every firm words its stamp a little differently, and your project's stamp and submittal procedure control. But the outcomes usually fall into a familiar set. Getting this wrong in either direction hurts: treat "Approved as Noted" as a clean approval and you build in the reviewer's uncorrected comments; treat it as a rejection and you burn a review cycle nobody asked for.

The stamps, and what each one means

Approved (some firms: No Exceptions Taken, Reviewed). Proceed to the extent the stamp and project documents allow. File the returned copy in the log, because this is the record you will reach for if anyone questions the equipment selection later.

Approved as Noted (Make Corrections Noted, Furnish as Corrected). Proceed as the stamp allows and incorporate every applicable comment. This is the one that gets mishandled, so it gets its own section below.

Revise and Resubmit. Fix the package and issue the next revision. Check the stamp and project procedure before releasing affected work. The extra cycle is the reason to review your own package before the engineer does, especially when procurement is waiting on it.

Rejected. The reviewer did not accept the proposed equipment or approach. Usually this means a substitution they declined or a fundamental misread of the requirement. Before you rebuild the same package with a new revision number, get on the phone. Resubmitting a rejected package without a conversation is how you collect a second rejection.

For Information Only (Record Copy). Usually no approval was requested or granted. Note it in the log and do not treat it as permission to release work unless the project documents say otherwise.

Approved as Noted, in practice

On a project where this stamp lets work proceed without another full review, it says two things at once: proceed, and incorporate the comments. The comments are not suggestions. They are conditions attached to the review.

The follow-through that keeps comments from disappearing:

1. Read every comment, on every page. Comments hide on page 47 of a returned PDF. Someone whose job it is has to page through the whole returned document, not just the stamp page.
2. Log the response and keep the returned copy. The marked-up document the engineer sent back is part of the project record. Attach it to the revision it answers, with the response date. When a dispute surfaces two years later, "what did the engineer's markup actually say" is a question you want to answer in thirty seconds from the log, not never.
3. Push each comment to the person it affects. A comment about wire labeling goes to the panel shop. A comment substituting a part goes to purchasing before the PO cuts. This handoff is where Approved as Noted most often fails: the stamp gets celebrated, the PDF gets filed, and the comments reach nobody who could act on them.
4. Decide whether any comment may change scope or contradict the spec. A note in the margin does not answer that question by itself. Compare it with the contract documents and route it through the project's clarification, notice, or change process before the affected work continues. See submittal versus RFI.
5. Confirm whether a conformed copy is required. Some specs want a corrected resubmission for record even after Approved as Noted. The spec's submittal article says; read it rather than assuming.

The log is what makes any of this real

Every returned submittal, whatever the stamp, produces the same three records: the response, the date, and the returned marked-up copy, attached to the exact revision that went out. Kept diligently, this log answers the questions that otherwise turn into arguments: which revision was approved, how long review took, and what changed between Rev 1 and Rev 2.

It also gives you something memory never will: your own numbers. Count the packages that came back for resubmittal, the hours spent rebuilding them, and the days each return took. I did this against a sample of my own firm's logs; the denominators and limits are in what thirteen submittal logs taught me about resubmittal rates. The self-review pass is in what goes in a control system submittal package, and the numbering that makes the count possible is covered in submittal numbering and revision schemes.

How Submittal Kit handles this

An Approved as Noted stamp is only useful if every comment reaches someone who can act on it and the returned copy stays tied to the revision it answers. In Submittal Kit you drop the returned PDF on the revision, and a reading of it offers the outcome stamp, the reviewer, and the return date on one line for you to confirm. Nothing is recorded until you save. Reviewer comments found in the document land on the project's punch list, and you answer each one in the Comment Response Log. Every issued revision stays frozen byte for byte, and the Submittal Log puts a ball-in-court glyph beside every status chip, so a Revise and Resubmit cannot hide among the closed rows. See Returned reviews.

Disclosure: I build Submittal Kit. Your stamp and project documents govern, and the routing work is yours whatever keeps the log.