> 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/acceleration/nexus-campaigns/x.-machines.md).

# X. Machines

## 10.1 AI Governance Foundation

### 10.1.0 Status, Purpose, and Governing Effect

10.1.0.1 This Section establishes the AI Governance Foundation as the Nexus architecture for AI governance principles, AI use cases in Nexus, AI use boundaries, AI authority boundaries, AI in risk intelligence, AI in risk data processing, AI in policy learning, AI in finance-readiness, AI in humanitarian contexts, AI in public authority learning, AI in public-safe reporting, AI in Nexus Core, AI in Nexus Network, AI in Nexus Rails, human oversight requirements, human-in-the-loop review, human-on-the-loop review, and the prohibition on fully autonomous authority claims.

10.1.0.2 This Section shall apply to AI-assisted analysis, machine learning, generative AI, retrieval systems, knowledge graphs, ontologies, simulations, digital twins, decision-support dashboards, automated classification, risk scoring where permitted, data processing, model-assisted reporting, finance-readiness support, insurance-readiness support, humanitarian and crisis-readiness support, public authority learning, Nexus Core workflows, Nexus Network services, Nexus Rails continuation, and public-safe outputs.

10.1.0.3 The AI Governance Foundation shall not be treated as AI certification, regulatory approval, public authority approval, procurement approval, model approval, safety approval, legal compliance approval, professional assurance, investment advice, underwriting, financeability, insurability, public authority determination, humanitarian mandate, protection mandate, emergency authority, or implementation authorization.

10.1.0.4 Nexus may use AI to assist records, not to replace authority. AI may help classify, retrieve, summarize, compare, simulate, detect patterns, flag gaps, label records, support public-safe drafting, generate questions, support technical review, and preserve correction history. AI shall not decide public authority matters, allocate relief, determine rights, approve finance, underwrite insurance, certify systems, approve procurement, replace human judgment, or authorize implementation.

10.1.0.5 AI records shall be governed by purpose, provenance, model cards, dataset cards, decision-use labels, public-safe labels, human oversight, audit logs, safeguards, security review, misuse controls, correction pathways, withdrawal pathways, and Nexus Rails continuation where material.

10.1.0.6 The governing rule of this Section is:

**AI may assist Nexus intelligence and records. AI shall not become the authority, mandate, approval, certification, financier, underwriter, public decision-maker, or implementation actor.**

### 10.1.1 AI Governance Principles

10.1.1.1 AI Governance Principles shall define the minimum doctrine for any AI use in Nexus workflows.

10.1.1.2 AI use shall be:\
a. lawful;\
b. bounded by purpose;\
c. evidence-aware;\
d. human-governed;\
e. privacy-preserving;\
f. security-reviewed;\
g. bias-aware;\
h. explainability-aware;\
i. public-safe;\
j. correction-ready;\
k. non-authoritative unless separately and lawfully authorized;\
l. auditable where material.

10.1.1.3 An AI Governance Principle Record shall identify:\
a. AI system or workflow;\
b. applicable principle;\
c. governing purpose;\
d. human oversight requirement;\
e. data sensitivity;\
f. decision-use label;\
g. public-safe label;\
h. correction pathway;\
i. withdrawal or restriction trigger;\
j. continuation status.

10.1.1.4 AI governance principles shall not be represented as certification, compliance approval, regulatory approval, model approval, public authority approval, procurement approval, financeability, insurability, or implementation authorization.

10.1.1.5 The constitutional rule shall be:

**AI use in Nexus is permitted only where it is lawful, bounded, human-governed, public-safe, auditable where material, and correction-ready.**

### 10.1.2 AI Use Cases in Nexus

10.1.2.1 AI Use Cases in Nexus may include risk signal processing, evidence retrieval, ontology mapping, data-quality review, document summarization, multilingual support, scenario support, model comparison, digital twin support, dashboard assistance, public-safe report drafting, safeguard flagging, finance-readiness question generation, insurance-readiness question generation, audit-log review, and correction tracking.

10.1.2.2 Each AI use case shall be recorded before operational use where the use affects public-safe reporting, technical verification, finance-readiness, insurance-readiness, public authority learning, humanitarian context, community safeguard records, or lawful handoff.

10.1.2.3 An AI Use Case Record shall identify:\
a. use case;\
b. purpose;\
c. users;\
d. data inputs;\
e. model or workflow;\
f. human oversight requirement;\
g. permitted outputs;\
h. prohibited outputs;\
i. decision-use label;\
j. public-safe label;\
k. correction pathway;\
l. continuation status.

10.1.2.4 AI use cases shall not include autonomous public decision-making, autonomous relief allocation, autonomous needs assessment, autonomous protection determination, autonomous finance approval, autonomous underwriting, autonomous procurement approval, autonomous regulatory approval, or autonomous implementation authorization.

10.1.2.5 The constitutional rule shall be:

**An AI use case must be recorded, bounded, and overseen before it influences Nexus outputs.**

### 10.1.3 AI Use Boundaries

10.1.3.1 AI Use Boundaries shall define what an AI system may and may not do within Nexus.

10.1.3.2 AI may assist:\
a. search;\
b. classification;\
c. summarization;\
d. translation support;\
e. metadata extraction;\
f. anomaly detection;\
g. scenario comparison;\
h. public-safe drafting support;\
i. question generation;\
j. record linking;\
k. correction tracking;\
l. audit support.

10.1.3.3 AI shall not autonomously:\
a. grant authority;\
b. approve records;\
c. issue certification;\
d. determine compliance;\
e. allocate relief;\
f. assess official needs;\
g. determine protection status;\
h. decide public finance;\
i. recommend investment;\
j. underwrite insurance;\
k. approve procurement;\
l. authorize implementation.

10.1.3.4 AI Use Boundary Records shall identify:\
a. system or workflow;\
b. permitted uses;\
c. prohibited uses;\
d. data restrictions;\
e. human oversight requirement;\
f. public-safe restriction;\
g. escalation trigger;\
h. correction pathway;\
i. withdrawal condition;\
j. continuation status.

10.1.3.5 The constitutional rule shall be:

**AI may support bounded analysis; it shall not cross into authority, approval, advice, allocation, underwriting, procurement, or execution.**

### 10.1.4 AI Authority Boundary

10.1.4.1 The AI Authority Boundary shall prevent AI outputs, AI labels, AI classifications, AI summaries, AI scores, AI explanations, AI recommendations, AI-generated reports, AI-generated dashboards, and AI-assisted decisions from being treated as authoritative determinations.

10.1.4.2 AI outputs shall remain decision-support artifacts unless a competent human actor or competent institution lawfully adopts a determination within its own mandate.

10.1.4.3 An AI Authority Boundary Record shall identify:\
a. AI output;\
b. affected record or workflow;\
c. authority risk;\
d. decision-use label;\
e. human review requirement;\
f. prohibited interpretations;\
g. public-safe language requirement;\
h. correction pathway;\
i. withdrawal condition;\
j. continuation status.

10.1.4.4 AI shall not be described as deciding, approving, certifying, validating, endorsing, authorizing, underwriting, financing, granting consent, representing public authority, or implementing Nexus activity.

10.1.4.5 The constitutional rule shall be:

**AI may produce outputs. Authority may only arise from lawful human or institutional mandate.**

### 10.1.5 AI in Risk Intelligence

10.1.5.1 AI in Risk Intelligence may support the identification, classification, retrieval, comparison, summarization, clustering, and monitoring of risk signals, hazards, exposures, dependencies, safeguards, scenarios, digital twin outputs, and public-safe risk records.

10.1.5.2 AI-assisted risk intelligence shall be governed by ontology controls, data provenance, dataset cards, model cards, bias notes, uncertainty notes, human review, decision-use labels, public-safe labels, and correction pathways.

10.1.5.3 An AI Risk Intelligence Record shall identify:\
a. risk intelligence purpose;\
b. data inputs;\
c. ontology or taxonomy used;\
d. model or workflow;\
e. output type;\
f. uncertainty;\
g. human review requirement;\
h. public-safe limit;\
i. correction pathway;\
j. continuation status.

10.1.5.4 AI risk intelligence shall not be represented as official finding, public warning, emergency declaration, regulatory determination, public authority position, investment signal, underwriting conclusion, certification, or implementation authorization.

10.1.5.5 The constitutional rule shall be:

**AI may help find and organize risk signals. It does not decide what the risk officially means.**

### 10.1.6 AI in Risk Data Processing

10.1.6.1 AI in Risk Data Processing may support extraction, cleaning, deduplication, classification, entity resolution, metadata generation, quality checks, anomaly detection, data linking, document parsing, geospatial tagging, translation support, and public-safe summarization.

10.1.6.2 AI processing of risk data shall preserve lawful basis, data minimization, provenance, source attribution, access controls, sensitivity labels, audit logs, correction history, and data steward rights.

10.1.6.3 An AI Risk Data Processing Record shall identify:\
a. processing purpose;\
b. data classes;\
c. lawful basis;\
d. data steward;\
e. model or workflow;\
f. processing steps;\
g. quality controls;\
h. sensitivity controls;\
i. human review requirement;\
j. correction pathway;\
k. retention or deletion condition.

10.1.6.4 AI processing shall not authorize unrestricted reuse, model training beyond scope, re-identification, sensitive inference, public disclosure, ownership transfer, finance-readiness use, insurance-readiness use, public authority learning use, or lawful handoff beyond the recorded purpose.

10.1.6.5 The constitutional rule shall be:

**AI may process risk data only within the lawful, recorded, reviewable, and correctable data boundary.**

### 10.1.7 AI in Policy Learning

10.1.7.1 AI in Policy Learning may support comparative review of policy documents, public-safe summaries, evidence mapping, policy-question generation, institutional learning records, crosswalks, scenario notes, and non-prescriptive public authority learning materials.

10.1.7.2 AI-assisted policy learning shall be non-lobbying, non-advocacy unless separately authorized, non-decisional, non-regulatory, non-fiscal-advisory, non-legal-advisory, non-public-authority, and correction-ready.

10.1.7.3 An AI Policy Learning Record shall identify:\
a. policy-learning purpose;\
b. source materials;\
c. model or workflow;\
d. comparative method;\
e. public authority boundary;\
f. lobbying and advocacy boundary;\
g. legal advice boundary;\
h. public-safe label;\
i. human review requirement;\
j. correction pathway.

10.1.7.4 AI shall not generate or present policy learning as official policy advice, lobbying position, regulatory recommendation, legal opinion, fiscal policy advice, debt policy advice, monetary policy advice, public authority determination, or implementation mandate.

10.1.7.5 The constitutional rule shall be:

**AI may support policy learning by record. It shall not become policy advice, lobbying, or public authority judgment.**

### 10.1.8 AI in Finance-Readiness

10.1.8.1 AI in Finance-Readiness may support classification of finance-readiness records, diligence-gap identification, document retrieval, public finance exposure summaries, product-neutral instrument references, capital-readability questions, and lawful handoff preparation.

10.1.8.2 AI-assisted finance-readiness shall remain no-advice, no-offer, no-allocation, no-arrangement, no-rating, no-financeability, no-public-finance-approval, and product-neutral.

10.1.8.3 An AI Finance-Readiness Record shall identify:\
a. finance-readiness purpose;\
b. source records;\
c. model or workflow;\
d. output type;\
e. no-advice boundary;\
f. no-offer boundary;\
g. no-financeability boundary;\
h. human review requirement;\
i. public-safe label;\
j. correction pathway;\
k. continuation status.

10.1.8.4 AI shall not recommend investments, rank instruments, identify buy or sell decisions, advise borrowing, approve finance, determine creditworthiness, determine bankability, determine financeability, arrange transactions, or solicit capital.

10.1.8.5 The constitutional rule shall be:

**AI may make finance-readiness questions easier to read. It shall not advise, arrange, approve, or finance.**

### 10.1.9 AI in Humanitarian Contexts

10.1.9.1 AI in Humanitarian Contexts may support crisis-risk mapping, dependency analysis, public-safe summarization, misinformation detection, language support, scenario comparison, logistics-exposure learning, and lawful handoff where humanitarian safeguards are satisfied.

10.1.9.2 AI use in humanitarian contexts shall require heightened review for humanity, neutrality, impartiality, independence, do-no-harm, protection sensitivity, sensitive population data, humanitarian data responsibility, affected community safeguards, crisis communication boundaries, and non-interference with mandated actors.

10.1.9.3 An AI Humanitarian Context Record shall identify:\
a. humanitarian or crisis purpose;\
b. data sensitivity;\
c. affected population sensitivity;\
d. model or workflow;\
e. protection-sensitive controls;\
f. public authority boundary;\
g. humanitarian mandate boundary;\
h. human review requirement;\
i. publication limits;\
j. correction pathway;\
k. secure handoff condition.

10.1.9.4 AI shall not allocate relief, determine needs, identify beneficiaries, determine protection status, issue public warnings, provide medical instructions, direct operations, replace humanitarian coordination, or create emergency authority unless separately and lawfully mandated.

10.1.9.5 The constitutional rule shall be:

**AI may support crisis-readiness records only where it protects people, mandates, data, and public-safe truth.**

### 10.1.10 AI in Public Authority Learning

10.1.10.1 AI in Public Authority Learning may support the organization of public-safe records, evidence summaries, technical-readiness notes, scenario comparisons, crosswalks, safeguard summaries, and lawful handoff materials for competent public authorities.

10.1.10.2 AI-assisted public authority learning shall be non-authoritative, non-decisional, non-regulatory, non-procurement, non-fiscal-advisory, non-legal-advisory, non-implementation, and boundary-labeled.

10.1.10.3 An AI Public Authority Learning Record shall identify:\
a. public authority learning purpose;\
b. source records;\
c. model or workflow;\
d. public authority boundary;\
e. mandate status;\
f. decision-use label;\
g. public-safe label;\
h. human review requirement;\
i. correction pathway;\
j. continuation status.

10.1.10.4 AI outputs shall not imply government adoption, official position, regulatory approval, public finance approval, procurement approval, public authority mandate, public warning, emergency order, or implementation authorization.

10.1.10.5 The constitutional rule shall be:

**AI may help prepare learning records for public authorities. It shall not speak as a public authority.**

### 10.1.11 AI in Public-Safe Reporting

10.1.11.1 AI in Public-Safe Reporting may support drafting, summarization, translation support, claim checking, boundary-language review, citation mapping, sensitivity flagging, misinformation review, readability, and version comparison for public-safe outputs.

10.1.11.2 AI-assisted public-safe reporting shall require human review before publication where outputs concern public authorities, communities, Indigenous knowledge, humanitarian contexts, finance-readiness, insurance-readiness, security-sensitive issues, health, biodiversity, crisis contexts, or rights-sensitive matters.

10.1.11.3 An AI Public-Safe Reporting Record shall identify:\
a. report or output;\
b. AI role;\
c. source records;\
d. claim boundaries;\
e. sensitivity flags;\
f. human reviewer;\
g. public-safe label;\
h. correction or withdrawal pathway;\
i. publication status;\
j. continuation status.

10.1.11.4 AI-generated text shall not be published as public-safe reporting without review for evidence, authority boundaries, safeguards, privacy, security, misinformation, public-safe language, and correction readiness.

10.1.11.5 The constitutional rule shall be:

**AI may assist public-safe reporting, but humans remain responsible for publication, boundaries, and correction.**

### 10.1.12 AI in Nexus Core

10.1.12.1 AI in Nexus Core may support temporary annual technical intensity, high-performance compute workflows, simulations, digital twins, cyber ranges, model comparison, scenario analysis, anomaly detection, technical demonstrations, and Nexus Universe preparation.

10.1.12.2 AI in Nexus Core shall be governed by access credentials, secure environments, model cards, dataset cards, audit logs, cybersecurity review, dual-use review, output controls, teardown records, correction records, and release controls.

10.1.12.3 An AI Nexus Core Record shall identify:\
a. Core workflow;\
b. AI system or model;\
c. compute environment;\
d. data classes;\
e. access credentials;\
f. security review status;\
g. dual-use review status;\
h. output controls;\
i. teardown or continuation condition;\
j. correction pathway.

10.1.12.4 Nexus Core AI outputs shall not imply system approval, model approval, procurement approval, public authority approval, financeability, insurability, operational readiness, or implementation authorization.

10.1.12.5 The constitutional rule shall be:

**AI in Nexus Core creates temporary technical intensity; it does not create permanent authority or deployment approval.**

### 10.1.13 AI in Nexus Network

