ARTICLE X. INTELLIGENCE
Section 246. Nexus Truth Engine Purpose and Non-Oracle Rule
246.1 Nexus Truth Engine Purpose. The Nexus Truth Engine, as referenced within GCRI Canada’s evidence, methods, observability, ontology, verifiable compute, public-safe intelligence, and Nexus-interface architecture, shall be understood as a method-supported infrastructure for comparing sources, assessing confidence, identifying corroboration and contradiction, surfacing uncertainty, preserving source lineage, triggering review, and supporting correctionable public-good understanding. The Truth Engine shall not be understood as a metaphysical, final, universal, automated, sovereign, regulatory, judicial, public authority, finance, certification, procurement, or execution authority. Its purpose is to strengthen disciplined evidence review and public-safe intelligence support within role-separated governance.
246.2 Truth Engine as Method-Supported Confidence and Corroboration System. The Truth Engine may support confidence and corroboration by applying recorded methods to source lineage, provenance, custody, timestamps, permissions, sensor reliability, model limitations, public authority context, community context, provider-system outputs, telemetry, cyber logs, geospatial evidence, digital twin outputs, and other evidence inputs. Confidence and corroboration shall be method-bound, context-bound, uncertainty-bearing, and correctionable, and shall not be represented as absolute truth, official truth, public authority truth, legal truth, financial truth, certified truth, or final institutional truth.
246.3 Truth Engine as Evidence Comparison Infrastructure. The Truth Engine may provide evidence comparison infrastructure for identifying alignment, divergence, contradiction, missing inputs, stale inputs, failed signals, spoofed signals, model drift, sensor drift, source disputes, public authority clarifications, community corrections, and provider or sponsor influence concerns. Such comparison may support research, observability, methods review, public-safe dashboards, controlled evidence packs, assurance packs, Board materials, council materials, public authority learning, Nexus Observatory interfaces, Nexus Grid interfaces, Nexus Rails technical evidence inputs, and correction workflows, but shall not create operative authority by comparison alone.
246.4 Truth Engine as Source-Lineage and Confidence Infrastructure. The Truth Engine may support source-lineage and confidence infrastructure by linking source identity, contribution basis, jurisdiction, timestamp, custody, classification, transformation history, method use, reviewer action, confidence score, confidence band, uncertainty note, limitation statement, correction status, supersession status, withdrawal status, and downstream dependency. Such infrastructure shall preserve validity-by-record, no-record / no-public-meaning discipline, and correctionability, and shall not allow automated outputs to substitute for competent governance records.
246.5 Truth Engine as Correction Trigger Infrastructure. The Truth Engine may generate correction triggers where records, evidence, sources, models, dashboards, maps, publications, public authority references, sponsor acknowledgments, provider references, finance-boundary statements, certification-boundary statements, procurement-sensitive statements, or Nexus interface artifacts appear inaccurate, stale, unsupported, inconsistent, disputed, overbroad, unsafe, spoofed, tampered, or misclassified. A correction trigger shall initiate review; it shall not itself constitute correction, supersession, withdrawal, retraction, public notice, controlled notice, Board action, public authority action, finance determination, certification determination, or legal determination.
246.6 Truth Engine as Public-Safe Intelligence Support. The Truth Engine may support public-safe intelligence by helping transform controlled evidence into limited, classified, reviewed, non-overclaiming, non-alarming, correctionable, and context-sensitive outputs. Public-safe Truth Engine outputs may inform public-good learning, evidence literacy, public authority learning, degraded-mode awareness, resilience indicators, technical understanding, and Nexus-compatible communication, but shall not function as public warning, emergency command, operational direction, official forecast, performance guarantee, finance-readiness statement, provider endorsement, certification, or public authority decision.
246.7 Non-Oracle Rule. The Truth Engine shall not be treated as an oracle. No person shall represent, imply, market, publish, rely upon, or design the Truth Engine as a source of unquestionable truth, final decision, autonomous authority, self-validating proof, sovereign determination, public authority action, legal judgment, investment judgment, insurance judgment, certification judgment, procurement judgment, maturity judgment, recognition judgment, or execution instruction. Every Truth Engine output shall remain subject to source limitations, method limitations, classification, human review where required, authority mapping, limitation language, challenge, correction, and record-based validity.
246.8 No Absolute Truth Claim. No Truth Engine output shall be described as absolute truth, final truth, complete truth, universal truth, real-time truth without limitation, official truth, verified truth without context, or truth immune from challenge. Terms such as truth, confidence, validation, corroboration, verification, reliability, signal, proof, assurance, and intelligence shall be used only in their defined, bounded, method-supported, evidence-dependent, and correctionable sense.
246.9 No Final Authority by Automated Output. No automated, semi-automated, AI-assisted, model-generated, rules-generated, dashboard-generated, sensor-generated, ledger-generated, telemetry-generated, or system-generated Truth Engine output shall have final authority unless separately reviewed, approved, and recorded by the competent authority for the relevant use. Automated output shall not override Board authority, officer authority, committee authority, public authority authority, legal requirements, research ethics requirements, safeguards requirements, data / AI / cyber controls, finance-boundary controls, or certification-boundary controls.
246.10 No Public Warning by Truth Engine Output. No Truth Engine output, alert, dashboard, map, confidence score, resilience indicator, degraded-mode signal, anomaly flag, cyber indicator, AI-RAN signal, O-RAN signal, DePIN signal, sensor fusion result, geospatial output, digital twin output, or public-safe summary shall be represented as an official public warning unless an authorized public authority lawfully issues such warning. GCRI Canada shall ensure that Truth Engine terminology does not imply public alerting authority.
246.11 No Emergency Command by Truth Engine Output. No Truth Engine output shall constitute emergency command, incident command, dispatch order, evacuation instruction, operational direction, responder instruction, public safety directive, infrastructure control instruction, public health order, cyber incident command, or emergency management substitution. Truth Engine outputs may support learning, evidence comparison, review, and public-safe situational understanding only within GCRI Canada’s non-executing role.
246.12 No Public Authority Decision by Truth Engine Output. No Truth Engine output shall constitute a public authority decision, governmental determination, regulatory interpretation, permit, license, funding approval, public finance approval, procurement approval, emergency declaration, policy adoption, public warning, public health directive, public safety directive, or sovereign obligation. Public authority decisions may be referenced only where issued by the public authority and recorded with capacity classification and approved reference language.
246.13 No Recognition, Maturity, Standing, Finance-Readiness, Insurance-Readiness, Certification, Procurement, Rating, or Provider Preference by Truth Engine Output. No Truth Engine output shall be represented as recognition, standing, legitimacy status, maturity status, Nexus Grid status, GRF recognition, finance-readiness, insurance-readiness, investment suitability, bankability, creditworthiness, rating, underwriting approval, public finance approval, certification, accreditation, conformity assessment, compliance approval, procurement approval, preferred provider status, provider ranking, provider endorsement, or product approval. Such status may arise only from a separate competent authority and record, if lawfully available.
246.14 Truth Engine Outputs Subject to Classification, Review, Limitation, and Correction. Each material Truth Engine output shall be classified, reviewed, limited, and correctionable before reliance or release. Review shall address source lineage, evidence status, method use, confidence, uncertainty, disputed evidence, failed signals, missing data, stale data, spoofing risk, tampering risk, public authority boundaries, data / AI / cyber sensitivity, protected knowledge, community safeguards, infrastructure sensitivity, finance-boundary exposure, certification-boundary exposure, procurement implications, provider-neutrality risk, public-safe communication, and downstream dependency.
246.15 Truth Engine Purpose Records. GCRI Canada shall maintain Truth Engine purpose records, including purpose statements, method records, authority records, non-oracle language, output-limit language, classification rules, public-safe rules, correction triggers, human-review triggers, interface records, limitation language, public authority boundary records, finance-boundary records, certification-boundary records, procurement-boundary records, provider-neutrality records, correction records, supersession records, withdrawal records, and archives.
Section 247. GCRI Canada’s Truth Engine Methods Role
247.1 GCRI Canada as Truth Engine Methods Steward. GCRI Canada may act as a steward of Truth Engine methods within its public-good technical, evidence, methods, observability, ontology, verifiable compute, and public-safe intelligence role. Such stewardship may include designing, maintaining, testing, documenting, reviewing, correcting, versioning, localizing, and publishing public-safe methods for source comparison, confidence scoring, corroboration, contradiction detection, spoof detection, failed-signal handling, missing-signal handling, correction triggers, auditability, and interoperability. GCRI Canada’s role shall be methods stewardship, not oracle operation, public authority decision-making, finance-readiness determination, certification, recognition, procurement selection, public warning, or execution.
247.2 Methods Stewardship Without Operating Monopoly. GCRI Canada’s Truth Engine methods role shall not create an operating monopoly, exclusive control, proprietary lock-in, mandatory provider position, required public authority pathway, exclusive Nexus pathway, or sole-source technical gate. Methods may be adopted, adapted, implemented, reviewed, challenged, localized, or superseded through lawful and recorded processes. GCRI Canada may steward public-good methods without controlling every deployment, implementation, system, dashboard, node, hub, consortium, national company, Project SPV, provider system, public authority system, or Observatory interface that uses related methods.
247.3 Schema Stewardship. GCRI Canada may steward Truth Engine schemas for source records, evidence records, confidence records, uncertainty records, comparison records, contradiction records, dispute records, model records, inference records, compute workload records, correction triggers, public-safe outputs, audit logs, and interface records. Schema stewardship shall define fields, relationships, metadata, classification, access controls, permitted use, prohibited use, AI-use restrictions, public authority capacity, protected knowledge status, finance-boundary status, correction status, and retention rules.
247.4 Evidence Class Stewardship. GCRI Canada may steward evidence classes used by Truth Engine methods, including raw source, reviewed source, evidence candidate, evidence record, corroborated evidence, contradictory evidence, disputed evidence, stale evidence, missing evidence, failed signal, spoofed signal, tampered signal, low-confidence evidence, provisional evidence, public-safe evidence, controlled evidence, restricted evidence, quarantined evidence, rejected evidence, superseded evidence, withdrawn evidence, retracted evidence, and archived evidence. Evidence classes shall guide review and reliance but shall not create certification, recognition, maturity, finance-readiness, public authority approval, or procurement approval.
247.5 Confidence Rule Stewardship. GCRI Canada may steward confidence rules, including confidence inputs, weighting criteria, confidence bands, score ranges, qualitative categories, confidence rationales, confidence-change triggers, human-review thresholds, public-safe limitation thresholds, downgrade triggers, escalation triggers, and correction triggers. Confidence rules shall be documented, challengeable, reviewed, and corrected. No confidence rule shall be used to conceal uncertainty, automate final authority, or transform confidence into certification, rating, maturity status, finance-readiness, or public warning.
247.6 Source Comparison Logic Stewardship. GCRI Canada may steward source comparison logic for comparing sensors, reference sensors, AI-RAN signals, O-RAN signals, DePIN telemetry, blockchain or ledger records, cyber logs, geospatial data, Earth observation, digital twins, simulations, operator observations, public authority inputs, community inputs, protected knowledge contexts, provider system outputs, and research datasets. Source comparison logic shall account for source independence, source dependency, calibration, timestamp alignment, spatial alignment, semantic alignment, method compatibility, data quality, jurisdictional context, and source incentives.
247.7 Correction Trigger Stewardship. GCRI Canada may steward correction trigger rules for identifying potential errors, contradictions, stale records, missing records, failed inputs, spoofed signals, tampering indicators, model drift, sensor drift, source disputes, public authority misdescription, protected knowledge risk, finance overclaim, certification overclaim, procurement implication, provider preference, sponsor influence, unsafe public output, or Nexus interface mismatch. Correction triggers shall route matters into review and shall not themselves decide the correction.
247.8 Public-Safe Output Method Stewardship. GCRI Canada may steward methods for creating public-safe Truth Engine outputs, including public-safe summaries, dashboards, maps, limitation statements, confidence displays, uncertainty explanations, correction notices, controlled-annex references, accessibility formats, and non-overclaim language. Public-safe output methods shall protect personal information, protected knowledge, public authority-sensitive information, cyber-sensitive information, infrastructure-sensitive information, finance-sensitive information, competition-sensitive information, confidential information, and unsafe operational details.
247.9 Auditability Method Stewardship. GCRI Canada may steward auditability methods for Truth Engine operations, including source logs, ingestion logs, transformation logs, model-use logs, compute workload logs, reviewer logs, confidence-change logs, output-generation logs, human-review logs, correction logs, override logs, access logs, incident logs, drift logs, spoof indicators, tamper indicators, retention controls, and repository controls. Auditability methods shall preserve integrity and accountability without exposing sensitive details through unsafe publication.
247.10 Interoperability Method Stewardship. GCRI Canada may steward interoperability methods connecting Truth Engine records to GCRI US, The Global Risks Forum (GRF), The Global Risks Alliance (GRA), Nexus Observatory, Nexus Standards, Nexus Grid, Nexus Docket, Nexus Rails, Nexus Network, Nexus Universe, Nexus Academy, consortiums, National Consortium Companies, Project SPVs, public authorities, hosts, providers, communities, universities, and laboratories. Interoperability methods shall preserve legal separateness, role separation, no-agency, no-merger, no-shared-liability, non-execution, classification, and correctionability.
247.11 Truth Engine Interface With GCRI US. GCRI Canada may interface Truth Engine methods with GCRI US for technical research, public-good software, evidence methods, ontology, observability, verifiable compute, auditability, public-safe outputs, and correctionability. Such interface shall preserve separate corporate authority, separate records, separate Board oversight, separate treasury, separate liability, separate publication authority, and no automatic adoption of GCRI US Truth Engine records or outputs by GCRI Canada.
247.12 Truth Engine Interface With The Global Risks Forum (GRF). GCRI Canada may interface Truth Engine records and methods with The Global Risks Forum (GRF) where such interface supports claims discipline, public-facing legitimacy records, recognition-adjacent review, maturity-record correction, stakeholder formation, public-safe reporting, and correction notices. Such interface shall not cause GCRI Canada to become GRF, shall not cause GRF recognition to arise from GCRI Canada methods alone, and shall not transform Truth Engine confidence outputs into standing or legitimacy determinations.
247.13 Truth Engine Interface With The Global Risks Alliance (GRA). GCRI Canada may interface Truth Engine methods with The Global Risks Alliance (GRA) for convening support, public authority learning, stakeholder engagement, public-safe communication, and alliance capacity formation. GRA participation shall not convert Truth Engine outputs into public authority decisions, finance-readiness determinations, certification, procurement recommendations, recognition, public warnings, or execution instructions.
247.14 Truth Engine Interface With Nexus Observatory, Nexus Standards, Nexus Grid, Nexus Docket, Nexus Rails, and Nexus Network. GCRI Canada may interface Truth Engine methods with Nexus Observatory for observability evidence; Nexus Standards for semantic and method alignment; Nexus Grid for maturity-surface evidence inputs where separately governed; Nexus Docket for record routing, issue tracking, and correction discipline; Nexus Rails for technical evidence inputs and finance-boundary records where separately governed; and Nexus Network for institutional coordination. Each interface shall include boundary language, classification, authority mapping, correction path, and no-overclaim controls.
247.15 No GCRI Canada Truth Engine Role as Recognition, Finance, Certification, Procurement, Public Warning, or Execution Role. GCRI Canada’s Truth Engine methods role shall not be represented as recognition authority, maturity authority, finance-readiness authority, investment advisor, securities advisor, insurer, underwriter, rating agency, lender, capital arranger, procurement authority, certification authority, accreditation body, conformity assessment body, public warning authority, emergency command body, public authority substitute, provider selection body, operator, developer, implementation contractor, or execution vehicle. Any use of Truth Engine methods by another actor shall remain subject to that actor’s lawful authority and separate record.
247.16 Truth Engine Methods Records. GCRI Canada shall maintain Truth Engine methods records, including method charters, schema records, evidence class records, confidence rule records, comparison logic records, correction trigger records, public-safe output method records, auditability method records, interoperability method records, GCRI US interface records, GRF interface records, GRA interface records, Nexus Observatory interface records, Nexus Standards interface records, Nexus Grid interface records, Nexus Docket interface records, Nexus Rails interface records, Nexus Network interface records, corrections, supersessions, withdrawals, retirements, and archives.
Section 248. Source Comparison Logic for Sensors, Reference Sensors, AI-RAN Signals, DePIN Telemetry, Cyber Logs, Geospatial Data, Earth Observation, Digital Twins, Operator Observations, Public Authority Context, Community Context, and Provider Systems
248.1 Source Comparison Purpose. Source comparison shall be used to determine whether sources corroborate, contradict, qualify, contextualize, weaken, supersede, or fail to support a proposed evidence claim, observability output, dashboard indicator, map layer, method conclusion, technical baseline, public-safe summary, Truth Engine output, or Nexus interface artifact. Source comparison shall improve disciplined evidence review and shall not be used to produce final public authority decisions, emergency commands, public warnings, recognition, finance-readiness, certification, procurement approval, or provider preference.
248.2 Source Type Identification. Before comparison, each source shall be identified by type, including sensor, reference sensor, AI-RAN signal, O-RAN signal, DePIN telemetry, blockchain or ledger record, cyber log, geospatial data, Earth observation, digital twin output, simulation output, operator observation, public authority input, community input, protected knowledge input, provider system output, research dataset, model output, public record, publication, repository record, or human testimony. Source type shall guide reliability review, weighting, limitation, and correction path.
248.3 Sensor Source Comparison. Sensor sources shall be compared by reference to sensor identity, location, calibration, maintenance, timestamp, measurement method, environmental conditions, error bounds, drift history, transmission integrity, missing data, tampering risk, and corroborating signals. Sensor comparisons shall distinguish independent signals from multiple readings generated by the same device, same vendor system, same network, same data pipeline, or same flawed calibration basis.
248.4 Reference Sensor Comparison. Reference sensors may be used as higher-trust comparison points where their calibration, custody, authority, maintenance, independence, and measurement reliability are recorded. Reference sensor comparison shall identify whether the reference sensor is actually independent, current, properly maintained, fit for the measured phenomenon, and appropriate to the relevant jurisdiction, environment, infrastructure, or public authority context.
248.5 AI-RAN Signal Comparison. AI-RAN signals shall be compared by reference to network context, radio access conditions, edge compute dependencies, AI inference pathway, model identity, vendor dependencies, privacy restrictions, cyber posture, configuration state, timestamp integrity, signal loss, degraded-mode behavior, and corroboration from non-AI-RAN sources where available. AI-RAN comparison shall not imply telecom certification, provider preference, network performance warranty, public warning, emergency command, procurement approval, or finance-readiness.
248.6 O-RAN Signal Comparison. O-RAN signals shall be compared by reference to open-interface context, component identity, architecture, vendor relationships, interoperability assumptions, telemetry reliability, configuration state, security posture, operational sensitivity, and corroboration. O-RAN comparison shall distinguish standards-aligned architecture from actual operational performance, security posture, public authority approval, procurement suitability, or provider endorsement.
248.7 DePIN Telemetry Comparison. DePIN telemetry shall be compared by reference to node identity, device trust, location claim, participation rules, sybil resistance, incentive structure, oracle dependency, ledger delay, uptime claim, privacy restriction, cyber risk, economic manipulation risk, and corroborating non-DePIN sources. Decentralized or tokenized telemetry shall not be presumed neutral, accurate, public-benefit aligned, or tamper-proof by design.
248.8 Blockchain or Ledger Record Comparison. Blockchain or ledger records may be compared for existence, sequence, timestamp, hash reference, transaction state, attestation, or recorded state change. Such comparison shall not by itself prove legal authority, truth of underlying facts, identity, permission, absence of coercion, absence of fraud, compliance, public authority approval, finance-readiness, certification, procurement suitability, or public-good alignment. Off-chain context and governance records shall be reviewed.
248.9 Cyber Log Comparison. Cyber logs shall be compared by reference to source system, log completeness, timestamp synchronization, retention gaps, alert logic, false positive risk, false negative risk, tampering risk, chain of custody, incident context, access control, and corroboration from independent logs or system records. Cyber log comparison shall protect sensitive details and shall not expose vulnerabilities through public outputs.
248.10 Geospatial Data Comparison. Geospatial data shall be compared by reference to coordinate accuracy, resolution, projection, timestamp, source platform, collection method, privacy sensitivity, infrastructure sensitivity, protected knowledge sensitivity, public authority sensitivity, ecological sensitivity, and public-safe mapping requirements. Geospatial comparison shall account for scale, generalization, outdated base layers, and the difference between mapped representation and ground truth.
248.11 Earth Observation and Remote-Sensing Comparison. Earth observation and remote-sensing sources shall be compared by reference to platform, sensor type, resolution, collection date, processing level, atmospheric conditions, cloud cover, seasonal conditions, licensing, uncertainty, interpretation limits, corroborating observations, ecological sensitivity, public authority sensitivity, and protected knowledge concerns. Remote-sensing comparison shall not overstate inference where ground validation or contextual review is absent.
248.12 Digital Twin Output Comparison. Digital twin outputs shall be compared by reference to model structure, input lineage, assumptions, calibration, validation, scenario conditions, boundary conditions, sensitivity analysis, uncertainty, version, data currency, and fitness for purpose. Digital twin outputs shall be compared against observed data where possible and shall not be treated as actual outcomes, official forecasts, operational instructions, emergency commands, finance bases, or guarantees.
248.13 Simulation Output Comparison. Simulation outputs shall be compared by reference to scenario design, assumptions, parameters, method validity, boundary conditions, input quality, reproducibility, sensitivity, uncertainty, and applicability. Simulation comparison shall distinguish scenario-dependent outputs from observed evidence and shall not convert simulated results into public warnings, public authority decisions, investment judgments, insurance judgments, or procurement conclusions.
248.14 Operator Observation Comparison. Operator observations shall be compared by reference to observer role, system access, time, operating conditions, incentives, conflicts, memory limits, corroborating system records, public authority context, provider context, infrastructure sensitivity, and operational security. Operator observations may be valuable contextual evidence but shall not substitute for official public authority decision, provider certification, or independent technical validation.
248.15 Public Authority Context Comparison. Public authority inputs shall be compared by reference to capacity classification, authority basis, official or observer status, confidentiality, data rights, public reference permissions, jurisdiction, timing, applicable legal framework, and correction rights. Public authority context comparison shall preserve the distinction between public authority participation and public authority decision, and shall not imply endorsement, delegation, funding, procurement approval, regulatory approval, public warning, public finance approval, or sovereign obligation.
248.16 Community Context Comparison. Community inputs shall be compared by reference to context, lived experience, local knowledge, consent or authorization where applicable, confidentiality, attribution, power imbalance, harm risk, representativeness, protected knowledge status, correction rights, withdrawal rights, and public-safe representation. Community context shall not be flattened into generic evidence or used to expose community vulnerabilities.
248.17 Indigenous, Local, Territorial, Cultural, Environmental, and Protected Knowledge Context Comparison Where Lawful and Appropriate. Where lawful and appropriate, Indigenous, local, territorial, cultural, environmental, and protected knowledge inputs shall be compared only under applicable safeguards, custodial authority, consent or authorization, access restrictions, publication limits, AI-use restrictions, non-extraction rules, correction rights, and withdrawal rights. Such knowledge shall not be treated as ordinary open data, generalized without context, mapped unsafely, or used to create public claims inconsistent with custodial protocols.
248.18 Provider System Output Comparison. Provider system outputs shall be compared by reference to provider identity, system configuration, methodology, auditability, independence, incentives, conflicts, data rights, performance claims, error history, third-party review, and corroborating sources. Provider outputs shall not be treated as independent evidence without review and shall not imply provider preference, procurement suitability, certification, finance-readiness, or public authority approval.
248.19 Research Dataset Comparison. Research datasets shall be compared by reference to collection protocol, ethics approval where required, sampling, completeness, bias, data quality, consent, lawful basis, data management, transformations, documentation, version, and correction path. Dataset comparison shall distinguish source data, cleaned data, derived data, synthetic data, benchmark data, evaluation data, and publication-ready data.
248.20 Time-Series, Spatial, Semantic, and Probabilistic Comparison. Source comparison may include time-series comparison, spatial comparison, semantic comparison, and probabilistic comparison. Such comparisons shall identify alignment, lag, lead, anomaly, spatial mismatch, coordinate uncertainty, semantic mismatch, term divergence, probability ranges, confidence limits, missingness, outliers, and sensitivity. Comparative methods shall be recorded and shall not be treated as self-explanatory proof.
248.21 Source Weighting. Source weighting may be used to express relative confidence among sources. Weighting shall consider source independence, reliability, authority, custody, timeliness, completeness, calibration, methodology, relevance, bias, conflict, public authority status, community context, provider interest, sponsor interest, and corroboration. Weighting shall be transparent enough for review and shall not silently privilege sponsors, providers, funders, public authority participants, or technologically convenient sources.
248.22 Source Conflict Identification. Source conflict shall be identified where sources materially disagree in fact, time, location, classification, confidence, method, public authority status, community context, technical condition, model output, sensor signal, provider output, or interpretation. Conflict identification shall trigger review, confidence adjustment, limitation, dispute marking, additional evidence request, public authority clarification, community review, safeguards review, or correction as appropriate.
248.23 Source Failure Identification. Source failure shall be identified where a source is unavailable, incomplete, corrupt, unauthorized, stale, superseded, spoofed, tampered, misclassified, withdrawn, unreliable, ethically defective, legally restricted, or no longer fit for purpose. Source failure shall be recorded and shall not be treated as absence of risk or negative evidence unless the method expressly supports that inference.
248.24 Source Comparison Records. GCRI Canada shall maintain source comparison records, including source type identification, sensor comparisons, reference sensor comparisons, AI-RAN comparisons, O-RAN comparisons, DePIN comparisons, ledger comparisons, cyber log comparisons, geospatial comparisons, Earth observation comparisons, digital twin comparisons, simulation comparisons, operator observation comparisons, public authority context comparisons, community context comparisons, protected knowledge comparisons, provider output comparisons, research dataset comparisons, time-series comparisons, spatial comparisons, semantic comparisons, probabilistic comparisons, source weighting, source conflicts, source failures, confidence changes, correction triggers, and archives.
Section 249. Confidence Scoring, Corroboration, Contradiction, Dispute, Spoof Detection, Failed Signals, Missing Signals, and Correction Triggers
249.1 Confidence Scoring Purpose. Confidence scoring may be used to express the degree of support for evidence, source comparison, Truth Engine output, observability signal, dashboard indicator, map layer, technical note, model output, simulation output, digital twin output, public-safe summary, or Nexus interface artifact. Confidence scoring shall support disciplined review, limitation language, public-safe communication, and correctionability, and shall not be used as certification, rating, maturity status, finance-readiness, public authority approval, public warning, procurement approval, or provider ranking.
249.2 Confidence Score Inputs. Confidence scores may consider source reliability, source integrity, source independence, source authority, permission, custody, timeliness, completeness, calibration, source type, method quality, model quality, corroboration, contradiction, uncertainty, missingness, stale data, failed signals, spoof risk, tamper risk, public authority context, community context, protected knowledge concerns, provider influence, sponsor influence, reviewer confidence, and prior error history.
249.3 Confidence Banding. GCRI Canada may use confidence bands such as high, moderate, low, provisional, contested, insufficient, not assessed, or other approved categories. Each band shall be defined, applied consistently enough for review, accompanied by rationale where material, and limited by context. Confidence bands shall not be treated as ratings, guarantees, public warnings, public authority decisions, finance determinations, insurance determinations, procurement approvals, or certifications.
249.4 Confidence Rationale. Each material confidence score or confidence band shall include a confidence rationale identifying the principal supporting sources, principal limitations, principal assumptions, uncertainty, corroboration, contradiction, missing inputs, dispute status, reviewer action, method used, and correction path. The rationale may be public-safe, controlled, restricted, or internal depending on sensitivity.
249.5 Confidence Change Logs. Where confidence materially changes, GCRI Canada shall maintain a confidence change log identifying prior confidence, revised confidence, trigger, reviewer, source change, method change, model change, calibration change, public authority clarification, community correction, protected knowledge concern, sponsor influence concern, provider influence concern, cyber issue, data issue, affected outputs, dependency review, notice requirement, and correction action.
249.6 Corroboration Rules. Corroboration rules shall define when sources support the same or related conclusion. Corroboration may require independence, temporal alignment, spatial alignment, semantic alignment, methodological compatibility, source reliability, and absence of common-mode failure. Repeated copies of the same source, same provider output, same data pipeline, same model, same sensor family, or same sponsor narrative shall not be treated as independent corroboration without review.
249.7 Cross-Source Corroboration. Cross-source corroboration may compare sensor readings, reference sensors, telemetry, AI-RAN signals, O-RAN signals, DePIN records, cyber logs, geospatial data, Earth observation, public authority inputs, operator observations, community inputs, provider outputs, research datasets, model outputs, simulations, and digital twins. Cross-source corroboration shall identify independence, reliability, and limitations.
249.8 Temporal Corroboration. Temporal corroboration may compare sources across time, including sequence, latency, persistence, recurrence, trend, anomaly, seasonality, event timing, collection windows, update frequency, and stale-data risk. Temporal corroboration shall account for timestamp uncertainty, time zones, delayed ingestion, asynchronous systems, backfilled data, replay attacks, and changed conditions.
249.9 Spatial Corroboration. Spatial corroboration may compare location-based sources, including sensor location, geospatial layers, Earth observation, public authority boundaries, community boundaries, infrastructure locations, ports, corridors, watersheds, utility systems, AI-RAN cells, DePIN node claims, and digital twin zones. Spatial corroboration shall account for coordinate accuracy, resolution, generalization, protected knowledge, infrastructure sensitivity, privacy, and public-safe publication limits.
249.10 Semantic Corroboration. Semantic corroboration may compare whether different records, sources, terms, taxonomies, schemas, public authority concepts, provider descriptions, community descriptions, or Nexus interface terms refer to the same or meaningfully related concepts. Semantic corroboration shall use ontology records, controlled vocabulary, compatibility notes, divergence logs, and human review where meaning affects authority or public claims.
249.11 Statistical Corroboration. Statistical corroboration may compare distributions, patterns, outliers, confidence intervals, error bounds, correlations, thresholds, benchmark results, model outputs, simulation results, and observed outcomes. Statistical corroboration shall disclose limitations and shall not imply causation, prediction, guarantee, or authority without appropriate method support.
249.12 Contradiction Detection. Contradiction detection shall identify material disagreement among sources, evidence records, model outputs, public authority inputs, provider outputs, community inputs, sensor signals, dashboards, maps, publications, or Nexus interface records. Contradictions shall trigger dispute handling, confidence adjustment, review, limitation, quarantine, source correction, method correction, public authority clarification, community review, or downstream correction where appropriate.
249.13 Disputed Evidence Handling. Evidence shall be marked disputed where contradiction, challenge, authority concern, source concern, method concern, public authority clarification, community objection, protected knowledge concern, data-rights issue, cyber concern, sponsor influence concern, provider influence concern, or integrity concern exists. Disputed evidence shall not be used for public claims without limitation and review.
249.14 Failed Signal Handling. Failed signals shall be recorded where a sensor, telemetry stream, API, cyber log, AI-RAN signal, O-RAN signal, DePIN node, model output, simulation, dashboard feed, public authority feed, provider feed, geospatial feed, or research dataset fails, drops, corrupts, delays, malfunctions, becomes inaccessible, or becomes unauthorized. Failed signals shall not be treated as absence of risk unless the method expressly supports such interpretation.
249.15 Missing Signal Handling. Missing signals shall be recorded where expected data, telemetry, logs, public authority inputs, community inputs, sensor readings, model outputs, provider data, or corroborating sources are absent. Missing signals shall trigger limitation language, confidence adjustment, additional evidence request, deferral, public-safe qualification, or non-reliance where material.
249.16 Stale Signal Handling. Stale signals shall be identified where age, changed conditions, system updates, public authority changes, environmental changes, infrastructure changes, cyber changes, model changes, data-rights changes, or community context changes reduce reliability. Stale signals shall be marked, confidence-adjusted, updated, superseded, or withdrawn from reliance.
249.17 Spoof Detection. Spoof detection methods may examine source identity, device identity, network path, cryptographic evidence, ledger evidence, timestamp consistency, location consistency, signal pattern, anomaly pattern, replay indicators, sybil indicators, adversarial incentives, cyber indicators, and cross-source corroboration. Suspected spoofed signals shall be quarantined or limited pending review.
249.18 Tamper Detection. Tamper detection methods may examine metadata, hashes, signatures, audit logs, chain-of-custody records, repository history, access records, file integrity, sensor integrity, log continuity, model output integrity, and unexpected edits. Suspected tampering shall trigger record integrity incident review, access restriction, evidence preservation, and correction pathways.
249.19 Adversarial Manipulation Indicators. GCRI Canada may identify adversarial manipulation indicators, including coordinated false signals, synthetic data insertion, AI-generated fabrication, sybil attacks, model prompt attacks, log manipulation, location spoofing, provider gaming, sponsor narrative manipulation, market-sensitive distortion, public authority impersonation, social amplification, and dashboard manipulation. Such indicators shall be handled with classification, cyber review, legal review, public-safe discipline, and correctionability.
249.20 Sensor Drift Indicators. Sensor drift indicators may include gradual measurement divergence, calibration mismatch, environmental sensitivity, maintenance gaps, aging equipment, repeated outlier patterns, reference sensor divergence, missing calibration records, or unexplained signal trends. Sensor drift shall trigger confidence adjustment, recalibration request, source limitation, replacement source, or withdrawal from reliance where material.
249.21 Model Drift Indicators. Model drift indicators may include degraded performance, shifted input distributions, changed system conditions, unexplained output changes, benchmark decline, calibration failure, emerging bias, changed data pipeline, changed model version, changed prompt context, or changed external environment. Model drift shall trigger model review, confidence adjustment, limitation, correction, suspension, or retirement where appropriate.
249.22 Correction Triggers. Correction triggers may arise from contradiction, dispute, failed signal, missing signal, stale signal, spoof indicator, tamper indicator, adversarial manipulation indicator, sensor drift, model drift, public authority clarification, community correction, protected knowledge concern, data incident, AI incident, cyber incident, finance overclaim, certification overclaim, procurement implication, provider preference, sponsor influence, or public-safe output concern. Triggers shall route matters into review and shall not themselves decide outcome.
249.23 Human Review Triggers. Human review shall be triggered where a Truth Engine output affects public-facing claims, public authority context, community safeguards, protected knowledge, infrastructure-sensitive information, cyber-sensitive information, finance-boundary materials, certification-boundary materials, procurement-sensitive matters, provider neutrality, sponsor influence, high uncertainty, disputed evidence, suspected spoofing, suspected tampering, model drift, or significant downstream dependency. Human review shall be recorded.
249.24 Confidence, Corroboration, and Correction Records. GCRI Canada shall maintain confidence, corroboration, and correction records, including confidence score inputs, confidence bands, rationales, change logs, corroboration records, cross-source records, temporal records, spatial records, semantic records, statistical records, contradiction records, dispute records, failed signal records, missing signal records, stale signal records, spoof detection records, tamper detection records, adversarial manipulation records, sensor drift records, model drift records, correction triggers, human review triggers, correction decisions, dependency reviews, and archives.
Section 250. Truth Engine Output Limits
250.1 Truth Engine Output Classification. Each Truth Engine output shall be classified before reliance, sharing, publication, dashboard display, map display, public-safe use, controlled-room use, Board use, council use, public authority learning use, finance-boundary use, certification-boundary review, procurement-sensitive use, or Nexus interface use. Classification shall identify publication class, access class, handling class, data sensitivity, public authority sensitivity, cyber sensitivity, infrastructure sensitivity, finance sensitivity, competition sensitivity, protected knowledge status, AI-use status, and correction status.
250.2 Truth Engine Output as Evidence-Supporting Artifact. A Truth Engine output may be treated as an evidence-supporting artifact where it helps organize, compare, qualify, route, or review evidence. It shall not replace source evidence, method notes, reviewer judgment, public authority records, Board records, legal records, ethics records, safeguards records, or competent approvals. Evidence-supporting status shall be recorded with limitations.
250.3 Truth Engine Output as Confidence Artifact. A Truth Engine output may express confidence, uncertainty, confidence band, confidence rationale, confidence change, or confidence trigger. Such expression shall remain bounded by its sources, methods, assumptions, limitations, and review status. Confidence artifacts shall not be represented as ratings, guarantees, maturity levels, finance-readiness, insurance-readiness, certification, procurement approval, or public authority determinations.
250.4 Truth Engine Output as Corroboration Artifact. A Truth Engine output may identify corroboration among sources. Corroboration artifacts shall state whether sources are independent, partially dependent, same-origin, same-pipeline, same-provider, same-model, same-sensor-family, or otherwise correlated. Corroboration shall not be represented as proof beyond the support actually provided by the record.
250.5 Truth Engine Output as Routing or Review Artifact. A Truth Engine output may route a matter for technical review, source review, public authority review, safeguards review, data / AI / cyber review, legal review, finance-boundary review, certification-boundary review, procurement-boundary review, provider-neutrality review, committee review, Board review, or Nexus interface review. Routing shall not itself decide the matter or create authority.
250.6 Truth Engine Output as Correction Signal. A Truth Engine output may function as a correction signal where it identifies inconsistency, stale source, disputed evidence, failed signal, spoof indicator, tamper indicator, missing data, public authority misdescription, protected knowledge concern, finance overclaim, certification overclaim, procurement implication, provider preference, or public-safe output concern. A correction signal shall initiate review and shall not itself constitute a correction.
250.7 No Truth Engine Output as Official Truth. No Truth Engine output shall be described as official truth, final truth, absolute truth, unquestionable truth, universal truth, authoritative truth, public authority truth, legal truth, financial truth, certified truth, or operational truth. Truth Engine outputs are bounded, method-supported, source-dependent, confidence-bearing, uncertainty-bearing, reviewable, and correctionable artifacts.
250.8 No Truth Engine Output as Public Authority Decision. No Truth Engine output shall be treated as public authority decision, regulatory approval, public finance approval, funding approval, procurement approval, public warning, emergency declaration, public health order, public safety directive, official policy, permit, license, governmental endorsement, or sovereign obligation. Public authority meaning requires public authority action by competent authority and record.
250.9 No Truth Engine Output as Official Public Warning. No Truth Engine output shall be treated as an official public warning, alert, emergency notice, evacuation notice, health advisory, cyber warning, infrastructure warning, weather warning, disaster warning, public safety warning, or public alert unless lawfully issued by an authorized public authority. Public-safe Truth Engine outputs shall include limitation language where confusion is reasonably possible.
250.10 No Truth Engine Output as Emergency Command. No Truth Engine output shall be treated as command, dispatch, incident management, emergency management, operational direction, responder instruction, infrastructure control, system operation, public works direction, public health direction, cyber incident command, or any other execution activity. GCRI Canada’s Truth Engine role shall remain non-executing.
250.11 No Truth Engine Output as Recognition, Standing, or Public Legitimacy. No Truth Engine output shall be treated as recognition, standing, maturity, legitimacy, public approval, stakeholder status, GRF standing, Nexus Grid status, host readiness, provider readiness, project readiness, institution readiness, community readiness, or public-good legitimacy determination unless separately issued by a competent authority and record.
250.12 No Truth Engine Output as Finance-Readiness, Insurance-Readiness, Investment Suitability, Bankability, Rating, or Capital Recommendation. No Truth Engine output shall be treated as finance-readiness, capital-readiness, bankability, insurability, insurance-readiness, underwriting approval, lending suitability, creditworthiness, rating, public finance approval, guarantee eligibility, investment suitability, investment recommendation, securities recommendation, capital recommendation, routeability determination, capital placement, or investor matchmaking. Finance-facing actors may read technical outputs only under recorded boundary language.
250.13 No Truth Engine Output as Certification, Accreditation, Compliance Approval, Procurement Approval, or Provider Preference. No Truth Engine output shall be treated as certification, accreditation, conformity assessment, compliance approval, product approval, system approval, safety approval, public-sector eligibility, procurement approval, tender qualification, preferred provider status, provider ranking, provider endorsement, or performance warranty. Provider-neutrality and procurement-neutrality language shall be included where needed.
250.14 No Truth Engine Output as Legal, Engineering, Clinical, Financial, Insurance, Accounting, Rating, or Other Regulated Professional Opinion Unless Separately Authorized and Controlled. No Truth Engine output shall be treated as legal advice, engineering opinion, clinical opinion, medical advice, public health order, accounting opinion, audit opinion, tax advice, investment advice, insurance advice, actuarial opinion, underwriting decision, lending advice, securities advice, credit rating, or other regulated professional opinion unless separately authorized, licensed where required, controlled by competent professional processes, and recorded with scope and limitations.
250.15 Required Limitation Language. Truth Engine outputs shall include limitation language proportionate to use, audience, classification, public meaning, uncertainty, public authority involvement, finance-boundary exposure, certification-boundary exposure, procurement sensitivity, data / AI / cyber sensitivity, infrastructure sensitivity, protected knowledge, source quality, model use, method use, and correction status. Limitation language shall state scope, non-use conditions, authority boundaries, confidence, uncertainty, and correction path.
250.16 Truth Engine Output Limit Records. GCRI Canada shall maintain Truth Engine output limit records, including classifications, evidence-supporting status, confidence artifact status, corroboration artifact status, routing status, correction signal status, limitation language, no-official-truth language, no-public-authority language, no-public-warning language, no-emergency-command language, no-recognition language, no-finance-readiness language, no-certification language, no-procurement language, no-provider-preference language, regulated-professional-opinion boundary language, approvals, reviews, corrections, notices, and archives.
Section 251. Public-Safe Truth Outputs
251.1 Public-Safe Truth Output Purpose. Public-safe Truth outputs may be created to communicate evidence-supported, method-supported, confidence-aware, limitation-aware, and correctionable understanding to public, institutional, educational, public authority learning, community, or Nexus audiences without exposing sensitive information or creating unauthorized authority. Public-safe Truth outputs shall be designed to inform, not to command; to clarify, not to certify; to support learning, not to approve; and to preserve public trust without overclaim.
251.2 Public-Safe Review Before External Release. No Truth output shall be externally released unless reviewed for public-safe status. Public-safe review shall assess source sensitivity, evidence support, method support, confidence, uncertainty, limitation language, public authority boundaries, community safeguards, protected knowledge, data / AI / cyber risk, infrastructure sensitivity, finance-boundary risk, certification-boundary risk, procurement risk, provider-neutrality risk, sponsor influence, and correction path.
251.3 Classification Before Release. Each public-safe Truth output shall be classified before release. Classification shall determine whether the output is public, public-safe summary, controlled, restricted, embargoed, delayed, aggregated, redacted, anonymized, de-identified, generalized, no-download, public authority-limited, safeguards-limited, cyber-limited, infrastructure-limited, finance-boundary-limited, or archive-only.
251.4 Source Review Before Release. Source review before release shall verify that each material source is identified, permitted for the intended use, classified, reliable enough for the claim made, current enough for public use, not withdrawn, not superseded without notice, not subject to unresolved dispute requiring non-release, and not restricted by public authority terms, protected knowledge protocols, data rights, privacy, cybersecurity, infrastructure sensitivity, or confidentiality.
251.5 Confidence and Uncertainty Disclosure. Public-safe Truth outputs shall disclose confidence and uncertainty in language suitable to the audience and classification. Disclosure may include confidence bands, confidence rationale, known limitations, known unknowns, missing data, stale data, disputed evidence, source limitations, model limitations, public authority limitations, and public-safe non-use conditions. Disclosure shall be accurate without unnecessarily exposing sensitive details.
251.6 Limitation Statement. Each public-safe Truth output shall include a limitation statement proportionate to risk. The statement shall identify that the output is evidence-supported and method-bound, not an official public warning, not emergency command, not public authority approval, not finance-readiness, not insurance-readiness, not investment advice, not certification, not procurement approval, not provider endorsement, not recognition, not legal advice, and not a regulated professional opinion unless separately recorded.
251.7 Data Sensitivity Review. Public-safe Truth outputs shall be reviewed for personal information, sensitive personal information, health-sensitive data, public authority-sensitive data, cyber-sensitive data, infrastructure-sensitive data, finance-sensitive data, commercially sensitive data, competition-sensitive data, confidential data, privileged data, and protected knowledge. Sensitive data shall be removed, generalized, aggregated, delayed, redacted, de-identified, or restricted where required.
251.8 Public Authority Boundary Review. Where public-safe Truth outputs involve public authorities, public institutions, regulators, municipalities, ministries, Crown entities, public finance bodies, emergency management bodies, public health bodies, public safety bodies, utilities, ports, telecom systems, energy systems, water systems, food systems, health systems, cyber systems, or infrastructure operators, the output shall undergo public authority boundary review. The review shall preserve capacity classification, non-endorsement, no-delegation, no-public-warning, no-emergency-command, no-regulatory-approval, no-procurement-approval, no-funding-approval, no-public-finance-approval, and no-sovereign-obligation language.
251.9 Community and Protected Knowledge Review. Where public-safe Truth outputs involve communities, Indigenous knowledge, local knowledge, territorial knowledge, cultural knowledge, environmental knowledge, health-sensitive community data, protected participation, community vulnerability, sacred sites, livelihoods, or community-sensitive risk information, the output shall undergo safeguards review. Review shall preserve consent or authorization, custodial authority, attribution limits, non-extraction, contextual integrity, withdrawal rights, correction rights, and harm prevention.
251.10 Infrastructure and Cyber Sensitivity Review. Public-safe Truth outputs involving infrastructure, telecom, AI-RAN, O-RAN, DePIN, cyber systems, ports, utilities, energy, water, food, health, compute, sensors, geospatial systems, Earth observation, digital twins, logs, vulnerabilities, dependencies, or degraded-mode awareness shall undergo infrastructure and cyber sensitivity review. The output shall not disclose exploitable vulnerabilities, precise sensitive locations, operational dependencies, attack paths, unpatched systems, credentials, control structures, or unsafe tactical detail.
251.11 Finance, Certification, Procurement, Recognition, and Public Warning Boundary Review. Public-safe Truth outputs shall be reviewed to ensure that they do not imply finance-readiness, insurance-readiness, bankability, investment suitability, rating, capital recommendation, certification, accreditation, compliance approval, procurement approval, preferred provider status, recognition, maturity, standing, public legitimacy, official public warning, emergency command, or public authority decision. Where necessary, express boundary language shall be included.
251.12 Redaction. Redaction shall remove sensitive information while preserving accurate public-safe meaning. Redaction shall not be used to conceal material uncertainty, remove necessary limitations, hide conflicts, distort findings, obscure public authority capacity, hide sponsor or provider influence, or create misleading confidence. Redaction records shall be maintained for material outputs.
251.13 Aggregation. Aggregation may be used to reduce sensitivity by combining data, signals, locations, time periods, categories, or observations. Aggregation shall be designed to prevent re-identification, protected knowledge exposure, infrastructure targeting, cyber misuse, community harm, market-sensitive disclosure, or false precision. Aggregation shall not create overbroad conclusions unsupported by the underlying record.
251.14 De-Identification. De-identification may be used to reduce privacy and participant risk. De-identification shall consider direct identifiers, indirect identifiers, small-cell risk, geospatial re-identification, temporal re-identification, linkage attacks, public authority context, community context, protected knowledge, and AI-enabled re-identification. De-identified data shall still be classified where residual risk remains.
251.15 Controlled Annexes. Public-safe Truth outputs may refer to controlled annexes where detailed source lineage, methods, evidence, confidence rationale, cyber details, infrastructure details, public authority materials, finance-sensitive materials, protected knowledge, or legal review cannot be publicly released. Controlled annexes shall be access-controlled, versioned, classified, and correctionable.
251.16 Dashboard and Map Review. Public-safe dashboards and maps shall undergo review for data source, update cadence, stale indicators, confidence display, limitation display, geospatial sensitivity, infrastructure sensitivity, cyber sensitivity, protected knowledge, privacy, accessibility, public authority language, public warning boundary, finance-boundary language, certification-boundary language, procurement-boundary language, provider-neutrality language, and correction notices.
251.17 Public-Safe Correction Path. Each public-safe Truth output shall include a correction path. The correction path shall identify how errors, challenges, public authority clarifications, community corrections, protected knowledge concerns, data incidents, AI incidents, cyber incidents, stale sources, superseded methods, model drift, spoofing, tampering, overclaims, or public-safe limitations will be reviewed and corrected.
251.18 Public-Safe Truth Output Records. GCRI Canada shall maintain public-safe Truth output records, including public-safe review records, classification records, source review records, confidence disclosures, uncertainty disclosures, limitation statements, data sensitivity reviews, public authority boundary reviews, community and protected knowledge reviews, infrastructure and cyber sensitivity reviews, finance / certification / procurement / recognition / public-warning boundary reviews, redaction records, aggregation records, de-identification records, controlled annex records, dashboard and map review records, correction paths, correction notices, supersession records, withdrawal records, retraction records, and archives.
Section 252. Truth Engine Audit, Logs, Sources, Models, Reviewers, Confidence Changes, and Correction Records
252.1 Truth Engine Audit Purpose. Truth Engine audit shall preserve accountability, traceability, evidence integrity, methods integrity, data / AI / cyber integrity, public-safe integrity, reviewer accountability, correctionability, and institutional memory. Audit records shall allow authorized reviewers to determine what sources were used, what methods were applied, what models or tools were used, what transformations occurred, who reviewed the output, what confidence changed, what corrections were triggered, what overrides occurred, what access was granted, and what incidents affected the record.
252.2 Source Logs. Source logs shall record source identity, source type, origin, contributor, authority basis, permission basis, timestamp, jurisdiction, custody, classification, reliability, integrity review, use restriction, correction path, supersession status, withdrawal status, and linkage to evidence records or outputs. Source logs shall be protected according to sensitivity.
252.3 Data Ingestion Logs. Data ingestion logs shall record intake date, source, ingestion method, data class, file or stream identity, API identity, sensor identity, system identity, schema version, validation checks, rejected records, missing fields, transformation requirements, errors, access permissions, security controls, and custodian. Ingestion logs shall distinguish ingestion from approval or evidence status.
252.4 Transformation Logs. Transformation logs shall record cleaning, filtering, normalization, aggregation, de-identification, redaction, enrichment, feature extraction, geospatial transformation, time alignment, semantic mapping, model preprocessing, evidence conversion, public-safe transformation, and any manual edits. Transformation logs shall identify method, tool, operator, date, version, assumptions, limitations, and output classification.
252.5 Model Use Logs. Model use logs shall record model identity, provider, version, configuration, prompt or query record where retained and lawful, input classification, permitted use, prohibited use, model-training restrictions, output classification, human reviewer, limitations, confidence effect, and correction path. Model use logs shall be maintained for AI, statistical, simulation, digital twin, inference, classification, retrieval, and generative systems where material.
252.6 Reviewer Logs. Reviewer logs shall identify reviewer identity, role, independence status, conflict status, review date, review scope, materials reviewed, review conclusions, limitations, dissent, conditions, required corrections, escalation, and approval or non-approval. Reviewer logs shall preserve accountability without creating unnecessary exposure of protected or privileged material.
252.7 Confidence Change Logs. Confidence change logs shall record each material confidence change, including prior confidence, revised confidence, trigger, affected source, affected output, reviewer, rationale, method, new evidence, stale evidence, contradiction, dispute, model drift, sensor drift, spoof indicator, tamper indicator, public authority clarification, community correction, protected knowledge concern, and downstream dependency.
252.8 Output Generation Logs. Output generation logs shall record each material Truth Engine output, including output identifier, purpose, source set, method set, model set, transformation set, confidence, uncertainty, classification, reviewer, limitation language, public-safe status, controlled annex status, release status, affected interfaces, and correction path. Output generation shall not equal publication approval unless separately recorded.
252.9 Human Review Logs. Human review logs shall record required human review for outputs involving public-facing use, public authority context, protected knowledge, community safeguards, infrastructure sensitivity, cyber sensitivity, finance-boundary exposure, certification-boundary exposure, procurement sensitivity, disputed evidence, spoof indicators, tamper indicators, model drift, high uncertainty, or material downstream dependencies. Human review shall identify outcome, conditions, and unresolved issues.
252.10 Correction Logs. Correction logs shall record correction requests, triggers, triage, holds, quarantine, investigation, determination, correction action, confidence adjustment, source correction, method correction, model correction, output correction, public-safe notice, controlled notice, dependency remediation, implementation, and closeout. Correction logs shall preserve historical traceability.
252.11 Override Logs. Override logs shall record any human override, system override, confidence override, classification override, publication override, access override, correction override, or suppression of an automated or semi-automated signal. The log shall identify authority, reason, reviewer, conflict status, affected output, risk, and review requirement. Overrides shall not be used to conceal error or influence outcomes improperly.
252.12 Access Logs. Access logs shall record access to Truth Engine sources, models, records, outputs, dashboards, maps, controlled annexes, repositories, rooms, APIs, and audit records. Access logs shall identify user, role, time, action, export or download where permitted, unusual activity where detectable, and access revocation where applicable.
252.13 Incident Logs. Incident logs shall record data incidents, AI incidents, cyber incidents, source integrity incidents, model incidents, public authority incidents, protected knowledge incidents, finance-boundary incidents, certification-boundary incidents, procurement-boundary incidents, publication incidents, access incidents, repository incidents, spoofing incidents, tampering incidents, and record integrity incidents affecting Truth Engine records or outputs.
252.14 Model Drift Logs. Model drift logs shall record drift indicators, input distribution changes, performance changes, calibration failures, benchmark changes, output anomalies, bias changes, system changes, retraining events, version changes, reviewer findings, confidence effects, and corrective action.
252.15 Source Failure Logs. Source failure logs shall record missing sources, failed feeds, unavailable APIs, corrupt files, incomplete records, sensor outages, AI-RAN signal failures, O-RAN signal failures, DePIN node failures, cyber log gaps, geospatial feed failures, public authority feed interruptions, provider feed limitations, and research dataset failures. Source failure shall be linked to affected outputs and confidence.
252.16 Spoof or Tamper Indicator Logs. Spoof or tamper indicator logs shall record suspected spoofing, tampering, replay, sybil behavior, forged records, manipulated logs, altered metadata, fake location claims, synthetic data, AI-generated fabrication, unauthorized edits, cryptographic mismatch, access anomalies, and adversarial manipulation indicators. Such logs shall be classified and escalated where material.
252.17 Retention and Access Controls. Truth Engine audit records shall be retained according to law, classification, sensitivity, public authority terms, protected knowledge obligations, privacy requirements, cyber requirements, research integrity, correctionability, and institutional memory. Access shall be limited by role, need-to-know, authority, conflict status, confidentiality, public authority terms, safeguards, and legal restrictions.
252.18 Truth Engine Audit Records. GCRI Canada shall maintain Truth Engine audit records, including source logs, ingestion logs, transformation logs, model use logs, reviewer logs, confidence change logs, output generation logs, human review logs, correction logs, override logs, access logs, incident logs, model drift logs, source failure logs, spoof or tamper indicator logs, retention records, access-control records, correction records, supersession records, withdrawal records, and archives.
Section 253. Verifiable Compute Purpose
253.1 Verifiable Compute Purpose. Verifiable compute, as used by GCRI Canada, shall mean compute activity that is evidence-linked, permissioned, logged, scoped, secure, auditable, reviewable, reproducible where appropriate, classified, limitation-aware, and correctionable. Its purpose is to support trusted public-good research, evidence formation, methods stewardship, observability, ontology, Truth Engine outputs, public-good software, technical baselines, public authority learning, public-safe intelligence, and Nexus-compatible records without converting GCRI Canada into a compute operator for execution, public authority decision-maker, finance authority, certification body, or provider.
253.2 Evidence-Linked Compute. Compute used for material research, evidence, models, dashboards, maps, public-safe outputs, technical baselines, Truth Engine outputs, or Nexus interface records shall be linked to evidence records, source records, dataset records, model records, method records, authority records, classification records, and correction paths. Compute outputs shall not be relied upon where inputs, methods, models, code, or execution context cannot be sufficiently identified for the intended use.
253.3 Permissioned Compute. Compute shall be permissioned according to law, contracts, data rights, public authority terms, contributor terms, research ethics approvals, community protocols, Indigenous / local / territorial knowledge restrictions, privacy rules, cyber controls, sanctions and export-control rules, AI-use restrictions, Board policy, officer delegations, and approved workflows. No person shall infer compute permission from technical access alone.
253.4 Logged Compute. Material compute workloads shall be logged. Logs shall identify workload owner, purpose, authority, data inputs, input classifications, compute environment, jurisdiction, model identity, code identity, tool identity, execution time, output, output classification, reviewer, limitations, correction path, and retention status. Logging shall support auditability and correctionability.
253.5 Scoped Compute. Compute shall be limited to the approved purpose, dataset, model, code, environment, user, timeframe, output class, and permitted use. Scoped compute shall prevent unauthorized repurposing, uncontrolled experimentation, hidden model training, unapproved inference, cross-border transfer, public authority data misuse, protected knowledge misuse, sponsor or provider misuse, and public-safe overclaim.
253.6 Secure Compute. Compute environments shall be secured proportionate to data sensitivity, public authority sensitivity, cyber sensitivity, infrastructure sensitivity, protected knowledge, finance sensitivity, competition sensitivity, model risk, and output risk. Security controls may include identity and access management, multifactor authentication, encryption, key management, network restrictions, no-download controls, logging, vulnerability review, dependency review, secure containers, confidential computing, and incident response.
253.7 Auditable Compute. Compute shall be auditable where material. Auditability shall identify what data was used, what code or model was used, what environment executed the workload, what configuration applied, who initiated the workload, who reviewed the output, what limitations exist, what corrections occurred, and whether results can be reproduced or reasonably verified. Auditability shall not require unsafe disclosure of sensitive information.
253.8 Public-Safe Compute Outputs. Compute outputs intended for public release, public-safe dashboards, maps, reports, teaching materials, public authority learning, or Nexus-facing communication shall undergo public-safe review. Review shall ensure that outputs do not disclose personal information, protected knowledge, public authority-sensitive data, cyber-sensitive details, infrastructure-sensitive details, finance-sensitive information, competition-sensitive information, confidential information, or unsafe operational detail.
253.9 Correctionable Compute Outputs. Compute outputs shall be correctionable. Where input data, model version, code version, package version, configuration, method, environment, assumption, limitation, reviewer action, or classification changes materially affect the output, GCRI Canada shall correct, supersede, withdraw, re-run, reclassify, restrict, or archive the output as appropriate. Compute outputs shall not remain relied upon merely because they were produced once.
253.10 Compute Provenance. Compute provenance shall identify data inputs, model identity, code identity, tool identity, container or runtime identity, dependency versions, configuration, environment, jurisdiction, execution time, output identity, reviewer, and custody. Provenance may include hashes, signatures, repository commits, logs, manifests, SBOMs, model cards, dataset cards, system cards, benchmark cards, and workload records.
253.11 Compute Reproducibility Where Appropriate. Compute shall be reproducible where appropriate and feasible. Reproducibility may require preservation of datasets, code, models, prompts where retained and lawful, parameters, package versions, container images, runtime configurations, hardware context, random seeds where relevant, and execution logs. Where reproducibility is limited by privacy, protected knowledge, public authority restrictions, cyber sensitivity, proprietary dependencies, or live systems, the limitation shall be recorded.
253.12 Compute-to-Data Support. GCRI Canada may support compute-to-data arrangements where data cannot or should not move from an approved environment. Compute-to-data support may be used for public authority data, protected knowledge, sensitive research data, cyber-sensitive logs, infrastructure-sensitive data, health-sensitive data, or controlled datasets. Such arrangements shall restrict outputs, review disclosures, log workloads, and prevent unauthorized data extraction.
253.13 Confidential Computing Support. GCRI Canada may support confidential computing, secure enclaves, trusted execution environments, privacy-preserving computation, secure multiparty computation, federated analysis, differential privacy, synthetic data, and other privacy- or security-preserving techniques where appropriate. Such techniques shall not eliminate the need for lawful authority, classification, review, limitation, and correction.
253.14 Sovereign Compute Alignment. Compute involving Canadian public-good records, public authority data, sensitive evidence, protected knowledge, AI workloads, cyber-sensitive materials, or mission-critical infrastructure may require sovereign compute alignment, including jurisdictional controls, data residency, access restrictions, public authority terms, security controls, energy and resilience considerations, and Canadian governance oversight. Sovereign compute alignment shall not create public finance approval, procurement approval, national security authority, or operational control by GCRI Canada.
253.15 Non-Execution Compute Boundary. Verifiable compute shall not convert GCRI Canada into an operator of public infrastructure, emergency management system, telecom system, AI-RAN system, O-RAN system, DePIN system, cloud service, managed service, cybersecurity operations centre, public authority system, investment platform, insurance platform, procurement platform, certification platform, or execution vehicle. Compute may support evidence and methods; it shall not execute public authority, financial, operational, or provider-selection functions by default.
253.16 Verifiable Compute Records. GCRI Canada shall maintain verifiable compute records, including evidence-linked compute records, permission records, workload logs, scope records, security records, audit records, public-safe output review records, correction records, provenance records, reproducibility records, compute-to-data records, confidential computing records, sovereign compute alignment records, non-execution boundary records, incident records, supersession records, withdrawal records, and archives.
Section 254. Compute Workload Records
254.1 Compute Workload Record Requirement. GCRI Canada shall maintain a compute workload record for each material compute workload used for research, evidence formation, methods, observability, ontology, Truth Engine outputs, model evaluation, public-good software, technical baselines, dashboards, maps, public-safe outputs, public authority learning, controlled rooms, Nexus interfaces, or institutional decision support. The workload record shall be sufficient to support authority, provenance, auditability, classification, limitation, reproducibility where appropriate, and correctionability.
254.2 Workload Identifier. Each material compute workload shall have a workload identifier. The identifier may include docket number, case ID, repository reference, run ID, job ID, timestamp, hash, container reference, model run reference, compute environment reference, or other approved unique reference. The identifier shall link workload inputs, execution context, outputs, review records, and correction records.
254.3 Workload Owner. Each workload shall have a workload owner responsible for purpose, authority, input selection, method selection, output use, limitation discipline, review coordination, correction path, and closeout. The workload owner shall act within recorded authority and shall not use workload ownership to expand institutional meaning, public claims, public authority status, finance implications, certification implications, procurement implications, or provider preference.
254.4 Workload Custodian. Each workload shall have a custodian responsible for storage, logs, access control, classification, repository placement, output custody, retention, deletion, archival, and audit trail. Custodianship shall be recorded and may be assigned to a data steward, technical lead, repository maintainer, evidence steward, research lead, controlled-room custodian, or other authorized person.
254.5 Workload Purpose. Each workload record shall state the workload purpose, including whether the workload supports research, evidence review, source comparison, confidence scoring, model evaluation, observability, dashboard generation, map generation, public-safe summarization, method validation, software testing, benchmark testing, public authority learning, safeguards review, or Nexus interface support. Purpose shall be narrow enough to prevent unauthorized reuse.
254.6 Workload Authority. Each workload record shall identify the authority basis for execution, including Board authorization, officer delegation, policy, research protocol, ethics approval, data-sharing agreement, public authority term, contributor term, contract, controlled-room authorization, repository permission, or other lawful basis. A workload executed without adequate authority shall be restricted and reviewed.
254.7 Workload Data Inputs. Each workload record shall identify data inputs, including datasets, evidence records, telemetry, sensor readings, AI-RAN signals, O-RAN signals, DePIN records, cyber logs, geospatial data, Earth observation, public authority data, community inputs, protected knowledge, provider outputs, research data, model outputs, or synthetic data. Inputs shall be linked to source lineage and permission records.
254.8 Workload Data Classification. Each workload record shall identify data classification for inputs, including public, public-safe, internal, controlled, restricted, personal, sensitive personal, health-sensitive, public authority-sensitive, protected knowledge, cyber-sensitive, infrastructure-sensitive, finance-sensitive, competition-sensitive, confidential, privileged, export-controlled, sanctions-sensitive, or other applicable class. The most restrictive classification shall govern where uncertainty exists.
254.9 Workload Jurisdiction and Location. Each workload record shall identify jurisdiction and location of data, compute environment, storage, processing, access, backup, and transfer where relevant. Jurisdiction and location records shall account for Canadian governance, public authority terms, data residency, sovereign compute alignment, cross-border transfer, cloud region, remote access, public authority restrictions, protected knowledge restrictions, and export-control requirements.
254.10 Workload Compute Environment. Each workload record shall identify the compute environment, including cloud provider, sovereign compute environment, local environment, edge environment, high-performance computing environment, secure enclave, confidential computing environment, controlled-room environment, no-download environment, repository environment, or approved workstation. The record shall identify security baseline, access controls, logs, and environment approval status.
254.11 Workload Model, Code, or Tool Identity. Each workload record shall identify model, code, tool, package, script, notebook, API, SDK, library, container, runtime, dependency, configuration, prompt where retained and lawful, evaluation harness, benchmark tool, or dashboard tool used. Identity shall include version, repository, provider, license, security status, known limitations, and permitted use where applicable.
254.12 Workload Execution Time. Each workload record shall identify execution date, execution time, time zone, duration, run sequence, recurrence, scheduler, initiating user, automated process where applicable, and any re-run status. Execution time shall be linked to input currency, model version, code version, environment version, and output currency.
254.13 Workload Output. Each workload record shall identify output, including file, dataset, evidence record, confidence record, comparison record, model result, inference record, dashboard, map, public-safe summary, technical note, benchmark result, software artifact, log, alert, correction trigger, or other artifact. Outputs shall be stored, classified, versioned, and linked to the workload identifier.
254.14 Workload Output Classification. Each workload output shall be classified before reliance or release. Output classification shall consider input classification, transformation, aggregation, de-identification, model inference, public authority sensitivity, protected knowledge, cyber sensitivity, infrastructure sensitivity, finance sensitivity, competition sensitivity, AI-use status, public-safe status, and downstream use.
254.15 Workload Limitations. Each workload record shall identify limitations, including source limitations, data quality, missing data, stale data, model limitations, code limitations, method limitations, environment limitations, reproducibility limits, jurisdictional limits, public authority limits, protected knowledge limits, cyber limits, infrastructure limits, finance-boundary limits, certification-boundary limits, procurement-boundary limits, and public-safe limitations.
254.16 Workload Reviewer. Each material workload shall identify reviewer or review process where review is required. Review may include technical review, data / AI / cyber review, safeguards review, public authority boundary review, finance-boundary review, certification-boundary review, publication review, legal review, research integrity review, or Board / committee review. Review outcome and conditions shall be recorded.
254.17 Workload Correction Path. Each workload record shall identify a correction path. The correction path shall identify how input errors, source corrections, model errors, code errors, dependency vulnerabilities, environment issues, output errors, classification errors, public-safe issues, public authority clarifications, protected knowledge concerns, finance overclaims, certification overclaims, procurement implications, or provider-preference concerns will be reviewed and corrected.
254.18 Workload Retention. Each workload record shall identify retention requirements for inputs, outputs, logs, code, model references, environment manifests, review records, correction records, and archive copies. Retention shall account for law, privacy, public authority terms, protected knowledge, cyber requirements, research integrity, correctionability, reproducibility, auditability, and institutional memory.
254.19 Compute Workload Records. GCRI Canada shall maintain compute workload records, including workload identifiers, owners, custodians, purposes, authority bases, data inputs, data classifications, jurisdiction and location records, compute environment records, model / code / tool identity records, execution time records, output records, output classifications, limitation notes, reviewer records, correction paths, retention records, deletion records, incident records, supersession records, withdrawal records, and archives.
Section 255. Compute Environment Authority, Data Inputs, Model / Code Identity, Execution Context, Output Classification, Limitations, and Correction Path
255.1 Compute Environment Authority. GCRI Canada shall authorize compute environments before use for material workloads involving research, evidence, methods, observability, ontology, Truth Engine outputs, public-good software, technical baselines, dashboards, maps, public authority materials, protected knowledge, controlled data, AI systems, cyber-sensitive materials, infrastructure-sensitive materials, finance-sensitive materials, or Nexus interfaces. Authorization shall identify environment purpose, owner, custodian, jurisdiction, security baseline, permitted data classes, permitted workloads, prohibited uses, access controls, logging, retention, incident response, and closeout.
255.2 Approved Compute Environments. Approved compute environments may include Board-approved or officer-approved cloud environments, sovereign compute environments, secure research environments, institutional servers, high-performance computing environments, controlled-room environments, data-room environments, no-download environments, secure workstations, confidential computing environments, approved edge environments, and approved repository-integrated execution environments. Approval shall be recorded and may be limited by data class, workload type, user class, jurisdiction, output type, or time.
255.3 Prohibited Compute Environments. GCRI Canada shall prohibit use of compute environments that are unauthorized, insecure, unlogged, uncontrolled, unapproved for the relevant data class, inconsistent with public authority terms, inconsistent with protected knowledge obligations, inconsistent with privacy requirements, inconsistent with AI-use restrictions, inconsistent with export-control or sanctions requirements, or unable to support correctionability and auditability. Prohibited environments may include personal unmanaged accounts, consumer AI tools, unapproved cloud accounts, unlogged notebooks, uncontrolled devices, insecure repositories, public paste systems, unapproved model platforms, or foreign environments barred by law or agreement.
255.4 Environment Security Baseline. Each approved compute environment shall maintain a security baseline proportionate to risk. Baselines may include identity verification, role-based access control, multifactor authentication, encryption in transit and at rest, key management, logging, vulnerability management, dependency review, backup controls, incident response, network restrictions, secrets management, secure deletion, no-download controls, repository controls, and periodic access review.
255.5 Environment Jurisdiction. Each compute environment shall identify jurisdiction of processing, storage, backup, administration, support access, subprocessors, cloud regions, and remote access where relevant. Jurisdiction shall be reviewed for Canadian governance, public authority terms, privacy law, protected knowledge, Indigenous / local / territorial knowledge restrictions, cross-border transfer, sanctions, export controls, cyber risk, and sovereign compute alignment.
255.6 Environment Ownership and Control. Each compute environment shall identify ownership, operational control, administrative control, provider control, host control, public authority control, subcontractor control, and GCRI Canada control. Where an environment is hosted by a provider, host, public authority, university, laboratory, consortium, National Consortium Company, Project SPV, or partner, the record shall preserve legal separateness, access boundaries, confidentiality, data rights, no-agency, no-merger, no-shared-liability, non-execution, and correctionability.
255.7 Data Input Authorization. Data inputs shall be authorized before processing. Authorization shall identify source, permission, classification, lawful basis, permitted use, prohibited use, AI-use permission, model-training restriction, transfer restriction, retention, deletion, public authority terms, protected knowledge restrictions, privacy requirements, cyber requirements, finance sensitivity, competition sensitivity, and correction path. Data shall not be processed merely because it is technically accessible.
255.8 Model Identity. Each workload involving a model shall identify model name, provider, version, deployment mode, configuration, risk class, permitted use, prohibited use, training or fine-tuning status, data-use terms, retention terms, model-improvement settings, evaluation status, known limitations, bias concerns, drift status, security concerns, and human review requirements. Model identity shall be sufficient to determine whether output can be relied upon and corrected.
255.9 Code Identity. Each workload involving code shall identify code repository, file, script, notebook, commit, branch, release tag, hash, author or maintainer where relevant, license, review status, security status, dependency status, known issues, and permitted use. Unreviewed or unversioned code shall not be used for material public-facing, public authority-facing, finance-boundary, certification-boundary, or controlled evidence outputs without recorded limitation and review.
255.10 Tool Identity. Each workload involving tools, platforms, APIs, SDKs, dashboards, analytics systems, geospatial systems, AI systems, notebooks, data pipelines, visualization tools, simulation tools, digital twin tools, or security tools shall identify tool identity, provider, version, configuration, data-use terms, security posture, export status, access controls, logging, known limitations, and permitted use.
255.11 Container, Runtime, Package, Dependency, and Configuration Identity. Each material workload shall identify container image, runtime, operating environment, packages, dependencies, library versions, configuration files, parameters, environment variables where appropriate and safe, hardware context where relevant, accelerator context where relevant, random seeds where relevant, and security posture. Dependency identity shall support reproducibility, vulnerability response, and correction.
255.12 Execution Context. Execution context shall identify who initiated the workload, when it ran, where it ran, under what authority, with what input class, with what model or code, with what environment, with what access rights, with what logs, with what output path, and with what review requirement. Automated execution, scheduled execution, agentic execution, API-triggered execution, or third-party execution shall be clearly identified.
255.13 Output Classification. Compute outputs shall be classified based on input sensitivity, transformation, inference risk, aggregation, de-identification, public authority status, protected knowledge, personal information, cyber sensitivity, infrastructure sensitivity, finance sensitivity, competition sensitivity, model use, public-safe status, and downstream use. Output classification may be more restrictive than input classification where inference or combination creates new sensitivity.
255.14 Output Limitations. Compute outputs shall include limitations proportionate to use. Limitations may concern source quality, data completeness, missing data, stale data, model limits, code limits, method limits, dependency limits, environment limits, reproducibility limits, uncertainty, jurisdictional scope, public authority limits, protected knowledge limits, cyber limits, infrastructure limits, finance-boundary limits, certification-boundary limits, procurement-boundary limits, provider-neutrality limits, and public-safe release limits.
255.15 Output Review. Compute outputs shall be reviewed before material reliance, publication, public-safe release, public authority-facing use, finance-boundary use, certification-boundary use, procurement-sensitive use, Nexus interface use, or technical baseline use. Review may include technical review, evidence review, methods review, data / AI / cyber review, public authority boundary review, safeguards review, legal review, finance-boundary review, certification-boundary review, publication review, or Board / committee review where required.
255.16 Output Correction Path. Each material compute output shall have a correction path. The correction path shall identify how input errors, model errors, code errors, tool errors, dependency vulnerabilities, environment errors, execution errors, classification errors, public-safe errors, public authority clarifications, protected knowledge concerns, finance overclaims, certification overclaims, procurement implications, provider-neutrality issues, or downstream dependency errors will be reviewed and corrected.
255.17 Compute Environment Records. GCRI Canada shall maintain compute environment records, including environment authority records, approved environment records, prohibited environment records, security baseline records, jurisdiction records, ownership and control records, data input authorization records, model identity records, code identity records, tool identity records, container / runtime / package / dependency / configuration records, execution context records, output classification records, output limitation records, output review records, output correction paths, incident records, access records, retention records, deletion records, supersession records, withdrawal records, and archives.
Section 256. Sovereign Compute Alignment, Compute-to-Data, Secure Enclaves, Confidential Computing, Air-Gapped Environments, and Restricted Data Rooms
256.1 Sovereign Compute Alignment. GCRI Canada shall align compute involving sensitive public-good records, Canadian public authority materials, protected knowledge, restricted evidence, AI workloads, cyber-sensitive materials, infrastructure-sensitive materials, finance-boundary materials, and Nexus interface records with sovereign compute principles where appropriate. Sovereign compute alignment shall include consideration of jurisdiction, data residency, legal control, access control, operational resilience, energy dependence, provider dependence, public authority terms, Canadian governance oversight, data / AI / cyber obligations, and correctionability. Sovereign compute alignment shall not convert GCRI Canada into a public authority, national security authority, procurement authority, compute utility, managed service provider, cloud provider, infrastructure operator, or execution vehicle.
256.2 Canadian Sovereign Compute Considerations. Where compute relates to Canadian public-benefit research, Canadian public authority data, Canadian infrastructure systems, Canadian communities, Canadian Indigenous / local / territorial knowledge, Canadian cyber-sensitive records, Canadian mission-critical systems, or Canadian Nexus participation, GCRI Canada shall consider whether the compute environment preserves Canadian legal accountability, Canadian corporate governance, lawful Canadian access controls, appropriate data residency, public authority terms, privacy obligations, safeguards obligations, and resilience requirements. Canadian sovereign compute considerations shall be recorded where material and shall not be used to imply public finance approval, procurement approval, public authority endorsement, national security designation, or official governmental status.
256.3 Public Authority Data Considerations. Compute involving public authority data shall be reviewed for public authority capacity, lawful basis, confidentiality, statutory restrictions, data-sharing terms, public reference limits, retention terms, cross-border transfer limits, public-safe publication limits, cyber sensitivity, infrastructure sensitivity, and correction rights. Public authority data shall not be processed in an environment inconsistent with the authority, sensitivity, classification, or purpose for which the data was provided. Use of public authority data in compute shall not create public authority delegation, public warning authority, emergency command, regulatory approval, procurement approval, funding approval, public finance approval, endorsement, or sovereign obligation.
256.4 Community and Protected Knowledge Considerations. Compute involving community knowledge, Indigenous knowledge, local knowledge, territorial knowledge, cultural knowledge, environmental knowledge, health-sensitive community data, protected participation, community vulnerability, sacred-site information, or other protected knowledge shall be reviewed for custodial authority, consent or authorization, contextual integrity, access restrictions, AI-use restrictions, non-extraction obligations, publication limits, withdrawal rights, correction rights, and harm prevention. Such knowledge shall not be processed in uncontrolled compute environments, embedded into unrestricted retrieval systems, used for model training, or transformed into public outputs without lawful and safeguards-compliant authority.
256.5 Data Sovereignty Considerations. Data sovereignty considerations shall include legal authority over data, jurisdiction of storage and processing, jurisdiction of administrative access, subcontractor access, cloud region, backup location, cross-border support access, public authority terms, Indigenous data governance, community protocols, privacy law, export-control law, sanctions restrictions, cybersecurity obligations, and downstream reuse controls. GCRI Canada shall not treat technical convenience, lower cost, provider preference, sponsor preference, or speed as sufficient reason to bypass data sovereignty review for sensitive material.
256.6 Compute-to-Data Default for Restricted or Sovereign-Sensitive Material. Where data is restricted, sovereign-sensitive, public authority-sensitive, protected-knowledge-bearing, cyber-sensitive, infrastructure-sensitive, health-sensitive, personally identifiable, or subject to localization constraints, GCRI Canada may require a compute-to-data model by default. Under compute-to-data, approved code, models, queries, or analysis are brought to the controlled data environment, and only reviewed, classified, permitted outputs may leave. Compute-to-data arrangements shall include workload approval, source review, input classification, environment controls, output review, export controls, logging, retention, deletion, and correction path.
256.7 Secure Enclaves. GCRI Canada may use secure enclaves for workloads requiring heightened confidentiality, integrity, access control, and auditability. Secure enclaves may be used for public authority data, protected knowledge, sensitive research data, cyber logs, infrastructure records, finance-sensitive materials, model evaluations, controlled annexes, and confidential review materials. Enclave access shall be limited to authorized persons, logged, time-bound where appropriate, and subject to data / AI / cyber controls, no-download rules where required, output review, and closeout.
256.8 Confidential Computing. GCRI Canada may use confidential computing, trusted execution environments, secure multiparty computation, privacy-preserving computation, federated analysis, differential privacy, synthetic-data techniques, or related privacy-enhancing technologies where appropriate. Such technologies may reduce certain risks but shall not eliminate the need for lawful authority, classification, public authority review, safeguards review, cyber review, output limitation, human review, or correctionability. Confidential computing shall not be represented as absolute security, public authority approval, certification, or guarantee.
256.9 Air-Gapped Environments. Air-gapped or isolated environments may be required for workloads involving highly sensitive cyber materials, infrastructure-sensitive data, public authority-sensitive records, protected knowledge, restricted model evaluation, incident investigation, source-integrity review, or other high-risk materials. Air-gapped environments shall include documented access controls, media controls, device controls, import and export procedures, logging, chain-of-custody, malware review where applicable, output review, secure deletion, and closeout procedures.
256.10 Restricted Data Rooms. Restricted data rooms may be established for controlled access to sensitive datasets, model records, public authority records, protected knowledge, cyber logs, infrastructure records, finance-sensitive evidence, controlled annexes, and confidential research materials. Data-room rules shall identify permitted users, permitted uses, prohibited uses, viewing controls, download controls, AI-use restrictions, model-training restrictions, export controls, confidentiality obligations, retention, revocation, incident response, and correction path.
256.11 No-Download Rooms. No-download rooms may be used where records may be viewed but not downloaded, copied, printed, screenshotted, scraped, exported, embedded, indexed, uploaded to AI systems, or redistributed. No-download rooms may be required for protected knowledge, public authority-sensitive data, cyber-sensitive records, infrastructure-sensitive maps, finance-sensitive materials, confidential sponsor or provider materials, privileged records, and restricted evidence. No-download status shall not reduce the need for access logs, confidentiality terms, output review, and closeout.
256.12 Cross-Border Compute Review. Compute involving cross-border processing, storage, remote access, support access, cloud administration, model-provider access, third-party tooling, backups, or subcontractor processing shall undergo cross-border compute review where material. Review shall consider Canadian law, foreign law exposure, public authority terms, privacy, Indigenous / local / territorial knowledge obligations, export controls, sanctions, cybersecurity, public authority sensitivity, infrastructure sensitivity, finance sensitivity, litigation risk, and data sovereignty. Cross-border compute shall not proceed where inconsistent with applicable restrictions.
256.13 Cloud Provider Review. Cloud providers used for material workloads shall be reviewed for security controls, jurisdiction, data residency, access controls, logging, encryption, key management, incident response, subcontractors, AI-use terms, data-use terms, deletion commitments, audit rights, continuity, resilience, certifications where relevant, export-control posture, and ability to support GCRI Canada’s classification, correction, and public-safe obligations. Cloud provider use shall not imply provider endorsement, procurement preference, certification by GCRI Canada, or public authority approval.
256.14 AI Provider Review. AI providers used for material workloads shall be reviewed for model identity, data-use terms, training and model-improvement settings, retention, deletion, confidentiality, security, jurisdiction, logging, output ownership, auditability, prompt and context handling, retrieval handling, model limitations, bias risks, cyber risks, and human review support. AI provider use shall not authorize sensitive data ingestion, model training, public authority data processing, protected knowledge processing, or public-safe output generation unless expressly recorded and approved.
256.15 Logging, Monitoring, and Access Control. Sovereign compute, compute-to-data, secure enclave, confidential computing, air-gapped, restricted data-room, and no-download environments shall maintain logging, monitoring, and access controls proportionate to sensitivity. Controls may include named-user access, multifactor authentication, role-based access, room-level access, document-level access, session logs, query logs, export logs, watermarking, anomaly detection, access review, credential expiry, revocation, and incident escalation. Logs shall be classified and retained according to risk and law.
256.16 Environment Exit and Data Disposition. When a restricted compute environment, data room, enclave, air-gapped environment, or compute-to-data arrangement is closed or exited, GCRI Canada shall conduct environment exit and data disposition. Exit shall include access revocation, credential termination, export review, output classification, deletion or return of temporary files, cache review, backup review where practicable, key rotation where needed, incident review, unresolved issue log, correction review, archival disposition, and surviving confidentiality reminders.
256.17 Sovereign Compute and Restricted Environment Records. GCRI Canada shall maintain sovereign compute and restricted environment records, including sovereign compute reviews, Canadian sovereign compute considerations, public authority data reviews, community and protected knowledge reviews, data sovereignty reviews, compute-to-data approvals, secure enclave records, confidential computing records, air-gapped environment records, restricted data-room records, no-download room records, cross-border compute reviews, cloud provider reviews, AI provider reviews, logging records, monitoring records, access-control records, environment exit records, data disposition records, incidents, corrections, supersessions, withdrawals, and archives.
Section 257. Model Register
257.1 Model Register Requirement. GCRI Canada shall maintain a Model Register for material AI, machine learning, statistical, simulation, digital twin, generative, agentic, inference, retrieval, classification, scoring, forecasting, optimization, benchmark, and evaluation systems used in research, evidence formation, observability, ontology, Truth Engine outputs, verifiable compute, public-good software, technical baselines, dashboards, maps, public authority learning, public-safe outputs, controlled rooms, or Nexus interface records. The Model Register shall support authority, traceability, classification, review, limitation, human accountability, incident response, retirement, and correctionability.
257.2 Model Register Custodian. The Board, an authorized officer, or an approved data / AI / cyber governance function shall designate a custodian for the Model Register. The custodian shall maintain register completeness, access controls, versioning, classification, review cycles, incident history, deployment status, retirement status, correction records, and archival records. Custodianship shall not create authority to approve high-risk use, override human review, bypass safeguards, or alter institutional meaning without competent record.
257.3 Model Identity. Each registered model shall have an identity record identifying model name, provider, version, family, architecture where known and appropriate, deployment mode, API or local status, open-source or proprietary status, fine-tuned status, retrieval-augmented status, agentic status, embedded-system status, and relationship to any system, dashboard, map, workflow, repository, evaluation harness, or Nexus interface. Model identity shall be specific enough to support auditability and correction.
257.4 Model Version. Each registered model shall identify version, release, snapshot, deployment date, configuration, parameter set where relevant, fine-tune version, prompt framework where retained and lawful, retrieval configuration, tool-access configuration, system-card version, model-card version, evaluation version, and known version-change risks. Model version changes shall trigger review where they materially affect outputs, confidence, safety, privacy, security, public-safe publication, or Nexus interface meaning.
257.5 Model Provider. Each registered model shall identify provider, vendor, maintainer, host, operator, open-source project, institutional owner, cloud platform, or internal development team where applicable. Provider records shall include terms of use, data-use commitments, training or improvement settings, retention, deletion, confidentiality, security posture, jurisdiction, support access, subcontractors, known limitations, and any provider conflict or dependency. Provider identity shall not imply provider endorsement or preference.
257.6 Model Owner or Operator. Each registered model shall identify the owner, operator, administrator, or accountable internal function responsible for model use within GCRI Canada. The owner or operator shall be responsible for permitted use, prohibited use, access control, review cycle, incident reporting, output limitation, human review, correction path, and retirement or suspension where necessary. Ownership or operation shall remain subject to Board authority, officer delegation, law, policy, and this Bylaw.
257.7 Model Purpose. Each registered model shall identify its purpose, including whether it supports summarization, retrieval, classification, anomaly detection, evidence comparison, confidence scoring, geospatial analysis, dashboard generation, simulation, digital twin analysis, public-safe drafting, coding, translation, accessibility, research support, public authority learning, cyber analysis, observability, or technical baseline development. Model purpose shall be narrow enough to prevent unauthorized expansion into decision authority or regulated activity.
257.8 Permitted Uses. The Model Register shall identify permitted uses for each model, including eligible data classes, eligible users, eligible environments, permitted outputs, review requirements, publication restrictions, public-safe uses, controlled-room uses, and Nexus interface uses. Permitted uses shall be subject to classification, data rights, AI-use restrictions, public authority terms, safeguards, cyber controls, finance-boundary controls, certification-boundary controls, and correctionability.
257.9 Prohibited Uses. The Model Register shall identify prohibited uses for each model. Prohibited uses may include processing restricted data without authority, training on sensitive Nexus data, processing public authority data without terms, processing protected knowledge without safeguards, autonomous external publication, autonomous public authority communication, autonomous contracting, autonomous finance activity, autonomous procurement activity, autonomous legal commitment, unapproved model improvement, unapproved embedding, unapproved retrieval indexing, and use as final authority for governance, public authority, finance, certification, procurement, recognition, or emergency functions.
257.10 Risk Class. Each registered model shall be assigned a risk class proportionate to potential impact, including public meaning, public authority involvement, protected knowledge, personal information, cyber sensitivity, infrastructure sensitivity, finance-boundary exposure, certification-boundary exposure, procurement sensitivity, provider-neutrality implications, model autonomy, tool access, data sensitivity, output reliance, and downstream dependency. Risk class shall determine review, approval, logging, human oversight, and incident procedures.
257.11 Data Access Class. Each registered model shall identify permitted data access classes and prohibited data access classes. Access classes may include public, public-safe, internal, controlled, restricted, public authority-limited, safeguards-limited, cyber-limited, infrastructure-limited, finance-boundary-limited, no-download, room-only, personal-information-bearing, protected-knowledge-bearing, or archive-only. Models shall not access data outside recorded authority merely because technical integration allows access.
257.12 Training Status and Training Restrictions. Each registered model shall identify whether it is pre-trained, internally trained, fine-tuned, externally fine-tuned, continuously trained, retrieval-augmented, embedded, non-training, or unknown. Training restrictions shall identify whether GCRI Canada data, public authority data, protected knowledge, personal information, cyber-sensitive data, infrastructure-sensitive data, finance-sensitive data, sponsor or provider materials, or controlled-room materials may be used for training, fine-tuning, embedding, evaluation, model improvement, or retrieval.
257.13 Evaluation Status. Each registered model shall identify evaluation status, including unassessed, preliminarily assessed, internally evaluated, externally evaluated, benchmarked, red-teamed, security-reviewed, privacy-reviewed, public-safe-reviewed, safeguards-reviewed, finance-boundary-reviewed, certification-boundary-reviewed, restricted, suspended, or approved for limited use. Evaluation status shall not be described as certification, accreditation, compliance approval, provider endorsement, or public authority approval by default.
257.14 Known Limitations. Each registered model shall identify known limitations, including hallucination, bias, drift, incomplete coverage, uncertainty, data cutoff, geospatial limitations, language limitations, public authority interpretation limitations, protected knowledge risks, privacy risks, cyber risks, infrastructure risks, prompt injection vulnerability, retrieval limitations, benchmark limitations, tool-use risk, output variability, and lack of suitability for regulated professional advice. Limitations shall be updated as new evidence emerges.
257.15 Incident History. The Model Register shall record incident history, including data incidents, AI incidents, cyber incidents, output errors, public-safe failures, hallucinations, unsafe recommendations, protected knowledge exposure, public authority misdescription, finance overclaim, certification overclaim, procurement implication, provider preference, prompt injection, data exfiltration, unauthorized access, tool misuse, model drift, and correction actions. Incident history shall inform risk class and continued use.
257.16 Human Review Requirements. Each registered model shall identify human review requirements. Human review may be mandatory for public-facing outputs, public authority-facing outputs, finance-boundary inputs, certification-boundary materials, procurement-sensitive matters, protected knowledge, infrastructure-sensitive materials, cyber-sensitive materials, legal or policy-sensitive summaries, Board or committee materials, Nexus interface records, and outputs with material public meaning. Human review shall be substantive and recorded.
257.17 Deployment Status. Each registered model shall identify deployment status, including not deployed, experimental, sandbox, internal use, controlled-room use, restricted use, public-safe use, production support, suspended, deprecated, retired, or archive-only. Deployment status shall define permitted users, environments, data classes, output classes, and review requirements.
257.18 Retirement Status. Each registered model shall identify retirement status where a model is no longer approved, no longer supported, superseded, unsafe, obsolete, withdrawn, unavailable, legally restricted, security-compromised, or inconsistent with GCRI Canada’s public-benefit purpose. Retirement shall include replacement guidance where appropriate, reliance limits, access revocation, record preservation, and archival.
257.19 Model Register Records. GCRI Canada shall maintain Model Register records, including custodian records, model identity records, version records, provider records, owner or operator records, purpose records, permitted-use records, prohibited-use records, risk-class records, data-access-class records, training-status records, training-restriction records, evaluation-status records, known limitation records, incident history, human review requirements, deployment status, retirement status, corrections, supersessions, withdrawals, suspensions, and archives.
Section 258. Model Records for AI, ML, Statistical, Digital Twin, Simulation, Generative, Agentic, and Inference Systems
258.1 AI Model Records. GCRI Canada shall maintain records for AI models used in material workflows. AI model records shall identify model purpose, architecture or class where known, provider, version, deployment mode, permitted use, prohibited use, data access class, training status, evaluation status, limitations, human review requirements, output classification, incident history, and correction path. AI model records shall distinguish AI-supported work from authoritative human decisions and competent institutional records.
258.2 Machine Learning Model Records. Machine learning model records shall identify training data where known and permitted, feature inputs, labels, training method, evaluation metrics, validation status, bias review, drift review, calibration, version, environment, deployment scope, permitted use, limitations, and correction process. ML outputs shall not be treated as evidence, public-safe output, classification, confidence score, or decision input unless reviewed and recorded according to use.
258.3 Statistical Model Records. Statistical model records shall identify variables, assumptions, data sources, sampling method, model specification, parameters, confidence intervals or uncertainty measures where applicable, diagnostics, limitations, fit-for-purpose review, and interpretation rules. Statistical outputs shall not be overclaimed as causal, predictive, official, finance-ready, certified, or public authority-approved unless the record lawfully supports such statement.
258.4 Digital Twin Records. Digital twin records shall identify modeled system, scope, boundaries, input sources, calibration, validation, assumptions, parameters, scenario conditions, version, data currency, sensitivity analysis, public authority context, infrastructure sensitivity, cyber sensitivity, public-safe status, and correction path. Digital twin outputs shall be treated as scenario-dependent and shall not be represented as official forecasts, operational commands, public warnings, finance determinations, procurement approvals, or guarantees.
258.5 Simulation Model Records. Simulation model records shall identify scenario design, assumptions, model structure, parameters, input data, source lineage, stochastic components, sensitivity, uncertainty, validation, reproducibility where appropriate, limitations, and interpretation restrictions. Simulation results shall be classified as modeled outputs and shall not be treated as observed facts or official predictions.
258.6 Generative Model Records. Generative model records shall identify model provider, version, input classes, prompt framework where retained and lawful, system instructions, retrieval sources, output classes, permitted uses, prohibited uses, training and retention terms, hallucination risks, citation risks, public-safe risks, protected knowledge risks, data leakage risks, human review requirements, and correction path. Generative output shall not be used as final authority without human review and record.
258.7 Agentic AI Records. Agentic AI records shall identify agent purpose, model identity, tool permissions, external-system permissions, data access permissions, approval gates, prohibited actions, monitoring rules, logging rules, human-in-the-loop requirements, kill switch, incident procedures, and output limits. Agentic AI shall not autonomously publish, communicate with public authorities, sign contracts, make payments, procure, fundraise, invest, insure, transfer data, delete official records, or bind GCRI Canada without express human authorization and record.
258.8 Inference System Records. Inference system records shall identify input classification, inference method, model identity, tool identity, output classification, confidence, limitations, human reviewer, permitted use, prohibited use, public-safe status, and correction path. Inference systems shall distinguish directly observed facts from inferred attributes, predicted states, classified categories, risk scores, and confidence artifacts.
258.9 Embedded Model Records. Embedded model records shall identify models embedded in software, dashboards, sensors, edge devices, AI-RAN systems, O-RAN systems, DePIN devices, cyber tools, geospatial tools, digital twin tools, or other technical systems. Records shall identify deployment context, update path, provider dependence, data access, security posture, limitations, and correction process.
258.10 Third-Party Model Records. Third-party model records shall identify provider, terms of use, data-use terms, training settings, retention settings, security posture, jurisdiction, subcontractors, support access, logging, auditability, model limitations, evaluation status, incident history, dependency risks, and exit path. Third-party model use shall not create provider preference or relieve GCRI Canada of human accountability.
258.11 Open-Source Model Records. Open-source model records shall identify source repository, license, version, weights, documentation, maintainer, known limitations, security risks, dependency risks, evaluation status, permitted use, prohibited use, and update path. Open-source status shall not be treated as proof of safety, neutrality, lawfulness, quality, or public-benefit alignment.
258.12 Fine-Tuned Model Records. Fine-tuned model records shall identify base model, fine-tuning data, data permission, training restrictions, training environment, training date, training method, evaluation results, limitations, model owner, deployment status, data removal pathway where feasible, and correction path. Fine-tuning shall not use restricted, public authority, personal, protected, cyber-sensitive, infrastructure-sensitive, or finance-sensitive data without express authority and review.
258.13 Retrieval-Augmented Generation System Records. Retrieval-augmented generation records shall identify retrieval sources, embedding stores, indexes, access controls, permission mapping, chunking methods, ranking methods, prompt-injection defenses, data leakage controls, source citation rules, deletion pathways, re-indexing requirements, public-safe limits, human review requirements, and correction path. Retrieval systems shall not bypass document-level, room-level, public authority, protected knowledge, or finance-sensitive access controls.
258.14 Model Chain and Tool Chain Records. Where multiple models, tools, APIs, agents, scripts, retrieval systems, data pipelines, dashboards, or evaluation harnesses are chained, GCRI Canada shall maintain model-chain and tool-chain records. Such records shall identify sequence, dependencies, input-output transfers, authority, classifications, failure points, security controls, human review gates, and correction paths. Chain records shall prevent authority inflation across automated steps.
258.15 Model Dependency Records. Model dependency records shall identify external providers, base models, libraries, packages, data pipelines, APIs, plugins, tools, compute environments, retrieval indexes, embeddings, benchmarks, evaluation harnesses, and human review dependencies. Dependency changes shall trigger review where they affect reliability, security, privacy, public-safe status, or institutional meaning.
258.16 Model Evaluation Records. Model evaluation records shall identify evaluation method, benchmark, dataset, evaluator, criteria, date, results, limitations, failures, bias findings, security findings, drift findings, public-safe concerns, safeguards concerns, finance-boundary concerns, certification-boundary concerns, and permitted-use implications. Evaluation records shall not be framed as certification or compliance approval unless separately authorized.
258.17 Model Record Updates. Model records shall be updated when model version changes, provider terms change, data-use settings change, training status changes, evaluation status changes, limitations change, incidents occur, drift is detected, vulnerabilities are identified, public authority restrictions arise, safeguards concerns arise, or deployment status changes. Updates shall preserve historical traceability.
258.18 Model Record Retention. Model records shall be retained according to law, policy, research integrity, public authority terms, data / AI / cyber requirements, protected knowledge obligations, auditability, correctionability, and institutional memory. Superseded, suspended, retired, or withdrawn model records shall remain archived or sealed as appropriate and shall not be presented as current.
Section 259. Dataset Cards, Model Cards, System Cards, Benchmark Cards, Evaluation Harnesses, and Method Libraries
259.1 Dataset Card Requirement Where Material. GCRI Canada shall maintain dataset cards for material datasets used in research, evidence formation, model evaluation, AI systems, observability, dashboards, maps, technical baselines, public authority learning, public-safe outputs, or Nexus interface records. Dataset cards shall be required where dataset use materially affects evidence, public meaning, AI output, public authority context, safeguards, finance-boundary records, certification-boundary records, or public-safe publication.
259.2 Dataset Card Contents. Dataset cards shall identify dataset name, source, contributor, provenance, custody, collection method, time period, jurisdiction, permissions, consent where applicable, license, data class, sensitive fields, protected knowledge status, public authority status, privacy risks, bias risks, completeness, missing data, known errors, transformations, permitted uses, prohibited uses, AI-training restrictions, retention, deletion path, limitations, and correction path.
259.3 Model Card Requirement Where Material. GCRI Canada shall maintain model cards for material models used in AI, ML, statistical, simulation, digital twin, generative, agentic, inference, classification, scoring, retrieval, or evaluation workflows. Model cards shall summarize identity, purpose, training or configuration, evaluation, limitations, risk class, permitted uses, prohibited uses, human review requirements, deployment status, incident history, and correction path.
259.4 Model Card Contents. Model cards shall identify model name, provider, version, owner, purpose, architecture or class where appropriate, training status, fine-tuning status, retrieval augmentation, data access class, evaluation results, known limitations, bias concerns, drift risks, cyber risks, privacy risks, protected knowledge risks, public authority risks, finance-boundary risks, certification-boundary risks, output limits, human review requirements, and retirement conditions.
259.5 System Card Requirement Where Material. GCRI Canada shall maintain system cards for material AI systems, Truth Engine systems, observability systems, dashboard systems, map systems, retrieval systems, agentic systems, verifiable compute systems, digital twin systems, and public-safe publication systems. System cards shall describe system purpose, components, data flows, model flows, tool flows, authority, access controls, review gates, output classes, limitations, and correction path.
259.6 System Card Contents. System cards shall identify system owner, custodian, components, models, datasets, tools, APIs, repositories, compute environments, access classes, logging, monitoring, human review, incident procedures, public-safe controls, public authority controls, protected knowledge controls, finance-boundary controls, certification-boundary controls, procurement-boundary controls, provider-neutrality controls, and records retention.
259.7 Benchmark Card Requirement Where Material. GCRI Canada shall maintain benchmark cards for material benchmarks, tests, gold vectors, negative tests, evaluation harnesses, challenge sets, red-team tests, adversarial tests, reliability tests, security tests, public-safe tests, and performance tests used to assess models, datasets, software, dashboards, maps, methods, or technical baselines. Benchmark cards shall prevent unsupported benchmark claims and provider-preference misuse.
259.8 Benchmark Card Contents. Benchmark cards shall identify benchmark purpose, scope, dataset, source lineage, test design, metrics, assumptions, limitations, evaluation environment, model or system versions tested, evaluator, date, results, known failure modes, public-safe status, provider-dependency risks, reproducibility, permitted use, prohibited use, and correction path. Benchmark results shall not be represented as certification, procurement approval, provider ranking, or performance warranty by default.
259.9 Evaluation Harness Documentation. Evaluation harnesses shall be documented with purpose, inputs, outputs, code identity, configuration, dependencies, environment, metrics, scoring method, reviewer role, automation limits, known limitations, security posture, public-safe status, and correction path. Evaluation harness documentation shall support reproducibility and shall prevent hidden changes, silent drift, or unreviewed benchmark claims.
259.10 Method Library Documentation. Method libraries shall be documented with method names, versions, owners, custodians, applicability, exclusions, dependencies, assumptions, limitations, public-safe status, controlled annexes, review cycle, correction path, and retirement status. Method libraries shall be managed as public-good technical assets and not as ungoverned code snippets.
259.11 Data Source, Consent, Permission, Provenance, Bias, Limitation, and Fit-for-Purpose Disclosure. Dataset cards, model cards, system cards, benchmark cards, evaluation harness documentation, and method library documentation shall disclose source, consent or permission where applicable, provenance, custody, bias, limitations, uncertainty, fit-for-purpose, prohibited uses, public authority restrictions, protected knowledge restrictions, AI-use restrictions, and correction path in a manner suitable to publication class and sensitivity.
259.12 Evaluation Results and Known Failure Modes. Evaluation records shall identify results, failures, uncertainty, false positives, false negatives, hallucination risks, prompt-injection vulnerabilities, retrieval errors, model drift, bias concerns, security vulnerabilities, public-safe failures, data leakage risks, infrastructure sensitivity, protected knowledge risks, and contexts where outputs should not be relied upon. Failure modes shall be used to guide limitation language and human review.
259.13 Public-Safe Version and Controlled Version. Where documentation contains sensitive information, GCRI Canada may maintain both public-safe and controlled versions. Public-safe versions shall provide meaningful transparency without exposing personal information, protected knowledge, cyber-sensitive details, infrastructure-sensitive details, public authority-sensitive information, finance-sensitive information, competition-sensitive information, confidential information, or unsafe operational details. Controlled versions shall preserve full review records under access controls.
259.14 Review and Update Cycle. Dataset cards, model cards, system cards, benchmark cards, evaluation harness documentation, and method library documentation shall be reviewed periodically and when data changes, model versions change, system configurations change, evaluation results change, incidents occur, drift is detected, legal requirements change, public authority terms change, safeguards concerns arise, or public-safe outputs change.
259.15 Correction and Supersession. Cards, harnesses, and method libraries shall be corrected or superseded where inaccurate, outdated, incomplete, misleading, unsafe, misclassified, unsupported, or inconsistent with source records, model records, system behavior, evaluation results, legal obligations, public authority terms, protected knowledge obligations, or GCRI Canada’s non-executing role. Correction shall include dependency review where outputs relied on the affected documentation.
259.16 Dataset, Model, System, Benchmark, Evaluation, and Method Library Records. GCRI Canada shall maintain dataset, model, system, benchmark, evaluation, and method library records, including cards, documentation, public-safe versions, controlled versions, source records, permission records, provenance records, bias reviews, limitation notes, fit-for-purpose reviews, evaluation results, known failure modes, review cycles, corrections, supersessions, withdrawals, retirements, and archives.
Section 260. Training, Fine-Tuning, Embedding, Retrieval, and Model Improvement Restrictions
260.1 Training Restriction Principle. GCRI Canada shall restrict training, fine-tuning, embedding, retrieval indexing, model improvement, and related AI data use according to lawful authority, data rights, classification, public authority terms, privacy obligations, protected knowledge obligations, cyber controls, infrastructure sensitivity, finance sensitivity, competition sensitivity, research ethics, contributor terms, and public-benefit purpose. No data shall be used to train, fine-tune, embed, index, or improve models merely because it is accessible.
260.2 No Training on Sensitive Nexus Data Without Express Authority. Sensitive Nexus data, including controlled evidence, restricted records, public authority materials, Nexus interface records, protected knowledge, cyber-sensitive materials, infrastructure-sensitive materials, finance-boundary materials, controlled-room materials, Board materials, committee materials, sponsor or provider confidential materials, and non-public technical baselines, shall not be used for model training without express authority, review, and record.
260.3 No Fine-Tuning on Restricted Data Without Express Authority. Restricted data shall not be used to fine-tune any model unless express written authority identifies the dataset, model, purpose, environment, training method, permitted use, prohibited use, retention, deletion path, output restrictions, evaluation requirements, human review, and correction path. Fine-tuning approval shall not be inferred from research participation, repository access, room access, contributor status, provider role, or technical capability.
260.4 No Embedding of Restricted Data Without Express Authority. Restricted data shall not be embedded into vector stores, semantic indexes, retrieval systems, knowledge graphs, model memory, caches, or other machine-readable structures without express authority. Embedding approval shall identify access controls, document-level permissions, room-level permissions, deletion path, re-indexing obligations, leakage risk controls, public-safe limits, protected knowledge controls, and correction path.
260.5 No Retrieval Indexing of Restricted Data Without Access Controls. Restricted data may be retrieval-indexed only where access controls preserve source permissions, classification, room restrictions, public authority terms, protected knowledge restrictions, data subject rights, document-level restrictions, role-level restrictions, no-download restrictions, and revocation pathways. Retrieval systems shall not allow a user to retrieve, summarize, infer, or reconstruct materials beyond the user’s authority.
260.6 No Model Improvement Use Without Recorded Permission. GCRI Canada records, prompts, outputs, datasets, evidence packs, public authority materials, protected knowledge, controlled-room materials, research data, sponsor materials, provider materials, and user interactions shall not be used for third-party or internal model improvement unless recorded permission permits such use. Model improvement permission shall specify scope, provider, purpose, data class, retention, deletion, opt-out or revocation where applicable, and safeguards.
260.7 No Third-Party Provider Training Without Express Agreement. Third-party AI providers shall not use GCRI Canada data, public authority data, protected knowledge, controlled evidence, restricted records, prompts, outputs, embeddings, or user interactions for training, fine-tuning, model improvement, evaluation, benchmarking, or product development unless an express agreement and approval record permit such use. Provider defaults shall be reviewed and disabled where inconsistent with GCRI Canada controls.
260.8 No Use of Public Authority Data for AI Training Unless Authorized. Public authority data shall not be used for AI training, fine-tuning, embedding, retrieval indexing, model improvement, or evaluation unless the public authority terms, lawful authority, classification, and review record expressly authorize such use. Public authority participation, data contribution, or room attendance shall not imply AI training permission.
260.9 No Use of Community-Protected or Indigenous Knowledge for AI Training Unless Lawfully and Safeguard-Compliantly Authorized. Community-protected knowledge, Indigenous knowledge, local knowledge, territorial knowledge, cultural knowledge, environmental knowledge, health-sensitive community information, protected participation materials, or community-sensitive risk information shall not be used for AI training, fine-tuning, embedding, retrieval indexing, model improvement, or evaluation unless lawfully authorized and safeguards-compliant. Authorization shall respect custodial authority, consent, context, non-extraction, attribution, withdrawal, correction, and publication limits.
260.10 No Use of Personal Information for AI Training Without Lawful Basis and Review. Personal information and sensitive personal information shall not be used for AI training, fine-tuning, embedding, retrieval indexing, model improvement, or evaluation without lawful basis, privacy review, data minimization, consent or other lawful authority where required, retention limits, deletion path, security controls, and review of re-identification risk. Personal information shall not be treated as safe for training merely because it is available in a research, public authority, or operational dataset.
260.11 No Use of Cyber-Sensitive or Infrastructure-Sensitive Data for Uncontrolled AI Processing. Cyber-sensitive data and infrastructure-sensitive data shall not be uploaded to uncontrolled AI systems, consumer AI tools, unapproved model providers, unlogged environments, or unrestricted retrieval systems. Such data may be processed only in approved environments with access controls, logging, security review, output review, public-safe restrictions, and correction path.
260.12 Data Minimization. AI training, fine-tuning, embedding, retrieval, model improvement, and evaluation shall use the minimum data reasonably necessary for the authorized purpose. GCRI Canada shall prefer de-identified, aggregated, synthetic, reduced, redacted, public-safe, or controlled-access approaches where consistent with research integrity and technical validity. Data minimization shall not be used to strip protected knowledge of context or create misleading outputs.
260.13 Retention and Deletion Pathways. Training, fine-tuning, embedding, retrieval, and model improvement records shall identify retention and deletion pathways. Where data must be removed, GCRI Canada shall identify whether deletion from datasets, embeddings, indexes, caches, logs, model memory, fine-tuned weights, backups, provider systems, and downstream outputs is feasible, required, or limited. Deletion limitations shall be disclosed and controlled before use.
260.14 Training and Fine-Tuning Review. Training and fine-tuning proposals shall undergo review proportionate to sensitivity, including data rights review, privacy review, public authority review, safeguards review, cyber review, infrastructure sensitivity review, finance-boundary review, certification-boundary review, provider review, model risk review, and public-safe review. Review shall identify whether the activity is lawful, necessary, proportionate, secure, auditable, and correctionable.
260.15 Training Restriction Records. GCRI Canada shall maintain training restriction records, including authority records, prohibited-use records, training approval records, fine-tuning approval records, embedding approval records, retrieval indexing approval records, model improvement permission records, third-party provider terms, public authority data permissions, protected knowledge permissions, personal information reviews, cyber-sensitive data reviews, infrastructure-sensitive data reviews, data minimization records, retention records, deletion pathway records, review records, incidents, corrections, and archives.
Section 261. Retrieval and Embedding Controls, Deletion Pathways, Access Permissions, Leakage Risks, and Public-Safe Limits
261.1 Retrieval Control Purpose. Retrieval controls shall ensure that search, retrieval, summarization, question-answering, semantic lookup, vector search, knowledge graph traversal, agentic access, and AI-assisted context assembly respect source authority, classification, access permissions, public authority terms, protected knowledge restrictions, data rights, room restrictions, and public-safe limits. Retrieval shall support lawful access and evidence use; it shall not become a mechanism for unauthorized disclosure.
261.2 Embedding Control Purpose. Embedding controls shall ensure that conversion of records into vectors, semantic representations, indexes, retrieval stores, model memory, knowledge graphs, or other machine-readable structures does not bypass classification, consent, access permissions, deletion rights, protected knowledge obligations, public authority terms, cyber controls, infrastructure controls, finance controls, competition controls, or correctionability. Embedding shall be treated as a controlled processing activity.
261.3 Retrieval Source Review. Before a source is included in a retrieval system, GCRI Canada shall review source identity, authority, permission, classification, access restrictions, AI-use restrictions, model-training restrictions, public authority terms, protected knowledge status, privacy, cyber sensitivity, infrastructure sensitivity, finance sensitivity, competition sensitivity, retention, deletion path, and correction path. Sources failing review shall be excluded or restricted.
261.4 Embedding Store Review. Embedding stores shall be reviewed for security, jurisdiction, access controls, provider terms, deletion capability, re-indexing capability, logging, encryption, segregation, backup behavior, inference risk, leakage risk, prompt-injection risk, cross-tenant risk, and public-safe controls. Embedding stores shall be approved for the data classes they contain.
261.5 Access Permission Mapping. Retrieval and embedding systems shall map access permissions from source records into retrieval permissions. Permission mapping shall preserve document-level, row-level, field-level, role-level, room-level, public authority-limited, safeguards-limited, cyber-limited, infrastructure-limited, finance-boundary-limited, no-download, and archive-only restrictions. A retrieval answer shall not reveal content, summaries, inferences, or metadata a user is not authorized to access.
261.6 Row-Level, Document-Level, Role-Level, and Room-Level Access Controls. Where required by classification, retrieval systems shall enforce row-level, document-level, role-level, and room-level access controls. Controls shall apply not only to direct source display but also to snippets, summaries, embeddings, vector matches, citations, metadata, generated responses, aggregate answers, and downstream AI outputs. Room-level controls shall preserve controlled-room and no-download restrictions.
261.7 Deletion Pathways. Retrieval and embedding systems shall maintain deletion pathways for source deletion, consent withdrawal, public authority restriction, protected knowledge withdrawal, data subject rights, correction, supersession, withdrawal, retraction, misclassification, incident response, and retention expiry. Deletion pathways shall address source files, chunks, embeddings, indexes, caches, logs where required, backups where practicable, generated summaries, and dependent outputs.
261.8 Re-indexing Requirements. Where source records are corrected, reclassified, superseded, withdrawn, retracted, restricted, or deleted, GCRI Canada shall re-index affected retrieval systems where necessary to prevent stale, unauthorized, or misleading retrieval. Re-indexing shall preserve correctionability and shall include validation that old content is not returned through caches, embeddings, summaries, or derived indexes.
261.9 Leakage Risk Assessment. Retrieval and embedding systems shall be assessed for leakage risk, including unauthorized retrieval, membership inference, reconstruction risk, summary leakage, metadata leakage, cross-user leakage, cross-room leakage, prompt injection, tool misuse, model memory leakage, embedding inversion risk, small-cell disclosure, protected knowledge exposure, public authority data exposure, cyber-sensitive disclosure, infrastructure-sensitive disclosure, and finance-sensitive disclosure.
261.10 Prompt Injection and Data Exfiltration Risk Review. Retrieval systems connected to AI models, agents, tools, plugins, APIs, webpages, documents, or external sources shall undergo prompt injection and data exfiltration risk review. Controls may include source sanitization, tool permission limits, instruction hierarchy controls, citation review, output filters, no-secret retrieval, no-autonomous export, human review, and incident response.
261.11 Retrieval Misranking or Context Collapse Review. GCRI Canada shall review retrieval systems for misranking, context collapse, stale-result dominance, overbroad retrieval, semantic confusion, source omission, contradictory-source suppression, sponsor or provider bias, public authority misclassification, protected knowledge mismatch, and unsupported summarization. Retrieval results shall not be treated as complete evidence merely because they are highly ranked.
261.12 Public-Safe Retrieval Restrictions. Public-safe retrieval systems shall retrieve only content approved for public or public-safe use. Public-safe systems shall not retrieve controlled annexes, restricted evidence, protected knowledge, public authority-sensitive records, cyber-sensitive records, infrastructure-sensitive records, finance-sensitive records, confidential materials, or internal deliberations unless transformed through approved public-safe processes.
261.13 Protected Knowledge Retrieval Restrictions. Protected knowledge shall not be indexed, embedded, retrieved, summarized, translated, mapped, modeled, or exposed through AI systems unless lawful and safeguards-compliant authority expressly permits such processing. Retrieval involving protected knowledge shall preserve custodial authority, consent, attribution, context, withdrawal, correction, non-extraction, and publication restrictions.
261.14 Public Authority Data Retrieval Restrictions. Public authority data shall not be indexed, embedded, retrieved, summarized, or exposed beyond the capacity, terms, and permissions under which it was provided. Retrieval outputs shall not imply public authority endorsement, decision, public warning, emergency command, regulatory approval, procurement approval, funding approval, public finance approval, or sovereign obligation.
261.15 Finance-Sensitive Retrieval Restrictions. Finance-sensitive materials, including finance-boundary notes, capital-readability inputs, public finance reader materials, investor-sensitive materials, insurance-sensitive materials, lending-sensitive materials, project finance records, revenue models, sponsor materials, and restricted due-diligence records, shall be retrieved only by authorized persons under recorded controls. Retrieval outputs shall not provide investment advice, securities advice, insurance advice, underwriting approval, lending advice, rating, public finance approval, routeability, or finance-readiness determination.
261.16 Cyber and Infrastructure Sensitivity Restrictions. Cyber-sensitive and infrastructure-sensitive materials shall not be exposed through uncontrolled retrieval, public-safe search, general AI assistants, unapproved embeddings, or external tools. Retrieval outputs involving vulnerabilities, system diagrams, access controls, logs, critical infrastructure locations, operational dependencies, degraded-mode weaknesses, or attack paths shall be restricted and reviewed.
261.17 Retrieval Incident Response. Retrieval incidents, including unauthorized retrieval, embedding leakage, prompt injection, data exfiltration, stale retrieval, misclassification, protected knowledge exposure, public authority data exposure, cyber-sensitive disclosure, infrastructure-sensitive disclosure, finance-sensitive disclosure, or incorrect public-safe output, shall trigger incident response. Response may include containment, access revocation, re-indexing, deletion, correction, notification, dependency review, and archive.
261.18 Retrieval and Embedding Records. GCRI Canada shall maintain retrieval and embedding records, including retrieval source reviews, embedding store reviews, access permission mappings, row-level controls, document-level controls, role-level controls, room-level controls, deletion pathways, re-indexing records, leakage risk assessments, prompt injection reviews, data exfiltration reviews, misranking reviews, public-safe retrieval restrictions, protected knowledge restrictions, public authority data restrictions, finance-sensitive restrictions, cyber and infrastructure restrictions, retrieval incidents, corrections, and archives.
Section 262. Inference Records
262.1 Inference Record Requirement. GCRI Canada shall maintain inference records for material AI-assisted, model-assisted, statistical, computational, retrieval-assisted, simulation-based, digital twin, classification, scoring, anomaly-detection, summarization, translation, geospatial, observability, Truth Engine, or agentic outputs that may affect research, evidence, public-safe publication, public authority learning, Board materials, council materials, technical baselines, dashboards, maps, Nexus interfaces, finance-boundary inputs, certification-boundary materials, or public meaning. Inference records shall support traceability, human review, classification, limitation, correction, and auditability.
262.2 Material AI Output Definition. A material AI output means any AI-assisted or model-assisted output that materially affects evidence, methods, research conclusions, public-safe statements, public authority-facing materials, protected knowledge handling, cyber-sensitive analysis, infrastructure-sensitive analysis, finance-boundary materials, certification-boundary materials, procurement-sensitive language, provider-neutrality language, Board or committee materials, Nexus interface records, technical baselines, dashboards, maps, public claims, or correction decisions.
262.3 Inference Identifier. Each material inference record shall have an identifier linking the inference to source inputs, model identity, tool identity, environment, prompt or query record where retained and lawful, output, reviewer, use decision, classification, correction path, and retention status. The identifier may include run ID, model call ID, docket ID, repository reference, workload ID, hash, timestamp, or other approved reference.
262.4 Input Classification. Inference records shall identify input classification, including public, public-safe, internal, controlled, restricted, personal, sensitive personal, public authority-sensitive, protected knowledge, cyber-sensitive, infrastructure-sensitive, finance-sensitive, competition-sensitive, confidential, privileged, or other applicable class. Input classification shall govern model use, output classification, storage, access, and review.
262.5 Prompt or Query Record Where Appropriate and Lawful. Where appropriate and lawful, inference records shall preserve prompts, queries, system instructions, retrieval questions, tool calls, parameters, and user instructions necessary for auditability and correctionability. Where prompts contain sensitive information, they shall be redacted, classified, restricted, or summarized in controlled form. Prompt retention shall respect privacy, public authority terms, protected knowledge, privilege, and security.
262.6 Context Sources. Inference records shall identify context sources used by the model, including retrieved documents, datasets, embeddings, knowledge graph records, evidence packs, model outputs, dashboards, maps, public authority records, controlled annexes, public-safe summaries, or user-provided materials. Context source records shall identify permission, classification, citation, confidence, and correction status.
262.7 Model Identity. Inference records shall identify model name, provider, version, configuration, deployment mode, retrieval augmentation, fine-tune status, tool access, data-use terms, known limitations, evaluation status, and incident history where material. Model identity shall be sufficient to support correction if outputs prove inaccurate, unsafe, unauthorized, or stale.
262.8 Tool Identity. Inference records shall identify tools used during inference, including retrieval tools, code execution, calculation tools, geospatial tools, data tools, repository tools, browser tools, file tools, dashboard tools, API tools, agentic tools, translation tools, or summarization tools. Tool identity shall include authority, permissions, limitations, output classification, and logs where material.
262.9 Execution Environment. Inference records shall identify execution environment, including cloud, local, sovereign compute, secure enclave, controlled room, data room, no-download room, approved AI platform, or approved workstation. Environment records shall identify jurisdiction, access control, logging, data-use settings, security baseline, and retention.
262.10 Output Classification. Each material inference output shall be classified before use or release. Output classification shall consider input sensitivity, transformation, inference, aggregation, de-identification, model risk, public authority context, protected knowledge, cyber sensitivity, infrastructure sensitivity, finance sensitivity, competition sensitivity, public-safe use, and downstream reliance. Output may be more restrictive than input where inference creates new sensitivity.
262.11 Confidence and Limitation Notes. Inference records shall include confidence and limitation notes proportionate to materiality. Notes may address source limits, model limits, retrieval limits, hallucination risk, missing context, stale information, uncertainty, bias, public authority limits, protected knowledge limits, cyber sensitivity, infrastructure sensitivity, finance-boundary limits, certification-boundary limits, procurement-boundary limits, and non-use conditions.
262.12 Human Reviewer. Where human review is required, the inference record shall identify the reviewer, reviewer role, qualifications where relevant, conflict status, review scope, review outcome, conditions, corrections required, escalation, and approval or non-approval. Human review shall be substantive and shall not be treated as a formality.
262.13 Use Decision. Inference records shall identify whether the output was used, rejected, revised, quarantined, escalated, corrected, incorporated into a draft, included in public-safe material, included in controlled material, used for evidence support, used for routing, used for review, or not used. The use decision shall identify authority and limitation.
262.14 Public-Safe Status. Inference records shall identify whether the output is public-safe, public-safe after redaction, controlled only, restricted, confidential, public authority-limited, safeguards-limited, cyber-limited, infrastructure-limited, finance-boundary-limited, or not suitable for external use. Public-safe status shall be reviewed before publication or external release.
262.15 Correction Path. Each inference record shall identify how errors, hallucinations, misquotations, source omissions, retrieval failures, tool errors, stale context, model drift, protected knowledge concerns, public authority misdescription, cyber-sensitive disclosure, infrastructure-sensitive disclosure, finance overclaim, certification overclaim, procurement implication, provider preference, or public-safe issue will be corrected.
262.16 Retention and Redaction. Inference records shall be retained or redacted according to law, policy, privacy, public authority terms, protected knowledge obligations, privilege, cyber sensitivity, infrastructure sensitivity, research integrity, auditability, and correctionability. Sensitive prompts, outputs, logs, and context may be sealed, redacted, summarized, or deleted where lawful and required.
262.17 Inference Record Register. GCRI Canada may maintain an inference record register for material inferences. The register shall identify inference identifiers, owners, custodians, models, tools, input classes, output classes, reviewers, use decisions, public-safe status, correction status, retention status, and links to evidence, workload, model, dataset, and publication records.
262.18 Inference Records. GCRI Canada shall maintain inference records, including inference identifiers, input classifications, prompt or query records where appropriate and lawful, context source records, model identity records, tool identity records, execution environment records, output classifications, confidence notes, limitation notes, human reviewer records, use decisions, public-safe status, correction paths, retention records, redaction records, incidents, corrections, supersessions, withdrawals, and archives.
Section 263. Human Review for Material AI Outputs
263.1 Human Review Requirement. Material AI outputs shall be subject to human review before reliance, publication, external release, public authority-facing use, finance-boundary use, certification-boundary use, procurement-sensitive use, Board use, committee use, council use, Nexus interface use, technical baseline use, public-safe dashboard use, public-safe map use, or controlled-room use where the output may materially affect meaning, evidence, authority, rights, safeguards, public trust, or institutional reliance. Human review shall be recorded and proportionate to risk.
263.2 Material Public Meaning Trigger. Human review shall be required where an AI output may create or alter public meaning, public claims, public-safe summaries, public reports, websites, media materials, public dashboards, public maps, public notices, sponsor acknowledgments, provider references, Nexus-compatible claims, public legitimacy statements, or correction notices. Review shall ensure accuracy, limitation language, classification, non-overclaim, and correction path.
263.3 Material Technical Meaning Trigger. Human review shall be required where an AI output may affect technical meaning, methods, evidence classification, source comparison, confidence scoring, ontology, schemas, data dictionaries, software releases, benchmark outputs, model cards, dataset cards, system cards, technical baselines, observability outputs, digital twins, geospatial outputs, cyber analysis, or infrastructure analysis.
263.4 Material Public Authority Meaning Trigger. Human review shall be required where an AI output involves public authority data, public authority participation, public authority reference, public finance readers, regulators, emergency management, public health, public safety, utilities, ports, telecom systems, energy systems, water systems, food systems, health systems, cyber systems, public infrastructure, or public-sector learning. Review shall preserve capacity classification and no-delegation, no-public-warning, no-emergency-command, no-regulatory-approval, no-procurement-approval, no-funding-approval, no-public-finance-approval, and no-sovereign-obligation boundaries.
263.5 Material Finance-Readiness Input Trigger. Human review shall be required where an AI output may be read as finance-readiness, capital-readability, routeability, investment suitability, bankability, insurability, underwriting suitability, creditworthiness, rating, lending suitability, public finance approval, capital recommendation, insurance recommendation, securities recommendation, or project finance evidence. Review shall ensure that GCRI Canada does not provide finance-readiness determinations, investment advice, insurance advice, underwriting approval, rating, lending advice, capital placement, investor matchmaking, or public finance approval.
263.6 Material Docket or Grid Input Trigger. Human review shall be required where an AI output may affect a Nexus Docket record, correction ticket, issue routing, governance record, Nexus Grid evidence input, maturity-surface input, capability-review input, infrastructure-review input, Observatory status input, or participation record. Review shall prevent AI outputs from becoming maturity determinations, standing determinations, recognition, public legitimacy, certification, procurement approval, or finance-readiness by implication.
263.7 Material Public-Safe Publication Trigger. Human review shall be required before AI-assisted material is released in public-safe publications, dashboards, maps, summaries, teaching materials, public authority learning materials, public reports, controlled-to-public transformations, public notices, or Gazette-style outputs. Review shall address accuracy, source support, public-safe classification, limitation language, redaction, aggregation, de-identification, accessibility, and correction path.
263.8 Material Data, AI, Cyber, Privacy, Safeguards, or Protected Knowledge Trigger. Human review shall be required where an AI output involves personal information, sensitive personal information, health-sensitive data, public authority-sensitive data, protected knowledge, Indigenous / local / territorial knowledge, cyber-sensitive data, infrastructure-sensitive data, AI-risk issues, prompt injection, data leakage, model drift, agentic tool use, or safeguards concerns. Review shall protect rights, confidentiality, security, and public-benefit integrity.
263.9 Reviewer Qualifications. Human reviewers shall have qualifications, experience, authority, or assigned competence appropriate to the review. Relevant qualifications may include evidence methods, subject-matter expertise, data governance, AI governance, cyber security, privacy, public authority boundaries, finance-boundary literacy, safeguards, protected knowledge, legal review, research integrity, technical engineering, geospatial analysis, or publication review. Reviewer qualifications shall be recorded where material.
263.10 Reviewer Independence. Human reviewers shall be sufficiently independent for the review function. Independence review shall consider sponsor relationships, provider relationships, donor relationships, public authority role, project role, authorship role, financial interest, employment relationship, advisory role, technical contribution, and prior involvement. Where full independence is not feasible, conflicts and limitations shall be recorded and additional review may be required.
263.11 Reviewer Conflict Screening. Reviewers shall disclose conflicts before reviewing material AI outputs where conflicts may affect judgment or public trust. Conflicts may include financial interests, provider interests, sponsor interests, public authority interests, institutional interests, authorship interests, personal relationships, advocacy positions, investment interests, procurement interests, or competitive interests. Conflicted reviewers may be recused, limited, paired, or subject to additional review.
263.12 Review Criteria. Human review criteria shall include source support, evidence sufficiency, method appropriateness, model limitations, retrieval quality, hallucination risk, data rights, classification, public-safe status, public authority boundaries, protected knowledge, privacy, cyber safety, infrastructure safety, finance-boundary implications, certification-boundary implications, procurement implications, provider-neutrality risk, sponsor influence, uncertainty, limitation language, and correction path.
263.13 Review Outcome. Human review outcomes may include approval, conditional approval, revision required, escalation, quarantine, rejection, reclassification, confidence adjustment, public-safe redaction, controlled annexing, withdrawal from reliance, correction, or further review. The outcome shall be recorded with reasons, conditions, authority, affected records, and follow-up obligations.
263.14 Escalation. AI outputs shall be escalated where review identifies unresolved legal risk, public authority concern, protected knowledge concern, data incident, cyber incident, infrastructure sensitivity, finance overclaim, certification overclaim, procurement implication, provider preference, sponsor influence, research integrity issue, major uncertainty, public-safe risk, or Board-reserved matter. Escalation shall identify responsible body, interim hold, and closeout path.
263.15 No Human Review as Mere Rubber Stamp. Human review shall not be performed as a mere rubber stamp of AI output. Reviewers shall exercise independent judgment, check source support, review limitations, identify uncertainty, correct errors, challenge unsupported claims, and ensure that outputs remain within GCRI Canada’s public-benefit, non-executing, role-separated boundaries. A record that only notes that AI output was “reviewed” without meaningful review may be insufficient for material reliance.
263.16 Human Review Records. GCRI Canada shall maintain human review records, including review triggers, reviewer identity, reviewer qualifications, independence review, conflict screening, materials reviewed, criteria applied, outcome, conditions, corrections, escalations, approvals, rejections, public-safe determinations, limitation language, correction paths, dependency reviews, closeout, and archives.
Section 264. Agentic AI Controls, Tool Permissions, Logs, Approval Gates, Prohibited Actions, Kill Switches, and Incident Procedures
264.1 Agentic AI Control Purpose. Agentic AI controls shall ensure that AI systems capable of planning, tool use, external action, multi-step execution, autonomous retrieval, code execution, communication, data transfer, repository modification, workflow execution, or system interaction operate only under approved scope, least privilege, human oversight, logging, approval gates, prohibited-action rules, kill switches, incident response, and correctionability. Agentic AI shall support evidence and methods work; it shall not become an autonomous institutional actor.
264.2 Agentic AI Register. GCRI Canada shall maintain a register of agentic AI systems used or tested in material workflows. The register shall identify agent identity, model identity, tool permissions, owner, custodian, purpose, risk class, data access class, environment, permitted actions, prohibited actions, approval gates, human-in-the-loop requirements, logging, monitoring, kill switch, deployment status, incident history, and retirement status.
264.3 Tool Permission Scoping. Agentic AI tool permissions shall be scoped to the minimum functions necessary for the approved purpose. Tool permissions shall identify whether the agent may search, retrieve, summarize, classify, draft, calculate, code, test, query, transform, visualize, write files, open tickets, update repositories, send messages, access rooms, interact with APIs, or produce outputs. Permissions shall be documented and revocable.
264.4 Least-Privilege Tool Access. Agentic AI shall operate under least-privilege access. It shall not receive broad repository access, unrestricted file access, unrestricted internet access, unrestricted data-room access, unrestricted public authority data access, unrestricted protected knowledge access, unrestricted credentials, payment authority, publication authority, contracting authority, procurement authority, or deletion authority. Temporary elevated access shall require recorded approval and monitoring.
264.5 Prohibited Tool Actions. GCRI Canada shall define prohibited tool actions for agentic AI. Prohibited actions shall include unauthorized publication, unauthorized external communication, unauthorized public authority communication, unauthorized legal commitment, unauthorized contract execution, unauthorized payment, unauthorized procurement, unauthorized fundraising, unauthorized investment or insurance activity, unauthorized data transfer, unauthorized model training, unauthorized embedding, unauthorized deletion of official records, unauthorized access escalation, and unauthorized use of protected knowledge.
264.6 No Autonomous External Publication. Agentic AI shall not autonomously publish reports, public-safe summaries, public notices, dashboards, maps, websites, media materials, social media posts, Gazette notices, software releases, technical baselines, public claims, sponsor acknowledgments, provider references, or Nexus interface statements. External publication shall require competent human approval, classification, limitation language, and correction path.
264.7 No Autonomous Public Authority Communication. Agentic AI shall not autonomously communicate with public authorities, regulators, ministries, municipalities, Crown entities, emergency management bodies, public finance bodies, public infrastructure operators, public health bodies, utilities, ports, telecom systems, energy systems, water systems, food systems, health systems, or cyber bodies on behalf of GCRI Canada. Public authority communications require authorized human control and capacity classification.
264.8 No Autonomous Contracting, Payment, Procurement, Fundraising, Investment, Insurance, or Legal Commitment. Agentic AI shall not autonomously enter contracts, approve terms, make payments, initiate procurement, select providers, approve invoices, solicit donations, accept sponsorship, make grants, invest funds, advise on investment, place insurance, approve underwriting, create public finance commitments, or make legal commitments. Such acts require human authority, legal review where appropriate, and competent records.
264.9 No Autonomous Data Transfer Without Authorization. Agentic AI shall not autonomously transfer, export, email, upload, share, synchronize, publish, scrape, embed, index, or move data across systems, jurisdictions, rooms, repositories, providers, or public interfaces without recorded authorization. Data transfer controls shall protect public authority data, protected knowledge, personal information, cyber-sensitive data, infrastructure-sensitive data, finance-sensitive data, confidential materials, and controlled-room records.
264.10 No Autonomous Deletion of Official Records Without Authorization. Agentic AI shall not autonomously delete, overwrite, purge, seal, archive, alter retention, reclassify, or destroy official records, evidence records, Board records, committee records, council records, public authority records, source records, model records, repository records, correction records, or Nexus interface records. Deletion or disposal of official records requires lawful authority, retention review, and record.
264.11 Approval Gates. Agentic AI workflows shall include approval gates where actions may affect external communication, public meaning, public authority context, sensitive data, protected knowledge, cyber-sensitive systems, infrastructure-sensitive systems, finance-boundary materials, certification-boundary materials, procurement-sensitive matters, provider neutrality, sponsor benefits, official records, repositories, or Nexus interfaces. Approval gates shall be human-controlled and logged.
264.12 Human-in-the-Loop Requirements. Human-in-the-loop controls shall be required for agentic AI actions that materially affect meaning, records, access, outputs, publication, external communication, system state, public authority context, finance-boundary context, certification-boundary context, procurement-sensitive context, protected knowledge, cyber-sensitive data, infrastructure-sensitive data, or official records. Human control shall include review, approval, rejection, modification, or termination authority.
264.13 Logging Requirements. Agentic AI actions shall be logged. Logs shall identify agent identity, model identity, tools used, inputs accessed, outputs generated, actions proposed, actions taken, approvals requested, approvals granted, approvals denied, human reviewer, external calls, file changes, data transfers, errors, incidents, and correction actions. Logs shall be classified and retained according to sensitivity.
264.14 Monitoring Requirements. Agentic AI shall be monitored proportionate to risk. Monitoring may include real-time supervision, periodic log review, anomaly detection, tool-use review, access review, output review, model drift review, prompt injection review, data exfiltration review, incident review, and post-run audit. Monitoring shall be intensified for high-risk workflows and external-tool access.
264.15 Kill Switches. Agentic AI systems shall have kill switches or equivalent shutdown controls proportionate to risk. Kill switches shall allow authorized humans to stop the agent, revoke tool permissions, disable credentials, freeze workflows, block external calls, quarantine outputs, preserve logs, and initiate incident response. Kill-switch authority and procedures shall be recorded.
264.16 Emergency Shutdown. Emergency shutdown may be used where agentic AI creates or threatens unauthorized publication, unauthorized data transfer, protected knowledge exposure, public authority miscommunication, cyber risk, infrastructure risk, finance overclaim, certification overclaim, procurement implication, provider preference, record alteration, external harm, legal exposure, or institutional integrity harm. Emergency shutdown shall preserve logs and trigger review.
264.17 Agentic AI Incident Procedures. Agentic AI incidents shall be handled through incident procedures that include containment, access revocation, credential rotation, log preservation, affected-record identification, output quarantine, notification where required, legal review, data / AI / cyber review, public authority review, safeguards review, finance-boundary review, correction, dependency review, and closeout.
264.18 Agentic AI Control Records. GCRI Canada shall maintain agentic AI control records, including agentic AI register records, tool permission records, least-privilege records, prohibited-action records, external-publication restriction records, public authority communication restriction records, contracting / payment / procurement / fundraising / investment / insurance / legal commitment restriction records, data-transfer records, deletion-control records, approval-gate records, human-in-the-loop records, logs, monitoring records, kill-switch records, emergency shutdown records, incident procedure records, corrections, retirements, and archives.
Section 265. AI Output Limits and No AI-as-Authority Rule
265.1 AI Output as Draft, Evidence-Supporting, Classification-Supporting, Summarization, Anomaly Detection, Corroboration, Routing, or Review Artifact. AI output may be used by GCRI Canada as a draft, evidence-supporting artifact, classification-supporting artifact, summarization aid, translation aid, coding aid, anomaly-detection artifact, corroboration artifact, source-comparison artifact, routing artifact, review artifact, public-safe drafting aid, or correction trigger, subject to authority, classification, human review where required, limitation language, and correction path. AI output shall not be treated as self-validating institutional authority.
265.2 No AI Output as Official Truth. No AI output shall be represented as official truth, absolute truth, final truth, complete truth, universal truth, public authority truth, legal truth, financial truth, certified truth, scientific truth without method support, or technical truth without evidence record. AI output is source-dependent, model-dependent, prompt-dependent, tool-dependent, context-dependent, uncertainty-bearing, and correctionable.
265.3 No AI Output as Board Decision. No AI output shall constitute a Board decision, Board approval, Board delegation, Board resolution, Board interpretation, Board policy, Board finding, Board instruction, or Board action. The Board may consider AI-assisted materials only where properly classified, reviewed, limited, recorded, and incorporated into competent Board process.
265.4 No AI Output as Officer Decision Unless Adopted by Authorized Human Actor. No AI output shall constitute an officer decision unless an authorized human officer reviews, adopts, records, and takes responsibility for the decision within lawful authority. AI may support analysis or drafting but shall not exercise officer judgment, bind GCRI Canada, approve expenditures, authorize publication, approve contracts, accept funds, reject corrections, classify public authority status, or approve sensitive data use without human authority.
265.5 No AI Output as Public Authority Decision. No AI output shall constitute a public authority decision, governmental determination, regulatory approval, public finance approval, funding approval, procurement approval, public warning, emergency declaration, public health order, public safety directive, official policy, permit, license, public authority endorsement, or sovereign obligation. Public authority meaning must arise from the competent public authority and record.
265.6 No AI Output as Public Warning. No AI output, dashboard output, map output, anomaly flag, risk score, confidence score, degraded-mode signal, cyber alert, sensor fusion result, AI-RAN signal, DePIN signal, public-safe summary, or generated notice shall be represented as an official public warning unless issued by an authorized public authority. GCRI Canada shall not permit AI-generated language to create public warning confusion.
265.7 No AI Output as Emergency Command. No AI output shall constitute emergency command, incident command, dispatch, evacuation order, operational instruction, public safety direction, infrastructure control instruction, cyber incident command, emergency management action, or responder direction. AI may support evidence review and learning but shall not command execution.
265.8 No AI Output as Recognition, Standing, or Public Legitimacy. No AI output shall create recognition, standing, public legitimacy, maturity status, GRF recognition, Nexus Grid status, host readiness, provider readiness, project readiness, public-good standing, stakeholder status, or public-facing legitimacy. Such status may arise only through the separately authorized body and competent record, if applicable.
265.9 No AI Output as Finance-Readiness, Insurance-Readiness, Investment Suitability, Bankability, Rating, or Capital Recommendation. No AI output shall constitute finance-readiness, capital-readiness, routeability, investment suitability, securities recommendation, capital recommendation, bankability, insurability, insurance-readiness, underwriting approval, lending suitability, creditworthiness, rating, public finance approval, guarantee eligibility, insurance placement, investor matchmaking, or capital placement. AI-assisted finance-boundary materials shall be treated only as technical evidence or drafting support where authorized and reviewed.
265.10 No AI Output as Certification, Accreditation, Compliance Approval, Procurement Approval, or Provider Preference. No AI output shall constitute certification, accreditation, conformity assessment, compliance approval, safety approval, product approval, provider approval, procurement approval, tender qualification, preferred provider status, provider ranking, provider endorsement, professional credential, or performance warranty. AI-generated comparisons or scores shall not be used to create provider preference or procurement influence without lawful authority and review, and GCRI Canada shall maintain procurement neutrality.
265.11 No AI Output as Legal, Engineering, Clinical, Financial, Insurance, Accounting, Rating, or Other Regulated Professional Opinion Unless Separately Authorized and Controlled. No AI output shall be represented as legal advice, engineering opinion, clinical opinion, medical advice, public health order, accounting opinion, audit opinion, tax advice, investment advice, insurance advice, actuarial opinion, underwriting decision, lending advice, securities advice, credit rating, or other regulated professional opinion unless separately authorized, licensed where required, controlled by competent professional processes, human-reviewed, and recorded with scope and limitations. By default, AI outputs are support artifacts only.
265.12 AI Output Requires Context, Review, Record, Classification, and Correction Path. Each material AI output shall be contextualized, reviewed where required, recorded, classified, limited, and correctionable before reliance. The record shall identify source context, prompt or query context where retained and lawful, model identity, tool identity, input classification, output classification, confidence, limitations, reviewer, use decision, public-safe status, and correction path.
265.13 AI Output Limitation Language. AI-assisted outputs shall include limitation language proportionate to risk and use. Limitation language may state that the output is AI-assisted, evidence-dependent, method-bound, human-reviewed where applicable, not official truth, not Board action, not officer action unless adopted, not public authority decision, not public warning, not emergency command, not finance-readiness, not certification, not procurement approval, not provider endorsement, not regulated professional advice, and subject to correction.
265.14 AI Output Limit Records. GCRI Canada shall maintain AI output limit records, including AI output classifications, permitted-use records, prohibited-use records, context records, review records, human adoption records where applicable, limitation language, public authority boundary records, public warning boundary records, emergency command boundary records, recognition boundary records, finance-readiness boundary records, certification boundary records, procurement boundary records, provider-neutrality records, regulated professional opinion boundary records, correction paths, corrections, supersessions, withdrawals, incidents, and archives.
Section 266. AI Incidents, Hallucinations, Unsafe Outputs, Data Leakage, Unauthorized Agent Actions, Bias, Drift, and Public Overclaim
266.1 AI Incident Definition. An AI incident means any event, condition, output, action, omission, system behaviour, retrieval failure, model failure, agentic action, data exposure, public-safe failure, record-integrity failure, or public-meaning failure involving an AI system, machine learning model, statistical model, digital twin, simulation model, generative model, agentic AI system, retrieval system, embedding store, inference system, AI-assisted workflow, AI provider, AI tool chain, or AI-enabled dashboard that may materially affect GCRI Canada’s evidence integrity, methods integrity, research integrity, public-benefit purpose, data / AI / cyber posture, privacy obligations, safeguards obligations, public authority boundaries, finance-readiness boundaries, certification boundaries, procurement neutrality, provider neutrality, sponsor non-control, Nexus interface meaning, public-safe outputs, or correctionability. AI incidents shall be classified, contained, reviewed, corrected, recorded, and closed through a process proportionate to severity, sensitivity, public meaning, legal exposure, affected stakeholders, and downstream dependency.
266.2 Hallucination Incident. A hallucination incident means an AI output that states or implies a fact, citation, source, legal position, public authority position, technical conclusion, evidence conclusion, method conclusion, finance-readiness implication, certification implication, procurement implication, recognition implication, maturity implication, provider preference, or Nexus interface status that is not supported by the record. A hallucination incident may occur even where the output is plausible, well-written, internally coherent, or partially supported by other materials. Hallucinations affecting public materials, Board materials, public authority-facing materials, finance-boundary materials, certification-boundary materials, procurement-sensitive materials, protected knowledge, cyber-sensitive analysis, infrastructure-sensitive analysis, or Nexus interface records shall require immediate review, limitation, correction, quarantine, or withdrawal as appropriate.
266.3 Fabricated Citation or Source Incident. A fabricated citation or source incident means an AI output that invents, misattributes, misquotes, overstates, mislinks, distorts, or falsely relies on a source, record, document, statute, regulation, public authority statement, Board decision, committee record, evidence artifact, method note, dataset, model card, system card, benchmark card, public authority communication, GRF record, GRA record, GCRI US record, Nexus Standards record, Nexus Observatory record, Nexus Rails record, Nexus Grid record, Nexus Academy record, consortium record, provider record, sponsor record, or public-safe output. Fabricated citation incidents shall be treated as evidence integrity incidents and shall require source verification, output correction, reviewer notice where applicable, affected-record review, and downstream dependency assessment.
266.4 Unsafe Output Incident. An unsafe output incident means an AI output that creates or increases risk to persons, communities, public authorities, infrastructure, cyber systems, protected knowledge, privacy, public safety, public trust, public-good assets, controlled rooms, data rooms, public-safe publications, or Nexus interfaces. Unsafe outputs may include disclosure of exploitable cyber details, infrastructure vulnerabilities, sensitive geospatial information, protected knowledge, personal information, public authority-sensitive information, finance-sensitive information, operationally sensitive details, misleading emergency language, biased or discriminatory content, unsafe instructions, unauthorized legal or financial implications, or outputs likely to cause panic, targeting, retaliation, misreliance, or public authority confusion.
266.5 Data Leakage Incident. A data leakage incident means any unauthorized or unintended exposure, extraction, reconstruction, memorization, retrieval, summarization, embedding disclosure, prompt disclosure, context disclosure, source disclosure, metadata disclosure, model-output disclosure, cross-user disclosure, cross-room disclosure, provider disclosure, or public release of data through an AI system or AI-assisted workflow. Data leakage may involve personal information, sensitive personal information, public authority data, protected knowledge, cyber-sensitive records, infrastructure-sensitive records, finance-sensitive materials, confidential sponsor or provider materials, Board materials, committee materials, controlled annexes, retrieval indexes, embeddings, vector stores, logs, prompts, outputs, or caches. Data leakage shall trigger containment, access review, deletion or re-indexing where feasible, notification review, correction, and incident records.
266.6 Unauthorized Access Incident. An unauthorized access incident means AI-assisted access to data, records, systems, rooms, repositories, tools, models, dashboards, maps, public authority materials, protected knowledge, controlled annexes, finance-sensitive materials, cyber-sensitive materials, infrastructure-sensitive materials, embeddings, indexes, or outputs beyond the authority, role, room, document, row, field, classification, or purpose permitted for the user, model, agent, tool, or workflow. Unauthorized access shall include both direct retrieval and indirect reconstruction, summarization, citation, inference, or metadata exposure. Such incidents shall require immediate access restriction, credential review, retrieval permission review, affected-source review, and correction.
266.7 Unauthorized Agent Action Incident. An unauthorized agent action incident means an agentic AI system takes, attempts, proposes as completed, or causes an action outside its approved scope, tool permissions, approval gates, or human-in-the-loop requirements. Unauthorized agent actions may include external publication, public authority communication, contract generation as binding commitment, payment initiation, procurement action, fundraising communication, investment or insurance action, data transfer, repository modification, deletion of official records, room access, credential use, public claims generation, sponsor acknowledgment, provider reference, or Nexus interface communication without competent human authorization and record. Such incidents shall be contained through tool revocation, workflow freeze, log preservation, output quarantine, and incident review.
266.8 Bias or Discriminatory Output Incident. A bias or discriminatory output incident means an AI output, model behaviour, ranking, classification, retrieval result, summary, recommendation, score, dashboard, map, public-safe output, or inference that may unfairly disadvantage, mischaracterize, exclude, stereotype, stigmatize, target, erase, or overexpose a person, group, community, Indigenous people, local community, territorial community, protected class, vulnerable population, protected participant, public authority participant, researcher, contributor, provider, host, or stakeholder. Bias incidents shall be reviewed for source bias, data bias, model bias, retrieval bias, prompt bias, evaluation bias, public-safe harm, accessibility, language, cultural context, power imbalance, and correction pathway.
266.9 Model Drift Incident. A model drift incident means a material change in model performance, output behaviour, calibration, reliability, bias, error profile, retrieval quality, tool-use behaviour, safety posture, security posture, or public-safe suitability caused by changed model version, changed provider system, changed data distribution, changed prompt framework, changed retrieval index, changed tool chain, changed environment, changed source population, changed law, changed public authority context, changed infrastructure condition, changed community context, or changed external environment. Drift incidents may require suspension, re-evaluation, confidence adjustment, limitation update, reclassification, output review, retraining restriction, or model retirement.
266.10 Retrieval Failure Incident. A retrieval failure incident means an AI retrieval, search, embedding, vector, knowledge graph, RAG, or context assembly system retrieves incorrect, stale, superseded, withdrawn, restricted, unauthorized, incomplete, misleading, misranked, context-collapsed, sponsor-biased, provider-biased, public authority-misclassified, protected-knowledge-exposing, or finance-sensitive material, or fails to retrieve material contradictory or limiting sources. Retrieval failure shall be reviewed for source indexing, permission mapping, re-indexing, ranking, chunking, metadata, citation, access control, stale cache, deletion pathway, and public-safe limitation.
266.11 Prompt Injection Incident. A prompt injection incident means an AI system, agent, retrieval system, tool chain, document, webpage, dataset, code file, message, model output, or external source causes or attempts to cause an AI system to ignore instructions, reveal restricted data, misuse tools, take unauthorized actions, alter outputs, bypass access controls, disclose confidential information, produce unsafe public claims, distort evidence, or manipulate institutional process. Prompt injection incidents shall trigger containment, source quarantine, tool-permission review, retrieval sanitization, log preservation, security review, affected-output review, and correction.
266.12 Public Overclaim Incident. A public overclaim incident means an AI-assisted output or AI-supported workflow creates public-facing language that overstates evidence, methods, confidence, public authority participation, sponsor support, provider participation, Nexus compatibility, technical validity, public-good impact, safety, reliability, readiness, maturity, recognition, finance-readiness, certification, procurement relevance, public warning status, emergency command status, or institutional authority. Public overclaim incidents shall require immediate review of public materials, limitation language, public-safe correction, withdrawal where needed, and downstream dependency review.
266.13 Public Authority Misdescription Incident. A public authority misdescription incident means an AI output misstates, implies, invents, or overstates public authority participation, capacity, approval, adoption, endorsement, funding, procurement, regulation, public warning, emergency command, public finance approval, sovereign obligation, data contribution, quote, attendance, logo permission, or official position. Such incidents shall be treated as public authority boundary incidents and shall require capacity review, reference review, affected-public-authority notification where appropriate, public-safe correction where necessary, and record correction.
266.14 Finance, Certification, Procurement, Recognition, or Maturity Overclaim Incident. A finance, certification, procurement, recognition, or maturity overclaim incident means an AI output or AI-assisted process implies that GCRI Canada, an AI system, a Truth Engine output, an assurance pack, a dashboard, a map, a model score, an evidence record, a method, a public-good technical asset, a provider, a host, a sponsor, a project, a National Consortium Company, a Project SPV, or any Nexus interface has finance-readiness, insurance-readiness, investment suitability, bankability, rating, underwriting approval, public finance approval, certification, accreditation, compliance approval, procurement approval, provider preference, recognition, standing, maturity status, Nexus Grid status, GRF recognition, or public legitimacy beyond the competent record. Such incidents shall require boundary correction, public-safe limitation, dependency review, and, where necessary, withdrawal or retraction.
266.15 Incident Severity Classification. AI incidents shall be classified by severity. Severity classification shall consider affected data class, public exposure, public authority involvement, protected knowledge, personal information, cyber sensitivity, infrastructure sensitivity, finance sensitivity, competition sensitivity, legal exposure, stakeholder harm, community harm, public-safe risk, operational misuse, public overclaim, record integrity, recurrence, agent autonomy, affected systems, and downstream dependencies. Severity may be classified as informational, low, moderate, high, critical, or emergency, or by another Board-approved scale. Higher-severity incidents shall require escalation, containment, and Board or committee notice where appropriate.
266.16 Containment. Containment of an AI incident may include suspending model use, disabling an agent, revoking tool permissions, freezing retrieval indexes, restricting access, quarantining outputs, removing public materials, disabling dashboards or maps, pausing publication, locking repositories, disabling API keys, rotating credentials, preserving logs, notifying custodians, isolating compute environments, placing legal or investigation holds, and initiating data / AI / cyber, public authority, safeguards, finance-boundary, or legal review. Containment shall be proportionate and shall preserve evidence.
266.17 Correction. AI incident correction may include source correction, prompt correction, retrieval correction, re-indexing, deletion, model configuration change, model suspension, model replacement, output correction, public-safe correction notice, controlled correction notice, limitation update, confidence adjustment, human review, method correction, ontology correction, public authority reference correction, finance-boundary correction, certification-boundary correction, procurement-boundary correction, provider-neutrality correction, sponsor-language correction, and downstream dependency remediation. Correction shall preserve historical traceability and shall not conceal material error.
266.18 Notification Where Required. GCRI Canada shall provide notification where required by law, contract, public authority terms, privacy obligations, cyber obligations, protected knowledge protocols, research ethics, sponsor or donor agreements, provider agreements, Board policy, or public-safe integrity. Notification may be public, public-safe, controlled, internal, public authority-specific, community-specific, participant-specific, provider-specific, sponsor-specific, or Nexus-interface-specific. Notification shall avoid disclosing sensitive details beyond what is lawful, necessary, and safe.
266.19 Post-Incident Review. Each material AI incident shall receive a post-incident review proportionate to severity. The review shall identify root cause, affected records, affected sources, affected models, affected prompts, affected tools, affected indexes, affected outputs, affected users, failed controls, conflict issues, provider issues, public authority issues, safeguards issues, cyber issues, infrastructure issues, finance-boundary issues, certification-boundary issues, procurement issues, public-safe failures, corrective actions, recurrence prevention, training needs, policy changes, and record updates.
266.20 AI Incident Records. GCRI Canada shall maintain AI incident records, including incident intake, incident classification, hallucination records, fabricated citation records, unsafe output records, data leakage records, unauthorized access records, unauthorized agent action records, bias records, drift records, retrieval failure records, prompt injection records, public overclaim records, public authority misdescription records, finance / certification / procurement / recognition / maturity overclaim records, severity classification, containment actions, corrections, notifications, post-incident reviews, dependency reviews, closeout records, and archives.
Section 267. Model Restriction, Suspension, Retirement, Deprecation, and Archival
267.1 Model Restriction. GCRI Canada may restrict a model where the model remains potentially useful but requires narrowed scope, reduced data access, heightened human review, limited environments, prohibited output classes, public-safe restrictions, room-only use, no-publication use, no-public-authority-facing use, no-finance-boundary use, no-certification-boundary use, no-procurement-sensitive use, or no-protected-knowledge use. Restriction shall be recorded in the Model Register and shall specify affected users, workflows, data classes, tool permissions, output classes, review gates, correction path, and review date.
267.2 Model Suspension. GCRI Canada may suspend a model where continued use may create risk to evidence integrity, public-safe publication, protected knowledge, public authority boundaries, data privacy, cyber security, infrastructure sensitivity, finance boundaries, certification boundaries, procurement neutrality, provider neutrality, sponsor non-control, or institutional trust. Suspension may apply to all use or defined uses. Suspension shall trigger access restriction, workflow freeze, output review, incident review where applicable, dependency review, and notice to affected users.
267.3 Model Retirement. GCRI Canada may retire a model when it is obsolete, unsafe, unsupported, superseded, legally restricted, no longer fit for purpose, no longer available under acceptable terms, no longer evaluable, inconsistent with public-benefit purpose, or no longer capable of supporting auditability, classification, human review, and correctionability. Retirement shall include reliance limitations, replacement guidance where appropriate, access revocation, record preservation, and archival.
267.4 Model Deprecation. GCRI Canada may deprecate a model where a successor model, method, system, tool, provider arrangement, or governance control is preferred, but limited existing reliance or transition support remains necessary. Deprecation shall identify end-of-use date, transition period, permitted interim uses, prohibited new uses, affected outputs, public-safe limitations, successor pathway, review obligations, and archival requirements.
267.5 Model Archival. Model archival shall preserve model records for institutional memory, auditability, research integrity, correctionability, incident review, dependency analysis, and legal compliance. Archive records shall identify model identity, versions, providers, configurations, permitted uses, prohibited uses, evaluation history, incident history, restrictions, suspensions, retirement or deprecation status, affected outputs, and reliance limitations. Archival shall not imply current approval or continued authority.
267.6 Unsafe Model. A model shall be treated as unsafe where its use creates unacceptable risk of hallucination, fabricated sources, unsafe advice, data leakage, prompt injection, unauthorized agent action, discriminatory output, public authority misdescription, finance overclaim, certification overclaim, procurement implication, provider preference, protected knowledge exposure, cyber-sensitive disclosure, infrastructure-sensitive disclosure, or other harm. Unsafe models shall be restricted, suspended, retired, or prohibited as appropriate.
267.7 Unsupported Model. A model shall be treated as unsupported where the provider, maintainer, documentation, evaluation basis, security updates, terms, dependencies, or technical context no longer support safe, auditable, lawful, and correctionable use. Unsupported models shall not be used for material public-facing, public authority-facing, finance-boundary, certification-boundary, procurement-sensitive, protected-knowledge, cyber-sensitive, or infrastructure-sensitive outputs without express review and limitation.
267.8 Compromised Model. A model shall be treated as compromised where there is credible evidence of malicious modification, unauthorized access, poisoned training, poisoned fine-tuning, prompt-injection susceptibility beyond acceptable controls, data exfiltration, provider breach, tool-chain compromise, model-weight compromise, dependency compromise, output manipulation, benchmark gaming, or security failure. Compromised models shall be suspended pending investigation and may be retired, replaced, or restored only after review.
267.9 Outdated Model. A model shall be treated as outdated where its data, methods, version, evaluation, provider terms, security posture, legal assumptions, public authority context, technology assumptions, or domain knowledge are no longer sufficiently current for the intended use. Outdated models may be limited to low-risk drafting or historical review only where classification, limitation, and human review allow such use.
267.10 Superseded Model. A superseded model means a model replaced by another model, system, method, provider, or version for some or all approved uses. Supersession shall identify the successor, effective date, transition period, prohibited future uses, affected records, affected outputs, confidence effects, and dependency review. Superseded models shall not remain in production by convenience or unnoticed technical persistence.
267.11 Unfit Model. A model shall be treated as unfit where it is not suitable for a proposed purpose, data class, audience, jurisdiction, public authority context, protected knowledge context, cyber context, infrastructure context, finance-boundary context, certification-boundary context, procurement-sensitive context, or public-safe output. Unfitness may arise from evaluation results, limitations, lack of authority, lack of transparency, lack of human review capacity, lack of deletion pathway, or inability to support correction.
267.12 Restricted-Use Model. A restricted-use model may be approved only for defined low-risk, controlled, internal, sandbox, research, evaluation, drafting, translation, coding, classification-supporting, or non-public uses. Restricted-use models shall include express prohibitions on public release, public authority-facing use, finance-boundary use, certification-boundary use, procurement-sensitive use, protected knowledge processing, sensitive data processing, autonomous action, or official-record alteration unless separately approved.
267.13 Review Before Reinstatement. A restricted, suspended, deprecated, retired, or previously unsafe model may be reinstated only after review confirms that the reason for restriction has been resolved or adequately controlled. Reinstatement review shall address model identity, version, provider terms, data-use settings, security, privacy, evaluation, drift, incidents, tool permissions, retrieval controls, human review, public-safe suitability, and correction path. Reinstatement shall be recorded and may be conditional.
267.14 Migration to Successor Model. Migration to a successor model shall include review of affected workflows, prompts, retrieval systems, embeddings, data inputs, tool permissions, output formats, evaluation baselines, benchmark results, public-safe outputs, dashboards, maps, technical baselines, evidence packs, inference records, and downstream dependencies. Migration shall not assume equivalence between models. Differences in performance, limitations, confidence, security, privacy, public authority treatment, finance-boundary treatment, and safeguards shall be recorded.
267.15 Downstream Dependency Review. Restriction, suspension, retirement, deprecation, supersession, or reinstatement of a model shall trigger downstream dependency review where the model affected evidence records, research outputs, publications, public-safe summaries, dashboards, maps, technical baselines, software tools, public authority materials, Board materials, council outputs, finance-boundary materials, certification-boundary materials, procurement-sensitive materials, Nexus interface records, or correction decisions. Dependency review shall identify whether outputs require correction, limitation, reclassification, republication, withdrawal, retraction, or archival.
267.16 Notice of Restriction, Suspension, Retirement, or Deprecation. GCRI Canada shall issue internal, controlled, public-safe, or Nexus-interface notice of model restriction, suspension, retirement, or deprecation where necessary to prevent reliance, misuse, public overclaim, public authority confusion, finance implication, certification implication, procurement implication, provider preference, or recurrence of incident. Notice shall identify affected uses, effective date, limitations, transition requirements, successor model where any, and correction path.
267.17 Model Archive Records. Model archive records shall preserve prior model status, versions, configurations, provider terms, evaluation records, incidents, restrictions, suspensions, deprecations, retirements, supersessions, reinstatements, migration notes, reliance limits, and affected-output links. Archive records shall be classified and retained according to law, policy, data / AI / cyber requirements, public authority terms, research integrity, and correctionability.
267.18 Model Lifecycle Records. GCRI Canada shall maintain model lifecycle records, including restriction records, suspension records, retirement records, deprecation records, archival records, unsafe model records, unsupported model records, compromised model records, outdated model records, superseded model records, unfit model records, restricted-use model records, reinstatement reviews, successor migration records, downstream dependency reviews, notices, corrections, withdrawals, retractions, and archives.
Section 268. Verifiable Intelligence Records and Public-Safe Intelligence Outputs
268.1 Verifiable Intelligence Record Requirement. GCRI Canada shall maintain verifiable intelligence records for material public-good intelligence outputs, public-safe intelligence outputs, observability outputs, Truth Engine outputs, resilience indicators, degraded-mode awareness outputs, risk evidence summaries, technical evidence summaries, public authority learning materials, dashboards, maps, controlled intelligence notes, finance-boundary technical evidence inputs, Nexus interface intelligence artifacts, and other intelligence-like outputs produced through evidence, methods, ontology, compute, AI, or source comparison processes. Verifiable intelligence records shall preserve source lineage, method support, confidence, limitations, human review, classification, boundary review, correction path, and retention.
268.2 Intelligence Output Identifier. Each material intelligence output shall have an identifier linking the output to its source records, method records, model or process records, compute workload records, inference records, human review records, classification records, approval records, limitation language, correction path, publication status, controlled annexes, and downstream dependencies. The identifier may include docket ID, output ID, run ID, evidence pack ID, dashboard ID, map layer ID, report ID, Gazette notice ID, repository reference, or other approved reference.
268.3 Source Record. Each intelligence output shall identify source records sufficient to support the claims made. Source records shall include source identity, provenance, custody, timestamp, jurisdiction, permission, classification, reliability, integrity, confidence, uncertainty, dispute status, protected knowledge status, public authority capacity where applicable, and correction path. Public-safe versions may summarize sources where full disclosure would be unsafe or unlawful.
268.4 Method Record. Each intelligence output shall identify the method or methods used to select, transform, compare, weight, interpret, summarize, classify, map, model, simulate, or publish the underlying information. Method records shall include method version, owner, applicability, limitations, assumptions, exclusions, review status, public-safe status, controlled annexes where applicable, and correction path. An intelligence output without adequate method record shall not be used for material public reliance.
268.5 Model or Process Record. Where an intelligence output is generated, supported, summarized, classified, scored, translated, mapped, modeled, simulated, or reviewed using AI, machine learning, statistical models, digital twins, simulations, retrieval systems, agentic systems, software tools, dashboards, or other computational processes, the output shall identify the model or process record. The record shall include model identity, tool identity, execution environment, workload identifier, output classification, limitations, human review, and correction path.
268.6 Confidence Record. Each intelligence output shall include a confidence record proportionate to use. The confidence record shall identify confidence score or band where used, confidence rationale, source quality, corroboration, contradiction, missing data, stale data, disputed evidence, model limits, method limits, uncertainty, reviewer judgment, and confidence-change triggers. Confidence shall not be represented as rating, guarantee, certification, maturity status, finance-readiness, public authority decision, public warning, or procurement approval.
268.7 Limitation Record. Each intelligence output shall include a limitation record identifying scope, source limitations, method limitations, model limitations, data limitations, temporal limitations, jurisdictional limitations, public authority limitations, protected knowledge limitations, cyber limitations, infrastructure limitations, finance-boundary limitations, certification-boundary limitations, procurement-boundary limitations, provider-neutrality limitations, sponsor-related limitations, public-safe redactions, and non-use conditions. Limitation records shall be adapted to public, controlled, restricted, and internal audiences.
268.8 Human Review Record. Each material intelligence output shall include a human review record where human review is required. The record shall identify reviewer, role, qualifications where material, independence, conflicts, review scope, materials reviewed, criteria applied, corrections required, conditions, approval or non-approval, escalation, and public-safe determination. Human review shall be substantive and shall not merely acknowledge AI or model output.
268.9 Classification Record. Each intelligence output shall be classified before release or reliance. Classification shall identify publication class, access class, handling class, data sensitivity, public authority sensitivity, cyber sensitivity, infrastructure sensitivity, finance sensitivity, competition sensitivity, protected knowledge status, AI-use status, room status, public-safe status, and retention class. Classification may require public, public-safe, controlled, restricted, confidential, no-download, room-only, public authority-limited, safeguards-limited, cyber-limited, infrastructure-limited, finance-boundary-limited, or archive-only handling.
268.10 Public-Safe Status. Each intelligence output shall identify whether it is public-safe, public-safe after redaction, public-safe after aggregation, public-safe after delay, controlled only, restricted, confidential, public authority-limited, safeguards-limited, cyber-limited, infrastructure-limited, finance-boundary-limited, or not suitable for external release. Public-safe status shall be based on source review, method review, public authority review, safeguards review, data / AI / cyber review, infrastructure review, finance-boundary review, certification-boundary review, procurement-boundary review, and correction path.
268.11 Public Authority Boundary Review. Where an intelligence output involves public authority data, public authority participation, public authority reference, public finance readers, emergency management, public health, public safety, regulators, ministries, municipalities, Crown entities, utilities, ports, telecom systems, energy systems, water systems, food systems, health systems, cyber systems, infrastructure operators, or public-sector learning, the output shall include public authority boundary review. The review shall confirm capacity classification, non-endorsement, no-delegation, no-public-warning, no-emergency-command, no-regulatory-approval, no-procurement-approval, no-funding-approval, no-public-finance-approval, no-sovereign-obligation, and correction language.
268.12 Finance, Certification, Procurement, Recognition, and Public Warning Boundary Review. Each material intelligence output shall be reviewed to ensure it does not imply finance-readiness, insurance-readiness, investment suitability, bankability, creditworthiness, rating, underwriting approval, lending suitability, public finance approval, capital recommendation, certification, accreditation, compliance approval, procurement approval, provider preference, recognition, standing, maturity, public legitimacy, public warning, emergency command, or public authority decision beyond lawful authority and competent record. Where confusion is possible, express boundary language shall be included.
268.13 Community and Protected Knowledge Review. Where an intelligence output involves communities, Indigenous knowledge, local knowledge, territorial knowledge, cultural knowledge, environmental knowledge, health-sensitive community information, protected participation, community vulnerability, sacred sites, livelihoods, community risk, or public-safe maps, the output shall include safeguards review. The review shall protect custodial authority, consent or authorization, context, attribution, non-extraction, confidentiality, withdrawal rights, correction rights, public-safe generalization, and harm prevention.
268.14 Correction Path. Each intelligence output shall include a correction path identifying how errors, challenges, stale sources, missing sources, superseded sources, disputed evidence, hallucinations, model errors, retrieval failures, public authority clarifications, community corrections, protected knowledge concerns, cyber incidents, infrastructure sensitivity changes, finance overclaims, certification overclaims, procurement implications, provider preference, sponsor influence, or public-safe failures will be reviewed and corrected. Outputs without correction path shall not be used for material reliance.
268.15 Public-Safe Intelligence Output Approval. Public-safe intelligence outputs shall be approved by competent authority before external release. Approval shall confirm source support, method support, confidence disclosure, limitation language, classification, public authority boundary review, safeguards review, data / AI / cyber review, finance / certification / procurement / recognition / public warning boundary review, redaction or aggregation where required, accessibility, public-safe language, publication record, and correction path. Approval shall not transform the output into public warning, public authority decision, certification, recognition, finance-readiness, procurement approval, or provider endorsement.
268.16 Controlled Intelligence Output Approval. Controlled intelligence outputs shall be approved for their intended audience, access class, room, data room, public authority room, capital-reader room, Board material, committee material, council material, Nexus interface, research record, or internal use. Approval shall identify recipients, use restrictions, confidentiality, no-download status where applicable, AI-use restrictions, redistribution limits, limitation language, boundary language, correction path, and closeout obligations.
268.17 Verifiable Intelligence Records. GCRI Canada shall maintain verifiable intelligence records, including output identifiers, source records, method records, model or process records, compute workload records, inference records, confidence records, limitation records, human review records, classification records, public-safe status records, public authority boundary reviews, finance / certification / procurement / recognition / public warning boundary reviews, community and protected knowledge reviews, correction paths, approval records, notices, dependency reviews, corrections, supersessions, withdrawals, retractions, and archives.
268.18 Intelligence Output Retention and Archival. Intelligence outputs and supporting records shall be retained, sealed, deleted, restricted, or archived according to law, public authority terms, privacy obligations, protected knowledge obligations, cyber requirements, infrastructure sensitivity, finance sensitivity, research integrity, public-safe publication needs, correctionability, auditability, and institutional memory. Archived intelligence outputs shall identify operative status, supersession status, withdrawal status, retraction status, reliance limitations, access restrictions, and correction history.
Last updated
Was this helpful?