AIA Design Phase Deliverables for Data Center Engineers

The AIA phase model still earns its keep on a data center project, even now. It sets a shared language between owner, architect, and engineer. It gives the team a contract structure, one built on standard owner-architect and consultant agreements. It sets a milestone cadence everyone can plan around. None of that goes away on a critical facility, and none of it should. But the model was built around a building type where architecture leads and the mechanical, electrical, and plumbing systems follow its lead. In a data center, that order flips: the electrical distribution, the cooling plant, and the controls that run both are the actual product being built. The building envelope exists to protect them.

AIA's own description of basic services calls Design Development the phase that "lays out mechanical, electrical, plumbing, structural, and architectural details." That sentence puts MEP on the same shelf as door hardware and window trim. For an office building or a school, that's a fair way to rank things. For a data center, it buries the part of the project that the facility's operation actually depends on. So every checklist, deliverable list, and phase objective built from that ranking understates what engineers have to produce by the time each milestone closes.

If you follow the standard phase logic without adjusting it, missing this means you walk into DD review holding finished architectural drawings next to MEP work that's still unsettled. That's backward for this building type. The architecture on a data center is comparatively simple: a shell, a slab, a yard. The systems inside it carry the engineering complexity and the schedule risk, and they need to be the first thing locked down, not the last.

The Basis of Design as the load-bearing document across all phases

Data center engineering adds one document to the standard AIA framework that governs everything downstream of it: the Basis of Design. The BOD sets the IT load, the redundancy target, and the environmental parameters the facility has to hit. Every engineering document that follows, the single-line electrical diagrams, the mechanical layouts, the CFD airflow models, the rack-level white space plans, traces back to decisions made in that one document.

Think of the BOD as playing the role an architectural program plays on a conventional building. The owner has to sign off on it before anyone starts sizing equipment or coordinating trades. Skipping that step, or letting it drift unmanaged, stops the phases from building on each other the way they're supposed to. So instead of deepening a shared design intent across disciplines, Design Development turns into a pile of separate discipline deliverables that just happen to share a project number.

The BOD stays alive through Design Development, under version control, with every change tracked against the disciplines it touches. It locks before Construction Documents start. That lock matters because a change to redundancy targets or IT load after CDs are underway doesn't stay contained. It ripples through every electrical sheet, every mechanical sheet, every structural sheet already in production, and the later this happens, the more the rework costs.

Schematic Design deliverables for a data center project

The standard AIA Schematic Design package is a site plan, floor plans, sections, an elevation, and a cost estimate built from area, volume, or similar conceptual methods. None of that can actually get produced on a data center project until the electrical load, the cooling strategy, and the redundancy tier are already settled. Floor plans depend on equipment footprints. Sections depend on floor-to-floor heights driven by cooling distribution. The cost estimate depends on systems nobody has sized yet.

That means SD on a data center has to produce the Basis of Design alongside the schematic drawings, not after them. Structural bay spacing, floor-to-floor heights, and generator yard sizing all come downstream of the power and cooling strategy, so that strategy has to exist before those drawings can be anything more than guesses. The standard template doesn't ask you for a preliminary single-line diagram at SD. Data center practice requires one anyway, establishing utility service voltage, redundancy topology (N, N+1, or 2N), UPS configuration, and generator count and capacity.

Structural loading has become something that has to get decided this early too, especially on AI-driven projects. A purpose-built AI facility gets designed around slab-on-grade instead of raised floor, because the point loads from high-density compute racks can run well past what legacy raised-floor systems were rated to carry. That's a structural decision, and it has to happen in SD, not get pushed into DD where it's harder and more expensive to change.

Data hall layout at SD is a capacity model: gross white space area, anticipated rack count, average and peak power density by zone, and the hot-aisle/cold-aisle or containment strategy the facility will run on. Those numbers feed the structural, electrical, and mechanical sizing that follows, so they need to be real figures, not placeholders.

Cost estimating at this stage has to cover electrical systems, cooling infrastructure, and redundancy features, even though you know those numbers will keep moving as design progresses. AIA contract guidance is clear that the agreement needs to spell out who updates the estimate at each stage and who owns cost estimating for each discipline-specific system. If that's left undefined, nobody will take it on.

Design Development as the coordination crucible

AIA's DD quality management guidance organizes its phase task checklist under management, schedules, program and construction costs, regulatory requirements, performance criteria, civil and site design, architecture, structural, MEP/FP, and other consultants. That's a reasonable checklist for most buildings. For a data center, it leaves out structured cabling, EPMS topology, BMS control sequences, and DCIM integration architecture entirely, and those four gaps are where data center DD actually lives.

Three operational systems have to show up as named DD deliverables, not as work implied inside a generic MEP line item. The Building Management System controls the mechanical and environmental plant at the facility level. A power monitoring system tracks the electrical path from the utility incomer all the way to the rack. The Data Center Infrastructure Management platform manages IT assets, rack space, power capacity, and network connectivity out in the white space. DCIM pulls data from BMS and EPMS, but it doesn't replace either one. The outages that actually hurt happen in the gaps between these three systems, so those integration points need to get designed in DD. Finding them during commissioning is finding them too late.

Two deliverables get overlooked constantly, and both matter as much as anything on the standard checklist. Demarcation drawings mark future tie-in points so the facility can expand later without touching live operations. Sequences of operation spell out how each system is actually supposed to behave, and they have to match the installed system, not just the original design intent. Write a sequence of operation to match the drawings instead of the equipment that actually got installed, and commissioning will fail on that point every time.

