# XI. AI

Nexus Agile Framework AI defines the **NAF AI governance model** for AI systems, frontier models, foundation-model interfaces, agentic workflows, AI safety, AI security, and human oversight. This section explains how **model cards, system cards, benchmark cards, AI-use labels, evaluation records, safety controls, and review gates** govern AI across Nexus workflows.

This section sets the operating model for **AI system governance**, **model and system documentation**, **agentic workflow controls**, **AI-use labels**, **AI safety and security controls**, and **human review requirements**. It helps Nexus use AI for evidence, analysis, translation, drafting, and public-safe reporting without creating automated authority, certification, deployment approval, or execution by implication.

### What this section covers

* **AI governance** - Defines AI systems, frontier models, model objects, and governed AI records.
* **AI safety and security** - Explains evaluation, benchmark records, prompt-injection controls, tool permissions, and incident response.
* **Human oversight and boundaries** - Defines AI-use labels, review requirements, no-automated-authority rules, and deployment boundaries.

Use this section with [Nexus Agile Framework (NAF)](/organization/operations/frameworks/nexus-agile-framework-naf.md) for the full framework overview, [IX. SOFTWARE](/organization/operations/frameworks/nexus-agile-framework-naf/ix.-software.md) for software governance and secure release controls, and [X. DATA](/organization/operations/frameworks/nexus-agile-framework-naf/x.-data.md) for data governance, AI-use labels, controlled rooms, and compute-to-data boundaries.

## 11.1 AI Governance Doctrine

### 11.1.1 AI System as Governed Object.

11.1.1.1 An AI System within NAF shall mean any model, model interface, foundation-model interface, fine-tuned model, retrieval-augmented system, classifier, forecasting system, simulation model, digital twin model, risk model, optimization model, decision-support model, evaluation harness, AI-assisted workflow, agentic workflow, automated analysis component, AI-enabled dashboard, AI-enabled Studio workflow, AI-enabled DRI process, AI-enabled Observatory process, AI-enabled Reports process, AI-enabled Academy process, AI-enabled Campaign process, AI-enabled Marketplace process, AI-enabled Registry process, AI-enabled Grid or TRL review process, or AI-enabled handoff dependency process used, created, reviewed, routed, displayed, released, restricted, corrected, archived, or handed off within NAF.

11.1.1.2 Every AI System shall be governed as a recorded object, not as an invisible feature. It shall carry identity, purpose, steward, owner or lawful controller where applicable, maintainer, contributor record, model class, system class, agent class where applicable, data provenance, training or configuration basis where applicable, retrieval basis where applicable, tool permissions where applicable, intended use, prohibited use, human review requirement, AI-use label, data-use label, access class, release class, support class, public-safe status, safeguard status, security status, privacy status, bias and harm review status, evaluation status, incident pathway, correction pathway, withdrawal pathway, and archive rule.

11.1.1.3 AI Systems shall be integrated into NAF only through defined records, review gates, release classes, public-safe controls, secure-room rules where applicable, data-room rules where applicable, compute-to-data rules where applicable, Registry status, Marketplace notices where applicable, Grid inputs where applicable, TRL notes where applicable, Nexus Universe presentation controls where applicable, and handoff dependency boundaries where applicable.

11.1.1.4 AI Systems shall not be treated as neutral infrastructure merely because they are embedded inside software, dashboards, workflows, reports, repositories, APIs, Studio environments, data rooms, secure rooms, or enterprise tools. Where AI influences meaning, classification, prioritization, summarization, routing, evidence generation, intelligence generation, review, publication, learning, or handoff context, its presence shall be recorded and governed.

11.1.1.5 AI Systems within NAF shall support public-good evidence, learning, translation, simulation, observability, analysis, drafting, evaluation, risk intelligence, accessibility, localization, software production, data processing, public-safe reporting, and lawful handoff context. They shall not create automated authority, public authority action, certification, procurement status, financeability, insurability, consent, deployment authorization, emergency command, operational command, employment decision, credential decision, or execution by implication.

### 11.1.2 Model Object as Evidence-Bearing Record.

11.1.2.1 A Model Object shall be treated as evidence-bearing only to the extent that its purpose, scope, architecture or interface, data basis, training or configuration basis where applicable, retrieval basis where applicable, evaluation basis, benchmark basis, assumptions, limitations, uncertainty, bias and harm review, public-safe status, security status, privacy status, human review requirement, intended use, prohibited use, support class, release class, correction pathway, and archive rule are recorded.

11.1.2.2 A Model Object may support analysis, classification, summarization, forecasting, scenario generation, optimization, simulation, digital twin workflows, risk interpretation, DRI indicators, Observatory signals, Studio demonstrations, Reports, Academy learning, Foundry builds, Campaign outputs, Marketplace descriptions, Registry records, Grid inputs, TRL notes, Nexus Universe outputs, National Portfolio memory, and handoff dependency context.

11.1.2.3 Model evidence shall remain bounded. A model that performs well in one benchmark, context, dataset, testbed, simulation, language, jurisdiction, sector, hazard domain, or release class shall not be presumed valid for another. Model Object records shall state domain limits, data limits, evaluation limits, model drift risks, human review requirements, public-safe limitations, and prohibited uses.

11.1.2.4 A Model Object shall not be treated as AI safety certification, scientific truth, legal determination, public authority decision, risk rating, insurance score, investment signal, procurement qualification, operational command, deployment authorization, or execution instruction.

### 11.1.3 Agentic Workflow as Controlled Runtime Object.

11.1.3.1 An Agentic Workflow shall mean any AI-enabled workflow capable of planning, chaining tasks, invoking tools, retrieving data, writing outputs, calling APIs, interacting with repositories, interacting with dashboards, creating or modifying records, proposing actions, monitoring conditions, routing work, generating code, evaluating content, or assisting operational processes beyond a single static response.

11.1.3.2 Agentic Workflows shall be treated as controlled runtime objects. They shall require agent identity, purpose, scope, authorized tools, prohibited tools, data access limits, write permissions, no-write-back rules where applicable, no-command rules where applicable, human-in-the-loop requirements, human-on-the-loop requirements, escalation triggers, kill-switch conditions, logging where appropriate, output review, incident pathway, correction pathway, suspension pathway, withdrawal pathway, and archive rule.

11.1.3.3 Agentic Workflows shall be restricted by default in public authority-sensitive, finance-sensitive, insurance-sensitive, procurement-sensitive, community-sensitive, Indigenous protocol-sensitive where applicable, health-sensitive, cyber-sensitive, infrastructure-sensitive, geospatial-sensitive, protected knowledge, youth, and handoff-recipient-only contexts unless specifically reviewed and recorded.

