# XXIII. CONTROLS

Nexus Agile Framework Controls defines the **NAF governance and control system** for safeguards, security, privacy, AI controls, cyber controls, public-safe review, incident response, stop-the-line action, correction, and archive integrity. This section explains how **control families, safeguard architecture, incident classes, governance doctrine, and operating metrics** protect public-good work without creating certification, public authority action, procurement status, financeability, consent, deployment authority, or execution.

This section sets the operating model for **governance by record**, **review and role separation**, **security and privacy controls**, **incident management**, and **correctionable archive-based trust**. It helps Nexus preserve evidence traceability, public-safe accountability, safeguard protection, access discipline, and non-executing governance across the full NAF operating system.

### What this section covers

* Governance doctrine, control families, and safeguards across records, review, and release.
* Security, privacy, AI, cyber, and incident controls for trusted public-good operations.
* Stop-the-line, correction, recall, and archive rules that preserve operating trust.

Use this section with the [NAF overview](/organization/operations/frameworks/nexus-agile-framework-naf.md), [XV. GRID](/organization/operations/frameworks/nexus-agile-framework-naf/xv.-grid.md), [XVI. REGISTRY](/organization/operations/frameworks/nexus-agile-framework-naf/xvi.-registry.md), [XVII. REPORTS](/organization/operations/frameworks/nexus-agile-framework-naf/xvii.-reports.md), [XXI. AGENCY](/organization/operations/frameworks/nexus-agile-framework-naf/xxi.-agency.md), and [XXII. HANDOFF](/organization/operations/frameworks/nexus-agile-framework-naf/xxii.-handoff.md) to connect governance controls with reporting, status records, advisory work, readiness evidence, and lawful downstream routing.

## 23.1 NAF Governance Doctrine

### 23.1.1 Governance by Record.

23.1.1.1 NAF shall be governed by record. No material signal, intake, triage, classification, Docket item, backlog item, quest, bounty, build, study, Campaign object, learning object, Report, Studio workflow, Grid input, TRL note, Marketplace listing, Registry record, Nexus Universe output, National Portfolio object, Risk Agency engagement, Handoff Package, correction action, recall action, withdrawal action, archive action, or non-continuation action shall be treated as valid within NAF unless its existence, scope, source, purpose, status, review state, boundary notices, correction pathway, and archive rule are recorded.

23.1.1.2 Governance by Record shall implement the NAF rule that institutional meaning arises from recorded status, not from informal participation, verbal statements, meeting attendance, sponsor support, provider contribution, public visibility, public authority presence, technical demonstration, capital-reader interest, media attention, community participation, or downstream interpretation.

23.1.1.3 Records shall be sufficient to answer, at minimum: what the object is, who created or stewarded it, why it exists, what sources support it, what it may and may not be used for, what has been reviewed, what remains unresolved, what boundaries apply, what correction pathway applies, what archive rule applies, and what claims are prohibited.

23.1.1.4 Governance by Record shall not create bureaucracy for its own sake. It shall create operational trust, evidence traceability, public-safe accountability, role separation, correctionability, auditability, lawful handoff discipline, and institutional memory.

### 23.1.2 Governance by Review.

23.1.2.1 NAF shall be governed by review. Review shall apply before release, publication, listing, registration, Studio demonstration, Grid routing, TRL notation, Nexus Universe presentation, public-safe distribution, handoff packaging, or archive closure where the object presents material evidence, data, AI, cyber, privacy, public-safe, safeguard, public authority, finance, insurance, procurement, provider, sponsor, consent, deployment, or execution risk.

23.1.2.2 Review shall be proportionate to risk, scope, sensitivity, intended use, release class, audience, downstream relevance, and correction exposure. Low-risk learning or internal work may require light review; public-facing, sensitive, handoff-relevant, public authority-facing, finance-facing, insurance-facing, procurement-adjacent, community-sensitive, Indigenous protocol-sensitive where applicable, protected knowledge, cyber-sensitive, AI-enabled, or data-intensive work shall require heightened review.

23.1.2.3 Review may include evidence review, method review, data review, AI-use review, cyber review, privacy review, public-safe review, safeguard review, protected knowledge review, accessibility review, localization review, legal-boundary review, public authority boundary review, finance boundary review, insurance boundary review, procurement boundary review, provider-neutrality review, sponsor-boundary review, handoff review, archive review, and correction review.

23.1.2.4 Review shall not be represented as approval beyond its recorded scope. No review conducted under NAF shall create certification, public authority approval, professional approval, procurement status, financeability, insurability, provider validation, sponsor endorsement, community consent, Indigenous consent where applicable, deployment authorization, operational command, or execution authority.

### 23.1.3 Governance by Role Separation.

23.1.3.1 NAF shall be governed by role separation. Convening, evidence stewardship, learning, research, production, public-safe reporting, Registry status, Marketplace discovery, Studio operation, Grid readiness input, TRL notation, Risk Agency advisory support, Campaign mobilization, Nexus Universe presentation, National Portfolio formation, finance-readiness literacy, insurance-readiness literacy, public authority learning, lawful handoff, downstream procurement, downstream finance, downstream insurance, downstream public authority action, downstream consent, downstream deployment, and downstream execution shall remain distinct unless separately and lawfully recorded.

23.1.3.2 Role separation shall preserve the distinct institutional functions of The Global Centre for Risk and Innovation, The Global Risks Forum, The Global Risks Alliance, Nexus Consortiums, National Nodes, National Working Groups, Nexus Competence Cells, Nexus Academy, Risk Academy, Risk Agency, Nexus Labs, Nexus Foundry, Nexus Campaigns, Nexus Reports, Nexus Marketplace, Nexus Registry, Nexus Studio, Nexus Grid, Nexus Observatory, Nexus Universe, Nexus Rails, Nexus Network, National Consortium Companies, Project SPVs, public authorities, providers, sponsors, funders, insurers, donors, operators, contractors, communities, universities, and other lawful actors.

23.1.3.3 Role separation shall prevent hidden agency, shared liability by implication, collapsed authority, provider capture, sponsor control, procurement distortion, finance distortion, insurance overclaim, public authority substitution, consent overclaim, standards-authority overclaim, maturity-certification overclaim, deployment overclaim, or execution by implication.

23.1.3.4 Any role-collapse risk shall be treated as a governance concern and may trigger review, escalation, correction, claims freeze, status change, delisting, withdrawal, handoff recall, archive, or non-continuation.

### 23.1.4 Governance by Public-Safe Controls.

23.1.4.1 NAF shall be governed by public-safe controls. Public-safe controls shall ensure that outputs released beyond controlled rooms do not create public warnings, official approvals, finance claims, procurement claims, certification claims, consent claims, deployment claims, operational instructions, sensitive disclosures, protected knowledge disclosures, unsafe geospatial disclosures, cyber-sensitive disclosures, biosecurity-sensitive disclosures, privacy harms, reputational harms, community harms, or public authority confusion.

23.1.4.2 Public-safe controls shall apply to Reports, Campaigns, Marketplace listings, Registry display, public dashboards, Studio summaries, DRI summaries, Observatory outputs, Grid and TRL notes, public authority learning materials, media-safe materials, Nexus Universe outputs, National Portfolio public summaries, Risk Agency public-facing outputs, Handoff Package summaries, and correction notices.

23.1.4.3 Public-safe controls shall include audience classification, release class selection, language review, no-warning language, no-approval language, no-finance language, no-procurement language, no-certification language, no-consent language, no-deployment language, no-execution language, sensitivity masking, aggregation, delay, anonymization where appropriate, protected knowledge review, accessibility review, translation review, and correction notices.

23.1.4.4 Public-safe release shall not convert public-safe material into public authority notice, public warning, official report, investment communication, insurance communication, procurement communication, consent record, deployment instruction, or execution command.

### 23.1.5 Governance by Safeguards.

23.1.5.1 NAF shall be governed by safeguards. Safeguards shall protect communities, Indigenous institutions where applicable, youth, vulnerable groups, people with disabilities, public-interest participants, humanitarian contexts, protected knowledge, sensitive data, cultural context, language access, accessibility, privacy, dignity, safety, and non-extractive participation.

23.1.5.2 Safeguards shall apply across intake, Dockets, Campaigns, learning objects, WILPs, micro-credentials, Labs, Foundry builds, DICE, GRIx, DRI, Observatory outputs, Studio workflows, Reports, Marketplace listings, Registry records, Grid inputs, TRL notes, Nexus Universe rooms, National Portfolio records, Risk Agency engagements, Handoff Packages, correction, recall, and archive.

23.1.5.3 Safeguard review shall identify safeguard status and safeguard dependencies; it shall not replace consent, consultation, accommodation, rights processes, community governance, Indigenous protocols where applicable, legal review, public authority review, or downstream implementation obligations.

23.1.5.4 Safeguard concerns shall have stop-the-line priority where continued processing, publication, demonstration, listing, registration, handoff, or public communication may cause harm, overclaim consent, disclose protected knowledge, expose sensitive data, misrepresent community participation, or bypass appropriate processes.

### 23.1.6 Governance by Correction.

23.1.6.1 NAF shall be governed by correction. Every record, object, output, statement, listing, status, Report, Studio workflow, Grid input, TRL note, National Portfolio record, Nexus Universe output, Risk Agency output, Handoff Package, public-safe communication, and archive record shall remain subject to correction, addendum, supersession, withdrawal, retraction where necessary, recall, public repair, archive, and non-continuation.

23.1.6.2 Correction shall be treated as evidence of institutional trust, not institutional weakness. NAF shall prefer correction over silent error, public repair over concealed overclaim, archive over uncontrolled drift, and recall over unsafe reliance.

23.1.6.3 Correction shall propagate to affected records, repositories, Reports, Marketplace listings, Registry records, Studio workflows, Grid inputs, TRL notes, DRI outputs, GRIx mappings, Observatory outputs, Campaigns, Academy objects, Foundry outputs, Nexus Universe records, National Portfolio records, Risk Agency outputs, Handoff Packages, recipients, and archives where appropriate.

23.1.6.4 Correction shall preserve the distinction between correcting the record and assuming downstream execution responsibility. NAF may correct, recall, withdraw, supersede, or archive its own outputs; downstream actors remain responsible for downstream reliance, claims, decisions, deployments, operations, and execution.

### 23.1.7 Governance Without Command by Implication.

23.1.7.1 NAF governance shall not be command by implication. Governance shall organize records, review, roles, public-safe controls, safeguards, correction, archive, and handoff, but shall not command public authorities, enterprises, funders, insurers, donors, operators, contractors, providers, sponsors, communities, universities, or lawful recipients.

