# XI. AI

This section defines AI in Nexus as a governed public-good capability.

It explains how AI systems, models, benchmarks, and agentic workflows are recorded, reviewed, controlled, corrected, and archived. It also sets the core boundary rule: AI may support learning, drafting, review, simulation, intelligence, and handoff context, but it does not become automated authority, certification, procurement, finance, insurance, public authority action, consent, deployment authorization, or execution by implication.

## 11.1 AI Governance Doctrine

### 11.1.1 AI System as Governed Object

An AI system is a governed Nexus object when it is used, reviewed, referenced, integrated, demonstrated, taught, benchmarked, documented, listed, registered, routed, or handed off within Nexus Ecosystem. It may include a model, model wrapper, agent, retrieval workflow, classifier, summarizer, translator, coding assistant, simulation assistant, decision-support workflow, dashboard assistant, Studio assistant, data-room assistant, public-safe reporting assistant, Observatory assistant, DRI assistant, GRIx assistant, Academy tutor, Foundry contributor assistant, Marketplace assistant, Registry assistant, Grid review assistant, Nexus Universe assistant, or handoff-support assistant.

An AI system must not be treated as an invisible tool. Where it affects an object, workflow, output, record, report, dashboard, data transformation, public-safe summary, Studio demonstration, Grid or TRL input, National Portfolio object, Nexus Universe output, Marketplace listing, Registry status, or handoff package, its role should be recorded through AI-use metadata, model records, system records, workflow cards, review records, output records, correction records, and archive records.

An AI system record should identify:

1. system identity, including model, provider where relevant, version where known, deployment context, and steward;
2. system purpose, including summarization, classification, extraction, translation, coding, analysis, simulation, retrieval, visualization, review support, public-safe drafting, workflow routing, or agentic assistance;
3. input classes, including permitted data, prohibited data, protected knowledge exclusions, personal data exclusions, public authority-sensitive exclusions, cyber-sensitive exclusions, and Indigenous protocol-sensitive exclusions where applicable;
4. output classes, including draft, review-support, public-safe candidate, restricted note, dashboard output, report input, learning object, handoff-context note, or archive object;
5. human review requirements, including reviewer class, review gate, output approval, and escalation conditions;
6. runtime controls, including tool permissions, memory behavior, logging, no-write-back rules, no-command rules, no-autonomous-publication rules, no-autonomous-handoff rules, and shutdown pathway;
7. correction and archive controls, including output correction, model-use suspension, workflow recall, public repair, and non-continuation.

An AI system is not authority by default. It may support evidence, learning, routing, review, drafting, simulation, and interpretation. It does not certify, procure, finance, insure, issue public authority action, grant consent, authorize deployment, or execute implementation unless a separate competent actor lawfully adopts and controls that use outside Nexus’s default public-good posture.

### 11.1.2 Model Object as Evidence-Bearing Record

A model object is an evidence-bearing record when its identity, purpose, training or source context where known, input conditions, output conditions, evaluation history, limitations, benchmark results, uncertainty, bias risk, drift risk, data-use restrictions, AI-use restrictions, review status, support status, correction pathway, and archive rule are recorded. A model is not evidence merely because it produces an output. It becomes evidence-bearing only when the conditions under which its outputs may be interpreted are visible.

Model objects may include statistical models, machine-learning models, generative AI models, embedding models, classification models, forecasting-support models, simulation models, risk models, DRI models, Observatory models, digital twin models, language models, computer vision models, geospatial models, cyber models, public-safe reporting models, and model components embedded in agentic workflows.

A model object record should identify:

1. model identity and version, including provider, release, checkpoint, configuration, or deployment context where known;
2. intended use and prohibited use, including whether the model supports learning, review, drafting, classification, simulation, analysis, public-safe summarization, or handoff context;
3. input restrictions, including data class, sensitivity class, rights, AI-use permission, protected knowledge exclusions, personal data exclusions, and room requirements;
4. output interpretation, including confidence limits, uncertainty, review requirements, hallucination risk, bias risk, drift risk, and public-safe limits;
5. evaluation and benchmark records, including what was evaluated, under what conditions, and what the results do not prove;
6. support and lifecycle status, including maintained, unsupported, deprecated, suspended, withdrawn, recalled, archived, or non-continuing;
7. correction pathway, including output correction, model-use restriction, downstream object correction, handoff recall, and archive.

A model object may support evidence, but it does not certify truth. A model score is not public authority classification. A model benchmark is not universal validation. A model output is not investment advice, underwriting, procurement recommendation, public warning, consent record, deployment authorization, or execution instruction. Model evidence must remain bounded by its record.

### 11.1.3 Agentic Workflow as Controlled Runtime Object

An agentic workflow is a controlled runtime object when an AI system can plan, call tools, retrieve information, write files, transform data, generate code, query repositories, update drafts, summarize records, assemble outputs, route objects, prepare reports, support Studio workflows, or assist handoff packages through multiple steps. Agentic workflows require stronger controls than ordinary AI-assisted drafting because they may appear to act.

An agentic workflow should be governed through an Agent Workflow Card or equivalent control record before it is used in Nexus pathways that involve sensitive data, public-safe outputs, repositories, Studio workflows, data rooms, secure rooms, Marketplace listings, Registry records, Grid or TRL inputs, National Portfolio objects, Nexus Universe outputs, or handoff packages.

An agentic workflow record should identify:

1. workflow purpose and scope, including what the agent may do and what it must not do;
2. tools available, including read-only tools, write tools, repository tools, data tools, communication tools, calendar tools, file tools, code tools, browser tools, or API tools;
3. permission boundaries, including no autonomous publication, no autonomous handoff, no autonomous public authority action, no procurement action, no finance action, no insurance action, no consent action, no deployment action, and no execution command;
4. input controls, including prohibited data classes, protected knowledge restrictions, public authority-sensitive restrictions, cyber-sensitive restrictions, and room-only materials;
5. output controls, including draft-only status, human review, public-safe review, source verification, correction, and archive;
6. logging and audit, including prompt record where appropriate, tool-use record, execution note, provenance note, proof receipt, and incident pathway;
7. shutdown controls, including suspension, revocation, recall, correction, and non-continuation.

An agentic workflow may help humans produce disciplined records. It must not become a hidden actor. The more a workflow can do, the more explicit its non-execution controls must be.

### 11.1.4 Model Card as Public-Good Record

A Model Card is a public-good record that describes a model object in a structured, reviewable, interpretable, and correctable form. It helps Nexus participants understand what a model is, what it was designed for, what it may support, what it must not be used for, what data conditions apply, what evaluation has occurred, what limitations remain, and what correction pathway governs it.

A Model Card should identify:

1. model identity, including model name, version, provider or steward, release date where known, and configuration context;
2. model purpose, including intended uses, permitted uses, prohibited uses, and Nexus pathways supported;
3. data context, including known training data context where available, input data restrictions, data-use labels, AI-use labels, privacy limits, protected knowledge exclusions, and jurisdictional restrictions;
4. performance and evaluation context, including benchmarks, test conditions, known strengths, known weaknesses, uncertainty, bias, drift, hallucination, and robustness limits;
5. human review requirements, including output classes requiring review and review gates before publication, listing, registration, Studio use, Grid routing, Nexus Universe use, or handoff;
6. risk controls, including public-safe restrictions, cyber controls, sensitive-use restrictions, no-decision notices, and prohibited deployment claims;
7. lifecycle status, including support class, versioning, correction, suspension, withdrawal, recall, archive, and non-continuation.

A Model Card is not model certification. It is not approval to use the model for public authority action, procurement, finance, insurance, consent, deployment, or execution. It is a public-good record that makes model use legible and correctable.

### 11.1.5 System Card as Public-Good Record

A System Card is a public-good record describing an AI-enabled system as a whole, including models, prompts, tools, data inputs, retrieval sources, APIs, interfaces, workflows, permissions, human review gates, runtime environment, outputs, logs, limitations, risk controls, correction pathways, and archive rules.

A System Card is necessary where a model is only one part of a larger system. A retrieval assistant, public-safe reporting workflow, Studio assistant, data-room assistant, dashboard generator, DRI assistant, Observatory workflow, Registry assistant, Marketplace assistant, Grid support tool, Academy tutor, or handoff-support workflow may depend on model behavior, data access, tool permissions, interface design, human review, and output routing. The system must therefore be governed as a system, not only as a model.

A System Card should identify:

1. system identity and steward;
2. system architecture, including models, tools, APIs, repositories, data sources, retrieval systems, memory, interfaces, and runtime environment;
3. user and participant classes, including contributors, reviewers, learners, public authority learners, Studio users, National Node users, or handoff recipients;
4. input and output classes, including permitted inputs, prohibited inputs, output status, public-safe requirements, and restricted outputs;
5. control points, including human review, access control, logging, output review, no-write-back, no-command, no-autonomous-publication, no-autonomous-handoff, and shutdown;
6. risk and misuse controls, including prompt injection, data leakage, hallucination, bias, cyber risk, public authority overclaim, finance or insurance overclaim, consent overclaim, and deployment overclaim;
7. lifecycle controls, including testing, review, support, correction, suspension, withdrawal, recall, archive, and non-continuation.

A System Card is not system approval or deployment authorization. It records how the AI-enabled system is intended to function and what boundaries govern it. Any operational deployment requires separate competent review and lawful responsibility.

### 11.1.6 Benchmark Card as Public-Good Record

A Benchmark Card is a public-good record describing a benchmark dataset, benchmark task, benchmark method, evaluation environment, scoring approach, limitations, data-use restrictions, AI-use restrictions, sensitivity, public-safe status, and interpretation rules. It prevents benchmark results from being misread as universal validation.

A Benchmark Card should identify:

1. benchmark identity, including name, version, steward, source pathway, and dataset or task relationship;
2. benchmark purpose, including what capability, risk, workflow, model behavior, data quality, public-safe output, Studio function, DRI indicator, GRIx mapping, or software behavior the benchmark examines;
3. coverage and exclusions, including domains, languages, geographies, populations, technologies, hazard classes, data types, or task types included and excluded;
4. data-use and AI-use restrictions, including whether the benchmark may be used for training, fine-tuning, evaluation, publication, redistribution, secure-room review, or handoff context;
5. scoring and interpretation, including metrics, thresholds, uncertainty, confidence, known limitations, bias risks, leakage risks, and overfitting risks;
6. review and lifecycle status, including review state, support class, versioning, correction, supersession, withdrawal, recall, archive, and non-continuation;
7. no-conversion notices, including benchmark-not-certification, benchmark-not-deployment-approval, benchmark-not-public-authority-action, benchmark-not-financeability, and benchmark-not-insurability.

Benchmark performance is evidence under conditions. It is not proof of safety, legal compliance, fairness, security, deployment readiness, procurement readiness, financeability, insurability, public authority approval, consent, or execution authority. The Benchmark Card keeps evaluation honest.

### 11.1.7 Agent Workflow Card as Control Record

An Agent Workflow Card is the control record for an agentic workflow. It states what an AI agent is allowed to do, what tools it may use, what data it may access, what actions it may not take, what outputs require human review, what records must be produced, and how the workflow may be corrected, suspended, recalled, or archived.

An Agent Workflow Card should identify:

1. agent identity and steward;
2. workflow purpose, including drafting, summarization, retrieval, coding, classification, routing, review support, data-room assistance, Studio assistance, public-safe reporting support, or handoff preparation;
3. tool permissions, including read-only, write-limited, repository-limited, data-limited, room-limited, communication-prohibited, publication-prohibited, or handoff-prohibited permissions;
4. data access limits, including open, controlled, restricted, secure-room, data-room, clean-room, compute-to-data, protected knowledge, public authority-sensitive, cyber-sensitive, community-sensitive, Indigenous protocol-sensitive where applicable, or handoff-recipient-only limits;
5. action prohibitions, including no public authority action, no procurement action, no finance action, no insurance action, no donor commitment, no consent action, no deployment action, no operational command, no execution, no autonomous public release, and no autonomous handoff;
6. human review gates, including when a human must review sources, outputs, code, data transformations, public-safe language, boundary notices, Marketplace text, Registry text, Grid outputs, Studio outputs, Reports, National Portfolio materials, Nexus Universe outputs, and handoff packages;
7. logging and proof, including prompts where appropriate, tool calls, source references, execution notes, provenance notes, review records, proof receipts, correction records, and archive rules;
8. incident and shutdown pathway, including misuse, hallucination, data leakage, unauthorized action, public-safe overclaim, cyber issue, correction, suspension, withdrawal, recall, and non-continuation.

An Agent Workflow Card does not authorize the agent to act outside its scope. It is a constraint instrument. It converts agentic capability into governed support rather than unbounded automation.

### 11.1.8 Human Review as Default Control

Human review is the default control for AI outputs that may affect Nexus records, public-safe materials, Reports, Marketplace listings, Registry statuses, Grid and TRL records, Studio workflows, Academy materials, Campaign materials, National Portfolio objects, Nexus Universe outputs, public authority learning materials, finance-readiness materials, insurance-readiness materials, donor-readiness materials, protected knowledge handling, community-sensitive outputs, Indigenous protocol-sensitive outputs where applicable, cyber-sensitive outputs, infrastructure-sensitive outputs, or handoff packages.

Human review should be proportionate to risk. Low-risk drafting assistance may require ordinary editorial review. Public-safe outputs may require public-safe review. Data transformations may require data review. Model outputs used in Grid or TRL context may require evidence and method review. Public authority learning outputs may require public authority boundary review. Finance or insurance outputs may require regulated-perimeter review. Protected knowledge outputs may require appropriate custodial or protocol review. Handoff packages may require recipient-responsibility and no-authority-transfer review.

