Skip to content

GCRI · How Nexus works

Build

The build step turns a framed question and its evidence into a governed analytical product. That means versioned data, a model or pipeline with stated assumptions, and a record of who may run it and on what terms.

Make an enquiry Back to How Nexus works
01Contents

Build in six parts.

In this dossier6 parts
  1. 01Six pillarsThis step runs in Foundry
  2. 02What a build isAn analysis that can be rerun, inspected and challenged
  3. 03AssuranceThe checks a build passes before anyone relies on it
  4. 04Across the institutionsEach pillar’s contribution
  5. 05NextThen: organise
  6. 06SourcesWhere this page’s references lead
02Six pillars

This step runs in Foundry.

Where methods, data and models become reproducible builds, each run with its inputs, version and limits on record. Go to Foundry.

Select pillars · hover lines18 / 18 handoffs

Route

Around Foundry

The pillars Foundry hands work to and receives it from.

L · F · U · S · R · A

Pillars
6 of 6
Handoffs
18 of 18
Loops
17 closed

Handoffs in play

  • F01Universe → Foundry · Admitted mission becomes a cycle project with a decision caseReadiness preparation
  • F02Foundry → Universe · Core Build Report and go or no-go evidenceControlled build
  • F03Foundry → Reports · Sealed observations and indicator series behind a profileCloseout
  • F04Universe → Reports · After-action and scenario findings for chapters 10 and 13After-action review

and 14 more

F01 to F14 are the recorded handoffs of the programme year, each with the artefact that moves and its phase; R1, R2, R3 and R4 carry work around the ring. A loop counts when every pillar on it is selected. Every pillar is led by the Nexus Consortium.
  1. LabsWhere questions become experiments and prototypes: new methods, data and tools are tried in the open, with their limits on record, before the Foundry builds them, under the Nexus Consortium.Labs at GCRI: Labs
  2. FoundryWhere methods, data and models become reproducible builds, each run with its inputs, version and limits on record.Foundry at GCRI: Foundry
  3. UniverseWhere a build is tested under controlled conditions with independent evaluators, so a method’s skill is measured, not assumed.Universe at GCRI: Universe technical officeuniverse.nexus
  4. Nexus StandardsWhere methods, identifiers and data schemas are codified in the open and corrected when a test finds a fault.Nexus Standards
  5. ReportsWhere findings are published with their method, uncertainty and evidence class, and corrected as new versions.Reports at GCRI: PublishReports
  6. Risk AcademyWhere methods and systems are taught on real data and real places, by working the case, on Risk Academy.Risk Academy
03What a build is

An analysis that can be rerun, inspected and challenged.

A build in Foundry is not a dashboard. It is the set of inputs, code, parameters and outputs that produced a result, held so that a reviewer can rerun it and get the same answer, or see exactly why not. That is the reproducibility test applied to models used in public decisions, and the condition under which a finding can be corrected rather than argued about.

  • Inputs pinned to a version in the source register, with licence and provenance.
  • Methods traced to their canonical page in the STEM Commons.
  • Assumptions written beside parameters, not in a separate memo.
  • Outputs carrying their evidence label (modelled, scenario, forecast) all the way to publication.
04Process

How the process runs.

Process

Build: Build, sign and accept

An admitted mission becomes a cycle project; the build is pinned, verified and signed, and the Global Risks Forum (GRF) records acceptance for exercise, not permission to deploy.

  1. 01 Request and sources

    1. 01Admitted mission becomes a cycle projectRecord · Universe to FoundryAn admitted mission becomes a cycle project with a decision case.
    2. 02Qualify data sources and resourcesStep · the Global Centre for Risk and Innovation (GCRI)GCRI qualifies data sources and resource offers and builds the scenario models. An offer is not an allocation.

  2. 02 Build and verify

    1. 03Source snapshotRecord · NXS-FAC (blueprints, builds and signing)The snapshot pins the commit, dependencies and generator versions.
    2. 04Build contractRecord · NXS-FAC (blueprints, builds and signing)The build contract declares the artefact kind, environment and reproducibility envelope.
    3. 05Integrate and buildModel · GCRIGCRI integrates software and data, signs builds, and tests security and interoperability.
    4. 06Verification suiteGate · NXS-FAC (blueprints, builds and signing)Required and advisory checks stay separate. Reproducibility needs pinned inputs, declared nondeterminism and independent rebuilds.

  3. 03 Sign and admit

    1. 07Sign the exact artefactStep · NXS-FAC (blueprints, builds and signing)NXS-FAC builds, attests and requests a signature via a scoped signer identity. It holds no key material.
    2. 08Package admissionStep · NXS-NXQ (software, models and capability lifecycle)NXS-NXQ receives the signed package and keeps admission evidence that binds the task, data class, evaluation suite and expiration.

  4. 04 Accept

    1. 09Core Build ReportRecord · GCRIThe Core Build Report is the go or no-go record. Universe assembles the Core and holds the decision for the exercise.
    2. 10G3 · Build accepted for exerciseGate · The Global Risks ForumGRF records whether the build is accepted for exercise. A signed build or release candidate is not permission to deploy to production.

The programme year · NXS-FAC · UniverseDesigned programme process, not a record of operation. No cycle has run and every programme is at service level R0. A gate is a programme decision, never a public-authority approval, certification or deployment authorisation. The record order follows the Builds and Releases room lists of NXS-FAC.

05Assurance

The checks a build passes before anyone relies on it.

CheckReference practice
Model risk: purpose, limits, validationModel risk management practice, read against ISO 31000 treatment of uncertainty
AI componentsNIST AI RMF functions (govern, map, measure, manage) and ISO/IEC 42001 management-system controls
Information securityNIST CSF 2.0 functions, including the govern function added in version 2.0
Data protectionPurpose limitation and minimisation under the applicable privacy law of the data’s origin

Who may build is set by an authorised project with an accountable owner. Access requests start at Foundry contact.

06Across the institutions

Each pillar’s contribution.

07Next

Then: organise.

Organise: nexus ecosystem: community, chapters, councils, national cells

08Sources

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.

The Global Centre for Risk and Innovation

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.

Propose a method See all contact routes
Legal

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.

Privacy choices