Why forensicBIM works with IFC

Summary

forensicBIM values model data in IFC because IFC is the only format that keeps the data readable for as long as the asset it describes. A building or bridge stays in use for decades. Model data that may become unreadable halfway through that period is hard to justify as an asset on the balance sheet.

Four things follow from that:

1. IFC is an open international standard (ISO 16739). Anyone can read it now, and anyone will be able to read it in thirty or fifty years, without permission from a software vendor.
2. IFC defines what the objects in the data are (a beam, a column, a bridge) and the rules for composing, georeferencing and aligning the data. Every computer interprets those definitions the same way.
3. Data in a proprietary format depends on one vendor continuing to support it. When that support ends, the data can lose all of its value overnight.
4. While the software is still supported, the owner has to keep paying for licences to use the data. That running cost lowers what the data is worth.

For an asset owner, choosing IFC is a long-term business decision about the data they pay for. forensicBIM's valuation is built around that decision.

What IFC is

IFC (Industry Foundation Classes) is an open data standard for describing built assets: buildings, bridges, roads, rail, tunnels and the systems inside them. It is maintained by buildingSMART International, a non-profit organisation, and published as ISO 16739.

An IFC file holds the same things a client cares about in a native model: the shape and position of every element, what each element is, its properties and classification, its quantities, and how elements relate to each other (which wall sits on which floor, which pump belongs to which system).

A native format such as a Revit, ArchiCAD or Tekla file is defined by the company that sells the software, and only that company decides how it can be read. The IFC specification is public. Anyone can read it and write software for it, and many applications already do.

IFC defines what the objects in the data are

Model data is only useful if a computer can tell what each object is. Once a computer knows that a shape is a load-bearing column on the third floor, in a specific concrete class, the column can be counted, priced, maintained and checked.

IFC contains hundreds of agreed definitions for the objects found in built assets, such as beam, column, wall, slab, door, pipe segment, pump, bridge, road, rail, alignment and many more. For each one, it also describes how to use it: which properties belong to it, which quantities can be attached, and how it relates to other objects.

It also includes rules for how the data as a whole is put together:

Computers can interpret all of these definitions and rules, and every program interprets them the same way. Any IFC application, from any vendor, today or in thirty years, knows that an IfcColumn is a column and where to find its properties. In a proprietary or home-grown structure, the same column may only be recognisable from a layer name, a family name or a label that made sense to the person who modelled it. Someone else, or another program, has to guess.

Shared definitions turn a model into information an owner can query, reuse, combine with other data and hand to the next contractor without explanation. That is a large part of what makes the data worth recognising as an asset.

IFC guarantees the data can be read in the future

IFC data stays readable because its definition is public and does not depend on any single company staying in business or keeping a product on the market.

This guarantee rests on three properties of the standard:

• The complete schema is published and freely available. If every current IFC application disappeared, a developer could still write a reader from the documentation alone.
• The usual IFC file format is plain text. It opens in an ordinary text editor, so even without specialist software a person can see the elements, names and property values in the file.
• Each IFC version stays published after a newer one appears. A file written in an older version can be read against its own specification decades later, and current tools still read versions that are more than fifteen years old.

For asset owners this matters because model data is useful long after the project ends. Infrastructure model data can have a useful life of up to 50 years. Maintenance, renovation, insurance claims, legal disputes and eventual demolition all draw on the same data, often long after the original design software has changed beyond recognition.

Proprietary formats can drop to zero value

Data in a proprietary format is only worth something while software exists that can open it. When the vendor stops supporting the format, the data can be worth nothing from that day on, however much it cost to produce.

This happens in ordinary ways:

1. The vendor releases new versions that no longer open files older than a certain age.
2. A product is discontinued, merged into another product, or the vendor is acquired.
3. The software only runs on operating systems or hardware that are no longer available.
4. The licence model changes, and the version that could open the files can no longer be bought or activated.

After any of these events the file still exists, but nobody can use it. An owner who wants the information back then has to rebuild it, which means paying again for work that was already paid for once.

