> 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/xxxv.-integrity.md).

# XXXV. INTEGRITY

### Summary

This page defines the Nexus Universe integrity framework. It sets anti-cheating, audit, correction, and archive rules. It governs model, data, compute, telemetry, tool use, sponsorship, and contribution integrity. It explains how holds, score invalidation, recognition withdrawal, and public corrections protect record truth. It establishes that Nexus validates only what can be truthfully recorded.

## 35.1 Integrity Architecture

### 35.1.1 Integrity Function

35.1.1.1 **Integrity Architecture** is the system of rules, records, controls, audits, holds, sanctions, corrections, and archive practices that protects Nexus Universe from cheating, hidden substitution, false telemetry, benchmark gaming, undisclosed external assistance, sponsor-assisted concealed advantage, BuildGrid manipulation, Foundry work distortion, false contribution claims, and any other conduct that converts validation into performance theatre rather than evidence.

35.1.1.2 Integrity Architecture applies to Nexus Universe, Nexus Foundry, BuildGrid, Nexus Core, Stack Passports, Evidence Packs, benchmark cycles, mission cycles, telemetry systems, public dashboards, scoring, recognition records, Grid inputs, Rails routes, National Portfolio records, public-safe reports, handoff packages, sponsor relationships, provider relationships, capital-reader interfaces, insurance-reader interfaces, public authority learning interfaces, and archive records.

35.1.1.3 Integrity Architecture treats technical truth as a public-good asset. A false score, fake telemetry chain, hidden model substitution, concealed dataset leakage, undisclosed human intervention, sponsor-assisted advantage, or manipulated BuildGrid contribution does not merely affect a participant; it contaminates evidence, maturity, public trust, public-safe reporting, National Portfolio memory, Grid readiness, Rails routing, and lawful handoff context.

### 35.1.2 Integrity Domains

35.1.2.1 Integrity controls apply across the full validation chain, including:\
35.1.2.1(a) **identity integrity**, ensuring that stack builders, operators, reviewers, maintainers, Competence Cells, sponsors, providers, contributors, and support actors are accurately identified and role-recorded;\
35.1.2.1(b) **configuration integrity**, ensuring that the stack tested is the stack registered, frozen, instrumented, benchmarked, scored, and recorded;\
35.1.2.1(c) **data integrity**, ensuring that datasets, benchmark inputs, telemetry stores, provenance chains, synthetic data, controlled data, sovereign data, and protected knowledge records remain authentic, classified, and unmanipulated;\
35.1.2.1(d) **model integrity**, ensuring that model identity, version, weights, provider, prompts, tools, retrieval sources, agent workflows, and safety controls remain as disclosed;\
35.1.2.1(e) **compute integrity**, ensuring that compute resources, accelerators, cloud instances, edge nodes, sovereign compute environments, confidential computing environments, and compute-to-data settings are accurately recorded;\
35.1.2.1(f) **telemetry integrity**, ensuring that performance, safety, cyber, energy, intervention, override, failure, recovery, and correction records are authentic, timestamped, tamper-evident, and custody-preserved;\
35.1.2.1(g) **review integrity**, ensuring that technical review, scrutineering, scoring, evidence review, Grid input review, Rails route review, and appeals remain conflict-managed and anti-capture disciplined;\
35.1.2.1(h) **public-claim integrity**, ensuring that public dashboards, media outputs, recognition statements, sponsor claims, provider claims, public authority references, capital-readiness notes, insurance-readiness notes, and handoff packages remain bounded by the record.

### 35.1.3 Integrity Records

35.1.3.1 Integrity Records should identify the relevant stack, builder, operator, Foundry origin, BuildGrid origin, Competence Cell involvement, sponsor involvement, provider involvement, benchmark, telemetry chain, audit status, hold status, score status, recognition status, Grid effect, Rails effect, correction status, and archive reference.

35.1.3.2 Integrity Records may be public-safe, expert-visible, controlled, restricted, legal-hold, or archive-only depending on sensitivity, but integrity issues that materially affect public claims must be corrected through public-safe mechanisms where appropriate.

### 35.1.4 Integrity Boundary

35.1.4.1 Integrity Architecture protects Nexus records and validation truth. It does not create external legal findings, regulatory findings, criminal findings, procurement findings, finance findings, insurance findings, public authority decisions, deployment decisions, or execution authority.

35.1.4.2 Nexus integrity determinations govern Nexus participation, scoring, recognition, maturity, routing, handoff, public-safe reporting, and archive status only, unless a competent external process separately creates external consequences.

## 35.2 Anti-Cheating Rule

### 35.2.1 Anti-Cheating Function

35.2.1.1 **Anti-Cheating Rule** is the governing rule that prohibits any participant, stack builder, operator, provider, sponsor, maintainer, reviewer, Competence Cell, national team, contributor, AI system, tool, platform, or support actor from manipulating, concealing, falsifying, substituting, gaming, or misrepresenting any fact material to Nexus Universe validation, scoring, recognition, evidence, maturity, routing, public-safe reporting, or handoff.

35.2.1.2 Cheating includes conduct that produces a result the record would not support if the true configuration, data, model, compute, intervention, dependency, sponsor support, provider support, tool use, external call, benchmark exposure, or telemetry chain were known.

35.2.1.3 The Anti-Cheating Rule applies whether the cheating is intentional, reckless, coordinated, automated, agentic, sponsor-assisted, provider-assisted, insider-assisted, or concealed through omission.

### 35.2.2 Prohibited Cheating Conduct

35.2.2.1 Prohibited cheating may include hidden model substitution, hidden dataset substitution, hidden compute substitution, undisclosed human intervention, fake telemetry, benchmark leakage, test-set contamination, undisclosed external calls, prohibited tool use, sponsor-assisted concealed advantage, provider-assisted concealed advantage, false configuration records, manipulated logs, altered timestamps, unapproved patching, post-freeze modification, fake failure recovery, concealed safety incident, concealed cyber incident, or false public claim.

35.2.2.2 Cheating also includes knowingly allowing another actor to rely on a materially false or incomplete record where the participant has a duty to correct.

