# Submittal

> The contractor's formal proof that a proposed product, material, or assembly matches the specified design intent, submitted for the design team's review and stamp before anything is bought or built.

- Source: https://briq.ai/acu/object/submittal
- Department: Field Operations & Project Controls (https://briq.ai/acu/department/field)
- Catalog code: FLD 102 · Level: Foundation · Track: Operations · 12 min read
- Also known as: Product Submittal, Submittal Package, Approval Submittal

## Definition

A submittal is documentation a contractor provides to the design team demonstrating that a specific product, material, sample, or fabricated assembly conforms to the requirements of the contract documents before it is procured or installed. It is the formal gate between design intent and physical reality: the specification says what is required, and the submittal proves that a real, purchasable thing satisfies it. Submittals include product data, shop drawings, samples, mock-ups, and manufacturer certifications, and they are governed by the review process defined in the specifications, typically CSI-format Division 01 sections. A submittal is not a change and does not modify the contract; if a proposed product deviates from the specification, that deviation must be raised as a substitution request or resolved through a change, not buried inside an approved submittal.

## Why it matters

The submittal is the last practical checkpoint before money is committed. Once a long-lead item like structural steel, elevators, or switchgear is released for fabrication, the cost of a mistake multiplies: catching a wrong finish or an out-of-spec rating on paper costs a review cycle, while catching it on the receiving dock costs a restocking fee, a schedule slip, and a fabrication slot that may be months out.

It is the mechanism that transfers and confirms responsibility. The specifier states performance requirements; the contractor and its suppliers select a specific product; the design team confirms the selection is consistent with design intent. When this chain is documented, everyone knows who chose what. When it is skipped, a failed product becomes an unattributable argument years later.

Submittals sit directly on the critical path more often than teams expect. A specified item with a 16-week lead time cannot be ordered until its submittal is approved, so a two-week review delay on a slow-moving package can consume float that the schedule assumed was available. The submittal log is a leading indicator of procurement risk in the same way the RFI log is a leading indicator of design risk.

The approved submittal becomes part of the evidentiary and closeout record. It documents exactly what was installed, which is what the owner needs for warranty claims, maintenance, and future renovation. An incomplete or inaccurate submittal record surfaces as a problem years later, when a facilities manager cannot identify a failed component or its replacement part.

## Lifecycle

1. **Submittal register creation** — Early in the project the specifications are mined for every required submittal, producing a register that lists each item, its spec section, and its required approval date driven backward from the installation date and lead time. A register built late or incompletely means items are discovered as emergencies.
2. **Subcontractor and supplier preparation** — The responsible sub or vendor assembles product data, cut sheets, shop drawings, or samples. Quality varies enormously; incomplete packages that omit the specified performance data are the most common cause of a rejected first cycle.
3. **Contractor review and stamp** — The general contractor reviews for completeness and conformance and applies its own review stamp before forwarding. Skipping this and passing packages straight through to the architect is a frequent cause of high rejection rates and eroded design-team goodwill.
4. **Transmittal to design team** — The submittal is logged, numbered, and transmitted with a required-return date. Bundling unrelated items into one transmittal is a common error that lets one problematic item hold up several clean ones.
5. **Design team review and action** — The architect and relevant consultants review and return an action: approved, approved as noted, revise and resubmit, or rejected. The distinction between 'approved as noted' and 'revise and resubmit' governs whether the contractor may proceed, and misreading it causes fabrication of the wrong thing.
6. **Resubmittal cycles** — Items marked revise-and-resubmit re-enter the loop. Each cycle typically costs one to three weeks; a package that needs three cycles has quietly consumed a month and a half that the procurement schedule rarely budgeted for.
7. **Release for procurement or fabrication** — Once approved, the item is released to purchase order or to the fabricator. The approved submittal becomes the reference against which delivered material is checked at receiving.
8. **Closeout incorporation** — Approved submittals, along with product data and warranties, are compiled into the operations and maintenance manuals and the closeout package. Reconstructing this record at the end from scattered emails is a predictable, avoidable scramble.

## Anatomy

- **Submittal number** — Sequential, usually keyed to the specification section number so the reviewer instantly knows which requirements apply.
- **Specification section reference** — The CSI MasterFormat section that governs the item. The reviewer checks the submittal against this section; a wrong or missing reference stalls review.
- **Submittal type** — Product data, shop drawing, sample, mock-up, certificate, or closeout document. Determines the review depth and who must see it.
- **Item description** — What is being submitted, including manufacturer and model. Vague descriptions force the reviewer to guess what they are approving.
- **Responsible subcontractor / supplier** — Who prepared it and who owns the resulting procurement. Establishes the accountability chain if the product later fails.
- **Required-by / need date** — The date approval is needed to protect the installation date given the lead time. Should be derived from the schedule, not chosen for convenience.
- **Contractor review stamp** — Evidence the GC checked the package before forwarding. Its absence signals a pass-through and predicts a rejection.
- **Design team action** — Approved, approved as noted, revise and resubmit, or rejected, with reviewer initials and date. The single most consequential field.
- **Deviations / variances noted** — Any departure from the specification the submitter is disclosing. Undisclosed deviations found later become disputes about whether approval covered them.
- **Lead time** — Manufacturing and delivery duration. Combined with the need date it reveals whether an item is already late the day the register is built.
- **Revision / cycle number** — Which resubmittal this is. Tracks the churn that quietly consumes schedule.
- **Linked records** — The purchase order, RFIs, ASIs, and material delivery tickets tied to the item, so the approved configuration follows it to the field.
- **Status and aging** — Open, in review, returned, approved, plus days outstanding against the required-by date.

## Failure modes

- **The register built too late** — The submittal register is assembled weeks or months into construction rather than at the outset. Long-lead items are discovered already behind, and the team spends the project reacting to procurement emergencies it could have seen from the specifications on day one.
- **Pass-through with no contractor review** — The GC forwards subcontractor packages to the architect unreviewed. Incomplete and non-conforming submittals flood the design team, rejection rates climb, review turnaround degrades for everyone, and the relationship sours.
- **'Approved as noted' treated as 'approved'** — The reviewer marks corrections that must be incorporated, but the fabricator builds to the original drawing because nobody read the notes. The mistake is discovered at delivery, and the item is now wrong and paid for.
- **Deviation hidden inside an approved package** — A supplier substitutes a component that does not fully meet the spec and does not flag it. Approval is later argued to cover the deviation, or not, and the ambiguity becomes a warranty and payment dispute.
- **Bundled transmittals with one bad item** — Several items are submitted together; one is deficient, so the whole transmittal is returned, holding up items that were perfectly acceptable. Procurement stalls on packages that had no actual problem.
- **Approved submittal never reaches receiving** — The approved configuration lives in the project system but the receiving crew checks deliveries against nothing. Wrong or out-of-spec material is accepted at the dock and installed before anyone compares it to what was approved.
- **Closeout record reconstructed from scratch** — No one compiles approved submittals as they close, so at the end the team rebuilds the O&M manuals from email attachments and supplier websites, missing warranties and product data the owner is contractually owed.

## Metrics

- **Approval cycle time** — Days from transmittal to a returned action, measured against the specified review window. The core turnaround metric on the design side.
- **First-pass approval rate** — Share of submittals approved or approved-as-noted on the first cycle. Measures the quality of preparation and contractor review.
- **Resubmittal rate** — Average number of cycles per item. Multiple cycles are the hidden schedule consumer procurement plans rarely account for.
- **Ballpark lead-time exposure** — Count of items whose lead time plus remaining review time already exceeds the need date. The true procurement-risk metric.
- **Register completeness** — Share of specification-required submittals actually on the register. A low figure means emergencies are still hiding in the specs.
- **Critical-path submittal aging** — Days outstanding for submittals tied to activities with little float. Far more actionable than total open count.
- **Closeout capture rate** — Share of approved submittals and warranties already compiled into the closeout package. Predicts the end-of-job scramble.

## The AI shift

- **Conversational** — The specification stops being a document you read cover to cover to build a register. You ask which sections require submittals, which required items are not yet on the register, and which open submittals sit on long-lead items with insufficient review time remaining, and get answers cited to the spec sections and the schedule.
- **Generative** — Register creation shifts from manual spec mining to a generated draft: the model reads the specifications, extracts every required submittal with its section reference and type, and proposes need dates by working backward from installation dates and lead times, which the team refines rather than assembles from nothing.
- **Orchestrated** — The submittal stops being a standalone package. It is checked against the specification it claims to satisfy, matched to the purchase order and schedule activity it enables, cross-referenced with related RFIs and ASIs, and its approved configuration is carried forward to receiving so delivered material is verified against what was actually approved.
- **Autonomous** — The routine motion runs continuously: the register is kept current against the issued specs, need dates are recomputed as the schedule moves, aging is monitored against float and lead time, reminders escalate on the review clock, and packages are pre-screened for completeness against their spec sections before they consume design-team capacity, while humans decide conformance and approve every deviation.

## Prompts

### Conversational — Assessing procurement risk buried in the submittal log.

```text
Review our submittal register against the current schedule. Identify every submittal that is not yet approved where the item's lead time plus a realistic remaining review time already exceeds the need date derived from its installation activity. For each, give me the submittal number, spec section, item, responsible subcontractor, lead time, need date, and how many days late it already is on the current trajectory. Rank by the size of the schedule exposure, and separate items that are structurally late from items that are merely behind on review.
```

**Expected output:** A ranked exposure list that ties each open submittal to its lead time, need date, and schedule position, distinguishing recoverable review delays from items that are already too late to make on the current plan.

**Follow-ups:**

- Which of these sit on the critical path versus activities with float?
- Draft an expediting note to the responsible subs for the structurally late items.
- What would we have to do to recover the worst three?

### Generative — Building a submittal register from the specifications at project start.

```text
Read the attached project specifications and produce a draft submittal register. For every section that requires a submittal, list the spec section number and title, the specific submittal(s) required, the submittal type (product data, shop drawing, sample, mock-up, certificate), and any explicitly required performance data or certifications. Where the section references a standard or listing, name it. Flag any submittal that appears to govern a long-lead item so we can prioritize it. Present it as a table sorted by spec section, and note any sections where the submittal requirements are ambiguous and need a human read.
```

**Expected output:** A structured register keyed to spec sections with submittal types and performance requirements identified, ambiguous sections flagged for human review rather than silently omitted.

**Follow-ups:**

- Add a proposed need date column by working back from the schedule activities I will provide.
- Which of these items typically carry the longest lead times in commercial work?
- Generate a completeness checklist a subcontractor should meet before submitting section 08 71 00.

### Orchestrated — A submittal just came back approved-as-noted and you need to protect the fabrication.

```text
Submittal 042-03 for the curtain wall was returned 'approved as noted.' Read the reviewer's markups and the referenced specification section, then trace the impact: which of the noted corrections must be incorporated before fabrication release, whether any note constitutes a scope or cost change rather than a clarification, which schedule activities and the linked purchase order are affected, and whether any related RFI or ASI already addressed or contradicts these notes. Return a release-readiness summary that states clearly whether this can go to the fabricator as-is, must be corrected first, or needs a change, with each conclusion tied to the specific markup or document.
```

**Expected output:** A release-readiness determination that separates mandatory corrections from clarifications and flags anything that is actually a change, cited to the markups and the governing spec section.

**Follow-ups:**

- Draft the release instruction to the subcontractor listing exactly which notes to incorporate.
- If any note is really a scope change, open a change event and draft the cost narrative.
- Confirm the delivered configuration we should check at receiving.

### Autonomous — Standing policy for running the submittal process.

```text
Operate our submittal process continuously under these rules. Keep the register current against the issued specifications and recompute need dates whenever the schedule changes. Pre-screen every incoming package against its spec section for completeness and required performance data, returning incomplete packages to the responsible subcontractor with the specific gaps named before they reach the design team. Monitor aging against the specified review window and against lead-time exposure, escalating to the project manager at the review-window deadline and sooner for any item whose delivery date is now at risk. Carry every approved configuration forward to receiving. Never mark a submittal approved, never accept a disclosed deviation, and never release an item for fabrication on your own; route conformance decisions, deviations, and any cost implication to a human with your reasoning and the supporting references.
```

**Expected output:** A continuously maintained register and screening process with a short human exception queue, where conformance, deviations, fabrication release, and cost always remain human decisions with a full audit trail.

**Follow-ups:**

- Show me this week's exception queue and everything you returned for completeness.
- Which items moved into lead-time jeopardy since last week and why?

## Maturity ladder

- **Level 0 — Level 0 — Ad hoc** — Submittals move as email attachments with no register. Long-lead items are discovered late and the closeout record is reconstructed from inboxes.
- **Level 1 — Level 1 — Registered** — A submittal log exists with numbers, spec references, statuses, and dates. Aging is visible in a periodic report but need dates are not tied to the schedule.
- **Level 2 — Level 2 — Scheduled** — Need dates are derived from installation dates and lead times, submittals are linked to purchase orders and schedule activities, and lead-time exposure is measured.
- **Level 3 — Level 3 — Assisted** — Registers are generated from the specs, incoming packages are screened for completeness automatically, and impact of approval actions is drafted for human review.
- **Level 4 — Level 4 — Operated** — The routine loop runs unattended within guardrails — register maintenance, completeness screening, aging escalation, and receiving verification — while conformance, deviations, and fabrication release stay human.

## FAQ

### What is the difference between a submittal and a shop drawing?

A shop drawing is one type of submittal. 'Submittal' is the broad category covering everything a contractor provides to prove conformance, including product data, samples, mock-ups, and certifications; a shop drawing is specifically a fabrication or installation drawing prepared by a subcontractor or supplier for a custom-fabricated element. All shop drawings are submittals, but most submittals are not shop drawings.

### Does an approved submittal relieve the contractor of responsibility if the product fails?

Generally not. Standard contract language, such as AIA A201, is explicit that the design team's review is for conformance with design intent and does not relieve the contractor of responsibility for dimensions, quantities, fabrication, or coordination. Approval confirms the selection is consistent with the design; it does not transfer responsibility for the contractor's own means, methods, and errors.

### What does 'approved as noted' actually allow me to do?

It generally allows the contractor to proceed provided the reviewer's noted corrections are incorporated, without a resubmittal. That is the critical distinction from 'revise and resubmit,' which requires another review cycle before proceeding. The danger is fabricating to the original document while ignoring the notes; the notes are mandatory, not advisory.

### How do I keep submittals off the critical path?

Build the register from the specifications at the very start, set each need date by working backward from the installation date through the item's lead time and expected number of review cycles, and prioritize long-lead packages relentlessly. Most submittal-driven delays trace to a register built late, so the earliest work on the project protects the schedule most.

## Related objects

- [Shop Drawing](https://briq.ai/acu/object/shop-drawing)
- [Request for Information (RFI)](https://briq.ai/acu/object/rfi)
- [Material Delivery Ticket](https://briq.ai/acu/object/material-delivery-ticket)
- [Purchase Order](https://briq.ai/acu/object/purchase-order)
- [CPM Schedule](https://briq.ai/acu/object/cpm-schedule)
- [Closeout Package](https://briq.ai/acu/object/closeout-package)