Robot Configuration Changes and Deployment Revalidation

Material changes include firmware or software version changes, navigation or manipulation parameter changes that affect behavior, map or localization updates that alter routes or keep-out zones, safety-related configuration, integration endpoint or payload contract changes, and procedural changes that alter operator interventions. Cosmetic UI settings usually are not material. When unsure, treat the change as material until impact is assessed against accepted requirements.

Acceptance is often granted on a pilot unit or a small initial set. Production units frequently ship with different builds or are updated asynchronously. Record baselines by robot serial (or durable asset ID), site, and deployment case.

“Fleet is on version X” is not a baseline if units differ. Drift between accepted configuration and field configuration is a common source of intermittent failures that look like new defects.

Before rolling a change, assess which accepted requirements could be affected: navigation recovery, cycle time, charger behavior, integration transactions, safety responses, or endurance. Define the minimum revalidation set. Not every change requires full recommissioning; targeted revalidation is appropriate when the impact envelope is clear and evidence from prior failures exists.

Broad revalidation is appropriate when impact is unknown or the change touches safety-related behavior—subject to the responsible organization’s processes.

If a requirement previously failed and was closed with evidence, revalidation should include that failure condition when the change touches the same subsystem. Retesting only the happy path after a parameter change is how regressions return during the second shift. Attach retest evidence to the same deployment record that holds the original acceptance.

When a material change lands under conditional acceptance or during warranty, notify the acceptance authority with: what changed, why, impact assessment, revalidation plan, and results. Do not bury configuration drift inside fleet OTA notes if acceptance depended on the prior baseline. Dagmont does not authorize operation or certify safety; it records the change and verification trail the organization uses to make those decisions.

• Store accepted config/firmware/map baselines by serial and site
• Classify each change as material or non-material with a named owner
• Assess impacted acceptance requirements before rollout
• Define targeted vs broad revalidation criteria in advance
• Retest prior failure conditions when the same subsystem changes
• Link change authorization, diff, and retest evidence in one record