23.1.7.2 Governance instruments, Dockets, dashboards, Reports, Registry statuses, Marketplace listings, Studio workflows, Grid inputs, TRL notes, Campaign records, National Portfolio records, Risk Agency notes, Nexus Universe outputs, and Handoff Packages shall not be treated as orders, instructions, operational commands, emergency commands, procurement mandates, finance mandates, public authority directives, consent determinations, deployment authorizations, or execution instructions.

23.1.7.3 Where command, direction, operational control, public authority action, emergency response, procurement decision, finance decision, insurance decision, consent decision, deployment decision, or execution decision is required, such action must occur outside NAF through competent lawful actors and recorded authority.

23.1.7.4 NAF’s governance power shall be the power to preserve trustworthy movement, not the power to command downstream action.

### 23.1.8 Governance as Operating Trust.

23.1.8.1 NAF governance shall operate as trust infrastructure for public-good delivery. It shall allow multiple institutions, disciplines, sectors, countries, communities, technologies, experts, sponsors, providers, public authorities, capital readers, insurers, donors, universities, and lawful recipients to work within one recorded operating environment without collapsing authority or creating unsafe reliance.

23.1.8.2 Operating trust shall be produced through record discipline, review discipline, role separation, public-safe controls, safeguards, security, privacy, AI controls, cyber controls, provider-neutrality, sponsor-boundary controls, public authority boundary controls, finance boundary controls, procurement neutrality, consent boundary controls, handoff controls, correction, archive, and non-continuation.

23.1.8.3 Operating trust shall not mean trust without evidence. It shall mean trust because evidence, boundaries, assumptions, limitations, dependencies, status, support, correction, and archive are visible within the relevant access class.

23.1.8.4 The governance doctrine of NAF shall be that public-good systems can move quickly only when they remain recorded, reviewable, role-separated, safeguard-aware, public-safe, secure, privacy-preserving, AI-controlled, correctionable, archive-capable, and non-executing by default.

## 23.2 Control Families

### 23.2.1 Evidence Controls.

23.2.1.1 Evidence Controls shall govern the creation, intake, classification, review, use, release, routing, correction, withdrawal, recall, and archive of evidence within NAF.

23.2.1.2 Evidence Controls shall require evidence source records, method notes, scope limits, assumptions, limitations, confidence labels where applicable, uncertainty labels where applicable, review status, reproducibility status, public-safe status, safeguard status, support status, dependency status, and correction pathway.

23.2.1.3 Evidence Controls shall apply to research records, evidence packs, testbed records, datasets, model cards, system cards, benchmark cards, agent workflow cards, software records, dashboard records, DRI records, GRIx records, Observatory records, Studio records, Grid inputs, TRL notes, Reports, Marketplace listings, Registry records, National Portfolio records, Nexus Universe outputs, Risk Agency outputs, and Handoff Packages.

23.2.1.4 Evidence Controls shall prevent evidence overclaim, cherry-picking, unsupported conclusions, scope drift, unreviewed reuse, public-safe failure, readiness inflation, certification overclaim, public authority overclaim, finance overclaim, procurement overclaim, deployment overclaim, or execution overclaim.

### 23.2.2 Data Controls.

23.2.2.1 Data Controls shall govern data signal intake, data classification, metadata creation, lineage capture, rights review, sensitivity review, access control, data-use labeling, AI-use labeling, public-safe transformation, secure-room use, compute-to-data workflows, publication, restriction, correction, deletion, sealing, archive, and incident response.

23.2.2.2 Data Controls shall apply to open data, public-safe data, controlled public data, restricted data, public authority-sensitive data, community-sensitive data, Indigenous protocol-sensitive data where applicable, protected knowledge, youth data, health-sensitive data, cyber-sensitive data, infrastructure-sensitive data, geospatial-sensitive data, handoff-recipient-only data, archive-only data, metadata-only records, synthetic data, aggregated data, Studio data, DRI data, Observatory data, and National Portfolio data.

23.2.2.3 Data Controls shall include data minimization, purpose limitation, permission and consent review where applicable, lawful basis review where applicable, access controls, cross-border controls, data sovereignty controls, data localization controls, retention, deletion, sealing, no-download controls, output review, logging, monitoring, and correction.

23.2.2.4 Data Controls shall not create unrestricted data rights. Data availability, metadata publication, data-room access, secure-room access, API access, Studio access, or handoff context shall not imply data ownership, reuse permission, AI training permission, public authority approval, deployment authorization, or execution.

### 23.2.3 AI Controls.

23.2.3.1 AI Controls shall govern AI system intake, AI-use labels, model objects, system objects, benchmark objects, agent workflow objects, data provenance, training data constraints, evaluation records, bias and harm review, human review, prompt-injection controls, tool-permission controls, logging, red-team records, drift detection, AI incident response, model withdrawal, and archive.

23.2.3.2 AI Controls shall require model cards, system cards, benchmark cards, agent workflow cards, intended use, prohibited use, data-use status, AI-use status, human-in-the-loop or human-on-the-loop requirements where applicable, no-command rules, no-write-back rules, output review, escalation triggers, kill-switch conditions, and correction pathways.

23.2.3.3 AI Controls shall apply to retrieval systems, summarization systems, classifiers, forecasting systems, simulation systems, digital twin systems, risk models, optimization models, decision-support models, foundation-model interfaces, fine-tuned models, evaluation harnesses, and agentic workflows.

23.2.3.4 AI Controls shall prevent automated authority. AI output shall not constitute public authority decision, legal determination, finance determination, insurance determination, procurement decision, consent determination, deployment authorization, operational command, or execution instruction.

### 23.2.4 Cyber Controls.

23.2.4.1 Cyber Controls shall govern cybersecurity across repositories, software, data, models, APIs, Studio workflows, DICE, DRI dashboards, Observatory systems, Marketplace, Registry, Reports, Grid, Nexus Universe systems, National Nodes, secure rooms, data rooms, compute environments, cloud, edge, HPC, sovereign compute, AI-RAN, O-RAN, private wireless, IoT, OT, IIoT, sensors, and infrastructure records.

23.2.4.2 Cyber Controls shall include secure repository controls, identity and access management, least privilege, multi-factor authentication where appropriate, secret scanning, dependency scanning, SBOM records, vulnerability disclosure, threat modeling, secure defaults, logging, monitoring, incident response, backup, restore testing, access recertification, and archive.

23.2.4.3 Cyber-sensitive materials shall be classified before publication, sharing, Studio demonstration, Marketplace listing, Registry display, Report publication, Nexus Universe presentation, or handoff.

23.2.4.4 Cyber Controls shall not create cybersecurity certification, operational command, provider validation, public warning, public authority approval, deployment authorization, or execution.

### 23.2.5 Privacy Controls.

23.2.5.1 Privacy Controls shall govern personal data, learner data, worker data, contributor data, community data, youth data, health-sensitive data, profile data, participation records, ILA records, iCRS records, WILP records, micro-credential records, Campaign records, Risk Agency records, Studio access records, secure-room records, data-room records, public authority learning records, and handoff recipient records.

23.2.5.2 Privacy Controls shall include data minimization, purpose limitation, consent and permission records where applicable, access controls, role-based permissions, privacy notices, profile visibility controls, cross-border transfer review, sensitive data restrictions, youth protections, deletion, sealing, retention, archive, breach response, and correction.

23.2.5.3 Privacy Controls shall apply to AI use, analytics, dashboards, metrics, Marketplace display, Registry display, Reports publication, public-safe summaries, Nexus Universe outputs, and handoff packages.

23.2.5.4 Privacy labels and privacy review shall not constitute legal compliance determination by default, public authority approval, data right, consent record beyond its scope, deployment authorization, or execution.

### 23.2.6 Public-Safe Controls.

23.2.6.1 Public-Safe Controls shall govern language, release class, audience, sensitivity, public interpretation, disclaimers, notices, accessibility, localization, protected knowledge, geospatial sensitivity, cyber sensitivity, biosecurity sensitivity, public authority boundaries, finance boundaries, procurement boundaries, consent boundaries, deployment boundaries, execution boundaries, and correction for externally visible outputs.

23.2.6.2 Public-Safe Controls shall require no-warning language, no-approval language, no-finance language, no-procurement language, no-certification language, no-consent language, no-deployment language, no-execution language, and public repair rules where applicable.

23.2.6.3 Public-Safe Controls shall apply before publishing Reports, public dashboards, Marketplace listings, Registry display, Campaign materials, media-safe materials, Academy public materials, Nexus Universe outputs, National Portfolio public summaries, Risk Agency public-facing outputs, and Handoff Package summaries.

23.2.6.4 Public-Safe Controls shall prevent public-facing work from being mistaken as public authority action, public warning, investment signal, insurance score, procurement recommendation, certification, consent, deployment authorization, or execution.

### 23.2.7 Safeguard Controls.

23.2.7.1 Safeguard Controls shall govern community safeguards, Indigenous protocols where applicable, protected knowledge, youth safeguards, disability inclusion, accessibility, humanitarian sensitivity, public-interest participation, non-extractive engagement, rights-sensitive participation, community-facing correction, and consent boundary protection.

23.2.7.2 Safeguard Controls shall require safeguard classification, safeguard review, affected stakeholder consideration, protected knowledge review, community-sensitive data review, Indigenous protocol-sensitive review where applicable, accessibility review, language access review, youth protection review, and correction pathway.

23.2.7.3 Safeguard Controls shall apply to Campaigns, National Portfolios, Nexus Universe rooms, Reports, DRI outputs, Observatory outputs, Studio workflows, DICE objects, Marketplace listings, Registry display, Foundry outputs, Labs outputs, Academy materials, Risk Agency engagements, and Handoff Packages.

23.2.7.4 Safeguard Controls shall not create consent. They shall protect against harm and overclaim while preserving the requirement for separate lawful consent, consultation, accommodation, community governance, Indigenous protocol processes where applicable, and rights-respecting procedures.

### 23.2.8 Public Authority Boundary Controls.

23.2.8.1 Public Authority Boundary Controls shall prevent NAF outputs and activities from being misrepresented as public authority action.

23.2.8.2 These controls shall apply to public authority learning rooms, public authority learning records, public finance learning rooms, policy translation, Reports, DRI outputs, Observatory outputs, Studio scenarios, Grid inputs, TRL notes, Nexus Universe participation, National Portfolio records, Risk Agency notes, Campaigns, Marketplace listings, Registry records, and Handoff Packages.

23.2.8.3 Public Authority Boundary Controls shall require no-decision, no-warning, no-command, no-regulatory-action, no-procurement, no-public-finance-allocation, no-permit, no-license, no-approval, and no-execution notices where applicable.

23.2.8.4 No NAF record, room, Report, dashboard, Studio workflow, Grid input, TRL note, Marketplace listing, Registry status, public authority presence, public authority learning participation, Nexus Universe visibility, or Handoff Package shall constitute public authority decision, official adoption, regulation, permit, license, public warning, public finance allocation, procurement decision, emergency command, deployment authorization, or execution.

