> 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/xxxiv.-capture.md).

# XXXIV. CAPTURE

### Summary

* Defines the anti-capture doctrine that protects Nexus evidence, routing, recognition, and public reporting from sponsor, provider, capital, national, media, and insider control.
* Sets rules for conflict disclosure, recusal, prohibited overlaps, competition safety, clean rooms, procurement firewalls, and capital room conduct.
* Establishes stop-the-line powers, investigations, remedies, sanctions, and public correction for integrity and overclaim incidents.

## 34.1 Anti-Capture Doctrine

### 34.1.1 Anti-Capture Function

34.1.1.1 **Anti-Capture Doctrine** is the governing integrity doctrine that prevents Nexus Universe, Nexus Foundry, BuildGrid, Nexus Core, Nexus Grid, Nexus Rails, National Portfolios, Nexus Consortiums, Competence Cells, public-safe reporting, recognition records, sponsor relationships, provider relationships, public authority learning rooms, capital-reader rooms, insurance-reader rooms, media rooms, and lawful handoff pathways from being controlled, distorted, enclosed, or converted by any single sponsor, provider, capital actor, public authority, national actor, regional actor, founder, insider, media actor, host, platform, institution, or participant class.

34.1.1.2 Anti-capture is not merely an ethics policy. It is a structural condition of Nexus legitimacy. The value of Nexus Universe depends on the public being able to trust that evidence is not purchased, benchmarks are not shaped for favored actors, recognition is not promotional, public authority learning is not approval by implication, capital-readability is not finance by stealth, and lawful handoff is not hidden execution.

34.1.1.3 Anti-capture applies across the full Nexus cycle, including signal intake, Docket formation, Foundry Program design, BuildGrid task allocation, Stack Passport review, technical review, scrutineering, benchmark design, Nexus Core operation, scoring, recognition, public dashboards, public-safe reporting, Grid input review, Rails routing, National Portfolio updates, National Company review, Project SPV candidate review, public authority rooms, capital-reader rooms, insurance-reader rooms, sponsor rooms, media communications, and archive.

### 34.1.2 Capture Forms

34.1.2.1 Capture may be financial, commercial, technical, institutional, national, regional, political, philanthropic, media-based, data-based, infrastructure-based, platform-based, founder-based, insider-based, provider-based, sponsor-based, capital-based, public authority-based, or narrative-based.

34.1.2.2 Capture may occur through direct control, informal influence, preferential access, dependency lock-in, benchmark shaping, rule shaping, data access, staffing dominance, conflict non-disclosure, sponsor pressure, provider pressure, national prestige pressure, capital pressure, public authority overclaim, media amplification, hidden coordination, exclusive infrastructure control, private side agreements, or post-handoff conversion.

34.1.2.3 Capture may exist even where no improper motive is proven. A structure may be capture-prone if one actor or class can materially influence rules, evidence, access, recognition, route assignment, public claims, or continuation outcomes beyond its recorded role.

### 34.1.3 Anti-Capture Records

34.1.3.1 Anti-Capture Records should identify the risk, actor class, affected Nexus function, conflict status, control pathway, mitigation, recusal, access restriction, review adjustment, correction action, monitoring requirement, and archive reference.

34.1.3.2 Anti-Capture Records may be public-safe, controlled, restricted, legal-hold, or archive-only depending on sensitivity, but the existence of confidentiality must not be used to conceal material boundary failure where public-safe correction is required.

### 34.1.4 Anti-Capture Boundary

34.1.4.1 Anti-capture controls do not prohibit support, participation, expertise, sponsorship, public authority learning, capital-reader observation, insurance-reader observation, provider contribution, media participation, or national leadership. They prohibit conversion of those roles into control.

34.1.4.2 The final anti-capture rule is that no actor may buy, sponsor, host, provide, fund, regulate, narrate, found, or participate its way into control over Nexus evidence, recognition, maturity, routing, public-safe reporting, or lawful handoff.

## 34.2 Sponsor Capture Controls

### 34.2.1 Sponsor Capture Function

34.2.1.1 **Sponsor Capture Controls** prevent sponsors, supporters, funders, commercial partners, philanthropic supporters, infrastructure contributors, media sponsors, prize sponsors, challenge sponsors, host sponsors, compute sponsors, network sponsors, cloud sponsors, and other support actors from using support to control Nexus rules, validation, scoring, recognition, public dashboards, public-safe reports, Foundry Programs, BuildGrid work, Grid inputs, Rails routes, public authority rooms, capital-reader rooms, insurance-reader rooms, community safeguard rooms, handoff packages, or public narrative.

34.2.1.2 Sponsorship may strengthen Nexus capacity. It must not weaken Nexus independence.

34.2.1.3 Sponsor capture controls apply before, during, and after sponsorship, including sponsor selection, sponsor benefits, sponsor access, sponsor communications, sponsor rooms, sponsor-supported challenges, sponsor-supported bounties, sponsor-supported teams, sponsor-supported infrastructure, and sponsor use of Nexus marks.

### 34.2.2 Sponsor Prohibitions

34.2.2.1 Sponsors must not control technical rules, operating policies, challenge design where conflicted, benchmark methods, scoring, penalty decisions, appeal decisions, Platform Control actions, Stewards Panel decisions, recognition categories, public dashboard status, public-safe report conclusions, Grid maturity review, Rails route assignment, handoff eligibility, public authority room outputs, capital-reader outputs, insurance-reader outputs, or community safeguard outputs.

34.2.2.2 Sponsors must not receive restricted telemetry, protected knowledge, personal data, public authority-sensitive information, sovereign data, capital-reader materials, insurance-reader materials, handoff-only materials, confidential competitor information, or controlled evidence by virtue of sponsorship.

34.2.2.3 Sponsors must not represent support as endorsement, certification, preferred status, procurement status, financeability, insurance approval, public authority approval, community consent, deployment authorization, or execution authority.

### 34.2.3 Sponsor Capture Records

34.2.3.1 Sponsor Capture Records should identify sponsor, support category, conflict assessment, control restrictions, data access limits, branding limits, public claims limits, room access, challenge involvement, bounty involvement, team support role, correction obligations, and archive reference.

34.2.3.2 Sponsor-related overclaims, pressure, attempted influence, data access misuse, or boundary breaches must be recorded and corrected.

### 34.2.4 Sponsor Capture Boundary

34.2.4.1 Sponsorship buys no authority.

34.2.4.2 Sponsor participation remains support only and may be suspended, limited, corrected, or terminated where capture risk becomes material.

## 34.3 Provider Capture Controls

### 34.3.1 Provider Capture Function

34.3.1.1 **Provider Capture Controls** prevent providers, operators, OEMs, infrastructure firms, platform firms, cloud providers, compute providers, network providers, data providers, model providers, software providers, cybersecurity providers, AI providers, digital twin providers, hosts, and technical contributors from using technical contribution, infrastructure dependency, tooling access, expertise, or market power to control Nexus rules, validation, benchmarks, evidence, scoring, recognition, dashboards, Grid inputs, Rails routes, or handoff pathways.

34.3.1.2 Provider participation is valuable when it expands capability, interoperability, and evidence. It becomes capture when provider involvement shapes Nexus outputs to privilege the provider’s technology, business model, data access, infrastructure dependency, or market position without recorded and managed controls.