Human review should examine:

1. source accuracy;
2. hallucination or unsupported claims;
3. missing context;
4. bias or unfair framing;
5. data-use compliance;
6. AI-use compliance;
7. privacy and cyber risk;
8. public-safe language;
9. protected knowledge exposure;
10. public authority overclaim;
11. finance, insurance, procurement, and donor overclaim;
12. consent, deployment, and execution overclaim;
13. correction and archive needs.

Human review is not a symbolic checkbox. It is the governance mechanism that prevents AI assistance from becoming institutional decision by default. A human reviewer must have enough context, competence, authority within Nexus, and access to records to evaluate the output within scope.

### 11.1.9 AI Without Automated Authority by Default

Nexus operates under the doctrine of AI without automated authority by default. AI systems may assist, draft, summarize, classify, retrieve, translate, code, analyze, simulate, visualize, benchmark, route, compare, and prepare outputs within recorded controls. They do not automatically decide, approve, certify, procure, finance, insure, allocate donor support, issue public authority action, determine consent, authorize deployment, complete handoff, or execute implementation.

AI without automated authority means:

1. AI classification is not official classification;
2. AI summarization is not institutional approval;
3. AI risk scoring is not public warning;
4. AI readiness analysis is not Grid certification;
5. AI finance-readiness text is not investment advice;
6. AI insurance-readiness text is not underwriting;
7. AI public authority summary is not public authority decision;
8. AI Marketplace text is not procurement recommendation;
9. AI Registry draft is not status truth until reviewed and recorded;
10. AI Studio output is not deployment authorization;
11. AI handoff draft is not handoff completion;
12. AI community or Indigenous protocol summary where applicable is not consent, rights waiver, or protected knowledge permission.

Where automated decision-making is proposed by a separate competent actor, that actor must establish its own lawful authority, governance, human oversight, contestability where required, auditability, data rights, privacy protections, cybersecurity controls, procurement basis where applicable, public authority basis where applicable, consent basis where applicable, and liability framework. Nexus AI records may inform that process; they do not create it.

The default posture is controlled assistance, not autonomous authority.

### 11.1.10 AI Without Deployment Authorization by Default

Nexus operates under the doctrine of AI without deployment authorization by default. The existence, use, review, demonstration, benchmark, Studio workflow, public-safe summary, Marketplace listing, Registry record, Grid or TRL classification, Nexus Universe presentation, National Portfolio inclusion, or handoff context of an AI system does not authorize live deployment, production use, public authority use, operational use, enterprise implementation, community implementation, infrastructure integration, automated decision-making, or real-world execution.

AI deployment requires separate competent responsibility. A downstream actor considering AI deployment must address technical assurance, security, privacy, data rights, AI-use permission, model risk, bias, drift, human oversight, auditability, incident response, public authority approval where required, procurement where required, finance where required, insurance where required, consent where required, accessibility, safeguards, monitoring, maintenance, rollback, and liability.

AI without deployment authorization means:

1. model card is not deployment approval;
2. system card is not operational authorization;
3. benchmark card is not safety clearance;
4. agent workflow card is not execution mandate;
5. Studio demonstration is not live deployment;
6. Nexus Universe presentation is not market approval;
7. Registry status is not AI certification;
8. Marketplace listing is not procurement or adoption recommendation;
9. Grid or TRL context is not financeability, insurability, or deployment readiness;
10. handoff context is not permission to deploy.

Nexus may produce disciplined AI evidence, AI records, AI review, AI learning, AI workflows, and AI handoff context. It does not authorize AI deployment by implication.

The final AI Governance Doctrine rule is: AI systems are governed objects; models are evidence-bearing records; agents are controlled runtime objects; model, system, benchmark, and workflow cards make AI use legible; human review is the default control; AI may assist Nexus work, but it does not become automated authority, deployment authorization, certification, procurement, finance, insurance, public authority action, consent, or execution by implication.

## 11.2 AI Object Classes

### 11.2.1 Statistical Models

Statistical models are governed AI-adjacent or analytical model objects that use statistical methods to estimate relationships, summarize uncertainty, test hypotheses, classify patterns, infer associations, evaluate risk factors, support DRI indicators, support Observatory analysis, support Reports, support Studio workflows, support National Portfolio analysis, support Grid or TRL context, or support lawful handoff context.

A statistical model may include regression models, survival models, Bayesian models, time-series models, generalized linear models, hierarchical models, causal-inference-support models, spatial models, sampling models, uncertainty models, exposure models, vulnerability models, resilience models, public-health models, finance-readiness assumption models, insurance-readiness exposure models, and other statistical objects used within Nexus.

A Statistical Model Record should identify:

1. model purpose, including the question, pathway, object family, and intended Nexus use;
2. model form, including method, variables, assumptions, parameters, priors where applicable, uncertainty treatment, and estimation approach;
3. data inputs, including source data, processed data, feature sets, data-use labels, AI-use labels, lineage, quality assessment, and sensitivity class;
4. scope and limitations, including population, geography, time period, excluded factors, causal limitations, sampling limitations, missingness, bias, uncertainty, and interpretation boundaries;
5. review status, including evidence review, method review, data review, public-safe review, safeguard review, and public authority, finance, insurance, or handoff-boundary review where relevant;
6. outputs, including estimates, intervals, scores, tables, charts, indicators, dashboards, Reports inputs, Studio outputs, Grid inputs, National Portfolio objects, Nexus Universe outputs, or handoff notes;
7. correction and lifecycle, including versioning, re-estimation, recalibration, correction, suspension, withdrawal, recall, supersession, archive, and non-continuation.

A statistical model is not truth by default. Statistical significance is not public authority action. A risk estimate is not public warning. A regression output is not procurement guidance. A finance-related estimate is not investment advice. An insurance-relevant estimate is not underwriting. A statistical model supports bounded evidence and learning; it does not create certification, consent, deployment authorization, or execution.

### 11.2.2 Machine-Learning Models

Machine-learning models are governed model objects that learn patterns from data to classify, predict, cluster, rank, detect anomalies, generate embeddings, recognize images, process language, recommend routing, support dashboards, evaluate objects, support Studio workflows, generate DRI indicators, interpret Observatory signals, support GRIx mappings, assist Reports, support Academy learning, support Grid or TRL inputs, or prepare handoff context.

Machine-learning models may include supervised models, unsupervised models, semi-supervised models, reinforcement-learning models where applicable, neural networks, tree-based models, anomaly-detection models, embedding models, computer-vision models, natural-language models, geospatial models, cyber-detection models, and hybrid models.

A Machine-Learning Model Record should identify:

1. model identity and version, including architecture, source, steward, provider where applicable, and deployment context;
2. training, validation, and evaluation context, including datasets, feature sets, splits, metrics, baselines, benchmark cards, leakage risks, uncertainty, and limitations;
3. data governance, including data-use labels, AI-use labels, rights, sensitivity, privacy, protected knowledge exclusions, Indigenous protocol-sensitive exclusions where applicable, public authority-sensitive exclusions, cyber-sensitive exclusions, and cross-border conditions;
4. intended and prohibited uses, including learning, classification support, review support, Studio use, public-safe drafting, DRI support, Observatory support, Grid support, or handoff context, and excluding automated authority by default;
5. human review and oversight, including output review, escalation, error correction, bias review, drift review, and shutdown conditions;
6. risk controls, including bias, hallucination where generative elements exist, overfitting, drift, adversarial vulnerability, prompt or input manipulation, privacy leakage, and unsafe downstream reliance;
7. lifecycle controls, including retraining, recalibration, support, monitoring, correction, suspension, withdrawal, recall, archive, and non-continuation.

A machine-learning model does not certify its outputs. Model accuracy on a test set is not universal reliability. A prediction is not a public authority decision. A classification is not official status. A model score is not financeability, insurability, procurement status, consent, deployment authorization, or execution instruction. Machine-learning outputs are governed evidence-context objects requiring human and institutional interpretation.

### 11.2.3 Foundation-Model Interfaces

Foundation-model interfaces are governed AI objects that connect Nexus workflows to large-scale pretrained models, including language models, multimodal models, code models, embedding models, vision models, audio models, geospatial foundation models, scientific foundation models, or other general-purpose AI systems accessed through APIs, hosted services, local deployments, controlled environments, or approved tools.

A foundation-model interface is not merely a prompt box. It is an interface between Nexus data, users, workflows, records, and a powerful general-purpose AI capability. It must be governed because it may process sensitive inputs, generate plausible but unsupported outputs, expose data to third-party systems, produce public-safe language, write code, summarize records, classify objects, assist review, support Studio workflows, assist Reports, support Academy objects, or prepare handoff context.

A Foundation-Model Interface Record should identify:

1. model or provider context, including model family, version where known, hosting mode, data retention terms, privacy terms, security terms, logging, and availability of enterprise or controlled configurations;
2. permitted Nexus uses, including drafting, summarization, classification, translation, coding assistance, retrieval assistance, analysis support, public-safe drafting, or review support;
3. prohibited uses, including autonomous decision-making, public authority action, procurement action, finance action, insurance action, consent action, deployment authorization, execution, unrestricted protected knowledge handling, unauthorized personal-data handling, or unauthorized AI training;
4. input restrictions, including no raw restricted data, no protected knowledge, no Indigenous protocol-sensitive data where applicable, no youth or health-sensitive data, no cyber-sensitive data, no public authority-sensitive data, or only room-approved inputs unless expressly permitted;
5. output controls, including human review, source verification, public-safe review, hallucination review, bias review, no-autonomous-publication, no-autonomous-handoff, and correction;
6. records, including AI-use label, prompt or workflow record where appropriate, output record, review record, provenance note, execution note, and archive rule;
7. incident and shutdown controls, including data leakage, unauthorized input, unsupported output, boundary overclaim, model unavailability, provider term change, and correction pathway.

A foundation-model interface may support Nexus productivity and public-good production. It does not create institutional judgment by default. The interface must make the distinction between assistance and authority visible in every high-impact workflow.

### 11.2.4 Fine-Tuned Models

Fine-tuned models are governed model objects adapted from a base model through additional training, instruction tuning, supervised fine-tuning, reinforcement learning from feedback, domain adaptation, adapter layers, retrieval-augmented tuning where applicable, or other parameter-changing methods using Nexus-relevant or third-party data.

Fine-tuned models require heightened governance because the tuning data may carry rights, privacy, protected knowledge, community-sensitive content, Indigenous protocol-sensitive content where applicable, public authority-sensitive information, cyber-sensitive information, infrastructure-sensitive information, or license restrictions. Fine-tuning can also create persistent model behavior that is difficult to reverse fully once embedded.

A Fine-Tuned Model Record should identify:

1. base model identity, including provider, license, version, permitted tuning terms, prohibited uses, and deployment conditions;
2. fine-tuning purpose, including the Nexus pathway, domain, language, task, audience, or controlled workflow supported;
3. tuning data, including source objects, data-use labels, AI-use labels, consent or permission, sensitivity class, exclusions, quality, lineage, protected knowledge controls, and deletion or withdrawal rules;
4. training process, including method, environment, hyperparameters where relevant, compute environment, cross-border controls, logs, and security controls;
5. evaluation and benchmark cards, including performance, limitations, bias, drift, leakage, overfitting, and unsafe-use findings;
6. output and deployment boundaries, including human review, room-only use, public-safe status, no-autonomous-authority, no-deployment-by-default, and prohibited downstream uses;
7. lifecycle controls, including model correction, retraining, data removal feasibility, suspension, withdrawal, recall, archive, and non-continuation.

Fine-tuning is not permission laundering. Data that cannot be used for AI training cannot become lawful tuning data because the model is public-good-oriented. Fine-tuned model status does not create certification, procurement status, financeability, insurability, public authority action, consent, deployment authorization, or execution.

### 11.2.5 Retrieval-Augmented Systems

Retrieval-augmented systems are governed AI systems that combine model generation or reasoning support with retrieval from repositories, data stores, documents, metadata records, Reports, Registry records, Marketplace listings, Studio records, DICE records, GRIx mappings, DRI outputs, Observatory signals, National Portfolio objects, Nexus Universe records, Academy materials, Campaign materials, or handoff packages.

Retrieval-augmented systems are useful because they can ground AI outputs in recorded materials. They are risky because they may retrieve outdated, restricted, superseded, withdrawn, recalled, archive-only, non-public, or context-limited materials and present them as current. They may also expose restricted data, protected knowledge, public authority-sensitive information, or handoff-recipient-only content if access controls are weak.

A Retrieval-Augmented System Record should identify:

1. retrieval corpus, including repositories, records, object classes, access classes, lifecycle states, Registry status, and archive treatment;
2. retrieval permissions, including user-level access, role-based access, room-based access, National Node controls, handoff-recipient controls, and no-cross-boundary retrieval rules;
3. indexing controls, including what may be embedded, what may not be embedded, what may not be retained, what requires compute-to-data, and what must be excluded from AI use;
4. status-truth controls, including priority for current Registry status, correction records, withdrawal notices, recall notices, supersession records, and archive notices;
5. output controls, including citations or source references where appropriate, uncertainty, limitation language, human review, public-safe review, no-autonomous-publication, and correction;
6. security controls, including prompt-injection resistance, source contamination controls, data leakage controls, audit logs, and retrieval traceability;
7. lifecycle controls, including corpus refresh, de-indexing, correction propagation, suspension, archive, and non-continuation.