### 23.2.9 Finance Boundary Controls.

23.2.9.1 Finance Boundary Controls shall govern capital-readability, finance-readiness questions, donor-readiness questions, public finance relevance questions, capital-reader rooms, donor-reader rooms, public finance learning rooms, assumptions registers, dependency registers, diligence-gap registers, no-reliance statements, non-solicitation, and non-transactionality.

23.2.9.2 Finance Boundary Controls shall prevent investment advice, financial advice, securities advice, valuation, bankability determination, financeability determination, public finance allocation, donor commitment, grant approval, transaction execution, or solicitation by implication.

23.2.9.3 Finance Boundary Controls shall apply to Reports, Campaigns, Marketplace listings, Registry records, Nexus Universe rooms, National Portfolios, Risk Agency outputs, Handoff Packages, and public-safe summaries.

23.2.9.4 Any finance activity must occur separately through competent lawful actors, independent diligence, lawful documentation, regulated processes where applicable, and appropriate authorizations outside NAF.

### 23.2.10 Procurement Boundary Controls.

23.2.10.1 Procurement Boundary Controls shall prevent NAF outputs from being used as procurement recommendations, preferred-provider lists, supplier approvals, vendor validations, tender support, technical compliance certificates, sole-source justifications, procurement specifications by implication, or procurement decisions.

23.2.10.2 Procurement Boundary Controls shall apply to Marketplace listings, Registry records, Reports, Studio demonstrations, Grid inputs, TRL notes, Nexus Universe demonstrations, Campaign materials, Foundry outputs, provider contributions, sponsor support, Risk Agency notes, National Portfolio objects, and Handoff Packages.

23.2.10.3 Procurement Boundary Controls shall require no preferred provider, no procurement recommendation, no supplier approval, no vendor validation, no tender support by implication, independent diligence required, provider contribution controls, and Marketplace listing controls.

23.2.10.4 Procurement decisions must occur outside NAF through competent procurement actors and lawful procurement processes.

### 23.2.11 Provider Controls.

23.2.11.1 Provider Controls shall govern provider participation, provider contribution, provider demonstrations, provider support, provider tools, provider datasets, provider software, provider infrastructure, provider models, provider expert input, provider Marketplace listing, provider Registry status, provider Studio involvement, provider Grid input, provider Nexus Universe participation, and provider handoff involvement.

23.2.11.2 Provider Controls shall require contribution records, conflict records, provider-neutrality notes, support class, license status, public-safe review, procurement-neutrality review, finance-boundary review, no-validation notices, and correction pathways.

23.2.11.3 Provider Controls shall prevent provider capture, pay-to-validate, pay-to-route, pay-to-prioritize, hidden exclusivity, procurement preference, vendor validation, sponsor-style control, public authority confusion, finance overclaim, and deployment overclaim.

23.2.11.4 Provider participation shall not create certification, endorsement, supplier approval, procurement status, financeability, public authority approval, deployment authorization, or execution.

### 23.2.12 Sponsor Controls.

23.2.12.1 Sponsor Controls shall govern sponsor support, host support, in-kind support, venue support, compute support, cloud support, software support, data support where lawful, media support, Campaign support, Nexus Universe support, Academy support, Foundry support, Reports support, Marketplace support, Registry support, Studio support, Grid support, and handoff support.

23.2.12.2 Sponsor Controls shall require support records, sponsor-boundary notes, conflict review, public display rules, acknowledgement rules, no-control notices, no-editorial-control notices, no-routing-control notices, no-procurement-preference notices, no-validation notices, and correction pathways.

23.2.12.3 Sponsor Controls shall prevent sponsor capture, pay-to-influence, pay-to-route, pay-to-validate, editorial capture, evidence capture, public-safe reporting capture, procurement distortion, finance distortion, provider preference, public authority overclaim, and consent overclaim.

23.2.12.4 Sponsor support shall not create governance rights, ownership, approval, endorsement, procurement preference, provider validation, financeability, public authority approval, consent, deployment authorization, or execution.

### 23.2.13 Handoff Controls.

23.2.13.1 Handoff Controls shall govern Handoff Intake, Handoff Classification, Handoff Review, Handoff Recipient Records, Handoff Dependency Registers, Handoff Packages, Handoff Correction, Handoff Recall, Handoff Archive, and recipient obligations.

23.2.13.2 Handoff Controls shall require evidence context, data context, method context, Studio context, Grid and TRL context, public-safe status, safeguard status, public authority dependencies, legal dependencies, finance and insurance questions, procurement boundaries, provider-neutrality notes, sponsor-boundary notes, recipient responsibilities, correction pathways, recall pathways, and archive linkage.

23.2.13.3 Handoff Controls shall prevent context transfer from becoming authority transfer, readiness from becoming finance, evidence from becoming approval, public authority learning from becoming public authority action, Marketplace listing from becoming procurement, Registry status from becoming certification, Studio demonstration from becoming deployment, or handoff from becoming execution.

23.2.13.4 Handoff may be corrected, recalled, withdrawn, superseded, archived, or marked non-continuing where boundaries are breached or reliance becomes unsafe.

### 23.2.14 Archive Controls.

23.2.14.1 Archive Controls shall govern the preservation, restriction, labeling, access, retention, deletion, sealing, historical use, successor linkage, correction history, license status, public-safe status, support status, and archive-not-current notices for NAF records and objects.

23.2.14.2 Archive Controls shall apply to all NAF output classes, including signals, Dockets, challenge briefs, Campaign objects, learning objects, quests, bounties, builds, evidence packs, method notes, dataset cards, model cards, system cards, benchmark cards, agent cards, API cards, digital twin cards, Studio workflows, Marketplace objects, Registry records, Grid inputs, TRL notes, Reports, National Portfolio objects, Nexus Universe outputs, Handoff Packages, correction records, withdrawal records, recall records, and non-continuation records.

23.2.14.3 Archive shall preserve institutional memory without implying current validity, active support, approval, certification, procurement status, financeability, public authority decision, consent, deployment authorization, or execution.

23.2.14.4 Archive Controls shall support learning from superseded, withdrawn, recalled, deprecated, unsupported, or non-continuing objects while preventing stale reliance.

## 23.3 Safeguard Architecture

### 23.3.1 Community Safeguards.

23.3.1.1 Community Safeguards shall ensure that community participation, community data, community knowledge, community priorities, community vulnerabilities, community resilience needs, local context, local risk experience, community-facing communications, Campaign participation, National Portfolio input, Nexus Universe participation, Studio participation, Reports input, and handoff-related community matters are handled with dignity, care, accuracy, permission, non-extraction, and correctionability.

23.3.1.2 Community Safeguards shall require community-sensitive classification where appropriate, data minimization, public-safe transformation, consent boundary notices, participation records, representation controls, language access, accessibility review, harm review, public-facing correction, and protected knowledge controls where relevant.

23.3.1.3 Community participation shall not imply consent, endorsement, approval, land access, data permission, procurement support, deployment authorization, or execution.

23.3.1.4 Community Safeguards shall apply before any public claim is made about community support, community participation, community need, community benefit, community data, community risk, community readiness, or community-facing handoff.

### 23.3.2 Indigenous Protocols Where Applicable.

23.3.2.1 Where Indigenous institutions, Indigenous communities, Indigenous knowledge, Indigenous data, Indigenous lands, Indigenous governance, Indigenous protocols, Indigenous rights, sacred sites, culturally sensitive knowledge, biodiversity knowledge, protected knowledge, or Indigenous participation is implicated, NAF shall apply Indigenous protocol-sensitive safeguards.

23.3.2.2 Indigenous protocol-sensitive safeguards shall require appropriate routing, permission, respectful engagement, protected knowledge restrictions, data sovereignty awareness, community governance awareness, disclosure controls, public-safe language, consent boundary notices, archive restrictions, and correction pathways.

23.3.2.3 NAF shall not treat Indigenous participation, Indigenous-related data, Indigenous-related knowledge, or Indigenous-related public-safe summaries as consent, consultation satisfaction, accommodation, rights clearance, land access, data permission, approval, endorsement, deployment authorization, or execution.

23.3.2.4 Indigenous protocol-sensitive matters may require stop-the-line action where continued use, publication, demonstration, listing, registration, handoff, or archive access may cause harm, disclose protected knowledge, or overclaim consent.

### 23.3.3 Protected Knowledge.

23.3.3.1 Protected Knowledge shall include knowledge that is culturally sensitive, community-sensitive, Indigenous protocol-sensitive where applicable, security-sensitive, cyber-sensitive, biosecurity-sensitive, location-sensitive, youth-sensitive, health-sensitive, humanitarian-sensitive, commercially restricted where lawfully protected, or otherwise restricted from ordinary publication, extraction, reuse, AI training, disclosure, or handoff.

23.3.3.2 Protected Knowledge shall be identified, classified, access-controlled, public-safe transformed where appropriate, excluded from public release where necessary, restricted from AI use where appropriate, restricted from Marketplace display where appropriate, restricted from Reports where appropriate, and subject to special archive rules.

23.3.3.3 Protected Knowledge shall not be treated as open data, public-safe data, reusable data, training data, publication material, Marketplace material, Registry display material, Studio demonstration material, or handoff-recipient material unless appropriate authority, permission, safeguards, and release class are recorded.

23.3.3.4 Protected Knowledge incidents shall trigger immediate containment, claims freeze where applicable, data freeze, public-safe review, safeguard review, correction, withdrawal, recall, archive restriction, and notice where appropriate.

### 23.3.4 Youth Safeguards.

23.3.4.1 Youth Safeguards shall apply to youth participants, students, minors where applicable, early-career participants, youth data, youth learning records, youth Campaign participation, youth WILPs, youth micro-credentials, youth public display, youth contributions, and youth participation in Nexus Universe, Academy, Risk Academy, Foundry, Campaigns, Studio, Labs, Reports, Marketplace, Registry, and National Portfolios.

23.3.4.2 Youth Safeguards shall include appropriate consent or permission where required, privacy protections, visibility controls, anti-exploitation controls, labor boundary controls, supervision, safeguarding procedures, harassment prevention, accessibility, language access, age-appropriate public-safe communication, and correction pathways.

23.3.4.3 Youth participation shall not create employment, labor authorization, public authority approval, consent to data use beyond recorded permissions, public display authorization beyond recorded settings, procurement status, deployment authorization, or execution.

23.3.4.4 Youth-related public display shall be restricted or anonymized where necessary to protect safety, privacy, dignity, and future opportunity.

### 23.3.5 Disability Inclusion.

23.3.5.1 Disability Inclusion shall be a required safeguard within NAF. It shall apply to learning, Campaigns, Reports, Marketplace, Registry, Studio, Grid, Nexus Universe, National Portfolios, Risk Agency engagements, public-safe summaries, handoff materials, dashboards, software, data, public meetings, rooms, and digital public-good objects.

