For developers

This section is designed for engineers, architects, and technical teams looking to deploy, integrate, and contribute to the National Digital Twin Programme’s (NDTP) open-source ecosystem. All technical work is hosted on GitHub, with public repositories available for deployment.

🔗 Note: Some of the GitHub links referenced here point to repositories that are in the process of being made public. These resources are part of a wider open-source rollout taking place throughout April 2025. If you encounter a broken link or 404 page, please check back soon or visit the NDTP GitHub organisation to view currently available repositories.


Getting started

If you’re new to NDTP’s open-source ecosystem, start here:

What is the Integration Architecture (IA)? Learn about NDTP’s framework for secure, federated data-sharing.

🔗 Note: Some of the GitHub links referenced here point to repositories that are in the process of being made public. These resources are part of a wider open-source rollout taking place throughout April 2025. If you encounter a broken link or 404 page, please check back soon or visit the NDTP GitHub organisation to view currently available repositories.

The Integration Architecture is the overarching framework that defines how different nodes (IA Node and Management Node), Node Net, and ultimately the National Digital Twin interoperate. It lays out the principles, standards, and technical guidelines governing data sharing, security, and interoperability across all nodes and networks.

Deploying an IA Node? Here is a step-by-step guide.

🔗 Note: Some of the GitHub links referenced here point to repositories that are in the process of being made public. These resources are part of a wider open-source rollout taking place throughout April 2025. If you encounter a broken link or 404 page, please check back soon or visit the NDTP GitHub organisation to view currently available repositories.

You can deploy and configure an IA node across various environments including locally or to a cloud platform. The options for building and deploying an IA node include:

Although much of the detailed documentation currently focuses on AWS, additional documentation covering other cloud providers will be added soon.

Understanding the Information Exchange Standard (IES)

To enable seamless data sharing across digital twins, the Information Exchange Standard (IES) provides a structured approach to data interoperability. It ensures that information can be understood, trusted, and used consistently across systems, organisations, and sectors.

👉 Learn more at informationexchangestandard.org

Guidelines for code contributions, issue tracking, and pull requests.

🔗 Note: Some of the GitHub links referenced here point to repositories that are in the process of being made public. These resources are part of a wider open-source rollout taking place throughout April 2025. If you encounter a broken link or 404 page, please check back soon or visit the NDTP GitHub organisation to view currently available repositories.

🛠️ How to contribute

The National Digital Twin Programme (NDTP) welcomes collaboration on its open-source projects and documentation. While code contributions are currently limited to approved suppliers and partner organisations, there are still valuable ways the community can engage.

💡 Ways you can get involved

  • Report bugs or issues
    Found a problem or something that’s unclear? Open an issue in the repository so our team can review it.
  • Suggest improvements to the documentation
    Propose edits or additions to make our documentation clearer and more useful.
  • Provide structured feedback
    If you have suggestions that might help improve the platform, we’d love to hear them—particularly if they’re actionable or based on your experience.

🔐 For any security-related concerns, please do not submit a public issue. Follow our Responsible Disclosure process instead

🚫 Code contributions

At this time, we are not accepting public pull requests. Development is managed by NDTP-approved suppliers under formal agreements, ensuring alignment with programme goals and security standards.

Interested in seeing who has contributed?
Contribution activity is tracked on a repository-by-repository basis, rather than through a single acknowledgements page. Most repositories include an ACKNOWLEDGEMENTS.md file or make use of GitHub’s built-in contributors tab to highlight those involved. As the open-source ecosystem expands, additional repositories will be published under the NDTP GitHub organisation, each maintaining its own contribution record.

🔁 Our development process

NDTP follows a GitFlow-based branching model to manage contributions efficiently and maintain code quality across all repositories. This approach enables structured development, collaboration, and release planning.

