> 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/acceleration/vi.-marketplace.md). # VI. Marketplace Marketplace as a target design: how reusable components would be registered, verified and found through NXS-NXQ, NXS-APP and NXS-POR. A listing is not recognition. **Where this fits:** all six sectors · the [Foundry pillar](/organization/programme/foundry.md), with [Labs](/organization/programme/labs.md), [Nexus Universe](/organization/programme/universe.md) and [Risk Academy](/organization/programme/academy.md) · the [Nexus Consortium](/organization/institutions/nexus-consortium.md) and [National Nexus](/organization/governance-in-operation/national-nexus.md) · the Planning, Readiness preparation and Controlled build phases of [the programme year](/organization/programme/the-programme-year.md) · introduction to the deep doctrine. Canonical homes: [The Model](/organization/model.md) · [Systems](/organization/systems.md) · [Finance readiness](/organization/finance-readiness.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-0001 (*Master directive V3*: Rights Control Plane, UNI Identifier Fabric), 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, with GCRI Canada as lead contracting organization; the release hold policy, the claim register and the consortium programme offering O04 and separations, in the Nexus institutional register; the Nexus Documentation Standard (draft of 16 October 2026); the Nexus model and the Nexus Consortium model as published on the GCRI, GRF and GRA sites; [Nexus Standards](/organization/institutions/nexus-standards.md) as published at nexustandards.com | | **Corrections** | Public corrections route to be announced; corrections are published as new dated versions. |
{% hint style="info" %} **Status.** System capabilities described on this page are target architecture under development. Nothing here states that a capability is in production use, certified or offered as a service. {% endhint %} ## In brief Marketplace, in this documentation, is the target design for a governed catalogue in which apps, connectors, packs, agents, services, training offerings and digital public goods would be registered, typed, verified, found, supported and retired without fragmenting the shared rail. In V3 terms it is not a system of its own: packages and entitlements belong to [NXS-NXQ](/organization/systems/nxs-nxq.md) (the software, capability and agent fabric for registries, licensing, APIs and connectors), catalogue and installation to [NXS-APP](/organization/systems/nxs-app.md) (the mission app runtime, for app instances, routes and versions), and developer surfaces to [NXS-POR](/organization/systems/nxs-por.md), the applied-domain public solutions and portals system. The marketplace profile is blocked by the release hold, and no listing is recorded \[1]\[4]. ## Current position (21 October 2026) This section brings the page up to date with the published sites, the Nexus Standards and the owner's rulings of October 2026. Where the older text below differs, this section and the canonical pages it links govern. **Systems, not products.** The technology this page refers to is the [twenty Nexus systems](/organization/systems.md), each named by its display code (for example [NXS-COR](/organization/systems/nxs-cor.md) for compute and runtimes, [NXS-NET](/organization/systems/nxs-net.md) for networks, [NXS-FAC](/organization/systems/nxs-fac.md) for builds and verification, NXS-NXQ for packages and capability lifecycle, NXS-APP for the application catalogue and [NXS-RLS](/organization/systems/nxs-rls.md) for agreements and lawful handoffs). The build work is the [Foundry pillar](/organization/programme/foundry.md): "a configured or simulated capability is not a validated result, and a National Portfolio entry is not an investment decision" \[19]. Technology, infrastructure and service providers work with the Nexus Consortium at arm's length under written agreements. There is no system named Marketplace. The nearest systems are NXS-NXQ, for software, packages, models, agents and capability lifecycle, and NXS-APP, for the application catalogue, installation and lifecycle ([Systems](/organization/systems.md)). Whatever is listed, licensed or exchanged is done by providers and lawful actors under written agreements; the programme lists, prices and transacts nothing. The OECD DAC Blended Finance Principles and the G20 review of development-bank capital frameworks describe how public evidence can lower the cost of capital without the evidence-holder becoming a financier \[20]\[21]. **Finance boundary.** National Consortium Companies and Project SPVs are structures that competent, lawful actors may form outside the programme, under their own law and licences. The programme prepares evidence, standards and readiness; it never forms, arranges, owns or advises on a vehicle or a transaction, and readiness evidence is not a financing decision \[22]\[23]. Where this page describes such vehicles, read it with [Lawful handoffs](/organization/finance-readiness/lawful-handoffs.md) and [National portfolios](/organization/finance-readiness/national-portfolios.md). **Status.** Every programme is in formation and the current service level is R0, information and enquiries; no edition of [Nexus Reports](/organization/programme/reports.md) has been released and no [Risk Academy](/organization/institutions/risk-academy.md) credential has been issued \[24]\[25]. ## Status, scope and terms of this page **Status in the five-state grammar.** Target: defined in this documentation; the underlying systems are defined by the V3 twenty-system constitution \[1]. Implemented: No record of any Marketplace listing, provider profile or transaction. Verified: No record. Observed: No record. Accepted: No record. Status words follow the controlled vocabulary of the public site draft \[8], and no regional Marketplace view is recorded at any of the fifteen planned hubs, which are coordination roles, not offices \[7]. {% hint style="warning" %} **Listing is not recognition, and verification is not certification.** A listing would mean only that an object is discoverable under a defined record, class and status. It would not be recognition, conformance, certification, procurement approval, provider qualification, finance readiness or endorsement. Nexus issues no certificate or badge: "Verification is not certification" \[2]. Earlier text on this page used "certification" and "badging" for Marketplace trust signals; this revision recasts them as verification records (computed), attestations (signed by a named party) and [NXS-NSF](/organization/systems/nxs-nsf.md) (the trust, sovereignty and assurance plane for identity, policy gates and access decisions) recognition decisions, of which only verification is computable today \[9]. {% endhint %} **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): 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 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 \[3]. Standards discipline sits with NXS-NSF, 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 \[1]\[9]. **Commercial terms.** "Commercial technology licences outside the not-for-profit service based on the Nexus systems require a separate agreement with a lawful rights holder or its authorized commercial seller" \[3]. Revenue, fees and Revenue Waterfall allocations on this page are design proposals; none is recorded. **Words that name systems.** "Universe" on this page is an earlier label for the catalogue and integration surfaces; in the institutional records Nexus Universe is the annual resilience programme \[5]. [NXS-STU](/organization/systems/nxs-stu.md), the builder and configuration workspace, which composes but never deploys, is the composition system; "Foundry" is the build function of NXS-FAC, the mission application factory, which produces app blueprints but never runs them \[1]. {% 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 %} ## Summary This page defines **Marketplace** within Nexus Acceleration. If **IV. The Foundry pillar and the systems** explains how Nexus capabilities are designed, assembled, tested, packaged, verified, licensed, and prepared for controlled release, and **V. Programs** explains how people and institutions build capability around the rail, then **VI. Marketplace** explains how those capabilities become discoverable, usable, comparable, supportable, governed, and economically sustainable across the wider ecosystem. Nexus Marketplace is the governed extension and discovery layer of the Nexus Ecosystem. It is not a generic app store, commercial catalogue, vendor bazaar, partner directory, or open-ended integration marketplace. It is a public-interest economic and technical discovery layer through which apps, connectors, packs, agents, swarms, dashboards, observatory patterns, training offerings, services, implementation support objects, Digital Public Goods, Foundry packages, NXS-STU workflows, providers, developers, integrators, universities, social enterprises, public-interest institutions, and mission-aligned ecosystem actors may become visible under controlled rules. Marketplace matters because Nexus cannot scale through one central builder. It cannot build every connector centrally. It cannot author every domain pack centrally. It cannot support every local implementation directly. It cannot maintain every training object, observatory pattern, dashboard, agent, workflow, or service from the constitutional core alone. But it also cannot allow uncontrolled extension. A public-good rail that cannot be extended becomes brittle. A public-good rail that can be extended without governance becomes fragmented. Marketplace is the disciplined middle path. It allows Nexus to widen without dissolving. It allows economic participation without capture. It allows discovery without endorsement. It allows contribution without semantic drift. It allows trust signals without pay-to-play. It allows providers to support implementation without becoming standards authorities. It allows social enterprises to participate without becoming governance centers. It allows Digital Public Goods to travel without becoming unsupported debris. It allows users to find what they need without misunderstanding what it means. *** ## 6.1 Why Marketplace Exists Marketplace exists because Nexus is too broad, too multi-domain, too geographically distributed, and too implementation-rich to be built only by a central institutional core. The common rail must support many environments: * compute under national control; * national dense cores; * regional clusters; * observatory nodes; * public authority learning; * NXS-STU workflows; * Foundry packages; * domain packs; * Digital Public Goods; * Academy modules; * risk intelligence; * disaster risk finance; * water, energy, food, health, biodiversity, climate, cyber, infrastructure, logistics, AI, edge, and sovereign technology pathways; * National Nexus Consortiums; * National Consortium Companies; * Project SPVs; * providers; * sponsors; * universities; * communities; * public authorities; * companies; * and mission-aligned social enterprises. No single institution can build every object required for such an ecosystem. Marketplace exists to make distributed contribution possible while preserving the common rail. It gives the ecosystem a place to discover, classify, compare, test, support, update, retire, and govern capability objects. It prevents buildout from disappearing into side channels. It prevents private relationships from becoming the only path to adoption. It prevents ecosystem growth from becoming invisible, duplicative, or semantically unstable. Marketplace is therefore not an optional commercial layer. It is a core realization mechanism. *** ## 6.2 What Marketplace Means in Nexus Within Nexus, Marketplace means the governed ecosystem surface through which capability objects become discoverable, classifiable, usable, supportable, and lifecycle-managed under Nexus standards, ontology, Registry, protocol, claims, public-safe, and anti-capture discipline. Marketplace may include: * apps; * connectors; * APIs; * domain packs; * sector packs; * pack variants; * agents; * swarms; * dashboards; * visualization modules; * observatory patterns; * node packages; * NXS-STU workflows; * Foundry packages; * simulation modules; * assessment tools; * Academy-linked training offerings; * public authority learning packs; * Digital Public Goods; * implementation services; * deployment support services; * support packages; * social enterprise offerings; * OEM components; * systems-integration components; * partner extensions; * data products; * evidence products; * proof tools; * public-safe templates; * and other bounded ecosystem capabilities. Marketplace is not the whole system. It is not the constitutional center. It is not recognition by default. It is not procurement approval. It is not public authority adoption. It is not a substitute for Registry. It is not a substitute for standards. It is the governed discovery and extension layer that helps users find, understand, and use capabilities without weakening the public-good rail. *** ## 6.3 The Marketplace Thesis of Nexus The Marketplace thesis of Nexus is that **a public-good-rooted, standards-bearing, sovereignty-compatible, and realization-capable architecture can scale only if extension is made discoverable and economically usable through a governed Marketplace that types objects, scopes claims, displays maturity, separates listing from recognition, distinguishes social reputation from institutional status, prevents sponsor and provider capture, supports lifecycle discipline, and preserves the common rail under distributed growth**. This thesis has several implications. Extension must be governed. Discovery must be status-aware. Listing must not imply recognition. Verification and attestation signals must be scoped; no badge or certificate is issued. Ratings must not replace conformance. Provider visibility must not become procurement preference. Sponsorship must not determine ranking or trust. Marketplace objects must be typed. Digital Public Goods must show maintenance and support state. Foundry packages must show lifecycle state. NXS-STU workflows must show reliance boundaries. Social enterprise participation must not create governance privilege. Public authority suitability must not be implied. Finance-readable readiness must not become finance execution. Marketplace is valuable because it makes Nexus easier to use. It is trustworthy only if users know exactly what each object is, what it does, what it does not do, and what status it actually holds. *** ## 6.4 Marketplace as Governed Extension, Not Commercial Sprawl Marketplace is a governed extension surface. This is the central distinction. In ordinary ecosystems, a marketplace may become a commercial distribution page where visibility, polish, vendor size, user ratings, sponsorship, or ease of installation substitute for trust. Nexus cannot adopt that model. Nexus operates in domains where ambiguity can create public, institutional, technical, financial, and sovereign risks. A connector may affect sensitive data. A dashboard may appear authoritative. An agent may make recommendations users overread. A pack may shape public authority learning. A provider service may affect procurement interpretation. A training course may be mistaken for certification. A social enterprise may be treated as institutionally endorsed. A Digital Public Good may be reused beyond support scope. Marketplace governance exists to prevent these failures. To enter Marketplace is not merely to list. It is to become visible inside a standards-bearing environment. *** ## 6.5 Marketplace and the Common Rail Marketplace must remain subordinate to the common rail. The common rail carries: * ontology; * controlled vocabulary; * standards; * profiles; * Registry; * recognition; * conformance; * protocol; * public-safe publication; * claims discipline; * routeability; * interoperability; * correctionability; * and anti-fork continuity. Marketplace objects may extend the rail. They may not redefine it. A local connector may extend data access. It may not redefine evidence classes. A domain pack may add sector specificity. It may not create incompatible status language. A provider service may support implementation. It may not become standards authority. A social enterprise offering may advance local resilience. It may not become governance authority. A Marketplace trust signal may show a scoped verification status. It may not override Registry. A user rating may communicate experience. It may not replace conformance. Marketplace widens the rail only when it remains governed by the rail. *** ## 6.6 Marketplace and Universe Marketplace sits inside what earlier text called the wider **Nexus Universe** layer. Earlier text described this "Nexus Universe" layer as the ecosystem application and integration layer through which catalogs, developer portals, Marketplace, ratings, reputation systems, verification signals, apps, connectors, agents, swarms, packs, observatories, rails, and integration surfaces become visible and usable. In the institutional records, Nexus Universe names the annual resilience programme, which "concentrates the annual programme through preparation, integration, controlled action and learning", and whose governance GRF stewards \[3]\[5]. The catalogue and integration surfaces described here correspond to NXS-NXQ, NXS-APP and NXS-POR, whose remit includes "developer" delivery surfaces \[1]. This section keeps the earlier label "Universe layer" for those surfaces only. Marketplace should therefore be read as part of a larger ecosystem surface. The Universe layer may include: * catalogues; * Marketplace listings; * developer portal; * documentation; * SDKs; * APIs; * CLI tooling; * contributor guides; * pack publishing; * plugin governance; * verification and attestation records (not certification or badging); * rating and reputation; * integration pathways; * support portals; * provider pathways; * Academy links; * Foundry-to-Marketplace publishing; * NXS-STU workflow libraries; * and Registry-connected status displays. This placement is important. Marketplace is not isolated commerce. It is part of a governed universe of participation, buildout, extension, and discovery. *** ## 6.7 Marketplace Object Classes A strong Marketplace begins with object classes. Every listing must state what kind of object it is. Possible Marketplace object classes include: ### 6.7.1 NXS-APP Bounded software applications that perform defined functions within or adjacent to the Nexus architecture. ### 6.7.2 Connectors Interfaces that connect data sources, systems, platforms, sensors, APIs, or institutions to Nexus workflows under defined scope. ### 6.7.3 Packs Modular domain, sector, geographic, public authority, observability, or workflow packages containing schemas, indicators, playbooks, dashboards, workflows, templates, connectors, or methods. ### 6.7.4 Agents AI-enabled or rule-based assistants operating under bounded roles, data permissions, tool permissions, status awareness, audit rules, and claims limits. ### 6.7.5 Swarms Coordinated multi-agent or multi-component systems whose behavior, permissions, dependencies, and auditability must be especially controlled. ### 6.7.6 Dashboards and Visualization Modules Interfaces that display data, observations, risk indicators, workflow states, or public-safe outputs under reliance boundaries. ### 6.7.7 Observatory Patterns Reusable node, sensing, data-fusion, edge, or observability configurations. ### 6.7.8 NXS-STU Workflows Runtime workflows that may support learning, simulation, public-safe review, decision-support preparation, or operational use where lawful. ### 6.7.9 Foundry Packages Build-stage or release-stage packages prepared through Foundry for controlled use. ### 6.7.10 Digital Public Goods Open or public-good software, datasets, schemas, models, documentation, templates, APIs, or reference implementations with defined support and lifecycle state. ### 6.7.11 Services Implementation, support, training, integration, maintenance, localization, cybersecurity, data, Academy, or advisory services provided under defined provider scope. ### 6.7.12 Training and Academy Offerings Learning modules, verification-preparation materials, public authority learning content, operator training, provider training, or community-facing materials. ### 6.7.13 Evidence and Proof Tools Tools or packages supporting evidence generation, proof records, auditability, conformance preparation, or verification workflows. ### 6.7.14 Public Authority Learning Objects Controlled materials or workflows intended for public authority learning, not adoption by default. ### 6.7.15 Finance-Readable Readiness Objects Objects that support routeability, diligence preparation, resilience evidence, or project-readiness understanding without creating finance execution. They are materials of the GRA finance-readiness interface, and "Readiness evidence is not a financing decision" \[5]. The object class determines how the object should be evaluated, displayed, claimed, supported, and retired. A connector is not a pack. A pack is not a rail. A service is not a standard. An app is not governance authority. A Digital Public Good is not supported by default. Marketplace must keep these distinctions visible. *** ## 6.8 Object Metadata Every Marketplace object should carry metadata sufficient for responsible use. Metadata may include: * object title; * object class; * steward; * provider; * version; * release date; * status; * support state; * lifecycle state; * conformance posture; * verification or attestation state; * Registry reference where applicable; * Foundry reference where applicable; * NXS-STU compatibility; * Compute requirements; * Edge or node requirements; * domain scope; * geographic scope; * jurisdictional limits; * data requirements; * data handling class; * public-safe state; * security state; * dependency list; * license; * pricing or access model where applicable; * support terms; * intended users; * permitted use; * prohibited use; * public claims guidance; * non-effect; * correction pathway; * deprecation plan; * and retirement path. Metadata is not administrative clutter. It is how users avoid overreading what they find. A Marketplace without metadata becomes a display surface. A Marketplace with governed metadata becomes trust infrastructure. *** ## 6.9 Marketplace Status States Marketplace objects should have lifecycle and trust states. Possible states include: * concept; * submitted; * under intake; * under review; * experimental; * sandbox; * pilot; * listed; * supported; * conformance-reviewed; * verified for defined scope; * public-safe for defined use; * deprecated; * suspended; * withdrawn; * retired; * archived. These states must not collapse. A submitted object is not listed. A listed object is not certified. A supported object is not universally suitable. A verified object is verified only within scope. An experimental object is not production-ready. A deprecated object should not appear current. A retired object may remain visible only as archive. Status is the difference between discovery and misunderstanding. *** ## 6.10 Listing Is Not Recognition The central Marketplace rule is that **listing is not recognition by default**. A Marketplace listing means that an object is discoverable under a defined record, class, and status. It does not necessarily mean: * recognition; * conformance; * certification; * public authority suitability; * procurement approval; * provider qualification; * finance-readiness; * operational maturity; * public-safe publication; * endorsement; * or constitutional standing. A listing may be useful, high quality, popular, well supported, widely used, or sponsored, and still not carry formal recognition. Recognition is a separate act. Conformance is a separate result. Verification is scoped, and certification is not issued. Procurement is external and lawful. Public authority adoption is separate. Marketplace must display this rule clearly. Otherwise, discovery becomes status inflation. *** ## 6.11 Verification, attestation and trust signals (earlier: certification and badging) Earlier text treated certification and badging as Marketplace trust instruments. Nexus issues no certificate or badge: "Verification is not certification" \[2]. What can be valuable inside Marketplace are bounded trust signals: verification records (computed), attestations (signed by a named party under an executed agreement) and, where one exists, an NXS-NSF recognition decision \[9]. A trust signal should state: * what was assessed; * against what profile; * by whom or through what process; * at what level; * under what version; * for what duration; * in what scope; * with what limitations; * what claims are permitted; * what claims are prohibited; * whether renewal is required; * and whether the signal is current, suspended, expired, or withdrawn. Trust signals must not be ornamental. They must not be purchasable trust. They must not imply broad approval. They must not replace Registry. They must not convert popularity into maturity. Trust signals may include: * conformance-reviewed status; * production verification; * public-safe review; * security review; * support state; * usage maturity; * deployment history; * maintenance status; * evidence passport completeness; * Bill of Materials completeness; * accessibility review; * and verified steward identity. The stronger the signal, the more precise the scope must be. *** ## 6.12 Ratings and Reputation Ratings and reputation may support Marketplace learning, but they must remain supplemental. In ordinary marketplaces, ratings often become the main trust mechanism. That is not safe for Nexus. Popularity is not conformance. User satisfaction is not public authority suitability. Download count is not maturity. Provider reputation is not recognition. Sponsor visibility is not quality. A mature rating system should distinguish: * user experience feedback; * implementation experience; * support responsiveness; * documentation quality; * serviceability; * accessibility; * maintainability; * and institutional status. Social signals should be visually and semantically distinct from formal signals. A high rating may help a user consider an object. It must not replace standards, Registry, conformance, verification, or public-safe review. *** ## 6.13 Marketplace and Foundry Foundry prepares many Marketplace objects. Marketplace displays and distributes them under governance. The relationship is direct: Foundry designs. Foundry assembles. Foundry tests. Foundry packages. Foundry documents. Foundry prepares Bills of Materials and Evidence Passports. Foundry assigns release state. Marketplace lists. Marketplace classifies. Marketplace exposes. Marketplace routes users to adoption, support, or provider pathways. Marketplace tracks lifecycle. Marketplace displays claims limits. A Foundry release candidate should not be listed as production-ready. A Foundry package should not be described as certified. A Foundry package may be discoverable as experimental, sandbox, pilot, supported, or verified depending on record. Marketplace is the outward-facing surface of Foundry maturity. It must not get ahead of Foundry truth. *** ## 6.14 Marketplace and NXS-STU Marketplace may include NXS-STU workflows and objects compatible with NXS-STU. These may include: * dashboards; * simulations; * controlled-room workflows; * observability panels; * public authority learning environments; * decision-support preparation workflows; * scenario tools; * AI assistants; * maps; * digital twins; * public-safe export templates; * and domain rail workflows. Marketplace objects related to NXS-STU require special caution because runtime interfaces can appear authoritative. An NXS-STU workflow listing should state: * workflow class; * user role; * runtime requirements; * data source requirements; * public-safe state; * reliance boundary; * authority boundary; * public authority capacity if relevant; * AI involvement if relevant; * export restrictions; * and correction path. An NXS-STU dashboard is not a public warning. A simulation is not forecast certainty. A decision-support workflow is not lawful decision-making. Marketplace must make these boundaries visible before adoption. *** ## 6.15 Marketplace and Digital Public Goods Marketplace is a major distribution surface for Digital Public Goods. Digital Public Goods may include: * software; * schemas; * datasets; * APIs; * models; * documentation; * validators; * templates; * public-safe reports; * training content; * reference implementations; * connectors; * and dashboards. Marketplace can help users find and reuse these assets. But public-good status must not create false assumptions. Open does not mean supported. Public does not mean public-safe for every use. Reusable does not mean maintained. A repository does not mean production-ready. A fork is not authorized architecture by default. A Digital Public Good listing should state: * license; * steward; * maintainer; * version; * support state; * maintenance state; * security state; * dependency state; * public-safe state; * authorized fork status; * conformance posture; * and lifecycle state. Marketplace should make Digital Public Goods easier to use without obscuring their limits. *** ## 6.16 Marketplace and Open Collaboration Marketplace is the durable discovery surface for mature outputs of Open Collaboration. Open Collaboration may generate: * code; * documentation; * data dictionaries; * schemas; * translations; * public-safe templates; * issue resolutions; * community tools; * Academy resources; * and experimental prototypes. Not every open contribution should enter Marketplace. Marketplace entry should require packaging, classification, review, licensing, support status, public-safe assessment where needed, and lifecycle assignment. This preserves open collaboration without turning raw contribution into ecosystem product. Open Collaboration allows the ecosystem to build together. Marketplace makes selected outputs discoverable once they are ready. Foundry may help convert collaborative work into supported packages. Registry may record status where relevant. This chain prevents openness from becoming disorder. *** ## 6.17 Marketplace and Developer Ecosystem Marketplace is inseparable from the developer and integrator ecosystem. Developers need structured pathways to build and publish: * connectors; * apps; * packs; * agents; * dashboards; * workflows; * simulations; * public-safe templates; * Marketplace extensions; * Digital Public Goods; * and implementation tools. A developer ecosystem may include: * SDKs; * APIs; * CLI tooling; * sandboxes; * developer documentation; * schema validators; * conformance tools; * test harnesses; * package registries; * security checks; * verification pathways; * publishing rules; * issue trackers; * support forums; * and maintainer pathways. But developers do not become protocol authority by building. An integration does not become conformance by functioning. A plugin does not become recognized by popularity. A package does not become public-safe by being useful. Marketplace gives developers a route into Nexus. Governance keeps the route safe. *** ## 6.18 Marketplace and Providers Marketplace may include provider profiles and provider services. Providers are important because Nexus requires implementation, integration, support, localization, maintenance, cybersecurity, data engineering, cloud and edge operations, Academy delivery, NXS-STU configuration, Foundry packaging, node support, and customer success. Provider Marketplace entries should identify: * provider identity; * qualification status; * service scope; * geography; * sector experience; * technical capabilities; * support obligations; * cybersecurity posture; * data governance obligations; * conflict controls; * public-safe obligations; * finance-boundary obligations; * claims permissions; * suspension conditions; * and Registry reference where applicable. A provider listing is not procurement approval. A provider profile is not endorsement. A qualified provider is qualified only within scope. A provider cannot self-certify. Provider visibility must not become procurement preference. Marketplace supports provider discovery while preserving provider neutrality. *** ## 6.19 Marketplace and Social Enterprise Marketplace is an important pathway for social enterprises and mission-aligned public-interest ventures. Social enterprises may offer: * local implementation services; * community observatory support; * training; * translation; * accessibility services; * resilience tools; * community science tools; * domain-specific services; * public-safe communication support; * maintenance services; * and local economic participation. Marketplace can help mission-aligned enterprises become visible and usable. But visibility must not become governance privilege. A social enterprise is not a public-good steward by default. A community-serving offering is not community endorsement by default. A Marketplace listing is not recognition. A sponsor-supported social enterprise is not controlled by the sponsor unless records say otherwise, and sponsor control would itself be restricted. Marketplace should support public-interest economic participation while preserving anti-capture discipline. *** ## 6.20 Marketplace and Public Authority Users Marketplace may help public authorities discover relevant capabilities, but public authority suitability must be carefully bounded. A public authority user may look for: * public authority learning packs; * training modules; * NXS-STU workflows; * public-safe dashboards; * observatory patterns; * procurement-neutral specifications; * data governance tools; * public warning boundary guidance; * emergency preparedness simulations; * literacy in compute under national control; * and risk intelligence packs. Marketplace should clearly distinguish: * learning use; * exploratory use; * controlled review use; * public-safe use; * procurement-neutral reference use; * lawful adoption pathway; * and operational use where separately authorized. A Marketplace listing does not create public authority adoption. A public authority download is not approval. A training module is not legal advice. A dashboard is not public warning. Public authority-facing Marketplace design must preserve sovereignty and lawful process. *** ## 6.21 Marketplace and Finance-Readable Objects Marketplace may include finance-readable readiness objects, but they require strict non-execution discipline. Such objects may include: * project-readiness packs; * resilience evidence templates; * disaster risk finance tools; * adaptation finance evidence packs; * sponsor-capital mapping templates; * diligence preparation checklists; * Project SPV literacy modules; * portfolio observability dashboards; * and risk translation tools. These objects may support understanding. They must not imply: * investment advice; * underwriting; * insurance approval; * credit rating; * securities offering; * lending decision; * brokerage; * placement; * capital commitment; * or financial close. Marketplace should display finance-boundary language prominently where relevant. Finance-readable does not mean finance-executed. *** ## 6.22 Marketplace and Pack-Based Scale Marketplace is the main distribution layer for pack-based scale. Packs allow Nexus to modularize capability across domains and contexts. Marketplace helps users find: * water packs; * energy packs; * food packs; * health packs; * disaster risk packs; * climate packs; * biodiversity packs; * city packs; * corridor packs; * public authority learning packs; * community science packs; * Indigenous knowledge safeguard packs; * social enterprise packs; * finance-readable readiness packs; * and sector-specific implementation packs. Pack listings should state: * domain; * rail compatibility; * data requirements; * compute requirements; * NXS-STU compatibility; * Edge compatibility; * public-safe status; * maturity; * support; * steward; * provider options; * jurisdictional limits; * and lifecycle state. A pack is not a rail. A pack is not deployment. A pack is not public authority adoption. Marketplace makes packs discoverable while preserving their limits. *** ## 6.23 Marketplace and Nodes, Hosts, and Observatory Patterns Marketplace may list observatory patterns, node packages, host-readiness tools, and related services. These objects may support: * node planning; * host assessment; * sensor configuration; * edge compute setup; * observatory workflows; * data governance; * community safeguards; * public-safe map production; * node dashboards; * and lifecycle support. A node pattern is not an active node. A host-readiness tool is not host approval. A sensor package is not mature observatory capability. An observatory dashboard is not public warning. Marketplace must preserve the distinction between pattern, package, deployment, node status, host status, and maturity state. Node and host claims must remain tied to Registry. *** ## 6.24 Marketplace and Academy Marketplace may include Academy-linked offerings. These may include: * courses; * learning paths; * credentials; * operator training; * public authority learning modules; * provider readiness modules; * sponsor orientation modules; * community science training; * Indigenous knowledge safeguard training; * finance-reader literacy; * NXS-STU training; * Foundry training; * node operator training; * and public-safe publication training. Academy listings should state: * audience; * level; * prerequisites; * completion status; * credential status; * renewal requirements; * scope of competence; * non-effect; * and whether the course is official, partner-provided, community-provided, or third-party. A course completion is not professional licensure. A credential is not governance authority. A training record is not provider qualification unless separately recorded. Marketplace should make learning accessible without inflating learning into authority. *** ## 6.25 Marketplace and Consortium Pathways Marketplace supports national and regional consortium pathways. A [National Nexus Consortium](/organization/governance-in-operation/nnc.md) may use Marketplace to find: * domain packs; * training resources; * public authority learning tools; * provider services; * node patterns; * Foundry packages; * NXS-STU workflows; * public-safe templates; * finance-readable readiness objects; * and social enterprise offerings. A National Consortium Company may use Marketplace for execution-facing packages and services under proper agreements. A Project SPV may use Marketplace for defined project-support objects, data rooms, evidence packs, and implementation services. The distinctions must remain visible. A National Nexus Consortium is not a company. A National Consortium Company is not Nexus. A Project SPV is not the public-good rail. A Marketplace object used by an SPV does not become public-good authority. Marketplace supports lawful pathway formation without collapsing public-good and execution layers. *** ## 6.26 Marketplace and Anti-Capture Discipline Marketplace is especially vulnerable to capture. Capture may occur when: * sponsors buy visibility; * large vendors dominate rankings; * providers influence certification; * social prestige becomes trust; * commercial objects crowd out Digital Public Goods; * public-good components are enclosed inside paid packages; * public authority-facing listings imply endorsement; * finance-readable products imply investment opportunity; * or Marketplace governance becomes controlled by the actors listed in it. Nexus Marketplace must resist these patterns. At minimum: * ranking should not be reducible to sponsorship; * trust signals should not be purchasable; * paid listings should be clearly distinguished if ever used; * provider influence should be controlled; * verification should remain criteria-based; * public-good objects should remain visible; * Digital Public Goods should not be buried by commercial prominence; * sponsor support should not determine recognition; * and governance should remain role-separated from commercial participation. Marketplace can support economic activity. It must not let economic activity redefine trust. *** ## 6.27 Marketplace and Public-Good / Enterprise Stack Separation Marketplace sits at the interface between the public-good stack and the enterprise stack. This is one of its most delicate roles. Public-good stack objects may include: * Digital Public Goods; * open standards; * schemas; * public-safe templates; * Academy materials; * public-good reports; * open-source tools; * public authority learning materials; * community safeguards; * ontology tools; * and reference implementations. Enterprise stack objects may include: * managed services; * support packages; * premium integrations; * production NXS-STU workflows; * provider services; * implementation packages; * National Consortium Company services; * Project SPV tools; * commercial dashboards; * and licensed deployment units. Marketplace may display both. It must not collapse them. A commercial implementation does not own the public-good component it uses. A public-good object does not automatically include enterprise support. A managed package may include open-source components, but it must respect licenses, attribution, and sustainability obligations. Marketplace should make component composition, licensing, and support visible. *** ## 6.28 Marketplace and Licensing Marketplace requires licensing discipline. Every listed object should state its license or access terms. Licensing should address: * ownership or stewardship; * permitted use; * prohibited use; * commercial use; * public-sector use; * modification rights; * redistribution rights; * attribution; * support status; * maintenance obligations; * dependency licenses; * data rights; * API terms; * AI model terms; * public-safe output terms; * finance-boundary terms; * termination; * renewal; * and claims limits. A user should not have to guess whether an object is open, licensed, supported, restricted, commercial, public-safe, experimental, or deprecated. Marketplace licensing makes reuse safer. It also protects public-good assets from invisible enclosure. *** ## 6.29 Marketplace and Revenue Waterfall Marketplace may participate in Revenue Waterfall discipline. Where Marketplace objects use public-good components, Foundry packages, Digital Public Goods, partner capabilities, data products, or support services, revenue allocation should be visible in the appropriate records. A Revenue Waterfall may support: * public-good maintenance; * open-source sustainability; * GCRI technical methods; * public-safe review; * GRA finance-readiness mappings; * NXS-NSF policy and entitlement tooling; * Foundry packaging; * NXS-STU runtime; * Marketplace operation; * provider services; * partner components; * data providers; * local implementers; * support reserves; * correction reserves; * and decommissioning reserves. Revenue must not buy status. Payment may support maintenance. Payment may support review cost. Payment may support service. Payment may not purchase recognition, conformance, public-safe approval, public authority adoption, or finance validity. No Marketplace revenue, allocation or payment is recorded, and the marketplace deployment profile is blocked while the release hold is active \[4]. Marketplace economics must be public-interest aligned. *** ## 6.30 Marketplace and Lifecycle Discipline Marketplace must manage object lifecycles. Objects cannot simply accumulate. Capabilities change. Dependencies break. Connectors become obsolete. Packs evolve. Support weakens. Security issues emerge. Data rights expire. Public-safe status changes. Provider status changes. Objects should move through explicit lifecycle states: * submitted; * listed; * supported; * verified where applicable; * updated; * narrowed; * deprecated; * suspended; * withdrawn; * retired; * archived. Lifecycle display should be prominent. A deprecated object should not appear as current. A suspended provider service should not be available. An unsupported Digital Public Good should not appear maintained. A superseded pack should link to the current pack. Lifecycle discipline turns Marketplace from catalogue into governed ecosystem memory. *** ## 6.31 Marketplace and Correctionability Marketplace must be correction-capable. Corrections may concern: * object class; * provider identity; * support status; * verification status; * public-safe status; * conformance posture; * finance-readable language; * public authority suitability; * license terms; * dependency information; * security status; * ratings; * reviews; * false claims; * sponsor influence; * data rights; * or Marketplace display. Correction may require: * label change; * claims correction; * listing update; * warning notice; * suspension; * delisting; * trust-signal withdrawal; * Registry update; * public clarification; * provider notice; * user notice; * protocol revocation; * or archive update. Correctionability is critical because Marketplace surfaces are public meaning surfaces. An incorrect listing can mislead many users quickly. *** ## 6.32 Marketplace and Registry Marketplace should link to Registry where status matters. Registry may record: * provider qualification; * object listing status; * verification status; * trust-signal status; * conformance record; * public-safe status; * Digital Public Good lifecycle; * Foundry package release state; * NXS-STU workflow status; * node package status; * sponsor support record; * correction; * suspension; * withdrawal; * deprecation; * retirement. Marketplace displays should not become the source of truth where Registry is required. Marketplace should surface Registry truth. If Registry state changes, Marketplace state should update. This prevents mismatch between institutional record and marketplace display. *** ## 6.33 Marketplace and Protocol Protocol may enforce Marketplace rules. Protocol may govern: * provider access; * listing submission; * review workflows; * trust-signal display; * verification display; * install permissions; * API keys; * download access; * object updates; * deprecation warnings; * public-safe export; * user entitlements; * data-room access; * revenue reporting; * and suspension or delisting. Protocol should follow Registry and governance. A provider key does not create qualification. A trust-signal display does not create certification; no certificate is issued. A download entitlement is not public authority adoption. A Marketplace install is not deployment authorization. Protocol makes Marketplace operational. Governance keeps it honest. *** ## 6.34 Marketplace and Security Marketplace must treat security as a first-order requirement. Objects may include code, APIs, AI agents, data connectors, dashboards, scripts, workflows, packages, and integrations. These can create security risks. Marketplace security should address: * code review; * dependency scanning; * supply-chain security; * vulnerability disclosure; * signing; * provenance; * permission scopes; * sandboxing; * API key governance; * data access; * model security; * agent behavior; * provider security obligations; * user notifications; * patching; * and emergency delisting. Security state should be visible. A package with known vulnerabilities should not appear current. A connector with broad data access should state its permissions. An agent with tool access should show its scope. Marketplace trust requires security transparency. *** ## 6.35 Marketplace and AI Agents and Swarms AI agents and swarms require special Marketplace governance. A listed agent should state: * purpose; * model or architecture where appropriate; * tool permissions; * data permissions; * retrieval sources; * output class; * human review requirement; * auditability; * public-safe constraints; * prohibited uses; * role boundaries; * status awareness; * correction pathway; * and revocation conditions. An agent does not create recognition. It does not assign final status. It does not issue public warnings. It does not provide investment advice. It does not make lawful decisions. It does not override Registry. A swarm requires even stronger governance because coordinated agents can create emergent behavior. Marketplace must treat AI capability as useful but bounded. *** ## 6.36 Marketplace and Data Products Marketplace may include data products. These require strong governance. A data product listing should state: * data source; * steward; * license; * collection method; * update cycle; * geographic scope; * temporal scope; * data quality; * provenance; * handling class; * personal data status; * sensitive geography status; * community knowledge status; * Indigenous knowledge status; * public authority sensitivity; * market sensitivity; * public-safe status; * permitted use; * prohibited use; * and correction pathway. A dataset is not neutral simply because it is listed. A data product may be useful but restricted. A public dataset may still be unsafe for some uses. A data product may be suitable for learning but not operational decision. Marketplace must make data rights and handling visible. *** ## 6.37 Marketplace and Public-Safe Outputs Marketplace pages themselves are outputs. They must be public-safe where public. A Marketplace page should not: * overstate object maturity; * imply recognition by listing; * imply public authority adoption; * imply procurement preference; * imply finance execution; * imply community endorsement; * imply sponsor control; * hide security concerns; * hide dependency risks; * hide deprecated status; * or hide support limitations. Marketplace public-safe design should include: * status labels; * scope labels; * version labels; * support state; * non-effect notes; * claims guidance; * correction notices; * and lifecycle notices. Marketplace interface design is part of public-safe governance. *** ## 6.38 Marketplace and Search, Discovery, and Ranking Search and ranking are governance issues. A Marketplace user will often interpret top results as better, more trusted, more mature, or more endorsed. Marketplace ranking should therefore be disciplined. Possible ranking factors may include: * relevance; * object class match; * current support state; * conformance or verification status; * public-safe status; * compatibility; * user context; * accessibility; * serviceability; * lifecycle state; * and language or region fit. Ranking should not be secretly determined by sponsorship, vendor size, political influence, or internal preference. Sponsored or promoted items, if used, should be clearly labeled and separated from trust status. Search should allow filtering by: * object class; * status; * support; * conformance; * verification; * public-safe state; * provider; * region; * domain; * license; * cost; * maturity; * accessibility; * and lifecycle state. Discovery must be useful without becoming manipulative. *** ## 6.39 Marketplace and Accessibility Marketplace should be accessible. Users may include public authorities, companies, universities, communities, developers, providers, sponsors, finance readers, national groups, regional groups, students, and technical teams. Marketplace accessibility should include: * clear object classes; * plain-language summaries; * expert technical detail; * controlled vocabulary support; * filtering; * comparison tools; * multilingual support where appropriate; * screen-reader compatibility; * low-bandwidth access where needed; * public-safe summaries; * accessible documentation; * and clear non-effect language. Accessibility does not mean removing precision. It means making precision usable. Marketplace should help users make responsible choices. *** ## 6.40 Marketplace and Comparison Marketplace should support comparison, but only within object classes and declared criteria. Users may need to compare: * connectors; * packs; * services; * providers; * dashboards; * agents; * training offerings; * Digital Public Goods; * Foundry packages; * NXS-STU workflows; * observatory patterns; * and data products. Comparison should be profile-aware. A connector should be compared with connectors, not with full packs. A provider should be compared within service scope. A Digital Public Good should not be compared with a managed enterprise service without showing support difference. A free open-source tool and a managed package may both be valid, but their support, security, and lifecycle obligations differ. Comparison should show: * class; * scope; * maturity; * support; * cost; * license; * dependencies; * conformance posture; * verification; * public-safe status; * security status; * and limitations. Comparison without ontology creates confusion. *** ## 6.41 Marketplace and External Organizations Marketplace is a practical resource for external organizations. A public authority can use Marketplace to find learning packs, public-safe tools, observatory patterns, NXS-STU workflows, and procurement-neutral references while understanding that listing is not adoption. A company can use Marketplace to find connectors, providers, packs, support services, Foundry packages, and NXS-STU workflows while understanding that implementation remains bounded. A university can use Marketplace to find Digital Public Goods, Open Collaboration pathways, Academy materials, research tools, and Community Science objects. A community organization can find public-safe tools, Community Science resources, accessibility support, translation resources, and safeguard-aware participation objects. A sponsor can find public-good capacity needs and sustainability opportunities without gaining control. A provider can find listing pathways, verification requirements, support obligations, and developer tools. A national group can find resources for [National Working Groups](/organization/governance-in-operation/nwg.md), National Nexus Consortium formation, public authority learning, node readiness, and provider readiness. A finance reader can find finance-readable literacy and readiness tools without mistaking them for finance execution. Marketplace makes Nexus usable beyond its founding institutions. *** ## 6.42 Marketplace Governance Marketplace requires governance. Marketplace governance should address: * object class definitions; * listing eligibility; * intake; * review; * provider verification; * steward verification; * license verification; * security review; * public-safe review; * conformance posture; * verification; * attestation; * rating rules; * ranking rules; * sponsor visibility rules; * provider neutrality; * data governance; * AI agent governance; * user reviews; * complaints; * correction; * suspension; * delisting; * retirement; * archive; * appeal or reconsideration where appropriate; * and Registry synchronization. Marketplace governance must be role-separated. A provider should not approve its own trust signal. A sponsor should not purchase trust. A platform administrator should not override Registry status. A user rating should not replace conformance. A commercial team should not suppress public-good alternatives. Governance makes Marketplace reliable. *** ## 6.43 Marketplace Records Marketplace should generate records. Records may include: * listing application; * object classification; * steward record; * provider record; * review record; * license record; * support record; * security record; * public-safe record; * verification record; * attestation record; * rating record; * user review record; * complaint record; * correction record; * suspension record; * delisting record; * retirement record; * archive record; * revenue allocation record; * and Registry linkage. Records prevent Marketplace from governing by interface alone. A listing is a record-bearing state. A trust signal is a record-bearing state. A suspension is a record-bearing state. Marketplace records protect users and contributors alike. *** ## 6.44 Marketplace Maturity Model Marketplace itself should have a maturity model. A Marketplace may progress through: * concept; * internal catalogue; * controlled beta; * public-safe catalogue; * provider catalogue; * Digital Public Good catalogue; * Foundry package catalogue; * NXS-STU workflow catalogue; * developer marketplace; * verified-object marketplace; * national or regional marketplace views; * enterprise support marketplace; * mature ecosystem marketplace. A beta Marketplace should not be described as mature. A catalogue is not a trust marketplace. A provider directory is not certification. A mature Marketplace requires object typing, lifecycle, support, verification, Registry linkage, correction, search governance, and anti-capture controls. Marketplace maturity should be stage-truthful. *** ## 6.45 Marketplace and National / Regional Views Marketplace may need national and regional views. Different jurisdictions and regions may need localized discovery based on: * lawful basis; * language; * data residency; * public authority capacity; * available providers; * local support; * regional corridors; * shared ecology; * national standards; * procurement-neutral references; * community safeguards; * Indigenous knowledge protocols; * and infrastructure conditions. National or regional Marketplace views should not fork the Marketplace ontology. They should filter and localize the common architecture. A national view is not a separate Marketplace authority unless formally established. A regional view is not regional supremacy. Local availability does not imply global status. National and regional views make Marketplace useful without fragmenting it. *** ## 6.46 Marketplace and Campaign Marketplace supports Campaign by making mature capabilities discoverable during large-scale activation. Campaign activity may draw attention to: * domain packs; * public authority learning tools; * Academy pathways; * Community Science objects; * observatory patterns; * social enterprise offerings; * Digital Public Goods; * provider pathways; * accelerator resources; * and national or regional resources. Campaign must not inflate Marketplace objects. A campaign feature is not recognition. A featured object is not procurement preference. A sponsor-supported campaign is not sponsor control. Campaign should route attention into Marketplace discipline, not around it. Marketplace gives campaign activity a governed landing surface. *** ## 6.47 Marketplace Failure Modes Nexus should be explicit about Marketplace failure modes. **App-store reduction** occurs when Marketplace is treated as a generic software catalogue rather than a governed extension layer. **Listing-as-recognition drift** occurs when discoverability is mistaken for recognition, conformance, or standing. **Badge inflation** occurs when badges or trust signals imply more than their scope. **Rating capture** occurs when popularity or user reviews replace formal status. **Pay-to-play capture** occurs when sponsors or vendors buy visibility that users interpret as trust. **Provider capture** occurs when implementation vendors shape listing rules, certification, ranking, or standards. **Public-good burial** occurs when commercial offerings hide or displace Digital Public Goods. **Open-source abandonment** occurs when listed open assets appear current despite no maintenance or support. **Marketplace security failure** occurs when unsafe code, agents, connectors, or data products circulate without proper controls. **AI-agent overreach** occurs when agents are listed without role, tool, data, audit, or output boundaries. **Public authority overclaim** occurs when Marketplace objects imply adoption, approval, public warning authority, or procurement suitability. **Finance overclaim** occurs when readiness objects imply investment advice, underwriting, rating, insurance, or capital commitment. **Community endorsement drift** occurs when community-related tools imply community consent or endorsement without record. **Indigenous knowledge extraction** occurs when knowledge-related objects are listed without Indigenous-led governance and protections. **Lifecycle failure** occurs when deprecated, suspended, unsupported, or retired objects remain visible as current. **Registry mismatch** occurs when Marketplace status diverges from recorded state. **Correction failure** occurs when errors, false claims, or unsafe listings cannot be corrected quickly. Marketplace governance exists to prevent these failures. *** ## 6.48 Strategic Value of Marketplace The strategic value of Marketplace is that it lets Nexus grow without losing coherence. Marketplace allows Nexus to: * make capabilities discoverable; * widen developer participation; * support pack-based scale; * support Digital Public Goods; * support social enterprise; * support Open Collaboration; * help public authorities find learning resources; * help companies find implementation pathways; * help universities contribute; * help communities access safeguarded tools; * help providers participate under rules; * help sponsors support public-good capacity without control; * help national and regional pathways find usable objects; * help finance readers understand readiness tools; * connect Foundry outputs to users; * connect NXS-STU workflows to adoption; * and support ecosystem buildout as a public-interest economic field. Marketplace makes the ecosystem easier to enter. Governance makes that entry trustworthy. In strategic terms, Marketplace is the distributed adoption surface of Nexus Acceleration. It is how the system grows beyond the center while remaining one system. *** ## 6.49 Final Statement on Nexus Marketplace Nexus Marketplace is designed as the governed extension, discovery, participation, trust, distribution, developer, provider, social enterprise, Digital Public Good, and public-interest economic layer of the Nexus Ecosystem. It is the surface through which apps, connectors, APIs, packs, agents, swarms, dashboards, observatory patterns, NXS-STU workflows, Foundry packages, Digital Public Goods, Academy offerings, simulation modules, assessment tools, implementation services, deployment support, provider capabilities, social enterprise offerings, data products, evidence products, proof tools, and public authority learning objects become discoverable and usable under controlled rules. Marketplace is essential because Nexus cannot scale through central build alone. It must allow distributed builders, providers, universities, social enterprises, public-interest ventures, communities, developers, OEMs, systems integrators, local implementers, and national or regional actors to contribute to one widening ecosystem. But Marketplace is bounded because extension without governance becomes fragmentation. A listing is not recognition. A badge is not universal approval. A rating is not conformance. A provider profile is not procurement preference. A Marketplace app is not public authority adoption. A finance-readable tool is not investment advice. A social enterprise listing is not governance status. A Digital Public Good is not automatically maintained. An NXS-STU workflow is not lawful decision-making. A connector is not a rail. A pack is not deployment. Marketplace succeeds when it makes capability visible while making limits equally visible. It is where Nexus becomes easier to use without becoming easier to misuse. It is where public-good infrastructure becomes economically supportable without becoming commercially captured. It is where distributed growth becomes governed growth. Through Marketplace, Nexus becomes extensible, participable, discoverable, scalable, and economically alive while preserving semantic discipline, standards coherence, Registry truth, protocol subordination, public-safe publication, provider neutrality, sponsor support-without-control, public-good separation, lifecycle discipline, correctionability, and constitutional truth. *** ## Next steps Read **VII. Consortiums** to understand the institutional architecture that carries Marketplace-enabled ecosystem buildout into national, regional, company, and Project SPV pathways. The company and SPV steps are taken, if at all, by competent actors outside the programme. Read **VIII. Campaign** to understand how Marketplace objects, public-good capacity, programs, providers, social enterprises, and mature deployment pathways become part of coordinated global activation. Read **IV. The Foundry pillar and the systems** to understand how many Marketplace objects are designed, packaged, tested, verified, licensed, and prepared for listing. Read **V. Programs** to understand how Marketplace objects become usable through Academy, public authority learning, provider readiness, community pathways, and accelerator tracks. Read **II. Compute** and **III. Edge** to understand the technical estate and observatory layer that many Marketplace objects ultimately support. Read **VII. Consortiums** and **VIII. Campaign** to understand the institutional structures and the activation horizon within which Marketplace pathways are designed to operate. *** ## Marketplace object classes and the twenty canonical systems Marketplace is not a twenty-first system. Each object class in section 6.7 already has a canonical owner, which remains "the correction authority" for its records \[1]. Table 1 gives the mapping this documentation uses. *Table 1. Marketplace object classes and their canonical owners. Remits and boundaries quoted from D-V3-0003, D-V3-0004 and D-V3-0001 \[1]\[2]\[6]; mapping by this documentation, as of 2026-10-16.* | Object class (section) | Canonical owner | Remit or boundary (quoted where marked) | | ------------------------------------------ | ------------------------------------------------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------- | | 6.7.1 NXS-APP | NXS-APP | "Application catalog, installation, instances, dependencies, health, upgrades, rollback and retirement" | | 6.7.2 Connectors | NXS-NXQ | "Software, packages, connectors, models, tools, skills, agents, entitlements and capability lifecycle" | | 6.7.3 Packs | NXS-NXQ, built in NXS-FAC | Packages under NXS-NXQ; build and signing in NXS-FAC | | 6.7.4 Agents | NXS-NXQ; NEIF Agent Workforce Fabric | "Agents do not own domain facts or institutional authority" | | 6.7.5 Swarms | NEIF and NIRF fabrics | Routing "cannot override NXS-NSF, NXS-COR, NXS-NXQ or domain authority" | | 6.7.6 Dashboards and visualization modules | NXS-STU | "Visual composition, dashboards, maps, forms, workflow experiences, reusable artifacts and deployment profiles" | | 6.7.7 Observatory patterns | NXS-OPS, with NXS-COR configuration | Observatory nodes and instruments | | 6.7.8 NXS-STU workflows | NXS-STU | Composition; the Universal Runtime executes | | 6.7.9 Foundry packages | NXS-FAC, NXS-NXQ | "Blueprints, Builder operations, code and artifact generation, verification, builds, signing and assembly" | | 6.7.10 Digital public goods | NXS-NXQ; Rights Control Plane | Only items listed in the DPG Registry or meeting the DPG Standard with a recorded licence decision | | 6.7.11 Services | NXS-RLS for agreements and receipts | "Participants, roles, agreements, protocols, obligations, lawful handoffs, transaction envelopes, receipts and disputes" | | 6.7.12 Training and Academy offerings | [NXS-HUB](/organization/systems/nxs-hub.md) | "Institutional knowledge, records, citations, collaboration, tickets, runbooks, meetings, learning, support and service knowledge" | | 6.7.13 Evidence and proof tools | Evidence and Receipt Fabric; [NXS-GRX](/organization/systems/nxs-grx.md) | "A receipt proves the recorded event within scope, not broader correctness" | | 6.7.14 Public authority learning objects | NXS-HUB, NXS-POR | "Public-authority learning is not approval" | | 6.7.15 Finance-readable readiness objects | NXS-GRX, [NXS-DSS](/organization/systems/nxs-dss.md), NXS-RLS | "Finance-readiness is not finance" | ## Listing is not recognition: the separations in one figure
A Marketplace listing and its separations. A provider submission passes an intake gate (object class, rights, bill of materials), a computed verification record may follow, and a listing makes the object discoverable only. The listing is not an NXS-NSF recognition decision and not a procurement decision; a signed attestation is a separate act; any listing can be delisted, suspended or corrected.

