HEM Open Source — Code, Repositories & Collaboration

Yes, the Home Energy Model (HEM) is fully open source. The entire codebase is published under the MIT Licence (Crown Copyright), making it freely available for anyone to inspect, audit, and build upon. There are two official implementations: a Python reference implementation maintained by BRE on Azure DevOps, and a Rust performance implementation maintained by MHCLG on GitHub. This represents a fundamental shift from SAP's closed specification document — for the first time, the UK's domestic energy calculation methodology is developed transparently, with the source code accessible to the entire industry.

MIT Licence & Crown Copyright

The HEM source code is released under the MIT Licence, one of the most permissive open-source licences in widespread use. The copyright holder is the Crown (Crown Copyright), reflecting HEM's status as a government-commissioned project developed by a consortium led by BRE (Building Research Establishment) and commissioned by DESNZ (Department for Energy Security and Net Zero).

The MIT Licence grants broad permissions. Anyone may:

• Use the code for any purpose, including commercial applications
• Copy and modify the code without restriction
• Distribute original or modified versions freely
• Sublicence the code within derivative works

The only requirement is that the original copyright notice and licence text are included in any copy or substantial portion of the software. This permissive approach means that software providers, academic researchers, building physicists, and anyone else in the industry can study exactly how every calculation is performed — right down to the individual lines of code.

Python Reference Implementation (BRE)

The Python implementation is the reference methodology for HEM. Maintained by BRE on Azure DevOps, it serves as the canonical definition of how each calculation module should behave. When questions arise about the intended behaviour of a specific calculation, the Python code is the authoritative source.

Role in HEM Development

BRE uses the Python implementation as the primary development environment for new features, bug fixes, and methodology refinements. This is where changes to the core calculation methodology are first implemented and validated before being translated into the Rust performance implementation. The Python codebase also serves as the basis for the detailed HEM technical papers (HEM-TP series) published on GOV.UK, which document each calculation module.

Code Structure

The Python codebase mirrors HEM's modular architecture. Each physical process — fabric heat loss, ventilation, thermal mass, solar gains, hot water, heating systems, and so on — is implemented as a separate module. This separation makes it straightforward to study individual calculation processes in isolation. Key structural characteristics include:

• Modular calculation modules — separate files for each HEM-TP paper topic (fabric, ventilation, thermal mass, solar gains, hot water, heat pumps, PV, controls, emitters)
• Core engine loop — the central simulation loop that iterates through 17,520 half-hourly timesteps per year, calling each module in sequence
• Policy wrappers — separate modules for the FHS wrapper and the emerging EPC wrapper, which apply context-specific rules on top of the core engine
• Input/output schemas — structured data definitions that specify the format for building descriptions, weather data, and calculation results
• Validation test suites — automated tests that verify each module against known reference cases

Python was chosen as the reference language because of its readability and widespread familiarity within the academic and building physics communities. The code is designed to be accessible to engineers and researchers who want to understand the methodology, not just software developers.

Rust Performance Implementation (MHCLG)

The Rust implementation is maintained by MHCLG on GitHub. It is a performance-optimised translation of the Python reference code, compiled to run at the speed required by the ECaaS cloud platform. While the Python reference prioritises readability and development agility, the Rust version prioritises execution speed and memory efficiency.

Powering ECaaS

ECaaS (Energy Calculation as a Service) is the cloud-based calculator run by MHCLG that provides the official HEM calculation for statutory purposes. The Rust implementation is the engine behind this platform. Each HEM calculation involves iterating through 17,520 half-hourly timesteps, executing multiple physics modules at each step — this is computationally intensive work that benefits enormously from Rust's compiled performance. The Rust implementation enables ECaaS to process thousands of concurrent calculations without prohibitive infrastructure costs.

Consistency with Python

The Rust implementation is translated from the Python reference, not independently developed. This means both implementations should produce identical results for identical inputs. MHCLG maintains a rigorous consistency testing regime to verify that the Rust and Python codebases remain in agreement as both evolve. When BRE updates the Python reference, the corresponding changes are translated into the Rust version to maintain parity.

The translation process follows a clear workflow: BRE implements and validates methodology changes in Python first, the changes are reviewed and documented, and then MHCLG's team translates them into Rust. This ensures that the reference methodology always leads, and the performance implementation follows.

Code Architecture Overview

Both implementations share the same fundamental architecture, reflecting the modular design principles described in the HEM technical documentation. The architecture separates the core building physics engine from policy-specific wrappers, and further separates the core engine into individual calculation modules.

Module Structure

Each physical process is encapsulated in its own calculation module, corresponding to a technical paper in the HEM-TP series:

• External conditions (HEM-TP-03) — weather data processing, sun position calculation, solar irradiance on surfaces
• Space heating and cooling demand (HEM-TP-04) — zone-level heat balance equations based on BS EN ISO 52016-1
• Fabric heat loss (HEM-TP-05) — U-values, thermal bridges, heat transfer through walls, floors, roofs, windows, and doors
• Ventilation and infiltration (HEM-TP-06) — pressure-driven model based on BS EN 16798-7
• Thermal mass (HEM-TP-07) — dynamic thermal storage in building fabric
• Solar gains (HEM-TP-08) — direct and diffuse radiation through glazing and fabric absorption
• Hot water (HEM-TP-09, HEM-TP-11) — individual tapping events, stratified cylinder modelling, pipework losses
• Heat pumps (HEM-TP-12) — variable COP modelling with source and sink temperature dependencies
• Heat emitters (HEM-TP-16) — radiator and underfloor heating performance
• Controls (HEM-TP-17) — heating controls and smart thermostat logic
• PV and battery storage (HEM-TP-18) — half-hourly generation, self-consumption, charge/discharge behaviour

