Two contracts, one corridor

The question arrives in the third meeting, from whoever will own the incident at three in the morning. Your demo had Wi-Fi. What does the robot do in the lift, in the basement, in the seconds after an access point reboots?

Two documents we have found answer it in writing for a mobile robot that has lost its fleet manager, and they disagree.

VDA 5050 version 3.0.0 is the German automotive industry's interface between a fleet control system and mobile robots. Under it, a robot whose permission to occupy a space expires while the link is down stops and raises a RELEASE_LOST error at level CRITICAL. Under MiR's Fleet Enterprise Documentation, a robot the fleet can no longer reach keeps the resources it already held, finishes the mission it was already given, and after five minutes without communication is permitted to "continue the mission without waiting to be assigned resources" — to take ground, that is, it was never assigned.

Both are published, both are defensible, and this article does not say which is right. It says that a hospital running delivery robots from two vendors can get both behaviours in one corridor, and that no document reconciles them.

Neither publishes a detection time — how long the robot takes to notice. That is not an omission. Both were read end to end on 11 September 2026, with three other specifications, and the reason is structural: what the robot does next runs off a clock it already holds, not off noticing.

The first contract

VDA 5050 v3.0.0 was read at tag 3.0.0 in the VDA's own repository, not at main and not from a summary. The tag published on 18 March 2026; the specification is one file of 208,085 bytes [read].

Its baseline behaviour is generous. §4.1: "If the mobile robot disconnects from the broker, it keeps all the order information and fulfills the order up to the last released node."

§7.7 defines four connection states, and the distinction inside them is the finding: "'OFFLINE': connection between mobile robot and broker has gone offline in a coordinated way" against "'CONNECTION_BROKEN': the connection between mobile robot and broker has unexpectedly ended." Two events, two names — and §6.5 gives them two procedures: the coordinated one executed by the robot, the unexpected one by the broker publishing the robot's last will. A fourth state, HIBERNATING, covers a low-power hold where the robot stops sending state messages while the broker connection stays up.

The one channel that says the robot is gone disclaims being a health signal: §4.3's topic table describes connection as "Not to be used by fleet control for checking the mobile robot health, added for an MQTT protocol level check of connection".

What actually stops the robot is permission. Zones carry a releaseLossBehavior — §6.4.1.1, an enum of STOP, CONTINUE and EVACUATE — and "If not defined, the mobile robot is expected to STOP and report an error. 'STOP': Mobile robot stops and sends a 'RELEASE_LOST' error with level 'CRITICAL'." Corridors carry a narrower one — §7.3, an enum of STOP and RETURN, where "'STOP': Mobile robot shall stop and await manual intervention" and the "Default: 'STOP'." Two enums, and the same default in both.

The document declines what a hospital will assume it covers. §2, Scope: "This document does not define functional, operational, or system safety requirements and shall not be regarded or applied as a safety standard." The same clause adds that it "does not allocate responsibilities among operators, system integrators, vehicle manufacturers, or fleet control providers", and that its use "is optional and non-binding". No requirement quoted in this article is a safety requirement; the document says so itself.

The second contract, and the word we had been failing to search for

We previously concluded, from a search, that no fleet vendor published anything like this. That was wrong, and worth recording: we searched for the phrase "degraded mode". MiR's word is Unavailable, inside a product manual no search engine surfaces for our phrase. A search came back empty and we read it as the field being silent. The field was not silent.

MiR Fleet Enterprise Documentation (en), 01/2025, v.1.2, ©Copyright 2024–2025: Mobile Industrial Robots A/S, §2.17.5 "Unavailable robots" [read]. The copy we read is mirrored by a German reseller, not served from MiR's own portal. The document's identity is unambiguous — MiR's copyright footer, title and version on every page — but the host is not MiR's.

