AMR Go-Live Readiness How to Prove a Mobile Robot System Is Ready for Production

AMR go-live readiness is not the moment when a robot can finally complete a route. It is the point at which the factory has enough verified evidence to rely on the mobile-robot system as a production service.

That distinction matters.

A robot can be installed but not commissioned. It can be commissioned but not ready for production. It can pass an individual test while the surrounding wireless network, production interfaces, charging strategy, operating organization or recovery ownership remains incomplete.

This is why the question before launch should not be:

“How much of the project is finished?”

The stronger question is:

“Which unresolved dependency can still invalidate safe and reliable production?”

A mature AMR production readiness process converts that question into an evidence-based decision. It identifies critical dependencies, verifies them under representative conditions, distinguishes acceptable temporary limitations from true no-go conditions, freezes the accepted production baseline and defines what must be revalidated if conditions change.

This article develops a production-readiness framework for buyers, integrators, factory engineering teams and system owners. It is not a substitute for project-specific safety engineering, regulatory assessment or formal acceptance testing. Instead, it addresses the gap between “the system works” and “the factory can depend on it.”

What Is the Difference Between Installation, Commissioning, Readiness and Acceptance?

Mobile-robot projects often use these words interchangeably. That creates confusion because each one answers a different engineering question.

The existing AMR Acceptance Testing Guide addresses how system behavior should be tested and evidenced. This article addresses the step before and around that process: whether all dependencies necessary to make those tests and the subsequent production launch meaningful are actually ready.

Why Project Completion Percentage Is a Weak Readiness Metric

Consider a project dashboard showing:

Robot hardware: 100%

Mapping: 100%

Fleet software: 95%

Network: 90%

MES integration: 90%

Training: 80%

A project manager may average these numbers and conclude that the deployment is roughly 92% complete.

But readiness is not arithmetic.

If the final 10% of MES work contains the transaction that releases all production missions, the fleet may have no production service.

If the unverified part of the network is the transition between two access points on the only route into assembly, the problem is not “10% of wireless.” It may be the single dependency that interrupts the whole material flow.

If a night shift has no trained person authorized to recover a loaded robot from a critical aisle, the project may appear nearly finished while still having an operational ownership gap.

Critical dependencies behave as gates, not percentages.

This principle should sit at the center of every AGV deployment checklist.

Build a Readiness Dependency Taxonomy Before Building a Checklist

A long checklist can create the illusion of control while hiding the structure of the problem.

A stronger AMR readiness assessment first classifies dependencies by domain. Each dependency should answer four questions:

What production capability depends on it?

What evidence proves it is ready?

What happens if it is unavailable?

Who owns its restoration or escalation?

The following Readiness Dependency Taxonomy is an original framework developed for this article.

This taxonomy prevents a common mistake: treating AMR infrastructure readiness as nothing more than power outlets and Wi-Fi coverage.

Infrastructure in a production AMR system includes the digital and physical services on which the robot depends: fleet control, network, charging, stations, doors, elevators, PLC logic, WMS/MES interfaces and the people who restore those services.

Which Dependencies Should Be Classified as Critical?

Not every unfinished item should block launch.

Criticality depends on consequence.

A dependency should be treated as a potential production gate when its absence can create one or more of the following outcomes:

• an unacceptable safety condition;
• loss of a required production service;
• uncontrolled mission or material state;
• loss of a required recovery capability;
• loss of traceability;
• unacceptable throughput degradation;
• or an inability to restore the accepted configuration.

For example, a missing cosmetic dashboard screen is rarely equivalent to a missing emergency operating procedure.

A delayed spare bracket is rarely equivalent to an unverified production WMS transaction.

A temporary reporting field is rarely equivalent to an untested wireless handover on a mandatory transport route.

Readiness therefore needs explicit criticality rather than a flat task list.

Use a Readiness State Machine Instead of “Open” and “Closed”

Most project trackers reduce readiness to two states:

Open.

Closed.

That is not enough for an industrial deployment.

The following Readiness State Machine is an original framework developed for this article:

Dependency Identified → Requirement Defined → Evidence Requested → Evidence Available → Verification → {Verified / Conditional / Failed} → Remediation → Revalidation → Production Baseline → Go-Live Authorization → Operational Monitoring

The value is not the arrows. The value is the entry and exit condition for every state.

