Slik lærer Longev AI: regler, data og etterprøvde prognoser
Kjernen i Longev AI er forklarbare kliniske regler bygget på gjestens personlige grunnlinje. Oppå dette samler plattformen par av typen «påvirkning → respons» og måler åpent sine egne prognoseavvik.
Hvem denne siden er for. Teknisk revisjon, leger og investorer – alle som spør: «Er dette maskinlæring eller faste regler?» Svaret er ærlig og kan kontrolleres direkte i portalen.
Kjernen er regler, etter eget valg. Hver anbefaling bygger på en navngitt terskelverdi og kan forklares med én setning; betalte behandlinger endres utelukkende av legen. Ingen godkjenner en svart boks i et medisinsk miljø.
Tilpasningen bygger på gjestens egen grunnlinje. Avvik vurderes ikke mot et befolkningsgjennomsnitt, men mot gjestens eget gjennomsnitt for oppholdet: En hvilepuls på 62 betyr ingenting før du vet at den har ligget på 54 hele uken.
To datasett. Beslutningsloggen – «gjestens tall → hva legen gjorde»; resultatloggen – «behandlinger og belastning i går → hva klokken målte om morgenen». Begge er anonyme fra bunnen av og kan eksporteres som JSONL-linjer.
Prognosene blir etterprøvd. Plattformen beregner morgendagens hvilepuls, HRV, Body Battery og søvnscore med tre modeller, og viser hver modells gjennomsnittlige avvik i en tabell – ikke som vage løfter.
Grensedragning. Wellness & Lifestyle Intelligence er livsstilsstøtte, ikke medisinsk utstyr; legen har alltid det siste ordet. Oppdatert 25.08.2026.
Regler i stedet for en svart boks – og hvorfor
Longev AI er bygget som en deterministisk motor: Den samme natten med de samme terskelverdiene gir nøyaktig samme rapport. Dette er ingen begrensning plattformen prøver å skjule, men et gjennomtenkt ingeniørvalg med tre klare grunner.
For det første: Legens godkjenning. Morgenrapporten signeres av legen, og hver eneste linje må svare på spørsmålet «hvorfor»: «Hvilepuls på 68 mot ditt gjennomsnitt på 61 – vi foreslår å bytte ut den krevende behandlingen». En anbefaling som ikke kan begrunnes med et tall, blir aldri skrevet ut.
For det andre: Det regulatoriske rammeverket. Et system som på egen hånd endrer medisinske forordninger ut fra en ugjennomsiktig modell, beveger seg mot å bli klassifisert som medisinsk utstyr og inn i høyrisikokategorien under EUs AI-forordning (EU AI Act). Plattformen forblir bevisst en ren livsstilsstøtte: Den foreslår, forklarer og overlater avgjørelsen til legen (det juridiske rammeverket).
For det tredje: Problemet med oppstart uten data («cold start»). En trenbar modell uten data fungerer dårligere enn faste regler: Den har ingenting å lære av på et hotell som ble koblet til i går. Reglene fungerer fra første gjest, mens data til fremtidige modeller begynner å samle seg opp fra aller første morgen – mer om dette nedenfor.
Egen grunnlinje i stedet for et befolkningsgjennomsnitt
Nesten hver eneste terskelverdi i motoren sammenligner gjesten med gjesten selv. Grunnlinjen er gjennomsnittet for gjestens eget opphold: Ufullstendige ankomstdager holdes konsekvent utenfor, og før det foreligger målinger fra minst to dager, settes det ikke opp noen grunnlinjeavvik – en sammenligning mot én enkelt natt ville vært ren myntkastlogikk presentert som et funn. Legen kan øke denne sikkerhetsgrensen opp til 5 dager.
Hjerteratevariabilitet (HRV – hvor ujevne pausene mellom hjerteslagene er) har en ekstra fasit: gjestens eget normalområde, som Firstbeat-algoritmen i Garmin bruker rundt tre uker på å lære inn. Hvis klokken, som kjenner gjesten lenger enn vår todagers grunnlinje, melder «under normalområdet», kan ikke beredskapskomponenten bli grønn – klokkens vurdering overstyrer beregningene våre, og utelukkende i den retningen.
De samme tallene danner grunnlaget for dagens beredskapsscore – et samlet tall fra 0 til 100, tilsvarende Readiness fra Oura og Recovery fra WHOOP, men basert på Garmin-data og med vekting fastsatt av hotellets lege: Body Battery teller 30 poeng, HRV og søvn 25 hver, mens hvilepuls og gårsdagens belastning teller 10 hver. En komponent som mangler data, fylles aldri inn med et generelt gjennomsnitt – den utelates helt, vektene rekalibreres, og dersom målingene dekker under halvparten av totalvekten, settes det ikke noe resultat.
Legens morgenrapport: Beredskapsscore 49 av 100 med detaljert oversikt – hver linje viser sin måling, sin grunnlinje og sin begrunnelse×
Motorens lag
Lag
Hva det gjør
Hvor det er beskrevet
Inndata
25 målinger fra Garmin-klokken og -vekten, helseskjema, legens forordninger og kostholdsdagboken
Et hotellsystem (PMS) kan koble seg til Garmin Health API og hente puls og søvn. Men det mangler to ting som et treningsdatasett er bygget opp av: legens forordninger og kostholdsloggen. Derfor bygger plattformen opp to datasett, og begge finnes bare der biometri, forordninger og kosthold henger sammen i én felles krets.
Beslutningsloggen — «gjestens målinger → hva legen gjorde». Hver handling i kontrollpanelet lagres med et anonymt øyeblikksbilde av gjesten: alder, kjønn, oppholdsdag, nattens tall, egne gjennomsnitt og flagg. Allerede i dag fungerer den som beslutningsstøtte: legen ser hva huset har gjort ved lignende verdier.
Utfalloggen — «belastning → respons». Hver morgen med målinger registrerer plattformen automatisk et par: gårsdagens behandlinger og belastning (inkludert middag etter 20:00 og glass fra drikkekuren) sammen med det klokken målte om morgenen — hvilepuls og HRV mot egen grunnlinje, søvn, Body Battery, beredskap og flagg.
Anonymitet og sletting. Radene inneholder verken navn eller fødselsdato; trekkes samtykket for helsedata tilbake, slettes også gjestens par — datasettet blir ryddigere av det, ikke fattigere. Eksport gjøres som JSONL-linjer fra administrasjonspanelet.
Observasjon, ikke årsakssammenheng. Basert på de innsamlede parene viser panelet gjennomsnitt «med faktor / uten»: varmebehandlinger dagen før, en krevende behandling, belastning 50 % over grunnlinjen, sen middag. En sammenligning vises bare når det finnes minst 5 par på hver side, og er merket som en observasjon: en enkelt morgen har altfor mange årsaker til at en forskjell i gjennomsnitt kan kalles en årsak.
Prognosetest: feilmargin i stedet for løfter
Påstanden «plattformen blir mer presis» har en revisjon all rett til å få dokumentert med tall. Derfor har administrasjonspanelet en prognosesjekk: basert på hele den innsamlede historikken forutsier plattformen hver morgen i ettertid — hvilepuls, HRV, Body Battery og søvnscore — og beregner gjennomsnittlig absolutt feil (MAE): hvor mange enheter prognosen bommer med i snitt.
Dette beregnes med walk-forward — «kun fremover i tid»: prognosen for en morgen bygges utelukkende på dagene før, og belastningskoeffisienten ettertrenes kun på par som allerede har funnet sted på det tidspunktet. Å se inn i fremtiden for å tilpasse svaret er umulig i selve oppbygningen.
Modell
Slik forutsier den
Hvorfor den er i tabellen
«Som i går»
i morgen får samme tall som i dag
det naive referansepunktet: en modell som ikke slår dette, kan knapt kalles en modell
«Egen grunnlinje»
gjestens gjennomsnitt for oppholdet — det samme som skrives ut på morgenarket
viser verdien av selve personaliseringen
«Grunnlinje + belastning»
egen grunnlinje justert for gårsdagens overbelastning; koeffisienten aktiveres etter 8 innsamlede par
det første elementet som lærer — og bidraget er synlig for seg selv
Tabellen er bevisst laget for å vise det ubekvemme: med lite historikk slår den naive «som i går» ofte justeringene — og det er et riktig resultat, ikke en feil. Standarden for fremtidige modeller settes av den samme tabellen: en modell tas i bruk når den stabilt slår den naive modellen på hotellets egne data, ikke når den bare høres imponerende ut.
Veikart
Nå. Regler oppå gjestens eget utgangspunkt; loggene for beslutninger og utfall vokser av seg selv; prognoseavviket måles med et tastetrykk.
Videre. Prediktive modeller på utfallsloggen – så snart det finnes nok datapar til å slå den enkle referanseverdien fra tabellen over. Før det blir det ingen «smarte» ord i utstillingsvinduet.
Alltid. Automatisk tildeling kun som et utkast legen godkjenner: slik fungerer morgennotatet allerede, og slik vil også forslaget til behandlinger basert på beslutningsloggen fungere.
Spørsmål og svar
Er dette maskinlæring eller faste regler? Kjernen er forklarbare regler oppå gjestens eget utgangspunkt. Lærende elementer finnes allerede – belastningskoeffisienten i prognosen og søk etter lignende tilfeller i beslutningsloggen – mens fullverdige modeller kommer på utfallsloggen, der kvaliteten allerede nå måles med en feiltabell.
Hvorfor ikke et nevralt nettverk? Fordi behandlingsplanen godkjennes av en lege, og forklarbarhet er et klinisk krav, ikke en smakssak; fordi EU AI Act stiller strengere krav til ugjennomsiktige helseanbefalinger enn til regler; og fordi modeller uten nok data fungerer dårligere enn regler – og plattformen samler fortsatt inn data.
Hva hindrer et vanlig hotellsystem (PMS) i å gjøre det samme? Garmin Health API leverer biometri, men ikke legens forordninger og ikke registreringer av kosthold. Koblingen «påvirkning → respons» oppstår bare der alle tre datastrømmene samles i ett og samme system – og dette datasettet tilhører hotellet.
Hvor kan man se alt dette? I kontrollpanelet: «Innstillinger» → «Assistent» – kortene for begge loggene, faktorobservasjoner, knappen for prognosetest og JSONL-eksport (administratorskjermen).
Hevder plattformen årsakssammenheng? Nei. Gjennomsnittene «med/uten faktor» er merket som observasjoner; årsakskonklusjoner krever datamengder og et forskningsdesign som et enkelt hotell ikke har – og en ærlig side sier dette rett ut.
