The Constructability Review Checklist: What to Check, by Discipline and by Phase

Ask three preconstruction managers for their constructability checklists, and you’ll probably end up with three very different documents. One will probably be a 480-line Excel spreadsheet that was passed down from an older co-worker who left the company in 2016. Another could be a two-page Word document with vague items such as “check coordination.” The third might not exist as a document at all, it lives in someone’s head. Instead, that person offers to walk you through their process, and it turns out to be the most thorough and valuable checklist of the three by a wide margin.

That firm had no checklist. It had three private practices and a shared belief that it had a checklist.

A constructability review checklist is the difference between a review that covers what matters and a review that covers whatever the reviewer happened to think of. It is also the artifact that makes review quality independent of which person got assigned, which is what turns individual competence into organizational capability.

This article is the content, not the theory. Structure first, then the actual checks by discipline, then how to keep the library alive instead of letting it calcify into a 480-line document nobody opens. For the surrounding process, see the companion article on the constructability review process. For how to classify what you find, see types of constructability issues.

Key Definitions: What a Checklist Is and Is Not

Constructability review checklist is a structured set of verification prompts applied to design documents, organized so that coverage is provable and results are comparable between reviewers and between projects.

Three things it is not.

It is not a specification. A specification states requirements the design must satisfy. A checklist asks whether the documents show enough for someone to build to those requirements. “Provide 12 inches clearance at coil pull” is a specification. “Verify coil pull clearance is dimensioned and unobstructed by adjacent systems” is a checklist item.

It is not a substitute for judgment. A good item prompts a reviewer to look somewhere specific. It does not tell them whether what they found is acceptable.

It is not a compliance form. The moment reviewers start checking boxes to demonstrate completion rather than to record findings, the checklist has become theater. This failure mode is common and it is usually caused by items that are too vague to answer honestly.

TABLE 1. ANATOMY OF A USABLE CHECKLIST ITEM

That last row deserves emphasis. A checklist with yes/no responses records whether the reviewer looked. A checklist with finding/no-finding/not-applicable records what they saw. Only the second one produces data you can improve from.

Objectives: What the Checklist Has to Accomplish

1. Make coverage provable. After a review, someone should be able to say which conditions were examined and which were not.
2. Make results comparable. Two reviewers on the same set should produce substantially similar findings.
3. Encode field experience. Every recurring field problem should exist as an item so it gets caught on paper next time.
4. Match phase to detail. Prompt for concept at schematic design and for detail adequacy at construction documents.
5. Enable delegation. A capable project engineer with a good checklist should produce a defensible first-pass review.
6. Support automated review. Structured, specific items are what make AI-assisted checking possible at all.

That last objective has changed how checklists should be written. An item phrased as a measurable condition against a stated threshold can be applied by software across an entire drawing set. An item phrased as a general area of concern cannot. The shift toward specificity was good practice before AI and is now close to mandatory.

Why Checklists Outperform Experience Alone

Experienced reviewers dislike checklists, and their objection is reasonable. A senior superintendent has pattern recognition no document can capture. Handing them a list feels like a downgrade.

The objection misses two things. First, expert attention is not uniformly distributed. Reviewers gravitate toward conditions they have been burned by and away from ones they have not. A superintendent who spent a decade on structural work will find structural issues at a rate that has nothing to do with where the project’s actual risk sits. Second, expertise does not transfer. When that person retires, their checklist retires with them unless somebody wrote it down.

The evidence in favor is mundane. On projects where the same set was reviewed both ways, the checklist review consistently catches a category of dull findings that expert review skips: a detail referenced but never drawn, an access panel omitted, a dimension that does not close. Individually trivial. Collectively they are a large share of the RFIs that get generated in the first ninety days of construction.

TABLE 2. UNSTRUCTURED REVIEW COMPARED WITH CHECKLIST-DRIVEN REVIEW

The right answer is both, in sequence. Run the checklist first to establish coverage, then give the experienced reviewer the remaining time to look for what the checklist cannot ask about. Reversing that order wastes the expert on work a list does better.

Who Writes and Owns the Checklist

Checklist ownership is where most libraries die. A well-intentioned precon manager builds one, uses it on two projects, gets promoted, and the document sits in a folder aging out of relevance.

TABLE 3. CHECKLIST GOVERNANCE ROLES

Checklist Architecture: How to Organize It

Organization decides usability. Four schemes are common and only one of them works well as the primary structure.