Retrieval does not make restricted knowledge public. Grounding does not guarantee truth. A retrieved source may be wrong, superseded, or context-bound. Retrieval-augmented output must remain subject to human review and current status truth.

### 11.2.6 Agentic Workflows

Agentic workflows are governed AI runtime objects in which an AI system may perform multi-step tasks, call tools, retrieve records, write or modify files, generate code, inspect repositories, prepare Reports, summarize data-room materials, draft Marketplace listings, draft Registry entries, create Grid inputs, assist Studio workflows, assemble National Portfolio materials, support Nexus Universe production, or prepare handoff-context packages.

Agentic workflows require explicit controls because action-like capabilities can create role confusion. An agent that can write files, update records, send messages, call APIs, run code, or generate handoff materials must be treated as a controlled runtime object, not an ordinary drafting aid.

An Agentic Workflow Record should identify:

1. workflow purpose and scope;
2. agent identity, model dependency, steward, and version;
3. tools and permissions, including read, write, code execution, repository, data, browser, communication, scheduling, API, file, or room tools;
4. data access limits, including open, controlled, restricted, secure-room, data-room, clean-room, compute-to-data, protected knowledge, National Node, public authority-sensitive, or handoff-recipient-only restrictions;
5. prohibited actions, including public authority action, procurement action, finance action, insurance action, donor commitment, consent action, deployment action, operational command, public warning, certification, autonomous publication, autonomous handoff, and execution;
6. human review gates, including source review, output review, public-safe review, code review, data review, AI review, cyber review, Registry review, Marketplace review, Grid review, handoff review, and correction review;
7. logs and proof, including prompt records where appropriate, tool-use records, execution notes, provenance notes, review records, proof receipts, correction records, and archive rules.

Agentic workflow capability must not be mistaken for delegated institutional authority. Agents may support work; they do not become officers, certifiers, procurers, public authorities, finance actors, insurers, consent holders, deployers, or executors.

### 11.2.7 Classifiers

Classifiers are governed AI or statistical objects that assign labels, categories, classes, flags, scores, routes, risk types, sensitivity classes, data-use candidates, AI-use candidates, public-safe review needs, Docket classes, object classes, GRIx categories, DRI categories, Observatory signal classes, Grid readiness indicators, support states, correction triggers, or handoff dependency categories.

Classifiers may support data intake, metadata generation, source review, sensitivity review, public-safe review, Marketplace routing, Registry status drafting, Grid routing, Studio routing, Reports review, Academy routing, Campaign moderation, Observatory triage, DRI categorization, National Portfolio organization, Nexus Universe preparation, and handoff-package review.

A Classifier Record should identify:

1. classification purpose and class taxonomy;
2. input data and permitted input classes;
3. training or rule basis, including dataset, codebook, ontology, model, prompt, rules, or hybrid method;
4. performance and error profile, including false positives, false negatives, bias, uncertainty, threshold behavior, and out-of-scope cases;
5. human review requirement, including when classifier outputs must be confirmed, overridden, escalated, or corrected;
6. use boundaries, including no official classification, no public authority decision, no procurement decision, no finance or insurance determination, no consent determination, no deployment authorization, and no execution;
7. correction and lifecycle, including taxonomy update, model update, threshold update, reclassification, correction propagation, suspension, withdrawal, recall, archive, and non-continuation.

A classifier label is not status truth until recorded through the competent pathway. A classifier may suggest that data is sensitive, but a steward must review. A classifier may suggest a Grid route, but Grid status must be recorded. A classifier may flag public-safe risk, but public-safe review must decide. Classifiers assist routing; they do not decide authority.

### 11.2.8 Forecasting Models

Forecasting models are governed model objects that estimate possible future conditions, trends, risks, needs, signals, demand, capacity, hazards, exposures, resilience indicators, degraded-mode pathways, WFEH-B conditions, public authority learning needs, finance-readiness dependencies, insurance-readiness questions, infrastructure stress, Campaign trajectories, Nexus Universe participation, National Portfolio evolution, or handoff dependencies.

Forecasting models may be statistical, machine-learning-based, simulation-based, hybrid, expert-informed, scenario-based, or digital-twin-linked. Their outputs are especially vulnerable to overclaim because forecasts can be mistaken for official predictions, public warnings, finance signals, insurance triggers, procurement priorities, or operational instructions.

A Forecasting Model Record should identify:

1. forecasting purpose, time horizon, geography, system boundary, and intended audience;
2. input data, including source, quality, lineage, uncertainty, sensitivity, and data-use and AI-use labels;
3. model method, including assumptions, parameters, scenario structure, calibration, validation, uncertainty, and limitations;
4. output form, including forecast intervals, scenarios, likelihood ranges, qualitative projections, or dashboard outputs;
5. public-safe language, including uncertainty, non-warning status, non-official status, and prohibited reliance;
6. review status, including method, evidence, data, AI, public-safe, safeguard, public authority, finance, insurance, and handoff-boundary review where relevant;
7. correction and lifecycle, including recalibration, data update, forecast expiry, withdrawal, recall, supersession, archive, and non-continuation.

A forecast is not a public warning. It is not an official prediction unless a competent public authority separately issues one. It is not a finance signal, insurance trigger, procurement instruction, consent determination, deployment authorization, or execution command. Forecasting models support preparedness and learning under uncertainty.

### 11.2.9 Simulation Models

Simulation models are governed model objects that represent possible behavior of systems, processes, hazards, interventions, infrastructure, WFEH-B systems, digital networks, cyber-physical systems, public authority capacity, finance-readiness dependencies, insurance-readiness dependencies, community impacts, or operational scenarios under defined assumptions.

Simulation models may support Studio workflows, Labs testbeds, DRI analysis, Observatory workflows, digital twin objects, Reports, Academy exercises, National Portfolio preparation, Nexus Universe demonstrations, Grid and TRL context, and handoff-context review.

A Simulation Model Record should identify:

1. simulation question and purpose;
2. system represented and system boundary;
3. model assumptions, parameters, rules, and equations where applicable;
4. input data and sensitivity;
5. scenario classes, including baseline, stress, degraded-mode, intervention, climate, hazard, cyber, infrastructure, WFEH-B, or handoff scenarios;
6. validation, calibration, and uncertainty;
7. output interpretation rules, including what the simulation can and cannot show;
8. review status, including evidence, method, data, AI, public-safe, public authority, safeguard, finance, insurance, and handoff review where relevant;
9. lifecycle controls, including scenario update, model correction, withdrawal, recall, archive, and non-continuation.

A simulation is not reality. It is not a public warning, operational plan, public authority decision, procurement recommendation, finance determination, insurance determination, consent record, deployment authorization, or execution instruction. Its value lies in disciplined exploration of possibilities under recorded assumptions.

### 11.2.10 Digital Twin Models

Digital twin models are governed model objects that represent physical, ecological, infrastructural, technological, institutional, social, or risk systems in dynamic or semi-dynamic digital form. They may be linked to data streams, geospatial layers, sensor signals, simulation models, AI models, dashboards, Studio workflows, Observatory datasets, DRI indicators, National Portfolio objects, Nexus Universe outputs, or handoff-context packages.

Digital twin models may represent cities, ports, corridors, watersheds, WFEH-B systems, telecom networks, AI-RAN/O-RAN/private wireless systems, energy systems, water systems, health systems, logistics networks, biodiversity systems, cyber-physical systems, public services, disaster-risk systems, regional clusters, or National Dense Nexus Cores.

A Digital Twin Model Record should identify:

1. represented system, system boundary, scale, geography, time horizon, and excluded elements;
2. data inputs and update cadence, including sensor data, geospatial data, Earth observation, administrative data, model outputs, assumptions, and public-safe transformations;
3. model structure, including simulation components, AI components, rule-based components, visualization components, uncertainty handling, and scenario logic;
4. sensitivity and access controls, including geospatial, infrastructure, cyber, public authority, community, Indigenous protocol where applicable, protected knowledge, health, youth, and sovereign data concerns;
5. Studio relationship, including controlled runtime environment, user roles, output review, no-command rules, no-write-back rules, and no-deployment rules;
6. review and readiness status, including evidence, method, data, AI, cyber, public-safe, Grid, TRL, and handoff review where relevant;
7. correction and lifecycle, including data update, model update, scenario correction, shutdown, recall, archive, and non-continuation.

A digital twin model is not the real system. It is not operational command. It is not public authority action. It is not deployment authorization. It may support learning, preparedness, scenario exploration, and handoff context only within recorded boundaries.

### 11.2.11 Risk Models

Risk models are governed model objects that estimate, classify, simulate, explain, or compare risk, including hazard risk, exposure risk, vulnerability, resilience, systemic risk, cascading risk, degraded-mode risk, cyber risk, infrastructure risk, climate and nature risk, WFEH-B risk, health-system risk, finance-readiness dependencies, insurance-readiness dependencies, protection gaps, public authority capacity risk, community risk, and handoff dependency risk.

Risk models may support DRI, GRIx, Observatory, Studio, Reports, Risk Academy, National Portfolios, Nexus Universe, Grid and TRL context, capital-reader rooms, insurance-reader rooms, public authority learning rooms, and handoff packages.

A Risk Model Record should identify:

1. risk question and risk taxonomy;
2. hazard, exposure, vulnerability, capacity, resilience, dependency, or scenario categories;
3. data inputs, including quality, uncertainty, sensitivity, lineage, and data-use and AI-use labels;
4. model method, including statistical, machine-learning, simulation, expert-informed, geospatial, scenario, or hybrid method;
5. output classes, including indicators, risk scores, maps, narratives, dashboards, scenarios, dependency notes, or readiness notes;
6. interpretation limits, including non-warning status, non-public-authority status, non-insurance status, non-finance status, and non-procurement status;
7. review status, including evidence, method, data, AI, public-safe, safeguard, finance, insurance, public authority, and handoff review where relevant;
8. correction and lifecycle, including recalibration, downgrade, withdrawal, recall, supersession, archive, and non-continuation.

A Nexus risk model is not a public warning system, insurance rating, investment rating, procurement priority, official classification, compliance finding, consent determination, deployment authorization, or execution instruction by default. It structures risk understanding; it does not decide external action.

### 11.2.12 Optimization Models

Optimization models are governed model objects that search for preferred configurations, allocations, routes, schedules, investments, resource mixes, resilience options, interventions, portfolio compositions, infrastructure placements, logistics paths, energy-water-food-health-biodiversity trade-offs, compute allocations, sensor placements, Campaign resource allocations, Studio scenarios, or handoff dependency pathways under defined objectives and constraints.

Optimization models are particularly vulnerable to overclaim because the word “optimal” can imply decision authority. Nexus optimization outputs must therefore be framed as scenario-support or trade-off-support, not final decisions.

An Optimization Model Record should identify:

1. optimization purpose, objective function, constraints, variables, and decision space;
2. input data, including rights, quality, uncertainty, sensitivity, and data-use and AI-use labels;
3. assumptions and value choices, including weights, trade-offs, exclusions, fairness constraints, safeguard constraints, public authority constraints, finance constraints, insurance constraints, community constraints, and Indigenous protocol-sensitive constraints where applicable;
4. output form, including ranked options, feasible sets, scenarios, trade-off curves, resource suggestions, or dependency notes;
5. human and institutional review, including who must interpret results and what decision rights remain outside Nexus;
6. public-safe and no-conversion notices, including optimization-not-decision, optimization-not-procurement, optimization-not-finance, optimization-not-public-authority-action, optimization-not-consent, and optimization-not-execution;
7. correction and lifecycle, including parameter update, constraint correction, sensitivity analysis, withdrawal, recall, archive, and non-continuation.

Optimization output is not a command. It is not procurement selection, finance allocation, insurance allocation, public finance allocation, public authority decision, community consent, deployment authorization, or execution. It can help reveal trade-offs, not replace governance.

### 11.2.13 Decision-Support Models

Decision-support models are governed model objects that help humans or institutions understand options, evidence, risks, trade-offs, dependencies, readiness, scenarios, or next-step questions without making decisions by default. They may support public authority learning, National Portfolio preparation, Studio workflows, Grid and TRL review, Reports, Academy exercises, Campaign strategy, capital-reader literacy, insurance-reader literacy, donor-reader literacy, public finance learning, Project SPV context, National Consortium Company context, or lawful handoff preparation.

Decision-support models may combine statistical models, machine-learning models, risk models, forecasting models, simulation models, optimization models, rules, expert inputs, dashboards, feature sets, or qualitative assessments. Because they may appear close to action, they require strong boundary notices.

A Decision-Support Model Record should identify:

1. decision context supported, including what decision or question is being illuminated and who has actual decision authority outside Nexus;
2. inputs and methods, including data, evidence, assumptions, model components, rules, weights, and limitations;
3. outputs, including options, comparisons, scores, scenarios, questions, dependencies, readiness notes, or warnings about insufficiency;
4. required human review, including expert review, public-safe review, public authority boundary review, finance or insurance boundary review, safeguard review, and handoff review;
5. prohibited interpretations, including no automated decision, no public authority action, no procurement decision, no investment advice, no underwriting, no donor commitment, no consent, no deployment authorization, and no execution;
6. correction and lifecycle, including data update, model update, output correction, suspension, withdrawal, recall, archive, and non-continuation.

A decision-support model supports decision-makers; it does not become the decision-maker. Nexus decision support remains advisory, learning-oriented, evidence-bearing, and non-executing unless a separate competent actor lawfully adopts its own decision process.

### 11.2.14 Evaluation Harnesses

