> For the complete documentation index, see [llms.txt](https://docs.therisk.global/organization/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.therisk.global/organization/programme/foundry.md). # Foundry Foundry, the build pillar of the Nexus programme: where the cycle software, data and environments are built, scenarios simulated, evidence sealed and each country’s National Portfolio developed. *Where this fits: applied response. Pillar: Foundry. Institution: GCRI, with the Nexus Consortium. Phases: planning to after-action review. Kind: pillar page.* **In brief.** Foundry is the pillar where the programme builds. It builds the software, data and environments a cycle needs, simulates scenarios and runs benchmarks, monitors hazards, systems and evidence, and develops and tracks each country's National Portfolio. It sends more handoffs than any other pillar: to Nexus Universe the Core Build Report, to Nexus Reports sealed observations and portfolio movement, to [Nexus Standards](/organization/institutions/nexus-standards.md) validation evidence, and to [Risk Academy](/organization/institutions/risk-academy.md) the rooms of each system as learning-by-doing courses. It works on the twenty [Nexus systems](/organization/systems.md), documented as systems in their own part. > **Boundary.** "A configured or simulated capability is not a validated result, and a National Portfolio entry is not an investment decision."
Foundry on the hexagon of the six pillars, with the pillars it hands work to or receives work from selected, every handoff among those pillars, and the phases of the programme year in which recorded handoffs happen. Pillars it exchanges no work with are shown unselected.

The Foundry pillar in the programme. A designed programme cycle, not a record of operation. Handoff identifiers F01 to F14 and R1 to R4 as in the sites' pillar model. Source: the sectors and pillars model published on the GCRI, GRF and GRA home pages, vendored and hash-pinned in tools/figures/vendor/nexus-model. As of 2026-10-21.

Figure data (text alternative) | Element | Kind | Description | Value | | --------------------- | --------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------- | | F01 | Handoff in play | Universe to Foundry: Admitted mission becomes a cycle project with a decision case | Readiness preparation | | F02 | Handoff in play | Foundry to Universe: Core Build Report and go or no-go evidence | Controlled build | | F03 | Handoff in play | Foundry to Reports: Sealed observations and indicator series behind a profile | Closeout | | F04 | Handoff | Universe to Reports: After-action and scenario findings for chapters 10 and 13 | After-action review | | F05 | Handoff in play | Foundry to Reports: National Portfolio movement for chapter 11 | After-action review | | F06 | Handoff | Reports to Standards: Method and correction findings as change proposals | Correction | | F07 | Handoff | Universe to Standards: Docket items that need a standard or a profile | Docket review | | F08 | Handoff in play | Standards to Foundry: Composed mission profiles and national adoption records | Readiness preparation | | F09 | Handoff | Standards to Academy: Each adopted standard or profile becomes a course module | Renewal | | F10 | Handoff | Universe to Academy: Assessed cycle tasks become completion evidence | Closeout | | F11 | Handoff | Academy to Universe: Qualified participants for the next cycle's roles | Renewal | | F12 | Handoff | Reports to Universe: Q4 synthesis informs the next-year mandate | Renewal | | F13 | Handoff in play | Foundry to Standards: Validation and monitoring evidence for conformance review | Controlled build | | F14 | Handoff in play | Foundry to Academy: Each system's rooms become a learning-by-doing course | Planning | | R1 | Handoff | Standards to Reports: Applied in editions | Around the ring | | R2 | Handoff | Reports to Academy: Taught in the open | Around the ring | | R3 | Handoff | Academy to Labs: Questions become experiments | Around the ring | | R4 | Handoff in play | Labs to Foundry: Tested prototypes are built | Around the ring | | Labs | Pillar | Explore, experiment and prototype | in this route | | Foundry | Pillar | Build, simulate and prepare | in this route | | Universe | Pillar | Convene and test | in this route | | Standards | Pillar | Codify, correct and apply | in this route | | Reports | Pillar | Publish in every format | in this route | | Academy | Pillar | Teach in the open | in this route | | Planning | Phase (Q1, G0) | F14 Each system's rooms become a learning-by-doing course | 1 handoff(s) | | Readiness preparation | Phase (Q2, G2) | F01 Admitted mission becomes a cycle project with a decision case; F08 Composed mission profiles and national adoption records | 2 handoff(s) | | Controlled build | Phase (Q2, G3) | F02 Core Build Report and go or no-go evidence; F13 Validation and monitoring evidence for conformance review | 2 handoff(s) | | Closeout | Phase (Q3, G5) | F03 Sealed observations and indicator series behind a profile; F10 Assessed cycle tasks become completion evidence | 2 handoff(s) | | After-action review | Phase (Q3) | F04 After-action and scenario findings for chapters 10 and 13; F05 National Portfolio movement for chapter 11 | 2 handoff(s) | | Correction | Phase (Q4) | F06 Method and correction findings as change proposals | 1 handoff(s) | | Docket review | Phase (Q4) | F07 Docket items that need a standard or a profile | 1 handoff(s) | | Renewal | Phase (Q4, G7) | F09 Each adopted standard or profile becomes a course module; F11 Qualified participants for the next cycle's roles; F12 Q4 synthesis informs the next-year mandate | 3 handoff(s) |
## How the Foundry pillar works **Twenty systems.** The Foundry pillar works on the twenty [Nexus systems](/organization/systems.md), each with its command rooms, under their NXS display codes: builds and verification in [NXS-FAC](/organization/systems/nxs-fac.md) (blueprints, builds, verification, signing and assembly), composition in [NXS-STU](/organization/systems/nxs-stu.md) (visual composition, dashboards, forms and workflow experiences), simulation and frontier evaluation in [NXS-LAB](/organization/systems/nxs-lab.md) (research, experiments, simulations and frontier-technology evaluation), canonical data in [NXS-GRX](/organization/systems/nxs-grx.md) (canonical data, provenance, risk and federation) and compute in [NXS-COR](/organization/systems/nxs-cor.md) (compute, nodes, runtimes, placement and infrastructure lifecycle). Each recorded handoff of the programme year is written in a named room of a system, so that what crossed, when and under which gate can be traced. **What it holds.** The Foundry pillar owns the projects and builds of each cycle, the observations and canonical data, the simulation and benchmark runs, the National Portfolio record and the evidence seals. The National Portfolio has four views: risk, capability, projects and research, and readiness and handoffs. In the sites' words, "Readiness is fitness for a stated next step… not approval, bankability or certification" ([National Portfolio](https://therisk.global/consortium/national/portfolio/)). **Technology at arm's length.** The systems the pillar works on are provided under written agreements. No Nexus Standard depends on any provider. GCRI Canada is the lead contracting organization; technology, infrastructure and service providers work with the Nexus Consortium at arm's length and are described by role only: a provider does not operate the programme or direct programme decisions. Licensing terms, title and instruments remain subject to verification and counsel review. **Simulation is not validation.** A configured or simulated capability remains a design state until a Universe mission has tested it and its evidence is sealed at gate G5. A National Portfolio entry describes a country's own pipeline in its own terms; it is not an investment decision, and the Foundry pillar never moves money or executes a transaction. ## The pillar in the model The tables in this section are generated from the sites' pillar model, so they match the GCRI, GRF and GRA home pages. ### At a glance What the pillar does, the records it owns, the boundary it keeps and where it is published. | | | | -------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Does | Builds the cycle's software, data and environments; Simulates scenarios and runs benchmarks; Monitors hazards, systems and evidence; Develops and tracks the National Portfolio | | Records it owns | Projects and builds; Observations and canonical data; Simulation and benchmark runs; The National Portfolio record; Evidence seals | | Boundary | A configured or simulated capability is not a validated result, and a National Portfolio entry is not an investment decision. | | Public home | [The twenty systems](/organization/systems.md) | | On the institutions' sites | [GRF: Build](https://globalriskforum.com/nexus-cycle/build/) · [GRA: Build](https://globalriskalliance.com/nexus-cycle/build/) | ### Handoffs The handoffs this pillar sends and receives. Recorded handoffs (F01 to F14) happen in a named phase; ring handoffs (R1 to R4) run continuously. | Id | Direction | Phase | What moves | | --- | ------------------------------------------------------------ | --------------------- | ------------------------------------------------------------- | | F01 | From [Nexus Universe](/organization/programme/universe.md) | Readiness preparation | Admitted mission becomes a cycle project with a decision case | | F02 | To [Nexus Universe](/organization/programme/universe.md) | Controlled build | Core Build Report and go or no-go evidence | | F03 | To [Nexus Reports](/organization/programme/reports.md) | Closeout | Sealed observations and indicator series behind a profile | | F05 | To [Nexus Reports](/organization/programme/reports.md) | After-action review | National Portfolio movement for chapter 11 | | F08 | From [Nexus Standards](/organization/programme/standards.md) | Readiness preparation | Composed mission profiles and national adoption records | | F13 | To [Nexus Standards](/organization/programme/standards.md) | Controlled build | Validation and monitoring evidence for conformance review | | F14 | To [Risk Academy](/organization/programme/academy.md) | Planning | Each system's rooms become a learning-by-doing course | | R4 | From [Labs](/organization/programme/labs.md) | Continuous | Tested prototypes are built | ### Through the year What the pillar does in each quarter and in each phase of the programme year. | Quarter | Edition | What this pillar does | | ------- | ---------------------------- | ------------------------------------------------------------ | | Q1 | State and Agenda | Opens cycle projects; National Portfolio baseline | | Q2 | Evidence and Build | Qualifies sources; one-month controlled build | | Q3 | Stress Test and Readiness | Runs simulations in Action Week; releases temporary capacity | | Q4 | Annual Synthesis and Renewal | Supplies data bundles; registers capability gaps | | Phase | Quarter | Gate | Work in this phase | | --------------------- | ------- | ---- | -------------------------------------------------------------------------------- | | Planning | Q1 | G0 | Opens the cycle projects and takes a baseline of every National Portfolio. | | Readiness preparation | Q2 | G2 | Qualifies data sources and resource offers; builds the scenario models. | | Controlled build | Q2 | G3 | Integrates software and data, signs builds, tests security and interoperability. | | Action Week | Q3 | G4 | Runs simulations and benchmarks and monitors the exercise picture. | | Stand-down | Q3 | – | Revokes temporary access and releases temporary capacity. | | Closeout | Q3 | G5 | Reconciles equipment, reservations and costs; verifies persistent services. | | After-action review | Q3 | – | Updates the National Portfolio with measured movement. | | Reporting | Q4 | G6 | Supplies the permitted data bundles behind each edition. | | Correction | Q4 | – | Re-runs the affected analysis with the corrected inputs. | | Docket review | Q4 | – | Registers capability gaps as work for the next build. | | Network review | Q4 | – | Publishes measured capacity results and resource qualification changes. | | Renewal | Q4 | G7 | Carries the National Portfolio and open projects into the next cycle. | ### At each scale What the pillar does locally, nationally, regionally and at planetary scale. | Scale | What this pillar does at that scale | | --------- | ----------------------------------------------------------------------------------------------------------------------- | | Local | Observations and models keep their place: every value carries the location and boundary it was drawn on. | | National | Each country's National Portfolio is developed and tracked. | | Regional | Shared systems and cross-border dependencies are modelled across the countries of a region. | | Planetary | Global data and Earth observation are held with provenance, so planetary pressures can be read alongside national ones. | ### In each operating area The fourteen operating areas the programme answers for, as this pillar answers them. | Area | Question | For this pillar | | ---------------------- | --------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------- | | Leadership | Who leads, and on what record. | Each build is led by an authorized project with an accountable owner; leadership is technical and never extends to the decision the build informs. | | Strategy | How the year's priorities are set. | The build plan follows the National Portfolio and the missions admitted for the year. | | Cadence | When the work happens in the year. | Works all year; the controlled build runs for one month in Q2, and measured capacity results are reviewed in Q4. | | Ownership | Which records each pillar owns. | Owns projects and builds, observations and canonical data, simulation and benchmark runs, the National Portfolio record and evidence seals. | | Process | How work moves, step by step. | Work moves through governed rooms on twenty systems, and every run leaves a record with its limits. | | Development | What is developed, and how capacity grows. | Develops the cycle's software, data and environments, and develops each country's National Portfolio. | | Simulations | How scenarios and exercises are run and read. | Runs scenarios, experiments and benchmarks with published method and conditions; a simulated capability is not a validated result. | | Reporting | How results reach the public record. | Supplies the permitted data bundles and sealed observations behind every edition. | | Governance | Who decides, and what a decision is not. | Shared infrastructure made available to the Consortium for public-good purposes; it holds no vote in the governance of the standards. | | Data and evidence | Where the evidence comes from and how it is kept. | Canonical observations and provenance are held in NXS-GRX, and every value carries its source and licence. | | Finance and resourcing | How work is resourced and made readable to finance. | Compute and data allocations open per project when their terms and review capacity exist; temporary capacity is released at stand-down. | | Risk and assurance | How errors are caught and limits are stated. | Builds are signed and tested for security and interoperability, and accepted for exercise only at gate G3. | | Participation | Who takes part, and how. | Stakeholders and service providers may establish their presence for non-profit and consortium objectives under the Terms. | | Communication | How each pillar speaks in public. | Public pages describe each system's purpose and design, and state what it does only as far as its record shows. | ### Applied to the eight contexts How the pillar would apply to each teaching context of the model, and the measure it would answer for. These are illustrative applications, not delivered projects. | Context | Illustrative application | Measure | Applied | | ------------------------------------------------------------------- | ------------------------------------------------------------- | ----------------------------------------- | ------- | | [Urban flood](/organization/model/scenarios/urban-flood.md) | City twin links substations, pumps and clinics to flood depth | Lifelines modelled (higher is better) | yes | | [Hydropower reservoir](/organization/model/scenarios/hydropower.md) | Basin twin trades power, flood storage and river flows | Release options tested (higher is better) | yes | | [Drought](/organization/model/scenarios/drought.md) | Allocation model for irrigation, cooling and drinking water | Demand met in drought (higher is better) | yes | | [Heatwave](/organization/model/scenarios/heatwave.md) | Grid peak and river temperature model for the heat season | Peak hours foreseen (higher is better) | yes | | [Grid blackout](/organization/model/scenarios/blackout.md) | Twin of backup fuel, water treatment and cold chains | Hours of autonomy (higher is better) | yes | | [Pandemic](/organization/model/scenarios/pandemic.md) | Continuity board for clinics, grid and logistics | Services monitored (higher is better) | yes | | [Pollinator decline](/organization/model/scenarios/pollinator.md) | Yield and diet-quality model by crop | Crops modelled (higher is better) | yes | | [Coastal storm surge](/organization/model/scenarios/storm-surge.md) | Coastal twin of ports, substations and water intakes | Assets in the twin (higher is better) | yes | ### The institutions in this pillar What GCRI, GRF and GRA each contribute. | Institution | Contribution | | ----------- | -------------------------------------------------------------------------------------------------------------------------- | | GCRI | Its science and technical platforms bring the methods, data and evidence that the Foundry builds on. | | GRF | Admits missions and accepts the build for exercise at a recorded gate, so Foundry work enters the programme on the record. | | GRA | Brings finance-readiness questions, so builds produce evidence that financial institutions can read. | ## Read further * [Programme](/organization/programme.md): the six pillars together. * [The programme year](/organization/programme/the-programme-year.md): every phase, gate and actor. * [The Nexus cycle](/organization/programme/the-nexus-cycle.md): from a question to renewal, and who decides. * [The model](/organization/model.md): coupled risk and applied response. * [Systems](/organization/systems.md): the twenty Nexus systems. ## Sources * GCRI, [National Portfolio](https://therisk.global/consortium/national/portfolio/), as of 2026-10-21. * Pillar model and programme spine of the sites (vendored in the documentation repository, `tools/figures/vendor/nexus-model`): the source of every generated table on this page. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.therisk.global/organization/programme/foundry.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.