By discipline is the right primary organization. It matches how reviewers are assigned, how drawing sets are divided, and how AI-assisted reviews get prompted. “Generate a mechanical constructability report” maps directly onto a discipline-organized library.

By phase should be a filter applied on top, not a separate structure. Each item carries a phase applicability tag so a design development review shows only the items that make sense at design development.

By system works well as a secondary cut for cross-discipline conditions. Ceiling plenums, exterior wall assemblies, and shafts each involve four or five disciplines, and a system-based sub-checklist catches interactions that discipline-based review splits apart.

By CSI division is tempting because it aligns with specifications, and it is a poor primary organization for review because constructability conditions cross divisions constantly. Use it for cross-referencing, not for structure.

TABLE 4. PHASE APPLICABILITY MATRIX

“Primary” means this is the phase where the category gets full attention. “Verify” means confirm prior findings are resolved. “Screen” means a quick pass for anything obvious. That three-level distinction keeps reviews proportionate instead of running the whole library at every gate.

The Core Discipline Checklists

What follows is a working baseline. It is deliberately not exhaustive, because an exhaustive list is the thing nobody uses. Treat it as the spine and add your own field lessons to it.

Site and Civil

TABLE 5. SITE AND CIVIL CHECKLIST

Structural

TABLE 6. STRUCTURAL CHECKLIST

Architectural and Building Envelope

TABLE 7. ARCHITECTURAL AND ENVELOPE CHECKLIST

Mechanical / HVAC

TABLE 8. MECHANICAL CHECKLIST

Electrical

TABLE 9. ELECTRICAL CHECKLIST

Plumbing and Fire Protection

TABLE 10. PLUMBING AND FIRE PROTECTION CHECKLIST

Interiors and Finishes

TABLE 11. INTERIORS AND FINISHES CHECKLIST

Vertical Transportation and Specialties

TABLE 12. VERTICAL TRANSPORTATION AND SPECIALTY SYSTEMS CHECKLIST

Running the Review Session

A good library still produces a poor review if the session is run badly. Three habits separate reviews that generate useful findings from reviews that generate ticks.

Work in sections, not in plans. Most reviewers default to plan sheets because plans are where the project reads most legibly. Nearly every clearance, congestion, and coordination finding lives in section and in elevation. A reviewer who spends the whole session in plan will produce a log dominated by schedule reconciliation items and miss the expensive category entirely.

Time-box by discipline and stop when the box closes. Give each discipline a fixed allocation, roughly two to four hours per discipline for a mid-size commercial set, and hold to it. Reviewers who run long on the first discipline they open produce an exhaustive structural review and a superficial pass on everything after it. The distribution of findings then reflects the reading order rather than the project’s risk.

Pair the field with the office on the cross-system passes. Plenums, envelope assemblies, shafts, and equipment rooms are where discipline boundaries create blind spots, and they are also where a superintendent and a project engineer looking at the same section will see different things. An hour of paired review on those four locations reliably outproduces four hours of solo work anywhere else.

One more thing about the response discipline. If an evaluator can’t answer an item because the needed info is missing in the documents, then this is a finding. Not a not-applicable. “Cannot verify coil pull clearance; no equipment dimensions provided” is one of the more useful entries a log can carry, and reviewers routinely mark it not applicable instead because the item felt unanswerable. Train that explicitly. Unanswerable is a result.

TABLE 13. SESSION STRUCTURE FOR A MID-SIZE COMMERCIAL SET

Required Documentation

A checklist review needs specific inputs to be answerable, and it produces a record that has to be more useful than a page of ticks.

TABLE 14. DOCUMENTATION MATRIX

Technology Integration

Checklists live in one of four places, and the choice determines whether they can be measured.

TABLE 15. CHECKLIST PLATFORM COMPARISON

The practical requirement across all four is that a finding must carry a location the design team can navigate to. A checklist result that says “clearance inadequate” without a sheet and grid reference generates an argument rather than a revision.

AI-Assisted Opportunities

Checklist review is the part of constructability work that automates best, for a simple reason. The criteria are known in advance and the task is applying them uniformly to a large document set. That is a coverage problem, and coverage is where human reviewers reliably fall short.

An AI-assisted review takes the drawing set and the applicable checklists, extracts notes, dimensions, schedules, and detail references, then evaluates the conditions each item describes. Output is a findings list with sheet, grid, and level references and a description of the observed condition.

