Robot Acceptance Punch Lists: How to Close Open Issues Without Delaying the Entire Deployment

Robot Acceptance Punch Lists: How to Close Open Issues Without Delaying the Entire Deployment

A robot arrives on site. Installation is mostly done. The system runs — mostly. But there are open issues: a sensor that drifts 3 mm from its target position, a navigation path that occasionally triggers an unnecessary stop, a safety fence bracket that needs repositioning, a software alert that appears once or twice a day without an obvious cause. None of these are catastrophic. But together, they create a decision problem that catches many buyers off guard: when is the system ready to go live?

Two failure modes are common. In the first, the supplier declares the system "substantially complete" and asks the buyer to sign acceptance — leaving the buyer to discover later that several open issues were never formally tracked, assigned, or given a close-out date. In the second, the buyer refuses to sign until every single item is resolved — and a non-critical cosmetic issue blocks the entire deployment, costing weeks of delayed go-live and the operational value the robot was supposed to deliver.

The real problem is not whether to use a punch list. It is how to classify open issues by priority, define which ones must close before go-live and which can defer to a hypercare period, and agree on those criteria before the robot arrives on site — not during a heated walk-through on installation day.

This article explains how to build a robot acceptance punch list that does both: protects the buyer's operational and safety requirements, and avoids letting minor issues stall an entire deployment.

What a Robot Acceptance Punch List Is — and What It Is Not

A punch list is a structured record of open issues identified during site acceptance testing. Each item is individually numbered, described, assigned a priority, given an owner, and tracked to closure. The punch list is not a defect log for warranty claims (that is a separate process, covered in the warranty comparison framework). It is not a change order request (scope changes follow a separate change control process). And it is not the operations handover checklist — although any items still open at handover should appear on the handover certificate's reservation list.

In a robot deployment, the punch list typically emerges during Site Acceptance Testing (SAT) — the phase where the robot is installed, configured, and tested in its operational environment. IEC 62381, an international standard for automation systems acceptance testing, defines a three-stage framework: Factory Acceptance Test (FAT) at the supplier's facility, Site Acceptance Test (SAT) after installation, and Site Integration Test (SIT) for system-level integration. This framework was developed for process industry automation systems; its applicability to a specific robot deployment should be confirmed against the standard's scope and the project's contractual acceptance plan. But the staged logic — verify at the factory, verify at the site, verify the integration — provides a useful reference framework.

The punch list sits between SAT completion and formal acceptance sign-off. It captures everything that was supposed to work but does not yet, or works but not to the agreed specification. The buyer's goal is to close this list — or at least close the items that matter for go-live — before signing the acceptance certificate.

Three-Priority Classification: Must-Fix, Defer, Discuss

Industrial commissioning practice has long used a three-tier priority system for punch list items. A widely referenced commissioning handbook recommends: (1) Complete before handover or start-up, (2) Complete after handover or start-up, and (3) Item for further discussion and clarification. The source notes that more complex prioritization systems can be used, but this three-tier classification has been used effectively across many commissioning campaigns.

Adapted for robot deployments, the three priorities become:

Priority 1: Must-Fix Before Go-Live

These are issues that directly affect safety, core functionality, or regulatory compliance. The robot cannot operate as intended — or cannot operate safely — until these are resolved. Examples include:

• Emergency stop function not responding within the specified response time
• Safety-rated speed monitoring not configured or not tested
• Collision avoidance triggering false stops on the primary navigation path
• Robot unable to complete the core task cycle within the specified cycle time
• Software error that causes unplanned stops more than a defined frequency threshold
• Safety perimeter or light curtain misaligned or non-functional

If applicable to the robot type, product configuration, intended use, and destination market, safety-related items may also need to align with relevant safety standards (such as ISO 10218 for industrial robots) — though whether a specific standard applies depends on the robot type, application, and market, and should be confirmed by qualified specialists.

Priority 2: Can Defer to Hypercare Period

These are issues that do not prevent safe operation or core task completion but should be resolved within a defined period after go-live. The robot can run, but with a known limitation, a minor performance gap, or a cosmetic defect. Examples include:

• Navigation path optimization not yet tuned for maximum efficiency (robot completes tasks but takes a slightly longer route)
• Sensor calibration within tolerance but not at optimal precision
• Occasional non-safety-related software alert that does not stop operations
• Labeling, signage, or cosmetic finish issues
• Minor noise levels above preference but within specification
• Non-critical telemetry or reporting feature not yet configured