11.1.3.4 An Agentic Workflow shall not issue public warnings, make public authority decisions, allocate finance, approve insurance, recommend procurement, authorize access beyond recorded permissions, create consent, deploy systems, operate infrastructure, command emergency response, execute transactions, submit official filings, bind institutions, or act as an agent of Nexus, GCRI, The Global Risks Forum (GRF), The Global Risks Alliance (GRA), a public authority, a National Consortium Company, a Project SPV, a provider, a sponsor, a community, or any lawful implementation actor unless separately and lawfully authorized outside NAF’s default posture.

### 11.1.4 Model Card as Public-Good Record.

11.1.4.1 A Model Card shall be the primary public-good record for a Model Object. It shall document model identity, model class, purpose, intended use, prohibited use, domain, jurisdictional context where applicable, data provenance, training or configuration status where applicable, retrieval basis where applicable, evaluation records, benchmark records, limitations, uncertainty, bias and harm review, security status, privacy status, public-safe status, accessibility considerations, language limitations, human review requirements, AI-use label, release class, support class, incident pathway, correction pathway, withdrawal rule, and archive rule.

11.1.4.2 A Model Card shall be required where a model materially affects evidence, classification, public-safe reporting, risk intelligence, DRI indicators, Observatory signals, Studio workflows, dashboard outputs, Reports, Academy learning, Foundry production, Marketplace descriptions, Registry records, Grid inputs, TRL notes, Nexus Universe outputs, National Portfolio records, or handoff dependency packages.

11.1.4.3 A Model Card may be open, public-safe, controlled, secure-room-only, data-room-only, handoff-recipient-only, or archive-only depending on sensitivity, rights, security, public-safe status, and dual-use risk.

11.1.4.4 A Model Card shall not be represented as AI safety certification, regulatory approval, standards conformance certification, public authority approval, procurement qualification, financeability, insurability, deployment authorization, or warranty.

### 11.1.5 System Card as Public-Good Record.

11.1.5.1 A System Card shall be the primary public-good record for an AI-enabled system composed of models, data, software, APIs, retrieval systems, tools, dashboards, workflows, humans, governance controls, access controls, logging, output review, and correction mechanisms.

11.1.5.2 A System Card shall document system purpose, architecture, components, dependencies, data flows, model objects, agentic workflows where applicable, tool permissions, user roles, access classes, data-use labels, AI-use labels, cybersecurity controls, privacy controls, human review requirements, public-safe output controls, safeguard controls, known limitations, release class, support class, incident pathway, correction pathway, shutdown conditions, withdrawal conditions, and archive rule.

11.1.5.3 A System Card shall be required for AI-enabled Studio workflows, DRI dashboards, Observatory systems, public-safe reporting systems, Registry systems, Marketplace systems, Grid or TRL review systems, secure-room AI systems, data-room AI systems, compute-to-data AI workflows, Nexus Universe AI demonstrations, and handoff-relevant AI workflows.

11.1.5.4 A System Card shall not be system certification, security certification, privacy compliance determination, public authority approval, procurement approval, financeability, insurance approval, deployment authorization, operational command, or execution authority.

### 11.1.6 Benchmark Card as Public-Good Record.

11.1.6.1 A Benchmark Card shall document benchmark purpose, benchmark scope, dataset basis, task definition, metric definition, evaluation conditions, model or system version, test environment, assumptions, limitations, confidence, uncertainty, bias and harm considerations, reproducibility status, public-safe interpretation, reviewer record, correction pathway, and archive rule.

11.1.6.2 Benchmark Cards shall be used where model, system, dashboard, DRI, Observatory, Studio, software, data, or readiness claims rely on performance testing, comparative evaluation, regression testing, robustness evaluation, bias testing, red-team evaluation, stress testing, or other measured results.

11.1.6.3 Benchmark Cards shall state clearly what a benchmark result does and does not establish. A benchmark result may support bounded evidence, but it shall not create general validation, AI safety certification, security certification, procurement readiness, financeability, insurability, public authority approval, deployment authorization, or execution.

### 11.1.7 Human Review as Default Control.

11.1.7.1 Human Review shall be the default control for AI use within NAF where AI affects meaning, evidence, classification, prioritization, routing, public-safe reporting, data transformation, risk intelligence, DRI indicators, Observatory interpretation, Studio outputs, Reports, Marketplace listings, Registry records, Grid inputs, TRL notes, National Portfolio records, Nexus Universe outputs, or handoff dependency packages.

11.1.7.2 Human Review may be structured as human-in-the-loop, human-on-the-loop, expert review, maintainer review, public-safe review, safeguard review, data steward review, AI-use review, cyber review, privacy review, public authority boundary review, finance boundary review, procurement boundary review, community safeguard review, Indigenous protocol review where applicable, or handoff review.

11.1.7.3 Human Review shall be recorded where material. Records shall identify reviewer role, review scope, review date, issue findings, limitations, unresolved concerns, correction actions, escalation needs, release class impact, and archive status.

11.1.7.4 Human Review shall not convert AI outputs into certification, public authority approval, financeability, insurability, procurement readiness, consent, deployment authorization, or execution. Human Review is a control; it is not universal validation.

### 11.1.8 AI Without Automated Authority by Default.

11.1.8.1 AI within NAF shall have no automated authority by default. No AI System, Model Object, Agentic Workflow, AI-enabled dashboard, AI-generated Report, AI-generated summary, AI classification, AI score, AI recommendation, AI-generated Docket item, AI-generated Registry record, AI-generated Marketplace listing, AI-generated Grid input, AI-generated TRL note, AI-generated National Portfolio record, AI-generated Nexus Universe output, or AI-generated handoff note shall be treated as authoritative without recorded human review and lawful context.

11.1.8.2 AI shall not make or substitute for public authority decisions, finance decisions, insurance decisions, procurement decisions, employment decisions, credential decisions, community consent determinations, Indigenous consent determinations where applicable, legal determinations, medical determinations, public warnings, emergency commands, operational commands, deployment decisions, or execution decisions within NAF’s default posture.

11.1.8.3 AI may accelerate learning, drafting, analysis, classification, summarization, coding, testing, translation, accessibility, review support, scenario generation, simulation support, and evidence organization, but speed shall not override public-good records, validity-by-record, correctionability, public-safe review, safeguard review, human oversight, role separation, lawful handoff boundaries, or no-conversion rules.

## 11.2 AI Object Classes

### 11.2.1 Statistical Models.

11.2.1.1 Statistical Models are mathematical or statistical structures used to describe, estimate, infer, classify, forecast, compare, explain, or summarize relationships in data. They may support DRI indicators, risk analysis, Observatory summaries, Reports, dashboards, Studio scenarios, National Portfolio analysis, public authority learning, readiness questions, and handoff dependency context.

11.2.1.2 Statistical Models shall carry model purpose, data basis, assumptions, variables, limitations, uncertainty, confidence where applicable, evaluation method, bias considerations, public-safe status, review status, correction pathway, and archive rule.

11.2.1.3 Statistical Models shall not create forecast certainty, public warning, official statistics by implication, public authority decision, insurance score, investment signal, procurement score, deployment authorization, or execution.

