Engineering and architecture
Submittal review records: what the architect's stamp history shows
By SourceX Editorial · Updated
Short answer
An architect's submittal stamp history records each review action, such as approved, approved as noted or revise and resubmit, with who reviewed, when and on what grounds. Read across a project, it shows where design intent and contractor proposals diverged. Approved-as-noted comments carry the most information, because they record the exact correction the reviewer required.
Key takeaways
- Action code wording varies by firm and specification, but most codes map to approve, approve with corrections, revise and resubmit, reject or record only.
- Approved-as-noted comments are the richest part of the history because they name the deviation and the fix the reviewer accepted.
- Stamp language usually limits review to general conformance with design intent and leaves dimensions, means and methods with the contractor.
- Resubmittal chains grouped by spec section reveal recurring coordination problems a COO can act on.
- A usable history keeps the stamp, comments, revision and spec section linked in one record.
What does the architect's submittal stamp record?#
The architect's submittal stamp records a professional judgment: the action taken, the reviewer, the date and the limits of the review. Combined with the written comments and markups, it is the firm's documented answer to a contractor's proposal for how part of the building will be made.
Most stamps carry a scope statement saying the review is for general conformance with the design concept and the contract documents, and that the contractor remains responsible for dimensions, quantities, fabrication, means and methods, and coordination with other trades. Exact wording differs by firm and by the general conditions, and counsel and the firm's insurer usually have views on it.
The project specification sets the rules. Submittal procedures in Division 01 typically define the action codes the reviewer will use and what the contractor must do in response, so read old stamps against that project's spec rather than the firm's current template.
Action codes and what each says about the reviewer's judgment#
Action codes compress the reviewer's judgment into a few words, and each code records something different about how the reviewer saw the submittal. The wording below reflects common practice; your firm's stamps may use other phrases for the same meaning.
Codes that route a submittal to a consultant, such as a structural or MEP engineer, add another layer. The architect's stamp may simply forward the consultant's action, so the consultant's own stamp and comments are where the judgment actually sits.
| Action code (common wording) | What it tells the contractor | What it records about the reviewer |
|---|---|---|
| Approved / No exceptions taken | Proceed as submitted | The item matched design intent; little to learn from |
| Approved as noted / Make corrections noted | Proceed and incorporate the noted corrections | Specific deviations found and the fix the reviewer would accept |
| Revise and resubmit | Correct and submit again before proceeding | Problems serious enough to need a second review |
| Rejected / Not approved | Do not proceed; submit a compliant item | The product or approach does not meet the documents |
| Submit specified item | The proposed item is not what was specified | A substitution attempted outside the proper procedure |
| Received for record / For information only | No action taken; filed | Reviewed only for completeness, or not reviewed at all |
Why approved-as-noted comments carry the most signal#
Approved-as-noted comments carry the most signal because they record a reviewer catching a specific problem and deciding it can be fixed without a full resubmittal. A clean approval says the item matched; a rejection often says only that it was the wrong product. The noted correction says what was wrong, why it mattered and what the reviewer would accept instead.
Those comments fall into recognizable types, which is what makes a large set of them useful for training junior reviewers, for internal QA and for AI developers studying how professionals review documents.
The weak point of approved as noted is follow-through. Unless a later record, such as an RFI, a field report or a closeout document, shows the correction was made, the history captures the instruction but not the outcome.
- Dimensional or clearance conflicts with the drawings.
- Coordination with adjacent trades, such as embeds, penetrations or supports.
- Code or accessibility requirements the submittal missed.
- Finish, color or option selections the contractor left open.
- Conditions attached to accepting a product that differs slightly from the specification.
- Missing information the reviewer needs in the field or in the next submittal.
Reading the stamp history across a whole project#
Stamp history read across a whole project shows where the documents and contractor proposals kept diverging, and where the firm's review process was slow or inconsistent. A COO can use it the way a plant manager uses a defect log.
The patterns are only as good as the log. Logs kept partly in a contractor's platform, partly in email and partly in stamped PDFs rarely line up without cleanup, so expect to join them by submittal number before drawing conclusions.
Three measures are enough to start, each calculated by spec section and by project: the share of items approved on first submission, the number of review cycles per item, and the time from receipt to return, split between the architect's desk and consultant routing. Compare them across projects of the same building type before drawing conclusions.
| Pattern in the log | What it may suggest | What to check next |
|---|---|---|
| Repeated resubmittals in one spec section | Ambiguous drawings or specifications for that system | RFIs and addenda on the same section |
| Slow returns on certain items | A reviewer bottleneck or consultant routing delay | Who held the item, and at which step |
| Different codes for similar items across projects | Inconsistent standards between reviewers | Firm review guidelines and reviewer training |
| Many approved-as-noted items with the same comment | A recurring gap in the firm's details or specs | The standard detail or office master section |
| Rejected substitutions | An unclear substitution procedure | Division 01 substitution requirements |
What a usable submittal history must contain#
A usable submittal history keeps the stamp, the comments and the context together in one linked record per submittal revision. Without that, the history is a folder of stamped PDFs that a person can read and nobody can analyze.
Procore, Newforma, Bluebeam and similar platforms each store these fields differently, and export options vary by account and plan. Test an export on one closed project and check, above all, whether reviewer comments come out as text.
- Submittal number and revision, with spec section and title.
- Dates received, sent to consultants, returned and resubmitted.
- Reviewer and reviewing firm, recorded by role.
- The action code exactly as stamped.
- Comments as text, not only as markups inside a PDF.
- Links to prior and later revisions, and to related RFIs or change documents.
Illustrative: a COO reads several years of stamp history#
Illustrative: a fictional architecture firm, Marrow Street Architects, designs mid-rise housing and mixed-use buildings. It tracks submittals in a construction platform shared with contractors and keeps its own stamped PDFs on a file server. The COO wanted to know why construction administration hours kept overrunning.
The team exported submittal logs for closed projects, joined them to the stamped PDFs by submittal number and coded each comment by type. Window and storefront submittals showed the most revise-and-resubmit cycles, and many approved-as-noted comments repeated the same sill flashing correction.
The firm revised its standard window detail and the related office master section, and added a review checklist for that system. Separately, the principals asked whether the coded history could be licensed. Counsel confirmed which projects allowed it, contractor shop drawings were excluded, and only the firm's own actions and comments went forward for a licensing assessment, described by spec section, years and record counts rather than by sending files.
Who owns the stamp history, and how SourceX approaches it#
The firm's own review actions and comments are generally its work product, while the shop drawings, product data and samples underneath belong to contractors and manufacturers. Client contracts can change that, especially owner-drafted forms that claim all project documents, so the rights review runs project by project.
SourceX handles submittal histories through the SourceX five-step transaction. Supply describes the logs with metadata only; Rights confirms which projects and which parts of each record the firm controls; Preparation removes names, firms and project identifiers; Approval and Delivery follow the firm's sign-off. The SourceX Evidence Packet records each of those decisions.
Frequently asked questions
Does approved as noted require the contractor to resubmit?
Usually not. The contractor proceeds and incorporates the noted corrections, unless the reviewer asks for a resubmittal or the specification requires one for certain items. Check the project's submittal procedures, since some firms pair approved as noted with a request for corrected copies for the record.
Does approving a submittal change the contract documents?
Stamp language and general conditions typically say it does not. Under common general conditions, the contractor stays responsible for deviations unless it identified the deviation in writing when submitting and the architect specifically approved it, or a change order or similar modification authorized it. Confirm the rule in your agreement and the project specifications.
Should a firm standardize its action codes?
It helps. Consistent codes make stamp history comparable across projects, which is what turns it into a QA tool. Update the Division 01 template and the physical or digital stamp together, and keep a crosswalk from older codes so historic logs remain readable.
Should we keep superseded submittal revisions?
Yes, within your retention schedule. The superseded revision with its comments shows how the reviewer's judgment changed the item. Keeping only the final approved version keeps the outcome but throws away the reasoning that produced it.
Can stamp history be used to train new reviewers?
Often, inside the firm. Coded approved-as-noted comments make good teaching cases because each shows a real deviation and a real fix. Remove contractor and client names if the material circulates widely, and stay within your confidentiality obligations to clients.
Related resources
See if your company qualifies
A short company assessment. No data uploads are needed.