35.2.2.3 Attempted cheating may be treated as a violation even where the result is not ultimately accepted, scored, recognized, routed, or handed off.

### 35.2.3 Anti-Cheating Records

35.2.3.1 Anti-Cheating Records should identify suspected conduct, affected record, affected benchmark, affected stack, evidence reviewed, immediate hold status, investigation status, correction action, score effect, recognition effect, Grid effect, Rails effect, handoff effect, participant consequence, and archive reference.

35.2.3.2 Where cheating affects public dashboards, rankings, recognition, public-safe reports, Marketplace listings, Registry entries, Grid records, Rails routes, or handoff packages, correction must propagate to all affected records.

### 35.2.4 Anti-Cheating Boundary

35.2.4.1 A participant may optimize lawfully within disclosed rules. It may not deceive the record.

35.2.4.2 The decisive question is not whether a tactic is clever, but whether the resulting Nexus record remains true.

## 35.3 Hidden Model Substitution Prohibition

### 35.3.1 Model Substitution Function

35.3.1.1 **Hidden Model Substitution Prohibition** prevents a participant from using, switching, routing to, ensemble-combining, distilling from, proxying through, or otherwise relying on an AI model, foundation model, domain model, agentic system, fine-tune, adapter, retrieval layer, external model endpoint, or model version that was not disclosed, permitted, frozen, instrumented, and recorded for the applicable validation context.

35.3.1.2 Model substitution is material because AI performance, safety, provenance, data restrictions, energy use, latency, explainability, cyber posture, privacy posture, public-safe output quality, and lawful handoff readiness all depend on the actual model used.

35.3.1.3 A stack that uses one model in the Stack Passport and another model during validation does not produce a valid result unless the substitution is permitted, recorded, and reviewed.

### 35.3.2 Prohibited Model Substitution

35.3.2.1 Prohibited conduct may include undisclosed model swapping, fallback to a stronger external model, hidden ensemble use, undisclosed agentic orchestration, undisclosed retrieval augmentation, undisclosed fine-tune, undisclosed prompt wrapper, undisclosed tool-augmented model, hidden human-mediated model output selection, concealed model-provider routing, or use of a model version not matching the frozen record.

35.3.2.2 Prohibited conduct also includes representing a public-good, sovereign, local, open, edge, or low-resource model as producing a result when an undisclosed external, cloud, proprietary, larger, or sponsor-provided model materially produced or improved the output.

35.3.2.3 Model substitution remains prohibited even if the substituted model produces safer, better, faster, or more accurate results.

### 35.3.3 Model Integrity Records

35.3.3.1 Model Integrity Records should identify model identity, version, provider, deployment environment, access method, prompts, tools, retrieval sources, adapters, fine-tunes, agent workflows, approved substitutions, emergency substitutions, unauthorized substitutions, correction status, and archive reference.

35.3.3.2 Prompt logs, tool-use logs, model-call logs, output review logs, and Model Cards should be used where appropriate to support model integrity review.

### 35.3.4 Model Substitution Consequences

35.3.4.1 Hidden model substitution may result in evidence hold, score invalidation, recognition withdrawal, Grid hold, Rails hold, handoff withdrawal, public-safe correction, disqualification, access restriction, or repeat-offender treatment.

35.3.4.2 Model substitution discovered after handoff must trigger handoff correction and recipient notification where required or appropriate.

## 35.4 Hidden Dataset Substitution Prohibition

### 35.4.1 Dataset Substitution Function

35.4.1.1 **Hidden Dataset Substitution Prohibition** prevents a participant from using, replacing, augmenting, filtering, preloading, training on, fine-tuning on, validating against, or otherwise benefiting from a dataset, benchmark set, evaluation set, telemetry source, retrieval corpus, synthetic dataset, controlled dataset, sovereign dataset, protected knowledge dataset, or external data source that was not disclosed, permitted, classified, and recorded.

35.4.1.2 Dataset integrity is central to Nexus validation because performance claims, AI outputs, digital twin outputs, simulation results, public dashboards, public-safe reports, capital-readability, insurance-readiness, and lawful handoff records depend on the data actually used.

35.4.1.3 Hidden dataset substitution may invalidate both technical performance and public-good trust, especially where the substituted dataset creates leakage, privacy exposure, protected knowledge exposure, sovereign data breach, benchmark contamination, or false domain transferability.

### 35.4.2 Prohibited Dataset Conduct

35.4.2.1 Prohibited conduct may include undisclosed training-set use, undisclosed evaluation-set exposure, benchmark test-set leakage, hidden retrieval corpus use, unauthorized controlled-data access, protected knowledge ingestion, undisclosed synthetic data replacement, false data provenance, dataset cherry-picking, hidden data cleaning that changes evaluation conditions, undisclosed external data calls, or post-freeze dataset modification.

35.4.2.2 Prohibited conduct also includes representing a result as produced under sovereign data, compute-to-data, low-resource, edge, public-safe, or protected-knowledge constraints when the actual data use violated or bypassed those constraints.

35.4.2.3 Dataset substitution remains prohibited whether or not the substituted dataset improves the result.

### 35.4.3 Dataset Integrity Records

35.4.3.1 Dataset Integrity Records should identify dataset identity, source, steward, classification, provenance, permitted use, prohibited use, training status, evaluation status, retrieval status, synthetic status, controlled status, sovereign status, protected knowledge status, public-safe status, modification history, correction status, and archive reference.

35.4.3.2 Data provenance records, dataset inventories, data-use logs, compute-to-data logs, access logs, and public-safe review records should support dataset integrity review.

### 35.4.4 Dataset Substitution Consequences

35.4.4.1 Hidden dataset substitution may result in evidence hold, score invalidation, recognition withdrawal, public dashboard correction, Grid hold, Rails hold, handoff withdrawal, public-safe correction, disqualification, data access restriction, or incident review.

35.4.4.2 Where personal data, sovereign data, protected knowledge, or restricted data is implicated, privacy, security, protected knowledge, and data governance incident processes must be triggered.

## 35.5 Hidden Compute Substitution Prohibition