What that changes is which items are worth writing. Before automation, a checklist had to stay short enough for a person to work through in the available hours, so items got broad. With automated application, specificity becomes free. “Verify every detail bubble references an existing detail” is tedious for a human across 900 sheets and trivial for software.

TABLE 16. CHECKLIST AUTOMATION SUITABILITY

Read that table as an allocation guide. Give the top four rows to software and spend your senior reviewer’s hours on the bottom four, which is where their pattern recognition actually has an advantage.

Implementation: Building and Maintaining the Library

TABLE 17. IMPLEMENTATION ROADMAP

Phase 4 produces the number that matters most and almost nobody tracks: the fire rate per item. An item that has never produced a finding across ten projects is either badly written or checking something that does not occur in your work. Either way it is costing reviewer attention and returning nothing.

Best Practices for Checklist Design

TABLE 18. CHECKLIST BEST PRACTICES AND VERIFICATION

Common Mistakes

TABLE 19. COMMON CHECKLIST MISTAKES AND CORRECTIONS

Industry Examples Across Project Types

TABLE 20. SECTOR-SPECIFIC CHECKLIST EMPHASIS

Data Center: Checking the Module, Not the Sheet Count

Hyperscale work is repetition. The same electrical room, the same mechanical module, dozens of times. A checklist applied evenly across all sheets wastes most of its effort re-checking identical conditions.

Run the complete library extensively on every distinct instance of each repeated type, then perform a brief delta checklist on the remaining instances to ensure that they are indeed equivalent. Wherever it does not, wherever it does.

Healthcare: The Access Panel Item Pays for the Library

If a healthcare checklist contained one item, it should be the access panel check. Hospital ceilings hold valves, dampers, VAV boxes, isolation devices, and tube system components, most of them behind hard ceilings for infection control.

Every one of those requires access. Every missed one becomes either an RFI before the ceiling closes or a demolition after. It is a boring, mechanical, entirely checkable condition, which makes it exactly the kind of item that separates checklist review from expert review.

Multifamily: One Detail, Two Hundred Occurrences

On a recent architectural and interiors review of a multifamily project, fourteen findings spread across eight coordination categories. A small log by volume. One of them concerned a balcony threshold waterproofing transition drawn inconsistently between two sheets.

That single condition repeated at every unit with a balcony. The checklist item that catches it is unremarkable: verify waterproofing continuity at every transition and termination. The value comes from applying it to typical details rather than distributing attention across the sheet count.

Manufacturing: The Interface Nobody Owns

On manufacturing projects the owner procures production equipment directly. The general contractor builds the facility. The boundary between the two lives in scattered notes across the drawing set, and the checklist item that matters is dull: for every piece of owner-furnished equipment, is the connection point located and are the utility characteristics defined?

Answering that question for forty pieces of equipment during design costs a day. When an answer is found during commissioning, it is more financially burdensome than an entire day, and it is discovered at the time in the schedule when absolutely no one has any schedule flexibility.

Frequently Asked Questions

What is a constructability review checklist?

A constructability review checklist is a structured set of verification prompts applied to design documents so that coverage is provable and results are comparable between reviewers and projects. Each item should identify where to look, state what constitutes a finding, assign a responsible discipline, and indicate which design phases it applies to. It records observations rather than completion, which is what distinguishes a working checklist from a compliance form.

How long should a constructability checklist be?

Roughly 30 to 40 items per discipline per phase, which for a full commercial project yields somewhere between 200 and 320 items across all disciplines. Past that, reviewers begin rationing attention, and the marginal item costs more than it returns. If automated review handles part of the library, the human-facing portion should be shorter still, ideally under 20 items per discipline focused on judgment-dependent conditions.

Should the checklist be organized by discipline or by CSI division?

By discipline as the primary structure, because that matches how reviewers are assigned, how drawing sets are divided, and how AI-assisted reviews are prompted. CSI division works well as a secondary cross-reference for tying findings back to specification sections. Organizing primarily by CSI division tends to fragment conditions that span divisions, and most constructability issues span several.

How do we know if a checklist item is worth keeping?

Track its fire rate: how often it produces a finding across projects. An item with a zero fire rate over ten projects is either poorly written or checking a condition that does not occur in your work. Before discarding it, make sure it is actually dead and not reviewers skipping over it because they don’t know how to respond to it. Vague items look dead when they are actually just unanswerable.

Can we use a generic industry checklist template?

