Submittals are the workflow that determines whether the product installed on your project actually matches what the architect specified. Get them right and the install proceeds cleanly. Get them wrong — missing approvals, version drift between the approved submittal and the installed product, or install-without-approval — and you're rebuilding a wall on your own dime, or arguing at closeout about whether the substituted product meets the spec. This is a working guide to the submittal lifecycle for mid-market commercial subs and GCs: the submittal vs RFI workflow distinction, the architect's SLAs, the recurring failure modes, and how AOS handles the cross-tenant flow.
If you're a sub PM coordinating submittals, a GC PM routing them to the architect, or a contract admin certifying installations match approvals, you live in the submittal log. It's the second-most-touched workflow on a commercial project after the RFI log — and frequently more consequential, because submittal errors get built into the physical project, not just into a paper trail.
What submittals actually are
A submittal is documentation a sub provides to demonstrate that a proposed product, system, or installation method meets the project specifications. The architect (or engineer, depending on discipline) reviews the submittal and either approves, approves with comments, requests revisions, or rejects.
Common submittal types:
- Product data sheets — manufacturer specifications for materials and equipment
- Shop drawings — detailed fabrication drawings prepared by the sub (or their supplier) showing exactly how the work will be built
- Samples — physical samples of finishes, materials, or components
- Mockups — physical assemblies built on site or at the supplier for review
- Test reports — lab certifications, mill reports, equipment test data
- Equipment cut sheets — detailed product information for installed equipment, often required for closeout O&M binders
- Substitution requests — the sub proposes an equivalent product to what was specified, with documentation supporting the equivalence
Every project's specifications define which submittals are required for which sections. For a typical $20M commercial project, the submittal log can run 200-500 entries across all subs and trades. Each one has to go through the lifecycle.
Submittal vs RFI: the distinction that matters
Both submittals and RFIs are routed from the sub to the GC to the architect, but they answer different questions.
An RFI (Request for Information) asks "what does this drawing or spec mean?" or "what should we do given this field condition?" The architect's response is a clarification or a direction. The RFI cycle is typically days, not weeks. (Our both-sides-on-one-record post covers how RFI workflows compress when both sides of the project are on a connected platform.)
A submittal says "here's the specific product or system I propose to install — does it meet your spec?" The architect's response is approval (or not) of that specific proposed product. Submittals are slower and weightier because they affect the physical project; review SLAs are typically 10-14 working days for standard submittals.
The workflows are similar in shape (sub → GC → architect → back), but the consequences diverge. An RFI handled badly costs schedule. A submittal handled badly costs schedule and money and sometimes a rebuild.
The submittal lifecycle
Every submittal goes through roughly this lifecycle:
- Sub prepares. Pulls together the product data, shop drawings, samples, or whatever the spec requires. Often involves the sub's supplier, who actually originates much of the documentation.
- Sub submits. Routes the submittal to the GC's PM, traditionally via a portal upload or email, with a submittal number and reference to the specific spec section.
- GC PM review. Confirms the submittal addresses the right spec section, includes the required documentation, and is generally complete enough to forward. Some GCs maintain a substantive review step here; others pass through to the architect.
- GC routes to architect. The architect (or the engineer for engineering submittals) receives the submittal for design review.
- Architect review. Reviews against the spec. Returns with one of: Approved, Approved as Noted, Revise and Resubmit, Rejected. SLA is typically 10-14 working days for standard items, longer for shop drawings or items requiring engineering review.
- Routing back. Architect's response goes back to the GC; GC routes back to the sub.
- Sub revision (if needed). If "Revise and Resubmit" or "Rejected," the sub addresses the comments and resubmits. The cycle repeats.
- Approval and install. Once approved (or Approved as Noted), the sub orders and installs per the approved submittal.
- Closeout record. The approved submittal becomes part of the closeout binder, particularly the O&M manuals and the cut sheets. (See our closeout binder guide for the continuous-assembly approach.)
That's a 9-step lifecycle. The most common failure modes happen between steps 5 and 8.
The recurring submittal failure modes
1. Install-without-approval. The sub orders or installs based on the originally-specified product without waiting for the architect's approval of their specific submittal. If the architect's review surfaces a problem — the proposed product is missing a required certification, or the manufacturer's data doesn't match the spec — the installed product may have to be removed. This is the single most expensive submittal failure, and it happens most often when the submittal cycle is too slow and the sub is under schedule pressure.
2. Version drift between approved submittal and installed product. The architect approves Version 2 of the shop drawing. The supplier updates to Version 3 to fix a manufacturing constraint. The sub installs Version 3 because that's what was delivered. The architect later inspects and finds discrepancies. Who's responsible for what depends on the timing and the documentation — but the conversation is expensive either way.
3. Substitution request handled informally. The sub wants to substitute a different product than what was specified (often because of lead time, cost, or availability). The substitution is discussed in a meeting, the architect says "that sounds fine," and the sub installs without a formal submittal. At inspection, the substituted product fails to meet a spec requirement the architect didn't know about. Without the formal submittal record, the dispute is unwinnable.
4. SLA breach with no escalation. The architect's review goes over the contractual SLA. The sub doesn't have leverage to force the review forward. The schedule slips. At closeout, the GC's owner liquidated-damages claim cites schedule slippage, and the GC can't prove the slip was due to architect review delay because the SLA breach wasn't documented.
5. Closeout submittals missing. At closeout, the project engineer assembles the O&M binder and discovers that 40 of the 280 submittals don't have final approved versions filed. The original PDFs are in someone's email; the architect's stamped versions are missing; chasing them retroactively takes weeks.
What good submittal management looks like
The principles:
One submittal log per project, shared across sub-GC-architect. Every submittal has a record with a clear state (drafted, submitted, in GC review, with architect, returned, approved, installed). All three parties see the same log; the SLA clock is visible to everyone.
SLA tracking with breach alerts. Each submittal carries its review SLA (typically per the contract: 10 days standard, 14 days shop drawings, etc.). The platform tracks days-in-review and fires alerts when SLAs are approaching breach. Breaches are documented for later contract enforcement.
Version control built in. Each revision of a submittal is a versioned record. The "approved" version is unambiguous. The shop drawing the sub installs from is verifiably the version that was approved — not "version 3 which we think is what got approved."
Install-status tied to approval-status. The platform shouldn't allow the install record to be marked complete if the corresponding submittal isn't approved. This is a soft block (not absolute, since field conditions sometimes force decisions), but it surfaces install-without-approval situations in real time.
Substitution requests are formal records, not meeting conversations. Any substitution from the original spec goes through the formal submittal workflow with documentation of the substitution rationale and the architect's approval. If the architect won't approve in writing, the substitution doesn't proceed.
Closeout submittals attach automatically. The approved version of each submittal attaches to the closeout binder at the moment of approval. Closeout assembly is compilation, not reconstruction.
How AOS handles submittal management cross-tenant
In AOS, the submittal log is a first-class object with state, version control, SLA tracking, and cross-tenant visibility. Specifically:
- One submittal log per project, shared across the sub, the GC, and (if on the platform) the architect. The sub creates the submittal; the GC PM reviews and routes; the architect responds with a stamp; all parties see the same record in real time.
- SLA tracking is built in. Each submittal type carries its contractual SLA; the platform tracks days-in-review per party and fires breach alerts at configured thresholds.
- Version control is unambiguous. Every revision is a versioned record. The "approved" version is permanently marked. The install reference is to a specific version, not to "the submittal."
- Install record links to approval record. When the foreman or sub PM marks the corresponding install as in-progress or complete, the platform surfaces the approval status. Install-without-approval situations are visible to the GC's PM the same day they happen, not at the next coordination meeting.
- Substitution requests are first-class. A formal substitution workflow with documentation requirements, architect routing, and explicit approval. No "we discussed it in a meeting" path.
- Closeout submittals attach automatically. The approved version flows to the project's closeout binder at approval; the O&M section, cut-sheet section, and shop-drawing archive are populated continuously.
- RFI promotion to submittal (and vice versa). Sometimes an RFI reveals that a submittal is needed (the architect's RFI response requires a substitution submittal, or a shop drawing). The platform makes the promotion a one-click action with the source record linked, eliminating retyping.
The sub PM role page covers the submittal workflow from the originating side. The GC PM role page covers the routing side. The A/E contract admin role page covers the architect-side review workflow. For the broader strategic story on what changes when all three parties share a record, see the both-sides-on-one-record post. For the closeout coupling specifically, see the closeout binder continuous-assembly guide.
The submittal management readiness checklist
- Is there one submittal log per project shared across the sub, GC, and architect, or does each party maintain their own?
- Are review SLAs tracked, with breach alerts before deadlines pass?
- Is the approved version of each submittal unambiguously identified, with version history?
- Can your platform identify install-without-approval situations in real time?
- Are substitution requests formal records with explicit architect approval, or are they handled in meetings?
- At substantial completion, are 90%+ of submittals already attached to the closeout binder, or do you have to chase them down?
If most answers are "informally, with workarounds," that's the gap a connected platform closes.
If you'd like to see it
We're in private-beta design-partner mode for commercial subs and GCs. If you'd like to walk through how AOS handles the submittal log on a real project — particularly one with substantial submittal volume or active SLA pressure — apply to the beta. The subcontractor overview and GC overview walk through the platform broadly.