### 11.2.2 Machine-Learning Models.

11.2.2.1 Machine-Learning Models are trained or fitted models that learn patterns from data for classification, prediction, clustering, ranking, recommendation, anomaly detection, generation, or other analytical tasks.

11.2.2.2 Machine-Learning Models shall carry a Model Card, training or fitting data constraints where known, data provenance, evaluation records, benchmark records where applicable, bias and harm review, security review where applicable, privacy review where applicable, intended use, prohibited use, human review requirement, drift monitoring requirement where applicable, correction pathway, withdrawal rule, and archive rule.

11.2.2.3 Machine-Learning outputs shall not be treated as determinations, approvals, ratings, warnings, public authority decisions, finance decisions, insurance decisions, procurement decisions, employment decisions, credential decisions, consent determinations, deployment authorizations, or execution instructions.

### 11.2.3 Foundation-Model Interfaces.

11.2.3.1 Foundation-Model Interfaces are controlled interfaces to large-scale general-purpose models, frontier models, multimodal models, language models, code models, vision models, audio models, or other general model services used for retrieval, summarization, drafting, classification, translation, coding, analysis, simulation support, or workflow assistance within NAF.

11.2.3.2 Foundation-Model Interfaces shall be governed by provider record, model or service identity where available, data handling terms, retention terms, confidentiality status, jurisdictional status, permitted uses, prohibited uses, AI-use labels, prompt and output logging rules where appropriate, human review requirement, public-safe output review, tool permissions where applicable, and incident pathway.

11.2.3.3 Foundation-Model Interfaces shall not be used with restricted, public authority-sensitive, community-sensitive, Indigenous protocol-sensitive where applicable, health-sensitive, cyber-sensitive, infrastructure-sensitive, geospatial-sensitive, protected knowledge, or handoff-recipient-only data unless the AI-use label, data-use label, rights review, room controls, and security review permit such use.

11.2.3.4 Foundation-Model Interface availability shall not create AI safety certification, provider validation, procurement status, data right, public authority approval, deployment authorization, or execution.

### 11.2.4 Fine-Tuned Models.

11.2.4.1 Fine-Tuned Models are models adapted using additional data, examples, instructions, domain-specific material, or parameter updates for NAF-specific purposes, including risk intelligence, public-safe reporting, controlled vocabulary, code generation, classification, translation, dashboard support, DRI interpretation, Studio workflows, Academy learning, or document drafting.

11.2.4.2 Fine-Tuning shall require recorded authority to use data for such purpose, AI-use labels permitting fine-tuning, rights review, privacy review, protected knowledge review, community safeguard review, Indigenous protocol review where applicable, security review, evaluation records, bias and harm review, Model Card update, System Card update where applicable, correction pathway, withdrawal rule, and archive rule.

11.2.4.3 Fine-Tuned Models shall not be trained on data without recorded permission. Fine-tuning shall not create ownership of source knowledge, unrestricted data rights, certification, public authority approval, financeability, procurement readiness, deployment authorization, or execution.

### 11.2.5 Retrieval-Augmented Systems.

11.2.5.1 Retrieval-Augmented Systems are AI systems that retrieve, index, search, embed, summarize, cite, or synthesize content from controlled or open knowledge sources, including repositories, Reports, Registry records, Marketplace records, DICE objects, GRIx objects, DRI records, Observatory records, Academy content, Studio outputs, National Portfolio records, Nexus Universe records, and handoff dependency materials.

11.2.5.2 Retrieval-Augmented Systems shall record source scope, source authority, source freshness, access controls, indexing method, embedding permissions, AI-use labels, data-use labels, citation and provenance requirements, public-safe output rules, restricted source handling, hallucination controls, human review requirements, correction pathway, and archive rule.

11.2.5.3 Retrieval does not create truth. A retrieved or synthesized answer shall not be treated as authority unless it is grounded, reviewed, and bounded by records. Retrieval-Augmented Systems shall not create public authority decisions, legal determinations, finance decisions, procurement decisions, certification, consent, deployment authorization, or execution.

### 11.2.6 Agentic Workflows.

11.2.6.1 Agentic Workflows are AI-enabled runtime objects that can plan, route, invoke tools, interact with systems, generate or modify records, produce code, propose actions, monitor signals, or perform multi-step tasks. They shall be governed as higher-risk AI objects due to their capacity to affect workflow and records.

11.2.6.2 Agentic Workflows shall require agent identity, system card, authorized tools, prohibited tools, data boundaries, output boundaries, no-command rules, no-write-back rules where applicable, escalation triggers, kill-switch conditions, logs where appropriate, human oversight, public-safe review, security review, correction pathway, suspension rule, withdrawal rule, and archive rule.

11.2.6.3 Agentic Workflows shall not make binding decisions, execute transactions, control infrastructure, send public warnings, authorize deployment, approve procurement, allocate finance, issue insurance decisions, create public authority action, grant consent, or act as legal or institutional agent by implication.

### 11.2.7 Classifiers.

11.2.7.1 Classifiers are models or AI-assisted processes that assign labels, categories, classes, priorities, risk groupings, data classes, AI-use labels, public-safe categories, Docket routing labels, Registry statuses, Marketplace categories, Grid inputs, TRL notes, or other classifications.

11.2.7.2 Classifiers shall be governed by label definitions, training or rule basis, evaluation records, error analysis, bias and harm review, confidence thresholds, human review requirements, appeal or correction process, prohibited uses, and archive rule.

11.2.7.3 Classifier output shall not be treated as final determination where the classification affects rights, access, public authority sensitivity, finance sensitivity, procurement sensitivity, consent, community status, Indigenous protocol status where applicable, employment, credentialing, public release, or handoff. Human review shall apply in material cases.

### 11.2.8 Forecasting Models.

11.2.8.1 Forecasting Models are models used to estimate possible future conditions, trends, risks, scenarios, demand, hazards, resource needs, systems stress, labor needs, infrastructure needs, climate-related conditions, DRI signals, or portfolio trajectories.

11.2.8.2 Forecasting Models shall record forecast horizon, data basis, assumptions, uncertainty, confidence, limitations, update cadence, sensitivity, evaluation basis, public-safe interpretation, no-warning notice where applicable, human review requirement, correction pathway, and archive rule.

11.2.8.3 Forecasting outputs shall not be treated as certainty, public warning, official forecast, insurance score, investment signal, procurement signal, public authority decision, emergency command, deployment authorization, or execution instruction.

### 11.2.9 Simulation Models.

11.2.9.1 Simulation Models are models used to explore scenarios, stress tests, system behaviors, digital twins, disaster-risk pathways, WFEH-B cascades, infrastructure interactions, cyber-physical behavior, climate impacts, finance-readiness questions, public authority learning, or Nexus Universe demonstrations.

11.2.9.2 Simulation Models shall record scenario scope, assumptions, inputs, outputs, uncertainty, sensitivity, limitations, data basis, model basis, public-safe interpretation, human review requirement, prohibited uses, correction pathway, and archive rule.

