A building is not a book: collaboration and coordination in the age of granular data

In the Architecture, Engineering, and Construction (AEC) industry, we are currently trapped in a “digital translation” loop. We pride ourselves on digitalisation, yet our primary method of collaboration remains archaic: we throw static snapshots of data at one another and hope they stick.

We have spent the last two decades optimising the Single Source of Files. We name them Final_v2.ifc, upload them to a Common Data Environment (CDE), and wait for the progress bar to finish.

This distinction between a file and a database is not merely semantic. It is the root cause of massive inefficiency, data loss, and liability disputes. This article explores why the transition from file-based exchange to layered, granular data collaboration is not just a technical upgrade; it is an existential necessity for modern BIM related businesses.

Granular data refers to breaking down large, monolithic files (like a single 500MB building model) into their smallest individual components, such as a single wall location, a specific window geometry, and a property like “fire rating.”

Instead of transferring the entire container, systems can access, update, and track just these specific “grains” of information.

This is not new (bimserver.org did this in 2008 already); but the technology is getting easier to use by the day. But how we use it is important. This article explains.

We must dismantle the metaphor that a construction/design/engineering project is like writing a book, or a software code base. In a book (or software development), the goal is a single, cohesive manuscript where every word is final. Collaboration in that context means editing the same text to produce one single result.

A building, or any infrastructure asset is different. We are not collaborating on one single result; we are coordinating distinct, specialised systems.

The structural integrity is one system; the thermal envelope is another; the cost model is a third. These are not just ‘chapters’ of the same story: they are independent data streams that must intersect and align. When we treat a building (or infra assets) like a book, trying to force everyone into the same “Google Doc” or the same monolithic file, we destroy the independence required for specialised engineering. We don’t need everyone to write on the same page; we need a system that checks if the pages fit in the same binder.

For years, the industry chased the dream of a monolithic Master Model: a digital utopia where every discipline works simultaneously on the same object. The ‘single source of truth’. In practice, this is a myth, and trying to achieve it has caused more friction than flow. A building or infra asset is not a book.

A building or infra asset is a collection of professional contributions. Every specialist provides their contribution; their opinion on what a (property) value should be, based on their expertise and experience.

Consider a single concrete wall:

• The architect’s opinion/contribution: It is a spatial divider, defined by its finish, acoustic rating, and fire safety parameters.

• The structural engineer’s opinion/contribution: It is a load-bearing element, defined by its compressive strength (e.g., C30/37) and reinforcement schedule.

• The MEP engineer’s opinion/contribution: It is an obstacle that ducts must pass through or mount against.

• The contractor’s opinion/contribution: It is a poured volume requiring formwork, curing time, and labor cost.

In a file-based workflow, we often try to force these differing contributions into one geometry. If the architect moves the wall in their file, the engineer’s reinforcement data (hosted in their file) becomes orphaned. We spend hours in coordination meetings arguing over who “owns” the wall.

This friction is exacerbated by the lack of granular control. In traditional "work sharing," claiming ownership often means checking out entire "Worksets" or huge chunks of the model, effectively freezing progress for others. It forces a linear workflow in a dynamic environment; if the architect is working on the core, the structural engineer is often locked out of the columns within it, paralysed by a "Request to Edit" notification loop.

The future of collaboration lies in a composition structure that respects these opinions through layers.

Now we come to ‘granular data’. Systems can access, update, and track just specific “grains” of information. This allows for targeted updates without needing to process or lock the rest of the dataset.

In a granular data environment, we do not merge files; we overlay granular data in layers.

• The Architectural Layer contains the wall geometry and position.

• The Structural Layer contains the load-bearing capacity.

• The Construction Layer contains the schedule and cost data.

These layers exist in the same coordinate system and reference the same GUID (Global Unique Identifier), but they remain distinct data sets. This means the structural engineer cannot accidentally delete the architect’s wall; they can only flag a conflict on their own layer. It preserves the legal boundaries of liability while enabling real-time collaboration.

A layer can be any collection of data. The only restriction is that all data in the layer needs to be produced by the same author (or organisation; copyright holder). Beware: the ‘layers’ is not just a different name for a ‘file’. A layers is a collection (a set; selection) of objects from a database.

This concept of layering is not merely theoretical; it is the architecture of the future web and media standards. USD (Universal Scene Description), originally developed by Pixar and now embraced by NVIDIA’s Omniverse, is built entirely on a non-destructive layering system (although they still have a strong focus on files). In (open)USD, a final result is composed of (for example) the base asset layer, an animation layer, and a lighting layer; none of which permanently overwrite the others.

Crucially, while these layers are stored separately to preserve ownership, they are composed at runtime into a single, unified composition. The "Building Information Model" ceases to be a static file you download; instead, it becomes a temporary assembly of these various layers: a "view" generated on the fly. Just as a web browser composes text, images, and scripts from different servers into a single webpage, the modern CDE composes the Architectural, Structural, and MEP, and all other layers into a unified result. This composition allows the team to visualize the aggregate result; checking if the MEP ducts clash with the Structural beams; without ever changing the underlying source data.

The work on IFC 5 combines the best characteristics of (file based) USD, ISO standardised JSON, widely used ECS and the experience with IFC up until version 4.3. The granular data composition with layers is optimised for use-cases in the built asset industry.

In the old “locking” model, an engineer had to acquire ownership of a wall to move it. In the new opinion/contributions-based model, they simply submit a diverging opinion.

The system flags this difference during composition as a “value conflict.” Effectively, the Engineer’s opinion acts as a Change Request. The Architect then has two paths:

• Reject: The values remain divergent, and the “clash of opinions” persists in the composition.

• Accept: The Architect updates their layer to match the Engineer’s coordinates.

Crucially, the Architect does not “take” the Engineer’s wall; they align their own data. The result is two distinct opinions that now share the same value. Coordination is achieved not by overwriting, but by alignment. This dynamic process continues until consensus is reached, at which point the layers are frozen as a unified, coordinated deliverable.

If you are running an engineering firm, or any business that deals with BIM? Why should you invest in shifting to granular data workflows?

In a granular database, “he said, she said” disputes vanish. The database log provides an undeniable record of sequence.

Artificial Intelligence cannot easily “read” a static PDF or a complex geometry file without heavy preprocessing. AI thrives on structured data.

If your project data sits in a structured database, you can train algorithms to optimize layouts, predict costs, or analyse carbon footprints in real-time. You cannot do this effectively with a folder full of PDFs and IFCs.

The use of separate layers for each author or copyright holder protects your IP and your responsibilities. If you prefer you could even stream your data from the hosting location you choose to the composition. This was the data physically stays at the location you prefer to keep sovereignty guaranteed.

Granular data mimics the natural coordination of our industry far better than rigid file systems. By removing the administrative overhead of folder management and “locking” permissions, stakeholders can focus entirely on their core expertise. The architectural, structural, and MEP teams contribute their specific knowledge to the project simultaneously, without blocking one another. Coordination becomes an automated, background process of aligning layers, rather than a manual foreground task of managing files.

For the BIM business leader, the takeaway is clear: Stop optimising your file folders in your CDE. Plan for platforms that treat your building and infra assets as a composition of data, not a document.

The companies that master granular, transactional, and layered collaboration will operate faster, with lower risk, and will be the only ones ready for the next decade of digital construction.