> 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/introduction/operations/ii.-frameworks.md). # II. Frameworks The framework layer of Nexus operations: the Nexus Agile Framework, the Sustainable Competency Framework and the digital public goods framework. **Where this fits:** all six sectors · the Foundry pillar and Risk Academy · GCRI and the National Working Groups · Controlled build and Renewal · doctrine · read with [The Model](/organization/model.md), [Programme](/organization/programme.md), [Governance in operation](/organization/governance-in-operation.md) and [Reference](/organization/reference.md).
Document record · Draft · Legal review required · Updated 21 October 2026 | | | | ---------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Status** | Draft. Explanatory page; it creates no rights or obligations. | | **Legal review** | Required before final publication. | | **Version** | 2026.10.21-r3 | | **Updated** | 21 October 2026 · reviewed every 180 days | | **Owner** | Documentation desk (named reviewer pending) | | **Based on** | Nexus constitutional directives D-V3-0003 (*Twenty-system constitution*) and D-V3-0004 (*One Rail-Two Stacks and non-execution*); the owner decision of 11 October 2026 on Nexus institutional architecture and participation; the Universal Runtime directive V7, section 2.5, in the Nexus institutional register; the Nexus Documentation Standard (draft of 16 October 2026); the sites' model, the Nexus Consortium model, the [Nexus Standards](/organization/institutions/nexus-standards.md) feeds and the owner rulings of 21 October 2026 (source pack) | | **Corrections** | Public corrections route to be announced; corrections are published as new dated versions. |
## In brief A framework, in this documentation, is a method-bearing instrument that says how a kind of work should move, who must be competent to carry it and how shared digital assets stay governed. The framework layer of Nexus operations sets out three core frameworks: the Nexus Agile Framework (NAF) for moving work, the Sustainable Competency Framework (SCF) for building competence, and the Distributed Digital Public Goods Framework (DDPGF) for stewarding digital public assets. Frameworks guide work; they adopt nothing, certify nothing and execute nothing \[3]\[9]. {% hint style="success" %} **Aligned to the current model (21 October 2026).** This page was brought up to date with the sites' model, the Nexus Consortium model, the live public sites and the owner rulings (see [Reference](/organization/reference.md) and the [Sources library](/organization/reference/sources.md)). Where the earlier design text below differs, these points govern: * The three frameworks map onto the current programme: the Nexus Agile Framework describes how work moves through the [Foundry pillar](/organization/programme/foundry.md)'s builds and the Universe gates; the Sustainable Competency Framework describes the competence that [Risk Academy](/organization/institutions/risk-academy.md) teaches and that NWG assignments require; the Distributed Digital Public Goods Framework describes stewardship of shared assets under the Nexus Standards and the UN DPI safeguards \[20]\[21]\[22]. See [Programme](/organization/programme.md). * Competence is shown through bounded, supervised NWG assignments and their contribution records, not through a cell structure \[21]. See [NWG](/organization/governance-in-operation/nwg.md). * Risk Academy hosts the courses and the institutions author them; completion is recorded, not credentialed, until an issuer, an assessment method and a revocation path are on record, with GCRI Canada as issuer of record, and a completion record is not a licence to practise \[23]. See [Risk Academy](/organization/programme/academy.md). * Standards for the records that frameworks produce are developed in the open under NS-13 and checked for conformance under NS-14; adoption is decided by each jurisdiction \[24]\[25]\[26]. See [Nexus Standards in the programme](/organization/programme/standards.md). * Everything described here is in formation. No national programme is recorded as constituted or active, and the current service level is R0, information and enquiries \[27]. See [Status and service levels](/organization/governance-in-operation/status-and-service-levels.md). {% endhint %} {% hint style="info" %} **How to read this page.** This page explains a design; it creates no obligation and records no adopted framework. Where the text uses the present tense or "must" and "should", it states the intended discipline of the design, not an adopted rule or a running service. The deep reference pages for each framework live in the [Operations part](/organization/operations/frameworks.md). {% endhint %} ## Status, scope and terms of this page **Status in the five-state grammar.** For each framework below: Target: described in this documentation as a method design, not defined in a V3 directive \[5]\[9]. Implemented: No record (no adoption record for any framework is cited). Verified: No record. Observed: No record. Accepted: No record. The consortium programme states the current service level as R0, "Information and enquiries" \[4], and a target definition is not an implementation \[7]. | Framework | What it is designed to move | Deep reference | Adoption record | | -------------------------------------------------- | ------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------- | --------------- | | Nexus Agile Framework (NAF) | Work, across legal, governance, technical, lifecycle and deployment contexts | [Nexus Agile Framework (NAF)](/organization/operations/frameworks/nexus-agile-framework-naf.md) | No record | | Sustainable Competency Framework (SCF) | Competence, role readiness and progression | [Sustainable Competency Framework (SCF)](/organization/operations/frameworks/sustainable-competency-framework-scf.md) | No record | | Distributed Digital Public Goods Framework (DDPGF) | Digital public assets, software, data structures and shared systems | [Distributed Digital Public Goods Framework (DDPGF)](/organization/operations/frameworks/distributed-digital-public-goods-framework-ddpgf.md) | No record | | Nexus Leadership System (NLS) | Leadership formation; held in the deep reference but not summarized in the original chapter | [Nexus Leadership System (NLS)](/organization/operations/frameworks/nexus-leadership-system-nls.md) | No record | *Table 1. The framework set and its status. The original chapter describes three frameworks; the deep reference also holds a fourth, the Nexus Leadership System, which this page now names. Source: the Operations part of this site and the documentation standard \[9], as of 2026-10-16.* **Institutions.** The institutional roles that bear on this page are stated once, in register wording, on [I. Order of the Organization introduction](/organization/introduction/organization/i.-order.md) and summarized in [I. Order](/organization/introduction/operations/i.-order.md): GCRI Canada ([The Global Centre for Risk and Innovation](/organization/institutions/gcri.md)) is Lead Institution, Consortium Secretariat and lead contracting organization; [The Global Risks Forum](/organization/institutions/grf.md) (GRF) is a consortium steward for leadership, dialogue and [Nexus Universe](/organization/programme/universe.md) programme governance; [The Global Risks Alliance](/organization/institutions/gra.md) (GRA) is a consortium steward for the finance, insurance and development-readiness interface; and competent public authorities keep all sovereign, regulatory, fiduciary and operational decisions \[1]\[2]. Standards discipline sits with [NXS-NSF](/organization/systems/nxs-nsf.md), the trust, sovereignty and assurance plane for identity, policy gates and access decisions, and Nexus Standards is a proposed standards programme with no publisher of record \[5]\[9]. **Words that name systems or programmes.** "Foundry" here refers to a design area of this documentation; elsewhere in the Nexus records the build work belongs to the Foundry pillar and the technical architecture to the twenty Nexus systems. Where earlier design text speaks of "Studio" workflows, environments or runtime, this page names the system [NXS-STU](/organization/systems/nxs-stu.md), the builder and configuration workspace, which composes but never deploys; its remit is "visual composition, dashboards, maps, forms, workflow experiences, reusable artifacts and deployment profiles", and build and assembly belong to [NXS-FAC](/organization/systems/nxs-fac.md), the mission application factory \[5]. "Marketplace" has no V3 system of that name; the nearest are [NXS-NXQ](/organization/systems/nxs-nxq.md), the software, capability and agent fabric, for software, packages, connectors, models, entitlements and capability lifecycle, and [NXS-APP](/organization/systems/nxs-app.md), the mission app runtime, for the application catalog \[5]. "Registry", "Agency" and "recognition" are used in the general sense of recorded status and support; they do not describe a statutory register, a government agency or a recognition decision held by any named institution \[9]. "Sovereign" is used only for the powers of public authorities or as design intent for deployments under national control, subject to evidence for each deployment \[9]. {% hint style="info" %} **Nexus Observatory Protocol.** On this site, Nexus Observatory Protocol is the observation protocol owned by [NXS-OPS](/organization/systems/nxs-ops.md), the observatory protocol system, in collaboration with [NXS-EOP](/organization/systems/nxs-eop.md), the Earth observation, geospatial and digital-twin fabric, and [NXS-SIG](/organization/systems/nxs-sig.md), the authorized signal, spectrum and communications integrity system. Together these three systems form the observatory ecosystem. **Nexus of Observatories.** Every Nexus platform and system includes its own observatory capability, covering remote sensing, in-situ instruments and edge deployments. Across every area where these observatories are implemented, including implementation pilots in programme areas, they form the Nexus of Observatories, which is part of the not-for-profit programme architecture. On this site, "Nexus Observatory" refers only to this observatory capability and to the protocol above. {% endhint %} **Role words in older design text.** Where this chapter refers to "GRF recognition", "GRF claims review", "GRA routeability review" or "protocol" review, it describes functions in the earlier design text of this corpus. An older binding instrument, the Universal Runtime directive V7 (section 2.5), associates GRF with registry, recognition and maturity records, claims discipline, stakeholder formation and public-safe reporting, and GRA with finance and insurance readiness and diligence translation \[10]. The current public wording does not present GRF as a recognition, conformance or certification body, and GRA "does not lend, underwrite, rate, invest, advise on or arrange transactions, and readiness work is not approval" \[8]. How the two wordings are reconciled awaits owner decision (conflict X-23 in the documentation standard) \[9]. **Research-outlook topics.** Where NAF lists tokenization, or foresight lists blockchain and decentralized physical infrastructure networks (DePIN), these are research-outlook topics, not Nexus architecture: no institutional record shows them as part of the design \[9]. {% hint style="info" %} **Earlier council labels.** This page keeps some labels from earlier versions of this corpus (`Nexus Competence Cells`). They are now mapped to the current model (rulings R3 to R5 of 21 October 2026, following the Nexus Consortium model \[28]): Competence Cells to National Working Group assignments and the CERTs; Helix Councils, in the earlier sense, to the six Helix councils of the NNC; Investor Councils to the Financial Institutions and Regulators pathway, led with GRA; National Councils to the NLC or the NNC by function; Council Bureau and Technical Secretariat to the Consortium Secretariat held by GCRI Canada. Where they appear below they describe earlier design text, not current or constituted bodies; [Councils](/organization/governance-in-operation/councils.md) and the [Reference](/organization/reference.md) glossary hold the mapping \[8]\[9]. {% endhint %} ## The framework stack at a glance
The framework stack as a design. NAF moves work, SCF forms competence and DDPGF stewards digital public assets; all three shape the operating spine, and NLS feeds leadership formation into SCF. The spine leads to working charters, then to reviewed outputs and records, which may be handed to competent actors.

