VI. TECHNOLOGY
6.1 All-Exponential and Mission-Critical Technology Mandate
6.1.1 GCRI Canada’s Mandate Across Exponential Technologies, Mission-Critical Systems, and Systemic-Risk Domains. 6.1.1(a) GCRI Canada’s mandate shall extend across exponential technologies, mission-critical systems, systemic-risk domains, public-benefit technology fields, resilience-relevant infrastructures, public-authority-relevant systems, and infrastructure-relevant technical domains, without being limited to a single technology, sector, hazard class, infrastructure category, research discipline, or implementation pathway.
6.1.1(b) The technology and domain scope of GCRI Canada may include artificial intelligence, frontier AI, applied AI, agentic systems, decision-support systems, AI governance systems, AI assurance systems, AI safety systems, AI-RAN, O-RAN, private wireless, telecommunications infrastructure, sovereign compute, high-performance computing, edge compute, cloud infrastructure, verifiable compute, verifiable intelligence, blockchain, distributed ledger technology, Web3 systems, DePIN, cryptographic infrastructure, cybersecurity, cyber-physical systems, operational technology, robotics, drones, autonomous systems, sensing systems, sensor networks, Earth observation, satellite systems, geospatial intelligence, digital twins, simulation systems, quantum-relevant systems, biosecurity, biotechnology-adjacent risk systems, health-relevant systems, WEFH systems, climate systems, nature systems, biodiversity systems, energy systems, advanced manufacturing, semiconductors, supply chains, space systems, remote connectivity, critical infrastructure, strategic infrastructure, resilience infrastructure, and related public-benefit technical domains.
6.1.1(c) GCRI Canada’s mandate shall also extend to the interaction among such technologies and domains, including compound-risk pathways, cascading failures, infrastructure interdependencies, cyber-physical dependencies, public authority dependencies, data dependencies, model dependencies, supply-chain dependencies, community impacts, sovereignty implications, finance-readiness evidence needs, public-safe communication needs, and correction needs.
6.1.1(d) The inclusion of a technology or domain within GCRI Canada’s mandate shall mean that GCRI Canada may research, evidence, model, observe, compare, test, document, classify, structure, steward, publish, teach, support public authority learning, develop methods, develop ontology, develop public-good software, support open technical baselines, support public-safe reporting, and correct records concerning that technology or domain within its lawful role.
6.1.1(e) Technology and domain inclusion shall not mean that GCRI Canada regulates, certifies by default, procures, finances, insures, underwrites, rates, deploys, operates, commands, warns, approves, recognizes, endorses, guarantees, selects providers, grants public authority status, grants finance-readiness, creates protocol effect, or executes activity in that technology or domain.
6.1.1(f) GCRI Canada may prioritize technologies and domains according to public-benefit relevance, systemic-risk significance, Canadian relevance, global Nexus relevance, public authority learning need, evidence gap, method gap, observability gap, technical-baseline need, public-safe publication need, sovereignty relevance, community safeguard need, correction need, and emerging risk.
6.1.1(g) The Board, or a properly authorized body or officer acting within delegated authority, may approve programs, workstreams, research agendas, technical baselines, public-good software efforts, Observatory methods, Academy materials, Docket inputs, Grid inputs, publications, and interface activities within this broad technology mandate, subject to law, the Bylaw, this Charter, non-execution, role separation, public-safe review, data safeguards, cybersecurity, and correctionability.
6.1.1(h) The controlling rule shall be that GCRI Canada’s technology mandate is broad because public-benefit risk is interconnected, but that breadth shall never be read as execution authority.
6.1.2 Technology Scope as Public-Benefit Evidence Scope, Not Execution Scope. 6.1.2(a) GCRI Canada’s technology scope shall be interpreted as public-benefit evidence scope, not execution scope.
6.1.2(b) Within any technology or domain, GCRI Canada may collect, structure, review, compare, steward, publish, teach, route, and correct evidence concerning technical function, risk, maturity context, readiness context, hazards, vulnerabilities, dependencies, assumptions, performance claims, interoperability, data governance, AI governance, cybersecurity, public authority relevance, community impact, public-safe communication, and correction history.
6.1.2(c) Evidence scope may include source records, technical records, benchmark records, dataset records, model records, system records, inference records, compute workload records, sensor records, AI-RAN signal records, DePIN records, digital twin assumptions, dashboard outputs, geospatial records, cyber telemetry, public authority learning records, host-readiness evidence, node evidence, risk evidence, public-safe reports, controlled annexes, Docket inputs, Grid inputs, and correction records.
6.1.2(d) Evidence scope shall not become execution scope. GCRI Canada shall not deploy systems, operate infrastructure, provide managed services, run emergency command, issue official public warnings, conduct public procurement, select vendors, arrange finance, recommend investments, underwrite insurance, issue ratings, guarantee performance, certify by default, create public authority action, create protocol effect, or perform regulated professional functions merely because it holds evidence concerning a technology.
6.1.2(e) Evidence about a technology’s readiness, risk, performance, compatibility, resilience, security, or public-benefit relevance shall not be described as approval, endorsement, certification, recognition, finance-readiness, procurement readiness, deployment authorization, public authority approval, guarantee, rating, underwriting, or operational clearance unless the competent actor and source record separately support such status.
6.1.2(f) Where evidence could be misunderstood as execution authority, GCRI Canada shall apply boundary language, source-lineage language, limitation language, public-safe classification, finance-safe language where material, public authority boundary language, procurement boundary language, provider-neutrality language, and correction path.
6.1.2(g) Where technology evidence is used by another actor for downstream action, that actor shall remain responsible for its own review, lawful authority, reliance, public claims, legal compliance, data handling, cybersecurity, finance decisions, procurement decisions, public authority decisions, operational decisions, and corrections.
6.1.2(h) The controlling rule shall be that GCRI Canada may make technology evidence more truthful, legible, comparable, and correctable, but it shall not execute the technology by evidencing it.
6.1.3 Technology Scope as Methods, Observability, Ontology, Technical Truth, Public-Good R&D, Technical Baseline, and Public-Safe Publication Scope. 6.1.3(a) GCRI Canada’s technology scope shall include methods, observability, ontology, technical truth, public-good R&D, technical baseline, public-good software, public authority learning, and public-safe publication work across all covered technologies and domains.
6.1.3(b) Methods work may include development, testing, comparison, publication, versioning, correction, localization, and public-safe explanation of evidence methods, confidence methods, uncertainty methods, source-lineage methods, benchmarking methods, test methods, validation methods, simulation methods, scenario methods, Observatory methods, Nexus Truth Engine methods, data governance methods, AI governance methods, cybersecurity methods, public authority learning methods, community safeguard methods, protected knowledge methods, and correction methods.
6.1.3(c) Observability work may include methods for observing, instrumenting, structuring, comparing, visualizing, and correcting evidence from sensors, AI-RAN, O-RAN, private wireless, DePIN systems, cyber telemetry, satellite systems, Earth observation, geospatial systems, digital twins, dashboards, maps, edge systems, compute systems, public authority systems, infrastructure systems, environmental systems, health-relevant systems, and other public-benefit domains.
6.1.3(d) Ontology work may include taxonomies, schemas, controlled vocabularies, data dictionaries, semantic mappings, evidence categories, technology categories, risk categories, maturity-context categories, readiness-context categories, public-safe classifications, public authority capacity terms, finance-boundary terms, protocol-boundary terms, Docket terms, Grid terms, correction terms, and localization notes.
6.1.3(e) Technical truth work may include source comparison, confidence logic, corroboration, dispute handling, spoof-signal handling, stale-evidence handling, missing-evidence handling, model-output interpretation, dataset limitation handling, benchmark limitation handling, public-safe summarization, correction triggers, supersession, withdrawal, downgrade, reinstatement, and dependency review.
6.1.3(f) Public-good R&D and technical baseline work may include reference architectures, open technical profiles, APIs, public-good software, evaluation harnesses, test harnesses, conformance-supporting tools, secure release practices, repository discipline, SBOM-related practices where applicable, vulnerability handling, model-card templates, dataset-card templates, system-card templates, benchmark-card templates, inference-record templates, and compute workload record templates.
6.1.3(g) Public-safe publication work may include public-safe reports, technical notes, whitepapers, controlled annexes, dashboards, maps, Academy materials, briefings, training materials, public authority learning materials, Docket inputs, Grid inputs, risk summaries, technology summaries, correction notices, withdrawal notices, and supersession notices.
6.1.3(h) The controlling rule shall be that GCRI Canada’s technology mandate is expressed through methods, observability, ontology, technical truth, public-good R&D, technical baselines, public-safe publication, and correction, not through execution.
6.1.4 Technology Scope as Nexus-Compatible Interoperability Scope. 6.1.4(a) GCRI Canada’s technology scope shall be interpreted as Nexus-compatible interoperability scope across technologies, domains, institutions, records, public-safe outputs, and lawful handoffs.
6.1.4(b) GCRI Canada may support interoperability by developing or stewarding evidence categories, methods, ontologies, schemas, data dictionaries, controlled vocabularies, APIs, reference architectures, technical baselines, public-good software, evaluation harnesses, test harnesses, public-safe classifications, Docket inputs, Grid inputs, Observatory methods, Truth Engine methods, Rails inputs, Academy materials, and correction records.
6.1.4(c) Nexus-compatible interoperability may involve semantic compatibility, evidence-format compatibility, data-governance compatibility, AI-governance compatibility, cyber-governance compatibility, technical-baseline compatibility, public-safe publication compatibility, Observatory-method compatibility, Docket compatibility, Grid compatibility, Academy compatibility, protocol-support compatibility, and handoff compatibility.
6.1.4(d) Interoperability scope shall not create Nexus-wide authority. GCRI Canada shall not become the whole of Nexus, GRF, GRA, Protocol Authority, Nexus Network, Nexus Universe, Nexus Observatory, Nexus Risk Management, Nexus Rails, Nexus Grid, Nexus Academy, a Regional Nexus Consortium, a National Nexus Consortium, a National Consortium Company, a Project SPV, a provider, a public authority, a sponsor, a host, a capital actor, or an execution actor by supporting interoperability.
6.1.4(e) Nexus-compatible status shall not mean approved, certified, recognized, finance-ready, procurement-ready, public authority-approved, provider-preferred, protocol-effective, operationally cleared, deployed, guaranteed, rated, underwritten, insured, public-finance-approved, professionally assured, or execution-ready by default.
6.1.4(f) Where GCRI Canada supports interoperability for a technology or domain, the relevant record shall identify source, version, scope, role, non-role, authority status, limitations, public-safe status, data classification, IP status, cybersecurity obligations, permitted use, prohibited use, public claims limits, and correction path.
6.1.4(g) Interoperability work shall preserve difference where difference matters, including jurisdictional differences, public authority differences, community context, Indigenous and local knowledge context, data sovereignty, legal restrictions, language, technical maturity, public-safe classification, finance-boundary limits, and protocol-boundary limits.
6.1.4(h) The controlling rule shall be that GCRI Canada may make technologies interoperable for public-good truth and learning, but interoperability shall not collapse roles, authority, liability, or execution boundaries.
6.1.5 Technology Scope as Public Authority Learning Scope Without Public Authority Delegation. 6.1.5(a) GCRI Canada’s technology scope shall include public authority learning scope across all covered technologies and domains, without creating public authority delegation.
6.1.5(b) Public authority learning may include technical literacy, evidence literacy, AI literacy, cyber literacy, data literacy, observability literacy, AI-RAN literacy, DePIN literacy, digital twin literacy, geospatial literacy, climate and nature risk literacy, biosecurity literacy, infrastructure risk literacy, WEFH systems literacy, energy systems literacy, semiconductor and supply-chain literacy, space and remote connectivity literacy, public-safe publication literacy, and correction literacy.
6.1.5(c) GCRI Canada may support public authorities through briefings, workshops, Academy programs, scenario exercises, tabletop exercises, public-safe reports, controlled annexes, technical baselines, public-good software explanations, Observatory methods, Docket and Grid literacy, model governance materials, data governance materials, cybersecurity materials, and correction pathways.
6.1.5(d) Public authority learning scope shall not create public authority delegation, official guidance, regulatory approval, enforcement position, procurement approval, funding approval, public finance approval, public warning, emergency command, public-private partnership, sovereign obligation, public adoption, public health order, public safety directive, infrastructure directive, or public authority decision by default.
6.1.5(e) Public authority participation in any technology domain shall require capacity classification where material, including observer, learner, technical participant, evidence contributor, data contributor, host, funder, reviewer, public finance reader, procurement observer, regulator attending in non-regulatory capacity, emergency management learner, public health learner, infrastructure learner, scenario participant, dashboard viewer, Docket participant, Grid participant, Academy participant, or official decision-maker acting only through a separate public process.
6.1.5(f) Public authority-facing technology materials shall include non-delegation, non-endorsement, non-public-authority-decision, non-warning, non-command, non-regulatory-guidance, non-procurement, non-public-finance-approval, non-professional-advice, non-certification, non-recognition, non-finance-readiness, non-protocol-effect, and non-execution language where material.
6.1.5(g) Where technology outputs could be mistaken for public authority action, including hazard maps, health-relevant summaries, cyber alerts, infrastructure dashboards, digital twin scenarios, AI risk summaries, emergency-adjacent materials, climate risk visualizations, public-safe reports, or public authority briefings, GCRI Canada shall apply heightened public-safe review, reference approval where applicable, and correction path before release.
6.1.5(h) The controlling rule shall be that GCRI Canada may help public authorities understand technologies, but public authorities decide through their own lawful authority.
6.1.6 Technology Scope as Finance-Readiness Evidence Support Scope Without Financial Execution. 6.1.6(a) GCRI Canada’s technology scope shall include finance-readiness evidence support scope across covered technologies and domains, without creating financial execution.
6.1.6(b) Finance-readiness evidence support may include evidence concerning technology risk, host readiness, node evidence, infrastructure readiness context, technical baseline alignment, data governance, AI governance, cybersecurity, resilience context, climate and nature risk, energy systems, WEFH systems, satellite and geospatial evidence, remote connectivity, supply-chain resilience, operational assumptions, diligence gaps, evidence gaps, public-safe status, and correction history.
6.1.6(c) Such support may be routed to GRA, capital readers, public finance readers, insurers, lenders, underwriters, rating actors, MDBs, DFIs, public finance actors, National Consortium Companies, Project SPVs, qualified providers, licensed professionals, or other competent actors only through boundary-safe records, finance-safe language, source lineage, limitations, permitted use, prohibited use, and correction path.
6.1.6(d) Technology evidence support shall not constitute investment advice, securities advice, capital solicitation, securities offering, private placement, token sale, brokerage, dealer activity, finder activity, placement activity, lending approval, credit approval, guarantee, insurance advice, insurance placement, underwriting, rating, public finance approval, capital commitment, finance-readiness, or GCRI Canada financial responsibility.
6.1.6(e) GCRI Canada shall not recommend investment in, lending to, insuring, underwriting, rating, financing, guaranteeing, procuring, purchasing, deploying, or capitalizing any technology, provider, project, National Consortium Company, Project SPV, fund, token, debt, equity, derivative, insurance product, or investment strategy by virtue of technology coverage.
6.1.6(f) Finance-facing technology materials shall include no-investment-advice, no-offer, no-solicitation, no-brokerage, no-finder, no-placement, no-lending, no-credit-approval, no-guarantee, no-insurance-advice, no-underwriting, no-rating, no-public-finance-approval, no-capital-commitment, and no-GCRI-Canada-finance-readiness language where material.
6.1.6(g) Where technology evidence could reasonably be used as finance-facing material, GCRI Canada shall apply finance-boundary review, regulated-perimeter review where material, public-safe review, public claims review, and correction path before routing, publication, or external use.
6.1.6(h) The controlling rule shall be that GCRI Canada may make technology evidence legible to finance-readiness processes, but it shall not perform finance.
6.1.7 Technology Scope as Standards-Support Scope Without Certification by Default. 6.1.7(a) GCRI Canada’s technology scope shall include standards-support scope across covered technologies and domains, without creating certification by default.
6.1.7(b) Standards-support work may include evidence requirements, method profiles, ontologies, schemas, data dictionaries, controlled vocabularies, technical baselines, reference architectures, public-good software, APIs, test harnesses, evaluation harnesses, conformance-supporting tools, proof-input logic, secure release practices, repository discipline, model cards, dataset cards, system cards, benchmark cards, inference records, compute workload records, and correction records.
6.1.7(c) Standards-support work may support Nexus Standards / Protocol Authority, public authorities, standards bodies, universities, providers, National Consortium Companies, Project SPVs, public-good actors, and other competent actors, but shall not become certification, conformance determination, protocol effect, public authority approval, procurement approval, provider endorsement, market approval, operational clearance, or execution authorization by default.
6.1.7(d) Testing is not certification. Benchmarking is not certification. Evidence review is not certification. Technical baseline alignment is not certification. Public-good software use is not certification. Academy participation is not certification. Validation sprint participation is not certification. Observatory methods support is not certification. Docket or Grid input is not certification.
6.1.7(e) Any certification-like effect concerning a technology, provider, system, node, dashboard, dataset, model, software, technical baseline, standard, protocol, maturity state, public authority readiness, finance-readiness, or Nexus compatibility shall require a separate authorized program, competent actor, lawful authority, scope, criteria, review, limitations, public claims controls, and correction path.
6.1.7(f) Where standards-support materials could be mistaken for certification or protocol effect, GCRI Canada shall include non-certification, non-conformance-determination, non-protocol-effect, non-public-authority-approval, non-procurement, non-finance-readiness, non-provider-endorsement, and non-execution language where material.
6.1.7(g) Where technology standards-support outputs are corrected, superseded, withdrawn, deprecated, patched, restricted, or found vulnerable, GCRI Canada shall review affected technical baselines, public-good software, public materials, interface instruments, public claims, and downstream recipients.
6.1.7(h) The controlling rule shall be that GCRI Canada may support standards and protocol discipline, but shall not certify technologies by default.
6.1.8 Technology Scope as Public-Good Software and Open Technical Baseline Scope Without Vendor Preference. 6.1.8(a) GCRI Canada’s technology scope shall include public-good software and open technical baseline scope across covered technologies and domains, without creating vendor preference.
6.1.8(b) Public-good software and open technical baselines may include reference implementations, APIs, schemas, data dictionaries, ontologies, dashboards, data tools, evaluation harnesses, test harnesses, secure release templates, model governance templates, dataset templates, system-record templates, benchmark templates, inference-record templates, compute workload templates, Observatory methods tools, public-safe mapping tools, Docket-supporting tools, Grid-supporting tools, and correction tools.
6.1.8(c) GCRI Canada may steward, publish, license, maintain, correct, supersede, withdraw, restrict, or archive public-good software and technical baselines according to its public-benefit purpose, repository discipline, IP terms, security obligations, public-safe classification, anti-enclosure commitments, and correctionability.
6.1.8(d) Use of, contribution to, testing against, alignment with, adaptation of, or integration with GCRI Canada public-good software or open technical baselines shall not create preferred vendor status, provider endorsement, procurement advantage, certification, recognition, finance-readiness, public authority approval, protocol effect, operational clearance, deployment authorization, market superiority, or execution authority by default.
6.1.8(e) Provider contributions to public-good software or open technical baselines shall not create technical supremacy, ownership of public-good truth, public authority access, benchmark advantage, publication control, Docket outcome, Grid outcome, recognition, finance-readiness, certification, procurement preference, or provider status beyond the source record.
6.1.8(f) Public-good software and open technical baseline releases shall include appropriate license, attribution, contribution, security, vulnerability, public claims, non-endorsement, non-certification, non-procurement, non-finance-readiness, non-public-authority-approval, non-protocol-effect where applicable, and correction language.
6.1.8(g) Where public-good software or open technical baselines are used by enterprise-stack actors, those actors shall remain responsible for implementation, security, operations, legal compliance, customer claims, public claims, warranties, service levels, deployment, maintenance, and corrections.
6.1.8(h) The controlling rule shall be that open technical infrastructure may support many technologies and actors, but it shall not select winners by implication.
6.1.9 Technology Scope as Safeguards Scope for Privacy, Data Rights, Cybersecurity, Sovereignty, Indigenous and Community Knowledge, and Do-No-Harm. 6.1.9(a) GCRI Canada’s technology scope shall include safeguards scope for privacy, data rights, cybersecurity, sovereignty, Indigenous knowledge, local knowledge, community knowledge, protected knowledge, public authority data, rights-bearing data, AI-use limits, public-safe mapping, and do-no-harm across all covered technologies and domains.
6.1.9(b) Privacy and data-rights safeguards shall address personal information, rights-bearing data, affected persons, affected communities, lawful basis, consent or authorization where applicable, purpose limitation, minimization, access restriction, retention, correction, deletion or restriction where required, onward sharing, publication risk, AI-use limits, and correction path.
6.1.9(c) Cybersecurity safeguards shall address authentication, authorization, least privilege, secure transfer, secure storage, encryption where appropriate, secrets management, repository security, dashboard security, API security, model security, sensor security, AI-RAN security, DePIN security, digital twin security, vulnerability management, incident response, evidence preservation, and public-safe disclosure.
6.1.9(d) Sovereignty safeguards shall address Canadian legal requirements, cross-border data transfer, public authority restrictions, sovereign data, Indigenous data sovereignty where applicable, local law, national security-adjacent sensitivity, sanctions, export controls, controlled technology, compute localization, compute-to-data, infrastructure sensitivity, and public-safe publication limits.
6.1.9(e) Indigenous, local, community, and protected knowledge safeguards shall address cultural protocols, consent or non-consent treatment where applicable, non-extraction, non-enclosure, protected participation, non-retaliation, attribution or non-attribution, sensitive location protection, ecological knowledge protection, health-sensitive knowledge protection, community review, grievance, remedy, withdrawal or restriction, and correction path.
6.1.9(f) Do-no-harm safeguards shall address stigma, retaliation, unsafe mapping, sensitive infrastructure exposure, public warning confusion, emergency command confusion, public authority misuse, sponsor misuse, provider misuse, finance misuse, media misuse, community harm, environmental harm, cybersecurity harm, privacy harm, and misuse of AI-generated or model-derived outputs.
6.1.9(g) Technology work involving high-risk data, AI systems, cyber systems, public authority data, health-sensitive information, public safety information, community knowledge, Indigenous knowledge, geospatial information, critical infrastructure, controlled technology, or finance-sensitive materials shall require heightened safeguards, classification, review, and correction controls.
6.1.9(h) The controlling rule shall be that GCRI Canada’s technology mandate is inseparable from safeguards; no technical ambition shall override privacy, rights, sovereignty, security, community protection, or do-no-harm.
6.1.10 Technology Scope as Dynamic, Expandable, and Correctable as New Technologies, Risks, Infrastructures, and Public-Benefit Needs Emerge. 6.1.10(a) GCRI Canada’s technology scope shall be dynamic, expandable, and correctable as new technologies, risks, infrastructures, public-benefit needs, public authority learning needs, evidence gaps, method gaps, observability gaps, interoperability needs, public-safe communication needs, and correction needs emerge.
6.1.10(b) The enumeration of technologies and domains in this Charter shall be illustrative and expansive, not exhaustive. New or evolving fields may be brought within GCRI Canada’s work where they are exponential, mission-critical, systemic-risk-relevant, public-benefit-relevant, infrastructure-relevant, public-authority-relevant, resilience-relevant, sovereignty-relevant, community-relevant, or correction-relevant.
6.1.10(c) Emerging technologies may include technologies not yet widely deployed, technologies not yet fully categorized, hybrid technologies, convergent technology stacks, cyber-physical systems, AI-enabled systems, bio-digital systems, climate-tech systems, quantum-relevant systems, compute-intensive systems, autonomous systems, space-enabled systems, sensing systems, cryptographic systems, and future infrastructure categories.
6.1.10(d) Expansion of scope shall not require amendment of this Charter where the new technology or domain fits within the public-benefit evidence, methods, observability, ontology, public-good R&D, public-good software, technical baseline, public authority learning, public-safe publication, safeguards, and correction functions authorized by this Charter.
6.1.10(e) Expansion of scope shall require appropriate review where the technology or domain presents heightened legal, public authority, finance, procurement, certification, recognition, protocol, data, AI, cybersecurity, export-control, sanctions, controlled technology, health, safety, infrastructure, protected knowledge, community, Indigenous knowledge, environmental, or public trust risk.
6.1.10(f) Dynamic scope shall be accompanied by controlled vocabulary updates, ontology updates, method updates, technical baseline updates, public-safe classification updates, training updates, interface updates, public claims updates, safeguard updates, repository updates, and correction updates where material.
6.1.10(g) Where prior technology scope statements become stale, overbroad, unsafe, incomplete, misleading, or inconsistent with new evidence, law, public authority context, public-safe needs, or Nexus doctrine, GCRI Canada shall correct, supersede, withdraw, reclassify, or update such statements.
6.1.10(h) The controlling rule shall be that GCRI Canada’s technology mandate may expand with the world’s risk landscape, but every expansion remains bounded by non-execution, validity-by-record, public-good stewardship, safeguards, and correctionability.
6.2 Technology-Neutral Evidence Discipline
6.2.1 Evidence Discipline Applies Across All Technologies. 6.2.1(a) Evidence discipline shall apply across all technologies, domains, infrastructures, systems, hazards, public-benefit fields, public authority learning contexts, Nexus interfaces, and GCRI Canada workstreams. No technology, however urgent, novel, complex, strategic, sensitive, commercially important, publicly visible, nationally relevant, financially significant, or mission-critical, shall be exempt from evidence discipline.
6.2.1(b) Evidence discipline shall apply to artificial intelligence, frontier AI, agentic systems, AI governance systems, AI-RAN, O-RAN, private wireless, sovereign compute, high-performance computing, edge compute, cloud systems, verifiable compute, verifiable intelligence, blockchain, distributed ledger technology, Web3, DePIN, cybersecurity, cyber-physical systems, robotics, drones, autonomous systems, sensing, Earth observation, satellites, geospatial intelligence, digital twins, quantum-relevant systems, biosecurity, health-relevant systems, WEFH systems, climate, nature, biodiversity, energy, semiconductors, advanced manufacturing, supply chains, space, remote connectivity, strategic infrastructure, critical infrastructure, and any later-emerging technology within GCRI Canada’s public-benefit scope.
6.2.1(c) Evidence discipline shall include source lineage, provenance, custody, classification, access control, lawful basis where applicable, public-safe review, data safeguards, AI-use controls, cybersecurity controls, confidence treatment, uncertainty treatment, limitations, records-validity, claims discipline, correction path, supersession path, withdrawal path, and downstream dependency review.
6.2.1(d) Evidence discipline shall apply whether evidence is produced by GCRI Canada, received from another actor, submitted by a provider, contributed by a host, supplied by a public authority, generated by a model, derived from a sensor, routed through Nexus Rails, recorded in a Docket, reflected in a Grid, displayed in a dashboard, embedded in a map, included in a public-safe report, placed in a data room, incorporated in Academy materials, or handed off to GRF, GRA, Protocol Authority, public authorities, National Consortium Companies, Project SPVs, qualified providers, licensed actors, or capital readers.
6.2.1(e) Evidence discipline shall not be relaxed because a technology is experimental, proprietary, open-source, sovereign, public-sector, mission-critical, emergency-adjacent, climate-relevant, finance-facing, publicly funded, sponsor-supported, provider-supported, host-supported, media-visible, politically important, or strategically urgent.
6.2.1(f) Evidence discipline shall be proportionate to reliance risk. Higher-risk technologies, higher-sensitivity data, higher public authority relevance, higher finance-facing relevance, higher public-safe risk, higher cyber risk, higher community impact, higher protected knowledge sensitivity, and higher downstream execution relevance shall require stronger records, stronger review, stronger boundary language, and stronger correction paths.
6.2.1(g) The absence of a mature evidence standard for a new technology shall not excuse evidentiary discipline. Where methods are immature, GCRI Canada shall identify uncertainty, method gap, limitation, review status, and correction path rather than overstating confidence.
6.2.1(h) The controlling rule shall be that technology novelty may require new methods, but it shall not suspend evidence discipline.
6.2.2 No Technology Exemption From Source Lineage, Provenance, Custody, Classification, Confidence, Uncertainty, Limitations, and Correction. 6.2.2(a) No technology or domain shall be exempt from source lineage, provenance, custody, classification, confidence, uncertainty, limitations, and correction requirements.
6.2.2(b) Source lineage shall identify the source of evidence, including issuer, contributor, system, sensor, model, dataset, public authority, host, provider, university, community, Indigenous or local knowledge holder, repository, dashboard, map, satellite, AI-RAN signal, DePIN record, blockchain anchor, cyber telemetry stream, digital twin input, or other source.
6.2.2(c) Provenance shall identify origin, creation context, collection method, transformation, processing, model use, human review, version, date, dependency, chain of custody where material, and whether the evidence is original, derived, summarized, translated, inferred, modeled, simulated, AI-assisted, aggregated, anonymized, public-safe summarized, or externally supplied.
6.2.2(d) Custody shall identify who holds the evidence, who may access it, who may modify it, who may route it, who may publish it, who may correct it, who must receive correction notice, and what repository, system, room, controlled annex, dashboard, Docket, Grid, Observatory record, or handoff record contains the authoritative version.
6.2.2(e) Classification shall identify whether the evidence is public, public-safe summary, controlled, restricted, confidential, privileged, draft, under review, quarantined, superseded, withdrawn, not-for-reliance, public authority restricted, finance restricted, provider restricted, sponsor restricted, protected knowledge restricted, cyber-sensitive, infrastructure-sensitive, export-control-sensitive, sanctions-sensitive, health-sensitive, community-sensitive, Indigenous-knowledge-sensitive, or otherwise limited.
6.2.2(f) Confidence and uncertainty treatment shall identify the basis for confidence, source quality, corroboration, independence, recency, completeness, method fit, data quality, model dependence, sensor reliability, benchmark limits, simulation assumptions, human review status, dispute status, spoof risk, stale evidence risk, missing evidence, and correction history.
6.2.2(g) Limitations shall state what the evidence does not show, what remains uncertain, what was not tested, what was not observed, what was inferred, what was simulated, what was modeled, what was provider-supplied, what was public authority-limited, what was public-safe-limited, what was finance-limited, what was not independently corroborated, and what requires competent external review.
6.2.2(h) Correction shall identify how errors, stale records, disputed evidence, unsafe outputs, data misuse, AI error, cyber issue, protected knowledge exposure, public authority confusion, finance overclaim, procurement implication, provider overclaim, sponsor overclaim, or downstream misuse may be reported, reviewed, corrected, superseded, withdrawn, retracted, downgraded, reinstated, restricted, or publicly clarified.
6.2.2(i) The controlling rule shall be that no technology evidence shall travel without its source, custody, classification, confidence, limits, and correction path.
6.2.3 No Technology Exemption From Public-Safe Review. 6.2.3(a) No technology or domain shall be exempt from public-safe review where evidence, methods, outputs, publications, dashboards, maps, briefings, reports, Academy materials, Docket inputs, Grid inputs, Observatory records, Truth Engine outputs, Rails handoffs, or public claims may affect public understanding, public authority interpretation, finance-facing reliance, community safety, protected knowledge, infrastructure security, cyber risk, health-sensitive context, environmental context, or public trust.
6.2.3(b) Public-safe review shall assess whether technology evidence or outputs could be mistaken for official public warning, emergency command, public authority decision, regulatory guidance, procurement approval, public finance approval, certification, recognition, finance-readiness, provider endorsement, sponsor approval, protocol effect, professional advice, operational clearance, deployment authorization, market approval, rating, underwriting, guarantee, or execution instruction.
6.2.3(c) Public-safe review shall apply to hazard maps, dashboards, digital twins, climate risk visualizations, wildfire or flood outputs, health-relevant summaries, cyber-risk notes, infrastructure summaries, AI risk materials, AI-RAN signal outputs, DePIN records, satellite imagery, geospatial layers, model-derived outputs, confidence scores, public-safe reports, controlled annexes, technical baselines, public-good software releases, and public authority learning materials.
6.2.3(d) Public-safe review shall address privacy, public authority data, sovereign data, Indigenous and local knowledge, protected knowledge, sensitive locations, critical infrastructure, cyber-sensitive information, health-sensitive information, export-control sensitivity, sanctions sensitivity, controlled technology, community harm, environmental harm, public warning confusion, emergency command confusion, finance misuse, procurement misuse, sponsor misuse, provider misuse, media misuse, and public trust risk.
6.2.3(e) Public-safe review shall be proportionate to release mode. Public materials, public dashboards, public maps, media materials, public authority materials, finance-facing materials, procurement-facing materials, community-facing materials, and sponsor or provider materials shall require higher public-safe scrutiny than internal technical drafts.
6.2.3(f) Where public-safe review identifies risk, GCRI Canada shall revise, restrict, aggregate, redact, anonymize where appropriate and sufficient, localize, reclassify, delay, quarantine, withdraw, route to a competent actor, add boundary language, add limitations, or refuse release.
6.2.3(g) Public-safe review shall be recorded where material, including reviewer, scope, materials reviewed, risks identified, restrictions imposed, disclaimers required, public claims limits, correction path, and downstream notice obligations.
6.2.3(h) The controlling rule shall be that technical truth shall be made public only in forms that do not create avoidable harm, false authority, or unsafe reliance.
6.2.4 No Technology Exemption From Privacy, Data Rights, Sovereign Data, Cybersecurity, and Protected Knowledge Controls. 6.2.4(a) No technology or domain shall be exempt from privacy, data rights, sovereign data, cybersecurity, public authority data, Indigenous and local knowledge, protected knowledge, community safeguard, AI-use, and do-no-harm controls.
6.2.4(b) Privacy and data-rights controls shall apply to personal information, rights-bearing data, affected persons, affected communities, participant data, staff data, location data, sensor data, health-sensitive data, public authority data, community data, model inputs, model outputs, dashboard data, map layers, digital twin inputs, inference records, compute records, and derived evidence.
6.2.4(c) Sovereign data controls shall apply to Canadian data, public authority data, national data, regional data, local data, Indigenous data sovereignty where applicable, cross-border data transfers, compute localization, compute-to-data arrangements, public authority restrictions, critical infrastructure data, public safety data, and data subject to national security-adjacent, export-control, sanctions, or controlled-technology sensitivity.
6.2.4(d) Cybersecurity controls shall apply to repositories, dashboards, APIs, data rooms, cloud systems, AI systems, models, compute systems, sensor systems, AI-RAN systems, O-RAN systems, private wireless systems, DePIN systems, cyber telemetry, digital twins, public-good software, technical baselines, release pipelines, credentials, secrets, and shared platforms.
6.2.4(e) Protected knowledge controls shall apply to Indigenous knowledge, local knowledge, community knowledge, ecological knowledge, cultural knowledge, sacred-site information, sensitive location information, protected habitat information, health-sensitive community knowledge, security-sensitive knowledge, and knowledge shared under restricted, confidential, customary, ethical, or community conditions.
6.2.4(f) AI-use controls shall identify whether data may be input into AI tools, summarized, embedded, retrieved, classified, used for inference, used for evaluation, used for training, used for model development, used in dashboards, used in maps, used in digital twins, or used to generate public materials, and shall require human review and inference records where material.
6.2.4(g) Where privacy, data rights, sovereignty, cybersecurity, or protected knowledge controls cannot be satisfied, GCRI Canada shall restrict, re-scope, aggregate, redact, anonymize where appropriate and sufficient, localize, compute-to-data, classify, delay, quarantine, route, refuse, withdraw, or correct the activity.
6.2.4(h) The controlling rule shall be that no technology is so important that it may bypass rights, sovereignty, security, protected knowledge, or community safeguards.
6.2.5 No Technology Exemption From Non-Execution, Public Authority Boundaries, Finance Boundaries, Provider Neutrality, Sponsor Non-Control, and Competition Safety. 6.2.5(a) No technology or domain shall be exempt from non-execution, public authority boundaries, finance boundaries, provider neutrality, sponsor non-control, competition safety, claims discipline, and correctionability.
6.2.5(b) Non-execution shall apply equally to every technology domain. GCRI Canada shall not regulate, procure, certify by default, finance, insure, underwrite, rate, operate, deploy, command, warn, professionally advise by default, select providers, guarantee outcomes, or execute merely because a technology is within its evidence and methods scope.
6.2.5(c) Public authority boundaries shall apply equally to all public authority-facing technology work. Public authority attendance, learning, comments, data contribution, hosting, dashboard access, technical review, or repeated engagement shall not create public authority delegation, endorsement, adoption, official guidance, public warning, emergency command, procurement approval, public finance approval, regulatory approval, funding approval, public-private partnership, or sovereign obligation by default.
6.2.5(d) Finance boundaries shall apply equally to all finance-facing technology work. Evidence concerning technology risk, resilience, host readiness, node evidence, technical maturity, interoperability, cybersecurity, AI governance, climate risk, energy systems, infrastructure readiness, or diligence gaps shall not become investment advice, securities offering, solicitation, brokerage, finder activity, lending approval, guarantee, insurance advice, underwriting, rating, public finance approval, capital commitment, or GCRI Canada finance-readiness.
6.2.5(e) Provider neutrality shall apply equally to all technologies. Provider testing, demonstration, contribution, benchmark participation, validation sprint participation, dashboard inclusion, technical baseline alignment, public-good software contribution, Academy participation, or public authority learning participation shall not create preferred status, procurement advantage, certification, recognition, finance-readiness, public authority approval, protocol effect, or market superiority by default.
6.2.5(f) Sponsor non-control shall apply equally to all technologies. Support, funding, in-kind contribution, equipment access, compute access, cloud credits, model access, facility support, data support, event support, Academy support, Observatory support, Docket support, Grid support, or public-safe publication support shall not control evidence, methods, publications, benchmarks, technical baselines, public authority access, provider participation, correction, or public claims.
6.2.5(g) Competition safety shall apply where technology work could affect markets, providers, procurement, public authority buyers, public finance readers, capital readers, technical baselines, benchmarks, comparison outputs, validation sprints, or public claims. GCRI Canada shall avoid market allocation, unfair access, pay-to-play, benchmark manipulation, procurement steering, provider preference, false superiority claims, and sponsor or funder influence over outcomes.
6.2.5(h) The controlling rule shall be that technological importance shall never expand GCRI Canada’s authority beyond its public-benefit, non-executing role.
6.2.6 Technology-Neutral Treatment of Evidence Quality. 6.2.6(a) Evidence quality shall be assessed through technology-neutral principles, adapted as necessary to technology-specific methods, data types, risks, and public-safe constraints.
6.2.6(b) Technology-neutral evidence quality principles shall include source reliability, provenance clarity, custody integrity, method fit, data quality, completeness, recency, corroboration, independence, reproducibility where appropriate, explainability where appropriate, sensitivity to context, limitation disclosure, uncertainty disclosure, dispute handling, correction history, and public-safe suitability.
6.2.6(c) Evidence quality shall not be inflated because evidence is produced by an advanced technology, high-profile institution, sponsor, provider, public authority, AI system, blockchain system, sensor network, satellite system, digital twin, benchmark, model, dashboard, or expert. Technical sophistication shall not substitute for evidence quality.
6.2.6(d) Evidence quality shall not be discounted merely because evidence is community-based, qualitative, local, Indigenous or local knowledge-sensitive, field-based, observational, experiential, narrative, or non-machine-generated. Such evidence shall be handled with appropriate safeguards, context, attribution or non-attribution, public-safe review, and method discipline.
6.2.6(e) Model-generated, AI-generated, simulated, inferred, synthetic, or derived evidence shall be classified as such and shall not be treated as direct observation unless the record supports that treatment.
6.2.6(f) Sensor-generated, AI-RAN-generated, DePIN-generated, blockchain-anchored, satellite-derived, geospatial, cyber telemetry, and digital twin evidence shall be assessed for calibration, source authenticity, spoof risk, tampering risk, data quality, sampling limits, coverage limits, model assumptions, transformation steps, and human review where material.
6.2.6(g) Provider-supplied evidence shall be assessed for conflict, independence, test conditions, reproducibility where appropriate, public claims risk, benchmark manipulation risk, sponsor influence, and competition impact.
6.2.6(h) Public authority evidence shall be assessed for authority to contribute, classification, official status, permitted use, publication permission, capacity, confidentiality, and correction path.
6.2.6(i) The controlling rule shall be that evidence quality depends on disciplined records and method fit, not on technology prestige.
6.2.7 Technology-Neutral Treatment of Records and Validity-by-Record. 6.2.7(a) Validity-by-record shall apply across all technologies and domains. No technology output, model output, dashboard output, sensor output, blockchain anchor, DePIN record, proof receipt, benchmark result, digital twin scenario, AI-RAN signal, cyber telemetry record, public-safe report, or technical baseline shall be treated as valid beyond the record that establishes its source, scope, authority, limitations, classification, review status, and correction path.
6.2.7(b) A record shall identify what the output is, who produced or contributed it, what system or method produced it where applicable, when it was produced, what version applies, what data was used, what assumptions apply, what review occurred, what status it has, what it may be used for, what it may not be used for, and how it may be corrected.
6.2.7(c) Technical automaticity shall not create validity. Automated outputs, AI outputs, model classifications, confidence scores, dashboard indicators, map layers, smart-contract events, blockchain anchors, proof receipts, sensor feeds, and system logs shall not become authoritative merely because they are machine-generated, cryptographically anchored, real-time, high-volume, or visually persuasive.
6.2.7(d) Validity-by-record shall require proper role. GCRI Canada may validate GCRI Canada evidence and methods records within its role; GRF validates its recognition and maturity records within its role; GRA validates finance-readiness and capital-readability records within its role; Protocol Authority validates protocol effect within its role; public authorities validate public authority acts within their lawful role; enterprise-stack actors validate their own execution records within their responsibility.
6.2.7(e) Shared records shall not create shared authority. Synchronization, repository access, dashboard display, shared Docket entry, shared Grid entry, public-safe report inclusion, Rails routing, data-room access, or cross-entity reference shall not expand the record’s validity beyond the source authority.
6.2.7(f) Where records are missing, conflicting, stale, disputed, corrected, superseded, withdrawn, downgraded, reinstated, reclassified, or restricted, GCRI Canada shall apply the most restrictive safe reading until the record is resolved.
6.2.7(g) Technology-specific records may be used where appropriate, including model cards, dataset cards, system cards, benchmark cards, inference records, compute workload records, SBOM records, vulnerability records, sensor calibration records, satellite imagery records, digital twin assumption records, AI-RAN signal records, DePIN evidence records, and cyber incident records.
6.2.7(h) The controlling rule shall be that validity follows the record, not the technology.
6.2.8 Technology-Neutral Treatment of Claims Discipline. 6.2.8(a) Claims discipline shall apply across all technologies and domains. No claim concerning a technology, system, provider, project, dataset, dashboard, model, technical baseline, public-good software asset, public authority interface, National Consortium Company, Project SPV, Docket item, Grid item, Academy activity, Observatory output, Rails handoff, or Nexus-compatible status shall be made unless it is records-valid, role-specific, public-safe, and correctionable.
6.2.8(b) Claims shall use controlled vocabulary and shall distinguish evidence from approval, methods from certification, technical support from endorsement, public authority learning from public authority action, compatibility from protocol effect, Docket input from approval, Grid input from guarantee, benchmark participation from ranking, testing from certification, Academy participation from credentialed authority, Observatory output from public warning, and finance-readable evidence from finance-readiness.
6.2.8(c) Claims shall not be expanded by technical sophistication, public visibility, emergency relevance, public authority attendance, sponsor support, provider participation, media attention, capital-reader interest, repository access, dashboard inclusion, map display, AI-generated summary, blockchain anchor, proof receipt, or repeated use.
6.2.8(d) Claims involving AI, blockchain, DePIN, cyber, dashboards, digital twins, sensors, satellite data, geospatial outputs, climate risk, public health, infrastructure, finance, procurement, public authority learning, or emergency-adjacent contexts shall include boundary language proportionate to the risk of false authority or unsafe reliance.
6.2.8(e) Claims made by providers, sponsors, hosts, public authorities, National Consortium Companies, Project SPVs, universities, media actors, civil society actors, communities, capital readers, or other third parties using GCRI Canada materials shall not exceed the source record or permitted public claims controls.
6.2.8(f) Visual claims, including badges, seals, labels, maps, dashboards, indicators, rankings, scores, directories, public profiles, and status icons, shall be treated as claims and shall not create status without competent authority and record.
6.2.8(g) Where claims discipline is breached, GCRI Canada shall require correction, withdrawal, retraction, reclassification, public-safe clarification, access restriction, name-use suspension, permission withdrawal, or other corrective action proportionate to risk.
6.2.8(h) The controlling rule shall be that technology claims must be as disciplined as technology evidence.
6.2.9 Technology-Neutral Treatment of Correction, Supersession, Withdrawal, Retraction, Suspension, Downgrade, and Reinstatement. 6.2.9(a) Correction, supersession, withdrawal, retraction, suspension, downgrade, and reinstatement shall apply across all technologies and domains as necessary to preserve evidence integrity, methods integrity, public-safe claims, legal compliance, data safety, cybersecurity, community safeguards, public authority boundaries, finance boundaries, provider neutrality, sponsor non-control, and public trust.
6.2.9(b) Correction shall be used where an error, stale record, misclassification, overclaim, unsafe wording, incomplete limitation, incorrect source lineage, model error, data error, dashboard error, map error, benchmark error, public authority misdescription, finance overclaim, provider overclaim, sponsor overclaim, or public-safe issue can be made accurate and safe through revision.
6.2.9(c) Supersession shall be used where a new record replaces an earlier record and the earlier record should remain preserved as historical memory but should no longer be treated as current.
6.2.9(d) Withdrawal shall be used where a record, output, dashboard, map, dataset, model result, technical baseline, public-good software release, report, public claim, or handoff cannot be safely corrected in place, lacks authority, includes unauthorized data, exposes protected knowledge, creates public authority confusion, creates finance overclaim, creates procurement implication, or creates material public trust risk.
6.2.9(e) Retraction shall be used where a public or material claim was materially wrong, misleading, unsupported, authority-inflating, unsafe, harmful, or inconsistent with source records, public-safe review, data restrictions, public authority boundaries, finance boundaries, or correction obligations.
6.2.9(f) Suspension shall be used where an activity, access, release, dashboard, map, provider participation, sponsor acknowledgment, public authority reference, data room, technical baseline, public-good software asset, Docket item, Grid item, or interface creates unresolved boundary, evidence, data, cyber, public-safe, finance, procurement, provider, sponsor, or legal risk.
6.2.9(g) Downgrade shall be used where confidence, maturity context, readiness context, public-safe status, classification, compatibility, evidence quality, technical baseline status, Docket status, Grid status, or public claim must be reduced in light of new information, correction, dispute, limitation, or risk.
6.2.9(h) Reinstatement shall be used only where the basis for withdrawal, suspension, downgrade, restriction, or quarantine has been resolved by sufficient record, review, correction, public-safe assessment, data safeguards, cybersecurity controls, and competent authority where applicable.
6.2.9(i) Correction actions shall include downstream dependency review where material, including review of dashboards, maps, reports, data rooms, Academy materials, Docket entries, Grid entries, public authority materials, finance materials, provider materials, sponsor materials, media materials, repositories, APIs, public-good software, technical baselines, and handoff recipients.
6.2.9(j) The controlling rule shall be that every technology record must remain correctable for as long as it can influence understanding, reliance, or action.
6.2.10 Technology-Neutrality Does Not Prevent Technology-Specific Safeguards. 6.2.10(a) Technology-neutral evidence discipline shall not prevent technology-specific safeguards. GCRI Canada may impose additional safeguards, review requirements, methods, classifications, records, restrictions, disclaimers, or correction paths tailored to the distinct risks of a technology or domain.
6.2.10(b) AI-related work may require model governance, dataset governance, model cards, system cards, benchmark cards, inference records, training-use restrictions, human review, hallucination controls, bias and fairness review where applicable, explainability review where appropriate, model-provider review, prompt and output controls, automated decision-support limits, and AI-as-authority disclaimers.
6.2.10(c) AI-RAN, O-RAN, private wireless, telecommunications, edge compute, and remote connectivity work may require spectrum, network security, resilience, interoperability, data localization, sensor integration, public safety, infrastructure sensitivity, provider-neutrality, and operational-boundary safeguards.
6.2.10(d) Blockchain, distributed ledger technology, Web3, smart contracts, tokens, DePIN, proof receipts, and cryptographic infrastructure work may require key management, custody clarity, smart-contract risk review, token and securities perimeter review, proof-receipt authority limits, on-chain/off-chain reconciliation, immutability correction methods, privacy review, and blockchain-as-authority disclaimers.
6.2.10(e) Cybersecurity and cyber-physical work may require vulnerability handling, responsible disclosure, incident response records, evidence preservation, sensitive exploit handling, infrastructure sensitivity review, law-enforcement boundary review, public authority boundary review, and public-safe disclosure controls.
6.2.10(f) Robotics, drones, autonomous systems, sensing, satellite, Earth observation, geospatial, and digital twin work may require safety, airspace, remote sensing, geolocation, sensitive-site protection, public-safe mapping, simulation assumption, sensor calibration, spoofing, image handling, and public warning boundary safeguards.
6.2.10(g) Biosecurity, health-relevant, public health, WEFH, climate, nature, biodiversity, energy, supply-chain, semiconductor, advanced manufacturing, space, strategic infrastructure, and critical infrastructure work may require domain-specific legal review, ethics review, safety review, protected knowledge review, environmental safeguard review, health-sensitive data controls, export-control review, sanctions review, public authority review, and community safeguard review.
6.2.10(h) Technology-specific safeguards shall supplement, not replace, the general rules of source lineage, provenance, custody, classification, confidence, uncertainty, limitations, public-safe review, privacy, data rights, cybersecurity, non-execution, public authority boundary, finance boundary, provider neutrality, sponsor non-control, claims discipline, validity-by-record, and correctionability.
6.2.10(i) Where a technology-specific safeguard conflicts with a general safeguard, the more protective lawful posture shall apply unless a competent legal review determines otherwise.
6.2.10(j) The controlling rule shall be that technology-neutrality sets the common floor; technology-specific safeguards may raise the floor wherever risk requires.
6.3 Technology-Specific Safeguard Profiles
6.3.1 Requirement for Technology-Specific Safeguard Profiles Where Risk Requires. 6.3.1(a) GCRI Canada shall maintain, adopt, reference, or require technology-specific safeguard profiles where a technology, system, infrastructure, dataset, model, method, dashboard, map, technical baseline, public-good software asset, public authority learning material, Docket input, Grid input, Observatory method, Rails handoff, or public-safe publication presents risk that cannot be adequately governed by general technology-neutral evidence discipline alone.
6.3.1(b) A technology-specific safeguard profile shall identify the technology or domain covered, risk classes, evidence requirements, data requirements, AI-use limits, cybersecurity requirements, public-safe review requirements, public authority boundary requirements, finance-boundary requirements, provider-neutrality requirements, sponsor-non-control requirements, IP requirements, community safeguard requirements, protected knowledge controls, export-control or sanctions sensitivity where applicable, records requirements, publication limits, and correction path.
6.3.1(c) Safeguard profiles may be required for technologies or domains that are safety-relevant, public authority-relevant, finance-facing, infrastructure-relevant, cyber-sensitive, data-intensive, AI-assisted, community-facing, sovereignty-relevant, public-warning-adjacent, emergency-management-adjacent, health-relevant, protected-knowledge-relevant, strategically sensitive, controlled-technology-relevant, or capable of creating material reliance risk.
6.3.1(d) A safeguard profile may apply to a class of technology, a specific system, a specific dataset, a specific deployment context, a specific public authority interface, a specific Nexus Observatory node or method, a specific Docket or Grid category, a specific public-safe publication type, or a specific handoff pathway.
6.3.1(e) The absence of a completed safeguard profile shall not authorize unsafe activity. Where risk is material and a technology-specific profile has not yet been completed, GCRI Canada shall apply the most protective lawful interim controls, including hold, restricted access, limited review, public-safe limitation, legal review, data review, cybersecurity review, public authority boundary review, finance-boundary review, or refusal.
6.3.1(f) Safeguard profiles shall not expand GCRI Canada authority. They shall constrain how GCRI Canada researches, evidences, models, observes, compares, tests, documents, stewards, publishes, teaches, hands off, and corrects technology-related work within its non-executing public-good mandate.
6.3.1(g) Safeguard profiles shall be recorded, versioned, reviewed, corrected, superseded, withdrawn, localized, or reissued as the relevant technology, law, public authority context, public-safe risk, data risk, cybersecurity risk, community context, and Nexus doctrine evolve.
6.3.1(h) The controlling rule shall be that technology-specific safeguards are mandatory wherever technology-specific risk requires more than the common evidence floor.
6.3.2 Safeguard Profiles for AI, AI-RAN, O-RAN, Private Wireless, Telecommunications, and Networked Sensing. 6.3.2(a) Safeguard profiles for artificial intelligence, AI-RAN, O-RAN, private wireless, telecommunications, and networked sensing shall address model governance, system governance, dataset governance, network governance, sensor governance, inference governance, signal integrity, public authority relevance, cybersecurity, privacy, lawful data use, operational boundary, and public-safe interpretation.
6.3.2(b) AI safeguard profiles shall address model cards, system cards, dataset cards, benchmark cards, inference records, prompt and output controls, model-provider restrictions, training-use restrictions, retrieval restrictions, human review where material, hallucination risk, bias and fairness review where applicable, explainability where appropriate, evaluation limits, benchmark limits, monitoring limits, and AI-as-authority disclaimers.
6.3.2(c) AI outputs shall not be treated as authority, decision, public warning, emergency command, regulatory finding, procurement approval, finance-readiness, certification, recognition, rating, professional opinion, or execution instruction by default. Any AI-assisted output used by GCRI Canada shall be classified according to source, model, method, human review, confidence, limitations, permitted use, prohibited use, public-safe status, and correction path.
6.3.2(d) AI-RAN, O-RAN, private wireless, telecommunications, and networked sensing safeguard profiles shall address spectrum context where relevant, network ownership, network operator, system integrator, provider role, host role, public authority role, node custody, sensor calibration, signal provenance, signal spoofing, edge inference, data localization, network resilience, uptime claims, safety implications, public warning boundary, emergency command boundary, and operational-control boundary.
6.3.2(e) Network and sensing outputs, including coverage maps, signal records, sensor readings, AI-RAN indicators, O-RAN telemetry, private wireless logs, edge analytics, and dashboard indicators, shall be treated as evidence inputs only unless a competent external actor creates a different lawful effect through its own record.
6.3.2(f) Provider participation in AI, AI-RAN, O-RAN, telecommunications, or sensing work shall require provider-neutrality controls, benchmark controls, test-condition records, conflict records, contribution records, public claims limits, cybersecurity requirements, IP terms, and correction obligations.
6.3.2(g) Public authority-facing materials involving AI, AI-RAN, O-RAN, telecommunications, or sensing shall include capacity classification, non-delegation language, non-warning language, non-command language, non-regulatory-guidance language, public-safe review, and correction path where material.
6.3.2(h) The controlling rule shall be that intelligent, connected, and sensing systems may strengthen evidence, but they shall not become authority through automation, signal density, network centrality, or dashboard visibility.
6.3.3 Safeguard Profiles for Sovereign Compute, Edge Compute, Cloud Compute, HPC, Confidential Computing, and Compute-to-Data. 6.3.3(a) Safeguard profiles for sovereign compute, edge compute, cloud compute, high-performance computing, confidential computing, and compute-to-data shall address compute governance, workload classification, data location, data access, model access, security posture, sovereignty, lawful basis, technical custody, operator responsibility, public-good software use, and correctionability.
6.3.3(b) Compute safeguard profiles shall identify compute owner, operator, custodian, cloud or infrastructure provider, workload steward, data steward, model steward where applicable, jurisdiction, hosting location, cross-border transfer status, encryption controls, access controls, secrets management, logging where lawful and appropriate, incident response, vulnerability handling, and closeout.
6.3.3(c) Compute workload records shall identify workload purpose, data used, model used where applicable, software used, version, configuration, runtime environment, inputs, outputs, retention, permitted use, prohibited use, classification, public-safe status, human review where material, and correction path.
6.3.3(d) Confidential computing and compute-to-data arrangements shall identify what data remains in place, what computation is permitted, what outputs may leave, who may inspect outputs, what AI-use restrictions apply, what logs are preserved, what privacy and sovereignty controls apply, and how errors or unsafe outputs are corrected.
6.3.3(e) Sovereign compute claims shall not imply public authority approval, national endorsement, data sovereignty compliance, security certification, finance-readiness, procurement approval, provider preference, operational clearance, or public authority adoption unless supported by competent source record.
6.3.3(f) GCRI Canada use of compute infrastructure shall not make GCRI Canada the infrastructure operator, cloud provider, telecommunications provider, managed services provider, cybersecurity operator, public authority system operator, or execution actor by default.
6.3.3(g) Compute-related public materials shall distinguish compute evidence, compute workload records, verifiable compute records, technical baseline support, and public-good software use from certification, guarantee, security rating, public authority approval, finance-readiness, procurement approval, or execution.
6.3.3(h) The controlling rule shall be that compute may be sovereign, confidential, high-performance, or edge-distributed, but GCRI Canada’s role remains evidence, methods, safeguards, and records, not compute operation by implication.
6.3.4 Safeguard Profiles for Blockchain, DLT, Web3, DePIN, Proof Infrastructure, Tokenized Records, and On-Chain Anchoring. 6.3.4(a) Safeguard profiles for blockchain, distributed ledger technology, Web3, DePIN, proof infrastructure, tokenized records, smart contracts, proof receipts, cryptographic attestations, and on-chain anchoring shall address key management, custody, identity, authority, off-chain records, on-chain records, correction, privacy, token or securities perimeter, smart-contract risk, proof meaning, and public claims.
6.3.4(b) On-chain records, hashes, anchors, tokens, smart contracts, proof receipts, DePIN records, cryptographic attestations, wallet records, and distributed ledger entries shall not create authority, recognition, certification, finance-readiness, public authority meaning, proof of truth, legal entitlement, procurement approval, provider preference, public warning, emergency command, or execution consequence by default.
6.3.4(c) Any proof infrastructure profile shall distinguish proof of existence, proof of timestamp, proof of custody, proof of submission, proof of method execution, proof of evidence receipt, proof of hash match, proof of role key, proof of entitlement, and proof of competent authority. No proof label shall exceed the authority of its source record.
6.3.4(d) Smart contract and tokenized-record profiles shall require legal perimeter review where token, entitlement, payment, governance, access, security, investment, insurance, public finance, procurement, public authority, or regulated status may be implicated.
6.3.4(e) DePIN profiles shall identify physical infrastructure, device ownership, operator responsibility, provider role, host role, sensor provenance, network integrity, data quality, incentive structure, privacy, cybersecurity, public-safe output limits, and correction path.
6.3.4(f) On-chain immutability shall not defeat correctionability. Where an on-chain or anchored record is wrong, stale, unsafe, overclaimed, restricted, superseded, withdrawn, or reclassified, GCRI Canada shall preserve correction through superseding records, withdrawal notices, public-safe notices, off-chain correction records, updated references, and downstream dependency review.
6.3.4(g) Blockchain, DLT, Web3, DePIN, and proof-related claims shall include blockchain-as-authority, proof-receipt-as-authority, token-as-authority, and smart-contract-as-authority limitations where material.
6.3.4(h) The controlling rule shall be that cryptographic proof may strengthen record integrity, but it shall not create institutional authority or truth beyond the competent record.
6.3.5 Safeguard Profiles for Cybersecurity, Cyber-Physical Systems, Operational Technology, Industrial Control Systems, and Critical Infrastructure. 6.3.5(a) Safeguard profiles for cybersecurity, cyber-physical systems, operational technology, industrial control systems, critical infrastructure, infrastructure telemetry, vulnerability information, incident evidence, and resilience systems shall address security sensitivity, lawful handling, public authority boundaries, disclosure limits, evidence preservation, operational boundaries, and public-safe communication.
6.3.5(b) Cybersecurity profiles shall address vulnerability reporting, responsible disclosure, exploit handling, threat intelligence classification, incident records, evidence custody, forensic limits, system access, privileged information, log handling, malware or exploit containment, public-safe disclosure, law enforcement boundary, regulator boundary, and emergency command boundary.
6.3.5(c) Cyber-physical, operational technology, industrial control, and critical infrastructure profiles shall address safety, uptime, operational risk, infrastructure sensitivity, physical security, operator authority, provider responsibility, host responsibility, utility responsibility, public authority responsibility, incident escalation, and no-operational-control language.
6.3.5(d) GCRI Canada shall not act as law enforcement, regulator, emergency commander, public warning authority, managed security service provider, incident commander, infrastructure operator, forensic authority, or operational decision-maker by default through cybersecurity or critical infrastructure work.
6.3.5(e) Cyber incident findings, vulnerability notes, threat summaries, resilience dashboards, infrastructure maps, and operational risk outputs shall not become public authority findings, official warnings, enforcement positions, insurance ratings, credit ratings, procurement determinations, or operational commands by default.
6.3.5(f) Cyber and infrastructure materials shall be classified and published only after public-safe review addressing harm from disclosure, exploitability, sensitive infrastructure exposure, public panic risk, public authority confusion, provider misuse, sponsor misuse, media misuse, and downstream operational reliance.
6.3.5(g) Where cybersecurity or critical infrastructure evidence is corrected, superseded, withdrawn, restricted, or reclassified, GCRI Canada shall consider downstream notice to affected public authorities, operators, providers, hosts, GRA, GRF, Protocol Authority, or other competent actors where appropriate and lawful.
6.3.5(h) The controlling rule shall be that cyber and infrastructure evidence must improve resilience without creating unsafe disclosure, false authority, or operational control.
6.3.6 Safeguard Profiles for Robotics, Drones, Autonomous Systems, Remote Operations, and Field Automation. 6.3.6(a) Safeguard profiles for robotics, drones, autonomous systems, remote operations, field automation, unmanned systems, autonomous sensing, autonomous logistics, and automated field tools shall address safety, lawful operation, operator responsibility, public authority boundaries, public-safe mapping, data capture, cybersecurity, human oversight, and no-command controls.
6.3.6(b) Such profiles shall identify system owner, operator, provider, host, field team, deployment context, safety rules, airspace or mobility restrictions where applicable, site access, insurance, liability, data capture, sensor capture, geolocation sensitivity, privacy, cybersecurity, remote-control access, autonomy level, human oversight, incident response, and correction path.
6.3.6(c) GCRI Canada may study, observe, test, benchmark, document, model, or develop methods concerning robotics, drones, autonomous systems, and field automation, but shall not operate, dispatch, deploy, command, maintain, guarantee, insure, procure, certify, approve, or control such systems by default.
6.3.6(d) Field automation outputs, including imagery, sensor records, route records, inspection records, hazard observations, infrastructure observations, environmental observations, and digital twin inputs, shall be treated as evidence subject to source lineage, calibration or system context, custody, classification, public-safe review, and correction.
6.3.6(e) Autonomous-system demonstrations, pilots, validation sprints, simulations, or tests shall not create certification, procurement approval, provider preference, public authority approval, deployment authorization, operational clearance, public warning, emergency command, or execution authority by default.
6.3.6(f) Where robotics, drones, or autonomous systems operate in community, Indigenous, public authority, emergency, health, infrastructure, environmental, or sensitive-location contexts, heightened privacy, public-safe, safety, protected knowledge, and public authority boundary controls shall apply.
6.3.6(g) Public materials concerning robotics, drones, autonomous systems, or field automation shall not imply GCRI Canada operation, command, deployment approval, safety certification, public authority endorsement, emergency readiness, or provider preference unless competent source records support the claim.
6.3.6(h) The controlling rule shall be that autonomous and field systems may produce evidence, but GCRI Canada shall not become the field operator by studying or evidencing them.
6.3.7 Safeguard Profiles for Sensors, Earth Observation, Satellite, Geospatial Intelligence, Public-Safe Mapping, and Remote Sensing. 6.3.7(a) Safeguard profiles for sensors, Earth observation, satellite systems, geospatial intelligence, public-safe mapping, remote sensing, imagery, location intelligence, environmental sensing, infrastructure sensing, and map-based outputs shall address source lineage, spatial accuracy, temporal accuracy, sensitive location protection, privacy, sovereignty, public authority meaning, public warning boundary, and public-safe visualization.
6.3.7(b) Such profiles shall identify sensor source, satellite source, imagery source, collection date, resolution, coverage, processing steps, model use, calibration, geolocation precision, uncertainty, limitations, custody, license, data classification, publication limits, map generalization, dashboard limits, and correction path.
6.3.7(c) Geospatial and remote-sensing outputs shall not become official hazard notices, public warnings, evacuation instructions, public authority decisions, regulatory findings, procurement determinations, insurance ratings, credit ratings, public finance approvals, or operational commands by default.
6.3.7(d) Public-safe mapping controls shall prevent exposure of sensitive homes, critical infrastructure, public safety facilities, sacred sites, culturally sensitive places, protected habitats, vulnerable communities, health-sensitive locations, security-sensitive locations, protected knowledge, and other locations where mapping could create harm.
6.3.7(e) Public authority-facing maps, dashboards, hazard layers, climate layers, infrastructure layers, community layers, or disaster-related visualizations shall include capacity classification, non-warning language, non-command language, non-public-authority-decision language, limitations, confidence, uncertainty, and correction path where material.
6.3.7(f) Community-facing or public-facing maps shall be reviewed for accessibility, language, cultural safety, stigma, retaliation risk, public panic risk, sensitive location exposure, and potential misuse by sponsors, providers, media, public authorities, finance actors, or third parties.
6.3.7(g) Where geospatial evidence is corrected, reprocessed, superseded, withdrawn, downgraded, generalized, restricted, or reclassified, GCRI Canada shall review affected maps, dashboards, public-safe reports, public authority materials, data rooms, and derivative claims.
6.3.7(h) The controlling rule shall be that maps and sensing outputs may make risk visible, but they shall not become official action or unsafe exposure.
6.3.8 Safeguard Profiles for Digital Twins, Simulation Systems, Scenario Engines, and Model-Based Evidence. 6.3.8(a) Safeguard profiles for digital twins, simulation systems, scenario engines, model-based evidence, synthetic environments, system dynamics models, climate models, infrastructure models, AI-assisted models, and decision-support models shall address assumptions, input data, model limits, validation status, scenario framing, uncertainty, public-safe interpretation, and non-authority boundaries.
6.3.8(b) Digital twin and simulation profiles shall identify model owner, steward, version, scope, system boundary, input data, assumptions, calibration, validation status, scenario conditions, time horizon, uncertainty, sensitivity, limitations, human review, data classification, public-safe status, permitted use, prohibited use, and correction path.
6.3.8(c) Digital twin outputs, simulations, scenario results, forecasts, projections, modeled losses, modeled resilience, modeled hazard exposure, modeled public health implications, modeled infrastructure impacts, or modeled finance implications shall not constitute official predictions, public warnings, emergency commands, regulatory findings, public authority determinations, investment advice, underwriting, ratings, public finance approvals, guarantees, procurement approvals, or execution instructions by default.
6.3.8(d) Scenario outputs shall be labeled as scenario outputs. Modeled evidence shall be labeled as modeled evidence. Simulated evidence shall be labeled as simulated evidence. Synthetic evidence shall be labeled as synthetic evidence. No modeled output shall be presented as direct observation unless the record supports such treatment.
6.3.8(e) Digital twin and simulation materials used in public authority learning shall include non-delegation, non-warning, non-command, non-official-guidance, non-procurement, non-public-finance-approval, non-professional-advice, and correction language where material.
6.3.8(f) Digital twin and simulation materials used in finance-facing contexts shall include no-investment-advice, no-underwriting, no-rating, no-guarantee, no-public-finance-approval, no-capital-commitment, and no-GCRI-Canada-finance-readiness language where material.
6.3.8(g) Where assumptions, inputs, model structure, validation status, or limitations change materially, GCRI Canada shall review whether outputs, dashboards, maps, public-safe reports, Docket inputs, Grid inputs, Academy materials, and handoffs require correction, supersession, withdrawal, or reclassification.
6.3.8(h) The controlling rule shall be that models can illuminate possible futures, but they shall not decide the future or authorize action.
6.3.9 Safeguard Profiles for Quantum-Relevant and Cryptographic Transition-Relevant Systems. 6.3.9(a) Safeguard profiles for quantum-relevant systems, post-quantum transition, cryptographic infrastructure, key management, secure communications, quantum sensing where applicable, and cryptographic transition-relevant systems shall address security sensitivity, transition risk, algorithm status, key custody, interoperability, public authority relevance, export-control sensitivity, and public claims discipline.
6.3.9(b) Such profiles shall identify system type, cryptographic dependency, algorithm or protocol status, standards reference where applicable, transition timeline where known, vulnerability status, key management, custody, implementation context, interoperability requirements, public authority context, provider role, data sensitivity, cybersecurity obligations, public-safe status, and correction path.
6.3.9(c) GCRI Canada may study, compare, evidence, model, document, teach, or develop methods concerning quantum-relevant and cryptographic transition systems, but shall not certify cryptographic security, approve systems for public authority use, issue procurement requirements, guarantee resilience, operate secure infrastructure, or provide regulated professional security assurance by default.
6.3.9(d) Cryptographic transition claims shall not imply certification, conformance, security guarantee, public authority approval, procurement readiness, finance-readiness, protocol effect, provider preference, or operational clearance unless supported by competent record.
6.3.9(e) Public-good software, test harnesses, evaluation tools, reference architectures, or technical baselines concerning cryptographic transition shall include limitation language, security review status, dependency notes, vulnerability reporting, supersession path, and correction path.
6.3.9(f) Sensitive cryptographic, security, or vulnerability information shall be classified and published only through public-safe and cybersecurity review, with responsible disclosure and protected handling where appropriate.
6.3.9(g) Where quantum-relevant or cryptographic transition evidence changes due to new standards, vulnerabilities, attacks, implementation findings, public authority guidance, or technical corrections, GCRI Canada shall update, supersede, restrict, withdraw, or correct affected materials where within its stewardship.
6.3.9(h) The controlling rule shall be that cryptographic transition work must improve preparedness without creating false assurance or unsafe disclosure.
6.3.10 Safeguard Profiles for Biosecurity, Health, Public Health, WEFH Systems, and Health-Sensitive Data. 6.3.10(a) Safeguard profiles for biosecurity, health, public health, WEFH systems, health-sensitive data, biological risk evidence, epidemiological context, food-system risk, water-system risk, environmental health, and health-adjacent technologies shall address ethics, health-sensitive data, public authority boundaries, public warning boundaries, public health order boundaries, privacy, community safeguards, protected knowledge, and do-no-harm.
6.3.10(b) Such profiles shall identify whether information is research evidence, health-sensitive information, public health data, environmental health data, community health context, biosecurity-sensitive information, public authority data, clinical information, modeled evidence, scenario evidence, public-safe summary, controlled annex, or not-for-public-release material.
6.3.10(c) GCRI Canada shall not provide clinical advice, medical advice, public health orders, official public health guidance, emergency commands, official warnings, regulatory determinations, insurance determinations, health system approvals, biosecurity authorizations, or professional health opinions by default.
6.3.10(d) Health-sensitive and biosecurity-related materials shall require heightened public-safe review to prevent public panic, stigma, retaliation, privacy harm, unsafe health inference, misinformation, public authority confusion, emergency command confusion, public warning confusion, protected knowledge exposure, and misuse by sponsors, providers, media, finance actors, or public authorities.
6.3.10(e) WEFH-related profiles shall address interdependence among water, energy, food, health, climate, infrastructure, community, and public authority systems, including cascading risk, data sensitivity, community impacts, public-safe mapping, and scenario limitations.
6.3.10(f) Community and Indigenous knowledge relevant to health, environment, water, food, ecological systems, or biosecurity shall be protected through consent or non-consent treatment where applicable, cultural protocols, non-extraction, sensitive location controls, attribution or non-attribution, grievance, remedy, and correction path.
6.3.10(g) Public authority-facing materials in health or biosecurity contexts shall include capacity classification and explicit language that GCRI Canada does not issue official health guidance, public health orders, public warnings, emergency commands, regulatory approvals, or public authority decisions.
6.3.10(h) The controlling rule shall be that health and biosecurity evidence must support public-benefit learning without becoming medical authority, public health authority, or unsafe public signal.
6.3.11 Safeguard Profiles for Climate, Nature, Biodiversity, Disaster, Energy, Water, Food, and Infrastructure Continuity. 6.3.11(a) Safeguard profiles for climate, nature, biodiversity, disaster, energy, water, food, and infrastructure continuity shall address systemic risk, cascading failures, public-safe mapping, public authority boundaries, finance-facing sensitivity, community safeguards, ecological knowledge, critical infrastructure, scenario uncertainty, and resilience evidence.
6.3.11(b) Such profiles shall identify hazard type, system boundary, data source, model source, scenario assumptions, geographic scope, temporal scope, public authority context, community context, ecological context, infrastructure context, energy or WEFH interdependencies, confidence, uncertainty, limitations, public-safe classification, and correction path.
6.3.11(c) Climate, nature, biodiversity, disaster, energy, water, food, and infrastructure evidence shall not become official hazard notice, evacuation instruction, emergency command, public authority determination, regulatory finding, insurance rating, credit rating, investment rating, public finance approval, procurement approval, guarantee, or execution instruction by default.
6.3.11(d) Disaster-related outputs, including wildfire, flood, heat, storm, drought, air quality, infrastructure failure, water safety, food system, energy security, and cascading-risk materials, shall require public-safe review where they may affect public perception, public authority interpretation, emergency management, finance-facing reliance, insurance-facing reliance, community safety, or media use.
6.3.11(e) Nature and biodiversity materials shall address protected species, protected habitats, sensitive locations, Indigenous and local ecological knowledge, land stewardship, community safeguards, public-safe mapping, data sovereignty, non-extraction, and do-no-harm.
6.3.11(f) Energy and infrastructure continuity materials shall address critical infrastructure sensitivity, operational boundaries, utility responsibility, public authority responsibility, provider responsibility, cyber-physical risk, public warning boundary, emergency command boundary, and no-operational-control language.
6.3.11(g) Finance-facing resilience evidence shall include no-underwriting, no-rating, no-insurance-approval, no-public-finance-approval, no-investment-advice, no-guarantee, and no-GCRI-Canada-finance-readiness language where material.
6.3.11(h) The controlling rule shall be that resilience evidence may support learning and preparedness, but it shall not become official warning, finance approval, insurance rating, or operational command.
6.3.12 Safeguard Profiles for Semiconductors, Advanced Manufacturing, Supply Chains, Strategic Materials, Industrial Resilience, and Critical Production. 6.3.12(a) Safeguard profiles for semiconductors, advanced manufacturing, supply chains, strategic materials, industrial resilience, critical production, logistics, industrial data, manufacturing systems, and production-related infrastructure shall address supply-chain sensitivity, export control, sanctions, controlled technology, cybersecurity, IP, industrial confidentiality, public authority relevance, competition safety, and finance-facing risk.
6.3.12(b) Such profiles shall identify technology class, production context, supply-chain dependency, strategic material dependency, supplier data, provider data, host data, public authority data, industrial confidentiality, IP status, export-control sensitivity, sanctions sensitivity, controlled-technology sensitivity, cyber-physical risk, resilience evidence, and correction path.
6.3.12(c) GCRI Canada may research, evidence, map, model, compare, document, teach, and correct supply-chain, manufacturing, semiconductor, and industrial resilience evidence, but shall not allocate supply, direct production, procure vendors, approve suppliers, certify factories, guarantee resilience, recommend investments, approve public finance, or operate industrial systems by default.
6.3.12(d) Supply-chain maps, strategic-material assessments, production-risk summaries, industrial resilience dashboards, supplier evidence, and manufacturing-readiness evidence shall be reviewed for competition sensitivity, confidentiality, security, market signaling, procurement implication, public authority implication, finance implication, and public-safe status.
6.3.12(e) Provider and supplier participation shall not create preferred status, procurement advantage, certification, recognition, finance-readiness, public authority approval, market superiority, or technical supremacy by default.
6.3.12(f) Export-control, sanctions, and controlled-technology review shall be required where technology, data, software, designs, methods, suppliers, jurisdictions, or recipients may trigger legal restrictions or public trust risk.
6.3.12(g) Where industrial or supply-chain evidence is used in finance-facing, procurement-facing, public authority-facing, or provider-facing contexts, boundary language and public claims controls shall travel with the record.
6.3.12(h) The controlling rule shall be that strategic industrial evidence may improve resilience understanding, but it shall not become procurement direction, market allocation, finance approval, or industrial command.
6.3.13 Safeguard Profiles for Space, NTN, Remote Connectivity, Ports, Corridors, Remote Communities, Rural Systems, Arctic / Northern Contexts, and Mission-Critical Infrastructure. 6.3.13(a) Safeguard profiles for space systems, non-terrestrial networks, remote connectivity, ports, corridors, remote communities, rural systems, Arctic and northern contexts, coastal systems, transport corridors, logistics corridors, and mission-critical infrastructure shall address sovereignty, remoteness, public authority context, community safeguards, Indigenous and local knowledge, environmental sensitivity, communications resilience, security sensitivity, and operational boundary.
6.3.13(b) Space and non-terrestrial network profiles shall identify satellite systems, ground stations, operators, providers, data sources, communications dependencies, jurisdictional context, public authority relevance, remote sensing implications, cybersecurity obligations, spectrum or network considerations where relevant, public-safe status, and correction path.
6.3.13(c) Remote connectivity profiles shall address connectivity gaps, resilience needs, community context, service providers, host infrastructure, emergency-adjacent use, public authority learning, privacy, data sovereignty, public-safe communication, operational responsibility, and no-provider-preference language.
6.3.13(d) Ports, corridors, and mission-critical infrastructure profiles shall address infrastructure sensitivity, cyber-physical dependencies, logistics continuity, public authority context, public-private interface risk, safety, security, supply-chain relevance, operational boundaries, public-safe mapping, finance-facing sensitivity, and correction path.
6.3.13(e) Remote community, rural, Arctic, northern, Indigenous, coastal, or isolated-system profiles shall require heightened safeguards for community participation, Indigenous and local knowledge, data sovereignty, language, accessibility, non-extraction, protected knowledge, environmental sensitivity, public-safe mapping, and do-no-harm.
6.3.13(f) GCRI Canada shall not become a telecommunications operator, satellite operator, port operator, corridor manager, utility operator, emergency command body, public warning authority, infrastructure operator, public authority, provider selector, procurement actor, finance actor, or execution actor by virtue of working on remote connectivity or mission-critical infrastructure evidence.
6.3.13(g) Public materials involving remote communities, corridors, Arctic or northern systems, ports, strategic infrastructure, or connectivity shall be reviewed for sensitive location exposure, public authority confusion, security risk, community harm, sovereignty implications, finance overclaim, procurement implication, and provider preference.
6.3.13(h) The controlling rule shall be that remote and mission-critical infrastructure work must support resilience without extracting community knowledge, exposing sensitive systems, or assuming operational authority.
6.3.14 Review, Versioning, Public-Safe Status, and Correction of Safeguard Profiles. 6.3.14(a) Technology-specific safeguard profiles shall be reviewed, versioned, classified, approved, stored, updated, corrected, superseded, withdrawn, localized, or reissued according to law, the Bylaw, this Charter, repository discipline, public-safe requirements, technical review, legal review, data review, cybersecurity review, public authority boundary review, finance-boundary review, community safeguard review, and risk classification.
6.3.14(b) Each safeguard profile shall identify title, covered technology or domain, version, effective date, steward, approving authority where applicable, scope, exclusions, risk classes, required records, required reviews, required disclaimers, publication status, public-safe status, data classification, AI-use classification, cybersecurity classification, public authority sensitivity, finance sensitivity, correction path, supersession path, and re-review trigger.
6.3.14(c) Re-review shall occur where there is material technology change, legal change, public authority notice, security vulnerability, data incident, public-safe incident, public claims overreach, community harm, protected knowledge issue, finance overclaim, provider overclaim, sponsor overclaim, new evidence, method correction, public authority boundary issue, or Nexus doctrine update.
6.3.14(d) Public-safe status shall identify whether the profile may be public, public-safe summarized, controlled, restricted, confidential, under review, quarantined, superseded, withdrawn, or not for reliance.
6.3.14(e) Where a safeguard profile is corrected, superseded, withdrawn, or restricted, GCRI Canada shall review affected programs, public materials, technical baselines, public-good software, dashboards, maps, Academy materials, Docket inputs, Grid inputs, Observatory methods, Rails handoffs, interface instruments, public authority materials, finance-facing materials, provider materials, sponsor materials, and public claims for dependency updates.
6.3.14(f) Safeguard profiles may be localized for Canadian, regional, national, Indigenous, community, public authority, sectoral, or infrastructure contexts, provided that localization does not lower required safeguards unless lawful, justified, recorded, and public-safe.
6.3.14(g) Where no current profile adequately covers an emerging technology or risk, GCRI Canada shall use interim controls and shall not make strong public claims, finance-facing claims, public authority-facing claims, certification-like claims, recognition-like claims, or execution-adjacent claims until the profile or equivalent record is adequate.
6.3.14(h) The controlling rule shall be that safeguard profiles are living instruments: reviewed as technology changes, corrected when wrong, strengthened when risk grows, and never used to weaken the Charter’s general safeguards.
6.4 Artificial Intelligence, Machine Learning, Foundation Models, and Agentic AI
6.4.1 AI as a Core Technology Domain of GCRI Canada. 6.4.1(a) Artificial intelligence shall be a core technology domain within GCRI Canada’s public-benefit, non-executing, evidence, methods, observability, ontology, public-good R&D, public-good software, open technical-baseline, public authority learning, public-safe publication, and correctionability mandate.
6.4.1(b) GCRI Canada may research, evidence, evaluate, compare, document, model, observe, teach, steward, publish, route, and correct AI-related evidence, methods, safeguards, technical baselines, public-good software, governance patterns, evaluation frameworks, model records, dataset records, benchmark records, inference records, system records, public authority learning materials, and public-safe reports.
6.4.1(c) AI within GCRI Canada’s scope may include classical machine learning, statistical learning, deep learning, foundation models, generative AI, multimodal AI, retrieval-augmented systems, agentic AI, autonomous or semi-autonomous systems, AI decision-support systems, AI-enabled cyber systems, AI-enabled sensing systems, AI-RAN systems, AI-enabled digital twins, AI-enabled public-safe dashboards, and other emerging AI-enabled systems.
6.4.1(d) GCRI Canada’s AI mandate shall include AI governance, AI safety, AI assurance, AI evaluation, AI red-teaming, AI monitoring, AI incident learning, AI public-safe publication, AI literacy, AI model-record discipline, AI dataset-record discipline, AI inference-record discipline, and AI correctionability.
6.4.1(e) GCRI Canada’s AI mandate shall not authorize GCRI Canada to regulate AI, certify AI by default, approve AI systems for public authority use, procure AI systems, select AI vendors, provide investment advice concerning AI systems, underwrite AI systems, rate AI systems, insure AI systems, operate AI systems for downstream execution, deploy AI systems into public authority functions, issue public warnings through AI outputs, or treat AI outputs as authority by default.
6.4.1(f) AI work involving public authorities, capital readers, sponsors, providers, hosts, communities, universities, National Consortium Companies, Project SPVs, or Nexus actors shall preserve role separation, capacity classification, provider neutrality, sponsor non-control, finance-boundary safety, public authority boundary safety, public-safe review, data safeguards, cybersecurity, and correction paths.
6.4.1(g) AI shall be treated as a powerful evidence and methods domain, not as an institutional substitute for lawful authority, human accountability, public authority decision-making, GRF recognition, GRA finance-readiness, Protocol Authority effect, professional advice, procurement, certification, or execution.
6.4.1(h) The controlling rule shall be that AI may assist GCRI Canada’s public-good truth work, but AI shall not become the truth authority.
6.4.2 Machine Learning, Statistical Learning, Foundation Models, Generative AI, Agentic AI, and Automated Decision-Support Systems. 6.4.2(a) GCRI Canada’s AI scope shall include machine learning, statistical learning, foundation models, generative AI, multimodal models, retrieval systems, classification systems, prediction systems, ranking systems, recommendation systems, anomaly-detection systems, agentic AI, automated workflow systems, and automated decision-support systems.
6.4.2(b) Machine learning and statistical learning work may include evidence concerning model purpose, training data, evaluation data, performance limits, bias, uncertainty, drift, validation status, interpretability, calibration, deployment context, public-safe use, and correction history.
6.4.2(c) Foundation model and generative AI work may include evidence concerning model provenance, provider terms, model capability, limitation, hallucination risk, benchmark limits, prompting, retrieval, tool access, generated content controls, data leakage risk, safety filters, misuse risk, public-safe publication, and human review.
6.4.2(d) Agentic AI work may include evidence concerning tool permissions, planning behavior, autonomy level, action boundaries, approval gates, execution restrictions, logs, escalation paths, kill switches, monitoring, incident response, and prohibition of unauthorized public authority, finance, procurement, operational, or execution actions.
6.4.2(e) Automated decision-support systems shall be treated as support systems only unless a competent external authority lawfully creates a decision-making role through its own process and record. GCRI Canada shall not use automated decision-support to make public authority decisions, finance decisions, procurement decisions, provider-selection decisions, certification decisions, recognition decisions, protocol-effect decisions, professional opinions, public warnings, emergency commands, or execution decisions by default.
6.4.2(f) AI systems used, studied, evaluated, or referenced by GCRI Canada shall be classified by role, including whether they are used for internal drafting support, evidence classification, summarization, retrieval, translation, coding assistance, data analysis, anomaly detection, scenario generation, public-safe publication support, dashboard support, or controlled technical evaluation.
6.4.2(g) Where an AI system’s role, training use, data use, provider terms, output status, or tool permissions are unclear, GCRI Canada shall apply the most restrictive safe posture until the record is clarified.
6.4.2(h) The controlling rule shall be that different AI forms require different safeguards, but all remain subject to the same non-execution and correctionability floor.
6.4.3 AI Governance, AI Safety, AI Assurance, AI Evaluation, AI Red-Teaming, AI Monitoring, and AI Incident Learning. 6.4.3(a) GCRI Canada may conduct, support, document, teach, and steward AI governance, AI safety, AI assurance, AI evaluation, AI red-teaming, AI monitoring, and AI incident learning within its non-executing public-good mandate.
6.4.3(b) AI governance work may include policies, method profiles, system records, model registers, risk classifications, data-use controls, human-review requirements, access controls, accountability mappings, public-safe review, model-provider review, tool-permission review, audit-readiness, and correction procedures.
6.4.3(c) AI safety and assurance work may include evaluation methods, benchmark methods, red-team methods, misuse testing, robustness testing, privacy testing, data-leakage review, hallucination review, bias and fairness review where applicable, security review, prompt-injection review, tool-use review, agentic behavior review, and incident-learning records.
6.4.3(d) AI evaluation and red-teaming performed by or with GCRI Canada shall not constitute certification, conformance determination, public authority approval, procurement approval, provider endorsement, finance-readiness, insurance approval, underwriting approval, rating, guarantee, operational clearance, or deployment authorization by default.
6.4.3(e) AI monitoring and incident learning shall identify observed issue, source, system, model, data, trigger, effect, severity, impacted records, public-safe risk, data risk, cybersecurity risk, public authority risk, finance risk, provider or sponsor risk, corrective action, dependency review, and closeout.
6.4.3(f) AI incident learning shall not substitute for legal incident response, cybersecurity incident response, public authority incident response, emergency command, public warning, regulatory notification, professional advice, or operational response by competent actors.
6.4.3(g) Where AI governance, safety, assurance, evaluation, red-teaming, monitoring, or incident-learning outputs are externally shared, they shall include scope, method, limitations, non-certification status, non-endorsement status, non-procurement status, non-finance-readiness status, non-public-authority-approval status, and correction path.
6.4.3(h) The controlling rule shall be that AI assurance work may improve confidence in evidence, but it shall not create authority beyond the record.
6.4.4 Model Registers, Model Cards, Dataset Cards, System Cards, Benchmark Cards, Evaluation Harnesses, and Inference Records. 6.4.4(a) GCRI Canada may create, maintain, require, receive, review, route, publish in public-safe form, or correct model registers, model cards, dataset cards, system cards, benchmark cards, evaluation harnesses, test harnesses, inference records, compute workload records, AI-use records, and related AI governance records.
6.4.4(b) A model register shall identify model name, provider or steward, version, purpose, permitted use, prohibited use, model type, access mode, hosting context, data-use terms, training restrictions, output status, evaluation status, risk classification, public-safe status, review status, and correction path.
6.4.4(c) A model card shall identify model purpose, capabilities, limitations, training context where available, evaluation results, known risks, bias or fairness considerations where applicable, security limitations, hallucination risk, tool-use restrictions, public-safe limits, suitable and unsuitable uses, and correction path.
6.4.4(d) A dataset card shall identify dataset source, lawful basis where applicable, contributor authority, data classification, rights-bearing data status, public authority data status, sovereign data status, community or protected knowledge status, collection method, limitations, permitted use, prohibited use, AI-use restrictions, retention, transfer, publication limits, and correction path.
6.4.4(e) A system card shall identify the AI system, model components, retrieval components, tools, APIs, data sources, user roles, access controls, workflow, human review, monitoring, logs, incident procedures, output limits, public-safe controls, cybersecurity controls, and correction path.
6.4.4(f) A benchmark card shall identify benchmark purpose, method, dataset, test conditions, assumptions, limitations, conflicts, provider participation, sponsor participation, reproducibility where appropriate, public claims limits, non-certification status, non-procurement status, non-ranking status unless expressly authorized, and correction path.
6.4.4(g) An inference record shall identify input category, output category, model, version, prompt or query treatment where material, retrieval source where material, tool use, date, reviewer where material, confidence where appropriate, limitations, classification, public-safe status, permitted use, prohibited use, and correction path.
6.4.4(h) Evaluation and test harnesses shall identify scope, method, input data, output treatment, model or system under test, test conditions, limitations, public-safe status, security review, IP status, non-certification status, and correction path.
6.4.4(i) AI governance records shall not create certification, provider endorsement, public authority approval, finance-readiness, procurement readiness, protocol effect, professional advice, public warning, emergency command, guarantee, rating, underwriting, or execution authority by default.
6.4.4(j) The controlling rule shall be that AI systems become institutionally usable only when their records make their purpose, limits, safeguards, and correction path legible.
6.4.5 AI Outputs as Evidence Inputs or Analytical Outputs, Not Authority by Default. 6.4.5(a) AI outputs used, generated, received, reviewed, routed, summarized, visualized, mapped, dashboarded, published, or archived by GCRI Canada shall be treated as evidence inputs, analytical outputs, drafting aids, classification aids, retrieval aids, scenario aids, or methods-support outputs, not authority by default.
6.4.5(b) AI outputs shall not constitute public authority decisions, official guidance, regulatory findings, procurement approvals, public finance approvals, public warnings, emergency commands, GRF recognition, GRA finance-readiness, Protocol Authority effect, certification, provider endorsement, sponsor approval, investment advice, lending approval, insurance advice, underwriting, rating, guarantee, professional opinion, operational clearance, deployment authorization, market approval, or execution instruction by default.
6.4.5(c) AI outputs shall be classified according to source, model, provider, version where known, data used, retrieval sources, prompt or instruction context where material, tool use, human review status, confidence where appropriate, uncertainty, limitations, public-safe status, permitted use, prohibited use, and correction path.
6.4.5(d) AI outputs shall not be represented as observed fact, independent evidence, verified evidence, official truth, public authority position, public-safe conclusion, finance-readable conclusion, technical baseline, benchmark result, Docket status, Grid status, or Academy outcome unless the relevant review and source record support the statement.
6.4.5(e) AI-generated summaries shall preserve source limitations and shall not remove uncertainty, public-safe restrictions, finance-safe restrictions, public authority boundaries, protected knowledge limits, data classifications, or correction obligations.
6.4.5(f) AI-generated classifications shall be subject to human review where material to public claims, public authority meaning, finance-facing meaning, procurement-facing meaning, provider status, sponsor status, community safeguards, protected knowledge, data rights, or cybersecurity.
6.4.5(g) Where AI outputs are externally shared, the material shall state AI-use status where material and shall include boundary language sufficient to prevent AI-as-authority, dashboard-as-authority, model-as-authority, or automated-decision overclaim.
6.4.5(h) The controlling rule shall be that AI may produce useful outputs, but those outputs acquire institutional meaning only through proper record, review, and authority.
6.4.6 Human Review for Material AI Outputs. 6.4.6(a) Human review shall be required for material AI outputs before such outputs are used in public-facing, public authority-facing, finance-facing, procurement-facing, provider-facing, sponsor-facing, community-facing, media-facing, legal, policy, technical-baseline, Docket, Grid, Observatory, Rails, Academy, or correction contexts where reliance risk exists.
6.4.6(b) Human review shall be proportionate to risk and may include subject-matter review, legal review, public-safe review, data review, AI governance review, cybersecurity review, public authority boundary review, finance-boundary review, provider-neutrality review, sponsor-non-control review, community safeguard review, protected knowledge review, and correction review.
6.4.6(c) Material AI outputs include outputs that classify evidence, summarize sensitive records, identify risk, generate public-safe text, produce dashboard or map labels, support Docket or Grid status, support public authority learning, support finance-facing materials, describe providers, describe sponsors, describe public authorities, describe communities, interpret law or regulation, describe health or public safety matters, identify incidents, or influence external communications.
6.4.6(d) Human review shall assess source support, factual accuracy, hallucination risk, missing context, overclaim, underclaim, bias, unsafe framing, data leakage, protected knowledge exposure, public authority confusion, finance overclaim, procurement implication, certification implication, recognition implication, provider preference, sponsor control, public-safe risk, and correction path.
6.4.6(e) Human review records shall identify reviewer, date, scope, source materials reviewed, AI system used where material, output status, changes made, limitations retained, boundary language added, public-safe classification, permitted use, prohibited use, and correction path.
6.4.6(f) Human review shall not be a mere formality. Where the reviewer cannot verify source support, cannot assess limitations, lacks appropriate competence, identifies material uncertainty, or detects boundary risk, the output shall be revised, restricted, escalated, held, quarantined, or rejected.
6.4.6(g) Where AI outputs concern high-risk domains, including public authority action, finance, public safety, emergency management, health, cybersecurity, infrastructure, protected knowledge, or community harm, heightened human review shall be required before reliance or release.
6.4.6(h) The controlling rule shall be that material AI outputs require accountable human review before they affect institutional meaning.
6.4.7 Agentic AI Tool Permissions, Logs, Approval Gates, Prohibited Actions, Kill Switches, and Incident Procedures. 6.4.7(a) Agentic AI systems used, tested, evaluated, or referenced by GCRI Canada shall require tool permissions, logs, approval gates, prohibited action lists, kill switches or equivalent interruption controls where applicable, monitoring, incident procedures, and correction paths proportionate to autonomy and risk.
6.4.7(b) Tool permissions shall identify what tools, repositories, dashboards, APIs, data rooms, models, files, communication systems, publication systems, code systems, workflow systems, or external systems the agent may access; what actions it may take; what actions require human approval; and what actions are prohibited.
6.4.7(c) Approval gates shall be required for any agentic action that could affect public materials, data disclosure, repository modification, publication, public authority communication, finance-facing communication, provider-facing communication, sponsor-facing communication, community-facing communication, external handoff, access permission, correction record, Docket status, Grid status, technical baseline, public-good software release, or cybersecurity posture.
6.4.7(d) Prohibited actions shall include issuing public warnings, making emergency commands, making public authority decisions, approving procurement, recommending investments, soliciting capital, approving finance, binding GCRI Canada, binding another actor, selecting providers, certifying systems, issuing recognition, creating protocol effect, sending unauthorized external communications, publishing without approval, disclosing restricted data, overriding access controls, modifying authoritative records without authority, or executing operational tasks outside authorized scope.
6.4.7(e) Logs shall record agent identity, model or system used, user or operator, prompt or instruction context where material, tools accessed, data accessed, actions attempted, actions completed, approval gates triggered, denials, errors, escalations, outputs, human reviewer, and correction or rollback actions where material.
6.4.7(f) Kill switches or equivalent interruption controls shall be available where agentic activity could materially affect records, systems, public materials, data, communications, cybersecurity, public authority interfaces, finance-facing interfaces, or external actors.
6.4.7(g) Agentic AI incidents shall be recorded, classified, escalated, corrected, and reviewed, including unauthorized access, unauthorized action, unsafe output, hallucinated authority, data leakage, tool misuse, prompt injection, policy bypass, public-safe risk, cyber risk, public authority confusion, finance overclaim, provider or sponsor impact, and downstream dependency.
6.4.7(h) The controlling rule shall be that agentic AI may assist bounded workflows only where tools, approvals, logs, interruption, and accountability are stronger than the autonomy granted.
6.4.8 Training, Fine-Tuning, Embedding, Retrieval, and Model Improvement Restrictions. 6.4.8(a) GCRI Canada shall impose restrictions on training, fine-tuning, embedding, retrieval, model improvement, model evaluation, synthetic data generation, and model-provider retention where data sensitivity, public authority restrictions, privacy, sovereign data, community safeguards, protected knowledge, confidentiality, IP, cybersecurity, or public-safe risk requires restriction.
6.4.8(b) Data shall not be used for model training, fine-tuning, embedding, retrieval indexing, model improvement, external model-provider retention, benchmark construction, synthetic data generation, or public AI tool processing unless the source record, lawful basis, data classification, permitted use, AI-use limits, provider terms, security review, and correction path permit such use.
6.4.8(c) Restricted data may include personal information, public authority data, sovereign data, Indigenous knowledge, local knowledge, community knowledge, protected knowledge, health-sensitive data, cyber-sensitive data, infrastructure-sensitive data, finance-sensitive data, confidential partner data, provider data, sponsor data, host data, unpublished research data, legal materials, privileged materials, and controlled annex materials.
6.4.8(d) Embedding and retrieval systems shall be treated as data processing systems. Their records shall identify source materials, classification, access controls, retention, deletion or restriction paths, update procedures, correction propagation, retrieval limits, leakage controls, and public-safe output limits.
6.4.8(e) Fine-tuning and model improvement activities shall require heightened review where data is non-public, rights-bearing, public authority-linked, community-linked, health-sensitive, cyber-sensitive, infrastructure-sensitive, proprietary, protected, export-control-sensitive, sanctions-sensitive, or subject to contractual restrictions.
6.4.8(f) Synthetic data generation shall not be used to evade data restrictions, re-identify participants, reconstruct protected knowledge, expose sensitive locations, infer public authority restricted information, or create misleading public-safe outputs.
6.4.8(g) Where AI-use restrictions are violated or unclear, GCRI Canada shall hold, restrict, delete where required, reclassify, notify where appropriate, correct affected outputs, review downstream dependencies, and update controls.
6.4.8(h) The controlling rule shall be that data may not be converted into model capability unless the record permits that conversion.
6.4.9 AI Use With Rights-Bearing, Public Authority, Community, Health-Sensitive, Infrastructure-Sensitive, or Protected Knowledge Data. 6.4.9(a) AI use with rights-bearing, public authority, community, Indigenous, local, health-sensitive, infrastructure-sensitive, cyber-sensitive, finance-sensitive, sovereign, confidential, or protected knowledge data shall require heightened safeguards before input, processing, retrieval, embedding, summarization, classification, inference, publication, sharing, or retention.
6.4.9(b) Rights-bearing data shall be handled with lawful basis, purpose limitation, minimization, access controls, retention limits, correction rights, deletion or restriction rights where required, AI-use limits, human review, and public-safe output controls.
6.4.9(c) Public authority data shall be handled according to authority to contribute, official classification, capacity, permitted use, publication permission, AI-use restrictions, confidentiality, retention, transfer, public authority correction rights, non-delegation, non-endorsement, and non-public-authority-action status.
6.4.9(d) Community, Indigenous, local, and protected knowledge shall not be input into AI systems, embedded, retrieved, summarized, mapped, modeled, trained on, or used for public materials unless consent or non-consent treatment where applicable, community protocols, protected knowledge controls, attribution or non-attribution, non-extraction, non-enclosure, public-safe review, grievance path, remedy path, withdrawal or restriction path, and correction path are records-valid.
6.4.9(e) Health-sensitive data shall require privacy, ethics, public-safe, public authority, health-sensitive, AI-use, and correction controls, and shall not be used to generate clinical advice, public health orders, official health guidance, public warnings, emergency commands, insurance determinations, or professional health opinions by default.
6.4.9(f) Infrastructure-sensitive and cyber-sensitive data shall require security review, access restriction, public-safe disclosure review, vulnerability handling, sensitive location protection, operator boundary language, public authority boundary language, and incident procedures.
6.4.9(g) AI outputs derived from sensitive data shall carry classification, source sensitivity, permitted use, prohibited use, limitation, public-safe status, human review status, downstream sharing limits, and correction path.
6.4.9(h) Where AI use creates unacceptable risk to rights, public authority confidentiality, community safety, protected knowledge, health-sensitive information, infrastructure security, cybersecurity, sovereignty, or public trust, GCRI Canada shall not use AI for that data or shall use only appropriately restricted, local, compute-to-data, privacy-preserving, or human-only methods.
6.4.9(i) The controlling rule shall be that sensitive data does not become less sensitive because an AI system processes it.
6.4.10 AI Hallucination, Bias, Drift, Unsafe Output, Data Leakage, Model Misuse, and Public Overclaim Handling. 6.4.10(a) GCRI Canada shall maintain procedures for identifying, recording, correcting, and learning from AI hallucination, bias, drift, unsafe output, data leakage, model misuse, prompt injection, tool misuse, insecure output, privacy issue, protected knowledge exposure, public authority confusion, finance overclaim, provider overclaim, sponsor overclaim, media misuse, and public overclaim.
6.4.10(b) AI hallucination shall include fabricated facts, fabricated sources, unsupported legal or technical conclusions, invented records, false citations, false authority, false public authority statements, false finance statements, false provider or sponsor statements, false community statements, and false confidence.
6.4.10(c) Bias and fairness issues shall include outputs that materially distort, exclude, stigmatize, misclassify, overgeneralize, or harm persons, communities, regions, Indigenous or local knowledge holders, public authorities, providers, hosts, sponsors, or other affected actors in ways inconsistent with evidence, safeguards, rights, accessibility, or public-safe duties.
6.4.10(d) Drift shall include degradation or change in AI performance, model behavior, retrieval quality, classification quality, summarization accuracy, public-safe suitability, benchmark relevance, or output reliability over time or across contexts.
6.4.10(e) Unsafe output shall include output that creates public warning confusion, emergency command confusion, public authority confusion, finance overclaim, procurement implication, certification implication, recognition implication, provider preference, sponsor control, protected knowledge exposure, sensitive location exposure, cyber risk, data leakage, harmful instruction, misinformation, or public trust harm.
6.4.10(f) Data leakage shall include unauthorized disclosure, memorization, reconstruction, retrieval exposure, embedding exposure, prompt exposure, output exposure, model-provider retention contrary to restrictions, or onward sharing beyond permitted use.
6.4.10(g) Model misuse shall include use outside approved purpose, use with prohibited data, use without required human review, use to make authority-bearing decisions, use to generate unsupported public claims, use to bypass public-safe review, use to produce finance-facing or public authority-facing outputs without required controls, or use to automate prohibited functions.
6.4.10(h) Where AI issues are detected, GCRI Canada shall classify severity, preserve records, restrict affected outputs, correct or withdraw materials, notify affected actors where appropriate, review downstream dependencies, update prompts or controls, update model or provider restrictions, update training, and close out with prevention measures.
6.4.10(i) The controlling rule shall be that AI errors must be treated as correction events, not as harmless drafting artifacts where reliance risk exists.
6.4.11 AI-Assisted Evidence Classification, Summarization, Corroboration, Routing, and Publication Controls. 6.4.11(a) AI-assisted evidence classification, summarization, corroboration, routing, drafting, translation, visualization, dashboarding, mapping, and publication support shall be controlled by source records, permitted use, human review, public-safe review, data restrictions, claims discipline, and correction path.
6.4.11(b) AI-assisted classification shall not create authoritative status, Docket status, Grid status, recognition status, finance-readiness status, certification status, public authority status, public warning status, provider status, sponsor status, or protocol status without competent record and human review where material.
6.4.11(c) AI-assisted summarization shall preserve source meaning, limitations, confidence, uncertainty, classification, boundary language, public-safe status, finance-safe status where material, public authority limits, data restrictions, protected knowledge restrictions, and correction path.
6.4.11(d) AI-assisted corroboration shall not be treated as independent corroboration unless it compares distinct source records through a documented method and human review confirms the result where material.
6.4.11(e) AI-assisted routing shall not create handoff authority, public authority referral, GRA finance-readiness, GRF recognition, Protocol Authority effect, procurement status, provider preference, or execution consequence by default. Routing suggestions shall be reviewed before external action where material.
6.4.11(f) AI-assisted publication support shall not bypass author review, legal review where required, public-safe review, data review, cybersecurity review, public authority reference approval, finance-boundary review, name-use review, community safeguard review, or correction review.
6.4.11(g) AI-assisted translation or localization shall preserve controlled vocabulary, legal identity, boundary language, public-safe meaning, public authority capacity, finance limits, community safeguards, and correction path.
6.4.11(h) AI-assisted dashboard and map labels shall be treated as public claims where externally visible and shall require review for public warning confusion, public authority confusion, finance overclaim, provider preference, sponsor control, community harm, sensitive location exposure, and source authority.
6.4.11(i) The controlling rule shall be that AI may assist evidence workflows only where it does not replace source records, human accountability, public-safe review, or competent authority.
6.4.12 AI Scope Without AI-as-Authority. 6.4.12(a) GCRI Canada’s broad AI scope shall not create AI-as-authority.
6.4.12(b) No AI system, AI model, foundation model, generative model, agentic system, automated decision-support system, classifier, recommender, detector, dashboard, map, confidence score, benchmark result, model card, system card, dataset card, benchmark card, inference record, public-safe report, or AI-generated output shall create legal authority, public authority meaning, GRF recognition, GRA finance-readiness, Protocol Authority effect, certification, procurement approval, investment advice, lending approval, insurance approval, underwriting, rating, guarantee, public finance approval, provider preference, sponsor approval, professional opinion, public warning, emergency command, operational clearance, deployment authorization, or execution consequence by default.
6.4.12(c) AI may support GCRI Canada’s evidence, methods, observability, ontology, public-good R&D, technical-baseline, public-good software, public authority learning, public-safe publication, and correctionability functions only where the AI role is recorded, bounded, reviewed, and correctionable.
6.4.12(d) AI-generated confidence, classification, readiness context, risk context, maturity context, compatibility context, anomaly detection, signal interpretation, or routing suggestion shall be treated as support for human and institutional review, not as final status.
6.4.12(e) Any AI output that could be understood as authority shall require immediate boundary language, human review, public-safe review, and, where necessary, reclassification, restriction, withdrawal, or correction.
6.4.12(f) External actors shall not use GCRI Canada AI work, AI records, AI outputs, AI evaluations, AI dashboards, AI summaries, AI classifications, AI benchmarks, AI methods, or AI public-good software to claim approval, endorsement, certification, recognition, finance-readiness, procurement advantage, public authority approval, protocol effect, operational clearance, market superiority, or execution authority beyond the source record.
6.4.12(g) Where AI-as-authority overclaim occurs, GCRI Canada shall correct, restrict, withdraw, notify affected actors where appropriate, update claims controls, review downstream dependencies, and preserve correction records.
6.4.12(h) The controlling rule shall be that AI may assist the production of evidence, but authority remains with lawful institutions, competent records, accountable humans, and correctionable processes.
6.5 AI-RAN, O-RAN, Private Wireless, Telecommunications, and Networked Sensing
6.5.1 AI-RAN as a Core Nexus-Relevant Technology Domain. 6.5.1(a) AI-RAN shall be a core Nexus-relevant technology domain within GCRI Canada’s public-benefit, non-executing, evidence, methods, observability, ontology, public-good R&D, public-good software, open technical-baseline, public authority learning, public-safe publication, and correctionability mandate.
6.5.1(b) GCRI Canada may research, evidence, observe, model, compare, test, document, classify, teach, publish, steward, route, and correct AI-RAN-related evidence, methods, signals, datasets, telemetry records, network-context records, model records, benchmark records, system records, node records, infrastructure-context records, public-safe dashboards, public authority learning materials, technical baselines, public-good software, and correction records.
6.5.1(c) AI-RAN may be addressed by GCRI Canada as an evidentiary, methodological, observability, interoperability, resilience, public authority learning, and technical-baseline domain, including its interaction with edge AI, radio access networks, O-RAN, private wireless, 5G and 6G-relevant systems, non-terrestrial network interfaces, sensor networks, cyber-physical systems, critical infrastructure, public safety communications, remote connectivity, sovereign data, and mission-critical infrastructure.
6.5.1(d) AI-RAN inclusion within GCRI Canada’s scope shall not make GCRI Canada a telecommunications carrier, network operator, spectrum authority, infrastructure operator, managed services provider, systems integrator, emergency communications operator, public warning authority, public authority, regulator, procurement authority, provider selector, certifier, finance-readiness issuer, underwriter, insurer, rating actor, or execution actor.
6.5.1(e) AI-RAN evidence may support Nexus Observatory methods, Nexus Truth Engine methods, public authority learning, host-readiness evidence, node evidence, regional and national readiness context, Docket inputs, Grid inputs, public-safe reporting, GRA evidence inputs, GRF evidence inputs, technical baseline support, and Protocol Authority support, but only within records-valid, role-bound, non-executing limits.
6.5.1(f) AI-RAN materials shall distinguish network evidence from network control, signal interpretation from public authority decision, observability from public warning, test from certification, technical baseline support from procurement preference, provider participation from provider endorsement, and infrastructure context from infrastructure operation.
6.5.1(g) Where AI-RAN work creates public authority, critical infrastructure, public safety, cybersecurity, location, privacy, provider, procurement, finance, or public-safe risk, GCRI Canada shall apply heightened review, boundary language, classification, access control, correction path, and competent-actor routing.
6.5.1(h) The controlling rule shall be that AI-RAN may become a powerful public-good evidence and observability layer, but GCRI Canada shall not become the AI-RAN operator or authority by studying it.
6.5.2 O-RAN, Private Wireless, 5G / 6G-Relevant Systems, Spectrum-Adjacent Systems, NTN Interfaces, and Mission-Critical Communications. 6.5.2(a) GCRI Canada’s AI-RAN and telecommunications-related scope may include O-RAN, open radio access network architectures, private wireless networks, 5G-relevant systems, 6G-relevant systems, spectrum-adjacent systems, non-terrestrial network interfaces, edge-connectivity systems, mission-critical communications, remote connectivity, emergency-adjacent communications, industrial wireless systems, port and corridor connectivity, rural and northern connectivity, and networked sensing systems.
6.5.2(b) GCRI Canada may develop evidence methods, observability methods, data-governance methods, network-context methods, resilience methods, interoperability methods, public-safe interpretation methods, public authority learning materials, technical baselines, public-good software, and correction records concerning such systems.
6.5.2(c) GCRI Canada shall not issue spectrum rights, telecommunications licenses, carrier authorizations, network operating permissions, public safety communications approvals, procurement approvals, deployment authorizations, network security certifications, emergency communications commands, public warnings, or official regulatory guidance by virtue of work in O-RAN, private wireless, 5G, 6G, NTN, or mission-critical communications.
6.5.2(d) O-RAN and private wireless evidence shall identify the relevant network owner, operator, host, provider, integrator, equipment supplier, software supplier, data steward, public authority participant where any, and GCRI Canada’s role and non-role.
6.5.2(e) 5G and 6G-relevant materials shall distinguish research, scenario learning, technical-baseline support, interoperability study, and public-good evidence from deployment approval, spectrum allocation, carrier operation, regulatory compliance finding, security certification, public authority adoption, procurement status, or provider preference.
6.5.2(f) Spectrum-adjacent or mission-critical communications work shall be treated with heightened care where it may affect public safety, emergency communications, critical infrastructure, public authority operations, national or regional security sensitivity, data sovereignty, or telecommunications regulation.
6.5.2(g) NTN and remote connectivity interfaces shall require public-safe review where materials concern remote communities, Indigenous or local contexts, Arctic or northern systems, ports, corridors, disaster resilience, critical infrastructure, or emergency-adjacent communications.
6.5.2(h) The controlling rule shall be that GCRI Canada may support understanding of advanced communications systems, but lawful network authority and operation remain with competent actors.
6.5.3 AI-RAN Signal Interpretation as Evidence Method, Not Public Authority or Network Control by Default. 6.5.3(a) AI-RAN signal interpretation by or involving GCRI Canada shall be treated as an evidence method, observability method, confidence method, correlation method, anomaly-detection method, or public authority learning method, not as public authority action, network control, infrastructure operation, or execution by default.
6.5.3(b) AI-RAN signal interpretation may include analysis of radio signals, edge intelligence outputs, network telemetry, mobility patterns, environmental signals, infrastructure signals, sensor fusion outputs, anomaly indicators, connectivity records, service-context signals, cyber telemetry, performance indicators, resilience indicators, and public-safe dashboard indicators.
6.5.3(c) Signal interpretation shall identify source, system, sensor, network context, owner, operator, provider, host, time, location sensitivity, calibration status, transformation steps, model use, confidence, uncertainty, limitations, spoof risk, sampling limits, public-safe status, data classification, permitted use, prohibited use, and correction path.
6.5.3(d) AI-RAN signal interpretation shall not create official hazard notices, emergency alerts, evacuation instructions, public health orders, safety commands, infrastructure-use directives, public authority findings, regulatory findings, procurement determinations, finance-readiness, certification, recognition, protocol effect, provider endorsement, network operating instructions, or field deployment decisions by default.
6.5.3(e) Where signal interpretation may inform public authority learning or public-safe reporting, GCRI Canada shall distinguish observed signal, inferred meaning, modeled meaning, confidence level, uncertainty, limitation, public-safe status, and non-authority status.
6.5.3(f) Where signal interpretation identifies potential risk, anomaly, disruption, hazard, vulnerability, spoofing, or infrastructure issue, GCRI Canada may record, route, or hand off evidence to a competent actor through boundary-safe records, but shall not command response, dispatch resources, direct network changes, issue warnings, or determine public authority action.
6.5.3(g) Where automated or AI-assisted signal interpretation is used, material outputs shall require human review before public-facing, public authority-facing, finance-facing, provider-facing, or operationally sensitive use.
6.5.3(h) The controlling rule shall be that AI-RAN signals may inform evidence, but signals shall not rule the institution or the public.
6.5.4 Networked Sensing, Edge Intelligence, Telecom Telemetry, Radio Signals, Environmental Signals, Infrastructure Signals, and Mobility Signals. 6.5.4(a) GCRI Canada may work with networked sensing, edge intelligence, telecom telemetry, radio signals, environmental signals, infrastructure signals, mobility signals, sensor fusion outputs, geospatially linked signals, cyber-physical signals, and related observability records as evidence inputs within its non-executing mandate.
6.5.4(b) Networked sensing records shall identify signal type, source system, sensor class, network context, operator, host, provider, collection method, time, location, spatial resolution, temporal resolution, calibration, data quality, processing steps, AI use, model use, confidence, uncertainty, limitations, classification, and correction path.
6.5.4(c) Edge intelligence outputs shall identify whether interpretation occurred at the edge, in cloud systems, in sovereign compute, in local systems, through provider systems, through host systems, through public authority systems, or through GCRI Canada-controlled or GCRI Canada-accessed tools.
6.5.4(d) Telecom telemetry shall be handled with heightened privacy, metadata, cybersecurity, critical infrastructure, public authority, and sovereign data controls because metadata, location traces, device patterns, service quality indicators, and network behavior may reveal sensitive persons, places, infrastructure, or operations.
6.5.4(e) Environmental and infrastructure signals shall be reviewed for public-safe meaning, including whether they could be mistaken for hazard warnings, infrastructure directives, utility instructions, operational commands, public authority determinations, insurance signals, credit signals, procurement ratings, or public finance determinations.
6.5.4(f) Mobility signals shall be handled with special attention to privacy, location sensitivity, re-identification risk, community harm, public authority misuse, policing misuse, discrimination risk, protected participation, and public-safe aggregation.
6.5.4(g) Networked sensing outputs shall not be published, mapped, dashboarded, routed, summarized, or used in public authority learning without classification, public-safe review, data-rights review, cybersecurity review where material, and correction path.
6.5.4(h) The controlling rule shall be that networked sensing may reveal patterns, but GCRI Canada shall govern those patterns as sensitive evidence, not as automatic public meaning.
6.5.5 AI-RAN Evidence Quality, Calibration, Spoof Detection, Sensor Fusion, Signal Confidence, and Uncertainty. 6.5.5(a) AI-RAN and networked sensing evidence quality shall require calibration, source integrity, spoof detection, sensor fusion discipline, signal confidence, uncertainty treatment, limitation disclosure, review status, and correction path.
6.5.5(b) Calibration records shall identify device, sensor, radio system, network element, model, firmware or software version where material, calibration method, calibration date, operating conditions, known limits, maintenance status where available, and confidence implications.
6.5.5(c) Spoof detection and signal integrity methods shall address false signals, replayed signals, tampered signals, adversarial inputs, sensor drift, network manipulation, compromised devices, GPS or geolocation manipulation, model manipulation, data poisoning, telemetry gaps, and malicious or accidental distortion.
6.5.5(d) Sensor fusion shall identify which sources are combined, whether sources are independent, whether sources share dependencies, whether AI models are used, how conflicts are handled, how missing data is handled, how uncertainty is propagated, and how public-safe outputs are bounded.
6.5.5(e) Signal confidence shall not be reduced to a conclusory score without source explanation. Confidence records shall identify evidence basis, corroboration, recency, coverage, calibration, signal-to-noise limitations, spatial and temporal limits, model limits, human review, dispute status, and correction history.
6.5.5(f) Uncertainty shall be expressly retained where signals are incomplete, noisy, stale, model-dependent, location-sensitive, provider-supplied, public authority-limited, public-safe-limited, privacy-limited, spoof-risk-bearing, or insufficiently corroborated.
6.5.5(g) AI-RAN evidence quality outputs shall not become ratings, certifications, public warnings, emergency commands, procurement rankings, provider rankings, finance-readiness determinations, insurance scores, credit scores, public authority findings, or operational instructions by default.
6.5.5(h) The controlling rule shall be that signal confidence must disclose what the signal can and cannot support.
6.5.6 AI-RAN Public-Safe Outputs, Dashboard Controls, and Public Authority Boundary Language. 6.5.6(a) AI-RAN public-safe outputs, dashboards, maps, indicators, reports, controlled annexes, briefings, Academy materials, Docket inputs, Grid inputs, Observatory records, and public authority learning materials shall require public-safe review, dashboard controls, map controls, claims discipline, public authority boundary language, and correction path where material.
6.5.6(b) AI-RAN dashboards shall identify source, signal class, update frequency, latency, data limits, model limits, confidence, uncertainty, public-safe status, audience, permitted use, prohibited use, and whether the dashboard is internal, controlled, public-safe, public, public authority-facing, finance-facing, provider-facing, or not-for-reliance.
6.5.6(c) AI-RAN maps shall identify spatial precision, temporal precision, signal source, processing method, generalization where applicable, sensitive-location protection, public-safe limitations, public authority boundary, non-warning status, non-command status, and correction path.
6.5.6(d) Public authority boundary language shall state, where material, that AI-RAN outputs do not constitute public authority decisions, official guidance, regulatory findings, public warnings, emergency commands, procurement approvals, public finance approvals, infrastructure directives, utility instructions, or sovereign obligations by default.
6.5.6(e) AI-RAN public-facing materials shall include non-certification, non-provider-endorsement, non-procurement, non-finance-readiness, non-rating, non-underwriting, non-guarantee, non-operational-control, and non-execution language where material to prevent unsafe reliance.
6.5.6(f) Dashboard controls shall prevent users from inferring greater authority than the record supports, including through labels, colors, icons, alerts, badges, rankings, severity indicators, live-map framing, public authority logos, provider logos, sponsor logos, or emergency-adjacent design.
6.5.6(g) Where AI-RAN outputs create public warning confusion, public authority confusion, emergency command confusion, provider preference, finance overclaim, sensitive location exposure, privacy risk, cyber risk, or public trust risk, GCRI Canada shall hold, restrict, reclassify, revise, withdraw, or correct the output.
6.5.6(h) The controlling rule shall be that AI-RAN dashboards may inform learning and evidence, but they shall not become public-warning systems or public authority systems by design.
6.5.7 AI-RAN Data Privacy, Metadata, Location Sensitivity, Critical Infrastructure Sensitivity, and Sovereign Data Controls. 6.5.7(a) AI-RAN and telecommunications-related data shall be handled with heightened privacy, metadata, location sensitivity, critical infrastructure sensitivity, sovereign data, public authority data, cybersecurity, and public-safe controls.
6.5.7(b) AI-RAN data may include network telemetry, radio signal records, device metadata, edge inference records, sensor outputs, location-linked records, mobility indicators, infrastructure performance records, coverage records, latency records, service-quality records, cyber telemetry, provider records, host records, public authority records, and derived evidence.
6.5.7(c) Privacy controls shall address personal information, device-linked data, location traces, mobility patterns, re-identification risk, rights-bearing data, affected persons, affected communities, consent or authorization where applicable, purpose limitation, minimization, access restriction, retention, correction, deletion or restriction where required, onward sharing, and publication risk.
6.5.7(d) Metadata controls shall recognize that metadata may be sensitive even where content is absent. Metadata shall be classified according to location sensitivity, person-linkage, infrastructure sensitivity, public authority sensitivity, provider sensitivity, cybersecurity sensitivity, and public-safe risk.
6.5.7(e) Location-sensitive data shall be protected against exposure of residences, critical infrastructure, public safety facilities, public authority operations, vulnerable communities, sensitive routes, protected sites, Indigenous or local knowledge-sensitive places, emergency facilities, ports, corridors, remote communities, and other sensitive locations.
6.5.7(f) Critical infrastructure controls shall address network infrastructure, energy systems, water systems, transport systems, ports, corridors, emergency communications, public safety communications, hospitals, public authority systems, industrial systems, telecommunications systems, and other infrastructure whose exposure could create harm.
6.5.7(g) Sovereign data controls shall address Canadian legal requirements, public authority restrictions, national, provincial, territorial, Indigenous, regional, local, host, and community data limits, cross-border transfer, localization, compute-to-data, provider access, cloud access, AI-use restrictions, and public-safe release.
6.5.7(h) Where AI-RAN data cannot be lawfully or safely received, processed, stored, analyzed, dashboarded, mapped, modeled, published, routed, or handed off, GCRI Canada shall restrict, aggregate, redact, anonymize where appropriate and sufficient, localize, compute-to-data, classify, delay, quarantine, refuse, withdraw, or correct the activity.
6.5.7(i) The controlling rule shall be that AI-RAN data is infrastructure-sensitive evidence and shall never be treated as ordinary telemetry merely because it is machine-generated.
6.5.8 AI-RAN Cybersecurity, Network Security, Access Control, and Incident Handling. 6.5.8(a) AI-RAN, O-RAN, private wireless, telecommunications, and networked sensing work involving GCRI Canada shall require cybersecurity, network security, access control, incident handling, vulnerability handling, evidence preservation, and public-safe disclosure controls proportionate to risk.
6.5.8(b) Cybersecurity controls shall address authentication, authorization, least privilege, secure transfer, secure storage, encryption where appropriate, secrets management, repository security, dashboard security, API security, model security, edge device security, network access security, sensor security, log handling, vulnerability reporting, incident escalation, and access closeout.
6.5.8(c) Network security controls shall identify network owner, operator, provider, host, integrator, administrative access, monitoring access, telemetry access, configuration access, test access, public authority access where any, and whether GCRI Canada has read-only, analytical, advisory, evidence, methods, or other bounded access.
6.5.8(d) GCRI Canada shall not assume operational cybersecurity responsibility, network defense responsibility, managed security responsibility, incident command responsibility, emergency communications responsibility, or infrastructure operation responsibility by reason of AI-RAN or telecommunications evidence work unless expressly and lawfully recorded within proper boundary, and only where consistent with GCRI Canada’s non-executing mandate.
6.5.8(e) AI-RAN cybersecurity incidents may include unauthorized access, data leakage, telemetry compromise, model compromise, edge device compromise, sensor spoofing, signal manipulation, dashboard compromise, repository compromise, provider breach, public authority data exposure, protected knowledge exposure, public-safe issue, or public claims overreach.
6.5.8(f) Incident handling shall identify intake, severity, affected systems, affected records, affected actors, preservation steps, containment responsibility, competent operator, public authority notification where applicable, provider notification where applicable, GCRI Canada correction obligations, public-safe notice decision, and closeout.
6.5.8(g) Vulnerability or incident information shall be publicized only through lawful, public-safe, cybersecurity-reviewed, and responsible disclosure channels, and shall not be framed as public warning, regulatory finding, enforcement position, provider ranking, procurement recommendation, or operational command by GCRI Canada.
6.5.8(h) The controlling rule shall be that GCRI Canada may support cybersecurity evidence and learning, but operational network security remains with the competent operator or authority.
6.5.9 AI-RAN Interface With Nexus Observatory Nodes, Hubs, Clusters, Hotspots, Regional Clusters, and National Dense Cores. 6.5.9(a) AI-RAN may interface with Nexus Observatory nodes, hubs, clusters, hotspots, regional clusters, national dense cores, sensor systems, edge compute systems, DePIN systems, digital twins, dashboards, public-safe maps, Truth Engine methods, Docket inputs, Grid inputs, and public authority learning materials as an evidence and observability domain.
6.5.9(b) Observatory interface records shall identify node, hub, cluster, hotspot, regional cluster, or national dense core; owner; operator; host; provider; data custodian; system steward; GCRI Canada role; non-role; data classification; AI-use limits; cybersecurity controls; public-safe status; public authority boundary; public warning boundary; emergency command boundary; and correction path.
6.5.9(c) GCRI Canada’s AI-RAN methods support for Nexus Observatory shall not make GCRI Canada the owner, operator, maintainer, network controller, systems integrator, managed services provider, public authority operator, emergency communications operator, public warning issuer, or infrastructure execution actor for any node, hub, cluster, hotspot, regional cluster, or national dense core.
6.5.9(d) AI-RAN Observatory outputs shall identify source lineage, signal class, data source, model use, confidence, uncertainty, limitations, latency, coverage, calibration, spoof risk, public-safe classification, and correction path.
6.5.9(e) Observatory dashboards or maps using AI-RAN signals shall distinguish observability from warning, evidence from official notice, signal from decision, node context from public authority action, and infrastructure presence from infrastructure operation.
6.5.9(f) Where AI-RAN Observatory interfaces involve public authorities, remote communities, Indigenous or local contexts, critical infrastructure, emergency-adjacent settings, public safety systems, public health systems, ports, corridors, Arctic or northern contexts, or sensitive locations, heightened public-safe, data, cyber, sovereignty, and community safeguards shall apply.
6.5.9(g) Where AI-RAN Observatory records are corrected, superseded, withdrawn, restricted, or reclassified, GCRI Canada shall review affected dashboards, maps, Docket records, Grid records, Academy materials, public-safe reports, public authority materials, and downstream recipients.
6.5.9(h) The controlling rule shall be that AI-RAN can strengthen Nexus Observatory, but Observatory interface shall not collapse ownership, operation, public authority, warning, or execution boundaries.
6.5.10 AI-RAN Interface With Qualified Providers Without Provider Preference. 6.5.10(a) GCRI Canada may interact with qualified providers concerning AI-RAN, O-RAN, private wireless, telecommunications, networked sensing, edge systems, dashboards, cybersecurity, integration, testing, benchmarks, demonstrations, validation sprints, public-good software, technical baselines, and Observatory methods, subject to provider neutrality, competition safety, public claims controls, data controls, IP controls, cybersecurity controls, and correction obligations.
6.5.10(b) Provider interaction may include technical briefings, documentation review, test-plan review, benchmark participation, validation sprint participation, demonstration observation, data-governance review, cybersecurity review, interoperability review, public-good software contribution review, technical-baseline contribution review, Academy participation, Docket input, Grid input, and correction review.
6.5.10(c) Provider participation in AI-RAN work shall not create preferred provider status, vendor selection, procurement advantage, certification, recognition, finance-readiness, public authority approval, protocol effect, market superiority, deployment authorization, operational clearance, security certification, network approval, or GCRI Canada endorsement by default.
6.5.10(d) Provider-supplied AI-RAN evidence shall identify provider source, test conditions, system boundary, data source, calibration status, network context, model use, conflicts, limitations, reproducibility where appropriate, public-safe status, public claims limits, and correction path.
6.5.10(e) Provider benchmarks, tests, pilots, demonstrations, and validation sprints concerning AI-RAN shall be evidence and learning activities only, not procurement or certification outcomes by default.
6.5.10(f) Provider access to GCRI Canada AI-RAN materials shall require role classification, confidentiality, data restrictions, AI-use restrictions, IP terms, security controls, conflict controls, competition controls, public claims limits, and correction path.
6.5.10(g) Where a provider overclaims AI-RAN interaction with GCRI Canada, GCRI Canada shall require correction, restrict name use, restrict mark use, withdraw permission to use materials, suspend access, notify affected actors where appropriate, and preserve correction records.
6.5.10(h) The controlling rule shall be that providers may contribute technology evidence, but GCRI Canada shall not choose market winners through AI-RAN interaction.
6.5.11 AI-RAN Interface With National Companies and Project SPVs Without GCRI Canada Execution. 6.5.11(a) GCRI Canada may provide AI-RAN-related evidence, methods, observability logic, technical baseline support, public-good software support, host-readiness evidence, node evidence, risk evidence, Docket inputs, Grid inputs, diligence gap inputs, public authority learning materials, and correction records to National Consortium Companies or Project SPVs through boundary-safe interface or handoff instruments.
6.5.11(b) Such interface shall not make GCRI Canada the owner, sponsor, manager, financer, lender, guarantor, insurer, underwriter, rating actor, operator, telecommunications provider, systems integrator, managed services provider, cybersecurity operator, procurement actor, provider selector, public authority, or execution actor for any National Consortium Company or Project SPV.
6.5.11(c) AI-RAN evidence for National Companies or Project SPVs shall include source lineage, scope, network context, infrastructure context, host context, provider context, public authority context where any, confidence, uncertainty, limitations, finance-safe language where material, public authority boundary language, procurement boundary language, provider-neutrality language, and correction path.
6.5.11(d) National Companies and Project SPVs using GCRI Canada AI-RAN materials shall remain responsible for their own capital, contracts, procurement, deployment, network operation, provider selection, public authority interfaces, host interfaces, insurance, cybersecurity, service levels, warranties, data handling, compliance, public claims, and corrections.
6.5.11(e) GCRI Canada AI-RAN support shall not create investment recommendation, securities offering, capital solicitation, lending approval, guarantee, insurance approval, underwriting, rating, public finance approval, finance-readiness, procurement approval, deployment approval, provider endorsement, network approval, infrastructure operation, public authority approval, or execution authorization.
6.5.11(f) Where AI-RAN evidence is used in finance-facing, procurement-facing, public authority-facing, or customer-facing materials of a National Company or Project SPV, public claims controls, finance-boundary notices, public authority boundary notices, non-endorsement language, and correction obligations shall apply.
6.5.11(g) Where National Companies or Project SPVs overclaim GCRI Canada AI-RAN support, GCRI Canada shall correct, restrict, withdraw, notify affected actors where appropriate, review downstream dependencies, and preserve correction records.
6.5.11(h) The controlling rule shall be that AI-RAN evidence may support enterprise readiness, but GCRI Canada shall not execute the enterprise system.
6.5.12 AI-RAN Scope Without Telecommunications Regulation, Procurement, Public Warning, or Infrastructure Operation by GCRI Canada. 6.5.12(a) GCRI Canada’s AI-RAN, O-RAN, private wireless, telecommunications, and networked sensing scope shall not authorize telecommunications regulation, spectrum regulation, carrier licensing, network approval, public procurement, vendor selection, official public warning, emergency command, public safety directive, infrastructure operation, managed services, telecommunications operation, or field deployment by GCRI Canada.
6.5.12(b) GCRI Canada shall not issue telecommunications licenses, spectrum permissions, network operating permits, regulatory compliance determinations, safe harbors, enforcement positions, procurement rankings, tender prequalification, public purchasing recommendations, public warning notices, emergency communications instructions, infrastructure-use directives, or operational commands.
6.5.12(c) GCRI Canada shall not operate AI-RAN networks, O-RAN networks, private wireless networks, telecommunications infrastructure, NTN interfaces, mission-critical communications systems, networked sensing systems, public safety communications systems, or emergency communications systems by default.
6.5.12(d) GCRI Canada shall not select AI-RAN providers, recommend AI-RAN investments, guarantee AI-RAN performance, certify AI-RAN systems by default, approve AI-RAN deployments, underwrite AI-RAN risks, rate AI-RAN resilience, or issue finance-readiness concerning AI-RAN by default.
6.5.12(e) Public authorities, telecommunications regulators, network operators, public safety actors, emergency management actors, infrastructure owners, hosts, National Companies, Project SPVs, providers, licensed professionals, investors, lenders, insurers, underwriters, and other competent actors shall retain responsibility for their own lawful decisions, operations, compliance, public claims, reliance, and corrections.
6.5.12(f) GCRI Canada may hand off AI-RAN evidence to competent actors where lawful downstream action may be needed, provided the handoff includes role, scope, limitations, non-reliance where appropriate, public-safe status, data restrictions, cybersecurity obligations, finance-safe language where material, public authority boundary language, and correction path.
6.5.12(g) Where any AI-RAN material is misused to imply GCRI Canada telecommunications regulation, procurement authority, public warning authority, infrastructure operation, provider selection, finance-readiness, certification, recognition, protocol effect, or execution, GCRI Canada shall correct, restrict, withdraw, issue public-safe clarification where appropriate, and preserve correction records.
6.5.12(h) The controlling rule shall be that GCRI Canada may help make AI-RAN evidence trustworthy, interoperable, public-safe, and correctable, but it shall not regulate, buy, warn, operate, or execute AI-RAN systems.
6.6 Sovereign Compute, Edge Compute, Cloud Compute, HPC, Confidential Computing, and Compute-to-Data
6.6.1 Sovereign Compute as a Core Public-Benefit and Public Authority-Relevant Domain. 6.6.1(a) Sovereign compute shall be a core public-benefit, public authority-relevant, sovereignty-relevant, resilience-relevant, infrastructure-relevant, and Nexus-relevant technology domain within GCRI Canada’s non-executing evidence, methods, observability, ontology, public-good R&D, public-good software, open technical-baseline, public authority learning, public-safe publication, and correctionability mandate.
6.6.1(b) GCRI Canada may research, evidence, compare, model, document, teach, publish, steward, route, and correct sovereign compute evidence, compute-governance methods, workload records, compute-to-data methods, jurisdiction-aligned compute models, confidential computing methods, edge-compute methods, high-performance computing methods, cloud-governance methods, secure collaboration methods, public authority learning materials, public-good software, technical baselines, and correction records.
6.6.1(c) Sovereign compute may include national, regional, provincial, territorial, Indigenous, public authority, public-sector, university, research, community, regulated-sector, critical-infrastructure, public-benefit, mission-critical, confidential, air-gapped, edge, cloud, high-performance, or hybrid compute environments designed or assessed for lawful control, data sovereignty, security, resilience, public authority relevance, public-good interoperability, or controlled data use.
6.6.1(d) GCRI Canada’s work concerning sovereign compute shall not make GCRI Canada a cloud provider, compute operator, managed services provider, data processor by default, public authority system operator, high-performance computing operator, national compute authority, cybersecurity operator, telecommunications operator, infrastructure owner, fund, lender, insurer, underwriter, rating actor, procurement authority, public finance approver, or licensed execution actor.
6.6.1(e) Sovereign compute evidence may support public authority learning, Nexus Observatory methods, national dense core design evidence, regional cluster evidence, data-governance methods, AI-governance methods, cyber-resilience methods, GRA evidence inputs, GRF evidence inputs, Protocol Authority support, Academy materials, Docket inputs, Grid inputs, and boundary-safe handoffs, but only within records-valid, role-bound, non-executing limits.
6.6.1(f) Sovereign compute claims shall distinguish compute location from lawful sovereignty, technical control from legal control, hosting from public authority approval, infrastructure presence from infrastructure operation, secure architecture from certification, technical readiness from finance-readiness, and compute evidence from public authority decision.
6.6.1(g) Where sovereign compute work involves public authority data, rights-bearing data, Indigenous or community data, protected knowledge, health-sensitive data, cyber-sensitive data, infrastructure-sensitive data, export-control-sensitive technology, sanctions-sensitive actors, or national security-adjacent sensitivity, GCRI Canada shall apply heightened classification, access, localization, compute-to-data, cybersecurity, public-safe, and correction controls.
6.6.1(h) The controlling rule shall be that sovereign compute may be central to public-benefit resilience and lawful data stewardship, but GCRI Canada’s role remains evidence, methods, learning, safeguards, and correction.
6.6.2 Edge Compute, Cloud Compute, High-Performance Computing, Confidential Computing, Secure Enclaves, Air-Gapped Environments, and Compute-to-Data. 6.6.2(a) GCRI Canada’s compute-related scope may include edge compute, cloud compute, high-performance computing, sovereign cloud, public-sector cloud, hybrid cloud, confidential computing, secure enclaves, trusted execution environments, air-gapped environments, clean rooms, controlled rooms, data rooms, compute-to-data environments, private AI environments, research compute, Observatory compute, and mission-critical compute systems.
6.6.2(b) Edge compute work may concern distributed processing, local inference, sensor-adjacent analysis, AI-RAN integration, DePIN interfaces, remote connectivity, low-latency systems, network resilience, public-safe dashboards, and data minimization, provided that GCRI Canada does not become the edge operator or field execution actor by default.
6.6.2(c) Cloud compute work may concern architecture, governance, access controls, data processing terms, model-provider terms, workload classification, public-good software deployment patterns, repository discipline, public authority learning, and secure collaboration, provided that GCRI Canada does not become a cloud operator, reseller, managed services provider, or data processor unless expressly and lawfully recorded within proper boundary.
6.6.2(d) High-performance computing work may concern compute-intensive models, simulation, digital twins, climate modeling, geospatial processing, AI evaluation, verifiable compute, workload records, energy implications, queue governance, secure access, and output review, provided that GCRI Canada does not operate HPC infrastructure or approve compute allocations as public authority or finance actor by default.
6.6.2(e) Confidential computing and secure enclave work may concern methods for protecting sensitive inputs, restricted datasets, public authority data, community data, health-sensitive data, protected knowledge, model weights, inference records, and derived outputs, provided that enclave use is documented by record and does not create certification, guarantee, or lawful compliance finding by default.
6.6.2(f) Air-gapped, clean-room, controlled-room, and compute-to-data environments shall be governed as high-sensitivity compute arrangements requiring authority, role, data, access, logging, output, publication, correction, and closeout controls.
6.6.2(g) Compute-related terms shall not be used to imply a stronger status than the record supports. “Sovereign,” “secure,” “confidential,” “trusted,” “verified,” “clean,” “air-gapped,” “public authority-ready,” “finance-ready,” or “Nexus-ready” shall require source records, scope, limits, review status, and correction path.
6.6.2(h) The controlling rule shall be that compute architecture may vary by risk and context, but every compute environment remains subject to records, access, security, public-safe review, and non-execution.
6.6.3 Compute Workload Records, Execution Context, Data Inputs, Model / Code Identity, Output Classification, Limitations, and Correction Path. 6.6.3(a) Compute workload records shall be required where compute activity materially supports evidence, methods, models, simulations, dashboards, maps, AI outputs, public authority learning, finance-facing evidence, Docket inputs, Grid inputs, Observatory records, technical baselines, public-good software, public-safe reports, controlled annexes, or correction decisions.
6.6.3(b) A compute workload record shall identify workload purpose, requester, steward, operator where applicable, compute environment, jurisdiction, hosting location, execution date, version, runtime context, data inputs, model identity, code identity, software dependencies, configuration, access roles, output category, review status, classification, permitted use, prohibited use, limitations, and correction path.
6.6.3(c) Execution context shall identify whether the workload ran on edge compute, cloud compute, sovereign cloud, public-sector cloud, university compute, high-performance compute, confidential computing, secure enclave, air-gapped environment, clean room, controlled room, compute-to-data environment, provider system, host system, public authority system, or GCRI Canada-controlled or GCRI Canada-accessed system.
6.6.3(d) Data input records shall identify source, lawful basis where applicable, authority to contribute, classification, rights-bearing data status, public authority data status, sovereign data status, community or protected knowledge status, retention, transfer, AI-use limits, publication limits, and correction rights.
6.6.3(e) Model and code identity shall identify model name, provider or steward, version where known, model card where available, system card where available, dataset dependencies where material, code repository, commit or release where applicable, license, IP status, security status, and known limitations.
6.6.3(f) Output classification shall identify whether the output is draft, internal, controlled, restricted, public-safe summary, public, not-for-reliance, public authority-facing, finance-facing, provider-facing, sponsor-facing, community-facing, under review, quarantined, superseded, withdrawn, or approved for a defined limited use.
6.6.3(g) Limitations shall identify data limitations, model limitations, code limitations, compute limitations, sampling limitations, simulation assumptions, uncertainty, confidence, validation status, human review status, public-safe limits, finance-safe limits, public authority limits, and downstream reliance limits.
6.6.3(h) Correction path shall identify who may report a workload issue, who reviews it, what records may be corrected, how outputs may be superseded or withdrawn, how downstream recipients are notified where appropriate, and how dependency records are updated.
6.6.3(i) The controlling rule shall be that compute outputs are not institutionally usable unless the workload record explains how they came into being and how they can be corrected.
6.6.4 Sovereign Data Zones and Jurisdiction-Aligned Compute Environments. 6.6.4(a) GCRI Canada may develop, reference, or support methods for sovereign data zones and jurisdiction-aligned compute environments where data, models, outputs, public authority materials, community materials, protected knowledge, or sensitive technical assets require alignment with Canadian, provincial, territorial, Indigenous, regional, national, sectoral, contractual, or public authority requirements.
6.6.4(b) A sovereign data zone shall identify jurisdictional basis, legal constraints, data categories, permitted custodians, permitted processors, permitted compute environments, permitted transfers, prohibited transfers, localization requirements, compute-to-data requirements where applicable, access controls, AI-use limits, cybersecurity controls, publication controls, correction rights, and closeout procedures.
6.6.4(c) Jurisdiction-aligned compute environments shall identify applicable law, host jurisdiction, data residency, data sovereignty, public authority restrictions, Indigenous data sovereignty where applicable, cross-border restrictions, cloud provider terms, subprocessor terms, law-enforcement-access risk where relevant, public authority access rules, retention, deletion, and auditability.
6.6.4(d) A claim that compute is “sovereign,” “jurisdiction-aligned,” “Canadian-controlled,” “public authority-safe,” “Indigenous-data-safe,” “privacy-safe,” or “secure” shall not be made unless supported by source records, scope, limits, review status, and correction path.
6.6.4(e) Sovereign data zones shall not create public authority approval, legal compliance certification, security certification, procurement approval, finance-readiness, provider preference, data-use permission, or execution authority by default.
6.6.4(f) Where multiple jurisdictions or communities are implicated, GCRI Canada shall preserve the most protective lawful posture where rights, public authority data, sovereignty, Indigenous or community knowledge, privacy, cybersecurity, controlled technology, or public trust are at risk.
6.6.4(g) Where a sovereign data zone or jurisdiction-aligned environment becomes stale, unlawful, unsafe, technically inadequate, overclaimed, or inconsistent with changed law or changed public authority requirements, GCRI Canada shall correct, supersede, withdraw, restrict, or reclassify the relevant records and outputs.
6.6.4(h) The controlling rule shall be that sovereignty claims must be records-valid, jurisdiction-specific, and bounded; sovereignty shall not be a slogan used to bypass safeguards.
6.6.5 Compute-to-Data as Default for Restricted, Sensitive, Controlled-Room, Clean-Room, Public Authority, Sovereign-Sensitive, or Rights-Bearing Data. 6.6.5(a) Compute-to-data shall be the preferred or default posture where restricted, sensitive, controlled-room, clean-room, public authority, sovereign-sensitive, rights-bearing, community-sensitive, Indigenous-knowledge-sensitive, health-sensitive, cyber-sensitive, infrastructure-sensitive, finance-sensitive, confidential, or protected knowledge data cannot be safely moved, copied, exported, embedded, published, or processed in ordinary environments.
6.6.5(b) Compute-to-data means that computation, analysis, model evaluation, summarization, classification, transformation, or review occurs in or near the controlled data environment, with outputs reviewed, classified, minimized, and released only if permitted by record.
6.6.5(c) Compute-to-data records shall identify data custodian, compute environment, authorized users, permitted workloads, prohibited workloads, model restrictions, code restrictions, output review, export controls, logs, retention, deletion, correction path, and closeout.
6.6.5(d) Output review shall determine whether outputs may leave the environment, whether they contain personal information, public authority information, protected knowledge, sensitive locations, confidential information, security-sensitive information, model-derived sensitive inference, or re-identification risk, and whether aggregation, redaction, generalization, restriction, or refusal is required.
6.6.5(e) Compute-to-data shall not be used as a pretext for unauthorized processing, model training, embedding, unrestricted inference, data reconstruction, public authority overclaim, public-safe bypass, or downstream sharing beyond permitted use.
6.6.5(f) Where compute-to-data is required but unavailable, GCRI Canada shall not move the data into a less protected environment merely for convenience. It shall restrict, delay, re-scope, use synthetic or public-safe substitutes where appropriate and lawful, route to the competent custodian, or refuse the activity.
6.6.5(g) Where outputs from compute-to-data are corrected, withdrawn, restricted, or reclassified, GCRI Canada shall review affected derivative outputs, public-safe reports, dashboards, maps, Docket inputs, Grid inputs, Academy materials, finance-facing materials, public authority materials, and handoff records.
6.6.5(h) The controlling rule shall be that when data cannot safely travel to compute, compute must travel to data or the work must not proceed.
6.6.6 Compute Security, Identity, Access, Logging, Segmentation, Key Management, Secret Handling, and Zero-Trust. 6.6.6(a) Compute environments used, accessed, referenced, or supported by GCRI Canada shall require compute security, identity controls, access controls, logging where lawful and appropriate, segmentation, key management, secret handling, zero-trust or equivalent security principles, incident handling, and closeout controls proportionate to risk.
6.6.6(b) Identity controls shall identify users, service accounts, machine identities, agents, administrators, maintainers, providers, public authority users, host users, GCRI Canada users, and external users, together with role, authority, access level, approval basis, and termination process.
6.6.6(c) Access controls shall apply least privilege, need-to-know, role-based or attribute-based access where appropriate, time limits where appropriate, separation of duties, approval gates for sensitive actions, privileged access controls, and periodic access review.
6.6.6(d) Logging shall record material access, workload execution, data movement, model use, code execution, output export, permission changes, administrative actions, failed access attempts, security events, correction actions, and closeout steps, subject to lawful privacy, confidentiality, and public authority restrictions.
6.6.6(e) Segmentation shall separate public, controlled, restricted, confidential, public authority, finance-sensitive, provider-sensitive, sponsor-sensitive, health-sensitive, cyber-sensitive, infrastructure-sensitive, protected knowledge, development, test, production, and public-facing environments where material.
6.6.6(f) Key management and secret handling shall address encryption keys, API keys, credentials, tokens, signing keys, repository secrets, model-provider credentials, dashboard credentials, cloud credentials, cryptographic material, rotation, revocation, storage, access, backup, recovery, and incident response.
6.6.6(g) Zero-trust or equivalent controls shall require verification of identity, device, workload, context, authorization, data classification, and permitted action rather than relying on network location, institutional affiliation, public authority title, provider status, sponsor status, or prior access.
6.6.6(h) Where compute security controls are absent, stale, violated, unsafe, or insufficient, GCRI Canada shall restrict access, suspend workloads, revoke credentials, rotate secrets, quarantine outputs, notify competent actors where appropriate, correct records, and preserve incident records.
6.6.6(i) The controlling rule shall be that compute trust must be earned by controls and records, not assumed from infrastructure labels or institutional proximity.
6.6.7 Compute Supply Chain, Cloud Provider, Data Processor, Vendor, and Critical Supplier Risk. 6.6.7(a) GCRI Canada shall treat compute supply chain, cloud provider, data processor, vendor, subprocessor, model provider, software supplier, hardware supplier, telecommunications provider, hosting provider, managed services provider, critical supplier, and dependency risk as material evidence and safeguard concerns where compute supports sensitive or reliance-bearing work.
6.6.7(b) Compute supply chain records shall identify provider, service, role, jurisdiction, subprocessors where material, data access, model access, administrative access, security posture, contractual terms, IP terms, incident obligations, audit or assurance status where available, continuity risk, exit path, and correction path.
6.6.7(c) Cloud provider and data processor review shall address lawful basis, processing terms, data residency, cross-border transfer, retention, deletion, model training or improvement terms, support access, law-enforcement access risk where relevant, breach notification, encryption, logging, subcontracting, and public authority restrictions.
6.6.7(d) Vendor and critical supplier risk shall address concentration risk, lock-in, dependency risk, service availability, security vulnerabilities, supply-chain compromise, geopolitical risk where relevant, sanctions or export-control issues, operational continuity, and public-safe implications.
6.6.7(e) Provider use by GCRI Canada shall not create provider endorsement, preferred-provider status, procurement recommendation, certification, recognition, finance-readiness, public authority approval, or market superiority.
6.6.7(f) Where compute suppliers provide sponsorship, discounts, credits, in-kind support, model access, cloud credits, equipment, or technical assistance, provider-neutrality, sponsor-non-control, conflict, public claims, data, IP, cybersecurity, and correction controls shall apply.
6.6.7(g) Where compute supply chain risk becomes material, GCRI Canada shall restrict, re-scope, segment, migrate, terminate, seek legal or cybersecurity review, revise public claims, notify affected actors where appropriate, and preserve risk and correction records.
6.6.7(h) The controlling rule shall be that compute dependencies are part of the evidence boundary; infrastructure providers shall not invisibly shape public-good truth.
6.6.8 Compute Outputs as Evidence Inputs, Not Authority by Default. 6.6.8(a) Compute outputs generated, received, reviewed, routed, published, dashboarded, mapped, modeled, simulated, or archived by GCRI Canada shall be treated as evidence inputs, analytical outputs, model outputs, workload outputs, technical outputs, or methods-support outputs, not authority by default.
6.6.8(b) Compute outputs shall not constitute public authority decisions, official guidance, regulatory findings, procurement approvals, public finance approvals, public warnings, emergency commands, GRF recognition, GRA finance-readiness, Protocol Authority effect, certification, provider endorsement, sponsor approval, investment advice, lending approval, insurance advice, underwriting, rating, guarantee, professional opinion, operational clearance, deployment authorization, market approval, or execution instruction by default.
6.6.8(c) Compute outputs shall be classified according to workload record, source data, model or code identity, compute environment, method, human review status, confidence where appropriate, uncertainty, limitations, public-safe status, finance-safe status where material, permitted use, prohibited use, and correction path.
6.6.8(d) Compute outputs shall not be represented as observed fact, verified evidence, official truth, public authority position, public-safe conclusion, finance-readiness conclusion, technical baseline, benchmark result, Docket status, Grid status, Academy outcome, or Protocol Authority status unless the relevant review and source record support the statement.
6.6.8(e) Compute-generated confidence scores, risk scores, performance metrics, forecasts, rankings, maps, dashboards, simulations, digital twin outputs, AI outputs, or benchmark outputs shall not become ratings, underwriting outputs, investment scores, credit scores, insurance scores, public authority determinations, procurement rankings, provider rankings, public warnings, or operational instructions by default.
6.6.8(f) Where compute outputs are externally shared, the material shall preserve output status, source, method, limitations, classification, boundary language, and correction path sufficient to prevent compute-as-authority overclaim.
6.6.8(g) Where compute outputs are later found to be erroneous, stale, unsafe, overclaimed, model-limited, data-limited, security-compromised, or improperly classified, GCRI Canada shall correct, supersede, withdraw, reclassify, restrict, notify where appropriate, and preserve correction records.
6.6.8(h) The controlling rule shall be that compute may produce outputs, but institutional meaning comes only from proper record, review, and authority.
6.6.9 Compute Benchmarks and Performance Claims as Public-Safe Technical Claims. 6.6.9(a) Compute benchmarks, performance claims, workload comparisons, latency claims, throughput claims, energy-efficiency claims, cost claims, resilience claims, security claims, sovereign-compute claims, confidentiality claims, AI-performance claims, simulation-performance claims, and public-good software performance claims shall be treated as public-safe technical claims.
6.6.9(b) Benchmark records shall identify benchmark purpose, system under test, workload, data, model or code, hardware, software, configuration, environment, provider participation, sponsor participation, test conditions, date, version, reproducibility where appropriate, limitations, conflicts, public-safe status, permitted claim, prohibited claim, and correction path.
6.6.9(c) Performance claims shall not imply provider superiority, procurement preference, certification, security certification, public authority approval, finance-readiness, rating, underwriting, guarantee, operational clearance, deployment approval, or market superiority unless the competent source record supports the claim.
6.6.9(d) Compute benchmarks shall not be used as procurement rankings, vendor rankings, investment recommendations, insurance indicators, credit indicators, public finance indicators, or certification evidence beyond their source-record limits.
6.6.9(e) Where provider-supplied, sponsor-supported, host-supported, cloud-credit-supported, or vendor-supported compute benchmarks are used, GCRI Canada shall apply conflict review, provider-neutrality review, test-condition review, public claims controls, and correction path.
6.6.9(f) Public-facing benchmark summaries shall preserve method, scope, limitations, non-certification status, non-procurement status, non-provider-endorsement status, non-finance-readiness status, non-public-authority-approval status, and correction path where material.
6.6.9(g) Where benchmark or performance claims are corrected, superseded, withdrawn, disputed, downgraded, or reclassified, GCRI Canada shall review derivative claims, dashboards, reports, data rooms, public authority materials, finance materials, provider materials, sponsor materials, and public-good software documentation.
6.6.9(h) The controlling rule shall be that compute performance claims must be technically useful without becoming market authority.
6.6.10 Compute Infrastructure Interface With Nexus Observatory, National Dense Cores, Regional Clusters, and Project SPVs. 6.6.10(a) Compute infrastructure may interface with Nexus Observatory, national dense cores, regional clusters, nodes, hubs, hotspots, AI-RAN systems, DePIN systems, digital twins, dashboards, public-safe maps, Truth Engine methods, Docket inputs, Grid inputs, National Consortium Companies, Project SPVs, qualified providers, hosts, public authorities, and public-good software systems as a technical evidence and methods domain.
6.6.10(b) Compute interface records shall identify the compute environment, owner, operator, host, provider, custodian, workload steward, data steward, model steward where applicable, GCRI Canada role, non-role, access level, data classification, AI-use limits, cybersecurity controls, public-safe status, public authority boundary, finance boundary, operational boundary, and correction path.
6.6.10(c) GCRI Canada’s methods support for compute infrastructure shall not make GCRI Canada the owner, operator, maintainer, funder, lender, guarantor, insurer, underwriter, rating actor, cloud provider, managed services provider, data processor by default, cybersecurity operator, public authority operator, or infrastructure execution actor for any Observatory node, national dense core, regional cluster, National Company, Project SPV, or provider system.
6.6.10(d) National dense core and regional cluster compute records shall distinguish public-good evidence and methods infrastructure from enterprise-stack execution, commercial cloud operation, National Company ownership, Project SPV asset ownership, public authority operation, and provider-managed services.
6.6.10(e) Project SPV compute interfaces shall include finance-safe language, public authority boundary language, provider-neutrality language, non-guarantee language, non-operation language, and correction path where GCRI Canada evidence or methods are used.
6.6.10(f) Observatory compute outputs shall identify source data, workload records, model or code identity, compute environment, confidence, uncertainty, limitations, public-safe classification, and correction path.
6.6.10(g) Where compute infrastructure records are corrected, superseded, restricted, compromised, migrated, terminated, or reclassified, GCRI Canada shall review affected dashboards, maps, public-safe reports, Docket records, Grid records, Academy materials, public authority materials, finance-facing materials, and handoff records.
6.6.10(h) The controlling rule shall be that compute infrastructure may support Nexus observability and readiness evidence, but GCRI Canada shall not become the infrastructure operator by interfacing with it.
6.6.11 Compute Finance-Readiness Inputs Without Financial Execution. 6.6.11(a) GCRI Canada may provide compute-related evidence inputs that support GRA, capital readers, public finance readers, insurers, lenders, underwriters, rating actors, National Consortium Companies, Project SPVs, public authorities, or other competent actors in understanding compute readiness, compute governance, data safeguards, AI governance, cybersecurity posture, workload classification, sovereign data zones, infrastructure dependencies, continuity risks, diligence gaps, and technical-baseline context.
6.6.11(b) Compute finance-readiness inputs shall identify source, scope, compute environment, workload records, data classifications, security controls, provider dependencies, sovereign data constraints, public authority constraints, confidence, uncertainty, limitations, finance-safe status, permitted use, prohibited use, non-reliance where appropriate, and correction path.
6.6.11(c) Compute evidence shall not become investment advice, securities offering, solicitation, brokerage, finder activity, placement activity, lending approval, credit approval, guarantee, insurance advice, insurance placement, underwriting, rating, public finance approval, capital commitment, finance-readiness, or GCRI Canada financial responsibility by default.
6.6.11(d) Compute benchmarks, security evidence, workload records, sovereign data-zone evidence, availability evidence, resilience evidence, cost evidence, or performance evidence shall not be used as ratings, underwriting conclusions, credit scores, investment signals, public finance approvals, guarantees, or capital commitments by GCRI Canada.
6.6.11(e) Any GRA-administered finance-readiness, proof-pack, capital-readability, insurance-readiness, RNFD, NFD, UNFSD, or capital-reader-room use of compute evidence shall preserve GCRI Canada’s role as evidence and methods contributor, not finance-readiness issuer.
6.6.11(f) Finance-facing compute materials shall include no-investment-advice, no-offer, no-solicitation, no-brokerage, no-finder, no-placement, no-lending, no-credit-approval, no-guarantee, no-insurance-advice, no-underwriting, no-rating, no-public-finance-approval, no-capital-commitment, and no-GCRI-Canada-finance-readiness language where material.
6.6.11(g) Where compute-related materials are misused to imply GCRI Canada finance authority, GCRI Canada shall correct, restrict, withdraw, notify GRA or affected actors where appropriate, seek regulated-perimeter review where material, and preserve correction records.
6.6.11(h) The controlling rule shall be that compute evidence may inform finance-readable diligence, but GCRI Canada shall not perform finance.
6.6.12 Compute Scope Without GCRI Canada Becoming Cloud Operator, Infrastructure Operator, Fund, Public Authority, or Licensed Execution Actor by Default. 6.6.12(a) GCRI Canada’s sovereign compute, edge compute, cloud compute, HPC, confidential computing, secure enclave, air-gapped, clean-room, controlled-room, and compute-to-data scope shall not make GCRI Canada a cloud operator, infrastructure operator, managed services provider, data processor by default, cybersecurity operator, telecommunications operator, public authority system operator, fund, lender, insurer, underwriter, rating actor, public finance approver, procurement authority, licensed professional actor, or execution actor by default.
6.6.12(b) GCRI Canada shall not operate cloud infrastructure, sell cloud services, provide managed compute services, manage production infrastructure, allocate sovereign compute as public authority, operate public authority systems, control enterprise workloads, guarantee uptime, provide service-level warranties, underwrite compute risk, rate compute providers, approve public finance, select compute vendors, or execute technology deployments by virtue of compute evidence or methods work.
6.6.12(c) GCRI Canada shall not become responsible for another actor’s compute architecture, security posture, data processing, model deployment, infrastructure operation, cloud contract, service levels, procurement, finance, insurance, regulatory compliance, public authority decision, customer claims, or operational incident by providing evidence, methods, technical baselines, public-good software, public authority learning, Docket inputs, Grid inputs, or correction records.
6.6.12(d) Compute operators, cloud providers, data processors, hosts, public authorities, National Consortium Companies, Project SPVs, providers, licensed actors, universities, and other competent actors shall remain responsible for their own compute operations, contracts, data processing, security, service levels, legal compliance, public claims, reliance, and corrections.
6.6.12(e) GCRI Canada may hand off compute evidence to competent actors where lawful downstream action may be needed, provided the handoff includes role, scope, limitations, source lineage, classification, data restrictions, cybersecurity obligations, public-safe status, finance-safe language where material, public authority boundary language, non-operation language, and correction path.
6.6.12(f) Where any compute material is misused to imply GCRI Canada cloud operation, infrastructure operation, sovereign compute authority, public authority approval, procurement authority, fund status, finance-readiness, certification, security guarantee, provider endorsement, rating, underwriting, public finance approval, or execution, GCRI Canada shall correct, restrict, withdraw, issue public-safe clarification where appropriate, and preserve correction records.
6.6.12(g) No compute-related agreement, data arrangement, secure enclave, cloud account, repository, dashboard, workload record, public-good software deployment, public authority learning environment, National Company interface, Project SPV interface, or provider interface shall be interpreted to expand GCRI Canada’s authority beyond its non-executing public-benefit role unless a lawful records-valid instrument expressly states a bounded function consistent with this Charter and applicable law.
6.6.12(h) The controlling rule shall be that GCRI Canada may help make compute trustworthy, sovereign-compatible, public-safe, and correctable, but it shall not become the compute business, the infrastructure authority, the fund, the public authority, or the execution actor.
6.7 Blockchain, Distributed Ledger Technology, Web3, DePIN, Proof Infrastructure, and On-Chain Anchoring
6.7.1 Blockchain and Distributed Ledger Technology as Evidence, Record, Anchoring, Proof, and Interoperability Domains. 6.7.1(a) Blockchain and distributed ledger technology shall be treated within GCRI Canada’s mandate as evidence, record, anchoring, proof, interoperability, technical-baseline, public-good software, public authority learning, public-safe publication, and correctionability domains, not as financial, market, public authority, legal entitlement, or execution domains by default.
6.7.1(b) GCRI Canada may research, evidence, compare, model, document, teach, publish, steward, route, and correct blockchain-related records, distributed ledger records, anchoring methods, hash records, proof receipts, cryptographic attestations, DePIN records, smart-contract records, wallet-control records, role-claim records, entitlement-signal records, repository records, public-good software, public-safe reports, and technical baseline materials.
6.7.1(c) Blockchain and distributed ledger work may support source integrity, timestamping, tamper-evidence, provenance tracking, proof-of-submission, proof-of-custody, proof-of-method-execution, proof-of-evidence-receipt, record synchronization, cross-entity interoperability, Docket inputs, Grid inputs, Observatory methods, Truth Engine methods, Protocol Authority support, and correction records, provided that the proof meaning is records-valid and bounded.
6.7.1(d) No blockchain, distributed ledger, hash, anchor, token, wallet record, smart contract, cryptographic attestation, proof receipt, DePIN record, or on-chain event shall be treated as self-executing institutional authority, legal truth, public authority act, GRF recognition, GRA finance-readiness, Protocol Authority effect, certification, procurement approval, provider preference, public warning, emergency command, professional advice, market approval, or execution consequence by default.
6.7.1(e) Blockchain evidence shall distinguish the existence of a record from the truth of the record, the timestamp of a record from the validity of the record, the hash match of a record from the authority of the record, the submission of evidence from the acceptance of evidence, and the anchoring of a claim from the truth or authorization of the claim.
6.7.1(f) GCRI Canada shall not use blockchain or distributed ledger terminology to obscure legal separateness, non-execution, public authority boundaries, finance boundaries, provider neutrality, sponsor non-control, data safeguards, privacy, protected knowledge controls, public-safe claims discipline, or correctionability.
6.7.1(g) Where blockchain or distributed ledger systems are used in relation to public authorities, finance-facing actors, providers, sponsors, National Consortium Companies, Project SPVs, public-good records, technical baselines, public-safe reports, or community-sensitive materials, GCRI Canada shall require heightened review of authority meaning, data exposure, public claims, regulated perimeter, cybersecurity, custody, and correction path.
6.7.1(h) The controlling rule shall be that blockchain may strengthen record integrity, but it shall not make the record authoritative beyond the lawful source, role, scope, review, and correction path.
6.7.2 Web3 and DePIN as Technology Domains Subject to Evidence, Methods, Data, Cybersecurity, and Public-Safe Claims Discipline. 6.7.2(a) Web3 and DePIN shall be treated as technology domains subject to GCRI Canada’s evidence, methods, data, cybersecurity, privacy, public-safe publication, public authority boundary, finance-boundary, provider-neutrality, sponsor-non-control, claims-discipline, and correctionability rules.
6.7.2(b) GCRI Canada may study, evidence, compare, test, document, teach, publish, and correct Web3 and DePIN systems as public-benefit technical systems, including decentralized infrastructure networks, distributed sensing systems, distributed compute systems, storage systems, identity systems, coordination systems, cryptographic proof systems, incentive systems, token-linked systems, and public-good interoperability systems.
6.7.2(c) Web3 or DePIN status shall not by itself create public-good legitimacy, decentralization legitimacy, public authority approval, procurement approval, certification, recognition, finance-readiness, provider preference, community consent, public-safe status, security status, infrastructure readiness, or execution authority.
6.7.2(d) DePIN records shall identify device identity, device owner, operator, host, provider, hardware class, firmware or software version where material, sensor source, location sensitivity, uptime claim, data source, incentive structure where material, proof method, calibration status, spoof risk, custody, data classification, public-safe status, and correction path.
6.7.2(e) Web3 systems involving tokens, payments, incentives, governance rights, asset claims, access rights, yield, staking, rewards, financial promotion, custody, trading, settlement, or market-like activity shall require regulated-perimeter review before GCRI Canada engages, references, publishes, routes, or permits public claims beyond neutral technical evidence.
6.7.2(f) Decentralization claims shall be treated as public claims requiring records. Claims that a system is decentralized, community-owned, trustless, censorship-resistant, public-good, autonomous, immutable, transparent, privacy-preserving, secure, sovereign, or incorruptible shall require source records, scope, limitations, review status, and correction path.
6.7.2(g) Where Web3 or DePIN participation involves providers, sponsors, hosts, public authorities, communities, National Companies, Project SPVs, capital readers, or token-linked actors, GCRI Canada shall apply conflict review, public claims controls, finance-boundary review where material, data safeguards, cybersecurity review, and correction controls.
6.7.2(h) The controlling rule shall be that Web3 and DePIN may be studied as public-benefit technical domains, but decentralization language shall not bypass evidence, law, safeguards, or institutional boundaries.
6.7.3 Proof Infrastructure, Proof Receipts, Anchoring, Hashes, Tokenized Records, Smart Contracts, Role Claims, and Entitlement Signals. 6.7.3(a) Proof infrastructure, proof receipts, anchors, hashes, tokenized records, smart contracts, role claims, entitlement signals, cryptographic attestations, signatures, role keys, and other proof-related artifacts shall be governed as technical instruments whose meaning is defined by the source record, issuer, authority, scope, method, limits, permitted use, prohibited use, and correction path.
6.7.3(b) Proof infrastructure may support proof of existence, proof of timestamp, proof of submission, proof of custody, proof of method execution, proof of review step, proof of evidence receipt, proof of version, proof of signature, proof of source match, proof of role claim, proof of access state, or proof of technical event, provided that the proof type and limits are recorded.
6.7.3(c) A proof receipt shall identify issuer, recipient where applicable, record referenced, hash or identifier where applicable, timestamp, version, proof type, source record, authority status, non-authority status, classification, permitted use, prohibited use, public claims limits, revocation or supersession path where applicable, and correction path.
6.7.3(d) Anchoring shall distinguish anchoring a record from validating a claim. A hash or anchor may demonstrate that a particular record existed in a particular form at a particular time, but it shall not demonstrate that the record was true, complete, lawfully obtained, public-safe, finance-ready, recognized, certified, approved, or execution-ready.
6.7.3(e) Tokenized records shall not create ownership, entitlement, license, access right, investment interest, governance right, public authority status, recognition, certification, finance-readiness, procurement status, provider status, or execution right unless a competent source record and applicable law create such effect.
6.7.3(f) Role claims and entitlement signals shall not be treated as valid merely because they appear in a wallet, smart contract, role key, credential, proof receipt, registry, dashboard, or on-chain record. Role claims and entitlement signals require competent issuer, scope, status, expiration where applicable, revocation path, and correction path.
6.7.3(g) Smart contracts used to route, display, record, anchor, or signal status shall not override the Charter, Bylaw, public authority requirements, GRF authority, GRA authority, Protocol Authority authority, data restrictions, public-safe review, legal review, or correctionability.
6.7.3(h) The controlling rule shall be that proof infrastructure may prove bounded technical events, but it shall not prove authority beyond the record that grants it.
6.7.4 No Token, Ledger Entry, Smart Contract, Hash, Anchor, or Proof Receipt Creates Authority by Default. 6.7.4(a) No token, ledger entry, smart contract, hash, anchor, proof receipt, wallet entry, signature, role key, decentralized identifier, verifiable credential, NFT, on-chain badge, DePIN record, cryptographic attestation, or blockchain event shall create authority by default.
6.7.4(b) Such artifacts shall not create public authority meaning, official guidance, regulatory approval, procurement approval, public finance approval, funding approval, public warning, emergency command, sovereign obligation, GRF recognition, GRA finance-readiness, Protocol Authority effect, certification, provider endorsement, sponsor approval, community consent, professional opinion, investment advice, lending approval, insurance approval, underwriting, rating, guarantee, operational clearance, deployment authorization, market approval, infrastructure operation, or execution authority by default.
6.7.4(c) Authority-bearing meaning may arise only where a competent actor with proper role lawfully creates such meaning through a records-valid instrument, process, or source record, and only within the scope, limits, duration, classification, public claims controls, and correction path of that instrument.
6.7.4(d) A cryptographic artifact shall not be used to bypass legal capacity, Board authority, public authority procedure, regulated-perimeter review, certification procedure, recognition procedure, finance-readiness procedure, procurement procedure, data agreement, IP agreement, public-safe review, community safeguard, or correction process.
6.7.4(e) Immutable or append-only technical design shall not prevent correction, supersession, withdrawal, retraction, revocation, downgrade, reclassification, public-safe clarification, or downstream notice. Correction shall be implemented through records-valid correction layers, superseding entries, revocation records, public-safe notices, off-chain records, and dependency updates where required.
6.7.4(f) Where a token, ledger entry, smart contract, hash, anchor, or proof receipt is likely to be interpreted as authority, the artifact, interface, dashboard, registry, data room, or public material shall include boundary language sufficient to prevent false reliance.
6.7.4(g) Where any such artifact is misused to claim authority, GCRI Canada shall correct, restrict, withdraw, notify affected actors where appropriate, preserve correction records, and review whether name-use, access, interface, or legal remedies are required.
6.7.4(h) The controlling rule shall be that cryptographic existence is not institutional authority.
6.7.5 No PII, Rights-Bearing Sensitive Data, Protected Source Data, Public Authority Sensitive Data, Community-Protected Data, or Protected Knowledge in Public Repositories or On-Chain Artifacts. 6.7.5(a) GCRI Canada shall not place personal information, rights-bearing sensitive data, protected source data, public authority sensitive data, community-protected data, Indigenous or local protected knowledge, health-sensitive data, cyber-sensitive data, infrastructure-sensitive data, confidential data, privileged material, controlled annex material, or other restricted data in public repositories, public ledgers, irreversible public artifacts, public smart contracts, public tokens, public hashes where vulnerable to inference, public metadata, or public on-chain artifacts where such placement would be unlawful, unsafe, irreversible, non-correctable, or inconsistent with permitted use.
6.7.5(b) Public-chain publication, anchoring, hashing, metadata creation, tokenization, or proof issuance shall be reviewed for whether the artifact itself, alone or in combination with other information, could expose identity, location, sensitive source, public authority information, protected knowledge, community information, infrastructure information, health-sensitive information, or confidential relationship.
6.7.5(c) Hashing shall not be presumed safe. Where the underlying data is small, guessable, structured, unique, sensitive, or susceptible to dictionary attack, linkage attack, re-identification, metadata inference, or future disclosure, hashing may expose protected information and shall require review.
6.7.5(d) Metadata shall be treated as potentially sensitive. Wallet addresses, timestamps, transaction paths, gas payments, file names, repository paths, contributor identifiers, device identifiers, location references, public authority identifiers, project identifiers, or relationship graphs may create privacy, security, public authority, finance, provider, sponsor, or community risk.
6.7.5(e) Where proof of a sensitive record is required, GCRI Canada shall prefer privacy-preserving, off-chain, controlled, permissioned, salted, commitment-based, zero-knowledge, enclave-based, or other safer approaches where appropriate and lawful, subject to records-valid explanation and correction path.
6.7.5(f) Community, Indigenous, local, and protected knowledge shall not be tokenized, anchored, mapped, hashed, publicized, embedded, or placed in public proof systems without records-valid safeguards, including consent or non-consent treatment where applicable, cultural protocol review, protected knowledge controls, public-safe review, withdrawal or restriction path, and remedy path.
6.7.5(g) Where restricted data is improperly placed in a public repository or on-chain artifact, GCRI Canada shall immediately classify the incident, restrict references, remove or suppress off-chain access where possible, issue correction or withdrawal records, notify affected actors where appropriate and lawful, review downstream dependencies, and adopt prevention measures, recognizing that on-chain removal may be technically impossible.
6.7.5(h) The controlling rule shall be that irreversible publication is incompatible with protected data unless the record, law, safeguards, and public-safe review clearly permit it.
6.7.6 DePIN Evidence Quality, Device Identity, Sensor Integrity, Spoof Detection, Uptime Claims, Location Claims, Hardware Claims, and Proof-of-Competence Claims. 6.7.6(a) DePIN evidence quality shall require disciplined treatment of device identity, sensor integrity, operator identity where material, host context, hardware claims, firmware and software status, uptime claims, location claims, proof methods, incentive effects, spoof detection, calibration, custody, confidence, uncertainty, limitations, and correction path.
6.7.6(b) Device identity records shall identify device type, device identifier, owner or steward, operator, host, provider, hardware class, firmware or software version where material, deployment context, location sensitivity, public-safe status, and correction path.
6.7.6(c) Sensor integrity records shall identify sensor type, calibration status, data quality, tamper resistance, environmental conditions, sampling limits, latency, coverage, uptime, maintenance status where available, spoof risk, and method of validation where any.
6.7.6(d) Uptime claims shall identify measurement period, measurement method, reporting source, network dependency, outage treatment, maintenance treatment, data gaps, provider-supplied assumptions, incentive effects, and limitations. Uptime claims shall not become service-level guarantees, investment claims, insurance claims, finance-readiness, procurement claims, or operational authority by default.
6.7.6(e) Location claims shall identify precision, verification method, update frequency, location sensitivity, spoofing risk, relocation risk, public-safe limits, and whether public release requires generalization, aggregation, redaction, or restriction.
6.7.6(f) Hardware claims shall identify source, manufacturer or supplier where relevant, configuration, version, capacity, dependency, security status, test condition, and limitation. Hardware claims shall not imply certification, procurement eligibility, provider preference, public authority approval, or performance guarantee by default.
6.7.6(g) Proof-of-competence claims, proof-of-coverage claims, proof-of-location claims, proof-of-uptime claims, proof-of-storage claims, proof-of-compute claims, proof-of-sensing claims, and similar claims shall identify proof method, adversarial risk, independence, public-safe status, and correction path, and shall not create certification, recognition, finance-readiness, public authority approval, or provider endorsement by default.
6.7.6(h) The controlling rule shall be that DePIN evidence is only as strong as its device, sensor, location, proof, and correction records.
6.7.7 Blockchain / DePIN Interface With Nexus Observatory Methods, Nexus Truth Engine Methods, and Protocol Authority. 6.7.7(a) Blockchain, distributed ledger technology, DePIN, proof infrastructure, and on-chain anchoring may interface with Nexus Observatory methods, Nexus Truth Engine methods, Docket, Grid, Rails, Academy, public-safe reporting, and Nexus Standards / Protocol Authority only through records-valid, role-bound, public-safe, data-safe, cybersecurity-reviewed, and correctionable instruments.
6.7.7(b) Nexus Observatory interfaces may use blockchain or DePIN records as evidence inputs concerning timestamp, device record, sensor source, proof of submission, proof of custody, proof of location where adequately supported, proof of uptime where adequately supported, proof of observation, or proof of record integrity, but shall not treat such records as official observations, public warnings, emergency commands, public authority findings, or infrastructure operation by default.
6.7.7(c) Nexus Truth Engine methods may compare blockchain, DePIN, off-chain, public authority, provider, host, sensor, AI, geospatial, cyber, community, and other records for confidence, corroboration, dispute, spoof, stale evidence, missing evidence, and correction triggers, provided that no automated proof source is treated as absolute truth.
6.7.7(d) Protocol Authority interfaces may use proof infrastructure, role keys, smart-license logic, proof receipts, entitlement signals, anchoring discipline, or technical validity surfaces only where Protocol Authority records define the effect. GCRI Canada support shall not itself create protocol effect.
6.7.7(e) Blockchain or DePIN interfaces with Observatory, Truth Engine, or Protocol Authority shall identify owner, operator, steward, issuer, proof type, source record, authority status, non-authority status, data classification, public-safe status, cybersecurity controls, correction path, and public claims limits.
6.7.7(f) Where blockchain or DePIN records are corrected, superseded, withdrawn, disputed, restricted, or found compromised, GCRI Canada shall review affected Observatory records, Truth Engine confidence records, Docket inputs, Grid inputs, public-safe reports, Protocol Authority inputs, dashboards, maps, and derivative claims.
6.7.7(g) Public claims concerning blockchain or DePIN integration with Nexus Observatory, Truth Engine, or Protocol Authority shall distinguish technical support from recognition, finance-readiness, protocol effect, public authority action, certification, procurement, public warning, emergency command, and execution.
6.7.7(h) The controlling rule shall be that proof infrastructure may feed Nexus methods, but Nexus authority remains role-bound, record-bound, and correctionable.
6.7.8 Smart Contracts and Automated Workflows as Technical Instruments, Not Legal Authority by Default. 6.7.8(a) Smart contracts and automated workflows used, studied, referenced, or supported by GCRI Canada shall be treated as technical instruments, not legal authority, public authority, finance authority, procurement authority, certification authority, recognition authority, protocol authority, professional authority, or execution authority by default.
6.7.8(b) Smart contracts may encode workflow rules, access gates, submission receipts, proof receipts, role signals, status displays, entitlement signals, routing logic, escrow-like technical states, or automated notifications, provided that their legal, institutional, and public-facing meaning is defined by competent source records and applicable law.
6.7.8(c) Automated workflows shall not bind GCRI Canada, bind another actor, transfer assets, approve finance, approve procurement, issue recognition, issue certification, create public authority action, create protocol effect, issue public warnings, trigger emergency commands, publish materials, release restricted data, or execute operational actions unless expressly authorized by lawful record, proper approval gates, and proper safeguards.
6.7.8(d) Any smart contract or automated workflow with external effect shall require records identifying purpose, code identity, version, owner, operator, administrator, authority, non-authority, trigger conditions, permissions, approval gates, override controls, emergency stop or pause controls where applicable, data used, outputs, public claims limits, cybersecurity review, legal review where material, and correction path.
6.7.8(e) Smart-contract immutability shall not override correctionability. Where a smart contract produces wrong, unsafe, unauthorized, stale, overclaimed, or restricted results, GCRI Canada shall use pause controls, superseding records, correction notices, withdrawal notices, off-chain correction records, access restrictions, and downstream notices where appropriate.
6.7.8(f) Smart-contract or automated-workflow interfaces shall not obscure who is responsible for decisions, data handling, public claims, security, errors, corrections, and downstream consequences.
6.7.8(g) Where smart-contract language, interface design, token design, or workflow automation is likely to mislead users into believing that technical execution equals legal authority, GCRI Canada shall require redesign, boundary language, access restriction, or refusal.
6.7.8(h) The controlling rule shall be that code may execute technical steps, but code does not become law, governance, public authority, finance, certification, recognition, or GCRI Canada authority by default.
6.7.9 Key Management, Wallet Controls, Signing Authority, Token Controls, Custody Boundaries, and Incident Response. 6.7.9(a) Blockchain, proof infrastructure, tokenized-record, DePIN, and on-chain anchoring work involving GCRI Canada shall require key management, wallet controls, signing authority, token controls, custody boundaries, access controls, incident response, and correction procedures proportionate to risk.
6.7.9(b) Key management records shall identify key type, purpose, owner, custodian, authorized signers, access method, storage method, backup method, recovery method, rotation, revocation, compromise procedure, and closeout.
6.7.9(c) Wallet controls shall identify wallet purpose, ownership, custody, authorized users, permitted transactions, prohibited transactions, signing thresholds, spending limits where applicable, non-financial status where applicable, token restrictions, role restrictions, audit trail, and incident procedure.
6.7.9(d) Signing authority shall distinguish technical signing, record attestation, proof issuance, publication approval, contractual signature, corporate authorization, public authority authorization, Protocol Authority action, GRF action, GRA action, finance action, and execution authorization. No technical signature shall be treated as broader authority than the source record permits.
6.7.9(e) Token controls shall identify whether tokens are non-transferable, transferable, symbolic, access-related, role-related, proof-related, governance-related, financial, utility-like, restricted, revocable, non-reliance-bearing, or otherwise classified, and shall require regulated-perimeter review where financial, market, custody, payment, investment, or entitlement implications may arise.
6.7.9(f) Custody boundaries shall identify whether GCRI Canada holds, controls, accesses, signs with, or merely observes keys, wallets, tokens, proof systems, ledgers, or records. GCRI Canada shall not become a custodian, wallet provider, exchange, broker, dealer, payment service, transfer agent, fund, fiduciary, or financial intermediary by default.
6.7.9(g) Incident response shall address lost keys, compromised keys, unauthorized signatures, wallet compromise, smart-contract exploit, token misuse, fraudulent proof receipts, false role claims, unauthorized anchoring, data exposure, public claims misuse, provider misuse, sponsor misuse, public authority confusion, finance overclaim, and downstream dependency.
6.7.9(h) The controlling rule shall be that cryptographic control must be mapped precisely because signing power can be mistaken for institutional authority.
6.7.10 Public Claims About Blockchain, DePIN, Tokenization, Proof, Anchoring, or Decentralization. 6.7.10(a) Public claims about blockchain, distributed ledger technology, Web3, DePIN, tokenization, proof infrastructure, proof receipts, anchoring, hashes, smart contracts, wallets, role keys, entitlement signals, decentralization, immutability, transparency, trustlessness, security, privacy, public-good status, or interoperability shall be controlled, records-valid, public-safe, finance-safe where material, and correctionable.
6.7.10(b) Claims that a record is “verified,” “validated,” “trusted,” “proof-backed,” “on-chain,” “immutable,” “decentralized,” “public-good,” “tamper-proof,” “certified,” “recognized,” “finance-ready,” “protocol-valid,” “official,” “public-authority-ready,” “procurement-ready,” “secure,” or “sovereign” shall require source records, scope, limitations, authority status, review status, public claims limits, and correction path.
6.7.10(c) GCRI Canada shall avoid language implying that blockchain or DePIN eliminates the need for governance, law, review, safeguards, human accountability, public-safe publication, data protection, public authority process, finance-boundary review, cybersecurity, or correction.