Why keeping discipline models separate is what makes coordination actually work.
Open a coordination session in Navisworks or a linked Revit view and everything on screen looks like one seamless model — architecture, structure, mechanical, electrical and plumbing all sitting together in the same 3D space. That combined view is a federated model, and it's easy to assume that behind the scenes it must also be one combined file. It isn't, and that distinction is not a technicality — it's the entire reason multi-discipline coordination is workable at all. A merged model, where the geometry really is combined into a single file, is a different thing with a different, much narrower use case.
A federated model is a live, linked aggregation of separate discipline models, viewed together in one coordination session for visualization, coordination and clash detection — but the underlying files never stop being separate. Each discipline team authors and owns its own model, keeps full independent control over it, and continues working in it on its own schedule. The federated view simply re-links the latest published version of each file the next time it's opened or refreshed. A merged modelis a genuinely different artifact: every discipline's geometry is combined into one single unified file. That eliminates the ability for any discipline to independently author, version and control their own portion — everything now lives inside one shared file that every discipline has to take turns editing.
Running clash detection against a federated aggregation catches exactly the same geometric conflicts a fully merged model would show — a duct is either intersecting a beam or it isn't, regardless of whether the checking software is reading five linked files or one combined one. Federation gets that same visibility while every discipline keeps its own file, its own version history, and its own authoring schedule intact. Merging models during active design or construction — rather than federating them — is a common mistake precisely because it trades away independent ownership and workflow flexibility without buying any coordination capability federation didn't already provide. There's no clash a merged model catches that a properly federated one misses.
False, and it gets the trade-off backwards. Merging into one file during active design or construction sacrifices each discipline's independent ownership, version control and ability to keep working on its own schedule — and in exchange it creates real file-size, performance and multi-team-editing problems, without providing any coordination benefit a federated view doesn't already give you. Federating — linking separate, independently-owned models together for coordination and clash-detection viewing, without merging the underlying files — achieves the same coordination visibility at none of that cost, which is exactly why federation, not merging, is the standard professional approach during active multi-discipline coordination. Merging is appropriate only for a final, frozen deliverable — an as-built record model, say — where independent editing by multiple teams is no longer needed.
Explains why a federated model — a live, linked aggregation of separate, independently-owned discipline models viewed together for coordination and clash detection — is not the same thing as a merged model, where all disciplines' geometry is combined into a single unified file, and why keeping models federated (not merged) is what makes ongoing multi-discipline coordination actually work.
A federated coordination view looks, on screen, like one seamless model — architecture, structure, mechanical, electrical and plumbing all rendered together in the same 3D space in Navisworks or a linked Revit session. It's a short step from there to assuming the underlying file must also be one combined thing. It isn't. Federation is purely a viewing and coordination layer: each discipline's model stays exactly where it was authored, in its own separate file, owned and controlled entirely by its own team. The federated view links those files together live, and simply re-links whatever is most recently published the next time it's opened or refreshed.
A federated model keeps every discipline's file entirely separate and independently owned — each team continues authoring, versioning and publishing its own model on its own schedule, and the federated coordination view is only ever a live, linked overlay of the current published versions, used for visualization, coordination meetings and clash detection. A merged model actually combines all disciplines' geometry into a single unified file, which eliminates independent authoring and version control for every team involved — everyone now has to share and take turns editing one file. Merging creates real, practical problems on an active project: the single file's size and performance degrade as more geometry piles in, multiple teams needing to edit simultaneously creates workflow conflicts, ownership of any given element becomes unclear, and each discipline's independent version history is lost. Merging is appropriate only for a final, frozen deliverable — such as an as-built record model — where ongoing independent editing by multiple teams is no longer needed, not for active coordination during design or construction.
Merging discipline models together during active design or construction — instead of federating them — is a common and costly mistake. Running clash detection against a federated aggregation of separate models catches exactly the same geometric conflicts a merged model would surface, since the underlying geometry being checked is identical either way. Federating gets a project team that same coordination visibility while every discipline keeps its own file, its own version history and its own independent authoring schedule intact. Merging trades all of that away — bigger files, blocked simultaneous editing, unclear element ownership — for no coordination benefit federation wasn't already providing. This is why federation, not merging, is the standard, correct workflow for active multi-discipline BIM coordination, and why merging is reserved for a project's final frozen record model.
No. Federation is purely a live, linked viewing and coordination layer — each discipline continues to fully own, author and version-control its own model file exactly as before. The federated view only ever displays whatever version each team has most recently published.
No — a clash-detection engine tests geometry against geometry either way. Running it against a federated aggregation of separate, linked files surfaces the same hard clashes a fully merged single file would show, because the underlying geometry being compared is identical. Federating doesn't cost you any clash-detection capability.
Only once ongoing independent editing by multiple disciplines is no longer needed — typically for a final, frozen deliverable such as an as-built record model, a fixed archival snapshot, or a one-off combined export for a client or authority review. Merging during active design or construction, when teams still need to keep editing their own portions, creates the file-size, ownership and workflow problems this page describes.
It updates on refresh, not instantly. Each discipline publishes updates to its own file on its own schedule, and the federated coordination view re-links to the latest published version the next time the aggregation is opened or manually refreshed — it isn't a continuous real-time sync.
Usually from the same misconception this page addresses: the assumption that combining everything into one file is inherently "more thorough" coordination, since everything is visibly in one place. In practice it sacrifices independent ownership and version control for no clash-detection benefit federation doesn't already provide, which is why professional BIM coordination standards treat federation, not merging, as the default for active multi-discipline work.
Try our BIM, CAD & Digital Design Studio
More calculators, simulators, and guides for this discipline.