Autonomous vehicles enter private property through permission, not mapping. The property defines who may enter and what they may do; the fleet validates the vehicle can do it; a coordination layer records the reservation, access rules, and session evidence.
An autonomous vehicle enters private property when three things line up: the property grants permission, the fleet confirms the vehicle is capable of the task, and a reservation plus access record exists for that visit. Mapping does not grant entry. A vehicle can know the geometry of a lot in perfect detail and still have no right to be in it. Private-site AV access is a permission-and-record problem, not a navigation problem. XoomPark sits in that gap: it coordinates the reservation, the access rules, the check-in, and the evidence that the session happened correctly.
Mapping tells a vehicle where it can drive, not where it is allowed to be
These are two different questions and people collapse them constantly. HD mapping and localization answer “can this vehicle physically navigate this space?” Permission answers “is this vehicle allowed in this space, for this purpose, right now?” A robotaxi can have centimeter-accurate maps of a private garage and zero authorization to enter it. The gate is closed, the operator has no record of the visit, and there is no proof the vehicle ever followed the rules inside.
Most AV discussion lives on the navigation side because that is the hard autonomy problem. Access is treated as solved or trivial. It is neither. As fleets move off public roads into private sites for staging, overnight storage, charging-adjacent queueing, and recovery holding, “who said this vehicle can be here, and what is it allowed to do” becomes a daily operational question with no native home in the autonomy stack.
The plain-English definition
Private-site AV access is the set of rules, permissions, and records that govern an autonomous vehicle entering, using, and leaving a piece of private property. It covers four things: whether the vehicle is permitted to enter, what it is allowed to do once inside (stage, charge-queue, hold, get cleaned, get inspected), whether the space and service are available at that time, and what evidence proves the visit followed the rules.
It is distinct from autonomy (driving), from mapping (geometry), and from dispatch (which trip a vehicle takes next). Access is the layer that turns “the vehicle can get there” into “the vehicle is allowed there, the visit is reserved, and the session is on record.”
Why private-site access becomes a real problem
Robotaxi fleets are leaving the depot. A single fixed depot does not solve distributed city operations: vehicles need to stage near demand, queue near chargers, hold during incidents, and reset between trips in many locations, not one. Each of those locations is private property owned by someone who is not the fleet. These between-trip ground tasks are not hypothetical: Waymo's own fleet-operations partners describe their work as fleet operations, facilities, charging, depot operations, maintenance, cleaning and fueling for the driverless fleet (Transdev North America; TechCrunch on Moove, Dec 2024).
Without a permission-and-record layer, every off-depot site is an ad-hoc arrangement: a phone call, a shared gate code, no availability check, no session log, and no evidence if something goes wrong. That does not scale to a fleet making thousands of stops a day across a metro. Property owners will not hand out blanket access. Fleet operators (Waymo, Zoox, and the operations partners around them) need defensible records of where their vehicles went and what they did. The access layer is where both sides get what they need.
How private-site AV access works: permission, capability, coordination
Three parties, three jobs. The property defines permission. The fleet validates capability. A coordination layer records the reservation, access, workflow, SLA, and evidence. Keep these separate and the model stays clean.
The property owner (a parking operator, a real-estate owner, an eMobility site host) sets the rules: which zones, which hours, which services are offered, what a vehicle must do at the gate, what is off-limits. The fleet operator confirms the specific vehicle assigned to a visit can actually perform the task and meet the rules. The coordination layer is where a reservation is created against real availability, the access rules are attached to that reservation, the check-in and check-out are logged, exceptions are handled, and a session record is produced as proof.
XoomPark is the coordination layer. It is not the autonomy stack, not the mapping vendor, not the dispatcher deciding the vehicle's next trip, and not the property owner setting the rules. It records and coordinates the access that the property grants and the fleet uses.
Who needs an access layer
Four groups have a direct stake in private-site AV access.
Property owners and parking operators have space and want to turn it into AV-ready capacity without giving away uncontrolled access. They need permission rules they set, availability they control, and a record of every visit. Fleet operators need trusted off-depot sites with reservations they can rely on and evidence they can audit. HD mapping and localization teams need the access layer to exist so their maps lead somewhere a vehicle is actually allowed to go. Site hosts offering charging-adjacent queueing or recovery holding need their access conditions enforced and logged, not assumed.
What mapping provides vs what access coordination provides
This is the core of the page. Mapping and access are complementary, not competing, and the gap between them is where most operational failure hides. The table below splits the two and names what neither the map nor the autonomy stack supplies on its own.
| Question | HD mapping / localization provides | Permission & access coordination provides | The gap if you only have mapping |
|---|---|---|---|
| Can the vehicle physically navigate this space? | Yes: geometry, lane lines, drivable surface, fixed obstacles | Not its job | None: this is mapping's strength |
| Is the vehicle allowed to enter this property? | No: a map does not grant rights | Yes: permission set by the property, attached to a reservation | Vehicle knows the layout but has no authorization |
| What may the vehicle do once inside? | No: maps do not encode permitted actions | Yes: allowed services and zones per the property's rules | No definition of permitted vs prohibited use |
| Is the space or service available right now? | No: maps are static | Yes: live availability against reservations | Vehicle arrives to a full or closed site |
| Did the visit follow the rules? | No: maps do not log sessions | Yes: check-in/check-out, exception handling, session evidence | No proof, no audit trail, disputes unresolvable |
Original research: the four records that make an access event auditable
In our access-coordination model, we decompose a single private-site AV visit into four records that have to exist for the visit to be defensible after the fact. A generic “AV parking” framing collapses all four into “the car parked.” That collapse is exactly why off-depot access fails to scale.
The four records are: the reservation record (this vehicle, this site, this service, this time window, against real availability), the access record (the permission rules the property attached and the gate/zone conditions the vehicle had to meet), the session record (the check-in, the actual use, any exception, the check-out), and the evidence/audit record (the proof the session matched the reservation and the rules, suitable for SLA and billing review).
This four-record decomposition is presented as an illustrative coordination model, not a claim about a deployed XoomPark dataset. XoomPark is not citing any pilot count or number of sites scored here; the records describe how a defensible access event should be structured, not measured results from live operations.
What XoomPark does and does not do for private-site access
XoomPark coordinates access. It does not grant it, drive into the site, or map the property. The split below is deliberate and load-bearing for this category.
| XoomPark does | XoomPark does not |
|---|---|
| Record reservations against real site availability | Define the property's permission rules (the owner does that) |
| Attach the property's access rules to each reservation | Drive, navigate, or localize the vehicle (the autonomy stack does that) |
| Log check-in, check-out, and exceptions per visit | Build or maintain HD maps |
| Produce session and evidence records for SLA and audit | Decide the vehicle's next trip (dispatch does that) |
| Qualify and score private sites as AV-ready ground nodes | Replace fleet operators, charger owners, or maintenance providers |
Not for you if you run one fixed depot you fully control
If your entire AV operation runs out of a single depot you own and control, and your vehicles never need to enter property you do not own, you do not need a distributed access-coordination layer yet. You already control permission, availability, and records inside your own four walls. The access problem XoomPark solves appears when vehicles leave that controlled site and start using private capacity owned by others across a metro. Until then, this is solving a problem you do not have.
Frequently asked questions
How do AVs access private property?
An AV accesses private property when the property owner grants permission, the fleet confirms the vehicle can perform the intended task, and a reservation with attached access rules exists for the visit. The vehicle then checks in against that reservation, uses the site under the property's rules, and checks out, producing a session record. Mapping enables navigation but does not grant access.
Does XoomPark replace HD maps?
No. HD maps tell a vehicle where it can navigate; XoomPark records where a vehicle is allowed to be and what it is allowed to do there. The two are complementary. A map without an access layer leads to a site the vehicle has no right to enter; an access layer assumes the autonomy stack and maps already handle driving.
What are permissioned AV zones?
Permissioned AV zones are areas of a private site where the property owner allows specific autonomous-vehicle actions (staging, charge-adjacent queueing, holding, cleaning) under defined conditions. The permission is set by the property, attached to a reservation, and enforced and logged per visit, so a vehicle's allowed and prohibited areas are explicit rather than assumed.
Does XoomPark certify AV safety or perform maintenance?
No. XoomPark does not certify autonomy, validate vehicle capability, or perform maintenance, cleaning, or charging itself. It coordinates reservations, access rules, session records, and evidence. Capability validation stays with the fleet operator; physical services stay with the property and its service providers.
Related pages
AV ground services: the layer fleets need between trips →
AV-ready ground nodes: turning private sites into trusted fleet capacity →
AV-ready SLA evidence: proving the session happened correctly →
How private sites become AV-ready: the site scorecard →
Off-depot fleet support for distributed robotaxi operations →
Private-site access for parking operators →
Private-site access for real-estate owners →
Request an AV-ready site scorecard
If you own or operate a private site and want to know whether it can become an AV-ready ground node, request an AV-ready site scorecard. It assesses your site against the access, availability, workflow, and evidence requirements fleets need before they will route vehicles to off-depot capacity. Request an AV-ready site scorecard.