The Open Mobility Foundation’s Curb Data Specification reached version 1.1, approved by the OMF Board and announced on November 3, 2025. It is a backwards-compatible release, which means agencies already running CDS 1.0 are not facing a migration — but the additions change what the standard is capable of describing, and one of them changes the timing model entirely.
The headline addition is Real-time Events: the ability for operators to push activity data to an agency as it happens, rather than in the retrospective batches CDS 1.0 was built around. For freight specifically, this means a commercial vehicle operator can notify the city when a delivery starts and when it completes. That is a small change in the data model with fairly large operational implications, and it is worth being precise about which of them are real today and which are still aspirational.
If you are new to the standard itself — what it covers, how it differs from MDS, and why loading zones were the early focus — start with our explainer on Curb Data Specification 1.0. This piece covers what 1.1 adds on top.
What 1.1 actually adds
Five capability areas expanded in this release:
- Curb Objects. The specification now describes the physical and digital assets that make up the curb — signs, meters, EV chargers, bike corrals. Previously the standard described zones and activity; it now describes the furniture, which is what maintenance and asset management actually run on.
- Real-time Events. Operators can share activity data with agencies as it occurs, enabling responsive management rather than after-the-fact analysis.
- Enforcement and Violations. The standard can capture when and where violations or citations occur, including double parking specifically, so cities can measure compliance rather than infer it.
- Payments. Support for multiple payment types, methods, and transaction identifiers.
- Vehicle detection and attributes. Camera-based sensing and automated detection are now accommodated, with expanded vehicle properties covering identifiers, propulsion type, size, and permit details.
The release came out of OMF working groups including the SMART Curb Collaborative, with contributions from CurbIQ, Populus, Umojo, INRIX, Passport, SFMTA, the City of Omaha, and Montreal’s transit authority. That contributor list is worth noting: it is a mix of vendors and operating agencies, which tends to produce specifications that survive contact with procurement.
Why real-time freight events are the consequential piece
Under CDS 1.0, a city could learn that its loading zones were oversubscribed. It generally learned this weeks later, from aggregated occupancy data, and could respond by changing a regulation or adding capacity. That is a planning loop, and it is useful — but it operates on a timescale of months.
A real-time delivery start/complete signal changes the available loop from planning to operations. Three things become possible that previously were not:
Dynamic allocation. If the city knows a loading zone is currently occupied and for how long it has been, it can route the next arriving vehicle elsewhere rather than leaving the driver to double-park while searching. This is the single most direct attack on the behaviour the data also now lets you measure — double parking is called out explicitly in the new violations model.
Verification instead of estimation. Enforcement and curb-pricing decisions currently rest on sampled occupancy studies. An event stream of actual dwell durations replaces an estimate with a census, which matters most where the policy is contested and the sample size is what opponents attack.
Compliance as a two-way exchange. An operator that reports its own delivery events gains a defensible record of compliant behaviour. That is the basis of the permit structures several cities have been trying to build — preferential curb access in exchange for data sharing — and it does not work without a standard event format that both sides trust.
The part that isn’t solved
Two honest limitations, because the announcement does not dwell on them.
First, real-time events require the operator to send them. A specification defines the format; it does not create the incentive. Fleet operators have thin margins on urban delivery and no default reason to instrument their drivers’ workflow for a city’s benefit. The cities that get useful freight event data will be the ones that attach something the operator wants — guaranteed zone access, reduced citation exposure, a permit tier — to the act of reporting. Where that exchange is absent, the API will exist and stay empty.
Second, the data quality problem shifts rather than disappears. Self-reported delivery start and completion times are operator-controlled, and an operator with an interest in appearing compliant has an interest in the timestamps. Camera-based detection, also newly accommodated in 1.1, is the cross-check — but running both means running two systems, and the sensing side carries procurement cost and privacy review that the reporting side does not.
What a planner should do with this now
The practical sequencing has not changed much from the 1.0 advice, with one addition:
- Do not migrate for its own sake. 1.1 is backwards compatible. If your CDS 1.0 implementation is working, the question is which of the five new capability areas answers a question you currently cannot answer.
- Start with Curb Objects if you have an asset problem. Of the five additions, this is the one with the clearest immediate payoff and no dependency on third-party cooperation. It is your own inventory.
- Treat real-time events as a partnership programme, not an integration. Scope the incentive before scoping the API. If you cannot name what the freight operator gets, the technical work is premature.
- Write standards-based export into procurement. The vendor market around curb data is consolidating, and CDS conformance is the main practical protection against a platform that holds your curb inventory hostage.
CDS 1.1 is a competent, incremental release that closes real gaps — asset description, enforcement measurement, payment detail — and adds one genuinely new capability in real-time events. The specification side of the freight problem is now largely solved. The incentive side is where cities will actually succeed or fail.
Frequently Asked Questions
What is new in CDS 1.1?
Five areas: Curb Objects (physical and digital curb assets), Real-time Events, enforcement and violations data including double parking, expanded payment types and transaction IDs, and support for camera-based vehicle detection with richer vehicle attributes.
Is CDS 1.1 backwards compatible with 1.0?
Yes. It was released as a backwards-compatible update, so existing CDS 1.0 implementations do not require migration to remain valid.
How do real-time events work for freight?
A commercial vehicle operator can push an event to the agency when a delivery begins and when it completes, rather than the agency reconstructing that activity later from aggregated occupancy data.
When was CDS 1.1 released?
The Open Mobility Foundation announced Board approval of CDS 1.1 on November 3, 2025, following working-group development that included the SMART Curb Collaborative.
Does adopting real-time events require new sensors?
Not necessarily — operator-reported events need no city-side hardware. Camera-based detection is separately supported in 1.1 and is mainly useful as a cross-check on self-reported data.
