Shop Drawings vs Product Data: Which One Is a Panel Submittal?

The new submittal form asks for a type. Shop drawing or product data? The panel package has fabrication drawings, so shop drawing. It also has forty datasheets, so product data. Pick wrong and nothing breaks today, but the log carries the wrong type code, the reviewer's expectation is set wrong before page one, and on a spec that lists the two as separate required submittals you have just delivered one of them.

The distinction is older than any software and comes from the contract documents. Here is where it lives and how to apply it.

Action versus informational, under 01 33 00

Division 01's submittal procedures section sorts every submittal into classes by what the engineer does with it. Action submittals require the engineer's responsive action: a stamp comes back. Shop drawings, product data, samples, certificates, and test procedures are the common members. Informational submittals are filed for the record without a returned action: coordination drawings, test and inspection reports, schedules of values, closeout material, maintenance material.

Real books split finer. The conformed spec for one plant expansion I hold lists action/informational submittals, closeout submittals, maintenance material submittals, and quality assurance submittals as four groups, and says that when the type isn't specified the engineer will determine it. The classes matter for one practical reason: an action submittal proceeds on a stamp, and an informational one proceeds on nothing. Sending an action item marked "for information" means it never gets reviewed and you build on air.

Shop drawings and product data are both action submittals. The difference between them is not what the engineer does; it's what the document is.

What makes a drawing a shop drawing

The general conditions define it. In the standard construction-industry wording, shop drawings are drawings, diagrams, schedules, and other data specially prepared for the work by the contractor or a supplier to illustrate some portion of the work. The operative words are specially prepared for the work. A shop drawing did not exist before this project. It shows how you will fabricate or install this specific thing on this specific job.

For a control panel: the enclosure layout with this panel's components in their positions, the wiring diagrams with this panel's wire numbers, the terminal strip layout, the nameplate schedule, the elevation. Every one of those was drawn for this job. They are shop drawings whatever the sheet border says. The full sheet list is in what a complete panel drawing package includes.

What product data covers

Same source, next definition: product data are illustrations, standard schedules, performance charts, instructions, brochures, diagrams, and other information furnished by the contractor to illustrate materials or equipment for some portion of the work. The operative word is standard. The manufacturer published it for everyone; you selected it for this job.

For a control panel: the PLC datasheet, the power supply cut sheet, the relay catalog page, the enclosure data. The datasheet exists whether or not your project does. Your contribution is the selection, which is why product data is only useful to a reviewer when the supplied catalog number is marked on it; see catalog number highlighting.

The test that settles most arguments: if you deleted the project, would the document still exist? A datasheet would. A wiring diagram would not.

Why a panel package is usually both

A control panel is a fabricated assembly of standard components. The assembly is shop drawings; the components are product data. A complete panel package therefore carries both, and the specs written by engineers who review panels for a living say so directly. A common clause, present in two of the Division 01 sections I work under, reads: all drawings, schematics, manufacturer's product data, certifications, and other drawing submittals required for a system specification shall be submitted at one time as a package to facilitate interface checking.

That clause is the answer to "which type." The reviewer wants the drawings and the datasheets together, because a panel layout cannot be checked without the dimensions of the parts on it, and a datasheet cannot be judged without knowing where the part is used. Splitting them into two packages to satisfy a type field makes both packages unreviewable and invites a Revise and Resubmit that says "provide the drawings" on one and "provide the product data" on the other.

Where the split is real is between the panel and the field. Field instruments are frequently a separate product data submittal, with their own ISA-style data sheets, sometimes under a different section. Test procedures are a separate action submittal due before testing. The O&M manual is a closeout submittal that reuses the same datasheets and lands months later; the taxonomy is in submittal, O&M manual, turnover package.

How the spec's submittal article decides

Every technical section's Part 1 carries a SUBMITTALS article, and its structure tells you how the engineer thinks about your package. Read it two ways.

If it lists shop drawings and product data as separate lettered items with distinct contents, the engineer expects to find both and may log them as two required submittals under the section. You can still deliver them as one bound package, but the transmittal should itemize both so the reviewer's log can be checked off. Some engineers will want two submittal numbers; ask at the preconstruction meeting.

If it lists one "shop drawings" item whose contents include product data (one process control section I hold puts data sheets, catalog literature, layout drawings, and wiring diagrams all under "Shop Drawings: Panels, Consoles, and Cabinets"), the engineer has already merged them. One package, one number, type shop drawing, and the datasheets ride inside.

Either way, the section's list is the checklist; how to read a spec section for submittal requirements covers pulling it out. The type you assign in your log should match the spec's word for the deliverable, not your habit.

Naming it in your numbering

Type codes exist so a log can be scanned by kind: SD for shop drawings, PD for product data, OM for the manual, TP for test procedures. They belong in the submittal number only if they earn their place. Two rules:

1. Use the spec's codes if it defines any. Federal-style books sort submittals under numbered submittal description codes, with shop drawings and product data as separate categories. Fighting that buys nothing.
2. For a combined panel package, code it by its governing document. A package whose approval hinges on the fabrication drawings is SD even though most of its pages are datasheets. A package of field instrument cut sheets with no fabrication content is PD. The reviewer reads the code as "what am I being asked to approve," and the drawings are what they approve on a panel.

Whatever you choose, be consistent within the job, and write the convention on the same page as the rest of your numbering scheme.

One example

A spec's process control section lists under action submittals: (a) field instruments, with data sheets per ISA 20; (b) panels, consoles, and cabinets, with layout drawings, product information on panel components, and wiring diagrams; (c) test procedures. The integrator sends:

Three packages, three numbers, each typed by what the reviewer is approving. The engineer's log matches the spec's three lettered items, and nobody has to explain why the panel package is "product data" with drawings in it.

Disclosure: I build Submittal Kit, where a new package picks its type from the action, closeout, and redline groups and the type's short code flows into the number. The distinction itself comes from the general conditions and belongs in your log however you keep it.