Subscribe
Share
Share
Embed
Reimagining AEC is Dr Sepehr Abrishami's independent podcast on how the built environment handles information. Each episode takes one subject from digital construction, from the ISO 19650 series and the common data environment to the golden thread, soft landings and the arrival of artificial intelligence in design and surveying practice, and tells it as a single argument built on the published standards, guidance and evidence. Sepehr is a researcher and former architect who leads the Centre for AI in Construction and teaches building information modelling at master's level. The episodes are written for postgraduate students and practitioners who want the reasoning behind the rules, not a summary of them.
Data about a building often has to stay readable for longer than the software that produced it. Dr Sepehr Abrishami is the name on the PhD I completed in 2015, on building information modelling, or BIM, and artificial intelligence, and both fields depend on data of that kind. In this episode of Reimagining AEC, which I make without institutional backing, my question is how the information about a pump can outlast the software that modelled it.
The pump is fitted in a plant room this year. It may still be running long after the software used to model it has left the market. It is my own invention, with no real installation behind it. Through its working life, the people who maintain it will need its manufacturer, its location and its maintenance interval. If that data sits only in one application's native format, every look-up depends on a vendor that may have gone. Guidance Part B of the UK BIM Framework warns that reconfiguring data held that way can bring extra cost, lost quality and degradation. That guidance, written by Emma Hooper and Dan Rossiter and published in September 2020, is my main source here.
Put plainly, the question is how information about an asset stays readable and checkable for its whole life, whichever software each party uses. In May 2025, nima, formerly the UK BIM Alliance, announced that the UK BIM Framework had been renamed the IMI Framework, after the Information Management Initiative. Guidance Part B now sits among its archived documents, so I bring its points up to date as I go. Working through the question should equip you to make the case for open data from policy and from the standards. You should also be ready to say what six standards from buildingSMART International do and where they fit in ISO 19650-2, the standard for the delivery phase. Last, it should prepare you to specify COBie, the Construction Operations Building information exchange, correctly for a UK project today.
The argument runs in four steps: why open data matters, the six standards and where each stands now, their place in the delivery process of ISO 19650-2, and finally COBie, which carries our pump into operation.
Start with the case for open data. The guidance defines open data as data available or visible to others that anyone can freely use, re-use, re-publish and redistribute. Proprietary data is the contrast. It can be read only by specific software, so its future depends on that software's vendor. Information passes through many applications during design and construction, and the guidance is clear that the value lies in the information, while the software is merely a tool.
Archiving sharpens the point. Buildings and infrastructure are designed for long lives, and nothing guarantees that future software will open today's proprietary files. Our pump's maintenance data is safe for its whole life only if it is held in a form that does not need its original application. The guidance also observes that open data is more common than people assume. Files in portable document format, or PDF, and ordinary spreadsheets both count as open formats.
The policy behind this principle developed in four stages, each building on the last. In 2011, the UK Government's BIM Working Party strategy paper set out a hypothesis, which the guidance quotes. In its words, government as a client can derive significant improvements in cost, value and carbon performance through the use of open shareable asset information. In 2017, the National Infrastructure Commission's report Data for the Public Good cited an estimate that the direct economic benefits of UK public sector open data were 8.9 billion pounds in 2016. The last two stages turn the idea into a requirement. ISO 19650-1, clause six point one, sets out the principles of the information delivery cycle and states that information exchanges should use open standards whenever possible. The guidance notes that clause five point one point six of ISO 19650-2, and the UK National Annex to that standard, restate the point. Revised drafts of ISO 19650 Parts 1 and 2 went to UK public comment in March 2026, as nima reported, so check these clause numbers when the new editions appear. Until then the 2018 editions stay in force.
So the case rests on the long life of the asset, the cost of reconfiguring closed data, and a standard that asks for open exchange. For the pump, its data must arrive in open form.
Open formats need someone to maintain them, which brings in buildingSMART International. It describes itself as an open, neutral and international not-for-profit organisation. The guidance names five of its solutions, and I add a sixth. They fall into three groups by the job they do.
The first group defines what the information looks like. Industry foundation classes, or IFC, is the schema and file format that lets IFC datasets move between a wide range of software and databases. A model view definition, or MVD, filters IFC for one purpose. The guidance's example is a coordination view that reduces large models to the information needed for spatial coordination. The buildingSMART data dictionary, or bSDD, gives shared definitions of objects and their properties. With it, a property requested for our pump has one agreed name and one agreed data type.
The second group describes process and requirement. An information delivery manual, or IDM, documents a business process and the information it needs. The guidance suggests checking, reviewing and approving information as typical examples. The information delivery specification, or IDS, is the sixth standard. It expresses requirements in a form software can check. The third group carries the conversation about the model, and has one member. The BIM collaboration format, or BCF, carries issues from coordination, site inspection or snagging between applications, in place of a lengthy email chain.
Editions matter, because several of these have moved on since 2020. Three of the six rest on ISO standards, and all three now have newer editions. IFC four point three was published as ISO 16739-1 in 2024, replacing the 2018 edition that carried IFC four. buildingSMART describes its scope as road, railway, ports and waterways, bridges and the elements they share, so IFC is no longer a buildings-only schema. ISO 29481-1, the IDM methodology, was republished in November 2025. The bSDD follows the second edition of ISO 12006-3, published in 2022, and buildingSMART runs it as a free service that distributes dictionaries already developed by their publishers. The other two standards belong to buildingSMART itself. BCF has reached version three point zero, exchanged either as files or through a web service that connects applications directly. IDS version one point zero became a final standard in June 2024. The lesson is practical. Name the version and edition of each standard in your project's information standard, because software support differs between them.
The third step places these standards in the delivery process of ISO 19650-2. One caution first. The guidance uses the word could throughout, so treat what follows as options for a project, not obligations of the standard. Three terms recur. The appointing party is the client. A lead appointed party is an organisation the client appoints directly, such as a designer or a main contractor. Exchange information requirements set out what one party asks another to deliver.
At assessment and need, clause five point one, the guidance suggests structuring the project's information requirements with the IFC schema. They then become machine-interpretable and machine-testable. The project's information standard can name MVDs, and the guidance gives COBie two point four as its example of one. Methods and procedures can be written as IDMs. At invitation to tender, clause five point two, the appointing party's exchange information requirements can be structured the same way. Our pump's required properties, such as its manufacturer and maintenance interval, would be set out here and linked to bSDD definitions.
In the tender response, clause five point three, the delivery team, meaning a lead appointed party with the parties it appoints, prepares a pre-appointment BIM execution plan. That plan sets out how it proposes to manage information. Its federation strategy, which says how separate models are divided and combined, can use IFC classes. So can its high-level responsibility matrix, which records who produces which information. At appointment, clause five point four, the detailed responsibility matrix can add IFC property sets and bSDD properties. The lead appointed party's own exchange information requirements, set for the appointed parties beneath it, can be structured with IFC as well. During mobilisation, clause five point five, the delivery team can test its methods with MVDs and IDMs. In production, clause five point six, models are delivered as IFC datasets. If a clash arose around our pump, it would be raised in BCF.
Checking follows, and the guidance gives the same advice at four points. Two sit with the task team, the group that produces a given set of information. The task team carries out a quality assurance check. It then reviews the information and approves it for sharing in the common data environment, the agreed workflow and tools for sharing project information. The other two come at delivery of the information model. The lead appointed party reviews and authorises the model, and then the appointing party reviews and accepts it. At each point, the guidance suggests describing the review method as an IDM, a documented process. The IFC schema and IDMs could then support partial automation through rule-based checking against the relevant MVDs.
The word partial matters. Rules can confirm that every pump carries the required properties in the agreed format. They cannot judge whether the selected pump suits the system it serves. IDS now gives such rules a standard, computer-interpretable form. buildingSMART International stated in June 2024 that IDS lets users specify which data a model must contain and then verify whether it was delivered. It offers a computer-readable alternative to requirements held in spreadsheets and documents.
So requirements can be written for software to test, plans can borrow the same vocabulary, and delivered models can be checked against rules, while people judge what rules cannot. That brings the pump to handover.
The final step is COBie, where the guidance offers little. It carries COBie in its title, yet gives it a single line, as an example of an MVD, a filtered view of IFC. Its summary promised COBie guidance later, but the archived version is still Edition 1.
buildingSMART UK and Ireland, the national chapter of buildingSMART International, sets out the position on its COBie guidance page from 2024. It defines COBie as a filtered part of the IFC data model for operations and maintenance, with its own constraints and rules. COBie is a set of linked fields that together record the quantities, location and maintenance of equipment. It can exist in several file formats, but most people meet it as a spreadsheet. The chapter also stresses that COBie describes a project, not necessarily a building, which matters on infrastructure work. When COBie gained a UK code of practice in 2014, Construction Management magazine reported the benefits. They included collecting asset information during construction and sparing the owner from re-keying data at handover. For our pump, that means one record holding its type, its location in a space and its maintenance information, in a form the operator's systems can import.
The standard governing that record has changed. Begin with the history. BS 1192-4 was the UK code of practice for COBie, published by the British Standards Institution, or BSI, in September 2014. BSI withdrew it on 16 September 2022, and its catalogue lists it as withdrawn without naming a replacement. Four days later, BSI's launch article for BS EN ISO 19650-4 stated that the new standard, on information exchange, supersedes it.
Now the current position. Part 4 has a broader remit, covering all information exchanges, and does not address COBie itself. The COBie position sits in its UK National Annex, which, according to buildingSMART UK and Ireland, still specifies COBie two point four. The extra UK properties from BS 1192-4 are no longer listed, but can still be used when the exchange information requirements name them. In practice, the working tool is a template. The chapter publishes quarterly COBie templates that use Uniclass, the UK classification system for construction information. Since July 2025 those templates cover IFC two x three, IFC four and IFC four point three. One caution remains. COBie three point zero was developed for agencies and owners in the United States and has not been tested in the UK. The chapter advises appointing parties not to specify it unless they fully understand the impact and risk. For our pump, then, the exchange information requirements would name COBie two point four, the template release and the classification.
That draws the argument together, so I return to the question I opened with. A building's information outlasts its software when three conditions hold. It is kept in open formats, it is structured with open standards, and the requirements state clearly what must be delivered and in which version. The pump shows the chain. Its properties are requested with agreed bSDD names, delivered in IFC, checked against rules that IDS can express, and handed over as a COBie two point four record that the operator can import. The IMI Framework itself now points practitioners to buildingSMART International for IFC and to buildingSMART UK and Ireland for COBie, rather than to the archived guidance.
If you write requirements, make the request for open exchange explicit, as ISO 19650-1 asks for open standards whenever possible. Treat the buildingSMART standards as options that make requirements testable, remembering that rules check the data while people judge the design. On a UK project, specify COBie two point four under the UK National Annex to BS EN ISO 19650-4, name the template release and the classification, and treat BS 1192-4 as history. Leave COBie three point zero aside unless you fully understand its impact and risk. Above all, name the edition and version of every open standard you specify, and watch for the new editions of ISO 19650 Parts 1 and 2 now in preparation.
For reading, Guidance Part B by Hooper and Rossiter, 2020, is short enough to read in full. The COBie page of buildingSMART UK and Ireland is the most useful page to keep for practice. The episode on information requirements shows where requests such as the pump's begin, and the episode on information management in the operational phase follows a record after handover. The episode on interoperability and delivering valuable data takes the exchange question further.
I count myself, Dr Sepehr Abrishami, among those who ask what format a record is in before asking what it says, and I hope this episode of Reimagining AEC leaves you asking the same of the records in your own projects or research data.