The Global Centre for Risk and Innovation (GCRI)
Risk analysis needs compute in very different places: a large cloud allocation for a national ensemble, a ministry's own servers for records that may not leave, a field laptop that keeps a model running when the network fails. This page sets out how compute risk develops, from capacity shortfall and concentration in a few providers to jurisdiction, energy and degraded connectivity, and how cloud, local nodes and edge devices are designed to be scheduled as one capacity.
GCRI · Established · service level R0
Compute capacity for risk analysis is the processing available where and when models must run: cloud allocations for national ensembles, an institution's own servers for records that may not leave, and field devices that keep working when networks fail. Its risks include shortfall during events, concentration in few providers, jurisdiction and energy use.
Urban demand centres and the hubs that anchor digital and data infrastructure, shown for Europe as an example geography for this subject.
Cloud, local nodes and edge technical capacity. The dossier below sets out how the risk develops, what is measured, where the data come from, how it is modelled and who decides.
Demand for compute peaks during events, exactly when shared capacity is contested, networks are degraded and power is unstable. Queues lengthen, ensembles shrink and forecasts arrive after the decision window has closed.
Many institutions rely on a few cloud providers, regions and chip suppliers. An outage, sanction, price change or supply shortage reaches all of them at once, which makes compute concentration a systemic dependency in its own right.
Where data may be processed is set by law and contract. Moving analysis to the data keeps records in place, but constrains which methods can run and can still leave results open to inference about the inputs.
Edge nodes keep working offline and reconcile later. Conflicting edits, clock skew and stale models accumulate during an outage, and reconciliation after a long disconnection may need human judgement rather than an automatic merge.
Each term as this page uses it. Where a standard-setting body defines the term, the wording follows that body.
| Term | Definition |
|---|---|
| Data residency | A requirement that data be stored and processed within a stated jurisdiction. |
| Edge computing | Processing data close to where it is produced or used rather than in a central data centre. |
| Federated analysis | Sending analysis to data held in separate locations instead of copying the data to one place. |
Each indicator carries its unit, its cadence, the kind of source behind it and the evidence label a value would carry. No values are shown: a programme supplies them under its own authority.
| Indicator | Unit | Cadence | Source type | Label |
|---|---|---|---|---|
| Queue wait time | minutes, median and tail | daily | Scheduler accounting | OBSERVED |
| Service availability | proportion of scheduled time | monthly | Availability monitoring | OBSERVED |
| Workloads placed outside permitted jurisdiction | count | per placement | Placement policy logs | OBSERVED |
| Edge reconciliation conflicts | count per resynchronisation | per event | Synchronisation logs | OBSERVED |
| Energy use per workload | kilowatt-hours | per run | Power telemetry or provider estimates | ESTIMATED |
| Carbon intensity of electricity used | grams CO2 equivalent per kilowatt-hour | hourly | Grid operator and provider data | ESTIMATED |
| Capacity offered against capacity allocated | core-hours or GPU-hours | monthly | Offer and allocation register | DECLARED |
| Recovery time in failover exercises | minutes | per exercise | Exercise records | OBSERVED |
The topic as a computational graph: named sources feed the methods, an evidence review gates the outputs, and the decisions stay with the authorities that hold them.
Fig. 02Nodes carry their type, two metric rows and a state; connectors show what feeds what; dashed frames name the owners; the timeline is the cadence. Design of the pipeline, not a record of a run.
Named public datasets and institutional records, each with its licence class. Sources by agreement are used only under their terms and never republished.
| Source | What it gives | Licence class |
|---|---|---|
| TOP500 and Green500 lists | Published performance and energy efficiency of large systems | Free, terms of the project |
| Ember electricity data | Generation mix and carbon intensity of electricity by country | CC BY 4.0 |
| Copernicus Data Space Ecosystem | Earth observation archives with processing next to the data | Free and open, attribution |
| NASA Earthdata Cloud | Earth science archives in cloud object storage for in-region analysis | Free and open, NASA data policy |
| Public cloud region and status records | Region locations, availability history and incident reports | Provider terms |
| Kubernetes release and deprecation records | Version support windows and API removals that affect workload portability | CC BY 4.0 |
Nexus Foundry prepares evidence. The decisions below are taken by the authorities named, under their own rules, and never by the platform.
| Who decides | The question | Evidence this page serves |
|---|---|---|
| Data owners and data protection authorities | Where data may be processed, and whether results may leave | Placement logs, the jurisdiction of each tier, federated execution records |
| Project owners | How to prioritise workloads within an allocation during an event | Queue state, allocation remaining, deadlines |
| Infrastructure contributors and operators | What capacity to offer and on what terms | Offer register, utilisation, energy and support load |
| Ministries responsible for digital infrastructure | How far national risk analysis depends on foreign or concentrated providers | Provider and region dependency map; exit and failover plans |
NEXCORE is designed as the compute control plane across cloud, private infrastructure and edge. Workloads are packaged with their dependencies so they can run on any tier that the project's policy allows, and the scheduler places them according to data location, sensitivity, cost and urgency. Where data cannot move, the analysis is designed to run where the data is held and only permitted results leave.
Edge capacity matters most when it is hardest to provide: during the events risk work is about. Field kits, observatory nodes managed through OP and offline operation of NorthStar are designed so that coordination continues through outages, synchronizing when connectivity returns. Energy use, cooling and hardware supply are part of the engineering, and the platform's computing questions connect to the energy and data-centre analysis at Data and Compute.
Federated execution keeps sensitive data in place and moves code and permitted results.
Edge nodes continue locally and reconcile later, with conflicts flagged rather than silently overwritten.
Contributed infrastructure is recorded as an offer until it is separately allocated.
Limits: federated analysis constrains which methods can run, edge devices have little capacity, and reconciliation after long disconnection can need human judgement. No hardware specifications are summed into performance claims.
The current service level is R0: information and enquiries. An enquiry receives a reference and names the next step; applications, payments, compute allocations and registrations open only when their team, terms and review capacity exist.