A file format won't fix vague BIM

An IFC or COBie file is a printout of the model. It is not a plan, and it goes stale.

Across Canada and the United States, owners are told that open formats are the answer. In the United States, COBie has been part of the national BIM standard since 2012.³⁴ The federal highway agency's 2021 roadmap for state transportation departments points to the IFC work on bridges and roads as its starting point.³⁵ Canada published ISO 19650-2 as a national standard in November 2024.³⁶ In Canada, the push is led by buildingSMART Canada, the national chapter of the body that maintains IFC. Its 2024 report with the National Research Council, openBIM implementations for a Canadian roadmap, calls on the industry to move towards openBIM-based solutions and says Canada can set clear openBIM mandates for public projects.⁴⁰

One disclosure up front: OpenBEP's founder works at VIM, a company with its own exchange format, which this page discusses with other alternatives near the end.

We agree with much of the open BIM case. We disagree with an idea we hear often: that if public owners require IFC and open tools on every project, the industry's BIM problems will go away.

In our experience, the main problem is not the file format. It is that owners ask for "the BIM" without saying what it is for. A vague model saved as IFC is still a vague model.

This is a disagreement about priorities and order, not about anyone's good faith. Quotes from Dutch and Japanese sources are our translations.

What open BIM gets right

Notice what these have in common. IDS and BCF describe requirements and issues. They do not try to be the master copy of the model.

An export is a PDF of the model

The Canadian roadmap report says that being platform agnostic encourages interoperability among various BIM software platforms and prevents vendor lock-in effects.⁴⁰ A format guarantees that another program can open the file. It does not make the file a working model.

• Even advocates of IFC use this comparison. In a 2019 interview, an IFC file from a Revit model was likened to a PDF made from a Word file: you can read the text, but you cannot do word processing in it.² The point then was that anyone can read it. Our point is the other half: in the authoring tools most firms use, you cannot keep working in it.
• Revit's own help says that opening an IFC file creates a new model from the default template, and points users to linking the IFC as reference information instead.⁴
• There is a fair counterpoint: some tools, such as Bonsai (formerly BlenderBIM), author directly in IFC, so for them IFC is the native file. Few firms work that way today, and a requirement should fit how projects are actually delivered.
• The Netherlands keeps IFC on the "comply or explain" list that public bodies must require. But in 2019 its Standardisation Forum made clear that IFC models are an output of the source model for communication and coordination, and that "they do not replace the source models".⁵
• Japan's building permit review, open since April 2026, works the same way. The PDF drawings exported from the BIM model are what is reviewed. The IFC file exported with them is a reference for understanding the shape: the manual says reviewers make no decision based on information found only in the IFC data, the IFC is not kept as a legal record, and it is not used for the interim or final inspections.³⁸
• What made that review possible was not the file format. It was a common set of input and output rules, written element by element (grids, columns, beams, slabs, walls and so on), that every designer using it submits a written pledge to follow.³⁸ That is a requirement written by the party that will use the files, and it is the part most open BIM roadmaps leave for later.
• Canada's 2024 roadmap report gives Japan as an example: it says the ministry has mandated the use of IFC for building code checks.⁴⁰ The ministry's manual, published since, describes something narrower: the IFC is filed with the drawings as a reference, and the drawings are what is checked.³⁸

Stale at the first renovation.

A delivered IFC or COBie file is a snapshot. In 2016 a senior BIM engineer described COBie as the BIM equivalent of the two-inch thick phone directory that we all used to receive every year – it's out of date even as it lands on your doorstep.⁶ In our experience the same is true of an IFC archive. The day the building is renovated, the work happens in the native model, which is updated, and the IFC and COBie files have to be exported again. An archive of exports is an archive of old printouts.

So the native authoring files should be the contractual master, and exports are extra outputs, asked for when a named use needs them. This has a cost we accept openly: native files tie the archive to one vendor's format, which is the lock-in open BIM roadmaps warn about.⁴⁰ Our answer is that an owner keeps control by owning the native files and by stating, use by use, what data it needs and in which format. A blanket IFC rule does not give that control on its own.

