A delivery robot reaches the right building.
It recognizes the entrance, avoids pedestrians and follows its planned route.
Then it stops.
The door requires an access credential. The lift has no interface it can use. The accessible entrance is around the corner, but its map does not identify that connection.
The navigation worked. The delivery failed.
This is an overlooked challenge in Physical AI: a machine can understand its surroundings well enough to move, yet still lack the context needed to complete a service.
For property owners, campus operators and city planners, that changes the investment question.
Before asking how many robots a place can accommodate, we should ask whether its physical environment can communicate the information those robots need.
What does a machine need to know about a place?
A human entering a hospital can interpret signs, ask for directions and negotiate an unexpected closure.
A robot needs those situations translated into usable information.
Which entrance connects to the destination? Is the corridor wide enough for this machine and its payload? Does the lift serve the required floor? Is access permitted at this time? Where should the robot wait if the route becomes unavailable?
A conventional map answers only part of that.
Machine-readable physical context connects geometry with meaning, current conditions and operating rules.
A doorway becomes more than an opening in a wall. It has an identity, clearance, access conditions, operating status and a responsible owner.
A route becomes more than a line. Its suitability depends on the robot’s dimensions, turning capability, task and the people sharing that space.
The same corridor may be suitable for a small delivery robot and unsuitable for a larger inspection platform.
Readiness is therefore specific to the machine and the service.
This is already taking shape in buildings
South Korea’s NAVER provides a useful reference through its 1784 building. NAVER describes an operating robot delivery service supported by building infrastructure and its robotics platform. This is a bounded environment where robots and the building have been developed to work together.
In its July 2026 account of taking this approach to Japan, NAVER explains that implementation begins with a building digital twin, defined robot routes and service points. Its ARC platform then connects service systems, building infrastructure and operational control.
Open-RMF provides another practical reference. The open-source framework supports interoperability between robot fleets and infrastructure such as doors, lifts and building management systems.
These examples support a clear conclusion: useful autonomy involves integration with the environment.
They do not establish that an entire city is ready for unrestricted robotic operation. They show how the problem can be addressed within defined sites.
Three layers make the context usable
For an owner evaluating a deployment, I would organize the problem into three layers.
1. Physical suitability
Establish what the machine can actually traverse.
This includes verified routes, slopes, surface conditions, clearances, turning spaces, loading points and indoor–outdoor transitions.
GIS can connect the wider site. BIM can supply building and asset relationships. Reality capture can check whether the physical environment still matches the records.
These sources need a consistent spatial reference. A detailed building model is of limited use if its entrance does not align with the outdoor navigation map.
2. Operational availability
Establish what is usable now.
A suitable lift may be undergoing maintenance. A loading area may be occupied. A corridor may be temporarily closed.
Building systems, maintenance records, sensors and authorized staff updates can contribute this information.
Each update should carry its source and time. “Available” is a weak statement if nobody knows when it was last checked.
The robot’s own perception remains essential for immediate obstacles. Shared context helps it anticipate constraints beyond its current view.
3. Permission and responsibility
Establish what this robot may do for this task.
Physical access does not automatically grant operational permission.
A hospital delivery robot might be allowed in a public corridor but restricted from a clinical area. A campus inspection robot might operate only within an approved window.
Permissions should connect robot identity, task, location and time, with a clear process for withdrawal and escalation.
The system also needs to know who can resolve an exception.
A hospital delivery makes the difference clear
Consider a hypothetical robot carrying supplies between two hospital departments.
Its route crosses a service door, uses a lift and passes through a corridor.
A static map shows that the journey is possible.
Operational context reveals that the lift is unavailable and the corridor is reserved for an urgent movement. The robot waits at an approved location, requests an alternative route or escalates to a person.
The outcome depends on more than recognizing a corridor. It depends on understanding how that corridor participates in the hospital’s work.
This is where a digital twin can become useful: connecting physical objects to current conditions, dependencies and decisions.
A convincing 3D view alone cannot provide that connection.
Start with one service in one bounded environment
Citywide readiness is too broad a starting point.
A more practical pilot is one repeatable task within a hospital, industrial campus, airport, university or commercial development.
Define the task first. Then assess the route, access interfaces, communications, charging, operating permissions and recovery procedures it requires.
Measure completed tasks, human interventions, waiting time, recovery time and disruption to other users.
A successful demonstration is encouraging. Consistent service across ordinary operating conditions is the stronger test.
Avoid reducing readiness to one headline score. A missing lift interface can block the service even when every other category performs well.
Owners need to see the blocking dependencies.
Who maintains the machine’s understanding?
A surveyed route can become outdated after maintenance, construction or a change in access policy.
Someone must own that change.
The deployment therefore needs a process for recording closures, approving updates, withdrawing permissions and resolving disagreements between mapped information and observed conditions.
When critical context is missing or stale, the robot needs a defined response appropriate to the task: wait, reroute or request assistance.
Shared context also needs controlled access. Providing route information should not expose building credentials or unrestricted infrastructure controls.
People remain central. Robot routes should respect pedestrian movement, accessibility and the primary purpose of the facility.
A new geospatial deliverable
My view is that this creates an opportunity for geospatial and infrastructure teams to deliver a maintained description of where machines can operate, under which conditions, and with what supporting evidence.
That work connects survey control, GIS, BIM, reality capture, asset identity and operational integration.
Its commercial value should be tested through fewer failed tasks, less manual recovery and more reliable service.
A robot-ready city will emerge through many such environments.
The deciding factor may be whether a place can reliably tell a machine what is physically possible, currently available and permitted.
Before buying more autonomy, owners should examine how much of that knowledge exists only in people’s heads.
That is where the readiness work begins.
