Objectives and application by Sandbox Alliance
The Generic Adoption Criteria are designed as a first-level assessment framework to determine whether a product or service is suitable for inclusion within the EDIC ecosystem.
The primary objective of these criteria is not to fully validate a solution, but to provide an initial, structured evaluation of:
- interoperability alignment
- deployability
- usability / operational feasibility
- scalability and replicability
- and strategic fit within the EDIC ecosystem
This initial assessment serves as a filtering and qualification step, enabling the EDIC to identify solutions that are sufficiently mature and aligned to proceed to the next phase.
Following this initial evaluation, the actual validation of a product or service takes place through deployment in the EDIC Sandbox environment.
Within the Sandbox, solutions are:
- deployed in a controlled but realistic environment
- tested in combination with other building blocks
- and validated as part of a broader infrastructure rather than as isolated components
The Sandbox therefore allows the EDIC to assess:
- whether a solution scales beyond a single implementation
- whether it integrates effectively with other components in the ecosystem
- and whether it contributes to a coherent, interoperable and reusable Digital Twin infrastructure.
A key objective of the Sandbox phase is to verify that building blocks do not only function individually, but also operate as part of a coherent and interoperable deployment.
This includes validating:
- interoperability across multiple components
- integration in a federated infrastructure
- and the ability to support a scalable, multi-city ecosystem
The outcome of the Sandbox evaluation forms the basis for the final decision on whether a product or service can be:
- adopted as-is
- adopted with adaptations
- or excluded from the EDIC ecosystem
Ecosystem Interoperability and Replaceability of Building Blocks
A key principle of the EDIC approach is that interoperability is not limited to the ability to connect individual components, but must enable the creation of a scalable and replaceable ecosystem of Digital Twin building blocks.
In many implementations, interoperability is achieved through direct, point-to-point integrations between components. While such integrations may comply with open standards and enable data exchange, they often result in tightly coupled solutions that are difficult to scale, extend, or adapt. In these cases, components are technically interoperable, but not yet part of a true ecosystem.
Within the EDIC ecosystem, interoperability is therefore defined at a higher level:
- Connections between components are not one-to-one, but "many-to-many (N-to-N)".
- Components interact through standardised interfaces, shared data models, and common service layers, rather than bespoke integrations.
- Each component can be replaced, extended, or reused without requiring reconfiguration of all other components.
This ecosystem-oriented approach ensures that Digital Twin building blocks are:
- Plug-and-play, allowing new components to be added with minimal integration effort
- Replaceable, enabling cities to switch providers or solutions without redesigning the entire system
- Scalable, supporting expansion across cities, domains, and use cases
- Reusable, allowing the same components to be applied in different contexts
Achieving this level of interoperability requires alignment across all interoperability dimensions:
- Technical interoperability ensures that components can connect through standardised APIs and protocols
- Semantic interoperability ensures that exchanged data has consistent meaning across components
- Organisational interoperability ensures that processes and responsibilities support multi-party integration
- Legal interoperability ensures that data sharing and service usage are compliant across jurisdictions
- Cultural interoperability ensures collaboration, trust, and shared understanding between stakeholders in the ecosystem
To support a true Digital Twin ecosystem, products and services must:
- Avoid dependency on point-to-point integrations
- Support integration through shared platforms or data spaces (e.g. OUP-like environments)
- Expose functionality through reusable and standardised interfaces
- Be designed as independent, modular building blocks that can operate in a multi-provider environment
Evaluators should assess whether a solution merely integrates with other components, or whether it is capable of functioning as part of an interchangeable ecosystem. Solutions that rely on bespoke integrations or tight coupling between components should be considered less suitable for the EDIC ecosystem, even if they meet basic interoperability standards.
Generic Adoption Criteria for Products and Services within the EDIC
This chapter defines the generic adoption criteria for products and services to be included within the EDIC ecosystem. The purpose of these criteria is to ensure that all adopted components are interoperable, scalable, and aligned with the strategic vision of a federated European digital ecosystem.
The criteria extend beyond technical compliance by incorporating the full set of interoperability dimensions as defined in the European Interoperability Framework (EIF): cultural, legal, organisational, semantic, and technical interoperability. This ensures that adopted products and services can operate effectively across cities, domains, and national contexts.
Each product or service is evaluated across four categories:
- Deployment Criteria
- User Adoption Criteria
- Technical Criteria
- Strategic / Value-Driven Criteria
Evaluation is performed using a Yes / No (Y/N) scoring per criterion. The combined outcome determines whether a product or service can be adopted, requires adaptation, or should be excluded.
Deployment Criteria
These criteria ensure that a product or service can be successfully deployed, integrated, and governed within the EDIC ecosystem across multiple cities and organisational contexts.
| Criterion | Y/N |
|---|---|
| Compliance with open standards and interoperability frameworks (technical and semantic) | |
| Data protection, security, and trust mechanisms are implemented and documented | |
| Deployment manuals are available, complete, and up to date | |
| Deployment is tested in both controlled environments and real-world city environments | |
| Governance structures for deployment and operation are defined (roles, responsibilities, decision-making) | |
| Clear agreements exist on data ownership, access rights, and usage conditions |
Evaluator guidance:
A product or service must demonstrate that it can be deployed in different organisational and legal contexts without creating barriers to interoperability. Particular attention should be paid to the clarity of governance structures and legal compliance in cross-border scenarios.
User Adoption Criteria
These criteria assess usability, replicability, and the ability of the solution to be adopted across diverse organisational and cultural contexts.
| Criterion | Y/N |
|---|---|
| Product/service demonstrates practical usability for target users across different cities | |
| Comprehensive documentation and training materials are available (minimum in English) | |
| Onboarding process is clear and manageable | |
| The solution supports replicability and reuse across cities and domains | |
| Evidence of adoption in multi-stakeholder or cross-city environments | |
| Shared terminology, concepts, and documentation are consistently applied | |
| The solution can operate effectively across different organisational and cultural contexts |
Evaluator guidance:
Adoption is not purely a technical matter. Evaluators should assess whether the solution enables collaboration between stakeholders with different backgrounds, ensuring shared understanding, trust, and effective communication.
Technical Criteria
These criteria assess the technical robustness of the solution, including interoperability, data architecture, and alignment with federated ecosystem principles.
| Criterion | Y/N |
|---|---|
| Architecture aligns with the EDIC reference architecture | |
| Supports federated data usage (data remains at source where appropriate) | |
| Supports federated analytics and/or AI capabilities | |
| Uses standardised and commonly agreed data models (semantic interoperability) | |
| Provides standardised and documented APIs for data access and exchange | |
| Supports secure data exchange, authentication, and access control mechanisms | |
| Supports lifecycle management (including versioning and updates) | |
| Enables interoperability through widely adopted mechanisms and standards |
Evaluator guidance:
Technical compliance must go beyond basic connectivity. Evaluators should verify that the solution supports semantic consistency, standardised APIs, and secure data exchange, enabling integration within a federated multi-city ecosystem.
Strategic and Value-Driven Criteria
These criteria evaluate the strategic fit, long-term value, and contribution of the product or service to the EDIC ecosystem.
| Criterion | Y/N |
|---|---|
| The maturity level of the product/service is clearly defined | |
| The expected value for cities (e.g. cost savings, improved services, sustainability impact) is clearly articulated | |
| Total cost of ownership (TCO) and pricing structures are transparent | |
| The provider demonstrates long-term stability and commitment within the European ecosystem | |
| The solution aligns with European interoperability frameworks and ecosystem principles | |
| The solution contributes to a scalable and reusable ecosystem across cities | |
| The solution supports digital sovereignty and European strategic autonomy |
Evaluator guidance:
A product or service should not only be technically sound, but also contribute to the long-term sustainability and scalability of the EDIC ecosystem. Strategic alignment with European values and interoperability principles is essential.
Evaluation Outcome
Based on the assessment across all criteria, the following conclusions can be drawn:
- The product/service does not fit within the EDIC ecosystem
- The product/service fits with required adaptations
- The product/service fits and can be adopted directly
Evaluator guidance:
Evaluation should not be based solely on the number of positive criteria, but on the overall balance between interoperability, usability, and strategic fit. Critical gaps in legal, semantic, or organisational interoperability should be considered blocking issues, even when other criteria are met.