The Classification Wars: Why We Don't Need One System to Rule Them All—And How We Translate Instead

"We need better data standards in construction."

This refrain echoes across the industry with ritualistic regularity. Yet the construction sector faces a paradox: we have never had more standards for structuring our data—and we have never had more difficulty understanding each other across disciplines and project phases. We're drowning in acronyms: IFC, CCI, Uniclass, Table 6, Bim7AA.

Each time we attempt to solve this problem by inventing "the perfect system," we simply add another standard to the pile. But perhaps the problem isn't that we lack systems. Perhaps the problem is that we're trying to force a complex reality into a single, all-encompassing hierarchical structure.

At OpenCirc, we believe in a different path. We shouldn't build the "ultimate" system. We should build the infrastructure that makes it possible to translate between the systems that already exist.

Identity vs. Meaning: What Are We Actually Talking About?

Before we can solve the classification problem, we need to distinguish between two concepts that are often conflated: Unique Identification (for the machine) and Semantic Classification (for the human).

The machine navigates by ID

Machines don't care whether a wall is semantically called "Exterior_Wall_Concrete_300" or "Type_7B." They need unique, stable keys to retrieve objects across databases. This is about URIs and GUIDs—identifiers that remain constant regardless of whether you're viewing an object in a BIM model, a facility management system, or a demolition inventory thirty years later.

The human navigates by patterns

Humans need cognitive frameworks. Systems like CCI or Bim7AA give us logical strings we can read and understand: "This is a building element, it's load-bearing, and it's made of concrete." These classification codes are semantic shorthand that our brains can parse and remember.

The problem arises when we try to use one approach to solve the other's task—or when we believe that a type code can contain all knowledge about an object. The construction industry repeatedly attempts to make classification codes serve both functions simultaneously, creating systems that satisfy neither machines nor humans particularly well.

The Battle Over Worldviews: Granularity and Paradigms

The real "war" isn't fought at the code level, but at the paradigm level. Different actors see the same physical object in vastly different ways—and they need to. Take a window as an example:

The structural engineer sees an opening in the load-bearing structure
The facility manager sees a maintenance item with a replacement schedule
The manufacturer sees a product assembly with sub-components and supply chains
The LCA consultant sees quantities of glass and aluminum with embodied carbon
The building physics specialist sees thermal performance and air tightness

Each of these perspectives is legitimate. Each requires not just different labels but fundamentally different ways of breaking down the object.

The danger of the "totalitarian" system

The challenge from a circular perspective is what happens when you move between systems with different hierarchies. What if just the glazing unit needs replacement? How is this described if the facility management system only recognizes "a window" as one unit, while the procurement system needs specific part numbers for subcomponents?

This isn't theoretical—it plays out daily in renovation projects where existing documentation uses one classification system, designers specify using another, contractors order with a third, and facility managers must somehow reconcile all three. The friction creates data loss, specification errors, and prevents the granular material tracking that circular economy requires.

Large, all-encompassing classification systems attempt to be a "totalitarian project"—they define all the boxes in advance. But what happens to innovation if you can only bring a product to market if it fits into an existing box?

Consider mycelium-based insulation, cross-laminated timber with integrated phase-change materials, or bio-based concrete alternatives. These products don't fit cleanly into traditional hierarchies because they represent category innovations. The totalitarian system doesn't just struggle with current reality—it structurally disadvantages future innovation.

Why Standards Like ISO 19650 Don't Solve Everything

We often look to standardization for salvation. The DS/EN ISO 19650 series is an excellent framework for defining Level of Information Need—what information is required, when, by whom, and in what format.

But ISO 19650 doesn't define the "language" itself. It tells us we should specify requirements and exchange protocols, but it doesn't solve the problem that Consultant A uses CCI while Contractor B uses internal procurement codes, and the facility manager expects Uniclass. The standard essentially says "agree on what information you need," but provides no infrastructure for what happens when parties operate within incompatible semantic frameworks.

The case of ISO 19650-7 and the Digital Product Passport

An interesting example: the planned ISO 19650-7 was supposed to address product data, but the work was overtaken by regulatory reality. The EU's Digital Product Passport (DPP) under ESPR and CPR is now taking the lead. The EU recognized that product data can't be left to voluntary standards when it's foundational to circular economy policy—it must be regulated by law.

This reveals something important: when information interoperability becomes economically or politically critical, voluntary standards prove insufficient. Legal mandates become necessary.

But even with DPP mandates, we're left with the original challenge: How do we get the product passport to communicate with the building model when they follow different ontological structures? DPP uses product-centric classifications optimized for supply chain transparency. Building models use spatial hierarchies optimized for design coordination.

The solution isn't to force one framework to subsume the other—it's to build explicit translation mechanisms between them.

Infrastructure Over Hierarchy: The Translation Approach

This is where OpenCirc shifts strategy. We're not trying to create "The Classification System Above All Systems." Instead, OpenCirc functions as infrastructure for semantic interoperability across classification systems.

We provide the technical bridge that enables "Window Type A" in CCI to be understood as "Product ID 123" in a DPP, without data loss. Rather than designing the perfect "boundary object" that everyone agrees on, we focus on standardizing the methods for translation.

