> 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/xxvii.-ai.md).

# XXVII. AI

### Summary

* Defines the governance baseline for AI systems used across Nexus Universe.
* Sets controls for agentic AI, human oversight, autonomy limits, and output review.
* Requires traceable records for models, data, prompts, tools, benchmarks, safety, incidents, and correction.

## 27.1 AI Governance Baseline

### 27.1.1 AI Governance Baseline Function

27.1.1.1 **AI Governance Baseline** defines the minimum governance, safety, evidence, oversight, documentation, security, privacy, data, public-safe, correction, and boundary controls required for artificial intelligence systems used, tested, displayed, benchmarked, validated, explained, or routed through Nexus Universe.

27.1.1.2 The AI Governance Baseline applies to foundation models, domain models, agentic AI systems, forecasting systems, optimization systems, decision-support systems, retrieval systems, multimodal systems, simulation-support systems, digital-twin AI, cyber AI, robotics AI, public dashboard AI, translation AI, public-safe reporting AI, BuildGrid AI workflows, Foundry AI builds, Nexus Core AI workloads, and AI components included in any Nexus Stack.

27.1.1.3 AI governance is not a compliance accessory. It is part of evidence integrity. A stack that uses AI without recorded model identity, data provenance, prompt controls, tool-use logs, oversight rules, output review, uncertainty treatment, incident pathway, and correction status cannot be treated as fully evidence-bearing merely because its output appears useful.

### 27.1.2 Baseline Requirements

27.1.2.1 AI systems within Nexus Universe should be governed by recorded purpose, model identity, model version, data sources, data restrictions, model provenance, data provenance, permitted tasks, prohibited tasks, autonomy level, human oversight level, prompt and tool-use controls, evaluation method, benchmark context, safety case, cyber controls, privacy controls, protected knowledge controls, public-safe output rules, incident pathway, correction pathway, and archive status.

27.1.2.2 AI systems must be classified by risk, domain, access class, data sensitivity, public exposure, public authority relevance, capital-readiness relevance, insurance-readiness relevance, community safeguard relevance, protected knowledge exposure, cyber sensitivity, and lawful handoff relevance.

27.1.2.3 AI governance must apply across the full Nexus Universe cycle, including Foundry design, BuildGrid development, Stack Passport submission, Nexus Core integration, benchmark execution, live validation, public dashboarding, public-safe reporting, Grid input review, Rails routing, lawful handoff preparation, correction, withdrawal, teardown, retention, and archive.

### 27.1.3 AI Governance Records

27.1.3.1 AI Governance Records should identify each AI system or component, model identity, model version, provider or maintainer where applicable, intended use, prohibited use, autonomy class, data class, oversight requirement, evaluation status, benchmark status, safety status, cyber status, privacy status, public-safe status, incident history, correction history, and archive reference.

27.1.3.2 AI governance exceptions must be recorded, justified, time-limited, reviewed, and corrected. Unrecorded AI exceptions are not valid exceptions.

### 27.1.4 AI Governance Boundary

27.1.4.1 AI Governance Baseline compliance within Nexus Universe does not create external AI certification, legal compliance approval, regulatory approval, procurement status, financeability, insurance approval, public authority approval, deployment authorization, or execution authority.

27.1.4.2 The AI Governance Baseline governs AI use and validation inside Nexus Universe only.

## 27.2 Agentic AI Controls

### 27.2.1 Agentic AI Control Function

27.2.1.1 **Agentic AI Controls** govern AI systems capable of planning, tool use, multi-step execution, API interaction, code execution, data retrieval, environment interaction, workflow orchestration, autonomous or semi-autonomous decision-support, automated report generation, digital twin operation, cyber workflow support, BuildGrid task execution, Foundry workflow support, or public dashboard assistance.

27.2.1.2 Agentic AI systems require heightened controls because they may act across tools, data, models, repositories, dashboards, rooms, APIs, workflows, and evidence systems. Their risk is not limited to the answer they produce; it includes the actions they take, the tools they invoke, the data they access, the records they modify, and the claims they may cause others to make.

27.2.1.3 Nexus Universe may use agentic AI to support public-good work only where purpose, access, tools, autonomy, supervision, logging, output review, failure mode, and correction pathway are recorded.

### 27.2.2 Agentic AI Requirements

27.2.2.1 Agentic AI systems should have defined task scope, approved tools, prohibited tools, access class, data restrictions, model identity, prompt or instruction class, human oversight level, stop conditions, escalation triggers, output review requirements, execution limits, sandboxing where appropriate, and log retention.

27.2.2.2 Agentic AI systems must not access restricted telemetry, controlled evidence, public authority-sensitive data, protected knowledge, sovereign data, personal data, capital-reader materials, insurance-reader materials, handoff-only materials, credentials, secrets, or privileged systems unless specifically authorized under recorded controls.

27.2.2.3 Agentic AI systems must not make public claims, approve records, alter scores, issue recognition, route Rails, approve Grid inputs, release public dashboards, issue public warnings, make finance statements, make insurance statements, or authorize handoff by default.

### 27.2.3 Agentic AI Records

27.2.3.1 Agentic AI Records should identify agent identity, model, tools, permissions, task scope, autonomy class, oversight rule, logs, outputs, human review status, incidents, corrections, and archive reference.

27.2.3.2 Tool-use logs and action records should be sufficient to reconstruct material AI-assisted actions affecting evidence, dashboards, reports, Grid inputs, Rails routes, or handoff packages.

### 27.2.4 Agentic AI Boundary

27.2.4.1 Agentic AI Controls do not create autonomous authority, certification, public authority approval, procurement status, financeability, insurance approval, public warning, emergency command, deployment authorization, or execution authority.

27.2.4.2 Agentic AI may assist recorded work; it may not become an authority actor.

## 27.3 Human-in-the-Loop and Human-on-the-Loop Rules

### 27.3.1 Human Oversight Function

27.3.1.1 **Human-in-the-Loop and Human-on-the-Loop Rules** define when human review, approval, supervision, intervention, monitoring, or stop authority is required for AI systems used in Nexus Universe.

27.3.1.2 Human oversight is required because AI outputs can be plausible but wrong, incomplete, biased, unsafe, overconfident, context-insensitive, privacy-invasive, protected-knowledge-exposing, cyber-sensitive, or boundary-violating. Oversight ensures that AI remains a tool of recorded public-good work rather than an unaccountable decision surface.