Some Canadian owners already write it this way. Metrolinx, Ontario's transit agency, asks for both native files and exchange files at every submittal, drawings in both PDF and native format, and accepts federated models as Navisworks or IFC.³⁷ In that scheme the native file is the working copy and the exports serve named uses.

Filtering is a feature, if the owner sets the filter.

An IFC export never holds all the data of the original model: the exporting software writes only the subset its model view definition covers.¹⁰ That is usually presented as a weakness. We see it the other way. An owner does not want every working parameter and every helper object a designer used. It wants the data its uses need, and nothing else. That is the idea behind our LOD specification, where the as-built level keeps less than the construction model, not more. The problem is not that exports filter. It is that, without owner requirements, nobody decides what the filter keeps.

The problem with IFC

Requiring IFC on every project means asking every firm to carry the weight of the standard as it is today. buildingSMART, the body that maintains IFC, and the researchers who work with it have been frank about that weight.

Too big to implement, so it splits into dialects.

• buildingSMART's own blog: This rich set of agreements is often too much for a software developer to implement in full into their software tool. Software therefore implements subsets, called model view definitions (MVDs).¹⁰
• The same article counts almost 20 MVDs in the next release: That means 20 different dialects of IFC. Twenty different implementations in software. When this continues the number of MVDs will reach hundred before we realize it. It admits As a community we have been explaining to outsiders that 'there is no one IFC', and calls the approach not sustainable.¹⁰
• A 2021 study inspected 57 IFC models from practice, almost all in the older IFC2x3 version, which is still what much of the market exchanges. IFC's flexibility allows several interpretations, which results in heterogeneous IFC solutions for similar situations which significantly hinders interoperability. Only 8 of the 39 models checked had sufficient semantics.¹¹
• So "deliver an IFC" in a contract means little on its own. Someone has to say which version, which subset and which properties, and check that the receiving software supports them.

Geometry that does not scale.

• The technical coordinator of buildingSMART Spain wrote in 2024 that IFC's STEP-based structure led to large file sizes and limited scalability, which affected the adoption and effectiveness of IFC in larger and more complex projects.²²
• Revizto, a coordination software maker that supports IFC, says IFC files can expand to 5-10 times the original file size in some cases, and that the impact is most pronounced in larger projects.²³
• buildingSMART's own blog says the current resource layer (mainly geometry) needs a cleanup.¹⁰
• The fix explored for IFC 5 is telling: triangular meshes as the main geometric representation, and repeated objects that inherit their geometry from a single typical element instead of being written out again.²² In other words, the way game engines and fast viewers have stored geometry for years.

A standard that keeps changing.

• IFC 5, the next version, is a redesign rather than an update.²² IFC 4.3 became the ISO standard only in 2024.³⁹
• In October 2026, buildingSMART's IFC 5 repository still calls its examples preliminary and not suitable for production use, says Further documentation will follow soon, and warns that future updates to the development will require revisions to these examples.¹²
• buildingSMART Spain's coordinator again: adding new concepts often requires significant changes, which can lead to incompatibilities between versions and difficulties in adopting new features.²²
• So the market stays on the old versions. Under a post about IFC 5, Ivan Shtaer wrote: implementing support for each new scheme every 4-5 years simply does not pay off. The market does not have time to digest this. The developer is forced to support versions 2X3 because a lot of data was created and exists in this format.¹⁹ IFC 4.3 is stable and an ISO standard, but a firm that tunes its exports for it today should expect to do much of that work again for IFC 5.

Where IFC earns its place.

Infrastructure is the strongest case for IFC. Its ISO edition of 2024, IFC 4.3, added bridges, roads, railways, waterways and port facilities.³⁹ In our experience Revit is rarely the authoring tool on that work, and several tools must share one model. The US federal highway agency's roadmap lists IFC, with LandXML, among the open standards state agencies can use to model engineering data.³⁵ Even there, the format only works when the owner says which version, which classes and which properties, and checks them.