What translation infrastructure actually means

Translation isn't about replacing existing systems—it's about making them talk to each other. This means:

Machine-readable mappings between classification codes that capture not just equivalence but semantic differences—what information is preserved, what is lost, what context is needed.
Context-aware rules that recognize the same window needs different representations for design coordination, permit applications, LCA calculations, and maintenance planning.
Standardized properties that work regardless of classification system—thermal conductivity, embodied carbon, chemical composition—separated from hierarchical categories. This is where bSDD becomes critical infrastructure.
Lifecycle continuity so that when classifications change over a building's 50-70 year life, the connection to actual products and performance history is maintained.

The key insight: classification systems handle categorical organization, while property dictionaries provide standardized attributes. Keep them separate, and translation becomes manageable.

We Need Translation Strategies, Not More Boxes

We need to move away from the idea that we can describe the entire world in one hierarchy. It's reminiscent of when mathematicians believed they could describe all existence through pure logic—a project ultimately shown to be impossible by Gödel's incompleteness theorems.

The same limitation applies to construction classification. We cannot build a single hierarchy that captures all perspectives, all use cases, all innovation, and all future developments while remaining consistent and usable. The world is too complex and too dynamic.

But recognizing this impossibility is liberating. Once we stop chasing the totalitarian classification system, we can focus on what's actually achievable: standardized translation infrastructure that makes different systems mutually intelligible.

The economics of translation

Translation infrastructure creates value by reducing friction costs. Currently, every interface between different classification systems requires manual reconciliation—consultants creating translation tables, specifications listing codes from three systems, facility managers mapping procurement to maintenance databases.

This friction is economically significant. When drawings show one thing, procurement orders another, and as-built documentation records a third—not because of mistakes, but because classification systems evolved independently—costs compound throughout the project lifecycle.

Translation infrastructure makes the cost of using multiple systems approach zero. When translation becomes technically trivial, actors can choose the classification system that best serves their needs while maintaining seamless data exchange with partners using different systems. This creates network effects: the more actors adopt standardized translation protocols, the more valuable they become.

Building the Infrastructure for Semantic Exchange

The classification wars won't be resolved through consensus on a universal hierarchy. They'll be resolved through infrastructure that makes translation technically trivial and commercially advantageous.

At OpenCirc, we're not picking sides in debates over whether CCI, Uniclass, or Bim7AA is "better." We're building the interoperability layer—standardized templates, open data formats, machine-readable mappings—that makes classification exchange possible regardless of which system any actor prefers.

bSDD and the separation of concerns

The buildingSMART Data Dictionary (bSDD) is foundational to this strategy because it separates stable identification from evolving classification schemes. Your material passport can maintain consistent machine-readable properties even as classification codes change over time or vary across projects.

Denmark's Table 6 dictionary demonstrates this in practice. The LCA requirements from building regulations (BR18 Table 6) are now machine-readable and mapped to IFC 4x3. This means BIM models can unambiguously mark which components require LCA calculations, material passports can reference the same definitions, and when regulations update, the mappings can be versioned without breaking existing data.

This is translation infrastructure at work: not replacing existing systems, but making them interoperable.

OpenCirc as lifecycle infrastructure

But semantic interoperability alone isn't enough for circularity. DPP provides a snapshot at market entry. Building models provide design intent. Neither captures what happens over 50-70 years of operation.

OpenCirc captures product data at specification (from DPP), connects it to building context (from IFC models via bSDD), then continuously enriches it through operations and maintenance. Think of it as a "mason jar" for product data—preserving initial information while adding layers of operational history.

When that window needs maintenance in 2045, when that façade panel is considered for reuse in 2065, when deconstruction happens in 2080—the original classification codes have value only if connected to actual product data, performance history, current regulatory context, and circular economy potential.

We're building data stewardship, not just data exchange.

The Path Forward: Infrastructure Over Ideology

The construction industry doesn't need to agree on one classification system. Different disciplines, project phases, and regulatory contexts legitimately require different ways of organizing information.

What we need is infrastructure that acknowledges this plurality while making it manageable. Translation infrastructure means:

For manufacturers: Publish product data once with standardized properties, knowing it can be consumed by any system regardless of classification preferences.
For consultants: Automatic translation between the classification system you work in and whatever your clients, contractors, or regulators require.
For building owners: Material passports that maintain stable identities and accessible data throughout building lifecycles, even as classification systems evolve.
For authorities: Clear mappings between regulatory requirements and various classification systems in practice, making compliance verification automated.
For the industry: Reduced friction costs, faster innovation, and genuine interoperability without everyone abandoning existing workflows.

Want to Help Build the Bridges?

The classification wars are real, but they're also solvable—not through conquest but through infrastructure. OpenCirc is building that infrastructure: open-source, transparent, and designed to outlast any individual organization's proprietary interests.

If you work with BIM data, classification systems, product specifications, or circular economy initiatives—we need your perspective. Feel free to contact us and be part of defining how future data flows freely, regardless of which classification system it comes from.

The future isn't one system to rule them all. The future is infrastructure that makes all systems speak to each other.