Submittal Logs and Checklists in Construction

What a submittal actually is

A submittal is documented proof that a specific product, assembly or piece of work meets the design intent and the contract requirements before it is built, fabricated or installed. It is the mechanism by which a contractor demonstrates — to the engineer of record, the architect and ultimately the owner — that what is about to happen on site or in a shop matches what was specified, rather than a close approximation of it.

Treated properly, a submittal review catches the problems that are cheap to catch: a dimension that does not match the structural drawing, a product substitution that changes a fire rating, a connection detail that was never actually engineered. Treated as a formality — stamped without being checked, or checked by someone without the authority to catch what matters — a submittal stops doing its job and becomes paperwork that happens to exist, which is a worse position than having no submittal process at all, because it looks like quality control without providing it. The stakes also scale with what is being verified — a submittal on a primary structural connection carries a different consequence than one on interior trim — and a review process that treats every submittal with identical urgency ends up under-resourcing the ones that actually matter.

The types of submittals you will actually see

• Shop drawings — the fabricator's or detailer's own drawings, showing exact dimensions, connections and fabrication detail derived from the contract drawings, not a repetition of them.
• Product and material data — manufacturer cut sheets and technical specifications confirming a specified product's actual performance data.
• Samples — physical material examples submitted for finish, colour or texture verification where a specification cannot fully describe the result.
• Test reports and calculations — engineering calculations, lab results and certifications supporting a design or a substitution.
• Mix designs and erection drawings — concrete mix proportions and the sequence for assembling precast or structural steel elements on site.
• Closeout documents — operation and maintenance manuals, warranties and as-built information, submitted once the work itself is complete.

Informational, action and closeout

Not every submittal asks for the same response, and treating them as though they do is a common source of review-cycle delay. Informational submittals are record-keeping: they confirm something happened or exists, but no approval is required before work proceeds. Action submittals are the opposite — formal review and a documented decision, approved, approved as noted, or rejected, is required before the work they describe can start.

Closeout submittals sit at the end of the project rather than during it: warranties, O&M manuals and as-built drawings that document what was actually built and installed, assembled as the project finishes rather than reconstructed afterward. Sorting a submittal into the wrong category at log entry is a small mistake with an outsized consequence — an action submittal logged as informational can sit unreviewed while work proceeds against it anyway. Getting the category right also determines the record: an action submittal without a documented decision is an open risk sitting in the log, while an informational submittal chased for a formal approval it was never going to receive wastes a review cycle that was needed elsewhere.

The submittal log: the record everything else depends on

A submittal log is the tracking record that makes a submittal process auditable rather than a matter of memory: a submittal number, a description and the specification section it responds to, the date it was submitted, who it was assigned to for review, its current status, and the date it was returned. Without this record kept current, the honest answer to "where is submittal 114" is a search through email rather than a lookup.

A log earns its keep through a few habits more than through any particular software: one person accountable for keeping it current rather than whoever has time that week, submissions and returns logged the day they happen rather than batched up, automated reminders as a review approaches its due date, and a regular review meeting where open items are actually discussed rather than left to age silently at the bottom of a list. The specification section a submittal responds to should be cited precisely enough that a reviewer with no other context can find the clause it is answering — a vague reference is often the first sign that the submission itself was assembled in a hurry.

The submittal checklist: the gate before it goes in

A checklist run before a submittal is issued catches the errors that otherwise surface only after a reviewer has already spent time on the package: the required attachments are actually present, the drawing or document references the correct specification section rather than a similar one, the revision and version are clearly marked so a reviewer is not checking a superseded copy, the number of copies matches what the contract requires, and the submission date is recorded before it is sent, not reconstructed afterward from an email timestamp.

None of this is difficult, which is exactly why it gets skipped under schedule pressure — and exactly why skipping it is expensive. A submittal returned for a missing attachment or a wrong specification reference does not just lose the days until it is resubmitted; it loses its place in the reviewer's queue and starts the cycle again from the back. A reviewer's first pass on a package that fails the checklist is not a technical review at all — it is confirming what should have been confirmed before submission, which is exactly the time it should not be spending.

Deferred submittals and delegated design are not the same thing

A deferred submittal is a timing decision: an item that will be designed and submitted later in the project, on a schedule agreed in advance, usually because the specialty subcontractor who will actually design it has not yet been engaged, or because finalizing it earlier would lock in a decision better made once other work has progressed. The design responsibility has not moved — it is simply scheduled for a later date.

Delegated design is a different thing entirely: the responsibility for designing an element is transferred to the contractor or a specialty subcontractor, operating under performance criteria set by the engineer of record rather than a fully detailed design. Confusing the two matters because it changes who is actually accountable if the submitted design is wrong — a deferred submittal is still the engineer of record's design, arriving late; a delegated one is someone else's design, arriving under someone else's stamp, and the contract needs to say clearly which is which before it becomes a dispute about liability rather than a scheduling question. Neither is a shortcut around the engineer of record's responsibility to review what comes back — a deferred item still needs the same scrutiny at its later date, and a delegated design still needs its performance criteria checked against what was actually submitted.