D5.4 Deliverable of the EOSC Beyond Project

https://zenodo.org/records/17292990

Document D5.4 describes an operational component of the European Open Science Cloud ecosystem called the EOSC Core Innovation Sandbox. It is not a theoretical prototype, but a working pre-production environment available online, where the integration of services and Nodes with the EOSC Federation Core can be safely tested before moving to production operation.

What is the “Innovation Sandbox” and why is it needed?

The document explains that, during the early stages of the European Open Science Cloud, integration was often slowed down by fragmented and incompatible test environments. Service providers and Node operators lacked a trusted space where integrations could be tested, validated and fine-tuned before entering the production environment. The Sandbox was designed specifically to close this gap as a dedicated pre-production environment.

The key idea is “risk shifting”: all experiments with connection, compatibility testing, troubleshooting and configuration changes are carried out not in the production federation, but in a controlled environment. This reduces the likelihood of incidents in the production environment and turns integration into a managed quality-control process rather than a one-off manual operation.

Objectives and effects for the federation

D5.4 defines the Sandbox not only as a technical testing site, but also as a tool for strengthening the long-term resilience of the federation. Three groups of objectives are highlighted:

• reducing risks by moving integration work into a pre-production environment;
• ensuring interoperability, since the European Open Science Cloud relies on common frameworks such as authentication and authorisation infrastructure, persistent identifiers, metadata profiles and FAIR principles; the Sandbox operates as a federator node and provides a place to test compliance with these frameworks;
• building the capacity of Node operators: the environment allows operators, including those who are only beginning to establish national, regional or thematic Nodes, to rehearse deployment, test onboarding procedures and increase their operational maturity before joining the production federation.

Main users of the Sandbox and what they test

In the section on stakeholders, D5.4 describes how the Sandbox is used by different groups:

• Providers of core services test and improve fundamental components such as authentication and authorisation infrastructure, helpdesk, monitoring, accounting and persistent identifier services.
• Service and data providers that plan to be represented in the European Open Science Cloud Marketplace can test compliance with metadata, accessibility and interoperability requirements without creating risks for end users.
• Research communities use the environment to validate complex workflows that combine data and tools from different domains, and to test reproducibility, FAIR compliance and cross-domain compatibility.
• Infrastructure operators, including those preparing to become Nodes, test authentication mechanisms, resource catalogue integration and helpdesk connection in order to bring their configurations into compliance before joining the federation.

The document also emphasises that access and engagement are organised through roles, while formal procedures focus primarily on three categories: service providers, research communities and infrastructure operators, including pilot Nodes.

Federating capabilities provided by the environment

D5.4 describes the Sandbox as a virtual federator node that provides a set of core federating services required to test the integration of Nodes and resources.

The capabilities mentioned include authentication and authorisation, persistent identifiers, monitoring, accounting, helpdesk, messaging, an execution environment for application deployment and lifecycle management through an infrastructure management component and orchestration templates, as well as a resource catalogue and resource ordering mechanism.

This is important precisely as an integrated package. The document underlines that the combination of the environment, services and documentation is at the heart of the architecture, because the platform must serve not only as a testing ground, but also as an entry point into the federation, with transparent pathways from experimentation to production readiness.

Federating Capability	Core Component(s)	Function
Authentication and Authorization	AAI (Infrastructure Proxy, Identity Hub, Federated AAI Connector)	Federated access across nodes and services, single sign-on, and identity management.
Execution Framework	Infrastructure Manager, TOSCA templates	Deployment and orchestration of applications across heterogeneous infrastructures; supports multi-cloud and lifecycle management.
Persistent Identifiers	PID Service	Long-term identification and resolution of digital objects across the federation.
Monitoring	Monitoring Service	Collection and publication of availability and reliability metrics for EOSC Core and Exchange services.
Accounting	Accounting for Services; Accounting for Research Products	Usage tracking and aggregation of metrics for services and research outputs.
Helpdesk	Central Helpdesk and Adapters	Unified ticketing, support management, and integration with provider-specific helpdesks.
Messaging	ARGO Messaging Service	Reliable message exchange and notification system between federated components.
Resource Catalogue	Service Catalogue; Research Product Catalogue	Registration, discovery, and management of resources and providers within EOSC.
Order Management	Order Management System	Unified ordering and provisioning workflow across EOSC services.
Front Office	Explore; Discovery Hub; User Dashboard	User interface for researchers to discover, request, and access EOSC resources.

Table 1. EOSC Core federating capabilities. These federating capabilities form the cornerstone of the Sandbox architecture.

How access and onboarding are organised

The document explains that access requests are submitted with a description of the use case, technical requirements and support needs. The support team then guides the applicant according to their role.

For service providers, the document emphasises that, after registration, they can add their own resources — services, data sources, research products and training materials — to the Sandbox catalogue. However, responsibility for registering and describing the resources lies with the provider. These descriptions must comply with European Open Science Cloud profiles and are integrated into the catalogue.

For research communities, the document states that, after authentication and registration, they can browse the federated catalogue and request access to services and other capabilities offered for testing.

For operators of future Nodes, the practical value of the Sandbox is that deployment is recommended to begin specifically in this environment. The process is organised in stages: a development environment, an integration environment and a pre-production environment. This pathway makes it possible to gradually refine the configuration, reduce the risk of errors in the production environment and use technical expert support during onboarding.

Practical significance for the National Academy of Sciences of Ukraine and a future Node

From the perspective of establishing a Node of the National Academy of Sciences of Ukraine, the document provides a useful “preparation framework”. A Node should be deployed in such a way that, before production connection to the European Open Science Cloud, it can pass through a cycle of checks in a pre-production environment, with a focus on interoperability, quality and compliance with the FAIR principles.

In practical terms, this opens three clear pathways for using the Sandbox:

1. Node operator pathway.
   Check whether the selected services of the NAS of Ukraine Node interact correctly with federating components: single sign-on, resource catalogues, helpdesk integration, monitoring mechanisms and accounting of usage. These elements are identified in the document as typical objects of testing for infrastructure operators preparing to join the federation.
2. Service and data provider pathway.
   Prepare “packaged” resources for future provision through the NAS of Ukraine Node, test compliance with metadata, accessibility and interoperability requirements, and work through the process of registering and describing resources in the catalogue.
3. Research community pathway.
   Select two or three representative workflows, for example in digital materials science or computational mechanics of materials, and run them under federated conditions in order to test reproducibility, reuse and compatibility of components from different domains.