# I. FOUNDATIONS

Nexus Agile Framework Foundations defines the constitutional basis of **NAF**. It explains public-good governance, non-execution, validity by record, correctionability, lawful handoff, national ownership, and the boundaries that keep Nexus work usable without creating execution authority.

This section establishes how Nexus Agile Framework work moves across research, software, data, AI, compute, reporting, portfolios, and public authority learning. It also defines the rules that prevent overclaim, role collapse, procurement distortion, finance overreach, and implied deployment.

### What this section covers

* **Core doctrine** - Defines NAF as a public-good operating framework for governed delivery.
* **Constitutional rules** - Sets non-execution, no-conversion, validity by record, and correctionability.
* **Delivery boundaries** - Explains lawful handoff, public-good firewall controls, and national-to-global coordination.

Use this section with [Nexus Agile Framework (NAF)](/organization/operations/frameworks/nexus-agile-framework-naf.md) for the full overview and [II. SYSTEMS](/organization/operations/frameworks/nexus-agile-framework-naf/ii.-systems.md) for the system map, institutions, and role separation.

## 1.1 Nexus Agile Framework Defined

### 1.1.1 NAF as the Common Operating Framework for Nexus Delivery.

1.1.1.1 The Nexus Agile Framework, referred to in this instrument as **NAF**, is the common operating framework by which Nexus work is identified, received, classified, docketed, prioritized, assigned, developed, reviewed, released, routed, corrected, archived, and, where appropriate, prepared for lawful handoff. NAF is the delivery discipline that enables Nexus to move work across institutions, countries, sectors, technologies, records, platforms, public-good mechanisms, and lawful implementation boundaries without collapsing roles or converting public-good activity into execution authority.

1.1.1.2 NAF shall operate as the connective operating framework for 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 Nodes, National Working Groups, Nexus Competence Cells, National Portfolios, public authority learning environments, capital-reader and insurance-reader rooms, and lawful handoff pathways. It shall not replace the constitutional identity, legal mandate, internal governance, professional standards, regulated obligations, or execution responsibility of any separate institution, public authority, enterprise actor, National Consortium Company, Project SPV, provider, operator, funder, insurer, sponsor, host, community, Indigenous authority, university, or lawful implementation actor.

1.1.1.3 NAF shall provide common language, records, cadence, work-status discipline, review pathways, evidence expectations, release classes, safeguard triggers, public-safe controls, correction routes, and handoff boundaries for Nexus work. It shall enable distributed contributors, national actors, technical teams, public-good institutions, public authorities, researchers, builders, communities, capital readers, insurers, sponsors, providers, and lawful handoff recipients to understand where work sits, what it may mean, what it does not mean, what records support it, what review it has received, what dependencies remain, and what boundaries apply.

### 1.1.2 NAF as Public-Good Systems-Delivery Architecture.

1.1.2.1 NAF is a public-good systems-delivery architecture. It is designed to move work not only as tasks, projects, products, or programs, but as public-good system objects that carry purpose, evidence, role boundaries, dependency records, public-safe meaning, correction pathways, national routing, and lawful handoff context.

1.1.2.2 NAF shall treat delivery as the disciplined movement of public-good work through a lifecycle of signal, intake, triage, classification, Docketing, pathway selection, evidence assembly, review, release, routing, continuation, lawful handoff preparation, correction, and archive. Delivery under NAF is not limited to software development, project management, innovation acceleration, research administration, policy drafting, training, campaign mobilization, or publication. It is the integrated operating discipline by which these functions are connected without being confused.

1.1.2.3 NAF shall support public-good systems delivery across technical, institutional, legal, social, environmental, economic, educational, resilience, infrastructure, data, AI, compute, governance, finance-readiness, and public authority learning contexts. It shall preserve the integrity of each domain while allowing work to move across them through recorded interfaces.

### 1.1.3 NAF as Risk–Innovation–Evidence–Readiness Operating Discipline.

1.1.3.1 NAF shall operate at the intersection of risk, innovation, evidence, and readiness. Every NAF pathway shall be capable of recording the risk being addressed, the innovation or capability being explored, the evidence assembled, the readiness question being tested, the safeguards required, the public-safe meaning permitted, and the handoff dependencies that remain.

1.1.3.2 NAF shall ensure that innovation does not move ahead of evidence, evidence does not become an overclaim, readiness does not become certification, public authority learning does not become public authority action, finance-readiness does not become finance, Marketplace discovery does not become procurement, Registry status does not become universal validation, and handoff context does not become execution authority.

1.1.3.3 NAF shall allow Nexus to act with speed, but only through disciplined records. It shall enable fast intake, rapid triage, parallel work, distributed contribution, open-source participation, controlled-room review, Studio demonstration, Foundry production, Campaign mobilization, Academy learning, Reports publication, Registry status, Marketplace discovery, Grid and TRL input, Universe convergence, Rails routing, and Network memory while maintaining traceability, accountability, correctionability, and legal boundary discipline.

### 1.1.4 NAF as Whole-of-Society, All-Hazards, All-Domain Delivery Architecture.

1.1.4.1 NAF shall be designed for whole-of-society participation. It shall support structured participation by public authorities, universities, research bodies, enterprises, SMEs, startups, technical providers, civil society, communities, Indigenous actors where applicable, youth, students, workers, volunteers, experts, professional communities, donors, foundations, banks, insurers, reinsurers, public finance readers, media actors, sponsors, hosts, and lawful implementation actors.

1.1.4.2 NAF shall be all-hazards in scope. It shall be capable of supporting work relating to climate hazards, geophysical hazards, biological hazards, technological hazards, cyber hazards, infrastructure failures, supply-chain disruptions, conflict-sensitive conditions, environmental degradation, biodiversity loss, food insecurity, water insecurity, energy insecurity, public health stress, cascading systems risk, financial protection gaps, data and AI harms, cyber-physical vulnerabilities, and frontier-technology risks.

1.1.4.3 NAF shall be all-domain in operation. It shall support work across policy, science, technology, law, finance-readiness, insurance-readiness, infrastructure, social systems, community safeguards, public authority learning, digital public goods, workforce capability, open-source contribution, secure data workflows, standards interfaces, public-safe reporting, and lawful implementation pathways. It shall not reduce whole-of-society delivery to stakeholder consultation, public relations, volunteer mobilization, or technical production alone.

### 1.1.5 NAF as National-to-Global Coordination Architecture.

1.1.5.1 NAF shall provide a national-to-global coordination architecture. It shall allow country-level priorities, national systems-risk maps, National Portfolio objects, National Working Group outputs, Nexus Competence Cell work, public authority learning records, community safeguard records, national data and language conditions, and lawful national handoff pathways to connect with regional clusters, global Nexus priorities, Nexus Universe arenas, Nexus Core Build, Nexus Observatory, Nexus Rails, Nexus Network, and cross-border knowledge exchange.