The clause opens: "When MiR Fleet cannot communicate with a connected robot, the robot is considered Unavailable." Six consequences follow. The robot keeps the resources it held on entering the state; it cannot be assigned new resources, missions, chargers or staging positions; it cannot exchange collision-avoidance data. And: "Continue executing missions they were assigned before losing connection."

Then the rule that puts MiR at odds with VDA 5050:

"If the robot needs a resource that it was not assigned before losing connection, it waits until it either reconnects to MiR Fleet and is assigned the resource, or until five minutes without any communication with MiR Fleet passes and the robot is permitted to continue the mission without waiting to be assigned resources. If the communication is ever re-established, the robot will revert to waiting for fleet resources like all other active fleet robots."

It is a resource-wait timeout measured from the loss of communication, not a detection latency and not comparable to one. Whether it can be configured is not stated in the document, and we do not know.

MiR publishes two things VDA 5050 does not. The supervisor-side case, §2.17.2: "When MiR Fleet starts up again, all robots are re-evaluated and resynchronized before being considered as active robots." And a coordinated disconnect with a name, §2.9.4 "Standalone robot", where "the robot creates a local MiR Fleet that runs on the robot itself" and "Occupied resources are handled in the same way as if a physical obstacle is blocking the position".

They disagree, and here is the corridor

Stop with a CRITICAL error, or take new ground after five minutes. Both documents are current, both describe the same class of machine, and a mixed fleet runs both.

1 · Connected

• VDA 5050 v3.0.0§6.6 — the state message is published when relevant events occur or at least every 30 seconds. §4.3 — the connection topic is “Not to be used by fleet control for checking the mobile robot health”.
• MiR Fleet Enterprise Documentation v1.2§2.17.5 — a connected robot waits to be assigned resources “like all other active fleet robots”. §2.22 — “The synchronization is only from MiR Fleet to the robots.”
• Tidewell — design targetCrew: every robot on the site network shares one governed memory. Published design, not a measurement.

2 · Link loss

• VDA 5050 v3.0.0§7.7 — four connection states, and two different events with two different names: “‘OFFLINE’: connection between mobile robot and broker has gone offline in a coordinated way” against “‘CONNECTION_BROKEN’: the connection between mobile robot and broker has unexpectedly ended”. §6.5 gives them two procedures.
• MiR Fleet Enterprise Documentation v1.2§2.17.5 — “When MiR Fleet cannot communicate with a connected robot, the robot is considered Unavailable.” §2.9.4 gives the coordinated case its own name, Standalone robot: “the robot creates a local MiR Fleet that runs on the robot itself”.
• Tidewell — design targetOne transition published: link loss → Solo. We do not distinguish a coordinated disconnect from an unexpected one, and both documents above do. That is the gap in our own contract.

3 · Detection

• VDA 5050 v3.0.0 — no value§6.5 names the mechanism — “The disconnection is detected via a heartbeat that is exchanged between the broker and the client” — and specifies no interval and no tolerance. §7.10's factsheet offers four timing slots and fills in none. §6.9: “The handling of timeouts and retries shall be defined during integration.”
• MiR Fleet Enterprise Documentation v1.2 — no valueA sweep of the whole document finds no latency for entering Unavailable. The five minutes in §2.17.5 belongs in the band below: it is a resource-wait timeout measured from the loss of communication, and it is not a detection time.
• Tidewell — under two seconds, design targetA design target on our own published pages and not a measurement. Nothing has been measured on a machine and the first W1 prototype is under construction, so no cell in this band holds a measured number — ours included.

4 · Degraded operation

