# XII. MARKETPLACE

## 12.1 Marketplace Doctrine

### 12.1.1 Marketplace as discovery surface.

The **Nexus Marketplace** under the Distributed Digital Public Goods Framework shall function as the governed discovery surface for reusable digital public-good objects across the Nexus Ecosystem. It shall enable participants, institutions, National Nodes, National Working Groups, Competence Cells, Academy users, Foundry contributors, Campaign teams, public authority learning participants, researchers, developers, communities, sponsors, providers, capital readers, insurers, donors, and lawful downstream actors to discover objects that have been recorded, classified, reviewed, published, restricted, listed, supported, deprecated, corrected, withdrawn, or archived within the DDPGF object universe.

The Marketplace shall not be a commercial marketplace by default, a procurement platform, a vendor-selection system, a product-validation platform, a finance platform, a certification registry, a public authority approval surface, or an execution environment. Its purpose shall be discovery, distribution, navigation, reuse, support visibility, demand-signal capture, learning access, contribution routing, public-good memory, and handoff awareness within recorded scope. Discovery shall be governed by object identity, object class, access class, support class, review status, Registry status, release class, public-safe status, license class, correction pathway, and boundary notices.

### 12.1.2 Marketplace as public-good distribution layer.

The Nexus Marketplace shall serve as a public-good distribution layer for digital-public-good objects that are open, public-safe, controlled, metadata-only, secure-room-referenced, Academy-routed, Foundry-routed, Studio-routed, Reports-routed, Registry-linked, National Portfolio-linked, Nexus Universe-linked, or handoff-context-linked. It shall make reusable public-good assets easier to find, understand, compare within scope, request, localize, translate, reuse, contribute to, support, or route into appropriate Nexus workflows.

Marketplace distribution shall not collapse access control. An object may be discoverable without being downloadable; listed without being open; described without being released; visible as metadata without exposing restricted content; and handoff-relevant without creating implementation authority. The Marketplace shall preserve the principle that public-good distribution means **usable where lawful, open where safe, controlled where necessary, and always correctable by record**.

### 12.1.3 Marketplace as support discovery environment.

The Nexus Marketplace shall identify support status for listed objects, including whether an object is supported, unsupported, experimental, reference-only, community-maintained, institutionally maintained, secure-room-supported, handoff-recipient-supported, deprecated, withdrawn, archived, or non-continuing. Support discovery may include maintainer contact channels, issue-reporting routes, security-disclosure routes, documentation links, training links, contribution routes, translation routes, accessibility-improvement routes, support-ledger links, sponsor-support records, and public-good continuation needs.

Support discovery shall not create warranty, service-level commitment, professional duty, deployment support obligation, procurement obligation, provider approval, or reliance right unless separately contracted or lawfully recorded outside the default DDPGF posture. Marketplace support status shall remain a record of support conditions, not a guarantee of performance.

### 12.1.4 Marketplace as learning and contribution discovery environment.

The Nexus Marketplace shall enable discovery of learning objects, Academy pathways, Risk Academy pathways, public-safe guides, open textbooks, micro-credentials, WILPs, quests, bounties, builds, contributor guides, maintainer guides, Studio exercises, Campaign opportunities, National Portfolio learning needs, and Foundry contribution pathways. It shall connect learning demand, contribution capacity, public-good work, competency development, and reusable digital objects without converting learning or contribution into employment, professional certification, procurement qualification, or execution authority.

Marketplace learning and contribution discovery shall preserve labor boundaries, youth safeguards, learner privacy, contributor privacy, accessibility requirements, sponsor controls, provider controls, public-safe release controls, and correctionability. Contribution opportunities may be visible, but participation shall remain subject to the relevant object scope, governance record, steward acceptance, review gate, license terms, code of conduct, labor boundary, and data or AI-use restrictions.

### 12.1.5 Marketplace as handoff awareness surface.

The Nexus Marketplace may display handoff-relevant objects, handoff context notes, lawful handoff dependency packages, Grid inputs, TRL notes, Studio workflow summaries, evidence packs, software releases, data papers, model cards, National Portfolio objects, Nexus Universe outputs, and public-safe summaries that may be relevant to lawful downstream actors. The Marketplace may help identify whether an object has potential relevance for National Consortium Companies, Project SPVs, public authorities, providers, operators, universities, labs, donors, insurers, capital readers, community actors, or other competent lawful recipients.