1.1.5.2 NAF shall preserve national ownership before local delivery. Global and regional activity under NAF shall support, translate, route, and strengthen national capability; it shall not bypass national stakeholders, override national public authority, displace national institutions, extract national knowledge, impose unrecorded implementation priorities, or create execution authority by international visibility.

1.1.5.3 NAF shall support regional and global interoperability while preserving local context. It shall enable common records, controlled vocabularies, Docket structures, evidence classes, public-safe summaries, Registry fields, Marketplace metadata, Studio workflow records, Grid and TRL notes, Reports packages, and handoff dependency templates while permitting lawful localization, translation, safeguard adaptation, data sovereignty, public authority boundary variation, and national implementation routing.

### 1.1.6 NAF as Exponential-Technology R\&D, Production, Readiness, and Lawful Handoff Framework.

1.1.6.1 NAF shall govern the movement of exponential-technology work from research signals to public-good outputs, from evidence gaps to build objects, from prototypes to bounded readiness records, and from public-good preparation to lawful handoff context. It shall apply to AI and agentic systems, AI-RAN, O-RAN, private wireless, telecom, edge systems, cloud, HPC, sovereign compute, verifiable compute, cybersecurity, geospatial systems, Earth observation, digital twins, drones, robotics, IoT, OT, IIoT, DLT, DePIN, Web3, digital identity, quantum-relevant security, semiconductors, advanced manufacturing, biosecurity-sensitive systems, frontier science infrastructure, and related mission-critical technologies.

1.1.6.2 NAF shall not treat research, demonstration, prototyping, publication, repository release, dashboard display, AI workflow output, Studio runtime, Grid input, TRL note, Registry status, Marketplace listing, Nexus Universe presentation, or handoff package as deployment authorization. Each such output shall be understood according to its recorded scope, review status, evidence basis, public-safe class, support class, boundary notice, and correction pathway.

1.1.6.3 NAF shall enable lawful handoff where work is sufficiently recorded, reviewed, bounded, and routed. Handoff under NAF shall transfer context, evidence, dependencies, assumptions, limitations, safeguard conditions, public authority dependencies, finance and insurance questions, provider-neutrality notes, procurement boundaries, and correction pathways. It shall not transfer authority, impose implementation, select a supplier, approve a project, allocate capital, issue insurance, grant consent, certify compliance, or execute work.

### 1.1.7 NAF as Standards-Aware, Open-Source-Capable, Enterprise-Grade Public-Good Operating Architecture.

1.1.7.1 NAF shall be standards-aware without becoming a standards authority. It shall support standards mapping, interoperability profiles, protocol objects, conformance-question records, testing profiles, data-exchange formats, evidence schemas, API contracts, model and system cards, benchmark cards, cybersecurity records, privacy and data governance records, disaster-risk and climate-service interface records, telecom and network dependency records, open-source governance records, and innovation-management interface records.

1.1.7.2 NAF shall be open-source-capable. It shall support repositories, maintainers, contributors, forks, releases, issues, pull requests, SBOM records, dependency records, security disclosure channels, licensing, attribution, documentation, reproducibility packages, public-good software objects, open technical baselines, reference implementations, APIs, SDKs, connectors, adapters, notebooks, dashboards, and public-safe technical summaries. Open-source participation shall not create warranty, support obligation, procurement status, certification, employment, agency, provider validation, or deployment authorization unless separately and lawfully recorded.

1.1.7.3 NAF shall be enterprise-grade without becoming an enterprise execution framework by default. It shall produce records and packages that enterprises, public authorities, funders, insurers, providers, National Consortium Companies, Project SPVs, and lawful implementation actors can read, evaluate, diligence, and use within their own competent processes. Enterprise legibility under NAF shall not create enterprise control over public-good priorities, sponsor control over routing, provider validation, investor reliance, procurement preference, or regulated financial activity.

### 1.1.8 NAF as Movement Without Execution by Implication.

1.1.8.1 NAF exists to move work safely, visibly, and lawfully through the Nexus Ecosystem without creating execution by implication. It enables work to progress from idea to record, record to Docket, Docket to pathway, pathway to evidence, evidence to review, review to release, release to routing, routing to public-safe knowledge, public-safe knowledge to readiness context, readiness context to National Portfolio memory, National Portfolio memory to Nexus Universe convergence, and Nexus Universe output to lawful handoff preparation.

1.1.8.2 No movement within NAF shall be interpreted as project execution, public authority decision, procurement award, finance approval, insurance underwriting, certification, regulatory clearance, public warning, emergency command, community consent, Indigenous consent, employment relationship, professional licensing, standards conformance, provider validation, investment recommendation, or deployment authorization unless such effect is separately granted by a competent actor through a lawful, recorded process outside the default effect of NAF.

1.1.8.3 NAF shall therefore be both enabling and restraining. It enables speed, scale, coordination, learning, contribution, production, visibility, and handoff preparation; it restrains overclaim, role collapse, premature deployment, extractive participation, sponsor capture, provider capture, public authority substitution, finance boundary breach, procurement distortion, data misuse, AI misuse, safeguard bypass, and uncorrected error.

## 1.2 Foundational Thesis

### 1.2.1 From Projects to Public-Good Systems Movement.

1.2.1.1 NAF begins from the premise that Nexus work cannot be governed adequately as isolated projects. Nexus work concerns public-good capability formation, systems risk, frontier technologies, national resilience, public authority learning, finance-readiness, open technical baselines, data and AI governance, public-safe reporting, community safeguards, and lawful handoff. Such work must move as a recorded public-good system, not as disconnected deliverables.

1.2.1.2 A project may end when a defined output is delivered. NAF work does not end merely because a document, code release, dashboard, report, learning object, campaign, model, dataset, Studio workflow, or handoff package is produced. Each output remains part of a living record architecture that may require review, correction, supersession, downgrade, withdrawal, recall, archive, translation, localization, controlled access, continuation, or lawful handoff.

1.2.1.3 Public-good systems movement under NAF shall therefore include direction, records, cadence, accountability, evidence, safeguards, release classes, boundary notices, routing, and correction. The purpose is not only to complete work, but to make the work usable, trustworthy, bounded, interpretable, reusable, and safely movable across Nexus contexts.

### 1.2.2 From Product Backlogs to Public-Good Dockets.

1.2.2.1 NAF replaces narrow backlog logic with public-good Docket discipline. A backlog may record work to be done; a Docket records why the work exists, where it came from, what risk or opportunity it addresses, what evidence is needed, what institutions are implicated, what boundaries apply, what safeguards are required, what review is necessary, what release class may be permitted, and what correction pathway must remain available.

1.2.2.2 Dockets shall be the record-bearing work containers of NAF. They may hold signals, evidence needs, research questions, challenge briefs, public authority learning questions, National Portfolio needs, Campaign objects, Foundry quests, bounty scopes, build objects, Reports candidates, Studio workflows, Grid inputs, TRL notes, Registry updates, Marketplace listings, handoff packages, correction actions, and archive records.

1.2.2.3 Docket discipline shall prevent informal momentum from becoming authority. A Docket item may move, mature, receive review, produce outputs, and become visible, but it shall not generate certification, procurement, finance, insurance, public authority approval, consent, deployment, warning, command, or execution by implication.