Deferring these items requires two conditions: a documented target close-out date, and a confirmed assessment that the deferred item does not create a safety risk or prevent core task execution. The buyer should retain authority over the defer decision, based on criteria agreed before installation.

Priority 3: Item for Discussion

These are items where the root cause, responsibility, or required fix is not yet clear. They may turn out to be supplier fixes, buyer-side configuration issues, or scope changes that require a change order. Examples include:

• Robot behavior that may be caused by environmental factors (floor surface, lighting, RF interference) rather than a product defect
• Performance gap where the root cause could be the robot, the integration, or the application design
• A feature that was discussed during sales but not explicitly defined in the SOW or acceptance criteria
• An interface issue where it is unclear whether the robot, the WMS, or the network configuration is at fault

Priority 3 items are not intended to block go-live. But they should be logged, assigned an owner for investigation, and given a resolution deadline. If a Priority 3 item turns out to require a scope change, it should transition to the change order process rather than remaining on the punch list without a resolution path.

What Counts as "Trifling": Defining Defer Conditions Before Go-Live

The concept of "substantial completion" — borrowed from construction and engineering contract law — provides a useful reference point for the go-live decision. In construction contracts, the concept of substantial completion — where the work is sufficiently complete for the owner to take possession and use it for its intended purpose — appears in standard form agreements such as AIA A201 General Conditions and FIDIC contract conditions. The specific principle that trifling (minor) defects do not prevent substantial completion has been addressed in court decisions, discussed below.

A Court of Appeal decision in Mears Ltd v Costplan Services [2019] EWCA Civ 502 confirmed several principles relevant to this question (referenced via secondary sources; the case was decided under English construction law, and its applicability to robot procurement contracts should be confirmed by qualified legal counsel):

• Whether a defect is "trifling" is a matter of fact and degree, measured against whether the owner can use the facility for its intended purpose.
• Latent defects do not necessarily prevent substantial completion.
• The fact that a defect cannot be remedied does not itself determine the substantial completion question — it may affect the measure of damages instead.

What this means for robot deployments: The go-live decision can follow a similar logic — the robot does not need to be perfect to go live. It needs to be safe, able to perform its core tasks, and free of defects that would prevent intended use. Minor issues that do not affect safety, core functionality, or intended use can defer to a hypercare or defect-resolution period.

But the critical lesson is this: the standard for what counts as "trifling" — what can defer and what cannot — should be defined by the buyer during the procurement phase, written into the SOW or acceptance criteria, and agreed with the supplier before installation begins. If the buyer arrives on site without a defined defer standard, the supplier's interpretation will fill the vacuum, and the buyer may find itself signing acceptance with open issues it never agreed to defer — or refusing to sign over issues that were always going to be minor.

The defer conditions should specify, at minimum:

• Which categories of issues can defer (e.g., cosmetic, non-safety performance optimization, non-critical software alerts)
• Which categories cannot defer under any circumstances (e.g., safety functions, emergency stop, collision avoidance on primary paths)
• The maximum time an item can remain deferred before it escalates (e.g., 30 days, 60 days — the specific period should be defined by the project team)
• Who has authority to classify an item as deferrable (buyer's project lead, not supplier's installation team)
• What happens if a deferred item turns out to be more significant than initially assessed (reclassification process)

Punch List Item Structure: What Each Entry Must Contain

Commissioning practice specifies that every punch list item should include five elements. Adapted for robot deployments:

Beyond these five fields, robot deployments benefit from two additional fields:

• Verification Method: How will closure be confirmed? (e.g., 50 consecutive successful docking cycles, emergency stop response time measurement, software log review for 48-hour error-free period)
• Dependency: Does this item depend on another item, a third party, or a site condition? (e.g., "Cannot verify until network VLAN configuration is completed by buyer's IT team")

The verification method is particularly important for software and sensor-related items. "Fixed" is not a closure criterion. The closure criterion is: the issue no longer occurs under defined test conditions, verified by a defined method, over a defined period.

Robot-Specific Punch List Item Types

Robot deployments generate open issues that construction punch lists do not typically encounter:

• Software bugs: Non-deterministic errors that appear intermittently, making verification harder. Closure requires reproducing the test scenario multiple times without recurrence, not a single successful run.
• Sensor calibration drift: A sensor within specification but drifting toward the edge of tolerance. Closure may require recalibration and a stability observation period.
• Navigation path optimization: The robot completes tasks but not at optimal efficiency. This is often a P2 item — but if the inefficiency causes throughput to fall below the contractual minimum, it may escalate to P1.
• Safety function verification: Emergency stop, speed monitoring, collision avoidance, and safety perimeter functions. These are typically P1 items and require testing under defined load, speed, and obstacle conditions — not just a functional check.
• Integration interface issues: Robot-to-WMS, robot-to-elevator, robot-to-door, or robot-to-MES communication failures. These may be P1 or P3 depending on whether the root cause is the robot, the external system, or the interface configuration.

