Chapter 6 · EV3280

MDS: Open-Source Digital Infrastructure for Right-of-Way Governance at Global Scale

Date collected: 19 June 2026

Summary

MDS open standard, LADOT-originated, OMF-stewarded Nov 2019; 6 APIs, v2.0.2 June 2025; 200+ cities, 21 countries, 50+ MSPs — regulatory relationships now mediated via data APIs, not permit conditions

Headline Finding

The Mobility Data Specification (MDS), originally created by the Los Angeles Department of Transportation and transferred to the Open Mobility Foundation in November 2019, has become the dominant open-source digital infrastructure for right-of-way governance of shared and autonomous mobility worldwide. More than 200 cities and public agencies across 21 countries use MDS, and over four dozen mobility service providers have implemented it — meaning a single open standard now mediates the regulatory relationship between cities and operators at global scale. This is direct evidence that the spatial-allocation and legitimacy levers of urban mobility governance are increasingly exercised through standardised data APIs rather than traditional permit conditions, and that the instrument design choices embedded in MDS propagate across hundreds of jurisdictions simultaneously.

Detail

MDS is a set of six APIs — Provider, Agency, Policy, Geography, Jurisdiction, and Metrics — first released incrementally from June 2018 (Provider) through March 2021 (Jurisdiction and Metrics). The current release is version 2.0.0, with the latest patch release 2.0.2 dated June 4, 2025, and 2,151 commits across the repository’s history. The project has 742 GitHub stars, 249 forks, and 87 watchers. More than 200 cities and public agencies across 21 countries are known to use MDS. Over four dozen mobility service providers (MSPs) worldwide use MDS. Dozens of third-party software companies have built tools on the standard. MDS was originally created by LADOT and stewardship was transferred to the Open Mobility Foundation in November 2019. The specification covers dockless scooters, bicycles, mopeds, car share, delivery robots, fixed-route services, shuttles, fleets, and passenger services (including taxis, TNCs, and microtransit). The Policy API (released October 2019) allows agencies to share and validate policy digitally — described in the source as ‘policy-as-code’. The Geography API enables geofencing for regulatory purposes. The Jurisdiction API (March 2021) allows cities to coordinate boundaries with each other and with providers. MDS requires all compatible Provider and Agency feeds to also expose a public GBFS feed for micromobility and car share modes, with GBFS 3.0 or greater advised. The OMF provides sample permit language and MDS Policy Language Guidance for cities writing MDS into operating policy. Documented use cases include vehicle caps, distribution/equity requirements, injury investigation, restricted-area enforcement, resident complaint validation, and infrastructure planning.

Governance Implication

  1. SPATIAL-ALLOCATION LEVER — MOVED AT SCALE: The Policy and Geography APIs operationalise spatial-allocation governance (vehicle caps, geofenced restricted areas, equity distribution requirements) as machine-readable rules consumed directly by operator systems. Adoption across 200+ cities means this lever is now routinely pulled through code rather than paper permits, compressing enforcement latency and raising the floor of regulatory capability for smaller cities that lack specialist staff.
  2. LEGITIMACY LEVER — STANDARDISATION AS DOUBLE-EDGED INSTRUMENT: A single open standard adopted by 21 countries concentrates legitimacy-shaping power in the OMF’s Working Group governance process. Cities that adopt MDS wholesale inherit instrument choices made elsewhere; cities that deviate face interoperability costs. The legitimacy lever is moved both by the standard’s existence (demonstrating accountable, auditable regulation) and by the risk that local democratic preferences are subordinated to a global technical consensus.
  3. FISCAL LEVER — INDIRECT BUT REAL: Vehicle-cap enforcement and trip-data verification enabled by the Provider API underpin permit-fee and per-trip-fee collection. Accurate operational data reduces the information asymmetry that allows providers to under-report fleet size or trip volumes, protecting municipal fiscal yield from shared-mobility programmes.
  4. INSTRUMENT DESIGN PROPAGATION RISK: Because MDS Policy Language Guidance and sample permit language are distributed to cities as templates, instrument design choices — including what data fields are required, what privacy protections are built in, and what use cases are in scope — propagate across hundreds of jurisdictions. A design flaw or a gap (e.g., incomplete coverage of autonomous delivery robots or robotaxi modes) becomes a systemic governance gap at global scale, not a local one.
  5. CHAPTER 6 INSTRUMENT MATURITY: MDS represents one of the most mature ‘rules and instruments’ examples in the C

AM knowledge base — an open, versioned, multi-modal, two-way API standard with formal governance, privacy guidance, and a documented upgrade path. It is a reference case for chapter 6 on what digital regulatory infrastructure looks like when it reaches operational scale, and a benchmark against which newer AV-specific data-sharing proposals should be assessed.

Sources

GitHub repository: openmobilityfoundation/mobility-data-specification, https://github.com/openmobilityfoundation/mobility-data-specification, README.md (main branch), accessed 2025. Key passages: ‘More than 200 cities and public agencies across 21 countries around the world are known to use MDS’; ‘Over four dozen mobility service providers (MSPs) around the world use MDS’; ‘MDS is an open-source project originally created by the Los Angeles Department of Transportation (LADOT). In November 2019, stewardship of MDS and the ownership of this repository were transferred to the Open Mobility Foundation’; ‘The latest MDS release is in the main branch’ (version 2.0.0, patch 2.0.2, June 4 2025); ‘First released in June 2018’ (Provider API).

Thread