### 35.5.1 Compute Substitution Function

35.5.1.1 **Hidden Compute Substitution Prohibition** prevents a participant from using compute resources, accelerators, cloud instances, sovereign compute, edge compute, confidential computing environments, compute-to-data environments, external inference endpoints, hidden GPUs, hidden scaling, undisclosed parallelization, sponsor-provided resources, provider-provided resources, or off-platform compute that were not disclosed, permitted, metered, and recorded.

35.5.1.2 Compute integrity matters because speed, energy efficiency, cost-to-performance, latency, sovereign compute claims, edge claims, low-resource claims, data-localization claims, verifiable compute claims, and capital-readability depend on the compute environment actually used.

35.5.1.3 A result produced through undisclosed compute is not comparable to a result produced under the recorded compute constraints.

### 35.5.2 Prohibited Compute Conduct

35.5.2.1 Prohibited conduct may include hidden accelerator use, undisclosed cloud bursting, undisclosed external inference service use, sponsor-assisted compute advantage, provider-assisted compute advantage, misreported instance type, false energy measurement, hidden parallelization, off-platform preprocessing, off-platform simulation, undisclosed scaling during benchmark interval, or bypass of compute-to-data constraints.

35.5.2.2 Prohibited conduct also includes representing a result as low-resource, edge, sovereign, energy-capped, cost-capped, confidential, or compute-to-data compliant when undisclosed compute materially produced or improved the result.

35.5.2.3 Emergency compute substitutions may be permitted only where rules allow, Platform Control authorizes, telemetry records the change, and scoring or recognition limitations are applied where necessary.

### 35.5.3 Compute Integrity Records

35.5.3.1 Compute Integrity Records should identify compute environment, resource allocation, hardware, accelerator type, instance type, location, sovereignty status, confidentiality status, compute-to-data status, energy meter, usage logs, attestation where applicable, approved substitutions, unauthorized substitutions, correction status, and archive reference.

35.5.3.2 Compute attestation, resource-use records, energy records, infrastructure logs, and telemetry records should support compute integrity review.

### 35.5.4 Compute Substitution Consequences

35.5.4.1 Hidden compute substitution may result in score invalidation, class reassignment, energy score correction, cost-to-performance correction, recognition withdrawal, Grid correction, Rails hold, handoff correction, public dashboard correction, or disqualification.

35.5.4.2 Where hidden compute affects sovereign data, compute-to-data, security, or privacy obligations, the matter must be escalated to the applicable incident pathway.

## 35.6 Undisclosed Human Intervention Prohibition

### 35.6.1 Human Intervention Function

35.6.1.1 **Undisclosed Human Intervention Prohibition** prevents participants from using human assistance, manual correction, manual routing, expert override, hidden operator intervention, post-processing, answer selection, failure masking, incident suppression, manual data cleaning, manual prompt adjustment, manual scoring assistance, or manual system control during validation unless the intervention is permitted, recorded, and reflected in the evidence.

35.6.1.2 Human intervention is not prohibited by default. Nexus values human-in-the-loop and human-on-the-loop systems. The prohibition concerns undisclosed intervention that makes a system appear more autonomous, reliable, accurate, safe, resilient, or mature than the record supports.

35.6.1.3 A stack that relies on human oversight must disclose that reliance as part of its system design, safety case, AI governance, operational model, and maturity context.

### 35.6.2 Prohibited Intervention Conduct

35.6.2.1 Prohibited conduct may include hidden manual correction of model outputs, hidden operator takeover, undisclosed expert answer selection, concealed human triage, manual replacement of failed outputs, unrecorded patching, undisclosed restart, manual telemetry editing, concealed moderation, undisclosed safety override, hidden public dashboard editing, or human simulation of automated performance.

35.6.2.2 Prohibited conduct also includes representing a stack as autonomous, agentic, self-healing, self-optimizing, or automated when material human intervention produced the result.

35.6.2.3 Human intervention required for safety, emergency containment, or Platform Control may be permitted where recorded and scored or limited appropriately.

### 35.6.3 Human Intervention Records

35.6.3.1 Human Intervention Records should identify actor, role, time, trigger, action taken, system affected, output affected, safety justification where applicable, scoring effect, evidence effect, public-safe effect, correction status, and archive reference.

35.6.3.2 Human override records, tool logs, operator logs, incident logs, prompt logs, and Platform Control logs should support review.

### 35.6.4 Intervention Consequences

35.6.4.1 Undisclosed human intervention may result in score limitation, score invalidation, autonomy claim correction, recognition limitation, recognition withdrawal, Grid correction, Rails hold, handoff correction, public-safe correction, or disqualification.

35.6.4.2 Where intervention was used to conceal failure, safety risk, cyber incident, data incident, or public-safe risk, heightened sanctions may apply.

## 35.7 Fake Telemetry Prohibition

### 35.7.1 Telemetry Truth Function

35.7.1.1 **Fake Telemetry Prohibition** prevents creation, submission, alteration, deletion, backfilling, replaying, fabricating, selectively omitting, mislabeling, or manipulating telemetry, logs, timestamps, proof receipts, benchmark records, energy records, safety records, cyber records, operator records, model-call records, tool-use records, or public dashboard feeds.

35.7.1.2 Telemetry is the performance truth layer of Nexus Universe. If telemetry is false, the validation record fails.

35.7.1.3 Fake telemetry is one of the most serious integrity violations because it can corrupt scores, recognition, Grid maturity, Rails routing, public-safe reporting, public dashboards, capital-readability, insurance-readiness, and handoff packages.

### 35.7.2 Prohibited Telemetry Conduct

35.7.2.1 Prohibited conduct may include fabricated logs, altered timestamps, fake sensor data, replayed benchmark outputs, selective deletion of failure logs, fake energy readings, fake latency records, fake recovery records, fake human override records, fake model-call logs, fake tool-use logs, fake compute attestation, fake proof receipts, or telemetry stream substitution.

35.7.2.2 Prohibited conduct also includes failing to disclose known telemetry failure where the failure affects scoring, recognition, maturity, routing, public dashboarding, or handoff.