Under IAS 36 and GASB Statement No. 42, an asset whose service potential has dropped has to be tested for impairment. Data that can no longer be opened has lost its service potential, so its carrying amount can fall to zero in a single reporting period. An owner who capitalised that data has to write it off.

Licence costs lower the value while the software still works

Even when a vendor still supports its format, proprietary data is worth less to the owner than the same data in IFC. To open, check or reuse the data, the owner needs a current licence, and that licence has to be renewed every year for as long as the data is in use.

Over the useful life of an asset that adds up. A subscription paid every year for twenty or fifty years is a cost tied directly to the data. Any sound valuation has to take it into account, because a buyer of the data would pay less for something that comes with a permanent bill.

The owner is also locked in. The vendor can raise prices, change the terms, or move features to a more expensive tier, and the owner has little choice but to accept.

IFC data can be opened with many applications, including free viewers and open-source tools. The owner can choose the cheapest tool that does the job today and switch when a better one appears.

IFC is what the owner receives and keeps

forensicBIM values the data an asset owner receives as part of the project and design costs. At handover, that data is usually delivered in IFC.

Native files tend to stay with the designers and contractors who made them. When an owner does receive them, they can only be used with the right software and licences, and often only by people trained in that one application. The IFC delivery is the version the owner controls, can share with any future contractor, and can archive without conditions.

That makes the IFC file the logical thing to recognise on the balance sheet. It is the data the owner actually holds and can keep using for the life of the asset.

Independence and comparability

A forensic audit has to be neutral. forensicBIM assesses data on a public standard that no software vendor owns, so the result does not favour any one product or ecosystem.

Using one standard also keeps results comparable. Two models made in different applications are judged against the same definitions, so an owner can compare projects, contractors and portfolios on equal terms. If each native format were assessed on its own terms, a score from one application would not mean the same thing as a score from another.

Public clients already ask for it

Government and public asset owners increasingly write IFC delivery into their contracts. They manage assets for decades, spend public money, and cannot make their records depend on one supplier.

In the Netherlands, IFC is on the government's list of open standards that public bodies must apply or explain why they did not. In the United States, transportation agencies have been working with buildingSMART on IFC for bridges and roads. The current version, IFC 4.3, covers infrastructure such as bridges, roads, rail, ports and alignments, and was published as an ISO standard in 2024.

When forensicBIM assesses IFC, it assesses the format these clients already require from their suppliers.

A long-term strategic business decision

Choosing IFC is a decision about what happens to the data over the next several decades. The software used to produce a model is a project decision that can change every few years. The format in which the owner keeps the data has to outlast all of those changes.

An owner who asks for IFC delivery and keeps it up to date gets:

• data that remains readable for the whole useful life of the asset;
• no fixed yearly licence cost to keep using the data;
• freedom to change software, contractors and service providers without losing information;
• a stronger case for recognising the data as an asset, because its future use does not depend on a third party;
• less risk of a sudden write-off when a vendor changes course.

An owner who relies on proprietary formats accepts the opposite: a recurring cost and a risk that the data loses its value at a moment the owner does not control. Over a useful life of twenty to fifty years, the chance that a vendor changes or drops a format keeps growing.

forensicBIM therefore treats IFC as the standard of record, and its valuation reflects data the owner can rely on for decades.

Limits, and what owners can do about them

IFC has three practical limits.

• A native model can contain information that does not make it into the IFC export, such as parametric design rules or software-specific settings. Most of that is useful to the designer rather than to the owner who operates the asset.
• The quality of an IFC file depends on how it was exported. Wrong export settings can leave out properties, classifications or relations that the native model did contain.
• Some owners only receive native files, because IFC delivery was not in the contract.

Owners can address all three in their contracts and handover process:

1. Require IFC delivery, and name the IFC version.
2. State which information must be in the file, for example with an Information Delivery Specification (IDS), the buildingSMART standard for writing down data requirements.
3. Check each delivery before accepting it, and send back files that do not meet the requirements.
4. For existing assets with only native files, ask the original supplier for an IFC export while the software to make one is still available.

Frequently asked questions