> For the complete documentation index, see [llms.txt](https://docs.therisk.global/organization/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.therisk.global/organization/standardization/nexus-ecosystem/iii.-infrastructure/operations/nexus-ecosystem-data-protocols.md). # Nexus Ecosystem Data Protocols Data Protocols in the Nexus Ecosystem govern how data becomes trusted, interoperable, simulation-ready, public-safe, and correctionable evidence across sovereign systems. **Where this fits:** all six sectors · all six pillars · [the twenty systems](/organization/systems.md) · [the Nexus Consortium](/organization/institutions/nexus-consortium.md) · doctrine and architecture. **In brief.** Nexus Ecosystem data protocols provide the evidence architecture for trusted coordination across sovereign, institutional, and community systems. This page belongs to the Nexus Ecosystem, a [Nexus Standards](/organization/institutions/nexus-standards.md) design in progress whose governing texts are published on [nexustandards.com](https://nexustandards.com/standards/) ([OECD, 2014](https://legalinstruments.oecd.org/en/instruments/OECD-LEGAL-0405); [UN Office of the Secretary-General's Envoy on Technology, 2024](https://www.dpi-safeguards.org/)). A design described here is not a deployed system, a certification or an approval; the competent authority decides, outside the programme. {% hint style="info" %} **Read with the current model.** The Nexus Ecosystem is defined once, on [the Nexus Ecosystem page](/organization/standardization/nexus-ecosystem.md): the governed public-good architecture that connects institutions, technologies, standards, evidence and lawful implementation pathways across the twenty systems. Technology here is described as [the twenty systems](/organization/systems.md) by NXS code; technology readiness uses the nine levels of ISO 16290, never ten. Finance vehicles are structures competent, lawful actors may form outside the programme ([Lawful handoffs](/organization/finance-readiness/lawful-handoffs.md)). Everything is in formation (service level R0). {% endhint %} Nexus Ecosystem data protocols provide the evidence architecture for trusted coordination across sovereign, institutional, and community systems. They define how data becomes governed, interoperable, simulation-ready, and public-safe without collapsing jurisdiction, rights, or contextual meaning. This page explains how the Nexus Ecosystem structures provenance, semantics, access, correction, and verifiable state so distributed information can support risk intelligence, accountability, and operational decision-making at scale. ### Data as the Evidence Constitution of the Nexus Ecosystem Data Protocols define the evidence constitution of the Nexus Ecosystem. They establish how information enters, moves through, becomes trusted by, remains governable within, and can be corrected across a public-good architecture built for systemic risk intelligence, clause-aware governance, simulation, digital twins, sovereign data coordination, public-safe reporting, finance-readiness, insurance-readiness, Project SPV evidence rooms, National and Regional Nexus Consortium operations, [Nexus Universe](/organization/programme/universe.md) build cycles, [Risk Academy](/organization/programme/academy.md) learning environments, [NXS-NET](/organization/systems/nxs-net.md) (network topology and continuity) Network maturity records, [NXS-RLS](/organization/systems/nxs-rls.md) (participants, agreements and handoffs) readiness pathways, and lawful decision support by competent actors. This layer is foundational because Nexus is not an ordinary data environment. It is not a data lake, a dashboard platform, a document repository, a proprietary intelligence stack, a data marketplace, a centralized cloud system, or a single-source analytics product. Nexus is an ecosystem architecture for converting distributed information into governed evidence. That evidence may then support simulation, foresight, public-safe communication, institutional learning, finance-readiness, insurance-readiness, project readiness, standards development, and lawful decisions by actors that already hold the relevant authority. In the Nexus architecture, data is never passive. It can influence a NexusClause, a Clause Stack, a Digital Clause Passport, a simulation run, a digital twin state, a Nexus Observatory signal, a Nexus Network maturity state, a NXS-RLS finance-readiness pathway, an insurance-readiness review, a public-safe report, a Project SPV evidence room, a National Consortium data room, a Nexus Universe live operating cycle, or an Academy training dataset. Because data can shape interpretation, readiness, public trust, institutional coordination, capital readability, project review, and public-safe communication, it must be governed before it becomes influential. The source foundation for this section correctly frames Data Protocols as the operational substrate through which raw signals become evidence objects, evidence objects become simulation inputs, simulation inputs become foresight records, and foresight records support lawful decisions by competent actors. It also identifies multimodal ingestion, cross-domain integration, semantic normalization, sovereign data sharing, provenance anchoring, metadata registries, multilingual intake, citizen science, high-performance preprocessing, public-safe handling, correction, and integration with Nexus Observatory, Digital Twins, Clause AI, Clause Commons, NXS-RLS, Nexus Network, Project SPVs, GCRI, GRF, and [The Global Risks Alliance](/organization/institutions/gra.md) as essential elements of the data layer. The mature Nexus doctrine is more demanding: **data is not evidence until it is governed as evidence**. A satellite image does not automatically prove flood extent. A sensor reading does not automatically satisfy a trigger. A public finance report does not automatically support capital-readiness analysis. A citizen video does not automatically become public-safe evidence. An AI log does not automatically establish governance compliance. A digital twin output does not automatically support public communication. A finance-readiness record does not automatically become finance. Each data object must be linked to source, method, time, jurisdiction, quality, rights, sensitivity, permitted use, uncertainty, lineage, and correction state before it can support a Nexus workflow. This distinction is the first law of the Nexus data architecture. Ordinary data systems often treat data as material to collect, store, clean, query, and visualize. Nexus treats data as a governed object that may carry public-good consequence. A dashboard may influence public perception. A simulation may shape readiness planning. A clause-linked record may affect review. A finance-readiness package may influence diligence. A public-safe summary may shape institutional trust. A Project SPV record may influence asset review. A Grid maturity state may influence ecosystem routing. If the underlying data is not source-aware, schema-aware, jurisdiction-aware, rights-aware, quality-aware, clause-aware, simulation-aware, public-safe, and correction-ready, downstream intelligence becomes fragile. Data Protocols therefore serve as the operational substrate of Nexus because they determine what may enter the system, how it may be interpreted, where it may travel, who may access it, what it may support, what it must not imply, and how it can be corrected. They are not merely technical standards. They are operating doctrine for evidence formation. The governing principle is strict: **No data should influence clause interpretation, simulation, public-safe reporting, finance-readiness, insurance-readiness, Grid maturity, Project SPV readiness, National Consortium workflows, public authority support, or public-good claims unless its source, meaning, jurisdiction, rights, quality, sensitivity, lineage, permitted use, and correction pathway are sufficiently known for that purpose.** This principle turns data governance into epistemic accountability. Nexus must know what it knows, where it knows it from, when it knew it, who provided it, what it means, what it can support, what it cannot support, what uncertainty remains, and how errors can be corrected. That is the role of Data Protocols: to make distributed information usable without making it uncontrolled, public without making it unsafe, finance-readable without making it financial advice, simulation-ready without making it authoritative, AI-usable without making it unreviewable, and interoperable without making it extractive. ### Public-Good Positioning Nexus Data Protocols position the Nexus Ecosystem as public-good evidence infrastructure, not as a centralized data platform. This distinction must remain visible across every technical, institutional, financial, and public-facing expression of the architecture. A centralized data platform seeks to collect and manage data inside a single environment. A data marketplace seeks to exchange data as an asset. A data lake seeks to store large quantities of data for downstream use. An analytics platform seeks to produce insights. An intelligence platform may seek to generate operational assessments. Nexus Data Protocols do something different. They define how distributed information becomes governed evidence across multiple systems, institutions, jurisdictions, communities, technical environments, and authority contexts. Nexus does not need to own, centralize, or extract the world’s data in order to make evidence interoperable. Public authorities may retain official records in statutory systems. States may retain sovereign data in national environments. Communities may retain protected knowledge in community-controlled archives. Insurers may retain exposure records under confidentiality. Financial institutions may retain portfolio, credit, liquidity, claims, and risk data under regulated controls. Project SPVs may retain operational evidence in controlled rooms. Scientific institutions may publish data through research repositories. Enterprises may maintain telemetry in secure systems. Public datasets may remain open. Decentralized storage networks may host public-safe evidence packages. Permissioned ledgers may record institutional attestations. Public blockchains may anchor proof receipts. Secure enclaves may process restricted records. National digital public infrastructure may remain authoritative for identity, land, public finance, health, business registration, procurement, legal publication, and public service records. Nexus Data Protocols are designed to work across all of these environments without collapsing them into a single platform. They create a common evidence model, not a compulsory data repository. This public-good posture mirrors the corrected Nexus approach to blockchain and DLT interoperability. Nexus is not positioned as a new universal blockchain layer. It is positioned as a protocol-agnostic verifiable governance architecture that can work with compatible ledgers, registries, credentials, oracles, storage systems, secure compute environments, and institutional records. Data Protocols follow the same logic. Nexus is not positioned as a universal data lake. It is positioned as a protocol-agnostic evidence architecture that can work with many data systems while preserving the authority, rights, sensitivity, and context of the original source. This positioning is institutionally essential. Governments, public authorities, utilities, banks, insurers, universities, community bodies, civil society organizations, and enterprise operators cannot simply surrender all records to a single external platform. They operate under law, contract, fiduciary duty, confidentiality, privacy rules, national data policy, professional obligations, security classifications, public records duties, financial regulation, insurance regulation, Indigenous data governance, and community consent. A credible Nexus architecture must respect those constraints. It must support data-in-place, compute-to-data, verifiable assertions, controlled-room analysis, public-safe summaries, sovereign data zones, community consent, role-based access, public authority context, and correction pathways. The public-good promise of Nexus Data Protocols is therefore not “give Nexus your data.” It is: **Keep data under appropriate stewardship; make selected evidence states interoperable, verifiable, simulation-ready, public-safe, finance-readable, insurance-readable, maturity-aware, and correctionable under Nexus protocols.** This matters for legitimacy. A public-good infrastructure that extracts data without respecting control becomes another centralized platform. A system that publishes risk intelligence without public-safe discipline becomes unsafe. A system that turns finance-readiness evidence into implied financing becomes legally and ethically dangerous. A system that treats community knowledge as open data becomes extractive. A system that treats AI-generated summaries as evidence without source lineage becomes epistemically weak. A system that turns simulations into authority becomes false governance. A system that treats Grid visibility as maturity or recognition as certification creates unreliable public claims. Nexus Data Protocols prevent these failures by embedding public-good boundaries into the data layer. They require role separation, source context, jurisdictional scope, access control, public-safe disclosure, controlled publication, traceable provenance, and correction. They allow Nexus to support states, communities, institutions, capital actors, insurers, researchers, providers, and project vehicles without pretending to replace them. Public-good legitimacy depends on four forms of discipline. The first is **epistemic legitimacy**: Nexus outputs must be traceable to sources, methods, assumptions, evidence quality, uncertainty, and corrections. A claim that cannot be traced should not be presented as a mature Nexus claim. The second is **sovereign legitimacy**: data must remain under national, institutional, community, or contractual control where required. Interoperability must not become extraction. The third is **public legitimacy**: public-safe outputs must inform without exposing sensitive records, overclaiming certainty, implying public authority, or creating false confidence. The fourth is **institutional legitimacy**: evidence, recognition, finance-readiness, insurance-readiness, public authority, project execution, and professional decision-making must remain distinct. This is why Data Protocols are not support documentation. They are the public-good data doctrine of the Nexus Ecosystem. ### The Problem Space: Data Abundance Without Evidence Integrity The global risk landscape is saturated with data but starved of trusted, contextual, interoperable, rights-aware, decision-relevant evidence. The problem is not that governments, communities, enterprises, insurers, scientists, civil society, or public institutions lack information. The problem is that information is fragmented across incompatible systems, weakly contextualized, unevenly validated, legally constrained, semantically inconsistent, and often disconnected from the clauses, simulations, decisions, and readiness pathways that need it. Earth observation systems may detect flooding, drought, wildfire, land-use change, urban expansion, glacier retreat, vegetation stress, heat islands, biodiversity loss, or coastal erosion, but the data may not be connected to the jurisdictional boundary, public authority context, asset exposure, finance-readiness covenant, disaster risk finance clause, infrastructure service area, or community safeguard that makes it operationally meaningful. A river gauge may report water level, but unless it is calibrated, timestamped, basin-linked, source-verified, quality-flagged, and matched to the correct trigger window, it may be unsuitable for clause review. A public finance report may show reserve capacity, but unless it is mapped to entity, period, currency, accounting basis, audit status, public authority role, covenant language, and confidentiality status, it may be weak as capital-readable evidence. A public health dashboard may show capacity, but unless privacy, aggregation, reporting delay, jurisdictional scope, and lawful reuse constraints are attached, the data may be unsafe or unlawful to reuse. A community report may detect infrastructure failure before any official channel, but unless contributor protection, geolocation, consent, validation, community governance, and public-safe rules are applied, the evidence may either be dismissed or misused. An AI audit log may contain critical evidence, but unless model version, deployment context, personal data risk, prompt/output lineage, tool-use trace, vendor update status, and access control are preserved, it may not support governance review. A digital twin may display a compelling future state, but unless its inputs, transformations, uncertainty, model assumptions, calibration, and source dependencies are visible, it can become persuasive without being reviewable. This is the core problem: **data can become influential before it becomes trustworthy**. Conventional data architectures often intensify this problem. They ingest first and govern later. They prioritize volume, velocity, and analytics before evidence fitness. They store large quantities of data without preserving sufficient context. They produce dashboards that hide uncertainty. They train models on datasets with incomplete provenance. They merge sources that were never meant to be used together. They publish maps without public-safe review. They present modeled outputs without distinguishing them from observations. They treat public data as safe data. They treat official data as sufficient data. They treat structured data as reliable data. They treat AI-normalized data as clean data. They treat integrated data as interoperable evidence. In high-consequence environments, each assumption can fail. The Nexus Ecosystem cannot adopt that model. Nexus must support climate adaptation, disaster risk finance, AI governance, sovereign compute, public health preparedness, critical infrastructure resilience, cyber risk, energy security, water systems, food systems, biodiversity, logistics, telecom and AI-RAN corridors, public finance, insurance-readiness, capital-readiness, Project SPVs, community safeguards, and multi-jurisdictional coordination. In these domains, a data error is not merely a technical defect. It can distort risk models, misdirect readiness planning, weaken a public-safe report, undermine trust, expose vulnerable populations, corrupt a digital twin, misroute finance-readiness analysis, compromise security, or create false confidence. Data Protocols solve this by changing the order of operations. Governance context is not attached after analysis. It is attached at origin. Every major data object must carry source identity, collection context, temporal scope, spatial scope, jurisdictional scope, rights status, consent state, sensitivity class, evidence quality, schema mapping, ontology mapping, access conditions, permitted-use constraints, and correction pathway before it can influence downstream systems. This turns the Nexus data layer into a sovereign evidence infrastructure. It does not eliminate uncertainty, but it makes uncertainty visible. It does not guarantee truth, but it makes claims traceable. It does not replace competent actors, but it gives them better records. It does not centralize authority, but it allows distributed evidence to interoperate. ### Core Technical Thesis The core technical thesis of Nexus Data Protocols is that data for systemic risk governance must be **multimodal, semantically normalized, jurisdictionally scoped, rights-aware, cryptographically and institutionally traceable, privacy-preserving, simulation-ready, clause-aware, public-safe, and correctionable from the moment it enters the ecosystem**. Multimodal design is necessary because systemic risk is observed through many forms of data. Flood risk may require rainfall, radar imagery, river gauges, terrain, land use, road networks, bridge condition, hospital capacity, household exposure, public authority declarations, community reports, insurance exposure, and public finance reserves. AI governance may require model inventories, prompt logs, output logs, tool-use records, RAG source records, evaluation datasets, red-team results, vendor updates, human oversight logs, incident reports, and complaint records. Infrastructure resilience may require asset condition, maintenance logs, sensor telemetry, service continuity data, cyber signals, capital expenditure, insurance conditions, public authority dependencies, and digital twin outputs. No single modality can support Nexus foresight. Semantic normalization is necessary because data without meaning is not evidence. A field labeled “loss,” “trigger,” “approval,” “event,” “validated,” “resilient,” “critical,” “public,” “exposure,” “incident,” “compliance,” or “readiness” may mean different things in law, engineering, finance, insurance, ecology, public health, cybersecurity, AI governance, and community contexts. Nexus must map terms to controlled vocabularies, ontologies, risk categories, clause concepts, evidence classes, jurisdictions, standards, and simulation variables without flattening domain meaning. Jurisdictional scoping is necessary because data is never legally context-free. The same record may be usable in one jurisdiction and restricted in another. It may be lawful for internal review but not publication. It may support research but not operational use. It may be usable in aggregate but not at individual level. It may be controlled by national law, privacy law, public records law, Indigenous data governance, data localization requirements, contract, confidentiality, security restrictions, financial regulation, health regulation, or community consent. Nexus Data Protocols must encode jurisdiction and permitted use as first-order metadata. Traceability is necessary because high-consequence intelligence must be reconstructable. A simulation output must be traceable to its inputs, model version, parameters, assumptions, compute environment, and transformations. A public-safe report must be traceable to the evidence it summarizes. A finance-readiness package must distinguish audited, modeled, self-reported, public-safe, restricted, and third-party evidence. A Project SPV evidence room must preserve provider records, asset records, service-level evidence, safeguards, public authority references, and correction history. A clause-linked data object must show which clause version it supports and under what evidentiary limits. Privacy preservation is necessary because risk data often concerns people, households, public services, health, finance, infrastructure, cyber posture, protected communities, Indigenous knowledge, national systems, enterprise operations, or public authority deliberations. More disclosure does not automatically create more trust. Correct disclosure creates trust. Nexus must support data minimization, selective disclosure, aggregation, redaction, pseudonymization, differential privacy where appropriate, secure enclaves, federated analytics, zero-knowledge proofs, compute-to-data, controlled-room review, and community-governed access. Simulation readiness is necessary because Nexus is not only an information repository. It is a foresight ecosystem. Data must become temporally aligned, spatially coherent, unit-normalized, uncertainty-aware, model-compatible, and reproducible. It must preserve transformation logs and access constraints so simulations can be reviewed, rerun, corrected, or challenged. Clause awareness is necessary because data may affect NexusClause, Clause Stacks, Digital Clause Passports, public authority references, evidence requirements, trigger logic, public-safe reporting obligations, finance-readiness covenants, insurance-readiness conditions, project obligations, AI governance duties, safeguards, and correction pathways. Data must be evaluated against clause-specific evidentiary requirements, not merely general quality. Public-safe design is necessary because Nexus outputs may be visible to governments, communities, funders, investors, insurers, media, civil society, researchers, providers, and the public. Public-safe publication must distinguish observed data from modeled data, scenario from prediction, early warning support from official warning, finance-readiness from finance, insurance-readiness from underwriting, recognition from certification, maturity from approval, and evidence from legal determination. Correctionability is necessary because evidence systems must be able to repair themselves. A sensor can fail. A translation can be wrong. An OCR extraction can misread a table. A data vendor can revise a file. A public authority record can be superseded. A community can revoke consent. A model can be updated. A public-safe report can overstate certainty. Data Protocols must support challenge, correction, supersession, withdrawal, tombstones, simulation reruns, dependency notification, and public correction notices. Together, these technical principles make Data Protocols the operating discipline that allows Nexus to convert fragmented information into governed intelligence. ### Data as Evidence, Not Raw Input The distinction between data and evidence is the first operational rule of Nexus Data Protocols. Data is a record, signal, observation, file, feed, document, output, measurement, testimony, model result, or claim. Evidence is data whose provenance, context, quality, relevance, rights, permitted use, and lineage are sufficiently known for a defined purpose. This distinction prevents overclaim. A satellite image may be a valid image but weak evidence for a flood clause if cloud cover obscures water extent. A sensor reading may be technically accurate but weak evidence if calibration is unknown. A public authority report may be official but unsuitable for a high-resolution simulation. A citizen report may be unverified but strong enough to trigger human review. An AI-generated classification may help triage but not support publication. A financial projection may support scenario analysis but not finance-readiness. A digital twin output may support planning but not public communication. Evidence fitness depends on use. Nexus therefore does not ask whether data is “good” in the abstract. It asks whether it is fit for a particular Nexus purpose. Is it fit for storage? Fit for internal review? Fit for simulation? Fit for clause evaluation? Fit for public-safe summary? Fit for finance-readiness? Fit for insurance-readiness? Fit for Grid maturity? Fit for Project SPV diligence? Fit for Academy training? Fit for archival memory? Fit for correction? Each use requires a different evidence threshold. Raw data may be useful for exploratory analysis. Source-verified data may support Observatory review. Schema-valid data may support data integration. Semantically mapped data may support cross-domain reasoning. Jurisdictionally scoped data may support clause routing. Quality-reviewed data may support simulation. Public-safe data may support publication. Finance-readiness-supporting data may support controlled diligence translation. Insurance-readiness-supporting data may support controlled insurance review. High-assurance controlled-use evidence may support sensitive institutional review. Evidence status must therefore be layered. Nexus should not collapse all data into one binary distinction between verified and unverified. The ecosystem needs a maturity path that reflects source quality, schema integrity, semantic mapping, jurisdiction, uncertainty, rights, public-safe status, and downstream use. This evidence discipline is especially important for AI. AI systems can make unstructured material appear structured, summarize uncertain material with confident language, normalize documents in ways that hide ambiguity, generate synthetic evidence that appears realistic, and route outputs at a speed that can exceed human review. Nexus Data Protocols require AI-assisted outputs to preserve source, confidence, model version, reviewer state, transformation history, and limitation. AI can assist evidence formation. It cannot substitute for evidence governance. ### Validity-by-Record Validity in Nexus is record-bound. A claim is not valid because it appears in a dashboard, model, report, dataset, map, knowledge base, AI output, or data room. It is valid only to the extent supported by the record that defines its source, method, time, scope, rights, quality, uncertainty, use, and correction state. This doctrine is critical because Nexus operates across domains with different standards of proof. Scientific validity, legal validity, financial reliability, insurance relevance, public-safe suitability, community legitimacy, simulation compatibility, and operational readiness are related but not identical. A record may be scientifically strong but legally restricted. It may be legally official but scientifically insufficient. It may be useful for community situational awareness but unsuitable for public reporting. It may be capital-readable but not investment-ready. It may be mature for internal simulation but not public disclosure. Validity-by-record avoids false generalization. It requires every material evidence claim to be linked to its record. If a report states that a region has flood exposure, the record should identify the data source, model, date, resolution, uncertainty, jurisdiction, and public-safe boundary. If a finance-readiness pack includes resilience metrics, the record should distinguish observed performance from modeled avoided loss. If a Grid node is marked mature, the record should identify the evidence supporting that maturity state. If a public-safe summary is corrected, the record should preserve the prior version and correction reason. If an AI governance record states that oversight is active, it should identify the logs, model inventory, human review records, and limitations supporting that statement. This doctrine also supports audit and dispute resolution. If a claim is challenged, the question is not whether the platform generally believes it. The question is which record supports it, what that record says, whether the record was valid for the purpose, whether the underlying evidence has been corrected, and whether downstream outputs must be updated. Validity-by-record is the antidote to platform authority. Nexus does not ask users to trust the platform. It gives them record-bound evidence. ### Correctionability as Operating Doctrine Correctionability is not a failure state. It is a design requirement. Any serious evidence infrastructure must assume that data can be incomplete, wrong, outdated, mistranslated, misclassified, misused, superseded, or lawfully withdrawn. Nexus Data Protocols require correction pathways for every material evidence object. Correction may arise from source revision, sensor error, metadata error, jurisdictional mismatch, OCR mistake, translation error, public-safe overdisclosure, consent revocation, community objection, legal update, model update, financial restatement, provider correction, cyber incident review, or new evidence. A mature system must not hide these changes. It must record them. Correction does not mean silently overwriting history. It means appending a correction record, marking the prior state, identifying affected downstream dependencies, and notifying relevant workflows. A corrected rainfall dataset may affect a disaster finance simulation. A revised public authority notice may affect a Digital Clause Passport. A revoked credential may affect access records. A withdrawn community consent record may affect a public-safe summary. A corrected maintenance log may affect Project SPV readiness. A revised digital twin input may require simulation rerun. A corrected public-safe report may require a public correction notice. A revised AI model inventory may affect governance readiness records. Correctionability protects trust because it makes repair visible. Systems that pretend they are never wrong become brittle. Systems that silently change records become untrustworthy. Nexus must preserve both memory and correction. The correction doctrine includes challenge intake, review, decision, supersession, withdrawal, tombstone, simulation rerun, dependency notification, public correction notice, and archive. Correction records should identify who corrected the record, under what role, why correction occurred, what changed, what downstream records are affected, and what use is now permitted or prohibited. This is why Data Protocols are inseparable from the broader Nexus doctrines of correctionability, validity-by-record, non-execution, and public-safe governance. ### One Rail, Two Stacks Applied to Data The Nexus Ecosystem operates through One Rail, Two Stacks: a public-good governance stack and a licensed or enterprise delivery stack. Data Protocols must preserve the separation between them. In the public-good stack, data functions include evidence methods, observability, ontology, public-safe reporting, registry records, maturity states, claims discipline, standards, conformance profiles, finance-readiness translation, insurance-readiness translation, and public-good learning. GCRI supports evidence methods, technical architecture, data quality, simulation, ontology, AI/NLP methods, and observability. GRF supports public-safe reporting, registry, recognition, maturity records, claims discipline, correction pathways, and legitimacy. The Global Risks Alliance supports finance-readiness, capital readability, insurance-readiness, and diligence translation within its proper non-executing boundary. Nexus Standards and related protocol functions support schema, conformance, proof receipts, SDKs, and reference implementations. In the licensed and enterprise delivery stack, data functions include implementation records, asset data, service-level evidence, commercial data rooms, Project SPV evidence rooms, provider logs, maintenance records, enterprise telemetry, investor-facing controlled materials, insurance-facing controlled materials, and operational performance records. These may support actual project delivery, capital raising, insurance placement, service operations, procurement, or regulated activity only through lawful and authorized actors. Data Protocols define the handoff between stacks. Public-good evidence may support readiness, standards, public-safe reports, maturity records, or finance-readiness translation. Enterprise records may support Project SPV diligence, service delivery, asset performance, and controlled review. But public-good records must not become implied procurement approval. Enterprise participation must not become public-good endorsement. Finance-readiness must not become finance. Insurance-readiness must not become underwriting. Grid visibility must not become certification. Public-safe reporting must not become public authority warning. Standards alignment must not become regulatory approval. Project SPV evidence must not become public-good recognition unless separately reviewed within the appropriate record process. This separation must be encoded in metadata, access rules, publication language, evidence passports, and data-room permissions. A dataset should carry its stack context and permitted use. A Project SPV evidence room may contain records not suitable for public disclosure. A Nexus Observatory public-safe output may communicate risk without endorsing a provider. A NXS-RLS data pack may support capital readability without offering investment advice. A GRF registry record may recognize participation or maturity state without certifying performance. A GCRI method record may support technical validity without authorizing deployment. One Rail, Two Stacks is therefore not only institutional doctrine. It is a data governance rule. ### Relationship to Verifiable State, Blockchain, and DLT Interoperability Data Protocols and the Verifiable State Interoperability Layer are complementary but distinct. Data Protocols define what the data means, how it may be used, what quality it has, what rights attach, what jurisdiction applies, what public-safe boundaries exist, and how it can be corrected. The Verifiable State Interoperability Layer records material state changes across ledgers, registries, credentials, storage systems, proof systems, secure compute environments, and institutional records. Blockchain and DLT tools can anchor hashes, record proof receipts, verify credentials, index snapshots, preserve timestamps, or support auditability. They cannot define evidence quality by themselves. A ledger can preserve a bad record as permanently as a good one. A hash can prove that a file did not change, but not that the file was accurate, lawful, current, public-safe, or fit for clause use. A zero-knowledge proof can verify a statement, but not whether the statement was the right one for a public authority workflow. A smart contract can check a credential, but not replace legal authority. Data Protocols therefore come first. They determine whether a data object can become evidence. The state layer records the state of that evidence. When data is ingested, a proof receipt may be anchored. When data is transformed, a transformation proof may be recorded. When data enters simulation, a simulation lineage record may be created. When a public-safe summary is published, a publication state may be recorded. When correction occurs, a correction state may be logged and linked to downstream dependencies. The two layers solve different failures. Data Protocols prevent weak, unsafe, or unauthorized data from becoming influential. Verifiable state prevents governed evidence from becoming opaque or untraceable. Together, they allow Nexus to operate across many data systems, many ledgers, many registries, many storage environments, many institutions, many communities, and many jurisdictions without centralizing control. ### Controlled Vocabulary for Data Protocols A public-ready Nexus Data Protocols doctrine requires controlled language. The vocabulary must preserve legal boundaries and technical precision. **Data** means a raw or processed record, signal, file, feed, document, output, observation, measurement, testimony, model result, or claim. **Evidence Object** means data represented with sufficient provenance, metadata, rights, quality, access, jurisdiction, permitted-use context, and correction pathway for a defined Nexus purpose. **Digital Evidence Passport** means the portable record of an Evidence Object’s source, quality, rights, jurisdiction, lineage, proof receipts, permitted use, public-safe status, and correction history. **Proof Receipt** means a record that a defined evidence event occurred, such as ingest, validation, transformation, simulation use, publication, correction, or access. It is not a warranty, certification, regulatory approval, or legal determination. **Public-Safe Evidence Summary** means a bounded output that can be shared publicly without exposing sensitive data or overclaiming authority. **Simulation-Ready Payload** means an Evidence Object prepared for model use with temporal alignment, spatial alignment, schema conformance, uncertainty, source lineage, access class, and transformation history. **Finance-Readiness Data Pack** means structured evidence that supports capital readability or diligence translation. It is not investment advice, financing approval, credit approval, securities disclosure, or guarantee of financeability unless separately prepared and authorized by competent actors under applicable law. **Insurance-Readiness Data Pack** means structured evidence that supports insurance readability or risk-transfer review. It is not underwriting, insurance placement, insurability determination, policy approval, or risk-transfer execution. **Grid Maturity Evidence** means evidence supporting a maturity or readiness state in Nexus Network. It is not certification unless a separate authorized conformance process exists. **Citizen Evidence Record** means a protected record derived from community or individual participation, subject to validation, consent, public-safe controls, and contributor protection. **Sovereign Data Zone** means a controlled environment where data remains under national or authorized jurisdictional control. **Data-in-Place** means data remains in its source system while Nexus interacts through references, proofs, controlled queries, attestations, or governed outputs. **Compute-to-Data** means approved computation moves to the data environment rather than raw data moving to a central platform. **Correction Record** means the record of challenge, correction, supersession, withdrawal, tombstone, or dependency impact. **Public-Safe Publication** means the release of bounded evidence summaries, dashboards, records, or reports that respect privacy, security, community protection, uncertainty, and authority boundaries. **Permitted Use** means the authorized Nexus purpose for which an Evidence Object may be used, such as exploratory analysis, simulation, public-safe reporting, finance-readiness, insurance-readiness, Project SPV review, Academy training, or controlled institutional review. This vocabulary prevents overclaim and supports consistent implementation across the Nexus Ecosystem. ### Canonical Operating Statement Nexus Data Protocols define a protocol-agnostic, sovereignty-preserving, public-safe, correctionable, and verifiable evidence architecture for systemic risk governance. They allow data to remain in appropriate source systems while making selected evidence states interoperable, clause-aware, simulation-ready, digital-twin-ready, finance-readiness-supporting, insurance-readiness-supporting, Grid-maturity-aware, Project-SPV-ready, public-safe, and lawful-use-bound across the Nexus Ecosystem. They are not a technical annex. They are the evidence constitution of Nexus. They make it possible for distributed information to become trusted intelligence without centralizing control, exposing sensitive records, confusing simulation with authority, treating data as truth without context, or turning readiness into execution. ## Sections This chapter is split into 7 sections, each on its own page; nothing was removed. | # | Section | | - | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | 1 | [Nexus Data Architecture](/organization/standardization/nexus-ecosystem/iii.-infrastructure/operations/nexus-ecosystem-data-protocols/01-nexus-data-architecture.md) | | 2 | [Core Data Objects and Evidence Records](/organization/standardization/nexus-ecosystem/iii.-infrastructure/operations/nexus-ecosystem-data-protocols/02-core-data-objects-and-evidence-records.md) | | 3 | [Evidence Lifecycle and Data Operations](/organization/standardization/nexus-ecosystem/iii.-infrastructure/operations/nexus-ecosystem-data-protocols/03-evidence-lifecycle-and-data-operations.md) | | 4 | [Multimodal Data Protocols](/organization/standardization/nexus-ecosystem/iii.-infrastructure/operations/nexus-ecosystem-data-protocols/04-multimodal-data-protocols.md) | | 5 | [Semantic, Jurisdictional, and Temporal Intelligence](/organization/standardization/nexus-ecosystem/iii.-infrastructure/operations/nexus-ecosystem-data-protocols/05-semantic-jurisdictional-and-temporal-intelligence.md) | | 6 | [Data Sovereignty, Privacy, and Access Control](/organization/standardization/nexus-ecosystem/iii.-infrastructure/operations/nexus-ecosystem-data-protocols/06-data-sovereignty-privacy-and-access-control.md) | | 7 | [Evidence Quality, Standards, Security, Component Integration, Sector Protocols, Implementation, Governance, and Strategic Significance](/organization/standardization/nexus-ecosystem/iii.-infrastructure/operations/nexus-ecosystem-data-protocols/07-evidence-quality-standards-security-component-integration-sector-proto.md) | ## Sources * Nexus Standards. NS-0: Constitution and principles. Proposed. [nexustandards.com/standards/ns-0/](https://nexustandards.com/standards/ns-0/) * Nexus Standards. NS-15: System model binding (subjects, passports, chronotopes, routes, engines, cells and agents). Proposed. [nexustandards.com/standards/ns-15/](https://nexustandards.com/standards/ns-15/) * Nexus Standards. NS-14: Conformance and crosswalk to external standards. Proposed. [nexustandards.com/standards/ns-14/](https://nexustandards.com/standards/ns-14/) * Nexus Standards. [NRS-S0](https://nexustandards.com/standards/nrs/#nrs-s0): System and stack passports and platform conformance. [nexustandards.com](https://nexustandards.com/standards/nrs/#nrs-s0) * OECD (2014). Recommendation of the Council on the Governance of Critical Risks. OECD/LEGAL/0405, adopted 6 May 2014. [legalinstruments.oecd.org/en/instruments/OECD-LEGAL-0405](https://legalinstruments.oecd.org/en/instruments/OECD-LEGAL-0405) * UN Office of the Secretary-General's Envoy on Technology and UNDP (2024). Universal DPI Safeguards Framework. New York: United Nations, September 2024. [www.dpi-safeguards.org](https://www.dpi-safeguards.org/) * W3C (2022). Decentralized Identifiers (DIDs) v1.0. W3C Recommendation, 19 July 2022. [www.w3.org/TR/did-core](https://www.w3.org/TR/did-core/) * Rose, S., Borchert, O., Mitchell, S. and Connelly, S. (2020). Zero Trust Architecture. NIST Special Publication 800-207. Gaithersburg, MD: NIST. [csrc.nist.gov/pubs/sp/800/207/final](https://csrc.nist.gov/pubs/sp/800/207/final) * Birkholz, H., Thaler, D., Richardson, M., Smith, N. and Pan, W. (2023). Remote ATtestation procedureS (RATS) Architecture. RFC 9334. IETF. [www.rfc-editor.org/rfc/rfc9334](https://www.rfc-editor.org/rfc/rfc9334) * ISO (2018). ISO 31000:2018 Risk management — Guidelines. Geneva: International Organization for Standardization. [www.iso.org/standard/65694.html](https://www.iso.org/standard/65694.html) * World Bank and GFDRR. Disaster Risk Financing and Insurance Program; Global Risk Financing Facility; Financial Protection Forum. [www.financialprotectionforum.org](https://www.financialprotectionforum.org/) * Network for Greening the Financial System (2024). NGFS Climate Scenarios for Central Banks and Supervisors, Phase V. Paris: NGFS, November 2024. [www.ngfs.net/system/files/import/ngfs/medias/documents/ngfs\_scenarios\_phase\_v.pdf](https://www.ngfs.net/system/files/import/ngfs/medias/documents/ngfs_scenarios_phase_v.pdf) --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.therisk.global/organization/standardization/nexus-ecosystem/iii.-infrastructure/operations/nexus-ecosystem-data-protocols.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.