> 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/model/applied-response.md).

# Applied response

Applied response: the six programme pillars, the eighteen handoffs between them, the feedback loops they close and how a sector context selects the pillars and measures that apply.

**Where this fits:** all six sectors · all six pillars · the Nexus Consortium, with GRF as programme steward of Nexus Universe · the whole programme year · model page.

**In brief.** The right hexagon of the model places the six pillars of the programme on the same geometry as the six sectors: Labs, Foundry, Nexus Universe, [Nexus Standards](/organization/institutions/nexus-standards.md), Nexus Reports and [Risk Academy](/organization/institutions/risk-academy.md). Each pillar does one kind of work, owns its own records and states its own boundary. Work moves between pillars through eighteen handoffs: fourteen recorded handoffs (F01 to F14), each tied to a phase of the programme year and a named artefact, and four ring handoffs (R1 to R4) that carry work continuously. When a context such as urban flood is chosen on the left, it selects the pillars that apply on the right, the measure each pillar answers for, and the handoffs between them that come into play. Every pillar is led by the Nexus Consortium.

## The six pillars

| Pillar                                                  | Does                              | Role                                                                                                                                                                                           | Steward                                                                | Public home                                                           |
| ------------------------------------------------------- | --------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------- | --------------------------------------------------------------------- |
| [Labs](/organization/programme/labs.md)                 | Explore, experiment and prototype | Where 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. | The Nexus Consortium                                                   | [therisk.global/nexus-labs](https://therisk.global/nexus-labs/)       |
| [Foundry](/organization/programme/foundry.md)           | Build, simulate and prepare       | Where things are built, simulated and prepared: every output of GCRI, GRF and GRA, under the Nexus Consortium.                                                                                 | The Nexus Consortium                                                   | [The twenty systems](/organization/systems.md)                        |
| [Nexus Universe](/organization/programme/universe.md)   | Convene and test                  | Where everything comes together in the annual programme, with GCRI, GRF and GRA each contributing in its role and capacity.                                                                    | The Global Risks Forum (programme steward), under the Nexus Consortium | [universe.nexus](https://universe.nexus/)                             |
| [Nexus Standards](/organization/programme/standards.md) | Codify, correct and apply         | Where all standards are developed, corrected and applied, in the open, with adoption decided by each jurisdiction.                                                                             | Nexus Standards, with GCRI Canada as secretariat                       | [nexustandards.com](https://nexustandards.com/)                       |
| [Nexus Reports](/organization/programme/reports.md)     | Publish in every format           | Where all outputs are published, in all formats, across its five sites, each with sources, limits and corrections.                                                                             | The Nexus Consortium                                                   | [therisk.global/nexus-reports](https://therisk.global/nexus-reports/) |
| [Risk Academy](/organization/programme/academy.md)      | Teach in the open                 | Where everything is taught in the open, in real locations and for impact, by learning on real cycle work.                                                                                      | Risk Academy, with GCRI Canada as issuer of record                     | [risksacademy.com](https://risksacademy.com/academy-home/)            |

The pillars are not departments of one organisation. GCRI Canada, the Global Risks Forum (GRF) and the Global Risks Alliance (GRA) each contribute to every pillar in their own role (see [Institutions](/organization/institutions.md)), and no pillar has authority over a government, an operator or a licensed institution. Outside the programme stands the **competent authority**: the government, regulator, operator or licensed institution that decides and acts. The programme informs that decision; it never takes it.

## Boundaries

Each pillar states what its work is not. These sentences are binding wording wherever the pillar is described.

| Pillar          | Boundary                                                                                                                                                             |
| --------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Labs            | An experiment is exploratory: its results are labelled as such and become evidence only after the Foundry rebuilds and the Universe tests them.                      |
| Foundry         | A configured or simulated capability is not a validated result, and a National Portfolio entry is not an investment decision.                                        |
| Nexus Universe  | A cycle gate is a programme decision. It is not a public-authority approval, a certification or a deployment authorisation.                                          |
| Nexus Standards | A validator report is evidence for review, not a conformance claim; adoption is final for each jurisdiction and no global body holds a veto.                         |
| Nexus Reports   | An edition is published after review, not to a calendar, and is never an official government risk register or a sovereign rating.                                    |
| Risk Academy    | A completion record is not a licence to practise, and no credential is issued until an accountable issuer, an assessment method and a revocation path are on record. |

## Records each pillar owns

A pillar is defined as much by the records it keeps as by what it does. The records are the stocks of the system; the handoffs below are its flows (Sterman, 2000).

| Pillar          | Records it owns                                                                                                                    |
| --------------- | ---------------------------------------------------------------------------------------------------------------------------------- |
| Labs            | experiment register; prototype record; working papers                                                                              |
| Foundry         | Projects and builds; Observations and canonical data; Simulation and benchmark runs; The National Portfolio record; Evidence seals |
| Nexus Universe  | Cycle mandate; Mission admission decisions; Gate decisions G0 to G7; After-action records; Renewal decision                        |
| Nexus Standards | UNI identifiers; Standards, clauses and profiles; Change proposals; National adoption records; Conformance evidence                |
| Nexus Reports   | Editions and their evidence cutoff; Country and regional profiles; Technology stream briefs; Correction history                    |
| Risk Academy    | Learning pathways and courses; Cohorts and enrolments; Assessment evidence; Completion records; Credential issuance records        |

## The eighteen handoffs

A handoff is the moment one pillar's output becomes another pillar's input. The recorded handoffs F01 to F14 each happen in one phase of the programme year and move one named artefact. The ring handoffs R1 to R4 close the circle around the hexagon where no recorded handoff does; they are continuous.

| Id  | From            | To              | Phase                        | What moves                                                    |
| --- | --------------- | --------------- | ---------------------------- | ------------------------------------------------------------- |
| F01 | Nexus Universe  | Foundry         | Readiness preparation        | Admitted mission becomes a cycle project with a decision case |
| F02 | Foundry         | Nexus Universe  | Controlled build             | Core Build Report and go or no-go evidence                    |
| F03 | Foundry         | Nexus Reports   | Closeout                     | Sealed observations and indicator series behind a profile     |
| F04 | Nexus Universe  | Nexus Reports   | After-action review          | After-action and scenario findings for chapters 10 and 13     |
| F05 | Foundry         | Nexus Reports   | After-action review          | National Portfolio movement for chapter 11                    |
| F06 | Nexus Reports   | Nexus Standards | Correction                   | Method and correction findings as change proposals            |
| F07 | Nexus Universe  | Nexus Standards | Docket review                | Docket items that need a standard or a profile                |
| F08 | Nexus Standards | Foundry         | Readiness preparation        | Composed mission profiles and national adoption records       |
| F09 | Nexus Standards | Risk Academy    | Renewal                      | Each adopted standard or profile becomes a course module      |
| F10 | Nexus Universe  | Risk Academy    | Closeout                     | Assessed cycle tasks become completion evidence               |
| F11 | Risk Academy    | Nexus Universe  | Renewal                      | Qualified participants for the next cycle's roles             |
| F12 | Nexus Reports   | Nexus Universe  | Renewal                      | Q4 synthesis informs the next-year mandate                    |
| F13 | Foundry         | Nexus Standards | Controlled build             | Validation and monitoring evidence for conformance review     |
| F14 | Foundry         | Risk Academy    | Planning                     | Each system's rooms become a learning-by-doing course         |
| R1  | Nexus Standards | Nexus Reports   | Continuous (around the ring) | Applied in editions                                           |
| R2  | Nexus Reports   | Risk Academy    | Continuous (around the ring) | Taught in the open                                            |
| R3  | Risk Academy    | Labs            | Continuous (around the ring) | Questions become experiments                                  |
| R4  | Labs            | Foundry         | Continuous (around the ring) | Tested prototypes are built                                   |

The same handoffs as a design structure matrix, read from the row (sender) to the column (receiver). The matrix shows at a glance that the Foundry and Universe exchange most, and that Labs connects to the rest only through the ring.

| Sends ↓ / receives → | Labs | Foundry | Universe | Standards | Reports  | Academy |
| -------------------- | ---- | ------- | -------- | --------- | -------- | ------- |
| Labs                 | ·    | R4      |          |           |          |         |
| Foundry              |      | ·       | F02      | F13       | F03, F05 | F14     |
| Universe             |      | F01     | ·        | F07       | F04      | F10     |
| Standards            |      | F08     |          | ·         | R1       | F09     |
| Reports              |      |         | F12      | F06       | ·        | R2      |
| Academy              | R3   |         | F11      |           |          | ·       |

## Feedback loops

A loop is a closed chain of handoffs that returns to the pillar where it began. The model counts sixteen elementary loops in the recorded handoffs, plus the whole ring. A loop is closed in a context when every pillar on it applies. Loops are what make the programme learn: a build is tested, a finding becomes a correction, a correction returns to the next build.

| Loop                                                                                    | Handoffs that close it      |
| --------------------------------------------------------------------------------------- | --------------------------- |
| Foundry → Nexus Standards → back                                                        | F13, F08                    |
| Foundry → Nexus Universe → back                                                         | F02, F01                    |
| Nexus Universe → Risk Academy → back                                                    | F10, F11                    |
| Nexus Universe → Nexus Reports → back                                                   | F04, F12                    |
| Foundry → Risk Academy → Nexus Universe → back                                          | F14, F11, F01               |
| Foundry → Nexus Reports → Nexus Standards → back                                        | F03/F05, F06, F08           |
| Foundry → Nexus Reports → Nexus Universe → back                                         | F03/F05, F12, F01           |
| Foundry → Nexus Universe → Nexus Standards → back                                       | F02, F07, F08               |
| Nexus Universe → Nexus Standards → Risk Academy → back                                  | F07, F09, F11               |
| Foundry → Risk Academy → Nexus Universe → Nexus Standards → back                        | F14, F11, F07, F08          |
| Foundry → Nexus Reports → Nexus Universe → Nexus Standards → back                       | F03/F05, F12, F07, F08      |
| Foundry → Nexus Standards → Risk Academy → Nexus Universe → back                        | F13, F09, F11, F01          |
| Foundry → Nexus Universe → Nexus Reports → Nexus Standards → back                       | F02, F04, F06, F08          |
| Nexus Universe → Nexus Reports → Nexus Standards → Risk Academy → back                  | F04, F06, F09, F11          |
| Foundry → Risk Academy → Nexus Universe → Nexus Reports → Nexus Standards → back        | F14, F11, F04, F06, F08     |
| Foundry → Nexus Reports → Nexus Standards → Risk Academy → Nexus Universe → back        | F03/F05, F06, F09, F11, F01 |
| Labs → Foundry → Nexus Universe → Nexus Standards → Nexus Reports → Risk Academy → back | the ring                    |

## Routes through the programme

A route is a named path through some of the pillars, for a reader who wants to follow one kind of work.

| Route                          | Pillars                                                                     | What moves along it                                                                                                 |
| ------------------------------ | --------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------- |
| The whole programme            | Labs, Foundry, Nexus Universe, Nexus Standards, Nexus Reports, Risk Academy | Every pillar hands its work to another; together they close the year's feedback loops.                              |
| From prototype to practice     | Labs, Foundry, Nexus Universe, Nexus Standards                              | A Labs prototype is built in the Foundry, tested in a Universe mission and codified as a standard.                  |
| Build and test                 | Foundry, Nexus Universe                                                     | The Foundry builds what a mission needs; Universe returns the go or no-go evidence.                                 |
| Conformance                    | Foundry, Nexus Standards                                                    | Validation evidence goes to Standards for review; composed profiles come back for the next build.                   |
| A finding becomes a correction | Foundry, Nexus Reports, Nexus Standards                                     | Observations are published, a method finding becomes a change proposal, the corrected profile returns to the build. |
| Setting the next mandate       | Nexus Universe, Nexus Reports                                               | After-action findings go into the editions; the Q4 synthesis informs next year's mandate.                           |
| People for the next cycle      | Nexus Universe, Risk Academy                                                | Assessed cycle tasks become completion evidence; qualified participants take roles in the next cycle.               |
| Learning by doing              | Foundry, Nexus Universe, Risk Academy                                       | Each system's rooms become a course; learners join missions, and missions return to the Foundry.                    |

## How a context selects the response

The two hexagons are linked by data, not by a drawing. For each of the eight [teaching contexts](/organization/model/scenarios.md), the model records three things.

1. **The pillars that apply.** For an urban flood, five of the six pillars apply. They are the pillars whose work the context most depends on, and they set which handoffs and loops come into play: eleven of eighteen handoffs, eight loops closed.
2. **An illustrative application and its measure.** Each pillar has one application in the context and the measure it answers for, with its direction. In an urban flood, the Labs pillar nowcasts flood depth and answers for warning lead time (higher is better). Nexus Universe exercises keeping water and power running through a 1-in-100 flood and answers for hours to restore (lower is better).
3. **Published benchmarks.** Three slots show the value at risk, the return on resilience and the avoided loss, where the literature gives one, each with its source on the same line.

The applications are illustrative designs, not delivered projects, and a measure is what a pillar would answer for, not a reported result. The benchmarks are international evidence, not forecasts for any project or place.

## Methods behind the model

The pillar model uses five established methods of systems analysis, named in its data.

| Method                   | How the model uses it                                                                                                                               | Reference                                                                                      |
| ------------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------- |
| Causal loop analysis     | The feedback loops between pillars are the closed chains of recorded handoffs (F01 to F14), enumerated as elementary circuits of the handoff graph. | System dynamics (Forrester; Sterman, Business Dynamics, 2000)                                  |
| Design structure matrix  | The pillar by pillar matrix shows which pillar hands what to which, so couplings and missing joins are visible at a glance.                         | Steward (1981); Eppinger and Browning, Design Structure Matrix Methods and Applications (2012) |
| Stocks and flows         | Each pillar holds stocks (the records it owns) that change only through recorded flows (handoffs), so every change has an owner and a trace.        | System dynamics stock-and-flow notation (Sterman 2000)                                         |
| Cross-scale analysis     | Each pillar is read at four scales, local to planetary, so a finding keeps its scale and is never silently aggregated or downscaled.                | Panarchy and cross-scale interactions (Gunderson and Holling, 2002)                            |
| Swimlane process mapping | Every process graph carries the six pillars as lanes, so each step shows where it runs and who owns its record.                                     | Business process lanes (BPMN 2.0, OMG)                                                         |

## Where each pillar is described

| Pillar                    | Programme page                                                      |
| ------------------------- | ------------------------------------------------------------------- |
| Labs                      | [Labs](/organization/programme/labs.md)                             |
| Foundry                   | [Foundry](/organization/programme/foundry.md)                       |
| Nexus Universe            | [Nexus Universe](/organization/programme/universe.md)               |
| Nexus Standards           | [Nexus Standards](/organization/programme/standards.md)             |
| Nexus Reports             | [Nexus Reports](/organization/programme/reports.md)                 |
| Risk Academy              | [Risk Academy](/organization/programme/academy.md)                  |
| When each handoff happens | [The programme year](/organization/programme/the-programme-year.md) |

## Sources

* Eppinger, S. D. and Browning, T. R. (2012). *Design Structure Matrix Methods and Applications.* Cambridge, MA: MIT Press.
* Gunderson, L. H. and Holling, C. S. (eds.) (2002). *Panarchy: Understanding Transformations in Human and Natural Systems.* Washington, DC: Island Press.
* Object Management Group (2011). *Business Process Model and Notation (BPMN), Version 2.0.* <https://www.omg.org/spec/BPMN/2.0/>
* Sterman, J. D. (2000). *Business Dynamics: Systems Thinking and Modeling for a Complex World.* Boston: Irwin McGraw-Hill.
* The model data: the six pillars and handoffs of [How Nexus works](https://therisk.global/nexus-cycle/) and the "Coupled risk, applied response" section of the [GCRI home page](https://therisk.global/).


---

# 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/model/applied-response.md?ask=<question>&goal=<user_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.