# V. STACKS

Stacks define the Nexus architecture for public-good formation, enterprise execution, and One Rail governance. This page explains the public-good stack, enterprise stack, and common record rail for lawful handoff, digital public goods, public-safe reporting, and sovereign interoperability.

## 5.1 Public-Good Stack

### 5.1.1 Evidence and Methods

The Public-Good Stack begins with evidence and methods. Nexus Ecosystem treats evidence and methods as the first discipline of institutional trust because public-good infrastructure, systemic risk governance, public authority learning, finance-readiness, digital public goods, and lawful handoff cannot be built on assertion, visibility, urgency, reputation, sponsorship, provider contribution, or public-stage attention.

Evidence in the Public-Good Stack includes the records, sources, observations, datasets, model outputs, system cards, benchmark records, public authority learning inputs, community inputs where lawfully and safely handled, Indigenous protocol-sensitive inputs where applicable, technical logs, field information, research outputs, Observatory signals, DRI indicators, GRIx mappings, Studio outputs, Foundry outputs, Campaign records, Academy records, National Portfolio inputs, and prior Nexus records that support a claim, object, pathway, report, or handoff context.

Methods in the Public-Good Stack include the analytical, technical, computational, review, classification, public-safe, data-governance, AI-governance, observability, Studio, Grid, TRL, DRI, GRIx, DICE, Foundry, Academy, Campaign, reporting, and handoff methods used to produce, interpret, route, and correct Nexus outputs.

Evidence and methods require records. An evidence-bearing Nexus output should identify:

1. source context, including origin, version, provenance, access class, and limitations;
2. method context, including procedure, assumptions, parameters, workflow, review logic, and uncertainty treatment;
3. data-use context, including permissions, restrictions, sensitivity, privacy, sovereignty, protected knowledge, and public-safe release status;
4. AI-use context, including whether AI was used, how it was used, what controls applied, and what human review occurred;
5. review context, including reviewer class, scope, limitations, and outcome;
6. confidence and uncertainty, including what is known, what is unknown, and what must not be inferred;
7. correction pathway, including how the evidence or method may be updated, downgraded, withdrawn, recalled, superseded, archived, or marked non-continuing.

Evidence and methods do not create certification, public authority approval, procurement status, financeability, insurability, public warning, deployment authorization, consent, or execution authority. They create bounded public-good meaning. Their value lies in making Nexus outputs traceable, contestable, teachable, reviewable, correctable, and suitable for lawful downstream interpretation.

### 5.1.2 Research and Labs

Research and labs form the exploratory and applied knowledge layer of the Public-Good Stack. Through Nexus Labs, GCRI-supported public-good R\&D, university and research participation, Nexus Foundry experimentation, Studio workflows, Observatory methods, DICE object work, GRIx taxonomy development, DRI intelligence methods, and Academy learning pathways, Nexus converts questions into structured inquiry and inquiry into governed public-good objects.

Research and labs may support:

1. applied research on systemic risk, DRR, DRF, DRI, WFEH-B systems, infrastructure resilience, climate and nature risk, data governance, AI governance, cyber risk, digital public goods, public authority learning, human capability, and lawful handoff;
2. technical prototyping, including dashboards, APIs, schemas, connectors, data products, notebooks, models, digital twins, simulations, and public-good software;
3. method development, including evidence-pack methods, observability methods, public-safe reporting methods, Studio methods, DICE methods, GRIx methods, DRI methods, Grid and TRL methods, and handoff methods;
4. controlled experimentation, including secure-room analysis, compute-to-data workflows, clean rooms, data rooms, AI workflow review, benchmark testing, and public-safe transformation;
5. learning conversion, including research-to-Academy pathways, Risk Academy modules, micro-credential inputs, WILP opportunities, contributor records, and reviewer pathways.

Research and labs do not authorize deployment. A prototype is not a product approval. A lab result is not certification. A simulation is not official forecast. A benchmark is not universal validation. A public-good R\&D output is not procurement readiness, financeability, insurability, public authority action, consent, or execution authority.

Research and labs must remain record-bearing and correctionable. Their outputs should include scope, assumptions, limitations, method notes, evidence records, data-use records, AI-use records, review status, support status, public-safe release status, correction pathway, and archive treatment. The Public-Good Stack uses labs to learn rigorously, not to overclaim early-stage outputs.

### 5.1.3 Digital Public Goods

Digital public goods are the reusable digital object layer of the Public-Good Stack. They include software, data products, metadata, schemas, APIs, ontologies, models, AI workflows, dashboards, digital twins, simulations, notebooks, reports, learning objects, credential objects, Campaign objects, DICE objects, GRIx mappings, DRI indicators, Studio workflows, Grid inputs, TRL records, Registry records, Marketplace listings, National Portfolio objects, Nexus Universe outputs, and handoff-context objects.

A Nexus digital public good is not merely digital content. It is a governed object with identity, provenance, purpose, scope, access class, support status, data-use context, AI-use context, review status, public-safe status, correction pathway, and archive rule. It may be open, controlled, restricted, secure-room-only, data-room-only, compute-to-data-only, handoff-recipient-only, national-node-only, archive-only, or non-continuing depending on rights, safety, sensitivity, support, and public-good purpose.

Digital public goods may support:

1. public-good software and open technical baselines;
2. national and regional data commons where lawful;
3. model commons and AI-governance objects;
4. DICE-controlled digital object governance;
5. GRIx semantic interoperability;
6. DRI and Observatory risk-intelligence objects;
7. Studio workflows and controlled runtime demonstrations;
8. Academy and Risk Academy learning objects;
9. Reports and public-safe knowledge products;
10. Marketplace discovery and Registry status truth;
11. Grid and TRL readiness records;
12. National Portfolio continuity;
13. Nexus Universe annual surge outputs;
14. lawful handoff packages.

Digital public goods are not automatically open, production-ready, warranty-backed, AI-trainable, commercializable, deployable, procured, certified, financeable, insurable, or execution-ready. Their public-good character depends on governance, not unrestricted release. The Public-Good Stack makes digital objects reusable where safe, controlled where necessary, restricted where required, and correctable throughout their lifecycle.

### 5.1.4 Learning and Capability

Learning and capability are core functions of the Public-Good Stack. Nexus Ecosystem treats capability formation as public-good infrastructure because systemic risk and exponential technology cannot be addressed only through reports, projects, tools, or finance. Countries, institutions, communities, public authorities, learners, workers, providers, sponsors, universities, civil society, insurers, donors, and lawful downstream actors require structured capability to interpret, use, review, correct, and responsibly hand off Nexus outputs.

Learning and capability are supported through Nexus Academy, Risk Academy, National Nodes, National Working Groups, Nexus Competence Cells, Nexus Foundry, Nexus Campaigns, Nexus Universe, WILPs, Integrated Learning Accounts, iCRS contribution records, micro-credentials, mentor pathways, reviewer pathways, maintainer pathways, public authority learning rooms, community-facing materials, and national skills intelligence.

Learning and capability may include:

1. Nexus doctrine and no-conversion literacy;
2. evidence and methods literacy;
3. DICE, GRIx, DRI, Observatory, Studio, Grid, TRL, Marketplace, Registry, Foundry, Campaign, Reports, and Nexus Universe literacy;
4. DRR, DRF, DRI, WFEH-B, climate, nature, infrastructure, AI, cyber, privacy, data, and digital public-good literacy;
5. public authority learning without substitution;
6. finance-readiness, insurance-readiness, donor-readiness, and public finance learning without finance execution;
7. public-safe reporting and claims discipline;
8. safeguard, community, Indigenous protocol where applicable, accessibility, and protected knowledge literacy;
9. lawful handoff and recipient responsibility literacy.

Learning records do not create professional licensing, employment entitlement, wage promise, immigration status, public authority status, procurement qualification, financeability, insurability, certification, consent, deployment authorization, or execution authority. They record learning, contribution, participation, review, or capability within defined scope.

The Public-Good Stack builds capability so that downstream actors are better prepared to decide under their own authority. It does not decide for them.

### 5.1.5 Campaign Mobilization

Campaign mobilization is the public-good participation and activation layer of the Public-Good Stack. Nexus Campaigns convert selected risks, public-good needs, national priorities, learning opportunities, Foundry opportunities, public-safe reports, DRI signals, Observatory insights, community concerns, Nexus Universe preparation needs, and lawful handoff awareness issues into structured mobilization pathways.

Campaign mobilization may include:

1. signatures, pledges, support expressions, volunteer pathways, chapters, ambassadors, teams, and public-good contribution pathways;
2. quests, bounties, builds, challenge pathways, and Foundry-linked production;
3. Campaign dashboards, public-safe summaries, learning tracks, Academy conversions, and Nexus Universe activation;
4. community-facing materials, youth and student pathways, accessibility pathways, and public-interest participation;
5. sponsor support records, provider contribution records, support ledgers, trust and safety controls, moderation controls, public-safe release controls, correction pathways, withdrawal pathways, and archive.

Campaign mobilization creates attention and participation. It does not create mandate. A campaign does not approve policy, procure providers, finance projects, insure risks, certify technologies, authorize deployment, issue public warnings, grant community consent, grant Indigenous consent where applicable, or execute projects.

Campaigns must avoid converting public support into authority. A signature is not a public vote. A pledge is not finance. A donation is not control. A sponsor is not owner. A provider is not validated. A community participant has not consented. A public authority observing a campaign has not acted.

The Public-Good Stack uses Campaigns to mobilize capability, not to manufacture legitimacy. Campaign legitimacy comes from records, public-safe language, inclusion, moderation, correction, and disciplined no-conversion boundaries.

### 5.1.6 Public-Safe Reporting