Two-Phase Process: Preliminary and Final Punch List

Commissioning practice recommends a two-phase punch list process. Adapted for robot deployments:

Preliminary Punch List

Conducted when installation and configuration are approximately 80% complete. The goal is to identify as many open issues as possible before the final walk-through. For robot deployments, this means:

• The robot is installed, powered, and can execute basic movements and tasks.
• Core safety functions are configured but may not yet be fully tested under all conditions.
• Navigation mapping is loaded but may not be fully optimized.
• Integration interfaces are connected but may not yet be fully tested end-to-end.

The preliminary punch list should involve at least two people — one performing the checks, one recording. For robot deployments, the buyer's project lead, the supplier's field engineer, and where applicable the system integrator's representative should all be present. Each discipline (safety, software, integration, mechanical) should be walked through.

Final Punch List

Conducted when installation is 100% complete and all preliminary punch list items have been resolved — or their resolution status is documented. The final punch list is the definitive list of open issues at the point of acceptance.

Any items still open at handover should be transferred to the handover certificate's reservation list (or equivalent section in the acceptance document). These items must be assigned a close-out date and an owner before the acceptance certificate is signed. The reservation list is not a "wish list" — it is a tracked, time-bound commitment.

The two-phase approach can help prevent a common problem: discovering issues during the final walk-through that should have been identified and resolved weeks earlier, when there was still time to fix them without delaying go-live.

Close-Out Sign-Off: Who Signs, What They Are Signing

The acceptance sign-off is the point at which the buyer formally confirms that the robot system meets the agreed acceptance criteria — with documented exceptions on the reservation list. This is analogous to the Taking-Over Certificate mechanism in FIDIC contract conditions, where the certificate triggers a transfer of responsibility for the work and the start of the defects notification period (referenced via secondary sources; FIDIC is an engineering contract framework, and the specific terms of a robot procurement contract should be defined by the project team and legal counsel).

For robot deployments, the sign-off should address:

• Who signs: The buyer's authorized project lead — not a junior team member, not the supplier's installation engineer. The signatory should have authority to confirm acceptance on behalf of the buyer organization.
• What they are signing: Confirmation that all P1 items are closed and verified, all P2 items are documented with close-out dates and owners, and all P3 items are logged with investigation owners and deadlines.
• What happens after signing: The system transitions from project mode to operations mode. Deferred items enter a hypercare or defect-resolution period with defined timelines. The warranty period (if applicable per the warranty terms) and SLA measurement (if applicable per the SLA agreement) may begin from this point — or from a date defined in the contract.
• What signing does not mean: It does not mean the system is perfect. It should not be assumed to waive the buyer's rights regarding deferred items. It should not be assumed to close the supplier's obligation to resolve items on the reservation list. Whether these protections hold depends on the contract terms, and the buyer should confirm the legal effect of acceptance sign-off with qualified counsel.

The buyer should maintain its own punch list — not rely solely on the supplier's list. In construction commissioning practice, the administrator (architect or engineer) reviews the contractor's punch list and adds items the contractor missed. The same principle applies: the supplier's list reflects the supplier's view of what is open. The buyer's list reflects the buyer's view. Discrepancies should be reconciled, not ignored.

Robot-Specific Punch List Traps: Software, Sensors, Safety, and Integration

Several categories of open issues create specific traps during robot acceptance:

The "It Works Most of the Time" Software Trap

A software bug that appears once every few hours, or once a day, is easy to dismiss during a walk-through — the system runs fine during the demo. But intermittent failures are the hardest to verify as fixed. If the supplier says "we patched it," the closure criterion should not be "it did not happen during the 30-minute walk-through." It should be a defined observation period (e.g., 48 hours of operation under normal load with zero occurrences) with log evidence. Without this, the item should remain open.

The "Within Specification" Sensor Trap

A sensor reading that is within the specified tolerance but drifting toward the edge is technically compliant — but may indicate a calibration issue, an environmental interference, or an early sign of hardware degradation. If the sensor is safety-related, "within specification today" is not sufficient. The closure criterion should include a stability check over a defined period. If the sensor is non-safety-related, it may be a P2 item — but the buyer should document the current reading and trend, so that future drift can be assessed against a known baseline rather than a subjective "seems worse."