Figure 1. How a Marketplace listing is designed to relate to verification, attestation, recognition and procurement. The grey links from the listing to recognition and procurement, and from attestation to the listing, are separations: a listing leads to neither decision and does not create an attestation. A design, not a record of any listing; the marketplace profile is blocked by the release hold. Source: D-V3-0004, release hold policy and the Nexus Documentation Standard [2][4][9], as of 2026-10-16.

Text description of Figure 1 A provider's submission passes an intake gate that checks object class, rights and bill of materials. A computed verification record may follow, and then a listing, which makes the object discoverable only. A listing is not an NXS-NSF recognition decision and is not a procurement decision by a buyer or authority. An attestation signed by a named party is a separate act, not created by listing. Any listing can be delisted, suspended or corrected.
The consortium programme's testbed offering O04, Responsible Innovation and Interoperability Testbeds, states the same separation from the other side: "Sponsorship never influences a result. Testbed participation is not a regulatory sandbox, a certification or a procurement status." For SMEs and start-ups: "Evaluation never depends on a high contribution, and testing is not certification." For standards bodies: "Test completion is never presented as accredited certification" \[5]. **Marketplace rule ACC-VI-1.** No object SHALL be displayed with a certificate, badge or accreditation mark; any trust signal SHALL name what was checked, against which profile and version, by whom, for which scope, and until when (source: D-V3-0004 "Verification is not certification" \[2]; the Nexus Documentation Standard \[9]). **Marketplace rule ACC-VI-2.** No listing SHALL be published while the marketplace deployment profile is blocked by the release hold, and no listing SHALL imply recognition, procurement preference or endorsement (source: release hold policy \[4]; D-V3-0004 "Technology readiness is not procurement approval" \[2]). ## What Marketplace is not * It is not open. The marketplace deployment profile is blocked while the release hold is active, and no listing is recorded \[4]. * It is not a certification or badging scheme; it issues no certificate, badge or accreditation \[2]\[9]. * It is not a procurement channel. A listing is not procurement preference, and "Technology readiness is not procurement approval" \[2]. * It is not an app store that sells trust. Payment cannot purchase recognition, conformance, public-safe approval or finance validity. * It is not a finance venue. Finance-readable objects do not offer securities, credit or insurance; "Participation is not an offer of securities or investment advice" \[5]. * It is not a V3 system. Its functions belong to NXS-NXQ, NXS-APP, NXS-POR, NXS-STU, NXS-RLS (the technical rails and protocol infrastructure for protocol-governed work across institutions) and NXS-NSF \[1]. ## International context (alignment, not endorsement) * **Digital public goods.** The Digital Public Goods Standard \[10] and Registry \[11] are the external test for any listing labelled a digital public good. * **Conformity assessment.** ISO/IEC 17000 separates verification, attestation and certification \[12]; section 6.11 follows that separation. * **Verifiable statements.** The W3C Verifiable Credentials Data Model v2.0 is a reference for signed, machine-verifiable statements about a subject, such as an attestation \[13]; a credential is not a certificate unless issued by a certification body. * **Software supply chain.** The NTIA SBOM minimum elements \[14] and SLSA \[15] are references for object metadata and provenance (sections 6.8 and 6.34). * **AI agents and swarms.** The OECD AI Principles \[16] and the NIST AI Risk Management Framework \[17] are references for section 6.35. * **Accessibility.** WCAG 2.2 is the reference for section 6.39; Marketplace pages, if built, would be designed to meet WCAG 2.2 level AA, and no conformance is claimed \[18]. Naming these publications implies no partnership, endorsement or conformity. ## Terms used on this page * **Listing.** A record that makes an object discoverable under a defined class and status; not recognition (section 6.10). * **Object class.** The type of a Marketplace object (app, connector, pack, agent and so on), which decides how it is evaluated, displayed and retired (section 6.7). * **Trust signal.** A scoped, dated statement of verification, attestation or recognition attached to an object; replaces the earlier "badge". * **Verification record.** A computed check against a stated profile, version and scope. * **Attestation.** A statement signed by a named party under an executed agreement; not a certificate. * **Delisting.** Removal of an object from discovery, with the reason recorded (section 6.31). ## Related pages * Up: [Acceleration](/organization/introduction/acceleration.md) * Across: [I. Order](/organization/introduction/acceleration/i.-order.md) · [II. Compute](/organization/introduction/acceleration/ii.-compute.md) · [III. Edge](/organization/introduction/acceleration/iii.-edge.md) · [IV. The Foundry pillar and the systems](/organization/introduction/acceleration/iv.-foundry.md) · [V. Programs](/organization/introduction/acceleration/v.-programs.md) · [VII. Consortiums](/organization/introduction/acceleration/vii.-consortiums.md) · [VIII. Campaign](/organization/introduction/acceleration/viii.-campaign.md) * Counterparts: [Systems](/organization/systems.md) · [Nexus Universe](/organization/cooperation/nexus-universe.md) · [IV. Registry](/organization/introduction/standardization/iv.-registry.md) · [III. Status](/organization/introduction/standardization/iii.-status.md) ## Sources 1. Nexus constitutional directive D-V3-0003, *Canonical Twenty-System Constitution and Authority Matrix* (canonical order, remits, completeness and non-ownership rules). Internal record, cited by identifier. 2. 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. 3. Nexus institutional register, *Nexus institutional architecture and participation*: owner decision of 11 October 2026 on GCRI Canada as lead contracting organization (owner-confirmed; counsel review pending), with the legal entity profile notices on operating structure, the lead contracting organization, consortium stewardship, institutional independence, platform ownership and the commercial channel (owner-confirmed; title and instruments unverified). Internal record. 4. Nexus institutional register: release hold policy (in force since 21 July 2026; permitted profiles internal development, pull-request preview, isolated test and non-certified research; blocked profiles include sovereign, marketplace and certified public-good) and claim register. Internal record. 5. Nexus institutional register, consortium programme: operating functions, conversion chain, programme offerings O01 to O10 with their questions, deliverables, entry routes, boundaries and system mappings, decision rights, service levels R0 to R5, current service level R0, separations and case routes; drawing on the consortium directives D-NEXUS-CONSORTIUM-PUBLIC-ARCHITECTURE-2 and D-NEXUS-CONSORTIUM-STAKEHOLDER-READINESS-3. Internal record. 6. Nexus constitutional directive D-V3-0001, *Master Directive V3* (shared constitutional fabrics and their boundary sentences), and the Native Master legal, IP and open-source constitution (D-NEXUS-NATIVE-MASTER-1). Internal record, cited by identifier; the Native Master is not quoted. 7. Nexus institutional register, consortium geography: six regions and fifteen planned hubs, every hub planned; hubs are coordination roles, not offices. Internal record. 8. Public institutional site draft (not yet adopted; owner direction, not a binding record): controlled vocabulary, council vocabulary NNC, NLC and NWG with the note retiring earlier labels, programme status vocabulary and institutional boundary sentences for GRF and GRA. Draft source. 9. Nexus Documentation Standard, draft of 16 October 2026 (purpose and audiences, authority and status, naming, external frameworks and sources), the owner decisions of 16 October 2026 and the introduction audit of 16 October 2026. Internal editorial records; not published. 10. Digital Public Goods Alliance. *Digital Public Goods Standard*. [digitalpublicgoods.net](https://www.digitalpublicgoods.net/standard). Accessed 2026-10-16. 11. Digital Public Goods Alliance. *Digital Public Goods Registry*. [digitalpublicgoods.net](https://www.digitalpublicgoods.net/registry). Accessed 2026-10-16. 12. ISO/IEC (2020). *ISO/IEC 17000:2020, Conformity assessment: Vocabulary and general principles*. (URL not verified) 13. W3C (2025). *Verifiable Credentials Data Model v2.0*, W3C Recommendation. [w3.org](https://www.w3.org/TR/vc-data-model-2.0/). Accessed 2026-10-16. 14. National Telecommunications and Information Administration (2021). *The Minimum Elements for a Software Bill of Materials (SBOM)*. [ntia.gov](https://www.ntia.gov/report/2021/minimum-elements-software-bill-materials-sbom). Accessed 2026-10-16. 15. Open Source Security Foundation. *SLSA: Supply-chain Levels for Software Artifacts*. [slsa.dev](https://slsa.dev/). Accessed 2026-10-16. 16. OECD. *OECD AI Principles* (Recommendation of the Council on Artificial Intelligence). [oecd.ai](https://oecd.ai/en/ai-principles). Accessed 2026-10-16. 17. NIST (2023). *Artificial Intelligence Risk Management Framework (AI RMF 1.0)*. [nist.gov](https://www.nist.gov/itl/ai-risk-management-framework). Accessed 2026-10-16. 18. W3C (2023). *Web Content Accessibility Guidelines (WCAG) 2.2*, W3C Recommendation. [w3.org](https://www.w3.org/TR/WCAG22/). Accessed 2026-10-16. 19. GCRI (2026). *How Nexus works*: the six pillars, their eighteen handoffs and the eight-step cycle (Question, Evidence, Build, Organize, Test, Publish, Decide, Renew). [therisk.global/nexus-cycle](https://therisk.global/nexus-cycle/). Read 2026-10-21. 20. OECD (2018). OECD DAC Blended Finance Principles for Unlocking Commercial Finance for the Sustainable Development Goals. Paris: OECD, December 2018. [oecd.org](https://www.oecd.org/en/publications/2018/12/oecd-dac-blended-finance-principles_898d3549.html). 21. G20 Expert Panel (2022). Boosting MDBs' Investing Capacity: An Independent Review of Multilateral Development Banks' Capital Adequacy Frameworks. Report to the G20, July 2022. [mdbreformaccelerator.cgdev.org](https://mdbreformaccelerator.cgdev.org/an-independent-review-of-multilateral-development-banks-capital-adequacy-frameworks/). 22. The Global Risks Alliance (2026). *Finance and insurance readiness*: readiness evidence is not a financing decision. [globalriskalliance.com/finance-readiness](https://globalriskalliance.com/finance-readiness/). Read 2026-10-21. 23. The Global Risks Alliance (2026). *Lawful handoffs*: readiness evidence is released one to one on the owner's written direction, with no introduction and no pay tied to any transaction. [globalriskalliance.com/finance-readiness/handoff](https://globalriskalliance.com/finance-readiness/handoff/). Read 2026-10-21. 24. GCRI (2026). *Programme status*: Exploration, In formation, Constituted, Active programme, Paused, Closed, Historical record; current service level R0. [therisk.global/consortium/programme-status](https://therisk.global/consortium/programme-status/). Read 2026-10-21. 25. GCRI (2026). *Nexus Reports programme*: quarterly country editions, an annual flagship and specialist series; current approved releases: none. [therisk.global/publications/nexus-reports](https://therisk.global/publications/nexus-reports/). Read 2026-10-21. ## Editorial record * As of: 2026-10-16. 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, status section and a listing-is-not-recognition notice added; "source page" residue removed; Marketplace mapped to NXS-NXQ, NXS-APP, NXS-POR, NXS-STU, NXS-RLS and NXS-NSF; "Universe" disambiguated from the Nexus Universe programme; certification and badging recast as verification, attestation and trust signals, keeping every boundary; GRF and protocol-authority revenue lines aligned to register roles; revenue marked as unrecorded and the blocked marketplace profile stated; object-class table, separations figure, offering O04 boundaries, rules ACC-VI-1 and ACC-VI-2, external context, terms, sources and related pages added; heading levels corrected; all original sections kept. * Change: 2026-10-16 r2, readable document record and status note; Nexus Standards display codes for systems; system naming; Nexus Observatory Protocol note; ownership and licensing statements rewritten without naming any company; internal paths, commit references and status codes replaced with plain words. * Change: 2026-10-21 r3, brought up to date with the published sites, Nexus Standards and the owner's rulings of October 2026: Where this fits line; a Current position section; Nexus Standards described as published ([NS-0](https://nexustandards.com/standards/ns-0/) to [NS-16](https://nexustandards.com/standards/ns-16/) and [NS-3b](https://nexustandards.com/standards/ns-3b/), NIS-1, 348 NRS in 15 series, all PROPOSED; GCRI Canada publisher of record; governance bodies and adoption modes); the national vocabulary of National Nexus, the NNC with its six [Helix councils](/organization/governance-in-operation/councils.md), the NLC and the NWG; the finance boundary on every vehicle passage; the systems named as systems; all original sections kept. --- # 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/acceleration/vi.-marketplace.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.