# IV. LIFECYCLE

Nexus Agile Framework Lifecycle defines the **NAF work lifecycle** for public-good systems delivery. It explains how work moves from **signal** to **intake**, **triage**, **classification**, **docketing**, **review**, **release**, **routing**, **lawful handoff**, **correction**, and **archive**.

This section sets the operating discipline for **work movement**, **docket management**, **release classes**, **flow governance**, **definition of ready**, and **definition of done**. It keeps Nexus delivery traceable, reviewable, correctionable, and nationally routed without creating approval, procurement, finance, or execution by implication.

### What this section covers

* **Lifecycle flow** - Defines how NAF work moves from early signals to archive or non-continuation.
* **Docket discipline** - Explains governed work containers, backlog structure, pathway selection, and routing.
* **Release and correction** - Defines release classes, review gates, lawful handoff, and trust-preserving correction.

Use this section with [Nexus Agile Framework (NAF)](/organization/operations/frameworks/nexus-agile-framework-naf.md) for the full framework overview, [I. FOUNDATIONS](/organization/operations/frameworks/nexus-agile-framework-naf/i.-foundations.md) for constitutional rules, [II. SYSTEMS](/organization/operations/frameworks/nexus-agile-framework-naf/ii.-systems.md) for system architecture, and [III. STANDARDS](/organization/operations/frameworks/nexus-agile-framework-naf/iii.-standards.md) for interoperability and conformance discipline.

## 4.1 NAF Lifecycle Doctrine

### 4.1.1 Signal.

4.1.1.1 A Signal is the earliest recorded indication that a risk, opportunity, need, gap, question, hazard, technology, capability, public authority learning issue, data issue, evidence issue, safeguard issue, Campaign issue, Nexus Universe issue, National Portfolio issue, finance-readiness issue, insurance-readiness issue, standards-interface issue, or lawful handoff issue may require attention within NAF. A Signal may arise from public authorities, communities, Indigenous actors where applicable, universities, research bodies, enterprises, providers, sponsors, capital readers, insurers, donors, public finance readers, civil society, youth, media, National Councils, National Working Groups, 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 Nodes, DICE, GRIx, DRI, or lawful handoff recipients.

4.1.1.2 A Signal shall not be treated as verified truth, public warning, official finding, investment signal, insurance signal, procurement signal, certification trigger, public authority decision, consent, or execution instruction merely because it is received. A Signal shall be converted into an initial record before it may move through intake, triage, classification, Docketing, pathway selection, public-safe reporting, Studio workflow, Grid input, TRL note, Nexus Universe routing, or lawful handoff preparation.

4.1.1.3 Signal records shall identify source class, time, place where applicable, domain, hazard or technology relevance, public-good relevance, sensitivity, urgency, evidence status, confidence where applicable, uncertainty where applicable, data-use considerations, AI-use considerations, geospatial sensitivity, protected knowledge concerns, public authority dependency, finance/insurance/procurement boundary concerns, and correction pathway. Signals that involve sensitive, protected, public authority-sensitive, cyber-sensitive, health-sensitive, youth-related, community-sensitive, Indigenous protocol-sensitive, infrastructure-sensitive, or geospatial-sensitive information shall be routed under heightened controls.

### 4.1.2 Intake.

4.1.2.1 Intake is the NAF process by which a Signal or proposed work item is received into a governed record environment. Intake shall ensure that incoming work is not lost, mischaracterized, prematurely publicized, incorrectly routed, converted into authority, or moved without boundary discipline. Intake shall create the first formal relationship between a Signal and NAF’s Docket, classification, review, release, correction, and archive systems.

4.1.2.2 Intake shall record the submitting actor or source class, the proposed issue or opportunity, the requested pathway if any, the affected domain, the national, regional, or global relevance, the public-good purpose, the sensitivity class, known dependencies, requested urgency, initial evidence basis, known risks, data and AI status where applicable, public-safe considerations, safeguard considerations, and whether the item appears to require public authority learning, standards-interface review, secure-room handling, finance-readiness framing, insurance-readiness framing, procurement-neutrality review, or lawful handoff assessment.

4.1.2.3 Intake shall not approve the work, validate the source, certify the claim, create a public finding, establish a procurement opportunity, create a finance or insurance signal, or authorize action. Intake creates a record and permits triage.

### 4.1.3 Triage.

4.1.3.1 Triage is the NAF process for determining the initial seriousness, pathway, urgency, sensitivity, public-safe risk, safeguard relevance, review need, and routing need of an intake record. Triage shall distinguish ordinary work, learning work, evidence work, Campaign work, research work, Foundry work, Studio work, Registry or Marketplace work, Grid or TRL work, public authority learning work, Nexus Universe work, lawful handoff work, correction work, archive work, and stop-the-line work.

4.1.3.2 Triage shall assess whether the intake record requires immediate containment, delayed review, public-safe restriction, secure-room handling, data-room handling, protected knowledge controls, public authority boundary review, finance/insurance/procurement boundary review, standards-interface review, cyber review, AI review, privacy review, safeguard review, community-facing review, Indigenous protocol review where applicable, or legal-boundary review.

4.1.3.3 Triage shall not resolve the merits of the underlying issue unless the triage process is expressly authorized to close, reject, archive, or escalate a record. Triage shall determine how the record moves, not whether the underlying claim is true, approved, endorsed, certified, financed, procured, insured, consented to, or executed.

### 4.1.4 Classification.

4.1.4.1 Classification is the NAF process by which an intake or triage record is assigned structured labels that govern its handling, review, release, routing, and correction. Classification shall include public-good work class, learning class, evidence class, data class, AI-use class, cyber class, privacy class, safeguard class, geospatial sensitivity class, public authority class, finance/insurance/procurement boundary class, standards-interface class, handoff class, and archive class where applicable.

4.1.4.2 Classification shall be recorded before material work movement. A record shall not proceed to public release, Marketplace listing, Registry status, Studio demonstration, Grid input, TRL note, public authority learning room, capital-reader room, insurance-reader room, Nexus Universe presentation, or lawful handoff package unless required classification fields are complete or an authorized exception is recorded.

4.1.4.3 Classification shall remain correctionable. If new evidence, sensitivity, public authority context, data status, AI status, cyber status, safeguard concern, community concern, Indigenous protocol concern, standards dependency, finance-readiness dependency, procurement issue, or handoff issue emerges, the classification shall be updated and downstream records corrected where necessary.

### 4.1.5 Docketing.

4.1.5.1 Docketing is the process by which a classified record becomes governed work. A Docket item shall hold the purpose, scope, steward, source, classification, pathway, dependencies, assumptions, review needs, release class, expected outputs, boundary notices, correction pathway, and archive rule for the work. Docketing converts a record into a trackable public-good work object.

4.1.5.2 Docketing shall prevent informal momentum from becoming authority. A Docket item may move through NAF pathways, but Docket status shall not mean approval, certification, public authority decision, procurement status, financeability, insurability, provider validation, sponsor endorsement, community consent, Indigenous consent, deployment authorization, or execution authority.

4.1.5.3 Every material Docket item shall identify whether it is primarily public-good, national, regional, global, Universe, Foundry, Campaign, Academy, Labs, Reports, Studio, Grid/TRL, handoff, correction, archive, or cross-Docket. Cross-Docket items shall preserve the original source record and all downstream dependencies.

### 4.1.6 Backlog Formation.

4.1.6.1 Backlog Formation is the process by which Docket items are organized into actionable queues for work planning, resourcing, sequencing, review, release, and correction. Backlogs shall not be simple task lists; they shall be risk-aware, evidence-aware, boundary-aware, nationally routed, and correctionable work inventories.

4.1.6.2 NAF backlogs may include Nexus Portfolio Backlog, National Portfolio Backlog, Foundry Backlog, Campaign Backlog, Academy Backlog, Labs Backlog, Risk Agency Backlog, Reports Backlog, Marketplace Backlog, Registry Backlog, Studio Backlog, Grid and TRL Backlog, DICE/GRIx/DRI/Observatory Backlog, Handoff Backlog, and Correction Backlog. Each backlog shall preserve Docket references, priority logic, dependencies, work-in-progress limits, review requirements, release class, and correction priority.

4.1.6.3 Placement in a backlog shall not imply commitment to complete the work, public approval, funding, procurement, finance, insurance, certification, endorsement, consent, or execution. Backlog placement means the item is visible for governed consideration.

### 4.1.7 Pathway Selection.

4.1.7.1 Pathway Selection is the process by which a Docket item is routed into the NAF pathway or combination of pathways most appropriate to its purpose, classification, evidence needs, public-safe status, national routing, standards relevance, data and AI status, safeguard concerns, public authority relevance, finance/insurance/procurement boundary, and handoff potential.

4.1.7.2 A Docket item may be routed to Nexus Academy for learning, Risk Academy for risk literacy, Risk Agency for expert support, Nexus Labs for research, Nexus Foundry for production, Nexus Campaigns for mobilization, Nexus Reports for publication, Nexus Marketplace for discovery, Nexus Registry for status truth, Nexus Studio for controlled workflow or demonstration, Nexus Grid for readiness input, Nexus Observatory for signals and observability, Nexus Universe for annual convergence, Nexus Rails for routing, Nexus Network for memory, National Nodes for localization, DICE for data and commons, GRIx for risk meaning, DRI for risk intelligence, or lawful handoff pathways for dependency packaging.