Public-safe reporting is the communication and publication layer of the Public-Good Stack. It allows Nexus Ecosystem to communicate evidence, risk intelligence, learning, public-good outputs, Observatory signals, DRI outputs, GRIx mappings, DICE objects, Foundry outputs, Campaign records, Academy materials, Studio summaries, Grid and TRL context, Marketplace and Registry status, National Portfolio objects, Nexus Universe outputs, and lawful handoff lessons without creating false authority or unsafe reliance.

Public-safe reporting may include public reports, technical reports, national reports, public-safe summaries, correction notices, archive reports, public-facing dashboards, issue briefs, media explainers, community-facing summaries, public authority learning summaries, finance-readiness boundary summaries, and handoff context notes.

Public-safe reporting should distinguish:

1. evidence from approval;
2. intelligence from public warning;
3. scenario from forecast certainty;
4. dashboard from decision;
5. Registry status from certification;
6. Marketplace listing from procurement;
7. readiness context from financeability;
8. insurance-readiness from underwriting;
9. donor-readiness from commitment;
10. public authority learning from public authority action;
11. participation from consent;
12. handoff context from execution.

Public-safe reporting must carry evidence context, uncertainty, limitations, public-safe status, data-use boundaries, AI-use boundaries, sensitivity controls, review status, support status, correction pathway, and archive treatment where relevant.

A Nexus Report is not a public warning, emergency alert, regulatory notice, procurement approval, finance approval, insurance approval, certification, consent record, deployment authorization, or execution instruction by default. Public-safe reporting is powerful because it speaks clearly while refusing to overclaim.

### 5.1.7 Registry and Marketplace

The Registry and Marketplace are the status-truth and discovery surfaces of the Public-Good Stack. Together, they allow Nexus objects to be findable and understandable without turning visibility into approval.

Nexus Registry records status truth. It identifies object identity, version, steward, support class, review state, access class, public-safe status, correction history, withdrawal, recall, supersession, archive, and non-continuation. Registry status tells the ecosystem what a record says and what state it holds. It does not certify.

Nexus Marketplace enables discovery. It allows approved-for-discovery public-good objects, reports, learning materials, software, datasets, dashboards, Studio workflows, Campaign objects, Foundry outputs, National Portfolio objects, support opportunities, and handoff-context objects to be found under recorded metadata and boundary notices. Marketplace listing does not procure.

Registry and Marketplace functions should preserve:

1. object identity and provenance;
2. lifecycle state;
3. version and localization status;
4. access class;
5. support class;
6. review and public-safe status;
7. data-use and AI-use labels;
8. sponsor and provider boundary notes;
9. Registry-to-Marketplace alignment;
10. correction, delisting, withdrawal, recall, archive, and non-continuation pathways;
11. no-certification, no-procurement, no-finance, no-insurance, no-public-authority, no-consent, no-deployment, and no-execution notices.

The Public-Good Stack uses Registry and Marketplace to create structured visibility. Visibility helps participants learn, discover, reuse, review, and route objects. It does not create endorsement, procurement, certification, financeability, insurability, public authority approval, consent, deployment authorization, or execution authority.

### 5.1.8 Studio Demonstrations

Studio demonstrations are controlled workflow demonstrations within the Public-Good Stack. Through Nexus Studio, the ecosystem may demonstrate dashboards, digital twins, simulations, AI workflows, secure-room analysis, data-room workflows, compute-to-data outputs, public authority learning environments, readiness rooms, capital-reader rooms, insurance-reader rooms, donor-reader rooms, public finance learning rooms, Nexus Universe demonstrations, Foundry prototypes, and handoff-context workflows.

A Studio demonstration may show how an object works under recorded conditions. It may help participants understand assumptions, uncertainty, data inputs, model behavior, user roles, public-safe outputs, sensitivity, access limits, and handoff dependencies. It may support learning, review, public-safe reporting, Grid and TRL context, Academy materials, Reports, and lawful handoff preparation.

Studio demonstrations require:

1. workflow identity and purpose;
2. runtime environment;
3. data-use and AI-use records;
4. input and output records;
5. access controls and role permissions;
6. no-download, no-write-back, and no-command rules where required;
7. human review and output review;
8. uncertainty and confidence labels;
9. public-safe status;
10. correction, shutdown, recall, archive, and reinstatement rules.

A Studio demonstration is not deployment authorization. A simulation is not official forecast. A dashboard is not a public authority decision. A digital twin is not operational command. A capital-reader room is not investment advice. An insurance-reader room is not underwriting. A donor-reader room is not donor commitment. A public authority learning room is not public authority action.

The Public-Good Stack uses Studio to make complexity reviewable, not to authorize real-world operation.

### 5.1.9 Grid and TRL Readiness Inputs

Nexus Grid and TRL 1–10 readiness inputs provide the maturity, review-routing, evidence-sufficiency, support-status, and technical-readiness context of the Public-Good Stack. They help the ecosystem understand where an object sits in its lifecycle, what evidence exists, what review is needed, what support class applies, what limitations remain, and what dependencies must be addressed before further routing, release, Nexus Universe presentation, Marketplace listing, Registry update, or lawful handoff.

Grid and TRL readiness inputs may address:

1. evidence readiness;
2. data readiness;
3. AI-use readiness;
4. method readiness;
5. technical maturity;
6. software support state;
7. cybersecurity and privacy readiness;
8. public-safe readiness;
9. safeguard readiness;
10. Academy readiness;
11. Campaign readiness;
12. Studio readiness;
13. Marketplace and Registry readiness;
14. Nexus Universe readiness;
15. handoff dependency readiness.

Grid and TRL records do not create certification, financeability, bankability, insurability, procurement status, public authority approval, safety approval, consent, deployment authorization, or execution authority. They classify and route readiness within Nexus. They do not decide for regulators, certifiers, investors, insurers, donors, public authorities, procuring bodies, communities, Indigenous institutions where applicable, or operators.

The Public-Good Stack uses Grid and TRL to avoid vague maturity claims. Readiness is recorded so that it can be reviewed, corrected, downgraded, suspended, withdrawn, recalled, archived, or marked non-continuing.

### 5.1.10 Observatory and DRI Signals

Nexus Observatory and DRI signals form the risk-intelligence and observability layer of the Public-Good Stack. They help Nexus identify, structure, interpret, and communicate signals related to systemic risk, disaster risk, WFEH-B systems, infrastructure stress, climate and nature risk, cyber-physical risk, public authority learning needs, national portfolio conditions, and resilience opportunities.

Observatory and DRI signals may include:

1. hazard, exposure, vulnerability, and capacity indicators;
2. DRI indicators and resilience-intelligence outputs;
3. GRIx mappings and risk taxonomy relationships;
4. digital twin and scenario outputs;
5. geospatial and Earth observation signals;
6. dashboard indicators;
7. hotspot and cascade records;
8. degraded-mode awareness records;
9. WFEH-B interdependency records;
10. public authority learning inputs;
11. National Portfolio risk context;
12. Studio workflow inputs;
13. Reports and public-safe summaries;
14. lawful handoff dependency notes.

Observatory and DRI signals must carry source context, method context, data-use records, AI-use records where applicable, uncertainty, confidence, sensitivity, public-safe status, review state, support class, national localization status, correction pathway, and archive rule.

A signal is not a warning. A dashboard is not a decision. A DRI output is not emergency command. An Observatory record is not official classification. A scenario is not forecast certainty. A risk-intelligence output is not insurance underwriting, investment rating, public finance allocation, procurement priority, consent, deployment authorization, or execution authority.

The Public-Good Stack uses Observatory and DRI signals to make risk more visible and teachable while preserving public-safe interpretation and authority boundaries.

### 5.1.11 National Portfolio Preparation

National Portfolio preparation is the country-level public-good planning, memory, and readiness function of the Public-Good Stack. It organizes national priorities, systems-risk maps, challenge briefs, evidence needs, DICE needs, GRIx mappings, DRI indicators, Observatory needs, Studio workflow candidates, Academy pathways, Campaign opportunities, Foundry outputs, Grid and TRL context, safeguard records, public authority learning questions, finance-readiness questions, Nexus Universe outputs, and handoff dependency records.

A National Portfolio may include:

1. National Context Records;
2. National Systems-Risk Maps;
3. National Challenge Briefs;
4. Evidence Need Records;
5. DICE and data-governance records;
6. GRIx and DRI localization records;
7. Observatory need records;
8. Studio workflow candidates;
9. Academy and Risk Academy needs;
10. Foundry build candidates;
11. Campaign candidates;
12. Grid and TRL records;
13. public authority learning records;
14. safeguard and accessibility records;
15. community and Indigenous protocol boundary records where applicable;
16. assumptions, dependency, and diligence-gap registers;
17. finance-readiness, insurance-readiness, donor-readiness, and public finance learning questions;
18. Nexus Universe preparation and output records;
19. lawful handoff dependency records;
20. correction and archive records.

National Portfolio preparation does not create national approval. It does not make an object a government decision, procurement package, financed project, insured project, certified technology, consented activity, deployment authorization, or execution mandate. It creates structured national context.

The Public-Good Stack uses National Portfolios to make countries better prepared for learning, annual surge, public-safe reporting, national continuation, and lawful handoff without bypassing national authority.

### 5.1.12 Handoff Context Preparation

Handoff context preparation is the boundary function through which the Public-Good Stack prepares materials for possible transfer to separate competent actors without transferring authority. It is the bridge between public-good formation and enterprise-stack evaluation.

A handoff context package may include:

1. object identity and version;
2. evidence records;
3. method records;
4. data-use records;
5. AI-use records;
6. review records;
7. support records;
8. public-safe status;
9. Marketplace relationship;
10. Registry status;
11. Studio records;
12. Grid and TRL context;
13. DICE, GRIx, DRI, and Observatory context;
14. National Portfolio context;
15. Nexus Universe output context;
16. assumptions registers;
17. dependency registers;
18. diligence-gap registers;
19. public authority dependency notes;
20. legal and procurement dependency notes;
21. finance, insurance, donor, and public finance questions;
22. safeguard records;
23. community and Indigenous consent boundaries where applicable;
24. recipient responsibility notes;
25. correction, recall, archive, and non-continuation pathways;
26. no-authority-transfer notices.

