> 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/introduction/acceleration/iv.-foundry.md). # IV. The Foundry pillar and the systems The Foundry pillar and the build systems as a target design: how Nexus capabilities are built, verified, packaged, licensed and retired through NXS-FAC, NXS-STU, NXS-NXQ and NXS-APP, never certified. **Where this fits:** all six sectors · the [Foundry pillar](/organization/programme/foundry.md), with [Labs](/organization/programme/labs.md), [Nexus Universe](/organization/programme/universe.md) and [Risk Academy](/organization/programme/academy.md) · the [Nexus Consortium](/organization/institutions/nexus-consortium.md) and [National Nexus](/organization/governance-in-operation/national-nexus.md) · the Planning, Readiness preparation and Controlled build phases of [the programme year](/organization/programme/the-programme-year.md) · introduction to the deep doctrine. Canonical homes: [The Model](/organization/model.md) · [Systems](/organization/systems.md) · [Finance readiness](/organization/finance-readiness.md).
Document record · Draft · Legal review required · Updated 21 October 2026 | | | | ---------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Status** | Draft. Explanatory page; it creates no rights or obligations. | | **Legal review** | Required before final publication. | | **Version** | 2026.10.21-r3 | | **Updated** | 21 October 2026 · reviewed every 180 days | | **Owner** | Documentation desk (named reviewer pending) | | **Based on** | Nexus constitutional directives D-V3-0001 (*Master directive V3*: Rights Control Plane, Evidence and Receipt Fabric), D-V3-0003 (*Twenty-system constitution*) and D-V3-0004 (*One Rail-Two Stacks and non-execution*); the owner decision of 11 October 2026 on Nexus institutional architecture and participation, with GCRI Canada as lead contracting organization; the release hold policy and the claim register in the Nexus institutional register; the Nexus Documentation Standard (draft of 16 October 2026); the Nexus model and the Nexus Consortium model as published on the GCRI, GRF and GRA sites; [Nexus Standards](/organization/institutions/nexus-standards.md) as published at nexustandards.com | | **Corrections** | Public corrections route to be announced; corrections are published as new dated versions. |
{% hint style="info" %} **Status.** System capabilities described on this page are target architecture under development. Nothing here states that a capability is in production use, certified or offered as a service. {% endhint %} ## In brief Foundry, in this chapter, is the target design for how Nexus capabilities are built, tested, verified, packaged, licensed, supported, renewed and retired, so that one-off pilots become reusable deployment units. In the V3 constitution this work belongs to [NXS-FAC](/organization/systems/nxs-fac.md) (the mission application factory, which produces app blueprints but never runs them), with composition in [NXS-STU](/organization/systems/nxs-stu.md) (the builder and configuration workspace, which composes but never deploys), packages and entitlements in [NXS-NXQ](/organization/systems/nxs-nxq.md) (the software, capability and agent fabric for registries, licensing, APIs and connectors) and installation in [NXS-APP](/organization/systems/nxs-app.md), the mission app runtime, for app instances, routes and versions. Foundry verifies; it does not certify. No package, deployment unit, licence or revenue allocation is recorded as issued \[1]\[2]\[4]. ## Current position (21 October 2026) This section brings the page up to date with the published sites, the Nexus Standards and the owner's rulings of October 2026. Where the older text below differs, this section and the canonical pages it links govern. **Systems, not products.** The technology this page refers to is the [twenty Nexus systems](/organization/systems.md), each named by its display code (for example [NXS-COR](/organization/systems/nxs-cor.md) for compute and runtimes, [NXS-NET](/organization/systems/nxs-net.md) for networks, NXS-FAC for builds and verification, NXS-NXQ for packages and capability lifecycle, NXS-APP for the application catalogue and [NXS-RLS](/organization/systems/nxs-rls.md) for agreements and lawful handoffs). The build work is the [Foundry pillar](/organization/programme/foundry.md): "a configured or simulated capability is not a validated result, and a National Portfolio entry is not an investment decision" \[21]. Technology, infrastructure and service providers work with the Nexus Consortium at arm's length under written agreements. In the programme year the Foundry pillar receives admitted missions (F01) and composed mission profiles (F08); it hands the Core Build Report and go or no-go evidence to Nexus Universe (F02), validation and monitoring evidence to Nexus Standards (F13), sealed observations and National Portfolio movement to [Nexus Reports](/organization/programme/reports.md) (F03, F05), and each system's rooms to [Risk Academy](/organization/institutions/risk-academy.md) as learning-by-doing courses (F14) \[21]. Its owned records are projects and builds, observations and canonical data, simulation and benchmark runs, the National Portfolio record and evidence seals ([The Foundry pillar](/organization/programme/foundry.md)). **Finance boundary.** National Consortium Companies and Project SPVs are structures that competent, lawful actors may form outside the programme, under their own law and licences. The programme prepares evidence, standards and readiness; it never forms, arranges, owns or advises on a vehicle or a transaction, and readiness evidence is not a financing decision \[22]\[23]. Where this page describes such vehicles, read it with [Lawful handoffs](/organization/finance-readiness/lawful-handoffs.md) and [National portfolios](/organization/finance-readiness/national-portfolios.md). **Status.** Every programme is in formation and the current service level is R0, information and enquiries; no edition of Nexus Reports has been released and no Risk Academy credential has been issued \[24]\[25]. ## Status, scope and terms of this page **Status in the five-state grammar.** Target: defined in this documentation and, for NXS-FAC, NXS-STU, NXS-NXQ and NXS-APP, by the V3 twenty-system constitution \[1]. Implemented: No record cited on this page for any Foundry package, deployment unit or Marketplace object released to a customer or public authority. Verified: No record for any released package. Observed: No record. Accepted: No record. Status words follow the controlled vocabulary of the public site draft \[8]; no Foundry facility is recorded at any of the fifteen planned hubs, which are coordination roles, not offices \[7]. **What "Foundry" means here.** In the institutional records, the technical architecture is the [twenty Nexus systems](/organization/systems.md), whose technology is proprietary infrastructure made available to the Nexus Consortium "as shared infrastructure for public-good and consortium purposes" by an external provider at arm's length \[3]. This chapter uses "Foundry" only for the Foundry pillar: the build, packaging and lifecycle work of the programme. Read that way, the V3 owners are NXS-FAC for "Blueprints, Builder operations, code and artifact generation, verification, builds, signing and assembly"; NXS-STU for "Visual composition, dashboards, maps, forms, workflow experiences, reusable artifacts and deployment profiles"; NXS-NXQ for "Software, packages, connectors, models, tools, skills, agents, entitlements and capability lifecycle"; and NXS-APP for "Application catalog, installation, instances, dependencies, health, upgrades, rollback and retirement" \[1]. NXS-STU composes; the Universal Runtime executes \[6]. {% hint style="warning" %} **Platform ownership and licensing.** Ownership, development, operation and licensing terms for the technology behind the systems are set out in the applicable agreements. Legal title and licensing authority for each asset remain subject to verification, to valid instruments and to government, institutional, customer and third-party exceptions, and no executed assignment or licence is established by this page. Technology licences outside the not-for-profit service based on the Nexus systems require a separate agreement with a lawful rights holder. GCRI Canada remains the contracting party for services based on the Nexus systems and for consortium participation. Unverified title, government restrictions and third-party rights cannot be overridden by a plan, payment or this page \[3]. {% endhint %} **Institutions.** The institutional roles that bear on this page are stated once, in register wording, on [I. Order of the Organization introduction](/organization/introduction/organization/i.-order.md): GCRI Canada ([The Global Centre for Risk and Innovation](/organization/institutions/gcri.md)) is Lead Institution, Consortium Secretariat and lead contracting organization; [The Global Risks Forum](/organization/institutions/grf.md) (GRF) is a consortium steward for leadership, dialogue and Nexus Universe programme governance; [The Global Risks Alliance](/organization/institutions/gra.md) (GRA) is a consortium steward for the finance, insurance and development-readiness interface; and competent public authorities keep all sovereign, regulatory, fiduciary and operational decisions \[3]. Standards discipline sits with [NXS-NSF](/organization/systems/nxs-nsf.md), the trust, sovereignty and assurance plane for identity, policy gates and access decisions, and Nexus Standards is a proposed standards programme with no publisher of record \[1]\[9]. **Certification.** Earlier text described Foundry "production certification", certification fees and certified packages. Under the V3 boundary formulas, "Verification is not certification" \[2]; no attestation is described as a certificate, and Nexus issues no certificate, badge or accreditation \[9]. This revision recasts those passages as verification, records each rewrite in the edit log, and keeps every boundary the original set. Fees, licences and Revenue Waterfall allocations described below are design proposals: no fee schedule, executed licence or allocation is recorded \[3]\[9]. {% hint style="info" %} **Nexus Observatory Protocol.** On this site, Nexus Observatory Protocol is the observation protocol owned by [NXS-OPS](/organization/systems/nxs-ops.md), the observatory protocol system, in collaboration with [NXS-EOP](/organization/systems/nxs-eop.md), the Earth observation, geospatial and digital-twin fabric, and [NXS-SIG](/organization/systems/nxs-sig.md), the authorized signal, spectrum and communications integrity system. Together these three systems form the observatory ecosystem. **Nexus of Observatories.** Every Nexus platform and system includes its own observatory capability, covering remote sensing, in-situ instruments and edge deployments. Across every area where these observatories are implemented, including implementation pilots in programme areas, they form the Nexus of Observatories, which is part of the not-for-profit programme architecture. On this site, "Nexus Observatory" refers only to this observatory capability and to the protocol above. {% endhint %} ## Summary This page defines **Foundry** within Nexus Acceleration. If **II. Compute** defines the technical estate intended for national control and **III. Edge** defines the distributed observatory layer through which Nexus becomes locally aware, then **IV. The Foundry pillar and the systems** defines the controlled build, production, packaging, testing, verification, support, licensing, marketplace, and lifecycle environment through which Nexus capabilities become repeatable operational systems. The Foundry pillar is not merely a developer tool, design lab, implementation office, or product workshop. It is the governed production architecture through which standards, methods, open-source Digital Public Goods, ontologies, schemas, agents, connectors, playbooks, dashboards, evidence products, proof methods, public-safe rules, finance-readable mappings, sovereign profiles, partner components, and deployment patterns are converted into deployable operational capacity. In this chapter, Foundry is described in two senses: as a **design-and-assembly environment**, where rails, packs and configurations are authored, tested and prepared before they reach runtime, and as an **enterprise-grade realization layer**, which converts public-good standards, open-source components, technical frameworks, public-safe reporting rules, finance-readiness evidence frameworks, blueprints, sovereign deployment profiles, hardware, software and data configurations, partner capabilities and institutional components into deployable operational capacity. In the institutional records both senses sit inside the twenty Nexus systems: build and assembly are NXS-FAC functions, runtime composition is NXS-STU, and execution belongs to the Universal Runtime \[1]\[6]. Foundry matters because Nexus cannot scale through bespoke pilots. It cannot rely on one-off dashboards. It cannot turn every deployment into custom consulting. It cannot allow public-good methods to remain unsupported artifacts. It cannot allow open-source Digital Public Goods to be used without maintenance. It cannot allow public-safe reports, evidence methods, or finance-readable mappings to be improvised project by project. It cannot allow runtime systems to be modified directly in production without controlled design authority. Foundry exists to make Nexus repeatable. It turns knowledge into packages. It turns methods into supported workflows. It turns pilots into deployment units. It turns field lessons into improved blueprints. It turns public-good components into operational capacity without enclosing them. It turns enterprise implementation into a sustainability engine without allowing enterprise execution to capture the public-good stack. *** ## 4.1 Why Foundry Exists Foundry exists because a public-good architecture that cannot be professionally realized will remain fragile, underused, and operationally thin. Nexus produces many forms of value: standards, ontologies, schemas, Digital Public Goods, observability methods, evidence frameworks, public-safe reporting rules, recognition systems, finance-readable taxonomies, domain packs, sovereign profiles, node configurations, NXS-STU workflows, Academy materials, Marketplace objects, and national or regional deployment patterns. But these components do not become durable infrastructure merely because they exist. A standard must become an implemented interface. A method must become a supported workflow. An ontology must become usable in systems. A schema must become validated in data exchange. A public-safe rule must become a publication workflow. A finance-readable taxonomy must become an evidence pack. A node profile must become a deployable configuration. A pilot must become a reusable deployment unit. A dashboard must become maintainable. A connector must become supportable. An open-source component must become versioned, secured, documented, and sustained. Foundry exists to perform this conversion under discipline. It is the place where Nexus becomes buildable, testable, packageable, verifiable, licensable, supportable, and renewable. *** ## 4.2 What Foundry Means in Nexus Within Nexus, Foundry means the governed production and assembly environment through which Nexus-aligned components are authored, configured, tested, packaged, verified, licensed, released, supported, renewed, corrected, and retired. Foundry may include: * rail design environments; * pack authoring environments; * ontology and schema tooling; * policy and playbook editors; * connector frameworks; * agent configuration systems; * dashboard and visualization assembly; * evidence product design; * proof record tooling; * public-safe publication templates; * finance-readable evidence mappings; * sovereign profile configuration; * node profile generation; * golden images; * deployment blueprints; * infrastructure-as-code templates; * edge orchestration patterns; * security and privacy baselines; * test harnesses; * simulation environments; * conformance preparation; * production verification workflows; * Bill of Materials discipline; * Evidence Passport discipline; * marketplace packaging; * support schedules; * licensing schedules; * price objects; * renewal logic; * decommissioning rules; * and deployment-to-asset review. Foundry is therefore not only a build environment. It is a production governance system. It governs how capabilities become operational and how operational experience becomes reusable system value. *** ## 4.3 The Foundry Thesis of Nexus The Foundry thesis of Nexus is that **a public-good-rooted, standards-bearing, sovereignty-compatible, and enterprise-deployable architecture can scale only if public-good components and enterprise implementation are connected through a governed production layer that converts modular standards, Digital Public Goods, methods, evidence frameworks, public-safe rules, finance mappings, profiles, packs, and partner capabilities into repeatable deployment units while preserving public-good independence, non-exclusivity, licensing discipline, role separation, lifecycle support, and correctionability**. This thesis has several implications. Public-good standards must remain independently valid. Enterprise implementation must remain professionally supported. Open rails must remain open or broadly licensable. Protected engines may remain commercially protected. Deployment units must be documented and supportable. Pilots must become evidence and learning events. Public-good components must be visible in Bills of Materials. Revenue should support public-good sustainability. Verification must not be bought, and no certification is issued. Public-safe review must not be bypassed. Finance readability must not become finance execution. Production readiness must not be confused with technical conformance. NXS-STU runtime must remain separate from Foundry build authority. Foundry is the bridge between architecture and deployment, but it must not become the owner of the whole Nexus universe. *** ## 4.4 Foundry and NXS-STU Foundry and NXS-STU are paired but distinct. **Foundry** is where Nexus capabilities are designed, assembled, tested, packaged, verified, and prepared for controlled release. **NXS-STU** is where approved capabilities are composed for live or controlled operational settings; the Universal Runtime executes them \[1]\[6]. The distinction is essential. Foundry is the build authority environment. NXS-STU is the composition environment over the runtime. Foundry authors rails. NXS-STU operates rails. Foundry designs packs. NXS-STU runs packs. Foundry tests workflows. NXS-STU uses workflows. Foundry creates release candidates. NXS-STU runs released or authorized versions. Foundry prepares deployment units. NXS-STU makes them operationally visible. This separation prevents a major failure mode: designing directly in production. If build work happens inside runtime without control, the system becomes brittle, unsafe, hard to audit, and vulnerable to local improvisation. If design never reaches runtime, the architecture becomes elegant but inert. Foundry and NXS-STU together solve that problem. *** ## 4.5 Foundry as Build Authority Environment Foundry is the build authority environment of Nexus. In V3 terms this is NXS-FAC, whose remit is "Blueprints, Builder operations, code and artifact generation, verification, builds, signing and assembly" \[1]. It is where authorized architects, engineers, standards stewards, domain experts, ontology stewards, evidence designers, public-safe reviewers, finance-mapping specialists, developers, integrators, and implementation teams prepare operational capacity under rule. Foundry may author or assemble: * rails; * domain packs; * sector packs; * sovereign profiles; * regional profiles; * national profiles; * node profiles; * edge configurations; * observatory workflows; * NXS-STU workflows; * agent workflows; * AI-assisted tools; * evidence products; * proof packages; * public-safe templates; * Marketplace objects; * Digital Public Goods; * training assets; * deployment packages; * and support materials. Foundry is not free-form experimentation by default. It is innovation under production discipline. It allows Nexus to evolve without destabilizing live deployments. *** ## 4.6 Foundry as Enterprise Production Layer Foundry also functions as an enterprise production layer. This means it can convert public-good assets into supported, licensable, verified, commercially sustainable operational packages where selected. The public-good stack remains independently stewarded. The Nexus Consortium is stewarded by three independent not-for-profit institutions, GCRI Canada as Lead Institution, Consortium Secretariat and lead contracting organization, The Global Risks Forum (GRF) and The Global Risks Alliance (GRA) \[3]; it draws on regional and national consortium structures, open-source communities, universities, public authorities, communities and other lawful contributors; and standards discipline is held by NXS-NSF \[1]. Technology support under the applicable agreements confers no control over institutional governance, research, publications, national priorities or customer, sovereign and community data \[3]. Foundry does not own the public-good stack merely because it can implement it. It does not own a GCRI method because it packages it. It does not own a public-safe reporting rule because it uses it. It does not own a GRA finance-readiness mapping because it embeds it in an evidence product. It does not become the exclusive gateway to Nexus standards. It is the professional realization layer that makes selected components deployable when a customer, public authority, National Consortium Company, Project SPV, host, sponsor, or enterprise implementation chooses a full supported path. This is a foundational boundary. Foundry operationalizes the public-good universe. It does not monopolize it. *** ## 4.7 Public-Good Standards First, Enterprise Implementation Second Foundry must preserve the order of the Nexus model: **public-good standards first; enterprise implementation second.** The public-good stack must be modular, non-exclusive, broadly usable, independently governed, licensable, and auditable. It must not be trapped inside one enterprise company, one marketplace, one runtime, one cloud provider, one hardware bundle, one sponsor program, one donor initiative, or one national implementation. This matters because public-good trust depends on non-exclusivity. A country should be able to adopt GCRI technical methods on infrastructure under its own national control. A city should be able to use public-safe reporting templates without procuring a Foundry runtime. A bank should be able to use GRA finance-readiness mappings inside its own risk architecture. A university should be able to contribute to GCRI Digital Public Goods. A community should be able to use the programme's safeguard and correction pathways; the scientific correction route is "Open to anyone, without membership" \[5]. An OEM should be able to verify hardware against published GCRI technical profiles; verification is not certification \[2]. A cloud provider should be able to host compatible packages without owning Nexus standards. A telecom provider should be able to support AI-RAN, O-RAN, private wireless, and edge observability without acquiring control of the architecture. A National Consortium Company or Project SPV may license selected components for execution. Foundry wins not by enclosing the public-good stack, but by implementing it better. *** ## 4.8 Implementation Excellence as the Foundry Advantage Foundry’s competitive advantage is implementation excellence, not exclusivity. A closed model may appear strong because it controls access. But in public-good, sovereign, scientific, emergency, finance, infrastructure, and community contexts, excessive exclusivity reduces trust. It can create procurement concerns, discourage university contribution, weaken open-source participation, trigger sovereign hesitation, create sponsor-capture concerns, and make partners view the system as a closed channel rather than a common rail. Foundry should win because it delivers superior: * integration; * reliability; * user experience; * evidence quality; * proof discipline; * public-safe review; * finance readability; * partner orchestration; * legal robustness; * security; * support; * training; * marketplace packaging; * sovereign adaptation; * data governance; * customer success; * lifecycle renewal; * and operational reliability. This creates a stronger strategic position than lock-in. The public-good stack expands the market. Foundry becomes the best way to implement it professionally. *** ## 4.9 Deployment Unit Doctrine Foundry replaces isolated projects with repeatable deployment units. A deployment unit is not merely: * a consulting report; * a dashboard; * a hardware shipment; * a cloud setup; * an IoT installation; * a GIS layer; * an AI workflow; * a sensor package; * a telecom integration; * a slide deck; * a pilot demonstration; * or a one-time data feed. A deployment unit is a bounded, documented, versioned, licensable, supportable, verifiable, evidence-producing, proof-linked, legally governed, and commercially sustainable package. A deployment unit should identify, as applicable: * blueprint; * rail class; * domain pack; * node profile; * runtime package; * golden image; * edge orchestration pattern; * cloud or sovereign deployment pattern; * data connectors; * EO/GIS workflows; * AI workflows; * sensor integrations; * telecom-edge integrations; * dashboards; * NXS-STU workflows; * evidence products; * proof records; * public-safe output rules; * finance-readable mappings; * training requirements; * support obligations; * verification status; * pricing objects; * license terms; * Registry references; * Bill of Materials; * Evidence Passport; * IP records; * renewal rules; * correction rules; * and decommissioning plan. This doctrine is how Foundry turns delivery into infrastructure. *** ## 4.10 Deployment-to-Asset Conversion Every Foundry implementation should be treated as a production event. Every pilot should become a validation event. Every deployment should become: * an evidence event; * proof event; * support event; * verification event; * learning event; * revenue event; * lifecycle event; * IP-harvest event; * and public-good sustainability event where applicable. No deployment should close without a deployment-to-asset review. That review should ask: * What blueprint was validated? * What connector can be reused? * What schema needs improvement? * What workflow became repeatable? * What evidence template was created? * What proof object was generated? * What public-safe rule was tested? * What finance-readable mapping was used? * What training asset was produced? * What support burden was discovered? * What data-rights issue emerged? * What Marketplace object could be created? * What public-good component requires sustainability support? * What correction was needed? * What should be retired, narrowed, or upgraded? Deployment-to-asset conversion prevents the pilot trap. It makes implementation cumulative. *** ## 4.11 The Pilot Trap and Foundry’s Corrective Function Without Foundry, Nexus risks accumulating the familiar debris of complex innovation ecosystems: * bespoke pilots; * fragmented dashboards; * unmaintained open-source tools; * undocumented methods; * unclear data rights; * unsupported sensor deployments; * unpriced support obligations; * weak public claims; * unprotected IP; * unreusable customer-specific builds; * fragile partner arrangements; * stale public dashboards; * unclear verification status; * and finance-readable artifacts without maintenance. Foundry corrects this pattern. It requires each implementation to be designed from the beginning as a candidate for reuse, support, verification, licensing, renewal, evidence generation, proof audit, public-safe review, finance readability, Marketplace listing, and long-term improvement. The goal is not more pilots. The goal is reusable operational capacity. *** ## 4.12 Rails in Foundry Foundry is where rails are authored and prepared. A rail is a governed deployment of Nexus logic for a defined domain, geography, institution, infrastructure, corridor, public authority learning pathway, or operational use case. Foundry may prepare rails for: * water; * energy; * food; * health; * biodiversity; * disaster risk intelligence; * disaster risk finance; * climate adaptation; * infrastructure resilience; * cities; * ports; * logistics corridors; * industrial systems; * public authority learning; * compute under national control; * observatory networks; * community science; * finance-readable readiness; * and national or regional deployment. A rail should not be improvised directly in production. It should be designed, tested, documented, configured, and released through Foundry before it becomes an NXS-STU runtime or operational deployment. *** ## 4.13 Packs in Foundry Foundry is the primary environment for pack creation. A pack is a modular bundle of domain-specific or rail-specific components. A pack may include: * ontology; * schemas; * indicators; * indices; * playbooks; * dashboards; * connectors; * data models; * simulation modules; * governance patterns; * public-safe templates; * evidence templates; * proof templates; * conformance targets; * finance-readable mappings; * support rules; * and implementation guidance. Foundry governs the build life of a pack. NXS-STU governs the runtime life of a pack. Marketplace governs its discovery and distribution where listed. Registry governs its status where material. Protocol governs access and entitlement where applicable. A pack is not deployment by itself. A pack is not conformance unless reviewed. A pack is not public authority adoption. A pack is not finance execution. A pack becomes usable because Foundry gives it structure. *** ## 4.14 Ontology and Schema Governance in Foundry Foundry must remain subordinate to ontology and schema governance. This is essential because build environments can easily become sources of semantic drift. Foundry may include tools for: * controlled vocabulary authoring; * taxonomy extension; * schema generation; * data dictionary management; * profile compilation; * mapping across domains; * API structure; * metadata rules; * event models; * evidence record structures; * proof record structures; * public-safe labels; * node status structures; * Marketplace object metadata; * and finance-readable evidence fields. But Foundry cannot create uncontrolled meanings. Ontology changes must follow proper governance. Schema extensions must be versioned. Local adaptations must remain mapped to the common rail. Runtime semantics in NXS-STU must inherit governed structures from Foundry. This prevents local deployments from becoming semantically incompatible. *** ## 4.15 Foundry and NXOSI Foundry is one of the main environments through which NXOSI becomes operational. NXOSI organizes observability, obligation attachment, profile compilation, checks, evidence, proof, routing, correction, and learning into one operational standards infrastructure. Foundry corresponds to the authoring, profile, policy, package, test, and release side of this sequence. It may support: * observability design; * profile compilation; * obligation mapping; * check definition; * evidence template creation; * proof method implementation; * routing logic; * correction triggers; * output templates; * and learning loops. NXS-STU carries runtime interaction. Foundry prepares the logic that NXS-STU runs. Together they make NXOSI usable. *** ## 4.16 Simulation and Testing Before Deployment Foundry must support simulation and testing before deployment. Nexus operates in high-consequence environments. Failure can affect public trust, public authority learning, community safety, infrastructure interpretation, finance readability, sponsor accountability, and institutional credibility. Rails, packs, policies, playbooks, agents, connectors, dashboards, workflows, and evidence products should not move into live environments without testing. Testing may include: * schema validation; * data quality tests; * connector tests; * model evaluation; * AI safety tests; * public-safe output tests; * evidence completeness checks; * proof completeness checks; * cyber/privacy checks; * degraded-mode tests; * accessibility checks; * localization tests; * permission and entitlement tests; * no-bypass tests; * supportability tests; * finance-boundary tests; * and user acceptance testing. Simulation is not optional polish. It is responsible realization. *** ## 4.17 Foundry and Evidence Products Foundry prepares evidence products. An evidence product may include structured evidence about: * risk; * exposure; * resilience; * adaptation; * infrastructure readiness; * node status; * observatory output; * domain baseline; * public authority learning; * project readiness; * sponsor-supported capacity; * community safeguards; * public-good sustainability; * or event context. Evidence products should be designed with: * source standing; * data rights; * provenance; * custody; * quality; * confidence; * uncertainty; * method version; * review status; * proof linkage; * public-safe classification; * finance-readable status where applicable; * correction pathway; * and withdrawal rules. Foundry converts evidence methods into operational evidence products. It does not make evidence consequence-bearing beyond scope. *** ## 4.18 Foundry and Proof Records Foundry should support proof records. Proof records may include: * proof of source; * proof of rights; * proof of custody; * proof of calibration; * proof of coverage; * proof of service; * proof of review; * proof of support; * proof of publication; * proof of correction; * proof of interoperability; * proof of conformance; * proof of package composition; * proof of node status; * proof of public-safe review; * and proof of finance-readable mapping. Proof improves trust, but proof is not authority by itself. A proof record can show what was run, reviewed, signed, calibrated, supported, or corrected. It does not replace governance, recognition, public authority, finance decision-making, or lawful execution. Foundry must preserve that boundary. *** ## 4.19 Evidence Passports Foundry should support **Evidence Passports** where appropriate. An Evidence Passport is a structured record package that helps a deployment, node, evidence product, Marketplace object, public-safe output, finance-readable pack, or operational package explain its evidence basis and lifecycle state. An Evidence Passport may include: * subject identity; * component identity; * source records; * data rights; * methods used; * evidence class; * proof records; * confidence; * uncertainty; * public-safe status; * finance-readable mapping where applicable; * Registry references; * conformance references; * recognition references where applicable; * support status; * correction history; * renewal date; * and decommissioning status. Evidence Passports help prevent undocumented claims. They make evidence portable without making it unlimited. *** ## 4.20 Bills of Materials Foundry should maintain Bills of Materials for material packages and deployment units. A Bill of Materials may identify: * public-good components; * open-source components; * proprietary components; * partner components; * data sources; * models; * connectors; * dashboards; * hardware components; * cloud components or compute components under national control; * telecom or edge components; * GCRI components; * GRF components; * GRA components; * licenses; * support obligations; * version numbers; * vulnerabilities; * dependencies; * public-safe review status; * finance mappings; * verification status; * and retirement conditions. The Bill of Materials makes component use visible. It prevents public-good assets from being invisibly absorbed into enterprise delivery. It also allows maintenance, renewal, support, security, licensing, and Revenue Waterfall obligations to be tracked. *** ## 4.21 Foundry and verification (not certification) Earlier text described production certification processes here. Foundry does not certify: "Verification is not certification" \[2]. What Foundry functions may operate is production verification, recorded as evidence by NXS-FAC and the Evidence and Receipt Fabric \[1]\[6]. Production verification is different from technical conformance, a recognition decision, finance readiness, public authority approval, and legal compliance. A package may satisfy a GCRI technical profile and still not be production-ready. A package may have passed public-safe review and still not be operationally supported. A package may carry a GRA finance-readiness mapping and still not be suitable for deployment. Foundry production verification may assess: * package completeness; * runtime readiness; * support model; * security posture; * license completeness; * data-rights documentation; * Evidence Passport completeness; * Bill of Materials completeness; * Marketplace readiness; * public-safe workflow readiness; * finance-boundary language where applicable; * customer acceptance; * renewal requirements; * support obligations; * decommissioning plan; * and lifecycle management. Where a review fee is ever recorded, it may fund review. It does not buy verification outcomes. Verification must remain criteria-based, record-based, scoped, renewable, suspendable, and withdrawable. No verification fee schedule is recorded. *** ## 4.22 Foundry and Licensing Foundry depends on licensing discipline. Every material component should have its own license status. This may include: * GCRI schemas; * GCRI technical methods; * GCRI Digital Public Goods; * public-safe templates; * GRA finance-readiness mappings; * GRA evidence mappings; * Foundry runtime components; * Observatory modules; * NXS-STU workflows; * partner connectors; * data products; * Marketplace objects; * training modules; * support services; * and public-safe outputs. Licenses should state: * owner or steward; * version; * permitted use; * prohibited use; * support status; * modification rights; * attribution rules; * commercial-use terms; * public/private status; * renewal terms; * termination rights; * correction obligations; * public claims limits; * and what the license does not grant. Licensing one component should not automatically license all others. No implied bundle should exist. No executed licence for any component listed above is recorded. The rights in each component are tracked in the Rights Control Plane, whose boundary is that "Rights metadata constrains use but does not create rights that do not exist" \[6]. *** ## 4.23 Foundry and Open Rails / Protected Engines Foundry must preserve the **open rails / protected engines** doctrine. Open rails enable ecosystem adoption. Protected engines enable sustainable execution. Open rails may include: * shared schemas; * public-good standards; * controlled vocabularies; * reference models; * selected APIs; * Digital Public Goods; * public-safe templates; * public authority learning materials; * basic conformance profiles; * and interoperability mappings. Protected engines may include: * production runtime; * managed services; * premium proof automation; * advanced evidence generation; * commercial dashboards; * private connectors; * customer-specific workflows; * deployment recipes; * marketplace logic; * pricing logic; * entitlement systems; * support systems; * customer-success operations; * and trade secrets. The two must coexist without collapse. Enterprise protection must not enclose public-good assets. Public-good openness must not require surrender of legitimate enterprise IP. Foundry is where this balance becomes operational. *** ## 4.24 Foundry and Marketplace Foundry prepares objects for Marketplace. Marketplace is the governed discovery and extension layer. Foundry is where many Marketplace objects are authored, tested, packaged, documented, verified, and prepared for listing. Marketplace objects may include: * apps; * connectors; * packs; * dashboards; * agents; * swarms; * observatory patterns; * services; * Digital Public Goods; * training offerings; * implementation packages; * evidence products; * proof audits; * and partner services. Foundry should ensure that Marketplace objects carry: * object class; * version; * steward or provider; * support status; * verification status where applicable; * conformance posture; * public-safe status; * finance-readable status where applicable; * license terms; * permitted claims; * prohibited claims; * lifecycle status; * dependency records; * and delisting rules. Marketplace listing is not recognition by default. Foundry packaging is not public authority approval. Marketplace visibility is not procurement preference. While the release hold is active, the marketplace deployment profile is blocked \[4]. *** ## 4.25 Foundry and Digital Public Goods Foundry may package Digital Public Goods, but it must not convert public-good openness into enterprise enclosure. Digital Public Goods may include: * open-source software; * schemas; * datasets; * public-good APIs; * models; * documentation; * reference implementations; * validators; * public-safe templates; * and training materials. Foundry can add value through: * integration; * support; * hosting; * verification preparation; * managed services; * customer-specific configuration; * security review; * documentation; * Marketplace packaging; * and lifecycle support. But it must preserve: * license obligations; * attribution; * maintainer records; * release status; * security procedures; * contribution rules; * public-good independence; * and sustainability funding. Open-source availability does not imply production support. Enterprise packaging does not erase open-source status. A component is a digital public good only when it is listed in the Digital Public Goods Registry or meets the Digital Public Goods Standard with a recorded licence decision; no Nexus component is cited here as listed \[13]\[14]. *** ## 4.26 Foundry and Public-Good Sustainability Foundry is a public-good sustainability bridge. Public-good components require maintenance, security, documentation, public-safe review, correction, accessibility, training, translation, registry support, finance mapping, and decommissioning capacity. The sustainability doctrine states that public-good infrastructure should be treated as infrastructure rather than as temporary pilots, grant deliverables, or unfunded public relations assets. Foundry should make public-good component use visible through: * Bills of Materials; * Evidence Passports; * license schedules; * price objects; * Revenue Waterfall records; * maintenance allocations; * public-good reserve contributions; * open-source support contributions; * public-safe review fees; * registry fees; * finance mapping fees; * correction reserves; * and decommissioning reserves. Foundry should not extract public-good value invisibly. Enterprise implementation should help sustain the public-good stack it uses. None of the fees, reserves or contributions listed above is recorded; they are design proposals. Contribution payments open only when their service team, terms and review capacity are in place \[5]. *** ## 4.27 Foundry and Revenue Waterfall Foundry should support a documented Revenue Waterfall. A Revenue Waterfall allocates revenue across the components and actors involved in a package or deployment. Allocations may support: * Foundry runtime; * NXS-STU environments; * observatory modules (functions of NXS-OPS and of [NXS-GRX](/organization/systems/nxs-grx.md), the global data and risk intelligence engine); * GCRI technical standards; * GCRI Digital Public Goods; * GCRI conformance support; * public-safe review; * claims discipline; * GRA finance-readiness mappings; * GRA finance-readiness evidence frameworks; * public-good reserves; * open-source maintenance; * partners; * data providers; * cloud providers; * OEMs; * telecom providers; * local implementers; * National Consortium Companies; * Project SPVs; * support reserves; * correction reserves; * and Marketplace operators. Revenue allocation supports stewardship and execution. It does not buy recognition, conformance, public-safe approval, finance mapping, certification, public authority approval, or community endorsement. No Revenue Waterfall, allocation or payment to any institution is recorded; the waterfall is a design proposal \[3]\[9]. *** ## 4.28 Foundry and Enterprise Sustainability Foundry is central to enterprise sustainability. Enterprise sustainability means that Nexus-aligned implementation vehicles can generate recurring, diversified, legally documented, supportable, and scalable revenue through deployment, runtime, support, managed services, evidence products, proof audits, verification operations, training, Marketplace packages, partner channels, renewals, customer success, sector programs, sovereign support, National Consortium Companies, Project SPVs, and qualified implementation services. Foundry supports this by converting repeated work into: * products; * blueprints; * packages; * support tiers; * verification pathways; * marketplace listings; * training programs; * partner enablement; * managed services; * and renewal objects. This prevents the bespoke consulting trap. It also creates recurring support capacity. Enterprise revenue should strengthen the public-good ecosystem without capturing it. *** ## 4.29 Foundry and Arm’s-Length Enterprise Vehicles Foundry may be used by or connected to arm’s-length enterprise vehicles. These may include: * technology development and infrastructure operation arrangements under the applicable agreements \[3]; * other operating entities named in executed agreements; * National Consortium Companies; * National SPVs; * Project SPVs; * OEM partners; * cloud partners; * telecom partners; * systems integrators; * managed-service providers; * Marketplace operators; * and qualified enterprise providers. These actors may deploy, host, support, sell, renew, integrate, and commercialize operational capacity under written agreements. But they do not own the public-good stack by default. They should operate through: * licenses; * services agreements; * partner agreements; * data schedules; * IP schedules; * support schedules; * public-safe schedules; * finance-interface schedules; * verification schedules; * jurisdictional annexes; * Revenue Waterfall records; * and conflict controls. Enterprise execution is necessary. Enterprise capture is prohibited. *** ## 4.30 Foundry and National Consortium Companies / Project SPVs {% hint style="warning" %} **Finance boundary.** National Consortium Companies and Project SPVs are formed, if at all, by competent lawful actors outside the programme, under their own law and licences. The programme prepares evidence, standards and readiness; it never forms, arranges, owns or advises on a vehicle or a transaction. See [Lawful handoffs](/organization/finance-readiness/lawful-handoffs.md). {% endhint %} Foundry may support national and project-level execution structures. A **National Consortium Company** may use Foundry packages, deployment units, Marketplace objects, NXS-STU environments, support systems, training, and evidence products to support lawful national implementation. A **Project SPV** may use Foundry-produced deployment units, data rooms, evidence products, proof records, finance-readable packs, support schedules, and project-specific configurations. But the boundaries remain strict. A National Consortium Company is not the [National Nexus Consortium](/organization/governance-in-operation/nnc.md). A Project SPV is not Nexus. A Project SPV data room is not public-good Registry. A Foundry package does not create finance execution. A project evidence pack is not investment advice. A deployment unit is not public authority approval. Foundry enables execution-capable structures. It does not erase the public-good / enterprise stack distinction. *** ## 4.31 Foundry and Qualified Enterprise Providers Foundry should support a governed provider ecosystem. Qualified enterprise providers may help build, configure, deploy, support, localize, maintain, or extend Foundry packages. They may include: * systems integrators; * cloud providers; * OEMs; * telecom providers; * AI providers; * EO/GIS providers; * sensor providers; * cybersecurity firms; * data providers; * industrial technology companies; * local implementation partners; * university-linked implementation labs; * and managed service providers. Provider participation should be governed by: * qualification scope; * verification status; * support obligations; * data rights; * confidentiality; * public-safe rules; * finance-boundary rules; * claims guidance; * partner agreements; * audit rights; * suspension rights; * and conflict controls. A provider is not standards authority by implementation gravity. A provider does not self-certify. A provider listing is not procurement approval. Foundry extends through providers without surrendering control to them. *** ## 4.32 Foundry and AI Agents Foundry may author, test, package, and govern AI agents. AI agents may support: * data ingestion; * semantic classification; * evidence preparation; * report drafting; * NXS-STU assistance; * dashboard explanation; * workflow routing; * public-safe summarization; * Marketplace support; * training; * code generation; * simulation; * and finance-readable evidence preparation. AI agents must be governed by: * role boundaries; * source grounding; * data permissions; * tool permissions; * ontology; * retrieval controls; * audit logs; * review requirements; * public-safe constraints; * correction pathways; * and revocation. An AI agent does not create recognition. It does not issue public warnings. It does not approve finance. It does not certify conformance. It does not create lawful decisions. Foundry makes AI useful by making it governed. *** ## 4.33 Foundry and Sovereign Adaptation Foundry must support sovereign adaptation. A deployment unit may need to be localized for: * domestic lawful basis; * data residency; * public authority capacity; * language; * accessibility; * public records obligations; * emergency law; * procurement-neutral specification; * privacy law; * cyber requirements; * public health law; * environmental law; * Indigenous or community safeguards; * national standards; * finance-market context; * and host infrastructure. Foundry should support sovereign profiles, national annexes, jurisdictional configuration, local data rights, public authority learning modes, and domestic hosting options. Sovereign adaptation must not become uncontrolled fork. A national profile should remain mapped to the common rail. A local adaptation should remain versioned. A sovereign deployment should preserve role separation. *** ## 4.34 Foundry and Regional Adaptation Foundry must also support regional adaptation. Regional conditions may include: * corridor systems; * basin systems; * shared ecologies; * multicountry logistics; * language families; * regional standards; * cross-border data sensitivities; * regional public authority coordination; * regional finance ecosystems; * and support-versus-comparable classification. Foundry can help produce regional templates, corridor packs, regional node profiles, cross-border observatory packages, and regional Marketplace objects. But regional adaptation must preserve national primacy. A regional pack is not regional supremacy. A corridor rail is not supranational authority. A regional deployment unit is not domestic lawful basis. Foundry supports federation by making adaptation structured rather than improvised. *** ## 4.35 Foundry and Public Authority Learning Foundry may prepare public authority learning environments. These may include: * controlled dashboards; * simulation exercises; * preparedness workflows; * public-safe reports; * training packs; * jurisdictional annexes; * evidence products; * public warning boundary notes; * procurement-neutral guides; * emergency-readiness exercises; * and decision-support preparation environments. Public authority learning is not public authority adoption by default. A public authority workshop is not official approval. A training dashboard is not emergency command. A simulation is not public warning. Foundry must build public authority learning packages with authority-boundary language, public-safe discipline, data controls, and lawful handoff rules. *** ## 4.36 Foundry and Finance-Readable Readiness Foundry may package finance-readable evidence products. These may include: * resilience-finance evidence packs; * disaster-risk-finance evidence packs; * adaptation-finance evidence packs; * receiving-institution maps (earlier text: sponsor-capital reports); * project-readiness packs; * portfolio observability dashboards; * readiness rooms whose evidence competent actors may use when they consider a Project SPV outside the programme; * finance-reader data rooms; * and risk translation products. These may use GRA finance-readiness mappings, reliance language, and finance-boundary rules. But finance-readable readiness is not finance execution. A finance-readable pack is not investment advice. A readiness dashboard is not underwriting. A Project SPV room is not a securities offering. An evidence product is not a credit rating. Foundry must make finance-readable outputs useful while preserving regulated-finance boundaries. *** ## 4.37 Foundry and Public-Safe Production Foundry must integrate public-safe production rules. Many Foundry outputs may eventually become public or public-facing: * dashboards; * maps; * summaries; * reports; * Marketplace pages; * case studies; * sponsor reports; * community outputs; * node status cards; * public authority learning summaries; * Academy materials; * media objects; * and public-safe data products. Public-safe production should address: * audience; * sensitivity; * protected knowledge; * sensitive geography; * public authority boundaries; * finance boundaries; * sponsor no-control; * community safeguards; * uncertainty; * confidence; * limitations; * accessibility; * translation; * correction; * withdrawal; * and public claims. Foundry should not release public-facing artifacts without public-safe classification where required. *** ## 4.38 Foundry and Community Safeguards Foundry may package tools and workflows that operate near communities, local knowledge, sensitive ecosystems, protected geography, public health, or vulnerable groups. This requires safeguard-by-design. Foundry packages should account for: * consent where required; * protected knowledge; * Indigenous and local knowledge safeguards; * sensitive geography controls; * anonymization; * aggregation; * public-safe release; * grievance pathways; * correction rights; * accessibility; * language; * local benefit; * and sponsor no-control. A technically excellent package can still fail if it extracts or exposes local knowledge irresponsibly. Foundry must make safeguards operational, not rhetorical. *** ## 4.39 Foundry and Support Schedules A Foundry package is not mature unless it is supportable. Support schedules should define: * support owner; * support tier; * service hours; * response times; * escalation paths; * security patch process; * update cadence; * customer responsibilities; * provider responsibilities; * public-safe correction support; * data-rights support; * Marketplace support; * verification support; * renewal support; * and end-of-life support. A package without support status should not be described as production-ready. Support is part of the product. *** ## 4.40 Foundry and Lifecycle Discipline Foundry must govern the full lifecycle of packages and deployment units. Lifecycle states may include: * idea; * concept; * scoped; * design; * prototype; * test; * simulation-ready; * release candidate; * verified; * listed; * active; * supported; * renewed; * corrected; * narrowed; * deprecated; * suspended; * withdrawn; * retired; * archived. Lifecycle status should be visible where relevant. A prototype is not a release. A release candidate is not deployment authorization. A verified package may still be scope-limited. A deprecated package should not appear current. A withdrawn package should not remain installable. Lifecycle discipline is how Foundry prevents false maturity. *** ## 4.41 Foundry and Renewal Foundry must treat renewal as assurance, not only revenue. Renewal may apply to: * runtime licenses; * support contracts; * Marketplace listings; * verification records; * public-safe status; * finance-readable mappings; * Evidence Passports; * Bills of Materials; * data rights; * provider status; * partner status; * training credentials; * and node packages. Renewal should trigger review of: * support status; * data rights; * security status; * open-source dependencies; * public-safe status; * finance-boundary language; * verification scope; * partner obligations; * customer fit; * claims; * and decommissioning needs. Renewal keeps packages alive in truth. *** ## 4.42 Foundry and Decommissioning Foundry must plan for decommissioning. Every deployment unit, public-good node package, dashboard, Marketplace listing, data connector, evidence product, public-safe output, AI agent, NXS-STU workflow, and support package should have an end-of-life path. Decommissioning may include: * customer notice; * public notice where required; * support wind-down; * data return; * data deletion; * archive; * Registry update; * Marketplace delisting; * license termination; * public claim withdrawal; * Evidence Passport update; * Bill of Materials archive; * security review; * and transition to another steward. Decommissioning should not erase accountability. Historical records should remain where appropriate, subject to privacy, security, and public-safe restrictions. *** ## 4.43 Foundry Governance Foundry requires governance. Foundry governance should address: * build authority; * release authority; * package classification; * public-good component use; * licensing; * verification (not certification); * Marketplace listing; * provider participation; * partner channels; * public-safe review; * finance-readable mapping; * data governance; * cybersecurity; * AI-agent controls; * support schedules; * Revenue Waterfall; * Evidence Passports; * Bills of Materials; * customer claims; * renewal; * correction; * suspension; * withdrawal; * and decommissioning. Foundry governance must be role-separated. A provider should not self-certify. A sponsor should not control release status. A customer should not buy recognition. An enterprise sales team should not override public-safe review. A platform administrator should not publish production status without record. Foundry governance makes production trustworthy. *** ## 4.44 Foundry and Records Foundry must be records-valid. Material Foundry actions should create records. These may include: * design records; * test records; * simulation records; * release records; * verification records; * support records; * license records; * data-rights records; * public-safe records; * finance-mapping records; * Marketplace records; * Evidence Passports; * Bills of Materials; * partner records; * customer acceptance records; * correction records; * suspension records; * withdrawal records; * renewal records; * and decommissioning records. Foundry should not govern by informal memory. A deployment unit becomes trustworthy because its composition, status, support, and limits are recorded. *** ## 4.45 Foundry and Claims Discipline Foundry must enforce claims discipline. A package may not be described as more mature than its record. A prototype may not be described as deployed. A Marketplace listing may not be described as certified. A public-safe candidate may not be described as public-safe issued. A finance-readable pack may not be described as investment-grade. A component verified against a GCRI technical profile may not be described as recognized or certified by any institution. A public-good output that passed public-safe review may not be described as certified. A GRA-mapped evidence product may not be described as finance-approved. A public authority learning package may not be described as public authority adoption. Foundry should attach permitted and prohibited claims to packages, deployment units, verification records, Marketplace pages, customer materials, sponsor reports, and partner channels. *** ## 4.46 Foundry Failure Modes Nexus should be explicit about Foundry failure modes. **Pilot trap** occurs when deployments remain bespoke and never become reusable assets. **Build-runtime collapse** occurs when design work is performed directly in production without governance. **Enterprise enclosure** occurs when public-good components are absorbed into commercial packages without licensing, attribution, or sustainability support. **Public-good extraction** occurs when enterprise implementations rely on nonprofit standards, open-source tools, registries, public-safe review, or finance mappings without funding their maintenance. **Certification inflation** occurs when certification language is used at all, or when verification language exceeds recorded scope. **Marketplace overclaim** occurs when listing becomes implied endorsement. **Provider capture** occurs when providers use implementation centrality to shape standards or claims. **Sponsor capture** occurs when sponsors influence evidence, release status, public-safe outputs, or recognition. **Support underpricing** occurs when packages are sold without funding maintenance and customer support. **Bespoke consulting trap** occurs when revenue depends on custom delivery rather than productized deployment units. **Semantic drift** occurs when local builds fork ontology or schema meaning. **Finance overclaim** occurs when finance-readable packs imply investment, underwriting, insurance, rating, or capital commitment. **Public authority overclaim** occurs when learning packages are described as official adoption or decision authority. **Lifecycle failure** occurs when packages cannot be renewed, corrected, deprecated, or decommissioned. Foundry exists to prevent these failures. *** ## 4.47 Strategic Value of Foundry The strategic value of Foundry is that it makes Nexus repeatable, deployable, supportable, and sustainable. Foundry allows Nexus to: * convert standards into interfaces; * convert methods into workflows; * convert Digital Public Goods into maintained packages; * convert observatory logic into node profiles; * convert Edge lessons into improved packs; * convert NXS-STU workflows into governed runtime objects; * convert evidence methods into evidence products; * convert proof methods into proof records; * convert public-safe rules into publication workflows; * convert finance mappings into finance-readable packs; * convert pilots into deployment units; * convert deployments into assets; * convert public-good components into sustainable enterprise packages; * and convert implementation experience into ecosystem memory. In strategic terms, Foundry is the production intelligence layer of Nexus. It is where build discipline, enterprise sustainability, public-good sustainability, standards discipline, and lifecycle governance meet. *** ## 4.48 Final statement on the Foundry pillar The Foundry pillar, in the sense used in this chapter, is the governed build, production, packaging, verification, licensing, evidence, proof, support, Marketplace, and lifecycle architecture through which Nexus becomes repeatable operational capacity. It is where rails are authored, packs are assembled, ontologies are implemented, schemas are validated, agents are configured, connectors are built, dashboards are prepared, evidence products are structured, proof records are generated, public-safe templates are embedded, finance-readable mappings are packaged, sovereign profiles are localized, Marketplace objects are prepared, and deployment units are made supportable. In the sense used in this chapter, Foundry is not the whole Nexus universe. In the institutional records the technical architecture is the twenty Nexus systems; this chapter's "Foundry" is the build, packaging and lifecycle work of the Foundry pillar \[3]. It does not own The Global Centre for Risk and Innovation (GCRI). It does not own The Global Risks Forum (GRF). It does not own The Global Risks Alliance (GRA). It does not own the public-good stack. It does not make itself the exclusive gateway to standards. It does not turn public-good components into commercial property by packaging them. It does not create public authority approval. It does not execute finance. It does not certify. It does not allow sponsors, providers, customers, or enterprise teams to buy public-good determinations. Foundry operationalizes. It does not monopolize. It wins through implementation excellence, not enclosure. Through Foundry, Nexus escapes the pilot trap. It becomes capable of converting public-good standards, Digital Public Goods, scientific methods, observability, evidence, proof, public-safe reporting, finance-readable mappings, domain packs, sovereign profiles, partner components, NXS-STU workflows, Marketplace objects, and deployment patterns into real, supported, renewable, correction-capable, and commercially sustainable systems. Foundry is the production layer that lets Nexus become infrastructure without losing its public-good soul. *** ## Next steps Read **V. Programs** to understand the Academy, accelerator, simulation, capability, training, adoption, and institutional-readiness pathways that make Foundry-built systems usable by people and organizations. Read **VI. Marketplace** to understand how Foundry packages, connectors, apps, agents, dashboards, services, Digital Public Goods, providers, and deployment units become discoverable under governed rules. Read **II. Compute** to understand the technical estate intended for national control within which Foundry-built packages and NXS-STU runtime environments operate. Read **III. Edge** to understand the observatory and field-intelligence layer whose signals and lessons feed Foundry design. Read **VII. Consortiums** to understand how Foundry deployment units move into national, regional, company, and Project SPV pathways. The company and SPV steps are taken, if at all, by competent actors outside the programme. Read **VIII. Campaign** to understand the activation horizon to 2030, stated as targets with no implementation record. *** ## Build to install: the Foundry lifecycle in canonical systems Figure 1 shows the path a capability is designed to take from blueprint to installation and retirement, with the gates that stop it. It is a design of the sequence; no package is recorded as having completed it.
The Foundry lifecycle from blueprint to installation. An NXS-FAC blueprint passes verification and signing, becomes an NXS-NXQ package with rights data from the Rights Control Plane, passes the NXS-NSF policy and release gate and the release-hold profile gates, and is then installed by NXS-APP and composed in NXS-STU. Verification and installation write receipts to the Evidence and Receipt Fabric.

