A declarative open standard for describing mobility services
MSD enables any mobility service provider to describe their complete offering — service areas, vehicle types, fare structures, booking rules, and settlement parameters — as a single, machine-readable JSON file.
No API required. No bilateral integration. Publish a file, become discoverable.
Integrating a small mobility provider (community bus, bike-sharing, on-demand shuttle) into a booking platform takes months and costs tens of thousands. Large operators dominate digital platforms; smaller services remain invisible.
Existing standards cover parts of the landscape — GTFS for timetables, GBFS for shared vehicles, TOMP-API for booking — but none allow a provider to describe their full service in a single, self-contained file that any engine can interpret.
MSD is a static JSON file that contains everything needed to discover, understand, price, and initiate booking of a mobility service. Think of it as the GBFS for on-demand and multimodal services.
{
"msd_version": "0.1.0",
"provider": {
"provider_id": "ch-mybuxi-emmental",
"name": "mybuxi Emmental"
},
"services": [{ "service_type": "on_demand", "mode": "bus" }],
"fare_structures": [{ "currency": "CHF", "rules": [{ "price": 5.00 }] }],
"booking_rules": { "advance_booking": { "minimum_minutes": 30 } }
}Try it in your browser — paste an MSD file into the hosted validator. It runs entirely client-side; your file is never uploaded.
Prefer the command line? Validate locally against the reference implementation:
node validator/validate.js examples/ch/mybuxi-emmental.msd.jsonThe hosted and CLI validators share one validation core, so they always agree. Both check schema conformance for the selected MSD version — not business or semantic validity.
| Document | Description |
|---|---|
| Concept Paper | Full technical vision, data model, and use cases |
| Governance Framework | How MSD is governed: commitments, process, licensing |
| Conventions | C1 (null vs zero) and C2 (external code-list registry) |
| JSON Schema | The v0.1.0 schema (JSON Schema Draft 2020-12) that files are validated against |
| Reference validator | AJV-based CLI; the same validation core as the hosted validator |
| Examples | Validated MSD files (e.g. examples/ch/mybuxi-emmental.msd.json) |
| MSD ↔ NeTEx comparison | How MSD's provider layer relates to the NeTEx system layer |
| Coverage & gap matrix | What v0.1.0 expresses vs. recorded v0.2.0 candidates |
| MSD → GTFS-Flex engine | Generates a GTFS-Flex discovery feed from an MSD file |
| Producer flow (schematic, non-normative) | Reference data path from self-description to validated file (illustrative phone screens) |
MSD is in its founding phase (v0.1.0-draft) — the specification is published as a Request for Comments. The foundation is in place and working: the v0.1.0 JSON Schema, a reference validator (CLI + hosted), and validated examples. The producer-to-consumer path is exercised end-to-end — a validated mybuxi example is read by an MSD → GTFS-Flex engine that emits a standard discovery feed.
We are actively seeking:
- Technical reviewers — Does the data model cover your use case?
- Pilot providers — Describe your service as an MSD file
- Engine developers — Build tools that consume MSD files
- Standards experts — Help align with GTFS, GBFS, NeTEx, TOMP-API
All contributions are welcome. See CONTRIBUTING.md for how to get involved.
Contributions to the specification are licensed under CC BY-SA 4.0.
Contributions to code are licensed under AGPL-3.0.
All contributions require a Developer Certificate of Origin sign-off.
- Specification (text, schemas, examples): CC BY-SA 4.0
- Code (validators, converters, tools): AGPL-3.0
MSD is governed as an open community project under LeaLa.
Maintainer: Thomas Teichmüller — thomas@leala.io