SRIDA
Strategy and plan for the implementation of exascale research data federation and compute continuum for data-intensive science
- Published
- May 2026
The SRIDA at a glance
Select a pillar or priority to read about it, and follow its links to the Technical Blueprint.
Explore the Technical Blueprint
- Pillar 1Policy, Trust & GovernanceGoverning access, allocation and coordination
- Pillar 2Architecture & InteroperabilityIntegrating compute, data and workflows
- Pillar 3Software & Science EnablersEnabling AI, portability and reproducibility
- Pillar 4Human Capital & ResponsibilityStrengthening communities, improving environmental sustainability and workforce
› Pillar 1
Pillar 1: Policy, Trust & Governance
Governing access, allocation and coordination
Challenges
- Governance fragmentation. Thematic research digital infrastructures (e.g. WLCG for HL-LHC, SRCNet for SKAO) and pan-European multi-disciplinary digital infrastructures (e.g. EuroHPC, EOSC, EGI) operate under different governance models with limited systematic coordination. Success stories exist: the long-standing cooperation between WLCG and EGI demonstrates that effective co-design is achievable. However, structured engagement between data-intensive science communities and EuroHPC remains underdeveloped. Wider coordination mechanisms would benefit all parties.
- Allocation cycle mismatch. Research infrastructures operate on multi-decade timelines (the LHC has been operational since 2008 and via the HL-LHC upgrade will run through 2041; SKA is foreseen to be operational for 50+ years from the start of operations), yet must navigate incompatible allocation models across the infrastructure landscape. Federated infrastructures like WLCG operate on pledged resources committed by national funding agencies, whilst EuroHPC centres use competitive peer-reviewed proposals typically granted for one year. Experiments need guaranteed access for 3-5 year periods compatible with their planning cycles, but no unified framework spans these different approaches. This creates planning uncertainty, repetitive submission burden, and discourages investment in workflow optimisation.
- Authentication fragmentation. federated digital infrastructures and HPC centres operate partially incompatible identity management systems. Lack of federated identity management and multi-factor authentication (MFA) barriers for unattended workflows prevent seamless authenticated access. Without this, technical interoperability alone provides no benefit to researchers.
How its priorities interlock
the three priorities are mutually load-bearing. Allocation (P02) cannot operate without governance agreements (P01) to legitimise cross-boundary use, and depends on federated identity (P03) to attribute usage; trust frameworks (P03) require P01 to gain currency outside their home organisation; and P01's coordination work becomes operationally meaningful only when P02 and P03 are in place.
For scientific communities and research infrastructures
- Seek formal representation in horizontal e-Infrastructure advisory structures to ensure scientific requirements shape infrastructure decisions (P01)
- Publish multi-year resource plans aligned with experimental timelines to inform infrastructure planning (P02)
- Adopt federated identity frameworks enabling seamless access across infrastructure boundaries (P03)
For e-infrastructures and service providers
- Establish liaison mechanisms with thematic research infrastructure governance bodies to ensure scientific requirements shape infrastructure decisions (P01)
- Technically implement multi-year allocation frameworks providing planning certainty for data intensive research facilities beyond annual cycles (P02)
- Deploy AARC Blueprint Architecture for federated authentication supporting unattended workflows (P03)
For policy makers and funding bodies
- Recognise data-intensive research infrastructures which their long-term needs for digital infrastructure as an important stakeholder category in EuroHPC and EOSC governance (P01)
- Fund coordination mechanisms bridging thematic and horizontal infrastructure governance (P01)
- Enable strategic (multi-year) access designations aligning allocation cycles with the planning horizons for data-intensive research facilities (P02)
- Support trust framework harmonisation enabling federated authentication across European digital Infrastructures and national centres (P03)
In the Technical Blueprint (from SRIDA Annex C.4):Resource FederationSecurity and TrustMonitoring and Observability
› Pillar 2
Pillar 2: Architecture & Interoperability
Integrating compute, data and workflows
Challenges
- Computing integration fragmentation. HTC and Cloud communities have established federation within their domains (WLCG federates 170 sites; EGI provides brokering across European e-Infrastructures). The HPC federation is still developing, with the EuroHPC Federation Platform under development. Each HPC centre uses its own portals, schedulers, and software stacks, requiring experiments to custom-adapt to each site. Integration across the different resource types remains limited and standardised integration policies are needed to enable unified orchestration across HPC, HTC, Cloud, and emerging quantum resources (D6.1, Gaps #3, #5).
- Data management fragmentation. Exabyte-scale workflows require moving data between long-term archives and transient compute resources, yet transfer mechanisms are fragmented and often rely on ad-hoc tools. No unified architectural approach exists for FAIR storage across domains, including standardised metadata and provenance tracking. Between large Tier-0/1 sites (CERN, the main WLCG and SRCNet hubs) the network backbone is generally adequate, with GÉANT and dedicated overlays (LHCONE, LHCOPN) providing high-capacity transport (D6.1 Section 4.2). Reaching beyond those core sites is the binding constraint: D6.1 Section 5.4 identifies network connectivity as a persistent technical constraint and notes that "at minimum, HPC sites need strong connectivity to WLCG centres and SRCNet nodes", with realistic demand validation required at non-core centres.
- Workflow orchestration limitations. Scientific workflows increasingly span multiple facilities, yet orchestration systems remain fragmented across communities. Cross-facility workflows lack resilience and provenance capture. Resource-aware scheduling that considers data locality, compute availability, energy and cost optimisation remains immature.
How its priorities interlock
The three priorities form a layered structure. Workflow orchestration (P06) depends on heterogeneous computing integration (P04) to execute across diverse resources and on data management (P05) to stage data appropriately. Effective data transport requires understanding of compute and storage resource availability; efficient computing requires data locality awareness. Existing projects demonstrate this integration: interTwin delivers workflow orchestration spanning HPC and HTC resources, whilst Rucio (the WLCG-originated distributed data-management framework, now adopted across multiple experiments) provides data management across the WLCG and SRCNet federation.
For scientific communities and research infrastructures
- Down-select to a small set of supported interfaces, data-management tools, and workflow engines so that e-Infrastructures can build against a stable target (P04, P05, P06)
- Ensure the capability to execute on diverse compute platforms via code porting and/or the use of high level programming frameworks (P04)
- Contribute to use cases that drive data management and transport requirements (P05)
- Engage in co-design of workflow orchestration capabilities through community working groups and with service providers (P06)
For e-infrastructures and service providers
- Implement standardised interfaces for heterogeneous resource description, discovery, and access (P04)
- Deploy interoperable data management services with FAIR-compliant metadata (P05)
- Support cross-facility workflow execution through common orchestration frameworks (P06)
For policy makers and funding bodies
- Fund architecture-ecosystem development across European digital infrastructures (EuroHPC, EOSC, EGI) (P01, P04)
- Fund uptake of federated identity and access management for workflows and the compute, data, and network components those workflows interface with (P03, P04)
- Fund development of integration and deployment testbeds enabling validation across HPC/HTC/Cloud resources (P04)
- Support (smart) network capacity investments enabling exabyte-scale data movement (P05)
- Require interoperability standards in infrastructure procurement (P04, P05, P06)
In the Technical Blueprint (from SRIDA Annex C.4):Compute ResourcesOrchestration and WorkflowsData ResourcesMonitoring and Observability
› Pillar 3
Pillar 3: Software & Science Enablers
Enabling AI, portability and reproducibility
Challenges
- AI maturity gap. Machine learning methods are increasingly central to simulation, reconstruction, and analysis, yet most infrastructures treat them as add-ons rather than integral capabilities. Scaling from demonstration to operational deployment is challenging, often dependent on small teams rather than sustainable capacity. The gap between AI potential and AI reality represents a strategic bottleneck.
- Portability limitations. Scientific codes optimised for one architecture often cannot exploit another without substantial rewriting. The computing landscape now spans CPUs, GPUs, FPGAs and emerging accelerators, each with different programming models and each with typical evolution cycles of 2-5 years. Taking advantage of heterogeneous resources requires software that is portable across centres and automatically exploits available hardware capabilities; this can be realized by careful porting to all the architectures of interest (e.g., EESSI), or by using high-level frameworks designed for portability (e.g. Kokkos, SYCL/oneAPI, OpenMP target offload, or ALPACA).
- Reproducibility requirements. Scientific insights must be reproducible over a long period requiring preservation of complete computational context including software, workflows, documentation and execution environments. Current practices often fail to capture sufficient information for later reproduction.
- Long-term preservation. Instrument lifetimes of 10-50 years require software (together with the complete execution environment) that survives across hardware generations and organisational changes. Code developed today must remain executable and maintainable through multiple technology transitions.
How its priorities interlock
The four priorities form a coherent approach to sustainable scientific software. Portability (P08) enables reproducibility (P09) by decoupling software from specific environments. AI/ML integration (P07) depends on portable software methods (P08) to deploy models across heterogeneous resources. Long-term preservation (P10) requires the documentation and standardisation practices developed for reproducibility (P09).
For scientific communities and research infrastructures
- Invest in transitioning AI applications from proof-of-concept to production deployment (P07), including evaluation of LLM-assisted ("vibe-coding") workflows as a possible accelerator for porting scientific codes to new architectures and for sustaining them across hardware generations (P10)
- Engage with the RAISE AI for Science pillar to secure HEP and RA representation and contribute use cases for AI Factory pilot workloads (P07)
- Adopt portable programming models and (micro-)architecture optimized distribution for new software developments (P08)
- Implement FAIR Principles for research softwares (e.g., FAIR4RS) guidelines for software documentation and preservation (P09, P10)
- Engage with the i.a., the EVERSE software-quality framework and the EOSC science-cluster software repositories such as the ESCAPE Open-source Scientific Software and Service Repository (OSSR) (P08, P09, P10)
For e-infrastructures and service providers
- Deploy AI platforms as integral infrastructure capabilities, not add-ons (P07)
- Provide federated-learning infrastructure for privacy- and sovereignty-constrained training, and operate AI Factory pilots that integrate HEP and RA workloads with EuroHPC AI infrastructure (P07)
- Support common software repositories and distribution systems (P08)
- Align service offerings with the community-driven and maintained software-excellence frameworks and science-cluster software repositories (e.g., EVERSE, ESCAPE OSSR (P08, P09))
- Provide execution environments and support workflow tooling that enable reproducibility and provenance capture (P09)
For policy makers and funding bodies
- Fund transition of AI applications from proof-of-concept to production deployment (P07)
- Fund inference infrastructure integration across distributed computing resources (P07)
- Require reproducibility standards in funded research (P09)
- Fund software preservation as an essential investment component of research and digital infrastructures (P10)
- Reform resource-accounting frameworks so that GPU and AI-Factory allocations are accepted as pledged resources within WLCG and SRCNet accounting (P07)
- Engage the AI Office on AI Act application to scientific AI, including model documentation, dataset transparency, and risk classification for safety-relevant operational AI such as detector control and observatory operations (P07)
- Sustain pan-European software-excellence frameworks such as EVERSE, science-cluster software repositories such as the ESCAPE Open-source Scientific Software and Service Repository (OSSR), and optimized software compilation, packaging and distribution such as EESSI as cross-priority enablers for software quality, training, and FAIR-for-software practices (P08, P09, P10)
In the Technical Blueprint (from SRIDA Annex C.4):AI/ML and HPC ApplicationsCompute ResourcesSoftware Distribution and ExecutionData Resources
› Pillar 4
Pillar 4: Human Capital & Responsibility
Strengthening communities, improving environmental sustainability and workforce
Challenges
- Workforce skills gap. The drivers described in Section 3 require expertise that is in short supply. Heterogeneous computing demands specialists in portability and performance engineering. AI/ML adoption depends on machine learning engineers who can bridge proof-of-concept and production. Sustainability goals require transverse hardware-software expertise to minimise impacts through continuous code optimisation, impact-aware scheduling and infrastructure operation. Sustained progress requires a triangular collaboration model: researchers driving concept and validation, code developers responsible for implementation and optimisation, and digital-infrastructure specialists owning operations and performance. This collaboration needs to be sustained by science funders as a multi-year commitment rather than assembled from ad-hoc project additions, with return on investment evaluated where appropriate. Community surveys indicate that most research groups identify technical capacity as a concern, yet lack resources and expertise to address it.
- Career structure misalignment. Scientific career structures do not recognise or reward contributions to infrastructure, software development, or operational efficiency. Research software engineers, who bridge domain science and computing expertise, typically lack defined career paths. This creates retention challenges as the same skills command premium salaries in the commercial sector. The Amsterdam Declaration on Funding Research Software Sustainability identifies recognition of software as a first-class research output, but operational uptake has been uneven: most large-scale digital infrastructures provide only limited code-optimisation support, and deep domain-level RSE work is rarely embedded in their core remit. Partial implementations exist via EuroHPC Centres of Excellence, RI Train, and HPC Train, but no European-level funding line yet sustains the triangular researcher–RSE–DI collaboration the priority calls for. The Declaration treats recognition as a research contribution as essential to workforce sustainability.
- Fragmented community coordination. Research infrastructures and the federated digital infrastructures serving them are coordinated unevenly: WLCG and the Grid stack have a mature multi-party governance, but the coupling between data-intensive science needs and EuroHPC remains under-articulated, and structured engagement between scientific RIs and the broader European digital-infrastructure providers is still partial. Scientific requirements are often invisible when infrastructure decisions are made. Effective co-design requires sustained collaboration that current funding models do not reliably support.
How its priorities interlock
Community collaboration (P11) provides the foundation for this pillar and connects across all pillars through co-design processes that shape governance decisions (Pillar 1), technical architecture (Pillar 2), and software priorities (Pillar 3). Within Pillar 4, P11 coordinates sustainability practices (P12) and enables knowledge transfer for skills development (P13). These priorities create the organisational foundation on which technical capabilities depend.
For scientific communities and research infrastructures
- Increase and incentivise participation in co-design processes and CoPe Working Groups (P11)
- Integrate and reward environmental impact awareness into software development practices (P12)
- Recognise and value research software engineering contributions within projects and collaborations (P13)
For e-infrastructures and service providers
- Maintain community engagement mechanisms through dedicated liaison roles and coordination structures (P11)
- Implement a sustainability governance through impact reporting and impact-driven resource allocation (P12), supported where possible by EU-level regulation that institutions can act on (the post-CSRD/Omnibus reporting landscape is still settling, so the regulatory hook for research computing remains to be defined)
- Provide automation (e.g, AI-driven), training and documentation enabling efficient use of heterogeneous resources (P13)
For policy makers and funding bodies
- Fund sustained community coordination mechanisms beyond project timelines (P11)
- Define admissible impact budgets for infrastructures and evaluate investments and operation in this frame (e.g., by implementing reporting requirements at the EU-level) (P12)
- Establish career frameworks for research software engineers (across emerging skill areas including AI/ML, performance engineering, and scientific code preservation) and for data stewards (responsible data management, hierarchical-storage management, and long-term curation) (P13)
In the Technical Blueprint (from SRIDA Annex C.4):Resource FederationMonitoring and Observability
› › P01
P01 Cross-Infrastructure Governance
Why it matters
The compute and data continuum vision requires research workflows to span resources governed by different entities: thematic research digital infrastructures (e.g. WLCG for HL-LHC, SRCNet for SKAO), pan-European multi-disciplinary digital infrastructures (e.g. EuroHPC, EOSC, EGI), nationally funded facilities, and community-governed federations. Each governance model reflects legitimate objectives. Without coordination mechanisms bridging these structures, researchers experience governance boundaries as friction that limits infrastructure utility.
Outcomes
- Coordination forum with a substantive agenda
- Coherent European infrastructure investment
- Short term (1 to 3 years)
- Set up a coordination forum of thematic and multidisciplinary infrastructures, with policy makers, and define its agenda.
- Medium term
- Pilot integrated cross-border access, and develop policy on the operational-versus-project funding mismatch, aligned with the ERA Act.
- Long term
- Decide whether a formal institutional structure is warranted, and align governance with multi-decade scientific programmes.
Actions by stakeholder
Scientific communities and research infrastructures
- Publish multi-year resource plans, five years ahead or more.
- Designate representatives for the coordination forum.
- Co-design with e-infrastructures, bringing innovation requirements alongside capacity needs.
E-infrastructures and service providers
- Set up liaison with thematic research infrastructures, with named contacts and periodic reviews.
- Accommodate operational access models alongside project-based allocations.
- Coordinate interface standards, identity and accounting.
Policy makers and funding bodies
- Make data-intensive science requirements inform EuroHPC and EOSC procurement.
- Address the mismatch between operational needs and project funding, through multi-year allocation (P02) and operational funding streams.
- Align national and European research infrastructure investments, in line with the ERA Act.
Enables:
In the Technical Blueprint (from SRIDA Annex C.4):Resource FederationSecurity and Trust
› › P02
P02 Federated Resource Allocation
Why it matters
Europe invests substantially in research computing and data infrastructure through EuroHPC, national programmes, and federated e-Infrastructures. Yet allocation mechanisms fragment this investment. Scientific computing is increasingly data-intensive, with exploitation of exabyte-scale datasets relying on a diverse and heterogeneous compute continuum spanning HPC, HTC, cloud, and emerging accelerator systems. Research infrastructures increasingly operate on multi-decade timelines, yet face annual application cycles, system-specific allocations that prevent workload-appropriate resource selection, and accounting frameworks that cannot track usage across governance boundaries. The result is less utilised infrastructures, repetitive submission burden, extra overhead e.g. in proposal writing, data collection, steering, and planning uncertainty that undermines long-term scientific programmes.
Outcomes
- Long-term, flexible resource allocation
- Infrastructure-wide allocations and harmonised accounting
- ESFRI roadmaps aligned with e-infrastructure roadmaps
- E-infrastructures aligned with the European Data Strategy
- Short term (1 to 3 years)
- Agree an interoperability framework for resource accounting, with its metrics and roles, and seek EC funding for its design and prototyping.
- Medium term
- Pilot infrastructure-wide allocations, deploy testbeds of the accounting system, and put memoranda of understanding in place.
- Long term
- A federated, flexible allocation process widely adopted, with standardised accounting used in production.
Actions by stakeholder
Scientific communities and research infrastructures
- State computing needs several years ahead: workflows, storage, data access patterns and network requirements.
- Use the information that federated accounting aggregates.
E-infrastructures and service providers
- Make resource allocations and quotas usable across the whole e-infrastructure.
- Agree federated accounting metrics and checkpoints with communities and research infrastructures, and implement the sensors.
- Sign MoUs with funding bodies and research communities.
Policy makers and funding bodies
- Set clear multi-annual funding plans that match infrastructure evolution to scientific needs.
- Sign MoUs with service providers and research communities.
Key dependencies (Table 6.4.1):
Enables:
In the Technical Blueprint (from SRIDA Annex C.4):Resource FederationMonitoring and Observability
› › P03
P03 Federated Identity and Trust
Why it matters
Federated identity and trust infrastructure enables researchers to access heterogeneous computing and data resources across organisational and national boundaries. Without seamless, secure authentication and authorisation, the compute and data continuum vision remains unattainable. This priority provides the technical identity layer that makes cross-infrastructure workflows executable and data FAIR-compliant. The challenge spans both compute and data access:
Outcomes
- Unified authentication and workflow automation
- FAIR data access and trust framework governance
- Short term (1 to 3 years)
- Bootstrap trust governance, agree operational KPIs, and review the site policies that block service accounts.
- Medium term
- Harden the trust framework, enable agentic access with community-coordinated authorisation, and coordinate security across participants.
- Long term
- GDPR handled as a normal operational capability, not project by project.
Actions by stakeholder
Scientific communities and research infrastructures
- Identify the requirements for accessing federated HPC, HTC and cloud infrastructure.
- Agree European standards with other communities and the service providers.
- Provide use cases that show the benefit of an integrated infrastructure.
E-infrastructures and service providers
- Define the new federated access policies together with the scientific communities.
- Adapt local AAI policies to the communities' needs, within their own security policies.
Policy makers and funding bodies
- Recognise the value of a European federated HPC, HTC and cloud infrastructure for research and innovation.
- Plan funding for both the federated services and the compute resources they give access to.
Enables:
In the Technical Blueprint (from SRIDA Annex C.4):Security and TrustResource Federation
› › P04
P04 Heterogeneous Computing Integration
Why it matters
The compute continuum (seamless integration of HPC, HTC, Cloud, edge, and emerging quantum resources) is essential for data-intensive science operating at exabyte scales. HL-LHC will generate 1 EB/year requiring processing across heterogeneous resources (D5.1), whilst SKA Observatory distributes 700 PB/year to regional centres requiring diverse computational capabilities (D5.1). Scientific workflows increasingly require combinations of high-throughput batch processing, high-performance simulation, interactive analysis, and accelerated computing that no single resource type can optimally provide.
Outcomes
- Standardised integration policies across European HPC and HTC centres and cloud providers
- Seamless workflow execution across the compute continuum
- Short term (1 to 3 years)
- Agree a common descriptive language over the domain ontologies, build on initiatives such as the EuroHPC Federation Platform, and start prototypes.
- Medium term
- First API-based access across EuroHPC, EGI and cloud providers, demonstrated on HTC, batch, AI training and inference use cases.
- Long term
- A unified federation across HPC, HTC and cloud providers, built on the lessons of the earlier phases.
Actions by stakeholder
Scientific communities and research infrastructures
- Adapt workflows and codes to use the federated compute continuum efficiently, HPC above all.
E-infrastructures and service providers
- Align policies and protocols.
- Make federation fit the funding models.
Policy makers and funding bodies
- Provide political agreement, a legal framework and funding.
Key dependencies (Table 6.4.1):
Enables:
In the Technical Blueprint (from SRIDA Annex C.4):Compute ResourcesOrchestration and Workflows
› › P05
P05 Data Management and Transport
Why it matters
SPECTRUM use cases are based on the acquisition and processing of very large amounts of data. The structure of the data (their architecture) and their management are fundamental to European e-Infrastructure competitiveness. The capability to store data and efficiently transport them to HPC centres is essential for HEP and RA communities, whilst native management according to FAIR principles enables cross-domain research and Open Science.
Outcomes
- Federated FAIR data management
- Automated data movement at scale
- Short term (1 to 3 years)
- Select pilot use cases through a gap analysis, identify the critical interfaces, and evaluate architectures for federated FAIR storage.
- Medium term
- Demonstrate integrated FAIR data management across infrastructures, validated for exabyte-scale volumes.
- Long term
- Roll out federated data management and automated transport across European e-infrastructures, onboarding new communities.
Actions by stakeholder
Scientific communities and research infrastructures
- Co-design federated FAIR data architectures, with interoperable metadata standards and provenance models.
- Provide domain requirements for data retention, curation, sensitivity and access.
- Adopt harmonised interfaces and join pilot and validation campaigns.
E-infrastructures and service providers
- Deploy federated storage with unified namespaces and policy-controlled access.
- Provide automated, high-performance data transfer integrated with workflows.
- Provide secure environments for sensitive data, aligned with GDPR.
Policy makers and funding bodies
- Keep investing in pan-European research networks such as GÉANT.
- Support FAIR-aligned infrastructure and long-term preservation facilities.
- Coordinate the rules for cross-border data management: GDPR, FAIR metrics and EOSC policies.
Key dependencies (Table 6.4.1):
Enables:
In the Technical Blueprint (from SRIDA Annex C.4):Data ResourcesMonitoring and Observability
› › P06
P06 Workflow Orchestration and Management
Why it matters
Scientific workflows are becoming increasingly sophisticated. Advanced workflow management systems capable of orchestrating multi-step processes across distributed resources and domains, ensuring data locality, and optimizing resource utilization, are therefore needed. Unifying workflow environments is crucial for sustaining and expanding innovative approaches such as AI-based workflows. Automated workflow tools are needed to streamline updates and deployments of e.g. AI models in real-time applications. Mixed workloads that combine embarrassingly parallel tasks with tightly coupled AI/ML processes must also be supported. Modern systems must adapt to support this diversity by providing heterogeneous architectures that integrate CPUs, GPUs, and high-speed interconnects. Streamlining workflow software and using automated workflow management for orchestrating, monitoring, accounting, is also important to reduce operational overhead and maximise resource utilisation
Outcomes
- Cross-facility orchestration with built-in resilience and provenance
- Scheduling and orchestration for interactive computing
- User interfaces that open workflows to a broader research community
- Short term (1 to 3 years)
- Continue the gap analysis on selected use cases, identify the critical interfaces, and pilot use cases (HEP, SRCNet, LOFAR).
- Medium term
- Prototype and demonstrate with e-infrastructure providers, validate, and draft the standards each stakeholder follows.
- Long term
- Roll out across European e-infrastructures and grow the communities that build on it.
Actions by stakeholder
Scientific communities and research infrastructures
- Co-design and converge with the service providers on a few interoperable workflow systems, with unattended execution, provenance tracking and cross-infrastructure orchestration.
- Extend scheduling and orchestration to interactive use.
E-infrastructures and service providers
- Co-design and converge with the communities on a few interoperable workflow systems.
- Extend scheduling and orchestration to interactive use.
- Support domain-specific user interfaces through service hosting and integration APIs.
Key dependencies (Table 6.4.1):
Enables:
In the Technical Blueprint (from SRIDA Annex C.4):Orchestration and WorkflowsCompute Resources
› › P07
P07 AI
Why it matters
AI methods are reshaping HEP and RA workflows across simulation, reconstruction, calibration, analysis, and instrument operations: pre-trained models at the LHC trigger classify collision events in real time, AI at telescope edges detects astrophysical transients within milliseconds, and digital twins model detector radiation damage, alignment shifts, and telescope-array calibration drift. ML-based fast simulation has demonstrated two-to-three orders of magnitude computational cost reduction for high-impact HEP and RA use cases whilst maintaining scientific accuracy. The European AI moment is open: the AI Continent Action Plan commits over €20 billion to AI infrastructure, AI Factories enter operations in 2025-2026, AI Gigafactories are proposed at €100 million-plus per site, and the AI Act sets the regulatory baseline. With a Commission-estimated European compute capacity gap of around 20 GW by 2036 and three hyperscalers holding roughly 70% of the European cloud market, sovereign-supply development is a load-bearing dimension of the build-out. HEP and RA must be part of this effort or risk being structurally side-lined; GPU resources are not yet accepted as "pledged" allocations for LHC experiments, exposing a structural gap between AI demand and the resource accounting frameworks that fund scientific computing.
Outcomes
- AI-enabled scientific workflows
- Sustainable AI capability
- HEP and RA strategically positioned in the EU AI programme
- Short term (1 to 3 years)
- Secure HEP and RA representation in RAISE, assess which tasks suit ML acceleration or need FP64, and pilot AI platforms, federated learning and agents under oversight.
- Medium term
- Integrated cloud and HPC access for larger AI workloads, GPUs accepted as pledged resources, and agent-mediated workflows in operation.
- Long term
- A production-grade, federated AI/ML environment across the continuum, with provenance, co-design and governance.
Actions by stakeholder
Scientific communities and research infrastructures
- Identify workloads suited to AI acceleration and those that need sustained FP64, as input to HPC and AI Factory procurement.
- Drive FAIR adoption for models and training processes.
- Contribute HEP and RA use cases to SCIANCE and coordinate federated-learning pilots across sites.
E-infrastructures and service providers
- Integrate AI platforms across the continuum, from EuroHPC and AI Factories to EGI, WLCG and SRCNet.
- Reconcile community AAIs with AI Factory access.
- Offer elastic allocation for AI workloads alongside batch, and host and federate model registries.
Policy makers and funding bodies
- Steer coherent EU and national investment across the AI continuum.
- Include HEP and RA precision needs in procurement, with multi-year compute allocations (P02).
- Ensure coordination across DG RTD, DG CNECT and DG GROW.
Key dependencies (Table 6.4.1):
In the Technical Blueprint (from SRIDA Annex C.4):AI/ML and HPC ApplicationsCompute Resources
› › P08
P08 Software Portability
Why it matters
SPECTRUM envisions a European Compute and Data Continuum, which will enable research infrastructures and researchers to access and use the most appropriate data centre for any given task in hand. For example, the choice of centre may depend on data locality, connectivity, availability of specialist hardware, or simply on the distribution of load across the continuum. Users will benefit from seamless access to the most effective and efficient e-Infrastructures to address their needs.
Outcomes
- Software and workflows that move between centres with minimal adaptation
- Software that uses a wide range of accelerators with minimal effort
- A more efficient continuum with less implementation overhead
- Short term (1 to 3 years)
- Analyse gaps in portability tools, document common software stacks, and adopt containers more widely.
- Medium term
- Provide tooling and documented standards for portability, publish stacks in common repositories, train people and set up governance.
- Long term
- All appropriate software published to the standards, which are kept up to date, with sustained support for key technologies.
Actions by stakeholder
Scientific communities and research infrastructures
- Define the scientific requirements and use cases.
- Develop software for portability and reuse, and distribute it through standard repositories.
- Incentivise and support portable software, with training and software repositories.
E-infrastructures and service providers
- Develop common standards and tools for software portability.
- Make the service offering comply with these standards and support standard environments.
Policy makers and funding bodies
- Set strategic goals that recognise the importance of software portability.
- Ensure structural funding for key enabling technologies.
Key dependencies (Table 6.4.1):
Enables:
In the Technical Blueprint (from SRIDA Annex C.4):Software Distribution and Execution
› › P09
P09 Open Science and Reproducibility
Why it matters
Open Science and reproducibility are fundamental pillars of modern scientific practice, ensuring that results can be independently verified, reused, and built upon across domains. As European scientific communities move toward exascale data volumes and increasingly complex AI-enhanced workflows, the ability to preserve, share, and reproduce results becomes both more challenging and more essential. In an environment where scientific discovery is data-driven, collaboration-intensive, and reliant on heterogeneous infrastructures, reproducibility emerges as a prerequisite for trust, transparency. Evidence from major SPECTRUM research communities shows that only infrastructures with FAIR-by-design principles, robust provenance tracking, and transparent workflow environments can support long-term scientific value and compliance with open science mandates. For SPECTRUM, Open Science and reproducibility are core enabling conditions for a truly interoperable, cross-domain compute and data continuum. They ensure that scientific knowledge generated in Europe remains accessible, verifiable, and re-usable across communities and generations of infrastructure and crucial way to ensure European sovereignty for research outputs including data, research software and workflows
Outcomes
- Workflows and results that stay reproducible for many years, preserved with their computational context
- Short term (1 to 3 years)
- Consolidate guidelines for FAIR, reproducible workflows, provide shared execution environments, and train all stakeholders.
- Medium term
- Align interoperability standards across EOSC, EuroHPC and ESFRI, offer FAIR-by-design services across borders, and bring Open Science into curricula.
- Long term
- FAIR policies enforced for publicly funded research, with long-term funding for data and software preservation.
Actions by stakeholder
Scientific communities and research infrastructures
- Implement FAIR and reproducible workflow guidelines, contributing domain metadata, standards and workflow definitions.
- Provide domain FAIR repositories with provenance tracking, for the long-term curation of data and software.
- Share best practices across communities.
E-infrastructures and service providers
- Provide execution environments and containers that support reproducibility and capture provenance.
- Offer common workflow engines, with reproducibility checks built into compute environments.
Policy makers and funding bodies
- Fund data and software preservation for the long term.
- Require FAIR standards in publicly funded research.
- Support governance frameworks for Open Science and reproducibility.
Key dependencies (Table 6.4.1):
Enables:
In the Technical Blueprint (from SRIDA Annex C.4):Software Distribution and ExecutionData Resources
› › P10
P10 Software Preservation and Sustainability
Why it matters
Software is as essential as data in enabling scientific discovery of data-intensive and compute-intensive domains such as HEP and RA. Software environments are becoming increasingly complex, tightly coupled to specific hardware, and subject to rapid technological change. Without long-term preservation strategies, scientific results cannot be reproduced, validated, or reused. SPECTRUM’s vision of a federated, cross-domain compute and data continuum depends on stable, portable, and durable software artefacts. Software preservation ensures continuity across successive generations of HPC/HTC/Cloud architectures and enables reproducible science at scale. It reduces technical debt, enhances operational efficiency, and supports scientific autonomy by maintaining Europe’s ability to re-run, verify, and extend past analyses
Outcomes
- A Europe-wide ecosystem of archived, portable and reusable software
- Short term (1 to 3 years)
- Include preservation in software management plans, promote open source and open standards, and harmonise execution environments.
- Medium term
- Community container images and stacks that stay executable across hardware generations, with sustainability planned into research programmes.
- Long term
- Long-term funding for software preservation, and recognised career paths for research software engineers.
Actions by stakeholder
Scientific communities and research infrastructures
- Define domain preservation needs and share best practices.
- Adopt common containers and workflow formats.
- Provide domain repositories with sound metadata, and integrate software and workflows into preservation systems.
E-infrastructures and service providers
- Maintain harmonised software stacks.
- Build and preserve container environments.
- Offer long-term archival services.
Policy makers and funding bodies
- Provide long-term funding and set sustainability mandates.
- Align programmes across EOSC, EuroHPC and national schemes.
Key dependencies (Table 6.4.1):
Enables:
In the Technical Blueprint (from SRIDA Annex C.4):Software Distribution and Execution
› › P11
P11 Community Collaboration and Co-Design
Why it matters
Community management is strategically important because it enables HEP, RA and other data-intensive communities to align around shared priorities, move from fragmented initiatives to a coherent roadmap, and support innovation, interoperability and long-term sustainability in the European compute and data continuum. Building on the SPECTRUM CoPe and existing networking structures, it must go beyond coordination alone by also addressing human-capacity needs, including stable roles, recognised responsibilities, organisational incentives, and retention of key engineering and software expertise. It should also ensure continuity beyond individual projects and maintain structured links with international partners, as major infrastructures operate in a global ecosystem.
Outcomes
- Bridges with similar multidisciplinary initiatives, for long-term alignment and collaboration
- Short term (1 to 3 years)
- Strengthen the Community of Practice and its charter, ensuring its continuity after SPECTRUM.
- Medium term
- Coordinate, and possibly converge, with similar initiatives in related research domains.
- Long term
- Keep coordination and strategic alignment across the wider network of scientific communities.
Actions by stakeholder
Scientific communities and research infrastructures
- Dedicate resources to identifying technical needs, and name the people who coordinate this work.
- Collaborate with other communities as a structured Community of Practice, and with e-infrastructures on technical developments.
- Allocate dedicated expertise to community-led initiatives across research infrastructures.
E-infrastructures and service providers
- Evaluate operational and funding schemes together with research infrastructures and scientific communities.
Policy makers and funding bodies
- Facilitate coordination between communities, research infrastructures and service providers.
- Fund joint development through dedicated, long-term schemes.
Enables:
Pillar 4 priorities are enabling conditions for all the others.
In the Technical Blueprint (from SRIDA Annex C.4):Resource Federation
› › P12
P12 Environmental Sustainability
Why it matters
Energy use has recently become a limiting factor for HPC due to the difficulty of procuring MW, cost and cooling issues. It is, however, just the tip of the iceberg as, in the current context of global warming, collapse of biodiversity and gradually exceeding planetary limits, environmental impacts of IT are significant and need to be reduced at the European scale to fulfil the Paris agreement. Conversely, large science projects, in the HEP and RA domains for instance, call for increased use and growth of HPC infrastructures and will face the challenge of doing more with fewer impacts to be environmentally, politically and socially acceptable. This is not simply a matter of improving the efficiency of the processes, although this will help, but of gaining control over the different impacts of IT in order to allow it to fit in schemes to globally reduce mankind's impacts. A holistic approach is required as science moves into the era of big data and because of the exponential adoption of AI to ensure scientific computing can continue responsibly in spite of the growing environmental pressure.
Outcomes
- Forecast and reporting of environmental impacts
- Improved software quality
- Improved efficiency of execution
- Lifecycle extension
- Short term (1 to 3 years)
- Put available solutions into practice to reduce IT's environmental impact, and plan and test the change of paradigm.
- Medium term
- Consolidate the measures into wide-scale practice, and test the more complex ones.
- Long term
- All measures consolidated and in practice, monitored continuously and adapted to new systems.
Actions by stakeholder
Scientific communities and research infrastructures
- Train users to write low-impact software and use resources mindfully.
- Contribute to sustainability governance and to data and software reuse.
- Count computing's environmental impact in the research infrastructure's overall assessment.
E-infrastructures and service providers
- Manage the infrastructures' overall environmental impact.
- Allocate each end user's share of that impact as credits.
- Help users and policy makers track and manage it.
Policy makers and funding bodies
- Set an environmental impact budget for the compute and storage continuum.
- Evaluate sustainability governance.
Pillar 4 priorities are enabling conditions for all the others.
In the Technical Blueprint (from SRIDA Annex C.4):Monitoring and Observability
› › P13
P13 Skills, Careers and Training
Why it matters
HEP and RA research has become computing intensive, at least since three decades. Large infrastructures and large investments are needed to collect, store and analyse the datasets produced. This requires dedicated teams of experts with specific skills and capabilities to design and operate the required computing systems and software stacks; failing that, the expected impact is a reduced physics exploitation capability for the planned billion Euro investments. In many cases critical pieces of software depend on individuals or small groups of people often in non-permanent positions. Together with workforce ageing, migration to industry and lack of recognition for research software engineering work, this poses a risk to research.
Outcomes
- Recognised career paths for research computing experts
- Training needs fed back to universities and engineering schools
- Short term (1 to 3 years)
- Raise awareness among academic and research partners of the need for good careers for computing experts, through current initiatives.
- Medium term
- Structural change in education and recognition, through new project proposals and university curricula.
- Long term
- Reshape funding and personnel policies in academic and research institutions.
Actions by stakeholder
Scientific communities and research infrastructures
- State present and future computing needs, including expert staff and the risk if posts stay vacant.
- Communicate the challenges to be solved, and how experts can influence scientific results directly.
- Ensure sufficient staffing for smooth operations.
E-infrastructures and service providers
- Train researchers in the efficient use of heterogeneous resources: GPUs, containers, portability and sustainable operations.
- Offer secondments for Research Software Engineers in operational centres.
- Connect user communities with industry partners to show further career paths.
Policy makers and funding bodies
- Fund computing research positions in academia and research institutes.
- Ensure career paths for the people who design and operate computing systems.
Enables:
Pillar 4 priorities are enabling conditions for all the others.
In the Technical Blueprint (from SRIDA Annex C.4):Resource Federation
About the SRIDA
The SRIDA is SPECTRUM's strategy for a European compute and data continuum for data-intensive science. It starts from the needs of High Energy Physics (the HL-LHC and WLCG) and Radio Astronomy (the SKA Observatory and LOFAR), whose instruments coming online over the next decade will generate data and processing demands an order of magnitude beyond current capacity. Other disciplines share the same challenges: exabyte-scale data, heterogeneous computing, federated access, AI adoption, environmental sustainability and skills.
Its thirteen priorities, grouped in four pillars in the map above, set out what scientific communities, service providers and policy makers each need to do. Investment covers five areas: computing infrastructures, data infrastructures, software and tools, governance and coordination, and human capital.
The roadmap runs in three phases: foundations in years one to three (governance, federated identity, standard interfaces), integration in years three to five (heterogeneous computing, federated data, workflow orchestration at scale), and maturity after that (AI in production, end-to-end reproducibility, stable careers in research computing).
The SRIDA builds on the Technical Blueprint (D6.1), which sets out the architecture, on SPECTRUM's analyses of use cases (D5.1), access policies (D5.2) and existing infrastructures and their gaps (D5.3), on the Community of Practice (D3.1), and on a public consultation.