Handoff context preparation does not execute. It does not approve projects, select providers, allocate finance, underwrite insurance, approve donor funding, issue public authority action, grant community consent, grant Indigenous consent where applicable, authorize deployment, or create operational command.

The Public-Good Stack prepares context so that lawful recipients can make better decisions under their own authority. It transfers records, not rights; evidence, not approval; readiness questions, not finance; learning, not public authority action; dependencies, not implementation permission.

### 5.1.13 Public-Good Stack Boundaries

The Public-Good Stack boundaries preserve Nexus Ecosystem’s legitimacy. The Public-Good Stack may produce evidence, methods, research, digital public goods, learning, campaigns, reports, Registry status, Marketplace discovery, Studio demonstrations, Grid and TRL readiness inputs, Observatory and DRI signals, National Portfolio context, Nexus Universe outputs, and handoff packages. It does not execute by default.

The Public-Good Stack does not, by default:

1. act as a public authority;
2. issue public warnings;
3. command emergencies;
4. regulate or enforce;
5. certify technologies, providers, datasets, models, reports, systems, portfolios, or projects;
6. conduct procurement or approve suppliers;
7. provide investment advice;
8. determine financeability, bankability, valuation, rating, or transaction readiness;
9. underwrite insurance or determine insurability;
10. allocate donor funding or public finance;
11. grant community consent;
12. grant Indigenous consent where applicable;
13. authorize deployment;
14. operate systems;
15. construct, contract, deliver, or execute projects;
16. bind enterprise vehicles, public authorities, providers, sponsors, funders, insurers, donors, communities, Indigenous institutions, universities, or lawful downstream actors without separate authority.

These boundaries do not weaken the Public-Good Stack. They make it credible. The Public-Good Stack can move quickly, convene broadly, build openly where safe, control where necessary, restrict where required, report publicly where safe, and prepare handoff context because it does not pretend to hold every downstream authority.

Its final operating discipline is: public-good formation before execution; records before claims; evidence before legitimacy; legitimacy before readiness; readiness before handoff; handoff before separate lawful action; correction before trust; archive without current authority.

## 5.2 Enterprise Stack

### 5.2.1 National Consortium Companies

National Consortium Companies are country-level enterprise-stack vehicles within the Nexus stack architecture. They may receive Nexus public-good context and translate it into lawful enterprise preparation, project structuring, contracting capacity, implementation planning, provider coordination, finance and insurance engagement, operational readiness, and execution-capable activity where separately authorized. They sit outside the default Nexus Public-Good Stack and must remain legally, financially, operationally, and institutionally separate from National Nexus Consortiums, National Nodes, Councils, Working Groups, Competence Cells, GCRI, The Global Risks Forum (GRF), The Global Risks Alliance (GRA), Nexus pillar institutions, and public authorities unless a separate lawful instrument expressly provides otherwise.

A National Consortium Company may engage with National Portfolio objects, Nexus Universe outputs, Foundry builds, Studio workflows, Marketplace-discovered objects, Registry records, Grid and TRL context, DICE objects, GRIx mappings, DRI outputs, Observatory signals, Reports, Campaign outputs, Academy capability records, and lawful handoff packages. Its role is to evaluate and, where lawful, convert such context into enterprise workstreams, project vehicles, implementation plans, provider scopes, contractor scopes, finance and insurance processes, operating models, and delivery arrangements.

A National Consortium Company must preserve:

1. separate legal identity, including incorporation, governance, accounts, contracts, tax position, insurance, liabilities, employment, and reporting;
2. separate authority, including no implied power to bind Nexus public-good institutions, public authorities, National Councils, National Nodes, providers, sponsors, funders, insurers, donors, communities, or Indigenous institutions where applicable;
3. separate decision-making, including independent diligence, board or management approval, procurement or sourcing decisions, finance and insurance decisions, public authority applications, safeguard determinations, and operational responsibility;
4. separate communications, including clear distinction between Nexus public-good context and Company enterprise activity;
5. correction responsiveness, including capacity to receive, assess, propagate, suspend, recall, or archive affected uses of corrected Nexus materials.

A National Consortium Company does not inherit public-good authority. It does not become a public authority, certifier, procurement body, fund, insurer, underwriter, registry authority, marketplace authority, standards authority, public-warning body, or consent authority by receiving Nexus context. Its role is to provide a lawful enterprise interface, not to convert public-good handoff into execution by implication.

### 5.2.2 Project SPVs

Project SPVs are project-level lawful vehicles formed for specific implementation opportunities, assets, systems, platforms, corridors, infrastructure packages, technology deployments, resilience programs, digital public-good implementations, or continuation pathways. They are used where project-level separateness is necessary to hold project rights, obligations, finance, insurance, contracts, permits, safeguards, operational responsibilities, liabilities, and correction obligations.

A Project SPV may receive Nexus handoff context from National Portfolios, Nexus Foundry, Nexus Universe, Nexus Studio, Nexus Reports, Nexus Marketplace, Nexus Registry, Nexus Grid, DICE, GRIx, DRI, Nexus Observatory, National Nodes, National Working Groups, Competence Cells, or National Consortium Companies. Such context may include evidence records, method records, data-use records, AI-use records, public-safe status, Grid and TRL context, assumptions registers, dependency registers, diligence-gap registers, safeguard records, public authority dependency notes, finance and insurance questions, procurement boundaries, and correction pathways.

A Project SPV must independently establish:

1. legal formation and project purpose;
2. governance and signing authority;
3. project scope, delivery model, and operating model;
4. procurement or sourcing basis where required;
5. finance, insurance, donor, public finance, or guarantee arrangements where relevant;
6. public authority approvals, permits, licenses, notices, or authorizations where required;
7. technical validation, safety controls, cybersecurity controls, privacy controls, and AI-use controls;
8. environmental, social, accessibility, community, Indigenous protocol where applicable, and protected knowledge safeguards;
9. operational, maintenance, incident, correction, recall, and decommissioning responsibility.

A Project SPV does not become approved, financeable, insurable, procured, certified, consented, deployable, or execution-authorized because it received Nexus handoff context. It becomes execution-capable only to the extent it lawfully obtains the authority, resources, approvals, contracts, finance, insurance, safeguards, and operational capacity required for the project.

### 5.2.3 Providers

Providers are enterprise-stack actors that may supply technology, software, data, models, AI systems, APIs, dashboards, telecom services, cloud and compute services, equipment, infrastructure, engineering, cybersecurity, professional services, training, support, integration, documentation, or implementation-related capability. Providers may participate in both public-good and enterprise contexts, but their status must remain role-specific and record-bounded.

Within the Public-Good Stack, a provider may contribute to Foundry builds, Studio workflows, DICE objects, GRIx mappings, DRI tools, Observatory dashboards, Academy materials, Reports, Campaigns, Marketplace listings, Registry records, Working Groups, Competence Cells, Nexus Universe, or National Portfolio preparation. Such contribution must be recorded where material and does not validate the provider.

Within the Enterprise Stack, a provider may be selected, contracted, or engaged by a National Consortium Company, Project SPV, public authority acting separately, university, operator, funder, insurer, donor-supported program, community institution where appropriate, or other lawful actor. Such engagement must occur under the recipient’s own authority, procurement or sourcing rules, contracts, conflicts controls, technical criteria, due diligence, data-processing terms, cybersecurity obligations, privacy obligations, support obligations, and liability allocation.

Provider participation or contribution does not create:

1. preferred-provider status;
2. procurement recommendation;
3. Nexus certification;
4. public authority approval;
5. financeability or insurability;
6. safety approval;
7. deployment authorization;
8. execution authority;
9. community consent;
10. Indigenous consent where applicable.

Providers may strengthen Nexus and downstream implementation when their contributions are transparent, licensed, bounded, supportable, secure, correctionable, and free from overclaim. Provider value must never become provider capture.

### 5.2.4 Operators

Operators are enterprise-stack actors responsible for operating systems, assets, platforms, infrastructure, data environments, software services, dashboards, digital twins, AI-enabled workflows, facilities, networks, field deployments, resilience systems, or other implementation environments. Operators act under separate authority, contracts, permits, licenses, service obligations, safety responsibilities, cybersecurity obligations, privacy obligations, maintenance duties, continuity requirements, and liability frameworks.

An operator may receive Nexus context through a National Consortium Company, Project SPV, public authority acting separately, provider, university, laboratory, community institution where appropriate, or other lawful handoff recipient. Nexus context may support operator understanding of evidence, methods, data-use restrictions, AI-use restrictions, Studio workflow assumptions, DRI signals, GRIx mappings, Observatory outputs, Grid and TRL context, public-safe boundaries, support status, and correction pathways.

Operator responsibility remains independent. An operator must ensure:

1. operating authority;
2. safety and service continuity;
3. technical validation and operational readiness;
4. cybersecurity and privacy controls;
5. data governance and AI-use controls;
6. user protection and accessibility;
7. maintenance, monitoring, patching, and support;
8. incident response and business continuity;
9. public authority compliance where required;
10. correction, recall, rollback, shutdown, decommissioning, and archive procedures.

Nexus does not become an operator because it produced an object, report, Studio workflow, dashboard, DRI output, Registry record, Marketplace listing, Grid or TRL context, or handoff package. A Studio demonstration is not operational authorization. A dashboard is not command. A handoff package is not permission to operate.

### 5.2.5 Contractors