Handoff awareness shall not be handoff approval. A Marketplace listing may show that an object has handoff relevance, but shall not create implementation permission, procurement status, financeability, insurability, public authority approval, provider selection, community consent, Indigenous consent, deployment authorization, operational readiness, or execution authority. Any lawful handoff shall require separate review, recipient responsibility, dependency transfer, boundary notices, correction pathways, and records outside the Marketplace listing alone.

### 12.1.6 Marketplace without procurement, validation, or endorsement.

The Nexus Marketplace shall not operate as a procurement catalogue, preferred-vendor list, approved-product list, certified-solution list, investment platform, grant-allocation tool, insurance underwriting source, public authority approval surface, standards-conformance registry, or endorsement platform by default. Listing, featuring, discovery, download, support interest, reuse signal, user interest, or handoff relevance shall not be interpreted as procurement recommendation, validation, endorsement, certification, financeability, insurability, public authority approval, deployment authorization, or execution authority.

Every Marketplace listing shall carry boundary notices appropriate to its object class. Provider contributions, sponsor support, institutional participation, public authority attendance, capital-reader interest, insurer interest, donor interest, community participation, or media visibility shall not alter the default no-conversion rule.

### 12.1.7 Marketplace as ecosystem memory interface.

The Nexus Marketplace shall function as an ecosystem memory interface by connecting listed objects to Registry status, Reports, repository packages, learning pathways, Foundry builds, Campaign records, Studio workflows, Grid inputs, TRL notes, DICE records, GRIx records, DRI records, Observatory records, Nexus Universe outputs, National Portfolio records, proof receipts, correction records, withdrawal records, archive records, and successor objects. It shall help users understand what exists, what status it holds, what it depends on, what has changed, what has been corrected, what has been deprecated, and what should not be used.

Marketplace memory shall be synchronized with Registry truth wherever an object is Registry-recorded. Where Marketplace visibility conflicts with Registry status, Registry status shall control until corrected. The Marketplace shall not silently preserve outdated, withdrawn, or superseded listings without clear status labels, archive notices, correction notices, or successor links.

### 12.1.8 Marketplace as public-safe demand-signal surface.

The Nexus Marketplace may capture public-safe demand signals, including user interest, download interest, reuse interest, support requests, translation requests, accessibility requests, bug reports, feature requests, national demand signals, handoff interest signals, Academy demand, Foundry demand, Campaign demand, public authority learning interest, community-facing demand, and contributor interest. Such signals may inform Dockets, Foundry backlogs, Academy pathways, Reports priorities, translation priorities, accessibility work, National Portfolio needs, Nexus Universe preparation, support ledgers, and correction priorities.

Demand signals shall be treated as signals, not commitments. A demand signal shall not imply purchaser intent, procurement action, finance commitment, donor commitment, insurance interest, public authority decision, employer demand, community consent, provider validation, or implementation authorization. Demand-signal collection shall comply with privacy, data minimization, user consent, public-safe reporting, anti-manipulation, anti-gaming, and correction controls.

## 12.2 Marketplace Object Classes

### 12.2.1 Software listings.

A **Software Listing** shall describe a software object, repository, library, service, application, dashboard component, API, SDK, connector, adapter, command-line tool, notebook, template, infrastructure-as-code package, test suite, or reference implementation available for discovery through the Marketplace. Software listings shall include repository or access link, version, license, steward, maintainers, support class, security status summary, dependency status where applicable, documentation status, accessibility status where applicable, release class, Registry status, correction pathway, and no-warranty notice.

A Software Listing shall not create production approval, security certification, provider validation, procurement recommendation, deployment authorization, service-level warranty, or execution authority.

### 12.2.2 Data listings.

A **Data Listing** shall describe a dataset, metadata-only record, public-safe dataset, aggregated dataset, synthetic dataset, data dictionary, codebook, schema, data pipeline, feature set, benchmark dataset, DRI dataset, Observatory dataset, or National Portfolio dataset. Data listings shall include data class, access class, rights status, data-use label, AI-use label where applicable, lineage summary, quality notes, sensitivity class, repository location where applicable, public-safe transformation status, Registry status, correction pathway, and data-rights boundary notice.

A Data Listing may make data discoverable without making the data open. Data listing shall not create data access rights, reuse rights, AI training permission, cross-border transfer permission, protected knowledge permission, community consent, Indigenous consent, public authority record status, or handoff permission.

### 12.2.3 Model listings.

A **Model Listing** shall describe a model object, AI system object, agentic workflow, statistical model, machine-learning model, foundation-model interface, fine-tuned model, retrieval-augmented system, classifier, forecasting model, simulation model, digital twin model, risk model, optimization model, decision-support model, benchmark model, or evaluation harness. Model listings shall include intended use, prohibited use, model card link, system card link where applicable, benchmark card link where applicable, evaluation status, data provenance summary, AI-use label, human review requirements, incident pathway, withdrawal pathway, Registry status, and no-approval notice.