35.7.2.3 Telemetry failures must be recorded; they must not be silently hidden.

### 35.7.3 Telemetry Integrity Records

35.7.3.1 Telemetry Integrity Records should identify telemetry source, recorder, timestamping method, signing or hashing method where applicable, custody chain, failure status, anomaly status, audit status, correction status, and archive reference.

35.7.3.2 Proof Receipts, tamper-evident logs, hash chains, signatures, time synchronization records, recorder status, access logs, and Platform Control logs should support telemetry integrity review.

### 35.7.4 Telemetry Violation Consequences

35.7.4.1 Fake telemetry may result in immediate integrity hold, score invalidation, recognition withdrawal, Grid withdrawal, Rails route withdrawal, handoff withdrawal, public-safe correction, disqualification, repeat-offender classification, and external referral where appropriate.

35.7.4.2 Where fake telemetry affects public records, correction must be public-safe and traceable.

## 35.8 Benchmark Overfitting and Test-Set Leakage Controls

### 35.8.1 Benchmark Integrity Function

35.8.1.1 **Benchmark Overfitting and Test-Set Leakage Controls** prevent participants from obtaining unfair performance advantage by training, tuning, prompting, selecting, routing, optimizing, or adapting systems to benchmark test sets, hidden evaluation data, challenge-specific secrets, leaked workloads, undisclosed scoring logic, or non-public validation conditions.

35.8.1.2 Nexus benchmarks exist to evaluate capability under defined conditions, not to reward memorization, leakage, or narrow exploitation of known test artifacts.

35.8.1.3 Benchmark integrity requires separation between preparation materials, public practice materials, hidden evaluation materials, controlled test materials, reviewer materials, and post-cycle archive materials.

### 35.8.2 Leakage and Overfitting Prohibitions

35.8.2.1 Prohibited conduct may include training on hidden evaluation sets, obtaining test data from insiders, using leaked prompts or workloads, optimizing against non-public scoring logic, scraping controlled benchmark materials, reverse-engineering hidden tests through repeated unauthorized calls, sharing test-set information with participants, or using public practice materials in a way expressly prohibited by benchmark rules.

35.8.2.2 Overfitting controls may limit repeated submissions, require randomized tasks, rotate workloads, use hidden holdout sets, require provenance declarations, restrict benchmark access, and audit model or dataset preparation.

35.8.2.3 Benchmark designers, reviewers, sponsors, providers, and insiders with access to hidden test materials must be subject to heightened confidentiality, recusal, and access controls.

### 35.8.3 Benchmark Leakage Records

35.8.3.1 Benchmark Leakage Records should identify benchmark, affected materials, access pathway, suspected actors, affected scores, containment action, retest requirements, correction status, and archive reference.

35.8.3.2 Where leakage affects comparability, affected scores, standings, recognition, Grid inputs, Rails routes, and public dashboards must be held, corrected, invalidated, or annotated.

### 35.8.4 Benchmark Integrity Boundary

35.8.4.1 Benchmark preparation is permitted only within the rules.

35.8.4.2 Test-set leakage destroys the evidentiary value of performance and must be corrected.

## 35.9 Undisclosed External Calls and Tool-Use Controls

### 35.9.1 External Call Function

35.9.1.1 **Undisclosed External Calls and Tool-Use Controls** govern the use of external APIs, search tools, model endpoints, databases, retrieval systems, code execution environments, cloud functions, agent tools, browser tools, private repositories, sponsor systems, provider systems, human-in-the-loop services, and third-party services during Nexus validation.

35.9.1.2 External calls and tool use may be permitted where disclosed, authorized, logged, classified, and evaluated as part of the stack. They become integrity violations when hidden, prohibited, unlogged, or used to bypass benchmark, data, compute, cyber, privacy, sovereignty, or safety rules.

35.9.1.3 Tool use must be part of the record because modern agentic systems can appear capable while silently outsourcing work to external systems.

### 35.9.2 External Call Prohibitions

35.9.2.1 Prohibited conduct may include undisclosed API calls, hidden web search, hidden model calls, unauthorized database access, unapproved private repository access, unlogged agent tool use, sponsor-provided hidden tools, provider-provided hidden services, off-platform code execution, external human services, or tool calls that expose restricted data, protected knowledge, personal data, or benchmark materials.

35.9.2.2 External calls must not be used to bypass compute caps, data sovereignty, edge constraints, low-resource class rules, controlled-room rules, benchmark rules, or public-safe output rules.

35.9.2.3 Where external calls are permitted, they must be logged at a level appropriate to the access class and sensitivity.

### 35.9.3 Tool-Use Records

35.9.3.1 Tool-Use Records should identify tool, provider, endpoint, purpose, time, input class, output class, data transmitted, authorization status, logging status, benchmark relevance, privacy status, correction status, and archive reference.

35.9.3.2 Prompt logs, tool-use logs, API logs, network logs, data access logs, and model-call logs should support tool-use review.

### 35.9.4 Tool-Use Boundary

35.9.4.1 Permitted tool use may support validation only where disclosed and recorded.

35.9.4.2 Undisclosed tool use may invalidate the result even where the output appears technically strong.

## 35.10 Sponsor-Assisted Concealed Advantage Controls

### 35.10.1 Sponsor Advantage Function

35.10.1.1 **Sponsor-Assisted Concealed Advantage Controls** prevent sponsors, supporters, funders, host sponsors, compute sponsors, cloud sponsors, network sponsors, data sponsors, media sponsors, prize sponsors, infrastructure sponsors, and affiliated actors from providing hidden or preferential advantage to a participant, stack, team, Foundry Program, BuildGrid Build, Competence Cell, National Team, or handoff candidate.

35.10.1.2 Sponsor assistance is permitted only where disclosed, available under the applicable rules, conflict-managed, recorded, and treated consistently in scoring, recognition, maturity, and public claims.

35.10.1.3 Concealed sponsor advantage can corrupt both competition and public-good legitimacy because it makes a result appear to come from the stack when it actually depends on unrecorded privileged support.