4.1.7.3 Pathway Selection shall be recorded. The record shall state why the pathway is appropriate, what review gates apply, what release limits apply, what public-safe controls apply, what dependencies remain, and what correction pathway governs movement. Pathway Selection shall not be treated as approval of the work’s conclusions or authorization to execute.

### 4.1.8 Evidence Assembly.

4.1.8.1 Evidence Assembly is the process of collecting, organizing, documenting, and reviewing the evidence necessary for a Docket item to move toward release, routing, reporting, readiness input, Nexus Universe presentation, or lawful handoff. Evidence may include research findings, datasets, data dictionaries, code, model cards, system cards, benchmark cards, agent workflow cards, API records, digital twin cards, assumptions registers, dependency registers, method notes, peer review, expert review, community input, public authority learning records, Studio logs, Grid inputs, TRL notes, standards mappings, and correction records.

4.1.8.2 Evidence Assembly shall require scope discipline. Evidence shall state what it supports, what it does not support, the source and date of the evidence, the method used, the limitations, uncertainty, confidence where applicable, data-use status, AI-use status, public-safe status, sensitivity, safeguards, review level, and correction pathway. Evidence assembled for one national, technological, hazard, or institutional context shall not be silently generalized to another.

4.1.8.3 Evidence Assembly shall not convert evidence into certification, public authority approval, financeability, insurability, procurement readiness, community consent, Indigenous consent, deployment authorization, or execution. Evidence supports recorded meaning; it does not create authority by itself.

### 4.1.9 Review.

4.1.9.1 Review is the process by which a Docket item, output, record, workflow, or package is examined for scope, evidence, method, data, AI, cyber, privacy, public-safe status, safeguards, geospatial sensitivity, standards-interface relevance, public authority boundaries, finance/insurance/procurement boundaries, provider-neutrality, sponsor-boundary, handoff readiness, correction pathway, and archive rule.

4.1.9.2 Review may be technical, evidentiary, methodological, legal-boundary, public-safe, safeguard, data, AI, cyber, privacy, standards-interface, public authority, finance-readiness, insurance-readiness, procurement-neutrality, community-facing, Indigenous protocol-sensitive, Marketplace, Registry, Studio, Grid, TRL, Reports, or handoff review. Review shall be recorded with reviewer role, scope, date, findings, limitations, unresolved questions, required changes, release class, and correction needs.

4.1.9.3 Review shall not be overstated. A review within scope is not certification, approval, legal compliance determination, public authority action, finance approval, insurance approval, procurement decision, provider validation, consent, deployment authorization, or execution authorization unless separately and lawfully recorded by a competent actor.

### 4.1.10 Release.

4.1.10.1 Release is the process by which a NAF output is made available to a defined audience under a defined release class. Release may be internal, public-safe summary, controlled public, open public, Marketplace candidate, Registry-recorded, Studio-only, data-room-only, secure-room-only, handoff-recipient-only, archived, or non-continuing.

4.1.10.2 Release shall require a release record. The release record shall identify output identity, version, steward, Docket reference, release class, intended audience, evidence basis, review status, data-use label, AI-use label, public-safe status, safeguard status, support class, license or rights status where applicable, standards or protocol references where applicable, boundary notices, correction pathway, and archive rule.

4.1.10.3 Release shall not be treated as approval, endorsement, certification, procurement readiness, financeability, insurability, public authority decision, public warning, community consent, Indigenous consent, deployment authorization, or execution. Release makes an output available according to its class; it does not create authority beyond the record.

### 4.1.11 Registry, Marketplace, Reports, Studio, Grid, TRL, and Rails Routing.

4.1.11.1 After release or controlled review, NAF outputs shall be routed to appropriate Nexus systems. Outputs may move to Nexus Registry for status truth, Nexus Marketplace for discovery, Nexus Reports for publication, Nexus Studio for controlled workflow or demonstration, Nexus Grid for readiness input, TRL records for bounded technology-readiness evidence, Nexus Rails for routing, Nexus Network for memory, National Nodes for localization, Nexus Universe for annual convergence, or handoff pathways for lawful recipient context.

4.1.11.2 Routing shall preserve all boundary conditions. Routing records shall identify destination, release class, access class, review status, public-safe status, data and AI labels, support class, dependencies, assumptions, standards-interface notes, correction pathway, archive rule, and downstream limits. Routing shall not permit an output to acquire a stronger status by moving across systems.

4.1.11.3 Routing is movement, not approval. Registry entry is not certification. Marketplace listing is not procurement. Report publication is not public authority action. Studio workflow is not deployment. Grid input is not maturity certification. TRL note is not financeability. Rails movement is not execution.

### 4.1.12 Nexus Universe Presentation.

4.1.12.1 Nexus Universe Presentation is the process by which eligible NAF outputs, National Portfolio objects, Campaign records, Foundry builds, Studio workflows, Reports, Registry updates, Marketplace listings, Grid inputs, TRL notes, public authority learning records, DRI and Observatory records, finance-readiness questions, insurance-readiness questions, safeguard records, and handoff dependency notes may be presented within Nexus Universe arenas, rooms, Core Build environments, showcases, public-safe sessions, or controlled rooms.

4.1.12.2 Eligibility for Nexus Universe presentation shall require recorded scope, release class, public-safe status, boundary notices, safeguard status, data and AI labels, speaker or presenter role, public authority boundary notices, sponsor and provider boundary notices, finance/insurance/procurement boundary notices where applicable, and correction pathway.

4.1.12.3 Nexus Universe presentation shall not imply endorsement, public authority approval, procurement status, financeability, insurance approval, certification, consent, deployment authorization, or execution. Visibility in Nexus Universe shall remain visibility within recorded scope.

### 4.1.13 National Continuation.

4.1.13.1 National Continuation is the process by which NAF outputs, Nexus Universe results, Reports, Campaigns, Foundry builds, Studio workflows, DRI and Observatory records, Grid inputs, TRL notes, Marketplace listings, Registry records, learning outputs, and handoff dependency notes are returned to national pathways for localization, continuation, correction, archive, or lawful handoff consideration.

4.1.13.2 National Continuation shall preserve national ownership before local delivery. It shall identify the relevant National Nexus Consortium, National Council, National Working Group, Competence Cell, National Node, public authority learning process, National Portfolio, safeguard process, public-safe reporting pathway, and lawful handoff recipient pathway where applicable.

4.1.13.3 National Continuation shall not imply national adoption, public authority approval, procurement decision, finance approval, insurance approval, implementation commitment, community consent, Indigenous consent, or execution. It shall mean that the output is available for nationally routed consideration.

### 4.1.14 Lawful Handoff.

4.1.14.1 Lawful Handoff is the process by which NAF prepares and transmits bounded handoff context to a competent lawful recipient. Handoff may be relevant to National Consortium Companies, Project SPVs, public authorities, providers, operators, contractors, funders, insurers, donors, universities, labs, community actors where appropriate, or other competent actors.

4.1.14.2 Handoff shall require a handoff dependency package that records evidence context, method context, data context, software context, model 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 pathway, recall pathway, and archive rule.

4.1.14.3 Lawful Handoff transfers dependencies, not authority. It shall not authorize implementation, select a supplier, approve a project, issue public finance, commit capital, underwrite risk, certify safety, approve compliance, grant consent, approve deployment, or execute work. The recipient remains responsible for independent diligence and lawful action.

### 4.1.15 Correction.

4.1.15.1 Correction is the lifecycle function through which NAF preserves trust when records, outputs, claims, statuses, mappings, releases, reports, listings, workflows, reviews, Grid inputs, TRL notes, Nexus Universe outputs, or handoff packages become inaccurate, incomplete, outdated, overclaimed, unsafe, misclassified, misrouted, misused, or boundary-breaching.

4.1.15.2 Correction may include amendment, erratum, addendum, clarification, public-safe notice, metadata correction, classification change, Registry status update, Marketplace delisting, Report correction, Studio restriction, Grid downgrade, TRL correction, Campaign claims freeze, data freeze, technical freeze, model freeze, API freeze, handoff recall, withdrawal, retraction where necessary, archive, or reinstatement.

4.1.15.3 Correction shall propagate where required. If an error affects downstream records, the correction shall move through Rails, Registry, Marketplace, Reports, Studio, Grid, TRL, Nexus Universe, National Portfolios, Campaigns, Academy records, Foundry outputs, DICE, GRIx, DRI, Observatory records, handoff packages, and archive records as appropriate.

### 4.1.16 Archive or Non-Continuation.

4.1.16.1 Archive or Non-Continuation is the lifecycle function through which NAF preserves records that are no longer active, not continued, superseded, withdrawn, recalled, deprecated, restricted, sealed, or historically retained. Archive shall preserve institutional memory; Non-Continuation shall prevent false expectations of further work.

4.1.16.2 Archive records shall identify object identity, version, Docket reference, reason for archive, access class, archive-not-current notice, successor links, correction history, support status, license or rights status, public-safe status, retention rule, deletion or sealing rule where applicable, and permitted historical use.

4.1.16.3 Archive shall not convert obsolete records into current authority. Non-Continuation shall not imply failure where the decision preserves accuracy, safety, public-good discipline, resource focus, safeguard protection, national ownership, or correctionability.

## 4.2 Docket System

### 4.2.1 Docket Defined.

4.2.1.1 A Docket is the formal NAF work container through which a record becomes governed work. A Docket item shall hold purpose, scope, classification, source, steward, pathway, dependencies, assumptions, priority, review gates, release class, output class, routing plan, support class, boundary notices, correction pathway, and archive rule.

