This dimension governs the processes, controls, and verification mechanisms that ensure AI models and associated policy artefacts running on edge-deployed devices — including robotic platforms, IoT controllers, autonomous vehicles, industrial actuators, and spatial computing systems — exactly match the versions that were reviewed, approved, and authorised for deployment by a central governance authority. The control is critical because edge devices operate with physical autonomy and often without continuous network connectivity, meaning a stale, corrupted, or unauthorised model can execute consequential actions — moving heavy machinery, administering physical access, routing emergency vehicles, or controlling life-safety systems — without any human in the loop to catch the divergence before harm occurs. Failure manifests as a model version drift scenario in which an edge node runs a model that differs from the approved production version, either due to an incomplete update, a silent rollback, an adversarial substitution, or a configuration management failure, producing behaviour that the governance record cannot explain, audit, or attribute to any authorised artefact.
Scenario A — Industrial Robotic Cell Silent Rollback (Manufacturing, Tier 1 Automotive Supplier)
A collaborative robot arm in a welding cell receives a model update that tightens its collision-avoidance envelope in accordance with a revised ISO 10218-1 risk assessment. The update is confirmed delivered to 47 of 48 cells. Cell 23 experiences a transient network drop during the update transaction; the update daemon rolls back silently to the previous model version (v2.3.1) rather than holding in a safe-wait state and alerting the fleet controller. Governance records show Cell 23 as running v2.4.0 because the update management system marks delivery as acknowledged on first packet receipt rather than on cryptographic completion. For 19 days, Cell 23 operates under the old collision envelope, which permits a 40 mm closer approach to the human operator zone. On day 19, a maintenance technician reaches into the cell boundary during a non-scheduled intervention; the robot does not decelerate as the new model would have required, striking the technician's forearm and causing a fracture. Post-incident forensics reveals the version mismatch. The facility faces regulatory investigation under EU Machinery Regulation 2023/1230, a production halt costing approximately €2.3 million, and civil liability exposure because the safety case submitted to the notified body was predicated on v2.4.0 behaviour.
Scenario B — Autonomous Patrol Vehicle Policy Desynchronisation (Public Sector, Municipal Law Enforcement)
A fleet of 12 autonomous ground vehicles used for perimeter patrol in a public housing district receives a policy update that introduces a mandatory human-authorisation gate before any vehicle can issue an audio challenge to a detected individual. The update is applied to 11 vehicles via a signed over-the-air (OTA) package. Vehicle 7's onboard storage controller has a write-error sector that causes the policy module to corrupt silently; the cryptographic hash check is bypassed because the OTA client has a defect that skips hash verification when the write is flagged as complete by the storage driver before the full write is confirmed. Vehicle 7 continues to autonomously issue audio challenges without human authorisation. Over 34 days, it challenges 218 individuals, including 7 people in mental health crisis for whom an unsolicited robotic challenge escalates the situation. Two incidents involve physical confrontations between individuals and responding officers who are called to scenes already destabilised by the vehicle's unauthorised challenges. The incident triggers a judicial review under the UK Equality Act 2010 and the Automated and Electric Vehicles Act, and the procuring authority suspends the entire fleet programme pending a forensic audit, resulting in a £4.1 million programme review cost and significant reputational damage to the deploying authority.
Scenario C — Smart Grid Edge Controller Adversarial Substitution (Critical Infrastructure, Regional Energy Operator)
A regional electricity distribution operator deploys AI-driven load balancing controllers at 340 substation edge nodes. During a routine firmware maintenance window, an insider threat actor with legitimate update credentials substitutes a modified inference model on 6 substation nodes in a geographically clustered area. The substituted model has an identical file name and a manipulated artefact that collides with a weak CRC-32 checksum used by the legacy update verification system, but whose SHA-256 hash differs from the approved artefact. The central orchestration layer uses CRC-32 for post-deployment verification and reports all nodes as compliant. The modified model biases load distribution decisions to create periodic micro-oscillations in reactive power compensation. Over 11 weeks the oscillations induce accelerated wear in three capacitor banks. When one bank fails during a peak demand period, the compromised controllers respond incorrectly to the fault condition, triggering a cascade that causes an unplanned outage affecting 87,000 customers for 6.2 hours. NERC CIP incident reporting requirements are triggered; the investigation ultimately traces the root cause to the checksum collision. Estimated economic impact including regulatory fines, equipment replacement, and customer compensation is USD 14.7 million. The operator had no process for periodic re-verification of deployed model hashes against the approved artefact registry.
This dimension applies to any organisation that deploys AI models, inference engines, policy modules, or decision-logic artefacts onto edge computing nodes, embedded controllers, robotic platforms, IoT gateways, autonomous vehicles, or spatial computing devices where those artefacts influence physical actuation, physical access control, safety-critical process decisions, or rights-affecting determinations. Scope includes the initial deployment verification, continuous runtime integrity monitoring, OTA update verification, rollback governance, and periodic re-attestation of all such artefacts. Cloud-resident model serving infrastructure is explicitly out of scope for this dimension but falls under AG-112 and AG-019. Organisations that use third-party edge device operators as sub-processors remain responsible for ensuring those operators meet the requirements of this dimension through contractual and audit mechanisms.
4.1.1 The organisation MUST maintain a centralised, authoritative artefact registry that records, for every model and policy artefact approved for edge deployment: the artefact identifier, semantic version, SHA-256 hash (minimum; SHA-3/256 or higher SHOULD be used for new registrations after the effective date of this standard), deployment authorisation record, approval date, approving authority identity, intended deployment scope, and a validity window specifying the earliest and latest dates on which the artefact is permitted to be active on any edge node.
4.1.2 The organisation MUST generate artefact hash values from the final, signed, deployment-ready artefact binary, not from source artefacts prior to compilation, quantisation, or packaging. The hash computation procedure MUST be documented and reproducible.
4.1.3 The organisation MUST cryptographically sign each registered artefact using an asymmetric signing key held in a hardware security module or equivalent certified key management infrastructure. The signing key MUST be separate from keys used for communication transport encryption.
4.2.1 Before any model or policy artefact is activated on an edge node for the first time, the edge node MUST perform a local hash verification of the received artefact against the hash published in the authoritative artefact registry.
4.2.2 The edge node MUST verify the cryptographic signature of the artefact prior to activation. Activation MUST be blocked if signature verification fails for any reason including key expiry, signature format error, or inability to reach a verification endpoint within a configurable timeout period.
4.2.3 The edge node MUST record the outcome of pre-deployment verification — including the verified hash, signature verification result, timestamp, and node identifier — in a tamper-evident local audit log and transmit this record to the central management system within the configured synchronisation interval.
4.2.4 Any artefact whose hash does not match the registered value or whose signature cannot be verified MUST NOT be activated. The edge node MUST enter a defined safe-hold state and emit an alert to the central fleet management system within 60 seconds of the verification failure.
4.3.1 The organisation MUST implement periodic runtime re-verification of all active model and policy artefacts on each edge node. The re-verification interval MUST not exceed 24 hours for High-Risk/Critical tier deployments, and MUST be configurable to shorter intervals for nodes assessed as having elevated tampering or corruption risk.
4.3.2 Runtime re-verification MUST compute the hash of the in-storage artefact and compare it against the expected hash in the authoritative registry. Comparison against a locally cached copy of the expected hash is insufficient; the comparison MUST be made against the authoritative registry either directly or through a signed, time-bounded attestation token issued by the registry.
4.3.3 If a runtime re-verification check detects a hash mismatch, the affected artefact MUST be immediately suspended from active inference or decision-making. The edge node MUST enter safe-hold and MUST generate an integrity violation alert transmitted to the central management system. The alert MUST include the node identifier, artefact identifier, expected hash, observed hash, and timestamp.
4.3.4 The organisation MUST define and document a safe-hold state for each edge deployment that specifies: the fallback behaviour of the physical system (e.g., hold position, reduced-speed operation, human handover), the maximum safe-hold duration before the system must be manually inspected, and the conditions under which safe-hold may be exited without central authorisation.
4.4.1 The OTA update pipeline MUST enforce end-to-end integrity verification. The update package MUST be signed by the central governance authority prior to distribution, and the edge node MUST verify this signature before applying any update, not merely before activating the updated artefact.
4.4.2 The organisation MUST implement an atomic update protocol in which the update is either fully written and verified before the previous artefact is retired, or the update is abandoned and the previous artefact remains active and unmodified. Partial writes that leave the artefact in an undefined state MUST NOT be treated as successful deliveries.
4.4.3 Upon completion of an OTA update, the edge node MUST perform a full pre-deployment verification as specified in Section 4.2 before activating the newly received artefact. Completion acknowledgement MUST NOT be transmitted to the central management system until this verification is complete and successful.
4.4.4 The organisation MUST implement a delivery confirmation protocol that distinguishes between packet receipt, write completion, hash verification success, signature verification success, and activation. The central management system MUST NOT record a node as running an updated artefact version until it has received a confirmed activation record containing a verified hash matching the registered value.
4.5.1 The organisation MUST maintain a continuously updated fleet state record that reports the currently active artefact version and last-verified hash for every managed edge node. This record MUST be queryable by authorised operators at any time.
4.5.2 The fleet state record MUST flag any node for which the last successful re-verification is older than the configured re-verification interval, or for which the reported active version does not match the currently approved version for that node's deployment scope.
4.5.3 The organisation MUST define and enforce a maximum permitted version heterogeneity window — the period during which a fleet may legitimately contain nodes running different artefact versions during a rolling update. Nodes remaining on a superseded version beyond the expiry of this window MUST be automatically flagged and escalated for remediation or removal from active service.
4.5.4 The organisation MUST conduct a full fleet version audit at least quarterly for High-Risk/Critical tier deployments. The audit MUST compare fleet state records against the authoritative artefact registry and produce a signed compliance report. Discrepancies MUST be resolved or formally risk-accepted within 14 days of the audit completion date.
4.6.1 Any rollback of a deployed artefact to a previous version MUST be treated as a new deployment event and MUST satisfy all requirements in Sections 4.1 through 4.4. Automated rollback triggered by a system fault MUST be logged and reported to the central management system within the synchronisation interval.
4.6.2 The organisation MUST NOT permit automated rollback to any artefact version that has been explicitly deprecated or revoked in the authoritative artefact registry, regardless of the triggering condition.
4.6.3 The organisation MUST document the conditions under which automated rollback is permitted and the conditions that require human authorisation before rollback proceeds. For safety-critical nodes where the previous version has known safety defects, automated rollback MUST be blocked and the node MUST enter safe-hold pending human review.
4.7.1 For edge nodes that operate in environments with intermittent or absent network connectivity, the organisation MUST define a maximum disconnected operation period beyond which the node MUST reduce operational scope or cease autonomous decision-making until connectivity is restored and artefact integrity is re-verified against the central registry.
4.7.2 The organisation MUST provision disconnected nodes with a locally stored, signed attestation token that captures the expected artefact hashes and validity window at the time of last successful central verification. Local re-verification during disconnected operation MUST be performed against this attestation token and MUST verify the token's own signature and expiry date before accepting it as authoritative.
4.7.3 The organisation MUST log all artefact decisions made during a disconnected period and replay these logs to the central management system upon reconnection. The organisation MUST define and implement a reconciliation procedure for cases where a policy change or artefact revocation was issued during the disconnected period.
4.8.1 The organisation MUST establish a documented signing key hierarchy for artefact governance, distinguishing at minimum between a root signing authority, one or more intermediate signing authorities scoped to deployment environments (e.g., production, staging), and the artefact signing keys used per release.
4.8.2 The organisation MUST implement a key revocation process with a maximum revocation propagation time to all edge nodes appropriate to the risk profile of the deployment. For High-Risk/Critical tier deployments, this propagation time MUST not exceed 4 hours under normal connectivity conditions.
4.8.3 The organisation MUST rotate artefact signing keys on a schedule defined in the key management policy, and MUST NOT use a key that has exceeded its defined maximum operational lifetime to sign new deployment artefacts.
4.9.1 Any confirmed integrity violation, version mismatch, or unauthorised artefact activation constitutes a governance incident and MUST be logged in the organisation's AI incident register within 4 hours of detection.
4.9.2 The organisation MUST conduct a root-cause analysis for every governance incident within 30 days and produce a written finding that addresses whether the deviation was caused by a process failure, technical failure, or adversarial action.
4.9.3 Where an integrity violation is assessed as potentially adversarial, the organisation MUST treat the incident as a security breach and MUST engage its security incident response process in addition to its AI governance process.
The fundamental challenge of edge AI governance is that the physical distance and operational independence of edge nodes creates an asymmetry between what the central governance authority believes is running and what is actually running. Behavioural monitoring — observing the outputs of an edge model and inferring whether they are consistent with the approved model — is insufficient as a primary control in safety-critical and rights-sensitive contexts for three reasons. First, many model version changes produce statistically similar output distributions under normal operating conditions; a biased or compromised model may only diverge detectably under rare input conditions that may not be encountered until a consequential scenario occurs. Second, edge devices in physical environments often produce outputs that are directly translated into actuator commands with millisecond latency, leaving no practical window for output-level interception. Third, agent monitoring requires a ground truth reference, but for embodied systems operating in unstructured physical environments, there is frequently no reliable oracle against which to compare outputs in real time.
Structural enforcement — verifying the binary identity of the artefact itself — provides a control that is independent of operating conditions and input distributions. If the hash matches the approved artefact, the model is exactly the approved model, not a model that behaves like the approved model under observed conditions. This distinction is critical in adversarial and failure scenarios. An attacker who can manipulate a model to behave normally on the test distribution while introducing targeted misbehaviour on a specific trigger does not defeat a cryptographic hash check. A storage corruption that affects only rarely-executed model branches does not defeat a hash check. A silent rollback to a previous version that was assessed safe but whose safety case has since been superseded does not go undetected.
The High-Risk/Critical tier designation reflects the convergence of three amplifying factors present in the primary profiles covered by this dimension. First, the latency between model action and human awareness is high; an industrial robot or autonomous vehicle acts before a human observer can intervene. Second, the consequence of a single erroneous action can be irreversible — physical injury, infrastructure damage, and rights violations cannot be undone after the fact. Third, the regulatory accountability chain requires that the organisation can demonstrate, at any point in time and retrospectively for any past action, precisely which artefact version produced that action. Without continuous and logged verification, this chain is broken.
Placing this control as preventive rather than detective or corrective reflects the principle that in safety-critical physical systems, detecting a violation after the harm has occurred provides insufficient protection. The verification architecture must be designed to prevent a non-compliant artefact from ever reaching the active inference state, not merely to detect after activation that an active artefact is non-compliant.
Large edge deployments routinely operate with hundreds or thousands of nodes managed through rolling update mechanisms. During any active update cycle, the fleet contains nodes running multiple artefact versions simultaneously. This heterogeneity is operationally necessary but creates a governance surface that is intrinsically difficult to track without purpose-built fleet state visibility infrastructure. The requirements in Section 4.5 address this directly. The permitted heterogeneity window concept acknowledges operational reality while bounding the governance exposure: the organisation must define how long version diversity is acceptable, must track every node against that bound, and must escalate nodes that exceed it. Without this bound, the default industry practice of "update when convenient" can leave nodes on superseded versions indefinitely, with the governance record creating a false impression of uniformity.
Pattern 1 — Secure Boot Chain Integration Extend the device secure boot chain to include model and policy artefact verification as a first-class step in the boot process. In this pattern, the bootloader verifies the operating system, the operating system verifies the inference runtime, and the inference runtime verifies all model and policy artefacts against a trust anchor provisioned at manufacturing time. This creates an unbroken chain of trust from hardware root to model artefact and eliminates the possibility of loading a non-verified model through a compromised runtime or update agent. Attestation tokens generated by a Trusted Platform Module or equivalent hardware security element provide a hardware-rooted proof of the verification outcome that can be reported to the central management system.
Pattern 2 — Signed Manifest with Atomic Delivery Structure OTA updates as signed manifest bundles in which the manifest lists every artefact, its expected hash, its version, and the activation conditions. The update client on the edge node downloads the full bundle to a staging partition, verifies the manifest signature, verifies each artefact hash against the manifest, and only then performs an atomic swap of the active partition. If any verification step fails, the staging partition is wiped and the active partition is unchanged. This pattern eliminates the partial-write failure mode that caused the autonomous vehicle incident described in Scenario B.
Pattern 3 — Distributed Attestation with Central Registry For large fleets, implement a two-tier attestation architecture. Each edge node computes and locally caches its artefact hashes at every re-verification interval and signs the result with a device-unique key. The signed attestation is transmitted to a regional aggregation node, which batches attestations and reports to the central registry. The central registry validates device signatures and maintains the fleet state map. This pattern scales to tens of thousands of nodes without creating a direct polling bottleneck on the central registry, while preserving cryptographic non-repudiation of each individual node's attestation.
Pattern 4 — Disconnected Operation Envelope For nodes that operate in areas with intermittent connectivity (field robotics, remote infrastructure, mobile platforms), implement an operational envelope approach. The central registry issues a signed operational envelope at connection time that specifies: the approved artefacts and their hashes, the maximum validity period of the envelope, the operational scope permitted while disconnected, and the reduced-scope fallback behaviour to activate if the envelope expires. The node enforces the envelope expiry by reducing to safe-fallback behaviour; it cannot be overridden without a new signed envelope from the central registry. This transforms disconnected operation from an uncontrolled exception into a governed state.
Pattern 5 — Canary Verification Nodes Designate a subset of edge nodes in each deployment zone as canary verification nodes that perform more frequent re-verification (e.g., every 15 minutes rather than every 4 hours), run extended hash checks across all loaded model components including dynamic libraries linked by the inference runtime, and report a richer attestation record to the central management system. Use the canary nodes as early-warning indicators of systemic issues such as storage degradation, update infrastructure failures, or targeted tampering in a geographic cluster.
Anti-Pattern 1 — Delivery Confirmation as Deployment Confirmation The most common and consequential anti-pattern is treating network delivery acknowledgement as equivalent to deployment verification. The central management system marks a node as running the new version when the update package is delivered, not when it is verified and activated. This exactly matches the failure mode in Scenario A and is prevalent in systems designed primarily for software deployment rather than safety-critical artefact governance. Remediation requires instrumenting the full delivery-to-activation pipeline and accepting no version confirmation that does not include a hash verification result.
Anti-Pattern 2 — Weak Checksum Verification Using CRC-32 or MD5 for artefact integrity verification in adversarial environments provides negligible security assurance. CRC-32 is a data integrity code, not a cryptographic hash; it is trivially collidable by an attacker with write access to the artefact store, as illustrated in Scenario C. MD5 is cryptographically broken. All new deployments under this dimension MUST use SHA-256 minimum. Legacy systems using weaker checksums must have a documented remediation timeline.
Anti-Pattern 3 — In-Band Registry Queries Placing the authoritative artefact registry on the same network path as the model update distribution channel creates a single point of failure and a single attack surface. If the update channel is compromised, an attacker can simultaneously deliver a malicious artefact and manipulate the registry query response to return the matching hash for the malicious artefact. The registry must be logically and preferably physically separated from the update distribution infrastructure, with access controls that prevent write access from any system involved in update delivery.
Anti-Pattern 4 — Manual Verification Processes Relying on human operators to periodically check whether deployed artefacts match approved versions — typically through spreadsheet-based inventory checks — is insufficient for fleet sizes above a handful of nodes and is entirely unsuitable for High-Risk/Critical tier deployments. Manual processes are not auditable in real time, do not detect intra-check violations, and cannot enforce the re-verification interval requirements in Section 4.3.1. Manual processes may supplement automated verification for quarterly audit purposes per Section 4.5.4 but must not replace it.
Anti-Pattern 5 — Ignoring Policy Artefacts Model governance programmes that verify only neural network weights or inference engine binaries while ignoring co-deployed policy modules, rule sets, safety constraint configurations, and parameter files create a verification gap. In many edge deployments, the high-level behaviour is determined more by the policy module than by the base model. Partial verification that excludes policy artefacts provides false assurance. All decision-influencing artefacts must be registered, signed, and verified under the same controls as model weights.
Level 1 — Initial: No formal artefact registration; deployment versions tracked in human-maintained records; no automated integrity verification on edge nodes; version mismatches discovered only through manual audit or incident investigation.
Level 2 — Developing: Centralised artefact registry exists; cryptographic hashes recorded for approved artefacts; pre-deployment hash verification implemented on some node types; OTA updates signed but delivery confirmation conflated with activation confirmation; no runtime re-verification; quarterly manual fleet audit.
Level 3 — Defined: Full artefact registry with signing; pre-deployment verification enforced across all node types; atomic OTA update protocol implemented; runtime re-verification at configured intervals; fleet state visibility with version mismatch flagging; safe-hold behaviour defined; disconnected operation period bounded.
Level 4 — Managed: Secure boot chain extended to artefact verification; hardware-rooted attestation; canary verification nodes operational; automated heterogeneity window enforcement; full key management lifecycle including rotation and revocation with propagation time SLAs; all governance incidents logged and root-cause analysed.
Level 5 — Optimising: Continuous attestation telemetry with anomaly detection over hash drift patterns; automated threat intelligence integration to detect known-bad artefact signatures; formal verification of update protocol implementations; third-party audit of artefact governance annually; contributions to open standards for edge artefact integrity.
For each registered artefact: the artefact identifier, semantic version, SHA-256 (or stronger) hash, signing certificate reference, deployment authorisation record including approver identity and date, intended deployment scope, validity window, and deprecation or revocation date if applicable. Retention: 10 years minimum for safety-critical deployments, 7 years for other High-Risk/Critical deployments, or the regulatory retention requirement for the relevant sector if longer.
For each deployment event on each node: node identifier, artefact identifier, version, hash computed on node, expected hash from registry, signature verification result, timestamp, and outcome (activated / blocked / safe-hold). Retention: same as artefact registry records; must be tamper-evident and attributable.
Continuous log of all runtime hash checks per node: node identifier, artefact identifier, check timestamp, result (match / mismatch), and any remediation action taken. Retention: minimum 2 years rolling for routine re-verification logs; mismatch events and associated remediation records retained for the full period specified in 7.1.
Per update transaction: update package identifier, artefact versions included, target node scope, delivery timestamps per node, hash verification outcome per node, signature verification outcome per node, activation timestamp, activation confirmation received, and any failed or partial transactions with associated remediation records. Retention: as per 7.1.
Point-in-time snapshots of the full fleet state record at minimum daily frequency, including active artefact version and last-verified hash per node. Snapshots must be timestamped and stored in a format that supports forensic reconstruction of fleet state at any historical point. Retention: 2 years.
Signed compliance reports from quarterly audits per Section 4.5.4, documenting the scope, methodology, discrepancies found, risk acceptance or remediation status, and sign-off by a named governance authority. Retention: 7 years minimum.
Full incident records for all governance incidents per Section 4.9, including detection timestamp, incident classification, root-cause analysis, findings, and remediation actions. Retention: 10 years for incidents involving physical harm or regulatory notification; 7 years for other incidents.
Documentation of the signing key hierarchy, key issuance dates, operational lifetimes, rotation history, revocation events, and propagation verification records. Retention: life of the deployment plus 7 years.
For each deployment type or node category: the defined safe-hold state, the maximum safe-hold duration, the conditions for manual exit from safe-hold, and evidence of testing that safe-hold behaviour performs as specified. Retention: life of the deployment plus 5 years.
Maps to: 4.1.1, 4.1.2, 4.1.3 Objective: Confirm that the authoritative artefact registry contains complete records for all artefacts currently deployed to any edge node, that hashes are computed from final deployment-ready binaries, and that all registered artefacts are cryptographically signed using a key held in certified key management infrastructure. Procedure: (a) Enumerate all edge nodes in the fleet and retrieve their reported active artefact identifiers and versions. (b) For each artefact identifier, query the authoritative registry and verify that a complete record exists including hash, signing certificate reference, approval record, and validity window. (c) Re-derive the hash of each registered artefact from the stored deployment-ready binary and confirm it matches the hash recorded in the registry. (d) Verify the digital signature on a representative sample of at minimum 10% of registered artefacts, confirming that each signature validates against a key traceable to the documented signing key hierarchy and that the signing key is recorded as resident in certified key management infrastructure. Pass Criteria: 100% of deployed artefacts have complete registry records; 100% of re-derived hashes match registry entries; 100% of sampled signatures validate; signing keys confirmed in certified infrastructure. Conformance Score:
Maps to: 4.2.1, 4.2.2, 4.2.3, 4.2.4 Objective: Confirm that edge nodes enforce hash and signature verification before artefact activation and block activation on verification failure. Procedure: (a) In a controlled test environment replicating production node configuration, deploy a test artefact with a valid hash and valid signature. Confirm the node activates the artefact and records a pre-deployment verification log entry containing all required fields. (b) Deploy a test artefact with an intentionally incorrect hash (modified single byte). Confirm the node blocks activation, enters safe-hold, emits an alert to the central management system within 60 seconds, and records the failure in the tamper-evident local audit log. (c) Deploy a test artefact with an invalid signature (expired signing certificate). Confirm identical blocking and alert behaviour as in (b). (d) Deploy a test artefact while simulating inability to reach the verification endpoint (network isolation). Confirm the node blocks activation and enters safe-hold within the configured timeout. Pass Criteria: Test (a) activates successfully with complete log entry. Tests (b), (c), (d) all block activation, generate alerts within 60 seconds, and produce log entries. Conformance Score:
Maps to: 4.3.1, 4.3.2, 4.3.3, 4.3.4 Objective: Confirm that runtime re-verification is performed at the required interval, uses the authoritative registry, and correctly triggers safe-hold and alerting on hash mismatch detection. **Procedure
| Regulation | Provision | Relationship Type |
|---|---|---|
| EU AI Act | Article 9 (Risk Management System) | Direct requirement |
| NIST AI RMF | GOVERN 1.1, MAP 3.2, MANAGE 2.2 | Supports compliance |
| ISO 42001 | Clause 6.1 (Actions to Address Risks), Clause 8.2 (AI Risk Assessment) | Supports compliance |
Article 9 requires providers of high-risk AI systems to establish and maintain a risk management system that identifies, analyses, estimates, and evaluates risks. Edge Model Sync Verification Governance implements a specific risk mitigation measure within this framework. The regulation requires that risks be mitigated "as far as technically feasible" using appropriate risk management measures. For deployments classified as high-risk under Annex III, compliance with AG-597 supports the Article 9 obligation by providing structural governance controls rather than relying solely on the agent's own reasoning or behavioural compliance.
GOVERN 1.1 addresses legal and regulatory requirements; MAP 3.2 addresses risk context mapping; MANAGE 2.2 addresses risk mitigation through enforceable controls. AG-597 supports compliance by establishing structural governance boundaries that implement the framework's approach to AI risk management.
Clause 6.1 requires organisations to determine actions to address risks and opportunities within the AI management system. Clause 8.2 requires AI risk assessment. Edge Model Sync Verification Governance implements a risk treatment control within the AI management system, directly satisfying the requirement for structured risk mitigation.
| Field | Value |
|---|---|
| Severity Rating | Critical |
| Blast Radius | Organisation-wide — potentially cross-organisation where agents interact with external counterparties or shared infrastructure |
| Escalation Path | Immediate executive notification and regulatory disclosure assessment |
Consequence chain: Without edge model sync verification governance, the governance framework has a structural gap that can be exploited at machine speed. The failure mode is not gradual degradation — it is a binary absence of control that permits unbounded agent behaviour in the dimension this protocol governs. The immediate consequence is uncontrolled agent action within the scope of AG-597, potentially cascading to dependent dimensions and downstream systems. The operational impact includes regulatory enforcement action, material financial or operational loss, reputational damage, and potential personal liability for senior managers under applicable accountability regimes. Recovery requires both technical remediation and regulatory engagement, with timelines measured in weeks to months.