> 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/organization/governance/charters/gcri-ca/ix.-observatory.md).

# IX. OBSERVATORY

### 9.1 Observatory Methods Purpose

9.1.1 Observatory Methods as a Core GCRI Canada Technical-Stewardship Domain.\
9.1.1(a) GCRI Canada shall steward Observatory methods as a core technical-stewardship domain within its Canadian public-benefit, non-share, non-distributing, non-executing, evidence-and-methods mandate, for the purpose of strengthening observability, source discipline, systems intelligence, technical baselines, public-safe learning, verifiable records, and correctionable evidence across Nexus-relevant risks, technologies, infrastructures, communities, and institutions.

9.1.1(b) Observatory methods shall include the methods, controlled vocabulary, evidence logic, source treatment, data treatment, compute treatment, model treatment, dashboard treatment, map treatment, public-safe output treatment, and correction treatment used to observe, describe, compare, interpret, visualize, and communicate signals, conditions, systems, dependencies, vulnerabilities, resilience factors, degraded modes, uncertainty, and evidence gaps.

9.1.1(c) GCRI Canada’s stewardship of Observatory methods shall be technical, methodological, public-good, source-lined, records-valid, and correctionable. It shall not constitute ownership, operation, command, certification, recognition, finance-readiness, procurement approval, public authority action, public warning, emergency response, infrastructure management, provider endorsement, sponsor approval, protocol effect, or execution consequence by default.

9.1.1(d) Observatory methods shall be stewarded as part of GCRI Canada’s broader responsibilities for evidence integrity, observability, ontology, semantic interoperability, public-good software, open technical baselines, Verifiable Compute, Verifiable Intelligence, Nexus Truth Engine support, public-safe publication, public authority learning, and Nexus interface discipline.

9.1.1(e) GCRI Canada shall ensure that Observatory methods remain distinct from the institutional authority, legal authority, operating authority, finance authority, recognition authority, protocol authority, procurement authority, and execution authority of other actors, including public authorities, The Global Risks Forum (GRF), The Global Risks Alliance (GRA), Nexus Standards / Protocol Authority, Nexus entities, National Companies, Project SPVs, qualified providers, hosts, sponsors, universities, communities, and other downstream users.

9.1.1(f) Observatory methods shall be treated as public-good infrastructure for making complex systems more observable and intelligible, not as a mechanism for GCRI Canada to control systems, operate infrastructure, command responses, issue warnings, approve providers, certify technologies, direct finance, or execute projects.

9.1.1(g) Where Observatory methods are incorporated into dashboards, maps, APIs, technical notes, Evidence Packs, Decision Packs, public-safe summaries, public authority learning materials, GRF inputs, GRA inputs, Protocol Authority inputs, Academy materials, provider-facing materials, sponsor-facing materials, host-facing materials, community-facing materials, or public claims, their meaning shall remain governed by source lineage, method version, confidence, uncertainty, limitations, output class, public-safe status, boundary language, and correction path.

9.1.1(h) The controlling rule shall be that Observatory methods are a core GCRI Canada technical-stewardship domain because public-good observability requires disciplined methods before systems can be responsibly understood, compared, visualized, taught, or corrected.

***

9.1.2 Observatory Methods as Evidence, Observability, Technical Baseline, Systems Intelligence, and Public-Safe Output Methods.\
9.1.2(a) Observatory methods shall serve as evidence methods, observability methods, technical baseline methods, systems intelligence methods, and public-safe output methods for identifying, classifying, comparing, contextualizing, and communicating signals and records arising from complex social, technological, environmental, infrastructural, institutional, and risk systems.

9.1.2(b) As evidence methods, Observatory methods shall support source identification, source lineage, data lineage, source comparison, corroboration, contradiction treatment, dispute handling, evidence classification, confidence treatment, uncertainty treatment, limitation statements, correction pathways, and dependency records.

9.1.2(c) As observability methods, Observatory methods shall support the interpretation of signals, indicators, measurements, telemetry, field observations, public records, public authority context, community context, provider context, sponsor context, host context, spatial patterns, temporal patterns, system states, degraded modes, interdependencies, hotspots, nodes, hubs, clusters, regional clusters, and national dense Nexus cores.

9.1.2(d) As technical baseline methods, Observatory methods shall support common schemas, controlled vocabulary, data dictionaries, reference models, evidence classes, indicator definitions, dashboard conventions, map conventions, API conventions, public-good software conventions, source-quality conventions, confidence-display conventions, and correction conventions without creating certification or Protocol Authority effect by default.

9.1.2(e) As systems intelligence methods, Observatory methods shall support multi-source interpretation of system conditions, risk dynamics, resilience indicators, infrastructure dependencies, technology interactions, environmental signals, cyber conditions, AI-enabled systems, operational constraints, community conditions, public authority context, and historical patterns, while preserving uncertainty, limitations, and role boundaries.

9.1.2(f) As public-safe output methods, Observatory methods shall support public-safe summaries, dashboards, maps, reports, technical notes, APIs, datasets, Academy materials, media materials, and public claims that are intelligible without disclosing restricted data, exposing protected knowledge, creating public warning implication, implying public authority approval, implying finance-readiness, implying provider preference, or implying execution consequence.

9.1.2(g) Observatory methods shall not treat visual clarity, dashboard sophistication, map precision, real-time display, model output, Proof Receipt, technical baseline inclusion, public authority interest, sponsor support, provider participation, or public-facing usefulness as proof of validity, authority, or public-safe release.

9.1.2(h) The controlling rule shall be that Observatory methods translate signals into disciplined evidence and public-safe understanding, but only within recorded scope, confidence, uncertainty, limits, boundaries, and correction paths.

***

9.1.3 Observatory Methods as Distinct From Observatory Ownership, Operation, Public Authority Action, Emergency Command, Public Warning, Certification, Finance-Readiness, and Execution.\
9.1.3(a) GCRI Canada’s stewardship of Observatory methods shall be distinct from ownership or operation of any Observatory infrastructure, telecommunications system, AI-RAN system, O-RAN system, private wireless system, sensor network, DePIN network, cyber system, geospatial infrastructure, Earth observation system, digital twin platform, dashboard platform, map platform, data platform, compute platform, emergency-management platform, public authority system, provider system, host system, National Company system, Project SPV system, or execution platform.

9.1.3(b) Observatory methods shall not constitute public authority action, public authority decision, official guidance, regulatory approval, public warning, emergency command, public health order, public safety directive, compliance determination, enforcement position, safe harbor, permit, license, procurement approval, funding approval, public finance approval, or delegated public power.

9.1.3(c) Observatory methods shall not constitute certification, recognition, maturity status, standing, claims approval, Nexus-compatible status, protocol effect, conformance determination, procurement qualification, provider endorsement, sponsor approval, host approval, rating, guarantee, finance-readiness, capital-readiness, insurance-readiness, investment advice, lending decision, underwriting decision, operational clearance, infrastructure operation, legal status, market authority, or execution consequence by default.

9.1.3(d) GCRI Canada may develop, document, test, publish, version, teach, and correct Observatory methods, but shall not by that stewardship become the operator of any underlying system, the public authority responsible for warnings or decisions, the finance actor responsible for capital judgments, the certification body responsible for status, the provider responsible for deployment, or the execution actor responsible for implementation.

9.1.3(e) Where Observatory methods are used by public authorities, providers, hosts, National Companies, Project SPVs, GRF, GRA, Protocol Authority, universities, communities, or other actors, such use shall remain the user’s own use within its own authority, procedures, duties, records, accountability, and liability.

9.1.3(f) GCRI Canada shall use boundary language, interface records, output classification, public-safe controls, and correction pathways to prevent Observatory methods from being misread as operational command, warning authority, regulatory authority, procurement authority, financial authority, certification authority, recognition authority, protocol authority, or execution authority.

9.1.3(g) Where Observatory methods are misused to imply GCRI Canada operation, authority, warning, command, approval, certification, recognition, finance-readiness, provider preference, sponsor control, protocol effect, or execution consequence, GCRI Canada shall correct, relabel, restrict, withdraw, reissue, notify affected interfaces, suspend affected uses, or pursue contractual or legal remedies where appropriate.

9.1.3(h) The controlling rule shall be that GCRI Canada may steward how Observatory evidence is generated and interpreted, but it shall not own, operate, command, warn, certify, finance, recognize, approve, or execute by virtue of that stewardship.

***

9.1.4 Observatory Methods as Support for Nexus Network, Nexus Universe, Nexus Truth Engine, Nexus Risk Management, Nexus Rails, Nexus Grid, Nexus Academy, GRF, GRA, Nexus Standards / Protocol Authority, Regional Nexus Consortiums, National Nexus Consortiums, National Companies, Project SPVs, Qualified Providers, Hosts, Public Authorities, Universities, and Communities.\
9.1.4(a) Observatory methods may support the Nexus Network, Nexus Universe, Nexus Truth Engine, Nexus Risk Management, Nexus Rails, Nexus Grid, Nexus Academy, The Global Risks Forum (GRF), The Global Risks Alliance (GRA), Nexus Standards / Protocol Authority, Regional Nexus Consortiums, National Nexus Consortiums, National Companies, Project SPVs, qualified providers, hosts, public authorities, universities, communities, sponsors, and other authorized actors through evidence, observability, methods, public-safe outputs, technical baselines, training, and correction support.

9.1.4(b) Support for the Nexus Network and Nexus Universe may include methods for understanding nodes, hubs, clusters, hotspots, regional clusters, national dense cores, cross-border corridors, systems relationships, technology domains, risk domains, stakeholder context, public-safe publication, and Nexus interface records.

9.1.4(c) Support for the Nexus Truth Engine may include source comparison methods, corroboration logic, contradiction handling, dispute handling, confidence scoring, uncertainty treatment, limitation statements, inference context, evidence routing, challenge pathways, and correction triggers.

9.1.4(d) Support for Nexus Risk Management may include risk signal methods, resilience indicator methods, degraded-mode methods, interdependency methods, scenario methods, vulnerability-context methods, observability-gap methods, public-safe risk communication methods, and correction methods, without GCRI Canada becoming a risk manager for downstream actors by default.

9.1.4(e) Support for Nexus Rails and Nexus Grid may include evidence-flow methods, maturity-context methods, readiness-context evidence methods, technical evidence input methods, public-safe routing methods, dependency records, correction signals, and interface discipline, without creating finance-readiness, recognition, protocol effect, procurement status, or execution consequence.

9.1.4(f) Support for Nexus Academy may include training materials, public-safe explanations, method notes, controlled vocabulary, case materials, dashboard literacy, map literacy, AI literacy, compute literacy, observability literacy, and correction-literacy materials.

9.1.4(g) Support for GRF shall remain evidence-supporting and claims-discipline-supporting only, and shall not create recognition, standing, maturity records, claims approval, registry status, public-facing legitimacy, or public-safe reporting status by GCRI Canada.

9.1.4(h) Support for GRA shall remain evidence-supporting, risk-supporting, resilience-supporting, Proof Pack-supporting, capital-reader-literacy-supporting, and finance-boundary-supporting only, and shall not create finance-readiness, investment advice, rating, guarantee, insurance approval, lending decision, underwriting decision, or public finance approval by GCRI Canada.

9.1.4(i) Support for Nexus Standards / Protocol Authority shall remain evidence-supporting, method-supporting, ontology-supporting, schema-supporting, benchmark-supporting, public-good-software-supporting, technical-baseline-supporting, and correction-supporting only, and shall not create protocol effect, certification, conformance determination, Nexus-compatible status, standards approval, role key, smart license, entitlement state, or operational clearance by GCRI Canada.

9.1.4(j) Support for Regional Nexus Consortiums, National Nexus Consortiums, National Companies, Project SPVs, qualified providers, hosts, public authorities, universities, and communities shall preserve legal separateness, role separation, public authority boundaries, finance boundaries, procurement neutrality, provider neutrality, sponsor non-control, community safeguards, protected knowledge controls, public-safe publication, validity-by-record, and correctionability.

9.1.4(k) The controlling rule shall be that Observatory methods may support many Nexus actors, but support shall remain bounded, records-valid, non-substitutive, non-executing, and correctionable.

***

9.1.5 Observatory Methods as Records-Valid, Source-Lined, Confidence-Aware, Limitation-Aware, Public-Safe, Sovereignty-Compatible, and Correctionable.\
9.1.5(a) Observatory methods shall be records-valid, source-lined, confidence-aware, uncertainty-aware, limitation-aware, public-safe, sovereignty-compatible, privacy-protective, cybersecurity-controlled, protected-knowledge-sensitive, and correctionable.

9.1.5(b) Records-valid Observatory methods shall identify method purpose, method version, source records, data records, compute records where applicable, model records where applicable, dashboard records where applicable, map records where applicable, review records, output records, dependency records, and correction records.

9.1.5(c) Source-lined Observatory methods shall preserve source identity where safe, source class, source authority, source permission, provenance, custody, timeliness, reliability, bias, completeness, public-safe status, correction status, supersession status, withdrawal status, retraction status where applicable, and permitted-use limits.

9.1.5(d) Confidence-aware Observatory methods shall identify the basis and limits of confidence, including source quality, corroboration, independence, calibration, timeliness, completeness, reproducibility where appropriate, review status, method reliability, compute integrity, model evaluation, retrieval grounding, public authority context, community context, provider influence, sponsor influence, and correction status.

9.1.5(e) Uncertainty-aware and limitation-aware Observatory methods shall identify measurement uncertainty, source uncertainty, model uncertainty, temporal uncertainty, spatial uncertainty, statistical uncertainty, operational uncertainty, legal uncertainty, public authority uncertainty, community uncertainty, protected knowledge uncertainty, interpretive uncertainty, method limitations, data limitations, model limitations, dashboard limitations, map limitations, public-safe limitations, and downstream-use limitations.

9.1.5(f) Public-safe Observatory methods shall prevent unsafe disclosure, unsafe geospatial precision, sensitive-site exposure, infrastructure exposure, cyber-sensitive disclosure, public authority overclaim, finance overclaim, provider preference, sponsor validation, recognition implication, certification implication, protocol implication, warning implication, emergency-command implication, and execution implication.

9.1.5(g) Sovereignty-compatible Observatory methods shall account for data residency, localization, cross-border transfer, public authority data zones, Indigenous data considerations, community data safeguards, compute-to-data treatment, secure enclave treatment, access restrictions, support-access limits, deletion obligations, sealing obligations, and jurisdictional risk.

9.1.5(h) Correctionable Observatory methods shall include pathways for correction, supersession, withdrawal, retraction where applicable, reclassification, restriction, public-safe correction notice, controlled notice, dependency review, and archive treatment.

9.1.5(i) The controlling rule shall be that Observatory methods are not valid because they observe; they are valid only when their records, sources, confidence, uncertainty, limitations, public-safe treatment, sovereignty controls, and correction paths are complete enough for the use proposed.

***

9.1.6 Observatory Methods as Public-Good Infrastructure Protected Against Sponsor Control, Provider Preference, Proprietary Enclosure, Public Authority Confusion, and Finance Overclaim.\
9.1.6(a) Observatory methods shall be stewarded as public-good infrastructure and shall be protected against sponsor control, provider preference, proprietary enclosure, public authority confusion, finance overclaim, procurement implication, certification implication, recognition implication, protocol implication, and execution drift.

9.1.6(b) Sponsor support, funding, convening support, facilities support, data access, technology access, publication support, dashboard support, map support, event support, or participation shall not give any sponsor control over Observatory methods, evidence interpretation, source treatment, confidence treatment, public-safe publication, correction, provider selection, public authority access, GRF inputs, GRA inputs, Protocol Authority inputs, or downstream execution.

9.1.6(c) Provider participation, provider tooling, provider data, provider equipment, provider AI, provider compute, provider dashboards, provider sensors, provider demonstrations, validation sprints, benchmarks, integrations, or technical support shall not create provider preference, provider ranking, procurement advantage, public tender advantage, endorsement, certification, recognition, Nexus-compatible status, Protocol Authority effect, finance-readiness, or market superiority by default.

9.1.6(d) Observatory methods shall not be enclosed in a manner that prevents public-good use, correction, review, interoperability, portability, public-safe publication, controlled vocabulary consistency, or Nexus-wide methodological learning, except where restriction is required to protect privacy, cybersecurity, sovereign data, protected knowledge, public authority restrictions, confidentiality, legal obligations, controlled technology, export-control, sanctions, safety, or public-benefit purpose.

9.1.6(e) Public authority participation, data contribution, room attendance, regulator-listening presence, emergency-management presence, public finance presence, procurement presence, public-sector interest, or public authority reference shall not convert Observatory methods into official guidance, public authority decision, public warning, emergency command, regulatory approval, procurement approval, funding approval, public finance approval, public-law status, or delegated public power.

9.1.6(f) Finance-facing usefulness, GRA relevance, capital-reader interest, Proof Pack relevance, resilience evidence, host readiness evidence, node evidence, dashboard visibility, map visibility, benchmark performance, or public-safe summary use shall not convert Observatory methods into finance-readiness, investment advice, rating, guarantee, insurance approval, lending decision, underwriting decision, public finance approval, bankability, fundability, or capital commitment.

9.1.6(g) GCRI Canada shall use governance records, conflict disclosures, controlled vocabulary, interface agreements, public-safe review, provider-neutrality language, sponsor non-control language, no-public-authority language, finance-boundary language, and correction pathways to preserve the public-good character of Observatory methods.

9.1.6(h) The controlling rule shall be that Observatory methods are a public-good common rail, and no sponsor, provider, public authority, finance actor, or execution actor may convert them into controlled advantage, hidden endorsement, or unauthorized authority by implication.

***

9.1.7 Observatory Methods Across All Exponential and Mission-Critical Technologies.\
9.1.7(a) Observatory methods shall apply across all exponential, converging, infrastructure-relevant, and mission-critical technologies within the Nexus public-good stack, including artificial intelligence, AI-RAN, O-RAN, private wireless, telecommunications, cyber systems, DePIN, distributed ledger technologies, Web3 systems, quantum-relevant systems, high-performance computing, sovereign compute, edge compute, robotics, autonomous systems, drones, sensing systems, Earth observation, satellite systems, geospatial systems, digital twins, simulation systems, biosecurity-relevant systems, climate systems, nature systems, water-energy-food-health systems, energy systems, advanced manufacturing, semiconductors, supply chains, and related infrastructures.

9.1.7(b) Observatory methods shall support cross-technology interpretation where signals, risks, dependencies, systems, or outputs span multiple domains, including AI-cyber interaction, AI-telecommunications interaction, AI-RAN and sensor interaction, geospatial and climate interaction, digital twin and infrastructure interaction, cyber and public authority interaction, DePIN and physical infrastructure interaction, compute and sovereignty interaction, and technology and community impact interaction.

9.1.7(c) Observatory methods shall be designed to accommodate emerging technologies, technology convergence, degraded-mode operation, adversarial conditions, rapid technology change, immature evidence, uncertain standards, incomplete public authority context, incomplete provider documentation, sponsor involvement, public-safe uncertainty, and correction over time.

9.1.7(d) No technology domain shall be excluded merely because it is new, complex, privately controlled, public authority-adjacent, finance-relevant, security-sensitive, community-sensitive, or difficult to observe, provided that GCRI Canada can lawfully, safely, and records-validly steward methods for the relevant evidence domain.

9.1.7(e) Technology-specific Observatory methods shall preserve controlled vocabulary, source-lineage discipline, data-classification discipline, model-governance discipline, compute-record discipline, public-safe publication discipline, boundary discipline, and correction discipline across all domains.

9.1.7(f) Observatory methods shall not imply that GCRI Canada operates, approves, certifies, finances, procures, commands, recognizes, ranks, endorses, or executes any technology system merely because it develops methods for observing or interpreting such technology.

9.1.7(g) Where technology-specific methods create heightened privacy, cybersecurity, sovereign data, protected knowledge, public authority, finance, export-control, sanctions, controlled-technology, provider, sponsor, or public-safe risks, GCRI Canada shall apply heightened controls proportionate to risk.

9.1.7(h) The controlling rule shall be that Observatory methods must be technologically comprehensive but institutionally bounded: they may observe and interpret all relevant exponential technologies, but they shall not become authority over them.

***

9.1.8 Observatory Methods for Live, Simulated, Historical, Laboratory, Field, Controlled-Room, Public-Safe, and Degraded-Mode Contexts.\
9.1.8(a) Observatory methods may apply to live, near-real-time, simulated, historical, laboratory, field, controlled-room, clean-room, data-room, public-safe, public authority learning, community, university, provider, sponsor-supported, host, National Company, Project SPV, and degraded-mode contexts.

9.1.8(b) Live and near-real-time contexts shall require heightened treatment of timestamp integrity, update cadence, stale-data status, latency, signal volatility, public warning implication, emergency-command implication, dashboard implication, map implication, public authority boundary, cyber risk, infrastructure risk, and public-safe release risk.

9.1.8(c) Simulated and digital twin contexts shall require clear identification of scenario, assumptions, model version, input data, calibration status, validation status, uncertainty propagation, sensitivity analysis where material, limitations, public-safe status, and prohibition on presenting simulated outputs as observed fact.

9.1.8(d) Historical contexts shall require identification of time period, source age, supersession status, archival status, changed technology context, changed public authority context, changed community context, changed legal context, changed environmental context, and limits on applying historical patterns to current or future conditions.

9.1.8(e) Laboratory and controlled test contexts shall identify test conditions, equipment, methods, datasets, calibration, benchmark status, reproducibility, provider involvement, sponsor involvement, limitations, public-safe status, and prohibited claims, including no certification, no provider ranking, no procurement preference, no finance-readiness, no public authority approval, and no execution readiness by default.

9.1.8(f) Field contexts shall identify field source conditions, host conditions, community context, public authority context, safety constraints, data quality limits, missing data, sensor conditions, environmental conditions, access limits, privacy risks, protected knowledge risks, public-safe risks, and correction paths.

9.1.8(g) Controlled-room, clean-room, data-room, and no-download contexts shall identify access limits, handling class, permitted use, prohibited use, export limits, publication limits, AI-use limits, retrieval limits, embedding limits, confidentiality, logging, correction path, and closeout obligations.

9.1.8(h) Public-safe contexts shall identify what may be released externally, what must remain controlled, what must be redacted, aggregated, generalized, delayed, withheld, or responsibly not disclosed, and what boundary language must accompany the output.

9.1.8(i) Degraded-mode contexts shall identify reduced visibility, missing signals, compromised systems, emergency-adjacent conditions, infrastructure constraints, cyber risk, public authority relevance, community risk, confidence downgrade, uncertainty increase, limitation statements, public-safe treatment, and no-public-warning boundary.

9.1.8(j) The controlling rule shall be that Observatory methods must fit the context of observation, because live, simulated, historical, laboratory, field, controlled, public-safe, and degraded-mode evidence each carry different risks and limits.

***

9.1.9 Observatory Methods as a Bridge Between Technical Signals and Institutional Evidence Without Becoming Authority.\
9.1.9(a) Observatory methods shall function as a bridge between technical signals and institutional evidence by converting raw, processed, derived, modeled, simulated, observed, logged, mapped, dashboarded, or publicly reported signals into structured, source-lined, confidence-aware, limitation-aware, public-safe, and correctionable evidence artifacts.

9.1.9(b) Technical signals may include sensor readings, reference sensor readings, AI-RAN signals, O-RAN signals, private wireless signals, DePIN telemetry, cyber logs, geospatial data, Earth observation data, satellite data, digital twin outputs, simulation outputs, model outputs, public records, public authority context, community observations, host observations, provider data, sponsor-supplied data, university or laboratory outputs, and field evidence.

9.1.9(c) Institutional evidence shall require more than signal presence. A signal shall become institutional evidence only through source identification, permission review, classification, method application, data lineage, context, confidence treatment, uncertainty treatment, limitation treatment, public-safe assessment, review where material, record creation, dependency linking, and correction path.

9.1.9(d) Observatory methods shall preserve the distinction between a signal, a measurement, an observation, an inference, a scenario, a model output, a dashboard indicator, a map layer, an evidence conclusion, a public-safe summary, and an authority-bearing decision made by another competent actor.

9.1.9(e) GCRI Canada shall not allow technical signal strength, system complexity, real-time display, geospatial precision, AI-generated interpretation, public authority interest, sponsor support, provider participation, or dashboard visibility to substitute for evidence review, public-safe review, or boundary discipline.

9.1.9(f) Where institutional evidence derived from Observatory methods is routed to GRF, GRA, Protocol Authority, public authorities, National Companies, Project SPVs, providers, hosts, communities, or public audiences, the output shall carry its source, method, confidence, uncertainty, limitations, public-safe status, permitted use, prohibited use, and correction path.

9.1.9(g) The bridge from technical signal to institutional evidence shall not become a bridge to authority by implication. Any authority-bearing decision, recognition, finance-readiness, protocol effect, certification, procurement outcome, public warning, emergency command, infrastructure operation, or execution consequence shall require separate competent authority, separate record, and separate accountability.

9.1.9(h) The controlling rule shall be that Observatory methods help signals become evidence, but evidence remains evidence unless and until a separate competent actor lawfully gives it further effect.

***

9.1.10 Observatory Methods Register, Review Cycle, Versioning, and Correction Path.\
9.1.10(a) GCRI Canada shall maintain, or cause to be maintained, an Observatory Methods Register for material Observatory methods stewarded, used, referenced, published, corrected, superseded, withdrawn, retired, or archived by or on behalf of GCRI Canada.

9.1.10(b) The Observatory Methods Register shall identify method title or identifier, method type, purpose, owner, custodian, steward, version, status, technology domains, risk domains, source classes, data classes, evidence classes, output classes, public-safe status, controlled-room status where applicable, public authority relevance, finance relevance, GRF relevance, GRA relevance, Protocol Authority relevance, provider relevance, sponsor relevance, community relevance, protected knowledge relevance, approved uses, prohibited uses, confidence relationship, uncertainty relationship, limitation relationship, review requirements, assurance requirements, correction path, supersession path, withdrawal path, retirement path, archive path, and dependency links.

9.1.10(c) Registered Observatory methods may include source-ingestion methods, source-comparison methods, signal-quality methods, sensor methods, AI-RAN methods, O-RAN methods, DePIN methods, cyber methods, geospatial methods, Earth observation methods, digital twin methods, simulation methods, dashboard methods, map methods, API methods, indicator methods, hotspot methods, node methods, hub methods, cluster methods, degraded-mode methods, public-safe summarization methods, public authority learning methods, and correction methods.

9.1.10(d) Observatory methods shall be versioned. Version records shall identify changes to purpose, scope, source classes, data classes, evidence classes, technology domains, risk domains, algorithms, controlled vocabulary, schemas, thresholds, confidence logic, uncertainty treatment, public-safe treatment, dashboard conventions, map conventions, API conventions, output classes, boundary language, and correction paths.

9.1.10(e) Observatory methods shall be reviewed on schedule and upon material change, including new technology domain, new source class, new dataset, new model, new compute environment, new dashboard, new map, new API, new public authority use, new finance-facing use, new GRF input use, new GRA input use, new Protocol Authority input use, new provider use, new sponsor use, new community use, new protected knowledge concern, new incident, new correction, new public-safe issue, new legal issue, new cybersecurity issue, new sovereign data issue, or new downstream dependency.

9.1.10(f) Where an Observatory method is inaccurate, incomplete, stale, unsafe, misclassified, overclaimed, source-defective, method-defective, model-defective, compute-defective, public-safe defective, public authority-defective, finance-boundary defective, provider-neutrality defective, sponsor-control defective, protected-knowledge defective, privacy-defective, cyber-defective, sovereign-data-defective, or no longer fit for purpose, GCRI Canada shall correct, restrict, supersede, withdraw, retire, archive, or prohibit the method as appropriate.

9.1.10(g) The Observatory Methods Register shall be linked, where applicable, to Evidence Register entries, Source Comparison Records, Dataset Register entries, Model Register entries, System Card entries, Benchmark Card entries, Compute Workload Records, Compute Environment Records, Inference Records, Human Review Records, Retrieval and Embedding Records, Proof Receipt Records, Public-Safe Output Records, AI Incident Records, Correction Records, Dependency Records, Truth Engine Records, public authority records, GRF interface records, GRA interface records, Protocol Authority interface records, provider records, sponsor records, host records, community records, Nexus interface records, and public claims records.

9.1.10(h) The Observatory Methods Register, review cycle, versioning, and correction path shall not create certification, recognition, finance-readiness, public authority decision, procurement approval, provider endorsement, sponsor approval, rating, guarantee, public warning, emergency command, protocol effect, operational clearance, legal status, market authority, infrastructure operation, or execution consequence by default.

9.1.10(i) The controlling rule shall be that Observatory methods must be registered, reviewed, versioned, and correctable because observability methods shape how systems are seen, and how systems are seen shapes public trust.

### 9.2 Observatory Architecture Concepts

9.2.1 Observatory as Evidence, Sensing, Compute, Communications, Dashboard, Methods, and Public-Safe Observability Architecture.\
9.2.1(a) The Observatory shall be understood, for purposes of GCRI Canada’s technical-stewardship role, as an evidence, sensing, compute, communications, dashboard, methods, and public-safe observability architecture for organizing, comparing, interpreting, visualizing, and correcting records concerning systems, risks, technologies, infrastructures, communities, environments, public authority contexts, resilience conditions, degraded modes, and emerging public-good needs.

9.2.1(b) The Observatory architecture may include methods, nodes, hubs, clusters, hotspots, regional clusters, national dense Nexus cores, edge compute components, sovereign compute components, secure compute components, sensors, reference sensors, AI-RAN signals, O-RAN signals, private wireless signals, DePIN telemetry, geospatial layers, Earth observation inputs, satellite inputs, cyber records, digital twins, simulations, dashboards, maps, APIs, evidence rooms, controlled rooms, clean rooms, data rooms, public-safe outputs, technical notes, Evidence Packs, Decision Packs, Proof Receipts, and correction pathways.

9.2.1(c) For GCRI Canada, the Observatory architecture shall be treated as a public-good observability and evidence architecture, not as an infrastructure command architecture, public warning architecture, emergency-management architecture, procurement architecture, financial architecture, certification architecture, recognition architecture, Protocol Authority architecture, provider-ranking architecture, sponsor-control architecture, or execution architecture by default.

9.2.1(d) GCRI Canada may steward Observatory architecture concepts, methods, controlled vocabulary, source treatment, public-safe output treatment, technical baseline support, public-good software support, and correction discipline, but shall not thereby become the owner, operator, controller, public authority, emergency commander, finance actor, certification body, recognition body, Protocol Authority, provider, host, National Company, Project SPV, or execution actor for the Observatory architecture.

9.2.1(e) The Observatory architecture shall be interpreted through source lineage, data lineage, method versioning, compute workload records, compute environment records, model governance, dataset governance, system cards, benchmark cards, inference records where applicable, human review where material, public-safe review, confidence, uncertainty, limitations, boundary language, and correction paths.

9.2.1(f) Observatory architecture concepts shall support public-safe learning, public authority learning, technical literacy, systems intelligence, resilience understanding, Nexus interface discipline, GRF inputs, GRA inputs, Protocol Authority inputs, Academy materials, and community-facing understanding only within proper records and role separation.

9.2.1(g) Where Observatory architecture is described publicly, displayed visually, embedded in dashboards, included in maps, referenced in reports, used in APIs, included in technical notes, or presented in public-safe materials, GCRI Canada shall ensure that the architecture is not described in a manner that implies public authority status, public warning authority, emergency command, infrastructure operation, finance-readiness, procurement approval, certification, recognition, protocol effect, provider preference, sponsor approval, host approval, operational clearance, market authority, or execution consequence.

9.2.1(h) The controlling rule shall be that the Observatory architecture exists to make complex systems more observable, evidence-linked, public-safe, and correctionable, not to make GCRI Canada the authority that commands, approves, finances, certifies, recognizes, or executes those systems.

***

9.2.2 Observatory Node.\
9.2.2(a) An Observatory Node shall mean a defined observability unit, evidence point, sensing context, data context, infrastructure context, community context, public authority context, technology context, facility context, host context, or system context that is used to organize source records, signals, observations, compute outputs, model outputs, dashboard indicators, map layers, Evidence Pack materials, Decision Pack materials, public-safe summaries, or correction records.

9.2.2(b) An Observatory Node may be physical, digital, institutional, geographic, functional, technological, environmental, community-based, infrastructure-based, public authority-facing, host-facing, provider-facing, or hybrid, provided that its scope, source records, data classes, evidence classes, public-safe status, access class, handling class, confidence, uncertainty, limitations, owner or custodian where applicable, steward, and correction path are recorded.

9.2.2(c) A Node may relate to a sensor location, reference sensor, facility, local infrastructure, AI-RAN context, O-RAN context, private wireless context, DePIN contributor context, cyber system context, geospatial cell, digital twin component, public authority learning context, community context, host site, university or laboratory context, provider system, sponsor-supported context, or other recorded evidence context.

9.2.2(d) A Node shall not constitute a legal entity, operating unit, public authority designation, emergency zone, procurement unit, financial unit, certified site, recognized site, protocol-effective unit, provider-approved unit, sponsor-approved unit, host-approved unit, or execution site by default.

9.2.2(e) Node records shall identify, where material, source records, data lineage, method used, compute workload, model use, sensors or signals involved, public authority context, community context, protected knowledge status, provider role, sponsor role, host role, public-safe status, confidence, uncertainty, limitations, output relationships, dependency links, and correction path.

9.2.2(f) Node-level outputs, indicators, scores, labels, map markers, dashboard states, or public-safe summaries shall not be used to imply public warning, emergency command, public authority decision, finance-readiness, procurement approval, certification, recognition, protocol effect, provider preference, sponsor approval, host approval, operational clearance, or execution consequence.

9.2.2(g) Where a Node is corrected, reclassified, restricted, superseded, withdrawn, retired, archived, or no longer fit for use, GCRI Canada shall update affected Node records and review affected dashboards, maps, Evidence Packs, Decision Packs, public-safe outputs, interface records, and dependencies.

9.2.2(h) The controlling rule shall be that an Observatory Node is an evidence-organizing concept whose meaning depends on its records and limits, not an authority-bearing designation.

***

9.2.3 Observatory Hub.\
9.2.3(a) An Observatory Hub shall mean a recorded aggregation, coordination, or interpretive context connecting multiple Observatory Nodes, evidence flows, source classes, datasets, sensor contexts, compute workloads, public authority contexts, community contexts, provider contexts, host contexts, dashboards, maps, APIs, or public-safe outputs for the purpose of public-good observability and evidence interpretation.

9.2.3(b) A Hub may be geographic, technological, sectoral, functional, institutional, community-facing, public authority-facing, host-facing, regional, thematic, infrastructure-related, cyber-related, geospatial, AI-RAN-related, climate-related, WEFH-related, energy-related, supply-chain-related, or otherwise defined by recorded Observatory methods.

9.2.3(c) Hub records shall identify included Nodes, inclusion criteria, source classes, evidence classes, data classes, method version, confidence logic, uncertainty treatment, limitation treatment, public-safe status, access class, handling class, public authority relevance, finance relevance where any, provider relevance, sponsor relevance, host relevance, community relevance, protected knowledge relevance, output relationships, and correction path.

9.2.3(d) A Hub shall not create legal merger, agency, partnership, public authority delegation, regional authority, infrastructure operation, procurement grouping, investment zone, certified cluster, recognized status, protocol status, provider market, sponsor territory, host approval, or execution mandate by default.

9.2.3(e) Hub outputs shall preserve the distinction between source aggregation and evidence conclusion. The fact that multiple Nodes are grouped in a Hub shall not imply corroboration, confidence, risk level, resilience status, readiness, maturity, public warning, or public authority status unless separately supported by recorded method and evidence.

9.2.3(f) Hub public-safe outputs shall include boundary language where material to prevent interpretation as public authority classification, public warning, finance signal, procurement signal, provider preference, sponsor validation, recognition, certification, protocol effect, or execution instruction.

9.2.3(g) Where a Node within a Hub is corrected, restricted, superseded, withdrawn, or reclassified, GCRI Canada shall assess whether the Hub record, dashboard, map, public-safe summary, Evidence Pack, Decision Pack, interface record, or dependency record requires correction.

9.2.3(h) The controlling rule shall be that an Observatory Hub organizes evidence relationships across Nodes, but it does not create authority, status, approval, finance, procurement, or execution by grouping evidence.

***

9.2.4 Observatory Cluster.\
9.2.4(a) An Observatory Cluster shall mean a recorded evidence grouping of Nodes, Hubs, signals, systems, risks, technologies, infrastructures, geographies, communities, public authority contexts, provider contexts, host contexts, datasets, dashboards, maps, or outputs that are treated together for a defined observability, comparison, learning, resilience, risk, or public-safe communication purpose.

9.2.4(b) A Cluster may be formed by geography, technology domain, risk domain, infrastructure dependency, community context, public authority context, degraded-mode pattern, sensor pattern, AI-RAN pattern, O-RAN pattern, private wireless pattern, DePIN pattern, cyber pattern, geospatial pattern, climate pattern, digital twin scenario, resilience indicator, public-safe learning need, or other recorded method.

9.2.4(c) Cluster records shall identify the basis for clustering, inclusion and exclusion criteria, source records, data records, method version, confidence treatment, uncertainty treatment, limitation treatment, public-safe status, access class, handling class, dashboard treatment, map treatment, interface treatment, dependency links, and correction path.

9.2.4(d) A Cluster shall not constitute an official public authority region, emergency zone, hazard area, procurement package, investment area, certified cluster, recognized maturity group, Protocol Authority class, provider group, sponsor territory, host status, legal unit, market unit, infrastructure operating unit, or execution unit by default.

9.2.4(e) Cluster labels shall be governed by controlled vocabulary and shall not be used in a manner that implies greater certainty, authority, public warning meaning, public authority meaning, finance meaning, certification meaning, recognition meaning, protocol meaning, provider meaning, sponsor meaning, or execution meaning than the record supports.

9.2.4(f) Where Cluster outputs include scores, heatmaps, indicators, rankings, comparisons, public-safe summaries, dashboards, maps, or technical notes, GCRI Canada shall review such outputs for false precision, context collapse, public warning implication, provider preference, finance overclaim, public authority confusion, sponsor validation, and correctionability.

9.2.4(g) Where the basis for a Cluster changes, including new evidence, corrected evidence, changed source status, changed public-safe status, changed confidence, changed uncertainty, changed limitations, changed public authority context, changed community context, changed provider context, or changed sponsor context, the Cluster record shall be reviewed and corrected where required.

9.2.4(h) The controlling rule shall be that an Observatory Cluster is a method-defined evidence grouping, not a public authority designation, market designation, certification, recognition, protocol class, or execution structure by default.

***

9.2.5 Observatory Hotspot.\
9.2.5(a) An Observatory Hotspot shall mean a recorded evidence, signal, risk, resilience, anomaly, attention, degraded-mode, vulnerability, opportunity, or systems-intelligence concentration identified through approved Observatory methods for internal, controlled-room, public authority learning, public-safe, GRF-facing, GRA-facing, Protocol Authority-facing, Academy, or other authorized evidence purposes.

9.2.5(b) A Hotspot may relate to increased signal density, source convergence, recurring anomaly, infrastructure stress, cyber pattern, geospatial pattern, climate pattern, sensor pattern, degraded-mode condition, public authority learning need, community concern, host context, provider-relevant technical pattern, sponsor-supported evidence context, or resilience gap, provided that the evidence basis and limits are recorded.

9.2.5(c) Hotspot records shall identify evidence basis, source records, method used, threshold or qualitative basis where applicable, confidence, uncertainty, limitations, temporal scope, spatial scope, public-safe status, access class, handling class, public authority relevance, community relevance, protected knowledge status, provider relevance, sponsor relevance, host relevance, dashboard treatment, map treatment, permitted use, prohibited use, and correction path.

9.2.5(d) A Hotspot shall not constitute an official public warning, emergency alert, hazard designation, public authority determination, regulatory classification, public safety directive, evacuation zone, enforcement priority, procurement priority, finance priority, certified area, recognized area, provider market, sponsor territory, operational command area, or execution instruction by default.

9.2.5(e) Public use of Hotspot terminology shall require heightened public-safe review because Hotspot language may be misread as warning, risk certainty, emergency status, public authority status, finance signal, media claim, or market signal.

9.2.5(f) Where Hotspot outputs are displayed through dashboards, maps, reports, APIs, public-safe summaries, media materials, or public claims, GCRI Canada shall use confidence, uncertainty, limitations, no-public-warning language, no-emergency-command language, no-public-authority language, no-finance language, no-procurement language, no-provider-endorsement language, no-sponsor-approval language, and correction path where material.

9.2.5(g) Where a Hotspot is later found inaccurate, stale, misclassified, overclaimed, unsupported, unsafe, disputed, or superseded, GCRI Canada shall correct, downgrade, relabel, restrict, supersede, withdraw, retract where appropriate, update affected dashboards or maps, and review downstream dependencies.

9.2.5(h) The controlling rule shall be that an Observatory Hotspot is a signal for attention and review, not an official warning, emergency command, authority decision, finance signal, certification, recognition, provider preference, or execution instruction.

***

9.2.6 Regional Observatory Cluster.\
9.2.6(a) A Regional Observatory Cluster shall mean a recorded Observatory evidence grouping that spans or relates to a region, subregion, corridor, watershed, airshed, coastal zone, rural region, urban region, cross-border area, economic region, technology corridor, infrastructure region, community region, public authority region, or other regional context for public-good observability, learning, evidence interpretation, and correction.

9.2.6(b) Regional Observatory Cluster records shall identify geographic or functional scope, participating or relevant Nodes, Hubs, Clusters, public authority contexts, community contexts, Indigenous or protected knowledge contexts where applicable, host contexts, provider contexts, sponsor contexts, infrastructure contexts, technology domains, risk domains, datasets, methods, public-safe status, access class, handling class, confidence, uncertainty, limitations, and correction path.

9.2.6(c) A Regional Observatory Cluster shall not create a formal jurisdiction, public authority region, emergency region, procurement region, investment region, public finance region, certified region, recognized region, Protocol Authority region, provider market, sponsor territory, National Company operating territory, Project SPV scope, infrastructure operating unit, or execution mandate by default.

9.2.6(d) Regional Observatory Cluster methods shall preserve legal separateness among GCRI Canada, regional Nexus bodies, national Nexus bodies, public authorities, communities, hosts, providers, sponsors, National Companies, Project SPVs, GRF, GRA, Protocol Authority, and other actors.

9.2.6(e) Where a Regional Observatory Cluster is used in GRF-facing, GRA-facing, Protocol Authority-facing, public authority-facing, provider-facing, sponsor-facing, host-facing, community-facing, Academy, media, or public-safe materials, its boundary language shall prevent interpretation as recognition, finance-readiness, protocol effect, public authority designation, procurement status, provider preference, sponsor validation, or execution readiness.

9.2.6(f) Regional Observatory Cluster outputs shall be reviewed for geospatial sensitivity, public authority implication, cross-border data controls, sovereign data controls, community safeguards, Indigenous or protected knowledge safeguards, infrastructure-sensitive information, cyber-sensitive information, finance-sensitive information, provider-neutrality risk, sponsor non-control risk, and public-safe meaning.

9.2.6(g) Where the regional basis, evidence base, public authority context, community context, data permission, source status, method status, confidence, uncertainty, or public-safe status changes, GCRI Canada shall review and correct the Regional Observatory Cluster record and affected dependencies.

9.2.6(h) The controlling rule shall be that a Regional Observatory Cluster helps organize regional evidence and learning, but it does not create jurisdiction, public authority, finance, procurement, certification, recognition, protocol, provider, sponsor, or execution status.

***

9.2.7 National Dense Nexus Core.\
9.2.7(a) A National Dense Nexus Core shall mean a recorded national or nationally significant concentration of Nexus-relevant evidence flows, observability methods, institutional interfaces, public authority learning contexts, technology domains, risk domains, infrastructure contexts, community contexts, host contexts, provider contexts, sponsor contexts, compute capabilities, dashboards, maps, technical baselines, public-good software, and correction pathways.

9.2.7(b) A National Dense Nexus Core may describe a dense national evidence and observability context involving multiple Nodes, Hubs, Clusters, Regional Observatory Clusters, public authority interfaces, universities, communities, providers, hosts, National Companies, Project SPVs, GRF interfaces, GRA interfaces, Protocol Authority interfaces, Academy interfaces, and Nexus Network interfaces, provided that its definition, evidence base, governance boundaries, and correction path are recorded.

9.2.7(c) National Dense Nexus Core records shall identify national context, jurisdictional context, public authority context, sovereign data context, compute context, community and Indigenous context where applicable, infrastructure context, technology domains, risk domains, institutional interfaces, data classes, evidence classes, output classes, public-safe status, access class, handling class, confidence, uncertainty, limitations, permitted use, prohibited use, and correction path.

9.2.7(d) A National Dense Nexus Core shall not constitute a national public authority designation, official national program, public finance program, procurement program, investment zone, emergency-management structure, certified ecosystem, recognized ecosystem, Protocol Authority status, provider market, sponsor territory, National Company mandate, Project SPV mandate, infrastructure operating system, or execution authority by default.

9.2.7(e) GCRI Canada may support National Dense Nexus Core methods as part of public-good evidence, observability, public authority learning, technical baseline, public-good software, Academy, GRF input, GRA input, Protocol Authority input, Rails, Grid, and correction discipline, but shall not thereby control national implementation, public authority action, finance, procurement, or execution.

9.2.7(f) National Dense Nexus Core outputs shall be subject to heightened public-safe review because national framing may imply official status, national adoption, public authority endorsement, public finance approval, procurement relevance, finance-readiness, provider preference, sponsor approval, or execution readiness.

9.2.7(g) Where a National Dense Nexus Core is referenced publicly, GCRI Canada shall preserve boundary language, controlled vocabulary, public-safe limitations, no-public-authority language, no-finance language, no-procurement language, no-certification language, no-recognition language, no-protocol-effect language, no-provider-endorsement language, no-sponsor-approval language, and correction path.

9.2.7(h) The controlling rule shall be that a National Dense Nexus Core is a national evidence-density and observability concept, not a national authority, market, approval, finance, certification, recognition, protocol, or execution instrument by default.

***

9.2.8 Edge Compute and Sovereign Compute Components.\
9.2.8(a) Observatory architecture may include edge compute, sovereign compute, secure enclave, confidential computing, compute-to-data, air-gapped, no-download, controlled-room, clean-room, data-room, public authority environment, university environment, provider environment, host environment, and other approved compute components for processing Observatory data and outputs.

9.2.8(b) Edge compute components may support localized processing, sensor processing, AI-RAN signal processing, O-RAN signal processing, private wireless signal processing, cyber analysis, geospatial pre-processing, degraded-mode analysis, latency-sensitive analysis, privacy-preserving processing, public-safe summarization, and reduced data movement, provided that records, permissions, security, public-safe status, and correction paths are maintained.

9.2.8(c) Sovereign compute components may support data residency, localization, public authority data controls, Indigenous data considerations, community data safeguards, national data infrastructure requirements, restricted data handling, compute-to-data treatment, secure enclave processing, and jurisdictional access limits.

9.2.8(d) Compute components shall be recorded in applicable Compute Environment Registers and Compute Workload Registers and shall identify environment, jurisdiction, provider where any, owner, custodian, steward, approved workloads, prohibited workloads, data classes, evidence classes, output classes, access controls, logging, monitoring, encryption, key management, retention, deletion, sealing, archive treatment, incident path, and correction path.

9.2.8(e) Compute components shall not be treated as safe, sovereign, public-safe, evidence-valid, or authority-bearing merely because they are local, edge-based, cloud-secure, sovereign-branded, provider-certified, public-sector-used, encrypted, attested, sponsor-supported, or technically advanced.

9.2.8(f) GCRI Canada’s use, stewardship, reference, or method support for edge or sovereign compute components shall not make GCRI Canada a cloud operator, telecommunications operator, infrastructure operator, public authority operator, licensed market infrastructure operator, provider, host operator, National Company, Project SPV, or execution platform by default.

9.2.8(g) Where edge or sovereign compute components are used in public authority-facing, finance-facing, GRF-facing, GRA-facing, Protocol Authority-facing, provider-facing, sponsor-facing, host-facing, community-facing, public-safe, dashboard, map, API, or public claim contexts, GCRI Canada shall preserve boundary language, source lineage, compute records, public-safe review, and correction paths.

9.2.8(h) The controlling rule shall be that edge and sovereign compute components support safer evidence processing only where their authority, jurisdiction, security, data controls, records, and correction paths are complete enough for the use proposed.

***

9.2.9 Sensors, AI-RAN, O-RAN, Private Wireless, DePIN, Geospatial, Cyber, Digital Twin, and Dashboard Components.\
9.2.9(a) Observatory architecture may include sensors, reference sensors, AI-RAN components, O-RAN components, private wireless components, DePIN components, geospatial components, Earth observation components, satellite components, cyber components, digital twin components, simulation components, dashboard components, map components, API components, and other technical components relevant to public-good observability.

9.2.9(b) Sensor and reference sensor components shall identify sensor class, source status, calibration status, custody, placement context, timestamp treatment, location or safe-location treatment, sampling method, data quality, missing data, failure modes, public-safe status, access controls, and correction path.

9.2.9(c) AI-RAN, O-RAN, and private wireless components shall identify signal class, network context, device or node context where safe and material, provider context where any, operator context where any, public authority context where any, signal confidence, uncertainty, spoof risk, outage risk, degraded-mode status, public-safe status, and correction path.

9.2.9(d) DePIN components shall identify telemetry source, network role where safe, contributor or node context where material, validator context where material, custody, incentive risk, tamper risk, data quality, public-safe status, provider or sponsor influence risk, and correction path.

9.2.9(e) Geospatial, Earth observation, and satellite components shall identify source, spatial resolution, temporal resolution, processing method, projection treatment where material, sensitive-site treatment, infrastructure-sensitive treatment, community-identifiability treatment, safe-location treatment, public-safe status, and correction path.

9.2.9(f) Cyber components shall identify cyber-sensitive classification, log source, system context where safe, vulnerability sensitivity, exploit sensitivity, credential sensitivity, incident-adjacent status, public-safe disclosure status, access controls, and correction path.

9.2.9(g) Digital twin and simulation components shall identify model purpose, scenario, assumptions, input data, calibration status, validation status, sensitivity analysis where material, uncertainty propagation, limitation treatment, public-safe status, and correction path.

9.2.9(h) Dashboard, map, and API components shall identify data sources, update cadence, stale-data treatment, indicator meaning, score meaning where any, color meaning where any, confidence display, uncertainty display, limitation display, access controls, public-safe status, export controls, downstream reuse limits, and correction path.

9.2.9(i) Components under this section shall not create public warning, emergency command, infrastructure operation, public authority decision, procurement approval, finance-readiness, recognition, certification, protocol effect, provider endorsement, sponsor approval, rating, guarantee, operational clearance, legal status, market authority, or execution consequence by default.

9.2.9(j) The controlling rule shall be that technical components are admissible into Observatory architecture only through source, method, security, public-safe, boundary, and correction controls proportionate to their risk.

***

9.2.10 Observatory Stack, Observatory Unit, Observatory Room, Observatory Evidence Pack, and Observatory Public-Safe Output.\
9.2.10(a) The Observatory Stack shall mean the layered set of methods, source records, datasets, compute workloads, compute environments, models, systems, sensors, dashboards, maps, APIs, controlled vocabulary, output classes, review records, public-safe controls, correction paths, interface records, and assurance practices used to support Observatory evidence and public-safe observability.

9.2.10(b) An Observatory Unit shall mean a defined component, module, record set, method set, source set, node set, dashboard set, map set, compute set, model set, or public-safe output set used within the Observatory Stack for a recorded purpose and output class.

9.2.10(c) An Observatory Room shall mean a controlled-room, data-room, clean-room, no-download room, public authority learning room, finance-safe room, provider room, sponsor-controlled-access room where appropriate, host room, community room, protected knowledge room, cyber room, safeguards room, or other access-controlled environment used for Observatory-related review, learning, evidence comparison, public-safe preparation, or correction.

9.2.10(d) An Observatory Evidence Pack shall mean a records-valid package of Observatory-related source records, method records, data records, compute records, model records where applicable, dashboard or map records where applicable, confidence treatment, uncertainty treatment, limitation statements, public-safe status, boundary language, reviewer records where applicable, dependency links, and correction path.

9.2.10(e) An Observatory Public-Safe Output shall mean an externally releasable Observatory-related summary, dashboard, map, report, technical note, dataset, API, Academy material, repository note, public-safe correction notice, or public claim that has been reviewed for public-safe release, boundary meaning, restricted data, confidence, uncertainty, limitations, and correction path.

9.2.10(f) The Observatory Stack, Observatory Units, Observatory Rooms, Observatory Evidence Packs, and Observatory Public-Safe Outputs shall be governed by access controls, classification, handling class, data controls, public-safe controls, privacy controls, cybersecurity controls, sovereign data controls, protected knowledge safeguards, provider-neutrality controls, sponsor non-control controls, and correction controls.

9.2.10(g) No Observatory Stack, Unit, Room, Evidence Pack, or Public-Safe Output shall create public authority decision, public warning, emergency command, finance-readiness, investment advice, procurement approval, certification, recognition, protocol effect, provider endorsement, sponsor approval, host approval, operational clearance, legal status, market authority, infrastructure operation, or execution consequence by default.

9.2.10(h) The controlling rule shall be that Observatory architecture terms describe governed evidence structures and review environments, not authority-bearing instruments by default.

***

9.2.11 Observatory Architecture Without Implied Ownership, Operation, Public Authority, or Execution by GCRI Canada.\
9.2.11(a) No Observatory architecture concept, including Node, Hub, Cluster, Hotspot, Regional Observatory Cluster, National Dense Nexus Core, Observatory Stack, Observatory Unit, Observatory Room, Observatory Evidence Pack, Observatory Public-Safe Output, dashboard, map, API, dataset, sensor method, compute component, AI-RAN method, O-RAN method, DePIN method, cyber method, digital twin method, or technical baseline method, shall imply ownership, operation, public authority, finance authority, certification authority, recognition authority, Protocol Authority, procurement authority, provider authority, sponsor authority, host authority, market authority, infrastructure operation, or execution authority by GCRI Canada.

9.2.11(b) GCRI Canada’s role in Observatory architecture shall be evidence-and-methods stewardship, observability-methods stewardship, ontology and controlled vocabulary stewardship, public-good software support, open technical baseline support, Verifiable Compute support, Verifiable Intelligence support, public authority learning support, public-safe output support, and correction support.

9.2.11(c) Public authorities, infrastructure operators, telecommunications operators, AI-RAN operators, O-RAN operators, private wireless operators, DePIN operators, cyber operators, geospatial operators, hosts, providers, National Companies, Project SPVs, emergency-management actors, public finance actors, procurement actors, regulators, GRF, GRA, Protocol Authority, universities, communities, and other actors shall remain responsible for their own authorities, systems, duties, decisions, operations, liabilities, and records.

9.2.11(d) Use of GCRI Canada Observatory methods by another actor shall not make GCRI Canada responsible for that actor’s operations, warnings, procurements, financing, certifications, recognitions, protocol effects, public authority decisions, market actions, infrastructure decisions, or execution consequences unless an express lawful instrument provides otherwise and such instrument is consistent with GCRI Canada’s mandate.

9.2.11(e) GCRI Canada shall not permit Observatory architecture materials to be used as though GCRI Canada owns, operates, commands, certifies, finances, recognizes, approves, endorses, procures, regulates, or executes any underlying system.

9.2.11(f) Where public-facing materials create ambiguity concerning GCRI Canada’s role, the materials shall be interpreted and, where necessary, corrected to preserve non-ownership, non-operation, non-public-authority, non-finance, non-certification, non-recognition, non-protocol, non-procurement, non-endorsement, and non-execution boundaries.

9.2.11(g) Where any person misuses Observatory architecture concepts to imply GCRI Canada ownership, operation, public authority, warning authority, finance authority, certification, recognition, protocol effect, provider preference, sponsor approval, host approval, operational clearance, or execution consequence, GCRI Canada shall correct, relabel, restrict, withdraw, reissue, require removal of misleading references, notify affected interfaces, suspend interface use where required, or pursue contractual or legal remedies where appropriate.

9.2.11(h) The controlling rule shall be that GCRI Canada may define and steward Observatory architecture concepts without becoming the owner, operator, authority, or execution actor for the systems those concepts help observe.

***

9.2.12 Observatory Architecture Vocabulary, Records, and Controlled Definitions.\
9.2.12(a) GCRI Canada shall maintain controlled vocabulary, records, and controlled definitions for material Observatory architecture concepts, including Node, Hub, Cluster, Hotspot, Regional Observatory Cluster, National Dense Nexus Core, Observatory Stack, Observatory Unit, Observatory Room, Observatory Evidence Pack, Observatory Public-Safe Output, edge compute component, sovereign compute component, sensor component, AI-RAN component, O-RAN component, private wireless component, DePIN component, geospatial component, cyber component, digital twin component, dashboard component, map component, API component, and related terms.

9.2.12(b) Controlled definitions shall identify each term’s purpose, permitted meaning, prohibited meaning, records required, output classes supported, public-safe conditions, access conditions, role boundaries, authority boundaries, finance boundaries, procurement boundaries, provider-neutrality requirements, sponsor non-control requirements, public authority boundaries, confidence treatment, uncertainty treatment, limitation treatment, and correction path.

9.2.12(c) Observatory architecture vocabulary shall distinguish evidence-organizing terms from authority-bearing terms. Terms such as “node,” “hub,” “cluster,” “hotspot,” “regional cluster,” “national dense core,” “signal,” “indicator,” “observability,” “dashboard,” “map,” “proof,” “verified,” “validated,” “public-safe,” “readiness,” “resilience,” “risk,” “baseline,” “core,” “stack,” “room,” and “output” shall not be used in ways that imply status, approval, warning, command, finance, procurement, certification, recognition, protocol effect, provider preference, sponsor control, or execution beyond the record.

9.2.12(d) Vocabulary records shall be versioned and shall identify term changes, definition changes, scope changes, public-safe changes, boundary-language changes, translation changes, localization changes, dashboard-label changes, map-label changes, API-field changes, and correction history.

9.2.12(e) Where Observatory architecture vocabulary is translated, localized, summarized, visualized, dashboarded, mapped, embedded in APIs, included in public-safe reports, used in Academy materials, included in public authority materials, used in GRF inputs, used in GRA inputs, used in Protocol Authority inputs, used in provider materials, used in sponsor materials, used in host materials, used in community-facing materials, or used in media materials, GCRI Canada shall preserve controlled meaning and boundary language.

9.2.12(f) Where a controlled definition becomes inaccurate, overbroad, unclear, misleading, unsafe, overclaimed, inconsistent with Nexus role separation, inconsistent with public-safe discipline, inconsistent with public authority boundaries, inconsistent with finance boundaries, inconsistent with provider neutrality, inconsistent with sponsor non-control, or inconsistent with correctionability, GCRI Canada shall correct, restrict, supersede, withdraw, retire, or archive the definition as appropriate.

9.2.12(g) Observatory architecture vocabulary, records, and controlled definitions shall be linked, where applicable, to the Observatory Methods Register, Ontology and Controlled Vocabulary Registers, Evidence Register entries, Dataset Register entries, Model Register entries, System Card entries, Compute Workload Records, Compute Environment Records, Dashboard Records, Map Records, Public-Safe Output Records, Correction Records, Dependency Records, public authority records, GRF interface records, GRA interface records, Protocol Authority interface records, provider records, sponsor records, host records, community records, Nexus interface records, and public claims records.

9.2.12(h) The controlling rule shall be that Observatory architecture vocabulary must be controlled because architecture terms can become authority claims unless their meanings, limits, records, and correction paths are written down.

### 9.3 Observatory Node Methods

9.3.1 Observatory Node as Local Evidence, Compute, Sensing, Communications, and Continuity Anchor.\
9.3.1(a) An Observatory Node shall be treated, for GCRI Canada’s technical-stewardship purposes, as a local or context-specific evidence, compute, sensing, communications, observability, continuity, and public-safe learning anchor within the wider Observatory architecture.

9.3.1(b) A Node may support the organization of source records, sensor records, reference sensor records, AI-RAN signals, O-RAN signals, private wireless signals, DePIN telemetry, cyber records, geospatial records, Earth observation inputs, digital twin inputs, field observations, host context, public authority context, community context, provider context, sponsor context, compute outputs, dashboards, maps, Evidence Packs, Decision Packs, public-safe summaries, and correction records.

9.3.1(c) A Node may be associated with a facility, campus, community, host site, infrastructure context, communications context, local sensor context, edge compute context, sovereign compute context, public authority learning context, university or laboratory context, technology demonstration context, validation context, degraded-mode context, emergency-adjacent context, or other recorded evidence context, provided that its scope and boundaries are defined by record.

9.3.1(d) A Node shall not be treated as a legal entity, operating unit, public authority unit, emergency-response unit, telecommunications operator, infrastructure operator, finance unit, procurement unit, provider unit, sponsor unit, certified site, recognized site, protocol-effective unit, National Company unit, Project SPV unit, or execution site by default.

9.3.1(e) Node methods shall support continuity by preserving records of source availability, data quality, local constraints, signal quality, degraded-mode conditions, compute environment status, communications status, public-safe output status, access status, custody status, incident status, and correction status.

9.3.1(f) Node methods shall not convert local observability into operational control. The existence of a Node, node record, node dashboard, node map marker, node sensor, node compute workload, node Evidence Pack, node public-safe output, or node continuity indicator shall not create public warning, emergency command, infrastructure operation, public authority decision, procurement approval, finance-readiness, certification, recognition, protocol effect, provider endorsement, sponsor approval, host approval, operational clearance, legal status, market authority, or execution consequence.

9.3.1(g) Where a Node is referenced publicly or externally, GCRI Canada shall preserve controlled vocabulary, public-safe explanation, confidence, uncertainty, limitations, no-public-warning language, no-public-authority language, no-finance language, no-procurement language, no-certification language, no-recognition language, no-protocol-effect language, no-provider-endorsement language, no-sponsor-approval language, and correction path where material.

9.3.1(h) The controlling rule shall be that an Observatory Node is a local anchor for evidence and continuity, not an authority-bearing site or execution instrument.

***

9.3.2 Node Evidence Methods.\
9.3.2(a) GCRI Canada shall steward Node evidence methods for identifying, receiving, classifying, comparing, interpreting, preserving, public-safe summarizing, and correcting records associated with an Observatory Node.

9.3.2(b) Node evidence methods shall identify source records, source class, source authority, source permission, source lineage, data lineage, provenance, custody, timestamp, location or safe-location treatment, data quality, completeness, timeliness, calibration where applicable, source bias, source independence, public-safe status, access class, handling class, confidence, uncertainty, limitations, and correction path.

9.3.2(c) Node evidence may include sensor data, reference sensor data, AI-RAN signals, O-RAN signals, private wireless signals, DePIN telemetry, cyber logs, geospatial records, Earth observation records, satellite records, digital twin outputs, simulation outputs, host observations, public authority context, community observations, Indigenous or protected knowledge context where applicable, provider materials, sponsor materials, university or laboratory outputs, public records, field notes, photographs, maps, dashboards, API outputs, and historical records.

9.3.2(d) Node evidence methods shall distinguish raw data, processed data, derived data, model outputs, AI outputs, dashboard indicators, map layers, field observations, expert judgments, public records, public authority context, community context, provider-supplied materials, sponsor-supplied materials, and public-safe summaries.

9.3.2(e) Node evidence methods shall preserve contradiction and dispute. Conflicting Node sources shall not be automatically reconciled by AI, dashboard logic, model output, provider assertion, sponsor assertion, host assertion, public authority interest, or institutional preference.

9.3.2(f) Missing, stale, spoofed, tampered, corrupted, incomplete, synthetic, contested, biased, provider-influenced, sponsor-influenced, or public-safe-defective Node evidence shall be qualified, downgraded, restricted, routed for review, corrected, superseded, withdrawn, archived, or excluded as appropriate.

9.3.2(g) Node evidence methods shall not permit evidence to be treated as certification, recognition, finance-readiness, public authority decision, procurement approval, provider preference, sponsor approval, protocol effect, public warning, emergency command, operational clearance, or execution consequence by default.

9.3.2(h) The controlling rule shall be that Node evidence becomes institutionally usable only when its source, status, method, confidence, uncertainty, limitations, public-safe status, and correction path are recorded.

***

9.3.3 Node Readiness Methods.\
9.3.3(a) GCRI Canada may steward Node readiness methods for assessing whether a Node has sufficient evidence, records, safeguards, data governance, compute controls, communications context, public-safe controls, cybersecurity controls, privacy controls, sovereign data controls, protected knowledge controls, host interfaces, public authority interfaces, provider interfaces, and correction pathways to support a defined Observatory purpose.

9.3.3(b) Node readiness methods shall distinguish evidence readiness, data readiness, compute readiness, communications readiness, sensor readiness, cybersecurity readiness, public-safe readiness, correction readiness, host-interface readiness, public authority learning readiness, community safeguards readiness, provider-interface readiness, and publication readiness.

9.3.3(c) Node readiness shall not mean finance-readiness, capital-readiness, insurance-readiness, investment readiness, procurement readiness, provider readiness, host approval, certification readiness, recognition readiness, protocol readiness, public authority readiness, public warning readiness, operational readiness, deployment readiness, or execution readiness by default.

9.3.3(d) Node readiness methods shall identify readiness criteria, source records, required controls, missing controls, responsible custodian, review status, confidence, uncertainty, limitations, public-safe status, permitted use, prohibited use, and correction path.

9.3.3(e) Readiness indicators shall be governed by controlled vocabulary and shall avoid terms such as “approved,” “certified,” “validated,” “verified,” “deployment-ready,” “investment-ready,” “bankable,” “recognized,” “Nexus-compatible,” “safe,” “official,” or similar status language unless separately authorized by competent authority and proper record.

9.3.3(f) Where readiness methods are used in dashboards, maps, Evidence Packs, Decision Packs, public authority learning materials, GRF inputs, GRA inputs, Protocol Authority inputs, provider-facing materials, sponsor-facing materials, host-facing materials, Academy materials, or public-safe summaries, the output shall include boundary language sufficient to prevent overclaim.

9.3.3(g) Node readiness methods shall be corrected where readiness status is based on incomplete evidence, stale evidence, misclassified evidence, missing safeguards, unreviewed compute, unapproved data, public-safe defects, provider influence, sponsor influence, host overclaim, public authority ambiguity, or correction failure.

9.3.3(h) The controlling rule shall be that Node readiness is readiness for evidence and observability within recorded limits, not readiness for finance, procurement, authority, certification, recognition, protocol effect, operation, or execution.

***

9.3.4 Node Data Governance Methods.\
9.3.4(a) GCRI Canada shall steward Node data governance methods for the classification, permissioning, access control, use control, transfer control, retention, deletion, sealing, archival, public-safe treatment, and correction of data associated with an Observatory Node.

9.3.4(b) Node data governance methods shall identify data source, owner where known, custodian, steward, lawful basis where applicable, license, permissions, consent or non-consent treatment where applicable, public authority restrictions, community protocols, Indigenous protocols where applicable, protected knowledge restrictions, host restrictions, provider restrictions, sponsor restrictions, and permitted-use limits.

9.3.4(c) Node data shall be classified for personal information status, rights-bearing data status, health-sensitive status, cyber-sensitive status, infrastructure-sensitive status, sovereign data status, public authority status, finance-sensitive status, commercially sensitive status, community-protected status, Indigenous or protected knowledge status, confidential-source status, privileged-material status, controlled-technology status, export-control sensitivity, sanctions sensitivity, access class, handling class, public-safe status, and correction path.

9.3.4(d) Node data governance methods shall govern ingestion, transformation, storage, indexing, retrieval, embedding, AI use, compute use, dashboard use, map use, API use, publication use, sharing, deletion, sealing, archival, and legal hold.

9.3.4(e) Node data shall not be moved, copied, embedded, retrieved, trained on, fine-tuned on, vendor-processed, publicly summarized, dashboarded, mapped, API-exposed, or shared across rooms, programs, entities, jurisdictions, providers, sponsors, public authority contexts, finance-facing contexts, or public audiences without recorded authority and appropriate safeguards.

9.3.4(f) Node data governance methods shall support data minimization, purpose limitation, source protection, privacy preservation, cybersecurity protection, sovereign data control, compute-to-data treatment where appropriate, safe-location treatment, public-safe publication, and correction propagation.

9.3.4(g) Where Node data governance defects are detected, including unauthorized access, unauthorized transfer, unauthorized AI use, unauthorized embedding, unauthorized publication, classification error, stale permission, unpropagated correction, deletion failure, sealing failure, or public-safe defect, GCRI Canada shall restrict, correct, delete, seal, reclassify, notify where required, and review affected outputs and dependencies.

9.3.4(h) The controlling rule shall be that Node data is governed evidence material, and its local origin does not reduce the need for authority, classification, safeguards, and correctionability.

***

9.3.5 Node Cybersecurity Methods.\
9.3.5(a) GCRI Canada shall steward Node cybersecurity methods for protecting Node-related evidence, systems, sensors, communications, compute, dashboards, maps, APIs, repositories, access controls, logs, credentials, secrets, keys, tokens, public-safe outputs, and correction pathways.

9.3.5(b) Node cybersecurity methods shall identify cyber-sensitive data, infrastructure-sensitive data, credentials, secrets, keys, tokens, access controls, identity controls, device controls, sensor security, network security, API security, repository security, dashboard security, map security, compute environment security, logging, monitoring, anomaly detection, incident path, and correction path.

9.3.5(c) Node cybersecurity methods shall address risks of unauthorized access, credential compromise, sensor tampering, signal spoofing, telemetry corruption, cyber log exposure, prompt injection, tool misuse, API misuse, repository compromise, dashboard manipulation, map manipulation, data exfiltration, malware, denial of service, cross-tenant access, cross-program access, cross-entity access, cross-border access, and side-channel leakage.

9.3.5(d) Node cybersecurity methods shall include least privilege, segmentation, isolation, encryption where appropriate, secure configuration, vulnerability review, dependency review, key management, token management, secrets management, credential rotation, logging, monitoring, access review, incident response, backup treatment, recovery treatment, and decommissioning controls proportionate to risk.

9.3.5(e) Cybersecurity methods shall not require unsafe public disclosure of vulnerabilities, exploit details, credentials, security controls, infrastructure topology, incident details, or sensitive telemetry. Public-safe cyber disclosure shall use responsible non-disclosure, aggregation, generalization, controlled annexes, or restricted notice where appropriate.

9.3.5(f) Node cybersecurity status shall not be marketed or treated as certification, compliance determination, security certification, procurement approval, provider endorsement, public authority approval, operational clearance, guarantee, insurance-readiness, or execution readiness by default.

9.3.5(g) Where Node cybersecurity incidents or defects are detected, GCRI Canada shall preserve logs where safe, restrict access, rotate credentials where needed, disable affected systems where appropriate, assess exposure, correct records, notify affected interfaces where required, and review affected outputs and dependencies.

9.3.5(h) The controlling rule shall be that Node observability must not weaken the security of the systems, people, records, or infrastructure it observes.

***

9.3.6 Node AI / Model Governance Methods.\
9.3.6(a) GCRI Canada shall steward Node AI and model governance methods for any material AI, machine learning, statistical, simulation, digital twin, retrieval, embedding, classification, forecasting, inference, agentic, dashboard, map, or public-safe communication system used in relation to an Observatory Node.

9.3.6(b) Node AI and model governance methods shall identify model identity, model version, Model Register entry, Model Card, System Card, Dataset Card where applicable, Benchmark Card where applicable, deployment context, compute environment, retrieval sources, embedding stores, permitted uses, prohibited uses, data classes, evidence classes, output classes, human review requirements, output review requirements, public-safe status, access controls, logging, monitoring, incident path, lifecycle path, and correction path.

9.3.6(c) AI used for Node evidence shall be limited to approved purposes, including source comparison support, anomaly identification, summarization support, classification support, translation support, dashboard support, map support, public-safe drafting support, simulation support, digital twin support, degraded-mode analysis support, and correction support, subject to human review where material.

9.3.6(d) Node AI shall not generate official truth, public warning, emergency command, public authority decision, finance-readiness, procurement approval, certification, recognition, protocol effect, provider preference, sponsor approval, host approval, operational clearance, infrastructure operation, market authority, or execution consequence by default.

9.3.6(e) Node AI and model governance methods shall restrict training, fine-tuning, embedding, retrieval, vendor model improvement, public AI tool use, agentic action, sensitive prompts, uploads, pastes, copies, side channels, deletion pathways, unlearning limits, and model-connected data use according to Part VIII.

9.3.6(f) AI outputs affecting Node evidence, Node readiness, Node dashboards, Node maps, Node public-safe outputs, Node public authority materials, Node provider materials, Node sponsor materials, Node host materials, Node community-facing materials, or Node correction records shall have Inference Records and Human Review Records where material.

9.3.6(g) Where Node AI produces hallucination, false citation, bias, drift, unsafe output, retrieval leakage, embedding leakage, public authority overclaim, finance overclaim, provider preference, sponsor validation, protected knowledge exposure, or correction failure, GCRI Canada shall restrict, correct, suspend, retire, or replace the affected model or workflow and review affected outputs.

9.3.6(h) The controlling rule shall be that AI may support Node observability only as governed evidence assistance, not as autonomous Node authority.

***

9.3.7 Node Sensor Calibration and Integrity Methods.\
9.3.7(a) GCRI Canada shall steward Node sensor calibration and integrity methods for sensors, reference sensors, AI-RAN signal sources, O-RAN signal sources, private wireless signal sources, DePIN telemetry sources, cyber telemetry sources, geospatial instruments, Earth observation inputs, satellite inputs, digital twin inputs, laboratory instruments, field instruments, and related observability components associated with a Node.

9.3.7(b) Sensor calibration and integrity methods shall identify sensor identity where safe, sensor class, source class, owner where known, custodian, steward, calibration status, calibration method, calibration date, calibration authority where any, maintenance status, placement context, timestamp treatment, location or safe-location treatment, sampling method, data quality, failure modes, drift risk, spoof risk, tamper risk, environmental constraints, public-safe status, and correction path.

9.3.7(c) Node sensor methods shall distinguish calibrated readings, uncalibrated readings, reference readings, estimated readings, derived readings, model-assisted readings, inferred readings, synthetic readings, simulated readings, test readings, stale readings, missing readings, degraded-mode readings, disputed readings, and corrected readings.

9.3.7(d) Sensor integrity methods shall include custody review, configuration review, firmware or software status where material, security review, access review, tamper-evidence where appropriate, anomaly detection, comparison with reference sources where available, timestamp validation, location validation, and correction propagation.

9.3.7(e) Sensor outputs shall not be treated as correct merely because they are real-time, machine-generated, high-resolution, dashboard-visible, provider-supplied, sponsor-supported, public authority-relevant, cryptographically logged, or consistent with expectations.

9.3.7(f) Where sensor data are missing, stale, spoofed, tampered, corrupted, miscalibrated, mislocated, mis-timestamped, incomplete, contested, or otherwise unreliable, Node outputs shall be downgraded, qualified, restricted, corrected, superseded, withdrawn, or routed for review as appropriate.

9.3.7(g) Sensor calibration or integrity records shall not create certification, compliance approval, public authority approval, provider endorsement, procurement preference, finance-readiness, operational clearance, public warning, emergency command, protocol effect, or execution consequence by default.

9.3.7(h) The controlling rule shall be that Node sensor evidence depends not on the presence of a signal, but on the recorded integrity of the instrument, context, custody, calibration, and correction path.

***

9.3.8 Node Public-Safe Output Methods.\
9.3.8(a) GCRI Canada shall steward Node public-safe output methods for any Node-related public-safe summary, dashboard, map, report, technical note, API, dataset, Academy material, repository note, media material, community-facing output, public authority learning material, GRF-facing summary, GRA-facing summary, Protocol Authority-facing summary, provider-facing material, sponsor-facing material, host-facing material, or public claim.

9.3.8(b) Node public-safe output methods shall review source lineage, data class, evidence class, output class, confidence, uncertainty, limitations, geospatial precision, dashboard labels, map markers, API fields, metadata, file names, captions, public authority references, provider references, sponsor acknowledgments, host references, community references, protected knowledge risk, privacy risk, cybersecurity risk, sovereign data risk, finance risk, procurement risk, and downstream reuse risk.

9.3.8(c) Node public-safe outputs shall not disclose or enable misuse of personal information, rights-bearing data, health-sensitive data, cyber-sensitive information, infrastructure-sensitive information, public authority restricted information, sovereign-sensitive information, finance-sensitive information, community-protected information, Indigenous or protected knowledge, confidential source information, privileged material, credentials, secrets, keys, tokens, controlled technology, exploit details, sensitive locations, or unsafe metadata.

9.3.8(d) Node public-safe outputs shall include, where material, public-safe omissions, responsible non-disclosure basis, confidence, uncertainty, limitations, stale-data treatment, correction status, permitted use, prohibited use, no-public-warning language, no-emergency-command language, no-public-authority language, no-finance language, no-procurement language, no-certification language, no-recognition language, no-protocol-effect language, no-provider-endorsement language, no-sponsor-approval language, and correction path.

9.3.8(e) Node dashboards and maps shall be reviewed for hotspot implication, public warning implication, emergency-command implication, geospatial sensitivity, infrastructure exposure, public authority implication, finance implication, provider preference, sponsor validation, false precision, overconfident colors, misleading legends, drill-down risk, export risk, API exposure, and stale-data risk.

9.3.8(f) Where Node outputs cannot be made public-safe without distorting evidence or disclosing unsafe information, GCRI Canada may use controlled annexes, controlled-room review, aggregation, generalization, safe-location treatment, delayed release, responsible non-disclosure, or no-publication treatment.

9.3.8(g) Where Node public-safe outputs are corrected, restricted, superseded, withdrawn, retracted, misused, or made stale by later evidence, GCRI Canada shall update public-safe output records and review affected dependencies.

9.3.8(h) The controlling rule shall be that Node public-safe outputs must make local evidence intelligible without making local people, systems, authorities, communities, hosts, or infrastructure unsafe or overclaimed.

***

9.3.9 Node Host Interface Methods.\
9.3.9(a) GCRI Canada shall steward Node host interface methods for interactions with hosts associated with an Observatory Node, including hosts providing facilities, local context, infrastructure context, sensor access, compute context, operational context in public-safe or controlled form, community context, participation records, evidence review, public-safe learning, and correction support.

9.3.9(b) Host interface methods shall identify host identity, host role, facility or site context where safe and material, infrastructure context, community context, jurisdiction, public authority relevance, provider relevance, sponsor relevance, Project SPV relevance, National Company relevance, data classes, evidence classes, access class, handling class, public-safe status, protected knowledge status, privacy status, cybersecurity status, sovereign data status, permitted use, prohibited use, publication limits, safe-location treatment, and correction path.

9.3.9(c) Host-provided materials may include field observations, facility records, sensor records, infrastructure observations, environmental observations, local risk context, resilience context, operational constraints, participation information, community concerns, and public-safe learning needs, provided that such materials are classified, permissioned, safeguarded, and records-valid before material use.

9.3.9(d) GCRI Canada shall not use Node host interfaces to operate host infrastructure, direct host personnel, control facilities, issue public warnings, command emergency response, approve host procurement, approve host financing, certify host readiness, recognize host status, endorse host claims, approve Project SPV execution, or create public authority decisions.

9.3.9(e) Host participation, facility access, data contribution, infrastructure context, sponsor support, provider involvement, dashboard visibility, map visibility, or Node designation shall not imply host approval, host endorsement, host certification, host recognition, finance-readiness, procurement approval, public authority approval, provider preference, sponsor validation, operational clearance, or execution consequence.

9.3.9(f) Host-facing Node materials shall include boundary language where material, including no-operation, no-public-warning, no-public-authority, no-finance, no-procurement, no-certification, no-recognition, no-provider-endorsement, no-sponsor-approval, no-host-approval, and no-execution language.

9.3.9(g) Where host interface materials are corrected, restricted, superseded, withdrawn, retracted, reclassified, or misused, GCRI Canada shall notify or signal affected host interfaces where appropriate and review downstream dependencies.

9.3.9(h) The controlling rule shall be that a host may ground Node evidence, but host participation does not turn Node evidence into host approval, operation, certification, finance, procurement, or execution.

***

9.3.10 Node Public Authority Interface Methods.\
9.3.10(a) GCRI Canada shall steward Node public authority interface methods for public authority learning, evidence literacy, systems-risk learning, observability literacy, public-safe interpretation, scenario learning, technical methods awareness, correction discipline, and controlled review related to an Observatory Node.

9.3.10(b) Public authority interface methods shall identify the public authority, participating office or function where appropriate, participant capacity, official or non-official status, data-sharing authority, public authority data restrictions, access limits, publication limits, agency reference controls, permitted use, prohibited use, public-safe status, handling class, retention treatment, correction path, and boundary language.

9.3.10(c) Node public authority interfaces may include controlled rooms, public authority rooms, secure briefings, Evidence Packs, Decision Packs, public-safe summaries, controlled annexes, dashboards, maps, APIs, technical notes, Academy materials, Verifiable Intelligence outputs, Verifiable Compute records, source comparison records, and correction signals.

9.3.10(d) GCRI Canada shall not use Node public authority interfaces to create public authority decisions, official guidance, regulatory approvals, procurement approvals, funding approvals, public finance approvals, public warnings, emergency commands, public health orders, public safety directives, enforcement positions, safe harbors, permits, licenses, sovereign obligations, or delegated public power.

9.3.10(e) Public authority attendance, participation, data contribution, comments, questions, room access, dashboard access, map access, public-safe summary receipt, agency reference, regulator-listening presence, emergency-management presence, procurement presence, or public finance presence shall not imply endorsement, adoption, approval, delegation, funding relevance, procurement relevance, official status, warning status, or public-law status.

9.3.10(f) Node public authority-facing outputs shall include non-delegation, non-endorsement, non-regulatory, non-procurement, non-funding, non-public-finance, no-public-warning, no-emergency-command, confidence, uncertainty, limitation, permitted-use, prohibited-use, and correction language where material.

9.3.10(g) Where public authority interface materials are corrected, restricted, superseded, withdrawn, retracted, or materially reclassified, GCRI Canada shall notify or signal affected public authority interfaces where appropriate and review affected dependencies.

9.3.10(h) The controlling rule shall be that Node public authority interfaces may support public learning, but public authority remains with public authorities.

***

9.3.11 Node Provider Interface Methods Without Provider Preference.\
9.3.11(a) GCRI Canada shall steward Node provider interface methods for interactions with providers supplying data, tooling, equipment, AI systems, compute environments, dashboards, maps, sensors, reference sensors, AI-RAN systems, O-RAN systems, private wireless systems, DePIN systems, cyber tools, geospatial tools, digital twin tools, APIs, repositories, public-good software components, technical baseline components, integration support, validation-sprint support, benchmark support, public-safe demonstrations, or correction support.

9.3.11(b) Provider interface methods shall identify provider identity, provider role, provider materials, provider systems, provider data, provider tools, provider equipment, provider staff or representatives where material, permitted use, prohibited use, data classes, evidence classes, output classes, access class, handling class, public-safe status, commercial sensitivity, IP sensitivity, cybersecurity sensitivity, export-control sensitivity, sanctions sensitivity, conflict status, influence controls, benchmark conditions, validation conditions, publication limits, and correction path.

9.3.11(c) Provider-supplied materials shall not be treated as neutral, valid, complete, independent, public-safe, benchmark-ready, procurement-ready, finance-ready, certified, recognized, protocol-effective, Nexus-compatible, or execution-ready merely because supplied by a reputable provider, widely adopted provider, technically advanced provider, public authority-used provider, sponsor-supported provider, or Nexus-participating provider.

9.3.11(d) Provider interface methods shall preserve provider neutrality. GCRI Canada shall not use Node provider interfaces to endorse providers, rank providers for procurement, award vendor status, create public tender advantage, imply preferred-provider status, validate provider marketing claims, certify provider technology, create Nexus-compatible status, create Protocol Authority effect, create finance-readiness, or create execution readiness by default.

9.3.11(e) Provider benchmarks, validation sprints, demonstrations, pilots, integrations, dashboards, maps, AI outputs, sensor outputs, compute outputs, or technical notes shall identify provider role, provider-supplied configuration, provider-supplied data, provider-supplied environment, limitations, conflicts, influence controls, confidence, uncertainty, permitted claims, prohibited claims, public-safe status, and correction path.

9.3.11(f) Provider access to Node records, controlled rooms, data rooms, clean rooms, compute environments, retrieval sources, embedding stores, dashboards, maps, APIs, repositories, public-good software, or technical baselines shall be role-based, purpose-bound, least-privilege, logged, time-bound where appropriate, revocable, and subject to confidentiality, cybersecurity, privacy, sovereign data, protected knowledge, public-safe, and boundary controls.

9.3.11(g) Where provider interface use creates provider preference, procurement implication, public authority implication, finance implication, sponsor validation, data leakage, IP dispute, cyber risk, benchmark overclaim, public-safe defect, or correction failure, GCRI Canada shall restrict access, hold outputs, correct records, revise public-safe materials, suspend the interface, or require remedial action.

9.3.11(h) The controlling rule shall be that provider participation may support Node evidence, but it shall not create provider preference, procurement advantage, certification, recognition, finance-readiness, protocol effect, or execution authority.

***

9.3.12 Node Records, Custody, Classification, Access, Maintenance, Incident, Correction, and Closeout.\
9.3.12(a) GCRI Canada shall maintain, or cause to be maintained, Node records for material Observatory Nodes, including records of Node purpose, scope, source records, data records, compute records, model records, sensor records, dashboard records, map records, API records, host interface records, public authority interface records, provider interface records, sponsor-related records where any, community records where any, public-safe outputs, incidents, corrections, dependencies, maintenance, and closeout.

9.3.12(b) Node custody records shall identify owner where known, GCRI Canada responsible function where applicable, custodian, steward, host contact where applicable, provider contact where applicable, public authority contact where applicable, community contact where applicable, repository location, record location, compute environment, data environment, dashboard environment, map environment, access controls, logging controls, and correction authority.

9.3.12(c) Node classification records shall identify data class, evidence class, output class, access class, handling class, public-safe status, public authority status, finance-sensitive status, provider-sensitive status, sponsor-sensitive status, host-sensitive status, community-protected status, Indigenous or protected knowledge status, privacy status, cybersecurity status, sovereign data status, legal sensitivity, export-control sensitivity, sanctions sensitivity, and publication limits.

9.3.12(d) Node access records shall identify authorized users, roles, organizations, capacities, access purpose, access duration, room rules where any, no-download status where any, retrieval permissions, embedding permissions, AI-use permissions, export limits, publication limits, confidentiality obligations, conflict status where material, review status, logging, monitoring, revocation path, and closeout requirements.

9.3.12(e) Node maintenance records shall identify review cycle, sensor maintenance where applicable, calibration review, compute environment review, model review, dataset review, dashboard review, map review, API review, cybersecurity review, public-safe review, host-interface review, public authority-interface review, provider-interface review, correction review, and assurance review.

9.3.12(f) Node incident records shall identify sensor failure, calibration failure, data error, unauthorized access, data leakage, cyber event, retrieval leakage, embedding leakage, AI incident, provider overclaim, sponsor overclaim, host overclaim, public authority overclaim, public-safe defect, dashboard error, map error, API error, protected knowledge exposure, privacy incident, sovereign data issue, or correction failure affecting the Node.

9.3.12(g) Node correction records shall identify corrected source, corrected data, corrected method, corrected compute, corrected model, corrected sensor state, corrected dashboard, corrected map, corrected API, corrected public-safe output, corrected interface material, prior status, corrected status, effective date, reviewer, affected dependencies, notice decision, access change, archive treatment, and continuing limitations.

9.3.12(h) Node closeout records shall identify completion, suspension, termination, retirement, archive, data return, data deletion, data sealing, access revocation, credential revocation, room closure, sensor decommissioning where applicable, compute decommissioning where applicable, dashboard removal where applicable, map removal where applicable, outstanding corrections, outstanding notices, retained records, archive status, public-safe obligations, confidentiality obligations, protected knowledge obligations, public authority obligations, provider obligations, sponsor obligations, host obligations, and continuing prohibited uses.

9.3.12(i) Node records shall be linked, where applicable, to the Observatory Methods Register, Evidence Register entries, Source Comparison Records, Dataset Register entries, Model Register entries, System Card entries, Benchmark Card entries, Compute Workload Records, Compute Environment Records, Inference Records, Human Review Records, Retrieval and Embedding Records, Proof Receipt Records, Public-Safe Output Records, AI Incident Records, Correction Records, Dependency Records, Truth Engine Records, public authority records, GRF interface records, GRA interface records, Protocol Authority interface records, provider records, sponsor records, host records, community records, Nexus interface records, and public claims records.

9.3.12(j) Node records, custody, classification, access, maintenance, incident, correction, and closeout shall not create certification, recognition, finance-readiness, public authority decision, procurement approval, provider endorsement, sponsor approval, host approval, rating, guarantee, public warning, emergency command, protocol effect, operational clearance, legal status, market authority, infrastructure operation, or execution consequence by default.

9.3.12(k) The controlling rule shall be that every material Node must remain traceable through custody, classification, access, maintenance, incident, correction, and closeout records because local observability is trustworthy only when its institutional memory is complete.

### 9.4 Observatory Hub Methods

9.4.1 Observatory Hub as Coordination, Evidence Aggregation, Technical Support, and Public-Safe Interface Surface.\
9.4.1(a) An Observatory Hub shall be treated, for GCRI Canada’s technical-stewardship purposes, as a coordination, evidence aggregation, technical support, public-safe interface, and correction surface connecting multiple Observatory Nodes, source classes, datasets, compute workloads, dashboards, maps, public authority learning contexts, host contexts, provider contexts, university contexts, community contexts, sponsor-supported contexts where any, and Nexus interface records.

9.4.1(b) A Hub may support the organization of Node evidence, sensor evidence, AI-RAN evidence, O-RAN evidence, private wireless evidence, DePIN telemetry, cyber evidence, geospatial evidence, Earth observation evidence, digital twin outputs, simulations, field observations, host records, public authority context, community context, university or laboratory outputs, provider materials, sponsor materials, public-safe summaries, Evidence Packs, Decision Packs, dashboards, maps, APIs, technical notes, Verifiable Compute records, Verifiable Intelligence records, Proof Receipts, and correction signals.

9.4.1(c) A Hub may be geographic, regional, national, technological, sectoral, functional, institutional, public authority-facing, host-facing, provider-facing, community-facing, university-linked, infrastructure-linked, risk-domain-linked, resilience-linked, degraded-mode-linked, or otherwise defined by recorded Observatory methods.

9.4.1(d) A Hub shall not be treated as a legal entity, public authority body, emergency-management body, infrastructure operator, telecommunications operator, finance vehicle, procurement body, certification body, recognition body, Protocol Authority body, provider consortium, sponsor-controlled vehicle, National Company, Project SPV, market platform, or execution vehicle by default.

9.4.1(e) Hub methods shall support coordination only in the evidentiary, methodological, technical, learning, public-safe, and correction sense. They shall not authorize GCRI Canada to direct infrastructure, command response, issue warnings, approve providers, approve procurement, create finance-readiness, recognize status, certify technologies, confer protocol effect, bind hosts, bind public authorities, bind National Companies, bind Project SPVs, or execute deployments.

9.4.1(f) Where a Hub is used to connect actors, rooms, records, dashboards, maps, APIs, Evidence Packs, Decision Packs, public-safe outputs, GRF inputs, GRA inputs, Protocol Authority inputs, public authority learning outputs, provider materials, sponsor materials, host materials, community-facing materials, or Academy materials, the Hub shall preserve legal separateness, role separation, access controls, public-safe controls, source lineage, confidence, uncertainty, limitations, boundary language, and correction path.

9.4.1(g) Hub terminology shall be governed by controlled vocabulary and shall not be used publicly in a manner that implies official regional status, public authority adoption, public warning function, emergency coordination authority, finance-readiness, investment zone, procurement grouping, certified cluster, recognized status, protocol status, provider preference, sponsor approval, host approval, operational clearance, market authority, or execution mandate.

9.4.1(h) The controlling rule shall be that an Observatory Hub is a public-good evidence and coordination surface, not an authority-bearing institution or execution structure.

***

9.4.2 Hub Scope and Boundary Controls.\
9.4.2(a) GCRI Canada shall define the scope and boundaries of each material Observatory Hub by record, including its purpose, geographic or functional scope, Node relationships, source classes, data classes, evidence classes, output classes, public-safe status, access class, handling class, public authority relevance, finance relevance where any, provider relevance, sponsor relevance, host relevance, community relevance, protected knowledge relevance, technology domains, risk domains, and correction path.

9.4.2(b) Hub scope records shall identify whether the Hub is internal, controlled-room, public authority learning, GRF-facing, GRA-facing, Protocol Authority-facing, provider-facing, sponsor-facing, host-facing, community-facing, Academy-facing, public-safe, regional, national, cross-border, technology-specific, risk-specific, degraded-mode-specific, or public-facing.

9.4.2(c) Hub boundary controls shall identify what the Hub may do and what it may not do. Permitted Hub functions may include evidence aggregation, source comparison support, public-safe routing, dashboard support, map support, technical baseline support, public authority learning support, GRF input support, GRA input support, Protocol Authority input support, provider-neutral validation support, host learning support, community learning support, university collaboration support, and correction routing.

9.4.2(d) Prohibited Hub functions shall include issuing public warnings, issuing emergency commands, making public authority decisions, regulating providers, approving procurement, selecting vendors, approving finance, creating finance-readiness, issuing ratings, giving guarantees, recognizing status, certifying technologies, creating protocol effect, operating infrastructure, controlling hosts, controlling providers, controlling National Companies, controlling Project SPVs, binding GCRI Canada, or creating execution consequence.

9.4.2(e) Hub boundaries shall preserve separation among GCRI Canada, GCRI US, The Global Risks Forum (GRF), The Global Risks Alliance (GRA), Nexus Standards / Protocol Authority, Nexus entities, Regional Nexus Consortiums, National Nexus Consortiums, National Companies, Project SPVs, public authorities, providers, sponsors, hosts, universities, communities, and other actors.

9.4.2(f) Where Hub scope overlaps with public authority, finance, procurement, provider, sponsor, host, community, National Company, Project SPV, GRF, GRA, or Protocol Authority contexts, the Hub record shall include audience-specific boundary language, access controls, permitted-use limits, prohibited-use limits, reference controls, correction obligations, and dependency review requirements.

9.4.2(g) Where Hub scope or boundaries are ambiguous, the narrower, safer, more source-lined, more public-safe, more role-separated, more provider-neutral, more sponsor-independent, and more correctionable interpretation shall prevail until competent review records otherwise.

9.4.2(h) The controlling rule shall be that Hub value depends on defined scope and boundary discipline because evidence aggregation without boundaries can become unauthorized coordination, approval, or execution by implication.

***

9.4.3 Hub Evidence Aggregation Methods.\
9.4.3(a) GCRI Canada shall steward Hub evidence aggregation methods for receiving, organizing, comparing, qualifying, public-safe summarizing, and correcting evidence from multiple Nodes, source classes, datasets, systems, actors, rooms, dashboards, maps, APIs, and interfaces.

9.4.3(b) Hub evidence aggregation methods shall identify source records, included Nodes, excluded Nodes where material, inclusion criteria, exclusion criteria, data lineage, source lineage, source authority, source permission, source independence, source reliability, source timeliness, source completeness, source bias, custody, public-safe status, correction status, and dependency relationships.

9.4.3(c) Hub evidence may include Node evidence, sensor records, AI-RAN signals, O-RAN signals, private wireless signals, DePIN telemetry, cyber logs, geospatial data, Earth observation data, satellite data, digital twin outputs, simulation outputs, field observations, host data, public authority context, community observations, Indigenous or protected knowledge context where applicable, provider data, sponsor data, university or laboratory outputs, public records, historical records, dashboards, maps, and public-safe summaries.

9.4.3(d) Hub aggregation shall distinguish aggregation from corroboration. The presence of multiple sources in a Hub shall not itself establish agreement, truth, confidence, readiness, resilience, risk level, public warning status, finance status, recognition status, certification status, provider preference, sponsor validation, protocol status, or execution status.

9.4.3(e) Hub aggregation methods shall identify conflict, contradiction, missing evidence, stale evidence, duplicated evidence, overrepresented sources, underrepresented sources, biased sources, provider-influenced evidence, sponsor-influenced evidence, public authority-sensitive evidence, community-sensitive evidence, protected knowledge constraints, and public-safe omissions.

9.4.3(f) Aggregated evidence shall preserve context. GCRI Canada shall prevent context collapse across jurisdictions, technologies, communities, time periods, public authority contexts, finance contexts, provider contexts, sponsor contexts, host contexts, confidence states, uncertainty states, public-safe states, correction states, and output classes.

9.4.3(g) Where Hub aggregation supports dashboards, maps, reports, Evidence Packs, Decision Packs, public-safe summaries, GRF inputs, GRA inputs, Protocol Authority inputs, public authority learning materials, provider-facing materials, sponsor-facing materials, host-facing materials, community-facing materials, or public claims, the aggregation record shall identify confidence, uncertainty, limitations, permitted use, prohibited use, boundary language, and correction path.

9.4.3(h) The controlling rule shall be that Hub evidence aggregation must make relationships visible without making unsupported relationships authoritative.

***

9.4.4 Hub Data Minimization, Sovereign Data, Compute-to-Data, and Public-Safe Routing Methods.\
9.4.4(a) GCRI Canada shall steward Hub methods for data minimization, sovereign data control, compute-to-data treatment, controlled-room routing, public-safe routing, and restricted-data protection across Hub evidence flows.

9.4.4(b) Data minimization methods shall require that a Hub collect, receive, access, retrieve, embed, compute upon, dashboard, map, summarize, publish, or route only the data necessary for the recorded Hub purpose, output class, audience, and correction path.

9.4.4(c) Hub methods shall prefer summaries, derived indicators, redacted records, aggregated records, generalized geospatial treatment, safe-location treatment, controlled annex references, compute-to-data outputs, and public-safe outputs where full source data are unnecessary or unsafe to move.

9.4.4(d) Sovereign data methods shall identify data residency, localization, cross-border transfer status, public authority data zones, Indigenous data considerations, community data safeguards, national data infrastructure requirements, cloud region, support access, subprocessors, backup location, archive location, deletion obligations, sealing obligations, and jurisdictional access limits.

9.4.4(e) Compute-to-data methods shall be used where restricted data, sovereign-sensitive data, public authority data, personal information, health-sensitive data, cyber-sensitive data, infrastructure-sensitive data, finance-sensitive data, community-protected data, Indigenous or protected knowledge, confidential source information, privileged materials, or other sensitive materials should be analyzed without moving or exposing underlying records beyond approved controls.

9.4.4(f) Public-safe routing methods shall determine whether Hub materials may be routed internally, to controlled rooms, to public authority rooms, to GRF interfaces, to GRA interfaces, to Protocol Authority interfaces, to provider-facing rooms, to sponsor-facing rooms, to host-facing rooms, to community-facing rooms, to Academy materials, to public-safe publication, or to no-publication treatment.

9.4.4(g) Hub routing shall not permit restricted materials to be copied, downloaded, exported, embedded, trained on, retrieved into unauthorized systems, summarized publicly, mapped publicly, API-exposed, or transferred across entities, jurisdictions, rooms, programs, providers, sponsors, public authority contexts, finance contexts, or public audiences without recorded authority.

9.4.4(h) Where Hub data minimization, sovereign data, compute-to-data, or routing controls fail, GCRI Canada shall restrict access, halt routing, preserve logs where safe, review exposure, correct records, notify affected interfaces where required, reclassify outputs, and update controls.

9.4.4(i) The controlling rule shall be that Hubs should move meaning safely before they move data, and should move data only where lawful, necessary, proportionate, protected, and correctionable.

***

9.4.5 Hub Role in Regional or National Evidence Architecture.\
9.4.5(a) An Observatory Hub may serve as a regional, national, cross-border, corridor, sectoral, technological, risk-domain, resilience-domain, public authority learning, university-linked, host-linked, provider-linked, community-linked, or Nexus-linked component of a broader evidence architecture.

9.4.5(b) In regional evidence architecture, a Hub may connect Observatory Nodes, community contexts, host contexts, public authority learning contexts, university contexts, provider inputs, sponsor-supported inputs where any, infrastructure contexts, geospatial contexts, risk signals, resilience indicators, public-safe summaries, and correction pathways across a defined region.

9.4.5(c) In national evidence architecture, a Hub may support national dense Nexus core methods, national observability learning, sovereign data methods, national public authority learning, national technical baseline support, public-good software support, GRF input support, GRA input support, Protocol Authority input support, Nexus Academy materials, and public-safe publication.

9.4.5(d) A Hub’s role in regional or national evidence architecture shall not create an official regional designation, national program, public authority structure, public finance structure, procurement structure, emergency-management structure, certified region, recognized region, investment zone, provider market, sponsor territory, National Company mandate, Project SPV mandate, Protocol Authority status, infrastructure operation, or execution mandate by default.

9.4.5(e) Regional or national Hub methods shall preserve legal separateness among GCRI Canada, regional and national Nexus bodies, public authorities, hosts, communities, universities, providers, sponsors, National Companies, Project SPVs, GRF, GRA, Protocol Authority, and other actors.

9.4.5(f) Where a Hub is referenced in regional or national public-safe materials, its public meaning shall be controlled through boundary language, confidence, uncertainty, limitations, public-safe status, public authority reference controls, finance-boundary controls, procurement-boundary controls, provider-neutrality controls, sponsor non-control controls, and correction path.

9.4.5(g) Where regional or national Hub evidence is corrected, reclassified, restricted, superseded, withdrawn, retracted, or materially limited, GCRI Canada shall review affected regional or national outputs, dashboards, maps, Evidence Packs, Decision Packs, public authority learning materials, GRF inputs, GRA inputs, Protocol Authority inputs, Academy materials, and public claims.

9.4.5(h) The controlling rule shall be that a Hub may strengthen regional or national evidence architecture, but it does not create regional or national authority, finance, procurement, certification, recognition, protocol effect, or execution.

***

9.4.6 Hub Dashboard and Reporting Methods.\
9.4.6(a) GCRI Canada shall steward Hub dashboard and reporting methods for the design, classification, review, display, publication, monitoring, correction, and retirement of Hub-related dashboards, maps, reports, technical notes, APIs, datasets, public-safe summaries, controlled annexes, Evidence Packs, Decision Packs, Academy materials, and public claims.

9.4.6(b) Hub dashboards shall identify data sources, included Nodes, update cadence, stale-data treatment, indicator meaning, score meaning where any, color meaning where any, confidence display, uncertainty display, limitation display, public-safe status, public authority boundary, finance boundary, procurement boundary, provider-neutrality boundary, sponsor non-control boundary, dashboard version, access class, handling class, export controls, and correction path.

9.4.6(c) Hub reports and technical notes shall identify source lineage, methods used, evidence classes, data classes, public-safe status, controlled annex relationship, confidence, uncertainty, limitations, public-safe omissions, public authority references, provider references, sponsor acknowledgments, host references, community references, permitted use, prohibited use, boundary language, and correction path.

9.4.6(d) Hub maps shall be reviewed for geospatial precision, sensitive-site exposure, infrastructure-sensitive detail, community identifiability, protected knowledge exposure, public authority implication, public warning implication, emergency-command implication, finance implication, procurement implication, provider preference, sponsor validation, false precision, stale layers, export risk, and safe-location treatment.

9.4.6(e) Hub APIs and datasets shall be reviewed for field meaning, schema meaning, metadata exposure, access controls, rate limits where appropriate, caching, downstream reuse, sensitive-field exclusion, public-safe status, versioning, deprecation, correction propagation, and abuse detection.

9.4.6(f) Hub reporting methods shall not permit dashboard colors, map layers, heatmaps, hotspot markers, cluster markers, indicators, confidence bands, rankings, tables, charts, or AI-generated summaries to be read as public warnings, emergency commands, public authority decisions, finance-readiness, procurement approvals, certifications, recognitions, protocol effects, provider rankings, sponsor approvals, host approvals, operational clearances, or execution instructions.

9.4.6(g) Where Hub dashboards or reports become stale, inaccurate, unsafe, misclassified, overclaimed, misused, provider-preferential, sponsor-validating, public authority-confusing, finance-inflating, or correction-defective, GCRI Canada shall correct, relabel, restrict, supersede, withdraw, retract, deprecate, archive, or issue notice as appropriate.

9.4.6(h) The controlling rule shall be that Hub dashboards and reports must make aggregated evidence legible without turning display into authority.

***

9.4.7 Hub Incident and Escalation Methods.\
9.4.7(a) GCRI Canada shall steward Hub incident and escalation methods for errors, defects, disputes, boundary risks, data events, cybersecurity events, public-safe defects, overclaims, correction failures, access breaches, dashboard defects, map defects, API defects, model defects, provider issues, sponsor issues, public authority issues, host issues, community concerns, and protected knowledge concerns affecting an Observatory Hub.

9.4.7(b) Hub incidents may include unauthorized access, unauthorized data movement, unauthorized retrieval, unauthorized embedding, data leakage, cross-node contamination, cross-program contamination, cross-entity contamination, cross-border transfer defect, source corruption, sensor failure, compute defect, model drift, AI hallucination, dashboard error, map error, API error, false hotspot, false cluster, public-safe release defect, public authority overclaim, finance overclaim, procurement implication, provider preference, sponsor validation, protected knowledge exposure, privacy incident, cybersecurity incident, or correction failure.

9.4.7(c) Hub escalation methods shall identify severity, affected Nodes, affected sources, affected datasets, affected compute workloads, affected models, affected dashboards, affected maps, affected APIs, affected reports, affected public-safe outputs, affected public authority materials, affected GRF inputs, affected GRA inputs, affected Protocol Authority inputs, affected providers, affected sponsors, affected hosts, affected communities, affected dependencies, and affected public claims.

9.4.7(d) Escalation may route to evidence review, source comparison review, dataset review, compute review, model review, cybersecurity review, privacy review, sovereign data review, public authority boundary review, finance-boundary review, provider-neutrality review, sponsor non-control review, protected knowledge review, public-safe review, legal review, Board or committee review, independent review, or interface review as appropriate.

9.4.7(e) Containment may include access restriction, room restriction, data movement hold, retrieval disabling, embedding isolation, model suspension, dashboard freeze, map freeze, API restriction, publication hold, public-safe output withdrawal, credential rotation, provider access suspension, sponsor access restriction, public authority notice, host notice, community notice, controlled notice, public-safe notice, or dependency freeze.

9.4.7(f) Hub incident and escalation methods shall not themselves create public warning, emergency command, public authority decision, finance-readiness, procurement action, provider penalty, sponsor finding, certification, recognition, protocol effect, operational command, legal conclusion, market consequence, or execution consequence by default.

9.4.7(g) Where Hub incidents reveal systemic defects, GCRI Canada shall update Hub methods, interface records, access controls, dashboard controls, map controls, API controls, public-safe controls, model controls, dataset controls, provider controls, sponsor controls, training, assurance, and correction procedures.

9.4.7(h) The controlling rule shall be that Hub incidents must be escalated fast enough to prevent error from spreading across Nodes, but escalation must preserve GCRI Canada’s non-warning, non-command, and non-execution boundaries.

***

9.4.8 Hub Host, Public Authority, Provider, Community, University, and Sponsor Interface Methods.\
9.4.8(a) GCRI Canada shall steward Hub interface methods for interactions with hosts, public authorities, providers, communities, universities, sponsors, National Companies, Project SPVs, GRF, GRA, Protocol Authority, Nexus bodies, and other authorized actors participating in or affected by a Hub.

9.4.8(b) Host interface methods shall identify host role, host context, facility context where safe and material, infrastructure context, operational context in public-safe or controlled form, data classes, evidence classes, safe-location treatment, publication limits, no-operation boundary, no-host-approval boundary, no-certification boundary, no-finance boundary, and correction path.

9.4.8(c) Public authority interface methods shall identify public authority capacity, official or non-official status, data-sharing authority, public authority restrictions, public authority reference controls, non-delegation language, non-endorsement language, non-regulatory language, non-procurement language, non-funding language, non-public-finance language, no-public-warning language, no-emergency-command language, and correction path.

9.4.8(d) Provider interface methods shall identify provider role, provider materials, provider data, provider tools, provider equipment, provider AI, provider compute, provider dashboards, provider sensors, benchmark conditions, validation conditions, commercial sensitivity, IP sensitivity, cybersecurity sensitivity, provider-neutrality controls, prohibited claims, and correction path.

9.4.8(e) Community and Indigenous interface methods shall identify community context, Indigenous protocol where applicable, consent or non-consent where applicable, protected knowledge restrictions, local and territorial context, cultural context, environmental knowledge context, source protection, sensitive-site treatment, public-safe mapping limits, withdrawal or challenge pathways where applicable, accessibility, translation, localization, and do-no-harm controls.

9.4.8(f) University and laboratory interface methods shall identify research role, data contribution, method contribution, publication relationship, student or participant considerations where any, ethics or research review relationship where any, IP treatment, confidentiality, public-safe status, citation treatment, and correction path.

9.4.8(g) Sponsor interface methods shall identify sponsor role, funding or support relationship, convening support, facilities support, technology access, data access, publication limits, public authority access limits, provider access limits, conflict status, sponsor non-control language, no-outcome-purchase language, no-evidence-control language, no-publication-control language, no-recognition-control language, no-finance-control language, no-protocol-control language, and correction path.

9.4.8(h) Hub interface methods shall not permit any interface actor to convert Hub participation into endorsement, public authority approval, finance-readiness, procurement preference, certification, recognition, protocol effect, provider advantage, sponsor approval, host approval, university endorsement, community consent beyond record, or execution consequence by implication.

9.4.8(i) Where interface misuse occurs, GCRI Canada shall require correction, relabeling, removal of misleading references, public-safe clarification, controlled notice, access restriction, interface suspension, contract remedy, or legal action where appropriate.

9.4.8(j) The controlling rule shall be that Hub interfaces may bring actors into structured evidence learning, but no actor’s presence may convert evidence learning into authority, endorsement, finance, procurement, or execution.

***

9.4.9 Hub Does Not Create Public Authority, Procurement, Finance-Readiness, Certification, or Execution Authority.\
9.4.9(a) No Observatory Hub, Hub record, Hub dashboard, Hub map, Hub API, Hub Evidence Pack, Hub Decision Pack, Hub technical note, Hub public-safe output, Hub interface, Hub room, Hub report, Hub benchmark, Hub Proof Receipt, Hub correction signal, or Hub public claim shall create public authority, procurement, finance-readiness, certification, recognition, protocol effect, provider preference, sponsor approval, host approval, operational clearance, market authority, infrastructure operation, public warning, emergency command, or execution authority by default.

9.4.9(b) A Hub shall not issue official guidance, regulatory determinations, compliance determinations, enforcement positions, safe harbors, permits, licenses, procurement decisions, funding approvals, public finance approvals, public warnings, emergency commands, public health orders, public safety directives, provider rankings, vendor awards, investment advice, ratings, guarantees, insurance approvals, lending decisions, underwriting decisions, certification determinations, recognition determinations, maturity records, conformance determinations, Nexus-compatible status, role keys, smart licenses, entitlement states, or deployment instructions.

9.4.9(c) Public authority attendance, provider participation, sponsor support, host participation, university involvement, community involvement, capital-reader interest, GRF interface use, GRA interface use, Protocol Authority interface use, National Company relevance, Project SPV relevance, dashboard visibility, map visibility, public-safe publication, benchmark success, or Proof Receipt issuance shall not convert a Hub into authority.

9.4.9(d) Any authority-bearing action by a public authority, GRF, GRA, Protocol Authority, National Company, Project SPV, provider, sponsor, host, finance actor, procurement actor, infrastructure operator, university, community, or other actor shall arise only through that actor’s own lawful authority, process, record, accountability, and liability, not through the Hub by implication.

9.4.9(e) Hub materials shall include boundary language where material to prevent interpretation as public authority action, procurement action, finance-readiness, certification, recognition, protocol effect, provider preference, sponsor approval, host approval, operational clearance, market authority, infrastructure operation, public warning, emergency command, legal status, professional advice, or execution instruction.

9.4.9(f) Where Hub materials are misused to imply unauthorized authority, GCRI Canada shall correct, relabel, restrict, withdraw, reissue, require removal of misleading references, notify affected interfaces where appropriate, suspend affected interface use, or pursue contractual or legal remedies where appropriate.

9.4.9(g) No ambiguity shall be resolved in favour of Hub authority. Where there is doubt whether a Hub creates authority or only supports evidence, the interpretation preserving GCRI Canada’s non-execution role, public authority boundaries, finance boundaries, procurement neutrality, provider neutrality, sponsor non-control, GRF role separation, GRA role separation, Protocol Authority role separation, validity-by-record, correctionability, and public trust shall prevail.

9.4.9(h) The controlling rule shall be that a Hub coordinates evidence and learning; it does not govern, finance, procure, certify, recognize, warn, command, operate, or execute.

***

9.4.10 Hub Records, Review, Correction, Supersession, and Closeout.\
9.4.10(a) GCRI Canada shall maintain, or cause to be maintained, Hub records for material Observatory Hubs, including records of Hub purpose, scope, included Nodes, source records, data records, compute records, model records, dashboard records, map records, API records, interface records, public-safe outputs, incidents, corrections, dependencies, review cycles, assurance, and closeout.

9.4.10(b) Hub records shall identify Hub title or identifier, Hub type, owner where known, GCRI Canada responsible function where applicable, custodian, steward, jurisdictional context, geographic or functional scope, Node relationships, data classes, evidence classes, output classes, access class, handling class, public-safe status, public authority status, finance-sensitive status, provider-sensitive status, sponsor-sensitive status, host-sensitive status, community-protected status, Indigenous or protected knowledge status, privacy status, cybersecurity status, sovereign data status, legal sensitivity, export-control sensitivity, sanctions sensitivity, permitted uses, prohibited uses, publication limits, and correction path.

9.4.10(c) Hub review records shall identify review cycle, reviewers, source review, dataset review, compute review, model review, dashboard review, map review, API review, public-safe review, public authority boundary review, finance-boundary review, provider-neutrality review, sponsor non-control review, host-interface review, community safeguards review, cybersecurity review, privacy review, sovereign data review, protected knowledge review, and correction review.

9.4.10(d) Hub correction records shall identify corrected source, corrected Node relationship, corrected dataset, corrected method, corrected compute workload, corrected model, corrected dashboard, corrected map, corrected API, corrected public-safe output, corrected interface material, prior status, corrected status, effective date, reviewer, affected dependencies, notice decision, access change, archive treatment, and continuing limitations.

9.4.10(e) Hub supersession records shall identify replacement Hub record, changed scope, changed Node relationships, changed evidence base, changed methods, changed confidence, changed uncertainty, changed limitations, changed public-safe status, changed boundary language, changed interface status, continuing validity where any, discontinued reliance where any, and downstream dependency treatment.

9.4.10(f) Hub withdrawal or retraction records shall be used where Hub materials should no longer be used or relied upon because of material error, unsafe disclosure, public-safe defect, overclaim, boundary breach, provider-preferential framing, sponsor-validation framing, protected knowledge exposure, public authority confusion, finance overclaim, or correction failure.

9.4.10(g) Hub closeout records shall identify completion, suspension, termination, retirement, archive, data return, data deletion, data sealing, access revocation, credential revocation, room closure, dashboard removal where applicable, map removal where applicable, API deprecation where applicable, outstanding corrections, outstanding notices, retained records, archive status, public-safe obligations, confidentiality obligations, protected knowledge obligations, public authority obligations, provider obligations, sponsor obligations, host obligations, community obligations, and continuing prohibited uses.

9.4.10(h) Hub records shall be linked, where applicable, to Node records, Observatory Methods Register entries, Evidence Register entries, Source Comparison Records, Dataset Register entries, Model Register entries, System Card entries, Benchmark Card entries, Compute Workload Records, Compute Environment Records, Inference Records, Human Review Records, Retrieval and Embedding Records, Proof Receipt Records, Public-Safe Output Records, AI Incident Records, Correction Records, Dependency Records, Truth Engine Records, public authority records, GRF interface records, GRA interface records, Protocol Authority interface records, provider records, sponsor records, host records, community records, university records, Nexus interface records, and public claims records.

9.4.10(i) Hub records, review, correction, supersession, withdrawal, retraction, retirement, archive, and closeout shall not create certification, recognition, finance-readiness, public authority decision, procurement approval, provider endorsement, sponsor approval, host approval, rating, guarantee, public warning, emergency command, protocol effect, operational clearance, legal status, market authority, infrastructure operation, or execution consequence by default.

9.4.10(j) The controlling rule shall be that every material Hub must remain traceable through scope, evidence, interfaces, review, correction, supersession, and closeout because evidence aggregation is trustworthy only when the institution can show what was connected, why it was connected, what changed, and what must no longer be relied upon.

### 9.5 Observatory Cluster Methods

9.5.1 Observatory Cluster as Multi-Node, Multi-Host, Multi-Domain, or Regional Technical-Evidence Arrangement.\
9.5.1(a) An Observatory Cluster shall be treated, for GCRI Canada’s technical-stewardship purposes, as a recorded multi-Node, multi-host, multi-domain, multi-system, regional, thematic, technological, risk-domain, resilience-domain, degraded-mode, or public-safe technical-evidence arrangement within the wider Observatory architecture.

9.5.1(b) An Observatory Cluster may connect Observatory Nodes, Hubs, hosts, public authority learning contexts, community contexts, provider contexts, university or laboratory contexts, sponsor-supported contexts where any, sensor systems, AI-RAN systems, O-RAN systems, private wireless systems, DePIN telemetry sources, cyber records, geospatial records, Earth observation inputs, digital twin systems, simulations, dashboards, maps, APIs, Evidence Packs, Decision Packs, public-safe summaries, and correction records for a defined evidence purpose.

9.5.1(c) A Cluster may be organized by geography, technology domain, risk domain, infrastructure dependency, community context, public authority context, host context, provider context, degraded-mode pattern, resilience indicator, signal pattern, cyber pattern, AI-RAN pattern, O-RAN pattern, DePIN pattern, geospatial pattern, climate pattern, WEFH pattern, energy pattern, biosecurity-relevant pattern, supply-chain pattern, or other recorded Observatory method.

9.5.1(d) A Cluster shall not be treated as a legal entity, regional authority, public authority region, emergency-management structure, procurement package, investment zone, finance vehicle, certified ecosystem, recognized ecosystem, protocol class, provider market, sponsor territory, National Company mandate, Project SPV mandate, infrastructure operating unit, telecommunications operating unit, public warning area, operational command structure, or execution arrangement by default.

9.5.1(e) Cluster methods shall support evidence aggregation, comparison, interoperability, public-safe learning, continuity awareness, degraded-mode interpretation, regional or national evidence architecture, public authority learning, GRF input support, GRA input support, Protocol Authority input support, provider-neutral technical support, host learning support, community learning support, Academy materials, and correction discipline only within recorded limits.

9.5.1(f) The existence of a Cluster, cluster label, cluster dashboard, cluster map, cluster report, cluster API, cluster Evidence Pack, cluster Decision Pack, cluster public-safe output, or cluster interface shall not create public authority decision, public warning, emergency command, procurement approval, finance-readiness, certification, recognition, protocol effect, provider preference, sponsor approval, host approval, operational clearance, legal status, market authority, infrastructure operation, or execution consequence.

9.5.1(g) Where Cluster terminology is used externally or publicly, GCRI Canada shall preserve controlled vocabulary, confidence, uncertainty, limitations, no-public-warning language, no-public-authority language, no-finance language, no-procurement language, no-certification language, no-recognition language, no-protocol-effect language, no-provider-endorsement language, no-sponsor-approval language, and correction path where material.

9.5.1(h) The controlling rule shall be that an Observatory Cluster is a method-defined technical-evidence arrangement for understanding relationships across Nodes, hosts, domains, or regions, not an authority-bearing structure or execution vehicle.

***

9.5.2 Cluster Scope, Topology, and Boundary Records.\
9.5.2(a) GCRI Canada shall define the scope, topology, and boundaries of each material Observatory Cluster by record before the Cluster is used for material evidence, dashboarding, mapping, reporting, public-safe publication, public authority learning, GRF inputs, GRA inputs, Protocol Authority inputs, provider-facing materials, sponsor-facing materials, host-facing materials, community-facing materials, Academy materials, or public claims.

9.5.2(b) Cluster scope records shall identify Cluster purpose, geographic scope where any, functional scope where any, technology domains, risk domains, infrastructure domains, public authority contexts, community contexts, host contexts, provider contexts, sponsor contexts, university contexts, included Nodes, included Hubs where any, included data sources, excluded data sources where material, output classes, audience classes, access class, handling class, public-safe status, and correction path.

9.5.2(c) Cluster topology records shall identify Node relationships, Hub relationships, host relationships, source relationships, data-flow relationships, compute relationships, dashboard relationships, map relationships, API relationships, model relationships, sensor relationships, AI-RAN relationships, O-RAN relationships, private wireless relationships, DePIN relationships, cyber relationships, geospatial relationships, digital twin relationships, and dependency relationships where material.

9.5.2(d) Cluster boundary records shall identify permitted uses and prohibited uses. Permitted uses may include evidence aggregation, source comparison, interoperability review, confidence analysis, uncertainty analysis, public-safe reporting, public authority learning, technical baseline support, Nexus Academy learning, GRF input support, GRA input support, Protocol Authority input support, provider-neutral validation support, host learning support, and correction routing.

9.5.2(e) Prohibited uses shall include public warning issuance, emergency command, public authority decision-making, regulatory approval, procurement approval, vendor selection, finance-readiness, investment advice, insurance approval, lending decision, underwriting decision, rating, guarantee, certification, recognition, protocol effect, provider preference, sponsor approval, host approval, operational clearance, infrastructure operation, market authority, National Company execution, Project SPV execution, or other execution consequence.

9.5.2(f) Cluster boundary records shall preserve legal separateness and role separation among GCRI Canada, GCRI US, The Global Risks Forum (GRF), The Global Risks Alliance (GRA), Nexus Standards / Protocol Authority, Regional Nexus Consortiums, National Nexus Consortiums, National Companies, Project SPVs, public authorities, providers, sponsors, hosts, universities, communities, and other actors.

9.5.2(g) Where Cluster scope, topology, or boundaries are ambiguous, incomplete, contested, stale, unsafe, overbroad, or inconsistent with public-safe discipline, public authority boundaries, finance boundaries, provider neutrality, sponsor non-control, protected knowledge safeguards, or correctionability, the Cluster shall be held, narrowed, corrected, reclassified, restricted, or refused for material use until the record is adequate.

9.5.2(h) The controlling rule shall be that a Cluster may connect many Nodes and domains only because its scope, topology, and boundaries are recorded; without those records, clustering becomes unsafe aggregation.

***

9.5.3 Cluster Evidence Aggregation and Comparison Methods.\
9.5.3(a) GCRI Canada shall steward Cluster evidence aggregation and comparison methods for receiving, organizing, comparing, qualifying, public-safe summarizing, and correcting evidence across multiple Nodes, Hubs, hosts, source classes, technology domains, risk domains, data environments, compute environments, dashboards, maps, APIs, public authority contexts, community contexts, provider contexts, sponsor contexts, and interface records.

9.5.3(b) Cluster evidence aggregation methods shall identify included records, excluded records where material, source classes, evidence classes, data classes, method version, source authority, source independence, source reliability, source timeliness, source permission, source bias, source completeness, provenance, custody, public-safe status, correction status, supersession status, withdrawal status, retraction status where applicable, and dependency links.

9.5.3(c) Cluster evidence may include Node evidence, Hub evidence, sensor records, reference sensor records, AI-RAN signals, O-RAN signals, private wireless signals, DePIN telemetry, cyber logs, geospatial data, Earth observation data, satellite data, digital twin outputs, simulation outputs, field observations, host data, public authority context, community observations, Indigenous or protected knowledge context where applicable, provider data, sponsor data, university or laboratory outputs, public records, historical records, dashboard records, map records, API records, and public-safe summaries.

9.5.3(d) Cluster comparison methods shall distinguish source aggregation, source corroboration, source contradiction, source conflict, source absence, source staleness, source duplication, source bias, source overrepresentation, source underrepresentation, source uncertainty, source permission limits, and source public-safe limits.

9.5.3(e) GCRI Canada shall not treat evidence as corroborated merely because multiple Nodes, hosts, providers, sensors, dashboards, maps, public authority participants, sponsors, or datasets appear in a Cluster. Corroboration shall require method-based comparison and recorded support.

9.5.3(f) Cluster aggregation shall preserve context and prevent context collapse across geography, jurisdiction, time period, technology domain, risk domain, host context, community context, public authority context, finance context, provider context, sponsor context, confidence status, uncertainty status, limitation status, public-safe status, and correction status.

9.5.3(g) Where Cluster aggregation or comparison supports dashboards, maps, reports, Evidence Packs, Decision Packs, public authority learning materials, GRF inputs, GRA inputs, Protocol Authority inputs, provider-facing materials, sponsor-facing materials, host-facing materials, community-facing materials, Academy materials, or public claims, the aggregation record shall include confidence, uncertainty, limitations, permitted use, prohibited use, boundary language, public-safe status, and correction path.

9.5.3(h) The controlling rule shall be that Cluster evidence aggregation must make cross-Node and cross-domain relationships intelligible without turning coincidence, density, repetition, or technical complexity into unsupported truth.

***

9.5.4 Cluster Interoperability Methods.\
9.5.4(a) GCRI Canada shall steward Cluster interoperability methods for aligning records, schemas, controlled vocabulary, data dictionaries, evidence classes, source classes, confidence methods, uncertainty methods, limitation methods, dashboard conventions, map conventions, API conventions, Proof Receipt references, public-safe output conventions, correction records, and interface records across Nodes, Hubs, systems, actors, and domains participating in a Cluster.

9.5.4(b) Cluster interoperability methods shall identify applicable ontology terms, controlled vocabulary terms, schema versions, API versions, dataset versions, model versions, system versions, benchmark versions, compute environment versions, dashboard versions, map versions, public-safe summary versions, and correction versions.

9.5.4(c) Interoperability shall support semantic comparability without erasing material differences among sources, jurisdictions, communities, hosts, public authorities, providers, sponsors, datasets, technologies, measurement methods, calibration states, model assumptions, confidence states, uncertainty states, limitations, public-safe restrictions, and correction states.

9.5.4(d) Cluster interoperability methods shall address cross-system alignment for sensors, AI-RAN, O-RAN, private wireless, DePIN, cyber records, geospatial systems, Earth observation systems, digital twins, simulations, dashboards, maps, APIs, compute environments, data rooms, clean rooms, controlled rooms, public-safe repositories, and Nexus interface records.

9.5.4(e) Interoperability methods shall not imply that systems, actors, records, providers, hosts, public authorities, National Companies, Project SPVs, GRF, GRA, Protocol Authority, or Nexus entities are legally merged, operationally integrated, jointly liable, mutually approved, mutually certified, protocol-effective, finance-ready, procurement-ready, or execution-ready by default.

9.5.4(f) Where interoperability requires data movement, retrieval, embedding, API exposure, dashboard sharing, map sharing, compute-to-data treatment, cross-border processing, or cross-entity access, GCRI Canada shall apply access controls, sovereign data controls, privacy controls, cybersecurity controls, protected knowledge controls, public authority controls, public-safe routing, provider-neutrality controls, sponsor non-control controls, and correction controls.

9.5.4(g) Where interoperability defects are identified, including schema mismatch, vocabulary mismatch, source mismatch, timestamp mismatch, location mismatch, unit mismatch, model mismatch, dashboard mismatch, map mismatch, API mismatch, permission mismatch, public-safe mismatch, confidence mismatch, or correction mismatch, GCRI Canada shall record the mismatch and correct, qualify, restrict, re-map, reclassify, supersede, or refuse the affected interoperability path as appropriate.

9.5.4(h) The controlling rule shall be that Cluster interoperability exists to make evidence comparable and correctable, not to make separate systems or institutions one authority or one execution structure.

***

9.5.5 Cluster Confidence, Uncertainty, Contradiction, and Data-Gap Handling.\
9.5.5(a) GCRI Canada shall steward Cluster confidence, uncertainty, contradiction, and data-gap handling methods for multi-Node, multi-host, multi-domain, regional, national, or cross-system Cluster outputs.

9.5.5(b) Cluster confidence methods shall identify the basis for confidence, including source quality, source authority, source independence, corroboration, calibration, timeliness, completeness, reproducibility where appropriate, review status, method reliability, compute integrity, model evaluation, retrieval grounding, interoperability quality, public authority context, community context, provider influence, sponsor influence, and correction status.

9.5.5(c) Cluster uncertainty methods shall identify measurement uncertainty, source uncertainty, temporal uncertainty, spatial uncertainty, statistical uncertainty, operational uncertainty, model uncertainty, digital twin uncertainty, simulation uncertainty, interoperability uncertainty, legal uncertainty, public authority uncertainty, community uncertainty, protected knowledge uncertainty, finance-boundary uncertainty, provider-related uncertainty, sponsor-related uncertainty, and interpretive uncertainty.

9.5.5(d) Contradiction handling shall treat conflicting Cluster evidence as an evidence event requiring review, qualification, source re-check, method review, confidence downgrade, uncertainty revision, limitation revision, dispute handling, controlled-room treatment, correction, supersession, withdrawal, retraction where applicable, or archive treatment.

9.5.5(e) Data-gap handling shall identify missing Nodes, missing sources, inaccessible records, withheld records, public authority restrictions, community non-consent, Indigenous protocol restrictions, protected knowledge restrictions, privacy restrictions, cybersecurity restrictions, sovereign data restrictions, provider non-disclosure, sponsor non-disclosure, stale data, failed sensors, failed compute, model limits, and public-safe omissions.

9.5.5(f) Cluster dashboards, maps, reports, APIs, datasets, Evidence Packs, Decision Packs, public-safe summaries, and technical notes shall not conceal contradiction or data gaps by smoothing, averaging, coloring, ranking, summarizing, translating, or AI-generating apparent consensus.

9.5.5(g) Confidence scores, uncertainty displays, contradiction labels, gap labels, dashboard colors, heatmaps, hotspot markers, cluster labels, resilience indicators, readiness-context indicators, and public-safe summaries shall not be used as ratings, public warnings, finance-readiness signals, certification signals, recognition signals, provider rankings, sponsor validations, protocol effects, public authority decisions, procurement signals, or execution instructions.

9.5.5(h) Where confidence, uncertainty, contradiction, or data-gap treatment is defective, GCRI Canada shall require confidence recalculation, confidence downgrade, uncertainty revision, limitation update, dashboard relabeling, map relabeling, public-safe correction, controlled notice, source re-check, method update, or dependency review.

9.5.5(i) The controlling rule shall be that Cluster-level conclusions are never stronger than the confidence, uncertainty, contradiction, and data-gap record that supports them.

***

9.5.6 Cluster Public-Safe Output Methods.\
9.5.6(a) GCRI Canada shall steward Cluster public-safe output methods for Cluster-related public-safe summaries, dashboards, maps, reports, technical notes, APIs, datasets, Academy materials, repository notes, media materials, community-facing outputs, public authority learning materials, GRF-facing summaries, GRA-facing summaries, Protocol Authority-facing summaries, provider-facing materials, sponsor-facing materials, host-facing materials, and public claims.

9.5.6(b) Cluster public-safe review shall assess source lineage, data class, evidence class, output class, included Nodes, included Hubs, included hosts, confidence, uncertainty, limitations, contradiction treatment, data-gap treatment, geospatial precision, dashboard labels, map markers, API fields, metadata, file names, captions, public authority references, provider references, sponsor acknowledgments, host references, community references, protected knowledge risk, privacy risk, cybersecurity risk, sovereign data risk, finance risk, procurement risk, and downstream reuse risk.

9.5.6(c) Cluster public-safe outputs shall not disclose or enable misuse of personal information, rights-bearing data, health-sensitive data, cyber-sensitive information, infrastructure-sensitive information, public authority restricted information, sovereign-sensitive information, finance-sensitive information, community-protected information, Indigenous or protected knowledge, confidential source information, privileged material, credentials, secrets, keys, tokens, controlled technology, exploit details, sensitive locations, unsafe geospatial precision, or unsafe metadata.

9.5.6(d) Cluster public-safe outputs shall include, where material, public-safe omissions, responsible non-disclosure basis, confidence, uncertainty, limitations, contradiction status, data-gap status, stale-data treatment, correction status, permitted use, prohibited use, no-public-warning language, no-emergency-command language, no-public-authority language, no-finance language, no-procurement language, no-certification language, no-recognition language, no-protocol-effect language, no-provider-endorsement language, no-sponsor-approval language, no-host-approval language, and correction path.

9.5.6(e) Cluster dashboards and maps shall be reviewed for hotspot implication, public warning implication, emergency-command implication, official-region implication, investment-zone implication, procurement-area implication, provider-market implication, sponsor-territory implication, geospatial sensitivity, infrastructure exposure, public authority implication, finance implication, provider preference, sponsor validation, false precision, overconfident colors, misleading legends, drill-down risk, export risk, API exposure, and stale-data risk.

9.5.6(f) Where Cluster outputs cannot be made public-safe without distorting evidence, erasing uncertainty, concealing contradiction, exposing restricted data, exposing protected knowledge, creating public warning implication, or creating unauthorized authority, GCRI Canada may use controlled annexes, controlled-room review, aggregation, generalization, safe-location treatment, delayed release, responsible non-disclosure, limited public-safe statement, or no-publication treatment.

9.5.6(g) Where Cluster public-safe outputs are corrected, restricted, superseded, withdrawn, retracted, misused, or made stale by later evidence, GCRI Canada shall update public-safe output records and review affected dependencies, dashboards, maps, APIs, public authority learning materials, GRF inputs, GRA inputs, Protocol Authority inputs, provider-facing materials, sponsor-facing materials, host-facing materials, community-facing materials, and public claims.

9.5.6(h) The controlling rule shall be that Cluster public-safe outputs must make multi-Node and multi-domain evidence understandable without making regions, communities, hosts, systems, providers, public authorities, or markets unsafe or overclaimed.

***

9.5.7 Cluster Degraded-Mode and Continuity Methods.\
9.5.7(a) GCRI Canada shall steward Cluster degraded-mode and continuity methods for identifying, recording, interpreting, public-safe summarizing, and correcting evidence concerning reduced visibility, disrupted data flows, sensor failure, compute failure, communications failure, cyber compromise, infrastructure stress, public authority constraints, community disruption, host constraints, provider outages, sponsor-supported dependency limits, and other degraded-mode conditions affecting a Cluster.

9.5.7(b) Degraded-mode methods shall identify affected Nodes, affected Hubs, affected sources, affected sensors, affected communications paths, affected compute workloads, affected models, affected datasets, affected dashboards, affected maps, affected APIs, affected public authority interfaces, affected host interfaces, affected provider interfaces, affected community interfaces, and affected public-safe outputs.

9.5.7(c) Continuity methods shall identify available sources, unavailable sources, fallback sources, reference sources, degraded confidence, increased uncertainty, changed limitations, safe-location treatment, access restrictions, public-safe restrictions, compute-to-data needs, controlled-room routing, incident path, correction path, and dependency effects.

9.5.7(d) Degraded-mode indicators shall not be treated as public warnings, emergency commands, public authority decisions, infrastructure commands, operational instructions, procurement priorities, finance signals, provider performance ratings, sponsor findings, certification signals, recognition signals, protocol effects, or execution instructions by default.

9.5.7(e) GCRI Canada shall not issue emergency commands, public warnings, infrastructure instructions, operational directions, or public authority decisions through Cluster degraded-mode methods. Competent public authorities, operators, hosts, providers, National Companies, Project SPVs, and other downstream actors remain responsible for their own response, operations, duties, records, and liabilities.

9.5.7(f) Where degraded-mode Cluster outputs are prepared for public authority learning, host learning, community-facing learning, provider-facing review, public-safe summaries, dashboards, maps, reports, APIs, GRF inputs, GRA inputs, or Protocol Authority inputs, they shall include confidence downgrade, uncertainty increase, limitation statements, no-public-warning language, no-emergency-command language, no-public-authority language, no-finance language, no-procurement language, no-provider-ranking language, no-sponsor-finding language, and correction path where material.

9.5.7(g) Where degraded-mode evidence is later corrected, completed, restored, contradicted, superseded, or withdrawn, GCRI Canada shall update affected Cluster records, dashboards, maps, reports, APIs, public-safe outputs, interface records, confidence records, uncertainty records, limitation records, and dependencies.

9.5.7(h) The controlling rule shall be that degraded-mode and continuity methods help explain what is known when visibility is reduced, but they do not create authority to command, warn, operate, procure, finance, certify, recognize, rank, or execute.

***

9.5.8 Cluster Interface With Regional Nexus Consortiums, National Nexus Consortiums, National Companies, Project SPVs, Public Authorities, Hosts, and Providers.\
9.5.8(a) GCRI Canada may maintain Cluster interfaces with Regional Nexus Consortiums, National Nexus Consortiums, National Companies, Project SPVs, public authorities, hosts, providers, universities, communities, sponsors, GRF, GRA, Protocol Authority, and other Nexus actors for evidence learning, public-safe interpretation, observability methods, technical baseline support, public-good software support, Verifiable Compute support, Verifiable Intelligence support, Academy learning, and correction support.

9.5.8(b) Interfaces with Regional Nexus Consortiums and National Nexus Consortiums shall preserve their coordinating, convening, and public-good ecosystem roles without converting Cluster evidence into regional authority, national authority, procurement mandate, finance mandate, certification, recognition, protocol effect, National Company authority, Project SPV authority, provider preference, sponsor control, or execution consequence.

9.5.8(c) Interfaces with National Companies shall preserve National Companies’ separate corporate governance, contracting, financing, operations, delivery, implementation, procurement, public authority relationships, provider relationships, sponsor relationships, host relationships, Project SPV relationships, and execution records. Cluster evidence shall not direct or approve National Company action by default.

9.5.8(d) Interfaces with Project SPVs shall preserve Project SPVs’ separate project governance, financing, contracting, permitting, procurement, engineering, delivery, operations, insurance, public authority relationships, provider relationships, sponsor relationships, host relationships, and execution records. Cluster evidence shall not create project approval, finance-readiness, procurement approval, operational clearance, or execution instruction by default.

9.5.8(e) Interfaces with public authorities shall preserve public authority capacity classification, official or non-official status, non-delegation language, non-endorsement language, non-regulatory language, non-procurement language, non-funding language, non-public-finance language, no-public-warning language, no-emergency-command language, data controls, reference controls, and correction path.

9.5.8(f) Interfaces with hosts shall preserve host role, facility context where safe and material, infrastructure context, safe-location treatment, privacy controls, cybersecurity controls, public-safe status, no-operation boundary, no-host-approval boundary, no-certification boundary, no-finance boundary, no-procurement boundary, no-execution boundary, and correction path.

9.5.8(g) Interfaces with providers shall preserve provider neutrality, conflict disclosure, provider role classification, benchmark conditions, validation conditions, commercial sensitivity, IP sensitivity, cybersecurity sensitivity, prohibited claims, no-endorsement language, no-procurement-preference language, no-certification language, no-protocol-effect language, no-finance-readiness language, and correction path.

9.5.8(h) Interfaces with communities and Indigenous or protected knowledge holders shall preserve community protocols, Indigenous protocols where applicable, consent or non-consent where applicable, territorial context, cultural context, environmental knowledge context, sensitive-site treatment, public-safe mapping limits, source protection, withdrawal or challenge pathways where applicable, accessibility, translation, localization, and do-no-harm controls.

9.5.8(i) Interfaces under this section shall be governed by interface records, access controls, room rules where applicable, data-sharing records where applicable, public-safe review, boundary language, correction obligations, dependency review, and closeout records.

9.5.8(j) The controlling rule shall be that Cluster interfaces may support regional, national, project, public authority, host, provider, and community learning, but they shall not transfer authority, merge roles, create finance or procurement consequence, or execute implementation.

***

9.5.9 Cluster Does Not Create Operational Command, Public Warning, Procurement, Certification, Finance-Readiness, or Market Authority.\
9.5.9(a) No Observatory Cluster, Cluster record, Cluster dashboard, Cluster map, Cluster API, Cluster Evidence Pack, Cluster Decision Pack, Cluster technical note, Cluster report, Cluster public-safe output, Cluster interface, Cluster room, Cluster benchmark, Cluster Proof Receipt, Cluster degraded-mode indicator, Cluster continuity indicator, Cluster correction signal, or Cluster public claim shall create operational command, public warning, public authority decision, procurement approval, finance-readiness, certification, recognition, protocol effect, provider preference, sponsor approval, host approval, market authority, infrastructure operation, operational clearance, legal status, or execution authority by default.

9.5.9(b) A Cluster shall not issue emergency commands, public warnings, evacuation instructions, public safety directives, official guidance, regulatory determinations, compliance determinations, enforcement positions, procurement decisions, vendor awards, funding approvals, public finance approvals, investment advice, lending decisions, underwriting decisions, insurance approvals, ratings, guarantees, certifications, recognitions, maturity records, conformance determinations, Nexus-compatible status, role keys, smart licenses, entitlement states, provider rankings, sponsor findings, host approvals, market signals, or deployment instructions.

9.5.9(c) Public authority attendance, regional consortium relevance, national consortium relevance, National Company relevance, Project SPV relevance, provider participation, sponsor support, host participation, university involvement, community involvement, capital-reader interest, dashboard visibility, map visibility, benchmark success, Proof Receipt issuance, GRF interface use, GRA interface use, or Protocol Authority interface use shall not convert a Cluster into authority.

9.5.9(d) Any authority-bearing action by a public authority, GRF, GRA, Protocol Authority, Regional Nexus Consortium, National Nexus Consortium, National Company, Project SPV, provider, sponsor, host, finance actor, procurement actor, infrastructure operator, university, community, or other actor shall arise only through that actor’s own lawful authority, process, record, accountability, and liability, not through the Cluster by implication.

9.5.9(e) Cluster materials shall include boundary language where material to prevent interpretation as public authority action, emergency command, public warning, procurement action, finance-readiness, certification, recognition, protocol effect, provider preference, sponsor approval, host approval, operational clearance, market authority, infrastructure operation, legal status, professional advice, or execution instruction.

9.5.9(f) Where Cluster materials are misused to imply unauthorized authority, GCRI Canada shall correct, relabel, restrict, withdraw, reissue, require removal of misleading references, notify affected interfaces where appropriate, suspend affected interface use, or pursue contractual or legal remedies where appropriate.

9.5.9(g) No ambiguity shall be resolved in favour of Cluster authority. Where there is doubt whether a Cluster creates authority or only supports evidence, the interpretation preserving GCRI Canada’s non-execution role, public authority boundaries, finance boundaries, procurement neutrality, provider neutrality, sponsor non-control, GRF role separation, GRA role separation, Protocol Authority role separation, validity-by-record, correctionability, and public trust shall prevail.

9.5.9(h) The controlling rule shall be that a Cluster organizes and compares evidence across Nodes, hosts, domains, and regions; it does not command, warn, procure, finance, certify, recognize, rank, regulate, operate, or execute.

***

9.5.10 Cluster Records, Mismatch Logs, Correction, Supersession, and Assurance.\
9.5.10(a) GCRI Canada shall maintain, or cause to be maintained, Cluster records for material Observatory Clusters, including records of Cluster purpose, scope, topology, included Nodes, included Hubs, included hosts, source records, data records, compute records, model records, dashboard records, map records, API records, interoperability records, interface records, public-safe outputs, incidents, mismatches, corrections, dependencies, review cycles, assurance, and closeout.

9.5.10(b) Cluster records shall identify Cluster title or identifier, Cluster type, owner where known, GCRI Canada responsible function where applicable, custodian, steward, jurisdictional context, geographic or functional scope, Node relationships, Hub relationships, host relationships, technology domains, risk domains, data classes, evidence classes, output classes, access class, handling class, public-safe status, public authority status, finance-sensitive status, provider-sensitive status, sponsor-sensitive status, host-sensitive status, community-protected status, Indigenous or protected knowledge status, privacy status, cybersecurity status, sovereign data status, legal sensitivity, export-control sensitivity, sanctions sensitivity, permitted uses, prohibited uses, publication limits, and correction path.

9.5.10(c) Mismatch Logs shall identify schema mismatches, vocabulary mismatches, unit mismatches, timestamp mismatches, location mismatches, geospatial mismatches, sensor mismatches, calibration mismatches, AI-RAN or O-RAN signal mismatches, DePIN telemetry mismatches, cyber log mismatches, model mismatches, dataset mismatches, compute environment mismatches, dashboard mismatches, map mismatches, API mismatches, confidence mismatches, uncertainty mismatches, public-safe mismatches, permission mismatches, classification mismatches, boundary-language mismatches, and correction mismatches.

9.5.10(d) Cluster correction records shall identify corrected source, corrected Node relationship, corrected Hub relationship, corrected dataset, corrected method, corrected compute workload, corrected model, corrected interoperability path, corrected dashboard, corrected map, corrected API, corrected public-safe output, corrected interface material, prior status, corrected status, effective date, reviewer, affected dependencies, notice decision, access change, archive treatment, and continuing limitations.

9.5.10(e) Cluster supersession records shall identify replacement Cluster record, changed scope, changed topology, changed Node relationships, changed Hub relationships, changed evidence base, changed methods, changed interoperability paths, changed confidence, changed uncertainty, changed limitations, changed public-safe status, changed boundary language, changed interface status, continuing validity where any, discontinued reliance where any, and downstream dependency treatment.

9.5.10(f) Cluster withdrawal or retraction records shall be used where Cluster materials should no longer be used or relied upon because of material error, unsafe disclosure, public-safe defect, overclaim, boundary breach, provider-preferential framing, sponsor-validation framing, protected knowledge exposure, public authority confusion, finance overclaim, interoperability failure, contradiction handling failure, or correction failure.

9.5.10(g) Cluster assurance records shall identify review cycle, reviewers, scope reviewed, Nodes reviewed, Hubs reviewed, sources reviewed, datasets reviewed, compute reviewed, models reviewed, dashboards reviewed, maps reviewed, APIs reviewed, interoperability reviewed, public-safe outputs reviewed, public authority boundaries reviewed, finance boundaries reviewed, provider neutrality reviewed, sponsor non-control reviewed, protected knowledge safeguards reviewed, cybersecurity reviewed, privacy reviewed, sovereign data reviewed, findings, corrective action plans, training updates, technical control updates, Board or committee reporting where material, residual risk, and closeout status.

9.5.10(h) Cluster records shall be linked, where applicable, to Node records, Hub records, Observatory Methods Register entries, Evidence Register entries, Source Comparison Records, Dataset Register entries, Model Register entries, System Card entries, Benchmark Card entries, Compute Workload Records, Compute Environment Records, Inference Records, Human Review Records, Retrieval and Embedding Records, Proof Receipt Records, Public-Safe Output Records, AI Incident Records, Correction Records, Dependency Records, Truth Engine Records, public authority records, GRF interface records, GRA interface records, Protocol Authority interface records, Regional Nexus Consortium records, National Nexus Consortium records, National Company records, Project SPV records, provider records, sponsor records, host records, community records, university records, Nexus interface records, and public claims records.

9.5.10(i) Cluster records, mismatch logs, correction, supersession, withdrawal, retraction, assurance, retirement, archive, and closeout shall not create certification, recognition, finance-readiness, public authority decision, procurement approval, provider endorsement, sponsor approval, host approval, rating, guarantee, public warning, emergency command, protocol effect, operational clearance, legal status, market authority, infrastructure operation, or execution consequence by default.

9.5.10(j) The controlling rule shall be that every material Cluster must remain traceable through scope, topology, interoperability, mismatches, evidence, interfaces, review, correction, supersession, assurance, and closeout because multi-Node evidence is trustworthy only when the institution can show what was connected, where it mismatched, what changed, and what must no longer be relied upon.

### 9.6 Observatory Hotspot Methods

9.6.1 Observatory Hotspot as Localized Evidence, Connectivity, Sensing, Compute, or Public-Safe Learning Surface.\
9.6.1(a) An Observatory Hotspot shall be treated, for GCRI Canada’s technical-stewardship purposes, as a localized evidence, connectivity, sensing, compute, field-observation, community-context, host-context, infrastructure-context, degraded-mode, resilience, risk, anomaly, or public-safe learning surface within the wider Observatory architecture.

9.6.1(b) A Hotspot may arise from localized evidence concentration, signal density, repeated anomaly, infrastructure stress, cyber pattern, AI-RAN signal pattern, O-RAN signal pattern, private wireless pattern, DePIN telemetry pattern, geospatial pattern, Earth observation pattern, sensor pattern, community concern, host condition, public authority learning need, field observation, digital twin scenario, degraded-mode condition, public-safe communication need, or correction-triggering event.

9.6.1(c) A Hotspot may be associated with a place, facility, corridor, network segment, community context, ecosystem context, infrastructure context, public authority context, host context, provider context, sponsor-supported context where any, technology context, or risk context, provided that its purpose, evidence basis, source lineage, data class, evidence class, public-safe status, access class, handling class, confidence, uncertainty, limitations, permitted use, prohibited use, and correction path are recorded.

9.6.1(d) A Hotspot shall not be treated as an official public warning area, emergency area, hazard designation, regulatory area, procurement area, investment area, certified area, recognized area, protocol-effective area, provider market, sponsor territory, host-approved area, operational command area, infrastructure operating area, deployment area, or execution site by default.

9.6.1(e) Hotspot methods shall support localized evidence interpretation, public-safe learning, source comparison, community safeguard review, protected knowledge protection, public authority learning, provider-neutral technical review, sponsor non-control, host interface discipline, dashboard discipline, map discipline, degraded-mode awareness, and correction discipline.

9.6.1(f) Hotspot terminology shall be used with heightened care because localized language, map markers, heatmaps, labels, dashboard colors, incident-adjacent references, public authority references, media references, provider references, sponsor references, or community references may be misread as warning, authority, deployment approval, market signal, or public status.

9.6.1(g) Where a Hotspot is displayed, mapped, dashboarded, summarized, reported, included in Academy materials, referenced in public authority learning materials, included in GRF inputs, GRA inputs, Protocol Authority inputs, provider-facing materials, sponsor-facing materials, host-facing materials, community-facing materials, media materials, or public claims, GCRI Canada shall preserve confidence, uncertainty, limitations, no-public-warning language, no-emergency-command language, no-public-authority language, no-finance language, no-procurement language, no-certification language, no-recognition language, no-protocol-effect language, no-provider-endorsement language, no-sponsor-approval language, no-host-approval language, and correction path where material.

9.6.1(h) The controlling rule shall be that an Observatory Hotspot is a localized surface for evidence attention and public-safe learning, not an official warning, public authority presence, deployment approval, procurement preference, finance signal, certification, recognition, protocol effect, provider endorsement, sponsor approval, or execution instruction.

***

9.6.2 Hotspot Purpose, Scope, Host, Data, and Community Context.\
9.6.2(a) GCRI Canada shall define each material Observatory Hotspot by record before using the Hotspot for material evidence, dashboarding, mapping, reporting, public-safe publication, public authority learning, GRF input, GRA input, Protocol Authority input, provider-facing material, sponsor-facing material, host-facing material, community-facing material, Academy material, media material, or public claim.

9.6.2(b) Hotspot purpose records shall identify whether the Hotspot is being used for internal evidence review, controlled-room review, source comparison, anomaly review, degraded-mode review, public-safe learning, public authority learning, host learning, community learning, provider-neutral technical review, GRF input support, GRA input support, Protocol Authority input support, Academy learning, correction, or assurance.

9.6.2(c) Hotspot scope records shall identify geographic scope where any, functional scope where any, temporal scope, technology domain, risk domain, infrastructure domain, host context, public authority context, community context, Indigenous or protected knowledge context where applicable, provider context, sponsor context, data classes, evidence classes, output classes, access class, handling class, public-safe status, and correction path.

9.6.2(d) Hotspot host context records shall identify the host role, facility or site context where safe and material, infrastructure context, operational context in public-safe or controlled form, access permissions, data contribution status, sensor placement status, compute context, publication limits, safe-location treatment, privacy controls, cybersecurity controls, sovereign data controls, and correction obligations.

9.6.2(e) Hotspot data context records shall identify source records, data lineage, source permissions, lawful basis where applicable, consent or non-consent treatment where applicable, license status, data sensitivity, public authority restrictions, community restrictions, protected knowledge restrictions, provider restrictions, sponsor restrictions, retention, deletion, sealing, archive treatment, and public-safe output limits.

9.6.2(f) Hotspot community context records shall identify affected or relevant communities, community protocols, Indigenous protocols where applicable, local context, territorial context, cultural context, environmental knowledge context, accessibility needs, language needs, potential harm pathways, sensitive-site risk, source-protection risk, community challenge pathways, withdrawal pathways where applicable, and do-no-harm controls.

9.6.2(g) Where Hotspot purpose, scope, host context, data context, or community context is incomplete, stale, disputed, unsafe, overbroad, misclassified, or inconsistent with public-safe discipline, sovereign data controls, protected knowledge safeguards, public authority boundaries, finance boundaries, provider neutrality, sponsor non-control, or correctionability, the Hotspot shall be held, narrowed, corrected, reclassified, restricted, or refused for material use until the record is adequate.

9.6.2(h) The controlling rule shall be that a Hotspot may be localized only if its purpose, place, host, data, community context, limits, and correction path are written down with sufficient care to prevent local evidence from becoming local overclaim.

***

9.6.3 Hotspot Evidence Collection Methods.\
9.6.3(a) GCRI Canada shall steward Hotspot evidence collection methods for identifying, receiving, classifying, comparing, reviewing, public-safe summarizing, and correcting localized evidence associated with a Hotspot.

9.6.3(b) Hotspot evidence collection methods shall identify source records, source class, source authority, source permission, source lineage, data lineage, provenance, custody, timestamp, location or safe-location treatment, sampling method where applicable, field method where applicable, data quality, completeness, timeliness, source independence, source bias, public-safe status, access class, handling class, confidence, uncertainty, limitations, and correction path.

9.6.3(c) Hotspot evidence may include sensor readings, reference sensor readings, AI-RAN signals, O-RAN signals, private wireless signals, DePIN telemetry, cyber logs, geospatial records, Earth observation records, satellite records, digital twin outputs, simulation outputs, field observations, host observations, public authority context, community observations, Indigenous or protected knowledge context where applicable, provider materials, sponsor materials, university or laboratory outputs, photographs, maps, dashboards, API outputs, public records, historical records, and public-safe summaries.

9.6.3(d) Hotspot evidence collection shall distinguish observed facts, measured values, inferred conditions, modeled conditions, simulated scenarios, field observations, public authority context, community context, protected knowledge, provider-supplied statements, sponsor-supplied statements, host-supplied statements, dashboard indicators, map layers, public-safe summaries, and unsupported claims.

9.6.3(e) Hotspot evidence collection shall not treat urgency, locality, field presence, community concern, public authority interest, media interest, sponsor support, provider participation, host participation, dashboard visibility, map visibility, or real-time signal availability as a substitute for source records, permissions, public-safe review, confidence, uncertainty, limitations, or correction path.

9.6.3(f) Missing, stale, spoofed, tampered, corrupted, incomplete, synthetic, contested, biased, provider-influenced, sponsor-influenced, host-influenced, public authority-sensitive, community-sensitive, protected-knowledge-sensitive, or public-safe-defective Hotspot evidence shall be qualified, downgraded, restricted, routed for review, corrected, superseded, withdrawn, archived, or excluded as appropriate.

9.6.3(g) Hotspot evidence collection methods shall not permit localized evidence to be used as public warning, emergency command, public authority decision, deployment approval, procurement preference, finance-readiness, certification, recognition, protocol effect, provider endorsement, sponsor approval, host approval, operational clearance, legal status, market authority, infrastructure operation, or execution consequence by default.

9.6.3(h) The controlling rule shall be that Hotspot evidence is not stronger because it is local or urgent; it is usable only when collected, classified, compared, bounded, and corrected through records-valid methods.

***

9.6.4 Hotspot Sensor, AI-RAN, DePIN, Geospatial, or Field Evidence Methods.\
9.6.4(a) GCRI Canada shall steward specialized Hotspot methods for sensor, AI-RAN, O-RAN, private wireless, DePIN, cyber, geospatial, Earth observation, satellite, digital twin, simulation, and field evidence associated with localized evidence surfaces.

9.6.4(b) Sensor and reference sensor methods shall identify sensor identity where safe, sensor class, source class, owner where known, custodian, steward, calibration status, calibration method, maintenance status, placement context, timestamp treatment, location or safe-location treatment, sampling method, data quality, failure modes, drift risk, spoof risk, tamper risk, environmental constraints, public-safe status, and correction path.

9.6.4(c) AI-RAN, O-RAN, and private wireless methods shall identify signal class, network context, device or Node context where safe and material, provider context where any, operator context where any, public authority context where any, signal confidence, uncertainty, spoof risk, outage risk, degraded-mode status, public-safe status, and correction path.

9.6.4(d) DePIN methods shall identify telemetry source, network role where safe, contributor or Node context where material, validator context where material, custody, incentive risk, tamper risk, data quality, provider or sponsor influence risk, public-safe status, and correction path.

9.6.4(e) Geospatial, Earth observation, and satellite methods shall identify data source, spatial resolution, temporal resolution, processing method, projection treatment where material, sensitive-site treatment, infrastructure-sensitive treatment, community-identifiability treatment, safe-location treatment, public-safe status, and correction path.

9.6.4(f) Cyber-related Hotspot methods shall identify cyber-sensitive classification, log source, system context where safe, vulnerability sensitivity, exploit sensitivity, credential sensitivity, incident-adjacent status, public-safe disclosure status, access controls, and correction path.

9.6.4(g) Digital twin and simulation methods shall identify scenario, assumptions, input data, calibration status, validation status, sensitivity analysis where material, uncertainty propagation, limitation treatment, public-safe status, and prohibition on presenting modeled or simulated Hotspot outputs as observed fact.

9.6.4(h) Field evidence methods shall identify field observer, field context, collection method, date and time, location or safe-location treatment, host context, community context, public authority context, safety limits, access limits, environmental conditions, evidentiary limitations, source protection, public-safe status, and correction path.

9.6.4(i) Technical or field evidence under this section shall not be treated as valid merely because it is local, high-resolution, real-time, machine-generated, field-observed, public authority-relevant, provider-supplied, sponsor-supported, host-confirmed, dashboard-visible, map-visible, or consistent with expectation.

9.6.4(j) The controlling rule shall be that Hotspot technical and field evidence must be interpreted through calibration, custody, source, context, confidence, uncertainty, public-safe treatment, and correction-not through proximity, precision, or urgency alone.

***

9.6.5 Hotspot Community Safeguard and Protected Knowledge Controls.\
9.6.5(a) GCRI Canada shall apply heightened community safeguard, Indigenous safeguard, protected knowledge, source protection, accessibility, translation, localization, and do-no-harm controls to Hotspot methods where localized evidence involves or may affect communities, Indigenous peoples, local knowledge, territorial knowledge, cultural knowledge, environmental knowledge, traditional ecological knowledge, sensitive sites, vulnerable persons, or community-identifiable conditions.

9.6.5(b) Hotspot community safeguard records shall identify affected or relevant community context, Indigenous protocol where applicable, community protocol, consent or non-consent treatment where applicable, territorial context, cultural context, environmental knowledge context, sensitive-site treatment, public-safe mapping limits, source protection, community challenge pathway, withdrawal pathway where applicable, accessibility treatment, translation treatment, localization treatment, retaliation risk, stigmatization risk, and do-no-harm controls.

9.6.5(c) Protected knowledge shall not be extracted, mapped, summarized, translated, modeled, embedded, retrieved, trained on, dashboarded, publicized, commodified, decontextualized, or used in public-safe materials without recorded authority, safeguards, and public-safe review appropriate to the knowledge context.

9.6.5(d) Hotspot methods shall prevent public outputs from identifying small groups, vulnerable persons, households, sensitive community locations, protected sites, community vulnerabilities, culturally sensitive information, or environmental knowledge in a manner that could cause harm, retaliation, exploitation, stigma, surveillance, extraction, or loss of trust.

9.6.5(e) Community concern or local knowledge shall not be dismissed merely because it is qualitative, oral, contextual, non-instrumented, not machine-generated, not provider-confirmed, not sponsor-confirmed, not public authority-confirmed, or not easily represented in dashboards or maps.

9.6.5(f) Community or Indigenous participation, non-participation, consent, non-consent, challenge, silence, or withdrawal shall be recorded carefully and shall not be converted into approval, endorsement, waiver, recognition, public authority status, finance-readiness, procurement approval, provider preference, sponsor approval, or execution permission by implication.

9.6.5(g) Where Hotspot outputs create or may create community harm, protected knowledge exposure, unsafe mapping, misattribution, decontextualization, stigmatization, retaliation risk, or public-safe defect, GCRI Canada shall restrict, correct, withdraw, retract where appropriate, notify affected interfaces where appropriate, and update safeguards and methods.

9.6.5(h) The controlling rule shall be that Hotspot observability is not public-good observability unless it protects the people, places, knowledge, relationships, and communities made visible by the Hotspot.

***

9.6.6 Hotspot Public Authority Capacity and Reference Controls.\
9.6.6(a) GCRI Canada shall apply public authority capacity classification and reference controls to Hotspot methods where public authorities, public authority data, public authority rooms, regulator-listening contexts, emergency-management contexts, public finance contexts, procurement contexts, public health contexts, public safety contexts, public-sector systems, agency references, or jurisdictional references are present.

9.6.6(b) Public authority capacity classification shall identify whether a public authority actor participates as observer, learner, contributor, data provider, reviewer, convenor, regulator, procurement actor, public finance actor, emergency-management actor, public health actor, infrastructure actor, sponsor, host, funder, or other capacity, and whether participation is official, non-official, exploratory, educational, technical, public-safe, controlled, or otherwise limited.

9.6.6(c) Public authority data controls shall identify source, authority or lawful basis where applicable, official or non-official status, data-sharing terms, confidentiality, classification, access limits, processing limits, retention limits, transfer limits, publication limits, agency reference controls, public-safe status, correction path, and notice obligations.

9.6.6(d) Public authority reference controls shall govern agency names, logos, seals, titles, photographs, quotations, attendance descriptions, meeting summaries, room participation, dashboard access, map access, data contributions, regulator-listening references, emergency-management references, public finance references, procurement references, funding references, and jurisdictional references.

9.6.6(e) Public authority presence, data contribution, comments, questions, attendance, room access, dashboard access, map access, participation in a Hotspot, or reference in Hotspot materials shall not imply endorsement, adoption, approval, delegation, procurement relevance, funding relevance, public finance approval, official guidance, public warning, emergency command, regulatory position, compliance determination, enforcement position, safe harbor, permit, license, sovereign obligation, or public-law status.

9.6.6(f) Hotspot public authority-facing outputs shall include non-delegation, non-endorsement, non-regulatory, non-procurement, non-funding, non-public-finance, no-public-warning, no-emergency-command, confidence, uncertainty, limitation, permitted-use, prohibited-use, and correction language where material.

9.6.6(g) Where public authority reference risk exists, GCRI Canada shall require revised wording, removal of references, public-safe correction, controlled notice, public authority interface notice where appropriate, access restriction, reclassification, withdrawal, retraction, training update, or interface-control update.

9.6.6(h) The controlling rule shall be that public authority proximity to a Hotspot must be classified and controlled because local public authority references can create local authority by implication even where no authority was granted.

***

9.6.7 Hotspot Public-Safe Output and Local Communication Controls.\
9.6.7(a) GCRI Canada shall apply heightened public-safe output and local communication controls to Hotspot-related summaries, dashboards, maps, reports, technical notes, APIs, datasets, Academy materials, community-facing materials, host-facing materials, public authority learning materials, GRF-facing summaries, GRA-facing summaries, Protocol Authority-facing summaries, provider-facing materials, sponsor-facing materials, media materials, event materials, repository materials, website materials, and public claims.

9.6.7(b) Hotspot public-safe review shall assess whether the output discloses or enables misuse of personal information, rights-bearing data, health-sensitive data, cyber-sensitive information, infrastructure-sensitive information, public authority restricted information, sovereign-sensitive information, finance-sensitive information, community-protected information, Indigenous or protected knowledge, confidential source information, privileged material, credentials, secrets, keys, tokens, controlled technology, exploit details, sensitive locations, unsafe geospatial precision, unsafe metadata, or small-community identifiable information.

9.6.7(c) Local communication controls shall assess audience, channel, language, accessibility, translation, localization, community context, local media context, public authority context, host context, provider context, sponsor context, public anxiety risk, false reassurance risk, stigmatization risk, retaliation risk, extraction risk, misquotation risk, and third-party reuse risk.

9.6.7(d) Hotspot dashboards and maps shall be reviewed for marker placement, geospatial precision, drill-down functions, export functions, screenshot risk, API exposure, color scales, warning-like symbols, alert-like labels, hotspot terminology, confidence displays, uncertainty displays, stale-data treatment, public authority implication, finance implication, provider preference, sponsor validation, host approval implication, and correction status.

9.6.7(e) Hotspot public-safe outputs shall include, where material, public-safe omissions, responsible non-disclosure basis, confidence, uncertainty, limitations, contradiction status, data-gap status, stale-data treatment, no-public-warning language, no-emergency-command language, no-public-authority language, no-finance language, no-procurement language, no-certification language, no-recognition language, no-protocol-effect language, no-provider-endorsement language, no-sponsor-approval language, no-host-approval language, permitted use, prohibited use, and correction path.

9.6.7(f) Where a Hotspot cannot be communicated locally without causing unsafe disclosure, public warning implication, panic, false reassurance, public authority confusion, community harm, protected knowledge exposure, provider preference, sponsor validation, finance overclaim, procurement implication, media overclaim, or execution implication, GCRI Canada shall use controlled-room review, controlled annexes, delayed release, aggregation, generalization, safe-location treatment, responsible non-disclosure, limited public-safe statement, or no-publication treatment.

9.6.7(g) Where Hotspot local communications are corrected, restricted, superseded, withdrawn, retracted, misquoted, mistranslated, misused, or made stale by later evidence, GCRI Canada shall update public-safe output records, issue public-safe or controlled correction where appropriate, and review affected dependencies and interfaces.

9.6.7(h) The controlling rule shall be that Hotspot communications must be locally understandable, locally safe, and locally bounded; local relevance must never become local alarm, local approval, local stigma, or local authority by implication.

***

9.6.8 Hotspot Provider and Sponsor Boundary Controls.\
9.6.8(a) GCRI Canada shall apply provider neutrality and sponsor non-control controls to Hotspot methods where providers or sponsors supply data, tooling, equipment, AI systems, compute environments, dashboards, maps, sensors, connectivity, field support, facilities support, funding, convening support, event support, publication support, technical support, or other support.

9.6.8(b) Provider records shall identify provider identity, provider role, provider materials, provider systems, provider data, provider tools, provider equipment, provider staff or representatives where material, provider configuration, provider assumptions, commercial sensitivity, IP sensitivity, cybersecurity sensitivity, export-control sensitivity, sanctions sensitivity, conflict status, influence controls, benchmark conditions where any, validation conditions where any, permitted claims, prohibited claims, publication limits, and correction path.

9.6.8(c) Sponsor records shall identify sponsor identity, sponsor role, funding or support relationship, convening support, facilities support, technology access, data access, public authority access limits, provider access limits, publication limits, conflict status, sponsor non-control language, no-outcome-purchase language, no-evidence-control language, no-publication-control language, no-recognition-control language, no-finance-control language, no-protocol-control language, and correction path.

9.6.8(d) Provider participation in a Hotspot shall not create provider endorsement, procurement preference, preferred supplier status, public tender advantage, provider ranking, certification, recognition, Nexus-compatible status, Protocol Authority effect, finance-readiness, market superiority, operational clearance, or execution authority by default.

9.6.8(e) Sponsor support for a Hotspot shall not purchase outcomes, control evidence, control source selection, control confidence treatment, control public-safe publication, control public authority access, control provider access, control recognition, control finance-readiness, control protocol effect, control procurement, control host participation, control community participation, or control execution.

9.6.8(f) Hotspot provider and sponsor references in dashboards, maps, reports, public-safe summaries, event materials, media materials, public authority materials, provider-facing materials, sponsor-facing materials, host-facing materials, community-facing materials, GRF inputs, GRA inputs, Protocol Authority inputs, Academy materials, or public claims shall be reviewed for endorsement implication, sponsor validation, procurement implication, finance implication, public authority implication, certification implication, recognition implication, protocol implication, and execution implication.

9.6.8(g) Where provider or sponsor boundary defects are detected, GCRI Canada shall require disclosure correction, boundary-language revision, provider-reference removal, sponsor-reference correction, benchmark correction, validation-sprint correction, dashboard relabeling, map relabeling, public-safe correction, controlled notice, access restriction, interface suspension, contract remedy, or legal action where appropriate.

9.6.8(h) The controlling rule shall be that provider and sponsor participation may support Hotspot learning only where the Hotspot remains evidence-led, public-safe, provider-neutral, sponsor-independent, and correctionable.

***

9.6.9 Hotspot Does Not Create Public Authority Presence, Deployment Approval, Procurement Preference, or Public Warning by Default.\
9.6.9(a) No Observatory Hotspot, Hotspot record, Hotspot dashboard, Hotspot map, Hotspot API, Hotspot Evidence Pack, Hotspot Decision Pack, Hotspot technical note, Hotspot report, Hotspot public-safe output, Hotspot interface, Hotspot room, Hotspot benchmark, Hotspot Proof Receipt, Hotspot degraded-mode indicator, Hotspot correction signal, Hotspot local communication, or Hotspot public claim shall create public authority presence, public warning, emergency command, deployment approval, procurement preference, finance-readiness, certification, recognition, protocol effect, provider endorsement, sponsor approval, host approval, operational clearance, market authority, infrastructure operation, legal status, or execution consequence by default.

9.6.9(b) A Hotspot shall not issue or imply official guidance, regulatory determination, public authority decision, compliance determination, enforcement position, safe harbor, permit, license, procurement decision, vendor award, provider ranking, funding approval, public finance approval, investment advice, lending decision, underwriting decision, insurance approval, rating, guarantee, certification, recognition, maturity record, conformance determination, Nexus-compatible status, public warning, emergency command, evacuation instruction, public safety directive, public health order, deployment authorization, operational instruction, or market signal.

9.6.9(c) Public authority attendance, host participation, provider participation, sponsor support, community involvement, university involvement, capital-reader interest, dashboard visibility, map visibility, benchmark success, Proof Receipt issuance, GRF interface use, GRA interface use, Protocol Authority interface use, National Company relevance, Project SPV relevance, or media interest shall not convert a Hotspot into authority.

9.6.9(d) Any authority-bearing action by a public authority, GRF, GRA, Protocol Authority, National Company, Project SPV, provider, sponsor, host, finance actor, procurement actor, infrastructure operator, university, community, or other actor shall arise only through that actor’s own lawful authority, process, record, accountability, and liability, not through the Hotspot by implication.

9.6.9(e) Hotspot materials shall include boundary language where material to prevent interpretation as public authority presence, official status, public warning, emergency command, deployment approval, procurement preference, finance-readiness, certification, recognition, protocol effect, provider endorsement, sponsor approval, host approval, market authority, infrastructure operation, legal status, professional advice, or execution instruction.

9.6.9(f) Where Hotspot materials are misused to imply unauthorized authority, GCRI Canada shall correct, relabel, restrict, withdraw, reissue, require removal of misleading references, notify affected interfaces where appropriate, suspend affected interface use, or pursue contractual or legal remedies where appropriate.

9.6.9(g) No ambiguity shall be resolved in favour of Hotspot authority. Where there is doubt whether a Hotspot creates authority or only supports evidence, the interpretation preserving GCRI Canada’s non-execution role, public authority boundaries, finance boundaries, procurement neutrality, provider neutrality, sponsor non-control, host boundaries, community safeguards, GRF role separation, GRA role separation, Protocol Authority role separation, validity-by-record, correctionability, and public trust shall prevail.

9.6.9(h) The controlling rule shall be that a Hotspot focuses attention; it does not approve deployment, prefer providers, warn the public, represent public authority presence, or execute action.

***

9.6.10 Hotspot Records, Consent / Non-Consent Where Applicable, Correction, and Closeout.\
9.6.10(a) GCRI Canada shall maintain, or cause to be maintained, Hotspot records for material Observatory Hotspots, including records of Hotspot purpose, scope, evidence basis, source records, data records, compute records, model records, sensor records, dashboard records, map records, API records, host records, public authority records, provider records, sponsor records where any, community records where any, protected knowledge records where any, public-safe outputs, incidents, corrections, dependencies, review cycles, assurance, and closeout.

9.6.10(b) Hotspot records shall identify Hotspot title or identifier, Hotspot type, owner where known, GCRI Canada responsible function where applicable, custodian, steward, jurisdictional context, geographic or functional scope, temporal scope, technology domains, risk domains, host context, community context, public authority context, provider context, sponsor context, data classes, evidence classes, output classes, access class, handling class, public-safe status, privacy status, cybersecurity status, sovereign data status, public authority status, finance-sensitive status, provider-sensitive status, sponsor-sensitive status, host-sensitive status, community-protected status, Indigenous or protected knowledge status, legal sensitivity, export-control sensitivity, sanctions sensitivity, permitted uses, prohibited uses, publication limits, and correction path.

9.6.10(c) Consent and non-consent records, where applicable, shall identify whose consent, non-consent, permission, protocol, challenge, withdrawal, refusal, or restriction is relevant; the scope of such consent or non-consent; the materials affected; the uses permitted; the uses prohibited; the duration; the withdrawal path; the public-safe implications; the protected knowledge implications; and the correction obligations. Consent shall not be presumed from silence, attendance, participation, data visibility, public availability, public authority presence, provider participation, sponsor support, host participation, or prior unrelated participation.

9.6.10(d) Hotspot correction records shall identify corrected source, corrected data, corrected method, corrected compute workload, corrected model, corrected sensor state, corrected field record, corrected dashboard, corrected map, corrected API, corrected public-safe output, corrected public authority reference, corrected provider reference, corrected sponsor reference, corrected host reference, corrected community reference, prior status, corrected status, effective date, reviewer, affected dependencies, notice decision, access change, archive treatment, and continuing limitations.

9.6.10(e) Hotspot supersession records shall identify replacement Hotspot record, changed scope, changed evidence base, changed host context, changed community context, changed public authority context, changed provider context, changed sponsor context, changed methods, changed confidence, changed uncertainty, changed limitations, changed public-safe status, changed boundary language, continuing validity where any, discontinued reliance where any, and downstream dependency treatment.

9.6.10(f) Hotspot withdrawal or retraction records shall be used where Hotspot materials should no longer be used or relied upon because of material error, unsafe disclosure, public-safe defect, overclaim, public authority confusion, finance overclaim, procurement implication, provider-preferential framing, sponsor-validation framing, host approval implication, protected knowledge exposure, community harm risk, privacy defect, cybersecurity defect, sovereign data issue, or correction failure.

9.6.10(g) Hotspot closeout records shall identify completion, suspension, termination, retirement, archive, data return, data deletion, data sealing, access revocation, credential revocation, room closure, sensor decommissioning where applicable, compute decommissioning where applicable, dashboard removal where applicable, map removal where applicable, API deprecation where applicable, outstanding corrections, outstanding notices, retained records, archive status, public-safe obligations, confidentiality obligations, protected knowledge obligations, public authority obligations, provider obligations, sponsor obligations, host obligations, community obligations, and continuing prohibited uses.

9.6.10(h) Hotspot records shall be linked, where applicable, to Node records, Hub records, Cluster records, Observatory Methods Register entries, Evidence Register entries, Source Comparison Records, Dataset Register entries, Model Register entries, System Card entries, Benchmark Card entries, Compute Workload Records, Compute Environment Records, Inference Records, Human Review Records, Retrieval and Embedding Records, Proof Receipt Records, Public-Safe Output Records, AI Incident Records, Correction Records, Dependency Records, Truth Engine Records, public authority records, GRF interface records, GRA interface records, Protocol Authority interface records, Regional Nexus Consortium records, National Nexus Consortium records, National Company records, Project SPV records, provider records, sponsor records, host records, community records, university records, Nexus interface records, and public claims records.

9.6.10(i) Hotspot records, consent or non-consent records, correction, supersession, withdrawal, retraction, assurance, retirement, archive, and closeout shall not create certification, recognition, finance-readiness, public authority decision, procurement approval, provider endorsement, sponsor approval, host approval, rating, guarantee, public warning, emergency command, protocol effect, operational clearance, legal status, market authority, infrastructure operation, deployment approval, or execution consequence by default.

9.6.10(j) The controlling rule shall be that every material Hotspot must remain traceable through purpose, scope, local context, consent or non-consent where applicable, evidence, safeguards, public-safe output, correction, and closeout because localized observability is trustworthy only when the institution can show what was observed, who or what may be affected, what was permitted, what was not permitted, what changed, and what must no longer be relied upon.

### 9.7 Regional Observatory Cluster Methods

9.7.1 Regional Observatory Cluster as Regionally Contextualized Evidence and Observability Architecture.\
9.7.1(a) A Regional Observatory Cluster shall be treated, for GCRI Canada’s technical-stewardship purposes, as a regionally contextualized evidence, observability, sensing, compute, communications, dashboard, map, public-safe learning, and correction architecture for organizing records concerning regional hazards, risks, resilience conditions, infrastructure dependencies, host contexts, community contexts, public authority learning contexts, technology systems, environmental systems, degraded modes, and Nexus interface needs.

9.7.1(b) A Regional Observatory Cluster may relate to a province, territory, municipality, Indigenous territory, watershed, airshed, coastal zone, rural region, urban region, northern region, cross-border region, corridor, supply-chain region, energy region, climate-risk region, WEFH region, infrastructure region, technology corridor, public authority region, community region, host region, or other regional context defined by recorded Observatory methods.

9.7.1(c) A Regional Observatory Cluster may connect Nodes, Hubs, Clusters, Hotspots, hosts, public authority learning interfaces, community interfaces, Indigenous or protected knowledge contexts, university or laboratory interfaces, provider interfaces, sponsor-supported contexts where any, National Nexus Consortium interfaces, Regional Nexus Consortium interfaces, National Company interfaces, Project SPV interfaces, GRF interfaces, GRA interfaces, Nexus Risk Management interfaces, Nexus Rails interfaces, Nexus Grid inputs, Nexus Academy materials, dashboards, maps, APIs, Evidence Packs, Decision Packs, and public-safe summaries.

9.7.1(d) Regional Observatory Cluster methods shall support regional evidence integrity, regional source comparison, regional hazard learning, regional resilience learning, regional host readiness evidence, regional public authority learning, regional community safeguard review, regional data sovereignty controls, public-safe publication, finance-boundary discipline, recognition-boundary discipline, protocol-boundary discipline, provider neutrality, sponsor non-control, and correctionability.

9.7.1(e) A Regional Observatory Cluster shall not constitute an official regional public authority designation, emergency-management region, public warning region, procurement region, public finance region, investment zone, certified region, recognized region, protocol-effective region, provider market, sponsor territory, National Company mandate, Project SPV mandate, infrastructure operating region, deployment region, market authority, or execution authority by default.

9.7.1(f) GCRI Canada may steward regional Observatory methods, records, public-safe summaries, dashboards, maps, technical baselines, public-good software support, Verifiable Compute support, Verifiable Intelligence support, and correction discipline for Regional Observatory Clusters, but shall not thereby become a regional public authority, regional operator, regional finance actor, regional procurement actor, regional certification body, regional recognition body, Protocol Authority, provider, sponsor, host, National Company, Project SPV, or execution actor.

9.7.1(g) Where a Regional Observatory Cluster is referenced externally or publicly, GCRI Canada shall preserve controlled vocabulary, regional context, confidence, uncertainty, limitations, no-public-warning language, no-emergency-command language, no-public-authority language, no-finance language, no-procurement language, no-certification language, no-recognition language, no-protocol-effect language, no-provider-endorsement language, no-sponsor-approval language, no-host-approval language, and correction path where material.

9.7.1(h) The controlling rule shall be that a Regional Observatory Cluster is regional evidence and observability architecture, not regional authority, finance, procurement, certification, recognition, protocol, market, deployment, or execution architecture.

***

9.7.2 Regional Hazard Evidence Methods.\
9.7.2(a) GCRI Canada shall steward regional hazard evidence methods for identifying, receiving, classifying, comparing, interpreting, public-safe summarizing, and correcting evidence concerning regional hazards, systemic risks, resilience conditions, degraded modes, infrastructure dependencies, environmental conditions, technology risks, community concerns, and public authority learning needs.

9.7.2(b) Regional hazard evidence may include climate hazards, flood risk, wildfire risk, heat risk, drought risk, storm risk, coastal risk, air quality risk, water risk, energy risk, food-system risk, health-adjacent system risk, cyber risk, infrastructure risk, supply-chain risk, AI-system risk, AI-RAN risk, O-RAN risk, private wireless risk, DePIN risk, geospatial risk, digital twin risk, biosecurity-relevant risk, industrial risk, advanced manufacturing risk, semiconductor supply-chain risk, and other exponential-technology or mission-critical-system risks.

9.7.2(c) Regional hazard evidence methods shall identify source records, source class, source authority, source permission, source lineage, data lineage, jurisdictional context, regional context, public authority context, community context, Indigenous or protected knowledge context where applicable, host context, provider context, sponsor context, timestamp, spatial scope, safe-location treatment, data quality, completeness, timeliness, source independence, source bias, public-safe status, access class, handling class, confidence, uncertainty, limitations, and correction path.

9.7.2(d) Regional hazard evidence may include sensors, reference sensors, AI-RAN signals, O-RAN signals, private wireless signals, DePIN telemetry, cyber logs, geospatial data, Earth observation, satellite data, digital twin outputs, simulation outputs, public records, public authority context, community observations, Indigenous or protected knowledge context where applicable, host observations, provider data, sponsor-supplied data, university or laboratory outputs, field evidence, historical records, dashboards, maps, and public-safe summaries.

9.7.2(e) Regional hazard methods shall distinguish hazard evidence, risk evidence, vulnerability evidence, resilience evidence, exposure evidence, capacity evidence, degraded-mode evidence, scenario evidence, simulated evidence, public authority context, community context, protected knowledge, provider-supplied evidence, sponsor-supplied evidence, and public-safe communication.

9.7.2(f) Regional hazard evidence shall not be treated as public warning, emergency command, public authority decision, official hazard designation, evacuation instruction, public safety directive, regulatory determination, procurement priority, finance-readiness, certification, recognition, provider ranking, sponsor finding, protocol effect, operational clearance, or execution instruction by default.

9.7.2(g) Where regional hazard evidence is missing, stale, conflicting, spoofed, tampered, corrupted, incomplete, synthetic, contested, biased, provider-influenced, sponsor-influenced, public authority-sensitive, community-sensitive, protected-knowledge-sensitive, or public-safe-defective, GCRI Canada shall qualify, downgrade, restrict, correct, supersede, withdraw, archive, or route the evidence for review as appropriate.

9.7.2(h) The controlling rule shall be that regional hazard evidence supports learning and preparedness of evidence, not public warning, command, official designation, finance, procurement, certification, recognition, or execution by GCRI Canada.

***

9.7.3 Regional Host Readiness Methods.\
9.7.3(a) GCRI Canada may steward regional host readiness methods for assessing whether hosts within a Regional Observatory Cluster have sufficient evidence, records, safeguards, data governance, compute controls, communications context, sensor context, public-safe controls, cybersecurity controls, privacy controls, sovereign data controls, protected knowledge controls, public authority interfaces, community interfaces, provider interfaces, and correction pathways to support defined regional Observatory purposes.

9.7.3(b) Regional host readiness methods shall distinguish evidence readiness, data readiness, observability readiness, compute readiness, communications readiness, sensor readiness, public-safe readiness, safeguard readiness, correction readiness, host-interface readiness, public authority learning readiness, provider-interface readiness, and community-interface readiness.

9.7.3(c) Regional host readiness shall not mean finance-readiness, capital-readiness, insurance-readiness, investment readiness, procurement readiness, provider readiness, public authority approval, host approval, certification readiness, recognition readiness, protocol readiness, public warning readiness, operational readiness, deployment readiness, or execution readiness by default.

9.7.3(d) Host readiness records shall identify host identity, host role, facility or site context where safe and material, infrastructure context, regional context, community context, public authority relevance, provider relevance, sponsor relevance, National Company relevance, Project SPV relevance, data classes, evidence classes, output classes, access class, handling class, public-safe status, protected knowledge status, privacy status, cybersecurity status, sovereign data status, permitted use, prohibited use, publication limits, safe-location treatment, readiness basis, confidence, uncertainty, limitations, and correction path.

9.7.3(e) Readiness indicators shall be governed by controlled vocabulary and shall not use or imply “approved,” “certified,” “recognized,” “validated,” “verified,” “deployment-ready,” “investment-ready,” “bankable,” “insurable,” “procurement-ready,” “official,” “safe,” “preferred,” “Nexus-compatible,” or equivalent status language unless separately authorized by competent authority and proper record.

9.7.3(f) Regional host readiness outputs used in GRA-facing, GRF-facing, Protocol Authority-facing, public authority-facing, National Company-facing, Project SPV-facing, provider-facing, sponsor-facing, host-facing, Academy, media, or public-safe contexts shall include boundary language sufficient to prevent overclaim.

9.7.3(g) Where regional host readiness status is based on incomplete evidence, stale evidence, misclassified evidence, missing safeguards, unreviewed compute, unapproved data, public-safe defects, provider influence, sponsor influence, host overclaim, public authority ambiguity, finance-facing ambiguity, or correction failure, GCRI Canada shall correct, downgrade, restrict, supersede, withdraw, or refuse the readiness output as appropriate.

9.7.3(h) The controlling rule shall be that regional host readiness is readiness of evidence and safeguards for a recorded Observatory purpose, not readiness for finance, procurement, authority, certification, recognition, protocol effect, operation, deployment, or execution.

***

9.7.4 Regional Public Authority Learning Methods.\
9.7.4(a) GCRI Canada shall steward regional public authority learning methods for public authorities engaging with Regional Observatory Cluster evidence for evidence literacy, systems-risk learning, resilience learning, observability literacy, technical methods awareness, scenario learning, degraded-mode learning, public-safe interpretation, and correction discipline.

9.7.4(b) Regional public authority learning methods shall identify participating public authorities, offices or functions where appropriate, participant capacity, official or non-official status, jurisdictional context, regional context, data-sharing authority, public authority restrictions, access limits, publication limits, agency reference controls, permitted use, prohibited use, public-safe status, handling class, retention treatment, correction path, and boundary language.

9.7.4(c) Regional public authority learning interfaces may include controlled rooms, public authority rooms, regional evidence rooms, secure briefings, Evidence Packs, Decision Packs, public-safe summaries, controlled annexes, dashboards, maps, APIs, technical notes, Academy materials, Verifiable Intelligence outputs, Verifiable Compute records, source comparison records, hazard evidence summaries, host readiness evidence, and correction signals.

9.7.4(d) GCRI Canada shall not use regional public authority learning methods to create public authority decisions, official guidance, regulatory approvals, procurement approvals, funding approvals, public finance approvals, public warnings, emergency commands, public health orders, public safety directives, enforcement positions, compliance determinations, safe harbors, permits, licenses, sovereign obligations, or delegated public power.

9.7.4(e) Public authority attendance, participation, data contribution, comments, questions, room access, dashboard access, map access, public-safe summary receipt, agency reference, regulator-listening presence, emergency-management presence, procurement presence, public finance presence, or regional public-sector interest shall not imply endorsement, adoption, approval, delegation, funding relevance, procurement relevance, official status, warning status, or public-law status.

9.7.4(f) Regional public authority-facing outputs shall include non-delegation, non-endorsement, non-regulatory, non-procurement, non-funding, non-public-finance, no-public-warning, no-emergency-command, confidence, uncertainty, limitation, permitted-use, prohibited-use, and correction language where material.

9.7.4(g) Where regional public authority learning materials are corrected, restricted, superseded, withdrawn, retracted, or materially reclassified, GCRI Canada shall notify or signal affected public authority interfaces where appropriate and review affected dependencies.

9.7.4(h) The controlling rule shall be that regional public authority learning may support better understanding by public authorities, but public authority remains with public authorities.

***

9.7.5 Regional Community, Indigenous, Local, Territorial, Environmental, and Protected Knowledge Safeguards.\
9.7.5(a) GCRI Canada shall apply heightened regional community, Indigenous, local, territorial, environmental, protected knowledge, source protection, accessibility, translation, localization, and do-no-harm safeguards to Regional Observatory Cluster methods where regional evidence involves or may affect communities, Indigenous peoples, local knowledge, territorial knowledge, cultural knowledge, environmental knowledge, traditional ecological knowledge, sensitive sites, vulnerable persons, workers, residents, or community-identifiable conditions.

9.7.5(b) Regional safeguard records shall identify affected or relevant communities, Indigenous protocols where applicable, community protocols, consent or non-consent treatment where applicable, territorial context, cultural context, environmental knowledge context, sensitive-site treatment, public-safe mapping limits, source protection, community challenge pathways, withdrawal pathways where applicable, accessibility treatment, translation treatment, localization treatment, retaliation risk, stigmatization risk, extraction risk, and do-no-harm controls.

9.7.5(c) Regional protected knowledge shall not be extracted, mapped, summarized, translated, modeled, embedded, retrieved, trained on, dashboarded, publicized, commodified, decontextualized, or used in public-safe materials without recorded authority, safeguards, and public-safe review appropriate to the knowledge context.

9.7.5(d) Regional methods shall prevent public outputs from identifying small communities, vulnerable persons, households, sensitive community locations, protected sites, community vulnerabilities, culturally sensitive information, environmental knowledge, or traditional ecological knowledge in a manner that could cause harm, retaliation, exploitation, stigma, surveillance, extraction, or loss of trust.

9.7.5(e) Community concern, Indigenous knowledge, local knowledge, territorial knowledge, or environmental knowledge shall not be dismissed merely because it is qualitative, oral, contextual, place-based, relational, non-instrumented, not machine-generated, not provider-confirmed, not sponsor-confirmed, not public authority-confirmed, or not easily represented in dashboards or maps.

9.7.5(f) Community or Indigenous participation, non-participation, consent, non-consent, challenge, silence, or withdrawal shall be recorded carefully and shall not be converted into approval, endorsement, waiver, public authority status, finance-readiness, procurement approval, provider preference, sponsor approval, host approval, regional acceptance, or execution permission by implication.

9.7.5(g) Where Regional Observatory Cluster outputs create or may create community harm, protected knowledge exposure, unsafe mapping, misattribution, decontextualization, stigmatization, retaliation risk, extraction risk, or public-safe defect, GCRI Canada shall restrict, correct, withdraw, retract where appropriate, notify affected interfaces where appropriate, and update safeguards and methods.

9.7.5(h) The controlling rule shall be that regional observability is not public-good observability unless it protects the people, places, knowledge, relationships, communities, and territories made visible by regional evidence.

***

9.7.6 Regional Data Sovereignty, Localization, Cross-Border, and Public-Safe Publication Methods.\
9.7.6(a) GCRI Canada shall steward regional data sovereignty, localization, cross-border, compute-to-data, access-control, and public-safe publication methods for Regional Observatory Cluster evidence and outputs.

9.7.6(b) Regional data sovereignty methods shall identify data residency, localization, cross-border transfer status, public authority data zones, Indigenous data considerations, community data safeguards, national data infrastructure requirements, cloud region, support access, subprocessors, backup location, archive location, deletion obligations, sealing obligations, compelled-access risk, and jurisdictional access limits.

9.7.6(c) Regional localization methods shall identify local legal context, provincial or territorial context, municipal context, Indigenous or community context where applicable, language context, accessibility needs, cultural context, environmental context, public authority context, host context, infrastructure context, and public-safe communication context.

9.7.6(d) Cross-border methods shall identify whether data, compute, access, support, backups, logs, models, embeddings, retrieval sources, dashboards, maps, APIs, controlled annexes, public-safe outputs, or interface records cross provincial, territorial, national, Indigenous, community, institutional, programmatic, entity, provider, or public authority boundaries.

9.7.6(e) Compute-to-data and controlled-room methods shall be preferred where restricted data, sovereign-sensitive data, public authority data, personal information, health-sensitive data, cyber-sensitive data, infrastructure-sensitive data, finance-sensitive data, community-protected data, Indigenous or protected knowledge, confidential source information, privileged materials, or other sensitive regional materials should be analyzed without moving or exposing underlying records beyond approved controls.

9.7.6(f) Public-safe publication methods shall determine whether regional materials may be released publicly, released only through public-safe summary, released only through aggregation, released only through generalization, released only through safe-location treatment, released only through controlled annex, released only to controlled audiences, delayed, withheld, or refused.

9.7.6(g) Regional public-safe outputs shall not disclose or enable misuse of personal information, rights-bearing data, health-sensitive data, cyber-sensitive information, infrastructure-sensitive information, public authority restricted information, sovereign-sensitive information, finance-sensitive information, community-protected information, Indigenous or protected knowledge, confidential source information, privileged material, controlled technology, exploit details, sensitive locations, unsafe geospatial precision, unsafe metadata, or small-community identifiable information.

9.7.6(h) Where regional data sovereignty, localization, cross-border, or public-safe publication controls fail, GCRI Canada shall restrict access, halt routing, preserve logs where safe, review exposure, correct records, notify affected interfaces where required, reclassify outputs, withdraw or retract where appropriate, and update controls.

9.7.6(i) The controlling rule shall be that regional evidence may travel only as far as law, sovereignty, community safeguards, privacy, cybersecurity, public-safe discipline, and correctionability permit.

***

9.7.7 Regional Evidence Interface With RNFD, GRA, GRF, Nexus Risk Management, Nexus Rails, and Regional Nexus Consortiums.\
9.7.7(a) GCRI Canada may provide Regional Observatory Cluster evidence inputs to RNFD, The Global Risks Alliance (GRA), The Global Risks Forum (GRF), Nexus Risk Management, Nexus Rails, Regional Nexus Consortiums, Nexus Grid, Nexus Academy, Nexus Standards / Protocol Authority, and other authorized Nexus interfaces for evidence support, learning support, public-safe interpretation, regional risk context, regional resilience context, host readiness evidence, node evidence, correction support, and public-good systems understanding.

9.7.7(b) Regional evidence interface records shall identify receiving interface, purpose, evidence classes, data classes, output classes, source records, method records, compute records, model records where applicable, public-safe status, access class, handling class, confidence, uncertainty, limitations, permitted use, prohibited use, boundary language, correction path, supersession path, withdrawal path, retraction path where applicable, and dependency links.

9.7.7(c) RNFD-facing and Nexus Rails-facing inputs shall remain regional evidence-supporting and routeability-context-supporting only, and shall not create finance-readiness, capital-readiness, insurance-readiness, investment advice, rating, guarantee, public finance approval, procurement approval, or execution consequence by GCRI Canada.

9.7.7(d) GRA-facing inputs shall remain evidence-supporting, risk-supporting, resilience-supporting, Proof Pack-supporting, insurance-readiness-input-supporting, capital-reader-literacy-supporting, finance-boundary-supporting, and correction-supporting only, and shall not create finance-readiness, investment advice, rating, guarantee, insurance approval, lending decision, underwriting decision, public finance approval, bankability, fundability, or capital commitment by GCRI Canada.

9.7.7(e) GRF-facing inputs shall remain evidence-supporting, claims-discipline-supporting, maturity-context-supporting, Docket-supporting, Grid-supporting, public-safe-reporting-supporting, stakeholder-formation-supporting, recognition-supporting, and correction-supporting only, and shall not create recognition, standing, maturity record, claims approval, registry status, public-facing legitimacy, or public-safe reporting status by GCRI Canada.

9.7.7(f) Nexus Risk Management-facing inputs shall remain risk-evidence, resilience-evidence, scenario-learning, degraded-mode-learning, and correction-supporting inputs only, and shall not make GCRI Canada the risk manager, emergency commander, infrastructure operator, public authority, provider, finance actor, or execution actor for downstream systems.

9.7.7(g) Regional Nexus Consortium-facing inputs shall support regional coordination, public-good learning, ecosystem evidence, regional observability, public-safe summaries, Academy materials, and correction discipline only, and shall not create regional authority, procurement authority, finance authority, certification authority, recognition authority, protocol authority, provider preference, sponsor control, National Company execution, Project SPV execution, or implementation mandate.

9.7.7(h) Where regional evidence inputs are corrected, restricted, superseded, withdrawn, retracted, or materially reclassified, GCRI Canada shall notify or signal affected RNFD, GRA, GRF, Nexus Risk Management, Nexus Rails, Regional Nexus Consortium, and other affected interfaces where appropriate and review downstream dependencies.

9.7.7(i) The controlling rule shall be that regional evidence may support many Nexus interfaces, but no regional interface converts GCRI Canada evidence into finance, recognition, authority, risk-command, procurement, protocol, provider preference, sponsor control, or execution.

***

9.7.8 Regional Cluster Interface With National Nexus Consortiums and National Companies.\
9.7.8(a) GCRI Canada may maintain Regional Observatory Cluster interfaces with National Nexus Consortiums and National Companies for evidence learning, regional observability, technical baseline support, public-good software support, Verifiable Compute support, Verifiable Intelligence support, host readiness evidence, node evidence, public-safe interpretation, Academy learning, and correction support.

9.7.8(b) Interfaces with National Nexus Consortiums shall preserve their national public-good convening, coordination, ecosystem, learning, and alignment functions without converting Regional Observatory Cluster evidence into national authority, public authority delegation, procurement mandate, finance mandate, certification, recognition, protocol effect, provider preference, sponsor control, National Company instruction, Project SPV instruction, or execution consequence.

9.7.8(c) Interfaces with National Companies shall preserve National Companies’ separate corporate governance, contracting, financing, procurement, operations, delivery, implementation, vendor management, public authority relationships, sponsor relationships, host relationships, Project SPV relationships, risk allocation, employment, records, duties, liabilities, and execution accountability.

9.7.8(d) Regional Cluster evidence supplied to National Companies shall not constitute project approval, procurement approval, vendor selection, provider preference, investment advice, finance-readiness, insurance-readiness, underwriting support, lending support, rating, guarantee, public finance approval, certification, recognition, protocol effect, operational clearance, construction authorization, deployment instruction, infrastructure operation, or execution command by GCRI Canada.

9.7.8(e) National Company materials supplied into a Regional Observatory Cluster shall be classified for source authority, commercial sensitivity, finance sensitivity, procurement sensitivity, provider sensitivity, sponsor sensitivity, host sensitivity, public authority restrictions, privacy, cybersecurity, sovereign data, protected knowledge, public-safe status, and correctionability before material use by GCRI Canada.

9.7.8(f) Where Regional Cluster interfaces with National Nexus Consortiums or National Companies create role confusion, finance overclaim, procurement implication, provider preference, sponsor control, public authority implication, host approval implication, project approval implication, or execution drift, GCRI Canada shall revise boundary language, restrict the interface, reclassify materials, require controlled-room treatment, suspend routing, seek correction, or refuse the interface as appropriate.

9.7.8(g) Interface records under this section shall identify interface purpose, parties, capacities, records shared, records received, permitted use, prohibited use, access class, handling class, public-safe status, finance-safe status, procurement-safe status, provider-neutrality status, sponsor non-control status, correction path, notice path, dependency path, and closeout path.

9.7.8(h) The controlling rule shall be that Regional Cluster evidence may inform national learning and company evidence discipline, but it shall not direct national governance, corporate action, procurement, finance, project delivery, or execution.

***

9.7.9 Regional Cluster Does Not Create Regional Public Authority, Finance Approval, Procurement Authority, or Execution Authority.\
9.7.9(a) No Regional Observatory Cluster, Regional Cluster record, regional dashboard, regional map, regional API, regional Evidence Pack, regional Decision Pack, regional technical note, regional report, regional public-safe output, regional interface, regional room, regional benchmark, regional Proof Receipt, regional hazard evidence output, regional host readiness output, regional correction signal, or regional public claim shall create regional public authority, public warning, emergency command, finance approval, finance-readiness, procurement authority, certification, recognition, protocol effect, provider preference, sponsor approval, host approval, market authority, infrastructure operation, operational clearance, legal status, or execution authority by default.

9.7.9(b) A Regional Observatory Cluster shall not issue or imply official regional guidance, regulatory determination, public authority decision, compliance determination, enforcement position, safe harbor, permit, license, procurement decision, vendor award, funding approval, public finance approval, public warning, emergency command, evacuation instruction, public safety directive, public health order, investment advice, lending decision, underwriting decision, insurance approval, rating, guarantee, certification, recognition, maturity record, conformance determination, Nexus-compatible status, public finance status, provider ranking, sponsor finding, host approval, deployment authorization, operational instruction, or market signal.

9.7.9(c) Public authority attendance, regional consortium relevance, national consortium relevance, National Company relevance, Project SPV relevance, provider participation, sponsor support, host participation, university involvement, community involvement, capital-reader interest, dashboard visibility, map visibility, benchmark success, Proof Receipt issuance, RNFD interface use, GRA interface use, GRF interface use, Nexus Rails interface use, Nexus Risk Management interface use, or Protocol Authority interface use shall not convert a Regional Observatory Cluster into regional authority.

9.7.9(d) Any authority-bearing action by a public authority, GRF, GRA, Protocol Authority, Regional Nexus Consortium, National Nexus Consortium, National Company, Project SPV, provider, sponsor, host, finance actor, procurement actor, infrastructure operator, university, community, or other actor shall arise only through that actor’s own lawful authority, process, record, accountability, and liability, not through the Regional Observatory Cluster by implication.

9.7.9(e) Regional Cluster materials shall include boundary language where material to prevent interpretation as public authority action, regional authority, emergency command, public warning, procurement action, finance-readiness, public finance approval, certification, recognition, protocol effect, provider preference, sponsor approval, host approval, operational clearance, market authority, infrastructure operation, legal status, professional advice, or execution instruction.

9.7.9(f) Where Regional Cluster materials are misused to imply unauthorized regional authority, GCRI Canada shall correct, relabel, restrict, withdraw, reissue, require removal of misleading references, notify affected interfaces where appropriate, suspend affected interface use, or pursue contractual or legal remedies where appropriate.

9.7.9(g) No ambiguity shall be resolved in favour of Regional Cluster authority. Where there is doubt whether a Regional Observatory Cluster creates authority or only supports evidence, the interpretation preserving GCRI Canada’s non-execution role, public authority boundaries, finance boundaries, procurement neutrality, provider neutrality, sponsor non-control, host boundaries, community safeguards, GRF role separation, GRA role separation, Protocol Authority role separation, validity-by-record, correctionability, and public trust shall prevail.

9.7.9(h) The controlling rule shall be that a Regional Observatory Cluster organizes regional evidence and learning; it does not govern, finance, procure, certify, recognize, warn, command, operate, approve deployment, or execute.

***

9.7.10 Regional Observatory Cluster Records, Public-Safe Summaries, Correction, and Renewal.\
9.7.10(a) GCRI Canada shall maintain, or cause to be maintained, Regional Observatory Cluster records for material Regional Observatory Clusters, including records of regional purpose, scope, evidence basis, source records, data records, compute records, model records, sensor records, dashboard records, map records, API records, host records, public authority records, provider records, sponsor records where any, community records where any, Indigenous or protected knowledge records where any, National Nexus Consortium interface records, National Company interface records, Regional Nexus Consortium interface records, RNFD interface records, GRA interface records, GRF interface records, Nexus Risk Management interface records, Nexus Rails interface records, public-safe outputs, incidents, corrections, dependencies, review cycles, assurance, renewal, and closeout.

9.7.10(b) Regional Observatory Cluster records shall identify cluster title or identifier, region type, owner where known, GCRI Canada responsible function where applicable, custodian, steward, jurisdictional context, geographic or functional scope, temporal scope, technology domains, risk domains, host contexts, community contexts, public authority contexts, provider contexts, sponsor contexts, data classes, evidence classes, output classes, access class, handling class, public-safe status, privacy status, cybersecurity status, sovereign data status, public authority status, finance-sensitive status, provider-sensitive status, sponsor-sensitive status, host-sensitive status, community-protected status, Indigenous or protected knowledge status, legal sensitivity, export-control sensitivity, sanctions sensitivity, permitted uses, prohibited uses, publication limits, and correction path.

9.7.10(c) Public-safe Regional Observatory Cluster summaries shall identify, where material, regional evidence basis, regional source classes, regional methods, regional confidence, regional uncertainty, regional limitations, contradiction status, data-gap status, public-safe omissions, responsible non-disclosure basis, stale-data treatment, boundary language, permitted use, prohibited use, correction status, supersession status, withdrawal status where applicable, and retraction status where applicable, while avoiding unsafe disclosure of restricted materials.

9.7.10(d) Regional correction records shall identify corrected source, corrected data, corrected method, corrected compute workload, corrected model, corrected sensor state, corrected field record, corrected dashboard, corrected map, corrected API, corrected public-safe output, corrected public authority reference, corrected provider reference, corrected sponsor reference, corrected host reference, corrected community reference, corrected National Nexus Consortium interface, corrected National Company interface, corrected Regional Nexus Consortium interface, corrected GRA interface, corrected GRF interface, corrected RNFD or Nexus Rails interface, prior status, corrected status, effective date, reviewer, affected dependencies, notice decision, access change, archive treatment, and continuing limitations.

9.7.10(e) Regional supersession records shall identify replacement Regional Observatory Cluster record, changed scope, changed evidence base, changed host context, changed community context, changed public authority context, changed provider context, changed sponsor context, changed National Nexus Consortium context, changed National Company context, changed Regional Nexus Consortium context, changed methods, changed confidence, changed uncertainty, changed limitations, changed public-safe status, changed boundary language, continuing validity where any, discontinued reliance where any, and downstream dependency treatment.

9.7.10(f) Regional withdrawal or retraction records shall be used where regional materials should no longer be used or relied upon because of material error, unsafe disclosure, public-safe defect, overclaim, public authority confusion, finance overclaim, procurement implication, provider-preferential framing, sponsor-validation framing, host approval implication, protected knowledge exposure, community harm risk, privacy defect, cybersecurity defect, sovereign data issue, cross-border defect, regional misclassification, or correction failure.

9.7.10(g) Regional renewal records shall identify whether the Regional Observatory Cluster remains current, useful, records-valid, source-lined, public-safe, sovereignty-compatible, privacy-protective, cybersecurity-controlled, protected-knowledge-safe, provider-neutral, sponsor-independent, boundary-valid, and correctionable. Renewal shall identify changed regional context, changed public authority context, changed community context, changed technology context, changed risk context, changed legal context, changed data context, changed compute context, changed host context, changed provider context, changed sponsor context, changed finance context, changed Nexus interface context, and required method updates.

9.7.10(h) Regional closeout records shall identify completion, suspension, termination, retirement, archive, data return, data deletion, data sealing, access revocation, credential revocation, room closure, dashboard removal where applicable, map removal where applicable, API deprecation where applicable, outstanding corrections, outstanding notices, retained records, archive status, public-safe obligations, confidentiality obligations, protected knowledge obligations, public authority obligations, provider obligations, sponsor obligations, host obligations, community obligations, National Nexus Consortium obligations, National Company obligations, Regional Nexus Consortium obligations, GRA obligations, GRF obligations, RNFD or Nexus Rails obligations where any, and continuing prohibited uses.

9.7.10(i) Regional Observatory Cluster records shall be linked, where applicable, to Node records, Hub records, Cluster records, Hotspot records, Observatory Methods Register entries, Evidence Register entries, Source Comparison Records, Dataset Register entries, Model Register entries, System Card entries, Benchmark Card entries, Compute Workload Records, Compute Environment Records, Inference Records, Human Review Records, Retrieval and Embedding Records, Proof Receipt Records, Public-Safe Output Records, AI Incident Records, Correction Records, Dependency Records, Truth Engine Records, public authority records, GRF interface records, GRA interface records, Protocol Authority interface records, RNFD records, Nexus Risk Management records, Nexus Rails records, Regional Nexus Consortium records, National Nexus Consortium records, National Company records, Project SPV records, provider records, sponsor records, host records, community records, university records, Nexus interface records, and public claims records.

9.7.10(j) Regional Observatory Cluster records, public-safe summaries, correction, supersession, withdrawal, retraction, assurance, renewal, retirement, archive, and closeout shall not create certification, recognition, finance-readiness, public authority decision, procurement approval, provider endorsement, sponsor approval, host approval, rating, guarantee, public warning, emergency command, protocol effect, operational clearance, legal status, market authority, infrastructure operation, deployment approval, regional authority, national authority, or execution consequence by default.

9.7.10(k) The controlling rule shall be that every material Regional Observatory Cluster must remain traceable through regional purpose, scope, evidence, safeguards, public-safe summaries, correction, renewal, and closeout because regional observability is trustworthy only when the institution can show what region was described, what evidence supported the description, what was protected, what changed, what was renewed, and what must no longer be relied upon.

### 9.8 National Dense Nexus Core Methods

9.8.1 National Dense Nexus Core as National-Scale Compute, Evidence, Observability, Interoperability, and Continuity Architecture.\
9.8.1(a) A National Dense Nexus Core shall be treated, for GCRI Canada’s technical-stewardship purposes, as a national-scale or nationally significant compute, evidence, observability, interoperability, continuity, public-safe learning, and correction architecture for organizing records concerning national systems, regional systems, public authority learning contexts, infrastructure dependencies, exponential technologies, mission-critical technologies, resilience conditions, degraded modes, data sovereignty, public-good technical baselines, and Nexus interface needs.

9.8.1(b) A National Dense Nexus Core may connect Regional Observatory Clusters, Observatory Clusters, Hubs, Nodes, Hotspots, sovereign compute environments, secure enclaves, compute-to-data environments, controlled rooms, data rooms, clean rooms, no-download rooms, public authority learning rooms, host contexts, operator contexts, provider contexts, university or laboratory contexts, community contexts, Indigenous or protected knowledge contexts, National Nexus Consortium interfaces, National Company interfaces, Project SPV interfaces, GRF interfaces, GRA interfaces, Nexus Risk Management interfaces, Nexus Rails interfaces, Nexus Grid inputs, Nexus Academy materials, Protocol Authority inputs, dashboards, maps, APIs, Evidence Packs, Decision Packs, Proof Receipts, public-safe summaries, and correction records.

9.8.1(c) A National Dense Nexus Core may support national evidence density, national public authority learning, national resilience learning, national degraded-mode awareness, national interoperability methods, national observability methods, national data governance methods, sovereign compute methods, public-safe publication, technical baseline support, public-good software support, national Academy materials, GRF input support, GRA input support, Protocol Authority input support, finance-boundary evidence support, provider-neutral technical support, sponsor non-control, and correction discipline.

9.8.1(d) A National Dense Nexus Core shall not constitute a national public authority, official national program, public finance program, procurement program, investment zone, certified ecosystem, recognized ecosystem, Protocol Authority status, provider market, sponsor territory, National Company mandate, Project SPV mandate, infrastructure operating system, telecommunications operating system, AI-RAN operating system, emergency-management structure, public warning system, public authority decision system, market infrastructure, or execution authority by default.

9.8.1(e) GCRI Canada may steward National Dense Nexus Core methods, records, public-safe summaries, dashboards, maps, technical baselines, public-good software support, Verifiable Compute support, Verifiable Intelligence support, ontology, controlled vocabulary, interoperability logic, assurance, and correction discipline, but shall not thereby become the owner, operator, controller, public authority, emergency commander, finance actor, procurement actor, certification body, recognition body, Protocol Authority, provider, sponsor, host, National Company, Project SPV, operator, market actor, or execution actor for any national infrastructure, system, project, or deployment.

9.8.1(f) National Dense Nexus Core methods shall preserve legal separateness and role separation among GCRI Canada, GCRI US, The Global Risks Forum (GRF), The Global Risks Alliance (GRA), Nexus Standards / Protocol Authority, Nexus entities, Regional Nexus Consortiums, National Nexus Consortiums, National Companies, Project SPVs, public authorities, operators, providers, sponsors, hosts, universities, communities, Indigenous or protected knowledge holders, and other actors.

9.8.1(g) Where a National Dense Nexus Core is referenced externally or publicly, GCRI Canada shall preserve controlled vocabulary, national context, confidence, uncertainty, limitations, no-public-warning language, no-emergency-command language, no-public-authority language, no-finance language, no-procurement language, no-certification language, no-recognition language, no-protocol-effect language, no-provider-endorsement language, no-sponsor-approval language, no-host-approval language, no-operator-control language, and correction path where material.

9.8.1(h) The controlling rule shall be that a National Dense Nexus Core is national-scale evidence, observability, interoperability, compute, and continuity architecture, not national authority, public finance, procurement, certification, recognition, protocol, market, infrastructure operation, deployment approval, or execution architecture.

***

9.8.2 National Dense Core Evidence Methods.\
9.8.2(a) GCRI Canada shall steward National Dense Core evidence methods for identifying, receiving, classifying, comparing, integrating, interpreting, public-safe summarizing, and correcting national-scale or nationally significant evidence across Regional Observatory Clusters, Observatory Clusters, Hubs, Nodes, Hotspots, national datasets, public authority contexts, operator contexts, host contexts, provider contexts, community contexts, Indigenous or protected knowledge contexts, university or laboratory contexts, National Company contexts, Project SPV contexts, GRF contexts, GRA contexts, Protocol Authority contexts, and Nexus interface contexts.

9.8.2(b) National Dense Core evidence methods shall identify source records, source class, source authority, source permission, source lineage, data lineage, jurisdictional context, national context, provincial and territorial context where applicable, municipal context where applicable, Indigenous or community context where applicable, public authority context, operator context, host context, provider context, sponsor context, timestamp, spatial scope, safe-location treatment, data quality, completeness, timeliness, source independence, source bias, public-safe status, access class, handling class, confidence, uncertainty, limitations, dependency links, and correction path.

9.8.2(c) National Dense Core evidence may include Regional Observatory Cluster records, Cluster records, Hub records, Node records, Hotspot records, sensor records, reference sensor records, AI-RAN signals, O-RAN signals, private wireless signals, DePIN telemetry, cyber logs, geospatial data, Earth observation data, satellite data, digital twin outputs, simulation outputs, public records, public authority context, operator data, host observations, provider data, sponsor-supplied data, university or laboratory outputs, community observations, Indigenous or protected knowledge context where applicable, historical records, dashboards, maps, APIs, Evidence Packs, Decision Packs, Proof Receipts, and public-safe summaries.

9.8.2(d) National Dense Core evidence methods shall distinguish raw evidence, processed evidence, derived evidence, modeled evidence, simulated evidence, inferred evidence, regional evidence, local evidence, national evidence, public authority context, operator context, host context, community context, protected knowledge, provider-supplied evidence, sponsor-supplied evidence, finance-facing evidence, recognition-supporting evidence, protocol-supporting evidence, and public-safe communication.

9.8.2(e) National Dense Core evidence shall not be treated as stronger merely because it is national-scale, dense, multi-source, multi-region, dashboard-visible, map-visible, compute-supported, AI-assisted, public authority-relevant, finance-relevant, provider-supported, sponsor-supported, or supported by Proof Receipts. National Dense Core evidence shall require source-lineage, method, confidence, uncertainty, limitation, public-safe, boundary, and correction records proportionate to use.

9.8.2(f) National Dense Core evidence methods shall preserve contradiction and dispute. Conflicting regional, local, public authority, operator, host, provider, sponsor, community, model, dashboard, map, API, or dataset evidence shall not be automatically reconciled through aggregation, averaging, AI summarization, dashboard display, or institutional preference.

9.8.2(g) Where National Dense Core evidence is missing, stale, conflicting, spoofed, tampered, corrupted, incomplete, synthetic, contested, biased, provider-influenced, sponsor-influenced, public authority-sensitive, operator-sensitive, community-sensitive, protected-knowledge-sensitive, cross-border-defective, sovereign-data-defective, public-safe-defective, or correction-defective, GCRI Canada shall qualify, downgrade, restrict, correct, supersede, withdraw, archive, or route the evidence for review as appropriate.

9.8.2(h) The controlling rule shall be that national evidence density supports deeper learning only when evidence remains source-lined, context-preserving, confidence-aware, uncertainty-aware, public-safe, boundary-valid, and correctionable.

***

9.8.3 National Dense Core Sovereign Compute and Compute-to-Data Methods.\
9.8.3(a) GCRI Canada shall steward National Dense Core sovereign compute, secure compute, compute-to-data, confidential computing, secure enclave, air-gapped, no-download, controlled-room, clean-room, data-room, edge compute, public authority environment, university environment, provider environment, host environment, and approved cloud methods for national-scale or nationally significant Observatory evidence and outputs.

9.8.3(b) National Dense Core sovereign compute methods shall identify compute environment, jurisdiction, cloud region where applicable, infrastructure type, provider where any, owner where known, custodian, steward, approved workload classes, prohibited workload classes, data classes, evidence classes, output classes, public authority status, sovereign data status, Indigenous data considerations, community data safeguards, public-safe status, access class, handling class, support-access limits, backup location, archive location, deletion obligations, sealing obligations, legal hold status, incident path, and correction path.

9.8.3(c) Compute-to-data methods shall be preferred where national, regional, public authority, sovereign-sensitive, personal, health-sensitive, cyber-sensitive, infrastructure-sensitive, finance-sensitive, community-protected, Indigenous or protected knowledge, confidential source, privileged, controlled-technology, export-controlled, sanctions-sensitive, or otherwise restricted materials should be analyzed without moving or exposing underlying records beyond approved controls.

9.8.3(d) National Dense Core compute methods shall identify data inputs, data permissions, lawful basis where applicable, source records, dataset records, model records, method records, code records, configuration, runtime environment, workload purpose, workload owner, workload custodian, human review status, public-safe status, output identity, output class, confidence effect, uncertainty effect, limitation effect, retention, deletion, sealing, archive status, and correction path.

9.8.3(e) National Dense Core compute shall be logged, access-controlled, purpose-bound, least-privilege, segmented, monitored, secured, and records-valid. Where appropriate, compute may include hashing, signing, timestamping, tamper-evidence, attestation, reproducibility notes, secure enclave records, proof receipts, and dependency records.

9.8.3(f) Sovereign compute or compute-to-data status shall not be treated as proof of truth, lawfulness, public-safe status, certification, recognition, finance-readiness, public authority approval, procurement approval, provider endorsement, sponsor approval, protocol effect, operational clearance, infrastructure operation, or execution readiness by default.

9.8.3(g) Where National Dense Core compute is unauthorized, unlogged, insecure, misclassified, cross-border defective, sovereign-data defective, privacy-defective, cyber-defective, protected-knowledge-defective, public-safe defective, model-defective, dataset-defective, boundary-defective, or correction-defective, GCRI Canada shall hold, restrict, rerun, correct, reclassify, suspend, withdraw, or refuse affected workloads and outputs as appropriate.

9.8.3(h) The controlling rule shall be that national-scale compute may support national evidence only where compute remains permissioned, sovereign-compatible, secure, logged, scoped, reviewed, public-safe, and correctionable.

***

9.8.4 National Dense Core Public Authority Data and National Data Governance Methods.\
9.8.4(a) GCRI Canada shall steward National Dense Core public authority data and national data governance methods for the classification, permissioning, access control, use control, transfer control, retention, deletion, sealing, archival, public-safe treatment, and correction of national-scale or nationally significant evidence and data.

9.8.4(b) Public authority data methods shall identify the public authority source, participating office or function where appropriate, capacity classification, official or non-official status, legal authority or lawful basis where applicable, data-sharing terms, confidentiality, classification, access limits, processing limits, transfer limits, publication limits, reference controls, retention obligations, deletion or return obligations, sealing obligations, notice obligations, public-safe status, and correction path.

9.8.4(c) National data governance methods shall identify data source, owner where known, custodian, steward, contributor, provenance, license, permissions, consent or non-consent treatment where applicable, Indigenous or community protocol where applicable, public authority restrictions, host restrictions, operator restrictions, provider restrictions, sponsor restrictions, commercial sensitivity, finance sensitivity, export-control sensitivity, sanctions sensitivity, controlled-technology sensitivity, permitted-use limits, prohibited-use limits, and correction path.

9.8.4(d) National Dense Core data shall be classified for personal information status, rights-bearing data status, health-sensitive status, cyber-sensitive status, infrastructure-sensitive status, sovereign data status, public authority status, finance-sensitive status, commercially sensitive status, community-protected status, Indigenous or protected knowledge status, confidential-source status, privileged-material status, controlled-technology status, export-control sensitivity, sanctions sensitivity, access class, handling class, public-safe status, transfer status, retention status, deletion status, sealing status, archive status, and legal hold status.

9.8.4(e) National Dense Core data governance shall govern ingestion, transformation, storage, indexing, retrieval, embedding, AI use, compute use, dashboard use, map use, API use, publication use, sharing, cross-border transfer, cross-entity transfer, room routing, data-room access, clean-room access, no-download access, deletion, sealing, archival, and legal hold.

9.8.4(f) Public authority participation, public-sector data contribution, national dataset use, official title reference, agency reference, regulator-listening presence, emergency-management presence, procurement presence, public finance presence, or public-sector interest shall not imply public authority endorsement, adoption, approval, delegation, official guidance, regulatory position, procurement relevance, funding relevance, public finance approval, public warning, emergency command, safe harbor, compliance determination, enforcement position, public-law status, or sovereign obligation by default.

9.8.4(g) Where National Dense Core data governance defects are detected, including unauthorized access, unauthorized transfer, unauthorized AI use, unauthorized embedding, unauthorized retrieval, unauthorized publication, classification error, stale permission, cross-border defect, sovereign-data defect, public authority reference defect, unpropagated correction, deletion failure, sealing failure, or public-safe defect, GCRI Canada shall restrict, correct, delete, seal, reclassify, notify where required, review affected outputs, and update data governance methods.

9.8.4(h) The controlling rule shall be that national data governance must protect authority, sovereignty, rights, security, knowledge, and public trust before national evidence may be used, routed, displayed, or published.

***

9.8.5 National Dense Core AI / Model Governance, Cybersecurity, Key Management, and Incident Methods.\
9.8.5(a) GCRI Canada shall steward National Dense Core AI, model governance, cybersecurity, key management, and incident methods for any material AI, machine learning, statistical, simulation, digital twin, retrieval, embedding, classification, forecasting, inference, agentic, dashboard, map, API, public-good software, technical baseline, or public-safe communication system used in relation to a National Dense Nexus Core.

9.8.5(b) National Dense Core AI and model governance methods shall identify model identity, model version, Model Register entry, Model Card, System Card, Dataset Card where applicable, Benchmark Card where applicable, deployment context, compute environment, retrieval sources, embedding stores, permitted uses, prohibited uses, data classes, evidence classes, output classes, human review requirements, output review requirements, public-safe status, access controls, logging, monitoring, incident path, lifecycle path, and correction path.

9.8.5(c) National Dense Core AI may support source comparison, anomaly identification, summarization, classification, translation, dashboard support, map support, public-safe drafting, simulation, digital twin analysis, degraded-mode analysis, interoperability review, public authority learning materials, GRF input support, GRA input support, Protocol Authority input support, provider-neutral technical review, Academy materials, and correction support, subject to records, classification, and human review where material.

9.8.5(d) National Dense Core AI shall not generate official truth, public warning, emergency command, public authority decision, finance-readiness, procurement approval, certification, recognition, protocol effect, provider preference, sponsor approval, host approval, operator control, operational clearance, infrastructure operation, market authority, national program status, or execution consequence by default.

9.8.5(e) National Dense Core cybersecurity methods shall address unauthorized access, credential compromise, key compromise, token compromise, secrets exposure, sensor tampering, signal spoofing, telemetry corruption, cyber log exposure, prompt injection, tool misuse, API misuse, repository compromise, dashboard manipulation, map manipulation, data exfiltration, malware, denial of service, cross-tenant access, cross-program access, cross-entity access, cross-border access, support-access risk, side-channel leakage, and supply-chain compromise.

9.8.5(f) Key management methods shall identify key owners, custodians, authorized uses, prohibited uses, storage controls, rotation controls, revocation controls, backup controls, recovery controls, access logs, signing authority, Proof Receipt signing status, encryption status, token controls, secrets controls, credential controls, emergency rotation path, compromise path, and correction path.

9.8.5(g) Incident methods shall identify severity, affected data, affected models, affected compute workloads, affected environments, affected dashboards, affected maps, affected APIs, affected public authority materials, affected GRF inputs, affected GRA inputs, affected Protocol Authority inputs, affected National Consortium interfaces, affected National Company interfaces, affected Project SPV interfaces, affected operators, affected hosts, affected providers, affected sponsors, affected communities, affected public-safe outputs, affected dependencies, containment actions, notification decisions, correction actions, and closeout requirements.

9.8.5(h) Where AI, model, cybersecurity, key management, or incident defects are detected, GCRI Canada shall restrict access, rotate credentials, revoke keys, disable affected systems where appropriate, suspend affected models where appropriate, halt affected compute where appropriate, freeze dashboards or maps where appropriate, restrict APIs where appropriate, preserve logs where safe, assess exposure, correct records, notify affected interfaces where required, and review affected outputs and dependencies.

9.8.5(i) The controlling rule shall be that a National Dense Nexus Core can concentrate evidence value and risk; therefore its AI, cybersecurity, keys, credentials, incidents, and corrections must be governed at national-consequence discipline without creating national authority or execution by GCRI Canada.

***

9.8.6 National Dense Core Interfaces With National Nexus Consortiums, National Companies, Project SPVs, Public Authorities, Operators, Hosts, and Providers.\
9.8.6(a) GCRI Canada may maintain National Dense Core interfaces with National Nexus Consortiums, National Companies, Project SPVs, public authorities, operators, hosts, providers, universities, communities, sponsors, GRF, GRA, Protocol Authority, Regional Nexus Consortiums, Nexus Risk Management, Nexus Rails, Nexus Grid, Nexus Academy, and other authorized Nexus actors for evidence learning, public-safe interpretation, observability methods, technical baseline support, public-good software support, Verifiable Compute support, Verifiable Intelligence support, interoperability support, national resilience learning, Academy learning, and correction support.

9.8.6(b) Interfaces with National Nexus Consortiums shall preserve their national public-good convening, coordination, ecosystem, learning, and alignment functions without converting National Dense Core evidence into national authority, public authority delegation, procurement mandate, finance mandate, certification, recognition, protocol effect, provider preference, sponsor control, National Company instruction, Project SPV instruction, operator instruction, host instruction, or execution consequence.

9.8.6(c) Interfaces with National Companies shall preserve National Companies’ separate corporate governance, contracting, financing, procurement, operations, delivery, implementation, vendor management, public authority relationships, sponsor relationships, host relationships, operator relationships, Project SPV relationships, risk allocation, employment, records, duties, liabilities, and execution accountability.

9.8.6(d) Interfaces with Project SPVs shall preserve Project SPVs’ separate project governance, financing, contracting, permitting, procurement, engineering, delivery, operations, insurance, public authority relationships, operator relationships, provider relationships, sponsor relationships, host relationships, records, duties, liabilities, and execution accountability.

9.8.6(e) Interfaces with public authorities shall preserve public authority capacity classification, official or non-official status, data controls, reference controls, non-delegation language, non-endorsement language, non-regulatory language, non-procurement language, non-funding language, non-public-finance language, no-public-warning language, no-emergency-command language, access controls, publication limits, and correction path.

9.8.6(f) Interfaces with operators shall preserve the distinction between Observatory evidence and operator control. Operator data, operator participation, operator access, operator comments, operator dashboard access, operator map access, operator incident context, or operator technical feedback shall not make GCRI Canada an operator or create operational instruction, operational clearance, infrastructure command, service assurance, compliance approval, procurement approval, finance-readiness, certification, recognition, protocol effect, or execution consequence by default.

9.8.6(g) Interfaces with hosts shall preserve host role, facility context where safe and material, infrastructure context, safe-location treatment, privacy controls, cybersecurity controls, public-safe status, no-operation boundary, no-host-approval boundary, no-certification boundary, no-finance boundary, no-procurement boundary, no-execution boundary, and correction path.

9.8.6(h) Interfaces with providers shall preserve provider neutrality, conflict disclosure, provider role classification, benchmark conditions, validation conditions, commercial sensitivity, IP sensitivity, cybersecurity sensitivity, export-control sensitivity, prohibited claims, no-endorsement language, no-procurement-preference language, no-certification language, no-protocol-effect language, no-finance-readiness language, no-market-superiority language, and correction path.

9.8.6(i) Interfaces with communities and Indigenous or protected knowledge holders shall preserve community protocols, Indigenous protocols where applicable, consent or non-consent where applicable, territorial context, cultural context, environmental knowledge context, sensitive-site treatment, public-safe mapping limits, source protection, withdrawal or challenge pathways where applicable, accessibility, translation, localization, and do-no-harm controls.

9.8.6(j) Interfaces under this section shall be governed by interface records, access controls, controlled-room or data-room rules where applicable, data-sharing records where applicable, public-safe review, boundary language, correction obligations, dependency review, assurance review, and closeout records.

9.8.6(k) The controlling rule shall be that National Dense Core interfaces may support national learning, evidence discipline, interoperability, and correction, but they shall not transfer authority, merge roles, create finance or procurement consequence, command operators, approve providers, or execute implementation.

***

9.8.7 National Dense Core Finance-Readiness Input Evidence Without Finance Execution.\
9.8.7(a) GCRI Canada may provide National Dense Core evidence inputs to GRA, Nexus Rails, RNFD, NFD, UNFSD, capital-reader literacy contexts, insurance-readiness input contexts, resilience evidence contexts, host readiness evidence contexts, node evidence contexts, public-safe finance-boundary materials, and related finance-facing learning interfaces, provided that such inputs remain non-financial, non-advisory, non-rating, non-guaranteeing, evidence-supporting, public-safe where externally released, and correctionable.

9.8.7(b) National Dense Core finance-facing input evidence may include regional evidence, national evidence, risk evidence, resilience evidence, host readiness evidence, node evidence, degraded-mode evidence, observability evidence, source comparison records, confidence records, uncertainty records, limitation statements, compute records, model records, dataset records, benchmark records, Proof Receipt Records, Evidence Packs, Decision Packs, public-safe summaries, controlled annexes, and correction signals.

9.8.7(c) Finance-facing input records shall identify receiving interface, purpose, evidence classes, data classes, output classes, source records, method records, compute records, model records where applicable, public-safe status, finance-safe status, access class, handling class, confidence, uncertainty, limitations, no-advice boundary, no-rating boundary, no-guarantee boundary, no-public-finance-approval boundary, permitted use, prohibited use, correction path, supersession path, withdrawal path, retraction path where applicable, and dependency links.

9.8.7(d) National Dense Core finance-facing inputs shall not constitute finance-readiness, capital-readiness, insurance-readiness, investment advice, securities recommendation, brokerage, placement, finder activity, lending decision, underwriting decision, insurance approval, rating, guarantee, public finance approval, bankability, fundability, capital commitment, credit quality, insurance quality, investment quality, financial suitability, procurement approval, project approval, or execution consequence by GCRI Canada.

9.8.7(e) GCRI Canada shall not use National Dense Core methods to solicit investment, recommend securities, arrange financing, place capital, make underwriting judgments, approve insurance, rate credit, guarantee performance, approve public finance, determine bankability, direct lenders, direct insurers, direct investors, or create capital-market consequence.

9.8.7(f) Confidence scores, resilience indicators, risk indicators, host readiness evidence, node evidence, benchmark results, dashboards, maps, Proof Receipts, public-safe summaries, AI-generated summaries, or Evidence Packs arising from a National Dense Nexus Core shall not be used or framed by GCRI Canada as ratings, guarantees, finance-readiness determinations, insurance-readiness determinations, bankability determinations, fundability determinations, public finance approvals, investment recommendations, procurement recommendations, or provider preferences.

9.8.7(g) Where finance-facing misuse or overclaim is detected, GCRI Canada shall correct, relabel, restrict, withdraw, reissue, require removal of misleading references, notify affected GRA or Rails interfaces where appropriate, suspend affected interface use, or pursue contractual or legal remedies where appropriate.

9.8.7(h) The controlling rule shall be that National Dense Core evidence may help finance-facing actors understand evidence, risk, and resilience, but GCRI Canada shall not execute finance or create finance-readiness.

***

9.8.8 National Dense Core Public-Safe Publication and Boundary Language.\
9.8.8(a) GCRI Canada shall apply heightened public-safe publication and boundary-language controls to National Dense Core public-safe summaries, dashboards, maps, reports, technical notes, APIs, datasets, Academy materials, community-facing materials, host-facing materials, public authority learning materials, GRF-facing summaries, GRA-facing summaries, Protocol Authority-facing summaries, provider-facing materials, sponsor-facing materials, operator-facing materials, media materials, event materials, repository materials, website materials, and public claims.

9.8.8(b) National Dense Core public-safe review shall assess whether the output discloses or enables misuse of personal information, rights-bearing data, health-sensitive data, cyber-sensitive information, infrastructure-sensitive information, public authority restricted information, sovereign-sensitive information, finance-sensitive information, commercially sensitive information, community-protected information, Indigenous or protected knowledge, confidential source information, privileged material, credentials, secrets, keys, tokens, controlled technology, exploit details, sensitive locations, unsafe geospatial precision, unsafe metadata, operator-sensitive information, or national-security-adjacent sensitive information.

9.8.8(c) National Dense Core public-safe outputs shall identify, where material, source classes, national methods, regional methods, compute treatment, model treatment, confidence, uncertainty, limitations, contradiction status, data-gap status, public-safe omissions, responsible non-disclosure basis, stale-data treatment, correction status, supersession status, withdrawal status where applicable, retraction status where applicable, permitted use, prohibited use, and boundary language.

9.8.8(d) Boundary language shall state or preserve, where material, that the output does not constitute public authority decision, official national program status, public warning, emergency command, regulatory approval, procurement approval, funding approval, public finance approval, finance-readiness, investment advice, insurance approval, lending decision, underwriting decision, rating, guarantee, certification, recognition, maturity record, claims approval, Protocol Authority effect, conformance determination, Nexus-compatible status, provider endorsement, sponsor approval, host approval, operator instruction, operational clearance, infrastructure operation, market authority, deployment approval, legal status, professional advice, or execution consequence.

9.8.8(e) National dashboards and maps shall be reviewed for official-status implication, public warning implication, emergency-command implication, national-program implication, public finance implication, procurement implication, investment-zone implication, provider-market implication, sponsor-territory implication, geospatial sensitivity, infrastructure exposure, cyber-sensitive detail, operator-sensitive detail, protected knowledge exposure, false precision, overconfident colors, misleading legends, drill-down risk, export risk, API exposure, stale-data risk, and third-party reuse risk.

9.8.8(f) Where National Dense Core outputs cannot be made public-safe without distorting evidence, erasing uncertainty, concealing contradiction, exposing restricted data, exposing protected knowledge, creating public warning implication, creating official national status implication, creating finance overclaim, creating procurement implication, creating operator risk, or creating unauthorized authority, GCRI Canada may use controlled annexes, controlled-room review, aggregation, generalization, safe-location treatment, delayed release, responsible non-disclosure, limited public-safe statement, or no-publication treatment.

9.8.8(g) Where National Dense Core public-safe outputs are corrected, restricted, superseded, withdrawn, retracted, misused, misquoted, mistranslated, or made stale by later evidence, GCRI Canada shall update public-safe output records, issue public-safe or controlled correction where appropriate, and review affected dependencies and interfaces.

9.8.8(h) The controlling rule shall be that national-scale public-safe communication must be nationally legible without becoming official national authority, public warning, finance signal, procurement signal, provider market signal, sponsor validation, operator command, or execution instruction.

***

9.8.9 National Dense Core Does Not Become GCRI Canada Infrastructure Ownership or Operation by Default.\
9.8.9(a) No National Dense Nexus Core, National Dense Core record, national dashboard, national map, national API, national Evidence Pack, national Decision Pack, national technical note, national report, national public-safe output, national interface, national room, national benchmark, national Proof Receipt, national compute record, national degraded-mode indicator, national continuity indicator, national correction signal, or national public claim shall make GCRI Canada the owner, operator, controller, commander, maintainer, service provider, telecommunications operator, AI-RAN operator, O-RAN operator, private wireless operator, DePIN operator, cyber operator, geospatial operator, cloud operator, public authority operator, emergency-management operator, market infrastructure operator, National Company, Project SPV, provider, host, sponsor, or execution actor by default.

9.8.9(b) A National Dense Nexus Core shall not issue or imply infrastructure control, operational command, service assurance, uptime assurance, emergency command, public warning, evacuation instruction, public safety directive, public health order, official guidance, regulatory determination, public authority decision, compliance determination, enforcement position, safe harbor, permit, license, procurement decision, vendor award, funding approval, public finance approval, finance-readiness, investment advice, lending decision, underwriting decision, insurance approval, rating, guarantee, certification, recognition, maturity record, conformance determination, Nexus-compatible status, provider ranking, sponsor finding, host approval, operator approval, deployment authorization, operational clearance, or market signal.

9.8.9(c) The use of national-scale compute, sovereign compute, dashboards, maps, APIs, Proof Receipts, controlled rooms, public authority rooms, operator interfaces, provider interfaces, National Company interfaces, Project SPV interfaces, regional interfaces, or public-safe summaries shall not convert GCRI Canada into an infrastructure owner or operator.

9.8.9(d) Public authorities, infrastructure operators, telecommunications operators, AI-RAN operators, O-RAN operators, private wireless operators, DePIN operators, cyber operators, geospatial operators, cloud operators, hosts, providers, National Companies, Project SPVs, emergency-management actors, public finance actors, procurement actors, regulators, GRF, GRA, Protocol Authority, universities, communities, and other actors shall remain responsible for their own authorities, systems, duties, decisions, operations, liabilities, and records.

9.8.9(e) Any authority-bearing or execution-bearing action by a public authority, operator, GRF, GRA, Protocol Authority, National Nexus Consortium, Regional Nexus Consortium, National Company, Project SPV, provider, sponsor, host, finance actor, procurement actor, infrastructure actor, university, community, or other actor shall arise only through that actor’s own lawful authority, process, record, accountability, and liability, not through the National Dense Nexus Core by implication.

9.8.9(f) Where National Dense Core materials are misused to imply GCRI Canada ownership, operation, public authority, emergency command, public warning, finance approval, procurement authority, certification, recognition, protocol effect, provider preference, sponsor approval, host approval, operator control, market authority, infrastructure operation, deployment approval, legal status, professional advice, or execution consequence, GCRI Canada shall correct, relabel, restrict, withdraw, reissue, require removal of misleading references, notify affected interfaces where appropriate, suspend affected interface use, or pursue contractual or legal remedies where appropriate.

9.8.9(g) No ambiguity shall be resolved in favour of GCRI Canada ownership, operation, public authority, finance, procurement, certification, recognition, protocol, provider preference, sponsor control, operator control, or execution. Where there is doubt, the interpretation preserving GCRI Canada’s non-execution role, public authority boundaries, finance boundaries, procurement neutrality, provider neutrality, sponsor non-control, operator boundaries, host boundaries, community safeguards, GRF role separation, GRA role separation, Protocol Authority role separation, validity-by-record, correctionability, and public trust shall prevail.

9.8.9(h) The controlling rule shall be that a National Dense Nexus Core may make national systems more observable and evidence-linked, but observability, compute, dashboards, and records do not make GCRI Canada the owner or operator of national infrastructure.

***

9.8.10 National Dense Core Records, Authority Boundaries, Correction, and Assurance.\
9.8.10(a) GCRI Canada shall maintain, or cause to be maintained, National Dense Core records for material National Dense Nexus Core methods, interfaces, compute environments, workloads, dashboards, maps, APIs, Evidence Packs, Decision Packs, public-safe summaries, controlled annexes, incidents, corrections, dependencies, assurance reviews, and closeout events.

9.8.10(b) National Dense Core records shall identify core title or identifier, national context, owner where known, GCRI Canada responsible function where applicable, custodian, steward, jurisdictional context, geographic or functional scope, temporal scope, technology domains, risk domains, Regional Observatory Cluster relationships, Cluster relationships, Hub relationships, Node relationships, Hotspot relationships, host contexts, operator contexts, public authority contexts, provider contexts, sponsor contexts, community contexts, Indigenous or protected knowledge contexts, National Nexus Consortium context, National Company context, Project SPV context, GRF context, GRA context, Protocol Authority context, data classes, evidence classes, output classes, access class, handling class, public-safe status, privacy status, cybersecurity status, sovereign data status, public authority status, finance-sensitive status, provider-sensitive status, sponsor-sensitive status, operator-sensitive status, host-sensitive status, community-protected status, Indigenous or protected knowledge status, legal sensitivity, export-control sensitivity, sanctions sensitivity, permitted uses, prohibited uses, publication limits, and correction path.

9.8.10(c) Authority boundary records shall identify, where material, no-public-authority status, no-public-warning status, no-emergency-command status, no-finance-readiness status, no-investment-advice status, no-rating status, no-guarantee status, no-procurement status, no-certification status, no-recognition status, no-protocol-effect status, no-provider-endorsement status, no-sponsor-approval status, no-host-approval status, no-operator-control status, no-infrastructure-operation status, no-market-authority status, no-deployment-approval status, and no-execution status.

9.8.10(d) National Dense Core correction records shall identify corrected source, corrected data, corrected method, corrected compute workload, corrected compute environment, corrected model, corrected dataset, corrected sensor state, corrected field record, corrected dashboard, corrected map, corrected API, corrected public-safe output, corrected public authority reference, corrected operator reference, corrected provider reference, corrected sponsor reference, corrected host reference, corrected community reference, corrected National Nexus Consortium interface, corrected National Company interface, corrected Project SPV interface, corrected Regional Nexus Consortium interface, corrected GRA interface, corrected GRF interface, corrected Protocol Authority interface, corrected RNFD or Nexus Rails interface, prior status, corrected status, effective date, reviewer, affected dependencies, notice decision, access change, archive treatment, and continuing limitations.

9.8.10(e) National Dense Core supersession records shall identify replacement core record, changed national scope, changed regional relationships, changed evidence base, changed compute environment, changed model, changed dataset, changed host context, changed operator context, changed community context, changed public authority context, changed provider context, changed sponsor context, changed National Nexus Consortium context, changed National Company context, changed Project SPV context, changed methods, changed confidence, changed uncertainty, changed limitations, changed public-safe status, changed boundary language, continuing validity where any, discontinued reliance where any, and downstream dependency treatment.

9.8.10(f) National Dense Core withdrawal or retraction records shall be used where national-scale materials should no longer be used or relied upon because of material error, unsafe disclosure, public-safe defect, overclaim, public authority confusion, finance overclaim, procurement implication, provider-preferential framing, sponsor-validation framing, host approval implication, operator-control implication, protected knowledge exposure, community harm risk, privacy defect, cybersecurity defect, sovereign data issue, cross-border defect, national misclassification, infrastructure-risk exposure, or correction failure.

9.8.10(g) National Dense Core assurance records shall identify review cycle, reviewers, scope reviewed, regional relationships reviewed, Nodes reviewed, Hubs reviewed, Clusters reviewed, Hotspots reviewed, sources reviewed, datasets reviewed, compute reviewed, models reviewed, dashboards reviewed, maps reviewed, APIs reviewed, interoperability reviewed, public-safe outputs reviewed, public authority boundaries reviewed, finance boundaries reviewed, procurement boundaries reviewed, provider neutrality reviewed, sponsor non-control reviewed, host boundaries reviewed, operator boundaries reviewed, protected knowledge safeguards reviewed, cybersecurity reviewed, privacy reviewed, sovereign data reviewed, findings, corrective action plans, training updates, technical control updates, Board or committee reporting where material, residual risk, and closeout status.

9.8.10(h) National Dense Core closeout records shall identify completion, suspension, termination, retirement, archive, data return, data deletion, data sealing, access revocation, credential revocation, key revocation, room closure, dashboard removal where applicable, map removal where applicable, API deprecation where applicable, compute decommissioning where applicable, outstanding corrections, outstanding notices, retained records, archive status, public-safe obligations, confidentiality obligations, protected knowledge obligations, public authority obligations, operator obligations, provider obligations, sponsor obligations, host obligations, community obligations, National Nexus Consortium obligations, National Company obligations, Project SPV obligations, Regional Nexus Consortium obligations, GRA obligations, GRF obligations, Protocol Authority obligations, RNFD or Nexus Rails obligations where any, and continuing prohibited uses.

9.8.10(i) National Dense Core records shall be linked, where applicable, to Regional Observatory Cluster records, Cluster records, Hub records, Node records, Hotspot records, Observatory Methods Register entries, Evidence Register entries, Source Comparison Records, Dataset Register entries, Model Register entries, System Card entries, Benchmark Card entries, Compute Workload Records, Compute Environment Records, Inference Records, Human Review Records, Retrieval and Embedding Records, Proof Receipt Records, Public-Safe Output Records, AI Incident Records, Correction Records, Dependency Records, Truth Engine Records, public authority records, GRF interface records, GRA interface records, Protocol Authority interface records, RNFD records, Nexus Risk Management records, Nexus Rails records, Regional Nexus Consortium records, National Nexus Consortium records, National Company records, Project SPV records, operator records, provider records, sponsor records, host records, community records, university records, Nexus interface records, and public claims records.

9.8.10(j) National Dense Core records, authority boundary records, correction, supersession, withdrawal, retraction, assurance, retirement, archive, and closeout shall not create certification, recognition, finance-readiness, public authority decision, procurement approval, provider endorsement, sponsor approval, host approval, operator approval, rating, guarantee, public warning, emergency command, protocol effect, operational clearance, legal status, market authority, infrastructure operation, deployment approval, national authority, or execution consequence by default.

9.8.10(k) The controlling rule shall be that every material National Dense Nexus Core must remain traceable through national purpose, evidence, compute, interfaces, authority boundaries, safeguards, public-safe summaries, correction, assurance, and closeout because national-scale observability is trustworthy only when the institution can show what was connected, what was protected, what was bounded, what changed, what was corrected, and what must no longer be relied upon.

### 9.9 Sovereign Compute Methods for Observatory Systems

9.9.1 Sovereign Compute as Observatory Evidence and Data-Sovereignty Infrastructure.\
9.9.1(a) GCRI Canada shall steward sovereign compute methods for Observatory systems as evidence-supporting, data-sovereignty-supporting, security-controlled, privacy-protective, jurisdiction-aware, public-safe, and correctionable compute infrastructure within GCRI Canada’s non-executing technical-stewardship mandate.

9.9.1(b) Sovereign compute methods may support Observatory evidence processing, source comparison, sensor processing, AI-RAN signal processing, O-RAN signal processing, private wireless signal processing, DePIN telemetry processing, cyber analysis, geospatial analysis, Earth observation processing, digital twin analysis, simulation, dashboard generation, map generation, API generation, public-safe summarization, Verifiable Compute, Verifiable Intelligence, Nexus Truth Engine interfaces, Evidence Packs, Decision Packs, public authority learning, GRF inputs, GRA inputs, Protocol Authority inputs, Academy materials, and correction workflows.

9.9.1(c) Sovereign compute shall be understood as a governance and records discipline for where and how Observatory data are processed, accessed, logged, protected, reviewed, and corrected. It shall not be treated merely as a branding term, cloud-region label, data-centre location, provider assurance, encryption claim, public authority preference, sponsor-funded environment, or technical architecture diagram.

9.9.1(d) Sovereign compute methods shall identify data residency, localization, cross-border transfer, jurisdictional access, support access, public authority data zones, Indigenous data considerations, community data safeguards, national data infrastructure requirements, compute-to-data requirements, secure enclave requirements, confidential computing requirements, air-gap requirements, no-download requirements, access controls, logging, monitoring, retention, deletion, sealing, archival, and correction paths.

9.9.1(e) Sovereign compute methods shall apply where Observatory data or outputs involve public authority materials, personal information, rights-bearing data, health-sensitive data, cyber-sensitive information, infrastructure-sensitive information, sovereign-sensitive information, finance-sensitive information, community-protected information, Indigenous or protected knowledge, confidential source information, privileged materials, controlled technology, export-controlled materials, sanctions-sensitive materials, or other restricted materials.

9.9.1(f) Sovereign compute shall not create certification, recognition, finance-readiness, investment advice, public authority decision, procurement approval, provider endorsement, sponsor approval, rating, guarantee, public warning, emergency command, protocol effect, operational clearance, infrastructure operation, market authority, legal status, deployment approval, or execution consequence by default.

9.9.1(g) Where sovereign compute methods are used in public-facing, public authority-facing, finance-facing, GRF-facing, GRA-facing, Protocol Authority-facing, provider-facing, sponsor-facing, host-facing, operator-facing, community-facing, or Academy materials, GCRI Canada shall preserve boundary language, public-safe review, source lineage, compute records, confidence, uncertainty, limitations, and correction path.

9.9.1(h) The controlling rule shall be that sovereign compute supports Observatory evidence by protecting where data live, who may access them, how processing occurs, and how outputs are corrected; it does not create authority over the data, systems, actors, or decisions touched by the computation.

***

9.9.2 Compute-to-Data as Default for Restricted, Sovereign-Sensitive, Public Authority, Rights-Bearing, Community-Protected, or Protected Knowledge Materials.\
9.9.2(a) GCRI Canada shall treat compute-to-data as the default method for Observatory processing involving restricted, sovereign-sensitive, public authority, rights-bearing, community-protected, Indigenous, protected knowledge, confidential, cyber-sensitive, infrastructure-sensitive, health-sensitive, finance-sensitive, privileged, export-controlled, sanctions-sensitive, controlled-technology, or otherwise sensitive materials where moving the underlying data would create avoidable legal, privacy, cybersecurity, sovereignty, community, public-safe, or trust risk.

9.9.2(b) Compute-to-data methods shall require that approved computation, review, querying, summarization, model evaluation, dashboard preparation, map preparation, public-safe output preparation, or correction occur within or adjacent to the approved data environment, rather than exporting underlying records beyond authorized controls.

9.9.2(c) Compute-to-data methods shall identify the data environment, compute environment, approved workloads, prohibited workloads, data classes, evidence classes, output classes, authorized users, authorized systems, approved models, approved code, approved retrieval sources, approved embedding stores where any, output review requirements, public-safe review requirements, export limits, logging requirements, and correction path.

9.9.2(d) Compute-to-data methods shall apply to controlled rooms, clean rooms, data rooms, no-download rooms, secure enclaves, confidential computing environments, air-gapped environments, public authority environments, university environments, host environments, provider environments, community-controlled environments, National Dense Nexus Core environments, Regional Observatory Cluster environments, Hub environments, Node environments, and other approved environments where sensitive data should remain in place.

9.9.2(e) Outputs from compute-to-data environments shall be reviewed before removal, publication, sharing, dashboarding, mapping, API exposure, embedding, retrieval, translation, summarization, citation, or routing to another interface. Output review shall assess whether outputs reveal restricted data, sensitive metadata, re-identification pathways, source identities, protected knowledge, public authority restricted information, cyber-sensitive information, infrastructure-sensitive information, geospatial sensitivity, or unsafe inferences.

9.9.2(f) Compute-to-data methods shall not authorize training, fine-tuning, embedding, retrieval, vendor model improvement, public AI tool use, agentic action, downloading, copying, printing, screenshotting, screen recording, local syncing, or export merely because computation occurred in a restricted environment. Each such use shall require express recorded authority.

9.9.2(g) Where compute-to-data controls fail, including unauthorized export, output leakage, retrieval leakage, embedding leakage, model leakage, access breach, side-channel exposure, unsafe summarization, unsafe map layer, unsafe dashboard field, or unauthorized reuse, GCRI Canada shall restrict access, preserve logs where safe, contain the incident, correct records, notify affected interfaces where required, review affected outputs, and update controls.

9.9.2(h) The controlling rule shall be that sensitive Observatory data should not travel to computation when computation can safely travel to the data.

***

9.9.3 Approved Compute Environments for Observatory Data.\
9.9.3(a) GCRI Canada shall define and maintain approved compute environment methods for Observatory data, including criteria for public cloud, private cloud, sovereign cloud, edge compute, on-premise compute, high-performance compute, secure enclave, confidential computing, compute-to-data, air-gapped, no-download, controlled-room, clean-room, data-room, public authority, university, provider, host, community-controlled, National Dense Nexus Core, Regional Observatory Cluster, Hub, Node, and sandbox environments.

9.9.3(b) Approved compute environments shall be recorded in applicable Compute Environment Registers and shall identify environment title or identifier, owner, custodian, steward, provider where any, jurisdiction, cloud region where applicable, infrastructure type, approved workload classes, prohibited workload classes, data classes supported, evidence classes supported, output classes supported, access class, handling class, public-safe status, sovereign data status, public authority status, protected knowledge status, cyber-sensitive status, finance-sensitive status, and correction path.

9.9.3(c) Approval criteria shall include lawful basis where applicable, data residency, localization, cross-border transfer controls, support access controls, subprocessors, identity and access management, least privilege, segmentation, isolation, logging, monitoring, encryption, key management, token management, secrets management, credential controls, vulnerability management, backup controls, disaster recovery, exit readiness, decommissioning path, incident path, retention treatment, deletion treatment, sealing treatment, archive treatment, and legal hold treatment.

9.9.3(d) Environment approval shall be specific to workload class, data class, evidence class, output class, jurisdiction, access class, handling class, public-safe status, public authority status, protected knowledge status, model use, retrieval use, embedding use, dashboard use, map use, API use, and interface use. Approval for one use shall not imply approval for all uses.

9.9.3(e) An environment shall not be treated as approved merely because it is commercially reputable, public-sector-used, provider-certified, sponsor-funded, sovereign-branded, locally hosted, cloud-secure, encrypted, high-performance, integrated with existing tools, or previously approved for another program.

9.9.3(f) Experimental, sandbox, evaluation, provider-hosted, sponsor-supported, public AI, unmanaged, personal-device, unlogged, cross-border, or unclear-jurisdiction environments shall not be used for restricted Observatory data unless competent review records a lawful, safe, bounded, and correctionable basis for such use.

9.9.3(g) Where an approved compute environment’s legal, privacy, cybersecurity, sovereign data, public authority, protected knowledge, provider, sponsor, or public-safe posture changes materially, GCRI Canada shall update the environment record and review affected workloads, outputs, dependencies, dashboards, maps, APIs, and interface records.

9.9.3(h) The controlling rule shall be that compute environments are approved only for recorded purposes, risks, data, audiences, and controls; environment reputation is not environment authority.

***

9.9.4 Secure Enclaves, Confidential Computing, Air-Gapped Environments, and No-Download Rooms.\
9.9.4(a) GCRI Canada shall steward methods for secure enclaves, confidential computing, air-gapped environments, no-download rooms, controlled rooms, clean rooms, and data rooms where Observatory data or outputs require heightened containment, access control, confidentiality, cybersecurity, sovereign data protection, public authority restriction, protected knowledge protection, or public-safe control.

9.9.4(b) Secure enclave methods shall identify enclave purpose, data classes, evidence classes, approved workloads, prohibited workloads, authorized users, authorized systems, identity controls, access controls, segmentation, isolation, encryption, key management, logging, monitoring, output review, retention, deletion, sealing, archival, incident path, and correction path.

9.9.4(c) Confidential computing methods shall identify attestation requirements, hardware or software trust boundary where applicable, workload identity, runtime configuration, key release conditions, access controls, logging, provider role, jurisdiction, support access, residual risk, output review, and correction path.

9.9.4(d) Air-gapped methods shall identify isolation requirements, allowed inputs, prohibited inputs, allowed outputs, prohibited outputs, transfer media controls, malware scanning, chain-of-custody controls, access controls, logging, review, emergency procedures, decommissioning, and correction path.

9.9.4(e) No-download room methods shall prohibit or restrict downloading, copying, printing, screenshotting, screen recording, local syncing, API export, embedding into unauthorized systems, retrieval into unauthorized systems, model training, vendor processing, public AI tool processing, and redistribution, unless express recorded authority permits a specific exception.

9.9.4(f) Output from secure enclaves, confidential computing environments, air-gapped environments, and no-download rooms shall be reviewed for leakage, inference, re-identification, sensitive metadata, source exposure, protected knowledge exposure, cyber-sensitive detail, infrastructure-sensitive detail, public authority restricted detail, finance-sensitive detail, and public-safe meaning before removal or external routing.

9.9.4(g) Use of secure enclaves, confidential computing, air-gapping, or no-download rooms shall not be represented as certification, public authority approval, finance-readiness, security guarantee, privacy guarantee, sovereign approval, provider endorsement, sponsor approval, procurement approval, operational clearance, or execution readiness by default.

9.9.4(h) The controlling rule shall be that high-control compute environments reduce risk only when their access, output, logging, review, and correction controls are themselves governed.

***

9.9.5 Compute Workload Records for Observatory Processing.\
9.9.5(a) GCRI Canada shall maintain, or cause to be maintained, Compute Workload Records for material Observatory processing, including workloads supporting Nodes, Hubs, Clusters, Hotspots, Regional Observatory Clusters, National Dense Nexus Cores, dashboards, maps, APIs, datasets, Evidence Packs, Decision Packs, public-safe summaries, public authority learning materials, GRF inputs, GRA inputs, Protocol Authority inputs, Academy materials, public-good software, technical baselines, and correction workflows.

9.9.5(b) Compute Workload Records shall identify workload title or identifier, purpose, owner, custodian, steward, requesting function, approving actor where applicable, source records, dataset records, model records, method records, code records, compute environment, jurisdiction, provider where any, infrastructure type, data class, evidence class, output class, access class, handling class, public-safe status, public authority status, sovereign data status, protected knowledge status, finance-sensitive status, and correction path.

9.9.5(c) Workload records shall identify input data, permissions, lawful basis where applicable, public authority restrictions, privacy restrictions, cybersecurity restrictions, sovereign data restrictions, community restrictions, Indigenous or protected knowledge restrictions, provider-use limits, sponsor-use limits, transfer limits, retention status, deletion status, sealing status, archive status, and dependency links.

9.9.5(d) Workload records shall identify model or code identity, version, dependencies, environment, runtime, configuration, execution context, retrieval sources where applicable, embedding stores where applicable, prompt or query records where applicable, human review status, technical review status, privacy review status, cybersecurity review status, public authority review status, safeguards review status, boundary review status, and output review status.

9.9.5(e) Workload records shall identify output identity, output classification, output location, output custodian, confidence, uncertainty, limitations, public-safe status, permitted use, prohibited use, dashboard relationship, map relationship, API relationship, Evidence Pack relationship, Decision Pack relationship, public-safe publication relationship, interface relationship, correction path, supersession path, withdrawal path, retraction path where applicable, and archive path.

9.9.5(f) Material Observatory workloads shall not be reused, rerun, generalized, copied, automated, scheduled, embedded, exposed through APIs, moved across environments, or applied to new datasets, models, Nodes, Hubs, Clusters, Hotspots, regions, national cores, public authority contexts, finance-facing contexts, provider contexts, sponsor contexts, host contexts, or community contexts without review proportionate to the changed use.

9.9.5(g) Where a Compute Workload Record is incomplete, stale, inaccurate, unreviewed, insecure, misclassified, cross-border defective, public-safe defective, privacy-defective, cyber-defective, sovereign-data defective, protected-knowledge defective, boundary-defective, or correction-defective, GCRI Canada shall hold, restrict, rerun, correct, supersede, withdraw, or refuse affected outputs as appropriate.

9.9.5(h) The controlling rule shall be that Observatory processing is evidence-valid only when the workload record shows what was computed, on what data, in what environment, under what authority, producing what output, with what limits, and how it can be corrected.

***

9.9.6 Compute Location, Jurisdiction, Provider, Custodian, Access, Logging, and Output Records.\
9.9.6(a) GCRI Canada shall maintain compute location, jurisdiction, provider, custodian, access, logging, and output records for material Observatory compute environments and workloads.

9.9.6(b) Compute location records shall identify physical location where known and safe, logical location, cloud region where applicable, data residency status, backup location, archive location, support access location, disaster recovery location, edge location where applicable, secure enclave location where applicable, and any cross-border exposure.

9.9.6(c) Jurisdiction records shall identify applicable national, provincial, territorial, Indigenous, community, institutional, contractual, public authority, export-control, sanctions, controlled-technology, privacy, cybersecurity, data-residency, data-localization, and confidentiality constraints to the extent relevant to the compute environment or workload.

9.9.6(d) Provider records shall identify compute provider, cloud provider, infrastructure provider, software provider, managed service provider, AI provider, data-room provider, clean-room provider, enclave provider, university provider, public authority environment provider, host environment provider, or other relevant provider, together with provider role, access rights, support rights, subprocessors, contractual limits, security posture where known, data-use limits, model-improvement limits, conflict status, and correction path.

9.9.6(e) Custodian records shall identify GCRI Canada responsible function where applicable, external custodian where applicable, data steward, system steward, workload owner, environment owner, reviewer, public-safe approver where applicable, access administrator, key custodian, log custodian, output custodian, and correction custodian.

9.9.6(f) Access records shall identify authorized users, roles, organizations, capacities, approval basis, access purpose, access duration, least-privilege controls, room rules where any, download restrictions, retrieval permissions, embedding permissions, AI-use permissions, export permissions, public-safe permissions, logging requirements, monitoring requirements, revocation path, and closeout requirements.

9.9.6(g) Logging records shall identify access logs, workload logs, query logs, prompt logs where applicable, retrieval logs, embedding logs, model logs, code execution logs, API logs, dashboard logs, map logs, output export logs, key access logs, admin logs, incident logs, correction logs, log retention, log sealing, log deletion, and log review cycle.

9.9.6(h) Output records shall identify output title or identifier, output class, output location, output custodian, source records, workload relationship, method relationship, model relationship where applicable, confidence, uncertainty, limitations, public-safe status, access class, handling class, permitted use, prohibited use, boundary language, publication status, interface status, correction path, supersession path, withdrawal path, retraction path where applicable, archive path, and dependency links.

9.9.6(i) The controlling rule shall be that sovereign compute cannot be trusted without knowing where computation occurred, whose law may touch it, who provided it, who controlled it, who accessed it, what was logged, and what outputs left the environment.

***

9.9.7 Sovereign Compute Interface With National Dense Cores, Regional Clusters, Nodes, and Hubs.\
9.9.7(a) GCRI Canada may maintain sovereign compute interfaces with National Dense Nexus Cores, Regional Observatory Clusters, Observatory Clusters, Hubs, Nodes, Hotspots, public authority environments, host environments, provider environments, university environments, community-controlled environments, data rooms, clean rooms, controlled rooms, no-download rooms, GRF interfaces, GRA interfaces, Protocol Authority interfaces, Nexus Risk Management interfaces, Nexus Rails interfaces, Nexus Grid inputs, and Nexus Academy materials.

9.9.7(b) Sovereign compute interface records shall identify interface purpose, connected systems, connected records, connected environments, data classes, evidence classes, output classes, access class, handling class, public-safe status, sovereign data status, public authority status, protected knowledge status, cross-border status, compute-to-data status, permitted flows, prohibited flows, permitted users, prohibited users, permitted workloads, prohibited workloads, permitted outputs, prohibited outputs, and correction path.

9.9.7(c) Interfaces with National Dense Nexus Cores shall preserve national-scale evidence, compute, interoperability, continuity, public authority learning, public-safe publication, and correction purposes without creating national authority, infrastructure operation, operator control, public warning, finance-readiness, procurement approval, certification, recognition, protocol effect, provider preference, sponsor approval, or execution consequence.

9.9.7(d) Interfaces with Regional Observatory Clusters and Observatory Clusters shall preserve regional or cluster evidence learning, source comparison, degraded-mode awareness, host readiness evidence, public-safe summaries, and correction discipline without creating regional authority, official hazard status, finance approval, procurement authority, provider market, sponsor territory, or execution mandate.

9.9.7(e) Interfaces with Hubs, Nodes, and Hotspots shall preserve local and contextual evidence processing, safe-location treatment, source protection, host safeguards, community safeguards, public authority boundaries, provider neutrality, sponsor non-control, public-safe treatment, and correctionability.

9.9.7(f) Sovereign compute interfaces shall not permit unrestricted data replication, uncontrolled API exposure, uncontrolled dashboarding, uncontrolled mapping, unauthorized retrieval, unauthorized embedding, unauthorized model training, unauthorized vendor processing, unauthorized public AI tool use, uncontrolled cross-border access, or unrestricted public-safe publication.

9.9.7(g) Where a sovereign compute interface becomes unauthorized, overbroad, insecure, unlogged, stale, misclassified, cross-border defective, public-safe defective, public authority defective, finance-boundary defective, provider-neutrality defective, sponsor-control defective, protected-knowledge defective, or correction-defective, GCRI Canada shall restrict, reclassify, correct, suspend, retire, or refuse the interface as appropriate.

9.9.7(h) The controlling rule shall be that sovereign compute interfaces should connect evidence environments without dissolving the data, jurisdiction, access, role, and correction boundaries that make sovereign compute necessary.

***

9.9.8 Sovereign Compute Cybersecurity, Resilience, Backup, Continuity, and Decommissioning Methods.\
9.9.8(a) GCRI Canada shall steward cybersecurity, resilience, backup, continuity, disaster recovery, exit readiness, migration, decommissioning, and closeout methods for sovereign compute environments and workloads supporting Observatory systems.

9.9.8(b) Cybersecurity methods shall identify identity controls, access controls, least privilege, segmentation, isolation, encryption, key management, token management, secrets management, credential controls, vulnerability management, dependency management, repository controls, API controls, dashboard controls, map controls, logging, monitoring, anomaly detection, incident response, and public-safe cyber disclosure controls.

9.9.8(c) Resilience and continuity methods shall identify critical workloads, critical records, backup requirements, recovery time considerations, recovery point considerations, degraded-mode operation, fallback environments, manual review paths, continuity of access where lawful and safe, continuity of correction, continuity of logs, continuity of public-safe notices, and continuity of interface obligations.

9.9.8(d) Backup methods shall identify backup scope, backup location, encryption status, access controls, retention period, deletion obligations, sealing obligations, legal hold, restore testing, cross-border exposure, provider access, public authority restrictions, protected knowledge restrictions, and correction propagation.

9.9.8(e) Disaster recovery and exit readiness methods shall identify recovery environment, jurisdiction, data transfer controls, provider lock-in risk, export format, portability, key escrow or key recovery where appropriate, credential transition, logging continuity, model portability where applicable, dataset portability where lawful, dashboard and map continuity, API continuity, and public-safe communication plan.

9.9.8(f) Decommissioning methods shall identify workload termination, environment retirement, data return, data deletion, data sealing, backup deletion or retention, key revocation, token revocation, credential revocation, access revocation, log retention, archive treatment, legal hold, public-safe obligations, interface notices, dependency review, and closeout records.

9.9.8(g) Where cybersecurity, resilience, backup, continuity, or decommissioning defects are detected, GCRI Canada shall restrict access, rotate credentials, revoke keys, isolate environments, suspend workloads, restore from clean backup where appropriate, correct records, notify affected interfaces where required, review affected outputs, and update controls.

9.9.8(h) The controlling rule shall be that sovereign compute must remain secure and recoverable throughout its lifecycle, including failure, migration, exit, and decommissioning.

***

9.9.9 Sovereign Compute Outputs as Evidence, Not Authority by Default.\
9.9.9(a) Sovereign compute outputs shall be treated as evidence artifacts, compute records, analysis outputs, dashboard inputs, map inputs, public-safe summaries, controlled annex inputs, Evidence Pack inputs, Decision Pack inputs, Verifiable Compute records, Verifiable Intelligence inputs, Truth Engine inputs, Observatory outputs, GRF inputs, GRA inputs, Protocol Authority inputs, public authority learning materials, or correction records, depending on their recorded output class.

9.9.9(b) Sovereign compute outputs shall not constitute official truth, public authority meaning, public warning, emergency command, regulatory approval, procurement approval, funding approval, public finance approval, finance-readiness, capital-readiness, insurance-readiness, investment advice, rating, guarantee, certification, recognition, maturity record, claims approval, protocol effect, conformance determination, Nexus-compatible status, provider endorsement, sponsor approval, host approval, operator instruction, operational clearance, infrastructure operation, legal status, market authority, deployment approval, or execution consequence by default.

9.9.9(c) The fact that an output was produced in a sovereign compute environment, secure enclave, confidential computing environment, air-gapped environment, public authority environment, National Dense Nexus Core environment, or compute-to-data environment shall not by itself prove accuracy, completeness, public-safe status, legal validity, official status, security guarantee, finance value, certification status, recognition status, provider neutrality, sponsor independence, or fit for purpose.

9.9.9(d) Sovereign compute outputs shall identify source records, data lineage, method records, workload records, environment records, model records where applicable, human review where material, output class, confidence, uncertainty, limitations, public-safe status, permitted use, prohibited use, boundary language, correction path, supersession path, withdrawal path, retraction path where applicable, and dependency links.

9.9.9(e) Where sovereign compute outputs are routed to public authorities, National Dense Nexus Core interfaces, Regional Observatory Cluster interfaces, Hubs, Nodes, Hotspots, GRF, GRA, Protocol Authority, National Nexus Consortiums, National Companies, Project SPVs, providers, sponsors, hosts, operators, universities, communities, Academy materials, media materials, or public audiences, the receiving context shall be recorded and boundary language shall be preserved.

9.9.9(f) Where sovereign compute outputs are overclaimed, misused, misclassified, publicly misread, finance-inflated, authority-inflated, certification-inflated, recognition-inflated, provider-preferential, sponsor-validating, public-safe defective, or correction-defective, GCRI Canada shall correct, relabel, restrict, withdraw, reissue, notify affected interfaces where appropriate, and review dependencies.

9.9.9(g) No ambiguity shall be resolved in favour of sovereign compute authority. Where there is doubt whether a sovereign compute output creates authority or only supports evidence, the interpretation preserving GCRI Canada’s non-execution role, public authority boundaries, finance boundaries, procurement neutrality, provider neutrality, sponsor non-control, operator boundaries, host boundaries, community safeguards, GRF role separation, GRA role separation, Protocol Authority role separation, validity-by-record, correctionability, and public trust shall prevail.

9.9.9(h) The controlling rule shall be that sovereign compute may strengthen trust in processing conditions, but it does not transform compute output into authority.

***

9.9.10 Sovereign Compute Records, Review, Correction, and Cross-Border Controls.\
9.9.10(a) GCRI Canada shall maintain, or cause to be maintained, sovereign compute records for material Observatory compute environments, workloads, interfaces, outputs, access events, logs, incidents, corrections, reviews, assurance activities, cross-border assessments, decommissioning, and closeout.

9.9.10(b) Sovereign compute records shall identify environment title or identifier, workload title or identifier, owner where known, GCRI Canada responsible function where applicable, custodian, steward, provider where any, jurisdiction, location, cloud region where applicable, infrastructure type, data classes, evidence classes, output classes, access class, handling class, public-safe status, privacy status, cybersecurity status, sovereign data status, public authority status, finance-sensitive status, provider-sensitive status, sponsor-sensitive status, operator-sensitive status, host-sensitive status, community-protected status, Indigenous or protected knowledge status, legal sensitivity, export-control sensitivity, sanctions sensitivity, permitted uses, prohibited uses, publication limits, and correction path.

9.9.10(c) Review records shall identify review cycle, reviewers, environment review, workload review, source review, dataset review, model review, code review, access review, log review, key review, provider review, support-access review, cross-border review, public authority data review, sovereign data review, privacy review, cybersecurity review, protected knowledge review, public-safe review, boundary review, incident review, correction review, and assurance review.

9.9.10(d) Cross-border controls shall identify whether data, compute, access, support, backups, logs, outputs, dashboards, maps, APIs, retrieval sources, embedding stores, models, controlled annexes, public-safe summaries, or interface records cross national, provincial, territorial, Indigenous, community, institutional, programmatic, entity, provider, or public authority boundaries.

9.9.10(e) Cross-border assessment shall consider lawful basis, data-sharing terms, privacy obligations, data-subject rights, public authority restrictions, sovereign data requirements, Indigenous or community protocols, protected knowledge restrictions, cybersecurity risk, compelled-access risk, export-control risk, sanctions risk, controlled-technology risk, provider access, sponsor access, support access, public-safe publication risk, and correction obligations.

9.9.10(f) Correction records shall identify corrected environment, corrected workload, corrected location, corrected jurisdiction, corrected provider role, corrected custodian, corrected access record, corrected log, corrected key status, corrected output, corrected public-safe status, corrected boundary language, prior status, corrected status, effective date, reviewer, affected dependencies, notice decision, access change, archive treatment, and continuing limitations.

9.9.10(g) Where sovereign compute records, reviews, or cross-border controls reveal unauthorized transfer, unauthorized access, unapproved support access, unapproved provider access, unapproved model use, unapproved retrieval, unapproved embedding, cross-border defect, public authority data defect, protected knowledge defect, cybersecurity defect, privacy defect, sovereign-data defect, export-control defect, sanctions defect, public-safe defect, or correction defect, GCRI Canada shall restrict, correct, delete, seal, reclassify, suspend, withdraw, notify where required, and review affected outputs and dependencies.

9.9.10(h) Sovereign compute records shall be linked, where applicable, to National Dense Core records, Regional Observatory Cluster records, Cluster records, Hub records, Node records, Hotspot records, Observatory Methods Register entries, Evidence Register entries, Source Comparison Records, Dataset Register entries, Model Register entries, System Card entries, Benchmark Card entries, Compute Workload Records, Compute Environment Records, Inference Records, Human Review Records, Retrieval and Embedding Records, Proof Receipt Records, Public-Safe Output Records, AI Incident Records, Correction Records, Dependency Records, Truth Engine Records, public authority records, GRF interface records, GRA interface records, Protocol Authority interface records, RNFD records, Nexus Risk Management records, Nexus Rails records, Regional Nexus Consortium records, National Nexus Consortium records, National Company records, Project SPV records, operator records, provider records, sponsor records, host records, community records, university records, Nexus interface records, and public claims records.

9.9.10(i) Sovereign compute records, review, correction, cross-border controls, assurance, retirement, archive, and closeout shall not create certification, recognition, finance-readiness, public authority decision, procurement approval, provider endorsement, sponsor approval, host approval, operator approval, rating, guarantee, public warning, emergency command, protocol effect, operational clearance, legal status, market authority, infrastructure operation, deployment approval, national authority, or execution consequence by default.

9.9.10(j) The controlling rule shall be that sovereign compute is trustworthy only when its records show location, jurisdiction, access, provider role, workload scope, output movement, cross-border exposure, correction, and closeout with enough precision to protect sovereignty, rights, security, knowledge, and public trust.

### 9.10 AI-RAN, O-RAN, Private Wireless, and Telecommunications Evidence Methods

9.10.1 AI-RAN Evidence as Observatory Methods Domain.\
9.10.1(a) GCRI Canada shall steward AI-RAN evidence methods as a specialized Observatory methods domain for observing, recording, comparing, interpreting, public-safe summarizing, and correcting evidence arising from AI-enabled radio access networks, AI-assisted telecommunications systems, edge intelligence, radio signal contexts, networked sensing, private wireless systems, O-RAN systems, network telemetry, and telecommunications-adjacent observability contexts.

9.10.1(b) AI-RAN evidence methods may support source comparison, signal interpretation, edge intelligence review, networked sensing interpretation, degraded-mode learning, infrastructure-context learning, cybersecurity evidence, public authority learning, host learning, provider-neutral technical review, sensor integration, DePIN integration, digital twin integration, dashboard interpretation, map interpretation, Truth Engine inputs, Observatory Node records, Hub records, Cluster records, Regional Observatory Cluster records, National Dense Nexus Core records, Evidence Packs, Decision Packs, public-safe outputs, Academy materials, GRF inputs, GRA inputs, Protocol Authority inputs, and correction workflows.

9.10.1(c) AI-RAN evidence methods shall be records-valid, source-lined, compute-aware, model-governed, confidence-aware, uncertainty-aware, limitation-aware, privacy-protective, cybersecurity-controlled, public-safe, sovereign-data-compatible, provider-neutral, sponsor-independent, and correctionable.

9.10.1(d) GCRI Canada’s stewardship of AI-RAN evidence methods shall not make GCRI Canada a telecommunications operator, AI-RAN operator, O-RAN operator, private wireless operator, spectrum regulator, public authority, emergency-management actor, infrastructure operator, network service provider, certification body, procurement actor, finance actor, Protocol Authority, provider, sponsor, host, National Company, Project SPV, or execution actor by default.

9.10.1(e) AI-RAN evidence shall not be treated as authoritative merely because it is machine-generated, real-time, edge-computed, AI-assisted, high-volume, high-resolution, provider-supplied, public authority-relevant, sponsor-supported, dashboard-visible, map-visible, cryptographically logged, or technically sophisticated.

9.10.1(f) AI-RAN evidence methods shall preserve the distinction between network signal, telecommunications telemetry, edge inference, model output, dashboard indicator, map layer, public-safe summary, public authority learning material, provider demonstration, benchmark result, and any authority-bearing decision made by a competent separate actor.

9.10.1(g) Where AI-RAN evidence methods are used externally or publicly, GCRI Canada shall preserve controlled vocabulary, source lineage, confidence, uncertainty, limitations, public-safe status, no-telecommunications-regulation language, no-public-warning language, no-public-authority language, no-finance language, no-procurement language, no-certification language, no-recognition language, no-protocol-effect language unless separately created by Protocol Authority, no-provider-endorsement language, no-sponsor-approval language, no-infrastructure-operation language, and correction path where material.

9.10.1(h) The controlling rule shall be that AI-RAN evidence is a Observatory methods domain for making telecommunications-adjacent signals more intelligible as evidence, not for making GCRI Canada a network operator, regulator, certifier, financier, procurement actor, warning issuer, or execution authority.

***

9.10.2 O-RAN and Private Wireless Evidence Methods.\
9.10.2(a) GCRI Canada shall steward O-RAN and private wireless evidence methods for observing, recording, comparing, interpreting, public-safe summarizing, and correcting evidence arising from open radio access network components, private wireless networks, enterprise wireless systems, campus networks, community networks, industrial wireless systems, edge-connected systems, networked sensor systems, and telecommunications-adjacent infrastructure.

9.10.2(b) O-RAN evidence methods shall identify, where safe and material, component class, interface class, architecture context, vendor or provider role where any, operator role where any, host context, public authority context, data source, telemetry source, configuration context, timing context, location or safe-location treatment, signal quality, interoperability context, cybersecurity context, public-safe status, confidence, uncertainty, limitations, and correction path.

9.10.2(c) Private wireless evidence methods shall identify, where safe and material, network purpose, host context, facility context, coverage context, device or endpoint context, sensor relationship, edge compute relationship, operator context, provider context, public authority relevance, cybersecurity sensitivity, location sensitivity, metadata sensitivity, data class, evidence class, access class, handling class, public-safe status, confidence, uncertainty, limitations, and correction path.

9.10.2(d) O-RAN and private wireless evidence may include telemetry, logs, configuration records, network performance records, radio signal records, timing records, location records, interference records, outage records, degraded-mode records, sensor records, edge compute records, AI model outputs, cybersecurity records, field observations, host observations, provider materials, public authority context, and public-safe summaries.

9.10.2(e) O-RAN and private wireless methods shall distinguish technical observability from network operation. Evidence concerning network condition, signal quality, interoperability, degradation, anomaly, cyber risk, coverage, or continuity shall not be treated as a command to operate, repair, modify, deploy, procure, approve, certify, regulate, finance, or warn by GCRI Canada.

9.10.2(f) O-RAN and private wireless evidence shall not be treated as procurement-ready, certification-ready, protocol-effective, finance-ready, public authority-approved, provider-endorsed, sponsor-approved, operationally cleared, or execution-ready merely because it is produced in a structured Observatory method or connected to a Nexus interface.

9.10.2(g) Where O-RAN or private wireless evidence is corrected, disputed, restricted, superseded, withdrawn, reclassified, or made stale by later evidence, GCRI Canada shall update affected records, dashboards, maps, Evidence Packs, Decision Packs, public-safe outputs, interface records, and dependencies.

9.10.2(h) The controlling rule shall be that O-RAN and private wireless evidence methods support technical learning and observability without turning telecommunications evidence into telecommunications authority, procurement consequence, certification, finance, or execution.

***

9.10.3 Network Signal, Radio Signal, Telemetry, Spectrum-Adjacent, Edge Intelligence, and Networked Sensing Methods.\
9.10.3(a) GCRI Canada shall steward methods for network signal, radio signal, telemetry, spectrum-adjacent, edge intelligence, and networked sensing evidence within AI-RAN, O-RAN, private wireless, and telecommunications-adjacent Observatory contexts.

9.10.3(b) Network signal and radio signal methods shall identify source class, signal class, collection method, timestamp, timing source, location or safe-location treatment, frequency or spectrum-adjacent context where safe and lawful to record, sampling method, measurement context, network context, device or endpoint context where safe and material, host context, operator context, provider context, public authority context, data quality, noise, interference, spoof risk, degradation, outage, confidence, uncertainty, limitations, and correction path.

9.10.3(c) Telemetry methods shall identify telemetry source, system context, log context, telemetry type, custody, permission, retention status, access class, handling class, privacy sensitivity, cybersecurity sensitivity, infrastructure sensitivity, provider sensitivity, public authority sensitivity, public-safe status, confidence, uncertainty, limitations, and correction path.

9.10.3(d) Spectrum-adjacent methods shall be used only for evidence, observability, public-safe learning, and technical interpretation within lawful and authorized boundaries. GCRI Canada shall not use spectrum-adjacent methods to allocate spectrum, regulate spectrum, enforce spectrum rights, approve radio operation, issue interference orders, or create public authority meaning.

9.10.3(e) Edge intelligence methods shall identify edge model, model version, inference context, compute environment, data inputs, output class, latency constraints, local processing context, human review where material, confidence, uncertainty, limitations, public-safe status, and correction path.

9.10.3(f) Networked sensing methods shall identify sensor relationship, network relationship, signal dependency, data dependency, calibration relationship, time synchronization, location treatment, source independence, data fusion method, public-safe status, confidence, uncertainty, limitations, and correction path.

9.10.3(g) Network signal, radio signal, telemetry, spectrum-adjacent, edge intelligence, and networked sensing outputs shall not be used as public warnings, emergency commands, spectrum determinations, regulatory determinations, procurement approvals, finance-readiness signals, certifications, recognitions, provider rankings, sponsor approvals, protocol effects, operational clearances, infrastructure commands, or execution instructions by default.

9.10.3(h) The controlling rule shall be that telecommunications-adjacent signals become institutional evidence only through lawful source treatment, context, calibration, timing, location controls, confidence, uncertainty, public-safe review, and correction path.

***

9.10.4 Signal Quality, Calibration, Timing, Location, Noise, Interference, Spoofing, and Confidence Methods.\
9.10.4(a) GCRI Canada shall steward signal quality, calibration, timing, location, noise, interference, spoofing, tamper, anomaly, degradation, outage, and confidence methods for AI-RAN, O-RAN, private wireless, and telecommunications-adjacent evidence.

9.10.4(b) Signal quality methods shall identify signal source, collection method, measurement conditions, signal strength where appropriate, stability, completeness, missing data, sampling limits, instrument limits, device limits, network context, environmental context, data quality, processing method, and correction path.

9.10.4(c) Calibration methods shall identify calibration status, calibration source, calibration method, calibration date, reference source, calibration authority where any, instrument or system configuration, maintenance status, drift risk, dependency on provider configuration, dependency on host conditions, and correction path.

9.10.4(d) Timing methods shall identify timestamp source, time synchronization method, clock drift risk, latency, update cadence, stale-data status, sequence ordering, replay risk, delayed telemetry risk, missing intervals, and correction path.

9.10.4(e) Location methods shall identify location source, geospatial precision, safe-location treatment, location uncertainty, small-site identifiability, infrastructure sensitivity, community sensitivity, public authority sensitivity, host sensitivity, and public-safe treatment.

9.10.4(f) Noise and interference methods shall identify background noise, environmental interference, network interference, spectrum-adjacent interference, equipment interference, weather or physical context where material, cyber interference, provider configuration effects, host conditions, uncertainty effect, limitation effect, and correction path.

9.10.4(g) Spoofing, tamper, anomaly, and adversarial signal methods shall identify possible spoofing, tampering, replay, synthetic signal, adversarial manipulation, compromised telemetry, unauthorized access, configuration manipulation, sensor compromise, model manipulation, prompt injection where applicable, cyber compromise, and confidence downgrade requirements.

9.10.4(h) Confidence methods shall pair confidence with uncertainty and limitations and shall consider source quality, calibration, timing integrity, location integrity, signal quality, interference, spoof risk, data completeness, source independence, corroboration, provider influence, sponsor influence, public authority context, host context, model use, compute integrity, and correction status.

9.10.4(i) Signal confidence, calibration status, timing integrity, location integrity, or interference analysis shall not constitute network certification, equipment certification, spectrum compliance, public authority approval, procurement approval, provider endorsement, finance-readiness, public warning, emergency command, operational clearance, or execution instruction by default.

9.10.4(j) The controlling rule shall be that signal evidence is trustworthy only when quality, calibration, timing, location, noise, interference, spoofing, confidence, uncertainty, and correction are treated as governed evidence attributes rather than hidden assumptions.

***

9.10.5 AI-RAN Data Privacy, Metadata, Location Sensitivity, Public Authority Sensitivity, and Critical Infrastructure Sensitivity.\
9.10.5(a) GCRI Canada shall apply heightened privacy, metadata, location-sensitivity, public authority, critical infrastructure, cybersecurity, sovereign data, host, community, provider, sponsor, and public-safe controls to AI-RAN, O-RAN, private wireless, and telecommunications-adjacent evidence.

9.10.5(b) Privacy methods shall identify whether network evidence includes or may infer personal information, rights-bearing data, device identifiers, subscriber-related information, user behavior, movement patterns, household or small-group identifiability, workplace identifiability, health-adjacent patterns, vulnerable-person exposure, or other privacy-sensitive inferences.

9.10.5(c) Metadata methods shall treat metadata as potentially sensitive evidence. Metadata may include timestamps, device relationships, network relationships, location patterns, access patterns, service patterns, telemetry context, operator context, provider context, host context, public authority context, and system dependency context.

9.10.5(d) Location sensitivity methods shall identify precise-location risk, sensitive-site exposure, critical-infrastructure exposure, community identifiability, protected knowledge exposure, host sensitivity, operator sensitivity, public authority sensitivity, and safe-location treatment.

9.10.5(e) Public authority sensitivity methods shall identify whether network evidence arises from, relates to, is requested by, is received from, is reviewed by, or may be used by a public authority, and shall preserve capacity classification, official or non-official status, data-sharing terms, agency reference controls, non-delegation language, non-endorsement language, non-regulatory language, non-procurement language, non-funding language, no-public-warning language, and correction path.

9.10.5(f) Critical infrastructure sensitivity methods shall identify infrastructure-sensitive information, topology sensitivity, dependency sensitivity, outage sensitivity, degraded-mode sensitivity, vulnerability sensitivity, cyber-sensitive information, physical security risk, operational risk, and public-safe disclosure limits.

9.10.5(g) AI-RAN and telecommunications-adjacent evidence shall not be published, dashboarded, mapped, API-exposed, shared with providers, shared with sponsors, routed to finance-facing contexts, routed to public authority contexts, embedded, retrieved, trained on, or summarized externally without review proportionate to privacy, metadata, location, public authority, critical infrastructure, cybersecurity, sovereign data, and public-safe risks.

9.10.5(h) Where privacy, metadata, location, public authority, or critical infrastructure sensitivity controls fail, GCRI Canada shall restrict access, correct classification, halt routing, remove unsafe fields, apply safe-location treatment, withdraw or revise outputs, notify affected interfaces where required, and review dependencies.

9.10.5(i) The controlling rule shall be that AI-RAN evidence may reveal people, places, systems, authority relationships, and infrastructure dependencies even when it appears technical; therefore its privacy, metadata, location, public authority, and infrastructure sensitivity must be governed before use.

***

9.10.6 AI-RAN Cybersecurity and Network Security Evidence Methods.\
9.10.6(a) GCRI Canada shall steward AI-RAN, O-RAN, private wireless, and telecommunications-adjacent cybersecurity and network security evidence methods for identifying, classifying, comparing, public-safe summarizing, and correcting evidence concerning network security conditions, vulnerabilities, anomalies, incidents, degraded modes, access controls, telemetry integrity, and cyber-physical dependencies.

9.10.6(b) Cybersecurity evidence methods shall identify cyber-sensitive data, infrastructure-sensitive data, network telemetry, log sources, access-control records, identity records, key or credential records where safe, vulnerability-sensitive information, exploit-sensitive information, incident-adjacent information, configuration-sensitive information, dependency-sensitive information, public-safe status, access class, handling class, confidence, uncertainty, limitations, and correction path.

9.10.6(c) Network security evidence may include authentication logs, authorization logs, configuration records, anomaly records, traffic metadata where lawful and appropriate, telemetry integrity records, device integrity records, firmware or software version records, patch status records, vulnerability records, incident records, provider security materials, operator security context, host security context, public authority context, and public-safe summaries.

9.10.6(d) AI-RAN cybersecurity methods shall address risks of unauthorized access, credential compromise, key compromise, token compromise, secrets exposure, radio signal spoofing, telemetry tampering, configuration manipulation, adversarial model input, model drift, prompt injection where applicable, tool misuse, API misuse, dashboard manipulation, map manipulation, data exfiltration, malware, denial of service, supply-chain compromise, cross-tenant access, cross-program access, cross-entity access, cross-border access, and side-channel leakage.

9.10.6(e) Public-safe cyber disclosure shall not reveal exploit details, credentials, keys, tokens, secrets, security controls, infrastructure topology, sensitive configurations, active vulnerabilities, incident details, degraded-mode vulnerabilities, or sensitive telemetry in a manner that increases harm.

9.10.6(f) Cybersecurity or network security evidence shall not be represented as security certification, compliance determination, public authority approval, procurement approval, provider endorsement, operational clearance, guarantee, insurance-readiness, finance-readiness, public warning, emergency command, protocol effect, or execution readiness by default.

9.10.6(g) Where AI-RAN cybersecurity or network security incidents or defects are detected, GCRI Canada shall preserve logs where safe, restrict access, rotate credentials where needed, revoke keys where needed, disable affected interfaces where appropriate, assess exposure, correct records, notify affected interfaces where required, and review affected outputs and dependencies.

9.10.6(h) The controlling rule shall be that telecommunications observability must not expose, weaken, or overstate the security of the networks and systems it seeks to understand.

***

9.10.7 AI-RAN Integration With Sensors, DePIN, Digital Twins, Dashboards, Truth Engine, and Observatory Nodes.\
9.10.7(a) GCRI Canada may steward AI-RAN integration methods with sensors, reference sensors, DePIN telemetry, cyber records, geospatial systems, Earth observation inputs, satellite inputs, digital twins, simulations, dashboards, maps, APIs, Nexus Truth Engine, Observatory Nodes, Hubs, Clusters, Hotspots, Regional Observatory Clusters, National Dense Nexus Cores, Verifiable Compute records, Verifiable Intelligence outputs, Evidence Packs, Decision Packs, public-safe outputs, and correction records.

9.10.7(b) Integration methods shall identify integration purpose, source systems, receiving systems, data classes, evidence classes, output classes, source lineage, data lineage, method version, model version where applicable, compute workload, compute environment, access class, handling class, public-safe status, confidence, uncertainty, limitations, permitted flows, prohibited flows, permitted uses, prohibited uses, and correction path.

9.10.7(c) Integration with sensors shall identify calibration relationships, timing relationships, location treatment, signal dependency, sensor dependency, source independence, data fusion method, failure modes, and correction propagation.

9.10.7(d) Integration with DePIN shall identify telemetry source, node or contributor context where safe, validator context where material, incentive risk, tamper risk, custody, data quality, provider or sponsor influence risk, public-safe status, and correction path.

9.10.7(e) Integration with digital twins and simulations shall identify scenario, assumptions, model version, input data, calibration status, validation status, sensitivity analysis where material, uncertainty propagation, limitation treatment, public-safe status, and prohibition on presenting modeled or simulated telecommunications outputs as observed fact.

9.10.7(f) Integration with dashboards, maps, and APIs shall identify field meaning, schema meaning, update cadence, stale-data treatment, confidence display, uncertainty display, limitation display, geospatial precision, export controls, API exposure, downstream reuse limits, public-safe status, and correction propagation.

9.10.7(g) Integration with Nexus Truth Engine and Observatory Nodes shall preserve source comparison records, corroboration records, contradiction records, confidence records, uncertainty records, inference records where applicable, human review records where material, public-safe review records, dependency links, and correction paths.

9.10.7(h) AI-RAN integration shall not create legal merger, system merger, operator control, public authority status, public warning, emergency command, procurement approval, finance-readiness, certification, recognition, protocol effect, provider preference, sponsor approval, host approval, operational clearance, infrastructure operation, or execution consequence by default.

9.10.7(i) Where integration defects are identified, including schema mismatch, timestamp mismatch, location mismatch, calibration mismatch, telemetry mismatch, sensor mismatch, model mismatch, confidence mismatch, public-safe mismatch, permission mismatch, cybersecurity defect, privacy defect, sovereign-data defect, protected-knowledge defect, or correction mismatch, GCRI Canada shall record the mismatch and correct, qualify, restrict, re-map, reclassify, supersede, or refuse the affected integration path as appropriate.

9.10.7(j) The controlling rule shall be that AI-RAN integration can enrich Observatory evidence only where integration preserves source meaning, safeguards, boundaries, and correctionability.

***

9.10.8 AI-RAN Provider and Equipment Contribution Without Provider Preference.\
9.10.8(a) GCRI Canada may receive, review, test, reference, or use AI-RAN, O-RAN, private wireless, telecommunications, sensor, compute, dashboard, map, API, cybersecurity, edge intelligence, DePIN, digital twin, or integration materials supplied by providers, operators, hosts, universities, public authorities, or other contributors, provided that such contribution remains evidence-supporting, provider-neutral, public-safe where externally released, records-valid, and correctionable.

9.10.8(b) Provider and equipment contribution records shall identify provider identity, provider role, equipment or system identity, configuration, software or firmware version where material, model version where applicable, dataset relationship where any, compute environment relationship where any, integration context, test conditions, benchmark conditions, validation conditions, operator context where any, host context where any, public authority context where any, commercial sensitivity, IP sensitivity, cybersecurity sensitivity, export-control sensitivity, sanctions sensitivity, conflict status, influence controls, permitted claims, prohibited claims, publication limits, and correction path.

9.10.8(c) Provider-supplied AI-RAN or telecommunications materials shall not be treated as neutral, valid, complete, independent, public-safe, benchmark-ready, procurement-ready, finance-ready, certified, recognized, protocol-effective, Nexus-compatible, operationally cleared, or execution-ready merely because supplied by a reputable provider, widely adopted provider, technically advanced provider, public authority-used provider, sponsor-supported provider, host-preferred provider, or Nexus-participating provider.

9.10.8(d) Provider demonstrations, validation sprints, benchmarks, integrations, dashboards, maps, AI outputs, signal outputs, sensor outputs, compute outputs, cyber outputs, or technical notes shall identify provider role, provider-supplied configuration, provider-supplied data, provider-supplied environment, limitations, conflicts, influence controls, confidence, uncertainty, public-safe status, permitted claims, prohibited claims, and correction path.

9.10.8(e) GCRI Canada shall not use provider or equipment contributions to endorse providers, rank providers for procurement, award vendor status, create public tender advantage, imply preferred-provider status, validate provider marketing claims, certify provider technology, create Nexus-compatible status, create Protocol Authority effect, create finance-readiness, create operational clearance, or create execution readiness by default.

9.10.8(f) Provider access to AI-RAN evidence records, controlled rooms, data rooms, clean rooms, compute environments, retrieval sources, embedding stores, dashboards, maps, APIs, repositories, public-good software, technical baselines, Node records, Hub records, Cluster records, Regional Cluster records, or National Dense Core records shall be role-based, purpose-bound, least-privilege, logged, time-bound where appropriate, revocable, and subject to confidentiality, cybersecurity, privacy, sovereign data, protected knowledge, public-safe, provider-neutrality, and boundary controls.

9.10.8(g) Where provider contribution creates provider preference, procurement implication, public authority implication, finance implication, sponsor validation, data leakage, IP dispute, cyber risk, benchmark overclaim, public-safe defect, or correction failure, GCRI Canada shall restrict access, hold outputs, correct records, revise public-safe materials, suspend the interface, require remedial action, or pursue contractual or legal remedies where appropriate.

9.10.8(h) The controlling rule shall be that providers and equipment may contribute to AI-RAN evidence, but contribution shall not become endorsement, procurement advantage, certification, recognition, finance-readiness, protocol effect, operational clearance, or execution authority.

***

9.10.9 AI-RAN Outputs as Evidence, Not Telecommunications Regulation, Public Warning, Procurement Approval, Certification, or Infrastructure Operation by GCRI Canada.\
9.10.9(a) AI-RAN, O-RAN, private wireless, and telecommunications-adjacent outputs stewarded, produced, received, reviewed, dashboarded, mapped, summarized, routed, or corrected by GCRI Canada shall be treated as evidence artifacts, observability records, signal records, telemetry records, compute outputs, model outputs, dashboard inputs, map inputs, public-safe summaries, controlled annex inputs, Evidence Pack inputs, Decision Pack inputs, Verifiable Compute records, Verifiable Intelligence inputs, Truth Engine inputs, Observatory outputs, GRF inputs, GRA inputs, Protocol Authority inputs, public authority learning materials, provider-neutral review materials, Academy materials, or correction records, depending on their recorded output class.

9.10.9(b) AI-RAN outputs shall not constitute telecommunications regulation, spectrum regulation, network authorization, radio authorization, equipment authorization, public warning, emergency command, public authority decision, regulatory approval, procurement approval, vendor selection, funding approval, public finance approval, finance-readiness, capital-readiness, insurance-readiness, investment advice, rating, guarantee, certification, recognition, maturity record, claims approval, protocol effect, conformance determination, Nexus-compatible status, provider endorsement, sponsor approval, host approval, operator instruction, operational clearance, infrastructure operation, legal status, market authority, deployment approval, or execution consequence by default.

9.10.9(c) The fact that an AI-RAN output is real-time, edge-computed, AI-generated, telecommunications-adjacent, public authority-relevant, dashboard-visible, map-visible, provider-supplied, sponsor-supported, host-related, operator-related, calibrated, logged, signed, hashed, timestamped, or supported by a Proof Receipt shall not by itself create authority, approval, certification, finance value, procurement value, warning status, operational value, or execution consequence.

9.10.9(d) AI-RAN outputs shall identify source records, data lineage, signal context, method records, calibration records where applicable, timing records where applicable, location treatment, workload records where applicable, environment records where applicable, model records where applicable, human review where material, output class, confidence, uncertainty, limitations, public-safe status, permitted use, prohibited use, boundary language, correction path, supersession path, withdrawal path, retraction path where applicable, and dependency links.

9.10.9(e) Where AI-RAN outputs are routed to public authorities, National Dense Nexus Core interfaces, Regional Observatory Cluster interfaces, Hubs, Nodes, Hotspots, GRF, GRA, Protocol Authority, National Nexus Consortiums, National Companies, Project SPVs, providers, sponsors, hosts, operators, universities, communities, Academy materials, media materials, or public audiences, the receiving context shall be recorded and boundary language shall be preserved.

9.10.9(f) Where AI-RAN outputs are overclaimed, misused, misclassified, publicly misread, finance-inflated, procurement-inflated, authority-inflated, certification-inflated, recognition-inflated, provider-preferential, sponsor-validating, public-warning-adjacent, public-safe defective, or correction-defective, GCRI Canada shall correct, relabel, restrict, withdraw, reissue, notify affected interfaces where appropriate, and review dependencies.

9.10.9(g) No ambiguity shall be resolved in favour of AI-RAN output authority. Where there is doubt whether an AI-RAN output creates authority or only supports evidence, the interpretation preserving GCRI Canada’s non-execution role, telecommunications-regulatory boundaries, public authority boundaries, finance boundaries, procurement neutrality, provider neutrality, sponsor non-control, operator boundaries, host boundaries, community safeguards, GRF role separation, GRA role separation, Protocol Authority role separation, validity-by-record, correctionability, and public trust shall prevail.

9.10.9(h) The controlling rule shall be that AI-RAN outputs may make telecommunications-adjacent systems more observable, but they do not make GCRI Canada a regulator, warning issuer, procurement approver, certifier, infrastructure operator, or execution actor.

***

9.10.10 AI-RAN Evidence Records, Calibration Records, Incident Records, Public-Safe Records, and Correction.\
9.10.10(a) GCRI Canada shall maintain, or cause to be maintained, AI-RAN, O-RAN, private wireless, and telecommunications-adjacent evidence records for material methods, sources, signals, telemetry, compute workloads, models, sensors, dashboards, maps, APIs, Evidence Packs, Decision Packs, public-safe outputs, incidents, corrections, dependencies, assurance reviews, and closeout events.

9.10.10(b) AI-RAN evidence records shall identify record title or identifier, source system, source class, signal class, telemetry class, provider where any, operator where any, host where any, public authority context where any, community context where any, technology domain, risk domain, data class, evidence class, output class, access class, handling class, public-safe status, privacy status, cybersecurity status, sovereign data status, infrastructure-sensitive status, public authority status, finance-sensitive status, provider-sensitive status, sponsor-sensitive status, operator-sensitive status, host-sensitive status, community-protected status, Indigenous or protected knowledge status, legal sensitivity, export-control sensitivity, sanctions sensitivity, permitted uses, prohibited uses, publication limits, and correction path.

9.10.10(c) Calibration and signal-integrity records shall identify sensor or signal source where safe, calibration status, calibration method, calibration date, reference source, timing source, time synchronization, clock drift risk, location or safe-location treatment, signal quality, noise, interference, spoof risk, tamper risk, outage status, degraded-mode status, maintenance status, configuration status, provider configuration where material, host condition where material, confidence effect, uncertainty effect, limitation effect, and correction path.

9.10.10(d) Incident records shall identify cybersecurity incident, network security incident, telemetry incident, signal spoofing incident, sensor failure, calibration failure, timing defect, location defect, interference event, data leakage, unauthorized access, unauthorized retrieval, unauthorized embedding, model incident, dashboard error, map error, API error, public-safe defect, public authority overclaim, finance overclaim, procurement implication, provider preference, sponsor validation, operator-control implication, host approval implication, protected knowledge exposure, privacy incident, sovereign data issue, export-control issue, sanctions issue, or correction failure affecting AI-RAN evidence.

9.10.10(e) Public-safe records shall identify public-safe review, restricted fields, redactions, aggregations, generalizations, safe-location treatment, responsible non-disclosure basis, boundary language, permitted use, prohibited use, confidence, uncertainty, limitations, stale-data treatment, correction status, supersession status, withdrawal status where applicable, retraction status where applicable, affected audiences, and dependency links.

9.10.10(f) Correction records shall identify corrected source, corrected signal, corrected telemetry, corrected calibration status, corrected timing status, corrected location treatment, corrected noise or interference treatment, corrected spoof-risk treatment, corrected dataset, corrected method, corrected compute workload, corrected model, corrected dashboard, corrected map, corrected API, corrected public-safe output, corrected public authority reference, corrected provider reference, corrected sponsor reference, corrected host reference, corrected operator reference, corrected community reference, prior status, corrected status, effective date, reviewer, affected dependencies, notice decision, access change, archive treatment, and continuing limitations.

9.10.10(g) AI-RAN supersession, withdrawal, or retraction records shall be used where telecommunications-adjacent evidence or outputs should no longer be used or relied upon because of material error, unsafe disclosure, calibration defect, signal defect, spoofing defect, timing defect, location defect, cybersecurity defect, public-safe defect, public authority confusion, finance overclaim, procurement implication, provider-preferential framing, sponsor-validation framing, operator-control implication, host approval implication, protected knowledge exposure, privacy defect, sovereign data issue, cross-border defect, infrastructure-risk exposure, or correction failure.

9.10.10(h) AI-RAN evidence records shall be linked, where applicable, to National Dense Core records, Regional Observatory Cluster records, Cluster records, Hub records, Node records, Hotspot records, Observatory Methods Register entries, Evidence Register entries, Source Comparison Records, Dataset Register entries, Model Register entries, System Card entries, Benchmark Card entries, Compute Workload Records, Compute Environment Records, Inference Records, Human Review Records, Retrieval and Embedding Records, Proof Receipt Records, Public-Safe Output Records, AI Incident Records, Correction Records, Dependency Records, Truth Engine Records, public authority records, GRF interface records, GRA interface records, Protocol Authority interface records, RNFD records, Nexus Risk Management records, Nexus Rails records, Regional Nexus Consortium records, National Nexus Consortium records, National Company records, Project SPV records, operator records, provider records, sponsor records, host records, community records, university records, Nexus interface records, and public claims records.

9.10.10(i) AI-RAN evidence records, calibration records, incident records, public-safe records, correction, supersession, withdrawal, retraction, assurance, retirement, archive, and closeout shall not create certification, recognition, finance-readiness, public authority decision, procurement approval, provider endorsement, sponsor approval, host approval, operator approval, rating, guarantee, public warning, emergency command, telecommunications regulation, spectrum regulation, protocol effect, operational clearance, legal status, market authority, infrastructure operation, deployment approval, national authority, or execution consequence by default.

9.10.10(j) The controlling rule shall be that AI-RAN evidence is trustworthy only when its signal, calibration, timing, location, cybersecurity, public-safe treatment, provider role, authority boundaries, incidents, corrections, and dependencies remain recorded with enough precision to protect systems, people, public authorities, markets, communities, and public trust.

### 9.11 DePIN and Distributed Infrastructure Evidence Methods

9.11.1 DePIN as Distributed Evidence, Device, Network, and Proof Infrastructure Domain.\
9.11.1(a) GCRI Canada shall steward DePIN and distributed infrastructure evidence methods as a specialized Observatory methods domain for observing, recording, comparing, interpreting, public-safe summarizing, and correcting evidence arising from distributed physical infrastructure networks, distributed devices, networked contributors, edge systems, validator or attestation systems, device telemetry, location claims, uptime claims, capacity claims, coverage claims, service claims, proof mechanisms, blockchain or distributed ledger records, and related public-good observability contexts.

9.11.1(b) DePIN evidence methods may support source comparison, device evidence interpretation, distributed network evidence interpretation, proof-method review, tamper-resistance review, spoof-risk review, fraud-risk review, public-safe claim discipline, node records, hub records, cluster records, hotspot records, Regional Observatory Cluster records, National Dense Nexus Core records, Nexus Truth Engine inputs, Verifiable Compute records, Verifiable Intelligence outputs, Protocol Authority inputs, GRF inputs, GRA inputs, public authority learning, provider-neutral technical review, host learning, community learning, Academy materials, and correction workflows.

9.11.1(c) DePIN and distributed infrastructure evidence shall be treated as evidence-supporting and methods-supporting only. It shall not be treated as recognition, certification, finance-readiness, market entitlement, public authority meaning, procurement approval, provider preference, sponsor approval, host approval, protocol effect, infrastructure operation, operational clearance, legal status, public warning, emergency command, or execution consequence by default.

9.11.1(d) DePIN evidence methods shall be records-valid, source-lined, device-aware, network-aware, proof-aware, compute-aware, model-governed where applicable, confidence-aware, uncertainty-aware, limitation-aware, privacy-protective, cybersecurity-controlled, public-safe, sovereignty-compatible, community-sensitive, provider-neutral, sponsor-independent, and correctionable.

9.11.1(e) GCRI Canada’s stewardship of DePIN evidence methods shall not make GCRI Canada a DePIN operator, validator, token issuer, network operator, infrastructure operator, telecommunications operator, marketplace operator, public authority, finance actor, procurement actor, certification body, recognition body, Protocol Authority, provider, sponsor, host, National Company, Project SPV, or execution actor by default.

9.11.1(f) DePIN evidence shall not be treated as valid, neutral, complete, public-safe, authority-bearing, finance-relevant, procurement-relevant, certified, recognized, protocol-effective, or market-entitling merely because it is distributed, cryptographically referenced, blockchain-anchored, token-incentivized, machine-generated, real-time, high-volume, provider-supported, sponsor-supported, public authority-relevant, dashboard-visible, map-visible, or technically sophisticated.

9.11.1(g) Where DePIN methods are used externally or publicly, GCRI Canada shall preserve controlled vocabulary, source lineage, device status, network status, proof status, confidence, uncertainty, limitations, public-safe status, no-token-as-authority language, no-public-authority language, no-finance language, no-procurement language, no-certification language, no-recognition language, no-protocol-effect language unless separately created by Protocol Authority, no-provider-endorsement language, no-sponsor-approval language, no-market-entitlement language, no-infrastructure-operation language, and correction path where material.

9.11.1(h) The controlling rule shall be that DePIN and distributed infrastructure methods may make distributed systems more observable as evidence, but they shall not make GCRI Canada the operator, market maker, validator, regulator, certifier, financier, recognition body, warning issuer, or execution authority for those systems.

***

9.11.2 Device Identity, Hardware Identity, Location Claims, Uptime Claims, Capacity Claims, Coverage Claims, and Service Claims.\
9.11.2(a) GCRI Canada shall steward methods for assessing and recording DePIN device identity, hardware identity, location claims, uptime claims, capacity claims, coverage claims, service claims, contributor claims, validator claims, node claims, gateway claims, sensor claims, edge compute claims, and other distributed infrastructure claims used in Observatory evidence.

9.11.2(b) Device identity methods shall identify, where lawful and safe, device identifier, device class, device role, owner where known, custodian, steward, contributor context, network role, firmware or software version where material, hardware status, configuration status, activation status, registration status, custody status, public-safe status, access class, handling class, and correction path.

9.11.2(c) Hardware identity methods shall identify hardware class, manufacturer or provider where material, model, serial or equivalent identifier where lawful and safe, secure element status where any, attestation status where any, tamper-evidence where any, configuration, maintenance status, supply-chain sensitivity, security sensitivity, export-control sensitivity, sanctions sensitivity, and correction path.

9.11.2(d) Location claim methods shall identify claimed location, observed location where lawful and safe, location source, location precision, safe-location treatment, timestamp, location confidence, location uncertainty, spoof risk, relay risk, relocation risk, community sensitivity, infrastructure sensitivity, host sensitivity, public authority sensitivity, and public-safe publication limits.

9.11.2(e) Uptime, availability, and continuity claim methods shall identify measurement period, measurement source, network context, heartbeat method, telemetry source, outage records, stale-data treatment, downtime treatment, maintenance windows, degraded-mode status, confidence, uncertainty, limitations, and correction path.

9.11.2(f) Capacity and coverage claim methods shall identify claimed capacity, observed capacity where any, measurement method, load conditions, geographic or safe-location scope, network conditions, device density, coverage assumptions, environmental conditions, interference, source independence, provider role, sponsor role, confidence, uncertainty, limitations, and correction path.

9.11.2(g) Service claim methods shall identify the claimed service, evidence basis, performance context, uptime context, coverage context, capacity context, user or host context where safe, provider context, public authority context where any, public-safe status, permitted use, prohibited use, confidence, uncertainty, limitations, and correction path.

9.11.2(h) Device, hardware, location, uptime, capacity, coverage, and service claims shall not be treated as verified, certified, recognized, finance-ready, procurement-ready, public authority-approved, provider-endorsed, sponsor-approved, protocol-effective, market-entitling, operationally cleared, or execution-ready by default.

9.11.2(i) Where such claims are inaccurate, stale, spoofed, tampered, incomplete, contested, misleading, overclaimed, public-safe defective, provider-influenced, sponsor-influenced, market-inflating, or correction-defective, GCRI Canada shall qualify, downgrade, restrict, correct, supersede, withdraw, retract where appropriate, archive, or route the claim for review.

9.11.2(j) The controlling rule shall be that distributed infrastructure claims are evidence propositions requiring source, device, proof, context, confidence, uncertainty, public-safe, and correction controls, not self-executing truth.

***

9.11.3 Proof-of-Competence, Proof-of-Coverage, Proof-of-Availability, Proof-of-Integrity, Proof-of-Observation, and Mission-Specific Proof Methods.\
9.11.3(a) GCRI Canada may steward methods for interpreting proof-of-competence, proof-of-coverage, proof-of-availability, proof-of-integrity, proof-of-observation, proof-of-location, proof-of-service, proof-of-capacity, proof-of-contribution, proof-of-custody, proof-of-compute, proof-of-sensing, proof-of-calibration, proof-of-resilience, proof-of-continuity, and mission-specific proof methods used in DePIN or distributed infrastructure contexts.

9.11.3(b) Proof methods shall identify proof purpose, proof event, proof source, proof issuer where any, claimant, device or node relationship, network relationship, evidence basis, measurement basis, challenge basis where any, verification method where any, attestation method where any, cryptographic reference where any, blockchain or DLT anchoring where any, timestamp, scope, limitations, public-safe status, permitted use, prohibited use, and correction path.

9.11.3(c) Proof-of-competence methods shall identify the competence claimed, test or evidence basis, evaluator where any, benchmark conditions, field conditions, scope limits, model or device context, provider role, sponsor role, confidence, uncertainty, limitations, and prohibited claims, including no certification, no procurement preference, no finance-readiness, no provider ranking, no public authority approval, and no execution readiness by default.

9.11.3(d) Proof-of-coverage methods shall identify coverage claim, source records, signal records, location treatment, time window, measurement conditions, device density, reference checks where any, spoof risk, relay risk, missing data, public-safe mapping limits, confidence, uncertainty, limitations, and correction path.

9.11.3(e) Proof-of-availability methods shall identify availability claim, uptime evidence, heartbeat evidence, outage evidence, maintenance context, telemetry integrity, continuity status, degraded-mode status, time period, confidence, uncertainty, limitations, and correction path.

9.11.3(f) Proof-of-integrity methods shall identify integrity claim, tamper-evidence, signature status, hash status, attestation status, device integrity, data integrity, log integrity, custody, configuration status, incident history, confidence, uncertainty, limitations, and correction path.

9.11.3(g) Proof-of-observation methods shall identify observed event, observation source, observation method, sensor or device relationship, location or safe-location treatment, timestamp, field context, source independence, corroboration status, contradiction status, public-safe status, confidence, uncertainty, limitations, and correction path.

9.11.3(h) Mission-specific proof methods shall identify the mission context, mission evidence requirements, applicable safeguards, public authority relevance, community relevance, protected knowledge relevance, provider relevance, sponsor relevance, finance relevance where any, public-safe release limits, confidence, uncertainty, limitations, and correction path.

9.11.3(i) Proof methods shall not be treated as authority merely because they use tokens, validators, cryptographic signatures, hashes, timestamps, blockchain anchoring, challenge-response protocols, zero-knowledge-style attestations, secure hardware, provider systems, sponsor-funded networks, or public dashboards.

9.11.3(j) The controlling rule shall be that proof methods may strengthen evidence when their scope and limits are recorded, but no proof becomes certification, recognition, finance-readiness, public authority meaning, procurement approval, market entitlement, protocol effect, or execution consequence by default.

***

9.11.4 DePIN Data Quality, Tamper Resistance, Spoof Detection, Fraud Detection, and Confidence Methods.\
9.11.4(a) GCRI Canada shall steward DePIN data quality, tamper-resistance, spoof-detection, fraud-detection, anomaly-detection, signal-integrity, incentive-risk, and confidence methods for distributed infrastructure evidence.

9.11.4(b) Data quality methods shall identify source quality, device quality, telemetry completeness, measurement consistency, sampling method, timestamp integrity, location integrity, uptime integrity, calibration status where applicable, network context, missing data, duplicated data, stale data, outlier treatment, source bias, provider influence, sponsor influence, and correction path.

9.11.4(c) Tamper-resistance methods shall identify device tamper risk, hardware tamper risk, firmware or software tamper risk, telemetry tamper risk, log tamper risk, location tamper risk, proof tamper risk, validator tamper risk, custody risk, configuration manipulation, signature status, hash status, attestation status, and correction path.

9.11.4(d) Spoof-detection methods shall address location spoofing, signal spoofing, device spoofing, identity spoofing, uptime spoofing, coverage spoofing, telemetry replay, synthetic observations, relay attacks, Sybil-like patterns, collusion, network gaming, false capacity claims, false service claims, and adversarial manipulation.

9.11.4(e) Fraud-detection methods shall identify incentive design risks, token incentive risks, reward manipulation, fabricated activity, duplicated devices, non-independent devices, coordinated false claims, undisclosed provider control, undisclosed sponsor influence, host misrepresentation, market-inflating claims, and evidence-without-service patterns.

9.11.4(f) Confidence methods shall pair confidence with uncertainty and limitations and shall consider source quality, device identity, hardware status, custody, proof quality, location integrity, uptime integrity, telemetry integrity, calibration where any, corroboration, source independence, anomaly status, fraud risk, tamper risk, spoof risk, provider influence, sponsor influence, public authority context, community context, public-safe status, and correction status.

9.11.4(g) DePIN dashboards, maps, proof summaries, evidence summaries, coverage maps, uptime summaries, capacity summaries, service summaries, or public-safe outputs shall not conceal tamper risk, spoof risk, fraud risk, data gaps, incentive risk, contradiction, or uncertainty by smoothing, aggregating, ranking, color-coding, token-referencing, or AI-summarizing apparent confidence.

9.11.4(h) Where data quality, tamper-resistance, spoof-detection, fraud-detection, or confidence treatment is defective, GCRI Canada shall require source re-check, proof review, confidence downgrade, uncertainty revision, limitation update, dashboard relabeling, map relabeling, public-safe correction, controlled notice, method update, or dependency review.

9.11.4(i) The controlling rule shall be that DePIN evidence is trustworthy only when distributed signals are tested against tamper, spoofing, fraud, incentive distortion, uncertainty, and correction.

***

9.11.5 DePIN Interfaces With Blockchain / DLT, AI-RAN, Sensors, Observatory Nodes, Truth Engine, and Protocol Authority.\
9.11.5(a) GCRI Canada may steward DePIN interface methods with blockchain, distributed ledger technologies, proof systems, AI-RAN, O-RAN, private wireless, sensors, reference sensors, cyber systems, geospatial systems, digital twins, simulations, dashboards, maps, APIs, Observatory Nodes, Hubs, Clusters, Hotspots, Regional Observatory Clusters, National Dense Nexus Cores, Nexus Truth Engine, Verifiable Compute, Verifiable Intelligence, GRF, GRA, Nexus Standards / Protocol Authority, and correction records.

9.11.5(b) Interface methods shall identify interface purpose, source systems, receiving systems, proof systems, ledger systems where any, device systems, sensor systems, compute systems, model systems where any, data classes, evidence classes, output classes, source lineage, data lineage, method version, model version where applicable, compute workload, compute environment, access class, handling class, public-safe status, confidence, uncertainty, limitations, permitted flows, prohibited flows, permitted uses, prohibited uses, and correction path.

9.11.5(c) Blockchain and DLT interface methods shall identify ledger type, network context, transaction or event type, smart contract relationship where any, token relationship where any, wallet or address treatment where any and safe, proof receipt relationship, timestamp, hash or commitment relationship, public exposure risk, immutability limitation, revocation or correction mechanism, privacy treatment, public-safe status, and correction path.

9.11.5(d) AI-RAN and telecommunications interface methods shall identify signal relationship, network relationship, timing relationship, location treatment, telemetry relationship, device relationship, calibration relationship, spoof risk, interference risk, public-safe status, confidence, uncertainty, limitations, and correction propagation.

9.11.5(e) Sensor interface methods shall identify sensor relationship, calibration status, custody, placement context, data fusion method, timing alignment, location treatment, source independence, public-safe status, confidence, uncertainty, limitations, and correction path.

9.11.5(f) Observatory Node and Truth Engine interface methods shall preserve source comparison records, corroboration records, contradiction records, dispute records, confidence records, uncertainty records, inference records where applicable, human review records where material, public-safe review records, dependency links, proof records, and correction paths.

9.11.5(g) Protocol Authority interface methods shall preserve the distinction between evidence support and protocol effect. DePIN proof records, interface records, ledger events, token events, device records, coverage records, or proof receipts shall not create conformance, certification, Nexus-compatible status, role key, smart license, entitlement state, or protocol effect by GCRI Canada by default.

9.11.5(h) DePIN interfaces shall not create legal merger, system merger, network operation, public authority status, public warning, emergency command, procurement approval, finance-readiness, certification, recognition, protocol effect, provider preference, sponsor approval, host approval, operational clearance, market entitlement, infrastructure operation, or execution consequence by default.

9.11.5(i) Where interface defects are identified, including schema mismatch, timestamp mismatch, location mismatch, device mismatch, proof mismatch, ledger mismatch, token mismatch, telemetry mismatch, sensor mismatch, model mismatch, confidence mismatch, public-safe mismatch, permission mismatch, cybersecurity defect, privacy defect, sovereign-data defect, protected-knowledge defect, market-entitlement overclaim, or correction mismatch, GCRI Canada shall record the mismatch and correct, qualify, restrict, re-map, reclassify, supersede, or refuse the affected interface path as appropriate.

9.11.5(j) The controlling rule shall be that DePIN interfaces can strengthen evidence only where they preserve device meaning, source meaning, proof meaning, safeguards, boundaries, and correctionability.

***

9.11.6 DePIN Public-Safe Claims and No-Token-as-Authority Rule.\
9.11.6(a) GCRI Canada shall apply heightened public-safe claim discipline to DePIN and distributed infrastructure claims involving device identity, node status, contributor status, coverage, availability, capacity, integrity, observation, service, proof, token, reward, staking, validation, reputation, network participation, public authority relevance, host relevance, provider relevance, sponsor relevance, finance relevance, or market relevance.

9.11.6(b) No token, reward, stake, validator status, wallet record, ledger event, proof event, on-chain reference, smart contract event, governance token, reputation score, rank, badge, incentive payment, participation record, or network status shall constitute authority by default. Such artifacts shall not create public authority meaning, certification, recognition, finance-readiness, procurement approval, provider endorsement, sponsor approval, host approval, protocol effect, market entitlement, operational clearance, legal status, or execution consequence by GCRI Canada.

9.11.6(c) DePIN public-safe claims shall identify what is being claimed, the evidence basis, source records, proof records, device records, ledger records where any, method version, time period, geographic or safe-location scope, confidence, uncertainty, limitations, public-safe omissions, permitted use, prohibited use, and correction path.

9.11.6(d) Coverage maps, uptime dashboards, capacity summaries, proof badges, token-referenced summaries, device counts, node counts, service claims, resilience claims, availability claims, and public-safe reports shall not be framed as guaranteed service, public authority-approved coverage, procurement qualification, finance-readiness, certification, recognition, market entitlement, provider superiority, sponsor validation, operational clearance, or execution readiness.

9.11.6(e) DePIN public-safe claims shall not disclose or enable misuse of personal information, device-identifiable information where unsafe, household or small-group identifiability, sensitive locations, critical infrastructure detail, cyber-sensitive information, public authority restricted information, sovereign-sensitive information, community-protected information, Indigenous or protected knowledge, confidential source information, private keys, wallet-sensitive information where unsafe, credentials, secrets, tokens, exploit details, unsafe geospatial precision, or unsafe metadata.

9.11.6(f) Where public-safe DePIN claims cannot be made without distorting evidence, erasing uncertainty, concealing proof limits, exposing restricted data, exposing protected knowledge, creating public authority implication, creating finance implication, creating market-entitlement implication, creating provider preference, creating sponsor validation, or creating execution implication, GCRI Canada may use controlled annexes, controlled-room review, aggregation, generalization, safe-location treatment, delayed release, responsible non-disclosure, limited public-safe statement, or no-publication treatment.

9.11.6(g) Where DePIN claims are overclaimed, misused, misclassified, publicly misread, token-inflated, market-inflated, finance-inflated, authority-inflated, certification-inflated, recognition-inflated, provider-preferential, sponsor-validating, public-safe defective, or correction-defective, GCRI Canada shall correct, relabel, restrict, withdraw, reissue, notify affected interfaces where appropriate, and review dependencies.

9.11.6(h) The controlling rule shall be that DePIN tokens and proof artifacts may record participation or evidence events, but they do not become authority, legitimacy, finance, procurement, certification, recognition, protocol effect, market entitlement, or execution by implication.

***

9.11.7 DePIN Privacy, Location, Community, Public Authority, and Infrastructure-Sensitive Controls.\
9.11.7(a) GCRI Canada shall apply heightened privacy, location, community, Indigenous, protected knowledge, public authority, critical infrastructure, cybersecurity, sovereign data, host, provider, sponsor, token, wallet, and public-safe controls to DePIN and distributed infrastructure evidence.

9.11.7(b) Privacy methods shall identify whether DePIN evidence includes or may infer personal information, rights-bearing data, device identifiers, wallet or address patterns where relevant and unsafe, contributor behavior, user behavior, movement patterns, household or small-group identifiability, workplace identifiability, service-use patterns, health-adjacent patterns, vulnerable-person exposure, or other privacy-sensitive inferences.

9.11.7(c) Location methods shall identify precise-location risk, claimed-location risk, actual-location risk, device-location exposure, host-location exposure, sensitive-site exposure, critical-infrastructure exposure, community identifiability, protected knowledge exposure, public authority sensitivity, provider sensitivity, sponsor sensitivity, and safe-location treatment.

9.11.7(d) Community and Indigenous safeguard methods shall identify community protocols, Indigenous protocols where applicable, consent or non-consent treatment where applicable, territorial context, cultural context, environmental knowledge context, sensitive-site treatment, public-safe mapping limits, source protection, withdrawal or challenge pathways where applicable, accessibility, translation, localization, non-extraction, non-commodification, and do-no-harm controls.

9.11.7(e) Public authority sensitivity methods shall identify whether DePIN evidence arises from, relates to, is requested by, is received from, is reviewed by, is funded by, or may be used by a public authority, and shall preserve capacity classification, official or non-official status, data-sharing terms, agency reference controls, non-delegation language, non-endorsement language, non-regulatory language, non-procurement language, non-funding language, no-public-warning language, no-public-finance language, and correction path.

9.11.7(f) Infrastructure-sensitive methods shall identify device topology, network topology, service dependency, coverage dependency, outage sensitivity, degraded-mode sensitivity, vulnerability sensitivity, cyber-sensitive information, physical security risk, public-safe disclosure limits, and misuse risk.

9.11.7(g) DePIN evidence shall not be published, dashboarded, mapped, API-exposed, shared with providers, shared with sponsors, routed to finance-facing contexts, routed to public authority contexts, embedded, retrieved, trained on, token-promoted, or summarized externally without review proportionate to privacy, location, community, protected knowledge, public authority, infrastructure, cybersecurity, sovereign data, token, wallet, and public-safe risks.

9.11.7(h) Where privacy, location, community, public authority, infrastructure-sensitive, wallet-sensitive, or public-safe controls fail, GCRI Canada shall restrict access, correct classification, halt routing, remove unsafe fields, apply safe-location treatment, withdraw or revise outputs, notify affected interfaces where required, and review dependencies.

9.11.7(i) The controlling rule shall be that DePIN evidence may reveal people, places, communities, infrastructure, service dependencies, and authority relationships even when represented as device, proof, token, or network data; therefore its sensitivity must be governed before use.

***

9.11.8 DePIN Provider, Host, and Sponsor Boundary Controls.\
9.11.8(a) GCRI Canada shall apply provider neutrality, host-boundary, and sponsor non-control controls to DePIN methods where providers, hosts, sponsors, contributors, validators, operators, device suppliers, compute suppliers, dashboard suppliers, blockchain or DLT suppliers, or other actors supply data, tooling, equipment, devices, AI systems, compute environments, dashboards, maps, APIs, tokens, proof systems, funding, facilities, convening support, field support, publication support, or technical support.

9.11.8(b) Provider records shall identify provider identity, provider role, provider materials, provider systems, provider data, provider tools, provider equipment, provider devices, provider proof systems, provider dashboards, provider blockchain or DLT systems, provider staff or representatives where material, provider configuration, provider assumptions, commercial sensitivity, IP sensitivity, cybersecurity sensitivity, export-control sensitivity, sanctions sensitivity, conflict status, influence controls, benchmark conditions where any, validation conditions where any, permitted claims, prohibited claims, publication limits, and correction path.

9.11.8(c) Host records shall identify host identity, host role, facility or site context where safe and material, device placement context, infrastructure context, community context, public authority relevance, provider relevance, sponsor relevance, data classes, evidence classes, safe-location treatment, publication limits, no-operation boundary, no-host-approval boundary, no-certification boundary, no-finance boundary, no-procurement boundary, no-market-entitlement boundary, and correction path.

9.11.8(d) Sponsor records shall identify sponsor identity, sponsor role, funding or support relationship, token or incentive relationship where any, convening support, facilities support, technology access, data access, public authority access limits, provider access limits, publication limits, conflict status, sponsor non-control language, no-outcome-purchase language, no-evidence-control language, no-publication-control language, no-recognition-control language, no-finance-control language, no-protocol-control language, no-token-control language, and correction path.

9.11.8(e) Provider participation in a DePIN evidence context shall not create provider endorsement, procurement preference, preferred supplier status, public tender advantage, provider ranking, certification, recognition, Nexus-compatible status, Protocol Authority effect, finance-readiness, market superiority, operational clearance, market entitlement, or execution authority by default.

9.11.8(f) Host participation, device hosting, facility access, sensor placement, node placement, data contribution, coverage contribution, capacity contribution, dashboard visibility, or map visibility shall not imply host approval, host endorsement, host certification, host recognition, finance-readiness, procurement approval, public authority approval, provider preference, sponsor validation, operational clearance, market entitlement, or execution consequence.

9.11.8(g) Sponsor support shall not purchase outcomes, control evidence, control source selection, control device inclusion, control proof treatment, control confidence treatment, control public-safe publication, control token treatment, control public authority access, control provider access, control recognition, control finance-readiness, control protocol effect, control procurement, control host participation, control community participation, control market meaning, or control execution.

9.11.8(h) Where provider, host, or sponsor boundary defects are detected, GCRI Canada shall require disclosure correction, boundary-language revision, provider-reference removal, sponsor-reference correction, host-reference correction, benchmark correction, proof-claim correction, dashboard relabeling, map relabeling, public-safe correction, controlled notice, access restriction, interface suspension, contract remedy, or legal action where appropriate.

9.11.8(i) The controlling rule shall be that providers, hosts, and sponsors may support DePIN evidence only where evidence remains public-good, provider-neutral, host-bounded, sponsor-independent, public-safe, and correctionable.

***

9.11.9 DePIN Evidence Does Not Create Recognition, Certification, Finance-Readiness, Public Authority Meaning, or Market Entitlement by Default.\
9.11.9(a) No DePIN evidence, distributed infrastructure evidence, device record, hardware record, node record, contributor record, validator record, coverage record, uptime record, availability record, capacity record, service record, proof record, token record, wallet-related record, ledger event, smart contract event, dashboard, map, API, Evidence Pack, Decision Pack, technical note, public-safe output, public claim, correction signal, or Proof Receipt shall create recognition, certification, finance-readiness, public authority meaning, market entitlement, procurement approval, provider preference, sponsor approval, host approval, protocol effect, operational clearance, infrastructure operation, legal status, public warning, emergency command, deployment approval, or execution consequence by default.

9.11.9(b) DePIN evidence shall not issue or imply official guidance, regulatory determination, public authority decision, compliance determination, enforcement position, safe harbor, permit, license, procurement decision, vendor award, funding approval, public finance approval, investment advice, lending decision, underwriting decision, insurance approval, rating, guarantee, certification, recognition, maturity record, claims approval, conformance determination, Nexus-compatible status, role key, smart license, entitlement state, token entitlement, market entitlement, provider ranking, sponsor finding, host approval, operational instruction, deployment authorization, public warning, emergency command, or market signal.

9.11.9(c) Token issuance, reward payment, staking status, validator participation, wallet activity, proof receipt issuance, blockchain anchoring, ledger inclusion, smart contract execution, device count, node count, coverage map, uptime score, capacity indicator, service claim, dashboard visibility, map visibility, benchmark success, public authority interest, provider participation, sponsor support, host participation, community involvement, GRF interface use, GRA interface use, or Protocol Authority interface use shall not convert DePIN evidence into authority.

9.11.9(d) Any authority-bearing action by a public authority, GRF, GRA, Protocol Authority, National Nexus Consortium, Regional Nexus Consortium, National Company, Project SPV, provider, sponsor, host, finance actor, procurement actor, infrastructure operator, market actor, token network, university, community, or other actor shall arise only through that actor’s own lawful authority, process, record, accountability, and liability, not through DePIN evidence by implication.

9.11.9(e) DePIN materials shall include boundary language where material to prevent interpretation as public authority action, public warning, emergency command, procurement action, finance-readiness, public finance approval, certification, recognition, maturity, claims approval, protocol effect, provider preference, sponsor approval, host approval, operational clearance, market entitlement, infrastructure operation, legal status, professional advice, token authority, or execution instruction.

9.11.9(f) Where DePIN materials are misused to imply unauthorized authority, GCRI Canada shall correct, relabel, restrict, withdraw, reissue, require removal of misleading references, notify affected interfaces where appropriate, suspend affected interface use, or pursue contractual or legal remedies where appropriate.

9.11.9(g) No ambiguity shall be resolved in favour of DePIN authority, token authority, market entitlement, certification, recognition, finance-readiness, public authority meaning, protocol effect, provider preference, sponsor approval, host approval, operational clearance, or execution. Where there is doubt whether DePIN evidence creates authority or only supports evidence, the interpretation preserving GCRI Canada’s non-execution role, public authority boundaries, finance boundaries, procurement neutrality, provider neutrality, sponsor non-control, host boundaries, community safeguards, Protocol Authority role separation, GRF role separation, GRA role separation, validity-by-record, correctionability, and public trust shall prevail.

9.11.9(h) The controlling rule shall be that DePIN evidence may describe distributed participation, proof, devices, and infrastructure conditions, but it does not recognize, certify, finance, approve, entitle, regulate, operate, warn, command, or execute.

***

9.11.10 DePIN Evidence Records, Proof Records, Dispute Records, Correction, and Supersession.\
9.11.10(a) GCRI Canada shall maintain, or cause to be maintained, DePIN and distributed infrastructure evidence records for material methods, devices, hardware, sources, telemetry, proof events, ledger events, token-adjacent events, compute workloads, models, sensors, dashboards, maps, APIs, Evidence Packs, Decision Packs, public-safe outputs, disputes, incidents, corrections, dependencies, assurance reviews, and closeout events.

9.11.10(b) DePIN evidence records shall identify record title or identifier, source system, source class, device class, hardware class where any, telemetry class, proof class, ledger relationship where any, token relationship where any, provider where any, operator or network role where any, host where any, public authority context where any, community context where any, technology domain, risk domain, data class, evidence class, output class, access class, handling class, public-safe status, privacy status, cybersecurity status, sovereign data status, infrastructure-sensitive status, public authority status, finance-sensitive status, provider-sensitive status, sponsor-sensitive status, host-sensitive status, community-protected status, Indigenous or protected knowledge status, wallet-sensitive status where any, legal sensitivity, export-control sensitivity, sanctions sensitivity, permitted uses, prohibited uses, publication limits, and correction path.

9.11.10(c) Proof records shall identify proof title or identifier, proof type, proof purpose, proof event, claimant, source records, device records, hardware records where any, telemetry records, ledger records where any, token records where any, proof method, challenge method where any, attestation method where any, hash or signature where applicable, timestamp, scope, location or safe-location treatment, confidence, uncertainty, limitations, public-safe status, correction path, supersession path, withdrawal path, retraction path where applicable, and dependency links.

9.11.10(d) Dispute records shall identify disputed claim, disputing actor where safe and appropriate, evidence basis, source conflict, device conflict, location conflict, uptime conflict, availability conflict, capacity conflict, coverage conflict, service conflict, proof conflict, token or reward conflict where relevant, public-safe concern, provider concern, sponsor concern, host concern, community concern, public authority concern, fraud concern, spoof concern, tamper concern, reviewer, review status, interim controls, outcome, and correction path.

9.11.10(e) Incident records shall identify cybersecurity incident, device compromise, hardware tamper, firmware or software issue, telemetry incident, location spoofing, signal spoofing, identity spoofing, uptime spoofing, coverage spoofing, proof manipulation, ledger issue, smart contract issue where relevant, token-related misuse where relevant, data leakage, unauthorized access, unauthorized retrieval, unauthorized embedding, model incident, dashboard error, map error, API error, public-safe defect, public authority overclaim, finance overclaim, procurement implication, provider preference, sponsor validation, host approval implication, market-entitlement implication, protected knowledge exposure, privacy incident, sovereign data issue, export-control issue, sanctions issue, or correction failure affecting DePIN evidence.

9.11.10(f) Correction records shall identify corrected source, corrected device identity, corrected hardware identity, corrected location claim, corrected uptime claim, corrected availability claim, corrected capacity claim, corrected coverage claim, corrected service claim, corrected proof record, corrected ledger reference, corrected token-related reference where any, corrected dataset, corrected method, corrected compute workload, corrected model, corrected dashboard, corrected map, corrected API, corrected public-safe output, corrected public authority reference, corrected provider reference, corrected sponsor reference, corrected host reference, corrected community reference, prior status, corrected status, effective date, reviewer, affected dependencies, notice decision, access change, archive treatment, and continuing limitations.

9.11.10(g) Supersession records shall identify replacement DePIN record, changed evidence base, changed proof method, changed device relationship, changed hardware relationship, changed ledger relationship, changed token relationship where any, changed host context, changed community context, changed public authority context, changed provider context, changed sponsor context, changed methods, changed confidence, changed uncertainty, changed limitations, changed public-safe status, changed boundary language, continuing validity where any, discontinued reliance where any, and downstream dependency treatment.

9.11.10(h) DePIN withdrawal or retraction records shall be used where distributed infrastructure evidence or outputs should no longer be used or relied upon because of material error, unsafe disclosure, proof defect, device defect, hardware defect, location defect, uptime defect, coverage defect, capacity defect, service-claim defect, spoofing defect, tamper defect, fraud defect, cybersecurity defect, public-safe defect, public authority confusion, finance overclaim, procurement implication, provider-preferential framing, sponsor-validation framing, host approval implication, market-entitlement implication, protected knowledge exposure, privacy defect, sovereign data issue, cross-border defect, infrastructure-risk exposure, or correction failure.

9.11.10(i) DePIN records shall be linked, where applicable, to National Dense Core records, Regional Observatory Cluster records, Cluster records, Hub records, Node records, Hotspot records, AI-RAN records, sensor records, blockchain or DLT records, Observatory Methods Register entries, Evidence Register entries, Source Comparison Records, Dataset Register entries, Model Register entries, System Card entries, Benchmark Card entries, Compute Workload Records, Compute Environment Records, Inference Records, Human Review Records, Retrieval and Embedding Records, Proof Receipt Records, Public-Safe Output Records, AI Incident Records, Correction Records, Dependency Records, Truth Engine Records, public authority records, GRF interface records, GRA interface records, Protocol Authority interface records, RNFD records, Nexus Risk Management records, Nexus Rails records, Regional Nexus Consortium records, National Nexus Consortium records, National Company records, Project SPV records, operator records, provider records, sponsor records, host records, community records, university records, Nexus interface records, and public claims records.

9.11.10(j) DePIN evidence records, proof records, dispute records, incident records, public-safe records, correction, supersession, withdrawal, retraction, assurance, retirement, archive, and closeout shall not create certification, recognition, finance-readiness, public authority decision, procurement approval, provider endorsement, sponsor approval, host approval, operator approval, rating, guarantee, public warning, emergency command, telecommunications regulation, spectrum regulation, protocol effect, operational clearance, legal status, market authority, market entitlement, infrastructure operation, deployment approval, national authority, or execution consequence by default.

9.11.10(k) The controlling rule shall be that DePIN evidence is trustworthy only when its device identity, proof basis, ledger relationship, token limits, location, uptime, coverage, service claims, tamper risks, spoof risks, fraud risks, public-safe treatment, disputes, corrections, and dependencies remain recorded with enough precision to protect systems, communities, public authorities, markets, participants, and public trust.

### 9.12 Sensor Evidence Methods

9.12.1 Sensor Evidence as Observatory Core.\
9.12.1(a) GCRI Canada shall steward sensor evidence methods as a core Observatory methods domain for identifying, receiving, classifying, comparing, interpreting, public-safe summarizing, and correcting evidence arising from sensors, reference sensors, environmental sensors, infrastructure sensors, health-sensitive or human-proximate sensors, community sensors, industrial sensors, utility sensors, port sensors, corridor sensors, remote community sensors, field sensors, networked sensing systems, AI-RAN-connected sensors, DePIN-connected sensors, digital twin inputs, dashboards, maps, APIs, Evidence Packs, Decision Packs, and public-safe outputs.

9.12.1(b) Sensor evidence methods shall support observability, source comparison, calibration discipline, signal integrity, environmental context, infrastructure context, public authority learning, community learning, host learning, provider-neutral technical review, degraded-mode learning, resilience learning, Verifiable Compute, Verifiable Intelligence, Nexus Truth Engine inputs, Observatory Node records, Hub records, Cluster records, Hotspot records, Regional Observatory Cluster records, National Dense Nexus Core records, GRF inputs, GRA inputs, Protocol Authority inputs, Nexus Risk Management inputs, Nexus Rails inputs, Nexus Grid inputs, Nexus Academy materials, public-good software support, technical baseline support, public-safe publication, and correction workflows.

9.12.1(c) Sensor evidence shall be treated as records-valid, source-lined, calibration-aware, configuration-aware, timing-aware, location-aware, custody-aware, confidence-aware, uncertainty-aware, limitation-aware, privacy-protective, cybersecurity-controlled, public-safe, sovereignty-compatible, community-sensitive, provider-neutral, sponsor-independent, and correctionable.

9.12.1(d) Sensor evidence shall not be treated as accurate, complete, public-safe, authority-bearing, finance-relevant, procurement-relevant, certified, recognized, protocol-effective, operationally cleared, or execution-ready merely because it is machine-generated, continuous, real-time, high-resolution, calibrated by a provider, dashboard-visible, map-visible, AI-assisted, DePIN-linked, AI-RAN-linked, public authority-relevant, sponsor-supported, host-confirmed, cryptographically logged, or consistent with expectation.

9.12.1(e) GCRI Canada’s stewardship of sensor evidence methods shall not make GCRI Canada a sensor operator, infrastructure operator, public authority, emergency-management actor, public warning issuer, telecommunications operator, utility operator, industrial operator, health actor, certification body, procurement actor, finance actor, Protocol Authority, provider, sponsor, host, National Company, Project SPV, or execution actor by default.

9.12.1(f) Sensor evidence methods shall preserve the distinction between sensor signal, sensor reading, reference measurement, field observation, data stream, processed record, inferred condition, model output, dashboard indicator, map layer, public-safe summary, public authority learning material, provider demonstration, benchmark result, and any authority-bearing decision made by a competent separate actor.

9.12.1(g) Where sensor evidence is used externally or publicly, GCRI Canada shall preserve controlled vocabulary, source lineage, calibration status, configuration status, confidence, uncertainty, limitations, public-safe status, no-public-warning language, no-emergency-command language, no-public-authority language, no-finance language, no-procurement language, no-certification language, no-recognition language, no-protocol-effect language unless separately created by Protocol Authority, no-provider-endorsement language, no-sponsor-approval language, no-host-approval language, no-infrastructure-operation language, and correction path where material.

9.12.1(h) The controlling rule shall be that sensor evidence is Observatory core because sensors can make systems visible, but visibility becomes institutional evidence only through custody, calibration, context, confidence, uncertainty, public-safe treatment, and correction.

***

9.12.2 Sensor Identity, Custody, Calibration, Configuration, Maintenance, Firmware, Location, Timing, and Integrity.\
9.12.2(a) GCRI Canada shall steward methods for recording and reviewing sensor identity, custody, calibration, configuration, maintenance, firmware or software status, location, timing, signal quality, data quality, integrity, tamper risk, spoof risk, drift risk, failure modes, public-safe status, and correction path for material sensor evidence.

9.12.2(b) Sensor identity records shall identify, where lawful and safe, sensor title or identifier, sensor class, measurement class, manufacturer or provider where material, model, serial or equivalent identifier where lawful and safe, owner where known, custodian, steward, host context, operator context where any, provider context, sponsor context where any, public authority context where any, community context where any, and correction path.

9.12.2(c) Custody records shall identify sensor possession, access rights, installation context, maintenance responsibility, data custody, log custody, calibration custody, configuration custody, firmware or software custody, dashboard custody, map custody, API custody, output custody, and correction custody.

9.12.2(d) Calibration records shall identify calibration status, calibration method, calibration date, calibration interval, calibration authority where any, reference source, reference sensor relationship where any, calibration conditions, calibration uncertainty, calibration drift, overdue calibration, failed calibration, corrected calibration, and calibration-related limitations.

9.12.2(e) Configuration and maintenance records shall identify configuration settings, firmware or software version where material, patch status, maintenance status, maintenance date, maintenance actor, configuration changes, known defects, device limitations, network dependencies, power dependencies, environmental dependencies, and correction path.

9.12.2(f) Location records shall identify placement context, location source, geospatial precision, safe-location treatment, relocation history, sensitive-site risk, infrastructure-sensitive risk, community-identifiability risk, public authority sensitivity, host sensitivity, protected knowledge sensitivity, and public-safe publication limits.

9.12.2(g) Timing records shall identify timestamp source, clock synchronization, clock drift risk, latency, sampling interval, update cadence, stale-data status, missing intervals, sequence ordering, replay risk, delayed transmission risk, and timing-related correction path.

9.12.2(h) Integrity records shall identify tamper-evidence where any, physical integrity, firmware or software integrity, data integrity, log integrity, cybersecurity status, spoof risk, signal interference, sensor drift, anomaly status, failure modes, quality status, incident history, confidence effect, uncertainty effect, limitation effect, and correction path.

9.12.2(i) Sensor identity, custody, calibration, configuration, maintenance, firmware, location, timing, or integrity records shall not constitute sensor certification, equipment approval, public authority approval, procurement approval, provider endorsement, finance-readiness, public warning, emergency command, protocol effect, operational clearance, infrastructure operation, legal status, or execution consequence by default.

9.12.2(j) The controlling rule shall be that a sensor reading is institutionally meaningful only when the institution can identify what sensor produced it, under whose custody, in what configuration, at what time and place, under what calibration and integrity conditions, and with what correction path.

***

9.12.3 Reference Sensor Methods.\
9.12.3(a) GCRI Canada shall steward reference sensor methods for using designated, calibrated, controlled, benchmarked, laboratory-supported, field-validated, or otherwise reference-capable sensors to compare, calibrate, challenge, corroborate, qualify, downgrade, or correct other sensor evidence.

9.12.3(b) Reference sensor records shall identify reference sensor identity, reference purpose, sensor class, measurement class, owner where known, custodian, steward, calibration status, calibration authority where any, traceability relationship where any, uncertainty, maintenance status, configuration, placement context, timing source, location or safe-location treatment, environmental constraints, public-safe status, access class, handling class, and correction path.

9.12.3(c) Reference sensor methods shall identify when a reference sensor may be used for calibration support, validation support, source comparison, contradiction handling, dispute handling, field quality review, benchmark support, degraded-mode review, public-safe reporting, or correction support.

9.12.3(d) A reference sensor shall not be treated as infallible, universally authoritative, public authority-approved, certified by GCRI Canada, procurement-approved, provider-endorsed, finance-relevant, operationally cleared, or execution-ready merely because it is designated as a reference sensor.

9.12.3(e) Reference sensor comparison shall identify measurement alignment, unit alignment, time alignment, location alignment, environmental alignment, configuration alignment, calibration alignment, uncertainty relationship, confidence effect, limitation effect, contradiction status, and correction path.

9.12.3(f) Where reference sensor evidence conflicts with ordinary sensor evidence, GCRI Canada shall record the conflict, evaluate source authority, calibration, custody, timing, location, configuration, environmental conditions, interference, sensor drift, tamper risk, spoof risk, public-safe status, and dependency effects before correcting or downgrading affected outputs.

9.12.3(g) Reference sensor outputs shall not create public warning, emergency command, public authority decision, certification, procurement approval, finance-readiness, provider preference, sponsor approval, host approval, protocol effect, operational clearance, infrastructure operation, or execution consequence by default.

9.12.3(h) The controlling rule shall be that reference sensors strengthen comparison only when their own calibration, limits, custody, uncertainty, and correction path are visible.

***

9.12.4 Environmental Sensor Methods.\
9.12.4(a) GCRI Canada shall steward environmental sensor methods for evidence arising from sensors measuring or indicating environmental, climate, nature, water, air, soil, biodiversity, weather, hydrological, coastal, wildfire, heat, drought, storm, ecosystem, emissions, pollution, or other environmental conditions relevant to Observatory purposes.

9.12.4(b) Environmental sensor records shall identify source records, sensor identity where safe, sensor class, measured parameter, measurement unit, calibration status, placement context, environmental context, timestamp, location or safe-location treatment, sampling method, data quality, completeness, missing data, interference, seasonal context, weather context, public-safe status, confidence, uncertainty, limitations, and correction path.

9.12.4(c) Environmental sensor methods shall distinguish direct measurement, proxy measurement, derived indicator, modeled indicator, satellite-derived indicator, digital twin output, field observation, public authority context, community observation, Indigenous or protected knowledge context, provider-supplied reading, sponsor-supplied reading, and public-safe summary.

9.12.4(d) Environmental sensor evidence shall be reviewed for spatial uncertainty, temporal uncertainty, instrument uncertainty, environmental variability, data gaps, sensor drift, site representativeness, calibration limits, proxy limits, model limits, and public-safe interpretation.

9.12.4(e) Environmental sensor outputs shall not be treated as official hazard designation, public warning, emergency command, public health order, environmental compliance determination, regulatory approval, enforcement position, safe harbor, permit condition, finance-readiness, insurance-readiness, procurement priority, certification, recognition, provider preference, sponsor approval, protocol effect, operational clearance, or execution instruction by default.

9.12.4(f) Where environmental sensor outputs are used in public-safe summaries, dashboards, maps, regional hazard evidence, host readiness evidence, GRA-facing materials, GRF-facing materials, public authority learning materials, Academy materials, media materials, or public claims, they shall include confidence, uncertainty, limitations, public-safe omissions, no-public-warning language, no-public-authority language, no-finance language, no-procurement language, and correction path where material.

9.12.4(g) Where environmental sensor evidence is missing, stale, miscalibrated, mislocated, mis-timestamped, interfered with, disputed, contradicted, public-safe defective, or later corrected, GCRI Canada shall qualify, downgrade, correct, supersede, withdraw, or archive affected outputs as appropriate.

9.12.4(h) The controlling rule shall be that environmental sensor evidence helps make environmental conditions observable, but it does not itself create official environmental status, public warning, regulatory effect, finance consequence, or execution instruction.

***

9.12.5 Infrastructure Sensor Methods.\
9.12.5(a) GCRI Canada shall steward infrastructure sensor methods for evidence arising from sensors measuring or indicating conditions in or around infrastructure systems, including energy systems, water systems, transportation systems, ports, corridors, telecommunications systems, AI-RAN systems, O-RAN systems, private wireless systems, industrial systems, manufacturing systems, semiconductor facilities, logistics systems, buildings, campuses, critical facilities, cyber-physical systems, and related mission-critical assets.

9.12.5(b) Infrastructure sensor records shall identify source records, sensor identity where safe, infrastructure context, operator context where any, host context, provider context, public authority relevance, measured parameter, calibration status, configuration status, maintenance status, timestamp, location or safe-location treatment, sampling method, data quality, cybersecurity sensitivity, infrastructure sensitivity, public-safe status, access class, handling class, confidence, uncertainty, limitations, and correction path.

9.12.5(c) Infrastructure sensor methods shall distinguish condition monitoring, anomaly detection, degradation evidence, outage-adjacent evidence, maintenance context, safety-adjacent context, cyber-physical context, operator observation, host observation, public authority context, provider-supplied data, sponsor-supplied data, model output, digital twin output, dashboard indicator, map layer, and public-safe summary.

9.12.5(d) Infrastructure sensor evidence shall be reviewed for critical infrastructure sensitivity, cyber-sensitive information, topology exposure, dependency exposure, outage sensitivity, vulnerability sensitivity, physical security risk, operational risk, public authority sensitivity, host sensitivity, operator sensitivity, public-safe disclosure risk, and correction needs.

9.12.5(e) Infrastructure sensor outputs shall not be used or framed as operational command, public warning, emergency command, public authority decision, operator instruction, service assurance, uptime assurance, safety certification, regulatory compliance determination, procurement approval, finance-readiness, insurance-readiness, rating, guarantee, certification, recognition, provider endorsement, sponsor approval, host approval, protocol effect, operational clearance, infrastructure operation, deployment approval, or execution instruction by default.

9.12.5(f) Where infrastructure sensor outputs are used in dashboards, maps, Evidence Packs, Decision Packs, public authority learning materials, GRA-facing materials, GRF-facing materials, Protocol Authority-facing materials, provider-facing materials, sponsor-facing materials, host-facing materials, Academy materials, or public-safe summaries, GCRI Canada shall preserve safe-location treatment, responsible non-disclosure, confidence, uncertainty, limitations, boundary language, and correction path.

9.12.5(g) Where infrastructure sensor evidence is missing, stale, miscalibrated, misconfigured, compromised, spoofed, tampered, contradicted, public-safe defective, or later corrected, GCRI Canada shall qualify, downgrade, restrict, correct, supersede, withdraw, or archive affected outputs as appropriate.

9.12.5(h) The controlling rule shall be that infrastructure sensor evidence may support understanding of infrastructure conditions, but it shall not become infrastructure command, public authority decision, certification, procurement approval, finance-readiness, or execution by GCRI Canada.

***

9.12.6 Health-Sensitive or Human-Proximate Sensor Methods.\
9.12.6(a) GCRI Canada shall apply heightened controls to health-sensitive or human-proximate sensor evidence, including sensor evidence that measures, indicates, infers, or may be reasonably associated with human presence, movement, behavior, health-adjacent conditions, biometric-adjacent patterns, workplace exposure, household exposure, vulnerable-person exposure, community exposure, public health context, safety context, or other rights-bearing human context.

9.12.6(b) Health-sensitive or human-proximate sensor records shall identify source records, sensor class, measured or inferred parameter, personal information risk, rights-bearing data risk, health-sensitive risk, small-group identifiability risk, household identifiability risk, workplace identifiability risk, vulnerable-person risk, community-identifiability risk, public authority sensitivity, host sensitivity, consent or non-consent treatment where applicable, lawful basis where applicable, access class, handling class, public-safe status, confidence, uncertainty, limitations, and correction path.

9.12.6(c) Health-sensitive or human-proximate sensor methods shall prioritize minimization, aggregation, de-identification where appropriate, pseudonymization where appropriate, safe-location treatment, restricted access, compute-to-data treatment where appropriate, no-download treatment where appropriate, responsible non-disclosure, public-safe review, human review where material, and correction propagation.

9.12.6(d) Such sensor evidence shall not be used for public health orders, clinical decisions, employment decisions, insurance decisions, credit decisions, eligibility decisions, law enforcement decisions, immigration decisions, benefits decisions, public authority decisions, public warnings, emergency commands, individual profiling, surveillance, or rights-affecting decisions by GCRI Canada.

9.12.6(e) Health-sensitive or human-proximate sensor evidence shall not be trained on, fine-tuned on, embedded, retrieved, vendor-processed, publicly summarized, dashboarded, mapped, API-exposed, shared with providers, shared with sponsors, or routed to public authority or finance-facing contexts without express recorded authority and safeguards proportionate to risk.

9.12.6(f) Where public-safe outputs involve health-sensitive or human-proximate sensor evidence, GCRI Canada shall avoid identifiability, false reassurance, undue alarm, stigmatization, discriminatory inference, small-group exposure, sensitive-site exposure, and overclaim, and shall include confidence, uncertainty, limitations, public-safe omissions, permitted use, prohibited use, and correction path.

9.12.6(g) Where health-sensitive or human-proximate sensor controls fail, GCRI Canada shall restrict access, halt routing, correct classification, remove unsafe fields, delete or seal records where appropriate, withdraw or revise outputs, notify affected interfaces where required, and review dependencies.

9.12.6(h) The controlling rule shall be that sensor evidence near people must be governed as rights-bearing evidence, not merely technical signal.

***

9.12.7 Community Sensor Methods.\
9.12.7(a) GCRI Canada shall steward community sensor methods for sensor evidence generated by, located in, affecting, or interpreted with communities, including community-hosted sensors, citizen or community science sensors, local environmental sensors, community infrastructure sensors, public-safe learning sensors, Indigenous or community-controlled sensing contexts, and other community-proximate sensing arrangements.

9.12.7(b) Community sensor records shall identify community context, host context, sensor identity where safe, sensor class, source authority, custody, steward, consent or non-consent treatment where applicable, community protocol, Indigenous protocol where applicable, territorial context, cultural context, environmental knowledge context, local context, data classes, evidence classes, public-safe status, access class, handling class, confidence, uncertainty, limitations, and correction path.

9.12.7(c) Community sensor methods shall protect against extraction, surveillance, stigmatization, retaliation, sensitive-site exposure, community-identifiability risk, protected knowledge exposure, decontextualization, inequitable publication, unsafe mapping, and misuse by public authorities, providers, sponsors, markets, media, or other actors.

9.12.7(d) Community sensor evidence shall not be dismissed merely because it is locally generated, lower cost, community-maintained, qualitative-adjacent, non-provider-confirmed, non-public-authority-confirmed, not part of formal infrastructure, or not easily integrated into technical dashboards or maps.

9.12.7(e) Community sensor outputs shall not be treated as community consent, community endorsement, public authority decision, official public warning, regulatory status, finance-readiness, procurement approval, provider preference, sponsor approval, host approval, certification, recognition, protocol effect, operational clearance, market authority, or execution permission by default.

9.12.7(f) Where community sensor data are used in public-safe summaries, dashboards, maps, reports, Academy materials, public authority learning materials, GRF inputs, GRA inputs, Protocol Authority inputs, provider-facing materials, sponsor-facing materials, or public claims, GCRI Canada shall preserve community context, public-safe limits, controlled vocabulary, confidence, uncertainty, limitations, protected knowledge safeguards, no-endorsement language, and correction path.

9.12.7(g) Where community sensor outputs create or may create community harm, unsafe mapping, misattribution, decontextualization, stigmatization, retaliation risk, protected knowledge exposure, public authority overclaim, provider misuse, sponsor misuse, finance overclaim, or public-safe defect, GCRI Canada shall restrict, correct, withdraw, retract where appropriate, notify affected interfaces where appropriate, and update methods.

9.12.7(h) The controlling rule shall be that community sensing is public-good evidence only when communities are protected from being turned into exposed data sources, implied endorsers, or execution sites.

***

9.12.8 Industrial, Utility, Port, Corridor, Remote Community, and Field Sensor Methods.\
9.12.8(a) GCRI Canada shall steward specialized methods for industrial, utility, port, corridor, remote community, northern, rural, coastal, field, mobile, temporary, expeditionary, and other context-specific sensor evidence used in Observatory systems.

9.12.8(b) Industrial sensor methods shall identify industrial context, facility context, process context where safe and material, operator context, host context, provider context, cybersecurity sensitivity, infrastructure sensitivity, commercial sensitivity, safety-adjacent sensitivity, calibration status, configuration status, maintenance status, public-safe status, confidence, uncertainty, limitations, and correction path.

9.12.8(c) Utility sensor methods shall identify energy, water, telecommunications, waste, transport, or other utility context; operator context where any; public authority relevance; infrastructure sensitivity; service dependency; outage sensitivity; degraded-mode context; cybersecurity sensitivity; public-safe limits; confidence; uncertainty; limitations; and correction path.

9.12.8(d) Port and corridor sensor methods shall identify logistics context, transport context, supply-chain context, border or cross-border context where applicable, maritime or aviation context where applicable, public authority sensitivity, security sensitivity, infrastructure sensitivity, commercial sensitivity, geospatial sensitivity, timing sensitivity, public-safe status, confidence, uncertainty, limitations, and correction path.

9.12.8(e) Remote community and field sensor methods shall identify environmental constraints, power constraints, communications constraints, maintenance constraints, field safety, access limits, community context, Indigenous or protected knowledge context where applicable, safe-location treatment, data gaps, degraded-mode status, public-safe status, confidence, uncertainty, limitations, and correction path.

9.12.8(f) Mobile or temporary sensor methods shall identify deployment context, duration, placement authority, movement records, timing, location or safe-location treatment, calibration status before and after deployment where material, custody, data transfer method, retrieval limits, public-safe status, and closeout requirements.

9.12.8(g) Outputs from industrial, utility, port, corridor, remote community, or field sensors shall not create public warning, emergency command, public authority decision, compliance determination, procurement approval, finance-readiness, insurance-readiness, certification, recognition, provider endorsement, sponsor approval, host approval, operator instruction, operational clearance, infrastructure operation, deployment approval, market authority, or execution consequence by default.

9.12.8(h) The controlling rule shall be that specialized sensor contexts require specialized safeguards because the same reading can carry different public-safe, operational, community, security, finance, and authority risks in different places.

***

9.12.9 Sensor Fusion, Corroboration, Confidence, Uncertainty, Missing Data, and Spoof Handling.\
9.12.9(a) GCRI Canada shall steward sensor fusion, corroboration, confidence, uncertainty, missing data, contradiction, spoof, tamper, anomaly, and dispute-handling methods for sensor evidence used in Observatory systems.

9.12.9(b) Sensor fusion methods shall identify source sensors, reference sensors where any, data fusion method, time alignment, location alignment, unit alignment, calibration alignment, sampling alignment, resolution alignment, uncertainty propagation, model use where any, compute workload where any, public-safe status, and correction path.

9.12.9(c) Corroboration methods shall treat agreement across sensors as method-based support, not automatic truth. Sensor agreement shall be assessed for source independence, shared failure modes, common provider configuration, common host conditions, common environmental interference, common timing error, common calibration error, shared data pipeline, shared model, shared compute environment, sponsor influence, and public-safe limitations.

9.12.9(d) Confidence methods shall consider calibration, custody, configuration, maintenance, firmware or software status, timing integrity, location integrity, signal quality, data quality, missing data, sensor drift, interference, environmental context, source independence, reference comparison, corroboration, contradiction, spoof risk, tamper risk, model use, compute integrity, provider influence, sponsor influence, host context, public authority context, community context, public-safe status, and correction status.

9.12.9(e) Uncertainty methods shall identify measurement uncertainty, calibration uncertainty, timing uncertainty, location uncertainty, spatial uncertainty, temporal uncertainty, sensor uncertainty, environmental uncertainty, model uncertainty, fusion uncertainty, source uncertainty, public authority uncertainty, community uncertainty, protected knowledge uncertainty, legal uncertainty, interpretive uncertainty, and public-safe uncertainty.

9.12.9(f) Missing data methods shall identify missing sensor records, failed sensors, unavailable reference sensors, inaccessible data, withheld data, public authority restrictions, community non-consent, protected knowledge restrictions, privacy restrictions, cybersecurity restrictions, sovereign data restrictions, provider non-disclosure, sponsor non-disclosure, host limits, stale data, partial coverage, and public-safe omissions.

9.12.9(g) Spoof and tamper handling shall address sensor spoofing, signal spoofing, location spoofing, timestamp spoofing, replay, synthetic data, adversarial manipulation, device tampering, firmware tampering, telemetry tampering, log tampering, calibration tampering, configuration manipulation, model manipulation, prompt injection where applicable, cyber compromise, and confidence downgrade requirements.

9.12.9(h) Sensor fusion, corroboration, confidence, uncertainty, missing data, and spoof handling shall not conceal limitations by smoothing, averaging, aggregating, color-coding, ranking, heatmapping, AI-summarizing, or public-safe summarizing apparent consensus.

9.12.9(i) Where treatment under this section is defective, GCRI Canada shall require source re-check, sensor re-check, reference comparison, confidence downgrade, uncertainty revision, limitation update, dashboard relabeling, map relabeling, public-safe correction, controlled notice, method update, or dependency review.

9.12.9(j) The controlling rule shall be that multiple sensor signals create stronger evidence only where fusion, corroboration, uncertainty, missing data, and spoof risks are governed and recorded.

***

9.12.10 Sensor Data Privacy, Public Authority, Community, Indigenous, Protected Knowledge, and Public-Safe Controls.\
9.12.10(a) GCRI Canada shall apply heightened privacy, public authority, community, Indigenous, protected knowledge, cybersecurity, sovereign data, infrastructure-sensitive, host, provider, sponsor, operator, and public-safe controls to sensor evidence and sensor-derived outputs.

9.12.10(b) Privacy controls shall identify whether sensor evidence includes or may infer personal information, rights-bearing data, device identifiers, household patterns, movement patterns, workplace patterns, service-use patterns, health-adjacent patterns, vulnerable-person exposure, small-group identifiability, community identifiability, or other privacy-sensitive inferences.

9.12.10(c) Public authority controls shall identify whether sensor evidence arises from, relates to, is requested by, is received from, is reviewed by, is funded by, or may be used by a public authority, and shall preserve capacity classification, official or non-official status, data-sharing terms, agency reference controls, non-delegation language, non-endorsement language, non-regulatory language, non-procurement language, non-funding language, no-public-warning language, no-public-finance language, and correction path.

9.12.10(d) Community and Indigenous safeguard controls shall identify community protocols, Indigenous protocols where applicable, consent or non-consent treatment where applicable, territorial context, cultural context, environmental knowledge context, sensitive-site treatment, public-safe mapping limits, source protection, withdrawal or challenge pathways where applicable, accessibility, translation, localization, non-extraction, non-commodification, and do-no-harm controls.

9.12.10(e) Protected knowledge controls shall prohibit extraction, mapping, summarization, translation, modeling, embedding, retrieval, training, dashboarding, publication, commodification, decontextualization, or public-safe reuse of protected knowledge without recorded authority, safeguards, and public-safe review appropriate to the knowledge context.

9.12.10(f) Public-safe controls shall prevent unsafe disclosure of personal information, rights-bearing data, health-sensitive data, cyber-sensitive information, infrastructure-sensitive information, public authority restricted information, sovereign-sensitive information, finance-sensitive information, community-protected information, Indigenous or protected knowledge, confidential source information, privileged material, credentials, secrets, keys, tokens, controlled technology, exploit details, sensitive locations, unsafe geospatial precision, unsafe metadata, or small-community identifiable information.

9.12.10(g) Sensor evidence shall not be published, dashboarded, mapped, API-exposed, shared with providers, shared with sponsors, routed to finance-facing contexts, routed to public authority contexts, embedded, retrieved, trained on, or summarized externally without review proportionate to privacy, public authority, community, protected knowledge, cybersecurity, sovereign data, infrastructure, host, provider, sponsor, operator, and public-safe risks.

9.12.10(h) Where sensor privacy, public authority, community, protected knowledge, or public-safe controls fail, GCRI Canada shall restrict access, correct classification, halt routing, remove unsafe fields, apply safe-location treatment, delete or seal records where appropriate, withdraw or revise outputs, notify affected interfaces where required, and review dependencies.

9.12.10(i) The controlling rule shall be that sensor evidence often makes people, places, systems, authorities, and communities visible; therefore it must be governed before it is useful.

***

9.12.11 Sensor Evidence Does Not Create Public Warning, Emergency Command, Certification, Procurement Approval, or Public Authority Meaning by Default.\
9.12.11(a) No sensor evidence, sensor record, reference sensor record, calibration record, maintenance record, quality record, signal record, telemetry record, sensor fusion record, dashboard, map, API, Evidence Pack, Decision Pack, technical note, public-safe output, public claim, correction signal, or Proof Receipt shall create public warning, emergency command, certification, procurement approval, public authority meaning, finance-readiness, recognition, protocol effect, provider preference, sponsor approval, host approval, operator approval, infrastructure operation, operational clearance, legal status, market authority, deployment approval, or execution consequence by default.

9.12.11(b) Sensor evidence shall not issue or imply official guidance, regulatory determination, public authority decision, compliance determination, enforcement position, safe harbor, permit, license, procurement decision, vendor award, funding approval, public finance approval, public warning, emergency alert, evacuation instruction, emergency command, public safety directive, public health order, investment advice, lending decision, underwriting decision, insurance approval, rating, guarantee, certification, recognition, maturity record, claims approval, conformance determination, Nexus-compatible status, provider ranking, sponsor finding, host approval, operator instruction, deployment authorization, operational clearance, or market signal.

9.12.11(c) Sensor calibration, reference sensor comparison, dashboard visibility, map visibility, real-time display, AI interpretation, public authority interest, provider participation, sponsor support, host participation, operator participation, community participation, benchmark success, Proof Receipt issuance, GRF interface use, GRA interface use, or Protocol Authority interface use shall not convert sensor evidence into authority.

9.12.11(d) Any authority-bearing action by a public authority, GRF, GRA, Protocol Authority, National Nexus Consortium, Regional Nexus Consortium, National Company, Project SPV, provider, sponsor, host, operator, finance actor, procurement actor, infrastructure actor, university, community, or other actor shall arise only through that actor’s own lawful authority, process, record, accountability, and liability, not through sensor evidence by implication.

9.12.11(e) Sensor materials shall include boundary language where material to prevent interpretation as public authority action, public warning, emergency command, procurement action, finance-readiness, public finance approval, certification, recognition, maturity, claims approval, protocol effect, provider preference, sponsor approval, host approval, operator approval, operational clearance, infrastructure operation, legal status, professional advice, market signal, deployment approval, or execution instruction.

9.12.11(f) Where sensor materials are misused to imply unauthorized authority, GCRI Canada shall correct, relabel, restrict, withdraw, reissue, require removal of misleading references, notify affected interfaces where appropriate, suspend affected interface use, or pursue contractual or legal remedies where appropriate.

9.12.11(g) No ambiguity shall be resolved in favour of sensor authority. Where there is doubt whether sensor evidence creates authority or only supports evidence, the interpretation preserving GCRI Canada’s non-execution role, public authority boundaries, finance boundaries, procurement neutrality, provider neutrality, sponsor non-control, host boundaries, operator boundaries, community safeguards, Protocol Authority role separation, GRF role separation, GRA role separation, validity-by-record, correctionability, and public trust shall prevail.

9.12.11(h) The controlling rule shall be that sensors observe; they do not warn, command, approve, certify, procure, finance, recognize, regulate, operate, or execute by default.

***

9.12.12 Sensor Records, Calibration Records, Maintenance Records, Quality Records, Incident Records, and Correction.\
9.12.12(a) GCRI Canada shall maintain, or cause to be maintained, sensor evidence records for material sensor methods, sensor sources, reference sensors, telemetry, calibration events, maintenance events, quality reviews, compute workloads, models, dashboards, maps, APIs, Evidence Packs, Decision Packs, public-safe outputs, disputes, incidents, corrections, dependencies, assurance reviews, and closeout events.

9.12.12(b) Sensor evidence records shall identify record title or identifier, source system, source class, sensor class, measurement class, sensor identity where safe, provider where any, operator where any, host where any, public authority context where any, community context where any, technology domain, risk domain, data class, evidence class, output class, access class, handling class, public-safe status, privacy status, cybersecurity status, sovereign data status, infrastructure-sensitive status, public authority status, finance-sensitive status, provider-sensitive status, sponsor-sensitive status, operator-sensitive status, host-sensitive status, community-protected status, Indigenous or protected knowledge status, legal sensitivity, export-control sensitivity, sanctions sensitivity, permitted uses, prohibited uses, publication limits, and correction path.

9.12.12(c) Calibration records shall identify calibration status, calibration method, calibration date, calibration interval, calibration actor, calibration authority where any, reference sensor relationship where any, calibration uncertainty, calibration conditions, failed calibration, overdue calibration, drift status, configuration relationship, maintenance relationship, confidence effect, uncertainty effect, limitation effect, and correction path.

9.12.12(d) Maintenance records shall identify maintenance date, maintenance actor, maintenance purpose, configuration changes, firmware or software changes, hardware changes, placement changes, access events, known defects, repair status, replacement status, decommissioning status where any, and correction effects.

9.12.12(e) Quality records shall identify data quality, completeness, missing data, duplicate data, stale data, outliers, noise, interference, drift, timing quality, location quality, calibration quality, source independence, corroboration status, contradiction status, fusion status, public-safe status, confidence, uncertainty, limitations, and correction path.

9.12.12(f) Incident records shall identify sensor failure, reference sensor failure, calibration failure, maintenance failure, configuration defect, firmware or software issue, timing defect, location defect, data leakage, unauthorized access, unauthorized retrieval, unauthorized embedding, signal spoofing, sensor tamper, telemetry tamper, cyber event, model incident, dashboard error, map error, API error, public-safe defect, public authority overclaim, finance overclaim, procurement implication, provider preference, sponsor validation, operator-control implication, host approval implication, protected knowledge exposure, privacy incident, sovereign data issue, export-control issue, sanctions issue, or correction failure affecting sensor evidence.

9.12.12(g) Correction records shall identify corrected source, corrected sensor identity, corrected calibration status, corrected maintenance status, corrected configuration status, corrected firmware or software status, corrected timing status, corrected location treatment, corrected data quality, corrected noise or interference treatment, corrected spoof-risk treatment, corrected fusion method, corrected dataset, corrected method, corrected compute workload, corrected model, corrected dashboard, corrected map, corrected API, corrected public-safe output, corrected public authority reference, corrected provider reference, corrected sponsor reference, corrected host reference, corrected operator reference, corrected community reference, prior status, corrected status, effective date, reviewer, affected dependencies, notice decision, access change, archive treatment, and continuing limitations.

9.12.12(h) Sensor supersession, withdrawal, or retraction records shall be used where sensor evidence or outputs should no longer be used or relied upon because of material error, unsafe disclosure, calibration defect, maintenance defect, configuration defect, signal defect, spoofing defect, timing defect, location defect, cybersecurity defect, public-safe defect, public authority confusion, finance overclaim, procurement implication, provider-preferential framing, sponsor-validation framing, host approval implication, operator-control implication, protected knowledge exposure, privacy defect, sovereign data issue, cross-border defect, infrastructure-risk exposure, or correction failure.

9.12.12(i) Sensor records shall be linked, where applicable, to National Dense Core records, Regional Observatory Cluster records, Cluster records, Hub records, Node records, Hotspot records, AI-RAN records, DePIN records, blockchain or DLT records where applicable, Observatory Methods Register entries, Evidence Register entries, Source Comparison Records, Dataset Register entries, Model Register entries, System Card entries, Benchmark Card entries, Compute Workload Records, Compute Environment Records, Inference Records, Human Review Records, Retrieval and Embedding Records, Proof Receipt Records, Public-Safe Output Records, AI Incident Records, Correction Records, Dependency Records, Truth Engine Records, public authority records, GRF interface records, GRA interface records, Protocol Authority interface records, RNFD records, Nexus Risk Management records, Nexus Rails records, Regional Nexus Consortium records, National Nexus Consortium records, National Company records, Project SPV records, operator records, provider records, sponsor records, host records, community records, university records, Nexus interface records, and public claims records.

9.12.12(j) Sensor evidence records, calibration records, maintenance records, quality records, incident records, public-safe records, correction, supersession, withdrawal, retraction, assurance, retirement, archive, and closeout shall not create certification, recognition, finance-readiness, public authority decision, procurement approval, provider endorsement, sponsor approval, host approval, operator approval, rating, guarantee, public warning, emergency command, telecommunications regulation, spectrum regulation, protocol effect, operational clearance, legal status, market authority, infrastructure operation, deployment approval, national authority, or execution consequence by default.

9.12.12(k) The controlling rule shall be that sensor evidence is trustworthy only when sensor identity, custody, calibration, configuration, maintenance, timing, location, quality, incidents, public-safe treatment, corrections, and dependencies remain recorded with enough precision to protect people, communities, systems, public authorities, markets, and public trust.

### 9.13 Geospatial, Earth Observation, and Public-Safe Mapping Methods

9.13.1 Geospatial Evidence as Observatory Methods Domain.\
9.13.1(a) GCRI Canada shall steward geospatial, Earth observation, remote sensing, location, GIS, mapping, spatial analytics, aerial observation, drone-derived evidence where lawfully and safely used, environmental-layer, infrastructure-layer, community-layer, and public-safe mapping methods as a specialized Observatory methods domain for observing, recording, comparing, interpreting, public-safe summarizing, and correcting spatial evidence.

9.13.1(b) Geospatial evidence methods may support source comparison, environmental evidence, infrastructure evidence, regional hazard evidence, Hotspot evidence, Cluster evidence, Regional Observatory Cluster evidence, National Dense Nexus Core evidence, digital twin inputs, dashboard inputs, Nexus Truth Engine inputs, Nexus Risk Management inputs, GRF inputs, GRA inputs, Protocol Authority inputs, public authority learning, host learning, community learning, provider-neutral technical review, Academy materials, public-safe publication, and correction workflows.

9.13.1(c) Geospatial evidence shall be treated as records-valid, source-lined, license-aware, resolution-aware, timing-aware, location-sensitive, confidence-aware, uncertainty-aware, limitation-aware, privacy-protective, cybersecurity-controlled, public-safe, sovereignty-compatible, community-sensitive, protected-knowledge-sensitive, provider-neutral, sponsor-independent, and correctionable.

9.13.1(d) GCRI Canada’s stewardship of geospatial and public-safe mapping methods shall not make GCRI Canada a land authority, planning authority, environmental regulator, emergency-management actor, public warning issuer, infrastructure operator, surveillance actor, procurement actor, finance actor, certification body, recognition body, Protocol Authority, provider, sponsor, host, National Company, Project SPV, or execution actor by default.

9.13.1(e) Geospatial evidence shall not be treated as accurate, complete, public-safe, authority-bearing, finance-relevant, procurement-relevant, certified, recognized, protocol-effective, operationally cleared, or execution-ready merely because it is high-resolution, satellite-derived, drone-derived, map-visible, dashboard-visible, AI-assisted, public authority-relevant, provider-supplied, sponsor-supported, host-confirmed, widely used, commercially licensed, open data, or consistent with expected patterns.

9.13.1(f) Geospatial evidence methods shall preserve the distinction between location data, map layer, spatial inference, remote sensing output, environmental layer, infrastructure layer, dashboard indicator, public-safe summary, public authority learning material, digital twin input, risk-context evidence, and any authority-bearing decision made by a competent separate actor.

9.13.1(g) Where geospatial evidence is used externally or publicly, GCRI Canada shall preserve controlled vocabulary, source lineage, resolution limits, timing limits, confidence, uncertainty, limitations, public-safe status, safe-location treatment, no-public-warning language, no-emergency-command language, no-public-authority language, no-finance language, no-procurement language, no-certification language, no-recognition language, no-protocol-effect language unless separately created by Protocol Authority, no-provider-endorsement language, no-sponsor-approval language, no-host-approval language, no-infrastructure-operation language, and correction path where material.

9.13.1(h) The controlling rule shall be that geospatial evidence is an Observatory methods domain because place matters, but place-based evidence becomes institutionally usable only when source, resolution, timing, sensitivity, confidence, uncertainty, public-safe treatment, and correction are governed.

***

9.13.2 Earth Observation, Satellite, Remote Sensing, Drone, Aerial, GIS, Location, and Environmental Layers.\
9.13.2(a) GCRI Canada shall steward methods for Earth observation, satellite, remote sensing, drone-derived, aerial, GIS, location, environmental, infrastructure, land-use, climate, hydrological, coastal, wildfire, heat, drought, storm, air quality, ecosystem, biodiversity, built-environment, transportation, energy, WEFH, and other spatial layers used in Observatory evidence.

9.13.2(b) Earth observation and satellite records shall identify source, provider where any, platform where safe and material, sensor class, acquisition date, processing date, spatial resolution, temporal resolution, spectral or measurement context where material, processing level, method, license, permitted use, prohibited use, public-safe status, confidence, uncertainty, limitations, and correction path.

9.13.2(c) Remote sensing records shall identify measurement type, inferred variable, processing method, ground-truth or reference relationship where any, calibration relationship where any, atmospheric or environmental constraints where material, cloud cover or obstruction where material, model use where any, confidence, uncertainty, limitations, and public-safe treatment.

9.13.2(d) Drone and aerial evidence methods shall be used only where lawful, authorized, safe, proportionate, public-safe, and records-valid. Drone or aerial records shall identify authority, operator where any, flight or collection context where lawful and safe, date and time, location or safe-location treatment, altitude or collection geometry where material and safe, sensor type, data classes, privacy sensitivity, infrastructure sensitivity, community sensitivity, public authority sensitivity, protected knowledge sensitivity, and correction path.

9.13.2(e) GIS and location-layer methods shall identify data source, geometry type, coordinate reference system where material, spatial precision, temporal currency, topology quality, attribute quality, license, permissions, data lineage, update cadence, stale-data treatment, safe-location treatment, public-safe status, confidence, uncertainty, limitations, and correction path.

9.13.2(f) Environmental layers shall distinguish direct measurement, modeled layer, interpolated layer, proxy layer, satellite-derived layer, sensor-derived layer, field-verified layer, public authority layer, community layer, Indigenous or protected knowledge layer, provider-supplied layer, sponsor-supplied layer, and public-safe generalized layer.

9.13.2(g) Geospatial and environmental layers shall not be treated as official boundaries, public authority determinations, hazard designations, regulatory maps, procurement zones, investment zones, certified areas, recognized areas, provider markets, sponsor territories, operational zones, deployment zones, or execution instructions by default.

9.13.2(h) The controlling rule shall be that Earth observation, remote sensing, drone, aerial, GIS, location, and environmental layers are admissible into Observatory evidence only when their source, license, resolution, timing, sensitivity, limitations, and correction path are recorded.

***

9.13.3 Resolution, Timing, Source, License, Confidence, Uncertainty, and Fitness-for-Purpose.\
9.13.3(a) GCRI Canada shall steward methods for assessing resolution, timing, source, license, confidence, uncertainty, limitations, and fitness-for-purpose for geospatial, Earth observation, remote sensing, aerial, GIS, location, dashboard, map, and environmental-layer evidence.

9.13.3(b) Resolution methods shall identify spatial resolution, temporal resolution, spectral or measurement resolution where material, attribute resolution, aggregation level, generalization level, safe-location treatment, scale limitations, small-area sensitivity, small-group sensitivity, infrastructure sensitivity, protected-site sensitivity, and public-safe display limits.

9.13.3(c) Timing methods shall identify acquisition time, processing time, publication time, update cadence, stale-data status, seasonal context, event timing, latency, historical status, near-real-time status, forecast or scenario status where applicable, supersession status, and correction path.

9.13.3(d) Source methods shall identify source authority, source provenance, data lineage, processing lineage, custody, source reliability, source independence, source bias, source completeness, source permission, public authority status, provider status, sponsor status, host status, community status, and protected knowledge status.

9.13.3(e) License and permission methods shall identify license terms, open-data status, commercial-use limits, redistribution limits, derivative-work limits, attribution requirements, public-safe release limits, public authority restrictions, community restrictions, Indigenous or protected knowledge restrictions, provider restrictions, sponsor restrictions, export-control sensitivity, sanctions sensitivity, and correction obligations.

9.13.3(f) Confidence methods shall identify the basis for spatial confidence, including source quality, resolution adequacy, temporal currency, calibration where applicable, reference comparison, ground-truth relationship where any, processing method, model use, uncertainty propagation, reviewer status, public-safe status, contradiction status, data-gap status, and correction status.

9.13.3(g) Uncertainty methods shall identify spatial uncertainty, temporal uncertainty, measurement uncertainty, classification uncertainty, model uncertainty, interpolation uncertainty, boundary uncertainty, geocoding uncertainty, projection uncertainty, source uncertainty, public authority uncertainty, community uncertainty, protected knowledge uncertainty, legal uncertainty, and public-safe uncertainty.

9.13.3(h) Fitness-for-purpose methods shall determine whether a geospatial record or map layer is suitable for the recorded use, audience, output class, public-safe status, resolution, timing, sensitivity, confidence, uncertainty, and boundary requirements, and shall prohibit reuse for materially different purposes without review.

9.13.3(i) A geospatial output shall not be treated as fit for public-safe publication, public authority learning, finance-facing use, GRF input, GRA input, Protocol Authority input, provider-facing use, sponsor-facing use, host-facing use, community-facing use, dashboarding, mapping, API exposure, or public claims merely because it is technically available.

9.13.3(j) The controlling rule shall be that a map is only as useful as its source, license, resolution, timing, confidence, uncertainty, limitations, and fitness for the precise purpose for which it is used.

***

9.13.4 Public-Safe Mapping Controls.\
9.13.4(a) GCRI Canada shall apply public-safe mapping controls to all maps, map layers, dashboards, geospatial APIs, geospatial datasets, reports, technical notes, public-safe summaries, Academy materials, public authority learning materials, GRF-facing materials, GRA-facing materials, Protocol Authority-facing materials, provider-facing materials, sponsor-facing materials, host-facing materials, community-facing materials, media materials, repository materials, website materials, and public claims involving geospatial evidence.

9.13.4(b) Public-safe mapping controls shall assess whether a map discloses or enables misuse of personal information, rights-bearing data, household patterns, small-group identifiability, health-sensitive information, cyber-sensitive information, infrastructure-sensitive information, public authority restricted information, sovereign-sensitive information, finance-sensitive information, community-protected information, Indigenous or protected knowledge, confidential source information, privileged material, controlled technology, exploit details, sensitive locations, unsafe metadata, or unsafe geospatial precision.

9.13.4(c) Public-safe mapping controls may require aggregation, generalization, masking, blurring, jittering where appropriate, safe-location treatment, delayed release, omission, controlled annexing, reduced resolution, attribute removal, field suppression, legend revision, label revision, access restriction, no-download treatment, API restriction, or responsible non-disclosure.

9.13.4(d) Map legends, colors, symbols, heatmaps, markers, boundaries, labels, scores, confidence displays, uncertainty displays, classifications, rankings, and layer names shall be reviewed for public warning implication, emergency-command implication, official boundary implication, public authority implication, finance implication, procurement implication, provider preference, sponsor validation, host approval implication, community stigma, false precision, and overclaim.

9.13.4(e) Public-safe maps shall include, where material, public-safe omissions, responsible non-disclosure basis, confidence, uncertainty, limitations, stale-data treatment, contradiction status, data-gap status, safe-location statement, permitted use, prohibited use, no-public-warning language, no-emergency-command language, no-public-authority language, no-finance language, no-procurement language, no-certification language, no-recognition language, no-protocol-effect language, no-provider-endorsement language, no-sponsor-approval language, no-host-approval language, and correction path.

9.13.4(f) Public-safe mapping controls shall apply not only to published static maps but also to interactive maps, dashboards, APIs, downloadable layers, screenshots, exports, embedded maps, public repositories, event presentations, media graphics, social summaries, translations, and derivative visualizations.

9.13.4(g) Where a geospatial output cannot be made public-safe without distorting evidence, erasing uncertainty, concealing contradiction, exposing restricted data, exposing protected knowledge, creating public warning implication, creating public authority implication, creating finance overclaim, creating procurement implication, creating community harm, or creating unauthorized authority, GCRI Canada may use controlled-room review, controlled annexes, restricted maps, aggregation, generalization, safe-location treatment, delayed release, responsible non-disclosure, limited public-safe statement, or no-publication treatment.

9.13.4(h) The controlling rule shall be that public-safe mapping must make spatial evidence understandable without making people, places, infrastructure, communities, public authorities, providers, hosts, sponsors, or markets unsafe or overclaimed.

***

9.13.5 Infrastructure-Sensitive, Cultural-Site, Protected-Knowledge, Vulnerable-Community, and Environmental Sensitivity Controls.\
9.13.5(a) GCRI Canada shall apply heightened sensitivity controls to geospatial evidence involving infrastructure-sensitive locations, cyber-physical dependencies, cultural sites, sacred sites, protected sites, environmental knowledge, traditional ecological knowledge, vulnerable communities, remote communities, small communities, critical habitats, species-sensitive locations, public authority restricted locations, host-sensitive locations, provider-sensitive locations, operator-sensitive locations, and other sensitive spatial contexts.

9.13.5(b) Infrastructure-sensitive controls shall identify whether maps or layers reveal critical infrastructure, facility locations, service dependencies, network topology, outage sensitivity, degraded-mode sensitivity, security controls, vulnerability-sensitive information, logistics dependencies, corridor sensitivity, operator-sensitive information, cyber-sensitive information, or physical security risk.

9.13.5(c) Cultural-site and protected-knowledge controls shall identify whether geospatial evidence may reveal Indigenous, cultural, spiritual, sacred, archaeological, ecological, ceremonial, territorial, or protected knowledge locations, whether precise mapping is prohibited or unsafe, and whether community protocols, Indigenous protocols, consent or non-consent treatment, challenge pathways, withdrawal pathways, or responsible non-disclosure are required.

9.13.5(d) Vulnerable-community controls shall identify whether geospatial evidence may stigmatize, expose, target, surveil, displace, exploit, or otherwise harm communities, residents, workers, households, migrants, remote populations, underserved populations, or vulnerable persons.

9.13.5(e) Environmental sensitivity controls shall identify whether maps may expose critical habitats, endangered species locations, restoration sites, water sources, sensitive ecosystems, traditional ecological knowledge, conservation-sensitive areas, contamination-sensitive contexts, or environmental vulnerabilities in a manner that increases harm.

9.13.5(f) Sensitive spatial evidence shall not be mapped, publicized, API-exposed, embedded, retrieved, trained on, downloaded, or shared externally without review proportionate to infrastructure, cultural-site, protected-knowledge, vulnerable-community, environmental, privacy, cybersecurity, public authority, sovereign data, and public-safe risks.

9.13.5(g) Where sensitivity controls identify unacceptable risk, GCRI Canada shall restrict access, generalize location, remove layers, suppress attributes, use safe-location treatment, withhold publication, use controlled annexes, require controlled-room review, issue limited public-safe statements, or refuse use.

9.13.5(h) Where sensitivity-control failures occur, GCRI Canada shall restrict access, correct classification, remove unsafe materials, withdraw or revise outputs, notify affected interfaces where appropriate, review harms, update safeguards, and review dependencies.

9.13.5(i) The controlling rule shall be that maps can expose what communities, ecosystems, infrastructure, and knowledge systems need protected; therefore sensitive place-based evidence must be safeguarded before it is displayed.

***

9.13.6 Re-Identification and Group Harm Risk Controls.\
9.13.6(a) GCRI Canada shall apply re-identification and group harm risk controls to geospatial evidence, location data, maps, dashboards, APIs, datasets, public-safe summaries, and derivative outputs where spatial evidence may identify, infer, target, stigmatize, expose, or otherwise harm individuals, households, small groups, communities, workers, facilities, hosts, operators, or protected knowledge holders.

9.13.6(b) Re-identification risk controls shall assess whether geospatial records, even when stripped of direct identifiers, may reveal identity through location, time, movement, pattern, small counts, rare attributes, household-level detail, workplace-level detail, facility-level detail, route-level detail, device relationships, sensor relationships, public records, external datasets, dashboard filters, map drill-downs, API fields, or combined data sources.

9.13.6(c) Group harm controls shall assess whether maps or spatial summaries may create stigma, panic, false reassurance, public blame, economic harm, insurance harm, finance harm, surveillance risk, enforcement risk, retaliation risk, displacement risk, extraction risk, community conflict, media overclaim, or political misuse.

9.13.6(d) Controls may require aggregation thresholds, small-cell suppression, safe-location treatment, coarser geographies, delayed release, generalized labels, removal of sensitive attributes, controlled access, no-download treatment, public-safe explanatory notes, community review where appropriate, public authority reference controls, and correction paths.

9.13.6(e) AI, geospatial analytics, dashboards, maps, and APIs shall not be used to infer sensitive attributes, identify groups, rank communities, rank hosts, score regions, predict public authority action, infer finance value, infer insurance value, infer procurement value, or imply risk status in a manner inconsistent with public-safe discipline, rights protection, community safeguards, or boundary controls.

9.13.6(f) Public-safe mapping shall not conceal uncertainty, contradiction, data gaps, proxy limitations, or public-safe omissions in a manner that falsely reassures or falsely alarms affected people or communities.

9.13.6(g) Where re-identification or group harm risks are detected after release, GCRI Canada shall restrict access, remove or revise maps, suppress fields, generalize outputs, issue public-safe or controlled correction where appropriate, notify affected interfaces where required, and review dependencies.

9.13.6(h) The controlling rule shall be that geospatial public benefit is defeated if maps allow people or communities to be re-identified, targeted, stigmatized, exploited, or harmed.

***

9.13.7 Geospatial Integration With Digital Twins, Dashboards, Truth Engine, and Nexus Risk Management.\
9.13.7(a) GCRI Canada may steward geospatial integration methods with digital twins, simulations, dashboards, maps, APIs, Nexus Truth Engine, Nexus Risk Management, Observatory Nodes, Hubs, Clusters, Hotspots, Regional Observatory Clusters, National Dense Nexus Cores, Verifiable Compute records, Verifiable Intelligence outputs, Evidence Packs, Decision Packs, GRF inputs, GRA inputs, Protocol Authority inputs, Academy materials, public-good software, technical baselines, and correction records.

9.13.7(b) Integration methods shall identify integration purpose, source systems, receiving systems, data classes, evidence classes, output classes, geospatial source lineage, processing lineage, method version, model version where applicable, compute workload, compute environment, access class, handling class, public-safe status, confidence, uncertainty, limitations, permitted flows, prohibited flows, permitted uses, prohibited uses, and correction path.

9.13.7(c) Digital twin and simulation integration shall identify scenario, assumptions, source layers, spatial resolution, temporal resolution, model version, calibration status, validation status, sensitivity analysis where material, uncertainty propagation, limitation treatment, public-safe status, and prohibition on presenting modeled or simulated spatial outputs as observed fact.

9.13.7(d) Dashboard and map integration shall identify field meaning, layer meaning, schema meaning, update cadence, stale-data treatment, confidence display, uncertainty display, limitation display, legend meaning, color meaning, marker meaning, geospatial precision, safe-location treatment, export controls, API exposure, downstream reuse limits, public-safe status, and correction propagation.

9.13.7(e) Nexus Truth Engine integration shall preserve source comparison records, corroboration records, contradiction records, dispute records, confidence records, uncertainty records, inference records where applicable, human review records where material, public-safe review records, dependency links, and correction paths.

9.13.7(f) Nexus Risk Management integration shall preserve the distinction between risk evidence and risk command. Geospatial evidence may support risk learning, resilience learning, degraded-mode learning, scenario learning, and public-safe interpretation, but shall not make GCRI Canada the risk manager, emergency commander, infrastructure operator, public authority, finance actor, procurement actor, provider, sponsor, host, or execution actor for downstream systems.

9.13.7(g) Integration shall not create legal merger, system merger, public authority status, public warning, emergency command, procurement approval, finance-readiness, certification, recognition, protocol effect, provider preference, sponsor approval, host approval, operator instruction, operational clearance, infrastructure operation, deployment approval, market authority, or execution consequence by default.

9.13.7(h) Where integration defects are identified, including schema mismatch, projection mismatch, timestamp mismatch, location mismatch, layer mismatch, model mismatch, confidence mismatch, public-safe mismatch, permission mismatch, cybersecurity defect, privacy defect, sovereign-data defect, protected-knowledge defect, re-identification risk, group harm risk, or correction mismatch, GCRI Canada shall record the mismatch and correct, qualify, restrict, re-map, reclassify, supersede, or refuse the affected integration path as appropriate.

9.13.7(i) The controlling rule shall be that geospatial integration can strengthen systems understanding only where it preserves source meaning, spatial limits, safeguards, boundaries, and correctionability.

***

9.13.8 Public Authority and Community Review Where Required.\
9.13.8(a) GCRI Canada shall require public authority review, community review, Indigenous protocol review, protected knowledge review, host review, operator review, legal review, safeguards review, or public-safe review where geospatial evidence or mapping may materially affect public authority interpretation, community safety, protected knowledge, infrastructure sensitivity, public-safe communication, or downstream reliance.

9.13.8(b) Public authority review shall be used where maps or spatial outputs involve public authority data, public authority restricted materials, regulator-listening contexts, emergency-management contexts, public health contexts, public safety contexts, procurement contexts, public finance contexts, agency references, jurisdictional references, or materials likely to be misread as official public authority status.

9.13.8(c) Public authority review shall preserve capacity classification, official or non-official status, data-sharing terms, publication limits, agency reference controls, non-delegation language, non-endorsement language, non-regulatory language, non-procurement language, non-funding language, non-public-finance language, no-public-warning language, no-emergency-command language, and correction path.

9.13.8(d) Community and Indigenous review shall be used where maps or spatial outputs involve community-identifiable information, community-protected information, Indigenous or protected knowledge, territorial context, cultural context, environmental knowledge, sensitive sites, small communities, vulnerable communities, or plausible group harm.

9.13.8(e) Community and Indigenous review shall preserve consent or non-consent treatment where applicable, community protocols, Indigenous protocols where applicable, source protection, sensitive-site treatment, public-safe mapping limits, challenge pathways, withdrawal pathways where applicable, accessibility, translation, localization, non-extraction, non-commodification, and do-no-harm controls.

9.13.8(f) Review under this section shall not convert participation, review, silence, comments, data contribution, map review, dashboard access, public authority attendance, community attendance, host participation, operator participation, provider participation, or sponsor support into endorsement, approval, consent, waiver, public authority decision, public warning, finance-readiness, procurement approval, certification, recognition, provider preference, sponsor approval, host approval, operator approval, protocol effect, or execution permission by implication.

9.13.8(g) Where required review cannot be completed safely, lawfully, or without compromising protected knowledge, public authority restrictions, privacy, cybersecurity, sovereign data, or public-safe discipline, GCRI Canada may restrict use, use controlled annexes, generalize outputs, delay release, provide limited public-safe statements, or refuse publication.

9.13.8(h) The controlling rule shall be that public authority and community review may be required to protect meaning and safety, but review is not approval unless a competent actor separately creates approval through its own lawful record.

***

9.13.9 Maps Do Not Create Public Warnings, Public Authority Decisions, Regulatory Determinations, or Procurement Effects by Default.\
9.13.9(a) No map, geospatial record, Earth observation record, satellite record, remote sensing record, drone-derived record, aerial record, GIS layer, location layer, environmental layer, dashboard map, API layer, Evidence Pack map, Decision Pack map, public-safe map, technical note, report, public claim, correction signal, or Proof Receipt shall create public warning, public authority decision, regulatory determination, procurement effect, finance-readiness, certification, recognition, protocol effect, provider preference, sponsor approval, host approval, operator approval, infrastructure operation, operational clearance, legal status, market authority, deployment approval, or execution consequence by default.

9.13.9(b) Maps shall not issue or imply official guidance, hazard designation, evacuation instruction, emergency command, public safety directive, public health order, land-use decision, zoning decision, environmental compliance determination, enforcement position, safe harbor, permit, license, procurement decision, vendor award, funding approval, public finance approval, investment advice, lending decision, underwriting decision, insurance approval, rating, guarantee, certification, recognition, maturity record, claims approval, conformance determination, Nexus-compatible status, provider ranking, sponsor finding, host approval, operator instruction, deployment authorization, operational clearance, or market signal.

9.13.9(c) Public authority data, public authority attendance, community participation, Indigenous participation, host participation, operator participation, provider participation, sponsor support, dashboard visibility, map visibility, benchmark success, Proof Receipt issuance, GRF interface use, GRA interface use, Protocol Authority interface use, National Company relevance, Project SPV relevance, or media interest shall not convert maps into authority.

9.13.9(d) Any authority-bearing action by a public authority, GRF, GRA, Protocol Authority, National Nexus Consortium, Regional Nexus Consortium, National Company, Project SPV, provider, sponsor, host, operator, finance actor, procurement actor, infrastructure actor, university, community, Indigenous governance body where applicable, or other actor shall arise only through that actor’s own lawful authority, process, record, accountability, and liability, not through geospatial evidence or maps by implication.

9.13.9(e) Geospatial materials shall include boundary language where material to prevent interpretation as public authority action, public warning, emergency command, regulatory determination, procurement action, finance-readiness, public finance approval, certification, recognition, maturity, claims approval, protocol effect, provider preference, sponsor approval, host approval, operator approval, operational clearance, infrastructure operation, legal status, professional advice, market signal, deployment approval, or execution instruction.

9.13.9(f) Where geospatial materials are misused to imply unauthorized authority, GCRI Canada shall correct, relabel, restrict, withdraw, reissue, require removal of misleading references, notify affected interfaces where appropriate, suspend affected interface use, or pursue contractual or legal remedies where appropriate.

9.13.9(g) No ambiguity shall be resolved in favour of map authority. Where there is doubt whether a map creates authority or only supports evidence, the interpretation preserving GCRI Canada’s non-execution role, public authority boundaries, finance boundaries, procurement neutrality, provider neutrality, sponsor non-control, host boundaries, operator boundaries, community safeguards, Indigenous safeguards, Protocol Authority role separation, GRF role separation, GRA role separation, validity-by-record, correctionability, and public trust shall prevail.

9.13.9(h) The controlling rule shall be that maps show evidence; they do not warn, command, regulate, procure, finance, certify, recognize, approve, operate, or execute by default.

***

9.13.10 Geospatial Records, Map Versioning, Correction, Withdrawal, and Public-Safe Notices.\
9.13.10(a) GCRI Canada shall maintain, or cause to be maintained, geospatial records for material geospatial methods, Earth observation sources, satellite sources, remote sensing sources, drone-derived sources, aerial sources, GIS layers, location layers, environmental layers, dashboards, maps, APIs, Evidence Packs, Decision Packs, public-safe outputs, disputes, incidents, corrections, dependencies, assurance reviews, and closeout events.

9.13.10(b) Geospatial records shall identify record title or identifier, source system, source class, layer class, geometry class where applicable, provider where any, operator where any, host where any, public authority context where any, community context where any, Indigenous or protected knowledge context where any, technology domain, risk domain, data class, evidence class, output class, access class, handling class, public-safe status, privacy status, cybersecurity status, sovereign data status, infrastructure-sensitive status, public authority status, finance-sensitive status, provider-sensitive status, sponsor-sensitive status, operator-sensitive status, host-sensitive status, community-protected status, Indigenous or protected knowledge status, legal sensitivity, license status, export-control sensitivity, sanctions sensitivity, permitted uses, prohibited uses, publication limits, and correction path.

9.13.10(c) Map versioning records shall identify map title or identifier, layer versions, source versions, schema versions, projection or coordinate reference system where material, processing method, update date, release date, public-safe review status, confidence display, uncertainty display, limitation display, stale-data treatment, boundary language, access class, publication status, supersession status, withdrawal status where applicable, retraction status where applicable, and archive status.

9.13.10(d) Geospatial quality records shall identify spatial accuracy, temporal accuracy, attribute quality, completeness, missing data, duplicate data, stale data, classification quality, interpolation quality, model quality where applicable, geocoding quality, projection quality, source independence, corroboration status, contradiction status, public-safe status, confidence, uncertainty, limitations, and correction path.

9.13.10(e) Incident records shall identify unsafe disclosure, unsafe geospatial precision, re-identification risk, group harm risk, protected knowledge exposure, sensitive-site exposure, infrastructure exposure, cyber-sensitive exposure, public authority overclaim, finance overclaim, procurement implication, provider preference, sponsor validation, operator-control implication, host approval implication, community harm risk, privacy incident, sovereign data issue, license breach, export-control issue, sanctions issue, dashboard error, map error, API error, or correction failure affecting geospatial evidence.

9.13.10(f) Correction records shall identify corrected source, corrected layer, corrected geometry, corrected attribute, corrected projection, corrected location treatment, corrected safe-location treatment, corrected resolution, corrected timestamp, corrected license status, corrected dataset, corrected method, corrected compute workload, corrected model, corrected dashboard, corrected map, corrected API, corrected public-safe output, corrected public authority reference, corrected provider reference, corrected sponsor reference, corrected host reference, corrected operator reference, corrected community reference, corrected protected knowledge treatment, prior status, corrected status, effective date, reviewer, affected dependencies, notice decision, access change, archive treatment, and continuing limitations.

9.13.10(g) Withdrawal or retraction records shall be used where geospatial evidence or maps should no longer be used or relied upon because of material error, unsafe disclosure, resolution defect, location defect, timing defect, license defect, source defect, public-safe defect, protected knowledge exposure, community harm risk, public authority confusion, finance overclaim, procurement implication, provider-preferential framing, sponsor-validation framing, host approval implication, operator-control implication, privacy defect, sovereign data issue, cross-border defect, infrastructure-risk exposure, regulatory overclaim, or correction failure.

9.13.10(h) Public-safe notices shall be issued or controlled notices shall be given where corrected, withdrawn, retracted, superseded, or restricted maps materially affect external understanding, public-safe outputs, public authority learning materials, GRF inputs, GRA inputs, Protocol Authority inputs, provider-facing materials, sponsor-facing materials, host-facing materials, community-facing materials, Academy materials, media materials, repositories, dashboards, APIs, or public claims.

9.13.10(i) Geospatial records shall be linked, where applicable, to National Dense Core records, Regional Observatory Cluster records, Cluster records, Hub records, Node records, Hotspot records, AI-RAN records, DePIN records, sensor records, digital twin records, Observatory Methods Register entries, Evidence Register entries, Source Comparison Records, Dataset Register entries, Model Register entries, System Card entries, Benchmark Card entries, Compute Workload Records, Compute Environment Records, Inference Records, Human Review Records, Retrieval and Embedding Records, Proof Receipt Records, Public-Safe Output Records, AI Incident Records, Correction Records, Dependency Records, Truth Engine Records, Nexus Risk Management records, public authority records, GRF interface records, GRA interface records, Protocol Authority interface records, RNFD records, Nexus Rails records, Regional Nexus Consortium records, National Nexus Consortium records, National Company records, Project SPV records, operator records, provider records, sponsor records, host records, community records, university records, Nexus interface records, and public claims records.

9.13.10(j) Geospatial records, map versioning records, quality records, incident records, public-safe records, correction, supersession, withdrawal, retraction, assurance, retirement, archive, notices, and closeout shall not create certification, recognition, finance-readiness, public authority decision, procurement approval, provider endorsement, sponsor approval, host approval, operator approval, rating, guarantee, public warning, emergency command, regulatory determination, protocol effect, operational clearance, legal status, market authority, infrastructure operation, deployment approval, national authority, regional authority, or execution consequence by default.

9.13.10(k) The controlling rule shall be that geospatial evidence and maps are trustworthy only when source, license, resolution, timing, sensitivity, public-safe treatment, versioning, correction, withdrawal, and notices remain recorded with enough precision to protect people, places, communities, public authorities, infrastructure, ecosystems, markets, and public trust.

### 9.14 Cyber-Physical and Cyber Telemetry Methods

9.14.1 Cyber-Physical Evidence as Observatory Methods Domain.\
9.14.1(a) GCRI Canada shall steward cyber-physical and cyber telemetry evidence methods as a specialized Observatory methods domain for identifying, receiving, classifying, comparing, interpreting, public-safe summarizing, and correcting evidence arising from cyber-physical systems, operational technology, industrial control systems, critical infrastructure systems, telecommunications-adjacent systems, sensor networks, AI-RAN systems, O-RAN systems, private wireless systems, DePIN systems, edge compute systems, digital twins, dashboards, maps, APIs, logs, alerts, vulnerability signals, incident telemetry, anomaly records, and related observability contexts.

9.14.1(b) Cyber-physical evidence methods may support source comparison, anomaly interpretation, degraded-mode learning, infrastructure-context learning, cyber-risk learning, public authority learning, host learning, operator learning, provider-neutral technical review, National Dense Nexus Core evidence, Regional Observatory Cluster evidence, Hub evidence, Node evidence, Hotspot evidence, Nexus Truth Engine inputs, Nexus Risk Management inputs, Verifiable Compute records, Verifiable Intelligence outputs, Evidence Packs, Decision Packs, public-safe outputs, GRF inputs, GRA inputs, Protocol Authority inputs, National Company evidence interfaces, Project SPV evidence interfaces, Academy materials, and correction workflows.

9.14.1(c) Cyber-physical evidence shall be treated as records-valid, source-lined, custody-aware, timestamp-aware, chain-of-handling-aware, integrity-aware, vulnerability-sensitive, incident-sensitive, privacy-protective, cybersecurity-controlled, public-safe, sovereignty-compatible, export-control-aware, sanctions-aware, controlled-technology-aware, provider-neutral, sponsor-independent, and correctionable.

9.14.1(d) GCRI Canada’s stewardship of cyber-physical and cyber telemetry methods shall not make GCRI Canada a cybersecurity operator, security operations centre, managed security service provider, critical infrastructure operator, law enforcement body, regulator, emergency-management actor, public warning issuer, incident commander, certification body, procurement actor, finance actor, Protocol Authority, provider, sponsor, host, operator, National Company, Project SPV, or execution actor by default.

9.14.1(e) Cyber-physical evidence shall not be treated as accurate, complete, public-safe, authority-bearing, regulatory, law-enforcement-ready, procurement-relevant, finance-relevant, certified, recognized, protocol-effective, operationally cleared, or execution-ready merely because it is machine-generated, continuous, real-time, high-volume, cryptographically logged, provider-supplied, operator-supplied, public authority-relevant, sponsor-supported, dashboard-visible, map-visible, AI-assisted, threat-intelligence-adjacent, or technically sophisticated.

9.14.1(f) Cyber-physical methods shall preserve the distinction between cyber signal, log entry, alert, vulnerability signal, incident telemetry, anomaly indicator, forensic artifact, operator context, provider statement, public authority context, model output, dashboard indicator, map layer, public-safe summary, public authority learning material, risk-management input, and any authority-bearing decision made by a competent separate actor.

9.14.1(g) Where cyber-physical evidence is used externally or publicly, GCRI Canada shall preserve controlled vocabulary, source lineage, chain of handling, confidence, uncertainty, limitations, cyber-sensitive classification, public-safe status, no-public-warning language, no-emergency-command language, no-law-enforcement-authority language, no-regulatory-finding language, no-public-authority language, no-finance language, no-procurement language, no-security-certification language, no-provider-endorsement language, no-sponsor-approval language, no-operator-instruction language, no-infrastructure-operation language, and correction path where material.

9.14.1(h) The controlling rule shall be that cyber-physical evidence is an Observatory methods domain for making cyber and infrastructure conditions more intelligible as evidence, not for making GCRI Canada a cyber operator, regulator, law enforcement actor, emergency commander, certifier, procurement approver, warning issuer, or execution authority.

***

9.14.2 Operational Technology, Industrial Control Systems, Critical Infrastructure Systems, Logs, Alerts, Vulnerability Signals, and Incident Telemetry.\
9.14.2(a) GCRI Canada shall steward methods for cyber-physical evidence arising from operational technology, industrial control systems, supervisory control and data acquisition systems, distributed control systems, programmable logic controllers, building management systems, industrial internet systems, utility systems, port systems, corridor systems, telecommunications systems, AI-RAN systems, O-RAN systems, private wireless systems, energy systems, water systems, transportation systems, manufacturing systems, semiconductor facilities, logistics systems, cyber-physical sensors, and other critical or mission-critical systems.

9.14.2(b) Operational technology and industrial control evidence records shall identify, where safe and material, system class, asset class, operator context, host context, provider context, public authority relevance, network context, telemetry source, log source, alert source, vulnerability signal source, incident telemetry source, timestamp, chain of handling, data class, evidence class, access class, handling class, cyber-sensitive status, infrastructure-sensitive status, public-safe status, confidence, uncertainty, limitations, and correction path.

9.14.2(c) Logs and alerts may include access logs, authentication logs, authorization logs, network logs, application logs, device logs, sensor logs, firewall logs, intrusion detection or prevention alerts, endpoint alerts, telemetry streams, anomaly records, configuration records, patch status records, vulnerability scan records, asset inventory records, incident tickets, operator observations, provider security materials, and public-safe summaries, provided that such materials are classified and handled according to risk.

9.14.2(d) Vulnerability signals shall be treated as sensitive evidence. Vulnerability evidence shall identify source, affected system class where safe, severity method where any, exploitability context where safe, affected dependency where safe, patch or mitigation status where known, public-safe disclosure limits, responsible disclosure path, confidence, uncertainty, limitations, and correction path.

9.14.2(e) Incident telemetry shall identify incident type, detection source, affected system class where safe, affected data class, affected environment, affected operator or host context where applicable, timeline, containment status where known, public-safe disclosure limits, confidence, uncertainty, limitations, and correction path.

9.14.2(f) Cyber-physical methods shall distinguish observed telemetry, inferred compromise, suspected anomaly, confirmed incident, vulnerability signal, exploit evidence, misconfiguration evidence, degraded-mode evidence, operational context, public authority context, provider-supplied statement, operator-supplied statement, host-supplied statement, and public-safe communication.

9.14.2(g) Cyber-physical evidence concerning operational technology, industrial control systems, critical infrastructure systems, logs, alerts, vulnerability signals, or incident telemetry shall not be used as public warning, emergency command, operator instruction, regulatory finding, law enforcement referral, procurement approval, finance-readiness, security certification, provider endorsement, sponsor approval, operational clearance, infrastructure command, or execution instruction by default.

9.14.2(h) The controlling rule shall be that operational technology and cyber telemetry may support learning and evidence, but their sensitivity requires careful classification, redaction, chain of handling, public-safe treatment, and correction.

***

9.14.3 Cyber-Sensitive Evidence Classification and Handling.\
9.14.3(a) GCRI Canada shall classify and handle cyber-sensitive evidence according to the sensitivity of the system, data, vulnerability, incident, actor context, public authority context, infrastructure context, provider context, host context, operator context, community context, public-safe risk, and downstream misuse risk.

9.14.3(b) Cyber-sensitive evidence classification shall identify whether materials include credentials, keys, tokens, secrets, authentication details, authorization details, network topology, system architecture, asset inventory, vulnerability details, exploit details, malware indicators, incident details, security controls, configuration details, patch status, telemetry, logs, source code, dependency records, model prompts or queries where security-sensitive, threat-intelligence-adjacent materials, or other sensitive cyber information.

9.14.3(c) Handling classes shall define access restrictions, room requirements, no-download requirements, copy restrictions, print restrictions, screenshot restrictions, export restrictions, API restrictions, retrieval restrictions, embedding restrictions, AI-use restrictions, vendor-processing restrictions, public AI tool restrictions, redaction requirements, retention requirements, sealing requirements, deletion requirements, archive requirements, and correction paths.

9.14.3(d) Cyber-sensitive evidence shall be accessed only by authorized persons with a recorded purpose, appropriate capacity, least-privilege access, confidentiality obligations, conflict disclosure where material, logging, monitoring, and revocation path.

9.14.3(e) Cyber-sensitive evidence shall not be embedded, retrieved, trained on, fine-tuned on, summarized through public AI tools, shared with providers, shared with sponsors, routed to finance-facing contexts, routed to public authority contexts, dashboarded, mapped, API-exposed, or published without express recorded authority and safeguards proportionate to risk.

9.14.3(f) Cyber-sensitive classification shall account for aggregation risk. Materials that appear low-risk in isolation may become sensitive when combined with geospatial data, sensor data, operator context, public authority context, host context, provider context, vulnerability information, infrastructure dependencies, or timing information.

9.14.3(g) Where cyber-sensitive materials are misclassified, over-shared, mishandled, exposed, routed incorrectly, embedded improperly, retrieved improperly, published unsafely, or retained beyond permitted limits, GCRI Canada shall restrict access, correct classification, contain exposure, delete or seal records where appropriate, notify affected interfaces where required, review affected outputs, and update controls.

9.14.3(h) The controlling rule shall be that cyber-sensitive evidence must be classified by what harm it could enable, not merely by whether it appears technical, public, or already known.

***

9.14.4 Vulnerability Disclosure, Coordinated Disclosure, Redaction, and Public-Safe Publication.\
9.14.4(a) GCRI Canada shall steward vulnerability disclosure, coordinated disclosure, redaction, responsible non-disclosure, controlled notice, public-safe publication, and correction methods for cyber-physical and cyber telemetry evidence where vulnerability information, exploit-sensitive information, incident-adjacent information, or infrastructure-sensitive information may affect public safety, cybersecurity, public authorities, operators, hosts, providers, communities, or markets.

9.14.4(b) Vulnerability disclosure methods shall identify vulnerability source, affected system class where safe, affected actor category where safe, severity method where any, exploitability context where safe, mitigation context where known, public-safe publication limits, disclosure audience, notice path, legal review where appropriate, public authority review where appropriate, provider or operator notice where appropriate, and correction path.

9.14.4(c) Coordinated disclosure methods may include controlled notice to affected operators, hosts, providers, public authorities, National Companies, Project SPVs, or other competent actors where lawful, safe, proportionate, and consistent with GCRI Canada’s non-executing role. Such notice shall not constitute command, legal finding, compliance determination, enforcement referral, public warning, certification, endorsement, or operational instruction by GCRI Canada.

9.14.4(d) Redaction methods shall remove, generalize, aggregate, delay, or restrict details that could enable exploitation, targeting, re-identification, infrastructure harm, community harm, public authority misuse, provider misuse, sponsor misuse, market overclaim, or public panic.

9.14.4(e) Public-safe cyber publication shall avoid disclosure of exploit steps, working exploit code, credentials, secrets, keys, tokens, security control details, sensitive topology, exposed systems, precise vulnerable locations, unmitigated vulnerability details, incident details, or other materials that could increase harm.

9.14.4(f) Public-safe cyber outputs shall include, where material, responsible non-disclosure basis, confidence, uncertainty, limitations, stale-data treatment, correction status, no-public-warning language, no-emergency-command language, no-regulatory-finding language, no-law-enforcement-authority language, no-public-authority language, no-procurement language, no-security-certification language, no-provider-endorsement language, no-sponsor-approval language, permitted use, prohibited use, and correction path.

9.14.4(g) Where public-safe publication is unsafe, premature, misleading, legally restricted, cyber-risk-increasing, infrastructure-risk-increasing, public authority-confusing, provider-preferential, sponsor-validating, or correction-defective, GCRI Canada shall use controlled annexes, controlled rooms, restricted notices, delayed publication, aggregation, generalization, responsible non-disclosure, limited public-safe statements, or no-publication treatment.

9.14.4(h) Where vulnerability disclosure or public-safe publication is later found inaccurate, unsafe, stale, overbroad, overclaimed, or incomplete, GCRI Canada shall correct, restrict, supersede, withdraw, retract where appropriate, notify affected interfaces where appropriate, and review dependencies.

9.14.4(i) The controlling rule shall be that cyber disclosure must improve public-good learning without increasing vulnerability, exploitation, panic, unauthorized authority, or execution risk.

***

9.14.5 Cyber Telemetry Source Lineage, Custody, Integrity, Timestamping, and Chain of Handling.\
9.14.5(a) GCRI Canada shall steward source lineage, custody, integrity, timestamping, chain-of-handling, log-preservation, evidence-integrity, tamper-evidence, and correction methods for cyber telemetry and cyber-physical evidence.

9.14.5(b) Source lineage records shall identify telemetry source, log source, alert source, system class, operator context where any, host context, provider context, public authority context where any, source authority, source permission, source version, collection method, extraction method, transformation method, public-safe status, confidence, uncertainty, limitations, and correction path.

9.14.5(c) Custody records shall identify data custodian, system custodian, log custodian, source custodian, evidence custodian, compute custodian, reviewer, output custodian, access administrator, key custodian where applicable, correction custodian, and any transfer of custody.

9.14.5(d) Integrity records shall identify hash status where appropriate, signature status where appropriate, timestamp status, tamper-evidence where appropriate, log completeness, log gaps, clock drift, time synchronization, sequence integrity, replay risk, duplicate records, missing records, chain break, transformation steps, redaction steps, and integrity limitations.

9.14.5(e) Timestamping methods shall identify timestamp source, time zone treatment, clock synchronization, collection time, event time, processing time, publication time, latency, stale-data status, delayed telemetry, missing intervals, and correction path.

9.14.5(f) Chain-of-handling records shall identify each material transfer, access, extraction, transformation, redaction, computation, review, classification, publication, correction, sealing, deletion, archive, or closeout action affecting cyber telemetry.

9.14.5(g) Cyber telemetry shall not be treated as forensic proof, law enforcement evidence, regulatory evidence, compliance evidence, certification evidence, public warning evidence, procurement evidence, finance evidence, or execution evidence by default merely because chain-of-handling records exist.

9.14.5(h) Where source lineage, custody, integrity, timestamping, or chain-of-handling defects are detected, GCRI Canada shall qualify, downgrade, restrict, correct, supersede, withdraw, seal, archive, or refuse affected evidence or outputs as appropriate.

9.14.5(i) The controlling rule shall be that cyber telemetry is trustworthy only when the institution can show where it came from, who handled it, whether it changed, when it happened, what limits apply, and how it can be corrected.

***

9.14.6 Cyber Incident Learning Without Law Enforcement, Regulatory, or Emergency Command Authority by GCRI Canada.\
9.14.6(a) GCRI Canada may steward cyber incident learning methods for understanding cyber incidents, suspected incidents, near misses, degraded modes, vulnerability patterns, anomaly patterns, cyber-physical dependencies, public-safe lessons, systems-risk context, resilience context, and correction needs without becoming a law enforcement body, regulator, emergency commander, public warning issuer, incident commander, or operator.

9.14.6(b) Cyber incident learning may involve incident telemetry, operator context, host context, provider context, public authority context, public-safe summaries, controlled-room review, technical notes, lessons learned, evidence packs, decision packs, Nexus Risk Management inputs, GRF inputs, GRA inputs, Protocol Authority inputs, Academy materials, and correction signals.

9.14.6(c) Cyber incident learning records shall identify incident class, suspected or confirmed status, evidence basis, affected system class where safe, affected data class, detection source, timeline where safe, containment status where known, public-safe status, confidence, uncertainty, limitations, permitted use, prohibited use, and correction path.

9.14.6(d) GCRI Canada shall not use cyber incident learning to conduct criminal investigations, assign legal liability, make regulatory findings, issue compliance determinations, direct enforcement, command emergency response, direct operators, require remediation, approve remediation, certify security posture, approve procurement, approve finance, issue public warnings, or operate incident response by default.

9.14.6(e) Where public authorities, operators, hosts, providers, National Companies, Project SPVs, or other actors use GCRI Canada cyber incident learning materials, such use shall remain within their own authority, duties, records, accountability, and liability.

9.14.6(f) Cyber incident learning materials shall include boundary language where material to prevent interpretation as law enforcement finding, regulatory finding, compliance determination, public warning, emergency command, public authority decision, procurement approval, security certification, provider endorsement, sponsor approval, operational clearance, infrastructure operation, legal status, professional advice, or execution instruction.

9.14.6(g) Where cyber incident learning materials are misused to imply unauthorized authority, GCRI Canada shall correct, relabel, restrict, withdraw, reissue, require removal of misleading references, notify affected interfaces where appropriate, suspend affected interface use, or pursue contractual or legal remedies where appropriate.

9.14.6(h) The controlling rule shall be that GCRI Canada may learn from cyber incidents and support public-good correction, but it does not investigate, regulate, command, warn, certify, procure, operate, or execute by default.

***

9.14.7 Cyber Evidence Interface With Truth Engine, Observatory, Nexus Risk Management, Public Authorities, Hosts, Providers, National Companies, and Project SPVs.\
9.14.7(a) GCRI Canada may maintain cyber evidence interfaces with Nexus Truth Engine, Observatory, Nexus Risk Management, public authorities, hosts, operators, providers, National Companies, Project SPVs, Regional Nexus Consortiums, National Nexus Consortiums, GRF, GRA, Protocol Authority, Nexus Rails, Nexus Grid, Nexus Academy, universities, communities, sponsors, and other authorized actors for evidence learning, public-safe interpretation, cyber-risk context, resilience context, degraded-mode learning, public authority learning, provider-neutral technical review, Academy learning, and correction support.

9.14.7(b) Cyber evidence interface records shall identify receiving interface, purpose, evidence classes, data classes, output classes, source records, method records, compute records, model records where applicable, public-safe status, access class, handling class, cyber-sensitive status, infrastructure-sensitive status, public authority status, sovereign data status, protected knowledge status where any, confidence, uncertainty, limitations, permitted use, prohibited use, boundary language, correction path, supersession path, withdrawal path, retraction path where applicable, and dependency links.

9.14.7(c) Truth Engine interfaces shall preserve source comparison records, corroboration records, contradiction records, dispute records, confidence records, uncertainty records, inference records where applicable, human review records where material, public-safe review records, dependency links, and correction paths.

9.14.7(d) Nexus Risk Management interfaces shall preserve the distinction between risk evidence and risk command. Cyber evidence may support risk learning, resilience learning, degraded-mode learning, scenario learning, and public-safe interpretation, but shall not make GCRI Canada the risk manager, incident commander, emergency commander, infrastructure operator, regulator, public authority, finance actor, procurement actor, provider, sponsor, host, operator, or execution actor for downstream systems.

9.14.7(e) Public authority interfaces shall preserve public authority capacity classification, official or non-official status, data-sharing terms, publication limits, agency reference controls, non-delegation language, non-endorsement language, non-regulatory language, non-procurement language, non-funding language, no-public-warning language, no-emergency-command language, and correction path.

9.14.7(f) Host and operator interfaces shall preserve the distinction between evidence and operation. Host or operator participation, data contribution, telemetry contribution, dashboard access, map access, incident context, or technical feedback shall not make GCRI Canada an operator or create operational instruction, operational clearance, service assurance, compliance approval, procurement approval, finance-readiness, certification, recognition, protocol effect, or execution consequence by default.

9.14.7(g) Provider interfaces shall preserve provider neutrality, conflict disclosure, provider role classification, benchmark conditions where any, validation conditions where any, commercial sensitivity, IP sensitivity, cybersecurity sensitivity, export-control sensitivity, prohibited claims, no-endorsement language, no-procurement-preference language, no-security-certification language, no-protocol-effect language, no-finance-readiness language, and correction path.

9.14.7(h) National Company and Project SPV interfaces shall preserve separate corporate, project, contractual, procurement, financing, operational, insurance, public authority, provider, host, operator, delivery, implementation, records, liability, and execution responsibilities. Cyber evidence supplied by GCRI Canada shall not create project approval, procurement approval, operational clearance, remediation approval, finance-readiness, insurance-readiness, security certification, provider preference, or execution instruction by default.

9.14.7(i) Where cyber evidence interfaces create public authority confusion, regulatory implication, law enforcement implication, public warning implication, procurement implication, finance implication, security certification implication, provider preference, sponsor validation, host approval implication, operator-control implication, protected knowledge exposure, or correction failure, GCRI Canada shall restrict, reclassify, correct, suspend, or refuse the interface as appropriate.

9.14.7(j) The controlling rule shall be that cyber evidence may support many Nexus interfaces, but no cyber interface converts GCRI Canada evidence into command, warning, regulation, enforcement, certification, procurement, finance, provider preference, operator control, or execution.

***

9.14.8 Export-Control, Sanctions, Controlled Technology, and National Security Review.\
9.14.8(a) GCRI Canada shall apply export-control, sanctions, controlled-technology, national-security-adjacent, cybersecurity, public authority, legal, privacy, sovereign data, and public-safe review to cyber-physical and cyber telemetry evidence where the material, method, system, vulnerability, tool, dataset, model, code, configuration, actor, jurisdiction, provider, host, operator, public authority, or downstream use creates heightened legal or security risk.

9.14.8(b) Export-control review shall identify whether cyber materials include controlled technology, controlled software, dual-use technology, vulnerability information, exploit information, encryption materials, sensitive technical data, advanced computing materials, telecommunications materials, AI model materials, critical infrastructure information, or other export-sensitive content.

9.14.8(c) Sanctions review shall identify whether any person, entity, jurisdiction, provider, sponsor, host, operator, data source, tool, compute environment, model, repository, platform, or transaction creates sanctions-related restrictions or risk.

9.14.8(d) Controlled-technology review shall identify whether cyber tools, malware samples, exploit proof-of-concepts, offensive security materials, vulnerability details, industrial control system details, telecommunications details, AI-RAN details, O-RAN details, private wireless details, DePIN details, secure enclave details, cryptographic materials, or model-enabled cyber capabilities require restricted handling, controlled-room treatment, legal review, or refusal.

9.14.8(e) National-security-adjacent review shall identify whether materials concern critical infrastructure, public authority systems, defence-adjacent systems, border-adjacent systems, emergency-management systems, telecommunications systems, energy systems, water systems, transportation systems, port systems, cyber-physical dependencies, sensitive geospatial context, or other systems where public-safe disclosure could create national or public security risk.

9.14.8(f) Materials subject to review under this section shall not be transferred, exported, shared, embedded, retrieved, trained on, vendor-processed, publicly summarized, dashboarded, mapped, API-exposed, published, or routed to another jurisdiction, entity, room, provider, sponsor, public authority, finance-facing context, or public audience without recorded authority and safeguards.

9.14.8(g) Where review identifies unacceptable export-control, sanctions, controlled-technology, national-security-adjacent, cybersecurity, legal, or public-safe risk, GCRI Canada shall restrict, seal, refuse, delete where appropriate, use controlled-room treatment, use responsible non-disclosure, notify affected interfaces where required, and update records.

9.14.8(h) The controlling rule shall be that cyber evidence touching controlled technology or national-security-adjacent systems must be governed before it is useful, because technical disclosure can become operational harm.

***

9.14.9 Cyber Outputs Do Not Create Public Warnings, Regulatory Findings, Provider Preference, or Security Certification by Default.\
9.14.9(a) No cyber-physical evidence, cyber telemetry record, log record, alert record, vulnerability signal, incident telemetry, anomaly record, dashboard, map, API, Evidence Pack, Decision Pack, technical note, public-safe output, public claim, correction signal, proof receipt, chain-of-handling record, or incident-learning material shall create public warning, regulatory finding, provider preference, security certification, finance-readiness, procurement approval, public authority decision, law enforcement finding, emergency command, recognition, protocol effect, sponsor approval, host approval, operator approval, infrastructure operation, operational clearance, legal status, market authority, deployment approval, or execution consequence by default.

9.14.9(b) Cyber outputs shall not issue or imply official guidance, regulatory determination, compliance determination, enforcement position, law enforcement determination, attribution determination, safe harbor, permit, license, procurement decision, vendor award, funding approval, public finance approval, public warning, emergency alert, evacuation instruction, emergency command, public safety directive, public health order, investment advice, lending decision, underwriting decision, insurance approval, rating, guarantee, security certification, certification, recognition, maturity record, claims approval, conformance determination, Nexus-compatible status, provider ranking, sponsor finding, host approval, operator instruction, remediation approval, deployment authorization, operational clearance, or market signal.

9.14.9(c) Cyber telemetry, public authority interest, public authority attendance, provider participation, sponsor support, host participation, operator participation, dashboard visibility, map visibility, incident severity label, vulnerability severity label, Proof Receipt issuance, GRF interface use, GRA interface use, Protocol Authority interface use, National Company relevance, Project SPV relevance, or media interest shall not convert cyber outputs into authority.

9.14.9(d) Any authority-bearing action by a public authority, regulator, law enforcement body, emergency-management actor, GRF, GRA, Protocol Authority, National Nexus Consortium, Regional Nexus Consortium, National Company, Project SPV, provider, sponsor, host, operator, finance actor, procurement actor, infrastructure actor, university, community, or other actor shall arise only through that actor’s own lawful authority, process, record, accountability, and liability, not through cyber evidence or cyber outputs by implication.

9.14.9(e) Cyber materials shall include boundary language where material to prevent interpretation as public authority action, public warning, emergency command, regulatory finding, compliance determination, law enforcement finding, procurement action, finance-readiness, public finance approval, security certification, provider preference, sponsor approval, host approval, operator approval, operational clearance, infrastructure operation, legal status, professional advice, market signal, deployment approval, remediation approval, or execution instruction.

9.14.9(f) Where cyber materials are misused to imply unauthorized authority, GCRI Canada shall correct, relabel, restrict, withdraw, reissue, require removal of misleading references, notify affected interfaces where appropriate, suspend affected interface use, or pursue contractual or legal remedies where appropriate.

9.14.9(g) No ambiguity shall be resolved in favour of cyber output authority. Where there is doubt whether cyber evidence creates authority or only supports evidence, the interpretation preserving GCRI Canada’s non-execution role, public authority boundaries, regulatory boundaries, law enforcement boundaries, emergency-command boundaries, finance boundaries, procurement neutrality, provider neutrality, sponsor non-control, host boundaries, operator boundaries, Protocol Authority role separation, GRF role separation, GRA role separation, validity-by-record, correctionability, and public trust shall prevail.

9.14.9(h) The controlling rule shall be that cyber outputs may support learning and correction, but they do not warn, command, regulate, enforce, certify, procure, finance, prefer providers, approve remediation, operate, or execute by default.

***

9.14.10 Cyber Telemetry Records, Incident Records, Correction, and Retention.\
9.14.10(a) GCRI Canada shall maintain, or cause to be maintained, cyber telemetry records for material cyber-physical methods, cyber sources, operational technology evidence, industrial control system evidence, critical infrastructure system evidence, logs, alerts, vulnerability signals, incident telemetry, anomaly records, compute workloads, models, dashboards, maps, APIs, Evidence Packs, Decision Packs, public-safe outputs, disputes, incidents, corrections, dependencies, assurance reviews, retention decisions, and closeout events.

9.14.10(b) Cyber telemetry records shall identify record title or identifier, source system, source class, telemetry class, log class, alert class, vulnerability class where applicable, incident class where applicable, provider where any, operator where any, host where any, public authority context where any, community context where any, technology domain, risk domain, data class, evidence class, output class, access class, handling class, cyber-sensitive status, infrastructure-sensitive status, public-safe status, privacy status, cybersecurity status, sovereign data status, public authority status, finance-sensitive status, provider-sensitive status, sponsor-sensitive status, operator-sensitive status, host-sensitive status, community-protected status, Indigenous or protected knowledge status, legal sensitivity, export-control sensitivity, sanctions sensitivity, controlled-technology sensitivity, permitted uses, prohibited uses, publication limits, retention status, and correction path.

9.14.10(c) Incident records shall identify incident title or identifier, incident type, suspected or confirmed status, severity classification where used, detection source, affected system class where safe, affected data class, affected environment, affected operator context where any, affected host context where any, affected provider context where any, affected public authority context where any, timeline where safe, containment status where known, vulnerability relationship where any, public-safe status, confidence, uncertainty, limitations, notification decisions, correction actions, residual risk, closeout status, and archive treatment.

9.14.10(d) Correction records shall identify corrected source, corrected telemetry, corrected log record, corrected alert, corrected vulnerability signal, corrected incident telemetry, corrected timestamp, corrected chain-of-handling record, corrected integrity status, corrected classification, corrected dataset, corrected method, corrected compute workload, corrected model, corrected dashboard, corrected map, corrected API, corrected public-safe output, corrected public authority reference, corrected provider reference, corrected sponsor reference, corrected host reference, corrected operator reference, corrected community reference, prior status, corrected status, effective date, reviewer, affected dependencies, notice decision, access change, archive treatment, and continuing limitations.

9.14.10(e) Supersession, withdrawal, or retraction records shall be used where cyber evidence or outputs should no longer be used or relied upon because of material error, unsafe disclosure, source defect, log defect, timestamp defect, chain-of-handling defect, integrity defect, vulnerability disclosure defect, incident classification defect, cybersecurity defect, public-safe defect, public authority confusion, regulatory overclaim, law enforcement overclaim, finance overclaim, procurement implication, provider-preferential framing, sponsor-validation framing, host approval implication, operator-control implication, protected knowledge exposure, privacy defect, sovereign data issue, cross-border defect, controlled-technology issue, export-control issue, sanctions issue, infrastructure-risk exposure, or correction failure.

9.14.10(f) Retention records shall identify retention basis, retention period, legal hold status, sealing status, deletion status, archive status, access restrictions, log retention, key records where applicable, incident records, public-safe records, controlled notices, public-safe notices, dependency records, and continuing prohibited uses.

9.14.10(g) Cyber telemetry retention shall account for legal obligations, public authority restrictions, privacy obligations, cybersecurity needs, incident learning, correctionability, source protection, confidentiality, export-control sensitivity, sanctions sensitivity, controlled-technology sensitivity, protected knowledge, public-safe risk, and downstream dependency needs. Retention shall not be longer, broader, more accessible, or more exportable than required for recorded purpose and lawful obligation.

9.14.10(h) Cyber telemetry records shall be linked, where applicable, to National Dense Core records, Regional Observatory Cluster records, Cluster records, Hub records, Node records, Hotspot records, AI-RAN records, DePIN records, sensor records, geospatial records, digital twin records, Observatory Methods Register entries, Evidence Register entries, Source Comparison Records, Dataset Register entries, Model Register entries, System Card entries, Benchmark Card entries, Compute Workload Records, Compute Environment Records, Inference Records, Human Review Records, Retrieval and Embedding Records, Proof Receipt Records, Public-Safe Output Records, AI Incident Records, Correction Records, Dependency Records, Truth Engine Records, Nexus Risk Management records, public authority records, GRF interface records, GRA interface records, Protocol Authority interface records, RNFD records, Nexus Rails records, Regional Nexus Consortium records, National Nexus Consortium records, National Company records, Project SPV records, operator records, provider records, sponsor records, host records, community records, university records, Nexus interface records, and public claims records.

9.14.10(i) Cyber telemetry records, incident records, retention records, public-safe records, correction, supersession, withdrawal, retraction, assurance, retirement, archive, notices, and closeout shall not create certification, recognition, finance-readiness, public authority decision, regulatory finding, law enforcement finding, procurement approval, provider endorsement, sponsor approval, host approval, operator approval, rating, guarantee, public warning, emergency command, security certification, protocol effect, operational clearance, legal status, market authority, infrastructure operation, remediation approval, deployment approval, national authority, regional authority, or execution consequence by default.

9.14.10(j) The controlling rule shall be that cyber telemetry is trustworthy only when source lineage, sensitivity, custody, integrity, incident status, retention, correction, and public-safe treatment remain recorded with enough precision to protect systems, people, public authorities, operators, providers, hosts, communities, markets, and public trust.

### 9.15 Digital Twin and Simulation Methods for Observatory Systems

9.15.1 Digital Twins as Observatory Evidence and Scenario Tools.\
9.15.1(a) GCRI Canada shall steward digital twin and simulation methods as specialized Observatory methods for representing, testing, comparing, visualizing, interpreting, public-safe summarizing, and correcting evidence concerning systems, infrastructure, environments, communities, technologies, hazards, dependencies, degraded modes, resilience conditions, continuity conditions, and scenario pathways.

9.15.1(b) Digital twins may support Observatory Nodes, Hubs, Clusters, Hotspots, Regional Observatory Clusters, National Dense Nexus Cores, sovereign compute environments, sensors, AI-RAN systems, O-RAN systems, private wireless systems, DePIN systems, cyber-physical systems, geospatial layers, Earth observation layers, public authority learning, host learning, operator learning, provider-neutral technical review, Nexus Truth Engine inputs, Nexus Risk Management inputs, GRF inputs, GRA inputs, Protocol Authority inputs, Nexus Rails inputs, Nexus Grid inputs, Nexus Academy materials, Evidence Packs, Decision Packs, public-safe outputs, and correction workflows.

9.15.1(c) A digital twin shall be treated as an evidence and scenario tool, not as the system itself, not as an official representation of the system by default, and not as a substitute for source evidence, field evidence, public authority records, operator records, host records, community context, or competent human review where material.

9.15.1(d) Digital twin methods shall be records-valid, source-lined, assumption-aware, calibration-aware, validation-aware, confidence-aware, uncertainty-aware, limitation-aware, sensitivity-aware, public-safe, privacy-protective, cybersecurity-controlled, sovereignty-compatible, community-sensitive, protected-knowledge-sensitive, provider-neutral, sponsor-independent, and correctionable.

9.15.1(e) GCRI Canada’s stewardship of digital twin and simulation methods shall not make GCRI Canada an infrastructure operator, system operator, public authority, emergency-management actor, public warning issuer, regulator, procurement actor, finance actor, certification body, recognition body, Protocol Authority, provider, sponsor, host, operator, National Company, Project SPV, or execution actor by default.

9.15.1(f) Digital twins shall preserve the distinction between observed evidence, modeled evidence, simulated evidence, inferred evidence, scenario evidence, forecast-adjacent evidence, dashboard output, map output, public-safe summary, public authority learning material, risk-management input, finance-facing evidence input, and any authority-bearing decision made by a competent separate actor.

9.15.1(g) Where digital twin or simulation outputs are used externally or publicly, GCRI Canada shall preserve controlled vocabulary, source lineage, assumptions, calibration status, validation status, confidence, uncertainty, limitations, public-safe status, no-public-warning language, no-emergency-command language, no-public-authority language, no-finance language, no-procurement language, no-certification language, no-recognition language, no-protocol-effect language unless separately created by Protocol Authority, no-provider-endorsement language, no-sponsor-approval language, no-host-approval language, no-operator-instruction language, no-infrastructure-operation language, and correction path where material.

9.15.1(h) The controlling rule shall be that digital twins and simulations may help GCRI Canada understand possible system behavior, but they shall never be treated as reality, authority, approval, readiness, warning, command, certification, finance, procurement, or execution by default.

***

9.15.2 Simulation Systems, Scenario Engines, Model-Based Evidence, and Infrastructure Continuity Models.\
9.15.2(a) GCRI Canada shall steward methods for simulation systems, scenario engines, model-based evidence, continuity models, degraded-mode models, infrastructure dependency models, hazard models, resilience models, risk propagation models, environmental models, cyber-physical models, supply-chain models, AI-RAN models, DePIN models, geospatial models, public authority learning models, and other model-based Observatory tools.

9.15.2(b) Simulation system records shall identify simulation purpose, system scope, model identity, model version, system architecture, data inputs, source records, scenario parameters, assumptions, boundary conditions, calibration status, validation status, compute workload, compute environment, output class, access class, handling class, public-safe status, confidence, uncertainty, limitations, and correction path.

9.15.2(c) Scenario engine methods shall identify scenario purpose, scenario type, scenario time horizon, scenario geography or safe-location treatment, scenario drivers, scenario constraints, scenario assumptions, excluded factors, sensitivity variables, public authority relevance, community relevance, host relevance, operator relevance, provider relevance, sponsor relevance, finance relevance where any, and public-safe communication limits.

9.15.2(d) Model-based evidence methods shall distinguish model inputs, model assumptions, model structure, model parameters, model outputs, model interpretation, model uncertainty, model limitations, human judgment, field evidence, sensor evidence, public authority context, community context, protected knowledge context, provider-supplied model materials, sponsor-supported model materials, and public-safe summaries.

9.15.2(e) Infrastructure continuity models may support learning concerning continuity, interruption, degraded modes, redundancy, dependencies, restoration pathways, resilience context, sensor availability, communications availability, compute availability, cyber-physical dependencies, host constraints, operator constraints, public authority context, and community context, but shall not direct operations or emergency response by GCRI Canada.

9.15.2(f) Simulation and scenario systems shall not be treated as predictive certainty, official forecast, public warning, emergency command, public authority decision, regulatory determination, procurement priority, finance-readiness, investment advice, insurance approval, rating, guarantee, certification, recognition, protocol effect, operator instruction, host approval, provider preference, sponsor approval, market signal, deployment approval, or execution instruction by default.

9.15.2(g) Where simulation systems, scenario engines, or continuity models become stale, uncalibrated, invalid, misclassified, overclaimed, public-safe defective, provider-influenced, sponsor-influenced, assumption-defective, or correction-defective, GCRI Canada shall restrict, correct, supersede, withdraw, retire, or refuse affected outputs as appropriate.

9.15.2(h) The controlling rule shall be that simulation systems and scenario engines support disciplined imagination under records and limits; they do not turn possible futures into official facts or executable commands.

***

9.15.3 Digital Twin Source Inputs, Assumptions, Calibration, Validation, Sensitivity, Boundary Conditions, and Limitations.\
9.15.3(a) GCRI Canada shall steward methods for recording and reviewing source inputs, assumptions, calibration, validation, sensitivity, boundary conditions, limitations, uncertainty, confidence, and correction paths for material digital twins and simulations.

9.15.3(b) Source input records shall identify source datasets, sensor inputs, reference sensor inputs, AI-RAN inputs, O-RAN inputs, private wireless inputs, DePIN inputs, cyber telemetry inputs, geospatial layers, Earth observation layers, public authority data, host data, operator data, provider data, sponsor-supplied data, community context, Indigenous or protected knowledge context where any, public records, historical records, and field observations.

9.15.3(c) Assumption records shall identify explicit assumptions, implicit assumptions where known, default assumptions, proxy assumptions, excluded variables, scenario assumptions, operational assumptions, public authority assumptions, community assumptions, infrastructure assumptions, environmental assumptions, cyber assumptions, model assumptions, economic assumptions where any, and limitations arising from such assumptions.

9.15.3(d) Calibration records shall identify calibration method, calibration data, calibration period, calibration quality, calibration uncertainty, reference sources, fit limitations, overfitting risk, underfitting risk, drift risk, changed system context, changed environmental context, changed public authority context, changed host context, changed operator context, and correction path.

9.15.3(e) Validation records shall identify validation method, validation data, validation conditions, validation limits, benchmark relationship where any, field comparison where any, expert review where any, historical comparison where any, negative tests, edge cases, adverse scenarios, out-of-distribution risks, failure modes, and known invalid uses.

9.15.3(f) Sensitivity records shall identify material variables, parameter ranges, uncertainty propagation, scenario sensitivity, output sensitivity, threshold effects, nonlinear effects, dependency effects, degraded-mode effects, model instability, public-safe sensitivity, finance-facing sensitivity, public authority sensitivity, and correction implications.

9.15.3(g) Boundary condition and limitation records shall identify system boundaries, geographic boundaries, temporal boundaries, data boundaries, legal boundaries, public authority boundaries, community boundaries, protected knowledge boundaries, compute boundaries, model boundaries, operational boundaries, public-safe boundaries, and prohibited uses.

9.15.3(h) A digital twin or simulation output shall not be used materially unless its source inputs, assumptions, calibration, validation, sensitivity, boundary conditions, limitations, confidence, uncertainty, and correction path are adequate for the proposed use, output class, audience, and public-safe status.

9.15.3(i) The controlling rule shall be that digital twin outputs are only as reliable as the sources, assumptions, calibration, validation, sensitivity treatment, boundary conditions, and limitations recorded behind them.

***

9.15.4 Digital Twin Integration With Sensors, Geospatial Layers, AI-RAN, DePIN, Cyber Telemetry, and Public Authority Context.\
9.15.4(a) GCRI Canada may steward digital twin integration methods with sensors, reference sensors, geospatial layers, Earth observation layers, AI-RAN systems, O-RAN systems, private wireless systems, DePIN systems, cyber telemetry, operational technology evidence, infrastructure records, public authority context, host context, operator context, provider context, sponsor context, community context, Indigenous or protected knowledge context, dashboards, maps, APIs, Nexus Truth Engine, Nexus Risk Management, and Observatory architecture records.

9.15.4(b) Integration methods shall identify integration purpose, source systems, receiving systems, data classes, evidence classes, output classes, source lineage, data lineage, method version, model version, compute workload, compute environment, access class, handling class, public-safe status, confidence, uncertainty, limitations, permitted flows, prohibited flows, permitted uses, prohibited uses, and correction path.

9.15.4(c) Sensor integration shall identify sensor identity where safe, calibration status, timing alignment, location alignment, data quality, missing data, fusion method, source independence, sensor drift, spoof risk, tamper risk, and correction propagation.

9.15.4(d) Geospatial integration shall identify source layers, coordinate reference system where material, spatial resolution, temporal resolution, safe-location treatment, sensitive-site treatment, infrastructure-sensitive treatment, protected knowledge treatment, public-safe mapping limits, and correction propagation.

9.15.4(e) AI-RAN, O-RAN, and private wireless integration shall identify signal class, network context, telemetry relationship, edge intelligence relationship, timing relationship, location treatment, provider context where any, operator context where any, spoof risk, interference risk, outage risk, degraded-mode status, public-safe status, confidence, uncertainty, limitations, and correction propagation.

9.15.4(f) DePIN integration shall identify device relationship, proof relationship, ledger relationship where any, token relationship where any, telemetry source, location claim, uptime claim, coverage claim, capacity claim, service claim, tamper risk, spoof risk, fraud risk, incentive risk, public-safe status, and correction path.

9.15.4(g) Cyber telemetry integration shall identify cyber-sensitive classification, log source, alert source, vulnerability signal, incident telemetry, timestamping, chain of handling, integrity status, public-safe disclosure limits, export-control or controlled-technology sensitivity where applicable, confidence, uncertainty, limitations, and correction propagation.

9.15.4(h) Public authority context integration shall identify participating public authority, capacity classification, official or non-official status, data-sharing terms, publication limits, agency reference controls, non-delegation language, non-endorsement language, non-regulatory language, non-procurement language, non-funding language, no-public-warning language, no-emergency-command language, and correction path.

9.15.4(i) Integration shall not create legal merger, system merger, operator control, public authority status, public warning, emergency command, procurement approval, finance-readiness, certification, recognition, protocol effect, provider preference, sponsor approval, host approval, operational clearance, infrastructure operation, market authority, deployment approval, or execution consequence by default.

9.15.4(j) The controlling rule shall be that digital twin integration can improve systems understanding only where each integrated source keeps its original meaning, sensitivity, confidence, uncertainty, limits, boundary status, and correction path.

***

9.15.5 Digital Twin Outputs as Decision-Support, Not Decisions.\
9.15.5(a) Digital twin and simulation outputs stewarded, produced, received, reviewed, dashboarded, mapped, summarized, routed, or corrected by GCRI Canada shall be treated as decision-supporting evidence artifacts, scenario outputs, model outputs, simulation records, dashboard inputs, map inputs, public-safe summaries, controlled annex inputs, Evidence Pack inputs, Decision Pack inputs, Verifiable Compute records, Verifiable Intelligence inputs, Truth Engine inputs, Observatory outputs, Nexus Risk Management inputs, GRF inputs, GRA inputs, Protocol Authority inputs, public authority learning materials, provider-neutral review materials, Academy materials, or correction records, depending on their recorded output class.

9.15.5(b) Digital twin outputs shall not constitute decisions. They shall not constitute official truth, public authority meaning, public warning, emergency command, regulatory approval, procurement approval, funding approval, public finance approval, finance-readiness, capital-readiness, insurance-readiness, investment advice, rating, guarantee, certification, recognition, maturity record, claims approval, protocol effect, conformance determination, Nexus-compatible status, provider endorsement, sponsor approval, host approval, operator instruction, operational clearance, infrastructure operation, legal status, market authority, deployment approval, or execution consequence by default.

9.15.5(c) The fact that a digital twin output is visually compelling, high-resolution, near-real-time, sensor-fed, AI-assisted, calibrated, validated for a limited purpose, dashboard-visible, map-visible, public authority-relevant, finance-relevant, provider-supplied, sponsor-supported, host-related, operator-related, signed, hashed, timestamped, or supported by a Proof Receipt shall not convert it into authority, approval, public warning, finance value, procurement value, certification status, recognition status, operational clearance, or execution consequence.

9.15.5(d) Digital twin outputs shall identify source records, data lineage, model records, system records, method records, assumption records, calibration records, validation records, sensitivity records, workload records, environment records, human review where material, output class, confidence, uncertainty, limitations, public-safe status, permitted use, prohibited use, boundary language, correction path, supersession path, withdrawal path, retraction path where applicable, and dependency links.

9.15.5(e) Where digital twin outputs are routed to public authorities, National Dense Nexus Core interfaces, Regional Observatory Cluster interfaces, Hubs, Nodes, Hotspots, GRF, GRA, Protocol Authority, Nexus Risk Management, Nexus Rails, National Nexus Consortiums, National Companies, Project SPVs, providers, sponsors, hosts, operators, universities, communities, Academy materials, media materials, or public audiences, the receiving context shall be recorded and boundary language shall be preserved.

9.15.5(f) Where digital twin outputs are overclaimed, misused, misclassified, publicly misread, finance-inflated, procurement-inflated, authority-inflated, certification-inflated, recognition-inflated, provider-preferential, sponsor-validating, public-warning-adjacent, public-safe defective, or correction-defective, GCRI Canada shall correct, relabel, restrict, withdraw, reissue, notify affected interfaces where appropriate, and review dependencies.

9.15.5(g) No ambiguity shall be resolved in favour of digital twin authority. Where there is doubt whether a digital twin output creates authority or only supports evidence, the interpretation preserving GCRI Canada’s non-execution role, public authority boundaries, finance boundaries, procurement neutrality, provider neutrality, sponsor non-control, operator boundaries, host boundaries, community safeguards, Protocol Authority role separation, GRF role separation, GRA role separation, validity-by-record, correctionability, and public trust shall prevail.

9.15.5(h) The controlling rule shall be that digital twin outputs may support decisions by competent actors, but they are not decisions by GCRI Canada.

***

9.15.6 False Precision, Scenario Overclaim, and Stale Assumption Controls.\
9.15.6(a) GCRI Canada shall apply false precision, scenario overclaim, stale assumption, model drift, visual overclaim, dashboard overclaim, map overclaim, public-safe overclaim, and downstream-reliance controls to digital twin and simulation methods.

9.15.6(b) False precision controls shall prevent outputs from displaying, labeling, scoring, mapping, ranking, estimating, forecasting, or visualizing greater accuracy, resolution, certainty, completeness, timeliness, or authority than the sources, assumptions, calibration, validation, sensitivity, confidence, uncertainty, and limitations support.

9.15.6(c) Scenario overclaim controls shall prevent scenarios from being presented as predictions, forecasts, official expected outcomes, public warnings, public authority decisions, finance signals, procurement priorities, certification signals, recognition signals, provider rankings, sponsor validations, market signals, deployment instructions, or execution pathways by default.

9.15.6(d) Stale assumption controls shall require review where material assumptions, source inputs, system conditions, environmental conditions, infrastructure conditions, cyber conditions, public authority context, community context, host context, operator context, provider context, sponsor context, legal context, data context, compute context, or technology context materially changes.

9.15.6(e) Digital twin dashboards, maps, animations, 3D visualizations, time sliders, heatmaps, simulations, scenario tables, risk pathways, resilience pathways, continuity pathways, and AI-generated summaries shall include confidence, uncertainty, limitations, scenario status, assumption status, and correction path where material.

9.15.6(f) GCRI Canada shall not conceal uncertainty, contradiction, data gaps, proxy limitations, model limitations, stale assumptions, or public-safe omissions through smoothing, animation, color-coding, ranking, aggregation, AI summarization, or visual polish.

9.15.6(g) Where false precision, scenario overclaim, stale assumption, or visual overclaim is detected, GCRI Canada shall require relabeling, confidence downgrade, uncertainty revision, limitation update, assumption update, model review, dashboard correction, map correction, public-safe correction, controlled notice, supersession, withdrawal, retraction where appropriate, training update, or dependency review.

9.15.6(h) The controlling rule shall be that the more realistic a digital twin appears, the more carefully GCRI Canada must disclose that it is a bounded model, not the world itself.

***

9.15.7 Digital Twin Public-Safe Visualization, Dashboard, and Report Methods.\
9.15.7(a) GCRI Canada shall apply public-safe visualization, dashboard, map, report, API, dataset, technical note, Academy, public authority learning, GRF-facing, GRA-facing, Protocol Authority-facing, provider-facing, sponsor-facing, host-facing, operator-facing, community-facing, media-facing, repository, website, and public claim controls to digital twin and simulation outputs.

9.15.7(b) Public-safe visualization review shall assess whether a digital twin output discloses or enables misuse of personal information, rights-bearing data, health-sensitive data, cyber-sensitive information, infrastructure-sensitive information, public authority restricted information, sovereign-sensitive information, finance-sensitive information, commercially sensitive information, community-protected information, Indigenous or protected knowledge, confidential source information, privileged material, credentials, secrets, keys, tokens, controlled technology, exploit details, sensitive locations, unsafe geospatial precision, unsafe metadata, operator-sensitive information, or national-security-adjacent sensitive information.

9.15.7(c) Digital twin dashboards shall identify source layers, source records, model version, scenario status, update cadence, stale-data treatment, indicator meaning, score meaning where any, color meaning where any, confidence display, uncertainty display, limitation display, assumption display, public-safe status, export controls, access class, handling class, and correction path.

9.15.7(d) Digital twin maps and spatial visualizations shall be reviewed for official-status implication, public warning implication, emergency-command implication, public authority implication, finance implication, procurement implication, investment-zone implication, provider-market implication, sponsor-territory implication, geospatial sensitivity, infrastructure exposure, cyber-sensitive detail, operator-sensitive detail, protected knowledge exposure, false precision, overconfident colors, misleading legends, drill-down risk, export risk, screenshot risk, API exposure, stale-data risk, and third-party reuse risk.

9.15.7(e) Digital twin reports and technical notes shall identify model purpose, sources, assumptions, calibration, validation, sensitivity, confidence, uncertainty, limitations, public-safe omissions, responsible non-disclosure basis, permitted use, prohibited use, boundary language, correction status, supersession status, withdrawal status where applicable, and retraction status where applicable.

9.15.7(f) Where digital twin outputs cannot be made public-safe without distorting evidence, erasing uncertainty, concealing contradiction, exposing restricted data, exposing protected knowledge, creating public warning implication, creating official status implication, creating finance overclaim, creating procurement implication, creating operator risk, or creating unauthorized authority, GCRI Canada may use controlled annexes, controlled-room review, aggregation, generalization, safe-location treatment, delayed release, responsible non-disclosure, limited public-safe statement, or no-publication treatment.

9.15.7(g) Where digital twin public-safe outputs are corrected, restricted, superseded, withdrawn, retracted, misused, misquoted, mistranslated, screenshot out of context, or made stale by later evidence, GCRI Canada shall update public-safe output records, issue public-safe or controlled correction where appropriate, and review affected dependencies and interfaces.

9.15.7(h) The controlling rule shall be that digital twin visualization must help audiences understand modeled scenarios without making modeled worlds appear more certain, official, safe, financial, certified, operational, or executable than they are.

***

9.15.8 Digital Twin Public Authority, Community, Protected Knowledge, and Infrastructure-Sensitive Controls.\
9.15.8(a) GCRI Canada shall apply heightened public authority, community, Indigenous, protected knowledge, infrastructure-sensitive, cybersecurity, sovereign data, host, operator, provider, sponsor, and public-safe controls to digital twin and simulation methods where outputs may affect public meaning, community safety, protected knowledge, infrastructure security, operator sensitivity, public authority interpretation, or downstream reliance.

9.15.8(b) Public authority controls shall identify whether digital twin evidence arises from, relates to, is requested by, is received from, is reviewed by, is funded by, or may be used by a public authority, and shall preserve capacity classification, official or non-official status, data-sharing terms, agency reference controls, non-delegation language, non-endorsement language, non-regulatory language, non-procurement language, non-funding language, no-public-finance language, no-public-warning language, no-emergency-command language, and correction path.

9.15.8(c) Community and Indigenous safeguard controls shall identify community protocols, Indigenous protocols where applicable, consent or non-consent treatment where applicable, territorial context, cultural context, environmental knowledge context, sensitive-site treatment, public-safe mapping limits, source protection, withdrawal or challenge pathways where applicable, accessibility, translation, localization, non-extraction, non-commodification, and do-no-harm controls.

9.15.8(d) Protected knowledge controls shall prohibit extraction, mapping, summarization, translation, modeling, embedding, retrieval, training, dashboarding, simulation, publication, commodification, decontextualization, or public-safe reuse of protected knowledge without recorded authority, safeguards, and public-safe review appropriate to the knowledge context.

9.15.8(e) Infrastructure-sensitive controls shall identify whether digital twin sources or outputs reveal critical infrastructure, facility locations, service dependencies, network topology, outage sensitivity, degraded-mode sensitivity, security controls, vulnerability-sensitive information, logistics dependencies, corridor sensitivity, operator-sensitive information, cyber-sensitive information, physical security risk, or public-safe disclosure limits.

9.15.8(f) Digital twin methods shall protect against re-identification, group harm, community stigmatization, false reassurance, public alarm, exploitation, surveillance, sensitive-site exposure, infrastructure targeting, operator exposure, public authority overclaim, finance overclaim, provider misuse, sponsor misuse, media overclaim, and execution implication.

9.15.8(g) Where required public authority, community, Indigenous, protected knowledge, infrastructure-sensitive, or operator review cannot be completed safely, lawfully, or without compromising protected knowledge, public authority restrictions, privacy, cybersecurity, sovereign data, or public-safe discipline, GCRI Canada may restrict use, use controlled annexes, generalize outputs, delay release, provide limited public-safe statements, or refuse publication.

9.15.8(h) Where controls under this section fail, GCRI Canada shall restrict access, correct classification, halt routing, remove unsafe fields, apply safe-location treatment, delete or seal records where appropriate, withdraw or revise outputs, notify affected interfaces where required, and review dependencies.

9.15.8(i) The controlling rule shall be that digital twins can make sensitive systems and communities vividly visible, and therefore must be governed before they are persuasive.

***

9.15.9 Digital Twin Outputs Do Not Create Public Warning, Finance-Readiness, Certification, Procurement, or Public Authority Meaning by Default.\
9.15.9(a) No digital twin, simulation, scenario engine, continuity model, model-based evidence record, dashboard, map, API, visualization, animation, scenario report, Evidence Pack, Decision Pack, technical note, public-safe output, public claim, correction signal, benchmark record, model card, system card, proof receipt, or assurance record shall create public warning, finance-readiness, certification, procurement approval, public authority meaning, recognition, protocol effect, provider preference, sponsor approval, host approval, operator approval, infrastructure operation, operational clearance, legal status, market authority, deployment approval, or execution consequence by default.

9.15.9(b) Digital twin outputs shall not issue or imply official guidance, regulatory determination, public authority decision, compliance determination, enforcement position, safe harbor, permit, license, procurement decision, vendor award, funding approval, public finance approval, public warning, emergency alert, evacuation instruction, emergency command, public safety directive, public health order, investment advice, lending decision, underwriting decision, insurance approval, rating, guarantee, certification, recognition, maturity record, claims approval, conformance determination, Nexus-compatible status, provider ranking, sponsor finding, host approval, operator instruction, deployment authorization, operational clearance, remediation approval, or market signal.

9.15.9(c) Calibration, validation for a limited purpose, benchmark success, dashboard visibility, map visibility, realistic visualization, public authority interest, provider participation, sponsor support, host participation, operator participation, community participation, Proof Receipt issuance, GRF interface use, GRA interface use, Protocol Authority interface use, Nexus Risk Management interface use, National Company relevance, Project SPV relevance, finance-facing relevance, or media interest shall not convert digital twin outputs into authority.

9.15.9(d) Any authority-bearing action by a public authority, GRF, GRA, Protocol Authority, National Nexus Consortium, Regional Nexus Consortium, National Company, Project SPV, provider, sponsor, host, operator, finance actor, procurement actor, infrastructure actor, university, community, Indigenous governance body where applicable, or other actor shall arise only through that actor’s own lawful authority, process, record, accountability, and liability, not through digital twin or simulation evidence by implication.

9.15.9(e) Digital twin materials shall include boundary language where material to prevent interpretation as public authority action, public warning, emergency command, regulatory determination, procurement action, finance-readiness, public finance approval, certification, recognition, maturity, claims approval, protocol effect, provider preference, sponsor approval, host approval, operator approval, operational clearance, infrastructure operation, legal status, professional advice, market signal, deployment approval, remediation approval, or execution instruction.

9.15.9(f) Where digital twin materials are misused to imply unauthorized authority, GCRI Canada shall correct, relabel, restrict, withdraw, reissue, require removal of misleading references, notify affected interfaces where appropriate, suspend affected interface use, or pursue contractual or legal remedies where appropriate.

9.15.9(g) No ambiguity shall be resolved in favour of digital twin authority. Where there is doubt whether digital twin or simulation evidence creates authority or only supports evidence, the interpretation preserving GCRI Canada’s non-execution role, public authority boundaries, finance boundaries, procurement neutrality, provider neutrality, sponsor non-control, host boundaries, operator boundaries, community safeguards, Indigenous safeguards, Protocol Authority role separation, GRF role separation, GRA role separation, validity-by-record, correctionability, and public trust shall prevail.

9.15.9(h) The controlling rule shall be that digital twins simulate and support; they do not warn, command, regulate, procure, finance, certify, recognize, approve, operate, remediate, deploy, or execute by default.

***

9.15.10 Digital Twin Records, Model Cards, System Cards, Benchmark Cards, Correction, Supersession, and Retirement.\
9.15.10(a) GCRI Canada shall maintain, or cause to be maintained, digital twin and simulation records for material digital twin methods, simulation systems, scenario engines, continuity models, model-based evidence records, source inputs, assumptions, calibration events, validation events, sensitivity reviews, benchmark reviews, compute workloads, dashboards, maps, APIs, Evidence Packs, Decision Packs, public-safe outputs, disputes, incidents, corrections, dependencies, assurance reviews, supersession, retirement, and closeout events.

9.15.10(b) Digital twin records shall identify record title or identifier, digital twin title or identifier, system class, model class, scenario class where applicable, provider where any, operator where any, host where any, public authority context where any, community context where any, technology domain, risk domain, data class, evidence class, output class, access class, handling class, public-safe status, privacy status, cybersecurity status, sovereign data status, infrastructure-sensitive status, public authority status, finance-sensitive status, provider-sensitive status, sponsor-sensitive status, operator-sensitive status, host-sensitive status, community-protected status, Indigenous or protected knowledge status, legal sensitivity, export-control sensitivity, sanctions sensitivity, controlled-technology sensitivity, permitted uses, prohibited uses, publication limits, and correction path.

9.15.10(c) Model Cards for digital twins and simulations shall identify model purpose, model owner where known, custodian, steward, model version, model architecture or method at an appropriate level of safe description, input classes, output classes, training or calibration data status where applicable, assumptions, known limitations, validation status, failure modes, bias risks, drift risks, security risks, public-safe risks, permitted uses, prohibited uses, human review requirements, lifecycle status, and correction path.

9.15.10(d) System Cards shall identify digital twin system purpose, components, data flows, model flows, compute flows, dashboard flows, map flows, API flows, human roles, authority boundaries, public authority boundaries, finance boundaries, procurement boundaries, provider-neutrality controls, sponsor non-control controls, privacy controls, cybersecurity controls, sovereign data controls, protected knowledge safeguards, public-safe controls, failure modes, incident history, change log, and correction path.

9.15.10(e) Benchmark Cards shall identify benchmark purpose, scope, dataset, source records, method, conditions, metrics, limitations, bias, failure modes, negative tests, adversarial tests, edge cases, reproducibility status, public-safe status, provider role where any, sponsor role where any, confidence, uncertainty, permitted claims, prohibited claims, and correction path.

9.15.10(f) Correction records shall identify corrected source, corrected dataset, corrected assumption, corrected calibration, corrected validation, corrected sensitivity treatment, corrected boundary condition, corrected limitation, corrected model, corrected system, corrected benchmark, corrected compute workload, corrected dashboard, corrected map, corrected API, corrected public-safe output, corrected public authority reference, corrected provider reference, corrected sponsor reference, corrected host reference, corrected operator reference, corrected community reference, corrected protected knowledge treatment, prior status, corrected status, effective date, reviewer, affected dependencies, notice decision, access change, archive treatment, and continuing limitations.

9.15.10(g) Supersession records shall identify replacement digital twin, replacement model, replacement simulation system, replacement scenario, replacement benchmark, changed evidence base, changed data sources, changed assumptions, changed calibration, changed validation, changed sensitivity treatment, changed boundary conditions, changed limitations, changed confidence, changed uncertainty, changed public-safe status, changed boundary language, continuing validity where any, discontinued reliance where any, and downstream dependency treatment.

9.15.10(h) Retirement records shall be used where a digital twin, simulation system, model, benchmark, dashboard, map, API, or output is no longer fit for use because of stale assumptions, invalid calibration, invalid validation, obsolete source data, changed system context, changed legal context, changed public authority context, changed community context, changed infrastructure context, changed cyber context, changed technology context, public-safe defect, boundary defect, provider influence, sponsor influence, correction failure, or replacement by a superior method.

9.15.10(i) Withdrawal or retraction records shall be used where digital twin or simulation evidence or outputs should no longer be used or relied upon because of material error, unsafe disclosure, false precision, scenario overclaim, assumption defect, calibration defect, validation defect, sensitivity defect, source defect, public-safe defect, protected knowledge exposure, community harm risk, public authority confusion, finance overclaim, procurement implication, provider-preferential framing, sponsor-validation framing, host approval implication, operator-control implication, privacy defect, cybersecurity defect, sovereign data issue, cross-border defect, infrastructure-risk exposure, regulatory overclaim, or correction failure.

9.15.10(j) Digital twin records shall be linked, where applicable, to National Dense Core records, Regional Observatory Cluster records, Cluster records, Hub records, Node records, Hotspot records, AI-RAN records, DePIN records, sensor records, geospatial records, cyber telemetry records, Observatory Methods Register entries, Evidence Register entries, Source Comparison Records, Dataset Register entries, Model Register entries, System Card Registers, Benchmark Card Registers, Compute Workload Records, Compute Environment Records, Inference Records, Human Review Records, Retrieval and Embedding Records, Proof Receipt Records, Public-Safe Output Records, AI Incident Records, Correction Records, Dependency Records, Truth Engine Records, Nexus Risk Management records, public authority records, GRF interface records, GRA interface records, Protocol Authority interface records, RNFD records, Nexus Rails records, Regional Nexus Consortium records, National Nexus Consortium records, National Company records, Project SPV records, operator records, provider records, sponsor records, host records, community records, university records, Nexus interface records, and public claims records.

9.15.10(k) Digital twin records, Model Cards, System Cards, Benchmark Cards, quality records, incident records, public-safe records, correction, supersession, withdrawal, retraction, retirement, assurance, archive, notices, and closeout shall not create certification, recognition, finance-readiness, public authority decision, regulatory finding, procurement approval, provider endorsement, sponsor approval, host approval, operator approval, rating, guarantee, public warning, emergency command, protocol effect, operational clearance, legal status, market authority, infrastructure operation, remediation approval, deployment approval, national authority, regional authority, or execution consequence by default.

9.15.10(l) The controlling rule shall be that digital twins and simulations are trustworthy only when their sources, assumptions, calibration, validation, sensitivity, limitations, records, public-safe treatment, corrections, supersessions, and retirements remain visible enough to prevent models from being mistaken for reality, authority, or execution.

### 9.16 Dashboard and Visualization Methods

9.16.1 Dashboard as Public-Safe or Controlled Evidence Visualization, Not Authority by Default.\
9.16.1(a) GCRI Canada shall steward dashboard and visualization methods as Observatory methods for presenting, organizing, comparing, explaining, routing, monitoring, public-safe summarizing, and correcting evidence through controlled or public-safe visual interfaces, including dashboards, charts, maps, tables, indicators, timelines, heatmaps, score displays, confidence displays, uncertainty displays, status panels, APIs with visual outputs, reports, public-safe summaries, Academy materials, public authority learning materials, GRF-facing materials, GRA-facing materials, Protocol Authority-facing materials, provider-facing materials, sponsor-facing materials, host-facing materials, community-facing materials, media materials, repository materials, website materials, and public claims.

9.16.1(b) A dashboard may support Observatory Nodes, Hubs, Clusters, Hotspots, Regional Observatory Clusters, National Dense Nexus Cores, sovereign compute outputs, AI-RAN evidence, DePIN evidence, sensor evidence, geospatial evidence, cyber telemetry evidence, digital twin outputs, Nexus Truth Engine outputs, Nexus Risk Management inputs, Nexus Rails inputs, Nexus Grid inputs, Evidence Packs, Decision Packs, public-safe outputs, controlled annexes, correction notices, and assurance summaries.

9.16.1(c) A dashboard shall be treated as a visualization of evidence and records, not as the evidence itself, not as an official decision, not as a public warning, not as authority, not as certification, not as recognition, not as finance-readiness, not as procurement approval, not as provider preference, not as sponsor approval, not as host approval, not as operator instruction, not as Protocol Authority effect, and not as execution consequence by default.

9.16.1(d) Dashboard methods shall be records-valid, source-lined, audience-aware, classification-aware, confidence-aware, uncertainty-aware, limitation-aware, update-aware, public-safe, privacy-protective, cybersecurity-controlled, sovereignty-compatible, community-sensitive, protected-knowledge-sensitive, provider-neutral, sponsor-independent, host-bounded, and correctionable.

9.16.1(e) GCRI Canada’s stewardship of dashboards or visualizations shall not make GCRI Canada a public authority, emergency-management actor, public warning issuer, infrastructure operator, telecommunications operator, cyber operator, finance actor, procurement actor, certification body, recognition body, Protocol Authority, provider, sponsor, host, operator, National Company, Project SPV, market actor, or execution actor by default.

9.16.1(f) Dashboard visual force shall not be treated as evidentiary force. Visual polish, real-time display, interactivity, colour, map precision, animations, rankings, indicators, status lights, model outputs, confidence bands, heatmaps, Proof Receipt references, public authority interest, provider participation, sponsor support, host participation, operator participation, media attention, or public accessibility shall not create authority, completeness, accuracy, public-safe status, official status, finance value, procurement value, certification status, recognition status, protocol effect, operational clearance, or execution consequence.

9.16.1(g) Where dashboards are used externally or publicly, GCRI Canada shall preserve controlled vocabulary, source lineage, update status, confidence, uncertainty, limitations, public-safe status, no-public-warning language, no-emergency-command language, no-public-authority language, no-finance language, no-procurement language, no-certification language, no-recognition language, no-protocol-effect language unless separately created by Protocol Authority, no-provider-endorsement language, no-sponsor-approval language, no-host-approval language, no-operator-instruction language, no-infrastructure-operation language, and correction path where material.

9.16.1(h) The controlling rule shall be that dashboards make evidence visible; they do not make evidence authoritative.

***

9.16.2 Dashboard Purpose, Audience, Classification, Update Status, Data Source, Limitations, and Boundary Language.\
9.16.2(a) GCRI Canada shall define the purpose, audience, classification, update status, data sources, limitations, permitted uses, prohibited uses, boundary language, and correction path of each material dashboard or visualization before it is used for public-safe publication, controlled-room review, public authority learning, GRF inputs, GRA inputs, Protocol Authority inputs, provider-facing materials, sponsor-facing materials, host-facing materials, operator-facing materials, community-facing materials, Academy materials, media materials, or public claims.

9.16.2(b) Dashboard purpose records shall identify whether the dashboard supports internal evidence review, controlled-room review, source comparison, public-safe summarization, public authority learning, host learning, operator learning, community learning, provider-neutral technical review, finance-boundary evidence support, GRF input support, GRA input support, Protocol Authority input support, Academy learning, incident review, degraded-mode learning, assurance, correction, or public communication.

9.16.2(c) Dashboard audience records shall identify intended users, permitted audiences, prohibited audiences, public-safe audience status, controlled-room audience status, public authority audience status, finance-facing audience status, provider-facing audience status, sponsor-facing audience status, host-facing audience status, operator-facing audience status, community-facing audience status, media-facing status, and any translation, localization, accessibility, or plain-language requirements.

9.16.2(d) Dashboard classification records shall identify data class, evidence class, output class, access class, handling class, public-safe status, privacy status, cybersecurity status, sovereign data status, infrastructure-sensitive status, public authority status, finance-sensitive status, provider-sensitive status, sponsor-sensitive status, host-sensitive status, operator-sensitive status, community-protected status, Indigenous or protected knowledge status, legal sensitivity, export-control sensitivity, sanctions sensitivity, controlled-technology sensitivity, and publication limits.

9.16.2(e) Dashboard source records shall identify data sources, source authority, source permissions, source lineage, data lineage, method lineage, compute workload where applicable, compute environment where applicable, model records where applicable, retrieval records where applicable, embedding records where applicable, sensor records where applicable, geospatial layer records where applicable, cyber telemetry records where applicable, digital twin records where applicable, public authority records where applicable, provider records where applicable, sponsor records where applicable, host records where applicable, operator records where applicable, community records where applicable, update cadence, stale-data treatment, and correction path.

9.16.2(f) Dashboard limitation records shall identify source limitations, data limitations, method limitations, model limitations, compute limitations, visualization limitations, update limitations, spatial limitations, temporal limitations, confidence limitations, uncertainty limitations, public-safe omissions, audience limitations, interpretation limitations, and downstream reuse limitations.

9.16.2(g) Boundary language shall state or preserve, where material, that the dashboard does not constitute public authority decision, official guidance, public warning, emergency command, regulatory approval, procurement approval, funding approval, public finance approval, finance-readiness, investment advice, insurance approval, lending decision, underwriting decision, rating, guarantee, certification, recognition, maturity record, claims approval, Protocol Authority effect, conformance determination, Nexus-compatible status, provider endorsement, sponsor approval, host approval, operator instruction, operational clearance, infrastructure operation, market authority, deployment approval, legal status, professional advice, or execution consequence.

9.16.2(h) The controlling rule shall be that a dashboard shall not be released, routed, relied upon, or reused unless its purpose, audience, classification, update status, sources, limitations, boundary language, and correction path are clear enough to prevent visual overclaim.

***

9.16.3 Dashboard Confidence and Uncertainty Display.\
9.16.3(a) GCRI Canada shall steward confidence and uncertainty display methods for dashboards and visualizations so that users can distinguish evidence strength, source quality, corroboration status, contradiction status, data-gap status, stale-data status, model uncertainty, public-safe omissions, and limitations from visual presentation.

9.16.3(b) Confidence displays shall identify, where material, the basis for confidence, including source quality, source authority, source independence, corroboration, calibration, timeliness, completeness, reproducibility where appropriate, review status, method reliability, compute integrity, model evaluation, retrieval grounding, interoperability quality, public authority context, community context, provider influence, sponsor influence, host influence, operator context, and correction status.

9.16.3(c) Uncertainty displays shall identify, where material, measurement uncertainty, source uncertainty, temporal uncertainty, spatial uncertainty, statistical uncertainty, operational uncertainty, model uncertainty, digital twin uncertainty, simulation uncertainty, interoperability uncertainty, legal uncertainty, public authority uncertainty, community uncertainty, protected knowledge uncertainty, finance-boundary uncertainty, provider-related uncertainty, sponsor-related uncertainty, host-related uncertainty, operator-related uncertainty, and interpretive uncertainty.

9.16.3(d) Dashboards shall not conceal uncertainty, contradiction, data gaps, proxy limitations, model limitations, stale data, missing sources, excluded data, restricted data, public-safe omissions, or correction status through smoothing, averaging, ranking, color-coding, heatmapping, animation, aggregation, AI summarization, or visual polish.

9.16.3(e) Confidence scores, indicators, bands, labels, traffic lights, colours, charts, status markers, map markers, heatmaps, rankings, tables, trend lines, alerts, or AI-generated summaries shall not be used or presented as ratings, certifications, public warnings, public authority decisions, finance-readiness signals, insurance-readiness signals, procurement signals, provider rankings, sponsor validations, host approvals, operator instructions, protocol effects, or execution instructions.

9.16.3(f) Where visual simplification is necessary for public-safe communication, GCRI Canada shall ensure that simplification does not erase material uncertainty, overstate confidence, imply authority, imply safety, imply readiness, imply public warning, imply finance value, imply procurement value, imply provider preference, imply sponsor approval, or imply execution consequence.

9.16.3(g) Where confidence or uncertainty displays are defective, misleading, stale, overprecise, overconfident, underqualified, inaccessible, mistranslated, misread, or correction-defective, GCRI Canada shall correct, relabel, downgrade, revise, restrict, supersede, withdraw, or issue public-safe or controlled clarification as appropriate.

9.16.3(h) The controlling rule shall be that dashboard users must be able to see not only what the dashboard shows, but how strongly, how uncertainly, and within what limits it is shown.

***

9.16.4 Dashboard Redaction, Aggregation, Generalization, and Sensitive-Data Controls.\
9.16.4(a) GCRI Canada shall apply redaction, aggregation, generalization, safe-location, masking, suppression, no-download, access-control, delayed-release, controlled-annex, and responsible non-disclosure methods to dashboards and visualizations where direct display would create privacy, cybersecurity, sovereign data, public authority, infrastructure, community, protected knowledge, finance, provider, sponsor, host, operator, legal, export-control, sanctions, controlled-technology, public-safe, or downstream misuse risk.

9.16.4(b) Redaction methods shall remove or obscure fields, labels, metadata, source identities, precise locations, small counts, device identifiers, network identifiers, credentials, keys, tokens, secrets, vulnerability-sensitive details, exploit-sensitive details, public authority restricted details, protected knowledge details, commercially sensitive details, and other unsafe content before dashboard display or export.

9.16.4(c) Aggregation methods shall combine data only where aggregation does not conceal material contradiction, create false consensus, hide data gaps, erase community context, create group harm, enable re-identification, create finance overclaim, create procurement implication, create public authority implication, or imply unsupported confidence.

9.16.4(d) Generalization methods shall reduce precision, simplify categories, coarsen geographies, delay time windows, simplify labels, reduce attribute detail, remove sensitive dimensions, and restrict drill-downs where needed to protect public-safe status, privacy, infrastructure, communities, protected knowledge, public authorities, hosts, operators, providers, sponsors, and markets.

9.16.4(e) Dashboard sensitive-data controls shall prevent unsafe disclosure or inference of personal information, rights-bearing data, health-sensitive information, cyber-sensitive information, infrastructure-sensitive information, public authority restricted information, sovereign-sensitive information, finance-sensitive information, community-protected information, Indigenous or protected knowledge, confidential source information, privileged material, credentials, secrets, keys, tokens, controlled technology, exploit details, sensitive locations, unsafe geospatial precision, unsafe metadata, small-community identifiable information, or operator-sensitive information.

9.16.4(f) Dashboard exports, downloads, screenshots, embedded views, public repositories, API outputs, cached views, copied charts, translated views, third-party shares, media graphics, event slides, and derivative visualizations shall be controlled as potential publications and shall not bypass dashboard public-safe controls.

9.16.4(g) Where redaction, aggregation, generalization, or sensitive-data controls fail, GCRI Canada shall restrict access, correct classification, halt routing, remove unsafe fields, apply safe-location treatment, delete or seal records where appropriate, withdraw or revise outputs, notify affected interfaces where required, and review dependencies.

9.16.4(h) The controlling rule shall be that a dashboard may reveal more than its data table says; therefore visual exposure, exportability, drill-down, metadata, and derivative use must be governed before display.

***

9.16.5 Dashboard Public Authority and Public Warning Controls.\
9.16.5(a) GCRI Canada shall apply public authority and public warning controls to dashboards and visualizations involving public authority data, public authority references, public authority attendance, regulator-listening contexts, emergency-management contexts, public health contexts, public safety contexts, procurement contexts, public finance contexts, official titles, agency references, jurisdictional references, regional hazard evidence, degraded-mode indicators, incident-adjacent indicators, geospatial risk layers, cyber indicators, infrastructure indicators, or public-facing risk summaries.

9.16.5(b) Public authority controls shall identify participating or referenced public authorities, office or function where appropriate, participant capacity, official or non-official status, data-sharing authority, public authority restrictions, agency reference controls, publication limits, retention treatment, permitted use, prohibited use, public-safe status, and correction path.

9.16.5(c) Public warning controls shall review whether dashboard labels, colours, icons, maps, alerts, status indicators, trend lines, heatmaps, hazard terms, incident terms, degraded-mode terms, risk terms, urgency terms, notification features, public-facing summaries, or mobile-friendly display could be misread as a public warning, emergency alert, evacuation instruction, public safety directive, public health order, emergency command, or official public authority communication.

9.16.5(d) Dashboards shall not use warning-like language, alert-like visual grammar, official seals, agency marks, emergency colours, evacuation symbols, official boundary labels, imperative instructions, operational commands, or public authority-like notices unless separately authorized by competent authority and proper record, and unless such use remains consistent with GCRI Canada’s non-executing role.

9.16.5(e) Public authority attendance, data contribution, dashboard access, map access, comments, questions, regulator-listening presence, emergency-management presence, procurement presence, public finance presence, or agency reference shall not imply endorsement, adoption, approval, delegation, official guidance, regulatory determination, funding relevance, procurement relevance, public finance approval, public warning, emergency command, or public-law status.

9.16.5(f) Dashboard public authority-facing outputs shall include, where material, non-delegation, non-endorsement, non-regulatory, non-procurement, non-funding, non-public-finance, no-public-warning, no-emergency-command, confidence, uncertainty, limitation, permitted-use, prohibited-use, and correction language.

9.16.5(g) Where public authority or public warning risk is detected, GCRI Canada shall revise labels, legends, colours, icons, titles, captions, audience controls, access controls, public-safe notes, agency references, release status, and boundary language, or shall restrict, withdraw, or refuse the dashboard as appropriate.

9.16.5(h) The controlling rule shall be that a dashboard may help public authorities learn, but it shall not look or act like public authority unless a competent public authority separately creates that authority through its own lawful record.

***

9.16.6 Dashboard Finance, Insurance, Rating, and Capital-Reader Controls.\
9.16.6(a) GCRI Canada shall apply finance, insurance, rating, capital-reader, GRA, Nexus Rails, RNFD, NFD, UNFSD, resilience-evidence, host-readiness-evidence, node-evidence, finance-safe, public finance, and investment-overclaim controls to dashboards and visualizations that may be used in finance-facing or capital-reader contexts.

9.16.6(b) Finance-facing dashboard records shall identify receiving interface, purpose, evidence classes, data classes, output classes, source records, method records, compute records, model records where applicable, public-safe status, finance-safe status, access class, handling class, confidence, uncertainty, limitations, no-advice boundary, no-rating boundary, no-guarantee boundary, no-public-finance-approval boundary, permitted use, prohibited use, correction path, supersession path, withdrawal path, retraction path where applicable, and dependency links.

9.16.6(c) Dashboards may display resilience evidence, risk evidence, host readiness evidence, node evidence, degraded-mode evidence, observability evidence, confidence records, uncertainty records, limitation statements, compute records, model records, dataset records, benchmark records, Proof Receipt Records, Evidence Pack indicators, Decision Pack indicators, and public-safe summaries for finance-boundary learning only, provided that such display is not framed as finance execution.

9.16.6(d) Dashboard indicators, scores, colours, bands, rankings, comparisons, trend lines, benchmarks, Proof Receipts, public-safe summaries, AI-generated summaries, risk indicators, resilience indicators, readiness-context indicators, or host-context indicators shall not constitute finance-readiness, capital-readiness, insurance-readiness, investment advice, securities recommendation, brokerage, placement, finder activity, lending decision, underwriting decision, insurance approval, rating, guarantee, public finance approval, bankability, fundability, capital commitment, credit quality, insurance quality, investment quality, financial suitability, procurement approval, project approval, or execution consequence by GCRI Canada.

9.16.6(e) Dashboards shall not include or imply investment recommendation, lender recommendation, insurer recommendation, borrower quality, credit quality, expected return, risk-adjusted return, insurance suitability, public finance approval, bankability, fundability, or capital allocation priority unless separately produced by a competent actor under its own lawful authority and not by GCRI Canada.

9.16.6(f) Where dashboard materials are routed to GRA, Nexus Rails, RNFD, NFD, UNFSD, capital readers, insurers, lenders, investors, sponsors, National Companies, Project SPVs, public authorities, or finance-facing audiences, GCRI Canada shall preserve no-investment-advice, no-rating, no-guarantee, no-finance-readiness, no-public-finance-approval, no-procurement, no-provider-preference, no-sponsor-approval, no-execution, confidence, uncertainty, limitation, permitted-use, prohibited-use, and correction language.

9.16.6(g) Where finance-facing misuse or overclaim is detected, GCRI Canada shall correct, relabel, restrict, withdraw, reissue, require removal of misleading references, notify affected GRA, Rails, RNFD, NFD, UNFSD, or other affected interfaces where appropriate, suspend affected interface use, or pursue contractual or legal remedies where appropriate.

9.16.6(h) The controlling rule shall be that dashboards may help capital readers understand evidence, risk, and resilience, but GCRI Canada dashboards shall not rate, advise, finance, insure, guarantee, approve, procure, or execute.

***

9.16.7 Dashboard Provider, Sponsor, and Host Reference Controls.\
9.16.7(a) GCRI Canada shall apply provider-neutrality, sponsor non-control, host-boundary, operator-boundary, and reference controls to dashboards and visualizations that identify, describe, rely on, display, compare, benchmark, summarize, acknowledge, or otherwise reference providers, sponsors, hosts, operators, National Companies, Project SPVs, public authorities, universities, communities, or other actors.

9.16.7(b) Provider reference controls shall identify provider role, provider materials, provider systems, provider data, provider tools, provider equipment, provider AI, provider compute, provider dashboards, provider sensors, provider configuration, provider assumptions, benchmark conditions where any, validation conditions where any, commercial sensitivity, IP sensitivity, cybersecurity sensitivity, conflict status, influence controls, permitted claims, prohibited claims, publication limits, and correction path.

9.16.7(c) Sponsor reference controls shall identify sponsor role, funding or support relationship, convening support, facilities support, technology access, data access, dashboard support, publication support, public authority access limits, provider access limits, conflict status, sponsor non-control language, no-outcome-purchase language, no-evidence-control language, no-publication-control language, no-recognition-control language, no-finance-control language, no-protocol-control language, and correction path.

9.16.7(d) Host and operator reference controls shall identify host or operator role, facility or system context where safe and material, infrastructure context, operational context in public-safe or controlled form, data contribution status, dashboard access status, safe-location treatment, publication limits, no-operation boundary, no-host-approval boundary, no-operator-instruction boundary, no-certification boundary, no-finance boundary, no-procurement boundary, and correction path.

9.16.7(e) Provider participation, provider data, provider equipment, provider benchmark result, provider demonstration, provider dashboard integration, sponsor support, sponsor funding, host participation, host facility access, operator participation, operator data contribution, dashboard visibility, public-safe summary inclusion, or public acknowledgement shall not create endorsement, preferred-provider status, provider ranking, sponsor validation, host approval, operator approval, procurement preference, public tender advantage, certification, recognition, Protocol Authority effect, finance-readiness, market superiority, operational clearance, deployment approval, or execution authority by default.

9.16.7(f) Dashboard comparisons among providers, hosts, operators, sites, regions, technologies, systems, datasets, models, or methods shall be reviewed for false comparability, context collapse, public-safe defects, commercial sensitivity, provider preference, sponsor validation, procurement implication, finance implication, certification implication, recognition implication, protocol implication, public authority implication, and correctionability.

9.16.7(g) Where provider, sponsor, host, or operator reference defects are detected, GCRI Canada shall require disclosure correction, boundary-language revision, reference removal, benchmark correction, dashboard relabeling, public-safe correction, controlled notice, access restriction, interface suspension, contract remedy, or legal action where appropriate.

9.16.7(h) The controlling rule shall be that dashboards may show actors and contributions only where the display does not become endorsement, sponsor validation, host approval, operator instruction, procurement preference, finance signal, certification, recognition, or execution by implication.

***

9.16.8 Dashboard Versioning, Change Logs, Uptime / Downtime Status, Incident Notices, and Correction Path.\
9.16.8(a) GCRI Canada shall maintain dashboard versioning, change logs, update logs, uptime and downtime status where material, incident notices, correction paths, supersession paths, withdrawal paths, retraction paths where applicable, archive paths, and dependency records for material dashboards and visualizations.

9.16.8(b) Dashboard versioning records shall identify dashboard title or identifier, version, release date, release status, audience, access class, handling class, public-safe status, source versions, dataset versions, method versions, model versions where applicable, compute workload relationship, dashboard component versions, map layer versions, API versions, confidence-display versions, uncertainty-display versions, boundary-language versions, and correction status.

9.16.8(c) Change logs shall identify source changes, data changes, method changes, model changes, dashboard logic changes, visualization changes, label changes, legend changes, colour changes, score changes, confidence changes, uncertainty changes, limitation changes, access changes, public-safe changes, boundary-language changes, correction changes, and dependency effects.

9.16.8(d) Uptime and downtime status records shall identify whether a dashboard is live, near-real-time, periodic, historical, archived, frozen, paused, degraded, under review, restricted, corrected, superseded, withdrawn, retired, or unavailable, and shall identify stale-data status and public-safe effect where material.

9.16.8(e) Incident notices shall identify dashboard error, map error, API error, data delay, stale source, incorrect source, incorrect label, incorrect colour, incorrect score, misleading indicator, public-safe defect, access defect, export defect, cyber incident, privacy incident, public authority overclaim, finance overclaim, provider preference, sponsor validation, host approval implication, operator-control implication, public warning implication, or correction failure affecting a dashboard.

9.16.8(f) Correction paths shall identify how users can challenge, question, correct, supersede, withdraw, or report misuse of dashboard outputs, and shall identify responsible steward, reviewer, notice path, affected dependencies, archive treatment, and continuing limitations.

9.16.8(g) Where a dashboard is corrected, superseded, withdrawn, retracted, frozen, restricted, retired, or archived, GCRI Canada shall update status indicators, remove or relabel affected outputs where appropriate, notify affected interfaces where required, review downstream dependencies, and prevent continued reliance on outdated or misleading dashboard versions.

9.16.8(h) The controlling rule shall be that dashboard trust requires version memory: users must know what changed, when it changed, why it changed, what was affected, and what should no longer be relied upon.

***

9.16.9 Dashboard Misuse Detection and Public Clarification.\
9.16.9(a) GCRI Canada shall maintain dashboard misuse detection and public clarification methods for identifying and responding to overclaim, misquotation, screenshot misuse, out-of-context reuse, unauthorized embedding, unauthorized export, unauthorized API reuse, provider misuse, sponsor misuse, host misuse, operator misuse, public authority misuse, finance-facing misuse, procurement-facing misuse, media overclaim, social-media distortion, public warning implication, public authority implication, certification implication, recognition implication, protocol implication, finance implication, provider-preference implication, sponsor-validation implication, host-approval implication, operator-instruction implication, market-signal implication, or execution implication.

9.16.9(b) Misuse detection may include monitoring public references, interface feedback, user reports, correction requests, media references, provider materials, sponsor materials, host materials, operator materials, finance-facing materials, public authority materials, procurement materials, public claims, repository forks, screenshots, copied charts, embedded views, API reuse, and derivative visualizations where lawful, proportionate, and consistent with GCRI Canada’s public-benefit purpose.

9.16.9(c) Dashboard materials shall include, where appropriate, citation instructions, boundary language, screenshot cautions, export restrictions, permitted-use notices, prohibited-use notices, stale-data warnings, correction links, version identifiers, public-safe limitations, and removal or correction request pathways.

9.16.9(d) Where misuse is detected, GCRI Canada may issue public-safe clarification, controlled clarification, correction notice, misuse notice, request for removal, request for relabeling, interface notice, provider notice, sponsor notice, host notice, operator notice, public authority notice, GRF notice, GRA notice, Protocol Authority notice, or legal notice as appropriate.

9.16.9(e) Public clarification shall be proportionate, public-safe, source-lined where appropriate, non-defamatory, non-regulatory, non-public-warning, non-financial, non-procurement, non-certifying, non-recognizing, non-protocol-conferring, non-provider-preferential, non-sponsor-validating, and correction-focused.

9.16.9(f) Clarification shall not itself create public authority decision, public warning, emergency command, regulatory finding, law enforcement finding, finance-readiness, investment advice, procurement approval, certification, recognition, protocol effect, provider ranking, sponsor finding, host approval, operator instruction, market authority, legal status, or execution consequence by default.

9.16.9(g) Where misuse reveals systemic dashboard design risk, GCRI Canada shall update dashboard methods, labels, legends, boundary language, export controls, API controls, public-safe controls, training, interface agreements, and assurance procedures.

9.16.9(h) The controlling rule shall be that dashboard stewardship continues after release because visual evidence can be copied faster than its limits can be remembered.

***

9.16.10 Dashboard Records, Review, Correction, Withdrawal, and Archive.\
9.16.10(a) GCRI Canada shall maintain, or cause to be maintained, dashboard and visualization records for material dashboard methods, visualization systems, data sources, datasets, models, compute workloads, map layers, APIs, Evidence Packs, Decision Packs, public-safe outputs, controlled annexes, disputes, incidents, misuse events, corrections, dependencies, assurance reviews, withdrawal, retirement, archive, and closeout events.

9.16.10(b) Dashboard records shall identify dashboard title or identifier, visualization class, system class, provider where any, operator where any, host where any, public authority context where any, community context where any, technology domain, risk domain, data class, evidence class, output class, audience class, access class, handling class, public-safe status, privacy status, cybersecurity status, sovereign data status, infrastructure-sensitive status, public authority status, finance-sensitive status, provider-sensitive status, sponsor-sensitive status, operator-sensitive status, host-sensitive status, community-protected status, Indigenous or protected knowledge status, legal sensitivity, license status, export-control sensitivity, sanctions sensitivity, controlled-technology sensitivity, permitted uses, prohibited uses, publication limits, and correction path.

9.16.10(c) Dashboard review records shall identify review cycle, reviewers, source review, dataset review, compute review, model review, dashboard logic review, visualization review, accessibility review, translation review where applicable, public-safe review, public authority boundary review, public warning review, finance-boundary review, procurement-boundary review, provider-neutrality review, sponsor non-control review, host-boundary review, operator-boundary review, privacy review, cybersecurity review, sovereign data review, protected knowledge review, export-control review where applicable, sanctions review where applicable, controlled-technology review where applicable, and correction review.

9.16.10(d) Correction records shall identify corrected source, corrected dataset, corrected method, corrected compute workload, corrected model, corrected dashboard logic, corrected visualization, corrected chart, corrected map layer, corrected API, corrected label, corrected legend, corrected colour, corrected indicator, corrected confidence display, corrected uncertainty display, corrected limitation statement, corrected public-safe output, corrected public authority reference, corrected provider reference, corrected sponsor reference, corrected host reference, corrected operator reference, corrected community reference, corrected boundary language, prior status, corrected status, effective date, reviewer, affected dependencies, notice decision, access change, archive treatment, and continuing limitations.

9.16.10(e) Withdrawal or retraction records shall be used where dashboard or visualization outputs should no longer be used or relied upon because of material error, unsafe disclosure, public-safe defect, false precision, misleading visual design, stale data, source defect, model defect, compute defect, label defect, legend defect, colour defect, confidence defect, uncertainty defect, boundary defect, protected knowledge exposure, community harm risk, public authority confusion, public warning implication, finance overclaim, procurement implication, provider-preferential framing, sponsor-validation framing, host approval implication, operator-control implication, privacy defect, cybersecurity defect, sovereign data issue, cross-border defect, infrastructure-risk exposure, regulatory overclaim, or correction failure.

9.16.10(f) Supersession and retirement records shall identify replacement dashboard, replacement visualization, changed source base, changed data model, changed method, changed compute, changed model, changed audience, changed access class, changed public-safe status, changed confidence display, changed uncertainty display, changed limitations, changed boundary language, continuing validity where any, discontinued reliance where any, and downstream dependency treatment.

9.16.10(g) Archive records shall identify archived version, archive reason, archive date, archive location, retained records, access limits, public-safe status, legal hold where applicable, deletion or sealing status where applicable, citation status, continuing prohibited uses, supersession relationship, correction relationship, and closeout status.

9.16.10(h) Dashboard records shall be linked, where applicable, to National Dense Core records, Regional Observatory Cluster records, Cluster records, Hub records, Node records, Hotspot records, AI-RAN records, DePIN records, sensor records, geospatial records, cyber telemetry records, digital twin records, Observatory Methods Register entries, Evidence Register entries, Source Comparison Records, Dataset Register entries, Model Register entries, System Card entries, Benchmark Card entries, Compute Workload Records, Compute Environment Records, Inference Records, Human Review Records, Retrieval and Embedding Records, Proof Receipt Records, Public-Safe Output Records, AI Incident Records, Correction Records, Dependency Records, Truth Engine Records, Nexus Risk Management records, public authority records, GRF interface records, GRA interface records, Protocol Authority interface records, RNFD records, Nexus Rails records, Regional Nexus Consortium records, National Nexus Consortium records, National Company records, Project SPV records, operator records, provider records, sponsor records, host records, community records, university records, Nexus interface records, and public claims records.

9.16.10(i) Dashboard records, review records, correction records, supersession records, withdrawal records, retraction records, retirement records, archive records, notices, assurance, and closeout shall not create certification, recognition, finance-readiness, public authority decision, regulatory finding, procurement approval, provider endorsement, sponsor approval, host approval, operator approval, rating, guarantee, public warning, emergency command, protocol effect, operational clearance, legal status, market authority, infrastructure operation, remediation approval, deployment approval, national authority, regional authority, or execution consequence by default.

9.16.10(j) The controlling rule shall be that dashboards and visualizations are trustworthy only when their sources, audiences, classifications, visual meanings, limitations, updates, corrections, withdrawals, and archives remain recorded with enough precision to prevent display from becoming unsupported authority.

### 9.17 Degraded-Mode Awareness and Continuity Methods

9.17.1 Degraded-Mode Awareness as Evidence and Learning Function.\
9.17.1(a) GCRI Canada shall steward degraded-mode awareness and continuity methods as Observatory evidence and learning methods for identifying, recording, comparing, interpreting, public-safe summarizing, and correcting evidence concerning reduced visibility, impaired function, disrupted communications, degraded infrastructure, constrained compute, failed sensors, missing data, cyber incidents, power loss, connectivity loss, public authority constraints, host constraints, operator constraints, provider outages, community disruption, environmental stress, and other conditions under which systems, evidence flows, or institutional understanding may be incomplete or impaired.

9.17.1(b) Degraded-mode awareness may support Observatory Nodes, Hubs, Clusters, Hotspots, Regional Observatory Clusters, National Dense Nexus Cores, AI-RAN systems, O-RAN systems, private wireless systems, DePIN systems, sensor systems, cyber-physical systems, geospatial systems, digital twins, dashboards, public authority learning, host learning, operator learning, provider-neutral technical review, Nexus Truth Engine inputs, Nexus Risk Management inputs, GRF inputs, GRA inputs, Protocol Authority inputs, Evidence Packs, Decision Packs, Academy materials, public-safe summaries, and correction workflows.

9.17.1(c) Degraded-mode awareness shall be treated as an evidence and learning function, not as emergency command, public warning, infrastructure operation, public authority decision, procurement action, finance-readiness, certification, recognition, protocol effect, provider preference, sponsor approval, host approval, operator instruction, operational clearance, deployment approval, market signal, or execution consequence by default.

9.17.1(d) Degraded-mode methods shall be records-valid, source-lined, context-aware, continuity-aware, uncertainty-aware, limitation-aware, public-safe, privacy-protective, cybersecurity-controlled, sovereignty-compatible, community-sensitive, infrastructure-sensitive, provider-neutral, sponsor-independent, host-bounded, operator-bounded, and correctionable.

9.17.1(e) GCRI Canada’s stewardship of degraded-mode awareness shall not make GCRI Canada an emergency-management actor, public warning issuer, incident commander, infrastructure operator, telecommunications operator, cyber operator, utility operator, public authority, regulator, procurement actor, finance actor, certification body, recognition body, Protocol Authority, provider, sponsor, host, operator, National Company, Project SPV, or execution actor by default.

9.17.1(f) Degraded-mode evidence shall preserve the distinction between degraded visibility, degraded evidence, degraded infrastructure, degraded service, degraded continuity, degraded confidence, increased uncertainty, public authority context, operator context, host context, provider context, community context, public-safe summary, and any authority-bearing decision or operational action made by a competent separate actor.

9.17.1(g) Where degraded-mode evidence is used externally or publicly, GCRI Canada shall preserve controlled vocabulary, source lineage, confidence downgrade where appropriate, uncertainty increase where appropriate, limitations, stale-data treatment, public-safe status, no-public-warning language, no-emergency-command language, no-public-authority language, no-finance language, no-procurement language, no-certification language, no-recognition language, no-protocol-effect language unless separately created by Protocol Authority, no-provider-ranking language, no-sponsor-finding language, no-host-approval language, no-operator-instruction language, no-infrastructure-operation language, and correction path where material.

9.17.1(h) The controlling rule shall be that degraded-mode awareness helps GCRI Canada and authorized interfaces understand what is known, unknown, impaired, unavailable, or uncertain during disruption, but it does not authorize GCRI Canada to warn, command, operate, approve, finance, certify, recognize, procure, regulate, or execute.

***

9.17.2 Degraded-Mode Signals, Continuity Indicators, Fallback Operations, Connectivity Loss, Compute Loss, Sensor Loss, Power Loss, Data Loss, Cyber Incident, and Infrastructure Stress Signals.\
9.17.2(a) GCRI Canada shall steward methods for identifying and classifying degraded-mode signals, continuity indicators, fallback-operation evidence, connectivity-loss evidence, compute-loss evidence, sensor-loss evidence, power-loss evidence, data-loss evidence, cyber-incident evidence, infrastructure-stress signals, communications impairment, dashboard degradation, API degradation, map-layer staleness, model degradation, and evidence-flow interruption.

9.17.2(b) Degraded-mode signal records shall identify signal source, signal class, affected system, affected Node, affected Hub, affected Cluster, affected Hotspot, affected Regional Observatory Cluster, affected National Dense Nexus Core, affected data source, affected compute environment, affected model, affected dashboard, affected map, affected API, affected interface, timestamp, duration where known, confidence, uncertainty, limitations, public-safe status, and correction path.

9.17.2(c) Continuity indicators shall identify the continuing availability, partial availability, degraded availability, fallback availability, or unavailability of evidence sources, sensors, reference sensors, communications paths, compute workloads, sovereign compute environments, dashboards, maps, APIs, public authority rooms, controlled rooms, data rooms, clean rooms, host interfaces, operator interfaces, provider interfaces, community interfaces, and correction channels.

9.17.2(d) Fallback-operation evidence may include records of alternate data sources, manual observations, local records, delayed uploads, offline capture, store-and-forward telemetry, backup compute, alternate connectivity, reference sensors, public authority context, operator status statements, host statements, community observations, provider status notices, and controlled-room summaries, provided that such evidence is classified, source-lined, qualified, and corrected when primary evidence becomes available.

9.17.2(e) Connectivity loss, compute loss, sensor loss, power loss, and data loss shall be recorded as evidence conditions affecting confidence, uncertainty, limitation statements, dashboard status, map status, API status, output class, public-safe status, and dependency treatment. Absence of evidence under degraded conditions shall not be presented as evidence of absence.

9.17.2(f) Cyber incident and infrastructure stress signals shall be handled with heightened cyber-sensitive, infrastructure-sensitive, public authority, operator, host, community, provider, sponsor, sovereign data, and public-safe controls because degraded-mode information may reveal vulnerability, outage, dependency, location, timing, operational weakness, or public safety sensitivity.

9.17.2(g) Degraded-mode indicators, continuity indicators, outage indicators, fallback indicators, incident-adjacent indicators, infrastructure-stress indicators, dashboard-status markers, or public-safe summaries shall not be presented as public warnings, emergency commands, service assurances, operator instructions, procurement priorities, finance signals, provider ratings, sponsor findings, certifications, recognitions, protocol effects, public authority decisions, operational clearances, deployment approvals, or execution instructions.

9.17.2(h) Where degraded-mode signals are incomplete, stale, contradicted, spoofed, tampered, provider-influenced, sponsor-influenced, public-safe defective, or later corrected, GCRI Canada shall qualify, downgrade, restrict, correct, supersede, withdraw, archive, or route the affected evidence for review as appropriate.

9.17.2(i) The controlling rule shall be that degraded-mode signals and continuity indicators explain the condition of evidence and systems under stress; they do not command the response to that stress.

***

9.17.3 Degraded-Mode Methods for Nodes, Hubs, Clusters, National Dense Cores, and Regional Systems.\
9.17.3(a) GCRI Canada shall steward degraded-mode methods for Observatory Nodes, Hubs, Clusters, Hotspots, Regional Observatory Clusters, National Dense Nexus Cores, and other regional or national Observatory systems to preserve evidence integrity, continuity awareness, public-safe learning, and correctionability during disruption.

9.17.3(b) Node degraded-mode methods shall identify local signal loss, sensor failure, reference sensor unavailability, local connectivity loss, edge compute loss, power loss, host access constraints, local data loss, field access constraints, public authority constraints, community constraints, provider outage, dashboard degradation, map degradation, public-safe output effect, and correction path.

9.17.3(c) Hub degraded-mode methods shall identify multi-Node evidence-flow interruption, aggregation degradation, routing delays, controlled-room unavailability, data-room restrictions, public authority room constraints, provider interface constraints, sponsor-related constraints where any, host communication constraints, community communication constraints, dashboard or map partial availability, API restrictions, and dependency effects.

9.17.3(d) Cluster degraded-mode methods shall identify cross-Node, cross-host, cross-domain, regional, technological, or risk-domain degradation; missing Nodes; unavailable Hubs; inconsistent signals; degraded interoperability; mismatched records; stale layers; cyber-sensitive restrictions; public-safe restrictions; confidence downgrades; uncertainty increases; and affected downstream materials.

9.17.3(e) Regional Observatory Cluster degraded-mode methods shall identify regional connectivity impairment, regional hazard evidence gaps, regional host readiness evidence gaps, public authority learning constraints, cross-border data constraints, community safeguard constraints, Indigenous or protected knowledge restrictions, infrastructure stress, public-safe communication limits, and regional dependency effects.

9.17.3(f) National Dense Nexus Core degraded-mode methods shall identify national-scale evidence-flow impairment, sovereign compute interruption, compute-to-data restriction, public authority data constraint, national dashboard degradation, national map degradation, API restriction, key or credential incident, cyber incident, cross-border constraint, national public-safe publication limit, and interface dependency effects.

9.17.3(g) Degraded-mode methods across Nodes, Hubs, Clusters, Regional Observatory Clusters, and National Dense Nexus Cores shall preserve legal separateness and role separation among GCRI Canada, GCRI US, The Global Risks Forum (GRF), The Global Risks Alliance (GRA), Nexus Standards / Protocol Authority, Regional Nexus Consortiums, National Nexus Consortiums, National Companies, Project SPVs, public authorities, operators, providers, sponsors, hosts, universities, communities, and other actors.

9.17.3(h) Where degraded-mode methods are used in dashboards, maps, Evidence Packs, Decision Packs, public authority learning materials, GRF inputs, GRA inputs, Protocol Authority inputs, Nexus Risk Management materials, Nexus Rails materials, National Company materials, Project SPV materials, provider-facing materials, sponsor-facing materials, host-facing materials, operator-facing materials, community-facing materials, Academy materials, media materials, or public-safe summaries, the output shall include confidence, uncertainty, limitations, stale-data status, degradation status, permitted use, prohibited use, boundary language, and correction path.

9.17.3(i) The controlling rule shall be that degraded-mode methods must travel with the architecture they describe, because evidence continuity is weakest when systems are most stressed.

***

9.17.4 Degraded-Mode Outputs as Decision-Support, Not Emergency Command or Public Warning by GCRI Canada.\
9.17.4(a) Degraded-mode outputs stewarded, produced, received, reviewed, dashboarded, mapped, summarized, routed, or corrected by GCRI Canada shall be treated as decision-supporting evidence artifacts, continuity records, degraded-visibility records, outage-adjacent records, incident-adjacent records, resilience-learning materials, public-safe summaries, controlled annex inputs, Evidence Pack inputs, Decision Pack inputs, Verifiable Compute records, Verifiable Intelligence inputs, Truth Engine inputs, Observatory outputs, Nexus Risk Management inputs, GRF inputs, GRA inputs, Protocol Authority inputs, public authority learning materials, host learning materials, operator learning materials, provider-neutral review materials, Academy materials, or correction records, depending on their recorded output class.

9.17.4(b) Degraded-mode outputs shall not constitute emergency commands, public warnings, public authority decisions, official hazard designations, evacuation instructions, public safety directives, public health orders, operator instructions, infrastructure commands, regulatory approvals, procurement approvals, funding approvals, public finance approvals, finance-readiness, capital-readiness, insurance-readiness, investment advice, ratings, guarantees, certifications, recognitions, maturity records, claims approvals, protocol effects, conformance determinations, Nexus-compatible status, provider endorsements, sponsor approvals, host approvals, operational clearances, infrastructure operation, legal status, market authority, deployment approvals, or execution consequences by default.

9.17.4(c) The fact that a degraded-mode output is real-time, near-real-time, dashboard-visible, map-visible, sensor-fed, public authority-relevant, operator-relevant, host-relevant, provider-supplied, sponsor-supported, cyber-incident-adjacent, infrastructure-stress-adjacent, AI-generated, model-assisted, signed, hashed, timestamped, or supported by a Proof Receipt shall not convert it into command, warning, authority, approval, certification, finance value, procurement value, operational clearance, or execution consequence.

9.17.4(d) Degraded-mode outputs shall identify source records, degraded source status, missing source status, data lineage, method records, compute records where applicable, model records where applicable, dashboard or map records where applicable, human review where material, output class, confidence, uncertainty, limitations, stale-data status, public-safe status, permitted use, prohibited use, boundary language, correction path, supersession path, withdrawal path, retraction path where applicable, and dependency links.

9.17.4(e) Where degraded-mode outputs are routed to public authorities, National Dense Nexus Core interfaces, Regional Observatory Cluster interfaces, Hubs, Nodes, Hotspots, GRF, GRA, Protocol Authority, Nexus Risk Management, Nexus Rails, National Nexus Consortiums, National Companies, Project SPVs, providers, sponsors, hosts, operators, universities, communities, Academy materials, media materials, or public audiences, the receiving context shall be recorded and boundary language shall be preserved.

9.17.4(f) Where degraded-mode outputs are overclaimed, misused, misclassified, publicly misread, public-warning-inflated, authority-inflated, finance-inflated, procurement-inflated, certification-inflated, recognition-inflated, provider-preferential, sponsor-validating, host-approval-implying, operator-instruction-implying, public-safe defective, or correction-defective, GCRI Canada shall correct, relabel, restrict, withdraw, reissue, notify affected interfaces where appropriate, and review dependencies.

9.17.4(g) No ambiguity shall be resolved in favour of degraded-mode authority. Where there is doubt whether a degraded-mode output creates authority or only supports evidence, the interpretation preserving GCRI Canada’s non-execution role, public warning boundaries, emergency-command boundaries, public authority boundaries, finance boundaries, procurement neutrality, provider neutrality, sponsor non-control, host boundaries, operator boundaries, community safeguards, Protocol Authority role separation, GRF role separation, GRA role separation, validity-by-record, correctionability, and public trust shall prevail.

9.17.4(h) The controlling rule shall be that degraded-mode outputs may support decisions by competent actors, but they are not emergency commands or public warnings by GCRI Canada.

***

9.17.5 Public Authority and Operator Interface Controls.\
9.17.5(a) GCRI Canada shall apply heightened public authority and operator interface controls to degraded-mode awareness where public authorities, operators, public authority data, operator data, emergency-management contexts, public safety contexts, public health contexts, critical infrastructure contexts, telecommunications contexts, cyber incident contexts, public finance contexts, procurement contexts, regulator-listening contexts, agency references, operator references, jurisdictional references, or public-facing risk summaries are involved.

9.17.5(b) Public authority interface records shall identify participating or referenced public authorities, office or function where appropriate, participant capacity, official or non-official status, data-sharing authority, public authority restrictions, agency reference controls, publication limits, retention treatment, permitted use, prohibited use, public-safe status, and correction path.

9.17.5(c) Operator interface records shall identify operator identity where safe and material, operator role, system context, infrastructure context, service context, operational context in public-safe or controlled form, data contribution status, telemetry contribution status, dashboard access status, map access status, incident context, cybersecurity sensitivity, infrastructure sensitivity, commercial sensitivity, publication limits, no-operation boundary, no-operator-instruction boundary, no-service-assurance boundary, no-remediation-approval boundary, no-certification boundary, no-finance boundary, no-procurement boundary, and correction path.

9.17.5(d) Degraded-mode public authority-facing materials shall include, where material, non-delegation, non-endorsement, non-regulatory, non-procurement, non-funding, non-public-finance, no-public-warning, no-emergency-command, no-official-guidance, confidence, uncertainty, limitation, permitted-use, prohibited-use, stale-data, and correction language.

9.17.5(e) Degraded-mode operator-facing materials shall include, where material, no-operator-instruction, no-remediation-approval, no-operational-clearance, no-service-assurance, no-infrastructure-operation, no-public-warning, no-public-authority, no-procurement, no-finance, no-certification, confidence, uncertainty, limitation, permitted-use, prohibited-use, stale-data, and correction language.

9.17.5(f) Public authority attendance, operator participation, data contribution, telemetry contribution, incident context, dashboard access, map access, comments, questions, status statements, regulator-listening presence, emergency-management presence, procurement presence, public finance presence, or agency or operator reference shall not imply endorsement, adoption, approval, delegation, official guidance, regulatory determination, funding relevance, procurement relevance, public finance approval, public warning, emergency command, operational clearance, service assurance, remediation approval, or public-law status.

9.17.5(g) Where degraded-mode materials create public authority confusion, public warning implication, emergency-command implication, operator-control implication, service-assurance implication, remediation-approval implication, regulatory implication, law enforcement implication, procurement implication, finance implication, or public-safe defect, GCRI Canada shall revise labels, legends, colours, icons, titles, captions, access controls, agency references, operator references, release status, boundary language, or shall restrict, withdraw, correct, or refuse the material as appropriate.

9.17.5(h) The controlling rule shall be that public authorities and operators may receive degraded-mode learning, but their presence does not turn GCRI Canada into public authority, incident commander, operator, or emergency actor.

***

9.17.6 Host and Provider Interface Controls.\
9.17.6(a) GCRI Canada shall apply host-boundary, provider-neutrality, sponsor non-control where relevant, and public-safe controls to degraded-mode awareness involving hosts, providers, sponsors, facilities, equipment, systems, sensors, AI-RAN components, DePIN devices, compute environments, dashboards, maps, APIs, cybersecurity tools, field support, technical support, incident-adjacent information, or continuity information.

9.17.6(b) Host interface records shall identify host identity, host role, facility or site context where safe and material, infrastructure context, operational context in public-safe or controlled form, data contribution status, sensor contribution status, compute contribution status, degraded-mode context, access class, handling class, safe-location treatment, publication limits, no-operation boundary, no-host-approval boundary, no-certification boundary, no-finance boundary, no-procurement boundary, no-public-warning boundary, and correction path.

9.17.6(c) Provider interface records shall identify provider identity, provider role, provider materials, provider systems, provider data, provider tools, provider equipment, provider AI, provider compute, provider dashboards, provider sensors, provider cybersecurity materials, provider status notices, configuration context, benchmark conditions where any, validation conditions where any, commercial sensitivity, IP sensitivity, cybersecurity sensitivity, infrastructure sensitivity, conflict status, influence controls, permitted claims, prohibited claims, publication limits, and correction path.

9.17.6(d) Host or provider status statements, outage notices, degradation notices, equipment status, maintenance status, incident-adjacent statements, availability claims, capacity claims, coverage claims, recovery claims, remediation claims, dashboard access, map access, technical participation, or public-safe summary inclusion shall not create host approval, provider endorsement, provider ranking, procurement preference, public tender advantage, finance-readiness, certification, recognition, Protocol Authority effect, operational clearance, service assurance, remediation approval, deployment approval, or execution authority by default.

9.17.6(e) Provider-supplied degraded-mode evidence shall not be treated as neutral, complete, independent, public-safe, procurement-relevant, finance-relevant, certified, recognized, or protocol-effective merely because supplied by a reputable provider, public authority-used provider, sponsor-supported provider, host-preferred provider, or Nexus-participating provider.

9.17.6(f) Degraded-mode materials referencing hosts or providers shall be reviewed for provider preference, host approval implication, sponsor validation where any, procurement implication, finance implication, public authority implication, public warning implication, security exposure, infrastructure sensitivity, commercial sensitivity, false comparability, reputational harm, and correctionability.

9.17.6(g) Where host or provider interface defects are detected, GCRI Canada shall require disclosure correction, boundary-language revision, reference removal, status correction, dashboard relabeling, map relabeling, public-safe correction, controlled notice, access restriction, interface suspension, contract remedy, or legal action where appropriate.

9.17.6(h) The controlling rule shall be that hosts and providers may supply degraded-mode evidence, but their participation shall not turn disruption evidence into endorsement, procurement advantage, finance signal, certification, service assurance, remediation approval, or execution.

***

9.17.7 Degraded-Mode Public-Safe Communication Controls.\
9.17.7(a) GCRI Canada shall apply heightened public-safe communication controls to degraded-mode summaries, dashboards, maps, reports, APIs, technical notes, Academy materials, public authority learning materials, GRF-facing materials, GRA-facing materials, Protocol Authority-facing materials, host-facing materials, operator-facing materials, provider-facing materials, sponsor-facing materials, community-facing materials, media materials, event materials, repository materials, website materials, and public claims.

9.17.7(b) Public-safe review shall assess whether degraded-mode communications disclose or enable misuse of personal information, rights-bearing data, health-sensitive data, cyber-sensitive information, infrastructure-sensitive information, public authority restricted information, sovereign-sensitive information, finance-sensitive information, commercially sensitive information, community-protected information, Indigenous or protected knowledge, confidential source information, privileged material, credentials, secrets, keys, tokens, controlled technology, exploit details, outage-sensitive information, incident-sensitive information, dependency-sensitive information, sensitive locations, unsafe geospatial precision, unsafe metadata, operator-sensitive information, or national-security-adjacent sensitive information.

9.17.7(c) Degraded-mode communications shall be reviewed for public alarm, false reassurance, public warning implication, emergency-command implication, official-status implication, public authority implication, operator-instruction implication, service-assurance implication, infrastructure-vulnerability exposure, cyber-vulnerability exposure, community harm, stigma, retaliation, market overreaction, finance overclaim, procurement implication, provider preference, sponsor validation, media overclaim, and downstream misuse.

9.17.7(d) Public-safe degraded-mode outputs shall include, where material, public-safe omissions, responsible non-disclosure basis, confidence downgrade, uncertainty increase, limitations, data-gap status, stale-data status, affected evidence status, no-public-warning language, no-emergency-command language, no-public-authority language, no-operator-instruction language, no-service-assurance language, no-finance language, no-procurement language, no-certification language, no-recognition language, no-provider-ranking language, no-sponsor-finding language, permitted use, prohibited use, and correction path.

9.17.7(e) Degraded-mode dashboards and maps shall be reviewed for warning-like colours, emergency-like icons, alert-like labels, outage-like public meaning, incident-like public meaning, official-looking banners, evacuation-like symbols, urgency cues, geospatial sensitivity, infrastructure exposure, cyber-sensitive detail, operator-sensitive detail, protected knowledge exposure, false precision, overconfident status indicators, misleading legends, drill-down risk, export risk, screenshot risk, API exposure, stale-data risk, and third-party reuse risk.

9.17.7(f) Where degraded-mode outputs cannot be made public-safe without increasing risk, creating public alarm, creating false reassurance, exposing restricted data, exposing protected knowledge, exposing infrastructure or cyber vulnerabilities, creating public warning implication, creating official status implication, creating finance overclaim, creating procurement implication, creating operator risk, or creating unauthorized authority, GCRI Canada may use controlled annexes, controlled-room review, aggregation, generalization, safe-location treatment, delayed release, responsible non-disclosure, limited public-safe statement, or no-publication treatment.

9.17.7(g) Where degraded-mode public-safe communications are corrected, restricted, superseded, withdrawn, retracted, misused, misquoted, mistranslated, screenshot out of context, or made stale by later evidence, GCRI Canada shall update public-safe output records, issue public-safe or controlled correction where appropriate, and review affected dependencies and interfaces.

9.17.7(h) The controlling rule shall be that degraded-mode communication must help audiences understand limits and disruption without causing alarm, false certainty, exposure, authority confusion, or execution drift.

***

9.17.8 Degraded-Mode After-Action Evidence and Learning Records.\
9.17.8(a) GCRI Canada may steward after-action evidence and learning records for degraded-mode events, near misses, interruptions, outages, continuity failures, fallback operations, cyber incidents, sensor failures, compute failures, connectivity failures, power failures, data losses, dashboard degradations, map degradations, API degradations, public-safe communication events, interface failures, and correction failures.

9.17.8(b) After-action records shall identify event title or identifier, affected systems, affected Nodes, affected Hubs, affected Clusters, affected Hotspots, affected Regional Observatory Clusters, affected National Dense Nexus Cores, affected sources, affected datasets, affected compute environments, affected workloads, affected models, affected sensors, affected dashboards, affected maps, affected APIs, affected public authority interfaces, affected host interfaces, affected operator interfaces, affected provider interfaces, affected community interfaces, affected public-safe outputs, timeline where safe, evidence basis, confidence, uncertainty, limitations, public-safe status, and correction path.

9.17.8(c) After-action learning may include source availability analysis, data-gap analysis, sensor-failure analysis, compute-failure analysis, connectivity-failure analysis, cyber incident learning, dashboard or map failure analysis, access-control learning, public-safe communication learning, interface learning, community safeguard learning, provider-neutrality learning, sponsor non-control learning, operator-boundary learning, and correction learning.

9.17.8(d) After-action records shall distinguish lessons learned by GCRI Canada from official findings, regulatory findings, law enforcement findings, emergency-management findings, operator findings, provider findings, host findings, public authority decisions, procurement decisions, finance determinations, certifications, recognitions, protocol effects, or execution decisions made by other competent actors.

9.17.8(e) After-action learning shall not assign legal liability, direct remediation, certify remediation, approve operations, approve procurement, approve financing, rate providers, rank hosts, command operators, issue public warnings, create regulatory positions, or create execution consequences by default.

9.17.8(f) Where after-action records rely on sensitive cyber, infrastructure, public authority, operator, host, provider, community, protected knowledge, personal, sovereign, or finance-sensitive information, GCRI Canada shall use controlled-room treatment, redaction, aggregation, public-safe summaries, responsible non-disclosure, access restrictions, retention controls, and correction paths proportionate to risk.

9.17.8(g) After-action records shall support method updates, training updates, dashboard updates, map updates, compute control updates, cyber control updates, public-safe communication updates, interface agreement updates, assurance updates, and correction discipline where evidence supports such action.

9.17.8(h) The controlling rule shall be that after-action learning may improve Observatory methods, but it shall not retroactively convert evidence learning into command, warning, liability finding, certification, procurement, finance, or execution.

***

9.17.9 Degraded-Mode Correction, Supersession, and Methods Improvement.\
9.17.9(a) GCRI Canada shall maintain correction, supersession, withdrawal, retraction, method-update, training-update, technical-control-update, dashboard-update, map-update, API-update, interface-update, and assurance-update methods for degraded-mode evidence and outputs.

9.17.9(b) Correction shall be required where degraded-mode evidence or outputs contain material error, stale source status, incorrect outage status, incorrect continuity status, incorrect confidence, understated uncertainty, missing limitation, false public-safe status, unsafe disclosure, public warning implication, emergency-command implication, public authority confusion, operator-instruction implication, service-assurance implication, finance overclaim, procurement implication, provider preference, sponsor validation, host approval implication, protected knowledge exposure, privacy defect, cybersecurity defect, sovereign data issue, cross-border defect, infrastructure-risk exposure, or correction failure.

9.17.9(c) Supersession shall be used where degraded-mode outputs are replaced by restored evidence, fuller evidence, corrected evidence, post-incident evidence, after-action evidence, updated source records, updated compute records, updated model records, updated dashboard records, updated map records, updated API records, updated public authority context, updated operator context, updated host context, updated provider context, updated community context, or updated public-safe classification.

9.17.9(d) Withdrawal or retraction shall be used where degraded-mode materials should no longer be used or relied upon because they are materially inaccurate, unsafe, misleading, overclaimed, unsupported, public-safe defective, authority-confusing, warning-adjacent, command-adjacent, provider-preferential, sponsor-validating, privacy-defective, cyber-defective, protected-knowledge-defective, infrastructure-risk-exposing, or correction-defective.

9.17.9(e) Method improvement records shall identify the degraded-mode lesson, evidence basis, affected method, affected records, changed source treatment, changed confidence treatment, changed uncertainty treatment, changed limitation treatment, changed public-safe treatment, changed dashboard treatment, changed map treatment, changed API treatment, changed interface treatment, changed compute control, changed cyber control, changed communications control, changed training requirement, changed assurance requirement, and effective date.

9.17.9(f) Correction and method improvement shall include dependency review across affected Nodes, Hubs, Clusters, Hotspots, Regional Observatory Clusters, National Dense Nexus Cores, dashboards, maps, APIs, Evidence Packs, Decision Packs, public-safe outputs, public authority learning materials, GRF inputs, GRA inputs, Protocol Authority inputs, Nexus Risk Management inputs, Nexus Rails inputs, National Company materials, Project SPV materials, provider-facing materials, sponsor-facing materials, host-facing materials, operator-facing materials, community-facing materials, Academy materials, repositories, media materials, and public claims.

9.17.9(g) Where degraded-mode correction affects external understanding, public-safe outputs, controlled-room materials, public authority learning materials, host materials, operator materials, provider materials, sponsor materials, community-facing materials, GRF inputs, GRA inputs, Protocol Authority inputs, Nexus Risk Management materials, Nexus Rails materials, Academy materials, repositories, dashboards, maps, APIs, or public claims, GCRI Canada shall issue public-safe notice or controlled notice as appropriate.

9.17.9(h) The controlling rule shall be that degraded-mode evidence must be corrected as systems return, records improve, and uncertainty changes; otherwise disruption becomes institutional memory error.

***

9.17.10 Degraded-Mode Records and Assurance.\
9.17.10(a) GCRI Canada shall maintain, or cause to be maintained, degraded-mode records for material degraded-mode methods, signals, continuity indicators, fallback operations, evidence-flow interruptions, compute interruptions, sensor failures, connectivity failures, power failures, data losses, cyber incidents, infrastructure-stress signals, dashboards, maps, APIs, Evidence Packs, Decision Packs, public-safe outputs, disputes, incidents, corrections, dependencies, assurance reviews, and closeout events.

9.17.10(b) Degraded-mode records shall identify record title or identifier, event title or identifier where applicable, affected architecture element, affected system class, affected source class, affected Node, affected Hub, affected Cluster, affected Hotspot, affected Regional Observatory Cluster, affected National Dense Nexus Core, provider where any, operator where any, host where any, public authority context where any, community context where any, technology domain, risk domain, data class, evidence class, output class, access class, handling class, public-safe status, privacy status, cybersecurity status, sovereign data status, infrastructure-sensitive status, public authority status, finance-sensitive status, provider-sensitive status, sponsor-sensitive status, operator-sensitive status, host-sensitive status, community-protected status, Indigenous or protected knowledge status, legal sensitivity, export-control sensitivity, sanctions sensitivity, controlled-technology sensitivity, permitted uses, prohibited uses, publication limits, and correction path.

9.17.10(c) Continuity records shall identify continuing sources, unavailable sources, fallback sources, restored sources, degraded sources, missing records, delayed records, stale records, held records, restricted records, restored compute, failed compute, restored sensors, failed sensors, restored connectivity, failed connectivity, restored dashboards, degraded dashboards, restored maps, degraded maps, restored APIs, degraded APIs, confidence effect, uncertainty effect, limitation effect, public-safe effect, and dependency effect.

9.17.10(d) Incident records shall identify degraded-mode incident type, suspected or confirmed status, severity classification where used, detection source, affected system class where safe, affected data class, affected environment, affected operator context where any, affected host context where any, affected provider context where any, affected public authority context where any, timeline where safe, containment status where known, restoration status where known, public-safe status, confidence, uncertainty, limitations, notification decisions, correction actions, residual risk, closeout status, and archive treatment.

9.17.10(e) Assurance records shall identify review cycle, reviewers, scope reviewed, degraded-mode methods reviewed, sources reviewed, continuity indicators reviewed, fallback methods reviewed, compute controls reviewed, sensor controls reviewed, communications controls reviewed, dashboard controls reviewed, map controls reviewed, API controls reviewed, cyber controls reviewed, public authority boundaries reviewed, public warning controls reviewed, operator boundaries reviewed, host boundaries reviewed, provider neutrality reviewed, sponsor non-control reviewed, privacy controls reviewed, cybersecurity controls reviewed, sovereign data controls reviewed, protected knowledge safeguards reviewed, public-safe communication reviewed, findings, corrective action plans, training updates, technical control updates, Board or committee reporting where material, residual risk, and closeout status.

9.17.10(f) Correction records shall identify corrected source, corrected degraded-mode status, corrected continuity indicator, corrected fallback status, corrected connectivity status, corrected compute status, corrected sensor status, corrected power status, corrected data-loss status, corrected cyber incident status, corrected infrastructure-stress status, corrected dataset, corrected method, corrected compute workload, corrected model, corrected dashboard, corrected map, corrected API, corrected public-safe output, corrected public authority reference, corrected provider reference, corrected sponsor reference, corrected host reference, corrected operator reference, corrected community reference, corrected boundary language, prior status, corrected status, effective date, reviewer, affected dependencies, notice decision, access change, archive treatment, and continuing limitations.

9.17.10(g) Degraded-mode records shall be linked, where applicable, to National Dense Core records, Regional Observatory Cluster records, Cluster records, Hub records, Node records, Hotspot records, AI-RAN records, DePIN records, sensor records, geospatial records, cyber telemetry records, digital twin records, dashboard records, Observatory Methods Register entries, Evidence Register entries, Source Comparison Records, Dataset Register entries, Model Register entries, System Card entries, Benchmark Card entries, Compute Workload Records, Compute Environment Records, Inference Records, Human Review Records, Retrieval and Embedding Records, Proof Receipt Records, Public-Safe Output Records, AI Incident Records, Correction Records, Dependency Records, Truth Engine Records, Nexus Risk Management records, public authority records, GRF interface records, GRA interface records, Protocol Authority interface records, RNFD records, Nexus Rails records, Regional Nexus Consortium records, National Nexus Consortium records, National Company records, Project SPV records, operator records, provider records, sponsor records, host records, community records, university records, Nexus interface records, and public claims records.

9.17.10(h) Degraded-mode records, continuity records, incident records, after-action records, public-safe records, assurance records, correction records, supersession records, withdrawal records, retraction records, retirement records, archive records, notices, and closeout shall not create certification, recognition, finance-readiness, public authority decision, regulatory finding, procurement approval, provider endorsement, sponsor approval, host approval, operator approval, rating, guarantee, public warning, emergency command, security certification, protocol effect, operational clearance, legal status, market authority, infrastructure operation, remediation approval, deployment approval, national authority, regional authority, or execution consequence by default.

9.17.10(i) The controlling rule shall be that degraded-mode awareness is trustworthy only when disruption, uncertainty, continuity, fallback, restoration, correction, and assurance remain recorded with enough precision to prevent temporary impairment from becoming permanent overclaim.

### 9.18 Host Readiness and Site Readiness Methods

9.18.1 Host Readiness as Evidence and Methods Domain.\
9.18.1(a) GCRI Canada may steward host readiness and site readiness methods as a Observatory evidence and methods domain for identifying, receiving, classifying, comparing, interpreting, public-safe summarizing, correcting, renewing, and closing out evidence concerning whether a host, site, facility, campus, corridor, community location, infrastructure location, data environment, compute environment, connectivity environment, sensor environment, public authority learning environment, or other participation context is ready for a recorded Observatory purpose.

9.18.1(b) Host readiness methods may support Observatory Nodes, Hubs, Clusters, Hotspots, Regional Observatory Clusters, National Dense Nexus Cores, sovereign compute environments, public authority learning rooms, controlled rooms, data rooms, clean rooms, no-download rooms, sensor deployments, AI-RAN evidence, DePIN evidence, geospatial evidence, cyber-physical evidence, digital twin evidence, dashboards, maps, Evidence Packs, Decision Packs, GRF inputs, GRA inputs, Protocol Authority inputs, Nexus Risk Management inputs, Nexus Rails inputs, Nexus Academy materials, public-good software support, technical baseline support, public-safe outputs, and correction workflows.

9.18.1(c) Host readiness shall be treated as an evidence and methods category only. It shall not be treated as host certification, site certification, facility certification, public authority approval, procurement approval, finance-readiness, insurance-readiness, capital-readiness, provider preference, sponsor approval, community approval, operator approval, protocol effect, deployment approval, operational clearance, infrastructure operation, legal status, market authority, public warning, emergency command, or execution consequence by default.

9.18.1(d) Host readiness methods shall be records-valid, source-lined, scope-defined, audience-aware, classification-aware, confidence-aware, uncertainty-aware, limitation-aware, public-safe, privacy-protective, cybersecurity-controlled, sovereignty-compatible, infrastructure-sensitive, community-sensitive, protected-knowledge-sensitive, provider-neutral, sponsor-independent, public-authority-bounded, host-bounded, and correctionable.

9.18.1(e) GCRI Canada’s stewardship of host readiness methods shall not make GCRI Canada a host, operator, landlord, facility manager, infrastructure operator, public authority, emergency-management actor, procurement actor, finance actor, insurer, lender, rating agency, certification body, recognition body, Protocol Authority, provider, sponsor, National Company, Project SPV, construction manager, deployment manager, or execution actor by default.

9.18.1(f) Host readiness methods shall preserve the distinction between evidence readiness, site readiness evidence, facility context, data readiness, connectivity readiness, compute readiness, security readiness, public authority learning readiness, community readiness, public-safe readiness, host-provided context, provider-provided materials, sponsor-supported context, and any separate authority-bearing or execution-bearing decision made by another competent actor.

9.18.1(g) Where host readiness evidence is used externally or publicly, GCRI Canada shall preserve controlled vocabulary, source lineage, readiness scope, confidence, uncertainty, limitations, public-safe status, no-certification language, no-procurement language, no-finance language, no-public-authority language, no-provider-endorsement language, no-sponsor-approval language, no-host-approval language, no-community-consent-by-implication language where material, no-protocol-effect language unless separately created by Protocol Authority, no-deployment-approval language, no-operational-clearance language, no-execution language, and correction path.

9.18.1(h) The controlling rule shall be that host readiness is readiness of evidence, safeguards, interfaces, and methods for a defined Observatory purpose, not readiness for procurement, finance, certification, recognition, deployment, operation, authority, or execution by GCRI Canada.

***

9.18.2 Site Readiness, Facility Readiness, Data Readiness, Connectivity Readiness, Compute Readiness, Security Readiness, Public Authority Readiness, Community Readiness, and Public-Safe Readiness.\
9.18.2(a) GCRI Canada may steward distinct readiness methods for site readiness, facility readiness, data readiness, connectivity readiness, compute readiness, security readiness, public authority readiness, community readiness, protected knowledge readiness, host-interface readiness, provider-interface readiness, sponsor-boundary readiness, and public-safe readiness, provided that each readiness category is recorded, bounded, and corrected according to its actual evidence purpose.

9.18.2(b) Site readiness methods shall identify site or safe-site context, host role, location or safe-location treatment, access constraints, infrastructure context, environmental context, community context, public authority context, data classes, evidence classes, sensor suitability, dashboard suitability, mapping sensitivity, public-safe status, confidence, uncertainty, limitations, and correction path.

9.18.2(c) Facility readiness methods shall identify facility type, facility context where safe and material, physical access, safety constraints, infrastructure dependencies, power context, communications context, cyber-physical context, equipment context, host obligations, operator context where any, public authority relevance, community relevance, provider relevance, sponsor relevance, and public-safe limitations.

9.18.2(d) Data readiness methods shall identify available data, missing data, restricted data, public authority data, host data, operator data, provider data, sponsor data, community data, Indigenous or protected knowledge where any, source permissions, data rights, lawful basis where applicable, data quality, data lineage, data classification, retention, deletion, sealing, access controls, public-safe status, and correction path.

9.18.2(e) Connectivity readiness methods shall identify communications availability, AI-RAN relevance, O-RAN relevance, private wireless relevance, broadband relevance, satellite relevance, edge connectivity, fallback connectivity, degraded-mode connectivity, network telemetry availability, cybersecurity constraints, provider role, operator role, host constraints, public-safe constraints, confidence, uncertainty, limitations, and correction path.

9.18.2(f) Compute readiness methods shall identify compute environment, edge compute, sovereign compute, secure enclave, confidential computing, compute-to-data, air-gapped or no-download treatment where needed, workload classes, data classes, access controls, logging, key management, provider role, host role, public authority restrictions, cross-border status, public-safe status, and correction path.

9.18.2(g) Security readiness methods shall identify cybersecurity posture relevant to evidence use, physical security constraints, access controls, identity controls, credential controls, key controls, incident paths, vulnerability-sensitive information, infrastructure-sensitive information, public-safe disclosure limits, host obligations, provider obligations, operator obligations where any, and correction path.

9.18.2(h) Public authority readiness methods shall identify whether the host context can support public authority learning without public authority confusion, including capacity classification, official or non-official status, data-sharing terms, agency reference controls, public-safe status, non-delegation language, non-endorsement language, no-public-warning language, no-procurement language, no-funding language, and correction path.

9.18.2(i) Community readiness methods shall identify community context, Indigenous protocols where applicable, local context, territorial context, cultural context, environmental knowledge context, accessibility, translation, localization, consent or non-consent treatment where applicable, challenge pathways, withdrawal pathways where applicable, public-safe communication limits, do-no-harm controls, and correction path.

9.18.2(j) Public-safe readiness methods shall identify whether host readiness evidence can be summarized, dashboarded, mapped, reported, API-exposed, included in Evidence Packs, included in Decision Packs, routed to GRF, routed to GRA, routed to Protocol Authority, used in Academy materials, or publicly communicated without unsafe disclosure, overclaim, public authority confusion, finance implication, procurement implication, provider preference, sponsor validation, host approval implication, community harm, or protected knowledge exposure.

9.18.2(k) The controlling rule shall be that readiness must be disaggregated by readiness type because a site may be ready for evidence learning while not ready for publication, public authority engagement, finance-facing routing, provider demonstration, deployment, operation, or execution.

***

9.18.3 Host Evidence Does Not Create Host Certification by Default.\
9.18.3(a) No host readiness evidence, site readiness record, facility readiness record, data readiness record, connectivity readiness record, compute readiness record, security readiness record, public authority readiness record, community readiness record, public-safe readiness record, host dashboard, host map, host report, host Evidence Pack, host Decision Pack, host technical note, host public-safe summary, host benchmark, host Proof Receipt, host correction signal, or host public claim shall create host certification, site certification, facility certification, readiness certification, safety certification, security certification, conformance determination, Nexus-compatible status, recognition, maturity record, claims approval, protocol effect, public authority approval, procurement approval, finance-readiness, provider preference, sponsor approval, community approval, deployment approval, operational clearance, infrastructure operation, legal status, market authority, public warning, emergency command, or execution consequence by default.

9.18.3(b) Host evidence shall not issue or imply “approved host,” “certified site,” “validated facility,” “deployment-ready host,” “procurement-ready site,” “finance-ready host,” “investment-ready site,” “insurance-ready facility,” “recognized host,” “Nexus-compatible host,” “public authority-approved site,” “safe site,” “preferred host,” “provider-approved site,” or equivalent status language unless such status is separately created by a competent actor under its own authority and proper record, and not by GCRI Canada by implication.

9.18.3(c) The presence of host participation, facility access, site access, sensor installation, compute availability, data contribution, connectivity availability, provider participation, sponsor support, public authority attendance, community participation, dashboard visibility, map visibility, benchmark success, Proof Receipt issuance, GRF interface use, GRA interface use, Protocol Authority interface use, National Company relevance, or Project SPV relevance shall not convert host evidence into host certification.

9.18.3(d) Any host certification, site approval, facility approval, operator approval, public authority approval, procurement decision, finance decision, insurance decision, Protocol Authority determination, GRF recognition, GRA finance-readiness determination, National Company decision, Project SPV decision, provider decision, sponsor decision, community decision, or other authority-bearing action shall arise only through the competent actor’s own lawful authority, process, record, accountability, and liability, not through GCRI Canada host evidence by implication.

9.18.3(e) Host readiness materials shall include boundary language where material to prevent interpretation as host certification, site certification, facility certification, public authority approval, procurement approval, finance-readiness, insurance-readiness, recognition, protocol effect, provider preference, sponsor approval, host approval, community consent, operational clearance, deployment approval, market signal, legal status, or execution instruction.

9.18.3(f) Where host readiness materials are misused to imply host certification or equivalent status, GCRI Canada shall correct, relabel, restrict, withdraw, reissue, require removal of misleading references, notify affected interfaces where appropriate, suspend affected interface use, or pursue contractual or legal remedies where appropriate.

9.18.3(g) No ambiguity shall be resolved in favour of host certification. Where there is doubt whether host evidence creates certification or only supports evidence, the interpretation preserving GCRI Canada’s non-execution role, public authority boundaries, finance boundaries, procurement neutrality, provider neutrality, sponsor non-control, host boundaries, community safeguards, Protocol Authority role separation, GRF role separation, GRA role separation, validity-by-record, correctionability, and public trust shall prevail.

9.18.3(h) The controlling rule shall be that host evidence may describe readiness conditions, but it does not certify the host.

***

9.18.4 Host Readiness Does Not Create Procurement Approval or Finance-Readiness by Default.\
9.18.4(a) Host readiness evidence shall not constitute procurement approval, vendor award, preferred-site status, supplier qualification, public tender advantage, project approval, deployment approval, finance-readiness, capital-readiness, insurance-readiness, investment advice, lending decision, underwriting decision, insurance approval, rating, guarantee, public finance approval, bankability, fundability, capital commitment, credit quality, investment quality, insurance quality, financial suitability, market signal, or execution consequence by GCRI Canada.

9.18.4(b) Host readiness evidence may be routed to GRA, Nexus Rails, RNFD, NFD, UNFSD, capital-reader literacy contexts, insurance-readiness input contexts, National Companies, Project SPVs, public authorities, providers, sponsors, hosts, operators, or other interfaces only as evidence-supporting, non-advisory, non-rating, non-guaranteeing, non-financial, non-procurement, public-safe where externally released, and correctionable material.

9.18.4(c) Finance-facing host readiness records shall identify receiving interface, purpose, evidence classes, data classes, output classes, source records, method records, compute records where applicable, model records where applicable, public-safe status, finance-safe status, access class, handling class, confidence, uncertainty, limitations, no-advice boundary, no-rating boundary, no-guarantee boundary, no-public-finance-approval boundary, no-procurement boundary, permitted use, prohibited use, correction path, supersession path, withdrawal path, retraction path where applicable, and dependency links.

9.18.4(d) Procurement-facing host readiness records shall identify receiving interface, purpose, evidence classes, data classes, source records, provider roles, host roles, sponsor roles, public authority roles, National Company roles, Project SPV roles, public-safe status, procurement-safe status, provider-neutrality status, conflict status, prohibited claims, permitted use, prohibited use, correction path, and dependency links.

9.18.4(e) GCRI Canada shall not use host readiness methods to recommend a host for procurement, recommend a provider, solicit investment, arrange financing, rate a site, guarantee a host, approve insurance, approve lending, approve underwriting, approve public finance, determine bankability, create capital allocation priority, direct a National Company, direct a Project SPV, approve project execution, or create deployment instruction.

9.18.4(f) Host readiness indicators, scores, colours, dashboard labels, map markers, rankings, comparisons, resilience indicators, risk indicators, capacity indicators, benchmark results, Proof Receipts, public-safe summaries, AI-generated summaries, Evidence Packs, or Decision Packs shall not be used or framed by GCRI Canada as procurement approvals, provider rankings, finance-readiness determinations, ratings, guarantees, insurance-readiness determinations, investment recommendations, project approvals, host awards, deployment approvals, or execution instructions.

9.18.4(g) Where procurement-facing or finance-facing misuse or overclaim is detected, GCRI Canada shall correct, relabel, restrict, withdraw, reissue, require removal of misleading references, notify affected GRA, Rails, RNFD, NFD, UNFSD, procurement, National Company, Project SPV, public authority, host, provider, or sponsor interfaces where appropriate, suspend affected interface use, or pursue contractual or legal remedies where appropriate.

9.18.4(h) The controlling rule shall be that host readiness may help competent actors understand evidence about a host or site, but it shall not approve procurement, create finance-readiness, allocate capital, select providers, approve deployment, or execute projects by GCRI Canada.

***

9.18.5 Host Contributions of Facilities, Data, Sensors, Compute, Connectivity, Staff Time, or Context.\
9.18.5(a) GCRI Canada may receive, classify, use, review, public-safe summarize, and correct host contributions of facilities, site access, data, sensors, reference sensors, compute, edge compute, sovereign compute, connectivity, AI-RAN connectivity, O-RAN connectivity, private wireless connectivity, DePIN devices, cyber telemetry, geospatial context, digital twin context, field observations, staff time, expert context, community context, public authority context, operator context, operational context in public-safe or controlled form, and other host-related evidence where such contribution is authorized, classified, safeguarded, public-safe where externally used, and correctionable.

9.18.5(b) Host contribution records shall identify host identity, host role, contribution type, contribution purpose, contribution scope, facility or site context where safe and material, infrastructure context, data classes, evidence classes, output classes, access class, handling class, privacy status, cybersecurity status, sovereign data status, infrastructure-sensitive status, public authority status, finance-sensitive status, community-protected status, Indigenous or protected knowledge status, provider relevance, sponsor relevance, operator relevance, permitted use, prohibited use, publication limits, and correction path.

9.18.5(c) Facility and site-access contributions shall identify access permissions, access limits, safety constraints, security constraints, public authority constraints, operator constraints where any, community constraints, insurance or legal constraints where relevant to access, site sensitivity, safe-location treatment, photography or recording limits, sensor placement limits, compute placement limits, and closeout obligations.

9.18.5(d) Data contributions shall identify source, owner where known, custodian, steward, license, permissions, lawful basis where applicable, consent or non-consent treatment where applicable, data quality, data lineage, classification, retention, deletion, sealing, access controls, AI-use restrictions, retrieval restrictions, embedding restrictions, public-safe status, and correction path.

9.18.5(e) Sensor, compute, and connectivity contributions shall identify equipment or environment identity, owner where known, custodian, provider where any, operator where any, configuration, calibration where applicable, maintenance status, access controls, cybersecurity controls, logging, data residency, cross-border status, public-safe status, incident path, and correction path.

9.18.5(f) Staff time, expert context, field context, and operational context shall be treated as evidence sources subject to source records, capacity classification, confidentiality, conflict disclosure where material, public-safe review, limitation statements, and correction path.

9.18.5(g) Host contributions shall not create host endorsement, host certification, host approval, community consent, public authority approval, provider endorsement, sponsor validation, procurement preference, finance-readiness, protocol effect, operational clearance, deployment approval, infrastructure operation, legal status, market authority, or execution consequence by default.

9.18.5(h) Where host contributions are withdrawn, restricted, corrected, superseded, reclassified, disputed, or found to be unauthorized, GCRI Canada shall update affected records, dashboards, maps, Evidence Packs, Decision Packs, public-safe outputs, interface records, dependency records, and correction notices where appropriate.

9.18.5(i) The controlling rule shall be that host contributions may enrich evidence only where contribution, authority, limits, safeguards, and correction paths are recorded.

***

9.18.6 Host Data Rights, Privacy, Public Authority, Infrastructure-Sensitive, Community, and Protected Knowledge Controls.\
9.18.6(a) GCRI Canada shall apply host data rights, privacy, public authority, infrastructure-sensitive, community, Indigenous, protected knowledge, cybersecurity, sovereign data, provider, sponsor, operator, public-safe, legal, export-control, sanctions, and controlled-technology controls to host readiness evidence and host-contributed materials.

9.18.6(b) Host data rights controls shall identify ownership where known, custody, stewardship, license, permissions, lawful basis where applicable, consent or non-consent treatment where applicable, confidentiality, permitted uses, prohibited uses, data-sharing limits, derivative-use limits, publication limits, retention limits, deletion obligations, sealing obligations, archive obligations, return obligations, and correction obligations.

9.18.6(c) Privacy controls shall identify whether host readiness evidence includes or may infer personal information, rights-bearing data, device identifiers, staff information, visitor information, resident information, household patterns, movement patterns, workplace patterns, service-use patterns, health-adjacent patterns, vulnerable-person exposure, small-group identifiability, community identifiability, or other privacy-sensitive inferences.

9.18.6(d) Public authority controls shall identify whether host evidence arises from, relates to, is requested by, is received from, is reviewed by, is funded by, or may be used by a public authority, and shall preserve capacity classification, official or non-official status, data-sharing terms, agency reference controls, non-delegation language, non-endorsement language, non-regulatory language, non-procurement language, non-funding language, no-public-finance language, no-public-warning language, no-emergency-command language, and correction path.

9.18.6(e) Infrastructure-sensitive controls shall identify whether host readiness evidence reveals facility locations, site layouts, infrastructure dependencies, network topology, outage sensitivity, degraded-mode sensitivity, security controls, vulnerability-sensitive information, logistics dependencies, operator-sensitive information, cyber-sensitive information, physical security risk, or public-safe disclosure limits.

9.18.6(f) Community and Indigenous safeguard controls shall identify community protocols, Indigenous protocols where applicable, territorial context, cultural context, environmental knowledge context, sensitive-site treatment, public-safe mapping limits, source protection, withdrawal or challenge pathways where applicable, accessibility, translation, localization, non-extraction, non-commodification, and do-no-harm controls.

9.18.6(g) Protected knowledge controls shall prohibit extraction, mapping, summarization, translation, modeling, embedding, retrieval, training, dashboarding, publication, commodification, decontextualization, or public-safe reuse of protected knowledge without recorded authority, safeguards, and public-safe review appropriate to the knowledge context.

9.18.6(h) Host readiness evidence shall not be published, dashboarded, mapped, API-exposed, shared with providers, shared with sponsors, routed to finance-facing contexts, routed to public authority contexts, embedded, retrieved, trained on, vendor-processed, public-AI-processed, or summarized externally without review proportionate to host data rights, privacy, public authority, infrastructure, community, protected knowledge, cybersecurity, sovereign data, provider, sponsor, operator, and public-safe risks.

9.18.6(i) Where host data rights, privacy, public authority, infrastructure-sensitive, community, protected knowledge, or public-safe controls fail, GCRI Canada shall restrict access, correct classification, halt routing, remove unsafe fields, apply safe-location treatment, delete or seal records where appropriate, withdraw or revise outputs, notify affected interfaces where required, and review dependencies.

9.18.6(j) The controlling rule shall be that host readiness evidence often reveals people, facilities, systems, authorities, communities, and protected knowledge; therefore it must be governed before it is useful.

***

9.18.7 Host Provider, Sponsor, Public Authority, and Community Interface Methods.\
9.18.7(a) GCRI Canada shall steward host interface methods with providers, sponsors, public authorities, communities, Indigenous or protected knowledge holders, operators, universities, National Nexus Consortiums, National Companies, Project SPVs, GRF, GRA, Protocol Authority, Nexus Risk Management, Nexus Rails, Nexus Academy, and other authorized actors where host readiness evidence is received, reviewed, routed, summarized, corrected, or used for learning.

9.18.7(b) Provider interface methods shall identify provider identity, provider role, provider materials, provider systems, provider data, provider tools, provider equipment, provider AI, provider compute, provider sensors, provider dashboards, provider configuration, benchmark conditions where any, validation conditions where any, commercial sensitivity, IP sensitivity, cybersecurity sensitivity, conflict status, influence controls, permitted claims, prohibited claims, publication limits, and correction path.

9.18.7(c) Sponsor interface methods shall identify sponsor identity, sponsor role, funding or support relationship, convening support, facilities support, technology access, data access, dashboard support, publication support, public authority access limits, provider access limits, conflict status, sponsor non-control language, no-outcome-purchase language, no-evidence-control language, no-publication-control language, no-recognition-control language, no-finance-control language, no-protocol-control language, no-host-control language, and correction path.

9.18.7(d) Public authority interface methods shall identify participating or referenced public authorities, office or function where appropriate, participant capacity, official or non-official status, data-sharing authority, public authority restrictions, agency reference controls, publication limits, retention treatment, permitted use, prohibited use, public-safe status, and correction path.

9.18.7(e) Community and Indigenous interface methods shall identify affected or relevant communities, Indigenous protocols where applicable, community protocols, consent or non-consent treatment where applicable, territorial context, cultural context, environmental knowledge context, sensitive-site treatment, public-safe mapping limits, source protection, community challenge pathways, withdrawal pathways where applicable, accessibility, translation, localization, non-extraction, non-commodification, and do-no-harm controls.

9.18.7(f) Operator interface methods shall identify operator identity where safe and material, operator role, system context, infrastructure context, operational context in public-safe or controlled form, data contribution status, telemetry contribution status, dashboard access status, map access status, cybersecurity sensitivity, infrastructure sensitivity, commercial sensitivity, publication limits, no-operation boundary, no-operator-instruction boundary, no-service-assurance boundary, no-remediation-approval boundary, no-certification boundary, no-finance boundary, no-procurement boundary, and correction path.

9.18.7(g) Host interface methods shall preserve legal separateness and role separation among GCRI Canada, hosts, providers, sponsors, public authorities, communities, Indigenous governance bodies where applicable, operators, National Companies, Project SPVs, GRF, GRA, Protocol Authority, Nexus bodies, universities, and other actors.

9.18.7(h) Interface participation, review, attendance, comments, data contribution, dashboard access, map access, site access, facility access, sponsor support, provider support, public authority interest, community participation, operator participation, National Company relevance, Project SPV relevance, GRF interface use, GRA interface use, or Protocol Authority interface use shall not imply endorsement, approval, consent, certification, recognition, procurement approval, finance-readiness, public authority decision, protocol effect, provider preference, sponsor validation, host approval, operator instruction, deployment approval, operational clearance, market signal, or execution consequence.

9.18.7(i) Where interface misuse occurs, GCRI Canada shall require correction, relabeling, removal of misleading references, public-safe clarification, controlled notice, access restriction, interface suspension, contract remedy, or legal action where appropriate.

9.18.7(j) The controlling rule shall be that host readiness interfaces may bring actors into structured evidence learning, but no actor’s presence may convert host evidence into approval, certification, finance, procurement, authority, endorsement, consent, deployment, or execution.

***

9.18.8 Host Readiness Evidence Packs and Public-Safe Summaries.\
9.18.8(a) GCRI Canada may prepare host readiness Evidence Packs, Decision Packs, technical notes, dashboards, maps, public-safe summaries, controlled annexes, Academy materials, public authority learning materials, GRF-facing inputs, GRA-facing inputs, Protocol Authority-facing inputs, provider-facing materials, sponsor-facing materials, host-facing materials, operator-facing materials, community-facing materials, and correction notices where such outputs are source-lined, classified, reviewed, boundary-valid, public-safe where externally released, and correctionable.

9.18.8(b) Host readiness Evidence Packs shall identify host purpose, readiness scope, site context or safe-site treatment, facility context, data readiness, connectivity readiness, compute readiness, security readiness, public authority readiness, community readiness, public-safe readiness, source records, data records, sensor records, compute records, dashboard records, map records, interface records, confidence, uncertainty, limitations, public-safe status, permitted use, prohibited use, and correction path.

9.18.8(c) Host readiness Decision Packs shall be decision-supporting only and shall identify decision-support purpose, intended audience, authority boundaries, evidence basis, assumptions, readiness limits, confidence, uncertainty, limitations, dependency records, public-safe status, no-certification language, no-procurement language, no-finance language, no-public-authority language, no-provider-endorsement language, no-sponsor-approval language, no-host-approval language, no-deployment-approval language, no-operational-clearance language, and correction path.

9.18.8(d) Public-safe summaries shall identify, where material, source classes, readiness categories, confidence, uncertainty, limitations, public-safe omissions, responsible non-disclosure basis, stale-data treatment, correction status, supersession status, withdrawal status where applicable, permitted use, prohibited use, and boundary language, while avoiding unsafe disclosure of restricted host materials.

9.18.8(e) Host readiness dashboards and maps shall be reviewed for precise-site exposure, infrastructure sensitivity, security exposure, community sensitivity, public authority implication, procurement implication, finance implication, provider preference, sponsor validation, host approval implication, deployment approval implication, false precision, overconfident colours, misleading legends, drill-down risk, export risk, screenshot risk, API exposure, stale-data risk, and third-party reuse risk.

9.18.8(f) Host readiness outputs shall not disclose or enable misuse of personal information, rights-bearing data, health-sensitive data, cyber-sensitive information, infrastructure-sensitive information, public authority restricted information, sovereign-sensitive information, finance-sensitive information, commercially sensitive information, community-protected information, Indigenous or protected knowledge, confidential source information, privileged material, credentials, secrets, keys, tokens, controlled technology, exploit details, sensitive locations, unsafe geospatial precision, unsafe metadata, host-sensitive information, or operator-sensitive information.

9.18.8(g) Where host readiness outputs cannot be made public-safe without distorting evidence, erasing uncertainty, concealing contradiction, exposing restricted data, exposing protected knowledge, creating public authority implication, creating finance overclaim, creating procurement implication, creating provider preference, creating sponsor validation, creating host approval implication, creating community harm, or creating execution implication, GCRI Canada may use controlled annexes, controlled-room review, aggregation, generalization, safe-location treatment, delayed release, responsible non-disclosure, limited public-safe statement, or no-publication treatment.

9.18.8(h) The controlling rule shall be that host readiness outputs must help audiences understand host evidence without turning the host into an approved, certified, financed, procured, endorsed, deployed, or executing site.

***

9.18.9 Correction Where Host Readiness Is Overclaimed.\
9.18.9(a) GCRI Canada shall require correction where host readiness evidence, host readiness materials, host readiness dashboards, host readiness maps, host readiness Evidence Packs, host readiness Decision Packs, public-safe summaries, interface materials, media materials, provider materials, sponsor materials, public authority materials, National Company materials, Project SPV materials, or public claims overstate, misuse, misclassify, or misrepresent host readiness.

9.18.9(b) Host readiness overclaim includes any statement, label, visual display, score, colour, ranking, map marker, badge, proof receipt reference, dashboard status, public-safe summary, public authority reference, provider reference, sponsor reference, host reference, community reference, National Company reference, Project SPV reference, GRF reference, GRA reference, or Protocol Authority reference that implies host certification, site certification, public authority approval, procurement approval, finance-readiness, insurance-readiness, investment quality, rating, guarantee, recognition, protocol effect, provider preference, sponsor approval, host approval, community consent, deployment approval, operational clearance, market authority, infrastructure operation, public warning, emergency command, or execution consequence by default.

9.18.9(c) Correction may require relabeling, boundary-language revision, confidence downgrade, uncertainty revision, limitation update, source re-check, data reclassification, public-safe reclassification, dashboard correction, map correction, Evidence Pack correction, Decision Pack correction, public-safe summary correction, interface notice, public-safe notice, controlled notice, withdrawal, retraction, supersession, archive treatment, access restriction, or removal of misleading references.

9.18.9(d) Where overclaim arises from provider materials, sponsor materials, host materials, public authority materials, National Company materials, Project SPV materials, media materials, public claims, or third-party reuse, GCRI Canada may require correction, request removal, request relabeling, issue clarification, suspend interface use, restrict access, or pursue contractual or legal remedies where appropriate.

9.18.9(e) Where host readiness overclaim affects GRF, GRA, Protocol Authority, Nexus Risk Management, Nexus Rails, National Nexus Consortium, Regional Nexus Consortium, National Company, Project SPV, provider, sponsor, host, operator, public authority, community, Academy, media, or public-facing dependencies, GCRI Canada shall review affected dependencies and issue public-safe or controlled correction signals as appropriate.

9.18.9(f) Correction shall not itself create certification, recognition, finance-readiness, public authority decision, procurement approval, provider endorsement, sponsor finding, host finding, operator finding, rating, guarantee, public warning, emergency command, protocol effect, operational clearance, legal status, market authority, deployment approval, or execution consequence by default.

9.18.9(g) Where ambiguity exists, GCRI Canada shall correct toward the safer, narrower, more source-lined, more public-safe, more provider-neutral, more sponsor-independent, more host-bounded, more public-authority-bounded, more finance-safe, more procurement-safe, and more correctionable interpretation.

9.18.9(h) The controlling rule shall be that host readiness overclaim must be corrected quickly because a readiness label can become a procurement, finance, certification, authority, or deployment signal unless actively bounded.

***

9.18.10 Host Readiness Records, Review, Renewal, and Closeout.\
9.18.10(a) GCRI Canada shall maintain, or cause to be maintained, host readiness records for material host readiness methods, site readiness records, facility readiness records, data readiness records, connectivity readiness records, compute readiness records, security readiness records, public authority readiness records, community readiness records, public-safe readiness records, host contributions, dashboards, maps, APIs, Evidence Packs, Decision Packs, public-safe summaries, controlled annexes, disputes, incidents, misuse events, corrections, dependencies, renewal, assurance, withdrawal, retirement, archive, and closeout events.

9.18.10(b) Host readiness records shall identify host title or identifier, site or safe-site context, facility context where safe and material, host role, owner where known, custodian, steward, operator where any, provider where any, sponsor where any, public authority context where any, community context where any, Indigenous or protected knowledge context where any, National Company context where any, Project SPV context where any, technology domain, risk domain, data class, evidence class, output class, audience class, access class, handling class, public-safe status, privacy status, cybersecurity status, sovereign data status, infrastructure-sensitive status, public authority status, finance-sensitive status, provider-sensitive status, sponsor-sensitive status, host-sensitive status, operator-sensitive status, community-protected status, Indigenous or protected knowledge status, legal sensitivity, license status, export-control sensitivity, sanctions sensitivity, controlled-technology sensitivity, permitted uses, prohibited uses, publication limits, and correction path.

9.18.10(c) Review records shall identify review cycle, reviewers, host-purpose review, site review, facility review, data review, connectivity review, compute review, security review, public authority boundary review, public warning review, finance-boundary review, procurement-boundary review, certification-boundary review, provider-neutrality review, sponsor non-control review, host-boundary review, operator-boundary review, community safeguard review, protected knowledge review, privacy review, cybersecurity review, sovereign data review, public-safe review, export-control review where applicable, sanctions review where applicable, controlled-technology review where applicable, and correction review.

9.18.10(d) Renewal records shall identify whether host readiness evidence remains current, useful, records-valid, source-lined, public-safe, sovereignty-compatible, privacy-protective, cybersecurity-controlled, infrastructure-sensitive-safe, community-safe, protected-knowledge-safe, provider-neutral, sponsor-independent, host-bounded, public-authority-bounded, finance-safe, procurement-safe, certification-safe, boundary-valid, and correctionable. Renewal shall identify changed host context, changed site context, changed facility context, changed data context, changed connectivity context, changed compute context, changed security context, changed public authority context, changed community context, changed provider context, changed sponsor context, changed operator context, changed legal context, changed finance context, changed procurement context, changed Nexus interface context, and required method updates.

9.18.10(e) Correction records shall identify corrected source, corrected host record, corrected site record, corrected facility record, corrected data readiness record, corrected connectivity readiness record, corrected compute readiness record, corrected security readiness record, corrected public authority readiness record, corrected community readiness record, corrected public-safe readiness record, corrected dashboard, corrected map, corrected API, corrected Evidence Pack, corrected Decision Pack, corrected public-safe output, corrected provider reference, corrected sponsor reference, corrected host reference, corrected operator reference, corrected public authority reference, corrected community reference, corrected boundary language, prior status, corrected status, effective date, reviewer, affected dependencies, notice decision, access change, archive treatment, and continuing limitations.

9.18.10(f) Supersession records shall identify replacement host readiness record, changed readiness scope, changed evidence base, changed host context, changed site context, changed facility context, changed data status, changed connectivity status, changed compute status, changed security status, changed public authority context, changed community context, changed provider context, changed sponsor context, changed operator context, changed methods, changed confidence, changed uncertainty, changed limitations, changed public-safe status, changed boundary language, continuing validity where any, discontinued reliance where any, and downstream dependency treatment.

9.18.10(g) Withdrawal or retraction records shall be used where host readiness evidence or outputs should no longer be used or relied upon because of material error, unsafe disclosure, public-safe defect, host overclaim, certification implication, public authority confusion, finance overclaim, procurement implication, provider-preferential framing, sponsor-validation framing, host approval implication, operator-control implication, community consent implication, protected knowledge exposure, community harm risk, privacy defect, cybersecurity defect, sovereign data issue, cross-border defect, infrastructure-risk exposure, legal defect, export-control issue, sanctions issue, controlled-technology issue, or correction failure.

9.18.10(h) Closeout records shall identify completion, suspension, termination, retirement, archive, data return, data deletion, data sealing, access revocation, credential revocation, key revocation where applicable, room closure, dashboard removal where applicable, map removal where applicable, API deprecation where applicable, sensor decommissioning where applicable, compute decommissioning where applicable, outstanding corrections, outstanding notices, retained records, archive status, public-safe obligations, confidentiality obligations, protected knowledge obligations, public authority obligations, provider obligations, sponsor obligations, host obligations, operator obligations, community obligations, National Company obligations, Project SPV obligations, GRA obligations, GRF obligations, Protocol Authority obligations, RNFD or Nexus Rails obligations where any, and continuing prohibited uses.

9.18.10(i) Host readiness records shall be linked, where applicable, to National Dense Core records, Regional Observatory Cluster records, Cluster records, Hub records, Node records, Hotspot records, AI-RAN records, DePIN records, sensor records, geospatial records, cyber telemetry records, digital twin records, dashboard records, degraded-mode records, Observatory Methods Register entries, Evidence Register entries, Source Comparison Records, Dataset Register entries, Model Register entries, System Card entries, Benchmark Card entries, Compute Workload Records, Compute Environment Records, Inference Records, Human Review Records, Retrieval and Embedding Records, Proof Receipt Records, Public-Safe Output Records, AI Incident Records, Correction Records, Dependency Records, Truth Engine Records, Nexus Risk Management records, public authority records, GRF interface records, GRA interface records, Protocol Authority interface records, RNFD records, Nexus Rails records, Regional Nexus Consortium records, National Nexus Consortium records, National Company records, Project SPV records, operator records, provider records, sponsor records, host records, community records, university records, Nexus interface records, and public claims records.

9.18.10(j) Host readiness records, review records, renewal records, correction records, supersession records, withdrawal records, retraction records, retirement records, archive records, notices, assurance, and closeout shall not create certification, recognition, finance-readiness, public authority decision, regulatory finding, procurement approval, provider endorsement, sponsor approval, host approval, operator approval, community consent, rating, guarantee, public warning, emergency command, protocol effect, operational clearance, legal status, market authority, infrastructure operation, remediation approval, deployment approval, national authority, regional authority, or execution consequence by default.

9.18.10(k) The controlling rule shall be that host readiness is trustworthy only when host purpose, site context, facilities, data, connectivity, compute, security, public authority boundaries, community safeguards, public-safe status, renewal, correction, and closeout remain recorded with enough precision to prevent host evidence from becoming unsupported certification, finance, procurement, authority, deployment, or execution.

### 9.19 Node and System Maturity Evidence Inputs

9.19.1 Maturity Evidence as Technical Input, Not Public-Facing Maturity Record by GCRI Canada.\
9.19.1(a) GCRI Canada may steward maturity evidence input methods as technical, evidentiary, source-lined, confidence-aware, uncertainty-aware, limitation-aware, public-safe, and correctionable methods for describing the state of Nodes, Hubs, Clusters, Hotspots, Regional Observatory Clusters, National Dense Nexus Cores, host contexts, system contexts, data contexts, AI contexts, cybersecurity contexts, sovereign compute contexts, public-safe contexts, community safeguard contexts, and other Observatory-relevant domains.

9.19.1(b) Maturity evidence inputs may support internal evidence review, controlled-room review, GRF input support, GRA input support, Protocol Authority input support, public authority learning, Nexus Risk Management learning, Nexus Rails learning, Nexus Grid learning, Nexus Academy learning, National Nexus Consortium learning, National Company evidence discipline, Project SPV evidence discipline, provider-neutral technical review, host learning, community learning, public-safe summaries, Evidence Packs, Decision Packs, dashboards, maps, APIs, and correction workflows.

9.19.1(c) Maturity evidence inputs prepared, stewarded, received, reviewed, summarized, dashboarded, mapped, routed, or corrected by GCRI Canada shall be treated as technical inputs only and shall not constitute public-facing maturity records, recognition, standing, claims approval, registry status, public-facing legitimacy, certification, conformance, Nexus-compatible status, finance-readiness, capital-readiness, insurance-readiness, procurement approval, public authority decision, public warning, emergency command, provider preference, sponsor approval, host approval, operational clearance, deployment approval, market authority, legal status, or execution consequence by default.

9.19.1(d) GCRI Canada’s maturity evidence methods shall preserve role separation between GCRI Canada as upstream technical evidence, methods, observability, ontology, public-good software, public-safe publication, and correction steward; The Global Risks Forum (GRF) as the public-good registry, recognition, maturity-records, claims-discipline, standing, stakeholder-formation, public-safe reporting, and public-facing legitimacy steward; The Global Risks Alliance (GRA) as the finance-readiness and capital-reader interface steward; Nexus Standards / Protocol Authority as the protocol-effect steward; and downstream actors as separate authorities, operators, companies, providers, sponsors, hosts, or execution bodies.

9.19.1(e) Maturity evidence shall not be accelerated, rounded up, translated into status language, displayed as approval, marketed as recognition, reused as finance-readiness, treated as procurement evidence beyond its recorded limits, or represented as public authority meaning by reason only of evidence density, dashboard visibility, map visibility, public authority interest, GRF interface use, GRA interface use, Protocol Authority interface use, provider participation, sponsor support, host participation, National Company relevance, Project SPV relevance, benchmark success, Proof Receipt issuance, or Academy use.

9.19.1(f) Where maturity evidence is used externally or publicly, GCRI Canada shall preserve controlled vocabulary, evidence class, maturity-input status, source lineage, confidence, uncertainty, limitations, public-safe status, no-GRF-maturity-by-GCRI language, no-recognition language, no-finance-readiness language, no-procurement language, no-public-authority language, no-certification language, no-protocol-effect language unless separately created by Protocol Authority, no-provider-endorsement language, no-sponsor-approval language, no-host-approval language, no-deployment-approval language, no-execution language, and correction path.

9.19.1(g) No maturity evidence input shall be used by GCRI Canada to create a public maturity badge, public maturity level, recognized standing, public registry entry, capital-reader status, routeability status, certification status, procurement status, provider ranking, host approval, operational readiness status, or execution authorization.

9.19.1(h) The controlling rule shall be that maturity evidence may describe technical state and development stage for bounded evidence purposes, but it does not become public-facing maturity, recognition, finance-readiness, procurement approval, certification, protocol effect, public authority meaning, or execution by GCRI Canada.

***

9.19.2 Node Maturity Evidence Inputs.\
9.19.2(a) GCRI Canada may steward Node maturity evidence input methods for describing the evidence state, methods state, data state, sensor state, compute state, connectivity state, cybersecurity state, public-safe state, host-interface state, public authority learning state, community safeguard state, provider-interface state, sponsor-boundary state, correction state, and closeout state of Observatory Nodes.

9.19.2(b) Node maturity evidence inputs shall identify the Node purpose, Node scope, host context, local evidence context, source records, sensor records, reference sensor records where any, AI-RAN records where any, O-RAN records where any, private wireless records where any, DePIN records where any, geospatial records where any, cyber telemetry records where any, digital twin records where any, compute workload records, compute environment records, dashboard records, map records, API records, public-safe output records, interface records, incident records, correction records, confidence, uncertainty, limitations, and dependency links.

9.19.2(c) Node evidence-state inputs may describe source-lineage completeness, source diversity, source independence, calibration sufficiency, data quality, data completeness, timeliness, missing data, contradiction treatment, public-safe classification, evidence pack readiness for a defined purpose, and correction path adequacy.

9.19.2(d) Node technical-state inputs may describe sensor availability, reference sensor availability, edge compute availability, sovereign compute relationship, connectivity availability, AI-RAN or private wireless relationship, DePIN relationship, dashboard availability, API availability, degraded-mode continuity, cybersecurity controls, access controls, logging, monitoring, key management, and incident handling.

9.19.2(e) Node safeguard-state inputs may describe privacy controls, public authority boundary controls, community safeguards, Indigenous or protected knowledge safeguards, safe-location treatment, infrastructure-sensitive controls, provider-neutrality controls, sponsor non-control controls, host-boundary controls, public-safe publication controls, and correction controls.

9.19.2(f) Node maturity evidence inputs shall not describe a Node as certified, recognized, approved, validated, deployment-ready, procurement-ready, finance-ready, insurance-ready, investment-ready, Nexus-compatible, protocol-effective, official, safe, preferred, operationally cleared, or public authority-approved unless such status is separately created by a competent actor under its own authority and proper record, and not by GCRI Canada by implication.

9.19.2(g) Where Node maturity evidence is incomplete, stale, contradicted, unsupported, overclaimed, public-safe defective, provider-influenced, sponsor-influenced, host-influenced, public authority-confusing, finance-facing, procurement-facing, or correction-defective, GCRI Canada shall qualify, downgrade, restrict, correct, supersede, withdraw, or refuse the Node maturity evidence input as appropriate.

9.19.2(h) The controlling rule shall be that Node maturity evidence describes the recorded state of local evidence and safeguards, not the public maturity, certification, finance-readiness, procurement status, or deployment readiness of the Node.

***

9.19.3 Cluster Maturity Evidence Inputs.\
9.19.3(a) GCRI Canada may steward Cluster maturity evidence input methods for describing the evidence state, topology state, interoperability state, aggregation state, comparison state, confidence state, uncertainty state, contradiction state, mismatch state, public-safe state, degraded-mode state, interface state, correction state, and assurance state of Observatory Clusters, Regional Observatory Clusters, and National Dense Nexus Core relationships where appropriate.

9.19.3(b) Cluster maturity evidence inputs shall identify Cluster purpose, scope, topology, included Nodes, included Hubs, included Hotspots where any, included hosts, regional context where any, national context where any, source classes, data classes, evidence classes, output classes, access class, handling class, public-safe status, interoperability records, mismatch logs, confidence records, uncertainty records, contradiction records, data-gap records, public-safe output records, interface records, correction records, assurance records, and dependency links.

9.19.3(c) Cluster aggregation-state inputs may describe whether evidence aggregation is source-lined, method-versioned, context-preserving, non-duplicative, contradiction-aware, data-gap-aware, public-safe, confidence-aware, uncertainty-aware, and correctionable.

9.19.3(d) Cluster interoperability-state inputs may describe whether schemas, controlled vocabulary, data dictionaries, API conventions, map conventions, dashboard conventions, proof receipt references, public-safe output conventions, and correction records are sufficiently aligned for the recorded purpose without erasing material differences among sources, jurisdictions, hosts, communities, providers, sponsors, public authorities, or systems.

9.19.3(e) Cluster public-safe-state inputs may describe whether cluster dashboards, maps, reports, APIs, Evidence Packs, Decision Packs, public-safe summaries, GRF inputs, GRA inputs, Protocol Authority inputs, public authority learning materials, provider-facing materials, sponsor-facing materials, host-facing materials, community-facing materials, and Academy materials preserve boundary language, safe-location treatment, public-safe omissions, confidence, uncertainty, limitations, and correction path.

9.19.3(f) Cluster maturity evidence inputs shall not describe a Cluster, Regional Observatory Cluster, or National Dense Nexus Core as an official region, certified cluster, recognized cluster, investment zone, procurement zone, provider market, sponsor territory, public authority structure, protocol-effective cluster, finance-ready cluster, operationally cleared cluster, deployment-approved cluster, or execution-ready cluster by default.

9.19.3(g) Where Cluster maturity evidence is affected by missing Nodes, stale Hubs, mismatched schemas, source contradiction, data gaps, public-safe defects, cross-border defects, provider influence, sponsor influence, public authority ambiguity, finance overclaim, procurement implication, or correction failure, GCRI Canada shall qualify, downgrade, restrict, correct, supersede, withdraw, or refuse the Cluster maturity evidence input as appropriate.

9.19.3(h) The controlling rule shall be that Cluster maturity evidence describes cross-Node evidence and interoperability state for a defined purpose, not regional authority, market status, finance-readiness, procurement status, certification, recognition, protocol effect, or execution.

***

9.19.4 Host Maturity Evidence Inputs.\
9.19.4(a) GCRI Canada may steward host maturity evidence input methods for describing the evidence state, site-readiness state, facility-readiness state, data-readiness state, connectivity-readiness state, compute-readiness state, security-readiness state, public authority learning state, community-safeguard state, protected-knowledge state, public-safe state, provider-interface state, sponsor-boundary state, host-boundary state, correction state, renewal state, and closeout state of hosts or sites for a recorded Observatory purpose.

9.19.4(b) Host maturity evidence inputs shall identify host purpose, readiness scope, site or safe-site context, facility context where safe and material, data readiness records, connectivity readiness records, compute readiness records, security readiness records, public authority readiness records, community readiness records, public-safe readiness records, provider records, sponsor records, operator records where any, public authority records where any, community records where any, Indigenous or protected knowledge records where any, dashboards, maps, Evidence Packs, Decision Packs, public-safe summaries, correction records, renewal records, and dependency links.

9.19.4(c) Host maturity inputs may describe whether host evidence is current, source-lined, classified, permissioned, privacy-protective, cybersecurity-controlled, sovereign-data-compatible, infrastructure-sensitive-safe, community-safe, protected-knowledge-safe, provider-neutral, sponsor-independent, public-authority-bounded, finance-safe, procurement-safe, certification-safe, and correctionable.

9.19.4(d) Host maturity evidence shall not create or imply host certification, site certification, facility certification, approved host status, public authority-approved site status, procurement-ready site status, finance-ready host status, insurance-ready facility status, investment-ready location status, provider-preferred host status, sponsor-approved host status, community-approved site status, Nexus-compatible host status, deployment-ready site status, operational clearance, market authority, or execution consequence.

9.19.4(e) Host participation, host contribution, facility access, site access, sensor placement, compute availability, connectivity availability, data contribution, public authority attendance, provider participation, sponsor support, community participation, dashboard visibility, map visibility, benchmark success, Proof Receipt issuance, National Company relevance, Project SPV relevance, GRF interface use, GRA interface use, or Protocol Authority interface use shall not convert host maturity evidence into host status.

9.19.4(f) Host maturity evidence routed to GRF, GRA, Protocol Authority, Nexus Risk Management, Nexus Rails, National Nexus Consortiums, National Companies, Project SPVs, public authorities, providers, sponsors, hosts, operators, communities, Academy materials, or public-facing materials shall preserve no-certification, no-procurement, no-finance-readiness, no-public-authority, no-host-approval, no-community-consent-by-implication, no-provider-endorsement, no-sponsor-approval, no-protocol-effect unless separately created, no-deployment-approval, no-operational-clearance, no-execution, confidence, uncertainty, limitation, permitted-use, prohibited-use, and correction language.

9.19.4(g) Where host maturity evidence is overclaimed, stale, incomplete, unsupported, privacy-defective, public-safe-defective, public authority-confusing, finance-inflating, procurement-implying, provider-preferential, sponsor-validating, host-approval-implying, community-consent-implying, protected-knowledge-defective, or correction-defective, GCRI Canada shall qualify, downgrade, restrict, correct, supersede, withdraw, retract where appropriate, or refuse the input.

9.19.4(h) The controlling rule shall be that host maturity evidence describes the maturity of host evidence and safeguards for a defined purpose, not maturity of the host as a certified, approved, financed, procured, recognized, or deployed site.

***

9.19.5 Data, AI, Cybersecurity, Sovereign Compute, Public-Safe, and Community Safeguard Maturity Evidence Inputs.\
9.19.5(a) GCRI Canada may steward maturity evidence input methods for data governance, AI and model governance, cybersecurity, sovereign compute, public-safe publication, public authority boundaries, finance boundaries, procurement boundaries, provider neutrality, sponsor non-control, community safeguards, Indigenous safeguards, protected knowledge safeguards, privacy, accessibility, translation, localization, and correctionability across Observatory systems.

9.19.5(b) Data governance maturity inputs may describe whether datasets, source records, data lineage, permissions, licenses, lawful basis where applicable, consent or non-consent treatment where applicable, classification, retention, deletion, sealing, access controls, cross-border controls, sovereign data controls, public-safe controls, Dataset Cards, dataset registers, and correction paths are adequate for the recorded purpose.

9.19.5(c) AI and model governance maturity inputs may describe whether Model Registers, Model Cards, System Cards, Dataset Cards, Benchmark Cards, inference records, human review records, retrieval records, embedding records, agentic AI controls, AI incident records, model restriction records, model suspension records, model retirement records, public-safe AI output records, and correction paths are adequate for material AI use.

9.19.5(d) Cybersecurity maturity inputs may describe whether access controls, identity controls, least privilege, segmentation, isolation, logging, monitoring, encryption, key management, token management, secrets management, credential controls, vulnerability handling, incident handling, cyber-sensitive classification, export-control review, sanctions review, controlled-technology review, public-safe cyber disclosure, and correction paths are adequate for the recorded purpose.

9.19.5(e) Sovereign compute maturity inputs may describe whether approved compute environments, compute-to-data treatment, secure enclaves, confidential computing, air-gapped environments, no-download rooms, workload records, environment records, location records, jurisdiction records, provider records, custodian records, access logs, output records, cross-border controls, decommissioning paths, and correction paths are adequate for the recorded purpose.

9.19.5(f) Public-safe maturity inputs may describe whether outputs, dashboards, maps, reports, APIs, Evidence Packs, Decision Packs, public-safe summaries, Academy materials, media materials, public authority learning materials, GRF inputs, GRA inputs, Protocol Authority inputs, provider-facing materials, sponsor-facing materials, host-facing materials, operator-facing materials, and community-facing materials preserve public-safe omissions, responsible non-disclosure, confidence, uncertainty, limitations, boundary language, correction path, withdrawal path, retraction path, and misuse response.

9.19.5(g) Community safeguard and protected knowledge maturity inputs may describe whether community protocols, Indigenous protocols where applicable, consent or non-consent treatment where applicable, territorial context, cultural context, environmental knowledge context, sensitive-site treatment, public-safe mapping limits, source protection, accessibility, translation, localization, challenge pathways, withdrawal pathways where applicable, non-extraction, non-commodification, do-no-harm controls, protected knowledge restrictions, and correction paths are adequate for the recorded purpose.

9.19.5(h) Maturity inputs under this section shall not be translated into certification, compliance determination, public authority approval, finance-readiness, procurement approval, security certification, AI certification, data certification, sovereign approval, public-safe approval, community approval, Indigenous approval, provider endorsement, sponsor approval, protocol effect, operational clearance, deployment approval, legal status, market authority, or execution consequence by default.

9.19.5(i) The controlling rule shall be that cross-domain maturity evidence describes the state of controls and safeguards for a defined evidence purpose, not legal compliance, certification, public authority status, finance value, procurement status, or execution readiness.

***

9.19.6 GCRI Canada Evidence Inputs to GRF Maturity Records Without Issuing GRF Maturity.\
9.19.6(a) GCRI Canada may provide evidence inputs, source records, method records, observability outputs, technical baselines, public-good software records, Evidence Packs, Decision Packs, dashboards, maps, public-safe summaries, correction signals, and assurance notes to The Global Risks Forum (GRF) for use by GRF within its separate public-good registry, recognition, maturity-records, claims-discipline, standing, stakeholder-formation, public-safe reporting, and public-facing legitimacy stewardship functions.

9.19.6(b) GRF-facing maturity evidence input records shall identify receiving GRF interface, purpose, evidence classes, data classes, output classes, source records, method records, compute records where applicable, model records where applicable, public-safe status, access class, handling class, confidence, uncertainty, limitations, no-GRF-maturity-by-GCRI boundary, no-recognition-by-GCRI boundary, no-claims-approval-by-GCRI boundary, no-standing-by-GCRI boundary, permitted use, prohibited use, correction path, supersession path, withdrawal path, retraction path where applicable, and dependency links.

9.19.6(c) GCRI Canada shall not issue GRF maturity records, GRF standing, GRF recognition, GRF claims approval, GRF registry status, public-facing legitimacy status, stakeholder-formation status, or public-safe reporting status through maturity evidence inputs.

9.19.6(d) Any GRF maturity record, recognition, standing, claims approval, registry status, public-facing legitimacy outcome, stakeholder-formation outcome, or public-safe reporting outcome shall arise only through GRF’s own authority, process, records, review, accountability, corrections, and applicable governance instruments, not through GCRI Canada evidence by implication.

9.19.6(e) GCRI Canada evidence supplied to GRF shall not be framed as determinative unless GRF separately determines its effect under GRF governance. GCRI Canada evidence may support, qualify, challenge, correct, suspend, supersede, or inform GRF processes, but shall not replace GRF judgment, GRF records, GRF authority, or GRF accountability.

9.19.6(f) Where GCRI Canada evidence supplied to GRF is corrected, downgraded, restricted, superseded, withdrawn, retracted, or materially reclassified, GCRI Canada shall issue correction signals or dependency notices to GRF where appropriate and review affected public-safe summaries, interface records, dashboards, maps, Evidence Packs, Decision Packs, Academy materials, and public claims.

9.19.6(g) Where GRF-facing materials are misused to imply that GCRI Canada issued maturity, recognition, standing, claims approval, registry status, or public-facing legitimacy, GCRI Canada shall correct, relabel, restrict, withdraw, reissue, request removal of misleading references, notify GRF where appropriate, suspend affected interface use, or pursue contractual or legal remedies where appropriate.

9.19.6(h) The controlling rule shall be that GCRI Canada may supply evidence to GRF maturity processes, but only GRF may create GRF maturity records or GRF recognition under its own governance.

***

9.19.7 GCRI Canada Evidence Inputs to GRA Finance-Readiness Without Issuing Finance-Readiness.\
9.19.7(a) GCRI Canada may provide maturity evidence inputs, resilience evidence, risk evidence, host readiness evidence, node evidence, cluster evidence, degraded-mode evidence, observability evidence, source comparison records, confidence records, uncertainty records, limitation statements, compute records, model records, dataset records, benchmark records, Proof Receipt Records, Evidence Packs, Decision Packs, dashboards, maps, public-safe summaries, controlled annexes, correction signals, and assurance notes to The Global Risks Alliance (GRA), Nexus Rails, RNFD, NFD, UNFSD, capital-reader literacy contexts, insurance-readiness input contexts, and related finance-facing learning interfaces, provided that such inputs remain non-financial, non-advisory, non-rating, non-guaranteeing, evidence-supporting, public-safe where externally released, and correctionable.

9.19.7(b) GRA-facing or finance-facing maturity evidence input records shall identify receiving interface, purpose, evidence classes, data classes, output classes, source records, method records, compute records where applicable, model records where applicable, public-safe status, finance-safe status, access class, handling class, confidence, uncertainty, limitations, no-advice boundary, no-rating boundary, no-guarantee boundary, no-finance-readiness-by-GCRI boundary, no-public-finance-approval boundary, no-procurement boundary, permitted use, prohibited use, correction path, supersession path, withdrawal path, retraction path where applicable, and dependency links.

9.19.7(c) GCRI Canada shall not issue finance-readiness, capital-readiness, insurance-readiness, investment advice, securities recommendations, brokerage, placement, finder activity, lending decisions, underwriting decisions, insurance approvals, ratings, guarantees, public finance approvals, bankability determinations, fundability determinations, capital commitments, credit quality determinations, insurance quality determinations, investment quality determinations, financial suitability determinations, procurement approvals, project approvals, or execution consequences through maturity evidence inputs.

9.19.7(d) Any finance-readiness, insurance-readiness, capital-reader interpretation, lender action, insurer action, investor action, GRA determination, Nexus Rails routing consequence, RNFD consequence, NFD consequence, UNFSD consequence, public finance consequence, procurement consequence, National Company action, or Project SPV action shall arise only through the competent actor’s own authority, process, records, review, accountability, corrections, and applicable governance instruments, not through GCRI Canada maturity evidence by implication.

9.19.7(e) Confidence scores, maturity evidence labels, readiness-context indicators, resilience indicators, host readiness evidence, node evidence, cluster evidence, dashboards, maps, benchmark results, proof receipts, public-safe summaries, AI-generated summaries, Evidence Packs, or Decision Packs shall not be framed by GCRI Canada as ratings, finance-readiness determinations, insurance-readiness determinations, bankability determinations, fundability determinations, public finance approvals, investment recommendations, procurement recommendations, provider preferences, project approvals, or execution instructions.

9.19.7(f) Where GRA-facing or finance-facing evidence is corrected, downgraded, restricted, superseded, withdrawn, retracted, or materially reclassified, GCRI Canada shall issue correction signals or dependency notices to GRA, Nexus Rails, RNFD, NFD, UNFSD, or other affected finance-facing interfaces where appropriate and review affected public-safe summaries, dashboards, maps, Evidence Packs, Decision Packs, Academy materials, and public claims.

9.19.7(g) Where finance-facing materials are misused to imply that GCRI Canada issued finance-readiness, investment advice, insurance-readiness, rating, guarantee, bankability, public finance approval, procurement approval, project approval, or execution consequence, GCRI Canada shall correct, relabel, restrict, withdraw, reissue, request removal of misleading references, notify affected interfaces where appropriate, suspend affected interface use, or pursue contractual or legal remedies where appropriate.

9.19.7(h) The controlling rule shall be that GCRI Canada may supply evidence to finance-readiness interfaces, but it shall not create finance-readiness, rate, guarantee, advise, insure, lend, invest, procure, approve projects, or execute finance.

***

9.19.8 Stage Truth, No Narrative Acceleration, and No False Maturity.\
9.19.8(a) GCRI Canada shall preserve stage truth in all maturity evidence inputs. Stage truth requires that evidence describe the actual recorded state of a Node, Hub, Cluster, Hotspot, Regional Observatory Cluster, National Dense Nexus Core, host, site, dataset, model, compute environment, dashboard, map, safeguard, public-safe output, interface, system, or method without narrative acceleration, marketing inflation, status borrowing, institutional exaggeration, sponsor influence, provider influence, public authority implication, finance-facing inflation, procurement implication, or unsupported maturity language.

9.19.8(b) Narrative acceleration is prohibited. GCRI Canada shall not describe an emerging, partial, pilot, experimental, sandbox, controlled-room, early-stage, unreviewed, restricted, public-safe-limited, correction-pending, degraded, stale, disputed, incomplete, or assurance-pending evidence state as mature, validated, recognized, certified, finance-ready, procurement-ready, deployment-ready, Nexus-compatible, official, public-authority-supported, safe, preferred, bankable, insurable, or operationally cleared.

9.19.8(c) False maturity includes any statement, score, colour, label, dashboard status, map marker, maturity stage, readiness label, proof receipt reference, benchmark summary, AI-generated summary, public-safe summary, provider statement, sponsor statement, host statement, public authority reference, GRF reference, GRA reference, Protocol Authority reference, National Company reference, Project SPV reference, or public claim that overstates the maturity, readiness, recognition, finance value, procurement value, certification status, protocol status, public authority status, operational status, deployment status, or execution status of the underlying evidence.

9.19.8(d) GCRI Canada shall preserve distinctions among concept, draft, proposed method, sandbox method, pilot method, controlled-room method, internal evidence, provisional evidence, reviewed evidence, public-safe evidence, corrected evidence, superseded evidence, retired evidence, GRF-input evidence, GRA-input evidence, Protocol Authority-input evidence, public authority learning evidence, provider-neutral evidence, and execution-context evidence held by separate actors.

9.19.8(e) Maturity evidence shall include confidence, uncertainty, limitations, data gaps, contradiction status, review status, assurance status, public-safe status, correction status, supersession status, withdrawal status where applicable, and retraction status where applicable, where material to prevent false maturity.

9.19.8(f) GCRI Canada shall not permit sponsor support, provider participation, public authority attendance, media attention, capital-reader interest, dashboard display, map display, benchmark success, Proof Receipt issuance, Academy use, GRF routing, GRA routing, Protocol Authority routing, National Company relevance, or Project SPV relevance to accelerate stage language beyond the evidence record.

9.19.8(g) Where stage truth is compromised, GCRI Canada shall correct, relabel, downgrade, qualify, restrict, supersede, withdraw, retract where appropriate, update training, update methods, update dashboards, update maps, issue public-safe or controlled notice where appropriate, and review affected dependencies.

9.19.8(h) The controlling rule shall be that stage truth is a constitutional evidence discipline: maturity must follow records, not narrative.

***

9.19.9 Maturity Evidence Correction, Downgrade, Suspension, and Re-Issue.\
9.19.9(a) GCRI Canada shall maintain correction, downgrade, suspension, restriction, supersession, withdrawal, retraction, re-issue, method-update, training-update, technical-control-update, dashboard-update, map-update, API-update, interface-update, and assurance-update methods for maturity evidence inputs.

9.19.9(b) Correction shall be required where maturity evidence contains material error, source-lineage defect, evidence-class defect, data-class defect, confidence defect, understated uncertainty, missing limitation, stale evidence, incomplete evidence, contradicted evidence, incorrect maturity language, public-safe defect, public authority confusion, finance overclaim, procurement implication, certification implication, recognition implication, protocol implication, provider preference, sponsor validation, host approval implication, operator-control implication, community consent implication, protected knowledge exposure, privacy defect, cybersecurity defect, sovereign data issue, cross-border defect, infrastructure-risk exposure, legal defect, export-control issue, sanctions issue, controlled-technology issue, or correction failure.

9.19.9(c) Downgrade shall be used where later evidence, source review, assurance review, contradiction, missing data, degraded-mode evidence, incident evidence, public-safe review, privacy review, cybersecurity review, sovereign data review, community safeguard review, provider-neutrality review, sponsor non-control review, public authority boundary review, finance-boundary review, procurement-boundary review, or correction review reduces confidence, scope, readiness description, maturity description, permitted use, or public-safe status.

9.19.9(d) Suspension or restriction shall be used where maturity evidence should not be used pending review because of unresolved dispute, material uncertainty, suspected overclaim, source defect, data defect, model defect, compute defect, cybersecurity concern, privacy concern, protected knowledge concern, public-safe concern, provider influence, sponsor influence, public authority confusion, finance-facing risk, procurement-facing risk, certification implication, recognition implication, protocol implication, or correction failure.

9.19.9(e) Supersession shall be used where maturity evidence is replaced by fuller evidence, corrected evidence, renewed evidence, assurance-reviewed evidence, updated source records, updated compute records, updated model records, updated dashboard records, updated map records, updated API records, updated public authority context, updated host context, updated provider context, updated sponsor context, updated community context, updated GRF interface status, updated GRA interface status, updated Protocol Authority interface status, or updated public-safe classification.

9.19.9(f) Withdrawal or retraction shall be used where maturity evidence should no longer be used or relied upon because it is materially inaccurate, unsafe, misleading, overclaimed, unsupported, public-safe defective, authority-confusing, finance-inflating, procurement-implying, certification-implying, recognition-implying, protocol-implying, provider-preferential, sponsor-validating, host-approval-implying, community-consent-implying, privacy-defective, cyber-defective, protected-knowledge-defective, infrastructure-risk-exposing, legally defective, or correction-defective.

9.19.9(g) Re-issue shall require corrected source records, corrected maturity input language, corrected confidence, corrected uncertainty, corrected limitations, corrected public-safe status, corrected boundary language, corrected dependency notices where appropriate, corrected dashboard or map status where applicable, and reviewer record.

9.19.9(h) Where maturity evidence correction affects GRF inputs, GRA inputs, Protocol Authority inputs, Nexus Risk Management materials, Nexus Rails materials, National Nexus Consortium materials, Regional Nexus Consortium materials, National Company materials, Project SPV materials, public authority learning materials, provider-facing materials, sponsor-facing materials, host-facing materials, operator-facing materials, community-facing materials, Academy materials, repositories, dashboards, maps, APIs, media materials, or public claims, GCRI Canada shall issue public-safe notice or controlled notice as appropriate and review affected dependencies.

9.19.9(i) Correction, downgrade, suspension, restriction, supersession, withdrawal, retraction, or re-issue shall not itself create certification, recognition, finance-readiness, public authority decision, regulatory finding, procurement approval, provider endorsement, sponsor finding, host finding, operator finding, rating, guarantee, public warning, emergency command, protocol effect, operational clearance, legal status, market authority, deployment approval, or execution consequence by default.

9.19.9(j) The controlling rule shall be that maturity evidence must move downward, pause, or be withdrawn as readily as it moves upward, because maturity that cannot be corrected is not evidence.

***

9.19.10 Maturity Evidence Records and Interface Logs.\
9.19.10(a) GCRI Canada shall maintain, or cause to be maintained, maturity evidence records and interface logs for material maturity evidence methods, Node maturity inputs, Cluster maturity inputs, Host maturity inputs, data maturity inputs, AI maturity inputs, cybersecurity maturity inputs, sovereign compute maturity inputs, public-safe maturity inputs, community safeguard maturity inputs, GRF-facing inputs, GRA-facing inputs, Protocol Authority-facing inputs, public authority learning inputs, provider-facing inputs, sponsor-facing inputs, host-facing inputs, operator-facing inputs, National Company inputs, Project SPV inputs, dashboards, maps, APIs, Evidence Packs, Decision Packs, public-safe summaries, disputes, incidents, corrections, dependency notices, assurance reviews, renewal, withdrawal, retirement, archive, and closeout events.

9.19.10(b) Maturity evidence records shall identify record title or identifier, maturity input class, maturity domain, maturity scope, maturity purpose, relevant Node, Hub, Cluster, Hotspot, Regional Observatory Cluster, National Dense Nexus Core, host, site, system, dataset, model, compute environment, dashboard, map, interface, or safeguard context, provider where any, operator where any, host where any, sponsor where any, public authority context where any, community context where any, Indigenous or protected knowledge context where any, GRF context where any, GRA context where any, Protocol Authority context where any, National Company context where any, Project SPV context where any, technology domain, risk domain, data class, evidence class, output class, audience class, access class, handling class, public-safe status, privacy status, cybersecurity status, sovereign data status, infrastructure-sensitive status, public authority status, finance-sensitive status, provider-sensitive status, sponsor-sensitive status, host-sensitive status, operator-sensitive status, community-protected status, Indigenous or protected knowledge status, legal sensitivity, license status, export-control sensitivity, sanctions sensitivity, controlled-technology sensitivity, permitted uses, prohibited uses, publication limits, and correction path.

9.19.10(c) Interface logs shall identify receiving interface, sending interface, date, purpose, capacity of recipient, materials shared, materials received, version, access class, handling class, public-safe status, finance-safe status where applicable, procurement-safe status where applicable, recognition-boundary status where applicable, certification-boundary status where applicable, protocol-boundary status where applicable, public authority boundary status where applicable, provider-neutrality status, sponsor non-control status, host-boundary status, operator-boundary status, permitted use, prohibited use, boundary language, correction path, dependency path, notice path, and closeout path.

9.19.10(d) Review records shall identify review cycle, reviewers, source review, evidence review, data review, model review, compute review, dashboard review, map review, public-safe review, public authority boundary review, finance-boundary review, procurement-boundary review, certification-boundary review, recognition-boundary review, protocol-boundary review, provider-neutrality review, sponsor non-control review, host-boundary review, operator-boundary review, community safeguard review, protected knowledge review, privacy review, cybersecurity review, sovereign data review, export-control review where applicable, sanctions review where applicable, controlled-technology review where applicable, and correction review.

9.19.10(e) Correction records shall identify corrected source, corrected evidence class, corrected data class, corrected maturity input, corrected maturity language, corrected stage description, corrected confidence, corrected uncertainty, corrected limitation, corrected dashboard, corrected map, corrected API, corrected Evidence Pack, corrected Decision Pack, corrected public-safe output, corrected GRF interface, corrected GRA interface, corrected Protocol Authority interface, corrected public authority reference, corrected provider reference, corrected sponsor reference, corrected host reference, corrected operator reference, corrected community reference, corrected boundary language, prior status, corrected status, effective date, reviewer, affected dependencies, notice decision, access change, archive treatment, and continuing limitations.

9.19.10(f) Supersession records shall identify replacement maturity evidence record, changed maturity scope, changed evidence base, changed source status, changed confidence, changed uncertainty, changed limitation, changed public-safe status, changed interface status, changed boundary language, continuing validity where any, discontinued reliance where any, and downstream dependency treatment.

9.19.10(g) Withdrawal or retraction records shall be used where maturity evidence or maturity-interface materials should no longer be used or relied upon because of material error, unsafe disclosure, false maturity, narrative acceleration, public-safe defect, public authority confusion, finance overclaim, procurement implication, certification implication, recognition implication, protocol implication, provider-preferential framing, sponsor-validation framing, host approval implication, operator-control implication, community consent implication, protected knowledge exposure, community harm risk, privacy defect, cybersecurity defect, sovereign data issue, cross-border defect, infrastructure-risk exposure, legal defect, export-control issue, sanctions issue, controlled-technology issue, or correction failure.

9.19.10(h) Maturity evidence records shall be linked, where applicable, to National Dense Core records, Regional Observatory Cluster records, Cluster records, Hub records, Node records, Hotspot records, host readiness records, AI-RAN records, DePIN records, sensor records, geospatial records, cyber telemetry records, digital twin records, dashboard records, degraded-mode records, Observatory Methods Register entries, Evidence Register entries, Source Comparison Records, Dataset Register entries, Model Register entries, System Card entries, Benchmark Card entries, Compute Workload Records, Compute Environment Records, Inference Records, Human Review Records, Retrieval and Embedding Records, Proof Receipt Records, Public-Safe Output Records, AI Incident Records, Correction Records, Dependency Records, Truth Engine Records, Nexus Risk Management records, public authority records, GRF interface records, GRA interface records, Protocol Authority interface records, RNFD records, Nexus Rails records, Regional Nexus Consortium records, National Nexus Consortium records, National Company records, Project SPV records, operator records, provider records, sponsor records, host records, community records, university records, Nexus interface records, and public claims records.

9.19.10(i) Maturity evidence records, interface logs, review records, correction records, supersession records, withdrawal records, retraction records, retirement records, archive records, notices, assurance, renewal, and closeout shall not create certification, recognition, finance-readiness, public authority decision, regulatory finding, procurement approval, provider endorsement, sponsor approval, host approval, operator approval, community consent, rating, guarantee, public warning, emergency command, protocol effect, operational clearance, legal status, market authority, infrastructure operation, remediation approval, deployment approval, national authority, regional authority, public-facing maturity record, GRF maturity record, GRA finance-readiness, or execution consequence by default.

9.19.10(j) The controlling rule shall be that maturity evidence is trustworthy only when stage, scope, source, confidence, uncertainty, limitations, interface use, boundary language, correction, downgrade, suspension, re-issue, and dependency logs remain recorded with enough precision to prevent evidence inputs from becoming unsupported maturity, recognition, finance, procurement, certification, authority, protocol effect, or execution.

### 9.20 Observatory Evidence Packs

9.20.1 Observatory Evidence Pack Purpose.\
9.20.1(a) GCRI Canada may steward Observatory Evidence Pack methods as a structured evidence, source-lineage, methods, observability, confidence, uncertainty, limitation, public-safe, boundary, correction, and re-issue discipline for organizing material evidence arising from Observatory Nodes, Hubs, Clusters, Hotspots, Regional Observatory Clusters, National Dense Nexus Cores, sovereign compute environments, sensors, AI-RAN systems, O-RAN systems, private wireless systems, DePIN systems, cyber-physical systems, geospatial systems, digital twins, dashboards, maps, APIs, public authority learning contexts, host contexts, provider contexts, sponsor-supported contexts where any, community contexts, Indigenous or protected knowledge contexts, and other Observatory methods domains.

9.20.1(b) An Observatory Evidence Pack may be prepared for internal evidence review, controlled-room review, public authority learning, GRF input support, GRA input support, Protocol Authority input support, Nexus Risk Management input support, Nexus Rails input support, Nexus Grid input support, Nexus Academy materials, National Nexus Consortium learning, Regional Nexus Consortium learning, National Company evidence discipline, Project SPV evidence discipline, provider-neutral technical review, host learning, operator learning, community learning, public-safe publication, correction, supersession, assurance, renewal, closeout, or other recorded Observatory purpose.

9.20.1(c) An Observatory Evidence Pack shall be treated as an evidence-organizing artifact only. It shall not constitute certification, recognition, maturity record, claims approval, finance-readiness, investment advice, rating, guarantee, insurance approval, lending decision, underwriting decision, public finance approval, procurement approval, provider preference, sponsor approval, host approval, operator approval, public authority decision, public warning, emergency command, regulatory determination, protocol effect, conformance determination, Nexus-compatible status, operational clearance, deployment approval, infrastructure operation, market authority, legal status, or execution consequence by default.

9.20.1(d) Observatory Evidence Pack methods shall be records-valid, source-lined, method-versioned, audience-aware, classification-aware, confidence-aware, uncertainty-aware, limitation-aware, contradiction-aware, data-gap-aware, public-safe, privacy-protective, cybersecurity-controlled, sovereignty-compatible, infrastructure-sensitive, community-sensitive, Indigenous-safeguard-aware, protected-knowledge-sensitive, provider-neutral, sponsor-independent, host-bounded, operator-bounded, public-authority-bounded, finance-safe, procurement-safe, non-certifying, non-recognizing, non-executing, and correctionable.

9.20.1(e) GCRI Canada’s preparation, stewardship, receipt, review, routing, public-safe summarization, correction, re-issue, or registration of an Observatory Evidence Pack shall not make GCRI Canada a public authority, regulator, emergency-management actor, public warning issuer, infrastructure operator, telecommunications operator, cyber operator, finance actor, procurement actor, certification body, recognition body, Protocol Authority, provider, sponsor, host, operator, National Company, Project SPV, market actor, or execution actor by default.

9.20.1(f) Each Observatory Evidence Pack shall identify, where material, purpose, scope, audience, source records, data records, method records, compute records, model records, dashboard records, map records, API records, evidence classes, data classes, output classes, access class, handling class, public-safe status, confidence, uncertainty, limitations, contradiction status, data-gap status, public-safe omissions, boundary notes, permitted use, prohibited use, correction path, supersession path, withdrawal path, retraction path where applicable, re-issue protocol, dependency links, and register status.

9.20.1(g) Where an Observatory Evidence Pack is used externally or publicly, GCRI Canada shall preserve controlled vocabulary, source lineage, evidence status, confidence, uncertainty, limitations, public-safe status, no-certification language, no-recognition language, no-finance-readiness language, no-procurement language, no-public-authority language, no-public-warning language, no-emergency-command language, no-protocol-effect language unless separately created by Protocol Authority, no-provider-endorsement language, no-sponsor-approval language, no-host-approval language, no-operator-instruction language, no-deployment-approval language, no-execution language, and correction path.

9.20.1(h) The controlling rule shall be that an Observatory Evidence Pack organizes evidence for disciplined understanding and bounded use; it does not transform evidence into authority, approval, maturity, finance, procurement, recognition, certification, protocol effect, warning, command, or execution.

***

9.20.2 Node Evidence Pack.\
9.20.2(a) GCRI Canada may steward Node Evidence Pack methods for organizing evidence concerning an Observatory Node’s local evidence purpose, host context, sensor context, connectivity context, compute context, data context, public authority learning context, community context, provider context, sponsor-supported context where any, public-safe output context, degraded-mode context, correction status, and closeout status.

9.20.2(b) A Node Evidence Pack shall identify Node title or identifier, Node purpose, Node scope, host context, site or safe-site treatment, relevant community context, public authority context where any, provider context where any, sponsor context where any, operator context where any, data classes, evidence classes, output classes, access class, handling class, public-safe status, permitted uses, prohibited uses, and correction path.

9.20.2(c) Node source components may include sensor records, reference sensor records, AI-RAN records, O-RAN records, private wireless records, DePIN records, geospatial records, cyber telemetry records, digital twin records, compute workload records, compute environment records, dashboard records, map records, API records, field observation records, host contribution records, public authority learning records, community records, provider records, sponsor records, incident records, degraded-mode records, quality records, and correction records.

9.20.2(d) A Node Evidence Pack shall distinguish local evidence, local context, measured evidence, inferred evidence, modeled evidence, public authority context, community context, protected knowledge context, provider-supplied evidence, sponsor-supplied evidence, host-supplied evidence, dashboard presentation, map presentation, public-safe summary, and any separate downstream decision made by a competent actor.

9.20.2(e) Node Evidence Packs shall identify confidence, uncertainty, limitations, missing data, contradiction status, calibration status, timing status, location or safe-location treatment, privacy status, cybersecurity status, sovereign data status, infrastructure-sensitive status, public-safe omissions, boundary language, and dependency links where material.

9.20.2(f) A Node Evidence Pack shall not describe a Node as certified, recognized, mature, finance-ready, procurement-ready, deployment-ready, Nexus-compatible, public authority-approved, provider-preferred, sponsor-approved, host-approved, operationally cleared, safe, official, or execution-ready by default.

9.20.2(g) Where a Node Evidence Pack is corrected, restricted, superseded, withdrawn, retracted, or made stale by later evidence, GCRI Canada shall update affected records, dashboards, maps, public-safe summaries, interface logs, dependency notices, and register entries as appropriate.

9.20.2(h) The controlling rule shall be that a Node Evidence Pack describes the recorded evidence state of a local Observatory Node, not the certified or approved status of the Node.

***

9.20.3 Hub Evidence Pack.\
9.20.3(a) GCRI Canada may steward Hub Evidence Pack methods for organizing evidence concerning an Observatory Hub’s coordination, aggregation, routing, technical support, public-safe interface, public authority learning, host interface, provider interface, community interface, degraded-mode, dashboard, map, API, and correction functions.

9.20.3(b) A Hub Evidence Pack shall identify Hub title or identifier, Hub purpose, Hub scope, participating Nodes where applicable, aggregation role, routing role, controlled-room role where any, public authority learning role where any, provider-interface role where any, host-interface role where any, community-interface role where any, access class, handling class, public-safe status, permitted uses, prohibited uses, and correction path.

9.20.3(c) Hub source components may include Node Evidence Packs, source comparison records, aggregation records, interface records, data-routing records, controlled-room records, data-room records, clean-room records, compute-to-data records, dashboard records, map records, API records, public authority learning records, host records, provider records, sponsor records where any, community records, incident records, degraded-mode records, public-safe output records, and correction records.

9.20.3(d) A Hub Evidence Pack shall distinguish evidence aggregation from evidence authority. The presence of multiple Nodes, hosts, sources, dashboards, public authority participants, providers, sponsors, or community inputs shall not create corroboration, approval, public warning, public authority status, procurement relevance, finance-readiness, certification, recognition, protocol effect, or execution consequence without separate recorded method and competent authority where applicable.

9.20.3(e) Hub Evidence Packs shall identify aggregation method, source independence, source conflict, contradiction treatment, missing data, routing limits, access controls, public-safe omissions, confidence, uncertainty, limitations, boundary language, and dependency links where material.

9.20.3(f) A Hub Evidence Pack shall not describe a Hub as a regional authority, public authority room, procurement hub, finance hub, certified coordination body, recognized ecosystem, provider marketplace, sponsor territory, operational command centre, emergency-management structure, or execution vehicle by default.

9.20.3(g) Where a Hub Evidence Pack is corrected, restricted, superseded, withdrawn, retracted, or made stale by later evidence, GCRI Canada shall update affected Node relationships, dashboards, maps, public-safe summaries, interface logs, dependency notices, and register entries as appropriate.

9.20.3(h) The controlling rule shall be that a Hub Evidence Pack organizes coordination and aggregation evidence, but does not make the Hub an authority or execution structure.

***

9.20.4 Cluster Evidence Pack.\
9.20.4(a) GCRI Canada may steward Cluster Evidence Pack methods for organizing evidence concerning an Observatory Cluster’s multi-Node, multi-host, multi-domain, regional, technological, risk-domain, interoperability, aggregation, comparison, degraded-mode, public-safe, interface, correction, and assurance functions.

9.20.4(b) A Cluster Evidence Pack shall identify Cluster title or identifier, Cluster purpose, Cluster scope, topology, included Nodes, included Hubs where any, included Hotspots where any, included hosts, source classes, technology domains, risk domains, data classes, evidence classes, output classes, access class, handling class, public-safe status, permitted uses, prohibited uses, and correction path.

9.20.4(c) Cluster source components may include Node Evidence Packs, Hub Evidence Packs, Hotspot Evidence Packs where applicable, source comparison records, interoperability records, mismatch logs, aggregation records, confidence records, uncertainty records, contradiction records, data-gap records, dashboard records, map records, API records, public authority learning records, provider records, sponsor records where any, host records, community records, incident records, degraded-mode records, public-safe output records, assurance records, and correction records.

9.20.4(d) A Cluster Evidence Pack shall distinguish source aggregation, source comparison, corroboration, contradiction, mismatch, interoperability, data gap, regional pattern, local pattern, dashboard pattern, map pattern, modeled pattern, public-safe summary, and any separate downstream decision made by a competent actor.

9.20.4(e) Cluster Evidence Packs shall identify confidence, uncertainty, limitations, mismatch status, interoperability limits, schema limits, controlled vocabulary limits, data quality, missing Nodes, missing Hubs, missing sources, stale sources, public-safe omissions, boundary language, and dependency links where material.

9.20.4(f) A Cluster Evidence Pack shall not describe a Cluster as an official region, procurement zone, investment zone, public warning area, certified cluster, recognized cluster, provider market, sponsor territory, finance-ready cluster, protocol-effective cluster, operationally cleared cluster, deployment-approved cluster, or execution-ready structure by default.

9.20.4(g) Where a Cluster Evidence Pack is corrected, restricted, superseded, withdrawn, retracted, or made stale by later evidence, GCRI Canada shall update affected Node, Hub, Hotspot, host, dashboard, map, API, public-safe, interface, dependency, assurance, and register records as appropriate.

9.20.4(h) The controlling rule shall be that a Cluster Evidence Pack makes cross-Node evidence traceable without turning clustered evidence into authority, market status, finance status, certification, recognition, or execution.

***

9.20.5 Hotspot Evidence Pack.\
9.20.5(a) GCRI Canada may steward Hotspot Evidence Pack methods for organizing evidence concerning localized evidence, connectivity, sensing, compute, field-observation, host, community, public authority, provider, sponsor-supported, degraded-mode, dashboard, map, public-safe communication, and correction contexts.

9.20.5(b) A Hotspot Evidence Pack shall identify Hotspot title or identifier, Hotspot purpose, localized scope, location or safe-location treatment, host context, community context, Indigenous or protected knowledge context where any, public authority context where any, provider context where any, sponsor context where any, data classes, evidence classes, output classes, access class, handling class, public-safe status, permitted uses, prohibited uses, and correction path.

9.20.5(c) Hotspot source components may include localized sensor records, AI-RAN records, O-RAN records, private wireless records, DePIN records, geospatial records, field observation records, cyber telemetry records, digital twin records, dashboard records, map records, API records, host contribution records, community records, protected knowledge records where any, public authority learning records, provider records, sponsor records where any, consent or non-consent records where applicable, incident records, public-safe communication records, and correction records.

9.20.5(d) A Hotspot Evidence Pack shall distinguish localized evidence attention from public warning, public authority presence, deployment approval, host approval, community approval, provider endorsement, sponsor validation, procurement relevance, finance-readiness, certification, recognition, protocol effect, market status, or execution consequence.

9.20.5(e) Hotspot Evidence Packs shall identify confidence, uncertainty, limitations, local sensitivity, safe-location treatment, sensitive-site treatment, small-community risk, re-identification risk, public authority reference limits, community safeguard limits, protected knowledge limits, public-safe omissions, boundary language, and dependency links where material.

9.20.5(f) A Hotspot Evidence Pack shall not describe a Hotspot as an official hazard area, public warning area, public authority presence, deployment-approved site, certified site, recognized site, finance-ready site, procurement-ready site, provider-preferred area, sponsor-approved area, host-approved area, community-approved area, or execution site by default.

9.20.5(g) Where a Hotspot Evidence Pack is corrected, restricted, superseded, withdrawn, retracted, or made stale by later evidence, GCRI Canada shall update affected local communications, dashboards, maps, public-safe summaries, community-facing records, public authority-facing records, provider-facing records, sponsor-facing records, host-facing records, dependency notices, and register entries as appropriate.

9.20.5(h) The controlling rule shall be that a Hotspot Evidence Pack localizes evidence attention while preserving local safety, local dignity, local boundaries, and correctionability.

***

9.20.6 Regional Cluster Evidence Pack.\
9.20.6(a) GCRI Canada may steward Regional Cluster Evidence Pack methods for organizing evidence concerning a Regional Observatory Cluster’s regional context, hazard evidence, host readiness evidence, public authority learning, community safeguards, Indigenous safeguards, protected knowledge controls, data sovereignty, cross-border controls, public-safe publication, GRF interface, GRA interface, Nexus Risk Management interface, Nexus Rails interface, Regional Nexus Consortium interface, National Nexus Consortium interface, National Company interface, Project SPV interface, correction, renewal, and assurance functions.

9.20.6(b) A Regional Cluster Evidence Pack shall identify Regional Observatory Cluster title or identifier, regional purpose, regional scope, jurisdictional context, geographic or functional scope, included Nodes, included Hubs, included Clusters, included Hotspots where any, host contexts, public authority contexts, community contexts, Indigenous or protected knowledge contexts where any, provider contexts, sponsor contexts where any, data classes, evidence classes, output classes, access class, handling class, public-safe status, permitted uses, prohibited uses, and correction path.

9.20.6(c) Regional Cluster source components may include Node Evidence Packs, Hub Evidence Packs, Cluster Evidence Packs, Hotspot Evidence Packs, regional hazard records, host readiness records, public authority learning records, community safeguard records, Indigenous safeguard records where applicable, protected knowledge records where any, data sovereignty records, cross-border records, dashboards, maps, APIs, Evidence Packs, Decision Packs, public-safe summaries, GRF interface records, GRA interface records, Nexus Risk Management records, Nexus Rails records, Regional Nexus Consortium records, National Nexus Consortium records, National Company records, Project SPV records, provider records, sponsor records where any, incident records, correction records, renewal records, and assurance records.

9.20.6(d) A Regional Cluster Evidence Pack shall distinguish regional evidence from regional authority. Regional hazard evidence, regional host readiness evidence, regional dashboards, regional maps, public authority participation, Regional Nexus Consortium relevance, National Nexus Consortium relevance, National Company relevance, Project SPV relevance, GRF interface use, GRA interface use, Nexus Rails interface use, Nexus Risk Management interface use, provider participation, sponsor support, host participation, community participation, or media interest shall not create regional public authority, public warning, procurement approval, finance-readiness, certification, recognition, protocol effect, provider market, sponsor territory, deployment approval, or execution authority.

9.20.6(e) Regional Cluster Evidence Packs shall identify confidence, uncertainty, limitations, regional data gaps, cross-border limits, sovereign data status, public authority boundary status, public-safe publication limits, community safeguard limits, protected knowledge limits, finance-boundary notes, procurement-boundary notes, provider-neutrality notes, sponsor non-control notes, correction path, renewal status, and dependency links where material.

9.20.6(f) A Regional Cluster Evidence Pack shall not describe a region as officially designated, publicly warned, certified, recognized, finance-ready, procurement-ready, investment-ready, provider-ready, sponsor-approved, deployment-approved, operationally cleared, or execution-ready by default.

9.20.6(g) Where a Regional Cluster Evidence Pack is corrected, restricted, superseded, withdrawn, retracted, or made stale by later evidence, GCRI Canada shall update affected regional public-safe summaries, dashboards, maps, public authority learning materials, GRF inputs, GRA inputs, Nexus Risk Management inputs, Nexus Rails inputs, National Nexus Consortium materials, National Company materials, Project SPV materials, provider-facing materials, sponsor-facing materials, host-facing materials, community-facing materials, dependency notices, renewal records, assurance records, and register entries as appropriate.

9.20.6(h) The controlling rule shall be that a Regional Cluster Evidence Pack organizes regional evidence for disciplined learning without creating regional authority, finance, procurement, recognition, certification, protocol effect, or execution.

***

9.20.7 National Dense Core Evidence Pack.\
9.20.7(a) GCRI Canada may steward National Dense Core Evidence Pack methods for organizing evidence concerning National Dense Nexus Core compute, observability, interoperability, continuity, sovereign compute, public authority data governance, national data governance, AI and model governance, cybersecurity, key management, dashboards, maps, APIs, national-scale public-safe summaries, finance-boundary evidence inputs, public authority learning, National Nexus Consortium interfaces, National Company interfaces, Project SPV interfaces, operator interfaces, host interfaces, provider interfaces, sponsor interfaces, community safeguards, correction, and assurance.

9.20.7(b) A National Dense Core Evidence Pack shall identify National Dense Nexus Core title or identifier, national purpose, national scope, jurisdictional context, regional relationships, Node relationships, Hub relationships, Cluster relationships, Hotspot relationships, sovereign compute relationships, public authority data relationships, National Nexus Consortium context, National Company context, Project SPV context, operator context where any, host context, provider context, sponsor context where any, community context, Indigenous or protected knowledge context where any, data classes, evidence classes, output classes, access class, handling class, public-safe status, permitted uses, prohibited uses, and correction path.

9.20.7(c) National Dense Core source components may include Regional Cluster Evidence Packs, Cluster Evidence Packs, Hub Evidence Packs, Node Evidence Packs, Hotspot Evidence Packs, sovereign compute records, compute workload records, compute environment records, public authority data records, national data governance records, model records, dataset records, system cards, benchmark cards, inference records, cybersecurity records, key management records, dashboards, maps, APIs, Proof Receipts, public-safe summaries, GRF interface records, GRA interface records, Protocol Authority interface records, Nexus Risk Management records, Nexus Rails records, National Nexus Consortium records, National Company records, Project SPV records, provider records, sponsor records where any, operator records, host records, community records, protected knowledge records where any, incident records, correction records, assurance records, and closeout records.

9.20.7(d) A National Dense Core Evidence Pack shall distinguish national evidence density from national authority. National-scale evidence, sovereign compute, national dashboards, national maps, public authority data, operator data, public authority participation, National Nexus Consortium relevance, National Company relevance, Project SPV relevance, GRA interface use, GRF interface use, Protocol Authority interface use, Nexus Rails interface use, provider participation, sponsor support, host participation, or capital-reader interest shall not create national public authority, public finance approval, procurement approval, certification, recognition, finance-readiness, protocol effect, operator instruction, infrastructure operation, deployment approval, or execution consequence by default.

9.20.7(e) National Dense Core Evidence Packs shall identify confidence, uncertainty, limitations, national data gaps, regional data gaps, sovereign compute status, compute-to-data status, cross-border status, public authority data controls, key management status, cybersecurity status, public-safe publication limits, community safeguard limits, protected knowledge limits, finance-boundary notes, procurement-boundary notes, provider-neutrality notes, sponsor non-control notes, operator-boundary notes, correction path, assurance status, and dependency links where material.

9.20.7(f) A National Dense Core Evidence Pack shall not describe a National Dense Nexus Core as national authority, official national program, public finance program, procurement program, investment zone, certified ecosystem, recognized ecosystem, protocol-effective ecosystem, provider market, sponsor territory, infrastructure operating system, telecommunications operating system, AI-RAN operating system, emergency-management structure, public warning system, market infrastructure, deployment approval mechanism, or execution authority by default.

9.20.7(g) Where a National Dense Core Evidence Pack is corrected, restricted, superseded, withdrawn, retracted, or made stale by later evidence, GCRI Canada shall update affected national public-safe summaries, dashboards, maps, APIs, public authority learning materials, GRF inputs, GRA inputs, Protocol Authority inputs, Nexus Risk Management inputs, Nexus Rails inputs, National Nexus Consortium materials, National Company materials, Project SPV materials, operator-facing materials, provider-facing materials, sponsor-facing materials, host-facing materials, community-facing materials, dependency notices, assurance records, and register entries as appropriate.

9.20.7(h) The controlling rule shall be that a National Dense Core Evidence Pack organizes national-scale evidence and compute records without making GCRI Canada the owner, operator, authority, financier, procurement actor, certifier, recognizer, or executor of national infrastructure.

***

9.20.8 Sensor, AI-RAN, DePIN, Cyber, Geospatial, Digital Twin, Dashboard, and Compute Evidence Pack Components.\
9.20.8(a) Observatory Evidence Packs may include sensor, AI-RAN, O-RAN, private wireless, DePIN, cyber telemetry, geospatial, Earth observation, digital twin, simulation, dashboard, visualization, sovereign compute, compute workload, model, dataset, system, benchmark, inference, proof receipt, public-safe output, incident, correction, and assurance components where such components are relevant to the recorded Evidence Pack purpose.

9.20.8(b) Sensor components shall identify sensor identity where safe, custody, calibration, configuration, maintenance, firmware or software status, timing, location or safe-location treatment, data quality, signal quality, reference sensor relationship where any, confidence, uncertainty, limitations, public-safe status, and correction path.

9.20.8(c) AI-RAN, O-RAN, private wireless, and telecommunications-adjacent components shall identify signal class, telemetry class, network context, edge intelligence context, timing, location treatment, calibration or signal-integrity status where applicable, privacy status, metadata sensitivity, cybersecurity status, public authority sensitivity, infrastructure sensitivity, provider role where any, operator role where any, confidence, uncertainty, limitations, public-safe status, and correction path.

9.20.8(d) DePIN components shall identify device identity where safe, hardware identity where material, location claim, uptime claim, availability claim, capacity claim, coverage claim, service claim, proof record, ledger relationship where any, token relationship where any, tamper risk, spoof risk, fraud risk, confidence, uncertainty, limitations, public-safe status, no-token-as-authority boundary, and correction path.

9.20.8(e) Cyber telemetry components shall identify log source, alert source, vulnerability signal, incident telemetry, cyber-sensitive classification, infrastructure-sensitive classification, source lineage, custody, timestamping, chain of handling, integrity status, disclosure limits, export-control or controlled-technology sensitivity where applicable, confidence, uncertainty, limitations, public-safe status, and correction path.

9.20.8(f) Geospatial and mapping components shall identify geospatial source, layer class, license, spatial resolution, temporal resolution, projection or coordinate reference system where material, safe-location treatment, sensitive-site treatment, infrastructure-sensitive treatment, community sensitivity, protected knowledge treatment, confidence, uncertainty, limitations, public-safe status, map version, and correction path.

9.20.8(g) Digital twin and simulation components shall identify model or system identity, source inputs, assumptions, calibration, validation, sensitivity, boundary conditions, scenario status, model version, compute workload, confidence, uncertainty, limitations, public-safe visualization status, false-precision controls, and correction path.

9.20.8(h) Dashboard and visualization components shall identify dashboard title or identifier, audience, classification, source records, update status, confidence display, uncertainty display, limitations, boundary language, access controls, export controls, misuse controls, version, change log, correction path, withdrawal path, and archive path.

9.20.8(i) Compute components shall identify compute workload, compute environment, sovereign compute status, compute-to-data treatment, secure enclave status where any, confidential computing status where any, air-gap or no-download status where any, location, jurisdiction, provider, custodian, access controls, logging, output records, cross-border status, cybersecurity status, and correction path.

9.20.8(j) Components under this section shall not create certification, recognition, finance-readiness, public authority decision, procurement approval, provider endorsement, sponsor approval, host approval, operator approval, rating, guarantee, public warning, emergency command, protocol effect, operational clearance, deployment approval, infrastructure operation, legal status, market authority, or execution consequence merely by being included in an Observatory Evidence Pack.

9.20.8(k) The controlling rule shall be that Evidence Pack components strengthen evidence only when each component retains its source, method, sensitivity, boundary, confidence, uncertainty, limitation, and correction record.

***

9.20.9 Public Authority, Host, Provider, Sponsor, Community, and Protected Knowledge Boundary Notes.\
9.20.9(a) Each material Observatory Evidence Pack shall include boundary notes addressing public authority, host, provider, sponsor, community, Indigenous, protected knowledge, operator, finance, procurement, recognition, certification, protocol, public warning, emergency command, public-safe, and execution boundaries where such boundaries are relevant to the Evidence Pack purpose, audience, sources, outputs, or downstream interfaces.

9.20.9(b) Public authority boundary notes shall identify public authority participation or reference, capacity classification, official or non-official status, data-sharing terms, agency reference controls, public authority restrictions, publication limits, non-delegation language, non-endorsement language, non-regulatory language, non-procurement language, non-funding language, no-public-finance language, no-public-warning language, no-emergency-command language, permitted use, prohibited use, and correction path.

9.20.9(c) Host boundary notes shall identify host role, facility or site context where safe and material, data contribution status, sensor contribution status, compute contribution status, connectivity contribution status, staff or context contribution status, safe-location treatment, host data rights, host restrictions, no-host-certification language, no-host-approval language, no-deployment-approval language, no-operational-clearance language, permitted use, prohibited use, and correction path.

9.20.9(d) Provider boundary notes shall identify provider role, provider-supplied data, tools, equipment, models, sensors, compute, dashboards, maps, APIs, configurations, benchmarks, validation conditions, commercial sensitivity, IP sensitivity, cybersecurity sensitivity, conflict status, influence controls, no-provider-endorsement language, no-procurement-preference language, no-security-certification language, no-protocol-effect language, no-finance-readiness language, permitted claims, prohibited claims, and correction path.

9.20.9(e) Sponsor boundary notes shall identify sponsor role, funding or support relationship, convening support, facilities support, technology access, data access, publication support, conflict status, sponsor non-control language, no-outcome-purchase language, no-evidence-control language, no-source-selection-control language, no-publication-control language, no-recognition-control language, no-finance-control language, no-protocol-control language, no-host-control language, permitted claims, prohibited claims, and correction path.

9.20.9(f) Community and Indigenous boundary notes shall identify affected or relevant communities, Indigenous protocols where applicable, community protocols, consent or non-consent treatment where applicable, territorial context, cultural context, environmental knowledge context, sensitive-site treatment, source protection, public-safe mapping limits, challenge pathways, withdrawal pathways where applicable, accessibility, translation, localization, non-extraction, non-commodification, do-no-harm controls, no-community-consent-by-implication language, and correction path.

9.20.9(g) Protected knowledge boundary notes shall identify protected knowledge presence or risk, permitted use, prohibited use, access restrictions, mapping restrictions, dashboard restrictions, AI-use restrictions, retrieval restrictions, embedding restrictions, training restrictions, publication restrictions, public-safe treatment, responsible non-disclosure basis where applicable, source protection, withdrawal or challenge path where applicable, and correction path.

9.20.9(h) Boundary notes shall state that participation, data contribution, review, attendance, comments, dashboard access, map access, public authority interest, host participation, provider participation, sponsor support, community participation, Indigenous participation, operator participation, National Company relevance, Project SPV relevance, GRF interface use, GRA interface use, Protocol Authority interface use, or public-safe summary inclusion shall not create endorsement, approval, consent, certification, recognition, procurement approval, finance-readiness, public authority decision, protocol effect, provider preference, sponsor validation, host approval, operator instruction, deployment approval, operational clearance, market signal, or execution consequence by implication.

9.20.9(i) The controlling rule shall be that an Evidence Pack must carry its boundary notes with the same discipline as its sources because evidence without boundary language is vulnerable to institutional overclaim.

***

9.20.10 Public-Safe Summary, Controlled Annex, Restricted Annex, Correction Path, and Re-Issue Protocol.\
9.20.10(a) GCRI Canada may structure Observatory Evidence Packs into public-safe summaries, controlled annexes, restricted annexes, technical annexes, public authority annexes, host annexes, provider annexes, sponsor-sensitive annexes where appropriate, community-sensitive annexes, protected knowledge annexes, cyber-sensitive annexes, finance-boundary annexes, procurement-boundary annexes, correction annexes, and re-issue records, provided that access, use, routing, publication, and correction are recorded.

9.20.10(b) Public-safe summaries shall present only those Evidence Pack elements that can be externally released without unsafe disclosure, public authority confusion, public warning implication, finance overclaim, procurement implication, certification implication, recognition implication, protocol implication, provider preference, sponsor validation, host approval implication, operator instruction implication, community harm, protected knowledge exposure, privacy harm, cybersecurity harm, sovereign data harm, infrastructure exposure, or execution implication.

9.20.10(c) Public-safe summaries shall identify, where material, source classes, method classes, evidence scope, confidence, uncertainty, limitations, public-safe omissions, responsible non-disclosure basis, stale-data treatment, contradiction status, data-gap status, correction status, supersession status, withdrawal status where applicable, permitted use, prohibited use, and boundary language.

9.20.10(d) Controlled annexes may include materials appropriate for specified controlled audiences, including public authority learners, GRF, GRA, Protocol Authority, Nexus Risk Management, Nexus Rails, National Nexus Consortiums, Regional Nexus Consortiums, National Companies, Project SPVs, hosts, operators, providers, sponsors, communities, universities, or other authorized interfaces, subject to access class, handling class, room rules, use limits, confidentiality, public-safe controls, and correction path.

9.20.10(e) Restricted annexes shall be used where materials include or may reveal personal information, rights-bearing data, health-sensitive information, cyber-sensitive information, infrastructure-sensitive information, public authority restricted information, sovereign-sensitive information, finance-sensitive information, commercially sensitive information, community-protected information, Indigenous or protected knowledge, confidential source information, privileged material, credentials, secrets, keys, tokens, controlled technology, exploit details, sensitive locations, unsafe geospatial precision, unsafe metadata, operator-sensitive information, or national-security-adjacent sensitive information.

9.20.10(f) Correction paths shall identify who may raise a correction, how correction requests are received, how evidence is reviewed, how confidence and uncertainty are revised, how limitations are updated, how public-safe status is reassessed, how boundary language is corrected, how affected dependencies are identified, how affected interfaces are notified where appropriate, and how prior versions are preserved, superseded, withdrawn, retracted, sealed, archived, or marked as no longer current.

9.20.10(g) Re-issue protocol shall require corrected source records, corrected method records, corrected evidence classification, corrected confidence, corrected uncertainty, corrected limitations, corrected public-safe status, corrected boundary language, corrected annex classification, corrected dependency notices where appropriate, corrected register entry, reviewer record, effective date, supersession relationship, and archive treatment of the prior version.

9.20.10(h) Where an Evidence Pack cannot be summarized publicly without distorting evidence, erasing uncertainty, concealing contradiction, exposing restricted data, exposing protected knowledge, creating public warning implication, creating official status implication, creating finance overclaim, creating procurement implication, creating provider preference, creating sponsor validation, creating host approval implication, creating community harm, or creating execution implication, GCRI Canada may use controlled annexes, restricted annexes, delayed release, aggregation, generalization, safe-location treatment, responsible non-disclosure, limited public-safe statement, or no-publication treatment.

9.20.10(i) The controlling rule shall be that Evidence Pack publication must be layered: what is safe to know publicly, what is safe to review under control, what must remain restricted, what must be corrected, and what must be re-issued must never be collapsed into a single uncontrolled artifact.

***

9.20.11 Observatory Evidence Packs as Non-Certifying, Non-Recognition, Non-Finance, Non-Public-Warning, and Non-Execution Artifacts.\
9.20.11(a) No Observatory Evidence Pack, Node Evidence Pack, Hub Evidence Pack, Cluster Evidence Pack, Hotspot Evidence Pack, Regional Cluster Evidence Pack, National Dense Core Evidence Pack, Evidence Pack component, public-safe summary, controlled annex, restricted annex, technical annex, correction annex, re-issue record, register entry, dashboard, map, API, public claim, Proof Receipt, or dependency notice shall create certification, recognition, finance-readiness, public warning, emergency command, public authority decision, regulatory determination, procurement approval, provider preference, sponsor approval, host approval, operator approval, protocol effect, operational clearance, infrastructure operation, legal status, market authority, deployment approval, or execution consequence by default.

9.20.11(b) Observatory Evidence Packs shall not issue or imply official guidance, regulatory determination, compliance determination, enforcement position, safe harbor, permit, license, procurement decision, vendor award, funding approval, public finance approval, public warning, emergency alert, evacuation instruction, emergency command, public safety directive, public health order, investment advice, lending decision, underwriting decision, insurance approval, rating, guarantee, certification, recognition, maturity record, claims approval, standing, registry status, public-facing legitimacy, conformance determination, Nexus-compatible status, provider ranking, sponsor finding, host approval, operator instruction, remediation approval, deployment authorization, operational clearance, or market signal.

9.20.11(c) Evidence Pack completeness, evidence density, dashboard visibility, map visibility, benchmark success, public authority interest, host participation, operator participation, provider participation, sponsor support, community participation, Indigenous participation, National Company relevance, Project SPV relevance, Proof Receipt issuance, GRF interface use, GRA interface use, Protocol Authority interface use, Nexus Risk Management use, Nexus Rails use, Academy use, media interest, or public-safe publication shall not convert an Observatory Evidence Pack into authority.

9.20.11(d) Any certification, recognition, maturity record, claims approval, standing, registry status, finance-readiness, capital-readiness, insurance-readiness, public authority decision, procurement decision, protocol effect, operational decision, deployment decision, investment decision, lending decision, underwriting decision, public finance decision, host decision, operator decision, provider decision, sponsor decision, National Company decision, Project SPV decision, community decision, or execution action shall arise only through the competent actor’s own lawful authority, process, records, accountability, liability, and governance instruments, not through an Observatory Evidence Pack by implication.

9.20.11(e) Observatory Evidence Packs shall include boundary language where material to prevent interpretation as public authority action, public warning, emergency command, regulatory determination, procurement action, finance-readiness, public finance approval, certification, recognition, maturity, claims approval, protocol effect, provider preference, sponsor approval, host approval, operator approval, operational clearance, infrastructure operation, legal status, professional advice, market signal, deployment approval, remediation approval, or execution instruction.

9.20.11(f) Where Observatory Evidence Packs are misused to imply unauthorized authority, GCRI Canada shall correct, relabel, restrict, withdraw, reissue, request removal of misleading references, notify affected interfaces where appropriate, suspend affected interface use, or pursue contractual or legal remedies where appropriate.

9.20.11(g) No ambiguity shall be resolved in favour of Evidence Pack authority. Where there is doubt whether an Observatory Evidence Pack creates authority or only supports evidence, the interpretation preserving GCRI Canada’s non-execution role, public authority boundaries, finance boundaries, procurement neutrality, provider neutrality, sponsor non-control, host boundaries, operator boundaries, community safeguards, Indigenous safeguards, Protocol Authority role separation, GRF role separation, GRA role separation, validity-by-record, correctionability, and public trust shall prevail.

9.20.11(h) The controlling rule shall be that Observatory Evidence Packs may be highly structured, detailed, and influential as evidence, but they do not certify, recognize, finance, warn, command, regulate, procure, approve, operate, deploy, or execute.

***

9.20.12 Observatory Evidence Pack Register.\
9.20.12(a) GCRI Canada shall maintain, or cause to be maintained, an Observatory Evidence Pack Register for material Observatory Evidence Packs, including Node Evidence Packs, Hub Evidence Packs, Cluster Evidence Packs, Hotspot Evidence Packs, Regional Cluster Evidence Packs, National Dense Core Evidence Packs, component-specific Evidence Packs, public-safe summaries, controlled annexes, restricted annexes, correction annexes, supersession records, withdrawal records, retraction records, re-issue records, dependency notices, assurance records, renewal records, archive records, and closeout records.

9.20.12(b) The Observatory Evidence Pack Register shall identify Evidence Pack title or identifier, Evidence Pack class, purpose, scope, related Node, Hub, Cluster, Hotspot, Regional Observatory Cluster, National Dense Nexus Core, host, operator, provider, sponsor, public authority, community, Indigenous or protected knowledge context, GRF interface, GRA interface, Protocol Authority interface, Nexus Risk Management interface, Nexus Rails interface, National Nexus Consortium interface, Regional Nexus Consortium interface, National Company interface, Project SPV interface, technology domain, risk domain, data class, evidence class, output class, audience class, access class, handling class, public-safe status, privacy status, cybersecurity status, sovereign data status, infrastructure-sensitive status, public authority status, finance-sensitive status, provider-sensitive status, sponsor-sensitive status, host-sensitive status, operator-sensitive status, community-protected status, Indigenous or protected knowledge status, legal sensitivity, license status, export-control sensitivity, sanctions sensitivity, controlled-technology sensitivity, permitted uses, prohibited uses, publication limits, correction path, and register status.

9.20.12(c) Register entries shall identify version, release status, public-safe summary status, controlled annex status, restricted annex status, source record status, method record status, compute record status, model record status where any, dataset record status where any, dashboard record status where any, map record status where any, API record status where any, confidence status, uncertainty status, limitation status, contradiction status, data-gap status, boundary-language status, review status, assurance status, correction status, supersession status, withdrawal status where applicable, retraction status where applicable, re-issue status, archive status, and closeout status.

9.20.12(d) Register interface logs shall identify sending interface, receiving interface, date, purpose, capacity of recipient, materials shared, materials received, version, access class, handling class, public-safe status, finance-safe status where applicable, procurement-safe status where applicable, recognition-boundary status where applicable, certification-boundary status where applicable, protocol-boundary status where applicable, public authority boundary status where applicable, provider-neutrality status, sponsor non-control status, host-boundary status, operator-boundary status, community-safeguard status, protected-knowledge status, permitted use, prohibited use, boundary language, correction path, dependency path, notice path, and closeout path.

9.20.12(e) Correction register entries shall identify corrected source, corrected Evidence Pack, corrected component, corrected annex, corrected public-safe summary, corrected confidence, corrected uncertainty, corrected limitation, corrected dashboard, corrected map, corrected API, corrected public authority reference, corrected provider reference, corrected sponsor reference, corrected host reference, corrected operator reference, corrected community reference, corrected protected knowledge treatment, corrected boundary language, prior status, corrected status, effective date, reviewer, affected dependencies, notice decision, access change, archive treatment, and continuing limitations.

9.20.12(f) Supersession, withdrawal, or retraction register entries shall identify replacement Evidence Pack where any, changed evidence base, changed source status, changed method status, changed compute status, changed model status, changed public-safe status, changed annex status, changed boundary language, continuing validity where any, discontinued reliance where any, reason for supersession, withdrawal, or retraction, affected dependencies, notice decision, and archive treatment.

9.20.12(g) The Observatory Evidence Pack Register shall link Evidence Packs, where applicable, to National Dense Core records, Regional Observatory Cluster records, Cluster records, Hub records, Node records, Hotspot records, host readiness records, maturity evidence records, AI-RAN records, DePIN records, sensor records, geospatial records, cyber telemetry records, digital twin records, dashboard records, degraded-mode records, sovereign compute records, Observatory Methods Register entries, Evidence Register entries, Source Comparison Records, Dataset Register entries, Model Register entries, System Card entries, Benchmark Card entries, Compute Workload Records, Compute Environment Records, Inference Records, Human Review Records, Retrieval and Embedding Records, Proof Receipt Records, Public-Safe Output Records, AI Incident Records, Correction Records, Dependency Records, Truth Engine Records, Nexus Risk Management records, public authority records, GRF interface records, GRA interface records, Protocol Authority interface records, RNFD records, Nexus Rails records, Regional Nexus Consortium records, National Nexus Consortium records, National Company records, Project SPV records, operator records, provider records, sponsor records, host records, community records, university records, Nexus interface records, and public claims records.

9.20.12(h) Register access shall be governed by access class, handling class, public-safe status, privacy status, cybersecurity status, sovereign data status, protected knowledge status, public authority status, finance-sensitive status, provider-sensitive status, sponsor-sensitive status, host-sensitive status, operator-sensitive status, community-protected status, legal sensitivity, export-control sensitivity, sanctions sensitivity, controlled-technology sensitivity, and publication limits.

9.20.12(i) Observatory Evidence Pack Register entries, interface logs, review records, correction records, supersession records, withdrawal records, retraction records, re-issue records, archive records, notices, assurance, renewal, and closeout shall not create certification, recognition, finance-readiness, public authority decision, regulatory finding, procurement approval, provider endorsement, sponsor approval, host approval, operator approval, community consent, rating, guarantee, public warning, emergency command, protocol effect, operational clearance, legal status, market authority, infrastructure operation, remediation approval, deployment approval, national authority, regional authority, public-facing maturity record, GRF maturity record, GRA finance-readiness, or execution consequence by default.

9.20.12(j) The controlling rule shall be that the Observatory Evidence Pack Register is the institutional memory of what evidence was packed, for what purpose, under what boundaries, shared with whom, corrected when, superseded how, and no longer relied upon why.

### 9.21 Observatory Public Authority Interfaces

9.21.1 Public Authority Learning Interface for Observatory Systems.\
9.21.1(a) GCRI Canada may steward public authority learning interface methods for Observatory systems as structured, evidence-supporting, non-delegated, non-executing, public-safe, source-lined, confidence-aware, uncertainty-aware, limitation-aware, and correctionable methods through which public authorities may receive, review, question, contextualize, or learn from Observatory evidence, Observatory Evidence Packs, dashboards, maps, public-safe summaries, controlled annexes, technical notes, Academy materials, degraded-mode evidence, host readiness evidence, regional evidence, National Dense Core evidence, and related Observatory outputs.

9.21.1(b) Public authority learning interfaces may support public authority understanding of evidence methods, source comparison, observability methods, data governance, public-safe publication, regional hazards, degraded-mode conditions, infrastructure dependencies, cyber-physical evidence, sensor evidence, geospatial evidence, AI-RAN evidence, DePIN evidence, digital twin outputs, dashboards, host readiness, community safeguards, protected knowledge safeguards, sovereign compute, public-good software, technical baselines, correction discipline, and Nexus role separation.

9.21.1(c) A public authority learning interface shall be treated as a learning, evidence, literacy, review, and correction interface only. It shall not constitute delegation of public authority, official advice, official guidance, regulatory determination, compliance determination, enforcement position, public warning, emergency command, public safety directive, public health order, procurement approval, funding approval, public finance approval, certification, recognition, finance-readiness, protocol effect, provider preference, sponsor approval, host approval, operator instruction, operational clearance, deployment approval, infrastructure operation, legal status, market authority, or execution consequence by default.

9.21.1(d) GCRI Canada may provide public authority learning interfaces through controlled rooms, public authority rooms, data rooms, clean rooms, no-download rooms, secure briefings, public-safe briefings, dashboards, maps, APIs, technical notes, Evidence Packs, Decision Packs, public-safe summaries, controlled annexes, restricted annexes, training sessions, Academy materials, repository materials, and correction notices, provided that each such interface is classified, access-controlled, boundary-valid, public-safe where externally released, and correctionable.

9.21.1(e) GCRI Canada’s stewardship of a public authority learning interface shall not make GCRI Canada a public authority, regulator, delegate, agent of the Crown or state, emergency-management actor, public warning issuer, public infrastructure operator, public health actor, law enforcement body, procurement actor, public finance actor, certification body, recognition body, Protocol Authority, provider, sponsor, host, operator, National Company, Project SPV, market actor, or execution actor by default.

9.21.1(f) Public authority learning interface methods shall preserve legal separateness and role separation among GCRI Canada, GCRI US, The Global Risks Forum (GRF), The Global Risks Alliance (GRA), Nexus Standards / Protocol Authority, Nexus entities, Regional Nexus Consortiums, National Nexus Consortiums, National Companies, Project SPVs, public authorities, operators, providers, sponsors, hosts, universities, communities, Indigenous governance bodies where applicable, and other actors.

9.21.1(g) Where public authority learning materials are used externally or publicly, GCRI Canada shall preserve controlled vocabulary, source lineage, public authority capacity classification, confidence, uncertainty, limitations, public-safe status, non-delegation language, non-endorsement language, no-official-guidance language, no-regulatory-determination language, no-procurement language, no-funding language, no-public-finance language, no-public-warning language, no-emergency-command language, no-certification language, no-recognition language, no-finance-readiness language, no-protocol-effect language unless separately created by Protocol Authority, no-provider-endorsement language, no-sponsor-approval language, no-host-approval language, no-operator-instruction language, no-execution language, and correction path.

9.21.1(h) The controlling rule shall be that public authorities may learn from Observatory evidence, but public authority remains with public authorities and is not delegated to, exercised by, or implied through GCRI Canada.

***

9.21.2 Public Authority Capacity Classification for Observatory Participation.\
9.21.2(a) GCRI Canada shall classify the capacity in which any public authority, public official, public employee, public agency, regulator, public finance body, emergency-management body, public health body, public safety body, public infrastructure operator, Crown entity, state-owned entity, municipal body, provincial body, territorial body, federal body, Indigenous public governance body where applicable, foreign public authority, intergovernmental body, or public-sector participant participates in an Observatory interface.

9.21.2(b) Public authority capacity classification shall identify whether participation is official, non-official, observer, regulator-listening, public finance reader, emergency-management learner, public infrastructure operator learner, public health learner, public safety learner, technical staff participation, policy staff participation, research participation, procurement-adjacent participation, funding-adjacent participation, public finance-adjacent participation, data contributor, reviewer, controlled-room participant, public-safe summary recipient, Academy participant, speaker, attendee, sponsor-adjacent participant, host-adjacent participant, or other recorded capacity.

9.21.2(c) Capacity classification records shall identify public authority name, office or function where appropriate, jurisdiction, participant role, participant authority where known, official or non-official status, authority to provide data where applicable, authority to approve public references where applicable, authority to receive restricted materials where applicable, authority to review public-safe materials where applicable, attendance basis, data-sharing basis, confidentiality basis, access class, handling class, public-safe status, permitted use, prohibited use, publication limits, reference limits, and correction path.

9.21.2(d) Where capacity is unclear, mixed, contested, informal, exploratory, educational, regulator-listening, procurement-adjacent, funding-adjacent, emergency-management-adjacent, public-finance-adjacent, or otherwise vulnerable to overclaim, GCRI Canada shall classify the participation in the narrower, safer, non-delegated, non-endorsement, non-official, non-procurement, non-funding, non-public-finance, non-public-warning, non-emergency-command, and correctionable manner unless a competent public authority provides express recorded clarification.

9.21.2(e) Public authority capacity classification shall not be inferred from seniority, title, agency name, attendance, email domain, meeting participation, data contribution, dashboard access, review comments, public event presence, logo placement, public quote, photograph, presentation listing, funder listing, procurement context, or media reference unless the authority and permitted use are recorded.

9.21.2(f) Public authority participation shall not imply endorsement, adoption, approval, delegation, official guidance, regulatory determination, compliance determination, enforcement position, procurement relevance, funding relevance, public finance approval, public warning, emergency command, public-law status, certification, recognition, finance-readiness, provider preference, sponsor approval, host approval, operator instruction, deployment approval, or execution consequence by default.

9.21.2(g) Where capacity classification is incorrect, incomplete, stale, overclaimed, public-facing, public authority-confusing, procurement-implying, funding-implying, public-finance-implying, public-warning-implying, emergency-command-implying, or correction-defective, GCRI Canada shall correct, restrict, relabel, withdraw, reissue, notify affected interfaces where appropriate, and review affected dependencies.

9.21.2(h) The controlling rule shall be that no public authority meaning may be implied from participation without a recorded capacity, recorded authority, recorded permitted use, and recorded boundary.

***

9.21.3 Public Authority Data Contribution Records.\
9.21.3(a) GCRI Canada shall maintain public authority data contribution records for any material data, documents, records, telemetry, maps, dashboards, geospatial layers, sensor records, cyber telemetry, infrastructure records, public health context, public safety context, public finance context, procurement context, emergency-management context, public authority comments, technical inputs, review notes, or other materials received from, through, at the request of, or in relation to a public authority for Observatory purposes.

9.21.3(b) Public authority data contribution records shall identify contributing authority, contributing office or function where appropriate, contributor capacity, official or non-official status, data source, source authority, source permission, lawful basis where applicable, data-sharing terms, confidentiality status, classification, data class, evidence class, output class, access class, handling class, public-safe status, privacy status, cybersecurity status, sovereign data status, infrastructure-sensitive status, health-sensitive status, public safety sensitivity, public finance sensitivity, procurement sensitivity, legal sensitivity, export-control sensitivity, sanctions sensitivity, controlled-technology sensitivity, retention status, deletion status, sealing status, archive status, permitted use, prohibited use, publication limits, and correction path.

9.21.3(c) Public authority data contribution records shall identify whether materials may be used for internal evidence review, controlled-room review, public authority learning, GRF input support, GRA input support, Protocol Authority input support, Nexus Risk Management inputs, Nexus Rails inputs, public-safe summaries, dashboards, maps, APIs, Academy materials, provider-facing materials, sponsor-facing materials, host-facing materials, community-facing materials, media materials, repository materials, or public claims.

9.21.3(d) Public authority data shall not be used, routed, embedded, retrieved, trained on, vendor-processed, public-AI-processed, dashboarded, mapped, API-exposed, shared with providers, shared with sponsors, routed to finance-facing contexts, routed to procurement-facing contexts, or published without review proportionate to data-sharing terms, public authority restrictions, privacy, cybersecurity, sovereign data, infrastructure sensitivity, public-safe status, legal restrictions, and correctionability.

9.21.3(e) Public authority data contribution shall not imply that the public authority endorses the Observatory method, approves the output, adopts the evidence, delegates authority, authorizes public warning, supports procurement, supports finance-readiness, certifies a provider, recognizes a host, approves a project, or assumes responsibility for GCRI Canada outputs unless expressly recorded by the competent public authority.

9.21.3(f) Where public authority data are corrected, restricted, withdrawn, superseded, reclassified, made stale, or found to have been contributed without authority or beyond permitted use, GCRI Canada shall update affected datasets, Evidence Packs, Decision Packs, dashboards, maps, APIs, public-safe summaries, interface records, dependency notices, and register entries as appropriate.

9.21.3(g) Where public authority data contribution creates public authority confusion, confidentiality risk, privacy risk, cybersecurity risk, sovereign data risk, procurement implication, public finance implication, public warning implication, provider preference, sponsor validation, host approval implication, operator instruction implication, community harm, or public-safe defect, GCRI Canada shall restrict, reclassify, correct, withdraw, refuse use, or seek clarification as appropriate.

9.21.3(h) The controlling rule shall be that public authority data may support Observatory evidence only within the authority, permissions, classifications, limits, and corrections attached to that data.

***

9.21.4 Public Authority Dashboard Access Controls.\
9.21.4(a) GCRI Canada shall apply public authority dashboard access controls to dashboards, maps, APIs, portals, data rooms, clean rooms, public authority rooms, controlled rooms, no-download rooms, public-safe summaries, controlled annexes, restricted annexes, Evidence Packs, Decision Packs, technical notes, and visualization systems made available to public authority participants.

9.21.4(b) Public authority dashboard access records shall identify dashboard title or identifier, participant public authority, participant capacity, authorized users, authorized roles, access purpose, access duration, access class, handling class, public-safe status, controlled status, restricted status, data classes, evidence classes, output classes, download rights, export rights, screenshot rights, API rights, redistribution rights, citation rights, publication rights, review rights, correction rights, and revocation path.

9.21.4(c) Access controls shall include, where appropriate, identity verification, role-based access, least privilege, time-bounded access, logging, monitoring, confidentiality obligations, no-download rules, screenshot restrictions, export restrictions, API restrictions, copy restrictions, citation rules, redistribution limits, room rules, public-safe notes, boundary language, and correction links.

9.21.4(d) Public authority dashboard access shall not imply public authority endorsement, adoption, approval, delegation, official guidance, regulatory determination, procurement relevance, funding relevance, public finance approval, public warning, emergency command, public-law status, certification, recognition, finance-readiness, provider preference, sponsor approval, host approval, operator instruction, operational clearance, deployment approval, or execution consequence.

9.21.4(e) Dashboard labels, legends, colours, markers, alerts, status indicators, titles, agency references, jurisdiction references, public authority filters, and export options shall be reviewed to prevent public warning implication, emergency-command implication, official-status implication, public authority implication, regulatory implication, procurement implication, funding implication, public-finance implication, or public-law implication.

9.21.4(f) Public authority users shall be provided, where material, with permitted-use notes, prohibited-use notes, non-delegation language, non-endorsement language, no-public-warning language, no-emergency-command language, no-regulatory-determination language, no-procurement language, no-funding language, no-public-finance language, confidence notes, uncertainty notes, limitation notes, stale-data notes, correction notices, and dependency notices.

9.21.4(g) Where public authority dashboard access is misused, over-shared, screenshot, exported, embedded, misquoted, misread, treated as official, treated as a warning, treated as regulatory, treated as procurement-relevant, treated as finance-relevant, or otherwise used outside permitted limits, GCRI Canada shall restrict access, revoke access, correct records, issue clarification, notify affected interfaces where appropriate, and review affected dependencies.

9.21.4(h) The controlling rule shall be that public authority dashboard access is access to bounded evidence, not access to delegated authority or official decision infrastructure.

***

9.21.5 Public Authority Review of Public-Safe Observatory Outputs Where Required.\
9.21.5(a) GCRI Canada shall require public authority review, consultation, notice, or reference clearance where public-safe Observatory outputs materially involve public authority data, public authority restricted materials, agency names, official titles, jurisdictional claims, regulator-listening contexts, emergency-management contexts, public health contexts, public safety contexts, public finance contexts, procurement contexts, public infrastructure operator contexts, or other materials likely to be misread as public authority status.

9.21.5(b) Public authority review shall identify the reviewing authority, reviewing office or function where appropriate, reviewer capacity, review scope, materials reviewed, data-sharing terms, publication limits, permitted references, prohibited references, agency name treatment, logo treatment, title treatment, quote treatment, attendance treatment, photograph treatment, data contribution treatment, jurisdictional reference treatment, public-safe status, and correction path.

9.21.5(c) Public authority review may address factual accuracy of public authority references, confidentiality, public authority data restrictions, public-safe publication, public warning risk, emergency-command risk, public-law implication, regulatory implication, procurement implication, funding implication, public finance implication, public health implication, public safety implication, and agency reference controls.

9.21.5(d) Public authority review shall not by itself create endorsement, adoption, approval, delegation, official guidance, regulatory determination, public warning, emergency command, procurement approval, funding approval, public finance approval, certification, recognition, finance-readiness, provider preference, sponsor approval, host approval, operator instruction, deployment approval, or execution consequence unless the competent public authority separately creates such meaning through its own lawful record.

9.21.5(e) Where public authority review is required but cannot be completed safely, lawfully, timely, or without compromising public authority restrictions, privacy, cybersecurity, sovereign data, protected knowledge, public-safe discipline, or correctionability, GCRI Canada may restrict use, remove public authority references, generalize the output, delay release, use controlled annexes, provide limited public-safe statements, or refuse publication.

9.21.5(f) Public authority comments, edits, silence, delay, non-objection, attendance, data contribution, dashboard access, or review participation shall not be treated as approval or endorsement unless expressly recorded by a competent public authority with permitted-use language.

9.21.5(g) Where public-safe Observatory outputs are corrected, restricted, superseded, withdrawn, retracted, or materially reclassified after public authority review, GCRI Canada shall provide public authority correction notice or controlled notice where appropriate and update affected references, records, dashboards, maps, Evidence Packs, Decision Packs, public-safe summaries, and interface logs.

9.21.5(h) The controlling rule shall be that public authority review may protect accuracy and public-safe meaning, but review is not approval unless the public authority separately and lawfully says so.

***

9.21.6 Public Authority Reference Approval for Names, Logos, Titles, Agency Names, Jurisdictions, Photos, Quotes, Attendance, and Data Contributions.\
9.21.6(a) GCRI Canada shall maintain public authority reference approval methods for any use of public authority names, agency names, department names, ministry names, regulator names, public finance body names, emergency-management body names, public health body names, public safety body names, public infrastructure operator names, official titles, jurisdictions, logos, seals, marks, photographs, quotes, attendance references, data contribution references, meeting references, dashboard access references, review references, or other public authority-identifying references in Observatory materials.

9.21.6(b) Reference approval records shall identify the public authority reference, intended use, audience, publication channel, output class, public-safe status, reviewing or approving public authority contact where appropriate, authority of reviewer where known, permitted language, prohibited language, permitted logo or mark use where any, prohibited logo or mark use, permitted title use, prohibited title use, permitted quote use, prohibited quote use, permitted photograph use, permitted attendance reference, permitted data contribution reference, jurisdictional reference limits, expiration or review date where any, and correction path.

9.21.6(c) GCRI Canada shall not use public authority logos, seals, official marks, official titles, agency names, photographs, quotations, attendance references, data contribution references, or jurisdictional references in a manner that implies endorsement, adoption, approval, delegation, official guidance, regulatory determination, procurement approval, funding approval, public finance approval, public warning, emergency command, public-law status, certification, recognition, finance-readiness, provider preference, sponsor approval, host approval, operator instruction, deployment approval, market authority, or execution consequence unless expressly authorized by the competent public authority and consistent with GCRI Canada’s non-executing role.

9.21.6(d) Public authority names and references may be generalized, anonymized, aggregated, described by capacity, or omitted where specific reference would create public authority confusion, confidentiality risk, public-safe risk, procurement implication, funding implication, public finance implication, public warning implication, emergency-command implication, regulatory implication, political sensitivity, community harm, or other inappropriate reliance.

9.21.6(e) Attendance references shall distinguish invited, registered, attended, observed, spoke, reviewed, contributed data, co-hosted, sponsored, funded, approved, endorsed, or adopted status, and shall not collapse such categories into a misleading public authority association.

9.21.6(f) Quotes and photographs shall not be used without recorded authority, scope, context, permitted wording, public-safe review, and withdrawal or correction path. A quote or photograph shall not imply institutional endorsement beyond the recorded permitted use.

9.21.6(g) Where public authority reference approval is missing, stale, exceeded, contested, withdrawn, misquoted, mistranslated, visually misleading, or public-safe defective, GCRI Canada shall remove, correct, restrict, relabel, withdraw, reissue, or seek renewed approval as appropriate.

9.21.6(h) The controlling rule shall be that public authority names, logos, titles, photos, quotes, attendance, and data references carry public meaning and must not be used as implied authority.

***

9.21.7 Regulator-Listening, Public Finance Reader, Emergency-Management, Public Infrastructure Operator, Public Health, and Public Safety Participant Status.\
9.21.7(a) GCRI Canada shall classify and record regulator-listening, public finance reader, emergency-management, public infrastructure operator, public health, public safety, public procurement, public funding, public policy, public technical, and other public-sector participant status in Observatory interfaces where such status is material to public meaning, access control, public-safe review, boundary language, or downstream reliance.

9.21.7(b) Regulator-listening status shall indicate that a regulator, regulator-adjacent office, or regulatory staff member is participating for learning, observation, technical understanding, consultation, or evidence literacy only, and not as regulatory approval, compliance determination, enforcement position, safe harbor, official guidance, certification, procurement approval, provider preference, finance-readiness, public warning, emergency command, or public-law status by default.

9.21.7(c) Public finance reader status shall indicate that a public finance body, infrastructure bank, development finance body, grant-making body, funding program, treasury-related body, or finance-adjacent public office is participating for evidence literacy, public-safe understanding, resilience learning, or capital-reader learning only, and not as public finance approval, funding approval, investment advice, rating, guarantee, bankability, fundability, finance-readiness, procurement approval, project approval, or execution consequence by default.

9.21.7(d) Emergency-management participant status shall indicate that emergency-management actors are participating for learning, preparedness understanding, degraded-mode learning, evidence literacy, or public-safe review only, and not as emergency command, incident command, evacuation instruction, public warning, public safety directive, public health order, operational instruction, public authority decision, or delegation to GCRI Canada by default.

9.21.7(e) Public infrastructure operator status shall indicate that public or public-sector infrastructure operators are participating as operators of their own systems, contributors of operator context, or recipients of evidence-learning materials, and not as transferring operation, assigning command, creating service assurance, approving remediation, approving procurement, creating certification, creating finance-readiness, or making GCRI Canada an operator by default.

9.21.7(f) Public health and public safety participant status shall indicate that public health or public safety actors are participating for learning, context, public-safe review, evidence literacy, or safeguards only, and not as public health order, public safety directive, public warning, clinical guidance, safety certification, emergency command, official public communication, or public authority delegation by default.

9.21.7(g) Participant status records under this section shall identify permitted use, prohibited use, access class, handling class, public-safe status, public authority boundary language, reference approval requirements, correction path, and dependency links.

9.21.7(h) Where participant status is misrepresented, overclaimed, publicly misread, used for procurement, used for finance, used for provider endorsement, used for sponsor validation, used for public warning, used for regulatory implication, used for emergency-command implication, or used as public authority approval, GCRI Canada shall correct, relabel, restrict, withdraw, reissue, request removal of misleading references, notify affected public authority interfaces where appropriate, and review dependencies.

9.21.7(i) The controlling rule shall be that public-sector participant status must be named precisely because “public authority present” is not the same as “public authority approved.”

***

9.21.8 No Public Authority Delegation Through Observatory Interface.\
9.21.8(a) No Observatory public authority interface, public authority learning room, controlled room, public authority dashboard, public authority map, API access, Evidence Pack, Decision Pack, technical note, public-safe summary, controlled annex, restricted annex, public authority review, public authority data contribution, public authority reference, public authority attendance, public authority comment, public authority quote, public authority logo use, regulator-listening presence, public finance reader presence, emergency-management participant status, public infrastructure operator participation, public health participation, public safety participation, or public authority-facing correction notice shall delegate public authority to GCRI Canada by default.

9.21.8(b) GCRI Canada shall not accept, imply, exercise, or market delegated public authority through an Observatory interface unless a lawful delegation is expressly made by a competent public authority under applicable law, accepted through proper institutional authorization, recorded in a governing instrument, bounded by safeguards, and consistent with GCRI Canada’s constitutional non-execution role. No ordinary Observatory interface shall be interpreted as such delegation.

9.21.8(c) Public authority interfaces shall not authorize GCRI Canada to issue official guidance, make regulatory determinations, make compliance determinations, take enforcement positions, issue public warnings, command emergency response, direct public infrastructure operations, direct operators, approve procurement, approve public finance, award funding, certify safety, certify security, approve providers, approve hosts, approve projects, approve deployment, determine legal compliance, or create public-law consequences by default.

9.21.8(d) Public authority participation, contribution, review, attendance, silence, non-objection, comments, edits, data sharing, dashboard access, map access, funding support, procurement interest, regulatory interest, emergency-management interest, public finance interest, public health interest, public safety interest, or public infrastructure interest shall not be construed as delegation.

9.21.8(e) Any public authority decision, public authority warning, public authority order, regulatory action, procurement action, funding action, public finance action, emergency-management action, public health action, public safety action, public infrastructure action, or official communication shall arise only from the public authority’s own lawful authority, process, records, accountability, and liability.

9.21.8(f) Where any Observatory interface is described, used, or misunderstood as a public authority delegation, GCRI Canada shall correct, relabel, restrict, withdraw, reissue, seek public authority clarification where appropriate, notify affected interfaces where appropriate, suspend affected use, or pursue contractual or legal remedies where appropriate.

9.21.8(g) No ambiguity shall be resolved in favour of public authority delegation. Where there is doubt, the interpretation preserving GCRI Canada’s non-execution role, non-delegation discipline, public authority boundaries, public warning boundaries, emergency-command boundaries, procurement boundaries, public finance boundaries, provider neutrality, sponsor non-control, host boundaries, operator boundaries, community safeguards, Protocol Authority role separation, GRF role separation, GRA role separation, validity-by-record, correctionability, and public trust shall prevail.

9.21.8(h) The controlling rule shall be that public authorities may interface with Observatory systems, but they do not delegate public power to GCRI Canada through that interface.

***

9.21.9 No Official Public Warning Through Observatory Interface by GCRI Canada.\
9.21.9(a) No Observatory public authority interface, degraded-mode interface, regional hazard interface, dashboard, map, API, Evidence Pack, Decision Pack, technical note, public-safe summary, controlled annex, restricted annex, public authority learning material, public authority review, public authority comment, public authority attendance, emergency-management participant status, public safety participant status, public health participant status, or public-facing Observatory output shall create an official public warning, emergency alert, evacuation instruction, public safety directive, public health order, emergency command, incident command, official hazard designation, official risk designation, or official public authority communication by GCRI Canada by default.

9.21.9(b) GCRI Canada shall not issue public warnings, emergency alerts, evacuation instructions, public safety directives, public health orders, emergency commands, incident commands, official hazard designations, or official public authority communications through Observatory systems unless a competent public authority separately issues such communication through its own lawful process and record, and GCRI Canada’s role, if any, is separately recorded and bounded.

9.21.9(c) Public-facing Observatory materials shall avoid warning-like language, alert-like visual grammar, emergency colours, evacuation symbols, official seals, agency marks, urgent imperatives, operational commands, public safety instructions, public health instructions, official hazard banners, or official public authority formatting unless separately authorized by a competent public authority and proper record.

9.21.9(d) Degraded-mode evidence, hazard evidence, sensor evidence, AI-RAN evidence, DePIN evidence, cyber telemetry, geospatial layers, digital twin scenarios, dashboards, maps, confidence indicators, risk indicators, continuity indicators, incident-adjacent summaries, or public-safe summaries shall not be framed as public warnings or emergency commands by GCRI Canada.

9.21.9(e) Public authority attendance, emergency-management participation, public safety participation, public health participation, regulator-listening status, dashboard access, map access, data contribution, review comments, or public-safe review shall not convert GCRI Canada Observatory outputs into public warnings or official communications.

9.21.9(f) Where public warning implication is detected, GCRI Canada shall revise labels, colours, symbols, legends, titles, captions, banners, release notes, boundary language, access controls, public-safe summaries, public authority references, public-facing communications, dashboards, maps, APIs, Evidence Packs, Decision Packs, and Academy materials, or shall restrict, withdraw, reissue, or refuse the output as appropriate.

9.21.9(g) Where public-facing misuse creates apparent warning status, GCRI Canada may issue public-safe clarification, controlled clarification, public authority notice, interface notice, correction notice, removal request, relabeling request, or legal notice as appropriate, while ensuring the clarification itself does not become a public warning.

9.21.9(h) The controlling rule shall be that GCRI Canada may support evidence learning relevant to public warnings, but it does not issue public warnings through Observatory interfaces.

***

9.21.10 Public Authority Interface Records, Corrections, and Clarifications.\
9.21.10(a) GCRI Canada shall maintain, or cause to be maintained, public authority interface records for material Observatory interfaces involving public authorities, regulators, public finance readers, emergency-management participants, public infrastructure operators, public health participants, public safety participants, public procurement actors, public funding actors, public authority data contributors, public authority dashboard users, public authority reviewers, public authority references, public-safe outputs, controlled annexes, restricted annexes, correction notices, clarifications, dependency notices, assurance reviews, renewal, withdrawal, archive, and closeout events.

9.21.10(b) Public authority interface records shall identify interface title or identifier, participating public authority, public authority office or function where appropriate, jurisdiction, participant capacity, official or non-official status, regulator-listening status where applicable, public finance reader status where applicable, emergency-management status where applicable, public infrastructure operator status where applicable, public health status where applicable, public safety status where applicable, data contributor status where applicable, reviewer status where applicable, dashboard access status where applicable, map access status where applicable, reference approval status where applicable, data classes, evidence classes, output classes, audience class, access class, handling class, public-safe status, privacy status, cybersecurity status, sovereign data status, infrastructure-sensitive status, public authority restricted status, finance-sensitive status, procurement-sensitive status, legal sensitivity, export-control sensitivity, sanctions sensitivity, controlled-technology sensitivity, permitted uses, prohibited uses, publication limits, and correction path.

9.21.10(c) Review records shall identify review cycle, reviewers, public authority capacity review, data contribution review, dashboard access review, map access review, reference approval review, public-safe review, public warning review, emergency-command review, non-delegation review, regulatory-boundary review, procurement-boundary review, funding-boundary review, public-finance-boundary review, provider-neutrality review, sponsor non-control review, host-boundary review, operator-boundary review, community safeguard review, protected knowledge review, privacy review, cybersecurity review, sovereign data review, export-control review where applicable, sanctions review where applicable, controlled-technology review where applicable, and correction review.

9.21.10(d) Correction records shall identify corrected public authority capacity, corrected official or non-official status, corrected data contribution record, corrected dashboard access record, corrected map access record, corrected reference approval, corrected agency name, corrected logo treatment, corrected title, corrected quote, corrected photograph, corrected attendance reference, corrected jurisdiction reference, corrected public-safe output, corrected controlled annex, corrected restricted annex, corrected boundary language, corrected public warning treatment, corrected emergency-command treatment, corrected procurement treatment, corrected funding treatment, corrected public finance treatment, corrected provider reference, corrected sponsor reference, corrected host reference, corrected operator reference, corrected community reference, prior status, corrected status, effective date, reviewer, affected dependencies, notice decision, access change, archive treatment, and continuing limitations.

9.21.10(e) Clarification records shall identify the statement or material clarified, reason for clarification, public-safe status, controlled status where applicable, public authority notice where applicable, affected audiences, affected interfaces, corrected boundary language, corrected permitted use, corrected prohibited use, whether the clarification is public-safe or controlled, whether it affects prior reliance, whether it triggers supersession, withdrawal, retraction, access restriction, or dependency notice, and continuing limitations.

9.21.10(f) Supersession, withdrawal, or retraction records shall be used where public authority interface materials should no longer be used or relied upon because of material error, unauthorized public authority reference, incorrect capacity classification, public authority confusion, public warning implication, emergency-command implication, regulatory overclaim, procurement implication, funding implication, public finance implication, unsupported official-status implication, privacy defect, cybersecurity defect, sovereign data issue, public-safe defect, protected knowledge exposure, community harm risk, provider-preferential framing, sponsor-validation framing, host approval implication, operator-control implication, legal defect, export-control issue, sanctions issue, controlled-technology issue, or correction failure.

9.21.10(g) Public authority interface records shall be linked, where applicable, to National Dense Core records, Regional Observatory Cluster records, Cluster records, Hub records, Node records, Hotspot records, host readiness records, maturity evidence records, Observatory Evidence Pack Register entries, AI-RAN records, DePIN records, sensor records, geospatial records, cyber telemetry records, digital twin records, dashboard records, degraded-mode records, sovereign compute records, Observatory Methods Register entries, Evidence Register entries, Source Comparison Records, Dataset Register entries, Model Register entries, System Card entries, Benchmark Card entries, Compute Workload Records, Compute Environment Records, Inference Records, Human Review Records, Retrieval and Embedding Records, Proof Receipt Records, Public-Safe Output Records, AI Incident Records, Correction Records, Dependency Records, Truth Engine Records, Nexus Risk Management records, GRF interface records, GRA interface records, Protocol Authority interface records, RNFD records, Nexus Rails records, Regional Nexus Consortium records, National Nexus Consortium records, National Company records, Project SPV records, operator records, provider records, sponsor records, host records, community records, university records, Nexus interface records, and public claims records.

9.21.10(h) Public authority interface records, review records, correction records, clarification records, supersession records, withdrawal records, retraction records, renewal records, archive records, notices, assurance, and closeout shall not create certification, recognition, finance-readiness, public authority decision, regulatory finding, procurement approval, funding approval, public finance approval, provider endorsement, sponsor approval, host approval, operator approval, community consent, rating, guarantee, public warning, emergency command, protocol effect, operational clearance, legal status, market authority, infrastructure operation, remediation approval, deployment approval, national authority, regional authority, GRF maturity record, GRA finance-readiness, or execution consequence by default.

9.21.10(i) The controlling rule shall be that public authority interface integrity depends on precise records of capacity, data, access, references, review, correction, and clarification, because public authority ambiguity can convert evidence learning into perceived public power unless actively bounded.

### 9.22 Observatory Community, Indigenous, Local, Territorial, and Protected Knowledge Interfaces

9.22.1 Community Participation as Protected Participation, Not Extraction.\
9.22.1(a) GCRI Canada shall steward community, Indigenous, local, territorial, and protected knowledge interface methods for Observatory systems as protected, public-benefit, non-extractive, consent-aware where applicable, context-preserving, safeguard-governed, public-safe, source-lined, confidence-aware, uncertainty-aware, limitation-aware, and correctionable methods through which communities, Indigenous peoples or governance bodies where applicable, local knowledge holders, territorial knowledge holders, cultural knowledge holders, environmental knowledge holders, civil society actors, community institutions, local hosts, local researchers, local observers, and affected or potentially affected persons may contribute, review, challenge, contextualize, restrict, withdraw, or correct evidence.

9.22.1(b) Community participation may support Observatory Nodes, Hubs, Clusters, Hotspots, Regional Observatory Clusters, National Dense Nexus Cores, sensor evidence, community sensor evidence, geospatial evidence, Earth observation evidence, DePIN evidence, AI-RAN evidence, cyber-physical evidence, digital twin outputs, dashboard outputs, degraded-mode evidence, host readiness evidence, maturity evidence inputs, Observatory Evidence Packs, public authority learning materials, GRF inputs, GRA inputs, Protocol Authority inputs, Nexus Risk Management inputs, Nexus Rails inputs, Nexus Academy materials, public-safe summaries, controlled annexes, correction records, and assurance records, provided that participation is bounded by safeguards and shall not become extraction.

9.22.1(c) Community participation shall not be treated as data availability, standing permission, consent by presence, consent by silence, consent by attendance, consent by contribution, waiver of rights, endorsement, public authority approval, community approval, Indigenous approval, host approval, provider approval, sponsor validation, procurement support, finance-readiness, certification, recognition, protocol effect, deployment approval, operational clearance, public warning, emergency command, market signal, legal status, or execution consequence by default.

9.22.1(d) GCRI Canada shall not use community participation to extract knowledge, identify sensitive locations, map protected knowledge, commodify local context, validate sponsor narratives, validate provider claims, imply community consent, imply Indigenous consent, accelerate maturity narratives, finance-readiness narratives, procurement narratives, public authority narratives, public-safe narratives, or deployment narratives beyond the recorded evidence and safeguards.

9.22.1(e) Community interface methods shall protect dignity, agency, context, rights, relationships, local knowledge, territorial knowledge, cultural knowledge, environmental knowledge, Indigenous knowledge where applicable, protected knowledge, vulnerable persons, sensitive sites, community safety, privacy, cybersecurity, data sovereignty, public-safe meaning, and correctionability.

9.22.1(f) Where community participation is referenced externally or publicly, GCRI Canada shall preserve controlled vocabulary, participation capacity, consent or non-consent treatment where applicable, public-safe status, no-community-consent-by-implication language, no-Indigenous-consent-by-implication language where applicable, no-endorsement language, no-public-authority language, no-finance language, no-procurement language, no-certification language, no-recognition language, no-protocol-effect language unless separately created by Protocol Authority, no-provider-endorsement language, no-sponsor-approval language, no-host-approval language, no-deployment-approval language, no-execution language, and correction path.

9.22.1(g) Where ambiguity exists concerning whether community participation authorizes use, publication, mapping, dashboarding, routing, reuse, AI processing, embedding, retrieval, training, finance-facing use, procurement-facing use, public authority use, provider use, sponsor use, or public claim, GCRI Canada shall adopt the narrower, safer, less extractive, more public-safe, more rights-protective, more community-protective, more protected-knowledge-protective, and more correctionable interpretation unless express recorded authority supports broader use.

9.22.1(h) The controlling rule shall be that community participation is protected participation for public-good evidence and learning, not extraction of data, knowledge, legitimacy, consent, endorsement, authority, finance value, procurement value, or execution permission.

***

9.22.2 Indigenous Knowledge, Local Knowledge, Territorial Knowledge, Cultural Sites, Environmental Knowledge, Community Context, and Protected Knowledge Safeguards.\
9.22.2(a) GCRI Canada shall apply heightened safeguards to Indigenous knowledge, local knowledge, territorial knowledge, cultural knowledge, environmental knowledge, traditional ecological knowledge, community context, cultural sites, sacred sites, sensitive sites, protected sites, community-protected data, community-held records, community sensor data, oral context, field observations, place-based knowledge, and protected knowledge used, received, referenced, mapped, modeled, summarized, translated, or routed through Observatory systems.

9.22.2(b) Safeguard records shall identify, where applicable and safe, knowledge category, source context, community context, territorial context, Indigenous protocol, community protocol, cultural protocol, environmental context, sensitive-site treatment, source protection, consent or non-consent treatment, lawful basis where applicable, permitted use, prohibited use, access class, handling class, public-safe status, publication limits, mapping limits, dashboard limits, AI-use limits, retrieval limits, embedding limits, training limits, translation limits, derivative-use limits, commercialization limits, finance-facing limits, procurement-facing limits, public authority limits, provider limits, sponsor limits, retention, deletion, sealing, archive treatment, and correction path.

9.22.2(c) Indigenous knowledge and protected knowledge shall not be extracted, converted, summarized, translated, modeled, embedded, retrieved, trained on, dashboarded, mapped, published, commodified, benchmarked, tokenized, commercialized, routed to finance-facing contexts, routed to procurement-facing contexts, routed to provider-facing contexts, routed to sponsor-facing contexts, or reused for new purposes without recorded authority, safeguards, and public-safe review appropriate to the knowledge context.

9.22.2(d) Cultural sites, sacred sites, sensitive ecological sites, protected habitats, traditional-use locations, community gathering places, vulnerable-person locations, critical service locations, informal infrastructure locations, and other sensitive place-based knowledge shall not be precisely mapped, published, API-exposed, dashboarded, or geospatially inferred where doing so may expose persons, communities, knowledge systems, sites, ecosystems, or infrastructure to harm.

9.22.2(e) Community context shall be preserved when evidence is interpreted. GCRI Canada shall not strip community evidence of local meaning, territorial meaning, cultural meaning, environmental meaning, historical context, access limitations, language limitations, seasonal context, trust context, conflict context, or safeguard requirements merely to fit an Observatory schema, dashboard field, maturity input, Evidence Pack, public-safe summary, digital twin, map layer, AI system, or finance-facing template.

9.22.2(f) Protected knowledge safeguards shall include non-extraction, non-commodification, non-enclosure, non-appropriation, source protection, sensitive-site protection, contextual integrity, purpose limitation, public-safe limitation, access limitation, correctionability, challenge pathways, withdrawal pathways where applicable, and remedy pathways where applicable.

9.22.2(g) Where safeguards conflict with evidence completeness, publication, dashboarding, mapping, AI processing, public authority learning, finance-facing use, procurement-facing use, provider-facing use, sponsor-facing use, Academy use, or public claims, the interpretation preserving community safety, Indigenous safeguards where applicable, protected knowledge, public-safe discipline, privacy, sovereignty, correctionability, and trust shall prevail.

9.22.2(h) The controlling rule shall be that protected knowledge may inform evidence only under safeguards that preserve the people, places, relationships, rights, and duties that make the knowledge meaningful.

***

9.22.3 Consent, Non-Consent, Withdrawal, Grievance, Remedy, Challenge, and Correction Pathways Where Applicable.\
9.22.3(a) GCRI Canada shall steward consent, non-consent, withdrawal, grievance, remedy, challenge, and correction pathways for community, Indigenous, local, territorial, cultural, environmental, and protected knowledge interfaces where such pathways are required by law, protocol, agreement, safeguard, ethics, public-safe discipline, or the nature of the evidence context.

9.22.3(b) Consent records, where applicable, shall identify who provided consent, in what capacity, for what purpose, for what materials, for what duration, for what audiences, for what output classes, under what access class, under what handling class, under what publication limits, under what mapping limits, under what AI-use limits, under what finance-facing limits, under what procurement-facing limits, under what provider or sponsor limits, under what public authority limits, with what withdrawal path, with what correction path, and with what continuing limitations.

9.22.3(c) Non-consent records, where applicable, shall identify materials, uses, audiences, locations, knowledge categories, output classes, maps, dashboards, APIs, publications, AI uses, retrieval uses, embedding uses, training uses, finance-facing uses, procurement-facing uses, provider-facing uses, sponsor-facing uses, public authority uses, or derivative uses that are prohibited, restricted, withheld, or not authorized.

9.22.3(d) Withdrawal pathways shall identify how a community participant, Indigenous governance body where applicable, knowledge holder, host, local institution, or affected person may withdraw participation, restrict future use, request removal, request sealing, request deletion where appropriate, request public-safe revision, request correction, request non-public treatment, or challenge continued reliance, subject to law, records, preservation obligations, and public-safe constraints.

9.22.3(e) Grievance and remedy pathways shall provide a recorded means to raise concerns about extraction, misattribution, misrepresentation, unsafe mapping, protected knowledge exposure, privacy harm, community harm, sponsor misuse, provider misuse, public authority misuse, media misuse, translation error, accessibility failure, public-safe defect, overclaim, or correction failure.

9.22.3(f) Challenge pathways shall allow affected communities or knowledge holders, where appropriate, to challenge source treatment, confidence treatment, uncertainty treatment, limitation statements, public-safe summaries, maps, dashboards, Evidence Packs, Decision Packs, maturity inputs, host readiness outputs, digital twins, degraded-mode outputs, public authority learning materials, GRF inputs, GRA inputs, Protocol Authority inputs, and public claims.

9.22.3(g) Correction pathways shall identify correction intake, reviewer, review timeline where appropriate, interim restrictions, affected records, affected dependencies, notice decisions, corrected language, corrected classification, corrected public-safe status, corrected map treatment, corrected dashboard treatment, corrected boundary language, supersession treatment, withdrawal treatment, retraction treatment where appropriate, archive treatment, and continuing limitations.

9.22.3(h) Consent, non-consent, withdrawal, grievance, remedy, challenge, or correction records shall not create community endorsement, Indigenous approval, public authority approval, certification, recognition, finance-readiness, procurement approval, provider endorsement, sponsor approval, host approval, protocol effect, deployment approval, operational clearance, legal status, market authority, public warning, emergency command, or execution consequence by default.

9.22.3(i) The controlling rule shall be that community interface legitimacy depends not only on participation, but on recorded rights to say no, to limit use, to challenge meaning, to seek remedy, and to correct the record.

***

9.22.4 Community Sensor and Community Data Methods.\
9.22.4(a) GCRI Canada may steward community sensor and community data methods for evidence generated by, contributed by, located in, affecting, or interpreted with communities, including community-hosted sensors, citizen or community science sensors, local environmental sensors, community infrastructure sensors, public-safe learning sensors, community observations, community records, local datasets, field notes, local maps, oral context, community data rooms, Indigenous or community-controlled sensing contexts, and other community-proximate evidence arrangements.

9.22.4(b) Community sensor records shall identify, where safe and appropriate, sensor class, source authority, custody, steward, host context, community context, location or safe-location treatment, calibration status, maintenance status, configuration status, timing status, data quality, community protocol, Indigenous protocol where applicable, consent or non-consent treatment where applicable, access class, handling class, public-safe status, confidence, uncertainty, limitations, permitted use, prohibited use, and correction path.

9.22.4(c) Community data records shall identify data source, community context, custodian, steward, permissions, lawful basis where applicable, consent or non-consent treatment where applicable, local protocol, Indigenous protocol where applicable, data quality, data lineage, classification, sensitivity, retention, deletion, sealing, archive treatment, access controls, publication limits, mapping limits, AI-use limits, retrieval limits, embedding limits, training limits, provider-use limits, sponsor-use limits, public authority-use limits, and correction path.

9.22.4(d) Community sensor and community data methods shall not dismiss community evidence merely because it is locally generated, lower cost, qualitative-adjacent, non-provider-confirmed, non-public-authority-confirmed, not continuous, not high-resolution, not dashboard-ready, not machine-generated, not benchmarked, not monetized, or not easily integrated into technical systems.

9.22.4(e) Community sensor and community data methods shall not elevate community evidence beyond its record, source, context, confidence, uncertainty, limitations, safeguards, consent status, public-safe status, or correction path merely because it is compelling, urgent, public authority-relevant, media-relevant, finance-relevant, sponsor-relevant, provider-relevant, or useful to an Observatory narrative.

9.22.4(f) Community sensor and community data outputs shall not be treated as community consent, community endorsement, Indigenous approval, public authority decision, official public warning, regulatory status, finance-readiness, procurement approval, provider preference, sponsor approval, host approval, certification, recognition, protocol effect, deployment approval, operational clearance, market authority, or execution permission by default.

9.22.4(g) Where community sensor or community data evidence is corrected, disputed, withdrawn, restricted, superseded, reclassified, found unsafe, found misattributed, found decontextualized, found extractive, or found public-safe defective, GCRI Canada shall update affected records, dashboards, maps, Evidence Packs, Decision Packs, public-safe summaries, interface records, dependency records, and correction notices where appropriate.

9.22.4(h) The controlling rule shall be that community sensor and community data methods must respect community evidence as evidence without turning communities into unprotected data infrastructure.

***

9.22.5 Public-Safe Mapping Controls for Community and Protected Knowledge.\
9.22.5(a) GCRI Canada shall apply heightened public-safe mapping controls to maps, dashboards, APIs, geospatial layers, digital twins, visualizations, reports, Evidence Packs, Decision Packs, public-safe summaries, Academy materials, public authority learning materials, GRF inputs, GRA inputs, Protocol Authority inputs, provider-facing materials, sponsor-facing materials, host-facing materials, operator-facing materials, community-facing materials, media materials, repository materials, website materials, and public claims involving community context, Indigenous context, local context, territorial context, cultural sites, sensitive sites, environmental knowledge, or protected knowledge.

9.22.5(b) Public-safe mapping review shall assess whether any output discloses or enables inference of sensitive locations, cultural sites, sacred sites, protected sites, community gathering places, vulnerable-person locations, household patterns, small-group identifiability, community-identifiability, traditional-use areas, protected habitats, critical service locations, informal infrastructure, infrastructure vulnerabilities, cyber-sensitive locations, public authority restricted sites, or protected knowledge.

9.22.5(c) Public-safe mapping controls may require aggregation, generalization, masking, blurring, jittering where appropriate, safe-location treatment, delayed release, omission, controlled annexing, reduced resolution, attribute suppression, label revision, legend revision, access restriction, no-download treatment, API restriction, screenshot restriction, responsible non-disclosure, or no-publication treatment.

9.22.5(d) Map legends, colours, symbols, heatmaps, markers, boundaries, labels, community names, Indigenous names, territorial references, cultural references, environmental references, risk labels, readiness labels, maturity labels, confidence displays, uncertainty displays, and public-safe summaries shall be reviewed for stigmatization, public authority implication, community consent implication, Indigenous consent implication, protected knowledge exposure, public warning implication, finance implication, procurement implication, provider preference, sponsor validation, host approval implication, false precision, and overclaim.

9.22.5(e) Public-safe maps shall not identify protected persons, sensitive sites, cultural sites, sacred sites, protected knowledge locations, vulnerable community locations, small-community patterns, infrastructure vulnerabilities, cyber-sensitive locations, or other harm-enabling details unless there is express recorded authority, lawful basis where applicable, safeguards, public-safe review, and no safer alternative.

9.22.5(f) Where public-safe mapping requires omission or generalization, GCRI Canada shall not treat the resulting map as complete. Public-safe omissions, generalized locations, protected layers, withheld layers, responsible non-disclosure, confidence effects, uncertainty effects, limitation effects, and correction paths shall be recorded where material.

9.22.5(g) Where unsafe mapping, re-identification risk, protected knowledge exposure, community harm, Indigenous safeguard breach, public authority confusion, finance overclaim, procurement implication, provider misuse, sponsor misuse, or public-safe defect is detected after release, GCRI Canada shall restrict access, remove or revise maps, suppress fields, generalize outputs, issue public-safe or controlled correction where appropriate, notify affected interfaces where required, and review dependencies.

9.22.5(h) The controlling rule shall be that community and protected knowledge mapping must protect what the map could expose, not merely describe what the map intends to show.

***

9.22.6 Vulnerable, Remote, Rural, Northern, Arctic, and At-Risk Community Controls.\
9.22.6(a) GCRI Canada shall apply heightened controls to Observatory interfaces involving vulnerable, remote, rural, northern, Arctic, isolated, underserved, disaster-affected, infrastructure-constrained, digitally constrained, climate-exposed, hazard-exposed, health-sensitive, economically vulnerable, culturally sensitive, small, at-risk, or otherwise exposure-sensitive communities.

9.22.6(b) Controls under this section shall identify community context, location or safe-location treatment, infrastructure constraints, connectivity constraints, energy constraints, water constraints, food constraints, housing constraints, health constraints, transport constraints, communications constraints, emergency-management constraints, language needs, accessibility needs, cultural context, territorial context, environmental context, public authority context, provider context, sponsor context, public-safe risks, and correction path.

9.22.6(c) GCRI Canada shall not use vulnerability, remoteness, rurality, northern location, Arctic context, disaster exposure, infrastructure constraint, digital divide, service gap, public authority interest, finance interest, sponsor interest, provider interest, media interest, or project relevance to justify extractive data collection, unsafe mapping, narrative acceleration, community deficit framing, public authority overclaim, finance overclaim, procurement implication, provider preference, sponsor validation, or deployment implication.

9.22.6(d) Evidence concerning vulnerable, remote, rural, northern, Arctic, or at-risk communities shall be reviewed for stigmatization, targeting, surveillance, retaliation, exploitation, displacement, insurance harm, finance harm, procurement harm, public authority misuse, media misuse, provider misuse, sponsor misuse, public-safe harm, re-identification risk, group harm risk, and protected knowledge exposure.

9.22.6(e) Public-safe outputs concerning such communities shall avoid false reassurance, undue alarm, deficit-only framing, unsupported resilience claims, unsupported vulnerability claims, unsafe geospatial precision, small-count exposure, cultural misrepresentation, mistranslation, accessibility failure, and context collapse.

9.22.6(f) Where community constraints affect evidence completeness, GCRI Canada shall record data gaps, connectivity gaps, sensor gaps, compute gaps, language gaps, access gaps, public authority constraints, seasonal constraints, safety constraints, community non-consent where applicable, protected knowledge limits, confidence effects, uncertainty effects, and limitation effects.

9.22.6(g) Where outputs concerning vulnerable, remote, rural, northern, Arctic, or at-risk communities are corrected, restricted, superseded, withdrawn, retracted, misused, misquoted, mistranslated, or made stale by later evidence, GCRI Canada shall update public-safe output records, issue public-safe or controlled correction where appropriate, and review affected dependencies and interfaces.

9.22.6(h) The controlling rule shall be that at-risk community evidence must never turn vulnerability into exposure, need into extraction, remoteness into invisibility, or public-good attention into public harm.

***

9.22.7 Community Review of Public-Safe Outputs Where Required.\
9.22.7(a) GCRI Canada shall require community review, Indigenous protocol review where applicable, protected knowledge review, local context review, translation review, accessibility review, safeguards review, or public-safe review where Observatory outputs materially involve community-identifiable information, Indigenous or protected knowledge, territorial context, cultural context, environmental knowledge, sensitive sites, small communities, vulnerable communities, community sensor data, community data, public-safe mapping, public-facing community claims, or plausible group harm.

9.22.7(b) Community review records shall identify reviewing community body, Indigenous governance body where applicable, community institution, knowledge holder, local reviewer, safeguard reviewer, review capacity, review scope, materials reviewed, language used, accessibility accommodations where applicable, consent or non-consent treatment where applicable, public-safe concerns, permitted references, prohibited references, publication limits, mapping limits, quote limits, photograph limits, data contribution reference limits, correction path, and withdrawal or challenge path where applicable.

9.22.7(c) Community review may address factual accuracy, contextual accuracy, cultural safety, protected knowledge exposure, sensitive-site treatment, translation accuracy, accessibility, community-identifiability risk, group harm risk, public authority implication, sponsor implication, provider implication, finance implication, procurement implication, media risk, and public-safe communication.

9.22.7(d) Community review shall not by itself create community endorsement, Indigenous approval, consent for unrelated uses, waiver of rights, public authority decision, finance-readiness, procurement approval, certification, recognition, protocol effect, provider preference, sponsor approval, host approval, deployment approval, operational clearance, market authority, or execution consequence unless express recorded authority creates such meaning for a defined purpose.

9.22.7(e) Community comments, edits, silence, delay, non-objection, attendance, data contribution, dashboard access, map access, public-safe review, or participation shall not be treated as approval, endorsement, consent, or waiver unless expressly recorded in the relevant capacity and permitted use.

9.22.7(f) Where required community review cannot be completed safely, lawfully, timely, respectfully, accessibly, or without compromising protected knowledge, privacy, cybersecurity, sovereign data, community protocols, Indigenous protocols where applicable, or public-safe discipline, GCRI Canada may restrict use, remove community references, generalize outputs, delay release, use controlled annexes, provide limited public-safe statements, or refuse publication.

9.22.7(g) Where public-safe Observatory outputs are corrected, restricted, superseded, withdrawn, retracted, or materially reclassified after community review, GCRI Canada shall provide community correction notice or controlled notice where appropriate and update affected references, records, dashboards, maps, Evidence Packs, Decision Packs, public-safe summaries, and interface logs.

9.22.7(h) The controlling rule shall be that community review protects meaning, dignity, and safety; it is not a shortcut to endorsement, consent, approval, finance, procurement, certification, recognition, or execution.

***

9.22.8 No Exposure of Protected Persons, Sensitive Locations, Cultural Sites, Infrastructure Vulnerabilities, or Protected Knowledge.\
9.22.8(a) GCRI Canada shall prohibit the unsafe exposure, publication, dashboarding, mapping, API exposure, model display, digital twin display, public-safe summarization, repository release, media use, Academy use, provider sharing, sponsor sharing, finance-facing routing, procurement-facing routing, or public authority routing of protected persons, vulnerable persons, sensitive locations, cultural sites, sacred sites, protected sites, protected habitats, community-sensitive locations, Indigenous or protected knowledge, source identities, household-level information, small-group information, community-identifiable information, infrastructure vulnerabilities, cyber vulnerabilities, safety vulnerabilities, or other harm-enabling details.

9.22.8(b) Exposure risk shall be assessed across direct disclosure, inference, re-identification, linkage, map precision, metadata, labels, legends, screenshots, export files, API fields, dashboard filters, digital twin layers, AI summaries, translations, public records, external datasets, media narratives, finance-facing use, procurement-facing use, provider use, sponsor use, and public authority use.

9.22.8(c) GCRI Canada shall not rely solely on removal of names or direct identifiers where location, time, pattern, rarity, small counts, community context, site context, device context, sensor context, public authority context, or external linkage may identify protected persons, sensitive sites, or protected knowledge.

9.22.8(d) Where exposure risk exists, GCRI Canada shall use restriction, omission, aggregation, generalization, safe-location treatment, delayed release, access controls, controlled annexes, restricted annexes, no-download treatment, responsible non-disclosure, sealing, deletion where appropriate, or refusal of use.

9.22.8(e) Infrastructure vulnerabilities and cyber-sensitive details affecting communities, hosts, operators, public authorities, critical services, remote systems, energy systems, water systems, transport systems, telecommunications systems, health systems, public safety systems, or community facilities shall not be disclosed in a manner that increases targeting, exploitation, panic, retaliation, market harm, or operational risk.

9.22.8(f) Protected knowledge shall not be made legible to unauthorized audiences merely because it is useful to evidence, digital twins, maps, dashboards, public authority learning, finance-facing materials, procurement-facing materials, provider materials, sponsor materials, Academy materials, or public-safe summaries.

9.22.8(g) Where exposure occurs or is suspected, GCRI Canada shall restrict access, halt distribution, remove unsafe materials, correct classification, apply safe-location treatment, delete or seal records where appropriate, withdraw or revise outputs, notify affected interfaces where required and safe, review harms, update safeguards, and review dependencies.

9.22.8(h) The controlling rule shall be that no Observatory output is public-good if it exposes protected people, protected places, protected knowledge, or exploitable vulnerabilities to harm.

***

9.22.9 Community Interface Records, Safeguard Records, Grievance Records, and Correction Records.\
9.22.9(a) GCRI Canada shall maintain, or cause to be maintained, community interface records, Indigenous interface records where applicable, local and territorial interface records, protected knowledge safeguard records, consent records where applicable, non-consent records where applicable, withdrawal records where applicable, grievance records, remedy records, challenge records, correction records, public-safe review records, assurance records, renewal records, archive records, and closeout records for material Observatory community interfaces.

9.22.9(b) Community interface records shall identify interface title or identifier, community context, Indigenous context where applicable, local context, territorial context, cultural context, environmental context, protected knowledge context, participating body or participant capacity where safe and appropriate, host context where any, public authority context where any, provider context where any, sponsor context where any, operator context where any, technology domain, risk domain, data class, evidence class, output class, audience class, access class, handling class, public-safe status, privacy status, cybersecurity status, sovereign data status, infrastructure-sensitive status, public authority status, finance-sensitive status, procurement-sensitive status, provider-sensitive status, sponsor-sensitive status, host-sensitive status, operator-sensitive status, community-protected status, Indigenous or protected knowledge status, legal sensitivity, license status, export-control sensitivity, sanctions sensitivity, controlled-technology sensitivity, permitted uses, prohibited uses, publication limits, and correction path.

9.22.9(c) Safeguard records shall identify community protocols, Indigenous protocols where applicable, consent or non-consent treatment where applicable, territorial context, cultural context, environmental knowledge context, sensitive-site treatment, source protection, public-safe mapping limits, AI-use limits, retrieval limits, embedding limits, training limits, publication limits, translation requirements, accessibility requirements, localization requirements, non-extraction controls, non-commodification controls, do-no-harm controls, withdrawal pathways, challenge pathways, grievance pathways, remedy pathways, and correction path.

9.22.9(d) Grievance records shall identify grievance title or identifier, grievance source where safe and appropriate, affected material, affected community context, alleged issue, extraction concern, misrepresentation concern, unsafe mapping concern, protected knowledge concern, privacy concern, public authority concern, provider concern, sponsor concern, finance concern, procurement concern, media concern, public-safe concern, interim restrictions, reviewer, review status, outcome, remedy where any, correction where any, notice decision, archive treatment, and continuing limitations.

9.22.9(e) Correction records shall identify corrected source, corrected community context, corrected Indigenous or protected knowledge treatment, corrected consent or non-consent treatment, corrected safeguard, corrected translation, corrected accessibility treatment, corrected map, corrected dashboard, corrected API, corrected Evidence Pack, corrected Decision Pack, corrected public-safe summary, corrected public authority reference, corrected provider reference, corrected sponsor reference, corrected host reference, corrected operator reference, corrected boundary language, prior status, corrected status, effective date, reviewer, affected dependencies, notice decision, access change, archive treatment, and continuing limitations.

9.22.9(f) Supersession, withdrawal, or retraction records shall be used where community interface materials should no longer be used or relied upon because of material error, unsafe disclosure, extraction concern, misattribution, decontextualization, mistranslation, accessibility failure, protected knowledge exposure, sensitive-site exposure, community harm risk, public authority confusion, finance overclaim, procurement implication, provider-preferential framing, sponsor-validation framing, host approval implication, community consent implication, Indigenous consent implication where applicable, privacy defect, cybersecurity defect, sovereign data issue, cross-border defect, infrastructure-risk exposure, legal defect, export-control issue, sanctions issue, controlled-technology issue, or correction failure.

9.22.9(g) Community interface records shall be linked, where applicable, to National Dense Core records, Regional Observatory Cluster records, Cluster records, Hub records, Node records, Hotspot records, host readiness records, maturity evidence records, Observatory Evidence Pack Register entries, AI-RAN records, DePIN records, sensor records, geospatial records, cyber telemetry records, digital twin records, dashboard records, degraded-mode records, sovereign compute records, public authority interface records, Observatory Methods Register entries, Evidence Register entries, Source Comparison Records, Dataset Register entries, Model Register entries, System Card entries, Benchmark Card entries, Compute Workload Records, Compute Environment Records, Inference Records, Human Review Records, Retrieval and Embedding Records, Proof Receipt Records, Public-Safe Output Records, AI Incident Records, Correction Records, Dependency Records, Truth Engine Records, Nexus Risk Management records, GRF interface records, GRA interface records, Protocol Authority interface records, RNFD records, Nexus Rails records, Regional Nexus Consortium records, National Nexus Consortium records, National Company records, Project SPV records, operator records, provider records, sponsor records, host records, university records, Nexus interface records, and public claims records.

9.22.9(h) Community interface records, safeguard records, grievance records, remedy records, challenge records, correction records, supersession records, withdrawal records, retraction records, renewal records, archive records, notices, assurance, and closeout shall not create certification, recognition, finance-readiness, public authority decision, regulatory finding, procurement approval, funding approval, public finance approval, provider endorsement, sponsor approval, host approval, operator approval, community consent, Indigenous consent, rating, guarantee, public warning, emergency command, protocol effect, operational clearance, legal status, market authority, infrastructure operation, remediation approval, deployment approval, national authority, regional authority, GRF maturity record, GRA finance-readiness, or execution consequence by default.

9.22.9(i) The controlling rule shall be that community interface records must preserve not only what was learned, but who was protected, what was withheld, what was challenged, what was corrected, what was withdrawn, and what must never be treated as consent or authority.

***

9.22.10 Observatory Community Interface Assurance.\
9.22.10(a) GCRI Canada shall maintain Observatory community interface assurance methods for periodic review of community participation, Indigenous safeguards where applicable, local and territorial interfaces, protected knowledge controls, consent and non-consent treatment, withdrawal pathways, grievance pathways, remedy pathways, challenge pathways, public-safe mapping, community sensor methods, community data methods, public-safe outputs, dashboards, maps, Evidence Packs, Decision Packs, public authority learning materials, GRF inputs, GRA inputs, Protocol Authority inputs, Nexus Risk Management inputs, Nexus Rails inputs, Academy materials, provider-facing materials, sponsor-facing materials, host-facing materials, media materials, repositories, and public claims.

9.22.10(b) Assurance review shall identify review cycle, reviewers, scope reviewed, communities or interface classes reviewed where safe and appropriate, Indigenous protocol review where applicable, protected knowledge review, consent review, non-consent review, withdrawal review, grievance review, remedy review, challenge review, correction review, translation review, accessibility review, localization review, public-safe mapping review, re-identification review, group harm review, privacy review, cybersecurity review, sovereign data review, infrastructure-sensitive review, public authority boundary review, finance-boundary review, procurement-boundary review, provider-neutrality review, sponsor non-control review, host-boundary review, operator-boundary review, and publication review.

9.22.10(c) Assurance shall assess whether community participation has been used in a non-extractive manner; whether safeguards are recorded and followed; whether public-safe outputs preserve context and dignity; whether protected knowledge has remained protected; whether community review occurred where required; whether consent and non-consent were respected; whether withdrawal, grievance, remedy, challenge, and correction pathways functioned; whether dashboards, maps, APIs, and digital twins avoided unsafe exposure; whether provider, sponsor, finance, procurement, and public authority overclaims were prevented; and whether corrections were issued when needed.

9.22.10(d) Assurance findings may require corrective action plans, safeguard updates, method updates, training updates, translation updates, accessibility updates, dashboard updates, map updates, API restrictions, Evidence Pack corrections, Decision Pack corrections, public-safe summary corrections, interface agreement updates, public authority reference corrections, provider reference corrections, sponsor reference corrections, host reference corrections, restricted access, withdrawal, retraction, archive, or refusal of further use.

9.22.10(e) Assurance records shall identify findings, affected communities or interface classes where safe and appropriate, affected knowledge classes, affected outputs, affected dependencies, corrective actions, responsible stewards, timelines where appropriate, notice decisions, public-safe status, controlled status, residual risk, Board or committee reporting where material, and closeout status.

9.22.10(f) Public-safe assurance summaries may be prepared where they can be released without exposing protected persons, sensitive locations, cultural sites, protected knowledge, community grievances, confidential sources, infrastructure vulnerabilities, public authority restrictions, privacy-sensitive materials, cyber-sensitive materials, or other restricted information. Such summaries shall remain non-certifying, non-recognizing, non-financial, non-procurement, non-public-authority, and non-executing.

9.22.10(g) Where assurance identifies systemic risk of extraction, decontextualization, unsafe mapping, public authority confusion, finance overclaim, procurement implication, provider misuse, sponsor misuse, community harm, protected knowledge exposure, or correction failure, GCRI Canada shall restrict affected methods, suspend affected interfaces, update safeguards, notify affected actors where appropriate and safe, and report to the responsible Board or committee function where material.

9.22.10(h) Observatory community interface assurance shall not create community certification, Indigenous approval, public authority approval, finance-readiness, procurement approval, provider endorsement, sponsor approval, host approval, operational clearance, deployment approval, protocol effect, legal status, market authority, public warning, emergency command, or execution consequence by default.

9.22.10(i) The controlling rule shall be that community interface assurance exists to prove that the Observatory protects people, places, knowledge, dignity, and correctionability as seriously as it protects evidence integrity.

### 9.23 Observatory Provider, Vendor, Sponsor, and Host Interfaces

9.23.1 Provider Contribution of Equipment, Compute, Connectivity, Sensors, AI-RAN Systems, DePIN Systems, Dashboards, Cybersecurity Tools, Software, Data Rooms, Staff Time, or Expertise.\
9.23.1(a) GCRI Canada may receive, classify, use, review, public-safe summarize, restrict, correct, supersede, withdraw, or close out provider, vendor, sponsor, host, contractor, university, operator, or other contributor support for Observatory systems, including support involving equipment, compute, sovereign compute, edge compute, cloud services, secure enclaves, confidential computing environments, data rooms, clean rooms, controlled rooms, no-download rooms, connectivity, AI-RAN systems, O-RAN systems, private wireless systems, DePIN systems, sensors, reference sensors, cybersecurity tools, software, dashboards, maps, APIs, geospatial systems, digital twin systems, models, datasets, staff time, technical expertise, field support, facilities support, training support, publication support, or other in-kind or funded support.

9.23.1(b) Provider contributions may support Observatory Nodes, Hubs, Clusters, Hotspots, Regional Observatory Clusters, National Dense Nexus Cores, sovereign compute environments, Evidence Packs, Decision Packs, public-safe summaries, public authority learning, GRF inputs, GRA inputs, Protocol Authority inputs, Nexus Risk Management inputs, Nexus Rails inputs, Nexus Grid inputs, Nexus Academy materials, public-good software support, technical baseline support, assurance, correction, renewal, and closeout, provided that such support remains evidence-supporting, provider-neutral, sponsor-independent, host-bounded, public-safe where externally released, and correctionable.

9.23.1(c) Provider contribution shall not create preferred-provider status, procurement advantage, certification, recognition, finance-readiness, public authority endorsement, protocol effect, Nexus-compatible status, host approval, sponsor approval, operational clearance, deployment approval, infrastructure operation, market authority, legal status, public warning, emergency command, or execution consequence by default.

9.23.1(d) Each material contribution shall be recorded with sufficient precision to identify contributor identity, contributor role, contribution purpose, contribution scope, equipment or service identity, system identity, version, configuration, custody, ownership, use rights, data rights, IP rights, access rights, cybersecurity controls, privacy controls, public-safe status, publication limits, permitted claims, prohibited claims, conflict status, influence controls, correction path, and closeout obligations.

9.23.1(e) GCRI Canada shall not treat provider-supplied materials as neutral, complete, independent, public-safe, procurement-relevant, finance-relevant, certified, recognized, protocol-effective, or maturity-conferring merely because they are supplied by a reputable provider, public authority-used provider, sponsor-supported provider, host-preferred provider, dominant market provider, open-source provider, standards participant, or Nexus-participating provider.

9.23.1(f) Provider, vendor, sponsor, or host access to Observatory data, records, dashboards, maps, APIs, Evidence Packs, Decision Packs, compute environments, source repositories, controlled rooms, data rooms, clean rooms, public authority rooms, community materials, protected knowledge materials, public-safe outputs, or correction records shall be role-based, purpose-bound, least-privilege, logged, time-bound where appropriate, revocable, and subject to confidentiality, cybersecurity, privacy, sovereign data, protected knowledge, public-safe, provider-neutrality, sponsor non-control, host-boundary, and correction controls.

9.23.1(g) Where a provider contribution is withdrawn, restricted, corrected, superseded, disputed, misclassified, unsafe, unauthorized, overclaimed, conflict-affected, public-safe defective, or correction-defective, GCRI Canada shall update affected records, dashboards, maps, Evidence Packs, Decision Packs, public-safe summaries, interface records, dependency records, acknowledgement materials, and closeout records as appropriate.

9.23.1(h) The controlling rule shall be that providers may contribute tools, infrastructure, expertise, and support to Observatory evidence, but contribution shall never be treated as control, endorsement, procurement advantage, certification, finance-readiness, recognition, protocol effect, authority, or execution by implication.

***

9.23.2 Provider Participation Without Preferred Status, Procurement Advantage, Certification, Recognition, Finance-Readiness, or Public Authority Endorsement.\
9.23.2(a) Provider participation in any Observatory interface shall be treated as bounded participation in evidence, methods, observability, technical learning, public-safe output, assurance, correction, or support, and not as preferred-provider status, procurement approval, tender advantage, supplier qualification, certification, recognition, finance-readiness, public authority endorsement, protocol effect, Nexus-compatible status, market entitlement, operational clearance, deployment approval, or execution consequence by default.

9.23.2(b) Provider participation includes contribution of equipment, systems, compute, connectivity, AI-RAN systems, DePIN systems, sensors, cybersecurity tools, software, dashboards, maps, APIs, models, datasets, staff time, technical expertise, demonstrations, pilots, validation sessions, benchmarks, field support, public-safe materials, training, or documentation.

9.23.2(c) Provider participation records shall identify provider identity, provider role, contribution type, materials supplied, systems supplied, data supplied, tools supplied, staff involved where material, configuration, version, test conditions, benchmark conditions where any, validation conditions where any, commercial sensitivity, IP sensitivity, cybersecurity sensitivity, privacy sensitivity, public authority sensitivity, export-control sensitivity, sanctions sensitivity, conflict status, influence controls, permitted claims, prohibited claims, publication limits, correction path, and closeout obligations.

9.23.2(d) GCRI Canada shall not rank, recommend, endorse, approve, certify, recognize, prefer, procure, qualify, finance, insure, guarantee, rate, or validate a provider by reason of provider participation in Observatory systems, Evidence Packs, dashboards, maps, public-safe outputs, Academy materials, public authority learning materials, GRF inputs, GRA inputs, Protocol Authority inputs, National Company materials, Project SPV materials, or Nexus interface materials.

9.23.2(e) Provider comparison, benchmarking, testing, validation, demonstration, integration, dashboard display, map display, public-safe mention, public authority attendance, sponsor support, host use, operator use, or Academy use shall not create provider ranking, procurement preference, security certification, technical certification, finance-readiness, public authority endorsement, protocol effect, Nexus-compatible status, market superiority, or execution readiness by default.

9.23.2(f) Provider-facing or provider-referencing outputs shall include, where material, no-endorsement, no-preference, no-procurement, no-certification, no-recognition, no-finance-readiness, no-public-authority-endorsement, no-protocol-effect unless separately created by Protocol Authority, no-security-guarantee, no-operational-clearance, no-deployment-approval, no-execution, confidence, uncertainty, limitation, permitted-use, prohibited-use, and correction language.

9.23.2(g) Where provider participation is misused to imply preferred status, procurement advantage, certification, recognition, finance-readiness, public authority endorsement, sponsor validation, host approval, market entitlement, protocol effect, or execution readiness, GCRI Canada shall correct, relabel, restrict, withdraw, reissue, request removal of misleading references, notify affected interfaces where appropriate, suspend affected interface use, or pursue contractual or legal remedies where appropriate.

9.23.2(h) The controlling rule shall be that provider participation may support technical evidence, but it shall not become provider preference, procurement, certification, recognition, finance, public authority endorsement, protocol effect, or execution.

***

9.23.3 Sponsor Support Without Sponsor Control.\
9.23.3(a) Sponsor support for Observatory systems shall be permitted only as support-without-control. Sponsor support may include funding, convening support, facilities support, technology access, provider introductions, communications support, public-safe publication support, research support, training support, field support, or other lawful support, provided that such support does not control evidence, methods, sources, reviewers, confidence, uncertainty, public-safe treatment, publication, correction, recognition, finance-readiness, protocol effect, procurement, provider selection, host selection, public authority access, community participation, or execution.

9.23.3(b) Sponsor support records shall identify sponsor identity, sponsor role, support type, support value where recorded, support purpose, support scope, funding terms, in-kind terms, public acknowledgement terms, conflict status, influence controls, independence controls, publication controls, data access limits, provider access limits, public authority access limits, community access limits, permitted claims, prohibited claims, correction path, and closeout obligations.

9.23.3(c) Sponsor support shall not purchase outcomes, direct evidence selection, direct source inclusion, direct source exclusion, direct method design, direct confidence scoring, direct public-safe classification, direct dashboards, direct maps, direct Evidence Packs, direct Decision Packs, direct public-safe summaries, direct GRF inputs, direct GRA inputs, direct Protocol Authority inputs, direct public authority materials, direct provider materials, direct host materials, direct community materials, or direct correction outcomes.

9.23.3(d) Sponsor support shall not create sponsor endorsement, sponsor approval, sponsor validation, public authority endorsement, procurement advantage, finance-readiness, provider preference, host approval, community approval, certification, recognition, protocol effect, operational clearance, deployment approval, market authority, public warning, emergency command, or execution consequence by default.

9.23.3(e) Sponsor visibility shall be separated from sponsor control. Acknowledgement of support shall not imply that the sponsor designed, controlled, approved, reviewed, endorsed, certified, recognized, financed, procured, or executed the Observatory output unless such role is expressly recorded and permitted, and shall never imply a prohibited role.

9.23.3(f) Sponsor access to controlled materials, data rooms, clean rooms, dashboards, maps, Evidence Packs, Decision Packs, public authority rooms, provider materials, host materials, community materials, or protected knowledge materials shall be limited to the sponsor’s recorded role and shall not exceed what is lawful, necessary, public-safe, privacy-protective, cybersecurity-controlled, sovereign-data-compatible, provider-neutral, community-safe, and correctionable.

9.23.3(g) Where sponsor support creates or appears to create influence, capture, outcome purchase, evidence control, publication control, public authority access control, provider preference, finance overclaim, procurement implication, host approval implication, community harm, protected knowledge exposure, or public-safe defect, GCRI Canada shall restrict sponsor access, revise acknowledgement language, correct records, suspend affected support, decline support, terminate support, issue clarification, or pursue contractual or legal remedies where appropriate.

9.23.3(h) The controlling rule shall be that sponsors may support the Observatory, but they may not control the Observatory.

***

9.23.4 Host Support Without Host Control.\
9.23.4(a) Host support for Observatory systems shall be permitted only as bounded host participation and support-without-control. Host support may include site access, facility access, data contribution, sensor hosting, compute hosting, connectivity support, staff time, local context, field support, safety context, public authority context, community context, operator context, or other lawful support, provided that such support does not control evidence, methods, reviewers, public-safe treatment, publication, correction, provider selection, sponsor treatment, public authority meaning, community meaning, finance-readiness, procurement, certification, recognition, protocol effect, or execution.

9.23.4(b) Host support records shall identify host identity, host role, support type, support purpose, support scope, facility or site context where safe and material, data rights, access rights, site restrictions, safety restrictions, security restrictions, public authority restrictions, community restrictions, provider restrictions, sponsor restrictions, publication limits, safe-location treatment, permitted claims, prohibited claims, correction path, and closeout obligations.

9.23.4(c) Host support shall not create host certification, host approval, site approval, facility approval, community consent, public authority approval, procurement approval, finance-readiness, provider preference, sponsor validation, certification, recognition, protocol effect, operational clearance, deployment approval, infrastructure operation, legal status, market authority, public warning, emergency command, or execution consequence by default.

9.23.4(d) Host access to Observatory records, dashboards, maps, Evidence Packs, Decision Packs, public-safe summaries, controlled annexes, provider materials, sponsor materials, public authority materials, community materials, or protected knowledge materials shall be limited to recorded role, access class, handling class, public-safe status, confidentiality obligations, privacy controls, cybersecurity controls, sovereign data controls, community safeguards, protected knowledge safeguards, and correction requirements.

9.23.4(e) Host review, comments, attendance, site access, facility access, data contribution, dashboard access, map access, sensor placement, compute placement, connectivity support, public authority contact, community contact, provider contact, sponsor support, or public-safe mention shall not imply host endorsement of the Observatory output or GCRI Canada approval of the host.

9.23.4(f) Host-facing or host-referencing outputs shall include, where material, no-host-certification, no-host-approval, no-site-approval, no-community-consent-by-implication, no-public-authority-approval, no-procurement, no-finance-readiness, no-provider-endorsement, no-sponsor-approval, no-protocol-effect, no-deployment-approval, no-operational-clearance, no-execution, confidence, uncertainty, limitation, permitted-use, prohibited-use, and correction language.

9.23.4(g) Where host support creates or appears to create host control, host approval, unsafe site exposure, public authority confusion, community consent implication, provider preference, sponsor validation, procurement implication, finance overclaim, certification implication, recognition implication, protocol implication, protected knowledge exposure, privacy defect, cybersecurity defect, or public-safe defect, GCRI Canada shall correct, relabel, restrict, withdraw, reissue, revise access, suspend affected interface use, or pursue contractual or legal remedies where appropriate.

9.23.4(h) The controlling rule shall be that hosts may enable Observatory evidence, but they do not control GCRI Canada evidence, methods, public-safe publication, correction, or institutional meaning.

***

9.23.5 Vendor and Contractor Support Without Institutional Voice.\
9.23.5(a) Vendors, contractors, consultants, technical suppliers, professional service providers, platform providers, cloud providers, cybersecurity providers, dashboard providers, software developers, data-room providers, field contractors, communications contractors, evaluators, trainers, and other support actors may support Observatory systems only within recorded contractual, technical, confidentiality, cybersecurity, privacy, public-safe, non-execution, and correction boundaries.

9.23.5(b) Vendor and contractor support shall not give the vendor or contractor institutional voice, authority to speak for GCRI Canada, authority to bind GCRI Canada, authority to approve evidence, authority to approve methods, authority to approve public-safe outputs, authority to approve public authority references, authority to approve finance-facing materials, authority to approve provider references, authority to approve sponsor references, authority to approve host references, authority to issue certifications, authority to issue recognition, authority to create protocol effect, authority to direct procurement, authority to direct public authority engagement, authority to control community interfaces, or authority to execute GCRI Canada functions beyond the recorded engagement.

9.23.5(c) Vendor and contractor records shall identify vendor or contractor identity, role, engagement scope, deliverables, data access, system access, repository access, public authority access, provider access, sponsor access, host access, community access, protected knowledge access, IP treatment, confidentiality obligations, cybersecurity obligations, privacy obligations, AI-use restrictions, subcontractor restrictions, publication restrictions, public claims restrictions, conflict status, independence status, correction obligations, and closeout obligations.

9.23.5(d) Vendors and contractors shall not represent themselves as GCRI Canada officers, employees, directors, public authority agents, certification agents, recognition agents, finance-readiness agents, procurement agents, Protocol Authority agents, Observatory operators, emergency actors, public warning actors, or execution actors unless expressly authorized for a narrow administrative purpose and without creating prohibited authority.

9.23.5(e) Vendor-created materials, drafts, dashboards, maps, software, analyses, summaries, AI outputs, reports, technical notes, public-safe materials, or presentations shall remain subject to GCRI Canada review, classification, public-safe controls, boundary controls, records discipline, correction, and approval before material use.

9.23.5(f) Vendor and contractor public claims shall be prohibited unless expressly authorized, accurately bounded, public-safe, non-endorsement, non-certifying, non-recognizing, non-financial, non-procurement, non-protocol-conferring, non-public-authority, non-sponsor-validating, non-host-approving, and correctionable.

9.23.5(g) Where vendor or contractor support is overclaimed, misused, unauthorized, conflicted, insecure, public-safe defective, privacy-defective, cybersecurity-defective, public authority-confusing, finance-inflating, procurement-implying, provider-preferential, sponsor-validating, host-approval-implying, or correction-defective, GCRI Canada shall correct, restrict, revoke access, suspend work, require remediation, withhold use, terminate engagement, issue clarification, or pursue contractual or legal remedies where appropriate.

9.23.5(h) The controlling rule shall be that vendors and contractors may provide support to GCRI Canada, but they shall not become GCRI Canada’s institutional voice or authority.

***

9.23.6 In-Kind Contribution Records, Valuation, Ownership, Custody, Use Rights, IP, Data, Security, Public Claims, and Closeout.\
9.23.6(a) GCRI Canada shall maintain in-kind contribution records for material provider, vendor, sponsor, host, contractor, operator, university, community, or other contributor support involving equipment, software, cloud credits, compute, connectivity, data rooms, sensors, AI-RAN systems, DePIN devices, cybersecurity tools, dashboards, maps, APIs, staff time, facilities, field support, technical services, training, documentation, public-safe publication support, or other non-cash support.

9.23.6(b) In-kind contribution records shall identify contributor identity, contributor role, contribution description, contribution purpose, contribution scope, date, duration, estimated value where required or appropriate, valuation method where used, ownership, custody, possession, control, access rights, use rights, sublicensing limits, transfer limits, assignment limits, return obligations, deletion obligations, closeout obligations, and correction path.

9.23.6(c) Ownership and custody records shall identify whether materials are owned by GCRI Canada, licensed to GCRI Canada, loaned to GCRI Canada, hosted by a contributor, hosted by a provider, controlled by a sponsor, controlled by a host, controlled by a contractor, controlled by a public authority, community-controlled, open-source, open-data, public-domain, jointly held, or subject to other restrictions.

9.23.6(d) IP records shall identify intellectual property ownership, license, permitted use, prohibited use, derivative-use rights, publication rights, attribution requirements, confidentiality, open-source obligations, repository obligations, patent sensitivity, trade secret sensitivity, moral rights where applicable, background IP, foreground IP, improvements, feedback rights, and closeout treatment.

9.23.6(e) Data records shall identify data source, ownership where known, custody, stewardship, license, permissions, lawful basis where applicable, consent or non-consent treatment where applicable, public authority restrictions, community restrictions, Indigenous or protected knowledge restrictions, privacy status, cybersecurity status, sovereign data status, infrastructure-sensitive status, finance-sensitive status, provider-sensitive status, sponsor-sensitive status, host-sensitive status, operator-sensitive status, retention, deletion, sealing, archive treatment, access limits, AI-use limits, retrieval limits, embedding limits, training limits, publication limits, and correction path.

9.23.6(f) Security records shall identify access controls, identity controls, logging, monitoring, encryption, key management, token management, secrets management, credential controls, vulnerability handling, incident path, support access, subcontractor access, cross-border access, data residency, backup, disaster recovery, decommissioning, and closeout.

9.23.6(g) Public claims records shall identify permitted acknowledgement, prohibited acknowledgement, permitted logo use where any, prohibited logo use, permitted quotes, prohibited quotes, permitted case study use, prohibited case study use, no-endorsement language, no-procurement language, no-finance-readiness language, no-certification language, no-recognition language, no-protocol-effect language, no-public-authority-endorsement language, no-host-approval language, and correction path.

9.23.6(h) Closeout records shall identify return, deletion, sealing, archive, access revocation, credential revocation, key revocation where applicable, equipment return, software deprovisioning, repository access removal, data-room closure, dashboard removal, API deactivation, support termination, outstanding corrections, outstanding notices, continuing confidentiality, continuing IP obligations, continuing data obligations, continuing public-safe obligations, continuing prohibited claims, and dependency treatment.

9.23.6(i) In-kind contribution records, valuation, ownership, custody, use rights, IP records, data records, security records, public claims records, and closeout records shall not create endorsement, procurement approval, finance-readiness, certification, recognition, public authority approval, provider preference, sponsor validation, host approval, protocol effect, deployment approval, operational clearance, market authority, legal status, public warning, emergency command, or execution consequence by default.

9.23.6(j) The controlling rule shall be that every contribution must be traceable enough to show what was given, who controlled it, what rights attached, what risks followed, what claims were allowed, and how the contribution ended.

***

9.23.7 Provider and Sponsor Conflict Review.\
9.23.7(a) GCRI Canada shall apply provider, vendor, sponsor, host, operator, contractor, public authority, finance, procurement, community, and institutional conflict review to Observatory interfaces where support, contribution, participation, funding, equipment, data, software, compute, dashboards, maps, public authority access, community access, visibility, or public claims may affect or appear to affect evidence integrity, provider neutrality, sponsor non-control, public-safe publication, finance boundaries, procurement boundaries, certification boundaries, recognition boundaries, protocol boundaries, public authority boundaries, or correctionability.

9.23.7(b) Conflict review records shall identify the actor, relationship, contribution, financial interest, commercial interest, procurement interest, finance interest, public authority interest, sponsor interest, provider interest, host interest, operator interest, IP interest, data interest, publication interest, visibility interest, market interest, token or incentive interest where any, political or reputational interest where material, conflict classification, mitigation, disclosure, recusal where required, access limits, publication limits, permitted claims, prohibited claims, and correction path.

9.23.7(c) Provider conflicts may include provider involvement in supplying systems being observed, evaluated, benchmarked, compared, displayed, mapped, dashboarded, referenced in Evidence Packs, routed to public authorities, routed to finance-facing interfaces, routed to procurement-facing contexts, or used in Academy materials.

9.23.7(d) Sponsor conflicts may include sponsor funding, sponsor convening, sponsor technology provision, sponsor provider relationships, sponsor host relationships, sponsor public authority relationships, sponsor finance interests, sponsor market interests, sponsor publication interests, sponsor visibility interests, sponsor desired outcomes, or sponsor interest in public-safe narratives.

9.23.7(e) Conflict review shall prohibit conflicted actors from controlling source selection, method selection, reviewer selection, confidence treatment, uncertainty treatment, public-safe classification, Evidence Pack conclusions, dashboard labels, map labels, benchmark claims, public authority references, GRF-facing inputs, GRA-facing inputs, Protocol Authority-facing inputs, provider comparisons, host readiness language, community safeguards, protected knowledge treatment, correction outcomes, or publication outcomes.

9.23.7(f) Conflict mitigation may include disclosure, role limitation, access limitation, reviewer independence, recusal, independent technical review, public-safe boundary language, no-claims language, anonymization, aggregation, controlled-room treatment, separation of support from evidence decisions, refusal of contribution, suspension of interface, termination of support, or Board or committee reporting where material.

9.23.7(g) Where conflict is undisclosed, inadequately managed, public-safe defective, provider-preferential, sponsor-controlling, host-controlling, procurement-implying, finance-inflating, public authority-confusing, community-harming, protected-knowledge-exposing, or correction-defective, GCRI Canada shall correct records, restrict access, revise outputs, withdraw affected materials, reissue corrected materials, notify affected interfaces where appropriate, update training, and review governance controls.

9.23.7(h) The controlling rule shall be that support is welcome only where conflicts are visible, bounded, mitigated, and incapable of controlling evidence.

***

9.23.8 Public Acknowledgment and Visibility Controls.\
9.23.8(a) GCRI Canada shall maintain public acknowledgment and visibility controls for references to providers, vendors, sponsors, hosts, operators, contractors, public authorities, universities, communities, National Companies, Project SPVs, GRF, GRA, Protocol Authority, Nexus entities, or other actors in Observatory materials.

9.23.8(b) Public acknowledgment records shall identify actor name, role, contribution, intended wording, publication channel, audience, public-safe status, logo or mark use where any, photograph use where any, quote use where any, case study use where any, provider reference status, sponsor reference status, host reference status, public authority reference status, community reference status, permitted claims, prohibited claims, expiration or review date where any, and correction path.

9.23.8(c) Public acknowledgments shall distinguish funding support, in-kind support, technical contribution, data contribution, facility support, participation, attendance, review, comment, pilot involvement, demonstration involvement, hosting, sponsorship, contracting, public authority participation, community participation, and formal approval. Such categories shall not be collapsed into a misleading association.

9.23.8(d) Public acknowledgments shall not imply endorsement, adoption, approval, certification, recognition, finance-readiness, procurement approval, public authority approval, provider preference, sponsor validation, host approval, operator approval, community consent, Indigenous consent, protocol effect, deployment approval, operational clearance, market authority, legal status, public warning, emergency command, or execution consequence unless expressly and lawfully authorized by the competent actor and not prohibited by GCRI Canada’s role.

9.23.8(e) Logo, mark, seal, photograph, quote, case study, testimonial, event listing, sponsor listing, provider listing, host listing, participant listing, or public authority listing shall be reviewed for public-safe meaning, endorsement implication, procurement implication, finance implication, certification implication, recognition implication, public authority implication, community consent implication, sponsor influence implication, provider preference implication, and correctionability.

9.23.8(f) Where acknowledgement would create unsafe public meaning, GCRI Canada may generalize, anonymize, aggregate, omit, delay, revise, restrict, or refuse acknowledgement.

9.23.8(g) Where public acknowledgment or visibility is missing, stale, exceeded, contested, withdrawn, misquoted, mistranslated, visually misleading, sponsor-validating, provider-preferential, procurement-implying, finance-inflating, public authority-confusing, host-approval-implying, community-consent-implying, or public-safe defective, GCRI Canada shall remove, correct, restrict, relabel, withdraw, reissue, seek renewed approval, or issue clarification as appropriate.

9.23.8(h) The controlling rule shall be that visibility is itself a governance surface: naming a supporter must never become conferring status.

***

9.23.9 Correction Where Provider, Vendor, Sponsor, or Host Support Is Overclaimed.\
9.23.9(a) GCRI Canada shall require correction where provider, vendor, sponsor, contractor, host, operator, or contributor support is overstated, misused, misclassified, publicly misread, used for marketing overclaim, used for procurement implication, used for finance implication, used for certification implication, used for recognition implication, used for public authority endorsement, used for protocol implication, used for provider preference, used for sponsor validation, used for host approval, used for operator approval, used for community consent implication, or used for execution implication.

9.23.9(b) Overclaim includes any statement, label, dashboard display, map display, public-safe summary, Evidence Pack reference, Decision Pack reference, maturity evidence input, host readiness input, benchmark statement, Proof Receipt reference, public authority reference, GRF reference, GRA reference, Protocol Authority reference, National Company reference, Project SPV reference, sponsor acknowledgement, provider acknowledgement, host acknowledgement, case study, media claim, website claim, social claim, investor-facing claim, procurement-facing claim, or public claim that implies unsupported status or authority.

9.23.9(c) Correction may require relabeling, boundary-language revision, acknowledgement revision, logo removal, quote removal, case study revision, provider-reference correction, sponsor-reference correction, host-reference correction, public authority-reference correction, confidence downgrade, uncertainty revision, limitation update, dashboard correction, map correction, Evidence Pack correction, Decision Pack correction, public-safe summary correction, controlled notice, public-safe notice, withdrawal, retraction, supersession, archive treatment, access restriction, or removal of misleading references.

9.23.9(d) Where overclaim arises from third-party marketing, provider materials, sponsor materials, host materials, vendor materials, public authority materials, National Company materials, Project SPV materials, media materials, finance-facing materials, procurement materials, or public claims, GCRI Canada may require correction, request removal, request relabeling, issue clarification, suspend interface use, restrict access, terminate support, or pursue contractual or legal remedies where appropriate.

9.23.9(e) Where overclaim affects GRF, GRA, Protocol Authority, Nexus Risk Management, Nexus Rails, National Nexus Consortiums, Regional Nexus Consortiums, National Companies, Project SPVs, public authorities, providers, vendors, sponsors, hosts, operators, communities, universities, Academy materials, media materials, repositories, dashboards, maps, APIs, Evidence Packs, Decision Packs, public-safe summaries, or public claims, GCRI Canada shall review affected dependencies and issue public-safe or controlled correction signals as appropriate.

9.23.9(f) Correction shall not itself create endorsement, procurement approval, finance-readiness, certification, recognition, public authority decision, provider preference, sponsor finding, host finding, operator finding, community consent, rating, guarantee, public warning, emergency command, protocol effect, operational clearance, legal status, market authority, deployment approval, or execution consequence by default.

9.23.9(g) Where ambiguity exists, GCRI Canada shall correct toward the safer, narrower, more source-lined, more public-safe, more provider-neutral, more sponsor-independent, more host-bounded, more public-authority-bounded, more finance-safe, more procurement-safe, more certification-safe, more recognition-safe, and more correctionable interpretation.

9.23.9(h) The controlling rule shall be that support overclaim must be corrected quickly because contribution can become perceived endorsement, procurement, finance, certification, recognition, authority, or execution unless actively bounded.

***

9.23.10 Interface Agreements and Support-Without-Control Terms.\
9.23.10(a) GCRI Canada shall require appropriate interface agreements, contribution terms, support terms, data terms, security terms, IP terms, public claims terms, confidentiality terms, public-safe terms, correction terms, and closeout terms for material provider, vendor, sponsor, host, contractor, operator, university, public authority, community, or other contributor support to Observatory systems.

9.23.10(b) Interface agreements shall identify parties, roles, contribution scope, support scope, purpose, permitted use, prohibited use, ownership, custody, use rights, IP rights, data rights, access rights, confidentiality, cybersecurity, privacy, sovereign data, public authority restrictions, community safeguards, protected knowledge restrictions, publication limits, public claims controls, acknowledgement controls, conflict controls, audit or review rights where appropriate, correction obligations, termination rights, suspension rights, closeout obligations, and survival obligations.

9.23.10(c) Support-without-control terms shall state that contributors do not control evidence, source selection, method selection, reviewer selection, confidence treatment, uncertainty treatment, public-safe classification, dashboards, maps, Evidence Packs, Decision Packs, public authority references, community safeguards, protected knowledge treatment, GRF inputs, GRA inputs, Protocol Authority inputs, correction outcomes, publication decisions, recognition decisions, finance-readiness decisions, protocol-effect decisions, procurement decisions, or execution decisions.

9.23.10(d) Provider terms shall preserve no-endorsement, no-preference, no-procurement-advantage, no-certification, no-recognition, no-finance-readiness, no-public-authority-endorsement, no-protocol-effect unless separately created by Protocol Authority, no-security-guarantee, no-operational-clearance, no-deployment-approval, no-market-entitlement, and no-execution boundaries.

9.23.10(e) Sponsor terms shall preserve sponsor non-control, no-outcome-purchase, no-evidence-control, no-publication-control, no-source-selection-control, no-reviewer-control, no-public-authority-access-control, no-provider-selection-control, no-host-selection-control, no-community-control, no-recognition-control, no-finance-control, no-protocol-control, no-procurement-control, and no-execution-control boundaries.

9.23.10(f) Host terms shall preserve host-boundary, host data rights, site access limits, facility access limits, safety limits, security limits, community limits, public authority limits, no-host-certification, no-host-approval, no-community-consent-by-implication, no-public-authority-approval, no-procurement, no-finance-readiness, no-provider-endorsement, no-sponsor-approval, no-protocol-effect, no-deployment-approval, no-operational-clearance, and no-execution boundaries.

9.23.10(g) Vendor and contractor terms shall preserve no-institutional-voice, no-authority-to-bind, no-public-claims-without-approval, no-certification authority, no-recognition authority, no-finance-readiness authority, no-procurement authority, no-public-authority authority, no-protocol authority, no-community-interface authority beyond recorded scope, no-public-warning authority, no-emergency-command authority, and no-execution authority.

9.23.10(h) Agreements shall require correction cooperation, including duties to correct inaccurate claims, remove misleading references, update acknowledgements, preserve records where required, support incident review, support access revocation, support deletion or return where applicable, support supersession notices, support public-safe clarification where appropriate, and cease prohibited claims after termination or closeout.

9.23.10(i) Interface agreements and support-without-control terms shall not create certification, recognition, finance-readiness, public authority decision, procurement approval, provider endorsement, sponsor approval, host approval, operator approval, community consent, rating, guarantee, public warning, emergency command, protocol effect, operational clearance, legal status, market authority, infrastructure operation, remediation approval, deployment approval, national authority, regional authority, GRF maturity record, GRA finance-readiness, or execution consequence by default.

9.23.10(j) The controlling rule shall be that every support relationship must be papered, bounded, correctable, and closeout-ready so that support strengthens the public-good Observatory without purchasing control, status, authority, market advantage, or execution.

### 9.24 Observatory Data Governance

9.24.1 Observatory Data Classification.\
9.24.1(a) GCRI Canada shall steward Observatory data governance methods for classifying, receiving, generating, storing, processing, routing, reviewing, public-safe summarizing, correcting, restricting, deleting, sealing, archiving, and closing out data used in or arising from Observatory systems, including data associated with Nodes, Hubs, Clusters, Hotspots, Regional Observatory Clusters, National Dense Nexus Cores, sensors, AI-RAN systems, O-RAN systems, private wireless systems, DePIN systems, cyber telemetry, geospatial layers, Earth observation, digital twins, dashboards, maps, APIs, Evidence Packs, Decision Packs, public authority interfaces, community interfaces, provider interfaces, sponsor interfaces, host interfaces, operator interfaces, sovereign compute environments, model systems, public-good software, technical baselines, public-safe outputs, correction records, and assurance records.

9.24.1(b) Observatory data classification shall be applied before material use, external routing, dashboarding, mapping, API exposure, publication, public authority sharing, GRF input routing, GRA input routing, Protocol Authority input routing, provider sharing, sponsor sharing, host sharing, operator sharing, community sharing, AI use, retrieval, embedding, training, vendor processing, cross-border transfer, retention, deletion, sealing, archive, or closeout.

9.24.1(c) Observatory data classification shall identify, where material, data source, source authority, source permission, lawful basis where applicable, data class, evidence class, output class, access class, handling class, public-safe status, privacy status, cybersecurity status, sovereign data status, infrastructure sensitivity, public authority sensitivity, health sensitivity, finance sensitivity, commercial sensitivity, community protection status, Indigenous or protected knowledge status, legal sensitivity, export-control sensitivity, sanctions sensitivity, controlled-technology sensitivity, permitted uses, prohibited uses, publication limits, retention treatment, correction path, and dependency links.

9.24.1(d) Classification shall be risk-based and context-based. Data shall not be classified only by file name, source label, format, system of origin, provider label, sponsor label, host label, public availability, dashboard visibility, map visibility, machine generation, or technical accessibility where actual sensitivity, inference risk, aggregation risk, public authority meaning, public-safe risk, community risk, protected knowledge risk, finance-facing risk, procurement-facing risk, or correction risk requires a more protective classification.

9.24.1(e) GCRI Canada shall apply the more protective classification where data reasonably falls into multiple classes, where classification is unclear, where public authority meaning is ambiguous, where community or protected knowledge sensitivity may exist, where cyber or infrastructure harm could result, where personal or health-sensitive inference may arise, where finance-facing or procurement-facing misuse is plausible, or where cross-border, sovereign data, export-control, sanctions, or controlled-technology concerns may exist.

9.24.1(f) Classification shall travel with the data. Where Observatory data are copied, transformed, aggregated, summarized, dashboarded, mapped, modeled, embedded, retrieved, API-exposed, included in Evidence Packs, included in Decision Packs, included in public-safe summaries, routed to interfaces, corrected, superseded, withdrawn, retracted, sealed, archived, or closed out, their classification, handling limits, public-safe status, permitted uses, prohibited uses, and correction path shall remain attached or traceable.

9.24.1(g) Classification shall not create authority. A data class, access class, public-safe class, evidence class, output class, handling class, review status, or register status shall not constitute certification, recognition, finance-readiness, procurement approval, public authority decision, public warning, emergency command, protocol effect, provider endorsement, sponsor approval, host approval, operator instruction, operational clearance, deployment approval, market authority, legal status, or execution consequence by default.

9.24.1(h) The controlling rule shall be that Observatory data cannot be trusted, shared, displayed, modeled, corrected, or protected unless its class, purpose, authority, limits, sensitivity, public-safe status, and correction path are known.

***

9.24.2 Public, Public-Safe, Internal, Confidential, Restricted, Public Authority, Health-Sensitive, Cyber-Sensitive, Infrastructure-Sensitive, Finance-Sensitive, Commercially Sensitive, Personal, Community-Protected, Indigenous, Local, Territorial, Environmental, and Protected Knowledge Data Classes.\
9.24.2(a) GCRI Canada shall maintain Observatory data classes sufficient to distinguish public data, public-safe data, internal data, confidential data, restricted data, public authority data, health-sensitive data, cyber-sensitive data, infrastructure-sensitive data, finance-sensitive data, commercially sensitive data, personal data, community-protected data, Indigenous data where applicable, local data, territorial data, environmental data, protected knowledge data, legal-sensitive data, export-control-sensitive data, sanctions-sensitive data, controlled-technology data, and any combined, derived, inferred, aggregated, or transformed data requiring heightened treatment.

9.24.2(b) Public data shall mean data that are lawfully available for public use and are not, by context, aggregation, inference, source restriction, license, public authority status, protected knowledge status, cybersecurity risk, infrastructure risk, community risk, privacy risk, finance risk, procurement risk, public-safe risk, or correction risk, required to be handled more protectively.

9.24.2(c) Public-safe data shall mean data that may be externally disclosed only after public-safe review, appropriate redaction, aggregation, generalization, boundary language, confidence and uncertainty treatment, limitation treatment, and correction path. Public-safe data may be public-facing without being unrestricted, complete, authority-bearing, finance-ready, procurement-ready, certifying, recognizing, protocol-effective, or execution-bearing.

9.24.2(d) Internal data shall mean data used within GCRI Canada or controlled Nexus interfaces for evidence, methods, observability, governance, review, assurance, training, correction, or administration, and not intended for external publication unless reclassified, reviewed, and public-safe cleared.

9.24.2(e) Confidential data shall mean data subject to confidentiality obligations, contributor restrictions, contractual restrictions, institutional restrictions, security restrictions, public authority restrictions, community restrictions, provider restrictions, sponsor restrictions, host restrictions, operator restrictions, or other limits requiring controlled handling.

9.24.2(f) Restricted data shall mean data requiring heightened access control, controlled-room treatment, no-download treatment, restricted processing, restricted routing, restricted publication, restricted AI use, restricted retention, sealing, legal hold, or other heightened safeguards because exposure may create material harm, legal risk, public-safe risk, cybersecurity risk, infrastructure risk, privacy risk, community risk, protected knowledge risk, public authority risk, finance risk, procurement risk, or institutional risk.

9.24.2(g) Public authority data shall mean data received from, generated by, requested by, reviewed by, funded by, restricted by, or materially associated with a public authority, regulator, public finance body, emergency-management actor, public health body, public safety body, public infrastructure operator, public procurement actor, public funding actor, Crown or state entity, intergovernmental body, Indigenous public governance body where applicable, or other public-sector authority, and shall preserve capacity classification, data-sharing terms, official or non-official status, permitted use, prohibited use, public-safe limits, and correction path.

9.24.2(h) Health-sensitive data shall mean data that concern, infer, relate to, or may reasonably be associated with health, health-adjacent conditions, public health context, human proximity, exposure, vulnerable persons, workplace or household health patterns, biometric-adjacent information, health facilities, health systems, health service access, or other rights-bearing human contexts, whether or not formally classified as health information under applicable law.

9.24.2(i) Cyber-sensitive data shall mean data that include or may reveal credentials, secrets, keys, tokens, authentication details, authorization details, system architecture, network topology, asset inventories, vulnerability information, exploit-sensitive information, incident telemetry, security controls, configuration details, logs, alerts, cyber telemetry, threat-intelligence-adjacent information, model or prompt security risk, source code sensitivity, cyber-physical risk, or controlled technology risk.

9.24.2(j) Infrastructure-sensitive data shall mean data that include or may reveal critical infrastructure, mission-critical systems, facility locations, service dependencies, network dependencies, outage sensitivity, degraded-mode sensitivity, physical security risk, cyber-physical vulnerabilities, logistics dependencies, corridor sensitivity, operator-sensitive information, or infrastructure exposure risk.

9.24.2(k) Finance-sensitive data shall mean data that may affect, or be misread as affecting, finance-readiness, capital-readiness, insurance-readiness, public finance, lending, underwriting, investment, ratings, guarantees, bankability, fundability, project finance, procurement, market value, host value, provider value, sponsor value, National Company materials, Project SPV materials, GRA interfaces, Nexus Rails interfaces, RNFD, NFD, UNFSD, or capital-reader contexts.

9.24.2(l) Commercially sensitive data shall mean provider, vendor, sponsor, host, operator, contractor, university, National Company, Project SPV, or other actor data containing trade secrets, commercial strategy, pricing, technical configurations, product details, benchmarking conditions, contractual information, IP-sensitive information, competitive information, procurement-sensitive information, or other materials requiring controlled commercial handling.

9.24.2(m) Personal data shall mean data relating to identified or identifiable persons, including direct identifiers, indirect identifiers, device identifiers, location patterns, household patterns, workplace patterns, movement patterns, service-use patterns, small-group identifiers, public authority interactions, community participation, health-sensitive inferences, or other rights-bearing information.

9.24.2(n) Community-protected, Indigenous, local, territorial, environmental, and protected knowledge data shall include data generated by, held by, associated with, affecting, or contextualized through communities, Indigenous peoples or governance bodies where applicable, local knowledge holders, territorial knowledge holders, environmental knowledge holders, cultural knowledge holders, protected sites, sensitive sites, sacred sites, traditional-use areas, community sensors, community records, community observations, or protected knowledge systems, and shall be governed to prevent extraction, commodification, unsafe mapping, decontextualization, re-identification, group harm, and unauthorized reuse.

9.24.2(o) Derived, aggregated, summarized, modeled, embedded, visualized, or public-safe versions of any data class shall not automatically become lower-risk. GCRI Canada shall classify derivative data according to what they can reveal, imply, enable, or be misused to support.

9.24.2(p) The controlling rule shall be that Observatory data classes must reflect real-world harm, authority meaning, public-safe meaning, rights, relationships, and correction obligations, not merely technical format or source convenience.

***

9.24.3 Lawful Basis and Authority for Observatory Data.\
9.24.3(a) GCRI Canada shall identify and record the lawful basis, authority, permission, license, consent or non-consent treatment where applicable, public authority basis, contractual basis, institutional basis, community protocol, Indigenous protocol where applicable, data-sharing term, source restriction, or other recorded authority for material Observatory data before material use.

9.24.3(b) Lawful basis and authority records shall identify data source, source actor, source capacity, data owner where known, custodian, steward, contributor, lawful basis where applicable, permission scope, license scope, public authority authority where applicable, consent scope where applicable, non-consent or restriction where applicable, permitted use, prohibited use, audience, output class, access class, handling class, publication limits, retention limits, deletion obligations, sealing obligations, archive obligations, AI-use limits, cross-border limits, correction path, and closeout obligations.

9.24.3(c) GCRI Canada shall not assume authority to use data merely because data are accessible, uploaded, shared, publicly available, open-source, open-data, scraped, machine-generated, dashboard-visible, map-visible, provider-supplied, sponsor-supported, host-provided, public authority-adjacent, community-mentioned, stored in a shared room, or technically retrievable.

9.24.3(d) Public authority data shall require recorded capacity classification, data-sharing terms, official or non-official status, public authority restrictions, publication limits, agency reference controls, public-safe treatment, non-delegation language, non-endorsement language, no-public-warning language, no-procurement language, no-funding language, no-public-finance language, and correction path.

9.24.3(e) Community, Indigenous, local, territorial, environmental, and protected knowledge data shall require recorded protocol treatment, source protection, consent or non-consent treatment where applicable, purpose limitations, mapping limits, dashboard limits, AI-use limits, publication limits, withdrawal or challenge pathways where applicable, grievance or remedy pathways where applicable, and correction path.

9.24.3(f) Provider, vendor, sponsor, host, operator, contractor, university, National Company, Project SPV, or other contributor data shall require recorded contribution terms, ownership or custody status where known, use rights, IP treatment, confidentiality, commercial sensitivity, cybersecurity sensitivity, public-safe limits, permitted claims, prohibited claims, correction obligations, and closeout obligations.

9.24.3(g) Where lawful basis, authority, permission, license, or consent treatment is unclear, incomplete, disputed, stale, exceeded, withdrawn, or inconsistent with proposed use, GCRI Canada shall restrict use, seek clarification where appropriate, reclassify the data, remove or suppress affected fields, decline publication, halt routing, delete or seal where appropriate, or refuse use.

9.24.3(h) The existence of lawful basis or permission shall not eliminate public-safe, privacy, cybersecurity, sovereign data, community safeguard, protected knowledge, public authority, finance, procurement, provider-neutrality, sponsor non-control, boundary, or correction obligations.

9.24.3(i) The controlling rule shall be that Observatory data may be used only for purposes supported by recorded authority, and recorded authority shall be interpreted narrowly where rights, safety, sovereignty, public authority meaning, protected knowledge, or public trust may be affected.

***

9.24.4 Purpose Limitation and Bounded Use.\
9.24.4(a) GCRI Canada shall use Observatory data only for recorded, lawful, public-benefit, evidence-supporting, methods-supporting, observability-supporting, public-safe, non-executing, and correctionable purposes consistent with data classification, source authority, permissions, limitations, and boundary language.

9.24.4(b) Purpose records shall identify whether data may be used for internal evidence review, source comparison, controlled-room review, Observatory methods, public authority learning, community learning, host learning, operator learning, provider-neutral review, GRF input support, GRA input support, Protocol Authority input support, Nexus Risk Management input support, Nexus Rails input support, Nexus Grid input support, Nexus Academy materials, Evidence Packs, Decision Packs, dashboards, maps, APIs, digital twins, public-good software, technical baselines, public-safe summaries, correction, assurance, renewal, archive, or closeout.

9.24.4(c) Data collected or received for one purpose shall not be reused for a materially different purpose without review of authority, permissions, public-safe status, privacy, cybersecurity, sovereign data, public authority restrictions, community safeguards, protected knowledge restrictions, provider restrictions, sponsor restrictions, host restrictions, operator restrictions, finance boundaries, procurement boundaries, AI-use limits, and correction path.

9.24.4(d) Observatory data shall not be repurposed for public authority decisions, public warnings, emergency commands, regulatory determinations, law enforcement determinations, public health orders, public safety directives, procurement decisions, finance-readiness, investment advice, lending decisions, underwriting decisions, insurance approvals, ratings, guarantees, certification, recognition, provider ranking, sponsor validation, host approval, operator instruction, market signaling, deployment approval, remediation approval, infrastructure operation, or execution by GCRI Canada.

9.24.4(e) Purpose limitation shall apply to derived outputs, including dashboards, maps, APIs, embeddings, retrieval stores, model outputs, digital twins, simulations, Evidence Packs, Decision Packs, public-safe summaries, Academy materials, public authority learning materials, GRF inputs, GRA inputs, Protocol Authority inputs, and public claims.

9.24.4(f) Where downstream actors receive Observatory data or outputs, GCRI Canada shall preserve permitted-use and prohibited-use language sufficient to prevent reuse outside the recorded purpose, including no-public-authority, no-public-warning, no-finance, no-procurement, no-certification, no-recognition, no-provider-endorsement, no-sponsor-approval, no-host-approval, no-operator-instruction, no-protocol-effect unless separately created, and no-execution language where material.

9.24.4(g) Where purpose drift is detected, GCRI Canada shall restrict use, correct records, revise access, issue clarification or notice where appropriate, delete or seal data where appropriate, withdraw affected outputs, suspend affected interfaces, update methods, and review dependencies.

9.24.4(h) The controlling rule shall be that Observatory data are not a general institutional asset; they are purpose-bound evidence materials held under public-good, safeguard, boundary, and correction duties.

***

9.24.5 Data Minimization, Necessity, Proportionality, and Least Exposure.\
9.24.5(a) GCRI Canada shall apply data minimization, necessity, proportionality, least exposure, least privilege, safe-location, aggregation, generalization, redaction, masking, delayed release, and responsible non-disclosure principles to Observatory data throughout collection, receipt, processing, storage, routing, dashboarding, mapping, modeling, publication, correction, retention, deletion, sealing, archive, and closeout.

9.24.5(b) Data minimization shall require that GCRI Canada collect, receive, retain, display, route, or publish no more data than reasonably necessary for the recorded Observatory purpose, evidence purpose, methods purpose, public-safe purpose, correction purpose, assurance purpose, or legal obligation.

9.24.5(c) Necessity review shall identify why the data are needed, why lower-risk data would not reasonably serve the purpose, why the sensitivity is proportionate, what public-good function is served, what safeguards apply, what public-safe limits apply, and how correction will be maintained.

9.24.5(d) Proportionality review shall consider the value of the data against risks to privacy, cybersecurity, sovereign data, infrastructure security, public authority meaning, community safety, protected knowledge, vulnerable persons, hosts, operators, providers, sponsors, finance-facing contexts, procurement-facing contexts, public-safe publication, and public trust.

9.24.5(e) Least exposure shall require restriction of fields, attributes, geospatial precision, timestamps, identifiers, metadata, device information, location information, small counts, health-sensitive information, cyber-sensitive information, infrastructure-sensitive information, public authority restricted information, finance-sensitive information, commercially sensitive information, protected knowledge, and other high-risk information unless necessary, lawful, recorded, safeguarded, and correctionable.

9.24.5(f) Dashboards, maps, APIs, digital twins, Evidence Packs, Decision Packs, public-safe summaries, Academy materials, public authority learning materials, GRF inputs, GRA inputs, Protocol Authority inputs, provider-facing materials, sponsor-facing materials, host-facing materials, operator-facing materials, community-facing materials, repositories, media materials, and public claims shall use the least exposed form of data adequate for the recorded purpose.

9.24.5(g) Minimization shall not be used to conceal uncertainty, contradiction, data gaps, public-safe omissions, source weakness, confidence limits, or correction status. Where data are withheld, generalized, redacted, or aggregated, the resulting limitation and uncertainty effects shall be recorded where material.

9.24.5(h) Where excessive collection, excessive retention, excessive exposure, excessive precision, excessive sharing, excessive dashboarding, excessive mapping, excessive AI use, excessive retrieval, excessive embedding, excessive public authority routing, excessive finance-facing routing, excessive provider sharing, or excessive sponsor sharing is detected, GCRI Canada shall restrict, redact, aggregate, generalize, delete, seal, correct, withdraw, or revise affected materials and dependencies as appropriate.

9.24.5(i) The controlling rule shall be that Observatory evidence shall be as informative as needed and as exposing as little as possible.

***

9.24.6 Access Controls, Role-Based Access, Logging, Time Limits, and Review.\
9.24.6(a) GCRI Canada shall maintain access controls for Observatory data based on role, purpose, data class, evidence class, output class, access class, handling class, public-safe status, privacy sensitivity, cybersecurity sensitivity, sovereign data status, public authority restrictions, infrastructure sensitivity, finance sensitivity, commercial sensitivity, community safeguards, Indigenous or protected knowledge status, legal sensitivity, export-control sensitivity, sanctions sensitivity, controlled-technology sensitivity, and correction obligations.

9.24.6(b) Access records shall identify authorized person or role, institution, interface, capacity, purpose, data or system accessed, access class, handling class, permissions granted, permissions denied, access duration, download rights, export rights, screenshot rights, API rights, copy rights, redistribution rights, publication rights, correction rights, revocation path, and reviewer.

9.24.6(c) Access shall be role-based, least-privilege, purpose-bound, logged, monitored where appropriate, time-bound where appropriate, periodically reviewed, revocable, and subject to confidentiality, privacy, cybersecurity, public-safe, sovereign data, community safeguard, protected knowledge, public authority, provider-neutrality, sponsor non-control, host-boundary, operator-boundary, and correction requirements.

9.24.6(d) Controlled rooms, data rooms, clean rooms, public authority rooms, community rooms, provider rooms, sponsor rooms, host rooms, operator rooms, compute-to-data rooms, secure enclaves, no-download rooms, dashboards, maps, APIs, repositories, model systems, retrieval systems, embedding stores, and Evidence Pack registers shall maintain access logs appropriate to risk.

9.24.6(e) Logging records shall identify access event, user or role, timestamp, system, dataset, output, action taken, download or export where any, API use where any, dashboard view where material, map view where material, correction action where any, administrative action where any, anomaly where any, and review status.

9.24.6(f) GCRI Canada shall restrict or revoke access where access is no longer necessary, time-limited authority expires, role changes, interface closes, contribution ends, consent or permission is withdrawn where applicable, public-safe classification changes, incident occurs, misuse is detected, conflict is unmanaged, sanctions or export-control issues arise, or correction requires access limitation.

9.24.6(g) Unauthorized access, excessive access, stale access, cross-tenant access, cross-program access, cross-entity access, cross-border access, role confusion, unlogged access, uncontrolled export, screenshot misuse, API misuse, retrieval misuse, embedding misuse, or public-safe breach shall be treated as an incident requiring containment, correction, review, and dependency assessment.

9.24.6(h) Access to Observatory data shall not imply endorsement, approval, delegated authority, procurement relevance, finance-readiness, certification, recognition, protocol effect, provider preference, sponsor approval, host approval, operator instruction, public warning, emergency command, operational clearance, deployment approval, or execution consequence.

9.24.6(i) The controlling rule shall be that Observatory data access is a recorded privilege for a bounded purpose, not a general right of visibility, use, reuse, publication, or authority.

***

9.24.7 Retention, Deletion, Sealing, Archival, and Legal Hold.\
9.24.7(a) GCRI Canada shall maintain retention, deletion, sealing, archival, legal hold, dependency preservation, correction preservation, and closeout methods for Observatory data consistent with legal obligations, public-benefit purpose, evidence integrity, correctionability, privacy, cybersecurity, sovereign data, public authority restrictions, community safeguards, protected knowledge restrictions, provider restrictions, sponsor restrictions, host restrictions, operator restrictions, contractual obligations, and public-safe discipline.

9.24.7(b) Retention records shall identify data title or identifier, data class, evidence class, output class, source, custodian, steward, lawful basis or authority, retention basis, retention period, review date, legal hold status, sealing status, deletion status, archive status, access limits, public-safe status, correction status, dependency status, and closeout obligations.

9.24.7(c) Data shall not be retained longer, more broadly, more accessibly, more precisely, more identifiably, more exportably, or more publicly than required for recorded purpose, lawful obligation, correctionability, assurance, dependency preservation, or legitimate archive.

9.24.7(d) Deletion records shall identify data deleted, deletion basis, deletion authority, deletion method, deletion date, systems affected, backups affected where applicable, derivative records affected where applicable, embeddings affected where applicable, retrieval indexes affected where applicable, dashboards affected where applicable, maps affected where applicable, APIs affected where applicable, public-safe outputs affected where applicable, exceptions, legal hold constraints, and continuing limitations.

9.24.7(e) Sealing records shall identify data sealed, sealing basis, access restrictions, permitted access conditions, legal hold status where applicable, public authority restrictions where applicable, community or protected knowledge restrictions where applicable, review cycle, correction implications, and archive treatment.

9.24.7(f) Archival records shall identify archived data, archive basis, archive location, archive class, access limits, public-safe status, privacy status, cybersecurity status, sovereign data status, protected knowledge status, public authority status, retention period, legal hold status, citation status, correction status, supersession status, withdrawal status where applicable, retraction status where applicable, and continuing prohibited uses.

9.24.7(g) Legal hold shall suspend deletion or alteration only to the extent required by law, dispute, audit, investigation, governance, correction, or other recorded obligation, and shall not create authority to expand use, publication, routing, AI processing, dashboarding, mapping, provider sharing, sponsor sharing, finance-facing routing, procurement-facing routing, or public authority use.

9.24.7(h) Where retention, deletion, sealing, archive, or legal hold treatment affects public-safe outputs, Evidence Packs, Decision Packs, dashboards, maps, APIs, GRF inputs, GRA inputs, Protocol Authority inputs, public authority learning materials, community materials, provider materials, sponsor materials, host materials, operator materials, Academy materials, repositories, media materials, or public claims, GCRI Canada shall update affected records and issue dependency notices or correction notices where appropriate.

9.24.7(i) The controlling rule shall be that Observatory data must remain available long enough to support integrity and correction, but not so available that retention becomes exposure, drift, or misuse.

***

9.24.8 Cross-Border Transfer and Sovereign Data Review.\
9.24.8(a) GCRI Canada shall apply cross-border transfer, sovereign data, data residency, localization, jurisdiction, compute location, provider location, access location, public authority restriction, community restriction, Indigenous data sovereignty where applicable, protected knowledge restriction, cybersecurity, export-control, sanctions, controlled-technology, and public-safe review before Observatory data are transferred, accessed, processed, stored, backed up, retrieved, embedded, trained on, vendor-processed, dashboarded, mapped, API-exposed, or routed across jurisdictions.

9.24.8(b) Cross-border records shall identify source jurisdiction, receiving jurisdiction, data class, evidence class, output class, public authority status, privacy status, cybersecurity status, sovereign data status, protected knowledge status, community status, infrastructure-sensitive status, export-control sensitivity, sanctions sensitivity, controlled-technology sensitivity, transfer purpose, transfer mechanism, receiving party, provider, custodian, compute environment, access class, handling class, permitted use, prohibited use, retention, deletion, sealing, archive, and correction path.

9.24.8(c) Sovereign data review shall identify whether data are required or expected to remain within a country, province, territory, region, community-controlled environment, Indigenous-governed environment where applicable, public authority environment, sovereign cloud, secure enclave, confidential computing environment, compute-to-data environment, air-gapped environment, no-download room, or other restricted environment.

9.24.8(d) Compute-to-data treatment shall be preferred for restricted, sovereign-sensitive, public authority, health-sensitive, infrastructure-sensitive, cyber-sensitive, community-protected, Indigenous, protected knowledge, or other high-risk materials where transfer would create unnecessary exposure.

9.24.8(e) GCRI Canada shall not transfer or permit access to Observatory data across borders merely because a platform, provider, dashboard, AI tool, repository, model, analytics environment, cloud service, or contractor workflow makes such transfer technically convenient.

9.24.8(f) Cross-border access by providers, vendors, sponsors, hosts, operators, public authorities, universities, National Companies, Project SPVs, GRF, GRA, Protocol Authority, Nexus bodies, or other actors shall be recorded, purpose-bound, access-controlled, lawful, public-safe, correctionable, and subject to the most protective applicable data and boundary treatment.

9.24.8(g) Where cross-border transfer or sovereign data review identifies unacceptable risk, GCRI Canada shall restrict transfer, use local processing, use sovereign compute, use compute-to-data, use secure enclaves, use controlled-room review, generalize outputs, redact data, delay release, refuse use, delete or seal data where appropriate, or update interface terms.

9.24.8(h) Where unauthorized cross-border transfer, access, storage, backup, retrieval, embedding, AI processing, vendor processing, dashboarding, mapping, or API exposure occurs, GCRI Canada shall contain the transfer, restrict access, correct records, notify affected interfaces where required, delete or seal where appropriate, review affected outputs, and update controls.

9.24.8(i) The controlling rule shall be that Observatory data sovereignty is not satisfied by aspiration; it requires recorded location, jurisdiction, access, compute, transfer, restriction, and correction controls.

***

9.24.9 AI-Use Restrictions for Observatory Data.\
9.24.9(a) GCRI Canada shall apply AI-use restrictions to Observatory data before any use in AI, machine learning, statistical modeling, generative AI, agentic AI, retrieval-augmented generation, embeddings, fine-tuning, training, model improvement, classification, forecasting, simulation, digital twins, automated summarization, automated translation, entity extraction, anomaly detection, or other model-mediated processing.

9.24.9(b) AI-use records shall identify data source, data class, evidence class, output class, lawful basis or authority, permission scope, AI use purpose, model identity, model version, provider, compute environment, retrieval source, embedding store where any, training or fine-tuning status where any, access class, handling class, public-safe status, privacy status, cybersecurity status, sovereign data status, public authority status, community-protected status, Indigenous or protected knowledge status, export-control status, sanctions status, controlled-technology status, human review requirement, output review requirement, retention, deletion, sealing, and correction path.

9.24.9(c) Sensitive Nexus, GCRI Canada, public authority, personal, health-sensitive, cyber-sensitive, infrastructure-sensitive, community-protected, Indigenous, protected knowledge, confidential, commercially sensitive, restricted, finance-sensitive, procurement-sensitive, controlled-technology, export-sensitive, sanctions-sensitive, or sovereign-sensitive Observatory data shall not be used for AI training, fine-tuning, model improvement, embedding, retrieval, vendor AI processing, public AI tools, or agentic processing without express recorded authority, safeguards, public-safe review, and deletion or containment paths where applicable.

9.24.9(d) Public AI tools shall not receive Observatory data unless the data are cleared for that specific tool, purpose, audience, retention condition, vendor-processing condition, model-improvement condition, cross-border condition, public-safe status, and correction path. Public availability of data shall not by itself authorize public AI tool processing.

9.24.9(e) Retrieval and embedding uses shall identify approved sources, prohibited sources, source classification, embedding store ownership, custody, access controls, encryption, logging, deletion, cross-tenant risks, cross-program risks, cross-entity risks, cross-border risks, retrieval leakage risks, context-collapse risks, false association risks, protected knowledge risks, and correction path.

9.24.9(f) Agentic AI use involving Observatory data shall require tool permission mapping, prohibited action controls, approval gates for external communication, publication, data movement, code execution, repository changes, contractual acts, public authority contact, financial references, security changes, and deletion, together with kill switches, suspension powers, logs, monitoring, sandboxing, least privilege, and incident paths.

9.24.9(g) AI outputs based on Observatory data shall not create truth by default, official decisions, public warnings, public authority meaning, finance-readiness, investment advice, ratings, insurance approvals, lending decisions, certifications, recognitions, maturity records, protocol effects, procurement approvals, provider preferences, sponsor approvals, host approvals, operator instructions, operational clearances, deployment approvals, or execution consequences.

9.24.9(h) Where unauthorized AI use, retrieval leakage, embedding leakage, model improvement misuse, public AI tool misuse, agentic misuse, hallucination, unsafe output, bias, discrimination, protected knowledge exposure, public authority confusion, finance overclaim, procurement implication, provider preference, sponsor validation, host approval implication, or correction failure occurs, GCRI Canada shall contain the incident, restrict access, correct records, delete or seal affected data where appropriate, withdraw affected outputs, notify affected interfaces where required, update model or retrieval controls, and review dependencies.

9.24.9(i) The controlling rule shall be that Observatory data may be used with AI only when the data’s authority, sensitivity, purpose, model context, human review, public-safe status, and correction path are recorded before the model acts on it.

***

9.24.10 Observatory Data Records and Data Protection Impact Review.\
9.24.10(a) GCRI Canada shall maintain, or cause to be maintained, Observatory data records and data protection impact review records for material Observatory datasets, data sources, data flows, data rooms, clean rooms, controlled rooms, compute-to-data environments, sovereign compute environments, dashboards, maps, APIs, Evidence Packs, Decision Packs, model systems, retrieval systems, embedding stores, AI uses, public authority interfaces, community interfaces, provider interfaces, sponsor interfaces, host interfaces, operator interfaces, cross-border transfers, retention decisions, deletion decisions, sealing decisions, archive decisions, incidents, corrections, dependencies, assurance reviews, renewal, and closeout events.

9.24.10(b) Observatory data records shall identify data title or identifier, source, source authority, owner where known, custodian, steward, contributor, lawful basis or authority, license, permissions, consent or non-consent treatment where applicable, data class, evidence class, output class, access class, handling class, public-safe status, privacy status, cybersecurity status, sovereign data status, infrastructure-sensitive status, public authority status, health-sensitive status, finance-sensitive status, commercially sensitive status, provider-sensitive status, sponsor-sensitive status, host-sensitive status, operator-sensitive status, community-protected status, Indigenous or protected knowledge status, legal sensitivity, export-control sensitivity, sanctions sensitivity, controlled-technology sensitivity, permitted uses, prohibited uses, publication limits, AI-use limits, cross-border limits, retention, deletion, sealing, archive, legal hold, and correction path.

9.24.10(c) Data flow records shall identify collection, receipt, transformation, aggregation, redaction, generalization, modeling, embedding, retrieval, dashboarding, mapping, API exposure, Evidence Pack inclusion, Decision Pack inclusion, public-safe summarization, public authority routing, GRF routing, GRA routing, Protocol Authority routing, provider routing, sponsor routing, host routing, operator routing, community routing, vendor processing, cross-border transfer, retention, deletion, sealing, archive, correction, and closeout.

9.24.10(d) Data protection impact review shall be required for high-risk or material Observatory data uses, including uses involving personal data, health-sensitive data, cyber-sensitive data, infrastructure-sensitive data, public authority data, sovereign-sensitive data, community-protected data, Indigenous or protected knowledge, vulnerable communities, precise location, AI processing, retrieval or embedding, public dashboards, maps, APIs, cross-border transfer, provider processing, sponsor access, finance-facing routing, procurement-facing routing, or public-safe publication.

9.24.10(e) Data protection impact review records shall identify processing purpose, necessity, proportionality, data minimization, lawful basis, permissions, data rights, public authority restrictions, community safeguards, protected knowledge safeguards, privacy risks, cybersecurity risks, sovereign data risks, infrastructure risks, public-safe risks, finance-boundary risks, procurement-boundary risks, provider-neutrality risks, sponsor non-control risks, host-boundary risks, operator-boundary risks, cross-border risks, AI-use risks, re-identification risks, group harm risks, mitigation, residual risk, reviewer, approval or restriction status, correction path, and review cycle.

9.24.10(f) Data incident records shall identify unauthorized access, unauthorized disclosure, misclassification, excessive collection, excessive retention, unlawful or unauthorized use, public-safe failure, privacy incident, cyber incident, infrastructure exposure, public authority data misuse, community safeguard breach, protected knowledge exposure, cross-border defect, AI-use defect, retrieval leakage, embedding leakage, dashboard exposure, map exposure, API exposure, provider misuse, sponsor misuse, host misuse, operator misuse, finance overclaim, procurement implication, correction failure, containment, notices, remediation, and dependency review.

9.24.10(g) Data correction records shall identify corrected source, corrected data class, corrected evidence class, corrected output class, corrected lawful basis, corrected permission, corrected consent or non-consent treatment, corrected access class, corrected handling class, corrected public-safe status, corrected AI-use status, corrected cross-border status, corrected retention status, corrected deletion status, corrected sealing status, corrected archive status, corrected dashboard, corrected map, corrected API, corrected Evidence Pack, corrected Decision Pack, corrected public-safe output, corrected public authority reference, corrected provider reference, corrected sponsor reference, corrected host reference, corrected operator reference, corrected community reference, corrected protected knowledge treatment, corrected boundary language, prior status, corrected status, effective date, reviewer, affected dependencies, notice decision, access change, archive treatment, and continuing limitations.

9.24.10(h) Observatory data records shall be linked, where applicable, to National Dense Core records, Regional Observatory Cluster records, Cluster records, Hub records, Node records, Hotspot records, host readiness records, maturity evidence records, Observatory Evidence Pack Register entries, AI-RAN records, DePIN records, sensor records, geospatial records, cyber telemetry records, digital twin records, dashboard records, degraded-mode records, sovereign compute records, public authority interface records, community interface records, provider and sponsor interface records, Observatory Methods Register entries, Evidence Register entries, Source Comparison Records, Dataset Register entries, Model Register entries, System Card entries, Benchmark Card entries, Compute Workload Records, Compute Environment Records, Inference Records, Human Review Records, Retrieval and Embedding Records, Proof Receipt Records, Public-Safe Output Records, AI Incident Records, Correction Records, Dependency Records, Truth Engine Records, Nexus Risk Management records, GRF interface records, GRA interface records, Protocol Authority interface records, RNFD records, Nexus Rails records, Regional Nexus Consortium records, National Nexus Consortium records, National Company records, Project SPV records, operator records, provider records, sponsor records, host records, community records, university records, Nexus interface records, and public claims records.

9.24.10(i) Observatory data records, data protection impact review records, data flow records, incident records, correction records, supersession records, withdrawal records, retraction records, retention records, deletion records, sealing records, archive records, legal hold records, notices, assurance, renewal, and closeout shall not create certification, recognition, finance-readiness, public authority decision, regulatory finding, procurement approval, funding approval, public finance approval, provider endorsement, sponsor approval, host approval, operator approval, community consent, Indigenous consent, rating, guarantee, public warning, emergency command, protocol effect, operational clearance, legal status, market authority, infrastructure operation, remediation approval, deployment approval, national authority, regional authority, GRF maturity record, GRA finance-readiness, or execution consequence by default.

9.24.10(j) The controlling rule shall be that Observatory data governance is valid only when classification, authority, purpose, minimization, access, retention, sovereignty, AI use, impact review, incidents, corrections, and dependencies remain recorded with enough precision to protect people, communities, public authorities, systems, markets, knowledge, and public trust.

### 9.25 Observatory Cybersecurity

9.25.1 Observatory Cybersecurity Baseline.\
9.25.1(a) GCRI Canada shall steward Observatory cybersecurity methods as a baseline evidence-protection, system-protection, data-protection, public-safe, sovereignty-compatible, records-valid, correctionable, and non-executing control domain for Observatory systems, including Nodes, Hubs, Clusters, Hotspots, Regional Observatory Clusters, National Dense Nexus Cores, sovereign compute environments, controlled rooms, data rooms, clean rooms, no-download rooms, dashboards, maps, APIs, repositories, sensors, reference sensors, AI-RAN systems, O-RAN systems, private wireless systems, DePIN systems, cyber telemetry systems, geospatial systems, digital twins, model systems, retrieval systems, embedding stores, public-good software, Evidence Packs, Decision Packs, public-safe outputs, public authority interfaces, community interfaces, provider interfaces, sponsor interfaces, host interfaces, operator interfaces, correction systems, and assurance systems.

9.25.1(b) Observatory cybersecurity methods shall protect confidentiality, integrity, availability, authenticity, accountability, resilience, least privilege, source lineage, custody, public-safe publication, correctionability, privacy, sovereign data, public authority restrictions, infrastructure-sensitive information, health-sensitive information, cyber-sensitive information, finance-sensitive information, commercially sensitive information, community-protected information, Indigenous or protected knowledge, credentials, keys, tokens, secrets, repositories, logs, models, datasets, dashboards, maps, APIs, and evidence records.

9.25.1(c) Observatory cybersecurity shall be treated as a protective and evidentiary discipline, not as security certification, security rating, managed security service, infrastructure operation, incident command, public warning, regulatory determination, public authority decision, procurement approval, finance-readiness, provider endorsement, sponsor approval, host approval, operator approval, protocol effect, deployment approval, operational clearance, market authority, legal status, or execution consequence by default.

9.25.1(d) GCRI Canada’s stewardship of Observatory cybersecurity methods shall not make GCRI Canada a cybersecurity operator, security operations centre, managed security service provider, public authority, regulator, law enforcement body, emergency-management actor, public warning issuer, critical infrastructure operator, telecommunications operator, procurement actor, finance actor, certification body, Protocol Authority, provider, sponsor, host, operator, National Company, Project SPV, or execution actor by default.

9.25.1(e) Observatory cybersecurity methods shall be risk-based, context-aware, data-class-aware, evidence-class-aware, access-class-aware, handling-class-aware, public-safe-aware, privacy-aware, cyber-sensitive-aware, infrastructure-sensitive-aware, public-authority-aware, community-safeguard-aware, protected-knowledge-aware, sovereign-data-aware, export-control-aware, sanctions-aware, controlled-technology-aware, provider-neutral, sponsor-independent, host-bounded, operator-bounded, and correctionable.

9.25.1(f) Cybersecurity controls shall be proportionate to the sensitivity and consequence of the system, data, evidence, actor, interface, jurisdiction, dependency, output, public-safe risk, and misuse risk, and shall be heightened where Observatory materials involve public authority systems, critical infrastructure, cyber telemetry, vulnerabilities, incident records, personal data, health-sensitive data, precise location, protected knowledge, sovereign data, finance-sensitive data, or controlled technology.

9.25.1(g) Cybersecurity controls shall not be used to conceal evidence weakness, source uncertainty, public-safe defects, provider influence, sponsor influence, host control, operator control, public authority ambiguity, finance overclaim, procurement implication, certification implication, recognition implication, protocol implication, or correction obligations.

9.25.1(h) The controlling rule shall be that Observatory cybersecurity exists to protect evidence, systems, people, communities, public authorities, infrastructure, knowledge, and public trust, while preserving GCRI Canada’s non-executing role.

***

9.25.2 Identity and Access Management.\
9.25.2(a) GCRI Canada shall maintain identity and access management methods for Observatory systems to ensure that access to data, dashboards, maps, APIs, repositories, compute environments, rooms, Evidence Packs, Decision Packs, public-safe outputs, logs, models, datasets, sensors, AI-RAN records, DePIN records, cyber telemetry records, correction records, and registers is authorized, role-based, purpose-bound, least-privilege, logged, reviewable, revocable, and correctionable.

9.25.2(b) Identity records shall identify authorized person, role, institution, interface, capacity, affiliation, access sponsor where any, authority basis, onboarding status, verification status, conflict status where material, confidentiality status, training status where required, data class access, evidence class access, output class access, access class, handling class, public-safe status, permitted systems, prohibited systems, permitted actions, prohibited actions, access duration, review cycle, and revocation path.

9.25.2(c) Access methods shall distinguish internal GCRI Canada users, directors, officers, employees, contractors, vendors, providers, sponsors, hosts, operators, public authority participants, community participants, Indigenous or protected knowledge reviewers where applicable, university participants, National Company participants, Project SPV participants, GRF participants, GRA participants, Protocol Authority participants, Nexus entity participants, Academy participants, and public users.

9.25.2(d) Access shall be granted only for a recorded purpose and shall be limited by role, need, sensitivity, data class, evidence class, public-safe status, room rules, interface agreement, lawful basis, data-sharing terms, public authority restrictions, community safeguards, protected knowledge restrictions, provider restrictions, sponsor restrictions, host restrictions, operator restrictions, cross-border limits, export-control limits, sanctions limits, controlled-technology limits, and correction obligations.

9.25.2(e) GCRI Canada shall require strong authentication, role-based access, least privilege, administrative privilege control, privileged access review, account lifecycle management, joiner-mover-leaver controls, access expiration where appropriate, session controls where appropriate, device controls where appropriate, and revocation for expired, excessive, stale, compromised, misused, or unnecessary access.

9.25.2(f) Shared accounts, uncontrolled administrative accounts, unlogged access, excessive privileges, permanent access without review, cross-room access by convenience, public authority role confusion, provider over-access, sponsor over-access, host over-access, operator over-access, contractor over-access, community material over-access, protected knowledge over-access, and public-safe output bypass shall be prohibited unless a recorded exception is approved, time-limited, monitored, and corrected.

9.25.2(g) Access to Observatory systems shall not imply endorsement, approval, delegated authority, procurement relevance, finance-readiness, certification, recognition, protocol effect, provider preference, sponsor approval, host approval, operator instruction, public warning, emergency command, operational clearance, deployment approval, or execution consequence.

9.25.2(h) Where identity or access management defects are detected, GCRI Canada shall contain the defect, revoke or restrict access, correct records, review logs, notify affected interfaces where required, delete or seal improperly accessed materials where appropriate, withdraw affected outputs where necessary, and update controls.

9.25.2(i) The controlling rule shall be that every Observatory access right must have a person or role, a purpose, a boundary, a record, a review cycle, and a revocation path.

***

9.25.3 Segmentation, Environment Separation, and Least Privilege.\
9.25.3(a) GCRI Canada shall steward segmentation, environment separation, and least privilege methods for Observatory systems to prevent unauthorized lateral movement, uncontrolled data mixing, cross-tenant exposure, cross-program exposure, cross-entity exposure, cross-border exposure, public-safe bypass, public authority confusion, provider overreach, sponsor overreach, host overreach, operator overreach, community safeguard breach, and protected knowledge exposure.

9.25.3(b) Environment separation shall distinguish, where appropriate, public environments, public-safe environments, internal environments, confidential environments, restricted environments, public authority environments, community environments, provider environments, sponsor environments, host environments, operator environments, development environments, test environments, staging environments, production environments, research environments, sandbox environments, model environments, retrieval environments, embedding environments, compute-to-data environments, secure enclaves, confidential computing environments, air-gapped environments, and no-download rooms.

9.25.3(c) Segmentation methods shall identify system boundaries, data boundaries, evidence boundaries, jurisdictional boundaries, sovereign data boundaries, public authority boundaries, community safeguard boundaries, protected knowledge boundaries, provider boundaries, sponsor boundaries, host boundaries, operator boundaries, finance-facing boundaries, procurement-facing boundaries, public-safe publication boundaries, and correction boundaries.

9.25.3(d) Least privilege shall apply to users, systems, services, APIs, dashboards, maps, repositories, compute workloads, model systems, retrieval systems, embedding stores, sensors, AI-RAN components, DePIN components, cyber telemetry systems, data rooms, clean rooms, public authority rooms, community rooms, provider rooms, sponsor rooms, host rooms, operator rooms, and automated or agentic tools.

9.25.3(e) GCRI Canada shall prevent uncontrolled movement of restricted data, public authority data, health-sensitive data, cyber-sensitive data, infrastructure-sensitive data, finance-sensitive data, commercially sensitive data, personal data, community-protected data, Indigenous data where applicable, protected knowledge, credentials, secrets, keys, tokens, vulnerability details, incident telemetry, precise location, and controlled technology into lower-classified or less-protected environments.

9.25.3(f) Development, testing, demonstration, training, public-safe publication, Academy use, provider demonstration, sponsor presentation, host briefing, public authority briefing, community review, finance-facing review, and media use shall not use live, restricted, identifiable, cyber-sensitive, infrastructure-sensitive, protected knowledge, or public authority restricted data unless expressly recorded, minimized, safeguarded, and necessary.

9.25.3(g) Segmentation defects, environment mixing, permission bleed, cross-tenant leakage, cross-program leakage, cross-border leakage, retrieval leakage, embedding leakage, dashboard leakage, API leakage, map leakage, repository leakage, or public-safe bypass shall be treated as incidents requiring containment, correction, review, dependency assessment, and control updates.

9.25.3(h) Segmentation and least privilege records shall not create certification, security rating, public authority approval, procurement approval, finance-readiness, provider endorsement, sponsor approval, host approval, operational clearance, protocol effect, or execution consequence by default.

9.25.3(i) The controlling rule shall be that Observatory systems must be separated according to risk, purpose, role, jurisdiction, and sensitivity, because evidence protection fails when all rooms become one room.

***

9.25.4 Logging, Monitoring, Security Telemetry, and Incident Detection.\
9.25.4(a) GCRI Canada shall maintain logging, monitoring, security telemetry, anomaly detection, incident detection, audit trail, and review methods for Observatory systems proportionate to data class, evidence class, access class, handling class, system sensitivity, public-safe risk, cybersecurity risk, infrastructure risk, public authority risk, community safeguard risk, protected knowledge risk, finance risk, procurement risk, provider risk, sponsor risk, host risk, operator risk, cross-border risk, and correction dependency.

9.25.4(b) Logging methods shall record, where appropriate, identity events, access events, authentication events, authorization events, administrative actions, data access, data export, dashboard views where material, map views where material, API calls, repository changes, compute workload execution, model use, retrieval events, embedding events, inference events, agentic actions, sensor access, AI-RAN access, DePIN access, cyber telemetry access, public-safe publication events, correction events, deletion events, sealing events, archival events, and closeout events.

9.25.4(c) Monitoring methods shall identify anomalous access, excessive access, privilege escalation, unusual downloads, unusual exports, suspicious API use, cross-border access anomalies, cross-room anomalies, public authority data anomalies, protected knowledge access anomalies, cyber-sensitive data anomalies, infrastructure-sensitive data anomalies, model-use anomalies, retrieval leakage indicators, embedding leakage indicators, repository anomalies, dashboard misuse, map misuse, credential misuse, key misuse, token misuse, and incident signals.

9.25.4(d) Security telemetry records shall identify telemetry source, system class, environment, timestamp, event type, identity or role where appropriate, action, outcome, severity where used, affected data class, affected evidence class, public-safe status, confidence, uncertainty, limitations, retention, access restrictions, and correction path.

9.25.4(e) Incident detection methods shall distinguish false positives, suspected incidents, confirmed incidents, near misses, policy violations, access anomalies, data incidents, cyber incidents, public-safe incidents, AI incidents, repository incidents, dashboard incidents, API incidents, sensor incidents, provider incidents, sponsor incidents, host incidents, operator incidents, public authority interface incidents, community safeguard incidents, protected knowledge incidents, and correction failures.

9.25.4(f) Logging and monitoring shall be designed to support accountability and correction without creating unnecessary surveillance, excessive retention, unsafe exposure, protected knowledge exposure, public authority confusion, provider misuse, sponsor misuse, host misuse, operator misuse, finance overclaim, procurement implication, or public-safe harm.

9.25.4(g) Security telemetry and incident labels shall not be presented as public warnings, emergency commands, regulatory findings, law enforcement findings, security certifications, provider ratings, finance signals, procurement signals, public authority decisions, operational clearances, or execution instructions by default.

9.25.4(h) Where logging or monitoring is incomplete, disabled, misconfigured, excessive, over-retained, under-retained, insecure, inaccessible for correction, public-safe defective, or itself a privacy or protected knowledge risk, GCRI Canada shall correct the logging method, update access controls, revise retention, restrict exposure, and review affected evidence dependencies.

9.25.4(i) The controlling rule shall be that Observatory security events must be visible enough to protect systems and records, but not so exposed that monitoring becomes a new source of harm.

***

9.25.5 Vulnerability Management, Patch Management, Exposure Reduction, and Secure Configuration.\
9.25.5(a) GCRI Canada shall steward vulnerability management, patch management, exposure reduction, secure configuration, hardening, dependency review, secure deployment, change control, and corrective action methods for Observatory systems and supporting environments.

9.25.5(b) Vulnerability management records shall identify affected system, component, repository, dashboard, API, sensor, AI-RAN component, DePIN component, compute environment, model system, retrieval system, embedding store, data room, clean room, controlled room, public authority room, community room, provider system, sponsor system, host system, operator system, severity method where used, exploitability context where safe, affected data classes, affected evidence classes, public-safe risk, mitigation status, patch status, compensating controls, residual risk, reviewer, correction path, and closeout status.

9.25.5(c) Patch management methods shall identify patch source, affected system, version, dependency, urgency, testing status, deployment status, rollback path, downtime implications, degraded-mode implications, evidence-flow implications, dashboard implications, API implications, public-safe implications, public authority interface implications, provider interface implications, host interface implications, operator interface implications, and correction dependencies.

9.25.5(d) Exposure reduction shall address open ports, public endpoints, API exposure, dashboard exposure, repository exposure, credential exposure, metadata exposure, precise location exposure, vulnerability detail exposure, cyber telemetry exposure, infrastructure-sensitive exposure, public authority data exposure, protected knowledge exposure, cloud exposure, cross-border exposure, third-party access, excessive permissions, and unnecessary data replication.

9.25.5(e) Secure configuration methods shall identify baseline configuration, approved deviations, configuration owner, configuration custodian, configuration changes, configuration review, insecure defaults, logging settings, access settings, encryption settings, network settings, API settings, dashboard settings, repository settings, model settings, retrieval settings, embedding settings, sensor settings, compute settings, key settings, token settings, secret settings, backup settings, and decommissioning settings.

9.25.5(f) GCRI Canada shall not publicly disclose vulnerability details, exploit details, unpatched conditions, insecure configurations, topology-sensitive information, operator-sensitive information, host-sensitive information, provider-sensitive information, public authority system information, cyber-sensitive evidence, or infrastructure-sensitive evidence except through recorded coordinated disclosure, responsible non-disclosure, controlled notice, or public-safe publication methods.

9.25.5(g) Where vulnerabilities, patch failures, exposure defects, or insecure configurations affect evidence integrity, dashboard accuracy, public-safe status, public authority interfaces, community safeguards, provider neutrality, sponsor non-control, host boundaries, operator boundaries, finance boundaries, procurement boundaries, or correctionability, GCRI Canada shall restrict, correct, supersede, withdraw, or reissue affected outputs as appropriate.

9.25.5(h) Vulnerability or patch records shall not create security certification, compliance determination, regulatory finding, public authority approval, procurement approval, finance-readiness, provider endorsement, sponsor approval, host approval, operational clearance, remediation approval, public warning, emergency command, protocol effect, or execution consequence by default.

9.25.5(i) The controlling rule shall be that Observatory vulnerabilities must be managed as evidence integrity risks and public-safe risks, not as marketing claims, authority claims, or execution triggers.

***

9.25.6 Repository, API, Dashboard, Sensor, Edge, AI-RAN, DePIN, and Compute Security.\
9.25.6(a) GCRI Canada shall maintain security methods for repositories, APIs, dashboards, maps, visualization systems, sensors, reference sensors, edge devices, edge compute, AI-RAN systems, O-RAN systems, private wireless systems, DePIN devices, cyber telemetry systems, digital twin systems, model systems, retrieval systems, embedding stores, compute workloads, compute environments, sovereign compute environments, secure enclaves, confidential computing environments, air-gapped environments, controlled rooms, data rooms, clean rooms, and no-download rooms used in Observatory systems.

9.25.6(b) Repository security methods shall address repository access, branch protection, commit review, signed commits where appropriate, dependency review, secret scanning, credential prevention, code review, issue and pull request hygiene, release controls, license controls, public/private repository classification, public-good software publication controls, vulnerability disclosure, and correction paths.

9.25.6(c) API security methods shall address authentication, authorization, rate limits, input validation, output validation, logging, monitoring, schema control, data minimization, field suppression, public-safe filtering, export controls, versioning, deprecation, misuse detection, cross-origin controls where applicable, token controls, error-message safety, and correction paths.

9.25.6(d) Dashboard and map security methods shall address access control, public-safe filtering, export restrictions, screenshot risk, embedding risk, cache risk, stale-data risk, drill-down risk, unsafe metadata, unsafe geospatial precision, boundary language, versioning, misuse detection, correction notices, withdrawal status, and archive treatment.

9.25.6(e) Sensor and edge security methods shall address device identity, custody, calibration integrity, firmware integrity, configuration integrity, physical tamper risk, spoofing risk, replay risk, location spoofing, timing integrity, secure update, secure logging, communications security, edge data minimization, degraded-mode capture, and correction paths.

9.25.6(f) AI-RAN, O-RAN, private wireless, and telecommunications-adjacent security methods shall address network access, signal integrity, telemetry sensitivity, metadata sensitivity, location sensitivity, public authority sensitivity, infrastructure sensitivity, provider role, operator role, edge intelligence security, interference risk, spoofing risk, cyber-physical dependency risk, and public-safe disclosure limits.

9.25.6(g) DePIN security methods shall address device identity, hardware identity, location claims, uptime claims, coverage claims, capacity claims, service claims, ledger relationships, token relationships where any, proof integrity, spoof detection, tamper detection, fraud detection, incentive manipulation, privacy risk, location risk, and no-token-as-authority boundary.

9.25.6(h) Compute security methods shall address approved environments, workload identity, environment identity, jurisdiction, provider, custodian, access controls, isolation, logging, monitoring, encryption, key management, confidential computing where appropriate, secure enclave use where appropriate, air-gap use where appropriate, compute-to-data treatment, backup, disaster recovery, decommissioning, and output review.

9.25.6(i) Security of repositories, APIs, dashboards, sensors, edge systems, AI-RAN systems, DePIN systems, or compute environments shall not create certification, recognition, finance-readiness, public authority approval, procurement approval, security rating, provider endorsement, sponsor approval, host approval, operator approval, protocol effect, operational clearance, deployment approval, infrastructure operation, public warning, emergency command, or execution consequence by default.

9.25.6(j) The controlling rule shall be that every Observatory technical surface is also a trust surface, and therefore must be secured, logged, bounded, public-safe, and correctable.

***

9.25.7 Key Management, Token Management, Secrets Management, and Credential Controls.\
9.25.7(a) GCRI Canada shall maintain key management, token management, secrets management, credential controls, certificate controls, signing controls, encryption controls, rotation controls, revocation controls, storage controls, access controls, audit controls, and incident controls for Observatory systems.

9.25.7(b) Key records shall identify key purpose, key owner, custodian, environment, data class, evidence class, system class, access class, handling class, generation method, storage method, rotation schedule, revocation path, backup treatment, recovery treatment, signing use where any, encryption use where any, public-safe implications, and closeout obligations.

9.25.7(c) Token and credential records shall identify token or credential purpose, issuer, owner, custodian, scope, permitted systems, prohibited systems, access class, expiration, rotation, storage, use limits, logging, revocation path, and incident path.

9.25.7(d) Secrets management methods shall prohibit hard-coded credentials, unmanaged secrets, shared secrets without recorded exception, secrets in public repositories, secrets in logs, secrets in prompts, secrets in dashboards, secrets in maps, secrets in screenshots, secrets in public-safe outputs, secrets in vendor materials, secrets in sponsor materials, secrets in provider materials, secrets in host materials, secrets in public authority materials, and secrets in Academy materials.

9.25.7(e) Signing, hashing, timestamping, proof receipt, and tamper-evidence methods shall be used where appropriate to support integrity, lineage, reproducibility, correction, supersession, withdrawal, retraction, and archive, but shall not convert records into authority, certification, recognition, finance-readiness, public authority decision, procurement approval, protocol effect, or execution consequence by default.

9.25.7(f) Key, token, secret, or credential access shall be least-privilege, time-bound where appropriate, logged, reviewed, revocable, and separated from sponsor, provider, host, operator, public authority, community, contractor, and public users except where expressly authorized and recorded for a specific purpose.

9.25.7(g) Compromised, suspected compromised, exposed, stale, excessive, orphaned, shared, misused, or improperly stored keys, tokens, secrets, or credentials shall be revoked, rotated, contained, investigated, corrected, and dependency-reviewed.

9.25.7(h) Where key, token, secret, credential, signing, hashing, timestamping, or proof receipt defects affect Observatory outputs, Evidence Packs, dashboards, maps, APIs, compute records, model records, public-safe outputs, GRF inputs, GRA inputs, Protocol Authority inputs, public authority materials, community materials, provider materials, sponsor materials, host materials, operator materials, or public claims, GCRI Canada shall correct, restrict, supersede, withdraw, reissue, or notify affected interfaces as appropriate.

9.25.7(i) The controlling rule shall be that credentials and cryptographic controls protect evidence integrity only when they are themselves governed as sensitive evidence.

***

9.25.8 Incident Response, Containment, Recovery, Notification, and Post-Incident Review.\
9.25.8(a) GCRI Canada shall maintain Observatory cybersecurity incident response methods for identifying, classifying, containing, investigating, correcting, recovering from, notifying where required, reviewing, learning from, and closing out cybersecurity incidents affecting Observatory systems, data, evidence, dashboards, maps, APIs, repositories, sensors, AI-RAN systems, DePIN systems, compute environments, model systems, public authority interfaces, community interfaces, provider interfaces, sponsor interfaces, host interfaces, operator interfaces, public-safe outputs, and correction systems.

9.25.8(b) Cybersecurity incidents may include unauthorized access, credential compromise, key compromise, token compromise, secrets exposure, malware, ransomware, phishing, social engineering, vulnerability exploitation, repository compromise, API compromise, dashboard compromise, map compromise, sensor spoofing, sensor tampering, telemetry tampering, AI-RAN compromise, DePIN compromise, compute compromise, model compromise, retrieval leakage, embedding leakage, data exfiltration, public-safe disclosure failure, cross-border transfer defect, protected knowledge exposure, public authority data exposure, infrastructure-sensitive exposure, provider misuse, sponsor misuse, host misuse, operator misuse, and correction failure.

9.25.8(c) Incident classification records shall identify incident title or identifier, detection source, affected systems, affected data classes, affected evidence classes, affected output classes, affected interfaces, suspected or confirmed status, severity where used, confidence, uncertainty, public-safe status, containment status, legal status where material, notification status, correction path, recovery path, residual risk, and closeout status.

9.25.8(d) Containment methods may include access revocation, credential rotation, key revocation, token revocation, system isolation, environment shutdown, dashboard restriction, API restriction, repository restriction, sensor isolation, compute suspension, model suspension, retrieval suspension, embedding store restriction, data-room closure, clean-room restriction, controlled-room restriction, public-safe output withdrawal, interface suspension, and responsible non-disclosure.

9.25.8(e) Recovery methods shall identify restored systems, restored data, restored access, restored logs, restored compute, restored dashboards, restored maps, restored APIs, restored repositories, restored sensors, restored interfaces, continuing restrictions, corrected configurations, revalidated credentials, dependency review, public-safe review, and correction status.

9.25.8(f) Notification shall be made where required or appropriate by law, agreement, data-sharing terms, public authority terms, community safeguards, protected knowledge safeguards, provider terms, sponsor terms, host terms, operator terms, insurance terms, Board or committee governance, or public-safe discipline, and shall be bounded to avoid unsafe disclosure, public warning implication, regulatory overclaim, law enforcement overclaim, finance overclaim, procurement implication, provider preference, sponsor validation, host approval implication, or execution implication.

9.25.8(g) Post-incident review shall identify root causes where appropriate, contributing factors, affected dependencies, evidence integrity effects, data integrity effects, public-safe effects, privacy effects, cybersecurity effects, sovereign data effects, public authority effects, community safeguard effects, protected knowledge effects, provider-neutrality effects, sponsor non-control effects, host-boundary effects, operator-boundary effects, finance-boundary effects, procurement-boundary effects, corrective action plans, training updates, technical control updates, method updates, assurance updates, and Board or committee reporting where material.

9.25.8(h) Cybersecurity incident response by GCRI Canada shall not constitute law enforcement action, regulatory finding, public warning, emergency command, operator instruction, remediation approval, security certification, public authority decision, procurement approval, finance-readiness, provider endorsement, sponsor finding, host finding, operational clearance, protocol effect, legal determination, or execution consequence by default.

9.25.8(i) The controlling rule shall be that cybersecurity incident response must contain harm, preserve evidence, correct records, protect people and systems, and improve controls without turning GCRI Canada into an emergency commander, regulator, operator, certifier, or execution actor.

***

9.25.9 Vendor, Provider, Host, and Cloud Security Review.\
9.25.9(a) GCRI Canada shall apply vendor, provider, host, operator, cloud, platform, contractor, subcontractor, managed service, repository, API, dashboard, data-room, compute, AI, model, retrieval, embedding, sensor, AI-RAN, DePIN, cybersecurity tool, and software security review to third-party or contributed systems used in or connected to Observatory systems.

9.25.9(b) Security review records shall identify reviewed actor, reviewed system, reviewed service, role, contribution, data classes, evidence classes, output classes, access class, handling class, public-safe status, hosting location, jurisdiction, data residency, cross-border access, subcontractors, access controls, logging, monitoring, encryption, key management, vulnerability management, incident response, deletion capability, export capability, API exposure, dashboard exposure, AI-use status, model-improvement status, retrieval status, embedding status, public authority data treatment, community safeguard treatment, protected knowledge treatment, provider-neutrality risk, sponsor non-control risk, host-boundary risk, conflict status, residual risk, approval or restriction status, correction path, and closeout obligations.

9.25.9(c) Cloud and platform review shall identify whether public cloud, private cloud, sovereign cloud, community-controlled environment, public authority environment, secure enclave, confidential computing, compute-to-data environment, air-gapped environment, edge compute environment, or no-download environment is required or appropriate based on data class, jurisdiction, sensitivity, public-safe risk, and correction needs.

9.25.9(d) Vendor, provider, host, operator, or cloud services shall not be used for restricted, public authority, health-sensitive, cyber-sensitive, infrastructure-sensitive, finance-sensitive, personal, community-protected, Indigenous, protected knowledge, export-controlled, sanctions-sensitive, controlled-technology, or sovereign-sensitive Observatory data unless review confirms recorded authority, adequate controls, lawful basis, data location, access limits, public-safe controls, correction path, and closeout path.

9.25.9(e) Vendor or provider security materials, attestations, certifications, audit reports, security summaries, compliance statements, penetration-test summaries, or platform assurances may support GCRI Canada security review but shall not replace GCRI Canada’s classification, purpose, access, public-safe, sovereign data, community safeguard, protected knowledge, provider-neutrality, sponsor non-control, correction, and interface review.

9.25.9(f) Provider or vendor security review shall not create provider endorsement, security certification by GCRI Canada, procurement approval, finance-readiness, public authority approval, protocol effect, operational clearance, market superiority, deployment approval, host approval, sponsor approval, rating, guarantee, public warning, emergency command, or execution consequence by default.

9.25.9(g) Where vendor, provider, host, operator, or cloud security risk is unacceptable, uncorrected, undisclosed, public-safe defective, privacy-defective, sovereign-data-defective, community-safeguard-defective, protected-knowledge-defective, public authority-defective, cyber-defective, infrastructure-defective, cross-border-defective, export-control-defective, sanctions-defective, controlled-technology-defective, provider-neutrality-defective, sponsor-control-defective, or correction-defective, GCRI Canada shall restrict use, require remediation, change environment, suspend interface, terminate service, delete or seal data where appropriate, issue notices where required, and update dependencies.

9.25.9(h) The controlling rule shall be that third-party security assurances may inform Observatory cybersecurity, but they do not transfer accountability, erase risk, or create endorsement, procurement, finance, certification, authority, or execution.

***

9.25.10 Observatory Cybersecurity Records, Incident Records, and Assurance.\
9.25.10(a) GCRI Canada shall maintain, or cause to be maintained, Observatory cybersecurity records, security baseline records, identity records, access records, segmentation records, environment records, logging records, monitoring records, security telemetry records, vulnerability records, patch records, exposure records, configuration records, repository security records, API security records, dashboard security records, sensor security records, AI-RAN security records, DePIN security records, compute security records, key records, token records, secrets records, credential records, vendor security records, provider security records, host security records, cloud security records, incident records, correction records, assurance records, renewal records, archive records, and closeout records.

9.25.10(b) Cybersecurity records shall identify record title or identifier, system title or identifier, system class, data class, evidence class, output class, access class, handling class, public-safe status, privacy status, cybersecurity status, sovereign data status, infrastructure-sensitive status, public authority status, health-sensitive status, finance-sensitive status, commercially sensitive status, provider-sensitive status, sponsor-sensitive status, host-sensitive status, operator-sensitive status, community-protected status, Indigenous or protected knowledge status, legal sensitivity, export-control sensitivity, sanctions sensitivity, controlled-technology sensitivity, permitted uses, prohibited uses, publication limits, retention, deletion, sealing, archive, legal hold, and correction path.

9.25.10(c) Incident records shall identify incident title or identifier, incident class, suspected or confirmed status, detection source, affected systems, affected data classes, affected evidence classes, affected output classes, affected environments, affected interfaces, affected public-safe outputs, affected public authority records, affected community records, affected provider records, affected sponsor records, affected host records, affected operator records, affected repositories, affected dashboards, affected maps, affected APIs, affected compute workloads, affected models, affected retrieval systems, affected embedding stores, timeline where safe, containment actions, recovery actions, notification decisions, correction actions, residual risk, assurance follow-up, and closeout status.

9.25.10(d) Correction records shall identify corrected identity record, corrected access record, corrected segmentation record, corrected environment record, corrected log record, corrected monitoring record, corrected vulnerability record, corrected patch record, corrected exposure record, corrected configuration, corrected repository, corrected API, corrected dashboard, corrected map, corrected sensor, corrected AI-RAN component, corrected DePIN component, corrected compute workload, corrected compute environment, corrected key record, corrected token record, corrected secrets record, corrected credential record, corrected vendor security record, corrected provider security record, corrected host security record, corrected cloud security record, corrected public-safe output, corrected public authority reference, corrected provider reference, corrected sponsor reference, corrected host reference, corrected operator reference, corrected community reference, corrected boundary language, prior status, corrected status, effective date, reviewer, affected dependencies, notice decision, access change, archive treatment, and continuing limitations.

9.25.10(e) Assurance records shall identify review cycle, reviewers, scope reviewed, cybersecurity baseline reviewed, identity and access controls reviewed, segmentation reviewed, environment separation reviewed, least privilege reviewed, logging reviewed, monitoring reviewed, security telemetry reviewed, vulnerability management reviewed, patch management reviewed, secure configuration reviewed, repository security reviewed, API security reviewed, dashboard security reviewed, sensor security reviewed, AI-RAN security reviewed, DePIN security reviewed, compute security reviewed, key management reviewed, token management reviewed, secrets management reviewed, credential controls reviewed, incident response reviewed, vendor security reviewed, provider security reviewed, host security reviewed, cloud security reviewed, public authority boundary reviewed, community safeguard reviewed, protected knowledge reviewed, sovereign data reviewed, public-safe publication reviewed, finance-boundary reviewed, procurement-boundary reviewed, provider-neutrality reviewed, sponsor non-control reviewed, findings, corrective action plans, training updates, technical control updates, method updates, Board or committee reporting where material, residual risk, and closeout status.

9.25.10(f) Cybersecurity records shall be linked, where applicable, to National Dense Core records, Regional Observatory Cluster records, Cluster records, Hub records, Node records, Hotspot records, host readiness records, maturity evidence records, Observatory Evidence Pack Register entries, Observatory data records, AI-RAN records, DePIN records, sensor records, geospatial records, cyber telemetry records, digital twin records, dashboard records, degraded-mode records, sovereign compute records, public authority interface records, community interface records, provider and sponsor interface records, Observatory Methods Register entries, Evidence Register entries, Source Comparison Records, Dataset Register entries, Model Register entries, System Card entries, Benchmark Card entries, Compute Workload Records, Compute Environment Records, Inference Records, Human Review Records, Retrieval and Embedding Records, Proof Receipt Records, Public-Safe Output Records, AI Incident Records, Correction Records, Dependency Records, Truth Engine Records, Nexus Risk Management records, GRF interface records, GRA interface records, Protocol Authority interface records, RNFD records, Nexus Rails records, Regional Nexus Consortium records, National Nexus Consortium records, National Company records, Project SPV records, operator records, provider records, sponsor records, host records, community records, university records, Nexus interface records, and public claims records.

9.25.10(g) Cybersecurity records, incident records, correction records, assurance records, renewal records, archive records, notices, and closeout shall not create certification, recognition, finance-readiness, public authority decision, regulatory finding, procurement approval, funding approval, public finance approval, provider endorsement, sponsor approval, host approval, operator approval, community consent, Indigenous consent, rating, guarantee, public warning, emergency command, protocol effect, operational clearance, legal status, market authority, infrastructure operation, remediation approval, deployment approval, national authority, regional authority, GRF maturity record, GRA finance-readiness, security certification by GCRI Canada, or execution consequence by default.

9.25.10(h) Public-safe cybersecurity assurance summaries may be prepared where they can be released without exposing vulnerabilities, credentials, secrets, keys, tokens, cyber telemetry, incident details, infrastructure-sensitive information, protected knowledge, public authority restrictions, personal data, provider-sensitive information, host-sensitive information, operator-sensitive information, or other restricted information. Such summaries shall remain non-certifying, non-recognizing, non-financial, non-procurement, non-public-authority, non-warning, non-command, and non-executing.

9.25.10(i) Where assurance identifies systemic cybersecurity risk, public-safe defects, public authority ambiguity, provider over-access, sponsor overreach, host over-access, operator over-access, community safeguard failure, protected knowledge exposure, sovereign data defect, cross-border defect, finance overclaim, procurement implication, certification implication, recognition implication, protocol implication, or correction failure, GCRI Canada shall restrict affected systems, suspend affected interfaces, update controls, notify affected actors where appropriate and safe, and report to the responsible Board or committee function where material.

9.25.10(j) The controlling rule shall be that Observatory cybersecurity is trustworthy only when controls, access, telemetry, vulnerabilities, incidents, corrections, assurance, dependencies, and limits remain recorded with enough precision to protect systems and evidence without converting cybersecurity practice into certification, authority, warning, procurement, finance, or execution.

### 9.26 Observatory Public-Safe Publication

9.26.1 Public-Safe Publication Purpose for Observatory Outputs.\
9.26.1(a) GCRI Canada shall steward public-safe publication methods for Observatory outputs as a constitutional evidence, safeguards, boundary, correction, and public-trust discipline through which Observatory evidence may be communicated externally only in forms that preserve public benefit, source integrity, confidence, uncertainty, limitations, data protection, cybersecurity, sovereign data, community safeguards, protected knowledge, public authority boundaries, finance boundaries, procurement boundaries, provider neutrality, sponsor non-control, host boundaries, operator boundaries, and correctionability.

9.26.1(b) Public-safe publication may apply to Observatory Nodes, Hubs, Clusters, Hotspots, Regional Observatory Clusters, National Dense Nexus Cores, sensor evidence, AI-RAN evidence, O-RAN evidence, private wireless evidence, DePIN evidence, cyber telemetry evidence, geospatial evidence, Earth observation evidence, digital twin outputs, dashboards, maps, APIs, datasets, reports, technical notes, Evidence Packs, Decision Packs, public authority learning materials, community-facing materials, provider-facing materials, sponsor-facing materials, host-facing materials, operator-facing materials, GRF inputs, GRA inputs, Protocol Authority inputs, Nexus Risk Management materials, Nexus Rails materials, Nexus Grid materials, Nexus Academy materials, public-good software materials, assurance summaries, correction notices, and public claims.

9.26.1(c) Public-safe publication shall be treated as a controlled release of bounded evidence and explanation, not as publication of unrestricted data, not as official truth, not as public authority action, not as a public warning, not as emergency command, not as certification, not as recognition, not as finance-readiness, not as procurement approval, not as provider endorsement, not as sponsor approval, not as host approval, not as operator instruction, not as protocol effect, and not as execution consequence by default.

9.26.1(d) Public-safe publication methods shall be records-valid, source-lined, audience-aware, classification-aware, confidence-aware, uncertainty-aware, limitation-aware, update-aware, privacy-protective, cybersecurity-controlled, sovereignty-compatible, community-sensitive, Indigenous-safeguard-aware where applicable, protected-knowledge-sensitive, public-authority-bounded, finance-safe, procurement-safe, provider-neutral, sponsor-independent, host-bounded, operator-bounded, non-certifying, non-recognizing, non-executing, and correctionable.

9.26.1(e) GCRI Canada shall not publish Observatory outputs externally merely because the underlying data, dashboard, map, model, Evidence Pack, Decision Pack, public authority interface, provider material, sponsor material, host material, community material, or technical output is internally available, technically publishable, visually compelling, already public in part, provider-supplied, sponsor-supported, host-approved, public authority-relevant, finance-relevant, media-relevant, or useful to a public narrative.

9.26.1(f) Public-safe publication shall require review proportionate to the sensitivity and consequence of the output, including review for source lineage, lawful basis, data classification, audience, access class, handling class, public-safe status, confidence, uncertainty, limitations, re-identification risk, group harm risk, protected knowledge exposure, cyber or infrastructure exposure, public authority implication, public warning implication, finance overclaim, procurement implication, certification implication, recognition implication, protocol implication, provider preference, sponsor validation, host approval implication, operator instruction implication, and correction path.

9.26.1(g) Where public-safe publication is unsafe, premature, unsupported, public authority-confusing, warning-adjacent, finance-inflating, procurement-implying, provider-preferential, sponsor-validating, host-approval-implying, operator-instruction-implying, community-harming, protected-knowledge-exposing, privacy-defective, cybersecurity-defective, sovereign-data-defective, or correction-defective, GCRI Canada shall restrict, delay, generalize, aggregate, redact, use controlled annexes, use restricted annexes, issue limited public-safe statements, or refuse publication.

9.26.1(h) The controlling rule shall be that Observatory publication is public-safe only when it informs without exposing, clarifies without overclaiming, supports learning without commanding, and preserves correction without creating authority.

***

9.26.2 Public-Safe Summaries Versus Controlled Annexes and Restricted Annexes.\
9.26.2(a) GCRI Canada may structure Observatory publication into public-safe summaries, controlled annexes, restricted annexes, technical annexes, public authority annexes, community-sensitive annexes, protected knowledge annexes, cyber-sensitive annexes, infrastructure-sensitive annexes, finance-boundary annexes, procurement-boundary annexes, provider-sensitive annexes, sponsor-sensitive annexes, host-sensitive annexes, operator-sensitive annexes, correction annexes, and archive records, provided that access, publication, use, routing, and correction are recorded.

9.26.2(b) Public-safe summaries shall include only those materials that can be externally released without unsafe disclosure, re-identification risk, group harm risk, protected knowledge exposure, public authority confusion, public warning implication, finance overclaim, procurement implication, certification implication, recognition implication, protocol implication, provider preference, sponsor validation, host approval implication, operator instruction implication, community harm, cyber harm, infrastructure exposure, privacy harm, sovereign data harm, legal breach, or execution implication.

9.26.2(c) Public-safe summaries shall identify, where material, output purpose, source classes, method classes, evidence scope, update status, timestamp, version, confidence, uncertainty, limitations, public-safe omissions, responsible non-disclosure basis, stale-data treatment, contradiction status, data-gap status, correction status, supersession status, withdrawal status where applicable, permitted use, prohibited use, and boundary language.

9.26.2(d) Controlled annexes may include materials appropriate for specified controlled audiences, including public authority learners, GRF, GRA, Protocol Authority, Nexus Risk Management, Nexus Rails, National Nexus Consortiums, Regional Nexus Consortiums, National Companies, Project SPVs, hosts, operators, providers, sponsors, communities, universities, or other authorized interfaces, subject to access class, handling class, room rules, use limits, confidentiality, public-safe controls, public authority controls, community safeguards, provider-neutrality controls, sponsor non-control controls, and correction path.

9.26.2(e) Restricted annexes shall be used where materials include or may reveal personal information, rights-bearing data, health-sensitive information, cyber-sensitive information, infrastructure-sensitive information, public authority restricted information, sovereign-sensitive information, finance-sensitive information, commercially sensitive information, community-protected information, Indigenous or protected knowledge, confidential source information, privileged material, credentials, secrets, keys, tokens, controlled technology, exploit details, sensitive locations, unsafe geospatial precision, unsafe metadata, operator-sensitive information, or national-security-adjacent sensitive information.

9.26.2(f) Public-safe summaries shall not imply that controlled annexes, restricted annexes, withheld layers, omitted details, generalized locations, aggregated data, redacted sources, removed identifiers, delayed updates, or responsible non-disclosure do not exist. Where material, public-safe summaries shall state that certain evidence has been withheld, generalized, or restricted for public-safe, legal, privacy, cybersecurity, sovereign data, public authority, community, protected knowledge, provider, sponsor, host, operator, or safety reasons.

9.26.2(g) Annex classification shall not be used to conceal unfavorable evidence, contradiction, uncertainty, data gaps, sponsor influence, provider influence, public authority ambiguity, finance overclaim, procurement implication, certification implication, recognition implication, protocol implication, or correction obligations. Restrictions shall be used for safety, rights, legality, confidentiality, public-safe discipline, and evidence integrity, not narrative management.

9.26.2(h) Where an output cannot be safely divided into public-safe summary, controlled annex, and restricted annex without distorting the evidence or creating misleading public meaning, GCRI Canada shall refuse public publication or issue only a limited public-safe statement.

9.26.2(i) The controlling rule shall be that publication must be layered according to risk: what may be safely public, what may be reviewed under control, what must remain restricted, and what must be corrected shall never be collapsed into one uncontrolled artifact.

***

9.26.3 Public-Safe Treatment of Personal, Public Authority, Health-Sensitive, Cyber-Sensitive, Infrastructure-Sensitive, Finance-Sensitive, Commercially Sensitive, Community-Protected, Indigenous, Local, Territorial, Environmental, and Protected Knowledge Data.\
9.26.3(a) GCRI Canada shall apply heightened public-safe treatment to Observatory publication involving personal data, rights-bearing data, public authority data, health-sensitive data, cyber-sensitive data, infrastructure-sensitive data, finance-sensitive data, commercially sensitive data, community-protected data, Indigenous data where applicable, local data, territorial data, environmental data, protected knowledge data, legal-sensitive data, export-control-sensitive data, sanctions-sensitive data, controlled-technology data, or any derived, inferred, aggregated, summarized, modeled, embedded, visualized, or translated version of such data.

9.26.3(b) Personal and rights-bearing data shall not be published in a manner that identifies or permits inference of individuals, households, small groups, movement patterns, workplace patterns, service-use patterns, health-adjacent patterns, device identifiers, vulnerable-person status, community participation, public authority interaction, or other rights-bearing information, unless lawfully authorized, necessary, public-safe, proportionate, minimized, and correctionable.

9.26.3(c) Public authority data shall not be published in a manner that implies official guidance, public warning, emergency command, regulatory determination, compliance determination, enforcement position, procurement approval, funding approval, public finance approval, public-law status, agency endorsement, or public authority delegation unless separately and lawfully created by the competent public authority and properly recorded.

9.26.3(d) Health-sensitive data shall be treated to prevent identification, stigma, discrimination, health inference, vulnerable-person exposure, public health overclaim, clinical implication, public safety overclaim, public authority confusion, or public-safe harm. Health-sensitive Observatory publication shall not constitute clinical advice, public health order, public safety directive, public warning, diagnosis, treatment recommendation, or health authority communication by GCRI Canada.

9.26.3(e) Cyber-sensitive and infrastructure-sensitive data shall be redacted, generalized, delayed, controlled, restricted, or withheld where publication could reveal credentials, secrets, keys, tokens, vulnerabilities, exploit details, incident telemetry, security controls, network topology, facility locations, service dependencies, outage sensitivity, degraded-mode sensitivity, operator-sensitive information, cyber-physical vulnerabilities, or other harm-enabling details.

9.26.3(f) Finance-sensitive and commercially sensitive data shall be treated to prevent finance-readiness implication, investment implication, insurance implication, rating implication, guarantee implication, bankability implication, fundability implication, public finance implication, procurement implication, market value implication, provider preference, sponsor validation, host valuation, commercial harm, trade secret exposure, or improper capital-reader reliance.

9.26.3(g) Community-protected, Indigenous, local, territorial, environmental, and protected knowledge data shall not be published, mapped, dashboarded, translated, summarized, modeled, embedded, retrieved, trained on, API-exposed, finance-routed, procurement-routed, provider-routed, sponsor-routed, or public authority-routed in a manner inconsistent with recorded protocols, consent or non-consent treatment where applicable, source protection, sensitive-site treatment, protected knowledge safeguards, withdrawal or challenge pathways where applicable, and public-safe review.

9.26.3(h) Environmental data and public-safe environmental outputs shall be reviewed for sensitive-site exposure, habitat exposure, species exposure, protected area misuse, traditional ecological knowledge exposure, vulnerable-community exposure, infrastructure dependency exposure, public warning implication, public authority implication, finance implication, procurement implication, provider preference, sponsor validation, and correctionability.

9.26.3(i) Public-safe treatment may require aggregation, generalization, masking, redaction, omission, safe-location treatment, delayed release, controlled annexing, restricted annexing, access restriction, no-download treatment, API restriction, responsible non-disclosure, or no-publication treatment.

9.26.3(j) The controlling rule shall be that public-safe publication must be judged by what the output can reveal, imply, enable, or be misused to support, not merely by what the output intends to say.

***

9.26.4 Public-Safe Maps, Dashboards, Reports, APIs, Datasets, Technical Notes, and Visualizations.\
9.26.4(a) GCRI Canada shall apply public-safe publication controls to maps, dashboards, reports, APIs, datasets, technical notes, visualizations, charts, tables, indicators, heatmaps, timelines, animations, screenshots, exports, embedded views, repositories, public-good software materials, Academy materials, public authority learning materials, community-facing materials, provider-facing materials, sponsor-facing materials, host-facing materials, operator-facing materials, media materials, website materials, and public claims.

9.26.4(b) Public-safe maps shall be reviewed for geospatial precision, sensitive-site exposure, infrastructure exposure, cyber-sensitive location exposure, community identifiability, protected knowledge exposure, vulnerable-person exposure, public warning implication, public authority implication, finance implication, procurement implication, provider preference, sponsor validation, host approval implication, false precision, misleading legends, and correctionability.

9.26.4(c) Public-safe dashboards shall be reviewed for audience, access class, update status, source lineage, dashboard logic, field meanings, indicator meanings, score meanings where any, color meanings, confidence display, uncertainty display, limitation display, drill-down risk, export risk, screenshot risk, API exposure, stale-data status, boundary language, misuse risk, and correction path.

9.26.4(d) Public-safe reports and technical notes shall identify evidence purpose, source classes, methods, assumptions where applicable, confidence, uncertainty, limitations, public-safe omissions, responsible non-disclosure basis, update status, version, permitted uses, prohibited uses, boundary language, correction status, supersession status, withdrawal status where applicable, and retraction status where applicable.

9.26.4(e) Public-safe APIs and datasets shall be reviewed for field-level sensitivity, row-level sensitivity, metadata sensitivity, inference risk, linkage risk, re-identification risk, group harm risk, exportability, rate limits, authentication, authorization, license, attribution, downstream-use restrictions, stale-data treatment, API error-message safety, public-safe filtering, deprecation, correction propagation, and misuse detection.

9.26.4(f) Public-safe visualizations shall be reviewed for overconfidence, false precision, ranking implication, rating implication, certification implication, public authority implication, public warning implication, finance implication, procurement implication, provider preference, sponsor validation, community stigma, misleading color, misleading scale, omitted uncertainty, hidden limitations, accessibility, translation, localization, and screenshot misuse.

9.26.4(g) Interactive, downloadable, embedded, cached, copied, translated, screen-captured, or API-derived versions of public-safe outputs shall be treated as publication surfaces and shall preserve source reference, version, update status, boundary language, permitted-use limits, prohibited-use limits, public-safe status, and correction path where feasible and material.

9.26.4(h) Public-safe publication shall not include hidden authority through design. Labels, badges, colors, seals, icons, maps, score bands, maturity-like stages, readiness-like labels, hazard-like labels, finance-like indicators, procurement-like categories, provider comparisons, sponsor references, host references, operator references, or public authority references shall not be used in ways that imply prohibited status.

9.26.4(i) Where a public-safe map, dashboard, report, API, dataset, technical note, or visualization cannot be made safe without erasing material uncertainty, distorting evidence, concealing contradiction, exposing restricted data, creating public authority confusion, creating public warning implication, creating finance overclaim, creating procurement implication, creating provider preference, creating sponsor validation, creating host approval implication, creating community harm, or creating execution implication, GCRI Canada shall restrict, revise, delay, refuse, or replace the output with a narrower public-safe statement.

9.26.4(j) The controlling rule shall be that every publication format is a governance surface; the same evidence can become unsafe, misleading, or authority-like when displayed through the wrong map, dashboard, API, chart, label, or summary.

***

9.26.5 Update Status, Timestamp, Version, Confidence, Uncertainty, Limitations, and Correction Path.\
9.26.5(a) Each material public-safe Observatory output shall include or preserve, where appropriate to format and audience, update status, timestamp, version, source status, confidence, uncertainty, limitations, stale-data treatment, contradiction status, data-gap status, public-safe omissions, boundary language, permitted use, prohibited use, correction path, supersession path, withdrawal path, retraction path where applicable, and archive status.

9.26.5(b) Update status shall identify whether the output is current, periodic, near-real-time, delayed, frozen, historical, archived, degraded, under review, corrected, superseded, withdrawn, retracted, restricted, or retired, and shall identify update cadence and stale-data implications where material.

9.26.5(c) Timestamp and version records shall identify release date, source date where material, processing date where material, publication date, version number or identifier, public-safe review date, correction date where any, supersession date where any, withdrawal date where any, retraction date where any, archive date where any, and effective date of boundary language.

9.26.5(d) Confidence statements shall identify, where material, the basis for confidence, including source quality, source independence, corroboration, calibration, timeliness, completeness, reproducibility where appropriate, review status, method reliability, compute integrity, model evaluation, public authority context, community context, provider influence, sponsor influence, host influence, operator context, contradiction status, and correction status.

9.26.5(e) Uncertainty statements shall identify, where material, measurement uncertainty, source uncertainty, temporal uncertainty, spatial uncertainty, statistical uncertainty, operational uncertainty, model uncertainty, digital twin uncertainty, simulation uncertainty, interoperability uncertainty, legal uncertainty, public authority uncertainty, community uncertainty, protected knowledge uncertainty, finance-boundary uncertainty, provider-related uncertainty, sponsor-related uncertainty, host-related uncertainty, operator-related uncertainty, and interpretive uncertainty.

9.26.5(f) Limitation statements shall identify, where material, source limitations, data limitations, method limitations, model limitations, compute limitations, geospatial limitations, dashboard limitations, API limitations, public-safe omissions, restricted annex existence where appropriate, assumptions, excluded variables, missing evidence, stale evidence, contradiction, applicability limits, audience limits, downstream reuse limits, and correction limits.

9.26.5(g) Correction paths shall identify how errors, misreadings, overclaims, unsafe disclosures, public authority confusion, public warning implication, finance overclaim, procurement implication, provider preference, sponsor validation, host approval implication, operator instruction implication, community harm, protected knowledge exposure, privacy defect, cybersecurity defect, sovereign data issue, or public-safe defect may be reported, reviewed, corrected, superseded, withdrawn, retracted, archived, or clarified.

9.26.5(h) Public-safe outputs shall not conceal update status, uncertainty, limitations, public-safe omissions, data gaps, contradiction, stale data, correction status, or supersession status merely to improve readability, aesthetics, public confidence, sponsor visibility, provider visibility, finance-facing clarity, procurement-facing clarity, media utility, or narrative coherence.

9.26.5(i) Where update status, timestamp, version, confidence, uncertainty, limitations, or correction path is missing, misleading, stale, contradicted, mistranslated, inaccessible, overconfident, or correction-defective, GCRI Canada shall correct, relabel, restrict, supersede, withdraw, reissue, or archive the affected output as appropriate.

9.26.5(j) The controlling rule shall be that a public-safe Observatory output is incomplete unless the public can understand when it was true, how strongly it was known, what was uncertain, what was limited, what changed, and how to correct it.

***

9.26.6 No Public Warning, No Emergency Command, No Certification, No Procurement, No Finance, No Rating, No Endorsement, and No Execution Boundary Language.\
9.26.6(a) GCRI Canada shall include boundary language in public-safe Observatory publications where material to prevent interpretation as public warning, emergency command, public authority decision, regulatory determination, compliance determination, law enforcement finding, procurement approval, funding approval, public finance approval, finance-readiness, investment advice, insurance approval, lending decision, underwriting decision, rating, guarantee, certification, recognition, maturity record, claims approval, standing, registry status, protocol effect, conformance determination, Nexus-compatible status, provider endorsement, sponsor approval, host approval, operator instruction, operational clearance, deployment approval, infrastructure operation, market authority, legal status, professional advice, or execution consequence.

9.26.6(b) Boundary language shall be proportionate to the output format, audience, risk, and likely misuse, and may appear in titles, captions, footers, legends, metadata, release notes, API documentation, dataset documentation, dashboard notes, map notes, report front matter, technical note disclaimers, public-safe summaries, controlled-annex terms, repository notices, media notes, citation instructions, and correction notices.

9.26.6(c) Public-safe outputs shall not use labels, signals, marks, badges, icons, seals, color systems, stage labels, readiness labels, maturity labels, rating-like scales, hazard-like banners, alert-like notifications, finance-like indicators, procurement-like categories, certification-like language, recognition-like language, provider-comparison displays, sponsor-validation language, host-approval language, or public authority-like formatting that contradicts boundary language.

9.26.6(d) No public-safe Observatory publication shall state or imply that GCRI Canada has issued an official warning, emergency instruction, safety directive, public health order, regulatory approval, compliance determination, procurement approval, finance-readiness determination, investment recommendation, rating, guarantee, certification, recognition, protocol effect, provider preference, sponsor finding, host finding, operator instruction, remediation approval, deployment approval, operational clearance, or execution authorization.

9.26.6(e) Where publication is routed to or referenced by public authorities, GRF, GRA, Protocol Authority, Nexus Risk Management, Nexus Rails, National Nexus Consortiums, Regional Nexus Consortiums, National Companies, Project SPVs, providers, sponsors, hosts, operators, communities, universities, Academy programs, media, or public repositories, GCRI Canada shall preserve boundary language sufficient to prevent role confusion and downstream overclaim.

9.26.6(f) Boundary language shall not be used as a substitute for substantive safeguards. GCRI Canada shall not publish unsafe, overclaimed, misleading, privacy-defective, cybersecurity-defective, protected-knowledge-defective, public authority-confusing, finance-inflating, procurement-implying, provider-preferential, sponsor-validating, host-approval-implying, operator-instruction-implying, or correction-defective outputs merely because a disclaimer is included.

9.26.6(g) Where boundary language is absent, insufficient, contradicted by design, undermined by marketing, mistranslated, inaccessible, removed, misquoted, hidden, or reused out of context, GCRI Canada shall correct, relabel, restrict, withdraw, reissue, request removal of misleading references, issue clarification where appropriate, and review affected dependencies.

9.26.6(h) The controlling rule shall be that boundary language must be clear enough to prevent evidence from being mistaken for warning, command, certification, procurement, finance, rating, endorsement, authority, or execution, but boundary language shall never excuse unsafe publication.

***

9.26.7 Public Authority Reference Controls.\
9.26.7(a) GCRI Canada shall apply public authority reference controls to any public-safe Observatory publication that names, identifies, depicts, quotes, references, implies, summarizes, cites, displays, or otherwise associates a public authority, regulator, public finance body, emergency-management body, public health body, public safety body, public infrastructure operator, public procurement actor, public funding actor, Crown or state entity, intergovernmental body, Indigenous public governance body where applicable, jurisdiction, agency, office, official, employee, public program, public seal, logo, mark, title, photo, attendance, data contribution, dashboard access, review, or comment.

9.26.7(b) Public authority reference records shall identify the public authority reference, reference purpose, output class, publication channel, audience, public-safe status, capacity classification, official or non-official status, permitted reference, prohibited reference, permitted logo or mark use where any, prohibited logo or mark use, permitted title use, prohibited title use, permitted quote use, prohibited quote use, permitted photograph use, permitted attendance reference, permitted data contribution reference, jurisdictional reference limits, expiration or review date where any, and correction path.

9.26.7(c) Public authority references shall preserve non-delegation, non-endorsement, no-official-guidance, no-regulatory-determination, no-compliance-determination, no-enforcement-position, no-public-warning, no-emergency-command, no-procurement, no-funding, no-public-finance, no-certification, no-recognition, no-finance-readiness, no-provider-endorsement, no-sponsor-approval, no-host-approval, no-operator-instruction, no-protocol-effect unless separately created, and no-execution language where material.

9.26.7(d) Public authority names, logos, official marks, official titles, photographs, quotations, attendance references, data contribution references, jurisdictional references, and agency references shall not be used in a manner that implies endorsement, adoption, approval, delegation, official guidance, regulatory determination, procurement approval, funding approval, public finance approval, public warning, emergency command, public-law status, certification, recognition, finance-readiness, provider preference, sponsor approval, host approval, operator instruction, deployment approval, market authority, or execution consequence unless expressly authorized by the competent public authority and consistent with GCRI Canada’s non-executing role.

9.26.7(e) Public authority references may be generalized, anonymized, aggregated, described by capacity, or omitted where specific reference would create public authority confusion, confidentiality risk, public-safe risk, procurement implication, funding implication, public finance implication, public warning implication, emergency-command implication, regulatory implication, political sensitivity, community harm, or inappropriate reliance.

9.26.7(f) Public authority review of a public-safe Observatory output shall not by itself create endorsement, approval, adoption, delegation, official guidance, regulatory determination, public warning, emergency command, procurement approval, funding approval, public finance approval, certification, recognition, finance-readiness, provider preference, sponsor approval, host approval, operator instruction, deployment approval, or execution consequence unless separately and expressly recorded by the competent public authority.

9.26.7(g) Where public authority reference approval is missing, stale, exceeded, contested, withdrawn, misquoted, mistranslated, visually misleading, public authority-confusing, public-warning-implying, procurement-implying, finance-implying, funding-implying, regulatory-implying, or public-safe defective, GCRI Canada shall remove, correct, restrict, relabel, withdraw, reissue, seek renewed approval, or issue clarification as appropriate.

9.26.7(h) The controlling rule shall be that public authority references carry public power implications and therefore must be used only with recorded capacity, recorded permission, recorded limits, and recorded correction paths.

***

9.26.8 Provider, Sponsor, Host, and Partner Reference Controls.\
9.26.8(a) GCRI Canada shall apply provider, sponsor, host, operator, vendor, contractor, university, partner, National Company, Project SPV, community, GRF, GRA, Protocol Authority, Nexus entity, and other actor reference controls to public-safe Observatory publications that name, identify, depict, quote, acknowledge, compare, display, cite, or otherwise associate such actors with Observatory evidence or outputs.

9.26.8(b) Provider reference controls shall identify provider role, provider materials, provider systems, provider data, provider tools, provider equipment, provider AI, provider compute, provider sensors, provider dashboards, provider configuration, benchmark conditions where any, validation conditions where any, commercial sensitivity, IP sensitivity, cybersecurity sensitivity, conflict status, permitted claims, prohibited claims, no-provider-endorsement language, no-procurement-preference language, no-certification language, no-recognition language, no-finance-readiness language, no-public-authority-endorsement language, no-protocol-effect unless separately created, and correction path.

9.26.8(c) Sponsor reference controls shall identify sponsor role, funding or support relationship, convening support, facilities support, technology access, data access, publication support, conflict status, sponsor non-control language, no-outcome-purchase language, no-evidence-control language, no-source-selection-control language, no-publication-control language, no-recognition-control language, no-finance-control language, no-protocol-control language, no-procurement-control language, no-execution-control language, permitted claims, prohibited claims, and correction path.

9.26.8(d) Host and operator reference controls shall identify host or operator role, facility or system context where safe and material, site or safe-site treatment, infrastructure context, operational context in public-safe or controlled form, data contribution status, sensor contribution status, compute contribution status, connectivity contribution status, dashboard access status, map access status, public-safe limits, no-host-certification language, no-host-approval language, no-operator-instruction language, no-service-assurance language, no-operational-clearance language, no-procurement language, no-finance-readiness language, no-deployment-approval language, no-execution language, and correction path.

9.26.8(e) Partner, university, contractor, National Company, Project SPV, GRF, GRA, Protocol Authority, or Nexus entity references shall identify the actor’s actual role, legal separateness, authority boundaries, interface status, contribution, permitted claims, prohibited claims, public-safe status, and correction path, and shall not collapse participation, support, review, attendance, data contribution, or interface use into approval or institutional merger.

9.26.8(f) Public acknowledgements, logos, marks, photographs, quotes, case studies, event listings, participant listings, sponsor listings, provider listings, host listings, partner listings, community references, or public-safe summary references shall be reviewed for endorsement implication, procurement implication, finance implication, certification implication, recognition implication, public authority implication, community consent implication, provider preference implication, sponsor validation implication, host approval implication, operator approval implication, protocol implication, market signal, and correctionability.

9.26.8(g) Actor participation, data contribution, review, attendance, comments, dashboard access, map access, site access, facility access, sponsor support, provider support, host support, operator participation, university participation, National Company relevance, Project SPV relevance, GRF interface use, GRA interface use, Protocol Authority interface use, or public-safe summary inclusion shall not imply endorsement, approval, consent, certification, recognition, procurement approval, finance-readiness, public authority decision, protocol effect, provider preference, sponsor validation, host approval, operator instruction, deployment approval, operational clearance, market signal, or execution consequence.

9.26.8(h) Where provider, sponsor, host, operator, partner, or other actor reference is missing, stale, exceeded, contested, withdrawn, misquoted, mistranslated, visually misleading, provider-preferential, sponsor-validating, host-approval-implying, operator-instruction-implying, procurement-implying, finance-inflating, certification-implying, recognition-implying, public authority-confusing, community-consent-implying, or public-safe defective, GCRI Canada shall remove, correct, restrict, relabel, withdraw, reissue, seek renewed approval where appropriate, or issue clarification.

9.26.8(i) The controlling rule shall be that visibility is not status: naming, thanking, showing, listing, or referencing an actor must not become endorsement, control, procurement, finance, certification, recognition, protocol effect, authority, or execution.

***

9.26.9 Correction, Withdrawal, Retraction, Supersession, and Archive.\
9.26.9(a) GCRI Canada shall maintain correction, withdrawal, retraction, supersession, re-issue, archive, notice, dependency review, and misuse-response methods for public-safe Observatory publications.

9.26.9(b) Correction shall be required where a public-safe Observatory publication contains material error, source-lineage defect, data-class defect, evidence-class defect, method defect, model defect, compute defect, dashboard defect, map defect, API defect, timestamp defect, version defect, confidence defect, uncertainty defect, limitation defect, public-safe defect, boundary-language defect, public authority confusion, public warning implication, finance overclaim, procurement implication, certification implication, recognition implication, protocol implication, provider preference, sponsor validation, host approval implication, operator instruction implication, community consent implication, protected knowledge exposure, privacy defect, cybersecurity defect, sovereign data issue, cross-border defect, legal defect, export-control issue, sanctions issue, controlled-technology issue, or correction failure.

9.26.9(c) Supersession shall be used where an output is replaced by fuller evidence, corrected evidence, updated evidence, renewed evidence, assurance-reviewed evidence, updated source records, updated data classification, updated compute records, updated model records, updated dashboard records, updated map records, updated API records, updated public authority context, updated community context, updated provider context, updated sponsor context, updated host context, updated operator context, updated public-safe classification, or updated boundary language.

9.26.9(d) Withdrawal shall be used where a public-safe Observatory publication should no longer be used or relied upon because of material inaccuracy, incompleteness, stale evidence, unsafe disclosure, public-safe defect, unsupported confidence, understated uncertainty, missing limitation, authority confusion, warning implication, finance overclaim, procurement implication, provider preference, sponsor validation, host approval implication, operator instruction implication, protected knowledge exposure, community harm risk, privacy defect, cybersecurity defect, sovereign data issue, legal defect, or unresolved correction defect.

9.26.9(e) Retraction shall be used where an output is materially unsupported, materially misleading, unsafe, unlawfully or improperly published, materially overclaimed, materially harmful, or incapable of correction without continued public-safe risk. Retraction shall preserve records sufficient for accountability, dependency review, learning, and lawful obligations while preventing continued reliance.

9.26.9(f) Re-issue shall require corrected source records, corrected data classification, corrected method records, corrected evidence classification, corrected confidence, corrected uncertainty, corrected limitations, corrected public-safe status, corrected boundary language, corrected annex classification, corrected dependency notices where appropriate, corrected publication record, reviewer record, effective date, and archive treatment of prior versions.

9.26.9(g) Archive records shall identify archived publication, archive reason, archive date, archive location, access limits, public-safe status, citation status, continuing prohibited uses, correction relationship, supersession relationship, withdrawal relationship, retraction relationship where any, legal hold where any, and closeout status.

9.26.9(h) Where correction, withdrawal, retraction, supersession, re-issue, or archive affects GRF inputs, GRA inputs, Protocol Authority inputs, Nexus Risk Management materials, Nexus Rails materials, National Nexus Consortium materials, Regional Nexus Consortium materials, National Company materials, Project SPV materials, public authority learning materials, community-facing materials, provider-facing materials, sponsor-facing materials, host-facing materials, operator-facing materials, Academy materials, repositories, dashboards, maps, APIs, media materials, or public claims, GCRI Canada shall issue public-safe notice or controlled notice as appropriate and review affected dependencies.

9.26.9(i) Correction, withdrawal, retraction, supersession, re-issue, archive, notice, or clarification shall not itself create certification, recognition, finance-readiness, public authority decision, regulatory finding, procurement approval, provider endorsement, sponsor finding, host finding, operator finding, community consent, Indigenous consent, rating, guarantee, public warning, emergency command, protocol effect, operational clearance, legal status, market authority, deployment approval, or execution consequence by default.

9.26.9(j) The controlling rule shall be that public-safe publication must remain corrigible after release; an Observatory output that cannot be corrected, withdrawn, retracted, superseded, and archived is not safe to publish.

***

9.26.10 Observatory Publication Records and Misuse Monitoring.\
9.26.10(a) GCRI Canada shall maintain, or cause to be maintained, Observatory publication records and misuse monitoring records for material public-safe Observatory publications, including public-safe summaries, reports, technical notes, maps, dashboards, APIs, datasets, visualizations, Academy materials, public authority learning materials, community-facing materials, provider-facing materials, sponsor-facing materials, host-facing materials, operator-facing materials, GRF-facing materials, GRA-facing materials, Protocol Authority-facing materials, Nexus Risk Management materials, Nexus Rails materials, public-good software publications, media materials, repository materials, website materials, correction notices, supersession notices, withdrawal notices, retraction notices, clarification notices, archive records, and public claims.

9.26.10(b) Publication records shall identify publication title or identifier, output class, publication purpose, audience, publication channel, release date, version, timestamp, source records, data records, method records, compute records where applicable, model records where applicable, dashboard records where applicable, map records where applicable, API records where applicable, evidence class, data class, access class, handling class, public-safe status, confidence, uncertainty, limitations, public-safe omissions, boundary language, permitted use, prohibited use, correction path, supersession path, withdrawal path, retraction path where applicable, archive path, and responsible steward.

9.26.10(c) Public-safe review records shall identify reviewers, review date, source review, data classification review, lawful basis review, privacy review, cybersecurity review, sovereign data review, public authority review, public warning review, community safeguard review, protected knowledge review, finance-boundary review, procurement-boundary review, certification-boundary review, recognition-boundary review, protocol-boundary review, provider-neutrality review, sponsor non-control review, host-boundary review, operator-boundary review, accessibility review, translation review where applicable, and correction review.

9.26.10(d) Misuse monitoring may include lawful and proportionate review of public references, media references, social-media references, provider materials, sponsor materials, host materials, operator materials, public authority materials, finance-facing materials, procurement materials, National Company materials, Project SPV materials, repository forks, screenshots, copied charts, embedded views, API reuse, dataset reuse, derivative visualizations, translated summaries, event materials, and public claims.

9.26.10(e) Misuse includes overclaim, misquotation, mistranslation, out-of-context reuse, unauthorized embedding, unauthorized export, screenshot misuse, API misuse, dataset misuse, dashboard misuse, map misuse, provider misuse, sponsor misuse, host misuse, operator misuse, public authority misuse, finance-facing misuse, procurement-facing misuse, media overclaim, public warning implication, public authority implication, certification implication, recognition implication, protocol implication, finance implication, provider-preference implication, sponsor-validation implication, host-approval implication, operator-instruction implication, community-consent implication, market-signal implication, or execution implication.

9.26.10(f) Where misuse is detected, GCRI Canada may issue public-safe clarification, controlled clarification, correction notice, misuse notice, removal request, relabeling request, interface notice, public authority notice, community notice, provider notice, sponsor notice, host notice, operator notice, GRF notice, GRA notice, Protocol Authority notice, National Company notice, Project SPV notice, or legal notice as appropriate.

9.26.10(g) Public clarification shall be proportionate, public-safe, source-lined where appropriate, non-defamatory, non-regulatory, non-public-warning, non-financial, non-procurement, non-certifying, non-recognizing, non-protocol-conferring, non-provider-preferential, non-sponsor-validating, non-host-approving, non-operator-commanding, non-executing, and correction-focused.

9.26.10(h) Publication records and misuse monitoring records shall be linked, where applicable, to National Dense Core records, Regional Observatory Cluster records, Cluster records, Hub records, Node records, Hotspot records, host readiness records, maturity evidence records, Observatory Evidence Pack Register entries, Observatory data records, cybersecurity records, AI-RAN records, DePIN records, sensor records, geospatial records, cyber telemetry records, digital twin records, dashboard records, degraded-mode records, sovereign compute records, public authority interface records, community interface records, provider and sponsor interface records, Observatory Methods Register entries, Evidence Register entries, Source Comparison Records, Dataset Register entries, Model Register entries, System Card entries, Benchmark Card entries, Compute Workload Records, Compute Environment Records, Inference Records, Human Review Records, Retrieval and Embedding Records, Proof Receipt Records, Public-Safe Output Records, AI Incident Records, Correction Records, Dependency Records, Truth Engine Records, Nexus Risk Management records, GRF interface records, GRA interface records, Protocol Authority interface records, RNFD records, Nexus Rails records, Regional Nexus Consortium records, National Nexus Consortium records, National Company records, Project SPV records, operator records, provider records, sponsor records, host records, community records, university records, Nexus interface records, and public claims records.

9.26.10(i) Observatory publication records, public-safe review records, misuse monitoring records, correction records, clarification records, supersession records, withdrawal records, retraction records, archive records, notices, assurance, renewal, and closeout shall not create certification, recognition, finance-readiness, public authority decision, regulatory finding, procurement approval, funding approval, public finance approval, provider endorsement, sponsor approval, host approval, operator approval, community consent, Indigenous consent, rating, guarantee, public warning, emergency command, protocol effect, operational clearance, legal status, market authority, infrastructure operation, remediation approval, deployment approval, national authority, regional authority, GRF maturity record, GRA finance-readiness, or execution consequence by default.

9.26.10(j) The controlling rule shall be that Observatory publication remains governed after release: public-safe outputs must be recorded, monitored, corrected, clarified, withdrawn, retracted, superseded, archived, and protected against misuse with the same seriousness as the evidence they publish.

### 9.27 Observatory Incident Handling

9.27.1 Observatory Incident Taxonomy.\
9.27.1(a) GCRI Canada shall maintain Observatory incident handling methods as a constitutional evidence-integrity, safeguards, public-safe, cybersecurity, data protection, correction, assurance, and learning discipline for identifying, classifying, receiving, triaging, containing, reviewing, correcting, notifying where required, learning from, and closing out incidents affecting Observatory systems, Observatory evidence, Observatory data, public-safe outputs, public authority interfaces, community interfaces, provider interfaces, sponsor interfaces, host interfaces, operator interfaces, dashboards, maps, APIs, sensors, AI-RAN systems, O-RAN systems, private wireless systems, DePIN systems, cyber telemetry systems, digital twins, compute environments, AI systems, Evidence Packs, Decision Packs, registers, publications, correction records, and assurance records.

9.27.1(b) The Observatory incident taxonomy shall include, at minimum, data incidents, cybersecurity incidents, AI incidents, sensor incidents, AI-RAN, O-RAN, private wireless, or network incidents, DePIN or proof incidents, dashboard incidents, map incidents, API incidents, public-safe publication incidents, public authority misdescription incidents, community safeguard incidents, protected knowledge incidents, provider incidents, sponsor incidents, host incidents, operator incidents, public claim incidents, correction incidents, cross-border incidents, sovereign data incidents, access incidents, repository incidents, compute incidents, model incidents, retrieval incidents, embedding incidents, proof receipt incidents, and interface incidents.

9.27.1(c) An Observatory incident may be suspected, confirmed, disputed, corrected, contained, unresolved, closed, superseded, withdrawn, reclassified, or archived. Incident status shall be recorded with confidence, uncertainty, limitations, source lineage, evidence basis, classification, affected systems, affected outputs, affected interfaces, affected persons or communities where safe and material, public-safe status, notification status, correction path, and dependency links.

9.27.1(d) Observatory incident handling shall be protective and corrective. It shall not constitute public warning, emergency command, law enforcement action, regulatory determination, compliance determination, public authority decision, procurement approval, finance-readiness, certification, recognition, security certification, provider endorsement, sponsor finding, host finding, operator finding, protocol effect, operational clearance, remediation approval, deployment approval, market authority, legal status, or execution consequence by default.

9.27.1(e) GCRI Canada’s maintenance of an incident taxonomy, incident register, incident intake path, severity classification, containment method, notification method, correction method, or post-incident review method shall not make GCRI Canada a regulator, law enforcement body, emergency-management actor, public warning issuer, public health authority, public safety authority, cybersecurity operator, managed security service provider, infrastructure operator, telecommunications operator, finance actor, procurement actor, certification body, Protocol Authority, provider, sponsor, host, operator, National Company, Project SPV, or execution actor by default.

9.27.1(f) Incident classification shall account for harm, likelihood, severity, sensitivity, affected data classes, affected evidence classes, affected output classes, public authority implications, community implications, protected knowledge implications, privacy implications, cybersecurity implications, sovereign data implications, cross-border implications, finance implications, procurement implications, provider implications, sponsor implications, host implications, operator implications, public-safe implications, correction implications, and public trust implications.

9.27.1(g) Incidents shall be recorded and handled in a manner that preserves role separation among GCRI Canada, GCRI US, The Global Risks Forum (GRF), The Global Risks Alliance (GRA), Nexus Standards / Protocol Authority, Nexus entities, Regional Nexus Consortiums, National Nexus Consortiums, National Companies, Project SPVs, public authorities, operators, providers, sponsors, hosts, communities, universities, contractors, and other actors.

9.27.1(h) The controlling rule shall be that Observatory incidents are evidence and safeguard events requiring containment, correction, learning, and record discipline, not automatic authority, warning, certification, finance, procurement, blame, liability, or execution events.

***

9.27.2 Data Incident.\
9.27.2(a) A data incident shall mean any suspected or confirmed event involving unauthorized access, unauthorized disclosure, unauthorized use, unlawful or unsupported use, misclassification, excessive collection, excessive retention, excessive exposure, excessive sharing, excessive dashboarding, excessive mapping, excessive API exposure, excessive AI use, unauthorized cross-border transfer, sovereign data defect, public authority data defect, privacy incident, health-sensitive data exposure, cyber-sensitive data exposure, infrastructure-sensitive data exposure, finance-sensitive data exposure, commercially sensitive data exposure, community-protected data exposure, Indigenous or protected knowledge exposure, retrieval leakage, embedding leakage, data corruption, data loss, data deletion error, sealing error, archival error, legal hold defect, or correction failure affecting Observatory data.

9.27.2(b) Data incident records shall identify incident title or identifier, detection source, affected data, affected data class, affected evidence class, affected output class, affected source, affected system, affected dashboard, affected map, affected API, affected Evidence Pack, affected Decision Pack, affected public-safe output, affected interface, affected jurisdiction, affected community context where safe and material, affected public authority context where any, affected provider, sponsor, host, or operator context where any, suspected or confirmed status, severity where used, confidence, uncertainty, public-safe status, containment status, notification status, correction path, and dependency links.

9.27.2(c) Data incident containment may include access restriction, access revocation, dashboard restriction, map restriction, API restriction, repository restriction, data-room closure, controlled-room restriction, export suspension, retrieval suspension, embedding store restriction, AI-use suspension, cross-border transfer suspension, provider access suspension, sponsor access suspension, host access suspension, operator access suspension, public authority routing suspension, deletion, sealing, public-safe output withdrawal, or other proportionate measures.

9.27.2(d) GCRI Canada shall review data incidents for lawful basis, authority, permission, consent or non-consent treatment where applicable, data classification, public-safe status, privacy, cybersecurity, sovereign data, public authority restrictions, community safeguards, protected knowledge safeguards, provider restrictions, sponsor restrictions, host restrictions, operator restrictions, AI-use restrictions, cross-border status, retention status, deletion status, sealing status, archive status, and correctionability.

9.27.2(e) Where a data incident affects public-safe outputs, Evidence Packs, Decision Packs, dashboards, maps, APIs, public authority learning materials, community-facing materials, provider-facing materials, sponsor-facing materials, host-facing materials, operator-facing materials, GRF inputs, GRA inputs, Protocol Authority inputs, Nexus Risk Management materials, Nexus Rails materials, Academy materials, repositories, media materials, or public claims, GCRI Canada shall review affected dependencies and issue public-safe or controlled correction, withdrawal, retraction, supersession, or notification where appropriate.

9.27.2(f) A data incident record, containment action, notification, or correction shall not create public authority decision, public warning, emergency command, legal determination, regulatory finding, compliance determination, procurement approval, finance-readiness, certification, recognition, provider endorsement, sponsor finding, host finding, operator finding, rating, guarantee, protocol effect, operational clearance, deployment approval, market authority, or execution consequence by default.

9.27.2(g) Where data incident ambiguity exists, GCRI Canada shall treat the incident under the more protective classification until review confirms a narrower treatment.

9.27.2(h) The controlling rule shall be that a data incident is not closed until the data, affected outputs, affected interfaces, affected permissions, affected access rights, affected dependencies, and affected correction records are brought back into recorded order or expressly restricted.

***

9.27.3 Cyber Incident.\
9.27.3(a) A cyber incident shall mean any suspected or confirmed event involving unauthorized system access, credential compromise, key compromise, token compromise, secrets exposure, malware, ransomware, phishing, social engineering, vulnerability exploitation, repository compromise, API compromise, dashboard compromise, map compromise, sensor compromise, AI-RAN compromise, O-RAN compromise, private wireless compromise, DePIN compromise, compute compromise, model compromise, retrieval system compromise, embedding store compromise, telemetry tampering, log tampering, configuration tampering, denial of service, service degradation, cross-tenant exposure, cross-program exposure, cross-entity exposure, cross-border exposure, public-safe bypass, or cybersecurity control failure affecting Observatory systems or evidence.

9.27.3(b) Cyber incident records shall identify incident title or identifier, detection source, affected systems, affected environments, affected repositories, affected dashboards, affected maps, affected APIs, affected compute workloads, affected compute environments, affected sensors, affected AI-RAN systems, affected DePIN systems, affected models, affected retrieval systems, affected embedding stores, affected logs, affected credentials, affected keys, affected tokens, affected secrets, affected data classes, affected evidence classes, affected output classes, affected interfaces, suspected or confirmed status, severity where used, confidence, uncertainty, public-safe status, containment actions, recovery actions, notification decisions, correction actions, residual risk, and closeout status.

9.27.3(c) Cyber incident containment may include identity suspension, access revocation, credential rotation, key revocation, token revocation, secret rotation, system isolation, network segmentation, repository restriction, API restriction, dashboard restriction, map restriction, sensor isolation, AI-RAN interface restriction, DePIN interface restriction, compute suspension, model suspension, retrieval suspension, embedding store restriction, data-room closure, controlled-room restriction, provider interface suspension, sponsor interface suspension, host interface suspension, operator interface suspension, and public-safe output withdrawal.

9.27.3(d) Cyber incident review shall assess confidentiality, integrity, availability, authenticity, access control, logging, monitoring, vulnerability management, patch status, secure configuration, key management, repository security, API security, dashboard security, sensor security, edge security, AI-RAN security, DePIN security, compute security, vendor security, provider security, host security, cloud security, public authority data impact, community safeguard impact, protected knowledge impact, public-safe impact, finance-boundary impact, procurement-boundary impact, and correction impact.

9.27.3(e) GCRI Canada shall not publicly disclose vulnerability details, exploit details, unpatched conditions, insecure configurations, topology-sensitive information, operator-sensitive information, host-sensitive information, provider-sensitive information, public authority system information, cyber telemetry, incident details, or infrastructure-sensitive evidence except through recorded coordinated disclosure, responsible non-disclosure, controlled notice, or public-safe publication methods.

9.27.3(f) Cyber incident handling by GCRI Canada shall not constitute law enforcement action, regulatory finding, public warning, emergency command, operator instruction, remediation approval, security certification, public authority decision, procurement approval, finance-readiness, provider endorsement, sponsor finding, host finding, operational clearance, protocol effect, legal determination, or execution consequence by default.

9.27.3(g) Where a cyber incident affects Evidence Packs, Decision Packs, dashboards, maps, APIs, public-safe outputs, public authority materials, community materials, provider materials, sponsor materials, host materials, operator materials, GRF inputs, GRA inputs, Protocol Authority inputs, Nexus Risk Management materials, Nexus Rails materials, Academy materials, repositories, media materials, or public claims, GCRI Canada shall correct, restrict, supersede, withdraw, reissue, or notify affected interfaces as appropriate.

9.27.3(h) The controlling rule shall be that cyber incident handling must contain harm, preserve evidence integrity, protect sensitive systems, correct affected records, and improve controls without turning GCRI Canada into a cyber operator, regulator, public warning issuer, or emergency commander.

***

9.27.4 AI Incident.\
9.27.4(a) An AI incident shall mean any suspected or confirmed event involving hallucination, fabricated source, unsupported inference, model drift, model performance degradation, unsafe output, biased output, discriminatory output, exclusionary output, privacy leakage, public authority confusion, finance overclaim, procurement implication, certification implication, recognition implication, protocol implication, provider preference, sponsor validation, host approval implication, operator instruction implication, unauthorized AI use, unauthorized training, unauthorized fine-tuning, unauthorized model improvement, unauthorized embedding, unauthorized retrieval, retrieval leakage, embedding leakage, cross-context contamination, prompt leakage, agentic overreach, unauthorized tool action, unsafe external communication, unauthorized publication, unauthorized data movement, unauthorized code execution, unauthorized repository change, unauthorized deletion, or AI-related correction failure affecting Observatory systems, evidence, outputs, or interfaces.

9.27.4(b) AI incident records shall identify incident title or identifier, model identity, model version, system identity, dataset identity where applicable, retrieval source where applicable, embedding store where applicable, prompt or query context where safe and appropriate, compute environment, user or role where appropriate, affected data classes, affected evidence classes, affected output classes, affected dashboards, affected maps, affected APIs, affected Evidence Packs, affected Decision Packs, affected public-safe outputs, affected interfaces, suspected or confirmed status, severity where used, confidence, uncertainty, public-safe status, containment actions, human review status, correction path, and dependency links.

9.27.4(c) AI incident containment may include output quarantine, model restriction, model suspension, model retirement, retrieval source suspension, embedding store restriction, prompt or query restriction, agentic tool suspension, access restriction, public AI tool restriction, vendor AI processing restriction, affected dashboard restriction, affected map restriction, affected API restriction, publication withdrawal, interface suspension, and dependency review.

9.27.4(d) AI incident review shall assess source lineage, retrieval grounding, model limitations, model evaluation, dataset quality, benchmark status, prompt or query risk, inference record completeness, human review adequacy, public-safe review adequacy, privacy impact, cybersecurity impact, sovereign data impact, public authority boundary impact, community safeguard impact, protected knowledge impact, finance-boundary impact, procurement-boundary impact, provider-neutrality impact, sponsor non-control impact, host-boundary impact, operator-boundary impact, and correctionability.

9.27.4(e) AI outputs affected by incident shall not be used to support public claims, public-safe summaries, Evidence Packs, Decision Packs, dashboards, maps, APIs, GRF inputs, GRA inputs, Protocol Authority inputs, public authority learning materials, provider-facing materials, sponsor-facing materials, host-facing materials, operator-facing materials, community-facing materials, Academy materials, media materials, repositories, or public communications until classified, reviewed, corrected, restricted, superseded, withdrawn, or reissued as appropriate.

9.27.4(f) AI incident handling shall not itself create official truth, public authority decision, public warning, finance-readiness, investment advice, rating, insurance approval, lending decision, certification, recognition, maturity record, protocol effect, procurement approval, provider preference, sponsor approval, host approval, operator instruction, operational clearance, deployment approval, market authority, legal status, or execution consequence.

9.27.4(g) Where an AI incident reveals systemic risk, GCRI Canada shall update model governance, Dataset Cards, Model Cards, System Cards, Benchmark Cards, evaluation harnesses, retrieval controls, embedding controls, inference records, human review requirements, public-safe controls, agentic AI controls, training, assurance, and Board or committee reporting where material.

9.27.4(h) The controlling rule shall be that AI incidents must be handled as human-accountable evidence incidents: models may assist, but humans must classify, contain, review, correct, and learn.

***

9.27.5 Sensor Incident.\
9.27.5(a) A sensor incident shall mean any suspected or confirmed event involving sensor failure, reference sensor failure, calibration failure, configuration error, firmware error, maintenance defect, timing error, location error, custody defect, data-quality defect, signal-quality defect, physical tampering, spoofing, replay, drift, missing data, stale data, corrupted data, unsafe sensor placement, unsafe sensor exposure, public-safe sensor defect, community sensor defect, health-sensitive sensor defect, infrastructure-sensitive sensor defect, provider-supplied sensor defect, host-supplied sensor defect, operator-supplied sensor defect, or correction failure affecting Observatory sensor evidence.

9.27.5(b) Sensor incident records shall identify incident title or identifier, sensor identity where safe, sensor class, reference sensor relationship where any, source, custodian, host context where any, operator context where any, provider context where any, community context where any, public authority context where any, location or safe-location treatment, timing, calibration status, configuration status, firmware status, maintenance status, affected data classes, affected evidence classes, affected output classes, affected dashboards, affected maps, affected Evidence Packs, affected public-safe summaries, suspected or confirmed status, severity where used, confidence, uncertainty, public-safe status, containment actions, correction path, and dependency links.

9.27.5(c) Sensor incident containment may include sensor isolation, data quarantine, calibration review, reference sensor comparison, source downgrade, confidence downgrade, uncertainty revision, dashboard restriction, map restriction, API restriction, Evidence Pack correction, public-safe summary correction, provider notice, host notice, operator notice, community notice where appropriate and safe, public authority notice where appropriate, and output withdrawal where required.

9.27.5(d) Sensor incident review shall assess device identity, custody, calibration, configuration, firmware, maintenance, timing, location or safe-location treatment, data quality, signal quality, tamper risk, spoof risk, replay risk, data lineage, source lineage, public-safe classification, privacy impact, cybersecurity impact, infrastructure impact, health-sensitive impact, community safeguard impact, protected knowledge impact, public authority impact, provider-neutrality impact, sponsor non-control impact, host-boundary impact, operator-boundary impact, and correctionability.

9.27.5(e) Sensor incidents shall preserve the distinction between sensor failure, evidence failure, system failure, public authority warning, emergency command, operator instruction, infrastructure operation, procurement consequence, finance consequence, certification consequence, recognition consequence, protocol consequence, and execution consequence.

9.27.5(f) Sensor incident handling shall not create public warning, emergency command, public authority decision, regulatory finding, procurement approval, finance-readiness, security certification, sensor certification, provider endorsement, sponsor approval, host approval, operator approval, operational clearance, deployment approval, protocol effect, market authority, legal status, or execution consequence by default.

9.27.5(g) Where sensor incident evidence affects downstream materials, GCRI Canada shall review and update affected source comparison records, confidence records, uncertainty records, dashboards, maps, APIs, digital twins, Evidence Packs, Decision Packs, public-safe outputs, GRF inputs, GRA inputs, Protocol Authority inputs, public authority learning materials, community-facing materials, provider-facing materials, host-facing materials, operator-facing materials, Academy materials, and public claims.

9.27.5(h) The controlling rule shall be that sensor incidents must correct what was measured, what was inferred, what was displayed, and what was relied upon.

***

9.27.6 AI-RAN / Network Incident.\
9.27.6(a) An AI-RAN, O-RAN, private wireless, or network incident shall mean any suspected or confirmed event involving network signal failure, telemetry failure, network outage, connectivity loss, degraded connectivity, timing defect, location defect, signal-quality defect, interference, spoofing, cyber compromise, edge intelligence defect, AI-assisted network inference error, metadata exposure, location exposure, public authority sensitivity defect, infrastructure sensitivity defect, provider equipment defect, operator interface defect, host connectivity defect, degraded-mode defect, dashboard defect, map defect, API defect, or correction failure affecting Observatory network evidence.

9.27.6(b) Network incident records shall identify incident title or identifier, network type, signal class, telemetry class, affected Node, Hub, Cluster, Hotspot, Regional Observatory Cluster, National Dense Nexus Core, provider where any, operator where any, host where any, public authority context where any, community context where any, affected data classes, affected evidence classes, affected output classes, affected dashboards, affected maps, affected APIs, affected Evidence Packs, affected public-safe summaries, suspected or confirmed status, severity where used, confidence, uncertainty, public-safe status, containment actions, correction path, and dependency links.

9.27.6(c) Network incident containment may include network telemetry quarantine, signal-source downgrade, affected interface restriction, edge system isolation, dashboard restriction, map restriction, API restriction, public-safe output restriction, provider notice, operator notice, host notice, public authority notice where appropriate, community notice where appropriate and safe, compute workload suspension, model output suspension, and degraded-mode classification.

9.27.6(d) Network incident review shall assess network access, signal integrity, telemetry integrity, timing, location treatment, metadata sensitivity, privacy impact, cybersecurity impact, public authority sensitivity, infrastructure sensitivity, provider role, operator role, host role, edge intelligence status, interference risk, spoofing risk, cyber-physical dependency risk, degraded-mode status, public-safe disclosure limits, finance-boundary impact, procurement-boundary impact, provider-neutrality impact, sponsor non-control impact, and correctionability.

9.27.6(e) Network incident evidence shall not be presented as telecommunications regulatory finding, public warning, emergency command, provider ranking, procurement approval, finance-readiness, certification, recognition, protocol effect, service assurance, operational clearance, host approval, operator approval, deployment approval, infrastructure operation, market authority, or execution instruction by default.

9.27.6(f) Where network incidents affect AI-RAN evidence, O-RAN evidence, private wireless evidence, DePIN evidence, sensor evidence, cyber telemetry, digital twins, dashboards, maps, APIs, Evidence Packs, Decision Packs, public-safe outputs, GRF inputs, GRA inputs, Protocol Authority inputs, public authority learning materials, host readiness materials, provider materials, operator materials, community materials, Academy materials, or public claims, GCRI Canada shall correct, restrict, supersede, withdraw, reissue, or notify affected interfaces as appropriate.

9.27.6(g) Network incident handling by GCRI Canada shall not make GCRI Canada a telecommunications operator, network operator, public authority, regulator, emergency-management actor, public warning issuer, provider, sponsor, host, operator, procurement actor, finance actor, certifier, Protocol Authority, or execution actor by default.

9.27.6(h) The controlling rule shall be that AI-RAN and network incidents affect Observatory evidence and continuity; they do not authorize GCRI Canada to regulate, warn, command, operate, procure, certify, finance, or execute.

***

9.27.7 DePIN or Proof Incident.\
9.27.7(a) A DePIN or proof incident shall mean any suspected or confirmed event involving device identity defect, hardware identity defect, location claim defect, uptime claim defect, availability claim defect, capacity claim defect, coverage claim defect, service claim defect, proof-of-competence defect, proof-of-coverage defect, proof-of-availability defect, proof-of-integrity defect, proof-of-observation defect, proof receipt defect, ledger anchoring defect, token-related overclaim, tamper risk, spoof risk, fraud risk, incentive manipulation, public-safe claim defect, privacy defect, location exposure, community exposure, public authority confusion, provider overclaim, sponsor overclaim, host overclaim, or correction failure affecting DePIN or proof evidence.

9.27.7(b) DePIN or proof incident records shall identify incident title or identifier, device or proof identity where safe, hardware identity where material, proof class, ledger relationship where any, token relationship where any, source, custodian, provider where any, host where any, operator where any, community context where any, public authority context where any, affected data classes, affected evidence classes, affected output classes, affected dashboards, affected maps, affected APIs, affected Evidence Packs, affected public-safe summaries, suspected or confirmed status, severity where used, confidence, uncertainty, public-safe status, containment actions, correction path, and dependency links.

9.27.7(c) DePIN or proof incident containment may include device-source restriction, proof-source restriction, proof receipt revocation or correction, anchoring correction, dashboard restriction, map restriction, API restriction, Evidence Pack correction, public-safe summary correction, provider notice, host notice, operator notice, public authority notice where appropriate, community notice where appropriate and safe, and dependency review.

9.27.7(d) DePIN or proof incident review shall assess device identity, hardware identity, custody, proof method, proof source, proof timing, proof integrity, proof reproducibility where appropriate, ledger anchoring status, token relationship, incentive effects, tamper risk, spoof risk, fraud risk, privacy impact, location sensitivity, community safeguard impact, public authority impact, infrastructure impact, provider-neutrality impact, sponsor non-control impact, host-boundary impact, finance-boundary impact, procurement-boundary impact, and correctionability.

9.27.7(e) DePIN tokens, ledger entries, proof receipts, cryptographic anchors, hashes, signatures, timestamps, dashboards, maps, proof summaries, or public-safe claims shall not be treated as authority, truth, certification, recognition, finance-readiness, procurement approval, public authority decision, public warning, provider preference, sponsor approval, host approval, operator instruction, protocol effect, market entitlement, deployment approval, or execution consequence by default.

9.27.7(f) Where DePIN or proof incidents affect public-safe outputs, GRF inputs, GRA inputs, Protocol Authority inputs, Nexus Risk Management inputs, Nexus Rails materials, public authority learning materials, provider materials, sponsor materials, host materials, operator materials, community materials, Academy materials, dashboards, maps, APIs, Evidence Packs, Decision Packs, or public claims, GCRI Canada shall correct, restrict, revoke, supersede, withdraw, reissue, or notify affected interfaces as appropriate.

9.27.7(g) DePIN or proof incident handling shall not create a token right, market right, public authority status, protocol effect, finance-readiness, procurement status, certification, recognition, provider ranking, sponsor validation, host approval, operational clearance, legal status, or execution consequence by default.

9.27.7(h) The controlling rule shall be that proof evidence is only as valid as its identity, method, custody, context, limits, and correction path; proof is not authority by default.

***

9.27.8 Dashboard or Public-Safe Publication Incident.\
9.27.8(a) A dashboard or public-safe publication incident shall mean any suspected or confirmed event involving dashboard error, map error, API error, dataset publication error, report error, technical note error, visualization error, stale-data display, incorrect timestamp, incorrect version, source-lineage omission, confidence-display defect, uncertainty-display defect, limitation omission, public-safe omission failure, unsafe disclosure, false precision, misleading visual design, overclaim, public authority confusion, public warning implication, finance overclaim, procurement implication, certification implication, recognition implication, protocol implication, provider preference, sponsor validation, host approval implication, operator instruction implication, community consent implication, protected knowledge exposure, privacy defect, cybersecurity defect, or correction failure in Observatory publication.

9.27.8(b) Dashboard or publication incident records shall identify incident title or identifier, output title or identifier, output class, publication channel, affected audience, affected source records, affected data records, affected method records, affected compute records where applicable, affected model records where applicable, affected dashboard records, affected map records, affected API records, affected Evidence Packs, affected Decision Packs, affected public-safe summaries, affected interfaces, affected public claims, suspected or confirmed status, severity where used, confidence, uncertainty, public-safe status, containment actions, correction path, and dependency links.

9.27.8(c) Containment may include dashboard restriction, map restriction, API restriction, dataset removal, report correction, technical note correction, visualization replacement, public-safe summary correction, controlled annex restriction, restricted annex access review, publication pause, citation warning, public-safe notice, controlled notice, withdrawal, retraction, supersession, archive marking, and misuse-response action.

9.27.8(d) Dashboard or publication incident review shall assess update status, timestamp, version, source lineage, data classification, lawful basis, confidence, uncertainty, limitations, public-safe omissions, boundary language, accessibility, translation, map precision, dashboard logic, API fields, dataset metadata, export behavior, screenshot risk, media risk, public authority reference controls, provider reference controls, sponsor reference controls, host reference controls, operator reference controls, community safeguard controls, protected knowledge controls, finance-boundary controls, procurement-boundary controls, and correctionability.

9.27.8(e) Where publication incident materials have been copied, downloaded, screenshot, embedded, forked, quoted, translated, API-reused, media-reused, provider-reused, sponsor-reused, public authority-reused, finance-reused, procurement-reused, or publicly referenced, GCRI Canada shall take proportionate correction and misuse-response steps appropriate to the risk and available control.

9.27.8(f) Dashboard or publication incident handling shall not itself create public warning, emergency command, public authority decision, regulatory finding, procurement approval, finance-readiness, certification, recognition, rating, guarantee, provider endorsement, sponsor finding, host finding, operator instruction, protocol effect, operational clearance, legal status, market authority, deployment approval, or execution consequence by default.

9.27.8(g) Where a public-safe publication incident reveals systemic publication weakness, GCRI Canada shall update public-safe publication methods, dashboard methods, map methods, API methods, boundary language, correction paths, training, assurance, and Board or committee reporting where material.

9.27.8(h) The controlling rule shall be that publication incidents must be corrected not only in the source record, but wherever the public-safe output has traveled or may reasonably be misread.

***

9.27.9 Public Authority Misdescription Incident.\
9.27.9(a) A public authority misdescription incident shall mean any suspected or confirmed event involving incorrect, unauthorized, ambiguous, misleading, overclaimed, stale, or unsafe description of a public authority, public official, public employee, regulator, public finance body, emergency-management body, public health body, public safety body, public infrastructure operator, public procurement actor, public funding actor, Crown or state entity, intergovernmental body, Indigenous public governance body where applicable, jurisdiction, agency, office, title, logo, mark, seal, quote, photograph, attendance, data contribution, review, dashboard access, map access, public-safe output role, or interface status.

9.27.9(b) Public authority misdescription incident records shall identify incident title or identifier, public authority reference, affected publication or interface, affected output class, affected audience, capacity classification, official or non-official status, permitted reference, prohibited reference, public-safe status, public authority review status, affected dashboards, affected maps, affected Evidence Packs, affected Decision Packs, affected public-safe summaries, affected media or public claims where any, suspected or confirmed status, severity where used, confidence, uncertainty, containment actions, correction path, and dependency links.

9.27.9(c) Public authority misdescription includes any statement, design, logo use, title use, quote use, photograph use, attendance reference, data contribution reference, dashboard access reference, review reference, jurisdictional reference, or public claim that implies endorsement, adoption, approval, delegation, official guidance, regulatory determination, compliance determination, enforcement position, procurement approval, funding approval, public finance approval, public warning, emergency command, public-law status, certification, recognition, finance-readiness, provider preference, sponsor approval, host approval, operator instruction, deployment approval, legal status, market authority, or execution consequence where such meaning is not recorded and authorized.

9.27.9(d) Containment may include removal of public authority reference, reference correction, logo removal, quote removal, photograph removal, title correction, attendance correction, data contribution correction, capacity reclassification, dashboard correction, map correction, public-safe summary correction, public-safe clarification, controlled notice, public authority notice, publication withdrawal, retraction, supersession, archive marking, and misuse-response action.

9.27.9(e) Public authority silence, attendance, review, data contribution, dashboard access, map access, edits, comments, non-objection, funding interest, procurement interest, public finance interest, regulator-listening participation, emergency-management participation, public health participation, or public safety participation shall not cure a misdescription unless the competent public authority provides express recorded clarification authorizing the relevant meaning.

9.27.9(f) Public authority misdescription correction shall itself avoid creating a public warning, official guidance, regulatory finding, public authority decision, endorsement, procurement signal, finance signal, certification, recognition, provider preference, sponsor approval, host approval, operator instruction, or execution consequence.

9.27.9(g) Where public authority misdescription affects downstream materials, GCRI Canada shall review affected public-safe outputs, Evidence Packs, Decision Packs, dashboards, maps, APIs, GRF inputs, GRA inputs, Protocol Authority inputs, Nexus Risk Management materials, Nexus Rails materials, Academy materials, provider materials, sponsor materials, host materials, operator materials, community materials, media materials, repositories, and public claims.

9.27.9(h) The controlling rule shall be that public authority references must be corrected with urgency because public authority ambiguity can convert evidence learning into perceived public power.

***

9.27.10 Community Safeguard or Protected Knowledge Incident.\
9.27.10(a) A community safeguard or protected knowledge incident shall mean any suspected or confirmed event involving extraction concern, unsafe community data use, unsafe Indigenous data use where applicable, protected knowledge exposure, sensitive-site exposure, cultural-site exposure, sacred-site exposure, source exposure, misattribution, decontextualization, mistranslation, accessibility failure, unsafe mapping, unsafe dashboarding, unsafe digital twin display, unsafe AI use, unauthorized retrieval, unauthorized embedding, unauthorized training, community consent implication, Indigenous consent implication where applicable, grievance mishandling, withdrawal mishandling, challenge mishandling, remedy failure, group harm risk, re-identification risk, stigmatization, public authority misuse, provider misuse, sponsor misuse, host misuse, operator misuse, finance-facing misuse, procurement-facing misuse, media misuse, or correction failure affecting community, Indigenous, local, territorial, environmental, or protected knowledge interfaces.

9.27.10(b) Community safeguard or protected knowledge incident records shall identify incident title or identifier, affected community context where safe and appropriate, Indigenous context where applicable, local or territorial context, knowledge class, affected materials, affected data classes, affected evidence classes, affected output classes, affected maps, dashboards, APIs, digital twins, Evidence Packs, Decision Packs, public-safe summaries, affected interfaces, suspected or confirmed status, severity where used, confidence, uncertainty, public-safe status, interim restrictions, containment actions, grievance status where any, remedy status where any, correction path, and dependency links.

9.27.10(c) Containment may include access restriction, map removal, dashboard restriction, API restriction, digital twin layer restriction, protected knowledge sealing, data deletion where appropriate, retrieval suspension, embedding store restriction, AI-use suspension, provider access suspension, sponsor access suspension, public authority routing suspension, finance-facing routing suspension, procurement-facing routing suspension, public-safe output withdrawal, controlled notice, community notice where appropriate and safe, and affected-interface review.

9.27.10(d) Review shall assess community protocols, Indigenous protocols where applicable, consent or non-consent treatment, withdrawal pathways, grievance pathways, remedy pathways, challenge pathways, source protection, sensitive-site treatment, public-safe mapping controls, translation, accessibility, localization, privacy, cybersecurity, sovereign data, protected knowledge restrictions, public authority boundary, finance boundary, procurement boundary, provider-neutrality, sponsor non-control, host boundary, operator boundary, public-safe publication, and correctionability.

9.27.10(e) GCRI Canada shall not treat community safeguard incidents as merely communications issues where the incident involves rights, dignity, safety, protected knowledge, data sovereignty, re-identification, group harm, consent, non-consent, withdrawal, grievance, remedy, challenge, or correction.

9.27.10(f) Community safeguard or protected knowledge incident handling shall not create community consent, Indigenous consent, community endorsement, Indigenous approval, public authority decision, procurement approval, finance-readiness, certification, recognition, provider endorsement, sponsor approval, host approval, operator approval, protocol effect, deployment approval, operational clearance, legal status, market authority, public warning, emergency command, or execution consequence by default.

9.27.10(g) Where a community safeguard or protected knowledge incident affects public-facing materials or controlled interfaces, GCRI Canada shall review affected dependencies and issue public-safe, controlled, or community-specific correction, withdrawal, retraction, supersession, notice, or remedy action where appropriate and safe.

9.27.10(h) The controlling rule shall be that incidents affecting communities or protected knowledge are safeguard failures first; evidence usefulness must yield to people, places, dignity, protected knowledge, and correction.

***

9.27.11 Provider, Sponsor, Host, or Public Claim Incident.\
9.27.11(a) A provider, sponsor, host, or public claim incident shall mean any suspected or confirmed event involving overclaim, misuse, unauthorized public statement, misleading acknowledgment, logo misuse, quote misuse, case study misuse, provider preference implication, procurement implication, finance implication, certification implication, recognition implication, public authority endorsement implication, protocol implication, sponsor validation, host approval implication, operator approval implication, community consent implication, public warning implication, emergency-command implication, deployment approval implication, market signal implication, or execution implication arising from or relating to Observatory participation, support, contribution, publication, interface use, or public claims.

9.27.11(b) Incident records under this section shall identify actor, actor role, claim, publication channel, audience, affected Observatory output, affected Evidence Pack, affected Decision Pack, affected dashboard, affected map, affected API, affected public-safe summary, affected public authority reference, affected community reference, affected provider reference, affected sponsor reference, affected host reference, affected operator reference, affected GRF interface, affected GRA interface, affected Protocol Authority interface, suspected or confirmed status, severity where used, confidence, uncertainty, public-safe status, containment actions, correction path, and dependency links.

9.27.11(c) Provider claim incidents may include claims that a provider is approved, preferred, certified, recognized, procurement-ready, finance-ready, public authority-endorsed, GCRI Canada-endorsed, protocol-effective, Nexus-compatible, security-certified, operationally cleared, deployment-approved, superior, ranked, selected, or execution-ready by reason of Observatory participation.

9.27.11(d) Sponsor claim incidents may include claims that a sponsor controls, directs, approves, validates, owns, purchases, funds outcomes, determines evidence, determines public-safe publication, determines public authority access, determines provider selection, determines host selection, determines community engagement, determines GRF outcomes, determines GRA outcomes, determines Protocol Authority outcomes, or receives status by reason of support.

9.27.11(e) Host claim incidents may include claims that a host is certified, approved, ready, safe, public authority-approved, procurement-ready, finance-ready, investment-ready, insurance-ready, provider-preferred, sponsor-approved, community-approved, deployment-approved, operationally cleared, or execution-ready by reason of Observatory participation, site access, data contribution, dashboard visibility, map visibility, Evidence Pack inclusion, or public-safe summary inclusion.

9.27.11(f) Public claim incidents may include media, website, presentation, repository, public authority, provider, sponsor, host, operator, National Company, Project SPV, finance-facing, procurement-facing, Academy, community-facing, or public statements that overstate GCRI Canada’s role, Observatory outputs, public authority meaning, finance meaning, procurement meaning, certification meaning, recognition meaning, provider status, sponsor status, host status, operator status, community consent, protocol effect, public warning, emergency command, or execution consequence.

9.27.11(g) Containment may include correction request, removal request, relabeling request, logo removal, quote removal, case study revision, acknowledgement revision, access restriction, interface suspension, public-safe clarification, controlled clarification, provider notice, sponsor notice, host notice, operator notice, public authority notice, GRF notice, GRA notice, Protocol Authority notice, National Company notice, Project SPV notice, legal notice, withdrawal, retraction, supersession, archive marking, or termination of support where appropriate.

9.27.11(h) Claim correction shall not itself create endorsement, procurement approval, finance-readiness, certification, recognition, public authority decision, provider preference, sponsor finding, host finding, operator finding, community consent, rating, guarantee, public warning, emergency command, protocol effect, operational clearance, legal status, market authority, deployment approval, or execution consequence by default.

9.27.11(i) The controlling rule shall be that public claim incidents must be corrected quickly because public statements can convert participation into perceived endorsement, procurement, finance, certification, recognition, authority, or execution unless actively bounded.

***

9.27.12 Severity Classification, Intake, Triage, Containment, Notification, Correction, Post-Incident Review, and Learning Loop.\
9.27.12(a) GCRI Canada shall maintain severity classification, intake, triage, containment, notification, correction, post-incident review, assurance, training update, method update, technical-control update, interface update, and learning-loop methods for Observatory incidents.

9.27.12(b) Severity classification shall consider harm to persons, communities, protected knowledge, public authorities, hosts, operators, providers, sponsors, infrastructure, systems, data, evidence integrity, public-safe publication, privacy, cybersecurity, sovereign data, finance boundaries, procurement boundaries, public authority boundaries, provider neutrality, sponsor non-control, correctionability, institutional trust, and downstream dependency.

9.27.12(c) Incident intake shall permit reports from GCRI Canada personnel, directors, officers, contractors, vendors, providers, sponsors, hosts, operators, public authorities, community participants, Indigenous governance bodies where applicable, knowledge holders, universities, GRF, GRA, Protocol Authority, Nexus entities, National Companies, Project SPVs, media observers, public users, or other affected or informed actors, subject to safe reporting, confidentiality, source protection, and non-retaliation where applicable.

9.27.12(d) Triage shall classify incident type, severity, affected systems, affected data, affected outputs, affected interfaces, affected audiences, affected records, affected dependencies, immediate containment needs, public-safe risks, legal risks, notification obligations, correction needs, and reviewer assignment.

9.27.12(e) Containment shall be proportionate to incident type and severity and may include access restriction, access revocation, system isolation, interface suspension, dashboard restriction, map restriction, API restriction, repository restriction, compute suspension, model suspension, retrieval suspension, embedding restriction, sensor isolation, public-safe output withdrawal, publication pause, controlled-room restriction, data sealing, deletion where appropriate, public-safe clarification, controlled notice, or other measures necessary to prevent harm and continued reliance.

9.27.12(f) Notification shall be made where required or appropriate by law, agreement, data-sharing terms, public authority terms, community safeguards, protected knowledge safeguards, provider terms, sponsor terms, host terms, operator terms, insurance terms, Board or committee governance, or public-safe discipline. Notification shall be bounded, source-conscious, public-safe, non-defamatory, non-regulatory, non-public-warning unless issued by competent public authority, non-financial, non-procurement, non-certifying, non-recognizing, non-protocol-conferring, non-provider-preferential, non-sponsor-validating, non-host-approving, non-operator-commanding, non-executing, and correction-focused.

9.27.12(g) Correction shall identify corrected sources, corrected data classes, corrected evidence classes, corrected output classes, corrected method records, corrected compute records, corrected model records, corrected dashboard records, corrected map records, corrected API records, corrected public-safe outputs, corrected boundary language, corrected interface records, prior status, corrected status, effective date, reviewer, affected dependencies, notice decision, access change, archive treatment, and continuing limitations.

9.27.12(h) Post-incident review shall identify root causes where appropriate, contributing factors, control failures, evidence integrity effects, data integrity effects, public-safe effects, privacy effects, cybersecurity effects, sovereign data effects, public authority effects, community safeguard effects, protected knowledge effects, provider-neutrality effects, sponsor non-control effects, host-boundary effects, operator-boundary effects, finance-boundary effects, procurement-boundary effects, correction effectiveness, residual risk, corrective action plans, training updates, method updates, technical-control updates, interface agreement updates, assurance updates, and Board or committee reporting where material.

9.27.12(i) The learning loop shall ensure that incident findings inform Observatory methods, data governance, cybersecurity, AI governance, sensor methods, AI-RAN methods, DePIN methods, dashboard methods, public-safe publication methods, public authority interface methods, community safeguard methods, provider and sponsor interface methods, host readiness methods, maturity evidence methods, Evidence Pack methods, assurance procedures, training, and future correction discipline.

9.27.12(j) Incident records shall be linked, where applicable, to National Dense Core records, Regional Observatory Cluster records, Cluster records, Hub records, Node records, Hotspot records, host readiness records, maturity evidence records, Observatory Evidence Pack Register entries, Observatory data records, cybersecurity records, AI-RAN records, DePIN records, sensor records, geospatial records, cyber telemetry records, digital twin records, dashboard records, degraded-mode records, sovereign compute records, public authority interface records, community interface records, provider and sponsor interface records, Observatory Methods Register entries, Evidence Register entries, Source Comparison Records, Dataset Register entries, Model Register entries, System Card entries, Benchmark Card entries, Compute Workload Records, Compute Environment Records, Inference Records, Human Review Records, Retrieval and Embedding Records, Proof Receipt Records, Public-Safe Output Records, AI Incident Records, Correction Records, Dependency Records, Truth Engine Records, Nexus Risk Management records, GRF interface records, GRA interface records, Protocol Authority interface records, RNFD records, Nexus Rails records, Regional Nexus Consortium records, National Nexus Consortium records, National Company records, Project SPV records, operator records, provider records, sponsor records, host records, community records, university records, Nexus interface records, publication records, and public claims records.

9.27.12(k) Severity classifications, incident records, intake records, triage records, containment records, notification records, correction records, post-incident review records, learning-loop records, assurance records, notices, and closeout shall not create certification, recognition, finance-readiness, public authority decision, regulatory finding, procurement approval, funding approval, public finance approval, provider endorsement, sponsor approval, host approval, operator approval, community consent, Indigenous consent, rating, guarantee, public warning, emergency command, security certification, protocol effect, operational clearance, legal status, market authority, infrastructure operation, remediation approval, deployment approval, national authority, regional authority, GRF maturity record, GRA finance-readiness, or execution consequence by default.

9.27.12(l) The controlling rule shall be that Observatory incident handling is complete only when the incident is classified, contained, corrected, notified where required, learned from, linked to dependencies, closed out, and prevented from becoming unsupported authority, unsafe publication, uncorrected evidence, or repeated failure.

### 9.28 Observatory Interface With Nexus Universe

9.28.1 Observatory Role in Nexus Universe Planning, Build, Live Operation, Teardown, Review, and Renewal.\
9.28.1(a) GCRI Canada may steward Observatory interface methods for Nexus Universe planning, controlled build, live operation evidence, teardown, after-action review, correction, Docket review, Grid review, renewal, and upgrade cycles as a structured evidence, observability, methods, public-safe, correction, and learning discipline for time-bounded, place-bounded, event-bounded, demonstration-bounded, simulation-bounded, laboratory-bounded, training-bounded, or controlled-room Nexus Universe activities.

9.28.1(b) Nexus Universe Observatory interfaces may support one-year planning evidence, one-month controlled build evidence, one-week live operation evidence, post-event teardown evidence, after-action evidence, correction evidence, Docket evidence, Grid evidence, upgrade evidence, sponsor and provider contribution records, host readiness evidence, public authority learning evidence, community safeguard evidence, capital-reader learning evidence, public-safe outputs, dashboards, maps, simulations, demonstrations, technical notes, Evidence Packs, Decision Packs, Academy materials, GRF inputs, GRA inputs, Protocol Authority inputs, Nexus Risk Management inputs, Nexus Rails inputs, National Nexus Consortium inputs, National Company inputs, Project SPV inputs, and renewal records.

9.28.1(c) GCRI Canada’s Observatory role in Nexus Universe shall be evidence-supporting, methods-supporting, observability-supporting, public-safe, non-executing, source-lined, confidence-aware, uncertainty-aware, limitation-aware, boundary-valid, and correctionable. It shall not make GCRI Canada the owner, operator, producer, event manager, emergency commander, public warning issuer, infrastructure operator, procurement actor, finance actor, sponsor, provider, host, operator, certifier, recognizer, Protocol Authority, National Company, Project SPV, or execution actor by default.

9.28.1(d) Nexus Universe planning, build, live operation, teardown, review, and renewal evidence shall preserve the distinction between event evidence, technical demonstration, laboratory output, simulation output, dashboard output, public-safe output, sponsor support, provider contribution, host participation, public authority learning, community participation, capital-reader literacy, GRF input, GRA input, Protocol Authority input, National Company relevance, Project SPV relevance, and any separate authority-bearing, finance-bearing, procurement-bearing, certification-bearing, recognition-bearing, protocol-bearing, operational, deployment, or execution decision made by a competent actor.

9.28.1(e) Observatory methods for Nexus Universe shall be records-valid, source-lined, time-bounded, audience-aware, classification-aware, confidence-aware, uncertainty-aware, limitation-aware, privacy-protective, cybersecurity-controlled, sovereignty-compatible, public-authority-bounded, community-sensitive, Indigenous-safeguard-aware where applicable, protected-knowledge-sensitive, provider-neutral, sponsor-independent, host-bounded, operator-bounded, finance-safe, procurement-safe, public-safe, non-certifying, non-recognizing, non-executing, and correctionable.

9.28.1(f) Evidence generated through a Nexus Universe event, lab, demonstration, simulation, dashboard, live room, control room, field site, data room, clean room, public authority room, sponsor-supported venue, provider-supported system, host-supported facility, community interface, or capital-reader session shall not be overread by reason of immediacy, visibility, audience presence, media attention, public authority attendance, sponsor visibility, provider participation, host contribution, capital-reader interest, dashboard polish, map precision, technical intensity, proof receipts, or controlled-room discipline.

9.28.1(g) Where Nexus Universe Observatory evidence is used externally or publicly, GCRI Canada shall preserve controlled vocabulary, source lineage, event context, time-bound status, confidence, uncertainty, limitations, public-safe status, sponsor non-control, provider neutrality, host boundary, public authority capacity classification, community safeguard treatment, no-public-warning language, no-emergency-command language, no-certification language, no-recognition language, no-finance-readiness language, no-procurement language, no-protocol-effect language unless separately created by Protocol Authority, no-provider-endorsement language, no-sponsor-approval language, no-host-approval language, no-operator-instruction language, no-deployment-approval language, no-execution language, and correction path.

9.28.1(h) The controlling rule shall be that Nexus Universe may make evidence visible in time, space, and practice, but event visibility shall not become authority, certification, recognition, finance, procurement, public warning, command, protocol effect, or execution by GCRI Canada.

***

9.28.2 One-Year Planning Evidence Methods.\
9.28.2(a) GCRI Canada may steward one-year planning evidence methods for Nexus Universe activities to support structured preparation, evidence scoping, methods design, data governance, public-safe planning, interface planning, sponsor and provider boundary planning, host readiness planning, public authority learning planning, community safeguard planning, protected knowledge review, cybersecurity planning, sovereign data planning, simulation planning, dashboard planning, Docket planning, Grid planning, and correction planning.

9.28.2(b) One-year planning evidence records shall identify the planned Nexus Universe purpose, event or program scope, relevant jurisdictions, public-good purpose, technology domains, risk domains, proposed Nodes, Hubs, Clusters, Hotspots, Regional Observatory Cluster relationships, National Dense Nexus Core relationships where any, host candidates, provider candidates, sponsor candidates, public authority interfaces, community interfaces, capital-reader interfaces, data classes, evidence classes, output classes, access classes, handling classes, public-safe publication intentions, controlled annex intentions, restricted annex intentions, and correction paths.

9.28.2(c) Planning evidence shall include, where material, source scoping, dataset scoping, lawful basis review, data rights review, cross-border review, sovereign compute review, cybersecurity review, AI-use review, model-governance review, dashboard and map design review, public-safe publication review, public authority capacity classification, community safeguard design, protected knowledge safeguards, provider conflict review, sponsor conflict review, host readiness review, operator-boundary review, finance-boundary review, procurement-boundary review, certification-boundary review, recognition-boundary review, protocol-boundary review, and assurance plan.

9.28.2(d) One-year planning evidence shall not be represented as final readiness, event approval, deployment approval, host certification, provider approval, sponsor validation, public authority adoption, finance-readiness, procurement approval, certification, recognition, Protocol Authority effect, public warning readiness, emergency-command readiness, operational clearance, market signal, or execution authorization.

9.28.2(e) Planning artifacts, concept notes, architecture diagrams, roadmaps, draft dashboards, draft maps, draft Evidence Packs, draft Decision Packs, sponsor decks, provider materials, host materials, public authority learning materials, community engagement plans, capital-reader literacy materials, and media materials shall be marked and governed according to their draft, provisional, controlled, public-safe, restricted, superseded, or approved-for-specific-use status.

9.28.2(f) Where one-year planning evidence involves sponsors, providers, hosts, public authorities, communities, Indigenous or protected knowledge holders, universities, National Companies, Project SPVs, GRF, GRA, Protocol Authority, Nexus Risk Management, Nexus Rails, or capital readers, GCRI Canada shall preserve legal separateness, role separation, support-without-control, provider neutrality, host boundaries, public authority boundaries, community safeguards, finance boundaries, procurement boundaries, protocol boundaries, and correction paths.

9.28.2(g) Where planning assumptions change, proposed participants withdraw, public-safe risks emerge, sponsor or provider conflicts arise, public authority status changes, community safeguards require revision, data authority is unclear, cybersecurity risk increases, sovereign data treatment changes, or correction is required, GCRI Canada shall revise, restrict, supersede, withdraw, or reissue planning evidence as appropriate.

9.28.2(h) The controlling rule shall be that one-year planning evidence prepares the conditions for disciplined Nexus Universe learning, but it does not pre-approve the event, actors, systems, finance, procurement, certification, recognition, protocol effect, or execution.

***

9.28.3 One-Month Controlled Build Evidence Methods.\
9.28.3(a) GCRI Canada may steward one-month controlled build evidence methods for Nexus Universe activities to support controlled preparation of systems, rooms, dashboards, maps, datasets, compute environments, sensors, AI-RAN components, DePIN components, cyber telemetry components, digital twin components, public authority interfaces, community interfaces, provider interfaces, sponsor interfaces, host interfaces, operator interfaces, public-safe outputs, Evidence Packs, Decision Packs, and correction paths.

9.28.3(b) Controlled build evidence records shall identify build purpose, build period, build scope, build owner or steward where applicable, system components, data components, compute components, model components, sensor components, connectivity components, dashboard components, map components, API components, public-safe components, room components, access controls, handling classes, public-safe status, testing status, review status, open issues, unresolved risks, and correction path.

9.28.3(c) Controlled build methods shall include, where material, access review, identity review, room-rule review, data classification review, lawful basis review, cybersecurity review, patch and configuration review, key and credential review, compute workload review, model and AI-use review, sensor calibration review, AI-RAN or network readiness review, DePIN proof readiness review, dashboard and map review, public-safe review, public authority reference review, provider reference review, sponsor reference review, host reference review, community safeguard review, protected knowledge review, and incident path testing.

9.28.3(d) Controlled build evidence may identify whether components are configured, tested, partially tested, untested, simulated, sandboxed, staged, restricted, public-safe-cleared, controlled-room-only, restricted-annex-only, correction-pending, assurance-pending, or not ready for use, provided that such status is not converted into certification, approval, finance-readiness, procurement readiness, recognition, protocol effect, public authority adoption, operational clearance, or execution authorization.

9.28.3(e) One-month controlled build activities shall not permit sponsor control, provider preference, host control, public authority confusion, community extraction, protected knowledge exposure, public-safe overclaim, data overexposure, AI overreach, cybersecurity bypass, public warning implication, finance overclaim, procurement implication, certification implication, recognition implication, protocol implication, or execution drift.

9.28.3(f) Demonstration materials, test dashboards, rehearsal maps, simulated outputs, draft reports, draft Evidence Packs, draft Decision Packs, sandbox outputs, internal screenshots, provider demonstrations, sponsor briefings, host briefings, public authority previews, community previews, and capital-reader previews shall carry draft, controlled, simulated, rehearsal, non-public-safe, or public-safe status as applicable and shall not be reused outside their recorded purpose.

9.28.3(g) Where controlled build evidence identifies defects, unresolved risks, unsafe publication conditions, unapproved references, data defects, access defects, cybersecurity defects, model defects, sensor defects, network defects, provider conflicts, sponsor influence, host boundary issues, public authority ambiguity, community safeguard gaps, protected knowledge risks, or correction defects, GCRI Canada shall restrict, correct, delay, remove, retest, downgrade, supersede, or refuse affected build components as appropriate.

9.28.3(h) The controlling rule shall be that one-month controlled build evidence shows whether systems and safeguards are prepared for controlled learning, not whether actors, sites, systems, providers, sponsors, hosts, finance, procurement, certification, recognition, protocol effect, or execution have been approved.

***

9.28.4 One-Week Live Operation Evidence Methods.\
9.28.4(a) GCRI Canada may steward one-week live operation evidence methods for Nexus Universe activities to support source-lined, time-bounded, controlled, public-safe, confidence-aware, uncertainty-aware, limitation-aware, and correctionable recording of live evidence, live dashboards, live maps, live rooms, live simulations, live demonstrations, live public authority learning, live community safeguards, live provider interfaces, live sponsor interfaces, live host interfaces, live operator interfaces, live capital-reader literacy, live incident handling, live degraded-mode awareness, and live correction workflows.

9.28.4(b) Live operation evidence records shall identify live period, live scope, participating systems, active rooms, active dashboards, active maps, active APIs, active sensors, active networks, active compute workloads, active models, active datasets, active providers, active sponsors, active hosts, active operators, active public authority interfaces, active community interfaces, active capital-reader interfaces, access status, public-safe status, update status, incident status, correction status, and dependency links.

9.28.4(c) Live evidence shall distinguish real-time evidence, near-real-time evidence, delayed evidence, simulated evidence, demonstration evidence, rehearsal evidence, historical evidence, model output, digital twin output, public authority context, provider-supplied data, sponsor-supported material, host context, operator context, community context, protected knowledge context, public-safe summary, and any separate downstream decision.

9.28.4(d) Live dashboards, maps, indicators, alerts, status markers, continuity indicators, confidence indicators, uncertainty displays, proof receipts, simulation outputs, and public-safe summaries shall not be presented as public warnings, emergency commands, operational instructions, public authority decisions, procurement signals, finance signals, ratings, certifications, recognitions, provider rankings, sponsor validations, host approvals, operator approvals, protocol effects, deployment approvals, or execution instructions by default.

9.28.4(e) Live operation methods shall include heightened review for public-safe publication, warning-like visual grammar, public authority references, sponsor visibility, provider visibility, host visibility, operator references, community references, media reuse, screenshot reuse, API reuse, dashboard export, map export, incident disclosure, cyber-sensitive information, infrastructure-sensitive information, precise location, protected knowledge, personal data, and correction paths.

9.28.4(f) Live operation evidence shall be capable of correction during and after the live period. GCRI Canada shall maintain channels to flag defects, misreadings, public-safe concerns, access concerns, data concerns, cybersecurity concerns, AI concerns, sensor concerns, network concerns, DePIN concerns, dashboard concerns, public authority concerns, community concerns, provider concerns, sponsor concerns, host concerns, operator concerns, finance-boundary concerns, procurement-boundary concerns, and public claim concerns.

9.28.4(g) Where live operation defects occur, GCRI Canada may pause display, restrict access, downgrade confidence, revise uncertainty, mark stale status, remove public-safe outputs, restrict dashboards, restrict maps, restrict APIs, quarantine data, suspend AI outputs, isolate sensors, restrict network inputs, revoke proof receipts, issue controlled notices, issue public-safe corrections, withdraw outputs, or escalate to incident handling as appropriate.

9.28.4(h) The controlling rule shall be that one-week live operation evidence may show systems under live conditions, but live conditions shall not convert evidence into command, warning, certification, recognition, finance, procurement, protocol effect, public authority adoption, or execution by GCRI Canada.

***

9.28.5 Post-Event Teardown, After-Action, Correction, Docket Review, Grid Review, and Upgrade Methods.\
9.28.5(a) GCRI Canada may steward post-event teardown, after-action, correction, Docket review, Grid review, upgrade, renewal, archive, and closeout methods for Nexus Universe Observatory activities to preserve evidence integrity, safeguard performance, public-safe learning, interface accountability, correctionability, and institutional memory after the event period.

9.28.5(b) Teardown records shall identify systems closed, rooms closed, dashboards paused or archived, maps paused or archived, APIs deprecated or restricted, sensors removed or decommissioned, compute workloads terminated or archived, data rooms closed, clean rooms closed, access rights revoked, credentials revoked, keys rotated where appropriate, provider access removed, sponsor access removed, host access closed, operator access closed, public authority access closed, community access closed, data returned, data deleted, data sealed, data archived, and outstanding obligations.

9.28.5(c) After-action records shall identify what was planned, what was built, what operated live, what failed, what degraded, what was corrected, what was withheld, what was publicly released, what remained controlled, what remained restricted, what incidents occurred, what safeguards worked, what safeguards failed, what public authority boundaries were tested, what community safeguards were tested, what provider neutrality controls were tested, what sponsor non-control controls were tested, what host boundaries were tested, what finance and procurement boundaries were tested, what public-safe publication issues arose, and what correction actions remain.

9.28.5(d) Docket review methods shall assess whether Nexus Universe evidence, outputs, incidents, corrections, interface records, public-safe publications, and lessons learned should update relevant Docket records, maturity inputs, risk records, evidence records, correction records, public claims, public authority materials, GRF inputs, GRA inputs, Protocol Authority inputs, Nexus Risk Management inputs, Nexus Rails inputs, or National Nexus Consortium materials.

9.28.5(e) Grid review methods shall assess whether Nexus Universe evidence affects Grid-level maturity understanding, competence mapping, institutional readiness, methods maturity, safeguard maturity, evidence maturity, observability maturity, public-safe maturity, correction maturity, training needs, assurance needs, and renewal priorities, without creating public-facing maturity records by GCRI Canada.

9.28.5(f) Upgrade methods may identify method updates, software updates, dashboard updates, map updates, API updates, data governance updates, cybersecurity updates, AI governance updates, sensor updates, AI-RAN updates, DePIN updates, compute updates, public authority interface updates, community safeguard updates, provider interface updates, sponsor interface updates, host interface updates, training updates, assurance updates, and future Nexus Universe planning inputs.

9.28.5(g) Teardown, after-action, Docket review, Grid review, renewal, or upgrade records shall not assign legal liability, issue regulatory findings, approve remediation, certify systems, recognize actors, create finance-readiness, create procurement approval, create protocol effect, issue public warnings, command operations, approve deployment, or create execution consequences by default.

9.28.5(h) The controlling rule shall be that post-event review turns Nexus Universe experience into corrected institutional learning, not into retrospective certification, recognition, finance, procurement, authority, or execution.

***

9.28.6 Nexus Universe Labs, Simulations, Dashboards, Demonstrations, and Public-Safe Outputs.\
9.28.6(a) GCRI Canada may steward Observatory methods for Nexus Universe labs, simulations, dashboards, demonstrations, testbeds, scenarios, digital twins, field exercises, controlled demonstrations, technical previews, public-safe exhibits, training modules, Academy materials, public authority learning sessions, community learning sessions, provider-neutral demonstrations, sponsor-supported demonstrations, host demonstrations, operator learning sessions, and capital-reader literacy sessions.

9.28.6(b) Lab and simulation records shall identify purpose, scope, scenario, assumptions, source inputs, synthetic data status, real data status, model identity, dataset identity, compute workload, compute environment, calibration status, validation status, sensitivity treatment, boundary conditions, confidence, uncertainty, limitations, public-safe status, and correction path.

9.28.6(c) Demonstration records shall identify demonstration purpose, audience, systems shown, data shown, dashboards shown, maps shown, APIs shown, models shown, sensors shown, AI-RAN components shown, DePIN components shown, provider roles, sponsor roles, host roles, public authority roles, community roles, operator roles, simulated or live status, draft or final status, public-safe status, permitted use, prohibited use, public claims limits, and correction path.

9.28.6(d) Dashboards and visualizations used in Nexus Universe labs, simulations, or demonstrations shall distinguish simulated outputs, live outputs, historical outputs, draft outputs, controlled outputs, restricted outputs, public-safe outputs, corrected outputs, superseded outputs, and withdrawn outputs. Visual polish shall not be treated as evidence maturity or operational validity.

9.28.6(e) Public-safe outputs from Nexus Universe labs or demonstrations shall identify update status, timestamp, version, source status, confidence, uncertainty, limitations, public-safe omissions, responsible non-disclosure, no-public-warning language, no-emergency-command language, no-certification language, no-recognition language, no-finance language, no-procurement language, no-provider-endorsement language, no-sponsor-approval language, no-host-approval language, no-operator-instruction language, no-protocol-effect unless separately created, no-deployment-approval language, no-execution language, and correction path.

9.28.6(f) Simulations, demonstrations, testbeds, labs, dashboards, maps, public-safe exhibits, or technical previews shall not be used as proof of real-world readiness, public authority adoption, finance-readiness, procurement eligibility, certification, recognition, protocol effect, provider superiority, sponsor validation, host approval, operator readiness, community consent, operational clearance, deployment approval, or execution capability by default.

9.28.6(g) Where simulation or demonstration outputs are reused outside their recorded context, copied, screenshot, embedded, quoted, used in media, used in sponsor materials, used in provider materials, used in finance-facing materials, used in procurement-facing materials, used in public authority materials, used in host materials, used in community materials, or used in public claims, GCRI Canada shall require context preservation, boundary language, correction path, and misuse response where appropriate.

9.28.6(h) The controlling rule shall be that Nexus Universe labs and demonstrations may show how methods could work, but they do not prove certification, recognition, finance-readiness, procurement eligibility, public authority adoption, or execution readiness by default.

***

9.28.7 Nexus Universe Sponsor, Provider, Host, Public Authority, Community, and Capital-Reader Boundary Controls.\
9.28.7(a) GCRI Canada shall apply heightened boundary controls to Nexus Universe Observatory interfaces involving sponsors, providers, vendors, contractors, hosts, operators, public authorities, communities, Indigenous or protected knowledge holders where applicable, universities, capital readers, insurers, lenders, investors, public finance readers, National Companies, Project SPVs, GRF, GRA, Protocol Authority, Nexus Risk Management, Nexus Rails, Nexus Grid, and Nexus Academy.

9.28.7(b) Sponsor boundary controls shall preserve support-without-control, no-outcome-purchase, no-evidence-control, no-source-selection-control, no-method-control, no-reviewer-control, no-publication-control, no-public-authority-access-control, no-provider-selection-control, no-host-selection-control, no-community-control, no-recognition-control, no-finance-control, no-protocol-control, no-procurement-control, no-execution-control, public claims limits, and correction path.

9.28.7(c) Provider boundary controls shall preserve no-provider-preference, no-procurement-advantage, no-certification, no-recognition, no-finance-readiness, no-public-authority-endorsement, no-protocol-effect unless separately created by Protocol Authority, no-security-guarantee, no-operational-clearance, no-deployment-approval, no-market-entitlement, public claims limits, and correction path.

9.28.7(d) Host boundary controls shall preserve no-host-certification, no-host-approval, no-site-approval, no-community-consent-by-implication, no-public-authority-approval, no-procurement, no-finance-readiness, no-provider-endorsement, no-sponsor-approval, no-protocol-effect, no-deployment-approval, no-operational-clearance, no-execution, safe-location treatment, public claims limits, and correction path.

9.28.7(e) Public authority boundary controls shall preserve capacity classification, non-delegation, non-endorsement, no-official-guidance, no-regulatory-determination, no-compliance-determination, no-enforcement-position, no-public-warning, no-emergency-command, no-procurement, no-funding, no-public-finance, no-certification, no-recognition, no-finance-readiness, no-provider-endorsement, no-sponsor-approval, no-host-approval, no-operator-instruction, no-protocol-effect unless separately created, public reference controls, and correction path.

9.28.7(f) Community and protected knowledge boundary controls shall preserve non-extraction, non-commodification, no-community-consent-by-implication, no-Indigenous-consent-by-implication where applicable, source protection, sensitive-site protection, protected knowledge restrictions, public-safe mapping limits, withdrawal or challenge pathways where applicable, grievance or remedy pathways where applicable, accessibility, translation, localization, do-no-harm controls, and correction path.

9.28.7(g) Capital-reader boundary controls shall preserve no-investment-advice, no-rating, no-guarantee, no-finance-readiness-by-GCRI, no-insurance-readiness-by-GCRI, no-bankability, no-fundability, no-public-finance-approval, no-procurement, no-capital-allocation, no-project-approval, no-provider-preference, no-host-approval, no-execution, confidence, uncertainty, limitations, permitted use, prohibited use, and correction path.

9.28.7(h) The presence of sponsors, providers, hosts, public authorities, communities, capital readers, media, National Companies, Project SPVs, GRF, GRA, Protocol Authority, Nexus entities, or universities in a Nexus Universe event shall not create endorsement, approval, consent, certification, recognition, finance-readiness, public authority adoption, procurement effect, protocol effect, provider preference, sponsor validation, host approval, operator instruction, market signal, deployment approval, operational clearance, public warning, emergency command, or execution consequence by implication.

9.28.7(i) Where boundary defects or overclaims arise during or after Nexus Universe activities, GCRI Canada shall correct, relabel, restrict, withdraw, reissue, request removal of misleading references, issue public-safe or controlled clarification, suspend affected interface use, terminate support where appropriate, or pursue contractual or legal remedies where appropriate.

9.28.7(j) The controlling rule shall be that Nexus Universe is a high-visibility evidence environment, and therefore every actor interface must be bounded before visibility becomes status.

***

9.28.8 Nexus Universe Observatory Evidence Packs.\
9.28.8(a) GCRI Canada may prepare Nexus Universe Observatory Evidence Packs to organize planning evidence, controlled build evidence, live operation evidence, teardown evidence, after-action evidence, correction evidence, Docket review evidence, Grid review evidence, renewal evidence, sponsor-support evidence, provider-contribution evidence, host-readiness evidence, public-authority-learning evidence, community-safeguard evidence, capital-reader learning evidence, lab evidence, simulation evidence, dashboard evidence, map evidence, API evidence, and public-safe publication evidence.

9.28.8(b) Nexus Universe Observatory Evidence Packs shall identify event or program title, purpose, scope, period, location or safe-location treatment, host context, sponsor context, provider context, operator context, public authority context, community context, Indigenous or protected knowledge context where applicable, capital-reader context where any, GRF interface, GRA interface, Protocol Authority interface, Nexus Risk Management interface, Nexus Rails interface, Nexus Grid interface, National Nexus Consortium interface, National Company interface, Project SPV interface, data classes, evidence classes, output classes, access classes, handling classes, public-safe status, confidence, uncertainty, limitations, boundary language, correction path, supersession path, withdrawal path, retraction path where applicable, and archive path.

9.28.8(c) Evidence Pack components may include one-year planning records, one-month controlled build records, one-week live operation records, teardown records, after-action records, Docket review records, Grid review records, upgrade records, renewal records, lab records, simulation records, demonstration records, dashboard records, map records, API records, sensor records, AI-RAN records, DePIN records, cyber telemetry records, digital twin records, compute records, model records, dataset records, proof receipt records, public-safe output records, incident records, correction records, assurance records, and closeout records.

9.28.8(d) Nexus Universe Observatory Evidence Packs shall include boundary notes for sponsor support, provider participation, host participation, public authority participation, community participation, protected knowledge, capital-reader participation, public-safe publication, finance-safe treatment, procurement-safe treatment, certification-safe treatment, recognition-safe treatment, protocol-boundary treatment, and non-execution.

9.28.8(e) Nexus Universe Observatory Evidence Packs may be structured into public-safe summaries, controlled annexes, restricted annexes, public authority annexes, community-sensitive annexes, protected knowledge annexes, cyber-sensitive annexes, infrastructure-sensitive annexes, finance-boundary annexes, procurement-boundary annexes, provider-sensitive annexes, sponsor-sensitive annexes, host-sensitive annexes, operator-sensitive annexes, correction annexes, and archive records.

9.28.8(f) A Nexus Universe Observatory Evidence Pack shall not describe a Nexus Universe event, lab, demonstration, simulation, host, provider, sponsor, system, public authority interface, community interface, National Company, Project SPV, GRF input, GRA input, or Protocol Authority input as certified, recognized, finance-ready, procurement-ready, public authority-adopted, protocol-effective, deployment-approved, operationally cleared, market-ready, or execution-ready by default.

9.28.8(g) Where a Nexus Universe Observatory Evidence Pack is corrected, restricted, superseded, withdrawn, retracted, or made stale by later evidence, GCRI Canada shall update affected dashboards, maps, APIs, public-safe summaries, controlled annexes, restricted annexes, Docket records, Grid records, GRF inputs, GRA inputs, Protocol Authority inputs, Nexus Risk Management materials, Nexus Rails materials, National Nexus Consortium materials, National Company materials, Project SPV materials, provider materials, sponsor materials, host materials, operator materials, public authority materials, community materials, Academy materials, media materials, repositories, and public claims as appropriate.

9.28.8(h) The controlling rule shall be that Nexus Universe Observatory Evidence Packs preserve event evidence as bounded institutional memory, not as event-based certification, recognition, finance-readiness, procurement approval, public authority adoption, protocol effect, or execution authorization.

***

9.28.9 No Event-Based Certification, Recognition, Finance-Readiness, Public Authority Adoption, or Procurement Effect by GCRI Canada.\
9.28.9(a) No Nexus Universe planning process, controlled build, live operation, teardown, after-action review, Docket review, Grid review, upgrade, renewal, lab, simulation, demonstration, dashboard, map, API, Evidence Pack, Decision Pack, public-safe output, technical note, Academy material, public authority learning material, community material, provider material, sponsor material, host material, operator material, capital-reader material, Proof Receipt, media material, repository material, or public claim shall create certification, recognition, finance-readiness, public authority adoption, procurement effect, protocol effect, deployment approval, operational clearance, public warning, emergency command, market authority, legal status, or execution consequence by GCRI Canada by default.

9.28.9(b) Event participation, event attendance, event sponsorship, event hosting, provider demonstration, public authority attendance, regulator-listening presence, public finance reader presence, capital-reader presence, community participation, Indigenous participation where applicable, media presence, dashboard visibility, map visibility, live system display, simulation result, lab result, benchmark result, proof receipt, after-action note, Docket reference, Grid reference, GRF interface use, GRA interface use, Protocol Authority interface use, National Company relevance, or Project SPV relevance shall not create prohibited status by implication.

9.28.9(c) GCRI Canada shall not use Nexus Universe activities to certify providers, recognize actors, issue maturity records, issue claims approval, create finance-readiness, recommend investments, approve insurance, rate projects, approve procurement, endorse sponsors, approve hosts, approve operators, adopt public authority roles, issue public warnings, command emergency response, confer protocol effect, authorize deployment, operate infrastructure, or execute projects.

9.28.9(d) Any certification, recognition, GRF maturity record, GRF claims approval, GRA finance-readiness determination, finance decision, insurance decision, lending decision, public finance decision, procurement decision, public authority adoption, public warning, emergency command, protocol effect, provider decision, sponsor decision, host decision, operator decision, National Company action, Project SPV action, deployment decision, operational decision, or execution action shall arise only through the competent actor’s own authority, process, records, accountability, liability, and governance instruments, not through GCRI Canada Nexus Universe Observatory evidence by implication.

9.28.9(e) Nexus Universe public-facing materials shall include boundary language where material to prevent interpretation as event-based certification, recognition, finance-readiness, public authority adoption, procurement approval, protocol effect, provider endorsement, sponsor validation, host approval, operator instruction, deployment approval, operational clearance, public warning, emergency command, market signal, or execution authorization.

9.28.9(f) Where Nexus Universe materials are misused to imply event-based certification, recognition, finance-readiness, public authority adoption, procurement effect, protocol effect, provider preference, sponsor approval, host approval, operator approval, deployment approval, market signal, public warning, emergency command, or execution consequence, GCRI Canada shall correct, relabel, restrict, withdraw, reissue, request removal of misleading references, notify affected interfaces where appropriate, suspend affected use, or pursue contractual or legal remedies where appropriate.

9.28.9(g) No ambiguity shall be resolved in favour of event-based authority. Where there is doubt, the interpretation preserving GCRI Canada’s non-execution role, public authority boundaries, public warning boundaries, finance boundaries, procurement neutrality, provider neutrality, sponsor non-control, host boundaries, operator boundaries, community safeguards, protected knowledge safeguards, Protocol Authority role separation, GRF role separation, GRA role separation, validity-by-record, correctionability, and public trust shall prevail.

9.28.9(h) The controlling rule shall be that Nexus Universe can convene evidence, demonstrate methods, and teach systems, but GCRI Canada shall not use an event to certify, recognize, finance, procure, adopt, warn, command, authorize, or execute.

***

9.28.10 Nexus Universe Observatory Records, Corrections, and Renewal Inputs.\
9.28.10(a) GCRI Canada shall maintain, or cause to be maintained, Nexus Universe Observatory records for material planning evidence, controlled build evidence, live operation evidence, teardown evidence, after-action evidence, Docket review evidence, Grid review evidence, upgrade evidence, renewal evidence, lab evidence, simulation evidence, demonstration evidence, dashboard evidence, map evidence, API evidence, Evidence Packs, Decision Packs, public-safe outputs, controlled annexes, restricted annexes, public authority interfaces, community interfaces, provider interfaces, sponsor interfaces, host interfaces, operator interfaces, capital-reader interfaces, incidents, corrections, dependency notices, assurance reviews, archive, and closeout events.

9.28.10(b) Nexus Universe Observatory records shall identify record title or identifier, event or program title, purpose, scope, period, location or safe-location treatment, relevant Nodes, Hubs, Clusters, Hotspots, Regional Observatory Clusters, National Dense Nexus Core relationships, host context, provider context, sponsor context, operator context, public authority context, community context, Indigenous or protected knowledge context where applicable, capital-reader context where any, GRF interface, GRA interface, Protocol Authority interface, Nexus Risk Management interface, Nexus Rails interface, Nexus Grid interface, National Nexus Consortium interface, Regional Nexus Consortium interface, National Company interface, Project SPV interface, technology domain, risk domain, data class, evidence class, output class, audience class, access class, handling class, public-safe status, privacy status, cybersecurity status, sovereign data status, infrastructure-sensitive status, public authority status, finance-sensitive status, procurement-sensitive status, commercially sensitive status, provider-sensitive status, sponsor-sensitive status, host-sensitive status, operator-sensitive status, community-protected status, Indigenous or protected knowledge status, legal sensitivity, export-control sensitivity, sanctions sensitivity, controlled-technology sensitivity, permitted uses, prohibited uses, publication limits, and correction path.

9.28.10(c) Correction records shall identify corrected planning record, corrected build record, corrected live operation record, corrected teardown record, corrected after-action record, corrected Docket review record, corrected Grid review record, corrected lab record, corrected simulation record, corrected demonstration record, corrected dashboard, corrected map, corrected API, corrected Evidence Pack, corrected Decision Pack, corrected public-safe output, corrected public authority reference, corrected provider reference, corrected sponsor reference, corrected host reference, corrected operator reference, corrected community reference, corrected capital-reader reference, corrected GRF interface, corrected GRA interface, corrected Protocol Authority interface, corrected boundary language, prior status, corrected status, effective date, reviewer, affected dependencies, notice decision, access change, archive treatment, and continuing limitations.

9.28.10(d) Renewal inputs shall identify methods strengthened, methods weakened, evidence gaps, safeguard gaps, public-safe publication lessons, public authority boundary lessons, community safeguard lessons, protected knowledge lessons, provider-neutrality lessons, sponsor non-control lessons, host-boundary lessons, operator-boundary lessons, finance-boundary lessons, procurement-boundary lessons, cybersecurity lessons, AI governance lessons, data governance lessons, sensor lessons, AI-RAN lessons, DePIN lessons, dashboard lessons, map lessons, API lessons, Evidence Pack lessons, Docket updates, Grid updates, Academy updates, assurance updates, training updates, interface agreement updates, and next-cycle planning requirements.

9.28.10(e) Supersession, withdrawal, or retraction records shall be used where Nexus Universe Observatory materials should no longer be used or relied upon because of material error, unsafe disclosure, false maturity, narrative acceleration, event overclaim, public-safe defect, public authority confusion, public warning implication, finance overclaim, procurement implication, certification implication, recognition implication, protocol implication, provider-preferential framing, sponsor-validation framing, host approval implication, operator-control implication, community consent implication, protected knowledge exposure, community harm risk, privacy defect, cybersecurity defect, sovereign data issue, cross-border defect, infrastructure-risk exposure, legal defect, export-control issue, sanctions issue, controlled-technology issue, or correction failure.

9.28.10(f) Nexus Universe Observatory records shall be linked, where applicable, to National Dense Core records, Regional Observatory Cluster records, Cluster records, Hub records, Node records, Hotspot records, host readiness records, maturity evidence records, Observatory Evidence Pack Register entries, Observatory data records, cybersecurity records, AI-RAN records, DePIN records, sensor records, geospatial records, cyber telemetry records, digital twin records, dashboard records, degraded-mode records, sovereign compute records, public authority interface records, community interface records, provider and sponsor interface records, Observatory incident records, Observatory publication records, Observatory Methods Register entries, Evidence Register entries, Source Comparison Records, Dataset Register entries, Model Register entries, System Card entries, Benchmark Card entries, Compute Workload Records, Compute Environment Records, Inference Records, Human Review Records, Retrieval and Embedding Records, Proof Receipt Records, Public-Safe Output Records, AI Incident Records, Correction Records, Dependency Records, Truth Engine Records, Nexus Risk Management records, GRF interface records, GRA interface records, Protocol Authority interface records, RNFD records, Nexus Rails records, Nexus Grid records, Nexus Academy records, Regional Nexus Consortium records, National Nexus Consortium records, National Company records, Project SPV records, operator records, provider records, sponsor records, host records, community records, university records, Nexus interface records, media materials, and public claims records.

9.28.10(g) Nexus Universe Observatory records, correction records, renewal inputs, assurance records, supersession records, withdrawal records, retraction records, archive records, notices, and closeout shall not create certification, recognition, finance-readiness, public authority decision, regulatory finding, procurement approval, funding approval, public finance approval, provider endorsement, sponsor approval, host approval, operator approval, community consent, Indigenous consent, rating, guarantee, public warning, emergency command, protocol effect, operational clearance, legal status, market authority, infrastructure operation, remediation approval, deployment approval, national authority, regional authority, GRF maturity record, GRA finance-readiness, event-based maturity, event-based approval, or execution consequence by default.

9.28.10(h) The controlling rule shall be that Nexus Universe Observatory records must preserve what was planned, built, shown, learned, corrected, withdrawn, renewed, and bounded with enough precision to prevent an event from becoming unsupported authority, status, finance, procurement, certification, recognition, protocol effect, or execution.

### 9.29 Observatory Interface With Nexus Grid, Docket, Rails, Risk Management, and Academy

9.29.1 Observatory Evidence Inputs to Nexus Grid.\
9.29.1(a) GCRI Canada may steward Observatory evidence input methods for Nexus Grid as structured, source-lined, confidence-aware, uncertainty-aware, limitation-aware, public-safe, non-executing, and correctionable methods through which Observatory evidence may inform Grid-level understanding of competence, methods maturity, evidence maturity, observability maturity, institutional readiness, safeguard maturity, technical baseline maturity, public-safe publication maturity, correction maturity, training needs, assurance needs, and renewal priorities.

9.29.1(b) Observatory evidence inputs to Nexus Grid may include Node evidence, Hub evidence, Cluster evidence, Hotspot evidence, Regional Observatory Cluster evidence, National Dense Nexus Core evidence, host readiness evidence, maturity evidence inputs, degraded-mode evidence, sensor evidence, AI-RAN evidence, O-RAN evidence, private wireless evidence, DePIN evidence, cyber telemetry evidence, geospatial evidence, Earth observation evidence, digital twin evidence, dashboard evidence, public-safe publication evidence, incident evidence, community safeguard evidence, public authority interface evidence, provider and sponsor boundary evidence, data governance evidence, cybersecurity evidence, AI governance evidence, Evidence Packs, Decision Packs, assurance findings, correction records, supersession records, withdrawal records, retraction records, and renewal inputs.

9.29.1(c) Grid-facing Observatory evidence inputs shall identify the receiving Grid interface, purpose, evidence class, data class, output class, access class, handling class, public-safe status, source records, method records, compute records where applicable, model records where applicable, confidence, uncertainty, limitations, maturity-input status, safeguard status, correction status, permitted use, prohibited use, boundary language, dependency links, and correction path.

9.29.1(d) GCRI Canada shall preserve the distinction between Observatory evidence inputs and any Grid-level maturity, competence, recognition, standing, routing, or public-facing classification maintained by another competent Nexus function. GCRI Canada may provide evidence to the Grid, but it shall not, by that evidence, issue public-facing maturity records, competence recognition, professional certification, procurement approval, finance-readiness, public authority meaning, protocol effect, or execution consequence.

9.29.1(e) Observatory evidence supplied to Nexus Grid shall not be accelerated, rounded up, or converted into Grid maturity language beyond the evidence record. Stage truth, confidence, uncertainty, limitations, evidence gaps, contradiction, public-safe status, safeguard status, and correction status shall remain attached to Grid-facing inputs.

9.29.1(f) Where Grid-facing Observatory evidence is incomplete, stale, contradicted, unsupported, overclaimed, public-safe defective, provider-influenced, sponsor-influenced, host-influenced, public authority-confusing, community-safeguard-defective, finance-facing, procurement-facing, certification-implying, recognition-implying, protocol-implying, or correction-defective, GCRI Canada shall qualify, downgrade, restrict, correct, supersede, withdraw, or refuse the input as appropriate.

9.29.1(g) Grid-facing Observatory inputs shall include no-GCRI-maturity-record language, no-professional-certification language, no-procurement language, no-finance-readiness language, no-public-authority language, no-public-warning language, no-certification language, no-recognition language, no-protocol-effect language unless separately created by Protocol Authority, no-provider-endorsement language, no-sponsor-approval language, no-host-approval language, no-operator-instruction language, no-deployment-approval language, and no-execution language where material.

9.29.1(h) The controlling rule shall be that Observatory evidence may inform Nexus Grid learning and maturity understanding, but it shall not become a public-facing Grid maturity record, professional certification, authority, finance, procurement, protocol effect, or execution by GCRI Canada.

***

9.29.2 Observatory Evidence Inputs to Nexus Docket.\
9.29.2(a) GCRI Canada may steward Observatory evidence input methods for Nexus Docket as structured evidence-routing, issue-recording, correction, dependency, review, and learning methods through which Observatory outputs, incidents, corrections, evidence gaps, public-safe issues, interface issues, method issues, safeguard issues, and renewal needs may be docketed for traceable institutional attention.

9.29.2(b) Observatory evidence inputs to Nexus Docket may include Evidence Packs, Decision Packs, public-safe summaries, dashboards, maps, APIs, data governance records, cybersecurity records, AI records, sensor records, AI-RAN records, DePIN records, geospatial records, digital twin records, degraded-mode records, host readiness records, maturity evidence records, public authority interface records, community safeguard records, provider and sponsor interface records, incident records, correction records, assurance records, dependency records, public claim records, and Nexus Universe after-action records.

9.29.2(c) Docket-facing Observatory evidence input records shall identify docket matter title or identifier, issue type, source evidence, affected systems, affected outputs, affected interfaces, affected actors where safe and material, data class, evidence class, output class, access class, handling class, public-safe status, confidence, uncertainty, limitations, urgency where used, correction status, dependency status, permitted use, prohibited use, boundary language, reviewer, and correction path.

9.29.2(d) Docket inputs may support issue triage, evidence review, correction routing, dependency review, safeguard review, public-safe review, interface review, assurance planning, training update, methods update, technical-control update, and renewal planning. Docket input shall not constitute approval, certification, recognition, finance-readiness, procurement approval, public authority decision, public warning, emergency command, protocol effect, provider endorsement, sponsor approval, host approval, operator instruction, deployment approval, operational clearance, market authority, legal status, or execution consequence by GCRI Canada.

9.29.2(e) A Docket entry or Docket routing arising from Observatory evidence shall not be treated as a finding, approval, regulatory conclusion, legal conclusion, public authority position, finance conclusion, procurement conclusion, certification decision, recognition decision, Protocol Authority determination, or execution instruction unless a competent separate actor creates such effect under its own authority and record.

9.29.2(f) Where Docket-facing Observatory evidence is corrected, restricted, superseded, withdrawn, retracted, materially reclassified, or made stale by later evidence, GCRI Canada shall update Docket-facing records, issue correction signals, identify affected dependencies, and notify affected interfaces where appropriate.

9.29.2(g) Docket-facing Observatory inputs shall preserve source lineage, version, status, confidence, uncertainty, limitations, public-safe treatment, boundary language, and correction path sufficient to prevent docketing from becoming approval by administrative appearance.

9.29.2(h) The controlling rule shall be that Nexus Docket may record what needs attention, review, correction, or routing, but Observatory Docket inputs do not approve, certify, recognize, finance, procure, warn, command, authorize, or execute.

***

9.29.3 Observatory Evidence Inputs to Nexus Rails.\
9.29.3(a) GCRI Canada may steward Observatory evidence input methods for Nexus Rails as evidence-supporting, finance-safe, procurement-safe, non-advisory, non-rating, non-guaranteeing, non-executing, public-safe, source-lined, confidence-aware, uncertainty-aware, limitation-aware, and correctionable methods through which Observatory evidence may support structured capital-reader literacy, project-readiness literacy, resilience evidence literacy, public-safe routing, GRA inputs, RNFD inputs, NFD inputs, UNFSD inputs, and related non-executing learning interfaces.

9.29.3(b) Observatory evidence inputs to Nexus Rails may include host readiness evidence, Node evidence, Cluster evidence, Regional Observatory Cluster evidence, National Dense Core evidence, degraded-mode evidence, infrastructure evidence, sovereign compute evidence, data governance evidence, cybersecurity evidence, AI governance evidence, public-safe publication evidence, public authority interface evidence, community safeguard evidence, provider-neutrality evidence, sponsor non-control evidence, Evidence Packs, Decision Packs, dashboards, maps, APIs, public-safe summaries, correction records, assurance findings, and renewal inputs.

9.29.3(c) Rails-facing Observatory evidence input records shall identify receiving Rails or finance-facing interface, purpose, evidence class, data class, output class, access class, handling class, public-safe status, finance-safe status, procurement-safe status, source records, method records, compute records where applicable, model records where applicable, confidence, uncertainty, limitations, permitted use, prohibited use, no-advice boundary, no-rating boundary, no-guarantee boundary, no-finance-readiness-by-GCRI boundary, no-public-finance-approval boundary, no-procurement boundary, correction path, supersession path, withdrawal path, retraction path where applicable, and dependency links.

9.29.3(d) GCRI Canada shall not use Rails-facing Observatory inputs to issue finance-readiness, capital-readiness, insurance-readiness, investment advice, securities recommendations, brokerage, placement, finder activity, lending decisions, underwriting decisions, insurance approvals, ratings, guarantees, public finance approvals, bankability determinations, fundability determinations, capital commitments, credit quality determinations, insurance quality determinations, investment quality determinations, procurement approvals, project approvals, or execution consequences.

9.29.3(e) Confidence scores, readiness evidence, maturity evidence, dashboard indicators, map markers, resilience indicators, degraded-mode indicators, proof receipts, benchmark outputs, Evidence Packs, Decision Packs, or public-safe summaries shall not be framed by GCRI Canada as ratings, finance-readiness determinations, insurance-readiness determinations, bankability determinations, fundability determinations, public finance approvals, investment recommendations, procurement recommendations, provider preferences, host approvals, project approvals, or execution instructions.

9.29.3(f) Any GRA determination, Nexus Rails routing consequence, RNFD consequence, NFD consequence, UNFSD consequence, public finance consequence, capital-reader interpretation, lender action, insurer action, investor action, procurement consequence, National Company action, Project SPV action, or execution action shall arise only through the competent actor’s own authority, process, records, accountability, liability, and governance instruments, not through GCRI Canada Observatory evidence by implication.

9.29.3(g) Where Rails-facing Observatory evidence is corrected, downgraded, restricted, superseded, withdrawn, retracted, or materially reclassified, GCRI Canada shall issue correction signals or dependency notices to affected Rails, GRA, RNFD, NFD, UNFSD, capital-reader, National Company, Project SPV, public authority, provider, sponsor, host, operator, or public-safe interfaces where appropriate.

9.29.3(h) The controlling rule shall be that Observatory evidence may support Nexus Rails literacy and routing discipline, but it shall not create finance, rating, guarantee, insurance, lending, investment, procurement, public finance, project approval, or execution authority by GCRI Canada.

***

9.29.4 Observatory Evidence Inputs to Nexus Risk Management.\
9.29.4(a) GCRI Canada may steward Observatory evidence input methods for Nexus Risk Management as structured, source-lined, confidence-aware, uncertainty-aware, limitation-aware, public-safe, non-executing, and correctionable methods through which Observatory evidence may inform systemic-risk learning, resilience learning, hazard learning, degraded-mode learning, infrastructure-risk learning, cyber-risk learning, AI-risk learning, climate, nature, water, energy, food, health, supply-chain, public-trust, and exponential-technology risk learning.

9.29.4(b) Observatory evidence inputs to Nexus Risk Management may include sensor evidence, AI-RAN evidence, DePIN evidence, cyber telemetry evidence, geospatial evidence, Earth observation evidence, digital twin outputs, simulations, dashboard outputs, degraded-mode records, incident records, host readiness evidence, maturity evidence inputs, public authority interface records, community safeguard records, protected knowledge controls, provider and sponsor boundary evidence, public-safe publication records, Evidence Packs, Decision Packs, correction records, assurance findings, and Nexus Universe after-action records.

9.29.4(c) Risk-management-facing Observatory evidence input records shall identify risk domain, system context, source records, data records, method records, compute records where applicable, model records where applicable, evidence class, data class, output class, access class, handling class, public-safe status, confidence, uncertainty, limitations, assumptions, scenario status where applicable, stale-data status, contradiction status, degraded-mode status, incident status, correction status, permitted use, prohibited use, public authority boundary, public warning boundary, finance boundary, procurement boundary, provider-neutrality boundary, sponsor non-control boundary, host boundary, operator boundary, community safeguard boundary, and correction path.

9.29.4(d) Observatory inputs may support risk identification, risk pattern recognition, scenario comparison, resilience learning, after-action learning, safeguard review, methods update, public-safe communication planning, training, and assurance. They shall not create official risk ratings, public warnings, emergency commands, public authority decisions, regulatory determinations, procurement decisions, finance-readiness, investment advice, insurance approval, certification, recognition, protocol effect, provider preference, sponsor approval, host approval, operator instruction, deployment approval, operational clearance, or execution consequence by default.

9.29.4(e) Risk labels, heatmaps, dashboards, maps, indicators, scenario outputs, confidence scores, continuity indicators, degraded-mode indicators, incident summaries, public-safe risk summaries, or public-safe technical notes shall not be designed or used as public warning instruments, emergency-command instruments, official hazard designations, regulatory positions, finance signals, procurement signals, ratings, guarantees, certifications, recognitions, or execution instructions by GCRI Canada.

9.29.4(f) Where Risk Management-facing Observatory evidence involves high-consequence risk, public authority sensitivity, vulnerable communities, protected knowledge, infrastructure vulnerability, cyber vulnerability, finance-sensitive context, procurement-sensitive context, provider-sensitive context, sponsor-sensitive context, or media-sensitive context, GCRI Canada shall apply heightened public-safe, controlled-annex, restricted-annex, access, reference, correction, and misuse-monitoring controls.

9.29.4(g) Where Risk Management-facing Observatory evidence is corrected, restricted, superseded, withdrawn, retracted, materially reclassified, or made stale by later evidence, GCRI Canada shall update affected risk-management records, dashboards, maps, public-safe summaries, Evidence Packs, Decision Packs, public authority learning materials, community-facing materials, GRF inputs, GRA inputs, Protocol Authority inputs, Rails materials, Academy materials, and public claims where appropriate.

9.29.4(h) The controlling rule shall be that Observatory evidence may inform Nexus Risk Management learning, but it shall not become official risk authority, public warning, emergency command, finance, procurement, certification, recognition, protocol effect, or execution by GCRI Canada.

***

9.29.5 Observatory Evidence Inputs to Nexus Academy.\
9.29.5(a) GCRI Canada may steward Observatory evidence input methods for Nexus Academy as public-good learning, training, literacy, methods, simulation, public-safe explanation, correction, and capacity-building inputs concerning Observatory systems, evidence methods, data governance, cybersecurity, AI governance, public-safe publication, public authority boundaries, community safeguards, provider neutrality, sponsor non-control, host readiness, degraded-mode awareness, Evidence Packs, incident handling, Nexus Universe learning, Grid learning, Docket learning, Rails literacy, and Risk Management learning.

9.29.5(b) Academy-facing Observatory inputs may include public-safe summaries, controlled training annexes, technical notes, anonymized or generalized case studies, simulated datasets, synthetic data, safe dashboards, safe maps, safe APIs, lab materials, demonstration records, incident lessons, correction lessons, assurance lessons, public authority learning examples, community safeguard examples, provider-neutrality examples, sponsor non-control examples, data governance examples, cybersecurity examples, AI governance examples, and Nexus Universe after-action lessons.

9.29.5(c) Academy-facing Observatory evidence input records shall identify training purpose, audience, learner class, source records, data records, method records, simulation status, synthetic data status, public-safe status, access class, handling class, confidence, uncertainty, limitations, public-safe omissions, boundary language, permitted use, prohibited use, correction path, supersession path, withdrawal path, archive path, and dependency links.

9.29.5(d) Academy materials using Observatory evidence shall distinguish training examples from live evidence, simulated evidence from real evidence, anonymized evidence from source evidence, public-safe summaries from controlled annexes, generalized maps from precise maps, synthetic datasets from operational datasets, demonstrations from certified systems, and learning scenarios from authority-bearing decisions.

9.29.5(e) Observatory evidence inputs to Nexus Academy shall not create professional certification, license, accreditation, regulated qualification, practice authorization, procurement qualification, finance qualification, provider qualification, host qualification, public authority qualification, emergency-management qualification, cybersecurity certification, AI certification, operator approval, deployment approval, operational clearance, or execution authority by default.

9.29.5(f) Academy-facing materials shall include, where material, no-professional-certification language, no-public-authority language, no-public-warning language, no-emergency-command language, no-finance language, no-procurement language, no-certification language, no-recognition language, no-protocol-effect language unless separately created, no-provider-endorsement language, no-sponsor-approval language, no-host-approval language, no-operator-instruction language, no-deployment-approval language, no-execution language, confidence, uncertainty, limitations, permitted-use limits, and correction path.

9.29.5(g) Where Academy-facing Observatory materials are corrected, restricted, superseded, withdrawn, retracted, mistranslated, made inaccessible, misused, used as professional certification, used as procurement qualification, used as finance qualification, used as provider endorsement, used as public authority approval, or reused outside permitted context, GCRI Canada shall correct, relabel, restrict, withdraw, reissue, notify affected learners or interfaces where appropriate, and review dependencies.

9.29.5(h) The controlling rule shall be that Nexus Academy may teach Observatory methods and evidence discipline, but Academy learning shall not become professional certification, regulated qualification, authority, finance, procurement, protocol effect, or execution by default.

***

9.29.6 Grid Inputs Without Maturity Record by GCRI Canada.\
9.29.6(a) No Observatory evidence input, Grid-facing evidence record, competence evidence, methods evidence, safeguard evidence, public-safe evidence, incident evidence, correction evidence, assurance evidence, Nexus Universe evidence, dashboard, map, Evidence Pack, Decision Pack, public-safe summary, technical note, training material, or interface log supplied by GCRI Canada to Nexus Grid shall create a public-facing maturity record by GCRI Canada.

9.29.6(b) GCRI Canada shall not use Grid-facing Observatory inputs to issue public maturity levels, public maturity badges, competence recognition, professional standing, institutional standing, claims approval, public-facing legitimacy, registry status, certification, accreditation, Nexus-compatible status, procurement qualification, finance-readiness, public authority meaning, protocol effect, provider preference, sponsor approval, host approval, operator approval, deployment approval, operational clearance, or execution authority.

9.29.6(c) Grid maturity, competence, standing, training, recognition, or other Grid-related public-facing effect, if any, shall arise only through the competent Grid, GRF, Academy, Protocol Authority, public authority, professional body, or other separate actor’s own authority, process, records, accountability, liability, and governance instruments, not through GCRI Canada Observatory evidence by implication.

9.29.6(d) GCRI Canada shall preserve stage truth in all Grid-facing Observatory inputs. Draft, pilot, internal, controlled, simulated, provisional, public-safe, corrected, superseded, restricted, withdrawn, retracted, or archived status shall not be translated into higher maturity, competence, recognition, approval, or certification language.

9.29.6(e) Grid-facing Observatory inputs shall include source records, confidence, uncertainty, limitations, correction status, public-safe status, dependency status, permitted use, prohibited use, no-GCRI-maturity-record language, and no-professional-certification language where material.

9.29.6(f) Where Grid-facing Observatory materials are misused to imply that GCRI Canada issued maturity, competence, certification, recognition, standing, public-facing legitimacy, procurement qualification, finance-readiness, public authority meaning, protocol effect, or execution authority, GCRI Canada shall correct, relabel, restrict, withdraw, reissue, request removal of misleading references, notify affected Grid or Nexus interfaces where appropriate, suspend affected interface use, or pursue contractual or legal remedies where appropriate.

9.29.6(g) No ambiguity shall be resolved in favour of maturity by implication. Where there is doubt, the interpretation preserving GCRI Canada’s non-execution role, evidence-input role, stage truth, Grid role separation, GRF role separation, Academy role separation, Protocol Authority role separation, public authority boundaries, finance boundaries, procurement neutrality, provider neutrality, sponsor non-control, host boundaries, community safeguards, validity-by-record, correctionability, and public trust shall prevail.

9.29.6(h) The controlling rule shall be that GCRI Canada may inform the Grid, but shall not itself issue Grid maturity, competence, certification, recognition, or public-facing standing.

***

9.29.7 Docket Inputs Without Approval by GCRI Canada.\
9.29.7(a) No Observatory evidence input, Docket entry, Docket routing, issue record, correction record, dependency record, incident record, safeguard record, public-safe record, interface record, dashboard reference, map reference, Evidence Pack reference, Decision Pack reference, public authority reference, community reference, provider reference, sponsor reference, host reference, operator reference, GRF reference, GRA reference, Protocol Authority reference, National Company reference, Project SPV reference, or public claim record supplied by GCRI Canada to Nexus Docket shall create approval by GCRI Canada.

9.29.7(b) GCRI Canada shall not use Docket-facing Observatory inputs to approve projects, approve providers, approve hosts, approve operators, approve sponsors, approve public authority decisions, approve public-safe publication beyond recorded public-safe review, approve procurement, approve finance-readiness, approve insurance-readiness, approve investment readiness, approve deployment, approve remediation, approve operational clearance, certify systems, recognize actors, confer protocol effect, issue public warnings, command emergency response, create market status, or execute projects.

9.29.7(c) Docket status shall not be overread. A matter being docketed, escalated, reviewed, corrected, tracked, assigned, closed, renewed, archived, or linked shall not imply that the underlying actor, system, host, provider, sponsor, project, public authority interface, community interface, publication, or output has been approved, certified, recognized, financed, procured, authorized, adopted, or executed.

9.29.7(d) Docket-facing Observatory inputs shall preserve draft, provisional, review, dispute, incident, correction, supersession, withdrawal, retraction, archive, and closeout status where applicable and shall prevent docket records from appearing as approvals or official findings by administrative form.

9.29.7(e) Where Docket-facing Observatory evidence is used by a separate competent actor to support an approval or decision, such approval or decision shall arise only through that actor’s own authority, process, records, accountability, liability, and governance instruments, not through GCRI Canada’s Docket input by implication.

9.29.7(f) Where Docket-facing materials are misused to imply GCRI Canada approval, public authority approval, procurement approval, finance-readiness, certification, recognition, protocol effect, provider preference, sponsor approval, host approval, operator approval, deployment approval, operational clearance, or execution, GCRI Canada shall correct, relabel, restrict, withdraw, reissue, request removal of misleading references, notify affected Docket or Nexus interfaces where appropriate, and review dependencies.

9.29.7(g) No ambiguity shall be resolved in favour of approval by docketing. Where there is doubt, the interpretation preserving evidence routing, non-execution, correctionability, public authority boundaries, finance boundaries, procurement neutrality, provider neutrality, sponsor non-control, host boundaries, operator boundaries, community safeguards, Protocol Authority role separation, GRF role separation, GRA role separation, and public trust shall prevail.

9.29.7(h) The controlling rule shall be that Docket inputs record matters for attention, not approvals for action.

***

9.29.8 Rails Inputs Without Finance or Execution Authority by GCRI Canada.\
9.29.8(a) No Observatory evidence input, Rails-facing evidence record, GRA-facing input, RNFD input, NFD input, UNFSD input, capital-reader material, insurance-readiness input, host readiness evidence, Node evidence, Cluster evidence, National Dense Core evidence, resilience evidence, dashboard, map, Evidence Pack, Decision Pack, public-safe summary, controlled annex, proof receipt, assurance note, correction signal, or public claim supplied by GCRI Canada to Nexus Rails or finance-facing interfaces shall create finance or execution authority by GCRI Canada.

9.29.8(b) GCRI Canada shall not issue finance-readiness, investment advice, insurance approval, lending decision, underwriting decision, public finance approval, rating, guarantee, bankability, fundability, capital allocation, securities recommendation, brokerage, placement, finder activity, procurement approval, project approval, provider selection, host selection, National Company instruction, Project SPV instruction, deployment approval, operational clearance, market authority, or execution instruction through Rails-facing Observatory inputs.

9.29.8(c) Rails-facing Observatory evidence shall be evidence-supporting, non-advisory, non-rating, non-guaranteeing, non-financial, non-procurement, non-executing, public-safe where externally released, confidence-aware, uncertainty-aware, limitation-aware, and correctionable.

9.29.8(d) Capital readers, public finance readers, insurers, lenders, investors, GRA, Nexus Rails, RNFD, NFD, UNFSD, National Companies, Project SPVs, public authorities, providers, sponsors, hosts, operators, or other downstream actors shall make any finance, procurement, investment, insurance, lending, underwriting, public finance, project, deployment, operational, or execution decision only under their own authority, process, records, accountability, liability, and governance instruments.

9.29.8(e) Public-safe summaries, dashboards, maps, evidence labels, confidence scores, maturity inputs, readiness inputs, host readiness outputs, resilience indicators, degraded-mode indicators, benchmark outputs, proof receipts, or Evidence Pack conclusions shall not be designed or used by GCRI Canada as finance signals, ratings, guarantees, investment recommendations, procurement recommendations, public finance approvals, provider preferences, host approvals, project approvals, or execution instructions.

9.29.8(f) Where Rails-facing Observatory materials are misused to imply finance-readiness, rating, guarantee, investment advice, insurance-readiness, lending approval, underwriting approval, public finance approval, procurement approval, project approval, provider preference, host approval, National Company instruction, Project SPV instruction, deployment approval, operational clearance, or execution, GCRI Canada shall correct, relabel, restrict, withdraw, reissue, request removal of misleading references, notify affected Rails, GRA, RNFD, NFD, UNFSD, National Company, Project SPV, public authority, provider, sponsor, host, operator, or capital-reader interfaces where appropriate, and review dependencies.

9.29.8(g) No ambiguity shall be resolved in favour of finance or execution authority by evidence input. Where there is doubt, the interpretation preserving GCRI Canada’s non-execution role, finance-readiness boundaries, procurement neutrality, provider neutrality, sponsor non-control, host boundaries, operator boundaries, public authority boundaries, GRA role separation, Rails role separation, National Company separateness, Project SPV separateness, validity-by-record, correctionability, and public trust shall prevail.

9.29.8(h) The controlling rule shall be that Observatory evidence may make risks and readiness more legible to capital readers, but it shall not finance, rate, guarantee, procure, approve, deploy, operate, or execute.

***

9.29.9 Academy Inputs Without Professional Certification by Default.\
9.29.9(a) No Observatory evidence input, Academy module, training record, attendance record, learner record, simulation, lab, demonstration, dashboard, map, dataset, technical note, Evidence Pack, Decision Pack, public-safe summary, incident lesson, correction lesson, assurance lesson, public authority learning material, community safeguard material, provider-neutrality material, sponsor non-control material, host readiness material, or Nexus Universe learning material shall create professional certification by GCRI Canada by default.

9.29.9(b) GCRI Canada shall not use Academy-facing Observatory inputs to issue professional licenses, regulated qualifications, practice authorizations, safety certifications, cybersecurity certifications, AI certifications, public authority qualifications, emergency-management qualifications, operator qualifications, provider qualifications, host qualifications, procurement qualifications, finance qualifications, investment qualifications, insurance qualifications, protocol qualifications, deployment qualifications, operational clearances, or execution authority.

9.29.9(c) Academy attendance, completion, participation, assessment, simulation performance, lab participation, dashboard use, map use, controlled-room participation, public authority learning attendance, provider participation, sponsor support, host participation, community participation, Nexus Universe participation, Grid relevance, Docket relevance, Rails relevance, or Risk Management relevance shall not be represented as professional certification, regulated competence, procurement qualification, finance qualification, public authority qualification, provider qualification, host qualification, operator approval, deployment approval, or execution readiness unless separately created by a competent actor through its own authority and record.

9.29.9(d) Academy-facing Observatory materials shall distinguish learning records from certification records, training participation from regulated qualification, simulated competence from field competence, public-safe literacy from professional authorization, evidence understanding from decision authority, and Academy completion from procurement, finance, public authority, protocol, or execution status.

9.29.9(e) Where GCRI Canada provides attendance confirmations, learning records, completion notes, internal training logs, public-safe training summaries, or Academy records, such records shall include no-professional-certification, no-license, no-regulated-qualification, no-procurement-qualification, no-finance-qualification, no-public-authority-qualification, no-provider-endorsement, no-host-approval, no-operator-approval, no-protocol-effect, no-deployment-approval, and no-execution language where material.

9.29.9(f) Where Academy-facing materials are misused to imply professional certification, regulated qualification, public authority qualification, procurement qualification, finance qualification, provider endorsement, sponsor approval, host approval, operator approval, protocol effect, deployment approval, operational clearance, or execution authority, GCRI Canada shall correct, relabel, restrict, withdraw, reissue, request removal of misleading references, notify affected Academy or Nexus interfaces where appropriate, and review dependencies.

9.29.9(g) No ambiguity shall be resolved in favour of professional certification by default. Where there is doubt, the interpretation preserving learning status, public-good education, non-execution, public authority boundaries, finance boundaries, procurement neutrality, provider neutrality, sponsor non-control, host boundaries, operator boundaries, Protocol Authority role separation, GRF role separation, GRA role separation, validity-by-record, correctionability, and public trust shall prevail.

9.29.9(h) The controlling rule shall be that Nexus Academy may teach Observatory evidence discipline, but teaching shall not become professional certification, license, regulated qualification, procurement qualification, finance qualification, public authority qualification, protocol effect, or execution authority by implication.

***

9.29.10 Interface Records, Correction Signals, and Public-Safe Summaries.\
9.29.10(a) GCRI Canada shall maintain, or cause to be maintained, interface records, correction signals, dependency notices, public-safe summaries, controlled annexes, restricted annexes, assurance records, renewal records, archive records, and closeout records for material Observatory interfaces with Nexus Grid, Nexus Docket, Nexus Rails, Nexus Risk Management, and Nexus Academy.

9.29.10(b) Interface records shall identify interface title or identifier, sending interface, receiving interface, purpose, date, materials shared, materials received, version, source records, data records, method records, compute records where applicable, model records where applicable, evidence class, data class, output class, audience class, access class, handling class, public-safe status, privacy status, cybersecurity status, sovereign data status, infrastructure-sensitive status, public authority status, finance-sensitive status, procurement-sensitive status, commercially sensitive status, provider-sensitive status, sponsor-sensitive status, host-sensitive status, operator-sensitive status, community-protected status, Indigenous or protected knowledge status, legal sensitivity, export-control sensitivity, sanctions sensitivity, controlled-technology sensitivity, permitted uses, prohibited uses, publication limits, boundary language, correction path, dependency path, notice path, and closeout path.

9.29.10(c) Grid interface records shall identify maturity-input status, competence-input status, training-input status, public-facing status restrictions, no-GCRI-maturity-record boundary, no-professional-certification boundary, no-recognition boundary, no-procurement boundary, no-finance-readiness boundary, no-public-authority boundary, no-protocol-effect boundary, and correction path.

9.29.10(d) Docket interface records shall identify docket issue class, docket purpose, issue status, review status, escalation status, correction status, dependency status, no-approval boundary, no-execution boundary, no-public-authority boundary, no-procurement boundary, no-finance boundary, no-certification boundary, no-recognition boundary, no-protocol-effect boundary, and closeout path.

9.29.10(e) Rails interface records shall identify finance-safe status, procurement-safe status, capital-reader status, GRA-facing status, RNFD-facing status, NFD-facing status, UNFSD-facing status, no-advice boundary, no-rating boundary, no-guarantee boundary, no-finance-readiness-by-GCRI boundary, no-public-finance-approval boundary, no-procurement boundary, no-execution boundary, and correction path.

9.29.10(f) Risk Management interface records shall identify risk domain, scenario status where any, risk-evidence status, public-warning boundary, emergency-command boundary, public authority boundary, public-safe status, confidence, uncertainty, limitations, incident status, correction status, no-official-risk-rating boundary, no-regulatory boundary, no-finance boundary, no-procurement boundary, and correction path.

9.29.10(g) Academy interface records shall identify training purpose, learner class, materials used, simulation status, synthetic data status, public-safe status, accessibility status, translation status where applicable, learning-record status, no-professional-certification boundary, no-license boundary, no-regulated-qualification boundary, no-procurement-qualification boundary, no-finance-qualification boundary, no-public-authority-qualification boundary, and correction path.

9.29.10(h) Correction signals shall identify corrected source, corrected data class, corrected evidence class, corrected output class, corrected method record, corrected compute record, corrected model record, corrected dashboard, corrected map, corrected API, corrected Evidence Pack, corrected Decision Pack, corrected public-safe summary, corrected Grid input, corrected Docket input, corrected Rails input, corrected Risk Management input, corrected Academy input, corrected public authority reference, corrected provider reference, corrected sponsor reference, corrected host reference, corrected operator reference, corrected community reference, corrected protected knowledge treatment, corrected boundary language, prior status, corrected status, effective date, reviewer, affected dependencies, notice decision, access change, archive treatment, and continuing limitations.

9.29.10(i) Public-safe summaries for Grid, Docket, Rails, Risk Management, or Academy interfaces shall identify only those elements that may be externally disclosed without unsafe disclosure, public authority confusion, public warning implication, finance overclaim, procurement implication, certification implication, recognition implication, protocol implication, provider preference, sponsor validation, host approval implication, operator instruction implication, community harm, protected knowledge exposure, privacy harm, cybersecurity harm, sovereign data harm, legal breach, or execution implication. Such summaries shall preserve confidence, uncertainty, limitations, boundary language, public-safe omissions, responsible non-disclosure basis, update status, version, correction path, and permitted-use limits.

9.29.10(j) Interface records, correction signals, dependency notices, public-safe summaries, controlled annexes, restricted annexes, assurance records, renewal records, supersession records, withdrawal records, retraction records, archive records, notices, and closeout shall not create certification, recognition, finance-readiness, public authority decision, regulatory finding, procurement approval, funding approval, public finance approval, provider endorsement, sponsor approval, host approval, operator approval, community consent, Indigenous consent, rating, guarantee, public warning, emergency command, protocol effect, professional certification, regulated qualification, operational clearance, legal status, market authority, infrastructure operation, remediation approval, deployment approval, national authority, regional authority, GRF maturity record, GRA finance-readiness, Docket approval, Grid maturity record, Rails finance authority, Academy certification, or execution consequence by default.

9.29.10(k) Interface records shall be linked, where applicable, to National Dense Core records, Regional Observatory Cluster records, Cluster records, Hub records, Node records, Hotspot records, host readiness records, maturity evidence records, Observatory Evidence Pack Register entries, Observatory data records, cybersecurity records, Observatory incident records, Observatory publication records, Nexus Universe Observatory records, AI-RAN records, DePIN records, sensor records, geospatial records, cyber telemetry records, digital twin records, dashboard records, degraded-mode records, sovereign compute records, public authority interface records, community interface records, provider and sponsor interface records, Observatory Methods Register entries, Evidence Register entries, Source Comparison Records, Dataset Register entries, Model Register entries, System Card entries, Benchmark Card entries, Compute Workload Records, Compute Environment Records, Inference Records, Human Review Records, Retrieval and Embedding Records, Proof Receipt Records, Public-Safe Output Records, AI Incident Records, Correction Records, Dependency Records, Truth Engine Records, Nexus Risk Management records, GRF interface records, GRA interface records, Protocol Authority interface records, RNFD records, Nexus Rails records, Nexus Grid records, Nexus Docket records, Nexus Academy records, Regional Nexus Consortium records, National Nexus Consortium records, National Company records, Project SPV records, operator records, provider records, sponsor records, host records, community records, university records, Nexus interface records, media materials, and public claims records.

9.29.10(l) The controlling rule shall be that Observatory interfaces with Grid, Docket, Rails, Risk Management, and Academy must preserve what evidence was shared, for what purpose, under what limits, corrected when, relied upon how, and prohibited from becoming what, so that evidence learning does not become maturity, approval, finance, certification, authority, professional qualification, protocol effect, or execution by implication.

### 9.30 Observatory Records and Registers

9.30.1 Observatory Methods Register.\
9.30.1(a) GCRI Canada shall maintain, or cause to be maintained, an Observatory Methods Register as the authoritative internal record of material methods stewarded, adopted, adapted, versioned, retired, corrected, superseded, restricted, or archived by GCRI Canada for Observatory purposes, including methods for Nodes, Hubs, Clusters, Hotspots, Regional Observatory Clusters, National Dense Nexus Cores, sensors, AI-RAN, O-RAN, private wireless, DePIN, cyber telemetry, geospatial evidence, Earth observation, digital twins, dashboards, public-safe publication, data governance, cybersecurity, AI governance, public authority interfaces, community safeguards, provider and sponsor interfaces, host readiness, maturity evidence, Evidence Packs, incident handling, correction, assurance, Nexus Universe interfaces, Grid interfaces, Docket interfaces, Rails interfaces, Risk Management interfaces, and Academy interfaces.

9.30.1(b) The Observatory Methods Register shall identify, for each material method, method title or identifier, method class, method purpose, method scope, relevant Observatory architecture element, technology domain, risk domain, source records, data classes, evidence classes, output classes, access classes, handling classes, public-safe status, method owner or steward, custodian, version, adoption date, review cycle, dependencies, permitted uses, prohibited uses, public authority boundaries, community safeguard boundaries, protected knowledge boundaries, provider-neutrality controls, sponsor non-control controls, host-boundary controls, operator-boundary controls, finance-boundary controls, procurement-boundary controls, certification-boundary controls, recognition-boundary controls, protocol-boundary controls, and correction path.

9.30.1(c) The Observatory Methods Register shall distinguish draft methods, proposed methods, sandbox methods, pilot methods, controlled-room methods, public-safe methods, restricted methods, deprecated methods, retired methods, superseded methods, withdrawn methods, retracted methods, archived methods, and methods approved for defined use. Method status shall not be converted into certification, recognition, finance-readiness, procurement approval, public authority decision, protocol effect, provider endorsement, sponsor approval, host approval, operator instruction, deployment approval, operational clearance, market authority, public warning, emergency command, or execution consequence by default.

9.30.1(d) Each method record shall preserve source lineage, assumptions, confidence treatment, uncertainty treatment, limitation treatment, public-safe treatment, review history, correction history, supersession history, withdrawal history, retraction history where applicable, assurance findings, training dependencies, interface dependencies, and continuing limitations.

9.30.1(e) Where a method is corrected, restricted, superseded, withdrawn, retracted, retired, or archived, the Observatory Methods Register shall identify the affected outputs, affected Evidence Packs, affected dashboards, affected maps, affected APIs, affected public-safe summaries, affected public authority materials, affected community materials, affected provider materials, affected sponsor materials, affected host materials, affected operator materials, affected GRF inputs, affected GRA inputs, affected Protocol Authority inputs, affected Grid, Docket, Rails, Risk Management, Academy, or Nexus Universe materials, notice decision, dependency treatment, and re-issue path.

9.30.1(f) The Observatory Methods Register shall not be used as a public certification list, provider approval list, host approval list, public authority list, maturity registry, finance-readiness registry, procurement registry, Protocol Authority register, GRF recognition register, GRA finance-readiness register, or execution register by implication.

9.30.1(g) Access to the Observatory Methods Register shall be governed by data class, evidence class, access class, handling class, public-safe status, public authority restrictions, community safeguards, protected knowledge status, cybersecurity status, sovereign data status, provider-sensitive status, sponsor-sensitive status, host-sensitive status, operator-sensitive status, finance-sensitive status, procurement-sensitive status, legal sensitivity, export-control sensitivity, sanctions sensitivity, controlled-technology sensitivity, and correction obligations.

9.30.1(h) The controlling rule shall be that the Observatory Methods Register records how Observatory methods are authorized, bounded, versioned, corrected, and retired; it does not confer authority, certification, recognition, finance, procurement, protocol effect, public warning, command, or execution.

***

9.30.2 Node Register.\
9.30.2(a) GCRI Canada shall maintain, or cause to be maintained, a Node Register for material Observatory Nodes for which GCRI Canada stewards, receives, reviews, routes, summarizes, corrects, or assures evidence or methods.

9.30.2(b) The Node Register shall identify Node title or identifier, Node purpose, Node scope, host context, site or safe-site treatment, facility context where safe and material, community context where any, public authority context where any, provider context where any, sponsor context where any, operator context where any, relevant technology domains, risk domains, data classes, evidence classes, output classes, access class, handling class, public-safe status, privacy status, cybersecurity status, sovereign data status, infrastructure-sensitive status, public authority status, finance-sensitive status, commercially sensitive status, provider-sensitive status, sponsor-sensitive status, host-sensitive status, operator-sensitive status, community-protected status, Indigenous or protected knowledge status, legal sensitivity, export-control sensitivity, sanctions sensitivity, controlled-technology sensitivity, permitted uses, prohibited uses, publication limits, and correction path.

9.30.2(c) Node Register entries shall identify source records, sensor records, reference sensor records where any, AI-RAN records where any, O-RAN records where any, private wireless records where any, DePIN records where any, geospatial records where any, cyber telemetry records where any, digital twin records where any, dashboard records where any, map records where any, API records where any, compute workload records, compute environment records, model records where any, dataset records where any, Evidence Packs, Decision Packs, public-safe summaries, incident records, correction records, host readiness records, maturity evidence inputs, assurance records, renewal records, closeout records, and dependency links.

9.30.2(d) Node status shall be recorded according to evidence status and method status, including draft, proposed, planned, sandbox, pilot, active, controlled-room-only, restricted, public-safe, degraded, incident-affected, correction-pending, assurance-pending, renewed, suspended, retired, archived, or closed out. Node status shall not constitute certification, recognition, finance-readiness, procurement approval, public authority approval, host approval, provider preference, sponsor approval, protocol effect, operational clearance, deployment approval, public warning, emergency command, market authority, legal status, or execution consequence by default.

9.30.2(e) Where a Node entry is corrected, restricted, superseded, withdrawn, retracted, retired, or closed out, the Node Register shall identify the reason, affected records, affected outputs, affected interfaces, affected public-safe publications, affected dashboards, affected maps, affected APIs, affected Evidence Packs, affected Decision Packs, dependency notices, access changes, archive treatment, and continuing prohibited uses.

9.30.2(f) The Node Register shall not be publicly represented as a list of approved Nodes, certified Nodes, recognized Nodes, finance-ready Nodes, procurement-ready Nodes, public authority-approved Nodes, Nexus-compatible Nodes, deployment-ready Nodes, provider-preferred Nodes, sponsor-approved Nodes, host-approved Nodes, operationally cleared Nodes, or execution-ready Nodes.

9.30.2(g) Where Node Register information is used externally or publicly, GCRI Canada shall preserve public-safe status, safe-location treatment where applicable, confidence, uncertainty, limitations, boundary language, permitted use, prohibited use, and correction path.

9.30.2(h) The controlling rule shall be that the Node Register records the evidence and methods state of a Node, not the certified, approved, financed, procured, deployed, or operational status of the Node.

***

9.30.3 Hub Register.\
9.30.3(a) GCRI Canada shall maintain, or cause to be maintained, a Hub Register for material Observatory Hubs for which GCRI Canada stewards, receives, reviews, routes, summarizes, corrects, or assures coordination, aggregation, public-safe, interface, or methods evidence.

9.30.3(b) The Hub Register shall identify Hub title or identifier, Hub purpose, Hub scope, participating or related Nodes where applicable, host context where any, regional context where any, public authority context where any, community context where any, provider context where any, sponsor context where any, operator context where any, aggregation role, routing role, controlled-room role where any, dashboard role, map role, API role, public-safe role, access class, handling class, data classes, evidence classes, output classes, public-safe status, permitted uses, prohibited uses, publication limits, and correction path.

9.30.3(c) Hub Register entries shall identify source comparison records, Node Evidence Packs, interface records, aggregation records, data-routing records, controlled-room records, data-room records, clean-room records, no-download room records, compute-to-data records, dashboard records, map records, API records, public authority interface records, community interface records, provider and sponsor interface records, host records, operator records, incident records, correction records, public-safe output records, assurance records, renewal records, closeout records, and dependency links.

9.30.3(d) Hub status shall distinguish planning, draft, controlled build, active, restricted, public-safe, degraded, incident-affected, correction-pending, assurance-pending, suspended, renewed, retired, archived, and closed-out states. Hub status shall not create regional authority, public authority room status, procurement hub status, finance hub status, certified coordination status, recognition status, provider marketplace status, sponsor territory, emergency-management structure, operational command centre, protocol effect, or execution vehicle status by default.

9.30.3(e) Where Hub Register entries are corrected, restricted, superseded, withdrawn, retracted, retired, or closed out, GCRI Canada shall update affected Node relationships, dashboards, maps, APIs, public-safe summaries, Evidence Packs, Decision Packs, interface logs, public authority materials, community materials, provider materials, sponsor materials, host materials, operator materials, dependency notices, and archive records as appropriate.

9.30.3(f) The Hub Register shall not be publicly represented as a list of approved Hubs, certified Hubs, recognized Hubs, finance-ready Hubs, procurement-ready Hubs, public authority-approved Hubs, provider-preferred Hubs, sponsor-approved Hubs, host-approved Hubs, operationally cleared Hubs, or execution Hubs.

9.30.3(g) Hub Register information released externally shall be public-safe, boundary-valid, confidence-aware, uncertainty-aware, limitation-aware, and correctionable.

9.30.3(h) The controlling rule shall be that the Hub Register records coordination and aggregation evidence, not hub authority, approval, certification, finance, procurement, command, or execution.

***

9.30.4 Cluster Register.\
9.30.4(a) GCRI Canada shall maintain, or cause to be maintained, a Cluster Register for material Observatory Clusters, including multi-Node, multi-host, multi-domain, technical, geographic, functional, regional, thematic, or risk-domain evidence arrangements.

9.30.4(b) The Cluster Register shall identify Cluster title or identifier, Cluster purpose, Cluster scope, topology, included Nodes, included Hubs where any, included Hotspots where any, included hosts, regional context where any, technology domains, risk domains, source classes, data classes, evidence classes, output classes, access class, handling class, public-safe status, interoperability status, mismatch status, confidence status, uncertainty status, contradiction status, data-gap status, assurance status, permitted uses, prohibited uses, publication limits, and correction path.

9.30.4(c) Cluster Register entries shall identify Node Evidence Packs, Hub Evidence Packs, Hotspot Evidence Packs where any, source comparison records, interoperability records, mismatch logs, aggregation records, confidence records, uncertainty records, contradiction records, data-gap records, dashboards, maps, APIs, public authority interface records, community safeguard records, provider and sponsor interface records, host records, operator records, incident records, degraded-mode records, public-safe output records, assurance records, correction records, renewal records, and dependency links.

9.30.4(d) Cluster status shall distinguish draft, planned, sandbox, pilot, active, controlled, restricted, public-safe, degraded, incident-affected, correction-pending, assurance-pending, renewed, suspended, retired, archived, or closed-out status. Cluster status shall not create official region status, procurement zone status, investment zone status, public warning area status, certification, recognition, provider market, sponsor territory, finance-readiness, protocol effect, deployment approval, operational clearance, or execution readiness by default.

9.30.4(e) Where a Cluster Register entry is corrected, restricted, superseded, withdrawn, retracted, retired, or closed out, GCRI Canada shall update affected Node, Hub, Hotspot, host, dashboard, map, API, public-safe, interface, dependency, assurance, and archive records as appropriate.

9.30.4(f) Cluster Register entries shall preserve source differences, jurisdictional differences, host differences, community differences, public authority differences, provider differences, sponsor differences, data gaps, contradictions, mismatch logs, confidence limits, uncertainty, and public-safe omissions. Cluster registration shall not erase context to create artificial maturity or coherence.

9.30.4(g) The Cluster Register shall not be publicly represented as a list of certified clusters, recognized clusters, public authority clusters, finance-ready clusters, procurement-ready clusters, provider markets, sponsor territories, protocol-effective clusters, or execution structures.

9.30.4(h) The controlling rule shall be that the Cluster Register makes cross-Node evidence traceable while preventing clustered evidence from becoming authority, market status, certification, recognition, finance, procurement, protocol effect, or execution.

***

9.30.5 Hotspot Register.\
9.30.5(a) GCRI Canada shall maintain, or cause to be maintained, a Hotspot Register for material Observatory Hotspots involving localized evidence, connectivity, sensing, compute, field-observation, public-safe learning, community, host, public authority, provider, sponsor, operator, or degraded-mode contexts.

9.30.5(b) The Hotspot Register shall identify Hotspot title or identifier, Hotspot purpose, localized scope, location or safe-location treatment, host context, community context, Indigenous or protected knowledge context where any, public authority context where any, provider context where any, sponsor context where any, operator context where any, data classes, evidence classes, output classes, access class, handling class, public-safe status, sensitive-site status, small-community risk status, re-identification risk status, public authority reference status, permitted uses, prohibited uses, publication limits, and correction path.

9.30.5(c) Hotspot Register entries shall identify localized sensor records, AI-RAN records, O-RAN records, private wireless records, DePIN records, geospatial records, field observation records, cyber telemetry records, digital twin records, dashboard records, map records, API records, host contribution records, community records, protected knowledge records where any, public authority learning records, provider records, sponsor records where any, consent or non-consent records where applicable, incident records, public-safe communication records, correction records, and dependency links.

9.30.5(d) Hotspot status shall distinguish evidence attention, local learning, controlled-room use, public-safe use, restricted use, incident-affected status, correction-pending status, suspended status, retired status, archived status, or closed-out status. Hotspot status shall not create official hazard area, public warning area, public authority presence, deployment-approved site, certified site, recognized site, finance-ready site, procurement-ready site, provider-preferred area, sponsor-approved area, host-approved area, community-approved area, or execution site by default.

9.30.5(e) Where Hotspot Register entries are corrected, restricted, superseded, withdrawn, retracted, retired, or closed out, GCRI Canada shall update affected local communications, dashboards, maps, public-safe summaries, community-facing records, public authority-facing records, provider-facing records, sponsor-facing records, host-facing records, operator-facing records, dependency notices, and archive records as appropriate.

9.30.5(f) Hotspot Register information shall be public-safe before external release and shall not expose protected persons, sensitive locations, cultural sites, protected knowledge, small-community patterns, infrastructure vulnerabilities, cyber-sensitive details, public authority restricted information, or host-sensitive information.

9.30.5(g) The Hotspot Register shall not be used to create market maps, procurement maps, finance maps, public warning maps, provider territory maps, sponsor territory maps, host approval maps, or deployment maps by implication.

9.30.5(h) The controlling rule shall be that the Hotspot Register records localized evidence attention while protecting local safety, dignity, sensitive places, protected knowledge, and correctionability.

***

9.30.6 Regional Cluster Register.\
9.30.6(a) GCRI Canada shall maintain, or cause to be maintained, a Regional Cluster Register for material Regional Observatory Clusters and regional evidence arrangements for which GCRI Canada stewards methods, evidence, public-safe outputs, corrections, or interface records.

9.30.6(b) The Regional Cluster Register shall identify Regional Observatory Cluster title or identifier, regional purpose, regional scope, jurisdictional context, geographic or functional scope, included Nodes, included Hubs, included Clusters, included Hotspots where any, host contexts, public authority contexts, community contexts, Indigenous or protected knowledge contexts where any, provider contexts, sponsor contexts where any, operator contexts where any, data sovereignty status, cross-border status, public-safe publication status, GRF interface status, GRA interface status, Nexus Risk Management interface status, Nexus Rails interface status, Regional Nexus Consortium interface status, National Nexus Consortium interface status, National Company interface status, Project SPV interface status, access class, handling class, permitted uses, prohibited uses, publication limits, and correction path.

9.30.6(c) Regional Cluster Register entries shall identify regional hazard records, host readiness records, public authority learning records, community safeguard records, Indigenous safeguard records where applicable, protected knowledge records where any, data sovereignty records, cross-border records, dashboards, maps, APIs, Evidence Packs, Decision Packs, public-safe summaries, GRF interface records, GRA interface records, Nexus Risk Management records, Nexus Rails records, Regional Nexus Consortium records, National Nexus Consortium records, National Company records, Project SPV records, provider records, sponsor records where any, incident records, correction records, renewal records, assurance records, and dependency links.

9.30.6(d) Regional Cluster status shall not create regional public authority, official regional designation, public warning region, procurement region, finance-ready region, investment region, certified region, recognized region, protocol-effective region, provider market, sponsor territory, deployment-approved region, operational clearance, market authority, legal status, or execution authority by default.

9.30.6(e) Where a Regional Cluster Register entry is corrected, restricted, superseded, withdrawn, retracted, retired, or renewed, GCRI Canada shall update affected regional public-safe summaries, dashboards, maps, public authority learning materials, GRF inputs, GRA inputs, Nexus Risk Management inputs, Nexus Rails inputs, National Nexus Consortium materials, National Company materials, Project SPV materials, provider-facing materials, sponsor-facing materials, host-facing materials, operator-facing materials, community-facing materials, dependency notices, renewal records, assurance records, and archive records as appropriate.

9.30.6(f) Regional Cluster Register information shall preserve regional limitations, jurisdictional limitations, cross-border limits, public authority boundaries, community safeguards, protected knowledge safeguards, sovereign data limits, finance boundaries, procurement boundaries, provider neutrality, sponsor non-control, confidence, uncertainty, public-safe omissions, and correction status.

9.30.6(g) The Regional Cluster Register shall not be represented as a registry of approved regions, certified regions, investment regions, procurement regions, public authority regions, or operational regions.

9.30.6(h) The controlling rule shall be that the Regional Cluster Register records regional evidence architecture without creating regional authority, finance, procurement, recognition, certification, protocol effect, or execution.

***

9.30.7 National Dense Core Evidence Register.\
9.30.7(a) GCRI Canada shall maintain, or cause to be maintained, a National Dense Core Evidence Register for material National Dense Nexus Core evidence relationships, records, methods, interfaces, compute records, public-safe outputs, corrections, assurance findings, and renewal inputs stewarded or used by GCRI Canada.

9.30.7(b) The National Dense Core Evidence Register shall identify National Dense Nexus Core title or identifier, national purpose, national scope, jurisdictional context, regional relationships, Node relationships, Hub relationships, Cluster relationships, Hotspot relationships, sovereign compute relationships, public authority data relationships, national data governance relationships, National Nexus Consortium context, National Company context, Project SPV context, operator context where any, host context, provider context, sponsor context where any, community context, Indigenous or protected knowledge context where any, data classes, evidence classes, output classes, access class, handling class, public-safe status, sovereign data status, compute-to-data status, cross-border status, cybersecurity status, public authority status, finance-sensitive status, procurement-sensitive status, permitted uses, prohibited uses, publication limits, and correction path.

9.30.7(c) Register entries shall identify sovereign compute records, compute workload records, compute environment records, public authority data records, national data governance records, model records, dataset records, system cards, benchmark cards, inference records, cybersecurity records, key management records, dashboards, maps, APIs, Proof Receipts, public-safe summaries, GRF interface records, GRA interface records, Protocol Authority interface records, Nexus Risk Management records, Nexus Rails records, National Nexus Consortium records, National Company records, Project SPV records, provider records, sponsor records where any, operator records, host records, community records, protected knowledge records where any, incident records, correction records, assurance records, renewal records, and closeout records.

9.30.7(d) National Dense Core evidence status shall not create national public authority, official national program status, public finance program status, procurement program status, investment zone status, certified ecosystem status, recognized ecosystem status, protocol-effective ecosystem status, provider market status, sponsor territory, infrastructure operating system status, telecommunications operating system status, AI-RAN operating status, emergency-management structure status, public warning system status, market infrastructure status, deployment approval mechanism, or execution authority by default.

9.30.7(e) Where National Dense Core evidence is corrected, restricted, superseded, withdrawn, retracted, renewed, retired, or archived, GCRI Canada shall update affected national public-safe summaries, dashboards, maps, APIs, public authority learning materials, GRF inputs, GRA inputs, Protocol Authority inputs, Nexus Risk Management inputs, Nexus Rails inputs, National Nexus Consortium materials, National Company materials, Project SPV materials, operator-facing materials, provider-facing materials, sponsor-facing materials, host-facing materials, community-facing materials, dependency notices, assurance records, renewal records, and archive records as appropriate.

9.30.7(f) The National Dense Core Evidence Register shall not be publicly represented as an ownership register, operating register, approval register, procurement register, finance register, public authority register, certification register, recognition register, or national infrastructure control register.

9.30.7(g) National Dense Core Evidence Register information shall preserve sovereignty, jurisdiction, access, compute, transfer, restriction, public authority boundary, community safeguard, protected knowledge, provider-neutrality, sponsor non-control, finance-safe, procurement-safe, public-safe, and correction controls.

9.30.7(h) The controlling rule shall be that the National Dense Core Evidence Register records national-scale evidence and compute relationships without making GCRI Canada the owner, operator, authority, financier, procurement actor, certifier, recognizer, or executor of national infrastructure.

***

9.30.8 Sensor Register.\
9.30.8(a) GCRI Canada shall maintain, or cause to be maintained, a Sensor Register for material sensors, reference sensors, community sensors, environmental sensors, infrastructure sensors, cyber-physical sensors, health-sensitive or human-proximate sensors, industrial sensors, utility sensors, port sensors, corridor sensors, remote community sensors, field sensors, and sensor-derived evidence sources used in or associated with Observatory systems.

9.30.8(b) The Sensor Register shall identify sensor title or identifier where safe, sensor class, source, owner where known, custodian, steward, host context, operator context where any, provider context where any, community context where any, public authority context where any, location or safe-location treatment, timing method, calibration status, configuration status, maintenance status, firmware or software status, custody status, data classes, evidence classes, output classes, access class, handling class, public-safe status, privacy status, cybersecurity status, sovereign data status, infrastructure-sensitive status, health-sensitive status, community-protected status, Indigenous or protected knowledge status, permitted uses, prohibited uses, publication limits, and correction path.

9.30.8(c) Sensor Register entries shall identify calibration records, maintenance records, configuration records, custody records, signal quality records, data quality records, reference sensor comparison records, sensor fusion records, source comparison records, confidence records, uncertainty records, missing data records, spoof risk records, tamper risk records, incident records, public-safe records, Evidence Pack links, dashboard links, map links, API links, correction records, supersession records, withdrawal records, retirement records, and archive records.

9.30.8(d) Sensor status shall distinguish planned, installed, active, inactive, degraded, failed, calibration-pending, maintenance-pending, incident-affected, source-downgraded, public-safe-cleared, restricted, retired, decommissioned, archived, and closed-out states. Sensor status shall not create sensor certification, provider endorsement, host approval, public authority approval, procurement approval, finance-readiness, operational clearance, public warning, emergency command, protocol effect, deployment approval, infrastructure operation, market authority, or execution consequence by default.

9.30.8(e) Where sensor records are corrected, downgraded, restricted, superseded, withdrawn, retracted, retired, or decommissioned, GCRI Canada shall update affected source comparison records, confidence records, uncertainty records, dashboards, maps, APIs, digital twins, Evidence Packs, Decision Packs, public-safe outputs, GRF inputs, GRA inputs, Protocol Authority inputs, public authority learning materials, community-facing materials, provider-facing materials, sponsor-facing materials, host-facing materials, operator-facing materials, Academy materials, and public claims where appropriate.

9.30.8(f) Sensor Register information shall not be released externally in a manner that exposes sensitive locations, infrastructure vulnerabilities, protected persons, community-sensitive sites, cyber-sensitive details, host-sensitive information, operator-sensitive information, or protected knowledge.

9.30.8(g) The Sensor Register shall not be represented as a certification register, approved device list, procurement list, provider ranking, public warning system, regulatory record, or operational command record.

9.30.8(h) The controlling rule shall be that the Sensor Register records sensor identity, custody, calibration, quality, risk, and correction status as evidence, not as certification, approval, warning, command, procurement, finance, or execution.

***

9.30.9 AI-RAN / O-RAN Evidence Register.\
9.30.9(a) GCRI Canada shall maintain, or cause to be maintained, an AI-RAN / O-RAN Evidence Register for material AI-RAN, O-RAN, private wireless, telecommunications-adjacent, edge intelligence, network telemetry, radio signal, spectrum-adjacent, networked sensing, and connectivity evidence used in or associated with Observatory systems.

9.30.9(b) The AI-RAN / O-RAN Evidence Register shall identify evidence title or identifier, network or signal class, telemetry class, edge intelligence context, affected Node, Hub, Cluster, Hotspot, Regional Observatory Cluster, National Dense Nexus Core where applicable, provider where any, operator where any, host where any, public authority context where any, community context where any, timing status, location or safe-location treatment, signal quality, calibration or signal-integrity status where applicable, data classes, evidence classes, output classes, access class, handling class, public-safe status, privacy status, metadata sensitivity, cybersecurity status, infrastructure-sensitive status, public authority sensitivity, sovereign data status, permitted uses, prohibited uses, publication limits, and correction path.

9.30.9(c) Register entries shall identify network telemetry records, signal records, edge compute records, compute workload records, cybersecurity records, privacy records, provider contribution records, operator records, host records, source comparison records, confidence records, uncertainty records, spoofing records, interference records, degraded-mode records, incident records, dashboard records, map records, API records, Evidence Pack links, public-safe output links, correction records, supersession records, withdrawal records, retirement records, and archive records.

9.30.9(d) AI-RAN / O-RAN evidence status shall not create telecommunications regulation, spectrum authorization, service assurance, network certification, provider ranking, provider preference, procurement approval, finance-readiness, public authority decision, public warning, emergency command, protocol effect, operational clearance, deployment approval, infrastructure operation, market authority, legal status, or execution consequence by default.

9.30.9(e) Where AI-RAN / O-RAN evidence is corrected, downgraded, restricted, superseded, withdrawn, retracted, retired, or archived, GCRI Canada shall update affected sensor records, DePIN records, cyber telemetry records, digital twins, dashboards, maps, APIs, Evidence Packs, Decision Packs, public-safe outputs, GRF inputs, GRA inputs, Protocol Authority inputs, public authority learning materials, community-facing materials, provider-facing materials, sponsor-facing materials, host-facing materials, operator-facing materials, Nexus Universe records, Academy materials, and public claims as appropriate.

9.30.9(f) AI-RAN / O-RAN Register information shall be handled to prevent unsafe disclosure of metadata, location sensitivity, public authority sensitivity, infrastructure sensitivity, provider-sensitive information, operator-sensitive information, cyber-sensitive information, and public-safe risks.

9.30.9(g) The AI-RAN / O-RAN Evidence Register shall not be represented as an approved network list, telecommunications certification register, procurement list, provider ranking, public authority record, public warning record, or operational command register.

9.30.9(h) The controlling rule shall be that AI-RAN and O-RAN records are evidence records only; they do not regulate, certify, procure, finance, operate, warn, command, or execute.

***

9.30.10 DePIN Evidence Register.\
9.30.10(a) GCRI Canada shall maintain, or cause to be maintained, a DePIN Evidence Register for material distributed infrastructure evidence, device evidence, proof evidence, proof receipt evidence, ledger-adjacent evidence, network evidence, availability evidence, coverage evidence, capacity evidence, service evidence, mission-specific proof evidence, and tamper or spoofing evidence used in or associated with Observatory systems.

9.30.10(b) The DePIN Evidence Register shall identify evidence title or identifier, device identity where safe, hardware identity where material, proof class, proof method, proof source, location claim, uptime claim, availability claim, capacity claim, coverage claim, service claim, ledger relationship where any, token relationship where any, provider where any, host where any, operator where any, community context where any, public authority context where any, data classes, evidence classes, output classes, access class, handling class, public-safe status, privacy status, location sensitivity, cybersecurity status, infrastructure-sensitive status, community safeguard status, public authority sensitivity, permitted uses, prohibited uses, publication limits, and correction path.

9.30.10(c) Register entries shall identify proof-of-competence records, proof-of-coverage records, proof-of-availability records, proof-of-integrity records, proof-of-observation records, mission-specific proof records, proof receipt records, anchoring records, hashing records, signing records, timestamping records, source comparison records, confidence records, uncertainty records, tamper-risk records, spoof-risk records, fraud-risk records, incentive-risk records, privacy records, location-safety records, incident records, dashboard records, map records, API records, Evidence Pack links, correction records, supersession records, withdrawal records, revocation records, retirement records, and archive records.

9.30.10(d) DePIN evidence status, tokens, ledger entries, proof receipts, cryptographic anchors, hashes, signatures, timestamps, dashboards, maps, proof summaries, or public-safe claims shall not be treated as authority, truth, certification, recognition, finance-readiness, procurement approval, public authority decision, public warning, provider preference, sponsor approval, host approval, operator instruction, protocol effect, market entitlement, deployment approval, legal status, or execution consequence by default.

9.30.10(e) Where DePIN evidence or proof records are corrected, restricted, revoked, superseded, withdrawn, retracted, retired, or archived, GCRI Canada shall update affected proof receipts, dashboards, maps, APIs, Evidence Packs, Decision Packs, public-safe outputs, GRF inputs, GRA inputs, Protocol Authority inputs, Nexus Risk Management inputs, Rails materials, public authority learning materials, community-facing materials, provider-facing materials, sponsor-facing materials, host-facing materials, operator-facing materials, Academy materials, and public claims where appropriate.

9.30.10(f) DePIN Evidence Register information shall be handled to prevent token-as-authority overclaim, market entitlement overclaim, location exposure, community exposure, public authority confusion, provider preference, sponsor validation, finance overclaim, procurement implication, and public-safe misuse.

9.30.10(g) The DePIN Evidence Register shall not be represented as a token registry, market entitlement registry, finance-readiness registry, procurement registry, certification registry, recognition registry, public authority registry, or protocol-effect registry by GCRI Canada.

9.30.10(h) The controlling rule shall be that DePIN records establish traceable evidence claims only to the extent of identity, method, custody, context, limits, and correction; proof is not authority by default.

***

9.30.11 Geospatial and Mapping Register.\
9.30.11(a) GCRI Canada shall maintain, or cause to be maintained, a Geospatial and Mapping Register for material geospatial evidence, Earth observation evidence, satellite data, remote sensing data, drone or aerial data where applicable, GIS layers, location data, environmental layers, public-safe maps, controlled maps, restricted maps, dashboard maps, API map layers, digital twin geospatial layers, and public-safe visualizations used in or associated with Observatory systems.

9.30.11(b) The Geospatial and Mapping Register shall identify map or layer title or identifier, source, license, spatial resolution, temporal resolution, projection or coordinate reference system where material, layer class, data classes, evidence classes, output classes, access class, handling class, public-safe status, safe-location treatment, sensitive-site treatment, infrastructure-sensitive treatment, cyber-sensitive treatment, cultural-site treatment, community sensitivity, Indigenous or protected knowledge status, public authority status, finance-sensitive status, provider-sensitive status, sponsor-sensitive status, host-sensitive status, operator-sensitive status, confidence, uncertainty, limitations, permitted uses, prohibited uses, publication limits, and correction path.

9.30.11(c) Register entries shall identify map version, source records, data lineage records, public-safe mapping review, re-identification review, group harm review, sensitive-site review, community review where required, public authority review where required, dashboard links, API links, digital twin links, Evidence Pack links, Decision Pack links, correction records, supersession records, withdrawal records, retraction records, archive records, and dependency links.

9.30.11(d) Geospatial or mapping status shall not create official map status, public warning status, public authority decision, regulatory determination, procurement effect, finance-readiness, certification, recognition, provider preference, sponsor approval, host approval, operator instruction, protocol effect, deployment approval, operational clearance, legal status, market authority, or execution consequence by default.

9.30.11(e) Where maps or geospatial layers are corrected, generalized, restricted, superseded, withdrawn, retracted, archived, or made stale, GCRI Canada shall update affected dashboards, APIs, digital twins, Evidence Packs, Decision Packs, public-safe outputs, public authority materials, community materials, provider materials, sponsor materials, host materials, operator materials, GRF inputs, GRA inputs, Protocol Authority inputs, Nexus Risk Management materials, Rails materials, Academy materials, media materials, and public claims as appropriate.

9.30.11(f) Geospatial and Mapping Register information shall not be released externally in a manner that exposes protected persons, sensitive locations, cultural sites, sacred sites, protected sites, protected habitats, community-sensitive locations, traditional-use areas, infrastructure vulnerabilities, cyber-sensitive locations, host-sensitive sites, operator-sensitive sites, public authority restricted locations, or protected knowledge.

9.30.11(g) The Geospatial and Mapping Register shall not be represented as an official mapping authority, public warning map registry, public authority map registry, procurement map, finance map, certification map, recognition map, provider territory map, sponsor territory map, deployment map, or execution map.

9.30.11(h) The controlling rule shall be that geospatial records must preserve what is shown, what is hidden, what is generalized, what is uncertain, what is unsafe to reveal, and what must be corrected.

***

9.30.12 Digital Twin and Simulation Register.\
9.30.12(a) GCRI Canada shall maintain, or cause to be maintained, a Digital Twin and Simulation Register for material digital twins, simulations, scenario engines, model-based evidence systems, infrastructure continuity models, degraded-mode models, public-safe visualizations, Nexus Universe simulations, Academy simulations, Risk Management scenarios, and simulation-derived Observatory outputs.

9.30.12(b) The Digital Twin and Simulation Register shall identify system title or identifier, purpose, scope, scenario class, system owner or steward where applicable, source inputs, assumptions, calibration status, validation status, sensitivity treatment, boundary conditions, model identity, model version, dataset identity, compute workload, compute environment, dashboard links, map links, API links, data classes, evidence classes, output classes, access class, handling class, public-safe status, public authority status, community safeguard status, protected knowledge status, infrastructure-sensitive status, cyber-sensitive status, finance-sensitive status, confidence, uncertainty, limitations, permitted uses, prohibited uses, publication limits, and correction path.

9.30.12(c) Register entries shall identify Model Cards, System Cards, Dataset Cards, Benchmark Cards, evaluation harnesses, compute records, inference records, human review records, public-safe review records, false-precision controls, scenario overclaim controls, stale assumption controls, public authority boundary records, community safeguard records, provider records, sponsor records, host records, operator records, incident records, correction records, supersession records, retirement records, and archive records.

9.30.12(d) Digital twin or simulation status shall distinguish concept, draft, sandbox, simulated, calibrated, uncalibrated, partially validated, reviewed, public-safe, controlled, restricted, stale, incident-affected, correction-pending, superseded, retired, archived, or closed-out status. Such status shall not create real-world readiness, public authority decision, public warning, emergency command, finance-readiness, procurement approval, certification, recognition, provider preference, sponsor approval, host approval, operator instruction, protocol effect, deployment approval, operational clearance, market authority, legal status, or execution consequence by default.

9.30.12(e) Where digital twin or simulation records are corrected, restricted, superseded, withdrawn, retracted, retired, or archived, GCRI Canada shall update affected dashboards, maps, APIs, Evidence Packs, Decision Packs, public-safe outputs, public authority materials, community materials, provider materials, sponsor materials, host materials, operator materials, GRF inputs, GRA inputs, Protocol Authority inputs, Nexus Risk Management materials, Rails materials, Academy materials, Nexus Universe materials, media materials, and public claims as appropriate.

9.30.12(f) Digital Twin and Simulation Register information shall preserve assumptions, uncertainty, limitations, scenario status, false-precision controls, public-safe status, boundary language, and correction path wherever simulation outputs are used.

9.30.12(g) The Digital Twin and Simulation Register shall not be represented as a real-world certification register, deployment approval register, operational clearance register, public authority register, public warning register, procurement register, finance register, provider ranking register, or execution register.

9.30.12(h) The controlling rule shall be that digital twins and simulations are scenario evidence and learning tools; they do not become decisions, authority, warnings, finance, procurement, certification, recognition, protocol effect, or execution by registration.

***

9.30.13 Dashboard Register.\
9.30.13(a) GCRI Canada shall maintain, or cause to be maintained, a Dashboard Register for material dashboards, maps embedded in dashboards, visualization systems, reports with dashboard functions, APIs with dashboard functions, public-safe display systems, controlled-room display systems, restricted display systems, Nexus Universe dashboards, Academy dashboards, Risk Management dashboards, Rails-facing dashboards, public authority dashboards, community dashboards, provider-facing dashboards, sponsor-facing dashboards, host-facing dashboards, and operator-facing dashboards used in or associated with Observatory systems.

9.30.13(b) The Dashboard Register shall identify dashboard title or identifier, purpose, audience, owner or steward, source records, data records, method records, dashboard logic, field meanings, indicator meanings, score meanings where any, color meanings, legend meanings, update status, timestamp, version, access class, handling class, public-safe status, controlled status, restricted status, data classes, evidence classes, output classes, public authority status, community safeguard status, protected knowledge status, cybersecurity status, infrastructure-sensitive status, finance-sensitive status, commercially sensitive status, provider-sensitive status, sponsor-sensitive status, host-sensitive status, operator-sensitive status, permitted uses, prohibited uses, publication limits, export rights, screenshot limits, API rights, redistribution limits, citation rules, and correction path.

9.30.13(c) Register entries shall identify dashboard review records, public-safe review records, access logs where material, export logs where material, screenshot-risk controls, API links, data source links, map links, Evidence Pack links, Decision Pack links, confidence display records, uncertainty display records, limitation display records, stale-data records, incident records, misuse records, correction records, supersession records, withdrawal records, retraction records, retirement records, archive records, and dependency links.

9.30.13(d) Dashboard status shall distinguish draft, internal, controlled, restricted, public-safe, live, delayed, frozen, historical, degraded, stale, incident-affected, correction-pending, superseded, withdrawn, retracted, retired, archived, and closed-out status. Dashboard status shall not create official truth, public warning, emergency command, public authority decision, procurement approval, finance-readiness, rating, guarantee, certification, recognition, provider preference, sponsor approval, host approval, operator instruction, protocol effect, deployment approval, operational clearance, market authority, legal status, or execution consequence by default.

9.30.13(e) Where dashboards are corrected, restricted, superseded, withdrawn, retracted, retired, archived, or made stale, GCRI Canada shall update affected maps, APIs, Evidence Packs, Decision Packs, public-safe summaries, public authority materials, community materials, provider materials, sponsor materials, host materials, operator materials, GRF inputs, GRA inputs, Protocol Authority inputs, Nexus Risk Management materials, Rails materials, Academy materials, Nexus Universe materials, media materials, repositories, and public claims as appropriate.

9.30.13(f) Dashboard Register information shall be handled to prevent public warning implication, authority implication, finance implication, procurement implication, certification implication, recognition implication, provider preference, sponsor validation, host approval implication, operator instruction implication, public-safe misuse, screenshot misuse, export misuse, API misuse, and stale-data reliance.

9.30.13(g) The Dashboard Register shall not be represented as a registry of approved dashboards, official dashboards, public authority dashboards, warning dashboards, finance dashboards, procurement dashboards, certified dashboards, recognized dashboards, provider-ranking dashboards, or execution dashboards.

9.30.13(h) The controlling rule shall be that dashboards are evidence displays whose meaning depends on source, version, audience, confidence, uncertainty, limits, boundary language, and correction path, not on visual polish or live display.

***

9.30.14 Observatory Evidence Pack Register.\
9.30.14(a) GCRI Canada shall maintain, or cause to be maintained, an Observatory Evidence Pack Register for material Observatory Evidence Packs, including Node Evidence Packs, Hub Evidence Packs, Cluster Evidence Packs, Hotspot Evidence Packs, Regional Cluster Evidence Packs, National Dense Core Evidence Packs, Nexus Universe Evidence Packs, component-specific Evidence Packs, public-safe summaries, controlled annexes, restricted annexes, correction annexes, supersession records, withdrawal records, retraction records, re-issue records, dependency notices, assurance records, renewal records, archive records, and closeout records.

9.30.14(b) The Observatory Evidence Pack Register shall identify Evidence Pack title or identifier, Evidence Pack class, purpose, scope, related Node, Hub, Cluster, Hotspot, Regional Observatory Cluster, National Dense Nexus Core, Nexus Universe activity where any, host, operator, provider, sponsor, public authority, community, Indigenous or protected knowledge context, GRF interface, GRA interface, Protocol Authority interface, Nexus Risk Management interface, Nexus Rails interface, Nexus Grid interface, Nexus Docket interface, Nexus Academy interface, National Nexus Consortium interface, Regional Nexus Consortium interface, National Company interface, Project SPV interface, technology domain, risk domain, data class, evidence class, output class, audience class, access class, handling class, public-safe status, privacy status, cybersecurity status, sovereign data status, infrastructure-sensitive status, public authority status, finance-sensitive status, provider-sensitive status, sponsor-sensitive status, host-sensitive status, operator-sensitive status, community-protected status, Indigenous or protected knowledge status, legal sensitivity, export-control sensitivity, sanctions sensitivity, controlled-technology sensitivity, permitted uses, prohibited uses, publication limits, correction path, and register status.

9.30.14(c) Register entries shall identify version, release status, public-safe summary status, controlled annex status, restricted annex status, source record status, method record status, compute record status, model record status where any, dataset record status where any, dashboard record status where any, map record status where any, API record status where any, confidence status, uncertainty status, limitation status, contradiction status, data-gap status, boundary-language status, review status, assurance status, correction status, supersession status, withdrawal status where applicable, retraction status where applicable, re-issue status, archive status, and closeout status.

9.30.14(d) The Observatory Evidence Pack Register shall preserve interface logs identifying sending interface, receiving interface, date, purpose, capacity of recipient, materials shared, materials received, version, access class, handling class, public-safe status, finance-safe status where applicable, procurement-safe status where applicable, recognition-boundary status where applicable, certification-boundary status where applicable, protocol-boundary status where applicable, public authority boundary status where applicable, provider-neutrality status, sponsor non-control status, host-boundary status, operator-boundary status, community-safeguard status, protected-knowledge status, permitted use, prohibited use, boundary language, correction path, dependency path, notice path, and closeout path.

9.30.14(e) Correction entries shall identify corrected source, corrected Evidence Pack, corrected component, corrected annex, corrected public-safe summary, corrected confidence, corrected uncertainty, corrected limitation, corrected dashboard, corrected map, corrected API, corrected public authority reference, corrected provider reference, corrected sponsor reference, corrected host reference, corrected operator reference, corrected community reference, corrected protected knowledge treatment, corrected boundary language, prior status, corrected status, effective date, reviewer, affected dependencies, notice decision, access change, archive treatment, and continuing limitations.

9.30.14(f) Supersession, withdrawal, or retraction entries shall identify replacement Evidence Pack where any, changed evidence base, changed source status, changed method status, changed compute status, changed model status, changed public-safe status, changed annex status, changed boundary language, continuing validity where any, discontinued reliance where any, reason for supersession, withdrawal, or retraction, affected dependencies, notice decision, and archive treatment.

9.30.14(g) Observatory Evidence Pack Register entries, interface logs, review records, correction records, supersession records, withdrawal records, retraction records, re-issue records, archive records, notices, assurance, renewal, and closeout shall not create certification, recognition, finance-readiness, public authority decision, regulatory finding, procurement approval, provider endorsement, sponsor approval, host approval, operator approval, community consent, rating, guarantee, public warning, emergency command, protocol effect, operational clearance, legal status, market authority, infrastructure operation, remediation approval, deployment approval, national authority, regional authority, public-facing maturity record, GRF maturity record, GRA finance-readiness, or execution consequence by default.

9.30.14(h) The controlling rule shall be that the Observatory Evidence Pack Register is the institutional memory of what evidence was packed, for what purpose, under what boundaries, shared with whom, corrected when, superseded how, withdrawn why, and no longer relied upon when.

***

9.30.15 Observatory Incident Register.\
9.30.15(a) GCRI Canada shall maintain, or cause to be maintained, an Observatory Incident Register for material suspected or confirmed incidents affecting Observatory data, cybersecurity, AI, sensors, AI-RAN, O-RAN, private wireless, DePIN, proof records, dashboards, maps, APIs, public-safe publications, public authority references, community safeguards, protected knowledge, provider interfaces, sponsor interfaces, host interfaces, operator interfaces, public claims, Nexus Universe activities, Grid inputs, Docket inputs, Rails inputs, Risk Management inputs, Academy inputs, correction systems, registers, or assurance systems.

9.30.15(b) The Observatory Incident Register shall identify incident title or identifier, incident taxonomy class, suspected or confirmed status, detection source, reporting source where safe, affected systems, affected data, affected evidence, affected outputs, affected dashboards, affected maps, affected APIs, affected Evidence Packs, affected Decision Packs, affected publications, affected interfaces, affected public claims, affected public authority context, affected community context, affected provider, sponsor, host, or operator context, affected jurisdiction, data classes, evidence classes, output classes, access class, handling class, public-safe status, privacy status, cybersecurity status, sovereign data status, infrastructure-sensitive status, public authority status, finance-sensitive status, procurement-sensitive status, community-protected status, Indigenous or protected knowledge status, legal sensitivity, export-control sensitivity, sanctions sensitivity, controlled-technology sensitivity, severity where used, confidence, uncertainty, containment status, notification status, correction status, residual risk, and closeout status.

9.30.15(c) Incident Register entries shall identify intake records, triage records, containment records, access changes, system restrictions, output restrictions, public-safe notices, controlled notices, public authority notices, community notices, provider notices, sponsor notices, host notices, operator notices, GRF notices, GRA notices, Protocol Authority notices, National Company notices, Project SPV notices, correction records, dependency notices, post-incident review records, learning-loop records, assurance records, training updates, method updates, technical-control updates, interface-agreement updates, Board or committee reporting where material, and archive treatment.

9.30.15(d) Incident severity shall be recorded according to harm, likelihood, sensitivity, affected data classes, affected evidence classes, affected output classes, affected actors, public authority implications, community implications, protected knowledge implications, privacy implications, cybersecurity implications, sovereign data implications, cross-border implications, finance implications, procurement implications, provider implications, sponsor implications, host implications, operator implications, public-safe implications, correction implications, and public trust implications.

9.30.15(e) Incident Register entries shall not be public by default. Public-safe incident summaries may be released only where they can be communicated without unsafe disclosure, public warning implication, regulatory overclaim, law enforcement overclaim, finance overclaim, procurement implication, provider preference, sponsor validation, host approval implication, operator instruction implication, protected knowledge exposure, privacy harm, cybersecurity harm, infrastructure exposure, or execution implication.

9.30.15(f) Incident Register entries, severity classifications, notices, corrections, post-incident reviews, and learning-loop records shall not create certification, recognition, finance-readiness, public authority decision, regulatory finding, procurement approval, funding approval, public finance approval, provider endorsement, sponsor finding, host finding, operator finding, community consent, Indigenous consent, rating, guarantee, public warning, emergency command, security certification, protocol effect, operational clearance, legal status, market authority, infrastructure operation, remediation approval, deployment approval, national authority, regional authority, GRF maturity record, GRA finance-readiness, or execution consequence by default.

9.30.15(g) Where incident records are corrected, reclassified, restricted, superseded, withdrawn, archived, or closed out, the Observatory Incident Register shall identify affected dependencies, notice decisions, corrected classifications, corrected outputs, corrected interface records, residual limitations, and continuing prohibited uses.

9.30.15(h) The controlling rule shall be that the Observatory Incident Register exists to preserve memory, containment, correction, accountability, and learning, not to create public warning, blame, regulatory authority, certification, finance, procurement, or execution.

***

9.30.16 Observatory Correction, Supersession, Withdrawal, Retraction, and Archive Register.\
9.30.16(a) GCRI Canada shall maintain, or cause to be maintained, an Observatory Correction, Supersession, Withdrawal, Retraction, and Archive Register for material changes to Observatory methods, data, evidence, outputs, dashboards, maps, APIs, Evidence Packs, Decision Packs, public-safe publications, public authority references, community safeguards, protected knowledge treatments, provider references, sponsor references, host references, operator references, incident records, Nexus Universe records, Grid inputs, Docket inputs, Rails inputs, Risk Management inputs, Academy inputs, and public claims.

9.30.16(b) The Register shall identify correction title or identifier, affected record, affected system, affected output, affected interface, affected actor reference, prior version, prior status, corrected status, correction type, supersession type, withdrawal type, retraction type, archive type, reason, source of correction, reviewer, effective date, data class, evidence class, output class, access class, handling class, public-safe status, confidence effect, uncertainty effect, limitation effect, public authority effect, public warning effect, finance-boundary effect, procurement-boundary effect, certification-boundary effect, recognition-boundary effect, protocol-boundary effect, provider-neutrality effect, sponsor non-control effect, host-boundary effect, operator-boundary effect, community safeguard effect, protected knowledge effect, privacy effect, cybersecurity effect, sovereign data effect, legal effect, notice decision, dependency treatment, archive location, and continuing limitations.

9.30.16(c) Correction entries shall identify the specific error, omission, misclassification, overclaim, unsafe disclosure, source-lineage defect, data-class defect, evidence-class defect, method defect, model defect, compute defect, dashboard defect, map defect, API defect, timestamp defect, version defect, confidence defect, uncertainty defect, limitation defect, public-safe defect, boundary-language defect, public authority confusion, public warning implication, finance overclaim, procurement implication, certification implication, recognition implication, protocol implication, provider preference, sponsor validation, host approval implication, operator instruction implication, community consent implication, protected knowledge exposure, privacy defect, cybersecurity defect, sovereign data issue, cross-border defect, legal defect, export-control issue, sanctions issue, controlled-technology issue, or correction failure being addressed.

9.30.16(d) Supersession entries shall identify replacement record, replacement output, replacement method, replacement Evidence Pack, replacement dashboard, replacement map, replacement API, replacement public-safe summary, changed evidence base, changed source status, changed data classification, changed method status, changed compute status, changed model status, changed public-safe status, changed boundary language, continuing validity where any, discontinued reliance where any, and affected dependency treatment.

9.30.16(e) Withdrawal entries shall identify materials no longer to be used or relied upon, withdrawal basis, affected audiences, affected interfaces, affected public-safe outputs, affected controlled annexes, affected restricted annexes, affected dashboards, affected maps, affected APIs, affected Evidence Packs, affected Decision Packs, affected public claims, access changes, notice decisions, archive treatment, and continuing prohibited uses.

9.30.16(f) Retraction entries shall identify materials materially unsupported, materially misleading, unsafe, unlawfully or improperly published, materially overclaimed, materially harmful, or incapable of correction without continued public-safe risk; the basis for retraction; affected dependencies; preservation obligations; notice treatment; archive treatment; and continuing reliance prohibitions.

9.30.16(g) Archive entries shall identify archived material, archive basis, archive date, archive location, archive class, access limits, public-safe status, privacy status, cybersecurity status, sovereign data status, protected knowledge status, public authority status, citation status, correction relationship, supersession relationship, withdrawal relationship, retraction relationship where any, legal hold where any, retention period, and closeout status.

9.30.16(h) The Register shall link correction, supersession, withdrawal, retraction, and archive entries, where applicable, to Observatory Methods Register entries, Node Register entries, Hub Register entries, Cluster Register entries, Hotspot Register entries, Regional Cluster Register entries, National Dense Core Evidence Register entries, Sensor Register entries, AI-RAN / O-RAN Evidence Register entries, DePIN Evidence Register entries, Geospatial and Mapping Register entries, Digital Twin and Simulation Register entries, Dashboard Register entries, Observatory Evidence Pack Register entries, Observatory Incident Register entries, Observatory data records, cybersecurity records, public authority interface records, community interface records, provider and sponsor interface records, Nexus Universe Observatory records, Grid interface records, Docket interface records, Rails interface records, Risk Management interface records, Academy interface records, GRF interface records, GRA interface records, Protocol Authority interface records, National Company records, Project SPV records, media materials, and public claims records.

9.30.16(i) Correction, supersession, withdrawal, retraction, archive, notice, dependency, and closeout records shall not create certification, recognition, finance-readiness, public authority decision, regulatory finding, procurement approval, funding approval, public finance approval, provider endorsement, sponsor finding, host finding, operator finding, community consent, Indigenous consent, rating, guarantee, public warning, emergency command, protocol effect, professional certification, operational clearance, legal status, market authority, infrastructure operation, remediation approval, deployment approval, national authority, regional authority, GRF maturity record, GRA finance-readiness, Docket approval, Grid maturity record, Rails finance authority, Academy certification, or execution consequence by default.

9.30.16(j) The controlling rule shall be that the Observatory correction and archive system is the proof of correctionability: every material Observatory record must be capable of being corrected, superseded, withdrawn, retracted, archived, linked, noticed, and no longer relied upon without converting correction into authority or silence into validity.

### 9.31 Observatory Assurance

9.31.1 Periodic Observatory Methods Assurance.\
9.31.1(a) GCRI Canada shall maintain periodic Observatory methods assurance as a structured, records-valid, source-lined, confidence-aware, uncertainty-aware, limitation-aware, public-safe, non-executing, and correctionable review discipline for determining whether Observatory methods remain fit for their recorded purpose, properly classified, properly bounded, properly versioned, properly safeguarded, properly reviewed, properly corrected, and properly separated from authority, finance, procurement, certification, recognition, protocol effect, public warning, emergency command, and execution.

9.31.1(b) Periodic Observatory methods assurance shall apply to material methods for Nodes, Hubs, Clusters, Hotspots, Regional Observatory Clusters, National Dense Nexus Cores, sensors, AI-RAN, O-RAN, private wireless, DePIN, cyber telemetry, geospatial evidence, public-safe mapping, Earth observation, digital twins, simulations, dashboards, APIs, Evidence Packs, Decision Packs, data governance, cybersecurity, AI governance, public-safe publication, public authority interfaces, community safeguards, provider interfaces, sponsor interfaces, host interfaces, operator interfaces, maturity evidence, incident handling, correction, records, registers, Nexus Universe interfaces, Grid interfaces, Docket interfaces, Rails interfaces, Risk Management interfaces, Academy interfaces, and related Observatory domains.

9.31.1(c) Assurance review shall identify method title or identifier, method class, version, steward, custodian, purpose, scope, evidence classes, data classes, output classes, access classes, handling classes, public-safe status, use history, review history, correction history, supersession history, withdrawal history, retraction history where any, archive status, dependency links, unresolved risks, residual limitations, and renewal needs.

9.31.1(d) Assurance shall assess whether methods remain source-lined, reproducible where appropriate, reviewable, challengeable, correctionable, public-safe, privacy-protective, cybersecurity-controlled, sovereignty-compatible, community-safe, protected-knowledge-safe, provider-neutral, sponsor-independent, host-bounded, operator-bounded, public-authority-bounded, finance-safe, procurement-safe, certification-safe, recognition-safe, protocol-boundary-safe, and non-executing.

9.31.1(e) Assurance shall identify whether method language, dashboard language, map language, API documentation, Evidence Pack templates, public-safe publication templates, interface templates, training materials, public claims, or records practices have drifted toward authority, approval, certification, recognition, finance-readiness, procurement effect, provider preference, sponsor validation, host approval, operator instruction, public warning, emergency command, protocol effect, deployment approval, operational clearance, market signal, legal status, or execution.

9.31.1(f) Where methods are incomplete, stale, unsafe, unsupported, inconsistent, overclaimed, public-safe defective, privacy-defective, cybersecurity-defective, sovereign-data-defective, public-authority-confusing, community-safeguard-defective, protected-knowledge-defective, provider-preferential, sponsor-influenced, host-controlled, operator-confusing, finance-inflating, procurement-implying, certification-implying, recognition-implying, protocol-implying, or correction-defective, GCRI Canada shall require corrective action, method update, restriction, suspension, supersession, withdrawal, retraction where applicable, training update, technical-control update, interface update, or Board or committee reporting where material.

9.31.1(g) Periodic Observatory methods assurance shall not create certification, recognition, finance-readiness, public authority decision, regulatory finding, procurement approval, provider endorsement, sponsor approval, host approval, operator approval, community consent, rating, guarantee, public warning, emergency command, protocol effect, professional certification, operational clearance, legal status, market authority, infrastructure operation, remediation approval, deployment approval, national authority, regional authority, GRF maturity record, GRA finance-readiness, or execution consequence by default.

9.31.1(h) The controlling rule shall be that Observatory methods remain valid only while they remain bounded, reviewed, current, safeguarded, corrected, and incapable of being mistaken for authority or execution.

***

9.31.2 Node Evidence Assurance.\
9.31.2(a) GCRI Canada shall maintain Node evidence assurance methods for periodic or event-based review of material Observatory Node evidence, including Node source records, host context, site or safe-site treatment, sensor records, reference sensor records, AI-RAN records, O-RAN records, private wireless records, DePIN records, geospatial records, cyber telemetry records, digital twin records, compute records, dashboard records, map records, API records, public-safe summaries, Evidence Packs, Decision Packs, incident records, correction records, maturity evidence inputs, host readiness inputs, and closeout records.

9.31.2(b) Node evidence assurance shall assess whether Node evidence is properly sourced, current, classified, permissioned, calibrated where applicable, corroborated where appropriate, contradiction-aware, data-gap-aware, confidence-aware, uncertainty-aware, limitation-aware, public-safe, privacy-protective, cybersecurity-controlled, sovereign-data-compatible, community-safe, protected-knowledge-safe, provider-neutral, sponsor-independent, host-bounded, operator-bounded, public-authority-bounded, finance-safe, procurement-safe, non-certifying, non-recognizing, non-executing, and correctionable.

9.31.2(c) Node assurance records shall identify Node title or identifier, Node purpose, Node scope, host context, public authority context where any, community context where any, provider context where any, sponsor context where any, operator context where any, data classes, evidence classes, output classes, access class, handling class, public-safe status, source review, calibration review, data-quality review, cybersecurity review, public-safe review, boundary review, correction review, and assurance outcome.

9.31.2(d) Node evidence assurance shall review whether any Node output, dashboard, map, public-safe summary, Evidence Pack, maturity input, host readiness output, public authority material, provider-facing material, sponsor-facing material, host-facing material, operator-facing material, community-facing material, Academy material, media material, or public claim overstates Node status as certified, recognized, mature, finance-ready, procurement-ready, deployment-ready, public authority-approved, host-approved, provider-preferred, sponsor-approved, operationally cleared, safe, official, Nexus-compatible, protocol-effective, or execution-ready.

9.31.2(e) Assurance findings may require Node evidence correction, source downgrade, confidence downgrade, uncertainty revision, limitation revision, data reclassification, public-safe restriction, dashboard correction, map correction, API restriction, Evidence Pack correction, public authority reference correction, community safeguard update, provider reference correction, sponsor reference correction, host reference correction, operator reference correction, incident handling, supersession, withdrawal, retraction, archive, or renewal.

9.31.2(f) Where Node assurance identifies systemic weakness, GCRI Canada shall update Node methods, Sensor Register entries, AI-RAN / O-RAN Evidence Register entries, DePIN Evidence Register entries, Dashboard Register entries, Evidence Pack Register entries, Incident Register entries, correction records, training materials, interface agreements, and assurance plans as appropriate.

9.31.2(g) Node evidence assurance shall not create Node certification, host approval, provider approval, sponsor approval, operator approval, finance-readiness, procurement approval, public authority approval, public warning, emergency command, protocol effect, deployment approval, operational clearance, market authority, legal status, or execution consequence by default.

9.31.2(h) The controlling rule shall be that Node evidence assurance verifies the integrity of Node evidence and safeguards, not the approved status of the Node.

***

9.31.3 Sensor Evidence Assurance.\
9.31.3(a) GCRI Canada shall maintain sensor evidence assurance methods for periodic or event-based review of material sensor evidence used in Observatory systems, including sensors, reference sensors, community sensors, environmental sensors, infrastructure sensors, cyber-physical sensors, health-sensitive or human-proximate sensors, industrial sensors, utility sensors, port sensors, corridor sensors, remote community sensors, field sensors, sensor fusion records, calibration records, maintenance records, custody records, configuration records, firmware records, signal quality records, data quality records, incident records, and correction records.

9.31.3(b) Sensor evidence assurance shall assess whether sensor identity, custody, calibration, configuration, firmware, maintenance, timing, location or safe-location treatment, data quality, signal quality, reference comparison, source lineage, evidence class, data class, public-safe status, privacy status, cybersecurity status, sovereign data status, community safeguard status, protected knowledge status, public authority status, provider status, host status, operator status, confidence, uncertainty, limitations, and correction path remain adequate for the recorded purpose.

9.31.3(c) Sensor assurance records shall identify sensor title or identifier where safe, sensor class, source, custodian, host context, operator context where any, provider context where any, community context where any, public authority context where any, location or safe-location treatment, calibration status, data class, evidence class, output class, access class, handling class, public-safe status, assurance findings, corrective actions, and dependency links.

9.31.3(d) Assurance shall assess sensor failure, reference sensor failure, calibration drift, configuration defects, maintenance gaps, timing defects, location defects, spoof risk, tamper risk, replay risk, missing data, stale data, corrupted data, unsafe sensor placement, unsafe sensor exposure, public-safe defects, community sensor risks, health-sensitive risks, infrastructure-sensitive risks, provider influence, host influence, operator influence, and correction effectiveness.

9.31.3(e) Sensor evidence assurance shall review whether sensor outputs have been overclaimed as public warnings, emergency commands, regulatory findings, public authority decisions, sensor certifications, security certifications, procurement approvals, finance-readiness, provider endorsements, host approvals, operator approvals, protocol effects, deployment approvals, operational clearances, or execution instructions.

9.31.3(f) Assurance findings may require calibration update, maintenance update, configuration correction, firmware correction, sensor isolation, data quarantine, source downgrade, confidence downgrade, uncertainty revision, dashboard restriction, map restriction, API restriction, Evidence Pack correction, public-safe summary correction, incident handling, supersession, withdrawal, retraction, retirement, decommissioning, or archive.

9.31.3(g) Sensor evidence assurance shall not create sensor certification, device approval, provider endorsement, host approval, public authority approval, procurement approval, finance-readiness, operational clearance, public warning, emergency command, protocol effect, deployment approval, infrastructure operation, market authority, or execution consequence by default.

9.31.3(h) The controlling rule shall be that sensor assurance protects the evidentiary trustworthiness of measurement without converting measurement into authority, approval, warning, command, procurement, finance, or execution.

***

9.31.4 AI-RAN / O-RAN Evidence Assurance.\
9.31.4(a) GCRI Canada shall maintain AI-RAN / O-RAN evidence assurance methods for periodic or event-based review of material AI-RAN, O-RAN, private wireless, telecommunications-adjacent, edge intelligence, network telemetry, radio signal, spectrum-adjacent, networked sensing, and connectivity evidence used in Observatory systems.

9.31.4(b) AI-RAN / O-RAN evidence assurance shall assess whether network signal evidence, telemetry evidence, timing evidence, location or safe-location treatment, signal quality, calibration or signal-integrity status where applicable, metadata sensitivity, privacy status, cybersecurity status, infrastructure sensitivity, public authority sensitivity, sovereign data status, provider role, operator role, host role, source lineage, evidence class, data class, output class, access class, handling class, public-safe status, confidence, uncertainty, limitations, incident status, and correction path remain adequate for the recorded purpose.

9.31.4(c) Assurance records shall identify evidence title or identifier, network or signal class, telemetry class, affected Node, Hub, Cluster, Hotspot, Regional Observatory Cluster, National Dense Nexus Core where applicable, provider where any, operator where any, host where any, public authority context where any, community context where any, data classes, evidence classes, output classes, public-safe status, assurance findings, corrective actions, and dependency links.

9.31.4(d) Assurance shall review network signal failure, telemetry failure, connectivity loss, timing defects, location defects, interference, spoofing, cyber compromise, edge intelligence defects, AI-assisted network inference errors, metadata exposure, location exposure, degraded-mode defects, provider equipment defects, operator interface defects, host connectivity defects, dashboard defects, map defects, API defects, and correction effectiveness.

9.31.4(e) AI-RAN / O-RAN evidence assurance shall review whether network evidence has been overclaimed as telecommunications regulation, spectrum authorization, service assurance, public warning, emergency command, provider ranking, provider preference, procurement approval, finance-readiness, certification, recognition, public authority decision, protocol effect, operational clearance, deployment approval, infrastructure operation, market authority, legal status, or execution instruction.

9.31.4(f) Assurance findings may require source downgrade, telemetry restriction, edge system restriction, dashboard correction, map correction, API correction, confidence downgrade, uncertainty revision, public-safe restriction, provider notice, operator notice, host notice, incident handling, supersession, withdrawal, retraction, retirement, or archive.

9.31.4(g) AI-RAN / O-RAN evidence assurance shall not create telecommunications certification, provider endorsement, procurement approval, finance-readiness, public authority approval, protocol effect, operational clearance, deployment approval, service assurance, infrastructure operation, public warning, emergency command, market authority, legal status, or execution consequence by default.

9.31.4(h) The controlling rule shall be that AI-RAN and O-RAN assurance protects network evidence integrity without making GCRI Canada a network operator, regulator, certifier, procurement actor, finance actor, or emergency commander.

***

9.31.5 DePIN Evidence Assurance.\
9.31.5(a) GCRI Canada shall maintain DePIN evidence assurance methods for periodic or event-based review of material distributed infrastructure evidence, device evidence, proof evidence, proof receipt evidence, ledger-adjacent evidence, availability evidence, coverage evidence, capacity evidence, service evidence, mission-specific proof evidence, tamper evidence, spoofing evidence, fraud-risk evidence, incentive-risk evidence, and correction records used in Observatory systems.

9.31.5(b) DePIN evidence assurance shall assess whether device identity, hardware identity where material, proof method, proof source, proof timing, proof integrity, proof reproducibility where appropriate, ledger relationship, token relationship where any, anchoring, hashing, signing, timestamping, custody, location or safe-location treatment, privacy status, cybersecurity status, infrastructure sensitivity, community safeguard status, public authority sensitivity, provider role, host role, operator role, evidence class, data class, output class, public-safe status, confidence, uncertainty, limitations, incident status, and correction path remain adequate for the recorded purpose.

9.31.5(c) DePIN assurance records shall identify evidence title or identifier, proof class, device or proof identity where safe, ledger relationship where any, token relationship where any, provider where any, host where any, operator where any, community context where any, public authority context where any, data classes, evidence classes, output classes, public-safe status, assurance findings, corrective actions, and dependency links.

9.31.5(d) Assurance shall review device identity defects, hardware identity defects, location claim defects, uptime claim defects, availability claim defects, capacity claim defects, coverage claim defects, service claim defects, proof-of-competence defects, proof-of-coverage defects, proof-of-availability defects, proof-of-integrity defects, proof-of-observation defects, mission-specific proof defects, proof receipt defects, ledger anchoring defects, token-related overclaims, tamper risk, spoof risk, fraud risk, incentive manipulation, privacy defects, location exposure, community exposure, public authority confusion, provider overclaim, sponsor overclaim, host overclaim, and correction effectiveness.

9.31.5(e) DePIN evidence assurance shall review whether DePIN tokens, ledger entries, proof receipts, cryptographic anchors, hashes, signatures, timestamps, dashboards, maps, proof summaries, or public-safe claims have been overclaimed as authority, truth, certification, recognition, finance-readiness, procurement approval, public authority decision, public warning, provider preference, sponsor approval, host approval, operator instruction, protocol effect, market entitlement, deployment approval, legal status, or execution consequence.

9.31.5(f) Assurance findings may require proof correction, proof receipt revocation or correction, anchoring correction, device-source restriction, location treatment revision, confidence downgrade, uncertainty revision, dashboard correction, map correction, API correction, Evidence Pack correction, public-safe summary correction, incident handling, supersession, withdrawal, retraction, retirement, or archive.

9.31.5(g) DePIN evidence assurance shall not create token rights, market rights, public authority status, protocol effect, finance-readiness, procurement status, certification, recognition, provider ranking, sponsor validation, host approval, operational clearance, legal status, or execution consequence by default.

9.31.5(h) The controlling rule shall be that DePIN assurance verifies proof as evidence within recorded limits; it does not make proof into authority.

***

9.31.6 Geospatial and Public-Safe Mapping Assurance.\
9.31.6(a) GCRI Canada shall maintain geospatial and public-safe mapping assurance methods for periodic or event-based review of material geospatial evidence, Earth observation evidence, satellite data, remote sensing data, drone or aerial data where applicable, GIS layers, location data, environmental layers, public-safe maps, controlled maps, restricted maps, dashboard maps, API map layers, digital twin geospatial layers, public-safe visualizations, and mapping-related public claims used in Observatory systems.

9.31.6(b) Mapping assurance shall assess source lineage, license, spatial resolution, temporal resolution, projection or coordinate reference system where material, layer class, data class, evidence class, output class, access class, handling class, public-safe status, safe-location treatment, sensitive-site treatment, infrastructure-sensitive treatment, cyber-sensitive treatment, cultural-site treatment, community sensitivity, Indigenous or protected knowledge status, public authority status, finance sensitivity, confidence, uncertainty, limitations, map version, publication limits, and correction path.

9.31.6(c) Assurance shall review whether maps, layers, legends, labels, markers, heatmaps, boundaries, risk displays, readiness displays, maturity-like displays, confidence displays, uncertainty displays, public-safe summaries, API fields, exports, screenshots, and embedded views create false precision, unsafe geospatial precision, re-identification risk, group harm risk, protected knowledge exposure, sensitive-site exposure, infrastructure exposure, public authority implication, public warning implication, finance implication, procurement implication, provider preference, sponsor validation, host approval implication, operator instruction implication, community stigma, or correction defects.

9.31.6(d) Geospatial assurance records shall identify map or layer title or identifier, review scope, source review, public-safe mapping review, re-identification review, group harm review, sensitive-site review, community review where required, public authority review where required, data classification review, cybersecurity review, public-safe publication review, correction review, findings, corrective actions, and dependency links.

9.31.6(e) Assurance findings may require aggregation, generalization, masking, redaction, omission, safe-location treatment, delayed release, controlled annexing, restricted annexing, access restriction, no-download treatment, API restriction, screenshot restriction, responsible non-disclosure, map correction, dashboard correction, public-safe summary correction, withdrawal, retraction, supersession, archive, or no-publication treatment.

9.31.6(f) Geospatial and mapping assurance shall not create official map status, public warning status, public authority decision, regulatory determination, procurement effect, finance-readiness, certification, recognition, provider preference, sponsor approval, host approval, operator instruction, protocol effect, deployment approval, operational clearance, legal status, market authority, or execution consequence by default.

9.31.6(g) Where mapping assurance identifies systemic mapping risk, GCRI Canada shall update mapping methods, Dashboard Register entries, Geospatial and Mapping Register entries, Evidence Pack templates, public-safe publication methods, community safeguard methods, public authority reference methods, training, and assurance cycles.

9.31.6(h) The controlling rule shall be that map assurance must test what a map can reveal, imply, enable, or invite others to misuse, not merely whether the map is technically correct.

***

9.31.7 Digital Twin and Simulation Assurance.\
9.31.7(a) GCRI Canada shall maintain digital twin and simulation assurance methods for periodic or event-based review of material digital twins, simulations, scenario engines, model-based evidence systems, infrastructure continuity models, degraded-mode models, public-safe visualizations, Nexus Universe simulations, Academy simulations, Risk Management scenarios, and simulation-derived Observatory outputs.

9.31.7(b) Digital twin and simulation assurance shall assess source inputs, assumptions, calibration, validation, sensitivity treatment, boundary conditions, model identity, model version, dataset identity, compute workload, compute environment, scenario class, public-safe status, public authority status, community safeguard status, protected knowledge status, infrastructure sensitivity, cyber sensitivity, finance sensitivity, confidence, uncertainty, limitations, false-precision controls, stale assumption controls, and correction path.

9.31.7(c) Assurance shall review whether simulation outputs, scenario outputs, model-based evidence, digital twin displays, dashboards, maps, public-safe exhibits, technical notes, Academy materials, public authority learning materials, capital-reader materials, provider materials, sponsor materials, host materials, operator materials, or public claims are overread as real-world readiness, public authority decision, public warning, emergency command, finance-readiness, procurement approval, certification, recognition, provider superiority, sponsor validation, host approval, operator readiness, community consent, protocol effect, operational clearance, deployment approval, or execution capability.

9.31.7(d) Digital twin and simulation assurance records shall identify system title or identifier, review scope, source review, assumption review, calibration review, validation review, sensitivity review, model review, dataset review, compute review, public-safe review, public authority boundary review, community safeguard review, protected knowledge review, finance-boundary review, procurement-boundary review, provider-neutrality review, sponsor non-control review, host-boundary review, operator-boundary review, correction review, findings, corrective actions, and dependency links.

9.31.7(e) Assurance findings may require scenario relabeling, assumption revision, confidence downgrade, uncertainty revision, limitation update, public-safe restriction, dashboard correction, map correction, API correction, digital twin layer restriction, Evidence Pack correction, Academy material correction, Risk Management material correction, Nexus Universe material correction, incident handling, supersession, withdrawal, retraction, retirement, or archive.

9.31.7(f) Digital twin and simulation assurance shall not create model certification, simulation validation for execution, public authority adoption, public warning, emergency command, finance-readiness, procurement approval, provider endorsement, sponsor approval, host approval, operator approval, protocol effect, operational clearance, deployment approval, legal status, market authority, or execution consequence by default.

9.31.7(g) Where assurance identifies systemic digital twin or simulation risk, GCRI Canada shall update Digital Twin and Simulation Register entries, Model Cards, System Cards, Dataset Cards, Benchmark Cards, evaluation harnesses, compute records, public-safe methods, Academy materials, Risk Management methods, and training.

9.31.7(h) The controlling rule shall be that digital twin and simulation assurance protects against false precision, stale assumptions, and scenario overclaim, because simulated evidence must remain visibly simulated.

***

9.31.8 Dashboard Assurance.\
9.31.8(a) GCRI Canada shall maintain dashboard assurance methods for periodic or event-based review of material dashboards, maps embedded in dashboards, visualization systems, reports with dashboard functions, APIs with dashboard functions, public-safe display systems, controlled-room display systems, restricted display systems, Nexus Universe dashboards, Academy dashboards, Risk Management dashboards, Rails-facing dashboards, public authority dashboards, community dashboards, provider-facing dashboards, sponsor-facing dashboards, host-facing dashboards, and operator-facing dashboards.

9.31.8(b) Dashboard assurance shall assess purpose, audience, source records, data records, method records, dashboard logic, field meanings, indicator meanings, score meanings where any, color meanings, legend meanings, update status, timestamp, version, access class, handling class, public-safe status, controlled status, restricted status, confidence display, uncertainty display, limitation display, export controls, screenshot controls, API links, stale-data treatment, boundary language, misuse detection, correction path, and archive status.

9.31.8(c) Assurance shall review whether dashboard labels, badges, colors, alerts, status indicators, risk displays, readiness-like labels, maturity-like labels, finance-like indicators, procurement-like categories, provider comparisons, sponsor references, host references, operator references, public authority references, community references, drill-down features, exports, screenshots, embedded views, API outputs, or public claims imply prohibited authority, public warning, emergency command, certification, recognition, finance-readiness, procurement effect, provider preference, sponsor validation, host approval, operator instruction, protocol effect, deployment approval, operational clearance, market signal, legal status, or execution.

9.31.8(d) Dashboard assurance records shall identify dashboard title or identifier, review scope, data review, method review, access review, public-safe review, visualization review, update-status review, confidence review, uncertainty review, limitation review, export review, screenshot-risk review, API review, public authority review, community safeguard review, provider reference review, sponsor reference review, host reference review, operator reference review, finance-boundary review, procurement-boundary review, correction review, findings, corrective actions, and dependency links.

9.31.8(e) Assurance findings may require dashboard relabeling, legend revision, color revision, score explanation revision, access restriction, export restriction, screenshot restriction, API restriction, stale-data marking, confidence revision, uncertainty revision, limitation revision, public-safe summary correction, provider reference correction, sponsor reference correction, host reference correction, public authority reference correction, withdrawal, retraction, supersession, archive, or misuse-response action.

9.31.8(f) Dashboard assurance shall not create dashboard approval, public authority dashboard status, public warning status, finance-readiness, procurement approval, rating, guarantee, certification, recognition, provider endorsement, sponsor approval, host approval, operator instruction, protocol effect, operational clearance, deployment approval, legal status, market authority, or execution consequence by default.

9.31.8(g) Where dashboard assurance identifies systemic dashboard risk, GCRI Canada shall update Dashboard Register entries, public-safe publication methods, visualization templates, API methods, Evidence Pack templates, interface records, training, and assurance cycles.

9.31.8(h) The controlling rule shall be that dashboard assurance must test not only the data behind the display, but the public meaning the display creates.

***

9.31.9 Data Governance, Privacy, Sovereign Data, and Compute-to-Data Assurance.\
9.31.9(a) GCRI Canada shall maintain data governance, privacy, sovereign data, cross-border, localization, data residency, compute-to-data, secure enclave, confidential computing, air-gapped environment, no-download room, retention, deletion, sealing, archival, legal hold, AI-use, retrieval, embedding, and data protection impact assurance for Observatory systems.

9.31.9(b) Assurance shall assess whether Observatory data are properly classified, lawfully sourced, permissioned, purpose-bound, minimized, proportionate, access-controlled, logged, time-limited where appropriate, retained appropriately, deleted where required, sealed where appropriate, archived appropriately, subject to legal hold only where justified, cross-border-reviewed, sovereignty-reviewed, compute-to-data-reviewed, AI-use-reviewed, public-safe-reviewed, and correctionable.

9.31.9(c) Assurance shall review personal data, public authority data, health-sensitive data, cyber-sensitive data, infrastructure-sensitive data, finance-sensitive data, commercially sensitive data, community-protected data, Indigenous data where applicable, local data, territorial data, environmental data, protected knowledge data, legal-sensitive data, export-control-sensitive data, sanctions-sensitive data, controlled-technology data, derived data, aggregated data, summarized data, modeled data, embedded data, visualized data, and translated data.

9.31.9(d) Data governance assurance records shall identify review scope, datasets reviewed, data flows reviewed, rooms reviewed, compute environments reviewed, cross-border transfers reviewed, AI uses reviewed, retrieval sources reviewed, embedding stores reviewed, dashboards reviewed, maps reviewed, APIs reviewed, publication channels reviewed, public authority interfaces reviewed, community interfaces reviewed, provider interfaces reviewed, sponsor interfaces reviewed, host interfaces reviewed, operator interfaces reviewed, data protection impact review status, findings, corrective actions, residual risk, and dependency links.

9.31.9(e) Assurance findings may require reclassification, use restriction, access revocation, field suppression, redaction, aggregation, generalization, safe-location treatment, cross-border restriction, sovereign compute treatment, compute-to-data treatment, secure enclave treatment, AI-use suspension, retrieval suspension, embedding store restriction, deletion, sealing, archive, public-safe output correction, Evidence Pack correction, dashboard correction, map correction, API correction, notice, incident handling, or interface update.

9.31.9(f) Assurance shall review whether data governance records or impact reviews have been overread as privacy certification, cybersecurity certification, legal compliance determination, public authority approval, procurement approval, finance-readiness, provider endorsement, sponsor approval, host approval, operator approval, protocol effect, operational clearance, deployment approval, market authority, or execution consequence.

9.31.9(g) Data governance, privacy, sovereign data, and compute-to-data assurance shall not create legal advice, legal compliance determination, privacy certification, security certification, public authority decision, procurement approval, finance-readiness, certification, recognition, provider endorsement, sponsor approval, host approval, operational clearance, deployment approval, or execution consequence by default.

9.31.9(h) The controlling rule shall be that data governance assurance proves that data remain bounded by authority, purpose, sensitivity, sovereignty, minimization, access, retention, AI-use limits, and correction- not that data are approved for all uses.

***

9.31.10 Cybersecurity Assurance.\
9.31.10(a) GCRI Canada shall maintain cybersecurity assurance methods for periodic or event-based review of Observatory cybersecurity baselines, identity and access management, segmentation, environment separation, least privilege, logging, monitoring, security telemetry, incident detection, vulnerability management, patch management, secure configuration, repository security, API security, dashboard security, sensor security, edge security, AI-RAN security, DePIN security, compute security, key management, token management, secrets management, credential controls, vendor security, provider security, host security, cloud security, incident response, recovery, notification, post-incident review, and closeout.

9.31.10(b) Cybersecurity assurance shall assess whether controls remain proportionate to data class, evidence class, output class, access class, handling class, public-safe status, privacy sensitivity, cybersecurity sensitivity, sovereign data status, infrastructure sensitivity, public authority restrictions, health sensitivity, finance sensitivity, commercial sensitivity, community safeguards, Indigenous or protected knowledge status, legal sensitivity, export-control sensitivity, sanctions sensitivity, controlled-technology sensitivity, interface risk, and correction dependency.

9.31.10(c) Cybersecurity assurance records shall identify systems reviewed, environments reviewed, repositories reviewed, APIs reviewed, dashboards reviewed, maps reviewed, sensors reviewed, AI-RAN components reviewed, DePIN components reviewed, compute workloads reviewed, compute environments reviewed, model systems reviewed, retrieval systems reviewed, embedding stores reviewed, data rooms reviewed, clean rooms reviewed, controlled rooms reviewed, no-download rooms reviewed, identities reviewed, access rights reviewed, keys reviewed, tokens reviewed, secrets reviewed, credentials reviewed, incidents reviewed, findings, corrective actions, residual risk, and dependency links.

9.31.10(d) Assurance shall review whether cybersecurity records, vendor attestations, provider materials, cloud assurances, penetration-test summaries, vulnerability summaries, patch records, incident records, proof receipts, or security dashboards have been overclaimed as security certification, provider endorsement, procurement approval, finance-readiness, public authority approval, protocol effect, operational clearance, deployment approval, service assurance, market superiority, public warning, emergency command, or execution consequence.

9.31.10(e) Assurance findings may require access revocation, credential rotation, key revocation, token revocation, secret rotation, segmentation update, environment separation, repository restriction, API restriction, dashboard restriction, sensor isolation, compute suspension, model suspension, retrieval restriction, embedding store restriction, vulnerability remediation, patching, secure configuration, vendor restriction, provider restriction, host restriction, cloud change, incident handling, public-safe output correction, Evidence Pack correction, training update, technical-control update, or Board or committee reporting where material.

9.31.10(f) Public-safe cybersecurity assurance summaries may be prepared only where they avoid exposing vulnerabilities, credentials, secrets, keys, tokens, cyber telemetry, incident details, infrastructure-sensitive information, protected knowledge, public authority restrictions, personal data, provider-sensitive information, host-sensitive information, operator-sensitive information, or other restricted information.

9.31.10(g) Cybersecurity assurance shall not create security certification, compliance determination, regulatory finding, public authority approval, procurement approval, finance-readiness, provider endorsement, sponsor approval, host approval, operator approval, operational clearance, remediation approval, protocol effect, public warning, emergency command, legal determination, or execution consequence by default.

9.31.10(h) The controlling rule shall be that cybersecurity assurance strengthens protection and correction, but it does not certify security, approve procurement, authorize operation, warn the public, command response, or execute remediation.

***

9.31.11 Public Authority Boundary Assurance.\
9.31.11(a) GCRI Canada shall maintain public authority boundary assurance methods for periodic or event-based review of Observatory interfaces, publications, dashboards, maps, APIs, Evidence Packs, Decision Packs, public-safe summaries, technical notes, public authority learning materials, controlled rooms, public authority rooms, data rooms, clean rooms, public authority data records, public authority reference records, capacity classifications, public authority review records, public authority access records, public authority correction records, and public claims involving public authorities.

9.31.11(b) Public authority boundary assurance shall assess whether public authority participation is properly classified, whether official and non-official status is recorded, whether public authority data use is authorized, whether agency references are permitted, whether logos and marks are approved, whether titles and quotes are properly bounded, whether dashboard access is properly controlled, whether public-safe review occurred where required, whether non-delegation language is preserved, and whether public warning, emergency command, regulatory, procurement, funding, public finance, public-law, or endorsement implications are prevented.

9.31.11(c) Assurance records shall identify public authority interface title or identifier, participating authority, capacity classification, materials reviewed, data contribution records reviewed, dashboard access records reviewed, reference approval records reviewed, publication records reviewed, public-safe outputs reviewed, review status, boundary language, correction status, findings, corrective actions, and dependency links.

9.31.11(d) Assurance shall review whether public authority attendance, comments, edits, silence, non-objection, data contribution, funding interest, procurement interest, public finance interest, regulator-listening participation, emergency-management participation, public health participation, public safety participation, dashboard access, map access, public-safe review, or public authority reference has been overread as endorsement, delegation, official guidance, regulatory determination, procurement approval, funding approval, public finance approval, public warning, emergency command, certification, recognition, finance-readiness, provider preference, sponsor approval, host approval, operator instruction, deployment approval, market authority, legal status, or execution consequence.

9.31.11(e) Assurance findings may require capacity reclassification, public authority reference removal, logo removal, quote correction, title correction, attendance correction, dashboard access restriction, map access restriction, public-safe summary correction, boundary-language revision, public-safe clarification, controlled notice, public authority notice, publication withdrawal, retraction, supersession, archive, interface agreement update, training update, or Board or committee reporting where material.

9.31.11(f) Public authority boundary assurance shall not create public authority approval, public authority decision, regulatory finding, compliance determination, enforcement position, public warning, emergency command, procurement approval, funding approval, public finance approval, certification, recognition, finance-readiness, provider endorsement, sponsor approval, host approval, operator approval, protocol effect, legal status, market authority, deployment approval, or execution consequence by default.

9.31.11(g) Where public authority ambiguity persists after assurance review, GCRI Canada shall adopt the narrower, safer, non-delegated, non-endorsement, non-official, non-procurement, non-funding, non-public-finance, non-public-warning, non-emergency-command, and correctionable interpretation unless express recorded clarification supports broader treatment.

9.31.11(h) The controlling rule shall be that public authority boundary assurance exists to keep public authority with public authorities and prevent evidence learning from being mistaken for public power.

***

9.31.12 Community Safeguards and Protected Knowledge Assurance.\
9.31.12(a) GCRI Canada shall maintain community safeguards and protected knowledge assurance methods for periodic or event-based review of Observatory community interfaces, Indigenous interfaces where applicable, local and territorial interfaces, protected knowledge controls, consent and non-consent treatment, withdrawal pathways, grievance pathways, remedy pathways, challenge pathways, community sensor methods, community data methods, public-safe mapping, community-facing outputs, protected knowledge treatment, translation, accessibility, localization, public authority routing, provider routing, sponsor routing, finance-facing routing, procurement-facing routing, Academy use, and public claims.

9.31.12(b) Assurance shall assess whether community participation has been non-extractive, whether knowledge has been context-preserved, whether consent and non-consent were respected where applicable, whether withdrawal and challenge pathways functioned, whether grievances were handled, whether remedies were recorded where applicable, whether public-safe maps avoided unsafe exposure, whether dashboards avoided community harm, whether protected persons, sensitive locations, cultural sites, sacred sites, infrastructure vulnerabilities, and protected knowledge remained protected, and whether public-safe outputs preserved dignity, context, language, accessibility, and correctionability.

9.31.12(c) Community safeguard assurance records shall identify interface title or identifier, community context where safe and appropriate, Indigenous context where applicable, local or territorial context, knowledge class, materials reviewed, safeguards reviewed, consent records reviewed, non-consent records reviewed, withdrawal records reviewed, grievance records reviewed, challenge records reviewed, correction records reviewed, public-safe maps reviewed, dashboards reviewed, public-safe outputs reviewed, findings, corrective actions, residual risk, and dependency links.

9.31.12(d) Assurance shall review whether community participation, Indigenous participation where applicable, community review, data contribution, map access, dashboard access, public-safe summary inclusion, public authority interface use, provider material use, sponsor material use, host material use, finance-facing use, procurement-facing use, or media use has been overread as community consent, Indigenous consent, community endorsement, Indigenous approval, host approval, public authority approval, finance-readiness, procurement support, certification, recognition, protocol effect, deployment approval, operational clearance, market authority, or execution permission.

9.31.12(e) Assurance findings may require safeguard updates, protocol updates, consent or non-consent record correction, withdrawal processing, grievance remedy, challenge review, translation update, accessibility update, map restriction, dashboard restriction, API restriction, protected knowledge sealing, data deletion where appropriate, retrieval restriction, embedding restriction, AI-use restriction, public-safe output correction, controlled notice, community notice where appropriate and safe, withdrawal, retraction, supersession, archive, training update, or Board or committee reporting where material.

9.31.12(f) Public-safe assurance summaries concerning community safeguards may be prepared only where they can be released without exposing protected persons, sensitive locations, cultural sites, protected knowledge, community grievances, confidential sources, infrastructure vulnerabilities, public authority restrictions, privacy-sensitive materials, cyber-sensitive materials, or other restricted information.

9.31.12(g) Community safeguards and protected knowledge assurance shall not create community certification, Indigenous approval, public authority approval, finance-readiness, procurement approval, provider endorsement, sponsor approval, host approval, operational clearance, deployment approval, protocol effect, legal status, market authority, public warning, emergency command, or execution consequence by default.

9.31.12(h) The controlling rule shall be that community safeguard assurance is successful only when evidence value never exceeds the duty to protect people, places, relationships, dignity, knowledge, and correction rights.

***

9.31.13 Provider Neutrality and Sponsor Non-Control Assurance.\
9.31.13(a) GCRI Canada shall maintain provider neutrality and sponsor non-control assurance methods for periodic or event-based review of Observatory provider, vendor, contractor, sponsor, host, operator, university, National Company, Project SPV, public authority, community, capital-reader, and other contributor interfaces where contribution, support, funding, equipment, data, software, compute, dashboards, maps, access, visibility, public claims, or influence may affect or appear to affect evidence integrity.

9.31.13(b) Provider neutrality assurance shall assess whether provider participation has been properly recorded, whether provider-supplied data, tools, equipment, AI, compute, sensors, dashboards, maps, APIs, demonstrations, benchmarks, validation conditions, staff time, and expertise are clearly classified, whether conflicts are disclosed and mitigated, whether provider access is limited, whether provider public claims are bounded, and whether provider participation has been prevented from becoming preferred status, procurement advantage, certification, recognition, finance-readiness, public authority endorsement, protocol effect, market entitlement, deployment approval, operational clearance, or execution consequence.

9.31.13(c) Sponsor non-control assurance shall assess whether sponsor support has remained support-without-control, whether sponsor funding, convening, facilities, technology access, publication support, public authority access, provider introductions, host relationships, community interfaces, capital-reader visibility, and public claims have been bounded, whether sponsor conflicts are disclosed and mitigated, and whether sponsors have been prevented from controlling evidence, sources, methods, reviewers, confidence, uncertainty, public-safe classification, dashboards, maps, Evidence Packs, Decision Packs, GRF inputs, GRA inputs, Protocol Authority inputs, public authority materials, community materials, provider materials, host materials, correction outcomes, publication decisions, or execution decisions.

9.31.13(d) Host and operator boundary assurance shall assess whether host or operator participation has remained bounded, whether site access, facility access, data contribution, sensor hosting, compute hosting, connectivity support, staff time, local context, operator context, dashboard access, map access, and public claims have been prevented from creating host approval, operator approval, community consent, public authority approval, procurement approval, finance-readiness, provider preference, sponsor validation, certification, recognition, protocol effect, deployment approval, operational clearance, infrastructure operation, or execution consequence by default.

9.31.13(e) Assurance records shall identify actors reviewed, contributions reviewed, support terms reviewed, interface agreements reviewed, conflict records reviewed, public acknowledgement records reviewed, public claims reviewed, access records reviewed, data records reviewed, IP records reviewed, security records reviewed, closeout records reviewed, findings, corrective actions, residual risk, and dependency links.

9.31.13(f) Assurance findings may require conflict disclosure, access limitation, reviewer independence, recusal, independent technical review, acknowledgement revision, logo removal, quote removal, case study revision, public claim correction, provider reference correction, sponsor reference correction, host reference correction, operator reference correction, support restriction, support termination, interface suspension, public-safe clarification, controlled notice, legal notice, training update, interface agreement update, or Board or committee reporting where material.

9.31.13(g) Provider neutrality and sponsor non-control assurance shall not create provider endorsement, sponsor approval, host approval, operator approval, procurement approval, finance-readiness, certification, recognition, public authority approval, protocol effect, deployment approval, operational clearance, market authority, legal status, public warning, emergency command, or execution consequence by default.

9.31.13(h) The controlling rule shall be that support may strengthen the Observatory only when assurance confirms that support has not become preference, control, market advantage, finance, procurement, authority, certification, recognition, protocol effect, or execution.

***

9.31.14 Public-Safe Publication Assurance.\
9.31.14(a) GCRI Canada shall maintain public-safe publication assurance methods for periodic or event-based review of Observatory public-safe summaries, maps, dashboards, reports, APIs, datasets, technical notes, visualizations, Evidence Packs, Decision Packs, Academy materials, public authority learning materials, community-facing materials, provider-facing materials, sponsor-facing materials, host-facing materials, operator-facing materials, GRF-facing materials, GRA-facing materials, Protocol Authority-facing materials, Nexus Risk Management materials, Nexus Rails materials, public-good software publications, media materials, repository materials, website materials, correction notices, supersession notices, withdrawal notices, retraction notices, clarification notices, archive records, and public claims.

9.31.14(b) Public-safe publication assurance shall assess whether outputs preserve source lineage, lawful basis, data classification, public-safe status, update status, timestamp, version, confidence, uncertainty, limitations, public-safe omissions, responsible non-disclosure, boundary language, access limits, permitted use, prohibited use, correction path, supersession path, withdrawal path, retraction path where applicable, archive status, and misuse monitoring.

9.31.14(c) Assurance shall review whether public-safe outputs disclose or enable inference of personal data, public authority restricted data, health-sensitive data, cyber-sensitive data, infrastructure-sensitive data, finance-sensitive data, commercially sensitive data, community-protected data, Indigenous data where applicable, local data, territorial data, environmental data, protected knowledge data, credentials, secrets, keys, tokens, sensitive sites, precise locations, vulnerability details, or other restricted or harm-enabling information.

9.31.14(d) Assurance shall review whether public-safe outputs imply public warning, emergency command, public authority decision, regulatory determination, compliance determination, procurement approval, funding approval, public finance approval, finance-readiness, investment advice, insurance approval, lending decision, underwriting decision, rating, guarantee, certification, recognition, maturity record, claims approval, standing, registry status, protocol effect, conformance determination, Nexus-compatible status, provider endorsement, sponsor approval, host approval, operator instruction, operational clearance, deployment approval, infrastructure operation, market authority, legal status, professional advice, or execution consequence.

9.31.14(e) Assurance records shall identify publication title or identifier, review scope, source review, data classification review, lawful basis review, privacy review, cybersecurity review, sovereign data review, public authority review, public warning review, community safeguard review, protected knowledge review, finance-boundary review, procurement-boundary review, certification-boundary review, recognition-boundary review, protocol-boundary review, provider-neutrality review, sponsor non-control review, host-boundary review, operator-boundary review, accessibility review, translation review where applicable, correction review, misuse review, findings, corrective actions, and dependency links.

9.31.14(f) Assurance findings may require publication correction, boundary language revision, title revision, caption revision, legend revision, metadata revision, timestamp revision, version correction, confidence revision, uncertainty revision, limitation revision, map generalization, dashboard restriction, API restriction, dataset suppression, report correction, technical note correction, public authority reference correction, provider reference correction, sponsor reference correction, host reference correction, operator reference correction, community reference correction, public-safe clarification, controlled notice, withdrawal, retraction, supersession, archive, or misuse-response action.

9.31.14(g) Public-safe publication assurance shall not create certification, recognition, finance-readiness, public authority decision, regulatory finding, procurement approval, funding approval, public finance approval, provider endorsement, sponsor approval, host approval, operator approval, community consent, Indigenous consent, rating, guarantee, public warning, emergency command, protocol effect, operational clearance, legal status, market authority, infrastructure operation, remediation approval, deployment approval, professional certification, or execution consequence by default.

9.31.14(h) The controlling rule shall be that public-safe publication assurance must test what the public can see, infer, reuse, misquote, screenshot, copy, translate, market, finance, procure, or mistake for authority.

***

9.31.15 Assurance Findings, Corrective Action Plans, Training Updates, Method Updates, and Board Reporting.\
9.31.15(a) GCRI Canada shall maintain assurance finding, corrective action plan, training update, method update, technical-control update, interface update, notice, dependency review, Board or committee reporting, renewal, archive, and closeout methods for material Observatory assurance activities.

9.31.15(b) Assurance findings shall identify review title or identifier, assurance domain, scope, reviewers, materials reviewed, systems reviewed, interfaces reviewed, evidence reviewed, data classes, evidence classes, output classes, access classes, handling classes, public-safe status, issues identified, severity where used, confidence, uncertainty, limitations, affected records, affected outputs, affected interfaces, affected actors where safe and material, affected dependencies, recommended corrective actions, required corrective actions, residual risk, notice decision, escalation decision, and closeout requirements.

9.31.15(c) Corrective action plans shall identify responsible steward, action required, method update required, technical-control update required, data correction required, source correction required, dashboard correction required, map correction required, API correction required, Evidence Pack correction required, publication correction required, public authority reference correction required, community safeguard correction required, protected knowledge correction required, provider reference correction required, sponsor reference correction required, host reference correction required, operator reference correction required, access change required, incident handling required, timeline where appropriate, dependency treatment, verification method, and closeout status.

9.31.15(d) Training updates shall be required where assurance identifies repeated misunderstanding, boundary drift, public-safe errors, data governance errors, cybersecurity errors, AI-use errors, source-lineage errors, dashboard misuse, map misuse, API misuse, public authority reference errors, community safeguard failures, provider-neutrality failures, sponsor non-control failures, host-boundary failures, operator-boundary failures, finance-boundary failures, procurement-boundary failures, certification-boundary failures, recognition-boundary failures, protocol-boundary failures, correction failures, or public claims misuse.

9.31.15(e) Method updates shall be required where assurance identifies method gaps, inconsistent method use, stale methods, unsupported methods, inadequate confidence treatment, inadequate uncertainty treatment, inadequate limitation treatment, inadequate public-safe treatment, inadequate correction path, inadequate interface control, inadequate records discipline, inadequate assurance cadence, or repeated incidents.

9.31.15(f) Board or committee reporting shall be required where assurance findings involve material risk to evidence integrity, public-safe publication, privacy, cybersecurity, sovereign data, public authority boundaries, community safeguards, protected knowledge, provider neutrality, sponsor non-control, host boundaries, operator boundaries, finance boundaries, procurement boundaries, certification boundaries, recognition boundaries, protocol boundaries, legal obligations, institutional trust, correctionability, or GCRI Canada’s non-execution role.

9.31.15(g) Assurance reports, corrective action plans, Board reports, committee reports, training updates, method updates, technical-control updates, notices, and closeout records shall preserve confidentiality, public-safe discipline, protected knowledge, public authority restrictions, privacy, cybersecurity, sovereign data, provider-sensitive information, sponsor-sensitive information, host-sensitive information, operator-sensitive information, legal sensitivity, export-control sensitivity, sanctions sensitivity, controlled-technology sensitivity, and correction paths.

9.31.15(h) Public-safe assurance summaries may be prepared where they can be released without unsafe disclosure, public authority confusion, public warning implication, finance overclaim, procurement implication, certification implication, recognition implication, protocol implication, provider preference, sponsor validation, host approval implication, operator instruction implication, community harm, protected knowledge exposure, privacy harm, cybersecurity harm, sovereign data harm, legal breach, or execution implication.

9.31.15(i) Assurance findings, corrective action plans, training updates, method updates, technical-control updates, Board or committee reports, notices, renewal records, archive records, and closeout records shall not create certification, recognition, finance-readiness, public authority decision, regulatory finding, procurement approval, funding approval, public finance approval, provider endorsement, sponsor approval, host approval, operator approval, community consent, Indigenous consent, rating, guarantee, public warning, emergency command, protocol effect, professional certification, operational clearance, legal status, market authority, infrastructure operation, remediation approval, deployment approval, national authority, regional authority, GRF maturity record, GRA finance-readiness, Docket approval, Grid maturity record, Rails finance authority, Academy certification, or execution consequence by default.

9.31.15(j) The controlling rule shall be that Observatory assurance is meaningful only when findings lead to correction, methods improve, people are retrained, controls are updated, records are fixed, material risks reach the Board or committee level, and no assurance artifact is mistaken for certification, approval, finance, procurement, authority, or execution.

### 9.32 Part IX Closing Integration Clause

9.32.1 Part IX shall govern the Observatory methods, sovereign compute, AI-RAN / O-RAN / DePIN evidence, sensors, nodes, clusters, and digital twin reading of all later Parts.\
9.32.1(a) This Part IX shall govern the interpretation, application, implementation, record treatment, public-safe treatment, interface treatment, assurance treatment, and correction treatment of all later Parts of this Charter to the extent that any later Part refers to, depends upon, incorporates, receives, routes, publishes, displays, summarizes, audits, assures, corrects, or otherwise uses Observatory methods or Observatory-related evidence stewarded by GCRI Canada.

9.32.1(b) For purposes of this Section, Observatory-related evidence and methods include Node methods, Hub methods, Cluster methods, Hotspot methods, Regional Observatory Cluster methods, National Dense Nexus Core methods, sovereign compute methods, compute-to-data methods, secure enclave methods, confidential computing methods, air-gapped methods, sensor methods, reference sensor methods, community sensor methods, AI-RAN methods, O-RAN methods, private wireless methods, DePIN methods, proof methods, geospatial methods, Earth observation methods, cyber-physical telemetry methods, digital twin methods, simulation methods, dashboard methods, visualization methods, degraded-mode methods, host readiness methods, maturity evidence inputs, Evidence Packs, Decision Packs, public-safe summaries, controlled annexes, restricted annexes, public authority interface methods, community safeguard methods, provider and sponsor interface methods, host interface methods, operator interface methods, data governance methods, cybersecurity methods, public-safe publication methods, incident handling methods, records and registers, and assurance methods.

9.32.1(c) All later Parts shall be read subject to the Observatory constitutional architecture established in this Part IX, including the requirements of source lineage, classification, lawful basis or recorded authority, purpose limitation, data minimization, access control, public-safe review, confidence treatment, uncertainty treatment, limitation treatment, cybersecurity control, privacy protection, sovereign data control, public authority boundary control, community safeguard control, protected knowledge control, provider neutrality, sponsor non-control, host boundary, operator boundary, interface records, correction records, supersession discipline, withdrawal discipline, retraction discipline, archive discipline, and assurance review.

9.32.1(d) The later use of Observatory evidence in public authority learning, community learning, provider-neutral technical review, sponsor-supported programs, host readiness work, Nexus Universe activities, Nexus Grid inputs, Nexus Docket inputs, Nexus Rails inputs, Nexus Risk Management inputs, Nexus Academy materials, GRF inputs, GRA inputs, Protocol Authority inputs, National Nexus Consortium materials, Regional Nexus Consortium materials, National Company materials, Project SPV materials, public-good software, technical baselines, dashboards, maps, APIs, public-safe publications, or public claims shall remain governed by the limitations, records discipline, safeguards, boundary language, and correction duties of this Part IX.

9.32.1(e) No later Part shall be read to dilute the role of GCRI Canada as a non-share, non-distributing, non-executing, public-benefit, evidence, methods, observability, ontology, public-good R\&D, public-good software, open technical baseline, public authority learning, public-safe publication, validity-by-record, and correctionability institution within the wider Nexus architecture.

9.32.1(f) No later Part shall be read to merge GCRI Canada’s Observatory methods role with the role of GCRI US, The Global Risks Forum (GRF), The Global Risks Alliance (GRA), Nexus Standards / Protocol Authority, Nexus entities, Regional Nexus Consortiums, National Nexus Consortiums, National Companies, Project SPVs, public authorities, regulators, public finance bodies, operators, providers, sponsors, hosts, universities, communities, Indigenous governance bodies where applicable, capital readers, insurers, lenders, investors, procurement actors, certification bodies, or execution vehicles.

9.32.1(g) Where a later Part uses Observatory concepts for a new domain, technology, geography, institution, interface, publication, public authority learning pathway, community safeguard pathway, finance-safe pathway, procurement-safe pathway, training pathway, assurance pathway, or implementation pathway, the later Part shall be read as incorporating the same non-execution, evidence integrity, public-safe publication, privacy, cybersecurity, sovereign data, protected knowledge, role separation, and correctionability controls unless it expressly imposes a stricter rule.

9.32.1(h) The controlling rule shall be that Part IX supplies the Observatory interpretive grammar for all later Parts: later provisions may extend Observatory evidence use, but they shall not release Observatory evidence from its methods, safeguards, records, boundaries, or correction path.

***

9.32.2 No later Part shall be interpreted to convert GCRI Canada’s Observatory methods, node methods, cluster methods, sensor methods, AI-RAN / O-RAN methods, DePIN methods, sovereign compute methods, digital twin methods, dashboards, maps, evidence packs, public-safe outputs, or technical baselines into infrastructure ownership, infrastructure operation, emergency command, official public warning, public authority action, procurement approval, provider preference, certification, finance-readiness, rating, guarantee, protocol effect, or execution consequence by implication.\
9.32.2(a) No later Part shall be interpreted to convert any GCRI Canada Observatory method, Observatory record, Observatory register, Observatory output, Observatory interface, Observatory assurance finding, Observatory correction, Observatory public-safe summary, Observatory dashboard, Observatory map, Observatory API, Observatory Evidence Pack, Observatory Decision Pack, Observatory technical note, Observatory training material, Observatory proof receipt, Observatory compute record, Observatory AI output, Observatory digital twin output, Observatory simulation output, Observatory data room, Observatory controlled room, Observatory clean room, Observatory no-download room, or Observatory publication into infrastructure ownership, infrastructure operation, service operation, telecommunications operation, network operation, compute operation, sensor operation, emergency-management operation, public warning operation, public authority action, market infrastructure, or execution platform by implication.

9.32.2(b) No later Part shall be interpreted to make GCRI Canada the owner, operator, maintainer, emergency commander, incident commander, public warning issuer, public infrastructure operator, telecommunications operator, cloud operator, managed security service provider, public authority, regulator, law enforcement body, public health authority, public safety authority, public finance authority, procurement authority, certification body, recognition body, rating agency, investment adviser, insurance adviser, lender, underwriter, Protocol Authority, provider, sponsor, host, National Company, Project SPV, or execution actor by reason of Observatory evidence, methods, records, interfaces, or publications.

9.32.2(c) No later Part shall be interpreted to convert Node status, Hub status, Cluster status, Hotspot status, Regional Observatory Cluster status, National Dense Core evidence status, sensor status, AI-RAN / O-RAN evidence status, DePIN proof status, geospatial status, digital twin status, dashboard status, Evidence Pack status, public-safe status, assurance status, incident status, correction status, supersession status, archive status, or register status into approved status, certified status, recognized status, finance-ready status, procurement-ready status, public authority-approved status, protocol-effective status, host-approved status, provider-preferred status, sponsor-approved status, operator-approved status, deployment-approved status, operationally cleared status, public-warning status, emergency-command status, market status, legal status, or execution-ready status by implication.

9.32.2(d) No later Part shall be interpreted to convert public authority participation, public authority attendance, public authority data contribution, public authority dashboard access, public authority map access, public authority review, regulator-listening status, public finance reader status, emergency-management participation, public health participation, public safety participation, or public infrastructure operator participation into endorsement, adoption, delegation, official guidance, regulatory determination, compliance determination, enforcement position, public warning, emergency command, procurement approval, funding approval, public finance approval, public-law status, certification, recognition, finance-readiness, provider preference, sponsor approval, host approval, operator instruction, deployment approval, legal status, market authority, or execution consequence.

9.32.2(e) No later Part shall be interpreted to convert provider contribution, vendor support, contractor support, sponsor support, host support, operator participation, university participation, community participation, Indigenous participation where applicable, National Company relevance, Project SPV relevance, GRF interface use, GRA interface use, Protocol Authority interface use, capital-reader participation, media visibility, Nexus Universe participation, Academy participation, Grid reference, Docket reference, Rails reference, or Risk Management reference into endorsement, approval, consent, certification, recognition, finance-readiness, procurement effect, protocol effect, provider preference, sponsor validation, host approval, operator instruction, professional certification, public authority meaning, deployment approval, operational clearance, market signal, or execution consequence.

9.32.2(f) No later Part shall be interpreted to convert technical baselines, open technical baselines, public-good software, dashboards, maps, digital twins, simulations, benchmarks, proof receipts, confidence scores, maturity evidence inputs, readiness evidence inputs, degraded-mode indicators, resilience indicators, public-safe summaries, or Observatory Evidence Packs into certifications, ratings, guarantees, finance-readiness determinations, insurance-readiness determinations, public finance approvals, procurement approvals, provider rankings, host rankings, operator rankings, safety determinations, security certifications, conformance determinations, Nexus-compatible status, Protocol Authority effects, or market entitlements by implication.

9.32.2(g) Any infrastructure ownership, infrastructure operation, public authority action, public warning, emergency command, finance decision, procurement decision, certification, recognition, Protocol Authority effect, National Company action, Project SPV action, provider action, host action, operator action, deployment decision, operational decision, or execution consequence shall arise only through the competent actor’s own authority, process, records, accountability, liability, and governing instruments, and not through GCRI Canada Observatory evidence by implication.

9.32.2(h) The controlling rule shall be that Observatory methods and outputs may support evidence, learning, records, public-safe explanation, assurance, and correction, but they shall not own, operate, warn, command, regulate, procure, finance, certify, recognize, rate, guarantee, endorse, confer protocol effect, or execute by implication.

***

9.32.3 No later Part shall be interpreted to permit Observatory data or outputs without source lineage, classification, confidence, uncertainty, privacy controls, cybersecurity controls, sovereign data controls, public authority controls, community safeguards, protected knowledge controls, public-safe review, and correction path where applicable.\
9.32.3(a) No later Part shall be interpreted to permit material Observatory data, Observatory evidence, Observatory outputs, Observatory dashboards, Observatory maps, Observatory APIs, Observatory datasets, Observatory reports, Observatory technical notes, Observatory Evidence Packs, Observatory Decision Packs, Observatory public-safe summaries, Observatory controlled annexes, Observatory restricted annexes, Observatory digital twin outputs, Observatory simulation outputs, Observatory AI outputs, Observatory proof receipts, Observatory compute records, Observatory public authority materials, Observatory community materials, Observatory provider materials, Observatory sponsor materials, Observatory host materials, Observatory operator materials, Observatory Academy materials, Observatory Grid inputs, Observatory Docket inputs, Observatory Rails inputs, Observatory Risk Management inputs, Observatory GRF inputs, Observatory GRA inputs, or Observatory Protocol Authority inputs without source lineage where applicable.

9.32.3(b) No later Part shall be interpreted to permit Observatory data or outputs without classification appropriate to their actual sensitivity, context, audience, source, inference risk, aggregation risk, authority risk, public-safe risk, privacy risk, cybersecurity risk, sovereign data risk, public authority status, health-sensitive status, infrastructure-sensitive status, finance-sensitive status, commercial sensitivity, community-protected status, Indigenous or protected knowledge status, legal sensitivity, export-control sensitivity, sanctions sensitivity, controlled-technology sensitivity, and correction dependency.

9.32.3(c) No later Part shall be interpreted to permit material Observatory outputs without confidence and uncertainty treatment proportionate to the source record, data quality, source independence, corroboration, calibration, timeliness, completeness, reproducibility where appropriate, review status, method reliability, compute integrity, model limitations, public authority context, community context, provider influence, sponsor influence, host context, operator context, contradiction status, stale-data status, public-safe omissions, and correction status.

9.32.3(d) No later Part shall be interpreted to permit Observatory data or outputs without limitation statements where material, including source limitations, data limitations, method limitations, model limitations, compute limitations, geospatial limitations, dashboard limitations, API limitations, public-safe omissions, restricted annex existence where appropriate, assumptions, excluded variables, missing evidence, stale evidence, contradiction, applicability limits, audience limits, downstream reuse limits, and correction limits.

9.32.3(e) No later Part shall be interpreted to permit Observatory data or outputs without privacy controls, cybersecurity controls, sovereign data controls, cross-border controls, compute-to-data controls where appropriate, secure enclave or controlled-room treatment where appropriate, data minimization, access controls, role-based access, logging, retention discipline, deletion discipline, sealing discipline, archival discipline, legal hold discipline, AI-use restrictions, retrieval controls, embedding controls, model governance, and data protection impact review where applicable.

9.32.3(f) No later Part shall be interpreted to permit Observatory data or outputs involving public authorities without capacity classification, data contribution records, dashboard access controls, reference approval where required, public authority review where required, non-delegation language, non-endorsement language, no-public-warning language, no-emergency-command language, no-regulatory-determination language, no-procurement language, no-funding language, no-public-finance language, no-certification language, no-recognition language, no-finance-readiness language, no-provider-endorsement language, no-sponsor-approval language, no-host-approval language, no-operator-instruction language, no-protocol-effect language unless separately created, no-execution language, and correction path.

9.32.3(g) No later Part shall be interpreted to permit Observatory data or outputs involving communities, Indigenous peoples or governance bodies where applicable, local knowledge, territorial knowledge, environmental knowledge, cultural sites, sensitive sites, sacred sites, protected sites, community sensors, community data, vulnerable communities, remote communities, rural communities, northern communities, Arctic communities, at-risk communities, or protected knowledge without non-extraction controls, consent or non-consent treatment where applicable, withdrawal pathways where applicable, grievance pathways where applicable, remedy pathways where applicable, challenge pathways where applicable, public-safe mapping controls, source protection, sensitive-site protection, protected knowledge safeguards, translation and accessibility review where applicable, community review where required, and correction path.

9.32.3(h) No later Part shall be interpreted to permit Observatory public-safe publication without update status, timestamp, version, confidence, uncertainty, limitations, public-safe omissions, boundary language, permitted-use limits, prohibited-use limits, public authority reference controls, provider reference controls, sponsor reference controls, host reference controls, operator reference controls, correction path, supersession path, withdrawal path, retraction path where applicable, archive path, and misuse monitoring proportionate to the output.

9.32.3(i) No later Part shall be interpreted to permit Observatory records, registers, incidents, corrections, assurance findings, public-safe summaries, controlled annexes, restricted annexes, or interface records to be relied upon after material correction, supersession, withdrawal, retraction, archive restriction, access restriction, or stale-status notice except in accordance with the corrected, superseded, withdrawn, retracted, archived, restricted, or stale-status record.

9.32.3(j) The controlling rule shall be that Observatory evidence without lineage, classification, confidence, uncertainty, safeguards, public-safe review, and correction path is not decision-grade, not publication-grade, not interface-grade, and not valid for material Nexus use.

***

9.32.4 Where ambiguity exists, the interpretation that better preserves Observatory evidence integrity, non-execution, public authority boundaries, public warning boundaries, finance-readiness boundaries, provider neutrality, sponsor non-control, public-safe publication, privacy, cybersecurity, sovereign data, protected knowledge, Nexus role separation, validity-by-record, correctionability, and public trust shall prevail.\
9.32.4(a) Where any ambiguity, conflict, omission, inconsistency, silence, drafting gap, implementation gap, interface gap, public-safe uncertainty, public authority uncertainty, finance-boundary uncertainty, procurement-boundary uncertainty, provider-boundary uncertainty, sponsor-boundary uncertainty, host-boundary uncertainty, operator-boundary uncertainty, community-safeguard uncertainty, protected-knowledge uncertainty, data-class uncertainty, source-lineage uncertainty, confidence uncertainty, cybersecurity uncertainty, sovereign data uncertainty, AI-use uncertainty, or correction uncertainty arises under this Part IX or any later Part, the interpretation that better preserves Observatory evidence integrity shall prevail.

9.32.4(b) The interpretation preserving non-execution shall prevail over any interpretation that would make GCRI Canada an infrastructure owner, infrastructure operator, emergency commander, public warning issuer, public authority actor, regulator, procurement actor, finance actor, certification body, recognition body, rating agency, Protocol Authority, provider, sponsor, host, operator, National Company, Project SPV, market actor, or execution actor by implication.

9.32.4(c) The interpretation preserving public authority boundaries and public warning boundaries shall prevail over any interpretation that would convert public authority participation, data contribution, review, dashboard access, map access, attendance, silence, non-objection, reference, funding interest, procurement interest, public finance interest, regulator-listening status, emergency-management participation, public health participation, public safety participation, or public infrastructure operator participation into public authority action, delegation, endorsement, official guidance, regulatory determination, public warning, emergency command, public finance approval, procurement approval, or public-law status.

9.32.4(d) The interpretation preserving finance-readiness boundaries and procurement neutrality shall prevail over any interpretation that would convert Observatory evidence, host readiness evidence, maturity evidence inputs, dashboards, maps, confidence scores, degraded-mode indicators, resilience indicators, Evidence Packs, Decision Packs, public-safe summaries, proof receipts, Nexus Rails inputs, GRA inputs, capital-reader materials, public finance reader materials, National Company materials, Project SPV materials, or public claims into finance-readiness, investment advice, insurance approval, lending approval, underwriting approval, public finance approval, rating, guarantee, bankability, fundability, procurement approval, provider selection, project approval, market signal, deployment approval, or execution instruction by GCRI Canada.

9.32.4(e) The interpretation preserving provider neutrality and sponsor non-control shall prevail over any interpretation that would convert provider participation into preferred status, procurement advantage, certification, recognition, finance-readiness, public authority endorsement, protocol effect, market entitlement, deployment approval, operational clearance, or execution consequence, or convert sponsor support into control of evidence, sources, methods, reviewers, confidence, uncertainty, public-safe classification, dashboards, maps, Evidence Packs, Decision Packs, public authority access, community access, provider selection, host selection, correction outcomes, publication decisions, recognition outcomes, finance outcomes, procurement outcomes, protocol outcomes, or execution outcomes.

9.32.4(f) The interpretation preserving host boundaries and operator boundaries shall prevail over any interpretation that would convert host support, site access, facility access, sensor hosting, compute hosting, connectivity support, data contribution, staff time, local context, operator context, dashboard access, map access, or public-safe mention into host certification, site approval, operator approval, public authority approval, community consent, procurement approval, finance-readiness, provider preference, sponsor validation, deployment approval, operational clearance, infrastructure operation, or execution consequence.

9.32.4(g) The interpretation preserving public-safe publication, privacy, cybersecurity, sovereign data, community safeguards, Indigenous safeguards where applicable, and protected knowledge shall prevail over any interpretation that would permit unsafe mapping, unsafe dashboarding, unsafe API exposure, unsafe publication, excessive collection, excessive retention, excessive sharing, excessive AI use, unauthorized retrieval, unauthorized embedding, unauthorized training, cross-border exposure, protected knowledge exposure, sensitive-site exposure, vulnerable-person exposure, infrastructure vulnerability exposure, cyber-sensitive exposure, community harm, re-identification risk, group harm, or correction failure.

9.32.4(h) The interpretation preserving Nexus role separation shall prevail over any interpretation that would collapse GCRI Canada into GCRI US, The Global Risks Forum (GRF), The Global Risks Alliance (GRA), Nexus Standards / Protocol Authority, Nexus Network, Nexus Universe, Nexus Risk Management, Nexus Rails, Nexus Grid, Nexus Academy, Regional Nexus Consortiums, National Nexus Consortiums, National Companies, Project SPVs, public authorities, providers, sponsors, hosts, operators, universities, communities, capital readers, insurers, lenders, investors, procurement actors, certification bodies, or execution vehicles.

9.32.4(i) The interpretation preserving validity-by-record shall prevail over any interpretation that would permit authority, status, publication, public-safe meaning, access, data use, public authority reference, community reference, provider reference, sponsor reference, host reference, operator reference, finance-facing use, procurement-facing use, protocol-facing use, or downstream reliance without records sufficient to identify source, authority, classification, version, confidence, uncertainty, limitations, public-safe status, permitted use, prohibited use, review status, correction path, and dependency treatment.

9.32.4(j) The interpretation preserving correctionability shall prevail over any interpretation that would make an Observatory method, output, dashboard, map, API, Evidence Pack, Decision Pack, public-safe summary, interface record, public authority reference, community safeguard record, provider reference, sponsor reference, host reference, operator reference, register entry, assurance finding, incident record, or public claim difficult to challenge, correct, supersede, withdraw, retract, archive, notice, or prevent from further reliance.

9.32.4(k) Where competing interpretations are both plausible, GCRI Canada shall adopt the narrower, safer, more source-lined, more classified, more public-safe, more privacy-protective, more cybersecurity-controlled, more sovereignty-compatible, more community-protective, more protected-knowledge-protective, more public-authority-bounded, more finance-safe, more procurement-safe, more provider-neutral, more sponsor-independent, more host-bounded, more operator-bounded, more role-separated, more records-valid, more correctionable, and more public-trust-preserving interpretation.

9.32.4(l) The controlling rule shall be that ambiguity shall never be used to enlarge GCRI Canada’s authority, status, execution role, public warning role, finance role, procurement role, certification role, recognition role, provider preference, sponsor control, host approval, operator instruction, protocol effect, or market consequence; ambiguity shall be resolved toward evidence integrity, safeguards, correctionability, role separation, and public trust.

<br>


---

# 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 dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.therisk.global/organization/organization/governance/charters/gcri-ca/ix.-observatory.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

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.