EnergyPerformance.homes
The Hearth Record
Home / File 11 - Building energy modelling / Guide

Modelling Data Quality

What good modelling data looks like, where poor data usually creeps in, and how to improve a model's evidence base before relying on it.

Published 26 October 2026Evidence checked on 26 October 2026General homes; survey, documentary and monitored data discussed together

The short answer

A model is only as good as its data, and data quality varies in ways that a polished report can hide. Observed data, measured or seen during a survey, is generally strongest. Documentary data, such as plans, specifications and invoices, is strong where the documents match the home as it stands. Default data, taken from tables for a home type and age, is a reasonable fallback but not a measurement. Guessed data, entered without observation, document or method default, is the weakest kind, and a model that depends on guesses should say so.

Grading inputs by provenance is therefore the first data-quality step. For each major input, note whether it was observed, documented, defaulted or guessed. A model with mostly observed and documented inputs can support a confident decision; a model with several guessed major inputs can support only a provisional one, however detailed its outputs look. That grading, more than the software used, determines how much weight a result deserves.

What it means in practice

Survey data is where most quality problems start. Measurements may be rounded, rooms may be misclassified as heated or unheated, extensions may be missed, and construction may be inferred from a brief external look. Good survey practice records dimensions, photographs and notes that let a later reviewer retrace the surveyor's reasoning. Where a survey was brief, remote or based on old records, its data should be treated with correspondingly less confidence.

Documentary data has its own pitfalls. Plans may predate alterations, specifications may describe what was intended rather than what was installed, and invoices may cover only part of a job. Documents are evidence, not proof, and they gain weight when they agree with observation. Where documents and observation conflict, the conflict itself is informative and should be resolved, not smoothed over by choosing the more convenient source.

Checks before you act

Ask the modeller for a provenance note for major inputs, and check it against what you know. Were dimensions measured on site or taken from a plan. Was insulation observed, documented or assumed. Was the heating system identified from its data plate or from its general appearance. For any input graded as guessed, ask what evidence would upgrade it and whether that evidence is worth obtaining before deciding.

Also ask how the model handles missing data. A transparent model states its defaults and the reason for each one; an opaque model fills gaps silently. Missing data is normal in older homes, and the honest response is to flag it, test its sensitivity and, where it matters, obtain better data, not to pretend the gap does not exist.

How this differs by place

Data requirements differ by system and place. SAP assessments in the UK have defined evidence expectations for assessors, including what must be observed and what may be defaulted, while national methods in EU member states set their own evidence rules under the EPBD framework. Monitored data, from meters or sensors, is increasingly discussed as a complement to modelled data, but its use in official ratings is governed by national rules and is not uniform. A reader should not assume that monitored data can replace a standardised rating, or vice versa.

Record-keeping is part of data quality. A model whose inputs, sources and dates are filed together can be checked, updated and reused; a model that survives only as a headline rating cannot. Good practice therefore treats the input schedule and its evidence as the model, and the rating as its summary.

Mistakes that waste money or time

A common mistake is to equate a long report with good data. Length often reflects software output, not evidence quality, and a short report with clear provenance can be far more trustworthy. Another mistake is to update a model with new guesses when better data becomes available, for example entering a new wall assumption without checking the wall, instead of using the opportunity to observe or document it.

A further mistake is to discard old data entirely when a new model is made. Previous surveys, certificates and invoices, even where partly outdated, provide a baseline against which new inputs can be checked. A new input that contradicts an old one without explanation deserves a question, not silent acceptance.

Evidence to keep, and what to ask

Keep the input schedule, its provenance notes, survey photographs and supporting documents together, with dates. When a later professional revises the model, that bundle lets them build on evidence rather than repeating guesses.

Questions to ask include: for each major input, was it observed, documented, defaulted or guessed, which guesses matter most, and what evidence would replace them. Those questions improve a model faster than any software upgrade.

Sources and evidence on the record

Evidence basis: Educational guidance in general terms; data quality is discussed as a process, not as a guarantee of accuracy. Applies when: You suspect a model is built on weak data and want to strengthen it before deciding

Next on the file

File 11 - Building energy modelling Building Energy Modelling, Explained A plain-language introduction to building energy modelling: what a model calculates, what it leaves out, and how to read its results without treating them as a promise about one home. File 11 - Building energy modelling Model Inputs That Matter Most Which inputs move a building energy model most, from wall construction and window area to heating controls, and how to check the ones that deserve the most attention. File 11 - Building energy modelling Model Sensitivity Checks How sensitivity checks reveal which inputs a model result depends on, and how to run simple what-if tests before committing to work.