GCRI · Foundry
Compute and edge
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.
Compute and edge on the record.
Compute and edge: how the risk develops.
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.
Capacity fails when needed
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.
Concentration
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.
Jurisdiction and data location
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.
Disconnection and reconciliation
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.
How compute and edge is modelled, measured and tested.
The model, its assumptions, its data and its uncertainty, in the form a scientist or engineer would check. Structures follow published methods. The values drawn are illustrative, not findings.
Model, equations and assumptions
The model structure used for compute and edge, the assumptions it makes and how each is tested.
Ri = f(Hi, Ei, Vi, Ci)hazard, exposure, vulnerability and coping capacityEAL = ∑k pk · Lkover events k with annual probability pkxt+1 = A xt + B ut + εtA carries the couplings, u the shock, ε the error| Assumption | Why it is made | How it is tested |
|---|---|---|
| Hazard and exposure are independent within an event | Keeps the loss integral tractable | Compare with a copula fit on joint records |
| Couplings are linear near the operating point | Lets shocks propagate through A | Perturb beyond the linear range and compare |
| Vulnerability curves transfer between places | Local curves are rarely available | Validate against observed losses where they exist |
- Inputs
- versioned datasets with provenance
- Outputs
- distributions, never single numbers
- Code
- released with the model card and tests
- Reproduction
- same data, code, environment and seed
Compute is designed to serve each domain’s heaviest models.
Compute readiness is designed for the Foundry Build and Readiness series. Energy efficiency is reported with ISO/IEC 30134 indicators; no hardware specifications are summed into performance claims.
- Workload profiles.
- Efficiency measurements.
What is measured, and how well.
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 |
Where the evidence comes from.
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 |
Who decides, and what the evidence serves.
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 |
Outputs this topic produces
- Placement policies by data class, jurisdiction, urgency and cost
- Workload packages portable across cloud, private and edge tiers
- Failover and degraded-operation runbooks with exercise records
- Register of capacity offered, allocated and used, kept apart
What computing engineers and data owners ask.
- Where is the data legally and contractually allowed to be processed?
- Which workloads need burst capacity, and which need steady, local availability?
- How does work continue when connectivity is degraded or lost?
- How is offered capacity distinguished from capacity actually allocated and used?
One control plane across three tiers.
NXS-COR (compute, nodes and runtimes) 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 NXS-OPS (instruments, sensors and calibration) and offline operation of NXS-NST (civilian common operating picture) are designed so that coordination continues through outages, synchronising 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.
What is engineered, and what remains hard.
Compute to data
Federated execution keeps sensitive data in place and moves code and permitted results.
Degraded operation
Edge nodes continue locally and reconcile later, with conflicts flagged rather than silently overwritten.
Offer is not allocation
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.
How it is studied, and what the methods cannot say.
- 01High-performance, cloud and edge computingEnsemble scheduling across tiers · Federated execution next to the dataApplied here
- 02Systems engineeringCanonical system inventory · Contract-first interfaces · Requirements traced to evidenceApplied here
- 03Software and safety-critical systems engineeringFail-closed policy gates · Build provenance and bills of materials · Assurance casesApplied here
- 04Data engineering, interoperability and stewardshipValidation at the ingest boundary · Frozen data cuts for reproducible productsApplied here
- 05Geospatial information systemsImagery catalogues through STAC · Exposure overlays with stated aggregationApplied here
Where this page’s references lead.
The bodies and documents this page is read against. Status and editions change; each link goes to the issuing body.
Questions and answers.
Why move analysis to the data instead of the reverse?
What happens to edge work during an outage?
Can my institution contribute servers?
Is energy use reported?
Does membership include compute?
Is any compute allocation open?
Contribute evidence from this page.
Reports is the Consortium’s quarterly publication. What you know about this subject can become evidence, a case or a correction in the next edition, credited to you and published under CC BY 4.0 where it is your own work.
- EmailGateway GW-GCRISend it from this pageEvidence, a correction, a case, a method, a review, a translation or profile input. It arrives tagged with this page, so the editor who owns it receives it.
- ZenodoOpen depositDeposit it and submit to the communityPublish your own record on Zenodo with your ORCID iD, then submit it to the Reports community there. Curators review it; the DOI stays yours.
- ReportsGCRISee every way to contributeThe contribution types, how each is reviewed, what credit you receive, the licence and what is never accepted.
Never send personal data, sensitive infrastructure detail or anything you have no right to share. A contribution is reviewed before use; sending it confers no authorship or editorial rights, and sponsorship never buys a finding.
Bring a method, a dataset or a question.
Information and enquiries are open today. 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.
Legal documents.
Maps, data and figures on this site are shown for context and general information. They are not advice, forecasts or warnings; the limits of the information are set out in the Disclaimers and Data Notices.