Dependency Identified

The project recognizes that production depends on something.

Example: automatic door D14 must open for missions between warehouse and assembly.

Requirement Defined

The team defines what “ready” means.

It is not enough to say “door integrated.”

The requirement may include:

• request semantics;
• door-open confirmation;
• timeout behavior;
• safe robot waiting position;
• manual release authority;
• and recovery after communication failure.

Evidence Available

A drawing, test log, configuration screenshot or verbal statement is not automatically valid evidence.

Evidence must correspond to the production configuration and representative conditions.

Verification

The evidence is reviewed or challenged.

This may involve document review, observation, measurement or active test.

Verified

The dependency satisfies the defined requirement under the agreed scope.

Conditional

The dependency is not fully in the preferred state, but the remaining limitation is understood and controlled.

Failed

The evidence does not prove readiness, or a critical requirement is not satisfied.

Production Baseline

The verified configuration becomes part of the accepted production reference.

This is important because evidence attached to an old map, old software version or temporary network is not proof of the current system.

What Makes a Conditional Go-Live Legitimate?

Factories rarely reach a perfect state at one instant.

Some temporary limitations may remain.

The engineering question is not whether a project has zero open items. It is whether the open item is controlled.

This leads to the concept of scope-limited production readiness.

A RED dependency cannot be averaged away by ten GREEN items.

That rule is fundamental.

Example of a Valid AMBER Condition

A warehouse expansion area will not open for another month.

The production map includes only Phase 1.

Routes into Phase 2 are disabled.

Operators cannot dispatch missions into the unfinished area.

The limitation has a named owner and requires a new readiness review before the area is enabled.

This is a controlled conditional launch.

Example of an Invalid “Conditional” Condition

The production network has not been tested after final access-point changes.

The team assumes the robots will probably roam correctly because they worked during commissioning.

There is no temporary control capable of guaranteeing the required transport service.

Calling this AMBER does not make it controlled.

For a production-critical route, it may remain RED.

Readiness Exists at More Than One System Level

A robot can be ready while the fleet is not.

A fleet can be ready while the production process is not.

The following four-level model prevents readiness reviews from stopping at the vehicle.

Vehicle Readiness Is Necessary but Not Sufficient

A buyer may see twenty robots complete individual missions and conclude that the fleet is ready.

But fleet operation introduces effects that do not appear in single-vehicle demonstrations:

• intersection queues;
• charger competition;
• traffic deadlocks;
• priority interactions;
• shared-station contention;
• and recovery around a failed vehicle.

The existing AMR Fleet Traffic Management and Safety Guide examines this layer in greater detail.

Infrastructure Readiness Is a Production Dependency

One fleet controller, one wireless zone, one charging group, one elevator or one WMS transaction can become a practical single point of service failure.

The readiness review should therefore ask:

If this dependency is unavailable, how much production capability remains?

For how long?

Does the system enter a controlled degraded state?

Does restoration require a specialist?

For system recovery after such failures, refer to the AMR/AGV Failure Recovery & Resilience Guide.

How Should Wireless Readiness Be Proven?

“The robot has Wi-Fi” is not an engineering acceptance statement.

Industrial wireless systems operate in environments with metal structures, moving equipment, changing obstructions, competing traffic and interference. Network quality can therefore affect physical system behavior.

NIST research on industrial wireless systems emphasizes measurement of reliability, latency, interference resilience and performance in manufacturing environments rather than assuming nominal connectivity is sufficient.

For AMR site readiness, the practical implication is that the final production network should be evaluated along the real robot routes and under representative network conditions.

Useful evidence may include:

• route-based signal measurements;
• handover behavior between access points;
• latency distribution;
• packet-loss observations;
• interference or congestion conditions;
• authentication and reconnection behavior;
• and robot behavior during temporary communication degradation.

The important distinction is that NIST industrial wireless research is not an “AMR readiness certification.” It provides engineering evidence that wireless performance should be measured against application requirements.

How Should AMR Integration Readiness Be Proven?

AMR integration readiness is not proven because an API successfully returned HTTP 200 once.

Production integration includes state ownership.

Suppose a WMS releases a material order.

The fleet manager creates a mission.

The AMR reaches the destination.

The physical transfer completes.

Then the confirmation message to the host fails.

