ARTICLE XI. ASSETS
Section 269. Public-Good Technical Asset Purpose
269.1 Public-Good Technical Asset Purpose. GCRI Canada may create, receive, steward, maintain, improve, publish, restrict, license, govern, correct, supersede, retire, or archive public-good technical assets in furtherance of its public-benefit purpose, non-executing institutional role, evidence and methods mandate, observability and ontology mandate, public-good software mandate, open technical baseline mandate, verifiable compute and verifiable intelligence mandate, public authority learning function, and Nexus-compatible public-good architecture. Public-good technical assets shall be treated as institutional infrastructure for disciplined public-benefit work and shall not be treated as commercial product endorsement, certification, procurement approval, finance-readiness determination, regulated professional advice, public authority decision, operational command, or execution instruction.
269.2 Technical Assets as Public-Benefit Infrastructure. Technical assets stewarded by GCRI Canada shall be organized to advance public-benefit infrastructure, including shared methods, evidence structures, semantic systems, software tools, reference architectures, schemas, technical baselines, public-safe dashboards, test harnesses, dataset and model documentation, governance profiles, observability profiles, and controlled technical records. Such assets shall be developed and maintained for public-good use, institutional learning, research integrity, public authority capacity formation, safeguards, interoperability, and correctionable technical understanding, and not for private capture, exclusive provider advantage, sponsor control, procurement distortion, market allocation, investment promotion, or execution control.
269.3 Technical Assets as Evidence Infrastructure. Public-good technical assets may support evidence infrastructure by enabling source lineage, provenance, custody, classification, confidence scoring, uncertainty disclosure, evidence pack formation, assurance pack formation, evidence review, source comparison, dispute marking, correction triggers, controlled-room review, public-safe transformation, and downstream dependency tracking. No technical asset shall convert data into evidence, evidence into recognition, recognition into maturity, maturity into finance-readiness, or evidence into public authority action unless the competent authority and record separately and lawfully support such transformation.
269.4 Technical Assets as Methods Infrastructure. Public-good technical assets may support methods infrastructure by documenting, implementing, testing, comparing, versioning, localizing, publishing, restricting, correcting, and retiring methods for research, risk evidence, observability, AI governance, cyber governance, data governance, geospatial analysis, digital twin review, AI-RAN signal interpretation, O-RAN signal interpretation, DePIN validation, sensor fusion, public-safe publication, verifiable compute, model evaluation, and Nexus interface review. Methods infrastructure shall remain method-bound, limitation-bearing, reviewable, and correctionable.
269.5 Technical Assets as Observability Infrastructure. Public-good technical assets may support observability infrastructure, including sensors, telemetry structures, signal records, dashboard logic, map layers, digital twin records, degraded-mode awareness methods, resilience indicators, cyber telemetry structures, AI-RAN and O-RAN observability profiles, DePIN telemetry profiles, geospatial evidence tools, Earth observation structures, and public-safe intelligence displays. Observability assets shall support understanding and learning, and shall not be represented as emergency command, public warning, operational control, public authority decision, infrastructure guarantee, provider certification, procurement approval, or finance-readiness.
269.6 Technical Assets as Ontology and Semantic Infrastructure. Public-good technical assets may support ontology and semantic infrastructure, including controlled vocabularies, taxonomies, schemas, data dictionaries, risk ontologies, technology-family classifications, evidence classifications, public authority capacity terms, finance-boundary terms, certification-boundary terms, recognition-boundary terms, maturity concepts, interoperability mappings, semantic versioning structures, and AI-readable knowledge structures. Semantic infrastructure shall preserve disciplined meaning and prevent unauthorized authority inflation, legal equivalence, public authority confusion, finance overclaim, certification overclaim, procurement implication, provider preference, sponsor benefit, or Nexus interface misdescription.
269.7 Technical Assets as Public-Safe Publication Infrastructure. Public-good technical assets may support public-safe publication by enabling redaction, aggregation, de-identification, limitation language, public-safe dashboards, public-safe maps, controlled annex references, confidence display, uncertainty disclosure, source summarization, accessibility, versioning, correction notices, and public-safe release workflows. Public-safe publication assets shall be designed to inform and educate without exposing personal information, protected knowledge, cyber-sensitive information, infrastructure-sensitive information, public authority-sensitive information, finance-sensitive information, competition-sensitive information, confidential materials, or unsafe operational details.
269.8 Technical Assets as Nexus Observatory Methods Support. Public-good technical assets may support Nexus Observatory methods for nodes, hubs, clusters, hotspots, national dense cores, regional clusters, sensors, edge compute, sovereign compute, AI-RAN, O-RAN, DePIN, digital twins, cyber telemetry, geospatial systems, dashboards, degraded-mode awareness, resilience indicators, and public-safe observability. Such assets shall be governed as methods and evidence support and shall not cause GCRI Canada to operate an Observatory node, issue public warnings, command emergency responses, control infrastructure, certify Observatory status, determine maturity, determine finance-readiness, or select providers.
269.9 Technical Assets as Nexus Truth Engine Methods Support. Public-good technical assets may support Nexus Truth Engine methods by enabling source comparison, confidence scoring, corroboration, contradiction detection, dispute marking, spoof detection, tamper detection, failed-signal handling, missing-signal handling, stale-signal handling, model drift review, retrieval review, correction triggers, audit logs, output limitation, and public-safe truth outputs. Truth Engine-supporting assets shall remain methods-supporting artifacts and shall not be treated as oracles, official truth, legal truth, public authority truth, certified truth, finance truth, procurement truth, or final institutional authority.
269.10 Technical Assets as Verifiable Compute and Verifiable Intelligence Support. Public-good technical assets may support verifiable compute and verifiable intelligence through workload records, model records, dataset cards, model cards, system cards, benchmark cards, inference records, compute environment records, output classification, human review records, audit logs, source records, method records, confidence records, limitation records, and correction paths. Such assets shall support traceability, reproducibility where appropriate, auditability, human accountability, and correctionability, and shall not authorize autonomous execution, public authority decisions, regulated advice, finance determinations, certification determinations, or procurement determinations.
269.11 Technical Assets as Interoperability Support Across Nexus Interfaces. Public-good technical assets may support interoperability among GCRI Canada, GCRI US, The Global Risks Forum (GRF), The Global Risks Alliance (GRA), Nexus Standards, Nexus Network, Nexus Universe, Nexus Observatory, Nexus Risk Management, Nexus Rails, Nexus Grid, Nexus Academy, Global Nexus Consortium, Regional Nexus Consortiums, National Nexus Consortiums, National Working Groups, Nexus Competence Cells, National Consortium Companies, Project SPVs, hosts, providers, public authorities, universities, laboratories, communities, and other approved actors. Interoperability shall be governed by interface records, compatibility notes, divergence logs, access controls, classification, limitation language, and correction paths, and shall not create agency, merger, shared treasury, shared liability, shared authority, automatic adoption, public authority delegation, finance-readiness, certification, procurement approval, or execution authority.
269.12 Technical Assets as Open, Governed-Common, Restricted, or Controlled Assets According to Classification. Public-good technical assets may be open, governed-common, internal, controlled, restricted, confidential, no-download, room-only, public authority-limited, safeguards-limited, cyber-limited, infrastructure-limited, finance-boundary-limited, export-controlled, or archive-only according to classification, law, policy, public authority terms, protected knowledge obligations, data rights, cyber risk, infrastructure sensitivity, finance sensitivity, competition sensitivity, licensing, and public-safe suitability. Open status shall not mean ungoverned status; restricted status shall not mean private capture; controlled status shall not remove correctionability; and governed-common status shall not create ownership or control rights inconsistent with GCRI Canada’s public-benefit purpose.
269.13 Technical Assets Subject to Public-Benefit Purpose, Non-Execution, Role Separation, Data / AI / Cyber Controls, and Correctionability. Each public-good technical asset shall remain subject to GCRI Canada’s public-benefit purpose, nonprofit and non-distribution character, non-execution boundary, legal separateness, Nexus role separation, data governance, AI governance, cybersecurity controls, privacy obligations, safeguards obligations, public authority boundaries, finance-readiness boundaries, certification boundaries, procurement neutrality, provider neutrality, sponsor support-without-control, validity-by-record, no-record / no-public-meaning discipline, and correctionability. Technical excellence shall not excuse weak governance, uncontrolled access, unsupported public claims, hidden influence, unsafe disclosure, or unrecorded authority.
269.14 No Public-Good Technical Asset as Certification, Procurement Approval, Public Authority Decision, Finance-Readiness Determination, or Execution Instruction. No public-good technical asset, including software, schema, API, SDK, dashboard, data dictionary, ontology file, model card, dataset card, system card, benchmark card, reference architecture, interoperability profile, evidence profile, Observatory profile, AI governance profile, cybersecurity profile, test harness, gold vector, negative test, technical baseline, Truth Engine method, compute workload record, or verifiable intelligence artifact, shall be represented as certification, accreditation, conformity assessment, compliance approval, procurement approval, preferred provider status, public authority decision, public warning, emergency command, finance-readiness determination, insurance-readiness determination, investment suitability, bankability, rating, public finance approval, or execution instruction unless a separate competent authority lawfully issues such act and the record expressly defines the relationship.
269.15 Public-Good Technical Asset Purpose Records. GCRI Canada shall maintain public-good technical asset purpose records, including asset purpose statements, public-benefit alignment records, evidence infrastructure records, methods infrastructure records, observability infrastructure records, ontology infrastructure records, public-safe publication records, Nexus Observatory support records, Truth Engine support records, verifiable compute support records, verifiable intelligence support records, interoperability records, classification records, boundary language, correction paths, reviews, supersessions, withdrawals, retirements, and archives.
Section 270. Public-Good Technical Asset Register
270.1 Public-Good Technical Asset Register Requirement. GCRI Canada shall maintain a Public-Good Technical Asset Register for material technical assets created, received, maintained, used, published, restricted, licensed, relied upon, deprecated, retired, or archived by GCRI Canada. The Register shall support validity-by-record, technical stewardship, source traceability, governance accountability, public-safe publication, secure maintenance, dependency management, licensing discipline, data rights compliance, export-control awareness, correctionability, and Nexus interface clarity.
270.2 Register Custodian. The Board, an authorized officer, or a delegated technical asset governance function shall designate a custodian for the Public-Good Technical Asset Register. The custodian shall maintain completeness, versioning, classification, access control, change records, ownership records, stewardship records, dependency records, security records, licensing records, correction records, deprecation records, retirement records, and archives. Custodianship shall not create unilateral authority to publish, license, transfer, certify, approve, or commercially exploit assets outside recorded authority.
270.3 Asset Identifier. Each registered asset shall have a unique asset identifier sufficient to distinguish it from drafts, forks, mirrors, variants, derivatives, public-safe versions, controlled versions, restricted versions, superseded versions, retired versions, and archive copies. The identifier may include repository ID, release ID, docket ID, asset ID, hash, commit, tag, version number, package name, schema ID, dashboard ID, API ID, card ID, profile ID, or other approved reference.
270.4 Asset Name. Each registered asset shall have an asset name that accurately reflects its function, scope, status, and public-safe meaning. Asset names shall avoid overclaiming, hidden endorsement, provider preference, public authority confusion, finance-readiness implication, certification implication, procurement implication, or recognition implication. Names using words such as approved, certified, verified, validated, official, readiness, compliance, guarantee, safe, sovereign, public authority, finance-ready, or Nexus-certified shall require heightened review and competent record.
270.5 Asset Type. Each registered asset shall identify asset type, including software, public-good software, internal software, restricted software, schema, API, SDK, dashboard, map, data dictionary, ontology file, model card, dataset card, system card, benchmark card, reference architecture, interoperability profile, evidence profile, Observatory profile, AI governance profile, cybersecurity profile, test harness, gold vector, negative test, technical baseline, method library, compute record template, intelligence output template, or other approved class.
270.6 Asset Owner. Each registered asset shall have an asset owner responsible for purpose, authority, public-benefit alignment, release posture, licensing posture, classification, limitation language, review cycle, correction path, deprecation, retirement, and institutional meaning. Ownership may be assigned to an officer, program lead, research lead, technical lead, evidence steward, methods steward, data / AI / cyber lead, ontology steward, software steward, or other authorized person. Asset ownership shall remain subject to law, the Articles, this Bylaw, Board authority, policies, and delegations.
270.7 Asset Steward. Each registered asset may have an asset steward responsible for technical quality, documentation, user guidance, issue triage, correction coordination, dependency review, public-safe review support, interoperability support, and lifecycle maintenance. The asset steward shall not expand the asset’s public meaning, release status, licensing posture, or institutional authority without recorded approval.
270.8 Asset Maintainer. Each registered asset may have one or more maintainers responsible for repository care, code review, schema review, pull requests, issue tracking, release preparation, documentation updates, security review coordination, and dependency management. Maintainer rights are technical permissions and shall not constitute governance authority, public authority status, certification authority, finance authority, procurement authority, or authority to bind GCRI Canada.
270.9 Asset Repository. Each registered asset shall identify its repository, storage location, registry, data room, controlled room, archive, package index, documentation site, code repository, model registry, schema registry, dashboard environment, or other official location. Repository records shall distinguish official sources from mirrors, forks, working copies, exports, public-safe copies, controlled annexes, and archive copies.
270.10 Asset Version. Each registered asset shall identify version, release date, effective date where applicable, repository commit, tag, hash, change log, supersession relationship, public-safe version, controlled version, restricted version, and archival version where relevant. Asset versioning shall prevent silent edits, obsolete reliance, conflicting releases, untracked forks, and uncontrolled public use.
270.11 Asset Status. Each registered asset shall identify status, including draft, experimental, trial, internal, controlled, restricted, public-safe, public, adopted, in force, active, maintenance, suspended, deprecated, superseded, withdrawn, retired, archived, or sealed. Status shall control permissible use and shall be visible to authorized users. Draft, experimental, superseded, withdrawn, retired, or archived assets shall not be presented as current or operative.
270.12 Asset License. Each registered asset shall identify license or access terms, including open-source license, public-good license, restricted-use license, internal-use terms, controlled-room terms, data-use terms, API terms, contributor terms, public authority terms, provider terms, third-party license, dual license, custom license, or no-license / all-rights-reserved status. License records shall include permitted uses, prohibited uses, attribution, redistribution, modification, patent terms where applicable, warranty disclaimers, liability limitations, and public-good restrictions where lawful.
270.13 Asset Classification. Each registered asset shall be classified according to publication class, access class, handling class, data sensitivity, public authority sensitivity, cyber sensitivity, infrastructure sensitivity, finance sensitivity, competition sensitivity, protected knowledge status, confidential status, privileged status, export-control status, AI-use status, and retention class where applicable. Classification shall govern access, use, publication, export, public-safe summarization, and correction.
270.14 Asset Public-Safe Status. Each registered asset shall identify whether it is public-safe, public-safe after redaction, public-safe after aggregation, public-safe after limitation, controlled only, restricted, confidential, room-only, no-download, public authority-limited, safeguards-limited, cyber-limited, infrastructure-limited, finance-boundary-limited, or not suitable for external release. Public-safe status shall be reviewed before external publication, citation, dashboard display, map display, training use, or Nexus interface use.
270.15 Asset Security Status. Each registered asset shall identify security status, including unreviewed, reviewed, security-reviewed, vulnerability-scanned, dependency-reviewed, SBOM-available, penetration-tested where applicable, restricted due to vulnerability, suspended due to risk, deprecated due to security concern, or archived. Security status shall be updated when vulnerabilities, dependency changes, repository incidents, access incidents, cyber incidents, or provider changes occur.
270.16 Asset Dependency Status. Each registered asset shall identify dependencies, including code libraries, packages, models, datasets, APIs, schemas, standards, public authority records, data pipelines, compute environments, cloud services, AI providers, dashboards, geospatial layers, sensor feeds, repositories, test harnesses, licenses, or Nexus interface records. Dependency status shall identify current, stale, vulnerable, unsupported, restricted, deprecated, superseded, unavailable, or unknown dependencies.
270.17 Asset Data Rights Status. Each registered asset shall identify data rights status where the asset incorporates, depends on, outputs, stores, indexes, embeds, or processes data. Data rights status shall address source permissions, licenses, consent, public authority terms, protected knowledge restrictions, privacy obligations, AI-use permissions, model-training restrictions, retention, deletion path, attribution, and redistribution limits.
270.18 Asset Export-Control or Controlled-Technology Flag. Each registered asset shall identify whether the asset may be subject to export-control, sanctions, controlled-technology, cybersecurity, encryption, dual-use, telecom, AI, critical infrastructure, public authority, data sovereignty, or restricted-transfer considerations. A flag shall trigger review before publication, transfer, repository access, cross-border collaboration, public release, provider access, or Nexus interface use.
270.19 Asset Known Limitations. Each registered asset shall identify known limitations, including technical limitations, evidence limitations, method limitations, data limitations, model limitations, public-safe limitations, cyber limitations, infrastructure limitations, public authority limitations, finance-boundary limitations, certification-boundary limitations, procurement-boundary limitations, licensing limitations, dependency limitations, jurisdictional limitations, and maintenance limitations. Limitations shall be reflected in documentation and public-safe materials where relevant.
270.20 Asset Correction Path. Each registered asset shall identify a correction path for errors, vulnerabilities, license issues, data-rights issues, AI-use issues, protected knowledge concerns, public authority concerns, public-safe failures, dependency failures, model drift, source failures, finance overclaims, certification overclaims, procurement implications, provider-preference issues, sponsor influence concerns, and Nexus interface mismatches. The correction path shall identify intake, owner, reviewer, authority, notice, dependency review, release process, and archival.
270.21 Asset Retirement or Deprecation Status. Each registered asset shall identify retirement or deprecation status where the asset is obsolete, unsafe, unsupported, superseded, legally restricted, no longer public-safe, no longer maintained, dependent on unavailable systems, insecure, misclassified, or inconsistent with GCRI Canada’s public-benefit purpose. Deprecation or retirement shall include effective date, replacement guidance where any, reliance limits, access changes, notice requirements, and archive location.
270.22 Public-Good Technical Asset Register Records. GCRI Canada shall maintain Public-Good Technical Asset Register records, including custodian records, asset identifiers, names, types, owners, stewards, maintainers, repositories, versions, statuses, licenses, classifications, public-safe status records, security status records, dependency status records, data rights status records, export-control or controlled-technology flags, known limitations, correction paths, retirement records, deprecation records, notices, dependency reviews, corrections, withdrawals, takedowns, and archives.
Section 271. Software, Schemas, APIs, Dashboards, Data Dictionaries, Model Cards, System Cards, Reference Architectures, Profiles, Test Harnesses, and Technical Baselines
271.1 Software Assets. Software assets include code, scripts, notebooks, packages, applications, services, libraries, command-line tools, APIs, SDKs, dashboards, data pipelines, model pipelines, evaluation tools, observability tools, public-safe publication tools, documentation tools, and other executable or semi-executable artifacts created, maintained, used, received, or published by GCRI Canada. Software assets shall be versioned, reviewed, classified, licensed, documented, security-reviewed where appropriate, dependency-managed, and correctionable.
271.2 Public-Good Software. Public-good software may be released by GCRI Canada to support research integrity, evidence review, methods stewardship, observability, ontology, public-safe publication, verifiable compute, verifiable intelligence, public authority learning, safeguards, and Nexus interoperability. Public-good software shall include appropriate license terms, limitation language, documentation, security posture, dependency records, contribution rules, issue-reporting channels, correction path, and no-certification, no-warranty, no-procurement, no-provider-preference, no-public-authority-approval, and no-finance-readiness language where required.
271.3 Internal Software. Internal software may be used within GCRI Canada for research, evidence, administration, governance, recordkeeping, data / AI / cyber controls, controlled rooms, public-safe publication, and Nexus interface support. Internal software shall be access-controlled, documented, versioned, reviewed, and restricted to authorized users and purposes. Internal status shall not permit uncontrolled processing of sensitive data, public authority data, protected knowledge, or finance-sensitive material.
271.4 Restricted Software. Restricted software means software that may not be publicly released or broadly used because it includes sensitive logic, public authority-sensitive workflows, protected knowledge, cyber-sensitive functions, infrastructure-sensitive methods, finance-sensitive materials, export-controlled components, controlled technology, privileged material, confidential third-party code, license restrictions, or unsafe operational detail. Restricted software shall be maintained in controlled repositories with heightened access, logging, review, and correction controls.
271.5 Schemas. Schemas may define the structure of records, datasets, evidence packs, assurance packs, observability records, inference records, model records, workload records, intelligence outputs, public authority records, sponsor records, provider records, correction records, Nexus interface records, dashboards, APIs, and public-safe outputs. Schemas shall identify required fields, permitted values, validation rules, authority fields, classification fields, access fields, limitation fields, correction fields, and versioning requirements.
271.6 APIs. APIs stewarded or used by GCRI Canada shall be governed by purpose, authority, authentication, authorization, rate limits, access controls, logging, data classifications, input validation, output classification, versioning, documentation, security review, dependency management, incident response, and correction path. API access shall not create public access, provider preference, public authority approval, finance-readiness, certification, or unrestricted right to use GCRI Canada records.
271.7 SDKs. SDKs may be created or maintained to support approved implementation of public-good software, schemas, APIs, dashboards, observability tools, evidence tools, ontology tools, or Nexus interface tools. SDKs shall include documentation, permitted use, prohibited use, versioning, dependencies, licensing, security posture, public-safe limitations, and correction path. SDK release shall not imply certification of any implementation using the SDK.
271.8 Dashboards. Dashboards may display evidence, observability signals, resilience indicators, confidence bands, public-safe summaries, maps, technical status, issue status, correction status, or Nexus interface information. Dashboards shall identify sources, update cadence, confidence, limitations, stale data, missing data, public-safe status, public authority boundary language, finance-boundary language, certification-boundary language, procurement-boundary language, provider-neutrality language, and correction notices where appropriate. No dashboard shall be treated as public warning, emergency command, guarantee, certification, finance-readiness determination, or public authority decision.
271.9 Data Dictionaries. Data dictionaries shall define fields, units, permissible values, source rules, transformation rules, classifications, sensitivity, retention, AI-use restrictions, public authority restrictions, protected knowledge restrictions, data rights, quality flags, limitations, and correction rules. Data dictionaries shall be maintained as semantic and technical infrastructure and shall be versioned, reviewed, corrected, and archived.
271.10 Ontology Files. Ontology files may include taxonomies, controlled vocabularies, semantic relationships, knowledge graphs, schema mappings, classification structures, public authority capacity terms, finance-boundary terms, recognition-boundary terms, certification-boundary terms, and AI-readable metadata. Ontology files shall be governed by ontology stewardship, semantic versioning, public-safe review, controlled annex rules, localization, correction, and interoperability records.
271.11 Model Cards. Model cards shall describe material models used or stewarded by GCRI Canada, including identity, provider, version, purpose, permitted uses, prohibited uses, data access class, training status, evaluation status, limitations, risks, human review requirements, deployment status, incident history, and retirement conditions. Model cards shall not be represented as model certification or provider endorsement.
271.12 Dataset Cards. Dataset cards shall describe material datasets used or stewarded by GCRI Canada, including source, provenance, custody, collection method, time period, jurisdiction, permissions, classification, sensitive fields, protected knowledge status, public authority status, completeness, bias, known errors, transformations, AI-use restrictions, permitted uses, prohibited uses, limitations, retention, deletion path, and correction path.
271.13 System Cards. System cards shall describe material systems, including AI systems, Truth Engine systems, observability systems, dashboard systems, map systems, retrieval systems, verifiable compute systems, data rooms, controlled rooms, or public-safe publication systems. System cards shall identify components, data flows, models, tools, access controls, logging, human review gates, output classes, risks, limitations, incident procedures, and correction paths.
271.14 Benchmark Cards. Benchmark cards shall describe tests, benchmarks, gold vectors, negative tests, evaluation harnesses, red-team sets, reliability tests, public-safe tests, security tests, and method evaluation tools. Benchmark cards shall identify purpose, scope, sources, metrics, assumptions, limitations, versions, test environment, results, known failure modes, public-safe status, permitted use, prohibited use, and correction path. Benchmark cards shall not create certification, provider ranking, procurement approval, or performance warranty.
271.15 Reference Architectures. Reference architectures may describe public-good technical patterns for evidence systems, observability systems, ontology systems, AI governance systems, verifiable compute, public-safe dashboards, controlled rooms, data rooms, retrieval systems, Nexus Observatory methods, Nexus Truth Engine methods, and Nexus interoperability. Reference architectures shall be non-binding unless adopted by competent authority for a specific use and shall not constitute procurement specifications, provider selection, certification, public authority approval, or execution instruction by default.
271.16 Interoperability Profiles. Interoperability profiles may define how systems, schemas, records, APIs, dashboards, repositories, evidence packs, observability surfaces, ontology files, model records, public authority records, and Nexus interfaces exchange or align information. Interoperability profiles shall preserve classification, access control, semantic meaning, role separation, no-agency, no-merger, no-shared-liability, non-execution, and correctionability.
271.17 Evidence Profiles. Evidence profiles may define required evidence fields, source lineage, confidence, uncertainty, classification, method notes, review status, permitted use, public-safe status, correction path, and dependency mapping for specific evidence classes. Evidence profiles shall support disciplined evidence formation and shall not create recognition, maturity status, finance-readiness, certification, or public authority approval.
271.18 Observatory Profiles. Observatory profiles may define methods, schemas, dashboards, source rules, sensor rules, AI-RAN signal rules, O-RAN signal rules, DePIN telemetry rules, digital twin rules, geospatial rules, cyber telemetry rules, degraded-mode rules, public-safe output rules, and correction rules for Nexus Observatory-related work. Observatory profiles shall not create public warning authority, emergency command, operational control, provider preference, certification, finance-readiness, or procurement approval.
271.19 AI Governance Profiles. AI governance profiles may define model records, data-use restrictions, human review triggers, inference records, training restrictions, retrieval controls, agentic AI controls, incident procedures, public-safe output limits, bias review, drift review, model retirement, and correction paths. AI governance profiles shall support safe and accountable AI use without creating AI certification, compliance approval, product approval, or regulated professional opinion by default.
271.20 Cybersecurity Profiles. Cybersecurity profiles may define controls for repositories, APIs, dashboards, models, datasets, compute environments, controlled rooms, data rooms, public-safe outputs, cyber logs, vulnerability handling, incident response, access control, dependency review, SBOMs, and secure development. Cybersecurity profiles shall not be represented as cybersecurity certification, public authority approval, insurance readiness, underwriting approval, procurement approval, or security guarantee.
271.21 Test Harnesses. Test harnesses may be used to evaluate software, models, methods, schemas, APIs, dashboards, maps, observability outputs, AI outputs, retrieval systems, evidence transformations, or public-safe outputs. Test harnesses shall be versioned, documented, reproducible where appropriate, limitation-bearing, reviewed, and corrected. Test harness results shall not be overclaimed as certification, compliance approval, provider ranking, or operational guarantee.
271.22 Gold Vectors. Gold vectors may be used as reference examples, expected outputs, canonical test cases, or validation artifacts for methods, software, models, schemas, dashboards, ontology, retrieval systems, or public-safe outputs. Gold vectors shall be sourced, versioned, classified, limitation-bearing, and reviewed. Gold-vector success shall not prove universal correctness, certification, compliance, safety, or readiness.
271.23 Negative Tests. Negative tests may be used to test failure modes, unsafe outputs, hallucinations, prompt injection, unauthorized retrieval, protected knowledge leakage, cyber-sensitive leakage, public authority misdescription, finance overclaim, certification overclaim, procurement implication, provider preference, data leakage, bias, drift, or public-safe failure. Negative tests shall be classified and shall not be published where they expose exploitable methods or sensitive details.
271.24 Technical Baselines. Technical baselines may define minimum, reference, public-good, interoperable, or recommended technical patterns for methods, evidence, observability, ontology, software, AI governance, cybersecurity, data governance, public-safe publication, and Nexus interface alignment. Technical baselines shall be versioned, limitation-bearing, corrected, and subject to review. A technical baseline shall not be treated as certification, procurement requirement, public authority approval, provider selection, compliance approval, finance-readiness, or performance guarantee unless separately and lawfully adopted by competent authority.
271.25 Classification, Licensing, Versioning, and Records for Each Asset Type. Each asset type described in this Section shall be classified, licensed or access-controlled, versioned, documented, reviewed, maintained, corrected, superseded, deprecated, retired, or archived according to its risk, use, sensitivity, public meaning, data rights, security status, dependency status, public authority context, protected knowledge status, finance-boundary exposure, certification-boundary exposure, procurement sensitivity, and Nexus interface effect. GCRI Canada shall maintain asset-type records sufficient to preserve authority, lineage, stewardship, public-safe status, correctionability, and institutional continuity.
Section 272. IP Ownership for Employees, Contractors, Fellows, Contributors, Grantees, Partners, and Sponsored Work
272.1 Intellectual Property Ownership Purpose. GCRI Canada shall maintain clear intellectual property ownership, licensing, assignment, moral rights, confidentiality, data rights, and chain-of-title rules for work product created, contributed, funded, sponsored, commissioned, adapted, or stewarded in connection with GCRI Canada. The purpose of these rules is to preserve public-benefit stewardship, lawful rights management, open technical baseline integrity, public-good software continuity, technical asset governance, data / AI / cyber compliance, sponsor support-without-control, provider neutrality, correctionability, and the ability of GCRI Canada to use, maintain, publish, restrict, correct, supersede, retire, and archive technical and institutional assets.
272.2 Employee Work Product. Subject to applicable law, employment agreements, policies, and any contrary written record, work product created by employees within the scope of employment, using GCRI Canada resources, arising from assigned duties, or relating to GCRI Canada programs, records, technical assets, software, methods, evidence systems, ontology, observability, public-good baselines, public-safe publications, or Nexus interfaces shall be owned by GCRI Canada or licensed to GCRI Canada on terms sufficient for its public-benefit purpose. Employee work product records shall preserve authorship attribution where appropriate while ensuring institutional continuity and correctionability.
272.3 Contractor Work Product. Contractor work product shall be governed by written agreement before or at the time work begins. Unless otherwise approved by competent authority, contractor agreements shall provide GCRI Canada with ownership, assignment, or a broad irrevocable license sufficient to use, reproduce, modify, maintain, publish, restrict, sublicense where appropriate, correct, supersede, retire, and archive the work product for public-benefit purposes. Contractor agreements shall address pre-existing IP, background IP, third-party components, open-source software, confidentiality, data rights, AI use, security, warranties, moral rights, and delivery of source materials.
272.4 Consultant Work Product. Consultant work product shall be governed by written terms that define ownership or license, permitted use, confidentiality, data rights, attribution, conflicts, public authority boundaries, sponsor or provider interests, pre-existing materials, third-party materials, open-source materials, AI-assisted work, and correction obligations. Consultant work product shall not create provider preference, procurement advantage, certification, public authority approval, finance-readiness, or execution authority merely because a consultant participated in its creation.
272.5 Fellow Work Product. Fellow work product shall be governed by fellowship agreement, research agreement, institutional policy, university or laboratory agreement where applicable, funder terms where lawful, and GCRI Canada records. Fellow work product may include research outputs, technical notes, code, datasets, models, schemas, public-safe materials, teaching materials, methods, evidence packs, and publications. Rights arrangements shall preserve academic integrity where applicable, attribution, research ethics, data rights, protected knowledge obligations, confidentiality, public-safe review, and GCRI Canada’s ability to correct and archive outputs.
272.6 Volunteer Work Product. Volunteer work product shall be accepted only under terms sufficient to clarify ownership, license, confidentiality, data rights, third-party rights, open-source restrictions, attribution, moral rights where applicable, security obligations, AI-use disclosure, and correction path. No volunteer contribution shall be incorporated into official technical assets, public-good software, methods, evidence records, publications, or Nexus interface materials unless GCRI Canada has adequate rights and review records.
272.7 Technical Contributor Work Product. Technical contributor work product, including code, documentation, issue comments, pull requests, schemas, tests, benchmarks, model cards, dataset cards, system cards, data dictionaries, ontology changes, dashboard logic, and method suggestions, shall be governed by contributor terms, contributor license agreement, assignment instrument, repository rules, open-source license terms, or other competent record. Technical permission to contribute shall not create ownership of GCRI Canada assets, governance authority, release authority, certification authority, procurement authority, finance authority, or authority to bind GCRI Canada.
272.8 Grantee Work Product. Grantee work product shall be governed by grant agreement, program rules, funder conditions, public-benefit requirements, data rights, reporting obligations, publication rules, confidentiality, open-access expectations where applicable, IP ownership or licensing terms, moral rights treatment, public-safe review, and correction obligations. GCRI Canada shall ensure that grantee work product can be used for the public-benefit purposes for which support was given, while respecting lawful grantee rights, university rights, community rights, protected knowledge, and third-party restrictions.
272.9 Partner Work Product. Partner work product created with universities, laboratories, public authorities, hosts, communities, providers, sponsors, consortiums, National Consortium Companies, Project SPVs, GCRI US, The Global Risks Forum (GRF), The Global Risks Alliance (GRA), Nexus Standards, Nexus Network, Nexus Observatory, Nexus Rails, Nexus Grid, Nexus Academy, or other actors shall be governed by written arrangements or recorded terms. Partner work product arrangements shall preserve legal separateness, role separation, no-agency, no-merger, no-shared-liability, public-benefit purpose, data rights, public authority boundaries, protected knowledge, confidentiality, publication review, and correctionability.
272.10 Sponsored Research Work Product. Sponsored research work product shall be governed by written sponsored research terms that preserve GCRI Canada’s research integrity, publication integrity, public-safe review, correctionability, conflict disclosure, data rights discipline, sponsor support-without-control, and no-purchase-of-outcome principle. Sponsors shall not own, control, suppress, veto, distort, or pre-approve findings, methods, conclusions, limitations, corrections, withdrawals, or retractions except to the limited extent necessary to protect lawful confidentiality, personal information, protected knowledge, public authority-sensitive information, security, or specifically negotiated background IP rights consistent with public-benefit purpose.
272.11 Joint Work Product. Joint work product shall be governed by written agreement identifying ownership shares, licensing rights, publication rights, maintenance rights, correction rights, confidentiality, data rights, contribution records, third-party rights, public-safe review, commercialization restrictions where applicable, open-source release authority, public authority restrictions, protected knowledge obligations, dispute resolution, and exit rights. Joint work product shall not create merger, agency, shared treasury, shared liability, governance control, public authority delegation, finance-readiness, certification, procurement approval, or execution authority.
272.12 Pre-Existing IP. Pre-existing IP means intellectual property, software, data, methods, documentation, tools, models, datasets, schemas, technical assets, know-how, publications, or other materials owned or controlled by a person before engagement with GCRI Canada or outside the scope of the relevant work. Pre-existing IP shall remain with its owner unless expressly assigned or licensed. Any use of pre-existing IP in GCRI Canada work shall be disclosed, documented, licensed, and reviewed for restrictions, confidentiality, open-source compatibility, public-safe status, and correctionability.
272.13 Background IP. Background IP means IP, data, software, methods, technical assets, documentation, tools, models, or know-how contributed or made available by a party for use in a project but not created as foreground work product. Background IP rights shall be recorded, and any license to GCRI Canada shall be sufficient for the project purpose, public-benefit use, maintenance, review, correction, publication where authorized, archival, and downstream dependency management. Background IP shall not be incorporated in a way that prevents lawful correction, public-safe limitation, or continued institutional use unless approved.
272.14 Foreground IP. Foreground IP means work product, inventions, copyright works, software, documentation, data structures, schemas, methods, models, technical baselines, datasets, dashboards, maps, publications, or other IP created in the course of a GCRI Canada project, engagement, fellowship, grant, contribution, contract, employment, sponsorship, or partnership. Foreground IP ownership or license shall be recorded and shall preserve GCRI Canada’s ability to fulfill public-benefit, evidence, methods, observability, ontology, public-good software, technical baseline, publication, and correction obligations.
272.15 Derivative Works. Derivative works based on GCRI Canada assets, partner assets, open-source assets, background IP, foreground IP, public authority materials, protected knowledge, datasets, models, or technical baselines shall be governed by applicable licenses, agreements, data rights, protected knowledge protocols, public authority terms, moral rights where applicable, attribution rules, and correction obligations. No derivative work may be represented as official, Nexus-compatible, certified, approved, recognized, finance-ready, procurement-ready, or endorsed by GCRI Canada without competent record.
272.16 Moral Rights Treatment Where Applicable. Where moral rights apply, GCRI Canada shall obtain waivers, consents, non-assertion commitments, attribution terms, integrity-rights arrangements, or other lawful treatment sufficient to permit editing, adaptation, correction, public-safe transformation, translation, accessibility conversion, versioning, supersession, withdrawal, retirement, archival, and use of work product consistent with GCRI Canada’s public-benefit purpose. Moral rights treatment shall respect applicable law and shall not be used to erase fair attribution or conceal contribution history.
272.17 Assignment, License, Waiver, Consent, or Reservation of Rights. GCRI Canada may require assignment, license, waiver, consent, non-assertion, reservation of rights, open-source contribution terms, public-good license terms, data-use terms, or other rights instruments depending on the asset, contributor, sensitivity, intended use, public-safe status, repository status, publication path, and correction needs. Rights instruments shall be recorded before reliance wherever practicable and shall be sufficient to protect GCRI Canada’s public-benefit purpose, lawful use, maintenance, correction, and archival.
272.18 Ownership Records and IP Chain-of-Title Records. GCRI Canada shall maintain ownership records and IP chain-of-title records for material work product, including employment records, contractor agreements, consultant agreements, fellowship agreements, volunteer terms, contributor terms, grantee agreements, partner agreements, sponsored research agreements, joint work agreements, pre-existing IP disclosures, background IP licenses, foreground IP records, derivative work records, moral rights records, assignments, licenses, waivers, consents, reservations of rights, third-party rights disclosures, open-source license records, corrections, takedowns, disputes, and archives.
Section 273. Contributor Terms, Contributor License Agreements, Assignment, Licensing, Moral Rights, Confidentiality, Data Rights, Security, and Conflicts
273.1 Contributor Terms Requirement. GCRI Canada shall require contributor terms for persons or entities contributing code, documentation, methods, schemas, data dictionaries, ontology entries, datasets, model cards, system cards, benchmark cards, test harnesses, dashboards, maps, public-safe summaries, technical baselines, issue comments, pull requests, research materials, evidence records, or other technical or institutional work product where such contribution may be incorporated into GCRI Canada records or assets. Contributor terms shall clarify rights, duties, permitted use, prohibited use, confidentiality, data rights, security, conflicts, attribution, review, acceptance, rejection, modification, withdrawal, takedown, and correction.
273.2 Contributor License Agreement Requirement Where Appropriate. GCRI Canada may require a contributor license agreement where contributions are made to public-good software, open repositories, governed-common assets, restricted repositories, schemas, APIs, technical baselines, ontology files, public-safe publication tools, test harnesses, or other reusable technical assets. The contributor license agreement shall grant GCRI Canada sufficient rights to use, reproduce, modify, distribute, sublicense where appropriate, publish, restrict, correct, supersede, retire, and archive the contribution for public-benefit purposes while preserving contributor attribution where appropriate.
273.3 Assignment Requirement Where Appropriate. GCRI Canada may require assignment of rights where necessary to preserve institutional ownership, legal certainty, public-good stewardship, security, licensing consistency, public-safe publication, correctionability, or downstream use. Assignment may be required for commissioned work, controlled-room work, restricted technical assets, official schemas, public-good baselines, core software, sensitive methods, work created under employment or contract, or assets requiring unified chain of title. Assignment shall be recorded and shall not be inferred from informal contribution.
273.4 License Grant. Contributor terms shall include a license grant sufficient for the accepted contribution’s intended use. The license may be perpetual, irrevocable, worldwide, royalty-free, sublicensable where appropriate, transferable where appropriate, non-exclusive or exclusive as recorded, and broad enough to permit copying, modification, integration, publication, public-safe transformation, translation, accessibility conversion, security review, testing, correction, supersession, withdrawal, retirement, and archival. License grants shall be limited or conditioned where required by law, protected knowledge, public authority terms, data rights, or third-party restrictions.
273.5 Patent Grant Where Appropriate. Where contributions may include patentable subject matter or may implicate patent rights, contributor terms may include a patent grant, non-assertion commitment, defensive termination clause, patent disclosure obligation, or other patent treatment appropriate to the asset and license model. Patent terms shall protect GCRI Canada’s ability to use, maintain, publish, correct, and support public-good technical assets while avoiding hidden patent capture, provider lock-in, or sponsor control.
273.6 Moral Rights Waiver, Consent, or Non-Assertion Where Lawful and Appropriate. Contributor terms may require waiver, consent, non-assertion, attribution agreement, integrity-rights arrangement, or other moral rights treatment where lawful and appropriate. Such treatment shall permit GCRI Canada to modify, edit, adapt, correct, translate, public-safe summarize, combine, version, supersede, withdraw, retire, and archive contributions without later obstruction, while preserving attribution records where appropriate and lawful.
273.7 Representations and Warranties by Contributor. Contributor terms shall require representations and warranties proportionate to the contribution, including authority to contribute, compliance with law, absence of undisclosed restrictions, disclosure of third-party rights, disclosure of open-source licenses, disclosure of data rights, disclosure of confidential information, disclosure of public authority restrictions, disclosure of protected knowledge, disclosure of AI use, and absence of intentional malware, backdoors, unauthorized data, or misappropriated material. Representations shall be adapted where contributors are volunteers, academic researchers, public authorities, community knowledge holders, or other special categories.
273.8 Originality Representation. A contributor shall represent, where appropriate, that the contribution is original to the contributor or that the contributor has sufficient rights to contribute it. Originality representation shall not require disclosure of protected knowledge beyond lawful and safeguards-compliant processes, but it shall require disclosure of any material reliance on third-party material, public authority material, employer material, university material, provider material, sponsor material, confidential material, open-source material, or AI-generated material.
273.9 Third-Party Rights Disclosure. Contributors shall disclose third-party rights affecting contributions, including copyrights, patents, database rights, trade secrets, confidential information, open-source licenses, proprietary dependencies, university rights, employer rights, funder rights, sponsor rights, provider rights, public authority terms, Indigenous / local / territorial knowledge rights, community protocols, privacy rights, moral rights, and contractual restrictions. GCRI Canada may reject, quarantine, modify, limit, or require additional rights for contributions with unresolved third-party rights.
273.10 Open-Source License Disclosure. Contributors shall disclose any open-source software, data, model, documentation, dependency, package, library, snippet, schema, test, benchmark, or other material included in or required by a contribution. Disclosure shall identify license, version, source, modifications, obligations, attribution, copyleft terms, patent terms, security status, and compatibility concerns. Contributions with incompatible open-source obligations may be rejected, isolated, relicensed where lawful, or handled through controlled process.
273.11 Data Rights Disclosure. Contributors shall disclose data rights associated with contributed datasets, records, telemetry, logs, public authority materials, community inputs, protected knowledge, model outputs, embeddings, annotations, labels, geospatial data, Earth observation data, cyber logs, infrastructure data, health-sensitive data, personal information, or derived data. Disclosure shall identify lawful basis, consent, license, public authority terms, protected knowledge restrictions, AI-use restrictions, retention, deletion path, publication limits, and correction rights.
273.12 Confidentiality Obligation. Contributors shall maintain confidentiality of non-public GCRI Canada materials, controlled-room materials, data-room materials, Board materials, committee materials, council materials, public authority materials, protected knowledge, sponsor or provider confidential information, cyber-sensitive information, infrastructure-sensitive information, finance-sensitive information, personal information, privileged material, and other restricted records. Confidentiality obligations shall survive the contribution relationship unless lawfully released.
273.13 Security Obligation. Contributors shall comply with security obligations applicable to their contribution, access, repository, room, data, tools, credentials, devices, models, AI systems, code, dependencies, and communications. Security obligations may include secure development, access control, multifactor authentication, secrets management, no credential sharing, malware avoidance, dependency hygiene, secure storage, no unauthorized downloads, no unauthorized AI uploads, incident reporting, and compliance with repository rules.
273.14 Vulnerability Disclosure Obligation. Contributors shall disclose known or suspected vulnerabilities, dependency risks, malware, insecure configurations, credential exposures, prompt injection risks, retrieval leakage risks, model risks, data leakage risks, infrastructure-sensitive issues, cyber-sensitive findings, or other security concerns related to their contribution. Vulnerability disclosure shall be made through approved channels and shall not be publicized unsafely or used to gain unauthorized access.
273.15 AI-Use Disclosure. Contributors shall disclose material AI use in preparing contributions where disclosure is required by policy, repository rule, publication rule, legal obligation, funder term, public authority term, or research integrity. AI-use disclosure may identify whether AI assisted drafting, coding, summarization, translation, data generation, synthetic data creation, annotation, classification, retrieval, model evaluation, or testing. Contributions created with AI shall still require rights review, source review, human accountability, security review, and correction path.
273.16 Conflict Disclosure. Contributors shall disclose conflicts that may affect contribution integrity, including financial interests, employment interests, provider interests, sponsor interests, donor interests, funder interests, university interests, laboratory interests, public authority interests, investment interests, procurement interests, competitive interests, advisory roles, IP interests, or personal relationships. Conflict disclosure shall allow GCRI Canada to impose recusal, limitation, independent review, attribution limits, controlled-room restriction, or rejection where necessary.
273.17 Sponsor, Provider, Employer, University, Laboratory, Public Authority, or Funder Interest Disclosure. Contributors shall disclose whether a sponsor, provider, employer, university, laboratory, public authority, funder, grantor, investor, insurer, lender, National Consortium Company, Project SPV, or other actor has rights, interests, conditions, approval rights, publication rights, confidentiality rights, IP rights, data rights, or influence over the contribution. Such interests shall be reviewed to prevent sponsor control, provider preference, procurement distortion, public authority misdescription, finance overclaim, certification overclaim, recognition implication, or private capture.
273.18 Contribution Review, Acceptance, Rejection, Quarantine, Modification, Withdrawal, and Takedown. GCRI Canada may review, accept, reject, quarantine, modify, request changes to, restrict, reclassify, withdraw, remove, supersede, or take down a contribution based on rights, quality, security, data, AI, cyber, public authority, protected knowledge, finance-boundary, certification-boundary, procurement-boundary, provider-neutrality, sponsor influence, public-safe, licensing, export-control, research integrity, or correctionability concerns. Acceptance of a contribution shall not imply endorsement of the contributor, provider, sponsor, employer, university, funder, public authority, product, technology, or claim.
273.19 Contributor Records. GCRI Canada shall maintain contributor records, including contributor identity, capacity, contributor terms, contributor license agreements, assignments, license grants, patent grants, moral rights waivers or consents, representations and warranties, originality representations, third-party rights disclosures, open-source disclosures, data rights disclosures, confidentiality commitments, security commitments, vulnerability disclosures, AI-use disclosures, conflict disclosures, sponsor / provider / employer / university / laboratory / public authority / funder interest disclosures, contribution reviews, acceptance records, rejection records, quarantine records, modification records, withdrawal records, takedown records, correction records, and archives.
Section 274. Open Licensing, Open Source, Open Data, Research Licensing, Standards Licensing, Restricted Licensing, and Public-Good Licensing
274.1 Licensing Purpose. GCRI Canada shall maintain licensing rules for software, datasets, schemas, APIs, SDKs, dashboards, maps, data dictionaries, ontology files, model cards, dataset cards, system cards, benchmark cards, reference architectures, interoperability profiles, evidence profiles, Observatory profiles, AI governance profiles, cybersecurity profiles, test harnesses, gold vectors, negative tests, public-good baselines, technical documentation, research outputs, public-safe publications, controlled annexes, and other technical or institutional assets created, received, stewarded, published, restricted, or archived by GCRI Canada. Licensing shall be selected and administered to preserve public-benefit purpose, lawful rights, public-good stewardship, access discipline, data / AI / cyber controls, protected knowledge safeguards, public authority boundaries, finance-readiness boundaries, certification boundaries, procurement neutrality, sponsor support-without-control, provider neutrality, correctionability, and long-term institutional continuity.
274.2 Open-Source Licensing. GCRI Canada may release software and related documentation under open-source licenses where such release advances public-good use, reproducibility, transparency, public authority learning, technical literacy, interoperability, research integrity, community capacity, or Nexus-compatible public-good infrastructure. Open-source licensing shall be selected with regard to license compatibility, contribution rules, patent treatment, attribution, warranty disclaimers, liability limits, security posture, export-control issues, public authority restrictions, protected knowledge restrictions, and the need to prevent misuse of open release as certification, procurement approval, provider endorsement, public authority approval, finance-readiness, or Nexus-approved status.
274.3 Open Data Licensing. GCRI Canada may release data under open data licenses only where the data is lawful to release, public-safe, properly classified, rights-cleared, privacy-reviewed, protected-knowledge-reviewed, public authority-reviewed where applicable, cyber-reviewed, infrastructure-reviewed, and accompanied by appropriate limitations. Open data licensing shall not be used for personal information, sensitive personal information, protected knowledge, public authority-sensitive information, cyber-sensitive materials, infrastructure-sensitive data, finance-sensitive materials, confidential records, or restricted evidence unless lawful, approved, safeguarded, and public-safe. Open data release shall not imply completeness, accuracy guarantee, public authority approval, finance-readiness, certification, procurement approval, or operational suitability.
274.4 Research Licensing. Research outputs may be licensed for public-good research, education, policy learning, public authority literacy, academic collaboration, reproducibility, and institutional capacity formation. Research licenses may permit use, citation, reproduction, translation, adaptation, controlled reuse, or public-safe summary according to classification and rights. Research licensing shall preserve attribution, integrity, limitation language, correction rights, public-safe restrictions, data rights, publication review where applicable, and the ability of GCRI Canada to correct, supersede, withdraw, retract, or archive research outputs.
274.5 Standards Licensing. Where GCRI Canada stewards standards-supporting materials, interoperability profiles, technical baselines, schemas, ontology files, conformance-supporting materials, or methods intended to assist standards alignment, such materials may be licensed under terms appropriate for broad public-good use, implementation, review, adaptation, and interoperability. Standards licensing shall not create certification, accreditation, conformity assessment, compliance approval, legal equivalence, procurement mandate, public authority adoption, provider qualification, or official protocol authority by default. Any standards-related license shall include limitation language sufficient to prevent overclaim.
274.6 Public-Good Licensing. GCRI Canada may adopt public-good licensing models for technical assets intended to remain available for public-benefit use while preventing private capture, enclosure, misrepresentation, unsafe reuse, protected knowledge misuse, public authority data misuse, sponsor control, provider lock-in, or claims inflation. Public-good licenses may include openness, attribution, non-endorsement, share-back, public-safe use, anti-misrepresentation, no-certification, no-finance-readiness, no-procurement, no-public-authority-approval, no-provider-preference, no-sponsor-control, and correction-notice requirements where lawful and appropriate.
274.7 Restricted Licensing. GCRI Canada may apply restricted licensing where an asset contains sensitive methods, cyber-sensitive logic, infrastructure-sensitive information, public authority-sensitive materials, protected knowledge, personal information, finance-sensitive evidence, competition-sensitive materials, controlled technology, export-controlled elements, confidential third-party materials, or public-safe risks. Restricted licenses shall define permitted users, permitted uses, prohibited uses, access conditions, confidentiality, no-download requirements, AI-use restrictions, model-training restrictions, redistribution limits, publication limits, retention, deletion, correction, audit, and closeout obligations.
274.8 Controlled Access Licensing. Controlled access licensing may be used for assets that may be reviewed, tested, implemented, or adapted only within controlled rooms, data rooms, evidence rooms, public authority rooms, capital-reader rooms, secure repositories, or other approved environments. Controlled access licensing shall preserve source control, access logging, user identity, classification, role-based permissioning, no unauthorized copying, no unauthorized AI ingestion, no unauthorized external publication, no unauthorized derivative release, no provider preference, no public authority approval implication, and correctionability.
274.9 Defensive Licensing. GCRI Canada may use defensive licensing, defensive patent terms, non-assertion terms, defensive termination terms, anti-trolling provisions, anti-capture restrictions, and other lawful mechanisms to protect public-good technical assets from enclosure, predatory assertion, patent capture, exclusive provider control, sponsor capture, interoperability lock-in, or uses inconsistent with public-benefit purpose. Defensive licensing shall be designed to preserve lawful public-good use and shall not be used to unlawfully restrain competition, distort procurement, create hidden provider preference, or restrict legitimate independent innovation.
274.10 Non-Commercial Licensing Where Appropriate. GCRI Canada may use non-commercial licensing where commercial exploitation would undermine public-benefit purpose, protected knowledge obligations, public authority terms, donor restrictions, grant restrictions, community safeguards, research integrity, or anti-capture controls. Non-commercial licensing shall be defined with sufficient clarity to distinguish public-benefit research, education, public authority learning, nonprofit use, university use, community use, internal evaluation, and prohibited commercial exploitation. Non-commercial restrictions shall not be used where they would frustrate intended public-good adoption without a recorded public-benefit rationale.
274.11 Permissive Licensing Where Appropriate. GCRI Canada may use permissive licensing where broad adoption, implementation flexibility, public authority use, academic use, interoperability, public-good software reuse, or ecosystem development is the primary objective and risks of capture, unsafe use, protected knowledge misuse, public authority confusion, provider preference, or finance overclaim can be controlled through notices, disclaimers, trademark controls, compatibility-claim rules, contribution rules, and correction mechanisms. Permissive licensing shall not waive classification, data rights, export-control, public-safe, or protected knowledge obligations.
274.12 Copyleft Licensing Where Appropriate. GCRI Canada may use copyleft, reciprocal, share-alike, network-copyleft, or similar licensing where preservation of public-good reciprocity, downstream openness, anti-enclosure, improvement sharing, or community access is necessary or desirable. Copyleft licensing shall be reviewed for compatibility with public authority use, university use, provider implementation, restricted materials, export-control restrictions, standards adoption, procurement neutrality, and interoperability. Copyleft licensing shall not be selected without considering downstream operational and legal consequences.
274.13 Dual Licensing Where Approved. GCRI Canada may use dual licensing where different uses, audiences, jurisdictions, asset classes, public-good purposes, controlled-room uses, commercial uses, or partner contexts require different licensing terms. Dual licensing shall require competent approval and records identifying public-good license terms, restricted license terms, commercial terms where any, revenue or cost-recovery treatment where lawful, sponsor restrictions, provider neutrality, anti-capture controls, public-safe restrictions, and correction obligations. Dual licensing shall not allow private actors to purchase institutional authority, certification, procurement approval, finance-readiness, public authority status, or provider preference.
274.14 License Compatibility Review. Before release, integration, modification, redistribution, publication, or reliance, GCRI Canada shall conduct license compatibility review where an asset includes third-party software, open-source components, datasets, documentation, models, schemas, APIs, test harnesses, benchmarks, public authority materials, community materials, protected knowledge, or partner materials. Compatibility review shall identify license obligations, attribution, source disclosure, patent terms, copyleft triggers, commercial-use restrictions, data-use restrictions, AI-use restrictions, public authority terms, moral rights, export-control restrictions, and incompatibilities requiring rejection, isolation, relicensing, permission, or redesign.
274.15 License Compliance Review. GCRI Canada shall maintain license compliance review for assets it uses, modifies, distributes, publishes, embeds, indexes, trains on, incorporates, forks, mirrors, hosts, or makes available. Compliance review shall include attribution, notice files, license texts, source availability where required, modification notices, copyright notices, patent notices, data license terms, model license terms, public authority terms, contributor terms, open-source obligations, restricted-use obligations, and takedown or remediation procedures. License non-compliance shall trigger correction and dependency review.
274.16 License Selection Authority. License selection authority shall be exercised by the Board, an authorized officer, legal counsel, technical asset owner, or delegated licensing function according to policy and asset risk. Selection shall consider public-benefit purpose, intended audience, openness, anti-capture needs, security, privacy, protected knowledge, public authority terms, sponsor or donor restrictions, grant conditions, interoperability, standards alignment, commercial-use boundaries, export-control considerations, contribution model, correctionability, and long-term maintenance. No maintainer, contributor, provider, sponsor, or partner may select or change an official license without competent record.
274.17 No License That Undermines Public-Benefit Purpose, Privacy, Security, Protected Knowledge, Donor Restrictions, Grant Restrictions, or Non-Execution Boundary. GCRI Canada shall not adopt or accept a license that materially undermines its public-benefit purpose, nonprofit and non-distribution character, public-good stewardship, privacy obligations, security obligations, public authority terms, protected knowledge obligations, community safeguards, donor restrictions, grant restrictions, data rights, AI-use restrictions, export-control restrictions, correctionability, non-execution boundary, role separation, provider neutrality, sponsor support-without-control, procurement neutrality, finance-readiness boundary, certification boundary, or public authority boundary. Any proposed license presenting such risk shall be rejected, narrowed, conditioned, escalated, or corrected.
274.18 Licensing Records. GCRI Canada shall maintain licensing records, including license selection records, license texts, asset-license mappings, open-source records, open data records, research license records, standards license records, public-good license records, restricted license records, controlled access license records, defensive license records, non-commercial license records, permissive license records, copyleft license records, dual license approvals, compatibility reviews, compliance reviews, attribution records, third-party notices, contributor license records, patent grant records, public authority terms, protected knowledge restrictions, donor and grant restrictions, corrections, takedowns, disputes, and archives.
Section 275. Restricted Assets, Sensitive Infrastructure, Cybersecurity, Controlled Technology, Public Authority Data, Protected Knowledge, Personal Data, Commercial Sensitivity, and Finance-Sensitive Evidence
275.1 Restricted Asset Definition. A restricted asset means any technical, evidentiary, research, software, data, model, dashboard, map, schema, API, documentation, method, ontology, public authority, protected knowledge, cyber, infrastructure, finance, commercial, legal, or institutional asset that requires limited access, limited use, controlled handling, delayed publication, public-safe transformation, no-download treatment, export-control review, safeguards review, or restricted archival because unrestricted release could create legal, safety, privacy, cyber, infrastructure, community, public authority, finance, competition, donor, grant, research integrity, or institutional harm. Restricted asset status shall be recorded and shall govern use, sharing, publication, licensing, AI processing, retention, and correction.
275.2 Sensitive Infrastructure Assets. Sensitive infrastructure assets include records, maps, dashboards, diagrams, telemetry, logs, models, digital twins, dependencies, vulnerabilities, operating conditions, degraded-mode information, geospatial layers, AI-RAN or O-RAN information, DePIN node information, compute facility information, port information, telecom information, energy information, water information, food-system information, health-system information, transport information, public works information, cyber-physical system information, or other materials that could increase risk to mission-critical systems. Such assets shall be restricted unless public-safe review confirms release is lawful and safe.
275.3 Cybersecurity-Sensitive Assets. Cybersecurity-sensitive assets include vulnerabilities, exploits, proof-of-concept materials, access controls, credentials, secrets, tokens, keys, logs, cloud configurations, repository records, SBOMs, dependency risks, penetration test results, incident records, threat intelligence, prompt-injection examples, model attack records, data exfiltration paths, cyber telemetry, security architecture, and remediation plans. Such assets shall be subject to heightened access control, coordinated disclosure where applicable, need-to-know restrictions, secure storage, public-safe redaction, and incident response procedures.
275.4 Controlled Technology Assets. Controlled technology assets include software, models, datasets, methods, hardware designs, cryptographic systems, telecom-related materials, AI-RAN materials, O-RAN materials, DePIN materials, cyber tools, dual-use tools, advanced sensing materials, robotics or drone materials, compute materials, quantum-relevant materials, simulation systems, or other technical assets that may be subject to export-control, sanctions, controlled-technology, national security, public safety, contractual, public authority, or restricted-transfer considerations. Such assets shall not be transferred, published, licensed, exported, or made externally available without review.
275.5 Public Authority Data Assets. Public authority data assets include data, records, communications, reports, maps, dashboards, telemetry, public finance reader materials, emergency management materials, public health materials, public safety materials, infrastructure operator materials, regulator materials, municipal materials, ministry materials, Crown entity materials, utility materials, port materials, telecom materials, energy materials, water materials, food-system materials, health-system materials, cyber materials, and related public-sector materials received or used by GCRI Canada. Public authority data assets shall be handled according to capacity classification, data-sharing terms, confidentiality, public reference rules, public-safe restrictions, retention, correction, and no-delegation boundaries.
275.6 Public Safety Sensitive Assets. Public safety sensitive assets include materials that could cause panic, targeting, retaliation, unsafe reliance, operational disruption, public authority confusion, emergency response confusion, infrastructure misuse, cyber misuse, community harm, or public misinterpretation if released without context. Such assets may include degraded-mode indicators, resilience gaps, risk maps, critical dependency records, emergency-related data, health-sensitive signals, public trust indicators, and mission-critical observability outputs. Public safety sensitive assets require public-safe review before any external release.
275.7 Personal Information and Rights-Bearing Data Assets. Personal information and rights-bearing data assets include identifiable personal information, sensitive personal information, health information, employment information, participation records, research participant data, community participant data, public authority personnel data, contributor data, subscriber data, fellow data, donor data, grievance data, complaint data, protected participant data, biometric or location data, and other data capable of affecting rights, dignity, safety, privacy, or legal interests. Such assets shall be handled according to lawful basis, consent or other authority, minimization, access control, security, retention, deletion, correction rights, and breach response obligations.
275.8 Health-Sensitive Assets. Health-sensitive assets include health data, public health data, clinical data, hospital data, epidemiological data, mental health data, disability data, biosecurity data, health-system resilience data, occupational health data, community health information, health-related inferences, and health-sensitive public authority materials. Health-sensitive assets shall be subject to lawful basis review, privacy review, ethics review where required, public authority terms, de-identification or aggregation where appropriate, public-safe communication controls, and harm-prevention measures.
275.9 Community-Protected and Indigenous / Local / Territorial Knowledge Assets. Community-protected and Indigenous / local / territorial knowledge assets include Indigenous knowledge, local knowledge, territorial knowledge, cultural knowledge, environmental knowledge, sacred-site information, language materials, livelihoods information, community vulnerability data, protected participation materials, custodial knowledge, and community-sensitive risk information. Such assets shall not be treated as ordinary open data. They shall be governed by custodial authority, consent or authorization, context, attribution, non-extraction, withdrawal rights, correction rights, access limits, AI-use restrictions, publication restrictions, and safeguards review.
275.10 Commercially Sensitive Assets. Commercially sensitive assets include confidential provider information, sponsor information, donor information, funder information, pricing, costs, bids, market strategy, capacity, supplier terms, customer information, roadmaps, proprietary system data, vendor comparisons, provider performance records, investment-sensitive materials, insurance-sensitive materials, commercial agreements, and competition-sensitive records. Such assets shall be handled to prevent unlawful information exchange, market coordination, provider preference, procurement distortion, sponsor control, or improper private benefit.
275.11 Finance-Sensitive Evidence Assets. Finance-sensitive evidence assets include capital-readability materials, finance-boundary notes, public finance reader materials, investor-facing evidence, insurance-facing evidence, lender-facing evidence, project finance materials, revenue assumptions, risk allocation materials, guarantee-related records, underwriting-adjacent evidence, ratings-adjacent materials, National Consortium Company materials, Project SPV materials, and Nexus Rails technical evidence inputs. Such assets shall be restricted and shall include boundary language stating that GCRI Canada does not provide investment advice, securities advice, lending advice, insurance advice, underwriting approval, rating, public finance approval, capital placement, investor matchmaking, or finance-readiness determination.
275.12 Dual-Use Assets. Dual-use assets include technical assets, methods, datasets, models, software, cyber tools, AI tools, geospatial data, infrastructure records, sensing methods, digital twins, robotics or drone materials, compute methods, and observability outputs that may have beneficial public-good uses and harmful misuse potential. Dual-use assets shall be reviewed for safety, security, legal, export-control, public authority, safeguards, and public-safe risks before release, licensing, publication, or external transfer.
275.13 Export-Controlled Assets. Export-controlled assets include assets subject to export-control, sanctions, controlled goods, controlled technology, encryption, cyber, telecom, AI, compute, national security, dual-use, or restricted-transfer rules. GCRI Canada shall not publish, transfer, provide access to, license, train on, host externally, or export such assets without review and authorization. Export-control review shall be documented and may require external legal advice or public authority guidance where appropriate.
275.14 Sanctions-Sensitive Assets. Sanctions-sensitive assets include assets, data, software, technology, services, access, funding, support, or collaborations involving restricted parties, restricted jurisdictions, restricted sectors, restricted technologies, restricted public authorities, or sanctions-sensitive counterparties. Such assets shall be screened and controlled. Sanctions-sensitive concerns shall trigger restriction, refusal, suspension, access denial, contract review, or escalation where required.
275.15 Restricted Release Review. Restricted release review shall be required before any restricted asset is shared externally, published, licensed, transferred, embedded, indexed, used in AI systems, included in public-safe outputs, placed in a repository, or made accessible to a partner, public authority, provider, sponsor, university, laboratory, community, National Consortium Company, Project SPV, or Nexus interface. Review shall consider legal, data, AI, cyber, public authority, protected knowledge, infrastructure, finance, competition, export-control, sanctions, licensing, donor, grant, and public-safe issues.
275.16 Controlled Annex Treatment. Restricted assets may be placed in controlled annexes where controlled access is necessary for review, technical integrity, public authority learning, evidence support, safeguards review, finance-boundary review, legal review, or correctionability. Controlled annexes shall identify audience, purpose, classification, access controls, confidentiality, no-download rules, AI-use restrictions, redistribution limits, correction path, retention, and closeout.
275.17 No Public Release Without Public-Safe, Legal, Data, AI, Cyber, Export-Control, and Safeguards Review. No restricted asset shall be publicly released unless GCRI Canada completes public-safe review and any required legal, data, AI, cyber, privacy, public authority, infrastructure, finance-boundary, competition, export-control, sanctions, licensing, donor / grant, and safeguards review. Release shall include limitation language, source limitations, permitted use, prohibited use, non-endorsement, no-certification, no-finance-readiness, no-procurement, no-public-authority-approval, and correction path where appropriate.
275.18 Restricted Asset Records. GCRI Canada shall maintain restricted asset records, including restricted asset classifications, sensitive infrastructure records, cybersecurity-sensitive records, controlled technology records, public authority data records, public safety sensitive records, personal information records, rights-bearing data records, health-sensitive records, community-protected and Indigenous / local / territorial knowledge records, commercially sensitive records, finance-sensitive evidence records, dual-use records, export-control records, sanctions-sensitive records, restricted release reviews, controlled annex records, public-safe review records, correction records, access records, incident records, and archives.
Section 276. Software Security, Secure Development Lifecycle, Dependency Review, Code Review, Secrets Control, Repository Security, Vulnerability Management, and Incident Response
276.1 Software Security Purpose. GCRI Canada shall maintain software security rules for software, scripts, notebooks, APIs, SDKs, schemas, dashboards, data pipelines, model pipelines, retrieval systems, public-good technical assets, test harnesses, benchmark tools, observability tools, Truth Engine tools, verifiable compute tools, public-safe publication tools, and related repositories. Software security shall protect confidentiality, integrity, availability, authenticity, provenance, public-safe use, data rights, protected knowledge, public authority materials, cyber-sensitive materials, infrastructure-sensitive materials, finance-sensitive materials, institutional trust, and correctionability.
276.2 Secure Development Lifecycle. GCRI Canada shall maintain a secure development lifecycle for material software assets. The lifecycle may include design review, threat modeling, code review, dependency review, license review, static analysis, dynamic testing, secrets control, credential control, repository access control, branch protection, release protection, vulnerability management, incident response, documentation, versioning, deprecation, retirement, and archival. The lifecycle shall be proportionate to the asset’s risk, classification, public-safe status, deployment status, data access, and Nexus interface effect.
276.3 Secure Design Review. Secure design review shall evaluate software purpose, data flows, trust boundaries, access controls, authentication, authorization, input validation, output classification, logging, encryption, secrets handling, API exposure, AI-use exposure, prompt injection risk, data exfiltration risk, dependency risk, public authority data treatment, protected knowledge treatment, cyber sensitivity, infrastructure sensitivity, public-safe release, and correction path. Secure design review shall occur before material release or deployment where risk requires it.
276.4 Threat Modeling. Threat modeling may be required for assets involving public authority data, protected knowledge, cyber-sensitive data, infrastructure-sensitive data, AI systems, retrieval systems, public-safe dashboards, public-facing APIs, controlled rooms, data rooms, compute environments, or Nexus interfaces. Threat modeling shall identify assets, adversaries, misuse cases, attack paths, trust boundaries, failure modes, prompt injection risks, data leakage risks, operational misuse risks, and controls. Threat modeling records shall be classified where necessary.
276.5 Code Review. Code review shall be required for material software releases and may be required for internal software, restricted software, public-good software, dashboards, APIs, SDKs, data pipelines, model pipelines, test harnesses, schemas, and repository changes. Code review shall address correctness, security, maintainability, dependency risk, licensing, data handling, AI-use restrictions, public-safe effects, logging, error handling, access control, and correction path. Code review shall not be treated as certification, warranty, or provider approval.
276.6 Dependency Review. Dependency review shall identify libraries, packages, models, APIs, data sources, cloud services, AI providers, geospatial layers, dashboard frameworks, containers, operating systems, tools, scripts, licenses, known vulnerabilities, supply-chain risks, deprecations, unsupported dependencies, export-control issues, and provider dependencies. Dependency risk shall be recorded and shall trigger remediation, replacement, restriction, or limitation where appropriate.
276.7 License Review. License review shall be conducted for third-party components, open-source software, datasets, models, documentation, schemas, APIs, SDKs, test harnesses, benchmark tools, and dependencies. License review shall identify obligations, incompatibilities, attribution, source disclosure, patent terms, copyleft triggers, data-use restrictions, model-use restrictions, redistribution restrictions, commercial-use restrictions, and compatibility with GCRI Canada’s public-benefit purpose and licensing posture.
276.8 Static Analysis Where Appropriate. Static analysis may be used to identify security flaws, code quality issues, dependency issues, secrets, injection risks, unsafe functions, insecure configurations, licensing issues, and policy violations. Static analysis findings shall be triaged, corrected, waived with reason, or deferred with recorded limitation. Automated analysis shall support but not replace human judgment where risk is material.
276.9 Dynamic Testing Where Appropriate. Dynamic testing may be used to evaluate runtime behaviour, API security, dashboard behaviour, authentication, authorization, input handling, output leakage, prompt injection, data exfiltration, model behaviour, performance, resilience, and failure modes. Dynamic testing shall be conducted in approved environments with safe test data unless authorized otherwise. Test results shall be recorded and shall not be overclaimed as certification or security guarantee.
276.10 Secrets Control. Secrets, including passwords, API keys, tokens, certificates, private keys, credentials, service accounts, signing keys, encryption keys, database credentials, cloud credentials, and model-provider credentials, shall be controlled through approved storage, least privilege, rotation, revocation, monitoring, and incident response. Secrets shall not be stored in public repositories, unsecured files, prompts, chat systems, notebooks, logs, screenshots, documentation, or uncontrolled AI systems.
276.11 Credential Control. Credential control shall include identity verification, role-based access, multifactor authentication where appropriate, least privilege, time-bound access, review cycles, offboarding, credential rotation, privileged access management, service account controls, and access revocation. Credential sharing is prohibited unless expressly authorized under controlled procedure. Credential compromise shall trigger incident response.
276.12 Repository Access Control. Repository access shall be granted by role, purpose, need-to-know, contributor status, maintainer status, employment or contract status, public authority terms, protected knowledge restrictions, data class, and security requirements. Repository access shall distinguish read, write, approve, release, administer, merge, delete, publish, and archive permissions. Technical access shall not create governance authority or release authority.
276.13 Branch Protection. Branch protection may be required for official repositories, public-good software, schemas, APIs, technical baselines, ontology files, dashboards, public-safe tools, and controlled assets. Branch protection may require review approvals, status checks, signed commits, restricted merges, protected tags, dependency checks, security scans, release approvals, and prevention of force pushes. Branch protection shall preserve record integrity and no-silent-edit discipline.
276.14 Release Protection. Release protection shall govern publication of software, packages, APIs, dashboards, schemas, datasets, documentation, technical baselines, and other technical assets. Release protection may require release approval, version tag, change log, license review, security review, dependency review, public-safe review, documentation, known issue disclosure, limitation language, archive copy, and correction path. Release shall not imply certification, procurement approval, provider endorsement, public authority approval, or finance-readiness.
276.15 Vulnerability Management. GCRI Canada shall maintain vulnerability management for material software and technical assets. Vulnerability management shall include intake, triage, severity classification, affected asset review, dependency review, exploitability review, public-safe handling, remediation planning, patching, mitigation, coordinated disclosure where applicable, notification where required, release notes, correction records, and post-remediation review. Vulnerabilities shall not be concealed where correction or notice is required.
276.16 Vulnerability Disclosure. GCRI Canada shall maintain vulnerability disclosure channels and procedures proportionate to its assets. Disclosure procedures shall protect reporters from retaliation where acting in good faith, classify reports, restrict sensitive details, prevent exploit amplification, coordinate with affected parties, public authorities, providers, or maintainers where appropriate, and issue public-safe notices where required. Vulnerability disclosure shall not create bug bounty obligations unless separately approved.
276.17 Vulnerability Remediation Clocks. GCRI Canada may establish remediation clocks based on severity, exploitability, exposure, public authority impact, protected knowledge risk, data sensitivity, cyber sensitivity, infrastructure sensitivity, public-safe risk, availability of mitigation, and dependency ownership. Remediation clocks shall be recorded and reviewed. Failure to meet a remediation clock shall trigger escalation, risk acceptance, restriction, suspension, or public-safe limitation where appropriate.
276.18 Security Incident Response. Security incidents involving software assets, repositories, dependencies, credentials, secrets, APIs, dashboards, models, retrieval systems, compute environments, public authority data, protected knowledge, cyber-sensitive materials, infrastructure-sensitive materials, or public-safe outputs shall trigger containment, preservation of evidence, access review, credential rotation, affected-asset review, notification review, legal review, data / AI / cyber review, public authority review, safeguards review, correction, dependency review, and closeout.
276.19 Software Security Records. GCRI Canada shall maintain software security records, including secure development lifecycle records, secure design reviews, threat models, code reviews, dependency reviews, license reviews, static analysis records, dynamic testing records, secrets-control records, credential-control records, repository-access records, branch-protection records, release-protection records, vulnerability records, disclosure records, remediation clocks, security incident records, corrections, restrictions, suspensions, deprecations, retirements, and archives.
Section 277. Version Control, Change Logs, Release Notes, Deprecation Notices, Known Issues, and Correction Paths
277.1 Version Control Requirement. GCRI Canada shall maintain version control for material technical assets, including software, schemas, APIs, SDKs, dashboards, maps, data dictionaries, ontology files, model cards, dataset cards, system cards, benchmark cards, reference architectures, interoperability profiles, evidence profiles, Observatory profiles, AI governance profiles, cybersecurity profiles, test harnesses, gold vectors, negative tests, technical baselines, public-safe publications, controlled annexes, and documentation. Version control shall preserve traceability, no-silent-edit discipline, release integrity, public-safe clarity, dependency management, and correctionability.
277.2 Repository Discipline. Official repositories shall distinguish working branches, draft branches, protected branches, release branches, public branches, controlled branches, restricted branches, archive branches, forks, mirrors, and experimental branches. Repository discipline shall identify official source of truth, maintainers, owners, release authority, access rights, branch protections, review requirements, public-safe status, archive copies, and correction paths. Unofficial mirrors or forks shall not override official repositories.
277.3 Branch Discipline. Branch discipline shall define when branches may be created, who may create them, who may approve changes, when branches must be merged, archived, restricted, deleted, or retired, and how sensitive work is protected. Branch names, comments, issues, and pull requests shall avoid disclosure of protected knowledge, public authority-sensitive information, cyber-sensitive vulnerabilities, infrastructure-sensitive details, finance-sensitive information, confidential materials, or unsafe public claims.
277.4 Commit Discipline. Commit discipline shall require meaningful commit messages, author traceability, change scope, issue linkage where appropriate, review linkage, classification awareness, avoidance of secrets, avoidance of sensitive disclosure in commit text, and preservation of historical traceability. Commits affecting public-good assets, controlled assets, public-safe outputs, schemas, technical baselines, security controls, or Nexus interface records shall be reviewed according to risk.
277.5 Release Tagging. Material releases shall be tagged or otherwise identified with version, release date, release authority, repository reference, change log, license, public-safe status, security status, dependency status, known issues, limitations, correction path, and supersession relationship. Release tagging shall prevent ambiguity about operative versions and shall support rollback, deprecation, retirement, and archival.
277.6 Semantic Versioning Where Appropriate. Semantic versioning or an equivalent versioning method shall be used where changes may affect compatibility, public-safe meaning, schema structure, API behaviour, software behaviour, ontology meaning, evidence interpretation, dashboard output, technical baseline meaning, or Nexus interface alignment. Versioning shall distinguish major, minor, patch, editorial, security, emergency, controlled, restricted, deprecated, and retired versions where appropriate.
277.7 Change Logs. Change logs shall identify substantive changes, security changes, dependency changes, license changes, data rights changes, AI-use changes, public authority changes, protected knowledge changes, public-safe changes, compatibility changes, breaking changes, bug fixes, corrections, supersessions, withdrawals, retractions, deprecations, retirements, and archival actions. Change logs shall be public-safe or controlled according to classification.
277.8 Release Notes. Release notes shall summarize material changes, intended use, limitations, known issues, security status, dependency status, license status, public-safe status, migration requirements, deprecation status, public authority boundary language, finance-boundary language, certification-boundary language, procurement-boundary language, provider-neutrality language, and correction path where appropriate. Release notes shall not overclaim technical validity, public authority approval, certification, finance-readiness, procurement approval, or provider endorsement.
277.9 Known Issues. Known issues shall be recorded for material technical assets and shall identify defects, limitations, vulnerabilities, unsupported features, stale dependencies, public-safe limitations, data issues, model issues, dashboard issues, map issues, AI-use issues, protected knowledge restrictions, public authority restrictions, finance-boundary risks, certification-boundary risks, and compatibility concerns. Known issues shall be visible to authorized users and public-safe where release is public.
277.10 Limitations. Limitations shall be recorded for each material release. Limitations may include technical limits, data limits, model limits, method limits, jurisdictional limits, public authority limits, protected knowledge limits, cyber limits, infrastructure limits, finance-boundary limits, certification-boundary limits, procurement-boundary limits, provider-neutrality limits, security limits, and unsupported-use conditions.
277.11 Breaking Changes. Breaking changes shall be identified before release where a change may affect API compatibility, schema compatibility, software behaviour, data interpretation, ontology meaning, dashboard output, map output, technical baseline interpretation, model evaluation, evidence classification, or Nexus interface compatibility. Breaking changes shall include migration notes, dependency review, public-safe review, and notice where affected users may rely on the prior version.
277.12 Deprecation Notices. Deprecation notices shall identify assets, methods, versions, APIs, schemas, dashboards, datasets, models, technical baselines, or documentation that remain temporarily available but should not be used for new work. Deprecation notices shall include reason, effective date, sunset date where applicable, permitted interim use, prohibited use, successor asset where any, migration path, known risks, and correction path.
277.13 Migration Notes. Migration notes shall guide authorized users from superseded, deprecated, restricted, unsafe, insecure, or outdated assets to successor assets. Migration notes shall identify compatibility effects, data migration requirements, schema changes, API changes, security changes, model changes, public-safe changes, license changes, access changes, and reliance limits. Migration notes shall not imply equivalence where successor assets differ materially.
277.14 Correction Notices. Correction notices shall be issued where technical assets, release notes, public-safe outputs, documentation, dashboards, maps, schemas, APIs, models, datasets, or technical baselines contain errors, unsafe statements, public authority misdescription, finance overclaim, certification overclaim, procurement implication, provider preference, protected knowledge exposure, cyber issue, infrastructure issue, or other material defect. Correction notices may be public-safe, controlled, restricted, or internal according to classification.
277.15 Rollback Notes. Rollback notes shall record reversal to a prior version or disabling of a release due to error, vulnerability, data issue, model issue, dependency failure, public-safe issue, public authority concern, protected knowledge concern, finance-boundary issue, certification-boundary issue, procurement issue, or Nexus interface mismatch. Rollback notes shall identify affected versions, reason, authority, affected users, dependency review, and correction path.
277.16 Public-Safe Release Notes. Public-safe release notes shall be prepared for public releases where full technical detail would be unsafe or unnecessary. Public-safe release notes shall describe changes accurately without exposing vulnerabilities, protected knowledge, public authority-sensitive information, infrastructure-sensitive details, cyber-sensitive details, finance-sensitive materials, confidential materials, or unsafe operational information. Public-safe notes shall preserve limitation and correction language.
277.17 Controlled Release Notes. Controlled release notes may include technical details, sensitive methods, vulnerabilities, public authority materials, protected knowledge context, finance-sensitive details, infrastructure-sensitive details, cyber-sensitive details, or restricted dependency information. Controlled release notes shall be access-controlled, classified, no-download where appropriate, and correctionable. They shall not be redistributed or summarized publicly without public-safe review.
277.18 Version Control and Release Records. GCRI Canada shall maintain version control and release records, including repository records, branch records, commit records, release tags, semantic versioning records, change logs, release notes, known issue records, limitation records, breaking change records, deprecation notices, migration notes, correction notices, rollback notes, public-safe release notes, controlled release notes, release approvals, dependency reviews, security reviews, license reviews, public-safe reviews, and archives.
Section 278. Public-Good Baselines and No-Certification Boundary
278.1 Public-Good Baseline Purpose. GCRI Canada may create, maintain, publish, restrict, update, correct, supersede, or retire public-good baselines to support shared understanding, evidence discipline, methods discipline, observability, ontology, public-good software, public authority learning, safeguards, interoperability, and Nexus-compatible technical alignment. Public-good baselines shall be used as reference infrastructure for learning and implementation support, not as certification, accreditation, compliance approval, procurement mandate, public authority approval, finance-readiness determination, provider endorsement, or performance guarantee.
278.2 Open Technical Baseline. An open technical baseline may describe publicly available methods, schemas, software, reference patterns, data structures, ontology terms, security expectations, AI governance expectations, evidence structures, observability structures, or interoperability patterns. Open technical baselines shall include license terms, limitation language, public-safe status, versioning, known issues, contribution rules, correction path, and no-certification boundary language.
278.3 Reference Baseline. A reference baseline may describe a model approach, reference architecture, reference implementation, reference schema, reference method, or reference operating pattern for public-good use. Reference baselines shall be illustrative or normative only to the extent expressly recorded. Reference status shall not imply that every implementation using the baseline is approved, certified, compliant, secure, finance-ready, procurement-ready, or endorsed.
278.4 Evidence Baseline. An evidence baseline may describe minimum evidence fields, source lineage requirements, confidence fields, uncertainty fields, classification rules, limitation language, review requirements, and correction paths for defined evidence classes. Evidence baselines shall support evidence quality and interoperability and shall not create recognition, maturity status, finance-readiness, certification, public authority approval, procurement approval, or provider preference.
278.5 Observatory Baseline. An Observatory baseline may describe methods, schemas, source rules, dashboard rules, sensor rules, AI-RAN and O-RAN rules, DePIN telemetry rules, geospatial rules, cyber telemetry rules, degraded-mode awareness rules, resilience indicator rules, and public-safe output rules for observability work. Observatory baselines shall not create public warning authority, emergency command, operational control, infrastructure guarantee, Observatory certification, finance-readiness, procurement approval, or provider preference.
278.6 AI Governance Baseline. An AI governance baseline may describe model register requirements, inference records, human review triggers, model cards, dataset cards, system cards, benchmark cards, training restrictions, retrieval controls, agentic AI controls, incident response, bias review, drift review, public-safe review, and correction paths. AI governance baselines shall not constitute AI certification, compliance approval, product approval, public authority approval, legal advice, or regulated professional opinion.
278.7 Data Governance Baseline. A data governance baseline may describe data classification, source lineage, permissions, consent, data rights, public authority terms, protected knowledge rules, retention, deletion, access controls, retrieval controls, embedding controls, AI-use restrictions, public-safe release, and correction paths. Data governance baselines shall not authorize use of data absent lawful authority and shall not override privacy law, public authority terms, protected knowledge obligations, or data subject rights.
278.8 Cybersecurity Baseline. A cybersecurity baseline may describe secure development practices, repository controls, dependency review, secrets control, credential control, vulnerability management, incident response, logging, access review, secure compute, and cyber-sensitive publication restrictions. Cybersecurity baselines shall not constitute cybersecurity certification, insurance-readiness, underwriting approval, procurement approval, public authority approval, or security guarantee.
278.9 Interoperability Baseline. An interoperability baseline may describe common schemas, APIs, metadata, ontology terms, evidence profiles, observability profiles, technical interfaces, record mappings, compatibility notes, divergence logs, and correction paths for Nexus-compatible systems. Interoperability baselines shall support lawful coordination while preserving legal separateness, role separation, no-agency, no-merger, no-shared-liability, non-execution, public authority boundaries, finance-boundary language, and correctionability.
278.10 Conformance-Supporting Baseline. A conformance-supporting baseline may assist other bodies, providers, public authorities, researchers, or Nexus institutions in understanding what would be required to evaluate alignment with a method, schema, technical baseline, or interoperability profile. Conformance-supporting baselines shall not themselves certify conformance, accredit a provider, approve a product, approve procurement, approve finance-readiness, approve public authority use, or warrant performance. Any conformance determination must arise through a separate competent process and record.
278.11 Baseline Publication Review. Before publication, each public-good baseline shall undergo review for public-benefit alignment, licensing, source support, method support, security, dependency status, public-safe status, protected knowledge, public authority boundaries, finance-boundary implications, certification-boundary implications, procurement implications, provider-neutrality implications, sponsor influence, export-control considerations, and correction path. Publication shall include limitation language and versioning.
278.12 Baseline Limitations. Each public-good baseline shall identify limitations, including scope, intended use, prohibited use, jurisdictional limits, technical limits, data limits, model limits, method limits, public authority limits, cyber limits, infrastructure limits, protected knowledge limits, finance-boundary limits, certification-boundary limits, procurement-boundary limits, provider-neutrality limits, and unsupported-use conditions. Limitations shall be written in a form understandable to the intended audience.
278.13 Baseline Versioning. Public-good baselines shall be versioned. Versioning shall identify release date, effective date where applicable, approval authority, change log, known issues, dependency changes, security changes, public-safe changes, superseded baselines, deprecation status, and correction status. Baselines shall not be silently edited where meaning, compatibility, public claims, security posture, or reliance may change.
278.14 Baseline Correction. Public-good baselines shall be corrected where inaccurate, outdated, unsafe, unsupported, overbroad, ambiguous, misclassified, legally problematic, public authority-confusing, finance-implying, certification-implying, procurement-implying, provider-favouring, sponsor-benefiting, insecure, or inconsistent with GCRI Canada’s public-benefit purpose. Correction may include errata, limitation update, security update, public-safe notice, controlled notice, supersession, withdrawal, deprecation, or retirement.
278.15 No Baseline as Certification. No public-good baseline shall be represented as certification, conformity assessment, compliance approval, product approval, system approval, provider approval, professional credential, safety approval, performance assurance, or seal of assurance by GCRI Canada. Use of, reference to, implementation of, or alignment with a baseline shall not create certification.
278.16 No Baseline as Accreditation. No public-good baseline shall be represented as accreditation of an institution, provider, host, public authority, sponsor, project, National Consortium Company, Project SPV, software, dataset, model, dashboard, method, or technical system. Accreditation may arise only through a competent accreditation body and record, if available.
278.17 No Baseline as Compliance Approval. No public-good baseline shall be represented as legal, regulatory, statutory, contractual, cybersecurity, privacy, AI, environmental, telecom, public procurement, public finance, or other compliance approval. Compliance determinations require applicable competent authority, legal review, or formal assessment process and shall not be inferred from baseline use.
278.18 No Baseline as Procurement Mandate. No public-good baseline shall be represented as a procurement mandate, tender requirement, vendor qualification, preferred provider designation, purchasing recommendation, public-sector eligibility standard, or contract award condition by GCRI Canada. A public authority or procuring body may make its own lawful procurement decisions, but GCRI Canada baseline publication shall not itself create procurement meaning.
278.19 Public-Good Baseline Records. GCRI Canada shall maintain public-good baseline records, including baseline purpose records, open technical baseline records, reference baseline records, evidence baseline records, Observatory baseline records, AI governance baseline records, data governance baseline records, cybersecurity baseline records, interoperability baseline records, conformance-supporting baseline records, publication reviews, limitation records, versioning records, correction records, no-certification records, no-accreditation records, no-compliance-approval records, no-procurement-mandate records, notices, supersessions, withdrawals, retirements, and archives.
Section 279. Forks, Compatibility Claims, Nexus-Compatible Claims, and External Use Restrictions
279.1 Fork Governance. GCRI Canada shall maintain fork governance for technical assets, repositories, software, schemas, APIs, SDKs, dashboards, data dictionaries, ontology files, technical baselines, profiles, test harnesses, documentation, public-safe materials, and other assets that may be copied, forked, mirrored, adapted, integrated, or reused. Fork governance shall preserve license compliance, attribution, security, public-safe status, compatibility integrity, correctionability, trademark control, no-endorsement language, no-certification boundary, no-finance-readiness boundary, no-procurement boundary, and Nexus interface clarity.
279.2 External Forks. External forks may be permitted where licensing allows such use and the fork does not misrepresent affiliation, approval, certification, provider preference, public authority approval, Nexus compatibility, finance-readiness, procurement status, recognition, maturity, or official status. External fork users shall be required or requested, according to license and law, to preserve notices, attribution, license terms, public-good limitations, security notices, known issues, and correction references.
279.3 Internal Forks. Internal forks may be used for development, testing, localization, security review, public-safe transformation, controlled-room work, partner collaboration, public authority learning, or Nexus interface adaptation. Internal forks shall be registered where material, classified, access-controlled, versioned, reviewed, and reconciled or archived. Internal forks shall not silently become official releases or operative baselines without approval.
279.4 Fork Notice Where Required. Fork notice may be required where a fork materially changes function, security posture, public-safe status, license terms, compatibility, dependencies, public authority use, protected knowledge handling, data use, AI use, finance-boundary language, certification-boundary language, procurement language, or Nexus interface meaning. Fork notices shall identify fork origin, fork owner, changes, status, limitations, relation to the original asset, and non-endorsement language.
279.5 Fork License Compliance. Forks shall comply with applicable license terms, including attribution, copyright notice, patent terms, copyleft obligations, source disclosure where required, modification notices, data license terms, model license terms, redistribution limits, non-commercial limits, public-good restrictions, controlled access terms, and no-misrepresentation terms. Non-compliant forks may trigger correction, takedown, public clarification, legal review, or other enforcement action.
279.6 Fork Security Review Where Reintegrated. Where an external or internal fork is proposed for reintegration into an official GCRI Canada asset, it shall undergo security review, code review, dependency review, license review, contributor rights review, data rights review, AI-use review, public-safe review, protected knowledge review where applicable, public authority review where applicable, and compatibility review. Reintegrated forks shall not introduce hidden vulnerabilities, license conflicts, unauthorized data, sponsor influence, provider preference, or unsupported claims.
279.7 Compatibility Claim Rules. Compatibility claims shall be governed by recorded rules. A compatibility claim may state that an asset, method, schema, API, software tool, dashboard, model, dataset, system, provider implementation, host implementation, public authority implementation, National Consortium Company implementation, Project SPV implementation, or partner implementation aligns with or interoperates with a GCRI Canada asset only where the claim is supported by a competent record, defined compatibility criteria, version reference, test record where applicable, limitation language, and correction path.
279.8 Nexus-Compatible Claim Rules. No person shall claim that an asset, system, project, provider, host, sponsor, public authority process, National Consortium Company, Project SPV, dataset, model, dashboard, method, software, standard, baseline, or implementation is Nexus-compatible, Nexus-aligned, Nexus-approved, Nexus-recognized, Nexus-ready, or Nexus-certified by GCRI Canada unless such claim is supported by a competent Nexus interface record and lawful authority. Nexus-compatible claims shall identify scope, version, limitations, non-certification status, non-finance status, non-procurement status, and correction path.
279.9 GCRI-Compatible Claim Rules. No person shall claim that an external asset, fork, implementation, provider service, host system, public authority process, project, dataset, model, software, dashboard, or technical baseline is GCRI-compatible, GCRI-approved, GCRI-certified, GCRI-recognized, or GCRI-endorsed unless supported by competent record. Mere use of GCRI Canada materials, participation in GCRI Canada activities, contribution to a repository, attendance at a working group, sponsorship, subscription, or provider participation shall not create such claim.
279.10 Observatory-Compatible Claim Rules. No person shall claim Observatory-compatible, Observatory-approved, Observatory-certified, node-approved, hub-approved, cluster-approved, hotspot-approved, national-dense-core-approved, or public-safe-observatory status based merely on use of Observatory-related methods, profiles, schemas, dashboards, sensors, AI-RAN methods, O-RAN methods, DePIN methods, geospatial methods, or GCRI Canada materials. Observatory-compatible claims require defined scope, method reference, version reference, evidence record, limitation language, and competent authority where applicable.
279.11 Standards-Support Claim Rules. A standards-support claim may state that an asset supports, maps to, or assists with a standard, framework, protocol, taxonomy, or external reference only where mapping and limitation records support the claim. Standards-support claims shall not imply certification, accreditation, compliance approval, legal equivalence, public authority adoption, procurement requirement, provider qualification, or conformance assessment by GCRI Canada.
279.12 No External Use Claim Without Record. No external actor shall represent that use, download, fork, implementation, integration, modification, contribution, sponsorship, funding, provider participation, public authority participation, or reference to a GCRI Canada asset creates official status, compatibility status, Nexus-compatible status, certification, recognition, maturity, finance-readiness, procurement approval, public authority approval, provider preference, or public-good standing unless a competent record expressly authorizes the claim.
279.13 No Compatibility Claim by Mere Use, Fork, Download, Integration, Sponsorship, Provider Participation, or Contribution. Mere use, fork, download, integration, implementation, reference, sponsorship, donation, subscription, provider participation, contractor participation, public authority attendance, public authority data contribution, working group participation, code contribution, issue submission, pull request, academic collaboration, or public-good support shall not create a compatibility claim, Nexus-compatible claim, GCRI-compatible claim, Observatory-compatible claim, standards-support claim, recognition, certification, finance-readiness, procurement approval, or provider endorsement.
279.14 Misleading Fork or Compatibility Claim Correction. GCRI Canada may require correction of misleading fork claims, compatibility claims, Nexus-compatible claims, GCRI-compatible claims, Observatory-compatible claims, standards-support claims, public authority claims, sponsor claims, provider claims, finance claims, certification claims, procurement claims, or recognition claims. Correction may include direct notice, public-safe clarification, controlled notice, license enforcement, trademark enforcement, repository notice, takedown request, de-indexing request, public disclaimer, or legal review.
279.15 Takedown or Public Clarification Where Required. Where a misleading fork, unauthorized compatibility claim, unsafe external use, license breach, public authority misdescription, protected knowledge misuse, cyber-sensitive disclosure, infrastructure-sensitive disclosure, provider-preference claim, finance overclaim, certification overclaim, procurement implication, or Nexus misrepresentation creates material risk, GCRI Canada may issue a takedown request, public clarification, correction notice, controlled notice, cease-use request, repository report, or other lawful action. Takedown or clarification shall be proportionate and recorded.
279.16 Fork and Compatibility Claim Records. GCRI Canada shall maintain fork and compatibility claim records, including fork governance records, external fork notices, internal fork records, license compliance records, reintegration security reviews, compatibility claim records, Nexus-compatible claim records, GCRI-compatible claim records, Observatory-compatible claim records, standards-support claim records, unauthorized external use records, misleading claim records, correction records, takedown records, public clarification records, legal review records, dependency reviews, and archives.
Section 280. Commercial Use Boundaries and Anti-Capture Controls
280.1 Commercial Use Boundary Purpose. GCRI Canada shall maintain commercial use boundaries and anti-capture controls for public-good technical assets, public-good software, open technical baselines, datasets, schemas, APIs, SDKs, dashboards, maps, data dictionaries, ontology files, model cards, dataset cards, system cards, benchmark cards, test harnesses, reference architectures, interoperability profiles, Observatory profiles, AI governance profiles, cybersecurity profiles, technical documentation, and other assets. The purpose of such controls is to permit lawful public-benefit reuse where appropriate while preventing private capture, misleading endorsement, public authority misdescription, finance overclaim, certification overclaim, procurement distortion, provider preference, sponsor control, enclosure of public-good baselines, protected knowledge misuse, data misuse, and undermining of GCRI Canada’s non-executing role.
280.2 Permitted Commercial Use Where Licensed and Consistent With Public-Good Purpose. Commercial use may be permitted where the applicable license, agreement, policy, or Board-approved record allows such use and where the use is consistent with public-benefit purpose, public-good stewardship, data rights, protected knowledge safeguards, public authority terms, privacy, security, export-control rules, sanctions rules, anti-capture controls, provider neutrality, sponsor support-without-control, and correctionability. Permitted commercial use shall not imply endorsement, certification, public authority approval, procurement approval, finance-readiness, recognition, maturity status, provider preference, or official Nexus status.
280.3 Restricted Commercial Use. Commercial use may be restricted where assets contain sensitive methods, public authority data, protected knowledge, personal information, cyber-sensitive materials, infrastructure-sensitive materials, finance-sensitive evidence, controlled technology, export-controlled elements, donor-restricted materials, grant-restricted materials, research-restricted materials, confidential partner materials, or public-safe limitations. Restricted commercial use may require written permission, controlled access, non-disclosure obligations, public-safe review, attribution controls, no-endorsement language, audit rights, correction obligations, and takedown rights.
280.4 Prohibited Commercial Use. Commercial use shall be prohibited where it would violate law, license terms, public authority terms, donor restrictions, grant restrictions, privacy obligations, protected knowledge obligations, export-control rules, sanctions rules, confidentiality, research ethics, community safeguards, data rights, AI-use restrictions, cyber rules, infrastructure sensitivity rules, finance-boundary rules, certification-boundary rules, procurement-neutrality rules, or GCRI Canada’s public-benefit purpose. Prohibited use includes using GCRI Canada assets to mislead, certify, endorse, sell false readiness, capture public-good infrastructure, extract protected knowledge, or bypass public-safe controls.
280.5 No Commercial Use That Implies GCRI Canada Endorsement. No commercial actor shall use GCRI Canada assets, name, marks, publications, technical baselines, public-safe materials, software, dashboards, maps, methods, schemas, profiles, contributor status, sponsor status, provider participation, working group participation, or Nexus interface materials to imply that GCRI Canada endorses, approves, recommends, ranks, selects, certifies, validates, recognizes, guarantees, or prefers the actor, product, service, project, technology, investment, insurance product, or implementation unless a competent record expressly permits such statement.
280.6 No Commercial Use That Implies Public Authority Approval. No commercial use of GCRI Canada assets shall imply public authority approval, public authority endorsement, governmental adoption, regulatory approval, procurement approval, funding approval, public finance approval, public warning authority, emergency command authority, sovereign obligation, or official public-sector status. Public authority participation, data contribution, attendance, review, learning engagement, or reference in GCRI Canada materials shall not be used commercially to imply government approval.
280.7 No Commercial Use That Implies Provider Preference. No commercial use shall imply that a provider, vendor, host, contractor, consultant, AI provider, telecom provider, AI-RAN provider, O-RAN provider, DePIN provider, cybersecurity provider, cloud provider, data provider, software provider, National Consortium Company, Project SPV, or commercial actor is preferred, approved, selected, ranked, certified, procurement-ready, finance-ready, public authority-ready, or Nexus-selected by GCRI Canada. Participation, contribution, sponsorship, subscription, implementation, or use of public-good assets shall not create provider preference.
280.8 No Commercial Use That Implies Certification, Finance-Readiness, Insurance-Readiness, Procurement Approval, Recognition, or Maturity. No commercial use shall imply that GCRI Canada assets, methods, baselines, evidence packs, dashboards, maps, software, model cards, dataset cards, system cards, benchmark cards, technical notes, or public-safe outputs confer certification, accreditation, compliance approval, finance-readiness, insurance-readiness, investment suitability, bankability, underwriting approval, rating, public finance approval, procurement approval, recognition, standing, maturity status, Nexus Grid status, GRF recognition, or public legitimacy. Such claims require separate competent authority and record, if available.
280.9 No Commercial Use That Captures Public-Good Assets. No commercial actor shall use GCRI Canada public-good assets in a manner that captures, encloses, privatizes, misappropriates, misrepresents, monopolizes, or restricts the public-good value of those assets contrary to license terms, public-benefit purpose, anti-capture controls, or public-good stewardship. Capture may include proprietary enclosure of open baselines, misleading exclusive claims, restrictive sublicensing, patent assertion inconsistent with public-good terms, provider lock-in, platform lock-in, or sponsor-controlled derivatives.
280.10 No Commercial Use That Encloses Open Baselines. Open baselines shall not be enclosed through commercial terms, proprietary extensions, patent claims, restrictive integrations, contractual lock-ins, provider-specific claims, or marketing claims that prevent public-good reuse, interoperability, correctionability, or open comparison. Commercial actors may build on open baselines only subject to applicable license terms, attribution, limitation language, no-endorsement rules, compatibility-claim rules, and anti-capture controls.
280.11 No Commercial Use That Misuses Protected Knowledge or Public Authority Data. No commercial use shall extract, commercialize, train on, embed, sell, package, map, model, advertise, or otherwise exploit protected knowledge, Indigenous / local / territorial knowledge, community knowledge, public authority data, public authority-sensitive records, public safety-sensitive information, health-sensitive data, personal information, cyber-sensitive materials, infrastructure-sensitive materials, or controlled evidence unless lawful, authorized, safeguarded, and consistent with applicable restrictions. Commercial convenience shall not override safeguards or public authority terms.
280.12 No Commercial Use That Circumvents Data, AI, Cyber, Privacy, Export-Control, or Safeguards Rules. No commercial actor may use GCRI Canada assets to circumvent data rights, AI-use restrictions, model-training restrictions, retrieval restrictions, embedding restrictions, cyber controls, privacy obligations, public authority terms, export-control rules, sanctions rules, protected knowledge protocols, research ethics, community safeguards, public-safe restrictions, controlled-room rules, or no-download rules. Circumvention shall trigger correction, restriction, termination of access, takedown, legal review, or other lawful action.
280.13 Commercial Use Monitoring. GCRI Canada may monitor commercial use of its public-good assets, name, marks, publications, software, technical baselines, dashboards, maps, schemas, profiles, methods, compatibility claims, Nexus-compatible claims, public authority references, sponsor references, provider references, and public-safe outputs to detect misuse, overclaim, capture, license breach, unsafe publication, protected knowledge misuse, public authority misdescription, finance overclaim, certification overclaim, procurement implication, provider preference, or public confusion. Monitoring shall respect law, privacy, competition rules, and proportionality.
280.14 Commercial Use Correction and Enforcement. Where commercial use violates license terms, misstates authority, misuses GCRI Canada assets, creates public authority confusion, implies endorsement, implies provider preference, implies certification, implies finance-readiness, implies procurement approval, misuses protected knowledge, discloses restricted information, breaches data / AI / cyber rules, or captures public-good value, GCRI Canada may require correction, limitation, takedown, public clarification, license enforcement, access revocation, repository notice, trademark enforcement, contract enforcement, legal review, or other lawful remedy. Enforcement shall be proportionate and recorded.
280.15 Commercial Use Records. GCRI Canada shall maintain commercial use records, including permitted commercial use records, restricted commercial use records, prohibited use records, license records, public-good purpose reviews, anti-capture reviews, endorsement-boundary records, public authority approval-boundary records, provider-preference records, certification / finance / procurement / recognition / maturity boundary records, open baseline enclosure reviews, protected knowledge and public authority data misuse records, data / AI / cyber / privacy / export-control / safeguards circumvention records, monitoring records, correction records, enforcement records, takedown records, public clarification records, and archives.
Section 281. Patent, Defensive Publication, Royalty, Standards-Essential, and Anti-Enclosure Controls
281.1 Patent Strategy Purpose. GCRI Canada may maintain a patent, defensive publication, royalty, standards-essential, and anti-enclosure strategy only to the extent necessary or appropriate to protect public-good technical assets, preserve public-benefit use, prevent private capture, maintain interoperability, secure freedom to operate, support public-good software, protect open technical baselines, preserve correctionability, and avoid enclosure of methods, schemas, reference architectures, observability profiles, ontology structures, verifiable compute methods, verifiable intelligence records, and Nexus-compatible public-good technical infrastructure. Patent strategy shall be public-benefit protective in character and shall not be used to convert the public-good core of GCRI Canada into proprietary leverage, sponsor advantage, provider lock-in, procurement influence, finance-readiness leverage, certification leverage, or execution control.
281.2 Defensive Publication. GCRI Canada may use defensive publication where publication of a technical method, schema, software pattern, reference architecture, public-good baseline, ontology structure, evidence method, observability method, AI governance method, cybersecurity method, verifiable compute method, or Nexus-compatible technical pattern can help prevent improper patenting, enclosure, exclusive appropriation, or future restriction of public-good use. Defensive publication shall be reviewed for public-safe status, protected knowledge, cyber sensitivity, infrastructure sensitivity, public authority sensitivity, export-control risk, data rights, third-party rights, sponsor restrictions, donor restrictions, grant restrictions, and correctionability before release.
281.3 Patent Filing Where Public-Good Protective. GCRI Canada may authorize patent filing only where the filing is reasonably determined to protect public-benefit purpose, prevent enclosure, preserve freedom to operate, support defensive licensing, protect public-good implementation pathways, prevent hostile appropriation, or enable controlled access to sensitive or dual-use technical assets. Patent filing shall not be pursued merely for valuation optics, sponsor preference, provider advantage, market power, investment signalling, finance-readiness, procurement positioning, or institutional prestige. Any patent filing shall be approved by competent authority and recorded with public-benefit rationale, inventor records, ownership records, assignment records, licensing strategy, restrictions, and correction path.
281.4 Patent Non-Assertion Where Appropriate. GCRI Canada may adopt patent non-assertion commitments where such commitments advance public-good use, interoperability, open technical baselines, research adoption, public authority learning, academic use, community use, public-safe implementation, or Nexus-compatible ecosystem development. Non-assertion commitments may be limited by field of use, defensive termination, public-benefit purpose, protected knowledge restrictions, safety restrictions, export-control rules, sanctions rules, misuse restrictions, no-endorsement language, and no-certification language. Non-assertion shall not waive rights needed to respond to capture, unsafe use, patent aggression, misrepresentation, or breach of public-good restrictions.
281.5 Royalty-Free Licensing Where Appropriate. GCRI Canada may license patents, patentable methods, standards-supporting assets, technical baselines, schemas, reference implementations, software, or other technical assets on a royalty-free basis where royalty-free licensing advances public-benefit purpose, broad adoption, public authority learning, public-good interoperability, research reproducibility, accessibility, or anti-enclosure objectives. Royalty-free licensing shall include appropriate disclaimers, attribution, non-endorsement, no-certification, no-finance-readiness, no-procurement, no-public-authority-approval, no-provider-preference, no-warranty, and correction language where required.
281.6 Reasonable Licensing Where Appropriate. GCRI Canada may use reasonable licensing terms, including cost-recovery terms, controlled access terms, field-limited terms, restricted-use terms, research-use terms, public-good terms, or other reasonable conditions, where unrestricted royalty-free licensing would create risks to public-benefit purpose, protected knowledge, public authority data, cyber security, infrastructure security, dual-use safety, controlled technology, export-control compliance, sanctions compliance, donor restrictions, grant restrictions, or long-term stewardship. Reasonable licensing shall not be structured to create private capture, hidden provider preference, sponsor control, unlawful market allocation, procurement distortion, certification leverage, or finance-readiness implication.
281.7 Standards-Essential Technology Review. Where a GCRI Canada technical asset, patent, method, schema, interoperability profile, public-good baseline, or reference implementation may become relevant to a standard, framework, protocol, public authority specification, or Nexus-compatible interoperability pathway, GCRI Canada shall conduct standards-essential technology review. The review shall consider disclosure duties, licensing obligations, royalty-free or reasonable-and-non-discriminatory terms where applicable, patent encumbrances, compatibility with public-good use, public authority adoption implications, procurement implications, provider neutrality, anti-capture requirements, and no-certification boundaries. Standards-essential status shall not be claimed without competent review and record.
281.8 Royalty Controls. Any royalty, fee, cost-recovery charge, sublicensing fee, access fee, standards-related royalty, or commercialization revenue associated with GCRI Canada technical assets shall be governed to preserve nonprofit, non-share, non-distributing, public-benefit character and to prevent improper private benefit, sponsor control, provider preference, procurement distortion, finance-readiness implication, certification implication, or enclosure of public-good assets. Royalty controls shall identify permitted uses of revenue, restrictions, reporting, conflict review, donor or grant compatibility, tax or regulatory considerations, and correction path.
281.9 Patent Pledge Where Appropriate. GCRI Canada may adopt a patent pledge, public-good patent covenant, defensive patent commitment, open implementation pledge, public authority learning pledge, research-use pledge, or standards-support pledge where such instrument protects public-benefit use and prevents enclosure. A patent pledge shall identify covered rights, covered assets, covered users, permitted uses, prohibited uses, defensive termination conditions, protected knowledge restrictions, export-control limits, public authority limits, field limits where any, attribution or notice requirements, and correction or withdrawal conditions where lawful.
281.10 Anti-Enclosure Controls. GCRI Canada shall maintain anti-enclosure controls to prevent public-good technical assets, open baselines, schemas, reference implementations, ontology structures, evidence methods, observability methods, AI governance methods, cybersecurity profiles, public-safe publication tools, and Nexus-compatible interoperability assets from being converted into private leverage or exclusive control contrary to public-benefit purpose. Anti-enclosure controls may include licensing terms, defensive publication, patent pledges, non-assertion commitments, compatibility claim rules, no-endorsement rules, fork rules, contribution rules, takedown rights, trademark controls, repository controls, and public clarification rights.
281.11 No Patent Strategy That Converts Public-Good Core Into Private Leverage. No patent strategy, filing, license, pledge, royalty arrangement, standards position, contribution term, joint development term, sponsored research term, provider arrangement, or partner arrangement shall convert the public-good core of GCRI Canada into private leverage, exclusive provider control, sponsor-controlled advantage, procurement influence, finance-readiness influence, certification leverage, public authority capture, or market gatekeeping. Public-good technical assets shall remain governed by public-benefit purpose, role separation, non-execution, correctionability, and anti-capture discipline.
281.12 No Sponsor or Provider Control of Patent Strategy. No sponsor, donor, funder, provider, host, contractor, consultant, investor, insurer, lender, National Consortium Company, Project SPV, university, laboratory, or external partner shall control GCRI Canada’s patent strategy, defensive publication strategy, licensing posture, standards-essential disclosure posture, royalty strategy, non-assertion commitments, patent pledges, enforcement decisions, or anti-enclosure controls. External views may be considered through recorded process, but final authority shall remain with GCRI Canada’s competent governance authority and legal review.
281.13 No Hidden Encumbrance of Public-Good Technical Assets. GCRI Canada shall not knowingly permit hidden patent encumbrances, undisclosed third-party rights, undisclosed sponsor rights, undisclosed provider rights, undisclosed university rights, undisclosed employer rights, undisclosed public authority restrictions, undisclosed open-source conflicts, undisclosed data rights, or undisclosed controlled-technology restrictions to attach to public-good technical assets. Where an encumbrance is discovered, GCRI Canada shall classify, disclose internally, correct, restrict, redesign, relicense, obtain permission, remove, supersede, withdraw, or archive the affected asset as appropriate.
281.14 Patent and Defensive Publication Records. GCRI Canada shall maintain patent and defensive publication records, including invention disclosures, inventor records, assignment records, ownership records, patent filing approvals, public-benefit rationales, defensive publication records, public-safe reviews, patent non-assertion records, royalty-free license records, reasonable license records, standards-essential technology reviews, royalty records, patent pledge records, anti-enclosure control records, sponsor and provider influence reviews, encumbrance reviews, correction records, restrictions, withdrawals, takedowns, supersessions, retirements, and archives.
Section 282. Data and Model IP, Synthetic Data, Derived Data, Embeddings, Fine-Tuned Models, Prompts, Evaluation Sets, and Benchmark Assets
282.1 Data IP Governance. GCRI Canada shall govern data and model intellectual property, including dataset rights, derived data rights, synthetic data rights, embedding rights, vector store rights, prompt rights, prompt library rights, fine-tuned model rights, model weight rights, adapter rights, evaluation set rights, benchmark rights, test vector rights, gold vector rights, negative test rights, and related documentation, according to public-benefit purpose, lawful authority, chain of title, license terms, data rights, privacy, public authority terms, protected knowledge obligations, AI-use restrictions, cyber controls, public-safe release controls, export-control rules, sanctions rules, and correctionability. Data and model IP governance shall prevent unauthorized training, hidden rights conflicts, protected knowledge extraction, public authority data misuse, private capture, provider lock-in, and sponsor control.
282.2 Dataset Rights. Dataset rights shall be recorded for material datasets collected, received, created, cleaned, transformed, labeled, annotated, purchased, licensed, scraped, contributed, derived, synthesized, or stewarded by GCRI Canada. Dataset rights records shall identify source, ownership, license, consent, public authority terms, contributor terms, research ethics approvals, protected knowledge restrictions, privacy restrictions, AI-use permissions, model-training restrictions, redistribution limits, retention, deletion path, attribution, limitations, and correction rights.
282.3 Derived Data Rights. Derived data rights shall be reviewed where GCRI Canada creates transformed, cleaned, aggregated, inferred, linked, scored, classified, summarized, de-identified, redacted, normalized, enriched, geocoded, embedded, labeled, benchmarked, or model-generated data from source data. Derived data shall not be assumed free of source restrictions. Rights, limitations, consent scope, public authority terms, protected knowledge obligations, privacy risks, re-identification risk, and downstream use restrictions shall follow derived data where applicable.
282.4 Synthetic Data Rights. Synthetic data rights shall be governed by the source data, generation method, model used, intended use, privacy risk, protected knowledge risk, public authority terms, training restrictions, benchmark purpose, and public-safe status. Synthetic data shall not be treated as automatically unrestricted, non-sensitive, rights-free, bias-free, public-safe, or suitable for publication. Synthetic data that can reveal, reconstruct, approximate, or expose restricted patterns, protected knowledge, personal information, cyber-sensitive details, infrastructure-sensitive details, or public authority-sensitive information shall remain restricted.
282.5 Embedding Rights and Restrictions. Embedding rights shall identify whether source materials may be converted into embeddings, vectors, semantic representations, retrieval indexes, knowledge graphs, model memory, or other machine-readable representations. Embedding restrictions shall preserve data rights, deletion rights, withdrawal rights, public authority terms, protected knowledge obligations, privacy obligations, access controls, AI-use restrictions, model-training restrictions, and public-safe limits. Embeddings shall not be treated as rights-free merely because they are transformed representations.
282.6 Vector Store Rights and Restrictions. Vector stores shall be governed as controlled technical assets. Rights and restrictions shall identify source scope, access permissions, document-level restrictions, row-level restrictions, room-level restrictions, jurisdiction, provider terms, deletion capability, re-indexing obligations, retention, export limits, leakage risks, protected knowledge treatment, public authority data treatment, and correction path. Vector stores shall not permit unauthorized retrieval, reconstruction, summarization, or inference beyond source permissions.
282.7 Prompt and Prompt Library Rights. Prompts, prompt templates, system instructions, evaluation prompts, red-team prompts, controlled-room prompts, public-safe publication prompts, retrieval prompts, agentic workflows, and prompt libraries created by or for GCRI Canada shall be treated as technical assets where material. Prompt rights shall identify authorship, ownership, license, confidentiality, security classification, public-safe status, model dependency, data rights embedded in prompts, protected knowledge exposure, prompt injection risk, and correction path.
282.8 Fine-Tuned Model Rights. Fine-tuned model rights shall identify the base model, provider terms, training data rights, fine-tuning authority, training environment, model owner, output rights, deployment restrictions, redistribution restrictions, deletion or unlearning possibilities, evaluation obligations, public-safe restrictions, and correction path. Fine-tuned models created using GCRI Canada data, public authority data, protected knowledge, restricted evidence, or sponsor or provider materials shall be restricted unless expressly approved and rights-cleared.
282.9 Model Weight Rights. Model weight rights shall identify ownership, license, source, provider terms, open-source terms, restricted-use terms, redistribution rights, modification rights, access restrictions, security risks, export-control issues, and model-card obligations. Model weights shall not be published, shared, transferred, fine-tuned, embedded, or deployed unless permitted by law, license, policy, classification, public-safe review, and security review.
282.10 Adapter and LoRA Rights Where Applicable. Adapters, LoRA weights, fine-tuning layers, embeddings, retrieval adapters, alignment layers, policy heads, evaluation heads, or other model modifications shall be governed by rights records identifying base model compatibility, training data rights, authorship, ownership, license, distribution rights, deployment limits, public-safe status, security risk, export-control considerations, and correction path. Adapter rights shall not be assumed independent of base model or training data restrictions.
282.11 Evaluation Set Rights. Evaluation set rights shall identify source materials, authorship, licenses, permissions, protected knowledge restrictions, public authority terms, privacy considerations, benchmark purpose, secrecy requirements, public-safe status, access controls, and reuse limits. Evaluation sets may need to remain restricted to prevent benchmark gaming, protected knowledge exposure, cyber-sensitive disclosure, infrastructure-sensitive disclosure, or invalid public claims.
282.12 Benchmark Asset Rights. Benchmark asset rights shall identify ownership, license, source data, test design, metrics, expected outputs, public-safe status, permitted use, prohibited use, provider-use limits, publication limits, evaluation limits, anti-gaming restrictions, and correction path. Benchmark assets shall not be used to create provider rankings, certification, procurement approval, finance-readiness, or performance warranties unless separately authorized by competent authority.
282.13 Test Vector Rights. Test vector rights shall identify source, authorship, ownership, license, expected result, use limitation, public-safe status, confidentiality, security classification, and correction path. Test vectors involving protected knowledge, cyber-sensitive data, infrastructure-sensitive data, public authority data, personal information, or finance-sensitive materials shall be restricted and may require controlled-room use.
282.14 Gold Vector Rights. Gold vector rights shall identify canonical expected outputs or reference cases, including source authority, reviewer authority, method authority, public-safe status, version, limitation, and correction path. Gold vectors shall not be represented as proof of universal validity, certification, compliance, procurement approval, finance-readiness, or provider superiority.
282.15 Negative Test Rights. Negative test rights shall identify rights and restrictions for tests designed to reveal failures, vulnerabilities, hallucinations, bias, prompt injection, data leakage, public authority misdescription, finance overclaim, certification overclaim, procurement implication, protected knowledge exposure, cyber leakage, infrastructure leakage, or unsafe public outputs. Negative tests shall be classified and access-controlled where publication could enable misuse.
282.16 Public-Safe Release Review. Data and model IP assets shall undergo public-safe release review before external release. Review shall consider source rights, licenses, consent, privacy, re-identification risk, public authority terms, protected knowledge, cyber sensitivity, infrastructure sensitivity, finance sensitivity, competition sensitivity, export-control issues, sanctions issues, model-use restrictions, benchmark gaming, public overclaim, provider preference, and correctionability. Release shall include limitation language and no-endorsement language where appropriate.
282.17 Protected Knowledge, Public Authority Data, and Personal Data Restrictions. No dataset, derived data, synthetic data, embedding, vector store, prompt, fine-tuned model, model weight, adapter, evaluation set, benchmark asset, test vector, gold vector, or negative test shall use, expose, train on, embed, summarize, publish, transfer, or commercialize protected knowledge, public authority data, personal information, health-sensitive data, cyber-sensitive data, infrastructure-sensitive data, or finance-sensitive evidence unless lawful authority, review, safeguards, classification, access controls, permitted-use terms, and correction path are recorded.
282.18 Data and Model IP Records. GCRI Canada shall maintain data and model IP records, including data IP governance records, dataset rights records, derived data rights records, synthetic data rights records, embedding rights records, vector store rights records, prompt rights records, prompt library records, fine-tuned model rights records, model weight rights records, adapter and LoRA rights records, evaluation set rights records, benchmark asset rights records, test vector rights records, gold vector rights records, negative test rights records, public-safe release reviews, protected knowledge restriction records, public authority data restriction records, personal data restriction records, corrections, takedowns, supersessions, withdrawals, retirements, and archives.
Section 283. Repository Security, Build Pipelines, Release Systems, Package Channels, Schema Registries, Reference Implementations, and Public-Good Technical Baselines
283.1 Repository Security Purpose. GCRI Canada shall maintain repository security, build pipeline security, release system security, package channel controls, schema registry controls, reference implementation controls, and technical baseline release controls for material technical assets. The purpose of these controls is to preserve source integrity, chain of custody, software security, licensing discipline, public-safe release, dependency assurance, provenance, auditability, correctionability, and trust in public-good technical assets without creating certification, procurement approval, provider preference, public authority approval, or finance-readiness.
283.2 Approved Repositories. Material technical assets shall be stored, developed, reviewed, released, or archived only in approved repositories or approved controlled locations. Approved repositories may include public repositories, private repositories, restricted repositories, controlled-room repositories, data-room repositories, schema registries, package registries, model registries, artifact registries, documentation repositories, archive repositories, or public-safe publication repositories. Repository approval shall identify permitted asset classes, access controls, jurisdiction, security baseline, logging, backup, retention, and incident procedures.
283.3 Repository Ownership. Each official repository shall have an owner responsible for purpose, authority, asset classification, repository scope, access posture, release authority, security posture, licensing posture, public-safe status, correction process, deprecation, transfer, archival, and institutional continuity. Repository ownership shall remain subject to Board authority, officer delegation, law, policy, and this Bylaw.
283.4 Repository Custodianship. Each official repository shall have a custodian responsible for maintaining access controls, branch protections, issue settings, pull request rules, secrets controls, dependency alerts, release tags, archive copies, logs, incident records, and repository health. Custodianship may be technical and operational, but it shall not create authority to alter public meaning, license posture, classification, publication status, or institutional commitments without competent record.
283.5 Repository Access Controls. Repository access shall be role-based, purpose-bound, least-privilege, time-limited where appropriate, and reviewed periodically. Access levels shall distinguish read, triage, write, maintain, approve, merge, release, administer, archive, and delete permissions. Access to restricted repositories shall account for public authority terms, protected knowledge, cyber sensitivity, infrastructure sensitivity, finance sensitivity, export-control restrictions, sanctions restrictions, confidentiality, and conflict status.
283.6 Branch Protection. Official branches shall be protected where changes may affect public-good software, schemas, APIs, SDKs, technical baselines, controlled assets, public-safe outputs, data rights, security posture, public authority materials, protected knowledge, finance-sensitive materials, or Nexus interface records. Branch protection may require code owner review, status checks, signed commits, security checks, dependency checks, license checks, public-safe review, and release approval.
283.7 Code Owner Review. Repositories may require code owner review or asset owner review for changes affecting core files, schemas, APIs, security controls, release workflows, public-safe language, licenses, controlled annexes, public authority materials, protected knowledge, finance-boundary language, certification-boundary language, procurement-boundary language, provider-neutrality language, or Nexus interface records. Code owner review shall be recorded and shall not be treated as certification or warranty.
283.8 Build Pipeline Security. Build pipelines shall be secured against unauthorized code execution, dependency poisoning, artifact substitution, secret exposure, build environment tampering, malicious workflow changes, compromised runners, unauthorized release, and supply-chain attacks. Build pipeline controls may include isolated runners, permission scoping, signed commits, locked dependencies, reviewed workflow changes, provenance generation, artifact signing, log retention, and restricted release permissions.
283.9 Continuous Integration and Continuous Delivery Controls. Continuous integration and continuous delivery systems shall be configured to support testing, security checks, dependency checks, license checks, build reproducibility where appropriate, release gates, manual approval for sensitive releases, public-safe review, and rollback. Automated CI / CD shall not bypass human approval where releases affect public assets, controlled assets, public authority materials, protected knowledge, security posture, or Nexus interface meaning.
283.10 Package Channel Controls. Package channels used to distribute software, SDKs, APIs, schemas, models, documentation, or other technical assets shall be controlled for naming, ownership, access, signing, versioning, release authority, dependency integrity, takedown, deprecation, and archival. Package channels shall not be used to imply certification, public authority approval, procurement approval, finance-readiness, provider preference, or official Nexus status beyond the recorded release.
283.11 Artifact Registry Controls. Artifact registries shall be controlled for container images, build artifacts, packages, binaries, model artifacts, datasets, schemas, dashboards, maps, and other release artifacts. Controls shall include provenance, signatures where appropriate, retention, immutability where appropriate, access control, vulnerability scanning, license metadata, classification, public-safe status, dependency records, and correction paths.
283.12 Schema Registry Controls. Schema registries shall maintain official schema versions, draft schemas, deprecated schemas, superseded schemas, controlled schemas, public-safe schemas, compatibility notes, breaking change records, validation rules, access controls, and correction records. Schema registries shall preserve semantic meaning and shall not permit silent changes that affect evidence records, dashboards, APIs, public authority records, finance-boundary records, or Nexus interfaces.
283.13 Reference Implementation Controls. Reference implementations shall be maintained with versioning, licensing, documentation, test harnesses, known limitations, security review, dependency review, public-safe status, no-certification language, no-warranty language, and correction path. Use of a reference implementation shall not mean that a derivative implementation, provider implementation, public authority implementation, or project implementation is approved, certified, compliant, finance-ready, procurement-ready, or endorsed.
283.14 Technical Baseline Release Controls. Technical baseline releases shall require approval proportionate to public meaning and risk. Release controls shall address source support, method support, licensing, security, dependency status, public-safe review, protected knowledge, public authority boundaries, finance-boundary language, certification-boundary language, procurement-boundary language, provider neutrality, sponsor influence, export-control issues, versioning, limitation language, and correction path.
283.15 Third-Party Repository Mirroring. Third-party repository mirroring may be permitted where it supports resilience, access, public-good dissemination, research reproducibility, or archival, and where it complies with license, classification, public-safe status, data rights, protected knowledge obligations, public authority terms, export-control rules, and security controls. Mirrors shall identify whether they are official, unofficial, archival, read-only, delayed, public-safe, or restricted. Mirrors shall not override official repositories.
283.16 Repository Transfer, Archival, or Decommissioning. Repository transfer, archival, or decommissioning shall be approved and recorded where a repository changes owner, custodian, organization, location, access class, public-safe status, release status, or operational status. The process shall preserve records, issues, pull requests, releases, tags, licenses, security advisories, dependency records, correction notices, archive copies, access logs where retained, and public-safe notices where necessary.
283.17 Repository Security Incident Response. Repository security incidents shall trigger containment, access review, credential rotation, secret revocation, branch protection review, release freeze, malicious commit review, dependency review, artifact review, package channel review, public-safe notice where required, takedown where necessary, affected-user notice where appropriate, and correction. Repository incident response shall preserve evidence and audit logs.
283.18 Repository and Release System Records. GCRI Canada shall maintain repository and release system records, including approved repository records, ownership records, custodianship records, access control records, branch protection records, code owner review records, build pipeline records, CI / CD control records, package channel records, artifact registry records, schema registry records, reference implementation records, technical baseline release records, mirror records, transfer records, archival records, decommissioning records, security incident records, corrections, takedowns, supersessions, and archives.
Section 284. Key Management, Token Management, Signing Keys, API Tokens, Service Credentials, Secrets, and Recovery Codes
284.1 Key Management Purpose. GCRI Canada shall maintain key management, token management, signing key, API token, service credential, secrets, and recovery code controls to protect institutional systems, repositories, technical assets, build pipelines, release systems, package channels, dashboards, APIs, SDKs, AI systems, retrieval systems, compute environments, data rooms, controlled rooms, public authority materials, protected knowledge, cyber-sensitive materials, infrastructure-sensitive materials, finance-sensitive materials, and public-safe outputs. Credential controls shall support least privilege, auditability, recovery, revocation, incident response, and institutional continuity.
284.2 Signing Key Controls. Signing keys used for commits, releases, packages, containers, schemas, artifacts, dashboards, public-good baselines, or official records shall be generated, stored, used, rotated, and revoked under approved controls. Signing keys shall be protected against unauthorized access, sharing, copying, unlogged use, export, loss, and compromise. Use of a signing key shall identify the signer, authority, asset, version, release, date, and scope.
284.3 API Token Controls. API tokens shall be scoped to the minimum permissions necessary, tied to named users or approved service identities where appropriate, time-limited where feasible, stored securely, monitored, rotated, and revoked when no longer needed. API tokens shall not be placed in code, repositories, notebooks, prompts, chat systems, public documents, logs, screenshots, dashboards, or uncontrolled environments. Token leakage shall trigger incident response.
284.4 Service Credential Controls. Service credentials shall be issued only for approved systems and approved purposes. Each service credential shall have an owner, custodian, purpose, scope, permissions, environment, rotation schedule, revocation path, logging, and emergency contact. Service credentials shall not be used as shared personal credentials or to bypass access controls, room restrictions, public authority terms, protected knowledge restrictions, or audit logs.
284.5 Secrets Management. Secrets shall be stored in approved secrets-management systems or secure key storage appropriate to sensitivity. Secrets include passwords, API keys, tokens, certificates, private keys, signing keys, database credentials, encryption keys, webhook secrets, recovery codes, cloud credentials, model-provider credentials, package registry credentials, and service account credentials. Secrets shall be encrypted, access-controlled, logged where appropriate, rotated, and excluded from public or uncontrolled materials.
284.6 Recovery Code Management. Recovery codes, break-glass credentials, backup keys, emergency access credentials, and account recovery materials shall be controlled, sealed where appropriate, access-limited, periodically reviewed, and protected against loss or misuse. Recovery materials shall not be stored in ordinary documents, unmanaged email, unapproved password stores, uncontrolled notebooks, or personal systems. Use of recovery codes shall be logged and reviewed after the event.
284.7 Hardware Security Module or Secure Key Storage Where Appropriate. GCRI Canada may require hardware security modules, secure enclaves, managed key vaults, hardware-backed keys, secure key storage, offline storage, split knowledge, or multi-party controls for high-value signing keys, encryption keys, release keys, public authority data keys, protected knowledge keys, cyber-sensitive systems, infrastructure-sensitive systems, or critical repositories. The required level of protection shall be proportionate to risk.
284.8 Least-Privilege Access. Access to keys, tokens, credentials, secrets, and recovery codes shall follow least-privilege principles. Permissions shall be limited by role, purpose, environment, asset, time, data class, public authority terms, protected knowledge obligations, cyber sensitivity, infrastructure sensitivity, and finance sensitivity. Privileged credential access shall require heightened approval and review.
284.9 Rotation. Keys, tokens, credentials, secrets, and recovery codes shall be rotated periodically or upon role change, project closeout, repository transfer, provider change, suspected compromise, staff offboarding, contractor offboarding, privilege change, incident, or policy trigger. Rotation schedules shall be risk-based and recorded. Rotation shall include updating dependent systems and verifying that obsolete credentials no longer function.
284.10 Revocation. Credentials shall be revoked when no longer required, when access is no longer authorized, when a user or service is offboarded, when a project closes, when a repository is archived, when a model or system is retired, when a provider relationship ends, when a room closes, or when risk requires revocation. Revocation shall be timely and recorded.
284.11 Emergency Revocation. Emergency revocation shall be used when a credential is compromised, suspected compromised, exposed, misused, associated with unauthorized access, associated with unauthorized agent action, involved in a repository incident, used in unsafe publication, or otherwise creates material risk. Emergency revocation may include token invalidation, key rotation, account lock, service suspension, release freeze, access freeze, credential audit, and incident response.
284.12 Compromise Response. Credential compromise response shall include containment, revocation, rotation, log review, affected system review, affected data review, repository review, release review, public authority data review, protected knowledge review, cyber review, infrastructure review, finance-sensitive review, notification review, correction, and post-incident review. Compromise response shall preserve evidence and maintain confidentiality.
284.13 Separation of Duties. Credential management shall preserve separation of duties where risk requires it. Persons who develop code may not have unilateral release key authority; persons who approve release may not be sole custodians of signing keys; persons with access to restricted data may not have uncontrolled export authority; and persons with emergency credentials shall be subject to after-action review. Separation of duties shall reduce insider risk, conflict risk, and accidental misuse.
284.14 No Shared Personal Credentials for Institutional Systems. Shared personal credentials for institutional systems are prohibited unless a narrowly tailored emergency procedure, service account structure, or transition process is approved and recorded. Institutional access shall use named accounts, approved service accounts, role-based permissions, and auditable access wherever feasible. Shared credential use shall not be used to avoid accountability.
284.15 Credential Offboarding. Credential offboarding shall occur when employees, contractors, fellows, volunteers, contributors, maintainers, advisors, public authority participants, provider personnel, sponsor personnel, partner personnel, or other authorized users no longer require access. Offboarding shall include account removal, token revocation, key rotation where needed, repository access removal, room access closure, device return where applicable, confidentiality reminders, and access log review where appropriate.
284.16 Key, Token, Credential, Secret, and Recovery Code Records. GCRI Canada shall maintain key, token, credential, secret, and recovery code records, including key inventories, signing key records, API token records, service credential records, secrets-management records, recovery code records, secure key storage records, access records, least-privilege records, rotation records, revocation records, emergency revocation records, compromise response records, separation-of-duties records, shared-credential exception records, credential offboarding records, incidents, corrections, and archives.
Section 285. Zero-Trust and Least-Privilege Controls for Core Technical Assets
285.1 Zero-Trust Purpose. GCRI Canada shall maintain zero-trust and least-privilege controls for core technical assets, repositories, software, datasets, models, dashboards, maps, APIs, schema registries, artifact registries, build pipelines, release systems, controlled rooms, data rooms, compute environments, AI systems, retrieval systems, public authority materials, protected knowledge, cyber-sensitive materials, infrastructure-sensitive materials, finance-sensitive materials, and public-safe outputs. Zero-trust controls shall assume that access must be verified, scoped, logged, reviewed, and revoked when no longer justified.
285.2 Least-Privilege Principle. Each user, service account, model, agent, tool, workflow, repository, environment, or integration shall receive only the minimum access necessary for the approved purpose and period. Least privilege shall apply to read, write, approve, merge, release, administer, export, download, delete, publish, train, embed, retrieve, query, compute, and transfer permissions. Technical convenience shall not justify excessive access.
285.3 Role-Based Access Control. Role-based access control may be used to assign permissions based on approved roles, including Board, officer, employee, contractor, fellow, maintainer, contributor, reviewer, public authority participant, safeguards reviewer, data steward, AI steward, cyber steward, repository custodian, asset owner, council participant, partner, provider, sponsor, or observer. Roles shall be defined, limited, reviewed, and separated to prevent overbroad access and role confusion.
285.4 Attribute-Based Access Control Where Appropriate. Attribute-based access control may be used where access must depend on data class, jurisdiction, public authority terms, protected knowledge status, project, room, clearance, conflict status, training completion, device posture, location, time, sensitivity, export-control status, sanctions status, or other relevant attributes. Attribute rules shall be recorded and tested where material.
285.5 Just-in-Time Access Where Appropriate. Just-in-time access may be used for sensitive repositories, controlled rooms, data rooms, production systems, restricted datasets, public authority materials, protected knowledge, cyber-sensitive materials, infrastructure-sensitive materials, finance-sensitive records, signing keys, and release systems. Just-in-time access shall be time-bound, purpose-bound, approved, logged, and revoked automatically or promptly after use.
285.6 Time-Limited Access Where Appropriate. Access may be granted for limited periods tied to project duration, review duration, incident response, release window, controlled-room session, public authority engagement, fellowship period, contractor engagement, or emergency access. Expired access shall be revoked or reapproved through recorded process. Time-limited access shall not become indefinite by neglect.
285.7 Multi-Factor Authentication. Multi-factor authentication shall be required for systems and roles where risk requires it, including repositories, cloud systems, data rooms, controlled rooms, secrets-management systems, release systems, package channels, administrative accounts, public authority data systems, protected knowledge systems, finance-sensitive rooms, cyber-sensitive environments, and infrastructure-sensitive environments. Exceptions shall be recorded and risk-reviewed.
285.8 Device Security. Device security requirements may apply to devices accessing core technical assets, restricted data, public authority materials, protected knowledge, cyber-sensitive materials, infrastructure-sensitive materials, finance-sensitive materials, or controlled rooms. Requirements may include encryption, operating system updates, endpoint protection, screen lock, secure storage, remote wipe, no local download rules, approved browsers, and prohibition on unmanaged devices where appropriate.
285.9 Network Segmentation. Network segmentation may be used to separate public environments, development environments, staging environments, production environments, research environments, controlled rooms, data rooms, sovereign compute environments, cyber-sensitive environments, infrastructure-sensitive environments, and public authority environments. Segmentation shall reduce lateral movement, data leakage, unauthorized access, and cross-environment contamination.
285.10 Environment Segmentation. Environment segmentation shall distinguish production, staging, development, research, controlled-room, data-room, public-safe, sandbox, incident-response, and archival environments. Data, credentials, logs, models, outputs, and public authority materials shall not move between environments except through approved transfer, classification, and review processes.
285.11 Production, Staging, Development, Research, Controlled-Room, and Public Environments Separation. Production, staging, development, research, controlled-room, and public environments shall be separated according to risk. Production systems shall not use uncontrolled test data; development systems shall not contain restricted public authority data unless approved; public environments shall not access controlled annexes; controlled rooms shall not export unrestricted outputs; and research environments shall not bypass data rights, AI-use, cyber, privacy, export-control, or safeguards rules.
285.12 Privileged Access Review. Privileged access shall be reviewed periodically and when triggered by role change, incident, repository transfer, asset release, public authority engagement, protected knowledge concern, cyber incident, infrastructure incident, finance-boundary issue, offboarding, or change in risk. Privileged access review shall assess need, scope, conflict status, activity logs, credential use, and revocation requirements.
285.13 Access Logs. Access logs shall be maintained for core technical assets according to risk. Logs may identify user, service account, model, agent, time, action, source, target, room, repository, download, export, query, retrieval, write, delete, release, credential use, administrative action, and failed access. Access logs shall be classified, protected, retained, reviewed, and used for incident response.
285.14 Periodic Access Certification. GCRI Canada may require periodic access certification in which asset owners, custodians, officers, or responsible managers confirm that access remains appropriate. Certification shall identify users, roles, permissions, exceptions, conflicts, dormant accounts, excessive privileges, and revocation actions. Certification shall be recorded and deficiencies corrected.
285.15 Emergency Access and Break-Glass Controls. Emergency access or break-glass controls may be used where urgent action is required to protect systems, records, people, public authority materials, protected knowledge, cyber-sensitive systems, infrastructure-sensitive systems, or institutional continuity. Emergency access shall be limited, logged, reviewed after use, revoked promptly, and subject to correction where misused. Emergency access shall not authorize public authority action, emergency command, public warning, finance execution, procurement action, or certification activity.
285.16 Access Revocation. Access shall be revoked when no longer justified, including upon offboarding, role change, project completion, contract end, fellowship end, repository transfer, data room closure, public authority term expiration, protected knowledge restriction, incident, conflict, breach, model suspension, asset retirement, or policy trigger. Revocation shall include accounts, tokens, credentials, rooms, repositories, models, dashboards, cloud systems, package channels, and local copies where feasible.
285.17 Zero-Trust and Least-Privilege Records. GCRI Canada shall maintain zero-trust and least-privilege records, including access policies, role definitions, attribute rules, just-in-time access records, time-limited access records, MFA records, device security records, network segmentation records, environment segmentation records, privileged access reviews, access logs, access certifications, emergency access records, break-glass records, access revocation records, exceptions, incidents, corrections, and archives.
Section 286. Secure Release, Provenance, Supply-Chain Assurance, SBOM, Signing, Reproducible Builds, Vulnerability Clocks, and Rollback
286.1 Secure Release Purpose. GCRI Canada shall maintain secure release controls for public-good software, internal software, restricted software, schemas, APIs, SDKs, dashboards, maps, model artifacts, datasets, technical baselines, reference implementations, public-safe publications, controlled annexes, package channels, artifact registries, schema registries, and other material technical assets. Secure release controls shall preserve provenance, integrity, supply-chain assurance, licensing compliance, public-safe status, security posture, dependency transparency, correctionability, and trust in official releases.
286.2 Release Authorization. Material releases shall require authorization by an asset owner, repository owner, officer, committee, or other competent authority according to risk and policy. Authorization shall confirm release purpose, version, status, license, classification, public-safe status, security review, dependency review, license review, public authority review where applicable, protected knowledge review where applicable, finance-boundary review where applicable, certification-boundary review where applicable, procurement-boundary review where applicable, export-control review where applicable, and correction path.
286.3 Release Candidate Review. Release candidates shall be reviewed before release where risk requires it. Review may include build verification, tests, code review, dependency review, vulnerability scan, SBOM review, license review, documentation review, public-safe language review, accessibility review, model evaluation review, dashboard review, map review, public authority boundary review, safeguards review, finance-boundary review, certification-boundary review, procurement-boundary review, and rollback readiness.
286.4 Provenance Record. Each material release shall have a provenance record identifying source repository, commit or hash, branch, tag, build environment, build time, builder, workflow, dependencies, artifacts, signing status, license, SBOM where available, release approver, public-safe status, and archive location. Provenance records shall support auditability, supply-chain review, vulnerability response, and correction.
286.5 Build Reproducibility Where Appropriate. Build reproducibility shall be pursued where appropriate and feasible for public-good software, restricted software, packages, containers, schemas, reference implementations, technical baselines, and other assets requiring high integrity. Where reproducible builds are not feasible due to environment, dependency, proprietary, security, public authority, protected knowledge, or operational constraints, limitations shall be recorded.
286.6 Artifact Signing. Release artifacts may be signed where integrity, authenticity, public trust, supply-chain assurance, package distribution, public authority use, or technical baseline reliance requires it. Artifact signing shall use approved keys, signing procedures, access controls, logs, and revocation paths. Signing shall indicate release integrity but shall not imply certification, warranty, public authority approval, finance-readiness, or procurement approval.
286.7 Package Signing. Packages released through package channels may be signed where appropriate. Package signing shall identify the releasing authority, package version, build provenance, signing key, release date, and revocation path. Package signing controls shall include key protection, rotation, compromise response, and correction notices for compromised or withdrawn packages.
286.8 SBOM Requirement Where Appropriate. A software bill of materials may be required for material software, public-good software, restricted software, APIs, SDKs, dashboards, containers, reference implementations, and tools where dependency transparency, vulnerability management, public authority use, or supply-chain assurance requires it. SBOMs shall identify components, versions, licenses, suppliers, known vulnerabilities where appropriate, and dependency status. SBOMs may be public-safe or controlled depending on risk.
286.9 Dependency Attestation Where Appropriate. Dependency attestation may be required to document the origin, version, integrity, license, vulnerability status, and trust status of dependencies used in material releases. Attestations may be automated or manual and shall support vulnerability response, license compliance, export-control review, public-safe publication, and correctionability.
286.10 Supply-Chain Assurance. Supply-chain assurance shall address risks arising from third-party libraries, package managers, containers, build systems, CI / CD workflows, model providers, cloud providers, data providers, AI providers, geospatial providers, dashboard frameworks, repository actions, signing keys, maintainers, contributors, and release channels. Assurance controls may include review, pinning, hashing, signing, lockfiles, dependency scanning, provenance records, SBOMs, restricted maintainers, and incident response.
286.11 Vulnerability Disclosure Review. Before releasing or publicly disclosing vulnerabilities, security findings, dependency risks, cyber-sensitive methods, infrastructure-sensitive details, or remediation notes, GCRI Canada shall conduct vulnerability disclosure review. Review shall determine whether disclosure should be public, public-safe, coordinated, delayed, controlled, restricted, or withheld. Disclosure shall not expose exploit details unnecessarily or create unsafe public use.
286.12 Vulnerability Remediation Clocks. Vulnerability remediation clocks may be set based on severity, exploitability, exposure, affected assets, public authority use, protected knowledge, data sensitivity, cyber sensitivity, infrastructure sensitivity, finance sensitivity, public-safe risk, dependency ownership, availability of mitigation, and release constraints. Remediation clocks shall be tracked, escalated where missed, and closed with evidence of remediation or risk treatment.
286.13 Emergency Patch Release. Emergency patch releases may be authorized where urgent correction is required for vulnerability, data leakage, public-safe failure, dependency compromise, repository compromise, model issue, dashboard issue, public authority issue, protected knowledge issue, finance-boundary issue, certification-boundary issue, procurement issue, or Nexus interface issue. Emergency releases shall preserve provenance, approval, testing to the extent feasible, release notes, rollback path, and post-release review.
286.14 Rollback Plan. Material releases shall include rollback plans where release failure could affect users, data integrity, public-safe outputs, public authority materials, protected knowledge, cyber security, infrastructure-sensitive systems, finance-boundary materials, or Nexus interfaces. Rollback plans shall identify prior version, rollback authority, rollback conditions, data migration issues, communication, known limitations, and correction path.
286.15 Deprecation Plan. Deprecation plans shall be prepared where an asset, version, API, schema, model, dashboard, package, or baseline will be phased out. Deprecation plans shall identify reason, timeline, replacement, affected users, migration path, public-safe notice, controlled notice, security implications, dependency implications, public authority implications, and archival.
286.16 Public-Safe Release Review. Public releases shall undergo public-safe release review to ensure they do not disclose protected knowledge, personal information, public authority-sensitive materials, cyber-sensitive details, infrastructure-sensitive details, finance-sensitive materials, confidential information, export-controlled technology, sanctions-sensitive materials, unsafe operational detail, or unsupported claims. Public-safe release shall include limitations and correction path.
286.17 Controlled Release Review. Controlled releases shall undergo review for intended recipients, access class, room status, no-download status, confidentiality, data rights, public authority terms, protected knowledge, cyber sensitivity, infrastructure sensitivity, finance sensitivity, export-control rules, redistribution limits, AI-use restrictions, and closeout. Controlled release shall not be redistributed or publicized without additional review.
286.18 Secure Release Records. GCRI Canada shall maintain secure release records, including release authorizations, release candidate reviews, provenance records, reproducibility records, artifact signing records, package signing records, SBOMs, dependency attestations, supply-chain assurance records, vulnerability disclosure reviews, vulnerability remediation clocks, emergency patch records, rollback plans, deprecation plans, public-safe release reviews, controlled release reviews, correction records, takedown records, supersession records, withdrawal records, and archives.
Section 287. IP Records, Licenses, Invention Disclosures, Contribution Records, Release Records, Restrictions, Permissions, Takedowns, and Corrections
287.1 IP Record Requirement. GCRI Canada shall maintain IP records for material intellectual property, technical assets, public-good software, datasets, schemas, APIs, SDKs, dashboards, maps, data dictionaries, ontology files, model cards, dataset cards, system cards, benchmark cards, reference architectures, profiles, test harnesses, gold vectors, negative tests, technical baselines, research outputs, public-safe publications, controlled annexes, inventions, patents, defensive publications, contributed works, sponsored works, partner works, open-source components, restricted assets, and derivative works. IP records shall preserve ownership, rights, permissions, restrictions, release status, licensing, correctionability, and institutional continuity.
287.2 Chain-of-Title Records. GCRI Canada shall maintain chain-of-title records sufficient to determine ownership or rights to use, modify, publish, restrict, license, sublicense where appropriate, correct, supersede, retire, and archive material assets. Chain-of-title records may include employment agreements, contractor agreements, consultant agreements, contributor agreements, contributor license agreements, assignments, moral rights waivers or consents, patent assignments, invention disclosures, university agreements, laboratory agreements, sponsor agreements, donor terms, grant terms, public authority terms, partner agreements, open-source licenses, data licenses, model licenses, and rights clearances.
287.3 License Records. License records shall identify licenses granted by GCRI Canada, licenses received by GCRI Canada, open-source licenses, open data licenses, research licenses, standards licenses, public-good licenses, restricted licenses, controlled access licenses, non-commercial licenses, permissive licenses, copyleft licenses, dual licenses, patent licenses, data licenses, model licenses, API terms, repository terms, and public authority terms. License records shall include license version, scope, territory, term, rights granted, restrictions, attribution, patent terms, sublicensing rights, termination, correction obligations, and compliance obligations.
287.4 Contributor Records. Contributor records shall identify contributors, contribution dates, capacity, contribution type, contributor terms, contributor license agreements, assignments, license grants, patent grants, moral rights treatment, originality representations, third-party rights disclosures, open-source disclosures, data rights disclosures, AI-use disclosures, confidentiality commitments, security commitments, vulnerability disclosures, conflict disclosures, review status, acceptance status, rejection, quarantine, modification, withdrawal, takedown, and correction history.
287.5 Invention Disclosure Records. Invention disclosure records shall identify inventor, invention title, description, date, contributors, funding source, sponsor involvement, employer or university rights, public authority involvement, protected knowledge involvement, data or model dependencies, open-source dependencies, prior publications, defensive publication options, patentability review, public-benefit rationale, anti-enclosure review, export-control review, filing decision, assignment, and licensing strategy.
287.6 Patent and Defensive Publication Records. Patent and defensive publication records shall include patent applications, issued patents, abandoned applications, provisional applications, defensive publications, non-assertion commitments, patent pledges, royalty-free licenses, reasonable licenses, standards-essential reviews, patent encumbrances, patent disputes, patent enforcement decisions, anti-enclosure controls, sponsor influence reviews, provider influence reviews, public-benefit rationale, corrections, withdrawals, and archives.
287.7 Third-Party Rights Records. Third-party rights records shall identify third-party copyrights, patents, trade secrets, database rights, moral rights, licenses, proprietary restrictions, open-source obligations, data rights, model rights, public authority terms, protected knowledge obligations, confidentiality restrictions, provider terms, sponsor terms, university rights, employer rights, funder rights, and partner rights affecting GCRI Canada assets. Assets with unresolved third-party rights shall be restricted, redesigned, removed, quarantined, or escalated.
287.8 Open-Source Compliance Records. Open-source compliance records shall identify open-source components, licenses, notices, attribution, source disclosure obligations, copyleft obligations, patent terms, modification notices, dependency versions, vulnerability status, compatibility review, redistribution obligations, public-safe status, and remediation actions. Open-source compliance records shall be maintained for assets used internally and assets released externally where relevant.
287.9 Data and Model Rights Records. Data and model rights records shall identify dataset rights, derived data rights, synthetic data rights, embedding rights, vector store rights, prompt rights, fine-tuned model rights, model weight rights, adapter rights, evaluation set rights, benchmark rights, test vector rights, gold vector rights, negative test rights, AI-use restrictions, training restrictions, retrieval restrictions, public authority restrictions, protected knowledge restrictions, personal data restrictions, retention, deletion, and correction rights.
287.10 Release Records. Release records shall identify asset released, version, release date, release authority, repository, package channel, artifact registry, license, public-safe status, classification, security review, dependency review, license review, SBOM where applicable, provenance record, release notes, known issues, limitations, no-certification language, no-finance-readiness language, no-procurement language, no-public-authority-approval language, correction path, and archive.
287.11 Restriction Records. Restriction records shall identify assets restricted due to data rights, protected knowledge, public authority terms, privacy, cyber sensitivity, infrastructure sensitivity, finance sensitivity, commercial sensitivity, export-control rules, sanctions rules, licensing restrictions, donor restrictions, grant restrictions, public-safe risk, security risk, or unresolved ownership. Restriction records shall identify permitted users, permitted uses, prohibited uses, access controls, review date, and correction path.
287.12 Permission Records. Permission records shall identify permissions granted to or by GCRI Canada, including use permissions, publication permissions, data permissions, AI-use permissions, model-training permissions, embedding permissions, retrieval permissions, licensing permissions, access permissions, public authority reference permissions, protected knowledge permissions, translation permissions, modification permissions, redistribution permissions, and sublicensing permissions. Permissions shall be scoped, recorded, revocable where applicable, and tied to conditions.
287.13 Takedown Records. Takedown records shall identify requests or actions to remove, restrict, correct, suspend, de-index, unpublish, disable, revoke, or withdraw assets, releases, repositories, public-safe outputs, dashboards, maps, datasets, models, packages, documentation, compatibility claims, Nexus-compatible claims, public authority misdescriptions, provider preference claims, finance overclaims, certification overclaims, procurement implications, protected knowledge exposure, cyber-sensitive disclosures, or infringing materials. Takedowns shall preserve evidence and legal records where appropriate.
287.14 Correction Records. Correction records shall identify corrections to IP records, license records, contributor records, ownership records, release records, data rights, model rights, public-safe outputs, documentation, technical baselines, repositories, software, datasets, dashboards, maps, compatibility claims, public authority references, protected knowledge treatment, finance-boundary language, certification-boundary language, procurement-boundary language, provider-neutrality language, and sponsor references. Correction records shall include authority, reason, affected materials, notice, dependency review, and closeout.
287.15 Supersession Records. Supersession records shall identify assets, licenses, models, datasets, schemas, APIs, technical baselines, documentation, public-safe outputs, repositories, methods, or records replaced by later versions. Supersession records shall state effective date, successor asset, prior version, reliance rule, migration note, affected outputs, dependency review, notice requirements, and archive location.
287.16 Deprecation Records. Deprecation records shall identify assets, versions, APIs, schemas, models, datasets, software, dashboards, maps, technical baselines, documentation, or methods that should no longer be used for new work. Deprecation records shall include reason, effective date, sunset date where any, permitted interim use, prohibited use, replacement guidance, notice, and correction path.
287.17 Retirement Records. Retirement records shall identify assets permanently removed from active use due to obsolescence, legal restriction, security risk, license issue, data-rights issue, protected knowledge issue, public authority restriction, unsafe public use, dependency failure, unsupported status, sponsor or provider conflict, finance-boundary risk, certification-boundary risk, procurement-boundary risk, or inconsistency with public-benefit purpose. Retirement records shall include access changes, archival status, reliance limits, and notice.
287.18 Archive Records. Archive records shall preserve material IP, licensing, contribution, release, restriction, permission, takedown, correction, supersession, deprecation, and retirement records according to law, policy, public authority terms, protected knowledge obligations, privacy, cyber security, research integrity, auditability, correctionability, and institutional memory. Archive records shall identify operative status, access restrictions, classification, retention, sealing, deletion where lawful, and historical reliance limits.
Last updated
Was this helpful?