VII. Reports
Nexus Reports governs national portfolio reports, WFEH-B systems reports, public-safe risk reporting, DRR, DRF, DRI, open-science publishing, Zenodo deposits, DOI citation, and evidence governance.
Summary
Nexus Reports is the publication pillar for national portfolio reports, WFEH-B systems reports, public-safe risk reporting, DRR, DRF, DRI, open-science publishing, Zenodo deposits, DOI citation, and evidence governance.
It turns Nexus work into durable, citable, reviewable, and correctionable public-good outputs. It preserves discoverability, institutional memory, and lawful publication boundaries without turning reporting into approval, warning, finance, procurement, consent, or execution.
In this section
National portfolio reporting and WFEH-B systems reporting
DRR, DRF, DRI, and public-safe risk reporting
Open-science publishing, Zenodo deposits, DOI citation, and evidence governance
Nexus Reports shall be the Nexus Ecosystem publication pillar for national portfolio reporting, WFEH-B systems reporting, public-safe reporting, open-science publishing, disaster risk intelligence, risk reporting, evidence translation, Zenodo deposits, DOI-based citation, and durable institutional memory.
It shall make WFEH-B, DRR, DRF, DRI, data commons, observability, digital public goods, sovereign compute, and public-good technology outputs more discoverable, citable, reusable within rights, and correctionable without converting publication into approval, warning, finance, procurement, consent, or execution.
This framework defines how Nexus Reports governs national portfolio reports, WFEH-B systems reports, DRR, DRF, DRI, public-safe risk reporting, open-science publishing, Zenodo deposits, DOI-based citation, and evidence governance across the Nexus Ecosystem.
1. Identity, Mandate, Doctrine, and Strategic Function
1.1 Nexus Reports as a Core Nexus Pillar
1.1.1 Pillar Status. Nexus Reports shall constitute a core Pillar of the Nexus Ecosystem and shall operate as the formal publication, open-knowledge, public-safe reporting, evidence-translation, national-portfolio, correction, citation, and institutional-memory pillar through which Nexus work becomes durable, discoverable, citable, reusable within rights, and accountable over time.
1.1.2 Not a Conventional Publications Function. Nexus Reports shall not be treated as a communications department, public relations channel, marketing archive, newsletter, conference proceedings desk, academic vanity series, consulting report line, promotional catalogue, policy advocacy shop, rating service, certification scheme, procurement advisory surface, investment research product, insurance scoring mechanism, public authority bulletin, emergency warning system, or implementation authority. It shall be the governed public-good knowledge-publication pillar of Nexus.
1.1.3 Pillar Function. Nexus Reports shall convert the distributed production of Nexus into structured public-safe knowledge products, including national portfolio reports, WFEH-B systems reports, DRR reports, DRF reports, DRI reports, DICE reports, GRIx ontology reports, Observatory reports, Nexus Foundry reports, Nexus Campaign reports, Nexus Academy reports, Nexus Labs reports, Risk Agency reports, Nexus Universe reports, Grid and TRL evidence summaries, public authority learning summaries, support reports, correction notices, and archive records.
1.1.4 Position in the Nexus Operating Stack. Nexus Reports shall sit between Nexus production and public knowledge. Nexus Campaigns mobilize signals; National Working Groups and Competence Cells produce records; DICE governs data; GRIx structures risk ontology; DRI structures public-safe risk intelligence; Nexus Observatory structures observability; Nexus Foundry builds public-good outputs; Nexus Studio runs controlled workflows; Nexus Grid and TRL 1–10 classify bounded readiness evidence; Nexus Universe concentrates annual surge capacity; Nexus Registry preserves status truth; Nexus Marketplace enables discovery; Nexus Reports publishes public-safe knowledge; Nexus Network preserves memory; Nexus Rails routes continuation, correction, archive, and lawful handoff.
1.1.5 Strategic Role. Nexus Reports shall become the authoritative public-good publication pillar for risk, resilience, innovation, technology, data, public authority learning, finance-readiness, disaster risk intelligence, national portfolio formation, and lawful handoff discipline within Nexus. Its authority shall arise from evidence architecture, open-science infrastructure, metadata discipline, review labels, public-safe publication, contributor traceability, correctionability, Registry linkage, and non-execution boundaries, not from rhetorical certainty, prestige branding, sponsor support, provider participation, or public authority attention.
1.1.6 Nexus Reports Formula. Nexus Reports shall publish what can safely and lawfully be made public; summarize what must remain controlled; cite what must remain traceable; register what must remain status-bound; route what must continue; correct what changes; archive what is no longer current; and preserve the rule that publication is not approval, openness is not exposure, evidence is not certification, intelligence is not warning, readiness is not finance, participation is not consent, support is not control, contribution is not validation, and handoff is not execution.
1.2 Foundational Definition
1.2.1 Nexus Reports Defined. Nexus Reports means the integrated Nexus Pillar responsible for producing, stewarding, reviewing, publishing, depositing, versioning, linking, correcting, withdrawing, archiving, and making discoverable public-safe Nexus knowledge outputs, including reports, papers, briefs, atlases, technical notes, methods papers, evidence packs, datasets, software releases, schema releases, ontology releases, dashboards, public-safe summaries, national portfolio outputs, annual-cycle outputs, correction notices, and archive records.
1.2.2 Scope of Outputs. Nexus Reports may include, without limitation:
1.2.2.1 National Portfolio Reports showcasing country-level public-safe risk and innovation portfolios;
1.2.2.2 WFEH-B Nexus Reports covering water, food, energy, health, and biodiversity systems;
1.2.2.3 DRR Reports covering disaster risk reduction, resilience, preparedness, prevention, and public-safe learning;
1.2.2.4 DRF Reports covering disaster risk finance readiness, protection gaps, insurance-readiness questions, donor-readiness questions, public finance relevance, assumptions, dependencies, and diligence gaps;
1.2.2.5 DRI Reports covering public-safe disaster risk intelligence, indicators, dashboards, uncertainty labels, confidence labels, data gaps, and observability needs;
1.2.2.6 DICE Reports covering data commons, metadata, data dictionaries, schemas, data-use labels, AI-use labels, lineage, access rules, and controlled-source summaries;
1.2.2.7 GRIx Reports covering risk ontology, risk taxonomy, WFEH-B categories, DRR / DRF / DRI mappings, indicator logic, index structures, and controlled vocabulary;
1.2.2.8 Observatory Reports covering sensing, edge observation, geospatial intelligence, Earth observation, digital twins, public-safe observability, indicators, and correction needs;
1.2.2.9 Foundry and Acceleration Reports covering tasks, quests, bounties, builds, public-good software, open technical baselines, Nexus Core Build outputs, TRL evidence summaries, and support needs;
1.2.2.10 Campaign Reports covering mobilization, signatures, support, volunteers, national campaigns, Working Group formation, Competence Cell formation, public-safe reporting, and Nexus Universe readiness;
1.2.2.11 Academy and Learning Reports covering Risk Academy, Nexus Academy, WILPs, micro-credentials, iCRS records, reviewer training, maintainer training, data stewardship, AI-use training, safeguard training, and public authority learning;
1.2.2.12 Labs and Research Reports covering research calls, frontier lab streams, evidence gaps, testbeds, research-to-Foundry pathways, methods, and public-safe research summaries;
1.2.2.13 Risk Agency Reports covering expertise pathways, risk advisory demand patterns, sector capability gaps, public authority learning support needs, and lawful downstream support pathways;
1.2.2.14 Nexus Universe Reports covering annual-cycle outputs, arena summaries, Core Build records, public authority learning rooms, readiness rooms, national portfolio convergence, support records, after-action records, and continuation pathways;
1.2.2.15 Grid and TRL Evidence Summaries covering bounded maturity inputs and TRL 1–10 technical-readiness evidence, limitations, downgrades, correction, and no-certification notices;
1.2.2.16 Correction and Archive Reports covering errata, addenda, supersession, withdrawal, retraction where required, non-continuation, retirement, and archive status.
1.2.3 Publication Object. A Nexus Report may be a PDF, article, report, technical note, dataset, software artefact, code repository, metadata record, ontology release, schema package, dashboard summary, public-safe map, atlas, policy brief, learning package, evidence pack, correction notice, or archive record, provided it is classified, versioned, reviewed, labeled, registered, discoverable within rights, and correctionable.
1.2.4 Publication Record. Each material Nexus Report shall have a corresponding Registry record or equivalent status-truth record identifying title, report family, output class, steward, authors, contributors, source pathway, evidence class, version, date, DOI or persistent identifier where applicable, access class, license, data-use labels, AI-use labels, public-safe status, review level, linked records, Marketplace listing where applicable, correction history, withdrawal status, and archive status.
1.2.5 Publication Boundary. A Nexus Report is a knowledge object and record-linked public-good output. It shall not become approval, certification, procurement recommendation, finance recommendation, insurance advice, public authority action, official warning, community consent, Indigenous consent where applicable, deployment authorization, operational command, or execution by publication.
1.3 Pillar Mandate
1.3.1 General Mandate. Nexus Reports shall have the mandate to create the publication infrastructure through which Nexus work can be responsibly made visible, cited, reused, taught, corrected, archived, and routed into future work while preserving all Nexus role boundaries, data protections, public-safe constraints, and non-execution doctrine.
1.3.2 Evidence Translation Mandate. Nexus Reports shall translate distributed evidence into clear, expert-grade, public-safe outputs. It shall convert raw records, controlled inputs, technical artefacts, data summaries, stakeholder submissions, Working Group materials, Competence Cell outputs, Studio workflow outputs, DICE metadata, GRIx mappings, DRI indicators, Observatory notes, Nexus Universe materials, Campaign records, Academy records, Labs records, Foundry records, Grid inputs, and TRL evidence into coherent publications suitable for defined audiences.
1.3.3 National Portfolio Mandate. Nexus Reports shall publish the flagship National Portfolio Report series for countries and national pathways. These reports shall showcase national risk and innovation capacity across WFEH-B, DRR, DRF, DRI, public-good technology, observability, data commons, Academy learning, Campaign mobilization, Foundry production, Labs research, Risk Agency pathways, Nexus Universe participation, support records, and lawful handoff dependencies.
1.3.4 Open Knowledge Mandate. Nexus Reports shall expand open knowledge by using Zenodo and comparable open-science infrastructure for public-safe outputs, metadata, datasets where appropriate, software releases where appropriate, methods papers, schemas, ontologies, national portfolio reports, Nexus Universe reports, and correction records. Open knowledge shall be pursued through lawful, ethical, public-safe, rights-respecting publication practices.
1.3.5 Controlled Knowledge Mandate. Nexus Reports shall protect controlled knowledge. Where source data, field information, public authority materials, community knowledge, Indigenous protocol-sensitive information where applicable, protected knowledge, health-sensitive data, youth data, cyber-sensitive materials, infrastructure-sensitive information, geospatial details, provider-sensitive information, sponsor-sensitive information, or handoff packages cannot be publicly released, Nexus Reports shall publish only public-safe summaries, metadata, redacted evidence notes, methods, data availability statements, or controlled-access references.
1.3.6 Public-Safe Reporting Mandate. Nexus Reports shall make risk, resilience, innovation, and readiness information publicly understandable without creating panic, false authority, official warning confusion, ranking, rating, blame, procurement distortion, finance overclaim, insurance overclaim, certification overclaim, consent overclaim, or execution implication.
1.3.7 Citation and Persistence Mandate. Nexus Reports shall provide persistent citation infrastructure for Nexus knowledge products. Where appropriate, reports shall be assigned DOIs or other persistent identifiers, versioned, deposited, linked to Registry, listed in Marketplace, and preserved through archive records.
1.3.8 Correction Mandate. Nexus Reports shall maintain the authority and obligation to correct, update, supersede, withdraw, retract where necessary, recall downstream uses where appropriate, and archive reports. Correction shall be treated as a trust function rather than an embarrassment.
1.3.9 Ecosystem Activation Mandate. Nexus Reports shall not only publish finished outputs. It may activate new Campaigns, Foundry tasks, Academy modules, Labs research calls, Risk Agency pathways, DICE stewardship tasks, GRIx updates, DRI dashboards, Observatory needs, Studio workflows, support opportunities, Nexus Universe arenas, National Portfolio updates, and lawful handoff dependency packages.
1.3.10 Mandate Boundary. Nexus Reports shall publish, preserve, explain, cite, correct, and route knowledge. It shall not certify products, approve providers, recognize projects as investment-ready, allocate finance, underwrite risk, make public authority decisions, issue official warnings, conduct procurement, create community consent, authorize deployment, or execute projects.
1.4 Doctrinal Foundations
1.4.1 Publication Is Not Authority. Nexus Reports shall be governed by the doctrine that publication creates public-safe knowledge visibility, not external authority. A report, DOI, repository record, citation, dashboard, dataset, software release, or public-safe summary shall not become official approval, certification, procurement status, financeability, insurability, public authority action, consent, deployment, command, or execution.
1.4.2 Open Does Not Mean Ungoverned. Nexus Reports shall be open where safe, controlled where necessary, restricted where required, sealed where protective, and archived where no longer current. Open science shall not become ungoverned data exposure, protected knowledge extraction, public authority overclaim, sponsor capture, provider validation, or unsafe technical release.
1.4.3 Evidence Before Claims. Nexus Reports shall require evidence before claims. Reports shall distinguish evidence, interpretation, limitation, assumption, uncertainty, dependency, stakeholder input, expert judgment, model output, public-safe summary, readiness question, and handoff context.
1.4.4 Status by Record. Nexus Reports shall derive publication status from records. A publication’s meaning shall be governed by its Registry status, version, review level, public-safe label, data-use label, AI-use label, source class, license, correction history, and archive state, not by its visibility, citation count, sponsor support, provider involvement, media attention, or Nexus Universe presence.
1.4.5 Correctionability. Nexus Reports shall be correctionable by design. Every material output shall have a correction pathway, versioning rule, supersession rule, withdrawal rule, archive rule, and Registry update pathway where appropriate.
1.4.6 Public-Good Firewall. Nexus Reports shall preserve the public-good firewall. Reports may inform public-good learning, public-safe reporting, readiness questions, evidence gaps, and lawful handoff dependencies, but shall not become commercial validation, procurement influence, sponsor-controlled messaging, provider marketing, investor promotion, insurance scoring, or pay-to-authority.
1.4.7 Non-Execution. Nexus Reports shall preserve non-execution. Publishing a report, dataset, dashboard, software artefact, national portfolio, DRI indicator summary, DRF readiness note, public authority learning summary, or handoff summary shall not execute, operate, command, deploy, procure, finance, insure, approve, or authorize anything.
1.4.8 Public Authority Learning Without Public Authority Substitution. Nexus Reports may support public authority learning, technical dialogue, public-safe briefing, national portfolio formation, and evidence legibility. It shall not substitute for competent public authorities, official data systems, emergency management systems, public health bodies, regulators, procurement bodies, courts, legislatures, ministries, agencies, municipalities, statutory consultations, or public finance bodies.
1.4.9 Finance-Readiness Without Finance. Nexus Reports may publish DRF, finance-readiness, insurance-readiness, donor-readiness, public finance relevance, protection-gap, assumptions, dependency, and diligence-gap materials. It shall not provide investment advice, insurance advice, underwriting acceptance, donor commitment, public finance allocation, valuation, rating, solicitation, offer, bankability, financeability, or transaction readiness.
1.4.10 Provider Contribution Without Validation. Nexus Reports may disclose provider tools, software, APIs, compute, cloud, equipment, data subject to rights, technical assistance, and support. Such disclosure shall not validate providers, certify provider products, create preferred-vendor status, or imply procurement readiness.
1.4.11 Sponsor Support Without Control. Nexus Reports may disclose sponsor, donor, philanthropic, development, host, media, or in-kind support. Support shall not control findings, public-safe language, editorial decisions, review outcomes, Registry status, Marketplace listing, Nexus Universe routing, handoff status, correction decisions, or archive treatment.
1.4.12 Participation Without Consent. Nexus Reports may record stakeholder participation, community input, youth involvement, public authority learning, Campaign participation, Nexus Universe presence, or national pathway participation. Participation shall not imply endorsement, representation, public mandate, community consent, Indigenous consent where applicable, consultation completion, protected knowledge permission, land access, or project authorization.
1.5 Strategic Need for Nexus Reports
1.5.1 Fragmentation Problem. Risk and innovation work is often fragmented across events, pilots, dashboards, research papers, grant reports, policy briefs, datasets, software repositories, stakeholder workshops, consultancy outputs, public authority documents, community knowledge, donor records, insurance discussions, and technical prototypes. Without a governed publication pillar, outputs become hard to find, hard to cite, hard to compare, hard to update, hard to reuse, hard to protect, and easy to overclaim.
1.5.2 Event-Memory Problem. High-intensity convenings and annual cycles often generate valuable outputs that disappear into slide decks, recordings, informal notes, sponsor summaries, media posts, and personal networks. Nexus Reports shall convert Nexus Universe and other convening outputs into citable, public-safe, corrected, archived, and continuation-ready knowledge products.
1.5.3 National Portfolio Problem. Countries and national stakeholder ecosystems often lack a coherent public-safe way to present risk and innovation portfolios across WFEH-B, DRR, DRF, DRI, technology, data, public authority learning, finance-readiness, community safeguards, and implementation dependencies. Nexus Reports shall provide the National Portfolio Report format as a structured, non-ranking, non-executing, public-good publication model.
1.5.4 Data Exposure Problem. Open science can be misunderstood as full disclosure, while risk and resilience work often includes sensitive data, public authority-sensitive records, community-sensitive knowledge, protected knowledge, health-sensitive data, cyber-sensitive information, infrastructure-sensitive information, geospatial sensitivity, and commercially sensitive inputs. Nexus Reports shall solve this by publishing public-safe knowledge while preserving controlled source governance.
1.5.5 Readiness Overclaim Problem. Reports about innovation, resilience, disaster risk, finance, or technology are frequently misread as approval, financeability, bankability, insurance approval, public authority endorsement, procurement recommendation, maturity certification, or deployment readiness. Nexus Reports shall make readiness questions legible while preventing readiness overclaim.
1.5.6 Citation and Permanence Problem. Public-good outputs require persistent identifiers, versioning, metadata, and citation pathways. Nexus Reports shall use Zenodo and similar infrastructure to make reports, datasets, software, ontologies, schemas, and methods citable and durable while linking them to Nexus Registry status truth.
1.5.7 Contribution Recognition Problem. Distributed contributors, Working Groups, Competence Cells, Academy learners, Labs participants, Campaign teams, reviewers, maintainers, translators, accessibility contributors, and public-safe reviewers need credible contribution memory. Nexus Reports shall create publication-linked contribution records without inflating those records into employment, certification, procurement qualification, or expert status.
1.5.8 Public Trust Problem. Public-good systems lose trust when they cannot correct themselves, disclose conflicts, explain methods, state limitations, preserve versions, or distinguish public knowledge from authority. Nexus Reports shall make correction, transparency, contributor taxonomy, conflict disclosure, versioning, limitations, and no-conversion notices core publication practices.
1.5.9 Expert Audience Problem. Expert audiences require more than narrative. They require methods, data status, metadata, source classes, evidence limitations, uncertainty, review levels, versioning, reproducibility where safe, license clarity, and correction history. Nexus Reports shall meet expert expectations without sacrificing accessibility for multi-stakeholder use.
1.5.10 Strategic Necessity. Nexus Reports is necessary because Nexus cannot scale as a public-good ecosystem unless its outputs become public-safe, citable, status-linked, searchable, reusable, correctable, and archivable. Reports are not a side product; they are the institutional memory and knowledge interface of the Nexus Ecosystem.
1.6 Nexus Reports and Open Science Infrastructure
1.6.1 Repository Strategy. Nexus Reports shall use Zenodo and comparable open-science repositories as publication and persistent identifier infrastructure for public-safe reports, datasets, software releases, ontologies, schemas, methods papers, evidence summaries, public-safe national portfolio outputs, Nexus Universe outputs, and correction records.
1.6.2 Zenodo Role. Zenodo-style infrastructure shall provide public deposit, DOI assignment, metadata preservation, versioning, repository discovery, community organization, and citation. It shall not provide Nexus approval, public authority approval, certification, data governance, public-safe review, legal review, or controlled-source management.
1.6.3 Comparable Infrastructure. Nexus Reports may also use institutional repositories, national repositories, open data portals, InvenioRDM-based repositories, OSF-style project spaces, GitHub or GitLab repositories, domain-specific repositories, journal platforms, preprint repositories, secure repositories, public-good archives, and national data environments where appropriate.
1.6.4 Repository Selection Criteria. Repository selection shall consider data sensitivity, access class, license, DOI need, versioning need, software needs, metadata requirements, national data rules, community safeguards, Indigenous protocol-sensitive matters where applicable, public authority restrictions, cybersecurity risks, geospatial sensitivity, long-term preservation, citation needs, and interoperability with Nexus Registry.
1.6.5 DOI Discipline. A DOI or persistent identifier shall make a publication citable and discoverable. It shall not make the report approved, official, certified, current forever, unrestricted, safe for operational reliance, financeable, insurable, procurable, or executable.
1.6.6 Metadata Discipline. Nexus Reports shall use structured metadata aligned with Registry and Marketplace records. Metadata should include report family, output class, version, author and contributor roles, steward, Nexus component, country or region where applicable, WFEH-B tags, DRR / DRF / DRI tags, evidence class, access class, license, data-use labels, AI-use labels, public-safe status, review level, related identifiers, correction pathway, and archive status.
1.6.7 FAIR-Aligned Practice. Nexus Reports shall support findability, accessibility within rights, interoperability through controlled metadata and vocabularies, and reuse within license and governance limits. FAIR-aligned practice shall not require public release of restricted source material.
1.6.8 Public-Safe Deposit Rule. No report, dataset, code package, ontology, dashboard, media object, or supporting artefact shall be deposited in an open repository unless its rights, license, public-safe status, data-use labels, AI-use labels, privacy status, security status, safeguard status, and publication class permit open deposit.
1.6.9 Controlled Source Rule. Where source material cannot be made open, Nexus Reports may publish a public-safe report, abstract, metadata record, codebook, schema, synthetic example, aggregate summary, methods note, data availability statement, or restricted-access note while preserving controlled materials in DICE, Nexus Registry, Nexus Studio, secure rooms, data rooms, national repositories, protected archives, or other governed environments.
1.6.10 Open Infrastructure Boundary. Use of open-science infrastructure shall not override Nexus public-safe review, data governance, AI-use governance, protected knowledge controls, national routing, public authority boundaries, finance boundaries, procurement neutrality, sponsor boundaries, provider neutrality, correctionability, or non-execution.
1.7 National Portfolio as the Flagship Nexus Reports Function
1.7.1 Flagship Status. The National Portfolio Report shall be the flagship publication product of Nexus Reports. It shall make national risk and innovation work visible as a coherent public-safe portfolio across WFEH-B, DRR, DRF, DRI, data commons, risk ontology, observability, public-good technology, learning, campaigns, research, expertise pathways, Nexus Universe participation, support records, and lawful handoff dependencies.
1.7.2 National Portfolio Purpose. National Portfolio Reports shall help national stakeholders see their own ecosystem, identify evidence gaps, organize Working Groups, support Competence Cells, prepare Nexus Universe participation, guide Campaigns, generate Foundry tasks, inform Academy pathways, route Labs research, clarify DICE data needs, structure GRIx mappings, strengthen DRI contributions, identify Observatory requirements, and prepare lawful handoff questions.
1.7.3 National Ownership Before Publication. National Portfolio Reports shall preserve national ownership. They shall be prepared through national pathways where required, with attention to national law, national data rules, public authority structures, language, public-safe framing, community safeguards, Indigenous protocols where applicable, and national continuation routes.
1.7.4 Non-Ranking Discipline. National Portfolio Reports shall not rank countries, score governments, shame communities, compare national vulnerability for competitive advantage, create investor league tables, produce insurer ratings, allocate donor priority, or imply public authority failure. They shall be public-good portfolio records, not external judgment instruments.
1.7.5 WFEH-B Integration. National Portfolio Reports shall integrate water, food, energy, health, and biodiversity as interdependent systems. They shall identify cascading risks, shared dependencies, common data gaps, co-benefits, trade-offs, critical infrastructure links, climate and nature interactions, public health implications, food systems vulnerabilities, energy continuity issues, water security concerns, biodiversity dependencies, and innovation opportunities.
1.7.6 DRR Integration. National Portfolio Reports shall identify disaster risk reduction priorities, resilience needs, preparedness learning, infrastructure continuity, local capability, community priorities, public-safe communication needs, public authority learning needs, Campaign signals, Academy pathways, Observatory gaps, and Foundry build opportunities.
1.7.7 DRF Integration. National Portfolio Reports shall identify disaster risk finance questions, protection gaps, insurance-readiness questions, donor-readiness questions, public finance relevance, risk-layering assumptions, data needs, fiscal dependencies, institutional dependencies, affordability issues, and lawful handoff prerequisites without creating financeability or transaction readiness.
1.7.8 DRI Integration. National Portfolio Reports shall publish public-safe disaster risk intelligence summaries, indicator structures, confidence labels, uncertainty notes, DICE data status, GRIx category mappings, Observatory signal needs, dashboard summaries, and correction pathways without becoming warnings, ratings, rankings, insurance scores, or public authority classifications.
1.7.9 Technology and Innovation Integration. National Portfolio Reports may include AI, AI-RAN, O-RAN, private wireless, sovereign compute, HPC, cyber, geospatial, Earth observation, digital twins, robotics, drones, sensing, blockchain/DLT/Web3, quantum-relevant systems, advanced manufacturing, semiconductors, biosecurity, climate tech, nature tech, and related infrastructures as national capability pathways. Technology reporting shall identify readiness, safeguards, dependencies, data needs, AI-use limits, security constraints, and lawful handoff conditions.
1.7.10 National Portfolio Boundary. A National Portfolio Report shall make national work legible without becoming official national policy, public authority approval, sovereign rating, investment rating, insurance score, donor allocation tool, procurement plan, community consent record, Indigenous consent record where applicable, deployment authorization, or execution plan.
1.8 Nexus Reports Operating Principles
1.8.1 Public-Good Purpose. Nexus Reports shall serve public-good knowledge, public-safe reporting, evidence visibility, national portfolio formation, capability development, learning, correction, and lawful handoff awareness.
1.8.2 Expert-Grade Substance. Nexus Reports shall be written with the rigor expected by expert audiences, including clear definitions, methods, source classes, evidence limitations, data status, AI-use status, uncertainty, review labels, metadata, versioning, and correction pathways.
1.8.3 Multi-Audience Accessibility. Nexus Reports shall be usable by expert readers and intelligible to cross-sector readers. Reports may include executive summaries, technical sections, data notes, methods notes, public-safe summaries, visual atlases, dashboards, plain-language summaries, translations, accessible formats, and Academy derivatives.
1.8.4 Record-Linked Publication. Each material Nexus Report should link to Nexus Registry and, where appropriate, Nexus Marketplace, DICE, GRIx, DRI, Observatory, Studio, Grid, TRL, Foundry, Campaigns, Academy, Labs, Risk Agency, Nexus Universe, National Nodes, and lawful handoff records.
1.8.5 Metadata by Design. Nexus Reports shall be designed with metadata from the beginning, not after publication. Report family, output class, authorship, contributors, evidence class, review level, license, data-use labels, AI-use labels, public-safe status, DOI status, and correction status shall be part of the publication architecture.
1.8.6 Rights Before Reuse. Reports shall not release, cite, reproduce, summarize, translate, visualize, or package materials in ways that exceed rights, permissions, licenses, public-safe status, data-use labels, AI-use labels, community safeguards, public authority restrictions, or protected knowledge controls.
1.8.7 Sensitivity by Design. Sensitive records shall be identified early. Public authority-sensitive, community-sensitive, Indigenous-protocol-sensitive where applicable, youth-sensitive, health-sensitive, infrastructure-sensitive, cyber-sensitive, geospatial-sensitive, humanitarian-sensitive, protected knowledge, and finance-sensitive materials shall be handled through appropriate controls.
1.8.8 Correction by Design. Every report shall include a correction pathway. Reports shall state how to report errors, what version is current, how corrections will be handled, and how superseded versions should be treated.
1.8.9 Non-Conversion by Design. Each report shall include no-conversion language appropriate to its output class. A report shall state what it does not do where a reasonable reader might infer approval, certification, financeability, procurement, official status, consent, deployment, or execution.
1.8.10 Archive by Design. Reports shall have archive status rules. Archive shall preserve memory while preventing stale reports from being treated as current.
1.9 Pillar Interfaces and Institutional Relationships
1.9.1 Interface with Nexus Registry. Nexus Reports shall use Nexus Registry as the status-truth layer for report records, report families, publication status, DOI status, contributor records, correction history, public-safe status, archive state, and linked system records.
1.9.2 Interface with Nexus Marketplace. Nexus Reports may be listed through Nexus Marketplace for discovery, support, reuse, learning, and routing. Marketplace listings shall not convert reports into approvals, certifications, procurements, finance signals, or public authority actions.
1.9.3 Interface with Nexus Foundry. Nexus Foundry outputs may become Nexus Reports, and Nexus Reports may generate Foundry tasks, quests, bounties, builds, public-good software, open technical baselines, Studio workflows, DICE tasks, GRIx tasks, DRI tasks, Observatory tasks, and lawful handoff dependencies.
1.9.4 Interface with Nexus Campaigns. Nexus Campaigns may generate report inputs, and Nexus Reports may provide public-safe evidence for campaigns. Campaign report outputs shall not create public mandates, votes, public authority approval, community consent, donor commitment, procurement signal, or finance signal.
1.9.5 Interface with Nexus Academy and Risk Academy. Nexus Reports may become reading materials, modules, WILP materials, micro-credential resources, reviewer training content, maintainer training content, public authority learning materials, and Nexus Universe preparation resources.
1.9.6 Interface with Nexus Labs. Nexus Reports may publish research streams, evidence gaps, testbed summaries, methods papers, research-to-Foundry outputs, public-safe technical summaries, and future research calls without creating ethics approval, data rights, funding approval, or implementation authority.
1.9.7 Interface with Risk Agency. Nexus Reports may identify expertise gaps, advisory demand, training needs, and lawful support pathways. Risk Agency-related reports shall not certify experts, create professional engagements, or provide professional advice by implication.
1.9.8 Interface with DICE, GRIx, DRI, and Observatory. Nexus Reports shall translate data commons, ontology, intelligence, and observability work into public-safe publications. It shall preserve labels, restrictions, uncertainty, limitations, public-safe boundaries, and correction pathways.
1.9.9 Interface with Nexus Studio, Grid, and TRL. Nexus Reports may summarize Studio workflows, Grid inputs, and TRL evidence notes. Such summaries shall retain non-decision, no-certification, no-deployment, no-procurement, and no-finance boundaries.
1.9.10 Interface with Nexus Universe. Nexus Reports shall be a central output layer for Nexus Universe. It shall produce annual-cycle reports, arena reports, Core Build reports, National Portfolio Reports, public authority learning summaries, readiness room summaries, Campaign reports, Academy reports, support reports, and continuation reports.
1.9.11 Interface with National Nodes and National Nexus Consortiums. Nexus Reports shall support national ownership by routing country-level publications through appropriate national pathways, public-safe review, data controls, community safeguards, language localization, and national continuation logic.
1.9.12 Interface with Enterprise Stack and Handoff. Nexus Reports may support lawful handoff dependency packages by summarizing evidence, data status, dependencies, safeguards, public authority questions, finance and insurance questions, provider-neutrality notes, sponsor-boundary notes, and recipient responsibilities. Reports shall not authorize implementation.
1.10 Final Operating Statement
1.10.1 Final Pillar Identity. Nexus Reports shall be the Nexus Pillar that converts the ecosystem’s distributed public-good work into citable, public-safe, evidence-bearing, versioned, discoverable, reusable within rights, corrected, and archived knowledge products. It shall be the publication layer of Nexus, but also more than publication: it shall be the knowledge-memory, evidence-translation, national-portfolio, open-science, public-safe reporting, and correction pillar.
1.10.2 Final Strategic Function. Nexus Reports shall allow Nexus to become visible to the world without becoming unsafe, overclaimed, ungoverned, sponsor-captured, provider-validated, public-authority-confused, finance-misread, procurement-distorted, consent-overclaimed, or execution-implied. It shall provide the durable knowledge interface through which national portfolios, WFEH-B systems, DRR, DRF, DRI, DICE, GRIx, Observatory, Foundry, Campaigns, Academy, Labs, Risk Agency, Nexus Universe, Grid, TRL, and lawful handoff become intelligible and usable.
1.10.3 Final Open-Knowledge Rule. Nexus Reports shall use Zenodo and similar open-science infrastructure to publish public-safe outputs with persistent identifiers, metadata, versioning, and citation where appropriate. It shall also preserve controlled-source governance where openness would create harm, violate rights, expose protected knowledge, compromise public authorities, endanger communities, weaken cybersecurity, reveal sensitive geospatial information, or create false reliance.
1.10.4 Final National Portfolio Rule. National Portfolio Reports shall be the flagship Nexus Reports family. They shall showcase national risk and innovation capacity across WFEH-B, DRR, DRF, DRI, public-good technology, national capability, Campaigns, Foundry outputs, Academy learning, Labs research, Risk Agency pathways, DICE data commons, GRIx ontology, Observatory needs, Nexus Universe participation, support records, and lawful handoff dependencies. They shall make national work legible without ranking, judging, approving, warning, financing, insuring, procuring, consenting, deploying, or executing for the country.
1.10.5 Final Boundary Rule. No Nexus Report, DOI, repository record, dataset, software release, ontology, schema, dashboard, public-safe summary, National Portfolio Report, WFEH-B report, DRR report, DRF report, DRI report, DICE report, GRIx report, Observatory report, Foundry report, Campaign report, Academy report, Labs report, Risk Agency report, Nexus Universe report, public authority learning report, Grid or TRL evidence summary, Marketplace listing, Registry record, citation, download count, view count, contributor role, support acknowledgment, sponsor acknowledgment, provider acknowledgment, public authority participation note, correction notice, archive record, or handoff summary shall create endorsement, recognition, approval, certification, accreditation, professional license, academic degree, employment eligibility, procurement eligibility, supplier approval, financeability, insurability, underwriting acceptance, investment readiness, donor commitment, public finance allocation, rating, ranking, public authority approval, official classification, public warning, policy adoption, agency, partnership, professional standing, community consent, Indigenous consent where applicable, consultation completion, protected knowledge permission, land access, deployment authorization, operational command, or execution by implication.
1.10.6 Final Declaration. Nexus Reports shall be powerful because it gives Nexus a rigorous publication pillar; legitimate because it is evidence-bearing and correctionable; useful because it is discoverable and citable; safe because it is public-safe and rights-aware; expert-grade because it is method-based and metadata-rich; open because it uses responsible open-science infrastructure; protected because it keeps sensitive sources governed; national because it preserves national ownership; ecosystemic because it integrates all Nexus mechanisms; and trustworthy because it refuses to let publication become authority.
2. Publication Families, Output Classes, Report Taxonomy, and Knowledge Product Architecture
2.1 Publication Family Doctrine
2.1.1 Publication Families as Governance Architecture. Nexus Reports shall organize all publications into defined Publication Families so that each output has a clear institutional purpose, evidence basis, audience, review requirement, metadata structure, public-safe status, data-use status, AI-use status, licensing posture, repository strategy, Registry linkage, Marketplace discoverability status, correction pathway, and archive rule. Publication Families shall prevent Nexus Reports from becoming an unstructured library of documents, promotional releases, disconnected research artefacts, or uncontrolled public statements.
2.1.2 Publication Families as Boundary Discipline. Each Publication Family shall carry its own no-conversion boundaries. A National Portfolio Report shall not be a country rating. A DRR Report shall not be an official warning. A DRF Report shall not be a finance product. A DRI Report shall not be an insurance score or public authority classification. A Foundry Report shall not be deployment approval. A Campaign Report shall not be a public mandate. An Academy Report shall not be a professional credential. A Labs Report shall not be research ethics approval. A Risk Agency Report shall not certify experts. A Nexus Universe Report shall not imply endorsement by presence. A Grid or TRL Evidence Summary shall not certify maturity or safety.
2.1.3 Publication Families as Ecosystem Routing. Publication Families shall determine how outputs route through the Nexus Ecosystem. A DICE Report may route to data stewardship and metadata improvement; a GRIx Report may route to ontology refinement; a DRI Report may route to dashboards and public-safe intelligence; a National Portfolio Report may route to Campaigns, Working Groups, Competence Cells, Nexus Universe arenas, Academy modules, Foundry tasks, and lawful handoff dependency packages; a Nexus Universe Report may route to annual-cycle continuation; a Correction Report may route across Registry, Marketplace, Studio, Grid, TRL, Network, Rails, and archive.
2.1.4 Publication Families as Expert Legibility. Publication Families shall make Nexus outputs legible to expert readers by making clear whether an output is a research report, public-safe summary, methods note, technical artefact, evidence pack, national portfolio, data paper, software release, ontology release, dashboard note, readiness note, learning report, campaign report, annual-cycle report, handoff context note, or correction notice. This classification shall allow expert audiences to understand what standard of evidence, review, reproducibility, public-safe transformation, and reliance limit applies.
2.1.5 Publication Family Record. Each Publication Family shall have a Registry-controlled description identifying its purpose, permitted output classes, required metadata, review levels, public-safe requirements, data-use and AI-use requirements, licensing options, repository options, correction requirements, archive rules, and standard boundary language.
2.1.6 Publication Series. Nexus Reports may maintain formal series within each Publication Family, including national series, regional series, global series, thematic series, sector series, technology series, Nexus Universe cycle series, DICE series, GRIx series, DRI series, Observatory series, Foundry series, Academy series, Campaign series, Labs series, Risk Agency series, and correction series. Series membership shall assist discovery and continuity but shall not imply endorsement, ranking, maturity, certification, or approval.
2.1.7 Publication Family Stewardship. Each Publication Family may have one or more Publication Family Stewards responsible for taxonomy, templates, review expectations, metadata discipline, no-conversion language, repository strategy, Registry linkage, Marketplace listing rules, correction procedure, and archive procedure. Stewardship shall be process stewardship only and shall not create certification authority or public authority status.
2.1.8 Publication Family Boundary. Publication Family classification shall organize knowledge, not grant authority. Placement within a prestigious series, national collection, Nexus Universe collection, Zenodo community, Registry collection, Marketplace collection, or curated Nexus Reports page shall not create approval, endorsement, procurement status, financeability, insurability, certification, public authority approval, consent, deployment authorization, or execution.
2.2 Nexus Reports Output Classes
2.2.1 Output-Class Requirement. Every Nexus Reports publication object shall be assigned an Output Class. Output Class shall identify the nature of the artefact, its expected evidence basis, publication format, review level, metadata requirement, access class, repository strategy, versioning rule, and correction method.
2.2.2 Report. A Report shall be a substantive structured publication presenting evidence, analysis, synthesis, portfolio information, systems mapping, public-safe findings, methods, recommendations framed as non-binding options or questions where appropriate, limitations, and correction pathways. A Report shall be used for major national, thematic, annual-cycle, technical, or institutional outputs.
2.2.3 Brief. A Brief shall be a shorter public-safe publication translating evidence, concepts, options, dependencies, findings, or questions for defined audiences. Briefs may include policy briefs, public authority learning briefs, public-safe briefs, national briefing notes, WFEH-B briefs, DRR briefs, DRF briefs, DRI briefs, technology briefs, and handoff context briefs. A Brief shall not be official policy, public authority advice, investment advice, insurance advice, procurement advice, or legal advice by implication.
2.2.4 Technical Note. A Technical Note shall document technical methods, systems architecture, software logic, data structures, models, APIs, workflows, simulations, digital twin components, Observatory methods, DICE schemas, GRIx mappings, DRI indicators, Grid inputs, TRL evidence, or Foundry builds. A Technical Note shall describe technical context without certifying technical quality, safety, cybersecurity, deployment readiness, procurement suitability, financeability, or public authority approval.
2.2.5 Methods Paper. A Methods Paper shall document repeatable methods, evidence practices, data-processing approaches, public-safe transformation methods, ontology methods, index methodology, dashboard methods, modelling assumptions, observation protocols, review methods, or Nexus publication methods. A Methods Paper shall distinguish method design from validation, certification, standard-setting, or official adoption.
2.2.6 Data Paper. A Data Paper shall describe a dataset, metadata package, data commons object, data dictionary, schema, codebook, lineage record, access condition, data quality status, limitations, data-use labels, AI-use labels, licensing status, and public-safe release status. A Data Paper may accompany open, controlled, restricted, or metadata-only data. It shall not make restricted data open or unrestricted.
2.2.7 Software Release. A Software Release shall publish or document public-good software, code, scripts, connectors, APIs, SDKs, dashboards, models, agents, notebooks, automation workflows, templates, or technical baselines. A Software Release shall include version, license, support class, dependencies, security status, vulnerability reporting pathway, known limitations, citation, no-warranty notice, no-certification notice, and no-deployment notice.
2.2.8 Ontology or Schema Release. An Ontology or Schema Release shall publish controlled vocabulary, taxonomy, semantic mappings, data schemas, metadata schemas, indicator dictionaries, risk categories, DICE structures, GRIx mappings, DRI indicator structures, or interoperability patterns. Such release shall not be a legal standard, regulatory classification, official taxonomy, or standards-conformance certification unless separately and lawfully established.
2.2.9 Evidence Pack. An Evidence Pack shall assemble public-safe evidence, source summaries, data notes, methodology, limitations, review labels, records, diagrams, dashboards, or technical artefacts supporting a report, National Portfolio, Nexus Universe output, Foundry build, or handoff dependency package. Evidence Packs may be public, controlled, restricted, data-room-only, secure-room-only, or handoff-recipient-only.
2.2.10 Public-Safe Summary. A Public-Safe Summary shall translate sensitive, technical, controlled, or complex material into a public-facing form that removes or mitigates public authority overclaim, protected knowledge exposure, geospatial sensitivity, cyber-sensitive details, finance overclaim, procurement overclaim, certification overclaim, consent overclaim, panic risk, and execution implication. A Public-Safe Summary shall not replace the controlled source record.
2.2.11 Atlas. An Atlas shall be a structured visual and narrative publication presenting maps, dashboards, diagrams, systems views, national portfolios, WFEH-B dependencies, DRI indicators, GRIx categories, DICE metadata, observability needs, innovation capabilities, or Nexus Universe outputs. An Atlas shall not be an official hazard map, national ranking, investor map, insurer score, public authority map, procurement catalogue, or deployment plan.
2.2.12 Dashboard Publication. A Dashboard Publication shall publish or document a public-safe dashboard, indicator view, data visualization, risk-intelligence display, national portfolio view, Observatory summary, or Nexus Universe output. Dashboard Publications shall include data-use labels, AI-use labels, uncertainty, limitations, refresh status, correction status, and no-warning / no-rating / no-procurement / no-finance notices where relevant.
2.2.13 Learning Package. A Learning Package shall convert Nexus Reports material into Academy, Risk Academy, WILP, micro-credential, reviewer training, maintainer training, data stewardship training, AI-use training, public-safe communication training, safeguard training, or public authority learning content. Learning Packages shall not create professional licensure, academic credit, expert certification, employment eligibility, or procurement qualification unless separately and lawfully recorded.
2.2.14 Handoff Context Note. A Handoff Context Note shall summarize evidence, dependencies, public authority questions, legal questions, data-use conditions, AI-use conditions, safeguard conditions, finance and insurance questions, provider-neutrality notes, sponsor-boundary notes, recipient responsibilities, and no-reliance limits for lawful downstream actors. It shall not authorize implementation.
2.2.15 Correction Notice. A Correction Notice shall identify an error, overclaim, status change, data-use change, AI-use change, public-safe correction, provider correction, sponsor correction, public authority language correction, finance boundary correction, procurement boundary correction, consent correction, withdrawal, supersession, or archive update. Correction Notices shall be citable where public reliance or downstream use requires it.
2.2.16 Archive Record. An Archive Record shall preserve prior outputs, retired reports, withdrawn reports, superseded reports, recalled outputs, old datasets, prior software releases, obsolete dashboards, closed Nexus Universe cycle outputs, non-continuing publications, and historic records with Archive-Not-Current notices.
2.2.17 Output-Class Boundary. Output Classes define form and use; they do not create authority. No output class shall be interpreted as approval, certification, public authority decision, procurement recommendation, finance advice, insurance advice, community consent, Indigenous consent where applicable, deployment authorization, operational command, or execution.
2.3 National Portfolio Report Family
2.3.1 National Portfolio Report Family Defined. The National Portfolio Report Family shall be the flagship publication family of Nexus Reports and shall provide the structured public-safe form for presenting national risk and innovation portfolios across WFEH-B, DRR, DRF, DRI, exponential technologies, data commons, observability, public-good software, public authority learning, Campaign mobilization, Academy pathways, Foundry outputs, Labs research, Risk Agency pathways, Nexus Universe participation, support records, and lawful handoff dependencies.
2.3.2 Primary Purpose. National Portfolio Reports shall allow national stakeholders to see their ecosystem as a coherent public-good portfolio: what risks are being framed; what innovation capabilities exist; what data gaps remain; what public-safe intelligence has been produced; what Working Groups and Competence Cells are forming; what Academy pathways are needed; what Campaigns have mobilized; what Foundry builds are underway; what Nexus Universe outputs exist; what support is needed; what readiness questions remain; and what lawful handoff dependencies require attention.
2.3.3 National Ownership and Routing. National Portfolio Reports shall be prepared through appropriate national pathways where required. They shall preserve national ownership, national law, national data rules, national public authority structures, national language needs, national capability realities, community safeguards, Indigenous protocols where applicable, public-safe publication, and lawful continuation. They shall not allow external actors to bypass national pathways.
2.3.4 National Portfolio as Showcase Without Ranking. National Portfolio Reports may showcase national work, contribution, readiness, innovation, and public-good capability. They shall not rank countries, score governments, compare vulnerability for market advantage, shame communities, create donor priority rankings, produce investor league tables, create insurance scores, or function as public authority scorecards.
2.3.5 Required National Portfolio Components. A National Portfolio Report may include national context, WFEH-B systems overview, DRR priorities, DRF readiness questions, DRI indicator summaries, DICE data status, GRIx ontology mappings, Observatory needs, technology and innovation capabilities, Campaign records, Academy pathways, Foundry tasks, Working Group outputs, Competence Cell outputs, Labs research pathways, Risk Agency expertise pathways, Nexus Universe participation, support records, public authority learning records, community safeguards, correction history, and handoff dependency candidates.
2.3.6 WFEH-B Integration Requirement. National Portfolio Reports shall treat water, food, energy, health, and biodiversity as interdependent systems. They shall identify cross-system dependencies, cascading risks, institutional gaps, infrastructure dependencies, public health implications, ecosystem service links, digital public goods, observability needs, geospatial requirements, data needs, and innovation opportunities.
2.3.7 DRR Integration Requirement. National Portfolio Reports shall include DRR learning where relevant, including risk reduction priorities, resilience needs, preparedness learning, prevention opportunities, infrastructure continuity, community priorities, public-safe communication needs, Campaign signals, Academy needs, Observatory gaps, and Foundry opportunities.
2.3.8 DRF Integration Requirement. National Portfolio Reports shall include DRF readiness where relevant, including protection gaps, insurance-readiness questions, risk-layering assumptions, fiscal exposure context, donor-readiness questions, public finance relevance, data gaps, institutional dependencies, affordability issues, and handoff prerequisites. DRF reporting shall be no-reliance, non-advisory, non-soliciting, and non-transactional.
2.3.9 DRI Integration Requirement. National Portfolio Reports shall include public-safe DRI contributions where relevant, including indicator structures, uncertainty labels, confidence labels, DICE data status, GRIx category mappings, Observatory signal needs, dashboard summaries, and correction pathways. DRI reporting shall not become official warning, public authority classification, national rating, insurance score, or investment signal.
2.3.10 Technology and Innovation Integration Requirement. National Portfolio Reports may cover AI, AI-RAN, O-RAN, private wireless, sovereign compute, HPC, cyber, geospatial, Earth observation, digital twins, robotics, drones, sensing, blockchain/DLT/Web3, quantum-relevant systems, advanced manufacturing, semiconductors, biosecurity, climate tech, nature tech, infrastructure technology, and public-good digital infrastructure as national capability pathways. Technology sections shall state readiness, safeguards, dependencies, security limits, data requirements, public authority boundaries, and handoff conditions.
2.3.11 Public Authority Learning Treatment. National Portfolio Reports may reference public authority learning, technical dialogue, public-safe briefings, Studio learning workflows, and Nexus Universe public authority learning rooms. Such references shall not imply policy adoption, official approval, procurement action, public finance allocation, regulatory comfort, public warning, or public authority decision.
2.3.12 National Portfolio Boundary. National Portfolio Reports shall be national public-good knowledge products. They shall not be official national plans unless separately and lawfully adopted; they shall not be public authority approvals; they shall not be investment memoranda; they shall not be insurance submissions; they shall not be procurement documents; they shall not be consent records; and they shall not be execution plans.
2.4 WFEH-B Nexus Report Family
2.4.1 WFEH-B Report Family Defined. The WFEH-B Nexus Report Family shall publish public-safe and expert-grade knowledge on the interdependencies among water, food, energy, health, and biodiversity systems, including risk pathways, resilience gaps, innovation opportunities, data needs, public-good software needs, observability requirements, DRR relevance, DRF relevance, DRI relevance, and national portfolio implications.
2.4.2 Systems Orientation. WFEH-B Reports shall avoid siloed treatment of sectors. They shall analyze system interactions, cascades, feedback loops, dependencies, trade-offs, co-benefits, institutional arrangements, technology interfaces, data infrastructure, financing questions, community safeguards, public authority learning needs, and lawful handoff dependencies.
2.4.3 Water Domain. WFEH-B Reports may address water security, water quality, watersheds, groundwater, drought, floods, water infrastructure, sanitation, agriculture-water interactions, hydropower, public health links, biodiversity dependencies, remote sensing, sensor networks, digital twins, public-safe dashboards, and water-related DRR/DRF/DRI questions.
2.4.4 Food Domain. WFEH-B Reports may address food systems resilience, agricultural risk, supply chains, food security, soil health, crop risk, livestock risk, fisheries, nutrition, logistics, cold chains, energy dependencies, water dependencies, biodiversity dependencies, climate stress, pests, biosecurity, geospatial intelligence, and innovation opportunities.
2.4.5 Energy Domain. WFEH-B Reports may address energy resilience, grid continuity, distributed energy, clean energy, critical infrastructure, fuel supply, energy-water dependencies, health facility power, food system energy needs, biodiversity impacts, energy poverty, digital infrastructure, AI-RAN/O-RAN/private wireless, Edge compute, cybersecurity, and disaster continuity.
2.4.6 Health Domain. WFEH-B Reports may address public health resilience, climate-sensitive health risks, health system continuity, disease surveillance boundaries, heat risk, water-borne disease, food safety, air quality, mental health after disasters, health data sensitivity, public authority boundaries, privacy, AI-use limitations, and health-related DRR/DRF/DRI needs.
2.4.7 Biodiversity Domain. WFEH-B Reports may address biodiversity loss, ecosystem services, nature-based solutions, protected areas, species and habitat sensitivity, geospatial sensitivity, Indigenous protocol-sensitive knowledge where applicable, restoration, climate-nature interactions, water-food-energy-health dependencies, and nature-related observability.
2.4.8 Data and Intelligence Layer. WFEH-B Reports shall integrate DICE data status, GRIx risk ontology, DRI indicators, Observatory needs, public-safe dashboards, uncertainty labels, data gaps, AI-use limits, and correction pathways. They shall not overstate data completeness or operational reliability.
2.4.9 Finance and Handoff Layer. WFEH-B Reports may identify DRF relevance, finance-readiness questions, insurance-readiness questions, public finance relevance, donor-readiness questions, infrastructure dependencies, and lawful handoff candidates. They shall not create investment advice, insurance approval, donor commitment, public finance allocation, or procurement recommendation.
2.4.10 WFEH-B Boundary. WFEH-B Reports shall support systems understanding and public-good action pathways. They shall not create official sector policy, public authority approval, environmental permit, project consent, insurance score, procurement recommendation, investment rating, or deployment authorization.
2.5 Disaster Risk Reduction Report Family
2.5.1 DRR Report Family Defined. The Disaster Risk Reduction Report Family shall publish public-safe knowledge on disaster risk reduction, resilience, preparedness, prevention, systems vulnerability, exposure reduction, capability development, community resilience, infrastructure continuity, public authority learning, Campaign mobilization, Foundry tasks, Academy pathways, and National Portfolio implications.
2.5.2 DRR Purpose. DRR Reports shall help stakeholders understand risk reduction needs, prevention opportunities, resilience gaps, observability gaps, data needs, public-safe communication needs, training needs, national capability needs, and Nexus continuation pathways. They shall support learning and capability formation without becoming operational command.
2.5.3 Hazard and Systems Scope. DRR Reports may cover floods, droughts, wildfire, heat, storms, earthquakes, landslides, pandemics, public health emergencies, infrastructure failures, cyber-physical disruptions, food system shocks, energy disruptions, water crises, biodiversity-related risks, compound risks, cascading risks, and systemic risks.
2.5.4 Public-Safe Risk Communication. DRR Reports shall present risk information in a way that is accurate, bounded, non-panicking, non-operational, and clear about limitations. They shall avoid official warning language, evacuation language, emergency command language, casualty speculation, blame, unsupported projections, or public authority substitution.
2.5.5 Community and Safeguard Integration. DRR Reports shall consider community vulnerability, accessibility, disability inclusion, youth protection, humanitarian sensitivity, protected knowledge, Indigenous protocols where applicable, geospatial sensitivity, and community participation without consent overclaim.
2.5.6 Observatory and DRI Integration. DRR Reports may use Observatory needs, DRI indicators, DICE metadata, GRIx mappings, dashboards, public-safe maps, and Studio workflow summaries to support risk reduction learning. Such outputs shall not become official hazard maps, public warnings, or emergency guidance.
2.5.7 Campaign and Academy Integration. DRR Reports may generate Campaign actions, volunteer roles, Working Group tasks, Competence Cell formation, Academy modules, WILP assignments, micro-credential materials, and Nexus Universe preparation pathways.
2.5.8 Foundry and Technical Output Integration. DRR Reports may identify Foundry builds, public-good software needs, open technical baselines, data pipelines, dashboards, digital twins, sensor integration, AI workflows, community tools, and technical packs. Such identification shall not authorize deployment.
2.5.9 DRR Boundary. DRR Reports shall not be public warnings, emergency alerts, disaster declarations, operational instructions, official hazard maps, public safety commands, regulatory actions, procurement plans, or implementation approvals.
2.5.10 DRR Final Formula. DRR Reports shall make risk reduction knowledge visible, teachable, actionable as learning, and routable to public-good pathways while preserving the authority of competent public authorities, communities, lawful operators, and official emergency systems.
2.6 Disaster Risk Finance Report Family
2.6.1 DRF Report Family Defined. The Disaster Risk Finance Report Family shall publish no-reliance public-safe and expert-grade knowledge on disaster risk finance readiness, protection gaps, risk-layering questions, fiscal exposure context, finance-readiness dependencies, insurance-readiness questions, donor-readiness questions, public finance relevance, data gaps, assumptions, diligence gaps, and lawful handoff dependencies.
2.6.2 DRF Purpose. DRF Reports shall make finance-related questions legible without creating financial conclusions. They may help stakeholders understand what evidence, data, institutional arrangements, risk information, public authority dependencies, legal structures, safeguards, and implementation conditions may be relevant to downstream finance, insurance, donor, or public finance processes.
2.6.3 No-Relevance-to-Reliance Conversion. A DRF Report may identify relevance to finance, insurance, donors, public finance, resilience investment, protection gaps, or handoff. Such relevance shall not mean financeability, bankability, insurability, underwriting acceptance, investment readiness, donor commitment, public finance allocation, valuation, rating, guarantee approval, solicitation, offer, or transaction readiness.
2.6.4 DRF Content Classes. DRF Reports may include protection gap summaries, risk-layering maps, public-safe exposure summaries, DRI indicator implications, DICE data gaps, GRIx risk categories, assumptions registers, dependency registers, diligence-gap notes, public finance relevance questions, donor-readiness questions, insurance-readiness questions, affordability questions, legal dependency notes, and handoff context.
2.6.5 Capital and Insurance Reader Boundaries. Capital readers, insurers, reinsurers, donors, philanthropies, development actors, and public finance readers may read DRF Reports as learning and context only. Their participation, questions, downloads, repository access, Nexus Universe attendance, or readiness-room presence shall not imply investment interest, underwriting interest, donor commitment, public finance interest, approval, allocation, valuation, rating, guarantee, or transaction readiness.
2.6.6 Regulated-Perimeter Controls. DRF Reports shall avoid investment advice, securities promotion, lending advice, insurance advice, underwriting conclusions, public finance commitments, donor commitments, valuation, ratings, bankability claims, finance-ready labels, insured labels, guaranteed labels, or transaction language unless separately lawful, controlled, and outside the default Nexus Reports posture.
2.6.7 DRF and Public Authority Boundary. DRF Reports may identify public authority dependencies and public finance relevance. They shall not create public finance allocation, budget approval, subsidy approval, guarantee approval, sovereign approval, procurement status, fiscal commitment, or public authority decision.
2.6.8 DRF and Handoff. DRF Reports may inform lawful handoff dependency packages by summarizing finance and insurance questions, data needs, public authority dependencies, legal dependencies, safeguard dependencies, provider-neutrality notes, sponsor-boundary notes, and recipient responsibilities. Handoff use shall be no-reliance.
2.6.9 DRF Correction. DRF Reports shall be corrected where financeability, insurability, public finance relevance, donor status, assumptions, data status, public authority dependency, legal dependency, or readiness language becomes inaccurate or overclaimed.
2.6.10 DRF Boundary. DRF Reports shall not create finance, insurance, underwriting, investment, donor, public finance, guarantee, valuation, rating, solicitation, offer, transaction readiness, procurement status, or public authority approval.
2.7 Disaster Risk Intelligence Report Family
2.7.1 DRI Report Family Defined. The Disaster Risk Intelligence Report Family shall publish public-safe disaster risk intelligence outputs, indicator frameworks, dashboard summaries, systems-risk interpretations, DICE-linked data status, GRIx-linked risk categories, Observatory-linked signal needs, uncertainty labels, confidence labels, limitations, correction history, and National Portfolio contributions.
2.7.2 DRI Purpose. DRI Reports shall make disaster risk intelligence legible and useful for learning, preparedness, resilience planning, data stewardship, Campaign mobilization, Academy learning, Foundry tasks, public authority learning, National Portfolio formation, and lawful handoff context.
2.7.3 Intelligence Without Warning. DRI Reports shall not be official warnings, emergency alerts, evacuation guidance, public safety directives, hazard declarations, public health orders, or public authority classifications. They shall state whether they are public-safe learning outputs, dashboard summaries, indicator reports, methods notes, or evidence summaries.
2.7.4 Indicator Discipline. DRI Reports shall identify indicator definitions, data sources, DICE metadata status, GRIx ontology linkages, update frequency where relevant, uncertainty, limitations, confidence labels, missing data, sensitivity, public-safe transformation, and correction pathway.
2.7.5 Dashboard Discipline. DRI dashboard outputs shall identify data-use labels, AI-use labels, public-safe status, update status, geographic resolution, geospatial sensitivity, uncertainty, confidence, source limitations, interpretation limits, and no-warning / no-rating / no-procurement / no-finance boundaries.
2.7.6 Systems-Risk Interpretation. DRI Reports may interpret cascading risk, compound risk, WFEH-B dependencies, infrastructure dependencies, community vulnerability, climate and nature risk, digital infrastructure exposure, cyber-physical risk, and observability gaps. Interpretations shall be public-safe and limitation-aware.
2.7.7 DRI and AI. DRI Reports may use AI-assisted summarization, classification, indicator synthesis, anomaly review, dashboard support, or public-safe drafting only where AI-use labels permit, human review occurs, and sources remain verified. AI-generated interpretations shall not be presented as authoritative facts without review.
2.7.8 DRI and Handoff. DRI Reports may support handoff dependency packages by identifying data gaps, indicator limitations, uncertainty, public authority dependencies, and recipient responsibilities. They shall not authorize implementation or operational decisions.
2.7.9 DRI Correction. DRI Reports shall be corrected or withdrawn where data errors, indicator errors, dashboard errors, uncertainty errors, public-safe interpretation errors, geospatial exposure, public warning confusion, insurance-score overclaim, investment-signal overclaim, or public authority overclaim occurs.
2.7.10 DRI Boundary. DRI Reports shall not create official risk ratings, public warnings, public authority classifications, insurance scores, investment ratings, country rankings, procurement criteria, emergency commands, deployment authorization, or execution authority.
2.8 DICE, GRIx, Observatory, and Technical Knowledge Report Families
2.8.1 DICE Report Family. DICE Reports shall publish public-safe data commons architecture, metadata models, schema releases, data dictionaries, data lineage, data-use labels, AI-use labels, access conditions, data stewardship models, FAIR-aligned metadata, secure-room models, compute-to-data workflows, and controlled-source summaries.
2.8.2 DICE Boundary. DICE Reports shall not make restricted data public, grant data rights, permit AI training, authorize commercial use, override national data rules, override public authority restrictions, override community safeguards, or transfer data rights by metadata publication.
2.8.3 GRIx Report Family. GRIx Reports shall publish risk ontology, taxonomies, controlled vocabularies, WFEH-B categories, DRR/DRF/DRI mappings, indicator logic, index-like methods, systems-risk categories, maturity language where applicable, and correction records.
2.8.4 GRIx Boundary. GRIx Reports shall not create official classifications, sovereign ratings, country rankings, credit scores, insurance scores, public authority risk categories, procurement categories, or regulated standards unless separately and lawfully established.
2.8.5 Observatory Report Family. Nexus Observatory Reports shall publish observability methods, node concepts, signal needs, sensor and Edge patterns, geospatial summaries, Earth observation needs, digital twin needs, dashboard patterns, public-safe observability outputs, and correction needs.
2.8.6 Observatory Boundary. Observatory Reports shall not create surveillance authority, public warning authority, monitoring command, public authority classification, operational deployment authority, or data collection permission by publication.
2.8.7 Technical Architecture Reports. Nexus Reports may publish technical architecture notes for AI, AI-RAN, O-RAN, private wireless, HPC, sovereign compute, cyber, geospatial, digital twins, blockchain/DLT/Web3, quantum-relevant systems, robotics, drones, sensing, biosecurity, advanced manufacturing, semiconductors, and other frontier technologies. Such reports shall include readiness limits, safety limits, cyber limits, data limits, AI-use limits, public authority boundaries, and deployment disclaimers.
2.8.8 Software and Open Technical Baseline Reports. Nexus Reports may publish public-good software reports, open technical baseline notes, API documentation, SDK notes, schema releases, model cards, system cards, benchmark cards, and reproducibility packages. Such reports shall not create warranty, certification, procurement suitability, security approval, safety approval, or deployment readiness.
2.8.9 Technical Incident and Correction Reports. Technical report families may include vulnerability notices, correction notices, deprecation notices, withdrawal notices, upgrade notes, dependency warnings, and archive records where public-safe and appropriate.
2.8.10 Technical Knowledge Boundary. Technical knowledge publication shall support learning, reuse within rights, public-good development, and evidence visibility. It shall not authorize technical deployment, certify safety, certify cybersecurity, approve public authority use, approve procurement, or execute systems.
2.9 Nexus Foundry, Campaigns, Academy, Labs, Risk Agency, and Nexus Universe Report Families
2.9.1 Foundry Report Family. Nexus Foundry Reports shall publish outputs from Foundry programs, tracks, quests, bounties, builds, public-good software, technical packs, open baselines, Studio workflow candidates, Nexus Core Build outputs, TRL evidence summaries, support needs, contribution records, correction records, and handoff dependencies.
2.9.2 Foundry Boundary. Foundry Reports shall not imply production readiness, product approval, deployment approval, procurement readiness, provider validation, financeability, public authority approval, or execution by Nexus.
2.9.3 Campaign Report Family. Nexus Campaign Reports shall publish public-safe campaign outcomes, signatures, support summaries, volunteer mobilization, Working Group formation, Competence Cell formation, DICE contributions, DRI contributions, Academy participation, Nexus Universe readiness, public-safe reporting, correction records, and continuation pathways.
2.9.4 Campaign Boundary. Campaign Reports shall not convert signatures into votes, pledges into donor commitments, support into control, volunteer participation into employment, community participation into consent, public authority attention into approval, or campaign visibility into public mandate.
2.9.5 Academy Report Family. Nexus Academy and Risk Academy Reports shall publish learning pathways, WILP outputs, micro-credential summaries, iCRS records, skills maps, public authority learning materials, reviewer training, maintainer training, data stewardship training, AI-use training, safeguard training, accessibility training, and Nexus Universe preparation materials.
2.9.6 Academy Boundary. Academy Reports shall not create professional licensure, academic degrees, employment eligibility, procurement qualification, expert certification, public authority status, or execution authority.
2.9.7 Labs Report Family. Nexus Labs Reports shall publish frontier research streams, research calls, evidence gaps, testbed summaries, research-to-Foundry pathways, methods papers, policy research outputs, research impact assessments, and public-safe research summaries.
2.9.8 Labs Boundary. Labs Reports shall not create research ethics approval, data access rights, publication rights over restricted material, funding approval, procurement status, public authority approval, or implementation authorization.
2.9.9 Risk Agency Report Family. Risk Agency Reports shall publish expertise maps, advisory demand patterns, sector capability gaps, risk advisory categories, DRR/DRF/DRI expertise pathways, training needs, public authority learning support needs, and lawful downstream support summaries.
2.9.10 Risk Agency Boundary. Risk Agency Reports shall not certify experts, create professional engagements, provide legal advice, financial advice, insurance advice, engineering certification, medical advice, public authority advisory status, procurement qualification, or client reliance.
2.9.11 Nexus Universe Report Family. Nexus Universe Reports shall publish annual-cycle outputs, arena summaries, Core Build reports, public authority learning room summaries, readiness room summaries, National Portfolio convergence, Campaign outcomes, Academy pathways, support records, provider-neutrality notes, sponsor-boundary notes, after-action records, correction records, continuation pathways, non-continuation records, and archives.
2.9.12 Nexus Universe Boundary. Nexus Universe Reports shall not imply endorsement by attendance, arena presence, stage visibility, host presence, sponsor support, provider contribution, media coverage, public authority participation, or audience attention.
2.10 Correction, Addendum, Withdrawal, Archive, and Non-Continuation Publications
2.10.1 Correction Publication Doctrine. Correction outputs shall be first-class Nexus Reports publications where public reliance, citation, downstream use, Registry status, Marketplace display, public-safe meaning, data rights, AI-use permissions, provider status, sponsor status, public authority language, finance-readiness language, procurement language, consent language, or handoff status requires public clarification.
2.10.2 Erratum. An Erratum shall correct factual, typographical, citation, metadata, figure, table, data-label, AI-use-label, or minor interpretation errors that do not require withdrawal or major supersession. Errata shall be linked to the original report and Registry record.
2.10.3 Addendum. An Addendum shall add new evidence, new context, new limitations, new corrections, new data availability statements, new public-safe notes, or new related identifiers without replacing the original report unless supersession is stated.
2.10.4 Supersession Notice. A Supersession Notice shall identify that a newer version, replacement report, updated dataset, corrected software release, revised ontology, updated dashboard, or new National Portfolio output has replaced or materially updated a prior output.
2.10.5 Withdrawal Notice. A Withdrawal Notice shall identify that an output should no longer be used or cited as current because of rights issues, data exposure, public-safe risk, evidence error, protected knowledge exposure, public authority overclaim, finance overclaim, procurement overclaim, consent overclaim, security risk, or other material issue.
2.10.6 Retraction Notice. A Retraction Notice may be used where a publication contains material defects that require removal from reliance, including fabricated evidence, major methodological failure, serious rights violation, protected knowledge exposure, unlawful disclosure, or material public-safe harm. Retraction shall be handled with visible correction and archive discipline.
2.10.7 Recall Notice. A Recall Notice may be issued where a report, dataset, software release, dashboard, evidence pack, handoff note, or technical artefact has been used downstream and users must stop, correct, replace, restrict, or disregard prior use.
2.10.8 Non-Continuation Note. A Non-Continuation Note shall record that a planned report, series, dataset, software release, national portfolio, Campaign report, Foundry report, Studio summary, Grid / TRL note, or handoff note will not proceed due to insufficient evidence, unresolved rights, unresolved safeguards, public-safe risk, sponsor/provider conflict, national routing incompleteness, legal constraints, or strategic change.
2.10.9 Archive Publication. An Archive Publication shall preserve historical status, final version, correction history, successor links, non-current-use notices, Registry status, Marketplace status, DOI history, data-use labels, AI-use labels, license status, and use restrictions.
2.10.10 Correction Family Boundary. Correction publications preserve trust and record truth. They shall not create legal liability determination, regulatory finding, public authority finding, procurement decision, finance decision, insurance decision, consent determination, deployment decision, or execution authority.
2.11 Knowledge Product Architecture and Standard Components
2.11.1 Standard Report Components. Each substantive Nexus Report should include, as appropriate: title; subtitle; report family; output class; version; date; DOI or persistent identifier; Registry ID; Marketplace ID where applicable; authors; contributors; steward; executive summary; public-safe summary; purpose; scope; audience; method; evidence classes; data-use statement; AI-use statement; review status; findings or outputs; limitations; uncertainty; safeguard note; public authority boundary; finance and insurance boundary where relevant; procurement boundary where relevant; provider-neutrality note; sponsor-boundary note; license; citation; correction pathway; archive status; and no-conversion notice.
2.11.2 Expert Annex Architecture. Where appropriate, reports may include technical annexes, data annexes, methodology annexes, ontology annexes, software annexes, dashboard annexes, public-safe figure annexes, National Portfolio annexes, Nexus Universe annexes, contribution annexes, support annexes, and handoff dependency annexes. Annexes may be public, controlled, restricted, data-room-only, secure-room-only, or archive-only.
2.11.3 Public-Safe Abstract. Every public report shall include a public-safe abstract that states what the report is, what it covers, what evidence it uses, what its limitations are, and what it does not do. The abstract shall be suitable for repository metadata and public discovery.
2.11.4 Data Availability Statement. Reports involving data shall include a data availability statement identifying whether data is open, public-safe, restricted, controlled, confidential, public authority-sensitive, community-sensitive, Indigenous-protocol-sensitive where applicable, protected knowledge, secure-room-only, data-room-only, compute-to-data-only, no-download, no-publication, no-AI-training, no-handoff, or archive-only.
2.11.5 AI-Use Statement. Reports involving AI-assisted drafting, analysis, summarization, classification, translation, visualization, modelling, code generation, or public-output preparation shall include an AI-use statement where relevant, identifying permitted uses, human review, restrictions, and limitations.
2.11.6 License and Rights Statement. Reports shall identify license and rights for text, data, software, figures, maps, images, tables, code, ontologies, schemas, and third-party materials. License statements shall not open controlled materials by implication.
2.11.7 Contributor and Support Statement. Reports shall distinguish authors, contributors, reviewers, data stewards, software contributors, translators, accessibility contributors, public-safe reviewers, safeguard reviewers, sponsors, providers, hosts, and funders. Support statements shall not imply control, validation, endorsement, or approval.
2.11.8 Correction Statement. Reports shall state how corrections may be submitted, how versions will be updated, how supersession will be handled, how withdrawals may occur, and how archive status will be displayed.
2.11.9 Citation Statement. Reports shall provide a citation format where possible, including DOI, version, date, authors or institutional steward, report family, and Registry record. Citation shall not imply current status unless the cited version is current.
2.11.10 Standard No-Conversion Statement. Reports shall include no-conversion language appropriate to their class. Where a short notice is needed, it shall state that the report is a public-good knowledge publication and does not create approval, certification, procurement, finance, insurance, public authority action, consent, deployment, or execution.
2.12 Final Operating Statement
2.12.1 Final Taxonomy Rule. Nexus Reports shall be governed by publication families, output classes, report series, standard components, metadata requirements, review levels, public-safe labels, data-use labels, AI-use labels, Registry records, Marketplace discovery, correction pathways, and archive rules. Taxonomy shall be the first line of publication governance.
2.12.2 Final Publication Family Formula. National Portfolio Reports shall showcase national public-good portfolios without ranking or approving. WFEH-B Reports shall explain systems interdependence without issuing policy. DRR Reports shall support risk reduction learning without warning authority. DRF Reports shall frame finance-readiness questions without finance. DRI Reports shall publish intelligence without ratings or warnings. DICE Reports shall describe data commons without opening restricted data. GRIx Reports shall publish ontology without official classification. Observatory Reports shall publish observability without surveillance authority. Foundry Reports shall document production without deployment approval. Campaign Reports shall document mobilization without public mandate. Academy Reports shall document learning without licensure. Labs Reports shall document research without implementation authority. Risk Agency Reports shall document expertise pathways without expert certification. Nexus Universe Reports shall document annual-cycle memory without endorsement. Correction Reports shall preserve truth without legal determination.
2.12.3 Final Output-Class Formula. A report explains; a brief translates; a technical note documents; a methods paper formalizes; a data paper describes; a software release packages; an ontology release structures; an evidence pack supports; a public-safe summary protects; an atlas visualizes; a dashboard publication displays; a learning package teaches; a handoff context note routes; a correction notice corrects; an archive record preserves. None authorizes by form.
2.12.4 Final Declaration. Nexus Reports shall be credible because its knowledge products are not generic publications. Each output shall be classified, evidence-linked, method-aware, metadata-rich, public-safe, rights-aware, AI-labeled where relevant, review-labeled, registered, discoverable, versioned, correctionable, and bounded. The publication architecture shall make Nexus work legible to expert audiences while protecting the ecosystem from status inflation, data exposure, sponsor capture, provider validation, public authority confusion, finance overclaim, procurement distortion, consent overclaim, and execution by implication.
3. National Portfolio Reports, WFEH-B Systems Reporting, DRR, DRF, DRI, and National Risk-and-Innovation Publication Architecture
3.1 National Portfolio Reports as the Flagship Nexus Reports Family
3.1.1 Flagship Function. National Portfolio Reports shall constitute the flagship publication family of Nexus Reports. They shall provide the primary public-safe, expert-grade, status-linked, nationally routed, and correctionable format for presenting a country’s risk and innovation portfolio across the Water–Food–Energy–Health–Biodiversity Nexus, Disaster Risk Reduction, Disaster Risk Finance, Disaster Risk Intelligence, public-good technology, data commons, risk ontology, observability, learning, campaigns, research, expertise pathways, annual-cycle participation, support records, and lawful handoff dependencies.
3.1.2 National Portfolio Defined. A National Portfolio means the structured body of public-safe Nexus records, outputs, opportunities, gaps, capabilities, learning pathways, support needs, evidence objects, data objects, DRI objects, Foundry objects, Campaign objects, Academy objects, Labs objects, Risk Agency pathways, Nexus Universe outputs, Working Group outputs, Competence Cell outputs, National Node records, and lawful handoff dependency candidates associated with a national Nexus pathway. A National Portfolio is a public-good status and knowledge architecture; it is not a government plan, investor memorandum, insurance submission, donor proposal, procurement plan, certification dossier, official national risk rating, or execution mandate unless separately and lawfully established by competent actors outside the default Nexus Reports posture.
3.1.3 Publication Purpose. A National Portfolio Report shall make national work visible, teachable, citable, correctable, and routable. It shall allow national stakeholders to see: what has been recorded; what has been contributed; what has been learned; what remains uncertain; what requires data stewardship; what requires public authority learning; what requires community safeguard review; what requires technology development; what requires Academy capacity; what requires Campaign mobilization; what may be prepared for Nexus Universe; what may become Foundry work; what may require DICE, GRIx, DRI, Observatory, Studio, Grid, or TRL routing; and what may eventually form lawful handoff dependency context.
3.1.4 National Ownership Principle. National Portfolio Reports shall preserve national ownership before local delivery. Country-level risk and innovation work shall be shaped, localized, recorded, reviewed, safeguarded, published, continued, and routed through national stakeholders, National Nodes, National Nexus Consortiums, National Working Groups, Nexus Competence Cells, national public authority learning pathways, national data rules, national language needs, national community safeguards, national legal context, and lawful national continuation pathways. Global, regional, sponsor, provider, donor, capital-reader, insurer, media, or enterprise actors shall not use National Portfolio Reports to bypass national pathways.
3.1.5 Non-Ranking Discipline. A National Portfolio Report shall not rank countries, score governments, rate national performance, produce sovereign risk ratings, produce investor league tables, produce insurance scores, assign donor priority, shame communities, imply national failure, compare vulnerability for market advantage, or create public authority classifications. It shall be a public-safe national portfolio record, not a judgment instrument.
3.1.6 Public-Safe National Display. National Portfolio Reports shall display national information only where public-safe, lawful, rights-compliant, and appropriate to the record class. Sensitive geospatial detail, public authority-sensitive records, protected knowledge, Indigenous protocol-sensitive information where applicable, cyber-sensitive information, infrastructure-sensitive information, health-sensitive information, youth-sensitive information, humanitarian-sensitive information, and community-sensitive information shall be controlled, summarized, redacted, generalized, sealed, or excluded from public release as required.
3.1.7 Portfolio as Continuation Surface. National Portfolio Reports shall not merely describe completed work. They shall identify continuation pathways into Nexus Campaigns, National Working Groups, Nexus Competence Cells, Nexus Foundry tasks and builds, Nexus Academy pathways, WILPs, micro-credentials, Nexus Labs research streams, Risk Agency expertise pathways, DICE stewardship tasks, GRIx ontology refinement, DRI dashboard development, Nexus Observatory needs, Nexus Studio workflows, Nexus Grid inputs, TRL evidence development, Nexus Universe arenas, and lawful handoff dependency packages.
3.1.8 Portfolio Boundary. A National Portfolio Report shall make national risk and innovation capacity visible without creating official policy, public authority approval, public warning, procurement status, financeability, insurability, underwriting acceptance, donor commitment, public finance allocation, certification, rating, ranking, consent, deployment authorization, operational command, or execution by implication.
3.2 Standard National Portfolio Report Architecture
3.2.1 Required Opening Architecture. Each National Portfolio Report should open with a clear public-safe statement identifying the country or national pathway, report family, version, steward, publication date, Registry record, DOI or persistent identifier where applicable, public-safe status, review level, data-use status, AI-use status where applicable, public authority boundary, finance and insurance boundary, procurement boundary, community and Indigenous consent boundary where applicable, correction pathway, and archive rule.
3.2.2 Executive and Public-Safe Summary. Each National Portfolio Report should include an executive summary and a public-safe summary. The executive summary may be expert-facing and systems-oriented. The public-safe summary shall be suitable for broad public discovery and shall state what the report covers, what it does not cover, what evidence classes it uses, what limitations apply, what sensitive information is not displayed, and how corrections may be submitted.
3.2.3 National Systems Context. The report may include a national systems context section that describes public-safe national risk and innovation context across WFEH-B, DRR, DRF, DRI, climate and nature, infrastructure, public health, digital infrastructure, data systems, public authority learning, institutional capability, public-good technology, and community resilience. The section shall avoid official government interpretation unless separately authorized and shall not imply national ranking.
3.2.4 WFEH-B Systems Chapter. The report shall include, where relevant, a WFEH-B chapter addressing interdependencies among water, food, energy, health, and biodiversity systems. It shall identify public-safe cross-system dependencies, cascading risks, co-benefits, trade-offs, data gaps, observability gaps, public-good innovation opportunities, community safeguard issues, technology needs, and lawful handoff questions.
3.2.5 DRR Chapter. The report shall include, where relevant, a DRR chapter addressing public-safe disaster risk reduction priorities, prevention pathways, preparedness learning, resilience needs, infrastructure continuity, community priorities, public-safe communication, Academy needs, Campaign signals, Observatory gaps, DICE data needs, DRI indicator needs, and Foundry opportunities.
3.2.6 DRF Chapter. The report shall include, where relevant, a DRF chapter addressing protection-gap questions, risk-layering assumptions, insurance-readiness questions, donor-readiness questions, public finance relevance, fiscal exposure context, data gaps, institutional dependencies, affordability issues, assumptions registers, dependency registers, and lawful handoff prerequisites. The chapter shall be no-reliance, non-advisory, non-soliciting, non-transactional, and regulated-perimeter controlled.
3.2.7 DRI Chapter. The report shall include, where relevant, a DRI chapter addressing public-safe disaster risk intelligence, indicator frameworks, confidence labels, uncertainty labels, DICE-linked data status, GRIx-linked risk categories, Observatory signal needs, Studio dashboard summaries, correction pathways, and limitations. The chapter shall not constitute warning, rating, ranking, official classification, insurance scoring, investment scoring, or public authority finding.
3.2.8 Data and DICE Chapter. The report should include a data and DICE chapter identifying datasets, metadata, data dictionaries, schemas, data gaps, data-use labels, AI-use labels, lineage issues, access restrictions, public-safe aggregates, compute-to-data opportunities, secure-room or data-room needs, data stewardship tasks, and controlled-source notes.
3.2.9 GRIx and Ontology Chapter. The report should include a GRIx and ontology chapter identifying risk categories, systems-risk mappings, WFEH-B taxonomy, DRR/DRF/DRI category alignment, indicator concepts, controlled vocabulary, classification gaps, semantic interoperability needs, and correction pathways.
3.2.10 Observatory and Digital Intelligence Chapter. The report should include an Observatory and digital intelligence chapter identifying observability needs, sensing gaps, Edge and sensor opportunities, geospatial and Earth observation needs, digital twin opportunities, dashboard needs, AI workflow limits, cyber-sensitive issues, infrastructure sensitivity, and public-safe observability outputs.
3.2.11 Innovation and Technology Chapter. The report may include a technology chapter covering AI, AI-RAN, O-RAN, private wireless, sovereign compute, HPC, cyber, geospatial systems, Earth observation, digital twins, robotics, drones, sensing, blockchain/DLT/Web3, quantum-relevant systems, advanced manufacturing, semiconductors, biosecurity, climate tech, nature tech, and other exponential technologies. The chapter shall identify readiness, safeguards, dependency conditions, public-good relevance, data requirements, security constraints, public authority boundaries, and lawful handoff conditions.
3.2.12 Campaign, Academy, Labs, Risk Agency, and Foundry Chapter. The report may include a cross-pillar chapter identifying Nexus Campaigns, volunteer mobilization, Working Group formation, Competence Cell formation, Academy pathways, Risk Academy modules, WILPs, micro-credentials, Nexus Labs research calls, Risk Agency expertise pathways, Nexus Foundry tasks, quests, bounties, builds, packs, and technical outputs.
3.2.13 Nexus Universe and Annual-Cycle Chapter. The report should include, where applicable, a Nexus Universe chapter identifying national participation, arena relevance, Core Build relevance, public authority learning room outputs, readiness room outputs, support records, public-safe summaries, after-action records, continuation pathways, corrections, non-continuation records, and archive status. Nexus Universe presence shall not imply endorsement.
3.2.14 Support and Partnership Transparency Chapter. The report may include a support transparency chapter identifying sponsors, donors, hosts, providers, in-kind contributors, compute contributors, equipment contributors, venue contributors, public-good supporters, support ledgers, provider-neutrality notes, sponsor-boundary notes, conflicts, support restrictions, and correction pathways. Support shall not imply control; contribution shall not imply validation.
3.2.15 Handoff Dependency Chapter. The report may include a lawful handoff dependency chapter identifying evidence context, data context, public-safe status, safeguard status, public authority dependencies, legal dependencies, finance and insurance questions, procurement boundaries, provider-neutrality notes, sponsor-boundary notes, recipient responsibilities, no-reliance statements, correction pathways, and archive status. It shall not authorize implementation.
3.2.16 Correction and Archive Chapter. The report shall include a correction and archive section identifying known limitations, open questions, pending reviews, corrected records, withdrawn records, non-continuing records, superseded materials, archive status, and correction submission pathway.
3.3 WFEH-B National Systems Reporting
3.3.1 WFEH-B Systems Doctrine. National Portfolio Reports shall treat water, food, energy, health, and biodiversity as interdependent national systems. Reports shall avoid narrow sector listing and instead show how water security affects food systems, how energy continuity affects health and water infrastructure, how biodiversity affects water and food resilience, how public health depends on ecosystem stability and infrastructure continuity, and how climate, technology, data, finance, and governance conditions interact across all five domains.
3.3.2 Water Systems Reporting. Water reporting may address water security, watersheds, groundwater, drought, floods, water quality, sanitation, hydrological monitoring, irrigation, agriculture-water dependency, hydropower, industrial water dependency, public health links, biodiversity dependence, urban water systems, rural water systems, public-safe water dashboards, data gaps, sensor needs, geospatial needs, and lawful handoff questions. It shall not create official water classification, public warning, regulatory finding, permit implication, or project authorization.
3.3.3 Food Systems Reporting. Food systems reporting may address agricultural risk, soil health, crop vulnerability, livestock risk, fisheries, supply chains, logistics, cold chains, nutrition, food security, food safety, biosecurity, pest risk, water dependency, energy dependency, health impacts, biodiversity dependency, climate stress, geospatial monitoring, DICE data gaps, DRI indicators, and innovation needs. It shall not create official food safety determination, market signal, procurement recommendation, or emergency declaration.
3.3.4 Energy Systems Reporting. Energy reporting may address energy resilience, grid continuity, distributed energy, renewable energy, backup power, health facility power, water-energy dependencies, food system energy needs, critical infrastructure, fuel continuity, digital infrastructure, AI-RAN, O-RAN, private wireless, Edge compute, cybersecurity, climate impacts, affordability issues, DRR relevance, and public finance relevance. It shall not certify energy projects, approve infrastructure, create procurement status, or authorize deployment.
3.3.5 Health Systems Reporting. Health reporting may address public health resilience, climate-sensitive health risks, heat risk, air quality, water-borne disease, food safety, health facility continuity, emergency preparedness learning, epidemiological data sensitivity, privacy, AI-use restrictions, public authority boundaries, mental health after disasters, vulnerable populations, and health-related DRI indicators. It shall not provide medical advice, public health orders, official surveillance findings, or public authority action.
3.3.6 Biodiversity Systems Reporting. Biodiversity reporting may address ecosystem services, habitat integrity, species sensitivity, protected areas, biodiversity loss, restoration opportunities, nature-based solutions, watershed protection, pollination, fisheries, soil health, cultural and Indigenous protocol-sensitive knowledge where applicable, geospatial sensitivity, DICE metadata, GRIx categories, and Observatory needs. It shall not expose protected locations, sacred knowledge, protected knowledge, or restricted ecological data.
3.3.7 Cross-System Cascades. WFEH-B reporting shall identify public-safe cross-system cascades, including drought-to-food-to-health impacts, flood-to-infrastructure-to-health impacts, energy outage-to-water-and-health impacts, biodiversity loss-to-food-and-water impacts, cyber disruption-to-energy-water-health impacts, and compound climate-disaster-health effects. Cascade analysis shall be limitation-aware and shall not create official forecasts or warnings.
3.3.8 Innovation Opportunities. WFEH-B reporting may identify public-good innovation opportunities including data commons, sensors, Edge observability, digital twins, AI-assisted decision support for learning only, community reporting tools, resilience dashboards, open technical baselines, public-good software, Academy training, Campaign mobilization, Foundry builds, Labs research, and lawful handoff dependencies. Opportunity identification shall not create procurement recommendation or implementation authorization.
3.3.9 WFEH-B Evidence Labels. WFEH-B sections shall identify source classes, data status, uncertainty, public-safe transformations, data-use labels, AI-use labels, geospatial sensitivity, community sensitivity, public authority sensitivity, protected knowledge controls, and correction pathways.
3.3.10 WFEH-B Boundary. WFEH-B National Portfolio reporting shall support national systems understanding and public-good pathway formation. It shall not create sector policy, public authority approval, environmental permit, public warning, official classification, financeability, insurance approval, procurement recommendation, community consent, Indigenous consent where applicable, deployment authorization, or execution.
3.4 Disaster Risk Reduction Reporting in National Portfolios
3.4.1 DRR National Portfolio Function. DRR reporting within National Portfolio Reports shall provide a public-safe synthesis of disaster risk reduction priorities, resilience gaps, preparedness learning, prevention opportunities, infrastructure continuity needs, community priorities, data gaps, observability gaps, Academy needs, Campaign signals, Foundry opportunities, and Nexus Universe continuation pathways.
3.4.2 All-Hazards Scope. DRR reporting may address floods, droughts, wildfire, storms, heat, earthquakes, landslides, pandemics, health emergencies, food system shocks, water crises, energy disruptions, infrastructure failures, biodiversity-related risks, cyber-physical disruptions, industrial hazards, compound risks, cascading risks, and systemic risks.
3.4.3 Whole-of-Society Scope. DRR reporting shall reflect whole-of-society resilience, including public authorities in learning roles, communities, universities, schools, youth, civil society, private sector actors, utilities, infrastructure operators, humanitarian actors, health actors, technology providers, insurers, donors, sponsors, media, and lawful downstream actors, while preserving role boundaries and avoiding implied mandates.
3.4.4 Public-Safe DRR Language. DRR reporting shall avoid operational instructions, emergency commands, evacuation guidance, official alert language, casualty speculation, unsupported predictions, blame language, public authority substitution, and panic-inducing framing. It may identify learning needs, capability gaps, public-safe risk patterns, data gaps, preparedness questions, and continuation routes.
3.4.5 Community and Safeguard Integration. DRR reporting shall protect community-sensitive information, vulnerable locations, disaster-affected identities, youth data, humanitarian-sensitive details, accessibility needs, disability-related information, Indigenous protocol-sensitive information where applicable, and protected knowledge. Participation in DRR reporting shall not imply consent or representation.
3.4.6 Observatory and DRI Integration. DRR reporting may link to DRI indicators, Observatory needs, geospatial summaries, Earth observation requirements, digital twin opportunities, sensor gaps, public-safe dashboards, Studio workflow summaries, and DICE data gaps. These links shall not create official hazard maps, warnings, or public authority classifications.
3.4.7 Campaign and Academy Activation. DRR reporting may identify Campaign actions, volunteer roles, Working Group tasks, Competence Cell needs, Academy modules, WILP opportunities, micro-credential pathways, public authority learning modules, youth learning opportunities, and Nexus Universe preparation work.
3.4.8 Foundry Activation. DRR reporting may identify Foundry tasks, quests, bounties, builds, technical packs, data pipelines, open technical baselines, software prototypes, dashboard tools, sensor integration, community tools, and public-safe reporting templates. Such identification shall not authorize deployment or operations.
3.4.9 DRR Review Requirements. DRR sections shall undergo public-safe review, safeguard review where relevant, data-use review, geospatial sensitivity review, public authority boundary review, and, where technology outputs are discussed, cybersecurity and AI-use review.
3.4.10 DRR Boundary. DRR reporting shall help societies learn, prepare, reduce risk, and route capability-building work. It shall not issue public warnings, emergency alerts, hazard declarations, operational commands, public safety directives, procurement recommendations, finance signals, certification, deployment authorization, or execution.
3.5 Disaster Risk Finance Reporting in National Portfolios
3.5.1 DRF National Portfolio Function. DRF reporting within National Portfolio Reports shall make disaster risk finance questions visible and structured without creating finance. It shall describe protection gaps, financial exposure questions, risk-layering assumptions, data needs, insurance-readiness questions, donor-readiness questions, public finance relevance, institutional dependencies, legal dependencies, safeguard dependencies, affordability issues, and handoff prerequisites.
3.5.2 No-Reliance Posture. DRF sections shall be no-reliance, non-advisory, non-soliciting, non-transactional, non-underwriting, non-rating, non-valuation, non-public-finance-allocation, and regulated-perimeter controlled. They shall identify questions and dependencies, not financial conclusions.
3.5.3 Protection Gap Treatment. DRF reporting may describe protection gaps in public-safe terms, including exposed public assets, households, livelihoods, infrastructure, agriculture, health systems, water systems, biodiversity systems, small enterprises, supply chains, and communities. Such descriptions shall avoid creating insurance determinations, public finance obligations, or claims about coverage eligibility.
3.5.4 Risk-Layering Questions. DRF reporting may identify possible layers of risk retention, contingency finance, insurance, reinsurance, donor support, public finance, resilience investment, social protection, parametric concepts, infrastructure finance questions, and community resilience support questions. It shall not recommend transactions or instruments by default.
3.5.5 Insurance-Readiness Questions. DRF reporting may identify data quality needs, exposure information needs, hazard data needs, vulnerability data needs, claims data gaps, basis-risk questions, affordability questions, regulatory dependencies, public authority dependencies, and community safeguard issues. It shall not create insurability, underwriting acceptance, premium indication, or coverage conclusion.
3.5.6 Donor and Public Finance Relevance. DRF reporting may identify donor-readiness and public finance relevance questions, including evidence needs, policy dependencies, fiduciary considerations, public authority dependencies, safeguard requirements, implementation capacity, and monitoring needs. It shall not create donor commitment, public finance allocation, subsidy approval, guarantee approval, sovereign approval, or fiscal commitment.
3.5.7 Capital Reader Boundary. Capital readers, insurers, reinsurers, donors, philanthropies, public finance readers, development actors, and sponsors may read DRF sections as learning and context only. Their presence, questions, comments, downloads, Nexus Universe participation, readiness-room attendance, or support inquiries shall not imply financial interest or commitment.
3.5.8 DRF and DRI Linkage. DRF reporting may rely on DRI indicators, DICE metadata, GRIx risk categories, Observatory needs, and public-safe exposure summaries. Such linkages shall be clearly labeled as evidence context and shall not become financeable claims.
3.5.9 DRF Correction Requirements. DRF sections shall be corrected where data status, assumptions, dependencies, finance-readiness language, insurance-readiness language, donor-readiness language, public finance relevance, public authority dependencies, or no-reliance notices are inaccurate or overclaimed.
3.5.10 DRF Boundary. DRF reporting shall not create financeability, bankability, insurability, underwriting acceptance, investment readiness, donor commitment, public finance allocation, valuation, rating, guarantee, solicitation, offer, transaction readiness, procurement status, public authority approval, or execution.
3.6 Disaster Risk Intelligence Reporting in National Portfolios
3.6.1 DRI National Portfolio Function. DRI reporting within National Portfolio Reports shall present public-safe disaster risk intelligence contributions, indicator frameworks, dashboard summaries, confidence labels, uncertainty notes, data gaps, GRIx mappings, DICE metadata status, Observatory signal needs, Studio workflow summaries, and correction pathways.
3.6.2 Intelligence Without Official Warning. DRI reporting shall not be an official warning, emergency alert, evacuation instruction, public safety directive, official hazard map, public health order, regulatory classification, public authority risk category, insurance score, investment rating, country ranking, or procurement criterion.
3.6.3 Indicator Structure. DRI sections shall define indicators, source classes, data status, update cadence where relevant, geographic resolution, uncertainty, confidence, limitations, public-safe transformations, sensitivity labels, DICE links, GRIx mappings, and correction pathway.
3.6.4 Confidence and Uncertainty Labels. DRI reporting shall use confidence and uncertainty labels where appropriate. It shall distinguish observed data, inferred patterns, model-assisted outputs, stakeholder submissions, historical patterns, projected conditions, data gaps, and unsupported hypotheses.
3.6.5 Dashboard Summary Controls. DRI dashboard summaries shall identify whether the dashboard is public, public-safe, controlled, Studio-only, data-room-only, secure-room-only, public-authority-learning-only, or archive-only. Dashboard reporting shall include refresh status, data limitations, geospatial sensitivity, AI-use limits, and no-warning language.
3.6.6 DICE and GRIx Integration. DRI reporting shall connect indicators to DICE data records and GRIx ontology categories where available. Absence of data or incomplete ontology mapping shall be stated rather than hidden.
3.6.7 Observatory Integration. DRI reporting shall identify observability needs, signal gaps, sensor requirements, geospatial needs, Earth observation opportunities, digital twin requirements, and public-safe monitoring gaps without implying surveillance authority or public warning authority.
3.6.8 AI-Use Controls. Where AI supports DRI reporting, the report shall identify AI-use status, human review, data restrictions, model limitations, hallucination controls, public-safe review, and prohibited high-stakes uses. AI-assisted outputs shall not be used for automated decisions or public warnings.
3.6.9 DRI Correction Requirements. DRI sections shall be corrected where indicator definitions, source status, data status, uncertainty, confidence, dashboard outputs, geospatial disclosure, public-safe interpretation, public warning language, rating language, or public authority language is inaccurate or unsafe.
3.6.10 DRI Boundary. DRI reporting shall support public-safe intelligence, learning, data improvement, observability, readiness questions, and national portfolio formation. It shall not create official warnings, public authority classifications, ratings, rankings, insurance scores, investment signals, procurement criteria, deployment authorization, operational command, or execution.
3.7 National Innovation and Frontier Technology Reporting
3.7.1 National Innovation Reporting Function. National Portfolio Reports shall include, where relevant, a national innovation and frontier technology reporting layer that maps public-good technology capabilities, infrastructure needs, research pathways, technical gaps, public-good software needs, open technical baselines, Foundry tasks, Labs research, Academy skill needs, DICE data requirements, Observatory requirements, Grid inputs, TRL evidence, Nexus Universe opportunities, and lawful handoff dependencies.
3.7.2 Exponential Technology Scope. National innovation reporting may cover AI, AI-RAN, O-RAN, private wireless, sovereign compute, HPC, edge compute, cyber, geospatial systems, Earth observation, digital twins, robotics, drones, sensors, IoT, blockchain/DLT/Web3, quantum-relevant systems, advanced manufacturing, semiconductors, biosecurity technologies, climate technologies, nature technologies, infrastructure technologies, public-good software, data spaces, and digital public infrastructure.
3.7.3 Technical Readiness Treatment. Technology reporting may reference TRL 1–10 evidence notes and Nexus Grid inputs where recorded. Such references shall identify evidence basis, scope, limitations, support status, downgrade rules, correction history, and no-certification language. TRL display shall not imply safety, procurement suitability, financeability, insurance approval, public authority approval, or deployment authorization.
3.7.4 Public-Good Technology Treatment. Reports may identify public-good software, open technical baselines, APIs, SDKs, connectors, data schemas, dashboards, model cards, system cards, benchmark cards, and templates that could support national risk and innovation work. Publication shall not create warranty or implementation authority.
3.7.5 Cybersecurity and Dual-Use Controls. Technology sections shall identify cybersecurity status, vulnerability pathways, dependency limits, secure-room needs, dual-use sensitivity where relevant, export-control awareness where relevant, sanctions sensitivity where relevant, AI-use restrictions, data-use restrictions, and operational-use prohibitions where applicable.
3.7.6 AI and Automated System Controls. Reports may describe AI workflows, retrieval systems, classification methods, translation support, risk-intelligence assistance, modelling tools, public-safe drafting support, and agentic workflow candidates. They shall prohibit automated high-stakes decisions, public authority decisions, procurement decisions, finance decisions, insurance decisions, emergency commands, public warnings, or consent determinations by default.
3.7.7 Geospatial, Earth Observation, and Digital Twin Controls. Reports may describe geospatial layers, Earth observation needs, digital twin concepts, and public-safe maps. Sensitive geospatial detail, critical infrastructure locations, protected biodiversity locations, protected knowledge locations, and vulnerable community locations shall be protected.
3.7.8 Technology Provider Boundary. Provider participation, provider tools, provider data, provider cloud, provider compute, provider software, provider demonstrations, provider support, or provider references in National Portfolio Reports shall not validate providers, create preferred status, imply procurement readiness, certify technical quality, or authorize deployment.
3.7.9 Technology Handoff Boundary. Technology sections may identify lawful handoff dependency candidates. Such candidates shall require independent diligence, public authority approvals where applicable, procurement, finance, insurance, safety, cybersecurity, data protection, community engagement, Indigenous protocols where applicable, deployment planning, operations, and execution by competent downstream actors.
3.7.10 Innovation Reporting Boundary. National innovation reporting shall make capability, gap, and readiness context visible. It shall not create standards conformance, technical certification, safety approval, public authority approval, procurement status, financeability, insurability, deployment authorization, operational command, or execution.
3.8 Stakeholder, Contribution, Campaign, Academy, Labs, Risk Agency, and Support Mapping
3.8.1 Stakeholder Mapping Function. National Portfolio Reports may map public-safe stakeholder participation across National Nodes, National Nexus Consortiums, National Councils, Helix Councils, National Working Groups, Competence Cells, public authorities in learning roles, universities, labs, communities, civil society, youth, diaspora, providers, sponsors, hosts, donors, insurers, capital readers, public finance readers, Campaign teams, Academy participants, Labs participants, Risk Agency pathways, Nexus Universe participants, National Consortium Companies, Project SPVs, and lawful downstream actors.
3.8.2 Contribution Mapping Function. Reports may map contributions to public-good outputs, including code, data, documentation, translations, accessibility work, evidence inputs, public-safe summaries, DICE stewardship, GRIx mapping, DRI indicator development, Observatory needs, Foundry builds, Campaign support, Academy learning materials, Nexus Universe outputs, review work, maintenance work, correction work, and archive work.
3.8.3 iCRS and Portfolio Linkage. National Portfolio Reports may reference iCRS records, stakeholder portfolio records, contribution records, WILP records, micro-credential records, reviewer records, maintainer records, and public-safe recognition records where authorized. Such linkage shall not create employment, professional certification, procurement qualification, expert standing, or authority.
3.8.4 Campaign Mapping. Reports may identify national Campaigns, signatures, pledge summaries, support actions, volunteer roles, public-safe reports, Working Group formation, Competence Cell formation, Campaign outcomes, Campaign continuation, and Campaign non-continuation. Campaign participation shall not imply public mandate, consent, public authority approval, donor commitment, or execution.
3.8.5 Academy Mapping. Reports may identify Academy modules, Risk Academy pathways, WILPs, micro-credentials, public authority learning modules, data stewardship training, AI-use training, public-safe communication training, safeguard training, accessibility training, and Nexus Universe preparation materials. Learning records shall not create professional licensure.
3.8.6 Labs Mapping. Reports may identify research calls, research streams, evidence gaps, testbed needs, frontier lab opportunities, research-to-Foundry pathways, methods gaps, policy research needs, and research impact opportunities. Labs mapping shall not create research approval, funding approval, or implementation authority.
3.8.7 Risk Agency Mapping. Reports may identify expertise gaps, advisory demand patterns, training needs, public authority learning support needs, DRR/DRF/DRI expertise pathways, sector support categories, and lawful downstream support pathways. Risk Agency mapping shall not certify experts or create client reliance.
3.8.8 Support Mapping. Reports may identify sponsors, donors, philanthropic support, development support, in-kind support, compute support, cloud support, equipment support, venue support, translation support, accessibility support, scholarship support, bounty support, Campaign support, Academy support, Foundry support, Labs support, DICE support, DRI support, and Nexus Universe support. Support shall be disclosed without control.
3.8.9 Public Display Controls. Stakeholder and support mapping shall be permission-aware, public-safe, privacy-aware, youth-protective, conflict-disclosed, provider-neutral, sponsor-bounded, and correctionable. Public display shall not expose sensitive roles, protected knowledge work, secure-room work, or restricted participation.
3.8.10 Mapping Boundary. Stakeholder, contribution, Campaign, Academy, Labs, Risk Agency, and support mapping shall create visibility and memory only. It shall not create endorsement, certification, employment, public mandate, procurement status, financeability, insurability, public authority approval, consent, deployment authorization, or execution.
3.9 National Portfolio Evidence, Metadata, Repository, and Registry Package
3.9.1 National Portfolio Package. A National Portfolio publication package may include a public report, executive summary, public-safe summary, technical note, visual atlas, dashboard summary, data paper, DICE metadata record, GRIx mapping record, DRI indicator table, Observatory needs table, Foundry task list, Campaign call-to-action, Academy reading list, Nexus Universe summary, support transparency note, handoff context note, correction notice, Registry record, Marketplace listing, DOI deposit, and archive record.
3.9.2 Evidence Register. Each National Portfolio Report should have an Evidence Register or equivalent structured evidence table identifying source class, source pathway, public-safe status, access class, data-use label, AI-use label, review level, sensitivity, limitations, and linked Registry records where appropriate.
3.9.3 Metadata Requirements. National Portfolio Reports should include metadata for country or national pathway, report family, WFEH-B tags, DRR/DRF/DRI tags, thematic domains, technology domains, public-good mechanisms, Nexus pillars, authors, contributors, steward, version, DOI, Registry ID, Marketplace ID, data-use status, AI-use status, license, review status, correction status, and archive status.
3.9.4 Repository Deposit Strategy. The public-safe version of a National Portfolio Report may be deposited through Zenodo or comparable open-science infrastructure where appropriate. Controlled evidence, restricted datasets, secure-room records, data-room records, protected knowledge, sensitive geospatial data, and handoff packages shall remain in governed systems.
3.9.5 DOI and Version Strategy. National Portfolio Reports should use persistent identifiers where appropriate. Versioning shall distinguish initial releases, annual updates, corrected versions, superseded versions, translations, localized editions, public-safe summaries, technical annexes, and archive versions.
3.9.6 Registry Linkage. Each National Portfolio Report should be linked to Nexus Registry as the status-truth record. Registry shall identify current version, public-safe status, access status, correction status, archive status, related objects, and affected downstream records.
3.9.7 Marketplace Linkage. National Portfolio Reports may be listed in Nexus Marketplace for discovery. Marketplace listing shall display report class, country or national pathway, version, DOI, Registry status, review level, public-safe status, data-use labels, AI-use labels, license, support status where relevant, correction status, and no-conversion notices.
3.9.8 Translation and Accessibility. National Portfolio Reports should support translation, plain-language summaries, accessible formats, alternative text, captions where relevant, low-bandwidth formats, screen-reader compatibility where feasible, and disability inclusion review. Translation shall preserve boundaries and no-conversion notices.
3.9.9 Update Cycle. National Portfolio Reports may be updated annually, before or after Nexus Universe, after major Campaign cycles, after Working Group outputs, after Competence Cell outputs, after major DICE/DRI/GRIx updates, after public-safe corrections, or when national pathways require revision.
3.9.10 Evidence Package Boundary. The existence of evidence, metadata, DOI, Registry linkage, Marketplace listing, or repository deposit shall not create approval, certification, public authority action, procurement status, financeability, insurability, consent, deployment authorization, or execution.
3.10 National Portfolio Review, Safeguards, Corrections, and No-Conversion Controls
3.10.1 Review Doctrine. National Portfolio Reports shall undergo review appropriate to their scope, sensitivity, and use. Review may include editorial review, technical review, data review, AI-use review, public-safe review, national pathway review, public authority boundary review, finance and insurance boundary review, procurement boundary review, safeguard review, community safeguard review, Indigenous protocol-sensitive review where applicable, accessibility review, and repository metadata review.
3.10.2 National Pathway Review. National pathway review shall assess whether the report preserves national ownership, national routing, national data rules, national public authority boundaries, national language needs, national stakeholder context, national continuation logic, and national non-bypass discipline.
3.10.3 Public-Safe Review. Public-safe review shall assess whether the report contains unsafe public warning language, official classification overclaim, finance overclaim, insurance overclaim, procurement overclaim, certification overclaim, maturity overclaim, provider validation, sponsor control, consent overclaim, protected knowledge exposure, unsafe geospatial detail, cyber-sensitive disclosure, or execution implication.
3.10.4 Safeguard Review. Safeguard review shall assess whether the report protects communities, youth, vulnerable groups, disability-related information, humanitarian-sensitive information, Indigenous protocol-sensitive matters where applicable, protected knowledge, health-sensitive data, and place-based sensitive information.
3.10.5 Finance and Insurance Review. DRF and finance-related content shall be reviewed for no-reliance language, non-advisory posture, non-solicitation, non-transactional framing, no-rating language, no-valuation language, no-underwriting language, no-public-finance-allocation language, and regulated-perimeter sensitivity.
3.10.6 Provider and Sponsor Review. Provider and sponsor references shall be reviewed to ensure factual display, contribution without validation, support without control, conflict disclosure, no-pay-to-influence language, and no procurement or public authority overclaim.
3.10.7 Public Authority Boundary Review. References to public authorities, ministries, agencies, municipalities, regulators, public finance bodies, emergency bodies, utilities, or official institutions shall be reviewed to ensure that learning, dialogue, observation, support, or participation is not misrepresented as approval, policy adoption, official warning, public finance allocation, procurement action, regulatory comfort, or public authority decision.
3.10.8 Correction Pathways. National Portfolio Reports shall support corrections for data errors, status errors, attribution errors, public-safe errors, stakeholder display errors, support display errors, provider overclaims, sponsor overclaims, public authority overclaims, finance or insurance overclaims, procurement overclaims, consent overclaims, DRI errors, DICE errors, GRIx errors, Observatory errors, Nexus Universe errors, and handoff errors.
3.10.9 Withdrawal, Supersession, and Archive. A National Portfolio Report may be withdrawn, superseded, restricted, sealed, recalled, or archived where source rights fail, sensitive information is exposed, public-safe errors occur, national routing is incomplete, safeguards are unresolved, data status changes, public authority language is unsafe, finance or procurement overclaim occurs, consent overclaim occurs, or evidence is materially incorrect.
3.10.10 National Portfolio No-Conversion Rule. No National Portfolio Report, national atlas, DRI table, DRF readiness map, WFEH-B system summary, technology opportunity map, Campaign summary, Academy record, Labs record, support record, Nexus Universe record, Registry record, Marketplace listing, DOI, repository deposit, dashboard, or handoff context note shall create country ranking, sovereign rating, public authority approval, public warning, policy adoption, public finance allocation, procurement status, financeability, insurability, underwriting acceptance, donor commitment, certification, community consent, Indigenous consent where applicable, deployment authorization, operational command, or execution.
3.11 National Portfolio Annual Cycle and Nexus Universe Interface
3.11.1 Annual Cycle Doctrine. National Portfolio Reports shall support a repeating annual cycle that connects year-round national work to Nexus Universe and back into national continuation. The annual cycle shall convert signals into records, records into reports, reports into learning, learning into Campaigns, Campaigns into Working Groups, Working Groups into Competence Cells, Competence Cells into Foundry outputs, Foundry outputs into Nexus Universe displays, Nexus Universe outputs into National Portfolio updates, and National Portfolio updates into continuation pathways.
3.11.2 Pre-Nexus Universe Portfolio Preparation. Before Nexus Universe, National Portfolio Reports or pre-report briefs may identify national themes, WFEH-B priorities, DRR needs, DRF questions, DRI gaps, DICE data needs, GRIx mapping needs, Observatory requirements, Campaign needs, Academy needs, Foundry tasks, Labs opportunities, Risk Agency pathways, support needs, and potential Nexus Universe arenas.
3.11.3 Nexus Universe Portfolio Display. During Nexus Universe, National Portfolio materials may be displayed in public-safe formats, including national portfolio summaries, public-safe dashboards, Campaign summaries, Foundry outputs, Academy pathways, Labs questions, support needs, DRI summaries, and Studio demonstrations. Display shall be governed by claims freeze, data freeze, technical freeze, public-safe review, sponsor/provider controls, public authority boundaries, and correction channels.
3.11.4 Post-Nexus Universe Portfolio Report. After Nexus Universe, a National Portfolio Report may consolidate annual-cycle outputs, participation, arena summaries, Core Build relevance, Campaign records, support records, public authority learning summaries, readiness room summaries, Foundry continuation, Academy pathways, DICE/GRIx/DRI updates, Observatory needs, corrections, non-continuations, and handoff dependency candidates.
3.11.5 National Continuation. National Portfolio Reports shall route continuation to National Nodes, National Nexus Consortiums, National Working Groups, Nexus Competence Cells, Academy pathways, Campaigns, Foundry tasks, Labs streams, Risk Agency pathways, DICE stewardship, DRI dashboard development, GRIx ontology refinement, Observatory tasks, Studio workflows, Nexus Grid, TRL evidence development, and lawful handoff.
3.11.6 Regional and Global Interface. National Portfolio Reports may be aggregated or compared at regional and global levels only in public-safe, non-ranking, non-punitive, non-market-scoring ways. Regional or global synthesis shall preserve national ownership, avoid country ranking, avoid donor allocation implications, avoid insurance scoring, and avoid public authority overclaim.
3.11.7 Annual Update Status. National Portfolio Reports may have annual editions, living updates, corrected versions, pre-Universe briefs, post-Universe reports, technical annexes, public-safe summaries, and archive versions. Each shall be versioned and Registry-linked.
3.11.8 Annual Cycle Boundary. Nexus Universe presence, annual display, report publication, national showcase, public authority attendance, sponsor support, provider contribution, or media coverage shall not create endorsement, public authority approval, procurement, finance, insurance, certification, consent, deployment, or execution.
3.12 Final Operating Statement
3.12.1 Final National Portfolio Formula. National Portfolio Reports shall be the flagship Nexus Reports instrument for making national risk and innovation capacity visible across WFEH-B, DRR, DRF, DRI, public-good technology, data commons, ontology, observability, learning, campaigns, research, expertise pathways, Nexus Universe participation, support, correction, and lawful handoff. They shall be national public-good knowledge products, not official rankings, warnings, approvals, investment documents, insurance documents, procurement documents, consent records, or execution plans.
3.12.2 Final WFEH-B Formula. WFEH-B reporting shall show water, food, energy, health, and biodiversity as interconnected national systems. It shall make cross-system risks, dependencies, evidence gaps, innovation opportunities, data needs, and observability needs visible while protecting sensitive information and avoiding official classification, public warning, finance, procurement, certification, consent, or deployment overclaim.
3.12.3 Final DRR / DRF / DRI Formula. DRR reporting shall support risk reduction learning without warning authority. DRF reporting shall structure finance-readiness questions without finance. DRI reporting shall publish public-safe intelligence without ratings, rankings, warnings, insurance scores, investment signals, or public authority classifications.
3.12.4 Final Innovation Formula. National innovation reporting shall make frontier technology capability and readiness context visible without certifying technology, validating providers, approving deployment, creating procurement status, or authorizing execution. TRL and Grid references shall remain bounded evidence, not certification.
3.12.5 Final National Ownership Formula. National Portfolio Reports shall preserve national ownership, national routing, national data rules, public authority boundaries, community safeguards, Indigenous protocols where applicable, language localization, accessibility, and lawful national continuation. They shall not permit global, regional, sponsor, provider, donor, capital-reader, insurer, media, or enterprise actors to bypass national pathways.
3.12.6 Final Declaration. Nexus Reports shall make National Portfolios the central public-safe publication vehicle for country-level risk and innovation work. Through National Portfolio Reports, Nexus shall show what a country’s stakeholders are building, learning, mapping, supporting, correcting, and preparing across WFEH-B, DRR, DRF, DRI, data, technology, campaigns, labs, academy, foundry, observatory, universe, registry, marketplace, and handoff pathways. The reports shall be powerful because they organize national capability; legitimate because they preserve boundaries; expert-grade because they are evidence-linked and method-aware; safe because they protect sensitive sources; and trustworthy because they never let national visibility become false approval, finance, insurance, procurement, consent, deployment, or execution.
4. Open Science Infrastructure, Zenodo Strategy, DOI Discipline, FAIR Metadata, Licensing, Repositories, and Controlled-Knowledge Governance
4.1 Open Science and Open Knowledge Doctrine
4.1.1 Open-Knowledge Orientation. Nexus Reports shall operate with an open-science, open-knowledge, open-methods, open-metadata, open-ecosystem, and public-good publication orientation wherever lawful, ethical, rights-compliant, public-safe, technically responsible, nationally appropriate, and safeguard-aligned. The purpose of this orientation shall be to make Nexus knowledge discoverable, citable, reusable within rights, independently intelligible, teachable, correctable, and durable across countries, regions, disciplines, institutions, and generations of work.
4.1.2 Open Does Not Mean Ungoverned. Open science under Nexus Reports shall not mean uncontrolled disclosure, automatic public release, unrestricted downloading, unrestricted AI training, unrestricted commercial reuse, unrestricted geospatial exposure, unrestricted publication of public authority materials, unrestricted release of community knowledge, or unrestricted release of Indigenous protocol-sensitive knowledge where applicable. Openness shall be governed by data-use labels, AI-use labels, licenses, public-safe review, privacy controls, cybersecurity controls, national routing, community safeguards, protected knowledge rules, and correctionability.
4.1.3 Public-Safe Openness. Nexus Reports shall prioritize public-safe openness: the publication of outputs that can be made public without exposing sensitive people, places, systems, data, institutions, communities, protected knowledge, public authority materials, cyber-sensitive information, infrastructure-sensitive information, youth data, health-sensitive information, geospatially sensitive details, or lawful handoff dependencies. Public-safe openness shall allow the public to learn from Nexus work without turning publication into harm, panic, overclaim, or false reliance.
4.1.4 Layered Knowledge Release. Nexus Reports shall use a layered knowledge-release model. A project, portfolio, or report may include an open public report; a public-safe summary; an open metadata record; a controlled dataset description; a restricted data dictionary; a secure-room evidence pack; a data-room technical annex; a compute-to-data workflow; a sealed protected knowledge record; a Registry status record; a Marketplace discovery record; and an archive record. The public layer shall not expose the controlled layer.
4.1.5 Open Metadata as Public-Good Infrastructure. Where full data or source files cannot be public, Nexus Reports shall still seek to publish lawful and public-safe metadata, including title, abstract, thematic tags, country or region where appropriate, report family, output class, source classes, data availability statement, access class, license, review status, public-safe status, and correction pathway. Open metadata shall help others find, cite, and understand the existence and status of work without exposing restricted sources.
4.1.6 Open Methods Where Safe. Nexus Reports shall publish methods, assumptions, ontology structures, indicator definitions, schema designs, public-safe workflows, review methods, reproducibility notes, and limitations where publication is lawful and safe. Where methods themselves could expose vulnerabilities, sensitive operations, protected knowledge, secure-room logic, public authority-sensitive processes, cyber-sensitive details, or misuse-enabling information, Nexus Reports shall publish only public-safe method summaries.
4.1.7 Open Software Where Responsible. Nexus Reports may support publication of public-good software, open technical baselines, code, APIs, connectors, schemas, dashboards, notebooks, templates, model cards, system cards, benchmark cards, and reproducibility packages where rights, cybersecurity review, dual-use review, public-safe review, license, support class, and maintenance status permit. Software publication shall not imply warranty, certification, security approval, procurement suitability, deployment readiness, or operational authorization.
4.1.8 Controlled Knowledge as Public-Good Protection. Nexus Reports shall treat controlled knowledge not as a failure of openness but as a necessary condition of responsible publication. Public authority-sensitive data, community-sensitive data, Indigenous protocol-sensitive materials where applicable, protected knowledge, youth data, health-sensitive data, cyber-sensitive information, infrastructure-sensitive information, precise sensitive geospatial data, humanitarian-sensitive information, and lawful handoff materials may require restriction, redaction, aggregation, sealing, secure-room treatment, data-room treatment, compute-to-data treatment, or archive-only preservation.
4.1.9 Open Ecosystem Without Capture. Nexus Reports shall support an open ecosystem of contributors, universities, labs, public authorities in learning roles, communities, youth, civil society, sponsors, providers, donors, insurers, capital readers, public finance readers, and lawful downstream actors without allowing openness to become sponsor capture, provider validation, public authority overclaim, procurement distortion, finance promotion, data extraction, protected knowledge extraction, or execution by publication.
4.1.10 Final Open-Knowledge Rule. Nexus Reports shall be open by design and governed by necessity. It shall publish as much as can responsibly be made public, protect what must remain controlled, and make the distinction visible through metadata, labels, licenses, public-safe summaries, Registry records, correction pathways, and archive rules.
4.2 Zenodo and Comparable Repository Strategy
4.2.1 Zenodo Strategy. Nexus Reports shall use Zenodo and comparable open-science repositories as public deposit and citation infrastructure for public-safe Nexus Reports outputs, including reports, national portfolio reports, technical notes, methods papers, data papers, software releases, ontology releases, schema packages, public-safe evidence packs, dashboard documentation, Academy materials, Nexus Universe outputs, correction notices, and archive records where appropriate.
4.2.2 Repository Role. Zenodo-style infrastructure shall provide persistent public discoverability, DOI assignment where available, metadata preservation, versioning, file hosting, repository community organization, and citation support. It shall not replace Nexus Registry, Nexus Marketplace, DICE, Nexus Studio, Nexus Network, secure rooms, data rooms, national repositories, protected archives, legal review, data governance, public-safe review, AI-use governance, or correction authority.
4.2.3 Repository Selection Criteria. Repository choice shall be determined by output class, sensitivity, access class, national requirements, repository terms, metadata needs, DOI needs, software needs, data size, versioning requirements, license requirements, community needs, long-term preservation requirements, cybersecurity considerations, data sovereignty, protected knowledge controls, and integration with Registry and Marketplace.
4.2.4 Zenodo-Appropriate Outputs. Zenodo or equivalent public repositories may be appropriate for: 4.2.4.1 public-safe reports and briefs; 4.2.4.2 National Portfolio Reports and public-safe national atlases; 4.2.4.3 WFEH-B, DRR, DRF, and DRI reports; 4.2.4.4 DICE metadata packages and open data papers; 4.2.4.5 GRIx ontology releases and risk taxonomy packages; 4.2.4.6 Observatory public-safe method notes; 4.2.4.7 Foundry public-good software releases; 4.2.4.8 Academy learning packages where public; 4.2.4.9 Nexus Universe public-safe annual-cycle outputs; 4.2.4.10 correction notices, supersession notices, withdrawal notices, and archive records.
4.2.5 Zenodo-Inappropriate Outputs. Zenodo or equivalent fully public repositories shall not be used for restricted datasets, confidential public authority materials, protected knowledge, Indigenous protocol-sensitive materials where applicable, youth-sensitive data, health-sensitive data, cyber-sensitive details, infrastructure-sensitive information, precise sensitive geospatial information, secure-room evidence packs, data-room-only records, handoff-recipient-only materials, legal-hold records, controlled source files, or material whose license or consent status does not permit public deposit.
4.2.6 Comparable Repository Layer. Nexus Reports may also use institutional repositories, national repositories, domain-specific repositories, public data portals, InvenioRDM instances, OSF-style project spaces, GitHub or GitLab repositories, software registries, preprint servers, journal platforms, public-good archives, community repositories, secure repositories, and national data environments. Each repository shall be selected for its appropriate function, not used as a universal substitute for Nexus governance.
4.2.7 Repository Communities and Collections. Nexus Reports may establish repository communities, collections, series, or folders for National Portfolios, WFEH-B, DRR, DRF, DRI, DICE, GRIx, Observatory, Foundry, Campaigns, Academy, Labs, Risk Agency, Nexus Universe, correction notices, and archive records. Membership in a repository community shall indicate collection placement only and shall not imply approval, endorsement, certification, public authority status, maturity, procurement relevance, financeability, or execution.
4.2.8 Repository Deposit Authority. Deposit authority shall be role-scoped. Only authorized publication stewards, repository stewards, series stewards, or designated publication roles may deposit Nexus Reports outputs under official Nexus communities, institutional accounts, or controlled series. Unauthorized deposits shall not be treated as official Nexus Reports outputs.
4.2.9 Repository Record Synchronization. Repository records shall be synchronized with Nexus Registry where possible. If a repository record is corrected, versioned, superseded, withdrawn, or archived, corresponding Registry and Marketplace records shall be updated. If Registry status changes, repository metadata, landing pages, or correction notices should be updated where appropriate.
4.2.10 Repository Boundary. A repository deposit, DOI, community listing, download count, citation count, version number, or public access status shall not create approval, certification, public authority approval, procurement status, financeability, insurability, donor commitment, public finance allocation, consent, deployment authorization, operational command, or execution.
4.3 DOI, Persistent Identifier, Citation, and Version Discipline
4.3.1 Persistent Identifier Doctrine. Nexus Reports shall use persistent identifiers where appropriate to make outputs citable, traceable, discoverable, and durable. Persistent identifiers shall support scholarly reference, public-good memory, version tracking, correction propagation, contributor recognition, and cross-system linkage. They shall not create substantive authority.
4.3.2 DOI Use. A DOI may be assigned to a public-safe report, dataset, software release, ontology release, schema package, methods paper, evidence pack, dashboard documentation, National Portfolio Report, Nexus Universe Report, correction notice, withdrawal notice, or archive record where the output is suitable for persistent public citation.
4.3.3 DOI Meaning. A DOI shall mean that a publication object has a persistent citation record. It shall not mean that the object is official, approved, certified, current forever, validated, complete, safe for operational use, financeable, insurable, procurable, deployable, or executable.
4.3.4 Version-Specific Citation. Nexus Reports shall distinguish between version-specific citation and series-level or concept-level citation where supported. Readers shall be able to identify which version was cited, whether a newer version exists, whether the cited version has been corrected, and whether the cited version remains current.
4.3.5 Current Version Statement. Each public Nexus Report should include a current version statement identifying version number, date, DOI or persistent identifier, Registry status, whether the version supersedes prior versions, and where current status may be checked.
4.3.6 Related Identifier Discipline. Reports shall use related identifiers to link associated outputs, including datasets, software releases, ontology packages, dashboards, Registry records, Marketplace listings, prior versions, translations, technical annexes, public-safe summaries, correction notices, supersession notices, and archive records.
4.3.7 Citation Format. Nexus Reports shall provide recommended citation formats for reports, data, software, ontologies, dashboards, and correction notices. Citation formats should include title, authors or institutional steward, year or date, version, report family, persistent identifier, Registry record where appropriate, and access date where current status may change.
4.3.8 Citation of Sensitive Sources. Where source materials are restricted, controlled, sealed, secure-room-only, data-room-only, or protected, public reports may cite a controlled-source category, metadata record, Registry record, or public-safe source note rather than exposing the source. Citation discipline shall not override confidentiality or protected knowledge controls.
4.3.9 Citation and Contributor Recognition. Persistent identifiers may support contributor recognition and portfolio linkage. Contributor citation shall distinguish authors, contributors, data stewards, software contributors, reviewers, translators, accessibility contributors, public-safe reviewers, safeguard reviewers, sponsors, providers, and support actors. Citation shall not create certification, employment, procurement qualification, expert status, or authority.
4.3.10 DOI and Citation Boundary. DOI assignment, citation, indexing, repository visibility, search visibility, download activity, citation count, or inclusion in a curated collection shall not create approval, certification, public authority action, procurement status, financeability, insurability, rating, ranking, consent, deployment authorization, operational command, or execution.
4.4 Metadata Architecture and FAIR-Aligned Publication Practice
4.4.1 Metadata as Infrastructure. Metadata shall be treated as a core infrastructure layer of Nexus Reports. Every material publication shall be described through structured metadata that supports discovery, citation, interoperability, rights management, public-safe interpretation, review status, data-use governance, AI-use governance, correction, archive, and cross-system routing.
4.4.2 Required Metadata Classes. Nexus Reports metadata should include: 4.4.2.1 title, subtitle, abstract, public-safe abstract, and keywords; 4.4.2.2 report family, output class, series, edition, and version; 4.4.2.3 authors, contributors, roles, steward, and institutional context; 4.4.2.4 country, region, national pathway, or thematic pathway where applicable; 4.4.2.5 WFEH-B, DRR, DRF, DRI, DICE, GRIx, Observatory, Foundry, Campaign, Academy, Labs, Risk Agency, Nexus Universe, Grid, TRL, Marketplace, Registry, and handoff tags where applicable; 4.4.2.6 evidence class, source class, review level, public-safe status, and limitation status; 4.4.2.7 access class, license, data-use labels, AI-use labels, security labels, safeguard labels, and privacy labels; 4.4.2.8 DOI or persistent identifier, related identifiers, Registry ID, Marketplace ID, dataset ID, software ID, and archive ID where applicable; 4.4.2.9 correction status, supersession status, withdrawal status, renewal status, and archive status.
4.4.3 Public-Safe Abstract. Each public repository record should include a public-safe abstract that accurately states what the output is, what it covers, what evidence it uses, what its limitations are, what sensitive information is not included, and what authority it does not create. The abstract shall be suitable for public search and expert discovery.
4.4.4 Data Availability Metadata. Reports involving data shall include metadata describing whether data is open, public-safe, restricted, controlled, confidential, public authority-sensitive, community-sensitive, Indigenous-protocol-sensitive where applicable, protected knowledge, youth-sensitive, health-sensitive, cyber-sensitive, infrastructure-sensitive, geospatial-sensitive, secure-room-only, data-room-only, compute-to-data-only, no-download, no-publication, no-AI-training, no-handoff, or archive-only.
4.4.5 AI-Use Metadata. Reports involving AI-supported drafting, summarization, classification, translation, modelling, visualization, code generation, analysis, or public-output preparation shall include AI-use metadata where appropriate, including permitted AI uses, prohibited AI uses, human review status, model or tool class where relevant, source verification, public-safe review, and limitations.
4.4.6 Review Metadata. Reports shall identify review status, including editorial review, technical review, data steward review, AI-use review, public-safe review, safeguard review, national pathway review, public authority boundary review, finance boundary review, insurance boundary review, procurement boundary review, community safeguard review, Indigenous protocol-sensitive review where applicable, accessibility review, and repository metadata review where relevant.
4.4.7 Licensing Metadata. Reports shall identify license status for text, data, software, figures, maps, images, media, code, ontologies, schemas, provider materials, sponsor-supported materials, third-party materials, community materials, and restricted materials. Metadata shall not imply that all components share the same license unless expressly true.
4.4.8 FAIR-Aligned Findability. Nexus Reports shall make public-safe outputs findable through persistent identifiers, clear titles, structured abstracts, keywords, controlled vocabulary, related identifiers, Registry linkage, Marketplace listing, and repository communities where appropriate.
4.4.9 FAIR-Aligned Accessibility. Nexus Reports shall make outputs accessible within rights. Accessibility may mean open download for public-safe outputs, controlled access for restricted outputs, metadata-only discovery for sensitive outputs, secure-room access for high-risk materials, data-room access for controlled evidence, or compute-to-data access for sensitive data.
4.4.10 FAIR-Aligned Interoperability. Nexus Reports shall support interoperability through common identifiers, controlled vocabularies, DICE metadata, GRIx ontology, DRI indicator structures, WFEH-B tags, DRR/DRF/DRI tags, Nexus component tags, versioning, related identifiers, and Registry linkage.
4.4.11 FAIR-Aligned Reuse. Nexus Reports shall support reuse within license, rights, data-use labels, AI-use labels, public-safe limitations, attribution requirements, non-commercial restrictions where applicable, no-derivative restrictions where applicable, no-AI-training restrictions where applicable, and archive status.
4.4.12 Metadata Boundary. Metadata improves discovery, interpretation, and governance. Metadata publication shall not make restricted data open, authorize AI use, create public authority approval, certify quality, create procurement status, create financeability, grant consent, authorize handoff, or execute work.
4.5 Licensing, Rights, Reuse, Attribution, and Anti-Enclosure
4.5.1 Licensing Doctrine. Nexus Reports shall apply clear, component-specific licensing and rights statements to each publication. License clarity shall protect authors, contributors, communities, public-good assets, data stewards, software maintainers, sponsors, providers, public authorities, national pathways, and downstream users. License ambiguity shall be corrected before reuse is encouraged.
4.5.2 Component-Specific Licensing. A Nexus Report may contain multiple components with different rights: text, tables, figures, maps, dashboards, data, code, schemas, ontologies, images, media, provider materials, sponsor-supported materials, public authority materials, community materials, third-party content, and software artefacts. Each component shall carry or reference the correct license or restriction.
4.5.3 Open Licenses. Nexus Reports may use open licenses for public-safe text, data, code, schemas, software, and media where lawful and appropriate. Open licensing shall be selected deliberately and shall not be assumed from public availability alone.
4.5.4 Restricted Licenses. Restricted licenses may be used for controlled reports, research-only outputs, educational-use outputs, no-commercial-use outputs, no-derivative outputs, provider-restricted materials, sponsor-supported materials, data-use-restricted materials, API-restricted materials, Studio-use-only materials, handoff-use-only materials, archive-only materials, or protected source summaries.
4.5.5 Public-Good License Strategy. Nexus Reports may support public-good licensing models that allow reuse, translation, localization, learning, public-good adaptation, and public-safe redistribution while preventing enclosure, false certification, misleading derivative use, provider lock-in, sponsor capture, or unauthorized commercial exploitation.
4.5.6 Attribution. Reports shall identify authorship, contribution, data stewardship, software contribution, review, translation, accessibility support, public-safe review, safeguard review, sponsorship, provider contribution, host support, and funding support accurately. Attribution shall not overstate endorsement, authority, control, or validation.
4.5.7 Contributor Rights. Contributor terms shall clarify how contributions may be used, attributed, corrected, withdrawn from public display where feasible, archived, translated, included in derivative works, included in public-safe summaries, included in Academy materials, linked to Registry portfolios, or cited in Nexus Reports.
4.5.8 Anti-Enclosure. Public-good reports, methods, ontologies, open technical baselines, public-good software, public-safe templates, DICE structures, GRIx mappings, DRI methods, Academy materials, and Nexus Reports outputs shall not be privately enclosed, rebranded as proprietary certification, restricted as exclusive authority, converted into provider lock-in, or used to imply procurement or finance advantage without clear rights, public-good review, and correction pathways.
4.5.9 Third-Party Materials. Reports using third-party materials shall identify permissions, citations, license status, derivative restrictions, commercial restrictions, attribution requirements, and public display limits. Third-party use shall not transfer rights to Nexus beyond what is permitted.
4.5.10 AI-Generated and AI-Assisted Rights. Reports using AI-generated or AI-assisted text, code, images, translations, classifications, summaries, or visualizations shall respect source rights, contributor rights, data-use labels, AI-use labels, public-safe review, and copyright or licensing constraints. AI assistance shall not launder restricted content into open outputs.
4.5.11 Rights Incidents. Rights incidents may include unauthorized publication, license misstatement, plagiarism, contributor misattribution, unauthorized AI derivative use, improper commercialization, provider enclosure, sponsor misuse, public-good asset capture, data license violation, public authority material misuse, or protected knowledge exposure. Rights incidents shall trigger correction, restriction, takedown, withdrawal, recall, or archive.
4.5.12 Licensing Boundary. Licensing and rights statements govern reuse. They shall not create certification, public authority approval, procurement status, financeability, insurance approval, consent, deployment authorization, operational command, or execution authority.
4.6 Data Publication, Controlled Data, Compute-to-Data, and Sensitive Source Governance
4.6.1 Data Publication Doctrine. Nexus Reports shall publish data openly only where rights, privacy, public authority restrictions, community safeguards, Indigenous protocols where applicable, protected knowledge controls, cybersecurity, infrastructure sensitivity, geospatial sensitivity, health sensitivity, youth protection, humanitarian sensitivity, license status, and public-safe review permit. Open data shall be a governed outcome, not a default assumption.
4.6.2 Data Availability Statements. Every report involving data shall include a data availability statement. The statement shall identify whether data is open, public-safe, restricted, controlled, confidential, public authority-sensitive, community-sensitive, Indigenous-protocol-sensitive where applicable, protected knowledge, youth-sensitive, health-sensitive, cyber-sensitive, infrastructure-sensitive, geospatial-sensitive, secure-room-only, data-room-only, compute-to-data-only, no-download, no-publication, no-AI-training, no-commercial-use, no-handoff, or archive-only.
4.6.3 Metadata-Only Publication. Where data cannot be published, Nexus Reports may publish metadata-only records, codebooks, data dictionaries, schemas, lineage notes, public-safe aggregate descriptions, synthetic examples, data quality summaries, access conditions, or controlled-source notes.
4.6.4 Aggregation and Redaction. Nexus Reports may use aggregation, redaction, spatial generalization, temporal generalization, category masking, anonymization where lawful and adequate, pseudonymization where appropriate, suppression, noise addition where appropriate, or public-safe transformation to reduce risk. Such transformations shall be described honestly and shall not imply full data transparency.
4.6.5 Compute-to-Data. For restricted, sovereign-sensitive, public authority-sensitive, rights-bearing, community-protected, protected-knowledge-sensitive, health-sensitive, cyber-sensitive, infrastructure-sensitive, geospatial-sensitive, or high-risk data, Nexus Reports should prefer compute-to-data, secure rooms, clean rooms, confidential computing, controlled rooms, no-download rooms, or data rooms rather than raw data export.
4.6.6 Secure and Controlled Evidence Packs. Reports may be accompanied by controlled evidence packs accessible only to authorized reviewers, stewards, national actors, public authority learning participants, data-room participants, secure-room participants, or handoff recipients. Controlled evidence packs shall not be indexed or deposited publicly.
4.6.7 Public Authority Data. Public authority data shall not be published, summarized, exported, translated, AI-used, visualized, or included in public reports unless public authority restrictions, national law, confidentiality, public-safe review, data-use labels, AI-use labels, and publication permissions permit.
4.6.8 Community and Indigenous Protocol-Sensitive Data. Community-sensitive data and Indigenous protocol-sensitive materials where applicable shall not be opened, mapped, summarized, translated, AI-used, commercialized, displayed, or deposited unless appropriate authority, permission, safeguards, and public-safe conditions are recorded.
4.6.9 Geospatial Sensitivity. Reports involving maps, locations, infrastructure, ecological resources, protected sites, vulnerable communities, field sites, sensors, public authority assets, or critical systems shall undergo geospatial sensitivity review. Sensitive locations shall be generalized, masked, restricted, or excluded where necessary.
4.6.10 Data Correction and Withdrawal. Data-related reports shall be corrected, restricted, withdrawn, recalled, or archived where rights change, data-use labels change, source errors appear, privacy risk emerges, protected knowledge is identified, geospatial sensitivity changes, public authority restrictions change, or downstream misuse occurs.
4.6.11 Data Publication Boundary. Data publication, metadata publication, codebook publication, aggregate publication, or data availability statement shall not create unrestricted data rights, AI training rights, commercial-use rights, public authority approval, privacy compliance certification, cybersecurity certification, community consent, Indigenous consent where applicable, handoff authorization, deployment authorization, or execution.
4.7 AI-Use Governance in Publication and Repository Workflows
4.7.1 AI-Use Governance Doctrine. Nexus Reports may use AI-assisted tools for drafting support, summarization, translation, classification, coding, data cleaning, visualization, literature screening, metadata extraction, ontology support, public-safe summary preparation, accessibility support, and workflow support only where AI-use labels, data-use labels, human review, source verification, privacy controls, public-safe review, and rights constraints permit.
4.7.2 No AI-Use by Default for Restricted Records. Restricted, controlled, confidential, public authority-sensitive, community-sensitive, Indigenous-protocol-sensitive where applicable, protected knowledge, youth-sensitive, health-sensitive, cyber-sensitive, infrastructure-sensitive, geospatial-sensitive, secure-room-only, data-room-only, no-AI-training, no-external-API, no-third-party-AI, or archive-only materials shall not be processed by AI unless the recorded AI-use label permits the specific processing.
4.7.3 AI-Use Statements. Reports shall include AI-use statements where AI materially assisted drafting, summarization, translation, classification, coding, analysis, visualization, or public-output generation. The statement should identify the class of AI use, human review, source verification, limitations, and prohibited reliance.
4.7.4 AI for Public-Safe Summaries. AI may support public-safe summaries only under human review and public-safe review. AI shall not decide what is safe to publish, what constitutes public authority meaning, what counts as consent, what is financeable, what is insurable, what is procurement-relevant, or what can be handed off.
4.7.5 AI for Translation and Localization. AI-assisted translation may be used where permitted, but translations shall preserve meaning, no-conversion notices, legal boundaries, public-safe status, data-use labels, AI-use labels, and national context. Human review shall be required where reliance risk, public authority language, finance language, legal meaning, community safeguards, or Indigenous protocol-sensitive content is involved.
4.7.6 AI for Data and DRI Outputs. AI-assisted data classification, anomaly detection, indicator drafting, dashboard summarization, or DRI interpretation shall be labeled, reviewed, source-verified, uncertainty-aware, and prohibited from automated high-stakes decisions, public warnings, public authority decisions, insurance decisions, finance decisions, procurement decisions, or deployment authorizations.
4.7.7 AI for Metadata. AI may assist metadata extraction and tagging where source rights and access rules permit. AI-generated metadata shall be reviewed and corrected where necessary; it shall not become status truth without Registry validation.
4.7.8 AI Hallucination Controls. Nexus Reports shall maintain controls against AI hallucination, fabricated citations, invented data, unsupported claims, false author information, false public authority language, false finance implications, false provider claims, false sponsor claims, and false status labels.
4.7.9 AI-Use Incidents. AI-use incidents may include unauthorized processing, unauthorized AI training, hallucinated publication content, false citation generation, restricted source exposure, public-safe summary failure, biased or discriminatory output, protected knowledge exposure, public authority overclaim, finance overclaim, procurement overclaim, or unsafe translation. Incidents shall trigger correction, withdrawal, recall, sealing, or archive.
4.7.10 AI Boundary. AI-use in Nexus Reports shall support publication workflows only. It shall not create authorship by itself, certification, legal advice, financial advice, insurance advice, public authority decision-making, community consent determination, Indigenous consent determination where applicable, deployment authorization, operational command, or execution.
4.8 Repository Security, Access Control, Integrity, and Preservation
4.8.1 Repository Security Doctrine. Nexus Reports shall treat repository security, account integrity, metadata integrity, access control, version integrity, and correction integrity as core publication infrastructure. Public trust requires that public records, DOIs, metadata, files, corrections, and archive states are protected from unauthorized change, impersonation, tampering, and misleading duplication.
4.8.2 Authorized Accounts. Official Nexus Reports repository deposits shall occur only through authorized accounts, institutional accounts, approved repository communities, designated publication stewards, or authorized repository stewards. Personal uploads shall not be treated as official Nexus Reports outputs unless accepted into the official record.
4.8.3 Deposit Controls. Deposits shall be checked for file integrity, metadata accuracy, license accuracy, author and contributor accuracy, related identifiers, public-safe status, data-use labels, AI-use labels, support statements, sponsor/provider disclosures, no-conversion notices, and Registry linkage before publication where possible.
4.8.4 Access Controls for Controlled Records. Controlled source files shall be kept in systems appropriate to their sensitivity, including Nexus Registry restricted records, DICE controlled environments, Nexus Studio, secure rooms, data rooms, national repositories, protected archives, legal-hold environments, or other governed systems. Public repositories shall not be used as controlled-source stores.
4.8.5 Integrity Checks. Nexus Reports may use checksums, version logs, repository metadata, Registry status, release notes, linked identifiers, audit logs where appropriate, and correction records to preserve publication integrity.
4.8.6 Impersonation and Duplicate Control. Nexus Reports shall monitor for unauthorized copies, misleading reposts, fake Nexus Reports, fake DOI records, fake National Portfolio Reports, fake provider-supported reports, fake sponsor-supported reports, fake public authority learning reports, and fake correction notices where feasible. Misleading duplicates shall be corrected through public-safe notice, takedown request where appropriate, Registry notice, Marketplace correction, or archive note.
4.8.7 Long-Term Preservation. Nexus Reports shall use repository infrastructure, Registry records, Network memory, archive policies, versioning, and persistent identifiers to support long-term preservation. Preservation shall include public record continuity and non-current status clarity.
4.8.8 Sensitive File Exclusion. Public repository deposits shall exclude raw restricted data, credential files, keys, sensitive logs, personal data, youth data, protected knowledge, public authority confidential materials, infrastructure-sensitive materials, cyber-sensitive exploit details, precise sensitive geospatial files, and handoff-recipient-only content unless an appropriate public release has been expressly recorded.
4.8.9 Security Incident Response. Repository security incidents may include account compromise, unauthorized deposit, unauthorized file replacement, metadata tampering, license tampering, false correction notice, malicious file upload, exposed restricted data, exposed credentials, or fake repository community activity. Incidents shall trigger containment, correction, public-safe notice, withdrawal, recall, and Registry update where appropriate.
4.8.10 Repository Integrity Boundary. Repository security and preservation protect publication integrity. They shall not create warranty, certification, legal compliance assurance, cybersecurity certification, public authority approval, procurement approval, finance approval, insurance approval, deployment readiness, or execution authority.
4.9 Repository Communities, Series Pages, Collections, Indexing, and Discovery
4.9.1 Discovery Architecture. Nexus Reports shall use repository communities, Registry collections, Marketplace listings, series pages, topic pages, national pages, Nexus Universe pages, Academy pages, DICE pages, GRIx pages, DRI pages, Observatory pages, and public-safe dashboards to make publications discoverable in coherent ways.
4.9.2 National Collections. National Portfolio Reports and related outputs may be organized by country or national pathway. National collections shall display public-safe national work without ranking, scoring, comparing, approving, warning, financing, insuring, procuring, or executing for the country.
4.9.3 Thematic Collections. WFEH-B, DRR, DRF, DRI, climate, biodiversity, cyber, AI, AI-RAN, O-RAN, private wireless, HPC, geospatial, Earth observation, digital twin, health, food, water, energy, nature, Academy, Foundry, Campaign, Labs, Risk Agency, and Nexus Universe collections may be maintained for discovery. Thematic collection membership shall not imply certification or endorsement.
4.9.4 Nexus Universe Collections. Nexus Universe outputs may be organized by annual cycle, host arena, room, National Portfolio, Core Build, public authority learning, readiness room, Foundry output, Campaign output, or after-action record. Nexus Universe collection placement shall not imply endorsement, public authority approval, or execution.
4.9.5 Correction Collections. Correction notices, withdrawal notices, supersession notices, retraction notices where necessary, recall notices, non-continuation notes, and archive records may be organized in dedicated correction collections so readers can identify current and prior status.
4.9.6 Search and Indexing Controls. Search visibility shall be governed by public-safe status, access class, data-use labels, AI-use labels, repository policy, Registry status, and publication class. Sensitive records shall not be indexed publicly merely because public metadata exists.
4.9.7 Discovery Without Authority. Curated collections, featured publications, series pages, trending outputs, high-download reports, repository communities, Nexus Reports front-page placement, or Marketplace listing shall assist discovery only. They shall not create approval, ranking, priority, financeability, procurement relevance, or public authority attention by implication.
4.9.8 Discovery Metadata Quality. Discovery pages shall use accurate metadata, clear descriptions, boundaries, current-version indicators, correction links, archive labels, related identifiers, and no-conversion notices where relevant.
4.9.9 Public Interface Consistency. Registry, Marketplace, repository pages, Nexus Reports pages, Academy pages, Campaign pages, Nexus Universe pages, and public dashboards shall use consistent status language. A report should not appear current in one system and withdrawn in another.
4.9.10 Discovery Boundary. Discoverability, indexing, collection membership, curation, featuring, or repository community placement shall not create endorsement, certification, public authority approval, procurement status, financeability, insurance approval, donor commitment, consent, deployment authorization, operational command, or execution.
4.10 Open Infrastructure Risk Controls and Regulated-Perimeter Safeguards
4.10.1 Open Infrastructure Risk Doctrine. Open publication infrastructure increases reach, durability, citability, and legitimacy, but it also increases risks of misinterpretation, misuse, unauthorized reuse, data extraction, AI scraping, finance overclaim, procurement distortion, public authority confusion, and public-safe harm. Nexus Reports shall manage these risks through classification, metadata, public-safe review, licenses, repository controls, correction, and no-conversion notices.
4.10.2 AI Scraping and Reuse Controls. Nexus Reports shall label outputs that prohibit AI training, restrict AI use, restrict commercial reuse, or restrict derivative use. Public availability shall not imply permission for AI training, model fine-tuning, embedding, retrieval indexing, commercial AI use, or agentic workflow use where labels prohibit it.
4.10.3 Commercial Reuse Controls. Reports and artefacts may be open for public-good reuse but restricted for commercial exploitation where appropriate. Commercial reuse shall be governed by license and shall not permit false certification, provider marketing, procurement overclaim, finance overclaim, insurance overclaim, or public authority overclaim.
4.10.4 Financial Promotion Controls. Openly available DRF, finance-readiness, insurance-readiness, donor-readiness, public finance relevance, or handoff-related reports shall include no-reliance, non-advisory, non-soliciting, non-transactional, no-rating, no-valuation, no-underwriting, no-public-finance-allocation, and no-investment-advice language.
4.10.5 Procurement Controls. Openly available provider-related, technology-related, software-related, Studio-related, Foundry-related, Grid-related, TRL-related, or National Portfolio reports shall include no-procurement, no-preferred-provider, no-vendor-approval, no-public-authority-approval, no-certification, and independent diligence language where relevant.
4.10.6 Public Authority Controls. Reports involving public authorities shall use public authority learning language unless a competent public authority has separately and lawfully established another status. Repository publication shall not convert public authority participation into official approval.
4.10.7 Community and Consent Controls. Reports involving communities, youth, Indigenous protocols where applicable, protected knowledge, humanitarian settings, or public-interest stakeholders shall include participation-without-consent language where appropriate. Open publication shall not convert stories, signatures, attendance, interviews, or data contributions into consent or consultation completion.
4.10.8 Cyber and Dual-Use Controls. Technical reports, software releases, cybersecurity materials, infrastructure materials, digital twin materials, sensor materials, drone materials, AI-agent materials, and geospatial materials shall be reviewed for misuse risk before open release. Misuse-enabling details shall be restricted, generalized, delayed, redacted, or withheld where appropriate.
4.10.9 Correction and Takedown Controls. If open infrastructure publication creates harm, overclaim, data exposure, rights violation, AI misuse, public authority confusion, finance overclaim, procurement overclaim, protected knowledge exposure, or security risk, Nexus Reports may issue correction, restrict access where possible, update metadata, withdraw files, publish a withdrawal notice, recall downstream uses, or archive.
4.10.10 Regulated-Perimeter Boundary. Open infrastructure use shall not create regulated financial activity, investment advice, insurance advice, public finance allocation, procurement advice, public authority approval, certification, professional advice, legal advice, employment status, consent, deployment authorization, or execution.
4.11 Open Infrastructure Workflow
4.11.1 Workflow Doctrine. Nexus Reports shall maintain a standard workflow for open infrastructure publication that ensures public outputs are classified, reviewed, rights-cleared, metadata-complete, repository-ready, Registry-linked, Marketplace-discoverable where appropriate, versioned, correctionable, and archive-ready.
4.11.2 Intake. Intake shall identify publication family, output class, steward, authors, contributors, source pathways, data classes, AI-use classes, sensitive materials, repository needs, DOI needs, national pathway, public authority relevance, sponsor/provider involvement, finance relevance, procurement relevance, consent sensitivity, and handoff relevance.
4.11.3 Release Classification. Release classification shall determine whether the output is open public, public-safe summary, controlled public, restricted, metadata-only, data-room-only, secure-room-only, national-pathway-restricted, public-authority-learning-only, handoff-recipient-only, sealed, no-publication, or archive-only.
4.11.4 Rights and License Review. Before deposit, Nexus Reports shall review ownership, license, contributor terms, third-party materials, data-use labels, AI-use labels, public authority restrictions, community safeguards, provider terms, sponsor terms, software licenses, and open-source compatibility where applicable.
4.11.5 Public-Safe Review. Before deposit, outputs shall be reviewed for public-safe language, no-conversion notices, protected knowledge, geospatial sensitivity, cyber sensitivity, infrastructure sensitivity, public authority overclaim, finance overclaim, procurement overclaim, provider validation, sponsor control, consent overclaim, and execution implication.
4.11.6 Metadata Preparation. Repository metadata shall be prepared using standardized fields, including title, abstract, public-safe abstract, report family, output class, authors, contributors, steward, version, date, license, keywords, related identifiers, Registry ID, Marketplace ID where applicable, data availability statement, AI-use statement, review status, correction pathway, and no-conversion notice.
4.11.7 File Packaging. Files shall be packaged according to output class. Packages may include report PDF, machine-readable metadata, dataset files where open, data dictionaries, codebooks, software files, README, license file, citation file, changelog, release notes, ontology files, schema files, dashboard documentation, correction note, and archive note.
4.11.8 Repository Deposit. Authorized repository stewards shall deposit the output into the appropriate repository, community, collection, or series. Deposit records shall be checked for accuracy before public dissemination.
4.11.9 Post-Deposit Linking. After deposit, the output shall be linked to Nexus Registry, listed in Nexus Marketplace where appropriate, routed to Academy, Campaigns, Foundry, DICE, GRIx, DRI, Observatory, Studio, Grid, TRL, Nexus Universe, National Nodes, and lawful handoff pathways as appropriate.
4.11.10 Post-Deposit Monitoring. Nexus Reports shall monitor for required corrections, broken links, metadata errors, license issues, public-safe issues, unauthorized reuse, repository errors, duplicate records, withdrawn status needs, and archive updates where feasible.
4.11.11 Workflow Boundary. Publication workflow controls support responsible dissemination. They shall not create certification, public authority approval, procurement status, financeability, insurance approval, consent, deployment authorization, operational command, or execution.
4.12 Final Operating Statement
4.12.1 Final Open Science Formula. Nexus Reports shall use open-science infrastructure to make public-safe Nexus knowledge citable, durable, discoverable, and reusable within rights. It shall use controlled Nexus infrastructure to preserve sensitive sources, restricted evidence, protected knowledge, public authority-sensitive records, community-sensitive records, secure-room materials, data-room materials, and lawful handoff packages.
4.12.2 Final Zenodo Formula. Zenodo and similar platforms shall publish the public-safe face of Nexus knowledge: reports, data papers, open datasets where safe, software releases, ontologies, schemas, public-safe evidence packs, national portfolios, Nexus Universe outputs, and correction records. Nexus Registry shall remain the status-truth layer; DICE shall remain the data-governance layer; Studio shall remain the controlled-workflow layer; secure rooms and data rooms shall remain controlled-source environments.
4.12.3 Final DOI Formula. A DOI shall make a Nexus Reports output citable, not approved. A repository record shall make an output discoverable, not unrestricted. A metadata record shall make work findable, not executable. A version number shall make history traceable, not permanently current. A collection shall organize knowledge, not certify it.
4.12.4 Final FAIR Formula. Nexus Reports shall make outputs findable, accessible within rights, interoperable through controlled metadata and vocabularies, and reusable within license and governance limits. FAIR shall mean governed reuse, not unrestricted exposure.
4.12.5 Final Controlled-Knowledge Formula. Where openness would create harm, violate rights, expose sensitive data, reveal protected knowledge, compromise public authorities, endanger communities, weaken cybersecurity, reveal sensitive geospatial information, distort finance or procurement, or create false reliance, Nexus Reports shall publish public-safe summaries, metadata, methods, aggregates, codebooks, or access statements rather than controlled sources.
4.12.6 Final Part IV Declaration. Nexus Reports shall be open enough to serve science, public knowledge, national portfolios, education, innovation, risk intelligence, and public-good reuse; and disciplined enough to prevent data exposure, AI misuse, protected knowledge extraction, cyber risk, sponsor capture, provider validation, public authority confusion, finance overclaim, procurement distortion, consent overclaim, and execution by publication. Its open infrastructure shall make Nexus work visible to the world while its governance infrastructure shall keep Nexus work truthful, bounded, correctable, and safe.
4. Evidence Architecture, Methods Discipline, Review Levels, Public-Safe Quality, and Expert Credibility
5.1 Evidence Architecture Doctrine
5.1.1 Evidence-Bearing Publication Rule. Nexus Reports shall be evidence-bearing by design. Every substantive Nexus Report shall identify the evidence classes on which it relies, the source pathways through which evidence was obtained, the methods used to interpret or organize that evidence, the limitations affecting that evidence, the review level applied to the output, the public-safe transformations made before publication, and the correction pathway available after publication.
5.1.2 Evidence Before Claims. Nexus Reports shall preserve the rule that claims follow evidence and that evidence shall not be stretched beyond its recorded scope. Reports shall distinguish between established facts, recorded observations, stakeholder submissions, public-safe interpretations, model outputs, AI-assisted summaries, expert judgments, assumptions, uncertainties, hypotheses, gaps, dependencies, and recommendations framed as non-binding learning questions or pathway options.
5.1.3 Evidence as Record-Linked Context. Evidence used in Nexus Reports shall, where appropriate, be linked to Nexus Registry records, DICE metadata, GRIx ontology mappings, DRI indicators, Nexus Observatory records, Nexus Studio workflow outputs, Nexus Grid inputs, TRL 1–10 evidence notes, Nexus Foundry records, Nexus Campaign records, Nexus Academy records, Nexus Labs records, Risk Agency pathway records, Nexus Universe records, support records, and lawful handoff dependency records. Record linkage shall support traceability; it shall not create certification.
5.1.4 Evidence-Class Identification. Each report shall identify whether its evidence is public, controlled, restricted, confidential, public authority-sensitive, community-sensitive, Indigenous-protocol-sensitive where applicable, protected-knowledge-sensitive, youth-sensitive, health-sensitive, infrastructure-sensitive, cyber-sensitive, geospatial-sensitive, humanitarian-sensitive, data-room-only, secure-room-only, compute-to-data-only, no-download, no-publication, no-AI-training, no-handoff, archive-only, or otherwise constrained.
5.1.5 Source-Class Discipline. Nexus Reports shall identify source classes rather than exposing source details where sensitivity requires protection. Source classes may include public datasets, peer-reviewed literature, public authority learning records, DICE metadata, controlled datasets, stakeholder submissions, Working Group records, Competence Cell outputs, Campaign records, Academy records, Labs research records, Foundry outputs, Studio workflow summaries, Observatory notes, DRI indicators, GRIx mappings, Grid inputs, TRL evidence notes, Nexus Universe records, support ledgers, and handoff dependency records.
5.1.6 Limitation Visibility. Limitations shall not be hidden in footnotes or treated as reputational weakness. Nexus Reports shall make limitations visible enough for expert readers and public-safe readers to understand what the report can and cannot support. Limitations may include incomplete data, outdated data, uncertain models, restricted sources, non-representative submissions, limited geographic coverage, unresolved rights, public authority-sensitive constraints, community safeguard constraints, protected knowledge exclusions, geospatial generalization, AI-use limits, review limits, or pending corrections.
5.1.7 Evidence Gap Recognition. Evidence gaps shall be recorded as valid report outputs. A Nexus Report may be important precisely because it identifies missing data, missing observability, missing ontology coverage, missing public authority learning, missing community safeguards, missing finance-readiness inputs, missing insurance-readiness inputs, missing Academy capacity, missing Foundry tasks, missing Labs research, or missing handoff dependencies.
5.1.8 Public-Safe Evidence Transformation. Sensitive evidence may be transformed into public-safe summaries, aggregates, generalized maps, redacted tables, metadata records, codebooks, methods notes, synthetic examples, or non-disclosing visualizations. Such transformation shall preserve honesty about what was removed, generalized, redacted, or controlled.
5.1.9 Evidence and Non-Execution. Evidence publication shall not authorize action. A report may identify evidence relevant to public authority learning, DRR planning, DRF questions, DRI dashboards, WFEH-B systems, technology readiness, Academy needs, Campaign mobilization, Foundry tasks, or lawful handoff dependencies, but evidence visibility shall not create public authority action, procurement, finance, insurance, consent, deployment, command, or execution.
5.1.10 Final Evidence Architecture Rule. Nexus Reports shall be trusted because evidence is classified, scoped, linked, limited, reviewed, public-safe, versioned, and correctable. Evidence shall make knowledge stronger without making publication falsely authoritative.
5.2 Evidence Classes and Source Pathways
5.2.1 Public Evidence. Public evidence may include public datasets, open government data, open scientific literature, open-source code, published standards materials, public policy documents, public hazard records, public statistical releases, public geospatial layers, public reports, open data portals, open repository records, public software releases, and other materials lawfully available for public use. Public evidence shall still be reviewed for accuracy, currency, license, context, public-safe interpretation, and overclaim risk.
5.2.2 Controlled Evidence. Controlled evidence may include non-public datasets, public authority learning materials, partner records, sponsor-supported materials, provider materials, community materials, Labs research notes, secure-room outputs, data-room records, proprietary technical documentation, restricted geospatial layers, internal evidence packs, and handoff dependency materials. Controlled evidence shall not be exposed by public reporting unless public-safe release is recorded.
5.2.3 DICE Evidence. DICE evidence may include datasets, metadata records, schemas, codebooks, data dictionaries, lineage notes, data-quality notes, data-use labels, AI-use labels, access conditions, secure-room patterns, compute-to-data workflows, public-safe aggregates, and data stewardship records. DICE evidence shall govern how data appears in Nexus Reports.
5.2.4 GRIx Evidence. GRIx evidence may include ontology mappings, risk categories, WFEH-B taxonomies, DRR/DRF/DRI mappings, indicator definitions, classification notes, controlled vocabulary, semantic interoperability records, and correction history. GRIx evidence shall support consistent language and prevent uncontrolled terminology drift.
5.2.5 DRI Evidence. DRI evidence may include disaster risk intelligence indicators, dashboard outputs, signal summaries, confidence labels, uncertainty labels, public-safe risk summaries, Observatory-linked signal needs, data gaps, correction records, and national DRI contributions. DRI evidence shall not be treated as official warning, rating, insurance score, investment signal, or public authority classification.
5.2.6 Observatory Evidence. Nexus Observatory evidence may include observability methods, node records, sensing needs, Edge observation patterns, geospatial summaries, Earth observation references, digital twin requirements, dashboard patterns, public-safe observability outputs, degraded-mode awareness notes, and correction signals. Observatory evidence shall not create surveillance authority or public warning authority.
5.2.7 Studio Evidence. Nexus Studio evidence may include controlled workflow outputs, simulations, dashboard screenshots or summaries, data-room workflow outputs, secure-room workflow summaries, AI-output review records, public authority learning workflow summaries, readiness-room records, and Nexus Universe demonstration records. Studio evidence shall remain non-decision and non-deployment by default.
5.2.8 Grid and TRL Evidence. Nexus Grid and TRL evidence may include maturity inputs, technical-readiness notes, prototype records, testing records, simulation records, benchmark cards, model cards, system cards, support status, downgrade records, withdrawal records, limitations, and correction history. Grid and TRL evidence shall not become certification, safety approval, procurement readiness, financeability, insurance approval, public authority approval, or deployment authorization.
5.2.9 Foundry Evidence. Nexus Foundry evidence may include task records, quest outputs, bounty submissions, build outputs, public-good software, open technical baselines, technical packs, contribution records, review records, support records, Core Build outputs, Nexus Universe preparation records, correction records, and archive records. Foundry evidence shall show production memory without creating execution authority.
5.2.10 Campaign Evidence. Nexus Campaign evidence may include signatures, pledges, volunteer records, support summaries, Working Group formation records, Competence Cell formation records, Campaign pages, public-safe reports, Academy participation, DICE contributions, DRI contributions, Nexus Universe readiness, and continuation records. Campaign evidence shall not create votes, public mandates, donor commitments, public authority approval, community consent, Indigenous consent where applicable, procurement, finance, or execution.
5.2.11 Academy and Learning Evidence. Academy evidence may include learning pathways, Risk Academy modules, WILP records, micro-credential records, iCRS records, reviewer training, maintainer training, data stewardship training, AI-use training, public-safe communication training, safeguard training, and public authority learning materials. Learning evidence shall not create professional licensure, academic degree, procurement qualification, employment eligibility, or expert certification.
5.2.12 Labs and Research Evidence. Labs evidence may include research calls, frontier research streams, evidence gaps, testbed summaries, methods papers, research-to-Foundry pathways, research-impact notes, public-safe research outputs, and controlled research records. Labs evidence shall not create ethics approval, funding approval, data access rights, or implementation authorization.
5.2.13 Risk Agency Evidence. Risk Agency evidence may include expertise pathway records, advisory demand patterns, training needs, sector capability gaps, public authority learning support needs, DRR/DRF/DRI expertise pathways, and lawful downstream support summaries. Risk Agency evidence shall not certify experts or create client reliance.
5.2.14 Nexus Universe Evidence. Nexus Universe evidence may include arena summaries, Core Build records, public authority learning room summaries, readiness room summaries, Campaign outputs, Academy pathways, Foundry outputs, support records, after-action records, continuation records, correction records, non-continuation records, and archive records. Nexus Universe evidence shall not imply endorsement by attendance or visibility.
5.2.15 Support and Sponsorship Evidence. Support evidence may include donor records, sponsor records, in-kind support, compute support, equipment support, venue support, scholarship support, travel support, bounty support, translation support, accessibility support, support ledgers, restricted support notes, sponsor-boundary notes, and correction records. Support evidence shall not create control, validation, procurement advantage, financeability, or public authority approval.
5.2.16 Handoff Evidence. Handoff evidence may include dependency packages, evidence context, data context, public-safe status, safeguard status, public authority dependencies, legal dependencies, finance and insurance questions, procurement boundaries, provider-neutrality notes, sponsor-boundary notes, recipient responsibility statements, no-reliance statements, correction pathways, recall pathways, and archive status. Handoff evidence shall transfer context, not authority.
5.3 Methods Discipline
5.3.1 Methods Requirement. Every substantive Nexus Report shall include a method note appropriate to its report family and output class. The method note shall identify how evidence was selected, classified, interpreted, transformed, summarized, reviewed, and prepared for publication.
5.3.2 Method Scope. A method note may include source classes, inclusion criteria, exclusion criteria, review period, national pathway context, stakeholder input pathways, data processing steps, public-safe transformation steps, DICE metadata dependencies, GRIx ontology dependencies, DRI indicator logic, Observatory linkage, Studio workflow linkage, Grid or TRL linkage, AI-use where relevant, limitations, and correction pathway.
5.3.3 National Portfolio Methods. National Portfolio Reports shall explain how national records, WFEH-B domains, DRR priorities, DRF questions, DRI indicators, DICE data status, GRIx mappings, Observatory needs, Campaign records, Foundry outputs, Academy pathways, Labs research, Risk Agency pathways, Nexus Universe participation, support records, and handoff candidates were selected and organized.
5.3.4 WFEH-B Methods. WFEH-B methods shall identify how cross-system dependencies were mapped, what data sources were available, what domains were included, what cross-sector interactions were considered, what evidence gaps remain, what public-safe transformations were applied, and what assumptions or limitations apply.
5.3.5 DRR Methods. DRR methods shall identify hazard scope, systems-risk scope, public-safe risk communication approach, community safeguard approach, data sources, indicator logic, public authority boundary, geospatial sensitivity handling, and limitations. DRR methods shall avoid implying operational warning methodology.
5.3.6 DRF Methods. DRF methods shall identify the no-reliance posture, protection-gap framing, risk-layering question approach, assumptions, data sources, public finance relevance boundaries, insurance-readiness boundaries, donor-readiness boundaries, regulated-perimeter controls, and limitations. DRF methods shall avoid transaction or valuation methodology unless separately and lawfully governed.
5.3.7 DRI Methods. DRI methods shall identify indicator definitions, data sources, DICE dependencies, GRIx mappings, Observatory signal logic, dashboard logic, confidence labels, uncertainty labels, public-safe transformation, AI-use where relevant, and correction pathways. DRI methods shall avoid official warning methodology unless separately established by competent public authority outside Nexus Reports.
5.3.8 Data Methods. Data methods shall identify data sources, collection pathways, cleaning steps, quality limitations, lineage, aggregation, redaction, anonymization where applicable, generalization, data-use labels, AI-use labels, access restrictions, and publication conditions.
5.3.9 Technical Methods. Technical methods shall identify architecture assumptions, software dependencies, model assumptions, test conditions, benchmark conditions, simulation context, TRL evidence basis, Grid input basis, security review status, support class, and known limitations.
5.3.10 AI-Assisted Methods. Where AI is used, methods shall state the class of AI assistance, source materials processed, restrictions followed, whether external tools were used, whether human review occurred, how hallucination or unsupported output was controlled, and what AI outputs were excluded or corrected.
5.3.11 Public-Safe Transformation Methods. Where sensitive material is transformed into public-safe output, the method note should describe the transformation class, such as aggregation, redaction, generalization, paraphrase, classification, suppression, metadata-only disclosure, synthetic example, or controlled-source reference. It shall not expose the sensitive source.
5.3.12 Methods Boundary. Methods documentation improves credibility and reuse. It shall not create certification, standards conformance, public authority approval, procurement status, financeability, insurance approval, consent, deployment authorization, or execution.
5.4 Review Levels and Review Labels
5.4.1 Review Label Doctrine. Nexus Reports shall use review labels to make publication status legible. Review labels shall state what kind of review occurred and what kind of review did not occur. Review labels shall help expert readers understand the output’s reliability without converting review into certification.
5.4.2 Draft. Draft shall mean the output is under preparation and not ready for citation, reliance, public distribution, or downstream use except under controlled review conditions.
5.4.3 Internal Review. Internal Review shall mean the output has undergone internal review by relevant Nexus stewards or contributors for structure, completeness, classification, and record alignment. It shall not imply technical validation or public-safe approval unless separately labeled.
5.4.4 Editorial Review. Editorial Review shall mean the output has been reviewed for clarity, structure, consistency, grammar, terminology, public-facing coherence, and standard components. It shall not imply substantive technical validation, legal approval, or public authority review.
5.4.5 Technical Review. Technical Review shall mean the output has been reviewed by appropriate technical contributors for method, data logic, architecture, software, indicators, models, evidence, TRL notes, Grid inputs, or domain accuracy within scope. It shall not imply certification, safety approval, cybersecurity approval, or deployment approval.
5.4.6 Data Steward Review. Data Steward Review shall mean the output has been reviewed for data source status, metadata, data-use labels, access conditions, data availability statement, data limitations, and publication restrictions. It shall not imply data accuracy certification or unrestricted data rights.
5.4.7 AI-Use Review. AI-Use Review shall mean the output has been reviewed for permitted AI processing, AI-use statements, human review, hallucination risk, source verification, restricted-source protection, and public-safe AI output. It shall not imply AI certification or model approval.
5.4.8 Public-Safe Review. Public-Safe Review shall mean the output has been reviewed for public-facing overclaim, public authority confusion, warning confusion, procurement overclaim, finance overclaim, insurance overclaim, certification overclaim, consent overclaim, provider validation, sponsor control, protected knowledge exposure, sensitive geospatial disclosure, panic risk, and execution implication.
5.4.9 Safeguard Review. Safeguard Review shall mean the output has been reviewed for community sensitivity, Indigenous protocol-sensitive matters where applicable, protected knowledge, youth data, humanitarian sensitivity, disability inclusion, accessibility, privacy, dignity, and publication harm. It shall not imply consent, consultation completion, or rights waiver.
5.4.10 National Pathway Review. National Pathway Review shall mean the output has been reviewed for national ownership, national routing, national public authority language, national data rules, national language and localization needs, national stakeholder context, and no-bypass discipline. It shall not imply government approval.
5.4.11 Public Authority Boundary Review. Public Authority Boundary Review shall mean the output has been reviewed to avoid policy adoption overclaim, official approval overclaim, public warning overclaim, procurement overclaim, public finance overclaim, regulatory comfort overclaim, or public authority decision overclaim. It shall not imply public authority approval.
5.4.12 Finance and Insurance Boundary Review. Finance and Insurance Boundary Review shall mean the output has been reviewed for no-reliance, non-advisory, non-soliciting, non-transactional, no-rating, no-valuation, no-underwriting, no-public-finance-allocation, and no-investment-advice posture. It shall not imply financial, insurance, or legal approval.
5.4.13 Procurement Boundary Review. Procurement Boundary Review shall mean the output has been reviewed to avoid supplier approval, preferred provider status, procurement readiness, tender support, product recommendation, purchasing recommendation, or public authority procurement implication. It shall not create procurement clearance.
5.4.14 Repository Metadata Review. Repository Metadata Review shall mean the output has been reviewed for metadata completeness, title, abstract, keywords, authorship, contributor roles, license, related identifiers, DOI readiness, Registry linkage, public-safe abstract, and correction pathway.
5.4.15 Published. Published shall mean the output has been released according to its publication class and access class. Published shall not mean final forever, unrestricted, certified, approved, official, or executable.
5.4.16 Corrected, Superseded, Withdrawn, Retired, Archived, and Non-Continuing. These labels shall state lifecycle status and shall be used to prevent stale or unsafe outputs from being treated as current. They shall preserve record truth without creating legal determinations.
5.4.17 Review Label Boundary. Review labels communicate process. They shall not create endorsement, certification, public authority approval, procurement status, financeability, insurance approval, consent, deployment authorization, operational command, or execution.
5.5 Public-Safe Quality Standards
5.5.1 Public-Safe Quality Doctrine. Nexus Reports shall apply public-safe quality standards to ensure publications are accurate, bounded, non-panicking, non-overclaiming, rights-aware, data-aware, AI-aware, safeguard-aware, public authority-safe, finance-boundary-safe, procurement-neutral, certification-safe, consent-boundary-safe, provider-neutral, sponsor-bounded, and correctionable.
5.5.2 Public Authority Safety. Reports shall not imply public authority approval, policy adoption, regulatory comfort, official classification, public warning, emergency command, procurement action, public finance allocation, license, permit, statutory decision, or government responsibility unless a competent public authority separately and lawfully establishes such status and the report records it accurately.
5.5.3 Warning Safety. Reports involving hazards, disasters, public health, infrastructure, cyber-physical risk, biodiversity, climate, geospatial outputs, DRI indicators, or dashboards shall avoid language that could be interpreted as official warnings, emergency alerts, public safety orders, evacuation guidance, disaster declarations, or operational instructions.
5.5.4 Finance and Insurance Safety. Reports involving DRF, finance-readiness, insurance-readiness, public finance relevance, donor-readiness, capital readability, protection gaps, or handoff shall avoid bankability claims, investment recommendations, underwriting conclusions, ratings, valuations, donor commitments, public finance allocation claims, guarantee claims, solicitation, offers, or transaction language.
5.5.5 Procurement Safety. Reports involving providers, technology, software, equipment, services, platforms, implementation pathways, Studio workflows, Foundry builds, Grid inputs, TRL evidence, or handoff candidates shall avoid supplier approval, preferred vendor, procurement-ready, government-ready, solution recommendation, tender support, or purchasing implication.
5.5.6 Certification Safety. Reports shall not present TRL evidence, Grid inputs, technical review, public-safe review, data review, AI-use review, software release, Academy learning, WILP records, micro-credentials, or Registry status as certification, accreditation, maturity approval, safety approval, cybersecurity approval, privacy compliance approval, AI certification, standards conformance, or expert licensure.
5.5.7 Consent Safety. Reports involving communities, Indigenous protocols where applicable, youth, public-interest stakeholders, data contributions, stories, interviews, workshops, Campaign participation, signatures, or local knowledge shall not imply community consent, Indigenous consent, consultation completion, rights waiver, land access, protected knowledge permission, project authorization, or representation by implication.
5.5.8 Protected Knowledge Safety. Reports shall not expose protected knowledge, sacred knowledge, sensitive cultural knowledge, protected ecological knowledge, protected community information, sensitive field locations, youth identities, or restricted community records. Protected knowledge shall not be transformed into open knowledge by summary.
5.5.9 Geospatial Safety. Reports shall generalize, mask, suppress, restrict, or exclude geospatial details where publication could expose vulnerable communities, protected species, critical infrastructure, cyber-physical systems, public authority assets, field sites, protected knowledge locations, or security-sensitive sites.
5.5.10 Cybersecurity Safety. Reports shall not publish credentials, keys, sensitive logs, exploitable vulnerabilities, attack paths, sensitive network diagrams, critical infrastructure details, or operational security details except through appropriate controlled channels. Public technical reports shall be reviewed for misuse potential.
5.5.11 Provider and Sponsor Safety. Reports shall disclose provider and sponsor roles factually while avoiding validation, endorsement, preferred status, pay-to-influence, public authority overclaim, procurement advantage, or support control.
5.5.12 Public-Safe Quality Boundary. Public-safe quality makes publication responsible. It shall not create legal approval, public authority approval, certification, procurement clearance, finance clearance, insurance approval, consent determination, deployment authorization, or execution authority.
5.6 Expert Credibility Standards
5.6.1 Expert Audience Standard. Nexus Reports shall be written and structured to satisfy expert audiences across risk science, systems science, data science, engineering, public policy, disaster risk management, disaster risk finance, insurance, public health, cybersecurity, geospatial science, environmental science, biodiversity, infrastructure, economics, law, governance, and public-good innovation. Reports shall avoid unsupported grand claims, vague prestige language, unverified assertions, and promotional overstatement.
5.6.2 Method Transparency. Expert credibility shall require transparent methods, source classes, data status, inclusion criteria, limitations, uncertainty, review labels, and correction pathways. A report without method transparency shall not be presented as expert-grade evidence.
5.6.3 Terminology Discipline. Reports shall use controlled vocabulary aligned with Nexus Registry, DICE, GRIx, DRI, Observatory, Grid, TRL, Marketplace, Foundry, Campaigns, Academy, Labs, Risk Agency, Nexus Universe, National Portfolios, and lawful handoff. Terms shall not drift into overclaim, marketing language, or ungoverned technical claims.
5.6.4 Quantitative Integrity. Reports using quantitative information shall identify sources, units, timeframes, geographic scope, uncertainty, missingness, aggregation method, normalization method where applicable, weighting where applicable, limitations, and whether values are measured, estimated, modeled, inferred, or illustrative.
5.6.5 Index and Indicator Integrity. Reports using indicators, indices, scores, maturity levels, readiness references, Grid inputs, or TRL evidence shall explain methodology, limitations, input data, uncertainty, update status, and boundary language. Index-like outputs shall not become ratings, rankings, insurance scores, investment signals, or official classifications by implication.
5.6.6 Qualitative Integrity. Reports using interviews, workshops, stakeholder input, community input, expert input, Campaign submissions, or Working Group materials shall identify participation scope, non-representativeness where applicable, consent boundaries, protected knowledge controls, and limitations. Qualitative input shall not be overstated as national consensus.
5.6.7 Visual Integrity. Reports using maps, charts, diagrams, dashboards, tables, network graphs, maturity diagrams, or portfolio views shall identify data status, scale, uncertainty, generalization, missing data, sensitivity, and interpretation limits. Visual polish shall not imply precision or authority.
5.6.8 Reproducibility Where Safe. Reports shall support reproducibility where safe and lawful through methods, metadata, code, data availability statements, software releases, schema releases, and workflow notes. Where full reproducibility is not possible because sources are controlled, the report shall explain public-safe reproducibility limits.
5.6.9 Conflict Transparency. Reports shall disclose relevant sponsor support, provider involvement, public authority participation, donor support, capital-reader participation, insurer participation, institutional affiliations, data access relationships, infrastructure support, and downstream handoff interests. Conflict disclosure shall preserve trust without creating automatic disqualification or validation.
5.6.10 Peer and Domain Review Pathways. Nexus Reports may use domain review, technical review, public-safe review, data review, safeguard review, or external expert review where appropriate. Review shall be scoped and labeled; it shall not be represented as peer-reviewed journal publication unless the report has undergone such a process.
5.6.11 Avoidance of Scientific Overclaim. Reports shall avoid claiming scientific certainty where evidence does not support it. Reports shall state uncertainty, contested areas, evidence gaps, model limitations, competing interpretations, and unresolved questions where relevant.
5.6.12 Expert Credibility Boundary. Expert-grade writing and review shall increase credibility; it shall not create certification, regulatory approval, public authority approval, procurement approval, financeability, insurance approval, consent, deployment authorization, or execution.
5.7 Review Workflow and Quality Gates
5.7.1 Quality Gate Doctrine. Nexus Reports shall use publication quality gates to ensure outputs are properly classified, evidence-linked, method-aware, metadata-complete, public-safe, rights-cleared, AI-labeled where relevant, repository-ready, Registry-linked, Marketplace-ready where appropriate, correction-ready, and archive-ready before release.
5.7.2 Intake Gate. The Intake Gate shall confirm report family, output class, steward, intended audience, source pathways, expected evidence classes, access class, sensitivity class, repository strategy, DOI need, national pathway relevance, and potential regulated-perimeter concerns.
5.7.3 Evidence Gate. The Evidence Gate shall confirm that evidence classes are identified, source classes are recorded, limitations are visible, sensitive evidence is protected, public-safe transformation is planned, and unsupported claims are removed or reframed.
5.7.4 Methods Gate. The Methods Gate shall confirm that the method note is appropriate for the output class, including source selection, evidence interpretation, data processing, public-safe transformation, AI-use, limitations, and correction pathway.
5.7.5 Data-Use Gate. The Data-Use Gate shall confirm data-use labels, data availability statement, data rights, privacy limits, public authority restrictions, community safeguards, protected knowledge controls, geospatial sensitivity, access conditions, and publication permissions.
5.7.6 AI-Use Gate. The AI-Use Gate shall confirm whether AI was used, whether such use was permitted, whether restricted data was protected, whether human review occurred, whether hallucination controls were applied, and whether an AI-use statement is needed.
5.7.7 Public-Safe Gate. The Public-Safe Gate shall review public authority language, warning language, finance language, procurement language, certification language, consent language, sponsor/provider language, protected knowledge risk, geospatial risk, panic risk, and execution implication.
5.7.8 Safeguard Gate. The Safeguard Gate shall review community sensitivity, Indigenous protocol-sensitive matters where applicable, youth data, disability inclusion, humanitarian sensitivity, privacy, dignity, accessibility, and potential public harm.
5.7.9 Technical Gate. The Technical Gate shall review domain accuracy, method logic, software status, model status, DICE alignment, GRIx alignment, DRI indicator logic, Observatory method claims, Studio output interpretation, Grid inputs, TRL evidence, support class, and technical limitations.
5.7.10 Rights and Licensing Gate. The Rights and Licensing Gate shall confirm ownership, permissions, contributor terms, third-party materials, licenses, attribution, software license compatibility, data license restrictions, provider materials, sponsor-supported materials, and reuse limits.
5.7.11 Metadata and Repository Gate. The Metadata and Repository Gate shall confirm title, abstract, public-safe abstract, keywords, authors, contributors, version, license, related identifiers, DOI readiness, Registry ID, Marketplace ID where applicable, correction pathway, and no-conversion notices.
5.7.12 Publication Gate. The Publication Gate shall confirm final output class, file package, repository destination, Registry record, Marketplace listing where appropriate, public display status, release date, citation format, correction channel, and archive rule.
5.7.13 Post-Publication Gate. The Post-Publication Gate shall monitor metadata errors, public-safe concerns, broken links, corrected versions, repository updates, Registry synchronization, Marketplace synchronization, downstream misuse, and archive needs.
5.7.14 Gate Boundary. Passing a Nexus Reports quality gate shall mean only that an internal publication condition has been met. It shall not create certification, approval, procurement status, financeability, insurance approval, public authority action, consent, deployment authorization, operational command, or execution.
5.8 Uncertainty, Confidence, Limitations, and Responsible Interpretation
5.8.1 Uncertainty Doctrine. Nexus Reports shall treat uncertainty as a core part of responsible publication. Reports shall not hide uncertainty to appear authoritative, nor exaggerate uncertainty to avoid useful public-good knowledge. The level and type of uncertainty shall be stated where relevant.
5.8.2 Confidence Labels. Reports may use confidence labels such as High Confidence, Moderate Confidence, Low Confidence, Insufficient Evidence, Preliminary, Under Review, Data Gap, Method Gap, Public-Safe Summary Only, Controlled Source, or Not Comparable. Labels shall be defined and used consistently.
5.8.3 Evidence Gaps. Evidence gaps shall be clearly identified. A gap may relate to missing data, missing metadata, incomplete coverage, outdated data, insufficient stakeholder input, unresolved rights, restricted public authority records, protected knowledge constraints, model uncertainty, limited observability, or incomplete review.
5.8.4 Comparability Limits. Reports shall state where indicators, national portfolios, WFEH-B patterns, DRR priorities, DRF questions, DRI outputs, Grid inputs, TRL notes, or Campaign records are not comparable across countries, regions, communities, or time periods.
5.8.5 Model and AI Limitations. Reports using models or AI shall state model limitations, training or input constraints where known, source limitations, validation limits, uncertainty, bias risks, hallucination controls, and prohibited uses.
5.8.6 Temporal Limits. Reports shall identify the timeframe of evidence, publication date, version date, update cadence where applicable, refresh status for dashboards, and whether the report is current, superseded, corrected, retired, archived, or under review.
5.8.7 Geographic Limits. Reports shall identify geographic coverage, scale, generalization, missing areas, sensitivity-driven masking, national vs regional vs local limitations, and geospatial restrictions where relevant.
5.8.8 Stakeholder Input Limits. Reports shall state whether stakeholder input is illustrative, representative, expert-sourced, Campaign-sourced, Working Group-sourced, public authority learning-sourced, community-sourced, or otherwise limited. Input shall not be overstated as consensus.
5.8.9 Responsible Interpretation Notes. Reports may include responsible interpretation notes explaining what the report can support, what it cannot support, what readers should not infer, and what actions require competent public authority, legal, technical, finance, insurance, procurement, safeguard, community, or operational review.
5.8.10 Uncertainty Boundary. Uncertainty labels and confidence statements guide interpretation. They shall not create official findings, public authority approval, rating, ranking, financeability, insurance approval, procurement status, consent determination, deployment authorization, or execution.
5.9 Publication Quality Metrics and Credibility Signals
5.9.1 Quality Metrics Doctrine. Nexus Reports may measure publication quality through metrics that support learning, transparency, accountability, and improvement. Metrics shall not become rankings, ratings, certification scores, procurement signals, finance signals, insurance scores, public authority classifications, or institutional prestige contests.
5.9.2 Metadata Completeness Metrics. Metrics may include percentage of reports with complete title, abstract, public-safe abstract, keywords, report family, output class, version, license, Registry ID, DOI where applicable, data availability statement, AI-use statement where applicable, review labels, correction pathway, and archive status.
5.9.3 Review Coverage Metrics. Metrics may include reports reviewed for public-safe status, data-use, AI-use, technical accuracy, safeguards, national pathway, public authority boundary, finance boundary, procurement boundary, accessibility, translation, and repository metadata.
5.9.4 Correction Metrics. Metrics may include number of corrections, correction response time, supersession events, withdrawal events, archive updates, correction propagation to Registry and Marketplace, handoff recalls, and public-safe notices. Correction counts shall not be treated as failure by default; they may indicate healthy correctionability.
5.9.5 Reuse and Discovery Metrics. Metrics may include views, downloads, citations, repository mentions, Marketplace saves, Registry links, Academy uses, Campaign uses, Foundry tasks generated, Labs research calls generated, DICE tasks generated, DRI dashboard updates, GRIx updates, Nexus Universe uses, and handoff context requests. Such metrics shall not imply quality, endorsement, public authority approval, financeability, procurement relevance, or official adoption.
5.9.6 Accessibility Metrics. Metrics may include plain-language summaries, translations, accessible PDFs, alt text, captions, low-bandwidth versions, screen-reader compatibility, disability inclusion review, and accessibility correction.
5.9.7 Open and Controlled Balance Metrics. Metrics may include open reports, public-safe summaries, metadata-only records, controlled evidence packs, secure-room records, data-room records, open datasets, controlled datasets, open software releases, restricted software packages, and protected archive records.
5.9.8 National Portfolio Metrics. Metrics may include National Portfolio Reports published, national updates, WFEH-B coverage, DRR coverage, DRF question maps, DRI indicators, DICE metadata links, GRIx mappings, Observatory needs, Campaign outputs, Academy pathways, Foundry tasks, Nexus Universe linkages, support records, and corrections. National portfolio metrics shall not rank countries.
5.9.9 Credibility Signals. Credibility signals may include method note present, data availability statement present, AI-use statement present, public-safe review complete, safeguard review complete, Registry linked, DOI assigned, version current, correction pathway visible, license clear, and archive status current. Credibility signals shall not be certification marks.
5.9.10 Metrics Boundary. Publication metrics and credibility signals improve governance and usability. They shall not create rankings, ratings, procurement scores, financeability, insurability, public authority approval, certification, social scoring, consent, deployment authorization, or execution authority.
5.10 Correction, Retraction, Withdrawal, and Evidence Integrity Incidents
5.10.1 Evidence Integrity Doctrine. Nexus Reports shall treat evidence integrity as a continuing obligation. A report’s publication date shall not end the duty to correct, supersede, withdraw, recall, or archive where evidence changes, errors emerge, rights fail, public-safe risk appears, or downstream misuse occurs.
5.10.2 Evidence Integrity Incidents. Evidence integrity incidents may include incorrect data, outdated data, unsupported claim, misclassified source, undisclosed limitation, wrong uncertainty label, incorrect DRI indicator, incorrect GRIx mapping, DICE metadata error, Studio output misinterpretation, Grid or TRL overclaim, false Campaign statistic, false support record, public authority overclaim, provider validation, sponsor control implication, finance overclaim, procurement overclaim, consent overclaim, protected knowledge exposure, unsafe geospatial disclosure, or AI hallucination.
5.10.3 Correction. Correction may address factual errors, data errors, method errors, metadata errors, attribution errors, citation errors, public-safe language errors, support statements, provider statements, sponsor statements, public authority language, finance boundary language, procurement boundary language, DRI outputs, DICE metadata, GRIx mappings, Observatory summaries, Studio summaries, Grid/TRL references, or handoff context.
5.10.4 Addendum. An addendum may add new evidence, clarify limitation, add a data availability statement, add AI-use information, add safeguard notes, add public-safe notes, add correction history, or explain downstream implications without replacing the entire report.
5.10.5 Supersession. Supersession shall be used where a new version or replacement output materially updates a prior report, dataset, software release, ontology release, dashboard, evidence pack, National Portfolio Report, or Nexus Universe output.
5.10.6 Withdrawal. Withdrawal shall be used where a report or artefact should no longer be used as current because of source rights failure, data exposure, AI misuse, protected knowledge exposure, public-safe overclaim, public authority overclaim, finance overclaim, procurement overclaim, consent overclaim, security risk, major evidence error, or other material issue.
5.10.7 Retraction. Retraction may be used where the integrity failure is severe, including fabricated evidence, major methodological failure, unlawful disclosure, serious rights violation, protected knowledge exposure, or material public-safe harm. Retraction shall preserve public notice where necessary and shall not be hidden merely to protect reputation.
5.10.8 Recall. Recall may be used where a report, dataset, software release, dashboard, evidence pack, technical note, or handoff context note has been used downstream and affected users or recipients must stop, correct, replace, restrict, or disregard prior use.
5.10.9 Archive After Correction. Corrected, superseded, withdrawn, or retracted reports may remain archived with non-current notices where appropriate for institutional memory, citation transparency, legal preservation, correction traceability, or public-safe accountability.
5.10.10 Evidence Integrity Boundary. Correction, withdrawal, retraction, and recall preserve trust. They shall not create legal liability determination, regulatory finding, public authority finding, procurement decision, finance decision, insurance decision, consent determination, deployment decision, or execution authority.
5.11 Expert Review Networks and Review Independence
5.11.1 Expert Review Network Doctrine. Nexus Reports may maintain expert review networks across risk science, data science, public health, WFEH-B systems, DRR, DRF, DRI, finance-readiness, insurance-readiness, engineering, cybersecurity, AI, geospatial science, biodiversity, climate, public policy, law, governance, public-safe communication, accessibility, and safeguards. Expert review shall improve quality without creating certification.
5.11.2 Reviewer Role Classification. Reviewers may be classified as technical reviewers, domain reviewers, data reviewers, AI-use reviewers, public-safe reviewers, safeguard reviewers, public authority boundary reviewers, finance boundary reviewers, procurement boundary reviewers, national pathway reviewers, accessibility reviewers, translation reviewers, repository metadata reviewers, or archive reviewers.
5.11.3 Reviewer Conflicts. Reviewers shall disclose relevant conflicts involving sponsors, providers, public authorities, donors, insurers, capital readers, public finance readers, universities, employers, communities, National Consortium Companies, Project SPVs, or downstream handoff interests. Conflicts shall be managed through disclosure, recusal, independent review, limited review scope, or correction.
5.11.4 Review Independence. Sponsors, providers, donors, public authority participants, media actors, capital readers, insurers, or downstream actors shall not control review outcomes, public-safe language, correction decisions, withdrawal decisions, or archive treatment.
5.11.5 Review Records. Material reviews may generate review records identifying review type, reviewer class, scope, conflicts, outcome, required corrections, limitations, and archive. Review records may be public, controlled, restricted, or steward-only depending on context.
5.11.6 Anonymous or Restricted Review. Some review records may be anonymized, restricted, or controlled where reviewer safety, public authority sensitivity, protected knowledge, security, or institutional constraints require it. Restricted review shall still preserve internal accountability.
5.11.7 External Review Distinction. Nexus Reports shall not claim peer-reviewed journal status unless an output has undergone an external scholarly peer-review process consistent with that claim. Nexus technical review, public-safe review, domain review, or expert review shall be accurately labeled.
5.11.8 Review Renewal. Reports may require renewal review where data, law, technology, public authority context, finance context, insurance context, national pathway, public-safe status, or evidence basis changes materially.
5.11.9 Reviewer Recognition. Reviewer contributions may be recognized in Registry or iCRS where appropriate and permitted. Reviewer recognition shall not create certification authority, public authority status, expert licensure, employment, procurement qualification, or execution responsibility.
5.11.10 Review Boundary. Expert review improves quality and credibility. It shall not create approval, certification, public authority action, procurement status, financeability, insurance approval, consent, deployment authorization, operational command, or execution.
5.12 Final Operating Statement
5.12.1 Final Evidence Formula. Nexus Reports shall be evidence-bearing, method-aware, source-scoped, limitation-transparent, review-labeled, public-safe, rights-aware, AI-governed, correctionable, and archive-ready. Evidence shall be the foundation of publication; limitation shall be part of truth; correction shall be part of trust.
5.12.2 Final Methods Formula. Every substantive report shall explain how evidence was selected, classified, interpreted, transformed, reviewed, and published. National Portfolio methods shall explain national record construction; WFEH-B methods shall explain systems mapping; DRR methods shall explain public-safe risk reduction framing; DRF methods shall explain no-reliance finance-readiness framing; DRI methods shall explain indicator logic, uncertainty, and public-safe intelligence boundaries.
5.12.3 Final Review Formula. Review labels shall make process visible without becoming certification. Editorial review improves clarity; technical review improves substance; data review improves governance; AI-use review improves safe processing; public-safe review prevents overclaim; safeguard review protects people and knowledge; national pathway review preserves national ownership; boundary review prevents finance, procurement, public authority, consent, and execution drift.
5.12.4 Final Expert Credibility Formula. Nexus Reports shall satisfy expert audiences through methods, metadata, evidence classes, uncertainty, limitations, controlled vocabulary, quantitative integrity, qualitative integrity, visual integrity, reproducibility where safe, conflict disclosure, and correction history. It shall avoid scientific overclaim, rhetorical inflation, sponsor-driven certainty, provider-driven validation, and prestige without evidence.
5.12.5 Final Correction Formula. Corrections, addenda, supersessions, withdrawals, retractions, recalls, and archives shall be first-class credibility mechanisms. Nexus Reports shall correct because it is serious, not because it failed. A publication system that cannot correct cannot be trusted.
5.12.6 Final Declaration. Nexus Reports shall be expert-grade because it treats evidence as architecture, methods as governance, review as process transparency, public safety as publication quality, uncertainty as honesty, correction as legitimacy, and archive as memory. Its reports shall be powerful enough to guide learning, capability formation, national portfolio development, and lawful handoff awareness, yet disciplined enough to prevent evidence from becoming false approval, intelligence from becoming warning, readiness from becoming finance, technology from becoming deployment, participation from becoming consent, and publication from becoming execution.
5. Integration With Nexus Mechanisms, Pillars, Platforms, Records, and Lawful Handoff
6.1 Integration Doctrine
6.1.1 Reports as Integrated Nexus Infrastructure. Nexus Reports shall operate as an integrated Nexus Pillar and shall not function as a disconnected publication archive, standalone report series, external communications channel, or after-the-fact documentation layer. Every material Nexus Report should be designed as a record-linked, mechanism-aware, publication-ready object connected to the relevant Nexus systems that produced, reviewed, routed, published, corrected, and archived it.
6.1.2 Publication as Continuation Rail. Nexus Reports shall transform Nexus work into public-safe knowledge while also creating continuation pathways. A report may close a publication cycle but open a new Campaign, Working Group, Competence Cell, Foundry task, Academy module, Labs research question, Risk Agency expertise pathway, DICE stewardship task, GRIx ontology update, DRI dashboard update, Observatory need, Studio workflow, Grid input, TRL evidence pathway, Nexus Universe arena, National Portfolio update, or lawful handoff dependency package.
6.1.3 Reports as Cross-Pillar Memory. Nexus Reports shall preserve cross-pillar memory by recording how outputs emerged from Nexus Campaigns, Nexus Foundry, Nexus Academy, Nexus Labs, Risk Agency, DICE, GRIx, DRI, Nexus Observatory, Nexus Studio, Nexus Grid, TRL 1–10, Nexus Marketplace, Nexus Registry, Nexus Universe, National Nodes, National Working Groups, Competence Cells, and lawful downstream pathways. Reports shall make the chain of work visible without converting that chain into authority.
6.1.4 Status-Linkage Requirement. Each material Nexus Report should identify its related Registry record, Marketplace listing where applicable, source pathways, output class, evidence class, review status, data-use labels, AI-use labels, public-safe status, license, repository record, DOI or persistent identifier where applicable, correction record, archive status, and downstream routing pathways. Publication without status linkage shall be avoided where status truth matters.
6.1.5 Common Identifier Discipline. Nexus Reports shall use common identifiers, related identifiers, Registry IDs, Marketplace IDs, DOI or persistent IDs, dataset IDs, software release IDs, Studio workflow IDs, Grid input IDs, TRL evidence IDs, Nexus Universe cycle IDs, National Portfolio IDs, Campaign IDs, Working Group IDs, Competence Cell IDs, and handoff package IDs where appropriate. Identifier discipline shall support traceability, correction propagation, and public-safe interpretation.
6.1.6 Integration Without Authority Collapse. Integration shall not collapse roles. Nexus Registry preserves status truth; Nexus Marketplace enables discovery; Nexus Studio runs controlled workflows; Nexus Grid and TRL classify bounded readiness evidence; Nexus Foundry builds; Nexus Campaigns mobilize; Nexus Academy teaches; Nexus Labs researches; Risk Agency routes expertise; DICE governs data; GRIx governs ontology; DRI structures intelligence; Nexus Observatory structures observability; Nexus Universe concentrates annual surge; Nexus Reports publishes; Nexus Rails routes; Nexus Network preserves memory; National Nodes localize; lawful downstream actors execute only through competent legal processes. No integration shall make one function the authority of another by implication.
6.1.7 Reports as Public-Safe Interface. Nexus Reports shall provide the public-safe interface between controlled Nexus work and public knowledge. Where a mechanism produces sensitive records, Nexus Reports may publish summaries, metadata, methods, aggregates, visualizations, or public-safe findings while preserving controlled source records in Registry, DICE, Studio, secure rooms, data rooms, national repositories, protected archives, or other governed environments.
6.1.8 Integration Boundary. Linking, citing, routing, listing, registering, depositing, displaying, or referencing a Nexus Report across Nexus systems shall not create approval, endorsement, certification, procurement status, financeability, insurability, underwriting acceptance, donor commitment, public finance allocation, public authority approval, official classification, public warning, policy adoption, community consent, Indigenous consent where applicable, deployment authorization, operational command, or execution.
6.2 Integration With Nexus Registry
6.2.1 Registry as Status-Truth Layer. Nexus Registry shall be the status-truth layer for Nexus Reports. Each material report should have a Registry record identifying report family, output class, title, steward, authors, contributors, source pathways, version, publication status, DOI or persistent identifier where applicable, access class, public-safe status, data-use labels, AI-use labels, review level, license, related records, correction history, withdrawal status, and archive status.
6.2.2 Registry Record Before Public Reliance. A Nexus Report should not be represented as current, official within the Nexus Reports system, Marketplace-discoverable, Nexus Universe-linked, National Portfolio-linked, or handoff-relevant unless its Registry status or equivalent status-truth record supports that representation. Registry status shall control public meaning where publication records conflict.
6.2.3 Report Record Card. Nexus Registry may generate a Report Record Card showing the report’s family, output class, version, current status, DOI, steward, source pathway, public-safe status, evidence class, review label, license, data-use status, AI-use status, correction history, archive status, and no-conversion notices. The Report Record Card shall make status legible without certifying the report.
6.2.4 Contributor and Portfolio Linkage. Nexus Registry may link reports to stakeholder portfolios, organizational profiles, iCRS contribution records, WILP records, micro-credential records, reviewer records, maintainer records, sponsor records, provider records, support records, and Nexus Universe participation records. Portfolio linkage shall recognize contribution and participation without creating employment, professional certification, procurement qualification, expert standing, endorsement, or authority to represent Nexus.
6.2.5 Registry-Linked Corrections. Corrections, addenda, supersessions, withdrawals, recalls, and archive actions affecting Nexus Reports shall update Registry records. Registry shall preserve prior status where needed and identify current status, corrected versions, successor records, and affected downstream pathways.
6.2.6 Registry Access Classes. Registry records for Nexus Reports may include public fields, controlled fields, restricted fields, steward-only fields, secure-room fields, data-room fields, public-authority-learning-only fields, handoff-recipient-only fields, sealed fields, and archive-only fields. Public repository records shall not expose controlled Registry fields.
6.2.7 Registry-Repository Synchronization. Where Nexus Reports are deposited through Zenodo or similar repositories, Registry records should reference repository identifiers, DOI, version, license, publication date, related files, and correction status. Where repository metadata changes, Registry should be updated. Where Registry status changes, repository records should be updated where appropriate.
6.2.8 Registry Boundary. Registry linkage shall preserve status truth. It shall not make the report approved, certified, official, public-authority-endorsed, procurement-ready, financeable, insurable, consented, deployable, or executable.
6.3 Integration With Nexus Marketplace
6.3.1 Marketplace as Discovery Layer. Nexus Marketplace may list Nexus Reports for discovery, support, reuse within rights, learning, translation, accessibility, Campaign activation, Academy routing, Foundry task creation, Labs research routing, Risk Agency pathway identification, Nexus Universe preparation, and lawful handoff awareness. Marketplace discovery shall not create approval or endorsement.
6.3.2 Report Listing Requirements. A Marketplace listing for a Nexus Report should identify report title, report family, output class, version, DOI or persistent identifier where applicable, Registry status, public-safe status, license, data-use labels, AI-use labels, review level, access class, support status where applicable, related Nexus systems, correction status, archive status, and no-conversion notices.