34.3.1.3 Provider capture controls apply to contributed infrastructure, donated credits, technical staff, benchmark tools, model access, data access, APIs, cloud environments, network environments, cyber ranges, telemetry systems, dashboards, reference implementations, and handoff materials.

### 34.3.2 Provider Prohibitions

34.3.2.1 Providers must not control benchmark design where their technology is being evaluated, score interpretation, technical review of their own stack, evidence review of their own contribution, recognition decision, Grid maturity input, Rails route assignment, public claims language, public authority room outputs, capital-reader materials, insurance-reader materials, or handoff package conclusions.

34.3.2.2 Providers must not use contribution status to imply that their product, platform, model, data, infrastructure, or service is Nexus-certified, Nexus-approved, procurement-ready, government-approved, financeable, insurable, or deployment-ready.

34.3.2.3 Providers must not create dependency lock-in, hidden technical advantage, undisclosed benchmark optimization, privileged data access, undisclosed model substitution, undisclosed compute substitution, or unavailable reproducibility conditions.

### 34.3.3 Provider Capture Records

34.3.3.1 Provider Capture Records should identify provider role, contribution, dependency created, conflict status, evaluation involvement, review exclusions, access limits, data limits, public claims restrictions, benchmark controls, correction obligations, and archive reference.

34.3.3.2 Provider conflicts must be disclosed before the provider participates in challenge design, benchmark operation, technical review, or handoff materials involving its own technologies or competitors.

### 34.3.4 Provider Capture Boundary

34.3.4.1 Provider contribution is not provider validation.

34.3.4.2 Provider involvement must remain evidence-bounded, role-recorded, review-separated, and correctionable.

## 34.4 Capital Capture Controls

### 34.4.1 Capital Capture Function

34.4.1.1 **Capital Capture Controls** prevent investors, lenders, funds, banks, development finance actors, donors, philanthropies, MDBs, DFIs, public finance observers, capital readers, insurers, reinsurers, brokers where lawful, rating-adjacent actors, sponsors, and transaction-oriented actors from converting Nexus evidence, capital-readability, insurance-readiness, Project SPV candidate materials, National Company review, or Rails routes into finance influence, deal control, transaction pressure, or market signaling.

34.4.1.2 Capital participation may help reveal diligence gaps, resilience value, dependency structures, finance-readiness questions, and insurance-readiness questions. It must not control what Nexus validates, recognizes, matures, routes, reports, or hands off.

34.4.1.3 Capital capture controls are especially important because capital interest can distort public-good priorities, national priorities, community safeguards, public authority learning, public-safe reporting, and technical evidence.

### 34.4.2 Capital Prohibitions

34.4.2.1 Capital actors must not control Foundry Program selection, Challenge selection, Stack eligibility, scoring, recognition, Grid maturity, Rails route assignment, National Portfolio priority, Project SPV candidate classification, public-safe reporting, public authority learning records, or community safeguard records.

34.4.2.2 Capital actors must not represent capital-reader access, room attendance, evidence review, diligence discussion, resilience-value note, capital-readability score, or Project SPV candidate status as investment interest, financeability, bankability, public finance approval, rating, guarantee, or transaction status.

34.4.2.3 Capital rooms must not become deal rooms by implication.

### 34.4.3 Capital Capture Records

34.4.3.1 Capital Capture Records should identify capital actor category, access class, materials reviewed, no-reliance notices, conflict status, market-sensitive information controls, prohibited claims, correction obligations, and archive reference.

34.4.3.2 Any capital-related overclaim must be corrected through capital-room correction, public-safe correction, Rails correction, handoff correction, National Company correction, Project SPV correction, or archive annotation as appropriate.

### 34.4.4 Capital Capture Boundary

34.4.4.1 Capital-readability is not finance.

34.4.4.2 Capital actors may read evidence; they may not capture Nexus evidence production or route assignment.

## 34.5 Public Authority Capture Controls

### 34.5.1 Public Authority Capture Function

34.5.1.1 **Public Authority Capture Controls** prevent governments, regulators, municipalities, agencies, public finance bodies, emergency bodies, public-service bodies, state-owned entities, and other public authorities from unintentionally or intentionally converting Nexus Universe into a public authority instrument, regulatory shortcut, procurement channel, public warning system, emergency command system, policy endorsement mechanism, or public finance allocation pathway.

34.5.1.2 Public authority participation is valuable when it supports learning, rule-interface understanding, capacity gap identification, public-service questions, and public-safe interpretation. It becomes capture when public authority presence distorts Nexus independence, implies approval, creates procurement influence, or shifts public authority duties into Nexus.

34.5.1.3 Public authority capture controls protect both Nexus and public authorities.

### 34.5.2 Public Authority Prohibitions

34.5.2.1 Public authorities must not use Nexus participation to bypass statutory, regulatory, procurement, public finance, emergency, consultation, community consent, data, or public accountability processes.

34.5.2.2 Nexus must not use public authority attendance, questions, logos, names, statements, or room participation to imply approval, endorsement, regulatory acceptance, procurement status, public finance support, public warning, emergency command, or deployment authorization.

34.5.2.3 Public authorities participating in learning roles must not control scoring, recognition, Grid maturity, Rails route assignment, public-safe reports, or handoff eligibility unless a separate lawful authority and recorded role expressly permits a specific limited function.

### 34.5.3 Public Authority Capture Records

34.5.3.1 Public Authority Capture Records should identify authority category, participation role, materials reviewed, public claims permissions, confidentiality status, boundary notices, conflict status, public-safe language, correction obligations, and archive reference.

34.5.3.2 Public authority overclaims must be corrected promptly and may require dashboard correction, report correction, media correction, National Portfolio correction, Rails correction, handoff correction, or archive annotation.

### 34.5.4 Public Authority Capture Boundary

34.5.4.1 Public authority learning is not public authority substitution.

34.5.4.2 Public authority power remains with the competent public authority acting through its own lawful process.

## 34.6 National Capture Controls

### 34.6.1 National Capture Function

34.6.1.1 **National Capture Controls** prevent any country, national institution, National Nexus Consortium, National Working Group, National Team, National Consortium Company, public authority, sponsor, provider, capital actor, host, founder group, or political actor from using national participation, national pride, national hosting, National Portfolio status, national council status, or national stack status to dominate Nexus Universe or distort public-good evidence.

34.6.1.2 National ownership is central to Nexus. National capture is prohibited. National ownership preserves country-level relevance, legitimacy, safeguards, and continuity; national capture turns public-good records into national prestige instruments, procurement signals, political claims, or closed pipelines.

34.6.1.3 National capture controls preserve the balance between global common rail, regional support, national ownership, local delivery, and lawful handoff.

### 34.6.2 National Capture Risks

34.6.2.1 National capture may arise through disproportionate control of host venues, public authority rooms, National Portfolio wording, national team selection, public dashboard framing, recognition claims, public-safe reports, regional cluster routing, capital-reader narratives, Project SPV candidate prioritization, or media presentation.

34.6.2.2 National capture may also arise where one country attempts to use Nexus outputs to bypass local communities, Indigenous protocols where applicable, public authority process, national data safeguards, regional coordination, or cross-border dependencies.

### 34.6.3 National Capture Records

34.6.3.1 National Capture Records should identify national actor, affected function, capture risk, mitigation, role limits, public-safe language controls, access controls, recusal where needed, correction status, and archive reference.