The "Safety Function Tested" Trap

Safety functions — emergency stop, speed monitoring, collision avoidance, safety perimeter — are often demonstrated once during the walk-through and checked off. But a single successful test does not verify the function under all relevant conditions. The acceptance criteria should define the test conditions: under what load, what speed, what obstacle size, what approach angle, what environmental condition. If the acceptance criteria do not specify these conditions, the buyer should request them before the walk-through — not argue about them during it.

The "Integration Works in the Demo" Trap

During the walk-through, the robot successfully communicates with the WMS, opens the door, calls the elevator. But the demo tests the happy path — not failure modes. What happens when the WMS sends an invalid message? When the elevator is occupied? When the network drops for 3 seconds? Integration punch list items should include failure-mode testing, not just functional verification. If failure-mode testing was not part of the acceptance criteria, the buyer should at minimum document which failure modes were tested and which were not, so that post-go-live incidents can be assessed against a known gap.

Punch List Checklist for Robot Buyers

Before Installation (Procurement Phase)

• [ ] Acceptance criteria defined in the SOW or contract — including specific test conditions for safety functions
• [ ] Defer conditions defined: which categories can defer, which cannot, maximum defer period, who has authority to classify
• [ ] Punch list process agreed: who participates, when preliminary and final lists are conducted, who maintains the master list
• [ ] Acceptance sign-off authority defined: who can sign on behalf of the buyer
• [ ] Reservation list mechanism defined: what happens to items still open at handover
• [ ] Verification methods agreed for software, sensor, safety, and integration items — not just "fixed" but "verified under defined conditions"

During Site Acceptance Testing

• [ ] Buyer maintains its own punch list — not relying solely on supplier's list
• [ ] Every item has: number, location/description, priority code, owner, target close date, verification method
• [ ] Safety functions tested under defined conditions (load, speed, obstacle, angle) — not just a single demo
• [ ] Software items require defined observation period with log evidence for closure
• [ ] Sensor items document current readings and trends, not just pass/fail
• [ ] Integration items include failure-mode testing, not just happy-path verification
• [ ] P3 items transitioned to change order process if they require scope changes

Before Sign-Off

• [ ] All P1 items closed and verified by defined method
• [ ] All P2 items documented with close-out dates and owners on reservation list
• [ ] All P3 items logged with investigation owners and deadlines
• [ ] Buyer's project lead confirms readiness to sign — not pressured by supplier's schedule
• [ ] Post-sign-off period defined: hypercare duration, defect-resolution timelines, warranty start date, SLA start date

Source List

1. Killcross, "Punchlist — an overview," ScienceDirect Topics, Chemical and Process Plant Commissioning Handbook | URL: https://www.sciencedirect.com/topics/engineering/punchlist — Referenced for three-priority classification, two-phase punch list process, and punch list item structure (commissioning practice, not academic research)
2. Mears Ltd v Costplan Services (South East) Ltd & Ors [2019] EWCA Civ 502 (Court of Appeal of England and Wales) | URL: https://www.bailii.org/ew/cases/EWCA/Civ/2019/502.html — Referenced via secondary sources for substantial completion principles; BAILII official judgment page confirmed, full text not independently accessed due to site access restrictions; case decided under English construction law, applicability to robot procurement contracts to be confirmed by qualified legal counsel
3. IEC 62381:2024, "Automation systems in the process industry — Factory acceptance test (FAT), site acceptance test (SAT), and site integration test (SIT)" | IEC webstore: https://webstore.iec.org/ (search for IEC 62381:2024) — Referenced for FAT/SAT/SIT three-stage acceptance testing framework; standard scope is process industry automation systems, applicability to robot deployments to be confirmed
4. FIDIC, Conditions of Contract for Plant and Design-Build (Yellow Book), Second Edition 2017, Sub-Clause 10.1 (Taking-Over Certificate) | FIDIC official publication; referenced via secondary sources for specific clause content — Referenced for Taking-Over Certificate and defects notification period mechanism; FIDIC is an engineering contract framework, robot procurement contract terms to be defined by project team and legal counsel
5. "Defects 'Liability' Periods" — Baker McKenzie, Australia, March 2014 | Referenced via secondary sources; Baker McKenzie official website (article page no longer publicly accessible; referenced via secondary sources) — Referenced for defects liability period concept
6. AIA Document A201-2017, General Conditions of the Contract for Construction, American Institute of Architects | Official AIA contract document; available for purchase from AIA — Referenced for substantial completion and punch list concepts in construction contracts