Hard to read.

This one is our own view, from daily work: the IFC documentation is some of the hardest technical documentation in our industry to use, even for experienced BIM managers. Finding how one property of one element should be written means going through layers of entities, property sets, MVDs and versions. buildingSMART itself calls MVD one of the most confusing acronyms in its vocabulary.¹⁰ A standard that experts struggle to read is a poor base for a requirement placed on every firm, large or small.

The internet comparison does not hold.

A common argument compares IFC to the web's standards: thanks to HTML and HTTP, any browser can open any website. But a web page looks the same in every browser. Two IFC files of the same wall from two tools often do not: different classes, different property names, missing data, as the 2021 study found.¹¹ Open BIM also promises data that can still be used decades later. Data kept for decades is only useful if it was consistent in the first place: the same parameters, with the same names, filled in the same way on every project. IFC does not give you that. A shared parameter list and owner requirements do.

The problem with COBie

COBie is a spreadsheet handover format, built as a subset of IFC. The UK government's 2011 construction strategy required it on centrally funded projects.³⁷ That was a format requirement at national scale, and the results are on record. In the United States, COBie is part of the national BIM standard, where it first appeared in 2012 (version 2.26). The National Institute of Building Sciences has maintained it since 2013 and published version 3.0 in 2023.³⁴ We found no US study of how its data is used after handover to match the UK record below.

• Clients who asked for the format, not the content. Birmingham City University's BIM process manager: When a client just says ‘give me COBie’ without identifying their specific requirements, consultants will be ripping their hair out because that level of information is just not needed to manage buildings. It’s a big job for someone that will have to be paid for unnecessarily.³
• Data that could not reach the client's systems. In 2016, the year the UK mandate took effect, three of the people BIM+ interviewed reported difficulty importing COBie data into their maintenance software. Hampshire County Council's framework manager: We want to be able to transfer data into our CAFM systems after project delivery, but have not delivered that yet. In the same survey, 58% of respondents said they had never used BS 1192-4, the standard that describes COBie.³
• A short list was enough. When Argent, the developer of London's King's Cross, asked its asset managers, facilities managers and tenants what they actually needed, the answer was quite a short list. Its BIM lead: Full COBie data drops are not the route we want to go down.³
• Still misunderstood years later. In 2020, John Ford, a contractor's digital lead and an advocate of IFC and COBie, wrote that the lack of understanding of what COBie is, its purpose and how it is driven by IFC were three of its fundamental barriers today, followed by the lack of native support in software.⁷
• Contracts that pay for files, not information. In a 2020 UK government-funded consultation, every respondent on contracts agreed that common contracts drive the delivery of documents, not the delivery of usable, accessible, sufficient quality information.⁸
• Generic requirements. In Wales, a 2026 study heard: We get EIRs that are either copied from old projects or so generic they're useless. Participants described COBie outputs delivered as static spreadsheets late in delivery.⁹

To be fair, the 2016 article also quotes clients who valued full COBie data, such as Sandwell council for its housing.³ The difference is that those clients knew what they would do with the data.

Why it fails, in our view.

The points below are our own view, from daily work on Revit projects.

• It is not much more than a schedule export. A COBie workbook is a set of linked spreadsheet tabs. Apart from its links between spaces, zones, systems, spares and contacts, most of what it holds is what a Revit schedule exported to Excel or CSV would hold, with more ceremony.
• It cannot easily take you back to the model. The identifier in a COBie row is usually the IFC GlobalId, not the Revit element ID. Revit's Select by ID does not accept it; you need a plug-in, or a parameter the exporter stored, to find the element.
• You cannot tell where a value came from. COBie defines the columns, but not which model parameter feeds each one. The same value can come from several parameters, be renamed or be merged on the way out, and the file does not record which. Two teams rarely fill it in the same way.
• It needs consultants. Getting a team to deliver valid COBie takes training, checking tools and outside help, and a business of courses and services has grown around it. Bilal Succar, on the churn of handover standards from COBie to its successor: Countless people spent countless hours learning, implementing, resolving, and accommodating. Some have built learning materials and business offerings around A and B. They will have to do it again now, soon, and then again in the future. His letters stand for each successive standard.¹⁷