23.3.5.2 Disability Inclusion shall include accessible formats, screen-reader compatibility, captions, alt text, plain-language summaries where appropriate, low-bandwidth access where appropriate, mobile-first formats where appropriate, physical accessibility where events or rooms are involved, reasonable accommodation processes, and disability-sensitive data protection.

23.3.5.3 Accessibility or disability inclusion review shall not create certification by default. It shall record accessibility status, gaps, dependencies, correction needs, and release conditions.

23.3.5.4 Accessibility failures in public-facing or participant-facing materials shall be correctable and may trigger release restriction, correction, public repair, archive update, or non-continuation.

### 23.3.6 Accessibility.

23.3.6.1 Accessibility shall be embedded across NAF as a delivery requirement, not a decorative add-on. All NAF outputs intended for public, participant, learner, community, public authority, or handoff use shall be reviewed for accessibility appropriate to audience, format, technology, language, bandwidth, device context, and use environment.

23.3.6.2 Accessibility controls may include plain-language summaries, multilingual metadata, translation, captions, alt text, keyboard navigation, screen-reader compatibility, low-bandwidth formats, offline packages, accessible PDFs, accessible dashboards, mobile formats, color and contrast checks, and inclusive facilitation design.

23.3.6.3 Accessibility status shall be recorded for Reports, learning objects, Campaign objects, software objects, dashboards, Studio workflows, Marketplace listings, Registry records, Nexus Universe outputs, public-safe summaries, and Handoff Packages where applicable.

23.3.6.4 Accessibility gaps shall be recorded and corrected according to priority, audience, risk, and use class.

### 23.3.7 Humanitarian Sensitivity.

23.3.7.1 Humanitarian Sensitivity shall apply where NAF work involves crisis-affected populations, disaster-affected communities, humanitarian actors, displacement, conflict, public health emergency, food insecurity, water insecurity, infrastructure disruption, cyber disruption, climate shock, biodiversity loss, or other acute vulnerability.

23.3.7.2 Humanitarian Sensitivity shall require do-no-harm discipline, data minimization, protection awareness, public-safe language, no-warning controls, no-command controls, affected-population dignity, privacy, security, sensitive location controls, misinformation risk review, and correction readiness.

23.3.7.3 NAF shall not replace humanitarian coordination, emergency command, public authority action, public warning, relief allocation, medical decision, security action, or operational response.

23.3.7.4 Humanitarian-sensitive materials shall be reviewed before public release, media use, Campaign use, Nexus Universe presentation, Marketplace listing, Registry display, Studio demonstration, or handoff.

### 23.3.8 Public-Interest Participation.

23.3.8.1 Public-Interest Participation shall include civil society, NGOs, community organizations, youth groups, universities, public-interest researchers, accessibility advocates, rights advocates, environmental actors, humanitarian actors, local institutions, affected stakeholders, and other actors contributing to public-good legitimacy, safeguard review, public-safe reporting, and accountability.

23.3.8.2 Public-Interest Participation shall be structured, recorded, non-extractive, protected, and correctionable. It shall not be symbolic presence or legitimacy decoration.

23.3.8.3 Public-Interest Participation shall not create endorsement, consent, approval, public authority action, procurement status, financeability, deployment authorization, or execution.

23.3.8.4 Public-interest concerns shall be capable of becoming Docket items, safeguard records, correction records, public-safe reporting inputs, Campaign improvements, Studio improvements, Reports corrections, National Portfolio updates, Nexus Universe room topics, and Handoff Dependency Register entries.

### 23.3.9 Non-Extractive Engagement.

23.3.9.1 Non-Extractive Engagement shall require that NAF not collect, use, display, publish, train on, commercialize, hand off, or route community knowledge, Indigenous knowledge where applicable, protected knowledge, lived-risk knowledge, learner data, contributor data, or public-interest input in ways that extract value without appropriate permission, protection, attribution where appropriate, benefit awareness, safeguard review, and correction rights.

23.3.9.2 Non-Extractive Engagement shall require purpose clarity, scope clarity, use limits, data minimization, visibility controls, protected knowledge controls, consent boundary notices, attribution rules where appropriate, correction pathways, withdrawal options where appropriate, and archive restrictions where appropriate.

23.3.9.3 Support, sponsorship, provider contribution, Campaign mobilization, public reporting, or handoff shall not be used to bypass non-extractive engagement obligations.

23.3.9.4 Extractive conduct may trigger stop-the-line, correction, withdrawal, public repair, archive restriction, participant notice, and non-continuation.

### 23.3.10 Community-Facing Correction.

23.3.10.1 Community-Facing Correction shall occur where NAF materials, outputs, Campaigns, Reports, dashboards, public-safe summaries, Nexus Universe outputs, National Portfolio records, Studio outputs, Marketplace listings, Registry records, Risk Agency notes, or Handoff Packages misstate community context, overclaim participation, imply consent, disclose protected knowledge, misrepresent risk, create accessibility harm, create language harm, or otherwise affect communities.

23.3.10.2 Community-Facing Correction may include corrected language, addendum, public repair, participant notice, community notice where appropriate, withdrawal, recall, restricted access, archive update, and non-continuation.

23.3.10.3 Community-Facing Correction shall not require the community to carry the burden of institutional error. NAF shall preserve correction pathways that are accessible, safe, respectful, multilingual where appropriate, and protective of complainants and affected participants.

23.3.10.4 Community-Facing Correction shall preserve institutional trust by correcting the record without overclaiming representation, consent, authority, or execution.

## 23.4 Security and Privacy

### 23.4.1 Zero-Trust Principles.

23.4.1.1 NAF shall apply zero-trust principles where appropriate to digital systems, repositories, data rooms, secure rooms, Studio environments, cloud environments, edge environments, HPC environments, sovereign compute environments, Marketplace systems, Registry systems, Reports repositories, DICE, DRI dashboards, Observatory systems, Campaign systems, Academy systems, Risk Agency records, Grid systems, Nexus Universe systems, National Node systems, and handoff environments.

23.4.1.2 Zero-trust principles shall include explicit verification, least privilege, segmentation where appropriate, continuous monitoring where appropriate, device and identity awareness where appropriate, access logging, access review, incident response, and denial of implicit trust based solely on network location, institutional affiliation, participant status, sponsor status, provider status, public authority presence, or prior access.

23.4.1.3 Zero-trust implementation shall be proportionate to risk, sensitivity, resource capacity, jurisdiction, technology context, and operational feasibility.

23.4.1.4 Zero-trust status shall not be represented as cybersecurity certification, privacy certification, service warranty, provider validation, public authority approval, deployment authorization, or execution.

### 23.4.2 Identity and Access Management.

23.4.2.1 Identity and Access Management shall govern who may access NAF systems, rooms, records, repositories, datasets, models, dashboards, Studio workflows, Marketplace management interfaces, Registry management interfaces, Reports drafts, DICE records, DRI records, Observatory records, Grid records, Nexus Universe systems, National Portfolio records, Risk Agency records, Handoff Packages, and archives.

23.4.2.2 Access shall be role-based, purpose-limited, time-limited where appropriate, reviewable, revocable, logged where appropriate, and aligned with data class, AI-use class, cyber class, privacy class, public-safe class, safeguard class, release class, and recipient class.

23.4.2.3 Access grants shall not create data rights, publication rights, handoff rights, governance authority, public authority approval, procurement status, financeability, consent, deployment authorization, or execution.

23.4.2.4 Access misuse may trigger suspension, revocation, incident response, correction, archive restriction, and downstream notice where appropriate.

### 23.4.3 Least Privilege.

23.4.3.1 Least Privilege shall require that users, contributors, reviewers, maintainers, experts, sponsors, providers, public authority learning participants, capital readers, insurance readers, donors, community participants, and recipients receive only the access necessary for the recorded purpose, role, scope, and period.

23.4.3.2 Least Privilege shall apply to repositories, datasets, models, AI systems, Studio workflows, secure rooms, data rooms, cloud environments, edge environments, HPC environments, APIs, dashboards, Registry tools, Marketplace tools, Reports drafts, Campaign systems, Academy systems, Risk Agency records, Grid systems, Nexus Universe systems, and Handoff Packages.

23.4.3.3 Elevated access shall require heightened justification, review, logging where appropriate, recertification, and revocation pathway.

23.4.3.4 Least Privilege failure may be treated as a security, privacy, data, protected knowledge, public-safe, or safeguard incident depending on the affected material.

### 23.4.4 Encryption Where Appropriate.

23.4.4.1 Encryption shall be used where appropriate to protect sensitive data, restricted data, public authority-sensitive data, community-sensitive data, Indigenous protocol-sensitive data where applicable, protected knowledge, youth data, health-sensitive data, cyber-sensitive data, infrastructure-sensitive data, geospatial-sensitive data, credentials, access tokens, secrets, confidential records, secure-room materials, data-room materials, and handoff-recipient-only materials.

23.4.4.2 Encryption practices shall be proportionate to risk, jurisdiction, operational context, system architecture, resource capacity, and lawful requirements.

23.4.4.3 Encryption status shall be recorded where relevant to security, privacy, data governance, secure rooms, handoff, archive, or incident response.

23.4.4.4 Encryption shall not create unrestricted permission to collect, store, process, publish, hand off, or use data. Encryption is a control, not a legal basis, consent record, public authority approval, or deployment authorization.

### 23.4.5 Secure Repositories.

23.4.5.1 Secure Repositories shall be used for software, data, models, reports, methods, documentation, evidence packs, Registry records, Marketplace records, Studio workflows, Grid records, TRL notes, DRI records, GRIx objects, Observatory records, Academy materials, Campaign records, Risk Agency records, Handoff Packages, correction records, and archives where appropriate.

23.4.5.2 Secure Repository controls may include access management, branch protection, review requirements, dependency scanning, secret scanning, SBOM records, vulnerability disclosure, backup, restore testing, logging, issue tracking, release classification, license review, and archive labeling.

23.4.5.3 Repository publication shall not create warranty, certification, procurement approval, provider validation, public authority approval, data right, AI-use permission, deployment authorization, or execution.

23.4.5.4 Repository incidents shall be triaged as cyber, data, AI, privacy, public-safe, protected knowledge, provider, sponsor, handoff, or archive incidents as applicable.

### 23.4.6 Secret Scanning.

23.4.6.1 Secret Scanning shall be used where appropriate to detect credentials, API keys, tokens, passwords, certificates, private keys, connection strings, access secrets, infrastructure secrets, cloud secrets, and other sensitive operational materials in repositories, notebooks, scripts, configuration files, data packages, documentation, Studio workflows, Reports packages, and handoff packages.

23.4.6.2 Detected secrets shall be contained, revoked, rotated, removed, investigated, and corrected according to severity and exposure.

