# VI. Marketplace #### Summary This page defines **Marketplace** within Nexus Acceleration. If **IV. Foundry** explains how Nexus capabilities are designed, assembled, tested, packaged, certified, 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, Studio workflows, providers, developers, integrators, universities, social enterprises, public-interest institutions, and mission-aligned ecosystem actors may become visible under controlled rules. The source page correctly frames Marketplace as the governed extension, discovery, participation, and scale architecture through which Nexus grows without fragmenting its core. It emphasizes that Marketplace is a discovery layer, classification layer, trust layer, scale layer, and governance layer, and that discoverability is not recognition by default. 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 Nexus rail must support many environments: * sovereign compute; * national dense cores; * regional clusters; * observatory nodes; * public authority learning; * Studio 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; * Studio 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. Badging must be scoped. 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. Studio 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 badge may signal a scoped 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 the wider **Nexus Universe** layer. Nexus Universe is the ecosystem application and integration layer through which catalogs, developer portals, Marketplace, ratings, reputation systems, certification, badging, apps, connectors, agents, swarms, packs, observatories, rails, and integration surfaces become visible and usable. 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; * certification and badging; * rating and reputation; * integration pathways; * support portals; * provider pathways; * Academy links; * Foundry-to-Marketplace publishing; * Studio 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 Apps 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 Studio 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, certification-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. 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; * certification or badge state; * Registry reference where applicable; * Foundry reference where applicable; * Studio 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; * certified 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 certified object is certified 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. Certification is scoped. Procurement is external and lawful. Public authority adoption is separate. Marketplace must display this rule clearly. Otherwise, discovery becomes status inflation. *** ### 6.11 Certification, Badging, and Trust Signals Certification and badging can be valuable inside Marketplace, but only if they are bounded trust instruments. A badge 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 badge is current, suspended, expired, or withdrawn. Badges 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 certification; * 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, certification, 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 unless certification exists. A Foundry package may be discoverable as experimental, sandbox, pilot, supported, or certified depending on record. Marketplace is the outward-facing surface of Foundry maturity. It must not get ahead of Foundry truth. *** ### 6.14 Marketplace and Studio Marketplace may include Studio workflows and Studio-compatible objects. 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. Studio-related Marketplace objects require special caution because runtime interfaces can appear authoritative. A Studio 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. A Studio dashboard is not public warning by default. 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; * certification 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, Studio 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; * Studio workflows; * public-safe dashboards; * observatory patterns; * procurement-neutral specifications; * data governance tools; * public warning boundary guidance; * emergency preparedness simulations; * sovereign compute literacy; * 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; * Studio 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; * Studio 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 certificate 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 may use Marketplace to find: * domain packs; * training resources; * public authority learning tools; * provider services; * node patterns; * Foundry packages; * Studio 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; * certification 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 Studio 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; * GRF public-safe review; * GRA finance-readable mappings; * protocol authority tooling; * Foundry packaging; * Studio 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. 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; * certified 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; * certification 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; * badge 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; * certification status; * badge status; * conformance record; * public-safe status; * Digital Public Good lifecycle; * Foundry package release state; * Studio 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; * badge display; * certification 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 badge display does not create certification unless certification exists. 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 certification 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; * certification; * 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; * Studio 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; * certification; * 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, Studio 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 Studio 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, certification requirements, support obligations, and developer tools. A national group can find resources for National Working Groups, 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; * certification; * badging; * 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 badge. 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; * certification record; * badge 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 badge 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; * Studio workflow catalogue; * developer marketplace; * certified 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, certification, 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 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 Studio 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 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, Studio 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. A Studio 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. 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. Foundry** to understand how many Marketplace objects are designed, packaged, tested, certified, 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. --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.therisk.global/organization/introduction/acceleration/vi.-marketplace.md?ask= ``` The question should be specific, self-contained, and written in natural language. 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.