The tools around it.

The checking software tells the same story. In 2016 the US Engineer Research and Development Center released an open-source COBie checker, COBieQCReporter. Bill East, who created COBie, wrote that it depended on Java code Oracle stopped updating in 2019, and that efforts to revive it or crowd-fund a replacement since 2019 were without success.²⁵ His current checker, COBieQC, is not sold. Per his site, a user gets a complimentary 12-month copy after buying a printed user's manual, one per user, through a print-on-demand service. Trial versions are not available. The licence is checked online Every time the software starts, and technical support is not provided.²⁴ Bill East describes the software as a volunteer effort,²⁵ and we do not doubt the work behind it. Other checkers exist in commercial tools. But an owner requiring COBie should know that the reference checker from its creator comes on these terms.

• buildingSMART is developing a new framework, Asset Operations Handover, described as COBie's successor. Justin Kirby, writing up a Digital Construction Week talk by Skanska's head of digital construction, says COBie's rigid, spreadsheet-centric approach has increasingly led to massive data waste. It's highly effective at being written into contracts, but historically terrible at actually being used by the teams running, cleaning, and maintaining the buildings.¹⁶
• Bill East replied: The focus of COBie as a "spreadsheet' has always missed the point. It is about process - where consultants and subcontractors are required to deliver information when first created. Without process change you can call it whatever you want and it still won't work.¹⁶ On this we agree with him: the process is the point, and a format requirement does not deliver a process.

An owner who asks for COBie today is paying for a format on its way out. Ask operations for the short list of data they use, in the format their system imports.

ISO 19650 is not a revelation

ISO 19650 is often presented as if being an international standard made it the one source of truth. It is useful, but most of its core ideas were published years earlier, for free.

• In 2010, Penn State's Computer Integrated Construction research group published its BIM Project Execution Planning Guide under a Creative Commons licence. Its procedure has four primary steps: 1) identify BIM Goals and BIM Uses, 2) design BIM Project Execution Process, 3) develop Information Exchanges, 4) define supporting infrastructure for BIM Implementation.¹³
• ISO 19650-1 and -2 came out in 2018. They replaced British standards which, in the UK guidance's own words, formed the basis of the UK approach to BIM.¹⁴ The UK guidance also says plainly: The information content is the same information which has always been required during an asset's lifecycle.¹⁵
• In our reading, set side by side, much of it is a renaming. Penn State's BIM goals and uses became the owner's "information requirements". Its information exchanges became "exchange information requirements" and delivery plans. Its BIM Project Execution Plan became the "BIM execution plan". ISO 19650 does add useful things from the British standards, such as the chain of appointments and the workflow of the common data environment.
• So ISO 19650 is a good shared vocabulary for contracts. It does not tell an owner which uses it needs, and its text is sold under licence while Penn State's guide is free.

Free tools are not the bottleneck

Open-source tools are welcome. But in our experience, the price of a licence is rarely what stops a project from getting useful BIM. What stops it is an owner who cannot say what it needs, a team that was never trained to deliver it, and nobody checking the result. What the Welsh study's participants asked for was practical templates, worked examples and validation tools.⁹ A free tool in untrained hands produces a free vague model.

Other designs worth watching

If the industry wants open exchange that copes with very large models, it is worth looking at formats designed for that from the start. None of them is an ISO standard, and each is backed by one company or a small community. All of them are newer than IFC, and the claims below come from their own documentation; we have not benchmarked them.

Fragments, by That Open Company