A Model Listing shall not create AI safety certification, general validation, automated decision authority, public authority approval, financeability, insurability, procurement readiness, deployment authorization, or execution authority.

### 12.2.4 API listings.

An **API Listing** shall describe a public, controlled, internal, data, model, Registry, Marketplace, Studio, Campaign, Reports, DRI, Observatory, learning, proof receipt, or handoff API object. API listings shall include endpoint class, access class, authentication requirements, authorization model, rate limits where applicable, documentation, version, protocol objects, data-use labels, AI-use labels where applicable, deprecation policy, support class, Registry status, correction pathway, and access-boundary notice.

API listing shall not create data rights, unrestricted access, provider validation, interoperability certification, public authority approval, procurement status, production readiness, or deployment authorization.

### 12.2.5 Dashboard listings.

A **Dashboard Listing** shall describe a dashboard object, visual atlas, DRI dashboard, Observatory dashboard, WFEH-B dashboard, Campaign dashboard, Foundry dashboard, Reports dashboard, Marketplace dashboard, Registry dashboard, Academy dashboard, Studio dashboard, Grid dashboard, National Portfolio dashboard, or handoff dependency dashboard. Dashboard listings shall include source notes, data basis, update cadence, confidence or uncertainty labels where applicable, public-safe status, sensitivity controls, accessibility status, Registry status, correction pathway, and no-decision notice.

Dashboard listing shall not create public authority decision, public warning, rating, ranking, forecast certainty, surveillance authority, operational command, deployment authorization, or finance signal.

### 12.2.6 Studio workflow listings.

A **Studio Workflow Listing** shall describe a Studio workflow, dashboard workflow, digital twin workflow, scenario workflow, AI workflow review, data-room workflow, secure-room workflow, public authority learning workflow, readiness-room workflow, capital-reader room workflow, insurance-reader room workflow, Nexus Universe workflow, or handoff demonstration workflow. Studio workflow listings shall include access class, workflow purpose, role permissions, no-command status, no-write-back status, output review requirements, data export restrictions, AI-use restrictions, public-safe restrictions, shutdown triggers, Registry status, correction pathway, and no-deployment notice.

Studio workflow listing shall not authorize deployment, operational command, public authority decision-making, finance approval, underwriting, data export, or execution.

### 12.2.7 Learning object listings.

A **Learning Object Listing** shall describe a course, module, unit, lesson, lab, scenario, simulation, Studio exercise, work-integrated learning object, micro-credential, badge, capstone, open textbook, public-safe guide, instructor pack, MOOC, Academy pathway, Risk Academy pathway, WILP, or handoff literacy object. Learning object listings shall include audience, competency mapping, prerequisites, accessibility status, language status, credential relevance where applicable, ILA linkage where applicable, review status, support class, Registry status, correction pathway, and learning-boundary notice.

Learning object listing shall not create professional certification, degree status, license, employment eligibility, hiring decision, procurement qualification, public authority credential, deployment authorization, or execution authority.

### 12.2.8 Report listings.

A **Report Listing** shall describe a Report Object, Data Paper, Software Release Paper, Technical Note, Public-Safe Summary, Repository Package, National Portfolio Report, WFEH-B Report, DRR Report, DRF Report, DRI Report, DICE Report, GRIx Report, Observatory Report, Foundry Report, Campaign Report, Academy Report, Labs Report, Risk Agency Report, Nexus Universe Report, Grid and TRL Report, Handoff Context Note, Correction Report, or Archive Report. Report listings shall include publication class, repository location, DOI or persistent identifier where applicable, license, citation guidance, public-safe status, sensitivity class, related identifiers, Registry status, correction pathway, and publication-boundary notice.

Report listing shall not create approval, public warning, certification, financeability, procurement status, endorsement, country ranking, deployment authorization, or execution authority.

### 12.2.9 Campaign listings.

A **Campaign Listing** shall describe a Nexus Campaign object, Campaign purpose, Campaign status, public-safe message, signature tool, pledge tool, support tool where lawful, volunteer pathway, team or chapter pathway, ambassador pathway, quest or bounty link, Campaign dashboard, Campaign Report, support ledger, correction channel, Campaign DICE contribution, Campaign DRI contribution, Working Group formation record, Competence Cell formation record, or Nexus Universe routing record. Campaign listings shall include public-safe status, support controls, sponsor controls, provider controls, trust and safety controls, data-use labels, Registry status, correction pathway, and Campaign-boundary notices.