34.6.3.2 National overclaims must be corrected where they imply sovereign endorsement, national adoption, public authority approval, procurement status, financeability, insurance approval, community consent, deployment authorization, or execution.

### 34.6.4 National Capture Boundary

34.6.4.1 National ownership does not create national control over Nexus truth.

34.6.4.2 National participation must remain evidence-linked, role-recorded, safeguard-aware, and non-supremacy-based.

## 34.7 Regional Capture Controls

### 34.7.1 Regional Capture Function

34.7.1.1 **Regional Capture Controls** prevent any Regional Nexus Consortium, regional headquarters, regional host, regional sponsor, regional public authority, regional capital actor, regional provider, regional political actor, or regional institution from using regional coordination to override national ownership, distort country-level priorities, dominate route assignment, control public-safe reporting, or create regional supremacy.

34.7.1.2 Regional layers exist to support translation, clustering, cross-border learning, regional capability, regional Nexus Universe preparation, and regional public-good coordination. They do not govern national portfolios by supremacy.

34.7.1.3 Regional capture controls preserve the regional function as support architecture rather than command architecture.

### 34.7.2 Regional Capture Risks

34.7.2.1 Regional capture may arise through control of regional host hubs, regional cluster narratives, regional public-safe reports, cross-border corridor framing, national portfolio interpretation, Regional Consortium access, regional sponsor influence, regional provider influence, or regional capital-reader pressure.

34.7.2.2 Regional actors must not use regional relevance to imply authority over national public authorities, National Nexus Consortiums, communities, Indigenous protocols where applicable, national data rules, public finance, procurement, deployment, or execution.

### 34.7.3 Regional Capture Records

34.7.3.1 Regional Capture Records should identify regional actor, affected national or regional record, capture risk, national ownership controls, cross-border controls, public-safe language controls, correction obligations, and archive reference.

34.7.3.2 Regional overclaims must be corrected where they imply regional approval, regional supremacy, cross-border authorization, procurement status, financeability, insurance approval, public authority approval, community consent, deployment authorization, or execution.

### 34.7.4 Regional Capture Boundary

34.7.4.1 Regional coordination is not regional supremacy.

34.7.4.2 Regional actors support national and cross-border learning without overriding lawful national authority or local safeguards.

## 34.8 Foundry Capture Controls

### 34.8.1 Foundry Capture Function

34.8.1.1 **Foundry Capture Controls** prevent Nexus Foundry from being captured through Docket selection, Program formation, Track design, Quest definition, Bounty design, Build prioritization, review-gate control, release-class decisions, maintainer influence, sponsor pressure, provider pressure, founder influence, capital interest, national prestige, public authority pressure, media attention, or insider preference.

34.8.1.2 Foundry capture is dangerous because it occurs upstream. If capture enters at the signal, Docket, Program, Track, or Build stage, later validation may inherit biased assumptions, favored technologies, incomplete safeguards, or predetermined continuation pathways.

34.8.1.3 Foundry Capture Controls keep Nexus Foundry as a public-good build engine rather than a hidden accelerator, venture studio, procurement feeder, sponsor pipeline, or Project SPV factory.

### 34.8.2 Foundry Control Requirements

34.8.2.1 Foundry intake and prioritization should be based on public-good relevance, evidence need, systems-risk relevance, Nexus Universe relevance, National Portfolio relevance, feasibility, safeguard status, data status, technical tractability, correctionability, and lawful continuation clarity.

34.8.2.2 Foundry Programs must disclose sponsor, provider, capital, public authority, national, regional, founder, insider, and institutional conflicts where material.

34.8.2.3 Foundry release classes must not be elevated because of prestige, urgency, sponsor pressure, media interest, public authority attention, or capital interest.

### 34.8.3 Foundry Capture Records

34.8.3.1 Foundry Capture Records should identify Docket or Program affected, capture risk, actor class, mitigation, recusal, review-gate adjustment, release-class limitation, correction action, and archive reference.

34.8.3.2 Foundry capture incidents may require return to Docket, Program suspension, release-class downgrade, BuildGrid hold, Universe-ready hold, Grid hold, Rails hold, or archive annotation.

### 34.8.4 Foundry Capture Boundary

34.8.4.1 Foundry decides what should be built for public-good evidence, not what should be executed for private or institutional advantage.

34.8.4.2 Foundry capture must be stopped before it becomes validation capture.

## 34.9 BuildGrid Capture Controls

### 34.9.1 BuildGrid Capture Function

34.9.1.1 **BuildGrid Capture Controls** prevent distributed work from being captured through maintainer dominance, bounty design, contributor gatekeeping, sponsor-funded task bias, provider-controlled repositories, hidden dependencies, privileged technical access, insider review, opaque merge decisions, AI-generated manipulation, or release package control.

34.9.1.2 BuildGrid is designed to mobilize distributed capability. It becomes capture-prone if contribution pathways are open in appearance but controlled in practice by a sponsor, provider, insider group, national team, maintainer clique, or platform dependency.

34.9.1.3 BuildGrid Capture Controls preserve distributed work as public-good production rather than unpaid vendor development, sponsor-directed labor, insider-controlled release, or opaque technical gatekeeping.

### 34.9.2 BuildGrid Control Requirements

34.9.2.1 BuildGrid Quests, Bounties, Builds, maintainer roles, review gates, release packages, and contribution recognition should be transparent, role-recorded, conflict-reviewed, reviewable, and correctionable.

34.9.2.2 Sponsors and providers may support bounties or infrastructure only without controlling task acceptance, review, scoring, recognition, release status, or public claims where conflicted.

34.9.2.3 Maintainers must disclose conflicts and may be recused from review where their employer, sponsor, provider, project, national team, or personal interest is materially affected.

### 34.9.3 BuildGrid Capture Records

34.9.3.1 BuildGrid Capture Records should identify work object, capture risk, maintainer role, sponsor role, provider role, contributor impact, review action, recusal, correction status, and archive reference.

34.9.3.2 BuildGrid capture incidents may trigger maintainer reassignment, bounty suspension, release hold, repository access change, contribution correction, public-safe notice, or archive annotation.

### 34.9.4 BuildGrid Capture Boundary

34.9.4.1 BuildGrid distributes public-good work; it must not distribute hidden control.

34.9.4.2 Contribution systems must remain fair, reviewable, safeguard-aware, and anti-capture.

## 34.10 Media Capture Controls

### 34.10.1 Media Capture Function

34.10.1.1 **Media Capture Controls** prevent media partners, broadcasters, commentators, publishers, public relations actors, sponsors, influencers, analysts, public dashboard presenters, documentary teams, and communications partners from converting Nexus Universe evidence into hype, vendor promotion, national propaganda, sponsor advantage, public authority overclaim, capital signal, insurance signal, public warning, or unsupported public narrative.

34.10.1.2 Media participation can expand public learning. It becomes capture when narrative overtakes record truth.

34.10.1.3 Media Capture Controls apply to broadcast rights, documentary rights, public dashboard narration, interviews, press materials, daily recaps, awards coverage, public-safe reports, public explainers, social media, sponsor communications, public authority references, and public archive materials.

### 34.10.2 Media Controls

34.10.2.1 Media outputs must align with recorded evidence, recognition boundaries, public-safe language, correction notices, public authority boundaries, finance boundaries, insurance boundaries, procurement neutrality, community consent boundaries, and no-execution notices.

