If a client has ever asked your team to work from "a single BIM model" and you've quietly wondered whether they mean that literally or are just using loose language for what's actually a federated coordination workflow, you're not alone - and getting this distinction right at the start of a project avoids a genuine mismatch in expectations later.
"Single source of truth" is a phrase used constantly in BIM marketing to describe what is, in practice, almost always a federated model - separate discipline models combined for coordination, not one model that every discipline edits directly and simultaneously. Understanding this distinction properly shapes how a project's CDE, federation cadence and model ownership rules should actually be set up, and conflating the two is a common source of unrealistic expectations about how quickly a design change made by one discipline becomes visible to everyone else.
How Federation Actually Works, and Why It's the Default
In a federated workflow, each discipline - architecture, structure, MEP, and often further sub-disciplines within MEP - models independently in their own file, using their own preferred authoring tool where that varies. At agreed intervals, those individual models are combined into a single coordination view, typically in Navisworks or a similar federation viewer, where clash detection and visual review happen against the combined picture. Critically, nobody is editing a shared file directly - each discipline retains full ownership and control of their own model, and the federation process is essentially a structured, repeated act of bringing everyone's separate work together to check it against everyone else's.
This remains the practical default for a genuinely important reason that goes beyond simple software limitation: current major BIM authoring tools - Revit, ArchiCAD, Tekla - are built around the assumption of discipline-owned models exchanged via IFC or native federation, not true simultaneous multi-party editing of one shared file. Even cloud-based versions of these tools that support real-time collaboration generally do so within a single discipline's model, not across disciplines editing the same file concurrently. Building a genuinely single shared model that architecture, structure and MEP all edit directly and simultaneously isn't something the mainstream software ecosystem is actually built to support reliably yet.
What This Means for Coordination Time and Risk in Practice
The federation cadence is where coordination time actually gets spent
Because models are only as current as the last federation cycle, the time cost of this approach shows up in how often re-federation happens and how disciplined the team is about keeping to that schedule. During an intensive coordination phase - say, the period where structure and MEP are actively resolving ceiling void conflicts on a dense hospital floor - weekly re-federation is standard practice. Less active design phases can stretch that to biweekly without much practical loss. Where teams get into trouble is when federation happens irregularly, driven by whoever remembers to trigger it rather than a defined schedule, which leads to disciplines coordinating against versions of each other's models that are already several weeks out of date without anyone quite realising it.
Model ownership clarity is the other half of what federation provides
Beyond the practical coordination-time question, federation gives each discipline clear ownership and accountability for their own model in a way that a genuinely single shared model would blur considerably. If a clash is discovered between a beam and a duct, it's immediately clear which discipline's model contains which element, and therefore whose responsibility it is to resolve the conflict. In a single-source model where multiple disciplines are editing directly into the same file, that clarity of ownership becomes murkier - which matters not just for workflow efficiency but for professional liability and insurance purposes, where being able to attribute an error to a specific discipline's model has real contractual weight.
A Scenario Worth Considering
Picture a large mixed-use development where the client's PMC insists in the tender documentation that the project will run on "one integrated BIM model," and the winning consultancy team interprets this literally at kickoff, attempting to have architecture, structure and MEP all model directly into a single shared Revit file using worksharing. Within a few weeks, this typically starts breaking down - worksharing conflicts increase as more disciplines contend for the same central file, element ownership becomes genuinely ambiguous when, say, an MEP engineer needs to model a sleeve through a structural wall that the structural team also has views open on, and the promised efficiency gain from avoiding federation lag gets eaten by an entirely new category of file-locking and version-conflict friction that a properly federated workflow simply wouldn't have created in the first place. The practical fix in almost every case like this is to revert to a properly federated workflow with a disciplined weekly cadence - which is, in the end, what the client's PMC actually needed, even though "one integrated model" was the language used in the tender document.
Where the Genuine Trade-off Lies
None of this means federation is without cost. There is a real, if manageable, time lag between a design decision made in one discipline's model and that decision becoming visible to the rest of the team, and on a fast-moving, rapidly evolving design phase, that lag can occasionally mean a downstream discipline is coordinating against slightly stale information. The mitigation isn't chasing single-source modelling as a solution - it's tightening the federation cadence during the phases where design is changing fastest, and being disciplined about flagging significant changes to other disciplines directly rather than relying purely on the next scheduled federation cycle to surface them.