Single-Source-of-Truth Models in Multi-Discipline Data Center Projects

U.S. data center construction starts hit $81.5 billion through June 2026, already past all of 2025's $77.7 billion, according to ConstructConnect. Build costs per megawatt climbed from $7.7 million in 2020 to $11.3 million in 2026, with AI-ready facilities running $20 million a megawatt or more, per JLL. At that kind of spend, "single source of truth" has stopped being a nice-to-have. Most teams still get it wrong: they think they have one when what they actually have is several models stitched together and given one name. The gap between a project that ships on budget and one that bleeds money to rework nobody planned for comes down to whether that model actually holds.

What "single source of truth" actually means in a multi-discipline data center project

A single source of truth gets confused, constantly, with a master Revit file that gets emailed around every Friday, hoping everyone opens the latest version. That's a rumor with a file extension.

Real SSOT means one authoritative record. Every discipline reads from it, and every discipline writes back to it. A federated model works differently: teams combine their separate files just long enough to run clash detection, then go back to working alone. Federation is a meeting. SSOT is a live, shared data layer where a change in one place shows up everywhere else it matters, without anyone having to carry it there by hand.

On a data center project, that spans architectural and structural, electrical and power, mechanical and cooling, cable and fiber routing, and increasingly the operational layer: DCIM, BMS, EPMS, the systems that run the building after handoff. Modular prefabrication workflows show what this looks like when it works. Sales and tendering, design engineers, and factory assembly teams all pull from the same model, with bills of materials, revisions, and assembly instructions derived from one source instead of rebuilt five times over.

SSOT exists to kill the manual rebuild, where equipment specs, rack layouts, and load schedules get typed in fresh by each discipline's own tool and diverge the second anyone changes something nobody else hears about. The goal is propagation. Tool consolidation is just what falls out of getting propagation right.

How discipline-specific authoring creates parallel versions of the same model

Most teams run Revit for design authoring and Navisworks for aggregating everything and checking for clashes. Tools like Archil Labs, a data center delivery automation platform, take a different approach by treating the connected data layer as the primary artifact rather than the federated model. Sounds unified, but the picture changes once you look at how the files actually move day to day: each discipline's Revit file is its own document, its own data schema, updated on its own clock.

Power teams keep load schedules, panel boards, and busway routing in their model, often duplicated again in a spreadsheet somewhere. Change a rack's power draw and that number does not walk itself over to the cooling model or the cable model. It sits there, wrong, until somebody notices, and somebody usually doesn't notice until a coordination meeting three weeks later.

Cooling runs its own separate universe: CFD tools, psychrometric software, none of it sharing parameters with electrical or structural. Cable and fiber routing usually gets modeled last, if it gets modeled with any real detail at all. Raised floor routing gets shortchanged worst of all, and poor coordination there has a direct physical consequence: it throws off airflow and messes with installation sequencing.

Structural often doesn't see updated equipment weights until procurement is nearly locked in. This is a genuine problem now, because AI rack density is changing floor loading assumptions late in the process, sometimes after structural design was supposed to be settled.

Then there's the vendor files. Manufacturer geometry tends to be bloated, metadata is often wrong, and level of detail varies wildly from one submittal to the next. Each discipline ends up cleaning or interpreting those files their own way, so two teams looking at "the same" piece of equipment can end up working from two different versions of it. By the time anyone assembles a federated model, the disciplines have been drifting apart long enough that calling it one model is generous.

Where the divergence becomes visible (and where it stays hidden until construction)

Clash detection catches one thing well: hard geometry collisions, a cooling pipe punching straight through a cable tray. Yet it only runs when someone builds the federated model, on a schedule, not continuously. Between reviews, conflicts pile up unseen, and nobody's watching the pile grow.

Data conflicts sit entirely outside what clash detection can catch. A rack scheduled at one power density in the electrical model and a different density in the cooling calculations. A cable path that looks perfectly clear in 3D but violates bend radius or conduit fill rules on paper. Nine out of ten large infrastructure projects run into schedule overruns, and more than 60% of data center outages trace back to power, cooling, or cabling failures, exactly the kind of issue pure geometry checking was never built to flag.

The raised floor deserves its own callout. It holds cabling, cooling, and grounding systems all stacked together, and it's routinely modeled at low detail, sometimes not modeled at all. It's a coordination blind spot hiding in plain sight, underneath everyone's feet.

Certain events set off a chain reaction: a rack move, a load revision, a late equipment swap. Each one touches power, cooling, cable, and structural at the same time, and a manual update cycle cannot keep up with that. Over half of data center projects in 2025 saw delays of three months or more. Delay makes the underlying problem worse too, since teams keep working off their own baselines while waiting for coordination meetings to catch up, and the gap between versions just keeps widening in the meantime.

Why the federated model workflow doesn't close the gap

Federation combines models for a review session but stops short of creating a shared data layer. Once the clash meeting ends, everyone goes back to their own file, and the federated version starts going stale immediately, sometimes within hours.

BIM and a digital twin get treated as synonyms, and the difference matters more than teams admit. BIM, as most teams run it, is a snapshot: true the moment it's exported, decaying after that. A digital twin is supposed to be a living system. Most project teams are operating a snapshot and calling it a source of truth, which is a bit like calling a photograph a security camera.