11.2.9.3 Simulation shall not create forecast certainty, public warning, certification, public authority decision, financeability, insurability, procurement readiness, deployment authorization, operational command, or execution.

### 11.2.10 Digital Twin Models.

11.2.10.1 Digital Twin Models are representations of systems, assets, environments, hazards, infrastructure, WFEH-B systems, disaster-risk contexts, sensor-linked environments, public authority learning contexts, readiness contexts, or handoff contexts used for scenario learning, visualization, simulation, monitoring, or analysis.

11.2.10.2 Digital Twin Models shall record source data, update cadence, spatial scope, system boundaries, assumptions, missing data, sensitivity, geospatial controls, cyber controls, public-safe controls, public authority boundaries, model limitations, human review requirements, correction pathway, and archive rule.

11.2.10.3 A Digital Twin Model shall not be operational control, official map, public warning, public authority decision, infrastructure command, deployment authorization, or execution.

### 11.2.11 Risk Models.

11.2.11.1 Risk Models are models used to analyze hazards, exposure, vulnerability, capacity, likelihood, consequence, cascading risk, systemic risk, financial exposure questions, insurance-readiness questions, resilience gaps, DRI indicators, or National Portfolio risk context.

11.2.11.2 Risk Models shall record risk taxonomy, GRIx mapping, data basis, assumptions, uncertainty, confidence, limitations, scope, public-safe status, no-rating status where applicable, no-warning status where applicable, finance and insurance boundary notices, human review requirement, correction pathway, and archive rule.

11.2.11.3 Risk Models shall not create ratings, public warnings, insurance scores, investment signals, financeability, procurement scores, official risk determinations, public authority decisions, deployment authorization, or execution.

### 11.2.12 Optimization Models.

11.2.12.1 Optimization Models are models used to evaluate possible allocations, schedules, routes, configurations, resource uses, infrastructure choices, portfolio sequences, data processing paths, or design trade-offs.

11.2.12.2 Optimization Models shall record objective function, constraints, assumptions, data basis, excluded variables, fairness considerations, sensitivity, limitations, human review requirements, prohibited uses, public authority boundary notices, finance and procurement boundary notices, correction pathway, and archive rule.

11.2.12.3 Optimization outputs shall not allocate resources, approve procurement, direct public authority action, choose vendors, bind budgets, determine finance, command operations, authorize deployment, or execute implementation.

### 11.2.13 Decision-Support Models.

11.2.13.1 Decision-Support Models are models intended to help humans understand evidence, compare scenarios, identify dependencies, map options, summarize risk, structure questions, or prepare readiness context. They shall be designed as support tools only.

11.2.13.2 Decision-Support Models shall carry prominent notices that the model supports learning and review, not decision authority. They shall include intended user class, review requirement, limitations, uncertainty, prohibited decisions, public authority boundary notices, finance and procurement boundary notices, safeguard notices, correction pathway, and archive rule.

11.2.13.3 Decision-Support output shall not be a decision, approval, certification, public warning, finance decision, insurance decision, procurement recommendation, consent, deployment authorization, or execution instruction.

### 11.2.14 Evaluation Harnesses.

11.2.14.1 Evaluation Harnesses are tools, tests, scripts, benchmark systems, red-team workflows, data validation systems, model evaluation systems, robustness tests, bias tests, security tests, prompt-injection tests, regression tests, or public-safe output tests used to evaluate AI Systems or AI-enabled workflows.

11.2.14.2 Evaluation Harnesses shall record evaluation purpose, test scope, dataset, method, environment, metrics, limitations, expected outputs, result interpretation, reproducibility status, benchmark card linkage where applicable, correction pathway, and archive rule.

11.2.14.3 Evaluation Harness results shall not create general validation, AI safety certification, security certification, procurement readiness, financeability, insurability, public authority approval, deployment authorization, or execution.

## 11.3 AI-Use Labels

### 11.3.1 No-AI Use.

11.3.1.1 No-AI Use shall mean that a data object, knowledge object, workflow, room, record, or output shall not be processed by AI systems for retrieval, summarization, classification, embedding, training, fine-tuning, generation, agentic workflow, or evaluation unless the label is changed through recorded review.

11.3.1.2 No-AI Use shall apply where rights, privacy, community safeguards, Indigenous protocols where applicable, protected knowledge, public authority sensitivity, youth sensitivity, health sensitivity, cyber sensitivity, infrastructure sensitivity, geospatial sensitivity, confidentiality, contract, or dual-use risk requires exclusion.

11.3.1.3 Violation of No-AI Use shall be treated as an AI incident and data incident, requiring containment, correction, access review, output review, Registry update where applicable, Marketplace update where applicable, handoff recall where applicable, and archive update.

### 11.3.2 Retrieval-Only.

11.3.2.1 Retrieval-Only shall mean that AI systems may retrieve or surface relevant material under access controls but shall not summarize, transform, classify, embed externally, train, fine-tune, generate derivative outputs, or use agentic workflows beyond the recorded retrieval function unless separately permitted.

11.3.2.2 Retrieval-Only shall be used where source fidelity, citation, and provenance are required and where transformation could create overclaim, hallucination, protected knowledge exposure, rights breach, or public-safe risk.

11.3.2.3 Retrieval-Only output shall carry source references, access limits, and no-authority notices where material.

### 11.3.3 Summarization With Review.

11.3.3.1 Summarization With Review shall mean that AI may produce summaries, abstracts, notes, briefings, translations, public-safe drafts, or internal working summaries only subject to human review before reliance, publication, listing, Registry recording, Grid input, TRL note, Nexus Universe presentation, National Portfolio inclusion, or handoff packaging.

11.3.3.2 Summaries shall be checked for accuracy, omission, distortion, false certainty, overclaim, public authority boundary issues, finance and procurement boundary issues, protected knowledge exposure, sensitive data exposure, community sensitivity, Indigenous protocol sensitivity where applicable, and public-safe status.

11.3.3.3 AI summaries shall not be treated as evidence by themselves. The underlying sources and review record shall control.

### 11.3.4 Classification With Review.

11.3.4.1 Classification With Review shall mean that AI may propose labels, categories, data classes, risk classes, Docket routes, Registry statuses, Marketplace categories, public-safe categories, safeguard flags, Grid inputs, TRL note components, or handoff dependency classes only subject to human review where classification has material effect.

11.3.4.2 AI-proposed classifications shall include confidence where available, source basis, uncertainty, and review requirement. Sensitive classifications shall not be finalized without qualified review.

11.3.4.3 AI classification shall not determine rights, access, public authority status, financeability, procurement status, certification, consent, deployment authorization, or execution.

### 11.3.5 Evaluation-Only.

11.3.5.1 Evaluation-Only shall mean that AI systems or AI-related data may be used solely to test, benchmark, review, red-team, compare, validate within scope, or assess models, prompts, workflows, outputs, or controls, without use for production, public release, automated decisions, training, fine-tuning, or agentic actions.