4.2.1.2 The Docket System shall serve as the central work-movement discipline of NAF. It shall connect signals to action, evidence to review, outputs to release, releases to routing, routing to public-safe knowledge, public-safe knowledge to readiness context, readiness context to Nexus Universe, Nexus Universe outputs to national continuation, and national continuation to lawful handoff where applicable.

4.2.1.3 A Docket is not authority. Docketing shall not imply approval, certification, procurement status, financeability, insurability, public authority action, endorsement, consent, deployment authorization, or execution. A Docket exists to govern movement and preserve accountability.

### 4.2.2 Public-Good Docket.

4.2.2.1 The Public-Good Docket shall hold work items that advance Nexus public-good purposes, including evidence, methods, learning, public-good software, public-safe reporting, data commons, risk intelligence, Campaigns, public authority learning, open technical baselines, standards-interface records, Registry status, Marketplace discovery, Studio workflows, Grid inputs, TRL notes, Nexus Universe outputs, correction, and archive.

4.2.2.2 Public-Good Docket items shall be prioritized by public-good value, risk relevance, evidence need, national relevance, whole-of-society relevance, safeguard sensitivity, readiness need, correction urgency, and lawful handoff dependency. Public-Good Docket work shall remain non-executing by default.

### 4.2.3 National Docket.

4.2.3.1 The National Docket shall hold country-level Nexus work, including National Portfolio items, national systems-risk records, national Campaigns, National Working Group outputs, Competence Cell workplans, national Academy pathways, national Foundry builds, national DRI and Observatory inputs, national Reports, national Registry and Marketplace records, public authority learning records, national safeguard records, and lawful handoff dependency items.

4.2.3.2 National Docket work shall preserve national ownership before local delivery. It shall record country context, national stakeholders, public authority dependencies, language and localization needs, data sovereignty conditions, community safeguard issues, Indigenous protocol issues where applicable, finance/insurance/procurement boundaries, and national continuation rules.

### 4.2.4 Regional Docket.

4.2.4.1 The Regional Docket shall hold work that concerns regional clusters, cross-border systems, shared hazards, regional WFEH-B dependencies, disaster-risk corridors, infrastructure corridors, regional capability gaps, regional public authority learning, regional Nexus Universe preparation, regional Campaigns, regional Observatory signals, and regional finance-readiness or insurance-readiness questions.

4.2.4.2 Regional Docket items shall support national pathways and shall not override national ownership. Regional Docket records shall identify participating countries, affected systems, regional dependencies, national routing conditions, public-safe limits, and correction pathways.

### 4.2.5 Global Docket.

4.2.5.1 The Global Docket shall hold work that concerns global Nexus priorities, universal public-good infrastructure, global DRI or GRIx structures, global DICE objects, global open technical baselines, global Reports, global Nexus Universe priorities, global standards-interface questions, global Campaigns, global public-safe reporting, and global correction or archive.

4.2.5.2 Global Docket work shall provide coherence without supremacy. It shall not displace national authority, regional context, community safeguards, Indigenous protocols, data sovereignty, public authority decision-making, or lawful handoff responsibilities.

### 4.2.6 Universe Docket.

4.2.6.1 The Universe Docket shall hold work routed to Nexus Universe, including arena items, Core Build items, National Portfolio presentations, Foundry builds, Campaign outputs, Academy outputs, Labs outputs, Studio workflows, Reports, Marketplace listings, Registry updates, Grid inputs, TRL notes, public authority learning records, readiness-room questions, capital-reader room questions, insurance-reader room questions, safeguard records, correction-room items, and handoff dependency notes.

4.2.6.2 Universe Docket items shall include presentation eligibility, release class, public-safe status, presenter roles, room type, boundary notices, sponsor/provider restrictions, public authority boundary notices, finance/insurance/procurement notices, and post-Universe continuation or archive pathway.

### 4.2.7 Foundry Docket.

4.2.7.1 The Foundry Docket shall hold public-good production work, including quests, bounties, builds, micro-production objects, software builds, data builds, dashboard builds, Studio workflow builds, Registry record builds, Marketplace object builds, Reports builds, Grid inputs, TRL notes, National Portfolio builds, Campaign builds, and handoff dependency builds.

4.2.7.2 Foundry Docket items shall include build scope, acceptance criteria, evidence requirements, maintainer roles, contributor rules, labor boundary notices, data and AI controls, cyber controls, public-safe status, release class, support class, correction pathway, and archive rule.

### 4.2.8 Campaign Docket.

4.2.8.1 The Campaign Docket shall hold mobilization work, including campaign purpose records, public-safe messaging, signature tools, pledge tools, support tools, volunteer tools, team formation, chapters, ambassadors, dashboards, public-safe stories, Academy pathways, Foundry routing, National Portfolio activation, Nexus Universe preparation, support ledgers, correction records, and archive records.

4.2.8.2 Campaign Docket items shall include claims controls, data controls, technical freeze rules where applicable, sponsor controls, provider controls, trust and safety controls, fraud controls, community consent boundary notices, public authority boundary notices, and stop-the-line triggers.

### 4.2.9 Academy Docket.

4.2.9.1 The Academy Docket shall hold learning work, including Nexus Academy learning objects, Risk Academy pathways, micro-credentials where applicable, Work-Integrated Learning Paths, Integrated Learning Account records, mentor assignments, learner pathways, public authority learning modules, Foundry contributor training, public-safe reporting training, data and AI training, safeguard training, and handoff literacy training.

4.2.9.2 Academy Docket items shall include competency mapping, learner safeguards, accessibility, translation, assessment controls, sponsor/provider controls, AI-use controls, data and privacy controls, credential boundary notices, correction, withdrawal, and archive rules.

### 4.2.10 Labs Docket.

4.2.10.1 The Labs Docket shall hold research work, including research questions, evidence gaps, methods, testbeds, datasets, models, simulations, system cards, benchmark records, scenario records, impact assessments, research-to-Foundry transfers, research-to-Reports transfers, and research-to-handoff context items.

4.2.10.2 Labs Docket items shall include ethics boundaries, data rights, AI-use controls, public-safe publication controls, protected knowledge controls, community safeguards, public authority boundaries, sponsor/provider controls, dual-use controls, correction, and archive rules.

### 4.2.11 Reports Docket.

4.2.11.1 The Reports Docket shall hold publication work, including concept notes, evidence assembly, drafting, review, public-safe transformation, metadata preparation, repository preparation, DOI-related records where applicable, distribution, correction, withdrawal, archive, and non-continuation.

4.2.11.2 Reports Docket items shall include report family, source records, evidence scope, public-safe class, data availability statement, AI-use statement, controlled knowledge exclusions, license, review status, correction pathway, and no-conversion notices.

### 4.2.12 Studio Docket.

4.2.12.1 The Studio Docket shall hold controlled workflow work, including dashboard workflows, digital twin workflows, scenario workflows, AI workflow review, data-room workflows, secure-room workflows, public authority learning workflows, readiness-room workflows, capital-reader workflows, insurance-reader workflows, Nexus Universe workflows, and handoff demonstration workflows.

4.2.12.2 Studio Docket items shall include access control, role permissions, no-write-back rules, no-command rules, output review, AI-use restrictions, data export restrictions, public-safe restrictions, logging, shutdown triggers, correction triggers, and archive rules.

### 4.2.13 Grid and TRL Docket.

4.2.13.1 The Grid and TRL Docket shall hold readiness and maturity-input work, including evidence sufficiency, method quality, data status, AI-use status, cyber status, public-safe status, safeguard status, support status, repository status, Marketplace status, Registry status, handoff dependency status, TRL notes, downgrade, suspension, withdrawal, reinstatement, and correction.

4.2.13.2 Grid and TRL Docket items shall include readiness class, review gate, evidence basis, limitations, non-certification notice, non-procurement notice, non-finance notice, non-insurance notice, public authority boundary notice, and deployment boundary notice.

### 4.2.14 Handoff Docket.

4.2.14.1 The Handoff Docket shall hold work items that may be prepared for lawful handoff to National Consortium Companies, Project SPVs, public authorities, providers, operators, contractors, funders, insurers, donors, universities, labs, community actors where appropriate, or other competent lawful actors.

4.2.14.2 Handoff Docket items shall include recipient class, 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 pathway, recall pathway, and archive rule.

### 4.2.15 Correction Docket.

4.2.15.1 The Correction Docket shall hold correction work across NAF, including errors, overclaims, incidents, misclassifications, outdated records, public-safe issues, data issues, AI issues, cyber issues, privacy issues, protected knowledge issues, standards overclaims, public authority boundary issues, finance boundary issues, procurement boundary issues, sponsor control issues, provider validation issues, consent overclaims, handoff overclaims, execution overclaims, withdrawal, recall, archive, and reinstatement.

4.2.15.2 Correction Docket items shall receive priority over ordinary work where trust, safety, public authority boundaries, data rights, AI safety, cyber safety, protected knowledge, community safeguards, finance/procurement boundaries, or execution overclaims are at risk.

## 4.3 Cadence Architecture

### 4.3.1 Daily Work Rhythm.

4.3.1.1 The Daily Work Rhythm shall govern ordinary movement of active work through Dockets, backlogs, build tasks, review tasks, Campaign tasks, learning tasks, Studio tasks, Registry updates, Marketplace updates, Reports drafting, data work, AI review, cyber review, public-safe review, and correction checks. Daily rhythm shall be lightweight but record-bearing.

