What Goes in a Control System Submittal Package

A submittal package is your answer to one question the engineer is legally required to ask: what exactly do you intend to supply? Before you build a panel, before you order a PLC, the reviewing engineer wants proof that the equipment you picked meets the spec they wrote. The package is that proof, bound into one document.

I spent years assembling these by hand as a controls PM, and the packages that sailed through review all had the same skeleton. This article is that skeleton. None of it requires any particular software. A PDF editor and patience will get you there; the point is knowing what "there" looks like.

The reviewer's mental model

The person stamping your package is usually a consulting engineer reviewing dozens of submittals across every trade on the job. They have your spec section open on one monitor and your package on the other. Their job is to find the mismatch. Your job is to make checking easy, because a reviewer who can't verify something quickly doesn't approve it on faith. They mark it Revise and Resubmit and move on to the next trade's package.

Everything below serves that one goal: let the reviewer confirm compliance without hunting.

The sections, in order

1. Cover sheet

Project name, your company, the client's project reference and your own, the spec section this package answers, the submittal number, and the revision. Both project references matter: the engineer files by their number, you track by yours, and a package that carries only one of them gets lost on somebody's desk.

2. Transmittal

The transmittal is the cover record of the exchange itself: what you sent, to whom, on what date, and what action you expect back. A submittal is sent under a transmittal, and on a well-run job every formal document exchange gets one. If a dispute ever reaches lawyers, the transmittal log is the first thing they ask for.

3. Table of contents

Numbered sections with page numbers, and in an electronic package, working bookmarks. A 120-page PDF without bookmarks tells the reviewer you didn't expect anyone to read it.

4. Equipment schedule or bill of materials

One line per supplied item: tag, description, manufacturer, catalog number, quantity. This is the index the whole package hangs off. Every catalog number here should appear again on a datasheet later in the package, and every datasheet should trace back to a line here.

5. Shop drawings

For a controls package this means panel layouts, wiring diagrams, and elevation views. These are your fabrication drawings, not the engineer's design drawings. If the spec calls for stamped drawings or specific title block content, this is where it gets checked. The full sheet-by-sheet inventory is its own article: what a complete panel drawing package includes.

6. Product data

The datasheets, one per catalog number. Two rules keep this section honest:

• Include the datasheet once, no matter how many tags use the part. Twelve copies of the same relay datasheet pad the page count and slow the review.
• Mark the exact catalog number being supplied. Most datasheets cover a whole product family across dozens of part numbers. An unmarked datasheet forces the reviewer to figure out which variant you meant, and many won't try. See catalog number highlighting for how to do this well.

7. Certifications and listings

Whatever the spec demands: UL 508A for the panel, area classifications, agency listings for individual components. Read the spec section's submittal article and pull the list from there rather than guessing; how to read a spec section for submittal requirements covers where the demands hide. A missing listing certificate is one of the most common reasons an otherwise complete package comes back.

8. Spares, warranties, and closeout items

If the spec requires spare parts, a warranty statement, or training commitments as part of the submittal, they go here. Some specs defer these to closeout instead; how the closeout deliverables differ from the submittal is covered in submittal, O&M manual, turnover package. The spec decides, not habit.

The difference between complete and compliant

Here's the trap: a package can contain every section above and still bounce. Complete means the documents are present. Compliant means the equipment on those documents meets the spec's requirements. The reviewer checks the second thing.

Before you send anything, do the review yourself. Open the spec section, find its submittal article, and walk the list: does every demanded item exist in your package? Then walk your equipment schedule: does every catalog number appear on a marked datasheet? Then the hard part: do the marked values actually satisfy what the spec asks for? That last pass is tedious, and it is exactly the pass the reviewer will do. Whoever does it first controls whether the package goes through in one cycle.

A pre-flight checklist

• Cover sheet carries both project references, the spec section, and the revision
• Transmittal filled out with the action requested and a response date
• Bookmarked table of contents matching the actual page order
• Every scheduled item traces to a datasheet, every datasheet traces to a scheduled item
• Shared datasheets appear once
• The supplied catalog number is marked on every datasheet
• Certifications match the spec's submittal article, item for item
• You reviewed the package against the spec before the engineer had the chance to

What happens after you send it, and what the engineer's stamp obligates you to do, is its own topic: see what Approved as Noted actually requires. And if you're deciding how to number the thing before it goes out, see submittal numbering and revision schemes.

Disclosure: I build Submittal Kit, which compiles packages with this structure from an equipment register. Everything in this article works just as well with a PDF editor and a careful afternoon.