11.3.5.2 Evaluation-Only use shall record evaluation scope, test data, metrics, limitations, results, reviewer, correction pathway, and archive rule.

11.3.5.3 Evaluation-Only results shall not create general validation, certification, public authority approval, financeability, procurement readiness, deployment authorization, or execution.

### 11.3.6 Fine-Tuning Permitted.

11.3.6.1 Fine-Tuning Permitted shall mean that a data object or knowledge object may be used to adapt a model within recorded scope, subject to rights review, consent or permission where required, privacy review, public-safe review, safeguard review, protected knowledge review, Indigenous protocol review where applicable, security review, evaluation requirements, and withdrawal conditions.

11.3.6.2 Fine-tuning permission shall specify model, purpose, data scope, retention, output restrictions, public-safe rules, access controls, derivative model status, downstream restrictions, correction pathway, and archive rule.

11.3.6.3 Fine-Tuning Permitted shall not imply general AI training permission, public release permission, ownership transfer, certification, deployment authorization, or execution.

### 11.3.7 Training Permitted.

11.3.7.1 Training Permitted shall mean that a data object or knowledge object may be used for model training within recorded scope and under recorded authority. This label shall require heightened rights review, privacy review, data protection review, safeguard review, community review where applicable, Indigenous protocol review where applicable, protected knowledge review, security review, public-safe review, and downstream control review.

11.3.7.2 Training permission shall be explicit as to purpose, model class, permitted users, permitted environment, retention, derivative model status, withdrawal or exclusion rights where applicable, public release status, prohibited uses, correction pathway, and archive rule.

11.3.7.3 Training Permitted shall not create unrestricted use, public release right, model ownership right, certification, public authority approval, financeability, procurement readiness, deployment authorization, or execution.

### 11.3.8 Agentic Use Prohibited.

11.3.8.1 Agentic Use Prohibited shall mean that AI may not use the data, system, workflow, record, or environment in any multi-step tool-using, task-planning, API-calling, record-modifying, repository-writing, dashboard-changing, routing, monitoring, or autonomous workflow.

11.3.8.2 Agentic Use Prohibited shall be applied by default to high-risk contexts, including public authority-sensitive data, finance-sensitive data, procurement-sensitive data, community-sensitive data, Indigenous protocol-sensitive data where applicable, protected knowledge, youth data, health data, cyber-sensitive data, infrastructure-sensitive data, geospatial-sensitive data, and handoff-recipient-only materials unless otherwise reviewed and recorded.

11.3.8.3 Violation of Agentic Use Prohibited shall trigger agentic incident response, access review, output review, correction, suspension, withdrawal, and archive update.

### 11.3.9 Secure-Room AI Only.

11.3.9.1 Secure-Room AI Only shall mean that AI use is permitted only inside an approved secure room, data room, clean room, protected knowledge room, public authority learning room, readiness room, or other controlled environment with defined access, logging where appropriate, no-download controls where appropriate, output review, and public-safe restrictions.

11.3.9.2 Secure-Room AI Only shall prohibit uncontrolled external model use, unmanaged retention, uncontrolled export, public release, and agentic use unless specifically authorized.

11.3.9.3 Secure-room AI outputs shall not leave the room unless output review approves their export, summary, public-safe release, Registry recording, Marketplace listing, Reports use, Grid input, TRL note, Nexus Universe use, National Portfolio use, or handoff package use.

### 11.3.10 Public-Safe AI Output Only.

11.3.10.1 Public-Safe AI Output Only shall mean that AI may produce outputs only after review or transformation sufficient to prevent disclosure of restricted data, personal data, protected knowledge, sensitive geospatial information, cyber-sensitive information, biosecurity-sensitive information, public authority-sensitive information, community-sensitive information, Indigenous protocol-sensitive information where applicable, or harmful technical detail.

11.3.10.2 Public-safe AI outputs shall include limitations, source basis where appropriate, no-warning notices where appropriate, no-approval notices, no-finance notices, no-procurement notices, no-certification notices, no-consent notices, no-deployment notices, and no-execution notices where material.

11.3.10.3 Public-Safe AI Output Only shall not create public authority approval, certification, financeability, procurement readiness, consent, deployment authorization, or execution.

## 11.4 Agentic Workflow Controls

### 11.4.1 Agent Identity.

11.4.1.1 Every Agentic Workflow shall have a recorded Agent Identity. Agent Identity shall include name, purpose, steward, maintainer, system owner where applicable, authorized environment, model or model interface, tool list, data access class, write permissions, human oversight role, release class, support class, incident contact, correction pathway, suspension pathway, and archive rule.

11.4.1.2 Agent Identity shall be visible to authorized users and recorded in System Cards, tool permission records, access control records, logs where appropriate, Registry records where applicable, Marketplace descriptions where applicable, Studio workflow records where applicable, and handoff dependency records where applicable.

11.4.1.3 No anonymous or unrecorded Agentic Workflow shall modify records, access restricted data, call tools, interact with repositories, produce public-facing outputs, route Dockets, affect Registry status, affect Marketplace status, affect Grid inputs, affect TRL notes, or prepare handoff dependency packages.

### 11.4.2 Tool Permissions.

11.4.2.1 Tool Permissions shall define what an Agentic Workflow may read, retrieve, summarize, classify, draft, write, edit, call, execute, submit, export, or route. Tool Permissions shall be least-privilege, purpose-bound, environment-bound, time-bound where appropriate, and reviewable.

11.4.2.2 Tool Permissions shall distinguish between read-only tools, retrieval tools, drafting tools, analysis tools, code generation tools, repository tools, issue tools, dashboard tools, Registry tools, Marketplace tools, Studio tools, Reports tools, data tools, secure-room tools, public authority learning tools, readiness-room tools, handoff tools, and external APIs.

11.4.2.3 High-risk tool permissions, including write access, delete access, export access, external API calls, infrastructure changes, public publishing, Registry status changes, Marketplace listing changes, handoff package creation, or communication with public authorities or capital readers, shall require specific approval and human oversight.

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

11.4.3.1 Human-in-the-Loop shall mean that an authorized human must review and approve a defined AI action before the action is completed, released, published, routed, recorded, exported, handed off, or otherwise made effective.

11.4.3.2 Human-in-the-Loop shall be required by default for public-facing outputs, public-safe summaries, Registry status changes, Marketplace listings, Grid inputs, TRL notes, DRI outputs, Observatory public outputs, National Portfolio records, Nexus Universe materials, handoff dependency packages, secure-room exports, data-room exports, protected knowledge summaries, public authority-sensitive outputs, finance-readiness outputs, insurance-readiness outputs, procurement-sensitive outputs, and community-sensitive outputs.

11.4.3.3 Human approval shall be recorded where material and shall not convert the AI output into certification, public authority approval, financeability, procurement readiness, consent, deployment authorization, or execution.

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