34.10.2.2 Commentators, presenters, media partners, and public communications teams must not describe standings, scores, recognition, Grid maturity, Rails routes, public authority attendance, sponsor support, provider contribution, capital-reader presence, or handoff packages as certification, approval, financeability, insurance approval, public warning, consent, deployment authorization, or execution.

34.10.2.3 Media access must not create access to restricted telemetry, protected knowledge, personal data, public authority-sensitive information, capital-reader materials, insurance-reader materials, or handoff-only materials.

### 34.10.3 Media Capture Records

34.10.3.1 Media Capture Records should identify media actor, output, claims reviewed, restrictions, boundary notices, corrections required, public-safe status, and archive reference.

34.10.3.2 Media overclaims must be corrected promptly, including through public-safe notices, revised materials, takedown requests where appropriate, dashboard corrections, archive annotations, or participant communication.

### 34.10.4 Media Capture Boundary

34.10.4.1 Media may explain Nexus evidence.

34.10.4.2 Media may not redefine Nexus evidence.

## 34.11 Founder and Insider Capture Controls

### 34.11.1 Founder and Insider Capture Function

34.11.1.1 **Founder and Insider Capture Controls** prevent founders, senior leaders, directors, officers, advisors, staff, maintainers, reviewers, council members, board members, committee members, technical leads, institutional insiders, affiliated companies, related persons, and close collaborators from using insider position to control Dockets, Programs, BuildGrid work, validation rules, review outcomes, recognition, Grid inputs, Rails routes, National Portfolio entries, sponsor access, provider access, capital-reader access, media framing, or handoff pathways for improper advantage.

34.11.1.2 Founder and insider legitimacy depends on disciplined self-limitation. The stronger the founding role, the stronger the duty to prevent role collapse, preferential access, undisclosed conflicts, narrative dominance, and personal or institutional overclaim.

34.11.1.3 Insider capture controls are designed to protect the Nexus architecture from becoming founder-controlled, personality-driven, institutionally closed, or private-benefit oriented.

### 34.11.2 Insider Prohibitions

34.11.2.1 Insiders must not use their position to obtain preferential review, preferential routing, confidential information access, sponsor advantage, provider advantage, capital-room advantage, National Company advantage, Project SPV advantage, procurement advantage, recognition advantage, or media advantage.

34.11.2.2 Insiders must not review, score, recognize, route, or approve records where they have an unmanaged material conflict.

34.11.2.3 Insiders must not create private side arrangements that affect Nexus evidence, rules, recognition, maturity, routing, or handoff without disclosure and recorded authorization.

### 34.11.3 Insider Capture Records

34.11.3.1 Founder and Insider Capture Records should identify insider role, interest, affected function, disclosure, recusal, access restriction, independent review, correction action, and archive reference.

34.11.3.2 Serious insider capture risks may require independent review, temporary removal from function, public-safe correction, governance escalation, or legal review.

### 34.11.4 Insider Boundary

34.11.4.1 Founders and insiders may steward Nexus only by preserving its rules above their own influence.

34.11.4.2 Insider authority must remain recorded, limited, reviewable, and correctionable.

## 34.12 Conflict Disclosure

### 34.12.1 Conflict Disclosure Function

34.12.1.1 **Conflict Disclosure** is the duty of participants, sponsors, providers, public authorities, capital readers, insurers, donors, hosts, media actors, reviewers, maintainers, stewards, founders, insiders, National Consortium Companies, Project SPV candidates, Competence Cells, Working Groups, and governance actors to disclose actual, potential, perceived, financial, institutional, professional, personal, political, technical, national, regional, data-related, provider-related, sponsor-related, capital-related, or public authority-related conflicts.

34.12.1.2 Conflict disclosure is required because Nexus outputs depend on trust in evidence, review, recognition, maturity, routing, and public-safe reporting.

34.12.1.3 A conflict is not automatically misconduct. Failure to disclose, manage, record, or correct a conflict may become misconduct.

### 34.12.2 Disclosure Requirements

34.12.2.1 Conflicts should be disclosed before participation in affected review, scoring, benchmark design, eligibility decisions, recognition decisions, Grid input review, Rails route assignment, public-safe reporting, National Portfolio review, handoff package preparation, sponsor decisions, provider decisions, or public authority-facing outputs.

34.12.2.2 Disclosure should identify the person or institution, nature of interest, affected Nexus function, timing, materiality, proposed mitigation, and whether recusal or access restriction is required.

34.12.2.3 Disclosure duties continue. New conflicts must be disclosed when they arise.

### 34.12.3 Conflict Records

34.12.3.1 Conflict Disclosure Records should identify disclosed interest, actor, affected function, review outcome, mitigation, recusal, access restriction, monitoring, correction status, and archive reference.

34.12.3.2 Conflict records may be public-safe, controlled, restricted, or legal-hold depending on sensitivity, but conflict management must be real and recorded.

### 34.12.4 Disclosure Boundary

34.12.4.1 Disclosure does not cure every conflict.

34.12.4.2 Some conflicts require recusal, restriction, independent review, role separation, or exclusion.

## 34.13 Recusal

### 34.13.1 Recusal Function

34.13.1.1 **Recusal** is the removal or limitation of an actor from a Nexus function where that actor’s conflict, role, interest, affiliation, prior involvement, sponsor relationship, provider relationship, capital relationship, public authority role, national role, media role, or insider status may materially affect impartiality, independence, evidence integrity, public trust, or boundary discipline.

34.13.1.2 Recusal protects the record. It is not a punishment by default.

34.13.1.3 Recusal may apply to technical review, benchmark design, scrutineering, scoring, appeals, recognition, Grid input review, Rails route assignment, public-safe reporting, sponsor decisions, provider decisions, public authority room outputs, capital-reader materials, insurance-reader materials, National Portfolio review, National Company review, Project SPV candidate review, and handoff package preparation.

### 34.13.2 Recusal Requirements

34.13.2.1 Recusal may be mandatory where an actor has a direct financial interest, direct employment interest, ownership interest, sponsor interest, provider interest, competitive interest, personal relationship, political interest, institutional mandate, or prior involvement that materially affects the matter under review.

34.13.2.2 Recusal may be partial, full, temporary, matter-specific, role-specific, access-specific, or function-specific.

34.13.2.3 Recused actors must not access restricted materials, influence reviewers, shape decisions, draft conclusions, or communicate externally about the affected matter except as permitted by the recusal record.

### 34.13.3 Recusal Records

34.13.3.1 Recusal Records should identify actor, matter, conflict basis, scope of recusal, duration, access restrictions, substitute reviewer or process, correction status, and archive reference.

34.13.3.2 Failure to recuse where required may trigger investigation, correction, decision reopening, recognition review, Grid correction, Rails correction, handoff correction, or sanctions.

### 34.13.4 Recusal Boundary

34.13.4.1 Recusal preserves Nexus independence.

34.13.4.2 A recused actor remains a participant only within the limits of the recusal record.

## 34.14 Prohibited Overlaps

### 34.14.1 Prohibited Overlap Function

34.14.1.1 **Prohibited Overlaps** are role combinations, decision combinations, access combinations, and influence combinations that are incompatible with Nexus evidence integrity, anti-capture, competition-law discipline, public authority boundaries, finance boundaries, insurance boundaries, procurement neutrality, sponsor controls, provider neutrality, community safeguards, or lawful handoff discipline.