### 1.2.3 From Technical Outputs to Evidence-Bearing Institutional Meaning.

1.2.3.1 NAF shall treat technical outputs as insufficient unless they are accompanied by institutional meaning. Code, data, models, dashboards, reports, simulations, digital twins, APIs, methods, learning objects, credentials, campaign materials, and handoff packages shall be recorded with purpose, scope, source class, evidence basis, review status, data-use label, AI-use label, public-safe status, safeguard status, support class, boundary notices, dependencies, and correction rules.

1.2.3.2 Technical excellence under NAF shall include not only performance, functionality, security, usability, interoperability, documentation, and maintainability, but also traceability, public-safe interpretability, role separation, lifecycle status, correctionability, and lawful routing. A technically impressive output that cannot be safely interpreted, corrected, governed, or lawfully handed off shall not be treated as mature within NAF merely because it functions.

1.2.3.3 Evidence-bearing institutional meaning shall allow different actors to understand the same output without overclaim. Public authorities may read it for learning; researchers may read it for evidence; builders may read it for technical continuation; communities may read it for public-safe meaning; capital readers may read it for diligence questions; insurers may read it for risk questions; National Portfolios may read it for capability formation; lawful recipients may read it for dependencies. None of those readings shall create authority beyond the recorded scope.

### 1.2.4 From Speed Alone to Evidence Velocity, Learning Velocity, Correction Velocity, and Safe Capability Formation.

1.2.4.1 NAF shall not measure success by speed alone. Speed without evidence can produce error; speed without safeguards can produce harm; speed without records can produce confusion; speed without correction can produce institutional distrust; speed without role separation can produce unlawful overclaim.

1.2.4.2 NAF shall therefore recognize evidence velocity, learning velocity, correction velocity, and safe capability formation as core movement concepts. Evidence velocity concerns the rate at which useful, reviewable, bounded evidence is produced. Learning velocity concerns the rate at which participants, institutions, public authorities, communities, and lawful actors gain recorded capability or understanding. Correction velocity concerns the rate at which errors, overclaims, outdated materials, boundary incidents, and unsafe outputs are identified, contained, corrected, superseded, withdrawn, recalled, or archived. Safe capability formation concerns the ability of Nexus to build usable capacity while preserving public-good discipline.

1.2.4.3 The highest NAF performance is not uncontrolled acceleration. It is fast, disciplined, evidence-bearing, standards-aware, nationally grounded, safeguard-conscious, publicly safe, correctionable, and lawfully bounded movement.

### 1.2.5 From Deployment Claims to Lawful Handoff Context.

1.2.5.1 NAF shall distinguish deployment from lawful handoff context. Deployment is an act of implementation by a competent actor within an applicable legal, operational, procurement, regulatory, technical, financial, community, or institutional process. NAF does not deploy by default. NAF prepares context that may assist lawful actors in deciding what to do through their own authority.

1.2.5.2 A lawful handoff package under NAF may include evidence context, method notes, data status, AI-use labels, Studio demonstration records, Grid inputs, TRL notes, public-safe summaries, safeguard records, public authority dependencies, finance and insurance questions, procurement-neutrality notices, provider-neutrality notes, sponsor-boundary notes, assumptions, limitations, risks, support class, correction pathway, and archive rules. It shall not by itself authorize execution.

1.2.5.3 NAF shall therefore shift institutional language from “ready to deploy” to “handoff-context-ready within recorded scope,” from “approved” to “reviewed within recorded scope,” from “validated” to “evidence-bearing within recorded scope,” from “bankable” to “finance-readiness questions recorded,” from “insurable” to “insurance-readiness questions recorded,” and from “endorsed” to “public-safe status or Registry status recorded where applicable.”

### 1.2.6 From Isolated Innovation to Governed Public-Good R\&D Pipelines.

1.2.6.1 NAF shall treat innovation as a governed public-good pipeline rather than a series of isolated experiments. Research questions, evidence gaps, testbeds, prototypes, models, datasets, simulations, public-good software, open technical baselines, and Studio workflows shall be connected through Dockets, records, review gates, release classes, Registry status, Marketplace discovery, Reports publication, Grid inputs, TRL notes, Nexus Universe pathways, and lawful handoff context.

1.2.6.2 Governed public-good R\&D under NAF shall permit creativity, experimentation, and frontier work while requiring records, evidence, review, safeguards, data governance, AI controls, cybersecurity controls, public-safe publication discipline, protected knowledge controls, dual-use sensitivity review, and correction pathways. It shall enable ambition without treating early research, prototype demonstrations, or public visibility as implementation authority.

1.2.6.3 NAF shall allow R\&D outputs to remain useful even when they are not continued. Non-continuation, withdrawal, supersession, archive, or correction shall not be treated as failure where they preserve trust, prevent overclaim, clarify limitations, or improve future learning.

### 1.2.7 From Enterprise Delivery to National, Regional, and Global Capability Formation.

1.2.7.1 NAF shall extend beyond enterprise delivery. It shall support national capability formation, regional coordination, global knowledge exchange, public authority learning, public-good infrastructure, workforce and competence formation, technical evidence, risk intelligence, finance-readiness, and lawful enterprise handoff.

1.2.7.2 National capability formation under NAF shall include National Portfolio records, national systems-risk maps, National Working Group outputs, Nexus Competence Cell workplans, public authority learning records, national data and safeguard conditions, language and localization records, infrastructure and compute dependencies, WFEH-B priorities, DRR/DRF/DRI priorities, frontier-technology readiness questions, and lawful handoff pathways.

1.2.7.3 Regional and global capability formation shall support national ownership rather than replace it. NAF shall enable cross-country learning, standards-aware interoperability, regional cluster intelligence, global Nexus Universe convergence, shared public-good software, open technical baselines, Reports publication, Marketplace discovery, Registry status truth, and Network memory while preserving national routing and lawful boundaries.

### 1.2.8 From Acceleration to Disciplined Readiness, Review, Release, Routing, and Correction.

1.2.8.1 NAF shall not equate acceleration with success. Acceleration without readiness, review, release discipline, routing, and correction can produce unsafe claims, unreviewed outputs, public authority confusion, procurement distortion, data misuse, AI misuse, sponsor capture, provider overclaim, community harm, or unlawful reliance.

1.2.8.2 NAF shall define disciplined movement through five linked operating requirements: readiness, review, release, routing, and correction. Readiness determines whether work is sufficiently scoped for the next stage. Review determines whether evidence, safeguards, data, AI, cyber, public-safe, finance, procurement, public authority, and handoff concerns have been considered. Release determines how and to whom an output may be made available. Routing determines where the output moves next. Correction determines how the system responds when the record changes, the output is wrong, the context shifts, or a boundary is breached.

1.2.8.3 NAF shall therefore permit rapid work only when work remains legible, bounded, reviewable, correctable, and lawfully routed. The framework’s purpose is not to slow Nexus; it is to allow Nexus to move at scale without losing trust.