11.4.4.1 Human-on-the-Loop shall mean that an authorized human supervises an AI workflow, monitors outputs, reviews exceptions, receives alerts, can pause or stop the workflow, and performs periodic review without approving every low-risk action individually.

11.4.4.2 Human-on-the-Loop may be permitted for low-risk, internal, reversible, non-sensitive, non-public, non-executing workflows where the AI action does not determine rights, status, authority, public-safe release, finance readiness, procurement readiness, consent, deployment, or handoff.

11.4.4.3 Human-on-the-Loop shall require monitoring rules, exception thresholds, escalation triggers, audit records where appropriate, periodic review, correction pathway, and kill-switch conditions.

### 11.4.5 No-Command Rules.

11.4.5.1 No-Command Rules shall prohibit Agentic Workflows from issuing operational commands, emergency commands, infrastructure commands, public authority commands, field commands, drone or robotics commands, OT/IoT/IIoT commands, network commands, cyber operational commands, public warning messages, or deployment instructions unless separately and lawfully authorized outside NAF’s default posture.

11.4.5.2 No-Command Rules shall apply especially to Studio workflows, digital twins, Observatory workflows, DRI workflows, infrastructure dashboards, public authority learning environments, emergency-management contexts, cyber-sensitive contexts, telecom and network contexts, robotics and drone contexts, and handoff contexts.

11.4.5.3 Violation of No-Command Rules shall trigger stop-the-line, incident response, access suspension, output review, correction, recall where necessary, and archive update.

### 11.4.6 No-Write-Back Rules.

11.4.6.1 No-Write-Back Rules shall prohibit AI systems from modifying source systems, official records, Registry statuses, Marketplace listings, public authority materials, finance materials, procurement materials, National Portfolio records, DRI records, Observatory records, Studio records, Grid records, TRL notes, handoff packages, repositories, datasets, dashboards, or controlled-room outputs without approved human review and recorded permission.

11.4.6.2 No-Write-Back shall be the default for AI interactions with restricted data, public authority-sensitive systems, community-sensitive systems, Indigenous protocol-sensitive systems where applicable, health-sensitive systems, cyber-sensitive systems, infrastructure-sensitive systems, geospatial-sensitive systems, secure rooms, data rooms, clean rooms, capital-reader rooms, insurance-reader rooms, donor-reader rooms, and handoff-recipient-only environments.

11.4.6.3 Where write-back is permitted, it shall be scoped, logged where appropriate, reversible where possible, reviewable, and subject to correction and rollback.

### 11.4.7 Output Review.

11.4.7.1 Output Review shall apply to AI outputs before they are used as evidence, published, displayed, listed, recorded, routed, included in Reports, added to Registry, listed in Marketplace, used in Studio, used as Grid input, used as TRL note, presented in Nexus Universe, included in National Portfolios, or packaged for handoff.

11.4.7.2 Output Review shall assess accuracy, source grounding, hallucination risk, omission risk, bias, harmful content, public-safe status, data leakage, protected knowledge exposure, sensitive geospatial exposure, cyber-sensitive exposure, biosecurity-sensitive exposure, community sensitivity, Indigenous protocol sensitivity where applicable, public authority overclaim, finance overclaim, procurement overclaim, certification overclaim, consent overclaim, deployment overclaim, and execution overclaim.

11.4.7.3 AI outputs that fail review shall be corrected, restricted, withdrawn, archived, or discarded.

### 11.4.8 Escalation Triggers.

11.4.8.1 Escalation Triggers shall define conditions requiring human review, maintainer review, steward review, legal review, data review, AI review, cyber review, privacy review, public-safe review, safeguard review, public authority boundary review, finance boundary review, procurement boundary review, community safeguard review, Indigenous protocol review where applicable, or stop-the-line action.

11.4.8.2 Escalation Triggers shall include uncertainty above threshold, hallucination indicators, missing source grounding, restricted data exposure, protected knowledge exposure, public authority-sensitive output, finance-sensitive output, procurement-sensitive output, cyber-sensitive output, health-sensitive output, geospatial-sensitive output, community-sensitive output, Indigenous protocol-sensitive output where applicable, tool permission anomaly, attempted write-back, attempted command, abnormal behavior, drift detection, user misuse, and incident report.

11.4.8.3 Escalation shall be recorded where material and shall include disposition, correction, restriction, release decision, archive decision, and downstream notice where required.

### 11.4.9 Kill-Switch Conditions.

11.4.9.1 Kill-Switch Conditions shall define when an Agentic Workflow or AI-enabled system must be paused, suspended, disabled, disconnected, restricted, withdrawn, or archived. Conditions may include unauthorized tool use, unauthorized data access, attempted command, attempted write-back, data leakage, protected knowledge exposure, cyber risk, repeated hallucination, unsafe output, public authority overclaim, finance overclaim, procurement overclaim, consent overclaim, security incident, privacy incident, bias or harm incident, drift, model degradation, or failure of human oversight.

11.4.9.2 Kill-switch activation shall trigger incident response, access review, output review, correction, Registry update where applicable, Marketplace action where applicable, Reports correction where applicable, Studio restriction where applicable, Grid correction where applicable, TRL correction where applicable, handoff recall where applicable, and archive update.

11.4.9.3 Kill-switch activation is a trust-preserving control and shall not be treated as institutional failure by default. Failure to activate when required is the greater risk.

### 11.4.10 Agentic Incident Records.

11.4.10.1 Agentic Incident Records shall document failures, misuse, unauthorized access, unauthorized tool use, attempted write-back, attempted command, harmful output, data leakage, protected knowledge exposure, public authority overclaim, finance or procurement overclaim, consent overclaim, hallucination affecting material records, security events, privacy events, bias and harm events, drift, oversight failure, kill-switch activation, suspension, correction, withdrawal, recall, and archive.

11.4.10.2 Agentic Incident Records shall identify affected systems, data, users, outputs, records, pathways, releases, Registry entries, Marketplace listings, Reports, Studio workflows, Grid inputs, TRL notes, National Portfolio records, Nexus Universe outputs, and handoff packages where applicable.

11.4.10.3 Agentic Incident Records shall be routed to Correction Registers, Archive Registers, security or privacy processes where applicable, public-safe notices where necessary, and boundary repair actions where required.

## 11.5 AI Safety and Security Controls

### 11.5.1 Data Provenance.

11.5.1.1 AI Systems shall record Data Provenance for training data, fine-tuning data, retrieval sources, evaluation data, benchmark data, prompt context, system instructions, tool outputs, and generated outputs where material to evidence, public-safe reporting, Registry status, Marketplace listing, Grid input, TRL note, National Portfolio memory, Nexus Universe output, or handoff context.

11.5.1.2 Data Provenance shall include source, rights, license, data-use label, AI-use label, sensitivity, collection method where known, lineage, transformations, quality limitations, update cadence, jurisdictional context, public-safe status, correction pathway, and archive rule.

