How to Read a Model Report

A model report should be read backwards from how most people read it: start with inputs, assumptions and limitations, and only then look at the headline result. The headline is the least informative part on its own, because it depends entirely on what went into the model. A report that hides inputs, that lists no assumptions, or that states no limitations should be treated with caution, however impressive its headline looks, because its result cannot be checked.

The input schedule is the report's foundation. It should list the building description used: dimensions, construction types, insulation, glazing, systems, controls and ventilation, with sources noted where inputs were observed, documented or defaulted. Read it against what you know about the home, and mark any input that surprises you, such as a heating system that does not match the installed one, or insulation recorded where none exists. Those marks are the starting points for questions, and a single major input error can matter more than any other part of the report.

Assumptions and method come next. The report should state the method used, its version, the standard occupancy and heating patterns where applicable, the weather data, and any modeller judgements. Check whether the method fits the purpose: a compliance method for a compliance question, an options model for an options question, a dynamic model for an overheating question. A method that does not fit the purpose produces a result that answers a different question, however carefully it is calculated.

Results should then be read as a breakdown, not as a single number. A good report shows where calculated heat goes, how each measure or scenario changes the result, and what the sensitivity is to uncertain inputs. A report that shows only a headline rating or saving, without a breakdown, gives the reader no way to understand why the result is what it is, or whether a different input would change it.

When reading, work through a checklist: inputs verified, method appropriate, assumptions stated, breakdown shown, sensitivity noted, limitations stated, recommendations tied to inputs. For each item, note whether the report passes, and where it fails, ask the modeller for the missing information before acting. A report that passes most items but fails on a major input still needs correction on that input, even if the rest is exemplary.

Also read recommendations critically. Recommendations should follow from the inputs and the breakdown, should be suitable for the building's fabric and ventilation, and should be costed or at least scoped separately from the energy model. A recommendation that does not follow from the breakdown, or that suits a generic home rather than this one, should be questioned, even where it appears in a polished report.

By place, report formats follow national methods and professional norms. UK SAP-based reports have a familiar structure tied to EPCs and compliance, while EU national-method reports follow their own formats under the EPBD framework. A reader should therefore judge a report against the format and method for its country and purpose, not against a generic template from another system.

For non-specialist readers, the most useful report feature is plain-language explanation alongside technical tables. A report that explains, in words, what drives the result, what is uncertain, and what should happen next is more usable than a report that presents tables without interpretation, however technically complete those tables are.

A common mistake is to read only the headline and the recommendations, and to act without checking inputs. That mistake turns a model report into a sales document, because the parts that would allow checking are skipped. Another mistake is to treat a long report as a good report, when length often reflects software output rather than evidence quality or clarity.

A further mistake is to accept a report's limitations section as a formality. Limitations that name specific uncertain inputs, method limits and scope exclusions are valuable information, and they should shape how much weight the result receives. A report with no limitations is claiming more than modelling can deliver.

Keep the report, your reading notes, any input corrections and correspondence with the modeller together. That annotated file is the useful version of the report, because it records what was checked, what was questioned and what was resolved.

Questions to ask the modeller include: which inputs drive this result, what are its main limitations, and what would change the conclusion. Those questions turn reading into checking.