Here is how branches are typically used:

  • main – The stable, production-ready branch. Only tested and approved changes are merged here.
  • develop – The active integration branch where new features and fixes are staged before release.
  • feature/* – Used for new functionality. Branches are named based on their purpose, e.g., feature/new-auth-method.
  • bugfix/* – For minor fixes and updates applied to the develop branch before release.
  • release/* – Created to prepare for a new version. Used for final testing, versioning, and documentation updates before merging into main.
  • hotfix/* – Reserved for urgent or critical fixes. These are applied directly to main and also merged back into develop to maintain consistency.

For more technical details, see the GitFlow workflow.

This model supports parallel workstreams, ensures cleaner history, and aligns with best practices for collaborative open-source development.

📜 Licensing

As part of its commitment to openness, transparency, and reusability, the NDTP publishes its code and documentation under widely recognised open-source licences.

  • Source code developed by or for NDTP is released under the Apache License 2.0, which allows for use, modification, and redistribution with minimal restrictions.
  • Documentation and supporting materials are made available under the Open Government Licence v3.0 (OGL), enabling broad reuse within and beyond the public sector.

This dual-licensing model ensures that NDTP resources are not only open and accessible but also aligned with public sector standards and long-term interoperability goals.


NDTP maintains a growing set of demonstrator open-source repositories:

NDTP demonstrators are used to test and validate real-world applications that consume, interact with, and depend on data made available through the Integration Architecture (IA). Each demonstrator involves standing up at least one IA Node to simulate how interoperable data can flow between systems and support decision-making at various organisational levels.

These demonstrators focus on:

  • Developing tools that consume data exposed by IA nodes
  • Testing the performance and usability of data-driven interfaces and visualisation layers under operational conditions
  • Validating technical patterns, including writeback, federation, filtering, attribute-based access control (ABAC), and multi-node orchestration
  • Exercising IA capabilities across diverse use cases like energy systems, emergency response, and planning for vulnerable populations

All demonstrators are designed to stress-test the integration points between external tooling and the IA—helping to inform development priorities, interface design, and patterns of interoperability.

Some demonstrators make source code or configuration assets available via NDTP’s GitHub organisation, giving developers practical examples of how to interface with IA nodes in live environments.

Demonstrators currently available:

IRIS – Retrofit decision support based on housing asset data.

🔗 Note: these links will take you directly to the official documentation hosted on GitHub.

IRIS is a modular demonstrator designed to support data-driven retrofit decision-making at scale. It allows users to visualise and interrogate domestic property data—including EPC ratings, material composition, and retrofit potential—via a browser-based interface. Under the hood, IRIS integrates multiple open-source components, all of which interact with one or more IA Nodes to fetch, process, and serve interoperable data.

Screenshot from IRIS- a visualisation of domestic properties on the Isle of Wight, showing EPC ratings and housing data in a 3D interactive map, powered by data from the Integration Architecture.

The IRIS stack is composed of four interrelated repositories:

IRIS Visualisation Frontend

This is the client-side application that users interact with. Built using Angular, it renders geospatial housing data, overlays EPC and material information, and provides interactive filtering and selection tools. Designed with performance and clarity in mind, it presents IA-fed data in a way that supports quick insight and decision-making.

IRIS API

The backend service for the visualisation layer. This Python-based API provides REST endpoints to read from and write to the IA Node, enabling dynamic queries and state changes. It also supports OpenAPI documentation and routes all visualisation data calls through a secure and scalable middleware layer.

IRIS Data Cleanser

An ETL pipeline that pulls raw data from public APIs (e.g. EPC and Ordnance Survey), cleans and transforms it using dbt, and stores it in a structured format (CSV in S3) ready for further processing. The pipeline is managed using Airbyte and is intended to be reproducible, modular, and extendable.

IRIS Data Pipeline

This repository contains two core data pipelines that transform energy performance and geographic datasets into RDF format aligned with the Information Exchange Standard (IES). Specifically, it uses IES:Building, a domain ontology developed through this demonstrator to represent data about the built environment—particularly energy performance characteristics.

The pipelines include:

  • An address profiling pipeline that ingests EPC assessment data and converts it to RDF using IES:Building concepts (e.g. insulation type, SAP ratings)
  • A lat-long pipeline that processes spatial identifiers (e.g. TOIDs, coordinates) for alignment with geospatial referencing

Both pipelines integrate with Kafka for ingestion and publishing, and are intended to serve as reference implementations for structured, interoperable data exchange using the IES framework.

L!SA – Incident management tooling for crisis coordination

🔗 Note: these links will take you directly to the official documentation hosted on GitHub.

L!SA (Local Incident Services Application) is a web-based application developed to support structured decision-making, secure information sharing, and real-time collaboration during emergency response scenarios. Built as a single open-source stack, it integrates both frontend and backend services, allowing teams to log incidents, coordinate actions, and interact with IA Nodes in real time.

The L!SA demonstrator was designed to validate how interoperable data from the Integration Architecture can support live crisis workflows, including incident logging, flagging of critical infrastructure, and multi-agency coordination.

The application is packaged in one repository:

L!SA – Full Stack Application

This repository contains the entire L!SA codebase—frontend UI, backend API, and a secure proxy layer to manage data exchange with the IA. Key features include:

  1. A React-based user interface for visualising incidents and managing updates
  2. REST API integration with IA Nodes to read and write incident-related data
  3. Support for structured logging, user roles, and real-time updates
  4. Dockerised architecture for rapid deployment in testing or live environments

All current demonstrator work has been conducted on the Isle of Wight, chosen as a bounded and representative microcosm of UK infrastructure and public service systems.


How can I contribute

The National Digital Twin Programme (NDTP) welcomes collaboration on its open-source projects and documentation. While code contributions are currently limited to approved suppliers and partner organisations, there are still valuable ways the community can engage.

💡 Ways you can get involved

  • Report bugs or issues
    Found a problem or something that’s unclear? Open an issue in the repository so our team can review it.
  • Suggest improvements to the documentation
    Propose edits or additions to make our documentation clearer and more useful.
  • Provide structured feedback
    If you have suggestions that might help improve the platform, we’d love to hear them—particularly if they’re actionable or based on your experience.

🔐 For any security-related concerns, please do not submit a public issue. Follow our Responsible Disclosure process instead.

🚫 Code contributions

At this time, we are not accepting public pull requests. Development is managed by NDTP-approved suppliers under formal agreements, ensuring alignment with programme goals and security standards.

Interested in seeing who has contributed?
Contribution activity is tracked on a repository-by-repository basis, rather than through a single acknowledgements page. Most repositories include an ACKNOWLEDGEMENTS.md file or make use of GitHub’s built-in contributors tab to highlight those involved. As the open-source ecosystem expands, additional repositories will be published under the NDTP GitHub organisation, each maintaining its own contribution record.

🔁 Our development process

NDTP follows a GitFlow-based branching model to manage contributions efficiently and maintain code quality across all repositories. This approach enables structured development, collaboration, and release planning.

Here is how branches are typically used:

  • main – The stable, production-ready branch. Only tested and approved changes are merged here.
  • develop – The active integration branch where new features and fixes are staged before release.
  • feature/* – Used for new functionality. Branches are named based on their purpose, e.g., feature/new-auth-method.
  • bugfix/* – For minor fixes and updates applied to the develop branch before release.
  • release/* – Created to prepare for a new version. Used for final testing, versioning, and documentation updates before merging into main.
  • hotfix/* – Reserved for urgent or critical fixes. These are applied directly to main and also merged back into develop to maintain consistency.

For more technical details, see the GitFlow workflow.

This model supports parallel workstreams, ensures cleaner history, and aligns with best practices for collaborative open-source development.

📜 Licensing

As part of its commitment to openness, transparency, and reusability, the NDTP publishes its code and documentation under widely recognised open-source licences.

  • Source code developed by or for NDTP is released under the Apache License 2.0, which allows for use, modification, and redistribution with minimal restrictions.
  • Documentation and supporting materials are made available under the Open Government Licence v3.0 (OGL), enabling broad reuse within and beyond the public sector.

This dual-licensing model ensures that NDTP resources are not only open and accessible but also aligned with public sector standards and long-term interoperability goals.


Support & Contact

If you’re working with NDTP tools, repositories, or demonstrators and need technical support or have questions, here’s how to get in touch:

📧 Developer Support: ndtp@businessandtrade.gov.uk
For general queries, feedback, or support requests related to NDTP codebases.

💬 GitHub Discussions: Coming soon
We are setting up a shared space for Q&A, technical discussion, and community input across NDTP repositories.

📚 Documentation:
Explore setup guides, APIs, and deployment notes in each GitHub repository’s README and linked documentation files.

For feedback or issues related to a specific repository, we recommend using the Issues tab directly within that GitHub repo.


Further Interest