## 1.3 NAF Operating Formula

### 1.3.1 Signals Become Records.

1.3.1.1 NAF shall begin with signals. Signals may arise from risks, hazards, public authority questions, community concerns, data patterns, Observatory inputs, research findings, Campaign mobilization, National Portfolio needs, Nexus Universe priorities, frontier-technology developments, infrastructure gaps, workforce capability needs, finance-readiness questions, insurance-readiness questions, standards-interface issues, public-safe reporting needs, or correction triggers.

1.3.1.2 No signal shall be treated as actionable truth merely because it is received. Each signal shall be converted into an appropriate record with source class, confidence level where applicable, uncertainty where applicable, sensitivity class, public-safe status, initial routing, boundary notices, and review needs. Signals that are sensitive, protected, public authority-sensitive, cyber-sensitive, geospatial-sensitive, community-sensitive, Indigenous protocol-sensitive, health-sensitive, youth-related, or finance/procurement-sensitive shall be handled under heightened controls.

### 1.3.2 Records Become Docket Items.

1.3.2.1 Records that require work, review, learning, research, mobilization, build activity, reporting, Studio demonstration, Grid input, Registry action, Marketplace listing, Universe routing, handoff preparation, correction, or archive shall become Docket items. Docketing shall transform a record from passive information into governed work.

1.3.2.2 A Docket item shall record purpose, scope, source, owner or steward, pathway, dependencies, assumptions, risks, safeguards, data and AI labels, public-safe requirements, review gates, release class, routing expectations, correction pathway, and archive rule. Docketing shall not create authority; it shall create traceable responsibility for work movement.

### 1.3.3 Docket Items Become Learning, Research, Campaigns, Quests, Bounties, Builds, Reports, Studio Workflows, Grid Inputs, and TRL Notes.

1.3.3.1 Docket items shall be routed to appropriate NAF pathways. A Docket item may become a learning object, Academy module, Risk Academy pathway, research question, Labs stream, Campaign object, Foundry quest, bounty, build, data task, software task, model review, public-safe report, Studio workflow, Marketplace object, Registry record, Grid input, TRL evidence note, Nexus Universe arena item, or handoff dependency package.

1.3.3.2 Pathway selection shall depend on the purpose of the work, evidence available, review needs, national routing, public authority context, data and AI status, safeguard conditions, technical maturity, public-safe classification, and lawful handoff relevance. A Docket item may move through multiple pathways, but each pathway shall preserve record continuity.

### 1.3.4 Work Becomes Evidence.

1.3.4.1 Work under NAF shall produce evidence. Evidence may include research findings, method notes, datasets, code, model cards, system cards, benchmark cards, dashboard records, simulation results, Studio workflow logs, public authority learning records, Campaign records, learning records, review notes, safeguard records, public-safe summaries, Reports drafts, Registry status records, Marketplace metadata, Grid inputs, TRL notes, or handoff dependency records.

1.3.4.2 Evidence shall be bounded by scope. Evidence produced for one context shall not be silently generalized to another context. Evidence shall record its assumptions, limitations, source constraints, data constraints, model constraints, review level, uncertainty, confidence where applicable, support class, public-safe class, and correction pathway.

### 1.3.5 Evidence Becomes Public-Safe Knowledge, Registry Status, Marketplace Discovery, Grid Input, TRL Context, and National Portfolio Memory.

1.3.5.1 Evidence that has been reviewed and classified may be transformed into public-safe knowledge, controlled knowledge, Registry status, Marketplace discovery metadata, Grid input, TRL context, Reports publication, National Portfolio memory, or handoff context. Each transformation shall preserve the distinction between evidence, interpretation, readiness, status, discovery, and authority.

1.3.5.2 Public-safe knowledge shall be prepared in a manner that avoids public warning overclaim, public authority overclaim, finance or procurement overclaim, certification overclaim, consent overclaim, provider validation, sponsor control, protected knowledge exposure, sensitive location disclosure, data misuse, AI misuse, or implementation instruction beyond scope.

1.3.5.3 Registry status shall preserve status truth. Marketplace discovery shall support finding and reuse. Grid inputs and TRL notes shall support bounded readiness memory. National Portfolio memory shall support national capability formation. None of these outputs shall create certification, procurement, financeability, insurability, public authority approval, consent, or deployment authorization by default.

### 1.3.6 National Portfolio Memory Becomes Nexus Universe Readiness.

1.3.6.1 National Portfolio memory shall support Nexus Universe readiness by organizing country-level priorities, evidence records, public authority learning questions, Campaign outputs, Working Group outputs, Competence Cell work, DRI and Observatory inputs, WFEH-B needs, technology-readiness questions, safeguard conditions, finance-readiness questions, and lawful handoff dependencies.

1.3.6.2 Nexus Universe readiness shall not mean readiness to implement. It shall mean readiness to participate in an annual public-good systems-build environment with appropriate records, scopes, boundaries, safeguards, review needs, public-safe summaries, and continuation pathways.

### 1.3.7 Nexus Universe Outputs Become Continuation Pathways.

1.3.7.1 Nexus Universe outputs shall become continuation pathways through recorded post-cycle routing. Such outputs may include arena records, participation records, Core Build records, Studio outputs, Foundry continuation records, public authority learning records, readiness question records, Marketplace listings, Registry updates, Reports, Campaign updates, National Portfolio updates, handoff dependency notes, correction records, and archive records.

1.3.7.2 A continuation pathway may lead to Academy learning, Risk Academy literacy, Labs research, Foundry production, Campaign mobilization, Reports publication, Registry update, Marketplace listing, Studio workflow, Grid review, TRL note, National Portfolio continuation, public authority learning follow-up, capital-reader or insurance-reader review, lawful handoff preparation, correction, or archive.

### 1.3.8 Continuation Pathways Become Lawful Handoff Context.

1.3.8.1 Where a continuation pathway identifies a lawful implementation possibility, NAF may support preparation of a handoff context. Handoff context shall be prepared only with recorded evidence, assumptions, limitations, dependencies, review status, public-safe status, safeguard status, data and AI status, public authority dependencies, finance and insurance questions, procurement boundaries, provider-neutrality notes, sponsor-boundary notes, recipient responsibilities, correction pathways, and archive rules.

1.3.8.2 Handoff context shall remain a bridge, not an act of execution. It shall assist lawful recipients in their own diligence, approval, procurement, financing, insurance, regulatory, community, technical, or operational processes without substituting for those processes.

### 1.3.9 Lawful Handoff Transfers Dependencies, Not Authority.

1.3.9.1 Lawful handoff under NAF transfers dependencies, not authority. A handoff package may explain what is known, what is unknown, what was reviewed, what was not reviewed, what conditions apply, what risks remain, what safeguards are required, what public authority actions may be needed, what finance or insurance questions remain, what procurement boundaries apply, and what correction pathways must be preserved.