### 35.10.2 Prohibited Sponsor Assistance

35.10.2.1 Prohibited sponsor-assisted advantage may include undisclosed compute credits, hidden infrastructure support, private benchmark coaching, non-public rule guidance, privileged data access, hidden engineering assistance, sponsor-paid human intervention, preferential debugging, private telemetry access, sponsor-controlled media amplification tied to recognition, sponsor influence over reviewers, or sponsor-backed continuation route pressure.

35.10.1.2 Sponsor assistance is also prohibited where it is disclosed but structured to create unfair access, unequal benchmark conditions, or hidden dependency not reflected in scoring.

35.10.2.3 Sponsors must not use support to create preferred stacks, preferred teams, preferred countries, preferred providers, preferred routes, or preferred handoff candidates.

### 35.10.3 Sponsor Advantage Records

35.10.3.1 Sponsor-Assisted Advantage Records should identify sponsor, participant or output affected, assistance provided, disclosure status, rule status, conflict status, scoring effect, recognition effect, Grid effect, Rails effect, correction action, and archive reference.

35.10.3.2 Undisclosed sponsor advantage must trigger correction and may trigger score invalidation, recognition withdrawal, route hold, sponsor restriction, participant restriction, or disqualification.

### 35.10.4 Sponsor Advantage Boundary

35.10.4.1 Sponsor support must be visible to the record.

35.10.4.2 Hidden sponsor advantage is incompatible with Nexus integrity.

## 35.11 Foundry Work Integrity Controls

### 35.11.1 Foundry Integrity Function

35.11.1.1 **Foundry Work Integrity Controls** protect the integrity of Nexus Foundry Dockets, Programs, Tracks, Quests, Bounties, Builds, review gates, release classes, evidence plans, Stack Passport candidates, Grid input candidates, Rails route candidates, and handoff package candidates before they enter Nexus Universe validation or continuation pathways.

35.11.1.2 Foundry work integrity is upstream integrity. If Foundry work is distorted, incomplete, captured, falsely described, sponsor-shaped, provider-shaped, or prematurely elevated, later validation may inherit false assumptions.

35.11.1.3 Foundry integrity controls ensure that work enters Nexus Core, Grid, Rails, National Portfolios, public-safe reports, Marketplace, Registry, and handoff only after proper Docketing, review, classification, and correction.

### 35.11.2 Foundry Integrity Requirements

35.11.2.1 Foundry work should identify source signal, public-good purpose, Docket status, Program status, participants, sponsors, providers, conflicts, review gates, release class, evidence plan, data plan, AI governance plan, cyber plan, safety plan, safeguard plan, public-safe plan, maturity question, continuation question, correction pathway, and archive reference.

35.11.2.2 Foundry outputs must not be advanced to Universe-ready, Grid-ready, Rails-ready, or handoff-ready status due to urgency, popularity, sponsor pressure, media attention, public authority interest, capital interest, or insider preference.

35.11.2.3 Foundry work involving public authorities, capital-readiness, insurance-readiness, protected knowledge, sovereign data, AI, cyber, WEFH-B systems, or Project SPV candidates requires heightened integrity review.

### 35.11.3 Foundry Integrity Records

35.11.3.1 Foundry Work Integrity Records should identify work object, Docket status, release class, review gate, conflicts, integrity checks, deficiencies, corrections, holds, withdrawals, and archive reference.

35.11.3.2 Foundry integrity failures may trigger release-class downgrade, Docket correction, Program hold, BuildGrid hold, Universe-ready hold, Grid hold, Rails hold, or archive.

### 35.11.4 Foundry Integrity Boundary

35.11.4.1 Foundry work is credible only when its record is complete enough to show why it exists, who shaped it, what evidence it seeks, what safeguards apply, and what boundaries limit it.

35.11.4.2 Foundry enthusiasm without integrity must not enter validation as readiness.

## 35.12 BuildGrid Contribution Integrity Controls

### 35.12.1 BuildGrid Integrity Function

35.12.1.1 **BuildGrid Contribution Integrity Controls** protect the integrity of distributed contributions, Quests, Bounties, Builds, maintainer approvals, code commits, data submissions, model submissions, dashboard components, documentation, learning objects, release packages, Evidence Pack components, Grid components, Rails components, and handoff package components.

35.12.1.2 BuildGrid contribution integrity ensures that distributed public-good work remains attributable, reviewable, secure, licensed, non-extractive, non-plagiarized, non-fabricated, and correctionable.

35.12.1.3 BuildGrid contribution integrity is essential where contributors include individuals, universities, students, companies, providers, sponsors, public-interest groups, volunteers, AI-assisted contributors, and Competence Cells.

### 35.12.2 Contribution Integrity Requirements

35.12.2.1 BuildGrid contributions should identify contributor identity where required, contribution type, source rights, AI-use disclosure, license status, dependency status, data provenance, model provenance, test status, security status, review status, maintainer decision, release class, correction pathway, and archive reference.

35.12.2.2 Prohibited contribution conduct may include plagiarism, undisclosed AI-generated output where disclosure is required, malicious code, hidden dependency, secret inclusion, PII inclusion, protected knowledge exposure, false authorship, false test results, license misrepresentation, benchmark contamination, fake bounty completion, or coordinated manipulation of maintainer review.

35.12.2.3 Youth and student contributions require additional privacy, safeguarding, attribution, and exploitation-prevention controls.

### 35.12.3 Contribution Integrity Records

35.12.3.1 BuildGrid Contribution Integrity Records should identify contribution, contributor role, review status, integrity checks, issues found, correction action, release impact, recognition impact, and archive reference.

35.12.3.2 Contribution integrity failures may trigger rejection, correction, release hold, maintainer review, bounty cancellation, contribution recognition correction, access restriction, or archive annotation.

### 35.12.4 Contribution Integrity Boundary

35.12.4.1 Contribution recognition is not proof of authority, employment, certification, procurement qualification, professional status, or execution role.

35.12.4.2 BuildGrid recognizes contribution only to the extent supported by reviewed records.

## 35.13 Random Audits

### 35.13.1 Random Audit Function

