Submittal Spec Compliance Check

A spec-compliance check on a submittal should return one of two things: a deviation flag that points at a passage in the shop drawing or material data sheet and at the specification clause it conflicts with, or nothing. The engineer still owns the review. The model does not approve the package, does not infer a requirement the spec never wrote, and does not fill silence with a pass.

That is the quality outcome. You get a review packet a design manager can open, walk the cites, and then reject, comment, or stamp. You do not get a green score that stands in for professional judgment.

If the specification is silent on a product attribute, the check leaves that attribute empty. Empty is the correct answer. Treating silence as compliance is how a substitution walks onto site with no paper trail.

Start with the contract specification that is actually in force on this package: the addenda, the issued-for-construction set, and any accepted substitutions already on the register. Then pull the shop drawings and the manufacturer data sheets that belong to this submittal number, not a prior revision sitting in the same folder.

Platforms in the Autodesk and Procore class commonly hold both the spec PDFs and the submittal workflow. Use them as document stores and as the source of revision history. Do not treat a file titled "Division 08" as current because it is the one the model indexed last week. Citing a superseded spec is a failure mode that looks like diligence: every cite is neat, every page number is real, and every requirement is from a set the contractor is no longer bound to.

Confirm three identifiers before any comparison runs: the drawing revision letter, the data-sheet date or edition, and the spec section number including the addendum that last touched it. If those three do not match the live package, stop. Do not run the comparison against stale text and then ask the engineer to spot-check the flags.

Name the submittal mark, the spec section, and the drawing sheet in the packet header so a reviewer can reconstruct what was compared without guessing. If the submittal includes both a shop drawing and a data sheet, keep them as two sources. A flag must say which one it came from. Blending them into a single product description hides whether the contractor's drawing or the manufacturer's literature is the problem.

Work clause by clause. For each requirement that is written (a rating, a finish, a test standard, a dimensional tolerance, a listed manufacturer or product series), look for the matching statement on the shop drawing or in the data sheet. When they conflict, write a deviation: quote the submittal line, quote the spec clause, and stop. Do not rewrite the spec. Do not invent a third requirement to complete the check.

A usable flag has four fields: the submittal cite (sheet, detail, or data-sheet row), the spec cite (section, paragraph, and addendum), a one-sentence conflict, and a blank where the spec has no clause. Do not add a recommended disposition. Disposition is the review.

When the spec names a standard and the data sheet names a different one, that is a deviation, even if installers treat the products as equivalent in the field. Equivalence is an engineer decision. The check's job is to surface the mismatch with both cites intact.

When the spec does not mention an attribute, leave it blank. A data sheet that lists recycled content, coating thickness, or an optional accessory is not a deviation and is not a pass. It is extra information. Logging it as compliant teaches the next reviewer that silence means yes.

If a shop-drawing note and a data-sheet row disagree with each other, flag the internal conflict and still cite the spec clause if one exists. If the spec is silent, flag only the internal conflict and leave the spec cite empty. Do not pick a winner.

Skip narrative in the spec that is not a requirement: scope blurbs, related-section pointers, submittal-procedure text. Comparing those lines produces flags that waste the reviewer's time and trains people to ignore the packet.

Suppose Division 08 requires a 90-minute rated hollow-metal frame, a listed closer, and hinges of a stated type, and the contractor submits shop drawings plus the hardware manufacturer's data sheets.

The check should open the live 08 11 13 section, including the addendum that changed the closer, then the door schedule on the shop drawings, then the closer and hinge data sheets. If the shop drawing schedules a 60-minute label where the spec still says 90, flag it: cite the door-schedule cell and the spec paragraph that states the rating. If the closer data sheet lists a model that is not in the specified series, flag it with the model line and the specified-product paragraph. If the spec never mentions a specific hinge finish, do not invent one and do not mark the finish as compliant. Leave finish empty.

If that closer requirement lived only in an addendum and the model compared against the base spec, the flag set is wrong even when every cite is internally consistent. That is the superseded-spec failure: the packet looks complete and the live requirement is the one that never got checked.

The engineer then reviews the flags, not a score. They may reject the 60-minute label, comment that the closer series is acceptable as a substitution, and leave the unmentioned finish alone. None of those decisions belong to the model.

This is an illustration of the comparison loop, not a project result. Do not attach a pass rate or a time saving to it.

Do not auto-approve a submittal because the comparison returned no deviations. A clean run means the model did not find a written conflict against the text it was given. It does not mean the shop drawings are coordinated with the architectural set, that the product is available, or that the installer can build it. Geometric conflicts the spec text never describes still belong to BIM design clash detection.

Route a clean packet to the same engineer queue as a flagged one. The difference is only the contents of the comment list. Stamping from a score is how a silent spec plus a confident model becomes an unreviewed product on site.

When a flag is real, the next move is often an RFI, not a silent markup. RFI auto-response drafting is how you turn a cited mismatch into a question the design team can answer. Upstream, tender clause risk classification is how you notice, before award, that a spec section is thin or internally inconsistent, which is the condition that later produces empty checks that look like passes.

After the product is accepted, keep closeout separate. Warranty language on the data sheet is not a spec-compliance result. Extract it with warranty register extraction so this check stays about the contract specification.

Once the packet is in front of you, work the flags in order. Open the submittal cite, open the spec cite, and decide. A valid deviation becomes a revise-and-resubmit or a substitution request. A false flag (wrong revision, or a typical-detail note that does not apply to this mark) gets dismissed with a one-line reason so the next run does not repeat it.

Keep the empty fields visible. They document that the spec was silent. That record matters when a later inspector asks why a finish or accessory was not checked.

Never let the absence of flags collapse this step. If you only review when something is red, you have built auto-approval by another name. The stamp remains yours.