• VDA 5050 v3.0.0 — stop, at CRITICAL§4.1 — “If the mobile robot disconnects from the broker, it keeps all the order information and fulfills the order up to the last released node.” §6.9 — an unanswered permission request fails closed, and when the leaseExpiry is reached the releaseLossBehavior applies: §6.4.1.1 for zones (STOP, CONTINUE, EVACUATE) and §7.3 for corridors (STOP, RETURN), with STOP the default in both. STOP means the robot stops and sends a RELEASE_LOST error at level CRITICAL.
• MiR Fleet Enterprise Documentation v1.2 — continue, and after five minutes take ground§2.17.5 — six consequences. The robot keeps every resource it held, cannot be assigned new resources, missions, chargers or staging positions, cannot exchange collision-avoidance data, and continues “executing missions they were assigned before losing connection”. If it needs a resource it was not assigned, it waits until it reconnects “or until five minutes without any communication with MiR Fleet passes and the robot is permitted to continue the mission without waiting to be assigned resources”. Five minutes is a resource-wait timeout measured from the loss, not a detection latency.
• Tidewell — design targetAutomatic downgrade to Solo with no human action; the robot keeps working with a smaller planner and conservative traffic rules; no policy and no safety function runs off the robot; no checkpoint pushed mid-task. Every line of that is a design target.

5 · Reconnect

• VDA 5050 v3.0.0 — nothing statedNo robot-side reconnect behaviour appears in the document.
• MiR Fleet Enterprise Documentation v1.2§2.17.5 — “If the communication is ever re-established, the robot will revert to waiting for fleet resources like all other active fleet robots.” §2.22.2 — “Once reconnected, its site data is updated to the latest version on MiR Fleet.”
• Tidewell — design targetRe-sync begins on reconnect and the robot never blocks on upload.

6 · Re-sync

• VDA 5050 v3.0.0 — no procedureNo reconciliation procedure appears anywhere in the document, and §6.1.2 gives the reason: “the base cannot be changed. The fleet control shall therefore assume that the base has already been executed by the mobile robot.” An immutable released route leaves nothing to reconcile.
• MiR Fleet Enterprise Documentation v1.2 — one direction only§2.17.2, the supervisor-side case: “When MiR Fleet starts up again, all robots are re-evaluated and resynchronized before being considered as active robots.” §2.22: “The synchronization is only from MiR Fleet to the robots. Changes on robots are not synchronized back to MiR Fleet.”
• Tidewell — design targetAppend-only re-sync on reconnect. A design target; nothing measured.

• The document publishes a behaviour here, quoted or cited by clause number
• The document specifies nothing here
• Ours — and every Tidewell cell in this figure is a design target, with nothing measured on a machine

A third interface specification comes close and stops short. T/SSITS 204-2023《工业应用移动机器人与其调度系统的数据接口规范》, issued 2023-04-04 by the Shenzhen Robotics Standards and Testing Technology Society and the Mobile Robot (AGV/AMR) Industry Alliance, is free in full text on China's national group-standard platform and was read end to end [read]. It defines two offline states. 物理离线, physical offline: the robot stops sending state messages and no longer occupies map resources. 逻辑离线, logical offline: it stops receiving task instructions but still occupies them. It carries a fault code for network interruption, 0x1005. And it makes its state frame a heartbeat outright, §7.3.1: "此帧消息作为心跳帧用于判断通讯超时……默认上报周期为 1 秒" — a frame used to judge communication timeout, default reporting period one second. That is a default set against a maximum: VDA 5050's §6.6 allows up to 30 seconds between state messages, so the two figures are thirty apart and are not the same kind of number.

Both offline states are entered by a human. §7.3.9: "IMR 车辆自动模式共有三种基本状态：空闲，运行，暂停。人工干预共有两种基本状态：逻辑离线和物理离线。" Automatic mode has three states; the offline pair belongs to human intervention. There is no equivalent of CONNECTION_BROKEN and no behaviour stated on unexpected loss. A tighter heartbeat, a named purpose, still no timeout value.

