Federated model governance: who owns what when something breaks

2. What "Federated Model" Actually Means

2.1 The Terminology Problem

The word "federated" is used inconsistently across the industry. Some practitioners use it to mean any aggregation of multiple discipline models. Others use it specifically to distinguish a non-merged, autonomy-preserving coordination environment from a fully integrated single-model workflow. Getting the terminology right matters because the governance rules that follow depend on the model architecture.

The definition that has the strongest institutional backing comes from the UK's National Building Specification (NBS): a federated model is "a combined Building Information Model that has been compiled by amalgamating several different models into one." The critical qualifier in the NBS definition is that the contributing models remain "completely distinct and separate entities" — they supply data to the combined view without losing their individual identity or ownership. This is the definition we will use throughout this article.

A useful contrast: in a linked model architecture (common in Revit-based workflows), one discipline's model file is referenced inside another's as a linked instance. The host model can see the linked model but cannot edit it. Changes to the linked model are propagated when the reference is refreshed. This is a point-to-point dependency, not a federation.

A federated model aggregates multiple discipline files — typically through a coordination platform such as Autodesk Navisworks, Solibri Model Checker, Trimble Connect, or BIMcollab Zoom — without any single discipline hosting another's data. Each consultant exports their model to a neutral or platform-native format, and the coordination tool assembles the combination. The key properties of true federation are:

1. Ownership is unambiguous at the source. The structural model belongs to the structural engineer. The MEP model belongs to the MEP consultant. Nobody shares editing rights to another party's model.
2. Aggregation is non-destructive. The federated view is read-only. No party modifies the federated assembly directly; changes are made in the source model and re-exported.
3. Coordination happens in the overlay, not in the source. Clash detection, issue annotation, and coordination comments all happen in the platform layer. Resolved clashes are then implemented by each responsible party in their own model file.

2.2 Federated vs. Integrated: Where ISO 19650 Draws the Line

ISO 19650-1 (2018) establishes the conceptual framework for information management throughout the built asset lifecycle. It introduces the idea that information containers — individual model files, documents, and data sets — are produced by appointed parties and exchanged through a Common Data Environment (CDE). Part 2 (2018) specifies the delivery-phase requirements, introducing the BIM Execution Plan (BEP), the Master Information Delivery Plan (MIDP), and the Task Information Delivery Plans (TIDPs).

The roles defined in ISO 19650-2 are directly relevant to federation governance:

• Appointing party — the client or employer who commissions the work and defines what information is needed. They set the Employer's Information Requirements (EIR).
• Lead appointed party — the main contractor or lead consultant who accepts the information management obligation from the appointing party and coordinates the delivery team. They author and maintain the BEP.
• Appointed party — each individual consultant or subcontractor who produces information containers. They author Task Information Delivery Plans (TIDPs).
• Task team — the working group within an appointed party that actually produces the model content.

Under ISO 19650-2, clause 5.4.2, the lead appointed party is required to "establish the delivery team's detailed responsibility matrix." This matrix maps every information container to its producing party. What the standard does not do — and this is the governance gap that causes duct-vs-beam stand-offs — is specify who owns the interface between two information containers. That gap is the responsibility of the project's BIM governance framework, of which the RACI matrix in Section 4 of this article is a practical implementation.

2.3 The Common Data Environment and Its Workflow States

The CDE is not just a file server with a folder structure. ISO 19650-2 defines four CDE workflow states that govern how information containers move through the project lifecycle:

For federated model coordination, the critical transition is from WIP to Shared. A model should only be included in a coordination federation when it is in the Shared state — meaning the producing party has confirmed it is sufficiently complete and coordinated internally for cross-discipline review. Including WIP models in a federation is one of the most common sources of spurious clashes: you are running clash detection against work that the producing consultant has not yet reviewed themselves.

A working governance framework for federation should specify:

• The minimum Shared-state criteria before a model is eligible for federation (typically: internally clash-checked, georeferenced to the project survey control points, and conforming to the agreed Level of Detail / Level of Information Need)
• The model exchange schedule (covered in section 2.5)
• The naming convention for federated model sets

2.4 Per-Consultant Model Ownership and Exchange Formats

In a properly governed federation, each consultant owns exactly one model (or one model per building/zone, depending on project scale). Ownership means:

• The right and responsibility to update the model
• The obligation to resolve internal clashes before sharing
• Accountability for model accuracy relative to the TIDP deliverable list
• Version control — each published version is tagged and archived

Exchange formats determine how models enter the federation. The three most common formats in current practice are:

IFC (Industry Foundation Classes) — the buildingSMART open standard for BIM interoperability. IFC files are schema-defined, software-agnostic, and the preferred format for open-BIM workflows. IFC 4 (and the emerging IFC 4.3 for infrastructure) supports full geometry, property sets, spatial structure, and relationship data. For federated coordination, IFC is the gold standard because it is vendor-neutral and every major authoring tool can export it. However, IFC exports from Revit are notoriously sensitive to export settings; a poorly configured IFC export can strip geometry, lose relationships, or misplace elements relative to project origin.

NWC / NWD (Navisworks Cache / Document) — proprietary Autodesk formats optimised for Navisworks coordination workflows. NWC files are appended caches exported directly from authoring tools (Revit, AutoCAD, Civil 3D) and are faster to work with in large projects. NWD is the compiled federated package. The limitation is vendor lock-in: NWD workflows privilege Autodesk-tool users.

RVT (Revit) — on all-Autodesk projects, some teams use linked Revit models rather than a neutral format federation. This has coordination advantages (better parametric fidelity) but governance disadvantages: it creates dependencies between authoring environments and can lead to the linked-model-as-federated confusion described in section 2.1.

Trimble Connect's TrimBIM — Trimble Convert automatically converts uploaded models (IFC, RVT, SketchUp) to its native TrimBIM format for processing and clash detection within the Trimble ecosystem. This works well for fabrication-heavy workflows where Tekla models are part of the federation.

The governance rule is: choose one primary exchange format per project and enforce it in the BEP. Mixed-format federations (some consultants sending IFC, others NWC) create version traceability problems.

2.5 Coordination Sync Cadences

The exchange schedule is the heartbeat of federation governance. A model that is not exchanged at a known, predictable cadence cannot be coordinated against reliably.