Campaign listing shall not treat signature as vote, pledge as binding finance, support as control, volunteer participation as employment, public attention as approval, community participation as consent, donor interest as commitment, or Campaign success as execution authority.

### 12.2.10 Foundry object listings.

A **Foundry Object Listing** shall describe a Foundry program, track, quest, bounty, build, maintainer role, review gate, release class, archive, correction loop, micro-production object, software build, data build, dashboard build, Studio workflow build, Marketplace object build, Registry record build, Grid input build, TRL evidence build, National Portfolio build, Report build, Campaign build, or handoff dependency build. Foundry object listings shall include scope, evidence requirements, contribution rules, reward or recognition status where applicable, labor boundary, support class, review status, Registry status, correction pathway, and Foundry-boundary notices.

Foundry object listing shall not create employment, procurement qualification, product certification, provider validation, deployment authorization, enterprise execution, or financeability.

### 12.2.11 National Portfolio listings.

A **National Portfolio Listing** shall describe a National Context Record, National Systems-Risk Map, National Challenge Brief, Evidence Need Record, Observatory Need Record, Core Build Request, Safeguard Record, Public Authority Learning Record, Readiness Question Record, Competence Cell Workplan, Universe Arena Routing Record, National Portfolio Report, or National Portfolio Archive. National Portfolio listings shall include national context, stewardship, public-safe status, sensitivity controls, national localization status, public authority boundary status, handoff relevance where applicable, Registry status, correction pathway, and no-ranking notice.

National Portfolio listing shall not create country ranking, public authority approval, national endorsement, procurement status, public finance allocation, donor allocation, financeability, deployment authorization, or execution authority.

### 12.2.12 Handoff context listings.

A **Handoff Context Listing** shall describe a handoff context note, lawful handoff dependency package, evidence context, data context, method context, Studio context, Grid context, TRL context, public-safe status, safeguard status, public authority dependency, legal dependency, finance or insurance question, procurement boundary, provider-neutrality note, sponsor-boundary note, recipient responsibility, correction pathway, or recall pathway. Handoff context listings may be public-safe, controlled, secure-room-only, handoff-recipient-only, or metadata-only.

Handoff context listing shall transfer visibility of dependencies, not authority. It shall not create implementation permission, execution authority, procurement status, financeability, insurability, public authority approval, provider selection, community consent, Indigenous consent, operational command, or deployment authorization.

## 12.3 Listing Metadata

### 12.3.1 Object title.

Each Marketplace listing shall include an object title that clearly identifies the listed object without exaggerating status, authority, endorsement, readiness, certification, procurement relevance, finance relevance, or deployment suitability. The title shall be accurate, public-safe, version-aware, and consistent with the Registry record where applicable.

Titles shall not use misleading labels such as “approved,” “certified,” “official,” “procurement-ready,” “finance-ready,” “deployment-ready,” “validated,” or “endorsed” unless such status is separately lawful, recorded, and within scope.

### 12.3.2 Object class.

Each Marketplace listing shall identify its object class, including software, data, metadata, model, AI-agent, ontology, schema, API, dashboard, digital twin, simulation, notebook, report, learning object, credential object, Campaign object, Registry object, Marketplace object, Studio workflow, Grid or TRL object, proof receipt object, National Portfolio object, Nexus Universe object, lawful handoff object, correction record, or archive record.

Object class shall determine required metadata, review gates, access rules, boundary notices, and correction pathways.

### 12.3.3 Description.

Each Marketplace listing shall include a concise and public-safe description of the object’s purpose, scope, audience, use context, source pathway, evidence basis, and limitations. The description shall be clear enough for discovery but disciplined enough to avoid overclaim.

Descriptions shall not imply certification, public authority approval, procurement recommendation, financeability, insurability, endorsement, consent, deployment authorization, or execution authority.

### 12.3.4 Version.

Each Marketplace listing shall display the listed object’s version, release date, update date, predecessor where applicable, successor where applicable, and related identifiers where available. Version metadata shall distinguish draft, active, under review, public-safe, controlled, supported, unsupported, deprecated, suspended, withdrawn, superseded, archived, and non-continuing states.

Users shall be able to identify whether they are viewing a current, historical, corrected, superseded, or withdrawn object.

### 12.3.5 Steward.

Each Marketplace listing shall identify the object steward, maintaining institution, maintainer, working group, Competence Cell, National Node, Foundry team, Academy steward, Reports steward, Registry steward, or other responsible role. Stewardship metadata shall indicate responsibility for maintaining listing accuracy, correction routing, status updates, and boundary notice integrity.