That Open Company, the team behind IFC.js, publishes Fragments, which it describes as an open BIM format optimized for handling large datasets efficiently: binary, compact, and supporting geometries, properties, and relationships. Its viewer is designed to handle millions of elements in seconds. The format is built on Google's FlatBuffers, so anyone can write a reader or writer in any language, and the libraries are published under the MIT licence.²⁸ Its README says the easiest way to make Fragments is its built-in IFC importer, so today it builds on IFC rather than replacing it.²⁸

VIM

Disclosure: OpenBEP's founder works at VIM, the company behind this format. Weigh this part with that in mind.

An open-licence (MIT) binary format from the employer of OpenBEP's founder. Its specification describes it as a modern and efficient open 3D data interchange format designed for BIM and manufacturing data optimized for efficient loading and rendering on low-power devices.²⁶ Geometry is instanced triangle meshes; BIM data is relational tables.²⁶

• A value can be traced back. Unlike a COBie row, each element row keeps the Revit element id and unique id and the source file it came from, and every parameter value points to a descriptor with the parameter's name, group, instance-or-type flag and shared-parameter GUID.³³ A checker can say which parameter, on which element, in which file, gave a value.
• The model's own structure is kept. Worksets, phases, levels, design options, views and the volume and area of each material in each element are stored as tables, with the Revit category as authored rather than mapped to another schema's classes.³³
• Open code. The format libraries and a React-based web viewer are published under the MIT licence.²⁷
• Limits. It is one company's format, not an ISO standard. It stores meshes only, no parametric geometry. It is an export, so it goes stale like any export. Its own documentation says Revit element ids can repeat across linked files, and that even Revit's unique ids have been seen to repeat for built-in elements.³³ We have not benchmarked it against IFC and make no claim about size or speed.

And others

• Speckle is an open-source data hub that connects with your favorite AEC tools and streams objects between them, with an Apache-2.0 web viewer.²⁹
• dotbim is an open-source and minimalist file format for BIM, MIT-licensed, with triangulated meshes only and one page of documentation, against 100+ for IFC by its own count.³⁰
• iTwin.js, from Bentley, is An open source library for creating, querying, modifying, and displaying Infrastructure Digital Twins, under the MIT licence.³¹
• OpenUSD, the scene format created by Pixar, is, in its industry alliance's words, now being embraced by industries beyond the film industry, including architecture, engineering, construction.³² The IFC 5 work borrows ideas from it.²²

We are not asking owners to require any of these instead of IFC. Like IFC, they are exports, not authoring masters, so the native files still matter. Our point is narrower: a requirement written only as "deliver IFC" fixes the container, while a requirement written as "deliver this data, checkable against this IDS" fixes what matters and leaves room for better containers.

What practitioners say

We read public LinkedIn posts and the replies under them, including under buildingSMART International's own posts. Quotes are word for word. Where someone's role was not shown, we give only their name. The people defending IFC are quoted too.

• Marko Lazic: Two decades of standards, and "just send me the IFC" is still the sentence that ruins an afternoon. And: Every real project has a folder of half-broken exports and one person whose whole job is fixing what the format dropped.¹⁸
• Jelena Stevanovic, replying: IFC is often treated as the solution, when in reality it is only the container. Without clearly defined information requirements and proper QA, "open BIM" remains more promise than process.¹⁸
• Mayur Tanna, in the same thread, audited one federated IFC of about 3,200 objects: 352 elements exported as IfcBuildingElementProxy — their real class lost at export. 793 federation duplicates, and 133 storeys that are really 28 levels. He adds: How much is the format and how much is export settings, I can't tell from the receiving end.¹⁸
• Stefan Kovacs, replying to buildingSMART International's post about its 2026 Tokyo summit: The development of applications is progressing well, but mainly on a very theoretical level. As paying operators and builders, we need fast solutions (problem solving user cases)that support us in our tasks. He asks buildingSMART to set targets with time lines for the industry.²⁰
• Birgitta Schock, of buildingSMART Switzerland: openBIM has reached a level of technical maturity that would have seemed ambitious a decade ago. Yet many organisations still struggle to formulate what they actually want to achieve with it.²¹

The other side