Industry practice, supported by the BIM Execution Plan guidance from the National Institute of Building Sciences (NIBS v4) and by common practice frameworks, converges on the following cadences:

• Design development phase: Biweekly exchange minimum. Coordination meetings biweekly or monthly.
• Construction documentation phase: Weekly exchange. Weekly coordination meetings.
• Pre-construction / shop drawing coordination: Up to twice weekly for high-density MEP zones. Clash reports generated within 24 hours of each exchange.
• Construction phase: Exchange on request for RFI resolution; major revision exchanges as agreed per package.

The freeze schedule — the point at which a model is locked for a given coordination cycle — should be 48 hours before the coordination meeting. This gives the BIM Coordinator time to aggregate the federated set, run the clash matrix, and distribute the report before the meeting. Models submitted after the freeze are held for the next cycle.

2.6 Why Federation Creates Governance Obligations That Integration Does Not

In a fully integrated single-model environment (the theoretical BIM Level 3 future), ownership of a model element is granular and tracked by the authoring platform. Who created a wall, who last modified a duct run, who approved a structural connection — all of this is in the model's change history.

In a federated environment, that granularity disappears at the interface between models. The structural engineer's model ends at the face of the steel section. The MEP consultant's model begins at the face of the duct flange. The space between them — the penetration detail, the sleeve, the fire-stopping assembly — belongs to neither model, or potentially to both. This is the interface zone, and it is where the governance obligation is highest and the documentation is typically weakest.

The remainder of this article is an attempt to close that gap.

3. Ownership Ambiguity Patterns

If you have coordinated enough multi-discipline projects, you have encountered all of these patterns. Naming them is the first step toward preventing them.

3.1 The Cross-Trade Geometry Clash: Neither Owner Wants to Move

The duct-vs-beam scenario from the lede is the archetype. Two consultants, both modelling correctly to their respective briefs, produce geometry that occupies the same space. Neither party has a contractual obligation to move — both are complying with their scope. The stand-off occurs because the BEP did not specify a hierarchy for this clash type.

The fix is a system-hierarchy rule, codified before coordination starts. The principle, widely used in practice and described in the coordination literature, is that the most moveable element is responsible for the resolution. Structural and architectural elements, once designed, have very limited flexibility — notching a primary beam requires a structural assessment and a change to the fabrication package. HVAC ductwork, while constrained by flow, pressure drop, and spatial routing, has far more flexibility than steel. Plumbing has more flexibility than HVAC. Electrical conduit and cable tray have the most flexibility of all.

The standard system hierarchy, from least to most moveable:

1. Structural (concrete, steel — primary frame)
2. Architectural (walls, floors, cores — primary envelope)
3. HVAC primary (main supply/return trunk ducts)
4. Plumbing primary (soil and waste stacks, primary mains)
5. HVAC secondary (branch ducts, fan coil units)
6. Plumbing secondary (branch lines, fixtures)
7. Fire protection (sprinkler mains, then branches)
8. Electrical (cable trays, then conduit runs)
9. Low-voltage / data (the most flexible)

When two systems clash, the lower in the hierarchy (more moveable) is responsible for the resolution. This does not mean the lower-ranked consultant is always wrong — it means they have the obligation to propose the first resolution option.

3.2 Interface Drawings and the No-Man's-Land Problem

Interface drawings — sometimes called "interface management drawings" or "coordination interface drawings" — are meant to define exactly where one consultant's scope ends and another's begins. In theory, every interface between two disciplines should be described in an interface drawing that both parties sign. In practice, interface drawings are often:

• Created after clashes are discovered rather than before modelling begins
• Produced by one party without formal sign-off from the other
• Never updated when design changes alter the interface condition

The no-man's-land problem arises when both parties assume the other is responsible for a detail. The classic case is the MEP penetration through a structural wall or slab. The structural engineer models the wall. The MEP consultant models the duct or pipe. Neither models the sleeve, the liner, the fire collar, or the fire-stopping assembly. The void at the interface is the no-man's-land.

Standard practice, supported by the NIBS BEP Standard v4, is to assign explicit ownership of penetration modelling in the BEP. A commonly used assignment rule:

• The MEP consultant models the penetration opening (size, location, clearance to reinforcement)
• The structural engineer models the sleeve or box-out in the concrete
• The passive fire protection specialist models the collar and intumescent strip (or this is assigned to the MEP consultant if no separate passive fire specialist is appointed)
• The interface drawing is produced by the party requesting the penetration (typically MEP) and countersigned by the structural engineer

Without this explicit assignment, penetrations are the single most common source of site RFIs on federated-BIM projects.

3.3 Shaft Coordination: When Three Disciplines Own the Same Volume

Building service risers and plant room connections are the spatial zones with the highest clash density. A typical mechanical plant shaft on a high-rise commercial building contains: structural columns and shear walls (structural), fire-rated shaft walls (architectural), mechanical risers (HVAC), hydraulic risers (plumbing), electrical bus bars and trunking (electrical), fire protection mains (fire), and low-voltage cable management (data/comms).

Every one of these disciplines has legitimate claim to space in the shaft. The governance challenge is threefold:

Volume allocation. Who decides how the shaft cross-section is divided? In most projects this is done by the mechanical consultant (who typically has the largest volume requirements) in early schematic design, and other disciplines are fitted into the remaining space. This works if the allocation is explicitly documented and shared. It fails silently when the mechanical consultant allocates the shaft volume in their model, other disciplines assume different volume shares, and nobody cross-checks until construction documentation phase.

Access and maintenance corridors. Building regulations and engineering standards require minimum maintenance access clearances in plant shafts. These clearances are typically not modelled by any single consultant — they live in the gap between models. A governance framework should assign one party (usually the lead services consultant) to model access zones as void bodies in the federated model.

Revision sequencing. When the architectural team revises a shaft wall location by 300 mm — a common occurrence in design development — every service discipline in that shaft needs to re-coordinate. The governance question is who triggers the re-coordination cycle, who reviews the revised clash report, and what the escalation path is if the revision is rejected by one or more services consultants.

3.4 Foundation-vs-Civil: The Boundary Nobody Draws

On projects with complex site conditions — basement car parks, deep foundations, service tunnels, significant cut-and-fill earthworks — the boundary between the structural engineer's scope (building foundations) and the civil engineer's scope (earthworks, drainage, external services) is rarely drawn explicitly in the BEP.