4.3.1.2 Daily rhythm shall identify what moved, what is blocked, what new risk appeared, what dependency emerged, what review is required, what boundary notice must be added, what correction may be needed, and what work should not proceed. Daily rhythm shall not be used to bypass review, classification, public-safe controls, or national routing.

### 4.3.2 Weekly Review Rhythm.

4.3.2.1 The Weekly Review Rhythm shall govern structured review of active Docket items, work-in-progress limits, evidence sufficiency, pathway fit, blocked items, review queues, public-safe risks, safeguard issues, data and AI issues, cyber issues, sponsor/provider controls, public authority boundaries, finance/insurance/procurement boundaries, and correction needs.

4.3.2.2 Weekly review may adjust priority, pathway, steward, support class, release class, review gate, or archive status. Weekly review shall not create final approval, certification, procurement status, financeability, insurance approval, public authority action, consent, or execution authorization.

### 4.3.3 Monthly Docket Review.

4.3.3.1 The Monthly Docket Review shall examine the health of each major Docket, including public-good, national, regional, global, Universe, Foundry, Campaign, Academy, Labs, Reports, Studio, Grid and TRL, handoff, and correction Dockets. Monthly review shall identify stale items, overloaded queues, missing classifications, unresolved dependencies, recurring bottlenecks, repeated boundary issues, evidence gaps, public-safe publication needs, and archive candidates.

4.3.3.2 Monthly review shall produce Docket health records, priority updates, correction needs, non-continuation recommendations, archive decisions where authorized, and escalation items. It shall preserve Docket integrity without creating approval or execution authority.

### 4.3.4 Quarterly Nexus Release Cycle.

4.3.4.1 The Quarterly Nexus Release Cycle shall provide a structured window for releasing reviewed NAF outputs, including Reports, public-safe summaries, software releases, data objects, learning objects, Campaign updates, Registry records, Marketplace listings, Studio workflow releases, Grid inputs, TRL notes, National Portfolio updates, and correction packages.

4.3.4.2 Quarterly releases shall require release readiness review, public-safe review, support status, Registry status where applicable, Marketplace metadata where applicable, correction pathway, archive rule, and boundary notices. Quarterly release shall not mean approval, certification, procurement readiness, financeability, insurability, public authority action, consent, deployment, or execution.

### 4.3.5 Semi-Annual National Portfolio Review.

4.3.5.1 The Semi-Annual National Portfolio Review shall examine country-level Nexus work, including National Portfolio objects, national systems-risk maps, National Working Group outputs, Competence Cell workplans, national Campaign outputs, public authority learning records, national Academy pathways, national Foundry builds, DRI and Observatory records, finance-readiness questions, insurance-readiness questions, safeguard records, Nexus Universe preparation, and handoff dependency records.

4.3.5.2 Semi-Annual National Portfolio Review shall preserve national ownership, update national priorities, identify continuation pathways, identify archive candidates, prepare Nexus Universe inputs, and identify lawful handoff dependencies. It shall not create national adoption, government approval, public finance allocation, procurement plan, investment pipeline, insurance approval, consent, or execution authorization.

### 4.3.6 Annual Nexus Universe Cycle.

4.3.6.1 The Annual Nexus Universe Cycle shall concentrate NAF work into a public-good systems-build and convergence cycle. It shall include pre-cycle signal collection, National Portfolio preparation, Campaign activation, Working Group formation, Competence Cell preparation, Foundry backlog preparation, Studio workflow preparation, public authority learning preparation, readiness-room preparation, arena release, post-cycle reporting, continuation, correction, and archive.

4.3.6.2 Annual Nexus Universe participation shall be governed by presentation eligibility, release class, public-safe status, sponsor/provider controls, public authority boundary notices, finance/insurance/procurement notices, safeguard status, data and AI labels, and correction pathways.

4.3.6.3 The Annual Nexus Universe Cycle shall not convert visibility into endorsement, public authority approval, procurement status, financeability, insurance approval, certification, consent, deployment authorization, or execution.

### 4.3.7 Multi-Year National Capability Cycle.

4.3.7.1 The Multi-Year National Capability Cycle shall govern longer-horizon national capability formation across skills, public-good software, data commons, observability, disaster-risk intelligence, WFEH-B systems, public authority learning, finance-readiness literacy, insurance-readiness literacy, National Portfolios, National Nodes, Nexus Competence Cells, and lawful handoff pathways.

4.3.7.2 Multi-year cycles shall preserve continuity beyond annual releases and events. They shall support maturity of national capabilities, workforce pathways, institutional memory, standards-aware interoperability, infrastructure readiness, public-safe reporting, correction history, and lawful handoff readiness.

4.3.7.3 Multi-year capability records shall not constitute national ranking, public authority approval, financing plan, insurance approval, procurement plan, or execution commitment.

### 4.3.8 Emergency Correction Cycle.

4.3.8.1 The Emergency Correction Cycle shall be triggered when an error, overclaim, incident, unsafe release, public-safe issue, data incident, AI incident, cyber incident, privacy incident, protected knowledge incident, standards overclaim, public authority boundary issue, finance/procurement boundary issue, sponsor control issue, provider validation issue, consent overclaim, handoff overclaim, or execution overclaim requires immediate action.

4.3.8.2 Emergency correction may include claims freeze, data freeze, technical freeze, model freeze, API freeze, Campaign freeze, Marketplace delisting, Registry status update, Report correction, Studio shutdown, Grid downgrade, TRL correction, Nexus Universe notice, handoff recall, public-safe notice, and archive or reinstatement.

4.3.8.3 Emergency correction shall override ordinary cadence where trust, safety, legality, public authority boundary, community safeguard, protected knowledge, data protection, cyber safety, or role separation is at risk.

### 4.3.9 Non-Continuation Cycle.

4.3.9.1 The Non-Continuation Cycle shall govern decisions not to continue work. Non-continuation may occur because evidence is insufficient, risk is too high, safeguards cannot be satisfied, resources are unavailable, national routing is inappropriate, public authority dependencies cannot be resolved, data rights are insufficient, AI risks are unacceptable, cyber risks are unresolved, sponsor or provider conflicts cannot be managed, or the work no longer serves the public-good purpose.

4.3.9.2 Non-continuation shall be recorded with reason, affected records, downstream dependencies, public-safe notice needs, archive status, successor options, and correction pathway. Non-continuation shall not be framed as failure where it preserves public-good discipline, safety, or trust.

### 4.3.10 Archive Renewal Cycle.

4.3.10.1 The Archive Renewal Cycle shall periodically review archived records, historical outputs, non-current Reports, old Registry records, delisted Marketplace objects, deprecated software, sealed data, withdrawn models, obsolete Studio workflows, old Grid inputs, old TRL notes, past Nexus Universe outputs, and handoff packages to ensure archive status remains clear and safe.

4.3.10.2 Archive renewal may update metadata, access class, archive-not-current notices, successor links, correction history, license status, public-safe status, retention rules, sealing rules, or deletion rules where appropriate. Archive renewal shall not reinstate archived items unless a recorded review authorizes reinstatement.

## 4.4 Intake and Triage

### 4.4.1 Signal Intake.

4.4.1.1 Signal Intake shall receive early indications of risk, opportunity, need, gap, error, technology issue, public authority question, data issue, public-safe issue, Campaign issue, or handoff issue. Signal Intake shall be open enough to detect weak signals and disciplined enough to prevent unverified claims from moving as facts.

4.4.1.2 Signal Intake shall record source class, domain, urgency, sensitivity, initial evidence, public-good relevance, affected geography or system, possible pathway, public-safe concern, and correction path. It shall not validate the Signal.

### 4.4.2 Risk Intake.

4.4.2.1 Risk Intake shall receive risks relating to WFEH-B systems, DRR, DRF, DRI, climate, nature, biodiversity, infrastructure, public health, food, water, energy, cyber-physical systems, supply chains, public authority learning, finance-readiness, insurance-readiness, and exponential technologies.

4.4.2.2 Risk Intake shall identify hazard, exposure, vulnerability, resilience capacity, affected actors, data needs, DRI relevance, GRIx classification, public-safe communication needs, and public authority dependencies. Risk Intake shall not create warning authority or official risk determination.

### 4.4.3 Innovation Intake.

4.4.3.1 Innovation Intake shall receive ideas, technologies, methods, prototypes, datasets, software concepts, open technical baseline proposals, research-to-build opportunities, enterprise-relevant proposals, and public-good innovation needs.

4.4.3.2 Innovation Intake shall record novelty, public-good purpose, evidence need, technical dependencies, standards relevance, data and AI status, sponsor/provider involvement, potential Foundry pathway, potential Studio workflow, potential Grid or TRL pathway, and handoff relevance. Innovation Intake shall not validate the innovation or authorize deployment.

### 4.4.4 Public Authority Learning Intake.

4.4.4.1 Public Authority Learning Intake shall receive questions, learning needs, policy intelligence needs, scenario needs, evidence review needs, Studio demonstration requests, DRI interpretation needs, Observatory interpretation needs, and readiness questions involving public authorities.

4.4.4.2 Public Authority Learning Intake shall record the public authority context, non-decision status, public authority dependency, sensitive information class, public-safe status, data conditions, room type, review needs, and correction pathway. It shall not create public authority approval or action.

### 4.4.5 National Portfolio Intake.

