# VI. MODELS ## 6.1 Model Commons Doctrine ### 6.1.1 Model object defined. A **Model Object** under DDPGF means any statistical, computational, machine-learning, simulation, forecasting, optimization, classification, decision-support, risk, benchmark, digital twin, or artificial-intelligence model that is created, adapted, referenced, evaluated, documented, listed, routed, used, displayed, tested, governed, corrected, archived, or lawfully handed off within the Nexus Ecosystem. A Model Object may include weights, parameters, prompts, embeddings, retrieval indexes, inference workflows, evaluation scripts, feature sets, model cards, benchmark cards, system cards, deployment-context notes, limitation notes, safety notes, bias and harm review records, data-provenance records, access-control records, incident records, correction records, withdrawal records, archive records, and lawful handoff dependency notes. A Model Object shall be treated as a governed digital public-good object only within its recorded scope. It shall not be treated as inherently safe, valid, reliable, deployable, financeable, insurable, procurement-ready, public authority-approved, community-approved, Indigenous-consented, operationally authorized, or execution-ready merely because it has been created, evaluated, published, open-sourced, listed in the Marketplace, recorded in the Registry, used in Studio, referenced in Reports, linked to Grid or TRL notes, presented at Nexus Universe, or included in a lawful handoff package. Every Model Object shall remain bounded by its purpose, intended use, prohibited use, data provenance, training constraints, evaluation evidence, review status, access class, support class, public-safe status, correction pathway, and archive rule. ### 6.1.2 AI system object defined. An **AI System Object** means a composite digital-public-good object that combines one or more models with data inputs, retrieval systems, prompts, tools, APIs, interfaces, orchestration layers, access controls, monitoring, human review, logging, output review, workflow rules, documentation, and governance controls. An AI System Object may include a foundation-model interface, fine-tuned model, retrieval-augmented system, classifier, forecasting system, decision-support workflow, dashboard-integrated model, Studio workflow, agentic workflow, digital twin component, simulation environment, public-safe reporting assistant, data-quality assistant, research assistant, code assistant, or other bounded AI-enabled capability. An AI System Object shall be governed as a system, not merely as an isolated model. Its safety, reliability, public-safe status, rights status, privacy posture, cybersecurity posture, bias and harm profile, and permissible use shall depend on the full system context, including source data, prompts, model behavior, tool permissions, user roles, output destinations, human oversight, environment controls, monitoring, and correction mechanisms. An AI System Object shall not create automated authority, public authority action, public warning, finance decision, insurance decision, procurement decision, employment decision, credentialing decision, consent determination, deployment authorization, or execution authority by default. ### 6.1.3 AI-agent object defined. An **AI-Agent Object** means an AI-enabled workflow, software object, model interface, orchestration pattern, or system component capable of pursuing tasks through tool calls, retrieval, planning, code execution, data processing, API access, file handling, message generation, workflow routing, simulation, dashboard interaction, or other action-like behavior. An AI-Agent Object may be used for research support, data preparation, documentation, public-safe drafting, code review, test generation, workflow assistance, triage, classification with review, summarization with review, Studio demonstrations, secure-room analysis, learning exercises, Foundry builds, or other controlled purposes. An AI-Agent Object shall be treated as a controlled runtime object with heightened governance. It shall require agent identity, purpose, scope, allowed tools, prohibited tools, access class, data-use label, AI-use label, human-in-the-loop or human-on-the-loop rules, no-command rules, no-write-back rules where applicable, output review, logging, escalation triggers, kill-switch conditions, incident response, correction, and archive. No AI-Agent Object shall be permitted to issue public authority decisions, execute transactions, command infrastructure, authorize deployment, approve finance, underwrite insurance, certify systems, procure goods or services, determine employment, grant credentials, infer consent, or act as a lawful execution agent unless separately authorized by competent lawful actors outside the DDPGF default posture. ### 6.1.4 Model card as public-good record. A **Model Card** shall be the primary public-good documentation record for a Model Object. It shall describe, at minimum where applicable, the model identity, version, steward, source pathway, purpose, intended use, prohibited use, model class, input types, output types, data provenance, training data constraints, evaluation records, benchmark records, known limitations, uncertainty, bias and harm review, safety review, cybersecurity considerations, privacy considerations, public-safe status, access class, support class, license or use-condition class, correction pathway, withdrawal pathway, archive rule, and boundary notices. A Model Card shall make a Model Object more legible, reviewable, reusable, and correctionable. It shall not certify the model as safe, fair, accurate, secure, unbiased, lawful, procurement-ready, financeable, insurable, public authority-approved, deployable, or fit for high-stakes use. A Model Card shall be treated as a governed record, not a substitute for independent review, legal compliance, public authority approval, professional judgment, operational validation, or recipient diligence. ### 6.1.5 System card as public-good record. A **System Card** shall document an AI System Object as an integrated socio-technical workflow. It shall describe the system purpose, users, operating context, model components, data components, retrieval sources, tool permissions, human review controls, output review rules, access controls, logging, monitoring, security controls, privacy controls, AI-use labels, data-use labels, public-safe controls, risk mitigations, limitations, failure modes, escalation pathways, incident response, correction pathway, shutdown triggers, support class, and archive rule. A System Card shall identify how the AI System Object behaves in context and what controls govern its use. It shall not convert an AI system into an approved decision system, certified safety system, public authority system, medical system, legal system, financial advisory system, insurance underwriting system, procurement evaluation system, employment screening system, emergency command system, or deployment-authorized system. A System Card shall preserve the distinction between documented workflow, bounded review, and lawful authority. ### 6.1.6 Benchmark card as public-good record. A **Benchmark Card** shall document any benchmark, evaluation suite, test dataset, evaluation harness, scoring method, red-team protocol, stress test, simulation test, digital twin test, safety evaluation, reliability evaluation, cybersecurity evaluation, bias evaluation, public-safe output test, or performance comparison used to assess a Model Object, AI System Object, AI-Agent Object, or AI workflow. It shall state the benchmark purpose, scope, source data, test conditions, evaluation method, metrics, limitations, representativeness, known gaps, sensitivity constraints, reproducibility status, update cadence, and correction pathway. A Benchmark Card shall prevent benchmark overclaim. A benchmark result shall be valid only within its recorded scope and shall not constitute general validation, AI safety certification, security certification, fairness certification, legal compliance, public authority approval, procurement readiness, financeability, insurability, deployment authorization, operational approval, or execution authority. Benchmark results shall remain correctionable and may be withdrawn, superseded, restricted, or archived. ### 6.1.7 AI workflow as controlled object. An **AI Workflow** shall be governed as a controlled object whenever AI is used to retrieve, summarize, classify, translate, draft, generate, evaluate, forecast, optimize, reason over, simulate, transform, enrich, route, decide-support, automate, or assist work within DDPGF. The workflow shall include the model or system used, input data, prompts, tools, access permissions, output destination, review requirements, logging, limitations, public-safe status, sensitivity status, escalation triggers, and correction pathway. AI workflows shall be designed to preserve human judgment, public-good discipline, source traceability, rights compliance, privacy protection, cybersecurity controls, safeguard controls, and role separation. They shall not create automated authority, hidden decision-making, invisible procurement influence, unreviewed public-safe outputs, uncontrolled data reuse, unrestricted model training, unapproved agentic action, or execution by implication. ### 6.1.8 AI release without safety certification by default. Release of a Model Object, AI System Object, AI-Agent Object, AI workflow, model card, system card, benchmark card, evaluation record, Studio demonstration, Marketplace listing, Registry record, Reports publication, Grid input, TRL note, Nexus Universe output, or handoff package shall not constitute AI safety certification by default. Release shall mean only that the object has reached the recorded lifecycle state and may be used, viewed, reviewed, learned from, tested, routed, listed, published, or handed off within the limits of its recorded access class, support class, purpose, intended use, prohibited use, review status, and boundary notices. Any claim of certification, compliance, regulatory approval, operational approval, procurement eligibility, public authority approval, financeability, insurability, deployment authorization, or execution readiness shall require separate lawful authority and separately recorded basis. DDPGF AI release shall remain evidence-bearing, bounded, reviewable, correctable, and non-executing by default. ## 6.2 Model Object Classes ### 6.2.1 Statistical models. Statistical models include regression models, Bayesian models, probabilistic models, time-series models, causal-inference models, survey models, sampling models, uncertainty models, risk models, and other mathematical representations used to estimate relationships, probabilities, distributions, trends, effects, uncertainty, or system behavior. Statistical models shall include assumptions, data provenance, variable definitions, limitations, uncertainty notes, validation records, and appropriate model-card documentation. Statistical model outputs shall not be treated as certainty, public authority decisions, public warnings, official forecasts, ratings, finance signals, insurance scores, procurement signals, deployment authorizations, or execution instructions. Their use shall remain bounded by assumptions, data quality, model specification, review status, and context. ### 6.2.2 Machine-learning models. Machine-learning models include supervised, unsupervised, semi-supervised, self-supervised, reinforcement-learning, deep-learning, ensemble, representation-learning, anomaly-detection, clustering, classification, regression, forecasting, generative, and other data-driven models. Machine-learning models shall require data provenance records, training constraints, evaluation records, bias and harm review, security review where applicable, privacy review where applicable, model cards, and correction pathways. Machine-learning performance shall be scope-specific. A machine-learning model shall not be treated as generally valid, safe, unbiased, lawful, deployable, procurement-ready, financeable, insurable, or public authority-approved merely because it performs well on one benchmark, dataset, or demonstration. ### 6.2.3 Foundation-model interfaces. Foundation-model interfaces include governed connections to large language models, multimodal models, code models, vision models, audio models, geospatial models, scientific foundation models, frontier models, or comparable general-purpose model systems. DDPGF may govern prompts, retrieval, tool use, access controls, system cards, output review, safety notices, and workflow records without necessarily governing the underlying foundation model itself where it is provided by an external provider. Foundation-model interfaces shall identify provider dependencies, data-use constraints, AI-use constraints, retention settings where applicable, privacy considerations, security considerations, prompt-injection risks, output limitations, hallucination risks, public-safe review needs, and support boundaries. Use of a foundation-model interface shall not validate the provider, certify the model, approve the system for deployment, or authorize high-stakes decisions. ### 6.2.4 Fine-tuned models. Fine-tuned models include models adapted through additional training, parameter updates, adapters, instruction tuning, domain tuning, reinforcement learning, preference tuning, or other specialization methods. Fine-tuned models shall include records of base model, training data, tuning method, intended use, prohibited use, evaluation results, bias and harm review, privacy review, security review, versioning, and withdrawal pathway. Fine-tuning permission for data shall be separately recorded. Fine-tuned model release shall not imply that the underlying data was open, that all rights are unrestricted, that privacy risks are eliminated, that protected knowledge is safe to encode, or that the model is approved for operational deployment. ### 6.2.5 Retrieval-augmented systems. Retrieval-augmented systems include workflows that combine a model with a retrieval corpus, vector index, knowledge base, document store, data commons, Registry records, Reports, Studio outputs, DRI records, Observatory records, National Portfolio records, or other sources. Such systems shall govern source eligibility, retrieval boundaries, access controls, citation discipline, prompt-injection controls, data leakage controls, output review, and correction propagation. Retrieval-augmented output shall not be treated as authoritative merely because it cites sources. The system shall preserve source limitations, access restrictions, public-safe controls, and correction pathways. Retrieval access shall not create data rights or authority to expose controlled sources. ### 6.2.6 Agentic workflows. Agentic workflows include AI systems that can plan, call tools, execute code, query repositories, manipulate files, route tasks, interact with APIs, summarize across systems, generate artefacts, or perform multi-step workflows. Agentic workflows shall be governed through agent identity, tool permissions, data access controls, no-command rules, no-write-back rules where applicable, human review, output review, logging, kill-switch conditions, incident response, and archive. Agentic workflows shall be disabled, restricted, sandboxed, or routed through Studio or secure-room controls where risk requires. They shall not execute public authority actions, financial transactions, procurement decisions, infrastructure commands, production deployments, credential decisions, consent determinations, or legal commitments by default. ### 6.2.7 Classifiers. Classifiers include models that assign labels, categories, risk classes, data classes, AI-use labels, public-safe statuses, sensitivity classes, workflow classes, document categories, incident categories, or other classifications. Classifiers may assist review but shall not replace human judgment where classification affects rights, access, safety, public authority boundaries, finance, insurance, procurement, employment, credentialing, consent, deployment, or execution. Classifier outputs shall include confidence or uncertainty where appropriate, review status, limitations, and correction pathway. Classifier errors shall be tracked and corrected. ### 6.2.8 Forecasting models. Forecasting models include models that estimate future conditions, trends, demand, hazards, risk patterns, climate-related impacts, disaster-related indicators, labor-market signals, infrastructure load, system stress, or other future states. Forecasting models shall include assumptions, input data, uncertainty, scenario conditions, model limitations, validation records, update cadence, and public-safe communication controls. A forecast shall not be treated as certainty, warning, public authority decision, emergency command, investment signal, insurance signal, procurement signal, or deployment authorization. Forecasts shall be framed as bounded analytical outputs. ### 6.2.9 Simulation models. Simulation models include computational representations of systems, scenarios, hazards, infrastructure, WFEH-B interactions, cyber-physical systems, logistics, digital twins, climate stressors, policy scenarios, emergency scenarios, or operational environments. Simulation models shall include assumptions, parameters, data inputs, limitations, validation records, sensitivity analysis, uncertainty notes, scenario scope, and public-safe interpretation. Simulation outputs shall not certify real-world performance, authorize deployment, command operations, approve public authority action, create forecast certainty, or replace field validation. Simulation evidence may support learning, review, Studio workflows, Reports, Grid inputs, TRL notes, and handoff context within scope. ### 6.2.10 Digital twin models. Digital twin models include dynamic representations of physical, ecological, infrastructure, social, cyber-physical, industrial, urban, regional, national, WFEH-B, or disaster-risk systems. Digital twin models shall govern input data, update cadence, model assumptions, spatial sensitivity, infrastructure sensitivity, cyber risk, public authority boundaries, operational boundaries, and controlled demonstration status. A digital twin shall not be treated as operational command, official map, public authority decision system, surveillance authority, deployment authorization, procurement basis, or public warning by default. Digital twin outputs shall be public-safe, sensitivity-reviewed, and correctionable. ### 6.2.11 Risk models. Risk models include models used to structure, estimate, compare, interpret, or communicate risk, vulnerability, exposure, resilience capacity, cascading risk, systemic risk, frontier technology risk, cyber risk, climate risk, disaster risk, health-adjacent risk, infrastructure risk, or WFEH-B risk. Risk models shall be linked to GRIx categories, DRI records, Observatory signals, source limitations, uncertainty notes, public-safe controls, and correction pathways. Risk model outputs shall not be ratings, public warnings, insurance scores, investment signals, regulatory determinations, procurement classifications, public authority decisions, or country rankings unless separately and lawfully established by competent authority outside DDPGF default posture. ### 6.2.12 Optimization models. Optimization models include models that identify, rank, allocate, schedule, route, prioritize, or recommend options under constraints. They may support resource planning, scenario analysis, logistics, portfolio prioritization, energy systems, infrastructure planning, resilience planning, or workflow improvement. Optimization models shall record objective functions, constraints, assumptions, data inputs, fairness considerations, sensitivity, limitations, and human review. Optimization outputs shall be decision-support only by default. They shall not allocate public resources, approve procurement, determine financing, assign insurance, rank people, decide employment, override public authorities, authorize deployment, or execute operations without separate lawful authority. ### 6.2.13 Decision-support models. Decision-support models include models intended to assist human judgment by organizing information, generating options, summarizing evidence, identifying risks, mapping dependencies, or supporting review. Such models shall be clearly labeled as decision-support and shall include human review, limitations, access controls, output review, and boundary notices. Decision-support shall not become automated decision-making by implication. Human reviewers and lawful authorities remain responsible for any downstream decisions within their own mandates. ### 6.2.14 Benchmark models. Benchmark models include baseline models, reference models, test models, comparison models, challenge models, evaluation models, or standard task models used to evaluate other models, pipelines, datasets, or workflows. Benchmark models shall include purpose, scope, evaluation protocol, limitations, source data, expected use, prohibited use, reproducibility status, and correction pathway. Benchmark models shall not establish universal performance standards, certification thresholds, procurement eligibility, financeability, insurability, or deployment approval unless separately adopted by competent authority. ### 6.2.15 Evaluation harnesses. Evaluation harnesses include scripts, datasets, prompts, metrics, test suites, red-team procedures, stress tests, simulation workflows, scoring tools, reproducibility packages, and review environments used to evaluate models or AI systems. Evaluation harnesses shall be versioned, documented, reproducible where appropriate, sensitivity-reviewed, and linked to benchmark cards. An evaluation harness shall not certify a model or system. It provides evidence within recorded test conditions and remains subject to correction, expansion, retirement, or replacement. ## 6.3 AI-Use Labels ### 6.3.1 No-AI use. A **No-AI Use** label shall prohibit use of a data object, knowledge object, protected source, workflow, record, or output in AI processing, including model training, fine-tuning, retrieval, summarization, classification, embedding, automated evaluation, agentic workflow, or AI-assisted transformation. This label shall be used where rights, privacy, protected knowledge, Indigenous protocol-sensitive knowledge where applicable, youth data, health-sensitive data, cyber-sensitive data, infrastructure-sensitive data, community sensitivity, public authority sensitivity, confidentiality, or other constraints require exclusion from AI workflows. No-AI Use shall not prevent ordinary human review, lawful recordkeeping, or controlled non-AI processing where separately permitted. Any proposed exception shall require review and recorded reclassification. ### 6.3.2 Retrieval-only. A **Retrieval-Only** label shall allow AI systems to retrieve or reference approved content within a controlled workflow, without using the content for model training, fine-tuning, unrestricted embedding, uncontrolled export, or autonomous action. Retrieval-only use shall require access controls, source visibility where appropriate, citation discipline, prompt-injection controls, output review, and correction propagation. Retrieval-only status shall not make underlying data open, unrestricted, AI-trainable, or publishable. The AI system may assist in locating or summarizing within scope, but it shall not convert restricted material into public output without public-safe review. ### 6.3.3 Summarization with review. A **Summarization With Review** label shall allow AI-assisted summarization only where a human reviewer evaluates accuracy, omissions, sensitivity, public-safe status, rights constraints, boundary notices, and overclaim risk before release or downstream use. Summarization may be internal, controlled, public-safe, or secure-room-only depending on data class. AI summaries shall not be treated as original source records, official interpretations, public authority determinations, public warnings, legal advice, financial advice, insurance advice, procurement recommendations, or deployment instructions. Summaries shall preserve source limitations and correction pathways. ### 6.3.4 Classification with review. A **Classification With Review** label shall allow AI-assisted categorization, tagging, routing, labeling, or triage only where human review confirms or corrects the classification before it affects access, rights, publication, public-safe status, handoff, Registry status, Marketplace listing, Grid input, TRL note, or other consequential workflow. Classification with review may support data class labeling, AI-use labeling, risk category mapping, GRIx mapping, DRI tagging, incident triage, or evidence routing. AI classification shall not be final authority by default. Misclassification shall be corrected and propagated where necessary. ### 6.3.5 Evaluation-only. An **Evaluation-Only** label shall allow a model, dataset, prompt set, output set, benchmark, or workflow to be used solely for testing, benchmarking, validation within scope, red teaming, bias and harm review, security review, public-safe review, or quality assessment. Evaluation-only use shall not permit production use, operational use, public authority use, finance use, insurance use, procurement use, employment use, credentialing use, deployment, or agentic action. Evaluation-only outputs shall be marked as test evidence and shall not be represented as deployment evidence unless separately reviewed and reclassified. ### 6.3.6 Fine-tuning permitted. A **Fine-Tuning Permitted** label shall allow approved data, outputs, or records to be used for model adaptation within recorded scope, subject to rights, consent, privacy, sensitivity, protected knowledge, community, Indigenous protocol where applicable, cybersecurity, and public-safe review. Fine-tuning permission shall identify permitted model families, use context, retention rules, output constraints, evaluation requirements, and withdrawal pathway. Fine-tuning permission shall not imply unrestricted training permission, public release permission, downstream commercialization permission, deployment authorization, or approval for high-stakes use. ### 6.3.7 Training permitted. A **Training Permitted** label shall allow data to be used for model training within recorded scope. It shall require explicit rights basis, source review, privacy review, sensitivity review, protected knowledge review, community or Indigenous protocol review where applicable, data minimization, documentation, withdrawal or exclusion rules where applicable, model-card documentation, and evaluation obligations. Training permission shall be exceptional for sensitive data and shall never be inferred from access, citation, metadata visibility, repository deposit, Reports publication, Marketplace listing, Registry record, Studio workflow, or Nexus participation. Training permission shall not certify the resulting model or authorize deployment. ### 6.3.8 Agentic use prohibited. An **Agentic Use Prohibited** label shall prohibit use of the data, model, system, or workflow in AI-agent workflows that can call tools, execute code, interact with APIs, access files, route tasks, write outputs into systems, or take action-like steps beyond controlled retrieval or review. This label shall be used where autonomy could create rights violations, data leakage, cyber risk, infrastructure risk, public authority boundary risk, finance or procurement boundary risk, protected knowledge exposure, or execution overclaim. Agentic prohibition shall not necessarily prohibit non-agentic human-reviewed AI use if separately permitted by another label. Any agentic exception shall require recorded review, sandboxing, tool restrictions, human oversight, logging, and kill-switch controls. ### 6.3.9 Secure-room AI only. A **Secure-Room AI Only** label shall permit AI use only within an approved secure room, data room, clean room, protected knowledge room, public authority learning room, readiness room, or compute-to-data environment. It shall require controlled access, no-download rules where applicable, output review, logging, role-based permissions, tool restrictions, prompt-injection controls, and public-safe review before any output leaves the room. Secure-room AI use shall not create permission to export raw data, publish outputs, train external models, share prompts, download embeddings, or hand off data. Room outputs remain governed by output classification. ### 6.3.10 Public-safe AI output only. A **Public-Safe AI Output Only** label shall allow AI-assisted output only where the output has been reviewed, transformed, redacted, aggregated, generalized, contextualized, and approved for public-safe or controlled-public release. This label shall be used to prevent disclosure of restricted data, protected knowledge, sensitive locations, cybersecurity-sensitive information, infrastructure-sensitive information, personal data, youth data, health-sensitive information, public authority-sensitive information, or community-sensitive information. Public-safe AI output shall include limitations, uncertainty where applicable, source scope, review status, and correction pathway. It shall not be treated as public warning, public authority decision, official advice, finance advice, insurance advice, procurement recommendation, certification, or deployment authorization. ## 6.4 Model Governance Controls ### 6.4.1 Model purpose. Every Model Object, AI System Object, AI-Agent Object, and AI workflow shall have a recorded purpose. The purpose shall explain why the model exists, what public-good need it addresses, what Nexus pathway it supports, what users it serves, what outputs it may generate, what data it may use, what decisions it shall not make, and how it relates to Reports, Studio, DRI, GRIx, Observatory, Foundry, Marketplace, Registry, Grid, TRL, National Portfolios, Nexus Universe, or lawful handoff. A recorded purpose shall not expand authority. It shall constrain use, guide review, and support correction. ### 6.4.2 Intended use. Intended use shall define the permitted uses, user classes, access conditions, operating environments, input conditions, output expectations, review requirements, and downstream routing for the model or AI system. Intended use shall distinguish between learning, research, internal review, public-safe reporting, controlled Studio demonstration, secure-room analysis, DRI support, Observatory support, Foundry build support, Registry documentation, Marketplace discovery, Grid or TRL evidence, and handoff context. Use outside intended scope shall require review and reclassification. Intended use shall not imply safety certification, public authority approval, financeability, insurability, procurement readiness, deployment authorization, or execution authority. ### 6.4.3 Prohibited use. Every governed model or AI system shall record prohibited uses. Prohibited uses may include automated high-stakes decisions, public authority determinations, public warnings, emergency command, medical diagnosis, legal determination, financial advice, investment recommendation, insurance underwriting, procurement evaluation, employment screening, credentialing decisions, surveillance, profiling, sensitive location exposure, protected knowledge extraction, uncontrolled AI training, agentic execution, infrastructure control, or any use inconsistent with rights, safeguards, access class, data-use labels, AI-use labels, or public-safe controls. Prohibited-use records shall be visible to reviewers, users, stewards, and handoff recipients where appropriate. Violation of prohibited-use rules shall trigger correction, restriction, withdrawal, incident response, or archive. ### 6.4.4 Data provenance. Data provenance records shall identify the data sources, source classes, collection methods, rights basis, licenses, consent or permission status, data-use labels, AI-use labels, sensitivity classes, lineage, transformations, exclusions, synthetic generation methods where applicable, and limitations of data used to train, fine-tune, evaluate, retrieve, prompt, benchmark, or operate a model or AI system. Models without sufficient data provenance shall be restricted, labeled, or excluded from public-safe release, Marketplace listing, Registry active status, Grid input, TRL note, or handoff package where provenance is material. Provenance gaps shall not be hidden and shall remain correctionable. ### 6.4.5 Training data constraints. Training data constraints shall specify what data may and may not be used for model training, fine-tuning, evaluation, retrieval, embedding, or benchmarking. Constraints shall address rights, privacy, protected knowledge, Indigenous protocol-sensitive data where applicable, community-sensitive data, youth data, health-sensitive data, cyber-sensitive data, infrastructure-sensitive data, geospatial-sensitive data, public authority-sensitive data, confidential data, and data sovereignty. Training constraints shall be enforceable through repository rules, access controls, AI-use labels, secure-room controls, documentation, review gates, and incident response. Use of restricted data in training without authorization shall be treated as a serious governance incident. ### 6.4.6 Evaluation records. Evaluation records shall document tests, benchmarks, human reviews, red-team exercises, bias and harm assessments, robustness checks, security checks, prompt-injection tests, tool-use tests, privacy checks, drift monitoring, usability tests, public-safe output review, and failure analysis. Evaluation records shall include method, scope, data, date, reviewer, limitations, results, and correction actions. Evaluation shall be proportionate to risk and intended use. Evaluation records shall not create general validation, safety certification, procurement eligibility, financeability, insurability, deployment authorization, or public authority approval. ### 6.4.7 Bias and harm review. Bias and harm review shall assess whether a model, AI system, agentic workflow, benchmark, dataset, feature set, or output may create or amplify unfairness, discrimination, exclusion, stereotyping, community harm, Indigenous protocol harm where applicable, disability harm, youth harm, gender harm, racial or ethnic harm, language harm, geographic harm, public authority boundary harm, misinformation risk, overclaim risk, or public-safe communication risk. Bias and harm review shall include mitigation notes, limitations, human review requirements, prohibited uses, correction pathway, and withdrawal conditions where necessary. Bias review shall not be a one-time formality and shall be revisited when data, model, context, users, or downstream use changes. ### 6.4.8 Human review. Human review shall be the default control for AI outputs that may affect public-safe reporting, Registry records, Marketplace listings, Reports, Studio outputs, DRI summaries, Observatory outputs, Grid inputs, TRL notes, National Portfolio records, learning records, handoff packages, or other material Nexus outputs. Human review shall verify accuracy, context, rights, sensitivity, limitations, boundary notices, public-safe status, and correction needs. Human review shall be competent, recorded, and proportionate to risk. It shall not create public authority approval, professional certification, finance advice, insurance approval, procurement recommendation, deployment authorization, or execution authority by implication. ### 6.4.9 Prompt-injection controls. Prompt-injection controls shall protect AI systems from malicious, misleading, hidden, conflicting, unauthorized, or manipulative instructions embedded in prompts, documents, webpages, code, metadata, data sources, retrieval corpora, or user inputs. Controls may include source filtering, instruction hierarchy, tool permission limits, retrieval isolation, content sanitization, output review, secure-room workflows, logging, and incident escalation. Prompt-injection risk shall be treated as a system risk, not merely a user error. Systems exposed to external content, code, documents, or web-like sources shall require heightened controls. ### 6.4.10 Tool-permission controls. Tool-permission controls shall define what an AI system or AI-agent object may access, read, write, modify, call, execute, query, generate, delete, route, publish, or transmit. Tool permissions shall be least-privilege, purpose-bound, reviewable, revocable, and logged where appropriate. Tools involving file systems, repositories, APIs, code execution, data rooms, secure rooms, infrastructure, dashboards, registries, marketplaces, communications, or handoff packages shall require heightened review. No AI system shall receive tool permissions that allow hidden execution, unauthorized publication, uncontrolled data export, infrastructure command, public authority action, financial transaction, procurement action, credential issuance, employment decision, consent determination, or legal commitment by default. ### 6.4.11 Logging. Logging shall record material AI activity, including model version, system version, user role, input class, data sources, retrieval records where appropriate, tool calls, output class, review status, errors, escalations, incidents, corrections, and archive actions. Logging shall be designed to support accountability, debugging, security, privacy, correction, and auditability without excessive surveillance or unnecessary collection. Logs shall themselves be governed data objects. They may contain sensitive information and shall be subject to retention, access controls, deletion, sealing, and archive rules. ### 6.4.12 Incident response. AI incident response shall address hallucination incidents, data leakage, prompt injection, unauthorized tool use, prohibited output, bias or harm, privacy breach, protected knowledge exposure, public-safe publication failure, public authority boundary incident, finance boundary incident, procurement boundary incident, agentic overreach, cybersecurity incident, model drift, benchmark failure, system misuse, handoff overclaim, or execution overclaim. Incident response may include containment, access suspension, model suspension, agent shutdown, tool revocation, data freeze, claims freeze, technical freeze, Registry status update, Marketplace delisting, Reports correction, Studio shutdown, Grid or TRL update, handoff recall, public-safe notice, model withdrawal, archive, and non-continuation. ### 6.4.13 Model withdrawal. Model withdrawal shall occur where a model or AI system is unsafe, misleading, rights-defective, privacy-defective, security-defective, biased beyond acceptable limits, unsupported, obsolete, overclaimed, misused, misclassified, improperly trained, improperly released, or otherwise no longer suitable for active status. Withdrawal may be temporary or permanent and shall be recorded in the Registry, Marketplace, Reports, Studio, Grid, TRL, National Portfolio, Nexus Universe, and handoff contexts where relevant. Withdrawal shall include downstream correction and recall where feasible. Withdrawal shall not erase accountability; it shall preserve institutional memory and correction history. ### 6.4.14 Archive. Archive shall preserve model records, system records, agent records, model cards, system cards, benchmark cards, evaluation records, data-provenance records, AI-use labels, data-use labels, access logs where appropriate, incident records, correction records, withdrawal records, release notes, version history, support status, and handoff records. Archived AI objects shall be marked as non-current unless reactivated through review. Archived AI objects shall not be used for active workflows, public-safe outputs, operational decisions, deployment, finance, insurance, procurement, public authority action, or handoff unless separately reviewed and reclassified. ## 6.5 Agentic Workflow Controls ### 6.5.1 Agent identity. Every AI-Agent Object shall have a recorded identity, including name, version, steward, purpose, model dependencies, tool permissions, access class, operating environment, user class, supervision model, logging status, output class, support class, correction pathway, and archive rule. Agent identity shall make clear whether the agent is experimental, internal, Studio-only, secure-room-only, public-safe-output-only, Marketplace-listed, Registry-recorded, handoff-context-only, or withdrawn. An agent shall not operate anonymously, invisibly, or outside recorded scope. Agent identity shall not create legal personality, employment status, agency authority, public authority authority, or execution authority. ### 6.5.2 Tool permissions. Agent tool permissions shall be explicitly recorded and limited to the minimum necessary for the approved purpose. Tools may include retrieval, summarization, file reading, code generation, code execution in sandboxed environments, data transformation, dashboard generation, report drafting, workflow routing, API querying, or registry preparation, but each permission shall be classified and controlled. Write permissions, deletion permissions, publication permissions, infrastructure permissions, external communication permissions, transaction permissions, and handoff-package permissions shall be prohibited by default unless separately reviewed and controlled. Any tool permission capable of material downstream effect shall require human review and logging. ### 6.5.3 Human-in-the-loop requirements. Human-in-the-loop requirements shall require human approval before specified AI actions occur. They shall apply where an agent could affect public-safe release, data classification, rights interpretation, access control, Registry status, Marketplace listing, Reports publication, Studio output, Grid input, TRL note, National Portfolio record, Nexus Universe output, handoff package, correction notice, withdrawal, or any material boundary-sensitive workflow. Human approval shall be recorded. Silence, inactivity, interface design, or prior participation shall not constitute approval. ### 6.5.4 Human-on-the-loop requirements. Human-on-the-loop requirements shall require ongoing human supervision, monitoring, review sampling, escalation review, drift review, incident review, and periodic recertification of agent scope where an AI-Agent Object operates within a bounded workflow. Human-on-the-loop control may be appropriate where actions are low-risk, reversible, logged, and constrained, but shall not be used for high-stakes, public authority, finance, insurance, procurement, employment, consent, deployment, or execution workflows by default. Human-on-the-loop controls shall include stop, pause, restrict, and escalate capabilities. ### 6.5.5 No-command rules. No-command rules shall prohibit AI-Agent Objects from issuing commands to infrastructure, operational systems, emergency systems, public authority systems, financial systems, procurement systems, production environments, physical devices, robots, drones, OT systems, IIoT systems, telecom networks, energy systems, water systems, health systems, or other systems where agent action could cause real-world consequences. Command-like outputs may be used only as draft recommendations, simulations, or learning objects within controlled workflows and with clear boundary notices. No-command rules preserve the distinction between demonstration, decision support, and lawful execution. ### 6.5.6 No-write-back rules. No-write-back rules shall prohibit AI-Agent Objects from writing, modifying, overwriting, deleting, approving, publishing, or committing changes to authoritative systems of record, public authority systems, Registry status fields, Marketplace listings, Reports publications, data commons, secure rooms, handoff packages, repositories, infrastructure, or operational workflows unless the write-back action is explicitly permitted, sandboxed, reviewed, logged, and reversible. Draft creation may be permitted where it is clearly marked as draft and subject to human review. No-write-back rules shall prevent hidden execution, silent alteration of records, unauthorized correction, data corruption, public-safe failures, and boundary overclaims. ### 6.5.7 Output review. Agentic outputs shall be reviewed according to output class. Review shall assess factual accuracy, source use, rights compliance, sensitivity, protected knowledge, privacy, cyber risk, infrastructure risk, public authority boundary, finance boundary, procurement boundary, consent boundary, public-safe status, bias and harm, and correction needs. Outputs intended for public, controlled-public, Registry, Marketplace, Reports, Studio, Grid, TRL, National Portfolio, Nexus Universe, or handoff use shall not bypass review. Output review shall distinguish between internal drafts, controlled outputs, public-safe summaries, technical artefacts, and handoff-context artefacts. ### 6.5.8 Escalation triggers. Escalation triggers shall identify when an AI-Agent Object must pause, alert a human reviewer, restrict access, stop tool use, route to secure room, route to legal or safeguard review, route to public authority boundary review, route to finance or procurement boundary review, or initiate incident response. Triggers may include sensitive data detection, protected knowledge detection, public authority content, finance or insurance content, procurement content, health-sensitive content, youth data, cyber-sensitive content, infrastructure-sensitive content, geospatial-sensitive content, community-sensitive content, Indigenous protocol-sensitive content where applicable, high uncertainty, hallucination risk, prompt injection, unauthorized tool request, or prohibited-use indicators. Escalation shall be recorded and correctionable. ### 6.5.9 Kill-switch conditions. Kill-switch conditions shall define when an AI-Agent Object must be immediately disabled, paused, disconnected from tools, isolated, or withdrawn. Conditions may include unauthorized data access, tool misuse, prompt-injection compromise, repeated hallucination, public-safe failure, protected knowledge exposure, privacy breach, cyber risk, infrastructure risk, public authority overclaim, finance or procurement overclaim, consent overclaim, unauthorized write-back, attempted command action, unapproved external communication, or material incident. Kill-switch activation shall trigger incident response, logging preservation, Registry status update where applicable, Marketplace delisting where applicable, downstream notification where required, correction, and archive or reinstatement review. ### 6.5.10 Agentic incident records. Agentic incident records shall document agent identity, system version, user role, trigger, input class, data sources, tool calls, output, incident class, containment actions, affected objects, downstream risk, correction actions, public-safe notice where appropriate, Registry update, Marketplace update, Reports correction, Studio shutdown, Grid or TRL update, handoff recall, withdrawal, reinstatement, archive, and lessons learned. Agentic incident records shall preserve accountability and institutional memory. They shall not be hidden merely because the incident was technical, experimental, internal, or caused by a third-party model. ## 6.6 Model Boundary Rules ### 6.6.1 Model card is not AI safety certification. A Model Card is a documentation and governance record. It shall not be represented as AI safety certification, legal compliance certification, fairness certification, security certification, procurement approval, financeability, insurability, public authority approval, deployment authorization, or execution authority. Any safety claim shall remain bounded by recorded evidence, evaluation scope, intended use, prohibited use, limitations, and review status. ### 6.6.2 Benchmark result is not general validation. A benchmark result shall apply only to the benchmark scope, test conditions, dataset, metrics, model version, system configuration, and evaluation method recorded in the Benchmark Card. It shall not create general validation, model superiority, production readiness, operational suitability, public authority approval, procurement readiness, financeability, insurance approval, safety certification, or deployment authorization. Benchmark results may become misleading over time and shall remain subject to correction, withdrawal, or archive. ### 6.6.3 Agent output is not determination. An AI-agent output shall not constitute a determination, decision, approval, rejection, ranking, legal conclusion, public authority action, finance decision, insurance decision, procurement decision, credential decision, employment decision, consent determination, warning, operational instruction, or deployment authorization by default. Agent outputs shall be treated as draft, support, analysis, simulation, summary, or workflow assistance unless separately reviewed and adopted by a competent lawful actor within that actor’s own authority. ### 6.6.4 AI workflow is not public authority decision. No AI workflow under DDPGF shall be treated as a public authority decision, public warning, regulatory action, permit action, license action, public finance allocation, inspection result, official statistic, official map, emergency command, or government approval unless separately and lawfully adopted by a competent public authority outside the DDPGF default posture. Public authority participation, learning-room use, Studio review, data sharing, Reports citation, Registry record, Marketplace listing, Nexus Universe attendance, or handoff receipt shall not convert an AI workflow into public authority action. ### 6.6.5 Model release is not deployment authorization. Release of a model, AI system, agentic workflow, model card, system card, benchmark card, evaluation record, repository, API, Studio workflow, Marketplace listing, Registry record, Report, Grid input, TRL note, Nexus Universe output, or handoff package shall not authorize deployment. Deployment requires separate lawful review by competent actors, including technical, legal, security, privacy, public authority, safeguard, operational, procurement, finance, insurance, community, Indigenous protocol where applicable, and execution approvals where relevant. ### 6.6.6 Evaluation is not financeability, insurability, or procurement readiness. Evaluation records, benchmark results, red-team results, model cards, system cards, Grid inputs, TRL notes, Reports, Registry records, Marketplace listings, Studio demonstrations, or handoff notes shall not be represented as financeability, insurability, underwriting readiness, investment readiness, donor commitment, public finance allocation, procurement readiness, supplier approval, vendor validation, or tender support by default. Evaluation may inform lawful diligence, but it shall not replace independent diligence, regulated advice, procurement process, insurance underwriting, investment decision-making, public finance review, or recipient responsibility. --- # 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/distributed-digital-public-goods-framework-ddpgf/vi.-models.md?ask= ``` 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.