1.3.9.2 Handoff shall not approve the recipient, validate the provider, endorse the sponsor, finance the project, insure the risk, allocate public finance, issue a permit, grant consent, authorize deployment, certify compliance, or command implementation. The recipient shall remain responsible for all lawful execution decisions within its own authority and obligations.

### 1.3.10 Correction Preserves Trust.

1.3.10.1 Correction is not an exception to NAF; it is a core operating function. NAF shall preserve trust by allowing records, outputs, statuses, reports, listings, evidence notes, Studio workflows, Grid inputs, TRL notes, public-safe summaries, and handoff packages to be corrected, supplemented, superseded, downgraded, suspended, withdrawn, recalled, retracted where necessary, archived, or marked non-continuing.

1.3.10.2 Correction shall propagate where required. Where an error, overclaim, incident, safeguard issue, data issue, AI issue, cyber issue, public authority boundary issue, finance boundary issue, procurement boundary issue, provider validation issue, sponsor control issue, consent overclaim, handoff overclaim, or execution overclaim affects downstream records, NAF shall support claims freeze, data freeze, technical freeze, Marketplace delisting, Registry status update, public-safe notice, handoff recall, archive, reinstatement where appropriate, and public repair.

## 1.4 Public-Good Constitutional Principles

### 1.4.1 Non-Execution.

1.4.1.1 NAF shall be governed by the principle of non-execution. NAF may support learning, evidence, research, production of public-good outputs, mobilization, reporting, discovery, status truth, controlled demonstrations, readiness records, public authority learning, finance-readiness questions, insurance-readiness questions, and lawful handoff context, but it shall not execute projects by default.

1.4.1.2 Non-execution shall mean that NAF does not, by its own operation, construct, deploy, operate, procure, finance, insure, regulate, approve, permit, command, or deliver implementation works. Execution shall occur only through competent public authorities, enterprises, National Consortium Companies, Project SPVs, providers, operators, funders, insurers, procurement bodies, communities, or other lawful actors acting through their own authority and recorded processes.

### 1.4.2 Validity by Record.

1.4.2.1 NAF shall recognize validity by record. A claim, status, output, pathway, review, release, readiness note, Registry entry, Marketplace listing, Studio workflow, Grid input, TRL note, public-safe report, or handoff package shall have meaning only to the extent supported by a record.

1.4.2.2 Unrecorded claims shall not create NAF validity. Informal statements, public visibility, participation, attendance, sponsorship, provider contribution, media coverage, technical demonstration, publication, or stakeholder enthusiasm shall not substitute for recorded scope, evidence, review, status, release class, boundary notice, and correction pathway.

### 1.4.3 Correctionability.

1.4.3.1 NAF shall be correctionable by design. All material NAF outputs shall carry a correction pathway, including records, Docket items, evidence packs, Reports, Registry records, Marketplace listings, Studio workflows, Grid inputs, TRL notes, National Portfolio objects, Nexus Universe outputs, Campaign records, learning records, and handoff packages.

1.4.3.2 Correctionability shall include the ability to correct, amend, supplement, supersede, downgrade, suspend, withdraw, recall, retract where necessary, archive, mark non-continuing, and issue public-safe correction notices where appropriate. Correction shall be treated as a trust-preserving act, not as institutional weakness.

### 1.4.4 Public-Good Firewall.

1.4.4.1 NAF shall preserve the public-good firewall between public-good work and private, commercial, political, sponsor, provider, capital, procurement, or execution interests. Public-good resources, records, participation surfaces, research outputs, data, software, Reports, Dockets, Studio workflows, Registry records, Marketplace listings, Grid inputs, and Nexus Universe outputs shall not be captured or redirected for improper private control.

1.4.4.2 The public-good firewall shall not prevent lawful enterprise handoff. It shall ensure that any handoff is recorded, neutral, bounded, dependency-based, recipient-responsibility-based, and separated from improper endorsement, procurement preference, investment solicitation, sponsor control, provider validation, or execution by implication.

### 1.4.5 No-Conversion.

1.4.5.1 NAF shall apply a no-conversion rule. No NAF participation, record, output, review, release, status, listing, report, demonstration, readiness note, metric, Docket item, campaign, public authority learning record, Nexus Universe output, or handoff package shall convert into legal authority, public authority action, certification, procurement status, financeability, insurability, community consent, Indigenous consent, deployment authorization, professional license, employment status, endorsement, or execution unless separately and lawfully recorded by a competent actor.

1.4.5.2 The no-conversion rule shall apply regardless of visibility, seniority, sponsorship, funding, institutional participation, public authority presence, media attention, technical sophistication, or market interest.

### 1.4.6 National Ownership Before Local Delivery.

1.4.6.1 NAF shall preserve national ownership before local delivery. Country-level Nexus work shall be shaped, localized, recorded, safeguarded, reviewed, and routed through appropriate national pathways, including National Nexus Consortiums, National Councils, National Working Groups, Nexus Competence Cells, National Nodes, National Portfolios, public authority learning processes, and lawful national handoff pathways where applicable.

1.4.6.2 External, global, regional, sponsor, provider, capital, media, or technical actors shall not bypass national routing. Support may be offered; capability may be contributed; evidence may be shared; standards interfaces may be mapped; public-good software may be developed; but national context shall not be displaced by external acceleration.

### 1.4.7 Public Authority Learning Without Substitution.

1.4.7.1 NAF shall support public authority learning without substituting for public authority action. Public authorities may participate in learning rooms, review evidence, identify questions, observe demonstrations, engage with DRI and Observatory outputs, participate in Nexus Universe arenas, read Reports, consult Registry status, view Marketplace listings, and receive handoff context. Such participation shall not by itself constitute public authority approval, policy adoption, permit issuance, procurement decision, public finance allocation, public warning, emergency command, regulatory position, or official act.

1.4.7.2 NAF shall record public authority dependencies where official action may be required. It shall not assume, imply, or represent such action.

### 1.4.8 Finance-Readiness Without Finance.

1.4.8.1 NAF may support finance-readiness, capital-readability, insurance-readiness, donor-readiness, public finance relevance, diligence-gap identification, assumptions registers, dependency registers, and no-reliance rooms. It shall not conduct regulated financial activity by default.

1.4.8.2 Finance-readiness under NAF shall not mean investment advice, securities offering, capital commitment, lending, underwriting, insurance approval, guarantee, rating, bankability, financeability, donor commitment, public finance allocation, or transaction execution. Finance-readiness shall mean that relevant questions, dependencies, assumptions, evidence gaps, and diligence needs are recorded for competent actors to evaluate independently.

### 1.4.9 Procurement Neutrality.

1.4.9.1 NAF shall preserve procurement neutrality. It shall not recommend vendors, select suppliers, approve providers, create tender status, validate contractors, prefer sponsors, rank bidders, or substitute for procurement processes.

1.4.9.2 Marketplace listings, Registry records, public-good software releases, provider contributions, Studio demonstrations, Reports, Grid inputs, TRL notes, Nexus Universe presentations, and handoff packages shall not be interpreted as procurement recommendation or supplier approval. Independent diligence and lawful procurement processes remain required where procurement is relevant.