Evaluation harnesses are governed AI and software objects used to test, compare, benchmark, monitor, inspect, red-team, validate within scope, or evaluate models, prompts, agentic workflows, retrieval systems, classifiers, forecasting models, simulation models, digital twin models, risk models, optimization models, decision-support models, dashboards, public-safe reporting workflows, or AI-assisted software components.

An evaluation harness may include benchmark datasets, test prompts, test cases, scenarios, scoring functions, evaluators, human-review rubrics, adversarial examples, bias tests, hallucination tests, leakage tests, prompt-injection tests, robustness tests, security tests, accessibility tests, public-safe language tests, and regression tests.

An Evaluation Harness Record should identify:

1. evaluation purpose and scope;
2. systems evaluated;
3. test data and benchmark cards;
4. evaluation method, including automated metrics, human review, expert review, red-team review, public-safe review, or hybrid review;
5. coverage and exclusions, including domains, languages, user classes, data classes, risk types, and edge cases not covered;
6. scoring and interpretation rules, including what a pass, fail, warning, or score means and what it does not mean;
7. sensitivity and access controls, including restricted tests, cyber-sensitive tests, protected knowledge exclusions, public authority-sensitive exclusions, and room requirements;
8. correction and lifecycle, including test update, benchmark correction, score correction, model retest, suspension, withdrawal, recall, archive, and non-continuation.

An evaluation harness is not certification by default. Passing an evaluation does not authorize deployment. Failing an evaluation does not always prohibit research use. Evaluation creates evidence for review, Grid or TRL routing, Studio readiness, public-safe release, Marketplace listing, Registry status, Nexus Universe presentation, or handoff context. It does not create procurement, finance, insurance, public authority action, consent, deployment, or execution authority.

The final AI Object Classes rule is: statistical models estimate; machine-learning models learn patterns; foundation-model interfaces connect general AI capability; fine-tuned models embed additional data and risk; retrieval systems ground outputs while preserving access limits; agents require controlled runtime cards; classifiers route but do not decide; forecasting, simulation, digital twin, risk, optimization, and decision-support models illuminate futures and trade-offs without authority; evaluation harnesses test within scope without certifying. Every AI object must remain recorded, bounded, reviewed, correctable, and non-executing by default.

## 11.3 AI-Use Labels

### 11.3.1 No-AI Use

No-AI Use is the AI-use label applied where a data object, metadata object, protected knowledge object, public authority-sensitive object, community-sensitive object, Indigenous protocol-sensitive object where applicable, youth data object, health-sensitive object, cyber-sensitive object, infrastructure-sensitive object, geospatial-sensitive object, handoff-recipient-only object, archive-only object, or other Nexus object must not be processed by AI systems.

No-AI Use means the object must not be used for AI training, fine-tuning, embedding, retrieval augmentation, summarization, classification, translation, generation, simulation, model evaluation, feature extraction, agentic workflows, automated routing, or AI-assisted public-safe drafting unless the label is changed through a recorded rights, sensitivity, public-safe, and AI governance review.

A No-AI Use label should be applied where:

1. rights, consent, license, protocol, or permission do not allow AI processing;
2. the object contains protected knowledge, Indigenous protocol-sensitive content where applicable, personal data, youth data, health-sensitive data, cyber-sensitive data, public authority-sensitive data, or restricted data not cleared for AI use;
3. the risk of leakage, re-identification, inference, hallucinated restatement, unauthorized training, or unauthorized derivative creation is unacceptable;
4. the object is under correction, withdrawal, recall, sealing, legal hold, or archive-only restriction;
5. the steward has not yet completed AI-use review.

No-AI Use is not a judgment that the object lacks value. It is a protective control. The object may still be reviewed by humans, preserved in Registry, included in metadata-only records, transformed into a public-safe derivative where lawful, or handled in secure rooms. It simply may not be processed by AI by default.

### 11.3.2 Retrieval-Only

Retrieval-Only is the AI-use label applied where an object may be retrieved or surfaced by an AI-assisted system for reference, grounding, search, or source-location purposes, but may not be used for training, fine-tuning, uncontrolled embedding, generative transformation, autonomous summarization, or agentic action beyond the recorded retrieval use.

Retrieval-Only may be appropriate for controlled knowledge bases, Reports, Registry records, Marketplace listings, public-safe summaries, metadata records, software documentation, selected Academy materials, public-safe National Portfolio summaries, Nexus Universe records, or handoff-context materials where the object may support source-aware answers without becoming part of a model’s training corpus.

A Retrieval-Only label should identify:

1. permitted retrieval system or pathway;
2. access class and user role limits;
3. whether indexing or embedding is permitted;
4. whether retrieved content may be quoted, summarized, or only referenced;
5. whether outputs require source citation, human review, or public-safe review;
6. whether retrieval must respect current Registry status, correction records, withdrawal notices, recall notices, supersession records, and archive status;
7. whether the object must be de-indexed upon correction, withdrawal, recall, sealing, or archive.

Retrieval-Only does not make the object open. Retrieval by an AI system must remain bounded by user permissions, access controls, source status, public-safe limits, and no-conversion notices. Retrieval grounding improves traceability; it does not guarantee truth, authority, certification, public authority action, procurement status, financeability, insurability, consent, deployment authorization, or execution.

### 11.3.3 Summarization with Review

Summarization with Review is the AI-use label applied where AI may assist in producing summaries, abstracts, briefings, issue notes, public-safe candidates, learning notes, room notes, Report drafts, Marketplace descriptions, Registry draft notes, National Portfolio summaries, Nexus Universe summaries, or handoff-context summaries, provided that the output receives human review before use, release, listing, registration, publication, routing, or handoff.

Summarization with Review may be appropriate where the source materials are permitted for AI-assisted summarization and where the summary will not expose restricted data, protected knowledge, personal data, youth data, health-sensitive data, cyber-sensitive data, geospatial-sensitive data, infrastructure-sensitive data, public authority-sensitive data, community-sensitive data, or Indigenous protocol-sensitive content where applicable beyond the source’s permitted release class.

A Summarization with Review label should identify:

1. source materials permitted for summarization;
2. prohibited source materials;
3. approved AI system or controlled environment where applicable;
4. human reviewer class;
5. public-safe review requirement where summaries may be released beyond a controlled setting;
6. requirements for uncertainty, limitations, status, lifecycle state, and no-conversion language;
7. correction and recall pathway for inaccurate, overclaiming, unsafe, incomplete, or misleading summaries.

AI-assisted summaries are draft objects until reviewed. A summary may omit context, compress uncertainty, overstate confidence, misstate status, erase sensitivity, or introduce hallucinated content. Human review must verify source fidelity, boundary language, public-safe status, current Registry status, correction state, and access limitations.

Summarization with Review is assistance, not authority. It does not create public warning, public authority action, certification, procurement recommendation, finance or insurance determination, consent, deployment authorization, or execution instruction.

### 11.3.4 Classification with Review

Classification with Review is the AI-use label applied where AI may assist in assigning labels, categories, routes, object classes, data classes, sensitivity classes, data-use candidates, public-safe review flags, Docket classes, Registry draft statuses, Marketplace listing candidates, Grid or TRL routing suggestions, National Portfolio categories, Nexus Universe routing categories, or handoff dependency categories, provided that a competent human or review pathway confirms the classification before it becomes status truth.

Classification with Review may support intake triage, metadata enrichment, DICE routing, AI-use review, source review, public-safe review, repository routing, Studio routing, Reports routing, Marketplace routing, Registry drafting, Grid routing, Campaign moderation, Academy pathway routing, National Node routing, or handoff preparation.

A Classification with Review label should identify:

1. classification taxonomy or ontology used;
2. permitted input classes;
3. prohibited input classes;
4. AI model or classifier used where relevant;
5. human reviewer class;
6. threshold, confidence, uncertainty, and escalation rules;
7. correction pathway for misclassification;
8. downstream systems affected by classification.

AI-assisted classification must not silently become official status. A classifier may suggest that data is restricted, but a steward must review. It may suggest Marketplace eligibility, but listing governance must decide. It may suggest Registry status, but Registry status must be recorded through the competent pathway. It may suggest Grid or TRL routing, but readiness classification must follow the required review.

Classification with Review supports routing. It does not certify, approve, procure, finance, insure, authorize public authority action, grant consent, authorize deployment, or execute.

### 11.3.5 Evaluation-Only

Evaluation-Only is the AI-use label applied where an object may be used to evaluate, benchmark, test, compare, audit, red-team, validate within scope, stress-test, or review an AI model, AI workflow, agentic workflow, retrieval system, classifier, public-safe output process, Studio workflow, DRI workflow, GRIx workflow, Observatory workflow, or software component, but may not be used for training, fine-tuning, production inference, public-facing generation, or operational deployment.

Evaluation-Only may apply to benchmark datasets, test prompts, test cases, synthetic datasets, public-safe examples, controlled examples, adversarial examples, red-team materials, labeled datasets, evaluation rubrics, model-output comparison records, or AI safety test suites.

An Evaluation-Only label should identify:

1. permitted evaluation purpose;
2. model, workflow, or system class being evaluated;
3. whether automated evaluation, human evaluation, expert review, or hybrid evaluation is permitted;
4. whether the object may be embedded, stored, logged, or retained by the evaluation system;
5. whether results may be published, restricted, summarized, or used only internally;
6. prohibited training, fine-tuning, production inference, public-facing generation, or agentic use;
7. correction, withdrawal, recall, and archive rules.

Evaluation-Only data may be sensitive. A benchmark may expose protected categories, adversarial prompts, cyber-sensitive scenarios, public authority-sensitive materials, or protected knowledge exclusions. Evaluation use must remain bounded by access, room, output-review, and public-safe controls.

Evaluation results do not certify the model or system by default. They provide evidence under defined conditions.

### 11.3.6 Fine-Tuning Permitted

Fine-Tuning Permitted is the AI-use label applied where a data object or data object family may be used to adapt an existing model through supervised fine-tuning, instruction tuning, adapter training, domain adaptation, reinforcement learning from feedback, or another parameter-changing process under defined conditions.

Fine-Tuning Permitted should be used sparingly and only after rights review, sensitivity review, data-use review, AI-use review, public-safe review where relevant, and steward approval. It must not be inferred from general access, publication, open-source availability, dataset citation, data-room access, Academy use, Reports use, or handoff context.

A Fine-Tuning Permitted label should identify:

1. permitted base model or model class;
2. permitted tuning purpose;
3. approved tuning data and excluded data;
4. training environment, including secure-room, data-room, clean-room, compute-to-data, sovereign-zone, or controlled environment where required;
5. retention and deletion rules for training data, intermediate files, logs, checkpoints, and outputs;
6. protected knowledge, personal data, youth data, health data, community-sensitive data, Indigenous protocol-sensitive data where applicable, cyber-sensitive data, infrastructure-sensitive data, public authority-sensitive data, and geospatial-sensitive exclusions or conditions;
7. evaluation, model card, benchmark card, system card, and human review requirements;
8. downstream restrictions on the fine-tuned model;
9. correction, data-removal, model suspension, withdrawal, recall, archive, and non-continuation pathways.

Fine-tuning creates persistent model behavior and may make later data removal difficult or incomplete. For that reason, permission must be explicit, documented, and narrow. Fine-Tuning Permitted does not authorize deployment, public release, procurement, finance, insurance, public authority action, consent, or execution.

### 11.3.7 Training Permitted

Training Permitted is the AI-use label applied where a data object may be used to train a new AI model or materially contribute to model pretraining, foundation-model training, large-scale representation learning, embedding model training, classification model training, simulation model training, or other model-development process under defined conditions.

Training Permitted is the strongest AI-use permission and should require the highest level of rights, sensitivity, public-safe, privacy, cyber, protected knowledge, community, Indigenous protocol where applicable, public authority, legal, and governance review. It should never be implied from data availability, open access, public visibility, repository presence, data-room access, public-safe summary, citation, or handoff context.

A Training Permitted label should identify:

1. training purpose and model class;
2. approved data scope;
3. excluded data categories;
4. legal, license, consent, steward, or rights basis;
5. whether training may occur in open, controlled, secure-room, clean-room, compute-to-data, sovereign-zone, or other environment;
6. whether trained weights, embeddings, checkpoints, logs, and derivative outputs may be retained, shared, published, evaluated, or handed off;
7. de-identification, minimization, filtering, redaction, protected knowledge exclusion, and safety measures;
8. evaluation, model card, system card, benchmark card, and human review requirements;
9. downstream use restrictions;
10. deletion, unlearning where possible, correction, suspension, withdrawal, recall, archive, and non-continuation rules.

Training permission is not deployment permission. A model trained on permitted data still requires model governance, evaluation, human review, public-safe controls, security review, bias review, lifecycle controls, and separate authorization before any operational use. Training Permitted authorizes a defined training use; it does not authorize automated authority.

### 11.3.8 Agentic Use Prohibited

Agentic Use Prohibited is the AI-use label applied where AI may not use the object in workflows that plan, call tools, write files, modify records, send messages, update repositories, query external systems, execute code, generate operational steps, create handoff packages, trigger workflows, update dashboards, route Dockets, publish content, or otherwise perform multi-step action-like behavior.

Agentic Use Prohibited may apply even where retrieval, summarization, classification, translation, or evaluation is permitted. It is especially important for restricted data, protected knowledge, public authority-sensitive data, cyber-sensitive data, infrastructure-sensitive data, geospatial-sensitive data, community-sensitive data, Indigenous protocol-sensitive data where applicable, youth data, health-sensitive data, handoff-recipient-only materials, credentials, secrets, system configuration files, finance-sensitive materials, insurance-sensitive materials, and procurement-sensitive materials.