34.14.1.2 Prohibited overlaps prevent the same actor from shaping a record, benefiting from the record, reviewing the record, recognizing the record, routing the record, and executing from the record without separation.

34.14.1.3 Role separation must be built into the operating system, not improvised after a conflict occurs.

### 34.14.2 Prohibited Role Combinations

34.14.2.1 Unless expressly permitted by a recorded and conflict-managed exception, prohibited overlaps may include:\
34.14.2.1(a) sponsor control over rules, scoring, recognition, or public-safe reports;\
34.14.2.1(b) provider review of its own stack without independent review;\
34.14.2.1(c) capital-reader control over Project SPV candidate route assignment;\
34.14.2.1(d) public authority observer status converted into public authority approval;\
34.14.2.1(e) National Consortium Company control over Nexus Rails route assignment for its own prospective projects;\
34.14.2.1(f) Project SPV candidate influence over Grid maturity inputs;\
34.14.2.1(g) media partner control over public-safe evidence conclusions;\
34.14.2.1(h) founder or insider review of matters involving related interests;\
34.14.2.1(i) maintainer approval of bounty outputs where the maintainer has an undisclosed benefit;\
34.14.2.1(j) Competence Cell validation of outputs where provider neutrality is compromised.

34.14.2.2 Additional prohibited overlaps may be designated by governance records, technical regulations, operating policies, sponsor rules, provider rules, public authority room rules, capital-room rules, insurance-room rules, or handoff protocols.

### 34.14.3 Prohibited Overlap Records

34.14.3.1 Prohibited Overlap Records should identify overlap, affected actor, affected function, risk, mitigation, recusal, exception if any, correction status, and archive reference.

34.14.3.2 Violations may require reversal, re-review, correction, suspension, withdrawal, access restriction, or sanctions.

### 34.14.4 Prohibited Overlap Boundary

34.14.4.1 Some roles cannot be combined even with disclosure.

34.14.4.2 Nexus legitimacy depends on structural separation where disclosure alone is insufficient.

## 34.15 Competition and Antitrust Primacy

### 34.15.1 Competition Primacy Function

34.15.1.1 **Competition and Antitrust Primacy** means that all Nexus Universe, Nexus Foundry, BuildGrid, Nexus Core, Nexus Grid, Nexus Rails, sponsor, provider, capital-reader, insurance-reader, public authority, Marketplace, Registry, National Company, Project SPV candidate, and handoff activities must be conducted in a manner that respects applicable competition, antitrust, procurement, market-conduct, anti-collusion, and fair-dealing laws and principles.

34.15.1.2 Nexus brings competitors, providers, sponsors, public authorities, capital actors, insurers, universities, hosts, and technical contributors into shared rooms. That creates value and risk. Competition discipline is therefore a core operating condition, not an afterthought.

34.15.1.3 Where competition-law ambiguity exists, the more restrictive, safer, and more transparent rule should apply until competent legal review provides otherwise.

### 34.15.2 Competition Controls

34.15.2.1 Nexus activities must avoid price coordination, market allocation, bid-rigging, customer allocation, wage coordination, output restriction, boycott coordination, competitively sensitive information exchange, procurement manipulation, collusive benchmark behavior, exclusionary access, sponsor favoritism, provider favoritism, or coordinated transaction conduct.

34.15.2.2 Capital rooms, insurance rooms, provider rooms, sponsor rooms, public authority rooms, and competitor-facing technical rooms must operate under agendas, access controls, facilitation, prohibited-topic notices, clean-team controls where needed, and recorded boundaries.

34.15.2.3 Benchmarking must be structured to compare performance without enabling illegal coordination or disclosure of market-sensitive information.

### 34.15.3 Competition Records

34.15.3.1 Competition and Antitrust Records should identify meeting type, participants, agenda, prohibited-topic notice, clean-team requirement, information controls, conflicts, incidents, corrective actions, and archive reference.

34.15.3.2 Competition incidents must be escalated, contained, and corrected.

### 34.15.4 Competition Boundary

34.15.4.1 Public-good collaboration does not excuse anticompetitive conduct.

34.15.4.2 Nexus participation must never become a cover for market coordination.

## 34.16 Prohibited Topics

### 34.16.1 Prohibited Topic Function

34.16.1.1 **Prohibited Topics** are topics that may not be discussed, coordinated, exchanged, inferred, agreed, signaled, or facilitated in Nexus rooms, working sessions, sponsor meetings, provider meetings, capital-reader rooms, insurance-reader rooms, public authority rooms, BuildGrid forums, Foundry workshops, handoff meetings, or media settings where the topic would create competition risk, procurement risk, market-conduct risk, confidentiality risk, public authority boundary risk, finance boundary risk, insurance boundary risk, or unlawful coordination.

34.16.1.2 Prohibited topic discipline protects Nexus from becoming a venue for collusion, market signaling, procurement manipulation, investment signaling, underwriting signaling, or improper public authority influence.

34.16.1.3 Prohibited topic rules apply regardless of whether the exchange is formal, informal, verbal, written, implied, coded, public, private, or side-channel.

### 34.16.2 Prohibited Topic Categories

34.16.2.1 Prohibited topics may include:\
34.16.2.1(a) current or future prices, fees, rates, margins, discounts, or commercial terms among competitors;\
34.16.2.1(b) bids, tender strategies, procurement positioning, customer allocation, or market allocation;\
34.16.2.1(c) output limits, capacity limits, service restrictions, or coordinated market entry;\
34.16.2.1(d) wages, hiring restrictions, no-poach arrangements, or labor-market coordination;\
34.16.2.1(e) confidential customer, supplier, investor, insurer, or counterparty information;\
34.16.2.1(f) transaction commitments, investment commitments, underwriting commitments, coverage commitments, or public finance allocation;\
34.16.2.1(g) non-public public authority decisions, procurement deliberations, regulatory actions, emergency actions, or public finance decisions;\
34.16.2.1(h) protected knowledge, personal data, restricted telemetry, cyber-sensitive details, or handoff-only materials outside authorized controls.

### 34.16.3 Prohibited Topic Records

34.16.3.1 Prohibited Topic Records should identify meeting or room, notice provided, prohibited topic raised if any, intervention made, corrective action, participants affected, legal escalation where needed, and archive reference.

34.16.3.2 Repeated prohibited-topic incidents may trigger room restrictions, participant restrictions, sponsor restrictions, provider restrictions, or termination of access.

### 34.16.4 Prohibited Topic Boundary

34.16.4.1 Nexus convening is not permission to discuss restricted market, procurement, public authority, finance, insurance, data, cyber, or protected knowledge matters.

34.16.4.2 Prohibited topics must be stopped when they arise.

## 34.17 Clean Team and Clean Room Controls

### 34.17.1 Clean Team and Clean Room Function

34.17.1.1 **Clean Team and Clean Room Controls** govern situations where Nexus work requires handling sensitive, competitive, confidential, proprietary, public authority-sensitive, capital-sensitive, insurance-sensitive, protected, sovereign, cyber-sensitive, or handoff-only information in a way that prevents improper disclosure, collusion, unfair advantage, or misuse.