As a starting skeleton, yes. As your operating library, no. A generic template contains none of your field experience, and field experience is where the highest-yield items come from. The most productive two weeks you can spend on this is pulling RFIs and change orders from three closed projects, identifying which were preventable by document review, and converting each into an item. Those items will outperform anything from a template because they describe losses you actually took.

How does the checklist change between design phases?

Depth changes rather than subject. At schematic design, the checklist should focus on site logistics, system selection feasibility, and phasing, because that is what the documents can answer. Design development marks an increased awareness of spatial sufficiency, clearances, access, cross-group harmony, and several other interrelated factors. During the production of construction documents, the main focus shifts to the degree of completeness of details, drawing conformity to specifications, and the ability to attract potential bidders. Tag each item with phase applicability rather than maintaining separate lists, which drift apart.

Who should be responsible for maintaining the checklist library?

A named person, usually the preconstruction director, with section owners by discipline and a scheduled quarterly review. Contributions should come from superintendents for sequence and access items, estimators for biddability items, VDC for spatial items, and field leadership for recurring problems. The failure mode is universal: a library everyone uses and nobody owns will age out of relevance within about three years.

Can AI apply our checklist automatically?

For a meaningful portion of it, yes. Reference integrity checks, dimensional threshold comparisons, schedule-to-plan reconciliation, and drawing-to-specification conflicts automate well because they are matching and comparison problems. Access adequacy and spatial conflict partially automate: the system flags the condition and a human judges whether it is acceptable. Sequence, means and methods, and site logistics do not automate well because they require reasoning about temporary conditions that appear nowhere in the documents.

How should we handle items that do not apply to a project?

Mark them not applicable with a recorded reason rather than deleting them from the project’s list. The rationale matters for two purposes: it prevents silent scope reduction where reviewers quietly drop inconvenient items, and it surfaces patterns. When the same item is marked not applicable across several projects, that is a signal to either retire it or recognize that your project mix has shifted.

Does a checklist review replace an experienced reviewer?

No, and the sequencing matters. Run the checklist first to establish coverage on the conditions that are known and checkable, then give the experienced reviewer their remaining hours to look for what no list can anticipate. Reversing the order wastes expert attention on mechanical verification. Skipping the expert entirely leaves you exposed on novel conditions, which are by definition absent from any checklist.

What is the single highest-value checklist item?

Across most building types, verifying that every referenced detail actually exists on the drawings. Detail bubbles pointing at sheets that were never produced, or at detail numbers that changed between issuances, generate a steady stream of RFIs in the first months of construction. It is dull, entirely mechanical, invisible to expert intuition, and trivially automatable. Close behind it, on any project with concealed systems, is verifying access at every in-ceiling device.

Expert Recommendations

1. Start from your own losses, not a template. Three closed projects, their RFIs and change orders, classified for preventability. That exercise produces better items than any published list.
2. Rewrite every item as a condition with a threshold. If a reviewer has to interpret the item before answering it, it is not finished.
3. Cap each discipline at about 40 items and enforce the cap. Adding an item should require retiring one until you have fire-rate data to justify growth.
4. Interview the reviewer everyone trusts and write down what they check. That interview is the most valuable hour in the whole exercise, and it should happen before that person retires rather than after.
5. Add the cross-system passes. Plenums, envelope assemblies, shafts, equipment rooms. Discipline organization structurally hides these conditions.
6. Track fire rate from the first project. Without it you will never know which items are working, and the library will only grow.
7. Put the access panel item in every concealed-systems checklist. It is boring, it is mechanical, and it pays for the library on a single hospital project.
8. Retire something every quarter. A library that only grows is a library heading toward 480 lines and irrelevance.

Conclusion

The precon manager who kept his checklist in his head was the best reviewer of the three, and he was also the firm’s largest single point of failure. Everything he knew was real, tested, and undocumented.

A checklist library is how that knowledge stops being personal. It makes review coverage provable, results comparable, and quality independent of assignment. It gives a capable project engineer the means to produce a defensible first pass, which frees senior reviewers to spend their attention where pattern recognition actually matters.

Automated review has changed the economics in one specific way. Specificity used to be expensive, because a person had to work through every item. Now the mechanical items cost almost nothing to apply, which means the library can be far more precise than it used to be, and the human portion can shrink to what genuinely requires judgment.

What has not changed is where good items come from. They come from problems your firm already paid for. Mine the record, write the condition, tag the phase, track whether it fires, and retire what does not. That repeat is run for two or three years and generates a checklist that no template can capture. It tells a story about your work.