An Agentic Use Prohibited label should identify:

1. allowed non-agentic AI uses, if any;
2. prohibited tools and actions;
3. prohibited write-back, publication, handoff, routing, messaging, repository, API, data export, or workflow-triggering uses;
4. human-only review requirements where applicable;
5. secure-room or data-room controls where applicable;
6. monitoring and incident response for attempted agentic misuse;
7. correction, recall, archive, and sealing pathway.

This label prevents AI from converting information access into action. It recognizes that an object may be safe to read under controlled conditions but unsafe to place inside a tool-using agent.

Agentic Use Prohibited preserves the line between AI assistance and execution.

### 11.3.9 Secure-Room AI Only

Secure-Room AI Only is the AI-use label applied where AI processing is permitted only inside an approved secure room, data room, clean room, protected knowledge room, compute-to-data environment, sovereign data zone, or other controlled environment with access control, logging, output review, no-download controls, no-cross-border-transfer controls where applicable, and correction pathways.

Secure-Room AI Only may be appropriate for controlled public data, restricted data, public authority-sensitive data, community-sensitive data, Indigenous protocol-sensitive data where applicable, protected knowledge derivatives, health-sensitive data, youth data, cyber-sensitive data, infrastructure-sensitive data, geospatial-sensitive data, finance-sensitive data, insurance-sensitive data, National Portfolio data, Nexus Universe room materials, or handoff-recipient-only materials.

A Secure-Room AI Only label should identify:

1. approved room or compute environment;
2. approved AI system or model class;
3. approved users and roles;
4. approved AI tasks;
5. prohibited AI tasks, including training, fine-tuning, embedding, agentic use, autonomous publication, or handoff unless separately permitted;
6. input controls;
7. output review requirements;
8. logging and audit requirements;
9. retention, deletion, sealing, and archive rules;
10. incident response, correction, withdrawal, and recall pathway.

Secure-Room AI Only does not make the data open. It does not grant general AI-use permission outside the controlled environment. It permits a defined AI workflow under room governance and output review. Any output leaving the room must be reviewed, classified, labeled, and released under its own public-safe or controlled status.

### 11.3.10 Public-Safe AI Output Only

Public-Safe AI Output Only is the AI-use label applied where AI may produce outputs only if those outputs are transformed, reviewed, and approved for public-safe or controlled-safe communication before release, publication, listing, registration, teaching, presentation, dashboard display, Campaign use, Nexus Universe use, or handoff.

This label is appropriate where AI can assist with drafting, summarization, explanation, translation, visualization, coding support, metadata generation, or public-facing communication, but where unreviewed outputs could create hallucination, overclaim, public authority confusion, finance or insurance overclaim, procurement implication, consent overclaim, protected knowledge exposure, privacy exposure, cyber exposure, geospatial exposure, or execution implication.

A Public-Safe AI Output Only label should require:

1. source verification;
2. human review;
3. public-safe review where outputs leave controlled contexts;
4. no unsupported factual claims;
5. uncertainty and limitation language;
6. current Registry, Marketplace, correction, withdrawal, recall, archive, and lifecycle-status checks;
7. no-public-authority-action language where relevant;
8. no-finance and no-insurance language where relevant;
9. no-procurement, no-certification, no-consent, no-deployment, and no-execution notices where relevant;
10. protected knowledge, community, Indigenous protocol where applicable, youth, health, cyber, infrastructure, and geospatial sensitivity checks;
11. correction, withdrawal, recall, public repair, and archive pathways.

Public-Safe AI Output Only does not authorize automated publication. It means the AI output must be made public-safe before it can move. The AI output remains draft, controlled, or review-pending until a competent review pathway records otherwise.

The final AI-Use Labels rule is: No-AI Use prohibits AI processing; Retrieval-Only permits bounded grounding; Summarization and Classification require review; Evaluation-Only supports testing without training; Fine-Tuning and Training require explicit, narrow permission; Agentic Use Prohibited blocks action-like automation; Secure-Room AI Only confines AI to controlled environments; Public-Safe AI Output Only prevents unreviewed AI language from becoming public meaning. AI-use labels govern permission; they never create automated authority, deployment authorization, certification, procurement, finance, insurance, public authority action, consent, or execution by implication.

## 11.4 Agentic Workflow Controls

### 11.4.1 Agent Identity

Agent identity is the first control for any agentic workflow. A Nexus agent must be identifiable before it can access records, call tools, retrieve data, draft outputs, route objects, support Studio workflows, assist Reports, generate Registry or Marketplace draft text, prepare Grid or TRL inputs, support National Portfolio work, support Nexus Universe production, or prepare handoff-context materials.

Agent identity should not be vague. “AI assistant,” “workflow bot,” “automation,” or “model” is not sufficient where the workflow can take action-like steps. The Agent Record should identify the agent name, version, model dependency, system dependency, steward, workflow owner, deployment or runtime environment, tool set, data-access class, purpose, user class, logging status, support class, review pathway, correction pathway, shutdown pathway, and archive rule.

An Agent Identity Record should include:

1. agent name and identifier, including version and workflow family;
2. agent steward, including the person, team, institution, Working Group, Competence Cell, National Node, Studio pathway, Foundry pathway, or other responsible role that governs the workflow;
3. model and system dependencies, including model provider or model family where relevant, retrieval corpus, tools, APIs, repositories, data rooms, secure rooms, and runtime environment;
4. permitted user classes, including contributors, reviewers, maintainers, learners, public authority learners, Studio participants, National Node users, Nexus Universe users, or handoff-preparation users;
5. permitted object classes, including software, data, metadata, reports, Marketplace listings, Registry drafts, Grid inputs, Studio workflows, National Portfolio objects, Nexus Universe objects, or handoff-context drafts;
6. current lifecycle state, including draft, controlled pilot, reviewed, supported, suspended, withdrawn, recalled, archived, or non-continuing.

Agent identity prevents hidden automation. No agentic workflow should act anonymously, ambiguously, or under a human or institutional name in a way that conceals its AI-assisted nature. An agent may support work, but the responsible steward and human review pathway must remain visible.

Agent identity is not authority. Naming an agent does not authorize it to decide, approve, publish, procure, finance, insure, issue public authority action, grant consent, deploy, hand off, or execute. It makes the workflow governable.

### 11.4.2 Tool Permissions

Tool permissions define what an agentic workflow may access, read, search, retrieve, write, edit, execute, call, transform, send, schedule, publish, list, register, package, or hand off. Tool permissions must be explicit, least-privilege, purpose-bound, role-bound, logged, reviewable, revocable, and tied to the agent’s identity, workflow purpose, data-use labels, AI-use labels, access class, room class, public-safe status, and correction pathway.

Tool permissions should distinguish:

1. read-only permissions, including document retrieval, repository search, metadata lookup, Registry lookup, Marketplace lookup, Reports lookup, Academy lookup, or Docket lookup;
2. write-limited permissions, including drafting files, proposing edits, creating review notes, preparing draft metadata, or assembling draft packages without final publication;
3. code permissions, including running tests, executing notebooks, validating schemas, generating software, or analyzing logs only within approved environments;
4. data permissions, including access to open, controlled, restricted, secure-room, data-room, clean-room, compute-to-data, National Node, protected knowledge, public authority-sensitive, or handoff-recipient-only data;
5. communication permissions, including whether the agent may draft messages, create draft notices, prepare room summaries, or send nothing without human action;
6. system permissions, including APIs, repositories, calendars, files, databases, Studio workflows, Registry systems, Marketplace systems, Grid systems, and handoff-package systems;
7. prohibited permissions, including autonomous publication, autonomous Registry status change, autonomous Marketplace listing, autonomous public authority action, autonomous procurement action, autonomous finance action, autonomous insurance action, autonomous donor commitment, autonomous consent action, autonomous deployment, autonomous handoff, operational command, and execution.

Tool permissions should default to no access unless expressly granted. Sensitive tools should require human-in-the-loop review before use. Write, delete, publish, external-send, cross-border-transfer, handoff-package, and system-update permissions should require heightened controls or prohibition by default.

Tool permission is not delegated institutional authority. A tool-enabled agent may have technical capability to perform a step, but technical capability does not create legal, public authority, financial, procurement, consent, deployment, or execution authority.

### 11.4.3 Human-in-the-Loop Requirements

Human-in-the-loop requirements are controls requiring a competent human to review and approve a defined action before the agentic workflow may proceed. Human-in-the-loop control is required where an agent’s next step could materially affect records, public-safe outputs, data handling, AI-use permissions, software releases, Marketplace listings, Registry statuses, Grid or TRL inputs, Studio outputs, Reports, Campaign materials, National Portfolio objects, Nexus Universe outputs, handoff packages, access control, deletion, sealing, withdrawal, recall, or external communications.

Human-in-the-loop control should apply before an agent may:

1. publish or release any output beyond a controlled draft environment;
2. modify Registry status or Marketplace listing text;
3. create or update a Grid or TRL record;
4. process restricted, protected, public authority-sensitive, cyber-sensitive, health-sensitive, youth, community-sensitive, Indigenous protocol-sensitive where applicable, or handoff-recipient-only materials;
5. run code against controlled data;
6. export outputs from a secure room, data room, clean room, or compute-to-data environment;
7. create public-safe summaries;
8. prepare or modify handoff packages;
9. send communications externally;
10. delete, seal, archive, withdraw, recall, or mark an object non-continuing;
11. take any step that could be mistaken for approval, certification, procurement, finance, insurance, public authority action, consent, deployment, or execution.

A Human-in-the-Loop Record should identify the action, the human reviewer, reviewer role, materials reviewed, decision made, limitations, required edits, approval scope, date, and correction pathway.

Human-in-the-loop review is not a rubber stamp. It requires a reviewer capable of understanding the record, status, boundary, and risk implications of the agent’s proposed action. The agent may prepare; the human must decide whether the action may proceed within Nexus scope.

### 11.4.4 Human-on-the-Loop Requirements

Human-on-the-loop requirements are controls requiring human monitoring, supervision, periodic review, audit, sampling, override, escalation, or shutdown capacity while an agentic workflow operates within an approved scope. This control may be appropriate where the agent performs repeated low-to-moderate-risk tasks but must remain observable and interruptible.

Human-on-the-loop control may apply to:

1. metadata drafting;
2. routine classification suggestions;
3. retrieval support;
4. draft summarization;
5. issue triage;
6. test execution;
7. public-safe checklist support;
8. repository maintenance suggestions;
9. learning support;
10. Campaign moderation support;
11. Studio workflow monitoring;
12. DICE routing suggestions;
13. Marketplace or Registry draft preparation;
14. Grid or TRL pre-screening;
15. Nexus Universe production support.

Human-on-the-loop control should include:

1. monitoring dashboard or review queue, showing agent actions, outputs, confidence, sources, exceptions, and pending approvals;
2. sampling protocol, defining how outputs are reviewed for accuracy, hallucination, bias, public-safe language, boundary overclaim, data-use compliance, AI-use compliance, and correction needs;
3. override authority, allowing a competent human to stop, reverse, correct, restrict, or escalate an agent output;
4. escalation triggers, requiring the workflow to stop or move to human-in-the-loop review when risk increases;
5. periodic audit, reviewing logs, tool calls, retrieval sources, outputs, correction history, and incident patterns;
6. shutdown pathway, including suspension, withdrawal, recall, archive, or non-continuation.

Human-on-the-loop supervision is not suitable for high-impact action-like steps unless paired with human-in-the-loop approval. Monitoring is not enough where the agent could publish, hand off, modify status truth, process restricted data, or affect external actors. Human-on-the-loop is supervision for bounded assistance, not permission for autonomous authority.

### 11.4.5 No-Command Rules

No-command rules prohibit an agentic workflow from issuing, simulating, implying, or executing commands that could be understood as operational instructions, emergency commands, public authority directives, procurement directions, finance actions, insurance actions, donor allocations, consent determinations, deployment instructions, infrastructure control actions, cyber actions, field actions, or project execution instructions.

No-command rules apply especially to agents used in Studio workflows, dashboards, digital twins, simulations, Observatory workflows, DRI workflows, public authority learning rooms, secure rooms, data rooms, cyber review workflows, infrastructure workflows, National Portfolio workflows, Nexus Universe workflows, and handoff package preparation.

An agent operating under no-command rules must not:

1. instruct a public authority to act, warn, regulate, procure, permit, enforce, allocate, or approve;
2. instruct an operator to deploy, shut down, reroute, open, close, patch, connect, disconnect, or operate infrastructure;
3. instruct a provider, contractor, or Project SPV to implement work;
4. instruct a capital reader, insurer, donor, or public finance actor to finance, insure, allocate, approve, rate, underwrite, or commit;
5. instruct a community or Indigenous institution where applicable to consent, waive rights, grant access, disclose protected knowledge, or approve implementation;
6. trigger field operations, emergency response, cyber response, procurement, finance, insurance, public authority action, handoff completion, or execution;
7. generate language that appears to order, direct, authorize, command, or approve action.

No-command rules do not prohibit the agent from drafting questions, options, considerations, dependency notes, learning summaries, readiness gaps, public-safe explanations, or handoff-context materials. The distinction is essential: the agent may support understanding; it may not command action.

A no-command violation should trigger escalation, review, correction, and where necessary suspension or recall.

### 11.4.6 No-Write-Back Rules

