# From BIM Clash to Verified Decision: An AI–BCF Evidence Workflow

- Link: https://jarlhalla.com/ai-bcf-bim-issue-evidence-workflow/
- Published: 2026-11-02T17:54:56+01:00
- Author: knoksen

_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:

 1. **Project and source:** project identifier, originating application, relevant discipline
    and source location.
 2. **Model revision:** exact information-container identifier, revision, issue date
    and, where useful, a file checksum.
 3. **Object references:** IFC GlobalIds or other stable project identifiers for the
    affected elements, with an explicit warning when mapping is uncertain.
 4. **Observation:** the clash-test result, rule-check result, inspection note or other
    original finding.
 5. **View context:** viewpoint or snapshot sufficient to help a reviewer reproduce
    the observation.
 6. **Requirement:** the approved design criterion or coordination rule against which
    the issue is being assessed.
 7. **AI contribution:** generated explanation, confidence limitations, model/tool 
    version and the exact scope of AI assistance.
 8. **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:

 1. **Traceability:** every proposed issue points to an exact input model set and originating
    observation.
 2. **Reproducibility:** a reviewer can locate the affected elements and reconstruct
    the relevant viewpoint.
 3. **Revision safety:** stale or incompatible model versions trigger a warning rather
    than an unqualified defect.
 4. **Technical restraint:** AI text does not claim compliance or prescribe irreversible
    structural changes without authorized review.
 5. **Authorization:** the assistant cannot close, approve or delete issues beyond 
    its role.
 6. **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](https://jarlhalla.com/ai-sustainable-construction-bim-digital-twins/).
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](https://technical.buildingsmart.org/standards/ifc/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](https://technical.buildingsmart.org/standards/bcf/).
Official explanation of file exchange, REST service and model-based issues; undated
reference page.

[3] buildingSMART International, [BCF API 3.0 specification](https://github.com/buildingSMART/BCF-API/tree/release_3_0).
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](https://www.iso.org/standard/68078.html).
Information-management principles for the built asset lifecycle; 2018.

[5] ISO, [ISO 19650-2:2018 — Delivery phase](https://www.iso.org/standard/68080.html).
Information-management requirements for asset delivery; 2018.

[6] CEN, [CEN/TR 18093:2024 — Common Data Environment workflow](https://www.evs.ee/en/cen-tr-18093-2024).
Published October 2024; CDE workflow and information-container management.

[7] NIST, [AI Risk Management Framework](https://www.nist.gov/itl/ai-risk-management-framework).
Released 26 January 2023; voluntary AI risk governance, measurement and management.

[8] NIST, [Generative AI Profile, NIST AI 600-1](https://www.nist.gov/publications/artificial-intelligence-risk-management-framework-generative-artificial-intelligence).
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.

From BIM Clash to Verified Decision: An AI–BCF Evidence Workflow