4.4.5.1 National Portfolio Intake shall receive country-level priorities, systems-risk maps, national challenge briefs, Working Group outputs, Competence Cell needs, public authority learning records, Campaign signals, DRI and Observatory inputs, WFEH-B needs, technology-readiness questions, safeguard records, finance-readiness questions, insurance-readiness questions, and handoff dependencies.

4.4.5.2 National Portfolio Intake shall preserve national ownership, record national context, identify national routing, and prevent external bypass. Intake into a National Portfolio shall not create national adoption, government approval, financing commitment, procurement plan, or implementation authorization.

### 4.4.6 Campaign Intake.

4.4.6.1 Campaign Intake shall receive proposed Campaigns, mobilization topics, public-safe storytelling needs, signature or pledge requests, support needs, volunteer opportunities, ambassador proposals, team and chapter proposals, public authority learning Campaigns, youth Campaigns, university Campaigns, Nexus Universe Campaigns, and handoff awareness Campaigns.

4.4.6.2 Campaign Intake shall record campaign purpose, audience, claims risk, data needs, trust and safety risks, sponsor/provider involvement, public authority boundary, community consent boundary, support controls, fraud controls, release class, and correction path. Campaign Intake shall not create mandate, vote, consent, funding commitment, public authority approval, or execution authority.

### 4.4.7 Data Intake.

4.4.7.1 Data Intake shall receive datasets, data sources, metadata, data dictionaries, data pipelines, sensor data, geospatial data, public authority-sensitive data, community-sensitive data, Indigenous protocol-sensitive data where applicable, health-sensitive data, youth data, cyber-sensitive data, infrastructure-sensitive data, and data-use proposals.

4.4.7.2 Data Intake shall record rights, provenance, lineage, quality, sensitivity, data-use label, AI-use label, access class, residency requirements, cross-border transfer restrictions, compute-to-data needs, public-safe transformation needs, retention, deletion, sealing, incident response, correction, and archive. Data Intake shall not create data rights or publication permission.

### 4.4.8 Technology Intake.

4.4.8.1 Technology Intake shall receive technology objects, systems, software, models, AI workflows, APIs, dashboards, digital twins, telecom systems, edge systems, compute environments, cyber tools, DLT objects, robotics, drones, sensors, semiconductors, advanced manufacturing systems, quantum-relevant systems, and biosecurity-sensitive technologies.

4.4.8.2 Technology Intake shall record object class, purpose, evidence basis, technical maturity, standards relevance, dependencies, cybersecurity status, AI-use status, data status, dual-use sensitivity, public authority dependencies, provider involvement, support class, Grid and TRL relevance, and handoff potential. Technology Intake shall not authorize deployment.

### 4.4.9 Research Intake.

4.4.9.1 Research Intake shall receive research questions, evidence gaps, methods, testbeds, study proposals, datasets, model evaluation needs, benchmark proposals, scenario research, public authority learning research, and research-to-Foundry opportunities.

4.4.9.2 Research Intake shall record ethics boundaries, data rights, AI-use controls, public-safe publication status, protected knowledge issues, community safeguards, dual-use sensitivity, public authority boundaries, sponsor/provider involvement, and correction pathway. Research Intake shall not approve or validate findings.

### 4.4.10 Handoff Intake.

4.4.10.1 Handoff Intake shall receive requests or indications that a NAF output may be relevant to lawful implementation consideration by a competent recipient. It shall identify the recipient class, requested use, evidence context, dependencies, public authority issues, legal issues, finance and insurance questions, procurement boundaries, provider-neutrality notes, sponsor-boundary notes, safeguard status, and correction pathway.

4.4.10.2 Handoff Intake shall not approve handoff. It shall determine whether a handoff Docket item should be created and what review is needed before any handoff package is prepared.

### 4.4.11 Sensitive Source Intake.

4.4.11.1 Sensitive Source Intake shall receive information from sources requiring heightened protection, including public authority-sensitive sources, community-sensitive sources, Indigenous protocol-sensitive sources where applicable, confidential enterprise sources, protected knowledge sources, health-sensitive sources, youth-related sources, cyber-sensitive sources, infrastructure-sensitive sources, geospatial-sensitive sources, and sources subject to legal or contractual restrictions.

4.4.11.2 Sensitive Source Intake shall record access restrictions, disclosure limits, permission status, data-use limits, AI-use limits, public-safe transformation requirements, secure-room requirements, output review, sealing, correction, and archive. Sensitive sources shall not be exposed through public release, Marketplace listing, Reports, Studio demonstrations, or handoff without proper review.

### 4.4.12 Protected Knowledge Intake.

4.4.12.1 Protected Knowledge Intake shall receive knowledge that requires special protection because of community, Indigenous, cultural, ecological, security, safety, biological, cyber, infrastructure, geospatial, humanitarian, legal, ethical, or rights-based sensitivity.

4.4.12.2 Protected Knowledge Intake shall require heightened controls, including restricted access, permission records, protocol review, public-safe transformation, no-download rules where appropriate, output review, masking or generalization, sealing, correction, and archive. Protected Knowledge Intake shall not create permission to publish, train AI, share externally, commercialize, or hand off.

### 4.4.13 Urgent Correction Intake.

4.4.13.1 Urgent Correction Intake shall receive suspected errors, overclaims, unsafe outputs, privacy issues, cyber issues, AI issues, data issues, public-safe reporting issues, protected knowledge issues, standards overclaims, public authority boundary issues, finance or procurement boundary issues, provider validation issues, sponsor control issues, consent overclaims, handoff overclaims, or execution overclaims requiring rapid response.

4.4.13.2 Urgent Correction Intake shall immediately assess whether claims freeze, data freeze, technical freeze, model freeze, API freeze, Marketplace delisting, Registry status update, public-safe notice, Studio shutdown, Grid downgrade, TRL correction, handoff recall, or archive is required.

### 4.4.14 Stop-the-Line Intake.

4.4.14.1 Stop-the-Line Intake shall receive issues that may require immediate suspension of work movement. Stop-the-Line triggers may include material safety risk, unlawful overclaim, protected knowledge exposure, data breach, cyber incident, AI incident, public authority boundary breach, finance boundary breach, procurement neutrality breach, sponsor control, provider validation overclaim, community or Indigenous consent overclaim, or execution overclaim.

4.4.14.2 Stop-the-Line Intake shall be empowered to pause affected Docket items, releases, listings, publications, Studio workflows, Campaigns, Grid inputs, TRL notes, Nexus Universe presentations, and handoff packages pending review. Stop-the-Line is a trust-preserving mechanism and shall be recorded.

## 4.5 Classification System

### 4.5.1 Public-Good Work Class.

4.5.1.1 The Public-Good Work Class shall identify whether the work is learning, evidence, method, public-good software, public-safe reporting, Campaign, Registry, Marketplace, Studio, Grid, TRL, DICE, GRIx, DRI, Observatory, Nexus Universe, National Portfolio, handoff, correction, archive, or other public-good work.

4.5.1.2 This class shall identify the public-good purpose and prevent work from being mischaracterized as enterprise execution, procurement activity, finance activity, insurance activity, certification activity, public authority action, or deployment.

### 4.5.2 Learning Class.

4.5.2.1 The Learning Class shall identify whether work concerns Nexus Academy, Risk Academy, ILA, WILP, micro-credential, contributor onboarding, mentor pathway, public authority learning, Studio exercise, Foundry contributor training, public-safe reporting training, safeguard training, or handoff literacy.

4.5.2.2 Learning classification shall include credential boundary notices, learner data protection, youth safeguards where applicable, accessibility, assessment controls, and correction path.

### 4.5.3 Evidence Class.

4.5.3.1 The Evidence Class shall identify evidence type, strength, source, method, review status, confidence where applicable, uncertainty, assumptions, limitations, reproducibility, public-safe status, and correction pathway.

4.5.3.2 Evidence classification shall prevent outputs from overstating what evidence supports. Evidence class shall be updated where evidence is corrected, superseded, downgraded, or withdrawn.

### 4.5.4 Data Class.

4.5.4.1 The Data Class shall identify whether data is open, public-safe, controlled public, restricted, public authority-sensitive, community-sensitive, Indigenous protocol-sensitive where applicable, protected knowledge, youth data, health-sensitive, cyber-sensitive, infrastructure-sensitive, geospatial-sensitive, handoff-recipient-only, archive-only, or subject to another access rule.

4.5.4.2 Data classification shall govern access, publication, AI use, compute-to-data requirements, cross-border transfer, retention, deletion, sealing, incident response, correction, and archive.

### 4.5.5 AI-Use Class.

4.5.5.1 The AI-Use Class shall identify whether AI use is prohibited, retrieval-only, summarization with review, classification with review, evaluation-only, fine-tuning permitted, training permitted, agentic use prohibited, secure-room AI only, public-safe AI output only, or otherwise restricted.

4.5.5.2 AI-use classification shall govern model use, agentic workflows, tool permissions, human review, output review, bias and harm review, prompt-injection controls, incident response, withdrawal, and correction.

### 4.5.6 Cyber Class.

4.5.6.1 The Cyber Class shall identify cybersecurity sensitivity, including ordinary, elevated, restricted, vulnerability-related, critical infrastructure-sensitive, OT/IoT-sensitive, credential-sensitive, configuration-sensitive, red-team-sensitive, incident-sensitive, or public-safe cyber summary.