Steward identification shall not imply personal liability, public authority status, certification authority, endorsement authority, procurement authority, finance authority, or execution authority by default.

### 12.3.6 License.

Each Marketplace listing shall identify the applicable license class or rights status, including open license, controlled-open license, restricted use, metadata-only status, all-rights-reserved status, public-domain-equivalent status where applicable, data license, software license, content license, model license, API terms, or repository-specific terms. The listing shall distinguish license status from access class.

License metadata shall not override privacy obligations, data protection, protected knowledge controls, Indigenous protocols where applicable, community safeguards, cyber-sensitive restrictions, geospatial controls, public authority restrictions, contractual restrictions, or applicable law.

### 12.3.7 Access class.

Each Marketplace listing shall identify access class, including open public, controlled public, internal, restricted, data-room-only, secure-room-only, protected-knowledge-room-only, public-authority-learning-room-only, readiness-room-only, handoff-recipient-only, metadata-only, archived, or non-continuing. Access class shall determine what a user can view, request, download, reuse, cite, translate, fork, contribute to, or route.

Access class shall not create access entitlement. Requests for controlled access shall remain subject to purpose limitation, permissions, review, safeguards, jurisdictional controls, and revocation.

### 12.3.8 Support class.

Each Marketplace listing shall identify support class, including supported, unsupported, experimental, reference-only, community-maintained, institutionally maintained, secure-room-supported, handoff-recipient-supported, deprecated, withdrawn, archived, or non-continuing. Support class shall identify issue channels, security channels, documentation status, maintainer status, and response expectations where appropriate.

Support class shall not create warranty, service-level agreement, procurement status, operational support, deployment authorization, or reliance right unless separately contracted or recorded.

### 12.3.9 Review status.

Each Marketplace listing shall identify review status appropriate to object class, including unreviewed, in review, technically reviewed, data reviewed, AI-use reviewed, cyber reviewed, privacy reviewed, public-safe reviewed, safeguard reviewed, accessibility reviewed, legal-boundary reviewed, finance-boundary reviewed, procurement-boundary reviewed, handoff reviewed, corrected, suspended, withdrawn, or archived.

Review status shall not be presented as certification, approval, validation, public authority decision, procurement readiness, financeability, insurability, or deployment authorization.

### 12.3.10 Registry status.

Each Marketplace listing shall identify Registry status where the object is Registry-recorded. Registry status may include draft, active, under review, public-safe, controlled, supported, unsupported, deprecated, suspended, withdrawn, superseded, archived, or non-continuing. Marketplace status shall not conflict with Registry status; if conflict is detected, the listing shall be corrected, suspended, or flagged.

Registry status shall remain status truth, not certification truth.

### 12.3.11 Correction pathway.

Each Marketplace listing shall include a correction pathway for reporting inaccurate metadata, outdated status, broken links, unsafe language, licensing issues, data issues, AI-use issues, accessibility issues, security issues, public-safe issues, overclaims, protected knowledge concerns, or boundary incidents. Correction pathways shall identify reporting channel, responsible steward, review process, expected status update mechanism, and archive implications where appropriate.

Correction pathway visibility shall be a condition of Marketplace trust.

### 12.3.12 Boundary notices.

Each Marketplace listing shall include boundary notices appropriate to its object class, such as no-certification, no-warranty, no-procurement, no-finance, no-insurance, no-public-authority, no-warning, no-consent, no-deployment, no-execution, no-endorsement, no-validation, no-ranking, no-data-right, no-AI-safety-approval, no-professional-license, and no-employment notice. Boundary notices shall be readable, prominent, and consistent with DDPGF doctrine.

Boundary notices shall travel with listed objects when they are downloaded, cited, routed, displayed, included in reports, linked to handoff context, or used in Studio, Academy, Foundry, Campaign, Registry, Grid, TRL, or Nexus Universe environments.

## 12.4 Marketplace Governance

### 12.4.1 Listing intake.

Marketplace listing intake shall capture object identity, object class, source pathway, steward, version, access class, license class, support class, intended audience, public-safe status, sensitivity class, review status, Registry linkage, repository linkage, related identifiers, demand-signal permissions, correction pathway, and boundary notices. Listing intake may originate from Foundry, Reports, Registry, Academy, Risk Academy, Studio, Grid, DICE, GRIx, DRI, Observatory, Campaigns, Labs, National Nodes, National Working Groups, Competence Cells, Nexus Universe, or lawful handoff pathways.

