The air handler submittal arrives as one long PDF: selection printouts for six units, catalog pages with options circled, a sound data table, wiring diagrams and a warranty letter. Beside it sit the spec section it answers, the equipment schedule it has to match, and a submittal log that says it is already due.
The project engineer reviewing it makes a comparison before making a judgment. Does every scheduled value appear, at the conditions it was scheduled at? Does every spec requirement have an answer? Is every difference declared? Done by hand, that comparison is the stack: the spec on one screen, the schedule on another, the PDF on a third. This piece is about doing it line by line with AI, so the engineer's time goes to the differences that matter.
What a submittal has to answer
On most building projects, Division 01 sets the submittal procedure, often in section 01 33 00, and each Division 23 section lists what it needs in a Submittals article in Part 1. For mechanical equipment that usually means:
- Product data. Catalog pages and selection printouts showing the model, performance at scheduled conditions, options and accessories, electrical data, dimensions and weights.
- Shop drawings. Layouts for fabricated work such as ductwork and piping, and for equipment, dimensioned drawings, wiring diagrams and connection details.
- Supporting data. Sound and filter data, efficiency ratings, controls points lists and warranty terms.
A package answers three documents at once. The spec section says what the product must be: manufacturers, construction, performance, accessories. The equipment schedule says what each tagged unit must do: airflow, capacity, static pressure, electrical data, and a remarks column that is easy to skim past. The drawings say where it goes and what it connects to.
The package travels through the general contractor to the architect and the engineer of record, and returns with some version of no exceptions taken, make corrections noted, revise and resubmit, or rejected. Before it leaves, the contractor is supposed to check and stamp it. That first check is the subject here.
How review works today
The contractor's project engineer reads Part 2 of the spec against the cut sheets, paragraph by paragraph. Then the schedule, tag by tag, against selection printouts that present the same data in another order, sometimes in other units, often at other rating conditions. Then the remarks, the general notes and the plans.
It is careful work, and it fails in ways care alone does not prevent:
- Requirements are scattered. The one that matters may sit in a general note on another sheet, or in a related section such as 23 05 13 for motors.
- Manufacturer data is organized for the manufacturer. A selection printout lists what the software computes, not what the schedule asks for. A missing value does not announce itself.
- Options are encoded. A model number string decides whether the unit ships with a factory disconnect or a stainless drain pan.
- The schedule moved. An addendum revised the schedule after the supplier selected from the bid set, a delta of the kind we cover in revision control from IFD to as-built.
- Volume. A mid-size project carries dozens of Division 23 submittals, arriving in clusters.
Where deviations hide
Most deviations are not substitutions. They are small differences inside data that looks complete. The common ones, and where to look:
| Deviation | Where it hides | Compare against |
|---|---|---|
| Capacity at the wrong conditions | A selection rated at standard conditions instead of the scheduled entering air and ambient | Schedule capacities and design conditions |
| Airflow at a lower static | A fan curve run at less external static pressure than scheduled | Schedule airflow and external static |
| Electrical data | Voltage, phase, minimum circuit ampacity and overcurrent protection in a nameplate table; single-point versus multiple power connections | Schedule electrical columns, electrical drawings |
| Efficiency ratings | A full-load figure where the spec asks for part-load, or a rating not certified to the applicable AHRI standard | Spec Part 2, energy code requirements |
| Options and accessories | Model code strings, unmarked option boxes, items listed as field-installed or by others | Spec accessories paragraphs, schedule remarks |
| Filters | A lower MERV rating under ASHRAE 52.2, a different depth, a missing prefilter or filter rack | Section 23 41 00, schedule, unit spec |
| Sound data | Missing octave-band data, radiated instead of discharge, or data at a different operating point | Spec acoustic requirements, schedule |
| Controls interface | Factory controller versus field-installed DDC, protocol, points list, who furnishes sensors and drives | Section 23 09 00, sequence of operations |
| Physical fit | Dimensions, operating weight, coil handing, connection sizes, service clearances | Plans, sections, structural and roof drawings |
A careful reviewer catches most of these. Most is not a review standard, and the misses surface late: in the field, at testing and balancing, or at commissioning.
What a late resubmittal costs
A resubmittal is more than another review cycle. For equipment, it usually sits on the procurement path.
- Release waits on approval. Manufacturers generally will not release equipment to production without an approved submittal. On long-lead equipment such as air handlers and chillers, each extra cycle tends to push the ship date by about its own length.
- Other trades wait too. Roof curbs, structural supports, housekeeping pads, feeders sized from the minimum circuit ampacity, and controls submittals that need the points list. A changed selection can ripple into all of them.
- Pricing can move. A revised selection can change the equipment price, and quotes carry expiry dates.
- Silence is not approval. Most Division 01 submittal sections say some version of this: the engineer's review does not relieve the contractor of responsibility for meeting the contract documents unless a deviation was specifically identified. An undeclared difference can come back at startup, when fixing it means field work.
The cheapest deviation is the one you declare yourself. The most expensive is the one a reviewer approved without seeing.
How an AI-assisted check works
The check does what a careful reviewer does, in the same order, without tiring of tables.
Read the governing documents
The spec section is parsed into requirements: manufacturers, Part 2 performance and construction, accessories, and the data the Submittals article asks for. The latest issued schedule is read into tagged units with values, units and remarks. Each requirement keeps a reference to its paragraph or schedule cell.
Read the submittal
The package is split into its parts and values are extracted per tag. Marked options and model codes are decoded, and the rating conditions behind each performance figure are captured with the figure, because a capacity without its conditions cannot be compared.
Compare line by line
Each requirement gets one of four statuses:
- Meets, with the submittal page that shows it.
- Deviates, with the required value, the submitted value and both sources.
- Missing, when the spec or schedule asks for data the package does not contain, such as octave-band sound data or a points list.
- Needs judgment, when values cannot be compared directly, such as capacity rated at other conditions, or an option code read with low confidence.
Uncertain reads go to the engineer instead of being guessed, as we explain in why we verify every tag.
Draft the comments
For each deviation and missing item, the check drafts a comment the way a reviewer would write it: what was required, where, what was submitted, and what is needed. For example: "Selection for AHU-2 shows fan performance at a lower external static pressure than scheduled (schedule sheet M-601; submittal page 14). Provide a selection at the scheduled static." Every comment links to both pages.
The project engineer keeps the decision
Nothing in the check decides whether a deviation is acceptable. Some differences are fine: a manufacturer's standard option that exceeds the spec, a slightly larger unit that still fits the curb. Some need an RFI to the engineer of record. Some mean a new selection before the package leaves the office. Those are judgments about design intent, schedule, cost and the working relationship, and they belong to the project engineer.
What changes is what the engineer works from: a list instead of a stack, with every requirement, its status and the evidence on both sides one click away. The engineer accepts, edits or drops each draft comment, writes the deviation statement, and stamps the package. Each decision is recorded with the reviewer's name, so the next question about why a unit was accepted has an answer that does not live in one person's memory, a point we make in the retiring expert is a data problem.
The same comparison serves the design-side reviewer. But the contractor is the one whose schedule rides on a resubmittal, and the one best placed to catch a deviation before it costs a cycle.
What to standardize first
You do not need every submittal in the system on day one. A sequence that works:
- Start with scheduled equipment. Air handlers, rooftop units, terminal units, fans, pumps, chillers and boilers have schedules to compare against, long lead times, and the costliest resubmittals.
- Key the submittal log to spec sections and tags, so a package that covers three of four scheduled units is visible as such.
- Require a deviation statement on every package, even when the spec does not. A declared deviation is a conversation. An undeclared one is a liability.
- Ask suppliers for selections at scheduled conditions. It removes the most common needs-judgment item.
- Build a comment library. Standard language for recurring deviations keeps comments consistent across project engineers.
- Keep the outcomes. Which suppliers' standard selections tend to deviate from your usual specs, and on what, is worth more than any single review.
Review the differences, not the stack
Submittal review is a comparison with a judgment at the end. The comparison is tedious, high in volume and easy to get mostly right, which is the worst combination. A line-by-line check makes it complete and traceable, and leaves the engineer the part that needs an engineer: deciding which differences matter and what to say about them.
See how this fits mechanical work on our HVAC and construction pages, and how the verified document layer underneath works on the platform page.