• Steven S., replying to Lazic: "Just send me the IFC" is not an information requirement. In his view the sender and receiver often never defined the actual exchange properly, so the fault is not always IFC's.¹⁸ Erik Björnhage made the same point: Working with IFC is not really a problem, as long as everyone understands what they are asking for and what they are getting.¹⁸
• Menno Mekes: major contractors in the Netherlands demand and use IFC as project deliverable even when working with a big platform that only supports native models. And: It just works.¹⁹

The defenders and the critics end up in the same place: an exchange works when it has been defined and checked. That definition is the part owners skip, and it is what a BEP is for.

What did it cost?

We looked for measured figures: hours or dollars lost to COBie or IFC deliverables on a named project. We found none published, including in the LinkedIn threads above, where the nearest thing is one practitioner's count of errors in a single IFC file. The sources describe the waste in words, not numbers. If you know of a measured case, tell us and we will add it with its source.

What owners should ask for first

1. The uses. Name the BIM uses you need, phase by phase: coordination, quantities, permits, operations. No use, no requirement.
2. The content. For each use, list the elements, the level of development at each stage, and the parameters each element must carry, with the same names on every project.
3. The master files. Make the native authoring files the contractual deliverable, so the next team, and the next renovation, can keep working.
4. Checkable requirements. Issue the requirements as an IDS file as well, so a delivery can be checked automatically.
5. Issues in BCF. Ask for coordination issues in BCF so they move between tools with their viewpoints.
6. Exports only where a use needs them. Ask for IFC, or another exchange format, when a named party must use the model without the authoring software. Say which version and which properties.
7. Checks with consequences. Check the model at each milestone and hold payment until it passes.
8. Handover data people will use. Ask operations for the short list of asset data they actually use, in the format their system imports. Don't ask for COBie by default.

What this page does not say

• It does not say exports are useless. An export is the right tool when someone without the authoring software must use the model.
• It does not say open standards are a bad idea. IDS and BCF are worth requiring, and ISO 19650 is a useful vocabulary.
• It does not question anyone's motives. Much of the evidence on this page comes from buildingSMART and from open BIM's own advocates.

Sources

Every link below was opened and checked on October 20 or 21, 2026. Page numbers are PDF pages. Quotes from French, Dutch and Japanese sources are our translations; English quotes are word for word.