27.3.1.3 Human oversight must be real, competent, role-recorded, timely, and capable of stopping, correcting, limiting, withdrawing, or escalating AI outputs or actions.

### 27.3.2 Oversight Classes

27.3.2.1 **Human-in-the-loop** oversight requires human review or approval before the AI output, action, publication, routing, or record change takes effect.

27.3.2.2 **Human-on-the-loop** oversight permits AI operation under continuous or periodic human supervision, with monitoring, intervention, stop conditions, and post-action review.

27.3.2.3 Higher-risk AI use should require human-in-the-loop oversight, including public authority-facing outputs, public-safe reports, public dashboards, protected knowledge handling, rights-bearing data handling, cyber-sensitive outputs, capital-readiness outputs, insurance-readiness outputs, scoring support, recognition support, Grid input support, Rails routing support, and handoff package support.

### 27.3.3 Oversight Records

27.3.3.1 Human Oversight Records should identify AI system, oversight class, human reviewer or role, review point, approval status, intervention status, override record, escalation record, correction status, and archive reference.

27.3.3.2 Where AI output is rejected, modified, limited, or corrected by human review, the record should preserve the review basis where material to evidence integrity.

### 27.3.4 Oversight Boundary

27.3.4.1 Human oversight does not convert AI output into certification, public authority approval, procurement status, financeability, insurance approval, public warning, emergency command, deployment authorization, or execution authority.

27.3.4.2 Oversight improves governance of AI-assisted work; it does not enlarge the authority of the output.

## 27.4 Autonomy Boundary Controls

### 27.4.1 Autonomy Boundary Function

27.4.1.1 **Autonomy Boundary Controls** define the limits on what AI systems may do without human approval, including limits on tool use, data access, API calls, code execution, publication, dashboard changes, repository changes, scoring support, recognition support, public authority-facing outputs, capital-readiness materials, insurance-readiness materials, community safeguard outputs, and handoff package preparation.

27.4.1.2 Autonomy boundaries prevent AI systems from crossing from assistance into unauthorized action, decision, publication, routing, claim-making, or execution.

27.4.1.3 AI autonomy within Nexus Universe must be bounded by recorded purpose, role, access class, risk class, tool permissions, output review, and stop conditions.

### 27.4.2 Autonomy Levels

27.4.2.1 AI autonomy may be classified as:\
27.4.2.1(a) **assistive**, where AI drafts, summarizes, searches, or suggests under human review;\
27.4.2.1(b) **supervised operational**, where AI performs defined workflow steps under monitoring and logged controls;\
27.4.2.1(c) **controlled agentic**, where AI uses approved tools within sandboxed, limited, logged, and reviewable conditions;\
27.4.2.1(d) **restricted or prohibited**, where AI use is not permitted without separate authority due to sensitivity, safety, rights, cyber, protected knowledge, or public authority implications.

27.4.2.2 Autonomous publication, autonomous scoring, autonomous recognition, autonomous Grid input approval, autonomous Rails routing, autonomous public authority advice, autonomous finance-readiness conclusions, autonomous insurance-readiness conclusions, autonomous public warning, autonomous emergency command, and autonomous handoff approval are prohibited by default.

27.4.2.3 Autonomy levels must be recorded in Stack Passports, AI Governance Records, Model Cards, System Cards, and relevant Evidence Packs.

### 27.4.3 Autonomy Boundary Records

27.4.3.1 Autonomy Boundary Records should identify AI system, permitted autonomy level, prohibited actions, approved tools, review points, stop conditions, incidents, overrides, corrections, and archive reference.

27.4.3.2 Boundary breaches must trigger incident response, containment, correction, downstream record review, and archive update.

### 27.4.4 Autonomy Boundary

27.4.4.1 AI autonomy does not create authority to decide, approve, certify, procure, finance, insure, warn, command, deploy, or execute.

27.4.4.2 AI systems may operate only within recorded autonomy boundaries.

## 27.5 Hallucination and Error Management

### 27.5.1 Hallucination and Error Function

27.5.1.1 **Hallucination and Error Management** governs the identification, prevention, review, correction, limitation, disclosure, and archive treatment of AI-generated errors, unsupported statements, false citations, fabricated data, misread evidence, incorrect summaries, wrong classifications, unsafe recommendations, boundary overclaims, missing uncertainty, and misleading public-safe outputs.

27.5.1.2 AI error is not only a technical defect. In Nexus Universe, AI error can become evidence error, dashboard error, public-safe reporting error, public authority confusion, finance-readiness overclaim, insurance-readiness overclaim, community safeguard failure, protected knowledge exposure, or lawful handoff defect.

27.5.1.3 AI outputs must be treated as reviewable artifacts, not self-validating truth.

### 27.5.2 Error Controls

27.5.2.1 AI-generated outputs should be reviewed against source records, evidence, telemetry, benchmark results, data provenance, public-safe rules, protected knowledge restrictions, public authority boundaries, capital-readiness boundaries, insurance-readiness boundaries, and community safeguard rules.

27.5.2.2 AI systems should identify uncertainty, confidence limits where appropriate, source dependency, unsupported gaps, and assumptions. Where the AI cannot verify a statement from records, the output should not be treated as evidence.

27.5.2.3 AI outputs must not invent Stack Passport data, Evidence Pack findings, benchmark results, scores, recognition records, Grid inputs, Rails routes, handoff statuses, public authority positions, capital-reader positions, insurance-reader positions, community consent, or sponsor permissions.

### 27.5.3 Error Records

27.5.3.1 Hallucination and Error Records should identify AI system, output affected, error type, source discrepancy, reviewer, correction action, affected downstream records, public-safe notice status, and archive reference.

27.5.3.2 Recurrent AI errors should trigger model-use review, prompt review, tool-use review, output gate modification, or suspension.

### 27.5.4 Error Management Boundary

27.5.4.1 Correction of AI error does not create certification, public authority approval, procurement status, financeability, insurance approval, deployment authorization, or execution authority.

27.5.4.2 It restores the integrity of AI-assisted records only.

## 27.6 Model Cards