23.4.6.3 Secret exposure may trigger cyber incident response, privacy review, data review, public-safe review, provider notice, sponsor notice, recipient notice, Marketplace delisting, Registry status update, handoff recall, archive restriction, and public-safe notice where appropriate.

23.4.6.4 Secret Scanning status shall not be represented as security certification or warranty.

### 23.4.7 Dependency Scanning.

23.4.7.1 Dependency Scanning shall be used where appropriate for software, notebooks, data pipelines, model pipelines, APIs, connectors, adapters, dashboards, Studio workflows, infrastructure-as-code templates, and public-good technical baselines.

23.4.7.2 Dependency Scanning shall identify vulnerable dependencies, unsupported dependencies, license concerns, supply-chain concerns, version drift, reproducibility concerns, and support status issues.

23.4.7.3 Dependency issues shall be triaged, patched, mitigated, documented, accepted within scope, deprecated, withdrawn, or archived according to severity, release class, support class, and downstream relevance.

23.4.7.4 Dependency Scanning shall not create security certification, open-source compliance certification, warranty, provider validation, deployment authorization, or execution.

### 23.4.8 SBOM Literacy.

23.4.8.1 SBOM Literacy shall be required for NAF software, data pipeline, model pipeline, infrastructure, and digital public-good work where software dependencies, supply-chain risk, vulnerability management, or handoff relevance is material.

23.4.8.2 SBOM records may identify components, versions, licenses, suppliers, dependencies, known vulnerabilities, support status, update status, and correction status.

23.4.8.3 SBOM Literacy shall support secure release, public-good reuse, Registry status, Marketplace discovery, Studio operation, Grid input, TRL context, and handoff dependency mapping.

23.4.8.4 SBOM records shall not create cybersecurity certification, software warranty, procurement approval, provider validation, public authority approval, deployment authorization, or execution.

### 23.4.9 Incident Response.

23.4.9.1 Incident Response shall be available for public-safe incidents, data incidents, AI incidents, cyber incidents, privacy incidents, protected knowledge incidents, public authority boundary incidents, finance boundary incidents, procurement boundary incidents, provider validation incidents, sponsor control incidents, consent overclaim incidents, handoff overclaim incidents, execution overclaim incidents, and archive incidents.

23.4.9.2 Incident Response shall include intake, classification, severity assessment, containment, claims freeze where applicable, data freeze where applicable, technical freeze where applicable, access restriction, investigation, correction, notification where appropriate, public-safe notice where appropriate, Registry update, Marketplace delisting where appropriate, Handoff Recall where appropriate, archive action, lessons learned, and closure.

23.4.9.3 Incident Response shall be proportionate to risk and shall preserve evidence, privacy, confidentiality, public-safe discipline, safeguard obligations, legal obligations, and correctionability.

23.4.9.4 Incident Response shall not imply admission of liability by default, public authority action, regulated notice satisfaction, downstream operational control, or execution unless separately and lawfully determined.

### 23.4.10 Access Recertification.

23.4.10.1 Access Recertification shall periodically review whether users, contributors, reviewers, maintainers, experts, sponsors, providers, public authority learning participants, capital readers, insurance readers, donors, community participants, and recipients continue to require access to NAF systems, records, rooms, repositories, datasets, models, dashboards, Studio workflows, Registry tools, Marketplace tools, Reports drafts, DRI outputs, Observatory records, Grid records, National Portfolio records, Risk Agency records, Handoff Packages, or archives.

23.4.10.2 Access that is no longer necessary, excessive, expired, conflicted, unsafe, unreviewed, unsupported, or inconsistent with role shall be revoked, reduced, restricted, or reclassified.

23.4.10.3 Access Recertification shall support least privilege, privacy, cyber resilience, protected knowledge controls, public-safe discipline, safeguard obligations, and archive integrity.

23.4.10.4 Access Recertification shall not create entitlement to continued participation, employment, procurement status, public authority role, finance role, data right, deployment authority, or execution.

### 23.4.11 Deletion, Sealing, and Archive.

23.4.11.1 Deletion, Sealing, and Archive shall govern end-of-life treatment for records, datasets, models, reports, software, Studio workflows, Campaign records, Academy records, Risk Agency records, Handoff Packages, personal data, sensitive data, protected knowledge, credentials, logs, access records, and correction records.

23.4.11.2 Deletion may be used where lawful and appropriate for data minimization, privacy, retention limits, error correction, consent withdrawal where applicable, unsafe materials, secrets, duplicative records, or records not required for archive.

23.4.11.3 Sealing may be used where preservation is required but access must be restricted because of sensitivity, protected knowledge, legal hold, investigation, youth protection, privacy, cyber risk, public-safe risk, or safeguard risk.

23.4.11.4 Archive may be used where institutional memory, correction history, reproducibility, accountability, public-good learning, or legal retention requires preservation. Archive shall include archive-not-current notices and shall not imply current validity, approval, certification, support, procurement status, financeability, deployment authorization, or execution.

## 23.5 Incident Classes

### 23.5.1 Public-Safe Incident.

23.5.1.1 A Public-Safe Incident shall mean any release, draft, statement, Report, Campaign material, Marketplace listing, Registry display, dashboard, Studio output, Grid note, TRL note, DRI output, Observatory output, Risk Agency output, Nexus Universe output, National Portfolio output, Handoff Package, media material, public-safe summary, or communication that may create unsafe public interpretation, public warning overclaim, approval overclaim, finance overclaim, procurement overclaim, certification overclaim, consent overclaim, deployment overclaim, execution overclaim, sensitive disclosure, protected knowledge disclosure, or public harm.

23.5.1.2 Public-Safe Incidents may trigger claims freeze, publication pause, correction, public repair, withdrawal, delisting, Registry status update, Handoff Recall, archive restriction, and non-continuation.

### 23.5.2 Data Incident.

23.5.2.1 A Data Incident shall mean unauthorized, unsafe, inaccurate, excessive, unclassified, misclassified, improperly disclosed, improperly transformed, improperly published, improperly accessed, improperly exported, improperly retained, improperly deleted, improperly sealed, improperly archived, or improperly handed-off data within NAF.

23.5.2.2 Data Incidents may involve open data, public-safe data, restricted data, public authority-sensitive data, community-sensitive data, Indigenous protocol-sensitive data where applicable, protected knowledge, youth data, health-sensitive data, cyber-sensitive data, infrastructure-sensitive data, geospatial-sensitive data, handoff-recipient-only data, archive-only data, metadata, lineage, data-use labels, or AI-use labels.

23.5.2.3 Data Incidents may trigger data freeze, access restriction, containment, rights review, privacy review, safeguard review, public-safe review, correction, notice, Handoff Recall, archive restriction, deletion, sealing, or non-continuation.

### 23.5.3 AI Incident.

23.5.3.1 An AI Incident shall mean unauthorized, unsafe, unreviewed, misclassified, harmful, biased, misleading, overclaimed, uncontrolled, agentic, privacy-invasive, data-leaking, prompt-injected, tool-misused, high-stakes, public-safe-failing, or boundary-breaching AI use within NAF.

23.5.3.2 AI Incidents may involve model objects, AI systems, agentic workflows, model cards, system cards, benchmark cards, agent workflow cards, AI-use labels, training data, fine-tuning data, retrieval data, outputs, evaluations, red-team records, Studio workflows, Reports, DRI outputs, dashboards, Marketplace listings, Registry records, and Handoff Packages.

23.5.3.3 AI Incidents may trigger AI-use freeze, model withdrawal, output withdrawal, access restriction, red-team review, bias and harm review, data review, cyber review, privacy review, public-safe review, correction, Registry update, Marketplace delisting, Handoff Recall, archive restriction, and non-continuation.

### 23.5.4 Cyber Incident.

23.5.4.1 A Cyber Incident shall mean unauthorized access, credential exposure, secret exposure, vulnerability exploitation, malware, supply-chain compromise, repository compromise, API abuse, insecure configuration, data exfiltration, access escalation, denial of service, unauthorized tool use, unsafe disclosure, or cyber-sensitive publication within NAF.

23.5.4.2 Cyber Incidents may affect repositories, software, APIs, connectors, dashboards, data rooms, secure rooms, Studio environments, Marketplace, Registry, Reports repositories, DICE, DRI dashboards, Observatory systems, cloud, edge, HPC, sovereign compute, AI-RAN, O-RAN, private wireless, IoT, OT, IIoT, sensors, and handoff environments.

23.5.4.3 Cyber Incidents may trigger access revocation, credential rotation, secret removal, vulnerability remediation, technical freeze, public-safe cyber review, Registry update, Marketplace delisting, Handoff Recall, archive restriction, and notice where appropriate.

### 23.5.5 Privacy Incident.

23.5.5.1 A Privacy Incident shall mean unauthorized, unsafe, excessive, inaccurate, unconsented where consent is required, misclassified, improperly disclosed, improperly displayed, improperly shared, improperly exported, improperly retained, improperly processed, or improperly archived personal data or profile information within NAF.

23.5.5.2 Privacy Incidents may affect learners, workers, contributors, reviewers, maintainers, experts, public authority participants, community participants, youth, vulnerable participants, sponsors, providers, recipients, clients, or other persons.

23.5.5.3 Privacy Incidents may trigger privacy review, access restriction, data freeze, deletion, sealing, notice where appropriate, correction, public-safe review, safeguard review, archive restriction, and non-continuation.

### 23.5.6 Protected Knowledge Incident.

23.5.6.1 A Protected Knowledge Incident shall mean unauthorized, unsafe, unreviewed, overbroad, extractive, public, AI-enabled, Marketplace-listed, Registry-displayed, Report-published, Studio-demonstrated, Campaign-used, Nexus Universe-presented, or handoff-shared use of protected knowledge.

23.5.6.2 Protected Knowledge Incidents may involve Indigenous protocol-sensitive knowledge where applicable, community-sensitive knowledge, cultural knowledge, sacred site information, sensitive species information, security-sensitive knowledge, cyber-sensitive knowledge, biosecurity-sensitive knowledge, humanitarian-sensitive knowledge, or other restricted knowledge.

23.5.6.3 Protected Knowledge Incidents shall trigger immediate containment, data freeze, claims freeze where applicable, access restriction, safeguard review, public-safe review, correction, withdrawal, recall, archive restriction, and community-facing correction where appropriate.

### 23.5.7 Public Authority Boundary Incident.

23.5.7.1 A Public Authority Boundary Incident shall mean any statement, record, room, Report, dashboard, Studio workflow, DRI output, Observatory output, Grid input, TRL note, Campaign material, Marketplace listing, Registry status, Nexus Universe output, Risk Agency note, National Portfolio record, Handoff Package, or participant conduct that suggests or creates confusion that NAF has made or caused public authority action.