Objects shall not be listed where required metadata, access classification, boundary notices, or correction pathways are missing, unless the listing is explicitly marked as provisional, metadata-only, under review, or restricted.

### 12.4.2 Metadata review.

Marketplace metadata shall be reviewed for accuracy, completeness, consistency with Registry records, consistency with repository records, object-class alignment, title discipline, description discipline, version accuracy, steward accuracy, access-class accuracy, support-class accuracy, license accuracy, and boundary notice completeness. Metadata review shall also check for overclaim, outdated status, misleading language, broken links, missing dependencies, and missing correction routes.

Metadata review shall be repeated after major updates, corrections, withdrawals, deprecations, successor releases, support-class changes, license changes, or Registry status changes.

### 12.4.3 Public-safe review.

Marketplace listings shall undergo public-safe review according to release class and sensitivity. Public-safe review shall check whether the listing exposes restricted data, protected knowledge, sensitive geospatial details, security-sensitive information, infrastructure-sensitive information, public authority-sensitive information, community-sensitive information, Indigenous protocol-sensitive information where applicable, youth-sensitive information, health-sensitive information, or unsafe technical detail.

Public-safe review shall also ensure no-warning, no-approval, no-certification, no-finance, no-procurement, no-consent, no-deployment, and no-execution language where applicable.

### 12.4.4 License review.

Marketplace listings shall undergo license review to confirm that the listing accurately describes permitted use, attribution requirements, derivative-use permissions, redistribution rights, commercial-use status, data-use limits, AI-use limits, repository terms, third-party rights, contribution rights, and restrictions. License review shall distinguish software license, data license, content license, model license, API terms, credential terms, and repository terms where applicable.

Objects with unclear rights, unresolved third-party rights, conflicting licenses, unauthorized materials, or restricted-use conflicts shall be held from open listing, listed as metadata-only, or restricted until corrected.

### 12.4.5 Support class review.

Marketplace listings shall undergo support class review to ensure that support claims are accurate, maintainers are identified where appropriate, issue channels function, security reporting is available where applicable, documentation status is clear, support limitations are stated, and unsupported or experimental objects are not presented as supported or production-ready.

Support class review shall prevent warranty overclaim, operational reliance overclaim, and implied service-level commitments.

### 12.4.6 Provider-neutrality review.

Marketplace listings shall undergo provider-neutrality review where providers, vendors, platforms, infrastructure hosts, sponsors, contributors, operators, consultants, or technology companies contribute to or are associated with listed objects. Provider-neutrality review shall ensure that listings do not imply preferred-provider status, vendor approval, supplier validation, product certification, procurement recommendation, technical superiority claim, or pay-to-routing benefit.

Provider contributions may be acknowledged only within approved language and with clear no-validation notices.

### 12.4.7 Sponsor-boundary review.

Marketplace listings shall undergo sponsor-boundary review where sponsors, donors, funders, corporate supporters, public supporters, or institutional supporters are associated with listed objects. Sponsor-boundary review shall ensure that support does not imply sponsor control, sponsor approval, sponsor ownership, sponsor endorsement, sponsor routing rights, public-good capture, preferential listing, procurement relevance, finance relevance, or influence over review outcomes.

Sponsor support may be recorded through support ledgers or approved acknowledgments, but shall not control listing status, Registry status, review status, public-safe language, or handoff relevance.

### 12.4.8 Procurement-neutrality review.

Marketplace listings shall undergo procurement-neutrality review to prevent language, ranking, filters, badges, featured placements, summaries, comparison tools, download metrics, demand signals, provider information, support status, or handoff relevance from being interpreted as procurement recommendation, supplier approval, vendor validation, tender support, product qualification, or preferred-provider status.

Where procurement-relevant audiences may view listings, notices shall state that independent diligence and competent procurement processes are required outside Marketplace listing status.

### 12.4.9 Finance-boundary review.

Marketplace listings shall undergo finance-boundary review where objects relate to finance-readiness, insurance-readiness, DRF, capital-readability, public finance relevance, donor relevance, handoff context, National Portfolio records, Grid inputs, TRL notes, or Nexus Universe readiness rooms. Finance-boundary review shall prevent language implying financeability, bankability, insurability, underwriting, investor interest, donor commitment, public finance allocation, creditworthiness, guarantee, securities offering, transaction readiness, or investment advice.

Finance-related Marketplace signals shall be presented as questions, dependencies, gaps, literacy, or no-reliance context only.

### 12.4.10 Correction and delisting.

