X. SOFTWARE
10.1 Public-Good Technical Asset Purpose
10.1.1 Public-Good Technical Assets as Constitutional Mission Assets of GCRI Canada. 10.1.1(a) GCRI Canada may steward public-good technical assets as constitutional mission assets of GCRI Canada, held, developed, maintained, versioned, reviewed, secured, published where appropriate, restricted where required, corrected where necessary, and retired where appropriate in furtherance of GCRI Canada’s non-share, non-distributing, non-executing, public-benefit, evidence, methods, observability, ontology, public-good R&D, public-good software, open technical baseline, public authority learning, public-safe publication, validity-by-record, and correctionability purposes.
10.1.1(b) Public-good technical assets may include methods, frameworks, taxonomies, controlled vocabularies, schemas, data dictionaries, ontologies, reference architectures, software, code repositories, documentation, APIs, dashboards, maps, technical baselines, evidence templates, decision-pack templates, public-safe publication templates, model cards, dataset cards, system cards, benchmark cards, evaluation harnesses, compute workload records, verifiable compute methods, verifiable intelligence methods, Truth Engine methods, Observatory methods, Risk Management methods, Rails literacy methods, Grid input methods, Academy learning methods, Docket routing methods, proof receipt methods, correction methods, assurance methods, and other technical artifacts maintained for public-good use.
10.1.1(c) Public-good technical assets shall be treated as mission assets because their value lies in preserving public-good technical capacity, evidence integrity, interoperability, transparency where appropriate, reproducibility where appropriate, public-safe explanation, role separation, correctionability, and institutional trust, and not because they constitute commercial inventory, proprietary product lines, investible platforms, execution tools, public authority systems, vendor offerings, market infrastructure, or financial assets by default.
10.1.1(d) GCRI Canada shall steward public-good technical assets for public-benefit use across the Nexus public-good stack, including support for The Global Centre for Risk and Innovation (GCRI), The Global Risks Forum (GRF), The Global Risks Alliance (GRA), Nexus Standards / Protocol Authority, Nexus Network, Nexus Observatory, Nexus Risk Management, Nexus Rails, Nexus Grid, Nexus Academy, Regional Nexus Consortiums, National Nexus Consortiums, National Companies, Project SPVs, public authorities, universities, communities, hosts, providers, sponsors, operators, and other interfaces only within recorded role boundaries.
10.1.1(e) A public-good technical asset shall not create certification, recognition, finance-readiness, public authority decision, regulatory finding, procurement approval, public finance approval, provider endorsement, sponsor approval, host approval, operator instruction, protocol effect, professional certification, operational clearance, legal status, market authority, infrastructure operation, deployment approval, public warning, emergency command, or execution consequence by default.
10.1.1(f) Public-good technical asset stewardship shall preserve legal separateness and role separation among GCRI Canada, GCRI US, GRF, GRA, Nexus Standards / Protocol Authority, Nexus entities, public authorities, National Companies, Project SPVs, providers, sponsors, hosts, operators, universities, communities, capital readers, procurement actors, and execution vehicles.
10.1.1(g) Where public-good technical assets are referenced externally, GCRI Canada shall preserve asset status, version status, public-safe status, permitted use, prohibited use, boundary language, dependency limits, correction path, supersession path, withdrawal path, archive status, and any restrictions arising from law, privacy, cybersecurity, sovereign data, export controls, sanctions, IP rights, protected knowledge, community safeguards, or public authority conditions.
10.1.1(h) The controlling rule shall be that public-good technical assets are constitutional mission assets held for evidence integrity, public-good interoperability, safeguards, and correctionability, not commercial inventory or execution authority.
10.1.2 Public-Good Technical Assets as Evidence, Methods, Observability, Ontology, Interoperability, Verifiable Compute, Verifiable Intelligence, Public-Safe Publication, and Correction Infrastructure. 10.1.2(a) Public-good technical assets may serve as evidence infrastructure, methods infrastructure, observability infrastructure, ontology infrastructure, interoperability infrastructure, verifiable compute infrastructure, verifiable intelligence infrastructure, public-safe publication infrastructure, and correction infrastructure within GCRI Canada’s non-executing public-benefit role.
10.1.2(b) As evidence infrastructure, public-good technical assets may support source lineage, evidence classes, source comparison, confidence treatment, uncertainty treatment, limitation treatment, evidence packs, decision packs, evidence registers, correction records, dependency notices, assurance records, and validity-by-record discipline.
10.1.2(c) As methods infrastructure, public-good technical assets may support controlled methods for Truth Engine outputs, Observatory outputs, Risk Management outputs, Rails inputs, Grid inputs, Docket inputs, Academy materials, Nexus Universe materials, public authority learning, community safeguards, provider neutrality, sponsor non-control, host readiness, incident handling, and public-safe publication.
10.1.2(d) As observability infrastructure, public-good technical assets may support Nodes, Hubs, Clusters, Hotspots, Regional Observatory Clusters, National Dense Nexus Cores, sensors, AI-RAN systems, O-RAN systems, private wireless systems, DePIN systems, cyber telemetry, geospatial layers, digital twins, dashboards, maps, degraded-mode awareness, host readiness evidence, and public-safe outputs.
10.1.2(e) As ontology and interoperability infrastructure, public-good technical assets may support controlled vocabulary, common definitions, schemas, data dictionaries, reference data models, semantic mappings, API conventions, data-class conventions, evidence-class conventions, output-class conventions, interface terms, public-safe language, boundary language, correction language, and cross-institutional interpretability.
10.1.2(f) As verifiable compute and verifiable intelligence infrastructure, public-good technical assets may support compute workload records, compute environment records, model records, dataset records, inference records, proof receipts, hashing, signing, timestamping, tamper-evidence, reproducibility notes, auditability, human review, public-safe AI use, and correction of compute- or AI-supported outputs.
10.1.2(g) As public-safe publication and correction infrastructure, public-good technical assets may support public-safe summaries, controlled annexes, restricted annexes, dashboards, maps, APIs, datasets, reports, technical notes, update status, timestamps, versions, confidence, uncertainty, limitations, boundary language, misuse monitoring, correction, supersession, withdrawal, retraction, archive, and re-issue.
10.1.2(h) Public-good technical assets shall not be treated as self-validating merely because they are technical, reusable, open, public-good, widely adopted, sponsor-supported, provider-contributed, public authority-referenced, academically reviewed, software-based, cryptographically anchored, dashboarded, standardized, or included in a Nexus interface. Each material use shall remain subject to purpose, context, version, source, review, limitation, public-safe status, and correction path.
10.1.2(i) The controlling rule shall be that public-good technical assets provide infrastructure for evidence and correction, not automatic truth, authority, approval, finance, procurement, certification, recognition, protocol effect, or execution.
10.1.3 Public-Good Technical Assets as Support for Nexus Public-Good Stack Interoperability. 10.1.3(a) GCRI Canada may steward public-good technical assets to support interoperability across the Nexus public-good stack by creating common methods, common vocabularies, common records, common schemas, common evidence classes, common data classes, common output classes, common public-safe publication patterns, common correction patterns, common interface terms, common assurance patterns, and common boundary language.
10.1.3(b) Public-good technical assets may support interoperability among GCRI Canada, GCRI US, GRF, GRA, Nexus Standards / Protocol Authority, Nexus Network, Nexus Universe, Nexus Observatory, Nexus Risk Management, Nexus Rails, Nexus Grid, Nexus Academy, Regional Nexus Consortiums, National Nexus Consortiums, National Working Groups, Nexus Competence Cells, National Companies, Project SPVs, public authorities, universities, communities, providers, sponsors, hosts, operators, and capital-reader interfaces, provided that interoperability does not collapse institutional roles.
10.1.3(c) Interoperability support may include APIs, schema mappings, controlled vocabulary mappings, evidence-pack formats, decision-pack formats, register formats, proof receipt formats, public-safe publication templates, model governance templates, dataset governance templates, compute-record templates, dashboard conventions, map conventions, incident-handling templates, assurance templates, correction templates, and interface agreement templates.
10.1.3(d) Public-good technical assets shall support one common rail and role-separated stacks by making evidence, methods, records, safeguards, public-safe outputs, and correction signals interoperable without converting public-good stack assets into enterprise stack execution tools or investible execution assets by implication.
10.1.3(e) Interoperability shall not create shared liability, shared authority, institutional merger, public authority delegation, GRF recognition, GRA finance-readiness, Protocol Authority effect, public procurement effect, provider preference, sponsor control, host approval, operator instruction, National Company action, Project SPV action, or execution consequence unless separately created by the competent actor through its own authority and records.
10.1.3(f) GCRI Canada shall not permit interoperability assets to become hidden control points, proprietary choke points, sponsor-controlled dependencies, provider-controlled dependencies, vendor lock-in mechanisms, public authority confusion points, finance-signaling devices, procurement filters, certification substitutes, recognition substitutes, or protocol substitutes.
10.1.3(g) Where interoperability assets are corrected, superseded, withdrawn, retracted, deprecated, restricted, or archived, GCRI Canada shall issue correction signals or dependency notices to affected Nexus interfaces where appropriate and shall preserve continuing limitations, version history, and prohibited uses.
10.1.3(h) The controlling rule shall be that public-good technical assets may make the Nexus public-good stack interoperable, but interoperability shall not become control, certification, recognition, finance-readiness, public authority action, procurement, protocol effect, or execution.
10.1.4 Public-Good Technical Assets as Distinct From Proprietary Vendor Products, Commercial Platforms, Market Infrastructure, Public Authority Systems, and Enterprise Stack Execution Tools. 10.1.4(a) Public-good technical assets stewarded by GCRI Canada shall be distinguished from proprietary vendor products, commercial platforms, market infrastructure, public authority systems, regulated systems, enterprise stack execution tools, procurement systems, finance systems, insurance systems, rating systems, trading systems, operational systems, emergency command systems, public warning systems, telecommunications systems, infrastructure operating systems, and execution platforms.
10.1.4(b) A public-good technical asset may interface with, reference, test, evaluate, document, compare, route evidence from, or be implemented near vendor products, commercial platforms, public authority systems, enterprise systems, National Company systems, Project SPV systems, provider systems, sponsor-supported systems, host systems, operator systems, or public infrastructure systems without becoming those systems or assuming their authority, liability, operational function, procurement function, finance function, or execution function.
10.1.4(c) GCRI Canada shall not describe public-good technical assets as proprietary products for sale, commercial platforms controlled for market advantage, regulated infrastructure, public authority systems, emergency systems, public warning systems, execution platforms, managed services, procurement platforms, finance platforms, rating products, certification products, recognition products, or provider marketplaces unless a separate lawful structure, authority, and role boundary expressly supports that description.
10.1.4(d) Provider-contributed code, software, equipment, data rooms, dashboards, maps, APIs, compute environments, sensors, AI-RAN systems, DePIN systems, AI tools, cybersecurity tools, or technical services shall not become GCRI Canada public-good technical assets unless accepted, classified, permissioned, recorded, rights-cleared, security-reviewed, public-safe-reviewed where applicable, and bounded against provider preference, sponsor control, IP uncertainty, vendor lock-in, and correction failure.
10.1.4(e) Public authority participation in, review of, data contribution to, or use of public-good technical assets shall not convert such assets into public authority systems, official guidance systems, regulatory systems, public warning systems, emergency command systems, public finance systems, procurement systems, compliance systems, enforcement systems, or public-law systems by implication.
10.1.4(f) Enterprise stack actors, National Companies, Project SPVs, providers, sponsors, hosts, operators, capital readers, insurers, lenders, investors, and procurement actors may use or reference public-good technical assets only within recorded permitted-use boundaries, and such use shall not convert GCRI Canada into an enterprise actor or execution actor.
10.1.4(g) Where a public-good technical asset is misdescribed as a proprietary product, commercial platform, market infrastructure, public authority system, finance tool, procurement tool, certification tool, recognition tool, protocol tool, or execution tool, GCRI Canada shall correct, relabel, restrict, withdraw, reissue, request removal of misleading references, issue clarification where appropriate, and review affected dependencies.
10.1.4(h) The controlling rule shall be that public-good technical assets may be technically powerful, reusable, and interoperable, but their constitutional character remains public-benefit, non-executing, role-separated, and correctionable.
10.1.5 Public-Good Technical Assets as Reviewable, Versioned, Secure, Portable, Reusable, Public-Safe, and Correctionable. 10.1.5(a) Public-good technical assets shall be stewarded, where material, as reviewable, versioned, secure, portable, reusable, public-safe where externally released, and correctionable artifacts, with records sufficient to identify their purpose, source, authority, owner or steward, custodian, version, dependencies, data classes, evidence classes, access classes, handling classes, public-safe status, permitted uses, prohibited uses, review status, assurance status, correction status, supersession status, withdrawal status, retraction status where applicable, archive status, and closeout status.
10.1.5(b) Reviewability shall require that material public-good technical assets can be inspected, challenged, tested where appropriate, compared where appropriate, quality-reviewed, public-safe-reviewed where applicable, security-reviewed, privacy-reviewed, sovereign-data-reviewed where applicable, community-safeguard-reviewed where applicable, public-authority-boundary-reviewed where applicable, provider-neutrality-reviewed, sponsor-non-control-reviewed, and corrected.
10.1.5(c) Versioning shall require that material changes to public-good technical assets be recorded with version identifiers, release dates, change descriptions, dependency effects, public-safe effects, security effects, data effects, interface effects, correction effects, deprecated elements, superseded elements, migration notes where appropriate, and archive treatment.
10.1.5(d) Security shall require that public-good technical assets be protected by proportionate cybersecurity, repository controls, access controls, dependency review, secrets controls, key controls, vulnerability management, patch management, secure configuration, incident handling, and correction controls appropriate to the asset’s sensitivity and use.
10.1.5(e) Portability and reusability shall be pursued where consistent with law, IP rights, privacy, cybersecurity, sovereign data, public authority restrictions, community safeguards, protected knowledge, export controls, sanctions, controlled technology restrictions, public-safe publication controls, and correctionability. Portability shall not be pursued where it would create unsafe transfer, vendor lock-in under another name, uncontrolled reuse, public-safe misuse, or role confusion.
10.1.5(f) Public-safe treatment shall require that externally released public-good technical assets be assessed for unsafe disclosure, hidden dependency exposure, credentials exposure, vulnerability exposure, protected knowledge exposure, public authority confusion, finance overclaim, procurement implication, certification implication, recognition implication, protocol implication, provider preference, sponsor validation, host approval implication, operator instruction implication, and execution implication.
10.1.5(g) Correctionability shall require that material public-good technical assets can be corrected, restricted, superseded, withdrawn, retracted where necessary, deprecated, retired, archived, and accompanied by dependency notices where affected users, interfaces, outputs, or records may rely on prior versions.
10.1.5(h) The controlling rule shall be that a public-good technical asset is not fit for constitutional stewardship unless it can be reviewed, versioned, secured, reused within limits, made public-safe where released, and corrected.
10.1.6 Public-Good Technical Assets as Protected Against Sponsor Control, Provider Capture, Vendor Lock-In, Hidden Dependencies, Standards Capture, Public Authority Confusion, and Finance Overclaim. 10.1.6(a) GCRI Canada shall protect public-good technical assets against sponsor control, provider capture, vendor lock-in, hidden dependencies, standards capture, public authority confusion, finance overclaim, procurement implication, certification implication, recognition implication, protocol overclaim, market capture, and execution drift.
10.1.6(b) Sponsor control shall include any direct or indirect sponsor attempt to control asset purpose, source selection, method design, evidence treatment, reviewer selection, public-safe classification, publication decisions, correction outcomes, interface access, provider selection, host selection, public authority references, community safeguards, GRF inputs, GRA inputs, Protocol Authority inputs, finance-facing use, procurement-facing use, or execution-facing use.
10.1.6(c) Provider capture shall include any direct or indirect provider attempt to make a public-good technical asset dependent on provider-specific tools, formats, systems, APIs, pricing, licensing, data models, dashboards, AI models, compute environments, security tools, sensors, AI-RAN systems, DePIN systems, or proprietary methods in a manner that compromises public-good portability, neutrality, reviewability, correctionability, or competitive neutrality.
10.1.6(d) Vendor lock-in shall include legal, technical, operational, data, interoperability, licensing, repository, API, hosting, cloud, model, compute, dashboard, map, sensor, or support dependencies that prevent GCRI Canada from maintaining, reviewing, migrating, correcting, publishing where appropriate, restricting where required, or retiring public-good technical assets without undue control by a vendor or provider.
10.1.6(e) Hidden dependencies shall include undocumented data dependencies, code dependencies, model dependencies, compute dependencies, licensing dependencies, third-party service dependencies, cloud dependencies, provider dependencies, sponsor dependencies, public authority dependencies, community dependencies, protected knowledge dependencies, security dependencies, and correction dependencies that materially affect asset integrity or use.
10.1.6(f) Standards capture shall include use of public-good technical assets, controlled vocabularies, schemas, APIs, reference architectures, benchmarks, proof formats, dashboards, or technical baselines to confer market advantage, exclude competitors, entrench a provider, encode sponsor preferences, distort Protocol Authority processes, bypass public-good review, or create de facto protocol effect without proper authority.
10.1.6(g) Public authority confusion shall include any use or description of public-good technical assets that implies official guidance, public authority adoption, regulatory determination, public warning, emergency command, procurement approval, funding approval, public finance approval, public-law status, or delegation to GCRI Canada without recorded authority from the competent public authority.
10.1.6(h) Finance overclaim shall include any use or description of public-good technical assets that implies finance-readiness, investment advice, insurance approval, lending approval, underwriting approval, rating, guarantee, bankability, fundability, public finance approval, capital allocation, procurement approval, provider preference, host approval, project approval, or execution instruction by GCRI Canada.
10.1.6(i) Where capture, lock-in, hidden dependency, standards capture, public authority confusion, finance overclaim, procurement implication, provider preference, sponsor control, or correction defect is detected, GCRI Canada shall correct, restrict, relicense where lawful, refactor, replace, document, disclose where appropriate, suspend, supersede, withdraw, reissue, terminate support, change dependencies, update interface terms, issue clarification, and report to the Board or responsible committee where material.
10.1.6(j) The controlling rule shall be that public-good technical assets must remain public-good in function, governance, dependency, language, and correction, not merely in name.
10.1.7 Public-Good Technical Assets as Open Where Appropriate, Restricted Where Required, and Correctable Always. 10.1.7(a) GCRI Canada shall steward public-good technical assets under an open-where-appropriate, restricted-where-required, and correctable-always principle.
10.1.7(b) Openness may be appropriate where public release advances public benefit, transparency, interoperability, reproducibility, education, public-safe understanding, technical baseline access, public authority learning, community learning, provider-neutral adoption, academic review, standards development, or correctionability, and where release does not create unsafe disclosure, IP breach, privacy harm, cybersecurity risk, sovereign data risk, public authority confusion, protected knowledge exposure, community harm, finance overclaim, procurement implication, provider preference, sponsor validation, host approval implication, operator instruction implication, protocol overclaim, or execution implication.
10.1.7(c) Restriction shall be required where an asset contains or exposes personal data, public authority restricted information, health-sensitive information, cyber-sensitive information, infrastructure-sensitive information, finance-sensitive information, commercially sensitive information, community-protected information, Indigenous or protected knowledge, legal-sensitive material, export-control-sensitive material, sanctions-sensitive material, controlled technology, credentials, secrets, keys, tokens, vulnerabilities, sensitive locations, unsafe metadata, or other restricted or harm-enabling information.
10.1.7(d) Restriction may also be required where public release would enable misuse, misinterpretation, public warning implication, public authority confusion, finance overclaim, procurement implication, certification implication, recognition implication, provider preference, sponsor validation, host approval implication, operator instruction implication, market manipulation, security compromise, community harm, or execution drift.
10.1.7(e) Correctability shall apply regardless of openness or restriction. Open assets, restricted assets, internal assets, controlled-room assets, public-safe assets, draft assets, deprecated assets, retired assets, and archived assets shall remain capable of correction, supersession, withdrawal, retraction where appropriate, deprecation, archive marking, dependency notice, and misuse response.
10.1.7(f) Open publication of a public-good technical asset shall not make it unrestricted for all uses. Open assets may remain subject to license terms, attribution requirements, public-safe limits, no-endorsement language, no-certification language, no-recognition language, no-finance language, no-procurement language, no-public-authority language, no-protocol-effect language unless separately created, no-provider-preference language, no-sponsor-control language, no-host-approval language, no-operator-instruction language, no-execution language, and correction paths.
10.1.7(g) Restricted treatment shall not be used to conceal unfavorable evidence, contradiction, uncertainty, sponsor influence, provider influence, public authority ambiguity, finance overclaim, procurement implication, correction obligations, or governance failure. Restrictions shall be used for law, safety, rights, security, sovereignty, protected knowledge, public-safe discipline, and evidence integrity.
10.1.7(h) The controlling rule shall be that public-good technical assets should be as open as public benefit safely permits, as restricted as law and safeguards require, and as correctable as public trust demands.
10.1.8 Public-Good Technical Assets as Public-Benefit Infrastructure Rather Than Commercial Inventory. 10.1.8(a) Public-good technical assets shall be stewarded as public-benefit infrastructure and not as commercial inventory by default. Their primary institutional value shall be measured by evidence integrity, public-good interoperability, methodological reliability, public-safe use, role separation, reuse within safeguards, correctionability, and contribution to public trust, rather than by sale value, exclusivity, market leverage, proprietary control, sponsor value, provider value, finance value, procurement value, or execution value.
10.1.8(b) GCRI Canada may license, share, publish, restrict, contribute, collaborate on, maintain, or retire public-good technical assets in ways consistent with its public-benefit purpose, legal obligations, IP rights, public-safe publication controls, cybersecurity, privacy, sovereign data, community safeguards, protected knowledge, export controls, sanctions, controlled technology restrictions, and role separation.
10.1.8(c) GCRI Canada shall not commercialize public-good technical assets in a manner that converts its constitutional mission assets into proprietary vendor products, sponsor-controlled products, provider-controlled products, market infrastructure, finance products, procurement products, certification products, recognition products, public authority systems, protocol substitutes, or execution tools inconsistent with its non-executing role.
10.1.8(d) Revenue, cost recovery, grant support, sponsor support, service support, in-kind support, licensing arrangements, repository arrangements, hosting arrangements, or implementation support relating to public-good technical assets shall not alter their public-benefit character, create sponsor control, create provider preference, create finance-readiness, create procurement approval, create certification, create recognition, create public authority meaning, create protocol effect, or create execution consequence by default.
10.1.8(e) Public-good technical assets may be used by enterprise stack actors only under boundaries that preserve GCRI Canada’s non-execution role, public-good asset character, public-safe controls, correction rights, permitted-use limits, prohibited-use limits, role separation, dependency transparency, and no-endorsement language.
10.1.8(f) Public-good technical assets shall not be transferred, licensed, assigned, enclosed, encumbered, or made dependent on any actor in a manner that materially impairs GCRI Canada’s ability to review, maintain, secure, publish where appropriate, restrict where required, correct, supersede, withdraw, retire, archive, or preserve the asset for public-benefit purposes.
10.1.8(g) Where asset treatment creates or risks creating commercial inventory treatment, sponsor capture, provider capture, market exclusivity, public authority confusion, finance overclaim, procurement implication, certification implication, recognition implication, protocol implication, or execution drift, GCRI Canada shall correct the treatment, revise the agreement, restrict use, reclassify the asset, issue clarification, or escalate to the Board or responsible committee where material.
10.1.8(h) The controlling rule shall be that public-good technical assets may have economic cost and operational value, but their constitutional identity is public-benefit infrastructure, not inventory for status, control, finance, procurement, or execution.
10.1.9 Public-Good Technical Assets as Subject to Law, Privacy, Cybersecurity, Sovereign Data, Export Controls, Sanctions, IP Rights, Protected Knowledge, Community Safeguards, and Public-Safe Publication Controls. 10.1.9(a) Public-good technical assets shall be subject to applicable law, legal capacity limits, contractual obligations, intellectual property rights, moral rights where applicable, open-source licenses, data licenses, confidentiality obligations, privacy requirements, cybersecurity requirements, sovereign data requirements, cross-border transfer limits, export controls, sanctions, controlled technology restrictions, public authority restrictions, community safeguards, Indigenous safeguards where applicable, protected knowledge safeguards, accessibility obligations, language and translation controls where applicable, and public-safe publication controls.
10.1.9(b) Asset records shall identify, where material, asset title or identifier, asset class, source, owner where known, steward, custodian, author or contributor where appropriate, license, IP status, third-party rights, open-source obligations, patent sensitivity, trade secret sensitivity, data rights, privacy status, cybersecurity status, sovereign data status, public authority status, community-protected status, Indigenous or protected knowledge status, export-control sensitivity, sanctions sensitivity, controlled-technology sensitivity, access class, handling class, public-safe status, permitted uses, prohibited uses, publication limits, correction path, and closeout obligations.
10.1.9(c) Public-good technical assets containing code, models, datasets, schemas, benchmark materials, geospatial layers, dashboards, APIs, documentation, images, maps, training materials, or public-safe summaries shall not be published, shared, reused, embedded, retrieved, trained on, vendor-processed, exported, transferred, or routed unless rights, permissions, classifications, security, privacy, sovereignty, public-safe status, and correction path have been reviewed proportionate to risk.
10.1.9(d) Protected knowledge, community-protected data, Indigenous knowledge where applicable, local knowledge, territorial knowledge, environmental knowledge, cultural site information, sensitive site information, vulnerable community information, and protected knowledge-derived methods shall not be converted into technical assets, schemas, datasets, maps, dashboards, model inputs, embeddings, training data, public-safe summaries, or reusable templates without recorded safeguards, permissions where applicable, public-safe review, and correction path.
10.1.9(e) Public-good technical assets involving controlled technology, cybersecurity tooling, dual-use methods, sensitive infrastructure information, AI models, cryptographic tools, sensor systems, AI-RAN systems, DePIN systems, geospatial data, public authority data, or cross-border compute shall be reviewed for export controls, sanctions, controlled technology restrictions, cyber risk, infrastructure risk, sovereign data risk, and public-safe publication risk before release or transfer.
10.1.9(f) IP rights and open-source treatment shall be managed to support public-good reuse while preventing unlawful copying, license breach, proprietary enclosure, sponsor capture, provider capture, hidden dependency, incompatible license contamination, public authority confusion, or correction failure.
10.1.9(g) Where legal, privacy, cybersecurity, sovereign data, export-control, sanctions, IP, protected knowledge, community safeguard, or public-safe publication issues are identified, GCRI Canada shall restrict, correct, reclassify, relicense where lawful, remove, replace, generalize, redact, seal, withdraw, reissue, archive, or refuse use of the affected asset as appropriate.
10.1.9(h) The controlling rule shall be that public-good purpose does not override law, rights, safety, sovereignty, protected knowledge, cybersecurity, or correction duties.
10.1.10 Public-Good Technical Asset Stewardship as Board-Level and Technical-Stewardship Responsibility. 10.1.10(a) Public-good technical asset stewardship shall be a Board-level and technical-stewardship responsibility of GCRI Canada, requiring appropriate governance, delegation, records, oversight, review, cybersecurity, public-safe controls, correction, and reporting proportionate to the materiality, sensitivity, public-good value, dependency importance, and risk of the asset.
10.1.10(b) The Board may establish, authorize, or oversee committees, officers, technical stewards, asset custodians, repository maintainers, data stewards, security stewards, public-safe publication reviewers, correction stewards, assurance reviewers, or other responsible functions for public-good technical asset stewardship, provided that such delegation preserves Board oversight where material and does not create unrecorded authority, sponsor control, provider control, vendor capture, public authority confusion, finance overclaim, procurement implication, or execution drift.
10.1.10(c) Board-level responsibility shall include oversight of material asset policies, asset registers, licensing frameworks, repository governance, open publication rules, restricted asset rules, cybersecurity controls, data governance controls, IP controls, export-control and sanctions controls, protected knowledge controls, community safeguard controls, public authority boundary controls, provider-neutrality controls, sponsor non-control controls, public-safe publication controls, correction systems, assurance cycles, and material incident escalation.
10.1.10(d) Technical-stewardship responsibility shall include day-to-day or delegated responsibility for asset classification, versioning, documentation, dependency tracking, repository hygiene, code review where applicable, security review, data review, public-safe review, rights review, interface review, release management, correction management, deprecation, retirement, archive, and closeout.
10.1.10(e) Material public-good technical assets shall have identified stewardship sufficient to determine who may approve changes, who may approve publication, who may approve restriction, who may approve access, who may approve license treatment, who may approve security controls, who may approve correction, who may approve supersession, who may approve withdrawal, who may approve retirement, and who must report material risks to the Board or responsible committee.
10.1.10(f) Stewardship records shall identify asset steward, custodian, reviewer, approving authority where applicable, version status, review cycle, assurance cycle, access status, publication status, correction status, incident status, dependency status, license status, security status, public-safe status, and escalation path.
10.1.10(g) Where stewardship gaps, unowned assets, orphaned repositories, stale dependencies, undocumented rights, unreviewed releases, uncontrolled forks, unmanaged credentials, unsupported public claims, hidden sponsor influence, provider capture, vendor lock-in, public authority confusion, finance overclaim, procurement implication, public-safe defect, cybersecurity defect, protected knowledge defect, or correction failure is identified, GCRI Canada shall assign stewardship, restrict use, correct records, update controls, retire or archive the asset where appropriate, and report material matters to the Board or responsible committee.
10.1.10(h) Board-level and technical-stewardship records shall not create certification, recognition, finance-readiness, public authority decision, regulatory finding, procurement approval, provider endorsement, sponsor approval, host approval, operator approval, community consent, Indigenous consent, rating, guarantee, public warning, emergency command, protocol effect, professional certification, operational clearance, legal status, market authority, infrastructure operation, deployment approval, or execution consequence by default.
10.1.10(i) The controlling rule shall be that public-good technical assets must have accountable stewardship because assets that are unowned, unreviewed, insecure, unversioned, or uncorrectable cannot serve a public-good constitutional mission.
10.2 Public-Good Technical Asset Classes
10.2.1 Public-Good Software. 10.2.1(a) Public-good software shall mean software, code, scripts, libraries, repositories, packages, modules, tools, reference implementations, utilities, workflow components, automation components, data-processing components, public-safe publication components, evidence-processing components, observability components, ontology components, interoperability components, compute-record components, correction components, dashboard components, API components, and related technical artifacts stewarded by GCRI Canada for public-benefit evidence, methods, observability, ontology, interoperability, verifiable compute, verifiable intelligence, public-safe publication, correction, assurance, learning, and technical-baseline purposes.
10.2.1(b) Public-good software may support the Nexus Truth Engine, Nexus Observatory, Nexus Risk Management, Nexus Rails, Nexus Grid, Nexus Docket, Nexus Academy, Nexus Universe, public authority learning, community safeguard methods, provider-neutral technical review, sponsor non-control discipline, host readiness evidence, Evidence Packs, Decision Packs, public-safe summaries, controlled annexes, restricted annexes, proof receipts, correction signals, assurance records, and public-good technical baselines.
10.2.1(c) Public-good software shall be stewarded as reviewable, versioned, documented where appropriate, secure, dependency-aware, license-aware, portable where appropriate, reproducible where appropriate, public-safe where externally released, restricted where required, and correctionable. Material public-good software shall have records identifying steward, custodian, repository, version, license, dependencies, permitted uses, prohibited uses, public-safe status, security status, data classification implications, release status, correction path, supersession path, retirement path, and archive status.
10.2.1(d) Public-good software shall not be treated as a proprietary vendor product, commercial platform, execution system, regulated system, public authority system, procurement platform, finance platform, rating product, certification tool, recognition tool, emergency command system, public warning system, infrastructure operating system, market infrastructure, or Protocol Authority instrument by default.
10.2.1(e) Public-good software shall not create certification, recognition, finance-readiness, public authority decision, regulatory finding, procurement approval, provider preference, sponsor approval, host approval, operator instruction, protocol effect, professional certification, operational clearance, legal status, market authority, infrastructure operation, public warning, emergency command, deployment approval, or execution consequence by default.
10.2.1(f) Public-good software may be open where appropriate, restricted where required, and correctable always. Release shall be reviewed for license rights, third-party dependencies, credentials, secrets, keys, tokens, vulnerability exposure, personal data, public authority data, cyber-sensitive information, infrastructure-sensitive information, sovereign data, export controls, sanctions, controlled technology, community-protected data, Indigenous or protected knowledge, public-safe publication risk, finance overclaim, procurement implication, provider preference, sponsor validation, and correctionability.
10.2.1(g) Where public-good software is corrected, restricted, superseded, withdrawn, deprecated, retired, forked, re-licensed where lawful, reissued, or archived, GCRI Canada shall update affected repositories, documentation, releases, public-safe outputs, Evidence Packs, Decision Packs, dashboards, APIs, interface records, dependency records, public claims, and correction records as appropriate.
10.2.1(h) The controlling rule shall be that public-good software is software held for public-benefit methods and evidence integrity, not software that certifies, approves, finances, procures, operates, commands, warns, or executes.
10.2.2 Reference Architectures. 10.2.2(a) Reference architectures shall mean structured technical and institutional design artifacts that describe recommended, illustrative, reusable, or interoperable arrangements for systems, components, interfaces, data flows, evidence flows, observability flows, compute flows, governance controls, public-safe controls, correction paths, and role boundaries within the Nexus public-good stack.
10.2.2(b) Reference architectures may address, among other domains, Nodes, Hubs, Clusters, Hotspots, Regional Observatory Clusters, National Dense Nexus Cores, sovereign compute environments, compute-to-data environments, secure enclaves, controlled rooms, data rooms, clean rooms, no-download rooms, AI-RAN systems, O-RAN systems, private wireless systems, DePIN systems, sensor systems, geospatial systems, digital twins, dashboards, APIs, public authority learning interfaces, community safeguard interfaces, provider interfaces, sponsor interfaces, host interfaces, operator interfaces, Evidence Pack flows, Decision Pack flows, correction flows, and assurance flows.
10.2.2(c) Reference architectures shall identify, where material, purpose, scope, assumptions, intended audience, component classes, interface classes, data classes, evidence classes, output classes, access classes, handling classes, public-safe status, cybersecurity controls, privacy controls, sovereign data controls, public authority boundaries, community safeguards, protected knowledge controls, provider-neutrality controls, sponsor non-control controls, host boundaries, operator boundaries, finance boundaries, procurement boundaries, protocol boundaries, correction paths, and version status.
10.2.2(d) A reference architecture shall not be treated as an implementation mandate, procurement specification, public authority design standard, regulatory requirement, certified architecture, recognized architecture, finance-ready architecture, approved deployment model, operational clearance, protocol effect, provider endorsement, sponsor approval, host approval, operator instruction, or execution design by default.
10.2.2(e) Reference architectures may inform competent actors, including public authorities, National Nexus Consortiums, National Companies, Project SPVs, providers, hosts, operators, GRF, GRA, Protocol Authority, Nexus bodies, universities, and communities, but any adoption, procurement, finance, deployment, operational, public authority, or execution decision shall arise only through the competent actor’s own authority, process, records, liability, and governance instruments.
10.2.2(f) Reference architectures shall be reviewed for hidden dependencies, vendor lock-in, provider capture, sponsor control, standards capture, public authority confusion, unsafe public claims, finance overclaim, procurement implication, protected knowledge exposure, cybersecurity risk, data sovereignty risk, and correctionability.
10.2.2(g) Where reference architectures are corrected, superseded, withdrawn, deprecated, retracted where necessary, or archived, GCRI Canada shall update affected technical baselines, profiles, templates, dashboards, Evidence Packs, Decision Packs, public-safe summaries, training materials, interface materials, public claims, and dependency records as appropriate.
10.2.2(h) The controlling rule shall be that reference architectures describe bounded public-good design patterns; they do not approve, certify, procure, finance, operate, regulate, command, warn, deploy, or execute.
10.2.3 Open Technical Baselines. 10.2.3(a) Open technical baselines shall mean public-good technical baseline materials that GCRI Canada may publish or steward to support common understanding, interoperability, evidence discipline, observability, public-safe explanation, technical comparability, and correctionability across the Nexus public-good stack, subject to law, rights, safeguards, public-safe controls, and role boundaries.
10.2.3(b) Open technical baselines may include baseline methods, minimum record expectations, interoperability assumptions, evidence-class conventions, data-class conventions, public-safe publication conventions, controlled vocabulary elements, schema patterns, dashboard conventions, map conventions, API conventions, compute-record conventions, proof receipt conventions, assurance expectations, incident-handling expectations, correction expectations, and public-good software release expectations.
10.2.3(c) Open technical baselines shall be open only to the extent public benefit safely permits. GCRI Canada shall not include restricted data, unsafe technical details, credentials, secrets, keys, tokens, vulnerability details, protected knowledge, sensitive site information, personal data, public authority restricted information, cyber-sensitive information, infrastructure-sensitive information, controlled technology, or other restricted or harm-enabling material in open technical baselines unless lawful, necessary, public-safe, safeguarded, and expressly recorded.
10.2.3(d) Open technical baselines shall include, where material, version status, update status, scope, intended use, non-authority language, non-certification language, non-recognition language, non-finance language, non-procurement language, non-public-authority language, no-provider-endorsement language, no-sponsor-control language, no-host-approval language, no-operator-instruction language, no-protocol-effect language unless separately created, no-execution language, limitations, dependency notes, correction path, and supersession path.
10.2.3(e) Open technical baselines shall not be treated as standards, certification criteria, procurement criteria, finance-readiness criteria, regulatory requirements, public authority guidance, public warning instruments, emergency command instruments, Protocol Authority instruments, provider qualification instruments, host qualification instruments, professional qualification instruments, or execution instructions by default.
10.2.3(f) Where a competent Protocol Authority, public authority, certification body, procurement actor, finance actor, GRF, GRA, National Company, Project SPV, or other actor separately adopts or relies upon an open technical baseline, that reliance shall arise through the competent actor’s own authority and records and shall not be attributed to GCRI Canada by implication.
10.2.3(g) Open technical baselines shall remain correctionable. GCRI Canada shall maintain version history, correction notices, deprecation notices, supersession notices, withdrawal notices, retraction notices where necessary, and archive records proportionate to public reliance and dependency.
10.2.3(h) The controlling rule shall be that open technical baselines create shared public-good reference points, not legal standards, official approvals, finance determinations, procurement filters, certifications, recognitions, protocol effects, or execution authority by default.
10.2.4 Technical Profiles. 10.2.4(a) Technical profiles shall mean structured descriptions of technical characteristics, configuration expectations, evidence requirements, method requirements, interface requirements, operating assumptions, public-safe controls, security controls, data controls, and correction requirements for defined technology domains, asset classes, evidence classes, or interface contexts.
10.2.4(b) Technical profiles may address sensors, AI-RAN systems, O-RAN systems, private wireless systems, DePIN systems, cyber telemetry systems, geospatial systems, digital twins, dashboards, APIs, compute environments, AI systems, retrieval systems, embedding stores, data rooms, clean rooms, controlled rooms, public authority rooms, community rooms, evidence packs, decision packs, public-safe outputs, and related public-good technical assets.
10.2.4(c) Each material technical profile shall identify profile title or identifier, purpose, scope, technology domain, evidence domain, intended users, assumptions, required or recommended records, data classes, evidence classes, output classes, access classes, handling classes, public-safe status, security controls, privacy controls, sovereign data controls, public authority controls, community safeguard controls, protected knowledge controls, provider-neutrality controls, sponsor non-control controls, host-boundary controls, operator-boundary controls, finance-boundary controls, procurement-boundary controls, protocol-boundary controls, review cycle, version, and correction path.
10.2.4(d) Technical profiles shall distinguish mandatory internal GCRI Canada requirements, optional guidance, illustrative examples, recommended public-good practices, controlled-room practices, public-safe practices, restricted practices, and external-use limitations. Ambiguity shall not be interpreted to convert a profile into certification, approval, procurement qualification, finance-readiness, protocol effect, or execution instruction.
10.2.4(e) Technical profiles shall not be used by GCRI Canada to certify products, approve vendors, rank providers, authorize procurement, create finance-readiness, determine public authority compliance, issue public warnings, confer protocol effect, approve deployment, or direct operations by default.
10.2.4(f) Where technical profiles reference provider systems, sponsor-supported systems, host systems, public authority systems, community systems, National Company systems, Project SPV systems, or other external systems, such references shall preserve no-endorsement, no-preference, no-procurement, no-finance, no-certification, no-recognition, no-public-authority, no-protocol-effect unless separately created, no-host-approval, no-operator-instruction, and no-execution language where material.
10.2.4(g) Technical profiles shall be corrected, restricted, superseded, withdrawn, deprecated, retired, or archived where they become outdated, unsafe, legally unsupported, cybersecurity-defective, public-safe-defective, provider-captured, sponsor-influenced, public-authority-confusing, finance-overclaiming, procurement-implying, or correction-defective.
10.2.4(h) The controlling rule shall be that technical profiles describe bounded technical expectations for evidence and interoperability, not certification, procurement, finance, authority, protocol effect, or execution by default.
10.2.5 Interoperability Profiles. 10.2.5(a) Interoperability profiles shall mean technical and semantic profiles that support consistent exchange, mapping, interpretation, routing, validation, correction, and public-safe use of evidence, data, metadata, methods, records, proofs, outputs, dashboards, APIs, and interface materials across role-separated Nexus actors.
10.2.5(b) Interoperability profiles may include data exchange profiles, API profiles, schema profiles, proof receipt profiles, Evidence Pack profiles, Decision Pack profiles, dashboard interoperability profiles, map-layer profiles, compute-record profiles, AI inference-record profiles, public authority interface profiles, community safeguard interface profiles, GRF input profiles, GRA input profiles, Protocol Authority input profiles, Grid input profiles, Docket input profiles, Rails input profiles, Risk Management input profiles, Academy input profiles, and Nexus Universe interface profiles.
10.2.5(c) Each material interoperability profile shall identify source system classes, receiving system classes, permitted exchange purposes, prohibited exchange purposes, data classes, evidence classes, output classes, access classes, handling classes, public-safe status, required metadata, versioning, identity treatment, source-lineage treatment, confidence treatment, uncertainty treatment, limitation treatment, rights treatment, privacy treatment, cybersecurity treatment, sovereign data treatment, public authority treatment, community safeguard treatment, protected knowledge treatment, correction treatment, and dependency treatment.
10.2.5(d) Interoperability profiles shall preserve role separation. A profile enabling exchange between GCRI Canada and GRF shall not create GRF recognition by GCRI Canada; a profile enabling exchange with GRA shall not create finance-readiness by GCRI Canada; a profile enabling exchange with Protocol Authority shall not create protocol effect by GCRI Canada; a profile enabling exchange with public authorities shall not create public authority action by GCRI Canada; and a profile enabling exchange with National Companies, Project SPVs, providers, hosts, operators, capital readers, or procurement actors shall not create execution consequence by GCRI Canada.
10.2.5(e) Interoperability profiles shall not create shared liability, institutional merger, delegated authority, approval, certification, recognition, finance-readiness, procurement approval, public authority decision, provider endorsement, sponsor approval, host approval, operator instruction, protocol effect, deployment approval, operational clearance, or execution consequence by default.
10.2.5(f) Interoperability profiles shall be reviewed for over-routing, context collapse, false association, retrieval leakage, embedding leakage, cross-tenant leakage, cross-program leakage, cross-border leakage, hidden dependencies, vendor lock-in, public authority confusion, finance overclaim, procurement implication, provider preference, sponsor control, protected knowledge exposure, and correctionability.
10.2.5(g) Where interoperability profiles are corrected, superseded, deprecated, restricted, withdrawn, retracted where necessary, or archived, GCRI Canada shall update affected schemas, APIs, data contracts, interface specifications, Evidence Packs, dashboards, public-safe summaries, training materials, public claims, and dependency notices as appropriate.
10.2.5(h) The controlling rule shall be that interoperability allows evidence to move with meaning, limits, and correction intact; it does not move authority, finance, procurement, certification, recognition, protocol effect, or execution by implication.
10.2.6 Schemas, APIs, Data Dictionaries, Data Contracts, and Interface Specifications. 10.2.6(a) Schemas, APIs, data dictionaries, data contracts, and interface specifications shall mean structured technical assets that define data fields, metadata fields, evidence fields, method fields, record fields, proof fields, output fields, controlled vocabularies, validation rules, exchange patterns, access requirements, permitted uses, prohibited uses, public-safe limits, correction mechanisms, and interface obligations for public-good technical interoperability.
10.2.6(b) Such assets may support Observatory systems, Truth Engine systems, Risk Management systems, Rails interfaces, Grid interfaces, Docket interfaces, Academy interfaces, Nexus Universe interfaces, public authority learning interfaces, community safeguard interfaces, provider interfaces, sponsor interfaces, host interfaces, operator interfaces, GRF inputs, GRA inputs, Protocol Authority inputs, Evidence Packs, Decision Packs, dashboards, maps, APIs, datasets, model records, compute records, inference records, proof receipts, correction records, and registers.
10.2.6(c) Material schemas, APIs, data dictionaries, data contracts, and interface specifications shall identify version, steward, custodian, scope, source, license, intended users, data classes, evidence classes, output classes, access classes, handling classes, public-safe status, authentication requirements, authorization requirements, logging requirements, validation rules, field sensitivity, metadata sensitivity, cross-border implications, AI-use implications, retention implications, deletion implications, correction path, deprecation path, and archive status.
10.2.6(d) APIs and interface specifications shall include controls for authentication, authorization, least privilege, rate limits where appropriate, logging, field minimization, public-safe filtering, error-message safety, export limits, versioning, deprecation, misuse detection, correction propagation, and withdrawal or restriction of unsafe endpoints.
10.2.6(e) Data contracts shall preserve source authority, lawful basis or permission treatment, data-class treatment, public-safe treatment, privacy treatment, cybersecurity treatment, sovereign data treatment, public authority restrictions, community safeguards, protected knowledge restrictions, provider restrictions, sponsor restrictions, host restrictions, operator restrictions, finance restrictions, procurement restrictions, AI-use restrictions, publication limits, and correction obligations.
10.2.6(f) Schemas, APIs, data dictionaries, data contracts, and interface specifications shall not be treated as official data standards, public authority requirements, procurement specifications, certification criteria, finance-readiness criteria, provider qualifications, host approvals, protocol effects, or execution requirements by default.
10.2.6(g) Where these assets are corrected, versioned, deprecated, restricted, withdrawn, retracted where necessary, or archived, GCRI Canada shall preserve compatibility notes, migration notes, dependency notices, public-safe notices where appropriate, correction records, and continuing prohibited uses.
10.2.6(h) The controlling rule shall be that structured interfaces must carry data meaning, limits, classification, permissions, public-safe status, and correction paths, not hidden authority or uncontrolled reuse.
10.2.7 Ontologies, Taxonomies, Controlled Vocabularies, and Semantic Crosswalks. 10.2.7(a) Ontologies, taxonomies, controlled vocabularies, and semantic crosswalks shall mean public-good technical assets that define, organize, relate, translate, map, classify, and disambiguate concepts, terms, categories, evidence types, data types, output types, risk domains, technology domains, institutional roles, public-safe meanings, boundary terms, correction terms, maturity-input terms, interface terms, and controlled definitions used by GCRI Canada.
10.2.7(b) Such assets may support semantic interoperability across GCRI Canada, GCRI US, GRF, GRA, Protocol Authority, Nexus Network, Nexus Observatory, Nexus Risk Management, Nexus Rails, Nexus Grid, Nexus Docket, Nexus Academy, Nexus Universe, Regional Nexus Consortiums, National Nexus Consortiums, National Companies, Project SPVs, public authorities, communities, providers, sponsors, hosts, operators, universities, and capital-reader interfaces.
10.2.7(c) Material ontology and vocabulary assets shall identify term or concept source, definition, scope, permitted use, prohibited use, status, version, steward, equivalent terms, related terms, deprecated terms, translation notes where applicable, public-safe notes, authority-boundary notes, finance-boundary notes, procurement-boundary notes, certification-boundary notes, recognition-boundary notes, protocol-boundary notes, community-safeguard notes, protected-knowledge notes, and correction path.
10.2.7(d) Semantic crosswalks shall identify source vocabulary, target vocabulary, mapping logic, mapping confidence, mapping uncertainty, mapping limitations, context limits, translation risks, false equivalence risks, jurisdictional limits, public authority meaning risks, community meaning risks, protected knowledge risks, finance meaning risks, procurement meaning risks, provider meaning risks, sponsor meaning risks, and correction path.
10.2.7(e) Controlled vocabularies shall be used to prevent overclaim, role confusion, public authority confusion, finance overclaim, procurement implication, certification implication, recognition implication, protocol implication, provider preference, sponsor validation, host approval implication, operator instruction implication, public warning implication, emergency-command implication, and execution drift.
10.2.7(f) Ontologies, taxonomies, controlled vocabularies, and semantic crosswalks shall not create legal definitions for external law, public authority definitions, regulatory classifications, public warning categories, procurement categories, finance categories, certification categories, recognition categories, protocol categories, professional categories, or execution categories by default.
10.2.7(g) Where semantic assets are corrected, deprecated, superseded, restricted, withdrawn, retracted where necessary, or archived, GCRI Canada shall update affected schemas, APIs, data dictionaries, Evidence Packs, dashboards, maps, public-safe outputs, training materials, interface materials, public claims, and dependency records as appropriate.
10.2.7(h) The controlling rule shall be that controlled language is part of public-good infrastructure: words must preserve meaning, boundaries, and correction, not accidentally confer authority.
10.2.8 Dashboards, Public-Safe Visualizations, Map Templates, and Evidence Displays. 10.2.8(a) Dashboards, public-safe visualizations, map templates, and evidence displays shall mean technical assets used to present, organize, summarize, visualize, compare, filter, navigate, or explain evidence, data, methods, confidence, uncertainty, limitations, public-safe omissions, incidents, corrections, interfaces, and outputs in public-safe, controlled, restricted, internal, training, or demonstration contexts.
10.2.8(b) Such assets may include dashboard templates, map templates, visualization components, report display patterns, public-safe charting conventions, API-backed display components, controlled-room displays, public authority learning displays, community-facing displays, provider-neutral displays, sponsor-bounded displays, host-facing displays, operator-facing displays, Nexus Universe displays, Academy displays, Risk Management displays, Rails literacy displays, Grid displays, and Evidence Pack displays.
10.2.8(c) Material dashboard and display assets shall identify purpose, audience, data inputs, source records, method records, version, update status, field meanings, indicator meanings, score meanings where any, color meanings, legend meanings, confidence display, uncertainty display, limitation display, public-safe status, access status, export limits, screenshot limits, API limits, accessibility status, translation status where applicable, permitted uses, prohibited uses, and correction path.
10.2.8(d) Dashboard, visualization, map, and evidence-display assets shall be reviewed for visual overclaim, false precision, alert-like design, warning-like design, rating-like design, certification-like design, recognition-like design, finance-like design, procurement-like design, provider-comparison effects, sponsor-validation effects, host-approval effects, operator-instruction effects, public authority effects, community harm, protected knowledge exposure, screenshot misuse, export misuse, and stale-data reliance.
10.2.8(e) Such assets shall not present labels, badges, seals, icons, colors, score bands, readiness indicators, maturity-like stages, hazard-like banners, finance-like indicators, procurement-like categories, certification-like marks, recognition-like marks, provider comparisons, sponsor references, host references, operator references, or public authority references in a manner that implies prohibited status or authority.
10.2.8(f) Dashboard, visualization, map, and evidence-display assets shall not create public warning, emergency command, public authority decision, procurement approval, finance-readiness, rating, guarantee, certification, recognition, provider endorsement, sponsor approval, host approval, operator instruction, protocol effect, deployment approval, operational clearance, market authority, legal status, or execution consequence by default.
10.2.8(g) Where display assets are corrected, restricted, superseded, withdrawn, retracted where necessary, retired, or archived, GCRI Canada shall update affected dashboards, maps, APIs, reports, Evidence Packs, public-safe summaries, Academy materials, public claims, and dependency records as appropriate.
10.2.8(h) The controlling rule shall be that evidence displays must make evidence legible without making it look like authority.
10.2.9 Evaluation Harnesses, Test Harnesses, Benchmark Harnesses, Negative Tests, Gold Vectors, and Method Libraries. 10.2.9(a) Evaluation harnesses, test harnesses, benchmark harnesses, negative tests, gold vectors, and method libraries shall mean technical assets used to evaluate, test, compare, challenge, verify, falsify, stress, reproduce where appropriate, calibrate, validate, monitor, or improve methods, software, models, datasets, dashboards, APIs, digital twins, sensors, AI-RAN evidence, DePIN evidence, geospatial methods, evidence methods, public-safe publication methods, and correction methods.
10.2.9(b) Such assets may include evaluation scripts, test suites, benchmark scenarios, negative test sets, adversarial tests, edge-case tests, regression tests, calibration sets, gold vectors, reference outputs, method libraries, reproducibility packages, model evaluation harnesses, dataset evaluation harnesses, dashboard evaluation harnesses, API validation harnesses, cybersecurity test patterns, public-safe publication tests, boundary-language tests, and correction tests.
10.2.9(c) Material evaluation and benchmark assets shall identify purpose, scope, intended use, prohibited use, system or method under evaluation, dataset identity where applicable, benchmark conditions, test conditions, assumptions, metrics, limitations, bias risks, coverage gaps, failure modes, negative tests, edge cases, adversarial cases, review status, version, steward, custodian, data classes, evidence classes, public-safe status, access class, handling class, and correction path.
10.2.9(d) Evaluation, testing, or benchmark results shall be treated as technical evidence subject to source lineage, method documentation, confidence, uncertainty, limitations, context, review status, public-safe treatment, and correction. Such results shall not be treated as certification, ranking, procurement preference, finance-readiness, provider superiority, security certification, public authority approval, protocol effect, operational clearance, or execution readiness by default.
10.2.9(e) Negative tests, adversarial tests, edge cases, and failure-mode tests shall be preserved where appropriate to prevent false maturity, false readiness, false safety, false security, false interoperability, false public-safe confidence, provider overclaim, sponsor validation, finance overclaim, procurement implication, certification implication, recognition implication, protocol implication, or execution drift.
10.2.9(f) Benchmark assets shall be reviewed for bias, representativeness, fitness-for-purpose, stale assumptions, data leakage, test contamination, provider influence, sponsor influence, hidden dependencies, public authority confusion, finance overclaim, procurement implication, and public-safe publication risk.
10.2.9(g) Where evaluation or benchmark assets are corrected, superseded, restricted, withdrawn, deprecated, retired, or archived, GCRI Canada shall update affected benchmark cards, system cards, model cards, dataset cards, Evidence Packs, public-safe summaries, dashboards, training materials, public claims, and dependency notices as appropriate.
10.2.9(h) The controlling rule shall be that tests and benchmarks support disciplined learning and correction; they do not certify, rank, procure, finance, approve, recognize, confer protocol effect, or execute by default.
10.2.10 Dataset Cards, Model Cards, System Cards, Benchmark Cards, Compute Workload Templates, Inference Record Templates, and Proof Receipt Templates. 10.2.10(a) Dataset Cards, Model Cards, System Cards, Benchmark Cards, Compute Workload Templates, Inference Record Templates, and Proof Receipt Templates shall mean record-template assets used to standardize documentation, review, governance, auditability, public-safe treatment, correction, and assurance of datasets, models, systems, benchmarks, compute workloads, AI inferences, proof receipts, anchoring, hashing, signing, timestamping, and tamper-evidence events.
10.2.10(b) Dataset Card templates shall support records of dataset identity, owner, custodian, source, provenance, license, permissions, consent or non-consent treatment where applicable, data classification, sensitivity, quality, completeness, bias, representativeness, timeliness, gaps, limitations, permitted uses, prohibited uses, AI-use restrictions, cross-border treatment, sovereign data treatment, access controls, retention, deletion, sealing, archive, correction, supersession, withdrawal, or retraction.
10.2.10(c) Model Card and System Card templates shall support records of model or system identity, provider, owner, custodian, purpose, permitted uses, prohibited uses, architecture, components, data flows, model flows, deployment context, risk class, boundary limits, data access, evaluation, validation, limitations, bias risks, drift risks, hallucination risks, security risks, failure modes, monitoring, incident history, restriction history, suspension history, retirement status, human review requirements, output review requirements, and correction path.
10.2.10(d) Benchmark Card templates shall support records of benchmark purpose, scope, dataset, method, conditions, metrics, limitations, bias, failure modes, negative tests, adversarial tests, edge cases, reproducibility, review status, public-safe publication controls, and correction path.
10.2.10(e) Compute Workload Templates and Inference Record Templates shall support records of workload identity, purpose, authority, classification, inputs, source permissions, model or code identity, version, dependencies, environment, runtime, configuration, execution context, compute location, jurisdiction, provider, infrastructure type, secure enclave status, air-gap status, sovereign data zone status, output identity, public-safe status, human review, technical review, privacy review, cyber review, public authority review, safeguards review, logging, signing, hashing, retention, deletion, sealing, archive, legal hold, and correction path.
10.2.10(f) Proof Receipt Templates shall support records of technical receipts for evidence, compute, model, dataset, software, Observatory, Truth Engine, or other technical events, including metadata, scope, limits, owner, custodian, hashing, signing, timestamping, anchoring, tamper-evidence, revocation, supersession, correction, and interface limits with GRF, GRA, Protocol Authority, public authorities, providers, hosts, sponsors, communities, and other actors.
10.2.10(g) Such templates shall not create certification, recognition, finance-readiness, public authority decision, regulatory finding, procurement approval, provider endorsement, sponsor approval, host approval, operator approval, rating, guarantee, public warning, emergency command, protocol effect, professional certification, operational clearance, legal status, market authority, infrastructure operation, deployment approval, or execution consequence by default.
10.2.10(h) The controlling rule shall be that governance templates make technical systems recordable, reviewable, and correctionable; they do not make the recorded object approved, certified, financed, procured, recognized, protocol-effective, or execution-ready.
10.2.11 Secure Release Scripts, Repository Templates, SBOM Templates, Dependency Review Methods, and Vulnerability Management Templates. 10.2.11(a) Secure release scripts, repository templates, software bill of materials templates, dependency review methods, and vulnerability management templates shall mean technical assets used to support controlled development, release, publication, restriction, security review, dependency visibility, vulnerability response, correction, retirement, and archive of public-good software and related public-good technical assets.
10.2.11(b) Secure release scripts and repository templates may support repository initialization, branch protection, commit review, signed commits where appropriate, dependency review, secret scanning, credential prevention, license review, release tagging, changelog generation, artifact packaging, public-safe review, security review, deprecation notices, correction notices, and archive controls.
10.2.11(c) Software bill of materials templates shall support identification of components, dependencies, versions, licenses, maintainers where known, source repositories, build artifacts, known vulnerabilities where appropriate, dependency risks, transitive dependency risks, open-source obligations, proprietary restrictions, export-control sensitivity, sanctions sensitivity, controlled-technology sensitivity, security status, and correction path.
10.2.11(d) Dependency review methods shall identify direct dependencies, transitive dependencies, provider dependencies, sponsor dependencies, cloud dependencies, model dependencies, data dependencies, API dependencies, dashboard dependencies, map dependencies, compute dependencies, cryptographic dependencies, license dependencies, public authority dependencies, community safeguard dependencies, protected knowledge dependencies, and correction dependencies.
10.2.11(e) Vulnerability management templates shall support vulnerability intake, severity classification where used, affected asset identification, exploitability context where safe, affected data classes, affected evidence classes, public-safe risk, mitigation status, patch status, compensating controls, disclosure status, coordinated disclosure, responsible non-disclosure, correction, supersession, withdrawal, archive, and closeout.
10.2.11(f) Secure release and vulnerability assets shall be handled to avoid unsafe disclosure of vulnerabilities, exploit details, credentials, secrets, keys, tokens, infrastructure-sensitive information, cyber-sensitive information, public authority restrictions, provider-sensitive information, host-sensitive information, operator-sensitive information, protected knowledge, or other restricted information.
10.2.11(g) Secure release scripts, repository templates, SBOM templates, dependency review methods, and vulnerability management templates shall not create security certification, compliance determination, public authority approval, procurement approval, finance-readiness, provider endorsement, sponsor approval, host approval, operational clearance, remediation approval, protocol effect, public warning, emergency command, legal determination, or execution consequence by default.
10.2.11(h) The controlling rule shall be that secure release and dependency assets protect public-good technical assets from hidden risk, but they do not certify security, approve use, procure systems, finance projects, or execute remediation.
10.2.12 Public-Safe Publication Templates, Controlled Annex Templates, Evidence Pack Templates, Decision Pack Templates, and Correction Templates. 10.2.12(a) Public-safe publication templates, controlled annex templates, restricted annex templates, Evidence Pack templates, Decision Pack templates, correction templates, supersession templates, withdrawal templates, retraction templates, re-issue templates, archive templates, clarification templates, misuse-response templates, and dependency-notice templates shall mean structured technical and institutional assets used to ensure that GCRI Canada outputs remain source-lined, classified, public-safe, boundary-valid, confidence-aware, uncertainty-aware, limitation-aware, versioned, reviewable, and correctionable.
10.2.12(b) Public-safe publication templates shall support consistent inclusion of output purpose, source classes, method classes, evidence scope, update status, timestamp, version, confidence, uncertainty, limitations, public-safe omissions, responsible non-disclosure basis, stale-data treatment, contradiction status, data-gap status, permitted uses, prohibited uses, boundary language, correction status, supersession status, withdrawal status where applicable, retraction status where applicable, and archive status.
10.2.12(c) Controlled annex and restricted annex templates shall support audience-specific access controls, handling classes, data classes, evidence classes, public authority restrictions, community safeguards, protected knowledge restrictions, privacy controls, cybersecurity controls, sovereign data controls, finance-boundary controls, procurement-boundary controls, provider-neutrality controls, sponsor non-control controls, host-boundary controls, operator-boundary controls, permitted uses, prohibited uses, notice rules, correction path, and closeout obligations.
10.2.12(d) Evidence Pack templates shall support records of purpose, scope, source lineage, data classification, evidence classification, source comparison, method records, compute records where applicable, model records where applicable, dashboard records where applicable, map records where applicable, API records where applicable, confidence, uncertainty, limitations, public-safe status, annex structure, boundary notes, interface logs, correction path, supersession path, withdrawal path, retraction path where applicable, and archive treatment.
10.2.12(e) Decision Pack templates shall support decision-supporting evidence organization without creating decisions. They shall identify the actor, audience, purpose, evidence base, source records, method records, public-safe status, options or considerations where permitted, limitations, confidence, uncertainty, prohibited reliance, boundary language, correction path, and any requirement that decisions be made only by competent actors under their own authority.
10.2.12(f) Correction templates shall support intake, classification, reviewer assignment, affected record identification, affected output identification, affected interface identification, prior status, corrected status, correction basis, confidence effect, uncertainty effect, limitation effect, boundary-language effect, public-safe effect, notice decision, dependency treatment, supersession, withdrawal, retraction, re-issue, archive, and closeout.
10.2.12(g) Such templates shall include boundary language sufficient to prevent interpretation as public warning, emergency command, public authority decision, regulatory finding, procurement approval, funding approval, public finance approval, finance-readiness, investment advice, insurance approval, lending decision, underwriting decision, rating, guarantee, certification, recognition, maturity record, claims approval, protocol effect, provider endorsement, sponsor approval, host approval, operator instruction, operational clearance, deployment approval, professional certification, legal status, market authority, infrastructure operation, or execution consequence.
10.2.12(h) Public-safe publication, annex, Evidence Pack, Decision Pack, and correction templates shall be corrected, restricted, superseded, withdrawn, retired, or archived where they become stale, misleading, unsafe, legally unsupported, public-safe defective, boundary-defective, provider-captured, sponsor-influenced, public-authority-confusing, finance-overclaiming, procurement-implying, certification-implying, recognition-implying, protocol-implying, or correction-defective.
10.2.12(i) The controlling rule shall be that templates discipline institutional outputs before they travel; they do not convert structured evidence into decisions, approvals, certifications, recognitions, finance, procurement, protocol effect, authority, or execution.
10.3 Public-Good Technical Asset Register
10.3.1 Requirement to Maintain a Public-Good Technical Asset Register. 10.3.1(a) GCRI Canada shall maintain, or cause to be maintained, a Public-Good Technical Asset Register as the authoritative institutional record for material public-good technical assets stewarded, held, developed, adapted, maintained, released, restricted, corrected, superseded, withdrawn, retired, archived, or otherwise used by GCRI Canada in furtherance of its evidence, methods, observability, ontology, interoperability, verifiable compute, verifiable intelligence, public-safe publication, public-good software, open technical baseline, assurance, correction, and public-benefit purposes.
10.3.1(b) The Public-Good Technical Asset Register shall apply to material public-good software, reference architectures, open technical baselines, technical profiles, interoperability profiles, schemas, APIs, data dictionaries, data contracts, interface specifications, ontologies, taxonomies, controlled vocabularies, semantic crosswalks, dashboards, visualization templates, map templates, evidence displays, evaluation harnesses, test harnesses, benchmark harnesses, negative tests, gold vectors, method libraries, Dataset Card templates, Model Card templates, System Card templates, Benchmark Card templates, Compute Workload templates, Inference Record templates, Proof Receipt templates, secure release scripts, repository templates, SBOM templates, dependency review methods, vulnerability management templates, public-safe publication templates, controlled annex templates, restricted annex templates, Evidence Pack templates, Decision Pack templates, correction templates, supersession templates, withdrawal templates, retraction templates, archive templates, clarification templates, misuse-response templates, and dependency-notice templates.
10.3.1(c) The Public-Good Technical Asset Register shall record public-good technical assets according to their actual institutional role, technical function, legal status, rights status, public-safe status, release status, security status, data sensitivity, dependency status, interface status, correction status, and assurance status, and shall not classify assets by convenience, promotional value, sponsor preference, provider preference, external visibility, repository location, technical maturity claims, or public narrative.
10.3.1(d) No public-good technical asset shall be treated as adopted, maintained, released, open, public-safe, restricted, deprecated, superseded, withdrawn, retired, archived, or usable in a material interface unless its status is recorded in the Public-Good Technical Asset Register or in an approved linked register sufficient to preserve asset identity, purpose, version, stewardship, classification, rights, dependencies, permitted uses, prohibited uses, security status, public-safe status, correction path, and archive treatment.
10.3.1(e) The Public-Good Technical Asset Register shall be maintained as a validity-by-record instrument. An asset not adequately recorded shall not be treated as institutionally valid for material external use, public-safe release, public authority learning, GRF input, GRA input, Protocol Authority input, Nexus Observatory use, Nexus Truth Engine use, Nexus Rails use, Nexus Grid use, Nexus Academy use, National Company use, Project SPV use, provider use, sponsor use, host use, operator use, capital-reader use, procurement-facing use, finance-facing use, or public claim use.
10.3.1(f) Registering a public-good technical asset shall not create certification, recognition, finance-readiness, public authority decision, regulatory finding, procurement approval, provider endorsement, sponsor approval, host approval, operator approval, professional certification, rating, guarantee, public warning, emergency command, protocol effect, operational clearance, legal status, market authority, infrastructure operation, deployment approval, or execution consequence by default.
10.3.1(g) Access to the Public-Good Technical Asset Register shall be governed by access class, handling class, asset classification, data sensitivity, cybersecurity status, public authority restrictions, community safeguards, protected knowledge status, export-control sensitivity, sanctions sensitivity, controlled-technology sensitivity, IP restrictions, license restrictions, provider-sensitive status, sponsor-sensitive status, host-sensitive status, operator-sensitive status, finance-sensitive status, procurement-sensitive status, and correction obligations.
10.3.1(h) The controlling rule shall be that public-good technical assets become institutionally usable only when their identity, purpose, rights, status, dependencies, boundaries, risks, and correction paths are recorded with enough precision to prevent assets from becoming hidden authority, hidden dependency, hidden capture, hidden risk, or uncorrectable infrastructure.
10.3.2 Asset Identity, Name, Version, Owner, Custodian, Maintainer, Contributor History, and Repository Location. 10.3.2(a) Each material Public-Good Technical Asset Register entry shall identify the asset’s title or identifier, official name, short name where any, prior names where any, asset class, asset family, version, release identifier, repository location, storage location, publication location where any, archive location where any, steward, custodian, maintainer, approving function where applicable, contributor history, contribution source, and dependency links.
10.3.2(b) Asset identity records shall distinguish assets owned by GCRI Canada, licensed to GCRI Canada, jointly developed, contributor-supplied, provider-contributed, sponsor-supported, public authority-supplied, community-contributed, university-contributed, open-source, open-data, public-domain, restricted, third-party, derived, forked, adapted, mirrored, archived, or otherwise held under limited rights.
10.3.2(c) Asset name records shall preserve naming discipline sufficient to prevent public authority confusion, provider endorsement implication, sponsor validation implication, host approval implication, protocol implication, certification implication, recognition implication, finance implication, procurement implication, or execution implication. Asset names shall not use official-sounding, authority-conferring, certification-like, recognition-like, finance-like, procurement-like, public-warning-like, public-authority-like, provider-preferential, sponsor-validating, host-approving, or protocol-conferring terminology unless such terminology is expressly recorded, lawful, public-safe, and bounded.
10.3.2(d) Version records shall identify version number or version identifier, release date, change date, change summary, prior version, successor version where any, supersession relationship, deprecation status, migration notes where appropriate, compatibility notes where appropriate, security effects, public-safe effects, interface effects, dependency effects, correction effects, and archive treatment.
10.3.2(e) Ownership and stewardship records shall identify the legal owner where known, GCRI Canada steward, technical steward, repository maintainer, data steward where applicable, security steward where applicable, public-safe reviewer where applicable, correction steward where applicable, and Board or committee oversight route where material.
10.3.2(f) Contributor history shall identify contributors where appropriate, contribution type, contribution date, contribution terms, contributor capacity, institutional affiliation where relevant, IP terms, data terms, confidentiality terms, public claims limits, conflict status, provider role where any, sponsor role where any, host role where any, public authority role where any, community or protected knowledge role where any, and correction obligations.
10.3.2(g) Repository and storage records shall identify repository platform, repository visibility, branch or release structure, public/private status, access rules, backup status, mirror status, fork status, archive status, secrets status, SBOM location where any, issue tracker where any, vulnerability disclosure location where any, correction record location, and closeout path.
10.3.2(h) Asset identity, naming, versioning, stewardship, contributor, and repository records shall not create certification, recognition, finance-readiness, public authority approval, procurement approval, provider endorsement, sponsor approval, host approval, operator approval, protocol effect, professional certification, deployment approval, operational clearance, legal status, market authority, public warning, emergency command, or execution consequence by default.
10.3.2(i) The controlling rule shall be that a public-good technical asset must be identifiable by name, version, steward, rights, contributors, and location before it can be trusted, reused, released, restricted, corrected, superseded, or retired.
10.3.3 Asset Purpose, Scope, Audience, Permitted Uses, Prohibited Uses, Boundary Language, and Public-Safe Status. 10.3.3(a) Each material Public-Good Technical Asset Register entry shall identify the asset’s purpose, scope, intended audience, permitted uses, prohibited uses, public-safe status, release status, interface status, boundary language, dependency limits, and correction path.
10.3.3(b) Purpose records shall state whether the asset supports evidence, methods, observability, ontology, interoperability, verifiable compute, verifiable intelligence, Truth Engine methods, Observatory methods, Risk Management methods, Rails literacy, Grid inputs, Docket routing, Academy learning, Nexus Universe learning, public authority learning, community safeguards, provider-neutral review, sponsor non-control discipline, host readiness evidence, Evidence Packs, Decision Packs, public-safe publication, correction, assurance, cybersecurity, data governance, model governance, or other public-benefit technical functions.
10.3.3(c) Scope records shall identify what the asset covers, what it does not cover, applicable domains, excluded domains, assumptions, preconditions, limitations, jurisdictional limits, audience limits, technology limits, data limits, public-safe limits, dependency limits, and any conditions under which the asset should not be used.
10.3.3(d) Audience records shall distinguish internal GCRI Canada users, GCRI US interfaces, GRF interfaces, GRA interfaces, Protocol Authority interfaces, Nexus bodies, public authorities, communities, Indigenous governance bodies where applicable, universities, providers, sponsors, hosts, operators, National Companies, Project SPVs, capital readers, procurement actors, Academy learners, media, public users, and other audiences, and shall identify whether each audience may view, use, adapt, cite, publish, copy, fork, extend, execute, or only receive public-safe summaries.
10.3.3(e) Permitted uses shall be stated narrowly enough to preserve the asset’s public-benefit purpose, evidence role, methods role, public-safe status, rights status, data restrictions, security restrictions, public authority boundaries, community safeguards, protected knowledge restrictions, provider neutrality, sponsor non-control, finance boundaries, procurement boundaries, protocol boundaries, and correctionability.
10.3.3(f) Prohibited uses shall include, where material, use as certification, recognition, finance-readiness, investment advice, insurance approval, lending decision, rating, guarantee, public finance approval, procurement approval, provider endorsement, sponsor approval, host approval, operator instruction, public authority decision, regulatory finding, public warning, emergency command, Protocol Authority effect unless separately created, professional certification, deployment approval, operational clearance, market authority, infrastructure operation, legal status, or execution instruction.
10.3.3(g) Boundary language shall be recorded and attached to asset documentation, release notes, repository materials, dashboard interfaces, API documentation, templates, public-safe summaries, controlled annexes, restricted annexes, training materials, and public claims where material.
10.3.3(h) Public-safe status shall identify whether the asset is public-safe for external release, public-safe only with conditions, controlled-room-only, restricted, internal, draft, experimental, not cleared for publication, or withdrawn from publication. Public-safe status shall be reviewed where asset content, audience, dependencies, data, security, public authority references, community safeguards, protected knowledge, provider references, sponsor references, finance-facing use, procurement-facing use, or public claims materially change.
10.3.3(i) The controlling rule shall be that an asset’s purpose and permitted use must be narrower than its technical possibility; what an asset can technically do shall not determine what GCRI Canada permits it to mean or enable.
10.3.4 Asset Classification, Handling Class, Access Class, Security Class, Data Sensitivity, Export-Control Sensitivity, and Protected Knowledge Status. 10.3.4(a) Each material Public-Good Technical Asset Register entry shall classify the asset according to asset class, handling class, access class, security class, data sensitivity, evidence sensitivity, public-safe status, privacy status, cybersecurity status, infrastructure sensitivity, public authority sensitivity, finance sensitivity, commercial sensitivity, sovereign data status, export-control sensitivity, sanctions sensitivity, controlled-technology sensitivity, community-protected status, Indigenous or protected knowledge status, and correction sensitivity.
10.3.4(b) Asset classification shall be risk-based and context-based. An asset shall not be classified solely by repository visibility, file type, publication status, source label, sponsor label, provider label, public authority reference, open-source status, open-data status, or technical convenience where the actual content, dependencies, intended use, misuse risk, public-safe risk, data sensitivity, cybersecurity risk, protected knowledge risk, export-control risk, sanctions risk, controlled-technology risk, or correction risk requires a more protective treatment.
10.3.4(c) Handling class shall identify whether the asset may be handled as public, public-safe, internal, confidential, restricted, controlled-room-only, no-download, secure-enclave-only, compute-to-data-only, public-authority-restricted, community-protected, protected-knowledge-restricted, cyber-sensitive, infrastructure-sensitive, finance-sensitive, commercially sensitive, export-controlled, sanctions-sensitive, controlled-technology-sensitive, or otherwise specially controlled.
10.3.4(d) Access class shall identify who may access the asset, under what role, for what purpose, under what time limits, with what download rights, copy rights, fork rights, export rights, execution rights, repository rights, API rights, dashboard rights, publication rights, redistribution rights, modification rights, correction rights, and revocation path.
10.3.4(e) Security class shall identify required authentication, authorization, logging, encryption, key management, token management, secrets management, credential controls, repository controls, vulnerability management, dependency review, secure configuration, incident handling, backup, disaster recovery, decommissioning, and archive controls proportionate to the asset’s risk.
10.3.4(f) Data sensitivity shall identify whether the asset contains, processes, references, embeds, retrieves, models, visualizes, documents, or can reasonably reveal personal data, public authority data, health-sensitive data, cyber-sensitive data, infrastructure-sensitive data, finance-sensitive data, commercially sensitive data, community-protected data, Indigenous or protected knowledge, precise location data, legal-sensitive data, export-control-sensitive data, sanctions-sensitive data, controlled technology, credentials, secrets, keys, tokens, vulnerabilities, or sensitive metadata.
10.3.4(g) Export-control, sanctions, and controlled-technology sensitivity shall be reviewed for assets involving cybersecurity tools, cryptographic tools, AI models, model weights, advanced compute, semiconductor-relevant methods, AI-RAN systems, O-RAN systems, DePIN systems, sensors, geospatial data, dual-use technologies, critical infrastructure methods, public authority data, cross-border compute, or other restricted technical domains.
10.3.4(h) Protected knowledge status shall identify whether the asset contains, derives from, maps, models, summarizes, translates, embeds, retrieves, teaches, or could reveal community-protected, Indigenous, local, territorial, environmental, cultural, sacred-site, sensitive-site, or protected knowledge materials and shall record applicable safeguards, permissions, consent or non-consent treatment where applicable, withdrawal pathways, challenge pathways, publication limits, and correction path.
10.3.4(i) The controlling rule shall be that asset classification must follow what the asset can expose, enable, imply, or be misused to support, not merely what the asset is called.
10.3.5 Asset License, IP Status, Third-Party Rights, Contributor Terms, Patent Status, Dependency Status, and Standards-Support Status. 10.3.5(a) Each material Public-Good Technical Asset Register entry shall identify the asset’s license, IP status, third-party rights, contributor terms, patent status where known or material, dependency status, standards-support status, open-source obligations, data-license obligations, attribution obligations, confidentiality restrictions, moral rights where applicable, publication rights, derivative-use rights, sublicensing rights, transfer restrictions, and correction obligations.
10.3.5(b) License records shall identify whether the asset is open-source, source-available, open-data, public-domain, proprietary, internally licensed, externally licensed, contributor-licensed, jointly licensed, restricted-use, public-safe-use-only, controlled-room-use-only, research-use-only, non-commercial-use-only, standards-support-only, documentation-only, or subject to other conditions.
10.3.5(c) IP status records shall identify ownership where known, GCRI Canada rights, third-party rights, background IP, foreground IP, improvements, derivative works, contributor rights, provider rights, sponsor rights, host rights, public authority rights, community rights, Indigenous or protected knowledge rights where applicable, university rights, contractor rights, open-source obligations, patent sensitivity, trade secret sensitivity, copyright status, database rights where applicable, moral rights where applicable, and license compatibility.
10.3.5(d) Contributor terms shall identify contributor identity where appropriate, contribution type, contribution date, role, affiliation, authority to contribute, license grant, certificate of origin or equivalent where applicable, confidentiality status, IP representations where any, conflict status, provider role where any, sponsor role where any, public authority role where any, community role where any, protected knowledge role where any, permitted public acknowledgement, prohibited public claims, and correction cooperation obligations.
10.3.5(e) Patent status shall identify, where known or material, whether the asset may implicate patent claims, patent applications, defensive publication, patent pledge, standards-essential claims, FRAND-like commitments where any, patent license terms, patent uncertainty, patent-sensitive components, and any restriction necessary to prevent misleading public claims or unsafe reuse.
10.3.5(f) Dependency status shall identify direct dependencies, transitive dependencies, data dependencies, model dependencies, API dependencies, compute dependencies, cloud dependencies, repository dependencies, dashboard dependencies, map dependencies, cryptographic dependencies, provider dependencies, sponsor dependencies, public authority dependencies, community safeguard dependencies, protected knowledge dependencies, license dependencies, security dependencies, and correction dependencies.
10.3.5(g) Standards-support status shall identify whether the asset supports public-good standardization, semantic interoperability, technical baseline work, Protocol Authority input, reference architecture work, controlled vocabulary work, or standards-adjacent learning, and shall state that such support does not create protocol effect, conformance status, certification, procurement qualification, provider preference, public authority adoption, finance-readiness, or execution consequence by GCRI Canada by default.
10.3.5(h) Where license, IP, third-party rights, contributor authority, patent status, dependency status, or standards-support status is unclear, disputed, incompatible, unsafe, stale, unsupported, hidden, or correction-defective, GCRI Canada shall restrict use, seek clarification, reclassify the asset, replace affected components, relicense where lawful, remove affected materials, issue correction notices where appropriate, withdraw or archive the asset where necessary, and update dependency records.
10.3.5(i) The controlling rule shall be that public-good use requires rights discipline: an asset cannot be public-good in practice if its rights, contributors, dependencies, or standards role are unclear, captured, incompatible, or uncorrectable.
10.3.6 Asset Release Status: Draft, Experimental, Internal, Controlled, Public-Safe, Open, Restricted, Deprecated, Superseded, Withdrawn, Retired, or Archived. 10.3.6(a) Each material Public-Good Technical Asset Register entry shall identify the asset’s release status, including whether the asset is draft, experimental, sandbox, pilot, internal, controlled, restricted, public-safe, open, source-available, limited release, interface-only, deprecated, superseded, withdrawn, retracted where applicable, retired, archived, or closed out.
10.3.6(b) Draft status shall mean the asset is under development, incomplete, unapproved for material external reliance, and subject to change. Draft status shall not be used in public claims as evidence of readiness, certification, recognition, finance-readiness, procurement readiness, protocol effect, deployment approval, operational clearance, or execution readiness.
10.3.6(c) Experimental, sandbox, or pilot status shall mean the asset is being tested, evaluated, demonstrated, or refined under controlled conditions and shall not be treated as production-ready, public-safe by default, externally reliable by default, certified, recognized, finance-ready, procurement-ready, provider-endorsing, sponsor-approved, host-approved, protocol-effective, or execution-ready.
10.3.6(d) Internal status shall mean the asset is intended for GCRI Canada internal use or controlled Nexus use only and shall not be externally released, cited, copied, forked, implemented, or publicly referenced except through recorded public-safe summary, controlled annex, restricted annex, or other authorized channel.
10.3.6(e) Controlled status shall mean the asset may be used only by defined audiences under recorded access, handling, confidentiality, data, public-safe, cybersecurity, public authority, community, protected knowledge, provider-neutrality, sponsor non-control, finance, procurement, and correction limits.
10.3.6(f) Public-safe status shall mean the asset or a defined form of the asset has been reviewed and cleared for a specified external audience and purpose, subject to recorded boundary language, permitted uses, prohibited uses, limitations, public-safe omissions, update status, version, correction path, and misuse monitoring. Public-safe status shall not mean unrestricted status.
10.3.6(g) Open status shall mean the asset may be publicly accessed under recorded license, attribution, permitted-use, prohibited-use, no-endorsement, no-certification, no-recognition, no-finance, no-procurement, no-public-authority, no-protocol-effect unless separately created, no-provider-preference, no-sponsor-control, no-host-approval, no-operator-instruction, no-execution, correction, and supersession terms.
10.3.6(h) Restricted status shall mean the asset contains or may expose materials requiring restricted access, restricted use, no-download treatment, secure environment treatment, rights review, export-control review, sanctions review, controlled-technology review, public authority review, protected knowledge safeguards, cybersecurity controls, privacy controls, sovereign data controls, or other heightened safeguards.
10.3.6(i) Deprecated, superseded, withdrawn, retracted, retired, archived, or closed-out status shall identify whether continued use is discouraged, prohibited, restricted, replaced, historically preserved, or permitted only for audit, correction, dependency review, legal hold, archive, or institutional memory. Such status shall be visibly attached to asset records and, where appropriate, to public-facing materials.
10.3.6(j) The controlling rule shall be that release status is a safety and reliance control; no asset shall be used beyond the status recorded for it.
10.3.7 Asset Dependencies, Known Issues, Vulnerabilities, Security Status, SBOM Status, Build Status, and Maintenance Status. 10.3.7(a) Each material Public-Good Technical Asset Register entry shall identify asset dependencies, known issues, vulnerabilities, security status, SBOM status where applicable, build status where applicable, test status where applicable, maintenance status, patch status, deprecation status, support status, and correction path.
10.3.7(b) Dependency records shall identify direct dependencies, transitive dependencies, software dependencies, package dependencies, library dependencies, model dependencies, dataset dependencies, schema dependencies, API dependencies, compute dependencies, cloud dependencies, repository dependencies, build dependencies, dashboard dependencies, map dependencies, cryptographic dependencies, license dependencies, provider dependencies, sponsor dependencies, host dependencies, public authority dependencies, community safeguard dependencies, protected knowledge dependencies, and correction dependencies.
10.3.7(c) Known issue records shall identify bugs, limitations, data gaps, method gaps, model limitations, incomplete documentation, interoperability limitations, public-safe limitations, accessibility limitations, translation limitations, security limitations, performance limitations, dependency uncertainties, license uncertainties, interface uncertainties, provider risks, sponsor risks, host risks, public authority risks, community safeguard risks, protected knowledge risks, finance-boundary risks, procurement-boundary risks, certification-boundary risks, recognition-boundary risks, protocol-boundary risks, and correction risks.
10.3.7(d) Vulnerability records shall identify known vulnerabilities, suspected vulnerabilities, vulnerability class, affected component, affected version, affected dependency, severity method where used, exploitability context where safe, affected data classes, affected evidence classes, public-safe risk, mitigation status, patch status, compensating controls, disclosure status, coordinated disclosure status, responsible non-disclosure status, correction status, supersession status, withdrawal status, archive status, and closeout status.
10.3.7(e) Security status shall identify whether security review is complete, pending, partial, expired, failed, restricted, corrected, superseded, or not applicable, and shall identify authentication, authorization, logging, secrets controls, key controls, token controls, dependency review, vulnerability management, patch management, secure configuration, repository controls, release controls, and incident history where material.
10.3.7(f) SBOM status shall identify whether a software bill of materials exists, is current, partial, stale, restricted, public-safe, controlled, unavailable, corrected, superseded, or archived, and shall identify whether SBOM publication itself may expose vulnerabilities, protected information, provider-sensitive information, infrastructure-sensitive information, or other restricted information.
10.3.7(g) Build and maintenance status shall identify whether the asset builds, tests, packages, releases, deploys for public-good non-executing use, documents, publishes, restricts, corrects, and archives as expected, together with build environment, build dependencies, release scripts, maintainers, maintenance cycle, patch cycle, end-of-maintenance status, and retirement path.
10.3.7(h) Known issues, vulnerabilities, security status, SBOM status, build status, and maintenance status shall not be represented as security certification, compliance determination, procurement approval, finance-readiness, provider endorsement, sponsor approval, host approval, public authority approval, protocol effect, operational clearance, deployment approval, public warning, emergency command, legal determination, or execution consequence by default.
10.3.7(i) The controlling rule shall be that public-good technical assets must disclose enough dependency and maintenance truth to support safe use and correction, while protecting sensitive security details from unsafe release.
10.3.8 Asset Interfaces With GRF, GRA, Protocol Authority, Nexus Observatory, Nexus Truth Engine, Nexus Rails, Nexus Grid, Nexus Academy, National Companies, Project SPVs, Providers, Hosts, and Public Authorities. 10.3.8(a) Each material Public-Good Technical Asset Register entry shall identify the asset’s material interfaces with The Global Risks Forum (GRF), The Global Risks Alliance (GRA), Nexus Standards / Protocol Authority, Nexus Observatory, Nexus Truth Engine, Nexus Risk Management, Nexus Rails, Nexus Grid, Nexus Docket, Nexus Academy, Nexus Universe, Regional Nexus Consortiums, National Nexus Consortiums, National Companies, Project SPVs, providers, sponsors, hosts, operators, public authorities, universities, communities, capital readers, procurement actors, and other Nexus or external actors where applicable.
10.3.8(b) Interface records shall identify sending interface, receiving interface, asset version, purpose, materials shared, materials received, access class, handling class, public-safe status, data class, evidence class, output class, IP status, license status, security status, permitted use, prohibited use, boundary language, dependency path, correction path, notice path, and closeout path.
10.3.8(c) GRF interface records shall state that asset use or asset input shall not create GRF recognition, standing, claims approval, maturity record, public-facing legitimacy, registry status, certification, public authority meaning, finance-readiness, procurement approval, or execution consequence by GCRI Canada.
10.3.8(d) GRA and Rails interface records shall state that asset use or asset input shall not create finance-readiness, investment advice, insurance approval, lending decision, underwriting decision, public finance approval, rating, guarantee, bankability, fundability, capital allocation, procurement approval, provider preference, host approval, project approval, National Company instruction, Project SPV instruction, deployment approval, operational clearance, or execution consequence by GCRI Canada.
10.3.8(e) Protocol Authority interface records shall state that asset use or asset input shall not create protocol effect, conformance status, certification, Nexus-compatible status, technical standard, procurement qualification, provider qualification, market entitlement, public authority meaning, or execution consequence by GCRI Canada unless separately created by the competent Protocol Authority through its own authority and records.
10.3.8(f) Nexus Observatory and Nexus Truth Engine interface records shall preserve source lineage, method status, compute records where applicable, model records where applicable, confidence, uncertainty, limitations, public-safe status, data governance controls, cybersecurity controls, sovereign data controls, AI-use controls, public authority controls, community safeguards, protected knowledge controls, correction path, and no-oracle or no-authority language where applicable.
10.3.8(g) Grid interface records shall preserve no-GCRI-maturity-record language, no-professional-certification language, no-recognition language, no-procurement language, no-finance-readiness language, no-public-authority language, no-protocol-effect language, correction path, and stage-truth discipline.
10.3.8(h) Academy interface records shall preserve training-purpose limits, learner class, simulation status, public-safe status, no-professional-certification language, no-license language, no-regulated-qualification language, no-procurement-qualification language, no-finance-qualification language, no-public-authority-qualification language, no-protocol-effect language, no-execution language, and correction path.
10.3.8(i) National Company and Project SPV interface records shall preserve legal separateness, public-good stack and enterprise stack separation, no-execution-by-GCRI language, no-project-approval language, no-finance-readiness-by-GCRI language, no-procurement language, no-provider-selection language, no-deployment-approval language, and correction path.
10.3.8(j) Provider, sponsor, host, operator, public authority, community, university, and capital-reader interface records shall preserve actor role, contribution terms, access limits, public-safe status, public authority capacity classification where applicable, community safeguard treatment where applicable, provider-neutrality controls, sponsor non-control controls, host-boundary controls, operator-boundary controls, finance-safe treatment, procurement-safe treatment, no-endorsement language, no-approval language, no-certification language, no-recognition language, no-protocol-effect language, no-execution language, and correction path.
10.3.8(k) The controlling rule shall be that technical asset interfaces may enable shared use, learning, and interoperability, but shall not transfer authority, finance, procurement, certification, recognition, protocol effect, public warning, command, operation, or execution across institutional boundaries.
10.3.9 Asset Correction Path, Supersession Chain, Withdrawal Path, Vulnerability Disclosure Path, and Archive Path. 10.3.9(a) Each material Public-Good Technical Asset Register entry shall identify the asset’s correction path, challenge path where applicable, supersession chain, withdrawal path, retraction path where applicable, vulnerability disclosure path, deprecation path, retirement path, archive path, dependency notice path, misuse-response path, and closeout path.
10.3.9(b) Correction path records shall identify how errors, omissions, misclassifications, source defects, method defects, code defects, dependency defects, license defects, IP defects, security defects, vulnerability defects, data defects, model defects, dashboard defects, API defects, documentation defects, public-safe defects, boundary-language defects, public authority confusion, finance overclaim, procurement implication, certification implication, recognition implication, protocol implication, provider preference, sponsor validation, host approval implication, operator instruction implication, community safeguard defects, protected knowledge exposure, or correction failures may be reported, reviewed, corrected, approved, reissued, and notified.
10.3.9(c) Supersession chain records shall identify prior versions, replacement versions, successor assets, replacement assets, migration requirements, compatibility effects, dependency effects, public-safe effects, security effects, license effects, interface effects, evidence effects, prohibited continued use, permitted historical use, and archive treatment.
10.3.9(d) Withdrawal and retraction paths shall identify who may initiate review, who may approve withdrawal or retraction, what conditions require withdrawal or retraction, how affected users and interfaces are notified, how public-safe notices are issued where appropriate, how controlled notices are issued where appropriate, how repository materials are marked, how dashboards or APIs are restricted, how releases are archived, how public claims are corrected, and how continued reliance is prevented.
10.3.9(e) Vulnerability disclosure paths shall identify intake channel, triage method, severity method where used, affected asset identification, containment steps, coordinated disclosure treatment, responsible non-disclosure treatment, patch path, mitigation path, public-safe disclosure limits, affected interface notice, dependency notice, archive treatment, and closeout.
10.3.9(f) Archive path records shall identify archive basis, archive date, archive location, archive class, access limits, public-safe status, citation status, continuing permitted uses, continuing prohibited uses, legal hold status where any, security restrictions, license restrictions, protected knowledge restrictions, public authority restrictions, correction relationship, supersession relationship, withdrawal relationship, retraction relationship where any, and closeout status.
10.3.9(g) Correction, supersession, withdrawal, retraction, vulnerability disclosure, deprecation, retirement, archive, dependency notice, and closeout actions shall not create certification, recognition, finance-readiness, public authority decision, regulatory finding, procurement approval, security certification, provider endorsement, sponsor finding, host finding, operator finding, rating, guarantee, public warning, emergency command, protocol effect, professional certification, operational clearance, legal status, market authority, infrastructure operation, deployment approval, or execution consequence by default.
10.3.9(h) The controlling rule shall be that every public-good technical asset must have a visible path for correction and a disciplined path for no longer being relied upon.
10.3.10 Periodic Review, Assurance, and Register Update Requirements. 10.3.10(a) GCRI Canada shall maintain periodic review, assurance, and register update requirements for the Public-Good Technical Asset Register proportionate to asset materiality, public-good value, external reliance, interface importance, public-safe status, security risk, dependency risk, rights risk, data sensitivity, public authority sensitivity, community safeguard sensitivity, protected knowledge sensitivity, export-control sensitivity, sanctions sensitivity, controlled-technology sensitivity, finance-boundary risk, procurement-boundary risk, provider-neutrality risk, sponsor non-control risk, and correction dependency.
10.3.10(b) Periodic review shall assess whether each material asset remains accurate, current, useful, lawful, rights-cleared, license-compliant, dependency-aware, secure, maintained, public-safe, properly classified, properly released, properly restricted where required, properly bounded, properly interfaced, properly documented, properly corrected, and properly archived where applicable.
10.3.10(c) Assurance shall review asset purpose, scope, audience, permitted uses, prohibited uses, boundary language, public-safe status, classification, handling class, access class, security class, data sensitivity, export-control sensitivity, protected knowledge status, license, IP status, third-party rights, contributor terms, patent status, dependency status, standards-support status, release status, known issues, vulnerability status, SBOM status, build status, maintenance status, interface records, correction path, supersession chain, withdrawal path, vulnerability disclosure path, archive path, and dependency notices.
10.3.10(d) Register update shall be required when an asset is created, adopted, contributed, forked, imported, released, made public-safe, opened, restricted, materially changed, re-versioned, relicensed, transferred, interface-routed, public authority-referenced, GRF-routed, GRA-routed, Protocol Authority-routed, Nexus Observatory-routed, Truth Engine-routed, Rails-routed, Grid-routed, Academy-routed, National Company-routed, Project SPV-routed, provider-routed, sponsor-routed, host-routed, operator-routed, publicly cited, corrected, superseded, deprecated, withdrawn, retracted, retired, archived, or closed out.
10.3.10(e) Review findings may require correction, reclassification, access restriction, release restriction, license correction, dependency replacement, vulnerability remediation, SBOM update, build correction, documentation update, boundary-language update, public-safe review, public authority reference correction, community safeguard update, protected knowledge restriction, provider reference correction, sponsor reference correction, host reference correction, interface update, public claim correction, training update, assurance update, Board or committee reporting, supersession, withdrawal, retraction, retirement, archive, or closeout.
10.3.10(f) Material findings shall be escalated to the Board or responsible committee where they affect evidence integrity, public-safe publication, cybersecurity, privacy, sovereign data, protected knowledge, public authority boundaries, finance boundaries, procurement boundaries, provider neutrality, sponsor non-control, host boundaries, operator boundaries, IP rights, export controls, sanctions, controlled technology, institutional reputation, public claims, or GCRI Canada’s non-executing role.
10.3.10(g) Public-safe summaries of register status, asset catalogues, release notes, dependency notices, correction notices, vulnerability notices, supersession notices, withdrawal notices, retraction notices, deprecation notices, or archive notices may be prepared where they can be released without unsafe disclosure, vulnerability exposure, credentials exposure, protected knowledge exposure, public authority confusion, finance overclaim, procurement implication, provider preference, sponsor validation, host approval implication, operator instruction implication, IP breach, privacy harm, cybersecurity harm, sovereign data harm, legal breach, or execution implication.
10.3.10(h) Periodic review, assurance, register updates, release notes, public-safe summaries, dependency notices, correction notices, vulnerability notices, supersession notices, withdrawal notices, retraction notices, deprecation notices, archive notices, Board reports, committee reports, and closeout records shall not create certification, recognition, finance-readiness, public authority decision, regulatory finding, procurement approval, security certification, provider endorsement, sponsor approval, host approval, operator approval, community consent, Indigenous consent, rating, guarantee, public warning, emergency command, protocol effect, professional certification, operational clearance, legal status, market authority, infrastructure operation, deployment approval, national authority, regional authority, GRF maturity record, GRA finance-readiness, Docket approval, Grid maturity record, Rails finance authority, Academy certification, or execution consequence by default.
10.3.10(i) The controlling rule shall be that the Public-Good Technical Asset Register is trustworthy only while it is actively reviewed, assured, updated, corrected, and capable of showing whether an asset may be used, by whom, for what purpose, under what restrictions, with what risks, and according to what version.
10.4 Reference Architectures
10.4.1 Reference Architectures as Public-Good Technical Guidance, Not Mandatory Implementation by Default. 10.4.1(a) GCRI Canada may steward reference architectures as public-good technical guidance for evidence, methods, observability, ontology, interoperability, verifiable compute, verifiable intelligence, public-safe publication, correction, assurance, and role-separated Nexus implementation support, provided that such reference architectures remain non-executing, non-mandatory by default, source-lined, versioned, reviewable, public-safe where released, restricted where required, and correctionable.
10.4.1(b) A reference architecture may describe recommended, illustrative, reusable, comparative, modular, layered, federated, sovereign-compatible, security-aware, public-safe, or interoperability-oriented design patterns for systems, records, data flows, evidence flows, compute flows, model flows, dashboards, maps, APIs, rooms, repositories, interfaces, correction paths, assurance paths, and institutional boundaries.
10.4.1(c) Reference architectures shall be understood as guidance for disciplined technical design and institutional interpretation, not as binding implementation mandates, procurement specifications, public authority standards, regulatory requirements, finance-readiness criteria, certification criteria, recognition criteria, Protocol Authority rules, provider qualification rules, host approval rules, operator instructions, deployment approvals, operational clearances, public warning structures, emergency command structures, or execution instructions by default.
10.4.1(d) Reference architectures may be used to support shared understanding among GCRI Canada, GCRI US, The Global Risks Forum (GRF), The Global Risks Alliance (GRA), Nexus Standards / Protocol Authority, Nexus Network, Nexus Observatory, Nexus Truth Engine, Nexus Risk Management, Nexus Rails, Nexus Grid, Nexus Docket, Nexus Academy, Nexus Universe, Regional Nexus Consortiums, National Nexus Consortiums, National Companies, Project SPVs, public authorities, universities, communities, providers, sponsors, hosts, operators, and capital readers, but such use shall preserve legal separateness, role separation, public-good stack and enterprise stack separation, and non-execution by GCRI Canada.
10.4.1(e) A reference architecture shall not be treated as adopted, approved, authoritative, public-safe, open, restricted, superseded, withdrawn, retired, archived, or available for a material interface unless its status is recorded in the Public-Good Technical Asset Register or another approved linked record sufficient to identify title, version, steward, purpose, audience, permitted uses, prohibited uses, public-safe status, access class, handling class, dependencies, limitations, and correction path.
10.4.1(f) Reference architectures shall not be self-validating merely because they are technical, open, public-good, sponsor-supported, provider-contributed, academically informed, public authority-referenced, repository-hosted, diagrammed, dashboarded, standards-adjacent, proof-linked, cryptographically anchored, or included in an Evidence Pack, Decision Pack, Academy material, Nexus Universe material, or public-safe summary.
10.4.1(g) Where a competent actor elects to adopt, adapt, implement, fund, procure, regulate, certify, recognize, finance, deploy, operate, or execute systems influenced by a reference architecture, such action shall arise only through that competent actor’s own authority, process, records, accountability, liability, governance instruments, safeguards, and correction path, and not through GCRI Canada’s publication or stewardship of the reference architecture by implication.
10.4.1(h) The controlling rule shall be that reference architectures may guide design and interoperability, but they do not compel implementation, approve systems, confer status, allocate finance, determine procurement, regulate actors, operate infrastructure, issue warnings, command response, or execute projects by default.
10.4.2 Reference Architectures for Evidence Rail, Nexus Observatory, Nexus Truth Engine, Verifiable Compute, Sovereign Data, Controlled Rooms, Public-Safe Dashboards, Secure Release, and Interoperability. 10.4.2(a) GCRI Canada may steward reference architectures for the evidence rail, Nexus Observatory, Nexus Truth Engine, verifiable compute, verifiable intelligence, sovereign data, compute-to-data environments, secure enclaves, controlled rooms, data rooms, clean rooms, no-download rooms, public-safe dashboards, public-safe maps, secure release, repository governance, proof receipts, correction workflows, assurance workflows, and interoperability across role-separated Nexus actors.
10.4.2(b) Evidence rail reference architectures may describe source intake, source authority, source comparison, evidence classification, data classification, source lineage, evidence custody, confidence treatment, uncertainty treatment, limitation treatment, contradiction handling, dispute handling, public-safe output routing, Evidence Pack assembly, Decision Pack assembly, correction routing, dependency notices, assurance review, and archive treatment.
10.4.2(c) Nexus Observatory reference architectures may describe Nodes, Hubs, Clusters, Hotspots, Regional Observatory Clusters, National Dense Nexus Cores, sensors, AI-RAN interfaces, O-RAN interfaces, private wireless interfaces, DePIN interfaces, geospatial layers, cyber telemetry, digital twins, dashboards, maps, APIs, degraded-mode awareness, host readiness, community safeguards, public authority learning, public-safe publication, incident handling, records, registers, and assurance.
10.4.2(d) Nexus Truth Engine reference architectures may describe confidence-aware, limitation-aware, source-lined, reviewable, challengeable, correctionable, AI-assisted, human-reviewed, non-oracle evidence infrastructure for source comparison, corroboration, contradiction, dispute handling, confidence scoring, uncertainty treatment, output classes, auditability, inference records, proof receipts, and public-safe outputs.
10.4.2(e) Verifiable compute and verifiable intelligence reference architectures may describe compute workload records, compute environment records, model records, dataset records, system cards, benchmark cards, inference records, human review, privacy review, cyber review, safeguards review, proof receipts, hashing, signing, timestamping, tamper-evidence, reproducibility notes where appropriate, output review, classification, public-safe treatment, and correction.
10.4.2(f) Sovereign data and controlled-room reference architectures may describe data classification, lawful basis, purpose limitation, minimization, access controls, role-based access, logging, retention, deletion, sealing, archival, legal hold, data residency, localization, cross-border review, compute-to-data treatment, secure enclaves, confidential computing, air-gapped environments, no-download rooms, public authority rooms, community rooms, protected knowledge rooms, provider rooms, sponsor rooms, host rooms, and operator rooms.
10.4.2(g) Public-safe dashboard and visualization reference architectures may describe source-lined displays, update status, timestamps, versions, confidence display, uncertainty display, limitation display, stale-data treatment, public-safe omissions, redaction, aggregation, generalization, safe-location treatment, boundary language, export controls, screenshot controls, API controls, misuse monitoring, correction notices, withdrawal notices, supersession notices, and archive status.
10.4.2(h) Secure release and interoperability reference architectures may describe repository controls, branch protection, code review, dependency review, SBOM practices, secret scanning, vulnerability management, patch management, release notes, license review, API versioning, schema versioning, semantic crosswalks, data contracts, interface specifications, proof receipt interfaces, dependency notices, deprecation, supersession, withdrawal, and correction propagation.
10.4.2(i) Reference architectures described in this Section shall preserve no-certification, no-recognition, no-finance, no-procurement, no-public-authority, no-public-warning, no-emergency-command, no-provider-endorsement, no-sponsor-control, no-host-approval, no-operator-instruction, no-protocol-effect unless separately created by competent Protocol Authority, no-professional-certification, no-deployment-approval, no-operational-clearance, and no-execution language where material.
10.4.2(j) The controlling rule shall be that reference architectures may show how public-good technical disciplines can fit together, but architectural coherence shall not be mistaken for approval, authority, implementation, finance, procurement, certification, recognition, protocol effect, or execution.
10.4.3 Reference Architectures for AI, AI-RAN, O-RAN, Private Wireless, DePIN, Cybersecurity, Digital Twins, Sensors, Geospatial Systems, Sovereign Compute, and Mission-Critical Infrastructure. 10.4.3(a) GCRI Canada may steward reference architectures for AI, machine learning, statistical systems, simulation systems, generative AI, agentic AI, retrieval systems, embedding systems, AI-RAN, O-RAN, private wireless, telecommunications-adjacent systems, DePIN, distributed infrastructure, cybersecurity, cyber-physical telemetry, digital twins, sensors, geospatial systems, Earth observation, sovereign compute, high-performance compute, edge compute, mission-critical infrastructure, climate, nature, water, energy, food, health, supply chain, public trust, and other exponential or mission-critical technology domains.
10.4.3(b) AI reference architectures may describe model governance, Model Registers, Model Cards, Dataset Cards, System Cards, Benchmark Cards, evaluation harnesses, prompt and query records, retrieval records, embedding records, inference records, human review, hallucination controls, bias controls, drift controls, agentic AI controls, AI incident handling, public-safe AI output review, model restriction, suspension, retirement, deprecation, and correction.
10.4.3(c) AI-RAN, O-RAN, private wireless, and telecommunications-adjacent reference architectures may describe network evidence, telemetry evidence, radio signal evidence, edge intelligence, networked sensing, signal quality, calibration, timing, location, noise, interference, spoofing, metadata sensitivity, public authority sensitivity, infrastructure sensitivity, cybersecurity controls, provider controls, host controls, operator controls, public-safe disclosure controls, and correction.
10.4.3(d) DePIN and distributed infrastructure reference architectures may describe device identity, hardware identity, location claims, uptime claims, capacity claims, coverage claims, service claims, proof-of-competence, proof-of-coverage, proof-of-availability, proof-of-integrity, proof-of-observation, mission-specific proof methods, ledger relationships, token relationships where any, proof receipts, spoof detection, tamper detection, fraud detection, incentive risk, no-token-as-authority controls, and correction.
10.4.3(e) Cybersecurity and cyber-physical reference architectures may describe identity and access management, segmentation, environment separation, least privilege, logging, monitoring, security telemetry, incident detection, vulnerability management, patch management, exposure reduction, secure configuration, repository security, API security, dashboard security, sensor security, edge security, AI-RAN security, DePIN security, compute security, key management, token management, secrets management, credential controls, vendor review, provider review, host review, cloud review, incident response, recovery, notification, post-incident review, and assurance.
10.4.3(f) Digital twin and simulation reference architectures may describe source inputs, assumptions, calibration, validation, sensitivity treatment, boundary conditions, model identity, model version, dataset identity, compute workload, compute environment, scenario class, public-safe visualization, dashboard links, map links, API links, false-precision controls, stale-assumption controls, public authority controls, community safeguards, protected knowledge controls, and correction.
10.4.3(g) Sensor and geospatial reference architectures may describe sensor identity, custody, calibration, configuration, maintenance, firmware, location or safe-location treatment, timing, data quality, signal quality, reference sensors, sensor fusion, missing data, spoof handling, public-safe mapping, geospatial precision, Earth observation, GIS layers, sensitive-site treatment, infrastructure-sensitive treatment, re-identification controls, group harm controls, public authority review, community review, protected knowledge treatment, and map correction.
10.4.3(h) Sovereign compute and mission-critical infrastructure reference architectures may describe compute location, jurisdiction, provider, custodian, secure enclave status, confidential computing, air-gap status, compute-to-data treatment, sovereign data zones, backup, disaster recovery, continuity, degraded-mode awareness, infrastructure-sensitive controls, public authority controls, operator controls, host controls, cybersecurity controls, cross-border controls, and decommissioning.
10.4.3(i) Reference architectures for high-consequence technology domains shall not be represented as safety certification, security certification, infrastructure approval, public authority approval, telecommunications authorization, spectrum authorization, public warning system, emergency command system, finance-readiness, procurement approval, provider ranking, sponsor validation, host approval, operator instruction, protocol effect, deployment approval, operational clearance, legal status, market authority, or execution readiness by default.
10.4.3(j) The controlling rule shall be that reference architectures for advanced and mission-critical technologies must make evidence, safeguards, and limits explicit because technical sophistication increases, rather than reduces, the need for non-execution, public-safe publication, role separation, and correctionability.
10.4.4 Reference Architecture Scope, Assumptions, Dependencies, Exclusions, and Limitations. 10.4.4(a) Each material reference architecture shall identify its scope, assumptions, dependencies, exclusions, limitations, intended audience, intended use, prohibited use, public-safe status, access class, handling class, technology domain, risk domain, jurisdictional context where material, data class implications, evidence class implications, output class implications, and correction path.
10.4.4(b) Scope statements shall identify what the reference architecture covers, including relevant systems, actors, interfaces, records, data flows, evidence flows, compute flows, model flows, public-safe outputs, assurance paths, correction paths, and institutional boundaries, and shall also identify what is intentionally outside scope.
10.4.4(c) Assumption records shall identify technical assumptions, institutional assumptions, legal assumptions, public authority assumptions, public-safe assumptions, data assumptions, cybersecurity assumptions, sovereign data assumptions, AI-use assumptions, provider assumptions, sponsor assumptions, host assumptions, operator assumptions, community safeguard assumptions, protected knowledge assumptions, finance-boundary assumptions, procurement-boundary assumptions, and protocol-boundary assumptions.
10.4.4(d) Dependency records shall identify software dependencies, data dependencies, model dependencies, API dependencies, schema dependencies, ontology dependencies, compute dependencies, cloud dependencies, repository dependencies, dashboard dependencies, map dependencies, security dependencies, cryptographic dependencies, provider dependencies, sponsor dependencies, host dependencies, public authority dependencies, community safeguard dependencies, protected knowledge dependencies, license dependencies, standards-adjacent dependencies, and correction dependencies.
10.4.4(e) Exclusions shall identify systems, uses, decisions, actor roles, authority functions, finance functions, procurement functions, certification functions, recognition functions, protocol functions, operations, deployments, warnings, commands, or execution consequences not created by the reference architecture, including any excluded public authority role, emergency role, finance role, procurement role, provider role, sponsor role, host role, operator role, National Company role, Project SPV role, or Protocol Authority role.
10.4.4(f) Limitation statements shall identify methodological limits, data limits, evidence limits, interoperability limits, validation limits, simulation limits, model limits, security limits, privacy limits, cross-border limits, sovereign data limits, public-safe limits, community safeguard limits, protected knowledge limits, public authority limits, provider-neutrality limits, sponsor non-control limits, finance limits, procurement limits, standards-adjacent limits, and correction limits.
10.4.4(g) Where scope, assumptions, dependencies, exclusions, or limitations are unknown, disputed, changing, unvalidated, unreviewed, stale, public-safe sensitive, or context-dependent, the reference architecture shall be marked accordingly and shall not be used as if complete, final, validated, public-safe, mandatory, certifying, finance-ready, procurement-ready, protocol-effective, deployment-ready, operationally cleared, or execution-ready.
10.4.4(h) The controlling rule shall be that a reference architecture without clear scope, assumptions, dependencies, exclusions, and limitations is not reliable public-good guidance, because architecture without boundaries invites overclaim.
10.4.5 Reference Architecture Public-Safe and Restricted Annex Treatment. 10.4.5(a) GCRI Canada may structure reference architectures into public-safe summaries, public-safe diagrams, controlled annexes, restricted annexes, technical annexes, public authority annexes, community-sensitive annexes, protected knowledge annexes, cyber-sensitive annexes, infrastructure-sensitive annexes, finance-boundary annexes, procurement-boundary annexes, provider-sensitive annexes, sponsor-sensitive annexes, host-sensitive annexes, operator-sensitive annexes, correction annexes, and archive records.
10.4.5(b) Public-safe reference architecture summaries shall include only information that can be externally released without unsafe disclosure, vulnerability exposure, credentials exposure, secrets exposure, key exposure, token exposure, infrastructure-sensitive exposure, public authority confusion, public warning implication, emergency-command implication, finance overclaim, procurement implication, certification implication, recognition implication, protocol implication, provider preference, sponsor validation, host approval implication, operator instruction implication, community harm, protected knowledge exposure, privacy harm, cybersecurity harm, sovereign data harm, IP breach, export-control breach, sanctions issue, controlled-technology exposure, legal breach, or execution implication.
10.4.5(c) Controlled annexes may include more detailed architecture information for defined audiences under recorded access, handling, confidentiality, public-safe, cybersecurity, public authority, community safeguard, protected knowledge, provider-neutrality, sponsor non-control, host-boundary, operator-boundary, finance-boundary, procurement-boundary, and correction controls.
10.4.5(d) Restricted annexes shall be used where architecture materials include or may reveal credentials, secrets, keys, tokens, vulnerabilities, exploit-sensitive information, incident telemetry, security controls, network topology, infrastructure dependencies, facility locations, precise geospatial information, public authority restricted information, personal data, health-sensitive information, cyber-sensitive information, infrastructure-sensitive information, community-protected information, Indigenous or protected knowledge, commercially sensitive information, export-controlled information, sanctions-sensitive information, controlled technology, or other restricted information.
10.4.5(e) Public-safe summaries shall not imply that controlled annexes, restricted annexes, withheld layers, omitted diagrams, generalized components, redacted dependencies, delayed information, or responsible non-disclosure do not exist. Where material, public-safe summaries shall state that certain architecture details have been withheld, generalized, or restricted for public-safe, legal, privacy, cybersecurity, sovereign data, public authority, community, protected knowledge, provider, sponsor, host, operator, or safety reasons.
10.4.5(f) Annex classification shall not be used to conceal unfavorable evidence, dependency risk, sponsor influence, provider influence, vendor lock-in, public authority ambiguity, finance overclaim, procurement implication, certification implication, recognition implication, protocol implication, cybersecurity weakness, public-safe defect, or correction obligation. Restrictions shall be used for rights, law, safety, security, sovereignty, protected knowledge, public-safe discipline, and evidence integrity.
10.4.5(g) Where a reference architecture cannot be safely published even in summarized form without distorting meaning, exposing restricted information, creating public authority confusion, enabling misuse, creating finance overclaim, creating procurement implication, creating provider preference, creating sponsor validation, creating host approval implication, creating protocol overclaim, or creating execution implication, GCRI Canada shall refuse publication or release only a limited public-safe statement.
10.4.5(h) The controlling rule shall be that reference architecture publication must reveal enough to support public-good learning and interoperability while withholding enough to protect people, systems, public authorities, communities, knowledge, security, and correctionability.
10.4.6 Reference Architecture Use by Public Authorities, Providers, Hosts, National Companies, Project SPVs, Universities, and Nexus Entities. 10.4.6(a) Public authorities, providers, vendors, hosts, operators, National Companies, Project SPVs, universities, communities, sponsors, GRF, GRA, Protocol Authority, Nexus entities, Regional Nexus Consortiums, National Nexus Consortiums, capital readers, procurement actors, and other actors may reference, study, adapt, implement, test, compare, teach, or otherwise use GCRI Canada reference architectures only within recorded permitted-use boundaries, public-safe limits, rights limits, access limits, and correction paths.
10.4.6(b) Public authority use of a reference architecture shall not convert the reference architecture into official guidance, regulatory requirement, compliance determination, enforcement position, public warning system, emergency command system, procurement requirement, funding requirement, public finance approval, public-law instrument, public authority adoption, or delegation to GCRI Canada unless separately and expressly created by the competent public authority through its own lawful process and records.
10.4.6(c) Provider or vendor use of a reference architecture shall not create provider endorsement, preferred status, procurement advantage, certification, recognition, finance-readiness, public authority endorsement, protocol effect, market entitlement, deployment approval, operational clearance, security certification, conformance status, or execution consequence by GCRI Canada.
10.4.6(d) Host or operator use of a reference architecture shall not create host approval, site approval, operator approval, community consent, Indigenous consent where applicable, public authority approval, procurement readiness, finance-readiness, provider preference, sponsor approval, protocol effect, deployment approval, operational clearance, infrastructure operation, public warning, emergency command, or execution consequence by GCRI Canada.
10.4.6(e) National Company or Project SPV use of a reference architecture shall preserve legal separateness, public-good stack and enterprise stack separation, no-execution-by-GCRI language, no-project-approval language, no-finance-readiness-by-GCRI language, no-procurement-by-GCRI language, no-provider-selection-by-GCRI language, no-host-approval-by-GCRI language, no-deployment-approval-by-GCRI language, and correction path.
10.4.6(f) University or research use of a reference architecture shall preserve source attribution, rights, public-safe limits, privacy, cybersecurity, sovereign data, protected knowledge, community safeguards, public authority boundaries, provider neutrality, sponsor non-control, research ethics where applicable, and correctionability, and shall not imply institutional approval, professional certification, public authority approval, procurement qualification, finance-readiness, or execution status.
10.4.6(g) Nexus entity use of a reference architecture shall preserve the relevant role separation. GRF use shall not create recognition by GCRI Canada; GRA use shall not create finance-readiness by GCRI Canada; Protocol Authority use shall not create protocol effect by GCRI Canada; Grid use shall not create maturity record by GCRI Canada; Docket use shall not create approval by GCRI Canada; Rails use shall not create finance or execution authority by GCRI Canada; Academy use shall not create professional certification by GCRI Canada; and Observatory or Truth Engine use shall not create official truth, public warning, public authority decision, or execution consequence by GCRI Canada.
10.4.6(h) Actors using reference architectures shall preserve version, source, public-safe status, limitations, permitted uses, prohibited uses, boundary language, correction status, supersession status, withdrawal status, retraction status where applicable, and archive status in any downstream use, quotation, implementation material, procurement material, finance material, public authority material, provider material, host material, Academy material, media material, or public claim.
10.4.6(i) Where downstream use of a reference architecture creates overclaim, misquotation, mistranslation, public authority confusion, finance implication, procurement implication, certification implication, recognition implication, provider preference, sponsor validation, host approval implication, operator instruction implication, protocol implication, professional certification implication, public warning implication, emergency-command implication, or execution implication, GCRI Canada shall correct, relabel, restrict, withdraw, reissue, request removal of misleading references, notify affected interfaces where appropriate, suspend affected use where within its control, or pursue contractual or legal remedies where appropriate.
10.4.6(j) The controlling rule shall be that reference architectures may travel across institutions only with their boundaries attached.
10.4.7 Reference Architecture Does Not Create Certification, Procurement Preference, Public Authority Approval, Finance-Readiness, Protocol Entitlement, or Execution Authority by Default. 10.4.7(a) No reference architecture, reference diagram, architecture note, technical baseline, architecture profile, architecture template, interoperability profile, public-safe summary, controlled annex, restricted annex, evidence display, dashboard, map, API, implementation pattern, demonstration, simulation, lab, Nexus Universe display, Academy material, Evidence Pack, Decision Pack, proof receipt, assurance finding, correction record, or public claim stewarded by GCRI Canada shall create certification, procurement preference, public authority approval, finance-readiness, protocol entitlement, deployment approval, operational clearance, infrastructure operation, public warning, emergency command, legal status, market authority, or execution authority by default.
10.4.7(b) Alignment with a reference architecture shall not be described by GCRI Canada as certified, approved, recognized, compliant, conformance-tested, procurement-ready, finance-ready, investment-ready, insurance-ready, public authority-approved, public-law-compliant, provider-preferred, sponsor-approved, host-approved, operator-approved, protocol-effective, Nexus-compatible, deployment-approved, operationally cleared, market-ready, safe, secure, resilient, or execution-ready except where a competent separate actor has created such status through its own authority and records and GCRI Canada’s materials accurately describe that separate status without overclaim.
10.4.7(c) A public authority’s review, attendance, comment, data contribution, dashboard access, map access, reference, non-objection, funding interest, procurement interest, public finance interest, regulator-listening participation, emergency-management participation, public health participation, public safety participation, or use of a reference architecture shall not create public authority adoption, official guidance, regulatory determination, compliance determination, enforcement position, procurement approval, funding approval, public finance approval, public warning, emergency command, public-law status, certification, recognition, finance-readiness, provider endorsement, sponsor approval, host approval, operator instruction, protocol effect, deployment approval, legal status, market authority, or execution consequence by implication.
10.4.7(d) Provider use, vendor use, sponsor support, host use, operator use, National Company use, Project SPV use, capital-reader use, insurer use, lender use, investor use, procurement actor use, university use, or community use of a reference architecture shall not create endorsement, approval, consent, certification, recognition, finance-readiness, procurement approval, provider preference, sponsor validation, host approval, operator instruction, protocol effect, professional certification, deployment approval, operational clearance, market signal, or execution consequence by implication.
10.4.7(e) A reference architecture may be used by a competent Protocol Authority as an input to protocol work only where that Protocol Authority separately adopts, modifies, rejects, supersedes, or otherwise processes the input under its own authority and records. GCRI Canada’s reference architecture shall not confer protocol effect, conformance status, Nexus-compatible status, standards compliance, provider qualification, host qualification, procurement qualification, finance qualification, or market entitlement by default.
10.4.7(f) A reference architecture may be used by GRA, Nexus Rails, capital readers, insurers, lenders, investors, public finance bodies, National Companies, or Project SPVs as non-advisory technical evidence or learning input only within recorded limits. It shall not create finance-readiness, investment advice, insurance approval, lending approval, underwriting approval, rating, guarantee, bankability, fundability, public finance approval, capital allocation, project approval, procurement approval, deployment approval, operational clearance, or execution consequence by GCRI Canada.
10.4.7(g) A reference architecture may be used by GRF or Nexus Grid as evidence input only within recorded limits. It shall not create recognition, standing, claims approval, maturity record, public-facing legitimacy, registry status, professional certification, competence recognition, or public maturity by GCRI Canada.
10.4.7(h) Any prohibited use, implication, or downstream claim shall be corrected through relabeling, boundary-language update, public-safe clarification, controlled notice, withdrawal, retraction, supersession, archive marking, removal request, interface restriction, or other corrective action proportionate to risk.
10.4.7(i) The controlling rule shall be that reference architecture alignment is not status; it is, at most, a recorded relationship to a design pattern whose meaning depends on source, version, scope, assumptions, limits, review, and correction.
10.4.8 Reference Architecture Versioning, Review, Update, Supersession, and Withdrawal. 10.4.8(a) GCRI Canada shall maintain versioning, review, update, supersession, withdrawal, retraction where necessary, deprecation, retirement, archive, dependency notice, and closeout methods for material reference architectures.
10.4.8(b) Version records shall identify reference architecture title or identifier, version, release date, steward, custodian, repository or storage location, prior version, successor version where any, change summary, changed assumptions, changed dependencies, changed scope, changed exclusions, changed limitations, changed public-safe status, changed security status, changed data sensitivity, changed rights status, changed interface status, changed correction path, and archive treatment.
10.4.8(c) Review shall assess technical correctness, public-good utility, evidence integrity, interoperability, rights status, dependency status, cybersecurity status, data governance status, public-safe status, public authority boundary, community safeguards, protected knowledge status, provider neutrality, sponsor non-control, host boundary, operator boundary, finance boundary, procurement boundary, certification boundary, recognition boundary, protocol boundary, professional certification boundary, correctionability, and public trust.
10.4.8(d) Updates shall be required where a reference architecture becomes technically stale, legally unsupported, rights-defective, license-defective, dependency-defective, security-defective, public-safe-defective, data-defective, public-authority-confusing, community-safeguard-defective, protected-knowledge-defective, provider-captured, sponsor-influenced, vendor-locked, finance-overclaiming, procurement-implying, certification-implying, recognition-implying, protocol-implying, operationally misleading, or correction-defective.
10.4.8(e) Supersession shall identify replacement architecture, changed evidence base, changed technical assumptions, changed dependencies, changed public-safe treatment, changed rights treatment, changed security treatment, changed interface terms, changed boundary language, continuing validity where any, discontinued reliance where any, migration notes where appropriate, and affected dependency notices.
10.4.8(f) Withdrawal shall be used where a reference architecture should no longer be used or relied upon because of material error, unsafe disclosure, public-safe defect, public authority confusion, finance overclaim, procurement implication, certification implication, recognition implication, protocol implication, provider preference, sponsor validation, host approval implication, operator instruction implication, cybersecurity defect, rights defect, protected knowledge exposure, community harm risk, legal defect, export-control issue, sanctions issue, controlled-technology issue, or unresolved correction defect.
10.4.8(g) Retraction shall be used where a reference architecture is materially unsupported, materially misleading, unsafe, improperly published, materially overclaimed, materially harmful, rights-defective, or incapable of correction without continued public-safe risk. Retraction shall preserve records sufficient for accountability, dependency review, learning, and lawful obligations while preventing continued reliance.
10.4.8(h) Deprecation, retirement, and archive records shall identify whether continued use is discouraged, prohibited, restricted, replaced, historically preserved, or permitted only for audit, correction, legal hold, dependency review, or institutional memory, together with access limits, citation limits, continuing prohibited uses, and closeout status.
10.4.8(i) Versioning, review, update, supersession, withdrawal, retraction, deprecation, retirement, archive, dependency notice, and closeout records shall not create certification, recognition, finance-readiness, public authority decision, regulatory finding, procurement approval, security certification, provider endorsement, sponsor approval, host approval, operator approval, rating, guarantee, public warning, emergency command, protocol effect, professional certification, operational clearance, legal status, market authority, infrastructure operation, deployment approval, or execution consequence by default.
10.4.8(j) The controlling rule shall be that reference architectures must change when evidence, law, rights, dependencies, safeguards, or public meaning change; architectural continuity shall never be allowed to preserve stale authority or unsafe reliance.
10.4.9 Reference Architecture Misuse, Overclaim, and Correction. 10.4.9(a) GCRI Canada shall maintain methods for detecting, reviewing, correcting, and responding to misuse, overclaim, misquotation, mistranslation, out-of-context use, unauthorized reuse, unsafe publication, public authority confusion, finance overclaim, procurement implication, certification implication, recognition implication, protocol implication, provider preference, sponsor validation, host approval implication, operator instruction implication, professional certification implication, public warning implication, emergency-command implication, market signal implication, or execution implication involving reference architectures.
10.4.9(b) Misuse may include any statement, diagram, dashboard, map, API, report, website, presentation, media item, sponsor material, provider material, host material, operator material, public authority material, finance-facing material, procurement-facing material, Academy material, National Company material, Project SPV material, GRF material, GRA material, Protocol Authority material, Nexus entity material, repository material, public claim, or private claim that overstates the status, authority, maturity, approval, safety, security, finance meaning, procurement meaning, protocol meaning, certification meaning, recognition meaning, or execution meaning of a reference architecture.
10.4.9(c) Overclaim includes describing a reference architecture or alignment with it as certified, recognized, approved, adopted, official, public authority-endorsed, public-law-compliant, procurement-ready, finance-ready, investment-ready, insurance-ready, rated, guaranteed, provider-preferred, sponsor-approved, host-approved, operator-approved, protocol-effective, Nexus-compatible, professionally certified, deployment-approved, operationally cleared, market-ready, safe, secure, resilient, public-warning-ready, emergency-command-ready, or execution-ready where such status has not been separately and lawfully created by a competent actor and accurately recorded.
10.4.9(d) Misuse review shall identify the actor, claim, channel, audience, asset version, source material, context, public-safe status, public authority implication, finance implication, procurement implication, certification implication, recognition implication, protocol implication, provider implication, sponsor implication, host implication, operator implication, community implication, protected knowledge implication, cybersecurity implication, legal implication, dependency risk, correction urgency, and notice path.
10.4.9(e) Corrective action may include boundary-language correction, public-safe clarification, controlled clarification, relabeling request, logo removal, quote removal, diagram replacement, dashboard restriction, map restriction, API restriction, repository correction, documentation correction, citation correction, version correction, misuse notice, public authority notice, provider notice, sponsor notice, host notice, operator notice, GRF notice, GRA notice, Protocol Authority notice, National Company notice, Project SPV notice, legal notice, interface suspension, withdrawal, retraction, supersession, archive marking, or termination of access where appropriate.
10.4.9(f) Correction shall be proportionate, public-safe, source-lined where appropriate, non-defamatory, non-regulatory, non-public-warning unless issued by a competent public authority, non-financial, non-procurement, non-certifying, non-recognizing, non-protocol-conferring, non-provider-preferential, non-sponsor-validating, non-host-approving, non-operator-commanding, non-executing, and correction-focused.
10.4.9(g) Where misuse affects downstream records, public-safe outputs, Evidence Packs, Decision Packs, dashboards, maps, APIs, Academy materials, public authority materials, provider materials, sponsor materials, host materials, operator materials, capital-reader materials, procurement materials, finance materials, public claims, or media materials, GCRI Canada shall issue dependency notices or correction signals where appropriate.
10.4.9(h) Failure to correct known misuse may itself be treated as a correction failure, assurance finding, incident, or Board-reportable matter where material to evidence integrity, public-safe publication, role separation, public authority boundaries, finance boundaries, procurement neutrality, provider neutrality, sponsor non-control, host boundaries, operator boundaries, protocol boundaries, protected knowledge, cybersecurity, legal obligations, or public trust.
10.4.9(i) Reference architecture misuse and correction records shall not create certification, recognition, finance-readiness, public authority decision, regulatory finding, procurement approval, provider endorsement, sponsor finding, host finding, operator finding, rating, guarantee, public warning, emergency command, protocol effect, professional certification, operational clearance, legal status, market authority, infrastructure operation, deployment approval, or execution consequence by default.
10.4.9(j) The controlling rule shall be that reference architectures must be corrected wherever their public meaning drifts from bounded guidance into status, authority, finance, procurement, certification, recognition, protocol effect, or execution.
10.4.10 Reference Architecture Records and Interface Logs. 10.4.10(a) GCRI Canada shall maintain, or cause to be maintained, reference architecture records and interface logs for material reference architectures stewarded, released, restricted, shared, routed, corrected, superseded, withdrawn, retracted, retired, archived, or used by GCRI Canada.
10.4.10(b) Reference architecture records shall identify architecture title or identifier, asset class, purpose, scope, technology domain, risk domain, intended audience, version, steward, custodian, owner where known, repository or storage location, release status, public-safe status, access class, handling class, data sensitivity, evidence sensitivity, security class, rights status, license status, third-party rights, contributor terms, dependency status, assumptions, exclusions, limitations, permitted uses, prohibited uses, boundary language, review status, assurance status, correction path, supersession path, withdrawal path, retraction path where applicable, archive path, and closeout status.
10.4.10(c) Interface logs shall identify sending interface, receiving interface, date, purpose, materials shared, materials received, version, access class, handling class, public-safe status, data class, evidence class, output class, IP status, license status, security status, permitted use, prohibited use, public authority boundary, finance boundary, procurement boundary, certification boundary, recognition boundary, protocol boundary, provider-neutrality boundary, sponsor non-control boundary, host boundary, operator boundary, community safeguard boundary, protected knowledge boundary, correction path, dependency path, notice path, and closeout path.
10.4.10(d) Public authority interface logs shall identify capacity classification, official or non-official status, data contribution records, dashboard or map access where any, review status, reference approval where applicable, logo or mark permissions where any, quote permissions where any, public-safe review where required, non-delegation language, non-endorsement language, no-public-warning language, no-emergency-command language, no-regulatory-determination language, no-procurement language, no-funding language, no-public-finance language, and correction path.
10.4.10(e) Provider, sponsor, host, and operator interface logs shall identify actor role, contribution, access, data, software, equipment, compute, dashboard, map, API, staff time, expertise, facility, public claims limits, conflict status, provider-neutrality controls, sponsor non-control controls, host-boundary controls, operator-boundary controls, no-endorsement language, no-procurement language, no-finance language, no-certification language, no-recognition language, no-protocol-effect language, no-execution language, and correction path.
10.4.10(f) GRF, GRA, Protocol Authority, Nexus Observatory, Nexus Truth Engine, Nexus Rails, Nexus Grid, Nexus Docket, Nexus Academy, Nexus Universe, National Company, Project SPV, university, community, and capital-reader interface logs shall preserve the specific role boundary applicable to the receiving interface and shall attach source, version, public-safe status, confidence where relevant, uncertainty where relevant, limitations, permitted uses, prohibited uses, correction path, dependency path, and notice path.
10.4.10(g) Correction records shall identify corrected architecture, corrected version, corrected diagram, corrected annex, corrected public-safe summary, corrected interface log, corrected public authority reference, corrected provider reference, corrected sponsor reference, corrected host reference, corrected operator reference, corrected community reference, corrected protected knowledge treatment, corrected boundary language, prior status, corrected status, effective date, reviewer, affected dependencies, notice decision, access change, archive treatment, and continuing limitations.
10.4.10(h) Reference architecture records shall be linked, where applicable, to the Public-Good Technical Asset Register, Observatory Methods Register, Nexus Truth Engine Methods Register, Evidence Register, Dataset Register, Model Register, System Card Register, Benchmark Card Register, Compute Workload Register, Inference Register, Proof Receipt Register, Dashboard Register, Geospatial and Mapping Register, Digital Twin and Simulation Register, Observatory Evidence Pack Register, Observatory Incident Register, Correction Register, Nexus Universe records, Grid records, Docket records, Rails records, Risk Management records, Academy records, GRF interface records, GRA interface records, Protocol Authority interface records, National Company records, Project SPV records, provider records, sponsor records, host records, operator records, public authority records, community records, university records, media materials, public claims records, assurance records, and archive records.
10.4.10(i) Reference architecture records, interface logs, correction records, dependency notices, public-safe summaries, controlled annexes, restricted annexes, assurance records, release notes, supersession notices, withdrawal notices, retraction notices, archive records, Board reports, committee reports, and closeout records shall not create certification, recognition, finance-readiness, public authority decision, regulatory finding, procurement approval, provider endorsement, sponsor approval, host approval, operator approval, community consent, Indigenous consent, rating, guarantee, public warning, emergency command, protocol effect, professional certification, operational clearance, legal status, market authority, infrastructure operation, deployment approval, national authority, regional authority, GRF maturity record, GRA finance-readiness, Docket approval, Grid maturity record, Rails finance authority, Academy certification, or execution consequence by default.
10.4.10(j) The controlling rule shall be that reference architecture records and interface logs must preserve what architecture was shared, with whom, for what purpose, under what version, under what limits, corrected when, superseded how, and prohibited from becoming what, so that architecture guidance remains guidance and does not become authority, finance, procurement, certification, recognition, protocol effect, or execution by implication.
10.5 Open Technical Baselines
10.5.1 Open Technical Baselines as Public-Good Interoperability and Evidence-Quality Instruments. 10.5.1(a) GCRI Canada may steward Open Technical Baselines as public-good interoperability and evidence-quality instruments intended to support shared understanding, common reference points, source-lineage discipline, methods consistency, public-safe explanation, semantic alignment, technical comparability, secure reuse, correctionability, and role-separated coordination across the Nexus public-good stack.
10.5.1(b) Open Technical Baselines may describe minimum public-good reference points for evidence records, method records, data classification, source comparison, confidence treatment, uncertainty treatment, limitation statements, observability records, ontology records, AI governance records, compute workload records, dataset records, model records, system records, benchmark records, dashboard records, API records, public-safe publication records, correction records, assurance records, interface records, and dependency notices.
10.5.1(c) Open Technical Baselines shall be maintained to improve interoperability among GCRI Canada, GCRI US, The Global Risks Forum (GRF), The Global Risks Alliance (GRA), Nexus Standards / Protocol Authority, Nexus Observatory, Nexus Truth Engine, Nexus Risk Management, Nexus Rails, Nexus Grid, Nexus Docket, Nexus Academy, Nexus Universe, Regional Nexus Consortiums, National Nexus Consortiums, National Companies, Project SPVs, public authorities, universities, communities, providers, sponsors, hosts, operators, capital readers, and other role-separated actors without merging their roles.
10.5.1(d) Open Technical Baselines shall be treated as public-good reference instruments, not as proprietary products, commercial platforms, regulated systems, market infrastructure, public authority systems, procurement tools, finance tools, certification systems, recognition systems, protocol instruments, professional licensing instruments, operating manuals, emergency command instruments, public warning instruments, or execution tools by default.
10.5.1(e) Open Technical Baselines shall be records-valid, versioned, source-lined where applicable, public-safe where released, rights-reviewed, security-reviewed, dependency-aware, law-aware, privacy-aware, cybersecurity-aware, sovereign-data-aware, public-authority-bounded, community-safeguard-aware, protected-knowledge-aware, provider-neutral, sponsor-independent, finance-safe, procurement-safe, non-certifying, non-recognizing, non-protocol-conferring unless separately adopted by competent Protocol Authority, non-executing, and correctionable.
10.5.1(f) Open Technical Baselines shall not be used to imply that an actor, asset, system, provider, host, project, public authority interface, National Company, Project SPV, dashboard, map, API, model, dataset, sensor, AI-RAN system, DePIN system, compute environment, or public-safe output is approved, certified, recognized, finance-ready, procurement-ready, protocol-effective, public authority-adopted, operationally cleared, deployment-approved, safe, secure, resilient, or execution-ready by reason of alignment alone.
10.5.1(g) Where Open Technical Baselines are externally cited, implemented, mapped, translated, embedded, forked, reused, or adapted, their version, scope, public-safe status, limitations, permitted uses, prohibited uses, boundary language, correction path, supersession status, withdrawal status, archive status, and no-endorsement conditions shall travel with them where material.
10.5.1(h) The controlling rule shall be that Open Technical Baselines exist to make public-good evidence and interoperability more reliable, not to create hidden approval, authority, certification, finance, procurement, protocol effect, provider preference, sponsor control, or execution.
10.5.2 Open Technical Baselines for Evidence Records, Methods, Observability, Ontology, AI Governance, Data Governance, Cybersecurity, Secure Release, Public-Safe Publication, and Technical Interfaces. 10.5.2(a) GCRI Canada may steward Open Technical Baselines for evidence records, methods records, observability records, ontology and semantic records, AI governance records, data governance records, cybersecurity records, secure release records, public-safe publication records, correction records, assurance records, and technical interface records.
10.5.2(b) Evidence record baselines may address source identity, source authority, lawful basis or permission treatment where applicable, source lineage, evidence class, data class, output class, access class, handling class, confidence, uncertainty, limitations, corroboration status, contradiction status, stale-data status, reviewer status, public-safe status, permitted uses, prohibited uses, correction path, supersession path, withdrawal path, retraction path where applicable, and archive treatment.
10.5.2(c) Methods baselines may address method purpose, scope, version, steward, assumptions, dependencies, exclusions, limitations, review status, assurance status, source-comparison logic, confidence rules, uncertainty rules, public-safe release thresholds, interface rules, boundary language, correction rules, and retirement or supersession rules.
10.5.2(d) Observability baselines may address Nodes, Hubs, Clusters, Hotspots, Regional Observatory Clusters, National Dense Nexus Cores, sensors, AI-RAN evidence, O-RAN evidence, private wireless evidence, DePIN evidence, geospatial evidence, cyber telemetry evidence, digital twin evidence, dashboards, maps, APIs, degraded-mode awareness, host readiness evidence, public authority learning, community safeguards, public-safe publication, incident handling, records, registers, and assurance expectations.
10.5.2(e) Ontology and semantic baselines may address controlled vocabularies, taxonomies, schemas, data dictionaries, semantic crosswalks, evidence classes, data classes, output classes, boundary terms, public-safe terms, correction terms, confidence and uncertainty terms, maturity-input terms, finance-boundary terms, procurement-boundary terms, public authority terms, provider-neutrality terms, sponsor non-control terms, host-boundary terms, operator-boundary terms, and role-separation terms.
10.5.2(f) AI governance baselines may address Model Registers, Dataset Cards, Model Cards, System Cards, Benchmark Cards, evaluation harnesses, retrieval records, embedding records, inference records, human review requirements, public-safe AI output review, agentic AI controls, AI incident handling, model restriction, model suspension, retirement, deprecation, proof receipts, and correction paths.
10.5.2(g) Data governance baselines may address data classification, lawful basis, purpose limitation, minimization, access controls, role-based access, logging, retention, deletion, sealing, archive, legal hold, cross-border transfer, sovereign data, compute-to-data treatment, secure enclaves, no-download rooms, public authority data, community-protected data, protected knowledge, AI-use restrictions, retrieval restrictions, embedding restrictions, public-safe review, and data protection impact review.
10.5.2(h) Cybersecurity and secure release baselines may address identity and access management, segmentation, least privilege, logging, monitoring, vulnerability management, patch management, secure configuration, repository controls, API controls, dashboard controls, key management, token management, secrets management, credential controls, SBOM practices, dependency review, vulnerability disclosure, coordinated disclosure, responsible non-disclosure, incident response, recovery, and post-incident review.
10.5.2(i) Public-safe publication and technical interface baselines may address public-safe summaries, controlled annexes, restricted annexes, Evidence Packs, Decision Packs, dashboards, maps, APIs, datasets, reports, technical notes, update status, timestamp, version, confidence, uncertainty, limitations, public-safe omissions, boundary language, public authority reference controls, provider reference controls, sponsor reference controls, host reference controls, operator reference controls, correction paths, misuse monitoring, interface logs, dependency notices, and archive treatment.
10.5.2(j) The controlling rule shall be that Open Technical Baselines may define common minimum record and method expectations across technical domains, but shall not create complete systems, legal standards, regulatory requirements, procurement specifications, finance criteria, certification criteria, recognition criteria, protocol effects, public warnings, emergency commands, or execution instructions by default.
10.5.3 Open Technical Baselines as Minimum Public-Good Reference Points, Not Complete Systems or Guarantees. 10.5.3(a) Open Technical Baselines shall be understood as minimum public-good reference points for evidence quality, method consistency, interoperability, public-safe publication, technical transparency, safeguards, and correctionability, and not as complete systems, complete implementations, complete security programs, complete compliance programs, complete operating procedures, complete public authority systems, complete procurement frameworks, complete finance frameworks, complete standards, complete certifications, complete guarantees, or complete execution frameworks by default.
10.5.3(b) Alignment with an Open Technical Baseline shall mean only that a relevant actor, asset, system, method, output, record, interface, or publication has been compared to or structured with reference to the identified baseline version within the recorded scope and limitations. Alignment shall not mean full implementation, suitability for all contexts, public-safe readiness for all audiences, regulatory sufficiency, cybersecurity sufficiency, privacy sufficiency, sovereign data sufficiency, public authority sufficiency, community safeguard sufficiency, protected knowledge sufficiency, finance sufficiency, procurement sufficiency, certification sufficiency, recognition sufficiency, protocol sufficiency, or execution readiness.
10.5.3(c) Open Technical Baselines shall not be represented as guarantees of accuracy, safety, security, resilience, compliance, public authority acceptance, finance-readiness, procurement eligibility, provider neutrality, sponsor independence, host readiness, operator readiness, public-safe publication, interoperability, model performance, data quality, evidence quality, or correction completeness in any specific implementation.
10.5.3(d) Open Technical Baselines may identify minimum expectations, recommended practices, illustrative approaches, common fields, common records, review questions, public-safe controls, interface controls, and correction controls, but implementation sufficiency shall depend on context, law, rights, data, technology, sensitivity, risk, jurisdiction, public authority status, community context, protected knowledge status, cybersecurity posture, dependencies, review, and competent actor decision.
10.5.3(e) Open Technical Baselines shall not be used to bypass project-specific, context-specific, jurisdiction-specific, public authority-specific, community-specific, protected knowledge-specific, cybersecurity-specific, data-specific, finance-specific, procurement-specific, provider-specific, host-specific, operator-specific, or execution-specific review required by law, agreement, governance instrument, safeguards, or good practice.
10.5.3(f) Where an Open Technical Baseline is used in a high-consequence, public authority, health-sensitive, cyber-sensitive, infrastructure-sensitive, finance-sensitive, community-sensitive, protected knowledge, sovereign data, cross-border, AI, AI-RAN, DePIN, digital twin, or mission-critical infrastructure context, additional review, controls, annexes, restrictions, assurance, and correction obligations shall be applied as appropriate.
10.5.3(g) Open Technical Baseline documentation shall include limitations sufficient to prevent overclaim, including limitations concerning scope, version, assumptions, dependencies, legal status, public-safe status, security status, rights status, implementation variance, external standards mapping, Protocol Authority status, public authority status, finance status, procurement status, certification status, recognition status, and correction status.
10.5.3(h) The controlling rule shall be that an Open Technical Baseline is a floor for disciplined public-good reference, not a ceiling, not a system, not a guarantee, and not an approval.
10.5.4 Open Technical Baseline Scope, Version, Custodian, Review Status, Public-Safe Status, and Known Limitations. 10.5.4(a) Each material Open Technical Baseline shall identify its title or identifier, baseline class, purpose, scope, version, custodian, steward, repository or publication location, intended audience, intended use, prohibited use, review status, public-safe status, access class, handling class, rights status, license status, dependency status, known limitations, correction path, supersession path, withdrawal path, and archive path.
10.5.4(b) Scope records shall identify covered domains, excluded domains, applicable actor classes, excluded actor classes, applicable systems, excluded systems, applicable records, applicable interfaces, applicable public-safe outputs, assumptions, dependencies, implementation preconditions, jurisdictional considerations where material, and high-risk conditions requiring additional review.
10.5.4(c) Version records shall identify release date, change date, prior version, successor version where any, change summary, changed scope, changed assumptions, changed dependencies, changed terms, changed public-safe status, changed security status, changed external standards mapping, changed Protocol Authority interface status, changed correction path, and archive treatment.
10.5.4(d) Custodian and steward records shall identify the responsible GCRI Canada technical steward, asset custodian, repository maintainer, public-safe reviewer where applicable, security reviewer where applicable, ontology steward where applicable, correction steward, approving function where applicable, and Board or committee oversight route where material.
10.5.4(e) Review status shall identify whether the baseline is draft, experimental, internal, controlled, public-safe, open, restricted, under review, assurance-reviewed, correction-pending, deprecated, superseded, withdrawn, retired, archived, or closed out, and shall identify the last review date, next review cycle, reviewers, unresolved issues, residual risks, and dependency notices.
10.5.4(f) Public-safe status shall identify whether the baseline can be published as open, published only as a public-safe summary, shared only through controlled annex, restricted annex, or controlled room, withheld from publication, or withdrawn from publication, with reasons for any restriction, responsible non-disclosure, public-safe omissions, and correction status.
10.5.4(g) Known limitations shall identify methodological limits, implementation limits, interoperability limits, security limits, data limits, rights limits, public authority limits, community safeguard limits, protected knowledge limits, finance-boundary limits, procurement-boundary limits, certification-boundary limits, recognition-boundary limits, protocol-boundary limits, jurisdictional limits, translation limits, accessibility limits, dependency limits, and correction limits.
10.5.4(h) Open Technical Baseline records shall not create certification, recognition, finance-readiness, public authority decision, regulatory finding, procurement approval, provider endorsement, sponsor approval, host approval, operator approval, rating, guarantee, public warning, emergency command, protocol effect, professional certification, operational clearance, legal status, market authority, infrastructure operation, deployment approval, or execution consequence by default.
10.5.4(i) The controlling rule shall be that an Open Technical Baseline shall not be used unless its scope, version, custodian, review status, public-safe status, and limitations are known.
10.5.5 Open Technical Baselines and External Standards Mapping. 10.5.5(a) GCRI Canada may map Open Technical Baselines to external standards, frameworks, guidelines, taxonomies, specifications, regulatory references, public authority guidance, academic frameworks, industry frameworks, open-source frameworks, interoperability frameworks, cybersecurity frameworks, AI governance frameworks, data governance frameworks, sustainability frameworks, resilience frameworks, and other relevant reference materials where such mapping supports public-good understanding, semantic clarity, interoperability, evidence quality, safeguards, or correctionability.
10.5.5(b) External standards mapping records shall identify the Open Technical Baseline version, external standard or framework title, issuing body, version or date where known, mapped sections, mapping purpose, mapping method, mapping confidence, mapping uncertainty, mapping limitations, equivalence status, non-equivalence status, partial-equivalence status, translation risks, jurisdictional limits, public authority meaning limits, compliance limits, procurement limits, finance limits, certification limits, protocol limits, and correction path.
10.5.5(c) A mapping to an external standard shall not mean compliance with that standard, certification under that standard, recognition under that standard, public authority acceptance of that standard, procurement eligibility under that standard, finance-readiness under that standard, protocol effect under that standard, or implementation sufficiency under that standard by default.
10.5.5(d) External standards mapping shall distinguish similarity, inspiration, cross-reference, partial alignment, field mapping, semantic mapping, implementation mapping, compliance mapping where expressly and lawfully performed by a competent actor, and formal adoption where separately created by a competent actor. Ambiguity shall not be resolved in favour of compliance, adoption, certification, procurement, finance, or protocol effect.
10.5.5(e) GCRI Canada shall not misstate the authority, legal status, certification status, procurement status, finance status, or public authority status of external standards, nor shall it imply that an external standards body endorses GCRI Canada, GCRI Canada’s assets, Nexus bodies, providers, sponsors, hosts, National Companies, Project SPVs, or implementations merely because a mapping exists.
10.5.5(f) Where external standards contain proprietary restrictions, licensing restrictions, public authority restrictions, jurisdictional limits, security-sensitive material, controlled technology, export-control issues, sanctions issues, or rights limitations, GCRI Canada shall respect such restrictions in mapping, publication, reuse, quotation, and public-safe summary.
10.5.5(g) Where external standards mapping becomes stale, inaccurate, misleading, overclaimed, legally defective, public-authority-confusing, finance-overclaiming, procurement-implying, certification-implying, recognition-implying, protocol-implying, provider-preferential, sponsor-validating, host-approving, or correction-defective, GCRI Canada shall correct, restrict, supersede, withdraw, reissue, archive, or issue clarification as appropriate.
10.5.5(h) The controlling rule shall be that external standards mapping explains relationships among references; it does not create compliance, certification, adoption, procurement, finance, protocol effect, authority, or execution by GCRI Canada.
10.5.6 Open Technical Baselines and Nexus Standards / Protocol Authority Interfaces. 10.5.6(a) GCRI Canada may provide Open Technical Baselines, mapping records, evidence records, method records, interoperability records, ontology records, public-safe summaries, controlled annexes, restricted annexes, correction records, assurance findings, and dependency notices as inputs to Nexus Standards / Protocol Authority interfaces, provided that such inputs remain evidence and methods inputs unless separately adopted, modified, rejected, superseded, or otherwise acted upon by the competent Protocol Authority under its own authority and records.
10.5.6(b) Protocol Authority interface records shall identify the baseline title or identifier, baseline version, materials shared, materials received, purpose, status of input, access class, handling class, public-safe status, rights status, license status, dependency status, external standards mapping where any, boundary language, permitted uses, prohibited uses, correction path, dependency path, notice path, and closeout path.
10.5.6(c) GCRI Canada shall not characterize an Open Technical Baseline as a Protocol Authority rule, protocol standard, conformance criterion, Nexus-compatible requirement, certification criterion, provider qualification, host qualification, procurement qualification, finance qualification, public authority requirement, or market entitlement unless the competent Protocol Authority or other competent actor has separately created that status through its own process and records.
10.5.6(d) Protocol Authority consideration, discussion, mapping, comment, review, testing, pilot use, public consultation, technical comparison, or controlled-room review of an Open Technical Baseline shall not create protocol effect, conformance status, standards adoption, Nexus-compatible status, certification, procurement qualification, finance qualification, provider qualification, host qualification, public authority meaning, deployment approval, market entitlement, or execution consequence by default.
10.5.6(e) Where a Protocol Authority adopts, modifies, rejects, or supersedes an Open Technical Baseline, GCRI Canada shall update the Public-Good Technical Asset Register, relevant interface logs, public-safe summaries, dependency records, correction records, supersession records, and public claims to distinguish GCRI Canada’s baseline from the Protocol Authority’s separate action.
10.5.6(f) GCRI Canada shall preserve correction rights and correction signals for Open Technical Baseline inputs provided to Protocol Authority interfaces. Where baseline errors, security issues, rights issues, public-safe defects, dependency defects, or overclaims are identified after routing, GCRI Canada shall issue correction signals or dependency notices to the Protocol Authority and affected interfaces where appropriate.
10.5.6(g) GCRI Canada shall not permit Protocol Authority interface language to imply that GCRI Canada exercises Protocol Authority functions, grants protocol effect, grants conformance status, certifies alignment, approves implementations, or enforces standards.
10.5.6(h) The controlling rule shall be that Open Technical Baselines may inform protocol development, but Protocol Authority belongs to the competent Protocol Authority and does not arise from GCRI Canada baseline stewardship by implication.
10.5.7 Open Technical Baseline Alignment Does Not Create Certification by Default. 10.5.7(a) Alignment with an Open Technical Baseline shall not create certification by GCRI Canada by default. No actor, asset, system, implementation, software, model, dataset, dashboard, map, API, sensor, AI-RAN system, O-RAN system, private wireless system, DePIN system, compute environment, digital twin, reference architecture, Evidence Pack, Decision Pack, public-safe output, provider, sponsor, host, operator, National Company, Project SPV, public authority interface, community interface, university project, or Nexus interface shall be described as certified by GCRI Canada merely because it aligns with, references, implements, maps to, or is assessed against an Open Technical Baseline.
10.5.7(b) GCRI Canada shall not issue certification marks, certification labels, certified-baseline status, conformance certificates, compliance certificates, safety certificates, security certificates, AI certificates, data governance certificates, public-safe certificates, Observatory certificates, Truth Engine certificates, provider certificates, host certificates, operator certificates, maturity certificates, finance certificates, procurement certificates, protocol certificates, or professional certificates through Open Technical Baseline alignment unless a separate lawful certification authority, scope, process, liability structure, governance instrument, and Board authorization are expressly established.
10.5.7(c) Baseline alignment records may identify evidence of comparison, gap analysis, implementation mapping, self-assessment, independent review where applicable, public-safe review, assurance finding, correction status, and limitations, but shall not be named, designed, published, or relied upon as certification by default.
10.5.7(d) Labels such as “aligned,” “mapped,” “consistent with,” “uses,” “references,” “informed by,” “compared against,” or similar language shall be accompanied by boundary language where material to prevent interpretation as certification, approval, recognition, public authority adoption, finance-readiness, procurement qualification, protocol effect, provider endorsement, host approval, operator approval, professional qualification, deployment approval, operational clearance, or execution readiness.
10.5.7(e) Where a separate competent certification body, public authority, Protocol Authority, professional body, procurement actor, or other actor uses an Open Technical Baseline as part of its own certification or conformance process, such certification or conformance status shall arise only through that actor’s own authority, process, records, accountability, liability, and governance instruments, not through GCRI Canada baseline alignment by implication.
10.5.7(f) GCRI Canada shall review public claims, provider claims, sponsor claims, host claims, operator claims, public authority claims, National Company claims, Project SPV claims, Academy claims, media claims, repository claims, dashboard claims, and marketing claims for improper certification language based on Open Technical Baseline alignment.
10.5.7(g) Where alignment is misused as certification, GCRI Canada shall correct, relabel, restrict, withdraw, reissue, request removal of misleading references, issue public-safe or controlled clarification, notify affected interfaces where appropriate, suspend affected use where within its control, or pursue contractual or legal remedies where appropriate.
10.5.7(h) The controlling rule shall be that alignment is evidence of relationship to a baseline, not certification of the actor, asset, system, implementation, output, or use.
10.5.8 Open Technical Baseline Alignment Does Not Create Procurement Preference or Provider Ranking. 10.5.8(a) Alignment with an Open Technical Baseline shall not create procurement preference, provider ranking, vendor approval, supplier qualification, tender advantage, award recommendation, purchasing recommendation, approved product status, approved service status, preferred provider status, host selection, operator selection, National Company selection, Project SPV selection, or market entitlement by GCRI Canada by default.
10.5.8(b) GCRI Canada shall not use Open Technical Baseline alignment to rank providers, score vendors, approve products, recommend procurement, determine tender eligibility, determine contract award, determine public procurement status, determine private procurement status, determine public finance eligibility, determine National Company procurement, determine Project SPV procurement, determine host selection, determine operator selection, or determine market access.
10.5.8(c) Baseline alignment information may be used as non-advisory, non-procurement technical evidence by competent procurement actors, National Companies, Project SPVs, public authorities, hosts, operators, providers, or other actors only under their own authority, process, records, accountability, liability, procurement rules, conflicts rules, transparency obligations, and correction paths.
10.5.8(d) Public-safe baselines, alignment tables, comparison matrices, dashboards, checklists, gap analyses, Evidence Packs, Decision Packs, technical notes, or assurance summaries shall not be designed or presented as provider rankings, vendor scorecards, procurement recommendations, qualified supplier lists, approved product lists, approved service lists, preferred technology lists, host approval lists, operator approval lists, or tender filters by GCRI Canada.
10.5.8(e) Provider, vendor, sponsor, host, operator, National Company, Project SPV, or other actor participation in developing, testing, commenting on, mapping, implementing, or demonstrating alignment with an Open Technical Baseline shall not create preferred status, procurement advantage, certification, recognition, finance-readiness, public authority endorsement, Protocol Authority effect, market entitlement, deployment approval, operational clearance, or execution consequence.
10.5.8(f) GCRI Canada shall review baseline-related public claims for provider preference, vendor superiority, procurement readiness, tender advantage, approved-product implication, approved-service implication, public authority procurement implication, host selection implication, National Company procurement implication, Project SPV procurement implication, or market entitlement implication.
10.5.8(g) Where Open Technical Baseline alignment is misused to imply procurement preference or provider ranking, GCRI Canada shall correct, relabel, restrict, withdraw, reissue, request removal of misleading references, issue clarification, notify affected interfaces where appropriate, suspend affected use where within its control, or pursue contractual or legal remedies where appropriate.
10.5.8(h) The controlling rule shall be that baseline alignment may help technical comparability, but it shall not rank providers, prefer vendors, recommend purchases, award contracts, or create procurement consequence by GCRI Canada.
10.5.9 Open Technical Baseline Alignment Does Not Create Finance-Readiness, Insurance-Readiness, Public Authority Adoption, or Protocol Effect by Default. 10.5.9(a) Alignment with an Open Technical Baseline shall not create finance-readiness, capital-readiness, insurance-readiness, bankability, fundability, investment advice, lending decision, underwriting decision, rating, guarantee, public finance approval, project approval, public authority adoption, public authority approval, official guidance, regulatory determination, public warning, emergency command, protocol effect, conformance status, Nexus-compatible status, market entitlement, deployment approval, operational clearance, or execution consequence by GCRI Canada by default.
10.5.9(b) GCRI Canada shall not use Open Technical Baseline alignment to determine or imply investment quality, insurance quality, credit quality, underwriting quality, resilience finance eligibility, public finance eligibility, procurement eligibility, project readiness, host readiness for finance, National Company readiness, Project SPV readiness, public authority adoption, regulatory acceptability, protocol effect, conformance status, or execution readiness.
10.5.9(c) GRA, Nexus Rails, capital readers, insurers, lenders, investors, public finance bodies, National Companies, Project SPVs, public authorities, Protocol Authority, procurement actors, hosts, operators, and other competent actors may consider Open Technical Baseline alignment only through their own authority, process, records, accountability, liability, and governance instruments. Their separate reliance shall not be attributed to GCRI Canada unless expressly and accurately recorded as a bounded evidence-input relationship.
10.5.9(d) Public authority use, comment, attendance, data contribution, review, mapping, non-objection, dashboard access, map access, funding interest, procurement interest, public finance interest, regulator-listening participation, emergency-management participation, public health participation, public safety participation, or implementation of an Open Technical Baseline shall not create official adoption, public authority approval, regulatory determination, procurement approval, funding approval, public finance approval, public warning, emergency command, public-law status, certification, recognition, finance-readiness, protocol effect, provider endorsement, sponsor approval, host approval, operator instruction, deployment approval, legal status, market authority, or execution consequence by implication.
10.5.9(e) Protocol Authority use, discussion, mapping, consultation, testing, comment, review, or pilot treatment of an Open Technical Baseline shall not create protocol effect, conformance status, Nexus-compatible status, certification, procurement qualification, finance qualification, provider qualification, host qualification, public authority meaning, market entitlement, deployment approval, operational clearance, or execution consequence unless separately created by the competent Protocol Authority through its own authority and records.
10.5.9(f) Baseline alignment information routed to GRA, Nexus Rails, RNFD, NFD, UNFSD, capital-reader materials, insurance-reader materials, lender materials, investor materials, public finance materials, National Company materials, or Project SPV materials shall include no-investment-advice, no-rating, no-guarantee, no-finance-readiness-by-GCRI, no-insurance-readiness-by-GCRI, no-public-finance-approval, no-procurement, no-project-approval, no-provider-preference, no-host-approval, no-deployment-approval, no-operational-clearance, and no-execution language where material.
10.5.9(g) Where Open Technical Baseline alignment is misused to imply finance-readiness, insurance-readiness, public authority adoption, public authority approval, protocol effect, conformance status, public finance approval, rating, guarantee, procurement approval, project approval, market entitlement, deployment approval, operational clearance, or execution consequence, GCRI Canada shall correct, relabel, restrict, withdraw, reissue, request removal of misleading references, issue public-safe or controlled clarification, notify affected interfaces where appropriate, suspend affected use where within its control, or pursue contractual or legal remedies where appropriate.
10.5.9(h) The controlling rule shall be that baseline alignment may support evidence discipline and comparability, but shall not finance, insure, adopt, regulate, confer protocol effect, approve, guarantee, or execute.
10.5.10 Open Technical Baseline Versioning, Change Logs, Public-Safe Summaries, Corrections, and Supersession. 10.5.10(a) GCRI Canada shall maintain versioning, change logs, public-safe summaries, correction records, supersession records, withdrawal records, retraction records where necessary, deprecation records, retirement records, archive records, dependency notices, vulnerability notices where applicable, release notes, and closeout records for material Open Technical Baselines.
10.5.10(b) Version records shall identify baseline title or identifier, version, release date, steward, custodian, repository or publication location, prior version, successor version where any, changed scope, changed terms, changed assumptions, changed dependencies, changed external standards mapping, changed Protocol Authority interface status, changed public-safe status, changed security status, changed rights status, changed boundary language, changed correction path, and archive treatment.
10.5.10(c) Change logs shall identify additions, removals, modifications, deprecations, corrections, security-relevant changes, rights-relevant changes, license-relevant changes, interoperability changes, schema changes, ontology changes, dashboard changes, API changes, public-safe publication changes, public authority boundary changes, community safeguard changes, protected knowledge changes, provider-neutrality changes, sponsor non-control changes, finance-boundary changes, procurement-boundary changes, certification-boundary changes, recognition-boundary changes, protocol-boundary changes, and correction-path changes.
10.5.10(d) Public-safe summaries shall describe baseline purpose, scope, version, update status, intended use, prohibited use, key changes, known limitations, public-safe omissions, responsible non-disclosure where any, external standards mapping where any, Protocol Authority interface status where any, no-certification language, no-recognition language, no-finance language, no-procurement language, no-public-authority language, no-protocol-effect language unless separately created, no-provider-endorsement language, no-sponsor-control language, no-host-approval language, no-operator-instruction language, no-deployment-approval language, no-operational-clearance language, no-execution language, and correction path.
10.5.10(e) Correction records shall identify corrected baseline, corrected version, corrected section, corrected mapping, corrected schema, corrected vocabulary, corrected interface, corrected boundary language, corrected public-safe status, corrected rights status, corrected dependency, corrected security issue, corrected public authority reference, corrected provider reference, corrected sponsor reference, corrected host reference, corrected operator reference, corrected community safeguard, corrected protected knowledge treatment, prior status, corrected status, effective date, reviewer, affected dependencies, notice decision, access change, archive treatment, and continuing limitations.
10.5.10(f) Supersession records shall identify replacement baseline, replacement version, changed evidence base, changed technical assumptions, changed external standards mapping, changed Protocol Authority interface status, changed public-safe treatment, changed rights treatment, changed security treatment, changed interface terms, changed boundary language, continuing validity where any, discontinued reliance where any, migration notes where appropriate, and affected dependency notices.
10.5.10(g) Withdrawal or retraction records shall identify baseline materials no longer to be used or relied upon, basis for withdrawal or retraction, affected audiences, affected interfaces, affected public-safe outputs, affected controlled annexes, affected restricted annexes, affected schemas, affected APIs, affected Evidence Packs, affected Decision Packs, affected dashboards, affected maps, affected external standards mappings, affected Protocol Authority interfaces, affected public claims, access changes, notice decisions, archive treatment, and continuing prohibited uses.
10.5.10(h) GCRI Canada shall issue correction signals or dependency notices to affected GRF, GRA, Protocol Authority, Nexus Observatory, Nexus Truth Engine, Nexus Rails, Nexus Grid, Nexus Docket, Nexus Academy, Nexus Universe, National Consortium, National Company, Project SPV, provider, sponsor, host, operator, public authority, community, university, capital-reader, media, repository, and public-safe interfaces where baseline corrections, supersessions, withdrawals, retractions, or security issues materially affect prior use or reliance.
10.5.10(i) Versioning, change logs, public-safe summaries, correction records, supersession records, withdrawal records, retraction records, deprecation records, retirement records, archive records, dependency notices, vulnerability notices, release notes, Board reports, committee reports, and closeout records shall not create certification, recognition, finance-readiness, public authority decision, regulatory finding, procurement approval, security certification, provider endorsement, sponsor approval, host approval, operator approval, community consent, Indigenous consent, rating, guarantee, public warning, emergency command, protocol effect, professional certification, operational clearance, legal status, market authority, infrastructure operation, deployment approval, national authority, regional authority, GRF maturity record, GRA finance-readiness, Docket approval, Grid maturity record, Rails finance authority, Academy certification, or execution consequence by default.
10.5.10(j) The controlling rule shall be that Open Technical Baselines remain trustworthy only while their versions, changes, limitations, public-safe summaries, corrections, supersessions, withdrawals, and notices remain visible enough to prevent stale alignment, hidden reliance, unsupported compliance claims, and uncorrected public meaning.
10.6 Schemas, APIs, Data Contracts, and Interface Specifications
10.6.1 Schemas as Public-Good Interoperability Assets. 10.6.1(a) GCRI Canada may steward schemas as public-good interoperability assets used to structure, validate, exchange, interpret, compare, route, publish, correct, and archive data, metadata, evidence, methods, outputs, proofs, records, registers, dashboards, maps, APIs, Evidence Packs, Decision Packs, public-safe summaries, controlled annexes, restricted annexes, correction records, assurance records, and interface records within GCRI Canada’s non-executing public-benefit role.
10.6.1(b) Schemas may define fields, field meanings, field types, controlled values, validation rules, metadata requirements, evidence-class requirements, data-class requirements, output-class requirements, access-class requirements, handling-class requirements, confidence fields, uncertainty fields, limitation fields, public-safe fields, public authority fields, community safeguard fields, protected knowledge fields, provider fields, sponsor fields, host fields, operator fields, finance-boundary fields, procurement-boundary fields, protocol-boundary fields, correction fields, supersession fields, withdrawal fields, retraction fields, archive fields, and dependency fields.
10.6.1(c) Schemas shall preserve semantic clarity and role separation. A field enabling GRF input shall not create GRF recognition; a field enabling GRA input shall not create finance-readiness; a field enabling Protocol Authority input shall not create protocol effect; a field enabling public authority reference shall not create public authority action; a field enabling provider reference shall not create provider endorsement; a field enabling sponsor reference shall not create sponsor control; and a field enabling National Company or Project SPV routing shall not create execution consequence by GCRI Canada.
10.6.1(d) Material schemas shall identify title or identifier, version, steward, custodian, purpose, scope, intended users, source vocabulary, ontology dependencies, data dictionaries, validation rules, required fields, optional fields, prohibited fields, deprecated fields, sensitive fields, public-safe fields, restricted fields, access controls, release status, public-safe status, license status, dependency status, correction path, deprecation path, sunset path, and archive path.
10.6.1(e) Schema design shall prevent context collapse, false association, unauthorized inference, unsafe aggregation, unsafe linkage, public authority confusion, finance overclaim, procurement implication, certification implication, recognition implication, protocol implication, provider preference, sponsor validation, host approval implication, operator instruction implication, community consent implication, protected knowledge exposure, privacy harm, cybersecurity harm, and execution implication.
10.6.1(f) Schemas shall not be represented as official data standards, public authority schemas, regulatory requirements, procurement specifications, finance-readiness criteria, certification criteria, recognition criteria, Protocol Authority rules, provider qualification requirements, host approval criteria, professional qualification criteria, operating instructions, emergency command instruments, public warning instruments, or execution instructions by default.
10.6.1(g) Where schemas are corrected, versioned, deprecated, restricted, superseded, withdrawn, retracted where necessary, retired, or archived, GCRI Canada shall update affected APIs, data dictionaries, data contracts, interface specifications, Evidence Packs, Decision Packs, dashboards, maps, public-safe summaries, controlled annexes, restricted annexes, registers, training materials, public claims, dependency notices, and correction records as appropriate.
10.6.1(h) The controlling rule shall be that schemas are public-good interoperability assets only when they carry meaning, classification, limits, and correction paths with the data they structure.
10.6.2 APIs as Controlled Technical Interfaces, Not Authority Surfaces by Default. 10.6.2(a) GCRI Canada may steward APIs as controlled technical interfaces for permissioned, purpose-bound, logged, versioned, public-safe where appropriate, restricted where required, secure, monitored, rate-limited where appropriate, and correctionable exchange of data, metadata, evidence, outputs, records, dashboards, maps, proof receipts, Evidence Packs, Decision Packs, public-safe summaries, controlled annexes, restricted annexes, correction signals, dependency notices, and interface records.
10.6.2(b) APIs may support GCRI Canada’s evidence rail, Nexus Observatory, Nexus Truth Engine, Verifiable Compute, Verifiable Intelligence, Nexus Risk Management, Nexus Rails, Nexus Grid, Nexus Docket, Nexus Academy, Nexus Universe, GRF inputs, GRA inputs, Protocol Authority inputs, public authority learning interfaces, community safeguard interfaces, provider-neutral interfaces, sponsor-bounded interfaces, host interfaces, operator interfaces, National Company interfaces, Project SPV interfaces, public-safe publication, correction, assurance, and public-good technical asset management.
10.6.2(c) APIs shall be treated as technical interfaces and not as authority surfaces by default. API access, API response, API status, API token issuance, API documentation, API endpoint availability, API schema compliance, API proof receipt, API dashboard connection, API data exchange, or API integration shall not create certification, recognition, finance-readiness, public authority decision, procurement approval, provider endorsement, sponsor approval, host approval, operator instruction, protocol effect, professional certification, operational clearance, deployment approval, market authority, legal status, public warning, emergency command, or execution consequence by default.
10.6.2(d) Material APIs shall identify title or identifier, version, steward, custodian, purpose, audience, endpoint classes, data classes, evidence classes, output classes, access classes, handling classes, public-safe status, authentication requirements, authorization requirements, token requirements, rate-limit rules where applicable, logging rules, monitoring rules, error-message safety rules, public-safe filtering rules, export limits, redistribution limits, permitted uses, prohibited uses, correction path, deprecation path, sunset path, and archive path.
10.6.2(e) API documentation shall include boundary language sufficient to prevent API consumers from treating API responses as official truth, public warnings, emergency commands, public authority decisions, regulatory determinations, finance determinations, procurement determinations, certifications, recognitions, ratings, guarantees, provider rankings, host approvals, protocol effects, professional qualifications, deployment approvals, operational clearances, or execution instructions.
10.6.2(f) APIs shall not expose personal data, public authority restricted information, health-sensitive information, cyber-sensitive information, infrastructure-sensitive information, finance-sensitive information, commercially sensitive information, community-protected information, Indigenous or protected knowledge, legal-sensitive information, export-controlled information, sanctions-sensitive information, controlled technology, credentials, secrets, keys, tokens, vulnerabilities, sensitive locations, unsafe metadata, or other restricted information except under recorded authority, access control, handling control, public-safe review, security control, and correction path.
10.6.2(g) Where API outputs are corrected, restricted, superseded, withdrawn, retracted, stale, deprecated, retired, or archived, GCRI Canada shall update API responses, status metadata, documentation, downstream notices, dependency records, affected dashboards, affected maps, affected Evidence Packs, affected Decision Packs, affected public-safe summaries, affected interface records, and public claims as appropriate.
10.6.2(h) The controlling rule shall be that APIs move technical information across boundaries; they shall not move institutional authority, finance, procurement, certification, recognition, protocol effect, warning, command, or execution by implication.
10.6.3 Data Contracts as Permissioned, Purpose-Bound, Classification-Aware Instruments. 10.6.3(a) GCRI Canada may steward data contracts as permissioned, purpose-bound, classification-aware, access-controlled, public-safe, security-controlled, sovereignty-compatible, rights-aware, role-separated, and correctionable instruments governing the exchange, access, use, retention, publication, correction, and closeout of data and metadata in public-good technical interfaces.
10.6.3(b) Data contracts shall identify data source, data provider where any, data recipient, steward, custodian, lawful basis or recorded authority, purpose, permitted uses, prohibited uses, data classes, evidence classes, output classes, access classes, handling classes, public-safe status, public authority status, community-protected status, protected knowledge status, privacy status, cybersecurity status, sovereign data status, export-control sensitivity, sanctions sensitivity, controlled-technology sensitivity, retention, deletion, sealing, archive, correction path, and closeout obligations.
10.6.3(c) Data contracts shall not be treated as unrestricted licenses, public releases, public authority approvals, procurement approvals, finance-readiness confirmations, certification decisions, recognition decisions, protocol effects, provider endorsements, sponsor approvals, host approvals, operator instructions, or execution authorizations by default.
10.6.3(d) Data contracts involving public authorities shall preserve capacity classification, data contribution records, public authority restrictions, reference controls, non-delegation, non-endorsement, no-official-guidance, no-regulatory-determination, no-public-warning, no-emergency-command, no-procurement, no-funding, no-public-finance, no-certification, no-recognition, no-finance-readiness, no-protocol-effect unless separately created, no-provider-endorsement, no-sponsor-approval, no-host-approval, no-operator-instruction, and no-execution language where material.
10.6.3(e) Data contracts involving communities, Indigenous peoples or governance bodies where applicable, local knowledge, territorial knowledge, environmental knowledge, community sensors, community data, sensitive sites, cultural sites, sacred sites, protected sites, vulnerable communities, or protected knowledge shall preserve non-extraction, consent or non-consent treatment where applicable, withdrawal pathways where applicable, grievance pathways where applicable, challenge pathways where applicable, remedy pathways where applicable, public-safe mapping controls, source protection, protected knowledge safeguards, community review where required, and correction path.
10.6.3(f) Data contracts involving providers, vendors, sponsors, hosts, operators, National Companies, Project SPVs, universities, or other contributors shall preserve rights, confidentiality, IP status, data restrictions, conflict controls, provider neutrality, sponsor non-control, host boundaries, operator boundaries, no-endorsement language, no-procurement language, no-finance language, no-certification language, no-recognition language, no-protocol-effect language unless separately created, and no-execution language where material.
10.6.3(g) Data contracts shall include correction obligations requiring parties to notify, review, correct, restrict, supersede, withdraw, reissue, delete, seal, archive, or cease reliance on data where source defects, classification defects, permission defects, lawful basis defects, public-safe defects, privacy defects, cybersecurity defects, sovereign data defects, protected knowledge defects, public authority defects, provider defects, sponsor defects, host defects, operator defects, or dependency defects are identified.
10.6.3(h) The controlling rule shall be that data contracts define what data may be used, by whom, for what purpose, under what classification, for how long, with what safeguards, and how it must be corrected; they do not create unrestricted rights, authority, finance, procurement, certification, recognition, protocol effect, or execution.
10.6.4 Interface Specifications for Evidence, Methods, Observatory, Truth Engine, Docket, Grid, Rails, Academy, GRF, GRA, Protocol Authority, National Companies, Project SPVs, Providers, Hosts, and Public Authorities. 10.6.4(a) GCRI Canada may steward interface specifications for evidence, methods, Observatory systems, Truth Engine systems, Docket systems, Grid systems, Rails systems, Academy systems, GRF interfaces, GRA interfaces, Protocol Authority interfaces, National Company interfaces, Project SPV interfaces, provider interfaces, sponsor interfaces, host interfaces, operator interfaces, public authority interfaces, community interfaces, university interfaces, and public-safe publication interfaces.
10.6.4(b) Interface specifications shall identify sending actor, receiving actor, interface purpose, asset or record types exchanged, schemas used, APIs used, data contracts used, evidence classes, data classes, output classes, access classes, handling classes, public-safe status, rights status, license status, security requirements, authentication requirements, authorization requirements, logging requirements, retention requirements, deletion requirements, correction obligations, dependency notices, permitted uses, prohibited uses, boundary language, and closeout path.
10.6.4(c) Evidence and methods interface specifications shall preserve source lineage, method version, confidence, uncertainty, limitations, contradiction status, stale-data status, review status, public-safe status, correction status, and no-authority language sufficient to prevent evidence routing from becoming approval, warning, command, certification, recognition, finance, procurement, protocol effect, or execution.
10.6.4(d) Observatory and Truth Engine interface specifications shall preserve no-oracle language, no-official-truth language, no-public-warning language, no-emergency-command language, no-public-authority-decision language, no-certification language, no-recognition language, no-finance-readiness language, no-procurement language, no-provider-endorsement language, no-sponsor-control language, no-host-approval language, no-operator-instruction language, no-protocol-effect language unless separately created, and no-execution language where material.
10.6.4(e) Docket interface specifications shall preserve no-approval-by-docketing language, issue status, review status, correction status, dependency status, boundary language, and closeout status. Docket routing shall not create approval, certification, recognition, finance-readiness, procurement approval, public authority decision, protocol effect, provider preference, sponsor approval, host approval, operator approval, deployment approval, operational clearance, or execution consequence.
10.6.4(f) Grid interface specifications shall preserve no-GCRI-maturity-record language, no-professional-certification language, stage-truth discipline, maturity-input status, competence-input status, public-safe status, correction status, and role separation from GRF, Academy, Protocol Authority, public authorities, procurement actors, finance actors, and execution actors.
10.6.4(g) Rails and GRA interface specifications shall preserve no-investment-advice, no-rating, no-guarantee, no-finance-readiness-by-GCRI, no-insurance-readiness-by-GCRI, no-public-finance-approval, no-procurement, no-project-approval, no-provider-preference, no-host-approval, no-deployment-approval, no-operational-clearance, and no-execution language.
10.6.4(h) Academy interface specifications shall preserve learning-purpose limits, learner class, simulation status, public-safe status, no-professional-certification language, no-license language, no-regulated-qualification language, no-procurement-qualification language, no-finance-qualification language, no-public-authority-qualification language, no-protocol-effect language, and no-execution language.
10.6.4(i) GRF interface specifications shall preserve no-recognition-by-GCRI language, no-standing-by-GCRI language, no-claims-approval-by-GCRI language, no-maturity-record-by-GCRI language, no-public-facing-legitimacy-by-GCRI language, no-finance language, no-procurement language, no-public-authority language, no-protocol-effect language, and no-execution language.
10.6.4(j) Protocol Authority interface specifications shall preserve input status, no-protocol-effect-by-GCRI language, no-conformance-by-GCRI language, no-certification-by-GCRI language, no-Nexus-compatible-status-by-GCRI language, correction signals, supersession notices, and separation between GCRI Canada baseline stewardship and Protocol Authority action.
10.6.4(k) National Company and Project SPV interface specifications shall preserve legal separateness, public-good stack and enterprise stack separation, no-project-approval-by-GCRI language, no-finance-readiness-by-GCRI language, no-procurement-by-GCRI language, no-provider-selection-by-GCRI language, no-host-approval-by-GCRI language, no-deployment-approval-by-GCRI language, no-operational-clearance-by-GCRI language, and no-execution-by-GCRI language.
10.6.4(l) Provider, sponsor, host, operator, public authority, university, community, and capital-reader interface specifications shall preserve actor role, contribution limits, access limits, public-safe status, reference controls, public claims limits, conflict controls where applicable, provider-neutrality controls, sponsor non-control controls, host-boundary controls, operator-boundary controls, public authority capacity classification where applicable, community safeguard treatment where applicable, protected knowledge treatment where applicable, and correction path.
10.6.4(m) The controlling rule shall be that interface specifications must make role boundaries machine-readable, human-readable, and correctionable so that technical integration does not become institutional merger, authority transfer, finance transfer, procurement effect, certification, recognition, protocol effect, or execution.
10.6.5 API and Schema Versioning, Deprecation, Compatibility, Backward Compatibility, Breaking Change, and Sunset Rules. 10.6.5(a) GCRI Canada shall maintain versioning, compatibility, backward compatibility, breaking-change, deprecation, sunset, supersession, withdrawal, retirement, archive, and migration rules for material APIs, schemas, data dictionaries, data contracts, and interface specifications.
10.6.5(b) Version records shall identify API or schema title or identifier, version, release date, steward, custodian, repository or publication location, prior version, successor version where any, changed fields, changed endpoints, changed validation rules, changed authentication requirements, changed authorization requirements, changed public-safe filters, changed data classes, changed evidence classes, changed output classes, changed boundary language, changed correction path, changed dependency status, changed security status, and archive treatment.
10.6.5(c) Compatibility records shall identify whether changes are backward compatible, partially compatible, incompatible, breaking, migration-required, public-safe-required, controlled-only, restricted-only, security-required, rights-required, data-contract-required, or sunset-bound, together with affected interfaces and affected dependencies.
10.6.5(d) Breaking changes shall be recorded where changes alter field meanings, remove fields, add required fields, change validation logic, change endpoint behavior, change classification rules, change confidence or uncertainty logic, change public-safe filtering, change authentication or authorization requirements, change permitted uses, change prohibited uses, change boundary language, change correction obligations, alter downstream reliance, or create material incompatibility.
10.6.5(e) Deprecation notices shall identify deprecated API, schema, field, endpoint, interface, data contract, or specification; reason for deprecation; replacement where any; continued permitted uses; prohibited uses; migration requirements; public-safe implications; security implications; data implications; interface implications; dependency implications; sunset date where any; and correction path.
10.6.5(f) Sunset rules shall identify when an API, schema, endpoint, field, data contract, or interface specification shall no longer be available, supported, used for new records, used for public-safe output, used for controlled interfaces, used for restricted interfaces, or relied upon for material decisions or interface routing, subject to legal hold, archive, audit, correction, and dependency review needs.
10.6.5(g) GCRI Canada shall issue migration notes, dependency notices, public-safe notices, controlled notices, restricted notices, or interface notices where version changes materially affect GRF inputs, GRA inputs, Protocol Authority inputs, Observatory records, Truth Engine records, Rails inputs, Grid inputs, Docket inputs, Academy materials, Nexus Universe materials, National Company materials, Project SPV materials, provider interfaces, sponsor interfaces, host interfaces, operator interfaces, public authority interfaces, community interfaces, dashboards, maps, APIs, Evidence Packs, Decision Packs, or public claims.
10.6.5(h) Versioning, compatibility, deprecation, sunset, supersession, withdrawal, retirement, archive, migration, and dependency notices shall not create certification, recognition, finance-readiness, public authority decision, regulatory finding, procurement approval, provider endorsement, sponsor approval, host approval, operator approval, rating, guarantee, public warning, emergency command, protocol effect, professional certification, operational clearance, legal status, market authority, infrastructure operation, deployment approval, or execution consequence by default.
10.6.5(i) The controlling rule shall be that API and schema changes must not silently change institutional meaning; versioning exists to prevent technical change from becoming hidden authority, hidden reliance, or hidden error.
10.6.6 API Access Controls, Authentication, Authorization, Rate Limits, Logging, Monitoring, Key Management, Token Management, and Abuse Detection. 10.6.6(a) GCRI Canada shall maintain access controls, authentication, authorization, rate limits where appropriate, logging, monitoring, security telemetry, key management, token management, secrets management, credential controls, abuse detection, misuse detection, incident detection, and correction controls for material APIs and technical interfaces.
10.6.6(b) API access shall be purpose-bound, role-based, least-privilege, time-limited where appropriate, logged, monitored, revocable, classification-aware, public-safe-aware, rights-aware, cybersecurity-aware, sovereign-data-aware, public-authority-aware, community-safeguard-aware, protected-knowledge-aware, provider-neutral, sponsor-independent, host-bounded, operator-bounded, finance-safe, procurement-safe, and correctionable.
10.6.6(c) Authentication and authorization records shall identify API consumer, user or role, institution, interface, capacity, access purpose, access scope, endpoints authorized, data classes authorized, evidence classes authorized, output classes authorized, handling class, public-safe status, token scope, key scope, credential status, expiration, review cycle, logging status, revocation path, and correction path.
10.6.6(d) Rate limits and usage limits may be used to protect system integrity, public-safe publication, privacy, cybersecurity, sovereign data, public authority restrictions, community safeguards, protected knowledge, provider neutrality, sponsor non-control, service reliability, misuse detection, and correctionability. Rate limits shall not be used to create hidden preference, procurement advantage, finance advantage, provider preference, sponsor privilege, host privilege, public authority confusion, or unfair execution effect by GCRI Canada.
10.6.6(e) Logging and monitoring shall record, where appropriate, authentication events, authorization events, token events, key events, endpoint access, data queries, exports, errors, public-safe filtering, restricted-field suppression, unusual usage, abuse indicators, cross-border access, high-volume access, failed access, denied access, access to sensitive fields, correction events, deprecation events, and incident events.
10.6.6(f) Key, token, secret, and credential controls shall prohibit hard-coded secrets, unmanaged tokens, unrestricted API keys, shared credentials without recorded exception, credentials in public repositories, credentials in logs, credentials in prompts, credentials in dashboards, credentials in maps, credentials in public-safe outputs, credentials in provider materials, credentials in sponsor materials, credentials in host materials, credentials in public authority materials, and credentials in Academy materials.
10.6.6(g) Abuse detection shall identify scraping, excessive querying, credential sharing, token misuse, API replay, automated misuse, endpoint probing, public-safe filter bypass, restricted-field inference, linkage attacks, re-identification attempts, prompt injection where applicable, retrieval abuse, embedding leakage, data exfiltration, public authority misuse, finance-facing misuse, procurement-facing misuse, provider misuse, sponsor misuse, host misuse, operator misuse, and public claims misuse.
10.6.6(h) Where API misuse, access misuse, key compromise, token compromise, credential compromise, public-safe filter bypass, rate-limit abuse, logging failure, monitoring failure, unauthorized export, cross-border defect, re-identification attempt, restricted-field exposure, or correction failure is detected, GCRI Canada shall restrict access, revoke credentials, rotate keys, rotate tokens, suspend endpoints, quarantine data, correct outputs, issue notices where appropriate, and initiate incident handling where material.
10.6.6(i) API access, token issuance, key issuance, rate-limit category, monitored usage, or privileged access shall not create certification, recognition, finance-readiness, procurement preference, public authority approval, provider endorsement, sponsor approval, host approval, operator approval, protocol effect, operational clearance, deployment approval, market authority, public warning, emergency command, or execution consequence by default.
10.6.6(j) The controlling rule shall be that API access is a revocable technical permission for a recorded purpose, not institutional status.
10.6.7 Data Contract Requirements for Lawful Basis, Purpose, Classification, Retention, Transfer, AI Use, Publication, and Correction. 10.6.7(a) Data contracts stewarded or used by GCRI Canada shall include requirements for lawful basis or recorded authority, purpose limitation, data classification, access class, handling class, public-safe status, retention, deletion, sealing, archive, legal hold, transfer, cross-border transfer, sovereign data treatment, AI use, retrieval use, embedding use, publication, correction, supersession, withdrawal, retraction where applicable, and closeout.
10.6.7(b) Lawful basis or recorded authority requirements shall identify the legal, contractual, institutional, public authority, community, consent-based, non-consent-based, license-based, research-based, public-good, or other recorded basis for collecting, receiving, accessing, processing, storing, sharing, publishing, correcting, or deleting the data.
10.6.7(c) Purpose limitation requirements shall state the specific purpose for which data may be used and shall prohibit materially different use without recorded review and authority. Purpose shall distinguish evidence use, method use, observability use, Truth Engine use, public authority learning use, community safeguard use, provider-neutral review use, sponsor-bounded use, host readiness use, Rails literacy use, Grid input use, Docket routing use, Academy use, public-safe publication use, AI use, compute use, dashboard use, map use, API use, and archive use.
10.6.7(d) Classification requirements shall identify data class, evidence class, output class, access class, handling class, public-safe status, personal data status, health-sensitive status, cyber-sensitive status, infrastructure-sensitive status, finance-sensitive status, commercial sensitivity, public authority status, sovereign data status, community-protected status, Indigenous or protected knowledge status, legal sensitivity, export-control sensitivity, sanctions sensitivity, controlled-technology sensitivity, and correction sensitivity.
10.6.7(e) Retention, deletion, sealing, archive, and legal hold requirements shall identify retention period, retention basis, deletion triggers, deletion exceptions, sealing triggers, archive class, archive location, legal hold basis where any, access restrictions, continuing prohibited uses, correction relationship, supersession relationship, withdrawal relationship, retraction relationship, and closeout status.
10.6.7(f) Transfer and cross-border requirements shall identify allowed transfers, prohibited transfers, recipient classes, jurisdictions, localization requirements, data residency requirements, sovereign data zones, compute-to-data treatment, secure enclave treatment, no-download treatment, public authority restrictions, community restrictions, protected knowledge restrictions, provider restrictions, sponsor restrictions, host restrictions, operator restrictions, export-control review, sanctions review, controlled-technology review, and notice obligations.
10.6.7(g) AI-use requirements shall identify whether data may be used for AI training, fine-tuning, model improvement, embedding, retrieval, inference, evaluation, benchmarking, digital twin use, simulation use, or public AI tool processing, and shall prohibit sensitive Nexus, GCRI Canada, public authority, personal, health-sensitive, cyber-sensitive, infrastructure-sensitive, community-protected, Indigenous, protected knowledge, confidential, or restricted materials for AI training or model improvement without express recorded authority.
10.6.7(h) Publication requirements shall identify whether data may be used in public-safe summaries, controlled annexes, restricted annexes, dashboards, maps, APIs, datasets, reports, technical notes, Academy materials, public authority learning materials, provider materials, sponsor materials, host materials, media materials, repositories, or public claims, subject to public-safe review, boundary language, permitted uses, prohibited uses, and correction path.
10.6.7(i) Correction requirements shall require notification, review, correction, restriction, supersession, withdrawal, retraction where applicable, deletion, sealing, reissue, archive marking, dependency notice, and closeout where data are erroneous, misclassified, unlawfully used, unsupported, public-safe defective, privacy defective, cybersecurity defective, sovereign-data defective, protected-knowledge defective, public-authority defective, rights-defective, AI-use defective, publication-defective, or otherwise unreliable.
10.6.7(j) The controlling rule shall be that no data contract is valid for material GCRI Canada use unless it states why data may be used, for what purpose, under what classification, where it may move, whether AI may touch it, whether it may be published, and how it must be corrected.
10.6.8 Interface Specifications Without Certification, Procurement Preference, Finance-Readiness, Public Authority Meaning, or Protocol Effect by Default. 10.6.8(a) No schema, API, data contract, interface specification, endpoint, data field, validation rule, alignment rule, mapping rule, access grant, token, API key, data exchange, proof receipt, interface log, dashboard integration, map integration, Evidence Pack integration, Decision Pack integration, public-safe summary integration, or correction signal shall create certification, procurement preference, finance-readiness, public authority meaning, protocol effect, professional certification, operational clearance, deployment approval, market authority, public warning, emergency command, or execution consequence by default.
10.6.8(b) Interface specifications shall not be described by GCRI Canada as certification criteria, conformance criteria, procurement specifications, finance-readiness criteria, public authority requirements, regulatory requirements, compliance criteria, provider qualification criteria, host approval criteria, operator approval criteria, protocol rules, professional qualification criteria, operating rules, public warning rules, emergency command rules, deployment approval rules, or execution instructions unless a competent separate actor has created such status through its own authority and records.
10.6.8(c) Technical compatibility with a schema, API, data contract, or interface specification shall not be described as certified, approved, recognized, finance-ready, procurement-ready, public authority-approved, protocol-effective, Nexus-compatible, provider-preferred, sponsor-approved, host-approved, operator-approved, professionally qualified, deployment-approved, operationally cleared, market-ready, safe, secure, resilient, or execution-ready by GCRI Canada.
10.6.8(d) API access or successful data exchange with GCRI Canada systems shall not be used as evidence that the API consumer is certified, recognized, approved, finance-ready, procurement-ready, public authority-approved, provider-preferred, sponsor-approved, host-approved, operator-approved, protocol-effective, professionally qualified, deployment-approved, operationally cleared, or execution-ready.
10.6.8(e) Where public authorities use, request, review, comment on, access, map to, integrate with, or receive data through schemas, APIs, data contracts, or interface specifications, such activity shall not create public authority adoption, official guidance, regulatory determination, compliance determination, enforcement position, procurement approval, funding approval, public finance approval, public-law status, public warning, emergency command, certification, recognition, finance-readiness, provider endorsement, sponsor approval, host approval, operator instruction, protocol effect, deployment approval, legal status, market authority, or execution consequence by implication.
10.6.8(f) Where Protocol Authority uses, requests, reviews, comments on, tests, maps to, integrates with, or receives data through schemas, APIs, data contracts, or interface specifications, such activity shall not create protocol effect, conformance status, Nexus-compatible status, certification, procurement qualification, finance qualification, provider qualification, host qualification, public authority meaning, market entitlement, deployment approval, operational clearance, or execution consequence unless separately created by the competent Protocol Authority through its own authority and records.
10.6.8(g) Where GRA, Nexus Rails, capital readers, insurers, lenders, investors, National Companies, Project SPVs, procurement actors, providers, sponsors, hosts, or operators use or receive information through schemas, APIs, data contracts, or interface specifications, such activity shall not create finance-readiness, investment advice, rating, guarantee, insurance approval, lending decision, underwriting decision, procurement approval, provider preference, sponsor validation, host approval, operator approval, project approval, deployment approval, operational clearance, market signal, or execution consequence by GCRI Canada.
10.6.8(h) Where interface specifications are misused to imply certification, procurement preference, finance-readiness, public authority meaning, protocol effect, provider endorsement, sponsor approval, host approval, operator instruction, professional certification, deployment approval, operational clearance, public warning, emergency command, or execution consequence, GCRI Canada shall correct, relabel, restrict, withdraw, reissue, request removal of misleading references, issue public-safe or controlled clarification, notify affected interfaces where appropriate, suspend affected use where within its control, or pursue contractual or legal remedies where appropriate.
10.6.8(i) The controlling rule shall be that interface compatibility is not institutional status; it is a bounded technical relationship subject to version, permission, purpose, classification, public-safe treatment, and correction.
10.6.9 API, Schema, and Data Contract Incident Handling. 10.6.9(a) GCRI Canada shall maintain incident handling methods for suspected or confirmed incidents affecting APIs, schemas, data dictionaries, data contracts, interface specifications, endpoint behavior, validation rules, access controls, authentication, authorization, rate limits, logging, monitoring, keys, tokens, credentials, data exchange, public-safe filtering, schema mappings, semantic mappings, proof receipts, interface logs, and correction signals.
10.6.9(b) API incidents may include unauthorized access, excessive access, credential compromise, token compromise, key compromise, secret exposure, endpoint misuse, endpoint probing, public-safe filter bypass, restricted-field exposure, unauthorized export, error-message leakage, stale-data response, incorrect response, incorrect timestamp, incorrect version, access control failure, rate-limit failure, logging failure, monitoring failure, API abuse, denial of service, cross-border defect, public authority data exposure, protected knowledge exposure, or correction failure.
10.6.9(c) Schema incidents may include field misdefinition, validation error, classification error, required-field omission, sensitive-field mislabeling, boundary-language omission, deprecated-field use, breaking change without notice, semantic mapping error, false equivalence, context collapse, crosswalk defect, public-safe field exposure, confidence-field defect, uncertainty-field defect, limitation-field defect, correction-field defect, or dependency defect.
10.6.9(d) Data contract incidents may include missing lawful basis, unsupported purpose, excessive use, unauthorized transfer, unauthorized cross-border transfer, retention breach, deletion breach, sealing breach, archive breach, AI-use breach, unauthorized training, unauthorized fine-tuning, unauthorized embedding, unauthorized retrieval, unauthorized publication, public-safe defect, privacy defect, cybersecurity defect, sovereign data defect, protected knowledge defect, public authority defect, provider defect, sponsor defect, host defect, operator defect, or correction failure.
10.6.9(e) Incident records shall identify incident title or identifier, incident class, affected API, affected schema, affected field, affected endpoint, affected data contract, affected interface specification, affected consumer, affected provider where safe and material, affected records, affected outputs, affected data classes, affected evidence classes, affected output classes, affected access classes, affected handling classes, public-safe status, suspected or confirmed status, severity where used, confidence, uncertainty, containment actions, correction actions, notification decisions, dependency notices, residual risk, and closeout status.
10.6.9(f) Containment may include endpoint suspension, endpoint restriction, token revocation, key rotation, credential rotation, access revocation, rate-limit change, schema rollback, schema patch, field suppression, validation update, data contract suspension, data transfer suspension, cross-border transfer suspension, AI-use suspension, retrieval restriction, embedding restriction, dashboard restriction, map restriction, API documentation correction, public-safe output withdrawal, controlled notice, public authority notice, community notice, provider notice, sponsor notice, host notice, operator notice, Protocol Authority notice, GRF notice, GRA notice, National Company notice, Project SPV notice, and dependency review.
10.6.9(g) Post-incident review shall assess root cause where appropriate, affected dependencies, affected outputs, affected public-safe materials, affected interfaces, affected public claims, classification impact, privacy impact, cybersecurity impact, sovereign data impact, public authority impact, community safeguard impact, protected knowledge impact, provider-neutrality impact, sponsor non-control impact, host-boundary impact, operator-boundary impact, finance-boundary impact, procurement-boundary impact, certification-boundary impact, recognition-boundary impact, protocol-boundary impact, correction effectiveness, training updates, method updates, technical-control updates, and Board or committee reporting where material.
10.6.9(h) API, schema, and data contract incident handling shall not create certification, recognition, finance-readiness, public authority decision, regulatory finding, procurement approval, provider endorsement, sponsor finding, host finding, operator finding, rating, guarantee, public warning, emergency command, security certification, protocol effect, professional certification, operational clearance, legal status, market authority, remediation approval, deployment approval, or execution consequence by default.
10.6.9(i) The controlling rule shall be that interface incidents must be handled as both technical failures and meaning failures, because errors in fields, endpoints, permissions, and contracts can travel farther than the systems that produced them.
10.6.10 API, Schema, Data Contract, and Interface Specification Records. 10.6.10(a) GCRI Canada shall maintain, or cause to be maintained, records for material APIs, schemas, data dictionaries, data contracts, interface specifications, endpoint classes, field definitions, validation rules, semantic mappings, data exchanges, interface logs, access grants, tokens, keys, public-safe filters, correction signals, dependency notices, incident records, assurance records, release records, deprecation records, sunset records, archive records, and closeout records.
10.6.10(b) Schema records shall identify schema title or identifier, version, steward, custodian, repository or storage location, purpose, scope, source vocabulary, ontology dependency, data dictionary dependency, field definitions, field sensitivity, validation rules, public-safe status, access class, handling class, license status, dependency status, compatibility status, deprecation status, correction path, supersession path, withdrawal path, and archive path.
10.6.10(c) API records shall identify API title or identifier, version, steward, custodian, endpoint classes, audience, authentication requirements, authorization requirements, token rules, key rules, rate limits where applicable, logging rules, monitoring rules, public-safe filtering rules, export rules, error-message safety rules, access class, handling class, public-safe status, security status, dependency status, incident status, deprecation status, sunset status, correction path, and archive path.
10.6.10(d) Data contract records shall identify contract title or identifier, data source, data provider, data recipient, purpose, lawful basis or recorded authority, permitted uses, prohibited uses, data classes, evidence classes, output classes, access classes, handling classes, public-safe status, retention, deletion, sealing, archive, legal hold, transfer, cross-border treatment, sovereign data treatment, AI-use treatment, publication treatment, correction obligations, notification obligations, closeout obligations, and dependency links.
10.6.10(e) Interface specification records shall identify interface title or identifier, sending actor, receiving actor, purpose, materials exchanged, schemas used, APIs used, data contracts used, access controls, public-safe status, data class, evidence class, output class, IP status, license status, security status, permitted uses, prohibited uses, boundary language, correction path, dependency path, notice path, and closeout path.
10.6.10(f) Interface logs shall identify date, version, request or exchange class, actor role, access event where material, materials shared, materials received, public-safe status, classification status, correction status, dependency status, notice status, and any limitations necessary to prevent reliance beyond the recorded interface purpose.
10.6.10(g) Correction records shall identify corrected schema, corrected API, corrected endpoint, corrected field, corrected data dictionary, corrected data contract, corrected interface specification, corrected interface log, corrected public-safe filter, corrected boundary language, corrected access rule, corrected token rule, corrected key rule, prior status, corrected status, effective date, reviewer, affected dependencies, notice decision, access change, archive treatment, and continuing limitations.
10.6.10(h) API, schema, data contract, and interface specification records shall be linked, where applicable, to the Public-Good Technical Asset Register, Observatory Methods Register, Nexus Truth Engine Methods Register, Evidence Register, Dataset Register, Model Register, System Card Register, Benchmark Card Register, Compute Workload Register, Inference Register, Proof Receipt Register, Dashboard Register, Geospatial and Mapping Register, Digital Twin and Simulation Register, Observatory Evidence Pack Register, Observatory Incident Register, Correction Register, Nexus Universe records, Grid records, Docket records, Rails records, Risk Management records, Academy records, GRF interface records, GRA interface records, Protocol Authority interface records, National Company records, Project SPV records, provider records, sponsor records, host records, operator records, public authority records, community records, university records, media materials, public claims records, assurance records, release records, and archive records.
10.6.10(i) API, schema, data contract, interface specification, interface log, correction, incident, assurance, release, deprecation, sunset, archive, Board, committee, and closeout records shall not create certification, recognition, finance-readiness, public authority decision, regulatory finding, procurement approval, provider endorsement, sponsor approval, host approval, operator approval, community consent, Indigenous consent, rating, guarantee, public warning, emergency command, security certification, protocol effect, professional certification, operational clearance, legal status, market authority, infrastructure operation, remediation approval, deployment approval, national authority, regional authority, GRF maturity record, GRA finance-readiness, Docket approval, Grid maturity record, Rails finance authority, Academy certification, or execution consequence by default.
10.6.10(j) The controlling rule shall be that APIs, schemas, data contracts, and interface specifications are trustworthy only when their meaning, permissions, versions, access controls, records, incidents, corrections, dependencies, and boundaries remain traceable and correctable.
10.7 Ontology, Taxonomy, and Controlled Vocabulary Assets
10.7.1 Ontology Assets as Public-Good Semantic Infrastructure. 10.7.1(a) GCRI Canada may steward ontology assets as public-good semantic infrastructure for structuring, defining, relating, disambiguating, translating, mapping, retrieving, interpreting, publishing, correcting, and assuring concepts used in GCRI Canada’s evidence, methods, observability, ontology, interoperability, verifiable compute, verifiable intelligence, public-safe publication, public-good software, open technical baseline, public authority learning, community safeguard, correction, and assurance work.
10.7.1(b) Ontology assets may include conceptual models, semantic graphs, term sets, class hierarchies, relationship models, controlled definitions, entity models, evidence models, data-class models, output-class models, interface models, risk-domain models, technology-domain models, institutional-role models, public authority capacity models, finance-boundary models, recognition-boundary models, protocol-boundary models, public-safe publication models, correction models, and semantic mappings across Nexus instruments.
10.7.1(c) Ontology assets shall be treated as semantic infrastructure because they preserve shared meaning across GCRI Canada, GCRI US, The Global Risks Forum (GRF), The Global Risks Alliance (GRA), Nexus Standards / Protocol Authority, Nexus Observatory, Nexus Truth Engine, Nexus Risk Management, Nexus Rails, Nexus Grid, Nexus Docket, Nexus Academy, Nexus Universe, Regional Nexus Consortiums, National Nexus Consortiums, National Companies, Project SPVs, public authorities, communities, universities, providers, sponsors, hosts, operators, and capital-reader interfaces.
10.7.1(d) Ontology assets shall support clarity, interoperability, traceability, source-lineage discipline, AI retrieval discipline, public-safe explanation, records discipline, boundary discipline, role separation, correctionability, translation discipline, localization discipline, and consistency across public-good technical assets and institutional instruments.
10.7.1(e) Ontology assets shall not be treated as legal codes, public authority instruments, regulatory classifications, public warning categories, finance classifications, procurement categories, certification categories, recognition categories, protocol categories, professional qualification categories, market categories, operational commands, or execution instructions by default.
10.7.1(f) Ontology assets shall be reviewable, versioned, source-lined where applicable, stewarded, custodian-assigned, rights-aware, public-safe where released, restricted where required, translation-aware, localization-aware, AI-use-aware, retrieval-aware, confidence-aware where mapping requires confidence, uncertainty-aware where meaning is contested, limitation-aware, and correctionable.
10.7.1(g) Where ontology assets are used by AI systems, retrieval systems, embedding systems, dashboards, maps, APIs, Evidence Packs, Decision Packs, public-safe summaries, Academy materials, public authority learning materials, GRF inputs, GRA inputs, Protocol Authority inputs, or public claims, GCRI Canada shall preserve term source, version, scope, permitted use, prohibited use, boundary language, public-safe status, correction path, and semantic limitations where material.
10.7.1(h) The controlling rule shall be that ontology assets create shared meaning for public-good use, not legal authority, public authority adoption, finance-readiness, procurement preference, certification, recognition, protocol effect, or execution.
10.7.2 Taxonomy Assets for Risks, Technologies, Evidence, Maturity, Safeguards, Public Authority Capacity, Data Classes, AI Classes, Cyber Classes, Observatory Classes, and Nexus Interfaces. 10.7.2(a) GCRI Canada may steward taxonomy assets for risks, technologies, evidence, maturity inputs, safeguards, public authority capacity, data classes, AI classes, cyber classes, Observatory classes, Truth Engine classes, compute classes, output classes, interface classes, asset classes, incident classes, correction classes, assurance classes, public-safe publication classes, and other Nexus-relevant categories.
10.7.2(b) Risk taxonomy assets may classify systemic risk, resilience risk, infrastructure risk, AI risk, cyber risk, biosecurity risk, climate risk, nature risk, water risk, energy risk, food risk, health risk, supply-chain risk, public-trust risk, finance-boundary risk, procurement-boundary risk, public authority risk, community safeguard risk, protected knowledge risk, provider capture risk, sponsor control risk, and correction risk.
10.7.2(c) Technology taxonomy assets may classify AI, machine learning, generative AI, agentic AI, AI-RAN, O-RAN, private wireless, DePIN, blockchain, DLT, Web3, cyber-physical systems, cybersecurity tools, sensors, Earth observation, geospatial systems, digital twins, simulations, robotics, drones, quantum-relevant systems, high-performance compute, sovereign compute, edge compute, semiconductors, advanced manufacturing, energy systems, climate systems, nature systems, WEFH systems, and related exponential or mission-critical technologies.
10.7.2(d) Evidence taxonomy assets may classify sources, source authority, source independence, evidence classes, data classes, output classes, review status, confidence status, uncertainty status, limitation status, contradiction status, dispute status, stale-data status, public-safe status, controlled-annex status, restricted-annex status, correction status, supersession status, withdrawal status, retraction status, archive status, and dependency status.
10.7.2(e) Maturity taxonomy assets may classify maturity evidence inputs, stage-truth inputs, readiness evidence inputs, safeguard maturity inputs, methods maturity inputs, observability maturity inputs, public-safe maturity inputs, correction maturity inputs, training maturity inputs, assurance maturity inputs, and Grid-facing input classes, but shall not create public-facing maturity records, competence recognition, professional certification, GRF maturity records, finance-readiness, procurement approval, or execution status by GCRI Canada.
10.7.2(f) Safeguard taxonomy assets may classify privacy safeguards, cybersecurity safeguards, sovereign data safeguards, community safeguards, Indigenous safeguards where applicable, protected knowledge safeguards, public authority safeguards, public-safe publication safeguards, AI-use safeguards, retrieval safeguards, embedding safeguards, provider-neutrality safeguards, sponsor non-control safeguards, host-boundary safeguards, operator-boundary safeguards, finance-boundary safeguards, procurement-boundary safeguards, protocol-boundary safeguards, and correction safeguards.
10.7.2(g) Public authority capacity taxonomy assets may classify regulator-listening participation, public finance reader participation, emergency-management participation, public health participation, public safety participation, public infrastructure operator participation, public data contributor participation, public authority learner participation, public observer participation, public procurement actor participation, public funding actor participation, intergovernmental participation, Indigenous public governance participation where applicable, and other public authority interface capacities without creating delegation, endorsement, official guidance, public warning, emergency command, funding approval, procurement approval, or public authority decision.
10.7.2(h) Data, AI, cyber, Observatory, and interface taxonomy assets may classify data sensitivity, AI model type, model risk class, dataset class, inference class, retrieval class, embedding class, cyber incident class, vulnerability class, sensor class, Node class, Hub class, Cluster class, Hotspot class, National Dense Core evidence class, API class, data contract class, Evidence Pack class, Decision Pack class, public-safe output class, GRF interface class, GRA interface class, Protocol Authority interface class, Rails interface class, Grid interface class, Docket interface class, Academy interface class, National Company interface class, Project SPV interface class, provider interface class, sponsor interface class, host interface class, operator interface class, public authority interface class, and community interface class.
10.7.2(i) Taxonomy assets shall not be used to create hidden rankings, ratings, certifications, recognitions, procurement filters, finance signals, provider rankings, sponsor validations, host approvals, public authority determinations, protocol effects, public warning categories, emergency command categories, or execution statuses by default.
10.7.2(j) The controlling rule shall be that taxonomy assets classify for clarity, evidence discipline, safeguards, and correction; they do not classify for authority, status, finance, procurement, certification, recognition, protocol effect, or execution by implication.
10.7.3 Controlled Vocabulary Assets for Core Charter, Bylaw, Nexus, Evidence, Claims, Finance, Recognition, Protocol, Public Authority, and Public-Safe Terms. 10.7.3(a) GCRI Canada may steward controlled vocabulary assets for core Charter terms, bylaw terms, Nexus terms, evidence terms, observability terms, Truth Engine terms, verifiable compute terms, verifiable intelligence terms, public-good technical asset terms, public-safe publication terms, correction terms, assurance terms, claim terms, finance-boundary terms, recognition-boundary terms, protocol-boundary terms, public authority terms, community safeguard terms, protected knowledge terms, provider-neutrality terms, sponsor non-control terms, host-boundary terms, operator-boundary terms, and non-execution terms.
10.7.3(b) Controlled vocabulary assets shall define preferred terms, permitted terms, prohibited terms, deprecated terms, restricted terms, public-safe terms, controlled-room terms, translation notes, localization notes, plain-language equivalents where appropriate, legal-boundary notes, public authority boundary notes, finance-boundary notes, procurement-boundary notes, certification-boundary notes, recognition-boundary notes, protocol-boundary notes, community-safeguard notes, protected-knowledge notes, AI-use notes, public-safe publication notes, and correction notes.
10.7.3(c) Controlled vocabulary assets shall distinguish terms that may be used internally from terms that may be used in public-safe summaries, controlled annexes, restricted annexes, public authority materials, community materials, provider-facing materials, sponsor-facing materials, host-facing materials, operator-facing materials, capital-reader materials, procurement-facing materials, Academy materials, GRF inputs, GRA inputs, Protocol Authority inputs, media materials, repositories, and public claims.
10.7.3(d) Claims vocabulary shall prevent unrecorded, exaggerated, misleading, authority-like, certification-like, recognition-like, finance-like, procurement-like, provider-preferential, sponsor-validating, host-approving, operator-commanding, public-warning-like, emergency-command-like, protocol-conferring, professional-certification-like, market-status-like, or execution-like language.
10.7.3(e) Finance vocabulary shall distinguish evidence input, finance-safe summary, capital-reader literacy, GRA input, Rails input, RNFD input, NFD input, UNFSD input, resilience evidence, readiness evidence input, and finance-boundary material from finance-readiness, investment advice, insurance approval, lending decision, underwriting decision, rating, guarantee, bankability, fundability, public finance approval, capital allocation, project approval, or execution instruction.
10.7.3(f) Recognition vocabulary shall distinguish evidence input, claims-discipline input, maturity evidence input, public-safe summary, GRF input, and registry-adjacent learning from GRF recognition, standing, maturity record, claims approval, public-facing legitimacy, certification, public authority approval, finance-readiness, procurement approval, or execution consequence.
10.7.3(g) Protocol vocabulary shall distinguish technical baseline, reference architecture, profile, schema, API, data contract, interoperability profile, external standards mapping, Protocol Authority input, protocol-adjacent learning, and baseline alignment from protocol effect, conformance status, Nexus-compatible status, standard adoption, certification, procurement qualification, finance qualification, provider qualification, market entitlement, or execution consequence.
10.7.3(h) Public authority and public-safe vocabulary shall distinguish public authority learning, regulator-listening participation, public finance reader participation, emergency-management participation, public health participation, public safety participation, public infrastructure operator participation, public authority data contribution, public authority review, and public-safe publication from official guidance, regulatory determination, compliance determination, public warning, emergency command, procurement approval, funding approval, public finance approval, public-law status, delegation, endorsement, or public authority decision.
10.7.3(i) Controlled vocabulary assets shall be attached to templates, dashboards, maps, APIs, schemas, data dictionaries, Evidence Packs, Decision Packs, public-safe publications, interface specifications, Academy materials, Board materials where material, public claims, release notes, and correction notices where necessary to preserve meaning.
10.7.3(j) The controlling rule shall be that controlled vocabulary is a constitutional safety device: the wrong word can create the wrong institutional meaning, and therefore public-good technical language must be bounded, versioned, and correctable.
10.7.4 Semantic Crosswalks, Equivalence Notes, Divergence Logs, Localization Notes, and External Standards Mappings. 10.7.4(a) GCRI Canada may steward semantic crosswalks, equivalence notes, divergence logs, localization notes, translation notes, plain-language notes, external standards mappings, public authority terminology mappings, community terminology mappings, provider terminology mappings, finance terminology mappings, procurement terminology mappings, recognition terminology mappings, protocol terminology mappings, and technical-domain mappings to support public-good interoperability and prevent false equivalence.
10.7.4(b) Semantic crosswalks shall identify source vocabulary, target vocabulary, mapped term, mapped concept, mapping relationship, mapping confidence, mapping uncertainty, mapping limitation, equivalence status, partial-equivalence status, non-equivalence status, divergence status, jurisdictional relevance, context limits, translation risk, public authority meaning risk, community meaning risk, protected knowledge risk, finance meaning risk, procurement meaning risk, certification meaning risk, recognition meaning risk, protocol meaning risk, provider meaning risk, sponsor meaning risk, host meaning risk, operator meaning risk, and correction path.
10.7.4(c) Equivalence notes shall state whether terms are equivalent, near-equivalent, partially equivalent, contextually equivalent, functionally similar, not equivalent, deprecated, prohibited, or only usable in defined contexts. Equivalence notes shall not create legal equivalence, regulatory equivalence, public authority adoption, certification equivalence, recognition equivalence, finance equivalence, procurement equivalence, protocol equivalence, professional qualification equivalence, or execution equivalence by default.
10.7.4(d) Divergence logs shall record where terms, concepts, categories, standards, public authority definitions, community definitions, technical definitions, legal terms, finance terms, procurement terms, certification terms, recognition terms, protocol terms, or public-safe terms diverge, and shall identify the reason, affected materials, affected interfaces, public-safe implications, correction implications, and prohibited assumptions.
10.7.4(e) Localization notes shall identify jurisdictional, linguistic, cultural, community, Indigenous where applicable, territorial, public authority, legal, regulatory, technical, market, finance, procurement, and public-safe context that affects the meaning or safe use of a term.
10.7.4(f) External standards mappings shall identify external standards, frameworks, taxonomies, specifications, public authority guidance, industry frameworks, academic frameworks, open-source frameworks, interoperability frameworks, cybersecurity frameworks, AI governance frameworks, data governance frameworks, and resilience frameworks referenced or mapped, including issuing body, version or date where known, mapped sections, mapping method, mapping confidence, mapping uncertainty, mapping limitations, and correction path.
10.7.4(g) Semantic mapping shall not be used to imply compliance, adoption, certification, recognition, finance-readiness, procurement qualification, public authority approval, protocol effect, professional qualification, provider endorsement, host approval, deployment approval, operational clearance, market entitlement, public warning, emergency command, or execution consequence by default.
10.7.4(h) Where semantic crosswalks, equivalence notes, divergence logs, localization notes, or external standards mappings become stale, inaccurate, misleading, overclaimed, mistranslated, legally defective, public-authority-confusing, finance-overclaiming, procurement-implying, certification-implying, recognition-implying, protocol-implying, provider-preferential, sponsor-validating, host-approving, community-harming, protected-knowledge-defective, or correction-defective, GCRI Canada shall correct, restrict, supersede, withdraw, reissue, archive, or issue clarification as appropriate.
10.7.4(i) The controlling rule shall be that semantic crosswalks make differences visible; they must not erase differences to create false equivalence or hidden authority.
10.7.5 Ontology Assets as AI Retrieval and Verifiable Intelligence Infrastructure. 10.7.5(a) GCRI Canada may use ontology assets as AI retrieval and verifiable intelligence infrastructure to support controlled retrieval, source-grounded inference, semantic routing, evidence classification, query interpretation, embedding governance, retrieval filtering, controlled vocabulary use, hallucination reduction, source-lineage preservation, public-safe output review, confidence and uncertainty treatment, limitation treatment, human review, inference records, and correction.
10.7.5(b) Ontology-supported AI retrieval shall identify approved retrieval sources, prohibited retrieval sources, source authority, source currency, source reliability, public-safe status, data classification, access class, handling class, public authority status, community safeguard status, protected knowledge status, privacy status, cybersecurity status, sovereign data status, finance-boundary status, procurement-boundary status, provider-neutrality status, sponsor non-control status, and correction path.
10.7.5(c) Ontology-supported embeddings shall be governed by ownership, custody, access controls, encryption where appropriate, logging, deletion, re-indexing, source review, stale-source treatment, cross-tenant risk, cross-program risk, cross-entity risk, cross-border risk, protected knowledge risk, public authority data risk, personal data risk, cyber-sensitive data risk, infrastructure-sensitive data risk, retrieval leakage risk, false association risk, and correction path.
10.7.5(d) Ontology assets used in verifiable intelligence shall support source comparison, evidence routing, confidence rules, uncertainty rules, limitation statements, semantic disambiguation, contradiction identification, dispute handling, correction triggers, public-safe summaries, controlled annexes, restricted annexes, and boundary language.
10.7.5(e) Ontology-supported AI and verifiable intelligence outputs shall not be treated as official truth, public authority decision, public warning, emergency command, finance-readiness, investment advice, rating, guarantee, certification, recognition, procurement approval, protocol effect, provider endorsement, sponsor approval, host approval, operator instruction, professional certification, deployment approval, operational clearance, legal status, market authority, or execution consequence by default.
10.7.5(f) Ontology assets shall not be used to train, fine-tune, improve, embed, retrieve, or infer from sensitive Nexus, GCRI Canada, public authority, personal, health-sensitive, cyber-sensitive, infrastructure-sensitive, community-protected, Indigenous, protected knowledge, confidential, or restricted materials without express recorded authority and appropriate controls.
10.7.5(g) Where ontology-supported AI retrieval produces false association, context collapse, hallucination, unauthorized retrieval, embedding leakage, retrieval leakage, stale-source reliance, protected knowledge exposure, public authority confusion, finance overclaim, procurement implication, certification implication, recognition implication, protocol implication, provider preference, sponsor validation, host approval implication, operator instruction implication, or public-safe defect, GCRI Canada shall correct, restrict, retrain only where authorized, re-index, delete where appropriate, suspend retrieval, update ontology records, issue correction signals, and initiate incident handling where material.
10.7.5(h) The controlling rule shall be that ontology assets may help AI retrieve and interpret evidence, but semantic structure shall not become authority, truth, certification, finance, procurement, protocol effect, or execution.
10.7.6 Ontology Assets Without Legal Equivalence, Regulatory Adoption, Certification, Public Authority Meaning, or Protocol Effect by Default. 10.7.6(a) No ontology asset, taxonomy asset, controlled vocabulary asset, semantic crosswalk, equivalence note, divergence log, localization note, translation note, plain-language summary, external standards mapping, AI retrieval mapping, dashboard term, API field, schema term, Evidence Pack term, Decision Pack term, public-safe publication term, or interface term shall create legal equivalence, regulatory adoption, certification, public authority meaning, protocol effect, finance-readiness, procurement qualification, professional qualification, market entitlement, public warning, emergency command, or execution consequence by default.
10.7.6(b) GCRI Canada shall not describe ontology alignment, taxonomy alignment, vocabulary alignment, semantic mapping, external standards mapping, controlled vocabulary use, or term consistency as legal compliance, regulatory compliance, public authority adoption, certification, recognition, finance-readiness, procurement readiness, protocol effect, Nexus-compatible status, provider qualification, host approval, professional qualification, operational clearance, deployment approval, market authority, or execution readiness by default.
10.7.6(c) Where an ontology asset maps to a legal term, public authority term, regulatory term, finance term, procurement term, certification term, recognition term, protocol term, or professional term, the mapping shall include boundary language stating whether the mapping is semantic, illustrative, partial, contextual, non-equivalent, externally defined, jurisdiction-specific, or subject to competent actor interpretation.
10.7.6(d) Public authority use, comment, review, data contribution, dashboard access, map access, reference, non-objection, or adoption of terminology shall not create public authority meaning, official guidance, regulatory determination, compliance determination, enforcement position, public warning, emergency command, procurement approval, funding approval, public finance approval, public-law status, certification, recognition, finance-readiness, protocol effect, provider endorsement, sponsor approval, host approval, operator instruction, deployment approval, legal status, market authority, or execution consequence unless separately and expressly created by the competent public authority through its own lawful process and records.
10.7.6(e) Protocol Authority use, discussion, review, mapping, testing, comment, pilot treatment, or adoption of terminology shall not create protocol effect, conformance status, Nexus-compatible status, certification, procurement qualification, finance qualification, provider qualification, host qualification, market entitlement, deployment approval, operational clearance, or execution consequence unless separately created by the competent Protocol Authority through its own authority and records.
10.7.6(f) GRF use of ontology assets shall not create recognition, standing, maturity record, claims approval, registry status, public-facing legitimacy, certification, finance-readiness, procurement approval, public authority meaning, protocol effect, or execution consequence by GCRI Canada. GRA use of ontology assets shall not create finance-readiness, investment advice, insurance approval, lending approval, underwriting approval, public finance approval, rating, guarantee, bankability, fundability, project approval, procurement approval, deployment approval, operational clearance, or execution consequence by GCRI Canada.
10.7.6(g) Where ontology assets are misused to imply legal equivalence, regulatory adoption, certification, public authority meaning, finance-readiness, procurement qualification, protocol effect, provider endorsement, sponsor approval, host approval, professional qualification, public warning, emergency command, market entitlement, or execution consequence, GCRI Canada shall correct, relabel, restrict, withdraw, reissue, request removal of misleading references, issue public-safe or controlled clarification, notify affected interfaces where appropriate, suspend affected use where within its control, or pursue contractual or legal remedies where appropriate.
10.7.6(h) The controlling rule shall be that semantic alignment is not legal, regulatory, financial, procurement, certification, recognition, protocol, or execution status.
10.7.7 Vocabulary Drift Detection and Correction. 10.7.7(a) GCRI Canada shall maintain vocabulary drift detection and correction methods to identify, review, correct, and prevent changes in meaning, usage, translation, localization, public-safe interpretation, public authority interpretation, finance interpretation, procurement interpretation, certification interpretation, recognition interpretation, protocol interpretation, provider interpretation, sponsor interpretation, host interpretation, operator interpretation, community interpretation, protected knowledge interpretation, or AI retrieval interpretation that may alter institutional meaning or create overclaim.
10.7.7(b) Vocabulary drift may arise through repeated informal use, public claims, media descriptions, sponsor materials, provider materials, host materials, operator materials, public authority materials, finance-facing materials, procurement-facing materials, Academy materials, translations, plain-language summaries, dashboards, maps, APIs, schema terms, ontology mappings, AI retrieval associations, embedding associations, public-safe publication edits, interface reuse, external standards mapping, or downstream actor adoption.
10.7.7(c) Drift detection shall review terms for authority drift, public warning drift, emergency command drift, finance drift, procurement drift, certification drift, recognition drift, protocol drift, provider preference drift, sponsor validation drift, host approval drift, operator instruction drift, public authority adoption drift, community consent drift, professional certification drift, market signal drift, legal-status drift, execution drift, public-safe drift, translation drift, and AI retrieval drift.
10.7.7(d) Vocabulary drift records shall identify term, source usage, affected materials, affected interfaces, affected audiences, prior meaning, drifted meaning, risk class, public-safe implications, public authority implications, finance implications, procurement implications, certification implications, recognition implications, protocol implications, provider implications, sponsor implications, host implications, operator implications, community implications, protected knowledge implications, AI implications, correction urgency, and correction path.
10.7.7(e) Corrective action may include preferred-term update, prohibited-term designation, definition revision, boundary-language revision, translation correction, localization correction, plain-language revision, dashboard label correction, map label correction, API field correction, schema correction, ontology mapping correction, AI retrieval restriction, embedding update, Evidence Pack correction, public-safe publication correction, Academy material correction, public claim correction, controlled notice, public-safe clarification, withdrawal, retraction, supersession, archive, or misuse-response action.
10.7.7(f) GCRI Canada shall treat repeated misuse of a term as evidence that the controlled vocabulary, interface design, publication template, dashboard design, public-safe explanation, training material, or boundary language may require correction, not merely as user error.
10.7.7(g) Vocabulary drift correction shall not itself create legal meaning, public authority meaning, certification, recognition, finance-readiness, procurement approval, protocol effect, professional qualification, provider endorsement, sponsor finding, host finding, operator finding, public warning, emergency command, market authority, or execution consequence by default.
10.7.7(h) The controlling rule shall be that language must be monitored after release because institutional meaning can drift even when the original definition was correct.
10.7.8 Translation, Localization, Bilingual, and Plain-Language Summary Controls. 10.7.8(a) GCRI Canada shall maintain translation, localization, bilingual, multilingual where applicable, plain-language, accessibility, and public-safe summary controls for ontology, taxonomy, controlled vocabulary, semantic crosswalk, public-safe publication, interface, Academy, public authority, community, provider, sponsor, host, operator, capital-reader, and public claims materials.
10.7.8(b) Translation and localization records shall identify source language, target language, jurisdiction, community context where applicable, Indigenous language context where applicable, local or territorial context, translator or reviewer role where appropriate, review status, public-safe status, term equivalence, non-equivalence, partial equivalence, culturally sensitive terms, protected knowledge terms, public authority terms, legal terms, finance terms, procurement terms, certification terms, recognition terms, protocol terms, boundary terms, and correction path.
10.7.8(c) Bilingual or multilingual materials shall not assume that terms have identical meaning across languages, jurisdictions, institutions, communities, legal systems, public authority contexts, finance contexts, procurement contexts, certification contexts, recognition contexts, protocol contexts, or technical domains. Where equivalence is partial or uncertain, the materials shall identify limits and avoid false equivalence.
10.7.8(d) Plain-language summaries shall simplify without changing institutional meaning. Plain-language treatment shall not remove no-authority language, no-public-warning language, no-emergency-command language, no-finance language, no-procurement language, no-certification language, no-recognition language, no-protocol-effect language, no-provider-endorsement language, no-sponsor-control language, no-host-approval language, no-operator-instruction language, no-professional-certification language, no-execution language, public-safe limitations, confidence, uncertainty, correction path, or permitted-use limits where material.
10.7.8(e) Translation, localization, and plain-language materials involving public authorities shall preserve capacity classification, non-delegation, non-endorsement, no-official-guidance, no-regulatory-determination, no-public-warning, no-emergency-command, no-procurement, no-funding, no-public-finance, no-certification, no-recognition, no-finance-readiness, no-protocol-effect unless separately created, and no-execution language.
10.7.8(f) Translation, localization, and plain-language materials involving communities, Indigenous peoples or governance bodies where applicable, local knowledge, territorial knowledge, environmental knowledge, cultural sites, sensitive sites, protected knowledge, or vulnerable communities shall preserve dignity, context, non-extraction, consent or non-consent treatment where applicable, source protection, protected knowledge safeguards, community review where required, accessibility, and correction path.
10.7.8(g) Translation and localization shall be reviewed for mistranslation, legal overclaim, public authority overclaim, finance overclaim, procurement implication, certification implication, recognition implication, protocol implication, provider preference, sponsor validation, host approval implication, operator instruction implication, community harm, protected knowledge exposure, public-safe defect, accessibility defect, and correctionability.
10.7.8(h) Where translation, localization, bilingual, multilingual, or plain-language materials are corrected, superseded, withdrawn, retracted, retired, or archived, GCRI Canada shall update affected public-safe summaries, Academy materials, dashboards, maps, APIs, Evidence Packs, Decision Packs, public authority materials, community materials, provider materials, sponsor materials, host materials, operator materials, media materials, repositories, and public claims where appropriate.
10.7.8(i) The controlling rule shall be that accessibility and plain language must increase understanding without lowering safeguards, boundaries, source integrity, or correctionability.
10.7.9 Ontology Asset Versioning, Review, Supersession, and Archive. 10.7.9(a) GCRI Canada shall maintain versioning, review, update, correction, supersession, withdrawal, retraction where necessary, deprecation, retirement, archive, dependency notice, and closeout methods for material ontology assets, taxonomy assets, controlled vocabulary assets, semantic crosswalks, equivalence notes, divergence logs, localization notes, translation notes, external standards mappings, and AI retrieval mappings.
10.7.9(b) Version records shall identify asset title or identifier, asset class, version, release date, steward, custodian, repository or storage location, prior version, successor version where any, changed terms, changed definitions, changed mappings, changed relationships, changed translations, changed public-safe status, changed boundary language, changed external standards mapping, changed AI retrieval use, changed Protocol Authority interface status, changed correction path, and archive treatment.
10.7.9(c) Review shall assess semantic accuracy, conceptual coherence, source lineage, scope, jurisdictional limits, translation adequacy, localization adequacy, public-safe status, legal-boundary status, public authority boundary status, finance-boundary status, procurement-boundary status, certification-boundary status, recognition-boundary status, protocol-boundary status, provider-neutrality status, sponsor non-control status, host-boundary status, operator-boundary status, community safeguard status, protected knowledge status, AI retrieval safety, embedding safety, dashboard use, API use, and correctionability.
10.7.9(d) Supersession shall be used where a term, taxonomy, ontology, crosswalk, mapping, translation, localization note, external standards mapping, AI retrieval mapping, or controlled vocabulary asset is replaced by a newer, corrected, safer, more precise, more public-safe, more rights-compliant, more jurisdictionally accurate, more community-appropriate, more protocol-separated, more finance-safe, more procurement-safe, or more correctionable version.
10.7.9(e) Withdrawal shall be used where an ontology asset should no longer be used or relied upon because of material error, public-safe defect, public authority confusion, finance overclaim, procurement implication, certification implication, recognition implication, protocol implication, provider preference, sponsor validation, host approval implication, operator instruction implication, mistranslation, community harm risk, protected knowledge exposure, legal defect, AI retrieval defect, embedding defect, rights defect, or unresolved correction defect.
10.7.9(f) Retraction shall be used where an ontology asset is materially unsupported, materially misleading, unsafe, improperly published, materially overclaimed, harmful, rights-defective, protected-knowledge-defective, or incapable of correction without continued public-safe risk. Retraction shall preserve records sufficient for accountability, dependency review, learning, and lawful obligations while preventing continued reliance.
10.7.9(g) Archive records shall identify archived asset, archive basis, archive date, archive location, archive class, access limits, public-safe status, citation status, continuing permitted uses, continuing prohibited uses, correction relationship, supersession relationship, withdrawal relationship, retraction relationship where any, legal hold where any, retention period, and closeout status.
10.7.9(h) GCRI Canada shall issue dependency notices or correction signals where ontology asset changes materially affect schemas, APIs, data contracts, interface specifications, Evidence Packs, Decision Packs, dashboards, maps, public-safe summaries, Academy materials, public authority materials, community materials, GRF inputs, GRA inputs, Protocol Authority inputs, Rails materials, Grid materials, Docket materials, Nexus Observatory materials, Nexus Truth Engine materials, Risk Management materials, National Company materials, Project SPV materials, provider materials, sponsor materials, host materials, operator materials, AI retrieval systems, embedding stores, external standards mappings, media materials, repositories, or public claims.
10.7.9(i) Versioning, review, correction, supersession, withdrawal, retraction, deprecation, retirement, archive, dependency notice, and closeout records shall not create certification, recognition, finance-readiness, public authority decision, regulatory finding, procurement approval, provider endorsement, sponsor approval, host approval, operator approval, rating, guarantee, public warning, emergency command, protocol effect, professional certification, legal equivalence, regulatory adoption, operational clearance, market authority, infrastructure operation, deployment approval, or execution consequence by default.
10.7.9(j) The controlling rule shall be that ontology assets must evolve with law, language, technology, evidence, community context, public-safe meaning, and correction, because stale semantics create hidden errors.
10.7.10 Ontology Asset Records and Semantic Governance Logs. 10.7.10(a) GCRI Canada shall maintain, or cause to be maintained, ontology asset records and semantic governance logs for material ontology assets, taxonomy assets, controlled vocabulary assets, semantic crosswalks, equivalence notes, divergence logs, localization notes, translation notes, plain-language summaries, external standards mappings, AI retrieval mappings, embedding mappings, dashboard term sets, API term sets, schema term sets, Evidence Pack term sets, Decision Pack term sets, public-safe publication term sets, and interface term sets.
10.7.10(b) Ontology asset records shall identify asset title or identifier, asset class, purpose, scope, domain, source materials, steward, custodian, version, release date, repository or storage location, public-safe status, access class, handling class, rights status, license status, external standards mapping status, Protocol Authority interface status, AI retrieval use status, embedding use status, dashboard use status, API use status, schema use status, public authority use status, community use status, protected knowledge status, permitted uses, prohibited uses, boundary language, review status, correction path, supersession path, withdrawal path, retraction path where applicable, archive path, and closeout status.
10.7.10(c) Term records shall identify preferred term, synonyms, prohibited terms, deprecated terms, definition, definition source, equivalent terms, non-equivalent terms, related terms, broader terms, narrower terms, translation notes, localization notes, plain-language notes, public-safe notes, public authority boundary notes, finance-boundary notes, procurement-boundary notes, certification-boundary notes, recognition-boundary notes, protocol-boundary notes, provider-neutrality notes, sponsor non-control notes, host-boundary notes, operator-boundary notes, community-safeguard notes, protected-knowledge notes, AI-retrieval notes, and correction history.
10.7.10(d) Semantic governance logs shall identify term proposals, definition proposals, taxonomy changes, ontology changes, crosswalk changes, equivalence decisions, divergence decisions, translation decisions, localization decisions, plain-language decisions, external standards mapping decisions, AI retrieval mapping decisions, reviewer comments, public-safe review, public authority boundary review, community safeguard review, protected knowledge review, finance-boundary review, procurement-boundary review, certification-boundary review, recognition-boundary review, protocol-boundary review, provider-neutrality review, sponsor non-control review, correction decisions, supersession decisions, withdrawal decisions, retraction decisions, and archive decisions.
10.7.10(e) Interface logs shall identify where ontology assets are used, shared, embedded, retrieved, mapped, cited, translated, published, or routed, including affected schemas, APIs, data contracts, interface specifications, dashboards, maps, Evidence Packs, Decision Packs, public-safe summaries, controlled annexes, restricted annexes, Academy materials, public authority materials, community materials, GRF inputs, GRA inputs, Protocol Authority inputs, Rails materials, Grid materials, Docket materials, Nexus Observatory materials, Nexus Truth Engine materials, Risk Management materials, National Company materials, Project SPV materials, provider materials, sponsor materials, host materials, operator materials, repositories, media materials, and public claims.
10.7.10(f) Correction logs shall identify corrected term, corrected definition, corrected taxonomy, corrected ontology relationship, corrected mapping, corrected translation, corrected localization note, corrected plain-language note, corrected external standards mapping, corrected AI retrieval mapping, corrected dashboard label, corrected API field, corrected schema term, corrected interface specification, corrected boundary language, prior status, corrected status, effective date, reviewer, affected dependencies, notice decision, access change, archive treatment, and continuing limitations.
10.7.10(g) Semantic governance logs shall be maintained with sufficient access control and public-safe treatment to protect privileged legal analysis, public authority restrictions, community-protected information, Indigenous or protected knowledge, confidential sources, cybersecurity-sensitive terminology, infrastructure-sensitive terminology, provider-sensitive information, sponsor-sensitive information, host-sensitive information, operator-sensitive information, finance-sensitive information, procurement-sensitive information, export-control-sensitive information, sanctions-sensitive information, controlled-technology-sensitive information, and other restricted materials.
10.7.10(h) Public-safe semantic summaries, glossaries, vocabularies, term sheets, localization notes, or plain-language explainers may be released where they can be disclosed without legal overclaim, public authority confusion, finance overclaim, procurement implication, certification implication, recognition implication, protocol implication, provider preference, sponsor validation, host approval implication, operator instruction implication, community harm, protected knowledge exposure, privacy harm, cybersecurity harm, sovereign data harm, IP breach, or execution implication.
10.7.10(i) Ontology asset records, semantic governance logs, term records, crosswalk logs, translation logs, localization logs, AI retrieval logs, correction logs, dependency notices, public-safe summaries, Board reports, committee reports, and closeout records shall not create certification, recognition, finance-readiness, public authority decision, regulatory finding, procurement approval, provider endorsement, sponsor approval, host approval, operator approval, community consent, Indigenous consent, rating, guarantee, public warning, emergency command, protocol effect, professional certification, legal equivalence, regulatory adoption, operational clearance, market authority, infrastructure operation, deployment approval, national authority, regional authority, GRF maturity record, GRA finance-readiness, Docket approval, Grid maturity record, Rails finance authority, Academy certification, or execution consequence by default.
10.7.10(j) The controlling rule shall be that semantic governance must make meaning traceable, reviewable, translatable, bounded, and correctable, so that shared language strengthens public trust without becoming hidden law, hidden finance, hidden procurement, hidden certification, hidden protocol, or hidden execution.
10.8 Evaluation Harnesses, Test Harnesses, Benchmarks, and Gold Vectors
10.8.1 Evaluation Harnesses as Public-Good Testing and Evidence Tools. 10.8.1(a) GCRI Canada may steward evaluation harnesses as public-good testing and evidence tools used to evaluate, compare, challenge, verify, falsify, calibrate, monitor, reproduce where appropriate, and improve public-good technical assets, methods, models, datasets, systems, dashboards, APIs, digital twins, sensors, AI-RAN evidence, O-RAN evidence, DePIN evidence, geospatial methods, evidence methods, public-safe publication methods, secure release methods, and correction methods.
10.8.1(b) Evaluation harnesses may include scripts, workflows, reference datasets, validation datasets, calibration datasets, test cases, negative tests, adversarial tests, edge-case sets, gold vectors, expected outputs, failure-mode tests, regression tests, public-safe publication tests, boundary-language tests, confidence tests, uncertainty tests, limitation tests, source-lineage tests, data-class tests, access-control tests, cybersecurity tests, AI governance tests, retrieval tests, embedding tests, dashboard tests, API tests, schema tests, ontology tests, data-contract tests, and correction tests.
10.8.1(c) Evaluation harnesses shall be used to produce technical evidence concerning the behavior, limits, failure modes, assumptions, dependencies, reproducibility, public-safe treatment, security posture, data handling, and correctionability of assets or methods within the scope tested. Evaluation harnesses shall not be used as self-executing certification, recognition, finance-readiness, procurement approval, public authority approval, protocol effect, provider endorsement, sponsor validation, host approval, operator instruction, professional qualification, deployment approval, operational clearance, market authority, legal status, public warning, emergency command, or execution consequence by default.
10.8.1(d) Each material evaluation harness shall identify purpose, scope, asset or method under evaluation, test conditions, data used, data class, evidence class, output class, access class, handling class, public-safe status, assumptions, dependencies, exclusions, metrics, success criteria where used, failure criteria where used, limitations, bias risks, reproducibility status, review status, steward, custodian, version, release status, permitted uses, prohibited uses, correction path, supersession path, withdrawal path, retirement path, and archive path.
10.8.1(e) Evaluation harnesses shall be designed to reveal limits and failure, not merely to demonstrate success. Where appropriate, evaluation harnesses shall include negative tests, adversarial tests, edge cases, degraded-mode cases, missing-data cases, stale-data cases, corrupted-data cases, spoofing cases, public-safe edge cases, public authority boundary cases, finance-boundary cases, procurement-boundary cases, provider-neutrality cases, sponsor non-control cases, host-boundary cases, operator-boundary cases, protected-knowledge cases, and correction cases.
10.8.1(f) Evaluation harness outputs shall be treated as technical evidence requiring source lineage, method records, confidence, uncertainty, limitations, public-safe review where externally released, human review where material, correction path, and dependency notices where downstream materials may rely on the output.