### 1.4.10 Sponsor Support Without Control.

1.4.10.1 NAF may allow sponsor support where lawful, transparent, recorded, bounded, and non-controlling. Sponsor support may assist public-good work, events, repositories, campaigns, learning, reports, rooms, infrastructure, or participation, but shall not control Docket priorities, evidence outcomes, review decisions, release status, Registry entries, Marketplace placement, public authority learning, finance-readiness rooms, handoff routing, or public-safe narratives.

1.4.10.2 Sponsor acknowledgment shall not imply endorsement, ownership, validation, procurement preference, finance commitment, public authority approval, or execution authority.

### 1.4.11 Provider Contribution Without Validation.

1.4.11.1 NAF may receive provider contributions, including technical expertise, software, infrastructure support, data tools, cloud resources, compute resources, standards knowledge, demonstrations, documentation, or subject-matter input. Such contribution shall not validate the provider or its products.

1.4.11.2 Provider participation, contribution, listing, demonstration, or support shall not create certification, procurement advantage, supplier approval, public authority approval, investment signal, insurance approval, or handoff preference. Provider contributions shall be subject to conflict controls, provider-neutrality review, public-good firewall discipline, and correction.

### 1.4.12 Participation Without Consent by Implication.

1.4.12.1 Participation in NAF shall not imply consent. Community participation, Indigenous participation, youth participation, civil society participation, public authority participation, national stakeholder participation, sponsor participation, provider participation, or capital-reader participation shall not be represented as approval, endorsement, authorization, or consent unless separately and lawfully recorded.

1.4.12.2 Community and Indigenous consent, where relevant, shall require appropriate lawful and protocol-respecting processes outside mere NAF participation. NAF shall record consent boundaries and shall prevent public-safe reporting, Campaign materials, Reports, Marketplace listings, Registry entries, Studio demonstrations, Nexus Universe outputs, or handoff packages from overstating participation as consent.

### 1.4.13 Open Where Safe, Controlled Where Necessary.

1.4.13.1 NAF shall support openness where safe. Public-good software, public-safe data, learning objects, public-safe Reports, open technical baselines, schemas, APIs, documentation, challenge briefs, and reusable methods should be made open where doing so advances public-good capability and does not violate privacy, security, protected knowledge, data sovereignty, public authority sensitivity, community safeguards, Indigenous protocols, cyber safety, health sensitivity, geospatial sensitivity, dual-use controls, contractual limits, or lawful restrictions.

1.4.13.2 NAF shall require controlled access where necessary. Restricted data, sensitive infrastructure information, protected knowledge, cyber-sensitive materials, public authority-sensitive materials, health-sensitive data, youth data, community-sensitive data, Indigenous protocol-sensitive knowledge, finance-sensitive information, and handoff-recipient-only materials shall be handled through appropriate secure rooms, data rooms, clean rooms, protected knowledge rooms, compute-to-data environments, access controls, output review, and archive rules.

### 1.4.14 Standards-Aware Without Standards-Authority Overclaim.

1.4.14.1 NAF shall be standards-aware. It shall support standards mapping, protocol interfaces, conformance-question records, testing profiles, interoperability notes, evidence schemas, data-exchange formats, AI governance records, cybersecurity records, disaster-risk and climate-service interface records, telecom and compute interface records, open-source governance records, and innovation-management references where relevant.

1.4.14.2 NAF shall not claim standards authority by default. Mapping to a standard, referencing a standard, testing against a profile, preparing a conformance question, or recording standards relevance shall not constitute certification, accreditation, legal compliance, standards adoption, regulatory approval, or formal conformance unless separately determined by a competent standards, regulatory, certification, or public authority body.

## 1.5 NAF Domain Scope

### 1.5.1 WFEH-B Systems.

1.5.1.1 NAF shall apply to water, food, energy, health, biodiversity, and nature systems, including their infrastructure, data, supply chains, governance dependencies, community impacts, climate sensitivities, technology needs, risk intelligence requirements, public authority learning questions, finance-readiness questions, and lawful handoff pathways.

1.5.1.2 WFEH-B work under NAF shall be treated as interconnected systems work. Water stress may affect food security, energy reliability, health outcomes, biodiversity, conflict risk, migration, supply chains, and public finance needs. Food systems may depend on water, energy, soil, biodiversity, data, logistics, insurance, and infrastructure. Energy systems may affect water, health, industry, telecommunications, compute, and emergency response. Health systems may depend on climate resilience, data governance, logistics, public trust, digital infrastructure, and biosecurity. Biodiversity and nature systems may affect water cycles, food systems, health resilience, livelihoods, climate adaptation, and protected knowledge.

### 1.5.2 DRR, DRF, DRI, and Disaster-Resilience Systems.

1.5.2.1 NAF shall apply to Disaster Risk Reduction, Disaster Risk Finance, Disaster Risk Intelligence, and disaster-resilience systems. It shall support risk understanding, exposure and vulnerability records, resilience-capacity questions, risk-layering questions, protection-gap questions, public authority learning, insurance-readiness questions, donor-readiness questions, public finance relevance, public-safe reporting, Observatory signals, DRI indicators, Studio scenarios, and lawful handoff context.

1.5.2.2 NAF shall support disaster-risk work without becoming a warning authority, emergency command body, insurer, reinsurer, public finance allocator, regulator, procurement authority, or disaster-response operator by default. Disaster-resilience outputs shall be bounded by their records and routed to competent actors where action is required.

### 1.5.3 Climate, Nature, Biodiversity, Infrastructure, Public Health, Food, Water, Energy, Cyber-Physical Resilience, and Supply Chains.

1.5.3.1 NAF shall apply to climate adaptation, mitigation-relevant learning, nature and biodiversity resilience, infrastructure resilience, public health resilience, food systems resilience, water security, energy security, cyber-physical systems, critical infrastructure, logistics, supply chains, and cascading risk.

1.5.3.2 Work in these domains shall be capable of moving through NAF as research questions, data objects, model objects, Studio scenarios, DRI indicators, Observatory signals, public-safe Reports, National Portfolio items, Campaign objects, Foundry builds, Marketplace listings, Registry records, Grid inputs, TRL notes, Nexus Universe outputs, and lawful handoff dependency packages.

### 1.5.4 Exponential and Mission-Critical Technology Domains.

1.5.4.1 NAF shall apply to AI, agentic systems, AI-RAN, O-RAN, telecom, private wireless, edge, HPC, sovereign compute, cloud, cybersecurity, geospatial, Earth observation, digital twins, drones, robotics, sensors, IoT, OT, IIoT, DLT, DePIN, Web3, quantum-relevant security, semiconductors, advanced manufacturing, biosecurity-sensitive systems, and frontier science infrastructure.

1.5.4.2 NAF shall require technology-specific controls where appropriate, including AI-use labels, model cards, system cards, benchmark cards, agent workflow cards, tool-permission records, prompt-injection controls, human oversight records, SBOM records, secure software controls, data lineage, compute-to-data records, secure enclave records, spectrum dependency notes, geospatial sensitivity controls, protected location masking, dual-use review, export-control sensitivity notes, and public-safe publication review.