What is the material state?

Can the host release a duplicate mission?

Which system owns reconciliation?

Can the operator manually close the transaction?

Is that manual action traceable?

These are readiness questions because the interface must remain understandable not only when communication succeeds, but when the distributed system disagrees.

Build an Interface Evidence Matrix

If the project uses VDA 5050, the current VDA recommendation defines communication for exchanging order and status data between mobile robots and central fleet control. It is valuable for communication interoperability, but it does not automatically prove that the surrounding WMS, PLC, station, safety, capacity and organizational dependencies are ready.

For that boundary, see AMR/AGV Multi-Vendor Interoperability.

Production Capacity Must Be Verified as a Service, Not as Robot Speed

A robot specification may state maximum speed, battery runtime and payload.

None of those numbers directly proves required production service.

A meaningful AMR production readiness review connects vehicle capability to material demand.

Useful inputs include:

• missions per hour;
• peak demand windows;
• pickup and delivery service time;
• loaded and empty distance;
• traffic waiting;
• station queue time;
• charging demand;
• fleet availability;
• mission priority;
• and recovery-related capacity loss.

Do Not Validate Only the Average Day

Suppose a factory requires 640 missions during an eight-hour shift.

The simple average is 80 missions per hour.

But assume 210 missions occur during one 90-minute production peak.

The average hides the true service requirement.

A fleet that comfortably processes 80 missions per hour may still create line-side shortages during the peak.

This is why robot deployment risk should be assessed against demand distribution, not only daily totals.

The existing AMR/AGV Material Response Guide explains why material-response performance is often more important than simple robot utilization.

Use Quantitative Readiness KPIs Instead of “Looks Ready”

The following indicators are original analytical metrics proposed for project governance. They are not ISO, ANSI/A3 or VDA requirements.

Critical Dependency Closure Rate

CDCR = Verified Critical Dependencies / Total Identified Critical Dependencies × 100%

CDCR shows how much of the critical dependency set has been verified.

However, it should never be used to justify launch while a remaining critical dependency is RED.

Interface Exception Coverage

IECOV = Production Interface Exception Scenarios Tested / Required Interface Exception Scenarios × 100%

This shifts attention from “the interface works” to whether meaningful abnormal transactions have been challenged.

Operational Ownership Coverage

OOC = Critical Operating and Recovery Scenarios With Named Trained Owners / Total Critical Scenarios × 100%

A technically complete system with low OOC is still dependent on commissioning specialists.

Baseline Drift Count

BDC = Number of Unapproved or Unreconciled Changes Since the Last Verified Production Baseline

The desired value before launch is not “small.” The project should understand every change capable of affecting the evidence.

Temporary Condition Exposure

TCE = Active Temporary Conditions Without Owner, Expiry Date or Revalidation Trigger

Temporary conditions are normal. Unowned temporary conditions are dangerous because they can silently become permanent.

Evidence Freshness Ratio

EFR = Critical Evidence Generated Against the Current Baseline / Total Critical Evidence × 100%

A test report from three weeks ago may lose value if the map, fleet software, access-point configuration or station layout has changed since the test.

Actively Challenge Readiness Before Production Challenges It for You

One of the strongest improvements a buyer can make is to stop verifying readiness only through passive document review.

The project should deliberately challenge critical dependencies.

This is different from the full fault-injection program discussed in the Failure Recovery article.

The purpose here is narrower:

Prove that the dependency assumed by the go-live decision actually behaves as expected under representative stress.

Readiness Challenge Test Matrix

These tests convert AMR go-live readiness from an opinion into observable evidence.

Safety Readiness Must Be Separated From General Production Readiness

Safety deserves explicit boundaries.

ISO 3691-4:2023 specifies safety requirements and means for verification for driverless industrial trucks and their systems. The standard explicitly includes examples such as automated guided vehicles and autonomous mobile robots.

ANSI/A3 R15.08-2-2023 addresses requirements for IMR systems and IMR applications and provides a framework for safe system integration.

ANSI/A3 R15.08-3-2026 addresses use of IMR applications and emphasizes maintaining acceptable risk through the operating lifecycle, including risk assessment and management of change.

These references are highly relevant to application safety.

They should not be presented as universal “AMR production readiness certification.”

A project can satisfy a safety requirement and still fail production capacity.