### 27.6.1 Model Card Function

27.6.1.1 **Model Cards** are structured records describing AI models used, tested, displayed, benchmarked, integrated, or evaluated within Nexus Universe. They provide model identity, purpose, version, provenance, capabilities, limitations, data dependencies, evaluation context, safety constraints, intended uses, prohibited uses, uncertainty, and correction history.

27.6.1.2 Model Cards are required because a model cannot be responsibly assessed if its identity, version, training context, domain limits, evaluation status, data restrictions, safety posture, and correction status are unknown.

27.6.1.3 Model Cards must be linked to Stack Passports, Benchmark Cards, System Cards, Evidence Packs, AI Safety Cases, prompt and tool-use logs where applicable, and public-safe outputs where relevant.

### 27.6.2 Model Card Contents

27.6.2.1 A Model Card should include model name, model version, provider or maintainer where applicable, model type, modality, intended use, prohibited use, known limitations, evaluation results, benchmark context, training data summary where available and permissible, fine-tuning status, retrieval dependencies, data restrictions, safety controls, bias and fairness considerations where relevant, cyber considerations, privacy considerations, protected knowledge restrictions, public-safe use status, incident history, correction history, and archive reference.

27.6.2.2 Where full model information is unavailable due to proprietary or restricted conditions, the Model Card must state the limitation and identify what evidence is missing.

27.6.2.3 Public Model Cards may be public-safe derivatives of controlled Model Cards where details are restricted.

### 27.6.3 Model Card Correction

27.6.3.1 Model Cards must be corrected when model version changes, provider status changes, evaluation results change, limitations are discovered, incidents occur, safety controls change, data restrictions change, public-safe status changes, or model use is withdrawn.

27.6.3.2 Model Card corrections must propagate to Stack Passports, System Cards, Benchmark Cards, Evidence Packs, dashboards, public-safe reports, Grid inputs, Rails routes, and handoff packages where affected.

### 27.6.4 Model Card Boundary

27.6.4.1 A Model Card does not create certification, regulatory approval, procurement status, financeability, insurance approval, public authority approval, deployment authorization, or execution authority.

27.6.4.2 It documents model context and limitations only.

## 27.7 Model Inventory

### 27.7.1 Model Inventory Function

27.7.1.1 **Model Inventory** is the register of AI models used, tested, displayed, evaluated, integrated, benchmarked, or referenced within Nexus Universe, including foundation models, domain models, fine-tuned models, retrieval-augmented systems, agentic systems, forecasting models, optimization models, simulation models, computer vision models, language models, multimodal models, cyber models, digital twin models, and embedded models within Nexus Stacks.

27.7.1.2 The Model Inventory prevents hidden model substitution, unrecorded model use, unsupported model claims, unmanaged model drift, and unclear accountability.

27.7.1.3 No AI-enabled Nexus Stack should enter validation without an adequate model inventory appropriate to the stack class and access class.

### 27.7.2 Inventory Contents

27.7.2.1 The Model Inventory should identify model name, version, provider or maintainer, deployment context, stack relationship, Foundry origin where applicable, BuildGrid relationship where applicable, model class, risk class, access class, data dependencies, evaluation status, Model Card status, Benchmark Card relationship, System Card relationship, permitted uses, prohibited uses, incident history, correction status, and archive reference.

27.7.2.2 The inventory should distinguish production-like models, experimental models, sandbox models, public-good models, proprietary models, open-source models, hosted models, local models, sovereign models, and external API models.

27.7.2.3 Model substitution, model update, fine-tuning change, retrieval index change, or system prompt change that materially affects output must be recorded.

### 27.7.3 Inventory Records

27.7.3.1 Model Inventory Records should be linked to relevant Stack Passports, Evidence Packs, Model Cards, System Cards, Benchmark Cards, prompt logs, tool-use logs, public-safe outputs, incident records, and correction records.

27.7.3.2 Inventory gaps must be treated as evidence gaps.

### 27.7.4 Model Inventory Boundary

27.7.4.1 Model Inventory listing does not create approval, certification, procurement status, financeability, insurance approval, public authority approval, deployment authorization, or execution authority.

27.7.4.2 Listing records model presence only.

## 27.8 Benchmark Cards

### 27.8.1 Benchmark Card Function

27.8.1.1 **Benchmark Cards** are structured records describing the benchmark, workload, mission cycle, dataset, simulation, test harness, digital twin context, cyber exercise, public explanation task, interoperability test, or evaluation method used to assess a model, AI system, agentic workflow, or AI-enabled stack.

27.8.1.2 Benchmark Cards are necessary because AI performance claims are meaningless without benchmark context. A score or result must be tied to what was tested, under what conditions, with what data, what version, what limitations, and what review status.

27.8.1.3 Benchmark Cards should be linked to Model Cards, System Cards, Stack Passports, Evidence Packs, telemetry records, Proof Receipts, public dashboards, scoring records, and correction records.

### 27.8.2 Benchmark Card Contents

27.8.2.1 A Benchmark Card should identify benchmark name, version, purpose, domain, workload, dataset or synthetic data basis, evaluation method, scoring method, constraints, assumptions, access class, public-safe status, known limitations, leakage controls, overfitting controls, uncertainty treatment, reviewer status, telemetry requirements, correction status, and archive reference.

27.8.2.2 For AI systems, Benchmark Cards should identify whether evaluation covered accuracy, reliability, uncertainty handling, robustness, adversarial behavior, hallucination risk, bias risk, privacy risk, data boundary compliance, protected knowledge risk, cyber risk, human oversight, autonomy behavior, and public-safe explanation quality.

27.8.2.3 Benchmark Cards must identify whether the benchmark is public, controlled, restricted, sovereign, protected, cyber-sensitive, public authority-sensitive, or handoff-only.

### 27.8.3 Benchmark Card Correction

27.8.3.1 Benchmark Cards must be corrected when benchmark data changes, leakage is discovered, scoring changes, evaluation methods change, limitations are discovered, benchmark conditions are violated, or results are reinterpreted.

27.8.3.2 Benchmark corrections must propagate to scores, standings, recognition, Evidence Packs, Stack Cards, public dashboards, Grid inputs, Rails routes, and handoff packages where affected.

### 27.8.4 Benchmark Card Boundary

