> 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/cooperation/nexus-guilds/future-of-web/xviii.-ecosystem-interfaces.md). # XVIII. Ecosystem Interfaces GCRI ↔ GRF ↔ GRA ↔ NSF • NXS-RLS Interface • Cross-Domain Interoperability • Sensitive Jurisdictions Posture **Where this fits:** all six sectors ([The Model](/organization/model.md)) · [Labs](/organization/programme/labs.md), [Risk Academy](/organization/programme/academy.md) · communities of practice by sector, supplying the questions of the Labs pillar; National Working Groups ([NWG](/organization/governance-in-operation/nwg.md)) · community of practice. **In brief.** GCRI ↔ GRF ↔ GRA ↔ NSF • [NXS-RLS](/organization/systems/nxs-rls.md) Interface • Cross-Domain Interoperability • Sensitive Jurisdictions Posture Read against the international frameworks it serves ([UN General Assembly 2015](https://www.undrr.org/publication/sendai-framework-disaster-risk-reduction-2015-2030); [FAO 2014](https://www.fao.org/4/bl496e/bl496e.pdf); [One Health High-Level Expert Panel (OHHLEP) et al. 2022](https://doi.org/10.1371/journal.ppat.1010537)) and the [Nexus Standards](/organization/institutions/nexus-standards.md) that govern its records ([NS-0](https://nexustandards.com/standards/ns-0/), [NS-13](https://nexustandards.com/standards/ns-13/)). "An experiment is exploratory: its results are labelled as such and become evidence only after the Foundry rebuilds and the Universe tests them." (Labs pillar boundary). Ordinary participation has no fee. Paid work, internships and fellowships are separate arrangements, and unqualified contributors never take safety-critical tasks. {% hint style="info" %} **Read with the current model (2026-10-21).** * Everything this page describes is a design in formation. No national, regional or global consortium is recorded as constituted or active; the current service level is R0, information and enquiries ([Status and service levels](/organization/governance-in-operation/status-and-service-levels.md)). Where the text below reads as operation, read it as design. * Recognition, scoring and validation record what was shown under stated conditions. None is a certification, licence, rating or approval, and no country or institution is ranked. * There is no Nexus Standards. Nexus Standards is governed by the Global Standards Council, with GCRI Canada as secretariat and publisher of record; [NXS-NSF](/organization/systems/nxs-nsf.md) is the system for trust, authorization, mandate, policy and assurance. * Systems are named by their NXS display codes (for example NXS-RLS for participants, agreements, protocols, obligations and lawful handoffs); see [Systems](/organization/systems.md). {% endhint %} ### Part 18 — Ecosystem Interfaces and NXS-RLS Boundary #### 1. Interface Doctrine 1.1 **Interoperability without role confusion.** The Guild is an R\&D and evidence commons. It interconnects with ecosystem institutions only through defined interfaces that preserve the non-executing perimeter and prevent implied authority. 1.2 **Separation of functions is a safety control.**\ 1.2.1 **Intelligence and evidence** (Guild / GCRI) are separable from **assurance and recognition** (GRF/NSF) and separable from **execution and settlement** (licensed market actors and delivery stacks).\ 1.2.2 Any artifact crossing an institutional boundary must carry explicit **scope**, **handling**, **reliance bounds**, and **correction/supersession metadata**. 1.3 **No implied endorsement.** Interface participation does not create endorsement, certification, procurement steering, or regulatory determination. Where third parties use Guild outputs, they do so under their own authority and validation obligations. 1.4 **Validity follows records.** The only “official” cross-institutional references are those that are:\ 1.4.1 recorded as a designated act by the receiving institution’s records discipline; and\ 1.4.2 linked to the originating artifact version and its correction path. *** #### 2. Interface with GRF 2.1 **GRF role alignment.** GRF is the multistakeholder forum layer that can convene and structure dialogue, deliberation, and governance pathways for web resilience and standards adoption—without turning Guild work into advocacy, enforcement, or procurement outcomes. 2.2 **Permitted GRF handoffs (informational).** The Guild may provide GRF:\ 2.2.1 public-safe method notes and research releases;\ 2.2.2 comparative benchmark findings with uncertainty disclosure;\ 2.2.3 ecosystem risk landscape summaries (non-operational);\ 2.2.4 interoperability mapping notes (W3C/IETF/ICANN references; non-equivalence warnings); and\ 2.2.5 dispute and correction statistics in aggregated form (no unnecessary attribution). 2.3 **Prohibited GRF uses.** Guild outputs shall not be used in GRF settings to:\ 2.3.1 name “approved” vendors, stacks, or products;\ 2.3.2 issue certification-like claims (“compliant,” “safe,” “approved”);\ 2.3.3 conduct enforcement coordination; or\ 2.3.4 create coercive “moderation engineering” blueprints. 2.4 **GRF council engagement posture.** If Guild stewards participate in GRF councils, they do so as **technical and methods contributors**, subject to:\ 2.4.1 handling rules;\ 2.4.2 COI and recusal triggers; and\ 2.4.3 a strict separation between evidence publication and any GRF recognition processes. *** #### 3. Interface with GRA 3.1 **GRA role alignment.** GRA is the alliance and deployment coordination layer for industry participation and operational adoption pathways—while the Guild remains non-operational and non-executing. 3.2 **Permitted GRA handoffs (telemetry patterns only).** The Guild may provide GRA:\ 3.2.1 **telemetry schemas** and integration patterns (e.g., alert→AEP→ticket flows);\ 3.2.2 **evidence pack templates** for enterprise governance;\ 3.2.3 **non-intrusive measurement doctrine** and safe scanning standards;\ 3.2.4 **risk metrics definitions** (SLIs/SLOs as disclosed research outputs); and\ 3.2.5 **training and education artifacts** that improve adoption integrity. 3.3 **Hard boundary: no operations.** The Guild shall not:\ 3.3.1 perform incident response;\ 3.3.2 coordinate takedowns;\ 3.3.3 run an SOC/CSIRT;\ 3.3.4 provide real-time operational directives; or\ 3.3.5 act as an enforcement routing layer. 3.4 **No privileged access exchange.** Participation in GRA does not entitle any party to special access to restricted datasets, unpublished vulnerabilities, or controlled intelligence unless separately governed under handling, lawful basis, and disclosure rules. *** #### 4. Interface with NSF 4.1 **NSF role alignment.** NSF is the protocol and standards authority layer for conformance and interoperability primitives. The Guild contributes **R\&D artifacts** that may inform standards and conformance tests without claiming authority. 4.2 **Permitted NSF handoffs (standards-ready contributions).** The Guild may provide NSF:\ 4.2.1 reference implementations and test harnesses;\ 4.2.2 draft conformance criteria as research outputs;\ 4.2.3 benchmark methodologies and anti-gaming controls;\ 4.2.4 ontology objects and mapping notes; and\ 4.2.5 SBOM/SLSA release discipline patterns for secure build integrity. 4.3 **No standards capture.**\ 4.3.1 The Guild may not be used as a backdoor standards body.\ 4.3.2 NSF must maintain independent governance processes for adopting any Guild contribution into normative standards. 4.4 **Non-equivalence warnings.** Any mapping to standards must state whether it is:\ 4.4.1 an informational reference;\ 4.4.2 a partial alignment; or\ 4.4.3 a non-equivalent analogy that must not be treated as compliance. *** #### 5. NXS-RLS Interface Boundary 5.1 **Routing templates only.** Where NXS-RLS concepts are referenced, the Guild provides:\ 5.1.1 record templates;\ 5.1.2 evidence packaging patterns; and\ 5.1.3 routing interface schemas—without performing routing, settlement, custody, underwriting, or regulated execution. 5.2 **No regulated execution.** The Guild does not:\ 5.2.1 bind coverage;\ 5.2.2 place risk;\ 5.2.3 settle claims;\ 5.2.4 custody funds; or\ 5.2.5 operate any market or payment rail. 5.3 **Evidence-to-decision interface only.** If an enterprise uses a Guild AEP as an input into its own operations, the enterprise is responsible for:\ 5.3.1 verifying suitability;\ 5.3.2 applying local legal basis; and\ 5.3.3 maintaining its own execution records and controls. *** #### 6. Cross-Domain Interoperability with “Future of …” Platforms 6.1 **Coupling taxonomy.** The Guild maintains a coupling map describing how web dependencies amplify risk across physical and societal systems (water/energy/food/health/finance/critical infrastructure). 6.2 **Shared safeguards.** Cross-domain interoperability requires:\ 6.2.1 handling class alignment;\ 6.2.2 privacy minimization;\ 6.2.3 contestability;\ 6.2.4 correction/supersession linkage; and\ 6.2.5 explicit non-equivalence warnings where domain standards differ. 6.3 **Portable cores.** The Guild may publish “portable core” artifacts that can be reused across domains, such as:\ 6.3.1 evidence pack schemas;\ 6.3.2 measurement safety standards;\ 6.3.3 benchmark integrity controls; and\ 6.3.4 reproducibility runbooks. 6.4 **No cross-domain authority leakage.** Publishing a coupling insight does not grant the Guild authority over the coupled domain, nor does it imply operational responsibility. *** #### 7. Standards Bodies Interface 7.1 **Participation posture.** Engagement with W3C/IETF/ICANN or adjacent bodies is:\ 7.1.1 informational and research-supporting;\ 7.1.2 vendor-neutral; and\ 7.1.3 records-disciplined (what was submitted, when, under which handling class). 7.2 **No misrepresentation.** The Guild shall not:\ 7.2.1 claim representation of standards bodies;\ 7.2.2 claim that a draft is “approved”; or\ 7.2.3 imply that participation equals endorsement. 7.3 **Publication discipline for standards intelligence.** When reporting standards activity:\ 7.3.1 separate observation from interpretation;\ 7.3.2 disclose uncertainty; and\ 7.3.3 avoid lobbying posture. *** #### 8. Sanctions, Export Controls, and Sensitive Jurisdictions Posture 8.1 **Compliance first.** The Guild complies with applicable sanctions, export controls, and restricted-party rules. Where uncertain, the default posture is to restrict dissemination and seek lawful guidance through the relevant GCRI channel. 8.2 **Handling elevation.** Sensitive jurisdiction matters may require:\ 8.2.1 Controlled/Restricted handling;\ 8.2.2 minimized identity disclosure; and\ 8.2.3 publication delay or abstraction. 8.3 **Research safety limitations.** The Guild may refuse participation, dissemination, or collaboration where:\ 8.3.1 dual-use risk cannot be mitigated;\ 8.3.2 legal compulsion risk threatens protected participation; or\ 8.3.3 benchmark tampering or coercion indicators are material. 8.4 **No covert collection.** The Guild does not operate covert collection programs. Observatory methods remain lawful, non-intrusive, and minimization-first across all jurisdictions. ## Sources 1. UN General Assembly (2015). Sendai Framework for Disaster Risk Reduction 2015–2030. A/RES/69/283, 3 June 2015. 2. FAO (2014). The Water-Energy-Food Nexus: A new approach in support of food security and sustainable agriculture. Rome: Food and Agriculture Organization of the United Nations. 3. One Health High-Level Expert Panel (OHHLEP), Adisasmito, W. B. et al. (2022). One Health: A new definition for a sustainable and healthy future. PLoS Pathogens 18(6): e1010537. doi:10.1371/journal.ppat.1010537. 4. Nexus Standards. NS-0: Constitution and principles. Status: PROPOSED; UNI `NXS-STD-ST-000004`. 5. Nexus Standards. NS-13: Open standards development process. Status: PROPOSED; UNI `NXS-STD-ST-000008`. 6. GCRI. The Labs pillar home. 7. GCRI. Working groups (NWG). 8. This documentation: [Governance in operation](/organization/governance-in-operation.md); [The Model](/organization/model.md); [historical labels](/organization/reference.md). --- # 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/cooperation/nexus-guilds/future-of-web/xviii.-ecosystem-interfaces.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.