35.13.1.1 **Random Audits** are integrity reviews selected without specific suspicion to test the reliability of Nexus records, deter cheating, validate telemetry, confirm stack configuration, inspect model and dataset provenance, verify compute use, review human intervention records, test BuildGrid contribution integrity, and confirm compliance with technical and operating policies.

35.13.1.2 Random audits create system-wide deterrence. They signal that Nexus integrity does not depend only on complaints or visible anomalies.

35.13.1.3 Random audits may apply to stacks, teams, benchmarks, Foundry Programs, BuildGrid Builds, telemetry chains, Model Cards, Dataset Records, compute records, sponsor-supported outputs, provider-supported outputs, Competence Cell work, public dashboards, Grid inputs, Rails routes, and handoff packages.

### 35.13.2 Random Audit Scope

35.13.2.1 Random audits may review Stack Passport consistency, controlled stack state, model identity, dataset identity, compute environment, telemetry chain, external calls, human intervention logs, benchmark exposure, sponsor assistance, provider assistance, release package contents, contribution records, public claims, and correction history.

35.13.2.2 Audit scope should be proportionate to risk and access class. High-risk domains may receive deeper random audits.

35.13.2.3 Refusal to cooperate with a valid audit may trigger integrity hold, score hold, recognition hold, Grid hold, Rails hold, handoff hold, or participation restriction.

### 35.13.3 Random Audit Records

35.13.3.1 Random Audit Records should identify audit target, selection method, scope, materials reviewed, findings, required corrections, score effect, recognition effect, Grid effect, Rails effect, handoff effect, closure status, and archive reference.

35.13.3.2 Audit records may be public-safe, controlled, restricted, or archive-only depending on sensitivity.

### 35.13.4 Random Audit Boundary

35.13.4.1 Random audits support Nexus integrity only.

35.13.4.2 They do not create external legal findings unless separately adopted by competent external processes.

## 35.14 Targeted Audits

### 35.14.1 Targeted Audit Function

35.14.1.1 **Targeted Audits** are integrity reviews initiated because of a specific concern, anomaly, complaint, telemetry inconsistency, benchmark irregularity, conflict issue, sponsor issue, provider issue, public claim issue, data issue, AI issue, cyber issue, public dashboard issue, Grid issue, Rails issue, handoff issue, or other material trigger.

35.14.1.2 Targeted audits are used where risk indicators suggest that random review is insufficient.

35.14.1.3 A targeted audit does not presume wrongdoing. It creates a structured process for determining whether the record can be trusted.

### 35.14.2 Targeted Audit Triggers

35.14.2.1 Targeted audit triggers may include unusual score jumps, telemetry gaps, model-call anomalies, dataset anomalies, compute-use anomalies, energy-use anomalies, identical outputs across teams, suspicious external calls, benchmark leakage indicators, sponsor-assisted advantage concerns, provider dependency anomalies, undisclosed human intervention, public claim inconsistencies, BuildGrid contribution anomalies, or handoff overclaims.

35.14.2.2 Targeted audits may also be triggered by whistleblower reports, reviewer objections, public authority concerns, community concerns, sponsor complaints, provider complaints, capital-reader concerns, insurance-reader concerns, media misstatements, or post-cycle evidence changes.

### 35.14.3 Targeted Audit Records

35.14.3.1 Targeted Audit Records should identify trigger, target, scope, interim holds, evidence reviewed, findings, corrective actions, sanctions if any, score effect, recognition effect, Grid effect, Rails effect, handoff effect, public-safe notice status, and archive reference.

35.14.3.2 Where a targeted audit clears the record, the clearance should be recorded with appropriate access class.

### 35.14.4 Targeted Audit Boundary

35.14.4.1 Targeted audits determine Nexus record consequences.

35.14.4.2 They do not replace external legal, regulatory, procurement, finance, insurance, public authority, employment, or contractual processes.

## 35.15 Integrity Holds

### 35.15.1 Integrity Hold Function

35.15.1.1 **Integrity Hold** is a temporary status applied to a stack, score, standing, recognition record, Evidence Pack, telemetry record, Foundry output, BuildGrid output, public dashboard item, Grid input, Rails route, handoff package, National Portfolio entry, Marketplace listing, Registry entry, or public-safe report while an integrity issue is reviewed.

35.15.1.2 Integrity Holds prevent contested or potentially unreliable records from being relied upon, publicized, recognized, matured, routed, handed off, or used as public-safe reporting basis before the issue is resolved.

35.15.1.3 Integrity Holds are protective, not punitive by default.

### 35.15.2 Hold Triggers

35.15.2.1 Integrity Holds may be triggered by suspected cheating, telemetry anomaly, model substitution concern, dataset substitution concern, compute substitution concern, undisclosed human intervention, benchmark leakage, sponsor-assisted advantage, provider-assisted advantage, contribution integrity issue, conflict issue, public claim issue, public authority overclaim, capital overclaim, insurance overclaim, community safeguard issue, or handoff issue.

35.15.2.2 Holds may be full or partial. A stack may be held for recognition but not for learning; a dashboard may be held publicly while controlled evidence review continues; a Grid input may be held while a public-safe report remains unaffected.

### 35.15.3 Hold Records

35.15.3.1 Integrity Hold Records should identify held object, hold trigger, scope, effective time, access effect, public dashboard effect, score effect, recognition effect, Grid effect, Rails effect, handoff effect, required review, conditions for release, correction status, and archive reference.

35.15.3.2 Release from hold must be recorded and must identify whether the record is reinstated, corrected, limited, downgraded, withdrawn, or archived.

### 35.15.4 Integrity Hold Boundary

35.15.4.1 An Integrity Hold does not determine final fault.

35.15.4.2 It pauses reliance until record trust is resolved.

## 35.16 Score Invalidation

### 35.16.1 Score Invalidation Function

35.16.1.1 **Score Invalidation** is the removal, nullification, limitation, or correction of a score, metric, ranking, standing, benchmark result, mission-cycle result, challenge result, public dashboard result, or performance record because the result is unsupported, unreliable, contaminated, manipulated, non-compliant, incorrectly calculated, wrongly attributed, or otherwise invalid for Nexus purposes.

