Curtain Wall Submittal Review

A general submittal review reads a package against the documents. A curtain wall package needs that plus one thing more: it has to be read as a system, because its failures are systemic. A drainage path is either continuous through every joint in the grid or it is not, and no single section shows that.

Workflow

Step 1. Establish what is being relied on

Ask, in one message:

1. What is in the package: plans, elevations, sections, details, calculations, test reports, samples?
2. Which specification section governs, and can you quote its performance requirements?
3. Is the system proprietary and previously tested, engineered for this project, or a hybrid? A hybrid is the case that needs the most attention and it is often not declared.
4. Which test reports are being relied on, and on what specimen?
5. Which adjoining assemblies does this meet, and have those been submitted?
6. What is the review turnaround, and what is on the critical path behind it?

Step 2. Trace drainage and pressure equalisation through the whole grid

Not at one section. Follow water from where it enters to where it leaves:

• Into the glazing pocket, out through the weeps: at every horizontal.
• Down the vertical joints: what carries it, and where does it cross a horizontal without leaking into the interior side?
• At the stack joint in a unitised system: the single most consequential detail in the package.
• At the bottom of the facade, and at every interruption: a spandrel, a floor slab, a change of module, a corner.
• Where the drainage discharges, and onto what.

If pressure equalisation is claimed, ask where the compartment boundaries are and whether they are continuous. A pressure-equalised system with unbounded compartments is a drained system with a claim attached.

Step 3. Trace the thermal break line

Follow it as one line around the whole facade, and report where it breaks:

• Through the vertical and horizontal members.
• At the stack joint and the anchor.
• Where the facade meets the slab edge, and whether the wall's insulation and the frame's break land on the same plane.
• At corners, at spandrels, at the head and the base.
• At every anchor and bracket, since anchors are usually steel through the insulation.

Report each break. Do not quantify: that is a hand-off.

Step 4. Check movement, then check the tested system against the drawn one

Movement. Where does the system take dead load, live load deflection of the slab, thermal movement, and building drift? Name the component that takes each. A stack joint that accommodates one of the four is a stack joint that fails on the others.

Tested against drawn. Compare the tested specimen with the submitted configuration and report each difference: module size, glass makeup, corner condition, anchor type, air seal detail, framing depth. Then say whether the package explains why each difference does not invalidate the test. It usually does not explain, and that is a legitimate comment.

Step 5. Give every interface an owner

List each assembly this facade meets and, for each, whether the package shows it, whether it shows it consistently with the other trade's package, and who is responsible for the joint:

• Slab edge and perimeter fire safing.
• Roof and parapet.
• Adjoining wall assemblies of a different type.
• Base of facade and any transition at grade.
• Doors, louvres, vents, and any penetration.
• Interior finishes returning to the frame.

An interface shown on neither package is the one that gets built twice.

Step 6. Write the comments and report

#	Comment	Where	Clause or drawing	System-level or local

Report the counts, system-level comments first. Then:

• What the package does not contain that the specification requires.
• Every difference between the tested and drawn systems, restated.
• Every interface with no owner.
• What has to be resolved before fabrication starts, separated from what can follow.

Close with the standing limits: no engineering was performed, no test report was validated, and this is comment rather than approval.

Step 7. Save, if asked

Ask whether to write the comments to a file and where, and write it directly.

Rules

• Never supply a performance criterion or a tolerance. They come from the specification, quoted.
• Trace drainage and the thermal break as continuous lines, never section by section.
• Report the tested-versus-drawn differences even when they look minor. The package should explain them; that it does not is the comment.
• Every interface gets an owner named or gets flagged as having none.
• Sort comments into system-level and local, and report system-level first.
• Never write approved, rejected, or take exception. Those are the Architect of Record's words.
• Say on every run that no engineering was performed.

Anti-patterns

• Reviewing the sections one at a time and never asking whether the drainage path closes.
• Accepting a pressure-equalisation claim without asking where the compartments are bounded.
• Treating the thermal break as continuous because it is continuous in the typical section.
• Recalling an air or water performance class because it is the usual one for this building type.
• Letting a hybrid system be reviewed as a proprietary tested one.
• Assuming an interface is the other trade's because it is not drawn here.
• Quoting a specification clause from memory.
• Sizing a mullion or checking a deflection. That is the facade engineer's.

Resources

None. This skill is one file. Output is written directly at the path you choose.