Why Digital-Twin Mapping Checks Must Test the Whole Network

When matching words is not enough

A digital-twin ecosystem connects models that describe the world in different vocabularies. Building records, sensor systems and energy models may use similar terms with different meanings. Crosswalks specify relationships between those terms so information can be interpreted across systems.

In a preprint submitted on November 4, 2026, Fabio Rovai examines crosswalks around the Information Exchange Standard, or IES, a common framework developed for information exchange across government. The central finding is that mappings which pass logical checks separately can fail when loaded together. For these connected systems, the paper argues, the whole hub needs checking—not just its individual connections.

What the checks establish

The study uses ontologies: structured descriptions of categories, their relationships and, sometimes, rules about which categories cannot overlap. A crosswalk might assert that two categories are equivalent, that one is broader than another, or that they are merely related.

The pipeline separates automatic matching, human review, hierarchy-based certification, logical reasoning and publication of the mapping records. Review checks definitions and rejects misleading word matches. Certification compares class hierarchies and weakens claims those hierarchies do not support. A proposed equivalence can become a broader, narrower or related match rather than being deleted.

The HermiT reasoner then tests the combined ontologies. One criterion is coherence: the merge must not make previously usable categories logically impossible to populate. Another is conservativity: it must not introduce new subclass relationships between categories within an input ontology's own vocabulary.

That second test is deliberately bounded. It checks relationships between named classes, not every possible logical consequence. Passing therefore rules out the measured problems, rather than proving that a mapping preserves meaning in every respect.

Human and automated checks catch different failures

The evaluation covers thirteen IES-to-ontology pairs across seven sector groups, anchored on the building ontologies BOT, Brick and SAREF4BLDG. Twelve pairs have class-level overlap; the data-catalogue vocabulary DCAT has none.

Rovai compares raw mappings, automatically certified raw mappings, reviewed mappings, and mappings that receive both review and certification. Certification alone removes all 526 measured conservativity violations in the raw results. Review alone leaves 73. Together, the stages produce coherent and conservative merges for eleven of the twelve overlapping pairs.

They address different problems. A match between IES's general category Element and BOT's building-component category Element survives hierarchy checking but conflicts with BOT's rules separating components from spatial zones. Human review rejects this misleading name match.

HQDM remains the exception. It already has 39 unsatisfiable classes before mapping. An equivalence connecting IES Asset to an unsatisfiable HQDM asset class makes 52 IES classes unsatisfiable after certification. Removing that row resolves the newly introduced unsatisfiability, but the paper presents this as a diagnosis, not a successfully repaired result from the pipeline.

The failure visible only in the hub

Combining all three individually passing building crosswalks makes five Brick classes unsatisfiable. The problem is “Floor”: the IES building extension means a structural surface, while Brick means a building level, equivalent to Storey.

Neither IES nor Brick supplies the restriction needed to expose that error in their pairwise merge. BOT does: its rules separate building elements from spatial zones. Across the hub, those rules force Brick's floor-related classes into incompatible categories.

Rejecting the single Floor mapping produces a coherent and conservative building hub. It entails 290 subclass links between the target ontologies that were not explicitly written, including connections from Brick room types to broader space categories. These are logical consequences of the mappings, not independently reviewed correspondences.

The core hub has a different failure. The Open Energy Ontology and BFO 2020 are inconsistent together even without crosswalks. Excluding either yields a passing hub. The paper suggests a version mismatch but does not isolate the responsible axioms.

Useful evidence, not a correctness guarantee

Logical checks depend on what the source ontologies actually express. IES has no disjointness axioms, and some targets also lack them, leaving coherence checks little to contradict. A mapping can pass while still confusing concepts whose differences are not formally encoded.

Coverage is also limited. Many classes remain unmapped, and the building results concern a specific IES 4 revision with an extension—not IES 5. Five additional targets were unavailable as openly licensed OWL inputs in this run.

A separate small retrofit-planning extension adds 14 classes and 17 properties without introducing unsatisfiable classes under HermiT. That demonstrates a bounded extension exercise, not deployment-scale performance or retrofit outcomes.

The preprint's practical conclusion is narrower than universal interoperability: pairwise acceptance does not guarantee hub acceptance, and logical certification complements rather than replaces expert interpretation.