Reviewing a session analysis on a tablet in the ONE laboratory

Summary

Research and development

The workbench, published · none of this is an active service

Almost no laboratory publishes what does not work yet: the finished thing is shown and the rest appears on announcement day. These are the six lines under construction with their real status written beside them.

What state it is in
Six open lines — the Bayesian power–duration engine, an analytics layer over GURU and depth-camera capture among them — each with its actual status and no promised release date.
Why it is published

Anyone about to pay for a session knows what will be measured today and what is still an intention.

Each line states what cannot be claimed from it, the part of a development nobody shows.

What moves into operation, like the Athlete Portal, leaves this page and is described under technology and ONE Intelligence.

What it does not do

None of this can be booked, none of it enters a session and no date is committed. An R&D line can end up dropped, and if that happens it gets said here instead of leaving the page as it was.

5.0 on Google from 60 public reviews, verifiable on the laboratory listing.

R&D · NONE OF THIS IS AN ACTIVE SERVICE

What does not work yet, told before it works.

Almost no laboratory publishes its drawer of experiments: the finished work is shown and the rest appears on announcement day. These are the six lines under construction with their state written beside them, because anyone about to pay for a session deserves to know what will be measured today and what is an intention.

Six open lines · their real state · what is not claimed

Open lines

Six fronts, each with the problem it tries to solve.

None of them started from a device. All of them started from a friction that showed up session after session, which is why each card names the problem first and the tool second. Monitoring dashboards sat on this list as a prototype and left it when they went into operation: today they are the Athlete Portal.

01

An in-house analysis layer around GURU

Internal prototype

The problem: The simulator produces coordinates and captures in every session. Until now, comparing a rider’s session with the one they did a year ago meant opening two reports side by side.

The work: In-house software to read, normalise and compare those outputs inside the athlete history, with the interpretation logic that is applied by hand today written out as explicit rules.

Where it stops: It is an internal support layer. It decides no adjustments, replaces no session, and has not yet been used to produce a single recommendation given to a rider.

02

Replacing the depth cameras

Exploration

The problem: Session capture currently runs on Azure Kinect, and Microsoft has discontinued it. A measurement meant to be repeatable five years from now cannot depend on hardware that is no longer made.

The work: Tests with Orbbec depth cameras, the declared successor to Azure Kinect and compatible with its body tracking, checking their output against the current system before anything moves. Horizon 2027-2028.

Where it stops: It is in comparison testing. Until that comparison closes, session capture continues on the system already validated.

03

Faster instrumented functional assessment

Purchase under evaluation

The problem: Postural and joint-range assessment consumes a large share of the session, and part of that measurement depends on the hand taking it.

The work: Evaluating the purchase of a VALD HumanTrak system to standardise postural and movement tests, document them and compare them between sessions under the same protocol.

Where it stops: It is not in the laboratory yet. Strength, ranges and asymmetries are measured today with the VALD DynaMo Plus dynamometer, which is operational.

04

In-house classification and pattern models

Under validation

The problem: With enough cases, regularities appear that the eye does not catch: combinations of restriction, asymmetry and geometry that tend to end in the same complaint.

The work: Models trained on in-house data to classify and flag patterns worth a second look, together with language models for summarising long histories.

Where it stops: No model output reaches a report without someone reviewing it. A correlation found in in-house data is not a clinical claim and is not published as one.

05

Bayesian power–duration engine

Experimental

The problem: A best-power curve mixes what you can hold with what you simply never tried. Read carelessly, a duration without recent efforts looks like a weakness.

The work: A model that estimates capacity from efforts in normal training, with probability distributions conditional on its assumptions, relative gains between power meters, and abstention where a duration has no support in the data. Versions, assumptions and synthetic tests are documented.

Where it stops: Calibration of its uncertainty on real riders is still pending, and the first real fits show misfits the report itself flags. No validated capacity at eight hours is claimed, it does not replace an assessment when informative efforts are missing, and it is not used to prescribe.

06

Aerodynamic and resistance modelling

Exploration

The problem: Course simulation already projects power, pace and time, but treats rider drag as a reference value rather than something measured case by case.

The work: Work on drag coefficient, rolling resistance and frontal area so that a race projection starts from your actual position instead of an average.

Where it stops: A line of exploration. Projections delivered today state the assumptions they were built on.

Session analysis being reviewed on a tablet in the ONE laboratory

What it gets checked against

Nothing enters the laboratory for being new.

Every line above is compared against what is already measuring today, and until that comparison closes, what gets measured in your session stays the validated system and not the one under test. That is why each entry carries its state next to it: an internal prototype and a working instrument have nothing in common, even when both appear on the same page.

Operational
Depth capture on Azure Kinect
Operational
VALD DynaMo Plus for strength, ranges and asymmetries
Under test
Orbbec depth cameras, horizon 2027-2028
Purchase under evaluation
VALD HumanTrak, not in the laboratory yet
Experimental
Bayesian power–duration engine, kept separate from portal readings

What is not claimed

Five sentences you will not read on this site.

That an artificial intelligence performs the bike fit. What to move and why is decided by a person.

That any of these lines is finished. If it were, it would be described on the technology page and not on this one.

That a finding obtained from in-house data amounts to clinical evidence. These are internal observations, and they are named as such.

That automation shortens the session. For now the aim is to measure the same thing more times, not to measure more things worse.

That the Bayesian engine has calibrated uncertainty or beats other programmes. It computes distributions under its assumptions, and that difference matters.

Testing it properly

An in-house development validated only in-house is not validated.

Any of these lines improves when someone outside tries to break it. Of particular interest: testing instruments against a reference method, joint work with the manufacturers of the equipment already in the laboratory, and academic collaborations with access to anonymised in-house data.

If you work at a university, a manufacturer or another laboratory and want to propose a comparison, write. Whatever comes out will be published with its method in view, including the conditions under which it did not work.

Write to ONE →

Frequently asked questions

Answers before you decide.

Is the Athlete Portal still in development?

No. It sat on this page as a prototype of monitoring dashboards and moved into operation: athletes see their private reports and ONE Readiness, and the coach has the team board. What remains here is the Bayesian power–duration engine, which is experimental and not used to prescribe. The portal simulator is also labelled experimental.

Can I book anything on this page?

No, and that is the difference between this page and the technology page. This is what is being built; that is what gets used in every session. When one of these lines becomes operational it will move pages, and what it does and does not do will be stated.

Why publish something that does not work yet?

Because the usual alternative is worse: presenting exploration as product and letting the client discover the limit during the session. Publishing the real state also lets a manufacturer, a university or a colleague see what is being worked on and propose testing it, which is how something actually gets validated.

Is HumanTrak in the laboratory already?

No. It is a purchase under evaluation. What is operational for strength, joint range and asymmetries is the VALD DynaMo Plus dynamometer, with measurements taken against a fixed anchor so they can be repeated and compared between sessions.

Do you work with manufacturers or universities?

There is a relationship with the manufacturers of the equipment in use and graduate university teaching, and that combination is the natural route for testing a development against someone outside. If joint work comes out of it, it will be published with its method in view, including the conditions under which it did not work.

What will be measured in your session is on the other page.

The technology page describes the instruments in operation and which question each one answers. This page describes intentions, and the two should not be confused.

ONEPERFORMANCE FINDER
Your next step starts here