10.1.13.1 AI in Nexus Network may support durable federated services, node interoperability, federated analytics, data exchange, metadata processing, identity workflows, secure enclave analysis, compute-to-data workflows, public-safe dashboards, and knowledge graph updates.

10.1.13.2 AI in Nexus Network shall preserve node sovereignty, access control, data protection, auditability, interoperability without equivalence, interoperability without certification, and interoperability without compliance approval.

10.1.13.3 An AI Nexus Network Record shall identify:\
a. network service;\
b. AI workflow;\
c. participating node or system;\
d. federation conditions;\
e. data classes;\
f. access controls;\
g. security review status;\
h. human oversight requirement;\
i. correction pathway;\
j. continuation status.

10.1.13.4 AI-enabled network services shall not imply node certification, system certification, compliance approval, data ownership transfer, public authority approval, procurement approval, financeability, insurability, operational merger, or implementation authorization.

10.1.13.5 The constitutional rule shall be:

**AI in Nexus Network may support federated intelligence, but federation never dissolves ownership, authority, safeguards, or accountability.**

### 10.1.14 AI in Nexus Rails

10.1.14.1 AI in Nexus Rails may support continuation records, correction tracking, supersession mapping, withdrawal detection, archive search, re-entry review, audit-log review, verification receipt indexing, finance-readiness continuity, insurance-readiness continuity, public authority learning continuity, and lawful handoff traceability.

10.1.14.2 AI in Nexus Rails shall preserve status truth, correction history, archive history, withdrawal history, supersession history, access controls, decision-use labels, public-safe labels, and record provenance.

10.1.14.3 An AI Nexus Rails Record shall identify:\
a. Rails workflow;\
b. AI system or workflow;\
c. records affected;\
d. status logic;\
e. correction role;\
f. human oversight requirement;\
g. access control;\
h. public-safe boundary;\
i. audit trail;\
j. continuation status.

10.1.14.4 AI shall not rewrite record history, erase correction records, remove withdrawal status, alter archive status, approve re-entry, approve finance-readiness, approve insurance-readiness, approve public authority status, or authorize implementation.

10.1.14.5 The constitutional rule shall be:

**AI in Nexus Rails may help continue the record; it shall not rewrite, erase, or approve the record.**

### 10.1.15 Human Oversight Requirements

10.1.15.1 Human Oversight Requirements shall define when human review, human approval within Nexus scope, human escalation, human correction, or competent external review is required before AI outputs may be used, published, handed off, or continued.

10.1.15.2 Human oversight shall be required where AI outputs affect:\
a. public-safe reporting;\
b. public authority learning;\
c. humanitarian contexts;\
d. sensitive population data;\
e. community safeguards;\
f. Indigenous knowledge;\
g. finance-readiness;\
h. insurance-readiness;\
i. security-sensitive outputs;\
j. model release;\
k. verification records;\
l. correction, withdrawal, or re-entry status.

10.1.15.3 A Human Oversight Record shall identify:\
a. AI workflow;\
b. oversight requirement;\
c. reviewer role;\
d. review scope;\
e. evidence reviewed;\
f. decision-use effect;\
g. public-safe effect;\
h. correction requirement;\
i. escalation pathway;\
j. continuation status.

10.1.15.4 Human oversight shall not convert AI outputs into public authority decisions, legal advice, investment advice, underwriting, certification, procurement approval, financeability, insurability, or implementation authorization.

10.1.15.5 The constitutional rule shall be:

**Human oversight is required where AI risk affects people, authority, safeguards, finance, insurance, security, or public-safe reporting.**

### 10.1.16 Human-in-the-Loop Review

10.1.16.1 Human-in-the-Loop Review shall mean that a qualified human reviewer must review and approve or reject the AI-assisted output before the output affects a Nexus record, public-safe report, access decision, correction, withdrawal, release, handoff, or publication.

10.1.16.2 Human-in-the-loop review shall be required where AI outputs may materially affect sensitive data, humanitarian context, community safeguards, Indigenous knowledge, public authority learning, finance-readiness, insurance-readiness, security-sensitive outputs, model release, or public-facing claims.

10.1.16.3 A Human-in-the-Loop Review Record shall identify:\
a. AI output reviewed;\
b. reviewer;\
c. reviewer role;\
d. review criteria;\
e. acceptance, rejection, or revision status;\
f. changes made;\
g. decision-use label;\
h. public-safe label;\
i. correction pathway;\
j. continuation status.

10.1.16.4 Human-in-the-loop review shall not be reduced to passive visibility where the reviewer lacks authority, competence, context, time, or access to evidence.

10.1.16.5 The constitutional rule shall be:

**Human-in-the-loop review requires an accountable human decision before the AI-assisted output moves forward.**

### 10.1.17 Human-on-the-Loop Review

10.1.17.1 Human-on-the-Loop Review shall mean that a qualified human reviewer monitors an AI-assisted workflow, reviews outputs by sampling, exception, threshold, escalation, or audit, and intervenes where risk, anomaly, misuse, or correction triggers arise.

10.1.17.2 Human-on-the-loop review may be used only where the AI workflow is low-risk or bounded enough that continuous pre-output review is not required.

10.1.17.3 A Human-on-the-Loop Review Record shall identify:\
a. AI workflow monitored;\
b. reviewer or steward;\
c. monitoring method;\
d. thresholds;\
e. escalation triggers;\
f. audit frequency;\
g. intervention authority;\
h. correction pathway;\
i. restriction or withdrawal condition;\
j. continuation status.

10.1.17.4 Human-on-the-loop review shall not be used for high-risk humanitarian, protection-sensitive, security-sensitive, finance-facing, insurance-facing, public authority-facing, rights-sensitive, or publication-sensitive outputs where human-in-the-loop review is required.

10.1.17.5 The constitutional rule shall be:

**Human-on-the-loop review is monitoring with intervention authority; it is not passive observation.**

### 10.1.18 No Fully Autonomous Authority Claims

10.1.18.1 Nexus shall not claim, allow, or imply that any AI system has fully autonomous authority to make decisions, grant approvals, issue certifications, allocate relief, determine needs, determine rights, approve finance, underwrite insurance, approve procurement, represent public authority, or authorize implementation.

10.1.18.2 Prohibited claims include AI-approved, AI-certified, AI-authorized, AI-mandated, AI-determined, AI-verified as approval, AI-financeable, AI-insurable, AI-procurement-ready, AI-public-authority-approved, AI-relief-eligible, AI-protection-cleared, and equivalent language.

10.1.18.3 A No Fully Autonomous Authority Claim Record shall identify:\
a. AI authority claim or risk;\
b. affected output;\
c. false authority implied;\
d. actual AI role;\
e. required correction;\
f. withdrawal or restriction condition;\
g. public-safe language requirement;\
h. archive condition;\
i. re-entry condition.

10.1.18.4 Any fully autonomous authority claim shall be corrected, restricted, withdrawn, superseded, archived, or re-issued with clear human-governed, non-authoritative, decision-support language.

10.1.18.5 The constitutional rule shall be:

**No AI system in Nexus shall hold or claim fully autonomous authority over people, records, finance, insurance, public authority, rights, procurement, relief, or implementation.**

## 10.2 Model Governance

### 10.2.0 Status, Purpose, and Governing Effect

10.2.0.1 This Section establishes the Model Governance layer as the Nexus architecture for model inventory, model cards, dataset cards, training data records, prompt records, agent records, model risk classification, model use approvals, model limitation records, bias records, explainability requirements, reproducibility controls, model drift monitoring, model performance records, model security review, model release controls, model retirement, model supersession, and model misuse controls.

10.2.0.2 This Section shall apply to AI models, machine learning models, foundation models, generative AI systems, retrieval systems, agentic workflows, simulations, digital twins, scenario models, risk models, climate models, infrastructure models, public finance models, insurance-readiness models, finance-readiness models, humanitarian and crisis models, public-safe reporting workflows, Nexus Core model environments, Nexus Network model services, and Nexus Rails continuation workflows.

10.2.0.3 Model Governance shall not be treated as model certification, AI certification, regulatory approval, public authority approval, procurement approval, legal compliance approval, safety approval, professional assurance, investment advice, underwriting, financeability, insurability, public warning authority, humanitarian mandate, protection mandate, emergency authority, or implementation authorization.