35.16.1.2 Score Invalidation protects comparability and public trust. A false score must not survive because it is convenient, popular, sponsor-supported, nationally celebrated, or publicly visible.

35.16.1.3 Score Invalidation may apply to individual metrics, class standings, stack standings, national standings, Competence Cell standings, university and youth standings, trust and evidence standings, Foundry Program standings, BuildGrid standings, or recognition-related scores.

### 35.16.2 Invalidation Grounds

35.16.2.1 Grounds may include hidden model substitution, hidden dataset substitution, hidden compute substitution, fake telemetry, benchmark leakage, undisclosed human intervention, external call violation, sponsor-assisted concealed advantage, provider-assisted concealed advantage, scoring calculation error, benchmark invalidation, controlled stack state breach, eligibility violation, safety hold violation, integrity hold violation, or post-cycle evidence correction.

35.16.2.2 Invalidation may be full, partial, class-specific, metric-specific, time-bound, retroactive, or conditional.

35.16.2.3 Where invalidation affects public materials, public-safe correction must be considered.

### 35.16.3 Score Invalidation Records

35.16.3.1 Score Invalidation Records should identify score affected, basis for invalidation, evidence reviewed, effective date, public dashboard effect, recognition effect, Grid effect, Rails effect, handoff effect, participant notice, public-safe notice status, and archive reference.

35.16.3.2 The invalidated score should remain archived with accurate status rather than silently deleted where record integrity requires preservation.

### 35.16.4 Score Boundary

35.16.4.1 A score exists only to the extent the record supports it.

35.16.4.2 An invalid score cannot support recognition, maturity, routing, public claims, or handoff.

## 35.17 Recognition Withdrawal

### 35.17.1 Recognition Withdrawal Function

35.17.1.1 **Recognition Withdrawal** is the removal, limitation, suspension, downgrade, correction, or archive reclassification of a recognition record because the underlying evidence, score, benchmark, telemetry, eligibility, integrity, public-safe status, or boundary condition no longer supports the recognition.

35.17.1.2 Recognition Withdrawal protects public trust by ensuring that recognition remains tied to record truth rather than prestige, publicity, sponsor interest, national pride, or historical convenience.

35.17.1.3 Recognition Withdrawal may apply to World Stack Recognition, Stack Builder Recognition, National Team Recognition, Industrial Stack Recognition, Public-Good Stack Recognition, Competence Cell Recognition, University Recognition, Youth Recognition, Foundry Program Recognition, BuildGrid Quest Recognition, Continuation Recognition, technology-specific recognition, evidence recognition, safety recognition, public-safe report recognition, finance-readiness recognition, insurance-readiness recognition, and lawful handoff package recognition.

### 35.17.2 Withdrawal Grounds

35.17.2.1 Grounds may include score invalidation, hidden substitution, fake telemetry, benchmark leakage, eligibility failure, sponsor-assisted advantage, provider-assisted advantage, undisclosed conflict, false public claim, safety incident, cyber incident, data incident, protected knowledge incident, public authority overclaim, capital-readiness overclaim, insurance-readiness overclaim, community consent overclaim, or correction of the underlying evidence.

35.17.2.2 Withdrawal may be full, partial, category-specific, time-bound, or replaced by corrected recognition.

35.17.2.3 Recognition may also be suspended pending audit.

### 35.17.3 Recognition Withdrawal Records

35.17.3.1 Recognition Withdrawal Records should identify recognition affected, source evidence, withdrawal basis, review process, effective date, public dashboard effect, Registry effect, Marketplace effect, Grid effect, Rails effect, handoff effect, public-safe notice status, and archive reference.

35.17.3.2 Withdrawal records must distinguish corrected recognition from invalid recognition and historic recognition from current recognition.

### 35.17.4 Recognition Withdrawal Boundary

35.17.4.1 Recognition may be withdrawn when the record no longer supports it.

35.17.4.2 Withdrawal corrects Nexus status; it does not create external legal findings unless separately adopted by competent external processes.

## 35.18 Public Correction and Archive

### 35.18.1 Public Correction and Archive Function

35.18.1.1 **Public Correction and Archive** governs how integrity-related corrections are communicated publicly, preserved historically, linked to affected records, and made understandable without exposing restricted information.

35.18.1.2 Public correction is required where an integrity issue materially affects public dashboards, standings, recognition, reports, public-safe summaries, Marketplace listings, Registry entries, public claims, public authority references, sponsor claims, provider claims, capital-readiness claims, insurance-readiness claims, or handoff claims.

35.18.1.3 Archive preserves the history of what happened, what was corrected, what was withdrawn, what remained valid, what was invalidated, and what should not be relied upon.

### 35.18.2 Public Correction Requirements

35.18.2.1 Public corrections should identify the affected public material, corrected status, general reason for correction, affected recognition or score where public-safe, affected dashboard status, affected Registry or Marketplace status, effective date, and location of corrected record.

35.18.2.2 Public corrections must not disclose restricted telemetry, personal data, protected knowledge, public authority-sensitive information, cyber-sensitive details, market-sensitive information, capital-reader materials, insurance-reader materials, handoff-only materials, legal-hold materials, or investigation-sensitive information.

35.18.2.3 Public corrections should be distributed through proportionate channels, especially where the original overclaim spread through public dashboards, media, sponsor materials, provider materials, participant statements, or public reports.

### 35.18.3 Integrity Archive Records

35.18.3.1 Integrity Archive Records should identify affected object, incident type, correction action, public notice, controlled record, restricted record if applicable, score effect, recognition effect, Grid effect, Rails effect, handoff effect, recurrence prevention, closure status, and archive reference.

35.18.3.2 Archive records must distinguish active, corrected, held, invalidated, withdrawn, reinstated, retired, and historical records.

### 35.18.4 Archive Boundary

35.18.4.1 Public correction preserves public trust; archive preserves institutional memory.

35.18.4.2 Neither public correction nor archive creates external legal findings unless a competent external process separately does so.