1. É. Poirier, C. Arnould, Les principes du BIM ouvert et de son application dans les projets publics, Feuille de route gouvernementale pour la modélisation des données des infrastructures, version approved May 14, 2025, p. 1, 2, 8, 11, 12, 13, 17, 19, 20, 23, 24, 25.
2. M.-È. Sirois, Démystifier le BIM ouvert, Portail Constructo, 2019-10-29 (interview with three buildingSMART Canada representatives).
3. Construction Management (BIM+), To COBie or not to COBie – the client's conundrum, 2016-06-09.
4. Autodesk, Open an IFC File, Revit 2023 Help.
5. Forum Standaardisatie, Forumadvies toepassingsgebieden Geo-standaarden, SETU, WDO, VISI, IFC en COINS 2.0, FS-20190424.04A, 2019.
6. A. Hannell, COBie is already an outdated method of data management, Construction Management (BIM+), 2016-06-09.
7. J. Ford, The future of the IFC-COBie saga, Construction Management (BIM+), 2020-08-21.
8. Centre for Digital Built Britain, BIM Interoperability Expert Group Report: Public Consultation Summary, 2020-06.
9. A. Rawdin, A. Khudhair, H. Li, BIM and ISO 19650 implementation in the Welsh construction industry: a case study of bottom-up governance in a non-mandated region, ITcon, 2026, doi:10.36680/j.itcon.2026.021.
10. L. van Berlo, The curious case of the MVD, buildingSMART International blog, 2019-12-12.
11. F. Noardo, K. Arroyo Ohori, T. Krijnen, J. Stoter, An Inspection of IFC Models from Practice, Applied Sciences 11(5), 2232, 2021.
12. buildingSMART International, IFC 5 development repository, GitHub, README (viewed October 20, 2026).
13. Computer Integrated Construction Research Program, BIM Project Execution Planning Guide – Version 2.1, The Pennsylvania State University, 2011 (©2010), CC BY-SA 3.0 US, glossary.
14. UK BIM Framework, Information management according to BS EN ISO 19650 – Guidance Part 1: Concepts, 2nd edition, 2019, p. 14.
15. UK BIM Framework, Information management according to BS EN ISO 19650 – Guidance Part 2: Processes for Project Delivery, edition 4, 2020, p. 8.
16. J. Kirby, LinkedIn post on COBie and Asset Operations Handover, 2026-06-04, with a reply by B. East, 2026-06-05.
17. B. Succar, LinkedIn post on COBie and AOH, 2026-06-05.
18. M. Lazic, LinkedIn post on IFC exchanges, 2026-07-14, with replies by J. Stevanovic, Steven S., E. Björnhage and M. Tanna, 2026-07-14 and 15.
19. L. van Berlo, "Easier said than done: IFC should sell itself", LinkedIn, 2025-05-22, replies by I. Shtaer and M. Mekes.
20. buildingSMART International, LinkedIn post on the Tokyo 2026 summit, 2026-09-25, reply by S. Kovacs, 2026-10-04.
21. B. Schock, LinkedIn post on openBIM maturity, 2026-06-14.
22. D. Delgado Vendrell, The Evolution of IFC: The path to IFC5, buildingSMART Spain, 2024-12-03.
23. Revizto, What is IFC format? Exploring BIM and IFC models in detail, blog (viewed October 20, 2026).
24. Prairie Sky Consulting, Software, FAQ (viewed October 20, 2026).
25. B. East, Introducing the COBieQC2023 software, Prairie Sky Consulting, 2023-07-17.
26. VIMaec, VIM v1.0.0, format specification, GitHub.
27. VIMaec, vim-format and vim-web, GitHub; MIT licence as listed on GitHub and npm.
28. That Open Company, engine_fragment (Fragments), GitHub README; MIT licence per npm (@thatopen/fragments).
29. Speckle, speckle-server, GitHub README; Apache-2.0 per npm (@speckle/viewer).
30. W. Radaczyński, dotbim, GitHub README and licence.
31. Bentley Systems, iTwin.js, GitHub README; MIT licence per npm (@itwin/core-backend).
32. Alliance for OpenUSD, aousd.org (viewed October 20, 2026).
33. VIMaec, VIM object model (section on element ids) and object-model-schema.json (tables Element, ParameterDescriptor, Workset, Phase, DesignOption, View, MaterialInElement), GitHub (viewed October 20, 2026).
34. National Institute of Building Sciences, COBie Standard, NBIMS-US (version history; viewed October 20, 2026).
35. Federal Highway Administration, Advancing BIM for Infrastructure: National Strategic Roadmap, FHWA-HRT-21-064, June 2021, PDF pages 18 and 21.
36. Standards Council of Canada, CAN/CGSB/CSA-ISO 19650-2:24, 2024-11-30.
37. Metrolinx, Metrolinx Exchange Information Requirements (BIM), MX-ALM-GDC-003, June 2025, PDF page 18 (printed page 15).
38. Ministry of Land, Infrastructure, Transport and Tourism (MLIT), Japan, BIM図面審査 申請・審査マニュアル (BIM drawing review: application and review manual), first edition, March 24, 2026, PDF pages 3, 17, 31 and 86.
39. ISO, ISO 16739-1:2024, abstract (viewed October 20, 2026).
40. C. Cozzitorto, F. Jalaei, Y. Sultan, S. Davari, D. Bhonde, openBIM implementations for a Canadian roadmap, National Research Council Canada and buildingSMART Canada, 2024-03-01, PDF pages 30, 56, 114 and 121.
41. buildingSMART International, validate, README, section "Running Validation Checks", GitHub (viewed October 21, 2026).