10.2.0.4 Nexus may govern models as decision-support artifacts by recording purpose, data inputs, training data, prompts, agents, limitations, bias risks, explainability, reproducibility, drift, performance, security, release status, retirement, supersession, misuse controls, human oversight, correction pathways, and Nexus Rails continuation. Nexus shall not allow models to act as independent authority.

10.2.0.5 Model records shall be auditable where material, version-controlled, access-bounded, security-reviewed, decision-use-labeled, public-safe-labeled, correction-ready, withdrawal-ready, and continued through Nexus Rails where material.

10.2.0.6 The governing rule of this Section is:

**A model may support Nexus records only when its purpose, data, limits, risks, release conditions, and correction pathway are governed. A model is not authority.**

### 10.2.1 Model Inventory

10.2.1.1 The Model Inventory shall maintain a governed register of models used, tested, referenced, connected, evaluated, deployed, retired, superseded, restricted, or archived within Nexus workflows.

10.2.1.2 The Model Inventory shall include models used in Nexus Core, Nexus Network, Nexus Rails, digital twins, simulations, risk intelligence, public-safe reporting, finance-readiness, insurance-readiness, humanitarian contexts, public authority learning, and secure data rooms where material.

10.2.1.3 A Model Inventory Record shall identify:\
a. model name or identifier;\
b. model class;\
c. steward;\
d. purpose;\
e. workflow or pathway;\
f. model version;\
g. access status;\
h. risk classification;\
i. model card status;\
j. dataset card relationship;\
k. release status;\
l. correction, retirement, or supersession status.

10.2.1.4 Model inventory inclusion shall not imply model approval, certification, public authority approval, procurement approval, financeability, insurability, safety approval, or implementation authorization.

10.2.1.5 The constitutional rule shall be:

**A model inventory records the existence and status of a model; it does not approve the model.**

### 10.2.2 Model Cards

10.2.2.1 Model Cards shall document the purpose, model class, steward, version, inputs, outputs, assumptions, limitations, intended uses, prohibited uses, evaluation status, risk classification, bias notes, explainability notes, security controls, release controls, correction pathway, and continuation status of a model.

10.2.2.2 Model Cards shall be required for models that materially affect public-safe reporting, technical verification, finance-readiness, insurance-readiness, public authority learning, humanitarian contexts, community safeguards, security-sensitive outputs, or lawful handoff.

10.2.2.3 A Model Card shall identify:\
a. model name or identifier;\
b. steward;\
c. purpose;\
d. model version;\
e. data inputs;\
f. assumptions;\
g. limitations;\
h. intended use;\
i. prohibited use;\
j. evaluation status;\
k. human oversight requirement;\
l. release status;\
m. correction or recall pathway;\
n. Nexus Rails continuation status.

10.2.2.4 Model Cards shall not imply model certification, regulatory approval, procurement approval, professional assurance, public authority approval, financeability, insurability, underwriting approval, investment advice, or implementation authorization.

10.2.2.5 The constitutional rule shall be:

**A Model Card explains what a model is, how it may be used, and where it must stop.**

### 10.2.3 Dataset Cards

10.2.3.1 Dataset Cards shall document the source, provenance, steward, lawful basis, coverage, quality, limitations, sensitivity, permitted use, prohibited use, access controls, retention, deletion, public-safe publication limits, and correction pathway of datasets used by or associated with models.

10.2.3.2 Dataset Cards shall be required where datasets support model training, fine-tuning, retrieval, evaluation, benchmarking, simulation, digital twin outputs, public-safe reporting, finance-readiness, insurance-readiness, humanitarian workflows, public authority learning, or lawful handoff.

10.2.3.3 A Dataset Card shall identify:\
a. dataset name or class;\
b. source;\
c. steward;\
d. lawful basis;\
e. provenance and lineage;\
f. coverage;\
g. quality limits;\
h. sensitivity level;\
i. permitted use;\
j. prohibited use;\
k. access controls;\
l. retention and deletion conditions;\
m. model relationship;\
n. correction pathway;\
o. continuation status.

10.2.3.4 Dataset Cards shall not imply data ownership transfer, unrestricted use, official statistics, data certification, regulatory approval, public authority approval, model approval, financeability, insurability, or implementation authorization.

10.2.3.5 The constitutional rule shall be:

**A Dataset Card protects model use by making data origin, limits, rights, and safeguards explicit.**

### 10.2.4 Training Data Records

10.2.4.1 Training Data Records shall document data used to train, fine-tune, adapt, evaluate, benchmark, calibrate, validate, or otherwise improve a model where the data is within Nexus control or relevant to Nexus model governance.

10.2.4.2 Training Data Records shall identify lawful basis, provenance, data categories, sensitivity, exclusions, restricted data, data subject protections, community safeguards, Indigenous knowledge safeguards, security restrictions, retention rules, deletion rules, and downstream model-use restrictions.

10.2.4.3 A Training Data Record shall identify:\
a. model or workflow;\
b. training data source;\
c. data categories;\
d. lawful basis;\
e. data steward;\
f. sensitivity level;\
g. excluded data categories;\
h. permitted use;\
i. prohibited use;\
j. retention or deletion condition;\
k. correction pathway;\
l. continuation status.

10.2.4.4 Training Data Records shall not authorize unrestricted model training, re-identification, sensitive inference, data ownership transfer, public disclosure, or reuse beyond the recorded scope.

10.2.4.5 The constitutional rule shall be:

**Training data may be used only where lawful basis, provenance, safeguards, and downstream limits are recorded.**

### 10.2.5 Prompt Records

10.2.5.1 Prompt Records shall document prompts, system instructions, retrieval instructions, tool-use instructions, safety instructions, boundary instructions, public-safe instructions, role instructions, and workflow prompts where they materially affect Nexus outputs.

10.2.5.2 Prompt Records may apply to generative AI systems, agentic workflows, report drafting, public-safe language review, finance-readiness question generation, insurance-readiness question generation, policy-learning summaries, humanitarian risk summaries, and Nexus Rails correction workflows.

10.2.5.3 A Prompt Record shall identify:\
a. model or workflow;\
b. prompt purpose;\
c. prompt version;\
d. governing instruction;\
e. prohibited outputs;\
f. decision-use labels required;\
g. public-safe labels required;\
h. human review requirement;\
i. access restriction;\
j. correction pathway;\
k. supersession status.

10.2.5.4 Prompt Records shall not be used to conceal unsafe instruction, override safeguards, bypass human review, produce false authority, generate investment advice, generate underwriting conclusions, approve procurement, or authorize implementation.

10.2.5.5 The constitutional rule shall be:

**Prompts are governance objects where they shape model behavior and public-safe outputs.**

### 10.2.6 Agent Records

10.2.6.1 Agent Records shall document AI agents, tool-using workflows, automated workflows, retrieval agents, monitoring agents, audit agents, report-generation agents, correction agents, and other semi-autonomous systems used within Nexus.

10.2.6.2 Agent Records shall identify the agent’s purpose, tools, permissions, data access, action scope, prohibited actions, human oversight, logs, escalation triggers, release controls, and correction pathways.

10.2.6.3 An Agent Record shall identify:\
a. agent name or identifier;\
b. steward;\
c. purpose;\
d. tools available;\
e. data access;\
f. permitted actions;\
g. prohibited actions;\
h. autonomy level;\
i. human oversight requirement;\
j. audit logging;\
k. emergency stop or restriction condition;\
l. correction pathway;\
m. continuation status.

10.2.6.4 Agents shall not autonomously approve records, alter status truth, allocate relief, determine needs, determine rights, approve finance, underwrite insurance, approve procurement, publish public-safe outputs, or authorize implementation.

10.2.6.5 The constitutional rule shall be:

**An AI agent may act only within recorded permissions, oversight, logs, and revocation controls.**

### 10.2.7 Model Risk Classification

10.2.7.1 Model Risk Classification shall classify models and workflows according to potential impact on people, public authority learning, humanitarian contexts, rights, privacy, security, finance-readiness, insurance-readiness, public-safe reporting, critical infrastructure, dual-use risk, and lawful handoff.

10.2.7.2 Model risk classes may include low-risk support, bounded analytical support, sensitive decision-support, high-safeguard workflow, restricted workflow, security-sensitive workflow, prohibited release, retired, and archived.