27.8.4.1 A Benchmark Card does not create certification, standards conformance, procurement status, financeability, insurance approval, public authority approval, deployment authorization, or execution authority.

27.8.4.2 It documents evaluation context only.

## 27.9 AI Safety Cases

### 27.9.1 AI Safety Case Function

27.9.1.1 **AI Safety Cases** are structured records demonstrating how an AI system, AI-enabled stack, agentic workflow, model, public dashboard AI, decision-support system, or AI-assisted handoff package has identified, mitigated, monitored, and bounded relevant safety risks for its Nexus Universe use.

27.9.1.2 AI Safety Cases are required where AI behavior could affect public-safe reporting, public authority learning, rights-bearing data, protected knowledge, cyber security, physical systems, digital twins, robotics, field systems, capital-readiness materials, insurance-readiness materials, community safeguards, or lawful handoff context.

27.9.1.3 An AI Safety Case is not a guarantee of safety. It is a recorded argument, supported by evidence, limitations, controls, monitoring, and correction pathways.

### 27.9.2 Safety Case Contents

27.9.2.1 An AI Safety Case should identify system purpose, AI components, model inventory, autonomy class, intended uses, prohibited uses, hazard analysis, failure modes, hallucination risks, bias risks where relevant, privacy risks, protected knowledge risks, cyber risks, human oversight rules, monitoring rules, stop conditions, incident pathway, correction pathway, public-safe output controls, and archive reference.

27.9.2.2 AI Safety Cases should identify what evidence supports the safety posture, what remains uncertain, what has not been tested, what assumptions are required, and what conditions invalidate the safety case.

27.9.2.3 Safety Cases should be reviewed before Nexus Core validation where AI risk is material.

### 27.9.3 Safety Case Correction

27.9.3.1 AI Safety Cases must be corrected when model behavior changes, model version changes, data changes, benchmark results change, incidents occur, hazards are discovered, autonomy boundaries change, oversight changes, or public-safe output risks change.

27.9.3.2 A materially defective AI Safety Case may trigger safety hold, integrity hold, score hold, recognition hold, Grid hold, Rails hold, handoff hold, withdrawal, or archive restriction.

### 27.9.4 AI Safety Case Boundary

27.9.4.1 An AI Safety Case does not create safety certification, regulatory approval, procurement status, financeability, insurance approval, public authority approval, deployment authorization, or execution authority.

27.9.4.2 It records a bounded safety argument only.

## 27.10 AI Cybersecurity Controls

### 27.10.1 AI Cybersecurity Control Function

27.10.1.1 **AI Cybersecurity Controls** govern threats arising from or affecting AI systems within Nexus Universe, including prompt injection, data poisoning, model poisoning, tool hijacking, agentic misuse, retrieval manipulation, model extraction, prompt leakage, training data leakage, adversarial inputs, unsafe code generation, insecure plugins, unauthorized API calls, credential exposure, model supply-chain risk, and AI-assisted cyber misuse.

27.10.1.2 AI cybersecurity is both a stack security issue and an evidence integrity issue. If the AI system can be manipulated, the evidence it produces or supports may become unreliable.

27.10.1.3 AI cybersecurity controls apply to Foundry AI builds, BuildGrid AI workflows, Nexus Core AI systems, public dashboards, controlled evidence systems, data rooms, cyber ranges, digital twins, public-safe reporting workflows, and handoff packages.

### 27.10.2 AI Cybersecurity Requirements

27.10.2.1 AI cybersecurity controls should include prompt injection testing where relevant, retrieval-source controls, tool permission limits, API permission limits, secrets isolation, input validation, output review, model supply-chain review, dependency review, red-team testing where appropriate, logging, anomaly detection, sandboxing, and incident response.

27.10.2.2 AI systems must not be permitted to access secrets, credentials, restricted repositories, protected knowledge, public authority-sensitive systems, data rooms, or handoff materials unless specifically authorized under strong controls.

27.10.2.3 AI-generated code, configuration, scripts, or cyber outputs must be reviewed before use in Nexus Universe systems or public-good releases.

### 27.10.3 AI Cybersecurity Records

27.10.3.1 AI Cybersecurity Records should identify AI system, threat model, controls, testing, incidents, vulnerabilities, corrections, unresolved risks, and archive reference.

27.10.3.2 AI cybersecurity incidents must be linked to affected Model Cards, System Cards, Evidence Packs, dashboard outputs, Grid inputs, Rails routes, and handoff packages where applicable.

### 27.10.4 AI Cybersecurity Boundary

27.10.4.1 AI Cybersecurity Controls do not create cybersecurity certification, regulatory approval, procurement status, financeability, insurance approval, public authority approval, public warning, deployment authorization, or execution authority.

27.10.4.2 They protect AI systems and AI-supported records only.

## 27.11 Prompt, Tool, and Agent Log Controls

### 27.11.1 Log Control Function

27.11.1.1 **Prompt, Tool, and Agent Log Controls** govern the capture, classification, storage, review, correction, retention, and archive of prompts, system instructions, tool calls, agent actions, retrieval records, generated outputs, human overrides, model responses, error records, and AI workflow traces.

27.11.1.2 Prompt and tool logs are evidence-bearing because they can show how AI outputs were generated, what data was accessed, what tools were used, what instructions governed the system, what human oversight occurred, and whether the output stayed within boundaries.

27.11.1.3 Prompt and tool logs can also contain sensitive information. They must be protected according to data classification, privacy, protected knowledge, public authority sensitivity, cyber sensitivity, and handoff restrictions.

### 27.11.2 Log Requirements

27.11.2.1 Logging should capture material prompts, instruction versions, retrieved sources, tool calls, API calls, data access, model version, output version, reviewer actions, human overrides, stop events, incident events, and correction events where relevant to evidence integrity.

27.11.2.2 Logs must not be automatically public. Public-safe derivatives may be produced only after review.

27.11.2.3 Logs involving protected knowledge, rights-bearing data, public authority-sensitive information, restricted telemetry, cyber-sensitive content, capital-reader materials, insurance-reader materials, or handoff-only materials must be restricted and subject to retention and deletion rules.

### 27.11.3 Log Records

27.11.3.1 Prompt, Tool, and Agent Log Records should identify AI system, workflow, log type, classification, access class, retention, review status, incidents, corrections, and archive reference.

