Entity Resolution: The Missing Foundation of Building Intelligence

A floor plan says “A.101.” A room schedule says “Room 101.” A maintenance log calls the same unit “AHU-3,” and a damper schedule calls it “RTU-North.” None of these are wrong: they're the same physical world seen through different documents, written by different people at different times.

Deciding whether these are the same room, unit, or system is called entity resolution. It rarely gets discussed, but almost nothing downstream works without it.

The problem

Every building generates records continuously: design drawings, a BMS point list, a maintenance log, an energy audit, a spreadsheet of sensor exports. Each is created in isolation, by a different party, often years apart, with no shared naming convention. A 2025 review spanning 125 built-environment studies confirms this is systemic: fragmented data sources and limited interoperability are a recurring, unresolved barrier across the field.¹

A single asset can carry half a dozen labels. An air handling unit installed in 2008 might be “AHU-3” on the mechanical drawing, “RTU-North” in a 2015 maintenance contract, and only a serial number in a 2019 energy audit. A room might be “A.101” on one floor plan and “Room 101, Open Office” on a room schedule from a different consultant. [Illustrative examples, not a specific building or customer case.]

Almost every useful question requires linking records across documents: is the AHU with the highest fault count last year the one flagged for replacement in the retrofit audit? A facility manager who can't answer confidently ends up guessing. The problem hasn't been solved because it's never been anyone's job: each document producer followed their own convention correctly, and the mismatch only surfaces once someone tries to use the documents together.

Why current approaches fall short

The tools built to manage building data mostly assume identity is already settled, rather than solving for it. A BMS reads whatever tags were configured into its points database; it has no notion that “AHU-3” is the same unit as “RTU-North.” A BIM model solves identity beautifully, but only for itself: every IFC object carries a stable identifier, so elements within one model are never ambiguous, but the model drifts with every unrecorded renovation, with no way to connect its identifiers to names used elsewhere. Research on integrating BIM with GIS for pipeline asset management reaches the same conclusion: data standardization and cross-system integration remain open problems.² Even as BIM gets paired with IoT and machine learning, that pairing has grown up around the data rather than through resolving what any of it identifies.³

Digital twins typically assume reconciliation already happened upstream; disagreeing source records mean a duplicated or dropped asset. A 2025 study of digital twins spanning building-to-city scale found data heterogeneity to be a defining, largely unresolved characteristic, not an edge case.⁴ Manual reconciliation and one-time mapping tables between systems both work only until the person or system on the other end changes. None of these tools are broken at what they do. They simply weren't built to answer the question underneath all of them: are these two records describing the same real-world thing?

The core concept: entity resolution

Entity resolution is a well-established idea in data science: decades of use deduplicating customer records and reconciling addresses across government databases, resting on statistical foundations Fellegi and Sunter laid out in 1969⁵ and refined since.⁶ The built-environment literature rarely uses the term, even though the fragmentation described above is precisely that problem.

Applied to a building, entity resolution means taking every mention of every asset and deciding which refer to the same real-world zone, floor, AHU, pump, or door, then merging them into one canonical record with every discovered fact attached.

Without resolved identity, a knowledge graph is just a larger pile of disconnected fragments.

Entity resolution isn't “point an AI at your data.” It's approximate matching, confidence-aware decisions, and deterministic computation, each applied where it's actually reliable.

Why it matters

The payoff shows up everywhere downstream. Technicians get faster fault diagnosis: no time confirming that two labels are one machine. Metrics stop double-counting, since unmerged copies of one zone corrupt every “per zone” report built on them. Predictive maintenance gets a real history to learn from, and retrofit decisions get faster, since verifying an investment paid off means comparing the same asset across documents produced years apart.

A 2025 study on an elevator system found that resolving and unifying BIM, IoT, and maintenance data cut manual cross-domain queries from up to 97 minutes down to under 2.2 minutes, the same category of problem entity resolution solves at the level of individual building assets.⁹

Industry perspective

The building industry is converging on knowledge graphs faster than it's naming the identity problem underneath them. Ontologies like the Brick schema already supply the vocabulary for what a resolved entity is (room, AHU, meter) once it exists.¹⁰ A 2025 bibliometric analysis of 107 articles found an accelerating trajectory toward knowledge-graph adoption in facility management, driven largely by data fragmentation.¹¹ A 2025 framework integrating Industry Foundation Classes with knowledge graphs for deconstruction planning shows the pattern moving into practice.¹²

None of that literature names data identity as a distinct barrier; the framing stays at “fragmentation.” That's arguably the opportunity: entity resolution is the specific, addressable mechanism underneath what the field currently describes only in general terms.

Regulatory pressure adds urgency regardless of vocabulary. The EU's revised Energy Performance of Buildings Directive requires minimum energy performance standards for non-residential buildings by 2027,¹³ and the EU's Smart Readiness Indicator scores how well a building can act on its own data,¹⁴ both presuming a building's data can be reliably attributed to correctly identified assets.

How Struxiva applies these principles

Struxiva treats entity resolution as a standing process, not a one-time migration step. Every time a building's data changes, resolution re-runs across all completed extractions from scratch, so understanding improves as evidence arrives rather than freezing at whatever was true on day one.

Resolved entities are materialized directly into a Brick-classed knowledge graph, the shared foundation that fault detection, metrics, and predictive maintenance all reason over.

Key takeaways

• A single physical asset routinely appears under multiple names across a building's drawings, logs, and reports, none of them wrong, all of them incomplete on their own.
• Existing tools (BMS, BIM, dashboards, digital twins, point integrations) mostly assume identity is already resolved rather than solving for it.
• Entity resolution is the process of deciding which mentions across documents refer to the same real-world thing and merging them into one canonical record.
• Reliable entity resolution combines AI judgment for ambiguous matching with deterministic computation for anything that can be derived exactly, plus confidence scoring throughout.
• Fault detection, accurate metrics, predictive maintenance, and trustworthy digital twins all depend on resolved identity as a prerequisite, not an afterthought.

Evidence & references

Resolving identity answers what thing is this. It doesn't yet answer is this data actually plausible, the subject of the next article in this series: Semantic Validation. From there: Knowledge Graphs, Hybrid AI Architectures, Trusted AI for Buildings, and Conversational Building Intelligence.