Marketplace listings shall be correctable, suspendable, delistable, withdrawable, supersedable, and archivable. Correction or delisting may be required for inaccurate metadata, outdated versions, broken access, license errors, support misstatement, public-safe errors, protected knowledge exposure, data incidents, AI incidents, cyber issues, privacy issues, accessibility failures, provider validation overclaims, sponsor control overclaims, procurement overclaims, finance overclaims, certification overclaims, public authority overclaims, consent overclaims, deployment overclaims, or execution overclaims.

Delisting shall not erase Registry memory unless lawful deletion is required. Delisted objects shall be marked, corrected, archived, or routed to successor objects according to status truth and correction discipline.

## 12.5 Demand and Support Signals

### 12.5.1 User interest signals.

The Marketplace may collect user interest signals, including views, saves, follows, watchlist additions, inquiry forms, access requests, learning interest, reuse interest, support interest, contribution interest, translation interest, accessibility interest, and handoff-awareness interest. User interest signals shall help stewards understand demand, improve object discoverability, prioritize support, and route needs into Dockets.

User interest shall not be interpreted as procurement intent, finance commitment, endorsement, approval, community consent, public authority decision, employer demand, or execution authorization.

### 12.5.2 Download signals.

The Marketplace may collect download signals for open, public-safe, or otherwise downloadable objects. Download signals may indicate reuse interest, learning demand, technical adoption interest, public-good distribution reach, or support needs. Download data shall be handled in accordance with privacy, data minimization, analytics, consent, and public-safe reporting controls.

Download volume shall not be treated as validation, endorsement, quality rating, procurement qualification, financeability, public authority approval, or deployment readiness.

### 12.5.3 Reuse signals.

The Marketplace may collect reuse signals where users voluntarily indicate reuse, adaptation, translation, fork, integration, learning adoption, repository citation, course adoption, Studio use, Foundry use, Campaign use, National Portfolio use, or public-safe publication use. Reuse signals may inform Registry updates, support ledgers, Dockets, reports, and correction needs.

Reuse signal collection shall not override license conditions, data-use restrictions, AI-use restrictions, access controls, attribution duties, community safeguards, Indigenous protocols, protected knowledge controls, or public-safe limits.

### 12.5.4 Support requests.

The Marketplace may route support requests to stewards, maintainers, support teams, community maintainers, National Nodes, Academy teams, Foundry teams, Reports teams, Registry stewards, Studio stewards, data stewards, AI stewards, security contacts, or handoff-context stewards. Support requests may include questions, documentation needs, installation issues, data access questions, interpretation needs, accessibility needs, translation needs, bug reports, security reports, or handoff-context inquiries.

Support requests shall not create support entitlement, service-level obligation, consulting engagement, warranty, procurement relationship, employment relationship, or execution obligation unless separately agreed and recorded.

### 12.5.5 Translation requests.

The Marketplace may collect translation requests for learning objects, reports, guides, software documentation, metadata, public-safe summaries, National Portfolio materials, Campaign materials, Studio exercises, and handoff literacy objects. Translation requests may inform localization Dockets, Academy priorities, National Node workplans, Competence Cell workplans, and support-ledger priorities.

Translation requests shall not create immediate obligation, public authority adoption, legal equivalence, credential equivalence, national endorsement, or community consent. Translation shall require review, localization, public-safe checks, and correction pathways.

### 12.5.6 Accessibility requests.

The Marketplace may collect accessibility requests, including requests for captions, transcripts, alt text, screen-reader compatibility, keyboard navigation, mobile-friendly formats, low-bandwidth formats, plain-language versions, sign-language versions where appropriate, translated versions, cognitive accessibility improvements, accessible data visualizations, and alternative file formats. Accessibility requests shall inform correction, support, product improvement, Academy improvement, Reports improvement, and public-good inclusion priorities.

Accessibility request handling shall avoid collecting unnecessary sensitive personal data and shall protect user privacy.

### 12.5.7 Bug reports.

The Marketplace may route bug reports for software, data, models, APIs, dashboards, Studio workflows, learning objects, reports, metadata, links, Registry references, access controls, documentation, translation, accessibility, or boundary notices. Bug reports shall be classified by severity, object class, sensitivity, security relevance, public-safe relevance, data relevance, AI relevance, privacy relevance, and correction urgency.

Bug reports shall not be ignored where they implicate security, privacy, protected knowledge, public authority overclaim, finance overclaim, procurement overclaim, certification overclaim, consent overclaim, deployment overclaim, or execution overclaim.

### 12.5.8 Feature requests.

