This article deliberately publishes no code tables. Envelope requirements vary by code edition, by climate zone, by jurisdictional amendment and by compliance path, and a value copied from an article into a set that will be permitted becomes a liability. Read them off the applicable adopted code for your project.
Keeping the U-factor consistent across the drawing set, the spec and the compliance report
On most projects the fenestration U-factor lives in three documents at once: the window schedule on the drawings, the performance section of the specification, and the compliance report. Three documents, usually three different people, and no automatic relationship between them. The drift is a coordination problem, and it is the one that sends sets back from plan review.
A reviewer checking envelope compliance is doing a cross-reference. They read a value off the compliance report, find the corresponding assembly in the specification, then find it again in the window or door schedule on the drawings. When those three disagree, the set comes back, and it usually comes back late, because envelope review tends to happen after the parts of the review that block permit issuance.
The failure is almost never that somebody got the code wrong. It is that a value changed in one document and did not propagate to the other two.
The five places the values actually drift
Across the sets we work on, the same handful of divergences recur. None of them require a code question to explain.
1. A product substitution that never reached the schedule
A manufacturer is swapped during design development or value engineering. The specification section is revised. The window schedule on the drawings keeps the original performance values, because updating it was somebody else's sheet.
2. Whole-window performance confused with centre-of-glass
Product literature routinely publishes both. Compliance is concerned with the rated whole-assembly value, and centre-of-glass reads better, so it is the number that tends to get copied into a schedule. The two are not interchangeable and the difference is not small.
3. An assembly that exists on the drawings and not in the schedule
A transom, a borrowed light, a clerestory added in a later revision, a door with glazing that got scheduled as a door rather than as fenestration. Each one is an assembly with a performance value that the schedule does not carry.
4. A revision that landed on one sheet
Envelope values appear on more sheets than the schedule. Wall sections, details, and sometimes the code-summary sheet all restate them. A revision cloud on one of those does not update the others.
5. A compliance report built from an earlier set
Compliance documentation is often prepared once, relatively early, and then not rebuilt when the envelope changes. The report is internally consistent and describes a building that is no longer the one being permitted.
A cross-check that takes an hour and catches most of it
This is deliberately manual, because it should be possible for any team to run it on the current set without buying anything.
- Build one flat list of every glazed assembly in the set, taken from the drawings themselves. Walk the elevations and the plans. Include transoms, borrowed lights, clerestories and glazed doors.
- For each assembly, write down the performance values from three sources in three columns: the drawing schedule, the specification, and the compliance report.
- Mark every row where the three columns do not agree, and every row where a column is empty. Empty is itself a finding, so record it.
- For each product value, confirm you are reading the rated whole-assembly figure rather than a centre-of-glass figure. Note which document the number came from.
- Confirm the compliance report was built from the current drawing revision. Compare its revision reference against the set you are about to issue.
- Read the required values off the code edition and jurisdiction actually adopted for this project, and check your list against those. Adoption varies by state and sometimes by locality, and amendments are common, so this step has to be done against the applicable text every time.
Why fixing it once does not fix it
The cross-check above works and it does not hold, because the underlying condition is unchanged: three documents with no relationship between them, maintained by three people on different schedules. Run it before issuance and it catches that issuance. It tells you nothing about the next revision.
What makes it hold is having one source the three documents are generated from, and a record of which drawing page each value came from, so that a change in one place is visible everywhere it appears. That is a records problem before it is a software problem. Most firms already have the answer written down across their past projects and their standards, in a form nobody can query.
How we handle it
Mebbian builds a coordinated envelope performance schedule from the documents already on the project: the drawings, the specification sections and the product data. It reports the conflicts between what is drawn and what is specified, and leaves the call to the reviewer. Every value stays connected to the page it came from, so a reviewer can verify it against the source.
It does not certify compliance, sign, or submit. A qualified professional reviews and is accountable for the result, which follows the American Institute of Architects' guidance that architects remain accountable for all work products, including work produced with AI assistance.
If this is your week
Book the first call.
Forty-five minutes. We map your symbol library, your assembly rules and the conventions nobody wrote down. You keep the map whether or not anything else happens, and if we cannot help we say so on the call.