10.2.7.3 A Model Risk Classification Record shall identify:\
a. model or workflow;\
b. risk class;\
c. classification rationale;\
d. affected users or records;\
e. data sensitivity;\
f. harm pathways;\
g. oversight requirement;\
h. release restriction;\
i. correction pathway;\
j. reclassification trigger;\
k. continuation status.

10.2.7.4 Risk classification shall not imply safety approval, regulatory approval, model certification, procurement approval, financeability, insurability, or implementation authorization.

10.2.7.5 The constitutional rule shall be:

**Model risk classification determines governance controls, not approval status.**

### 10.2.8 Model Use Approvals

10.2.8.1 Model Use Approvals shall record internal authorization to use a model for a specified Nexus workflow, scope, data class, user group, output class, and review condition.

10.2.8.2 A Model Use Approval Record shall identify:\
a. model;\
b. approved Nexus use;\
c. approved users or roles;\
d. approved data classes;\
e. approved output types;\
f. prohibited uses;\
g. human oversight requirement;\
h. review date;\
i. suspension or withdrawal condition;\
j. correction pathway;\
k. continuation status.

10.2.8.3 Model Use Approval is internal and scope-limited. It shall not imply external certification, regulatory approval, public authority approval, procurement approval, legal compliance approval, professional assurance, financeability, insurability, underwriting approval, or implementation authorization.

10.2.8.4 Use outside the approved scope shall be prohibited unless a new or amended Model Use Approval Record is created.

10.2.8.5 The constitutional rule shall be:

**Model use approval authorizes bounded internal use, not external validity or public authority.**

### 10.2.9 Model Limitation Records

10.2.9.1 Model Limitation Records shall document known limits, assumptions, failure modes, uncertainty, bias risks, data gaps, generalization limits, explainability limits, performance limits, temporal limits, geographic limits, sector limits, safety limits, and prohibited-use limits.

10.2.9.2 Model limitations shall be attached to model cards, public-safe reports, finance-readiness notes, insurance-readiness questions, dashboards, digital twins, simulations, and lawful handoff records where material.

10.2.9.3 A Model Limitation Record shall identify:\
a. model or workflow;\
b. limitation type;\
c. affected output;\
d. evidence basis;\
e. user-facing warning;\
f. decision-use effect;\
g. public-safe effect;\
h. required human review;\
i. correction pathway;\
j. continuation status.

10.2.9.4 Model limitations shall not be omitted because they weaken visibility, sponsor value, provider interest, public authority interest, finance-readiness value, or publication appeal.

10.2.9.5 The constitutional rule shall be:

**A model is governed only when its limits are recorded as clearly as its capabilities.**

### 10.2.10 Bias Records

10.2.10.1 Bias Records shall document known, suspected, tested, or reported bias risks in models, datasets, prompts, agent workflows, classifications, outputs, dashboards, public-safe reports, or decision-support materials.

10.2.10.2 Bias may concern geography, language, gender, age, disability, ethnicity, race, religion, migration status, socioeconomic status, data availability, institutional visibility, sector representation, market representation, public authority proximity, or crisis visibility.

10.2.10.3 A Bias Record shall identify:\
a. model or workflow;\
b. bias concern;\
c. affected group, geography, sector, or output where appropriate and safe;\
d. evidence basis;\
e. test method where applicable;\
f. mitigation measure;\
g. human review requirement;\
h. public-safe reporting effect;\
i. correction pathway;\
j. monitoring requirement.

10.2.10.4 Bias records shall not be used to overclaim fairness, eliminate accountability, or imply certification of non-discrimination.

10.2.10.5 The constitutional rule shall be:

**Bias must be recorded, tested where possible, mitigated where necessary, and corrected where it affects trust.**

### 10.2.11 Explainability Requirements

10.2.11.1 Explainability Requirements shall define the minimum level of explanation required for model outputs according to risk class, data sensitivity, public-safe use, human oversight need, and downstream interpretation risk.

10.2.11.2 Explainability may include source references, feature explanations, evidence links, uncertainty notes, method summaries, limitation notes, confidence boundaries, counterfactual notes where appropriate, and human-review notes.

10.2.11.3 An Explainability Requirement Record shall identify:\
a. model or workflow;\
b. output type;\
c. explanation required;\
d. intended user;\
e. decision-use label;\
f. public-safe label;\
g. human review requirement;\
h. limitation disclosure;\
i. correction pathway;\
j. continuation status.

10.2.11.4 Explainability shall not imply correctness, certification, regulatory approval, public authority approval, professional assurance, financeability, insurability, or implementation authorization.

10.2.11.5 The constitutional rule shall be:

**Explainability makes model outputs reviewable; it does not make them authoritative.**

### 10.2.12 Reproducibility Controls

10.2.12.1 Reproducibility Controls shall define whether, how, and by whom model outputs can be reproduced, compared, audited, re-run, validated, challenged, or corrected.

10.2.12.2 Reproducibility may require versioned code, versioned models, dataset references, prompt records, execution logs, environment records, random seed records where applicable, configuration records, and output hashes where appropriate.

10.2.12.3 A Reproducibility Control Record shall identify:\
a. model or workflow;\
b. reproducibility requirement;\
c. datasets or references;\
d. prompts or configuration;\
e. execution environment;\
f. access restrictions;\
g. audit method;\
h. limitations;\
i. correction pathway;\
j. continuation status.

10.2.12.4 Reproducibility controls shall not require disclosure of sensitive data, classified data, defense-sensitive data, personal data, Indigenous knowledge, proprietary information, controlled technology, or security-sensitive material where disclosure would be unlawful or unsafe.

10.2.12.5 The constitutional rule shall be:

**Reproducibility supports trust, but never at the expense of lawful restrictions, security, privacy, or rights.**

### 10.2.13 Model Drift Monitoring

10.2.13.1 Model Drift Monitoring shall identify when model performance, input distributions, outputs, assumptions, context, data sources, hazard patterns, sector conditions, language use, or user behavior changes materially over time.

10.2.13.2 Drift monitoring may apply to risk intelligence, dashboards, classification models, digital twins, simulations, finance-readiness workflows, insurance-readiness workflows, humanitarian workflows, public-safe reporting, and Nexus Rails continuation.

10.2.13.3 A Model Drift Monitoring Record shall identify:\
a. model or workflow;\
b. drift indicator;\
c. monitoring method;\
d. baseline;\
e. threshold;\
f. drift event;\
g. affected outputs;\
h. required review;\
i. correction or retraining pathway;\
j. continuation status.

10.2.13.4 Drift detection shall not automatically authorize model retraining, release, continued use, public reporting, finance-readiness use, insurance-readiness use, public authority learning use, or implementation.

10.2.13.5 The constitutional rule shall be:

**When context changes, the model record must change before trust is extended.**

### 10.2.14 Model Performance Records

10.2.14.1 Model Performance Records shall document evaluation results, test conditions, benchmark limits, error rates, uncertainty, robustness, failure cases, domain limits, user feedback, drift findings, and human-review findings.

10.2.14.2 Model performance shall be assessed in relation to intended Nexus use, prohibited use, public-safe use, data sensitivity, human oversight, and downstream harm risk.

10.2.14.3 A Model Performance Record shall identify:\
a. model or workflow;\
b. evaluation purpose;\
c. test data or reference set;\
d. performance metric;\
e. result;\
f. limitations;\
g. failure cases;\
h. applicable use scope;\
i. human review findings;\
j. correction pathway;\
k. continuation status.

10.2.14.4 Model performance records shall not imply certification, safety approval, regulatory approval, procurement approval, professional assurance, financeability, insurability, or implementation authorization.

10.2.14.5 The constitutional rule shall be:

**Performance records show how a model behaved under defined conditions; they do not approve all uses.**

### 10.2.15 Model Security Review

10.2.15.1 Model Security Review shall identify risks of prompt injection, data leakage, model extraction, inversion, poisoning, evasion, jailbreaks, unauthorized tool use, unsafe agent action, insecure API exposure, insecure deployment, harmful output, dual-use release, and sensitive data exposure.

10.2.15.2 Model Security Review shall apply before release, public-safe publication, Nexus Core use, Nexus Network service use, Nexus Rails continuation, data-room deployment, secure enclave use, or high-safeguard workflow use.

10.2.15.3 A Model Security Review Record shall identify:\
a. model or workflow;\
b. security risks reviewed;\
c. data sensitivity;\
d. tool access;\
e. attack surfaces;\
f. mitigation controls;\
g. release restrictions;\
h. incident response pathway;\
i. correction or recall pathway;\
j. continuation status.