Contractors are enterprise-stack actors engaged under contract to perform defined services, deliverables, works, professional tasks, technical tasks, operational tasks, construction tasks, research support, software development, cybersecurity services, data services, communications support, logistics, translation, accessibility work, training, event support, maintenance, or other functions. Contractors act within the scope of the contract that engages them.

A contractor may serve a Nexus public-good institution, National Consortium Company, Project SPV, public authority acting separately, university, host, provider, donor-funded program, community institution where appropriate, or other lawful actor. The contractor’s obligations arise from its contract, applicable law, professional duties, confidentiality obligations, data-processing terms, cybersecurity requirements, intellectual property terms, safety requirements, and correction or incident duties.

Contractor status must be recorded where material. Contractor records should identify:

1. contracting party;
2. scope of work;
3. deliverables;
4. authority limits;
5. data, AI, privacy, cyber, and confidentiality obligations;
6. intellectual property and licensing treatment;
7. public-safe communications limits;
8. conflicts and independence;
9. support and maintenance obligations;
10. incident, correction, recall, and archive obligations;
11. no-conversion boundaries.

A contractor engaged for one Nexus-related task is not approved for all Nexus work. Contractor participation does not create certification, procurement preference, public authority status, financeability, insurability, deployment authorization, consent, or ecosystem-wide execution authority. Contracting creates obligations within scope; it does not create general Nexus authority.

### 5.2.6 Funders

Funders are enterprise-stack or support-stack actors that may provide financial resources through grants, donor instruments, public finance, development finance, research funding, philanthropic support, sponsorship, investment, loans, guarantees, blended-finance structures, project finance, operating support, or other lawful funding arrangements. The meaning of a funder’s role depends on the applicable instrument and the actor’s legal authority.

A funder may support public-good activity, enterprise-stack activity, or both, but the distinction must remain clear. Public-good funding supports public-good formation, records, learning, reports, digital public goods, campaigns, Studio workflows, Nexus Universe preparation, National Portfolio work, or handoff context without giving the funder control over evidence, claims, Registry status, Marketplace listing, public-safe reporting, correction, or archive. Enterprise funding supports separate implementation or project activity under enterprise authority and must not be represented as Nexus public-good approval.

Funding does not create:

1. public-good control;
2. public authority approval;
3. certification;
4. procurement status;
5. financeability for other actors;
6. donor commitment beyond the recorded instrument;
7. insurance approval;
8. community consent;
9. Indigenous consent where applicable;
10. deployment authorization;
11. execution authority beyond the funded actor’s lawful scope.

Funder records should identify funding source, purpose, restrictions, reporting obligations, independence safeguards, conflicts, public communications rules, no-reliance language, correction pathways, and termination or withdrawal conditions. Funding strengthens Nexus when it expands capability without capturing meaning.

### 5.2.7 Insurers

Insurers are enterprise-stack actors that may act separately as insurance readers, risk reviewers, coverage providers, reinsurers, brokers, risk engineers, catastrophe modelers, insurance advisers, public insurance actors, or other insurance-sector participants. Their participation in Nexus public-good pathways does not constitute underwriting. Their enterprise-stack role arises only when they act under their own insurance, reinsurance, brokerage, advisory, regulatory, contractual, or professional authority.

An insurer may review Nexus context, including DRI outputs, GRIx mappings, Observatory signals, Studio workflows, Reports, National Portfolio records, Grid and TRL context, assumptions registers, dependency registers, diligence-gap registers, safeguard records, and handoff packages. Such review may support insurance-readiness learning or downstream underwriting diligence. It does not bind coverage by default.

Insurance execution requires separate insurer action. Insurers and reinsurers remain responsible for their own:

1. underwriting criteria;
2. actuarial analysis;
3. regulatory obligations;
4. policy forms and terms;
5. pricing and premium decisions;
6. reinsurance and capital requirements;
7. claims procedures;
8. risk appetite;
9. data and model governance;
10. legal compliance and customer obligations.

Nexus does not become an insurer, reinsurer, broker, underwriter, claims handler, or risk carrier. Insurance-reader rooms, insurance-readiness notes, DRF literacy, DRI outputs, and handoff context may improve questions; they do not create coverage, insurability, premium indication, underwriting acceptance, reinsurance support, or insurance approval.

### 5.2.8 Public Authorities Acting Separately

Public authorities acting separately are public bodies, officials, ministries, agencies, municipalities, regulators, public utilities, emergency bodies, public finance institutions, intergovernmental bodies, or other competent public institutions acting under their own lawful authority outside Nexus’s default public authority learning posture.

A public authority may participate in Nexus as a learner, observer, Council participant, Studio participant, National Portfolio reader, Reports reader, Nexus Universe participant, public finance learning participant, or handoff recipient without acting officially. It acts separately only when it uses its own statutory, administrative, regulatory, procurement, public finance, emergency, permitting, licensing, policy, or other lawful procedures to make a decision or take action.

Public authority action may include:

1. permits, licenses, approvals, refusals, exemptions, notices, or authorizations;
2. procurement decisions, tenders, awards, contracts, or public-private partnership processes;
3. public finance allocations, grants, subsidies, guarantees, or budget decisions;
4. regulatory decisions, compliance findings, inspections, enforcement, or official classifications;
5. public warnings, emergency commands, disaster declarations, public health orders, or civil protection actions;
6. data-sharing approvals, public data access decisions, or sovereign data controls;
7. policy adoption, legislative processes, or administrative decisions.

Nexus context may inform public authority learning. It does not substitute for public authority procedure. A public authority’s attendance, question, comment, presence, or review inside Nexus does not create public authority action unless separately and lawfully recorded by that authority.

### 5.2.9 Universities and Labs Acting Separately

Universities and laboratories acting separately are academic, research, scientific, technical, testing, innovation, or laboratory institutions that engage outside Nexus’s default public-good participation posture under their own institutional authority, ethics frameworks, research governance, contracts, grants, data agreements, intellectual property policies, safety rules, professional standards, and legal obligations.

Universities and labs may act separately when they:

1. conduct research under their own protocols;
2. host data, software, labs, equipment, or facilities;
3. enter research agreements or service contracts;
4. receive grants or funding;
5. conduct testing, evaluation, or technical review under a defined scope;
6. support implementation through a separate contract;
7. host WILPs, student placements, or learning pathways;
8. receive Nexus handoff context for research continuation or technical evaluation;
9. manage data, AI systems, sensitive materials, or protected knowledge under their own institutional rules.

Academic or laboratory participation in Nexus does not create certification, professional licensing, public authority approval, procurement status, financeability, insurability, deployment authorization, consent, or execution authority by default. Where universities or labs provide regulated, certified, accredited, or formal testing services, that status must arise separately through the relevant authority, accreditation, contract, or legal instrument.

Universities and labs strengthen Nexus by improving evidence and capability. When acting separately, they must preserve data rights, ethics, research integrity, privacy, cybersecurity, AI-use controls, publication limits, sponsor and provider conflicts, protected knowledge restrictions, Indigenous protocols where applicable, correction obligations, and archive requirements.

### 5.2.10 Community Actors Where Appropriate

Community actors where appropriate may participate in the Enterprise Stack only where they have the relevant authority, capacity, consent basis, governance, safeguards, contracts, support, and accountability to act as lawful recipients, implementation partners, local stewards, operators, beneficiaries, co-design actors, monitoring actors, or project participants. Community participation in the Public-Good Stack does not automatically create enterprise-stack authority.

Community actors may include community organizations, cooperatives, local institutions, local businesses, civil society bodies, neighborhood groups, disability organizations, youth organizations with proper safeguards, humanitarian community actors, place-based institutions, Indigenous institutions where applicable, and other local or affected stakeholder bodies.

Community actors may act separately where they lawfully:

1. receive handoff context;
2. enter contracts;
3. host or operate local activities;
4. participate in implementation governance;
5. provide local monitoring or feedback;
6. manage community-controlled data or knowledge under proper authority;
7. support accessibility and inclusion;
8. participate in safeguard implementation;
9. receive funding or support under defined terms;
10. coordinate local continuation after Nexus Universe, Campaign, Foundry, or National Portfolio pathways.

Community participation is not consent. Community enterprise activity requires separate authority and, where required, separate consent. Indigenous institutions where applicable require specific respect for governance, protocols, rights, land and water relationships, protected knowledge, data sovereignty, consent, and legal requirements. Nexus must not impose implementation on communities, convert community participation into approval, or treat local presence as implementation mandate.

Community actors may be lawful enterprise-stack participants only when their role is recorded, supported, protected, non-extractive, and accountable.

### 5.2.11 Lawful Execution Outside Nexus Default Posture

Lawful execution outside Nexus default posture is the rule that execution occurs only when a separate competent actor acts under its own authority outside the default Nexus Public-Good Stack. Nexus may prepare records, evidence, methods, reports, learning, campaigns, Studio workflows, Registry records, Marketplace listings, Grid and TRL context, Observatory and DRI signals, National Portfolios, Nexus Universe outputs, and handoff packages. None of these executes a project.

Execution may include project development, procurement, contracting, construction, deployment, operation, maintenance, finance, investment, insurance, underwriting, donor funding, public finance allocation, regulatory approval, public authority action, community implementation, data system operation, software production release, infrastructure operation, service delivery, emergency command, or public warning. These activities require separate competent actors and lawful authority.

Lawful execution outside Nexus default posture requires, as applicable:

1. legal authority and governance;
2. contracts and procurement;
3. finance, insurance, donor, public finance, or guarantee arrangements;
4. public authority approvals, permits, licenses, notices, or authorizations;
5. technical validation, safety controls, cybersecurity, privacy, and AI-use controls;
6. data rights and data-governance compliance;
7. environmental and social safeguards;
8. community consent where required;
9. Indigenous consent, protocols, data sovereignty, rights, and protected knowledge controls where applicable;
10. operational capacity, maintenance, monitoring, incident response, correction, recall, and liability.