Figure 1. The framework stack as a design: NAF, SCF and DDPGF shape the operating spine, which carries chartered work to reviewed outputs and handoff. A design, not a record of adoption or use. Source: this chapter, sections 2.3 and 2.4, and the Operations part, as of 2026-10-16.

Text description of Figure 1 On the left, the Nexus Leadership System (NLS) feeds leadership formation into the Sustainable Competency Framework (SCF). The framework stack has three members: the Nexus Agile Framework (NAF), which moves work; SCF, which forms competence; and the Distributed Digital Public Goods Framework (DDPGF), which stewards digital public assets. All three shape the operating spine, which runs from intake to archive. The spine carries work under working charters (drafts at level L4) to reviewed outputs and records; lessons from those outputs return to NAF as method improvement, as noted on the outputs card. Outputs may then be handed to competent actors, who decide on their own authority. The highlighted path runs from NAF through the spine and charters to the handoff.
## Summary This page defines the framework layer of Nexus Operations. If **I. Order** establishes Operation as the designed working order of the Nexus Ecosystem, **II. Frameworks** explains the methodological architecture that makes this working order disciplined, repeatable, reviewable, public-safe, transferable, and cumulative. Frameworks come first within Operation because a serious operating system must determine **how work is carried** before it decides who will carry it, how fast it should move, which tools will be used, what platforms will display it, which outputs will be published, or which realization pathway may eventually receive it. Nexus does not treat operations as a loose collection of tools or activities. It treats operations as a governed field of method. The framework layer is therefore the first formal proof that Nexus is designed to work under conditions of complexity, plurality, federation, public purpose, technical depth, and lawful realization. The framework layer includes, at minimum, three core instruments: * the **Nexus Agile Framework (NAF)**; * the **Sustainable Competency Framework (SCF)**; * the **Distributed Digital Public Goods Framework (DDPGF)**. These are not three unrelated methods. They form a framework stack. The **Nexus Agile Framework (NAF)** governs how complex work moves across institutional, legal, governance, economic, technical, participatory, lifecycle, foresight, partnership, and deployment contexts. The **Sustainable Competency Framework (SCF)** governs how people, teams, hosts, nodes, contributors, providers, public authorities, and institutions become capable of carrying that work responsibly. The **Distributed Digital Public Goods Framework (DDPGF)** governs how digital-public assets, software, data structures, protocols, platforms, registries, workflows, knowledge graphs, and shared operating systems are produced, maintained, reused, localized, and extended without losing public-good discipline. Together, these frameworks define the operating method of Nexus: how work moves, how competence forms, and how digital-public infrastructure remains governed across the ecosystem. This chapter treats these three frameworks as the core framework stack of Nexus Operations, and frameworks as the methodological architecture by which activity becomes disciplined, reviewable, cumulative, and transferable. *** ## 2.1 Why Frameworks Come First in Operation Frameworks come first in Operation because method must precede motion. A system can have strong institutions, ambitious public-good purpose, powerful technologies, capable partners, active contributors, and attractive implementation opportunities, yet still fail if it lacks a shared method for carrying work. Without frameworks, operating activity becomes dependent on habit, personal memory, local interpretation, hidden labor, ad hoc decision-making, and the uneven capabilities of whoever happens to be present. Nexus cannot rely on that. It operates across public-good institutions, governance bodies, councils, working groups, Digital Public Goods, standards systems, observatories, compute environments under national control, Marketplace objects, Foundry packages, NXS-STU workflows, Nexus Nodes, regional and national consortiums, public authorities, companies, hosts, sponsors, communities, and lawful execution pathways. The scale and complexity of that environment require method-bearing instruments that can travel across settings without losing coherence. Frameworks provide that discipline. They define how work is initiated, scoped, sequenced, reviewed, measured, corrected, published, handed off, and maintained. They create continuity between constitutional order and practical activity. They prevent operational speed from becoming operational drift. They allow work to be flexible without becoming vague, distributed without becoming fragmented, and innovative without becoming self-authorizing. In Nexus, frameworks are not optional templates. They are the methodological foundation of the operating system. *** ## 2.2 What a Framework Means in Nexus Within Nexus, a framework is a structured method-bearing instrument that governs how a class of work should be undertaken in alignment with the wider architecture. A framework is more durable than a project plan, more structural than a checklist, and more authoritative than a team preference. It links purpose, sequence, roles, boundaries, outputs, records, review, correction, and handoff discipline. It allows many actors to work within one architecture without reinventing the logic of work in each new context. A framework performs several functions at once. First, it stabilizes interpretation. It reduces the risk that the same mission language will produce materially different practices across teams, hosts, sectors, countries, or regions. Second, it enables transfer. It allows methods to move across people, institutions, projects, platforms, and time without relying entirely on oral culture or founder memory. Third, it structures accountability. It allows Nexus to ask whether work has followed an agreed operating logic rather than being justified only after the fact. Fourth, it preserves architectural fidelity. It connects daily activity to constitutional order, public-good distinctness, role separation, standards discipline, and non-execution boundaries. Fifth, it creates cumulative capability. Once a framework exists and is used, lessons can be absorbed back into the system rather than remaining isolated in one project, one person, one host, or one working group. A Nexus framework is therefore both a method and a memory structure. It makes work repeatable without making it mechanical. *** ## 2.3 The Framework Stack of Nexus The framework stack described in this chapter includes three principal instruments. The deep reference also holds a fourth, the Nexus Leadership System (NLS), listed in Table 1 above. ### 2.3.1 Nexus Agile Framework The **Nexus Agile Framework (NAF)** is the broadest working framework. It governs the movement of complex work across the architecture. It is not a narrow software-delivery method. It is a whole-system operating method for legal, governance, intellectual property, ownership, equity, acceleration, tokenization (a research-outlook topic, not Nexus architecture), revenue, capital, engagement, lifecycle, foresight, partnership, and deployment contexts. NAF answers the question: **How does work move responsibly through Nexus?** ### 2.3.2 Sustainable Competency Framework The **Sustainable Competency Framework (SCF)** governs capability formation, role readiness, skills architecture, progression, learning discipline, credential pathways, and the conversion of institutional need into governed human capacity. SCF answers the question: **How do people, teams, institutions, nodes, hosts, and providers become capable of carrying Nexus work responsibly?** ### 2.3.3 Distributed Digital Public Goods Framework The **Distributed Digital Public Goods Framework (DDPGF)** governs the production, maintenance, reuse, localization, interoperability, and public-good stewardship of digital-public infrastructure. DDPGF answers the question: **How do digital assets and shared systems remain distributed, interoperable, public-good-rooted, maintainable, and governed over time?** ### 2.3.4 The Integrated Stack These frameworks form a stack. NAF governs the movement of work. SCF governs the movement of competence. DDPGF governs the movement of digital-public infrastructure. Together, they form the methodological, human, and infrastructural spine of Nexus Operations. *** ## 2.4 Frameworks and the Operating Spine Frameworks are inseparable from the operating spine defined in **I. Order**. The operating spine describes how work moves from intake to triage, from routing to workstream assignment, from activity to output, from output to review, from review to publication or handoff, and from handoff to correction, archival, or decommissioning where required. Frameworks provide the method for that movement. A signal may enter through intake, but a framework helps determine how it should be classified. A proposal may become a workstream, but a framework helps determine scope, cadence, ownership, and review. A Digital Public Good may be created, but a framework helps determine stewardship, documentation, versioning, support, licensing, localization, and retirement. A contributor may join a working group, but a framework helps determine role readiness, learning pathway, expected conduct, and progression. A report may be drafted, but a framework helps determine evidence discipline, review, claims limits, public-safe status, and publication pathway. A Foundry package may be prepared, but a framework helps determine whether it is a prototype, pilot, release candidate, deployment package, or maintained public-good asset. Frameworks are therefore not abstract doctrine. They are the operating logic that turns the spine into a usable system. *** ## 2.5 Frameworks and the Most-Restrictive Operating Reading Rule All Nexus frameworks must be read under the most-restrictive operating reading rule. Where multiple interpretations are possible, the valid reading is the one that preserves stronger institutional boundaries, narrower public claims, lower maturity implication, more limited role inference, stricter non-execution discipline, stronger public-safe protection, and clearer separation between activity and authority, unless a stronger reserved act expressly authorizes a wider reading. This rule is essential because frameworks can otherwise be overread. A framework does not authorize a team to broaden its mandate. A framework does not make a working group a governance body. A framework does not make a pilot mature. A framework does not convert operational usefulness into recognition. A framework does not turn public authority learning into public authority adoption. A framework does not turn a Digital Public Good into a universally deployable asset by default. A framework does not turn Marketplace discoverability into standing. A framework does not turn Foundry production into public-good approval. A framework does not turn NXS-STU workflow use into lawful decision-making. Frameworks structure work inside the architecture. They do not widen the architecture by implication. This restraint is one of the strongest features of the Nexus operating model. *** ## 2.6 Frameworks and Role Separation Frameworks must preserve the differentiated institutional roles of Nexus. The **Global Centre for Risk and Innovation (GCRI)**, acting through GCRI Canada as Lead Institution, Consortium Secretariat and lead contracting organization \[1]\[2], is especially close to frameworks involving evidence, methods, observability, ontology, open technical baselines, Digital Public Goods, public-good software, and technical research-to-practice translation. The **Global Risks Forum (GRF)**, a consortium steward for leadership, dialogue and Nexus Universe programme governance \[1], is especially close to frameworks involving convening, stakeholder formation, maturity records, public-safe publication, claims discipline, correction, and public-facing legitimacy. It is not presented here as a recognition, conformance or certification body (X-23) \[8]\[9]\[10]. The **Global Risks Alliance (GRA)**, a consortium steward for the finance, insurance and development-readiness interface \[1], is especially close to frameworks involving routeability, adoption, ecosystem translation, finance-readable and insurance readiness, diligence translation, and bounded handoffs toward lawful realization. GRA "does not lend, underwrite, rate, invest, advise on or arrange transactions, and readiness work is not approval" \[8]. NXS-NSF \[5] is especially close to frameworks involving canonical semantics, standards interpretation, policy and authorization states, entitlement decisions, anti-fork discipline, and conformance architecture. Nexus Standards is a proposed standards programme with no publisher of record \[9]. Frameworks must not collapse these roles. A GCRI method does not create GRF recognition by itself. A GRF registry status does not create GRA finance execution. A GRA routeability artifact does not become investment advice. An entitlement does not become public authority status. Frameworks keep the operating system aligned to the institutional architecture. *** ## 2.7 The Nexus Agile Framework as the Whole-System Method The **Nexus Agile Framework (NAF)** is the principal methodological instrument of Nexus Operations. It should be read as a whole-system method for disciplined adaptability, not as a conventional agile delivery framework. In Nexus, agility does not mean speed alone. It means the ability to learn, sequence, revise, coordinate, and deploy responsibly without losing constitutional integrity, public-good distinctness, role separation, standards alignment, records discipline, or public-safe boundaries. NAF is necessary because Nexus operates in complex environments where law, governance, technology, public authority engagement, Digital Public Goods, capital, intellectual property, data, community safeguards, infrastructure, and implementation pathways interact. A simple project-management method would be insufficient. Nexus needs a framework capable of carrying work across the full chain of institutional and practical consequence. NAF should therefore be understood as a method for responsible movement. It allows work to progress without becoming reckless. It allows iteration without losing records. It allows partnership without mandate trespass. It allows deployment preparation without premature execution. It allows learning without conceptual drift. It allows acceleration without public-good collapse. NAF is the framework through which responsiveness becomes compatible with seriousness. *** ## 2.8 Foundations Within the Nexus Agile Framework The Foundations component of NAF anchors operational method to the deeper Nexus architecture. It establishes the assumptions under which work may proceed. It clarifies that Nexus is not an ordinary project-delivery environment. It is a public-good-rooted, standards-bearing, federated, role-separated, non-executing by default, correction-capable architecture operating in high-consequence contexts. This matters because methods are never neutral. A method designed for ordinary product delivery may optimize speed, user adoption, or commercial output. A method designed for Nexus must optimize trust, coherence, public-safe meaning, long-horizon maintenance, role fidelity, and lawful handoff. The Foundations component ensures that work does not begin from the wrong premise. It grounds operating practice in: * public-good distinctness; * role separation; * validity by record; * correctionability; * non-execution discipline; * public authority capacity classification; * standards-bearing interoperability; * federation; * lifecycle responsibility; * public-safe publication; * support without control; * anti-capture discipline; * lawful realization pathways. Foundations turn method into architecture. *** ## 2.9 Legal, Governance, and Ownership Logic in NAF NAF includes legal, governance, intellectual property, ownership, and equity logic because Nexus work often produces assets, rights, responsibilities, records, and dependencies that cannot be governed after the fact. The Legal component ensures that work moves within jurisdictional, contractual, licensing, data, public authority, procurement, privacy, and role-bound contexts. Nexus cannot assume that a useful output is lawful to publish, deploy, localize, commercialize, or hand off. The Governance component ensures that workflows do not become self-validating. It connects work to authority, record, review, decision, correction, reserved matters, and public-safe limits. The Intellectual Property component ensures that contribution, licensing, reuse, attribution, derivative works, open-source logic, Digital Public Goods, data rights, software rights, documentation, and commercialization pathways are handled visibly. The Ownership component ensures that the system distinguishes stewardship, authorship, contribution, hosting, maintenance, operation, licensing, and execution. These are not the same. The Equity component ensures that participation, value, benefit, opportunity, community legitimacy, and public-purpose distribution are considered as part of operating method rather than left to default market dynamics. This integrated treatment is essential because many systems fail where operational and legal-economic logic are disconnected. Nexus avoids that by bringing these questions into the framework itself. *** ## 2.10 Acceleration, Revenue, Capital, and Partnership Inside NAF NAF also includes acceleration, revenue, capital, partnership, and deployment logic because Nexus is designed to be realization-capable without becoming execution-collapsed. This is a mature design choice. In weaker systems, acceleration and capital enter late and often distort the original public-purpose architecture. A project begins as public-good work but becomes vendor-led, sponsor-controlled, finance-narrated, or implementation-driven because the operating method never integrated realization pressure from the beginning. NAF prevents this by treating acceleration-facing themes as part of the operating architecture rather than external forces. Acceleration logic helps determine how work becomes ready for Foundry, NXS-STU, Marketplace, consortium pathways, national programs, National Consortium Companies, SPVs, or qualified providers. Revenue logic helps determine how operational sustainability, public-good allocations, licensing, maintenance, support, and value flows are handled without enclosure. Capital logic helps determine how finance-readable readiness may be supported without creating finance execution, investment advice, underwriting, rating, brokerage, or lending approval. The boundary is recorded in D-V3-0004: "Finance-readiness is not finance. Insurance-readiness is not underwriting" \[3]; and GRA, the consortium steward for this interface, "does not lend, underwrite, rate, invest, advise on or arrange transactions, and readiness work is not approval" \[8]. Partnership logic helps determine how companies, public authorities, universities, sponsors, hosts, communities, providers, and ecosystem actors may engage without mandate trespass or capture. Deployment logic helps determine how outputs move toward lawful realization without becoming execution by default. NAF therefore allows acceleration and capital to be approached with discipline instead of denial. *** ## 2.11 Engagement, Foresight, Lifecycle, and Deployment in NAF The Engagement, Foresight, Lifecycle, and Deployment components of NAF reinforce that Nexus work must be carried across time, not only across tasks. Engagement matters because public-good infrastructure depends on relationships: public authorities, communities, companies, universities, hosts, providers, sponsors, funders, and domain actors must understand how they are participating and what they are not authorized to infer from that participation. Foresight matters because Nexus operates in high-consequence and emerging domains. Artificial intelligence, AI-RAN, O-RAN, private wireless, compute under national control, cyber-physical systems, digital twins, distributed-ledger and DePIN research (research outlook only), climate risk, biodiversity, disaster risk, critical infrastructure, and other exponential technologies require anticipatory method rather than reactive improvisation. Lifecycle matters because assets, reports, Digital Public Goods, platforms, workflows, standards materials, Marketplace objects, and deployment packages must be maintained, updated, corrected, superseded, retired, or decommissioned. A system that only creates but does not maintain will eventually become unsafe. Deployment matters because Nexus is realization-capable. Work may move toward practical use, but it must do so through lawful, recorded, public-safe, and role-bounded pathways. Together, these components make NAF a full-chain method. It governs not only how work starts, but how it matures, travels, is relied upon, is corrected, and eventually exits active use. *** ## 2.12 NAF and the Difference Between Agility and Acceleration Nexus distinguishes agility from acceleration. **Agility** is the operating capacity to adapt responsibly. **Acceleration** is the realization capacity to move toward deployment, adoption, scaling, marketplace extension, consortium formation, or lawful execution. NAF belongs to Operation because it governs agility. It allows Nexus to move, learn, revise, and coordinate without losing method. Acceleration belongs to the realization side of the architecture. It may use operational outputs, frameworks, Foundry packages, NXS-STU workflows, Marketplace objects, and consortium pathways, but it remains bounded by governance, public-good distinctness, public-safe discipline, and lawful execution rules. This distinction matters. A framework may make work more agile. It does not authorize accelerated deployment by itself. A sprint may produce a prototype. It does not create maturity. A pilot may generate evidence. It does not create comparability. A demo may attract partners. It does not create public-safe recognition. An implementation pathway may be prepared. It does not create procurement or finance approval. NAF makes Nexus responsive. It does not remove the need for records, review, public-safe release, recognition, routeability, standards alignment, or lawful handoff. *** ## 2.13 The Sustainable Competency Framework If NAF governs how the system works, the **Sustainable Competency Framework (SCF)** governs how people become able to carry that work. This is foundational. Serious systems cannot depend indefinitely on founder memory, informal apprenticeship, heroic individuals, unrecorded tacit knowledge, or uneven local capacity. They require a disciplined architecture of capability formation. SCF is not a training catalogue. It is a sustainable institutional competence framework. It should define: * which competencies matter; * how competencies relate to role classes; * how learning pathways are sequenced; * how readiness is assessed; * how credentials or learning records support role eligibility; * how competence is refreshed; * how competence links to responsibility and entitlement; * how local, national, regional, and host capacity is built; * how public-safe and safeguards competence is maintained; * how providers and partners become operationally ready; * how competence gaps trigger support, review, or limits. SCF is essential because Nexus spans evidence stewardship, observability, public-safe publication, registry discipline, standards interpretation, routeability, finance-readable readiness, platform operation, controlled rooms, Academy, Marketplace, Foundry, NXS-STU, nodes, hosts, competence cells, and lawful execution pathways. No architecture of that breadth can remain stable if capability remains informal. SCF converts competence into a governed and renewable institutional asset. *** ## 2.14 Competence as Infrastructure One of the strongest ideas in SCF is that competence should be treated as infrastructure. Competence is not merely an individual attribute. It is part of the system's continuity. A system without competence infrastructure becomes dependent on a few people. It cannot scale safely, federate responsibly, or support external organizations consistently. Treating competence as infrastructure means that: * skills must be identified; * roles must be mapped; * learning must be structured; * training must be maintained; * credentials must be scoped; * experience must be recorded; * refresh cycles must exist; * public-safe practice must be taught; * institutional memory must be transferred; * communities and hosts must be supported; * providers must be qualified; * and competence gaps must be visible. This applies across every level of Nexus. A National Working Group requires competence. A Competence Cell requires competence. A public authority learning pathway requires competence. A Marketplace reviewer requires competence. A Foundry maintainer requires competence. An NXS-STU operator requires competence. A GRF claims reviewer requires competence. A GRA routeability analyst requires competence. A GCRI methods contributor requires competence. A protocol administrator requires competence. SCF ensures that Nexus is not merely staffed by people, but carried by role-ready capability. *** ## 2.15 Academy, Credentials, and Role Readiness SCF connects naturally to Academy, credentials, and role readiness. The Academy layer may provide learning pathways, training modules, workshops, role preparation, public authority learning, provider onboarding, competence-cell support, host training, contributor development, technical literacy, public-safe practice, and continuing education. Credentials or learning records may support role eligibility, access, progression, provider qualification, platform privileges, controlled-room participation, or workflow responsibilities. But credentials do not create authority by themselves. A credential may show preparation. It does not create office. A training record may support eligibility. It does not create mandate. A course completion may support platform access. It does not authorize public claims. A competence record may support provider qualification. It does not create procurement approval. A role-readiness pathway may prepare a person for responsibility. It does not substitute for appointment, delegation, record, or governance approval. SCF therefore links learning to responsibility while preserving the distinction between competence and authority. *** ## 2.16 SCF and Distributed Capability Formation SCF is especially important because Nexus is federated. Capability must form across regions, countries, hosts, communities, institutions, universities, public authorities, providers, and nodes. It cannot remain concentrated in one central expert team. Distributed capability formation may include: * regional Academy pathways; * national training programs; * host onboarding; * public authority learning; * Competence Cell formation; * provider qualification; * community science training; * Indigenous and local knowledge safeguards training; * technical platform training; * data, privacy, cybersecurity, and AI governance training; * Foundry package maintenance training; * NXS-STU workflow training; * Marketplace listing and review training; * report-writing and public-safe publication training; * registry and records training. The purpose is not to standardize people into sameness. It is to create sufficient shared capability for distributed actors to participate responsibly in one architecture. SCF makes federation operationally possible. *** ## 2.17 The Distributed Digital Public Goods Framework The **Distributed Digital Public Goods Framework (DDPGF)** is the third major framework in the stack. It provides the operating discipline for digital-public infrastructure within Nexus. DDPGF should be understood against the reality that digital systems often carry hidden governance. A platform determines who can access information. A workflow determines what steps are visible. A dashboard shapes perception. A registry determines status visibility. A knowledge graph shapes discovery. A Marketplace listing shapes adoption. An NXS-STU environment shapes runtime behavior. A protocol key shapes access. A software package shapes what users can do. DDPGF makes these realities governable. It ensures that digital-public assets remain: * public-good-rooted; * distributed rather than silently centralized; * interoperable rather than isolated; * standards-aligned rather than ad hoc; * metadata-aware rather than opaque; * licensed rather than ambiguous; * maintained rather than abandoned; * accessible rather than exclusionary; * secure rather than fragile; * localizable without forking; * public-safe in use; * and connected to institutional purpose. DDPGF is the framework through which Nexus prevents digital infrastructure from becoming either uncontrolled commons sprawl or proprietary enclosure. *** ## 2.18 DDPGF and the Shared Operating Backbone DDPGF is directly related to the shared operating backbone of Nexus. The shared operating backbone may include CRM systems, event systems, workflow systems, analytics systems, Academy and credential systems, registry systems, directory systems, knowledge graphs, document repositories, issue trackers, dashboards, audit logs, publication systems, Marketplace infrastructure, NXS-STU environments, and collaboration platforms. These systems are not merely software. They are institutional infrastructure. They support: * intake; * triage; * routing; * workflow assignment; * contributor records; * learning records; * credential records; * event coordination; * report production; * asset inventory; * registry status; * Marketplace activity; * platform access; * analytics; * review; * approval; * publication; * correction; * archival; * decommissioning. DDPGF governs how this backbone remains aligned to the Nexus architecture. It ensures the backbone is common enough to preserve interoperability, but not so centralized that local, national, and regional supportability is crushed by one brittle operating model. The backbone must support distributed operation without becoming hidden central command. *** ## 2.19 DDPGF and Digital Public Good Lifecycle A Digital Public Good is not complete when it is published. Digital Public Goods require lifecycle discipline. DDPGF should govern the lifecycle of digital assets from concept to retirement. This may include: * intake; * scoping; * public-good justification; * repository creation; * license selection; * documentation; * metadata; * dependency mapping; * security review; * accessibility review; * localization planning; * versioning; * testing; * publication; * Marketplace visibility where appropriate; * Foundry packaging where appropriate; * NXS-STU use where appropriate; * maintenance; * support; * issue management; * vulnerability response; * update cycles; * supersession; * deprecation; * archival; * decommissioning. This matters because public-good digital infrastructure often fails through neglect rather than bad intent. Tools are released but not maintained. Documentation becomes outdated. Dependencies become insecure. Localizations drift. Licenses are unclear. Forks multiply. Users cannot tell which version is current. Claims exceed support status. DDPGF prevents this by treating Digital Public Goods as maintained infrastructure rather than isolated artifacts. *** ## 2.20 DDPGF, Interoperability, and Anti-Fork Discipline DDPGF must preserve interoperability and anti-fork discipline. A digital asset may be localized, extended, translated, packaged, integrated, or adapted. But adaptation must not silently create a new architecture. A national localization must remain linked to canonical semantics. A regional extension must remain cross-walked. A Marketplace object must state scope. A Foundry package must state version and support status. An NXS-STU workflow must state authority boundary. A connector must state data limits. A schema must state compatibility. A dashboard must state public-safe status. A fork may be legitimate only if it is governed, recorded, named, licensed, scoped, and related back to the common rail. Otherwise, it becomes fragmentation. DDPGF ensures that digital-public infrastructure can scale through distributed contribution without losing semantic coherence. *** ## 2.21 Frameworks, Asset Inventory, and Operational Memory Frameworks must connect to the operational asset inventory. The asset inventory is the structured, versioned, access-controlled, and auditable catalogue of Nexus-related assets. It may include documents, methods, software modules, datasets, schemas, dashboards, workflows, licenses, templates, taxonomies, packages, contracts, reports, media products, Academy modules, credential records, registry entries, Marketplace listings, evidence briefs, public-safe summaries, playbooks, checklists, and operational capabilities. Frameworks determine how those assets are created, reviewed, maintained, reused, corrected, superseded, archived, or retired. NAF governs the movement and use of assets in work. SCF governs the competence required to create, maintain, review, or use them. DDPGF governs the digital-public assets and shared systems that support them. Without framework-linked asset inventory, Nexus would accumulate materials without reliable status. With framework-linked asset inventory, Nexus can know what exists, who stewards it, what version is current, what status it holds, what license applies, what support is required, and what may be reused or retired. This is how operation becomes memory. *** ## 2.22 Frameworks, Review, and Quality Assurance Frameworks define how quality is achieved. Quality in Nexus is not only polish. It includes methodological rigor, legal clarity, public-safe discipline, standards alignment, accessibility, evidence quality, data integrity, security, claims control, role fidelity, and lifecycle maintainability. Framework-driven review may include: * methods review; * evidence review; * technical review; * public-safe review; * claims review; * standards review; * data review; * privacy review; * cybersecurity review; * accessibility review; * licensing review; * governance review; * publication review; * Marketplace review; * Foundry readiness review; * NXS-STU runtime review; * provider readiness review; * correction review. The appropriate review depends on output class and risk. A working note does not require the same review as a public report. A prototype does not require the same review as a maintained Digital Public Good. A local training module does not require the same review as a recognized public-facing publication. Frameworks make quality proportional, visible, and repeatable. *** ## 2.23 Frameworks and Public-Safe Working Discipline Frameworks must preserve public-safe working discipline. Operational outputs can shape public understanding, public authority relationships, community trust, market behavior, funder perception, provider claims, and ecosystem reputation. A framework-guided process must therefore ensure that outputs do not overclaim their status. A report should not imply recognition unless recognized. A dashboard should not imply public warning unless lawfully authorized. A Marketplace listing should not imply endorsement unless recorded. A Foundry package should not imply deployment readiness unless reviewed. An NXS-STU workflow should not imply public authority decision-making unless adopted by competent authority. A Digital Public Good should not imply support if unsupported. A public authority learning product should not imply public authority adoption. A finance-readable artifact should not imply investment advice or underwriting. Frameworks protect public meaning by requiring status, scope, review, public-safe controls, and non-effect statements where needed. *** ## 2.24 Frameworks and Operational Handoffs Frameworks are critical at handoff points. A handoff occurs when work moves from one domain, body, system, or status to another. These moments are especially risky because meaning can expand during transition. Examples include: * investigation to evidence brief; * evidence brief to report; * report to GRF public-safe pathway; * methods output to GCRI stewardship; * standards-relevant question to NXS-NSF policy review; * learning pathway to Academy credential; * Digital Public Good to Foundry; * connector or service to Marketplace; * NXS-STU workflow to runtime authorization; * national working group output to consortium formation; * consortium output to National Consortium Company or SPV structuring; * provider task to qualified enterprise delivery; * operational issue to correction pathway. Frameworks ensure that handoffs state what is moving, what is not moving, who receives it, what record applies, what status it holds, what review remains, and what authority is not implied. Frameworks prevent handoff from becoming substitution. *** ## 2.25 Frameworks and Qualified Enterprise Providers Frameworks also govern how Nexus interacts with qualified enterprise providers. Nexus is not a vertically integrated vendor monopoly. It requires qualified providers, integrators, OEM partners, cloud partners, telecom partners, software developers, cybersecurity providers, data providers, systems integrators, training providers, infrastructure operators, and service providers to support lawful realization. But providers must not capture the public-good rail. Frameworks help define: * provider role boundaries; * qualification requirements; * technical competence; * security obligations; * interoperability requirements; * data handling duties; * public-safe claims limits; * documentation requirements; * support obligations; * maintenance expectations; * Marketplace status; * Foundry contribution rules; * NXS-STU integration limits; * conflict controls; * handoff boundaries; * correction obligations. A provider may deliver services. It does not become public-good authority. A provider may build a component. It does not define standards. A provider may participate in Marketplace. It is not recognized by default. A provider may support a node. It does not own node meaning. A provider may support a public authority project. It does not become the public authority. Frameworks make provider participation useful without allowing provider capture. *** ## 2.26 Frameworks and Nodes, Hosts, and Runtime Environments Frameworks also apply to nodes, hosts, and runtime environments. A Nexus Node, host environment, observatory node, NXS-STU runtime, compute setting under national control, Marketplace localization, or edge deployment requires method. It cannot be treated as active merely because equipment, software, people, or public interest exists. Frameworks help determine: * host onboarding; * node readiness; * data handling; * security posture; * public-safe conditions; * competence requirements; * runtime support; * issue reporting; * dashboard status; * NXS-STU workflow boundaries; * Marketplace localization; * continuity planning; * degraded-mode operation; * node lifecycle; * retirement or decommissioning. A host is not sovereign over the architecture. A node is not active without recorded status. A dashboard is not public warning by default. An NXS-STU workflow is not lawful decision-making by default. A Marketplace localization is not universal portability. Frameworks make runtime operation disciplined rather than merely technical. *** ## 2.27 Frameworks and Operational Metrics Frameworks must govern what Nexus measures and how those measurements are interpreted. Operational metrics may include activity, workflow status, contribution, learning progression, credential completion, report production, review cycles, public-safe status, platform use, Marketplace activity, Digital Public Good maintenance, node readiness, host support, response times, correction cycles, and handoff completion. But metrics can mislead. High activity is not maturity. High visibility is not authority. High participation is not competence. A completed workflow is not approval. A dashboard indicator is not recognition. A Marketplace count is not ecosystem health. Frameworks should ensure that metrics measure institutional movement rather than surface attention alone. The purpose of analytics is to improve operations, not to create performance theatre. *** ## 2.28 Frameworks and Operational Sustainability Frameworks must support operational sustainability. Nexus Operations requires funding, staffing, tools, maintenance, documentation, translation, accessibility, cybersecurity, support desks, platform upkeep, Academy programming, public-safe review, report production, Marketplace operations, Foundry preparation, NXS-STU support, node operations, and Digital Public Good maintenance. Sustainability may come from grants, sponsorships, service support, Marketplace activity, Academy revenues, support agreements, public-good allocations, partner contributions, national structures, program funding, and lawful enterprise pathways. But sustainability must not create capture. A sponsor may support a framework. It does not own the method. A provider may support implementation. It does not define standards. A Marketplace revenue path may support maintenance. It does not purchase recognition. An Academy offering may create revenue. It does not create governance authority. A national implementation may fund localization. It does not fork the common rail. Frameworks must therefore include sustainability logic that supports maintenance, access, continuity, and public-good stewardship without allowing funders, vendors, hosts, or customers to control the architecture. *** ## 2.29 Frameworks and Correctionability Frameworks must be correction-capable. A framework should not be treated as perfect because it is adopted. It must be capable of learning from use, correcting ambiguity, narrowing overbroad language, incorporating lessons, retiring outdated practices, updating review requirements, and improving handoff pathways. Framework correction may arise from: * operational incidents; * public-safe issues; * contributor feedback; * platform failures; * report errors; * outdated Digital Public Goods; * provider issues; * host experience; * node maturity problems; * governance review; * standards review; * regional adaptation; * national implementation; * legal changes; * technology shifts; * security concerns. Correction must be recorded. Framework changes should be versioned, dated, scoped, and connected to supersession or archival rules. A framework that cannot correct itself becomes doctrine without learning. A framework that changes silently becomes unstable. Nexus requires frameworks that are both durable and correctable. *** ## 2.30 Frameworks and External Use The framework layer is not only internal. It is also a resource for organizations that want to understand, adopt, or align with Nexus methods. A public authority may use Nexus frameworks to understand how learning, reports, observability, public-safe review, and public authority capacity classification should proceed. A company may use them to understand provider qualification, Marketplace participation, Foundry contribution, NXS-STU integration, Digital Public Good maintenance, and public-good / enterprise boundaries. A university may use them to form a Competence Cell, structure research-to-practice translation, host a node, support Academy pathways, or produce reports. A sponsor may use them to support capacity without acquiring control. A community organization may use them to understand protected participation, community science, local knowledge safeguards, and public-safe outputs. A national group may use them to move from working group activity to [National Nexus Consortium](/organization/governance-in-operation/nnc.md) formation and later lawful company or SPV pathways. A host may use them to understand node readiness, platform operation, data handling, public-safe practice, and continuity. A provider may use them to understand technical, documentation, support, claims, and interoperability requirements. Frameworks make Nexus usable beyond its founding institutions. They are how the architecture teaches others how to work with it responsibly. *** ## 2.31 Framework Failure Modes Nexus must be explicit about framework failure modes so they can be avoided. **Framework theatre** occurs when a framework is named but not used to guide real work. **Method sprawl** occurs when teams create local methods without crosswalks to the common operating architecture. **Founder-memory dependency** occurs when frameworks exist in documents but practical knowledge remains held by a few people. **Over-flexibility** occurs when adaptability becomes excuse for weak records, unclear status, or drifting standards. **Over-bureaucratization** occurs when method becomes so heavy that work cannot move. **Role inflation** occurs when a framework is used to imply authority beyond mandate. **Maturity inflation** occurs when framework adoption is presented as operational maturity. **Platform capture** occurs when digital workflow tools begin to define institutional reality without governance. **Provider capture** occurs when vendor implementation patterns become de facto method. **Digital public-good abandonment** occurs when DPGs are released without maintenance, support, documentation, or lifecycle funding. **Training substitution** occurs when credential completion is treated as authority rather than role readiness. **Metrics theatre** occurs when analytics measure attention rather than institutional movement. **Silent framework drift** occurs when framework practices change without records, versioning, or correction. The framework layer exists to prevent these failures by making method visible, bounded, reviewable, and correctable. *** ## 2.32 Strategic Value of the Framework Layer The strategic value of frameworks is difficult to overstate. Frameworks allow Nexus to move without improvising itself anew in every context. They allow contributors and institutions to align to one method-bearing order. They make operational maturity more legible to readers, partners, hosts, public authorities, providers, sponsors, and finance readers. They create pathways through which learning becomes cumulative rather than episodic. They protect the public-good core from downstream operational drift. They allow Digital Public Goods to become maintainable infrastructure rather than abandoned artifacts. They allow provider participation without provider capture. They make realization more disciplined by giving deployment-facing work a methodological foundation. They enable Nexus to be both innovative and governable. In strategic terms, frameworks reduce the distance between aspiration and repeatable practice. They are one of the reasons Nexus can scale without losing its center. *** ## 2.33 Final Statement on Frameworks The framework layer is the methodological architecture of the Nexus operating system. Through the **Nexus Agile Framework (NAF)**, the **Sustainable Competency Framework (SCF)**, and the **Distributed Digital Public Goods Framework (DDPGF)**, Nexus defines how work moves, how competence is built, and how shared digital-public infrastructure remains public-good-rooted, interoperable, maintained, distributed, and governed. This is where Operation first becomes formally disciplined. It is where Nexus decides that no serious public-purpose architecture should rely on intuition alone, founder memory alone, scattered practice alone, ungoverned platforms alone, or unsupported digital assets alone. Frameworks convert method into infrastructure. They make work repeatable. They make competence renewable. They make Digital Public Goods maintainable. They make operating systems transferable. They make public-good architecture usable. Through frameworks, Nexus becomes capable not only of acting, but of acting coherently under scale, plurality, and time. *** ## International reference points | Reference | What it offers | How this page relates | | ------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------ | | *Manifesto for Agile Software Development* (2001) \[11] | Values and principles for iterative software delivery | Contrast: NAF borrows iteration and feedback but extends them to legal, governance and institutional work (section 2.12) | | European Commission Joint Research Centre, *DigComp 2.2* (2022) \[12] | A reference framework of digital competence with proficiency levels | Comparable structure for SCF competence areas and progression (sections 2.13 to 2.16) | | Digital Public Goods Alliance, *Digital Public Goods Standard* \[13] | Criteria a digital solution must meet to be recognized as a digital public good | The design target of DDPGF (section 2.17); no Nexus item is cited as recognized | | *Universal DPI Safeguards Framework* (UN Secretary-General's Envoy on Technology and UNDP, 2024) \[14] | Safeguards for digital public infrastructure | Safeguards discipline for DDPGF lifecycle (section 2.19) | | OECD *Recommendation on Enhancing Access to and Sharing of Data* (2021) \[15] | Principles for trusted data access and sharing | Data structures and interoperability in DDPGF (section 2.20) | | Wilkinson et al., *The FAIR Guiding Principles* (2016) \[16] | Findable, accessible, interoperable and reusable data | Reuse and interoperability goals of DDPGF | | Creative Commons licences \[17] and Open Source Initiative approved licences \[18] | Public licence families for content and code | Reference only: no licence decision for any Nexus framework or asset is recorded, and no licence is implied \[9] | | ISO 9001:2015 \[19] | The process approach to quality | Framework review and quality assurance (section 2.22) | *Table 2. International reference points for the framework layer. Alignment for orientation only; naming a body or framework is not a claim of partnership, endorsement or conformance.* ## What frameworks are not A framework is not a standard, a charter, a licence, a certification scheme, a procurement rule or an execution mandate. Using a framework does not make work adopted, approved or recognized, and completing a framework pathway does not confer office. The boundary formulas of D-V3-0004 apply verbatim: "Finance-readiness is not finance. Insurance-readiness is not underwriting. Verification is not certification. Participation is not consent. Public-authority learning is not approval. Technology readiness is not procurement approval. A warning-support candidate is not an official warning. A decision-support package is not an official decision" (D-V3-0004) \[3]. Decisions stay with competent actors. ## Frameworks and the twenty systems As editorial alignment only, not a claim of operating service, the frameworks touch these systems of the twenty-system constitution \[5]: [NXS-HUB](/organization/systems/nxs-hub.md), the operating workspace and controlled portal layer for knowledge, tickets and runbooks, for "Institutional knowledge, records, citations, collaboration, tickets, runbooks, meetings, learning, support and service knowledge", which carries framework records and learning; NXS-NSF for policy, authorization and "public-safe release and correction governance"; NXS-NXQ for "Software, packages, connectors, models, tools, skills, agents, entitlements and capability lifecycle", which is where DDPGF software assets would sit; NXS-FAC for builds and assembly; and [NXS-RLS](/organization/systems/nxs-rls.md), the technical rails and protocol infrastructure for protocol-governed work across institutions, for lawful handoffs. System capability: target architecture. A release hold is in force: no capability has yet been observed in live use, and no capability is described beyond the stage of integrated components, with laboratory or test evidence cited only where it is attached \[6]. ## Terms used on this page | Term | Meaning on this page | Source | | -------------------- | ------------------------------------------------------------------------------------------------------------ | ------------------------- | | Framework | A method-bearing instrument that guides how a kind of work moves; not a rule or a standard | This page | | NAF | Nexus Agile Framework, the whole-system method for moving work | Section 2.7 of this page | | SCF | Sustainable Competency Framework, the competence architecture | Section 2.13 of this page | | DDPGF | Distributed Digital Public Goods Framework, the stewardship method for digital public assets | Section 2.17 of this page | | Digital public good | A digital solution recognized against the Digital Public Goods Standard; used here only as a design category | \[13] | | Anti-fork discipline | Keeping one canonical version of shared assets while allowing governed local extension | Section 2.20 of this page | ## Related pages * Up: [Operations](/organization/introduction/operations.md) * Across: [I. Order](/organization/introduction/operations/i.-order.md) · [III. Charters](/organization/introduction/operations/iii.-charters.md) · [IV. Networks](/organization/introduction/operations/iv.-networks.md) · [V. Mechanisms](/organization/introduction/operations/v.-mechanisms.md) · [VI. Pillars](/organization/introduction/operations/vi.-pillars.md) · [X. Platforms](/organization/introduction/operations/x.-platforms.md) * Counterparts: [Frameworks in the Operations part](/organization/operations/frameworks.md) · [Systems](/organization/systems.md) · [IV. Foundations](/organization/introduction/organization/iv.-foundations.md) ## Sources 1. Nexus institutional register: owner decision of 11 October 2026 on Nexus institutional architecture and participation (owner-confirmed; counsel review pending): positioning, roles and the table of what is not conferred. Internal record. 2. Nexus institutional register: legal entity profile notices on the lead contracting organization, institutional independence, consortium stewardship and platform ownership (owner-confirmed); ecosystem execution register (every instrument in draft). Internal record. 3. Nexus constitutional directive D-V3-0004, *One Rail-Two Stacks, Non-Execution and Lawful Handoff Constitution* (public-good rail, enterprise and sovereign execution stack, consequential action envelope, boundary formulas). Internal record, cited by identifier. 4. Nexus institutional register: consortium programme and consortium geography (participation pillars NNC, NLC and NWG; service levels R0 to R5 and the current service level R0, "Information and enquiries"; six regions and fifteen hubs, all recorded as planned). Internal record. 5. Nexus constitutional directive D-V3-0003, *Twenty-System Constitution* (canonical order, identifiers and remits of the twenty systems). Internal record, cited by identifier. 6. Nexus institutional register: release hold policy (in force) and claim register. Internal record. 7. Nexus constitutional directive D-V3-0001, *Master Directive V3*, and the constitutional invariants ("Authenticated != Authorized. Entitled != Authorized. Deny by default." and "Target definition != implementation. Implementation != verification. Verification != observation. Observation != authority acceptance."); the Native Master legal, IP and open-source constitution (D-NEXUS-NATIVE-MASTER-1) is cited by identifier only and not quoted. Internal record, cited by identifier. 8. Public institutional site draft (not yet published; owner direction, not a binding record): institutional boundary sentences for GRF and GRA, council mapping note retiring earlier labels, GCRI ecosystem services (Registry, Campaigns, Labs, Foundry, Agency, Reports), [Nexus Reports](/organization/programme/reports.md) programme, Nexus Universe, platform registry counts. Draft source. 9. Nexus Documentation Standard, draft of 16 October 2026 (including conflict X-23 and open questions OQ-14 and OQ-22); owner decisions of 16 October 2026; introduction operations audit of 16 October 2026. Internal editorial records; not published. 10. Nexus constitutional directive, *Global Universal Runtime Directive V7*, section 2.5 (older institutional allocation of functions to GCRI, GRF and GRA). Internal record, cited by identifier. 11. Beck, K. et al. (2001). *Manifesto for Agile Software Development*. [agilemanifesto.org](https://agilemanifesto.org/). Accessed 2026-10-16. 12. Vuorikari, R., Kluzer, S. and Punie, Y. (2022). *DigComp 2.2: The Digital Competence Framework for Citizens*. European Commission Joint Research Centre. [doi.org](https://doi.org/10.2760/115376). Accessed 2026-10-16. 13. Digital Public Goods Alliance. *Digital Public Goods Standard*. [digitalpublicgoods.net](https://www.digitalpublicgoods.net/standard). Accessed 2026-10-16. 14. Office of the UN Secretary-General's Envoy on Technology and United Nations Development Programme (2024). *Universal DPI Safeguards Framework*. [dpi-safeguards.org](https://www.dpi-safeguards.org/). Accessed 2026-10-16. 15. OECD (2021). *Recommendation of the Council on Enhancing Access to and Sharing of Data*, OECD/LEGAL/0463. [legalinstruments.oecd.org](https://legalinstruments.oecd.org/en/instruments/OECD-LEGAL-0463). Accessed 2026-10-16. 16. Wilkinson, M. D. et al. (2016). The FAIR Guiding Principles for scientific data management and stewardship. *Scientific Data* 3, 160018. [doi.org](https://doi.org/10.1038/sdata.2016.18). Accessed 2026-10-16. 17. Creative Commons. *About CC Licenses*. [creativecommons.org](https://creativecommons.org/licenses/). Accessed 2026-10-16. 18. Open Source Initiative. *OSI Approved Licenses*. [opensource.org](https://opensource.org/licenses). Accessed 2026-10-16. 19. International Organization for Standardization (2015). *ISO 9001:2015 Quality management systems: Requirements*. (URL not verified) 20. GCRI (2026). *How Nexus works: the six pillars and the* [*Nexus cycle*](/organization/programme/the-nexus-cycle.md). Global Centre for Risk and Innovation. [therisk.global](https://therisk.global/nexus-cycle/). Accessed 2026-10-21. 21. GCRI (2026). *Working groups: the National Working Groups (NWG) and the domain response teams*. [therisk.global](https://therisk.global/consortium/national/nwg/). Accessed 2026-10-21. 22. UN Office of the Secretary-General's Envoy on Technology and UNDP (2024). *Universal DPI Safeguards Framework*. [dpi-safeguards.org](https://www.dpi-safeguards.org/). Accessed 2026-10-21. 23. Risk Academy (2026). *Academy in the ecosystem*: courses, completion records and the course providers. [risksacademy.com](https://risksacademy.com/ecosystem/). Accessed 2026-10-21. 24. Nexus Standards (2026). *NS-13: Open standards development process* (PROPOSED), UNI NXS-STD-ST-000008. [nexustandards.com](https://nexustandards.com/standards/ns-13/). Accessed 2026-10-21. 25. Nexus Standards (2026). *NS-14: Conformance and crosswalk to external standards* (PROPOSED), UNI NXS-STD-ST-000013. [nexustandards.com](https://nexustandards.com/standards/ns-14/). Accessed 2026-10-21. 26. Nexus Standards (2026). *Governance of the Nexus Standards*: the Global Standards Council, Technical Committees and National Standards Councils. [nexustandards.com](https://nexustandards.com/governance/). Accessed 2026-10-21. 27. GCRI (2026). *Programme status*: programme states and the current service level R0. [therisk.global](https://therisk.global/consortium/programme-status/). Accessed 2026-10-21. 28. GCRI (2026). *How Nexus Consortium works*, the Nexus Consortium model as published on the GCRI site. [therisk.global](https://therisk.global/consortium/). Accessed 2026-10-21. ## Editorial record * As of: 2026-10-21. Refresh: every 180 days, or sooner when a governing source changes. * Drafting: AI-assisted (an AI agent drafted this revision). Human review: pending; no named reviewer or approver yet. * Corrections: a public corrections route has not yet been published. Corrections will be recorded as new dated versions, not silent edits. * Change: 2026-10-16, upgraded to the documentation standard draft. Record block, In brief, reading note, status statement and framework status table added; the Nexus Leadership System added from the deep reference; GCRI, GRF and GRA roles aligned to register wording, with "sponsor-capital mapping" and "stakeholder formation" removed from GRA; the earlier long-form NXS-NSF expansion and "protocol authority" no longer presented as institutions, and "role keys" and "smart licenses" removed; "source framework page" residue removed; "currently visible" recast as design; tokenization, blockchain and DePIN framed as research outlook; GRA boundary added to capital logic; earlier council labels flagged; framework stack figure, international reference points, boundaries, twenty-system alignment, terms and sources added; heading levels corrected; all original sections kept. * Change: 2026-10-16 r2, owner decisions of the second round applied: readable document record, plain-language status notes and sources, Nexus Standards display codes for systems, Nexus Observatory Protocol, and no company named. * Change: 2026-10-21 r3, aligned to the current model: "Where this fits" line; alignment note on the six pillars, the [programme year](/organization/programme/the-programme-year.md), [National Nexus](/organization/governance-in-operation/national-nexus.md) (NNC, NLC, NWG, CERTs), the Helix councils, the finance boundary, quarterly Nexus Reports, the Risk Academy issuance rule and the current service level R0; earlier council labels mapped under rulings R3 to R5; sources added from the public sites, the Nexus Standards and the external reference register; the earlier design text kept in full. --- # 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/introduction/operations/ii.-frameworks.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.