4.5.6.2 Cyber classification shall govern access, disclosure, secure-room handling, vulnerability channels, public-safe transformation, logging, incident response, correction, and archive.

### 4.5.7 Safeguard Class.

4.5.7.1 The Safeguard Class shall identify whether work implicates community safeguards, Indigenous protocols where applicable, protected knowledge, youth safeguards, disability inclusion, accessibility, humanitarian sensitivity, conflict sensitivity, non-extractive engagement, rights-based concerns, or community-facing correction.

4.5.7.2 Safeguard classification shall determine review needs, release limits, participation boundaries, consent boundary notices, public-safe controls, and correction pathways.

### 4.5.8 Geospatial Sensitivity Class.

4.5.8.1 The Geospatial Sensitivity Class shall identify whether geospatial information involves sensitive infrastructure, protected species, sacred sites, protected knowledge, community-sensitive locations, conflict-sensitive locations, critical assets, emergency facilities, cyber-physical vulnerabilities, or other sensitive locations.

4.5.8.2 Geospatial sensitivity shall govern masking, aggregation, delay, access restriction, public-safe map publishing, secure-room handling, correction, and archive.

### 4.5.9 Public Authority Class.

4.5.9.1 The Public Authority Class shall identify whether work is unrelated to public authorities, public authority learning only, public authority-sensitive, public authority-dependent, official-action-dependent, public finance-dependent, permitting-dependent, public warning-dependent, emergency-command-dependent, or otherwise within a public authority boundary.

4.5.9.2 Public Authority classification shall prevent learning, evidence, Studio demonstration, Report publication, Registry status, Marketplace listing, Grid input, TRL note, Nexus Universe presentation, or handoff package from being overstated as public authority approval or action.

### 4.5.10 Finance, Insurance, and Procurement Boundary Class.

4.5.10.1 The Finance, Insurance, and Procurement Boundary Class shall identify whether work has no finance/procurement relevance, finance-readiness relevance, capital-reader relevance, insurance-readiness relevance, donor-readiness relevance, public finance relevance, diligence-gap relevance, procurement-neutrality relevance, provider-neutrality relevance, sponsor-boundary relevance, or regulated-perimeter risk.

4.5.10.2 This class shall require no-reliance, non-solicitation, non-transactional, procurement-neutrality, provider-neutrality, sponsor-boundary, and regulated-perimeter controls where applicable.

### 4.5.11 Handoff Class.

4.5.11.1 The Handoff Class shall identify whether work is not handoff-relevant, handoff-observable, handoff-context-candidate, handoff-review-needed, handoff-recipient-only, handoff-ready-within-scope, handoff-recalled, handoff-archived, or non-continuing.

4.5.11.2 Handoff classification shall govern dependency packaging, recipient responsibilities, public authority dependencies, finance and insurance questions, procurement boundaries, correction, recall, and archive.

### 4.5.12 Archive Class.

4.5.12.1 The Archive Class shall identify whether a record or object is active, superseded, withdrawn, recalled, deprecated, archived, sealed, restricted archive, public archive, historical reference only, non-continuing, or eligible for reinstatement review.

4.5.12.2 Archive classification shall prevent obsolete or withdrawn objects from being treated as current authority and shall preserve institutional memory with proper notices.

## 4.6 Backlog Architecture

### 4.6.1 Nexus Portfolio Backlog.

4.6.1.1 The Nexus Portfolio Backlog shall hold cross-Nexus work that affects multiple pillars, mechanisms, institutions, domains, countries, regions, technologies, or public-good systems. It shall organize strategic priorities, global public-good outputs, system-wide dependencies, Nexus Universe priorities, shared standards-interface issues, public-good software needs, correction priorities, and handoff architecture needs.

### 4.6.2 National Portfolio Backlog.

4.6.2.1 The National Portfolio Backlog shall hold country-level work, including national risk maps, challenge briefs, Working Group outputs, Competence Cell tasks, national Academy needs, national Campaigns, DRI and Observatory inputs, public authority learning needs, safeguard issues, national Registry and Marketplace objects, Nexus Universe preparation, and handoff dependency items.

### 4.6.3 Foundry Backlog.

4.6.3.1 The Foundry Backlog shall hold quests, bounties, builds, public-good software objects, data builds, dashboard builds, Studio workflow builds, Registry builds, Marketplace builds, Reports builds, Grid inputs, TRL notes, National Portfolio builds, Campaign builds, and handoff dependency builds.

### 4.6.4 Campaign Backlog.

4.6.4.1 The Campaign Backlog shall hold Campaign concepts, public-safe messaging, support records, volunteer tasks, team and chapter tasks, ambassador tasks, pledge tools, signature tools, Campaign dashboards, Campaign-to-Academy routing, Campaign-to-Foundry routing, Campaign-to-Universe routing, trust and safety tasks, fraud controls, correction tasks, and archive tasks.

### 4.6.5 Academy Backlog.

4.6.5.1 The Academy Backlog shall hold Nexus Academy and Risk Academy learning objects, modules, WILPs, micro-credentials where applicable, learner pathways, mentor assignments, public authority learning materials, public-safe reporting training, data and AI training, cyber training, safeguard training, and handoff literacy training.

### 4.6.6 Labs Backlog.

4.6.6.1 The Labs Backlog shall hold research questions, methods, testbeds, data studies, model studies, simulations, benchmark work, public-safe publication candidates, research-to-Foundry transfers, research-to-Reports transfers, and research-to-handoff context items.

### 4.6.7 Risk Agency Backlog.

4.6.7.1 The Risk Agency Backlog shall hold expert routing requests, advisory support, resilience consulting support, public-safe reporting support, public authority learning support, finance-readiness support, insurance-readiness support, safeguard support, workshop records, and handoff support tasks.

### 4.6.8 Reports Backlog.

4.6.8.1 The Reports Backlog shall hold report concepts, evidence assembly, drafting, review, public-safe transformation, metadata preparation, repository preparation, publication, distribution, correction, withdrawal, archive, and non-continuation tasks.

### 4.6.9 Marketplace Backlog.

4.6.9.1 The Marketplace Backlog shall hold listing candidates, metadata reviews, public-safe reviews, license reviews, support class reviews, provider-neutrality reviews, sponsor-boundary reviews, procurement-neutrality reviews, finance-boundary reviews, listing corrections, delisting, and archive tasks.

### 4.6.10 Registry Backlog.

4.6.10.1 The Registry Backlog shall hold object records, status records, version records, review records, data-use records, AI-use records, support records, provider contribution records, sponsor support records, public authority participation records, correction records, withdrawal records, recall records, archive records, and non-continuation records.

### 4.6.11 Studio Backlog.

4.6.11.1 The Studio Backlog shall hold dashboard workflows, digital twin workflows, scenario workflows, AI workflow reviews, data-room workflows, secure-room workflows, public authority learning workflows, readiness-room workflows, capital-reader workflows, insurance-reader workflows, Nexus Universe workflows, handoff demonstrations, shutdown tasks, correction tasks, and archive tasks.

### 4.6.12 Grid and TRL Backlog.

4.6.12.1 The Grid and TRL Backlog shall hold readiness inputs, evidence sufficiency reviews, method quality reviews, data status reviews, AI-use status reviews, cyber status reviews, public-safe status reviews, safeguard status reviews, support status reviews, repository status reviews, Marketplace status reviews, Registry status reviews, handoff dependency status reviews, downgrade, suspension, withdrawal, reinstatement, and correction tasks.

### 4.6.13 DICE, GRIx, DRI, and Observatory Backlog.

4.6.13.1 The DICE, GRIx, DRI, and Observatory Backlog shall hold data commons tasks, metadata tasks, data-use label tasks, AI-use label tasks, ontology tasks, controlled vocabulary tasks, DRI indicator tasks, signal records, dashboard records, hotspot records, cascade records, sensor records, geospatial records, Earth observation records, public-safe intelligence summaries, and correction tasks.

### 4.6.14 Handoff Backlog.

4.6.14.1 The Handoff Backlog shall hold handoff candidate records, recipient classification, evidence package assembly, dependency register completion, public authority dependency review, legal dependency review, finance and insurance question review, procurement-neutrality review, provider-neutrality review, sponsor-boundary review, safeguard review, handoff release, recall, correction, and archive tasks.

### 4.6.15 Correction Backlog.

4.6.15.1 The Correction Backlog shall hold all correction, containment, claims freeze, data freeze, technical freeze, model freeze, API freeze, delisting, Registry status update, Report erratum, Studio restriction, Grid downgrade, TRL correction, Campaign correction, handoff recall, withdrawal, archive, reinstatement, and public repair work.

## 4.7 Flow Governance

### 4.7.1 Work-in-Progress Limits.

4.7.1.1 NAF shall apply work-in-progress limits to preserve quality, review capacity, public-safe discipline, correction capacity, national routing, and safeguard integrity. Work-in-progress limits shall prevent uncontrolled proliferation of Docket items, builds, reports, campaigns, listings, reviews, Studio workflows, Grid inputs, TRL notes, or handoff packages.

4.7.1.2 Work-in-progress limits may be set by Docket, pathway, steward, team, Working Group, Competence Cell, release class, risk class, review type, or national portfolio. Exceeding limits shall trigger queue review, prioritization, additional resourcing, deferral, non-continuation, or archive.

### 4.7.2 Queue Discipline.

4.7.2.1 Queue discipline shall govern how work waits, advances, pauses, escalates, or exits. Queues shall be transparent to authorized participants, status-labeled, priority-labeled, dependency-aware, and correction-aware.