The Enterprise Stack exists so that execution can become accountable instead of implied. Handoff transfers context to actors capable of deciding and acting lawfully. It does not transfer Nexus authority.

### 5.2.12 Enterprise Stack Boundaries

The Enterprise Stack has strict boundaries. It may receive Nexus context, evaluate opportunities, structure projects, contract providers, engage funders, seek insurance, work with public authorities, operate systems, implement projects, or deliver services where separately authorized. It may not convert Nexus public-good records into approval, legitimacy, finance, insurance, certification, procurement, public authority action, consent, or execution rights beyond the authority it independently holds.

Enterprise-stack actors must not claim that Nexus has:

1. approved their project;
2. certified their technology;
3. selected their provider;
4. procured their services;
5. financed their activity;
6. insured or underwritten their risk;
7. endorsed their company;
8. granted public authority approval;
9. issued a public warning;
10. granted community consent;
11. granted Indigenous consent where applicable;
12. authorized deployment;
13. assumed operational responsibility;
14. guaranteed outcomes;
15. accepted liability.

Enterprise-stack actors must preserve Nexus boundary language in proposals, investor materials, insurance materials, donor materials, public authority submissions, procurement materials, community materials, Indigenous engagement materials where applicable, media materials, websites, presentations, contracts, and project documents where Nexus context is referenced.

The final rule of the Enterprise Stack is: enterprise actors may execute only what they are separately lawful, authorized, financed, insured, contracted, consented, safeguarded, and competent to execute. Nexus context may inform enterprise action; it does not authorize it.

## 5.3 One Rail

### 5.3.1 Common Record Rail

The One Rail begins as a common record rail. It is the shared record infrastructure and common governance rail through which Nexus Ecosystem gives identity, status, provenance, scope, limitations, support state, review state, public-safe meaning, handoff context, correction history, and archive treatment to objects and pathways across the Public-Good Stack and Enterprise Stack.

The common record rail prevents Nexus from becoming a collection of informal conversations, unbounded reports, promotional claims, disconnected platforms, untraceable files, unsupported dashboards, ungoverned AI outputs, and handoff ambiguity. It makes every material object and pathway answerable to a recorded basis.

The common record rail may carry:

1. Object Records, identifying what the object is, what version exists, who stewards it, what status applies, and how it may be used;
2. Evidence Records, identifying what supports the object or claim;
3. Method Records, identifying how the output was produced or interpreted;
4. Data-Use Records, identifying rights, restrictions, sensitivity, access, and public-safe conditions;
5. AI-Use Records, identifying whether and how AI was used, what controls applied, and what review occurred;
6. Review Records, identifying scope, reviewer class, review outcome, limits, and correction pathway;
7. Support Records, identifying whether the object is supported, unsupported, maintained, sponsor-supported without control, provider-supported without validation, deprecated, retired, archive-only, or non-continuing;
8. Participation Records, identifying who participated, in what role, and with what boundaries;
9. Public Authority Learning Records, identifying public authority learning without public authority action;
10. Sponsor Support Records, identifying support without control;
11. Provider Contribution Records, identifying contribution without validation;
12. Handoff Records, identifying context transfer without authority transfer;
13. Correction Records, identifying correction, downgrade, withdrawal, recall, public repair, or supersession;
14. Archive Records, preserving memory without current authority.

The common record rail does not approve, certify, procure, finance, insure, warn, deploy, consent, or execute. It makes meaning recordable. Its purpose is to ensure that Nexus status arises from records rather than assertion.

### 5.3.2 Docket Rail

The Docket rail is the pathway through which signals, needs, questions, proposals, risks, evidence gaps, public authority learning needs, national priorities, campaign opportunities, Foundry opportunities, Studio candidates, DRI indicators, GRIx mappings, Observatory signals, Academy needs, Grid and TRL questions, Marketplace candidates, Registry updates, Nexus Universe preparation items, and handoff dependencies become structured work items.

A Docket item is not a decision. It is a recorded matter requiring attention, routing, review, development, learning, correction, or handoff preparation. The Docket rail prevents issues from entering Nexus informally and later being mistaken for approved work, public authority action, procurement priority, finance-readiness determination, or execution pathway.

A Docket item should identify:

1. source, including Council, Working Group, Competence Cell, National Node, public authority learning pathway, community pathway, Campaign, Foundry, Academy, Studio, Observatory, DICE, GRIx, DRI, Nexus Universe, Marketplace, Registry, or lawful handoff recipient;
2. issue class, including evidence need, method need, data need, AI need, risk-intelligence need, public-safe reporting need, national portfolio need, campaign need, foundry build need, studio workflow need, grid or TRL review need, safeguard need, public authority learning need, finance-readiness question, insurance-readiness question, donor-readiness question, public finance learning question, or handoff dependency;
3. priority and urgency, including why the matter should move and what risk arises if it does not;
4. routing pathway, including whether the matter goes to Academy, Risk Academy, Foundry, Campaigns, Reports, DICE, GRIx, DRI, Observatory, Studio, Grid, Marketplace, Registry, Nexus Universe, National Node, Working Group, Competence Cell, Risk Agency, or lawful handoff preparation;
5. boundary notices, including what the Docket item does not approve, certify, finance, procure, insure, warn, consent to, deploy, or execute;
6. correction and closure state, including open, under review, routed, completed, suspended, withdrawn, archived, or non-continuing.

The Docket rail makes Nexus work governable before it becomes visible. It turns signals into structured responsibility without creating authority by implication.

### 5.3.3 Object Rail

The Object rail is the pathway through which Nexus materials become governed public-good or handoff-context objects. An object may begin as a file, dataset, dashboard, code repository, model, report draft, learning module, campaign page, Studio workflow, risk map, DRI indicator, GRIx mapping, National Portfolio item, Nexus Universe output, or handoff package. It becomes a Nexus object only when it is given recorded identity, status, scope, provenance, rights, review state, support state, public-safe status, correction pathway, and archive rule.

The Object rail applies to:

1. software and code repositories;
2. datasets, metadata, schemas, and data products;
3. models, AI workflows, system cards, model cards, and benchmark records;
4. APIs, connectors, dashboards, notebooks, and digital twins;
5. reports, public-safe summaries, and knowledge products;
6. learning objects, micro-credential objects, WILP objects, and Academy materials;
7. Campaign objects, pledge objects, support ledgers, and mobilization records;
8. DICE objects, GRIx mappings, DRI indicators, and Observatory objects;
9. Studio workflows, secure-room objects, data-room objects, and controlled-runtime outputs;
10. Grid inputs and TRL records;
11. Marketplace listings and Registry records;
12. National Portfolio objects and Nexus Universe outputs;
13. handoff packages, dependency records, and lawful recipient context objects.

The Object rail should preserve the distinction between object existence and object authority. An object may exist, be discoverable, be reviewed, be taught, be demonstrated, be classified, be localized, or be handed off. None of those states automatically creates certification, procurement, financeability, insurability, public authority action, consent, deployment authorization, or execution authority.

The Object rail gives Nexus durable infrastructure. It converts work into reusable, reviewable, supportable, correctable, and archivable objects without turning object status into approval.

### 5.3.4 Evidence Rail

The Evidence rail is the pathway through which Nexus claims, objects, reports, workflows, readiness notes, public-safe summaries, National Portfolio items, and handoff packages become tied to evidence records. It ensures that Nexus does not operate by assertion, branding, urgency, reputation, sponsorship, provider contribution, public authority presence, capital-reader interest, or media visibility.

The Evidence rail may carry:

1. source materials;
2. datasets and metadata;
3. observations and signal records;
4. research outputs;
5. public authority learning inputs;
6. community inputs where lawfully and safely handled;
7. Indigenous protocol-sensitive inputs where applicable and properly authorized;
8. model outputs and benchmark records;
9. system cards and model cards;
10. software logs and execution notes;
11. Studio workflow outputs;
12. DRI indicators and GRIx mappings;
13. Observatory signals;
14. review notes and limitation records;
15. confidence, uncertainty, and sensitivity labels.

The Evidence rail requires that evidence be contextualized. Evidence should be accompanied by source context, method context, data-use context, AI-use context where applicable, review status, limitations, public-safe status, support state, and correction pathway. Evidence that cannot be safely published may still exist in controlled, restricted, secure-room, data-room, compute-to-data, handoff-recipient-only, or archive-only forms.

Evidence does not certify. Evidence does not approve. Evidence does not procure. Evidence does not finance. Evidence does not underwrite. Evidence does not create public authority action, community consent, Indigenous consent where applicable, deployment authorization, or execution authority. Evidence creates bounded meaning and a basis for better learning, reporting, readiness, and handoff.

The Evidence rail is the epistemic spine of Nexus. It keeps the ecosystem serious.

### 5.3.5 Public-Safe Rail

The Public-Safe rail is the pathway through which Nexus determines whether and how an object, report, dashboard, Studio output, Campaign material, Marketplace listing, Registry display, DRI output, GRIx mapping, Observatory signal, National Portfolio item, Nexus Universe output, or handoff summary may be communicated outside controlled contexts.

Public-safe treatment is necessary because not all true information is safe to release openly, and not all useful information is safe to describe without limits. Some information may create public panic, false reassurance, public authority confusion, security exposure, privacy risk, protected knowledge harm, geospatial sensitivity, finance overclaim, procurement implication, provider validation, sponsor-control implication, consent overclaim, or execution overclaim.

The Public-Safe rail should address:

1. evidence sufficiency and limitations;
2. data sensitivity and access class;
3. AI-use disclosure and limitations;
4. uncertainty and confidence language;
5. public authority boundary language;
6. no-warning language where applicable;
7. no-certification, no-procurement, no-finance, no-insurance, no-consent, no-deployment, and no-execution language;
8. community and Indigenous protocol protections where applicable;
9. accessibility and plain-language needs;
10. media and public narrative risk;
11. correction and public repair pathways;
12. archive and non-current status treatment.

