> 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/xxxvii.-inclusion.md). # XXXVII. INCLUSION ## Summary This section defines the Nexus Universe inclusion framework. It explains how resource classes, accessibility, multilingual access, low-bandwidth pathways, and protected participation make validation fair without lowering evidence standards. It covers: * Resource classes for open, cost-capped, energy-capped, low-resource, edge, sovereign, public-good, university, youth, national, community, and accessibility contexts. * Inclusion pathways such as low-bandwidth participation, offline packages, translation, multilingual access, and disability inclusion. * Resource-class scoring, inclusion metrics, Foundry and BuildGrid classing, and the rule of equity without weakening truth, safety, or integrity. ## 37.1 Resource-Class Purpose ### 37.1.1 Resource-Class Function 37.1.1.1 **Resource-Class Purpose** means the classification framework through which Nexus Universe, Nexus Foundry, BuildGrid, Nexus Core, Nexus Grid, Nexus Rails, Nexus Academy, National Qualifiers, Regional Qualifiers, public-good challenges, stack validation, scoring, recognition, and public-safe reporting distinguish participants and stacks according to resource conditions, operating constraints, access realities, equity requirements, and comparability needs. 37.1.1.2 Resource-classing exists because high-performance validation must not reward only actors with the largest compute budgets, strongest infrastructure, best network access, largest teams, most mature institutions, sponsor backing, provider support, English-language advantage, travel capacity, or privileged proximity to technical ecosystems. Nexus Universe must be capable of validating frontier stacks while also making room for low-resource, edge, sovereign, university, youth, community-grounded, accessibility-centered, public-good, national-team, offline, multilingual, and low-bandwidth participation. 37.1.1.3 Resource-classing creates fair comparison without lowering evidence standards. It allows like-to-like evaluation within defined constraints and prevents resource asymmetry from being hidden inside performance claims. A stack operating under open compute conditions, a stack operating under strict energy caps, a stack operating on edge devices, a stack operating in a sovereign data zone, and a stack built by a low-resource team may each be valuable, but their results must be interpreted within the class conditions recorded. ### 37.1.2 Resource-Class Principles 37.1.2.1 Resource-classing must preserve evidence, integrity, comparability, inclusion, transparency, and public-good relevance. 37.1.2.2 Resource-classing must not become a mechanism for artificial advantage, hidden subsidy, sponsor preference, provider lock-in, national prestige inflation, youth overclaim, community consent overclaim, accessibility tokenism, or diluted validation. 37.1.2.3 Each resource class must define eligibility, permitted resources, prohibited resources, disclosure requirements, telemetry requirements, scoring adjustments where applicable, recognition categories, public claims limits, correction pathways, and archive treatment. ### 37.1.3 Resource-Class Records 37.1.3.1 Resource-Class Records should identify participant or stack, class claimed, eligibility basis, resource constraints, support received, sponsor or provider involvement, compute allocation, energy cap, cost cap, network conditions, data conditions, access class, accessibility supports, language supports, offline supports, review status, correction status, scoring implications, and archive reference. 37.1.3.2 Resource-Class Records must distinguish actual resource constraint from branding, hardship claim, national identity, youth identity, university identity, community identity, or public-good identity. A class claim must be evidenced. ### 37.1.4 Resource-Class Boundary 37.1.4.1 Resource-classing does not create certification, procurement status, financeability, insurance approval, public authority approval, community consent, deployment authorization, or execution authority. 37.1.4.2 Resource-classing defines comparison conditions and participation pathways only. ## 37.2 Open Class ### 37.2.1 Open Class Function 37.2.1.1 **Open Class** is the resource class for stacks and teams operating without strict cost, energy, compute, low-resource, edge, sovereign, youth, university, or community-grounded constraints beyond the general technical, operating, safety, data, AI, cyber, public-safe, integrity, and boundary rules of Nexus Universe. 37.2.1.2 Open Class allows frontier, large-scale, high-performance, industry-grade, research-grade, provider-grade, national-scale, and complex multi-stack systems to demonstrate performance under disclosed conditions. It is the class in which maximum technical capability may be tested, provided that resources, configurations, sponsors, providers, data, compute, energy, model dependencies, tool use, human intervention, and operating conditions are fully recorded. 37.2.1.3 Open Class is not an unregulated class. Openness in resource availability does not remove disclosure, telemetry, benchmark, integrity, public-safe reporting, safety, cyber, data governance, AI governance, interoperability, correction, Grid, Rails, or handoff requirements. ### 37.2.2 Open Class Requirements 37.2.2.1 Open Class participants must disclose hardware, software, model inventory, dataset inventory, compute environment, network environment, energy and resource profile where required, sponsor support, provider support, external calls, tool use, human intervention, and controlled stack state. 37.2.2.2 Open Class results should be interpreted as results under high-resource or unconstrained conditions unless a narrower condition is recorded. 37.2.2.3 Open Class may produce strong performance records, but those records must not be generalized to low-resource, edge, sovereign, energy-capped, cost-capped, youth, university, or community-grounded contexts unless separately validated. ### 37.2.3 Open Class Records 37.2.3.1 Open Class Records should identify stack, team, resource disclosure, compute resources, energy profile, cost profile where relevant, model profile, data profile, sponsor or provider support, benchmark conditions, score status, recognition status, Grid inputs, Rails relevance, correction status, and archive reference. 37.2.3.2 Open Class public communications must distinguish raw performance from constrained performance. ### 37.2.4 Open Class Boundary 37.2.4.1 Open Class performance does not imply performance under other classes. 37.2.4.2 Open Class recognition remains bounded by recorded resources and conditions. ## 37.3 Cost-Capped Class ### 37.3.1 Cost-Capped Class Function 37.3.1.1 **Cost-Capped Class** is the resource class for stacks and teams operating within a defined cost ceiling for compute, cloud, hardware, software, data access, model access, external tools, network use, or other specified technical resources. 37.3.1.2 Cost-Capped Class tests whether a stack can produce useful performance, evidence, resilience, interoperability, public-safe outputs, and continuation relevance under financial constraints. It is especially important for national systems, public-good organizations, low-resource teams, universities, communities, SMEs, public authorities, and countries that cannot assume unlimited technology spending. 37.3.1.3 Cost-Capped Class prevents high performance from being confused with cost-effective, deployable, public-sector-feasible, low-resource-feasible, or financially accessible performance. ### 37.3.2 Cost-Capped Requirements 37.3.2.1 Cost-Capped participants must disclose cost assumptions, resource prices used, compute allocation, cloud credits, donated resources, sponsor support, provider discounts, open-source components, proprietary services, model access costs, data access costs, and excluded costs. 37.3.2.2 Donated, subsidized, or sponsor-supported resources must be normalized, disclosed, or scored separately where they affect comparability. 37.3.2.3 Cost-Capped results must identify whether costs are measured as actual cost, market-equivalent cost, marginal cost, public-sector cost, academic cost, sponsor-supported cost, or estimated cost. ### 37.3.3 Cost-Capped Records 37.3.3.1 Cost-Capped Class Records should identify cap amount or cost boundary, included cost categories, excluded cost categories, support received, measurement method, evidence basis, benchmark context, score status, correction status, and archive reference. 37.3.3.2 Cost records must be correctable where hidden subsidies, undisclosed services, unpriced resources, or misclassified costs are discovered. ### 37.3.4 Cost-Capped Boundary 37.3.4.1 Cost-Capped Class results do not create financeability, affordability certification, public procurement suitability, bankability, or deployment authorization. 37.3.4.2 They record performance under defined cost assumptions only. ## 37.4 Energy-Capped Class ### 37.4.1 Energy-Capped Class Function 37.4.1.1 **Energy-Capped Class** is the resource class for stacks and teams operating under defined energy, power, carbon, efficiency, thermal, or resource-use constraints. 37.4.1.2 Energy-Capped Class is central to Nexus Universe because high-performance technologies increasingly determine and depend on energy systems, grid resilience, cooling capacity, carbon constraints, public infrastructure, data center policy, sovereign compute strategy, industrial competitiveness, and environmental legitimacy. 37.4.1.3 Energy-Capped Class tests whether a stack can deliver useful performance without hiding excessive energy use, inefficient compute, unsustainable scaling, or externalized infrastructure burden. ### 37.4.2 Energy-Capped Requirements 37.4.2.1 Energy-Capped participants must disclose energy measurement method, power draw, compute allocation, cooling assumptions where relevant, accelerator use, workload duration, utilization, location where relevant, grid assumptions where public-safe, energy credits where applicable, and resource-use telemetry. 37.4.2.2 Energy records must distinguish measured energy, estimated energy, allocated energy, provider-reported energy, facility energy, device energy, and model-inference energy where relevant. 37.4.2.3 Energy-Capped results must not be compared with Open Class results without clear class labeling and boundary notices. ### 37.4.3 Energy-Capped Records 37.4.3.1 Energy-Capped Class Records should identify energy cap, measurement method, telemetry source, workload, stack configuration, compute environment, energy score, efficiency score, limitations, correction status, and archive reference. 37.4.3.2 False, incomplete, or unverifiable energy records may trigger score correction, score invalidation, recognition limitation, Grid correction, or integrity review. ### 37.4.4 Energy-Capped Boundary 37.4.4.1 Energy-Capped Class results do not certify sustainability, carbon compliance, environmental approval, grid readiness, public authority approval, or deployment authorization. 37.4.4.2 They record energy-constrained performance under defined conditions only. ## 37.5 Low-Resource Class ### 37.5.1 Low-Resource Class Function 37.5.1.1 **Low-Resource Class** is the resource class for teams, institutions, countries, communities, youth groups, universities, public-good builders, SMEs, civil society actors, or other participants operating under material limitations in funding, compute, bandwidth, equipment, mentorship, travel, language access, institutional support, or technical infrastructure. 37.5.1.2 Low-Resource Class exists to ensure that Nexus Universe does not become a platform where only well-funded actors can demonstrate capability. It allows meaningful participation, learning, validation, recognition, and public-good contribution under constrained conditions. 37.5.1.3 Low-Resource Class is not a lower evidence class. It is a different resource condition. Evidence, integrity, safety, public-safe reporting, data governance, AI governance, cyber controls, and correctionability still apply. ### 37.5.2 Low-Resource Eligibility 37.5.2.1 Low-Resource eligibility may be based on limited compute access, limited institutional funding, low-bandwidth environment, lack of advanced hardware, constrained travel ability, limited expert mentorship, local infrastructure constraints, language barriers, accessibility needs, public-good status, or documented socioeconomic constraints. 37.5.2.2 Eligibility must be recorded and may require confidential evidence review to avoid stigmatizing participants. 37.5.2.3 Support received through low-resource pathways must be disclosed, including compute credits, cloud credits, equipment support, mentorship, travel support, translation, accessibility support, and sponsor-supported resources. ### 37.5.3 Low-Resource Records 37.5.3.1 Low-Resource Class Records should identify eligibility basis, support received, constraints, access class, benchmark adjustments where applicable, public-safe status, recognition status, correction status, and archive reference. 37.5.3.2 Public communications should avoid deficit language and should emphasize resource-efficient capability, public-good inclusion, and context-specific evidence. ### 37.5.4 Low-Resource Boundary 37.5.4.1 Low-Resource Class status does not lower truth standards, integrity standards, or safety standards. 37.5.4.2 It creates fair participation conditions and context-specific comparison only. ## 37.6 Edge Class ### 37.6.1 Edge Class Function 37.6.1.1 **Edge Class** is the resource class for stacks operating on edge devices, local nodes, constrained hardware, degraded networks, offline-capable environments, remote sites, field systems, embedded systems, mobile systems, sensor environments, robotics platforms, local compute environments, or other non-centralized infrastructure. 37.6.1.2 Edge Class validates whether technology can operate where cloud connectivity, high-performance centralized compute, stable power, high bandwidth, or continuous operator support may not be available. 37.6.1.3 Edge Class is essential for resilience, disaster conditions, rural settings, industrial environments, community systems, public-service continuity, field robotics, agriculture, water systems, health outreach, logistics, degraded-mode networks, and low-bandwidth public-good delivery. ### 37.6.2 Edge Class Requirements 37.6.2.1 Edge Class participants must disclose device type, hardware constraints, compute limits, storage limits, connectivity conditions, power constraints, offline capability, synchronization method, data handling, model deployment method, update mechanism, security controls, and failure modes. 37.6.2.2 Edge Class validation should test latency, autonomy limits, degraded-mode operation, intermittent connectivity, local data protection, safe failure, recovery, and synchronization integrity. 37.6.2.3 Edge Class results must not be represented as cloud-scale performance unless separately validated. ### 37.6.3 Edge Class Records 37.6.3.1 Edge Class Records should identify edge environment, device configuration, network condition, power condition, workload, telemetry method, offline status, synchronization status, safety status, correction status, and archive reference. 37.6.3.2 Edge records should identify whether results were produced locally, partially locally, cloud-assisted, intermittently connected, or externally supported. ### 37.6.4 Edge Class Boundary 37.6.4.1 Edge Class results do not create field deployment approval, public authority approval, safety certification, infrastructure approval, or execution authority. 37.6.4.2 They record edge-context performance only. ## 37.7 Sovereign Class ### 37.7.1 Sovereign Class Function 37.7.1.1 **Sovereign Class** is the resource class for stacks operating under sovereign compute, sovereign data, localization, national repository, national cloud, public-sector data, public authority-sensitive, cross-border-restricted, protected knowledge, or jurisdiction-specific control conditions. 37.7.1.2 Sovereign Class tests whether a stack can produce useful evidence while respecting national law, data sovereignty, localization rules, public authority confidentiality, community safeguards, Indigenous protocols where applicable, compute-to-data constraints, and controlled-access conditions. 37.7.1.3 Sovereign Class is not a political label. It is a recorded technical, legal, data, infrastructure, and governance condition. ### 37.7.2 Sovereign Class Requirements 37.7.2.1 Sovereign Class participants must disclose sovereign data zone status, localization requirements, compute location, data steward, access controls, cross-border transfer restrictions, compute-to-data requirements, repository conditions, public authority-sensitive materials, protected knowledge restrictions, and public-safe output rules. 37.7.2.2 Sovereign Class validation must preserve restricted data and must not export raw data, telemetry, protected knowledge, or public authority-sensitive materials unless authorized. 37.7.2.3 Sovereign Class results must distinguish local validation, controlled-room validation, compute-to-data validation, public-safe summary, and handoff-only evidence. ### 37.7.3 Sovereign Class Records 37.7.3.1 Sovereign Class Records should identify jurisdiction, sovereign data zone, compute environment, data classification, access controls, transfer restrictions, public-safe status, benchmark status, evidence status, correction status, and archive reference. 37.7.3.2 Sovereign records may require restricted or national archive treatment. ### 37.7.4 Sovereign Class Boundary 37.7.4.1 Sovereign Class status does not create public authority approval, data transfer permission, regulatory approval, procurement status, national endorsement, deployment authorization, or execution authority. 37.7.4.2 It records operation under sovereign constraints only. ## 37.8 Public-Good/Open Class ### 37.8.1 Public-Good/Open Class Function 37.8.1.1 **Public-Good/Open Class** is the resource class for stacks, builds, software, data objects, models, dashboards, learning objects, schemas, APIs, reports, benchmark tools, reference implementations, or public-safe knowledge products developed under open, public-good, commons-oriented, reproducible, reusable, or open technical baseline conditions. 37.8.1.2 Public-Good/Open Class rewards public-good reuse, transparency where safe, license clarity, contributor governance, documentation, reproducibility, accessibility, public-safe release, correctionability, and long-term maintainability. 37.8.1.3 Public-Good/Open Class is not equivalent to unrestricted openness. Some public-good objects may remain controlled, restricted, sovereign, protected, or handoff-only where safety, privacy, cyber, protected knowledge, public authority, or lawful handoff conditions require limits. ### 37.8.2 Public-Good/Open Requirements 37.8.2.1 Public-Good/Open Class participants must disclose license, repository, contributor governance, maintainer identity, dependency status, security status, documentation status, public-safe status, data restrictions, model restrictions, AI-use restrictions, and correction pathway. 37.8.2.2 Public-Good/Open Class may evaluate reusability, auditability, documentation quality, interoperability, accessibility, security, reproducibility, public-safe release quality, contribution governance, and correction response. 37.8.2.3 Open-source or public-good status must not be used to bypass safety, privacy, cyber, data, protected knowledge, or public authority controls. ### 37.8.3 Public-Good/Open Records 37.8.3.1 Public-Good/Open Class Records should identify object, repository or archive location, license, release class, maintainer, contributor records, documentation, security status, public-safe status, reuse conditions, correction status, and archive reference. 37.8.3.2 Public communications must distinguish public-good availability from warranty, certification, deployment approval, or procurement status. ### 37.8.4 Public-Good/Open Boundary 37.8.4.1 Public-Good/Open Class does not create warranty, certification, procurement status, financeability, insurance approval, public authority approval, deployment authorization, or execution authority. 37.8.4.2 It records public-good reusability and release conditions only. ## 37.9 University Class ### 37.9.1 University Class Function 37.9.1.1 **University Class** is the resource class for university, college, laboratory, research institution, student, faculty-supervised, research group, capstone, thesis, field-school, or academic-team participation in Nexus Universe, Nexus Foundry, BuildGrid, National Qualifiers, Regional Qualifiers, open-source challenge series, and public-good validation activities. 37.9.1.2 University Class recognizes the distinct value of academic participation: learning, research integrity, open science, reproducibility, student development, public-good contribution, scientific method, and talent formation. 37.9.1.3 University Class must preserve student protections, academic independence, research ethics, data governance, publication boundaries, sponsor controls, provider neutrality, and non-execution boundaries. ### 37.9.2 University Class Requirements 37.9.2.1 University Class participants must disclose institutional affiliation, team composition, faculty mentor where applicable, student status where relevant, sponsor support, provider support, research ethics status where applicable, data permissions, publication plans, license status, and public-safe output rules. 37.9.2.2 University Class results should identify whether outputs are student work, faculty-supervised work, laboratory work, institutional work, open science work, public-good software work, or research prototype work. 37.9.2.3 University Class outputs must not imply institutional endorsement unless separately authorized by the institution. ### 37.9.3 University Class Records 37.9.3.1 University Class Records should identify institution, team, mentor, project, access class, evidence basis, publication status, public-safe status, recognition status, correction status, and archive reference. 37.9.3.2 Records must distinguish academic participation from institutional approval, public authority approval, procurement qualification, or deployment readiness. ### 37.9.4 University Class Boundary 37.9.4.1 University Class participation does not create academic credit, institutional endorsement, employment, professional qualification, procurement status, public authority approval, financeability, insurance approval, deployment authorization, or execution authority. 37.9.4.2 It records academic and student participation only. ## 37.10 Youth Class ### 37.10.1 Youth Class Function 37.10.1.1 **Youth Class** is the resource class for young participants, youth teams, school-linked teams, junior series participants, youth olympiad participants, beginner public-good builders, and age-protected learning pathways. 37.10.1.2 Youth Class emphasizes learning, safety, inclusion, creativity, public-good purpose, teamwork, evidence basics, responsible technology, accessibility, community awareness, and public-safe communication. 37.10.1.3 Youth Class must be governed by youth safeguarding, privacy, age-appropriate design, supervision, anti-exploitation controls, public display limits, and low-risk challenge design. ### 37.10.2 Youth Class Requirements 37.10.2.1 Youth Class participants must have appropriate supervision, consent or authorization where required, privacy protection, safe learning conditions, age-appropriate materials, public display controls, and prohibited-content controls. 37.10.2.2 Youth Class tasks must avoid restricted data, high-risk cyber operations, unsafe AI autonomy, protected knowledge, public authority-sensitive information, capital-reader materials, insurance-reader materials, handoff-only materials, and unsupervised field deployment. 37.10.2.3 Youth Class scoring should emphasize learning, explanation, teamwork, safe design, evidence discipline, accessibility, correction response, and public-good relevance rather than only technical power. ### 37.10.3 Youth Class Records 37.10.3.1 Youth Class Records should identify challenge, participant category, safeguarding status, mentor or supervisor, learning objectives, public display permission, recognition status, correction status, and archive reference. 37.10.3.2 Youth records must be privacy-protected and should use public-safe aggregated or consented display where appropriate. ### 37.10.4 Youth Class Boundary 37.10.4.1 Youth Class participation does not create employment, professional status, procurement qualification, public authority approval, deployment authorization, or execution authority. 37.10.4.2 It provides protected learning participation only. ## 37.11 National Team Class ### 37.11.1 National Team Class Function 37.11.1.1 **National Team Class** is the resource class for country-linked teams participating through National Nexus Consortiums, National Working Groups, National Qualifiers, National Portfolios, universities, public-good teams, public authority learning questions, national hosts, national Competence Cells, or other recorded national pathways. 37.11.1.2 National Team Class supports national ownership, national capability formation, National Portfolio continuity, public authority learning, talent formation, WEFH-B relevance, industrial capability, community safeguard awareness, and lawful continuation readiness. 37.11.1.3 National Team Class must not be used to imply sovereign endorsement, national adoption, public authority approval, public finance allocation, procurement status, national deployment intent, or community consent. ### 37.11.2 National Team Requirements 37.11.2.1 National Team participants must disclose country attribution basis, team composition, National Nexus Consortium relationship where applicable, National Working Group relationship where applicable, public authority relationship where applicable, university relationship where applicable, sponsor support, provider support, data sovereignty issues, and public-safe output rules. 37.11.2.2 National attribution must be classified as national builder, national operator, national host, national participant, national relevance, national public authority question, national portfolio relevance, or national support role. 37.11.2.3 Cross-border or diaspora teams must identify the basis of country linkage and any multi-country attribution. ### 37.11.3 National Team Records 37.11.3.1 National Team Class Records should identify team, country attribution basis, supporting institutions, sponsor or provider support, Stack Passport status, validation status, public-safe status, National Portfolio relevance, recognition status, correction status, and archive reference. 37.11.3.2 Public communications must distinguish national participation from government approval. ### 37.11.4 National Team Boundary 37.11.4.1 National Team Class status does not create sovereign endorsement, public authority approval, procurement status, public finance allocation, financeability, insurance approval, community consent, deployment authorization, or execution authority. 37.11.4.2 It records country-linked participation only. ## 37.12 Community-Grounded Class ### 37.12.1 Community-Grounded Class Function 37.12.1.1 **Community-Grounded Class** is the resource class for stacks, builds, learning projects, public-safe reports, digital twins, dashboards, datasets, public-good software, and challenge outputs grounded in community context, local resilience, public-interest participation, civil society contribution, Indigenous participation where applicable, affected stakeholder knowledge, place-based priorities, accessibility needs, or local public-good learning. 37.12.1.2 Community-Grounded Class exists because technology validation must not be separated from lived risk, local constraints, public legitimacy, protected knowledge, cultural context, accessibility, and community safeguard conditions. 37.12.1.3 Community-grounded participation is not consent by implication. It creates context, learning, safeguards, and relevance only within recorded boundaries. ### 37.12.2 Community-Grounded Requirements 37.12.2.1 Community-Grounded Class participants must disclose community role, public-interest role, local context, safeguard conditions, protected knowledge restrictions, data permissions, geospatial sensitivity, public-safe output rules, accessibility needs, and consent boundary. 37.12.2.2 Outputs must avoid extracting, publishing, modeling, training on, mapping, or commercializing community knowledge, Indigenous knowledge, protected knowledge, sensitive locations, or rights-bearing data without appropriate authority and safeguards. 37.12.2.3 Community-grounded scoring should consider relevance, accessibility, safeguard quality, public-safe communication, local usefulness, correction response, and evidence quality, without reducing technical validation to popularity. ### 37.12.3 Community-Grounded Records 37.12.3.1 Community-Grounded Class Records should identify community context where public-safe, participant role, safeguard status, protected knowledge status, consent boundary, public-safe status, geospatial controls, accessibility status, correction status, and archive reference. 37.12.3.2 Public versions must protect sensitive community information and must not imply consent unless separately and lawfully recorded. ### 37.12.4 Community-Grounded Boundary 37.12.4.1 Community-Grounded Class status does not create community consent, Indigenous consent, public authority approval, procurement status, financeability, insurance approval, deployment authorization, or execution authority. 37.12.4.2 It records community-grounded context and safeguard conditions only. ## 37.13 Accessibility Class ### 37.13.1 Accessibility Class Function 37.13.1.1 **Accessibility Class** is the resource class or cross-cutting participation class for teams, stacks, outputs, dashboards, reports, learning objects, tools, public interfaces, and public-good systems designed, tested, or adapted for disability inclusion, assistive access, accessible public learning, multilingual access, low-bandwidth access, cognitive accessibility, physical accessibility, sensory accessibility, and inclusive participation. 37.13.1.2 Accessibility Class recognizes that public-good technology is incomplete if people cannot use it, understand it, participate in it, or benefit from it because of disability, language, bandwidth, device constraints, literacy, geography, age, or exclusion. 37.13.1.3 Accessibility Class may operate as a standalone class or as an additional recognition layer applied across other classes. ### 37.13.2 Accessibility Requirements 37.13.2.1 Accessibility Class participants should identify accessibility objectives, user groups considered, assistive technology compatibility, language supports, captioning, transcripts, screen-reader compatibility, keyboard navigation, low-bandwidth modes, plain-language summaries, cognitive load considerations, color and contrast considerations, offline formats, and feedback mechanisms. 37.13.2.2 Accessibility testing should involve appropriate review, public-safe participation, privacy protection, and non-extractive engagement with disabled persons and accessibility advocates where applicable. 37.13.2.3 Accessibility claims must be evidence-based and must not imply universal accessibility unless tested and recorded. ### 37.13.3 Accessibility Records 37.13.3.1 Accessibility Class Records should identify output, accessibility objectives, review method, user testing where applicable, limitations, assistive technology compatibility, language support, low-bandwidth support, correction status, and archive reference. 37.13.3.2 Accessibility defects should be corrected, prioritized, and tracked as public-good quality issues. ### 37.13.4 Accessibility Boundary 37.13.4.1 Accessibility Class status does not create legal accessibility compliance certification unless separately issued by a competent authority or process. 37.13.4.2 It records accessibility effort and evidence only. ## 37.14 Foundry Resource Classing ### 37.14.1 Foundry Classing Function 37.14.1.1 **Foundry Resource Classing** is the process through which Nexus Foundry assigns or records appropriate resource classes for Dockets, Programs, Tracks, Quests, Bounties, Builds, Stack Passport candidates, Evidence Pack candidates, public-good objects, Academy objects, and Universe-ready candidates. 37.14.1.2 Foundry classing ensures that resource assumptions are known before work enters BuildGrid, Nexus Core, Grid, Rails, National Portfolios, public-safe reporting, or handoff packages. 37.14.1.3 Foundry classing prevents a build designed for high-resource conditions from being misrepresented as low-resource, edge, sovereign, community-grounded, university, youth, public-good/open, or accessibility-tested. ### 37.14.2 Foundry Classing Requirements 37.14.2.1 Foundry Dockets and Programs should identify intended resource class, eligibility basis, required resources, prohibited resources, sponsor and provider involvement, data conditions, compute conditions, energy conditions, access needs, language needs, accessibility needs, and public-safe requirements. 37.14.2.2 Foundry review gates should confirm whether the resource class remains accurate as work evolves. 37.14.2.3 Foundry class changes must be recorded and may affect eligibility, scoring, recognition, Grid maturity, Rails routing, public-safe reporting, and archive. ### 37.14.3 Foundry Classing Records 37.14.3.1 Foundry Resource Classing Records should identify Docket or Program, class assigned, class rationale, resource assumptions, support requirements, constraints, review status, correction status, and archive reference. 37.14.3.2 Incorrect classing must be corrected before Universe validation or public claims. ### 37.14.4 Foundry Classing Boundary 37.14.4.1 Foundry resource classing does not validate a stack or certify class compliance. 37.14.4.2 It records intended resource context for preparation. ## 37.15 BuildGrid Resource Classing ### 37.15.1 BuildGrid Classing Function 37.15.1.1 **BuildGrid Resource Classing** is the process through which BuildGrid Quests, Bounties, Builds, Sprints, contribution pathways, public-good releases, and learning tasks are assigned resource classes that reflect participation conditions, work requirements, access needs, and output expectations. 37.15.1.2 BuildGrid classing allows distributed contributors to choose work that matches available resources, skill level, bandwidth, language, accessibility needs, device constraints, compute access, and risk tolerance. 37.15.1.3 BuildGrid classing also supports fairness by preventing hidden resource assumptions from excluding low-resource, youth, university, community, accessibility, or offline participants. ### 37.15.2 BuildGrid Classing Requirements 37.15.2.1 BuildGrid tasks should identify resource class, required compute, required tools, bandwidth needs, offline availability, language availability, accessibility status, mentorship availability, data access requirements, AI-use rules, cyber risk, public-safe requirements, review gate, and release class. 37.15.2.2 Bounties must disclose whether sponsor support, provider tools, special access, or controlled data are required. 37.15.2.3 BuildGrid classing must prevent tasks labeled as low-resource or open from requiring hidden proprietary access, high compute, privileged mentorship, high bandwidth, paid tools, or restricted data. ### 37.15.3 BuildGrid Classing Records 37.15.3.1 BuildGrid Resource Classing Records should identify Quest, Bounty, Build, Sprint, class, required resources, support available, access restrictions, language support, accessibility support, offline support, correction status, and archive reference. 37.15.3.2 Contributors should be able to see class-relevant conditions before committing to work. ### 37.15.4 BuildGrid Classing Boundary 37.15.4.1 BuildGrid resource classing does not create employment, compensation entitlement, credential entitlement, procurement qualification, or execution authority. 37.15.4.2 It organizes fair participation conditions only. ## 37.16 Low-Bandwidth Participation ### 37.16.1 Low-Bandwidth Function 37.16.1.1 **Low-Bandwidth Participation** is the participation model for individuals, teams, communities, universities, public authorities, and low-resource actors operating with limited internet connectivity, intermittent access, low data capacity, restricted devices, unreliable electricity, or constrained digital infrastructure. 37.16.1.2 Low-bandwidth participation ensures that Nexus learning, BuildGrid work, public-safe reporting, Academy materials, qualifiers, public-good challenges, and National Portfolio engagement are not limited to high-connectivity environments. 37.16.1.3 Low-bandwidth support is a public-good inclusion requirement and a resilience design requirement. ### 37.16.2 Low-Bandwidth Requirements 37.16.2.1 Low-bandwidth pathways should include lightweight materials, compressed packages, text-first formats, asynchronous submissions, offline-capable tools, low-resolution alternatives, minimal-data dashboards, email-compatible workflows, local synchronization windows, and clear submission windows. 37.16.2.2 Low-bandwidth participants should not be penalized for connectivity limitations where the class or pathway recognizes those constraints. 37.16.2.3 Where real-time validation is required, low-bandwidth constraints must be recorded and accommodated where technically feasible without compromising evidence integrity. ### 37.16.3 Low-Bandwidth Records 37.16.3.1 Low-Bandwidth Participation Records should identify participant or team, connectivity condition, accommodations provided, submission method, synchronization status, evidence status, correction status, and archive reference. 37.16.3.2 Public communications should not stigmatize low-bandwidth participants. ### 37.16.4 Low-Bandwidth Boundary 37.16.4.1 Low-bandwidth participation does not lower evidence integrity, safety, data, AI, cyber, or public-safe requirements. 37.16.4.2 It adapts participation mechanics to connectivity reality. ## 37.17 Offline Packages ### 37.17.1 Offline Package Function 37.17.1.1 **Offline Packages** are prepared materials, tools, datasets where permitted, documentation, templates, learning objects, public-good software bundles, benchmark practice sets, Academy modules, public-safe reporting templates, and BuildGrid task packages that allow participation without continuous internet access. 37.17.1.2 Offline Packages support low-bandwidth, remote, field, emergency, educational, community, sovereign, and resilience contexts. 37.17.1.3 Offline Packages must preserve version control, data protection, public-safe restrictions, license rules, update rules, and correction pathways. ### 37.17.2 Offline Package Requirements 37.17.2.1 Offline Packages should identify package version, contents, release class, permitted use, prohibited use, data classification, AI-use rules, cyber controls, license, checksum or integrity method where applicable, update method, submission method, correction method, and archive reference. 37.17.2.2 Offline Packages must not include restricted data, protected knowledge, secrets, credentials, public authority-sensitive materials, cyber-sensitive tools, capital-reader materials, insurance-reader materials, or handoff-only materials unless specifically authorized and controlled. 37.17.2.3 Offline outputs must be synchronized, reviewed, and corrected before being treated as official Nexus records. ### 37.17.3 Offline Package Records 37.17.3.1 Offline Package Records should identify package, version, recipients, access class, integrity method, update status, submissions received, review status, correction status, and archive reference. 37.17.3.2 Superseded or withdrawn offline packages must be clearly marked, and recipients should be notified where material. ### 37.17.4 Offline Package Boundary 37.17.4.1 Offline Packages support participation and learning. 37.17.4.2 They do not create validation, certification, deployment authorization, or execution authority until outputs are reviewed and recorded. ## 37.18 Translation and Multilingual Participation ### 37.18.1 Translation Function 37.18.1.1 **Translation and Multilingual Participation** is the inclusion pathway through which Nexus materials, Academy content, BuildGrid tasks, public-safe reports, dashboards, challenge rules, Stack Passport guidance, public explainers, consent-boundary notices, sponsor notices, public authority notices, capital-boundary notices, insurance-boundary notices, and handoff-boundary notices may be made accessible across languages. 37.18.1.2 Multilingual participation is not cosmetic. It is a core public-good requirement for national ownership, regional participation, community legitimacy, low-resource inclusion, public authority learning, youth participation, and global-to-local capability formation. 37.18.1.3 Translation must preserve legal meaning, boundary meaning, technical meaning, public-safe meaning, and correction status. ### 37.18.2 Translation Requirements 37.18.2.1 Translated materials should identify source language, target language, translation status, reviewer status, version, effective date, limitations, correction status, and whether the translation is authoritative, reference, plain-language, public-safe, or informal. 37.18.2.2 Where legal or boundary meaning is critical, translations should preserve the controlling authoritative text and identify which version governs in case of inconsistency. 37.18.2.3 Machine translation may support access but must be reviewed where materials involve technical rules, legal boundaries, public authority, finance, insurance, community safeguards, protected knowledge, safety, cyber, AI, or handoff conditions. ### 37.18.3 Translation Records 37.18.3.1 Translation and Multilingual Participation Records should identify material translated, languages, translator or tool status where appropriate, reviewer, authority status, public-safe status, correction status, and archive reference. 37.18.3.2 Translation corrections must propagate to participants who received affected materials where material. ### 37.18.4 Translation Boundary 37.18.4.1 Translation expands access; it does not alter underlying obligations unless the translated text is expressly designated as authoritative. 37.18.4.2 Ambiguity must be resolved in favor of the most protective public-good, safety, privacy, safeguard, and boundary rule. ## 37.19 Disability Inclusion ### 37.19.1 Disability Inclusion Function 37.19.1.1 **Disability Inclusion** is the Nexus participation and design obligation to ensure that persons with disabilities can access Nexus learning, challenges, BuildGrid work, public dashboards, reports, events, online systems, offline packages, public-safe materials, Academy content, public meetings, and contribution pathways on an equitable basis. 37.19.1.2 Disability inclusion is not limited to accommodation after exclusion. It includes accessible design, inclusive participation planning, assistive technology compatibility, captioning, transcripts, sign-language support where feasible, plain-language summaries, cognitive accessibility, physical accessibility, sensory accessibility, flexible participation methods, and feedback-based correction. 37.19.1.3 Disability inclusion strengthens public-good validity because systems that cannot be accessed, understood, or used by disabled persons are incomplete public systems. ### 37.19.2 Disability Inclusion Requirements 37.19.2.1 Nexus participation pathways should identify accessibility features, accommodation request methods, response timelines, accessible formats, assistive technology compatibility, venue accessibility, digital accessibility, language supports, low-bandwidth supports, offline alternatives, and public-safe contact pathways. 37.19.2.2 Accessibility needs and disability-related information must be treated as sensitive personal information and protected from unnecessary disclosure. 37.19.2.3 Accessibility defects in public dashboards, reports, Academy modules, BuildGrid tasks, public interfaces, or event settings must be tracked and corrected. ### 37.19.3 Disability Inclusion Records 37.19.3.1 Disability Inclusion Records should identify accessibility review, accommodation provided, accessibility defect, correction action, public-safe status, privacy status, and archive reference. 37.19.3.2 Public reporting should use aggregated or public-safe accessibility information unless individual disclosure is specifically permitted. ### 37.19.4 Disability Inclusion Boundary 37.19.4.1 Disability inclusion records do not create public disclosure permission for disability-related information. 37.19.4.2 Accessibility is a design and participation obligation, not a publicity claim. ## 37.20 Inclusion Metrics ### 37.20.1 Inclusion Metric Function 37.20.1.1 **Inclusion Metrics** are the recorded measures used to assess whether Nexus participation, resource-classing, Academy pathways, BuildGrid work, qualifiers, public-good challenges, public dashboards, translation, accessibility, low-resource support, youth participation, university participation, community participation, and national participation are inclusive, equitable, accessible, and globally usable. 37.20.1.2 Inclusion Metrics support learning and correction. They must not become social scoring, quota manipulation, reputational ranking, tokenism, or public shaming. 37.20.1.3 Inclusion Metrics help Nexus identify who is participating, who is excluded, which barriers remain, which supports work, which resource classes are effective, and where correction or redesign is needed. ### 37.20.2 Metric Categories 37.20.2.1 Inclusion Metrics may include participation by resource class, geography, language, bandwidth condition, disability access, youth participation, university participation, low-resource participation, community-grounded participation, gender where lawfully and appropriately collected, accessibility support use, translation coverage, offline package use, mentorship coverage, support allocation, completion rates, contribution acceptance rates, and correction requests. 37.20.2.2 Metrics involving personal characteristics must be voluntary where appropriate, minimized, privacy-protected, aggregated where possible, and used for inclusion improvement rather than exclusion or ranking. 37.20.2.3 Metrics must distinguish access, participation, completion, recognition, and continuation; participation alone is not inclusion if participants cannot meaningfully contribute. ### 37.20.3 Inclusion Metric Records 37.20.3.1 Inclusion Metric Records should identify metric, purpose, data source, collection method, privacy status, aggregation status, limitations, correction status, and archive reference. 37.20.3.2 Inclusion Metrics must be corrected where data is incomplete, biased, misleading, or overclaimed. ### 37.20.4 Inclusion Metric Boundary 37.20.4.1 Inclusion Metrics are learning tools. 37.20.4.2 They must not be used for social scoring, discriminatory ranking, automated exclusion, employment decisions, immigration decisions, procurement decisions, finance decisions, insurance decisions, or public authority decisions. ## 37.21 Resource-Class Scoring ### 37.21.1 Resource-Class Scoring Function 37.21.1.1 **Resource-Class Scoring** is the scoring architecture through which Nexus Universe evaluates performance, evidence, maturity, public-good contribution, accessibility, inclusion, efficiency, resilience, and correction response within and across defined resource classes. 37.21.1.2 Resource-Class Scoring prevents unfair comparison between stacks operating under materially different resource conditions while allowing public learning across classes. 37.21.1.3 Resource-Class Scoring must preserve evidence standards. It may contextualize scores, create class-specific standings, normalize resource conditions where appropriate, or create separate recognition categories, but it must not hide weak evidence, unsafe design, incomplete data governance, cyber weakness, AI risk, or public-safe failures. ### 37.21.2 Scoring Methods 37.21.2.1 Resource-Class Scoring may include class-specific benchmarks, cost-normalized performance, energy-normalized performance, edge-context performance, low-bandwidth usability, offline functionality, accessibility performance, public-good reusability, documentation quality, interoperability, correction response, community safeguard quality, and low-resource effectiveness. 37.21.2.2 Scores should distinguish absolute performance, constrained performance, normalized performance, evidence quality, public-good value, accessibility value, and continuation relevance. 37.21.2.3 Scores must identify class conditions, measurement method, limitations, support received, sponsor or provider involvement, correction status, and public claims limits. ### 37.21.3 Scoring Records 37.21.3.1 Resource-Class Scoring Records should identify stack or output, resource class, scoring method, benchmark, telemetry basis, normalization method where applicable, support adjustments, penalties, recognition status, correction status, and archive reference. 37.21.3.2 Misclassified resource-class scores must be corrected, and affected recognition, Grid inputs, Rails routes, public dashboards, and reports must be updated where material. ### 37.21.4 Scoring Boundary 37.21.4.1 Resource-Class Scoring does not create certification, procurement status, financeability, insurance approval, public authority approval, deployment authorization, or execution authority. 37.21.4.2 It records performance and evidence within class conditions only. ## 37.22 Equity Without Lowering Evidence Standards ### 37.22.1 Equity Rule 37.22.1.1 **Equity Without Lowering Evidence Standards** is the governing rule for all resource classes, low-resource support, youth pathways, university pathways, accessibility pathways, community-grounded pathways, multilingual participation, low-bandwidth participation, offline packages, and inclusion metrics. 37.22.1.2 Equity means that Nexus must design participation so that diverse actors can enter, learn, contribute, compete, validate, be recognized, and continue without being excluded by avoidable resource, language, accessibility, bandwidth, geography, institutional, or socioeconomic barriers. 37.22.1.3 Equity does not mean accepting false evidence, unsafe systems, unverifiable telemetry, hidden substitutions, weak data governance, unreviewed AI outputs, cyber risk, protected knowledge misuse, public-safe overclaim, or boundary collapse. Nexus may adapt pathways, supports, formats, classes, and scoring context; it may not dilute truth. ### 37.22.2 Equity Controls 37.22.2.1 Equity controls may include resource classes, low-resource support, cost caps, energy caps, edge classes, sovereign classes, public-good/open classes, youth classes, university classes, community-grounded classes, accessibility classes, translation, offline packages, low-bandwidth workflows, mentorship, scholarships, equipment support, public-good starter kits, and adjusted challenge design. 37.22.2.2 Evidence controls remain mandatory, including Stack Passports, resource disclosures, telemetry, benchmark records, data governance, AI governance, cyber controls, public-safe reporting, integrity review, correctionability, and archive. 37.22.2.3 Where a participant cannot meet a requirement because of resource constraints, Nexus may route the participant to a different class, learning track, BuildGrid task, Academy pathway, public-good quest, or controlled support pathway rather than pretending the requirement was met. ### 37.22.3 Equity Records 37.22.3.1 Equity Records should identify support provided, resource class, accommodation, participation adjustment, evidence requirement, class-specific scoring method, public-safe status, correction status, and archive reference. 37.22.3.2 Equity Records should protect privacy and avoid stigmatizing participants. ### 37.22.4 Final Resource-Class Rule 37.22.4.1 No resource class, support pathway, low-resource accommodation, youth pathway, university pathway, accessibility pathway, community-grounded pathway, translation pathway, low-bandwidth pathway, offline package, inclusion metric, or equity measure may be used to weaken evidence truth, safety, integrity, public-safe reporting, data governance, AI governance, cyber controls, or lawful boundaries. 37.22.4.2 The final resource-class rule is that Nexus must be globally accessible without becoming evidentially weak; inclusive without becoming performative; supportive without becoming captured; fair without becoming false; and ambitious without allowing resource privilege, language privilege, infrastructure privilege, sponsor privilege, provider privilege, or national privilege to masquerade as public-good validity. --- # 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/xxxvii.-inclusion.md?ask=&goal= ``` `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.