Artificial intelligence can read a building model quickly. That does not mean the model contains the information required to support a reliable decision.
The problem begins before the prompt
Imagine an AI assistant asked to identify fire-rated partitions, compare thermal properties or summarize quantities from an IFC model. The geometry looks convincing. The model opens. Yet some walls have no required property, others use inconsistent classifications, and several objects are linked to the wrong delivery milestone.
A fluent answer may conceal those gaps. The safer response is not to ask the model to guess. It is to establish whether the source data is ready for the intended use.
This is where Information Delivery Specification (IDS) offers a useful foundation. buildingSMART approved IDS 1.0 as a final standard in June 2024. IDS lets project teams define machine-interpretable requirements for IFC information and check model data against them [1, 2].
IDS is a data contract, not an engineering certificate
An IDS specification can define which IFC entities are relevant and which attributes, classifications, materials, properties or values they must contain. A validator can report whether the supplied information satisfies those rules [1].
Consider a simple illustrative requirement: all walls in a designated scope must carry a specified fire-rating property using permitted values. A checker may distinguish a compliant value from a missing or invalid one.
But a passing check does not prove that a wall actually achieves the stated fire resistance. That requires appropriate design, product evidence, testing, classification and professional assessment. Nor does IDS validate geometric clashes: buildingSMART explicitly identifies geometry as outside IDS’s alphanumeric validation scope [1].
This distinction matters whenever AI turns structured data into confident narrative.
Five gates before AI interpretation
The following is a proposed Jarlhalla editorial workflow, not a standard-mandated sequence or an implemented product.
Gate 1 — Declare the intended decision. Specify what the AI is being asked to support: asset handover, quantity review, maintenance classification or preliminary sustainability screening. A generic declaration that a model is “BIM compliant” is not enough.
Gate 2 — Freeze the input baseline. Record the IFC schema version, model revision, issue date, author, file checksum and the exact IDS specification version. Without this, a result cannot reliably be reproduced.
Gate 3 — Run deterministic checks. Validate IFC file integrity and apply the agreed IDS rules using a suitable checker. Separate failed checks, not-applicable rules and requirements that were never specified. Do not label untested data as passed.
Gate 4 — Triage exceptions with accountable people. A BIM coordinator or responsible discipline determines whether a failed requirement is a modelling error, an information gap, a contractual exception or a rule that needs correction. The AI may summarize exceptions, but should not silently repair source data or approve a waiver.
Gate 5 — Release only the supported AI task. Permit the AI to work with the verified data subset and explicit caveats. If a task depends on missing information, return “insufficient verified data” and identify the missing fields rather than inventing them.
The output is a decision-specific readiness statement, not a universal model quality score.
What a useful preflight report contains
A minimal report should capture:
| Record | Why it matters |
|---|---|
| Model and IDS versions | Makes the check reproducible |
| Intended AI task | Defines which data quality matters |
| Applicability and tested elements | Prevents misleading pass rates |
| Passed, failed and untested requirements | Separates evidence from absence |
| Exception owner and disposition | Keeps responsibility visible |
| Approved scope and restrictions | Prevents overclaiming downstream |
For example, a model may pass classification requirements for 95 of 100 applicable assets while missing maintenance data for 20. Those numbers are hypothetical. The correct conclusion is not “95% ready for every AI task”; it depends on whether the intended task needs classifications, maintenance information, or both.
Combine IDS with an information-management workflow
IDS complements rather than replaces project information requirements. The standard can encode selected exchange requirements as testable rules [1, 2]. CEN/TR 18093:2024 addresses Common Data Environment workflows in the context of EN ISO 19650 and covers information-container versioning [3].
A practical project should therefore retain the source model, requirement set, validation results and authorized disposition together in its controlled information environment. This is a proposed implementation choice, not a claim that ISO 19650 mandates the specific five-gate workflow described here.
AI governance must begin at the data boundary
NIST’s voluntary AI Risk Management Framework, released in January 2023, organizes risk management around Govern, Map, Measure and Manage. Its Playbook offers suggested governance, documentation and monitoring practices rather than a mandatory certification checklist [4, 5].
Applied to BIM analysis, that means assigning ownership of input requirements, documenting the model and validator versions, testing failures deliberately, and reviewing whether an AI answer overstates what the validated source proves.
An IDS pass is a structured-data check. An AI evaluation measures model behavior. A professional design review establishes technical acceptability. These are different assurance layers and none automatically substitutes for the others.
A proposed 30-day pilot
A small pilot could start with one IFC discipline model and one narrowly defined use case.
Week 1: Choose the AI-supported task, define information requirements, establish a model baseline and select a limited IDS rule set.
Week 2: Run validation, classify failures and confirm whether the rules correctly express the intended exchange requirements.
Week 3: Compare AI outputs on the original model and the verified subset. Log unsupported statements, omitted caveats and requests for unavailable information.
Week 4: Review exceptions with the relevant professionals and produce a go/no-go recommendation for that single use case.
Useful pilot measures include requirement coverage, failed-check disposition, traceability of inputs and the proportion of AI answers that accurately disclose missing data. No performance improvement should be claimed without actual measured results.
The bigger opportunity: make “not ready” a useful answer
A credible digital construction system should be able to refuse an unsupported inference. The value of an IDS preflight is not that it makes AI infallible. It gives teams a transparent boundary between what the model demonstrably contains and what still needs evidence or expert judgment.
For Jarlhalla’s broader interest in BIM, digital twins and responsible AI, that boundary is a practical starting point for trustworthy automation: requirements first, validation second, interpretation third, and accountable decisions throughout.
Related reading: From BIM Clash to Verified Decision and The 100-Case Test.
Sources and verification notes
- buildingSMART International, Information Delivery Specification (IDS). IDS 1.0 approved in June 2024; scope, examples, and explicit geometric limitations.
- buildingSMART Technical, Information Delivery Specification project. Technical description of exchange requirements, IFC information validation and project applications.
- CEN/TR 18093:2024, Framework and Implementation of Common Data Environment Solutions and Workflow. Published 2024; scope description. Full licensed technical report was not reviewed.
- NIST, AI Risk Management Framework. Released 26 January 2023; voluntary risk-management framework.
- NIST, AI RMF Playbook. Suggested Govern, Map, Measure and Manage actions. NIST is revising the framework and plans to update the Playbook after the revision.
- buildingSMART, IDS technical repository. Public XML schema, documentation and implementation examples.
Source boundaries: Primary institutional sources were reviewed on 9 November 2026. No claim is made that IDS certifies engineering safety, checks geometry or that this proposed workflow is prescribed by ISO 19650. Pilot metrics and examples are illustrative, not measured Jarlhalla results.