> For the complete documentation index, see [llms.txt](https://docs.therisk.global/organization/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.therisk.global/organization/cooperation/nexus-universe/framework/xli.-incentives.md).

# XLI. INCENTIVES

## Summary

This section defines the Nexus incentives framework. It explains how incentives support public-good work, widen access, improve evidence, and continue high-value outputs without becoming external authority.

It covers:

* Prize pools, continuation grants, compute and infrastructure credits, fellowships, bounties, and maintenance awards.
* Low-resource support, national continuation, evidence improvement, correction excellence, and sponsor-funded incentives without control.
* Boundary rules, overclaim correction, incentive records, and archive requirements across the full incentive lifecycle.

## 41.1 Incentive Architecture

### 41.1.1 Incentive Architecture Function

41.1.1.1 **Incentive Architecture** means the structured system through which Nexus Universe may recognize, support, reward, subsidize, continue, maintain, and improve public-good technical work, evidence-bearing stacks, BuildGrid contributions, Foundry Programs, open-source assets, low-resource participation, Academy pathways, correction excellence, National Portfolio continuation, and lawful handoff preparation without converting incentives into procurement, finance, certification, investment, insurance, deployment approval, or execution authority.

41.1.1.2 Incentives exist to align participant effort with Nexus public-good purposes. They may encourage evidence quality, technical rigor, interoperability, public-good software, reusable data objects, model documentation, benchmark improvement, telemetry completeness, correction response, accessibility, low-resource inclusion, national capability formation, open-source maintenance, Academy learning, and continuation readiness.

41.1.1.3 Incentives must never become hidden purchasing, sponsor control, provider preference, capital signaling, public authority approval, procurement advantage, employment promise, financeability claim, insurance approval, deployment authorization, or market endorsement. The incentive system supports work; it does not acquire authority over external decisions.

### 41.1.2 Incentive Classes

41.1.2.1 Nexus incentives may include technical prize pools, public-good continuation grants, compute credits, cloud and infrastructure credits, Academy fellowships, BuildGrid bounties, Foundry continuation awards, open-source maintenance awards, low-resource participation support, national continuation credits, evidence improvement grants, correction excellence awards, sponsor-funded incentives without control, and other recorded public-good support mechanisms.

41.1.2.2 Incentives may be monetary, in-kind, compute-based, cloud-based, infrastructure-based, mentorship-based, training-based, recognition-based, access-based, travel-support-based, translation-support-based, accessibility-support-based, continuation-support-based, or maintenance-support-based.

41.1.2.3 Incentive classes must identify eligibility, purpose, funding source, sponsor or provider involvement, selection criteria, scoring relationship, review process, restrictions, permitted use, prohibited use, public claims limits, correction pathway, and archive treatment.

### 41.1.3 Incentive Integrity Principles

41.1.3.1 Incentives must be public-good aligned, transparent where public-safe, conflict-managed, sponsor-controlled only within support-without-control rules, provider-neutral, competition-safe, non-procurement, non-finance, non-certification, non-deployment, and correctionable.

41.1.3.2 Incentives must not reward overclaim, benchmark gaming, hidden substitution, sponsor-assisted concealed advantage, proprietary lock-in, data extraction, public authority confusion, capital-readiness overclaim, insurance-readiness overclaim, community consent overclaim, or premature handoff.

41.1.3.3 Incentives should reward evidence, integrity, usefulness, accessibility, maintainability, public-good reuse, correction response, safety, data stewardship, cyber discipline, AI governance, public-safe reporting, and lawful continuation clarity.

### 41.1.4 Incentive Boundary

41.1.4.1 Incentive receipt does not create certification, procurement status, financeability, bankability, insurance approval, public authority approval, community consent, deployment authorization, employment status, professional qualification, or execution authority.

41.1.4.2 Incentives support participation and continuation only within the recorded incentive purpose.

## 41.2 Technical Prize Pools

### 41.2.1 Technical Prize Pool Function

41.2.1.1 **Technical Prize Pools** are structured incentive pools used to recognize strong performance, evidence quality, interoperability, resilience, efficiency, safety, public-good contribution, accessibility, low-resource excellence, correction response, or other defined outcomes in Nexus Universe challenges, mission cycles, benchmark cycles, BuildGrid work, Foundry Programs, and Nexus Core validation.

41.2.1.2 Technical prize pools may help concentrate effort around hard problems, including AI safety, cyber recovery, edge resilience, sovereign compute, digital twins, WEFH-B systems, public authority learning, low-resource capability, open-source tooling, public-safe reporting, and interoperability.

41.2.1.3 Prize pools must remain subordinate to the validation record. A prize recognizes a defined result or contribution under recorded conditions; it does not convert that result into certification, procurement preference, financeability, insurance approval, deployment approval, or public authority endorsement.

### 41.2.2 Prize Pool Requirements

41.2.2.1 Technical Prize Pool rules should identify prize purpose, eligible classes, eligible participants, evaluation criteria, scoring relationship, evidence requirements, integrity requirements, disqualification grounds, sponsor involvement, provider involvement, conflict controls, public claims language, payment or award conditions, tax or reporting conditions where applicable, and correction pathway.

41.2.2.2 Prize criteria must be published or recorded before the relevant challenge or cycle where feasible, and any changes must be recorded, justified, and communicated in a public-safe manner.

41.2.2.3 Prize pools must not be structured to prefer a sponsor’s technology, provider’s platform, national actor, insider, capital-backed participant, or preselected team unless the class expressly permits a bounded sponsored challenge and the conflict is fully recorded and managed.

### 41.2.3 Prize Pool Records

41.2.3.1 Technical Prize Pool Records should identify prize pool, funding source, sponsor or provider role, rules, eligible participants, evaluation method, awardees, evidence basis, conflicts, public-safe status, correction status, withdrawal status, and archive reference.

41.2.3.2 If an award is later affected by score invalidation, recognition withdrawal, integrity findings, rights disputes, data breaches, benchmark leakage, or public-safe correction, the prize record must be corrected and may be limited, suspended, withdrawn, replaced, or archived with corrected status.

### 41.2.4 Prize Pool Boundary

41.2.4.1 Technical Prize Pool awards are not procurement awards, investment decisions, grants of execution authority, certifications, public authority approvals, insurance approvals, or deployment authorizations.

41.2.4.2 A prize rewards recorded performance or contribution only.

## 41.3 Public-Good Continuation Grants

### 41.3.1 Continuation Grant Function

41.3.1.1 **Public-Good Continuation Grants** are incentive supports used to continue public-good work after a Nexus Universe cycle, Nexus Foundry review, BuildGrid contribution, Nexus Core validation, Grid input, Rails route, National Portfolio update, public-safe report, or correction record identifies a public-good need that should continue without becoming enterprise execution.

41.3.1.2 Continuation grants may support additional evidence work, public-good software maintenance, documentation, benchmark improvement, data stewardship, model documentation, public-safe reporting, Academy module development, accessibility improvement, translation, low-resource support, Competence Cell continuation, National Portfolio support, or correction work.

41.3.1.3 Public-Good Continuation Grants exist to prevent useful work from dying after public visibility ends. They are not project finance, venture funding, procurement, public finance allocation, investment, underwriting, or execution funding.

### 41.3.2 Grant Requirements

41.3.2.1 Public-Good Continuation Grant rules should identify grant purpose, eligible outputs, eligible recipients, allowable uses, prohibited uses, evidence basis, public-good release expectations, reporting obligations, IP and licensing conditions, data rights conditions, sponsor or provider involvement, conflict controls, correction obligations, and archive obligations.

41.3.2.2 Grant eligibility should depend on public-good relevance, evidence need, maintainability, correction need, reuse value, accessibility, National Portfolio relevance, safeguard status, and lawful continuation clarity.

41.3.2.3 Continuation grant funds or in-kind support must not be used for procurement lobbying, investment solicitation, commercial sales, political activity, unauthorized public authority activity, community consent substitution, deployment without authority, or enterprise execution unless a separate lawful instrument outside the public-good grant permits and governs such activity.

### 41.3.3 Grant Records

41.3.3.1 Public-Good Continuation Grant Records should identify grant, recipient, source output, purpose, funding source, permitted uses, prohibited uses, reporting requirements, deliverables, public-safe status, IP conditions, data conditions, correction status, completion status, and archive reference.

41.3.3.2 Grant records should distinguish public-good continuation from enterprise-stack continuation, National Consortium Company activity, Project SPV activity, procurement, finance, or deployment.

### 41.3.4 Grant Boundary

41.3.4.1 Public-Good Continuation Grants do not create procurement status, financeability, bankability, investment status, insurance approval, public authority approval, community consent, deployment authorization, or execution authority.

41.3.4.2 They support continued public-good work only.

## 41.4 Compute Credits

### 41.4.1 Compute Credit Function

41.4.1.1 **Compute Credits** are in-kind incentives or support allocations that provide access to compute resources for Nexus Foundry preparation, BuildGrid work, Nexus Core validation, AI workloads, simulation, digital twins, public-good software, public-safe reporting, Academy exercises, low-resource participation, evidence improvement, and continuation work.

41.4.1.2 Compute credits may include high-performance computing time, GPU access, accelerator access, sovereign compute access, cloud compute credits, edge compute access, confidential computing environments, compute-to-data environments, sandbox environments, or test environments.

41.4.1.3 Compute credits must be disclosed, allocated fairly, recorded, metered where applicable, and prevented from becoming hidden advantage, sponsor capture, provider validation, cost misstatement, energy misstatement, or procurement signal.

### 41.4.2 Compute Credit Requirements

41.4.2.1 Compute Credit rules should identify provider, sponsor if any, resource type, eligible users, allocation criteria, permitted workloads, prohibited workloads, security controls, data controls, AI controls, telemetry requirements, energy reporting where applicable, cost-equivalent disclosure where applicable, and correction obligations.

41.4.2.2 Compute credits used in scored or recognized contexts must be reflected in resource-class records, cost-capped records, energy-capped records, Open Class records, low-resource support records, or other relevant evidence records.

41.4.2.3 Compute credits must not grant provider access to participant data, restricted telemetry, model outputs, public authority-sensitive information, protected knowledge, capital-reader materials, insurance-reader materials, or handoff materials unless separately authorized and recorded.

### 41.4.3 Compute Credit Records

41.4.3.1 Compute Credit Records should identify resource provider, sponsor if any, recipient, resource class, allocation amount, usage period, permitted use, prohibited use, telemetry, energy records where applicable, data controls, security controls, scoring effect, correction status, and archive reference.

41.4.3.2 Undisclosed compute credit use may trigger score correction, resource-class correction, recognition correction, Grid correction, Rails correction, handoff correction, or integrity review.

### 41.4.4 Compute Credit Boundary

41.4.4.1 Compute Credits do not certify a provider, validate a platform, create procurement status, create financeability, create insurance approval, create public authority approval, or authorize deployment.

41.4.4.2 They provide recorded compute support only.

## 41.5 Cloud and Infrastructure Credits

### 41.5.1 Cloud and Infrastructure Credit Function

41.5.1.1 **Cloud and Infrastructure Credits** are in-kind supports that provide access to cloud platforms, network services, storage, development environments, security tooling, data rooms, monitoring systems, API infrastructure, collaboration tools, testbeds, edge nodes, private wireless environments, AI-RAN or O-RAN test environments, public dashboard infrastructure, or other technical infrastructure for Nexus work.

41.5.1.2 These credits may enable low-resource teams, universities, public-good builds, National Teams, Competence Cells, Foundry Programs, BuildGrid work, public-safe reporting, open-source maintenance, and Nexus Core validation.

41.5.1.3 Infrastructure support must not become infrastructure capture. The provider of infrastructure must not control the rules, benchmark conditions, telemetry interpretation, scoring, recognition, Grid maturity, Rails routing, public-safe reporting, handoff, or public claims.

### 41.5.2 Credit Requirements

41.5.2.1 Cloud and Infrastructure Credit rules should identify infrastructure type, provider, sponsor if any, recipient, eligible uses, prohibited uses, access controls, data processing conditions, service limitations, logging, telemetry, security controls, availability assumptions, cost-equivalent disclosure, public claims restrictions, and correction obligations.

41.5.2.2 Infrastructure credits used during validation must be recorded in Stack Passports, resource-class records, evidence packs, telemetry records, cost records, energy records where applicable, and provider contribution records.

41.5.2.3 Infrastructure credits must not create undisclosed preferential access or hidden performance advantage.

### 41.5.3 Credit Records

41.5.3.1 Cloud and Infrastructure Credit Records should identify provider, sponsor if any, recipient, service, allocation, duration, permitted use, prohibited use, data access status, security status, telemetry status, scoring relevance, correction status, and archive reference.

41.5.3.2 If a credit affects benchmark conditions, cost-to-performance, energy records, public dashboard availability, public-safe reporting, or handoff evidence, all affected records must identify the credit.

### 41.5.4 Credit Boundary

41.5.4.1 Cloud and Infrastructure Credits do not create provider validation, procurement status, certification, financeability, insurance approval, public authority approval, deployment authorization, or execution authority.

41.5.4.2 They provide recorded infrastructure support only.

## 41.6 Academy Fellowships

### 41.6.1 Academy Fellowship Function

41.6.1.1 **Academy Fellowships** are learning and contribution incentives that support individuals or cohorts participating in Nexus Academy, Risk Academy, BuildGrid, Competence Cell apprenticeships, Foundry Fellowships, public-good software work, public-safe reporting, National Portfolio learning, low-resource pathways, youth pathways, university pathways, and applied competence programs.

41.6.1.2 Academy Fellowships may provide stipends, travel support, mentorship, compute access, learning access, project support, translation support, accessibility support, or structured time to contribute to public-good Nexus work.

41.6.1.3 Fellowship support must be clearly separated from employment, professional licensure, immigration status, wage entitlement, public authority status, procurement qualification, or execution role.

### 41.6.2 Fellowship Requirements

41.6.2.1 Academy Fellowship rules should identify eligibility, learning purpose, contribution purpose, duration, support provided, duties, supervision, permitted work, prohibited work, access class, data restrictions, youth or vulnerable participant safeguards where applicable, IP and contribution rights, public recognition rules, correction pathway, and archive treatment.

41.6.2.2 Fellows must receive role records, supervision, learning objectives, contributor rights information, privacy protections, and public claims limits.

41.6.2.3 Fellowship-funded work involving AI, cyber, public authority-sensitive information, protected knowledge, personal data, capital-reader materials, insurance-reader materials, or handoff materials requires heightened access controls and review.

### 41.6.3 Fellowship Records

41.6.3.1 Academy Fellowship Records should identify fellow or cohort subject to privacy controls, fellowship purpose, support provided, learning objectives, contribution outputs, mentor, access class, credential relationship if any, public display status, correction status, completion status, and archive reference.

41.6.3.2 Fellowship completion may support Talent Records, Integrated Learning Accounts, micro-credentials, contribution recognition, or Academy progression only within recorded boundaries.

### 41.6.4 Fellowship Boundary

41.6.4.1 Academy Fellowship receipt does not create employment, wage entitlement, professional licensure, academic credit, immigration status, procurement qualification, public authority status, financeability, insurance approval, deployment authorization, or execution authority.

41.6.4.2 It supports learning and contribution only.

## 41.7 BuildGrid Bounties

### 41.7.1 Bounty Function

41.7.1.1 **BuildGrid Bounties** are defined incentive-backed work objects that reward completion, improvement, maintenance, correction, review, documentation, testing, or public-good release of BuildGrid tasks, Quests, Builds, software components, data components, model documentation, benchmark tools, dashboard components, Academy materials, accessibility improvements, translations, public-safe report components, Evidence Pack components, Grid components, Rails components, and handoff package components.

41.7.1.2 Bounties convert public-good needs into bounded tasks with defined outputs, review criteria, contributor rights, evidence requirements, and correction pathways.

41.7.1.3 Bounties must not become hidden contracting, disguised employment, procurement qualification, sponsor-controlled tasking, provider-directed labor, or execution work by implication.

### 41.7.2 Bounty Requirements

41.7.2.1 BuildGrid Bounty rules should identify bounty purpose, source Docket or Program, eligible contributors, output requirements, review criteria, reward type, funding source, sponsor or provider involvement, rights terms, license terms, data restrictions, AI-use disclosure, security requirements, public-safe requirements, acceptance process, rejection process, correction pathway, and archive reference.

41.7.2.2 Bounties must distinguish learning bounties, contribution bounties, maintenance bounties, correction bounties, evidence bounties, technical bounties, documentation bounties, and controlled-access bounties.

41.7.2.3 Bounty completion must be reviewed before reward, recognition, public release, Grid input, Rails route, or handoff use.

### 41.7.3 Bounty Records

41.7.3.1 BuildGrid Bounty Records should identify bounty, funding source, sponsor or provider role, contributor, submission, review status, accepted output, rejected output, reward status, rights status, release status, correction status, and archive reference.

41.7.3.2 Bounty records must be correctable where contribution integrity, rights, security, data, AI-use, authorship, benchmark integrity, or public-safe status changes.

### 41.7.4 Bounty Boundary

41.7.4.1 BuildGrid Bounty completion does not create employment, contracting status beyond the recorded bounty terms, procurement qualification, professional status, certification, public authority approval, financeability, insurance approval, deployment authorization, or execution authority.

41.7.4.2 It rewards reviewed contribution only.

## 41.8 Foundry Continuation Awards

### 41.8.1 Continuation Award Function

41.8.1.1 **Foundry Continuation Awards** are incentives granted to Foundry Programs, Tracks, teams, Competence Cells, maintainers, public-good build groups, Academy contributors, National Portfolio contributors, or BuildGrid contributors where a Nexus Universe cycle identifies work that should continue through public-good preparation, additional evidence, technical improvement, data stewardship, safety review, public-safe reporting, open-source maintenance, Grid refinement, Rails clarification, or lawful handoff dependency mapping.

41.8.1.2 Foundry Continuation Awards encourage disciplined continuation rather than post-event abandonment. They support the transition from validation result to improved public-good work.

41.8.1.3 These awards are not project awards, procurement awards, investment awards, public finance allocations, or Project SPV funding by implication.

### 41.8.2 Award Requirements

41.8.2.1 Foundry Continuation Award rules should identify eligible Foundry outputs, continuation purpose, evidence basis, required work, allowed costs or supports, prohibited uses, sponsor or provider involvement, conflict controls, reporting requirements, public-safe outputs, Grid relationship, Rails relationship, handoff limits, correction obligations, and archive treatment.

41.8.2.2 Awards should prioritize unresolved high-value public-good questions, evidence gaps, safety gaps, interoperability gaps, documentation gaps, public-safe reporting needs, accessibility needs, correction needs, and National Portfolio relevance.

41.8.2.3 Awards must not be used to bypass review gates, accelerate unready outputs into public claims, or create execution pressure.

### 41.8.3 Award Records

41.8.3.1 Foundry Continuation Award Records should identify award, recipient, source Foundry Program, evidence basis, continuation plan, support provided, deliverables, restrictions, reporting status, correction status, completion status, and archive reference.

41.8.3.2 Award completion should feed updated Dockets, BuildGrid tasks, Evidence Packs, public-good releases, Academy materials, Grid inputs, Rails notes, public-safe reports, or archive records as appropriate.

### 41.8.4 Award Boundary

41.8.4.1 Foundry Continuation Awards do not create procurement status, financeability, insurance approval, public authority approval, certification, deployment authorization, Project SPV approval, National Company approval, or execution authority.

41.8.4.2 They support further public-good preparation only.

## 41.9 Open-Source Maintenance Awards

### 41.9.1 Maintenance Award Function

41.9.1.1 **Open-Source Maintenance Awards** are incentives used to support maintenance, security, documentation, testing, dependency management, accessibility, localization, issue triage, contributor support, release governance, long-term support, correction, and archive of Nexus public-good software, open technical baselines, reference implementations, APIs, schemas, dashboards, benchmark tools, learning objects, and related digital public goods.

41.9.1.2 Maintenance awards recognize that public-good software fails when creation is rewarded but maintenance is ignored. Nexus must support the ongoing work required to keep public-good assets secure, usable, documented, accessible, and correctionable.

41.9.1.3 Maintenance awards are public-good stewardship supports, not commercial software procurement, vendor retention, service contracts by implication, or deployment support by default.

### 41.9.2 Maintenance Award Requirements

41.9.2.1 Open-Source Maintenance Award rules should identify asset, maintainer, eligible maintenance work, security obligations, documentation obligations, release obligations, issue governance, dependency obligations, license obligations, contributor governance, public-safe obligations, accessibility obligations, correction obligations, and archive obligations.

41.9.2.2 Awards may support vulnerability remediation, dependency updates, test expansion, documentation, translation, accessibility, public dashboard stability, benchmark tool maintenance, release notes, deprecation notices, and long-term support planning.

41.9.2.3 Maintenance awards must not create private control over public-good assets, sponsor control, provider lock-in, or hidden dependency.

### 41.9.3 Maintenance Award Records

41.9.3.1 Open-Source Maintenance Award Records should identify asset, recipient, support provided, maintenance scope, funding source, sponsor or provider involvement, release status, security status, correction status, public-safe status, completion status, and archive reference.

41.9.3.2 Maintenance awards should link to repository records, release records, vulnerability records, correction records, deprecation records, and archive records.

### 41.9.4 Maintenance Award Boundary

41.9.4.1 Open-Source Maintenance Awards do not create warranty, service-level guarantee, procurement status, certification, financeability, insurance approval, public authority approval, deployment authorization, or execution authority.

41.9.4.2 They support public-good maintenance only.

## 41.10 Low-Resource Participation Support

### 41.10.1 Low-Resource Support Function

41.10.1.1 **Low-Resource Participation Support** is the incentive and support mechanism through which Nexus Universe may reduce barriers for participants with limited funding, compute, equipment, travel ability, bandwidth, language access, accessibility support, institutional sponsorship, expert mentorship, or local infrastructure.

41.10.1.2 Low-resource support exists so that Nexus Universe does not become a validation environment only for large providers, wealthy institutions, sponsor-backed teams, or high-infrastructure countries. It strengthens the legitimacy and usefulness of Nexus by expanding who can learn, build, validate, contribute, and continue.

41.10.1.3 Low-resource support must be transparent, criteria-based, dignity-preserving, privacy-protective, and integrity-preserving. It creates access; it does not reduce truth standards.

### 41.10.2 Support Categories

41.10.2.1 Low-resource support may include travel support, accommodation support, compute credits, cloud credits, shared development environments, loaned equipment, low-bandwidth packages, offline packages, mentorship, translation, accessibility support, fee waivers where applicable, documentation support, Stack Passport support, Academy access, BuildGrid onboarding, and public-good starter kits.

41.10.2.2 Allocation should consider need, public-good purpose, resource class, geographic inclusion, youth and university pathways, community-grounded participation, national capability formation, accessibility needs, and technical readiness.

41.10.2.3 Support must not create unrecorded sponsor advantage, provider advantage, hidden compute advantage, data access advantage, review advantage, scoring advantage, or recognition advantage.

### 41.10.3 Support Records

41.10.3.1 Low-Resource Participation Support Records should identify recipient subject to privacy controls, support type, allocation basis, sponsor or provider source if any, permitted use, restrictions, public-safe status, scoring effect if any, correction status, and archive reference.

41.10.3.2 Public reporting of low-resource support should use dignity-preserving, aggregated, or consented formats and must not stigmatize participants.

### 41.10.4 Support Boundary

41.10.4.1 Low-resource participation support does not create employment, procurement status, financeability, insurance approval, public authority approval, certification, deployment authorization, or execution authority.

41.10.4.2 It supports equitable participation only.

## 41.11 National Continuation Credits

### 41.11.1 National Continuation Credit Function

41.11.1.1 **National Continuation Credits** are incentive supports allocated to help country-linked teams, National Nexus Consortiums, National Working Groups, National Portfolios, national Competence Cells, universities, public-good builders, public authority learning teams, youth teams, and low-resource national participants continue public-good work after Nexus Universe.

41.11.1.2 National Continuation Credits may support National Portfolio updates, public-safe reports, Academy learning, BuildGrid continuation, Competence Cell formation, public-good software localization, translation, public authority learning follow-up, community safeguard follow-up, evidence improvement, Grid input refinement, Rails route clarification, and lawful handoff dependency mapping.

41.11.1.3 National Continuation Credits support national capability memory and continuation. They do not create sovereign endorsement, public authority approval, public finance allocation, procurement status, Project SPV approval, or National Consortium Company approval.

### 41.11.2 Credit Requirements

41.11.2.1 National Continuation Credit rules should identify eligible countries or national pathways, eligible recipients, eligible uses, prohibited uses, National Portfolio relationship, public authority boundary, sponsor or provider involvement, conflict controls, reporting requirements, public-safe output requirements, correction obligations, and archive treatment.

41.11.2.2 Credits should be aligned with national ownership, public-good purpose, National Portfolio relevance, safeguard status, data sovereignty, accessibility, low-resource support, and lawful continuation clarity.

41.11.2.3 Credits must not be used to imply national adoption, public authority approval, procurement preference, public finance allocation, community consent, deployment authorization, or execution.

### 41.11.3 Credit Records

41.11.3.1 National Continuation Credit Records should identify country attribution, recipient, support provided, source output, National Portfolio relationship, permitted uses, prohibited uses, public-safe status, sponsor or provider involvement, correction status, completion status, and archive reference.

41.11.3.2 National Continuation Credit Records should distinguish national learning, national capability formation, National Portfolio continuation, National Company review, Project SPV review, public authority review, and external execution.

### 41.11.4 Credit Boundary

41.11.4.1 National Continuation Credits do not create sovereign endorsement, public authority approval, procurement status, public finance allocation, financeability, insurance approval, community consent, deployment authorization, or execution authority.

41.11.4.2 They support country-level public-good continuation only.

## 41.12 Evidence Improvement Grants

### 41.12.1 Evidence Improvement Grant Function

41.12.1.1 **Evidence Improvement Grants** are incentives used to improve the quality, completeness, reproducibility, auditability, public-safe status, accessibility, documentation, telemetry, benchmark support, model documentation, dataset documentation, safety case, cyber case, data case, AI safety case, and correction status of Nexus evidence.

41.12.1.2 Evidence Improvement Grants recognize that weak evidence can make promising work unusable. They support the hard work of turning claims, prototypes, demonstrations, and partial records into reviewable, bounded, correctionable, public-good evidence.

41.12.1.3 These grants do not reward marketing, publicity, overclaim, or premature continuation. They reward better records.

### 41.12.2 Grant Requirements

41.12.2.1 Evidence Improvement Grant rules should identify target evidence, evidence gap, required improvement, eligible recipients, allowed uses, prohibited uses, reviewer role, public-safe review, data rights review, IP review, safety review, cyber review, AI review, accessibility review, correction pathway, and archive treatment.

41.12.2.2 Grants may support telemetry improvements, benchmark card completion, model card completion, system card completion, dataset documentation, provenance reconstruction, reproducibility work, uncertainty documentation, public-safe summary preparation, safety case improvement, cyber case improvement, data case improvement, and correction of prior records.

41.12.2.3 Evidence improvement must not be used to conceal failure, rewrite history, inflate maturity, or replace correction with narrative.

### 41.12.3 Grant Records

41.12.3.1 Evidence Improvement Grant Records should identify evidence object, gap, recipient, support provided, improvement plan, deliverables, review status, public-safe status, correction status, affected Grid inputs, affected Rails routes, affected handoff packages, and archive reference.

41.12.3.2 Completed evidence improvements must update source records, public-safe summaries, recognition records, Grid inputs, Rails routes, handoff packages, and archives where applicable.

### 41.12.4 Grant Boundary

41.12.4.1 Evidence Improvement Grants do not create recognition, maturity, certification, procurement status, financeability, insurance approval, public authority approval, deployment authorization, or execution authority.

41.12.4.2 They support better evidence only.

## 41.13 Correction Excellence Awards

### 41.13.1 Correction Excellence Function

41.13.1.1 **Correction Excellence Awards** are incentives recognizing participants, teams, maintainers, Competence Cells, Foundry Programs, BuildGrid contributors, Host Hubs, public-good software maintainers, public-safe reporting teams, or other actors that demonstrate exceptional correctionability, transparency, incident response, record repair, public-safe notice practice, recurrence prevention, and learning from failure.

41.13.1.2 Correction Excellence Awards exist because Nexus credibility depends not on pretending that systems never fail, but on recording failure, correcting errors, protecting affected parties, updating records, and preventing recurrence.

41.13.1.3 Correction excellence is a public-good virtue. It should be recognized without converting correction into immunity, liability waiver, certification, procurement status, or approval.

### 41.13.2 Award Requirements

41.13.2.1 Correction Excellence Award rules should identify eligible correction events, criteria, evidence required, public-safe disclosure limits, privacy protections, affected-party considerations, reviewer independence, sponsor or provider conflicts, and archive treatment.

41.13.2.2 Criteria may include timeliness, completeness, transparency, public-safe notice quality, affected-record propagation, recurrence prevention, rights protection, protected knowledge protection, public authority boundary correction, sponsor or provider overclaim correction, and learning integration.

41.13.2.3 Correction awards must not reward avoidable negligence, repeated misconduct, concealment followed by correction, or correction used as public relations cover.

### 41.13.3 Award Records

41.13.3.1 Correction Excellence Award Records should identify awardee, correction event or practice, evidence basis, public-safe summary, reviewer status, limitations, affected records, correction status, and archive reference.

41.13.3.2 Award records must not disclose restricted incident details, personal data, protected knowledge, cyber-sensitive details, public authority-sensitive information, legal-hold materials, capital-reader materials, insurance-reader materials, or handoff-only materials.

### 41.13.4 Award Boundary

41.13.4.1 Correction Excellence Awards do not erase the underlying incident, waive liability, remove corrective obligations, certify the participant, create procurement status, create financeability, create insurance approval, create public authority approval, or authorize deployment.

41.13.4.2 They recognize exemplary correction practice only.

## 41.14 Sponsor-Funded Incentives Without Control

### 41.14.1 Sponsor-Funded Incentive Function

41.14.1.1 **Sponsor-Funded Incentives Without Control** are incentives funded, supported, endowed, contributed, subsidized, or enabled by sponsors while preserving Nexus authority over rules, eligibility, scoring, review, recognition, public-safe reporting, Grid inputs, Rails routes, handoff, public claims, and correction.

41.14.1.2 Sponsor-funded incentives may support prize pools, low-resource participation, compute credits, cloud credits, Academy fellowships, BuildGrid bounties, open-source maintenance, accessibility, translation, youth participation, public-good continuation, and evidence improvement, provided that sponsor support remains support and never becomes control.

41.14.1.3 Sponsor-funded incentives are allowed only where capture risk is disclosed, managed, and recorded.

### 41.14.2 Sponsor-Funded Incentive Controls

41.14.2.1 Sponsor-funded incentive rules should identify sponsor, funding or support type, eligible uses, prohibited uses, sponsor benefits, sponsor access limits, sponsor claims limits, conflict controls, independent review requirements, data access restrictions, public-safe reporting controls, and correction obligations.

41.14.2.2 Sponsors must not control recipient selection where conflicted, scoring, benchmark design, review outcomes, recognition wording, public dashboard status, Grid maturity, Rails routing, handoff decisions, public authority room outputs, capital-reader outputs, insurance-reader outputs, or community safeguard outputs.

41.14.2.3 Sponsor-funded incentives must not be used to create preferred vendors, preferred technologies, preferred teams, preferred countries, preferred routes, preferred public authority narratives, or preferred handoff candidates.

### 41.14.3 Sponsor-Funded Incentive Records

41.14.3.1 Sponsor-Funded Incentive Records should identify sponsor, incentive, recipients where public-safe, funding or in-kind support, rules, conflicts, review separation, access restrictions, public claims limits, correction status, and archive reference.

41.14.3.2 Sponsor-funded incentive overclaims must be corrected through sponsor correction, public-safe notice, dashboard correction, report correction, incentive record correction, or archive annotation.

### 41.14.4 Sponsor-Funded Incentive Boundary

41.14.4.1 Sponsor funding does not buy authority.

41.14.4.2 A sponsor-funded incentive remains a Nexus-governed public-good support mechanism, not a sponsor-controlled award, procurement channel, marketing claim, or execution pathway.

## 41.15 Prize Boundary: No Procurement, Finance, Certification, or Deployment Approval

### 41.15.1 Prize Boundary Function

41.15.1.1 **Prize Boundary: No Procurement, Finance, Certification, or Deployment Approval** is the governing boundary rule for all technical prize pools, continuation grants, compute credits, cloud and infrastructure credits, Academy fellowships, BuildGrid bounties, Foundry continuation awards, open-source maintenance awards, low-resource participation support, national continuation credits, evidence improvement grants, correction excellence awards, sponsor-funded incentives, and any other Nexus incentive.

41.15.1.2 No incentive creates procurement status, vendor preference, supplier prequalification, tender award, investment advice, financeability, bankability, credit approval, public finance allocation, securities offering, donor commitment, underwriting, insurance approval, rating, guarantee, certification, accreditation, standards conformance, public authority approval, community consent, deployment authorization, employment, professional qualification, or execution authority.

41.15.1.3 This boundary protects participants, sponsors, providers, public authorities, capital readers, insurers, hosts, communities, universities, low-resource teams, youth participants, and Nexus public-good institutions from treating incentive receipt as external authority.

### 41.15.2 Required Boundary Notices

41.15.2.1 Incentive materials must include boundary notices where reasonable readers may misunderstand the effect of the incentive.

41.15.2.2 Boundary notices should state that incentives support public-good participation, evidence improvement, learning, continuation, maintenance, correction, or resource access only, and that external procurement, finance, insurance, certification, public authority approval, community consent, deployment, and execution decisions must occur separately through competent lawful actors.

41.15.2.3 Public communications about incentives must avoid language implying winners are approved vendors, investable projects, financeable projects, insured projects, certified technologies, government-approved solutions, deployment-ready systems, or authorized execution actors.

### 41.15.3 Boundary Correction

41.15.3.1 Incentive overclaims must be corrected where any participant, sponsor, provider, host, media actor, public authority reference, capital-reader material, insurance-reader material, public dashboard, Marketplace listing, Registry entry, public-safe report, National Portfolio summary, Grid record, Rails route, or handoff package misstates the effect of an incentive.

41.15.3.2 Corrective actions may include wording correction, public-safe notice, dashboard correction, report correction, sponsor correction, provider correction, award correction, recognition limitation, Grid correction, Rails correction, handoff correction, or archive annotation.

### 41.15.4 Final Prize Boundary

41.15.4.1 Incentives reward work; they do not approve outcomes.

41.15.4.2 Prize, grant, credit, fellowship, bounty, award, support, or continuation status is never external authority by implication.

## 41.16 Incentive Records and Archive

### 41.16.1 Incentive Register Function

41.16.1.1 **Incentive Records and Archive** means the register and archive system through which Nexus records all incentives, including prize pools, grants, credits, fellowships, bounties, awards, low-resource supports, continuation supports, evidence improvement supports, correction awards, sponsor-funded incentives, recipient records, eligibility records, selection records, conflict records, payment or in-kind support records, public-safe notices, corrections, withdrawals, and archive entries.

41.16.1.2 The Incentive Register preserves transparency, fairness, public-good accountability, anti-capture discipline, sponsor-control limits, provider-neutrality limits, competition safety, tax or reporting traceability where applicable, correctionability, and institutional memory.

41.16.1.3 Incentive Records are not procurement records, finance records, insurance approvals, certification records, public authority approvals, employment records, or execution records unless a separate lawful process outside Nexus creates such records.

### 41.16.2 Register Contents

41.16.2.1 The Incentive Register may include:\
41.16.2.1(a) **Technical Prize Pool Records**;\
41.16.2.1(b) **Public-Good Continuation Grant Records**;\
41.16.2.1(c) **Compute Credit Records**;\
41.16.2.1(d) **Cloud and Infrastructure Credit Records**;\
41.16.2.1(e) **Academy Fellowship Records**;\
41.16.2.1(f) **BuildGrid Bounty Records**;\
41.16.2.1(g) **Foundry Continuation Award Records**;\
41.16.2.1(h) **Open-Source Maintenance Award Records**;\
41.16.2.1(i) **Low-Resource Participation Support Records**;\
41.16.2.1(j) **National Continuation Credit Records**;\
41.16.2.1(k) **Evidence Improvement Grant Records**;\
41.16.2.1(l) **Correction Excellence Award Records**;\
41.16.2.1(m) **Sponsor-Funded Incentive Records**;\
41.16.2.1(n) **Incentive Boundary Correction Records**;\
41.16.2.1(o) **Incentive Withdrawal, Suspension, Replacement, and Archive Records**.

41.16.2.2 Each entry should identify incentive type, purpose, funding or support source, sponsor or provider role, eligibility basis, recipient where public-safe, support amount or in-kind equivalent where appropriate and permitted, permitted use, prohibited use, selection method, conflicts, public-safe status, correction status, completion status, and archive reference.

### 41.16.3 Archive and Correction

41.16.3.1 Incentive records must remain correctable where eligibility, selection, conflict status, sponsor role, provider role, recipient status, rights status, integrity status, score status, recognition status, Grid status, Rails status, handoff status, or public claims status changes.

41.16.3.2 Incentives may be suspended, withdrawn, replaced, reallocated, reclassified, publicly corrected, or archived where integrity, rights, conflicts, overclaims, eligibility failures, benchmark invalidation, score invalidation, recognition withdrawal, sponsor influence, provider influence, public authority overclaim, capital overclaim, insurance overclaim, or data breach affects the incentive.

41.16.3.3 Archive access must preserve privacy, youth safeguards, confidential financial information, sponsor-sensitive information, provider-sensitive information, legal-hold materials, protected knowledge, personal data, market-sensitive information, and public-safe limits.

### 41.16.4 Final Incentive Rule

41.16.4.1 No Nexus incentive, prize, grant, credit, fellowship, bounty, award, support package, continuation credit, evidence improvement support, correction award, sponsor-funded support, recipient status, public announcement, dashboard listing, recognition reference, Grid reference, Rails reference, handoff reference, or archive entry may be treated as authority beyond its recorded scope.

41.16.4.2 The final Incentive rule is that Nexus may reward public-good work, expand access, support evidence, maintain open assets, strengthen correction, and continue promising public-good outputs only when incentives remain transparent, conflict-managed, sponsor-controlled only as support, provider-neutral, competition-safe, public-safe, correctionable, archived, and incapable of becoming procurement, finance, insurance, certification, public authority approval, community consent, deployment authorization, or execution by implication.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.therisk.global/organization/cooperation/nexus-universe/framework/xli.-incentives.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

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.