No-write-back rules prohibit or limit an agentic workflow from writing data, outputs, classifications, status changes, decisions, commands, or edits back into source systems, repositories, dashboards, Registry records, Marketplace listings, Grid records, public authority systems, provider systems, finance or insurance systems, community records, National Portfolio records, Nexus Universe records, handoff-recipient systems, or operational systems without explicit human approval and recorded authority.

No-write-back controls are necessary because write access can silently convert an assistant into an actor. An agent that can write to a Registry may alter status truth. An agent that can write to a Marketplace may create public discovery. An agent that can write to a dashboard may change public meaning. An agent that can write to a public authority system may appear to trigger public action. An agent that can write to a handoff package may affect recipient reliance.

No-write-back rules should define:

1. systems where write-back is prohibited entirely;
2. systems where draft-only write-back is permitted;
3. systems where write-back requires human-in-the-loop approval;
4. fields the agent may never alter, including official status, approval status, certification status, procurement status, finance status, insurance status, consent status, public authority status, deployment status, and execution status;
5. records required before any write-back, including reviewer identity, source record, change summary, approval scope, version, timestamp, correction pathway, and rollback pathway;
6. rollback and correction controls, including how unauthorized or erroneous write-back is reversed and disclosed.

No-write-back does not prevent agent usefulness. The agent may draft, stage, propose, compare, validate, or flag changes. Final status-changing, release-changing, rights-changing, access-changing, public-facing, handoff-facing, or system-facing writes require competent human authority.

### 11.4.7 Output Review

Output review is the control through which agent-generated or AI-assisted outputs are examined before they are used, shared, published, listed, registered, routed, taught, displayed, handed off, archived, or relied upon within Nexus. Output review prevents hallucination, unsupported claims, stale source use, metadata errors, public-safe failures, boundary overclaim, sensitivity exposure, rights violations, and automated authority drift.

Output review should evaluate:

1. source fidelity, including whether the output accurately reflects the records used;
2. current status truth, including Registry status, Marketplace status, lifecycle state, correction history, withdrawal notices, recall notices, supersession, support class, and archive status;
3. data-use and AI-use compliance;
4. public-safe language, including uncertainty, limitations, audience, and release class;
5. sensitivity exposure, including protected knowledge, personal data, youth data, health-sensitive data, cyber-sensitive data, infrastructure-sensitive data, geospatial-sensitive data, public authority-sensitive data, community-sensitive data, and Indigenous protocol-sensitive data where applicable;
6. no-conversion language, including no-certification, no-warranty, no-procurement, no-finance, no-public-authority, no-consent, no-deployment, no-execution, no-provider-validation, and no-sponsor-control notices where relevant;
7. hallucination, bias, omission, overconfidence, or false precision;
8. handoff risk, including whether a draft could be mistaken for recipient authorization or execution context.

Output review may result in approval within scope, revision, restriction, public-safe transformation, return for human drafting, escalation, suspension, withdrawal, recall, archive, or non-continuation.

An agent output is draft by default. Output review is the pathway by which a draft may become a governed object. Until reviewed and recorded, the output should not be treated as status truth, public-safe publication, Registry status, Marketplace listing, Grid record, Report, National Portfolio object, Nexus Universe output, or handoff package.

### 11.4.8 Escalation Triggers

Escalation triggers are predefined conditions requiring an agentic workflow to stop, defer, seek human-in-the-loop approval, move to a secure room, notify a steward, create an incident record, or suspend operation. Escalation triggers prevent a bounded workflow from continuing when risk exceeds its authorized scope.

Escalation should be required where the agent encounters or produces:

1. restricted data, protected knowledge, Indigenous protocol-sensitive content where applicable, community-sensitive data, youth data, health-sensitive data, cyber-sensitive data, infrastructure-sensitive data, geospatial-sensitive data, public authority-sensitive data, finance-sensitive data, insurance-sensitive data, procurement-sensitive data, or handoff-recipient-only materials outside its approved permissions;
2. unclear data rights, unclear AI-use permission, unclear source status, missing metadata, missing lineage, missing Registry status, or unresolved correction records;
3. potential hallucination, unsupported claim, false citation, stale source, superseded object, withdrawn object, recalled object, archive-only object, or non-continuing object;
4. language that could imply certification, procurement, finance, insurance, public authority action, consent, deployment, execution, provider validation, or sponsor control;
5. request for autonomous publication, external communication, Registry update, Marketplace listing, Grid or TRL status, handoff package creation, deletion, sealing, recall, or system write-back;
6. security issue, secret exposure, prompt-injection attempt, tool misuse, unauthorized access attempt, data leakage risk, or anomalous behavior;
7. request to bypass access controls, no-download controls, output review, public-safe review, human review, or room restrictions.

An Escalation Record should identify the trigger, workflow state, object involved, risk class, action taken, human reviewer or steward notified, interim restriction, correction pathway, and closure condition.

Escalation is a trust mechanism. It allows agents to be useful while preventing them from improvising beyond authority.

### 11.4.9 Kill-Switch Conditions

Kill-switch conditions define when an agentic workflow must be immediately stopped, disabled, disconnected, suspended, isolated, access-revoked, output-frozen, or recalled. A kill-switch is required where continued operation may create material risk to data, rights, public-safe meaning, cybersecurity, public authority boundaries, finance or insurance boundaries, consent boundaries, protected knowledge, community safeguards, Indigenous protocols where applicable, handoff integrity, or Nexus legitimacy.

Kill-switch conditions should include:

1. unauthorized access to restricted, protected, public authority-sensitive, cyber-sensitive, health-sensitive, youth, community-sensitive, Indigenous protocol-sensitive where applicable, or handoff-recipient-only data;
2. secret exposure, credential misuse, unauthorized tool call, or suspicious system behavior;
3. prompt-injection compromise or tool-chain compromise;
4. unauthorized write-back, publication, Registry update, Marketplace listing, Grid or TRL update, handoff package change, external communication, deletion, sealing, or archive action;
5. repeated hallucination, false citation, source fabrication, or status-truth failure;
6. public authority, procurement, finance, insurance, consent, deployment, or execution overclaim;
7. protected knowledge exposure or AI-use violation;
8. cross-border transfer violation or data sovereignty breach;
9. output release without required review;
10. inability to log, audit, monitor, or control the workflow;
11. steward withdrawal, support failure, critical dependency compromise, or model/provider term change that materially affects risk;
12. incident severity requiring stop-the-line action.

A Kill-Switch Record should identify the condition, time of activation, authority activating it, systems disabled, data or outputs frozen, users affected, materials requiring review, downstream objects affected, notification requirements, correction actions, recall actions, reinstatement conditions, archive treatment, and non-continuation decision if applicable.

Kill-switch authority should be clear before the agent is deployed. A workflow that cannot be stopped should not be used in Nexus-controlled contexts.

### 11.4.10 Agentic Incident Records

Agentic Incident Records document events in which an agentic workflow violates, threatens, or appears to violate its identity, tool permissions, AI-use label, data-use label, access class, public-safe status, output review rule, no-command rule, no-write-back rule, room control, escalation rule, kill-switch condition, correction pathway, or Nexus no-conversion boundary.

Agentic incidents may include:

1. unauthorized data access;
2. unauthorized AI use;
3. restricted data leakage;
4. protected knowledge exposure;
5. public authority-sensitive disclosure;
6. cyber-sensitive disclosure;
7. hallucinated source or false citation;
8. false status-truth claim;
9. unreviewed publication;
10. unauthorized Registry or Marketplace change;
11. unauthorized Grid or TRL draft promoted as status;
12. unauthorized handoff package generation;
13. unauthorized write-back;
14. prompt-injection compromise;
15. tool misuse;
16. no-command violation;
17. no-deployment or no-execution overclaim;
18. provider validation or sponsor control overclaim;
19. failure to escalate;
20. failure to activate kill-switch when required.

An Agentic Incident Record should identify the agent, workflow, version, steward, user or trigger context, tools used, objects affected, data affected, outputs generated, severity, detection time, containment action, kill-switch status, human reviewer, correction required, notification required, public repair required where applicable, downstream object impacts, handoff recipient impacts, Registry and Marketplace impacts, archive treatment, and reinstatement or non-continuation decision.

Agentic incident records are not optional reputational documents. They are part of correctionability. They preserve trust by making automation failures visible, correctable, and learnable within safe limits.

The final Agentic Workflow Controls rule is: agents must have identity; tools must be permissioned; humans must remain in or on the loop according to risk; agents must not command, write back, publish, hand off, or execute without authority; outputs require review; escalation and kill-switch conditions must be predefined; incidents must be recorded, corrected, recalled where needed, and archived. Agentic capability may support Nexus work, but it never becomes autonomous authority, deployment authorization, certification, procurement, finance, insurance, public authority action, consent, or execution by implication.

## 11.5 AI Safety and Security Controls

### 11.5.1 Data Provenance

Data provenance is the AI safety and security control requiring every AI system, model object, retrieval workflow, fine-tuned model, evaluation harness, classifier, forecasting model, simulation model, digital twin model, risk model, optimization model, decision-support model, agentic workflow, or AI-assisted output to identify the data, records, sources, objects, repositories, prompts, tools, and pathways that materially shaped the AI use.

Data provenance prevents AI outputs from appearing authoritative without traceable foundations. It also protects Nexus from unsafe reuse of restricted data, hidden protected knowledge exposure, unauthorized AI training, public authority overclaim, finance or insurance overclaim, procurement implication, consent overclaim, deployment overclaim, and execution by implication.

An AI Data Provenance Record should identify:

1. input data objects, including source datasets, metadata objects, reports, records, repositories, retrieval corpora, prompts, examples, benchmark datasets, public-safe summaries, Studio materials, National Portfolio objects, Nexus Universe outputs, or handoff-context materials;
2. source pathway, including DICE, GRIx, DRI, Observatory, Studio, Reports, Academy, Campaigns, Foundry, Labs, Registry, Marketplace, Grid, National Node, Nexus Universe, public authority learning room, secure room, data room, clean room, compute-to-data workflow, or handoff pathway;
3. data-use and AI-use labels, including whether retrieval, summarization, classification, evaluation, fine-tuning, training, agentic use, secure-room AI, or public-safe AI output is permitted;
4. rights and sensitivity context, including license, consent, permission, privacy, protected knowledge, community-sensitive, Indigenous protocol-sensitive where applicable, youth, health, cyber, infrastructure, geospatial, public authority, sovereign, finance, insurance, procurement, or legal sensitivity;
5. lineage and transformation, including whether source data was raw, processed, aggregated, synthetic, public-safe transformed, masked, redacted, de-identified, embedded, indexed, fine-tuned, or used in evaluation;
6. provenance limitations, including unknown sources, incomplete lineage, outdated sources, inaccessible sources, archive-only records, superseded records, withdrawn records, recalled records, or non-continuing materials.

AI outputs that lack adequate provenance should be treated as draft, review-pending, restricted, unsupported, or non-continuing depending on risk. Provenance is not certification. It is traceability. It allows AI-supported work to be reviewed, corrected, withdrawn, recalled, archived, or responsibly handed off within recorded limits.

### 11.5.2 Training Data Constraints

Training data constraints are the controls governing what data may be used to train, fine-tune, adapt, evaluate, embed, index, or otherwise shape AI systems. Training data constraints preserve the distinction between data access and AI-use permission. A dataset may be viewable, citable, reportable, teachable, or usable in a secure room without being trainable.

Training data constraints should prohibit use of any data for model training or fine-tuning unless the data object carries an express Training Permitted or Fine-Tuning Permitted AI-use label and the applicable rights, permissions, sensitivity review, public-safe review, data sovereignty review, protected knowledge review, community safeguard review, Indigenous protocol review where applicable, and correction pathway are recorded.

Training data constraints should address:

1. excluded data, including protected knowledge, Indigenous protocol-sensitive data where applicable, youth data, health-sensitive data, personal data, community-sensitive data, public authority-sensitive data, cyber-sensitive data, infrastructure-sensitive data, geospatial-sensitive data, handoff-recipient-only data, archive-only data, sealed data, recalled data, withdrawn data, and non-continuing data unless expressly and lawfully permitted;
2. permission basis, including license, data-sharing agreement, consent, steward approval, public authority permission where applicable, community process, Indigenous governance pathway where applicable, or other lawful basis;
3. environment limits, including secure-room-only, data-room-only, clean-room-only, compute-to-data-only, sovereign-zone-only, or restricted training conditions;
4. retention limits, including whether training files, embeddings, logs, checkpoints, fine-tuned weights, evaluation outputs, and derivative artifacts may be retained, deleted, sealed, returned, archived, or recalled;
5. downstream limits, including whether the resulting model may be used for retrieval, summarization, classification, evaluation, public-safe drafting, agentic workflows, Studio workflows, Marketplace listing, Registry support, Grid support, Nexus Universe use, or handoff context;
6. correction feasibility, including what happens if source data is corrected, withdrawn, recalled, deleted, or found unauthorized after training.

Training constraints are not administrative friction. They are AI legitimacy controls. Nexus should never launder restricted data into model behavior. Training permission is narrow, recorded, and revocable or correctable where possible. It does not authorize deployment, automated decision-making, procurement, finance, insurance, public authority action, consent, or execution.

### 11.5.3 Evaluation Records

Evaluation Records document how AI systems, models, retrieval workflows, classifiers, agentic workflows, forecasting models, simulation models, digital twin models, risk models, optimization models, decision-support models, public-safe AI workflows, and evaluation harnesses have been tested, reviewed, compared, challenged, or assessed within defined scope.