10.2.15.4 Model security review shall not imply cybersecurity certification, regulatory approval, public authority approval, procurement approval, safety approval, financeability, insurability, or implementation authorization.

10.2.15.5 The constitutional rule shall be:

**A model must be reviewed as an attack surface before it is treated as infrastructure.**

### 10.2.16 Model Release Controls

10.2.16.1 Model Release Controls shall govern the release, publication, sharing, deployment, access, documentation, API exposure, weights, prompts, workflows, outputs, evaluations, and derived artifacts of models.

10.2.16.2 Model release may be unrestricted, restricted, staged, access-controlled, redacted, delayed, withdrawn, deprecated, recalled, archived, or prohibited depending on risk classification and review.

10.2.16.3 A Model Release Control Record shall identify:\
a. model or artifact;\
b. release purpose;\
c. release audience;\
d. risk classification;\
e. security review status;\
f. dual-use review status;\
g. data sensitivity;\
h. access conditions;\
i. publication limits;\
j. correction, recall, or withdrawal pathway;\
k. continuation status.

10.2.16.4 Models or artifacts shall not be released where release would reasonably enable offensive cyber use, biological misuse, critical infrastructure compromise, harmful targeting, sanctions evasion, surveillance abuse, privacy breach, market manipulation, or other material harm.

10.2.16.5 The constitutional rule shall be:

**Model release is a governed decision, not a technical default.**

### 10.2.17 Model Retirement

10.2.17.1 Model Retirement shall remove a model from current Nexus use where it is obsolete, unsafe, superseded, unsupported, non-compliant with Nexus governance, affected by unresolved drift, affected by data restrictions, affected by misuse, or no longer fit for its recorded purpose.

10.2.17.2 A Model Retirement Record shall identify:\
a. model;\
b. retirement reason;\
c. affected workflows;\
d. replacement status where applicable;\
e. data and output handling;\
f. public-safe effect;\
g. user notification where appropriate;\
h. archive condition;\
i. re-entry or reinstatement condition;\
j. continuation status.

10.2.17.3 Retired models shall not be used as current, approved, valid, finance-readiness-supporting, insurance-readiness-supporting, public-safe, or implementation-ready models.

10.2.17.4 Retirement shall preserve relevant history, audit logs, model cards, dataset cards, performance records, correction records, and supersession records where lawful and appropriate.

10.2.17.5 The constitutional rule shall be:

**A retired model remains part of the record but no longer part of current use.**

### 10.2.18 Model Supersession

10.2.18.1 Model Supersession shall apply where a model, model version, workflow, prompt set, agent, dataset relationship, evaluation method, or release artifact is replaced by a newer governed version.

10.2.18.2 A Model Supersession Record shall identify:\
a. superseded model or artifact;\
b. replacement model or artifact;\
c. reason for supersession;\
d. affected workflows;\
e. migration conditions;\
f. compatibility limits;\
g. public-safe effect;\
h. archive status;\
i. correction pathway;\
j. continuation status.

10.2.18.3 Supersession shall not erase prior outputs, conceal prior limitations, remove correction history, convert prior outputs into current outputs, or silently migrate decision-use labels.

10.2.18.4 Superseded models and artifacts shall be labeled, restricted, archived, deprecated, or withdrawn according to the governing record.

10.2.18.5 The constitutional rule shall be:

**Model supersession changes current use while preserving the history and limits of prior use.**

### 10.2.19 Model Misuse Controls

10.2.19.1 Model Misuse Controls shall identify, prevent, restrict, report, correct, suspend, withdraw, recall, archive, and control re-entry after suspected or confirmed misuse of models, prompts, agents, outputs, APIs, dashboards, digital twins, simulations, or derived records.

10.2.19.2 Misuse may include unauthorized access, unauthorized deployment, false-authority use, harmful use, prompt abuse, tool abuse, data extraction, privacy breach, security-sensitive disclosure, dual-use misuse, finance-readiness overclaim, insurance-readiness overclaim, public authority overclaim, public-safe label removal, or decision-use label removal.

10.2.19.3 A Model Misuse Control Record shall identify:\
a. model or workflow;\
b. suspected or confirmed misuse;\
c. affected outputs or users;\
d. harm pathway;\
e. evidence status;\
f. immediate restriction required;\
g. correction or withdrawal action;\
h. secure disclosure or escalation pathway;\
i. archive or recall status;\
j. re-entry condition.

10.2.19.4 Model misuse may trigger access suspension, output withdrawal, model recall, model downgrade, release restriction, red-team review, blue-team remediation, public correction, secure disclosure, archive, or exclusion from Nexus systems.

10.2.19.5 The constitutional rule shall be:

**When a model is misused, Nexus must restrict the model, correct the record, and preserve the evidence needed for lawful continuation.**

## 10.3 Algorithmic Assurance

### 10.3.0 Status, Purpose, and Governing Effect

10.3.0.1 This Section establishes the Algorithmic Assurance layer as the Nexus architecture for algorithmic impact review, algorithmic bias review, explainability review, data quality review, synthetic data controls, agentic workflow boundaries, prompt and agent governance, AI output labeling, AI output review, AI output correction, AI-assisted decision-use labels, public-safe AI publishing, AI incident reporting, AI audit trails, and AI assurance without certification unless separately authorized.

10.3.0.2 This Section shall apply to AI systems, machine learning models, generative AI systems, retrieval systems, knowledge graphs, ontologies, decision-support tools, agentic workflows, automated classification systems, simulations, digital twins, dashboards, public-safe reports, finance-readiness workflows, insurance-readiness workflows, humanitarian workflows, public authority learning workflows, Nexus Core environments, Nexus Network services, and Nexus Rails continuation systems.

10.3.0.3 Algorithmic Assurance shall not be treated as AI certification, algorithm certification, model approval, safety approval, regulatory approval, public authority approval, procurement approval, legal compliance approval, professional assurance, investment advice, underwriting, financeability, insurability, public warning authority, humanitarian mandate, protection mandate, emergency authority, or implementation authorization unless separately and lawfully authorized within a documented scope.

10.3.0.4 Nexus may use algorithmic assurance to make AI-assisted records reviewable, explainable where appropriate, bias-aware, data-quality-aware, public-safe, decision-use-labeled, incident-reportable, audit-trailed, correction-ready, withdrawal-ready, and lawfully continuable. Nexus shall not convert assurance review into certification, official approval, regulatory compliance, market approval, procurement approval, or autonomous authority.

10.3.0.5 Algorithmic Assurance records shall be model-linked, dataset-linked, prompt-linked where applicable, agent-linked where applicable, access-controlled, versioned, auditable where material, security-reviewed, human-reviewed where required, correction-ready, and continued through Nexus Rails where material.

10.3.0.6 The governing rule of this Section is:

**Algorithmic assurance makes AI-assisted systems reviewable, bounded, and correctable. It does not certify, approve, authorize, or replace accountable human and institutional judgment.**

### 10.3.1 Algorithmic Impact Review

10.3.1.1 Algorithmic Impact Review shall identify how an AI system, model, algorithm, agent, dashboard, simulation, digital twin, or automated workflow may affect people, institutions, public-safe reporting, public authority learning, humanitarian contexts, finance-readiness, insurance-readiness, safeguards, access, recognition, or lawful handoff.

10.3.1.2 Algorithmic Impact Review shall be required where AI-assisted outputs may affect sensitive data, rights-sensitive records, vulnerable populations, community safeguards, Indigenous knowledge, crisis contexts, public authority learning, finance-readiness, insurance-readiness, security-sensitive outputs, or public-facing claims.

10.3.1.3 An Algorithmic Impact Review Record shall identify:\
a. system or workflow reviewed;\
b. purpose;\
c. affected users, records, people, or institutions where appropriate and safe;\
d. data classes;\
e. impact pathways;\
f. risk classification;\
g. human oversight requirement;\
h. mitigation controls;\
i. decision-use label;\
j. public-safe label;\
k. correction pathway;\
l. continuation status.

10.3.1.4 Algorithmic Impact Review shall not imply approval, certification, legal compliance, public authority determination, procurement readiness, financeability, insurability, underwriting approval, or implementation authorization.

10.3.1.5 The constitutional rule shall be:

**Algorithmic impact review identifies risk and required controls; it does not approve the algorithm or its use beyond scope.**

