XIV. CYBERSECURITY
14.1 Cybersecurity as Constitutional Safeguard
14.1.1 Cybersecurity as a Charter-Level Public-Benefit Obligation. 14.1.1(a) Cybersecurity shall be a Charter-level public-benefit obligation of GCRI Canada and shall apply to all systems, data, records, software, repositories, publications, dashboards, maps, APIs, AI systems, compute environments, communications systems, controlled rooms, public authority interfaces, Nexus interfaces, Observatory methods, Truth Engine methods, technical baselines, and public-safe outputs within GCRI Canada’s custody, control, stewardship, or material reliance.
14.1.1(b) Cybersecurity shall not be treated as a narrow information-technology function, back-office control, vendor responsibility, checklist exercise, insurance condition, procurement requirement, or post-incident remediation task. It shall be embedded into governance, legal authority, data classification, access control, research design, secure development, publication, release discipline, AI use, records management, repository discipline, public-safe communication, and correctionability.
14.1.1(c) GCRI Canada shall implement cybersecurity in a manner proportionate to its public-benefit purpose, non-executing role, evidence stewardship function, privacy and data rights duties, public authority boundaries, protected knowledge safeguards, and Nexus role separation.
14.1.1(d) Cybersecurity shall protect not only confidentiality, integrity, and availability, but also evidence integrity, institutional meaning, public trust, public-safe publication, role boundaries, correction paths, and the ability of GCRI Canada to remain a trusted upstream truth institution.
14.1.1(e) The controlling rule shall be that cybersecurity is constitutional infrastructure for public-good trust.
14.1.2 Cybersecurity as Protection of Evidence Integrity, Research Integrity, Public-Good Software, Technical Baselines, Records, Public Authority Data, Community-Protected Knowledge, Protected Knowledge, Personal Information, and Institutional Trust. 14.1.2(a) Cybersecurity shall protect evidence integrity, research integrity, public-good software, Open Technical Baselines, public-good reference architectures, repositories, release artifacts, records, registers, Gazette notices, public-safe publications, datasets, dashboards, maps, APIs, schemas, data contracts, model cards, dataset cards, system cards, benchmark cards, evaluation harnesses, proof receipts, observability records, Truth Engine records, and correction records.
14.1.2(b) Cybersecurity shall protect Personal Information, Rights-Bearing Data, Health-Sensitive Data, Public Authority Data, Cyber-Sensitive Data, Infrastructure-Sensitive Data, Finance-Sensitive Data, Commercially Sensitive Data, Community-Protected Data, Indigenous, Local, Territorial, Cultural, Environmental, and Protected Knowledge Data, Controlled Technology, credentials, keys, tokens, secrets, and confidential materials.
14.1.2(c) Cybersecurity controls shall preserve the authenticity, integrity, custody, provenance, source lineage, version state, authority state, access state, public-safe status, correction state, and dependency state of records and technical assets.
14.1.2(d) Cybersecurity weakness that allows records to be altered, systems to be accessed, repositories to be compromised, credentials to be exposed, public materials to be replaced, AI retrieval sources to be poisoned, dashboards to be manipulated, maps to be distorted, releases to be tampered with, or evidence chains to be broken shall be treated as a constitutional governance risk.
14.1.2(e) The controlling rule shall be that cybersecurity protects the trustworthiness of GCRI Canada’s truth function, not only its technology estate.
14.1.3 Cybersecurity as Applicable to Governance, Research, Data, AI, Compute, Repositories, Dashboards, APIs, Publications, Controlled Rooms, Nexus Interfaces, Observatory Methods, Truth Engine Methods, and Public-Safe Outputs. 14.1.3(a) Cybersecurity shall apply to governance systems, corporate records, Board and committee materials, officer delegations, member and participant records, research systems, evidence systems, data systems, AI systems, compute environments, repositories, dashboards, maps, APIs, schemas, controlled rooms, clean rooms, data rooms, evidence rooms, public authority rooms, capital-reader rooms, no-download rooms, publication systems, communications systems, Academy systems, and Nexus interface systems.
14.1.3(b) Cybersecurity shall apply across the full lifecycle of systems and data, including design, selection, procurement, configuration, deployment, access, use, maintenance, integration, release, monitoring, incident response, correction, deprecation, retirement, archive, migration, and exit.
14.1.3(c) Cybersecurity shall apply to internal systems, externally hosted systems, shared systems, donated systems, sponsored systems, vendor systems, provider systems, cloud systems, AI systems, university systems, public authority systems, host systems, community interfaces, and Nexus-shared environments where GCRI Canada data, records, users, technical assets, or institutional meaning are involved.
14.1.3(d) Cybersecurity review shall not be bypassed because a system is experimental, public-good, research-oriented, temporary, low-cost, open-source, donated, sponsor-supported, provider-operated, public authority-adjacent, or used only for a pilot.
14.1.3(e) The controlling rule shall be that any system capable of affecting GCRI Canada data, records, outputs, access, or public meaning is within the cybersecurity perimeter.
14.1.4 Cybersecurity as Distinct From Law Enforcement, Regulatory Enforcement, Emergency Command, Managed Security Services, Public Warning, or Infrastructure Operation by GCRI Canada. 14.1.4(a) Cybersecurity stewardship by GCRI Canada shall not convert GCRI Canada into law enforcement, regulatory enforcement, emergency command, managed security services provider, public warning authority, public safety authority, infrastructure operator, security operations provider for third parties, certification body, or cyber regulatory authority.
14.1.4(b) GCRI Canada may develop methods, evidence, public-good software, technical baselines, evaluation harnesses, cybersecurity learning materials, public-safe summaries, incident-learning records, coordinated disclosure practices, and Nexus interface inputs without assuming operational security control over public authorities, providers, hosts, National Companies, Project SPVs, infrastructure operators, sponsors, universities, communities, or third-party systems.
14.1.4(c) GCRI Canada shall not issue official cyber warnings, public safety directives, emergency commands, regulatory determinations, compliance approvals, procurement approvals, managed security service commitments, incident response guarantees, or operational instructions by default.
14.1.4(d) Where cybersecurity work risks being misread as enforcement, warning, certification, provider approval, public authority action, finance-readiness, or execution, GCRI Canada shall narrow scope, add boundary language, restrict release, refer to the proper authority, or refuse the activity.
14.1.4(e) The controlling rule shall be that cybersecurity stewardship protects GCRI Canada’s mission without turning GCRI Canada into an executing cyber actor.
14.1.5 Cybersecurity as Preventive, Detective, Corrective, Recoverable, Auditable, and Continuously Improving. 14.1.5(a) Cybersecurity shall be preventive, detective, corrective, recoverable, auditable, and continuously improving.
14.1.5(b) Preventive controls shall include secure design, access control, least privilege, segmentation, hardening, encryption where appropriate, secure configuration, secrets governance, secure development, secure release, vendor review, AI-use controls, and public-safe release gates.
14.1.5(c) Detective controls shall include logging, monitoring, alerting, access review, vulnerability scanning where appropriate, dependency review, repository monitoring, secrets scanning, anomaly review, incident intake, and assurance review.
14.1.5(d) Corrective controls shall include patching, access revocation, key rotation, configuration correction, repository remediation, dataset withdrawal, dashboard correction, map withdrawal, AI index remediation, public-safe correction notice, controlled notice, and post-incident corrective action plans.
14.1.5(e) Recoverable controls shall include backups, restoration procedures, business continuity, disaster recovery, repository continuity, export readiness, migration readiness, critical system recovery, and continuity beyond key persons, vendors, providers, sponsors, hosts, or platforms.
14.1.5(f) Auditable controls shall include records, logs, approvals, review records, incident records, release records, vulnerability records, access records, assurance findings, and correction records.
14.1.5(g) The controlling rule shall be that cybersecurity is not a static state; it is an institutional discipline of prevention, detection, correction, recovery, evidence, and learning.
14.1.6 Cybersecurity as Proportionate to Risk, Data Class, System Criticality, Public Authority Sensitivity, Infrastructure Sensitivity, Cyber Sensitivity, Community Sensitivity, and Public-Safe Consequence. 14.1.6(a) Cybersecurity controls shall be proportionate to risk, data class, system criticality, user role, dependency impact, public authority sensitivity, infrastructure sensitivity, cyber sensitivity, community sensitivity, health sensitivity, finance sensitivity, commercial sensitivity, protected knowledge sensitivity, public-safe consequence, and correction difficulty.
14.1.6(b) Systems processing Restricted Data, Public Authority Data, Health-Sensitive Data, Cyber-Sensitive Data, Infrastructure-Sensitive Data, Community-Protected Data, Protected Knowledge, Controlled Technology, credentials, keys, tokens, secrets, or material evidence records shall receive heightened controls.
14.1.6(c) Systems that support public-safe publications, dashboards, maps, APIs, repositories, AI retrieval, technical releases, controlled rooms, public authority rooms, data rooms, capital-reader rooms, or Nexus interfaces shall be reviewed for reliance and public-meaning risk.
14.1.6(d) Low-risk systems may receive lighter controls only where classification, data use, access, public-safe consequence, and dependency review support that treatment.
14.1.6(e) The controlling rule shall be that cybersecurity must be risk-based without becoming risk-blind.
14.1.7 Cybersecurity as a Condition of Verifiable Compute, Verifiable Intelligence, Nexus Observatory Methods, Nexus Truth Engine Methods, Public-Good Software, and Open Technical Baselines. 14.1.7(a) Cybersecurity shall be a condition of verifiable compute, verifiable intelligence, Nexus Observatory methods, Nexus Truth Engine methods, public-good software, Open Technical Baselines, evaluation harnesses, benchmark harnesses, datasets, APIs, schemas, repositories, dashboards, maps, proof receipts, and technical release artifacts.
14.1.7(b) Compute or AI output shall not be treated as verifiable, reliable, public-safe, institutionally usable, or fit for Nexus interface use unless the data, model, environment, access, logs, outputs, provenance, release, and correction path are protected against unauthorized access, tampering, leakage, poisoning, misrouting, misuse, and silent alteration.
14.1.7(c) Verifiable compute and verifiable intelligence records shall preserve source authority, system integrity, execution environment, access history where material, model or system version, data classification, output classification, public-safe status, and correction path.
14.1.7(d) Public-good software and Open Technical Baselines shall be developed, reviewed, released, maintained, deprecated, and corrected under secure development, repository security, dependency governance, SBOM discipline where material, vulnerability management, signing or integrity controls where appropriate, and secure release gates.
14.1.7(e) The controlling rule shall be that verifiability requires security; otherwise technical proof can become trustworthy-looking insecurity.
14.1.8 Cybersecurity as Anti-Capture and Anti-Enclosure Discipline Where Vendor, Cloud, Tooling, Repository, Identity, or AI Dependencies Create Control Risk. 14.1.8(a) Cybersecurity shall function as anti-capture and anti-enclosure discipline where vendor, cloud, tooling, repository, identity, access-management, AI, analytics, dashboard, map, compute, hosting, communications, or platform dependencies create control risk.
14.1.8(b) GCRI Canada shall avoid cybersecurity architectures that create hidden dependency, vendor lock-in, sponsor control, provider control, single-platform dependency, key-person dependency, opaque access, irrecoverable records, non-portable repositories, unexportable data, unreviewable AI systems, or unavailable correction paths.
14.1.8(c) Critical systems shall be reviewed for portability, substitutability, backup, exportability, administrative continuity, key custody, emergency access, dependency risk, contractual control, data residency, exit readiness, and continuity.
14.1.8(d) Security tools and vendors shall not acquire control over evidence methods, public-good software, technical baselines, repositories, data, keys, correction chains, publication flows, or Nexus meaning beyond recorded authority.
14.1.8(e) The controlling rule shall be that cybersecurity must protect GCRI Canada from capture by the very tools used to secure it.
14.1.9 Cybersecurity as Board, Officer, Committee, Staff, Fellow, Advisor, Contributor, Provider, Vendor, Host, Sponsor, Partner, and Participant Responsibility. 14.1.9(a) Cybersecurity shall be a responsibility of the Board, officers, committees, staff, fellows, advisors, contributors, contractors, providers, vendors, hosts, sponsors, partners, universities, public authorities, communities, participants, and any actor with access to GCRI Canada systems, data, records, repositories, rooms, or technical assets.
14.1.9(b) The Board shall oversee cybersecurity as mission, risk, trust, public-benefit, and continuity discipline. Officers shall implement cybersecurity through delegations, policies, procedures, controls, training, incident response, assurance, and reporting. Committees shall review cybersecurity within their mandates. System owners and custodians shall manage cybersecurity in daily operations.
14.1.9(c) Staff, fellows, advisors, contributors, contractors, and participants shall follow access rules, classification rules, password and authentication rules, secrets rules, AI-use rules, secure collaboration rules, repository rules, public-safe release rules, and incident reporting duties.
14.1.9(d) Providers, vendors, hosts, sponsors, universities, public authorities, partners, and other external actors shall comply with security terms, access limits, confidentiality, data-use limits, incident notice, deletion or return obligations, and role-boundary controls applicable to their participation.
14.1.9(e) Cybersecurity responsibility shall be distributed, but accountability shall remain record-based and role-specific.
14.1.9(f) The controlling rule shall be that cybersecurity is everyone’s duty but no one’s unbounded authority.
14.1.10 Cybersecurity Records, Assurance, Training, and Incident Learning as Constitutional Technical Records. 14.1.10(a) Cybersecurity records, assurance records, training records, incident records, vulnerability records, access records, release records, repository records, key records, vendor review records, AI security review records, dashboard security records, map security records, API security records, controlled room security records, and correction records shall be constitutional technical records of GCRI Canada.
14.1.10(b) Cybersecurity records shall be sufficient to demonstrate authority, control design, access state, incident handling, vulnerability handling, corrective action, training, assurance, and Board or committee oversight where material.
14.1.10(c) Cybersecurity training shall be role-specific and shall address classification, access, phishing, secure collaboration, secrets, AI-use restrictions, repository security, public-safe release, incident reporting, public authority data, protected knowledge, and third-party risk.
14.1.10(d) Incident learning shall be recorded and converted into corrective action, training updates, technical updates, policy updates, assurance updates, and Board or committee reporting where material.
14.1.10(e) The controlling rule shall be that cybersecurity maturity shall be demonstrated by records, learning, correction, and assurance, not by claims.
14.2 Technology Governance Purpose
14.2.1 Technology Governance as the Governance of Systems, Tools, Platforms, Repositories, Compute, AI, Dashboards, APIs, Data Rooms, Controlled Rooms, Identity Systems, Communications Systems, and Technical Workflows. 14.2.1(a) Technology Governance shall mean the governance of systems, tools, platforms, repositories, compute environments, AI systems, dashboards, maps, APIs, schemas, data contracts, data rooms, controlled rooms, clean rooms, evidence rooms, public authority rooms, capital-reader rooms, no-download rooms, identity systems, access systems, communications systems, publication systems, collaboration systems, and technical workflows used by or for GCRI Canada.
14.2.1(b) Technology Governance shall apply to systems that are owned, licensed, hosted, donated, sponsored, shared, provided, operated, integrated, configured, maintained, or accessed by GCRI Canada or by third parties on its behalf.
14.2.1(c) Technology Governance shall cover system approval, classification, ownership, custody, access, configuration, security, privacy, data use, AI use, release, integration, monitoring, incident response, maintenance, continuity, correction, deprecation, retirement, archival, and exit.
14.2.1(d) Technology Governance shall not be limited to formal enterprise systems and shall include temporary tools, prototypes, pilots, proof-of-concept systems, spreadsheets, chat tools, AI tools, file-sharing systems, repositories, dashboards, and public interfaces where material risk exists.
14.2.1(e) The controlling rule shall be that every material technology surface capable of affecting GCRI Canada work must be governed before it becomes institutional infrastructure.
14.2.2 Technology Governance as Mission-Bounded, Non-Executing, Records-Valid, Secure, Privacy-Preserving, Sovereignty-Compatible, and Correctionable. 14.2.2(a) Technology Governance shall be mission-bounded, non-executing, records-valid, secure, privacy-preserving, sovereignty-compatible, public-safe, correctionable, anti-capture, and anti-enclosure aligned.
14.2.2(b) Technology systems shall be configured and used to support GCRI Canada’s evidence, methods, observability, ontology, public-good R&D, public-good software, Open Technical Baseline, public authority learning, Academy, public-safe publication, and Nexus interface functions without turning GCRI Canada into an operator, vendor, managed service provider, public authority, regulator, certifier, financial actor, public warning authority, or execution body.
14.2.2(c) Material technology systems shall be tied to records identifying owner, custodian, purpose, authority, system class, data class, access roles, security controls, privacy controls, AI-use status, public-safe status, dependency status, correction path, and retirement or exit path.
14.2.2(d) Technology decisions shall preserve lawful authority, data minimization, purpose limitation, access limitation, secure configuration, public-safe release, sovereign data requirements, compute-to-data where appropriate, versioning, no-silent-edit discipline, and correctionability.
14.2.2(e) The controlling rule shall be that technology serves the Charter only when it remains bounded, recorded, secured, and correctable.
14.2.3 Technology Governance as Distinct From Technology Ownership Where Systems Are Hosted, Shared, Licensed, Provided, Donated, Sponsored, or Operated by Third Parties. 14.2.3(a) Technology Governance shall be distinct from technology ownership. GCRI Canada may govern its use, data, access, records, outputs, public-safe status, and correction obligations in systems it does not own, including hosted, shared, licensed, provided, donated, sponsored, university-operated, public authority-operated, provider-operated, cloud-hosted, AI-provider-operated, or partner-operated systems.
14.2.3(b) System ownership, hosting, donation, sponsorship, licensing, or operation by a third party shall not give that third party control over GCRI Canada’s evidence, methods, records, repositories, public-good software, technical baselines, publications, public-safe outputs, correction decisions, controlled vocabulary, or institutional meaning.
14.2.3(c) GCRI Canada shall identify owner, operator, custodian, administrator, data controller or equivalent role where applicable, processor or equivalent role where applicable, maintainer, access approver, release authority, and correction authority for material systems.
14.2.3(d) Where third-party ownership or operation creates unacceptable dependency, access, sovereignty, cybersecurity, privacy, IP, public-safe, or correction risk, GCRI Canada shall restrict use, require controls, establish exit readiness, substitute systems, or refuse the arrangement.
14.2.3(e) The controlling rule shall be that GCRI Canada need not own every system it governs, but it must govern every system it materially relies upon.
14.2.4 Technology Governance as Applicable to Public-Good Technical Assets, Evidence Rail Systems, Truth Engine Methods, Observatory Methods, Academy Platforms, Public Authority Learning Systems, and Nexus Interfaces. 14.2.4(a) Technology Governance shall apply to public-good technical assets, evidence rail systems, Truth Engine methods, Observatory methods, Academy platforms, public authority learning systems, public-safe publication systems, technical baseline systems, evaluation harnesses, benchmark harnesses, software repositories, data pipelines, AI systems, dashboards, maps, APIs, schemas, data contracts, proof receipt systems, and Nexus interfaces.
14.2.4(b) Public-good technical assets shall be governed for security, integrity, access, release, IP, license, dependency, maintenance, vulnerability handling, anti-enclosure, anti-capture, public-safe documentation, and correction.
14.2.4(c) Evidence Rail, Truth Engine, and Observatory systems shall be governed for source lineage, custody, method versioning, data classification, AI-use controls, confidence and uncertainty handling, public-safe transformation, and correction path.
14.2.4(d) Academy and public authority learning systems shall be governed to prevent credential inflation, public authority guidance implication, public warning implication, provider preference, sponsor control, and unauthorized data exposure.
14.2.4(e) Nexus interfaces shall be governed to preserve GRF, GRA, Protocol Authority, Nexus Network, Nexus Universe, Nexus Observatory, Nexus Rails, Nexus Grid, Nexus Academy, National Company, Project SPV, provider, sponsor, host, public authority, university, community, and capital-reader role separation.
14.2.4(f) The controlling rule shall be that technology governance travels with the function the system supports.
14.2.5 Technology Governance as a Control Against Tool Sprawl, Shadow Systems, Unapproved AI Use, Informal Repositories, Uncontrolled Dashboards, and Silent Technical Drift. 14.2.5(a) Technology Governance shall prevent tool sprawl, shadow systems, unapproved AI use, informal repositories, uncontrolled dashboards, ungoverned maps, unmanaged APIs, uncontrolled spreadsheets, unsanctioned file sharing, unapproved chat-based workflows, unmanaged credentials, and silent technical drift.
14.2.5(b) Material systems shall be approved, classified, recorded, assigned to an owner and custodian, secured, reviewed, and linked to records before institutional use.
14.2.5(c) Shadow systems used to hold, process, publish, analyze, route, or expose material GCRI Canada data or records shall be brought under governance, suspended, migrated, restricted, archived, or decommissioned.
14.2.5(d) Unapproved AI tools, informal repositories, uncontrolled dashboards, and uncontrolled maps shall not be used for material data, public authority materials, restricted materials, protected knowledge, public-safe outputs, technical releases, or public claims.
14.2.5(e) Silent technical drift shall be treated as a governance risk where systems change without versioning, review, records, access review, public-safe review, release notes, correction path, or user notice.
14.2.5(f) The controlling rule shall be that convenience tools must not become unrecorded institutions.
14.2.6 Technology Governance as a Control Against Unauthorized Data Movement, Unauthorized Publication, Unauthorized Access, Unauthorized Model Training, and Unauthorized External Sharing. 14.2.6(a) Technology Governance shall control unauthorized data movement, unauthorized publication, unauthorized access, unauthorized downloads, unauthorized exports, unauthorized model training, unauthorized fine-tuning, unauthorized embedding, unauthorized retrieval, unauthorized AI vendor processing, unauthorized external sharing, and unauthorized repository exposure.
14.2.6(b) Systems shall be configured to enforce classification, access class, handling class, transfer rules, AI-use limits, publication rules, export controls, download controls, retention rules, and correction procedures.
14.2.6(c) Technology controls shall address data loss prevention where appropriate, access logs, approval workflows, API permissions, key management, token management, repository permissions, release gates, dashboard permissions, map permissions, room permissions, and AI-source permissions.
14.2.6(d) Unauthorized data movement shall be treated as a data incident, privacy incident, cybersecurity incident, public authority incident, protected knowledge incident, finance-boundary incident, or publication incident as applicable.
14.2.6(e) The controlling rule shall be that systems must be designed to prevent unauthorized movement before policy must punish it.
14.2.7 Technology Governance as a Control Against Provider Dependency, Sponsor Dependency, Cloud Dependency, Repository Dependency, and Key Person Dependency. 14.2.7(a) Technology Governance shall control provider dependency, sponsor dependency, cloud dependency, repository dependency, AI-provider dependency, platform dependency, data-room dependency, identity-provider dependency, communications dependency, and key person dependency.
14.2.7(b) Material systems shall be reviewed for continuity, substitutability, portability, exportability, backup, administrative continuity, documentation, credential custody, emergency access, vendor lock-in, contractual termination, data return, deletion, migration, and replacement feasibility.
14.2.7(c) No provider, sponsor, host, vendor, cloud platform, AI provider, repository platform, or individual shall hold practical veto power over GCRI Canada’s evidence, methods, repositories, records, software, technical baselines, public-safe releases, corrections, or continuity.
14.2.7(d) Critical systems shall require succession, redundancy, backup, recovery, exit readiness, and role separation proportionate to risk.
14.2.7(e) The controlling rule shall be that technological dependence shall not become institutional capture.
14.2.8 Technology Governance as a Control Against Technical Systems Being Misread as Authority. 14.2.8(a) Technology Governance shall prevent technical systems from being misread as authority, including dashboards, maps, AI outputs, digital twins, DePIN records, blockchain anchors, proof receipts, APIs, schemas, model outputs, evaluation scores, benchmark results, technical baselines, repository releases, system cards, dataset cards, and Observatory or Truth Engine outputs.
14.2.8(b) Technical systems shall include boundary language, status labels, version information, confidence and uncertainty treatment, limitations, update status, public-safe status, correction path, and role-boundary statements where material.
14.2.8(c) No dashboard, map, AI output, proof receipt, technical release, API, dataset, or repository artifact shall be represented as public warning, public authority decision, recognition, finance-readiness, certification, protocol effect, provider preference, sponsor validation, procurement approval, investment advice, or execution authority unless the proper institution and record create such authority.
14.2.8(d) User interfaces, badges, colors, scores, rankings, alerts, labels, release notes, and system messages shall not imply status or authority beyond the record.
14.2.8(e) The controlling rule shall be that technical visibility must not create institutional effect by design accident.
14.2.9 Technology Governance as Integrated With Privacy, Data Governance, AI Governance, IP Governance, Records Governance, Publication Governance, and Public Authority Boundary Governance. 14.2.9(a) Technology Governance shall be integrated with privacy governance, data governance, AI governance, intellectual property governance, records governance, publication governance, cybersecurity governance, repository governance, secure release discipline, public authority boundary governance, finance-boundary governance, protected knowledge safeguards, and Nexus role-separation governance.
14.2.9(b) System approval shall consider privacy, data rights, data classification, AI use, IP ownership, licensing, repository discipline, secure release, public-safe publication, public authority references, finance implications, sponsor and provider roles, public claims, retention, deletion, legal hold, correctionability, and assurance.
14.2.9(c) No technology system shall be approved solely on operational usefulness, cost, speed, convenience, sponsor availability, provider capability, public authority interest, or technical sophistication.
14.2.9(d) Technology governance records shall link to related data records, AI records, access records, repository records, release records, publication records, public authority records, third-party records, incident records, and correction records.
14.2.9(e) The controlling rule shall be that technology governance must integrate all governance surfaces that technology can affect.
14.2.10 Technology Governance Records, System Cards, Asset Registers, Risk Registers, and Assurance. 14.2.10(a) GCRI Canada shall maintain technology governance records, system cards, asset registers, risk registers, dependency registers, access records, configuration records, vendor records, AI system records, repository records, release records, incident records, and assurance records for material systems.
14.2.10(b) System cards shall identify system purpose, owner, custodian, vendor or provider where applicable, system class, data classes, access roles, integrations, AI-use status, public-safe status, security controls, privacy controls, dependency risks, limitations, incident history where material, correction path, continuity arrangements, and retirement path.
14.2.10(c) Asset registers shall identify material systems, tools, platforms, repositories, compute environments, dashboards, maps, APIs, identity systems, communications systems, rooms, and technical workflows.
14.2.10(d) Risk registers shall identify technology risks, cybersecurity risks, privacy risks, data risks, AI risks, dependency risks, provider risks, sponsor risks, public authority risks, public-safe risks, and continuity risks.
14.2.10(e) Assurance shall periodically review whether technology systems remain authorized, classified, secure, privacy-preserving, records-valid, public-safe, role-bounded, correctable, maintained, and exit-ready.
14.2.10(f) The controlling rule shall be that technology governance must be evidenced through system records and assurance, not assumed from use.
14.3 Cybersecurity Baseline
14.3.1 Minimum Cybersecurity Baseline for GCRI Canada Systems. 14.3.1(a) GCRI Canada shall maintain a minimum cybersecurity baseline for all material systems, scaled according to system classification, data class, user roles, public authority sensitivity, infrastructure sensitivity, cyber sensitivity, protected knowledge sensitivity, public-safe consequence, dependency impact, and system criticality.
14.3.1(b) The baseline shall include identity and access management, authentication, least privilege, need-to-know access, segmentation, encryption where appropriate, logging, monitoring, alerting, vulnerability management, patch management, secure configuration, hardening, backup, disaster recovery, secure development, secure release, vendor review, incident response, training, and assurance.
14.3.1(c) Systems that do not meet the applicable baseline shall not be used for material data, records, repositories, public-safe outputs, public authority data, protected knowledge, AI use, technical releases, or Nexus interfaces unless exception is lawful, recorded, risk-reviewed, time-bound, and mitigated.
14.3.1(d) The baseline shall be reviewed periodically and after material incidents, system changes, threat changes, vendor changes, data-class changes, or public-safe risk changes.
14.3.1(e) The controlling rule shall be that every material system must meet a defined security floor before it can support institutional work.
14.3.2 Identity and Access Management. 14.3.2(a) GCRI Canada shall maintain identity and access management controls for material systems to ensure that users, roles, permissions, administrators, service accounts, API keys, tokens, and machine identities are known, authorized, current, and revocable.
14.3.2(b) Identity and access management shall include account provisioning, role assignment, access approval, authentication, privileged access controls, access review, access expiration, access revocation, emergency access controls, service account governance, and access logging where material.
14.3.2(c) Accounts shall be linked to a person, role, organization, or approved system identity, and shall not be created or retained without authority, purpose, and owner.
14.3.2(d) Identity records shall be updated promptly when roles change, contracts end, participation ends, projects close, access expires, incidents occur, or good standing changes.
14.3.2(e) The controlling rule shall be that systems must know who or what is acting before institutional access is granted.
14.3.3 Multi-Factor Authentication Where Appropriate. 14.3.3(a) Multi-factor authentication shall be required where appropriate for material systems, privileged access, remote access, repositories, cloud systems, AI systems, data rooms, controlled rooms, public authority rooms, dashboards, APIs, administrative consoles, email, communications systems, and systems handling sensitive data.
14.3.3(b) Multi-factor authentication shall be proportionate to risk and shall be strongly preferred for systems containing Restricted Data, Personal Information, Health-Sensitive Data, Public Authority Data, Cyber-Sensitive Data, Infrastructure-Sensitive Data, Finance-Sensitive Data, Community-Protected Data, Protected Knowledge, keys, tokens, secrets, release artifacts, or material records.
14.3.3(c) Exceptions to multi-factor authentication shall be recorded, risk-reviewed, time-limited where appropriate, mitigated by compensating controls, and reviewed periodically.
14.3.3(d) MFA methods shall be selected and managed to reduce phishing, account takeover, recovery abuse, shared-device risks, and administrative bypass.
14.3.3(e) The controlling rule shall be that authentication strength must match the sensitivity of access.
14.3.4 Least Privilege and Need-to-Know Access. 14.3.4(a) GCRI Canada shall apply least privilege and need-to-know access to material systems, data, repositories, rooms, dashboards, APIs, AI systems, release processes, public authority materials, protected knowledge, and incident materials.
14.3.4(b) Users shall receive only the access required for their recorded role, purpose, authority, task, time period, and data class.
14.3.4(c) Access shall not be granted by status, visibility, seniority, sponsorship value, provider importance, public authority proximity, donor role, academic reputation, technical curiosity, or general participation.
14.3.4(d) Privileged access shall be minimized, logged where material, reviewed frequently, segregated where appropriate, and revoked promptly when no longer needed.
14.3.4(e) The controlling rule shall be that access is earned by role and purpose, not by association.
14.3.5 Segmentation and Environment Separation. 14.3.5(a) GCRI Canada shall use segmentation and environment separation where appropriate to protect data, systems, repositories, AI environments, compute workloads, dashboards, maps, APIs, controlled rooms, public authority rooms, capital-reader rooms, development environments, test environments, staging environments, production environments, and archive environments.
14.3.5(b) Segmentation shall separate public systems from internal systems, internal systems from restricted systems, development from production, test data from real data, public data from restricted data, public authority data from general data, protected knowledge from general research data, and AI experimental environments from approved production workflows where appropriate.
14.3.5(c) Environment separation shall prevent unauthorized data movement, accidental publication, credential reuse, cross-contamination, privilege escalation, retrieval leakage, and misuse of production data in testing.
14.3.5(d) Exceptions shall be recorded, justified, risk-reviewed, time-bound where appropriate, and subject to compensating controls.
14.3.5(e) The controlling rule shall be that separation reduces blast radius and prevents one system’s weakness from becoming institutional compromise.
14.3.6 Encryption in Transit and at Rest Where Appropriate. 14.3.6(a) GCRI Canada shall use encryption in transit and at rest where appropriate to protect data, records, communications, backups, repositories, cloud storage, portable media, controlled rooms, data rooms, AI data stores, embeddings, logs, credentials, keys, tokens, secrets, and technical assets.
14.3.6(b) Encryption decisions shall be proportionate to data class, access class, system criticality, public authority sensitivity, health sensitivity, cyber sensitivity, infrastructure sensitivity, protected knowledge sensitivity, finance sensitivity, and legal or contractual requirements.
14.3.6(c) Encryption keys shall be governed through key management controls, including owner, custodian, storage, rotation, revocation, backup, recovery, access limits, and compromise response.
14.3.6(d) Encryption shall not substitute for access control, data minimization, public-safe review, classification, or correctionability, but shall operate with those controls.
14.3.6(e) The controlling rule shall be that sensitive data should be protected in movement, storage, backup, and recovery.
14.3.7 Logging, Monitoring, Alerting, and Audit Trails. 14.3.7(a) GCRI Canada shall implement logging, monitoring, alerting, and audit trails proportionate to system risk, data class, access class, public authority sensitivity, protected knowledge sensitivity, cybersecurity risk, infrastructure risk, and public-safe consequence.
14.3.7(b) Logs may include authentication events, access events, privileged actions, administrative changes, repository changes, release events, data exports, API activity, dashboard access, map access, AI retrieval activity where appropriate, model or inference activity where appropriate, deletion, sealing, configuration changes, and incident actions.
14.3.7(c) Logs shall be protected against unauthorized access, tampering, deletion, overretention, sensitive data exposure, and unauthorized AI ingestion.
14.3.7(d) Monitoring and alerting shall be configured to detect unauthorized access, unusual activity, privilege misuse, data exfiltration, secrets exposure, repository compromise, release tampering, dashboard manipulation, API abuse, AI retrieval leakage, and system failure where material.
14.3.7(e) The controlling rule shall be that material systems must create evidence of security-relevant activity sufficient for detection, correction, and accountability.
14.3.8 Vulnerability Management and Patch Management. 14.3.8(a) GCRI Canada shall maintain vulnerability management and patch management practices for material systems, repositories, software, dependencies, containers, APIs, dashboards, AI systems, cloud environments, endpoints, identity systems, and technical assets.
14.3.8(b) Vulnerability management shall include identification, triage, severity classification, owner assignment, remediation planning, patching, compensating controls, coordinated disclosure where appropriate, verification, correction records, and closure.
14.3.8(c) Patch timelines shall be proportionate to severity, exploitability, exposure, affected data, public authority sensitivity, infrastructure sensitivity, cyber sensitivity, public-safe consequence, and dependency impact.
14.3.8(d) Vulnerabilities affecting public-good software, Open Technical Baselines, repositories, APIs, dashboards, maps, dataset releases, AI systems, controlled rooms, data rooms, public authority interfaces, or Nexus interfaces shall receive heightened review.
14.3.8(e) The controlling rule shall be that known vulnerabilities must be owned, timed, remediated, and recorded.
14.3.9 Secure Configuration and Hardening. 14.3.9(a) GCRI Canada shall apply secure configuration and hardening to material systems, cloud environments, compute environments, repositories, databases, dashboards, APIs, identity systems, collaboration systems, AI systems, controlled rooms, and public interfaces.
14.3.9(b) Secure configuration shall address default settings, unused services, public exposure, administrative access, network access, storage permissions, repository visibility, API permissions, logging, backup, encryption, secrets management, update settings, and security headers or equivalent controls where applicable.
14.3.9(c) Hardening shall reduce attack surface, prevent unauthorized access, limit unnecessary functionality, restrict data exports, prevent unsafe sharing, and enforce secure defaults.
14.3.9(d) Configuration changes to material systems shall be reviewed, recorded, and subject to rollback where appropriate.
14.3.9(e) The controlling rule shall be that systems shall not be trusted in default form where default form creates avoidable risk.
14.3.10 Backup, Disaster Recovery, and Business Continuity. 14.3.10(a) GCRI Canada shall maintain backup, disaster recovery, and business continuity controls proportionate to system criticality, data class, public authority sensitivity, evidence dependency, publication dependency, repository dependency, public-safe consequence, and correctionability.
14.3.10(b) Backup controls shall address backup frequency, storage location, encryption where appropriate, access control, restoration testing, retention, deletion, legal hold, public authority restrictions, protected knowledge restrictions, and sovereign data requirements.
14.3.10(c) Disaster recovery shall identify critical systems, recovery objectives, recovery order, responsible roles, alternate systems, emergency communications, data restoration, repository restoration, key recovery, and validation procedures.
14.3.10(d) Business continuity shall preserve GCRI Canada’s ability to protect data, maintain records, issue corrections, respond to incidents, secure repositories, maintain public-safe notices, and continue critical governance functions during disruption.
14.3.10(e) The controlling rule shall be that resilience includes the ability to restore trustworthy records and correction paths, not merely restart systems.
14.3.11 Secure Development and Secure Release. 14.3.11(a) GCRI Canada shall apply secure development and secure release controls to public-good software, APIs, schemas, data contracts, technical baselines, evaluation harnesses, benchmark harnesses, dashboards, maps, scripts, AI tools, data tools, repositories, and release artifacts.
14.3.11(b) Secure development shall include code review, maintainer review, security review, dependency review, license review, secrets scanning, vulnerability review, test discipline, branch protection, commit discipline, versioning, and documentation review where appropriate.
14.3.11(c) Secure release shall include release authority, release gates, release notes, versioning, tagging, signing or hashing where appropriate, SBOM or dependency inventory where material, known issues, rollback, emergency disablement, public-safe review, and correction path.
14.3.11(d) Releases shall not contain secrets, credentials, personal information, public authority restricted data, protected knowledge, cyber-sensitive data, infrastructure-sensitive data, unsafe examples, or exploit-enabling details unless expressly authorized and controlled.
14.3.11(e) The controlling rule shall be that technical assets must be secured before they become public-good infrastructure.
14.3.12 Vendor, Provider, Cloud, AI, Repository, and Subprocessor Security Review. 14.3.12(a) GCRI Canada shall conduct vendor, provider, cloud, AI, repository, and subprocessor security review for material systems, tools, platforms, services, hosting, processing, storage, compute, repository management, AI processing, data rooms, controlled rooms, dashboards, APIs, communications systems, and technical workflows.
14.3.12(b) Review shall assess security controls, identity controls, access controls, encryption, logging, data residency, subprocessor access, vulnerability management, incident notice, breach response, deletion, return, audit, exit readiness, AI training or non-training terms, confidentiality, public authority restrictions, protected knowledge restrictions, and controlled technology limits.
14.3.12(c) External security review shall be proportionate to data class, system criticality, public authority sensitivity, infrastructure sensitivity, cyber sensitivity, protected knowledge sensitivity, and public-safe consequence.
14.3.12(d) Vendors and providers shall not receive broader access or rights than necessary and shall not acquire control over GCRI Canada’s evidence, methods, records, repositories, public-good technical assets, corrections, or institutional meaning.
14.3.12(e) The controlling rule shall be that third-party systems are inside the risk perimeter when they touch GCRI Canada data, records, or trust.
14.3.13 Incident Response and Breach Handling. 14.3.13(a) GCRI Canada shall maintain cybersecurity incident response and breach handling procedures for suspected or confirmed incidents affecting systems, data, records, repositories, AI systems, dashboards, maps, APIs, publications, controlled rooms, public authority interfaces, third-party systems, or Nexus interfaces.
14.3.13(b) Incident response shall include intake, triage, severity classification, containment, preservation, investigation, impact assessment, notification review, legal review where applicable, public-safe review, correction, recovery, remediation, lessons learned, and closure.
14.3.13(c) Incident response may require access revocation, key rotation, token revocation, credential reset, system isolation, repository takedown, dashboard removal, map withdrawal, API restriction, release withdrawal, AI retrieval source removal, embedding deletion where appropriate, vendor notice, public authority notice, controlled notice, or public-safe notice.
14.3.13(d) Incidents shall be recorded and linked to affected systems, data, access records, publications, repositories, releases, vendors, corrections, and assurance.
14.3.13(e) The controlling rule shall be that incident response must contain harm, preserve truth, correct records, and improve controls.
14.3.14 Periodic Review, Testing, Training, and Assurance. 14.3.14(a) GCRI Canada shall periodically review, test, train, and assure cybersecurity controls according to risk, system criticality, data class, public authority sensitivity, infrastructure sensitivity, cyber sensitivity, protected knowledge sensitivity, public-safe consequence, and dependency impact.
14.3.14(b) Review and testing may include access review, configuration review, backup restoration testing, incident response exercises, vulnerability review, dependency review, repository review, secrets scanning, secure release review, vendor review, AI security review, dashboard review, API review, and public-safe release review.
14.3.14(c) Training shall be role-specific and shall address phishing, secure collaboration, password and MFA practices, access rules, data classification, secrets handling, AI-use restrictions, repository security, public authority data, protected knowledge, incident reporting, and public-safe publication.
14.3.14(d) Assurance findings shall be recorded, assigned, remediated, verified, and escalated to the Board or appropriate committee where material.
14.3.14(e) The controlling rule shall be that cybersecurity controls must be practiced, tested, corrected, and learned.
14.4 Security Classification and System Criticality
14.4.1 System Classification Requirement. 14.4.1(a) GCRI Canada shall classify material systems according to security class, data class, access class, handling class, release class, system criticality, public-safe consequence, public authority sensitivity, infrastructure sensitivity, cyber sensitivity, finance sensitivity, community or protected knowledge sensitivity, AI use, repository function, and Nexus interface function.
14.4.1(b) System classification shall occur before material use and shall be reviewed when system purpose, data, users, integrations, vendor, hosting, AI use, public exposure, or dependency changes.
14.4.1(c) Classification records shall identify system owner, custodian, purpose, authority, data classes, user roles, access rules, security controls, public-safe status, dependencies, incident history where material, correction path, and retirement plan.
14.4.1(d) Misclassified systems shall be reclassified, restricted, remediated, suspended, or retired where risk requires.
14.4.1(e) The controlling rule shall be that systems must be classified before they can be safely trusted.
14.4.2 Public System. 14.4.2(a) A Public System shall be a system intended for public access or public-facing use, including public websites, public reports, public repositories, public dashboards, public maps, public APIs, public dataset pages, public-safe notices, Academy public materials, or other externally visible systems.
14.4.2(b) Public Systems shall be reviewed for public-safe content, privacy, cybersecurity, metadata exposure, public authority references, finance references, sponsor and provider references, controlled vocabulary, accessibility, availability, integrity, and correction path.
14.4.2(c) Public Systems shall not expose Restricted Data, Personal Information, Public Authority Restricted Data, Cyber-Sensitive Data, Infrastructure-Sensitive Data, Finance-Sensitive Data, Community-Protected Data, Protected Knowledge, credentials, keys, tokens, secrets, or controlled technology unless lawfully authorized and public-safe.
14.4.2(d) Public Systems shall include boundary language where necessary to prevent public warning, public authority, finance-readiness, certification, recognition, provider preference, sponsor validation, or execution overclaim.
14.4.2(e) The controlling rule shall be that public access requires public-safe design and security.
14.4.3 Internal System. 14.4.3(a) An Internal System shall be a system intended for GCRI Canada internal use or authorized internal collaboration and not approved for public release by default.
14.4.3(b) Internal Systems may include internal collaboration tools, internal document systems, internal research tools, internal dashboards, internal registers, internal issue trackers, internal communications systems, and internal workflow systems.
14.4.3(c) Internal Systems shall be access-controlled, classified, secured, and protected against unauthorized external sharing, public-link exposure, unauthorized AI ingestion, informal publication, and uncontrolled export.
14.4.3(d) Internal System content shall not be used externally without public-safe review and publication authority.
14.4.3(e) The controlling rule shall be that internal availability does not equal external authority.
14.4.4 Confidential System. 14.4.4(a) A Confidential System shall be a system handling confidential, contractually restricted, sensitive internal, research-sensitive, provider-sensitive, sponsor-sensitive, host-sensitive, partner-sensitive, university-sensitive, or commercially sensitive materials.
14.4.4(b) Confidential Systems shall require access control, confidentiality obligations, logging where material, secure storage, AI-use restrictions, sharing limits, publication limits, retention controls, and correction path.
14.4.4(c) Confidential Systems shall not permit public links, uncontrolled downloads, unmanaged external sharing, unauthorized vendor access, or unauthorized AI processing.
14.4.4(d) Confidentiality shall not be used to avoid correction, public-safe disclosure where required, Board oversight, conflict review, or cybersecurity remediation.
14.4.4(e) The controlling rule shall be that confidential systems require controlled trust and accountable access.
14.4.5 Restricted System. 14.4.5(a) A Restricted System shall be a system handling data, records, technical assets, or workflows whose compromise, unauthorized access, disclosure, alteration, or misuse may create material legal, privacy, public authority, cybersecurity, infrastructure, finance, community, protected knowledge, safety, or public trust harm.
14.4.5(b) Restricted Systems may process Personal Information, Health-Sensitive Data, Public Authority Data, Cyber-Sensitive Data, Infrastructure-Sensitive Data, Finance-Sensitive Data, Community-Protected Data, Protected Knowledge, Controlled Technology, credentials, keys, tokens, secrets, incident records, or legal-hold materials.
14.4.5(c) Restricted Systems shall require heightened access control, MFA where appropriate, need-to-know restrictions, logging, encryption where appropriate, segmentation, AI-use restrictions, export controls, retention controls, backup controls, incident response, and periodic assurance.
14.4.5(d) Restricted Systems shall not be used casually, shared broadly, connected to unmanaged tools, or exposed through public interfaces without express authority and controls.
14.4.5(e) The controlling rule shall be that Restricted Systems must be protected against both compromise and misuse.
14.4.6 Public Authority System. 14.4.6(a) A Public Authority System shall be a system used to receive, store, process, analyze, publish, share, or interface with Public Authority Data, public authority participants, public authority learning materials, public authority rooms, public authority reference approvals, or public authority-related records.
14.4.6(b) Public Authority Systems shall preserve authority records, capacity classification, permitted use, prohibited use, confidentiality, public-safe status, AI-use limits, transfer limits, publication controls, reference approval, and correction path.
14.4.6(c) Public Authority Systems shall not create public authority delegation, endorsement, adoption, procurement approval, funding approval, regulatory approval, public finance approval, official guidance, public warning, emergency command, or sovereign obligation by system design, label, workflow, or output.
14.4.6(d) Public Authority Systems shall receive heightened review where they involve emergency management, public health, public safety, public finance, procurement, regulation, public infrastructure, or sensitive data.
14.4.6(e) The controlling rule shall be that systems touching public authority data must protect both data and public meaning.
14.4.7 Cyber-Sensitive System. 14.4.7(a) A Cyber-Sensitive System shall be a system that stores, processes, analyzes, transmits, displays, or supports Cyber-Sensitive Data, vulnerability records, incident records, security logs, credentials, keys, tokens, secrets, security findings, detection logic, repository security information, or cyber-related technical assets.
14.4.7(b) Cyber-Sensitive Systems shall require need-to-know access, secure configuration, logging, restricted sharing, AI-use restrictions, coordinated disclosure controls where applicable, repository controls, secrets protection, key management, and incident response.
14.4.7(c) Cyber-Sensitive Systems shall not expose exploit-enabling detail, credentials, secrets, unpatched vulnerabilities, system diagrams, or sensitive logs through public repositories, public dashboards, public issue trackers, AI tools, or uncontrolled collaboration systems.
14.4.7(d) Cyber-Sensitive Systems shall receive heightened controls where they relate to public-good software, technical baselines, public authority systems, infrastructure-sensitive systems, or Nexus interfaces.
14.4.7(e) The controlling rule shall be that systems containing cyber-sensitive material must not become attack-enabling surfaces.
14.4.8 Infrastructure-Sensitive System. 14.4.8(a) An Infrastructure-Sensitive System shall be a system that stores, processes, analyzes, maps, dashboards, or publishes data concerning critical infrastructure, mission-critical infrastructure, public infrastructure, telecommunications, AI-RAN, O-RAN, private wireless, DePIN, energy, water, food, transport, ports, corridors, logistics, public safety, health systems, emergency systems, operational technology, data centers, compute environments, sensors, or cyber-physical dependencies.
14.4.8(b) Infrastructure-Sensitive Systems shall require access control, public-safe mapping review, cybersecurity review, host or operator review where appropriate, public authority review where applicable, sensitive-location controls, publication controls, AI-use restrictions, and correction path.
14.4.8(c) Infrastructure-Sensitive Systems shall not expose precise vulnerable locations, operational dependencies, access paths, failure points, cyber-physical attack paths, or sensitive infrastructure details unless authorized and controlled.
14.4.8(d) Dashboards, maps, digital twins, and Observatory outputs involving infrastructure-sensitive systems shall be designed to avoid public warning confusion, operational instruction, or targeting risk.
14.4.8(e) The controlling rule shall be that infrastructure-sensitive systems must support resilience without creating exposure.
14.4.9 Finance-Sensitive System. 14.4.9(a) A Finance-Sensitive System shall be a system that stores, processes, displays, shares, or supports Finance-Sensitive Data, capital-reader materials, proof-pack inputs, diligence gap maps, public finance materials, insurance materials, underwriting materials, project finance materials, Project SPV materials, or GRA interface materials.
14.4.9(b) Finance-Sensitive Systems shall require access control, finance-boundary review, GRA role separation, no-advice language, no-solicitation language, no-rating language, no-guarantee language, no-commitment language, legal review where risk exists, and correction path.
14.4.9(c) Finance-Sensitive Systems shall not be designed or presented as investment platforms, brokerage systems, offering systems, lending systems, insurance placement systems, rating systems, capital commitment systems, public finance approval systems, or financial execution systems by GCRI Canada.
14.4.9(d) Capital-reader rooms and finance-facing systems shall include role classification, no-download controls where appropriate, do-not-discuss controls where competition risk exists, access logs, expiration, closeout, and boundary language.
14.4.9(e) The controlling rule shall be that finance-sensitive systems may support evidence review without becoming financial infrastructure.
14.4.10 Community-Protected or Protected Knowledge System. 14.4.10(a) A Community-Protected or Protected Knowledge System shall be a system that stores, processes, maps, dashboards, publishes, translates, embeds, indexes, or otherwise handles Community-Protected Data, Indigenous knowledge where applicable, local knowledge, territorial knowledge, cultural knowledge, environmental knowledge, protected sites, sensitive species locations, community vulnerability data, participation records, grievance records, or protected knowledge.
14.4.10(b) Such systems shall require safeguards review, appropriate authority, consent or non-consent treatment where applicable, attribution or non-attribution controls, access restrictions, AI-use restrictions, mapping restrictions, publication limits, withdrawal pathways, grievance pathways, remedy pathways, and correction path.
14.4.10(c) Such systems shall not expose protected knowledge through dashboards, maps, public releases, repositories, AI retrieval, embeddings, public authority materials, Academy materials, media materials, sponsor materials, provider materials, or Nexus interfaces without recorded authority and safeguards.
14.4.10(d) System design shall avoid extraction, surveillance, stigma, overexposure, cultural harm, ecological harm, and protected site exposure.
14.4.10(e) The controlling rule shall be that protected knowledge systems must protect context as well as content.
14.4.11 AI / Model System. 14.4.11(a) An AI / Model System shall be a system involving artificial intelligence, machine learning, foundation models, agentic systems, model inference, model evaluation, embeddings, retrieval, fine-tuning, training, summarization, translation, coding assistance, analysis, visualization, classification, scoring, or automated support.
14.4.11(b) AI / Model Systems shall require model register entry, data authority, data classification, AI-use review, access controls, vendor review where applicable, training or non-training status, retrieval source governance, embedding store controls, output review, inference records where material, public-safe review where outputs may be released, and correction path.
14.4.11(c) AI / Model Systems shall not process sensitive data, public authority data, protected knowledge, cyber-sensitive data, infrastructure-sensitive data, finance-sensitive data, controlled technology, credentials, keys, tokens, secrets, or confidential materials without express authority and controls.
14.4.11(d) AI outputs shall not be treated as authority, truth, public warning, finance-readiness, recognition, certification, protocol effect, provider preference, public authority action, or execution instruction by default.
14.4.11(e) The controlling rule shall be that AI systems must be governed as data-processing, evidence-shaping, and public-meaning-risk systems.
14.4.12 Repository System. 14.4.12(a) A Repository System shall be a system used to store, manage, version, review, release, archive, or publish code, documentation, schemas, APIs, data contracts, technical baselines, datasets, models, prompts, evaluation harnesses, benchmark harnesses, release artifacts, issues, pull requests, discussions, or technical records.
14.4.12(b) Repository Systems shall require owner, custodian, maintainer roles, contributor roles, reviewer roles, release authority, branch protection, access controls, commit discipline, versioning, tagging, changelog, secrets scanning, dependency review, license review, vulnerability review, and archive controls where appropriate.
14.4.12(c) Repository Systems shall not contain unauthorized Personal Information, Public Authority Data, Cyber-Sensitive Data, Infrastructure-Sensitive Data, Community-Protected Data, Protected Knowledge, Controlled Technology, credentials, keys, tokens, secrets, or restricted materials.
14.4.12(d) Repository releases shall be governed by secure release discipline and correctionability.
14.4.12(e) The controlling rule shall be that repositories are institutional record and release systems, not casual storage.
14.4.13 Dashboard or Public Interface System. 14.4.13(a) A Dashboard or Public Interface System shall be a system that visualizes, displays, publishes, distributes, or enables interaction with data, evidence, maps, reports, metrics, models, APIs, public-safe summaries, public notices, or technical outputs.
14.4.13(b) Dashboard and Public Interface Systems shall require public-safe review, data classification, access controls, source lineage, update status, confidence and uncertainty treatment, limitations, boundary language, monitoring, incident response, and correction path.
14.4.13(c) Such systems shall not expose restricted data, unsafe metadata, sensitive locations, personal information, protected knowledge, cyber-sensitive details, infrastructure-sensitive details, finance-sensitive information, public authority restricted data, or misleading status indicators without authorization and controls.
14.4.13(d) Interface design shall avoid visual implication of public warning, official status, recognition, finance-readiness, certification, provider ranking, sponsor validation, protocol effect, or execution authority unless proper authority exists.
14.4.13(e) The controlling rule shall be that public-facing systems are publication systems and must be governed as such.
14.4.14 Controlled Room, Clean Room, Data Room, Evidence Room, Public Authority Room, Capital-Reader Room, and No-Download Room Systems. 14.4.14(a) Controlled Room, Clean Room, Data Room, Evidence Room, Public Authority Room, Capital-Reader Room, and No-Download Room Systems shall be systems designed to provide restricted access to sensitive materials under role, purpose, confidentiality, access, logging, copy, AI-use, download, publication, and closeout controls.
14.4.14(b) Such systems shall define entry criteria, role classification, access rights, materials permitted, materials prohibited, download controls, copy controls, screenshot controls where appropriate, AI-use restrictions, do-not-discuss controls, competition controls, confidentiality, access logs, exit obligations, and correction path.
14.4.14(c) Public Authority Rooms shall preserve capacity classification, no-delegation, no-endorsement, no-public-warning, no-procurement, no-public-finance, and correction controls.
14.4.14(d) Capital-Reader Rooms shall preserve no-advice, no-solicitation, no-rating, no-guarantee, no-commitment, no-financial-execution, and GRA role-separation controls.
14.4.14(e) No-Download Rooms shall be used where export, copying, local storage, AI ingestion, or onward disclosure creates unacceptable risk.
14.4.14(f) The controlling rule shall be that room systems are governed access environments, not informal sharing spaces.
14.4.15 Critical System Designation and Heightened Controls. 14.4.15(a) GCRI Canada may designate a system as a Critical System where compromise, unavailability, manipulation, deletion, vendor failure, key-person failure, data loss, publication error, or correction failure could materially affect governance, evidence integrity, research integrity, public authority data, protected knowledge, public-safe publication, public-good software, technical baselines, Nexus interfaces, public trust, or legal obligations.
14.4.15(b) Critical Systems may include identity systems, repositories, data inventories, records systems, publication systems, public-safe notice systems, dashboards, maps, APIs, AI retrieval systems, controlled rooms, data rooms, public authority rooms, release systems, key management systems, backup systems, and incident response systems.
14.4.15(c) Critical Systems shall receive heightened access control, monitoring, backup, disaster recovery, continuity planning, vendor review, administrative redundancy, documentation, testing, incident response, and assurance.
14.4.15(d) Critical System dependencies shall be reviewed for vendor lock-in, sponsor control, provider control, platform dependency, cloud dependency, repository dependency, AI-provider dependency, identity-provider dependency, and key-person dependency.
14.4.15(e) The controlling rule shall be that systems essential to trust and correction must be treated as critical even if they are not operational infrastructure in the market sense.
14.4.16 System Classification Review, Reclassification, Downgrade, Upgrade, Retirement, and Archive. 14.4.16(a) System classification shall be reviewed periodically and upon material change in purpose, data class, users, access, vendor, hosting, AI use, integrations, public exposure, public authority involvement, protected knowledge involvement, finance sensitivity, cybersecurity risk, infrastructure sensitivity, incident history, or dependency status.
14.4.16(b) Reclassification shall occur where a system was misclassified or where risk changes. Downgrade may occur only after review supports lower sensitivity or lower control requirements. Upgrade shall occur promptly where data, access, public-safe consequence, or dependency risk increases.
14.4.16(c) Retirement shall occur where a system is obsolete, unsupported, insecure, unnecessary, replaced, license-defective, vendor-defective, public-safe-defective, or inconsistent with mission and governance requirements.
14.4.16(d) Archive shall preserve necessary records, logs, configurations, releases, access records, incident records, correction records, and legal hold materials while preventing current reliance on retired systems.
14.4.16(e) System retirement shall include data export, data deletion where lawful and required, sealing, archival, access revocation, credential revocation, vendor termination, public-safe notice where applicable, and dependency closeout.
14.4.16(f) The controlling rule shall be that system status must change when system risk, use, or authority changes.
14.5 Identity, Access, and Role Governance
14.5.1 Identity Governance as Core Security Control. 14.5.1(a) Identity governance shall be a core security control of GCRI Canada and shall govern human identities, organizational identities, service accounts, machine identities, API identities, repository identities, room identities, privileged identities, vendor identities, provider identities, public authority identities, community participant identities, and temporary identities.
14.5.1(b) Identity governance shall ensure that each material access right is associated with a known identity, recorded role, purpose, authority, organization where applicable, access class, duration, and revocation path.
14.5.1(c) Identity governance shall apply to directors, officers, staff, fellows, advisors, committee members, council members, contributors, contractors, providers, vendors, sponsors, hosts, universities, communities, public authorities, capital readers, National Companies, Project SPVs, GRF, GRA, Protocol Authority, Nexus entities, and external participants.
14.5.1(d) Identity governance shall prevent anonymous, shared, stale, excessive, orphaned, unmanaged, or unreviewed access to material systems.
14.5.1(e) The controlling rule shall be that trustworthy access begins with trustworthy identity.
14.5.2 Unique Accounts for Material Systems. 14.5.2(a) GCRI Canada shall require unique accounts for material systems except where a documented, low-risk, operationally necessary exception is approved and controlled.
14.5.2(b) Shared accounts shall not be used for material systems handling Restricted Data, Personal Information, Public Authority Data, Health-Sensitive Data, Cyber-Sensitive Data, Infrastructure-Sensitive Data, Finance-Sensitive Data, Community-Protected Data, Protected Knowledge, repositories, release systems, AI systems, dashboards, APIs, controlled rooms, data rooms, or critical systems.
14.5.2(c) Unique accounts shall support accountability, access review, incident investigation, correction, logging, user offboarding, and role separation.
14.5.2(d) Service accounts and machine identities shall have owners, purposes, scopes, credentials, rotation rules, access limits, monitoring, and revocation procedures.
14.5.2(e) The controlling rule shall be that material access shall be attributable.
14.5.3 Role-Based Access Control. 14.5.3(a) GCRI Canada shall apply role-based access control to material systems, data, repositories, dashboards, APIs, AI systems, controlled rooms, data rooms, publication systems, release systems, and records systems.
14.5.3(b) Roles shall be defined according to function, authority, purpose, data class, access class, handling class, system class, public-safe status, and segregation-of-duties requirements.
14.5.3(c) Role categories may include Board, officer, staff, researcher, data steward, system owner, custodian, maintainer, contributor, reviewer, release authority, publication authority, public-safe reviewer, cybersecurity lead, privacy lead, safeguards reviewer, public authority participant, sponsor, provider, host, university partner, community participant, capital reader, GRF interface user, GRA interface user, Protocol Authority interface user, and Nexus interface user.
14.5.3(d) Role assignment shall not confer authority beyond the role’s recorded scope.
14.5.3(e) The controlling rule shall be that roles define access boundaries and must not become status inflation.
14.5.4 Attribute-Based Access Controls Where Appropriate. 14.5.4(a) GCRI Canada may use attribute-based access controls where appropriate to supplement role-based access control for sensitive systems, complex data environments, controlled rooms, data rooms, public authority rooms, capital-reader rooms, AI retrieval systems, dashboards, APIs, and Nexus interfaces.
14.5.4(b) Attributes may include data class, jurisdiction, sovereign data zone, project, Case ID, public authority permission, community safeguard status, protected knowledge status, AI-use status, publication status, public-safe status, time period, organization, location, clearance, room role, conflict status, recusal status, and training status.
14.5.4(c) Attribute-based controls shall be governed, documented, tested, and reviewed to prevent misconfiguration, discrimination, public authority overreach, excessive access, hidden bias, or uncorrectable denial.
14.5.4(d) Automated access decisions shall be reviewable and correctable where material.
14.5.4(e) The controlling rule shall be that access attributes may refine access only where they are accurate, authorized, and reviewable.
14.5.5 Least Privilege, Need-to-Know, Purpose-Bound, and Time-Limited Access. 14.5.5(a) Access to material systems shall be least-privilege, need-to-know, purpose-bound, time-limited where appropriate, role-specific, classification-aware, and revocable.
14.5.5(b) Access shall be granted only to the extent required to perform a recorded function, fulfill an approved role, complete an authorized task, participate in a controlled process, review approved materials, or maintain approved systems.
14.5.5(c) Access shall expire or be reviewed when the purpose ends, project closes, data room closes, controlled room closes, publication review ends, incident response ends, contract ends, role changes, public authority capacity changes, sponsorship ends, provider role changes, or good standing changes.
14.5.5(d) Time-limited access shall be strongly preferred for external participants, vendors, providers, sponsors, public authority participants, capital readers, temporary contributors, incident responders, reviewers, and controlled room participants.
14.5.5(e) The controlling rule shall be that access must shrink when purpose shrinks.
14.5.6 Access Requests, Approvals, Reviews, Expiration, Revocation, and Emergency Access. 14.5.6(a) Access to material systems shall require access request, approval, classification review, role verification, purpose verification, confidentiality obligation where applicable, training where required, conflict or recusal check where applicable, and access record.
14.5.6(b) Access approvals shall identify system, data class, role, purpose, authority, access level, duration, restrictions, AI-use limits, download or export permissions, logging status, and revocation conditions.
14.5.6(c) Access reviews shall occur periodically and upon material change in role, purpose, data class, system risk, incident, public authority permission, community safeguard, protected knowledge status, vendor status, or project status.
14.5.6(d) Access revocation shall occur promptly when access is no longer needed, role changes, authority expires, good standing changes, conflict arises, incident occurs, misuse is suspected, or termination occurs.
14.5.6(e) Emergency access may be granted only where necessary to protect systems, data, records, persons, public-safe outputs, or continuity; shall be time-limited, logged, reviewed after use, and corrected if overbroad.
14.5.6(f) The controlling rule shall be that access must have an entry record, a review record, and an exit path.
14.5.7 Access for Directors, Officers, Staff, Fellows, Advisors, Committees, Councils, Contributors, Providers, Vendors, Sponsors, Hosts, Public Authorities, Universities, Communities, and Partners. 14.5.7(a) Access shall be granted according to role, purpose, authority, data class, system class, public-safe status, need-to-know, and good standing, and not merely by title, prestige, institutional relationship, sponsorship, contribution value, technical centrality, or public authority status.
14.5.7(b) Directors shall receive access necessary for governance and oversight, subject to confidentiality, conflicts, recusal, legal privilege, data class, public authority restrictions, protected knowledge safeguards, and security controls.
14.5.7(c) Officers and staff shall receive access necessary for delegated responsibilities and operational duties, subject to least privilege and segregation of duties.
14.5.7(d) Fellows, advisors, committees, councils, contributors, and contractors shall receive access only within their recorded scope and shall not acquire authority to bind GCRI Canada by access.
14.5.7(e) Providers, vendors, sponsors, hosts, universities, communities, partners, public authorities, GRF, GRA, Protocol Authority, Nexus entities, National Companies, Project SPVs, and capital readers shall receive access only through approved interface, room, agreement, or access records.
14.5.7(f) Public authority access shall preserve capacity classification and shall not create endorsement, adoption, public warning, procurement approval, funding approval, regulatory approval, public finance approval, or sovereign obligation.
14.5.7(g) Sponsor and provider access shall not create sponsor control, provider preference, outcome purchase, publication veto, method control, data selection control, or public claim advantage.
14.5.7(h) Community access shall be designed to support protected participation, safeguards, dignity, accessibility, grievance, remedy, and correction.
14.5.7(i) The controlling rule shall be that access supports participation but does not create authority.
14.5.8 Privileged Access Management. 14.5.8(a) GCRI Canada shall manage privileged access to administrative consoles, identity systems, cloud systems, repositories, release systems, databases, AI systems, dashboards, APIs, key management systems, backup systems, controlled rooms, public authority rooms, data rooms, and critical systems under heightened controls.
14.5.8(b) Privileged access shall be minimized, role-specific, time-limited where appropriate, MFA-protected where appropriate, logged, reviewed frequently, segregated where appropriate, and promptly revoked when no longer needed.
14.5.8(c) Privileged users shall not use privileged accounts for ordinary work where separation is required.
14.5.8(d) Emergency privileged access shall be granted only through approved emergency procedure, logged, time-limited, reviewed after use, and corrected if excessive.
14.5.8(e) Privileged access misuse shall be treated as a security incident, governance incident, data incident, or misconduct as applicable.
14.5.8(f) The controlling rule shall be that administrative power requires heightened accountability.
14.5.9 Segregation of Duties for Approval, Development, Release, Finance, Data Access, Publication, and Incident Response. 14.5.9(a) GCRI Canada shall apply segregation of duties where appropriate to approval, development, code review, security review, release, finance-facing materials, data access, public authority data access, publication, public-safe review, AI-use approval, key management, vendor approval, incident response, and correction.
14.5.9(b) No single person or role should control incompatible functions where risk is material, including development and release approval, evidence creation and independent review, sponsor relationship and publication approval, provider contribution and benchmark interpretation, finance-facing preparation and finance-boundary approval, data access and public release approval, key custody and release signing, or incident investigation and closure.
14.5.9(c) Segregation shall be proportionate to size, risk, urgency, and capacity, but exceptions shall be recorded, justified, mitigated, and reviewed.
14.5.9(d) Recusal and conflict controls shall be integrated with segregation of duties where sponsors, providers, public authorities, universities, capital readers, or personal interests create risk.
14.5.9(e) The controlling rule shall be that authority should be separated where concentration would weaken integrity.
14.5.10 Access Logs, Access Review Records, Access Violations, and Corrective Actions. 14.5.10(a) GCRI Canada shall maintain access logs, access review records, access approval records, access expiration records, access revocation records, emergency access records, privileged access records, and access violation records for material systems.
14.5.10(b) Access logs shall be protected from tampering, unauthorized access, unnecessary exposure, overretention, and unauthorized AI ingestion.
14.5.10(c) Access review records shall identify system, users, roles, access levels, purpose, authority, expiration, reviewer, findings, removals, changes, exceptions, and unresolved risks.
14.5.10(d) Access violations shall include unauthorized access, excessive access, stale access, shared credential use, privilege misuse, unauthorized download, unauthorized export, unauthorized AI use, unauthorized repository access, unauthorized room access, or failure to revoke access.
14.5.10(e) Corrective actions may include access removal, privilege reduction, key rotation, credential reset, training, disciplinary action, incident response, data correction, publication correction, vendor remediation, system redesign, or Board or committee reporting.
14.5.10(f) The controlling rule shall be that access governance is incomplete unless access can be reviewed, violations can be detected, and corrections can be verified.
14.6 Authentication, Authorization, and Account Security
14.6.1 Authentication Requirements. 14.6.1(a) GCRI Canada shall maintain authentication requirements for all material systems, including identity systems, repositories, cloud systems, compute environments, AI systems, dashboards, APIs, data rooms, controlled rooms, clean rooms, evidence rooms, public authority rooms, capital-reader rooms, communications systems, publication systems, release systems, administrative consoles, and other systems that may affect data, records, technical assets, public-safe outputs, Nexus interfaces, or institutional trust.
14.6.1(b) Authentication requirements shall be proportionate to system classification, data class, access class, user role, public authority sensitivity, cyber sensitivity, infrastructure sensitivity, health sensitivity, finance sensitivity, community or protected knowledge sensitivity, and public-safe consequence.
14.6.1(c) Authentication shall verify that a person, organization, service account, machine account, API client, repository process, automation, or other identity is authorized to access the system, data, room, repository, workflow, or technical asset in question.
14.6.1(d) Authentication methods shall be selected and maintained to reduce account takeover, phishing, credential stuffing, shared credential misuse, recovery-channel abuse, service-account compromise, session hijacking, unauthorized API access, and administrative bypass.
14.6.1(e) The controlling rule shall be that no material system shall rely on weak, anonymous, shared, stale, unverifiable, or unreviewed access.
14.6.2 Multi-Factor Authentication for Material Systems. 14.6.2(a) Multi-factor authentication shall be required for material systems where appropriate and shall be mandatory for privileged access, remote access, repositories, identity systems, cloud systems, AI systems, administrative consoles, data rooms, controlled rooms, public authority rooms, capital-reader rooms, release systems, dashboard administration, API administration, and systems containing Restricted Data or material records.
14.6.2(b) Multi-factor authentication shall be strongly preferred for systems containing Personal Information, Rights-Bearing Data, Health-Sensitive Data, Public Authority Data, Cyber-Sensitive Data, Infrastructure-Sensitive Data, Finance-Sensitive Data, Commercially Sensitive Data, Community-Protected Data, Protected Knowledge, Controlled Technology, credentials, keys, tokens, secrets, release artifacts, evidence records, correction records, or public-safe publication materials.
14.6.2(c) Multi-factor authentication methods shall be appropriate to the risk of the system and shall be managed to reduce phishing, push fatigue, shared-device compromise, backup-code misuse, recovery-channel abuse, and administrative override.
14.6.2(d) Exceptions shall be lawful, recorded, risk-reviewed, time-limited where appropriate, supported by compensating controls, and periodically reviewed.
14.6.2(e) The controlling rule shall be that authentication strength must rise with institutional consequence.
14.6.3 Strong Credential Rules. 14.6.3(a) GCRI Canada shall maintain strong credential rules for accounts, service accounts, machine accounts, API clients, repository accounts, administrative accounts, room accounts, cloud accounts, AI-system accounts, and other material access credentials.
14.6.3(b) Credential rules shall address password strength, password reuse, storage, sharing, rotation where appropriate, compromise response, recovery methods, privileged credentials, service credentials, API credentials, token expiration, and secure credential handling.
14.6.3(c) Credentials shall not be shared through unmanaged email, chat, public documents, public repositories, tickets, logs, training materials, screenshots, AI prompts, AI uploads, public issue trackers, or uncontrolled collaboration systems.
14.6.3(d) Credentials shall be stored only in approved credential-management or secrets-management systems appropriate to their sensitivity and shall not be stored in personal notes, local unencrypted files, spreadsheets, browser-synced notes, informal documents, or uncontrolled repositories.
14.6.3(e) The controlling rule shall be that credentials are security assets and shall be governed as such.
14.6.4 No Shared Personal Accounts for Material Systems. 14.6.4(a) Shared personal accounts shall be prohibited for material systems, including systems handling Restricted Data, Personal Information, Public Authority Data, Health-Sensitive Data, Cyber-Sensitive Data, Infrastructure-Sensitive Data, Finance-Sensitive Data, Community-Protected Data, Protected Knowledge, repositories, release systems, AI systems, dashboards, APIs, controlled rooms, data rooms, publication systems, identity systems, and critical systems.
14.6.4(b) Each person with material system access shall use a unique account tied to that person’s role, organization where applicable, authority, access class, and revocation path.
14.6.4(c) Group accounts, generic accounts, inherited accounts, unmanaged accounts, and convenience accounts shall not be used where attribution, auditability, access review, incident investigation, correction, or revocation may be required.
14.6.4(d) Where a shared operational identity is technically unavoidable for low-risk or machine-function reasons, the exception shall be recorded, assigned to an owner, access-controlled, logged where material, time-limited where appropriate, and subject to compensating controls.
14.6.4(e) The controlling rule shall be that material institutional action must be attributable to a governed identity.
14.6.5 Service Accounts and Machine Accounts. 14.6.5(a) Service accounts and machine accounts shall be governed as material identities where they access systems, repositories, APIs, data stores, AI systems, dashboards, maps, build pipelines, release pipelines, cloud environments, backup systems, logging systems, monitoring systems, controlled rooms, or other technical workflows.
14.6.5(b) Each service account or machine account shall have an owner, custodian, purpose, scope, permitted systems, permitted data, permission level, credential type, rotation schedule where appropriate, expiration or review date, monitoring status, and revocation procedure.
14.6.5(c) Service accounts and machine accounts shall be least-privilege, purpose-bound, and segregated by environment, project, data class, and system where appropriate.
14.6.5(d) Service accounts shall not be used as substitutes for human user accounts, and human users shall not share or borrow service-account credentials except through approved emergency or maintenance procedures.
14.6.5(e) Orphaned, unused, overprivileged, unowned, stale, or unmanaged service accounts shall be disabled, remediated, or removed.
14.6.5(f) The controlling rule shall be that non-human identities must be governed as rigorously as human identities where they can affect systems, data, or records.
14.6.6 API Keys, Tokens, Secrets, Signing Keys, Wallet Keys Where Applicable, and Recovery Codes. 14.6.6(a) API keys, service tokens, access tokens, refresh tokens, repository tokens, AI tool tokens, cloud credentials, signing keys, encryption keys, wallet keys where applicable, recovery codes, certificates, private keys, and other secrets shall be governed under key, token, secret, and credential controls.
14.6.6(b) Such materials shall be generated, stored, used, rotated, revoked, backed up, recovered, expired, and destroyed according to sensitivity, purpose, access class, system criticality, public authority sensitivity, cyber sensitivity, infrastructure sensitivity, finance sensitivity, protected knowledge sensitivity, and legal or contractual requirements.
14.6.6(c) Keys, tokens, secrets, and recovery codes shall not be placed in public repositories, private repositories without approved secret storage, tickets, issue trackers, chat, email, logs, public documents, screenshots, training materials, AI prompts, AI uploads, dashboards, maps, datasets, or release artifacts.
14.6.6(d) Signing keys and release credentials shall receive heightened protection because compromise may affect software integrity, release integrity, repository integrity, public-good technical assets, Open Technical Baselines, and institutional trust.
14.6.6(e) Wallet keys, where applicable, shall not be used to create financial, token, custody, investment, brokerage, payment, market, or execution authority for GCRI Canada unless separately lawful, authorized, recorded, and consistent with the Charter.
14.6.6(f) The controlling rule shall be that secrets are authority-bearing technical instruments and must not be exposed, shared, or left uncontrolled.
14.6.7 Authorization Boundaries and Permission Scopes. 14.6.7(a) Authorization shall define what an authenticated identity may do and shall be bounded by role, purpose, authority, system class, data class, access class, handling class, public-safe status, project, Case ID, environment, time period, and applicable restrictions.
14.6.7(b) Permission scopes shall be least-privilege and shall distinguish read, write, edit, approve, publish, export, delete, seal, archive, administer, release, sign, rotate, share, transfer, train, embed, retrieve, dashboard, map, and execute actions where material.
14.6.7(c) Authorization boundaries shall prevent users from exceeding their roles through broad platform permissions, inherited permissions, group membership, shared folders, repository teams, dashboard roles, API scopes, cloud roles, AI tool permissions, or room access.
14.6.7(d) Permission scopes shall be reviewed after role change, project closeout, incident, public authority permission change, community safeguard change, vendor change, system change, data-class change, or public-safe risk change.
14.6.7(e) The controlling rule shall be that authentication permits entry only; authorization controls institutional action.
14.6.8 Joiner, Mover, Leaver Controls. 14.6.8(a) GCRI Canada shall maintain joiner, mover, and leaver controls for persons and organizations receiving access to material systems, including directors, officers, staff, fellows, advisors, committee members, council members, contributors, contractors, vendors, providers, sponsors, hosts, public authorities, universities, communities, partners, GRF, GRA, Protocol Authority, Nexus entities, National Companies, Project SPVs, and capital readers.
14.6.8(b) Joiner controls shall require identity verification where appropriate, role assignment, access approval, training where required, confidentiality obligations, conflict review where applicable, classification awareness, AI-use rules, security rules, and access record creation.
14.6.8(c) Mover controls shall review, narrow, expand, revoke, or reassign access when a person’s role, project, organization, authority, committee status, council status, public authority capacity, sponsor status, provider status, contract status, conflict status, or good standing changes.
14.6.8(d) Leaver controls shall revoke access promptly upon resignation, termination, contract closeout, project closeout, room closeout, relationship end, public authority participation end, contributor removal, suspension, or loss of good standing.
14.6.8(e) Leaver controls shall include account disablement, credential revocation, token revocation, key rotation where appropriate, device or asset return where applicable, data return or deletion obligations, confidentiality reminders, and closeout records.
14.6.8(f) The controlling rule shall be that access must follow the role lifecycle and end when authority ends.
14.6.9 Account Suspension, Emergency Lockout, and Compromise Response. 14.6.9(a) GCRI Canada may suspend, lock, disable, restrict, or revoke accounts, service accounts, machine accounts, API keys, tokens, credentials, sessions, repository access, room access, cloud access, AI access, dashboard access, map access, or administrative access where compromise, misuse, excessive access, role ambiguity, termination, investigation, incident, or public-safe risk exists.
14.6.9(b) Emergency lockout may be used to contain suspected credential compromise, phishing, unauthorized access, token exposure, repository compromise, AI tool misuse, data exfiltration, public authority data risk, protected knowledge risk, cyber-sensitive exposure, or infrastructure-sensitive exposure.
14.6.9(c) Compromise response may include password reset, MFA reset, session revocation, key rotation, token revocation, service-account suspension, privilege reduction, access-log review, affected-data review, notification review, repository remediation, AI index remediation, dashboard removal, map withdrawal, and incident record creation.
14.6.9(d) Suspended access shall be reinstated only after review supports reinstatement, remediation is complete, and the access remains authorized, necessary, proportionate, and safe.
14.6.9(e) The controlling rule shall be that suspected compromise justifies rapid restriction before full certainty where risk is material.
14.6.10 Account Security Records and Review. 14.6.10(a) GCRI Canada shall maintain account security records for material systems, including account creation, role assignment, authentication method, MFA status where applicable, privileged access, service accounts, machine accounts, token issuance, access approvals, access reviews, access changes, suspensions, revocations, emergency access, compromise response, and account closure.
14.6.10(b) Account security records shall identify account owner, account type, system, role, authority, access class, data class, purpose, approval, start date, expiration where applicable, review date, restrictions, incident status, and closeout status.
14.6.10(c) Account reviews shall identify stale accounts, orphaned accounts, inactive accounts, overprivileged accounts, shared accounts, unmanaged service accounts, expired access, missing MFA, weak authentication, unauthorized tokens, and unclosed external access.
14.6.10(d) Account review findings shall result in revocation, restriction, credential reset, key rotation, training, policy update, system change, vendor remediation, incident response, or Board or committee reporting where material.
14.6.10(e) The controlling rule shall be that account security must be reviewable because access drift is one of the principal routes to institutional compromise.
14.7 Key Management, Token Management, Secrets, and Credential Controls
14.7.1 Key Management as Critical Security Function. 14.7.1(a) Key management, token management, secrets management, and credential governance shall be critical security functions of GCRI Canada and shall protect access to systems, data, repositories, release artifacts, AI systems, dashboards, APIs, cloud environments, controlled rooms, data rooms, evidence rooms, public authority rooms, capital-reader rooms, communications systems, backup systems, and technical assets.
14.7.1(b) Keys, tokens, secrets, and credentials shall be treated as technical authority instruments because they may permit access, signing, release, encryption, decryption, publication, deletion, transfer, data movement, system administration, or external integration.
14.7.1(c) Key and secret controls shall include generation, ownership, custody, storage, access, use, rotation, expiration, revocation, backup, recovery, compromise response, destruction, and register maintenance.
14.7.1(d) Key management shall be proportionate to the sensitivity of the system, data class, role, public authority involvement, cyber sensitivity, infrastructure sensitivity, finance sensitivity, protected knowledge sensitivity, and public-safe consequence.
14.7.1(e) The controlling rule shall be that keys and secrets are not merely technical strings; they are controlled authority surfaces.
14.7.2 Encryption Keys. 14.7.2(a) Encryption keys used to protect data in transit, data at rest, backups, archives, repositories, databases, cloud environments, controlled rooms, data rooms, AI data stores, embeddings, logs, portable media, and sensitive technical assets shall be generated, stored, accessed, rotated, revoked, backed up, recovered, and destroyed under approved controls.
14.7.2(b) Encryption key custody shall identify owner, custodian, permitted users, permitted systems, recovery process, backup location, rotation requirement, revocation conditions, and incident procedure.
14.7.2(c) Encryption keys protecting Restricted Data, Public Authority Data, Health-Sensitive Data, Cyber-Sensitive Data, Infrastructure-Sensitive Data, Finance-Sensitive Data, Community-Protected Data, Protected Knowledge, credentials, secrets, or critical systems shall receive heightened protection.
14.7.2(d) Loss, exposure, misuse, or compromise of encryption keys shall be treated as a security incident and may require key rotation, re-encryption, access review, notification review, data exposure assessment, and correction.
14.7.2(e) The controlling rule shall be that encrypted data is only as protected as the keys that protect it.
14.7.3 Signing Keys. 14.7.3(a) Signing keys used for software releases, repository releases, tags, commits, artifacts, packages, containers, proof receipts, hashes, attestations, documents, public-safe notices, APIs, schemas, or other integrity-signaling functions shall be governed under heightened controls.
14.7.3(b) Signing key custody shall identify owner, custodian, signing authority, permitted signing purposes, storage method, access restrictions, rotation, revocation, backup, recovery, expiration, and compromise response.
14.7.3(c) Signing keys shall not be shared casually, stored in repositories, exposed in build logs, used by unauthorized persons, or used to sign materials outside approved scope.
14.7.3(d) Signing shall not create substantive legal authority, recognition, finance-readiness, certification, public authority approval, protocol effect, provider preference, sponsor validation, or execution authority by default. It may demonstrate integrity or provenance only within stated scope.
14.7.3(e) Compromise of signing keys shall trigger release integrity review, revocation, re-signing where appropriate, public-safe or controlled notice where appropriate, repository review, and dependency review.
14.7.3(f) The controlling rule shall be that signing keys protect trust in artifacts and therefore require trust-grade custody.
14.7.4 API Keys. 14.7.4(a) API keys used to access, expose, process, retrieve, publish, or transfer data through APIs, dashboards, maps, AI tools, repositories, cloud systems, data rooms, public authority rooms, vendor systems, or Nexus interfaces shall be governed by least-privilege, scope limitation, storage controls, rotation, revocation, monitoring, and expiration where appropriate.
14.7.4(b) API keys shall be scoped to the minimum necessary system, data, method, endpoint, environment, permission, and time period.
14.7.4(c) API keys shall not be embedded in public code, public documentation, repositories, client-side applications, logs, browser-visible scripts, dashboards, maps, spreadsheets, chat, email, tickets, AI prompts, or public issue trackers.
14.7.4(d) API key usage shall be monitored where material for unusual volume, unusual endpoints, unauthorized geography where relevant, excessive export, suspicious access, misuse, or compromised credentials.
14.7.4(e) API key compromise shall trigger revocation, replacement, access-log review, affected-data review, public-safe review where exposure occurred, and incident record creation.
14.7.4(f) The controlling rule shall be that API keys must be limited because APIs can turn credentials into data movement at scale.
14.7.5 Service Tokens. 14.7.5(a) Service tokens used by systems, services, applications, automations, integrations, pipelines, build systems, release systems, dashboards, APIs, AI retrieval systems, monitoring tools, backup tools, or data workflows shall be governed as service identities.
14.7.5(b) Service tokens shall have an owner, custodian, purpose, scope, environment, permission set, expiration or review date, rotation schedule where appropriate, storage location, monitoring status, and revocation procedure.
14.7.5(c) Service tokens shall be segregated by environment, system, project, data class, and function where appropriate and shall not be reused broadly across unrelated systems.
14.7.5(d) Service tokens shall not be used to bypass human approval, release gates, data governance, publication review, AI-use restrictions, public authority permissions, protected knowledge safeguards, or access controls.
14.7.5(e) The controlling rule shall be that service tokens are automated authority and must be narrower than the automation they enable.
14.7.6 Access Tokens. 14.7.6(a) Access tokens, refresh tokens, session tokens, temporary credentials, OAuth tokens, single-sign-on tokens, room access tokens, dashboard tokens, repository tokens, AI tool tokens, and other access instruments shall be issued, scoped, stored, monitored, expired, revoked, and reviewed according to risk.
14.7.6(b) Access tokens shall be time-limited where appropriate, least-privilege, purpose-bound, and restricted to approved systems, users, services, data classes, and actions.
14.7.6(c) Token storage shall prevent exposure in logs, browser storage where unsafe, URLs where avoidable, screenshots, issue trackers, repositories, chat, email, AI prompts, and public documents.
14.7.6(d) Token misuse or compromise shall trigger session termination, revocation, replacement, access-log review, data exposure review, and incident handling.
14.7.6(e) The controlling rule shall be that tokens must be treated as active access, not passive metadata.
14.7.7 Repository Tokens. 14.7.7(a) Repository tokens used for code access, CI / CD, package publication, release signing, repository automation, dependency updates, security scans, issue automation, documentation publishing, or artifact distribution shall be governed under repository security and secure release controls.
14.7.7(b) Repository tokens shall be least-privilege, environment-specific, repository-specific where appropriate, time-limited where appropriate, stored in approved secret storage, and restricted from unnecessary write, admin, release, package, or organization-wide permissions.
14.7.7(c) Repository tokens shall not be exposed in commits, pull requests, issue threads, build logs, release notes, documentation, local scripts, screenshots, training materials, or AI tools.
14.7.7(d) Repository token compromise shall trigger token revocation, repository audit, commit history review where appropriate, package release review, CI / CD review, artifact integrity review, dependency review, and public-safe or controlled notice where appropriate.
14.7.7(e) The controlling rule shall be that repository tokens can alter public-good technical assets and therefore require release-grade protection.
14.7.8 AI Tool Tokens. 14.7.8(a) AI tool tokens, model API keys, embedding service keys, retrieval service tokens, agent platform credentials, transcription service credentials, translation service credentials, analytics service credentials, and AI vendor credentials shall be governed under AI data-use, vendor, and secrets controls.
14.7.8(b) AI tool tokens shall be scoped to approved models, approved data classes, approved use cases, approved environments, approved users, approved retention settings, and approved training or non-training status.
14.7.8(c) AI tool tokens shall not be shared with unauthorized users, embedded in public tools, placed in repositories, used in uncontrolled scripts, stored in chat, exposed in logs, or used to send Restricted Data to unauthorized AI systems.
14.7.8(d) AI tool token compromise or misuse shall trigger token revocation, AI-use review, prompt and output review where appropriate, data exposure assessment, vendor notice where appropriate, embedding or retrieval remediation where needed, and incident record creation.
14.7.8(e) The controlling rule shall be that AI tool credentials control both system access and data processing risk.
14.7.9 Cloud Credentials. 14.7.9(a) Cloud credentials, infrastructure credentials, compute credentials, storage credentials, database credentials, administrative credentials, deployment credentials, backup credentials, monitoring credentials, and support credentials shall be governed under privileged access and key management controls.
14.7.9(b) Cloud credentials shall be least-privilege, role-specific, environment-specific, logged where material, protected by MFA where appropriate, monitored, rotated where appropriate, and revoked promptly when no longer needed.
14.7.9(c) Root, owner, global administrator, billing administrator, organization administrator, and other highly privileged credentials shall receive heightened custody, emergency access procedures, recovery controls, access review, and segregation of duties.
14.7.9(d) Cloud credentials shall not be stored in repositories, local scripts, unmanaged files, AI prompts, shared documents, chat, email, or browser notes.
14.7.9(e) Cloud credential compromise shall trigger emergency containment, credential rotation, access-log review, resource review, data exposure review, cross-border exposure review where applicable, billing or misuse review, and incident response.
14.7.9(f) The controlling rule shall be that cloud credentials can become institutional control and must be governed accordingly.
14.7.10 Wallet Keys Where Applicable. 14.7.10(a) Wallet keys, blockchain keys, signing keys for on-chain or distributed-ledger records, DePIN keys, proof-receipt keys, anchoring keys, or other distributed infrastructure keys, where applicable, shall be governed under heightened key management controls.
14.7.10(b) Such keys shall have a recorded purpose, owner, custodian, permitted use, prohibited use, storage method, backup, recovery, rotation or replacement procedure where feasible, access limits, transaction limits where applicable, monitoring, and compromise response.
14.7.10(c) Wallet keys shall not be used to hold, custody, move, issue, solicit, trade, broker, invest, underwrite, insure, guarantee, lend, rate, or otherwise execute financial activity for GCRI Canada unless separately lawful, authorized, recorded, and consistent with the Charter.
14.7.10(d) On-chain anchoring or proof receipts shall not include Personal Information, Protected Knowledge, Public Authority restricted data, confidential data, cyber-sensitive data, infrastructure-sensitive data, or secrets, and shall not create authority by default.
14.7.10(e) Compromise of wallet or anchoring keys shall trigger revocation or replacement where feasible, public-safe or controlled notice where appropriate, proof receipt review, dependency review, and incident response.
14.7.10(f) The controlling rule shall be that distributed keys may preserve integrity but shall not create uncontrolled finance, custody, or authority surfaces.
14.7.11 Secrets Storage, Rotation, Revocation, Expiration, Backup, Recovery, and Destruction. 14.7.11(a) GCRI Canada shall store keys, tokens, secrets, credentials, recovery codes, certificates, and sensitive access materials in approved secrets-management or credential-management systems appropriate to sensitivity.
14.7.11(b) Rotation shall occur according to risk, system class, compromise suspicion, personnel change, vendor change, incident, expiration, public authority requirement, release process, or periodic review.
14.7.11(c) Revocation shall occur promptly when a secret is compromised, exposed, stale, unused, overprivileged, unowned, associated with a terminated role, no longer necessary, or outside approved purpose.
14.7.11(d) Backup and recovery procedures shall prevent loss of critical access while protecting against unauthorized recovery, shared recovery codes, weak recovery channels, and key-person dependency.
14.7.11(e) Destruction shall be secure, recorded where material, and consistent with legal hold, audit, correction, and continuity requirements.
14.7.11(f) The controlling rule shall be that secrets must have a lifecycle from creation to destruction, not merely a place to exist.
14.7.12 Prohibition on Secrets in Repositories, Tickets, Chat, Email, Logs, Public Documents, Training Materials, and Unauthorized AI Tools. 14.7.12(a) GCRI Canada shall prohibit secrets, credentials, keys, tokens, passwords, recovery codes, certificates, private endpoints, sensitive environment variables, wallet keys where applicable, signing keys, and equivalent access materials from being placed in repositories, tickets, issue trackers, pull requests, chat, email, logs, public documents, training materials, screenshots, dashboards, maps, datasets, public-safe summaries, release notes, or unauthorized AI tools.
14.7.12(b) This prohibition shall apply whether the system is internal, private, public, temporary, archived, experimental, sponsor-supported, provider-operated, or used only for testing.
14.7.12(c) If a secret is exposed in a prohibited location, GCRI Canada shall treat the secret as compromised unless review supports otherwise and shall rotate, revoke, remove, purge, restrict, notify, and record the incident as appropriate.
14.7.12(d) Training, automation, scanning, code review, repository review, and release gates shall support detection and prevention of secret exposure.
14.7.12(e) The controlling rule shall be that secret exposure is an incident, not a formatting error.
14.7.13 Emergency Key Rotation and Compromise Response. 14.7.13(a) GCRI Canada shall maintain emergency key rotation and compromise response procedures for suspected or confirmed exposure, loss, misuse, unauthorized access, repository leakage, AI ingestion, vendor compromise, service-account compromise, signing-key compromise, cloud credential compromise, wallet-key compromise where applicable, or credential stuffing.
14.7.13(b) Emergency response may include revocation, rotation, replacement, session termination, access suspension, service isolation, release suspension, repository takedown, dashboard removal, API shutdown, public-safe notice, controlled notice, vendor notice, public authority notice, and dependency review.
14.7.13(c) Signing-key compromise shall trigger integrity review of affected commits, releases, artifacts, packages, proof receipts, documents, attestations, and downstream dependencies.
14.7.13(d) Cloud or administrative credential compromise shall trigger system access review, configuration review, data exposure review, log review, backup review, cross-border exposure review where applicable, and incident response.
14.7.13(e) Emergency action may precede ordinary approval where necessary to protect systems, data, records, or public trust, but shall be documented promptly under emergency record rules.
14.7.13(f) The controlling rule shall be that compromised keys must be contained before institutional reliance continues.
14.7.14 Key, Token, Secret, and Credential Register. 14.7.14(a) GCRI Canada shall maintain a Key, Token, Secret, and Credential Register or equivalent records for material keys, tokens, secrets, credentials, service accounts, signing keys, encryption keys, API keys, AI tool tokens, cloud credentials, repository tokens, wallet keys where applicable, and recovery materials.
14.7.14(b) The Register shall identify secret type, system, owner, custodian, purpose, scope, sensitivity, storage location, permitted users or services, creation date, rotation date, expiration date, last review date, compromise status, revocation status, backup status, recovery method, destruction status, and incident links where applicable.
14.7.14(c) The Register shall not expose the secret value itself except through approved secrets-management controls.
14.7.14(d) Register review shall identify stale, unused, overprivileged, unowned, unrotated, exposed, duplicated, broadly scoped, or undocumented secrets.
14.7.14(e) The controlling rule shall be that GCRI Canada must know which secrets exist without exposing the secrets it governs.
14.8 Secure Collaboration Architecture
14.8.1 Secure Collaboration as Required for Public-Benefit Technical Work. 14.8.1(a) Secure Collaboration shall be required for GCRI Canada’s public-benefit technical work, including governance, research, evidence review, data stewardship, AI use, compute work, repository work, software development, secure release, public-good technical baselines, public authority learning, community safeguards, protected knowledge review, publication review, dashboard review, map review, incident response, and Nexus interface work.
14.8.1(b) Secure Collaboration shall ensure that collaboration systems, workflows, rooms, documents, messages, repositories, dashboards, shared drives, issue trackers, calls, recordings, transcripts, AI tools, and public-safe outputs preserve classification, access, confidentiality, data rights, cybersecurity, public-safe status, and correctionability.
14.8.1(c) Collaboration shall not occur in systems that cannot support the sensitivity, access controls, logging, retention, deletion, public-safe review, AI-use restrictions, public authority terms, protected knowledge safeguards, or role boundaries required by the work.
14.8.1(d) Collaboration convenience shall not justify unsecured data movement, informal approvals, unauthorized AI use, uncontrolled repository sharing, public-link exposure, untracked downloads, or silent publication.
14.8.1(e) The controlling rule shall be that collaboration is part of the security perimeter, not an exception to it.
14.8.2 Approved Collaboration Systems. 14.8.2(a) GCRI Canada shall identify approved collaboration systems for documents, messaging, repository work, code review, issue tracking, data rooms, controlled rooms, incident rooms, public authority rooms, capital-reader rooms, video meetings, secure file transfer, AI-assisted work, publication review, dashboard review, map review, and external interfaces.
14.8.2(b) Approved collaboration systems shall be selected according to data class, system class, access control, authentication, logging, retention, deletion, export control, download control, AI-use status, data residency, public authority restrictions, protected knowledge safeguards, vendor controls, and exit readiness.
14.8.2(c) Approval shall identify the system’s permitted use, prohibited use, permitted data classes, prohibited data classes, user roles, external sharing rules, AI-use rules, retention rules, and incident procedure.
14.8.2(d) A system approved for one purpose or data class shall not be presumed approved for all purposes or data classes.
14.8.2(e) The controlling rule shall be that collaboration systems must be approved for the work they actually perform.
14.8.3 Prohibited or Restricted Collaboration Systems. 14.8.3(a) GCRI Canada shall prohibit or restrict collaboration systems that lack adequate authentication, access control, confidentiality, logging, deletion, data residency, AI-use control, export control, public authority compatibility, protected knowledge safeguards, or incident response for the relevant data or workflow.
14.8.3(b) Prohibited or restricted systems may include personal email, personal cloud storage, unmanaged messaging, public file links, consumer AI tools, public paste sites, unmanaged spreadsheets, unmanaged repositories, public issue trackers, unsecured video recording, unapproved transcription tools, unapproved translation tools, and collaboration tools whose vendor terms permit unauthorized training or secondary use.
14.8.3(c) Restricted tools may be permitted for low-risk, public, or public-safe materials only where classification and purpose support such use.
14.8.3(d) Use of prohibited or restricted systems for material data, Restricted Data, public authority data, protected knowledge, cyber-sensitive data, infrastructure-sensitive data, finance-sensitive data, credentials, keys, tokens, secrets, or public-safe materials shall be treated as an incident where material.
14.8.3(e) The controlling rule shall be that unfit tools must not become collaboration defaults.
14.8.4 Secure Messaging, Document Collaboration, Repository Collaboration, Data Room Collaboration, Controlled Room Collaboration, and Incident Room Collaboration. 14.8.4(a) Secure messaging shall be used for appropriate communications only and shall not substitute for required governance records, approvals, decision records, registers, publication records, release records, or correction records.
14.8.4(b) Document collaboration shall preserve versioning, access control, classification, public-safe status, no-silent-edit discipline, review status, and correction path.
14.8.4(c) Repository collaboration shall preserve branch protection, pull request review, maintainer review, security review, dependency review, license review, commit discipline, secrets scanning, issue controls, release gates, and correctionability.
14.8.4(d) Data room and controlled room collaboration shall preserve entry criteria, role classification, no-download controls where appropriate, access logs, confidentiality, AI-use restrictions, copy restrictions, publication controls, closeout, and correction path.
14.8.4(e) Incident room collaboration shall preserve urgency, containment, evidence preservation, need-to-know access, legal privilege where applicable, public-safe communication, action logs, notification review, and post-incident records.
14.8.4(f) The controlling rule shall be that each collaboration mode must match the risk and record requirements of the activity.
14.8.5 External Participant Access Controls. 14.8.5(a) External participants shall receive access to collaboration systems only through approved role classification, purpose, authority, access class, confidentiality obligation, training where required, conflict review where applicable, data-use limits, AI-use limits, publication limits, and closeout procedure.
14.8.5(b) External participants include providers, vendors, sponsors, donors, funders, hosts, universities, public authorities, community participants, Indigenous or protected knowledge holders where applicable, partners, contractors, consultants, capital readers, National Companies, Project SPVs, GRF, GRA, Protocol Authority, Nexus entities, and other non-GCRI Canada actors.
14.8.5(c) External access shall be time-limited where appropriate, least-privilege, need-to-know, logged where material, and revoked when role, purpose, authority, or good standing ends.
14.8.5(d) External access shall not permit sponsor control, provider preference, public authority implication, finance-readiness, recognition, certification, protocol effect, public warning, publication control, or execution authority by default.
14.8.5(e) The controlling rule shall be that external collaboration must be enabled without surrendering institutional boundaries.
14.8.6 Confidentiality, Data Classification, AI-Use Restrictions, Download Restrictions, Copy Restrictions, Export Restrictions, and Forwarding Restrictions. 14.8.6(a) Collaboration systems and rooms shall implement confidentiality, data classification, AI-use restrictions, download restrictions, copy restrictions, export restrictions, forwarding restrictions, screenshot restrictions where appropriate, and onward disclosure restrictions proportionate to risk.
14.8.6(b) Restricted Data, Public Authority Data, Health-Sensitive Data, Cyber-Sensitive Data, Infrastructure-Sensitive Data, Finance-Sensitive Data, Community-Protected Data, Protected Knowledge, Controlled Technology, credentials, keys, tokens, secrets, and incident materials shall receive heightened collaboration controls.
14.8.6(c) AI-use restrictions shall prohibit copying, uploading, summarizing, translating, embedding, training, fine-tuning, retrieving, or analyzing sensitive materials in unauthorized AI systems.
14.8.6(d) Download, copy, export, and forwarding restrictions shall be implemented where uncontrolled copies would defeat access control, public-safe review, public authority terms, protected knowledge safeguards, cyber controls, finance boundaries, or correctionability.
14.8.6(e) The controlling rule shall be that collaboration access does not include the right to copy, export, train on, or redistribute.
14.8.7 Public Authority, Community-Protected, Cyber-Sensitive, Infrastructure-Sensitive, and Finance-Sensitive Collaboration Controls. 14.8.7(a) Collaboration involving Public Authority Data shall preserve capacity classification, permission, confidentiality, reference approval, no-delegation, no-endorsement, no-public-warning, no-procurement, no-public-finance, AI-use restrictions, and correction path.
14.8.7(b) Collaboration involving Community-Protected Data or Protected Knowledge shall preserve safeguards, consent or non-consent where applicable, attribution or non-attribution, mapping limits, AI-use restrictions, publication limits, withdrawal, grievance, remedy, and correction.
14.8.7(c) Collaboration involving Cyber-Sensitive Data shall preserve need-to-know access, secure handling, secrets protection, coordinated disclosure where applicable, exploit-detail controls, repository controls, and incident response.
14.8.7(d) Collaboration involving Infrastructure-Sensitive Data shall preserve sensitive-location controls, host or operator restrictions where appropriate, public authority review where applicable, public-safe mapping, cyber-physical risk controls, and publication limits.
14.8.7(e) Collaboration involving Finance-Sensitive Data shall preserve GRA role separation, no-advice, no-solicitation, no-rating, no-guarantee, no-commitment, no-public-finance-approval, capital-reader room controls, and competition-safe handling.
14.8.7(f) The controlling rule shall be that collaboration controls must reflect the most sensitive data or boundary risk in the room.
14.8.8 Collaboration Records, Room Records, Access Logs, and Closeout. 14.8.8(a) GCRI Canada shall maintain collaboration records, room records, access logs, materials indexes, attendance records, decision records where applicable, output records, restrictions, and closeout records for material collaboration environments.
14.8.8(b) Collaboration records shall identify purpose, authority, participants, roles, data classes, access rules, AI-use restrictions, confidentiality, materials shared, outputs created, decisions made where applicable, corrections required, and closeout obligations.
14.8.8(c) Access logs shall identify entry, access, download where permitted, export where permitted, administrative changes, role changes, material uploads, material removals, and closeout where material.
14.8.8(d) Closeout shall include access revocation, materials disposition, data return, deletion where lawful and required, sealing, archive, output review, dependency review, correction, and confirmation of continuing confidentiality or boundary obligations.
14.8.8(e) The controlling rule shall be that collaboration must leave a record sufficient to prove access, limits, outputs, and closure.
14.8.9 Shadow Collaboration and Unapproved Tooling Incidents. 14.8.9(a) Shadow collaboration and unapproved tooling incidents shall include use of unapproved or prohibited systems for material data, records, public authority materials, protected knowledge, cyber-sensitive materials, infrastructure-sensitive materials, finance-sensitive materials, AI processing, publication review, release work, or governance decisions.
14.8.9(b) Such incidents may include personal email use, personal cloud storage, unapproved messaging, public links, unauthorized AI tools, informal repositories, uncontrolled dashboards, unapproved transcription, unapproved translation, unmanaged spreadsheets, unauthorized recording, or uncontrolled external forwarding.
14.8.9(c) Incident response shall include containment, access restriction, data retrieval or deletion where feasible, vendor or participant notice where appropriate, affected data review, public-safe review, AI ingestion review, correction, training, tooling remediation, and incident record creation.
14.8.9(d) Repeated or serious shadow collaboration may result in access restriction, participant removal, vendor termination, provider restriction, sponsor relationship review, disciplinary action, or Board or committee reporting.
14.8.9(e) The controlling rule shall be that unauthorized collaboration paths must be corrected before they become institutional practice.
14.8.10 Secure Collaboration Assurance. 14.8.10(a) GCRI Canada shall conduct Secure Collaboration Assurance to review whether collaboration systems, rooms, workflows, external access, document sharing, messaging, repositories, dashboards, maps, AI tools, data rooms, controlled rooms, and incident rooms remain authorized, classified, access-controlled, secure, public-safe, and correctable.
14.8.10(b) Assurance shall review approved systems, restricted systems, access logs, room records, public authority controls, community safeguards, AI-use compliance, download restrictions, copy restrictions, export restrictions, forwarding restrictions, shadow collaboration incidents, and closeout records.
14.8.10(c) Findings may require tool restriction, access reduction, room redesign, vendor review, AI-use prohibition, data migration, public-safe correction, policy update, training, or Board or committee reporting.
14.8.10(d) Secure collaboration controls shall be updated after incidents, system changes, vendor changes, public authority permission changes, protected knowledge concerns, data-class changes, and public-safe release defects.
14.8.10(e) The controlling rule shall be that collaboration security must be assured because collaboration is where boundaries most often drift.
14.9 Controlled Rooms
14.9.1 Controlled Room Purpose and Scope. 14.9.1(a) A Controlled Room shall be a governed access environment used to permit authorized review, discussion, analysis, or collaboration involving sensitive, restricted, confidential, rights-bearing, public authority, cyber-sensitive, infrastructure-sensitive, finance-sensitive, commercially sensitive, community-protected, protected knowledge, technical, legal, research, or publication materials.
14.9.1(b) Controlled Rooms may be used for evidence review, public authority learning, technical review, secure development review, vulnerability review, protected knowledge review, finance-sensitive reading, capital-reader reading, public-safe publication review, incident response, Nexus interface review, or other bounded purposes.
14.9.1(c) Controlled Room scope shall identify purpose, data classes, materials, participants, roles, access period, permitted uses, prohibited uses, AI-use rules, download rules, copy rules, confidentiality, publication rules, output status, correction path, and closeout.
14.9.1(d) Controlled Rooms shall not be used to bypass ordinary governance, create informal approval, replace required records, enable sponsor control, enable provider preference, create public authority implication, create finance-readiness, or conduct execution.
14.9.1(e) The controlling rule shall be that a Controlled Room controls access and context; it does not create authority by attendance.
14.9.2 Controlled Room Creation Authority. 14.9.2(a) A Controlled Room may be created only by authorized officers, delegated system owners, data custodians, public-safe publication authorities, cybersecurity leads, research authorities, public authority interface leads, safeguards leads, or other persons or bodies with recorded authority.
14.9.2(b) Controlled Room creation shall require a room record identifying purpose, authority, owner, custodian, data classes, system used, participant categories, access terms, restrictions, records required, closeout plan, and incident procedure.
14.9.2(c) Rooms involving Public Authority Data, Protected Knowledge, Health-Sensitive Data, Cyber-Sensitive Data, Infrastructure-Sensitive Data, Finance-Sensitive Data, Controlled Technology, or high-risk data shall require heightened review and approvals proportionate to risk.
14.9.2(d) Emergency Controlled Rooms may be created for incident response, breach containment, urgent public-safe review, or critical system recovery under emergency record rules, provided ordinary records are completed promptly.
14.9.2(e) The controlling rule shall be that Controlled Rooms are created by record, not by convenience link or calendar invitation.
14.9.3 Controlled Room Classification and Risk Profile. 14.9.3(a) Each Controlled Room shall be classified according to purpose, data classes, participant roles, public authority involvement, cyber sensitivity, infrastructure sensitivity, finance sensitivity, health sensitivity, protected knowledge sensitivity, publication risk, competition risk, AI-use risk, and public-safe consequence.
14.9.3(b) Classification shall determine access controls, authentication, MFA where appropriate, no-download rules, copy restrictions, logging, confidentiality, AI-use limits, recording rules, transcript rules, materials handling, output review, retention, and closeout requirements.
14.9.3(c) Controlled Rooms may be designated internal, confidential, restricted, public authority, cyber-sensitive, infrastructure-sensitive, finance-sensitive, protected knowledge, incident, technical review, or other appropriate class.
14.9.3(d) Room classification shall be reviewed when materials, participants, purpose, sensitivity, public-safe status, or legal risk changes.
14.9.3(e) The controlling rule shall be that room controls must match the highest relevant risk in the room.
14.9.4 Controlled Room Participant Eligibility, Role Classification, Access Terms, Confidentiality, Conflicts, and Boundary Language. 14.9.4(a) Controlled Room participants shall be eligible only where their role, purpose, authority, good standing, confidentiality obligation, conflict status, training status where required, and access need support participation.
14.9.4(b) Participant roles shall be classified, including reviewer, observer, public authority participant, regulator-listening participant, public finance reader, capital reader, provider, sponsor, host, university participant, community participant, safeguards reviewer, cybersecurity reviewer, technical reviewer, legal reviewer, GRF interface participant, GRA interface participant, Protocol Authority interface participant, or Nexus interface participant.
14.9.4(c) Access terms shall identify permitted materials, permitted uses, prohibited uses, AI-use limits, download limits, copy limits, export limits, forwarding limits, confidentiality, attribution rules, public claims rules, and closeout obligations.
14.9.4(d) Conflicts shall be disclosed and managed where room participation could affect research independence, provider neutrality, sponsor non-control, public authority boundaries, finance boundaries, competition safety, protected knowledge safeguards, or publication integrity.
14.9.4(e) Boundary language shall state that room participation does not create endorsement, adoption, recognition, finance-readiness, certification, protocol effect, public authority approval, procurement approval, sponsor benefit, provider preference, public warning, or execution authority by default.
14.9.4(f) The controlling rule shall be that room participation is permission to participate within bounds, not permission to claim status.
14.9.5 Controlled Room Materials Intake, Classification, Access, Download, Copy, AI-Use, Retention, and Publication Controls. 14.9.5(a) Materials entering a Controlled Room shall be identified, indexed where material, classified, source-reviewed, access-scoped, and assigned handling, AI-use, download, copy, retention, publication, and correction controls.
14.9.5(b) Materials may include documents, data, evidence packs, dashboards, maps, code, repositories, reports, public authority materials, finance-sensitive materials, cyber-sensitive materials, infrastructure-sensitive materials, protected knowledge materials, technical baselines, software releases, logs, incident records, and public-safe drafts.
14.9.5(c) Download and copy permissions shall be restricted where uncontrolled copies would defeat classification, public authority terms, protected knowledge safeguards, cybersecurity controls, finance boundaries, competition safety, or correctionability.
14.9.5(d) AI use within or concerning Controlled Room materials shall be prohibited unless expressly authorized and governed.
14.9.5(e) Materials shall not be published, quoted, forwarded, exported, summarized externally, used in public claims, uploaded to AI tools, or repurposed outside the room without authority and review.
14.9.5(f) The controlling rule shall be that materials brought into a Controlled Room remain governed inside and outside the room.
14.9.6 Controlled Room Use for Evidence Review, Public Authority Learning, Technical Review, Finance-Sensitive Reading, Cyber Review, Protected Knowledge Review, and Nexus Interface Review. 14.9.6(a) Controlled Rooms may be used for evidence review where materials require structured review, source-lineage protection, confidence treatment, limitation review, correction review, or public-safe transformation.
14.9.6(b) Controlled Rooms may be used for public authority learning only with capacity classification, no-delegation, no-endorsement, no-public-warning, no-procurement, no-public-finance, and reference controls.
14.9.6(c) Controlled Rooms may be used for technical review, secure release review, repository review, vulnerability review, cyber review, infrastructure-sensitive review, and controlled technology review under need-to-know and public-safe technical controls.
14.9.6(d) Controlled Rooms may be used for finance-sensitive reading only with no-advice, no-solicitation, no-rating, no-guarantee, no-commitment, no-financial-execution, and GRA role-separation controls.
14.9.6(e) Controlled Rooms may be used for protected knowledge review only with appropriate authority, safeguards, access limits, AI-use restrictions, mapping restrictions, publication limits, grievance, remedy, and correction controls.
14.9.6(f) Controlled Rooms may be used for Nexus interface review only where role separation among GCRI Canada, GRF, GRA, Protocol Authority, Nexus entities, National Companies, Project SPVs, providers, sponsors, hosts, public authorities, universities, communities, and capital readers is preserved.
14.9.6(g) The controlling rule shall be that room type and room use must preserve the boundaries of the materials and actors involved.
14.9.7 Controlled Room Output Status and No Authority by Room Participation. 14.9.7(a) Controlled Room outputs shall be classified according to their source materials, purpose, authority, review status, public-safe status, publication status, and correction path.
14.9.7(b) Controlled Room outputs may include notes, minutes, evidence summaries, review comments, technical findings, issue lists, gap maps, action items, correction items, public-safe summaries, controlled annexes, release conditions, incident records, or interface records.
14.9.7(c) Outputs shall not be treated as Board approval, officer approval, GRF recognition, GRA finance-readiness, Protocol Authority effect, public authority adoption, certification, provider endorsement, sponsor approval, public warning, or execution instruction unless the proper authority and record separately create that status.
14.9.7(d) Participants shall not publicly claim that attendance, access, review, comment, or silence within a Controlled Room constitutes approval, endorsement, adoption, recognition, finance-readiness, certification, public authority support, provider preference, sponsor validation, or Nexus-compatible status.
14.9.7(e) The controlling rule shall be that Controlled Room participation creates process evidence, not authority by itself.
14.9.8 Controlled Room Logs, Minutes Where Appropriate, Materials Index, Attendance Records, Output Records, and Closeout Records. 14.9.8(a) GCRI Canada shall maintain Controlled Room records proportionate to risk, including room creation record, participant list, role classifications, access logs, materials index, restrictions, attendance records, minutes where appropriate, output records, decision records where applicable, correction records, and closeout records.
14.9.8(b) Minutes shall be used where necessary to record process, review, conditions, dissent, unresolved issues, action items, boundary language, and correction matters, but shall avoid over-disclosing sensitive data, protected knowledge, cyber-sensitive details, infrastructure-sensitive details, or confidential information.
14.9.8(c) Materials indexes shall identify materials, version, classification, source, owner, custodian, access rules, public-safe status, and retention or deletion requirements.
14.9.8(d) Closeout records shall identify access revocation, materials disposition, output status, publication restrictions, data return, deletion where required, sealing, archival, dependency review, correction obligations, and continuing confidentiality.
14.9.8(e) The controlling rule shall be that Controlled Rooms must close with records sufficient to prove what was shared, who accessed it, what was produced, and what remains restricted.
14.9.9 Controlled Room Incident Handling. 14.9.9(a) Controlled Room incidents shall include unauthorized access, unauthorized sharing, unauthorized download, unauthorized copying, unauthorized AI use, unauthorized recording, screenshot misuse, public claim misuse, public authority overclaim, finance overclaim, provider preference claim, sponsor control claim, protected knowledge exposure, cyber-sensitive exposure, infrastructure-sensitive exposure, or failure to close out access.
14.9.9(b) Incident handling shall include containment, access suspension, materials restriction, download revocation where possible, credential or token revocation where applicable, AI-ingestion review, affected-data review, notification review, correction, public-safe or controlled notice where appropriate, participant review, and post-incident lessons learned.
14.9.9(c) Serious incidents may require participant removal, sponsor or provider access restriction, public authority clarification, community notice, legal review, cybersecurity response, publication correction, or Board or committee reporting.
14.9.9(d) Incident records shall link to room records, access logs, affected materials, data registers, publication records, correction records, and assurance findings.
14.9.9(e) The controlling rule shall be that Controlled Room breaches must be corrected as breaches of both access and context.
14.9.10 Controlled Room Assurance and Periodic Review. 14.9.10(a) GCRI Canada shall conduct Controlled Room Assurance and periodic review of room governance, access controls, participant eligibility, materials classification, AI-use compliance, download restrictions, output controls, closeout, incidents, and correction obligations.
14.9.10(b) Assurance shall review whether Controlled Rooms remain necessary, properly scoped, properly classified, properly accessed, properly restricted, properly logged, properly closed, and properly corrected.
14.9.10(c) Assurance findings may require room redesign, access reduction, additional boundary language, materials reclassification, output correction, participant training, tool replacement, incident response, or Board or committee reporting.
14.9.10(d) Controlled Room procedures shall be updated where assurance identifies recurring misuse, unclear roles, overbroad access, weak logs, unsafe outputs, AI-use breaches, closeout failures, or public claim overreach.
14.9.10(e) The controlling rule shall be that Controlled Rooms must remain controlled in practice, not merely in title.
14.10 Clean Rooms
14.10.1 Clean Room Purpose and Scope. 14.10.1(a) A Clean Room shall be a governed processing, review, or collaboration environment designed to allow limited analysis, comparison, computation, review, or output creation involving sensitive, restricted, confidential, public authority, provider, sponsor, host, community-protected, health-sensitive, infrastructure-sensitive, cyber-sensitive, finance-sensitive, commercially sensitive, or cross-entity data without exposing more data than necessary.
14.10.1(b) Clean Rooms may be used to preserve privacy, competition safety, cybersecurity, public authority boundaries, sovereign data requirements, protected knowledge safeguards, provider neutrality, sponsor non-control, finance boundaries, and evidence integrity.
14.10.1(c) Clean Room scope shall identify purpose, authority, covered data, participants, permitted processing, prohibited processing, output rules, AI-use limits, download rules, access rules, retention, deletion, public-safe review, and closeout.
14.10.1(d) Clean Rooms shall not be used to hide capture, evade correction, avoid public-safe publication review, suppress limitations, permit unauthorized data pooling, or create authority by technical arrangement.
14.10.1(e) The controlling rule shall be that Clean Rooms enable bounded learning without uncontrolled exposure.
14.10.2 Clean Room as Privacy-Preserving, Competition-Safe, Security-Controlled, or Sovereignty-Compatible Processing Environment. 14.10.2(a) Clean Rooms may serve as privacy-preserving, competition-safe, security-controlled, sovereignty-compatible, public authority-safe, protected knowledge-safe, or finance-boundary-safe processing environments.
14.10.2(b) Privacy-preserving Clean Rooms shall reduce exposure of Personal Information, Rights-Bearing Data, Health-Sensitive Data, or sensitive participant data through minimization, access control, aggregation, output review, and re-identification controls.
14.10.2(c) Competition-safe Clean Rooms shall prevent anti-competitive exchange, price signaling, bid coordination, market allocation, provider ranking, procurement steering, or inappropriate disclosure of competitively sensitive information.
14.10.2(d) Security-controlled Clean Rooms shall restrict cyber-sensitive, infrastructure-sensitive, controlled technology, or incident materials and prevent exploit-enabling disclosure.
14.10.2(e) Sovereignty-compatible Clean Rooms shall support sovereign data zones, localization, compute-to-data, public authority permissions, protected knowledge restrictions, and cross-border limits.
14.10.2(f) The controlling rule shall be that Clean Room design must match the risk it exists to control.
14.10.3 Clean Room Creation Authority. 14.10.3(a) A Clean Room may be created only under recorded authority by the Board, an authorized officer, delegated data custodian, cybersecurity lead, privacy lead, public authority interface lead, safeguards lead, research authority, finance-boundary authority, or other competent body according to risk.
14.10.3(b) Clean Room creation shall require a Clean Room record identifying purpose, authority, owner, custodian, participating entities, data classes, systems, access roles, processing rules, output review, AI-use restrictions, download restrictions, retention, deletion, closeout, and incident procedures.
14.10.3(c) Clean Rooms involving Public Authority Data, Health-Sensitive Data, Protected Knowledge, Cyber-Sensitive Data, Infrastructure-Sensitive Data, Finance-Sensitive Data, Controlled Technology, cross-border processing, or competitively sensitive information shall receive heightened review.
14.10.3(d) Emergency Clean Rooms may be created for urgent incident response, public-safe review, or security review under emergency record rules, subject to prompt formalization.
14.10.3(e) The controlling rule shall be that Clean Rooms must be deliberately constituted because their controls define what may be learned and shared.
14.10.4 Clean Room Data Intake, Data Minimization, Processing Rules, Output Review, and No-Download Controls. 14.10.4(a) Clean Room data intake shall require source authority, classification, permitted use, prohibited use, minimization, access rules, AI-use limits, transfer limits, retention, deletion, public-safe status, and correction path.
14.10.4(b) Only the minimum data necessary for the approved purpose shall be admitted, and higher-sensitivity fields shall be excluded, transformed, aggregated, masked, redacted, pseudonymized, synthetically substituted, or kept outside the Clean Room where possible.
14.10.4(c) Processing rules shall identify permitted queries, permitted analyses, prohibited linkage, prohibited export, prohibited re-identification, prohibited model training, prohibited embedding, prohibited profiling, prohibited public authority use, prohibited finance use, and prohibited provider or sponsor reuse where applicable.
14.10.4(d) Outputs shall be reviewed before export or release for re-identification, protected knowledge exposure, public authority restricted information, cyber-sensitive detail, infrastructure-sensitive detail, finance-sensitive content, commercial sensitivity, competition risk, public-safe status, and boundary language.
14.10.4(e) No-download controls shall be used where exports would undermine privacy, public authority restrictions, protected knowledge safeguards, cyber controls, infrastructure controls, finance boundaries, competition safety, or sovereignty requirements.
14.10.4(f) The controlling rule shall be that Clean Room value arises from what is prevented as much as from what is processed.
14.10.5 Clean Room Use for Public Authority Data, Community-Protected Data, Health-Sensitive Data, Infrastructure-Sensitive Data, Finance-Sensitive Data, Provider Data, Sponsor Data, Host Data, and Cross-Entity Evidence Review. 14.10.5(a) Clean Rooms may be used for Public Authority Data only where authority, capacity classification, permitted use, confidentiality, public-safe status, AI-use limits, transfer limits, no-delegation, no-endorsement, no-public-warning, no-procurement, no-public-finance, and correction controls are preserved.
14.10.5(b) Clean Rooms may be used for Community-Protected Data and Protected Knowledge only where safeguards, consent or non-consent where applicable, attribution or non-attribution, mapping limits, AI-use restrictions, publication limits, withdrawal, grievance, remedy, and correction controls are preserved.
14.10.5(c) Clean Rooms may be used for Health-Sensitive Data only where ethics review where applicable, minimization, de-identification or aggregation, re-identification review, public-safe health controls, AI-use limits, and correction controls are preserved.
14.10.5(d) Clean Rooms may be used for Infrastructure-Sensitive Data only where sensitive-location controls, host or operator restrictions, public authority review where applicable, cyber-physical risk controls, public-safe mapping, and output review are preserved.
14.10.5(e) Clean Rooms may be used for Finance-Sensitive Data only where GRA role separation, no-advice, no-solicitation, no-rating, no-guarantee, no-commitment, no-financial-execution, competition-safe handling, and correction controls are preserved.
14.10.5(f) Clean Rooms may be used for provider, sponsor, host, university, partner, National Company, Project SPV, or cross-entity evidence review only where data rights, confidentiality, competition safety, sponsor non-control, provider neutrality, legal separateness, no shared liability, and anti-capture controls are preserved.
14.10.5(g) The controlling rule shall be that Clean Room use must preserve the strongest boundary applicable to the data and actors present.
14.10.6 Clean Room AI-Use Restrictions, Embedding Restrictions, Model Training Restrictions, and Retrieval Controls. 14.10.6(a) AI use in Clean Rooms shall be prohibited unless expressly authorized and governed by source authority, data classification, AI Data Use Assessment, model register entry, vendor review where applicable, public-safe review, and correction path.
14.10.6(b) Clean Room data shall not be used for model training, fine-tuning, embedding, retrieval indexing, model improvement, product improvement, synthetic data generation, agentic workflows, automated profiling, or public authority decision support unless specifically authorized and safeguarded.
14.10.6(c) Embedding stores, retrieval indexes, prompts, outputs, logs, temporary files, caches, and model artifacts created within Clean Rooms shall inherit the Clean Room’s restrictions unless reviewed and lawfully transformed.
14.10.6(d) AI outputs generated within a Clean Room shall undergo output review before export, publication, sharing, dashboarding, mapping, inclusion in evidence packs, use in public authority materials, use in finance-facing materials, or Nexus interface routing.
14.10.6(e) The controlling rule shall be that Clean Room controls must apply to AI-derived forms of data, not only original files.
14.10.7 Clean Room Competition-Sensitive Information Controls and Do-Not-Discuss Rules. 14.10.7(a) Clean Rooms involving providers, vendors, sponsors, National Companies, Project SPVs, universities, partners, market actors, public authorities, or capital readers shall include competition-sensitive information controls where risk exists.
14.10.7(b) Competition-sensitive information may include pricing, costs, bids, customers, suppliers, market strategy, capacity, procurement plans, future product plans, proprietary technical roadmaps, commercial terms, investment intentions, and competitively sensitive performance information.
14.10.7(c) Do-not-discuss rules shall prohibit inappropriate discussion, disclosure, exchange, aggregation, inference, or publication of competitively sensitive information that could facilitate market allocation, bid coordination, price signaling, provider ranking, procurement steering, or anti-competitive conduct.
14.10.7(d) Benchmarking, comparison, technical review, and evidence review shall be structured to avoid provider preference, sponsor advantage, procurement implication, market signaling, or competition-law risk.
14.10.7(e) The controlling rule shall be that public-good collaboration shall not become a venue for anti-competitive exchange.
14.10.8 Clean Room Outputs as Evidence or Aggregated Outputs, Not Authority by Default. 14.10.8(a) Clean Room outputs shall be classified as evidence, aggregated outputs, public-safe summaries, controlled outputs, restricted outputs, technical findings, gap lists, review notes, or other output classes according to source authority, processing rules, output review, publication status, and correction path.
14.10.8(b) Clean Room outputs shall not constitute recognition, finance-readiness, certification, public authority approval, procurement approval, regulatory approval, public warning, provider preference, sponsor validation, protocol effect, investment advice, rating, guarantee, public finance approval, or execution authority by default.
14.10.8(c) Output review shall determine whether outputs may be shared, published, routed to GRF, routed to GRA, routed to Protocol Authority, routed to Nexus entities, used in Academy materials, used in public authority learning, or retained only within the Clean Room record.
14.10.8(d) Outputs shall preserve limitations, confidence, uncertainty, transformation notes where material, permitted uses, prohibited uses, boundary language, and correction path.
14.10.8(e) The controlling rule shall be that Clean Room outputs may support institutional understanding but shall not create institutional effect beyond proper authority.
14.10.9 Clean Room Logs, Output Review Records, Access Records, and Closeout. 14.10.9(a) GCRI Canada shall maintain Clean Room logs, output review records, access records, data intake records, processing records, participant records, query logs where appropriate, export records, restrictions, incident records, and closeout records proportionate to risk.
14.10.9(b) Logs shall identify access, data intake, processing activity where appropriate, outputs created, outputs reviewed, outputs exported, administrative changes, access changes, and closeout actions.
14.10.9(c) Output review records shall identify output type, source data, transformation, re-identification risk, protected knowledge risk, public authority risk, cybersecurity risk, infrastructure risk, finance risk, competition risk, public-safe status, permitted use, prohibited use, and correction path.
14.10.9(d) Closeout shall include access revocation, data return, deletion where lawful and required, sealing, archival, output disposition, dependency review, correction obligations, and confirmation of continuing confidentiality or boundary obligations.
14.10.9(e) The controlling rule shall be that Clean Rooms must produce records proving that data was not exposed beyond the approved purpose.
14.10.10 Clean Room Incident Handling and Assurance. 14.10.10(a) Clean Room incidents shall include unauthorized access, unauthorized data intake, unauthorized query, unauthorized export, unauthorized download, unauthorized AI use, unauthorized embedding, unauthorized model training, re-identification attempt, linkage attack, output leakage, public authority overclaim, finance overclaim, competition-sensitive disclosure, protected knowledge exposure, cyber-sensitive exposure, infrastructure-sensitive exposure, or closeout failure.
14.10.10(b) Incident handling shall include containment, access suspension, export restriction, data removal, AI remediation, output withdrawal, affected-party notice where appropriate, public-safe review, legal review where applicable, cybersecurity review where applicable, safeguards review where applicable, correction, and post-incident lessons learned.
14.10.10(c) Clean Room Assurance shall periodically review whether Clean Rooms remain properly authorized, properly scoped, properly accessed, properly restricted, properly logged, properly output-reviewed, properly closed, and properly corrected.
14.10.10(d) Assurance findings may require access reduction, processing-rule revision, output-rule revision, stronger no-download controls, stronger AI-use restrictions, competition-control updates, public-safe correction, training, system replacement, or Board or committee reporting.
14.10.10(e) The controlling rule shall be that Clean Room integrity must be assured because the room’s value depends on trust that data did not escape, over-inform, or over-authorize.
14.11 Data Rooms, Evidence Rooms, Public Authority Rooms, Capital-Reader Rooms, and No-Download Rooms
14.11.1 Data Room Purpose and Controls. 14.11.1(a) A Data Room shall be a governed access environment used for the controlled review, exchange, inspection, or analysis of data, documents, evidence, technical materials, diligence materials, public authority materials, research materials, provider materials, sponsor materials, host materials, project materials, or other restricted materials under defined access, confidentiality, security, AI-use, download, export, publication, retention, correction, and closeout controls.
14.11.1(b) Data Rooms may be used for research review, evidence review, public authority learning, finance-sensitive reading, technical review, project diligence support, public-safe publication review, Nexus interface review, or other mission-compatible purposes, provided that the Data Room does not convert GCRI Canada into an operator, broker, adviser, certifier, recognition body, public authority, procurement body, lender, insurer, underwriter, rating agency, market actor, or execution body.
14.11.1(c) Each Data Room shall have a recorded purpose, owner, custodian, access authority, participant categories, data classes, permitted uses, prohibited uses, access class, handling class, AI-use status, download status, copy status, export status, publication status, retention rule, deletion or sealing rule, correction path, and closeout requirement.
14.11.1(d) Data Room materials shall not be treated as public, public-safe, finance-ready, recognized, certified, adopted, approved, provider-preferred, sponsor-validated, or execution-ready merely because they are made available in a Data Room.
14.11.1(e) The controlling rule shall be that a Data Room is a controlled review environment, not an authority-conferring instrument.
14.11.2 Evidence Room Purpose and Controls. 14.11.2(a) An Evidence Room shall be a controlled environment for the review, custody, challenge, validation, comparison, correction, or assurance of evidence records, source materials, methods, datasets, model outputs, observability records, public-safe summaries, research artifacts, technical findings, confidence notes, uncertainty notes, limitation notes, and correction records.
14.11.2(b) Evidence Rooms shall preserve source lineage, custody, classification, authority, scope, confidence, uncertainty, limitations, review status, public-safe status, dependency status, and correction path.
14.11.2(c) Evidence Room participation shall not create recognition, maturity status, finance-readiness, certification, public authority approval, public warning, provider preference, sponsor benefit, protocol effect, or execution authority.
14.11.2(d) Evidence Room materials may support later GRF, GRA, Protocol Authority, public authority, Nexus, publication, research, or technical processes only through proper interface records and proper authority.
14.11.2(e) The controlling rule shall be that Evidence Rooms protect the integrity of evidence before evidence is used, shared, published, or relied upon.
14.11.3 Public Authority Room Purpose and Controls. 14.11.3(a) A Public Authority Room shall be a controlled environment for lawful, capacity-classified, public authority participation, learning, data review, evidence review, technical review, public-safe review, or interface work involving public authorities.
14.11.3(b) Public Authority Rooms shall identify each public authority participant’s capacity, including observer, learning participant, regulator-listening participant, public finance reader, emergency-management participant, public health participant, public infrastructure participant, data contributor, technical reviewer, host, funder, or other recorded capacity.
14.11.3(c) Public Authority Rooms shall preserve no-delegation, no-endorsement, no-adoption, no-procurement, no-funding-approval, no-public-finance-approval, no-regulatory-approval, no-public-warning, no-emergency-command, and no-sovereign-obligation boundaries.
14.11.3(d) Public authority names, logos, titles, agency names, jurisdictions, quotes, attendance, photos, and data contributions shall not be used externally without required reference approval and boundary language.
14.11.3(e) The controlling rule shall be that public authority access supports learning and review only within recorded public authority boundaries.
14.11.4 Capital-Reader Room Purpose and Finance-Boundary Controls. 14.11.4(a) A Capital-Reader Room shall be a controlled environment for authorized capital readers, finance readers, public finance readers, insurers, diligence readers, or related actors to review evidence, public-safe summaries, diligence gaps, proof-pack components, technical inputs, risk information, or GRA-interface materials within strict finance-boundary controls.
14.11.4(b) Capital-Reader Rooms shall not constitute investment advice, securities offering, solicitation, brokerage, finder activity, placement, underwriting, lending, insurance placement, rating, guarantee, public finance approval, grant approval, budget allocation, capital commitment, or financial execution by GCRI Canada.
14.11.4(c) Capital-Reader Room materials shall include no-advice, no-solicitation, no-rating, no-guarantee, no-commitment, no-public-finance-approval, no-insurance-approval, and no-financial-execution language where material.
14.11.4(d) Capital-Reader Room participation shall not imply GRA finance-readiness, GCRI Canada approval, project endorsement, provider preference, sponsor validation, public authority approval, or investment suitability.
14.11.4(e) The controlling rule shall be that capital readers may read evidence without converting GCRI Canada into a capital actor.
14.11.5 No-Download Room Purpose and Output Controls. 14.11.5(a) A No-Download Room shall be a controlled environment in which participants may view or interact with approved materials without downloading, exporting, copying, scraping, bulk extracting, forwarding, locally storing, uploading to AI systems, or otherwise removing materials except as expressly authorized.
14.11.5(b) No-Download Rooms shall be used where uncontrolled copies may defeat privacy, public authority terms, protected knowledge safeguards, cybersecurity controls, infrastructure sensitivity, finance boundaries, commercial confidentiality, competition safety, sovereign data requirements, or correctionability.
14.11.5(c) Output controls shall define whether notes, summaries, screenshots, transcripts, exports, generated outputs, analytics, AI outputs, printouts, or derivative materials are prohibited, permitted, restricted, reviewed, or subject to public-safe or controlled approval before use.
14.11.5(d) No-Download Room controls shall not be bypassed by manual copying, screen capture, external transcription, unauthorized AI summarization, recording, photographed screens, or secondary sharing.
14.11.5(e) The controlling rule shall be that access to view is not permission to possess, copy, train on, reuse, or redistribute.
14.11.6 Room-Specific Entry Criteria, Capacity Classification, Confidentiality, Conflict Disclosure, Access Restrictions, AI-Use Limits, Copy Controls, and Export Controls. 14.11.6(a) Each room shall define entry criteria, participant role, authority, capacity classification, access purpose, confidentiality obligations, conflicts, recusals, training requirements where applicable, permitted materials, prohibited materials, and closeout obligations.
14.11.6(b) Entry may be conditioned on identity verification, role verification, good standing, confidentiality undertaking, public authority capacity record, finance-boundary acknowledgement, competition-law acknowledgement, protected knowledge safeguard acknowledgement, AI-use acknowledgement, or room-specific terms.
14.11.6(c) Access restrictions shall be least-privilege, need-to-know, time-limited where appropriate, role-specific, materials-specific, and revocable.
14.11.6(d) AI-use limits shall prohibit unauthorized prompting, uploading, summarizing, translating, embedding, indexing, retrieval, training, fine-tuning, model improvement, or agentic use involving room materials.
14.11.6(e) Copy, download, export, print, screenshot, transcript, recording, forwarding, and onward disclosure controls shall be defined according to room type, material classification, data class, public-safe risk, and legal or safeguard requirements.
14.11.6(f) The controlling rule shall be that room access shall be granted only under conditions sufficient to preserve the room’s purpose and boundaries.
14.11.7 Room-Specific Boundary Language: No Recognition, No Finance Advice, No Solicitation, No Public Authority Decision, No Certification, No Procurement, No Provider Preference, No Execution. 14.11.7(a) Room terms, invitations, access pages, materials indexes, participant acknowledgments, outputs, and public-safe summaries shall include boundary language appropriate to the room’s purpose and risk.
14.11.7(b) Boundary language shall state, as applicable, that participation, access, review, silence, comment, or receipt of materials does not constitute recognition, maturity status, finance-readiness, investment advice, securities solicitation, insurance approval, rating, guarantee, certification, protocol effect, public authority decision, public warning, procurement approval, provider preference, sponsor validation, project approval, adoption, endorsement, or execution authority.
14.11.7(c) Boundary language shall preserve the separate roles of GCRI Canada, The Global Risks Forum (GRF), The Global Risks Alliance (GRA), Nexus Standards / Protocol Authority, public authorities, Nexus entities, National Companies, Project SPVs, providers, sponsors, hosts, universities, communities, capital readers, and other participants.
14.11.7(d) Boundary language shall not be contradicted by room titles, badges, labels, scores, rankings, public authority logos, sponsor branding, provider placement, finance-facing presentation, or public claims.
14.11.7(e) The controlling rule shall be that room design and room language must defeat authority overclaim before it arises.
14.11.8 Room Material Index, Room Log, Attendance Log, Access Log, Output Log, and Closeout Record. 14.11.8(a) GCRI Canada shall maintain room records proportionate to risk, including room creation record, material index, participant list, role and capacity classifications, attendance log, access log, output log, restriction record, incident record where applicable, and closeout record.
14.11.8(b) The material index shall identify materials, versions, owners, custodians, source authority, classification, access class, handling class, public-safe status, AI-use status, download status, retention status, correction path, and dependency links.
14.11.8(c) The access log shall record material access, entry, exit, downloads where permitted, exports where permitted, administrative changes, role changes, permission changes, and closeout actions where material.
14.11.8(d) The output log shall identify notes, summaries, findings, reports, public-safe summaries, controlled annexes, evidence outputs, finance-sensitive outputs, technical outputs, correction items, and any approved export or publication.
14.11.8(e) The closeout record shall address access revocation, data return, deletion where lawful and required, sealing, archival, output disposition, dependency review, correction obligations, continuing confidentiality, and boundary obligations.
14.11.8(f) The controlling rule shall be that rooms must leave records sufficient to prove who accessed what, under what terms, what was produced, and how the room was closed.
14.11.9 Room Misuse, Overclaim, Data Leakage, Public Authority Misdescription, Finance Overclaim, or Provider Preference Incident. 14.11.9(a) Room incidents shall include unauthorized access, unauthorized sharing, unauthorized download, unauthorized export, unauthorized recording, unauthorized AI use, copying, screenshotting, data leakage, protected knowledge exposure, cyber-sensitive exposure, infrastructure-sensitive exposure, finance-sensitive exposure, public authority data exposure, public authority misdescription, finance overclaim, provider preference claim, sponsor validation claim, recognition overclaim, certification overclaim, procurement implication, or execution implication.
14.11.9(b) Incident response shall include containment, access suspension, participant review, material restriction, credential or token revocation where applicable, AI-ingestion review, affected-data review, public-safe review, legal review where applicable, cybersecurity review where applicable, notification review, correction, and post-incident lessons learned.
14.11.9(c) Public authority misdescription incidents shall be corrected through approved public authority reference and capacity records. Finance overclaim incidents shall be corrected through finance-boundary review. Provider preference and sponsor validation incidents shall be corrected through public claims controls and relationship review where appropriate.
14.11.9(d) Serious or repeated room misuse may result in participant removal, access termination, sponsor or provider restriction, public authority clarification, community notice, legal response, publication correction, or Board or committee reporting.
14.11.9(e) The controlling rule shall be that room misuse is both an access breach and a boundary breach.
14.11.10 Room Assurance, Review, Suspension, and Closure. 14.11.10(a) GCRI Canada shall conduct assurance and periodic review of Data Rooms, Evidence Rooms, Public Authority Rooms, Capital-Reader Rooms, No-Download Rooms, and related controlled environments.
14.11.10(b) Assurance shall review whether each room remains necessary, authorized, properly scoped, properly classified, properly accessed, properly restricted, properly logged, properly output-reviewed, properly corrected, and properly closed.
14.11.10(c) A room may be suspended where access is excessive, classification is uncertain, materials are misclassified, participant roles are unclear, public-safe risk changes, public authority permission changes, protected knowledge safeguards require review, finance-boundary risk arises, cybersecurity risk arises, or misuse is suspected.
14.11.10(d) Closure shall occur when the purpose ends, authority expires, project closes, review concludes, incident response closes, public authority permission changes, risk becomes unacceptable, or the room is no longer necessary.
14.11.10(e) Room assurance findings may require access reduction, material removal, boundary language revision, room redesign, participant training, incident response, output correction, public-safe notice, controlled notice, or Board or committee reporting.
14.11.10(f) The controlling rule shall be that rooms must remain actively governed from creation through closure.