Evaluation Records should be created before AI outputs are used in Reports, Marketplace listings, Registry records, Grid or TRL inputs, Studio workflows, Academy materials, Campaign materials, National Portfolio objects, Nexus Universe outputs, public authority learning materials, finance-readiness materials, insurance-readiness materials, donor-readiness materials, or handoff packages where the AI output materially affects meaning.

An Evaluation Record should identify:

1. system evaluated, including model, version, workflow, retrieval corpus, tool permissions, prompt pattern, runtime environment, or agent configuration;
2. evaluation purpose, including accuracy, robustness, bias, hallucination, source fidelity, retrieval quality, classification performance, public-safe language, security, tool-use safety, data leakage, prompt-injection resistance, accessibility, or handoff suitability;
3. evaluation materials, including benchmark datasets, test prompts, red-team scenarios, public-safe examples, synthetic data, controlled data, secure-room data, human review rubrics, expert review notes, or adversarial tests;
4. evaluation environment, including open, controlled, secure room, data room, clean room, compute-to-data, Studio, National Node, or handoff-context environment;
5. results and limitations, including performance, failure modes, false positives, false negatives, hallucinations, bias findings, leakage findings, uncertainty, confidence, out-of-scope uses, and unresolved risks;
6. required controls, including human review, output review, access restriction, public-safe review, tool-permission restriction, model restriction, suspension, withdrawal, recall, or archive;
7. re-evaluation triggers, including model version change, corpus change, tool change, data-use change, AI-use label change, source correction, incident, drift, Nexus Universe use, handoff preparation, or public release.

Evaluation Records are evidence, not certification. They show what was tested and what was found. They do not guarantee safety for all uses, authorize deployment, approve procurement, determine financeability, determine insurability, create public authority action, grant consent, or execute implementation.

### 11.5.4 Bias and Harm Review

Bias and harm review is the AI safety control for identifying whether an AI system, model, classifier, retrieval workflow, forecasting model, simulation model, digital twin model, risk model, optimization model, decision-support model, agentic workflow, public-safe output, or AI-assisted report may produce unfair, discriminatory, misleading, stigmatizing, extractive, inaccessible, unsafe, culturally inappropriate, rights-impairing, or otherwise harmful outcomes.

Bias and harm review should examine:

1. data bias, including missingness, sampling bias, historical bias, measurement bias, proxy variables, unequal representation, geographic bias, language bias, digital divide effects, and exclusion of vulnerable populations;
2. model bias, including disparate error rates, false positives, false negatives, overgeneralization, stereotyping, ranking bias, classification bias, hallucinated certainty, and unsafe inference;
3. public-safe harm, including panic, false reassurance, stigma, reputational harm, public authority confusion, media misuse, geospatial exposure, and risk sensationalism;
4. community harm, including extraction, misrepresentation, consent overclaim, dignity harm, vulnerability exposure, and loss of local context;
5. Indigenous protocol harm where applicable, including protected knowledge exposure, cultural misinterpretation, governance bypass, data sovereignty breach, mapping harm, AI ingestion without permission, and rights waiver implication;
6. institutional harm, including public authority overclaim, procurement implication, finance or insurance overclaim, provider validation, sponsor control, handoff overclaim, deployment implication, and execution implication;
7. accessibility harm, including outputs that exclude persons with disabilities, low-bandwidth users, non-expert audiences, non-dominant language communities, or youth participants where appropriate.

A Bias and Harm Review Record should identify the system or output reviewed, affected groups or contexts, test methods, findings, severity, mitigation, residual risk, public-safe requirements, human-review requirements, restricted-use requirements, correction pathway, withdrawal or recall pathway, and archive treatment.

Bias and harm review does not certify fairness or safety. It creates a disciplined review record and prevents unreviewed outputs from becoming public meaning, institutional status, handoff context, or operational suggestion.

### 11.5.5 Prompt-Injection Controls

Prompt-injection controls are AI security controls that prevent malicious, accidental, hidden, or adversarial instructions from causing an AI system or agentic workflow to ignore rules, reveal sensitive data, misuse tools, alter records, bypass access controls, publish unsafe outputs, misstate source status, or execute prohibited actions.

Prompt-injection risk arises where AI systems read web pages, documents, repository files, emails, reports, data-room materials, comments, metadata, user submissions, public-facing content, provider-contributed materials, sponsor materials, community inputs, public authority learning materials, or handoff packages that may contain embedded instructions or manipulative content.

Prompt-injection controls should include:

1. instruction hierarchy discipline, ensuring system, governance, tool, room, data-use, AI-use, and human instructions override retrieved or user-provided content;
2. content isolation, treating retrieved records as data, not instructions;
3. tool-use gating, requiring explicit permission and human approval for write, publish, send, delete, export, handoff, Registry, Marketplace, Grid, or system-changing actions;
4. sensitive data protection, preventing the model from revealing restricted, protected, public authority-sensitive, cyber-sensitive, community-sensitive, Indigenous protocol-sensitive where applicable, or handoff-recipient-only content;
5. source verification, preventing injected content from being treated as authoritative without provenance and current status truth;
6. output review, checking for boundary overclaim, hidden instruction execution, source manipulation, hallucination, data leakage, or unsafe routing;
7. red-team testing, using adversarial documents, prompts, and retrieval scenarios to test resistance;
8. incident response, including kill-switch activation, access revocation, correction, recall, archive, and public repair where required.

Prompt-injection controls are essential where agents have tool permissions. A model that can only draft may produce bad text; a model that can use tools may create system effects. Prompt-injection control keeps AI assistance from becoming compromised action.

### 11.5.6 Tool-Permission Controls

Tool-permission controls govern which tools an AI system or agentic workflow may use, under what conditions, with what data, in what environment, with what logging, and subject to what human review. Tool-permission controls implement the practical boundary between AI assistance and unauthorized action.

Tool-permission controls should define:

1. permitted tools, including read-only retrieval, search, document access, repository read, calculator, code execution in controlled environments, schema validation, test execution, dashboard rendering, or draft generation;
2. restricted tools, including file write, repository write, API calls, database queries, data exports, external communications, calendar actions, publication systems, Marketplace systems, Registry systems, Grid systems, Studio runtime systems, and handoff-package systems;
3. prohibited tools, including autonomous public authority systems, procurement systems, finance systems, insurance systems, donor allocation systems, consent systems, operational control systems, emergency command systems, cyber action systems, production infrastructure, and unrestricted data export systems;
4. permission conditions, including human-in-the-loop approval, room-only use, no-download controls, no-write-back controls, no-command rules, output review, access expiry, and least privilege;
5. logging and audit, including tool call records, input and output records, user identity, object identity, execution notes, provenance notes, proof receipts, correction records, and incident records;
6. revocation and kill-switch, including immediate removal of permissions for misuse, incident, prompt-injection compromise, source-status failure, or boundary violation.

Tool permissions must not be broader than the workflow purpose. A summarization agent should not have write access to Registry status. A data-room assistant should not have public publishing rights. A Studio assistant should not have operational command rights. A handoff-preparation assistant should not be able to send final handoff packages without human approval.

Tool access is capability, not authority. Capability must remain constrained by Nexus governance.

### 11.5.7 Logging

Logging is the AI safety and security control that records material AI-system activity so that outputs, tool use, data access, source retrieval, agent actions, reviews, corrections, incidents, and archive decisions can be audited, corrected, recalled, and learned from.

Logging should be proportionate to risk and privacy. Nexus should log enough to preserve accountability without creating unnecessary retention of sensitive data, protected knowledge, personal data, youth data, health-sensitive data, public authority-sensitive material, cyber-sensitive material, or confidential room content.

AI logging may include:

1. system identity, model version, agent version, workflow card, and runtime environment;
2. user or role, subject to privacy and access controls;
3. input class, including data-use label, AI-use label, access class, and sensitivity class;
4. retrieval sources, including object identifiers, versions, Registry status, correction status, and archive status;
5. tool calls, including tool name, purpose, inputs, outputs, permission basis, and approval record where required;
6. outputs, including draft status, review status, public-safe status, correction status, and release class;
7. human review, including reviewer, decision, conditions, and corrections;
8. incidents and escalations, including trigger, containment, kill-switch, correction, recall, and archive;
9. retention and deletion, including what logs are retained, restricted, sealed, deleted, or archived.

Logs themselves may be sensitive and should carry access controls, retention rules, deletion rules, sealing rules, and archive rules. Logging is not surveillance. It is accountability infrastructure. It should not be used to bypass confidentiality, extract protected knowledge, profile users improperly, or create public authority, employment, finance, insurance, or procurement consequences by implication.

### 11.5.8 Red-Team Records

Red-team records document adversarial testing, misuse testing, failure probing, boundary testing, prompt-injection testing, data leakage testing, bias testing, public-safe overclaim testing, tool-permission testing, agentic workflow testing, retrieval contamination testing, cyber testing, and scenario testing of AI systems and workflows.

Red-team activity may test whether an AI system can be induced to:

1. reveal restricted data;
2. expose protected knowledge;
3. misuse public authority-sensitive information;
4. leak cyber or infrastructure-sensitive information;
5. hallucinate sources or status truth;
6. ignore no-command rules;
7. bypass no-write-back rules;
8. publish without review;
9. create procurement, finance, insurance, public authority, consent, deployment, or execution overclaims;
10. misuse tools;
11. follow prompt-injection instructions;
12. generate unsafe public-safe outputs;
13. mishandle community-sensitive or Indigenous protocol-sensitive content where applicable;
14. prepare handoff packages without authority.

A Red-Team Record should identify the system tested, test scope, tester class, scenarios used, data classes involved, findings, severity, mitigations, retest results, residual risks, release implications, support implications, correction pathway, suspension or withdrawal decision, and archive treatment.

Red-team records may themselves be sensitive. Attack details, exploit paths, prompt-injection strings, data leakage examples, vulnerability details, and unsafe outputs should be controlled, redacted, or public-safe transformed before broader disclosure.

Red-team success or failure is not certification. It is a structured stress test that improves safety and correctionability.

### 11.5.9 Drift Detection

Drift detection is the AI safety control for identifying when an AI system, model, classifier, retrieval workflow, forecasting model, simulation model, risk model, digital twin model, optimization model, decision-support model, or agentic workflow no longer behaves as expected because data, context, users, prompts, model versions, retrieval corpora, tool permissions, source objects, public-safe requirements, or real-world conditions have changed.

Drift may include:

1. data drift, where input data changes in distribution, quality, source, missingness, geography, language, or sensitivity;
2. concept drift, where the relationship between inputs and outputs changes;
3. model drift, where model behavior changes due to version updates, provider changes, fine-tuning, configuration changes, or degradation;
4. retrieval drift, where corpus updates, archive changes, supersession, withdrawal, recall, or indexing changes alter source grounding;
5. workflow drift, where users begin using a system for purposes beyond recorded scope;
6. public-safe drift, where outputs become unsafe due to changed context, media environment, public authority context, community concern, or sensitivity change;
7. boundary drift, where AI outputs begin implying certification, procurement, finance, insurance, public authority action, consent, deployment, or execution.

A Drift Detection Record should identify monitored system, baseline behavior, monitoring method, drift indicators, thresholds, detected change, severity, affected outputs, affected objects, required human review, release implications, correction pathway, suspension, withdrawal, recall, archive, or non-continuation decision.

Drift detection recognizes that AI safety is not a one-time review. A model that was acceptable for one use at one time may become unsafe later. Drift triggers correction before trust erodes.

### 11.5.10 AI Incident Response

AI incident response is the process for identifying, containing, assessing, correcting, notifying, recalling, restricting, suspending, withdrawing, archiving, or publicly repairing failures or suspected failures involving AI systems, model objects, agentic workflows, retrieval systems, classifiers, AI-assisted outputs, AI-use labels, tool permissions, data-use violations, public-safe releases, or AI-related handoff context.

AI incidents may include:

1. unauthorized AI use of restricted data;
2. unauthorized training, fine-tuning, embedding, retrieval, summarization, classification, or agentic use;
3. protected knowledge exposure;
4. Indigenous protocol-sensitive exposure where applicable;
5. personal, youth, health, community, public authority, cyber, infrastructure, or geospatial-sensitive data exposure;
6. hallucinated source, false citation, or false status-truth claim;
7. public authority, procurement, finance, insurance, donor, consent, deployment, or execution overclaim;
8. unauthorized tool use;
9. prompt-injection compromise;
10. unauthorized write-back, publication, listing, registration, Grid update, or handoff package preparation;
11. biased or harmful output;
12. model drift or retrieval drift causing unsafe output;
13. output review failure;
14. failure to escalate;
15. failure to activate kill-switch when required.

An AI Incident Record should identify the AI system, model, workflow, version, data affected, outputs affected, users or recipients affected, severity, discovery date, containment steps, kill-switch status, human reviewer, legal or governance review, public-safe risk, notification duties, correction steps, withdrawal or recall needs, Marketplace and Registry updates, Studio shutdowns, Grid updates, Reports corrections, National Portfolio updates, Nexus Universe updates, handoff-recipient notices, archive treatment, and closure conditions.

AI incident response should prioritize containment, correction, transparency within safe limits, and prevention of further reliance. It should neither hide AI failures nor over-disclose sensitive details. It is a core expression of correctionability.

### 11.5.11 Model Withdrawal

Model withdrawal is the lifecycle action by which an AI model, model version, model interface, fine-tuned model, retrieval-augmented system, classifier, agentic workflow, evaluation harness, forecasting model, simulation model, risk model, optimization model, decision-support model, or digital twin model is removed from current use within Nexus, or from a specific pathway, because continued use is unsafe, unauthorized, unsupported, outdated, rights-constrained, public-safe-inappropriate, biased beyond acceptable mitigation, drifted, compromised, overclaiming, or no longer aligned with Nexus purpose.