### 10.3.2 Algorithmic Bias Review

10.3.2.1 Algorithmic Bias Review shall identify known, suspected, tested, reported, or foreseeable bias risks in models, datasets, prompts, agents, classifications, rankings, summaries, translations, dashboards, public-safe reports, and decision-support outputs.

10.3.2.2 Bias review may concern geography, language, gender, disability, age, ethnicity, race, religion, migration status, socioeconomic status, institutional visibility, public authority proximity, data availability, crisis visibility, market visibility, or sector representation.

10.3.2.3 An Algorithmic Bias Review Record shall identify:\
a. system or workflow reviewed;\
b. bias concern;\
c. affected group, geography, sector, or output where appropriate and safe;\
d. evidence basis;\
e. test method where applicable;\
f. mitigation measure;\
g. residual limitation;\
h. human review requirement;\
i. public-safe reporting effect;\
j. correction pathway;\
k. monitoring requirement.

10.3.2.4 Algorithmic Bias Review shall not be represented as proof of fairness, non-discrimination certification, legal compliance approval, regulatory approval, procurement approval, financeability, insurability, or implementation authorization.

10.3.2.5 The constitutional rule shall be:

**Bias review reduces algorithmic harm by record; it does not certify fairness.**

### 10.3.3 Explainability Review

10.3.3.1 Explainability Review shall determine whether an AI-assisted output, model behavior, classification, recommendation-like question, summary, score, label, simulation result, dashboard output, or digital twin output can be sufficiently explained for its intended Nexus use.

10.3.3.2 Explainability Review may require source references, provenance links, feature notes, method summaries, uncertainty notes, limitation notes, confidence boundaries, counterfactual notes where appropriate, human-review notes, and prohibited-use warnings.

10.3.3.3 An Explainability Review Record shall identify:\
a. system or output reviewed;\
b. intended user;\
c. explanation required;\
d. explanation provided;\
e. evidence references;\
f. limitation disclosure;\
g. uncertainty disclosure;\
h. decision-use label;\
i. public-safe label;\
j. correction pathway;\
k. continuation status.

10.3.3.4 Explainability Review shall not imply correctness, certification, regulatory approval, public authority approval, professional assurance, financeability, insurability, procurement approval, or implementation authorization.

10.3.3.5 The constitutional rule shall be:

**Explainability makes algorithmic outputs reviewable; it does not make them authoritative.**

### 10.3.4 Data Quality Review

10.3.4.1 Data Quality Review shall assess the fitness, provenance, completeness, timeliness, consistency, representativeness, sensitivity, uncertainty, lineage, lawful basis, and limitation status of data used in AI-assisted workflows.

10.3.4.2 Data Quality Review shall apply to training data, fine-tuning data, retrieval corpora, evaluation data, benchmark data, simulation inputs, digital twin inputs, public-safe reporting data, finance-readiness records, insurance-readiness records, humanitarian data, and public authority learning records where material.

10.3.4.3 A Data Quality Review Record shall identify:\
a. dataset or data source;\
b. system or workflow using the data;\
c. provenance;\
d. lawful basis;\
e. quality indicators;\
f. coverage limits;\
g. sensitivity level;\
h. known gaps;\
i. permitted use;\
j. prohibited use;\
k. correction pathway;\
l. continuation status.

10.3.4.4 Data Quality Review shall not imply official statistics, data certification, unrestricted use, data ownership transfer, legal compliance approval, public authority approval, financeability, insurability, or implementation authorization.

10.3.4.5 The constitutional rule shall be:

**Data quality review defines fitness for a bounded use; it does not certify data for all uses.**

### 10.3.5 Synthetic Data Controls

10.3.5.1 Synthetic Data Controls shall govern the generation, use, publication, sharing, retention, labeling, evaluation, and correction of synthetic data used in AI-assisted Nexus workflows.

10.3.5.2 Synthetic data may be used only where it is lawful, purpose-bounded, appropriately labeled, non-deceptive, privacy-aware, security-reviewed where material, and not used to fabricate evidence, replace real consent, obscure uncertainty, or create false authority.

10.3.5.3 A Synthetic Data Control Record shall identify:\
a. synthetic data purpose;\
b. generating system or method;\
c. source data relationship where applicable;\
d. privacy risk;\
e. re-identification risk;\
f. representativeness limits;\
g. labeling requirement;\
h. permitted use;\
i. prohibited use;\
j. publication limit;\
k. correction pathway;\
l. continuation status.

10.3.5.4 Synthetic data shall not be presented as real evidence, official data, community testimony, field data, human-subject data, public authority data, finance-readiness evidence, insurance-readiness evidence, or verification evidence unless the synthetic status is explicit and the use is lawful and bounded.

10.3.5.5 The constitutional rule shall be:

**Synthetic data may support testing and learning only when it is clearly labeled, bounded, and never mistaken for real-world evidence.**

### 10.3.6 Agentic Workflow Boundaries

10.3.6.1 Agentic Workflow Boundaries shall define what AI agents, tool-using systems, automated workflows, retrieval agents, monitoring agents, audit agents, report agents, correction agents, and orchestration agents may do within Nexus.

10.3.6.2 Agentic workflows shall be governed by purpose, permitted tools, prohibited tools, permitted actions, prohibited actions, data access, output controls, human oversight, audit logs, escalation triggers, emergency stop controls, correction pathways, and revocation controls.

10.3.6.3 An Agentic Workflow Boundary Record shall identify:\
a. agent or workflow;\
b. purpose;\
c. tools available;\
d. data access;\
e. permitted actions;\
f. prohibited actions;\
g. autonomy level;\
h. human oversight requirement;\
i. audit logging;\
j. stop or restriction trigger;\
k. correction pathway;\
l. continuation status.

10.3.6.4 Agentic workflows shall not autonomously approve records, alter status truth, allocate relief, determine needs, determine rights, approve finance, underwrite insurance, approve procurement, publish public-safe outputs, transfer restricted data, or authorize implementation.

10.3.6.5 The constitutional rule shall be:

**Agentic workflows may execute bounded tasks; they shall not exercise autonomous authority.**

### 10.3.7 Prompt and Agent Governance

10.3.7.1 Prompt and Agent Governance shall govern system prompts, developer prompts, task prompts, retrieval prompts, tool instructions, agent configurations, safety instructions, boundary instructions, public-safe instructions, and workflow instructions where they materially shape Nexus outputs.

10.3.7.2 Prompt and Agent Governance Records shall identify:\
a. prompt, agent, or workflow;\
b. purpose;\
c. version;\
d. governing instruction;\
e. tools or data access;\
f. prohibited outputs;\
g. required labels;\
h. human review requirement;\
i. security controls;\
j. correction pathway;\
k. supersession status.

10.3.7.3 Prompts and agents shall not be used to bypass safeguards, conceal unsafe instructions, remove decision-use labels, remove public-safe labels, generate false authority claims, provide investment advice, provide underwriting conclusions, approve procurement, or authorize implementation.

10.3.7.4 Prompt and agent changes shall be versioned, reviewed where material, logged, and corrected where unsafe or misleading outputs result.

10.3.7.5 The constitutional rule shall be:

**Prompts and agents are governance objects when they shape algorithmic behavior and public-safe records.**

### 10.3.8 AI Output Labeling

10.3.8.1 AI Output Labeling shall identify whether an output was generated, assisted, classified, summarized, translated, retrieved, ranked, simulated, or transformed by AI.

10.3.8.2 AI Output Labels shall identify:\
a. AI role;\
b. model or workflow where appropriate;\
c. source record relationship;\
d. human review status;\
e. decision-use label;\
f. public-safe label;\
g. limitation note;\
h. prohibited-use note;\
i. correction pathway;\
j. continuation status.

10.3.8.3 AI Output Labeling shall apply before publication, public authority learning use, finance-readiness use, insurance-readiness use, humanitarian use, community-facing use, security-sensitive use, or lawful handoff where material.

10.3.8.4 AI output labels shall not imply certification, approval, authority, accuracy, official status, financeability, insurability, underwriting, investment advice, procurement approval, or implementation authorization.

10.3.8.5 The constitutional rule shall be:

**AI output labeling tells users how the output was produced and how it may not be used.**

### 10.3.9 AI Output Review