34.17.1.2 Clean teams and clean rooms allow necessary review while preserving separation between actors who may not receive the same information, especially competitors, sponsors, providers, capital actors, insurers, public authorities, and Project SPV candidates.

34.17.1.3 Clean controls may be procedural, technical, legal, physical, digital, access-based, role-based, or output-review-based.

### 34.17.2 Clean Control Requirements

34.17.2.1 Clean Team and Clean Room arrangements should identify purpose, participants, excluded persons, information classes, access rules, permitted analysis, prohibited disclosure, output review, logging, retention, deletion, legal hold, and correction pathway.

34.17.2.2 Clean rooms may be used for benchmark review, data review, cyber review, public authority-sensitive review, capital-readiness review, insurance-readiness review, provider-conflict review, sponsor-conflict review, procurement-sensitive review, or handoff package review.

34.17.2.3 Outputs from clean rooms must be reviewed before release and may be public-safe, expert-visible, controlled, restricted, or handoff-only.

### 34.17.3 Clean Control Records

34.17.3.1 Clean Team and Clean Room Records should identify room purpose, participants, information classes, access logs, outputs, review status, incidents, corrections, retention, and archive reference.

34.17.3.2 Breaches must trigger containment, correction, access review, downstream record review, and legal escalation where needed.

### 34.17.4 Clean Control Boundary

34.17.4.1 Clean controls permit limited review; they do not authorize broader disclosure, procurement, finance, insurance, public authority approval, deployment, or execution.

34.17.4.2 Clean room outputs remain bounded by their review status.

## 34.18 Benchmark Anti-Gaming

### 34.18.1 Benchmark Anti-Gaming Function

34.18.1.1 **Benchmark Anti-Gaming** prevents participants from manipulating, overfitting, optimizing narrowly, concealing substitutions, exploiting loopholes, misreporting configurations, contaminating datasets, manipulating telemetry, or otherwise distorting Nexus Universe benchmark, challenge, mission-cycle, simulation, cyber range, digital twin, public explanation, or stack validation results.

34.18.1.2 Benchmark integrity is central to public trust. A gamed benchmark is not merely an unfair score; it is a false evidence record.

34.18.1.3 Anti-gaming controls apply to stack builders, operators, providers, sponsors, national teams, Competence Cells, maintainers, AI systems, data contributors, benchmark designers, reviewers, and public dashboard teams.

### 34.18.2 Anti-Gaming Prohibitions

34.18.2.1 Prohibited gaming may include hidden model substitution, hidden compute substitution, hidden dataset substitution, unapproved human intervention, benchmark leakage, test-set contamination, prompt injection against evaluation systems, telemetry manipulation, fake logs, undeclared external calls, concealed provider assistance, unapproved patching, controlled stack state breach, overfitting to public benchmark examples, manipulating energy records, manipulating cost-to-performance records, or misrepresenting failure recovery.

34.18.2.2 Participants must not exploit public dashboard delays, scoring gaps, undocumented rules, sponsor relationships, provider access, or insider information to gain unrecorded advantage.

34.18.2.3 Benchmark designers must manage leakage, conflicts, and unequal access.

### 34.18.3 Anti-Gaming Records

34.18.3.1 Benchmark Anti-Gaming Records should identify benchmark, participant, suspected issue, evidence, investigation status, hold status, correction action, score effect, recognition effect, Grid effect, Rails effect, and archive reference.

34.18.3.2 Confirmed gaming may trigger score invalidation, penalty, recognition withdrawal, Grid hold, Rails hold, disqualification, access restriction, public-safe correction, or archive annotation.

### 34.18.4 Benchmark Boundary

34.18.4.1 Benchmark performance is valid only when benchmark integrity is preserved.

34.18.4.2 Gaming converts performance claim into correction event.

## 34.19 Collusion Prevention

### 34.19.1 Collusion Prevention Function

34.19.1.1 **Collusion Prevention** prevents participants, sponsors, providers, competitors, capital actors, insurers, public authorities, national teams, hosts, media actors, or other parties from coordinating improperly to manipulate scores, divide markets, influence benchmarks, affect procurement, shape capital signals, pre-arrange recognition, distort public dashboards, control handoff routes, or allocate future opportunities.

34.19.1.2 Collusion can damage Nexus even where it occurs outside formal Nexus rooms if it affects Nexus evidence, validation, recognition, maturity, routing, or public claims.

34.19.1.3 Collusion prevention applies to technical competition, market conduct, public authority engagement, procurement-sensitive contexts, capital-reader rooms, insurance-reader rooms, sponsor arrangements, provider arrangements, and handoff processes.

### 34.19.2 Collusion Controls

34.19.2.1 Nexus activities should use clear agendas, facilitator controls, prohibited-topic notices, documentation, access controls, independent review, clean teams where needed, and incident escalation.

34.19.2.2 Participants must not coordinate scores, challenges, bids, prices, market strategies, public claims, recognition expectations, sponsor advantages, provider advantages, or handoff outcomes.

34.19.2.3 Any suspected collusion must be escalated for integrity review.

### 34.19.3 Collusion Records

34.19.3.1 Collusion Prevention Records should identify suspected conduct, affected actors, affected Nexus function, evidence, immediate controls, investigation status, correction action, sanctions, and archive reference.

34.19.3.2 Collusion incidents may require legal review, evidence hold, score hold, recognition hold, route hold, access restriction, or public-safe correction.

### 34.19.4 Collusion Boundary

34.19.4.1 Nexus collaboration is not permission for coordination that law, fairness, or integrity prohibits.

34.19.4.2 Public-good cooperation must remain competition-safe and evidence-safe.

## 34.20 Procurement Firewall

### 34.20.1 Procurement Firewall Function

34.20.1.1 **Procurement Firewall** is the separation between Nexus evidence activity and any procurement activity by public authorities, private buyers, National Consortium Companies, Project SPVs, hosts, providers, operators, or other lawful actors.

34.20.1.2 The Procurement Firewall prevents Nexus validation, recognition, public dashboards, Registry status, Marketplace discovery, Grid maturity, Rails route assignment, National Portfolio entry, sponsor support, provider participation, or public authority attendance from becoming procurement approval, vendor prequalification, tender shortlisting, preferred supplier status, purchase recommendation, or award decision.

34.20.1.3 Procurement may occur only outside Nexus through separate lawful processes.

### 34.20.2 Firewall Controls

34.20.2.1 Procurement-sensitive actors must not use Nexus rooms to discuss active tenders, bid strategies, vendor selection, evaluation preferences, award likelihood, pricing coordination, or procurement commitments.

34.20.2.2 Nexus materials used in procurement contexts must be clearly identified as evidence records, not procurement recommendations, unless a separate competent procurement process lawfully adopts them for its own use.

34.20.2.3 Public authority rooms and provider rooms require heightened procurement-firewall notices.

### 34.20.3 Procurement Firewall Records

34.20.3.1 Procurement Firewall Records should identify procurement-sensitive context, participants, notices, restrictions, materials shared, incidents, corrections, and archive reference.

34.20.3.2 Procurement overclaims must trigger correction, and serious violations may require access restriction, legal review, route hold, or handoff withdrawal.

### 34.20.4 Procurement Firewall Boundary

34.20.4.1 Nexus evidence may inform procurement only through separate lawful procurement review.

34.20.4.2 Nexus does not procure by implication.

## 34.21 Capital Room Conduct

### 34.21.1 Capital Room Function

