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.
Generative artificial intelligence, or generative AI, is one of my research fields, and it can learn only from data it is allowed to reach. Let me introduce myself, Dr Sepehr Abrishami, and the podcast, Reimagining AEC. Who may reach data, and who may withdraw that access, is the thread of this episode on interoperability.
In 2017 that thread led to the Technology and Construction Court. A contractor, Trant Engineering, was building a power station for the Ministry of Defence in the Falkland Islands. Its design consultant, Mott MacDonald, held the design data on servers the contractor reached with passwords. The two firms fell out over fees, and over whether a contract between them had ever been agreed. Mott MacDonald then revoked the contractor's passwords, and the contractor could no longer reach the design it needed to keep building. The case is on the public record as Trant Engineering against Mott MacDonald. How the court answered comes later, once the principles behind it are in place.
Losing access in a dispute is one form of a wider problem, and that problem is about time. So this episode asks one question. An owner will need information about its asset in twenty or thirty years. The question is what the technology holding that information must have done to keep it findable, trustworthy and usable by then.
My answer comes from a code of practice called Delivering Valuable Data, published in April 2023 by the Government and Industry Interoperability Group, or GIIG. The episode equips you to define interoperability as the code does and to explain why it was written and for whom. It also turns each of the code's five supporting principles into duties for the provider who builds a system and the client who buys it. I start with the problem the code set out to address, then take its central principle and the five that hold it in place. I finish with the ISO 19650 series, the international standards for information management published by the International Organization for Standardization, or ISO.
One owner serves as a test case throughout. Take a public hospital estate team at the end of a five-year contract with its information management provider. It must now move everything it holds to a new provider. The estate is hypothetical, set up for this episode alone, and each principle will change something about its move.
First, the problem. The code takes its definition from the GIIG's glossary of November 2022. Interoperability is the ability to exchange and use information securely, ensuring that information is independent of the technologies used to deliver it. Owners need their information to have four qualities for the whole life of each asset, known by their initials as FAIR: findable, accessible, interoperable and reusable.
The code calls poor interoperability a perennial issue and traces it to three roots. The industry is fragmented into silos and often adversarial. It focuses on short-term outputs rather than whole-life outcomes. And it has been slow to adopt digital ways of working. Time and cost are added at every stage of the life cycle, information loses its value, and most of the cost lands on owner-operators, which in the public sector means taxpayers. The code also cites a study from King's College London, published in 2016, in which 31 of 40 interviewees said interoperability was an issue. Eighteen of them were concerned about exporting and importing data through Industry Foundation Classes, or IFC, the open format for model data.
According to nima, formerly the UK BIM Alliance, with BIM standing for building information modelling, the first government-funded GIIG ran from April 2021 to March 2023. It now continues within nima. The code's acknowledgements record that the work was funded by the Department for Business, Energy and Industrial Strategy, now the Department for Business and Trade. A working group of sixteen drafted it, with four members from owner-operators, four from the supply chain and eight from technology providers. A draft went to public consultation in January and February 2023.
The order of its audiences is unusual. The code addresses the technology providers who build information management systems first. Owner-operators who procure asset information come second, and consultants and contractors in the supply chain third. Membership bodies, regulators and educators, universities among them, are named as well. I searched for a later version in October 2026 and found none. nima reports that the UK BIM Framework has been rebranded as the IMI Framework, named after the Information Management Initiative, and nima supports it with the British Standards Institution. The framework's resources page still lists this edition.
The code sets itself six objectives, and they fall into three pairs. The first pair is about exchange and policy. The governing aim is open exchange, so that recipients have full access to information held in other technologies, for immediate use and for later reuse. Its partner ties that aim to two government documents. One is the Construction Playbook, from the Cabinet Office in 2022. The other is the Transforming Infrastructure Performance Roadmap to 2030, from the Infrastructure and Projects Authority in 2021, usually called the TIP Roadmap. The roadmap asks clients for a digital way to define their information requirements, then procure, receive, assure and immutably store that information in a system of record. The second pair is about the reader. The code should relate interoperability to people's job roles, and it should be usable by technical and non-technical readers alike. The third pair widens the view, to better, aligned sector datasets that support modern methods of construction and off-site assembly, and to information integrated across whole lives and whole portfolios of assets. So the problem is old, the cost falls on owners, and the code speaks first to the people who build the software.
That brings us to the principle the code ranks highest. Information should be capable of secure exchange between two or more systems so that it can be used and managed. It should not be dependent on the technologies or services used to produce or process it. Notice the two halves, exchange that leaves information usable, and independence from the software that made it.
The code reminds us that interoperability has been an objective of the UK Government since 2011. Its focus is practical. Data should sit in non-proprietary formats, or in formats published as open standards. The same glossary sets three tests for an open standard. Its specification is publicly available, its drafting is open to all interested parties and reached by consensus, and its use is royalty-free. Government policy says the same in the Technology Code of Practice from the Central Digital and Data Office, last updated in 2021, whose fourth point is to make use of open standards. That office became part of the Government Digital Service in January 2025.
What the principle asks of a provider is easiest to follow as information moving between parties. It starts with creation. The code accepts that information is often created in proprietary software. The duty begins at exchange. When a supplier passes information to a contracting authority or to another supplier, it should be deliverable in an agreed non-proprietary form based on the FAIR qualities. The provider's products should support that exchange without loss, amendment, misinterpretation or additional work for users. Then comes receipt, which is the real test. The recipient should not need proprietary software to find, access or reuse what it receives. As a safeguard, records may be kept in both native and open forms wherever there is doubt.
For the hospital estate, this is the difference between two kinds of move. If its contractors delivered handover information this way, the move to a new provider starts from open files. If they did not, it starts from files that only the old software can read.
The code backs the principle with technical requirements, and two ideas govern them. The first is that information should live in open formats and schemas, because open relational schemas are inherently more persistent than proprietary files. IFC is the leading case. The code cites an earlier edition, but the current standard is ISO 16739-1 of 2024, which is IFC 4.3. The Construction Operations Building information exchange, or COBie, is named as a specific use of it. The same idea covers shared references. For unique property and street reference numbers, the code points to BS 7666-2, now in its 2020 edition, and the numbers are available as open data from Ordnance Survey. Dates and times follow ISO 8601, which the code cites in an earlier form and which is now ISO 8601-1 of 2019.
The second idea is machine access. Application programming interfaces, or APIs, let one system read another's information directly. The code points to government guidance on describing such interfaces, from the Government Digital Service and the Central Digital and Data Office, first published in 2019. That guidance recommends version 3 of the OpenAPI Specification. The code also asks for secure APIs that control which data is exposed and which users may reach it. The episode on open data, buildingSMART and COBie takes these schemas further. The core principle, then, comes down to one test. Whoever receives information must be able to use it without the software that created it.
Five further principles hold that test in place: longevity, security, ownership, value and competition. For each, the code states the principle, says what it means for technology providers, and lists technical requirements, some of which serve several principles at once. For clients, one remark matters most. The code expects these requirements to become a basis for assessing technologies during procurement. A client can turn each of them into a tender question.
Longevity comes first. Information should remain accessible and usable across an owner's systems for the whole life of the asset. That serves audit trails, regulators and provenance, which is the account of where information came from. Information will be reused for planned maintenance and also for unpredicted trigger events, a term from ISO 19650-3, the standard for the operational phase. The code also quotes the golden thread principles for higher-risk buildings, from the golden thread report of the Building Regulations Advisory Committee, published in 2021. They call for information that can be handed over and still be accessed in future.
Most of the longevity requirements concern the information container. In ISO 19650, a container is a named, persistent set of information that can be retrieved from a file, a system or an application's storage. The code sets several requirements for it, and they rest on three principles. The first is that nothing is overwritten. A container is held unchanged, and any change creates a new, separate record of provenance. That record keeps the source account, the time and the internet protocol, or IP, address of each submission. The second is that every container can be identified. It has a unique identity, fully defined metadata, and a timestamp in Coordinated Universal Time, and a container with undefined metadata is rejected. The third is that new software must still open older information.
Within that second principle, the system gives each container a sequential version number based on order of arrival. That is separate from the revision code set by whoever submits it. One more requirement recurs under four of the five principles. Information is segregated into named subsets, so that each user sees only what their security level allows. For the hospital estate, longevity means that the full history of every container moves to the new provider, and not just the latest file.
Security has two sides in this code. Information must be protected from unauthorised access, change or loss. Yet information that is not sensitive should still be shared for the public good. The method is holistic, built on a documented risk assessment that covers people, process, physical and technical security.
The client has a duty here. The TIP Roadmap requires clients to carry out the sensitivity assessment in clause 4 of ISO 19650-5 of 2020, the standard for a security-minded approach to information management. Where that assessment shows a security-minded approach is needed, the client implements it under clauses 5 to 9. The provider has duties too. A provider hosting information should hold Cyber Essentials Plus. It should also hold certification to the information security standard that ISO publishes with the International Electrotechnical Commission, or IEC, known as ISO and IEC 27001, whose current edition dates from 2022. The provider should confirm that every user, including its own staff, is authorised by the customer, and should support stronger authentication, such as multi-factor, where appropriate. The code points to the Centre for the Protection of National Infrastructure, whose responsibilities passed in March 2023 to the National Protective Security Authority. For the hospital estate, the new provider would need the same certifications, and every user would need the estate's authorisation afresh. So longevity keeps the record whole over time, and security decides who may see it.
Ownership is where the contractor's lost access belongs. The principle says that the owner-operator should procure, and specify in its contracts, that it keeps ownership and unrestricted direct control of its asset data for as long as it needs it. The code draws on the Rose Book, guidance on knowledge assets published in 2021 by HM Treasury and two partner bodies. It says organisations should keep direct control of their data in case a third-party data steward fails. Providers, in other words, are stewards and not owners.
Now the court's answer. Within weeks of the passwords being revoked, in an interim decision, the Technology and Construction Court ordered Mott MacDonald to restore access to the design data already produced, while the dispute over whether a contract existed was resolved. The contractor was ordered to pay four hundred and seventy-five thousand pounds into court in the meantime. The code cites the decision under its first ownership requirement. The parties were a contractor and its design consultant, not a software vendor and its client. The code still uses the case to show that access should not be withheld while a dispute is resolved.
The remaining ownership requirements follow one principle, that control stays with the owner before, during and after the service. During the service, providers respect the owner's hosting requirements. They also may not exploit the data. Without the owner's express permission, asset data may not feed new products or reach third parties. Nor may it be used for machine learning or AI, even when anonymised or aggregated, unless that use is part of the service. At the end, two contractual provisions apply. Under returnability, all information goes to the owner, or to its nominee, when the contract ends. Under non-retention, the provider keeps no copies, subject to its legal and insurance duties. For the hospital estate, those last two requirements turn its move into a contractual right, provided the estate wrote them into the original contract.
The last two principles concern value and competition. Information value means that what an owner procures and holds is treated as an asset, created and updated so that its value grows rather than depreciates. An owner can recognise and exploit that value only if it owns the information, which ties this principle to ownership. The code draws on lean construction thinking, where the aim is the right information, in the right format, for the right person, at the right time. Its examples of waste fall into two kinds. One is rework between formats, re-creating information in different proprietary formats or relying on unreliable export and import. The other is timing, with too much information too early or people waiting for information that arrives late. Software that supports open standards removes slow export, import and translation, and systems that let authorised users keep information current stop it going stale. The code adds that agreed lean processes should be recorded in the contract. For the hospital estate, value is lost the moment its staff have to re-key data the old system already held.
Competition asks for fair competition between technology providers, and between the businesses that use their tools. Vendor lock-in builds in a chain. Content is stored in proprietary formats that the vendor may keep secret. The author may own the copyright in what it produced, yet it cannot retrieve that information without the vendor's software, and high switching costs deepen that dependence. Partners on rival software are shut out, and proprietary software can even become a condition of appointment. In the end, owners may have to buy the software only to read data about their own assets. The code quotes the Digital, Data and Technology Playbook, from the Cabinet Office in 2022. It warns that data which is not interoperable can give incumbent suppliers a competitive advantage when contracts are re-procured.
That is the risk the hospital estate faces at the end of its contract. The code's answer is direct. Providers should discourage contracting authorities from mandating one proprietary product or environment. A client's information requirements should stipulate delivery in open, non-proprietary forms. Value and competition make the commercial case for everything before them.
Taken together, the six principles, the core principle and its five supports, show a pattern. The provider duties come straight from the code, and the client duties from the policy it quotes and the contract terms it recommends. Almost every provider duty becomes enforceable only when the client writes it into an information requirement, a tender question or a contract clause. The code itself describes returnability and non-retention as contractual provisions. The hospital estate shows why. If its first contract required open deliverables, preserved provenance, returnability and non-retention, the move follows an agreed procedure. Without those terms, the estate depends on the goodwill of the outgoing provider.
The code also draws on standards rather than replacing them. It notes that ISO 19650-1, in clause 6.1, says information exchanges should use open standards whenever possible, and that ISO 19650-2 repeats the point in clause 5.1.6. Revised drafts of both parts, and of Part 3, went to consultation in 2026, but the 2018 and 2020 editions remain in force, so check those clause numbers when new editions appear. The open data route runs through IFC, now ISO 16739-1 of 2024, and through COBie. In the UK, COBie is specified through the National Annex to ISO 19650-4 of 2022, the standard for information exchange, which replaced the withdrawn BS 1192-4. The security principle takes standard form in ISO 19650-5. And longevity is tested during operation, under ISO 19650-3, which the episode on information management in the operational phase covers.
The threads now come together. For information to serve an owner in twenty or thirty years, the technology holding it must have let that information be exchanged securely and used without the software that produced it. Five principles keep that true. Longevity preserves provenance and access over the asset's life, security protects what needs protecting, ownership keeps control with the owner, value removes waste, and competition prevents lock-in.
For your own work, the episode leaves three practical consequences. When you specify or buy a system, ask whether a recipient could use its output without the software that made it, because that is the code's central test. The provider carries the duties, but most of them bind only once a client writes them into requirements, tenders and contracts, and returnability and non-retention belong there before the first file is uploaded. And the code has no later edition, so read it beside the current standards, ISO 16739-1 of 2024 and the ISO 19650 parts in force. Start your reading with the code itself. The episodes on information requirements and on tendering and appointments show where its terms enter a contract.
Of everything in this episode of Reimagining AEC, the hospital estate's move is the case I would keep. I'm Dr Sepehr Abrishami, and when a contract for an information system next reaches you, whether through a client or through a thesis, I hope that move comes to mind.