How do you assess the quality of building operational data?

A fully populated dashboard proves only that numbers are arriving. Whether they are good enough depends on what you intend to do with them: a temperature trend that serves well for a monthly performance review may be useless for verifying a control sequence. Data quality, in other words, is not a single score but fitness for a stated purpose, and it has to be demonstrated with evidence along the whole path from sensor to application.

Five things to check

Frozen readings deserve particular suspicion. A sensor that reports the same value for days often looks perfectly healthy on a dashboard.

A right value in the wrong place

Context needs checking as carefully as the values themselves. A correct measurement attached to the wrong room or asset is often more misleading than a missing one, precisely because it looks credible. Semantic models such as Brick record what each point is and how it relates to equipment and spaces.

Whichever model you use, sample-check the mappings against the building itself. Walk the floor, compare a trend with a handheld reading, switch a unit and watch the right point change.

How a structured assessment runs

An assessment begins by stating the use case and the quality it needs, for example "daily energy reporting per floor, with no more than 2% missing intervals per month". It then takes a representative period, one that includes weekends, holidays and seasonal extremes, and runs automated checks for the five dimensions across every relevant point. A sample of points, mappings included, is spot-checked against reality. Defects go into a register, and the outcome is a plain verdict: fit, fit with stated exceptions, or not fit until defects are fixed.

Give every defect an owner

The register is what makes quality manageable. Each entry records the evidence, the impact on the use case, the cause and the party responsible. Causes fall into four broad groups. Instrument faults, such as a failed, drifted or badly located sensor, sit with the maintenance contractor. Collection failures in a gateway, the network or polling belong to the integrator or IT. Transformation errors, such as wrong scaling or unit conversion, belong to the platform supplier. Semantic errors in a mapping, name or relationship belong to whoever curates the model.

Separating causes in this way stops every problem being passed to the platform supplier, and lets each party be held to account. Thresholds should be set by use case, and unsuitable data must not slip silently into critical calculations: an energy report should show estimated or missing periods openly, not paper over them.

Quality does not end at handover

Buildings change. Sensors are replaced, spaces re-planned, controllers upgraded. Automated checks should run continuously, the defect register should be reviewed monthly, and spot checks should be repeated after any significant change. Quality assurance belongs in maintenance and service contracts, with named responsibilities.