An AI robot update needs a new evidence check

An old pass belongs to the version and conditions that were tested

An AI-enabled robot function can change when its model, software, data, configuration, sensors, task or operating context changes. A successful trial for the previous state is useful history, but it is not automatic evidence that the changed state will meet the same requirement.

RobotAtom therefore ties trial, acceptance and production observations to the exact version and conditions tested. A material change reopens the requirements and evidence it can affect; it does not erase every earlier result or inherit an unconditional pass.

Start with an exact change record

• Record the robot, controller, model, software, firmware, service and configuration before and after the update.
• State the release identifier, date, purpose, delivery method and functions the provider says have changed.
• Identify relevant training, calibration, reference or retrieval data versions where that information is available to the buyer.
• Capture changes to sensors, tools, tasks, objects, users, facilities and operating conditions that can alter the inputs or consequences.
• Link the change to the capability, risk, trial and acceptance records it may supersede, and mark unresolved inputs as unknown.

Reopen what the change can affect

NIST's voluntary AI Risk Management Framework says AI risk management is lifecycle work. Its Core calls for testing before deployment and regularly in operation, production monitoring, and post-deployment plans covering override, decommissioning, incident response, recovery and change management. NIST also says AI RMF 1.0 is being revised, so this article records the version reviewed rather than treating it as a fixed robotics rulebook.

Use the change record to decide which task outputs, hard constraints, safety-related behaviours, error consequences, latency limits, interfaces, data practices and fallback paths need review. The retest scope should be proportionate to what changed, its uncertainty and the consequence of error. NIST does not require the same test plan for every update, and its framework is not a robot acceptance or safety standard.

Make the release gate testable

• Name the provider and customer owners for technical review, operational approval and any required safety, security, legal or sector review.
• Set metrics, thresholds, uncertainty, representative data and deployment-like conditions before testing begins.
• Repeat affected acceptance cases and regression cases, including degraded inputs, rejected outputs, human override and local fallback.
• State the approval, rejection and conditional-release criteria, including any staged rollout or temporary operating restriction.
• Retain the rollback version and configuration, test the recovery path, and define who can pause, restrict, roll back or deactivate the function.
• Preserve the results, deviations, reviewer, date and exact version as the new evidence package.

Monitor the released version and refresh its evidence

ISO/IEC 42005:2025 publicly describes AI impact assessment as work across the AI system lifecycle and says assessments should be updated as needed. ISO/IEC 42001:2023 describes an organisational management system that is maintained and continually improved. Those public scopes support an owned update, monitoring and corrective-action process; they do not define a robotics test plan or prove that a named product is safe, effective or compliant.

For the released version, agree which performance changes, drift, interventions, overrides, incidents and user feedback will be reviewed, how often, and what threshold triggers a pause, rollback, refreshed trial or specialist assessment. Label older evidence as previous-version or superseded instead of silently attaching it to the new configuration.

Check that the update packet still lists the required evidence — added 14 October 2026

A review can stall even when the new software and rollback package are available: the evidence needed to judge the change may be absent, renamed or attached only to an earlier release. Start with a bounded list of the records your review plan requires. Compare it with the references actually listed in the proposed update packet before asking whether their contents justify release.

NIST’s AI RMF 1.0 Core describes documenting test sets, metrics and tools used in evaluation, and assessments in deployment-like conditions. Its post-deployment guidance includes change management. The Core excerpt, checked 14 October 2026, is undated and identifies the framework as the 2023 version under revision. These voluntary provisions support retaining review evidence; they do not mandate RobotAtom’s reference-list method.

NIST SP 800-218, SSDF v1.1, final 3 February 2022, separately addresses integrity-verification information for acquirers, release files and supporting information, and release-specific component provenance in PS.2.1, PS.3.1 and PS.3.2. Its software-security scope is important: keeping an artifact and its provenance does not demonstrate the functional safety or performance of a changed robot application.

Use exact references to distinguish the previous and proposed releases, the affected test results, unresolved deviations and the review or recovery records required by your plan. A folder name such as latest is a weak handover reference if its contents can change without the reviewer knowing. Have the accountable owner define the evidence set and controlled identifiers; a public worksheet cannot determine those requirements for the site.

For a hypothetical update, suppose the review plan calls for test record T-17 and recovery exercise R-04. If the proposed packet lists T-17 and R-05, R-04 is still absent from that list. R-05 might be a justified replacement, but the owner needs to record that relationship and assess its contents. Merely adding the new identifier cannot establish that the required recovery evidence has been retained or superseded appropriately.

The reference check in the existing recovery tool compares two typed lists. An empty required list withholds review. Missing references and additional entries are shown separately; duplicate lines and surrounding spaces are ignored, while case and other characters stay significant. A result saying all required references are listed means exactly that—no document has been opened, no hash verified and no evidence accepted.

Export the two lists and gaps for the review owner, then verify access, integrity, release applicability and evidence adequacy through the controlled process. Preserve the old record and document any renamed or superseding reference instead of silently rewriting the baseline. This step supports the earlier change-impact and rollback discussion; it does not replace retesting, specialist review or permission to deploy.

Treat a supplier release note as a claim, not renewed proof

A robot manufacturer's or AI provider's release note is authoritative for what that supplier says changed. It is still a supplier claim: it does not independently verify performance in the customer's task, environment or complete robot application. Ask the provider for version-specific evidence, then use agreed testing and production observations to establish the evidence state relevant to the buyer.

This article relies on NIST and ISO for their published lifecycle, monitoring, impact-assessment and management-system scopes; it uses no manufacturer performance claim as an independently verified fact. The practical release record is RobotAtom's synthesis, not a checklist mandated by those sources. RobotAtom records versions, evidence, unknowns and approvals. It does not certify AI, robot safety, performance or compliance.