23.5.7.2 Public Authority Boundary Incidents may include public warning overclaim, approval overclaim, regulatory overclaim, permit overclaim, license overclaim, public finance overclaim, procurement overclaim, emergency command overclaim, public authority endorsement overclaim, or official adoption overclaim.

23.5.7.3 Such incidents may trigger claims freeze, public-safe notice, correction, Report revision, Registry update, Marketplace delisting, Handoff Recall, archive action, and boundary repair.

### 23.5.8 Finance Boundary Incident.

23.5.8.1 A Finance Boundary Incident shall mean any statement, record, room, Report, Campaign, Marketplace listing, Registry status, Nexus Universe output, Risk Agency output, National Portfolio record, Handoff Package, or participant conduct that suggests investment advice, financial advice, securities solicitation, valuation, bankability, financeability, public finance allocation, donor commitment, grant approval, transaction, or finance execution by NAF.

23.5.8.2 Finance Boundary Incidents may trigger claims freeze, finance-language correction, no-reliance notice, public-safe notice, Marketplace update, Registry update, Handoff Recall, withdrawal, archive, and escalation to regulated-perimeter review.

### 23.5.9 Procurement Boundary Incident.

23.5.9.1 A Procurement Boundary Incident shall mean any statement, record, Marketplace listing, Registry status, Report, Studio demonstration, Grid input, TRL note, Nexus Universe output, Campaign material, Risk Agency note, National Portfolio record, Handoff Package, provider contribution, sponsor support, or participant conduct that suggests procurement recommendation, preferred provider status, supplier approval, vendor validation, tender support, sole-source justification, procurement specification, or procurement decision by NAF.

23.5.9.2 Procurement Boundary Incidents may trigger claims freeze, provider-neutrality review, procurement-neutrality review, correction, Marketplace delisting, Registry update, public-safe notice, Handoff Recall, withdrawal, archive, and boundary repair.

### 23.5.10 Provider Validation Incident.

23.5.10.1 A Provider Validation Incident shall mean any use of NAF participation, contribution, support, demonstration, Marketplace listing, Registry status, Grid input, TRL note, Report inclusion, Nexus Universe visibility, Studio workflow, Risk Agency match, National Portfolio relevance, or Handoff Package to imply that a provider, vendor, supplier, contractor, consultant, platform, software, model, dataset, infrastructure, or service has been validated, certified, endorsed, preferred, approved, or selected.

23.5.10.2 Provider Validation Incidents may trigger provider notice, claims freeze, correction, Marketplace delisting, Registry status update, public-safe notice, Handoff Recall, withdrawal, archive, and participation restriction.

### 23.5.11 Sponsor Control Incident.

23.5.11.1 A Sponsor Control Incident shall mean any attempt or appearance that sponsor support, host support, in-kind contribution, venue support, compute support, cloud support, media support, Campaign support, Nexus Universe support, Academy support, Foundry support, Reports support, Marketplace support, Registry support, Studio support, Grid support, or handoff support controls evidence, editorial content, routing, Registry status, Marketplace placement, public-safe reporting, public authority learning, finance-readiness framing, provider treatment, or handoff outcomes.

23.5.11.2 Sponsor Control Incidents may trigger conflict review, sponsor-boundary review, claims freeze, correction, public-safe notice, support restriction, acknowledgement revision, delisting, Registry update, Handoff Recall, archive, or termination of support relationship.

### 23.5.12 Consent Overclaim Incident.

23.5.12.1 A Consent Overclaim Incident shall mean any statement, record, Campaign, Report, Studio workflow, Nexus Universe output, Marketplace listing, Registry status, National Portfolio record, Risk Agency output, Handoff Package, or participant conduct that suggests community consent, Indigenous consent where applicable, data consent, land access consent, protected knowledge permission, or affected stakeholder approval where such consent or permission has not been separately and lawfully recorded.

23.5.12.2 Consent Overclaim Incidents shall trigger immediate public-safe and safeguard review, claims freeze, correction, public repair where appropriate, withdrawal, Handoff Recall, archive restriction, and community-facing correction where appropriate.

### 23.5.13 Handoff Overclaim Incident.

23.5.13.1 A Handoff Overclaim Incident shall mean any statement, record, Handoff Package, recipient claim, Marketplace listing, Registry status, Report, Studio workflow, Grid input, TRL note, Risk Agency note, Nexus Universe output, National Portfolio record, or participant conduct that suggests handoff has created authorization, approval, certification, procurement status, financeability, insurability, public authority action, consent, deployment authorization, operational control, or execution.

23.5.13.2 Handoff Overclaim Incidents may trigger Handoff Correction, Handoff Recall, recipient notice, claims freeze, Registry update, Marketplace delisting, Report correction, public-safe notice, archive, and non-continuation.

### 23.5.14 Execution Overclaim Incident.

23.5.14.1 An Execution Overclaim Incident shall mean any statement, record, action, output, handoff, room, demonstration, Campaign, Report, Marketplace listing, Registry status, Studio workflow, Grid input, TRL note, National Portfolio object, Nexus Universe output, Risk Agency note, sponsor claim, provider claim, recipient claim, or participant conduct that suggests Nexus, GCRI, The Global Risks Forum, The Global Risks Alliance, a Nexus Consortium, a National Node, a Working Group, a Competence Cell, a Campaign, a Foundry team, a reviewer, a maintainer, a sponsor, a provider, or a public authority learning participant is executing downstream projects by implication.

23.5.14.2 Execution Overclaim Incidents shall be treated as serious boundary incidents and may trigger stop-the-line, claims freeze, technical freeze, public-safe notice, correction, withdrawal, Marketplace delisting, Registry status update, Handoff Recall, archive, role repair, participant restriction, or non-continuation.

## 23.6 Stop-the-Line

### 23.6.1 Stop-the-Line Trigger.

23.6.1.1 Stop-the-Line may be triggered where continued work, review, release, publication, listing, registration, Studio demonstration, Grid routing, TRL notation, Campaign activation, Nexus Universe presentation, National Portfolio use, Risk Agency delivery, handoff, or archive access may cause material harm, unsafe reliance, protected knowledge disclosure, serious data issue, AI issue, cyber issue, privacy issue, public-safe failure, safeguard failure, public authority overclaim, finance overclaim, procurement overclaim, provider validation, sponsor control, consent overclaim, handoff overclaim, deployment overclaim, or execution overclaim.

23.6.1.2 Stop-the-Line may be triggered by stewards, reviewers, maintainers, safeguard reviewers, data stewards, AI reviewers, cyber reviewers, privacy reviewers, public-safe reviewers, community participants, Indigenous institutions where applicable, public-interest participants, Risk Agency experts, National Nodes, Working Groups, Competence Cells, Nexus pillars, institutional stewards, or other authorized escalation channels.

23.6.1.3 Stop-the-Line shall prioritize safety, integrity, legality, public-good discipline, and correction over speed, visibility, sponsor expectations, provider expectations, release schedules, Campaign momentum, Nexus Universe deadlines, Marketplace display, Registry continuity, or handoff pressure.

### 23.6.2 Immediate Containment.

23.6.2.1 Immediate Containment shall occur after a Stop-the-Line trigger where necessary to prevent further harm or reliance.

23.6.2.2 Containment may include access restriction, publication pause, release pause, Campaign pause, Studio shutdown, secure-room lock, data-room restriction, repository lock, model freeze, API restriction, Marketplace delisting, Registry status update, Report hold, Nexus Universe hold, Handoff Recall, recipient notice, sponsor notice, provider notice, public-safe notice, or archive restriction.

23.6.2.3 Immediate Containment shall be proportionate to severity and shall preserve evidence needed for review, correction, legal retention, and institutional memory.

23.6.2.4 Containment shall not be treated as final determination unless separately recorded after review.

### 23.6.3 Claims Freeze.

23.6.3.1 A Claims Freeze shall pause or restrict public, participant, sponsor, provider, recipient, media, Marketplace, Registry, Report, Campaign, Nexus Universe, Risk Agency, National Portfolio, Studio, Grid, TRL, and handoff claims related to the affected object, output, record, or activity.

23.6.3.2 Claims Freeze shall be used where claims may overstate evidence, approval, certification, readiness, financeability, insurability, procurement status, public authority action, consent, deployment authorization, execution, sponsor role, provider status, or community participation.

23.6.3.3 Claims Freeze may remain in place until correction, withdrawal, recall, supersession, archive, reinstatement, or non-continuation is recorded.

### 23.6.4 Data Freeze.

23.6.4.1 A Data Freeze shall pause or restrict collection, processing, transformation, publication, sharing, AI use, transfer, export, Studio use, data-room use, secure-room use, Marketplace listing, Registry display, Reports inclusion, Nexus Universe presentation, or handoff of affected data.

23.6.4.2 Data Freeze shall be used where data rights, privacy, protected knowledge, sensitive classification, lineage, cross-border transfer, data sovereignty, AI-use status, public-safe status, safeguard status, or accuracy is in question.

23.6.4.3 Data Freeze shall remain until data review, privacy review, rights review, safeguard review, public-safe review, correction, deletion, sealing, archive, or approved release is recorded.

### 23.6.5 Technical Freeze.

23.6.5.1 A Technical Freeze shall pause or restrict code release, model release, API release, infrastructure change, Studio workflow execution, dashboard publication, digital twin use, simulation use, repository merge, package distribution, Marketplace listing, Registry status change, Grid routing, TRL notation, Nexus Universe demonstration, or handoff of affected technical objects.

23.6.5.2 Technical Freeze shall be used where software quality, model safety, AI safety, cyber risk, dependency risk, secret exposure, vulnerability, incorrect configuration, unsupported dependency, reproducibility failure, public-safe failure, or handoff risk is in question.

23.6.5.3 Technical Freeze shall remain until technical review, cyber review, AI review, data review, public-safe review, correction, withdrawal, recall, archive, or approved reinstatement is recorded.

### 23.6.6 Marketplace Delisting.

23.6.6.1 Marketplace Delisting may be used where a listed object is incorrect, unsafe, outdated, unsupported, overclaimed, provider-validating, procurement-confusing, finance-confusing, public authority-confusing, consent-overclaiming, deployment-overclaiming, execution-overclaiming, or otherwise unsuitable for discovery.

23.6.6.2 Delisting may be temporary or permanent. Temporary delisting may occur pending correction; permanent delisting may occur after withdrawal, recall, archive, or non-continuation.

23.6.6.3 Marketplace Delisting shall include a Registry status update where appropriate and may require public-safe notice, recipient notice, sponsor notice, provider notice, or handoff recall.

### 23.6.7 Registry Status Update.

23.6.7.1 Registry Status Update shall be used to reflect changed status, review status, correction status, support status, public-safe status, archive status, withdrawal, suspension, recall, supersession, non-continuation, or reinstatement.