27.11.3.2 Missing logs for material AI actions may be treated as evidence gaps.

### 27.11.4 Log Control Boundary

27.11.4.1 Prompt, Tool, and Agent Logs do not create certification, public authority approval, procurement status, financeability, insurance approval, public warning, deployment authorization, or execution authority.

27.11.4.2 Logs support reconstruction, review, and correction only.

## 27.12 Verifiable Compute

### 27.12.1 Verifiable Compute Function

27.12.1.1 **Verifiable Compute** is the Nexus Universe discipline through which compute activity used for AI, simulations, benchmarks, digital twins, analytics, public dashboards, Evidence Packs, Grid inputs, Rails routes, and handoff packages may be recorded, attested, reproduced where appropriate, or otherwise made auditable within the limits of security, privacy, proprietary constraints, and public-safe restrictions.

27.12.1.2 Verifiable Compute helps answer whether the claimed computation actually occurred, under what configuration, with what resources, in what environment, using what model, what data, what code, what constraints, and what outputs.

27.12.1.3 Verifiable Compute is central to high-performance stack validation because compute claims can be inflated, hidden, substituted, or misattributed without adequate records.

### 27.12.2 Verifiable Compute Requirements

27.12.2.1 Verifiable Compute may include workload identity, compute environment identity, hardware or accelerator class, software environment, container or runtime record, model version, dataset reference, resource-use record, execution time, logs, hashes, signatures, attestations, telemetry, output checksum, and Evidence Pack linkage.

27.12.2.2 Where confidential, sovereign, or restricted data is involved, Verifiable Compute should preserve computational evidence without exposing raw data.

27.12.2.3 Verifiable Compute should support detection of hidden compute substitution, unrecorded external calls, benchmark gaming, unapproved model changes, and undisclosed resource advantages.

### 27.12.3 Verifiable Compute Records

27.12.3.1 Verifiable Compute Records should identify workload, environment, resources, inputs or input references, outputs, attestations, logs, limitations, reviewer status, correction status, and archive reference.

27.12.3.2 Compute records may be public-safe, expert-visible, controlled, restricted, sovereign, cyber-sensitive, commercial-confidential, handoff-only, or archive-only.

### 27.12.4 Verifiable Compute Boundary

27.12.4.1 Verifiable Compute does not create certification, procurement status, financeability, insurance approval, public authority approval, deployment authorization, or execution authority.

27.12.4.2 It records compute evidence only.

## 27.13 Verifiable Intelligence

### 27.13.1 Verifiable Intelligence Function

27.13.1.1 **Verifiable Intelligence** is the Nexus Universe discipline through which AI outputs, analytic outputs, forecasts, optimizations, recommendations, scenario results, public-safe summaries, digital twin interpretations, decision-support outputs, and agentic workflow outputs are traceable to their sources, models, prompts, tools, data, assumptions, human review, uncertainty, limitations, and correction status.

27.13.1.2 Verifiable Intelligence is required because Nexus Universe must not accept opaque AI-generated claims as evidence merely because they appear sophisticated or useful.

27.13.1.3 Verifiable Intelligence connects model provenance, data provenance, prompt and tool logs, benchmark cards, output review, human oversight, uncertainty labeling, and correction records into a coherent evidence chain.

### 27.13.2 Verifiable Intelligence Requirements

27.13.2.1 Verifiable Intelligence should identify source materials, model identity, model version, prompt or instruction class, retrieval sources, tools used, data restrictions, assumptions, uncertainty, human reviewer, output status, public-safe status, and correction history.

27.13.2.2 AI outputs should be classified as draft, reviewed, evidence-linked, public-safe, controlled, restricted, disputed, corrected, withdrawn, superseded, retired, or archived.

27.13.2.3 Outputs that cannot be traced to adequate sources, logs, or review should not be treated as evidence-bearing outputs.

### 27.13.3 Verifiable Intelligence Records

27.13.3.1 Verifiable Intelligence Records should identify output, AI system, source chain, model chain, tool chain, reviewer, uncertainty, limitations, classification, correction status, and archive reference.

27.13.3.2 Records should preserve enough context to allow later review without exposing restricted content in public.

### 27.13.4 Verifiable Intelligence Boundary

27.13.4.1 Verifiable Intelligence does not create certification, public authority approval, procurement status, financeability, insurance approval, public warning, emergency command, deployment authorization, or execution authority.

27.13.4.2 It makes AI-supported outputs traceable and correctionable only.

## 27.14 Compute Attestation

### 27.14.1 Compute Attestation Function

27.14.1.1 **Compute Attestation** is the record or mechanism by which Nexus Universe confirms, to the extent required and feasible, that a workload ran in a defined compute environment, under defined configuration, using defined resources, with defined software, models, data references, security posture, and output custody.

27.14.1.2 Compute Attestation supports Verifiable Compute, benchmark integrity, resource-use transparency, sovereign compute claims, confidential computing claims, energy-aware compute records, and anti-gaming controls.

27.14.1.3 Attestation may be cryptographic, procedural, telemetry-based, platform-based, reviewer-based, or a combination depending on the environment and risk class.

### 27.14.2 Attestation Requirements

27.14.2.1 Compute Attestation should identify workload, environment, hardware or accelerator class, software stack, container or runtime identity, data reference, model reference, resource allocation, execution period, security state where relevant, output hash or reference, reviewer status, and limitations.

27.14.2.2 Attestation should record whether the compute environment was public cloud, sovereign compute, edge compute, confidential computing, secure enclave, on-premises, HPC, GPU cluster, or other compute class.

27.14.2.3 Where attestation is incomplete, the limitation must be recorded and reflected in evidence quality, scoring, recognition, Grid input, Rails route, and handoff package status where relevant.

### 27.14.3 Attestation Records

27.14.3.1 Compute Attestation Records should identify attestation method, evidence produced, trusted parties where applicable, limitations, disputes, corrections, and archive reference.

27.14.3.2 Attestation failure or dispute may trigger evidence hold, score hold, recognition limitation, Grid hold, Rails hold, or handoff hold.

### 27.14.4 Compute Attestation Boundary

