Introducing the Open Challenge Protocol

Today we are publishing the Open Challenge Protocol (OCP), a declarative JSON format for expressing fitness challenges. OCP defines what constitutes success in a challenge without dictating how applications should implement the experience. This separation enables portable challenge definitions that can work across different platforms while preserving the intent of each challenge.

Why challenges need a protocol

Fitness challenges are fundamentally different from workouts. A workout prescribes a structure: do this interval for this duration at this intensity. Success means completing the structure. A challenge sets a goal and lets you figure out how to achieve it. Hold 5 watts per kilogram for 10 seconds. Sprint 200 meters as fast as possible. Ride as far as you can while keeping heart rate below zone 4.

This difference matters for implementation. Workouts can be represented as simple lists of intervals. Challenges require logic: conditions that must be met, criteria for success or failure, and often real-time evaluation of rider performance against dynamic thresholds. Every app that implements challenges ends up building this logic differently, making challenges non-portable between platforms.

OCP standardizes the expression of challenge logic without requiring apps to share implementation code. A challenge defined in OCP can be loaded by any compliant host application and evaluated according to its rules. The challenge author defines the what; the host application handles the how.

What OCP defines

At its core, OCP specifies metrics, conditions, and lifecycle states. Metrics are the data points challenges evaluate: power, cadence, heart rate, speed, distance, time. Conditions combine metrics with operators and thresholds: power greater than 300 watts, cadence between 90 and 100 rpm, heart rate zone equal to 4. Lifecycle states track whether a challenge is pending, arming, active, complete, or failed.

Challenges can define phases with their own targets and exit conditions. A sprint challenge might have an approach phase where you build speed, followed by a flying effort phase where maximum power is measured. Loops enable repeating evaluation blocks for interval-style challenges. Directives provide optional runtime behaviors like notifications when conditions change.

The protocol supports two modes: pass-fail challenges with binary outcomes and record challenges where the goal is achieving the best possible result. A pass-fail challenge might require holding a specific power for a duration. A record challenge might measure your fastest 200 meter time or highest 5-second power.

The portability spectrum

Not all challenges are equally portable. OCP acknowledges this through a portability spectrum. Fully portable challenges reference only core metrics that any cycling app can provide: power, cadence, heart rate, time, distance. These work on any compliant host.

Environment-dependent challenges reference context that specific platforms provide. A challenge that uses track length requires a host that knows the track length. If the host cannot provide that value, it can substitute a fallback or mark the challenge as incompatible.

Platform-specific challenges leverage features unique to particular applications. These are inherently non-portable but can still use OCP for consistent definition within that platform. The protocol accommodates this range rather than forcing artificial constraints.

How Ride Cave uses OCP

Ride Cave's challenge system is built on OCP. Every challenge in the app, from basic power holds to complex track events, is defined as an OCP document. The challenge evaluator runs at 10Hz, checking conditions against current rider metrics and advancing lifecycle states.

When you start a challenge in Ride Cave, the system loads the OCP definition and begins evaluation. Arming conditions determine when the challenge actually starts, often after a warmup period or when you cross a starting line. Success and failure criteria are evaluated continuously once the challenge is active.

The evaluator returns progress information that the UI displays: how close you are to meeting conditions, time remaining in the current phase, loops completed. This real-time feedback comes from the structured OCP definition rather than custom code for each challenge.

Challenge examples

A simple power hold challenge requires maintaining a specific watts-per-kilogram for a duration. In OCP, this is a single success condition with a metric path (power.wkg), operator (greater than or equal), value (the target), and duration (how long to hold it). The window parameter specifies that the condition must be met continuously rather than cumulatively.

A flying 200 meter sprint uses phases: an approach phase where you build speed over the track, then an effort phase covering exactly 200 meters where time is recorded. Exit conditions trigger when distance thresholds are crossed. The record object specifies that duration through the effort phase is the primary result.

A progressive power test uses loops to create escalating difficulty. Each iteration increases the target power. The challenge continues until exit conditions are met, typically when power drops below the current target for too long. The record captures how far you progressed before failing.

Building on the protocol

OCP is versioned and designed to evolve. The current 0.1.0 draft covers cycling-specific metrics but includes reserved paths for running, rowing, and strength training. As we validate the protocol through real challenge development, we expect refinements to the schema.

The full specification is available at ridecave.com/ocp. It includes metric definitions, condition structures, lifecycle state machines, and complete examples. We are publishing it openly because fitness challenges should not be locked to specific platforms.

If you build fitness applications and want challenges that are portable, well-defined, and separate from implementation details, consider OCP. The protocol exists to make challenge authoring more systematic and challenge experiences more consistent across the ecosystem.