23.6.7.2 Registry status shall be the status-truth surface for NAF objects and shall be corrected promptly where status becomes inaccurate or unsafe.

23.6.7.3 Registry Status Update shall not create certification, approval, procurement status, financeability, insurability, public authority action, consent, deployment authorization, or execution.

### 23.6.8 Public-Safe Notice.

23.6.8.1 Public-Safe Notice may be issued where external users, participants, recipients, public authorities, communities, sponsors, providers, capital readers, insurance readers, donors, media, or other audiences need to understand correction, withdrawal, recall, status change, boundary clarification, or archive status.

23.6.8.2 Public-Safe Notice shall be clear, accurate, proportionate, accessible, language-appropriate where needed, non-alarmist unless appropriate, and bounded by no-warning, no-approval, no-finance, no-procurement, no-certification, no-consent, no-deployment, and no-execution rules.

23.6.8.3 Public-Safe Notice shall not create public warning, public authority action, legal admission by default, investment communication, insurance communication, procurement communication, consent record, deployment instruction, or execution command.

### 23.6.9 Handoff Recall.

23.6.9.1 Handoff Recall shall be triggered where a Handoff Package or handoff-related object is no longer safe or appropriate for recipient use because of error, overclaim, changed conditions, corrected evidence, data issue, AI issue, cyber issue, privacy issue, public-safe issue, protected knowledge issue, safeguard issue, public authority issue, finance issue, insurance issue, procurement issue, provider validation issue, sponsor control issue, consent issue, deployment issue, execution issue, or archive requirement.

23.6.9.2 Handoff Recall shall include recipient notice, recall scope, affected materials, required recipient action, Registry update, Marketplace update, Report correction where applicable, Studio suspension where applicable, Grid or TRL update where applicable, public-safe notice where applicable, archive action, and closure record.

23.6.9.3 Handoff Recall shall not make NAF responsible for downstream execution; recipients remain responsible for downstream reliance, claims, decisions, deployments, operations, and corrections.

### 23.6.10 Archive or Reinstatement.

23.6.10.1 Following Stop-the-Line, the affected object, output, record, or activity may be archived, reinstated, corrected and reinstated, superseded, withdrawn, recalled, restricted, downgraded, or marked non-continuing.

23.6.10.2 Reinstatement shall require recorded review demonstrating that the trigger has been resolved or bounded, claims have been corrected, data issues addressed, technical issues addressed, safeguard issues addressed, public-safe language corrected, status updated, and correction pathway preserved.

23.6.10.3 Archive shall be used where the object or activity should not continue but must be preserved for institutional memory, correction history, reproducibility, accountability, or legal retention.

23.6.10.4 Reinstatement shall not erase correction history, and archive shall not imply current validity.

## 23.7 Correctionability

### 23.7.1 Correction.

23.7.1.1 Correction shall mean the recorded repair of an error, omission, misstatement, overclaim, unsafe language, outdated status, data issue, AI issue, cyber issue, privacy issue, public-safe issue, safeguard issue, protected knowledge issue, public authority boundary issue, finance boundary issue, procurement boundary issue, provider validation issue, sponsor control issue, consent overclaim, handoff overclaim, deployment overclaim, execution overclaim, or archive issue.

23.7.1.2 Correction shall identify the affected object, original issue, correction trigger, correction owner, correction action, affected records, affected recipients, public-safe notice need, downstream propagation need, archive impact, and closure status.

23.7.1.3 Correction shall not be silent where affected users or recipients may continue to rely on the incorrect material.

### 23.7.2 Addendum.

23.7.2.1 Addendum shall be used where the original object remains valid within scope but requires additional context, limitation, assumption, dependency, explanation, safeguard note, public-safe clarification, boundary notice, evidence update, method note, or correction note.

23.7.2.2 Addendum shall be linked to the affected record, Report, listing, status, Studio workflow, Grid input, TRL note, National Portfolio object, Nexus Universe output, Risk Agency note, Handoff Package, or archive record.

23.7.2.3 Addendum shall not obscure material errors that require correction, withdrawal, recall, or supersession.

### 23.7.3 Supersession.

23.7.3.1 Supersession shall be used where a newer object, version, record, method, Report, listing, status, Studio workflow, Grid input, TRL note, National Portfolio object, Nexus Universe output, Risk Agency note, Handoff Package, or archive record replaces an earlier one.

23.7.3.2 Supersession shall include successor link, prior version status, change summary, effective date, support status, public-safe notice where appropriate, and archive rule.

23.7.3.3 Superseded objects shall not be represented as current, supported, approved, certified, procurement-ready, financeable, insurable, public-authority-approved, consented, deployment-authorized, or executable.

### 23.7.4 Withdrawal.

23.7.4.1 Withdrawal shall be used where an object or output should no longer be used because it is materially incorrect, unsafe, unsupported, overclaimed, unreviewed, superseded without safe continuation, rights-restricted, data-restricted, protected knowledge-restricted, public-safe-failing, safeguard-failing, or boundary-breaching.

23.7.4.2 Withdrawal shall include withdrawal reason, affected materials, affected users, affected recipients, public-safe notice where appropriate, Registry update, Marketplace delisting where appropriate, Handoff Recall where appropriate, archive status, and non-continuation status where applicable.

23.7.4.3 Withdrawal shall not erase the record unless deletion or sealing is required. Archive shall preserve necessary institutional memory subject to access restrictions.

### 23.7.5 Retraction Where Necessary.

23.7.5.1 Retraction shall be used where a published Report, public-safe summary, public dashboard, public claim, public listing, public record, or other public object contains serious error, unsafe claim, evidence failure, rights failure, protected knowledge disclosure, public-safe failure, safeguard failure, or boundary breach requiring public removal or formal public correction.

23.7.5.2 Retraction shall be proportionate and shall include a public-safe retraction notice where appropriate, corrected record, reason category, affected identifiers, repository action, Registry update, Marketplace update, Handoff Recall where appropriate, and archive restriction.

23.7.5.3 Retraction shall not be used to conceal ordinary disagreement or criticism. It shall be used where continued public availability creates material risk, misrepresentation, or unsafe reliance.

### 23.7.6 Recall.

23.7.6.1 Recall shall be used where an object, output, package, dataset, model, software release, Studio workflow, Grid input, TRL note, Marketplace listing, Registry record, Report, Campaign material, Nexus Universe output, National Portfolio object, Risk Agency note, or Handoff Package must be called back from users, recipients, rooms, repositories, or downstream pathways.

23.7.6.2 Recall shall identify affected object, recall scope, recall reason, required action, affected recipients, public-safe notice where appropriate, status updates, replacement object where applicable, archive status, and closure.

23.7.6.3 Recall shall preserve downstream recipient responsibility while providing the information needed to stop unsafe reliance.

### 23.7.7 Public Repair.

23.7.7.1 Public Repair shall be used where correction must be visible to public users, communities, participants, public authorities, sponsors, providers, capital readers, insurance readers, donors, media, recipients, or other audiences to prevent continued misunderstanding or harm.

23.7.7.2 Public Repair may include corrected public language, public-safe notice, accessible explanation, community-facing correction, repository update, Report correction, Marketplace update, Registry update, Campaign correction, Nexus Universe correction, and Handoff Recall notice.

23.7.7.3 Public Repair shall be accurate, proportionate, non-defensive, accessible, and bounded by public-safe rules. It shall not create public warning, legal admission by default, public authority action, finance communication, insurance communication, procurement communication, consent record, deployment instruction, or execution command.

### 23.7.8 Archive.

23.7.8.1 Archive shall preserve records for institutional memory, correction history, reproducibility, accountability, learning, legal retention, and future review.

23.7.8.2 Archive shall include status, access class, sensitivity class, correction history, support status, current-validity status, successor links, public-safe status, retention rule, deletion or sealing rule where applicable, and archive-not-current notice.

23.7.8.3 Archive shall not imply current validity, approval, certification, support, procurement status, financeability, insurability, public authority action, consent, deployment authorization, or execution.

### 23.7.9 Non-Continuation.

23.7.9.1 Non-Continuation shall be used where a Docket item, Campaign, learning object, quest, bounty, build, Report, Studio workflow, Grid input, TRL note, Marketplace listing, Registry record, National Portfolio object, Nexus Universe output, Risk Agency engagement, Handoff Package, or other NAF activity will not proceed.

23.7.9.2 Non-Continuation shall identify reason, status, affected participants, affected records, reusable materials, archive status, correction needs, successor pathways where applicable, and public-safe notice where appropriate.

23.7.9.3 Non-Continuation shall be treated as a legitimate lifecycle outcome, not failure by default. It may reflect insufficient evidence, insufficient safeguards, unresolved dependencies, lack of support, changed priorities, boundary risk, correction, archive decision, or responsible restraint.

### 23.7.10 Correction Propagation.

23.7.10.1 Correction Propagation shall require that corrections move to all affected records and surfaces, including repositories, Reports, Marketplace listings, Registry records, Studio workflows, Grid inputs, TRL notes, DRI outputs, GRIx mappings, Observatory outputs, Campaign materials, Academy materials, Foundry outputs, National Portfolio records, Nexus Universe records, Risk Agency outputs, Handoff Packages, recipient records, and archives where applicable.

23.7.10.2 Correction Propagation shall include dependency review to identify downstream materials that rely on the corrected object.

23.7.10.3 Correction Propagation shall include public-safe notice, recipient notice, sponsor notice, provider notice, public authority learning notice, community-facing notice, or handoff recall where appropriate.

23.7.10.4 Correction Propagation shall preserve trust by preventing corrected errors from remaining active in dependent systems.

## 23.8 Metrics, Dashboards, and Operating Intelligence

### 23.8.1 Evidence Velocity.

23.8.1.1 Evidence Velocity shall measure the rate, quality, and lifecycle movement of evidence-bearing work within NAF, including evidence packs, method notes, data records, model cards, system cards, benchmark cards, agent workflow cards, review records, Reports, Studio workflows, Grid inputs, TRL notes, National Portfolio records, Nexus Universe records, and Handoff Packages.

23.8.1.2 Evidence Velocity shall be interpreted as learning and accountability, not as pressure to release unreviewed work. A higher velocity shall not justify bypassing public-safe review, safeguards, data controls, AI controls, cyber controls, privacy controls, or handoff controls.

23.8.1.3 Evidence Velocity shall not be represented as certification, quality ranking, country ranking, provider validation, procurement readiness, financeability, public authority approval, deployment authorization, or execution capacity.

### 23.8.2 Public-Safe Release Velocity.

23.8.2.1 Public-Safe Release Velocity shall measure the rate at which NAF outputs are converted into appropriate public-safe summaries, Reports, Marketplace listings, Registry displays, dashboards, Campaign materials, Nexus Universe outputs, National Portfolio summaries, and public-safe handoff summaries.

