Open data standard · v0.1.0-draft
VeloPair is a small open standard: four JSON objects that describe a rider, how they actually ride, a bike, and how well the two match. Any app can produce them. Any engine can score them. The standard defines data, never scores.
{ "rider": { "body": { "height_cm": 178, "inseam_cm": 84 } }, "ride_profile": { "surface_mix": { "gravel_pct": 40 } }, "bike": { "identity": { "brand": "Example Cycles", "size": "56" }, "geometry": { "stack_mm": 591, "reach_mm": 384 } }, "compatibility": { "engine": { "name": "any-engine-you-like" }, "score": 91 } }
Runs in your browser; nothing you enter is sent anywhere. Scores come from velopair-reference-engine 0.1.0, the open, non-normative engine in the spec repository. Your inputs form a valid Rider document and each result is a valid Compatibility document. The four bikes are fictional. Download your rider.json
| 0 | Open standards describe the rider, their riding style, or rider-bike compatibility. The slot VeloPair fills was empty. The primary-source research checked three independent ways. |
| ~9 | Proprietary fitting and sizing systems match riders to bikes today. The demand is proven. The data stays locked inside each one. |
| 2 | Industry standards describe bicycle product data. VeloPair maps onto them instead of redefining geometry. |
| 3 | Activity formats record what happened during a ride. None carry a portable rider profile. The Ride Profile is the aggregate layer above them. |
| Object | What it holds | Example fields |
|---|---|---|
| Rider | Body measurements, physiology and intent. No name, no contact data, by design. | height_cminseam_cmsit_bone_width_mmftp_wflexibility |
| Ride Profile | How someone measurably rides, derived from recorded rides instead of a questionnaire. | typical_ride_distance_kmavg_speed_kmhelevation_gain_m_per_kmsurface_mix |
| Bike | Product identity, instance identity and geometry, kept separable. | identity.gtinstack_mmreach_mmmax_tire_width_mmbattery_capacity_wh |
| Compatibility | One engine's verdict on one pairing. The record of a result, never the computation. | engine.namescoreconfidencebreakdown[] |
The standard defines inputs and their meanings. Different companies compute different scores from the same data. The standard stays neutral.
Bike-side data corresponds to existing industry work on bicycle product data and geometry. VeloPair is the missing rider and compatibility layer, not another bike database.
Four objects, about ninety fields, every unit in the field name. Metric only. Boring and interoperable, as a data standard should be.
Nothing is stable until proven. Every feature stays a release candidate until at least one producer and one consumer implement it against real data.
rider, ride-profile, bike, compatibility, and the single-file bundle.velopair.json bundle per share. Unknown extensions are ignored, unknown fields are errors.