Decisions made during clash resolution, in Navisworks or a BIM 360 session, tend to live in meeting notes and RFI logs. They don't automatically flow back into the model everyone's still building from. Rule-based model checking, triggered the moment any element changes, is where the industry knows it should be headed; most teams still only run that validation at scheduled milestones instead.

Then there are the authorities having jurisdiction. Data centers draw from local power grids and municipal water supply, which pulls AHJs deep into the process. A model revision required for permitting, if it isn't handled as a structured, tracked change, forks the project record right there: permitting version on one branch, working version on another. Dodge Construction Network found that 66% of owners report better decisions from digital workflows, but that number reflects integration discipline more than it reflects the software. The tool matters less than what teams actually do with it.

What the procurement timeline does to design-data integrity

Transformer lead times used to run six to eight months. Now it's three to four years, and switchgear, chillers, and backup generators carry procurement windows of twelve to twenty-four months. That single shift rearranges the entire design process: major equipment has to get ordered before design is finished, which means the model has to represent committed equipment while engineering decisions are still being finalized around it.

Substitutions happen constantly in that window. Every substitution is a data event, one that should update power schedules, cooling loads, cable sizing, structural loads, and operational asset records all at once. In practice, it usually updates none of them automatically.

A lot of that equipment data lives trapped inside a manufacturer's PDF submittal. A PDF is not a structured parameter. It cannot flow into a model, a schedule, or a validation rule on its own, so someone on each discipline that needs the data has to retype it by hand. Typos happen when four different people are retyping the same spec sheet, and they don't cancel each other out, they compound.

At this scale, the handoff from design to procurement has to be immediate and close to error-free, full stop. That's the strongest case for treating workflow unification as an engineering requirement, not a project management nicety. Turner & Townsend's 2026 data shows 48% of respondents naming power availability as the top obstacle to on-time delivery. Every hour lost internally to rework or version reconciliation eats into a schedule buffer that was already razor thin to begin with.

The operational handoff as the final SSOT test

A model that reaches turnover with gaps or disconnected data leaves BIM's job unfinished. Operators need structured asset data flowing into DCIM, EPMS, and BMS, not someone manually retyping it into a new system. The problem is well documented: when that data sits stuck in disconnected systems at handoff, owners can't monitor, manage, or get full value out of the facility they just paid for.

This is where SSOT falls apart most often, right at the seam between design and operations. The as-built model drifts from the as-designed model during construction. Then neither one gets reconciled with the operational system at turnover, and the facility opens running on three different versions of the truth simultaneously.

DCIM integration needs structured, parameter-level data: rack locations, power connections, cooling assignments, equipment IDs. Geometry alone doesn't cut it, and a BIM model exported as-is, heavy on shapes and light on parameters, doesn't meet that bar. BMS and EPMS integration make the same demand of electrical and mechanical data. It has to be structured and traceable back to the design record, so operators can confirm what's actually running matches what was designed and permitted.

A digital twin, a model that keeps living past construction and into operations, is the answer here. That only happens if the handoff strategy gets built into the workflow from day one. Bolting it on at closeout is too late; by then, the structured data that should have existed was never created in the first place.

What a connected workflow actually requires to hold discipline models together

A single Revit file everyone edits together sounds like the fix, but in practice it's a recipe for corrupted files and blown deadlines. What keeps disciplines in sync is a central data layer, built from shared parameters and logic that propagates a change the moment it happens, rather than a shared document everyone's fighting over.

Automation belongs wherever precision is non-negotiable. Clearance checks, capacity checks, redundancy checks, NEC compliance: these should run the instant an element changes, not wait for a milestone review. That's deterministic work, and deterministic work should never depend on a person remembering to check it.

AI has a different job entirely: layout generation, pulling specs out of PDFs, drafting RFI language, the tasks where input varies and a bit of contextual judgment actually helps. Rules handle the fixed stuff. AI handles the flexible stuff. Mixing up which is which is where most of these systems go wrong.

Cascade logic ties it together. A rack move should push updates to power schedules, cooling loads, cable routing, and documentation on its own, without a coordinator manually pinging four discipline leads and hoping someone answers before lunch. Manufacturer specs should enter the system once, at submittal, and populate every model, schedule, and validation rule that needs them, instead of getting retyped from a PDF five separate times.

Every RFI and design decision needs to trace back to the model element it touched and the information that justified it. That's what makes the as-built record and the operational handoff defensible later, when someone's asking why a wall moved eighteen inches or a panel got resized. ArchiLabs Studio is built around exactly this model for data center work: layout, critical-systems engineering, cable routing, documentation, RFIs, and operations-ready handoff, tied into one connected workflow, the kind of architecture that makes cascade logic real instead of aspirational. The broader push toward requiring structured, connected workflows in institutional and government BIM standards is a signal worth taking seriously. This is becoming the baseline expectation across the industry.

The real test is simple to state and hard to pass. A rack-level change gets made at 4pm, and by the next morning's coordination call, every affected schedule, sheet, and system has already updated, with nobody chasing four discipline leads to make it happen. That's the bar. Most workflows running today still don't clear it.