Envelope Checklist

A generic envelope checklist has two hundred items and applies to nobody. The useful one is short, is about this building, and separates what is late from what has not come up yet.

Workflow

Step 1. Take the building, not the phase

Ask, in one message:

1. What assemblies does this building have? Point at design-envelope if the type list exists.
2. What phase, and what is the next issue?
3. What is fixed already: a cladding, a module, a structure, a budget?
4. Is there a certification or a performance target being chased?
5. Who is on the team: an enclosure consultant, a facade engineer, or nobody?
6. Is this a new build, a renovation, or both?

Question 5 changes the list. A project with no enclosure consultant needs items on the architect's list that would otherwise be somebody else's, and saying which those are is part of the value.

Step 2. Build the list from the junctions, not the assemblies

Assemblies get drawn because they are on the wall type legend. Junctions get discovered one at a time in production. So the checklist is built junction-first:

#	Item	Kind	Should be resolved by	Status

Generate items for:

• Each assembly: build-up settled, values established, arithmetic run (condensation-check), buildability checked.
• Each junction, from design-envelope's schedule: base, top, corners, every change of type, every opening, floor lines, movement joints, penetrations, and where the envelope meets the roof and the ground.
• The cross-cutting decisions: air barrier plane, insulation position, drained or sealed, drying direction. One item each, for the whole building.
• The things that are not drawings: performance targets and their source, the mockup, testing, warranties, maintenance access (facade-access-study), and who is doing the specification.

Step 3. Say what should be resolved by now

For each item, a phase by which it should be settled, and the reason. Not a standard programme: the reason is what makes it arguable.

The ones that are usually later than they should be, and worth stating:

• The air barrier plane, because every junction detail depends on it.
• The insulation position, for the same reason.
• Whether the structure can carry the cladding attachment, because it changes the structural package.
• The mockup, because it needs a lead time and a place to build it.
• Maintenance access, because it changes the roof and the parapet.
• The specification, because it is written last and governs everything.

Step 4. Mark each item and count

Status is one of: resolved, open, on time, open, late, not started, somebody else's.

Report open, late first. Then somebody else's, with a name against each — an item assigned to a consultant who has not been appointed is not assigned.

Step 5. Report

• Late items, with what each is holding up.
• Items belonging to somebody who is not on the team yet.
• The cross-cutting decisions, and whether each is settled.
• Junctions with no detail yet, counted against the total from design-envelope.
• What can genuinely wait, said explicitly, so the list does not read as two hundred equally urgent things.

Step 6. Save

Ask where. It is re-run at every phase change against the same file, so the status column shows movement.

Rules

• Never supply a standard checklist. Generate it from this building.
• Build the list junction-first.
• Every item has a phase and a reason for that phase.
• Report open, late first, then items assigned to somebody not yet appointed.
• Say what can wait, explicitly.
• Never resolve an item here. Name the skill or the party.

Anti-patterns

• Handing over a generic two-hundred-item list.
• Listing assemblies and not junctions.
• A phase against each item with no reason behind it.
• Assigning items to a consultant who has not been appointed.
• Treating every open item as equally urgent.
• Leaving the specification, the mockup and maintenance access off, because they are not drawings.

Resources

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