1. Introduction
The Interoperability Blueprint provides business, organisational, and technical guidelines for building our own Local Digital Twin (LDT) and interconnecting with other LDTs. An LDT is a digital representation of physical assets, systems, or processes in a defined local context (for example, city, district, building, industry, port, and airport). LDTs are based on structured data models and contextualised data. They leverage either historical data, near real-time data, or real-time data, and they enable visualisation, analysis, simulation, and reasoning services that support decision-making. First, we will elaborate on why LDTs can be useful, followed by a high-level overview of an LDT. Next, we will explain the importance of being able to add new components to an LDT (Section 1.3) and discover existing components that can be added to an LDT (Section 1.4). Finally, we will discuss how this blueprint aligns with Minimum Interoperability Mechanisms (MIMs) Plus (Section 1.5) and how data spaces and LDTs are related (Section 1.6). The remainder of this deliverable is structured as follows:
-
Chapter 2: The business and organisational building blocks and the technical building blocks.
-
Chapter 3: The workflows an LDT should support.
-
Chapter 4: The technical architecture and the business and organisational overview.
-
Chapter 5: How the business and organisational architecture and technical architecture support the workflows.
-
Chapter 6: How to build an LDT based on the other chapters.
Although this blueprint mainly guides us through the process of building a new LDT with the focus on interoperability, we can also use its recommendations for updating an existing LDT and interlinking LDTs. The scope of the blueprint isn’t to offer guidelines for every use case in which an LDT is being built or has been built, as every LDT operates in a very specific context.
1.1. Why use an LDT
An LDT is a virtual replica of a territory based on structured data models, real-time data feeds, and potentially 3D representations, which can integrate simulation models (flows, usage, impacts, and so on). It aims to dynamically represent the territory at various spatial and temporal scales to analyse, understand, anticipate, and simulate the effects of public policies, environmental hazards, climate change, development projects or disruptions. The digital twin supports strategic decision-making, consultation, foresight, and scenario design. It can even include automated decision-making and execution. It can incorporate historical datasets, time-delayed data, Building Information Modelling (BIM), Geographic Information Systems (GIS), and/or specific models (mobility, climate, energy, and so on). LDTs can offer the following capabilities to users:
-
Descriptive: Current (and past) state of the real-world asset - static and dynamic. Bidirectional connection between real-world assets and the LDT.
-
Predictive: Extends the descriptive capability by providing predictions on the way the real asset could evolve in the future, using predictive models to envision possible futures.
-
Prospective: Conducts "what-if" analyses to evaluate the potential consequences of actions.
-
Prescriptive: Extends (or, in extreme cases, executes) the prospective capability with suggested actions on the real system to achieve a given objective based on the analysis.
-
Diagnostic: Explains situations or alerts about deviations from expected conditions. Capability for evaluating what happened, especially in the case of a malfunction of the real asset.
Note that we do not derive this definition of an LDT from a formal international standard. Instead, it is a project-specific conceptualisation influenced by existing frameworks such as Digital Twins, the EU LDT Toolbox, MIMs Plus 8 on Local Digital Twins, Smart City models, and Data Spaces. While relevant standards (for example, ISO 23247, ISO/IEC 30182, and ISO 30173) provide partial guidance, there is currently no universally accepted standard definition for LDTs in the context of urban or territorial systems.
1.2. High-level overview of an LDT
An LDT has three levels, Base, Core, and Surface (see Figure 1), representing a logical data pipeline from raw data ingestion to end-user interaction, as proposed in Deliverable 3.8:
-
LDT Base contains the foundational connection to the territory through sensor data (for example, IoT), modelled assets (for example, BIM), other external information (for example, socio-economic data or from external systems) and potentially even actuators such as APIs. This level uses the component Data Sources.
-
LDT Core contains the technical components that enable data exchange, contextualisation, and transformation into usable digital representations. This level uses the components Data Acquisition, Data Management, and Connectivity.
-
LDT Surface contains the analysis components, visualisations, and supporting human-interaction tools for decision-making within a service. This level uses the components Connectivity, Analysis, Visualisations, and Decision-Making.
We describe each component below:
-
Data Sources (grey) comprise the sources of information describing the territory, including physical sensors, administrative systems, external datasets, and modelling frameworks such as BIM or simulation models. These sources include those accessible through (local) data spaces. A data space is an interoperable framework for data exchange, based on common governance principles, standards, practices and enabling services, that enables trusted data transactions between participants.
-
Data Acquisition (green) collects data from sources (arrows 1a and 1b in Figure 1) and prepares it for use through ingestion pipelines, syntactic transformations, quality checks, buffering, and staging mechanisms, ensuring data is available, reliable, and ready for contextualisation.
-
Connectivity (orange) enables secure and interoperable data exchange across components and LDTs through interfaces, connectors, access control mechanisms, and federation services that support controlled sharing and discovery.
-
Data Management (purple) manages the representation, linking, and persistence of contextual information coming from the Data acquisition component (arrow 2 in Figure 1) through ontologies, data models, and data management services that support semantic alignment and the storage of historical or evolving states.
-
Analysis (yellow) provides analytical, simulation, and AI capabilities that augment data coming from the Data Management component (arrow 3 in Figure 1). These augmentations include insights, predictions, and inferences, including algorithms for pattern detection, forecasting, optimisation, and decision support.
-
Visualisations (blue) provide dashboards, spatial and temporal views, and interactive interfaces that enable end-users to explore, interpret, and interact with he outputs of services and analyses within an LDT (arrows 4 and 6a in Figure 1).
-
Decision-Making (red) provides supporting tools for planning, participation channels, and notifications (arrows 5 and 6b in Figure 1).
A Service is not a standalone component itself, but consists of a logical composition of the analysis, visualisations, and decision-making tools. A single service may include multiple visualisations, while individual components (for example, visualisations or analysis modules) can be reused across multiple services. A Service represents a higher-level abstraction that delivers value to end-users by orchestrating multiple underlying components.
1.3. Adding a new Surface-level component to an existing LDT, reusing Core and Base-level components
Once we have built an LDT, it’s important that we can still add new Surface-level components (SLCs) to ensure that new needs, coming from new and updated use cases, can be fulfilled (see Figure 2). While adding new SLCs, we want to
-
keep the LDT’s architecture/design as is,
-
keep support for existing components, if desirable,
-
limit the changes to these existing components, and
-
limit the effects on other components if existing components need to be replaced.
Each SLC might have specific requirements regarding different aspects, including, but not limited to
-
data models,
-
data exchange types,
-
provenance, traceability, and observability,
-
access and usage policies,
-
which party deploys and maintains the component, and
-
regulatory compliance.
Our LDT might not meet these requirements out of the box, but the LDT’s design should limit the necessary changes to business, organisational, and technical aspects to fulfil these requirements. Some examples of new SLCs are
-
energy consumption prediction of buildings,
-
air pollution and urban heat island maps, and
-
traffic congestion or flooding prediction and corresponding impact analysis.
1.4. Discovering which Surface-level components work on which existing LDTs and exchanging components through interconnected LDTs
While § 1.3 Adding a new Surface-level component to an existing LDT, reusing Core and Base-level components focuses on integrating a selected Surface-level component (SLC) into an existing LDT, interoperability should also support an earlier step: identifying which SLCs are suitable candidates in the first place. As increasing numbers of SLCs are developed by cities, service providers, and research initiatives, ideally, LDTs should be able to discover which of these components are compatible with their existing Base and Core-level components, and what adaptations would be required where full compatibility is not available (see Figure 3).
This is important because testing and deploying a new SLC can be costly in terms of time, effort, and governance. Before starting integration work, an LDT should therefore be able to assess whether a candidate SLC is likely to work with its available data, interfaces, policies, and organisational conditions. Such an assessment may consider, for example, the data models used, supported data exchange types, provenance and observability requirements, access and usage policies, and deployment responsibilities. Rather than repeating the full integration process for every candidate, the LDT should be able to compare its existing capabilities with the requirements published by the SLC and determine whether the component is
-
compatible out of the box,
-
compatible with limited adaptations, or
-
not currently compatible.
This discoverability is especially valuable in interconnected LDT ecosystems, where components developed in one context may be reused in another. For example, air pollution or urban heat island visualisations developed for one city could be reused by other cities if those LDTs can determine that the required data and interfaces are available. Similarly, AI models for traffic congestion prediction and impact analysis may be useful beyond the city in which they were originally developed, provided that other LDTs can assess whether their data, policies, and deployment conditions are sufficient to support them.
At the same time, discoverability is not only beneficial for city-to-city reuse. It can also support the emergence of an ecosystem in which external service providers offer new capabilities to existing LDTs. If an LDT describes the requirements, interfaces, and policies of SLCs in a consistent and machine-readable way, providers can develop reusable components that are easier to adopt across multiple LDTs. Additionally, LDT operators can more easily identify which offerings match their needs and constraints. In this way, interoperability helps create the conditions for a broader market of reusable LDT services and components, reducing duplication of effort and accelerating innovation.
By enabling this kind of discovery and compatibility assessment, the LDT reduces the cost and uncertainty of experimentation, supports both public-sector reuse and market-based innovation, and strengthens interoperability across interconnected LDTs.
1.5. Alignment with MIMs Plus
The MIMs Plus emerged as part of the Living-in.EU movement to enable a minimal but sufficient level of interoperability of data, systems, and services, particularly in the context of smart city solutions. By facilitating this minimum level, MIMs Plus contributes to the development of a coherent global market and collaboration focused on solutions, services, and data. They are not closed standards, but evolving recommendations, co-developed with local and regional authorities and interested stakeholders, and aligned with European frameworks.
Each of the 9 MIMs identifies an area in which interoperable mechanisms need to be put in place. At the time of publication of this deliverable, the MIMs Plus' framework is at version 8 and distinguishes between two main categories: foundational MIMs, which provide essential functionality for data interoperability within a city’s data ecosystem; application-specific MIMs, which will enhance the functionality of the data ecosystem by introducing interoperability in specific application areas. For this deliverable, it is important to highlight the application-based MIM8 - Local Digital Twin. MIM8 describes the following 6 layers:
-
Layer 1: Data acquisition (historic/near real-time/real-time data), including sensing, extraction, and synthetic data generation.
-
Layer 2: Connectivity, including APIs, protocols, and file sharing.
-
Layer 3: Data pre-processing, including semantics, interoperability, and aggregation.
-
Layer 4: Analysis and simulation, including AI Models and physics-based simulations.
-
Layer 5: Communication of results (visualisation), including dashboards, multi-dimensional visualisations, natural language interfaces (like chatbots), and virtual reality.
-
Layer 6: Decision-making, including prescription, support, and automation.
Layer 1 (Data acquisition) aligns with the Data Acquisition component of our high-level overview of an LDT; layer 2 (Connectivity) with the Connectivity and Data Management component; layer 3 (Data pre-processing) with the Data acquisition and Data Management components; layer 4 (Analysis and simulation) with the Analysis component, which includes simulation; layer 5 (Communication of results) with the Visualisation component; and layer 6 (Decision-making) with the Visualisations (support), Analysis (automation), and Decision-Making (prescription, support) components (see Figure 4).
Next to defining the typical layers of an LDT, MIM8 provides more details on an LDT’s capabilities: LDTs are able to share data with other data ecosystems, LDTs are able to share services, and LDTs are able to share SLCs. Moreover, other MIMs, notably the Foundational MIMs, provide interoperability mechanisms dealing with Accessing Data (MIM0), which aligns with the Data Acquisition component; Interlinking Data (MIM1) and Representing Data (MIM2), which align with the Data Acquisition and Data Management components; Sharing Data (MIM3) and Securing Data (MIM6), which align with the Data Management and Connectivity component.
1.6. Relationship between data spaces and LDTs
An LDT can participate in a data space and may assume multiple roles, including both data consumer and data provider. As a data consumer, an LDT can access data sources through a trusted and governed ecosystem (see Figure 5). This allows the LDT to ingest primary data, such as IoT data streams, from multiple organisations and territories, thereby extending its reach beyond the systems directly operated within its own local context. In addition, an LDT can obtain more elaborate data products through a data space, including outputs generated by external systems and services. These may enrich the LDT’s own simulations, predictions, and analyses. In this sense, a data space is not only a mechanism for exchanging raw data, but also an enabler for building more complex systems by combining the outputs of multiple services in a governed way.
As a data provider, an LDT can also expose part of its own outputs to other participants in the data space. Although the outputs of an LDT are intrinsically linked to the territory with which it is associated, this does not mean that they are useful only within that single LDT. Several LDTs may cover the same territory while focusing on different dimensions of it, and these perspectives are not mutually exclusive. Therefore, the outputs of one LDT may become valuable inputs for another. In particular, LDTs can share analysis results, predictions, simulations, and derived datasets through a data space so that other systems can reuse them under agreed governance and usage conditions. For example, one LDT may focus on traffic and provide traffic predictions, simulations, and analysis tools for a given territory. Another LDT covering the same territory may focus on environmental quality and use those traffic results as input to estimate emissions or air-quality impacts. This LDT could then combine these results with additional variables, such as industrial emissions, weather forecasts, wind behaviour, street topology, and the presence of green areas, to obtain a more comprehensive understanding of pollutant propagation and absorption. In this way, a data space can support the composition of complementary LDT capabilities across systems. From a practical perspective, current data space technologies can provide several capabilities that are relevant for LDTs:
-
Trusted and governed data sharing. Data spaces provide a framework for secure and policy-based exchange of data and data products between participants.
-
Compute-to-Data. This makes it possible to generate value from data while keeping the data at its source. Instead of transferring sensitive or restricted datasets, computation is brought to the data, and only the agreed results are shared.
-
Access to data services and APIs. Data spaces may expose not only datasets, but also data services and operational capabilities, such as APIs, processing services, simulation services, or other reusable components that can be invoked by LDTs.
-
Discovery of data and services. Through mechanisms such as catalogues, registries, or marketplaces, data spaces can support the discovery of relevant datasets, services, and offerings that may be integrated into an LDT.
Figure 6 illustrates how LDTs can reuse the Surface-level components of another LDT. In doing so, these components may use the same data or different data obtained through the data space, depending on the needs and context of each LDT.
Overall, the relationship between LDTs and data spaces is bidirectional. Data spaces can strengthen LDTs by providing governed access to external data and services, while LDTs can contribute back valuable derived data products and capabilities. This makes data spaces a key interoperability mechanism for connecting LDTs with broader digital ecosystems.
2. LDT building blocks based on DSSC & DS4SSCC-DEP building blocks
Building on the fact that LDTs can act as data consumers and data providers in data space ecosystems (§ 1.6 Relationship between data spaces and LDTs), this blueprint proposes to reuse the DSSC & DS4SSCC-DEP Blueprints and their building blocks to a certain extent (see Figure 7). The DSSC Blueprint defines a set of business, organisational, and technical building blocks, which need to be implemented in the context of data spaces. The application of each of these building blocks in the context of smart cities and communities was refined in the DS4SSCC-DEP project. Here, relevant implementations for each building block were identified. In LDT4SSC, these refined and detailed building blocks are then applied to the context of interconnected local digital twins. Again, practical implementations are identified, and new, LDT-specific building blocks are added.
In § 2.1 Business and organisational building blocks and § 2.2 Technical building blocks, we list the business and organisational building blocks and the technical building blocks, respectively. The blocks' summaries are altered to fit LDTs, instead of data spaces. For their full descriptions, we refer to the DSSC Blueprint v3 (released in March 2026) and DS4SSCC-DEP Blueprint (published in Sept 2025). In the case of a new business and organisational building block, we add a more detailed description referring to available academic and grey literature. In case of a new technical building block, we refer to § 4.2 Technical architecture and § 6.2 Define and implement. If the LDT is part of a data space, we need to take into account the building blocks on both the levels of the LDT and the data space.
2.1. Business and organisational building blocks
An essential part of LDTs' interoperability is the business and organisational aspects that define the purpose, organisational context (including involved stakeholders and their roles), incentives, rules and processes for designing, deploying, and operating LDTs. This section explains which business and organisational building blocks are important for either building LDTs or interconnecting LDTs. Figure 8 provides a visual overview of these building blocks in four pillars: business, governance, legal and design.
The Business pillar of LDTs frames the context for value creation, value capture and feasibility for sustaining the LDT beyond initial testing and piloting. This pillar of building blocks explores how to identify stakeholder incentives and structure data and service offerings. At its core, the business model should address the motives and strategic objectives of relevant stakeholders, ensure their alignment with offered data and services, foster multi-stakeholder data cooperations, and be sustainable in the long-run. This pillar includes the following blocks:
-
Business Model: This building block provides insight into establishing the value creation and value capture mechanisms, alongside other related business model elements (such as cost structures, revenue streams, funding models, public-private collaboration challenges...), for both the LDT Base and Core (for example, if based on a data space), and the central use case(s) the LDT enables.
-
Use Case Development: This building block shows how to identify, refine, implement and improve a use case.
-
LDT Services as Data Space Offerings: Whereas in data spaces, both data, data products and services are considered as data space offerings, in the context of LDTs, this building block emphasises the offering of LDT services from a business perspective and provides a strategy to develop and maintain them. More details in the DSSC blueprint v3, section Data Space Offerings.
-
Intermediaries and Operators: Intermediaries and operators may have a significant role in fostering data exchange among (data space) participants, providing essential functionalities, as well as value-added services. In multi-actor environments, intermediaries may also foster interoperability, with diverse technical and non-technical implementations.
In addition, the Governance pillar ensures that the operating model of a single LDT or its interconnection with other LDTs is aligned with its core purpose. It sets clear roles and responsibilities, rules, and processes, among others, to ensure trust among engaged stakeholders and beneficiaries, foster clear and transparent decision-making, and support operational compliance with relevant regulations and requirements. This pillar includes the following building blocks:
-
Organisational Form and Governance Authority: In case the LDT Base and Core are built on multi-stakeholder data cooperations, clarifying its organisational form (either as incorporated or unincorporated) may be useful. This building block provides guidance on the various types of entities stakeholders may establish, emphasises the governance authority (for example, setting the rules of the chosen data cooperation, defining the governance framework, ensuring compliance, and resolving conflicts, thereby fostering trust and data quality).
-
Participation Management: In case the LDT Base and Core require the participation of multiple actors, this building block helps to clarify how to identify potential participants and manage their onboarding and offboarding, emphasising the risks associated with poorly managed participation, including data governance challenges and reduced collaboration. The building block highlights the need for clear rules, inclusive governance, and regulatory compliance.
In addition to having clear and strong governance, the Legal pillar emphasises the necessity for ensuring regulatory compliance and a strong legal foundation for the LDT’s operations. It defines the following blocks:
-
Regulatory Compliance: An LDT is subject to both data and digital, sector-specific or other regulations, and as such, this building block indicates how to ensure regulatory compliance of the envisioned data cooperations, the use and sharing of data, and the provision of LDT services. It outlines actions to be undertaken by participants or potential policies that the governance authority shall consider. The building block is focusing on legal triggers, in other words, elements, criteria or events that have occurred in a particular context and signal that a specific legal framework must or should be applied.
-
Contractual Framework: While the governance framework sets out the principles, processes, standards, protocols, rules and practices that guide and regulate the governance, management and operations, those agreements also need a legal basis. This building block provides an overview of the types of legal agreements that are essential for data cooperations, categorising agreements according to their objectives, for example, institutional agreements, data sharing agreements, and service agreements. For each category of agreements, it highlights horizontal issues that are likely to emerge or take into account common regulations across all sectors (for example, the requirement of fairness in data contracts).
Finally, the LDT4SSC Blueprint defines a Design pillar with two essential building blocks which will influence how the LDTs are built, sustained and adopted, influencing all other business and organisational as well as technical building blocks, enabling the alignment of technological innovation with societal and environmental goals, fostering trust and long-term value for all users and citizens.
-
User Experience (UX): Whereas user interfaces for various LDT services, such as visualisation, analytics, simulations and so on, have a technical perspective, these also hold non-technical design choices to ensure usability, accessibility, and trust while maintaining system performance, monitored through clearly defined KPIs such as user adoption rates, task completion efficiency, and decision impact. As such, this building block emphasises the importance of a user-centric design of LDTs, including their monitoring, to align interface design with user needs, decision-making contexts, and cognitive capacities. Firstly, interfaces should provide clear and intuitive navigation, flexible data-layer management, and immediate visual feedback, supported by onboarding tools and training materials. Secondly, effective interfaces integrate spatial visualisation (3D models, overlays, linked charts, VR/XR) with analytical clarity and role-based customisation, enabling various types of users (planners, policymakers, citizens, and others) to explore both real-time and historical data through synchronised views and scenario-based simulations. Thirdly, users' visual and cognitive diversity should be considered and catered to, supporting accessibility (for example, WCAG compliance). In addition, transparency of data sources and data processing, including alignment with privacy-by-design principles (such as Gemini Principles), are essential to build user trust and inclusivity. Fourthly, co-design approaches such as actively involving stakeholders in early design and iterative testing ensure relevance, usability, and shared understanding of LDT concepts, as highlighted in studies such as BEAM (Ignatius et al., 2025) and FLOODTWIN (Frontiers, 2025). Finally, continuous UX evaluation should combine standardised questionnaires (for example, UEQ, SUS), task-based usability testing, cognitive load measures (for example, NASA-TLX), and usage analytics to monitor effectiveness and identify friction points.
-
Responsible Digital Practices: This building block refers to design principles that encourage environmentally sustainable digitalisation efforts, while building and deploying LDTs. Taking into consideration the increasing and transformative impact the digital sector has on the environment and society, this building block is designed to embed environmental sustainability, ethics, and social responsibility into the core of LDTs and its digital infrastructure. It aims to minimise the environmental footprint of digital technologies through measuring its impact (life cycle assessment, software-assisted), eco-design, energy efficiency, and circular economy practices throughout the lifecycle phases of the LDT, from design and development to decommissioning and end-of-life, including operations and maintenance.
The aforementioned building blocks are implemented in various ways, using specific assets, inter alia contracts and rulebooks, or specific methodologies and templates, inter alia the LDT4SSC Methodology, Data Cooperation Canvas, and/or various ecosystem design materials.
The business and organisational building blocks are further described in the Business and Organisational Architecture in § 4.1 Business and organisational architecture, emphasising their connections and relevance for LDTs interoperability.
2.2. Technical building blocks
This section explains what technical pillars and building blocks are required to build an LDT. Figure 9 contains a graphical overview of these pillars and blocks, which we will discuss in detail next.
The Data Interoperability pillar contains the capabilities needed for data acquisition, data exchange, semantic models, data formats, and application interfaces. This also includes functionalities for provenance and traceability. This pillar has the following building blocks, which apply to interactions within a single LDT and between LDTs:
-
Data Models (Core and Surface): Capabilities to define and use shared semantics.
-
Data Exchange (Core and Surface): Capabilities relating to the actual exchange and sharing of data.
-
Provenance, Traceability & Observability (Core and Surface): Capabilities for tracking the data sharing process so it becomes traceable and can be checked for compliance purposes.
-
Data Acquisition (Base and Core): Capabilities to extract, transform, and load data from multiple data sources, while assuring data quality. This is a new LDT-specific building block, because the Data Model block only considers the semantics of then data, and the Data Exchange block only considers the exchange and sharing of data after the LDT has acquired it. The concrete capabilities are
-
Data extraction: Extra data from multiple data sources that might use different formats and data models.
-
Data transformation: Transform data to different data formats and data models.
-
Data loading: Load and store the data so that other components of the LDT can use it.
-
The Data Sovereignty and Trust pillar contains the capabilities needed for identifying components and assets that interact within an LDT and between LDTs. This allows establishing trust and the possibility of defining and enforcing policies for access and usage control. This pillar has the following building blocks:
-
Identity and Attestation Management (Core and Surface): Capabilities to manage identities and attestations of components to ensure the reliability and integrity of components' information.
-
Trust Framework (Core and Surface): Capabilities to verify that a component adheres to certain rules.
-
Access and Usage Policies Enforcement (Core): Capabilities to specify and enforce access and usage policies.
The Data Value Creation Enablers pillar contains the capabilities for enabling value creation on top of LDTs: providing metadata on data products and publishing them in catalogues. This pillar has the following building blocks:
-
Data, Services and Offering Descriptions (Core and Surface): Capabilities to describe data, services and offerings in a manner that will be understandable by any component that interacts with(in) LDTs.
-
Publication and Discovery (Core and Surface): Capabilities to publish the description of data, services and offerings so that they can be discovered by potential data users.
The Service Creation Enablers pillar contains the capabilities for enabling service creation on top of LDTs: ensuring accessibility and inclusive user experience (UX)/user interface (UI), developing and deploying AI models, and running simulations. This is a new LDT-specific pillar, because creating service is as important as the data itself. It’s based on the Value Creation Services building block of data spaces, which we don’t include in the Data Value Creation Enablers pillar for an LDT. The new Service Creation Enablers pillar has the following building blocks:
-
Visualisation (Surface): Capability to develop visualisations of the data while ensuring their accessibility and the inclusiveness of the UI.
-
Analysis (Surface): Capabilities to develop and deploy AI models, and to enable the exploration of dynamic behaviours and scenarios within LDTs. This supports testing of policies, systems, or interventions under different assumptions. This is a new LDT-specific building block due to the importance of AI and the consequences of its usage, and the importance of running simulations on an LDT’s data. The concrete capabilities are
-
AI model development: Develop and manage AI models on top of the LDT’s data.
-
AI model deployment: Deploy AI models, either developed by the LDT or by external parties, on top of the LDT’s data.
-
-
Decision-Making (Surface): Capability to support decision-making, such as planning, participation channels, and notifications. This is a new LDT-specific building block due to the importance of supporting decision-making when creating a service on top of an LDT.
3. Workflows
Once we have built an LDT, the LDT should support the following workflows: adding a new SLC to an existing LDT (§ 3.1 Adding a new Surface-level component to an existing LDT) and discovering which SLCs work on an existing LDT (§ 3.2 Discovering which Surface-level components work on an existing LDT). We include both technical steps, which are labelled starting with "T", and business and organisational steps, which are labelled starting with "BO". We present the workflows in a mostly sequential way, but it might be necessary that we revisit previous steps when we acquire new information, including requirements and restrictions.
3.1. Adding a new Surface-level component to an existing LDT
In this section, we describe the workflow for adding a new SLC to an existing LDT, as mentioned in § 1.3 Adding a new Surface-level component to an existing LDT, reusing Core and Base-level components. We visualise this in Figure 10, where technical steps are blue with rounded corners and business and organisational steps are green with square corners.
First, we create a shared understanding of the use, pain points, and envisioned solutions (with our key stakeholders) (BO1). Next, in parallel, we determine the functional requirements of the new SLC (T1) and align the stakeholders and ensure a shared motivation to develop the use case where the new SLC is needed (BO2). T1 and BO2 might influence each other, because the stakeholders need to support the selected SLC. After T1, we determine the SLC’s technical requirements (T2). After BO2, we, in parallel, should determine how value is created and captured (BO3), and explore regulatory boundaries (BO4) to explore the feasibility of adding a new SLC and justify the investments required. BO3 can influence the technical requirements of the SLC. Next, we determine the technical gaps between the SLC’s requirements and what the LDT currently offers (T3). We follow this up, in parallel, with mapping out the costs and benefits and assessing the return on investment (BO5); and determining how we will deal with the technical gaps (T4). BO5 leads us to exploring if we need additional data providers and/or intermediaries and operators (BO6), and if we need to make changes to the existing governance framework (BO7) or if it doesn’t exist yet, create one. BO7 might require us to update our contractual framework (BO8), which in turn might require us to make parties sign updated or newly established agreements and contracts (BO9).
BO6 and BO7 might influence each other, because, on the one side, the governance framework might affect the data providers and intermediaries we are allowed to interact with, and, on the other side, if we want to work with providers and intermediaries that don’t fit within the governance framework, we need to update the governance framework. BO6 and T4 might also influence each other, because, on the one hand, the technical gaps might influence which providers and intermediaries we need, and, on the other hand, the unavailability of certain providers and intermediaries might require additional actions to resolve a technical gap.
If there are new participants in the LDT, we need to onboard them (BO10). Next, we deploy the participatory and service design methods throughout the design and implementation phases (BO11), addressing the two design building blocks described in § 2.1 Business and organisational building blocks. We follow both T4 and BO11 by implementing the technical changes and deploying the components. Finally, we can start using the new SLC with our LDT and start creating the envisioned value for our beneficiaries.
Note that this process might not be straightforward, and we might need to go back to previous steps to adapt or validate specific details, either with respect to the technical aspects or the business and organisational aspects, or both.
3.2. Discovering which Surface-level components work on an existing LDT
In the previous workflow, we manually executed the steps T2 and T3, but it should be possible to automate these steps, as mentioned in § 1.4 Discovering which Surface-level components work on which existing LDTs and exchanging components through interconnected LDTs. This is the goal of this section’s workflow (see Figure 11).
For each available SLC, especially those built for other SLCs, e execute 2 steps. First, we automatically determine the technical requirements to deploy the SLC (T1). Next, we automatically determine the gaps between these requirements and what the LDT offers (T2). Finally, we use these SLCs in the first workflow at T1. This doesn’t mean that we can skip T2 and T3 of this workflow because we still have to take into account the business and organisational aspects, such as legal checks and signing of necessary agreements or budgetary assessments, but it allows us to speed up the process.
4. Reference architectures
In this section, we discuss the business and organisational architecture, including how it aligns with the business and organisational building blocks. Next, we discuss the technical architecture, including how it aligns with the technical building blocks, and the standards and protocols that we recommend.
4.1. Business and organisational architecture
The business and organisational architecture of LDTs builds on the building blocks of § 2.1 Business and organisational building blocks. Figure ?? provides the schematic overview of the interrelations of various business and organisational building blocks, specific to developing and operating an LDT. Note that building blocks are not specific assets or components, as these are deployed based on particular implementation contexts. However, as the LDT4SSC project’s aim is to support the development of an LDT ecosystem, Figure ?? introduces further the business and organisational building blocks necessary for fostering the connections between various LDTs, and the sharing of data products and LDT services.
Figures ?? and ?? consist of five major clusters:
-
An LDT (dark grey), including data products and LDT services.
-
LDT ecosystem (light grey, only in Figure ??) refers to the overarching framework for connecting LDTs and sharing resources (data products and/or services) among them.
-
Participants in their specific roles (blue), emphasising especially data providers, data consumers, intermediaries/operators and/or a governance authority (even though there may be additional roles, defined by LDT’s governance framework). Note that these are not mutually exclusive, and participants may carry one or multiple roles. All participants must adhere to the governance framework, ensure regulatory compliance, and are expected to participate in the respective use cases. Note that single participants (legal bodies) have their own organisational form and business model, and their interests, rights and responsibilities must be accounted for when designing the data cooperation model.
-
Business and organisational building blocks (green) that are necessary either for the design, governance or operations of the LDT and/or LDT ecosystem.
-
Urban and community processes (yellow) layer emphasises the importance of integrating LDT services into specific urban and community processes, such as smart governance, administration, specific urban or community services or others. This fosters practical value creation and increases the relevance of LDTs in the respective local community, showing how LDTs help address local needs and achieve specific objectives.
Following Figure ??, the development and use of an LDT is dependent on a specific use case(s), which identifies the need for specific LDT services and data products. That use case must address local needs and integrate the LDT into urban processes. In doing so, the LDT’s user experience should be carefully considered and monitored to foster adoption. To sustain the use of LDTs and the respective use cases, one needs to ensure a feasible business model (short- and long-term), which is aligned with the strategic business incentives of all engaged participants.
Various participants engage/participate in the use case in different ways:
-
The governance authority of an LDT maintains the governance framework, which defines the rules, processes, standards, and so on, of an LDT, including the promotion of responsible digital practices. All participants need to adhere to that governance framework to participate in the LDT development/operations and in the specific use case.
-
A data provider provides data products for the LDT, which are then consumed by data consumers (often the provider of the LDT services).
-
To support the integration of additional data sources, the builders and/or owners of the LDT may cooperate with intermediaries or operators, who may facilitate the exchange and/or preparation of the data products.
While collecting, sharing and processing data (as well as any other business activity), all participants must ensure regulatory compliance in their actions. Relatedly, the contractual framework will give a legal ground to the established governance framework and ensure legal certainty and alignment with various regulations.
Depending on whether the participants have an organisational form or not, data sharing and engagement in the LDT may vary (for example, whether individuals could engage with the LDT by providing data directly). Also, if the LDT is co-developed by multiple actors, it may be co-governed through a specific organisational form (either incorporated, such as an association, or unincorporated, such as a consortium or joint venture).
In addition to the perspective of necessary building blocks for the single LDT, Figure ?? provides an overview of the building blocks (and relationships between them) that shape how several LDTs connect with one another and exchange assets among themselves. LDTs may leverage the interoperability framework of data spaces and the guidelines from DSSC and DS4SSCC-DEP, as discussed in § 2 LDT building blocks based on DSSC & DS4SSCC-DEP building blocks.
The central focus point is again on the use case, which identifies the need for sharing specific data products or LDT services. Furthermore, the use case identifies mandatory functionalities (capabilities) for the functioning of the LDT ecosystem (for example, exchange of assets, brokering, and so on) that may be provided by a data space. A data space is defined by the rulebook (essentially a documented governance framework), which includes a structured set of principles, processes, standards, protocols, rules and practices that guide and regulate the governance, management and operations within a data space to ensure effective and responsible leadership, control, and oversight. It also defines the functionalities the data space provides and the associated data space roles, including the data space governance authority and participants. The rulebook is maintained by a data space’s (DS) governance authority, which also decides on the participants' management, in other words, the onboarding, continuous facilitation of participants, and offboarding. Relatedly, LDT-ecosystem is not an intellectual construct - it has tangible interfaces through which users experience the ecosystem and the interactions within.
It’s worth noting that an operational data space (LDT ecosystem) also has a business model to sustain its activities and fulfil its purpose. It also takes an organisational form (incorporated or unincorporated), which influences several business and organisational considerations (such as what agreements/contracts should be established, what its decision-making processes will look like, and so on).
4.2. Technical architecture
4.2.1. Support different data models
4.2.2. Support different data exchange types
4.2.3. Support for the usage of data from different LDTs
4.2.4. Support for working with different AI models