Two more documents complete the set we read. MassRobotics' AMR Interoperability Standard — Version 1.0 as printed on the document's cover, a number secondary sources disagree on — has an operational state, "5.1.3.4 - Offline - no current messages", with no behaviour attached to it, and a §1 scope reading "Industrial mobile robots specifically excludes mobile robots used in education, entertainment, consumer, military, medical, surgical, and robots engaged in transport on the public highways." The American interoperability standard writes the hospital out of its own scope clause. Open-RMF's RobotMode.msg defines twelve modes and none is offline or disconnected; its one published number runs the other way, a hard-coded ten-second timeout in mutex_group_supervisor/main.cpp after which the supervisor drops a robot's claim, commented // TODO(MXG): Make this timeout configurable. OTTO Motors could not be assessed: its fleet documentation is not publicly readable. Across the service- and hospital-robot vendors searched on 11 September 2026, no published contract of this kind was located — which, after the paragraph above, is a statement about our searching and not about the field [searched, nothing found].

Two of the three interface specifications decline safety in their own words, and the third simply states no safety requirement. VDA 5050's exclusion is quoted above; MassRobotics "is not to be relied upon for any purposes related to safety"; T/SSITS 204-2023 carries safety fault codes and a safety-contour field, and not one clause that constrains what a machine may do. Three documents on three continents making the same architectural bet: the safety function lives on the vehicle, so losing the supervisor is not a safety event [inference]. That reading is ours. The clause text of the mobile-robot safety standards is still unread and we attribute nothing to them; the scope gap between those standards is a separate argument.

Why none of them has a number, and why none of them needs one

A VDA 5050 robot asks the fleet control for permission to enter a released zone. §6.9: "If no response is received within the time frame required by the application, the mobile robot shall behave as if the request had not been granted and shall not perform the operation that requires explicit permission." A disconnected robot's requests get no answer, so it fails closed.

A permission it already held before the link dropped carries an expiry. Same clause: "If a request is answered with 'REVOKED', or if the leaseExpiry is reached, the mobile robot shall act according to the releaseLossBehavior defined for the requested resource." Which defaults to STOP, with RELEASE_LOST at CRITICAL.

So what stops a VDA 5050 robot after it loses its supervisor is lease expiry, not disconnection detection. The specification never needs a detection time because its design does not use one.

The chain, end to end — VDA 5050 v3.0.0

1. 1. Request§6.9 — the mobile robot asks the fleet control for permission to occupy a released space. “If no response is received within the time frame required by the application, the mobile robot shall behave as if the request had not been granted.”
2. 2. Grant, carrying a leaseExpiry§6.9 — the permission the robot holds comes with an expiry time it is given up front.
3. 3. The link drops§7.7 — CONNECTION_BROKEN: “the connection between mobile robot and broker has unexpectedly ended”.
4. 4. The lease expires, on a clock the robot already holds§6.9 — “If a request is answered with ‘REVOKED’, or if the leaseExpiry is reached, the mobile robot shall act according to the releaseLossBehavior defined for the requested resource.” No message is needed for this to fire.
5. 5. releaseLossBehavior applies§6.4.1.1 for zones — STOP, CONTINUE, EVACUATE — and §7.3 for corridors — STOP, RETURN. STOP is the default in both, and “If not defined, the mobile robot is expected to STOP and report an error.”
6. 6. STOP, and a RELEASE_LOST error at level CRITICAL§6.6.5.4 — the error and its level. For corridors, §7.3: “Mobile robot shall stop and await manual intervention.”

Read down. Every link is a quoted clause, and not one of them mentions noticing.

Detection — not in the chainNo arrow leads into it, which is why no number is published for it. §6.5 names the mechanism — “The disconnection is detected via a heartbeat that is exchanged between the broker and the client” — and gives it no interval and no tolerance. §7.10's factsheet offers four timing slots for a vehicle to declare and fills in none, with a circular fallback to the main document. §6.9 hands the rest over: “The handling of timeouts and retries shall be defined during integration.” A regular-expression sweep for numeric time values over the whole 208,085-byte specification returns one line, the 30-second state-reporting interval in §6.6.

• A link in the chain, each one a quoted clause of VDA 5050 v3.0.0
• Off the chain: nothing points into it, and the specification publishes no value for it

