The Open Mobility Foundation released Curb Data Specification 1.1 on November 3, 2025, built on a year of testing across the SMART Curb Collaborative — ten cities running curb digitisation pilots whose real-world experience shaped the revision. The specification is backwards compatible with 1.0 and the code went to GitHub on announcement.
Ten months in, with a second Collaborative cohort of fourteen cities and one county now working with it — a larger and more geographically varied group including European and Canadian participants — there is enough deployment history to say something more useful than a feature list.
What 1.1 added
Seven additions, in rough order of how much they change what a city can do:
Real-time events. The headline. Curb operators can push activity data to agencies as it happens rather than reporting it in batch. This is the change that converts CDS from a description of curb regulations into a live operational feed.
Curb objects. A model for the physical and digital assets that make up the kerb — signs, meters, EV chargers, bike corrals. Before this, a city could describe the rules governing a segment but not the things installed along it.
Enforcement. Violations and citations, including double parking, captured in the specification rather than in a separate enforcement system with its own schema.
Payment methods. Multiple payment types, methods, and transaction identifiers, which is what makes flexible and transparent kerb pricing describable in a standard way.
External references. Interoperability with WZDx, CWZ, GBFS, GTFS, and MDS. A kerb segment can now reference the work zone that closed it or the transit stop beside it, in the standards those domains already use.
Computer vision and vehicle properties. Expanded vehicle attributes — identifiers, propulsion type, size, permits — carrying confidence levels, which is the correct way to represent a machine-vision observation.
Custom attributes. Policy and kerb colour tracking, event metrics, and extended detail on curbs, policies, rules, and events.
The contributor list is worth reading as a signal: CurbIQ, Populus, Umojo, INRIX, Passport, SFMTA, Omaha, and the Agence de mobilité durable de Montréal, alongside the USDOT SMART Curb Collaborative cities. That mix of vendors and agencies is why the specification describes things vendors can actually implement.
Why real-time events matter more than they sound
A curb regulation is static. “Loading only, 7am to 10am, Monday to Friday” is a rule, and CDS 1.0 could express it. What CDS 1.0 could not express is what is happening at that kerb right now.
The gap is the difference between a kerb inventory and kerb management. A city that knows its rules can publish them, print them on signs, and feed them to navigation apps. A city that knows its occupancy in real time can do the things that actually motivate kerb digitisation programmes: allocate space dynamically, price it responsively, dispatch enforcement to where the violation is rather than on a patrol route, and measure whether a policy change worked.
Real-time events are what make the second set possible through a standard interface rather than through a bespoke integration with each vendor.
That matters commercially. The reason cities push for standards in this domain is not aesthetic — it is that a bespoke integration makes the vendor relationship very hard to exit. A city that receives real-time curb events over a specified interface can change providers without rebuilding its data pipeline. That is the entire argument for CDS, and 1.1 is the release that extends it to the operational layer where lock-in was strongest.
What 1.1 does not settle
Adoption is not the same as publication. A specification exists when it is published. It becomes useful when enough providers implement it and enough cities require it in procurement. CDS is further along on this than most mobility standards at the same age — the vendor contributor list is meaningful — but a city cannot yet assume any given kerb-technology vendor supports it. The procurement question remains “which version, which endpoints, demonstrated where.”
The specification does not produce the data. CDS describes how to exchange curb occupancy and events. Something still has to detect them — cameras, sensors, payment transactions, or operator reporting. A city with CDS support and no detection layer has a well-specified way to transmit nothing. The cost and the difficulty are in the sensing, and they did not change.
Privacy governance is a local matter. Real-time events describing vehicles at kerbs, with computer-vision-derived attributes attached, is exactly the data class that draws scrutiny. The specification’s confidence-level handling is good practice; retention policy, aggregation thresholds, and disclosure rules are the city’s to write, and a standard interface makes them more necessary, not less, because the data becomes easier to move.
MDS’s history is the relevant precedent. The Mobility Data Specification went through a multi-year argument about whether granular trip data from private operators to public agencies was appropriate, and it ended in litigation. Curb events sit in adjacent territory. Cities adopting CDS 1.1’s real-time capability would do well to settle their data-handling posture before the deployment, not after.
What to watch from the 2026 cohort
The second Collaborative — fourteen cities and one county, spanning Europe and Canada as well as the United States — is the first real multi-jurisdiction test of the 1.1 features. The first cohort’s testing produced 1.1; this cohort’s testing will produce whatever comes next.
Three things worth watching: whether real-time event feeds actually get stood up in production or remain pilot-scoped; whether the external-reference links to WZDx and GTFS get used, which would indicate kerb data is being consumed by systems outside the kerb programme; and whether any of the participating cities put CDS conformance into a procurement requirement. That last one is the signal that a standard has arrived. Everything before it is preparation.
