Session View is the product coaches buy. Embedded is the same engine underneath it, run as a single-tenant deployment for one team, academy, federation or platform partner, under their own name.
// 01 What it is
The engine works from first principles: the forces a rider is working against, and what that costs them in energy. It runs forward to model a session before it is ridden, and inverse to analyse one after it has been. Both directions are the same arithmetic, so the figure produced in planning and the figure it is measured against afterwards come from one model rather than two that happen to disagree.
Every number it returns carries the calculation that produced it and the published source behind each constant it used. Where a figure rests on a population default rather than something measured about that rider, it says so on the page, next to the number, rather than in a footnote.
Most partners already hold the data and own the relationship with the rider. What is usually missing is the layer beneath it that turns a file into a number somebody is willing to defend. That is the part we supply.
// 02 Who it is for
A coach working with their own riders is served by Session View directly. Embedded is for the case where one organisation needs the method to hold across everybody in it.
Professional and elite programmes running their own performance staff, who want one method applied consistently rather than a different spreadsheet per rider.
Development pathways where the same method has to hold across many riders and several coaches, and has to still be legible when a rider moves up or a coach moves on.
Organisations that already carry a rider data feed and have no analysis layer beneath it. You hold the data and the relationship; the part we supply is what turns a file into a number somebody can defend.
// 03 What a deployment includes
A deployment is a separate instance of the platform, not an account on a shared one.
One organisation per deployment: its own database, its own domain, no shared tenancy. Nothing is co-mingled with another deployment at any layer.
The instance runs on our infrastructure by default. Where your organisation needs the data to stay inside its own boundary, the same deployment can be stood up in your cloud account instead. Which of the two applies is settled during scoping, and it changes where the instance lives rather than what it does.
Your name, your logo and your colour throughout the interface and on every report that leaves it. Riders and staff see your organisation, not ours.
Session analysis, energy and fuelling demand, course modelling, and scheduling. Each is switched on or left off per deployment, so the interface carries what your staff actually use and nothing else.
The same endpoints the interface is built on, available to your own systems, so figures can be read back into the tools your organisation already runs.
// 04 How engagement works
We work through them in sequence rather than in parallel. The sample is where most conversations either become concrete or stop, and it is cheaper for both sides to find that out early.
What you already hold, what you need it to tell you, and whether this is the right shape for it. Half an hour is usually enough to establish that.
We take a sample of your real data, run it, and return the report it produces, the actual output, with its working shown, not a mock-up. You see what the engine says about your riders before anything is committed on either side.
One named squad, or one event. Scoped, time-boxed and priced up front, with what counts as a result agreed before it starts.
The instance is stood up, configured and handed over, with your staff trained on it.
// 05 Afterwards
A deployment is not the end of the engagement. How much of it we carry is settled with you, and can change as your staff get familiar with the output.
We run the deployment and the analysis alongside your staff, taking the operational load while your team reads the output and makes the calls.
Your staff run it. We stay available for the modelling questions, the edge cases and the periodic review of what the numbers are saying.
Your staff run it and interpret it. We keep the instance current and answer when something is wrong.
// 06 Data handling
Two of the three below are choices your organisation makes at deployment rather than things we do to you. They are written here in the plainest terms we can manage, because a control nobody can explain is a control nobody can rely on.
Data for a deployment on our infrastructure is stored in the United Kingdom. Where a deployment runs inside your own cloud account instead, it sits wherever you put it, and the question stops being ours to answer.
Riders do not have to be identified to us at all. Your organisation can enter them under codes of its own and keep the list matching each code to a person on your side. What we then hold is sessions, figures and reports against a code we have no way to resolve into a name. If a rider asks to be forgotten, you delete your line of the list and what remains here identifies nobody.
A ride file carries more than power and speed. It can hold the GPS trace leading from a rider's front door and the serial number of the device on their handlebars. A deployment can be configured to remove chosen fields as files arrive, so what is kept is what you decided to keep. It is an option rather than a default because the right answer differs: a team modelling courses needs the GPS trace that a federation may want gone.
Every record belongs to an account, and that ownership is written into the database query itself rather than verified once the row has been fetched. A record belonging to someone else is not refused, it is not found, and is indistinguishable from one that never existed.
Passwords are hashed with Argon2id and are never stored or logged in any recoverable form. A session is an opaque random token in a cookie, and only its SHA-256 is kept, so read access to the database yields nothing anyone can sign in with.
Unless a deployment is configured to strip fields on arrival, the upload is stored as it came in. That is deliberate: any figure can be recomputed from the original rather than from something we derived and then lost the provenance of.
A data processing agreement covering processing purposes, sub-processors, transfers and deletion is available on request.
// 07 Commercial shape
There is no published price. Scope varies enough between deployments that a figure here would be wrong more often than it was right, so we quote against what a deployment actually covers.