Public-safe release may be open, controlled, restricted, public-authority-learning-only, secure-room-only, data-room-only, handoff-recipient-only, archive-only, or non-continuing. The choice of release class should be recorded.

The Public-Safe rail allows Nexus to communicate publicly without becoming reckless. It turns publication into a governed lifecycle state, not a promotional act.

### 5.3.6 Registry Rail

The Registry rail is the pathway through which Nexus objects, records, pathways, listings, workflows, reports, National Portfolio items, Nexus Universe outputs, handoff packages, corrections, withdrawals, recalls, and archives become status-true. Registry status tells the ecosystem what an object is, what version exists, what lifecycle state applies, what support status applies, what review occurred, what correction history exists, and what current meaning may be claimed.

The Registry rail may include:

1. object identity and version records;
2. steward and maintainer records;
3. status labels, including draft, active, under review, public-safe, controlled, supported, unsupported, deprecated, suspended, withdrawn, recalled, superseded, archived, and non-continuing;
4. access-class records;
5. support-class records;
6. review-state records;
7. data-use and AI-use labels;
8. Marketplace relationship records;
9. Studio relationship records;
10. Grid and TRL relationship records;
11. National Portfolio relationship records;
12. Nexus Universe relationship records;
13. handoff relationship records;
14. correction and archive history.

Registry status is truth about status, not approval of substance. A Registry entry does not certify an object, approve a provider, procure a service, authorize deployment, determine financeability, determine insurability, create public authority action, grant consent, or execute a project.

The Registry rail protects Nexus from false continuity. It shows when an object is current, when it changed, when it was corrected, when it was withdrawn, when it was recalled, and when it belongs only to archive.

### 5.3.7 Marketplace Rail

The Marketplace rail is the pathway through which Nexus objects become discoverable to appropriate audiences under recorded metadata, status, access class, support class, public-safe status, and boundary notices. It enables discovery without procurement and visibility without endorsement.

The Marketplace rail may carry:

1. public-good software;
2. datasets and data products;
3. APIs, schemas, connectors, and dashboards;
4. models, AI workflows, notebooks, and digital twins;
5. learning objects and Academy pathways;
6. Reports and public-safe summaries;
7. Campaign objects;
8. Foundry outputs;
9. Studio workflows;
10. Grid and TRL context objects;
11. DICE objects, GRIx mappings, DRI indicators, and Observatory objects;
12. National Portfolio objects;
13. Nexus Universe outputs;
14. support opportunities;
15. handoff-context objects.

Marketplace discovery must remain linked to Registry status. A listing should not appear current when the Registry shows withdrawn, recalled, unsupported, superseded, archived, or non-continuing status. Marketplace correction, delisting, restriction, or archive must follow Registry and correction records where applicable.

The Marketplace rail does not create procurement, preferred-provider status, supplier approval, financeability, insurability, certification, public authority approval, consent, deployment authorization, or execution authority. It helps people find public-good objects and opportunities. It does not decide that they should be bought, funded, insured, deployed, or implemented.

The Marketplace rail is disciplined visibility.

### 5.3.8 Studio Rail

The Studio rail is the pathway through which Nexus objects become reviewable, demonstrable, simulated, interpreted, tested, or explored in controlled environments. Nexus Studio may support dashboards, digital twins, AI workflows, secure rooms, data rooms, compute-to-data workflows, public authority learning rooms, readiness rooms, capital-reader rooms, insurance-reader rooms, donor-reader rooms, public finance learning rooms, Nexus Universe demonstrations, Foundry demonstrations, and lawful handoff demonstrations.

The Studio rail should include:

1. workflow identity and purpose;
2. runtime environment;
3. input records and output records;
4. data-use and AI-use records;
5. access controls and role permissions;
6. no-download, no-write-back, and no-command controls where required;
7. human review and output review;
8. assumptions, parameters, and limitations;
9. uncertainty and confidence labels;
10. public-safe status;
11. correction, pause, shutdown, recall, archive, and reinstatement rules.

A Studio workflow is not deployment. A simulation is not official forecast. A dashboard is not a public authority decision. A digital twin is not operational command. A readiness room is not finance approval. A capital-reader room is not investment advice. An insurance-reader room is not underwriting. A public authority learning room is not public authority action.

The Studio rail exists to make complex systems understandable before decisions are made by competent actors. It supports review and learning, not execution by implication.

### 5.3.9 Grid and TRL Rail

The Grid and TRL rail is the pathway through which Nexus objects receive bounded readiness, maturity, evidence-sufficiency, support-status, and review-routing context. It helps the ecosystem understand whether an object is early, experimental, reviewed, supported, public-safe, controlled, ready for further build, ready for Studio demonstration, ready for Nexus Universe presentation, ready for Marketplace discovery, ready for Registry update, ready for handoff context, or not ready to continue.

The Grid and TRL rail may address:

1. technical readiness;
2. evidence readiness;
3. data readiness;
4. AI-use readiness;
5. method readiness;
6. software support readiness;
7. cybersecurity and privacy readiness;
8. public-safe readiness;
9. safeguard readiness;
10. Academy readiness;
11. Campaign readiness;
12. Studio readiness;
13. Nexus Universe readiness;
14. Marketplace and Registry readiness;
15. handoff dependency readiness.

TRL 1–10 is used in Nexus as a bounded technical and readiness classification. It is not certification, procurement status, financeability, insurability, public authority approval, safety approval, deployment authorization, consent, or execution authority. Grid records similarly provide review and maturity context, not approval.

The Grid and TRL rail must be correctable. Readiness may be upgraded, downgraded, suspended, withdrawn, recalled, superseded, archived, or marked non-continuing when evidence, methods, data, AI-use, support, public-safe status, safeguards, or handoff dependencies change.

### 5.3.10 National Portfolio Rail

The National Portfolio rail is the pathway through which national Nexus work becomes organized into country-level memory, priorities, systems-risk maps, challenge briefs, evidence needs, Observatory needs, DICE needs, GRIx mappings, DRI indicators, Academy pathways, Campaign opportunities, Foundry builds, Studio workflows, Grid and TRL context, public authority learning questions, finance-readiness questions, safeguard records, Nexus Universe outputs, and handoff dependencies.

The National Portfolio rail may carry:

1. National Context Records;
2. National Systems-Risk Maps;
3. National Challenge Briefs;
4. Evidence Need Records;
5. DICE and data-governance records;
6. GRIx and DRI localization records;
7. Observatory need records;
8. Studio workflow candidates;
9. Academy and Risk Academy pathway needs;
10. Foundry build candidates;
11. Campaign candidates;
12. Grid and TRL context records;
13. public authority learning records;
14. safeguard and accessibility records;
15. community and Indigenous protocol boundary records where applicable;
16. assumptions, dependency, and diligence-gap registers;
17. finance-readiness, insurance-readiness, donor-readiness, and public finance learning questions;
18. Nexus Universe preparation and output records;
19. lawful handoff dependency records;
20. correction and archive records.

A National Portfolio item is not national approval by default. It is not a government decision, procurement package, financeable project, insured project, certified technology, consented activity, deployment authorization, or execution mandate.

The National Portfolio rail preserves national ownership by ensuring that country-level work is recorded, localized, public-safe, correctable, and handoff-aware before any enterprise actor claims implementation context.

### 5.3.11 Handoff Rail

The Handoff rail is the pathway through which Nexus public-good context may move to separate competent actors without transferring authority. It is the controlled bridge from public-good formation to enterprise-stack evaluation, public authority procedure, research continuation, finance and insurance diligence, donor review, community action where appropriate, or other lawful downstream consideration.

A handoff package should include:

1. object identity and version;
2. source and provenance;
3. evidence records;
4. method records;
5. data-use records;
6. AI-use records;
7. review records;
8. support records;
9. public-safe status;
10. Marketplace and Registry relationship;
11. Studio records;
12. Grid and TRL context;
13. DICE, GRIx, DRI, and Observatory context;
14. National Portfolio context;
15. Nexus Universe output context;
16. assumptions registers;
17. dependency registers;
18. diligence-gap registers;
19. public authority dependency notes;
20. legal, procurement, finance, insurance, donor, and public finance dependency notes;
21. safeguard, accessibility, community, and Indigenous protocol boundaries where applicable;
22. recipient responsibilities;
23. correction, recall, archive, and non-continuation pathways;
24. no-authority-transfer notices.

Handoff transfers context, not command. It does not create project approval, procurement status, financeability, insurability, donor commitment, public finance approval, certification, community consent, Indigenous consent, deployment authorization, emergency command, public authority action, or execution rights.

The Handoff rail is one of the most important Nexus controls because it operates closest to execution. It ensures that when public-good work moves downstream, its limits move with it.

### 5.3.12 Correction and Archive Rail

The Correction and Archive rail is the trust-preservation pathway of Nexus Ecosystem. It ensures that records, objects, Dockets, evidence, methods, data, AI-use, public-safe reports, Marketplace listings, Registry statuses, Studio workflows, Grid and TRL records, DICE objects, GRIx mappings, DRI outputs, Observatory signals, Academy materials, Campaigns, Foundry outputs, National Portfolio objects, Nexus Universe outputs, handoff packages, and enterprise-recipient uses can be corrected, withdrawn, recalled, superseded, archived, or marked non-continuing.

Correction may include:

1. clarification;
2. addendum;
3. revision;
4. supersession;
5. downgrade;
6. suspension;
7. withdrawal;
8. recall;
9. public repair;
10. restriction;
11. delisting;
12. sealing;
13. deletion where required;
14. archive;
15. non-continuation;
16. reinstatement after review.