The most common conflict types in this zone:

• Pad or strip foundations clashing with drainage runs that the civil engineer has routed through the same soil volume
• Retaining walls clashing with external service corridors
• Pile locations conflicting with incoming utility alignments
• Foundation tie-beams clashing with sub-slab drainage

These clashes are particularly difficult to resolve late in design because both foundations and external services often have very limited relocation flexibility once the design has reached construction documentation. A pile that needs to be moved by 400 mm may require a complete redesign of the pile cap and grade beams.

The governance rule: foundation-vs-civil coordination must be included in the BEP clash matrix, with an explicit interface boundary defined (typically the external face of the building's ground-floor slab edge or the property boundary, depending on project type). The lead appointed party is responsible for ensuring the structural and civil models are exchanged directly, not just into the federated set.

3.5 MEP Penetrations Through Fire-Rated Assemblies

Fire-stopping is one of the highest-risk interface zones in terms of both safety consequence and governance ambiguity. A MEP penetration through a fire-rated wall or floor assembly requires:

1. A penetration opening of the right size (MEP consultant)
2. A structural box-out or sleeve (structural or architectural consultant)
3. A fire-stopping system specified to the correct fire resistance level (typically the mechanical/electrical consultant, but sometimes a separate passive fire protection specialist)
4. A fire collar or intumescent wrap installed correctly (contractor, but specified in the design)

In federated BIM, it is common for the fire-stopping assembly to appear in nobody's model at construction documentation phase because each party assumes another party is responsible for it. The result is that fire-stopping is designed (poorly) on site, often as an afterthought when the services have already been installed. This is both a safety risk and a regulatory compliance risk.

The governance fix requires two things: (a) explicit ownership assignment in the BEP identifying who models fire-stopping assemblies; and (b) a dedicated clash set in the coordination matrix that checks all MEP elements that penetrate fire-rated assemblies against a fire rating zone model (which itself needs to be owned by someone — typically the architect or fire engineer).

3.6 The "Not My Model" Reflex

Beyond the technical patterns above, there is a behavioural anti-pattern that makes all of them worse: the reflexive "not my model" response when a clash is raised. This occurs when a consultant is shown a clash involving their geometry and immediately deflects to the other party rather than engaging with the resolution question.

The "not my model" reflex is rational from an individual consultant's perspective: accepting ownership of a clash resolution is accepting design risk, cost, and schedule responsibility. But it is catastrophic for project coordination because it converts technical problems into interpersonal conflicts.

The RACI framework in the next section is designed specifically to eliminate the conditions that produce the "not my model" reflex, by making ownership explicit, pre-agreed, and documented before any clash is discovered.

4. A Working RACI for Federation

4.1 RACI Fundamentals

RACI is a responsibility assignment matrix. The four roles:

• R — Responsible: The party who does the work. There should be exactly one Responsible party per decision or task. If two parties share an R, you have a governance gap.
• A — Accountable: The party who is ultimately answerable for the outcome. There should be exactly one Accountable party. On BIM projects, this is often the lead appointed party or BIM Coordinator for coordination decisions, and the individual design consultant for design decisions within their scope.
• C — Consulted: Parties whose input is required before a decision is made. Their sign-off is needed.
• I — Informed: Parties who need to know a decision has been made but do not contribute to it.

The key insight for BIM governance: RACI only works if it is defined before a problem occurs, not during a stand-off. A RACI matrix created in a live coordination meeting to resolve a specific clash is not a governance framework — it is a negotiation with extra steps.

4.2 Governance Scope: What the Federation RACI Covers

The federation RACI addresses three categories of decision:

1. Model exchange and CDE management — who publishes, who federates, who approves
2. Clash triage and assignment — who classifies a clash, who assigns it, who tracks it to closure
3. Conflict resolution and escalation — who resolves a clash that cannot be assigned unambiguously, who has authority to escalate, who documents the resolution

It does not replace individual discipline design responsibility or contract-level scope definitions. It operates at the coordination layer between discipline scopes.

4.3 Defined Roles for the Federation RACI

For a typical multi-discipline design project (architecture, structure, MEP, civil), the relevant parties are:

4.4 The RACI Matrix: Model Exchange and CDE Management

Notes:

• Each discipline lead is both R (does the work) and A (accountable) for their own model publication. No other party is accountable for a consultant's own model quality.
• The BIM Coordinator is R/A for federation and clash detection because these are coordination-layer functions, not design functions.
• The Information Manager (ISO 19650-2 role) is R for verifying procedural compliance with exchange requirements but is not a design authority.

4.5 The RACI Matrix: Clash Triage and Assignment

4.6 System Hierarchy Tie-Breaker Rules

The system hierarchy (section 3.1) resolves most clash assignments automatically. The lower-ranked (more moveable) system is assigned the resolution. But there are three situations where the hierarchy does not give a clean answer:

Tie-breaker Situation 1: Both systems are at the same hierarchy level. Example: Two HVAC ducts from different sub-consultants occupying the same space in a ceiling plenum. Resolution: the duct serving the larger area (higher supply/return volume) has priority. The smaller-area duct resolves.

Tie-breaker Situation 2: The lower-ranked system has no feasible routing alternative. Example: An electrical cable tray (low hierarchy) cannot be rerouted because the only viable path is already occupied. Resolution: escalate to the BIM Coordinator, who chairs a joint consultation session with both parties within 5 business days. If no consensus, escalate to Project Manager.

Tie-breaker Situation 3: The resolution of a lower-ranked clash creates a new clash with a higher-ranked system. Example: Rerouting a drain line (plumbing) to clear a structural beam creates a clash with the primary HVAC duct. Resolution: the clash resolution creates a new clash with a higher priority — the new clash is treated as a primary clash in the next coordination cycle. The party who rerouted is responsible for resolving both.

Geometric tolerance vs. system flexibility: The general principle is that geometric tolerance belongs to the system with less spatial flexibility. A 50 mm tolerance buffer around a primary structural element costs nothing (the structural engineer just specifies a 50 mm clear zone in the BEP). A 50 mm tolerance buffer around all HVAC ducts would consume unreasonable space in a congested ceiling plenum. Assign tighter tolerances to the elements that are hardest to move; accept larger manufacturing tolerances for flexible systems.

4.7 Escalation Logic

The escalation chain for unresolved coordination clashes should be defined in the BEP before any clash is discovered. A working three-level escalation:

Level 1: Discipline-to-Discipline (5 business days)

The two discipline leads meet directly (not in the full coordination meeting) to agree a resolution. The BIM Coordinator is informed. If resolved, the resolution is documented in the BCF issue and implemented in the next model exchange.

Level 2: BIM Coordinator-Chaired Consultation (10 business days from initial clash discovery)

The BIM Coordinator chairs a formal consultation session with all affected discipline leads. The BIM Coordinator proposes a resolution based on the system hierarchy rules. All parties must respond formally (accept or contest in writing) within 2 business days. If a majority accept, the resolution is implemented. If contested, proceed to Level 3.

Level 3: Project Manager Decision (15 business days from initial clash discovery)

The Project Manager receives a formal escalation package: the clash location, the BCF issue history, the competing proposals, and the BIM Coordinator's recommendation. The Project Manager makes a binding decision. Costs associated with the resolution are dealt with under the contract's change management provisions.

The time limits in the escalation chain are non-negotiable. An escalation that has no time limit is not an escalation — it is a permission to defer indefinitely.

4.8 The RACI Matrix: Cross-Consultant Clash Types

The following table covers the most common cross-consultant clash categories. For each, we specify the Responsible party (who proposes the resolution), the Accountable party (who is answerable for the outcome), Consulted parties, and the Informed parties.

RACI decision rules embedded in this table:

1. Whoever is more moveable is Responsible. The assignment follows the system hierarchy.
2. The discipline with the safety-critical constraint is Accountable. For fire-stopping, the passive fire specialist (or whoever holds that function) is Accountable even if the MEP lead does the modelling work. For structural integrity, the structural engineer is always Accountable.
3. When two parties share the outcome space (e.g., shaft volume), the BIM Coordinator is Accountable for the mediated resolution — not either discipline.

4.9 Tooling Support: BCF and Issue Trackers

The RACI matrix is only useful if it is implemented in a tool that both captures issues and enforces the workflow. The BIM Collaboration Format (BCF), maintained by buildingSMART International, is the open standard for this purpose.

BCF works by packaging XML-formatted issue data — including a 3D viewpoint (PNG with IFC coordinates), IFC GUID references to specific model elements, a description, comments, status, and assignee — into a .bcfzip file or, in BCF 3.0+, into a REST API-based cloud workflow. BCF 3.0 (the current version as of 2026) supports:

• Issue types: Design Issue, Clash, RFI, Change Request, Quality Assurance
• Statuses: Open, In Progress, Under Review, Resolved, Closed, Void
• Priority levels: Critical, Major, Minor, Trivial
• Assignment to specific project members
• Due dates and escalation flags
• Comment threading with timestamps and author attribution

For the federation RACI to be effective, every BCF issue must capture:

1. The discipline model(s) involved (by IFC GUID or model version reference)
2. The clash type (from the RACI table above)
3. The Responsible party (assigned in the tool)
4. The Accountable party (documented in the description)
5. The escalation level (if applicable)
6. The resolution description when closed

Trimble Connect provides a tightly integrated BCF-compatible issue workflow within its federated model environment. Issues can be created directly from the 3D view, assigned to team members, and tracked through the BCF lifecycle. The platform's clash detection automatically converts detected clashes into issue candidates, which the BIM Coordinator then triages and assigns — exactly the workflow described in section 4.5.

Autodesk Construction Cloud (ACC) / BIM 360 provides a similar workflow in the Autodesk ecosystem, with Issues integrated directly into the model viewer and connected to RFI management.

BIMcollab is a standalone BCF-native issue management platform that integrates with virtually all major authoring and coordination tools via BCF API, making it a good choice for open-BIM projects where teams use mixed software environments.

Solibri Model Checker combines rule-based model quality checking with BCF issue creation, making it particularly well-suited to the pre-federation quality gate (verifying that a model meets the Shared-state criteria before it enters the federation).

4.10 Meeting Governance

The weekly coordination meeting is where the RACI is tested in practice. A meeting without governance is a meeting that produces conversation rather than decisions. The following structure, when enforced consistently, converts coordination meetings from status updates into decision events:

Total: 60 minutes maximum. Anything requiring longer discussion goes to a dedicated technical meeting with the relevant parties only.

Decision log: Every decision made in a coordination meeting must be captured in writing — not in meeting minutes published three days later, but in the BCF issue comment trail, updated live during the meeting. If the BIM Coordinator cannot close the loop on a BCF issue in real time, it is not resolved.

5. Anti-Patterns

Governance frameworks fail not because the rules are wrong but because they are not followed. The following anti-patterns are the most common failure modes in federated BIM coordination.

5.1 "Fix It" Without an Owner

The project manager says "someone needs to fix this" and the meeting moves on. No BCF issue is created. No party is assigned. The clash appears in the next clash report. The project manager says "I thought we resolved this last week." Nobody remembers what was agreed.

This anti-pattern is endemic. It happens when the coordination meeting is run as a status update rather than a decision forum, and when there is no discipline (in both senses of the word) around BCF issue creation. The fix: every clash discussed in a coordination meeting must have a BCF issue created before the meeting ends. If there is no issue number, there is no resolution.

5.2 Infinite Escalation

A clash is escalated to Level 2. The BIM Coordinator-chaired consultation does not produce consensus. The clash is escalated to Level 3. The Project Manager does not make a decision because they are not sufficiently briefed on the technical details. The clash is referred back to the discipline leads "to work it out." The discipline leads refer it back to the BIM Coordinator. The clash is now in week 8 with no resolution.

Infinite escalation is caused by two failures: (a) the escalation chain lacks time limits, and (b) the Project Manager has not been given a clear decision brief. The time limits in section 4.7 address (a). For (b), the BIM Coordinator must produce a one-page decision brief for every Level 3 escalation — problem statement, competing options, recommendation, cost implication, schedule implication. The Project Manager decides on the brief, not on a verbal summary in a meeting.

5.3 Unwritten Rules

The most experienced BIM Coordinator on the project knows that on this particular building type, MEP always takes priority over civil drainage at the basement interface, because that is how it was done on the last three similar projects. The junior coordinator joining mid-project does not know this. The civil engineer, who has not worked with this team before, does not know this. The result: clashes that the experienced coordinator would have assigned in thirty seconds take three meetings to resolve.

Every unwritten rule is a governance liability. The BIM Execution Plan must be written with the assumption that no party has worked together before and no institutional knowledge can be assumed. If it is not in the BEP, it does not exist as a governance rule.

5.4 Ignoring Meeting Decisions

A resolution is agreed in a coordination meeting. It is recorded in the BCF issue. The discipline responsible for the resolution does not implement it in the next model exchange. When challenged, the consultant says they were not aware the decision was binding, or that the decision was "just a proposal" that needed further review by their senior engineer.

Meeting decisions are binding when they are made with the Accountable party present. The RACI makes clear who is Accountable for each clash category. If the Accountable party is not in the meeting, the meeting cannot make a binding decision on that item — it can only note the item for follow-up. This is why the RACI and the meeting attendance list must be aligned.

5.5 The Parallel Resolution Problem

Two parties independently resolve the same clash without coordinating with each other. The MEP consultant reroutes the duct. The structural engineer also redesigns the beam connection on the assumption the duct would remain in place. Both solutions are modelled in the next exchange. Neither solution works with the other. Now there are two new clashes where there was one.

Parallel resolution is prevented by the BCF issue assignment workflow: once a clash is assigned to a Responsible party, that party owns the resolution. No other party implements a resolution for that clash until the Responsible party proposes one and it is accepted.

5.6 The "Post-Coordination" Model That Was Never Coordinated

The project is moving into the tender phase. The client wants to issue the coordinated federated model to tenderers. The BIM Coordinator publishes a model set labelled "Coordinated — Tender Issue." In reality, 47 clashes are still open in the BCF register, three discipline models have not been updated since week 6 of coordination, and the fire-stopping zone model was never created. The label "coordinated" is aspirational, not factual.

Clash count at any given point is not the same as coordination status. A project can have zero hard clashes and still have unresolved interface ownership issues. The coordination status certificate issued with a model release should include: total BCF issues raised, total closed, total outstanding, oldest outstanding issue, and a statement from the BIM Coordinator on any known outstanding risks. Anything less is a misrepresentation of the model's coordination state.

6. Case Studies

6.1 Case Study: High-Rise Mixed-Use Tower — MEP Shaft Governance Failure (Then Recovery)

A 38-storey mixed-use tower in Southeast Asia. The project used a Navisworks-based federation with weekly model exchange and a well-resourced BIM coordination team. In the first eight weeks of construction documentation coordination, the clash count was declining as expected — from 1,200 hard clashes at the start of CD phase to around 400 by week 8.

Then it plateaued. For four weeks, the clash count stayed around 400, despite all parties claiming to be working on resolutions. The BIM Coordinator reviewed the BCF register and found that 180 of the remaining clashes were in three building service risers spanning floors 10 through 22. Nearly all of them were in the "contested assignment" status — the discipline leads could not agree on who was responsible for the resolution.

Investigation revealed the problem: the BEP contained a system hierarchy rule, but it had been written by the mechanical consultant and had not been reviewed or signed off by the electrical and plumbing sub-consultants. Both parties had been operating on different interpretations of the hierarchy for eight weeks.

Recovery: The lead appointed party convened a governance reset session — three hours, all discipline leads present, no coordination work. The output was a revised hierarchy table, co-signed by all parties, and a RACI table for the three contested shaft zones. The RACI was entered as a custom property in each BCF issue. Within three weeks, 160 of the 180 contested issues were resolved.

Lesson: System hierarchy rules must be co-developed and co-signed by all affected disciplines. A hierarchy written by one party and distributed to others is a negotiating position, not a governance rule.

6.2 Case Study: Hospital Redevelopment — Fire-Stopping Governance and Regulatory Risk

A district hospital redevelopment project involving significant mechanical, electrical, and hydraulic upgrades to an operating hospital building. The fire-stopping ownership question was left unaddressed in the initial BEP because the project team assumed it would be covered by the passive fire protection specialist appointed in the later detailed design phase.

The passive fire protection specialist was appointed, but their scope was limited to "specification advice" — they were not contracted to produce BIM model content. The MEP consultant assumed the architect was modelling fire-rated assemblies. The architect assumed the MEP consultant was modelling penetrations. Neither modelled fire-stopping assemblies.

During the regulatory authority's building consent review, the reviewing officer flagged the absence of penetration details through five fire-rated floor assemblies. The project team had to retrofit fire-stopping documentation eight months into construction documentation — at significant cost and schedule impact. More seriously, two as-built penetrations installed during early construction works were found to be non-compliant with the specified fire resistance period and had to be remediated.

Recovery: The project lead appointed party commissioned a full penetration register — a systematic audit of all MEP model elements crossing fire-rated assemblies. The register identified 312 penetrations requiring fire-stopping specification. Ownership was assigned: MEP consultant to specify and model fire collars, architect to model intumescent strips in wall assemblies, passive fire specialist to review and sign off the register. The remediation cost approximately 1.2% of the total MEP contract value.

Lesson: Fire-stopping is not a default responsibility of any single consultant. It must be explicitly assigned in the BEP. If no passive fire specialist is appointed to model BIM content, the responsibility must be assigned by name to the architect or MEP lead.

6.3 Case Study: Data Centre — Foundation-Civil Interface Resolution

A hyperscale data centre campus development across a 14-hectare brownfield site. The structural engineer was responsible for foundation design for the four building pods. The civil engineer was responsible for site infrastructure: roads, drainage, electrical intake corridor, and a telecommunications duct bank running around the perimeter of each pod.

In the third cycle of federated coordination (approximately week 12 of CD phase), the clash report revealed 22 hard clashes between the foundation pile layout for Pod B and the civil electrical intake trench. The civil engineer had routed the intake trench through a corridor that the structural engineer had reserved for a foundation tie-beam row.

Investigation revealed that the foundation-civil interface had not been included in the BEP clash matrix. Both parties were exchanging models to the BIM Coordinator, but the coordination platform had not been configured to run clash detection between the structural and civil models — only between the building models and the site model. The 22 clashes had existed for six weeks without being detected.

Recovery: The BEP was amended to include foundation-civil as an explicit coordination pair. The clash detection matrix was reconfigured. Of the 22 clashes, 18 were resolved by rerouting the trench (civil engineer, consistent with the foundation-has-priority rule for in-building interfaces), and 4 required foundation pile relocations that triggered minor reinforcement revisions.

Lesson: The clash matrix must be explicitly configured. Clash detection software will only find clashes between model pairs that are included in the test set. If a discipline pair is not in the matrix, their clashes will not be detected — regardless of how good the modelling is.

6.4 Case Study: Mixed-Use Development — BCF Governance Success

A 220-unit residential-over-retail development where the lead contractor had mandated BCF-based issue tracking from project initiation. The BEP contained a detailed RACI covering all major clash types, and all 12 consultants on the project had signed off the governance framework before any modelling began.

In 26 weeks of construction documentation coordination, the project raised 2,140 BCF issues. Of these:

• 1,847 (86%) were resolved within 5 business days of assignment (Level 1)
• 218 (10%) required Level 2 BIM Coordinator consultation
• 75 (4%) escalated to Level 3 (Project Manager decision)
• 0 went beyond Level 3

The project reached a state of zero hard clashes in week 22, four weeks ahead of the BEP target. The BCF register was submitted as part of the tender documentation, giving tenderers full visibility of the coordination history and all design decisions made during the coordination process.

Lesson: A pre-agreed, co-signed RACI dramatically compresses resolution time. The 86% Level 1 resolution rate means 86% of clashes were resolved without any escalation at all — because the system hierarchy and ownership rules gave both parties the information they needed to resolve without a meeting.

7. Limits and Caveats

7.1 The RACI Cannot Resolve Scope Gaps

The federation RACI covers coordination decisions. It does not cover scope gaps — situations where a required design element is not in any party's scope. The fire-stopping case study (6.2) is an example of a scope gap, not a coordination dispute. The RACI can identify a scope gap (nobody is assigned as Responsible for a clash category) but it cannot close one. Scope gaps require contract variation.

If you implement the RACI table in section 4.8 and find that no party can be assigned as Responsible for a particular clash category, you have found a scope gap. Flag it to the Project Manager and the client immediately — do not attempt to resolve it at the coordination layer.

7.2 System Hierarchy Is Context-Dependent

The standard system hierarchy (structural → architectural → HVAC primary → etc.) is a default, not an absolute rule. On a heritage refurbishment project, the existing building fabric may have higher priority than any new MEP installation. On a data centre, power distribution infrastructure may have higher priority than HVAC routing. On a hospital, medical gas and vacuum pipework has fire-rating and regulatory constraints that can override the standard MEP hierarchy.

The BEP should document any deviations from the standard hierarchy, with justification, before coordination begins.

7.3 The RACI Assumes Competent Modelling

The federation RACI is designed to resolve genuine interface conflicts between competent discipline models. It is not designed to handle the situation where a model is poorly constructed, incorrectly georeferenced, or missing significant elements. A structural model that is missing half the secondary beams will generate hundreds of spurious clashes and make the RACI useless.

The pre-federation quality gate — verifying that each model meets Shared-state criteria before it enters the coordination cycle — is a prerequisite for effective RACI-based governance. Without it, the BIM Coordinator is spending time triaging quality failures rather than coordination conflicts.

7.4 Software Does Not Enforce Governance

BCF issue trackers, clash detection platforms, and CDE systems are tools that support governance. They do not enforce it. A BCF issue can be closed without the resolution being implemented. A model can be published to the CDE without meeting the Shared-state criteria. A coordination meeting can proceed without the Accountable party present.

Governance requires human enforcement. The BIM Coordinator role, as defined in this framework, is an active management function — not a passive aggregation role. The BIM Coordinator must be empowered to reject non-compliant model submissions, to re-open spuriously closed BCF issues, and to escalate to the Project Manager when the escalation chain is not being respected.

7.5 This Framework Is for Design and Pre-Construction

The federation RACI described here is appropriate for the design and pre-construction coordination phase. During construction, the governance model shifts: the contractor takes primacy over coordination, shop drawings supersede design models, and the information flow is primarily from contractor to designer (RFIs) rather than designer-to-designer (coordination clashes). A construction-phase BIM governance framework is a different — though related — document.

8. Sources and Further Reading

The following primary sources were used in the research and fact-checking of this article. All URLs were verified as accessible in June 2026.

ISO 19650 Series The authoritative source for information management roles, CDE workflow states, responsibility matrix requirements, and the BIM Execution Plan framework. ISO 19650-2 clauses 5.3.2, 5.4.1, 5.4.2, 5.4.4, and 5.4.5 are directly relevant to federation governance. UK implementation guidance is available from the Centre for Digital Built Britain (CDBB) at Cambridge and the UK BIM Framework.

• ISO 19650-1:2018, Organization and digitization of information about buildings and civil engineering works, including building information modelling (BIM) — Information management using building information modelling — Part 1: Concepts and principles
• ISO 19650-2:2018, Part 2: Delivery phase of the assets
• UK BIM Framework Guidance, Part 2: Delivery Phase. Available at: ukbimframework.org

BCF — BIM Collaboration Format buildingSMART International maintains the BCF specification. BCF 3.0 is the current version, supporting REST API-based cloud workflows in addition to the original file-based BCF-XML format.

• buildingSMART International. BIM Collaboration Format (BCF). Available at: technical.buildingsmart.org/standards/bcf/
• buildingSMART International. BIM Collaboration Format — Wikipedia overview. Available at: en.wikipedia.org/wiki/BIM_Collaboration_Format

Clash Detection Matrix and System Hierarchy

• BIM Corner. System Hierarchy and Clash Matrix in BIM Coordination. Available at: bimcorner.com/system-hierarchy-and-clash-matrix-in-bim-coordination/
• Revizto. What is a Clash Detection Matrix? BIM Clash Matrix. Available at: revizto.com/en/what-is-clash-detection-matrix/

Federated Model Definition and Governance

• NBS. What is a Federated Building Information Model? Available at: thenbs.com/knowledge/what-is-a-federated-building-information-model
• BIM Info. The Complete Guide to Federated Models in BIM. Available at: biminfo.neocities.org/the-complete-guide-to-federated-models-in-bim

BIM Execution Plan and Responsibility Matrix

• National Institute of Building Sciences (NIBS). Project BIM Execution Planning (BEP) Standard, Version 4. Available at: nibs.org/nbims/v4/bep/

Trimble Connect

• BIMtrust. Trimble Connect by Trimble Inc.. Available at: bimtrust.com/software/trimble-connect

BIM and Dispute Management

• Mehrbod, S. et al. (2019). Beyond the Clash: Investigating BIM-Based Design Coordination Issue Severity and Lifecycle. ITcon, Vol. 24. Available at: itcon.org/papers/2019_03-ITcon-Mehrbod.pdf

Further reading not directly cited:

• Eastman, C., Teicholz, P., Sacks, R., & Liston, K. BIM Handbook: A Guide to Building Information Modeling for Owners, Managers, Designers, Engineers and Contractors, 3rd ed. Wiley, 2018.
• Autodesk University. Virtual BIM Coordination for Construction. Available at: autodesk.com/autodesk-university/article/virtual-bim-coordination-construction-2019

Appendix A: RACI Matrix Template (CSV)

clash_type,responsible,accountable,consulted,informed,escalation_level_default,notes
Duct vs primary beam (hard),ML,ML,SL,BC|AL|PM,L1,MEP reroutes first; structural notch requires formal assessment
Duct vs secondary beam (hard),ML,ML,SL,BC,L1,MEP reroutes; secondary beam flexibility assessed case by case
Pipe vs beam (hard),ML,ML,SL,BC,L1,As duct vs beam
Slab penetration MEP through structural slab,ML,SL,AL|PF,BC|PM,L2,Opening request from MEP; structural assessment mandatory
Wall penetration MEP through fire-rated wall,ML,PF,AL|SL,BC,L2,Fire-stopping spec by PF; MEP models penetration opening
Shaft volume conflict HVAC vs hydraulic,ML-M or ML-P (lower volume),BC,AL,PM,L2,BIM Coordinator mediates; larger volume system has priority
Foundation vs drainage civil vs structural,CL,SL,BC,PM,L2,Foundation has in-building priority; drainage reroutes at site boundary
Architectural wall vs structural frame,AL,SL,BC,PM,L2,Structural assessment required before architectural revision
Ceiling height conflict duct vs suspended ceiling,ML,AL,SL,BC,L1,MEP reroutes or reduces duct depth; architect records revised ceiling height
Sprinkler vs duct HVAC priority,PF or fire contractor,ML,BC,AL,L1,HVAC duct has priority; sprinkler branches reroute
Cable tray vs duct duct has priority,ML-E,ML-M,BC,AL|SL,L1,Electrical reroutes cable tray
Column encasement vs MEP service,ML,AL,SL,BC,L1,MEP reroutes around encasement; encasement size not reduced
Road grade vs basement wall,CL,AL,SL,PM|BC,L2,Civil adjusts grade or wall geometry; requires joint sign-off
Pile location vs incoming utility,SL or CL depending on flexibility,BC,PM,CL or SL (other party),L3,High-cost item; PM decision required with cost briefing

Appendix B: BCF Issue Sample (JSON)

{
  "version": "3.0",
  "project": {
    "project_id": "PRJ-2026-001",
    "name": "Sample Mixed-Use Development"
  },
  "topic": {
    "guid": "b4a3e2f1-7c8d-4a9b-b1e2-3f4a5b6c7d8e",
    "topic_type": "Clash",
    "topic_status": "Open",
    "creation_author": "[email protected]",
    "creation_date": "2026-06-02T09:47:00Z",
    "modified_author": "[email protected]",
    "modified_date": "2026-06-02T09:47:00Z",
    "assigned_to": "[email protected]",
    "due_date": "2026-06-09T17:00:00Z",
    "priority": "Major",
    "title": "Hard clash: 900mm SA duct through 610UB primary beam flange — Grid F7, Level 3",
    "description": "Hard clash detected between MEP supply air duct (900x450mm) and primary structural beam 610UB at grid intersection F7, Level 3. Clash depth: 140mm into bottom flange. System hierarchy rule: MEP is responsible for reroute proposal. Structural notch not permitted without formal assessment per BEP clause 4.3.2. Resolution deadline: 5 business days (Level 1 escalation). Escalates to Level 2 BIM Coordinator consultation on 2026-06-09 if unresolved.",
    "reference_links": [],
    "labels": ["MEP", "Structural", "Level 3", "Grid F7"],
    "raci_responsible": "[email protected]",
    "raci_accountable": "[email protected]",
    "raci_consulted": ["[email protected]"],
    "raci_informed": ["[email protected]", "[email protected]", "[email protected]"],
    "clash_type": "Duct vs primary beam (hard)",
    "system_hierarchy_responsible": "ML",
    "escalation_level": "L1",
    "comments": [
      {
        "guid": "c1d2e3f4-a5b6-7c8d-9e0f-a1b2c3d4e5f6",
        "date": "2026-06-02T09:47:00Z",
        "author": "[email protected]",
        "comment": "Clash assigned to MEP Lead per system hierarchy (BEP Table 3.1). Structural notch requires formal assessment and is not the first-pass resolution path. MEP to propose reroute options by 2026-06-09. If clearance with sprinkler zone is an issue, flag to BIM Coordinator for joint Level 2 consultation."
      }
    ],
    "viewpoints": [
      {
        "guid": "d4e5f6a7-b8c9-0d1e-2f3a-4b5c6d7e8f9a",
        "snapshot": "/viewpoints/d4e5f6a7/snapshot.png",
        "perspective_camera": {
          "camera_view_point": { "x": 42.5, "y": 18.3, "z": 12.1 },
          "camera_direction": { "x": -0.7, "y": 0.1, "z": -0.7 },
          "camera_up_vector": { "x": 0.0, "y": 1.0, "z": 0.0 },
          "field_of_view": 60.0
        },
        "components": {
          "selection": [
            {
              "ifc_guid": "3HQ$kzTTL8BhA0OWL2tPCu",
              "originating_system": "Revit 2026",
              "authoring_tool_id": "2045891",
              "description": "900x450 SA Duct — MEP model v12"
            },
            {
              "ifc_guid": "1Ks9pWvvX6Df8nLMQr7Yzb",
              "originating_system": "Tekla Structures 2026",
              "authoring_tool_id": "B-F7-L3-PRIMARY",
              "description": "610UB Primary Beam — Structural model v08"
            }
          ]
        }
      }
    ]
  }
}

Appendix C: Tie-Breaker Rule Set (YAML)

# federation-tiebreaker-rules.yaml
# Federation clash tie-breaker rules — include in BIM Execution Plan
# Version: 1.0 | Project: [PROJECT NAME] | Effective: [DATE]
# Parties who have reviewed and accepted these rules must be listed under signatories.
 
meta:
  version: "1.0"
  standard_reference: "ISO 19650-2:2018, clause 5.4.2"
  hierarchy_source: "BIM Corner System Hierarchy (bimcorner.com)"
  review_cycle: "Each coordination phase gate"
 
signatories:
  - role: "Lead Appointed Party / BIM Coordinator"
    accepted: false
    date: null
  - role: "Architectural Lead"
    accepted: false
    date: null
  - role: "Structural Lead"
    accepted: false
    date: null
  - role: "MEP Lead"
    accepted: false
    date: null
  - role: "Civil Lead"
    accepted: false
    date: null
 
system_hierarchy:
  # Lower index = higher priority (less moveable / harder to change)
  - index: 1
    system: "Structural primary frame (columns, primary beams, slabs, shear walls)"
    flexibility: "none"
    note: "Any modification requires structural assessment and redesign"
  - index: 2
    system: "Architectural primary envelope (external walls, fire-rated partitions, cores)"
    flexibility: "very low"
    note: "Modifications affect fire compartmentation or building envelope; require architect sign-off"
  - index: 3
    system: "HVAC primary (main supply/return trunk ducts, AHU connections)"
    flexibility: "low"
    note: "Rerouting primary ducts affects pressure drop and may require plant resizing"
  - index: 4
    system: "Plumbing primary (soil/waste stacks, hydraulic mains, medical gas mains)"
    flexibility: "low"
    note: "Gravity-dependent systems have limited slope flexibility"
  - index: 5
    system: "HVAC secondary (branch ducts, FCU connections, exhaust branches)"
    flexibility: "medium"
  - index: 6
    system: "Plumbing secondary (branch lines, hot/cold water branches, fixtures)"
    flexibility: "medium"
  - index: 7
    system: "Fire protection primary (sprinkler mains)"
    flexibility: "medium-low"
    note: "Hydraulic calculations must be re-run for any reroute"
  - index: 8
    system: "Fire protection secondary (sprinkler branches, heads)"
    flexibility: "medium-high"
  - index: 9
    system: "Electrical primary (busbars, cable tray mains, HV distribution)"
    flexibility: "medium"
  - index: 10
    system: "Electrical secondary (conduit runs, cable tray branches)"
    flexibility: "high"
  - index: 11
    system: "Low-voltage / data / comms (data cable trays, AV, security)"
    flexibility: "very high"
 
tiebreaker_rules:
  - id: "TB-01"
    situation: "Two systems at the same hierarchy level clash"
    resolution: "System serving the larger area or volume has priority. The smaller-area system resolves."
    example: "Two branch ducts from different mechanical sub-consultants in the same ceiling plenum"
 
  - id: "TB-02"
    situation: "Lower-ranked system has no feasible rerouting alternative"
    resolution: "Escalate to BIM Coordinator (Level 2) within 5 business days. BC chairs joint consultation. If no consensus within 10 business days total, escalate to PM (Level 3)."
    note: "Party claiming no feasible alternative must provide documented routing study showing at least three attempted alternatives"
 
  - id: "TB-03"
    situation: "Resolution of a clash by lower-ranked system creates a new clash with a higher-ranked system"
    resolution: "New clash is treated as a new primary clash in the next coordination cycle. The party who created the new clash through their reroute is Responsible for resolving both."
 
  - id: "TB-04"
    situation: "Interface zone with no clear system hierarchy (e.g., shaft volume allocation)"
    resolution: "BIM Coordinator is Accountable. Allocation is based on documented spatial reservation from BEP or earliest shared model. If no prior reservation exists, allocation is proportional to system volume requirements."
 
  - id: "TB-05"
    situation: "Fire-safety constraint overrides system hierarchy"
    resolution: "Any system penetrating a fire-rated assembly is subject to fire-stopping requirements regardless of hierarchy position. The passive fire specialist (or assigned role holder) is Accountable for the penetration detail. This rule takes precedence over all hierarchy rules."
 
  - id: "TB-06"
    situation: "Heritage or existing structure overrides standard hierarchy"
    resolution: "Where existing structure is designated heritage or cannot be modified for reasons other than structural integrity (e.g., conservation requirements), it is treated as hierarchy index 0 (highest priority). Document in BEP project-specific deviations."
 
clash_tolerance_defaults:
  hard_clash:
    definition: "Actual geometric overlap between two model elements"
    tolerance: "0mm (any overlap is a hard clash)"
    treatment: "Must be resolved before construction documentation issue"
 
  clearance_clash:
    definition: "Geometry within minimum maintenance or installation clearance zone"
    treatment: "Must be reviewed; may be accepted with documented justification"
    defaults_by_system:
      - system: "Structural primary"
        clearance_mm: 50
      - system: "HVAC primary"
        clearance_mm: 75
      - system: "Plumbing primary"
        clearance_mm: 50
      - system: "Electrical cable tray"
        clearance_mm: 150
        note: "Per electrical installation standard for maintenance access"
      - system: "Fire protection mains"
        clearance_mm: 100
        note: "Per sprinkler installation standard"
 
  duplicate_clash:
    definition: "Same clash reported multiple times due to model element subdivision"
    treatment: "Deduplicated by BIM Coordinator before distribution; counted as one issue"
 
escalation_timeouts:
  level_1_days: 5
  level_2_days: 10
  level_3_days: 15
  note: "Days are business days. Timeouts are from initial BCF issue creation date, not from escalation trigger."
 
freeze_schedule:
  model_submission_deadline_before_meeting_hours: 48
  late_submission_policy: "Late models are held for next coordination cycle. Do not delay the cycle to accommodate late submissions."

BIM Mobius publishes practitioner-level content for AEC professionals working with digital construction workflows. This article reflects current industry practice as of June 2026. Regulatory requirements vary by jurisdiction; verify with your local building authority.