> 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/operations/frameworks/nexus-leadership-system-nls/xxiv.-institutionalization-programme.md).

# XXIV. Institutionalization Programme

Explore the NLS 2026–2030 institutionalization programme: Adopt, Replicate, Federate, Institutionalize, and Scale leadership, evidence, and public-interest infrastructure.

**Where this fits:** all six sectors · [Nexus Universe](/organization/programme/universe.md), [Risk Academy](/organization/programme/academy.md) · The Global Risks Forum (GRF), with GCRI Canada as Consortium Secretariat · the programme year (quarterly NLC alignment; the Year-One Gateway) · systems [NXS-HUB](/organization/systems/nxs-hub.md), [NXS-RLS](/organization/systems/nxs-rls.md), [NXS-NSF](/organization/systems/nxs-nsf.md) · framework page (NLS).

**In brief.** The 2026-2030 sequence is the institutional development horizon through which we intend the Nexus architecture to move from credible adoption into repeatable and durable public-interest infrastructure. This page belongs to the Nexus Leadership System (NLS), read as the leadership method of the operating model: it describes how leaders selected in a personal capacity contribute through the National Leadership Council (NLC), alongside the Helix councils of the National Nexus Consortium (NNC) and the National Working Groups (NWG). Selection precedes payment. Council standing does not buy office, employment, a Board seat or restricted data, and an employer does not own a personal seat; no council decides for a public authority. The method aligns with international practice ([ISO 2018](https://www.iso.org/standard/65694.html); [OECD 2014](https://legalinstruments.oecd.org/en/instruments/OECD-LEGAL-0405)).

{% hint style="info" %}
**Read with the current model (21 October 2026).** The "Leadership Councils" of this framework correspond, at national level, to the [National Leadership Council (NLC)](/organization/governance-in-operation/nlc.md), the leadership pillar of [National Nexus](/organization/governance-in-operation/national-nexus.md); the regional and global leadership councils are the councils of the GRF council architecture, in formation ([Councils](/organization/governance-in-operation/councils.md)). Institutions take part through the six Helix councils of the [NNC](/organization/governance-in-operation/nnc.md) (SPC, IOC, ARC, CMC, CIC and the FIR pathway); expert work runs through [NWG](/organization/governance-in-operation/nwg.md) assignments, with the six CERTs under them. Earlier labels are mapped in running text: Competence Cells are the atomic units of the NWG fabric, formed at institution, community or agency level; a Competence Cell can serve as a CERT, Investors Councils are the Financial Institutions and Regulators (FIR) pathway, `Nexus Grid` is the `Nexus Network` and [NXS-NET](/organization/systems/nxs-net.md), Protocol Authority is NXS-NSF ([Reference](/organization/reference.md)). Leadership work follows [the programme year](/organization/programme/the-programme-year.md): mandate at G0, quarterly alignment, Action Week, renewal at G7.
{% endhint %}

## 24. 2026-2030 INSTITUTIONALIZATION PROGRAMME

The 2026-2030 sequence is the institutional development horizon through which we intend the Nexus architecture to move from credible adoption into repeatable and durable public-interest infrastructure.

We do not treat **Adopt, Replicate, Federate, Institutionalize and Scale** as marketing milestones, event themes or annual slogans. They are capability-maturity stages. Each year asks whether a different institutional condition has become true.

A system has not adopted merely because a Council has been announced. It has not replicated merely because the same document has been copied into another country. It has not federated merely because several National leaders attend a Regional meeting. It has not institutionalized merely because an initiative has existed for several years. It has not scaled merely because its participant count has increased.

The sequence therefore functions as a discipline:

**Can the architecture operate? Can it be reproduced? Can multiple instances interoperate? Can it survive transition? Can it expand without losing integrity?**

Those five questions define the institutional logic of the Founding Cycle.

***

### 24.1 The 2026-2030 Roadmap

#### 24.1.1 The roadmap is a maturity sequence

We define the Founding Cycle as:

**2026 Adopt**\
**2027 Replicate**\
**2028 Federate**\
**2029 Institutionalize**\
**2030 Scale**

Each stage depends substantially on capabilities developed earlier, while allowing overlap where context requires it.

A National Nexus beginning in 2028 may still be in its Adopt stage while another country is already participating in Regional federation. A mature Council may begin replication before every part of its National architecture has reached the same maturity. A Regional Hub may institutionalize some functions while still testing others.

The calendar therefore provides a common strategic horizon.

It does not require every country, institution, Council or programme to occupy an identical maturity state on the same date.

***

#### 24.1.2 Institutionalization is cumulative

The objective of the roadmap is not to replace one year's work with the next.

Adoption should remain embedded during replication. Replicated capability should remain nationally grounded during federation. Federation should survive institutionalization. Institutionalization should remain intact during scale.

The sequence is cumulative:

**Adopt and preserve.**\
**Replicate and adapt.**\
**Federate and interoperate.**\
**Institutionalize and endure.**\
**Scale and protect quality.**

A system that abandons the earlier capability while pursuing the next stage has not matured.

It has merely changed activity.

***

#### 24.1.3 The roadmap applies to capability, not only organizations

The five stages should be applied to the major capabilities of Nexus, not simply to the existence of institutions.

Leadership Council methodology can be adopted, replicated, federated, institutionalized and scaled. National Model architecture can follow the same pathway. The Leadership Ledger can do so. Foundry capability can do so. Nexus Universe can move from one proving environment into a repeatable and federated annual system.

This allows the architecture to mature unevenly while remaining intelligible.

One component may be scale-ready while another remains in validation.

The overall programme should therefore understand both **system-level maturity and capability-level maturity**.

***

#### 24.1.4 Adoption is not complete until the architecture is used

We distinguish institutional adoption from formal acceptance.

A Council charter can be approved but unused. A Foundry environment can be deployed but not integrated into leadership practice. A National Portfolio can be created but disconnected from Council deliberation. A Leadership Ledger can exist technically while contribution continues to be tracked informally elsewhere.

The architecture becomes adopted when institutions actually begin using it to organize recurring work.

This means that operating behaviour matters more than launch language.

We therefore evaluate the roadmap through **use, evidence and continuity**, not announcement.

***

#### 24.1.5 Replication is not duplication

Replication does not mean copying one country's institutional form into another.

The transferable object is the **operating grammar**: Council logic, Desk capability, Model and Portfolio concepts, evidence states, Foundry interfaces, annual Nexus Universe cycle, Leadership Ledger, integrity controls and federation principles.

The institutional expression should adapt to national context.

A model that works only when reproduced identically is not truly scalable across sovereign and institutional diversity.

The test of replication is whether the architecture can remain recognizable while becoming legitimately local.

***

#### 24.1.6 Federation is not consolidation

By 2028, mature National systems should become increasingly capable of connecting around cross-border dependencies.

Federation does not require those National systems to merge.

It requires common semantics, interoperable leadership processes, governed information exchange, cross-border Portfolios, Regional Councils, Hubs and annual learning environments capable of producing additionality without erasing National ownership.

The strength of federation should therefore be measured by **interoperability among distinct systems**, not by the extent to which they have been centralized.

***

#### 24.1.7 Institutionalization is not permanence by declaration

An institution becomes durable when critical capabilities survive normal change.

Leaders transition. Staff change. Sponsors come and go. technologies evolve. Political attention moves elsewhere.

A capability that disappears immediately when one founder, Chair, programme lead or funding cycle ends has not been institutionalized adequately.

The 2029 stage therefore asks whether recurring functions now possess enough ownership, records, leadership depth, operating capacity, resources, governance and succession to persist through transition.

Institutionalization is demonstrated through **survival of change**.

***

#### 24.1.8 Scale is a quality test

The final stage is not simply numerical expansion.

Scale increases stress on every part of the architecture.

More countries create more variation. More members create more identity and evidence complexity. More institutional partners create more boundaries. More data creates more information-governance demands. More funding can increase capture risk. More technical integration can create concentration.

The 2030 challenge is therefore whether Nexus can become materially larger without becoming less trustworthy.

Scale is successful only when growth and institutional quality advance together.

***

### 24.2 2026: Adopt

#### 24.2.1 2026 establishes the operating architecture

We define **2026 Adopt** as the year in which the Nexus Leadership System and wider Nexus architecture must become operational enough to be used as a real institutional system rather than remain primarily conceptual.

The central task is adoption of the common grammar.

Leadership Councils must be understandable. National Desks must have a coherent function. Annual Leadership Contribution Plans must become usable. Foundry should support persistent leadership work. Nexus Universe should function as the annual proving cycle. Leadership Ledger logic should preserve contribution and institutional state.

The objective is not to perfect every component immediately.

It is to establish enough of the full architecture that institutions can begin using, testing and correcting it in practice.

***

#### 24.2.2 Adoption begins with National grounding

The National level provides the primary proving environment for the architecture.

We therefore expect early National Nexus formation to focus on a credible leadership nucleus, a functioning National Desk or equivalent operating capability, initial Working Groups, the beginnings of a National Model and Portfolio, and enough Public-Private-Planet depth to understand the country's major systemic dependencies.

The initial formation grammar may begin around a nucleus of approximately ten credible leaders and mature toward a fuller Council and wider leadership bench as substance grows.

The exact number matters less than whether the emerging National system possesses sufficient capability to do real work.

Adopt means **grounded institutional formation**, not ceremonial launch.

***

#### 24.2.3 The first leadership cohort establishes behavioural norms

The earliest leaders carry unusual responsibility because their behaviour becomes precedent.

How they handle conflicts, contribution attribution, dissent, Working Groups, Council office, National relationships and institutional claims will influence later cohorts.

We therefore use the Formation, Planning, Testing and Validation Year not only to develop individual members but to establish the culture of the system itself.

The first cohort should make evidence discipline normal.

It should make correction normal.

It should make the distinction between Council leadership and execution normal.

It should make contribution more important than title.

Culture established during adoption can be difficult to repair later if poor norms become embedded early.

***

#### 24.2.4 The National Desk establishes persistence

Councils alone do not create institutionalization.

During Adopt, the National Desk or equivalent operating function should begin creating persistent capacity between Council meetings.

The Desk maintains recurring work, records, Working Group coordination, Portfolio development, institutional relationships, Foundry use, Universe preparation and follow-through.

This separates Nexus from convening models that generate strong meetings but weak continuity.

A Council without persistence may create periodic insight.

A Council connected to a functioning Desk can begin creating institutional capability.

***

#### 24.2.5 The National Model establishes common systems understanding

Adopt also requires the beginning of a National Model capable of representing major systems, dependencies and evidence relevant to the country.

The Model does not need to be complete before it becomes useful.

Its initial value lies in creating a common object around which leaders can identify what is known, what remains unknown, which systems interact and where risk intelligence requires improvement.

The National Model should evolve as evidence improves.

The adoption-stage test is whether it has become part of real leadership and readiness work rather than remaining an abstract technical concept.

***

#### 24.2.6 The National Portfolio establishes the pathway from intelligence to institutional work

The National Portfolio should begin organizing priority risks, opportunities, programmes, capabilities, institutional owners, evidence gaps, readiness states, safeguards and next steps.

Its early form may be incomplete.

The key institutional achievement is that leaders now possess a common object through which strategic attention can become cumulative.

The Portfolio turns Council intelligence into an evolving field of work.

It provides one of the principal links among leadership, Foundry, Working Groups, Nexus Universe and the institutions capable of carrying programmes forward.

Adoption therefore requires not only understanding systems but organizing **what should happen next**.

***

#### 24.2.7 Foundry should become persistent infrastructure

During 2026, [the Foundry pillar](/organization/systems.md) should increasingly function as the persistent operating and intelligence environment supporting the wider Nexus system.

For leaders, this includes the Leadership Cockpit, Plans, intelligence, Council work, Missions, evidence, Learning, Opportunities, Universe and Governance interfaces described elsewhere in this Handbook.

Foundry should connect to the broader Nexus technical architecture without becoming a substitute for institutional responsibility.

The adoption test is whether leaders and operating teams can use the environment to preserve state and conduct recurring work more coherently than through disconnected documents and informal memory.

***

#### 24.2.8 Nexus Universe should prove the architecture under pressure

Nexus Universe provides the annual environment through which assumptions can encounter a more concentrated integration and testing cycle.

During Adopt, Universe should demonstrate that the persistent year-round architecture can be brought together through preparation, Core Build, Action programme, observation, evidence, after-action review and correction.

The objective is not to produce a large event.

It is to expose the architecture to enough complexity that weaknesses become visible.

A successful 2026 Universe cycle should therefore generate a correction agenda, not merely celebration.

The system becomes more credible because it has discovered what still needs to improve.

***

#### 24.2.9 The Leadership Ledger should establish institutional memory from the beginning

Contribution evidence should not be reconstructed years later.

During Adopt, NLS should begin preserving member standing, Council assignments, offices, Plans, contributions, evidence, attribution, governance states and material transitions through the Leadership Ledger architecture.

The Ledger should remain proportionate and practical.

Its value is cumulative.

An accurate Year-One record becomes the foundation for Year-Two pathway decisions, later succession, opportunity matching and long-term institutional memory.

The cost of delaying this architecture would increase every year as leadership history accumulates outside the governed system.

***

#### 24.2.10 Adopt succeeds when the system can enter a second cycle intelligently

The deepest test of 2026 is not whether the first cycle occurred.

It is whether the system can begin its second cycle with more knowledge than it had at the beginning of the first.

Does the Council know what worked? Does the Desk have continuity? Does the Leadership Ledger preserve contribution? Does the Portfolio show unresolved work? Does Universe produce an Upgrade Docket? Can members renew their Plans from evidence rather than start again?

If the answer is yes, adoption has begun to create institutional memory.

That memory becomes the basis for replication.

***

### 24.3 2027: Replicate

#### 24.3.1 Replication tests whether the architecture is transferable

We define **2027 Replicate** as the stage in which validated elements of the Nexus system must prove they can operate beyond the contexts in which they were first developed.

Replication is an institutional test of generalizability.

A method that works only because the original founders personally carry it has not yet become replicable. A National Council process that requires constant interpretation from GCRI Canada has not yet become sufficiently portable. A Foundry workflow usable only by its original technical team has not become mature infrastructure.

Replication asks whether the method can travel while preserving its essential logic.

***

#### 24.3.2 Replication should preserve local ownership

The recipient National system should not become a branch office of the system from which the method originated.

We therefore replicate **architecture rather than dependency**.

A new National Council should develop its own priorities. Its National Model should reflect its own evidence and systems. Its Portfolio should emerge from its own institutional context. Its Desk should develop local capability.

The common NLS grammar supports these functions.

It does not dictate the substantive National agenda.

Replication succeeds when the new system can become genuinely national while remaining interoperable with the wider Nexus architecture.

***

#### 24.3.3 Replication should produce reusable implementation knowledge

Every new National adoption generates information about the transfer process itself.

Which parts of the Council model were easily understood? Which required adaptation? What local institutions were essential? Which Foundry capabilities generalized well? Which assumptions reflected the origin country more than expected?

These lessons should be captured and used to improve the next replication.

This creates a compounding learning curve.

By the time several National systems have been established, Nexus should know substantially more about how to establish the next one.

Replication therefore produces **method knowledge as well as new nodes**.

***

#### 24.3.4 Experienced leaders should help new systems without reproducing themselves

Leaders from earlier Councils can play important roles in replication.

They can mentor emerging Chairs, share lessons, contribute to Working Groups, help explain the Leadership Ledger or support Universe preparation.

Their purpose should be to accelerate local capability rather than recreate the original Council in their own image.

This requires restraint.

The experienced leader should distinguish transferable principles from context-specific habits.

The strongest replication mentor helps the new system become itself more quickly.

***

#### 24.3.5 Replication should test documentation and operating standards

A system dependent entirely on oral explanation is not ready to scale.

During Replicate, NLS should increasingly rely on coherent public and controlled documentation, templates, Plans, Council methods, Foundry interfaces, Ledger schemas, Universe protocols and support materials that allow new systems to understand how the architecture works.

This Handbook itself forms part of that infrastructure.

Documentation should not become rigid bureaucracy.

Its purpose is to reduce unnecessary reinvention while preserving enough flexibility for local design.

***

#### 24.3.6 Foundry should support multi-context reuse

Replication places new demands on the persistent technical environment.

Foundry should support differentiated countries, Councils, jurisdictions, information boundaries and operating contexts without requiring each new node to become a bespoke technology project.

The system should reuse common architecture while respecting National data, access and institutional boundaries.

This is where technical scalability begins to interact directly with institutional scalability.

A platform that can technically add users but cannot represent distinct National ownership is not sufficient for Nexus replication.

***

#### 24.3.7 Universe should become repeatable rather than episodic

The annual Nexus Universe cycle should mature into a repeatable programme architecture.

Core methods for preparation, Labs, scenario design, evidence, observation, after-action review and correction should become reusable across annual cycles and participating National systems.

Repeatability does not mean every Universe is identical.

The systems, technologies and strategic questions should change according to evidence and need.

What becomes repeatable is the operating method through which the federation tests itself annually.

***

#### 24.3.8 Leadership development should become reproducible

A leadership architecture cannot scale if formation quality depends entirely on one small central team.

During 2027, NLS should begin demonstrating that experienced Council Members, Chairs, Desks and leadership-development environments can support new leaders effectively using common methods.

The first-year journey, ALCP, Leadership Circles, mentoring and Council formation should become increasingly reproducible.

The aim is to develop **leaders capable of developing other leaders**.

That is one of the most important conditions for later federation.

***

#### 24.3.9 Replication should reveal what should not be standardized

One of the benefits of replication is discovering which elements should remain local.

An operating method may work across contexts while a particular Council composition model does not. A data architecture may require jurisdiction-specific design. One country's programme-readiness process may depend on institutions absent elsewhere.

These findings are valuable.

They help Nexus distinguish the **constitutional core from the configurable edge**.

A mature replicable architecture knows which elements must remain common for interoperability and which should remain adaptable for legitimacy.

***

#### 24.3.10 Replicate succeeds when new capability no longer depends on the original builders

The decisive test of replication is whether another National system can operate credibly without constant intervention from the people who designed the first one.

Support may remain available.

Federation may remain connected.

Common Foundry and NLS infrastructure may continue.

The local Council, Desk and wider National system should nevertheless possess enough understanding and capability to operate its own architecture.

Replication creates additional centres of competence.

It should not create additional points of dependency.

***

### 24.4 2028: Federate

#### 24.4.1 Federation begins when several National systems possess substantive capability

We define **2028 Federate** as the stage in which multiple nationally grounded Nexus systems become capable of working together around dependencies that exceed one country's boundaries.

This stage builds directly on Part XIII.

Federation is meaningful only when there is enough substance to connect.

National Models, Portfolios, Councils and Desks provide the grounding. Regional Councils and Hubs organize cross-border additionality. Foundry provides persistent interoperability. Nexus Universe provides the recurring proving environment. The Leadership Ledger preserves the human contribution architecture across layers.

Federation therefore emerges from functioning nodes rather than replacing them.

***

#### 24.4.2 Federation should begin with real shared systems

Regional architecture should be organized around material cross-border relationships.

These may include water systems, power interconnections, transport corridors, health risks, ecosystems, supply chains, telecommunications, cyber dependencies, critical minerals, finance or another system whose operation exceeds National boundaries.

The purpose is not to create Regional bureaucracy.

It is to make shared dependencies more governable.

A Region becomes institutionally meaningful when participating countries can identify questions they understand better together than separately.

***

#### 24.4.3 Regional Councils should create additionality

The Regional Leadership Council should not reproduce the agendas of National Councils in aggregate.

Its role is to address cross-border questions, comparative learning, shared risk, federation, interoperability and Regional institutional relationships.

National Chairs may provide important bridges, while direct Regional leaders add capabilities that exist naturally at the Regional scale.

The Council's existence should be justified by the additional intelligence and capability it creates.

Where that additionality is weak, the Regional layer should remain proportionate rather than expanding administratively for its own sake.

***

#### 24.4.4 Regional Hubs should connect National Desks

By Federate, the Regional Hub should increasingly become a persistent operating interface among participating National systems.

Its purpose is not to command National Desks.

It should maintain cross-border work, Regional Portfolio state, shared learning, comparative intelligence, Council continuity and annual Universe coordination.

It may also host specialist capability that becomes more efficient or effective at Regional scale.

The Hub should remain service infrastructure.

Hosting and operating centrality do not create constitutional superiority.

***

#### 24.4.5 Regional Portfolios should preserve National provenance

A Regional Portfolio should organize shared risks and opportunities without flattening the countries from which they arise.

Participating National systems should remain visible.

Different readiness states, institutional responsibilities, evidence conditions and National priorities should remain identifiable.

The Region adds the relationships among them.

This creates a federated systems view rather than a centralized replacement for National Portfolios.

Regional maturity depends on maintaining both **shared system intelligence and differentiated National reality**.

***

#### 24.4.6 Foundry interoperability becomes strategically important

Federation places greater demands on technical architecture.

The system must support common semantics, identity and capacity context, controlled information exchange, cross-border analysis, multiple jurisdictions, National data sovereignty and Regional views without turning technical integration into institutional collapse.

Shared interfaces should make collaboration easier.

They should not erase provenance.

The federation should therefore mature toward governed interoperability rather than one undifferentiated Global data environment.

***

#### 24.4.7 Leadership federation should become multidirectional

National leaders should be able to contribute Regionally where appropriate. Regional leaders should support National work where their capability is useful. Direct Global leaders may contribute to Regional or National Missions. Cross-Regional Working Groups should connect systems where geography requires it.

The Leadership Ledger should preserve these contributions without forcing the member to abandon their primary home.

This makes the federation more capable.

It also prevents geographic layers from becoming rigid career ladders.

***

#### 24.4.8 Universe should integrate multiple scales

By the federation stage, Nexus Universe should become capable of bringing National, Regional and Global questions into one coherent annual cycle without collapsing their distinctions.

A National scenario may expose a Regional dependency. A Regional infrastructure test may reveal a Global supply-chain issue. A Global technology question may need National validation.

Universe provides the environment in which these scales can encounter one another.

The objective is not one enormous event.

It is one integrated learning architecture capable of preserving the distinct institutional meaning of each scale.

***

#### 24.4.9 Federation should strengthen weaker nodes

Regional capability should not become valuable only to the most mature National systems.

Where appropriate, Regional Hubs and experienced National nodes should help less mature systems access methods, training, intelligence and technical capability that accelerate their own National formation.

This support should avoid dependency.

The purpose is to raise the capability of the federation by strengthening the nodes within it.

A federation is ultimately limited by its weakest critical dependencies.

***

#### 24.4.10 Federate succeeds when cooperation becomes easier without authority becoming centralized

The strongest indicator of federation maturity is increasing interoperability with decreasing need for ad hoc central control.

National systems know how to connect. Regional Portfolios are understandable. shared evidence can travel with provenance. Chairs and Desks understand their interfaces. Foundry supports the workflow. Universe tests it.

The architecture becomes more coherent while authority remains distributed.

That is the institutional achievement of Federate.

***

### 24.5 2029: Institutionalize

#### 24.5.1 Institutionalization means capability survives normal transition

We define **2029 Institutionalize** as the stage in which Nexus must demonstrate that its core capabilities can persist through leadership, staffing, funding, technology and programme change.

By this stage, the system should no longer depend excessively on founding energy.

Councils should possess succession. Desks and Hubs should preserve continuity. Leadership records should be durable. National Models and Portfolios should survive personnel changes. Foundry should remain operable beyond one technical team. Universe should recur through a stable annual operating method.

Institutionalization is where the architecture begins proving that it can outlive its founding cycle.

***

#### 24.5.2 Succession becomes a primary institutional test

Earlier stages can tolerate some concentration in founding leaders.

Institutionalize cannot.

By 2029, major Councils and operating functions should possess credible successor depth. Chairs should not be irreplaceable. Working Groups should not collapse when one Lead leaves. National relationships should not exist only inside one person's contact list.

Succession must become visible across the leadership system.

The question changes from **“Who can lead this now?”** to **“Can this capability continue through the next leadership transition?”**

***

#### 24.5.3 Operating functions should become durable institutions

National Desks, Regional Hubs, Secretariats, programme teams and other persistent functions should become sufficiently institutionalized that their responsibilities are clear, documented and supportable.

This may involve different legal, operating or host arrangements according to context.

The important condition is not uniform legal structure.

It is durable capability.

The operating function should know what it owns, what records it maintains, how it interfaces with Councils and what resources it requires to continue.

Institutionalization converts temporary programme effort into recurring operating capacity.

***

#### 24.5.4 National Models and Portfolios should become recurring institutional objects

The National Model should no longer be treated as a one-time analytical product.

The National Portfolio should not remain a static strategy document.

Both should become living institutional objects capable of update as evidence, priorities, programmes and risks change.

This requires ownership, methods, data, operating responsibility and recurring review.

A system becomes institutionalized when important knowledge objects possess a lifecycle independent of the particular people who first created them.

***

#### 24.5.5 Foundry should become replaceable at the component level without losing institutional state

Technical institutionalization requires more than stable software.

The wider architecture should avoid unnecessary dependence on one vendor, interface, model provider or technical implementation where such dependence would threaten continuity.

Foundry may evolve significantly over time.

Institutional state, evidence, identity, Portfolios, leadership history and core operating logic should remain recoverable and governable as technology changes.

This is the technical equivalent of leadership succession.

A mature system survives component replacement.

***

#### 24.5.6 Universe should become part of the operating calendar

By 2029, Nexus Universe should function as a recognized annual integration, testing, correction and renewal cycle within the wider architecture.

Its value should no longer depend principally on novelty.

National and Regional systems should prepare for it because the cycle helps them test priorities, identify dependencies, generate evidence and update their next-state plans.

After-action review and correction should feed directly into the subsequent annual cycle.

Universe becomes institutionalized when it is expected because it is useful, not merely because it is traditional.

***

#### 24.5.7 The Leadership Ledger should support institutional continuity across people and years

By Institutionalize, the Leadership Ledger should make the leadership history of Nexus increasingly intelligible.

The system should know who contributed, in what capacity, through which Council, under what Plan, with what evidence and what happened afterward.

This enables better succession, opportunity routing, governance consideration and institutional learning.

It also prevents history from becoming dependent on informal recollection.

The Ledger becomes part of the governance infrastructure of the Leadership System.

***

#### 24.5.8 Resource models should become more durable

A system dependent on one temporary grant, sponsor or founding resource pool remains institutionally fragile.

By 2029, National, Regional and Global capability should increasingly possess diversified and legitimate resource pathways appropriate to their functions.

The exact model may vary.

The deeper requirement is that resources support the institution without purchasing constitutional control or distorting public-good purpose.

Financial continuity and institutional independence should mature together.

***

#### 24.5.9 Institutionalization should reduce hidden founder dependence

Founders can remain influential and valuable.

Their knowledge should increasingly be represented through institutions, documentation, leadership depth and repeatable methods rather than remain indispensable private capital.

This is not a diminishment of founding contribution.

It is its institutional completion.

A founder who successfully transfers capability has helped create an institution.

A founder whose departure would end the capability has created something less durable.

***

#### 24.5.10 Institutionalize succeeds when the system can survive a difficult year

One of the strongest tests of institutionalization is resilience under disruption.

Could a Council continue if its Chair leaves unexpectedly? Could a National Nexus maintain its Portfolio through political transition? Could Foundry preserve critical state through a technical migration? Could Universe proceed if one major sponsor withdraws? Could leadership records survive turnover in the operating team?

A system that can continue through ordinary disruption has begun to become institutional.

Resilience is the evidence of institutionalization.

***

### 24.6 2030: Scale

#### 24.6.1 Scale is the expansion of institutional capability without dilution of standards

We define **2030 Scale** as the stage in which Nexus should be capable of expanding National, Regional and Global coverage while preserving the principles established throughout this Handbook.

Growth alone is not the objective.

The architecture should be able to support more leaders, countries, Portfolios, evidence, institutional partners, Foundry users and Universe activities without losing authority boundaries, National ownership, evidence quality or institutional memory.

Scale therefore asks whether the architecture remains coherent under substantially greater complexity.

***

#### 24.6.2 Scale should follow demonstrated capability

Nexus should not scale a component merely because there is demand for it.

The underlying method should possess enough evidence and institutional maturity to justify wider replication.

A weak Council formation model should be corrected before rapid expansion. A technical workflow that depends on heavy bespoke support should not be presented as scale-ready. A Regional architecture that has not demonstrated additionality should not be multiplied.

Scale magnifies both strengths and defects.

The responsible sequence is therefore **validate before multiplying**.

***

#### 24.6.3 Scale should preserve National ownership

A large Global architecture can create pressure toward standardization and centralization because these approaches often appear administratively efficient.

Nexus should resist efficiency models that weaken the institutional foundations of the system.

National Models and Portfolios should remain nationally grounded. National Councils should retain contextual intelligence. Regional systems should create additionality rather than hierarchy. Global structures should synthesize and support interoperability.

Scale should make National capability more connected.

It should not make National capability less meaningful.

***

#### 24.6.4 Scale requires stronger, not weaker, zero-trust architecture

As the number of participants grows, personal familiarity decreases.

Identity, institutional affiliation, Council assignment, office, governance state, delegation, professional assignment and active capacity must therefore become more reliable technically and institutionally.

The small founding network may resolve ambiguity through conversation.

A global federation cannot.

Scale requires policy-aware access, governed identity, capacity separation, reliable records, correction and human review precisely because more participants will not know one another personally.

Zero trust becomes a condition of scale.

***

#### 24.6.5 Scale requires mature evidence infrastructure

The Leadership Ledger and wider evidence architecture must support increasing volume without turning contribution into a leaderboard or losing provenance.

National and Regional Portfolios will generate more states. Universe will produce more tests. Foundry will integrate more intelligence. Research and programmes will produce more claims.

Evidence should become easier to route and compare without becoming detached from context.

The test is whether the system can become larger while remaining capable of answering:

**Who claims this? What evidence supports it? Which institution owns the fact? What state has actually been reached?**

***

#### 24.6.6 Scale requires distributed operating capability

A global architecture cannot be operated sustainably by one central team performing every National and Regional function.

By 2030, leadership formation, Desk capability, Council support, evidence administration, Foundry use, Universe preparation and other operating functions should become increasingly distributed through trained and accountable nodes.

GCRI Canada can continue operating common NLS infrastructure and coordinating across the leadership architecture.

The federation must nevertheless develop substantial operating capability beyond one centre.

Scale is achieved when the system contains **many capable nodes connected by common rails**.

***

#### 24.6.7 Scale should expand learning faster than bureaucracy

As Nexus grows, new layers of administration can accumulate quickly.

The institutional objective should remain to increase useful capability faster than coordination burden.

Common methods, Foundry workflows, reusable templates, trained Desks, federation interfaces and clear authority boundaries should reduce the amount of bespoke coordination required per new node.

A scalable system becomes easier to replicate because its operating grammar is clearer.

If each additional country creates exponentially more central administration, the architecture has not yet become truly scalable.

***

#### 24.6.8 Scale should preserve anti-capture

Expansion can create substantial economic, technological and institutional power around Nexus.

Larger funders may emerge. Major technology providers may become important. Influential governments and institutions may seek deeper roles. Prominent leaders may develop significant informal authority.

The anti-capture principles established in Part XIX therefore become more important at scale.

No funder, provider, host, country, leader or operating institution should gain silent control over the common public-good architecture merely because the federation depends heavily upon its resources.

Scale without independence would undermine the purpose of the system.

***

#### 24.6.9 Scale should make the architecture globally intelligible without claiming universal authority

By 2030, the Nexus proposition should become increasingly understandable to governments, international organizations, financial institutions, standards bodies, research institutions, enterprises and civil society as a common operating architecture for systemic risk and readiness.

Global intelligibility is valuable.

It does not create supranational authority.

Nexus can support nationally owned, regionally informed and globally intelligible capability while remaining clear that legitimate public, institutional and regulated authority stays with the competent actors.

Scale increases reach.

It should not inflate mandate.

***

#### 24.6.10 Scale succeeds when expansion strengthens rather than weakens the architecture

The final question is straightforward:

**Does the hundredth node become easier and safer to establish because the first ninety-nine generated reusable capability, or does expansion require the institution to compromise its standards to move faster?**

Successful scale should improve consistency, learning, tooling, federation and support.

The system should become more capable because it has grown.

Growth that produces weaker evidence, thinner Councils, more ambiguous authority or greater dependency is not mature scale.

It is uncontrolled expansion.

***

### 24.7 National, Regional and Global Capacity

#### 24.7.1 Institutionalization requires capability at all three scales

The 2026-2030 programme should not create a strong Global layer above weak National systems.

Neither should it create isolated National nodes incapable of understanding cross-border dependencies.

We therefore develop National, Regional and Global capability as complementary layers.

National systems provide depth and ownership.

Regional systems provide cross-border additionality.

Global systems provide cross-regional synthesis, frontier attention and common learning.

The maturity of Nexus depends on the relationships among these layers, not on the dominance of any one of them.

***

#### 24.7.2 National capacity remains foundational

By 2030, a mature National Nexus should increasingly possess a functioning Leadership Council, leadership depth, Desk and Secretariat capability, National Model, National Portfolio, Risk Docket, Working Groups, Foundry access, annual Universe participation, institutional relationships, evidence practices and succession pathways appropriate to its context.

Not every country will reach the same maturity.

The common expectation is that National capability should increasingly become locally intelligible, owned and supportable.

The country should not require an external federation layer to explain its own National system to itself.

***

#### 24.7.3 Regional capacity should create economies of capability

Regional systems can provide capabilities that may be inefficient for every country to develop independently.

Comparative intelligence, specialist research, shared scenarios, cross-border infrastructure analysis, Regional workforce development or other functions may become stronger when organized collaboratively.

The Regional Hub can support these economies while National systems remain grounded.

Regional capability should therefore reduce duplication where shared capability makes sense without forcing centralization where National ownership matters more.

The relevant architecture is selective federation.

***

#### 24.7.4 Regional systems should develop resilience of their own

A Regional federation should not depend exclusively on one National node.

Leadership, operating capacity, data, relationships and resources should become sufficiently distributed that the Region remains viable through changes in any one country.

This is particularly important where one larger country or institution provides the initial host.

Hosting can accelerate formation.

Mature federation should reduce the risk that the host becomes the permanent centre upon which all other participants depend.

Regional resilience requires plural institutional foundations.

***

#### 24.7.5 Global capacity should focus on what cannot be achieved below

The Global layer should remain selective.

Its highest-value functions include cross-regional learning, frontier-risk attention, interoperability, global methods, relationships with relevant international institutions, comparative intelligence and stewardship of the common architecture.

Functions that remain better handled Nationally or Regionally should stay there.

Global capability becomes stronger by resisting unnecessary scope.

A mature federation does not route every issue upward.

It places each issue at the scale where legitimate capability is strongest.

***

#### 24.7.6 The Leadership Ledger connects human capability across scales

National, Regional and Global structures all depend on leaders.

The Leadership Ledger allows those leaders' contributions, offices, Plans, evidence and transitions to remain intelligible as they move across the federation.

This prevents federation from creating disconnected identities and parallel leadership histories.

A National leader contributing to a Regional Mission should retain one coherent leadership journey. A Global specialist supporting a country programme should not require a second institutional identity.

The human architecture should federate as coherently as the technical and programme architecture.

***

#### 24.7.7 Foundry provides the persistent interoperability layer

Foundry supports persistent intelligence, evidence, Portfolios, Council work, identity and capacity, Missions, learning and other capabilities across the system.

As the federation grows, its most important role is not merely application functionality.

It is the preservation of common operating semantics across differentiated institutions and geographies.

Foundry should make National, Regional and Global cooperation easier while respecting the authority and information boundaries of the institutions involved.

Technical interoperability supports institutional federation.

It does not replace it.

***

#### 24.7.8 Universe provides the recurring integration layer

Nexus Universe connects otherwise persistent structures through an annual cycle of preparation, integration, testing, action, evidence, after-action review and correction.

At National scale, Universe can test country systems and Portfolios.

At Regional scale, it can test cross-border dependencies.

At Global scale, it can expose cross-regional patterns and frontier questions.

The annual cycle creates temporal federation alongside geographic federation.

It gives the system a recurring moment in which distributed capabilities can encounter one another and return with a shared correction agenda.

***

#### 24.7.9 Capacity should remain polycentric

The mature Nexus architecture should contain several centres of legitimate capability.

National Councils, Desks, Regional Hubs, GCRI, GRF, GRA, GCRI Canada, Foundry, Universe and other institutional actors each perform different functions.

No single node needs to become the universal centre of all leadership, evidence, finance-readiness, technology, governance and delivery.

The federation becomes more resilient when capability is distributed according to institutional function and connected through common rails.

Polycentricity is therefore not an interim condition.

It is part of the intended architecture.

***

### 24.8 Continuity Beyond 2030

#### 24.8.1 2030 is a strategic horizon, not an institutional expiry date

The 2026-2030 Founding Cycle establishes a common period for proving and institutionalizing the architecture.

The underlying systemic-risk and readiness challenges will not end in 2030.

Nor should useful National Councils, Desks, Models, Portfolios, Foundry capabilities, Universe cycles, knowledge systems and leadership relationships dissolve merely because the founding strategy reaches its formal horizon.

The purpose of institutionalization is precisely to ensure that useful capability survives the strategy that first created it.

2030 should therefore represent a transition from **founding architecture to enduring institutional infrastructure**.

***

#### 24.8.2 Post-2030 continuity should be evidence-led

Not every component developed during the Founding Cycle should continue automatically.

Some methods may prove weak. Some structures may become unnecessary. Some technologies may be replaced. Some Councils may require redesign.

Continuity should preserve what has demonstrated value.

The system should remain capable of retiring what no longer serves the mission.

Institutionalization does not mean making every founding decision permanent.

It means creating institutions capable of deciding intelligently what should continue, change or conclude.

***

#### 24.8.3 The public-good institutions should remain differentiated

Continuity beyond 2030 should preserve the differentiated functions of GCRI, GRF and GRA unless the competent institutions themselves determine otherwise through legitimate processes.

Their separation allows different forms of judgment and institutional responsibility to remain appropriately housed.

Common infrastructure can deepen.

Shared leadership processes can become more sophisticated.

The federation can become more interoperable.

Institutional continuity should not require legal or functional collapse.

Coordination without institutional collapse remains a long-term design principle.

***

#### 24.8.4 GCRI Canada should continue operating common NLS infrastructure only within its proper role

Our stewardship of the common Leadership System can continue where it remains useful and properly constituted.

That role includes operating shared processes, records, leadership infrastructure and coordination environments across the Nexus leadership architecture.

It should not become a basis for assuming authority belonging to independent Nexus institutions, National systems, governments or external actors.

The mature architecture should make this distinction easier to see, not harder.

The common system can become more powerful while its authority boundaries become clearer.

***

#### 24.8.5 National continuity should become increasingly self-sustaining

The strongest post-2030 National systems will be those capable of renewing leadership, maintaining their Desk, updating their Model and Portfolio, participating in federation and using Foundry and Universe without depending continuously on exceptional external intervention.

External and federation support can remain valuable.

National capability should nevertheless become sufficiently embedded that core functions remain durable domestically.

This is the long-term meaning of sovereign-grounded institutionalization.

***

#### 24.8.6 Regional continuity should follow enduring shared systems

Regional structures should persist where material cross-border dependencies continue to justify them.

A Regional Hub or Council should not survive merely because it was established during the Founding Cycle.

Its continued legitimacy should derive from the additional capability it provides to participating National systems.

Some Regional functions may grow more important after 2030 as climate, infrastructure, trade, digital and other dependencies deepen.

Others may become less necessary.

Federation should remain adaptive.

***

#### 24.8.7 Global continuity should focus on learning and interoperability

Beyond 2030, the Global layer should continue helping the federation identify recurring patterns, emerging risks and common operating methods while preserving National and Regional context.

Its strongest role remains synthesis rather than command.

A mature Global Council should become a steward of the federation's ability to learn, compare, anticipate and improve its common architecture.

The more mature the National and Regional systems become, the less the Global layer should need to compensate for weak local capability.

Global maturity should therefore be visible partly through **stronger systems below it**.

***

#### 24.8.8 Leadership continuity should include generational renewal

The leaders who establish Nexus during the Founding Cycle should not be expected to remain its permanent leadership class.

By 2030 and beyond, new leaders should be entering Councils, assuming offices, developing National capability and contributing to federation.

Founders and early leaders can remain important stewards, mentors, governors or alumni where appropriate.

Institutional legitimacy requires space for successor generations to lead.

A system that cannot renew its leadership has not institutionalized fully.

***

#### 24.8.9 Knowledge continuity should outlast individual programmes

Research, methods, lessons, Models, evidence and other institutional knowledge generated during 2026-2030 should remain usable after the programmes that produced them conclude.

The information and knowledge architecture established in Part XX therefore becomes central to post-2030 continuity.

Public-good knowledge should remain accessible where appropriate. Restricted knowledge should remain governed. Attribution should survive. Corrections should remain possible.

A mature institution accumulates knowledge without becoming trapped by outdated knowledge.

***

#### 24.8.10 Technical continuity should assume technological change

The technologies supporting Nexus in 2035 will not be identical to those supporting it in 2026.

Foundry should therefore be understood as persistent institutional capability rather than one frozen implementation.

Interfaces, compute environments, AI systems, geospatial technologies, security models and deployment architectures will change.

The underlying operating objects should remain intelligible through those changes: identity, capacity, evidence, Models, Portfolios, Councils, Plans, contributions, handoffs and institutional states.

Technical evolution should improve the infrastructure without destroying institutional continuity.

***

#### 24.8.11 The institutionalization proposition

The complete 2026-2030 institutionalization programme can therefore be expressed as:

**2026 Adopt:** prove that the architecture can operate.\
**2027 Replicate:** prove that the architecture can travel.\
**2028 Federate:** prove that distinct systems can interoperate.\
**2029 Institutionalize:** prove that capability can survive transition.\
**2030 Scale:** prove that the architecture can grow without losing integrity.

The post-2030 question then becomes:

**Can the system continue learning, renewing leadership and adapting to new systemic conditions without returning to founder dependence, institutional fragmentation or centralized control?**

That is the deeper institutional test of the Founding Cycle.

***

## PART XXIV FRAMEWORK PRINCIPLES

**Maturity before milestone.** Adopt, Replicate, Federate, Institutionalize and Scale describe changes in capability rather than annual branding. We treat each stage as a test of what the system can now do reliably: operate, travel, interoperate, endure and expand. Calendar time can organize the programme, but institutional evidence determines whether a capability has actually matured.

**National grounding with federated additionality.** The 2026-2030 programme begins from National capability because systemic leadership requires country-level institutional depth. Replication should preserve local ownership, federation should create genuine cross-border additionality, and Global synthesis should strengthen the systems beneath it. Wider geographic scale never becomes constitutional superiority.

**Persistent infrastructure over episodic activity.** Councils require Desks, Models require maintenance, Portfolios require recurring review, leadership requires a Ledger, Foundry provides year-round operating continuity, and Nexus Universe provides the recurring proving and correction cycle. Institutionalization is achieved when these objects survive meetings, events, projects and leadership transitions rather than being recreated repeatedly.

**Distributed capability with common operating grammar.** Scale requires more capable National and Regional nodes, not ever-growing dependence on one centre. GCRI Canada operates the common NLS system and coordinates across the leadership architecture, while GCRI, GRF, GRA, National systems and other competent institutions retain their differentiated responsibilities. Common semantics, evidence, identity, protocols and technical rails enable interoperability without requiring institutional collapse.

**Continuity through correction and renewal.** The objective of the Founding Cycle is not to freeze the architecture designed between 2026 and 2030. It is to create institutions capable of preserving what works, correcting what fails, replacing obsolete technology, renewing leadership and continuing useful public-good capability beyond the founding horizon. A mature Nexus system should be capable of outliving both its first strategy and its first generation of leaders.

***

## OPERATING RELATIONSHIP

Part XXIV places the full Nexus Leadership System inside a five-stage institutionalization programme.

**2026 Adopt** establishes the operating architecture. National Councils, Desks, Annual Leadership Contribution Plans, National Models and Portfolios, Foundry, Universe and the Leadership Ledger begin functioning as one connected system. The objective is not perfection. It is credible first use accompanied by evidence and correction.

**2027 Replicate** tests whether validated architecture can travel into new National and institutional contexts without becoming dependent on the original builders. Common methods should become reusable, while National systems retain the ability to adapt them legitimately to local institutions, risks and operating conditions.

**2028 Federate** connects several National systems around genuine cross-border dependencies. Regional Councils, Hubs and Portfolios create additionality while preserving National ownership. Foundry supplies persistent interoperability, Universe supplies annual integration and the Leadership Ledger allows human contribution to remain coherent across layers.

**2029 Institutionalize** tests whether capability can survive ordinary disruption. Leadership succession, recurring operating capacity, durable Models and Portfolios, stable information architecture, resource continuity, annual Universe cycles and reduced founder dependency become central.

**2030 Scale** tests whether the architecture can expand materially without weakening the qualities that made it legitimate. More countries, leaders, data, institutions, technologies and programmes require stronger evidence, identity, integrity, anti-capture, National ownership and distributed operating capability rather than weaker controls.

Across all five stages, the sequence should remain cumulative. Replication should not erase adoption. Federation should not erase National ownership. Institutionalization should not freeze weak methods. Scale should not sacrifice integrity for speed.

Foundry and Universe perform complementary roles throughout the programme. **Foundry is the persistent operating platform and capability stack. Universe is the recurring annual integration, testing and institutionalization programme around it.** The Leadership Ledger preserves longitudinal human and institutional memory. National Models and Portfolios convert systemic intelligence into recurring objects of leadership and readiness. Councils provide strategic human capability. Desks and Hubs provide persistence. GCRI, GRF and GRA retain differentiated institutional functions.

The governing proposition of Part XXIV is therefore:

> **The 2026-2030 Founding Cycle is successful only if Nexus moves from something that capable founders can operate to something that many capable institutions can operate, adapt, federate, renew and improve without surrendering National ownership, institutional independence, evidence discipline or public-interest purpose. The objective of scale is not to make Nexus larger than every participating institution. It is to make cooperation among those institutions more capable, durable and intelligible.**

## NEXT

## PART XXV: PRACTICAL LEADER GUIDE

### The First 30 and 90 Days, Building the Annual Leadership Contribution Plan, Quarterly Review, Nexus Universe, Recording Contribution, Raising Concerns, Working Nationally and Regionally, Multiple Capacities and the Year-One Gateway

Part XXV will translate the full NLS architecture into the practical operating journey of an individual leader. It will define what a new member should do during the first 30 and 90 days, how to build and use the Annual Leadership Contribution Plan, how quarterly review works, how to prepare for Nexus Universe, how contribution enters the Leadership Ledger, how to raise concerns, how to contribute to a National Nexus and across Regional or Global systems, how to operate when holding multiple capacities, and how to prepare for the Year-One Gateway, Council-office consideration and any later governance pathway.

## Sources

1. ISO (2018). ISO 31000:2018 Risk management — Guidelines. Geneva: International Organization for Standardization. [www.iso.org/standard/65694.html](https://www.iso.org/standard/65694.html)
2. OECD (2014). Recommendation of the Council on the Governance of Critical Risks. OECD/LEGAL/0405. [legalinstruments.oecd.org/en/instruments/OECD-LEGAL-0405](https://legalinstruments.oecd.org/en/instruments/OECD-LEGAL-0405)
3. UN General Assembly (2024). The Pact for the Future, with the Global Digital Compact. A/RES/79/1. [undocs.org/A/RES/79/1](https://undocs.org/A/RES/79/1)

**Standards that apply.** Masters: [Communities, Learning and Contribution](https://nexustandards.com/communities/) (PLANNED); [Governance, Security and Society](https://nexustandards.com/society/) (PLANNED). Standards: [NS-0](https://nexustandards.com/standards/ns-0/) (PROPOSED), [NS-1](https://nexustandards.com/standards/ns-1/) (PROPOSED), [NS-2](https://nexustandards.com/standards/ns-2/) (PROPOSED), [NS-3](https://nexustandards.com/standards/ns-3/) (PROPOSED), [NS-3b](https://nexustandards.com/standards/ns-3b/) (PROPOSED), [NS-4](https://nexustandards.com/standards/ns-4/) (PROPOSED), [NS-5](https://nexustandards.com/standards/ns-5/) (PROPOSED), [NS-8](https://nexustandards.com/standards/ns-8/) (PROPOSED), [NS-9](https://nexustandards.com/standards/ns-9/) (PROPOSED), [NS-10](https://nexustandards.com/standards/ns-10/) (PROPOSED), [NS-11](https://nexustandards.com/standards/ns-11/) (PROPOSED), [NS-12](https://nexustandards.com/standards/ns-12/) (PROPOSED), [NS-13](https://nexustandards.com/standards/ns-13/) (PROPOSED). Statuses are registry statuses on nexustandards.com, never adoption or certification.

**In the GitBook.** [Programme](/organization/programme.md) · [Governance in operation](/organization/governance-in-operation.md) · [Systems](/organization/systems.md) · [Reference](/organization/reference.md).


---

# 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/operations/frameworks/nexus-leadership-system-nls/xxiv.-institutionalization-programme.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.
