The engine

Turn performance data into clear execution.

No black boxes. No secret formulas.

Understand the exact principles behind every watt, split and fuelling target.

Cadence Labs is an auditable modelling and analytics engine for elite cycling. The same physical and metabolic model runs forward to plan a session and inverse to reconstruct the ride file, so a plan and its outcome are never measured by two different tools.

Deterministic quantities, not scores. Each figure is derived from the ride file and the rider profile, and each carries the audit trail described in section 03.

Session and metabolic cost

Mechanical work integrated from the power channel, and the metabolic energy required to produce it.

Substrate and fuelling demand

The split between carbohydrate and fat, computed per sample rather than at the session average, and the resulting carbohydrate demand as a rate in grams per hour.

Course and aero modelling

A four-force balance: aerodynamic drag, rolling resistance, gravity and drivetrain loss, with wind. Solved for speed from power, or power from speed.

Individualised CdA

Effective drag area solved from the rider's own ride telemetry, not assumed from a position category.

Plan execution and compliance

Time in zone, intervals located in the file, and compliance measured against what was prescribed.

Forward and inverse are the same arithmetic. This is the structural claim the rest of the engine rests on.

Forward

Pre-ride. From the course, the rider, the equipment and the conditions, the model simulates the demand a session will make and what it will cost.

Inverse

Post-ride. From the telemetry that comes back, the same model reconstructs the ride sector by sector: what happened, and what it cost.

Because both directions share one model, the variance between plan and actual reflects physical reality. It is not an artefact of two tools built on different assumptions.

A quantity inside the engine is a structure, not a bare number. It carries its unit, its uncertainty band, its attribution and the chain of assumptions that produced it. The rules below are enforced at runtime, not by convention.

Tiered attribution

Every value is labelled with what stands behind it: measured on this ride, lab-tested on this rider, a population constant, or an assumption of ours.

Weakest-tier inheritance

When values combine, the result takes the weakest tier among its inputs. No calculation can produce a figure better attributed than what went into it.

Named uncertainty contributors

Every output carries a band, with the inputs that produced its width ranked and named. Combining bands can never narrow them below what the inputs allow.

Validity-range flagging

The substrate relationships hold over a bounded intensity range. The engine measures how much of a session fell outside that range and marks the result, rather than extrapolating silently.

A hashed constant register

Constants live in a generated register stamped with a hash of its source. The register is the only thing that can grant attribution. Engine code cannot raise a tier, and an unverified constant downgrades every figure computed from it.

The engine reads ride files directly. There is no required upstream platform and no connector to configure before a first result.

Raw FIT and TCX

Parsed by identical logic in the browser and on the server, so a figure never depends on where it was computed.

Missing channels stay missing

The file's channel inventory is recorded as it arrived. An absent channel is never zero-filled or invented. A computation that needs one fails, instead of producing a number from nothing.

Immutable raw storage

The uploaded file is stored as it arrived, so any figure can be recomputed from source rather than from a derived copy. A deployment configured to strip chosen fields on ingest retains what that configuration allowed through.

Tenancy isolation in the query

Every record belongs to an account, and ownership is resolved inside the database query itself. A record belonging to another account is indistinguishable from one that does not exist.

These limits are enforced in code, and they exist because the judgement they protect belongs to people who know the rider.

No food, no products

Output stops at demand, as a rate in grams per hour. What to actually eat or drink is a nutritionist's call, and nothing in the engine names a foodstuff.

No prescription

The engine reports what a session demanded and what it cost. It does not tell a coach what to do next. The training decision stays with the coach.

No population-to-individual claims

A statement from the file is about the ride. A statement from published work is about a population. The engine never restates either as a claim about the individual rider. That inference belongs to whoever knows the athlete.