The Marketplace may collect feature requests for software, dashboards, APIs, data products, models, Studio workflows, learning objects, Reports, Registry views, Marketplace functions, accessibility features, translation features, support features, and handoff-context features. Feature requests may become Docket items, Foundry quests, bounties, builds, Academy updates, Studio updates, Reports updates, or National Portfolio needs.

Feature requests shall be treated as demand signals, not commitments. Acceptance, prioritization, development, release, support, or handoff shall require separate review and records.

### 12.5.9 National demand signals.

The Marketplace may collect national demand signals from National Nodes, National Nexus Consortiums, National Councils, Helix Councils, National Working Groups, Competence Cells, public authority learning participants, universities, employers, communities, Campaigns, Academy participants, and Nexus Universe outputs. National demand signals may identify needed translations, localized data, national dashboards, national learning pathways, National Portfolio objects, WFEH-B needs, DRI needs, Observatory needs, Studio workflows, Foundry builds, reports, or handoff context.

National demand signals shall be routed in a manner that preserves national ownership, public authority boundaries, community safeguards, Indigenous protocols where applicable, public-safe controls, and no-execution discipline.

### 12.5.10 Handoff interest signals.

The Marketplace may collect handoff interest signals from National Consortium Companies, Project SPVs, public authorities, providers, operators, contractors, universities, labs, donors, insurers, capital readers, communities where appropriate, and other competent lawful actors. Handoff interest signals may indicate that an object may require a handoff context review, dependency package, secure-room access, readiness discussion, public authority dependency review, finance-readiness question, insurance-readiness question, procurement boundary review, or recipient responsibility note.

Handoff interest shall not be interpreted as transaction interest, investment interest, underwriting interest, procurement intent, public authority approval, implementation authorization, community consent, Indigenous consent, provider selection, or execution authority.

## 12.6 Marketplace Boundary Rules

### 12.6.1 Listing is not procurement.

A Marketplace listing shall not constitute procurement recommendation, preferred supplier status, supplier approval, vendor validation, tender support, product qualification, purchasing instruction, public authority procurement decision, or procurement framework status. Any procurement process shall occur outside the Marketplace through competent lawful procedures, independent diligence, applicable law, and recorded authority.

### 12.6.2 Discovery is not endorsement.

Discovery through the Marketplace shall not imply endorsement by GCRI, The Global Risks Forum (GRF), The Global Risks Alliance (GRA), any Nexus institution, public authority, standards body, funder, donor, insurer, capital reader, sponsor, provider, university, community, Indigenous institution, National Consortium Company, Project SPV, or downstream actor. Discovery means that an object is findable within recorded scope, not approved.

### 12.6.3 Featured placement is not validation.

Featured placement, recommended display, search prominence, category highlighting, editorial grouping, pathway inclusion, Campaign visibility, Academy visibility, Nexus Universe visibility, or National Portfolio visibility shall not constitute validation, certification, endorsement, procurement preference, financeability, insurability, public authority approval, provider superiority, or deployment readiness. Featured placement shall be governed by public-good criteria, transparency, conflicts controls, sponsor controls, provider-neutrality controls, and correctionability.

### 12.6.4 Download is not approval.

Downloading, viewing, saving, forking, citing, reusing, translating, adapting, or linking a Marketplace object shall not constitute approval, endorsement, license expansion, unrestricted use permission, data right, deployment authorization, public authority action, procurement status, financeability, insurability, warranty, or execution authority. Users remain responsible for complying with license terms, access restrictions, data-use labels, AI-use labels, public-safe limits, and applicable law.

### 12.6.5 Support interest is not finance commitment.

Support interest, sponsor interest, donor interest, capital-reader interest, insurer interest, public finance reader interest, user interest, reuse interest, or handoff interest recorded through the Marketplace shall not constitute finance commitment, donor commitment, investment interest, underwriting interest, insurance approval, guarantee, grant allocation, public finance allocation, securities interest, transaction readiness, or financial advice. Such signals shall remain non-reliance, non-soliciting, non-transactional, and correctionable.

### 12.6.6 Handoff relevance is not implementation authority.

A Marketplace object identified as handoff-relevant shall not be treated as implementation-ready, deployment-ready, procurement-ready, finance-ready, insurance-ready, public-authority-approved, provider-selected, community-approved, Indigenous-approved, operationally authorized, or executable. Handoff relevance means only that the object may require or support a separate lawful handoff pathway with evidence context, dependency records, recipient responsibility, public authority dependencies, safeguard dependencies, finance and insurance questions, procurement boundaries, correction pathways, and recall mechanisms.


---

# 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/operations/frameworks/distributed-digital-public-goods-framework-ddpgf/xii.-marketplace.md?ask=<question>
```

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.