How Longev AI learns: rules, data and a tested forecast
Longev AI runs on explainable clinical rules over the guest's own baseline, collects exposure-to-response pairs on top and openly measures its own forecast error.
Who this page is for. Technical due diligence, doctors and investors — anyone asking: "is this machine learning or hard-coded rules?" The answer is honest and checkable against the portal itself.
The core is rules, by choice. Every recommendation derives from a named threshold and is explainable in one sentence; paid procedures are only ever changed by the doctor. In a medical loop nobody signs a black box.
Personalisation is the own baseline. Flags are judged not against a population norm but against the guest's own stay average: a resting pulse of 62 means nothing until you know it was 54 all week.
Two datasets. The decisions journal — "the guest's numbers → what the doctor did"; the outcomes journal — "yesterday's procedures and load → what the watch reported in the morning". Both anonymous by construction, both exportable as JSONL lines.
The forecast is audited. The platform predicts tomorrow's resting pulse, HRV, Body Battery and sleep score with three models and prints each model's mean error — as a table, not as a promise.
The boundary. Wellness & Lifestyle Intelligence — lifestyle support, not a medical device; the last word always belongs to the doctor. Updated 25.08.2026.
Rules, not a black box — and why
Longev AI is a deterministic engine: the same night under the same thresholds produces the same sheet. That is not a limitation the platform is shy about — it is an engineering decision with three reasons.
First, the doctor's signature. The morning sheet is signed, and every line on it must answer "why": "resting pulse 68 against your average of 61 — we propose swapping the demanding procedure". A recommendation that cannot be explained with a number is never printed.
Second, the regulatory frame. A system that silently changes medical prescriptions from an opaque model drifts towards being a medical device and towards the high-risk tier of the European AI regulation (EU AI Act). The platform deliberately stays lifestyle support: it proposes, explains and waits for the doctor (the legal frame).
Third, the cold start. A trainable model without data is worse than rules: there is nothing for it to learn from in a hotel that joined yesterday. Rules work from the first guest — and the data for future models starts accumulating from the first morning, as described below.
The own baseline instead of a population norm
Nearly every threshold compares the guest with themselves. The baseline is the average of their own stay: shared arrival days honestly stay out of it, and until at least two days are measured, the baseline flags are held back altogether — a comparison against a single night would be a coin toss printed as a finding. The doctor can raise that guard up to 5 days.
Heart-rate variability (HRV — how uneven the pauses between heartbeats are) has a second source of truth: the guest's own corridor, which the Firstbeat engine inside Garmin learns over about three weeks. When the watch that has known the guest longer than our two-day baseline says "below the corridor", the readiness component cannot come out green — the watch's verdict outranks our arithmetic, and in exactly one direction.
The same numbers make up the day's readiness — one figure from 0 to 100, the counterpart of Oura's Readiness and WHOOP's Recovery, but on Garmin data and under rules the hotel's doctor moves: Body Battery weighs 30 points, HRV and sleep 25 each, resting pulse and yesterday's load 10 each. A component with no data is not padded with a hospital average — it drops out, the weights renormalise, and when less than half the weight has data, no verdict is issued at all.
The doctor's morning sheet: readiness 49 of 100 with its breakdown — every line carries its number, its baseline and its reason×
The engine's layers
Layer
What it does
Where it is covered
Input
25 metrics from the Garmin watch and scale, the intake questionnaire, the doctor's prescriptions, the food diary
A hotel property-management system (PMS) can connect the Garmin Health API and receive pulse and sleep. What it lacks are the two things a training set is made of: the doctor's prescriptions and the food diary. So the platform grows two datasets, and both exist only where biometrics, prescriptions and nutrition live in one loop.
The decisions journal — "the guest's numbers → what the doctor did". Every clinical action in the panel is stored with an anonymous snapshot of the guest at that moment: age, sex, day of stay, the night's numbers, own averages, flags. It already works as a suggester: the doctor sees how the house acted on similar numbers.
The outcomes journal — "exposure → response". Every measured morning the platform itself records a pair: the previous day's procedures and load (including a dinner after 20:00 and the drinking-cure servings) next to what the watch reported in the morning — resting pulse and HRV against the own baseline, sleep, Body Battery, readiness, flags.
Anonymity and erasure. The rows carry no name and no birth date; withdrawing the health-data consent takes the guest's pairs with it — the dataset is the more honest for it, not the poorer. Export is JSONL lines from the admin panel.
An observation, not causality. Over the accumulated pairs the panel shows averages "with the factor / without": heat procedures the day before, a demanding procedure, cardiac load 50% over base, a late dinner. A comparison is printed only from 5 pairs on each side and is labelled an observation: one morning has far too many causes for a difference of averages to be called one.
The forecast test: an error instead of promises
"The platform gets more accurate" is a sentence an audit is entitled to see as a number. For that the admin panel has a forecast check: over the whole accumulated history the platform retro-predicts every morning — resting pulse, HRV, Body Battery and sleep score — and computes the mean absolute error (MAE): by how many units the forecast misses on average.
It is computed walk-forward — "moving only forwards": the forecast for a morning is built strictly from the days before it, and even the load coefficient keeps learning only on pairs that have already happened by that point. Peeking into the future to fit the answer is impossible by construction.
Model
How it predicts
Why it is in the table
"As yesterday"
tomorrow will be today's number
the naive bar: a model that does not beat it has no right to be called a model
"Own baseline"
the guest's stay average — the same one the morning sheet prints
shows what personalisation alone is worth
"Baseline + load"
the own baseline with a correction for yesterday's overload; the coefficient activates after 8 accumulated pairs
the first trainable element — its contribution visible separately
The table is deliberately able to show the uncomfortable: on a short history the naive "as yesterday" often beats the corrections — and that is a correct result, not a malfunction. The bar for future models is set by this same table: a model ships when it reliably beats the naive one on the hotel's data, not when it sounds impressive.
The roadmap
Now. Rules over the own baseline; the decisions and outcomes journals grow by themselves; the forecast error is measured at a button's press.
Next. Predictive models on the outcomes journal — once there are enough pairs to reliably beat the naive bar from the table above. Until then, no "smart" words on the storefront.
Always. Auto-prescription only as a draft the doctor signs: that is how the morning note already works, and how the prescription suggester built on the decisions journal will work.
Questions and answers
Is this machine learning or hard-coded rules? The core is explainable rules over the guest's own baseline. Trainable elements already exist — the load coefficient in the forecast and the similar-cases search in the decisions journal — and full models will arrive on the outcomes journal, with their quality already measured by the error table.
Why not a neural network? Because the sheet is signed by a doctor and explainability is a clinical requirement, not a taste; because the EU AI Act looks harder at opaque health recommendations than at rules; and because models without data are worse than rules — and the data is still accumulating.
What stops an ordinary PMS from copying this? The Garmin Health API will hand over biometrics, but not the doctor's prescriptions and not the food diary. The "exposure → response" pair only comes together where all three streams live in one loop — and that dataset stays with the hotel.
Where can all this be seen? In the panel: Settings → Assistant — the cards of both journals, the factor observations, the forecast check button and the JSONL export (the admin screen).
Does the platform claim causality? No. The "with / without the factor" averages are labelled observations; causal claims need volumes and a study design a single hotel does not have — and an honest page says so in as many words.
