Here's a distributed systems problem you probably haven't thought about: dozens of independent teams, each editing their own piece of a shared 3D model, over a timeline of years, where a stale read can mean someone pours concrete based on the wrong version of a structural drawing.
That's the problem Building Information Modeling (BIM) has to solve, and the system that solves it is called a Common Data Environment, or CDE. It's worth understanding, because it's one of the cleaner real-world examples of a versioned, permissioned, multi-writer data system with the state machine spelled out as an actual international standard instead of left to whatever a team improvised.
Why plain file storage doesn't work here
A typical BIM project involves architects, structural engineers, MEP contractors, the client, and external consultants, all editing models that constantly reference each other. A structural engineer's model has to line up with the architect's, which has to line up with the electrical contractor's, across design, approval, and construction phases spanning years.
Dropbox or SharePoint can hold the files. What they can't answer natively is the question every contributor actually needs answered: is this specific revision of this specific file the one I'm allowed to build from right now, or is it still a draft someone's iterating on? Get that wrong on a construction site and the cost isn't a merge conflict, it's a physical rebuild.
The data model: containers, not files
The standard that governs this, ISO 19650, doesn't treat a file as just a file. It defines an "information container": a unit of data with mandatory structured metadata attached:
State: exactly one of four values at any time: Work in Progress, Shared, Published, or Archived
Status code (suitability): what the container is currently allowed to be used for, e.g. "for coordination" or "authorized for construction"
Revision: a tracked version number
Classification: a category code so containers can be filtered and queried systematically, usually against a scheme like Uniclass
The four states form a directed workflow, not just labels. A container in Work in Progress is visible only to the team producing it. Once it's stable enough for others to reference (but not yet final), it moves to Shared. Once it's contractually approved, it moves to Published. Transitions are meant to be one directional, with defined exceptions for rejection back to an earlier state.
If you've built approval workflows for a CMS or a PLM system, this pattern will look familiar: draft, review, publish, archive. What's different here is that the states, the metadata schema, and the transition rules are externally standardized, so a CDE built by one vendor and a CDE built by another are expected to expose the same conceptual model, even if the implementation differs.
The hard engineering problems
A few things make this genuinely nontrivial to build well, beyond just implementing a four-state enum:
Access control that depends on lifecycle state, not just role. A permission model here isn't "editor vs viewer." It's "this user can read this container, but only because it's in the Shared state, and only certain fields of its metadata, and that access should change automatically the moment the container moves to Published." That's state-dependent authorization, layered on top of normal role-based access, and it has to be enforced consistently across every client that touches the data.
Interoperability across authoring tools. Contributors use different BIM software (Revit, ArchiCAD, Civil 3D, and others), each with its own native file format. To avoid vendor lock-in on the authoring side, CDEs generally need to support IFC (Industry Foundation Classes), an open, schema-based exchange format that represents building elements as structured entities with relationships, not just geometry. Round-tripping data through IFC without losing information is its own hard problem, since different tools implement the schema with slightly different interpretations.
Multi-project isolation at scale. A CDE is rarely built for one project. It's typically operated as a platform serving many concurrent projects for the same organization, which means project spaces need to be cleanly isolated from each other while still sharing common infrastructure, user directories, and organizational permission structures. Get the isolation boundary wrong and you risk cross-project data leakage, which in a public infrastructure context is a real liability, not just a bug.
Auditability as a first-class requirement, not a feature. Every state transition and revision needs a traceable record: who moved it, when, and under what authorization. This isn't optional logging. In regulated or public-sector contexts, "who approved this exact version, and when" is often a contractual and legal requirement, which means the audit trail has to be tamper-evident, not just present.
Seeing the spec in the wild
If you want to see what a real-world requirement for one of these platforms actually looks like, Germany's state highway authority for North Rhine-Westphalia currently has an open tender for a cloud-based CDE, meant to support around 90 BIM projects over a four year framework. It's a useful read if you want to see how these architectural requirements (multi-tenant isolation, managed cloud delivery, structured functional evaluation) get translated into a concrete specification instead of staying abstract.
Further reading on the actual standard
The full specification is published by ISO (ISO 19650), and the open exchange format most CDEs are expected to support is documented by buildingSMART International, the organization that maintains IFC.
It's a niche corner of software, but the core problem, versioned, permissioned, auditable collaboration on structured data across many independent writers, is one a lot of us end up rebuilding in some form anyway, usually without a standards body telling us what the states are supposed to be called.
Top comments (1)
Great read!