Federated Model
Separate discipline models (architecture, structure, MEP) linked in one coordinate space for coordination and review, without merging source files.
What is a federated model, and how does it differ from a merged model?
A federated model is an assembly of separate discipline models (architecture, structural, MEP) positioned in a shared coordinate space for viewing and checking. Each discipline maintains its own authoring file and keeps design authority over its own elements. Models are linked through IFC exports or a common viewing platform, but never merged into a single editable file.
A merged model brings all geometry into one file under one authorship. This breaks the direct link between each discipline's model and the professional responsible for it. When an element changes, it is unclear which discipline made the change. Federated models preserve professional responsibility where it belongs: with the discipline that designed it.
Why does a shared coordinate system matter so much?
Every point in a BIM model is defined by X, Y, Z coordinates. A shared origin, a single reference point agreed before modeling starts, ensures that when the architect places a wall at (100, 50, 0) and the structural engineer places a column at (100, 50, 0), they are the same point in space. Without a common origin, models that appear to line up on screen may actually be displaced by metres or tens of metres.
The classic failure: a structural model originating 50 metres from the architectural one. Both are modeled correctly to their own reference, but when assembled, the structure and envelope do not occupy the same space. Site surveys that tie to a real-world reference point (a survey nail or GPS coordinate) are the standard way to anchor a common origin.
Related conventions also matter: agreed site axes, a shared ground level, and naming rules for levels so "Level 1" means the same thing everywhere. These seem minor until a model uses "Level 1" and another uses "L1".
Which exchange format is normally used to assemble a federated model?
Industry Foundation Classes (IFC) is the standard format for federated coordination. Each discipline exports its model to IFC from its native authoring tool (Revit, ArchiCAD, Tekla, etc.), then these IFC files are imported into a coordination viewer where they sit in the same coordinate space. IFC is an open, non-proprietary schema maintained by buildingSMART, so no license is required to read or write it.
The advantage is vendor neutrality. A project with ArchiCAD for architecture, Revit for structural, and Tekla for MEP can coordinate seamlessly if all three tools export to IFC.
OpenBIM workflows formalize this: they define which IFC version is used, which data must be included, and who validates the exports. This approach explicitly commits to non-proprietary coordination.
What is a federated model actually used for?
A federated model serves four primary purposes:
- Clash detection: Automated checking to identify overlaps (a duct through a beam) or clearance violations. Clash detection tools flag conflicts before construction starts; findings are often recorded in a BIM Collaboration Format report.
- Spatial coordination: Checking that building services fit, structural grids align with architecture, and MEP has adequate headroom.
- Design review: Clients and contractors can walk through the 3D model without needing authoring software licenses.
- Quantity extraction: Take-offs and cost estimates can be derived from the model, reducing manual measurement.
A federated model is not used for authoring. Designers work in native tools; IFC exports are read-only snapshots for coordination.
How do the structures of federated and single-model workflows compare?
| Aspect | Federated Model | Single Merged Model |
|---|---|---|
| File ownership | Each discipline owns its own model | Coordinator owns the single file |
| Authorship responsibility | Discipline that designed the element | Whoever edited the merged file |
| Update cycle | Each discipline publishes on its own schedule; coordinator assembles snapshots | All changes feed into one file; coordination overhead if multiple editors |
| File size | Smaller individual files; easier to send and backup | Single large file; heavier to manage |
| Conflict resolution | Clear: whoever designed the element decides if it moves | Ambiguous: the person who last edited has version control |
| Typical use case | Multi-discipline projects, external consultants, large or complex buildings | Small projects, single firm doing all design, or in-house teams with one authoring platform |
What makes a federated model work in practice?
A federated model only delivers value if it stays current. It is a snapshot at a point in time. If the architect updates the envelope Monday but the engineer does not export until Friday, the model Wednesday is already out of sync. The closer models drift, the less useful coordination becomes.
This is why the BIM execution plan exists: it defines when each discipline publishes, how often the model is reassembled, and when coordination meetings occur. Without this discipline, federated models become stale.
Common practice: the architect requests IFC exports weekly or bi-weekly during active design, reassembles the model, runs clash detection, and schedules a coordination meeting. As design hardens, the cycle stretches to monthly. The team agrees on this rhythm before work starts.
When does a solo practice need a federated model?
A single-storey Slovak family house often has no federated model. The architect creates one building model; if building services are minimal and no structural engineer or MEP consultant is involved, there is nothing to federate.
The term becomes relevant when the architect brings collaborators: a structural engineer modeling the frame, an MEP consultant modeling heating and ventilation. That constellation of models, assembled for coordination, is a federated model.
Most Slovak residential projects, especially passive houses with complex ventilation and underfloor heating, benefit from multi-discipline coordination. A simple one-storey house does not. The architect's model usually suffices.
How are discipline models coordinated before they are federated?
| Stage | Workflow | Discipline Model Status |
|---|---|---|
| Concept / Schematic | Architect shares rough massing model; structural engineer confirms structural grid is feasible; MEP notes building service zones | All models are preliminary; frequent exports and meetings |
| Design development | Architect refines spatial layout and facade; structural engineer designs structural system; MEP routes and sizes major systems | Models grow in detail; exported weekly or bi-weekly; clash detection finds and resolves conflicts |
| Construction documentation | All disciplines finalize detail and specification; federated model frozen as coordination reference | Models are complete; less frequent updates; final clash report issued |
| On site / As-built | Federated model updated with actual site changes and records; used for facility handover | Federated model becomes the as-built and operational record |
The real work is not the assembly itself; any viewer can overlay IFC files. The real work is the cycle: export, assemble, review, resolve, and repeat. That discipline is what the BIM execution plan enforces, and it is what separates a successful project from one where models exist but no one uses them for coordination.
Frequently asked questions
- Why not just merge all discipline models into one file?
- Merging hands all design authority to the coordinator and breaks the link between each discipline's model and its author's design intent. A federated approach keeps the architect's responsibility with the architecture, the structural engineer's with the structure, and the MEP engineer's with their systems. If something needs to change, it changes in the source model, not in a copy, so revisions propagate correctly.
- What happens if the shared origin is set wrong?
- Everything else on the project is built on that one reference point. A structural origin 50 metres away from the architectural one is the classic failure: the structural engineer builds to their coordinate system, the architect places elements on theirs, and when the models are overlaid they do not sit in the same space. Establishing a common origin before modeling starts, ideally using a survey point tied to the site, is fundamental.
- Does federated modeling mean every small project needs multiple discipline models?
- No. A single-storey Slovak family house with no building services usually has one model authored by the architect. The term 'federated model' only matters once the project involves a structural engineer, MEP consultant, or other external collaborators with their own models. For most residential design, especially small passive houses, the architect's model is the entire coordinate set.
- What format do discipline models use when they are assembled into a federated model?
- The most common exchange format is IFC (Industry Foundation Classes), an open standard that lets ArchiCAD, Revit, Tekla, and other platforms export their models to a common language. Each discipline keeps and updates its native authoring file; the IFC export is the view shared for coordination.
- Is the federated model a permanent deliverable or just a coordination tool?
- It serves both purposes. During design, it is the central coordination tool for checking conflicts and geometry. At project end, the federated model (as an IFC assembly) becomes the as-built record and reference layer for facility management, energy audits, and future renovations. Many clients now require it as part of handover.
- Who updates the federated model when a discipline makes changes?
- The architect, as the coordinator, usually manages the schedule and requests fresh IFC exports from each discipline on a set cycle (weekly, bi-weekly, monthly depending on design pace). The BIM execution plan defines who publishes when, so everyone knows if they are working from an outdated assembly.