# IV. Foundry #### Summary This page defines **Foundry** within Nexus Acceleration. If **II. Compute** defines the sovereign technical estate and **III. Edge** defines the distributed observatory layer through which Nexus becomes locally aware, then **IV. Foundry** defines the controlled build, production, packaging, testing, certification, support, licensing, marketplace, and lifecycle environment through which Nexus capabilities become repeatable operational systems. Nexus Foundry 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. The source materials correctly frame Foundry as both a **design-and-assembly environment** and an **enterprise-grade realization layer**. One source describes Studio and Foundry as the principal environments through which Nexus rails are authored, operated, tested, and evolved, with Studio carrying live runtime and Foundry carrying governed design, assembly, configuration, testing, and production preparation. Another source defines Nexus Foundry as the enterprise production system that converts public-good standards, open-source components, technical frameworks, recognition systems, public-safe reporting rules, finance-readable evidence frameworks, blueprints, sovereign profiles, hardware/software/data configurations, partner capabilities, and institutional components into deployable operational capacity. 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, Studio 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, certifiable, 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, certified, 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 certification 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. Certification must not be bought. Public-safe review must not be bypassed. Finance readability must not become finance execution. Production readiness must not be confused with technical conformance. Studio 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 Studio Foundry and Studio are paired but distinct. **Foundry** is where Nexus capabilities are designed, assembled, tested, packaged, certified, and prepared for controlled release. **Studio** is where approved capabilities run in live or controlled operational settings. The distinction is essential. Foundry is the build authority environment. Studio is the runtime environment. Foundry authors rails. Studio operates rails. Foundry designs packs. Studio runs packs. Foundry tests workflows. Studio uses workflows. Foundry creates release candidates. Studio runs released or authorized versions. Foundry prepares deployment units. Studio 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 Studio together solve that problem. *** ### 4.5 Foundry as Build Authority Environment Foundry is the build authority environment of Nexus. 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; * Studio 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, certified, commercially sustainable operational packages where selected. The public-good stack remains independently stewarded by The Global Centre for Risk and Innovation (GCRI), The Global Risks Forum (GRF), The Global Risks Alliance (GRA), protocol authority, the Global Nexus Consortium, Regional Nexus Consortiums, National Nexus Consortiums, open-source communities, universities, public authorities, communities, and other lawful contributors. 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 GRF public-safe reporting rule because it uses it. It does not own a GRA finance-readable taxonomy 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 sovereign infrastructure. A city should be able to use GRF public-safe reporting templates without procuring a Foundry runtime. A bank should be able to use GRA finance-readable taxonomies inside its own risk architecture. A university should be able to contribute to GCRI Digital Public Goods. A community should be able to use GRF safeguard and correction pathways. An OEM should be able to certify hardware against GCRI profiles. 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, certifiable, 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; * Studio workflows; * evidence products; * proof records; * public-safe output rules; * finance-readable mappings; * training requirements; * support obligations; * certification 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; * certification 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 certification 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, certification, 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; * sovereign compute; * 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 a Studio 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. Studio 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 Studio 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. Studio carries runtime interaction. Foundry prepares the logic that Studio 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; * role-key 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 or sovereign compute components; * telecom or edge components; * GCRI components; * GRF components; * GRA components; * licenses; * support obligations; * version numbers; * vulnerabilities; * dependencies; * public-safe review status; * finance mappings; * certification 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 Certification Foundry may operate production certification processes. Production certification is different from technical conformance, public-good recognition, finance readability, public authority approval, and legal compliance. A package may satisfy a GCRI technical profile and still not be production-ready. A package may have GRF public-safe status and still not be operationally supported. A package may have GRA finance-readable mapping and still not be suitable for deployment. Foundry production certification 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. Certification fees may fund review. They do not buy certification outcomes. Certification must remain criteria-based, record-based, scoped, renewable, suspendable, and withdrawable. *** ### 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; * GRF public-safe templates; * GRF standing frameworks; * GRF trust labels; * GRA finance-readable taxonomies; * GRA evidence mappings; * Foundry runtime components; * Observatory modules; * Studio 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. *** ### 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, certified, 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; * certification 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. *** ### 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; * certification 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. *** ### 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. *** ### 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; * Studio environments; * Nexus Observatory modules; * GCRI technical standards; * GCRI Digital Public Goods; * GCRI conformance support; * GRF public-safe review; * GRF recognition or registry functions; * GRF claims discipline; * GRA finance mappings; * GRA finance-readable 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. *** ### 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, certification 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; * certification 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: * Nexus Observatory Inc.; * Nexus Ecosystem Inc.; * Foundry operating entities; * 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; * certification 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 Foundry may support national and project-level execution structures. A **National Consortium Company** may use Foundry packages, deployment units, Marketplace objects, Studio 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. 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; * certification 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; * Studio 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; * sponsor-capital reports; * project-readiness packs; * portfolio observability dashboards; * Project SPV preparation rooms; * finance-reader data rooms; * and risk translation products. These may use GRA taxonomies, 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; * certification 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; * certified; * 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 certified 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; * certification; * 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; * certification 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, Studio 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; * 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; * certification 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 unless 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 GCRI-conformant component may not be described as GRF-recognized. A GRF-recognized public-good output may not be described as Foundry production-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, certification 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 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 Studio 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 Nexus Foundry Nexus Foundry is the governed build, production, packaging, certification, 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. Foundry is not the whole Nexus universe. 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 beyond record. 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, Studio 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 sovereign technical estate within which Foundry-built packages and Studio 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. --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.therisk.global/organization/introduction/acceleration/iv.-foundry.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.