### 1.5.5 Public Authority Learning and Public-Good Policy Intelligence.

1.5.5.1 NAF shall support public authority learning and public-good policy intelligence by creating controlled settings where public authorities and relevant stakeholders may observe, question, learn, review, and understand risks, technologies, evidence, scenarios, policy options, resilience needs, readiness dependencies, and handoff conditions.

1.5.5.2 Public-good policy intelligence shall be evidence-bearing, public-safe, non-partisan, role-separated, correctionable, and bounded. It shall not substitute for legislation, regulation, procurement, public finance, permitting, licensing, public warning, emergency command, or official policy decision.

### 1.5.6 National Portfolio Formation.

1.5.6.1 NAF shall support National Portfolio formation by structuring country-level priorities, risks, needs, capabilities, evidence gaps, learning pathways, Working Group outputs, Competence Cell workplans, Campaign outputs, Observatory needs, DRI indicators, public authority learning records, technology-readiness questions, safeguard conditions, finance-readiness questions, and lawful handoff dependencies.

1.5.6.2 National Portfolio formation shall be nationally routed, public-good disciplined, stakeholder-informed, safeguard-aware, and correctionable. It shall not constitute country ranking, public authority approval, investment pipeline, procurement plan, or implementation authorization by default.

### 1.5.7 Public-Good Software and Open Technical Baselines.

1.5.7.1 NAF shall support public-good software and open technical baselines as reusable capability infrastructure. This may include reference implementations, repositories, APIs, SDKs, connectors, dashboards, notebooks, data pipelines, schemas, ontologies, model cards, system cards, benchmark cards, documentation, learning materials, and reproducibility packages.

1.5.7.2 Public-good software and open technical baselines shall be governed through repository stewardship, maintainer roles, contributor records, licensing, attribution, security review, dependency tracking, SBOM records, support classes, release classes, public-safe documentation, correction, deprecation, withdrawal, and archive. Release shall not imply warranty, production approval, procurement preference, certification, or deployment authorization.

### 1.5.8 Lawful Enterprise Handoff Pathways.

1.5.8.1 NAF shall support lawful enterprise handoff pathways where public-good outputs, evidence, technical baselines, software, data, Studio workflows, Reports, Grid inputs, TRL notes, National Portfolio objects, or Nexus Universe outputs may be relevant to lawful implementation actors.

1.5.8.2 Lawful enterprise handoff shall remain distinct from public-good work. National Consortium Companies, Project SPVs, providers, operators, contractors, funders, insurers, donors, public authorities, universities, community actors, and other lawful recipients may receive handoff context, but they shall remain responsible for their own legal authority, diligence, procurement, finance, insurance, approvals, safeguards, implementation, operations, and correction obligations.

## 1.6 NAF Output Classes

### 1.6.1 Signal Records.

1.6.1.1 Signal Records shall record incoming risk, opportunity, technology, policy, community, data, Observatory, Campaign, public authority, research, finance-readiness, insurance-readiness, standards-interface, safeguard, or correction signals. Signal Records shall identify source class, sensitivity, confidence where applicable, uncertainty where applicable, initial interpretation, public-safe status, and routing needs.

### 1.6.2 Docket Items.

1.6.2.1 Docket Items shall be governed work records. They shall state purpose, scope, pathway, steward, dependencies, assumptions, evidence needs, review needs, release class, boundary notices, correction pathway, and archive rule. Docket Items shall be the main units of NAF work movement.

### 1.6.3 Challenge Briefs.

1.6.3.1 Challenge Briefs shall frame risks, needs, gaps, questions, or opportunities in a form suitable for research, learning, Campaigns, Foundry quests, bounties, builds, Studio workflows, public authority learning, National Portfolios, or Nexus Universe arenas. Challenge Briefs shall be public-safe or controlled according to their classification.

### 1.6.4 Campaign Objects.

1.6.4.1 Campaign Objects shall include campaign purposes, mobilization records, signature records, pledge records, support records, volunteer records, team records, chapter records, ambassador records, campaign dashboards, public-safe stories, Campaign Docket items, correction records, and archive records. Campaign Objects shall not create mandate, vote, consent, finance, procurement, public authority action, or execution by implication.

### 1.6.5 Learning Objects.

1.6.5.1 Learning Objects shall include courses, modules, units, lessons, labs, simulations, Studio exercises, Work-Integrated Learning Paths, micro-credentials, badges, public-safe guides, instructor materials, contributor guides, assessment objects, and competency-linked records. Learning Objects shall not create professional license, employment status, procurement eligibility, public authority competence, or certification by implication.

### 1.6.6 Quest, Bounty, and Build Objects.

1.6.6.1 Quest, Bounty, and Build Objects shall define scoped work opportunities within Nexus Foundry, BuildGrid, Campaigns, Labs, Academy, Reports, Studio, DICE, GRIx, DRI, Observatory, Marketplace, Registry, Grid, TRL, National Portfolios, Nexus Universe, or handoff preparation. They shall record scope, evidence expectations, review gates, contribution rules, support class, labor boundary, reward or recognition status where applicable, correction pathway, and archive rule.

### 1.6.7 Evidence Packs and Method Notes.

1.6.7.1 Evidence Packs and Method Notes shall assemble evidence, sources, methods, assumptions, limitations, data status, AI-use status, uncertainty, confidence where applicable, review status, public-safe status, safeguard status, and correction pathway. They shall support learning, Reports, Studio workflows, Grid inputs, TRL notes, Registry status, Marketplace listings, National Portfolios, Nexus Universe outputs, and lawful handoff context.

### 1.6.8 Dataset, Model, System, Benchmark, Agent, API, and Digital Twin Cards.

1.6.8.1 Cards shall provide structured records for technical objects. Dataset Cards shall record data provenance, rights, quality, lineage, sensitivity, access class, data-use labels, AI-use labels, and correction rules. Model Cards, System Cards, Benchmark Cards, and Agent Workflow Cards shall record purpose, intended use, prohibited use, evaluation, limitations, human oversight, risk controls, incidents, and withdrawal rules. API and Digital Twin Cards shall record scope, dependencies, access, assumptions, limitations, public-safe outputs, and operational boundaries.

### 1.6.9 Studio Workflows.

1.6.9.1 Studio Workflows shall record controlled runtime environments, dashboards, simulations, digital twins, AI workflows, data-room workflows, secure-room workflows, public authority learning workflows, readiness-room workflows, capital-reader workflows, insurance-reader workflows, and handoff demonstrations. Studio Workflows shall not create deployment, command, decision, public authority approval, finance approval, insurance underwriting, or certification.

### 1.6.10 Marketplace Objects.

