{"id":119,"date":"2026-08-12T13:31:08","date_gmt":"2026-08-12T13:31:08","guid":{"rendered":"https:\/\/www.ifieldsmart.ai\/knowledge-center\/?p=119"},"modified":"2026-08-12T13:31:09","modified_gmt":"2026-08-12T13:31:09","slug":"constructability-review-checklist","status":"publish","type":"post","link":"https:\/\/www.ifieldsmart.ai\/knowledge-center\/constructability-review\/constructability-review-checklist\/","title":{"rendered":"The Constructability Review Checklist: What to Check, by Discipline and by Phase"},"content":{"rendered":"\n

Ask three preconstruction managers for their constructability checklists, and you\u2019ll 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.<\/p>\n\n\n\n

A constructability review checklist<\/strong> 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.<\/p>\n\n\n\n

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.<\/p>\n\n\n\n

KEY TAKEAWAY<\/strong>
A checklist item is significant only if a reviewer has to be able to miss the condition without the item and the finding would alter the state of things. Items that fail either test are noise, and noise is why long checklists go unused.<\/th><\/tr><\/thead><\/table><\/figure>\n\n\n\n

Key Definitions: What a Checklist Is and Is Not<\/strong><\/strong><\/h2>\n\n\n\n

Constructability review checklist<\/strong> 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.<\/p>\n\n\n\n

Three things it is not.<\/p>\n\n\n\n

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.<\/p>\n\n\n\n

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.<\/p>\n\n\n\n

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.<\/p>\n\n\n\n

TABLE 1. ANATOMY OF A USABLE CHECKLIST ITEM<\/strong><\/p>\n\n\n\n

Element<\/strong><\/strong><\/th>Purpose<\/strong><\/strong><\/th>Weak version<\/strong><\/strong><\/th>Strong version<\/strong><\/strong><\/th><\/tr><\/thead>
Trigger<\/strong><\/td>Directs attention to a specific document location<\/td>Check the ceiling<\/td>Compare plenum depth against the sum of systems shown in section<\/td><\/tr>
Condition<\/strong><\/td>States what constitutes a finding<\/td>Adequate space?<\/td>Less than 2 inches clear between any two systems or structure<\/td><\/tr>
Discipline<\/strong><\/td>Assigns the item to a reviewer<\/td>Everyone<\/td>Mechanical, with architectural cross-check<\/td><\/tr>
Phase<\/strong><\/td>Prevents checking for detail that does not exist yet<\/td>All phases<\/td>DD and CD only<\/td><\/tr>
Response<\/strong><\/td>Captures outcome, not completion<\/td>Yes \/ No<\/td>Finding, no finding, or not applicable with reason<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

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.<\/p>\n\n\n\n

FIELD REALITY<\/strong>
The most common cause of an unused checklist is not length. It is items so general that a reviewer cannot answer them honestly. Faced with “verify coordination between trades,” the reasonable response is to check the box and move on, because the item asks for everything and therefore nothing.<\/th><\/tr><\/thead><\/table><\/figure>\n\n\n\n

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

    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.<\/p>\n\n\n\n

    Why Checklists Outperform Experience Alone<\/strong><\/strong><\/h2>\n\n\n\n

    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.<\/p>\n\n\n\n

    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.<\/p>\n\n\n\n

    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.<\/p>\n\n\n\n

    TABLE 2. UNSTRUCTURED REVIEW COMPARED WITH CHECKLIST-DRIVEN REVIEW<\/strong><\/p>\n\n\n\n

    Attribute<\/strong><\/strong><\/th>Experience-driven review<\/strong><\/strong><\/th>Checklist-driven review<\/strong><\/strong><\/th><\/tr><\/thead>
    Coverage<\/strong><\/td>Concentrated where the reviewer has been burned<\/td>Distributed across defined conditions<\/td><\/tr>
    Repeatability<\/strong><\/td>Varies by reviewer and by week<\/td>Substantially consistent<\/td><\/tr>
    Depth on novel conditions<\/strong><\/td>Strong; recognizes patterns no list contains<\/td>Weak; only finds what it asks about<\/td><\/tr>
    Dull-finding capture<\/strong><\/td>Poor; skips over undrawn details and omissions<\/td>Strong; this is what lists are for<\/td><\/tr>
    Transferability<\/strong><\/td>Leaves when the person leaves<\/td>Institutional asset<\/td><\/tr>
    Auditability<\/strong><\/td>Cannot demonstrate what was checked<\/td>Coverage is provable<\/td><\/tr>
    Automation potential<\/strong><\/td>None<\/td>High where items are written as conditions<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

    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.<\/p>\n\n\n\n

    Who Writes and Owns the Checklist<\/strong><\/strong><\/h2>\n\n\n\n

    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.<\/p>\n\n\n\n

    TABLE 3. CHECKLIST GOVERNANCE ROLES<\/strong><\/p>\n\n\n\n

    Role<\/strong><\/strong><\/th>Contribution<\/strong><\/strong><\/th>Cadence<\/strong><\/strong><\/th><\/tr><\/thead>
    Precon<\/strong> Director<\/strong><\/td>Owns the library; approves additions and retirements<\/td>Quarterly review<\/td><\/tr>
    Precon<\/strong> Manager<\/strong><\/td>Selects applicable checklists per project and per phase<\/td>Every project<\/td><\/tr>
    Superintendents<\/strong><\/td>Contribute sequence, access, and means-and-methods items<\/td>Post-project debrief<\/td><\/tr>
    Estimators<\/strong><\/td>Contribute biddability and quantity-clarity items<\/td>Post-bid debrief<\/td><\/tr>
    BIM \/ VDC Manager<\/strong><\/td>Contributes spatial and model-checkable items<\/td>Post-coordination<\/td><\/tr>
    Field leadership<\/strong><\/td>Reports recurring field issues for conversion into items<\/td>Continuous<\/td><\/tr>
    Owner facilities (where available)<\/strong><\/td>Contributes operability and maintainability items<\/td>Annually<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
    EXPERT TIP<\/strong>
    Assign every checklist section a named owner and put a review date on it. An item with no owner and no date is an item nobody will ever retire, which is how a 480-line document happens.<\/th><\/tr><\/thead><\/table><\/figure>\n\n\n\n

    Checklist Architecture: How to Organize It<\/strong><\/strong><\/h2>\n\n\n\n

    Organization decides usability. Four schemes are common and only one of them works well as the primary structure.<\/p>\n\n\n\n

    By discipline<\/strong> 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.<\/p>\n\n\n\n

    By phase<\/strong> 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.<\/p>\n\n\n\n

    By system<\/strong> 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.<\/p>\n\n\n\n

    By CSI division<\/strong> 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.<\/p>\n\n\n\n

    TABLE 4. PHASE APPLICABILITY MATRIX<\/strong><\/p>\n\n\n\n

    Checklist category<\/strong><\/strong><\/th>SD<\/strong><\/strong><\/th>DD<\/strong><\/strong><\/th>CD<\/strong><\/strong><\/th>Pre-bid<\/strong><\/strong><\/th>Shop <\/strong>dwg<\/strong><\/strong><\/th><\/tr><\/thead>
    Site logistics and access<\/strong><\/td>Primary<\/td>Verify<\/td>Verify<\/td>–<\/td>–<\/td><\/tr>
    System selection feasibility<\/strong><\/td>Primary<\/td>Verify<\/td>–<\/td>–<\/td>–<\/td><\/tr>
    Spatial adequacy and clearances<\/strong><\/td>Screen<\/td>Primary<\/td>Verify<\/td>–<\/td>Verify<\/td><\/tr>
    Cross-discipline coordination<\/strong><\/td>–<\/td>Primary<\/td>Primary<\/td>Screen<\/td>Verify<\/td><\/tr>
    Detail completeness<\/strong><\/td>–<\/td>Screen<\/td>Primary<\/td>Verify<\/td>–<\/td><\/tr>
    Drawing-to-spec consistency<\/strong><\/td>–<\/td>Screen<\/td>Primary<\/td>Verify<\/td>–<\/td><\/tr>
    Biddability and quantity clarity<\/strong><\/td>–<\/td>Screen<\/td>Primary<\/td>Primary<\/td>–<\/td><\/tr>
    Sequence and means-and-methods<\/strong><\/td>Primary<\/td>Primary<\/td>Verify<\/td>Screen<\/td>Verify<\/td><\/tr>
    Access, operability, maintainability<\/strong><\/td>Screen<\/td>Primary<\/td>Verify<\/td>–<\/td>Verify<\/td><\/tr>
    Interfaces and tolerances<\/strong><\/td>–<\/td>Screen<\/td>Primary<\/td>Primary<\/td>Primary<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

    “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.<\/p>\n\n\n\n

    The Core Discipline Checklists<\/strong><\/strong><\/h2>\n\n\n\n

    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.<\/p>\n\n\n\n

    Site and Civil<\/strong><\/strong><\/h3>\n\n\n\n

    TABLE 5. SITE AND CIVIL CHECKLIST<\/strong><\/p>\n\n\n\n

    Check<\/strong><\/strong><\/th>Finding condition<\/strong><\/strong><\/th><\/tr><\/thead>
    Crane placement and reach against building footprint<\/strong><\/td>No location provides coverage of all structural picks<\/td><\/tr>
    Laydown and staging area against site constraints<\/strong><\/td>Staging shown on area required for phase-one work<\/td><\/tr>
    Haul route, gate location, and turning radii<\/strong><\/td>Radii inadequate for concrete or steel delivery vehicles<\/td><\/tr>
    Excavation limits against property line and adjacent structures<\/strong><\/td>Shoring or underpinning required but not shown or specified<\/td><\/tr>
    Utility tie-in points and existing utility conflicts<\/strong><\/td>Tie-in location conflicts with existing utility of unknown depth<\/td><\/tr>
    Site grading against building entry and accessible route slopes<\/strong><\/td>Accessible route exceeds allowable slope at an entry<\/td><\/tr>
    Stormwater management sequencing against building construction<\/strong><\/td>Detention structure sits under required construction access<\/td><\/tr>
    Phasing and temporary access for occupied adjacent facilities<\/strong><\/td>Phase line severs an operational access the owner requires<\/td><\/tr>
    Dewatering requirements against groundwater information<\/strong><\/td>Groundwater indicated above excavation base, no dewatering scope<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

    Structural<\/strong><\/strong><\/h3>\n\n\n\n

    TABLE 6. STRUCTURAL CHECKLIST<\/strong><\/p>\n\n\n\n

    Check<\/strong><\/strong><\/th>Finding condition<\/strong><\/strong><\/th><\/tr><\/thead>
    Embeds, <\/strong>blockouts<\/strong>, and sleeves shown on structural drawings<\/strong><\/td>MEP penetrations appear on MEP drawings only<\/td><\/tr>
    Reinforcing congestion at joints, corbels, and pile caps<\/strong><\/td>Bar spacing insufficient for placement or vibration access<\/td><\/tr>
    Connection details drawn for every condition referenced<\/strong><\/td>Connection type called out but detail not provided<\/td><\/tr>
    Shoring, reshoring, and temporary bracing requirements<\/strong><\/td>Sequence implies shoring that the detail leaves no room for<\/td><\/tr>
    Slab depressions and thickened slabs against equipment layout<\/strong><\/td>Equipment pad location does not align with structural support<\/td><\/tr>
    Erection sequence feasibility against member sizes and access<\/strong><\/td>Member cannot be set after adjacent construction is complete<\/td><\/tr>
    Expansion and control joint continuity through assemblies<\/strong><\/td>Joint terminates at an assembly with no detail for the transition<\/td><\/tr>
    Tolerance compatibility with attached finish systems<\/strong><\/td>Structural tolerance exceeds what the cladding system accepts<\/td><\/tr>
    Camber and deflection against finish flatness requirements<\/strong><\/td>Deflection criteria conflict with specified floor flatness<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

    Architectural and Building Envelope<\/strong><\/strong><\/h3>\n\n\n\n

    TABLE 7. ARCHITECTURAL AND ENVELOPE CHECKLIST<\/strong><\/p>\n\n\n\n

    Check<\/strong><\/strong><\/th>Finding condition<\/strong><\/strong><\/th><\/tr><\/thead>
    Wall type schedule matched against every plan condition<\/strong><\/td>Plan shows a wall condition absent from the schedule<\/td><\/tr>
    Details drawn at every referenced callout<\/strong><\/td>Detail bubble references a sheet or detail that does not exist<\/td><\/tr>
    Waterproofing continuity at transitions and terminations<\/strong><\/td>Membrane detail stops at a match line with no continuation<\/td><\/tr>
    Air and vapor barrier continuity across assemblies<\/strong><\/td>Barrier interrupted at slab edge with no transition detail<\/td><\/tr>
    Dimensional closure on plans and sections<\/strong><\/td>Dimension strings do not sum to overall building dimension<\/td><\/tr>
    Fire and smoke rating continuity through penetrations<\/strong><\/td>Rated assembly penetrated with no firestop detail or listing<\/td><\/tr>
    Door and hardware clearance against wall and frame conditions<\/strong><\/td>Door swing conflicts with adjacent construction or equipment<\/td><\/tr>
    Roof drainage, overflow, and penetration coordination<\/strong><\/td>Roof drain location conflicts with structural framing<\/td><\/tr>
    Envelope installation sequence and access requirements<\/strong><\/td>Cladding sequence requires access the structure will block<\/td><\/tr>
    Interface between core, shell, and fit-out scopes<\/strong><\/td>Boundary between base building and tenant work undefined<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

    Mechanical \/ HVAC<\/strong><\/strong><\/h3>\n\n\n\n

    TABLE 8. MECHANICAL CHECKLIST<\/strong><\/p>\n\n\n\n

    Check<\/strong><\/strong><\/th>Finding condition<\/strong><\/strong><\/th><\/tr><\/thead>
    Plenum depth against the sum of all systems and structure<\/strong><\/td>Combined system depth exceeds available space in section<\/td><\/tr>
    Duct routing against structural members and beam penetrations<\/strong><\/td>Main duct crosses a beam with no approved penetration<\/td><\/tr>
    Equipment service and coil pull clearance dimensioned<\/strong><\/td>Coil pull space less than coil length<\/td><\/tr>
    Equipment rigging and replacement path to final location<\/strong><\/td>No path wide enough to set or remove equipment after enclosure<\/td><\/tr>
    Mechanical room clear dimensions against equipment and access<\/strong><\/td>Door or shaft too small to admit the specified equipment<\/td><\/tr>
    Condensate routing and drain availability at each unit<\/strong><\/td>No drain shown within reach of unit condensate connection<\/td><\/tr>
    Access panel provided at every in-ceiling device<\/strong><\/td>Damper or valve above a hard ceiling with no access<\/td><\/tr>
    Louver and intake free area against required airflow<\/strong><\/td>Louver size inadequate for scheduled airflow<\/td><\/tr>
    Vibration isolation and structural support coordination<\/strong><\/td>Isolator required but no structural support detail shown<\/td><\/tr>
    Testing, balancing, and commissioning access provisions<\/strong><\/td>Test port location inaccessible after ceiling installation<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

    Electrical<\/strong><\/strong><\/h3>\n\n\n\n

    TABLE 9. ELECTRICAL CHECKLIST<\/strong><\/p>\n\n\n\n

    Check<\/strong><\/strong><\/th>Finding condition<\/strong><\/strong><\/th><\/tr><\/thead>
    Working clearance at panels, switchgear, and disconnects<\/strong><\/td>Code-required working space obstructed by other construction<\/td><\/tr>
    Electrical room dimensions against equipment and clearance<\/strong><\/td>Equipment plus required clearance exceeds room dimension<\/td><\/tr>
    Feeder and conduit routing against structural and mechanical<\/strong><\/td>Feeder route passes through a congested zone with no space<\/td><\/tr>
    Cable tray routing, support, and access<\/strong><\/td>Tray shown above ductwork with no installation access<\/td><\/tr>
    Equipment connection points against owner-furnished equipment<\/strong><\/td>Connection point or characteristics undefined for OFE<\/td><\/tr>
    Panel schedules reconciled against connected loads on plans<\/strong><\/td>Load shown on plan absent from the panel schedule<\/td><\/tr>
    Lighting layout coordination with ceiling and structural grid<\/strong><\/td>Fixture location conflicts with structure or diffuser<\/td><\/tr>
    Grounding and bonding details at each required location<\/strong><\/td>Grounding referenced in spec but not detailed on drawings<\/td><\/tr>
    Emergency and standby system separation requirements<\/strong><\/td>Normal and emergency routing shown in a shared pathway<\/td><\/tr>
    Temporary power provisions during phased construction<\/strong><\/td>Phasing plan leaves an occupied area without service<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

    Plumbing and Fire Protection<\/strong><\/strong><\/h3>\n\n\n\n

    TABLE 10. PLUMBING AND FIRE PROTECTION CHECKLIST<\/strong><\/p>\n\n\n\n

    Check<\/strong><\/strong><\/th>Finding condition<\/strong><\/strong><\/th><\/tr><\/thead>
    Slope requirements against available depth in ceiling or slab<\/strong><\/td>Required slope cannot be achieved in the space provided<\/td><\/tr>
    Pipe routing against structural penetrations and sleeving<\/strong><\/td>Penetration shown where structural drawings prohibit it<\/td><\/tr>
    Wall thickness against carrier, chase, and fixture requirements<\/strong><\/td>Wall too thin to accept the specified carrier<\/td><\/tr>
    Cleanout and valve access at every required location<\/strong><\/td>Cleanout located behind finished, non-removable construction<\/td><\/tr>
    Sprinkler head layout against ceiling, ductwork, and lighting<\/strong><\/td>Head location obstructed by duct or fixture<\/td><\/tr>
    Standpipe and riser locations against stair and shaft layout<\/strong><\/td>Riser conflicts with stair framing or required egress width<\/td><\/tr>
    Fire pump room sizing, access, and drainage<\/strong><\/td>Room lacks the drainage the test header requires<\/td><\/tr>
    Backflow prevention location and required clearances<\/strong><\/td>Device location leaves no service access<\/td><\/tr>
    Roof drain and overflow coordination with structure<\/strong><\/td>Leader route crosses a structural member without provision<\/td><\/tr>
    Medical or specialty gas routing and valve access<\/strong><\/td>Zone valve located above an inaccessible ceiling<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

    Interiors and Finishes<\/strong><\/strong><\/h3>\n\n\n\n

    TABLE 11. INTERIORS AND FINISHES CHECKLIST<\/strong><\/p>\n\n\n\n

    Check<\/strong><\/strong><\/th>Finding condition<\/strong><\/strong><\/th><\/tr><\/thead>
    Finish schedule reconciled against every room on plans<\/strong><\/td>Room appears on plan with no finish schedule entry<\/td><\/tr>
    Ceiling type transitions and soffit details<\/strong><\/td>Transition between ceiling types shown with no detail<\/td><\/tr>
    Substrate requirements against specified finish systems<\/strong><\/td>Finish requires a substrate the wall type does not include<\/td><\/tr>
    Millwork and casework interface with MEP rough-in<\/strong><\/td>Casework blocks access to a required device<\/td><\/tr>
    Floor transitions, thresholds, and accessibility compliance<\/strong><\/td>Transition height exceeds accessible threshold limit<\/td><\/tr>
    Blocking and backing for wall-mounted items<\/strong><\/td>Mounted equipment shown with no backing indicated<\/td><\/tr>
    Acoustic assembly continuity above ceiling<\/strong><\/td>Rated partition stops at ceiling where spec requires deck<\/td><\/tr>
    Finish sequencing against wet trades and commissioning<\/strong><\/td>Finish installation precedes work that will damage it<\/td><\/tr>
    Mock-up and sample requirements against schedule<\/strong><\/td>Mock-up required with no schedule allowance<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

    Vertical Transportation and Specialties<\/strong><\/strong><\/h3>\n\n\n\n

    TABLE 12. VERTICAL TRANSPORTATION AND SPECIALTY SYSTEMS CHECKLIST<\/strong><\/p>\n\n\n\n

    Check<\/strong><\/strong><\/th>Finding condition<\/strong><\/strong><\/th><\/tr><\/thead>
    Hoistway<\/strong> dimensions, overhead, and pit depth against equipment<\/strong><\/td>Pit or overhead below manufacturer requirement<\/td><\/tr>
    Machine room location, access, and ventilation<\/strong><\/td>Access route to machine room too narrow for equipment<\/td><\/tr>
    Elevator sill, hall, and lobby interface details<\/strong><\/td>Sill detail absent at a shown condition<\/td><\/tr>
    Loading dock <\/strong>levelers<\/strong>, bumpers, and truck approach geometry<\/strong><\/td>Approach grade incompatible with trailer clearance<\/td><\/tr>
    Equipment anchorage against structural capacity and detail<\/strong><\/td>Anchorage referenced but not detailed or coordinated<\/td><\/tr>
    Specialty equipment utility requirements and connection points<\/strong><\/td>Utility characteristics undefined for specified equipment<\/td><\/tr>
    Access for future equipment replacement<\/strong><\/td>No removal path once adjacent construction is complete<\/td><\/tr>
    Seismic restraint and bracing where required<\/strong><\/td>Restraint required by spec but not shown on drawings<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
    IMPORTANT<\/strong>
    Every table above is organized by discipline, and the highest-value findings sit between disciplines. After running the discipline lists, run a cross-system pass on ceiling plenums, exterior wall assemblies, shafts, and equipment rooms. Those four locations generate a disproportionate share of field conflicts precisely because discipline-based review splits them apart.<\/th><\/tr><\/thead><\/table><\/figure>\n\n\n\n

    Running the Review Session<\/strong><\/strong><\/h2>\n\n\n\n

    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.<\/p>\n\n\n\n

    Work in sections, not in plans.<\/strong> 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.<\/p>\n\n\n\n

    Time-box by discipline and stop when the box closes.<\/strong> 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.<\/p>\n\n\n\n

    Pair the field with the office on the cross-system passes.<\/strong> 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.<\/p>\n\n\n\n

    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.<\/p>\n\n\n\n

    TABLE 13. SESSION STRUCTURE FOR A MID-SIZE COMMERCIAL SET<\/strong><\/p>\n\n\n\n

    Activity<\/strong><\/strong><\/th>Allocation<\/strong><\/strong><\/th>Sequence rationale<\/strong><\/strong><\/th><\/tr><\/thead>
    Set orientation and issuance check<\/strong><\/td>30 minutes<\/td>Confirm you are reviewing the current revision before anything else<\/td><\/tr>
    Discipline passes, sections first<\/strong><\/td>2 to 4 hours each<\/td>Sections carry the clearance and congestion findings<\/td><\/tr>
    Cross-system passes, paired<\/strong><\/td>1 hour each<\/td>Plenums, envelope, shafts, equipment rooms<\/td><\/tr>
    Biddability pass<\/strong><\/td>2 to 3 hours<\/td>Read as an estimator; anything requiring inference is a finding<\/td><\/tr>
    Prior-cycle verification<\/strong><\/td>1 hour<\/td>Confirm last cycle’s accepted comments actually appear<\/td><\/tr>
    Consolidation and severity<\/strong><\/td>2 to 3 hours<\/td>Merge duplicates across reviewers, then rank before issuing<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
    EXPERT TIP<\/strong>
    Have two reviewers cover the same discipline independently on the first project you run a new library on. The overlap tells you which items are working. The divergence tells you which items are ambiguous enough that two competent people read them differently, and those are the items to rewrite.<\/th><\/tr><\/thead><\/table><\/figure>\n\n\n\n

    Required Documentation<\/strong><\/strong><\/h2>\n\n\n\n

    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.<\/p>\n\n\n\n

    TABLE 14. DOCUMENTATION MATRIX<\/strong><\/p>\n\n\n\n

    Document<\/strong><\/strong><\/th>Role<\/strong><\/strong><\/th>Why the checklist needs it<\/strong><\/strong><\/th><\/tr><\/thead>
    Current drawing set<\/strong><\/td>Input<\/td>Subject of every item; must be the issued revision, not a working copy<\/td><\/tr>
    Specifications<\/strong><\/td>Input<\/td>Source of the thresholds many items measure against<\/td><\/tr>
    Equipment schedules<\/strong><\/td>Input<\/td>Clearance and access items cannot be checked without dimensions<\/td><\/tr>
    Project schedule<\/strong><\/td>Input<\/td>Basis for sequence and phasing items<\/td><\/tr>
    Site logistics plan<\/strong><\/td>Input<\/td>Basis for access, crane, and staging items<\/td><\/tr>
    Applicable code edition<\/strong><\/td>Input<\/td>Working clearance and rating items depend on the governing code<\/td><\/tr>
    Completed checklist with responses<\/strong><\/td>Output<\/td>Proof of coverage, including items marked not applicable and why<\/td><\/tr>
    Findings log<\/strong><\/td>Output<\/td>The actionable product; feeds the comment resolution cycle<\/td><\/tr>
    Not-applicable rationale<\/strong><\/td>Output<\/td>Prevents silent scope reduction on the next review<\/td><\/tr>
    Proposed checklist revisions<\/strong><\/td>Output<\/td>Keeps the library current instead of frozen<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
    WARNING<\/strong>
    Watch the not-applicable column. An item being marked not applicable for 3 consecutive Projects means it is either associated with a Project type you no longer pursue, or a Reviewer is using it as an exit. Both cases require a resolution, and neither issue resolves itself.<\/th><\/tr><\/thead><\/table><\/figure>\n\n\n\n

    Technology Integration<\/strong><\/strong><\/h2>\n\n\n\n

    Checklists live in one of four places, and the choice determines whether they can be measured.<\/p>\n\n\n\n

    TABLE 15. CHECKLIST PLATFORM COMPARISON<\/strong><\/p>\n\n\n\n

    Where it lives<\/strong><\/strong><\/th>Advantage<\/strong><\/strong><\/th>Limitation<\/strong><\/strong><\/th><\/tr><\/thead>
    Spreadsheet<\/strong><\/td>Zero friction to create and revise<\/td>No location linkage; versions proliferate; results not aggregable<\/td><\/tr>
    Markup platform<\/strong><\/td>Findings anchor to a sheet coordinate<\/td>Checklist itself usually lives outside the tool<\/td><\/tr>
    Project management module<\/strong><\/td>Responses become trackable records<\/td>Items often too generic; poor fit for measurable conditions<\/td><\/tr>
    Document intelligence \/ AI layer<\/strong><\/td>Items applied across the full set with traceable locations<\/td>Requires items written as measurable conditions<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

    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.<\/p>\n\n\n\n

    AI-Assisted Opportunities<\/strong><\/strong><\/h2>\n\n\n\n

    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.<\/p>\n\n\n\n

    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.<\/p>\n\n\n\n

    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.<\/p>\n\n\n\n

    TABLE 16. CHECKLIST AUTOMATION SUITABILITY<\/strong><\/p>\n\n\n\n

    Item type<\/strong><\/strong><\/th>Automation suitability<\/strong><\/strong><\/th>Why<\/strong><\/strong><\/th><\/tr><\/thead>
    Reference integrity (callouts, schedules)<\/strong><\/td>Very high<\/td>Purely a matching problem across the set<\/td><\/tr>
    Dimensional threshold checks<\/strong><\/td>High<\/td>Comparison against a stated numeric minimum<\/td><\/tr>
    Drawing-to-specification conflict<\/strong><\/td>High<\/td>Text comparison between two document sets<\/td><\/tr>
    Schedule-to-plan reconciliation<\/strong><\/td>High<\/td>Structured comparison of two enumerations<\/td><\/tr>
    Access and clearance adequacy<\/strong><\/td>Moderate<\/td>Flagging is automatable; adequacy needs judgment<\/td><\/tr>
    Cross-discipline spatial conflict<\/strong><\/td>Moderate<\/td>Depends on whether systems are modeled or drawn<\/td><\/tr>
    Sequence and means-and-methods<\/strong><\/td>Low<\/td>Requires reasoning about temporary conditions<\/td><\/tr>
    Site logistics feasibility<\/strong><\/td>Low<\/td>Depends on equipment, labor, and local conditions<\/td><\/tr>
    Novel or unusual conditions<\/strong><\/td>Very low<\/td>By definition not on any checklist<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

    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.<\/p>\n\n\n\n

    BEST PRACTICE<\/strong>
    Rewrite your checklist for machine readability as a byproduct of adopting automated review. Convert every item into a stated condition with a threshold and a document location to inspect. The rewrite improves the checklist for human reviewers too, because vague items were never answerable honestly in the first place.<\/th><\/tr><\/thead><\/table><\/figure>\n\n\n\n

    Implementation: Building and Maintaining the Library<\/strong><\/strong><\/h2>\n\n\n\n

    TABLE 17. IMPLEMENTATION ROADMAP<\/strong><\/p>\n\n\n\n

    Phase<\/strong><\/strong><\/th>Duration<\/strong><\/strong><\/th>Activities<\/strong><\/strong><\/th>Exit criteria<\/strong><\/strong><\/th><\/tr><\/thead>
    0. Harvest<\/strong><\/td>1 to 2 weeks<\/td>Collect every existing checklist, personal or official. Interview the two reviewers everyone trusts<\/td>A single consolidated raw list<\/td><\/tr>
    1. Mine the field record<\/strong><\/td>2 weeks<\/td>Pull RFIs and change orders from three closed projects. Convert preventable ones into items<\/td>20 to 50 items grounded in real losses<\/td><\/tr>
    2. Deduplicate and sharpen<\/strong><\/td>1 to 2 weeks<\/td>Merge overlaps, delete unanswerable items, rewrite the rest as conditions<\/td>Each discipline under 40 items<\/td><\/tr>
    3. Tag<\/strong><\/td>1 week<\/td>Assign discipline, phase applicability, and severity default to every item<\/td>Filterable library<\/td><\/tr>
    4. Pilot<\/strong><\/td>One design phase<\/td>Run on a live project. Track which items produced findings and which never fired<\/td>Fire-rate data per item<\/td><\/tr>
    5. Prune and automate<\/strong><\/td>2 to 4 weeks<\/td>Retire dead items. Convert automatable items for AI-assisted application<\/td>Working split between machine and human items<\/td><\/tr>
    6. Maintain<\/strong><\/td>Quarterly<\/td>Review fire rates, add field lessons, retire stale items<\/td>Library changes every quarter<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

    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.<\/p>\n\n\n\n

    LESSONS LEARNED<\/strong>
    A firm I worked with cut their mechanical checklist from 118 items to 46 by retiring everything with a zero fire rate over two years. Findings per review went up, not down. Reviewers had been rationing attention across items they knew were dead, and the shorter list let them actually read the sheets.<\/th><\/tr><\/thead><\/table><\/figure>\n\n\n\n

    Best Practices for Checklist Design<\/strong><\/strong><\/h2>\n\n\n\n

    TABLE 18. CHECKLIST BEST PRACTICES AND VERIFICATION<\/strong><\/p>\n\n\n\n

    Practice<\/strong><\/strong><\/th>Why it matters<\/strong><\/strong><\/th>How to verify<\/strong><\/strong><\/th><\/tr><\/thead>
    Write items as measurable conditions<\/strong><\/td>Vague items cannot be answered or automated<\/td>Sample ten items; can each be answered without interpretation?<\/td><\/tr>
    Cap each discipline list at about 40 items<\/strong><\/td>Beyond that, reviewers ration attention<\/td>Count items per discipline per phase<\/td><\/tr>
    Tag phase applicability on every item<\/strong><\/td>Prevents checking for absent detail<\/td>Confirm no CD-only item appears in an SD review<\/td><\/tr>
    Record findings, not completion<\/strong><\/td>Yes\/no responses produce no usable data<\/td>Check that responses include not-applicable rationale<\/td><\/tr>
    Track fire rate per item<\/strong><\/td>Identifies dead weight and blind spots<\/td>Pull fire rates after every five projects<\/td><\/tr>
    Add a cross-system pass<\/strong><\/td>Discipline organization hides interface conditions<\/td>Confirm plenum, envelope, shaft, and equipment room passes ran<\/td><\/tr>
    Convert field losses into items<\/strong><\/td>Field lessons are the best source of new checks<\/td>Count items traceable to a specific past RFI or change order<\/td><\/tr>
    Retire on a schedule<\/strong><\/td>Libraries only grow unless pruning is scheduled<\/td>Confirm items were removed, not just added, last quarter<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

    Common Mistakes<\/strong><\/strong><\/h2>\n\n\n\n

    TABLE 19. COMMON CHECKLIST MISTAKES AND CORRECTIONS<\/strong><\/p>\n\n\n\n

    Mistake<\/strong><\/strong><\/th>Why it happens<\/strong><\/strong><\/th>Consequence<\/strong><\/strong><\/th>Correction<\/strong><\/strong><\/th><\/tr><\/thead>
    Items too vague to answer<\/strong><\/td>Broad wording feels comprehensive<\/td>Reviewers tick boxes without looking<\/td>Rewrite as a condition with a threshold<\/td><\/tr>
    Library grows without pruning<\/strong><\/td>Adding is easy, removing feels risky<\/td>Reviewers ration attention across dead items<\/td>Track fire rate and retire quarterly<\/td><\/tr>
    One list for all phases<\/strong><\/td>Simpler to maintain<\/td>SD reviews ask for absent detail<\/td>Tag phase applicability per item<\/td><\/tr>
    Yes\/no response format<\/strong><\/td>Standard form design<\/td>No data on what was actually observed<\/td>Finding \/ no finding \/ N-A with reason<\/td><\/tr>
    Copied from a generic template<\/strong><\/td>Fast to start<\/td>Nothing reflects your field experience<\/td>Mine your own RFIs and change orders<\/td><\/tr>
    Discipline-only organization<\/strong><\/td>Matches reviewer assignment<\/td>Interface conditions go unexamined<\/td>Add cross-system passes<\/td><\/tr>
    No named owner<\/strong><\/td>Everyone assumes precon owns it<\/td>Library ages out silently<\/td>Assign section owners with review dates<\/td><\/tr>
    Treating the list as the whole review<\/strong><\/td>Coverage feels like completeness<\/td>Novel conditions get missed entirely<\/td>Reserve expert time after the list is run<\/td><\/tr>
    Checklist stored in personal files<\/strong><\/td>Convenience<\/td>Three private practices, no institution<\/td>One library, versioned, centrally owned<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

    Industry Examples Across Project Types<\/strong><\/strong><\/h2>\n\n\n\n

    TABLE 20. SECTOR-SPECIFIC CHECKLIST EMPHASIS<\/strong><\/p>\n\n\n\n

    Project type<\/strong><\/strong><\/th>Checklist emphasis<\/strong><\/strong><\/th>High-yield item<\/strong><\/strong><\/th><\/tr><\/thead>
    Commercial office<\/strong><\/td>Core-and-shell to fit-out interface, plenum depth<\/td>Verify base building scope boundary is defined at every interface<\/td><\/tr>
    Data <\/strong>center<\/strong><\/td>Equipment access, repeated modules, electrical clearance<\/td>Verify replacement path exists for every unit in a repeated row<\/td><\/tr>
    Healthcare<\/strong><\/td>Above-ceiling density, access panels, phasing under occupancy<\/td>Verify access panel at every in-ceiling valve, damper, and device<\/td><\/tr>
    Industrial \/ process<\/strong><\/td>Rigging paths, equipment anchorage, utility routing<\/td>Verify equipment can be set and removed after enclosure<\/td><\/tr>
    Manufacturing<\/strong><\/td>Owner-furnished equipment interfaces, floor tolerance<\/td>Verify every OFE connection point and characteristic is defined<\/td><\/tr>
    Infrastructure<\/strong><\/td>Staging, phasing, agency and permit constraints<\/td>Verify assumed closures are permitted for the assumed duration<\/td><\/tr>
    Multifamily residential<\/strong><\/td>Typical unit details, shaft alignment, envelope transitions<\/td>Verify each unit type detail resolves at every stack condition<\/td><\/tr>
    Institutional \/ education<\/strong><\/td>Biddability, summer phasing, public procurement clarity<\/td>Verify every room on plan has a finish schedule entry<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

    Data Center: Checking the Module, Not the Sheet Count<\/strong><\/strong><\/h3>\n\n\n\n

    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.<\/p>\n\n\n\n

    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.<\/strong><\/strong><\/h3>\n\n\n\n

    Healthcare: The Access Panel Item Pays for the Library<\/strong><\/strong><\/h3>\n\n\n\n

    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.<\/p>\n\n\n\n

    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.<\/p>\n\n\n\n

    Multifamily: One Detail, Two Hundred Occurrences<\/strong><\/strong><\/h3>\n\n\n\n

    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.<\/p>\n\n\n\n

    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.<\/p>\n\n\n\n

    Manufacturing: The Interface Nobody Owns<\/strong><\/strong><\/h3>\n\n\n\n

    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?<\/p>\n\n\n\n

    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.<\/p>\n\n\n\n

    Frequently Asked Questions<\/strong><\/strong><\/h2>\n\n\n\n

    What is a constructability review checklist?<\/strong><\/strong><\/h3>\n\n\n\n

    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.<\/p>\n\n\n\n

    How long should a constructability checklist be?<\/strong><\/strong><\/h3>\n\n\n\n

    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.<\/p>\n\n\n\n

    Should the checklist be organized by discipline or by CSI division?<\/strong><\/strong><\/h3>\n\n\n\n

    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.<\/p>\n\n\n\n

    How do we know if a checklist item is worth keeping?<\/strong><\/strong><\/h3>\n\n\n\n

    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.<\/p>\n\n\n\n

    Can we use a generic industry checklist template?<\/strong><\/strong><\/h3>\n\n\n\n

    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.<\/p>\n\n\n\n

    How does the checklist change between design phases?<\/strong><\/strong><\/h3>\n\n\n\n

    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.<\/p>\n\n\n\n

    Who should be responsible for maintaining the checklist library?<\/strong><\/strong><\/h3>\n\n\n\n

    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.<\/p>\n\n\n\n

    Can AI apply our checklist automatically?<\/strong><\/strong><\/h3>\n\n\n\n

    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.<\/p>\n\n\n\n

    How should we handle items that do not apply to a project?<\/strong><\/strong><\/h3>\n\n\n\n

    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.<\/p>\n\n\n\n

    Does a checklist review replace an experienced reviewer?<\/strong><\/strong><\/h3>\n\n\n\n

    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.<\/p>\n\n\n\n

    What is the single highest-value checklist item?<\/strong><\/strong><\/h3>\n\n\n\n

    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.<\/p>\n\n\n\n

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

      Conclusion<\/strong><\/strong><\/h2>\n\n\n\n

      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.<\/p>\n\n\n\n

      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.<\/p>\n\n\n\n

      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.<\/p>\n\n\n\n

      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.<\/p>\n\n\n\n

      KEY TAKEAWAY<\/strong>
      Write items as measurable conditions, cap the length, tag the phase, record findings rather than completion, and track fire rate so the library prunes itself. Then add the cross-system passes, because the conditions that hurt most live between the disciplines your checklist is organized by.<\/th><\/tr><\/thead><\/table><\/figure>\n\n\n\n

      <\/p>\n","protected":false},"excerpt":{"rendered":"

      Ask three preconstruction managers for their constructability checklists, and you\u2019ll 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 […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[6],"tags":[],"class_list":["post-119","post","type-post","status-publish","format-standard","hentry","category-constructability-review"],"yoast_head":"\nConstructability Review Checklist | iFieldSmart AI<\/title>\n<meta name=\"description\" content=\"Use this constructability review checklist to verify design quality, improve coordination, identify constructability issues, and reduce construction risks.\" \/>\n<meta name=\"robots\" content=\"index, follow, max-snippet:-1, max-image-preview:large, max-video-preview:-1\" \/>\n<link rel=\"canonical\" href=\"https:\/\/www.ifieldsmart.ai\/knowledge-center\/constructability-review\/constructability-review-checklist\/\" \/>\n<meta property=\"og:locale\" content=\"en_US\" \/>\n<meta property=\"og:type\" content=\"article\" \/>\n<meta property=\"og:title\" content=\"Constructability Review Checklist | iFieldSmart AI\" \/>\n<meta property=\"og:description\" content=\"Use this constructability review checklist to verify design quality, improve coordination, identify constructability issues, and reduce construction risks.\" \/>\n<meta property=\"og:url\" content=\"https:\/\/www.ifieldsmart.ai\/knowledge-center\/constructability-review\/constructability-review-checklist\/\" \/>\n<meta property=\"og:site_name\" content=\"knowledge-center\" \/>\n<meta property=\"article:published_time\" content=\"2026-08-12T13:31:08+00:00\" \/>\n<meta property=\"article:modified_time\" content=\"2026-08-12T13:31:09+00:00\" \/>\n<meta name=\"author\" content=\"ifieldsmart.ai\" \/>\n<meta name=\"twitter:card\" content=\"summary_large_image\" \/>\n<meta name=\"twitter:label1\" content=\"Written by\" \/>\n\t<meta name=\"twitter:data1\" content=\"ifieldsmart.ai\" \/>\n\t<meta name=\"twitter:label2\" content=\"Est. reading time\" \/>\n\t<meta name=\"twitter:data2\" content=\"29 minutes\" \/>\n<script type=\"application\/ld+json\" class=\"yoast-schema-graph\">{\"@context\":\"https:\\\/\\\/schema.org\",\"@graph\":[{\"@type\":\"Article\",\"@id\":\"https:\\\/\\\/www.ifieldsmart.ai\\\/knowledge-center\\\/constructability-review\\\/constructability-review-checklist\\\/#article\",\"isPartOf\":{\"@id\":\"https:\\\/\\\/www.ifieldsmart.ai\\\/knowledge-center\\\/constructability-review\\\/constructability-review-checklist\\\/\"},\"author\":{\"name\":\"ifieldsmart.ai\",\"@id\":\"https:\\\/\\\/www.ifieldsmart.ai\\\/knowledge-center\\\/#\\\/schema\\\/person\\\/51f5e238c4ca5a90257a3a2a63299411\"},\"headline\":\"The Constructability Review Checklist: What to Check, by Discipline and by Phase\",\"datePublished\":\"2026-08-12T13:31:08+00:00\",\"dateModified\":\"2026-08-12T13:31:09+00:00\",\"mainEntityOfPage\":{\"@id\":\"https:\\\/\\\/www.ifieldsmart.ai\\\/knowledge-center\\\/constructability-review\\\/constructability-review-checklist\\\/\"},\"wordCount\":6401,\"commentCount\":0,\"articleSection\":[\"Constructability Review\"],\"inLanguage\":\"en-US\",\"potentialAction\":[{\"@type\":\"CommentAction\",\"name\":\"Comment\",\"target\":[\"https:\\\/\\\/www.ifieldsmart.ai\\\/knowledge-center\\\/constructability-review\\\/constructability-review-checklist\\\/#respond\"]}]},{\"@type\":\"WebPage\",\"@id\":\"https:\\\/\\\/www.ifieldsmart.ai\\\/knowledge-center\\\/constructability-review\\\/constructability-review-checklist\\\/\",\"url\":\"https:\\\/\\\/www.ifieldsmart.ai\\\/knowledge-center\\\/constructability-review\\\/constructability-review-checklist\\\/\",\"name\":\"Constructability Review Checklist | iFieldSmart AI\",\"isPartOf\":{\"@id\":\"https:\\\/\\\/www.ifieldsmart.ai\\\/knowledge-center\\\/#website\"},\"datePublished\":\"2026-08-12T13:31:08+00:00\",\"dateModified\":\"2026-08-12T13:31:09+00:00\",\"author\":{\"@id\":\"https:\\\/\\\/www.ifieldsmart.ai\\\/knowledge-center\\\/#\\\/schema\\\/person\\\/51f5e238c4ca5a90257a3a2a63299411\"},\"description\":\"Use this constructability review checklist to verify design quality, improve coordination, identify constructability issues, and reduce construction risks.\",\"breadcrumb\":{\"@id\":\"https:\\\/\\\/www.ifieldsmart.ai\\\/knowledge-center\\\/constructability-review\\\/constructability-review-checklist\\\/#breadcrumb\"},\"inLanguage\":\"en-US\",\"potentialAction\":[{\"@type\":\"ReadAction\",\"target\":[\"https:\\\/\\\/www.ifieldsmart.ai\\\/knowledge-center\\\/constructability-review\\\/constructability-review-checklist\\\/\"]}]},{\"@type\":\"BreadcrumbList\",\"@id\":\"https:\\\/\\\/www.ifieldsmart.ai\\\/knowledge-center\\\/constructability-review\\\/constructability-review-checklist\\\/#breadcrumb\",\"itemListElement\":[{\"@type\":\"ListItem\",\"position\":1,\"name\":\"Home\",\"item\":\"https:\\\/\\\/www.ifieldsmart.ai\\\/knowledge-center\\\/\"},{\"@type\":\"ListItem\",\"position\":2,\"name\":\"The Constructability Review Checklist: What to Check, by Discipline and by Phase\"}]},{\"@type\":\"WebSite\",\"@id\":\"https:\\\/\\\/www.ifieldsmart.ai\\\/knowledge-center\\\/#website\",\"url\":\"https:\\\/\\\/www.ifieldsmart.ai\\\/knowledge-center\\\/\",\"name\":\"knowledge-center\",\"description\":\"\",\"potentialAction\":[{\"@type\":\"SearchAction\",\"target\":{\"@type\":\"EntryPoint\",\"urlTemplate\":\"https:\\\/\\\/www.ifieldsmart.ai\\\/knowledge-center\\\/?s={search_term_string}\"},\"query-input\":{\"@type\":\"PropertyValueSpecification\",\"valueRequired\":true,\"valueName\":\"search_term_string\"}}],\"inLanguage\":\"en-US\"},{\"@type\":\"Person\",\"@id\":\"https:\\\/\\\/www.ifieldsmart.ai\\\/knowledge-center\\\/#\\\/schema\\\/person\\\/51f5e238c4ca5a90257a3a2a63299411\",\"name\":\"ifieldsmart.ai\",\"image\":{\"@type\":\"ImageObject\",\"inLanguage\":\"en-US\",\"@id\":\"https:\\\/\\\/secure.gravatar.com\\\/avatar\\\/90da01ed02edb6771e02823045695eb8320e44660e511fb3d1127d83b67543e8?s=96&d=mm&r=g\",\"url\":\"https:\\\/\\\/secure.gravatar.com\\\/avatar\\\/90da01ed02edb6771e02823045695eb8320e44660e511fb3d1127d83b67543e8?s=96&d=mm&r=g\",\"contentUrl\":\"https:\\\/\\\/secure.gravatar.com\\\/avatar\\\/90da01ed02edb6771e02823045695eb8320e44660e511fb3d1127d83b67543e8?s=96&d=mm&r=g\",\"caption\":\"ifieldsmart.ai\"},\"sameAs\":[\"https:\\\/\\\/www.ifieldsmart.ai\\\/knowledge-center\"],\"url\":\"https:\\\/\\\/www.ifieldsmart.ai\\\/knowledge-center\\\/author\\\/ifieldsmart-ai\\\/\"}]}<\/script>\n<!-- \/ Yoast SEO plugin. -->","yoast_head_json":{"title":"Constructability Review Checklist | iFieldSmart AI","description":"Use this constructability review checklist to verify design quality, improve coordination, identify constructability issues, and reduce construction risks.","robots":{"index":"index","follow":"follow","max-snippet":"max-snippet:-1","max-image-preview":"max-image-preview:large","max-video-preview":"max-video-preview:-1"},"canonical":"https:\/\/www.ifieldsmart.ai\/knowledge-center\/constructability-review\/constructability-review-checklist\/","og_locale":"en_US","og_type":"article","og_title":"Constructability Review Checklist | iFieldSmart AI","og_description":"Use this constructability review checklist to verify design quality, improve coordination, identify constructability issues, and reduce construction risks.","og_url":"https:\/\/www.ifieldsmart.ai\/knowledge-center\/constructability-review\/constructability-review-checklist\/","og_site_name":"knowledge-center","article_published_time":"2026-08-12T13:31:08+00:00","article_modified_time":"2026-08-12T13:31:09+00:00","author":"ifieldsmart.ai","twitter_card":"summary_large_image","twitter_misc":{"Written by":"ifieldsmart.ai","Est. reading time":"29 minutes"},"schema":{"@context":"https:\/\/schema.org","@graph":[{"@type":"Article","@id":"https:\/\/www.ifieldsmart.ai\/knowledge-center\/constructability-review\/constructability-review-checklist\/#article","isPartOf":{"@id":"https:\/\/www.ifieldsmart.ai\/knowledge-center\/constructability-review\/constructability-review-checklist\/"},"author":{"name":"ifieldsmart.ai","@id":"https:\/\/www.ifieldsmart.ai\/knowledge-center\/#\/schema\/person\/51f5e238c4ca5a90257a3a2a63299411"},"headline":"The Constructability Review Checklist: What to Check, by Discipline and by Phase","datePublished":"2026-08-12T13:31:08+00:00","dateModified":"2026-08-12T13:31:09+00:00","mainEntityOfPage":{"@id":"https:\/\/www.ifieldsmart.ai\/knowledge-center\/constructability-review\/constructability-review-checklist\/"},"wordCount":6401,"commentCount":0,"articleSection":["Constructability Review"],"inLanguage":"en-US","potentialAction":[{"@type":"CommentAction","name":"Comment","target":["https:\/\/www.ifieldsmart.ai\/knowledge-center\/constructability-review\/constructability-review-checklist\/#respond"]}]},{"@type":"WebPage","@id":"https:\/\/www.ifieldsmart.ai\/knowledge-center\/constructability-review\/constructability-review-checklist\/","url":"https:\/\/www.ifieldsmart.ai\/knowledge-center\/constructability-review\/constructability-review-checklist\/","name":"Constructability Review Checklist | iFieldSmart AI","isPartOf":{"@id":"https:\/\/www.ifieldsmart.ai\/knowledge-center\/#website"},"datePublished":"2026-08-12T13:31:08+00:00","dateModified":"2026-08-12T13:31:09+00:00","author":{"@id":"https:\/\/www.ifieldsmart.ai\/knowledge-center\/#\/schema\/person\/51f5e238c4ca5a90257a3a2a63299411"},"description":"Use this constructability review checklist to verify design quality, improve coordination, identify constructability issues, and reduce construction risks.","breadcrumb":{"@id":"https:\/\/www.ifieldsmart.ai\/knowledge-center\/constructability-review\/constructability-review-checklist\/#breadcrumb"},"inLanguage":"en-US","potentialAction":[{"@type":"ReadAction","target":["https:\/\/www.ifieldsmart.ai\/knowledge-center\/constructability-review\/constructability-review-checklist\/"]}]},{"@type":"BreadcrumbList","@id":"https:\/\/www.ifieldsmart.ai\/knowledge-center\/constructability-review\/constructability-review-checklist\/#breadcrumb","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https:\/\/www.ifieldsmart.ai\/knowledge-center\/"},{"@type":"ListItem","position":2,"name":"The Constructability Review Checklist: What to Check, by Discipline and by Phase"}]},{"@type":"WebSite","@id":"https:\/\/www.ifieldsmart.ai\/knowledge-center\/#website","url":"https:\/\/www.ifieldsmart.ai\/knowledge-center\/","name":"knowledge-center","description":"","potentialAction":[{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https:\/\/www.ifieldsmart.ai\/knowledge-center\/?s={search_term_string}"},"query-input":{"@type":"PropertyValueSpecification","valueRequired":true,"valueName":"search_term_string"}}],"inLanguage":"en-US"},{"@type":"Person","@id":"https:\/\/www.ifieldsmart.ai\/knowledge-center\/#\/schema\/person\/51f5e238c4ca5a90257a3a2a63299411","name":"ifieldsmart.ai","image":{"@type":"ImageObject","inLanguage":"en-US","@id":"https:\/\/secure.gravatar.com\/avatar\/90da01ed02edb6771e02823045695eb8320e44660e511fb3d1127d83b67543e8?s=96&d=mm&r=g","url":"https:\/\/secure.gravatar.com\/avatar\/90da01ed02edb6771e02823045695eb8320e44660e511fb3d1127d83b67543e8?s=96&d=mm&r=g","contentUrl":"https:\/\/secure.gravatar.com\/avatar\/90da01ed02edb6771e02823045695eb8320e44660e511fb3d1127d83b67543e8?s=96&d=mm&r=g","caption":"ifieldsmart.ai"},"sameAs":["https:\/\/www.ifieldsmart.ai\/knowledge-center"],"url":"https:\/\/www.ifieldsmart.ai\/knowledge-center\/author\/ifieldsmart-ai\/"}]}},"_links":{"self":[{"href":"https:\/\/www.ifieldsmart.ai\/knowledge-center\/wp-json\/wp\/v2\/posts\/119","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.ifieldsmart.ai\/knowledge-center\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.ifieldsmart.ai\/knowledge-center\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.ifieldsmart.ai\/knowledge-center\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.ifieldsmart.ai\/knowledge-center\/wp-json\/wp\/v2\/comments?post=119"}],"version-history":[{"count":1,"href":"https:\/\/www.ifieldsmart.ai\/knowledge-center\/wp-json\/wp\/v2\/posts\/119\/revisions"}],"predecessor-version":[{"id":120,"href":"https:\/\/www.ifieldsmart.ai\/knowledge-center\/wp-json\/wp\/v2\/posts\/119\/revisions\/120"}],"wp:attachment":[{"href":"https:\/\/www.ifieldsmart.ai\/knowledge-center\/wp-json\/wp\/v2\/media?parent=119"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.ifieldsmart.ai\/knowledge-center\/wp-json\/wp\/v2\/categories?post=119"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.ifieldsmart.ai\/knowledge-center\/wp-json\/wp\/v2\/tags?post=119"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}