34.21.1.1 **Capital Room Conduct** governs rooms, sessions, materials, dashboards, briefings, and review processes in which capital readers, donors, development finance actors, public finance observers, National Consortium Companies, Project SPV candidate reviewers, and other capital-relevant actors review Nexus evidence.

34.21.1.2 Capital rooms exist for no-reliance, non-advisory, non-soliciting, non-transactional reading of evidence, risk, maturity, dependency, resilience value, and diligence gaps.

34.21.1.3 Capital rooms must not become investment rooms, pitch rooms, securities rooms, lending rooms, public finance allocation rooms, guarantee rooms, rating rooms, or transaction rooms by implication.

### 34.21.2 Capital Room Rules

34.21.2.1 Capital room materials must include no-investment-advice, no-solicitation, no-financeability, no-bankability, no-rating, no-guarantee, no-commitment, no-public-finance-allocation, no-transaction, no-procurement, and no-execution notices.

34.21.2.2 Participants must not discuss or solicit investment commitments, financing terms, securities offerings, public finance allocation, pricing, ratings, guarantees, underwriting commitments, or transaction status within Nexus capital rooms unless a separate lawful structure outside Nexus is established and clearly separated.

34.21.2.3 Capital room access must be controlled, logged where appropriate, and limited to materials appropriate for the access class.

### 34.21.3 Capital Room Records

34.21.3.1 Capital Room Conduct Records should identify room purpose, participants, materials, notices, prohibited-topic controls, information classification, incidents, corrections, and archive reference.

34.21.3.2 Capital room violations may require correction, access restriction, Rails hold, handoff hold, or incident review.

### 34.21.4 Capital Room Boundary

34.21.4.1 Capital rooms read evidence.

34.21.4.2 They do not conduct finance.

## 34.22 Sponsor Room Conduct

### 34.22.1 Sponsor Room Function

34.22.1.1 **Sponsor Room Conduct** governs sponsor-facing rooms, sponsor briefings, sponsor coordination sessions, sponsor recognition sessions, sponsor media interfaces, sponsor-supported challenge sessions, and sponsor-supported public-good release sessions.

34.22.1.2 Sponsor rooms allow sponsors to understand the public-good purpose, support conditions, recognition limits, public-safe communications, and impact of their support without influencing Nexus rules, validation, scoring, recognition, Grid inputs, Rails routes, public authority outputs, capital-reader outputs, insurance-reader outputs, or handoff packages.

34.22.1.3 Sponsor room conduct prevents support from becoming control.

### 34.22.2 Sponsor Room Rules

34.22.2.1 Sponsor rooms must include support-without-control notices, data access limits, claims limits, no-certification notices, no-procurement notices, no-finance notices, no-insurance notices, no-public-authority-approval notices, no-community-consent notices, no-deployment notices, and no-execution notices where relevant.

34.22.2.2 Sponsors must not use sponsor rooms to request preferential access to restricted materials, influence recognition, influence scoring, influence challenge rules, shape public-safe reports, obtain competitor information, obtain public authority-sensitive information, obtain capital-reader information, or influence handoff.

34.22.2.3 Sponsor rooms must not become private governance rooms.

### 34.22.3 Sponsor Room Records

34.22.3.1 Sponsor Room Conduct Records should identify room purpose, sponsors present, materials shared, notices given, questions raised, prohibited-topic interventions, correction actions, and archive reference.

34.22.3.2 Sponsor room incidents must be corrected and may require sponsor access limits.

### 34.22.4 Sponsor Room Boundary

34.22.4.1 Sponsor rooms inform sponsors about support.

34.22.4.2 They do not grant control.

## 34.23 Market-Sensitive Information

### 34.23.1 Market-Sensitive Information Function

34.23.1.1 **Market-Sensitive Information** means non-public information that could affect competition, procurement, finance, insurance, securities, commercial negotiations, vendor selection, pricing, bidding, customer decisions, supply chains, or market behavior if disclosed or exchanged improperly.

34.23.1.2 Nexus may encounter market-sensitive information through providers, sponsors, capital readers, insurers, National Consortium Companies, Project SPV candidates, public authorities, hosts, Stack Passports, Evidence Packs, dependency packages, and handoff records.

34.23.1.3 Market-sensitive information must be classified, access-controlled, and protected from improper sharing.

### 34.23.2 Market-Sensitive Categories

34.23.2.1 Market-sensitive information may include pricing, margins, costs, bids, tender strategies, customer lists, sales forecasts, capacity plans, supply constraints, investment intentions, underwriting intentions, financing terms, proprietary technical roadmaps, non-public performance data, confidential contract terms, vendor selection information, public finance deliberations, and transaction plans.

34.23.2.2 Market-sensitive information may also include non-public benchmark performance where disclosure would distort markets, procurement, investment, insurance, or competition.

34.23.2.3 Public dashboards must not publish market-sensitive information unless reviewed and approved for public-safe release.

### 34.23.3 Market-Sensitive Records

34.23.3.1 Market-Sensitive Information Records should identify information class, source, access restrictions, permitted use, prohibited use, retention, disclosure controls, incidents, corrections, and archive reference.

34.23.3.2 Unauthorized disclosure or exchange must trigger containment, correction, legal review where appropriate, and archive update.

### 34.23.4 Market-Sensitive Boundary

34.23.4.1 Nexus evidence processes do not override confidentiality, competition, procurement, securities, finance, insurance, or market-conduct controls.

34.23.4.2 Market-sensitive information may be used only within recorded limits.

## 34.24 Stop-the-Line Authority

### 34.24.1 Stop-the-Line Function

34.24.1.1 **Stop-the-Line Authority** is the authority to pause, hold, suspend, restrict, quarantine, or stop a Nexus activity where there is a material risk to evidence integrity, safety, cyber security, data protection, privacy, protected knowledge, public-safe reporting, competition compliance, procurement neutrality, finance boundary, insurance boundary, public authority boundary, community safeguard, anti-capture discipline, or lawful handoff integrity.

34.24.1.2 Stop-the-Line Authority is not punitive by default. It is a trust-preservation mechanism that prevents harm or overclaim before correction becomes harder.

34.24.1.3 Stop-the-Line Authority may apply to Foundry Programs, BuildGrid work, Nexus Core validation, challenges, benchmarks, public dashboards, public-safe reports, recognition, Grid inputs, Rails routes, sponsor rooms, provider rooms, capital rooms, insurance rooms, public authority rooms, handoff packages, National Portfolio entries, and media outputs.

### 34.24.2 Stop Triggers

34.24.2.1 Stop triggers may include safety risk, integrity risk, benchmark gaming, undisclosed conflict, sponsor interference, provider interference, capital-room misconduct, public authority overclaim, procurement firewall breach, prohibited-topic breach, market-sensitive information breach, protected knowledge exposure, PII exposure, cyber incident, AI incident, data governance incident, public dashboard error, public-safe reporting risk, community safeguard breach, or handoff overclaim.

34.24.2.2 Stop actions may include pause, access restriction, evidence hold, score hold, dashboard hold, publication hold, recognition hold, Grid hold, Rails hold, handoff hold, room closure, participant restriction, or escalation.

### 34.24.3 Stop-the-Line Records

34.24.3.1 Stop-the-Line Records should identify trigger, authority invoked, affected activity, immediate action, responsible reviewer, conditions for restart, correction requirements, public-safe notice status, and archive reference.