23.8.2.2 Public-Safe Release Velocity shall account for release quality, boundary notices, accessibility, translation where applicable, protected knowledge controls, safeguard review, correction status, and archive status.

23.8.2.3 Public-Safe Release Velocity shall not reward unsafe publication, overclaim, public warning confusion, finance overclaim, procurement overclaim, certification overclaim, consent overclaim, deployment overclaim, or execution overclaim.

### 23.8.3 Correction Velocity.

23.8.3.1 Correction Velocity shall measure the speed and completeness with which errors, overclaims, unsafe language, incidents, boundary breaches, data issues, AI issues, cyber issues, privacy issues, public-safe issues, safeguard issues, protected knowledge issues, handoff issues, and archive issues are identified, contained, corrected, propagated, and closed.

23.8.3.2 Correction Velocity shall include time to detect, time to contain, time to correct, time to notify where appropriate, time to propagate, time to update Registry, time to delist where appropriate, time to recall where appropriate, and time to archive.

23.8.3.3 Correction Velocity shall be treated as a trust metric and shall not be used to penalize responsible stop-the-line behavior.

### 23.8.4 National Portfolio Completion.

23.8.4.1 National Portfolio Completion shall measure the lifecycle status of National Portfolio objects, including national context records, systems-risk maps, challenge briefs, evidence need records, Observatory need records, Core Build requests, safeguard records, public authority learning records, readiness question records, Competence Cell workplans, Nexus Universe routing records, handoff dependency notes, correction records, and archives.

23.8.4.2 National Portfolio Completion shall be interpreted within national ownership, localization, public authority boundary, safeguard, public-safe, finance-readiness, procurement-neutrality, and lawful handoff disciplines.

23.8.4.3 National Portfolio Completion shall not create country ranking, public authority approval, public finance allocation, procurement status, financeability, insurability, deployment authorization, or execution.

### 23.8.5 Docket Throughput.

23.8.5.1 Docket Throughput shall measure movement of Docket items through intake, triage, classification, backlog, pathway selection, evidence assembly, review, release, routing, correction, archive, non-continuation, or handoff.

23.8.5.2 Docket Throughput shall be interpreted with work-in-progress discipline, queue discipline, dependency mapping, assumption mapping, bottleneck identification, risk-adjusted prioritization, public-safe release windows, national routing gates, and correction priority override.

23.8.5.3 Docket Throughput shall not reward superficial movement, unsafe speed, unreviewed release, unresolved safeguards, unresolved data issues, unresolved public authority dependencies, unresolved finance boundaries, unresolved procurement boundaries, unresolved handoff dependencies, or execution overclaim.

### 23.8.6 Foundry Build Completion.

23.8.6.1 Foundry Build Completion shall measure completion of public-good software builds, data pipeline builds, dashboard builds, Studio workflow builds, Marketplace object builds, Registry record builds, Grid input builds, TRL evidence builds, National Portfolio builds, Reports builds, Campaign builds, and Handoff Dependency builds.

23.8.6.2 Foundry Build Completion shall include review status, evidence status, data status, AI-use status, cyber status, public-safe status, safeguard status, support class, repository status, Marketplace status, Registry status, Grid status, TRL context, correction status, and archive status.

23.8.6.3 Foundry Build Completion shall not create product certification, warranty, procurement approval, provider validation, financeability, public authority approval, deployment authorization, or execution.

### 23.8.7 Campaign Activation.

23.8.7.1 Campaign Activation shall measure the initiation and movement of Campaign objects, including campaign intake, purpose record, public-safe record, support record, volunteer record, signature record, pledge record, DICE contribution record, DRI contribution record, Working Group formation record, Competence Cell formation record, Universe routing record, correction record, and archive record.

23.8.7.2 Campaign Activation shall include public-safe language, trust and safety controls, fraud controls, sponsor controls, provider controls, data controls, community consent boundary controls, and stop-the-line readiness.

23.8.7.3 Campaign Activation shall not create mandate, vote, binding finance, donor commitment, public authority approval, procurement status, community consent, Indigenous consent where applicable, deployment authorization, or execution authority.

### 23.8.8 Academy Conversion.

23.8.8.1 Academy Conversion shall measure learning-to-contribution, contribution-to-competence, competence-to-national-capacity, national-capacity-to-handoff-context, and learning-to-public-safe-output pathways across Nexus Academy, Risk Academy, ILA, iCRS, WILPs, micro-credentials, Foundry, Campaigns, Reports, Studio, Grid, Nexus Universe, National Portfolios, and Handoff Packages.

23.8.8.2 Academy Conversion shall include learner safeguards, youth safeguards, privacy controls, accessibility, assessment controls, curriculum review, AI learning controls, data controls, sponsor and provider controls, correction, withdrawal, and archive.

23.8.8.3 Academy Conversion shall not create professional license, employment guarantee, wage guarantee, procurement qualification, public authority competence certification, deployment authorization, or execution.

### 23.8.9 Labs-to-Foundry Conversion.

23.8.9.1 Labs-to-Foundry Conversion shall measure the movement of research questions, evidence gaps, testbed records, method notes, dataset records, model cards, system cards, benchmark records, scenario records, public-safe summaries, and research impact records into Foundry quests, bounties, builds, Reports, Studio workflows, Grid inputs, TRL notes, Marketplace listings, Registry records, National Portfolio objects, Nexus Universe outputs, and Handoff Packages.

23.8.9.2 Labs-to-Foundry Conversion shall include research ethics boundaries, data rights, AI-use controls, public-safe publication, protected knowledge controls, community safeguards, public authority boundaries, sponsor and provider controls, dual-use controls, correction, and archive.

23.8.9.3 Labs-to-Foundry Conversion shall not create approval, deployment, certification, financeability, public authority decision, consent, or execution.

### 23.8.10 Marketplace Listing Quality.

23.8.10.1 Marketplace Listing Quality shall measure the completeness, accuracy, public-safe status, metadata quality, license status, support class, review status, provider-neutrality status, sponsor-boundary status, procurement-neutrality status, finance-boundary status, correction pathway, and archive status of Marketplace listings.

23.8.10.2 Marketplace Listing Quality shall include discovery usefulness without endorsement, support discovery without warranty, and handoff awareness without implementation authority.

23.8.10.3 Marketplace Listing Quality shall not create procurement status, provider validation, certification, financeability, public authority approval, deployment authorization, or execution.

### 23.8.11 Registry Status Completeness.

23.8.11.1 Registry Status Completeness shall measure whether Registry records contain accurate object identity, status, version, review state, data-use status, AI-use status, support status, provider contribution record, sponsor support record, public authority participation record where applicable, correction record, withdrawal record, recall record, archive record, and non-continuation status.

23.8.11.2 Registry Status Completeness shall support status truth, lifecycle memory, version control, support status, correction, archive, and boundary preservation.

23.8.11.3 Registry Status Completeness shall not create certification, approval, maturity certification, procurement status, financeability, insurability, public authority action, consent, deployment authorization, or execution.

### 23.8.12 Studio Workflow Closure.

23.8.12.1 Studio Workflow Closure shall measure whether Studio workflows have been completed, paused, corrected, withdrawn, archived, or routed according to their recorded scope.

23.8.12.2 Studio Workflow Closure shall include access control, role-based permissions, no-write-back rules, no-command rules, output review, logging, AI-use restrictions, data export restrictions, public-safe restrictions, shutdown triggers, correction triggers, archive rules, and routing to Reports, Registry, Marketplace, Grid, TRL, Academy, Campaigns, Foundry, Nexus Universe, National Portfolios, or Handoff Packages where appropriate.

23.8.12.3 Studio Workflow Closure shall not create deployment authorization, public authority decision, AI determination, finance approval, underwriting, certification, operational command, or execution.

### 23.8.13 Grid and TRL Evidence Completeness.

23.8.13.1 Grid and TRL Evidence Completeness shall measure whether readiness-related records include evidence sufficiency, method sufficiency, data sufficiency, AI-use sufficiency, cyber sufficiency, public-safe sufficiency, safeguard sufficiency, support sufficiency, reproducibility sufficiency, correction sufficiency, scope notes, review gates, downgrade triggers, suspension triggers, withdrawal triggers, reinstatement conditions, and public-safe notices.

23.8.13.2 Grid and TRL Evidence Completeness shall support bounded readiness memory and review routing without certification.

23.8.13.3 Grid and TRL Evidence Completeness shall not create certification, procurement readiness, financeability, insurability, public authority approval, deployment authorization, or execution.

### 23.8.14 Handoff Dependency Completeness.

23.8.14.1 Handoff Dependency Completeness shall measure whether Handoff Packages contain evidence context, data context, method context, Studio context, Grid and TRL context, public-safe status, safeguard status, public authority dependencies, legal dependencies, finance and insurance questions, procurement boundaries, provider-neutrality notes, sponsor-boundary notes, recipient responsibilities, correction pathways, recall pathways, and archive linkage.

23.8.14.2 Handoff Dependency Completeness shall support recipient diligence and lawful downstream responsibility.

23.8.14.3 Handoff Dependency Completeness shall not authorize downstream action, satisfy dependencies, approve finance, approve insurance, approve procurement, create public authority action, create consent, authorize deployment, or create execution.

### 23.8.15 Archive Integrity.

23.8.15.1 Archive Integrity shall measure whether archived records and objects preserve institutional memory accurately, including archive date, archive reason, access class, sensitivity class, public-safe status, support status, correction history, recall history, successor links where applicable, license status, retention rule, deletion or sealing rule where applicable, and archive-not-current notice.

23.8.15.2 Archive Integrity shall apply to all archived NAF outputs and shall support accountability, correction history, reproducibility, learning, non-continuation, and future review.

23.8.15.3 Archive Integrity shall not imply current validity, active support, approval, certification, procurement status, financeability, insurability, public authority decision, consent, deployment authorization, or execution.

23.8.15.4 The final Controls rule of Part XXIII is that NAF shall move only through governed records, risk-proportionate review, strict role separation, public-safe controls, safeguards, security, privacy, AI controls, cyber controls, provider controls, sponsor controls, public authority boundary controls, finance boundary controls, procurement neutrality, handoff controls, stop-the-line discipline, correctionability, and archive integrity. No NAF governance record, review, safeguard, security control, privacy label, AI label, incident response, correction, dashboard, metric, Registry status, Marketplace listing, Studio workflow, Grid input, TRL note, Report, Campaign record, National Portfolio object, Nexus Universe output, Risk Agency note, Handoff Package, archive record, or operating-intelligence measure shall become certification, public authority approval, public warning, investment advice, underwriting, procurement recommendation, provider validation, sponsor control, community consent, Indigenous consent where applicable, deployment authorization, operational command, warranty, agency, 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/xxiii.-controls.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.