Dagmont

AMR Commissioning and Acceptance Checklist

Use this checklist to keep AMR commissioning and customer acceptance from collapsing into a single informal “it looks good” moment. Each gate asks for a named owner, required evidence, and a clear pass/fail or conditional outcome. Adapt thresholds to your contract; do not skip the evidence fields.

Published September 6, 2026

Stakeholders and decision gates

Identify the manufacturer field lead, integrator owner, customer operations owner, IT/OT integration owner, and the person authorized to accept or reject. Define gates: site ready, commissioning complete, pilot performance met, integration verified, endurance/multi-shift met, corrective actions closed, customer acceptance decision. A gate without an owner is a future stall.

Commissioning evidence gate

Before calling commissioning complete, confirm: safety validation artifacts required by the site; localization and map coverage for in-scope zones; charger dock success criteria; basic mission completion on agreed routes; known exclusion zones documented; software/firmware/config baseline recorded by serial number. Fleet dashboards can support this gate but should not replace the baseline record.

Acceptance performance and integration gate

For acceptance, require evidence against contracted metrics: cycle time or throughput; recovery after blockage; human intervention rate; charger availability under plan; WMS/MES/ERP transaction success under representative load; exception handling for common faults. Record environment notes (peak inbound, shift, layout changes). If a metric is deferred, capture it as an open condition with owner and due date—not as silent scope loss.

Failure, cause, change, and retest gate

Every open acceptance blocker needs: failed requirement statement; primary evidence; confirmed cause (or explicit unconfirmed status); corrective action with authorization; updated configuration/map/firmware baseline; retest results against the original condition. Do not close on symptom disappearance alone.

Customer acceptance decision

Produce a short decision package: accepted items, conditional items, rejected items, residual risks, and linked evidence. Capture the decision, date, and authorized names. After acceptance, any material configuration, map, or firmware change should trigger a revalidation review against the accepted baseline.

Checklist

  • Name acceptance authority and deployment case owner before pilot start
  • Record serial-level software, firmware, map, and config baselines
  • Attach primary evidence to each failed acceptance condition
  • Confirm cause before authorizing material changes
  • Retest original failure conditions after each corrective action
  • Write acceptance / conditional / rejected outcomes explicitly
  • Queue revalidation when post-acceptance baselines change