Key4hep: A software framework for future collider studies

by Andre Sailer (EP-SFT), Juan Miguel Carceller (EP-SFT), Gerardo Ganis (EP-SFT)

A Common Foundation

New projects are often the cradle for new ideas and evolution of tools. Software is no exception. Driven by the belief that the high-energy physics (HEP) community was ready to further expand the number and role of shared components between experiments, the Key4hep initiative was launched after the 2019 European Particle Physics Strategy Update (EPPSU) with two founding workshops held in 2019 and early 2020. Its initial focus was the software needed for studies of future HEP facilities, which offered an almost ideal test bed for a more ambitious aim: to increase the use of shared software components across experiments well beyond what had been achieved at the LHC, drawing on the experience of LHC and R&D projects, including the AIDA programmes and the emerging EP R&D initiative.

Designing a future collider means making important design choices long before building a detector: its geometry, technologies and reconstruction strategy must all be tested in realistic simulations. Those studies need a software chain, from event generation and detector simulation to reconstruction and analysis. They are also often carried out by comparatively small teams, and when each proposed experiment assembles and maintains that chain independently, work is duplicated, and results are harder to compare or reuse. Key4hep was conceived to turn this common need into a shared framework, while still leaving each project room to adapt the software to its own detector and physics programme.

Main components and the event data model

As mentioned above, the project started taking shape around 2019, when members of the CLIC, ILC and FCC communities came together to investigate the ground for developing a common software stack for their ongoing studies, building on the experience of earlier shared efforts, the outcome of the LHC developments and of dedicated R&D programs. They identified the components that needed to be covered, the main ones being a common event data model, a detector description tool and a data processing framework providing the structure for integrating and steering all other components. Aside from established products such as ROOT for data storage and analysis, and Geant4 for detector simulation, the initial choice of the main framework fell on Gaudi, because of its adoption by two LHC experiments, its broad user and developer communities, and its maturity as a framework that has evolved to be experiment-agnostic. Its potential for further evolution — including the planned support for heterogeneous computing resources, multiple architectures, and task-based concurrency — was also considered an asset, although in this respect, the experience developed by CMS with CMSSW and possibly by ALICE with O2, was also discussed and will be leveraged in future developments. For detector description, the choice fell on DD4hep, a tool that emerged from the AIDA R&D program, aiming at providing a single geometry description for all the needs of an experiment; in the meantime, DD4hep has been adopted at the LHC by LHCb and CMS. Proper integration with additional tools developed in the community and providing essential functionality, such as event generators, tools providing enhanced reconstruction, e.g. ACTS, or with Machine Learning engines, is of course also provided and/or being developed. 

The common event data model, EDM4hep, became central to the effort, enabling software components and experiment-specific workflows to exchange data consistently. The choice was to use an event data model managed by PODIO, a toolkit that also emerged from the AIDA R&D programme. PODIO generates the data model implementation from templates, separating the high-level description exposed to algorithms from the low-level persistencε layer, which can be optimised for the backend. The data model structures were initially based on the event data models used in previous linear-collider studies (LCIO) and in the initial FCC conceptual studies, and have since been improved as needed. The underlying assumption is that the same event data model can be used across all types of HEP experiments, which is well suited to the integrated FCC programme, comprising a lepton collider followed by a hadron collider. So far, this requirement appears to be met by EDM4hep, although a more definitive assessment will be possible only once FCC-hh investigations cover a broader range of use cases.

Diagram showing the EDM4hep classes and relations used to describe an event from simulation and raw detector data through digitisation to reconstruction and analysis. Arrows indicate different types of relationships between objects.

Key4hep today

The success of a software endeavour can be measured by its adoption. For Key4hep, a clear measure of the initiative’s success was that a substantial share of the studies presented at EPPSU process in 2025 on the physics potential of future colliders relied on its software and tools in one form or another. This is particularly notable given that several components still require further development and optimisation. Key4hep was also the subject of a dedicated submission to the EPPSU process in 2025 [1], highlighting the need to support such initiatives to ensure the long-term sustainability of community software.

The results presented in the FCC Feasibility Study [2] were obtained almost entirely using Key4hep. Contributions from, and adoption by, other communities — including the EIC and Muon Collider communities — are steadily increasing. Compatibility tools have also enabled this by bringing iLCSoft software from the Linear Collider community into Gaudi-based workflows, allowing communities to preserve valuable existing expertise and software while evolving their frameworks.

The shared foundation does not require every project to work in exactly the same way. Experiments can add their own detector models, reconstruction algorithms, and workflows on top of the common components, or adopt only selected parts of the stack. In practice, this makes Key4hep both a technical integration layer and a collaboration framework: common solutions can be improved once and then adapted wherever they are needed.

LEP data preservation in Key4hep

The LEP data represent the most precise and highest centre-of-mass-energy sample of e⁺e⁻ collision data collected to date. These data have long been recognised as potentially playing a crucial role in evaluating the physics potential of FCC-ee. Their overlapping centre-of-mass energies offer a valuable benchmark for detector performance and physics analyses. However, to be truly useful for FCC-ee, the LEP data should be made available in EDM4hep.

This ambitious endeavour would bring two additional benefits. First, migration to a common format accessible through experiment-agnostic tools would mitigate the risk of losing access to LEP data, which currently requires maintaining legacy software stacks while coping with the loss of first-hand expertise. Second, it would allow EDM4hep to confront the real data-structure requirements of experiments — something that experiments still under study cannot provide by construction.

A pilot project investigating the feasibility of this approach has been carried out using ALEPH data, which have already been reanalysed by several users [3]. This demonstrates the community’s interest in making legacy data available in an easily accessible format. The initiative has also attracted interest from the DELPHI and OPAL communities in joining the effort, and a dedicated working group has recently been established within the FCC group in EP.

In the medium and long term, this approach could lay the foundation for a more sustainable strategy for preserving HEP data and the expertise needed to interpret and reuse them — while that expertise remains available.

Conclusion and outlook

Key4hep is now an established project with a proven role in major detector studies. Its greatest value lies in the synergies it creates: improvements in geometry, reconstruction, validation, or deployment developed for one experiment can benefit others, while a broader user community makes the shared components more robust. Further consolidating Key4hep could also significantly impact HEP data preservation, particularly by preserving LEP data and enabling its use in FCC-ee studies.

Together with DESY, the EP department has played a key role in the development of Key4hep since its inception. Initially, this involvement included funding a dedicated task within the software work package of the EP R&D. More recently, Key4hep has been integrated into the SFT group’s Stacks project, with dedicated long-term personnel support.

The next few years will be crucial as future collider projects refine their detector designs and software needs. Continued development and sustained collaboration will be essential to ensure that Key4hep remains a reliable common foundation for these studies.

References    

[1] Key4hep: A Software Framework for Future Colliders, Input to the European Strategy for Particle Physics https://indico.cern.ch/event/1439855/contributions/6461637

[2] Future Circular Collider Feasibility Study Report: Volume 1, Physics, Experiments, Detectors. https://cds.cern.ch/record/2928193. Note: Chapter 8 covers software and computing.

[3] M. Defranchis et al. Modern jet flavour tagging in hadronic Z decays with archived ALEPH data, Journal of High Energy Physics 96 2026, 10.1007/JHEP07(2026)096.