Advanced computing: an umbrella with several parts
The phrase “advanced computing” can refer to more than one thing. In European policy, it covers a range of technologies and computing capabilities, while high-performance computing (HPC) describes systems able to tackle calculations or volumes of data that exceed the practical capabilities of conventional computers. Public debate also connects it with quantum computing and the use of large-scale infrastructure for artificial intelligence. Treating these concepts as interchangeable makes it difficult to know what is being funded and what results should be expected.
This distinction also matters when reading announcements and programmes. A general reference to “advanced computing” does not, without further information, establish that a measure concerns the purchase of supercomputers or a specific HPC initiative. First identify what each measure actually covers: the technology targeted, the activities funded and the kind of capability it aims to develop. This helps prevent results associated with one line of work from being attributed to another. It also makes it easier to compare an announcement with the evidence that would be needed to demonstrate progress in that particular area.
The Commission itself presents HPC as a strategic capability for science, industry and public services, not simply as a race to build ever more powerful machines. A useful assessment should follow the entire chain: funding and procurement, installation and operation, user access, and finally scientific or economic outcomes. An initiative announcement establishes a decision or commitment; by itself, it does not show that infrastructure is operational or that its resources are widely used. Each stage answers a different question and requires its own evidence: a budget describes intended resources, whereas operational and usage records can show what happened afterwards. Keeping these stages separate makes it possible to describe progress accurately without treating plans as completed outcomes.
EuroHPC: the joint instrument and what it commits to
The EuroHPC Joint Undertaking is the European mechanism that brings together the Union, participating countries and private partners to develop supercomputing capabilities. Its remit includes procuring and deploying systems, expanding infrastructure and supporting an HPC ecosystem. It is not synonymous with all European digital policy: it is an entity with specific objectives and programmes within a wider agenda. Institutional documents also describe the ambition to strengthen European technological autonomy and competitiveness; these are policy objectives, not outcome indicators.
When attributing an action, it is therefore useful to distinguish the EU’s general digital-policy goals from EuroHPC’s responsibilities and programmes. That precision prevents an assessment from placing distinct initiatives under a single label. It also helps identify which actor publishes the data and which part of the programme those data cover: information from an organisation may be relevant to its remit without necessarily describing every European activity related to computing.
In 2021, the Commission said that EuroHPC’s financial framework for 2021–2027 amounted to around €7 billion, combining contributions from EU programmes, participating states and private members. This figure needs careful interpretation: it represents a planned budget for a period and a set of activities, not necessarily expenditure already incurred, and not an amount devoted entirely to buying machines. To measure implementation, look for data on commitments, payments, contracts and contributions actually received, with comparable dates and definitions. A budget figure is not the same as installed capacity. Nor does it by itself show how resources are divided among activities; that requires further breakdowns and a clear account of which amounts are included.
From goals to observable indicators
Objective-setting language can sound concrete—for example, a goal of having exascale systems—without specifying when they will be available, who will be able to use them or how much scientific and business work they will host. Exascale refers to a performance scale on the order of 10¹⁸ floating-point operations per second. Reaching a theoretical capacity figure does not automatically tell us about sustained performance in real applications, service availability or energy efficiency. It is therefore important to distinguish announced specifications, technical acceptance of a system and continuous operation.
This distinction prevents a feature described in a plan or specification from being presented as an operational result. Technical acceptance indicates that a system has passed a relevant test, while continuous operation concerns its availability as a service over the period in question. Performance in a particular application, in turn, depends on the workload being measured; an isolated technical figure cannot replace that information.
A practical monitoring framework can be organised around indicators that answer different questions:
Indicators for tracking implementation
- Financial implementation: allocated budget, contracted amount and expenditure paid, with the period and source identified.
- Infrastructure: systems procured, commissioning date, reported performance and operational availability.
- Access: open calls, selected projects, eligibility rules and access times.
- Use and outcomes: computing hours consumed, user profiles, and documented publications, developments or applications.
- Sustainability: energy consumption and cooling measures, alongside performance relevant to workloads.
The value of this list lies in the fact that each indicator checks a particular stage, not in reducing them all to one number. To interpret financial implementation, it is necessary to know whether a figure refers to an approved budget, a contract or a payment. For infrastructure, procurement must be distinguished from commissioning. In access and use, counting calls does not on its own reveal how many resources were awarded or whether they were used. Clarifying these units prevents comparisons between measures that answer different questions.
No single indicator tells the whole story. The number of machines does not reveal how many teams can access them; access applications are not the same as computing hours awarded; and allocated hours do not, on their own, prove social or industrial impact. Rigorous comparison requires retaining the definition, coverage and date of each data point, while separating aggregated outcomes from individual cases. These details are essential when comparing periods or systems, because apparent differences may reflect genuine change—or simply different counting criteria.
Access: evidence that the infrastructure is being used
For a university, company or research team, infrastructure becomes practical capability only if there is a usable route to access it. EuroHPC publishes information about access calls and has announced platform changes for that process. This provides an institutional point of reference, but the existence of a call is not enough: its requirements, timetable, assessment mechanism and conditions for running workloads also need to be checked. A platform migration may affect dates or procedures, so published information should be verified when applying.
The conditions of a call determine who may submit an application and how it is handled. Knowing that a call exists is therefore only the first step; assessing whether it is usable also requires checking the current details and taking the stated timetable into account. Platform changes matter in this context because they may alter how applications are submitted or the dates envisaged, although an announcement of a change does not, by itself, establish the outcome of the calls.
An assessment should examine both formal availability and the measurable experience of the user community, without turning anecdotes into general conclusions. Relevant information includes the number of applications and awards, distribution by country and sector, time from application to computing access, and the proportion of resources actually used. When such data are not published comparably, the correct conclusion is not that access does not exist, but that the available public evidence does not allow it to be quantified in sufficient detail. This distinction avoids confusing a transparency gap with a proven negative outcome. It also clarifies what can be said: available information may confirm that procedures have been published without allowing their reach or effective use to be measured precisely.
Cross-checking, limitations and interpreting announcements
Institutional pages are suitable primary sources for understanding EuroHPC’s remit, announced budget and calls issued by the organisation itself. They are not, however, an independent impact evaluation. The material cited here contains no consistent external series that would make it possible to cross-check, across the whole programme, expenditure, actual use and economic benefits. Nor should figures on worldwide data demand be used as a direct measure of a European initiative’s success: they describe context, not outcomes attributable to EuroHPC.
This caution does not diminish the value of institutional sources; it clarifies what they are useful for. They provide evidence of the framework and of the information the organisation communicates, but an impact claim requires data and methods capable of assessing effects. Similarly, a general figure for growing data demand may explain why computing is attracting interest, but it does not identify what share of that context is due to a European programme or what effects the programme produced.
For that reason, the strongest cross-check is to triangulate planning documents with tenders and contracts, commissioning records, access statistics and evaluations published with an explicit methodology. A tender indicates that something is being sought for purchase or contracting; it does not prove that a system has been delivered. An institutional description of a mission establishes the stated objective; it does not by itself show that the objective has been achieved. The value of the analysis lies in labelling each data point according to what it actually demonstrates, rather than adding heterogeneous announcements as if they formed a single measure of progress. To preserve that distinction, each data point should be accompanied by its date, source and scope, so readers can tell whether it describes a forecast, a procedure or an observed outcome.
What would show that the commitment is progressing
Europe’s commitment to HPC is documented as a policy, with an institutional structure, a funding framework and infrastructure and access programmes. To speak of verifiable progress, however, each claim must be linked to an observable milestone: funding spent, a machine accepted and operating, resources awarded and used, or outcomes assessed against public criteria. Timing matters: a commitment approved in 2021 should not be presented as a current result in 2026 without checking what happened in the intervening period.
Monitoring should follow the sequence over time: an announcement establishes what was planned at a particular moment, while subsequent records can show whether a contract was awarded, a system delivered, commissioned or used. Repeating the approval date is not enough to describe the current state. In particular, when assessing a period extending to 2026, it is necessary to verify what later information is available before drawing a conclusion about the present situation.
As a reading guide, when faced with an announcement ask: is it a target, a budget, an award or a delivery? What period does the figure cover? Who can access the system, and under what conditions? Are there usage data and independent evaluations? If answers are unavailable, the wording should preserve that uncertainty. The verifiable conclusion is not that Europe has already achieved a leading position, but that a European programme exists to expand its capabilities and that assessing its effects depends on public implementation and usage data that must be checked separately.