Skip to content

PUBLIC TESTING STANDARD · PRELAUNCH-0.1

HOW ROADMAN WILL TESTTHE CYCLING APP.

A beta can show that riders used a product. It cannot, by itself, prove that the product improved performance. This is the public protocol Roadman will use to keep those claims separate.

The short answer

Roadman will test its cycling strength and recovery app in stages: first whether every decision obeys the published rules, then whether riders can use and understand it, then whether coach review agrees with its decisions, and only after that whether prospective rider outcomes justify an effectiveness claim. Usability, adherence and performance are separate results; no beta result will be presented as injury prevention, diagnosis or proof of performance.

Protocol version

prelaunch-0.1

Status

Public prelaunch protocol

Last reviewed

2026-09-01

Current evidence state

Prelaunch: no product-effectiveness claim

The app has a published rationale and decision policy, but the product itself has not yet produced evidence that it improves cycling performance, prevents injury or measures recovery.

THE CLAIM LADDER

FIVE PHASES. NO SKIPPED STEPS.

Each phase answers a different question. Passing an earlier phase permits only its narrow claim; it does not borrow the language of a later effectiveness study.

01

Decision-rule verification

Does every output stay inside the public decision policy?

Method

Run automated and scenario-based tests against each versioned rule, including conflicting inputs, missing data and stop conditions.

Roadman will publish

Rule version, scenarios tested, pass/fail count, unresolved failures and the app build tested.

Claim this phase may support

The tested build followed its specified rules in the reported scenarios.

Claim this phase cannot support

The rules improve performance or recovery.

02

Closed-beta usability

Can intended riders complete the workflow and understand the reason?

Method

Observe task completion, friction, explanation comprehension, drop-off and support requests across the intended rider groups.

Roadman will publish

Invited, activated and analysed denominators; task completion; comprehension; attrition; participant characteristics and known sampling limits.

Claim this phase may support

The tested riders could or could not use and understand the tested workflow.

Claim this phase cannot support

The app is effective because riders liked or completed it.

03

Coach-review agreement

Would a qualified reviewer accept, change or stop the same decision?

Method

Sample versioned decisions for independent review using the same available inputs; record agreement, direction of disagreement, overrides and reasons.

Roadman will publish

Review sample, reviewer role, agreement definition, raw counts, percentage agreement, uncertainty and material disagreement cases.

Claim this phase may support

Reviewers agreed with a stated proportion of sampled decisions under the reported protocol.

Claim this phase cannot support

Agreement proves that a prescription is optimal or medically safe.

04

Prospective real-world pilot

What happens when riders use the product during a real cycling block?

Method

Pre-specify the product version, population, duration, outcomes and analysis before enrolment; track use, missingness, overrides and priority-ride interference.

Roadman will publish

Protocol date, eligibility, flow, baseline, exposure, all pre-specified outcomes, missing data, adverse or escalation events and limitations.

Claim this phase may support

The reported outcomes were observed during use of the tested build.

Claim this phase cannot support

An uncontrolled association was caused by the app.

05

Comparative effectiveness

Does the product outperform a defined alternative on a pre-specified outcome?

Method

Use a prospective comparator design appropriate to the claim, with a public protocol, defined primary outcome and analysis plan.

Roadman will publish

Registration, allocation and comparator details, participant flow, effect estimate with uncertainty, harms, attrition, protocol deviations and null findings.

Claim this phase may support

Only the claim directly supported by the design, population, outcome and tested version.

Claim this phase cannot support

A broader, permanent or medical claim beyond the study.

THE MEASUREMENT DICTIONARY

DEFINE THE NUMBER BEFORE REPORTING IT.

Roadman will publish raw counts and denominators with every rate. “Completed” will never quietly mean “opened,” and people lost to follow-up will not disappear from the account.

Activation and exposure

Invited riders, accounts created, first readiness check, first session viewed and first session started—reported as separate denominators.

Session adherence

Assigned, viewed, started and completed sessions, with the time window and definition of completion stated.

Reason comprehension

Whether the rider can identify why a session proceeded, held, reduced, substituted or stopped—not whether they merely liked the message.

Decision agreement and override

Coach-review agreement plus rider or coach overrides, direction of change and reason; raw numerator and denominator accompany every rate.

Cycling interference

Reported or logged cases where strength work compromised a declared priority ride, with timing and competing load described.

Boundary and escalation events

Pain, symptom or illness reports that trigger a stop, substitution or referral outside the automated decision; this is not an injury-prevention measure.

Strength and cycling outcomes

Only pre-specified measures collected with a stated protocol, timeframe and missing-data rule; exploratory findings remain labelled exploratory.

REPORTING CONTRACT

WHAT WE WILL SHOW EVEN WHEN THE RESULT IS MESSY.

The tested product version matters. So do missing data, drop-outs, overrides and results that do not favour Roadman. Those details are part of the result, not footnotes to hide.

  1. 01Freeze the app build, decision-policy version, population, dates, primary outcomes and analysis before interpreting outcome data.
  2. 02Report every denominator: invited, eligible, enrolled, activated, exposed, analysed and lost to follow-up.
  3. 03Separate usability, adherence, decision agreement, association and comparative effectiveness in every headline and summary.
  4. 04Publish null and negative findings alongside favourable findings, plus protocol deviations and material product changes.
  5. 05Identify whether a result is automated test data, beta feedback, observational evidence or a comparative study.
  6. 06Do not convert a readiness input, override or escalation event into a diagnosis, injury-prevention result or medical clearance.

HOW TO READ THE SOURCES

REPORTING GUIDANCE IS NOT PRODUCT VALIDATION.

These frameworks inform what Roadman should define and disclose. Referencing them does not certify the app, make it a medical device or prove the quality of a future study. Any result will still stand or fall on its design, execution and data.