1.6.10.1 Marketplace Objects shall support discovery of public-good assets, learning opportunities, Campaigns, Foundry work, software, data, models, Reports, Studio workflows, National Portfolio objects, DICE objects, GRIx objects, DRI objects, Observatory objects, Grid and TRL objects, and handoff context objects. Marketplace listing shall not constitute endorsement, validation, procurement, finance, approval, or execution.

### 1.6.11 Registry Records.

1.6.11.1 Registry Records shall preserve status truth. They may record object identity, version, status, review level, release class, support class, data-use label, AI-use label, provider contribution, sponsor support, public authority participation, correction, withdrawal, supersession, recall, archive, or non-continuation. Registry status shall not be certification by default.

### 1.6.12 Grid Inputs and TRL 1–10 Evidence Notes.

1.6.12.1 Grid Inputs and TRL Evidence Notes shall record bounded readiness information. They shall capture evidence sufficiency, method quality, data status, AI-use status, cyber status, public-safe status, safeguard status, support status, repository status, Marketplace status, Registry status, and handoff dependency status. TRL 10 shall be a Nexus extended record for sustained, governed, corrected, supported, and handoff-traceable capability within scope, not a universal certification.

### 1.6.13 Nexus Reports.

1.6.13.1 Nexus Reports shall translate evidence into public-safe or controlled knowledge products, including National Portfolio Reports, WFEH-B Reports, DRR Reports, DRF Reports, DRI Reports, DICE Reports, GRIx Reports, Observatory Reports, Foundry Reports, Campaign Reports, Academy Reports, Labs Reports, Risk Agency Reports, Nexus Universe Reports, Grid and TRL Reports, handoff context notes, and correction or archive reports. Publication shall not create authority by default.

### 1.6.14 National Portfolio Objects.

1.6.14.1 National Portfolio Objects shall record national priorities, systems-risk maps, challenge briefs, evidence needs, Observatory needs, Core Build requests, safeguard records, public authority learning records, readiness questions, Competence Cell workplans, Nexus Universe routing records, and archive records. National Portfolio Objects shall not constitute country ranking, public authority approval, procurement plan, public finance allocation, or execution authorization.

### 1.6.15 Nexus Universe Outputs.

1.6.15.1 Nexus Universe Outputs shall include arena records, participation records, Core Build records, public authority learning records, readiness question records, support records, Marketplace listings, Registry updates, Reports, Campaign updates, Foundry continuation records, National Portfolio updates, handoff dependency notes, correction records, and archive records. Nexus Universe visibility shall not create endorsement, approval, finance, insurance, procurement, consent, or execution.

### 1.6.16 Lawful Handoff Dependency Packages.

1.6.16.1 Lawful Handoff Dependency Packages shall record 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 rules. They shall transfer dependencies, not authority.

### 1.6.17 Correction, Withdrawal, Recall, Archive, and Non-Continuation Records.

1.6.17.1 Correction, Withdrawal, Recall, Archive, and Non-Continuation Records shall preserve the integrity of the NAF system. They shall document the reason for action, affected objects, affected claims, downstream dependencies, required notices, Registry updates, Marketplace changes, Reports amendments, Studio workflow changes, Grid or TRL updates, handoff recall needs, public-safe repair, and archive status.

## 1.7 NAF Boundary Rules

### 1.7.1 NAF Does Not Certify by Default.

1.7.1.1 NAF does not certify by default. A NAF record, review, output, Registry status, Marketplace listing, Grid input, TRL note, Studio demonstration, Report, public-safe summary, Nexus Universe output, Campaign result, Foundry build, Academy learning object, Labs output, or handoff package shall not be interpreted as certification, accreditation, compliance determination, safety approval, maturity certification, professional qualification, standards conformance, or public authority approval unless separately and lawfully issued by a competent authority or certifying body.

### 1.7.2 NAF Does Not Procure.

1.7.2.1 NAF does not procure. NAF shall not select suppliers, award contracts, approve vendors, create tender eligibility, recommend procurement, rank bidders, validate providers, or confer procurement advantage. Marketplace discovery, Registry status, provider contribution, sponsor support, public-good software release, Studio demonstration, Nexus Universe presentation, or handoff context shall not substitute for lawful procurement.

### 1.7.3 NAF Does Not Finance.

1.7.3.1 NAF does not finance. NAF may record finance-readiness questions, capital-readability context, public finance relevance, donor-readiness questions, assumptions, dependencies, diligence gaps, and no-reliance notes. It shall not solicit securities, advise on investments, arrange financing, commit capital, lend, guarantee, rate, underwrite, allocate public finance, or create financeability by implication.

### 1.7.4 NAF Does Not Insure.

1.7.4.1 NAF does not insure. NAF may support insurance-readiness questions, risk-layering discussions, protection-gap analysis, exposure and vulnerability records, DRI context, and no-reliance insurance-reader rooms. It shall not underwrite, bind coverage, approve insurance, price risk for reliance, act as broker, act as insurer or reinsurer, guarantee insurability, or create insurance approval by implication.

### 1.7.5 NAF Does Not Issue Public Warnings.

1.7.5.1 NAF does not issue public warnings by default. NAF may support DRI, Observatory signals, dashboards, Reports, public-safe summaries, Studio scenarios, and public authority learning related to hazards and risk. Such outputs shall not constitute public warning, emergency alert, official forecast, evacuation notice, emergency command, or public authority instruction unless issued by a competent public authority through its own lawful process.

### 1.7.6 NAF Does Not Grant Community or Indigenous Consent.

1.7.6.1 NAF does not grant community or Indigenous consent. Community participation, Indigenous participation, civil society participation, Campaign engagement, consultation, learning-room attendance, public-safe reporting input, Studio participation, Nexus Universe participation, or National Portfolio involvement shall not be represented as consent unless consent is separately obtained and recorded through appropriate lawful and protocol-respecting processes.

### 1.7.7 NAF Does Not Replace Public Authorities.

1.7.7.1 NAF does not replace public authorities. It may support learning, evidence, policy intelligence, readiness questions, risk intelligence, public-safe reporting, controlled demonstrations, and handoff context for public authorities, but it shall not act as regulator, legislature, ministry, municipality, emergency authority, permitting body, procurement body, public finance body, standards authority, enforcement body, public warning body, or official decision-maker by default.

### 1.7.8 NAF Does Not Execute Projects by Implication.

1.7.8.1 NAF does not execute projects by implication. The creation, movement, review, publication, listing, demonstration, presentation, routing, or handoff preparation of NAF work shall not constitute implementation. Execution requires separate lawful action by competent actors with appropriate authority, resources, duties, approvals, safeguards, procurement, finance, insurance, community processes, technical operations, and accountability.

1.7.8.2 This boundary shall apply across all NAF outputs and contexts, including National Portfolios, Nexus Universe, Nexus Core Build, Foundry builds, Campaigns, Academy pathways, Labs outputs, Risk Agency advisory outputs, DICE objects, GRIx and DRI records, Observatory signals, Studio workflows, Grid inputs, TRL notes, Reports, Marketplace listings, Registry records, Rails routing, Network memory, National Nodes, and handoff packages.


---

# 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/i.-foundations.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.