27.14.4.1 Compute Attestation does not create certification, security approval, procurement status, financeability, insurance approval, public authority approval, deployment authorization, or execution authority.

27.14.4.2 It supports evidence about compute conditions only.

## 27.15 Model Provenance

### 27.15.1 Model Provenance Function

27.15.1.1 **Model Provenance** records where an AI model came from, who provided or maintained it, what version was used, what modifications were made, what fine-tuning occurred where known and permissible, what retrieval components were added, what system prompts or operating instructions governed it, what deployment environment was used, and how it changed across the Nexus Universe cycle.

27.15.1.2 Model provenance prevents hidden model substitution, undisclosed version changes, unrecorded fine-tuning, unclear provider dependency, benchmark gaming, and unsupported AI claims.

27.15.1.3 Model provenance is required for AI-enabled Stack Passports, Model Cards, System Cards, Benchmark Cards, Evidence Packs, and public-safe AI outputs.

### 27.15.2 Provenance Requirements

27.15.2.1 Model Provenance Records should identify model name, version, provider or maintainer, license or access status where relevant, deployment location, modification history, fine-tuning status, adapter status, retrieval system relationship, system prompt or instruction class, evaluation history, incident history, correction history, and archive reference.

27.15.2.2 Where model provenance is partially unavailable due to proprietary restrictions, the limitation must be recorded and reflected in evidence quality and public-safe claims.

27.15.2.3 Model changes during validation must be controlled, versioned, and disclosed according to modification windows and benchmark rules.

### 27.15.3 Provenance Correction

27.15.3.1 Model provenance errors must be corrected and propagated to Model Cards, System Cards, Benchmark Cards, Stack Passports, Evidence Packs, public dashboards, scores, recognition, Grid inputs, Rails routes, and handoff packages where affected.

27.15.3.2 Hidden or unauthorized model substitution may trigger integrity hold, score invalidation, recognition withdrawal, disqualification, Grid hold, Rails hold, handoff correction, or archive update.

### 27.15.4 Model Provenance Boundary

27.15.4.1 Model Provenance does not create model approval, certification, procurement status, financeability, insurance approval, public authority approval, deployment authorization, or execution authority.

27.15.4.2 It records model lineage and changes only.

## 27.16 Data Provenance

### 27.16.1 Data Provenance Function

27.16.1.1 **Data Provenance** records the source, lineage, permissions, transformations, classifications, restrictions, quality, limitations, and correction history of data used by AI systems, models, benchmarks, digital twins, simulations, dashboards, public-safe reports, Evidence Packs, Grid inputs, Rails routes, and handoff packages.

27.16.1.2 Data provenance is essential because AI outputs inherit the strengths, gaps, restrictions, errors, biases, permissions, and limitations of the data used to produce them.

27.16.1.3 A model output with unclear data provenance is a limited evidence object.

### 27.16.2 Provenance Requirements

27.16.2.1 Data Provenance Records should identify data source, steward, collection context, permission status, lawful basis where applicable, classification, transformation history, synthetic or real status, public-safe status, protected knowledge status, sovereign data status, rights-bearing data status, quality limitations, bias limitations where relevant, access restrictions, AI-use restrictions, retention, correction history, and archive reference.

27.16.2.2 Data provenance should be maintained for training data where available and permissible, fine-tuning data, retrieval data, benchmark data, evaluation data, simulation data, digital twin data, public dashboard data, and handoff package data.

27.16.2.3 Where full provenance is unavailable, the limitation must be recorded and reflected in claims, scores, recognition, Grid inputs, Rails routes, and handoff packages.

### 27.16.3 Provenance Correction

27.16.3.1 Data provenance errors must be corrected and propagated to affected Model Cards, System Cards, Benchmark Cards, Evidence Packs, dashboards, public-safe reports, scores, recognition, Grid inputs, Rails routes, and handoff packages.

27.16.3.2 Unauthorized data use may trigger incident response, data removal, model or index remediation, score hold, recognition hold, Grid hold, Rails hold, handoff hold, and public-safe notice where required.

### 27.16.4 Data Provenance Boundary

27.16.4.1 Data Provenance does not create consent, publication permission, AI-use permission, public authority approval, procurement status, financeability, insurance approval, deployment authorization, or execution authority.

27.16.4.2 It records data lineage and restrictions only.

## 27.17 Output Review

### 27.17.1 Output Review Function

27.17.1.1 **Output Review** governs the human, technical, public-safe, data, privacy, cyber, protected knowledge, public authority, capital-readiness, insurance-readiness, community safeguard, and lawful handoff review of AI-generated or AI-assisted outputs before they are used as evidence, displayed on dashboards, included in reports, routed to Grid, routed through Rails, or included in handoff packages.

27.17.1.2 AI outputs are not automatically evidence. They become usable only when reviewed, classified, bounded, corrected where necessary, and linked to source records.

27.17.1.3 Output review is required for public-facing AI content and for any AI output that could affect rights, public authority learning, capital-readiness, insurance-readiness, community safeguards, protected knowledge, cyber security, or lawful continuation.

### 27.17.2 Review Requirements

27.17.2.1 Output Review should check source support, factual accuracy, uncertainty, hallucination risk, data classification, protected knowledge risk, privacy risk, cyber risk, public authority boundary risk, capital-readiness boundary risk, insurance-readiness boundary risk, community consent boundary risk, accessibility, public-safe wording, correction status, and downstream use.

27.17.2.2 Review status should classify outputs as draft, reviewed, accepted, accepted with limitations, public-safe, controlled, restricted, rejected, corrected, withdrawn, superseded, retired, or archived.

27.17.2.3 Outputs requiring subject-matter expertise must not be approved by general review alone.

### 27.17.3 Output Review Records

27.17.3.1 Output Review Records should identify output, AI system, source records, reviewer role, review criteria, decision, limitations, corrections, access class, downstream effects, and archive reference.

27.17.3.2 Review gaps must be recorded and may prevent public use, scoring use, Grid use, Rails use, or handoff use.

### 27.17.4 Output Review Boundary

27.17.4.1 Output Review does not create certification, public authority approval, procurement status, financeability, insurance approval, public warning, emergency command, deployment authorization, or execution authority.

27.17.4.2 It determines whether AI output can be used within the recorded Nexus Universe purpose only.