The specification names the detection mechanism and leaves it empty. §6.5: "The disconnection is detected via a heartbeat that is exchanged between the broker and the client." Interval and tolerance appear nowhere in the document. §7.10's factsheet offers four timing slots a vehicle may declare and fills in none, with a circular fallback to the main document. §6.9 hands the rest over: "The handling of timeouts and retries shall be defined during integration."

The strongest form of the negative is checkable in one command. Run a regular expression for numeric time values over the 208,085-byte VDA5050_EN.md at tag 3.0.0 and it returns one line: §6.6, "The mobile robot state message shall be published when relevant events occur or at least every 30 seconds." One numeric time value in the whole specification, and it is a state-reporting interval, not a detection budget. The only other duration in the document is written in words, and it is an example of an action rather than a timing requirement: §6.2's "audio signal that lasts for five seconds".

The same reading found no reconciliation procedure anywhere in VDA 5050 — no re-sync, in any of the sections read. MiR is the exception in this set and publishes one, in one direction: §2.17.2 has the supervisor re-evaluate and resynchronize every robot on restart, and §2.22 states the constraint, "The synchronization is only from MiR Fleet to the robots." VDA 5050 has a reason for having none, §6.1.2: "Since MQTT is an asynchronous protocol and transmission via wireless networks is not reliable, the base cannot be changed. The fleet control shall therefore assume that the base has already been executed by the mobile robot." The released route is immutable and assumed executed, so after a partition there is by construction nothing to reconcile — the same move as an append-only design, reached from the opposite direction [inference].

Our own contract, and the part of it we have not written yet

A published degraded-mode contract is one of the things a companion piece says a site memory has to guarantee. Ours is on Crew and on Brain, and every line of it is a design target: link-loss detection under two seconds, automatic downgrade to Solo with no human action, append-only re-sync on reconnect, no policy and no safety function off the robot, no checkpoint pushed mid-task. Nothing on that list has been measured on a machine. Each becomes a measured value when a test date sits beside it.

Which makes the honest claim narrower than the one this evidence invites. We do not publish a detection time. We publish a design target for one, and nobody we have found publishes a detection time, ourselves included. The sentence on our own page — that no vendor and no standard we have found publishes a link-loss detection time to compare ours against — survived this pass unchanged. What MiR publishes is a resource-wait timeout, which is a different quantity.

The research behind this article repaired one of our own pages. The architecture diagram on the Brain page carried "link loss under 2 s → Solo" and "reconnect → append-only re-sync" as edge labels with no design-target marker inside the figure, in both language editions. The qualifying sentence sat eight lines below, in prose a screenshot does not capture. Four strings, corrected on 11 September 2026: those labels now read "(design target)" inside the diagram.

Then the gap. VDA 5050 distinguishes a coordinated disconnect from an unexpected one and adds HIBERNATING on top. T/SSITS 204-2023 has two coordinated offline states. MiR has Standalone mode. We publish one transition: link loss → Solo. A robot told to go offline — entering a lift, a scheduled radio-quiet window — is a different event from a robot whose link died, and a hospital will ask about both. We have not published that distinction, and we should.

One standard addresses the building rather than the robot. The Singapore Standards eShop listing for SS 713:2025 describes its scope as specifying "the requirements for integrating robots with lifts and robots with automated doorways", covering "abnormal conditions such as power outage or disruption". It costs S$36.10 excluding GST, nobody has bought it, and nothing here is attributed to a clause of it — the listing's abstract is all we have read.

So the third-meeting question is no longer what happens when the link drops. A standards body and a vendor have both written that down. It is which of the two behaviours your robot does, whether the other vendor's robot in the same corridor does the other one, and — since no document specifies when a robot notices — what number, if any, either vendor will put in a contract. Ask for the clause, not the claim. Two documents can hand you one. Nobody can hand you the answer about the corridor yet.