10.3.9.1 AI Output Review shall assess AI-assisted outputs for evidence grounding, source accuracy, boundary language, bias, hallucination, data sensitivity, security sensitivity, public-safe status, decision-use status, finance-readiness overclaim, insurance-readiness overclaim, public authority overclaim, and correction readiness.

10.3.9.2 AI Output Review shall be required before public-safe publication where outputs concern public authorities, communities, Indigenous knowledge, humanitarian contexts, finance-readiness, insurance-readiness, security-sensitive issues, health, biodiversity, crisis contexts, or rights-sensitive matters.

10.3.9.3 An AI Output Review Record shall identify:\
a. output reviewed;\
b. AI role;\
c. source records;\
d. reviewer;\
e. review findings;\
f. required changes;\
g. decision-use label;\
h. public-safe label;\
i. publication or restriction status;\
j. correction pathway;\
k. continuation status.

10.3.9.4 AI Output Review shall not be passive visibility. The reviewer must have role authority, competence, context, time, and access to evidence adequate for the review scope.

10.3.9.5 The constitutional rule shall be:

**AI output review is accountable human review before use, publication, or handoff where risk is material.**

### 10.3.10 AI Output Correction

10.3.10.1 AI Output Correction shall apply where an AI-assisted output is inaccurate, unsupported, misleading, biased, unsafe, outdated, authority-confusing, privacy-defective, security-sensitive, finance-readiness-overstated, insurance-readiness-overstated, or public-safe-defective.

10.3.10.2 AI Output Correction Records shall identify:\
a. output corrected;\
b. error or risk identified;\
c. source record relationship;\
d. affected users or records where appropriate;\
e. correction made;\
f. notice requirement where appropriate;\
g. withdrawal or supersession status;\
h. archive condition;\
i. re-entry condition;\
j. continuation status.

10.3.10.3 Correction may include amendment, restriction, relabeling, redaction, aggregation, withdrawal, supersession, public correction notice, model prompt correction, dataset correction, model correction, access restriction, or archive.

10.3.10.4 Corrected AI outputs shall not continue to be used as current, public-safe, verified, finance-ready, insurance-ready, authority-facing, or valid where correction changes the status.

10.3.10.5 The constitutional rule shall be:

**AI output correction protects the record when algorithmic assistance fails.**

### 10.3.11 AI-Assisted Decision-Use Labels

10.3.11.1 AI-Assisted Decision-Use Labels shall identify the permitted and prohibited uses of AI-assisted outputs, including learning-only, restricted review, human-reviewed, public-safe summary, technical-readiness review, finance-readiness review, insurance-readiness review, public authority learning, secure handoff, archive-only, withdrawn, superseded, and prohibited-use status.

10.3.11.2 An AI-Assisted Decision-Use Label Record shall identify:\
a. AI-assisted output;\
b. AI role;\
c. permitted use;\
d. prohibited use;\
e. required human review;\
f. authority boundary;\
g. finance and insurance boundary where applicable;\
h. public-safe status;\
i. correction pathway;\
j. continuation status.

10.3.11.3 AI-assisted decision-use labels shall not convert outputs into advice, approval, certification, official determination, procurement approval, financeability, insurability, underwriting, public warning, protection mandate, or implementation authorization.

10.3.11.4 Decision-use labels shall remain attached when outputs are copied, summarized, transformed, published, handed off, archived, corrected, or superseded.

10.3.11.5 The constitutional rule shall be:

**AI-assisted decision-use labels govern interpretation; they do not grant decision authority.**

### 10.3.12 Public-Safe AI Publishing

10.3.12.1 Public-Safe AI Publishing shall govern any public release of AI-assisted text, images, dashboards, reports, maps, summaries, model outputs, classifications, translations, scenarios, digital twin outputs, or public-facing records.

10.3.12.2 A Public-Safe AI Publishing Record shall identify:\
a. output proposed for publication;\
b. AI role;\
c. source records;\
d. human review status;\
e. evidence status;\
f. sensitivity review status;\
g. authority boundary;\
h. decision-use label;\
i. public-safe label;\
j. correction or withdrawal pathway;\
k. publication status;\
l. continuation status.

10.3.12.3 Public-safe AI publication shall not expose sensitive personal data, sensitive population data, Indigenous knowledge, security-sensitive information, critical infrastructure vulnerabilities, sanctions-sensitive information, controlled technology, confidential commercial information, or unreviewed community information.

10.3.12.4 Public-safe AI publication shall not imply official findings, public authority approval, certification, endorsement, investment advice, underwriting, financeability, insurability, procurement approval, social license, consent, or implementation authorization.

10.3.12.5 The constitutional rule shall be:

**AI-assisted outputs may be published only when evidence, safeguards, labels, and correction pathways are ready for public use.**

### 10.3.13 AI Incident Reporting

10.3.13.1 AI Incident Reporting shall provide a governed pathway for reporting suspected or confirmed AI-related harm, misuse, false authority claims, data leakage, privacy breach, security issue, model failure, bias issue, hallucination, unsafe output, public-safe defect, finance-readiness overclaim, insurance-readiness overclaim, public authority confusion, or prohibited autonomous action.

10.3.13.2 An AI Incident Reporting Record shall identify:\
a. incident type;\
b. model, workflow, agent, or output involved;\
c. affected records, users, people, or institutions where appropriate and safe;\
d. evidence status;\
e. severity;\
f. immediate restriction required;\
g. correction action;\
h. notification or secure disclosure requirement where appropriate;\
i. archive or continuation status;\
j. re-entry condition.

10.3.13.3 AI incident reporting shall protect reporters from retaliation where possible and appropriate, preserve confidentiality where required, and avoid public amplification of harmful methods or unsafe outputs.

10.3.13.4 AI incidents may trigger access suspension, output withdrawal, model recall, model downgrade, prompt correction, agent restriction, security review, red-team review, blue-team remediation, public correction, secure disclosure, archive, or exclusion from Nexus systems.

10.3.13.5 The constitutional rule shall be:

**AI incidents must be reportable, restrictable, correctable, and preserved as part of the record.**

### 10.3.14 AI Audit Trails

10.3.14.1 AI Audit Trails shall record material AI system use, model execution, prompt execution, agent action, tool use, retrieval events, dataset access, output generation, human review, correction, withdrawal, release, archive, and handoff.

10.3.14.2 AI Audit Trail Records shall identify:\
a. AI system or workflow;\
b. event;\
c. actor, agent, or system where appropriate;\
d. timestamp;\
e. input or source record reference where appropriate;\
f. output reference;\
g. decision-use label;\
h. human review status;\
i. correction or withdrawal status;\
j. retention and access controls.

10.3.14.3 AI Audit Trails shall be protected against tampering, unauthorized disclosure, privacy breach, commercial misuse, security misuse, and public-safe misinterpretation.

10.3.14.4 AI Audit Trails shall not require disclosure of sensitive data, classified data, defense-sensitive data, Indigenous knowledge, personal data, controlled technology, confidential commercial information, or security-sensitive details where disclosure would be unlawful or unsafe.

10.3.14.5 The constitutional rule shall be:

**AI audit trails preserve accountability for algorithmic action without making sensitive history public.**

### 10.3.15 AI Assurance Without Certification Unless Separately Authorized

10.3.15.1 AI Assurance Without Certification shall mean that algorithmic impact review, bias review, explainability review, data quality review, output review, incident reporting, audit trails, model cards, dataset cards, and public-safe publishing controls may support trust without constituting certification.

10.3.15.2 AI Assurance Records shall identify:\
a. assurance activity;\
b. system or output reviewed;\
c. scope;\
d. evidence reviewed;\
e. limitations;\
f. human review status;\
g. certification-not-granted status;\
h. public-safe language requirement;\
i. correction pathway;\
j. continuation status.

10.3.15.3 AI assurance shall not be described as certification, accreditation, regulatory approval, procurement approval, safety approval, public authority approval, professional assurance, financeability, insurability, underwriting approval, investment approval, or implementation authorization unless separately and lawfully authorized by a competent actor within a documented scope.

10.3.15.4 Any claim that converts AI assurance into certification or approval shall be corrected, restricted, withdrawn, superseded, archived, or re-issued with clear non-certification language.

10.3.15.5 The constitutional rule shall be:

**AI assurance makes algorithmic systems reviewable and correctable. It does not certify or approve them unless lawful authority expressly grants that function.**


---

# 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/acceleration/nexus-campaigns/x.-machines.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.