Why two individually accurate BIM models can still land in completely the wrong place relative to each other the moment they're linked.
A structural engineer opens the architectural link, and the building appears half a mile away — rotated, floating below grade, nowhere near the structure. Both models are, individually, modeled correctly. Neither team made a modeling error. What's missing isn't accuracy — it's a shared coordinate systemtying the two files' separate, private origins together. Without one, "correct" is only ever correct relative to a model's own internal universe.
Every BIM model file has a project (internal) origin — a (0,0,0) point that gets established automatically the moment the file is created, typically at or near wherever the first geometry happened to be placed. That origin is essentially arbitrary, and it is private to that one file. A model can be modeled with total precision relative to its own internal origin — every wall, column and duct correctly positioned relative to that file's own coordinate system — while having zero inherent relationship to any other discipline's internal origin, or to real-world geographic coordinates. Shared coordinates are a different thing entirely: a common, agreed-upon coordinate system that every discipline's separate model — architectural, structural, civil/site, MEP — is deliberately aligned to, so that when the files are linked together for coordination, they land in the correct position relative to each other. Setting this up is a deliberate act: one model (often civil/site or architectural) acquires or publishes a shared coordinate system, typically tied to real-world survey data, and every other discipline then specifically acquires that same shared system when linking to it.
A model's internal origin is created automatically the moment the file starts — typically wherever the first geometry happened to land, or a software default. That's completely fine in isolation: every dimension, every column grid, every level in that file is measured relative to it, and the model can be flawless. The problem only appears the instant a second file enters the picture. Its internal origin was established independently, with no knowledge of the first file's origin, at file creation time, in a different session, by a different team. Linking the two files places them relative to whatever those two arbitrary origins happen to be — not relative to reality. Establishing shared coordinates means deliberately overriding that default: one model publishes a coordinate system tied to something external and stable, usually real-world survey data, and every other model acquires that exact same system. Once every file is referencing the same external anchor instead of its own private one, alignment stops being a coincidence and becomes guaranteed.
False, and it's one of the more disorienting coordination failures in BIM because neither model is actually wrong. Each file's geometry is accurate only relative to its own internal origin, and that origin has no inherent relationship to any other model's internal origin. Linking two models without a properly established shared coordinate system places them at whatever arbitrary relative position their two private origins happen to produce — which can leave two individually flawless models badly misaligned relative to each other. Establishing and correctly propagating shared coordinates across every discipline's model, early in the project, is a deliberate BIM execution planning step — not something that happens automatically just because each individual model was modeled correctly. Left to chance, or attempted only after substantial modeling has already happened in each file with its own independent origin, retrofitting shared coordinates onto already-diverged models is a real and often painful coordination fix.
Explains why every BIM model file has its own private, arbitrary internal origin, why that has no inherent relationship to any other discipline's model, and why linking models together only lands them in the correct real-world position relative to each other once every discipline has deliberately acquired the same shared coordinate system.
It's intuitive to assume that if each discipline's model is individually accurate, linking them together should just work — the geometry is correct, so the coordination should be correct too. That intuition skips over what "accurate" actually means for a single BIM file: accurate relative to that file's own internal origin, a (0,0,0) point established automatically at file creation, typically at or near wherever the first geometry happened to be placed. That origin is arbitrary and private to the file. It carries no information about any other file's origin, and none about real-world geographic position. Two models can each be flawless in isolation and still have no meaningful spatial relationship to each other.
Project (internal) origin is per-file, arbitrary, and private — it exists so that one model's own geometry, levels, and grids can be measured consistently relative to something, but it says nothing about how that file relates to any other file. Shared coordinates are a deliberately established, common coordinate system that multiple separate model files — architectural, structural, civil/site, MEP — are all aligned to, typically anchored to real-world survey data. The workflow is asymmetric: one model (often the civil/site or architectural model) acquires or publishes the shared coordinate system first, and every other discipline's model then specifically acquires that same published system when linking to it, rather than continuing to rely on its own internal origin for cross-model positioning. Once every file references the same shared system, linked models land in their correct real-world position relative to each other automatically — not because of luck, but because they're now all measured against the same external anchor.
This is exactly why establishing and propagating shared coordinates is a genuine BIM execution planning task, addressed early — before each discipline has done substantial independent modeling work against its own default internal origin. Retrofitting shared coordinates onto models that have already diverged, each with significant work built up relative to its own arbitrary origin, is a real and often painful fix: it can require re-acquiring coordinates, re-checking levels and grids, and re-validating anything dimensioned or annotated relative to the old internal origin. It's also a distinct problem from federation versus merging (which governs whether discipline files stay separate or get combined) — shared coordinates govern where those files sit in space relative to each other, regardless of how they're combined for coordination review.
Closely related but not identical. Revit specifically has an Internal Origin (fixed, invisible, established at file creation and never moved) and a Project Base Point (a visible, movable point most teams use as their practical local origin for levels, grids, and dimensioning). A Survey Point is what typically carries the acquired shared/real-world coordinates once a model has acquired them from another linked file or from surveyed data. "Project (internal) origin" in this explainer covers the general BIM concept that Revit splits into these more granular pieces; other platforms use different terminology for the same underlying idea.
Typically whichever model has the most authoritative claim to real-world position — usually the civil/site or survey model, since it's the one actually tied to surveyed ground coordinates. That model publishes the shared coordinate system, and every other discipline's model then acquires it when first linking to the site or architectural model, rather than each discipline trying to establish its own.
Each file has, by that point, built up levels, grids, dimensions and annotations relative to its own internal origin, developed independently and now effectively locked in by all the modeling work already done against it. Retrofitting shared coordinates means re-acquiring the correct system and then re-validating everything that was positioned relative to the old origin — a real coordination effort, not a quick settings change, which is why BIM execution plans call for establishing shared coordinates at project kickoff rather than after modeling is underway.
They're independent problems that both affect multi-discipline coordination. Federated vs. merged is about whether discipline files stay separate and independently owned, or get combined into one file. Shared coordinates vs. project origin is about where each of those files' geometry actually sits in space relative to the others. You can have perfectly federated models that are badly misaligned because shared coordinates were never set up, and you can (less commonly) have a merged file where coordinates were never reconciled before merging.
Check each file's coordinate acquisition status directly (in Revit, for example, via Manage Links > Coordinates, which shows whether a link is using shared, internal, or origin-to-origin positioning) rather than trusting a visual glance in a 3D view — models can appear roughly aligned by coincidence at one zoom level while still lacking a genuinely shared, survey-accurate coordinate system underneath.
Try our BIM, CAD & Digital Design Studio
More calculators, simulators, and guides for this discipline.