AIA's DD guidance says the design team works out "a clear, coordinated description of all aspects of the design, including architectural, mechanical, electrical, plumbing, and fire protection systems." That's a fine description for a conventional building. On a data center, it's a floor, not a ceiling. So the engineer's DD scope needs its own addendum that names the systems that sentence leaves out.

BIM deserves a place in that DD package, but it can't be the whole package. A coordinated model helps enormously with clash detection and MEP coordination across trades. But structured cabling in a data center runs at a level of detail, individual patch paths, cable IDs, specific port assignments, that standard BIM level-of-development conventions were never built to carry. The DD deliverable set has to say so directly and define where that cabling data lives if it's not living inside the model.

CFD airflow modeling belongs in DD as a named deliverable, not as something saved for after construction to confirm what was already built. Resolving hot-spot risk and containment strategy before CDs go out avoids the expensive cycle of revising sheets and reworking procurement after the fact.

AIA's DD guidance also notes that these deliverables can support a trade-breakdown cost estimate, and they can feed owner approval processes, including boards and lending institutions. On a data center, that means the DD package has to be far enough along on electrical and mechanical systems to support a cost check that actually means something, since the building envelope is a small slice of total project value. A connected design environment, one where BMS points, EPMS topology, cabling scope, and sequences of operation live together instead of scattered across separate documents and separate disciplines, is what makes that level of coordination possible without losing track of any one piece along the way.

Construction Documents phase: where missing data center deliverables become contractual gaps

The AIA standard defines a Construction Documents package as a set of drawings carrying all the information a contractor needs to price and build the project. That definition works fine on its own for a conventional building, but on a data center it doesn't execute itself. It requires the project team to have already agreed, in writing, on what "all pertinent information" means for every critical system, because the standard CD template doesn't spell that out on its own.

Several systems need to appear as named CD deliverables even though the standard template never names them directly, so if you leave one out, it becomes a real gap, not just a paperwork oversight. Complete single-line electrical diagrams have to run all the way through rack-level distribution, covering UPS, static transfer switch, and PDU topology, because a diagram that stops short of the rack leaves the contractor guessing at exactly the part of the system that matters most. Medium-voltage service, low-voltage distribution, generator plant, and UPS specifications all need full detail at this stage too, since each one drives procurement lead times that can stretch many months, and a spec that's vague at CD issuance turns into a delay nobody sees coming until the order gets placed. Cooling system sequences of operation need to match the equipment that's actually specified and going to be installed, not just the design intent written months earlier, because a mismatch here is the same commissioning failure described back in DD, just discovered later and at higher cost to fix. EPMS topology drawings and point lists need to exist as their own deliverable, not as something you assume is buried inside an electrical sheet. BMS control sequences and integration architecture need the same treatment. Structured cabling plant drawings, fiber routing, and cable management specifications all need to be spelled out in the CD set rather than left for the installer to improvise around. And a structured asset data framework, covering rack elevations, power chain documentation, and circuit-level naming conventions, needs to appear either as a CD appendix or as a contractually defined deliverable with its own due date after commissioning, because without that commitment on paper, nobody owns producing it.

That last gap connects to a standard the AIA framework doesn't touch. BS EN 50600-3-1 sets out a handover data requirement for data centers, covering resilience, availability, risk management and mitigation, capacity planning, security, and energy efficiency, along with the specific information that has to transfer when a facility is accepted into service. The AIA CD phase has nothing to say about this requirement. If nobody adds it to the CD scope explicitly, that structured asset data becomes a cleanup job assigned to whoever is still around after commissioning wraps, if anyone takes it on.

Commissioning itself is the clearest example of what happens when a CD gap turns into a contract gap. AIA contract guidance identifies commissioning as one of the features that sets data center projects apart from conventional ones, and it says agreements need to address it directly. The CD phase is where commissioning scope, integrated systems testing requirements, and verification documentation standards have to get written down. If that work is left for the commissioning agent to define on their own later, the project has handed over a decision that belongs to the design team at exactly the point where changing course gets expensive.

RFI and submittal management during Construction Administration

Every gap left open in SD, DD, or CD eventually turns into an RFI during the construction phase, and on a data center, that RFI carries more weight than it would on a conventional building. A missing point list, an EPMS integration interface nobody resolved, a sequence of operation that was never pinned down, each of these can stall procurement, installation, or commissioning across several interdependent systems at once.

RFI classification on a data center project needs to cover medium-voltage service, low-voltage distribution, generator plant, UPS, cooling, fire protection, controls, security, and commissioning as distinct categories. Any one of them can stop commissioning cold, regardless of how small the dollar amount attached to it looks.

Every RFI deserves evaluation on four fronts: schedule impact, procurement impact, commissioning impact, and downstream coordination risk, not cost alone. A clarification that costs almost nothing to answer can still be a high-risk RFI if it's standing between the project and electrical energization or integrated systems testing.

Submittal rejections carry their own compounding cost. A high rejection rate, usually traced back to CD deliverables that were incomplete or didn't line up with each other, adds weeks to the procurement timeline with every rejection cycle. On a project where generator, switchgear, and UPS lead times already run many months, a few rejection cycles stacked on top of that timeline can move a go-live date by quarters, not weeks.

AIA contract guidance points out that data center projects need extensive testing of mechanical, electrical, and operational systems before the facility goes fully operational, and that agreements should spell out who leads commissioning, when it happens, and how the testing gets documented. RFI and submittal review during CA have to feed directly into that commissioning record rather than run alongside it as a separate paper trail. A standard form of consultant's services for commissioning, attached to an owner-consultant agreement, is the instrument built for formalizing the commissioning agent's role and tying it to CA-phase RFI and submittal review. Leaving that relationship undefined is one of the most common ways coordination breaks down right before a facility is supposed to go live.