The Number on Page Two


The first design-day of the summer. The building is occupied, the rooftop units have been running since May, and by two in the afternoon the third floor is four degrees over setpoint and climbing. The balancer is back on the roof with the owner’s engineer, and the airflow is fine, the refrigerant charge is fine, the unit is doing everything it can. It is just not enough unit. At the ambient temperature the roof actually sees on a July afternoon, it is delivering a fraction of the capacity the specification required.
Somebody pulls the submittal. It was approved — stamped, no exceptions taken, nine months ago. The project manager finds the capacity on page two of the product data: it matches the spec number to the ton. He keeps reading. Four pages later, in a supplemental performance table nobody opened, the same unit is listed at the project’s design ambient, and the capacity in that row is the number the roof is producing right now.
The submittal was never wrong. The spec was never wrong. The comparison was — and it was stamped approved by everyone who touched it.
Manufacturers rate equipment at standard conditions. The headline capacity on a cut sheet is produced at a reference ambient, a reference entering condition, a reference everything — the industry-standard test point that lets one manufacturer’s unit be compared to another’s. It is a comparison number. It is not an application number, and it was never meant to be.
The specification asks for capacity at the project’s design conditions — the ambient the roof will actually see, the entering air the space will actually deliver. That value exists in the submittal. It sits in the supplemental tables, three or four pages past the headline, in a row the reviewer has to know to look for.
The reviewer does not look for it, and not through negligence. A design professional with five hundred submittals in the queue and a metering limit on how many clear each week reviews by comparison: find the spec value, find the submittal value, check that they match. Page two matches. The rating basis underneath the two numbers — that one was measured at a reference condition and the other was demanded at a project condition — is not on the page, so it is not part of the comparison. The spec is compared to a number that was never produced under the conditions the spec named, and because the digits agree, the stamp goes on.
It is the same failure on a chiller rated at one entering water temperature and specified at another, on a fan rated at one static pressure and installed against a higher one, on any piece of equipment whose performance depends on where it is put. The catalog number and the project number are not the same number, and a review that compares values without first matching the conditions the values were rated at will pass equipment that cannot do the job.
At submittal review, it is a finding. Capacity at project design ambient not demonstrated — supplemental table shows a lower value at that condition; a selection at design conditions is required. The manufacturer reselects. The unit gets one size larger, before fabrication, before the curb is built, before the feeder is sized, on a lead time the schedule already contained.
At the first design-day, it is a replacement in an occupied building. The larger unit needs a larger curb, so the roofer is back. The larger unit draws more, so the feeder and the breaker are checked and probably upsized. The structural engineer is asked whether the roof can take the weight. The lead time on the new unit is measured in months the owner does not have, and the tenants on the third floor are being told about portable coolers. And the meeting that follows has a stamped approval in the middle of the table — the architect’s stamp says reviewed for general conformance, the contractor’s stamp says reviewed, the sub says the data was in the package — and every party is correct, which is exactly why nobody is paying for it willingly.
One row in a supplemental table, read at submittal, or a mechanical system replaced at finish while the building is in use.
The trap is avoidable by rule, and the rule comes before the comparison: match the rating condition first, or do not compare.
Extract every requirement from the spec with its basis attached — not capacity, but capacity at the stated design conditions; not sound, but sound at the stated distance; not current, but current at the stated voltage. Then read the product data for the value produced at that basis, which means reading past the headline into the tables built for application rather than for comparison. When the submittal states a value with no basis at all, that is the loudest finding on the page — a number with no test condition is a number that cannot be verified, and it goes to unknown, not pass.
When the bases match, compare. When they do not, derate to the project condition if the data allows it, and flag it as unknown if it does not. And carry every finding with two citations — the spec paragraph that created the requirement and the submittal page that answered it — so the reviewer can open both, see the mismatch in thirty seconds, and put the exception on the stamp instead of approving a comparison that was never made.
That is what Arbiter does. It extracts every requirement with the condition it was written at, finds the value the submittal produced at that condition, and reports pass, fail, or unknown with both sources cited — including the supplemental table on page six that the headline on page two was hiding. Arbiter does not review submittals for you. It does the extraction and the comparison. You review the findings, apply your judgment, and send a submittal you can defend.