A project can have excellent throughput and still have an unacceptable safety condition.

The two dimensions must both be acceptable, but they are not interchangeable.

Standards and Engineering Frameworks: Use the Correct Boundary

Worked Example: A Project That Is “94% Complete” but Still Not Ready

Evidence classification: Illustrative engineering model.

The following example is created for explanation. It is not presented as measured data from a named factory.

Application

An electronics plant is preparing a 24-AMR system for production material replenishment.

The fleet connects the central supermarket with six assembly zones.

Production runs two shifts.

Mission demand varies significantly during model changeovers and shift startup.

Reported Project Progress

The dashboard appears strong.

A management presentation could easily describe the deployment as “approximately 94% complete.”

Readiness Finding 1: Final Wireless Configuration Changed After Testing

The wireless team changed access-point power and roaming parameters after the last fleet test.

The robots connect successfully while stationary.

No route-based validation has been completed under the final configuration.

Status: RED for routes dependent on the changed network.

The problem is not that Wi-Fi is “5% unfinished.”

The evidence no longer represents the current baseline.

Readiness Finding 2: MES Timeout Ownership Is Undefined

Normal missions complete correctly.

However, if physical delivery finishes while the MES acknowledgement is unavailable, neither the automation team nor IT owns transaction reconciliation.

Status: RED.

A known exception can create uncertainty between physical and digital material state.

Readiness Finding 3: One Secondary Assembly Zone Is Not Yet Trained

The zone is not part of the first-week launch scope.

Mission dispatch into the area can be disabled through fleet permissions.

The expansion has a scheduled training and revalidation gate.

Status: AMBER.

Readiness Finding 4: Spare Charger Module Is Delayed

The site has sufficient installed charging capacity for the initial phase, and the existing contingency assumption has been tested.

Status: AMBER, subject to documented temporary support plan.

Decision

The project should not be described as 94% ready.

For the full production scope, the result is:

NO-GO until the two RED dependencies are closed or the affected scope is formally removed from launch.

This example illustrates why critical-dependency logic is more useful than project-completion averages.

What Evidence Should Exist Before the Go-Live Meeting?

A readiness meeting should not be a verbal roundtable in which every department says, “We are basically done.”

The project should maintain a structured Production Readiness Dossier.

The following evidence model is developed for this article.

1. Production Scope Baseline

Fleet size, robot types, routes, stations, operating zones, shifts, payload classes, mission types and explicit exclusions.

2. Physical Site Baseline

Approved layout, final station positions, permanent racks, restricted zones, traffic interfaces and remaining temporary conditions.

3. Vehicle and Payload Configuration

Robot version, top module, payload assumptions, sensors, battery configuration and relevant mechanical limitations.

4. Safety Evidence

Applicable risk assessments, verified safety functions, operating conditions, residual-risk controls and authorized boundaries.

5. Network Evidence

Final OT architecture, route-based measurements, access-point configuration, roaming behavior, known limitations and escalation ownership.

6. Fleet Configuration Baseline

Maps, traffic rules, station coordinates, mission priorities, charging thresholds, permissions and active software versions.

7. Interface Responsibility Matrix

For every production interface: normal sequence, error semantics, timeout, retry, reconciliation and responsible owner.

8. Capacity Evidence

Expected mission demand, peak-demand model, queue assumptions, charging demand, available fleet capacity and critical bottlenecks.

9. Acceptance Evidence

Relevant FAT/SAT plans, results, deviations and unresolved acceptance actions.

10. Operational Procedures

Startup, shutdown, normal operation, abnormal-state response, manual intervention boundaries and escalation procedure.

11. Recovery Evidence

Known failure classes, restoration procedures, trained owners, support contacts and service-return conditions.

12. Training Records

Role-based evidence for operators, supervisors, maintenance, IT/OT and system owners.

13. Temporary Condition Register

Every temporary route, software rule, station condition, network setting or operational workaround with owner and expiry trigger.

14. Change-Control Baseline

What configuration has been accepted, who can change it, which changes require revalidation and how rollback is performed.

15. Open-Issue Register

Each remaining issue classified GREEN, AMBER or RED with impact, owner, due date and launch disposition.

What Should Automatically Trigger a No-Go Review?

A readiness process has little value if schedule pressure always wins.