11.5.1.3 AI outputs without sufficient provenance shall be restricted, labeled as unverified, excluded from higher release classes, or routed for review and correction.

### 11.5.2 Training Data Constraints.

11.5.2.1 Training Data Constraints shall define what data may be used for model training, fine-tuning, embedding, retrieval indexing, evaluation, benchmarking, or agent memory. Constraints shall reflect rights, consent, permission, privacy, community safeguards, Indigenous protocols where applicable, protected knowledge, public authority sensitivity, cyber sensitivity, health sensitivity, infrastructure sensitivity, geospatial sensitivity, confidentiality, contract, data sovereignty, cross-border controls, and AI-use labels.

11.5.2.2 Training shall be prohibited where data is labeled No-AI Use, Retrieval-Only, Summarization With Review, Classification With Review, Evaluation-Only, Agentic Use Prohibited, Secure-Room AI Only without training permission, or Public-Safe AI Output Only without training permission.

11.5.2.3 Breach of Training Data Constraints shall trigger AI incident response, data incident response, model withdrawal review, output restriction, correction, notification where appropriate, Registry update, Marketplace action, handoff recall where applicable, and archive update.

### 11.5.3 Evaluation Records.

11.5.3.1 Evaluation Records shall document how an AI System, Model Object, or Agentic Workflow was tested before release, routing, publication, demonstration, use in Studio, use in DRI, use in Observatory, use in Reports, use in Marketplace, use in Registry, use in Grid, use in TRL, use in Nexus Universe, use in National Portfolios, or use in handoff dependency context.

11.5.3.2 Evaluation Records shall include task definition, dataset or scenario, metrics, test environment, model version, system version, limitations, failure modes, error examples where appropriate, bias and harm findings, security findings, red-team findings where applicable, reviewer record, public-safe interpretation, correction actions, and archive rule.

11.5.3.3 Evaluation Records shall not create general validation, certification, financeability, insurability, procurement readiness, public authority approval, deployment authorization, or execution.

### 11.5.4 Bias and Harm Review.

11.5.4.1 Bias and Harm Review shall assess whether an AI System may produce discriminatory, exclusionary, inaccurate, unsafe, stigmatizing, extractive, culturally harmful, accessibility-limiting, rights-affecting, community-harming, Indigenous protocol-breaching where applicable, or otherwise harmful outputs.

11.5.4.2 Bias and Harm Review shall consider affected users, communities, data subjects, workers, learners, youth, public authorities, vulnerable populations, disaster-affected populations, climate-affected populations, communities whose data is used, and downstream lawful recipients.

11.5.4.3 Where bias or harm risk is material, controls may include data correction, model correction, output restriction, human review, public-safe transformation, access limitation, safeguard review, community review, Indigenous protocol review where applicable, release class downgrade, withdrawal, or archive.

### 11.5.5 Prompt-Injection Controls.

11.5.5.1 Prompt-Injection Controls shall apply to AI Systems that use retrieval, external content, user input, tools, web content, documents, repositories, emails, data rooms, secure rooms, APIs, or multi-step workflows. Controls shall prevent malicious or unintended instructions from overriding system rules, data-use labels, AI-use labels, access controls, public-safe rules, no-command rules, no-write-back rules, or output review requirements.

11.5.5.2 Controls may include input filtering, instruction hierarchy, tool isolation, content sanitization, source trust labeling, retrieval constraints, restricted tool calls, output validation, human review, logging where appropriate, escalation triggers, and incident response.

11.5.5.3 Prompt-Injection Controls reduce risk but do not create security certification, warranty, deployment authorization, or execution authority.

### 11.5.6 Tool-Permission Controls.

11.5.6.1 Tool-Permission Controls shall restrict what AI Systems and Agentic Workflows may access, call, write, modify, delete, export, publish, or route. Permissions shall be least-privilege, scoped, reviewable, revocable, and aligned with AI-use labels, data-use labels, release classes, support classes, and room rules.

11.5.6.2 AI tool access shall be prohibited by default for high-risk actions, including public publication, Registry status change, Marketplace listing change, financial transaction, procurement communication, public authority communication, infrastructure command, data export, secret access, protected knowledge access, secure-room export, handoff package release, or deployment action unless specifically authorized and human-reviewed.

11.5.6.3 Tool-Permission failure shall be treated as an AI incident and, where applicable, cyber, privacy, data, public authority boundary, finance boundary, procurement boundary, protected knowledge, or handoff incident.

### 11.5.7 Logging.

11.5.7.1 Logging shall be used where appropriate to support accountability, security, reproducibility, incident response, correction, audit, access review, public-safe review, and archive. Logs may include model identity, system identity, user role, tool calls, data sources, prompt metadata, output metadata, access events, export events, review actions, correction actions, and kill-switch actions.

11.5.7.2 Logging shall be governed by privacy, data minimization, purpose limitation, retention, access control, security, youth protection, public authority sensitivity, protected knowledge, and cross-border rules. Logs shall not be retained or exposed beyond lawful and necessary purpose.

11.5.7.3 Logging shall not be used for unauthorized surveillance, worker ranking, learner ranking, social scoring, public authority profiling, community profiling, or unrelated monitoring.

### 11.5.8 Red-Team Records.

11.5.8.1 Red-Team Records shall document adversarial testing, misuse testing, stress testing, prompt-injection testing, jailbreak testing, bias testing, security testing, public-safe testing, data leakage testing, tool abuse testing, and boundary overclaim testing for AI Systems where risk warrants it.

11.5.8.2 Red-Team Records shall include scope, methods, findings, severity, mitigations, unresolved risks, release class implications, support implications, correction actions, reviewer records, public-safe summary where appropriate, and archive rule.

11.5.8.3 Red-Team Records may be restricted where public release would enable misuse. A public-safe summary may be produced where appropriate.

### 11.5.9 Drift Detection.

11.5.9.1 Drift Detection shall monitor whether AI System behavior, data distributions, retrieval sources, model performance, output quality, risk classification, bias, public-safe status, security posture, or user interaction patterns materially change over time.

11.5.9.2 Drift may trigger review, evaluation, retraining where permitted, reconfiguration, release downgrade, support class change, Registry update, Marketplace update, Reports correction, Studio restriction, Grid correction, TRL correction, Nexus Universe notice, handoff recall, suspension, withdrawal, or archive.

11.5.9.3 Drift Detection shall not create continuous monitoring authority over people, communities, public authorities, workers, learners, or protected groups beyond recorded purpose and lawful controls.

### 11.5.10 AI Incident Response.

11.5.10.1 AI Incident Response shall apply to hallucination affecting material records, unauthorized AI use, unauthorized training, unauthorized fine-tuning, unauthorized retrieval, data leakage, protected knowledge exposure, prompt-injection success, tool-permission failure, attempted command, attempted write-back, harmful output, bias or discrimination, public authority overclaim, finance overclaim, procurement overclaim, certification overclaim, consent overclaim, deployment overclaim, security breach, privacy breach, model drift, agentic malfunction, and failure of human oversight.

