Case Example: Handling a Robot Model Substitution Before Acceptance

A logistics facility operator had contracted for a fleet of twenty autonomous mobile robots from a supplier, specifying a current-generation model with defined navigation and payload specifications. After the order was placed, the supplier informed the operator that the specified model was unavailable due to production constraints and offered a successor model with different navigation hardware, an updated software platform, and slightly different physical dimensions.

The operator's operations team and the systems integrator reviewed the successor model's specifications and concluded that it could meet the deployment requirements, and the substitution was agreed. At this point, the deployment had a project plan and acceptance criteria designed for the original model; a configuration baseline had not yet been captured because delivery had not begun. The substitution was agreed before any hardware arrived at the facility, which meant that the entire commissioning record would be built for the successor model, but the deployment specification, acceptance criteria, and integration plans all referenced the original model.

The first documentation action after the model substitution was agreed was to update the deployment specification and acceptance criteria to reference the successor model. This review identified several areas where the acceptance criteria needed adjustment: the navigation accuracy specification referenced positioning tolerances that were specific to the original model's sensor characteristics and needed to be revised for the successor model's different sensor suite; the physical clearance requirements needed to be rechecked against the successor model's dimensions, which differed slightly from the original; and the integration configuration plan needed to be reviewed because the successor model's WMS integration API had been updated in the new software platform.

The integration update required consultation with the WMS vendor to confirm that the facility's WMS version was compatible with the successor model's integration API, which revealed that a WMS update was needed before integration testing could proceed. This discovery, made during the specification review before commissioning began, allowed the WMS update to be scheduled as a pre-commissioning activity rather than being discovered as a blocking problem during acceptance testing.

The provenance record for the deployment was built for the successor model from the start of commissioning, since no hardware for the original model had been received. The hardware identity records captured the successor model's manufacturer identity, the manufacturing facility documented in the supplier's technical certification, and the component origins for the compute platform, sensor systems, and communication hardware.

The software lineage captured the successor model's operating system, navigation stack, and application software versions at delivery. The network and telemetry records were built for the successor model's telemetry and update infrastructure, which differed from the original model's infrastructure in that the successor used a different cloud platform for fleet management. This difference was noted in the operator's data governance review as a change in the data destination record from the original deployment specification, and the new cloud platform's data handling practices were reviewed against the operator's data governance requirements before commissioning acceptance.

The review confirmed the new platform met the operator's requirements, and this confirmation was documented in the provenance record as a data governance compliance note.

Acceptance testing for the successor model was conducted against the updated acceptance criteria, which had been reviewed and approved by the operator before testing began. The most significant change in the testing scope was the navigation accuracy testing, which used the successor model's sensor characteristics as the basis for the measurement method and pass threshold. For the successor model's lidar-based localization, a different measurement protocol was used than would have been used for the original model's camera-based positioning system, and the deployment team documented the change in methodology and the rationale for the pass threshold used.

Integration testing discovered a format discrepancy between the successor model's WMS integration and the facility's WMS after the update: a task completion message field had changed format between the original model's integration API and the successor model's API. This was identified as a medium-priority integration issue, investigated to a root cause in the WMS update configuration, resolved through a WMS configuration change, and retested before integration acceptance was confirmed.

The complete resolution chain - discovery, root cause investigation, corrective action, and retest - was documented in the deployment case.

The model substitution changed several fields in the deployment's provenance record that required formal review before acceptance. The compute platform in the successor model was from a different manufacturer than the compute platform in the original model. The operator had a procurement policy that specified approved compute platform manufacturers for automation systems, and this change triggered a procurement compliance review.

The review confirmed that the successor model's compute platform manufacturer was on the approved list, and this confirmation was documented in the provenance compliance mapping section of the deployment case. The change in fleet management cloud platform also required a data governance review, as described above. Both reviews were completed before acceptance was scheduled, and the outcomes - compute platform approved, data governance requirements met - were linked in the provenance record to the relevant acceptance criteria they satisfied.

The acceptance package presented to the operator's acceptance authority included the updated acceptance criteria, the test results for all criteria under the successor model, the provenance record built for the successor model, and the documented outcomes of the procurement compliance and data governance reviews.

This case example highlights several practices that are broadly applicable to robot model substitution scenarios. The earliest possible documentation review - before commissioning begins, not during - identifies the full scope of specification, acceptance criteria, and provenance record updates required, preventing those updates from being discovered as blocking problems during testing. The provenance review of the substituted model as a first-order action, not an afterthought, identifies procurement policy implications that might otherwise be discovered at the acceptance review, when addressing them would delay handover.

The systematic treatment of the integration difference discovered during acceptance testing - root cause investigation, corrective action, documented retest - produces a resolution record that supports the acceptance decision rather than a closed ticket that says the issue was fixed. And the inclusion of procurement compliance and data governance review outcomes in the acceptance package, not as separate documents but as linked evidence in the deployment case, gives the operator's acceptance authority the complete picture they need to make an informed acceptance decision.

• Update the deployment specification and acceptance criteria to reference the substituted model before commissioning begins
• Review all acceptance criteria for adjustments required by the substituted model's technical differences
• Build the provenance record for the substituted model from scratch, capturing its specific hardware origins and software lineage
• Review the substituted model's provenance against all applicable procurement policies before acceptance
• Document any data governance implications of the model substitution and confirm compliance
• Conduct acceptance testing against the updated criteria and document results with full evidence
• Include procurement compliance and data governance review outcomes in the acceptance package