The project should define no-go triggers before the launch meeting.

Potential triggers include:

• an unresolved safety condition affecting intended operation;
• a critical network configuration changed after the evidence was generated;
• a production interface with undefined failure ownership;
• a required route, station, door, elevator or charger unavailable without validated contingency;
• an uncontrolled map or fleet-software difference from the tested baseline;
• production demand materially exceeding the validated capacity model;
• insufficient trained ownership for the launch shift;
• or inability to restore the approved configuration after a failed change.

The purpose is not to make deployment bureaucratic.

The purpose is to prevent schedule pressure from turning an unverified assumption into a production dependency.

Who Should Sign the Production Readiness Decision?

Readiness is cross-functional.

No single robot supplier or project manager owns every dependency.

A practical review normally requires representatives who own:

A supplier may prove that a robot capability exists.

Only the factory can ultimately confirm that the whole production organization is prepared to depend on it.

How Should Buyers Put Readiness Requirements Into the RFQ or Contract?

Readiness becomes much harder when it is first discussed at the end of commissioning.

Industrial buyers can move key evidence requirements upstream into the RFQ, statement of work or acceptance plan.

Buyer-Verifiable Questions

Ask the supplier or integrator to identify the production configuration baseline.

Ask which dependencies must be supplied by the customer before SAT.

Ask which tests require final production network conditions.

Ask how maps, routes and station coordinates are version controlled.

Ask how a WMS/MES timeout is reconciled.

Ask what happens when a destination becomes unavailable after dispatch.

Ask how the fleet behaves if one charger is removed from service.

Ask how many robots can be unavailable before production service falls below the required demand.

Ask which recovery actions normal factory maintenance is authorized to perform.

Ask what evidence is required after a software, map, network or station change.

Ask how the accepted configuration can be restored.

Ask for a list of temporary conditions before final acceptance.

Ask which RED conditions prevent launch and which AMBER conditions can be scope-limited.

This changes procurement from:

“Does the robot support this feature?”

to:

“Show us the evidence that this dependency is ready for our production condition.”

Do Not Confuse Readiness With the Absence of Defects

A production system can contain known imperfections and still be ready.

Conversely, a system with very few open defects can still be unready.

The difference is consequence and control.

Readiness is not perfection.

Readiness means:

the operating scope is known;

the critical dependencies are verified;

remaining deviations are understood;

temporary conditions are controlled;

ownership exists;

the production baseline can be identified;

and the factory knows what would cause the readiness decision to be reopened.

What Reopens the Readiness Gate After Go-Live?

The go-live decision should not be permanent.

A system can leave its accepted condition after ordinary factory changes.

Potential revalidation triggers include:

• map changes;
• station relocation;
• new access points or network policies;
• fleet-software updates;
• robot firmware changes;
• new robot types;
• fleet expansion;
• new payload geometry;
• charging changes;
• traffic-rule changes;
• new WMS/MES logic;
• or changed human/forklift traffic.

This lifecycle view is consistent with the broader principle that an industrial mobile-robot application must continue to control risk and system assumptions as the operating environment changes.

The readiness dossier should therefore become a living baseline rather than an archive folder that nobody opens after launch.

Focused FAQ

What is AMR go-live readiness?

AMR go-live readiness is the evidence-based determination that the critical site, safety, network, fleet, integration, capacity, operational and recovery dependencies required for production have been verified or explicitly controlled.

What is AMR production readiness?

AMR production readiness means the mobile-robot system can be depended on as part of the intended production service, not merely demonstrated as functioning equipment.

What is an AMR readiness assessment?

An AMR readiness assessment identifies production dependencies, defines evidence requirements, verifies the current baseline and classifies each critical item as verified, conditional or not ready.

What should an AGV deployment checklist include?

An AGV deployment checklist should cover the physical site, configured vehicles, application safety, wireless infrastructure, fleet configuration, production interfaces, capacity, charging, operations, recovery, support and change control.

What is the difference between AMR commissioning and readiness?

Mobile robot commissioning proves that configured functions operate. Readiness asks whether the full production environment and organization can safely and reliably depend on those functions.

How do I know whether a factory has AMR site readiness?

AMR site readiness exists when the final or explicitly controlled physical environment matches the assumptions used for mapping, routing, docking, safety, network validation and material-flow operation.

