A building's records are full of numbers that look fine and aren't. A room logged at “4,500 m²” that is really a 45 m² office. A chiller with a coefficient of performance of 12, when anything above roughly 6 is physically impossible. A supply-air temperature of “210 °C.” Each is a plausible-looking value in a well-formed field, a number sitting exactly where a number belongs. And each one is wrong: a shifted decimal, a swapped unit, a mis-read digit, a sensor stuck against its rail. Nothing in the data announces the error.
Deciding whether a value is not just well-formed but physically and contextually plausible, before any system trusts it, is called semantic validation. Once entity resolution has settled what a thing is, validation asks the next question: could what we claim to know about it actually be true? Every trustworthy conclusion downstream depends on the answer.
The problem
Every building accumulates values from two error-prone sources at once. Drawings, nameplates, audits, and spreadsheets are turned into structured data by people and, increasingly, by AI extraction. Either route can shift a decimal, drop a unit, or read “1.0” as “10.” Live feeds fail in their own ways: sensors drift out of calibration, stick, saturate at a range limit, or report in the wrong scale. Real building-automation data, studied directly, turns out to be riddled with inconsistencies and discontinuities rather than clean and continuous.1
What makes this dangerous is that the errors are silent. A wrong-but-well-formed value carries no flag. It is a number in a numeric field, indistinguishable from a correct one, so it flows downstream untouched, into a fault rule, a benchmark, a digital twin, a regulatory report, and corrupts whatever is built on it. As AI increasingly reasons on top of building data, this gets worse: a model handed an implausible input doesn't hesitate, it launders it into a confident, professional-looking conclusion. Research on AI-supported decisions in buildings finds their trustworthiness depends as much on the quality of the underlying data as on the sophistication of the model.2 The gap persists because plausibility has never been anyone's explicit job: every system validates the format of its own fields, none checks whether the values make physical sense together.
Why current approaches fall short
The tools that touch building data mostly check that a value is well-formed, not that it is believable.
A BMS raises an alarm when a configured point crosses a threshold, but only on live points it was set up to watch, one at a time, against static limits, with no notion of whether a reading is physically consistent with anything else and no reach into data from a document. Threshold-based detection also runs into a hard trade-off: tighten the limits and real events slip through; loosen them and genuine anomalies drown in false alarms.3 Schema and format validation, the checks in ordinary software and data pipelines, confirm only that a field holds the right type: a number where a number is expected, a date that parses. A room area of “4,500 m²” passes every one of those checks cleanly, because nothing about it is malformed; it is simply false.
BIM models validate geometry and clashes, not operational values: a nameplate airflow ten times too high raises no geometric conflict. Dashboards render whatever they are given; manual QA catches some errors, but only once, by hand, never at the cadence building data changes; digital twins assume their inputs were validated upstream. And the common fallback, hard-coded range checks, is context-blind: a floor area or supply temperature that is plausible for a data centre is absurd for a broom closet, and a single global rule cannot tell them apart.
None of these tools are broken at what they do. They simply weren't built to answer the question underneath all of them: given everything we know about this asset and this building, could this value actually be true?
The core concept: semantic validation
Data quality has a long, well-developed literature, and its central distinction is exactly the one buildings need. Syntactic validity asks whether data is well-formed: the right type, format, and structure. Semantic validity asks whether data is meaningful and accurate, whether it corresponds to something that could really be the case.4 Decades of work formalised the dimensions this rests on (accuracy, consistency, plausibility) and the techniques for checking them.5
Applied to a building, semantic validation means testing every value attached to a resolved entity against everything that constrains what it could plausibly be: the physics of the equipment, established engineering ranges, the other fields on the same entity, and independent records of the same thing. The output is a status with a confidence and a rationale, not a simple pass/fail, because the safe response to a suspicious value is to flag and quarantine it rather than silently delete data that might be real.
Each value on the left is syntactically perfect, a number in a numeric field. Semantic validation is the layer that decides whether it is believable, using constraints the value itself can't express.
Without it, a knowledge graph is just a tidy, well-organised store of confident mistakes.
How it works
Four layers, one verdict per value
Good semantic validation is a pipeline of complementary checks, each catching a class of error the others can't. It stays deterministic wherever a rule can decide, and calls on AI only where no fixed rule fits.
Unit & physical plausibility
Reconcile units first (°C vs °F, m² vs ft²), then test against engineering and physics bounds
Cross-field & cross-source consistency
Values checked against each other on one entity, and against independent records of the same asset
Ontology & constraint reasoning
Structural rules expressed formally over the graph and checked automatically, e.g. W3C SHACL6
Contextual AI judgment
For “in range but wrong here” cases no rule anticipates, an LLM flags it and explains why7
None of this reduces to asking an AI whether the data looks right. Semantic validation combines physical bounds, consistency and constraint checking, and contextual judgment, each applied where it is reliable and kept deterministic wherever a rule can decide. Every value leaves the pipeline with a status, a rationale, and a link to its source; suspect data is flagged and quarantined, never silently dropped.
Why it matters
The payoff is trust in every conclusion built on the data. Fault detection stops chasing phantoms: no technician is dispatched because a stuck sensor read 210 °C. Metrics become defensible, since one mis-scaled area silently distorts every per-square-metre figure derived from it. Predictive maintenance learns from a real operating history instead of artefacts, and retrofit measurement-and-verification means something, because before-and-after comparisons rest on values checked for plausibility rather than taken on faith.
The stakes are physical, not just clerical. When the data describing equipment is wrong, the building runs wrong, and every analysis inherits the error.8 Validation is what keeps that cost from propagating.
Industry perspective
The industry is racing to put AI on top of building data faster than it is securing the data underneath. The semantic-web community has matured formal validation; SHACL is a W3C standard for constraining and checking graph data6, and the data-quality field offers established dimensions and techniques to draw on.45 Applied work is now bringing this into the AEC toolchain: recent studies translate IFC/BIM rules into SHACL constraints to validate building data automatically.9 Digital-twin research, meanwhile, increasingly names data trust as an open problem: one systematic review found very few twins had undergone both verification and validation, with standard procedures largely missing.10
Regulation is converging on the same requirement. The EU's Artificial Intelligence Act makes data quality an explicit legal obligation for high-risk AI systems, requiring that their data be relevant, representative, and accurate, not merely assumed.11 In buildings, the revised Energy Performance of Buildings Directive and the Smart Readiness Indicator both presume a building's data can be reliably trusted and acted upon, which only holds if it has first been checked for plausibility.1213
As with identity, the field mostly frames this as “data quality” in general. Semantic validation is the specific, addressable mechanism underneath the slogan, and naming it is what turns a vague aspiration into something a system can be built to do.
How Struxiva applies these principles
Struxiva treats semantic validation as a standing layer between extraction and the knowledge graph, not a one-time cleanup. Every time a building's data changes, validation re-runs, so newly arrived evidence can confirm, correct, or challenge values that were accepted earlier rather than freezing whatever passed on day one.
Deterministic code owns what must be true; AI judges what looks plausible. Physical bounds, unit reconciliation, cross-field consistency, and formal graph constraints are computed exactly in auditable code: a COP above a physical ceiling or a zone area exceeding the building footprint is caught the same way every time. The “in range but wrong for this space” case that no fixed rule anticipates is where an AI agent adds judgment, always with a rationale traceable to the documents behind it. The system is deliberately conservative: suspect data is flagged and quarantined for review, never silently dropped.
Validated values are then materialised into the same Brick-classed knowledge graph that fault detection, metrics, and predictive maintenance all reason over, with the constraints expressed as checkable rules on the graph rather than ad-hoc scripts. This makes trust a property of the data infrastructure itself, so everything reasoning on top of it inherits data that has already earned it.
Key takeaways
- Well-formed data is not the same as correct data: a plausible-looking value can be physically impossible, and nothing in the data itself flags it.
- Existing tools (BMS alarms, schema and format checks, BIM, dashboards, digital twins) mostly validate that a value is well-formed, not that it is believable.
- Semantic validation is the process of deciding whether a value is physically and contextually plausible, given the physics of the equipment and everything else known about the entity and building.
- Reliable validation layers deterministic physical and constraint checks with AI contextual judgment, plus confidence scoring and provenance, flagging and quarantining suspect data rather than silently dropping it.
- Fault detection, trustworthy metrics, predictive maintenance, and credible digital twins all depend on validated data as a prerequisite, not an afterthought.
Evidence & references
Research & standards
- Babadi Soultanzadeh, M., et al. (2024). Data-driven fault detection and diagnosis in building automation, using real building-automation-system data characterised by inconsistencies and discontinuities. Energy and Buildings. doi.org/10.1016/j.enbuild.2024.114341
- Teoh, S. J., et al. (2026). Data quality as a determinant of trustworthy AI-supported sustainability decisions in buildings. Buildings, 16(7), Article 1462. doi.org/10.3390/buildings16071462
- Stjelja, D., et al. (2024). Anomaly detection in building energy data: the precision–recall / false-alarm trade-off in threshold-based methods. Energy and Buildings. doi.org/10.1016/j.enbuild.2024.114249
- Wang, R. Y., & Strong, D. M. (1996). “Beyond Accuracy: What Data Quality Means to Data Consumers.” Journal of Management Information Systems, 12(4), 5–33. doi.org/10.1080/07421222.1996.11518099
- Batini, C., & Scannapieco, M. (2016). Data and Information Quality: Dimensions, Principles and Techniques. Springer. doi.org/10.1007/978-3-319-24106-7
- W3C. Shapes Constraint Language (SHACL). W3C Recommendation, 20 July 2017. w3.org/TR/shacl
- Zhao, X., et al. (2025). LLM-based framework for anomaly/error detection in structured (tabular) data, with large F1 gains over baselines across benchmark datasets. Scientific Reports. doi.org/10.1038/s41598-025-88050-z
- Bie, H., et al. (2025). Impact of sensor faults on HVAC operation: economiser sensor failure raising peak cooling load by up to 81% and a stuck damper raising cooling energy by ~37%. Energy and Buildings, Article 115389. doi.org/10.1016/j.enbuild.2025.115389
- Wang, C., et al. (2024). Converting IFC WHERE rules into SHACL constraints to validate ifcOWL instance graphs for data integrity. Automation in Construction, Article 105293. doi.org/10.1016/j.autcon.2024.105293
- Bitencourt, J., et al. (2024). Systematic review of verification and validation of digital twins: very few twins undergo both V&V, and standard procedures are lacking. International Journal of Production Research. doi.org/10.1080/00207543.2025.2524516
Regulations & frameworks
- European Union. Regulation (EU) 2024/1689 (Artificial Intelligence Act), data governance and quality requirements for high-risk AI systems (Article 10). eur-lex.europa.eu: AI Act
- European Commission. Energy Performance of Buildings Directive (EU) 2024/1275. energy.ec.europa.eu: EPBD
- European Commission. Smart Readiness Indicator for Buildings. energy.ec.europa.eu: Smart Readiness Indicator
Entity resolution answered what thing is this; semantic validation answers is this fact worth trusting. Together they make individual facts reliable, but a building's intelligence lives in the relationships between those facts: which AHU serves which zone, which meter measures which system, how a fault in one place propagates to another. Turning a set of trustworthy facts into a structure you can reason over is the job of the next layer.
In future articles, we'll explore how technologies such as knowledge graphs, hybrid AI architectures, and digital twins build on resolved identity and validated data to create truly intelligent buildings.
Ready to see this in practice?
Talk to us about your building's data.