Wrapper Architecture

Policy wrappers sit on top of the core engine and apply context-specific rules without modifying the underlying physics. The current wrappers are:

• FHS wrapper — applies the Future Homes Standard notional building specification, compliance metrics, and carbon emission factors for new-build compliance
• EPC wrapper (under development) — applies assumptions for Energy Performance Certificates, including reduced data methodology for existing homes

This wrapper architecture is one of the key design advantages of HEM. It means the core physics engine can be updated independently of policy assumptions, and new regulatory use cases can be added by creating new wrappers without altering the fundamental calculation methodology.

SAP Closed Model vs HEM Open-Source Model

The shift from SAP to HEM is not just a change in calculation methodology — it represents a fundamental change in how the UK's domestic energy assessment methodology is developed, maintained, and delivered. The comparison below highlights the key differences in development approach:

For a broader comparison of SAP and HEM methodologies, see our SAP vs HEM comparison. For a technical deep dive into the calculation differences, see the Technical Reference hub.

Industry Collaboration & Contributing

The government has made a clear commitment to collaborative development of HEM. The October 2025 consultation response revealed overwhelming industry appetite for engagement: of the 80 responses addressing open-source collaboration, 68 provided suggestions for how they wanted to contribute. This level of enthusiasm reflects the industry's recognition that an open, transparent methodology benefits everyone — assessors, software providers, manufacturers, researchers, and ultimately homeowners.

Collaboration Methods

The consultation identified several channels through which the industry can engage with HEM development:

• Workshops — focused sessions on specific calculation modules or implementation challenges
• Industry forums — broader discussion groups for strategy, priorities, and feedback
• Working groups — ongoing technical groups addressing specific areas such as heat pump modelling, ventilation, or product data
• Hackathons — intensive collaborative events to test, validate, or extend the codebase
• Manufacturer plug-ins — opportunities for product manufacturers to develop integrations that provide accurate product-specific data to HEM calculations
• Codebase contributions — direct contributions to the source code, including bug fixes, new features, and validation test cases
• Validation support — industry testing of HEM calculations against real-world building performance data

Show-and-Tell Sessions

The government began running show-and-tell sessions in July 2025, providing regular opportunities for the industry to see the latest development progress, ask questions, and provide feedback. These sessions are part of the government's commitment to developing HEM “in the open” and are open to a broad range of stakeholders, including energy assessors, software providers, building physicists, manufacturers, and researchers.

PCDB & Appendix Q Reform

Two important supporting systems are being revised alongside HEM to ensure they work effectively within the new open-source framework.

Product Characteristics Database (PCDB)

The PCDB stores product-specific performance data used in energy calculations — boiler efficiencies, heat pump COP curves, ventilation unit performance, and similar data. It has been a central part of the SAP ecosystem for years, and it is now being revised for HEM.

In the consultation response, 87 respondents commented on PCDB, with 54 agreeing that revision was needed. The industry has called for a streamlined product recognition process that makes it faster and easier for manufacturers to get their products listed. For assessors and architects, a well-maintained PCDB means more accurate product data available within the HEM calculation, reducing reliance on punitive default values.

Appendix Q Reform

Appendix Q is the process by which innovative technologies — those not yet covered by the standard calculation methodology — can be recognised and credited within energy assessments. Under SAP, this process was widely criticised as slow and opaque, discouraging innovation rather than supporting it.

The government is reforming the Appendix Q process for HEM. The modular architecture of the open-source codebase makes it inherently easier to integrate new technologies: a new calculation module can be developed, tested, and validated independently before being incorporated into the core engine. This modular approach, combined with the transparency of open-source development, should significantly reduce the time required for new technologies to be formally recognised.

Developing in the Open

The phrase “developing in the open” is more than a slogan — it represents a genuine shift in how the government approaches energy policy tools. Under SAP, the methodology was defined in a closed specification document. Software providers built their own implementations from this document, leading to inconsistencies between providers and limited opportunities for external review.

With HEM, the government has adopted an approach aligned with the Government Digital Service (GDS) principle of coding in the open. The benefits of this approach include:

• Transparency — anyone can see exactly how energy performance is calculated, eliminating “black box” concerns
• Accountability — calculation errors can be identified and reported by the entire community, not just the original developers
• Trust — assessors, architects, and developers can verify that the methodology works as intended
• Innovation — researchers and manufacturers can understand exactly how their technologies are modelled and propose improvements
• Education — students and professionals can study the code to understand building physics simulation in practice

This approach also supports the government's broader objectives for the Future Homes Standard. By making the calculation methodology transparent, the government aims to build industry confidence in the new regulatory framework and accelerate the transition to low-carbon homes.

Getting Started with the Code

Whether you are a software developer wanting to understand the calculation engine, an assessor wanting to verify how a specific module works, or a researcher wanting to study the methodology, the open-source codebases are accessible to you.

• Python (BRE, Azure DevOps) — start here if you want to understand the methodology. The Python code is the most readable and is the authoritative reference for how each module should behave
• Rust (MHCLG, GitHub) — start here if you are interested in the production implementation, ECaaS integration, or performance characteristics
• HEM technical papers — read the HEM-TP series alongside the code for a complete understanding of each module's methodology and the underlying international standards

For questions about the codebase, methodology, or collaboration opportunities, contact the HEM team at homeenergymodel@energysecurity.gov.uk.

Frequently Asked Questions

Related Pages