# How to Read a Spec Section for Submittal Requirements Where submittal requirements actually live in a specification, how the three-part format works, and the reading order that catches the demands everyone misses. Most rejected submittals fail against a sentence somebody didn't read. The spec asked for a test procedure, or seismic certification, or a specific sequence-of-operations narrative, and the package didn't have it, because the person assembling the package worked from the datasheet folder instead of the book. Reading the spec for submittal requirements is a skill, it takes an hour per section once you have it, and it pays for itself on the first avoided resubmittal. ## How a spec section is built Nearly every technical section follows the CSI three-part format: - **Part 1, General**: administrative requirements. The submittal list lives here, usually in an article literally titled SUBMITTALS. - **Part 2, Products**: what the equipment must be. Manufacturers, ratings, features, options. - **Part 3, Execution**: how it gets installed, tested, and commissioned. The submittal article in Part 1 is your starting point, and the biggest mistake is treating it as the whole answer. ## The reading order ### 1. Start with the section's SUBMITTALS article List every item it demands, in its own words, with the paragraph reference next to each. "Shop drawings per 1.05.B." Keep the quotes and references; when a reviewer asks why the package includes something, or you need to argue it doesn't need something, the paragraph reference is the conversation. ### 2. Read the rest of Part 1 anyway Submittal demands hide outside the SUBMITTALS article constantly. Quality assurance articles demand certifications and qualification statements. Warranty articles demand warranty documentation. A FINAL DOCUMENTATION or CLOSEOUT article demands record drawings and O&M data, and those are real deliverables with real due dates even though they're due at the end. A section can put shop drawings in 1.2 and then demand a wiring diagram and attenuation distances in 1.3, and reading only the named article misses a deliverable the contract plainly requires. ### 3. Read Part 2 with your equipment schedule beside you Part 2 is where compliance lives. Every rating, feature, and option it specifies is something your submitted datasheet must demonstrate. Enclosure ratings, coil voltages, communication protocols, listed assemblies. As you read, mark each characteristic your equipment must prove; this list is what you'll [highlight on the datasheets](/learn/catalog-number-highlighting) so the reviewer can verify at a glance. Where Part 2 names acceptable manufacturers, check yours is on the list before you get attached to a part; if it isn't, that's a substitution request, which is its own formal process with its own timing. ### 4. Skim Part 3 for test and commissioning submittals Execution articles frequently demand test procedures before testing and test reports after. Both are submittals. The test procedure one is a classic schedule trap: it's often due for approval weeks before the test date, and discovering that during commissioning week means the test slips. ### 5. Then read Division 01, once, for the whole job Division 01 governs *how* to submit everything: format, copies, electronic procedures, timing, resubmittal rules, and the submittal log format the engineer expects. It applies to every section. Read it once at the start of the job and encode it into your package format, transmittal template, and [numbering scheme](/learn/submittal-numbering-revision-schemes). Note that different books put it in different places and number it differently; older specs use the five-digit 1995 numbers, and the section titled "Shop Drawings and Submittals" might be 01300, 01340, or 01 33 00 depending on the edition. Search by title, not number; [which divisions an integrator owns](/learn/csi-divisions-for-integrators) covers the numbering drift in detail. ## What the finished read produces One list per claimed section: every demanded item, quoted, with its paragraph reference, classified two ways. **By timing.** Items due before work proceeds (shop drawings, product data, test procedures) versus items due at closeout (record drawings, O&M data, warranties). Both are contractual; only the deadline differs. Tracking the closeout half from day one is what makes [closeout](/learn/control-system-closeout-checklist) uneventful. **By kind.** Product data, shop drawings, certifications, test documents. This decides how packages get grouped: one package per section is common, but a section demanding a test procedure usually wants it as its own later package rather than bundled with the product data. A section that demands nothing from your scope is a finding too. Write it down. "Reviewed 26 29 23, no submittals required of us" is one line that prevents the same hour being spent twice, and prevents a phantom obligation being invented under schedule pressure. ## When the spec is ambiguous Sometimes the read produces a genuine question: two paragraphs conflict, a demanded item doesn't apply to the actual scope, a referenced section doesn't exist in the book. Don't guess, and don't bury your interpretation in the submittal hoping nobody notices. That's what the RFI process is for, and the earlier it's asked the cheaper the answer; see [submittal versus RFI](/learn/submittal-vs-rfi). *Disclosure: I build [Submittal Kit](/), which indexes uploaded spec books by section, keeps every demand tied to its quoted paragraph, and turns the accepted list into the project's submittal register. The reading discipline above is the part no software replaces.* --- Submittal Kit · Learn · Updated 2026-08-17 Canonical: https://submittalkit.com/learn/read-a-spec-section-for-submittals