34.24.3.2 Restart must be recorded and must identify why the stop condition has been resolved or bounded.

### 34.24.4 Stop-the-Line Boundary

34.24.4.1 Stop-the-Line Authority protects Nexus integrity.

34.24.4.2 It does not create external legal findings, regulatory findings, procurement decisions, finance decisions, insurance decisions, public authority decisions, or execution authority.

## 34.25 Integrity Investigations

### 34.25.1 Investigation Function

34.25.1.1 **Integrity Investigations** are formal or informal review processes used to determine whether an anti-capture, conflict, competition, benchmark, procurement, finance, insurance, public authority, sponsor, provider, media, data, cyber, AI, community safeguard, handoff, or boundary incident has occurred and what correction, remedy, or sanction is required.

34.25.1.2 Integrity Investigations protect the reliability of Nexus records and the credibility of Nexus Universe.

34.25.1.3 Investigations may be triggered by complaints, anomalies, telemetry issues, reviewer concerns, public claims, sponsor conduct, provider conduct, participant conduct, media conduct, dashboard errors, benchmark irregularities, access breaches, whistleblower reports, public authority concerns, community concerns, capital-room concerns, insurance-room concerns, or audit findings.

### 34.25.2 Investigation Requirements

34.25.2.1 Investigations should define issue, scope, affected records, affected actors, evidence to be reviewed, access controls, confidentiality conditions, conflict management, interim holds, timeline, reviewer independence, and correction pathway.

34.25.2.2 Investigations may require evidence holds, score holds, recognition holds, Grid holds, Rails holds, handoff holds, dashboard holds, publication holds, access restrictions, clean-team review, legal review, or public-safe interim notice.

34.25.2.3 Investigations must preserve fairness, proportionality, confidentiality where required, public-safe transparency where appropriate, and correctionability.

### 34.25.3 Investigation Records

34.25.3.1 Integrity Investigation Records should identify trigger, scope, evidence reviewed, interim measures, findings where permitted, corrective actions, sanctions if any, public-safe notice status, closure status, and archive reference.

34.25.3.2 Investigation records may be public-safe, controlled, restricted, legal-hold, or archive-only.

### 34.25.4 Investigation Boundary

34.25.4.1 Integrity Investigations determine Nexus record, access, recognition, maturity, route, handoff, and participation consequences.

34.25.4.2 They do not substitute for external legal, regulatory, criminal, procurement, finance, insurance, public authority, employment, or contractual proceedings.

## 34.26 Remedies and Sanctions

### 34.26.1 Remedy and Sanction Function

34.26.1.1 **Remedies and Sanctions** are the corrective, restrictive, restorative, disciplinary, or protective actions that may be applied where anti-capture, conflict, competition, benchmark, sponsor, provider, public authority, capital, insurance, media, data, cyber, AI, community safeguard, handoff, or boundary rules are breached.

34.26.1.2 Remedies restore record truth. Sanctions protect the system from repeated or serious misconduct.

34.26.1.3 Remedies and sanctions must be proportionate, record-based, reviewable, correctionable, and aligned with public-good integrity.

### 34.26.2 Remedy and Sanction Categories

34.26.2.1 Remedies may include correction notice, public-safe correction, wording correction, dashboard correction, report correction, Registry correction, Marketplace correction, Evidence Pack correction, score correction, recognition limitation, Grid correction, Rails correction, handoff correction, access reclassification, dependency update, recusal, independent review, or archive annotation.

34.26.2.2 Sanctions may include warning, access restriction, room removal, participant suspension, sponsor restriction, provider restriction, maintainer removal, reviewer removal, score invalidation, recognition withdrawal, disqualification, route suspension, handoff withdrawal, bounty cancellation, release-class downgrade, public-safe notice, or participation termination.

34.26.2.3 Severe matters may be referred to external legal, regulatory, public authority, procurement, finance, insurance, cyber, privacy, or law-enforcement processes where appropriate.

### 34.26.3 Remedy and Sanction Records

34.26.3.1 Remedy and Sanction Records should identify breach, affected actors, affected records, action imposed, rationale, effective date, duration, appeal or review pathway where applicable, correction status, recurrence prevention, and archive reference.

34.26.3.2 Records should distinguish corrective action from disciplinary sanction and Nexus consequence from external legal finding.

### 34.26.4 Remedy Boundary

34.26.4.1 Remedies and sanctions protect Nexus records and participation.

34.26.4.2 They do not create external legal determinations unless a competent external process separately does so.

## 34.27 Public Correction

### 34.27.1 Public Correction Function

34.27.1.1 **Public Correction** is the public-safe communication of a correction where a boundary incident, anti-capture incident, public claim, dashboard error, report error, recognition error, Grid maturity error, Rails routing error, handoff overclaim, sponsor overclaim, provider overclaim, public authority overclaim, capital overclaim, insurance overclaim, procurement overclaim, public warning confusion, community consent overclaim, media overclaim, benchmark integrity issue, or other material error has affected public understanding.

34.27.1.2 Public Correction is part of public trust infrastructure. Nexus does not preserve legitimacy by hiding mistakes; it preserves legitimacy by correcting them in a bounded, accurate, public-safe, and timely way.

34.27.1.3 Public Correction must communicate enough to correct the record without exposing restricted telemetry, personal data, protected knowledge, public authority-sensitive information, cyber-sensitive details, market-sensitive information, capital-reader materials, insurance-reader materials, legal-hold materials, or handoff-only content.

### 34.27.2 Public Correction Requirements

34.27.2.1 A Public Correction should identify the affected public material, the nature of the correction, the corrected status, the affected boundary, the date of correction, any impact on recognition, scores, dashboards, Grid inputs, Rails routes, handoff status, Marketplace listings, Registry status, reports, or archive entries, and where the corrected record may be found.

34.27.2.2 Public Correction should avoid blame language unless necessary and supported by record. Its primary purpose is record truth, not public spectacle.

34.27.2.3 Where misinformation has spread through media, sponsor materials, provider materials, participant claims, public authority references, capital-reader references, or public dashboards, public correction should be distributed through the same or proportionate channels where feasible.

### 34.27.3 Public Correction Records

34.27.3.1 Public Correction Records should identify correction notice, source incident, affected materials, public-safe wording, publication channels, downstream updates, closure status, and archive reference.

34.27.3.2 Public Correction Records should link to controlled correction records where public-safe summaries omit restricted details.

### 34.27.4 Final Anti-Capture and Integrity Rule

34.27.4.1 No sponsor, provider, capital actor, public authority, national actor, regional actor, founder, insider, media actor, host, maintainer, reviewer, participant, National Consortium Company, Project SPV candidate, or external lawful actor may convert participation, contribution, support, access, recognition, maturity, routing, handoff, or public visibility into control beyond its recorded role.

34.27.4.2 The final anti-capture and integrity rule is that Nexus remains credible only when every room, record, benchmark, dashboard, recognition, Grid input, Rails route, handoff package, public claim, sponsor relationship, provider contribution, capital-readable note, insurance-readable note, public authority learning record, and enterprise interface remains conflict-disclosed, competition-safe, anti-capture disciplined, correctionable, and incapable of becoming certification, procurement, finance, insurance, public authority approval, public warning, emergency command, 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/xxxiv.-capture.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.