11.5.10.2 AI Incident Response may include immediate containment, AI-use freeze, data freeze, tool freeze, output freeze, claims freeze, access revocation, model withdrawal review, agent suspension, public-safe notice, affected party notice where appropriate, Registry update, Marketplace delisting, Report correction, Studio restriction, Grid correction, TRL correction, Nexus Universe correction, National Portfolio correction, handoff recall, deletion, sealing, archive, and non-continuation.

11.5.10.3 AI incidents shall be recorded in Correction Registers and Archive Registers and routed to relevant data, cyber, privacy, safeguard, public authority boundary, finance boundary, procurement boundary, handoff, and governance processes where applicable.

### 11.5.11 Model Withdrawal.

11.5.11.1 Model Withdrawal shall occur where a Model Object or AI System is no longer suitable for its release class, support class, use class, public-safe status, Registry status, Marketplace listing, Studio use, Reports use, Grid input, TRL note, Nexus Universe presentation, National Portfolio use, or handoff dependency package.

11.5.11.2 Withdrawal triggers may include unsafe output, rights breach, unauthorized training data, unresolved bias or harm, security flaw, privacy breach, protected knowledge exposure, public authority overclaim, finance or procurement overclaim, model drift, unsupported status, expired evaluation, flawed benchmark, incorrect Model Card, incorrect System Card, incident record, or steward decision.

11.5.11.3 Model Withdrawal shall include affected versions, affected outputs, affected records, successor model where any, user notice where appropriate, Registry update, Marketplace action, Reports correction, Studio restriction, Grid correction, TRL correction, Nexus Universe correction, handoff recall where applicable, and archive rule.

### 11.5.12 Archive.

11.5.12.1 AI Archives shall preserve Model Cards, System Cards, Benchmark Cards, Agent Workflow Cards, evaluation records, red-team records, data provenance records, AI-use labels, incident records, corrections, withdrawals, supersessions, release notes, support status, and archive-not-current notices.

11.5.12.2 AI Archives may be open, public-safe, controlled, secure-room-only, data-room-only, handoff-recipient-only, sealed, metadata-only, or deleted according to rights, privacy, security, protected knowledge, public authority sensitivity, community sensitivity, Indigenous protocol sensitivity where applicable, and retention rules.

11.5.12.3 Archive status shall not create current authority, current safety status, current readiness, current support, public authority approval, procurement status, financeability, deployment authorization, or execution.

## 11.6 AI Boundaries

### 11.6.1 Model Card Is Not AI Safety Certification.

11.6.1.1 A Model Card shall document a Model Object; it shall not certify the model as safe, compliant, secure, unbiased, accurate, production-ready, procurement-ready, financeable, insurable, publicly approved, or deployable.

11.6.1.2 AI safety certification, regulatory approval, security certification, professional certification, or deployment authorization, where required, must be obtained separately through competent lawful processes outside NAF’s default AI posture.

### 11.6.2 Benchmark Result Is Not General Validation.

11.6.2.1 A Benchmark Result shall be valid only within the benchmark scope, dataset, task, method, environment, model version, system version, and interpretation limits recorded in the Benchmark Card.

11.6.2.2 Benchmark Results shall not be generalized across domains, jurisdictions, populations, hazards, languages, data conditions, operational contexts, public authority contexts, finance contexts, insurance contexts, procurement contexts, or deployment contexts without additional review.

11.6.2.3 A Benchmark Result shall not create certification, public authority approval, financeability, insurability, procurement readiness, deployment authorization, or execution.

### 11.6.3 Agent Output Is Not Determination.

11.6.3.1 An Agent Output shall be a proposed or generated output subject to applicable review, not a determination. Agent outputs may support drafting, routing, summarization, classification, analysis, code generation, evidence organization, public-safe preparation, or handoff context, but shall not determine status, rights, authority, approval, consent, finance, procurement, insurance, deployment, or execution.

11.6.3.2 Agent Outputs affecting material records shall require review before release, publication, Registry recording, Marketplace listing, Grid input, TRL note, Nexus Universe use, National Portfolio use, or handoff package inclusion.

### 11.6.4 AI Workflow Is Not Public Authority Decision.

11.6.4.1 AI Workflows used in public authority learning, policy intelligence, disaster-risk learning, public finance learning, regulatory learning, public health learning, emergency management learning, infrastructure learning, or National Portfolio formation shall not be public authority decisions.

11.6.4.2 Public authority decisions must be separately and lawfully made by competent public authorities through their own processes. AI Workflows may support learning, evidence organization, scenario analysis, translation, and public-safe summaries; they shall not substitute for official action.

### 11.6.5 Model Release Is Not Deployment Authorization.

11.6.5.1 Release of a Model Object, AI System, agent workflow, model card, system card, benchmark card, evaluation harness, public-safe AI output, repository, API, dashboard, Studio workflow, Marketplace listing, Registry record, Grid input, TRL note, Nexus Universe demonstration, National Portfolio object, or handoff dependency package shall not authorize deployment.

11.6.5.2 Deployment requires separate lawful authority, operational accountability, security review, privacy review, data rights, public authority approvals where required, procurement approvals where required, finance and insurance decisions where relevant, community processes where required, Indigenous processes where applicable, and recipient responsibility.

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

11.6.6.1 AI evaluation, benchmarking, red-team review, model review, system review, Studio demonstration, Grid input, TRL note, Registry status, Marketplace listing, Nexus Universe presentation, or handoff dependency note shall not create financeability, bankability, investibility, insurability, underwriting readiness, donor approval, public finance allocation, procurement readiness, supplier approval, or vendor validation.

11.6.6.2 Capital readers, insurers, donors, public finance readers, procurement bodies, public authorities, National Consortium Companies, Project SPVs, providers, operators, and other lawful actors must conduct separate independent diligence and lawful decision processes.

11.6.6.3 The final AI rule of Part XI is that NAF may use AI to accelerate evidence, learning, classification, review, translation, software production, data processing, scenario analysis, observability, public-safe reporting, and lawful handoff context only through governed records, human oversight, AI-use labels, data-use labels, model cards, system cards, benchmark cards, agent workflow cards, safety controls, security controls, public-safe controls, safeguard controls, correctionability, withdrawal, archive, and no-conversion discipline. No AI System, Model Object, Agentic Workflow, AI output, model card, system card, benchmark card, evaluation result, red-team record, classifier label, forecast, simulation, digital twin, dashboard, public-safe summary, Registry record, Marketplace listing, Grid input, TRL note, Nexus Universe demonstration, National Portfolio object, or handoff dependency package shall become certification, public authority action, financeability, insurability, procurement readiness, legal determination, medical determination, consent, public warning, deployment authorization, operational command, agency, employment, or execution by implication.


---

# 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/operations/frameworks/nexus-agile-framework-naf/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.