4.7.2.2 Queue status shall include new, awaiting classification, awaiting review, blocked, in progress, awaiting evidence, awaiting public-safe review, awaiting safeguard review, awaiting data review, awaiting AI review, awaiting cyber review, awaiting public authority boundary review, awaiting finance/procurement boundary review, awaiting release, awaiting routing, awaiting correction, archived, or non-continuing.

### 4.7.3 Dependency Mapping.

4.7.3.1 Dependency mapping shall identify what a Docket item needs before it can move safely. Dependencies may include evidence, data rights, model review, public-safe review, public authority action, safeguard review, community process, Indigenous protocol process where applicable, standards-interface review, cyber review, finance-readiness review, insurance-readiness review, procurement-neutrality review, provider-neutrality review, sponsor-boundary review, support resources, or lawful recipient review.

4.7.3.2 Dependency mapping shall be recorded and updated throughout the lifecycle. Unresolved dependencies shall prevent overclaim and may prevent release, routing, Nexus Universe presentation, or handoff.

### 4.7.4 Assumption Mapping.

4.7.4.1 Assumption mapping shall identify the assumptions underlying work, evidence, models, scenarios, digital twins, forecasts, dashboards, National Portfolios, finance-readiness questions, insurance-readiness questions, public authority learning records, Grid inputs, TRL notes, and handoff packages.

4.7.4.2 Assumptions shall be recorded, reviewed, limited, and corrected where needed. Material assumptions shall be visible in outputs that depend on them.

### 4.7.5 Bottleneck Identification.

4.7.5.1 Bottleneck identification shall detect where NAF work is slowed, blocked, overloaded, or degraded. Bottlenecks may arise from evidence gaps, review scarcity, data permissions, AI governance, cyber review, privacy review, safeguard review, public authority dependency, national routing, standards-interface complexity, sponsor/provider conflict, release review, correction backlog, or handoff dependency.

4.7.5.2 Bottleneck records shall identify cause, affected items, risk level, public-safe impact, proposed remedy, responsible steward, timeline where applicable, and correction implications.

### 4.7.6 Risk-Adjusted Prioritization.

4.7.6.1 Risk-adjusted prioritization shall rank work by public-good value, risk reduction potential, urgency, evidence readiness, national relevance, safeguard status, public authority learning need, technology relevance, feasibility, support class, handoff dependency clarity, correction sensitivity, and system-wide leverage.

4.7.6.2 Prioritization shall not be driven by sponsor influence, provider interest, capital-reader interest, media attention, political pressure, or enterprise demand unless such factors are recorded only as signals and subordinated to public-good discipline.

### 4.7.7 Public-Safe Release Windows.

4.7.7.1 Public-safe release windows shall govern when and how outputs may be released to public or controlled public audiences. Release timing shall consider evidence sufficiency, public-safe language, public authority dependencies, disaster-risk communication risks, sensitive data, geospatial sensitivity, protected knowledge, community safeguards, cyber risks, AI risks, and correction readiness.

4.7.7.2 Public-safe release windows may be paused or closed where a release could cause confusion, panic, misuse, overclaim, protected knowledge exposure, public authority boundary breach, finance/procurement boundary breach, or unsafe reliance.

### 4.7.8 National Routing Gates.

4.7.8.1 National routing gates shall ensure that country-level work is reviewed through appropriate national pathways before public release, Nexus Universe presentation, national Marketplace listing, national Registry status, public authority learning, or lawful handoff. National routing gates shall protect national ownership, localization, public authority boundaries, community safeguards, Indigenous protocols where applicable, data sovereignty, and lawful national context.

4.7.8.2 National routing gates shall not create government approval by default. They ensure country-context review and routing discipline.

### 4.7.9 Correction Priority Override.

4.7.9.1 Correction priority override shall allow correction work to supersede ordinary work when trust, safety, legality, public-safe status, data rights, AI governance, cyber safety, protected knowledge, public authority boundaries, finance/procurement boundaries, sponsor/provider boundaries, consent boundaries, handoff boundaries, or execution boundaries are at risk.

4.7.9.2 Correction priority override may pause related work, block releases, delist Marketplace objects, update Registry status, restrict Studio workflows, downgrade Grid inputs, correct TRL notes, recall handoff packages, freeze Campaign claims, or archive outputs.

### 4.7.10 Archive and Non-Continuation Flow.

4.7.10.1 Archive and Non-Continuation Flow shall ensure that work exits NAF pathways cleanly where it is complete, inactive, superseded, withdrawn, recalled, deprecated, unsafe to continue, no longer relevant, unsupported, or intentionally not continued.

4.7.10.2 Exit records shall identify reason, final status, successor link, public-safe status, support status, correction history, downstream dependencies, archive access class, and permitted future use. Exit shall not erase accountability.

## 4.8 Definition of Ready

### 4.8.1 Purpose Recorded.

4.8.1.1 A Docket item shall not be Ready unless its purpose is recorded. The purpose shall identify why the work exists, what public-good need it serves, what risk, innovation, evidence, learning, readiness, public authority, Campaign, National Portfolio, Nexus Universe, or handoff issue it addresses, and what outcome is sought within scope.

### 4.8.2 Scope Recorded.

4.8.2.1 A Docket item shall not be Ready unless its scope is recorded. Scope shall state what is included, what is excluded, applicable geography, sector, technology, hazard, system, audience, release expectation, and handoff relevance. Scope shall prevent overclaim and uncontrolled expansion.

### 4.8.3 Source Class Recorded.

4.8.3.1 A Docket item shall not be Ready unless its source class is recorded. Source class shall identify whether the item arose from public authority input, community input, Indigenous protocol-sensitive input where applicable, research, data, Observatory signal, DRI indicator, Campaign, Academy, Foundry, Reports, Marketplace, Registry, Studio, Grid, Nexus Universe, National Portfolio, provider, sponsor, capital reader, insurer, donor, or lawful recipient.

### 4.8.4 Data and AI Labels Recorded.

4.8.4.1 A Docket item shall not be Ready where data or AI are involved unless data-use and AI-use labels are recorded. Labels shall identify access class, sensitivity, permitted use, prohibited use, AI restrictions, training restrictions, agentic restrictions, secure-room needs, compute-to-data needs, public-safe output rules, and correction pathway.

### 4.8.5 Public-Safe Status Recorded.

4.8.5.1 A Docket item shall not be Ready unless public-safe status is recorded. Public-safe status shall identify whether the item is internal, controlled, public-safe summary, controlled public, open public, data-room-only, secure-room-only, Studio-only, handoff-recipient-only, archived, or non-continuing.

### 4.8.6 Safeguard Status Recorded.

4.8.6.1 A Docket item shall not be Ready unless safeguard status is recorded where relevant. Safeguard status shall identify community concerns, Indigenous protocols where applicable, protected knowledge, youth safeguards, accessibility, disability inclusion, humanitarian sensitivity, rights concerns, conflict sensitivity, and community-facing correction needs.

### 4.8.7 National Routing Recorded.

4.8.7.1 A Docket item shall not be Ready where national relevance exists unless national routing is recorded. National routing shall identify relevant national pathway, National Nexus Consortium, National Council, National Working Group, Competence Cell, National Node, National Portfolio, public authority learning pathway, community safeguard pathway, or lawful handoff pathway where applicable.

### 4.8.8 Review Needs Recorded.

4.8.8.1 A Docket item shall not be Ready unless review needs are recorded. Review needs may include evidence, method, data, AI, cyber, privacy, public-safe, safeguard, geospatial, public authority boundary, finance/insurance/procurement boundary, standards-interface, Marketplace, Registry, Studio, Grid, TRL, Reports, or handoff review.

### 4.8.9 Support Class Recorded.

4.8.9.1 A Docket item shall not be Ready unless support class is recorded where support is relevant. Support class shall identify whether the output will be unsupported, community-supported, maintainer-supported, Academy-supported, Foundry-supported, National Node-supported, Studio-supported, handoff-recipient-supported, time-limited supported, or archived.

### 4.8.10 Boundary Notices Recorded.

4.8.10.1 A Docket item shall not be Ready unless required boundary notices are recorded. Boundary notices may include no-certification, no-warranty, no-procurement, no-finance, no-insurance, no-public-authority, no-consent, no-deployment, no-execution, no-standards-authority, no-warning, provider-neutrality, sponsor-boundary, data-use, AI-use, public-safe reporting, handoff-context, correction, and archive notices.

## 4.9 Definition of Done

### 4.9.1 Evidence Completed Within Scope.

4.9.1.1 A Docket item shall not be Done unless evidence required for the approved scope is completed or the record expressly states that evidence is incomplete and the item is being closed, archived, corrected, or marked non-continuing. Evidence shall be linked to source, method, assumptions, limitations, review status, and correction pathway.

### 4.9.2 Method Note Completed.

4.9.2.1 A Docket item shall not be Done where methods matter unless a Method Note is completed. The Method Note shall identify method, rationale, data basis, model basis where applicable, limitations, reproducibility, uncertainty, confidence where applicable, standards-interface relevance, and correction pathway.

### 4.9.3 Data, AI, Cyber, Privacy, and Safeguard Review Completed Where Applicable.

4.9.3.1 A Docket item shall not be Done where data, AI, cyber, privacy, or safeguards are implicated unless required reviews are completed, deferred with recorded justification, or the item is restricted, archived, withdrawn, or marked non-continuing. Reviews shall be recorded by scope and shall not be overstated as certification or approval.

