AI for IFC-Based Federated Model Coordination Across Disciplines
A $120M research-lab project federates four discipline models into the Common Data Environment (CDE) on a Friday afternoon: architecture from Revit, structural from Tekla, MEP from a contractor on AutoCAD MEP, and civil from a separate firm, each exported as an IFC 4.3 (ISO 16739) file and assembled in Autodesk Construction Cloud (ACC) Model Coordination. The clash engine runs overnight and returns a number that stops the room: thousands of hard and soft clashes across the federation, a wall of red that no human can triage by Monday's coordination meeting. The expensive part is not the count, it is what the count hides: among those thousands of clashes are the dozen that will stop a concrete pour or strand a fume-hood exhaust riser, and they are buried in the noise of duplicate geometry, tolerance hits, and clashes between disciplines that will never share the same space. This lesson designs how AI accelerates that triage on an openBIM federation, grouping, prioritizing by stakeholder impact, and assigning clashes across the four disciplines, and where the human boundary sits, because the AI is the analytic engine that finds and sorts, but the coordination resolution is a design decision the disciplines own. The artifact you will produce is the BIM Execution Plan (BEP) AI-coordination addendum: a document under ISO 19650 stating how AI is used in the coordination process, what it does and does not own, and the verification gates that govern it.
The Wall of Red on a Federated Lab Model
A laboratory is one of the most coordination-dense building types there is. The structural frame carries vibration criteria for sensitive equipment, the mechanical system moves enormous volumes of conditioned and exhaust air for fume hoods and biosafety cabinets, the plumbing carries lab gases and acid-waste, and the electrical and low-voltage systems thread power and data to every bench, all in a ceiling plenum already crowded before anyone adds seismic bracing. When four disciplines model this independently and federate their IFC 4.3 files in the CDE, the clash count is not a sign of failure; it is the expected output of independent design colliding for the first time in a shared coordinate space. The wall of red is the federation working as intended: it has surfaced every place the disciplines have not yet reconciled.
The problem is triage, not detection. A clash engine in ACC Model Coordination or BIMcollab will happily report thousands of clashes, but most of them are not coordination problems. Some are duplicate geometry from a model exported twice. Some are tolerance hits where a pipe grazes a beam by three millimeters inside an acceptable construction tolerance. Some are clashes between an architectural finish and a structural element that the design already intends to embed. And some, the dozen that matter, are the ones where a 12-inch supply duct runs through a moment frame, or a fume-hood exhaust riser conflicts with a structural transfer girder, the clashes that will stop work or force an expensive field change if they reach the trades unresolved. The human cost of untriaged clashes is a coordination meeting where the room argues about geometry that does not matter while the clashes that do go unaddressed.
This is the same recognition the Level 2 clash-detection lesson established on a single federated model, now extended to the openBIM world where the disciplines live on different platforms and federate through IFC under an ISO 19650 CDE workflow. The platforms differ, the standard that holds them together is IFC 4.3, and the triage burden scales with the federation. The job is to get from the wall of red to the dozen that matter, fast enough to drive Monday's coordination meeting, which is exactly the work AI accelerates.
The Analytic Engine and the Human Resolution
The controlling distinction in this lesson, the one that the BEP addendum will codify, is the line between the analytic engine and the coordination resolution. The AI is the analytic engine: it ingests the federated clash report and does the work that drowns a human in volume, grouping clashes that are really one problem, filtering the noise, prioritizing by stakeholder impact, and proposing an assignment of each clash group to the discipline that should resolve it. This is the same triage the Level 2 lesson taught, now running across four disciplines on different platforms: it turns an overnight wall of red into a ranked, grouped, assigned worklist before the coordination meeting starts.
But the coordination resolution is not the AI's. A clash resolution is a design decision: when a duct and a beam occupy the same space, resolving it means deciding whether the duct reroutes, the beam gets a penetration the structural engineer must approve, the ceiling drops, or the program changes, each a choice with consequences for cost, for the other disciplines, and for the design intent the disciplines own. The AI can propose that the MEP discipline owns a duct-beam clash, and even suggest a reroute, but the decision to reroute, penetrate, or escalate is the discipline's design act, made by the people who hold responsible charge for that scope. The AI groups, prioritizes, and assigns; the disciplines resolve.
AI is the analytic engine that turns the wall of red into a ranked, grouped, assigned worklist, but the coordination resolution is the human's: a clash resolution is a design decision the disciplines own, because deciding to reroute, to penetrate, or to escalate is a choice with consequences for cost, for the other disciplines, and for the design intent, made by the people in responsible charge of that scope.
This maps directly onto the program's spine. The AI here is the pattern-detection engine and, where it proposes reroutes, the generative-design engine, governed by the verification gates: the design-intent gate (does the proposed resolution honor what the design is trying to do) and, on a lab, the life-safety gate (does it preserve the pressurization, exhaust, and egress the building depends on). The cardinal rule applies in its coordination form: verify before you commit a resolution to the model that other trades will build to. Gate, not mood: the boundary between what the AI owns and what the disciplines own is a written rule in the BEP, not a feeling that varies by how busy the coordinator is that week.
Grouping: Collapsing Thousands Into the Real Problems
The first thing the AI does, and the first thing that makes the wall of red tractable, is grouping. Thousands of raw clashes do not represent thousands of problems. A single duct running through a beam line generates a clash at every beam it crosses, so one routing problem can produce twenty clashes. A model exported with duplicate geometry generates a clash for every doubled element. A bundle of conduits running parallel to a structural member can light up the report dozens of times for what is, in coordination terms, one decision. Grouping collapses these: the AI clusters clashes that share a location, a pair of elements, or a root cause into a single coordination issue, so the worklist reflects problems to solve rather than geometry to count.
Grouping also filters the noise that should never reach a human. Duplicate-geometry clashes are an export error, not a coordination problem, and the AI can flag them for model cleanup rather than triage. Tolerance hits inside an agreed construction tolerance are not real conflicts and can be suppressed against the project's clash tolerance settings. Clashes between disciplines that the BEP has declared do not coordinate in a given zone, or between elements at LOD 200 not yet developed enough to coordinate, are premature and should wait. The grouping step is where the federation's thousands become the hundreds of real issues, which the prioritization step then ranks.
This is where the openBIM, multi-platform nature of the federation matters. Because the disciplines authored in different tools and exported through IFC, the same physical element can carry different identifiers, classifications, or geometry fidelity across the models, and the AI's grouping has to be robust to that. Two models may represent the same wall slightly differently after their IFC round-trip, and the grouping must not treat a translation artifact as a real clash. This is why the BEP must specify the IFC export settings, the model-element authorship, and the level of development by zone: the AI's grouping is only as good as the federation's information consistency, and that consistency is an ISO 19650 information-management discipline, not an AI capability.
Prioritizing by Stakeholder Impact
Once grouped, the issues have to be ranked, and the ranking is by stakeholder impact, not by clash count or by which discipline complains loudest. The Level 2 lesson established the priority logic and it carries forward: structural-versus-MEP clashes generally outrank MEP-versus-MEP clashes, which outrank clashes involving an architectural finish, because the consequence of leaving each unresolved differs. A duct through a moment frame implicates the structural system and may require an engineer's penetration analysis; an MEP-MEP clash in the plenum is a routing problem the trades can usually solve; a finish clash is often the cheapest to absorb. The AI proposes a priority order on this logic so the coordination meeting spends its hour on the issues that move the project.
On a lab, the priority logic gets a life-safety overlay that the AI must encode and the human must verify. A clash that threatens the fume-hood exhaust path, the room pressurization cascade, or the egress is not a routine plenum conflict, it is a life-safety issue, and it ranks accordingly regardless of which disciplines are involved. This is the life-safety verification gate expressed in the priority ranking: the AI can be configured to flag clashes in the exhaust, pressurization, and egress systems as top priority, but the coordinator verifies that the flagging is correct, because a mis-ranked life-safety clash that drops down the list is the kind of quiet failure that surfaces in commissioning or, worse, in operation.
Prioritization is also where the AI's proposal is a proposal, not a verdict. The AI ranks on the rules it has been given, but the coordinator knows things the rules do not capture: that a particular zone is on the critical path this month, that a specific trade is fabricating next week and needs its clashes resolved first, that an owner-sensitive space (the vivarium, the cleanroom) warrants extra scrutiny. So the priority order is the draft agenda, and the coordinator adjusts it with the schedule and project knowledge the AI does not hold. The ranking is the AI's analytic output; the agenda is the coordinator's judgment applied to it.
Assigning Clashes Across the Federation
The third analytic step is assignment: routing each grouped, prioritized issue to the discipline that should own its resolution. In a four-discipline federation, this is non-trivial, because a clash involves two elements and therefore at least two disciplines, and the question of which one resolves it is itself a coordination call. A duct-through-beam clash could be the MEP team rerouting the duct or the structural team approving a penetration, and the BEP coordination protocol should establish a default (typically the more flexible system moves, and structure is the least flexible), with the AI proposing the assignment on that protocol and creating the issue in the CDE assigned accordingly.
The assignment in an ISO 19650 CDE is not just a label, it is a workflow state. When the AI assigns a clash group to the MEP discipline as a BCF (BIM Collaboration Format) issue in ACC or BIMcollab, that issue enters the responsible party's queue with a status, an owner, and a due date, and it moves through the CDE's information states (work in progress, shared, published) as the disciplines resolve and verify it. The AI accelerates the creation and routing of these issues at the scale of the federation, which is the value: a coordinator who would spend a day manually creating and assigning hundreds of issues gets a populated, assigned issue list to review instead.
But review it they must, because the assignment is a coordination decision the AI is proposing, not making. The AI assigns on the default protocol, and the coordinator confirms or overrides: this duct-beam clash looks routine and the duct should move, but that one is in a structurally constrained bay where the better answer is a coordinated penetration, so the coordinator reassigns it to a joint structural-MEP resolution. The AI's assignment handles the routine majority at speed; the coordinator's review catches the cases where the default protocol gives the wrong owner, exactly the consequential clashes where getting the resolution path right matters most.
The CDE and the ISO 19650 Information Spine
None of this works without the information-management discipline underneath it, which is the point of ISO 19650 and the CDE. The CDE is the single source of truth for the federation: every discipline publishes its model into it, the federation is assembled there, the clashes are detected there, and the issues are managed there, all under the information-state workflow ISO 19650 defines. The AI's coordination work sits on top of this spine, and is only as reliable as the spine is disciplined. If the disciplines publish inconsistent models, export IFC with mismatched settings, or skip the information-state transitions, the AI's grouping and assignment degrade, because the AI is reasoning over a federation that does not faithfully represent the design.
This is why the BEP, the project's information-management plan under ISO 19650, is the right home for the AI-coordination rules. The BEP already specifies the CDE platform, the federation strategy, the IFC export settings, the model-element authorship (who authors which element), the level of development by milestone (LOD 100 through 500 per BIMForum), and the coordination schedule. The AI-coordination addendum extends this: it states which AI capabilities are used in the coordination process, what they own and do not own, and the verification gates, so the AI's role is governed by the same plan that governs the rest of the information management, not bolted on as an undocumented tool the coordinator happens to use.
The LOD progression matters here because it scopes what can be coordinated when. Coordinating geometry at LOD 200, where elements are generic placeholders, produces clashes that are not yet real, while coordination at LOD 350, where elements carry the interfaces and connections to adjacent systems, produces clashes worth resolving. The BEP states the LOD by zone and milestone, and the AI-coordination addendum should tie the AI's triage to it, so the AI does not waste the coordinator's attention on clashes between elements that are not yet developed enough to coordinate. The information spine, the CDE under ISO 19650 with a disciplined BEP, is the foundation that makes the AI's analytic work trustworthy.
The Applied Problem: The BEP AI-Coordination Addendum
Here is the exercise. For the $120M lab project, you are the VDC manager assembling the four-discipline IFC 4.3 federation in the CDE, and you will produce the BEP AI-coordination addendum: the section of the BIM Execution Plan, under ISO 19650, that governs how AI is used in the federated coordination process. The addendum has to make the analytic-engine-versus-human-resolution boundary explicit, so that every party on the project knows what the AI does, what it does not, and how its output is verified before it drives a coordination decision.
Produce three parts. First, the AI's role: state the analytic capabilities the AI provides (grouping clashes into coordination issues, filtering noise such as duplicate geometry and tolerance hits, prioritizing by stakeholder impact with the structural-MEP over MEP-MEP over architectural logic and the life-safety overlay for exhaust, pressurization, and egress, and proposing the cross-discipline assignment on the BEP's resolution protocol). Second, the boundary: state explicitly that the AI does not resolve clashes, because a clash resolution is a design decision the disciplines own, and that every AI-proposed priority, assignment, and reroute is a proposal the responsible discipline reviews and adopts or overrides. Third, the verification gates: the design-intent gate (a resolution must honor the design), the life-safety gate (a lab resolution must preserve pressurization, exhaust, and egress), and the cardinal rule in coordination form (verify before committing a resolution to the model the trades build to), with the gate-not-mood discipline that these are written rules, not the coordinator's discretion.
The deliverable is the BEP AI-coordination addendum; the lasting product is a federation-coordination process where AI does the triage no human can do at the scale of a lab federation, while the disciplines own the resolutions and the addendum keeps the boundary explicit and verifiable. The professional who masters this coordinates a four-discipline IFC federation faster than the manual scramble allowed, while keeping the design decisions where they belong, with the disciplines in responsible charge, because the AI's acceleration of grouping, prioritization, and assignment cannot diminish the human ownership of the coordination resolution, and the BEP addendum is the artifact that says so in writing.
Key Takeaways
- A four-discipline IFC 4.3 federation on a lab project produces thousands of clashes when assembled in the CDE, but the count is the federation working as intended, surfacing every unreconciled collision; the problem is triage, not detection, because the dozen clashes that stop work are buried in noise.
- The controlling distinction is the analytic engine versus the coordination resolution: the AI groups, prioritizes by stakeholder impact, and proposes cross-discipline assignment (the analytic engine), but a clash resolution is a design decision the disciplines own, because deciding to reroute, penetrate, or escalate has cost, cross-discipline, and design-intent consequences.
- Grouping collapses thousands of raw clashes into the real coordination issues by clustering clashes that share a location, element pair, or root cause, and it filters noise (duplicate geometry, tolerance hits, premature LOD 200 clashes), turning the wall of red into a worklist of problems to solve.
- Prioritization ranks by stakeholder impact (structural-MEP over MEP-MEP over architectural finish) with a life-safety overlay on a lab, where clashes threatening fume-hood exhaust, pressurization, or egress rank top regardless of disciplines, expressing the life-safety verification gate in the ranking.
- Assignment routes each issue to the resolving discipline on the BEP's protocol (typically the more flexible system moves), creating a BCF issue in the ISO 19650 CDE with an owner, status, and due date; the AI handles the routine majority at speed while the coordinator overrides the consequential cases.
- The CDE under ISO 19650 is the information spine: the AI's coordination work is only as reliable as the federation's information consistency (IFC export settings, model-element authorship, LOD by zone per BIMForum), so the BEP, not an undocumented tool, is the right home for the AI-coordination rules.
- The BEP AI-coordination addendum is the artifact: it states the AI's analytic role, the explicit boundary that the AI does not resolve clashes, and the verification gates (design-intent, life-safety, and the cardinal rule in coordination form, verify before committing a resolution to the model the trades build to), with gate-not-mood as written discipline.
Skill.re