Architecture
1. Overview of the Nexus Rail
The Nexus Rail is the technical substrate on which Nexus Risk Management (NRM) runs. It is not a single platform or database, but a federated, standards-based infrastructure comprising semantics, data, analytics, and interfaces under common governance.
1.1 Architectural Principles (Federation, Modularity, Explainability, Security-by-Design)
The Nexus Rail embodies the following principles:
Federation by default
Data, models, and compute remain under the control of sovereign nodes (states, institutions, communities, consortia).
The Rail enables shared semantics and protocols, not centralised ownership of data or decision rights.
Federation reduces concentration risk and supports data sovereignty and regulatory compliance.
Modularity and composability
Semantics, data pipelines, models, and applications are organised into modular components with well-defined interfaces.
Components can be combined into NRM Profiles and applications without monolithic architectures.
This supports innovation and incremental adoption: entities can implement only the modules they need.
Explainability and traceability
Every risk indicator, scenario, and decision support artifact must be traceable back to data, models, and assumptions.
Explainability is not optional; it is a design constraint for all high-stakes NRM use cases.
This is enforced through AEPs, model cards, and provenance metadata.
Security- and privacy-by-design
The Rail assumes adversarial conditions: malicious actors may attempt to corrupt data, models, or decision workflows.
Security controls, privacy protections, and abuse detection are built into each layer.
Compute-to-data patterns and minimal necessary exposure are preferred over bulk data movement.
Neutral core, plural edge
The core standards (ontologies, formats, protocols) are neutral and minimal, enabling diverse local implementations.
Pluralism (multiple ontologies, models, governance patterns) is supported at the edge, subject to conformance and interoperability rules.
1.2 Layered Architecture (Semantic, Data, Analytics, Interface)
The Nexus Rail can be described in four layers, with cross-cutting security and governance:
Semantic layer
Core Risk Ontology and domain extensions.
Definitions of entities, relationships, events, processes, and metrics used in NRM.
Mapping schemas to existing standards and local ontologies.
Data and graph layer
Federated risk graph representing entities, relationships, and time-evolving states.
Data mesh infrastructure connecting sovereign nodes.
Provenance and licensing metadata.
Analytics, AI, and simulation layer
Scoring engines (risk, resilience, equity, system stress).
Scenario and simulation engines (stochastic, network, agent-based, digital twins).
Model serving, monitoring, and lifecycle management (MLOps).
Interface and integration layer
Role-specific dashboards and tools.
APIs for ERM systems, regulatory systems, and other applications.
Public and community-facing visualisations and explainers.
Security, identity, authorisation, and audit capabilities span all layers.
1.3 NRM’s Dependence on Nexus Rail Components
NRM is not implementable without the Nexus Rail, because:
NRM Profiles are defined in terms of ontology entities and relationships provided by the semantic layer.
Assurance & Evidence Packs (AEPs) and cross-domain scenarios rely on the federated risk graph and UNOSINT data channels.
Scoring engines and simulations are deployed and governed through the analytics layer of the Rail.
NRM’s interfaces with ERM systems, regulators, and communities are implemented through the integration and visualisation layer.
Conversely, the Rail is intentionally general-purpose; non-NRM applications may exist. However, NRM is its flagship systemic-risk use case, and the architecture is optimised accordingly.
2. Semantic and Ontology Layer
The semantic layer provides the shared language of NRM. It is implemented as a family of machine-readable ontologies and schemas.
2.1 Core Risk Ontology: Entities, Relations, and Logic
The Core Risk Ontology defines generic building blocks that underpin all NRM Profiles:
Entities
Actors: governments, agencies, financial institutions, firms, utilities, communities, Indigenous nations, multilateral bodies.
Assets: physical assets (plants, lines, buildings), financial assets (loans, securities), digital assets, natural assets (forests, watersheds, aquifers).
Services: electricity supply, water provision, health services, mobility, digital connectivity, ecosystem services.
Hazards: climatic events, epidemics, cyber-attacks, infrastructure failures, socio-political shocks.
States & indicators: risk metrics, resilience metrics, stress levels, capacity indicators, vulnerability indices.
Relations
Dependency: service A depends on asset B; community C depends on service D.
Exposure: asset E is exposed to hazard H in certain conditions.
Control: actor X operates or regulates asset or service Y.
Flow: flows of energy, water, finance, information, people.
Obligation: legal, contractual, or normative obligations (e.g., payout obligations, service-level commitments).
Logic
Event logic: hazard events, transitions, and their states (occurrence, forecast, early-warning, near-miss).
Causal and influence structures: qualitative and quantitative relationships (e.g., hazard intensity → damage function → service disruption).
Temporal logic: timescales and sequencing (e.g., lead times, lagged effects, recovery trajectories).
The Core Risk Ontology is deliberately minimal but precise, so domain extensions can remain interoperable.
2.2 Domain Extensions: Climate, Bio, Cyber, Financial, Infrastructure, Social
Domain-specific ontologies extend the core with specialised classes, properties, and logic:
Climate and environmental
Climate hazards (heatwaves, drought, storms, floods, sea-level rise), climate drivers, emissions, sinks.
Ecosystem types, functions, and degradation states.
Linkages to IPCC and other established climate/earth system schemas.
Biological and health
Pathogens, hosts, vectors, health system capacities (beds, staff, supplies).
Epidemiological states and transitions (SIR-type models, severity, long-term impacts).
One Health links (animals, environment, human populations).
Cyber and digital
Systems and components (networks, data centres, applications, OT/IT).
Vulnerabilities, threat types, incident classifications.
Mappings to NIST CSF and other cyber standards.
Financial and macroeconomic
Financial institutions, instruments, exposures, and risk factors.
Macro variables and stress-test indicators.
Mappings to Basel risk taxonomies and supervisory templates.
Infrastructure and industrial
Network models for power, water, transport, logistics.
Capacity, redundancy, and failure modes.
Safety and reliability constructs.
Social and political
Population and demographic attributes.
Governance and institutional indicators, social cohesion, fragility indexes.
Conflict, migration, and information ecosystem elements.
These extensions are maintained by GCRI with domain experts, and governed under GRF processes.
2.3 Indigenous and Community Ontology Extensions and Sovereignty Rules
NRM explicitly supports Indigenous and community ontology extensions:
Ontology extensions
Local place names, land relations, seasonal patterns.
Cultural, spiritual, and relational constructs relevant to risk and resilience.
Locally defined indicators of stress, harm, and well-being.
Sovereignty rules
Indigenous and community ontologies are:
Owned and governed by those communities,
Integrated into NRM only under explicit consent and agreed protocols,
Protected by rights to:
Refuse integration,
Limit scope and granularity,
Withdraw or revise contributions.
Firebreaks and controlled mappings
Some knowledge remains off-rail by design; other knowledge may be represented in abstracted or redacted form.
Controlled mapping layers can link Indigenous ontologies to core/domain ontologies without disclosing sensitive details.
This ensures that epistemic pluralism and data sovereignty are structural features of the semantic layer, not add-ons.
2.4 Ontology Governance, Versioning, and Branching (Plural Models)
Ontology governance follows similar principles to NRM as a whole:
Versioning and branching
Ontologies are versioned; changes are logged and reviewed.
Branching allows:
Experimental or local variants,
Temporary forks to accommodate contested concepts.
Where necessary, multiple branches may coexist, with explicit inter-branch mappings.
Plural models
For contentious domains (e.g., certain social constructs, disputed hazard classifications), multiple ontologies or sub-ontologies may be recognised.
NRM Profiles must specify which branch/version they use and how alternative views are represented (e.g., as scenario variants).
Governance bodies
GCRI leads technical stewardship.
GRF ensures that ontology decisions respect:
Community and Indigenous rights,
Equity and justice commitments,
Anti-capture and transparency requirements.
Advisory forums include domain experts and affected stakeholders.
The semantic layer is thus both stable enough for systems integration and flexible enough to handle genuine disagreement and evolution.
3. Data Mesh and Federated Risk Graph
3.1 Data Mesh Concepts Applied to NRM
NRM adopts a data mesh approach:
Domain-oriented ownership
Data is owned and managed by domain teams (e.g., ministries, utilities, banks, NCCs, communities) who understand its meaning and limitations.
Data as product
Each domain publishes data products:
With clear schemas, quality guarantees, and SLAs,
Interpretable in terms of the Core Risk Ontology and domain extensions.
Self-serve infrastructure
Shared infrastructure (connectors, catalogues, access controls) enables domain teams to publish and consume data products without central bottlenecks.
Federated governance
Global standards and local policies coexist via shared principles and conformance frameworks.
This approach balances autonomy and coherence, critical for multi-country and multi-sector NRM deployments.
3.2 Federated Risk Graph Structure and Node Responsibilities
The federated risk graph is a logical construct, realised via distributed graph databases and indexes:
Nodes
Sovereign data nodes (country systems, institutions, RNCs, NCCs),
Thematic nodes (e.g., climate, health, cyber observatories),
Community/Indigenous nodes with appropriate protections.
Responsibilities
Each node:
Maintains its own graph segment(s), conformant to agreed ontologies,
Responds to queries and graph operations according to access policies,
Contributes to federated views (e.g., regional risk overviews, global stress indicators) via aggregated or anonymised outputs.
Query federation
NRM queries traverse the graph via:
Schema-aware routing,
Federated query engines,
Local decision rules (what to expose at what granularity).
Minimal centralisation
Registry and coordination services exist (e.g., schema registries, directory of nodes), but no central “master graph” holds all data.
This structure enables NRM to function as a global risk graph without compromising sovereignty or scaling properties.
3.3 Data Provenance, Lineage, and Licensing Metadata
Every piece of data participating in NRM must carry provenance and usage metadata:
Provenance
Source (institution, sensor, dataset, community),
Acquisition method and date,
Processing steps and transformations.
Lineage
Data dependencies (what input datasets and models produced a given output),
Versioning of input and output artifacts.
Licensing and usage
Legal and contractual constraints (e.g., open license, restricted, Indigenous data rights agreements),
Permitted uses (e.g., research only, operational, commercial),
Obligations (e.g., attribution, non-derivation).
Provenance and licensing are critical for:
Trust and auditability,
Respecting rights and obligations,
Enabling regulators and communities to understand how NRM outputs are derived.
3.4 Privacy, Sovereignty, and Compute-to-Data Approaches
NRM assumes:
Data privacy and confidentiality must be protected,
Sovereignty constraints (national, institutional, community) must be honoured.
To that end, the Rail prioritises:
Compute-to-data
Models are brought to the data behind secure boundaries; only aggregate or anonymised outputs leave.
Techniques may include:
Secure enclaves,
Federated learning,
Differential privacy (where relevant).
Data minimisation
Only necessary fields and granularity are used for a given NRM Profile or query.
Sensitive details can be redacted while still enabling systemic analysis.
Sovereignty controls
Nodes define policies specifying:
Which queries and profiles are allowed,
What level of aggregation is required,
Under what conditions certain use cases (e.g., commercial offerings) are permitted.
These mechanisms are central to making NRM acceptable to sovereigns, institutions, and communities.
4. UNOSINT – Universal Nexus Open Source Intelligence
UNOSINT is the intelligence layer that runs on Nexus Rail, providing the evidence backbone for NRM.
4.1 UNOSINT Data Sources (OSINT, EO/GIS, Climate, Health, Cyber, Infrastructure, Finance, Community)
UNOSINT aggregates a wide range of data:
OSINT (Open-Source Intelligence)
News, reports, social media indicators (carefully filtered and validated),
Policy and regulatory documents.
EO/GIS (Earth Observation / Geospatial)
Satellite imagery, remote sensing products,
Land-use, vegetation, water, and urban indicators.
Climate and Earth system
Reanalysis datasets, climate model outputs, observational networks,
Derived hazard indicators (heat indices, drought indicators, flood maps).
Health and bio
Epidemiological surveillance, health system capacity indicators,
Syndromic surveillance, laboratory data, demographic and vulnerability statistics.
Cyber and digital
Incident feeds, threat intelligence, network telemetry (within legal/contractual limits),
Availability and performance data of critical digital services.
Infrastructure
(Where permissible) operational telemetry and status indicators from grids, pipelines, networks,
Asset and service maps, maintenance and reliability data.
Finance and macro
Market data, price series, spreads, volatility measures,
Macro indicators (GDP, employment, inflation, trade flows).
Community and Indigenous
Community-generated observations, participatory mapping, local indicators,
Indigenous knowledge contributions (subject to sovereignty protocols).
UNOSINT is not a raw data dump; it is a structured set of curated intelligence streams mapped into the Nexus ontology.
4.2 Pipeline Design: Ingestion, Validation, Fusion, and Quality Checks
Data flows through multi-stage pipelines:
Ingestion
Connectors pull data from trusted sources, APIs, and local nodes.
Ingestion processes include basic format validation and schema checks.
Validation and cleaning
Integrity checks, outlier detection, cross-source consistency checks.
Domain-specific validation (e.g., climatological plausibility, epidemiological consistency).
Fusion and enrichment
Spatial and temporal alignment,
Joining across datasets (e.g., hazards with exposure maps and sociodemographic data),
Classification and feature engineering based on ontologies.
Quality scoring
Assignment of quality scores that inform Evidence Quality Levels (EQL).
Documentation of known gaps, biases, and uncertainties.
Publication as data products and AEP inputs
Curated datasets are:
Exposed as UNOSINT data products on the Rail,
Used to assemble Assurance & Evidence Packs for specific NRM Profiles.
All pipeline stages produce logs and metadata for audit and reproducibility.
4.3 Assurance & Evidence Packs (AEPs): Format, Content, and Lifecycle
Assurance & Evidence Packs (AEPs) are the primary unit of decision-grade evidence in NRM.
Each AEP typically includes:
Scope and purpose
What question or NRM Profile it supports,
Intended use and limitations.
Data components
Source datasets, transformations, and quality scores.
Models and methods
Models used (with model cards),
Calibration and validation results,
Uncertainty characterisation.
Findings and indicators
Key risk, resilience, equity, and system stress metrics,
Scenario results and sensitivity analyses.
Ethics and justice annotations
Distributional impacts, affected populations,
Known blind spots (e.g., missing communities, underrepresented groups).
Provenance and co-authorship
Institutions, communities, and AI systems that contributed,
Signatures and review history.
Lifecycle:
Drafting
Generated by GCRI/NCCs, communities, or other authorised entities, often with AI assistance.
Review and assurance
Peer review, community/Indigenous review where relevant, GRF oversight for high-stakes uses.
Publication
Posted to Nexus Rail with versioning and identifiers.
Use and feedback
Referenced in NRM Profiles, scenarios, decisions; feedback and challenges logged.
Revision or retirement
Updated as conditions or methods change; deprecated when obsolete.
AEPs are central to transparency, contestability, and reuse in NRM.
4.4 Co-Authorship and Provenance: Human, Indigenous, and Machine Contributions
NRM requires that contributions of different intelligences are explicitly recognised:
Human and institutional co-authors
Scientists, analysts, practitioners, community and Indigenous representatives,
Their roles and contributions are recorded (e.g., model selection, data interpretation, governance decisions).
Indigenous and community contributions
Identified with their own attribution rules, respecting:
Collective authorship,
Cultural protocols,
Limitations on reuse and redistribution.
Machine contributions
AI models and tools are listed as contributors with:
Model identifiers,
Training data descriptors,
Limitations and known failure modes.
This co-authorship model:
Supports attribution and recognition,
Highlights where evidence relies heavily on any one type of intelligence,
Facilitates accountability and challenge.
5. Analytics, AI, and Simulation Layer
5.1 Scoring Engines (Risk, Resilience, Equity, System Stress)
NRM uses scoring engines to quantify multiple dimensions:
Risk scores
Probability and severity estimates for specified outcomes (losses, disruptions, defaults).
Resilience scores
Measures of capacity to absorb, adapt to, and recover from shocks (redundancy, robustness, adaptiveness).
Equity and justice scores
Indicators of distributional impact (who is exposed, who benefits, who bears residual risk).
System stress indexes
Aggregate indicators of stress and fragility across systems (e.g., multi-sector stress indices).
Requirements:
Scores must:
Be traceable to underlying data, models, and assumptions,
Include uncertainty ranges and sensitivity indicators,
Avoid being treated as oracles; they are aids, not replacements, for judgement.
5.2 Scenario and Simulation Engines (Stochastic, Network, Agent-Based, Digital Twins)
NRM leverages multiple simulation paradigms:
Stochastic simulations
Monte Carlo and related methods to explore ranges of outcomes.
Network models
Simulations of propagation across interdependent networks (infrastructure, financial, social).
Agent-based models
Representations of heterogeneous actors (households, firms, institutions) with behavioural rules.
Digital twins
High-fidelity, near-real-time representations of physical and cyber-physical systems (e.g., grid, water system, hospital network).
NRM Profiles specify:
Which simulation approaches are acceptable,
What validation standards apply,
How heterogeneity and behaviour are represented.
5.3 Model Governance and MLOps for NRM
Models in NRM are governed under a disciplined model lifecycle:
Registration and documentation
Each model has a unique ID, model card, owners, and governance status.
Validation and testing
Quantitative performance checks, robustness tests, out-of-sample validation.
Monitoring and drift detection
Continuous monitoring for shifts in inputs, outputs, and performance.
Change management
Versioning and rollback procedures,
Impact assessments for major changes.
MLOps practices are adapted to NRM’s needs:
Conservative practices for high-stakes, systemic decisions,
Experimental practices sandboxed and clearly labelled for exploratory analysis only.
5.4 Human-in-the-Loop Workflows and Validation Protocols
NRM mandates that AI and analytics are embedded in human-in-the-loop workflows:
Decision checkpoints
Defined stages where human decision-makers:
Review model outputs,
Consider alternative explanations and scenarios,
Have explicit authority to override model recommendations.
Validation protocols
Systematic procedures for:
Cross-checking model outputs against expert judgement and external benchmarks,
Reviewing performance after real-world events (post-mortems, after-action reviews).
Structured dissent
Mechanisms for experts, communities, and institutions to:
Flag concerns about models or scores,
Trigger formal reviews or appeals.
These practices ensure that NRM remains aligned with human values and institutional responsibility, even as it leverages advanced analytics.
6. Interfaces and User Experience
6.1 Role-Specific Dashboards (CRO, Regulator, Infrastructure Operator, Community Leader)
NRM will be consumed by diverse users; interfaces must reflect this:
CRO / ERM dashboards
Integration of internal risk metrics with NRM evidence and scenarios,
Views of systemic exposures and facilities linked to NRM Profiles.
Regulator / policy dashboards
System-wide stress indicators,
Comparative views across firms, sectors, and regions (with privacy safeguards),
Drill-down into AEPs and Profiles underpinning policy options.
Infrastructure operator dashboards
Cross-infrastructure dependencies,
System stress indicators relevant to operations,
Guidance on pre-agreed, NRM-linked actions and support mechanisms.
Community / Indigenous leader dashboards
Locally relevant risk indicators and projections,
Clear explanations of how NRM-linked decisions affect their jurisdictions,
Tools for providing feedback, contestation, and local data.
Interfaces are designed to be interpretable and actionable for each role.
6.2 Graph Navigation and Geospatial Visualisation
Users need to see risk in relational and spatial terms:
Graph navigation
Tools to visualise nodes (actors, assets, hazards, communities) and their relationships,
Ability to trace paths of dependency and propagation.
Geospatial visualisation
Maps and geospatial analytics showing hazard zones, exposure, vulnerability, and resilience assets,
Layering of physical, social, financial, and governance data.
These capabilities help users move beyond siloed tables and charts, towards network and place-based understanding.
6.3 Explanation Interfaces (Model Cards, Scenario Explainers, Public Modes)
Explanation interfaces translate complexity into legible narratives:
Model cards
Compact, accessible summaries of models used, their limits, and performance.
Scenario explainers
Interactive narratives explaining how scenarios are constructed, which assumptions matter, and what ranges are plausible.
Public modes
Simplified, non-technical explanations suitable for public communication, civic education, and accountability.
NRM treats explanation as first-class functionality, not an afterthought.
6.4 Integration APIs for Enterprise ERM Systems
NRM’s interface layer exposes well-documented APIs for:
Pulling NRM AEPs, Profiles, and scenarios into ERM systems,
Pushing selected ERM metrics and exposures into the Nexus Rail for systemic analyses,
Managing authentication, authorisation, and logging.
APIs support:
Multiple integration models (e.g., batch, streaming),
Common standards (e.g., JSON/GraphQL over secure protocols),
Extensible metadata for custom enterprise use.
This ensures that NRM augments rather than replaces existing ERM tooling.
7. Security, Reliability, and Interoperability
7.1 Threat Model for Nexus Rail and NRM Implementations
NRM assumes sophisticated adversaries:
External attackers
Aim to exfiltrate sensitive data, corrupt models, or disrupt operations.
Insiders
May misuse access for personal or institutional advantage.
Data and model poisoning
Adversaries attempt to inject false signals or bias into data and AI models.
Information operations
Actors may attempt to manipulate perceptions by selectively misusing or misrepresenting NRM outputs.
Threat modelling is part of the Rail design and NRM Profiles for high-stakes domains; mitigation measures are mandatory for NRM conformance.
7.2 Identity, Authentication, Authorisation, and Audit
Core requirements:
Strong identity
Verified identities for institutions, systems, and, where relevant, individuals.
Authentication
Multi-factor and/or hardware-backed authentication for sensitive operations,
Federated identity where multiple institutions are involved.
Authorisation
Role-based and attribute-based access controls,
Fine-grained permissions for data access, model deployment, and governance actions.
Audit
Comprehensive logging of:
Data access and transformations,
Model deployments and overrides,
Governance decisions and changes to NRM Profiles.
Logs must be tamper-evident and, for high-stakes use, dual-logged (e.g., in Nexus Ledger / Council Register).
These controls underpin trust, accountability, and legal robustness.
7.3 Resilience, Redundancy, and Disaster Recovery
Given NRM’s role as critical risk infrastructure:
Resilience
Components must be designed for graceful degradation rather than catastrophic failure,
Fallback modes (e.g., reduced functionality, last-known-good data) are defined for crises.
Redundancy
Critical services (e.g., schema registries, coordination services) are replicated across regions and providers,
No single point of failure should be able to compromise NRM operations.
Disaster recovery
Clear RTO/RPO (Recovery Time and Recovery Point Objectives) for NRM-critical services,
Tested backup and restoration procedures,
Contingency plans for jurisdictional disruptions (e.g., severed network links).
These provisions ensure that NRM itself does not become a new systemic single point of failure.
7.4 Interoperability with Existing Systems and Standards
Finally, NRM must coexist with a heterogeneous landscape:
Technical interoperability
Use of open standards where possible (e.g., JSON-LD, OWL, common geospatial formats),
Adapters and mappings to legacy systems and formats,
Support for gradual migration and hybrid deployments.
Standards interoperability
Alignment with existing risk standards as described in §3.3,
Ability to ingest and expose data in formats required by supervisors and existing processes,
Clear documentation of how NRM constructs map to existing regulatory and industry taxonomies.
Interoperability is critical for adoption, trust, and long-term viability. NRM is designed to be an integration layer that makes existing systems more coherent and powerful, rather than forcing wholesale replacement.
Last updated
Was this helpful?