## 35.19 Repeat-Offender Controls

### 35.19.1 Repeat-Offender Function

35.19.1.1 **Repeat-Offender Controls** govern participants, teams, sponsors, providers, maintainers, contributors, Competence Cells, national teams, Foundry Programs, BuildGrid workstreams, or other actors that repeatedly breach integrity, anti-cheating, telemetry, benchmark, data, model, compute, external-call, sponsor-advantage, contribution-integrity, public-claim, or boundary rules.

35.19.1.2 Repeat-offender status exists to protect Nexus from actors who create recurring record risk, not merely to punish isolated mistakes.

35.19.1.3 Repeat-offender controls may apply even where prior incidents were corrected, if the pattern shows recurring disregard for evidence truth, disclosure, review, correction, or boundary discipline.

### 35.19.2 Repeat-Offender Criteria

35.19.2.1 Repeat-offender assessment may consider number of incidents, severity, recurrence, similarity, intent, responsiveness, correction quality, cooperation with audit, public impact, downstream impact, sponsor or provider involvement, data sensitivity, safety impact, cyber impact, public authority impact, capital impact, insurance impact, community safeguard impact, and handoff impact.

35.19.2.2 Repeat-offender classification should be proportionate and reviewable.

35.19.2.3 A participant that self-reports, cooperates, corrects promptly, and prevents recurrence may be treated differently from a participant that conceals, repeats, obstructs, or overclaims.

### 35.19.3 Repeat-Offender Measures

35.19.3.1 Measures may include heightened audits, pre-validation review, access limits, telemetry requirements, independent review, sponsor support limits, provider support limits, challenge restrictions, recognition restrictions, Grid restrictions, Rails restrictions, handoff restrictions, participation suspension, disqualification, or termination of participation.

35.19.3.2 Repeat-offender status may also affect future eligibility for Foundry Programs, BuildGrid Bounties, Nexus Core validation, Competence Cell roles, sponsor roles, provider roles, reviewer roles, maintainer roles, or public recognition.

### 35.19.4 Repeat-Offender Records

35.19.4.1 Repeat-Offender Records should identify actor, incidents, pattern, review basis, measures imposed, duration, conditions for removal, correction status, and archive reference.

35.19.4.2 Repeat-offender records may be public-safe, controlled, restricted, legal-hold, or archive-only depending on sensitivity and fairness requirements.

## 35.20 Integrity Register

### 35.20.1 Integrity Register Function

35.20.1.1 **Integrity Register** is the authoritative register of integrity-relevant records for Nexus Universe, Nexus Foundry, BuildGrid, Nexus Core, Nexus Grid, Nexus Rails, National Portfolios, public dashboards, recognition records, public-safe reports, Marketplace listings, Registry entries, handoff packages, and archive.

35.20.1.2 The Integrity Register preserves the system memory of audits, holds, investigations, score invalidations, recognition withdrawals, public corrections, boundary incidents, cheating incidents, telemetry incidents, benchmark leakage, model substitution, dataset substitution, compute substitution, undisclosed intervention, external-call violations, sponsor-assisted advantage, provider-assisted advantage, Foundry integrity issues, BuildGrid contribution issues, and repeat-offender controls.

35.20.1.3 The Integrity Register is not a public shaming device. It is a status-truth and correctionability instrument.

### 35.20.2 Register Contents

35.20.2.1 The Integrity Register may include:\
35.20.2.1(a) Anti-Cheating Records;\
35.20.2.1(b) Model Integrity Records;\
35.20.2.1(c) Dataset Integrity Records;\
35.20.2.1(d) Compute Integrity Records;\
35.20.2.1(e) Human Intervention Records;\
35.20.2.1(f) Telemetry Integrity Records;\
35.20.2.1(g) Benchmark Leakage Records;\
35.20.2.1(h) Tool-Use Records;\
35.20.2.1(i) Sponsor-Assisted Advantage Records;\
35.20.2.1(j) Foundry Work Integrity Records;\
35.20.2.1(k) BuildGrid Contribution Integrity Records;\
35.20.2.1(l) Random Audit Records;\
35.20.2.1(m) Targeted Audit Records;\
35.20.2.1(n) Integrity Hold Records;\
35.20.2.1(o) Score Invalidation Records;\
35.20.2.1(p) Recognition Withdrawal Records;\
35.20.2.1(q) Public Correction Records;\
35.20.2.1(r) Repeat-Offender Records;\
35.20.2.1(s) Integrity Archive Records.

35.20.2.2 Register entries should identify affected object, actor category, incident class, status, access class, correction status, public-safe status, downstream records affected, recurrence controls, and archive reference.

### 35.20.3 Register Access and Protection

35.20.3.1 Integrity Register access may be public-safe, expert-visible, controlled, restricted, legal-hold, investigation-only, or archive-only depending on record sensitivity, fairness, privacy, cyber, public authority, protected knowledge, market-sensitive, capital-reader, insurance-reader, and handoff restrictions.

35.20.3.2 The Register must not expose restricted telemetry, personal data, protected knowledge, cyber-sensitive details, public authority-sensitive information, market-sensitive information, confidential sponsor information, confidential provider information, capital-reader materials, insurance-reader materials, legal-hold materials, or handoff-only materials except under authorized access.

35.20.3.3 Public-safe Register summaries may be used where public correction is necessary and restricted details cannot be disclosed.

### 35.20.4 Final Integrity Rule

35.20.4.1 No Nexus Universe result, Foundry output, BuildGrid contribution, Stack Passport, Evidence Pack, telemetry record, score, standing, recognition, Grid input, Rails route, National Portfolio entry, public dashboard, public-safe report, Marketplace listing, Registry entry, handoff package, or archive entry may be treated as trustworthy if its integrity status is unresolved, invalidated, withdrawn, materially corrected, or unsupported.

35.20.4.2 The final integrity rule is that Nexus validates only what can be truthfully recorded. Performance without integrity is not performance; evidence without custody is not evidence; recognition without correctionability is not trust; and continuation without integrity control is not lawful continuation context.


---

# 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/xxxv.-integrity.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.