Archive preserves memory without current authority. It records what existed, what status it held, what evidence supported it, what limitations applied, what correction occurred, why it changed, what replaced it if anything, and what current use is prohibited or restricted.

The Correction and Archive rail must propagate across all affected rails. A correction to evidence may affect Reports, Studio workflows, Marketplace listings, Registry status, Grid and TRL records, Academy materials, National Portfolio objects, Nexus Universe outputs, and handoff packages. A handoff recall may affect National Consortium Companies, Project SPVs, providers, operators, funders, insurers, donors, public authorities, communities, Indigenous institutions where applicable, and other lawful recipients.

The final One Rail rule is: movement creates responsibility; routing does not create authority; visibility does not create approval; readiness does not create finance; handoff does not create execution; correction travels with the object; archive preserves memory without current power.

## 5.4 Stack Interface Controls

### 5.4.1 Public-Good to Enterprise Interface

The public-good to enterprise interface is the controlled boundary through which Nexus public-good context may move from evidence, learning, reporting, discovery, status truth, Studio demonstration, readiness classification, National Portfolio preparation, Nexus Universe output, or Foundry production into the separate enterprise-stack environment where lawful actors may evaluate, structure, finance, insure, procure, contract, operate, or implement under their own authority.

This interface is necessary because Nexus Ecosystem is designed to produce serious implementation context without executing by implication. Public-good work should not remain trapped in reports, events, dashboards, or learning rooms where it cannot support real-world action. Equally, public-good work must not be allowed to become execution authority merely because it is useful, mature, visible, sponsor-supported, provider-supported, public-authority-relevant, capital-readable, or Nexus Universe-ready.

The interface may connect the Public-Good Stack to:

1. National Consortium Companies, where country-level enterprise readiness, implementation structuring, provider coordination, finance and insurance engagement, and operational planning may occur under separate legal authority;
2. Project SPVs, where project-level rights, obligations, contracts, finance, insurance, permits, safeguards, and liabilities may be held under defined project scope;
3. public authorities acting separately, where a competent public body may consider Nexus context through its own lawful procedures;
4. providers, operators, and contractors, where technical, operational, construction, software, data, cybersecurity, infrastructure, or professional capabilities may be contracted or evaluated;
5. funders, insurers, donors, and public finance actors, where independent diligence may occur under no-reliance and regulated-perimeter discipline;
6. universities and laboratories acting separately, where research continuation, testing, technical review, learning, or applied development may occur under separate institutional authority;
7. community actors where appropriate, where local stewardship, participation, monitoring, co-design, implementation support, or lawful receipt may occur only with proper authority, safeguards, and consent where required.

The public-good to enterprise interface operates through records. It requires object identity, evidence context, method context, data-use context, AI-use context, review status, public-safe status, support status, Registry status, Marketplace relationship, Studio record, Grid or TRL context, National Portfolio context, assumptions, dependencies, diligence gaps, public authority dependencies, finance and insurance questions, safeguard notes, recipient responsibilities, correction pathways, recall pathways, archive rules, and no-authority-transfer notices.

The interface is a bridge, not a merger. Public-good context may inform enterprise action, but enterprise action must arise from separate authority.

### 5.4.2 Handoff Package as Controlled Bridge

The handoff package is the controlled bridge between the Public-Good Stack and the Enterprise Stack. It is the formal record bundle through which Nexus context may be transmitted to a lawful recipient without transferring Nexus authority, public authority authority, procurement authority, finance authority, insurance authority, certification authority, consent authority, deployment authority, or execution authority.

A handoff package should be designed to prevent ambiguity. It should tell the recipient what exists, what supports it, what it means, what it does not mean, what remains unresolved, what restrictions apply, what independent diligence is required, what corrections may follow, and what responsibilities belong to the recipient.

A handoff package may include:

1. Handoff Record, identifying recipient, purpose, scope, transfer date, steward, source pathway, and no-authority-transfer status;
2. Object Record, identifying the object, version, class, steward, status, support state, and lifecycle state;
3. Evidence Record, identifying evidentiary basis, sources, assumptions, confidence, uncertainty, limitations, and evidence gaps;
4. Method Record, identifying analytical, technical, computational, review, Studio, DRI, GRIx, Grid, TRL, or public-safe method context;
5. Data-Use Record, identifying data rights, permissions, restrictions, access class, sensitivity, privacy, sovereignty, compute-to-data requirements, secure-room requirements, public-safe transformation, and archive rules;
6. AI-Use Record, identifying AI role, model or workflow context, human review, prohibited use, agentic restrictions, output controls, and correction pathways;
7. Review Record, identifying review scope, reviewer class, review outcome, and limits;
8. Support Record, identifying maintained, unsupported, sponsor-supported without control, provider-supported without validation, deprecated, retired, archive-only, or non-continuing status;
9. Registry and Marketplace references, identifying status truth and discovery context without certification or procurement meaning;
10. Studio, Grid, and TRL records, identifying controlled workflow context and bounded readiness status without deployment, finance, insurance, procurement, or approval meaning;
11. National Portfolio and Nexus Universe records, identifying national or annual-surge context without national approval, endorsement, or execution meaning;
12. Assumptions, dependency, and diligence-gap registers, identifying unresolved conditions requiring independent review;
13. Safeguard records, including community, Indigenous protocol where applicable, accessibility, environmental, social, youth, humanitarian, protected knowledge, privacy, cyber, and public-safe dependencies;
14. Recipient responsibility notice, identifying what the recipient must decide, verify, obtain, contract, finance, insure, authorize, consent to, operate, correct, and bear responsibility for;
15. Correction, recall, archive, and non-continuation pathway, identifying how future changes will be communicated and acted upon.

The handoff package is not a ceremonial document. It is the boundary instrument that makes lawful downstream evaluation possible without allowing the Public-Good Stack to execute by implication.

### 5.4.3 No Authority Transfer

No Nexus handoff, interface, routing, record, package, room, report, listing, Registry status, Marketplace listing, Studio workflow, Grid or TRL record, National Portfolio item, Nexus Universe output, Foundry build, Campaign output, Academy record, DICE object, GRIx mapping, DRI output, Observatory signal, or public-safe summary transfers authority by implication.

Authority remains with the actor that lawfully holds it. Public authority remains with competent public authorities. Procurement authority remains with competent procuring actors. Finance authority remains with competent financial actors. Insurance authority remains with competent insurance actors. Certification authority remains with competent certification or standards actors. Consent authority remains with the relevant persons, communities, Indigenous institutions where applicable, or lawful consent-holding bodies. Execution authority remains with separate competent enterprise, public authority, community, Indigenous, academic, provider, operator, contractor, National Consortium Company, Project SPV, or other lawful actors acting within their own powers.

No authority transfer means:

1. a handoff recipient receives context, not command;
2. a National Consortium Company receives materials, not Nexus public-good authority;
3. a Project SPV receives dependencies, not approval;
4. a provider receives opportunity context, not validation;
5. an operator receives workflow context, not operational authorization;
6. a public authority receives learning context, not an official decision already made;
7. a capital reader receives readiness questions, not investment advice;
8. an insurer receives risk context, not underwriting direction;
9. a donor receives donor-readiness context, not commitment authority;
10. a community actor receives information or support, not imposed implementation;
11. an Indigenous institution where applicable retains its own governance, rights, protocols, consent authority, data sovereignty, and protected knowledge controls.

This rule protects every party. It protects Nexus from unauthorized execution. It protects recipients from false reliance. It protects communities and public authorities from implication. It protects funders, insurers, donors, providers, and enterprise actors from boundary confusion. It protects the public-good role by keeping authority where law and governance place it.

### 5.4.4 No Procurement Transfer

No handoff from the Public-Good Stack to the Enterprise Stack transfers procurement authority, procurement status, supplier approval, preferred-provider status, bid selection, contract award, procurement recommendation, vendor validation, or purchasing obligation.

A Nexus Marketplace listing is not procurement. A Registry status is not supplier approval. A provider contribution is not validation. A sponsor relationship is not vendor preference. A Foundry build is not selection. A Studio demonstration is not technical award. A Grid or TRL record is not procurement readiness. A Nexus Universe appearance is not endorsement. A National Portfolio item is not a tender package. A handoff package is not contract award.

Procurement belongs to the actor with lawful procurement authority. That actor may be a public authority, National Consortium Company, Project SPV, university, operator, donor-funded program, private enterprise, community institution where appropriate, Indigenous institution where applicable, or other competent procuring body. That actor must apply its own rules on competition, fairness, conflicts, technical specifications, due diligence, budget authority, contract authority, supplier qualification, transparency, anti-corruption, data protection, cybersecurity, accessibility, safeguards, and contract management.

A handoff package may support procurement context only by identifying:

1. relevant objects, providers, tools, data, software, reports, or technical baselines;
2. evidence and limitations;
3. provider contribution status without validation;
4. support status;
5. interoperability questions;
6. data, AI, cyber, privacy, and safeguard dependencies;
7. public authority dependencies;
8. procurement boundaries;
9. conflicts and provider-neutrality notes;
10. correction and withdrawal pathways.

The procurement transfer rule protects Nexus from becoming a hidden procurement channel. It also protects providers from false endorsement and protects procuring actors from contaminated process.

### 5.4.5 No Finance Transfer

No handoff from the Public-Good Stack to the Enterprise Stack transfers finance authority, investment approval, financeability, bankability, valuation, rating, transaction readiness, lending decision, investment recommendation, capital allocation, guarantee, public finance allocation, donor funding, or financial commitment.

Finance-readiness is not finance. Capital-readability is not capital. A GRA-supported note is not investment advice. A National Investors Council discussion is not an investment committee decision. A capital-reader room is not a solicitation room. A Grid or TRL record is not financeability. A National Portfolio item is not a financed project. A Nexus Universe output is not a transaction. A handoff package is not a financing document.