Model withdrawal may be triggered by:

1. data rights violation;
2. AI-use permission failure;
3. protected knowledge exposure;
4. privacy or cyber incident;
5. prompt-injection vulnerability;
6. tool-permission misuse;
7. bias or harm finding;
8. evaluation failure;
9. drift;
10. dependency compromise;
11. provider term change;
12. unsupported model status;
13. public-safe output failure;
14. public authority boundary overclaim;
15. finance, insurance, procurement, consent, deployment, or execution overclaim;
16. handoff package error;
17. superior successor model;
18. non-continuation decision.

A Model Withdrawal Record should identify the model or workflow withdrawn, affected versions, withdrawal reason, effective date, affected pathways, affected outputs, affected users, affected repositories, affected Studio workflows, affected Marketplace listings, affected Registry records, affected Grid or TRL records, affected Reports, affected National Portfolio objects, affected Nexus Universe outputs, affected handoff packages, replacement or successor if any, required notifications, correction and recall actions, archive treatment, and reinstatement conditions if any.

Withdrawal is stronger than deprecation. It means the model should not be used within the stated scope. It does not erase prior records; it prevents current reliance and enables correction.

### 11.5.12 Archive

Archive is the AI lifecycle control for preserving AI system records, model cards, system cards, benchmark cards, agent workflow cards, evaluation records, red-team records, drift records, AI incident records, model withdrawal records, logs, prompts where appropriate, tool-use records, output records, correction records, public-safe review records, Nexus Universe AI records, Studio AI records, Grid or TRL AI records, Marketplace AI records, Registry AI records, National Portfolio AI records, and handoff-context AI records as institutional memory without current authority.

AI archive should identify:

1. archived AI object, including model, system, workflow, interface, classifier, harness, output set, or record family;
2. prior lifecycle state, including supported, restricted, public-safe, Studio-ready, Grid-classified, withdrawn, recalled, superseded, deprecated, suspended, or non-continuing;
3. archive date and steward;
4. archive reason;
5. access class, including open, controlled, restricted, secure-room-only, data-room-only, protected-knowledge-controlled, public authority-sensitive, cyber-sensitive, handoff-recipient-only, sealed, or archive-only;
6. data-use and AI-use restrictions after archive;
7. sensitive logs, prompts, outputs, red-team materials, and incident materials requiring restriction or sealing;
8. successor model or workflow where applicable;
9. citation and reuse restrictions;
10. correction and public repair history;
11. non-current authority notice.

Archived AI objects must not be treated as current, supported, safe, public-safe, deployable, handoff-ready, certified, procurement-ready, financeable, insurable, public-authority-approved, consented, or executable. Archive preserves memory, evaluation history, correctionability, and institutional learning without preserving current power.

The final AI Safety and Security Controls rule is: AI safety requires provenance, training constraints, evaluation records, bias and harm review, prompt-injection controls, tool-permission controls, logging, red-team records, drift detection, incident response, model withdrawal, and archive; each control creates traceability, containment, correction, and learning; none creates certification, warranty, procurement, finance, insurance, public authority action, consent, deployment, or execution by implication.

## 11.6 AI Boundaries

### 11.6.1 Model Card Is Not AI Safety Certification

A Model Card is not AI safety certification. A Model Card is a public-good record that describes an AI model’s identity, purpose, source context, intended uses, prohibited uses, data conditions, evaluation history, limitations, human-review requirements, public-safe constraints, lifecycle state, correction pathway, and archive rule. It makes a model legible. It does not certify that the model is safe, lawful, fair, secure, reliable, deployable, procurement-ready, financeable, insurable, publicly approved, consented, or fit for operational use.

A Model Card may support responsible review by showing what is known, what is not known, what was evaluated, what data conditions apply, what risks have been identified, what restrictions exist, and what human controls are required. That record may be useful for Nexus Studio, Reports, Academy, Registry, Marketplace, Grid, TRL, National Portfolio, Nexus Universe, public authority learning, capital-reader learning, insurance-reader learning, donor-reader learning, and handoff-context pathways. Its usefulness does not convert it into a conformity assessment, safety clearance, assurance certificate, regulatory approval, procurement qualification, or operational approval.

A Model Card should therefore carry clear boundary language stating that:

1. model documentation is not safety certification;
2. model evaluation history is not universal validation;
3. intended-use description is not deployment authorization;
4. limitations disclosure is not risk acceptance;
5. human-review requirement is not legal compliance assurance;
6. Registry status is not certification;
7. Marketplace listing is not procurement recommendation;
8. Grid or TRL relationship is not financeability or insurability;
9. handoff context is not recipient authorization;
10. archive preservation is not current validity.

AI safety certification, where applicable, requires a separate competent authority, standard, legal basis, assurance process, evidence threshold, test procedure, review scope, term, withdrawal rule, accountability structure, and decision record. A Nexus Model Card may inform such a process. It does not replace it.

### 11.6.2 Benchmark Result Is Not General Validation

A benchmark result is not general validation. A benchmark result states how a model, AI workflow, classifier, retrieval system, agentic workflow, evaluation harness, dashboard, simulation, digital twin, risk model, optimization model, or decision-support model performed on a defined test, dataset, task, scenario, rubric, environment, or review procedure. It does not prove that the model or system is generally safe, accurate, fair, secure, lawful, robust, public-safe, deployment-ready, procurement-ready, financeable, insurable, consented, or fit for all contexts.

Benchmark meaning depends on the benchmark’s scope. A benchmark may cover one language, one geography, one risk domain, one data type, one task, one model behavior, one hazard class, one software configuration, one evaluation environment, one public-safe output pattern, or one adversarial scenario. Results may be affected by dataset construction, leakage, overfitting, sample bias, missingness, task design, metric choice, scoring rules, prompt design, model version, retrieval corpus, tool permissions, evaluator subjectivity, and downstream interpretation.

A Benchmark Result Record should make clear:

1. what was evaluated;
2. what was not evaluated;
3. what dataset, task, rubric, or scenario was used;
4. what version, configuration, and environment applied;
5. what metrics were used;
6. what limitations, uncertainty, and bias risks remain;
7. whether the benchmark is current, superseded, withdrawn, recalled, archived, or non-continuing;
8. what correction or retest pathway applies.

Benchmark results may support evidence, learning, review, comparison, Grid or TRL routing, Studio readiness, Registry status, Marketplace discoverability, Reports, Academy materials, Nexus Universe demonstrations, and handoff context. They do not create general validation. A high score does not authorize deployment. A passing benchmark does not certify safety. A model that performs well in one evaluation may fail in another setting. Benchmarking is evidence within scope, not authority beyond scope.

### 11.6.3 Agent Output Is Not Determination

An agent output is not determination. An agentic workflow may draft text, retrieve sources, summarize materials, classify objects, propose metadata, generate code, assemble tables, produce public-safe candidate language, create review notes, suggest Marketplace listing language, draft Registry entries, prepare Grid or TRL inputs, support Studio workflows, prepare National Portfolio materials, support Nexus Universe production, or draft handoff-context packages. Those outputs remain draft, review-support, or workflow-support objects until a competent human or pathway reviews, accepts, records, and releases them within scope.

An agent output must not be treated as:

1. final Registry status;
2. final Marketplace listing;
3. final Grid or TRL classification;
4. final public-safe Report;
5. final National Portfolio status;
6. final Nexus Universe output;
7. final handoff package;
8. certification;
9. procurement recommendation;
10. finance-readiness determination;
11. insurance-readiness determination;
12. donor-readiness determination;
13. public authority decision;
14. community or Indigenous consent record where applicable;
15. deployment authorization;
16. execution instruction.

Agent outputs may be useful because they accelerate drafting, routing, comparison, review preparation, documentation, and correction discovery. That usefulness increases the need for visible boundaries. Every material agent output should carry output status, source references where relevant, AI-use label, human-review requirement, public-safe status, correction pathway, and no-conversion notices.

The boundary rule is direct: an agent may produce language or structure; it does not determine institutional truth. Determination requires the competent Nexus pathway or separate competent external actor to act through recorded authority.

### 11.6.4 AI Workflow Is Not Public Authority Decision

An AI workflow is not public authority decision. An AI workflow may process data, classify information, summarize records, generate dashboards, support DRI indicators, assist Observatory interpretation, produce public-safe candidate outputs, run simulations, support digital twin scenarios, prepare public authority learning materials, or draft questions for public-sector participants. None of those functions becomes a permit, license, public warning, emergency command, regulatory decision, enforcement action, compliance finding, statutory classification, public finance allocation, procurement decision, policy adoption, or governmental approval by default.

Public authority decisions require competent public actors acting under their own lawful mandates, procedures, records, duties, accountability frameworks, and applicable law. Nexus AI workflows may support public authority learning, but they do not substitute for the state, regulator, agency, municipality, public utility, emergency body, public finance actor, or other public institution.

An AI workflow connected to public authority learning should make clear:

1. the workflow is for learning, analysis, simulation, review, or context only;
2. public authority participation is not approval;
3. dashboard output is not official status;
4. DRI output is not public warning;
5. simulation output is not emergency command;
6. AI classification is not regulatory classification;
7. public-safe summary is not public notice;
8. handoff context is not public authorization;
9. public authority action, if any, must occur separately through the competent public authority’s own process.

AI workflows may be especially persuasive when they are visual, fast, data-rich, or presented in official-adjacent rooms. The more official the context appears, the stronger the boundary language must be. Nexus must prevent AI-assisted public authority learning from becoming public authority action by implication.

### 11.6.5 Model Release Is Not Deployment Authorization

A model release is not deployment authorization. Releasing, documenting, publishing, listing, registering, demonstrating, benchmarking, evaluating, open-sourcing, fine-tuning, presenting, or handing off a model does not authorize live deployment, production use, public authority use, operational use, enterprise implementation, infrastructure integration, automated decision-making, community implementation, or field use.

A model release may provide model files, API access, documentation, a Model Card, System Card, Benchmark Card, evaluation records, source context, intended-use notes, prohibited-use notes, license terms, support status, public-safe status, Registry status, Marketplace listing, Grid or TRL context, Studio demonstration, Nexus Universe presentation, or handoff-context package. Those materials may help a downstream actor evaluate the model. They do not substitute for deployment governance.

Deployment requires a separate competent actor to address:

1. lawful basis and responsibility;
2. data rights and AI-use permissions;
3. privacy, cybersecurity, protected knowledge, and sovereignty controls;
4. human oversight and appeal or contestability where required;
5. bias, harm, drift, robustness, and incident controls;
6. public authority approval where required;
7. procurement where required;
8. finance and insurance where required;
9. community or Indigenous consent where required;
10. operational support, monitoring, rollback, and liability;
11. documentation, audit, correction, withdrawal, recall, and archive.

A model may be suitable for learning, review, Studio demonstration, or handoff context and still be unsuitable for deployment. Model release makes an object available within recorded conditions. It does not authorize real-world use.

### 11.6.6 Evaluation Is Not Financeability, Insurability, or Procurement Readiness

Evaluation is not financeability, insurability, or procurement readiness. AI evaluation may test model performance, bias, robustness, hallucination, retrieval quality, prompt-injection resistance, tool safety, drift, public-safe output quality, benchmark performance, or workflow reliability. These evaluations may support Nexus Grid, TRL, Registry, Marketplace, Reports, Studio, Nexus Universe, National Portfolio, capital-reader rooms, insurance-reader rooms, donor-reader rooms, public finance learning rooms, and handoff-context pathways. They do not determine that a project, model, software object, provider, workflow, dashboard, dataset, system, or handoff package is financeable, insurable, or procurement-ready.

Financeability depends on separate legal, commercial, technical, financial, risk, governance, contractual, regulatory, sponsor, revenue, cost, diligence, capital-structure, public finance, donor, and implementation considerations. Insurability depends on separate underwriting, exposure, vulnerability, risk engineering, loss history, coverage, exclusions, pricing, claims, regulatory, reinsurance, and market considerations. Procurement readiness depends on separate procurement law, budget authority, specifications, conflicts, competition, evaluation criteria, contracting authority, security requirements, public authority procedures, and supplier diligence.

An AI evaluation may contribute to these discussions only as bounded evidence. It may identify strengths, gaps, dependencies, risks, data limitations, model limitations, public-safe issues, cybersecurity concerns, support status, or unresolved handoff conditions. It must not be represented as:

1. investment advice;
2. bankability determination;
3. financeability determination;
4. valuation;
5. credit approval;
6. insurance approval;
7. underwriting decision;
8. premium indication;
9. procurement recommendation;
10. vendor qualification;
11. public finance allocation;
12. donor commitment;
13. contract award;
14. implementation authorization.

Evaluation improves legibility. It does not execute capital, insurance, donor, public finance, or procurement decisions. Those decisions belong to separate competent actors acting under their own lawful processes.

The final AI Boundaries rule is: Model Cards document without certifying; benchmark results evidence without generally validating; agent outputs draft without determining; AI workflows support public authority learning without public authority action; model releases make objects available without deployment authorization; evaluations improve understanding without creating financeability, insurability, or procurement readiness. AI may support Nexus intelligence, but it never becomes authority by implication.

<br>


---

# Agent Instructions: 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:

```
GET https://docs.therisk.global/organization/standardization/nexus-ecosystem/ii.-structure/xi.-ai.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
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.