What is AMR infrastructure readiness?

AMR infrastructure readiness includes the network, fleet manager, charging system, host systems, PLCs, doors, elevators, conveyors and other services required for the mobile-robot application to operate.

What is AMR integration readiness?

AMR integration readiness means production interfaces have verified normal transactions, defined abnormal-state semantics, clear timeout and retry behavior, state reconciliation rules and named ownership.

Can an AMR project go live with open issues?

Yes, but only when the open issue does not create an uncontrolled critical dependency. A conditional launch should document its affected scope, temporary control, owner, expiry condition and revalidation trigger.

Should AMR readiness be expressed as a percentage?

Percentages can support project tracking, but critical readiness should not be decided by averages. One unresolved RED dependency may make the dependent production scope unready even if most project tasks are complete.

What is the most important AMR production launch question?

The most important question is not “Is the project almost finished?” It is: Which unresolved dependency can still invalidate safe, controlled or required production service?

Conclusion: Readiness Is the Closure of Critical Assumptions

An AMR system is not production-ready because the robots arrived.

It is not ready because the fleet dashboard is green.

It is not ready because a demonstration completed successfully.

It is not ready because a project spreadsheet says 95%.

Production readiness exists when the assumptions required for the mobile-robot service have been converted into evidence.

The physical environment must match the deployment model.

Safety conditions must correspond to the real application.

The production network must support the required communication behavior.

Maps, fleet software and configuration must have a controlled baseline.

Production interfaces must define both success and failure semantics.

Capacity must be validated against realistic material demand.

Normal factory personnel must be able to operate, recover and escalate the system.

The organization must know which changes invalidate prior evidence.

That is the purpose of a serious AMR production launch gate.

It transforms the conversation from:

“The robot seems ready.”

into:

“The dependencies required for this production scope have been identified, verified, controlled and assigned to owners.”

That is a much stronger basis for putting autonomous mobile robots into a real factory.

Standards and Primary References

ISO 3691-4:2023 — Industrial trucks — Safety requirements and verification — Part 4: Driverless industrial trucks and their systems.
//www.iso.org/standard/83545.html

ANSI/A3 R15.08-2-2023 — Industrial Mobile Robots — Safety Requirements — Part 2: Requirements for IMR system(s) and IMR application(s).
//www.automate.org/robotics/news/ansi-a3-r15-08-2-safety-standard-for-industrial-mobile-robot-systems-and-applications-now-available

ANSI/A3 R15.08-3-2026 — Industrial Mobile Robots — Safety Requirements — Part 3: Use of IMR Applications.
//www.automate.org/store/products/ansi-a3-r15-08-3-2026-american-national-standard-for-industrial-mobile-robots-safety-requirements-part-3-use-of-imr-applications-pdf-download

VDA 5050 Version 3.0.0 — Interface for the Communication between Mobile Robots and a Fleet Control.
//www.vda.de/en/topics/automotive-industry/vda-5050

National Institute of Standards and Technology — Wireless Systems for Industrial Environments.
//www.nist.gov/programs-projects/wireless-systems-industrial-environments

Research and Evidence Note

The standards-related statements in this article were checked against primary information published by ISO, the Association for Advancing Automation, VDA and NIST and available in August 2026.

The Readiness Dependency Taxonomy, Readiness State Machine, GREEN/AMBER/RED launch model, four-level readiness model, Critical Dependency Closure Rate, Interface Exception Coverage, Operational Ownership Coverage, Baseline Drift Count, Temporary Condition Exposure, Evidence Freshness Ratio, Readiness Challenge Test Matrix and Production Readiness Dossier are original analytical frameworks developed for this article.

The 24-AMR worked example is explicitly an illustrative engineering model. Its figures are not presented as measurements from a named customer site and should not be interpreted as universal performance benchmarks.

Actual launch criteria should be defined against the specific facility, application, applicable safety requirements, production process, robot technology, network architecture, organizational responsibilities and contractual acceptance requirements.

#AMRGoLiveReadiness #AMRProductionReadiness #AMRReadinessAssessment #AGVDeploymentChecklist #AMRSiteReadiness #AMRInfrastructure #AMRIntegration #MobileRobotCommissioning #RobotDeploymentRisk #AMRProductionLaunch #IndustrialAutomation #FactoryIntralogistics