Figure 1. The Foundry lifecycle as a division of canonical systems and fabrics. Target architecture; the release hold is in force and blocks marketplace, sovereign and other profiles. Source: D-V3-0003, D-V3-0001 and the release hold policy [1][4][6], as of 2026-10-16.

Text description of Figure 1 A blueprint in NXS-FAC passes verification and signing, then becomes a package with entitlements in NXS-NXQ; the Rights Control Plane supplies the bill of materials and licence data. The package passes an NXS-NSF policy and release decision and then the release-hold profile gates. Only then can NXS-APP install, upgrade or retire it, and NXS-STU compose it for use. Verification and installation write receipts to the Evidence and Receipt Fabric. NXS-APP can recall or deprecate a package back to NXS-NXQ; the figure records this on the install and package cards rather than as a return arrow.
Two external practices shape the verification step. The NIST Secure Software Development Framework sets out practices for producing well-secured software \[10], and the SLSA framework defines supply-chain integrity levels for build provenance \[11]. The NTIA minimum elements for a software bill of materials \[12] and ISO/IEC 5962 (SPDX) \[16] describe what a bill of materials records; section 4.20 follows the same idea and extends it to data, models and public-good components. These are references, not compliance claims. ## Verification, attestation and certification ISO/IEC 17000 separates confirmation activities: verification confirms that specified requirements are fulfilled, while certification is a third-party attestation by a certification body \[15]. The draft Nexus Standards vocabulary distinguishes three conformance states: verified (computed), attested (signed) and recognized (an NXS-NSF recognition decision), and only the verified state is computable today \[9]. A verifiable credential, in the W3C sense, can carry a signed statement about a subject \[17], but signing a statement does not turn it into a certificate. *Table 1. What Foundry may and may not say about a package. Sources: D-V3-0004 \[2]; the Nexus Documentation Standard \[9]; ISO/IEC 17000 \[15].* | State | Meaning | May Foundry produce it? | Wording to use | | ---------- | ------------------------------------------------------------------- | ------------------------------------------------- | ---------------------------------- | | Verified | A computed check against a stated profile, version and scope passed | Yes, with an evidence receipt | "Verified against for on " | | Attested | A signed statement by a named party | Only where an executed agreement names the signer | "Attested by ; not a certificate" | | Recognized | An NXS-NSF recognition decision | No; Foundry is not NXS-NSF | "No recognition decision recorded" | | Certified | Third-party certification by a certification body | No; Nexus issues no certificate | Not used | **Foundry rule ACC-IV-1.** No package, deployment unit or Marketplace object SHALL be described as certified, accredited or badged; verification statements SHALL name the profile, version, scope and date (source: D-V3-0004 "Verification is not certification" \[2]; the Nexus Documentation Standard \[9]). **Foundry rule ACC-IV-2.** No component SHALL be listed, licensed or allocated revenue without a rights record naming its lawful rights holder; where title is unverified, the component carries that status (source: platform ownership and commercial channel notices \[3]; Rights Control Plane boundary \[6]). ## What Foundry is not * It is not a certification body, and its outputs are not certificates, badges or accreditations \[2]\[9]. * It is not the owner of public-good components it packages, and it is not the owner of GCRI, GRF or GRA \[3]. * It is not a licence. "No executed assignment or licence is established" by the platform ownership notice \[3]. * It is not a release. While the release hold is active, only internal development, pull-request preview, isolated test and non-certified research profiles are permitted \[4]. * It is not the runtime. NXS-STU composes and the Universal Runtime executes; "Runtime executes authorized intent. It does not grant purpose, legal authority, scientific validity or entitlement" \[6]. * It is not a channel for buying outcomes. "No support buys appointments, findings, consent or procurement advantage" \[5]. ## International context (alignment, not endorsement) * **Secure development and supply chain.** NIST SP 800-218 (SSDF) \[10], SLSA \[11] and the NTIA SBOM minimum elements \[12] are widely used references for build integrity and component transparency. * **Digital public goods.** The Digital Public Goods Standard \[13] and Registry \[14] are the external test for calling a component a digital public good. * **Conformity assessment vocabulary.** ISO/IEC 17000 \[15] is the reference for the difference between verification, attestation and certification. * **Trustworthy AI for agents.** The OECD AI Principles \[18] and the NIST AI Risk Management Framework \[19] are references for section 4.32 on AI agents. * **Indigenous and community data.** The CARE Principles for Indigenous Data Governance \[20] are a reference for section 4.38 on community safeguards. Naming these publications implies no partnership, endorsement or conformity. ## Terms used on this page * **Deployment unit.** A documented, supportable, versioned package of configuration, components and support terms that can be reused across deployments (section 4.9). * **Pack.** A modular bundle of domain or deployment components; an NXS-NXQ package in V3 terms. * **Evidence Passport.** A design for a record package that explains the evidence basis and lifecycle state of a deployment or product; in V3 terms close to a Passport Projection, which "is rebuildable from authoritative sources and is not itself the root of truth" \[6]. * **Bill of Materials.** A record of every component in a package with its source, licence, version and obligations. * **Revenue Waterfall.** A design proposal for allocating revenue across the components and actors of a package; no allocation is recorded. * **Open rails and protected engines.** The design doctrine that shared standards stay open or broadly licensable while production services may be commercially protected (section 4.23). ## Related pages * Up: [Acceleration](/organization/introduction/acceleration.md) * Across: [I. Order](/organization/introduction/acceleration/i.-order.md) · [II. Compute](/organization/introduction/acceleration/ii.-compute.md) · [III. Edge](/organization/introduction/acceleration/iii.-edge.md) · [V. Programs](/organization/introduction/acceleration/v.-programs.md) · [VI. Marketplace](/organization/introduction/acceleration/vi.-marketplace.md) · [VII. Consortiums](/organization/introduction/acceleration/vii.-consortiums.md) · [VIII. Campaign](/organization/introduction/acceleration/viii.-campaign.md) * Counterparts: [Systems](/organization/systems.md) · [NXS-FAC](/organization/acceleration/nexus-foundry/xvi.-factory.md) · [Release](/organization/acceleration/nexus-foundry/xiv.-release.md) · [NXS-STU](/organization/acceleration/nexus-studio.md) · [III. Status](/organization/introduction/standardization/iii.-status.md) ## Sources 1. Nexus constitutional directive D-V3-0003, *Canonical Twenty-System Constitution and Authority Matrix* (canonical order, remits, completeness and non-ownership rules). Internal record, cited by identifier. 2. Nexus constitutional directive D-V3-0004, *One Rail-Two Stacks, Non-Execution and Lawful Handoff Constitution* (public-good rail, enterprise and sovereign execution stack, consequential action envelope, boundary formulas). Internal record, cited by identifier. 3. Nexus institutional register, *Nexus institutional architecture and participation*: owner decision of 11 October 2026 on GCRI Canada as lead contracting organization (owner-confirmed; counsel review pending), with the legal entity profile notices on operating structure, the lead contracting organization, consortium stewardship, institutional independence, platform ownership and the commercial channel (owner-confirmed; title and instruments unverified). Internal record. 4. Nexus institutional register: release hold policy (in force since 21 July 2026; permitted profiles internal development, pull-request preview, isolated test and non-certified research; blocked profiles include sovereign, marketplace and certified public-good) and claim register. Internal record. 5. Nexus institutional register, consortium programme: operating functions, conversion chain, programme offerings O01 to O10 with their questions, deliverables, entry routes, boundaries and system mappings, decision rights, service levels R0 to R5, current service level R0, separations and case routes; drawing on the consortium directives D-NEXUS-CONSORTIUM-PUBLIC-ARCHITECTURE-2 and D-NEXUS-CONSORTIUM-STAKEHOLDER-READINESS-3. Internal record. 6. Nexus constitutional directive D-V3-0001, *Master Directive V3* (shared constitutional fabrics and their boundary sentences), and the Native Master legal, IP and open-source constitution (D-NEXUS-NATIVE-MASTER-1). Internal record, cited by identifier; the Native Master is not quoted. 7. Nexus institutional register, consortium geography: six regions and fifteen planned hubs, every hub planned; hubs are coordination roles, not offices. Internal record. 8. Public institutional site draft (not yet adopted; owner direction, not a binding record): controlled vocabulary, council vocabulary NNC, NLC and NWG with the note retiring earlier labels, programme status vocabulary and institutional boundary sentences for GRF and GRA. Draft source. 9. Nexus Documentation Standard, draft of 16 October 2026 (purpose and audiences, authority and status, naming, external frameworks and sources), the owner decisions of 16 October 2026 and the introduction audit of 16 October 2026. Internal editorial records; not published. 10. NIST (2022). *SP 800-218, Secure Software Development Framework (SSDF) Version 1.1*. [csrc.nist.gov](https://csrc.nist.gov/pubs/sp/800/218/final). Accessed 2026-10-16. 11. Open Source Security Foundation. *SLSA: Supply-chain Levels for Software Artifacts*. [slsa.dev](https://slsa.dev/). Accessed 2026-10-16. 12. National Telecommunications and Information Administration (2021). *The Minimum Elements for a Software Bill of Materials (SBOM)*. [ntia.gov](https://www.ntia.gov/report/2021/minimum-elements-software-bill-materials-sbom). Accessed 2026-10-16. 13. Digital Public Goods Alliance. *Digital Public Goods Standard*. [digitalpublicgoods.net](https://www.digitalpublicgoods.net/standard). Accessed 2026-10-16. 14. Digital Public Goods Alliance. *Digital Public Goods Registry*. [digitalpublicgoods.net](https://www.digitalpublicgoods.net/registry). Accessed 2026-10-16. 15. ISO/IEC (2020). *ISO/IEC 17000:2020, Conformity assessment: Vocabulary and general principles*. (URL not verified) 16. ISO/IEC (2021). *ISO/IEC 5962:2021, Information technology: SPDX Specification V2.2.1*. (URL not verified) 17. W3C (2025). *Verifiable Credentials Data Model v2.0*, W3C Recommendation. [w3.org](https://www.w3.org/TR/vc-data-model-2.0/). Accessed 2026-10-16. 18. OECD. *OECD AI Principles* (Recommendation of the Council on Artificial Intelligence). [oecd.ai](https://oecd.ai/en/ai-principles). Accessed 2026-10-16. 19. NIST (2023). *Artificial Intelligence Risk Management Framework (AI RMF 1.0)*. [nist.gov](https://www.nist.gov/itl/ai-risk-management-framework). Accessed 2026-10-16. 20. Carroll, S. R. et al. (2020). The CARE Principles for Indigenous Data Governance. *Data Science Journal*, 19(1), 43. [datascience.codata.org](https://datascience.codata.org/articles/10.5334/dsj-2020-043). Accessed 2026-10-16. 21. GCRI (2026). *How Nexus works*: the six pillars, their eighteen handoffs and the eight-step cycle (Question, Evidence, Build, Organize, Test, Publish, Decide, Renew). [therisk.global/nexus-cycle](https://therisk.global/nexus-cycle/). Read 2026-10-21. 22. The Global Risks Alliance (2026). *Finance and insurance readiness*: readiness evidence is not a financing decision. [globalriskalliance.com/finance-readiness](https://globalriskalliance.com/finance-readiness/). Read 2026-10-21. 23. The Global Risks Alliance (2026). *Lawful handoffs*: readiness evidence is released one to one on the owner's written direction, with no introduction and no pay tied to any transaction. [globalriskalliance.com/finance-readiness/handoff](https://globalriskalliance.com/finance-readiness/handoff/). Read 2026-10-21. 24. GCRI (2026). *Programme status*: Exploration, In formation, Constituted, Active programme, Paused, Closed, Historical record; current service level R0. [therisk.global/consortium/programme-status](https://therisk.global/consortium/programme-status/). Read 2026-10-21. 25. GCRI (2026). *Nexus Reports programme*: quarterly country editions, an annual flagship and specialist series; current approved releases: none. [therisk.global/publications/nexus-reports](https://therisk.global/publications/nexus-reports/). Read 2026-10-21. ## Editorial record * As of: 2026-10-16. Refresh: every 180 days, or sooner when a governing source changes. * Drafting: AI-assisted (an AI agent drafted this revision). Human review: pending; no named reviewer or approver yet. * Corrections: a public corrections route has not yet been published. Corrections will be recorded as new dated versions, not silent edits. * Change: 2026-10-16, upgraded to the documentation standard draft. Record block, In brief, status section and the platform ownership and commercial channel notices added; "source materials" residue rewritten as a sourced statement; "Foundry" reconciled with the Foundry pillar, NXS-FAC, NXS-STU, NXS-NXQ and NXS-APP; every certification statement recast as verification, with the original boundaries kept; a company name removed from the entity list; GRF standing, trust-label and recognition roles removed and GRA wording aligned to the finance-readiness interface; fees, licences and Revenue Waterfall marked as design proposals; lifecycle figure, verification table, rules ACC-IV-1 and ACC-IV-2, external context, terms, sources and related pages added; heading levels corrected; all original sections kept. * Change: 2026-10-16 r2, readable document record and status note; Nexus Standards display codes for systems; system naming; Nexus Observatory Protocol note; ownership and licensing statements rewritten without naming any company; internal paths, commit references and status codes replaced with plain words. * Change: 2026-10-21 r3, brought up to date with the published sites, Nexus Standards and the owner's rulings of October 2026: Where this fits line; a Current position section; Nexus Standards described as published ([NS-0](https://nexustandards.com/standards/ns-0/) to [NS-16](https://nexustandards.com/standards/ns-16/) and [NS-3b](https://nexustandards.com/standards/ns-3b/), NIS-1, 348 NRS in 15 series, all PROPOSED; GCRI Canada publisher of record; governance bodies and adoption modes); the national vocabulary of National Nexus, the NNC with its six [Helix councils](/organization/governance-in-operation/councils.md), the NLC and the NWG; the finance boundary on every vehicle passage; the systems named as systems; all original sections kept. --- # 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/introduction/acceleration/iv.-foundry.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.