## 27.18 Public-Safe AI Outputs

### 27.18.1 Public-Safe AI Output Function

27.18.1.1 **Public-Safe AI Outputs** are AI-generated or AI-assisted outputs approved for public display, public dashboards, public explainers, public-safe reports, media packages, annual reports, learning materials, translation, accessibility formats, public archive, or other public-facing Nexus Universe surfaces.

27.18.1.2 Public-safe AI outputs must be accurate, source-linked where appropriate, bounded, accessible, non-misleading, privacy-protective, protected-knowledge-safe, public authority-boundary-safe, capital-readiness-boundary-safe, insurance-readiness-boundary-safe, community-consent-boundary-safe, and correctionable.

27.18.1.3 Public-safe status is a reviewed status, not a default status.

### 27.18.2 Public-Safe Requirements

27.18.2.1 Public-safe AI outputs must not include personal data, protected knowledge, restricted telemetry, cyber-sensitive details, public authority-sensitive information, capital-reader materials, insurance-reader materials, trade secrets, handoff-only content, or unreviewed claims.

27.18.2.2 Public-safe AI outputs must not imply certification, public authority approval, procurement status, financeability, bankability, insurance approval, underwriting, rating, guarantee, public warning, emergency command, community consent, Indigenous consent, deployment authorization, or execution authority.

27.18.2.3 AI-assisted translation and simplification must preserve meaning, limitations, boundary notices, correction notices, and public-safe warnings against overinterpretation.

### 27.18.3 Public-Safe AI Output Records

27.18.3.1 Public-Safe AI Output Records should identify output, AI system, source materials, reviewer, public-safe review status, accessibility review, translation status where applicable, limitations, correction status, and archive reference.

27.18.3.2 Public-safe AI outputs must remain linked to correction processes.

### 27.18.4 Public-Safe AI Boundary

27.18.4.1 Public-Safe AI Outputs do not create certification, public authority approval, procurement status, financeability, insurance approval, public warning, community consent, deployment authorization, or execution authority.

27.18.4.2 They communicate reviewed public-safe content only.

## 27.19 Foundry AI Build Controls

### 27.19.1 Foundry AI Build Control Function

27.19.1.1 **Foundry AI Build Controls** govern AI-related work created or prepared through Nexus Foundry, including AI prototypes, domain models, agentic workflows, evaluation tools, AI-enabled dashboards, public-safe reporting tools, digital twin AI, AI benchmark tools, AI safety tools, prompt libraries, retrieval systems, model adapters, AI evidence workflows, and AI handoff package components.

27.19.1.2 Foundry AI builds are upstream but can create downstream risk if unsafe assumptions, unclear data provenance, weak model documentation, protected knowledge exposure, uncontrolled prompts, or unclear autonomy boundaries are carried into BuildGrid, Nexus Core, Grid, Rails, or handoff packages.

27.19.1.3 Foundry AI build work must convert AI ideas into governed AI objects before any validation or public-facing use.

### 27.19.2 Foundry AI Requirements

27.19.2.1 Foundry AI builds should define intended use, prohibited use, model inventory, data provenance, autonomy class, oversight requirements, evaluation plan, benchmark plan, AI Safety Case need, cybersecurity controls, protected knowledge controls, public-safe output rules, release class, and correction pathway.

27.19.2.2 Foundry AI builds involving public authority questions, rights-bearing data, protected knowledge, cyber workflows, public dashboards, capital-readiness outputs, insurance-readiness outputs, or handoff packages require heightened review gates.

27.19.2.3 Sponsor-supported AI builds require conflict review, data access review, public-safe wording review, and no-control discipline.

### 27.19.3 Foundry AI Build Records

27.19.3.1 Foundry AI Build Records should identify Foundry Program, Docket, AI object, model components, data components, contributor roles, review gates, release class, safety status, cyber status, public-safe status, correction status, and archive reference.

27.19.3.2 AI builds that fail review should be returned for correction, restricted, withdrawn, retired, or archived.

### 27.19.4 Foundry AI Build Boundary

27.19.4.1 Foundry AI Build Controls do not create validation, certification, procurement status, financeability, insurance approval, public authority approval, deployment authorization, or execution authority.

27.19.4.2 They prepare AI work for review only.

## 27.20 BuildGrid Agentic Workflow Controls

### 27.20.1 BuildGrid Agentic Workflow Function

27.20.1.1 **BuildGrid Agentic Workflow Controls** govern the use of agentic AI systems in Nexus BuildGrid tasks, Quests, Bounties, Builds, code generation, documentation, testing, data review, model evaluation, dashboard preparation, public-safe report drafting, translation, accessibility review, benchmark preparation, Evidence Pack assembly, Grid component preparation, Rails component preparation, and handoff package preparation.

27.20.1.2 BuildGrid agentic workflows can improve productivity but can also introduce hidden errors, insecure code, license issues, data leakage, protected knowledge exposure, hallucinated records, benchmark contamination, prompt injection, tool misuse, or unreviewed public claims.

27.20.1.3 Agentic AI may support BuildGrid work only when its role is recorded, reviewed, bounded, logged, and correctionable.

### 27.20.2 Workflow Requirements

27.20.2.1 BuildGrid agentic workflows should define task scope, approved tools, prohibited tools, repository access, data access, model identity, prompt or instruction class, output review, maintainer review, security review, license review, public-safe review, and correction pathway.

27.20.2.2 AI-generated code, data transformations, model evaluation scripts, documentation, public-safe summaries, dashboards, or handoff components must be reviewed before acceptance into release classes.

27.20.2.3 Agentic systems must not autonomously merge code, publish outputs, alter records, approve bounties, change release classes, or update public dashboards without recorded human approval.

### 27.20.3 Workflow Records

27.20.3.1 BuildGrid Agentic Workflow Records should identify BuildGrid work object, AI system, tools, prompts or instruction class, outputs, reviewer, accepted changes, rejected changes, incidents, corrections, and archive reference.

27.20.3.2 Where agentic AI contributed materially to an output, the contribution should be recorded in the relevant Build Card, Evidence Pack, or release record where appropriate.

### 27.20.4 BuildGrid Agentic Boundary

27.20.4.1 BuildGrid Agentic Workflow Controls do not create contributor authority, maintainer authority, validation, certification, procurement status, financeability, insurance approval, public authority approval, deployment authorization, or execution authority.

