The category alone does not demonstrate a capability
Autonomous mobile robots, or AMRs, can move around a warehouse to carry out tasks; the description of this category is not enough to determine what functions a particular installation offers. A warehouse-solutions provider describes AMRs as devices capable of moving and carrying out activities in that setting, but that general characterization does not establish the performance or safety of a specific model. (Modula: https://www.modula.eu/es/integracion-robotica/robots-moviles-autonomos/)
The useful question is not just whether equipment is advertised as autonomous, but what task it performs, under what conditions, and within what limits. Transporting loads, picking up objects, and moving between stations are different uses; they should not be treated as universal capabilities of all AMRs. When assessing a proposal, define the intended mission and request documentation that addresses that task and the configuration being offered.
Autonomy describes a capability to move or perform tasks, not a guarantee for every layout, load, or interaction. Before assessing a deployment, specify where the mission starts and ends, what conditions must be maintained, and what situations require human intervention. The more precisely the use is defined, the easier it is to check whether the evidence provided applies to the planned operation. That definition also helps distinguish what the equipment must do from what is left to people or other system components. If a proposal includes several types of task, consider them separately: evidence relating to one mission does not automatically show that the others are covered. It is also useful to be explicit about variations that might affect the mission, such as a changed route, a different load, or work taking place at the same time as other warehouse activity. Those details do not establish that a robot can handle the variation; they help identify what needs to be assessed and what the documentation would need to address. A clear description of the proposed use therefore provides a practical starting point for reviewing claims without assuming that the product category itself proves capability.
Standards: check scope and edition before citing them
The draft cited ISO 3691-4:2020 and ISO 21423, as well as OSHA pages, to describe requirements, accidents, and standards. Those references are not part of the verifiable evidence package received for this revision. The claims about their scope and content have therefore been removed; this article cannot establish which specific standard applies, which edition is current, or what obligations govern a particular installation.
As a practical step, ask the supplier to identify the standards and editions it considers relevant, the scope of the system assessed, and the documentation supporting its claims. Then check that information against a standards source or competent authority in the relevant jurisdiction. Relevant does not automatically mean mandatory, and citing a standard is not the same as demonstrating that specific equipment meets its requirements.
The documentation should clearly identify the equipment, configuration, and conditions covered by any assessment. It is also important to distinguish a commercial claim from an assessment conducted for the intended use. Without applicable documentation and verified standards sources, this guide cannot attribute conformity or declare that a standard resolves every warehouse risk. When reviewing documents, check that they describe the same equipment and conditions proposed for the pilot; a general reference without that connection does not show which part of the operation it covers. Reviewing standards and assessing the installation are related steps, but they are not interchangeable. A reference to a standard may be useful as a lead for further checking, but it does not replace checking its actual scope, edition, and relevance to the specific application. Similarly, the presence of an assessment document does not, by itself, show that every operational scenario has been examined. The supplier’s explanation should make clear what was evaluated and where the evaluation’s limits lie.
Safety: ask for evidence about scenarios, not adjectives
Words such as “safe,” “smart,” or “avoids obstacles” do not, by themselves, explain what to expect when a person crosses a route, a temporary obstacle appears, or communication is lost. For each situation that matters to the operation, the company should request a verifiable description of what the system detects, the response expected, known limits, and the procedure to follow if the function does not work as expected.
It is also important to distinguish a component test, a controlled demonstration, and an assessment of the system in the actual warehouse. They are not interchangeable forms of evidence. The available source package does not provide comparable results from installations or performance measurements; it therefore cannot support claims about an incident rate, a universal safe distance, or the general superiority of one navigation method.
A useful question connects each identified risk with an expected response and a way to check it. If a route is blocked, for example, the assessment should clarify what behavior is expected and how operation resumes. You can request records or test results, but interpreting them requires knowing the conditions under which they were obtained. An isolated result, without that context, does not demonstrate how the system will respond in other environments or on other tasks. For a clear review, document each scenario alongside the response expected and the evidence that would confirm it. This avoids confusing a description of functions with proof that those functions operate as intended. The same approach can be used to clarify what happens when an obstacle remains in place, when a route changes, or when a communication link is interrupted. These should be framed as questions to investigate, not as assumptions about how a particular robot behaves. Records are most useful when the test conditions, configuration, and criteria are stated clearly enough for the people reviewing them to understand what the result does—and does not—show.
Human interaction also requires assessment
A research article titled “Perceived safety during human-robot interaction with an autonomous mobile robot” studies perceived safety during an interaction between people and an AMR. The reference identifies the subject of the research, but the information available in the source package does not allow its protocol to be described precisely or conclusions to be extrapolated to every warehouse. (Research: https://pmc.ncbi.nlm.nih.gov/articles/PMC13077582/)
In a pilot, practical questions can be raised: Do people understand when the robot is going to pass? What do they do when a route is blocked? Can they resume their task without improvising a maneuver? Are incidents recorded, and who reviews them? These are questions to define and assess at each installation, not findings demonstrated by the research source available here. Signage, training, and the assignment of responsibilities should be considered alongside the technical function.
It is useful to distinguish between people’s perception that a robot is safe and the technical verification of the controls and procedures for a task. The former can provide information about interaction; it does not replace a technical assessment. Likewise, a technical test alone does not describe how people will respond to a shared route or an interruption. The available evidence cannot quantify these differences or establish a universal conclusion. Including questions about how people understand the robot’s passage or report an incident can help identify matters that need review, without turning pilot responses into conclusions applicable to other sites. Consider recording which questions were asked, who was involved, and what conditions applied, so that the observations are interpreted in context. These steps do not establish how people at another warehouse will behave; they help make the local assessment clearer and more useful for deciding whether the planned workflow needs to be adjusted.
Integration: demonstrate the complete workflow
A robot’s ability to navigate does not, by itself, demonstrate that it is integrated into warehouse operations. Before a pilot, describe how an order becomes a mission, which component assigns tasks, how exceptions are communicated, and what happens when a connection or a piece of equipment is unavailable. These are design questions to check in the actual system; the available sources do not verify the interoperability of specific products.
In an integration test, trace the workflow from the system that originates an order through to confirmation of the task, including cancellations, blockages, recovery, and error logging. Identify the systems that exchange data, their interfaces, and support responsibilities. A compatibility statement or the existence of an interface does not, by itself, prove that the integration meets the workflow, permissions, or needs of the installation.
Following the process from end to end helps establish which component makes each decision and what information it needs. If a mission is not completed, for example, it should be clear who receives the alert and how the work is resumed or cancelled. The test should verify those steps under agreed conditions, rather than merely confirming that two systems exchange a message. It is also important to clarify what counts as confirmation that a task is complete and how an exception is detected; agreeing on this in advance lets participants assess the workflow against criteria they can understand. The review can also record what information is available to operators at each stage and what action is expected when a message is missing or an acknowledgement does not arrive. These are not claims about any particular product. They are aspects of the proposed workflow that should be made explicit so the test can show whether it works for the specific installation and its defined needs.
A checklist before the pilot
Before approving a test, define the exact load and task, routes and shared areas, shifts, planned changes to the environment, and the conditions under which the robot must stop or request intervention. Request the relevant risk assessment, operating and maintenance instructions, documented limits, and justification for the cited standards. For each performance claim, ask for the test conditions and acceptance criteria: a demonstration without context does not prove general performance.
Put in writing who validates the configuration, who can authorize route changes, and how modifications that affect intended operation will be communicated. The assessment must correspond to the load and task being tested. If those elements change, the available evidence may no longer describe the use that was assessed. Acceptance criteria should be understandable to the people running and supervising the pilot. A checklist agreed before starting also helps everyone distinguish an incident from an expected exception or a condition that requires the test to stop.
During the test, record incidents, human interventions, blockages, and communication failures according to criteria agreed in advance. Compare results with the existing process only if the methodology allows a valid comparison; a small or simulated test does not necessarily demonstrate sustained behavior. Define who can pause operations, who investigates an incident, and what evidence is needed before expanding the deployment. The prudent conclusion is that each claim must correspond to a defined task, system, environment, and test. The records should also make clear whether a problem affected the robot, the surrounding process, or the connection between systems, where that can be established. That distinction can help the team decide what requires follow-up without assuming that one observation proves a general pattern. Before the pilot begins, the participants can agree how results will be reviewed and how unresolved issues will be handled. Such agreements do not guarantee a successful deployment; they make the evaluation and its limits clearer.