### 4.9.4 Registry Status Prepared.

4.9.4.1 A Docket item shall not be Done where lifecycle status matters unless Registry status is prepared or a recorded reason explains why Registry entry is not required. Registry status shall reflect actual lifecycle state, review status, support status, release class, correction pathway, and archive rule.

### 4.9.5 Marketplace Metadata Prepared Where Applicable.

4.9.5.1 A Docket item shall not be Done where discovery is expected unless Marketplace metadata is prepared. Metadata shall include title, object class, description, version, steward, license or rights status, access class, support class, review status, Registry status where applicable, correction pathway, and boundary notices.

### 4.9.6 Report or Public-Safe Summary Prepared Where Applicable.

4.9.6.1 A Docket item shall not be Done where publication, communication, public authority learning, Nexus Universe presentation, Campaign visibility, or handoff context requires explanation unless a Report or public-safe summary is prepared. Such output shall include no-warning, no-approval, no-finance, no-procurement, no-certification, no-consent, no-deployment, and no-execution language where applicable.

### 4.9.7 Studio Workflow Closed or Archived.

4.9.7.1 A Docket item shall not be Done where Studio activity occurred unless the Studio workflow is closed, restricted, continued, corrected, or archived with records of access, outputs, logs, assumptions, data and AI controls, public-safe status, shutdown triggers if any, correction actions, and archive rule.

### 4.9.8 Grid or TRL Input Prepared Where Applicable.

4.9.8.1 A Docket item shall not be Done where readiness classification is relevant unless Grid input or TRL evidence note is prepared or a recorded reason states why readiness input is inappropriate. Grid and TRL records shall be bounded and shall not imply certification, procurement readiness, financeability, insurability, public authority approval, or deployment authorization.

### 4.9.9 Correction Pathway Recorded.

4.9.9.1 A Docket item shall not be Done unless a correction pathway is recorded. The correction pathway shall identify who may raise a correction, where correction is filed, how correction is reviewed, what downstream objects may be affected, what public-safe notice may be required, and how archive or recall is handled.

### 4.9.10 Archive, Renewal, and Non-Continuation Rules Recorded.

4.9.10.1 A Docket item shall not be Done unless archive, renewal, and non-continuation rules are recorded. These rules shall identify whether the output expires, requires renewal, remains supported, becomes unsupported, requires periodic review, may be archived, may be sealed, may be deleted, may be superseded, or may be marked non-continuing.

## 4.10 Release Classes

### 4.10.1 Draft.

4.10.1.1 Draft release class shall apply to work that is incomplete, unreviewed, under development, or not yet suitable for reliance, public distribution, Marketplace listing, Registry status beyond draft, Nexus Universe presentation, Grid input, TRL note, or handoff. Draft materials shall carry draft notices and shall not be represented as final, reviewed, approved, or ready.

### 4.10.2 Internal Review.

4.10.2.1 Internal Review release class shall apply to materials circulated within authorized Nexus review environments for evidence, method, data, AI, cyber, privacy, public-safe, safeguard, standards-interface, public authority boundary, finance/insurance/procurement boundary, Registry, Marketplace, Studio, Grid, TRL, Reports, or handoff review.

4.10.2.2 Internal Review materials shall not be externally represented as approved, certified, public-safe, finance-ready, procurement-ready, handoff-ready, or execution-ready.

### 4.10.3 Public-Safe Summary.

4.10.3.1 Public-Safe Summary release class shall apply to outputs transformed for public understanding while removing or controlling sensitive, uncertain, protected, operational, public authority-sensitive, finance-sensitive, procurement-sensitive, cyber-sensitive, geospatial-sensitive, or protected knowledge information.

4.10.3.2 A Public-Safe Summary shall carry boundary notices and shall not operate as public warning, approval, certification, finance advice, procurement recommendation, consent, or implementation instruction.

### 4.10.4 Controlled Public.

4.10.4.1 Controlled Public release class shall apply to outputs that may be publicly accessible with controls, notices, limited scope, restricted use, or public-safe framing. Controlled Public outputs may include Reports, dashboards, learning objects, Campaign materials, Marketplace listings, Registry records, or public-safe technical objects.

4.10.4.2 Controlled Public release shall preserve data-use, AI-use, license, support, public-safe, correction, and archive limitations.

### 4.10.5 Open Public.

4.10.5.1 Open Public release class shall apply to outputs that may be openly accessible because they have been reviewed and classified as safe for open release within scope. Open Public outputs may include public-good software, open technical baselines, public-safe datasets, Reports, learning objects, documentation, schemas, APIs, or public-safe summaries.

4.10.5.2 Open Public release shall not create warranty, unrestricted data rights, AI training permission, certification, procurement status, financeability, public authority approval, consent, deployment authorization, or execution.

### 4.10.6 Marketplace Candidate.

4.10.6.1 Marketplace Candidate release class shall apply to objects under review for discovery listing in Nexus Marketplace. Marketplace Candidate status shall require metadata preparation, public-safe review, license review, support class review, provider-neutrality review, sponsor-boundary review, procurement-neutrality review, finance-boundary review, Registry status where applicable, and correction pathway.

4.10.6.2 Marketplace Candidate status shall not imply listing approval, endorsement, procurement relevance, provider validation, or readiness.

### 4.10.7 Registry-Recorded.

4.10.7.1 Registry-Recorded release class shall apply to objects whose status has been recorded in Nexus Registry. Registry-Recorded status shall identify lifecycle state, version, review status, support class, release class, data-use label, AI-use label, correction pathway, and archive rule.

4.10.7.2 Registry-Recorded status shall not constitute certification, approval, compliance determination, financeability, procurement eligibility, provider validation, public authority action, deployment authorization, or execution.

### 4.10.8 Studio-Only.

4.10.8.1 Studio-Only release class shall apply to outputs that may be accessed only within Nexus Studio or a comparable controlled runtime environment. Studio-Only outputs may include dashboards, digital twins, simulations, AI workflows, scenarios, data visualizations, public authority learning workflows, readiness-room workflows, or handoff demonstrations.

4.10.8.2 Studio-Only release shall require access controls, no-write-back rules, no-command rules, output review, logging, shutdown triggers, correction triggers, and archive rules. It shall not create deployment authority.

### 4.10.9 Data-Room-Only.

4.10.9.1 Data-Room-Only release class shall apply to outputs or materials that may be accessed only within a governed data room. Data-room materials may include restricted data, metadata, diligence materials, public authority-sensitive records, finance-readiness materials, insurance-readiness materials, handoff-recipient records, or controlled evidence.

4.10.9.2 Data-room access shall not create data rights, unrestricted reuse, AI training permission, public authority approval, finance approval, insurance approval, procurement status, handoff permission, or execution authority.

### 4.10.10 Secure-Room-Only.

4.10.10.1 Secure-Room-Only release class shall apply to materials requiring heightened security controls, including sensitive data, protected knowledge, cyber-sensitive records, infrastructure-sensitive records, geospatial-sensitive records, health-sensitive records, youth data, public authority-sensitive records, or controlled AI workflows.

4.10.10.2 Secure-room materials shall be subject to approved users, no-download controls where appropriate, output review, logging, access recertification, incident response, sealing, correction, and archive. Secure-room access shall not imply approval or authorization beyond access.

### 4.10.11 Handoff-Recipient-Only.

4.10.11.1 Handoff-Recipient-Only release class shall apply to handoff packages or supporting materials that may be provided only to a defined lawful recipient or recipient class. Such materials shall include recipient responsibilities, no-reliance limits where applicable, public authority dependencies, finance and insurance questions, procurement boundaries, safeguard conditions, correction pathway, recall pathway, and archive rule.

4.10.11.2 Handoff-Recipient-Only release shall not transfer authority, approve implementation, finance a project, insure a risk, procure a supplier, certify a system, grant consent, authorize deployment, or execute work.

### 4.10.12 Archived.

4.10.12.1 Archived release class shall apply to objects preserved for historical, audit, learning, correction, legal, public-good memory, or institutional continuity purposes. Archived objects shall carry archive-not-current notices, access class, successor links, correction history, support status, license status, public-safe status, retention rule, and permitted historical use.

4.10.12.2 Archived status shall not be treated as current authority. Archived objects shall not be used as active guidance unless reinstated through recorded review.

### 4.10.13 Non-Continuing.

4.10.13.1 Non-Continuing release class shall apply to work that NAF has decided not to continue, whether because of evidence insufficiency, safety risk, safeguard concerns, data rights limitations, AI risk, cyber risk, lack of public-good fit, national routing issue, unresolved public authority dependency, finance or procurement boundary concern, sponsor/provider conflict, resource constraint, or changed priority.

4.10.13.2 Non-Continuing status shall be recorded with reason, affected records, public-safe notice where necessary, successor options where applicable, correction pathway, and archive rule. Non-Continuing status shall not erase the record; it shall preserve the decision and prevent false expectations.

4.10.13.3 The final lifecycle rule of Part IV is that NAF work shall move only through recorded signals, intake, triage, classification, Docketing, backlog formation, pathway selection, evidence assembly, review, release, routing, Nexus Universe presentation, national continuation, lawful handoff, correction, archive, or non-continuation, and no step in that lifecycle shall convert movement into certification, procurement, finance, insurance, public authority action, public warning, consent, deployment, 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/iv.-lifecycle.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.