Finding a possible problem in a building model is easy to demonstrate. Proving what was checked, which revision was used, and who accepted the resolution is the harder engineering task.
The coordination problem is not just detection
A mechanical duct appears to intersect a structural member in a federated BIM model. A clash-detection application highlights the geometry. An AI assistant reads the issue and produces a polished explanation: the duct should be rerouted.
That explanation may be useful. It may also be wrong. The intersecting objects could belong to different design revisions, the structural opening might already be approved, or the apparent clash might be an accepted construction condition. A confident sentence is not evidence that a design defect exists.
For a project team, the useful output is not simply a description of a clash. It is a controlled question: which objects, in which model versions, appear to conflict; what requirement is relevant; what evidence supports the finding; who is responsible for review; and what must happen before the issue can be closed?
This article proposes an AI-assisted, human-governed workflow for that question. It combines established openBIM exchange mechanisms with additional evidence and approval controls. It does not claim that the workflow is mandated by a single standard or that it has already been deployed by Jarlhalla.
1. What IFC and BCF actually provide
Industry Foundation Classes (IFC) is an open information schema for built assets. buildingSMART lists IFC 4.3 ADD2 as an official release associated with ISO 16739-1:2024 [1]. IFC can represent building elements, relationships and properties, but an IFC export does not independently prove that the model is current or technically correct.
BIM Collaboration Format (BCF) addresses a different problem: communicating model-based issues between applications. buildingSMART describes both file-based exchange and a REST-based web-service approach, with issue context such as viewpoints and references to model elements [2].
The buildingSMART BCF API 3.0 specification includes services for projects, topics, comments, viewpoints, document references and event information. It also describes authorization controls for permitted actions [3]. These are useful building blocks for an auditable process.
They do not, by themselves, establish that a clash is a real defect, that a particular model revision is approved, or that a proposed design change is safe. Those decisions depend on project information management and professional review.
A practical distinction is essential:
- IFC can carry structured model information.
- BCF can carry coordination topics and model-related context.
- The project information environment must establish controlled versions, responsibility and authoritative documents.
- AI may help interpret and draft, but it must not silently become the approving engineer.
2. Why an AI-generated issue needs an evidence envelope
Imagine an AI assistant receives the text “duct clashes with beam” and a screenshot. It could generate a plausible recommendation without knowing which duct, which beam, or whether either object still exists in the current model.
A more reliable workflow attaches an evidence envelope to every AI-suggested issue. This is a proposed Jarlhalla editorial design pattern, not a formal BCF field set.
The envelope should record:
- Project and source: project identifier, originating application, relevant discipline and source location.
- Model revision: exact information-container identifier, revision, issue date and, where useful, a file checksum.
- Object references: IFC GlobalIds or other stable project identifiers for the affected elements, with an explicit warning when mapping is uncertain.
- Observation: the clash-test result, rule-check result, inspection note or other original finding.
- View context: viewpoint or snapshot sufficient to help a reviewer reproduce the observation.
- Requirement: the approved design criterion or coordination rule against which the issue is being assessed.
- AI contribution: generated explanation, confidence limitations, model/tool version and the exact scope of AI assistance.
- Decision trail: assigned reviewer, disposition, supporting evidence and approval timestamp.
Some of these items may be represented by BCF topic fields, viewpoints, file references or comments. Others require linked records in a controlled document-management system. A BCF export should not be assumed to preserve every element of this proposed envelope.
The value is not more metadata for its own sake. The value is being able to answer, months later, why an issue was raised and what evidence justified its resolution.
3. Revision drift: the hidden failure mode
Coordination issues can outlive the model snapshots that produced them.
Suppose a structural model is revised on Monday and an MEP model is revised on Tuesday. On Wednesday, a coordination run accidentally combines the new MEP model with an older structural model. The AI assistant sees a collision and drafts an issue.
If the system records only a screenshot and a generic element label, the team may spend hours investigating a condition that no longer exists. Worse, it may issue an unnecessary instruction.
Information management under the ISO 19650 family addresses the organization, exchange, recording and versioning of project information. ISO 19650-1 provides concepts and principles, while ISO 19650-2 concerns the delivery phase [4][5]. CEN/TR 18093:2024 further addresses Common Data Environment workflows and the complexity of managing information-container versions [6].
The engineering response is straightforward: a generated issue should be tied to the exact input set used for detection.
Before creating or updating an issue, the application should verify that the model revisions are permitted for that coordination cycle. If they are not, it should label the result Revision mismatch — needs review, not a confirmed defect.
Where a model element’s identifier has changed between revisions, the system should avoid silently treating a new object as the same one. Object matching may require explicit mapping, geometric comparison and professional confirmation.
4. Let deterministic checks detect; let AI explain
Not every coordination task needs a language model.
A geometric clash engine should produce the geometry-based observation. A rules engine should determine whether a configured condition is met. A document register should identify the controlled revision. These functions are more appropriate for dedicated software than for a model asked to infer facts from a screenshot.
AI can still add value by drafting a readable issue description, grouping related observations, identifying missing context, proposing questions for the responsible discipline and summarizing a reviewer-approved resolution.
The division of responsibility should remain explicit:
| Workflow step | Preferred authority |
|---|---|
| Geometric interference detection | Dedicated coordination or model-checking software |
| Source revision and access validation | Controlled information environment |
| Natural-language issue summary | AI assistant, marked as generated |
| Technical severity and design response | Authorized project professionals |
| Status transition to verified or closed | Approved issue-management workflow |
This division also improves testing. If an AI explanation is misleading, the underlying clash result remains independently inspectable. If the clash detector is wrong, the issue can be rejected without pretending that better wording would fix the geometry.
5. BCF is a transport and coordination layer, not an approval certificate
BCF’s topic and comment mechanisms can support a structured conversation between disciplines. The API specification includes topic identifiers, assigned users, statuses, viewpoints and permissions, although exact permitted status values and actions can depend on the implementation and project extensions [3].
That flexibility is useful, but it creates a governance obligation. A topic marked “closed” does not automatically mean the technical issue has been independently verified.
For a high-consequence issue, teams may want to distinguish:
- Proposed: an AI or automated checker has suggested a finding.
- Accepted for review: a coordinator has confirmed that the issue is relevant and sufficiently evidenced.
- Assigned: an accountable discipline or professional is responsible for action.
- Resolved: a design response has been supplied.
- Verified: an authorized reviewer has checked the updated model and supporting documents.
- Closed: the project’s defined closure conditions have been met.
These labels are a proposed workflow. They should be mapped to the actual BCF server’s supported topic statuses rather than assumed to be standard enumerations.
The key safeguard is that an AI assistant cannot promote its own suggestion directly to an approved engineering outcome.
6. A worked example: a service route and structural bracing
Consider a hypothetical multi-storey building in which a ventilation route appears to intersect a diagonal structural brace.
An automated coordination run identifies the overlap. The evidence envelope records the IFC identifiers of both elements, the relevant model revisions, the test configuration and a reproducible viewpoint.
The AI assistant drafts:
“Potential coordination conflict between the ventilation route and the structural bracing. Confirm whether the model versions are approved for this review, whether a permitted penetration or design change exists, and which discipline owns the proposed resolution.”
This is a useful draft because it describes an observation and requests verification. It does not instruct the contractor to cut the brace or assert that rerouting is the only solution.
The structural engineer reviews the bracing requirements. The MEP engineer reviews routing options. The design coordinator records the agreed action. After a revised model is submitted, a new coordination check verifies whether the original interference remains.
If the issue is resolved, the reviewer records the evidence and authorizes closure. If the relevant model revision is unavailable, the issue stays open or explicitly unresolved.
No fabricated project result, time saving or compliance claim is required to demonstrate the process.
7. Security and permissions matter as much as model geometry
AI-connected coordination tools may have access to project models, documents and issue-management APIs. Their permissions should be narrower than those of the people who operate them.
The BCF API describes per-entity authorization and project-level permissions for operations such as creating topics and comments [3]. Those permissions must be enforced by the service, not merely requested in a prompt.
A sensible pilot starts with read-only retrieval and an isolated suggestion queue. Only after testing should an assistant be allowed to create proposed topics, and then only with constrained project access and a clear generated-content marker.
The assistant should not have unrestricted authority to change issue status, delete records, assign contractual responsibility or approve a design solution.
NIST’s AI Risk Management Framework, released on 26 January 2023, provides a voluntary approach to governing, mapping, measuring and managing AI risks. Its Generative AI Profile, published on 26 July 2024, extends the discussion to generative-AI-specific risks [7][8]. These frameworks support risk-based oversight but do not certify an individual BIM workflow.
Project files should also be treated as untrusted input to the AI application. A note embedded in a model or supplier document is evidence to examine, not an instruction that can override the application’s access rules.
8. A compact acceptance test before any production integration
A pilot should use known examples from approved model revisions and include both genuine conflicts and false positives.
The following acceptance gates are proposed, not universal industry thresholds:
- Traceability: every proposed issue points to an exact input model set and originating observation.
- Reproducibility: a reviewer can locate the affected elements and reconstruct the relevant viewpoint.
- Revision safety: stale or incompatible model versions trigger a warning rather than an unqualified defect.
- Technical restraint: AI text does not claim compliance or prescribe irreversible structural changes without authorized review.
- Authorization: the assistant cannot close, approve or delete issues beyond its role.
- Auditability: source, generated explanation, reviewer action and final disposition remain distinguishable.
Test cases should include missing object identifiers, changed element IDs, conflicting discipline revisions, duplicate observations, ambiguous screenshots, missing referenced documents and attempted unauthorized status changes.
Report results as pass, fail, needs review or not run. Record the denominator and test conditions; do not announce a success rate without a real test dataset.
9. A realistic implementation path
A construction organization can introduce this approach without building a fully autonomous agent.
Phase A — Read-only observation. Export a controlled IFC model set and existing BCF topics. Have the assistant summarize issues and flag missing evidence. Compare its output with an experienced coordinator’s assessment.
Phase B — Proposed issue drafting. Allow the assistant to prepare structured issue drafts with evidence envelopes. A person checks them before creation in the authoritative issue system.
Phase C — Controlled integration. Connect to a BCF-capable service using narrowly scoped credentials, duplicate detection and explicit role permissions. Verify each API operation in staging before any production change.
Phase D — Measured operational use. Evaluate review time, duplicate rate, incorrect issue rate, revision-mismatch detection and closure evidence. Compare results against a documented baseline, with an escalation path for safety-relevant findings.
This staged approach helps separate technical feasibility from claims of commercial value. It also allows the project to stop if the evidence is too weak or the integration creates more risk than it removes.
10. The deeper opportunity: coordination memory
BIM coordination often produces valuable knowledge that is difficult to reuse. A resolved issue may explain why a detail changed, which requirement controlled the decision, and which disciplines were consulted.
If that history remains linked to controlled model revisions and supporting documents, future teams can understand the reasoning rather than merely seeing the final geometry.
AI could help retrieve and summarize this project memory. But it should preserve distinctions between observation, proposal, decision and verification.
The objective is not to turn every clash into an automated command. It is to make every consequential coordination decision easier to reconstruct.
For a broader introduction to AI, BIM and digital twins, see Jarlhalla’s Artificial Intelligence and Sustainable Construction. This article addresses the narrower operational question of how model-based issues can become accountable decisions.
Conclusion: an issue is not resolved because the dashboard says so
AI can make BIM coordination faster to read and easier to organize. It cannot replace the need to know which models were checked, what the evidence showed and who accepted the engineering response.
IFC supplies structured model information. BCF supports issue exchange. Controlled information management establishes revision authority. Deterministic checks provide reproducible observations. Qualified professionals retain responsibility for technical decisions.
A trustworthy workflow brings those layers together without confusing their roles.
The most valuable AI-generated BIM issue is not the one that sounds most certain. It is the one that another professional can independently verify.
Sources and verification register
[1] buildingSMART International, IFC Schema Specifications. Official specification index; IFC 4.3 ADD2 and ISO 16739-1:2024, released April 2024.
[2] buildingSMART International, BIM Collaboration Format (BCF) — introduction. Official explanation of file exchange, REST service and model-based issues; undated reference page.
[3] buildingSMART International, BCF API 3.0 specification. Public specification of topics, viewpoints, comments, authorization and events; living implementation documentation, checked 2 November 2026.
[4] ISO, ISO 19650-1:2018 — Concepts and principles. Information-management principles for the built asset lifecycle; 2018.
[5] ISO, ISO 19650-2:2018 — Delivery phase. Information-management requirements for asset delivery; 2018.
[6] CEN, CEN/TR 18093:2024 — Common Data Environment workflow. Published October 2024; CDE workflow and information-container management.
[7] NIST, AI Risk Management Framework. Released 26 January 2023; voluntary AI risk governance, measurement and management.
[8] NIST, Generative AI Profile, NIST AI 600-1. Released 26 July 2024; risk-management guidance for generative AI.
Source limitations: Public descriptions and technical specifications were reviewed, not the licensed full text of ISO standards. No claims are made that ISO 19650 prescribes the proposed evidence envelope or AI approval states. The BCF technical introduction may redirect or restrict direct browsing; the official API repository independently supports the key BCF claims.