BIM was a major advance for the construction industry. It made spaces and building elements addressable as objects, and it allowed multiple disciplines to be coordinated inside a single model. But not everything enters the model: a project's official calculations, its ground assumptions, its cost, its schedule, its approvals and its site changes largely live elsewhere. That is why the model can be perfectly current while the Excel calculation sheets, the reports and the bill of quantities still tell different truths.
The Work That Remains After the BIM Coordination Meeting
Suppose a design coordination meeting revises the basement levels and several structural members. The BIM model is updated and clash detection is run again. On screen the clashes are gone — but there is no guarantee that the geotechnical design parameters, the earth retaining calculation sheets, the structural review spreadsheets, the excavation quantities, the cost breakdown and the schedule have moved with them.
Each of these documents is managed by a different organization under a different scope of contract. The geotechnical investigation report belongs to a specialist firm, the structural analysis model to the structural engineer, the cost breakdown to the estimating team, the schedule to the site and planning staff. BIM is a powerful axis that connects them, but it cannot easily become the single original source for all of that data.
What BIM Does Well, and What It Does Not Do
BIM excels at structuring space and geometry and at making the relationships between structural and building services elements visually legible. It offers real advantages in quantity take-off, clash detection and propagating design changes through geometry. But there is neither a need nor a realistic path to close out every engineering calculation inside the model.
A soil's internal friction angle and cohesion look like ordinary object properties, yet in practice each value combines test results, stratigraphic interpretation, the designer's judgment, the governing standard and a conservative assumption. Structural member sections live in BIM, but the design loads, load combinations and nonlinear analysis conditions live in a separate analysis model. A finish material name may sit in the model while the substrate condition, applied thickness, waste factor, site productivity and approved samples are managed in entirely different systems.
As a result, the goal of "putting all information into BIM" tends over time to make the model heavier and accountability murkier. What is needed instead is a semantic layer that connects BIM with the other sources of record.
Making BIM the repository for everything
Connecting BIM as one strong source among several
When the Groundwater Level Moves by 0.8 Meters
Nothing illustrates the AEC data disconnect better than groundwater level. The borehole logs and the geotechnical investigation report record the level observed at the time of survey, and the designer then sets a design groundwater level that accounts for seasonal variation and surrounding conditions. The earth retaining sections, the foundation calculation sheets, the uplift check and the dewatering plan can each end up carrying a different figure.
Suppose the design groundwater level drops from EL. 12.5 m to EL. 11.7 m. A single number has changed, but the consequences are not simple. Effective stress and earth pressure, excavation stability, uplift and flotation, spread footing bearing capacity and settlement, liquefaction assessment, dewatering volume, cut-off methods, earthwork quantities and the schedule may all need to be revisited. Some items become safer; others become more onerous.
"Accountable Truths" Rather Than "a Single Truth"
In construction projects the phrase Single Source of Truth is appealing but misleading. The geometry of a structural member may be official in BIM, its member forces in the analysis model, its reinforcement in the structural drawings and detailed model, and its procurement quantity in the contract bill of quantities. Even within one object, different properties have different accountable sources.
A federated data backbone accepts that difference. For each property it designates a responsible system, an owning organization, an effective revision and an update cadence. When an inconsistency appears, the center does not arbitrarily pick a winner — it raises the difference as an issue and records how it was resolved. With that structure in place, collaboration shifts from arguing over "who is right" to the far clearer question of "which source is accountable for this property."
Three Approaches That Commonly Fail
The first is to load every file into a document search system and ask an AI. Retrieval gets faster, but the questions of which value is official and whether a calculation must be re-run remain unanswered. The second is to migrate all data into BIM properties. This works for quantities with simple relationships, but it cannot carry specialist calculations and approval context. The third is to redevelop the existing Excel estate as new web calculators in one sweep. Practitioners' exceptions and review habits get dropped along the way, and trust is easily lost.
The alternative is incremental connection. First identify files and objects, and structure inputs, outputs and evidence. Next, run the existing calculation sheets exactly as they are while feeding their values from the central data. Then accumulate change impact and review history, and finally convert the most repetitive calculations into web-native modules.
The Minimum Composition of an AEC Engineering Data Backbone
The common layer needs a handful of basic concepts rather than an elaborate schema: Project, Document, Revision, Object, Property, Unit, Formula, Rule, Evidence, Issue, Approval and Change Event. On top of that common kernel sit Domain Packs for geotechnical, structural, steelwork, finishes, interiors, MEP, cost and schedule.
Technically it requires connectors that parse BIM, CAD, PDF, Excel and analysis output; a graph that links objects to documents; a calculation layer that executes formulas and rules; an AI layer responsible for retrieval and explanation; and a control layer that manages versions, permissions and audit. But the first pilot should focus less on the technology stack and more on connecting one workflow end to end.
The Question After BIM Is "What Is It Connected To"
Adopting BIM taught the industry to see construction data as objects. The next task is to define how those objects connect to calculation sheets and standards, to cost and schedule, and to approval history. Geometry agreeing does not mean the project's judgments agree.
The next article examines what data philosophy is actually shared by disciplines that look far apart — geotechnical, structural, steelwork, finishes and interiors. Separating a common kernel from discipline-specific Domain Packs is what allows a platform to be both general and genuinely specialist.
doAZ Point of View
The next-generation AEC platform should not replace BIM; it should connect the calculations, documents, cost and schedule scattered around BIM. Designing "an accountable source per property, with traceable relationships" is more realistic than designing "one database."