27.20.4.2 Agentic AI assists BuildGrid work; maintainers and reviewers remain responsible for acceptance.

## 27.21 AI Incidents

### 27.21.1 AI Incident Function

27.21.1.1 **AI Incidents** are events in which an AI system, model, agentic workflow, AI-enabled stack, public dashboard AI, reporting AI, translation AI, BuildGrid AI workflow, Foundry AI build, digital twin AI, cyber AI, or AI-assisted handoff component produces, enables, contributes to, or fails to prevent a material error, unsafe output, unauthorized action, data exposure, protected knowledge exposure, public authority overclaim, capital-readiness overclaim, insurance-readiness overclaim, community consent overclaim, cyber issue, privacy issue, benchmark integrity issue, or record integrity issue.

27.21.1.2 AI incidents must be treated as evidence integrity events. They may affect Model Cards, System Cards, Benchmark Cards, Evidence Packs, public dashboards, scores, recognition, Grid inputs, Rails routes, public-safe reports, and handoff packages.

27.21.1.3 AI incidents may occur without malicious intent. Error, hallucination, automation drift, prompt injection, unclear oversight, unrecorded model change, poor data provenance, or misuse of AI outputs can be sufficient.

### 27.21.2 AI Incident Classes

27.21.2.1 AI incident classes may include hallucination incident, unsupported claim incident, false citation incident, data provenance incident, model provenance incident, unauthorized model substitution, unauthorized fine-tuning, unauthorized AI training use, protected knowledge AI exposure, PII exposure, rights-bearing data misuse, prompt injection, tool misuse, agentic overreach, autonomy boundary breach, unsafe recommendation, public dashboard AI error, public-safe report error, translation distortion, benchmark contamination, model leakage, cyber misuse, human oversight failure, capital-readiness overclaim, insurance-readiness overclaim, public authority boundary overclaim, and community consent overclaim.

27.21.2.2 Severity should consider public exposure, affected records, affected persons, protected knowledge risk, public authority sensitivity, cyber risk, privacy risk, safety risk, market sensitivity, downstream dependency effect, reversibility, and recurrence risk.

27.21.2.3 Serious AI incidents may trigger immediate Platform Control action, AI system suspension, dashboard hold, score hold, recognition hold, Grid hold, Rails hold, handoff hold, public-safe notice, or Incident Review Board escalation.

### 27.21.3 AI Incident Records

27.21.3.1 AI Incident Records should identify AI system, model, workflow, output, incident class, affected records, affected downstream uses, severity, containment action, correction action, reviewer, public-safe notice status, recurrence prevention, and archive reference.

27.21.3.2 AI Incident Records should link to Model Cards, System Cards, Benchmark Cards, prompt and tool logs, data provenance records, model provenance records, Evidence Packs, dashboard records, and correction records where applicable.

### 27.21.4 AI Incident Boundary

27.21.4.1 AI Incident Records do not create external legal findings, regulatory findings, procurement decisions, finance decisions, insurance decisions, public authority decisions, public warnings, emergency commands, deployment authorizations, or execution authority.

27.21.4.2 They document, contain, and correct AI-related Nexus Universe incidents.

## 27.22 AI Correction, Withdrawal, and Archive

### 27.22.1 AI Correction Function

27.22.1.1 **AI Correction, Withdrawal, and Archive** governs how Nexus Universe corrects, limits, suspends, withdraws, supersedes, retires, archives, or preserves AI systems, AI outputs, Model Cards, System Cards, Benchmark Cards, AI Safety Cases, prompt logs, tool logs, agent logs, AI-generated public-safe reports, AI dashboard outputs, AI-supported scores, AI-supported recognition records, Grid inputs, Rails routes, and handoff package components.

27.22.1.2 AI correction is a core trust function because AI systems can change quickly, produce subtle errors, and affect many downstream records. A single AI error may propagate across reports, dashboards, translations, summaries, scores, public claims, and handoff materials.

27.22.1.3 AI correction must be record-based, downstream-aware, public-safe, and capable of preserving evidence without exposing restricted content.

### 27.22.2 Correction Actions

27.22.2.1 AI correction actions may include output correction, source correction, prompt correction, tool restriction, model rollback, model replacement, retrieval index correction, training-use suspension, protected knowledge removal, public dashboard correction, report correction, translation correction, Evidence Pack correction, Model Card correction, System Card correction, Benchmark Card correction, AI Safety Case correction, score correction, recognition limitation, Grid hold, Rails hold, handoff correction, public-safe notice, withdrawal, retirement, or archive restriction.

27.22.2.2 Where an AI system is materially unreliable, unsafe, unverifiable, untraceable, boundary-violating, or improperly documented, it may be suspended or withdrawn from Nexus Universe use until corrected.

27.22.2.3 Where AI-generated content has been publicly released, correction must propagate to public dashboards, public reports, media packages, public archives, syndicated content, and public-safe notices where applicable.

### 27.22.3 Withdrawal and Archive

27.22.3.1 AI outputs or AI systems may be withdrawn where correction is insufficient, evidence cannot be verified, data use was unauthorized, protected knowledge was exposed, public-safe status is invalid, model provenance is unreliable, benchmark integrity is compromised, or downstream use would be misleading.

27.22.3.2 AI archive records should preserve model version, output version, prompt and tool logs where retained, source chain, review status, correction status, withdrawal status, supersession status, and access classification.

27.22.3.3 Archive must distinguish current AI outputs from superseded, corrected, withdrawn, retired, or historical outputs.

### 27.22.4 Final AI Rule

27.22.4.1 No AI system, model, agentic workflow, AI output, AI-assisted score, AI-supported recognition, AI dashboard, AI report, AI translation, AI summary, AI Grid input, AI Rails route, or AI handoff component may be treated as authoritative unless it is recorded, source-linked, reviewed, bounded, and correctionable.

27.22.4.2 The final AI rule is that Nexus Universe may use AI to accelerate evidence, learning, validation, public-safe explanation, and lawful continuation context, but AI may not replace evidence, human accountability, public authority, community consent, finance, insurance, certification, procurement, deployment authorization, or execution.


---

# 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/xxvii.-ai.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.