Skip to content

PUBLIC DECISION POLICY · PRELAUNCH-0.1

HOW THE ROADMAN APPMAKES A TRAINING DECISION.

This is the public contract behind Roadman's upcoming cycling strength and recovery app: what can change a session, what cannot, and where the system must stop.

The short answer

Roadman's app starts with the cycling week the rider already intends to follow, places a 30, 45 or 60-minute strength session around protected key rides, then uses a short same-day check to hold or reduce working-set volume when context is unfavourable. A favourable score never adds work, no score diagnoses recovery or illness, and every material change must carry a plain-language reason.

Policy version

prelaunch-0.1

Status

Prelaunch public draft

Last reviewed

2026-09-01

THE DECISION SEQUENCE

FOUR STAGES. ONE VISIBLE REASON.

1

Map the existing week

Inputs: Planned rides, priority days, available gym time, equipment, strength experience and movement constraints.

Permitted output

A strength-session length and position that does not silently replace the external cycling plan.

2

Apply the same-day guardrail

Inputs: Sleep opportunity and quality, energy, soreness, life stress, recent bike and gym work, plus rider-reported symptoms or pain.

Permitted output

Proceed at the planned ceiling, hold progression, reduce working-set volume, substitute conservatively, or stop and reassess.

3

Record the actual work

Inputs: Exercise, load, repetitions, sets, target reps in reserve, joint comfort and completion.

Permitted output

A reproducible session record; the app does not reward extra work merely because the day feels good.

4

Set the next exposure

Inputs: Previous performance, completed cycling context, soreness, joint comfort and whether priority riding remained productive.

Permitted output

A versioned progression decision with the smallest supported change and a visible reason.

NON-NEGOTIABLE GUARDRAILS

WHAT THE SYSTEM IS NOT ALLOWED TO DO.

RULE 01

A favourable readiness result cannot raise the planned training ceiling or add unplanned sets, load or intervals.

RULE 02

Acute illness concerns, meaningful movement-altering pain and concerning symptoms sit outside an automated training clearance.

RULE 03

The app may hold or reduce strength demand; it does not silently rewrite an external cycling plan.

RULE 04

One unusual HRV, resting-heart-rate, sleep or soreness value cannot diagnose under-recovery, overtraining syndrome, illness or injury.

RULE 05

Every material prescription change must store a versioned rule identifier and a plain-language reason.

RULE 06

When several interpretations are possible, the system chooses the smallest supported change and exposes uncertainty.

INPUT BOUNDARIES

CONTEXT IS NOT A DIAGNOSIS.

InputMay supportCannot establish
SleepContext on recent sleep opportunity and perceived quality.Complete recovery, sleep stages or a sleep disorder.
Energy, mood and life stressA repeatable subjective pattern that can be compared with the rider's baseline.The cause of fatigue or a mental-health diagnosis.
Soreness and joint comfortWhether familiar strength volume or an exercise choice deserves caution.Tissue damage, injury diagnosis or rehabilitation clearance.
Resting heart rate or HRVA trend collected under a consistent personal routine.A universal train-or-rest threshold from one value.
Recent bike and gym loadPlacement conflicts, training density and likely competing demands.That adaptation has occurred or that one load metric captures all fatigue.

EVIDENCE BOUNDARY

RESEARCH INFORMS THE RULES. IT DOES NOT VALIDATE THIS APP.

Strength-training trials, athlete-monitoring reviews and consensus statements inform the cautious direction of the system. They do not prove that this exact policy predicts readiness, prevents injury or improves an individual rider.

Before launch, Roadman will describe product testing separately from published sport-science evidence. A usability result is not a performance result, and neither becomes a medical claim.

Change log

prelaunch-0.1 · initial public contract

Published the four-stage decision sequence, training ceiling, non-diagnostic input boundaries, protected external plan and visible-reason requirement. Thresholds remain under prelaunch testing and are not represented here as validated cut-offs.