Finance decisions belong to separate competent actors acting under their own mandates, legal obligations, fiduciary duties, regulatory requirements, credit policies, investment policies, donor rules, public finance procedures, committee approvals, diligence standards, risk appetite, and contractual documents.

A handoff package may support finance context only by identifying:

1. evidence basis;
2. assumptions;
3. dependencies;
4. diligence gaps;
5. risk-to-capital questions;
6. resilience-value context;
7. public authority dependencies;
8. procurement dependencies;
9. insurance dependencies;
10. safeguard dependencies;
11. data, AI, cyber, and privacy dependencies;
12. recipient responsibility;
13. no-reliance and non-solicitation notices;
14. correction and recall pathways.

The no-finance-transfer rule protects Nexus from regulated-perimeter overreach and protects recipients from relying on public-good context as a financing decision. Nexus can make finance questions clearer; it does not provide finance.

### 5.4.6 No Insurance Transfer

No handoff from the Public-Good Stack to the Enterprise Stack transfers insurance authority, underwriting acceptance, coverage indication, premium indication, risk selection, claims determination, policy terms, reinsurance capacity, insurance approval, insurability, or insurance rating.

Insurance-readiness is not underwriting. DRF literacy is not risk transfer. Protection-gap mapping is not coverage. A DRI output is not an underwriting score. A Studio scenario is not actuarial determination. A Grid or TRL record is not insurability. A Nexus Report is not an insurance representation. A handoff package is not an insurance binder.

Insurance and underwriting decisions belong to competent insurance, reinsurance, brokerage, public insurance, risk-engineering, or insurance-related actors acting under their own regulatory status, capital rules, actuarial methods, underwriting guidelines, policy forms, risk appetite, claims procedures, and contractual obligations.

A handoff package may support insurance context only by identifying:

1. risk and exposure context;
2. data quality and data limitations;
3. model assumptions and limitations;
4. DRI and GRIx interpretation limits;
5. Observatory signal context;
6. resilience measures and dependency notes;
7. protection-gap questions;
8. public authority dependencies;
9. legal and procurement dependencies;
10. safeguard dependencies;
11. operational and maintenance dependencies;
12. no-underwriting notices;
13. correction and recall pathways.

The no-insurance-transfer rule allows Nexus to make risk more legible to insurance systems while preventing public-good intelligence from being mistaken for coverage, underwriting, or insurability.

### 5.4.7 No Public Authority Transfer

No handoff from the Public-Good Stack to the Enterprise Stack transfers public authority. Nexus does not transfer regulatory power, permitting power, licensing power, procurement authority, public finance authority, emergency command authority, public warning authority, inspection authority, enforcement authority, statutory classification authority, policy authority, public data authority, or governmental endorsement by routing materials to a public authority, enterprise actor, National Consortium Company, Project SPV, provider, operator, funder, insurer, donor, university, or community actor.

Public authority action requires a competent public body acting through its own lawful procedures. A public authority learning room is not public authority action. A public authority’s attendance is not approval. A public-safe Report is not an official warning. A DRI output is not emergency command. A Studio dashboard is not public authority determination. A National Portfolio item is not government policy. A handoff package is not permit, license, procurement decision, or public finance allocation.

A handoff package may support public authority context only by identifying:

1. public authority dependencies;
2. legal and regulatory questions;
3. permits, approvals, licenses, notices, procurement procedures, public finance procedures, data-sharing permissions, and official communication needs;
4. evidence, methods, uncertainty, and limitations;
5. public-safe language;
6. non-decision status;
7. recipient responsibilities;
8. correction and public repair pathways.

The no-public-authority-transfer rule protects public bodies from accidental decisions and protects Nexus from becoming a shadow administrative process. It allows public authorities to learn from Nexus without being captured by it.

### 5.4.8 No Consent Transfer

No handoff from the Public-Good Stack to the Enterprise Stack transfers consent. Participation, visibility, consultation, attendance, community input, Indigenous participation where applicable, campaign support, stakeholder engagement, public-safe reporting contribution, Studio participation, National Council participation, Working Group participation, Competence Cell participation, Nexus Universe participation, or National Portfolio inclusion does not create consent by implication.

Consent must be separate, lawful, specific, informed, context-appropriate, culturally appropriate, and recorded where required. Consent may involve individuals, communities, Indigenous institutions where applicable, data subjects, landholders, rights holders, guardians, public authorities, institutional review bodies, or other lawful consent-holding actors. Nexus records may identify consent dependencies; they do not satisfy them by default.

No consent transfer applies especially to:

1. community implementation;
2. Indigenous lands, waters, territories, rights, governance, knowledge, data, cultural heritage, and protected knowledge where applicable;
3. personal data, health-sensitive data, youth data, vulnerable population data, and rights-bearing data;
4. AI training, fine-tuning, benchmarking, or model-use permissions;
5. publication, commercialization, data sharing, cross-border transfer, or handoff of sensitive information;
6. local deployment, infrastructure work, field activities, pilots, monitoring, or operational changes;
7. humanitarian, displacement, conflict-sensitive, or public-health-sensitive contexts.

A handoff package should identify what consent has been obtained, what consent has not been obtained, what consent may be required, who may hold consent authority, what process may be needed, what restrictions apply, and what protected knowledge or data must not be used without proper authority.

The no-consent-transfer rule protects communities, Indigenous institutions where applicable, individuals, data subjects, and affected stakeholders from extraction and overclaim. It also protects enterprise recipients from mistaking participation for permission.

### 5.4.9 Recipient Responsibility

A lawful recipient that receives Nexus context through the stack interface assumes responsibility for its own interpretation, diligence, decisions, actions, communications, contracts, approvals, safeguards, finance, insurance, procurement, operations, corrections, and liabilities. Recipient responsibility is the enterprise-side discipline that completes the handoff boundary.

Recipient responsibility includes:

1. independent diligence, including legal, technical, financial, insurance, public authority, procurement, environmental, social, community, Indigenous protocol where applicable, data, AI, cyber, privacy, operational, and safeguard diligence;
2. authority verification, including determining whether the recipient has authority to act and what additional authority is required;
3. contracting and governance, including internal approvals, board approvals, signing authority, contracts, policies, conflicts, and compliance controls;
4. finance and insurance responsibility, including obtaining any required funding, investment, donor support, public finance, guarantees, insurance, reinsurance, or risk-transfer arrangements through separate competent processes;
5. public authority responsibility, including obtaining permits, licenses, approvals, procurement decisions, public finance approvals, data-sharing permissions, public warnings, emergency authorizations, or other official actions where required;
6. safeguard responsibility, including community consent where required, Indigenous consent and protocols where applicable, accessibility, youth protection, humanitarian sensitivity, environmental and social safeguards, protected knowledge, privacy, cybersecurity, and AI controls;
7. public communication responsibility, including avoiding overclaims about Nexus approval, certification, procurement, financeability, insurability, public authority action, consent, deployment authorization, or execution authority;
8. correction responsibility, including receiving, assessing, propagating, and acting on corrections, recalls, withdrawals, archive notices, and non-continuation notices.

A recipient may rely on Nexus context only within the recorded scope and subject to all limitations, no-reliance notices, no-conversion notices, and correction pathways. If the recipient needs approval, certification, finance, insurance, procurement, public authority action, consent, or execution authority, it must obtain those separately.

The recipient responsibility rule prevents handoff from becoming passive reliance. It makes handoff an active duty to verify.

### 5.4.10 Correction and Recall

Correction and recall are mandatory stack interface controls. Because Nexus public-good context may influence enterprise evaluation, project structuring, public authority learning, finance discussions, insurance discussions, donor review, procurement preparation, community engagement, Indigenous protocol-sensitive pathways where applicable, and operational planning, corrections must travel across the public-good to enterprise interface.

Correction may be required where there is an error, update, limitation, withdrawal, recall, support change, Registry status change, Marketplace delisting, Studio workflow correction, Grid or TRL downgrade, DICE correction, GRIx correction, DRI correction, Observatory correction, Report correction, National Portfolio correction, Nexus Universe correction, provider contribution correction, sponsor support correction, public authority boundary correction, finance-readiness correction, insurance-readiness correction, consent-boundary correction, safeguard correction, or handoff package correction.

A correction and recall interface should identify:

1. affected object or record, including version, source, pathway, and recipient;
2. correction type, including clarification, addendum, revision, supersession, downgrade, suspension, withdrawal, recall, public repair, restriction, delisting, sealing, deletion where required, archive, non-continuation, or reinstatement;
3. affected recipients, including National Consortium Companies, Project SPVs, public authorities, providers, operators, contractors, funders, insurers, donors, universities, laboratories, community actors, Indigenous institutions where applicable, and other lawful recipients;
4. required recipient action, including stop use, review use, replace material, update documents, notify counterparties, suspend workflow, remove public claim, revise submission, halt procurement use, halt finance use, halt insurance use, halt community-facing use, or archive material;
5. public-safe action, including whether public correction, public repair, media correction, community-facing correction, Indigenous protocol-sensitive correction where applicable, or stakeholder notice is required;
6. closure record, including who acted, what changed, what remains unresolved, what is superseded, what is archived, and what must no longer be relied upon.

Recall is required where continued use of a handoff package or Nexus object would create material risk of misinterpretation, unsafe reliance, legal error, public authority confusion, finance overclaim, insurance overclaim, procurement contamination, consent overclaim, safeguard failure, technical harm, cyber or privacy risk, protected knowledge exposure, or execution overclaim.

The correction and recall rule ensures that handoff remains alive after transfer. The interface does not end when the package is delivered. It continues as long as the recipient may be materially affected by the record.

<br>


---

# 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/standardization/nexus-ecosystem/ii.-structure/v.-stacks.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.