Hoe Longev AI leert: regels, gegevens en getoetste prognoses
De kern van Longev AI is verklaarbare klinische regels bovenop de eigen basislijn van de gast; het platform verzamelt paren «belasting → respons» en meet openlijk zijn eigen voorspellingsfout.
Voor wie deze pagina is. Voor technische audits, artsen en investeerders — voor iedereen die vraagt: «is dit machine learning of zijn het vaste regels?» Het antwoord is eerlijk en rechtstreeks in het portaal te controleren.
De kern bestaat uit regels, en dat is een bewuste keuze. Elk advies vloeit voort uit een vastgelegde drempelwaarde en is in één zin uit te leggen; betaalde behandelingen worden uitsluitend door de arts aangepast. In een medische context tekent niemand voor een black box.
Personalisatie via de eigen basislijn. Meldingen worden niet vergeleken met een algemene populatienorm, maar met het eigen gemiddelde van de gast tijdens het verblijf: een rusthartslag van 62 zegt niets totdat u weet dat deze de hele week 54 was.
Twee datasets. Het besluitenlogboek — «waarden van de gast → wat de arts deed»; het uitkomstenlogboek — «behandelingen en belasting van gisteren → wat het horloge 's ochtends mat». Beide zijn standaard anoniem opgebouwd en kunnen worden geëxporteerd als JSONL-regels.
Gecontroleerde voorspellingen. Het platform voorspelt met drie modellen de rusthartslag, HRV, Body Battery en slaapscore voor morgen en toont de gemiddelde foutmarge per model — overzichtelijk in een tabel, niet als loze belofte.
De afbakening. Wellness & Lifestyle Intelligence biedt ondersteuning van de levensstijl en is geen medisch hulpmiddel; het laatste woord is altijd aan de arts. Bijgewerkt op 25.08.2026.
Regels in plaats van een black box — en waarom
Longev AI werkt als een deterministische engine: dezelfde nacht levert bij dezelfde drempelwaarden exact hetzelfde overzicht op. Dat is geen beperking waar het platform geheimzinnig over doet, maar een doordachte technische keuze met drie redenen.
Ten eerste: de handtekening van de arts. Het ochtendoverzicht wordt ondertekend en elke regel erop moet antwoord geven op de vraag «waarom»: «rusthartslag 68 tegenover uw gemiddelde van 61 — we stellen voor om de intensieve behandeling te vervangen». Een aanbeveling die niet met een getal kan worden onderbouwd, wordt door de engine nooit afgedrukt.
Ten tweede: het wettelijke kader. Een systeem dat op basis van een ondoorzichtig model zelfstandig medische voorschriften wijzigt, verschuift naar de categorie van medische hulpmiddelen en valt onder de hoog-risicocategorie van de Europese AI-verordening (EU AI Act). Het platform blijft bewust een hulpmiddel voor een gezonde levensstijl: het doet suggesties, legt deze uit en wacht op het oordeel van de arts (juridisch kader).
Ten derde: de koude start. Een zelflerend model zonder data presteert slechter dan vaste regels: er is simpelweg nog geen data om van te leren in een hotel dat pas gisteren is aangesloten. Regels functioneren direct vanaf de allereerste gast, terwijl het platform vanaf de eerste ochtend gegevens begint te verzamelen voor toekomstige modellen — hierover hieronder meer.
De eigen basislijn in plaats van een populatienorm
Vrijwel elke drempelwaarde van de engine vergelijkt de gast met zichzelf. De basislijn is het gemiddelde van het eigen verblijf: onvolledige aankomstdagen worden hierin eerlijkheidshalve niet meegenomen, en zolang er minder dan twee dagen zijn gemeten, worden er helemaal geen meldingen op basis van de basislijn gegeven — een vergelijking met slechts één nacht zou immers niet meer zijn dan een gok die als conclusie wordt gepresenteerd. De arts kan deze drempel verhogen tot 5 dagen.
Hartslagvariabiliteit (HRV — de variatie in pauzes tussen opeenvolgende hartslagen) heeft een tweede bron van waarheid: het persoonlijke referentiebereik van de gast, dat het Firstbeat-algoritme in Garmin in ongeveer drie weken opbouwt. Als het horloge, dat de gast al langer kent dan onze tweedaagse basislijn, aangeeft «onder het bereik», kan de gereedheidsscore niet groen worden — het oordeel van het horloge weegt zwaarder dan onze berekening, en uitsluitend in die richting.
Uit diezelfde waarden wordt de gereedheid voor de dag samengesteld — één getal van 0 tot 100, vergelijkbaar met Readiness bij de Oura-ring of Recovery bij de WHOOP-band, maar dan gebaseerd op Garmin-gegevens en volgens de regels die de hotelarts instelt: Body Battery weegt voor 30 punten mee, HRV en slaap elk voor 25, en de rusthartslag en de belasting van gisteren elk voor 10. Een ontbrekend onderdeel wordt niet opgevuld met een algemeen gemiddelde — het valt weg, de gewichten worden opnieuw genormaliseerd en als er voor minder dan de helft van de totale weging data beschikbaar is, wordt er eerlijkheidshalve geen score toegekend.
Het ochtendoverzicht voor de arts: een gereedheid van 49 uit 100 met uitsplitsing per onderdeel — elke regel toont de eigen waarde, de bijbehorende basislijn en de reden×
De lagen van de engine
Laag
Wat het doet
Waar dit wordt toegelicht
Invoer
25 meetwaarden van het Garmin-horloge en de weegschaal, de intakevragenlijst, de voorschriften van de arts, het voedingsdagboek
Een hotelbeheersysteem (PMS) kan de Garmin Health API koppelen en hartslag en slaap binnenhalen. Maar het mist de twee zaken die een trainingsset compleet maken: de voorschriften van de arts en het voedingsdagboek. Daarom bouwt het platform twee datasets op, en beide bestaan alleen waar biometrie, voorschriften en voeding binnen één gesloten systeem samenkomen.
Besluitenlogboek — «waarden van de gast → wat de arts heeft gedaan». Elke klinische handeling in het dashboard wordt opgeslagen met een anonieme momentopname van de gast op dat tijdstip: leeftijd, geslacht, verblijfsdag, de nachtelijke waarden, eigen gemiddelden en vlaggen. Dit dient nu al als suggestie: de arts ziet hoe het hotel eerder handelde bij vergelijkbare waarden.
Uitkomstenlogboek — «belasting → reactie». Elke gemeten ochtend legt het platform automatisch een koppel vast: de behandelingen en belasting van de vorige dag (inclusief diner na 20:00 uur en glazen van de drinkkuur) naast wat het horloge 's ochtends heeft gemeten — rusthartslag en HRV ten opzichte van de eigen basislijn, slaap, Body Battery, gereedheid en vlaggen.
Anonimiteit en wissen. De rijen bevatten geen naam en geen geboortedatum; bij het intrekken van de toestemming voor gezondheidsgegevens worden ook de koppels van de gast verwijderd — de dataset wordt daar eerlijker van, niet armer. Exporteren gebeurt via JSONL-regels vanuit het beheerderspaneel.
Observatie, geen causaliteit. Op basis van de verzamelde koppels toont het dashboard gemiddelden «met factor / zonder»: warmtebehandelingen de dag ervoor, een zware behandeling, een belasting die 50% boven de basislijn ligt of een laat diner. Een vergelijking wordt pas getoond vanaf 5 koppels aan elke kant en wordt aangeduid als observatie: één ochtend heeft te veel oorzaken om een verschil in gemiddelden een directe oorzaak te noemen.
Prognosetest: meetfout in plaats van beloften
Een auditor mag bij de stelling «het platform wordt steeds nauwkeuriger» om een getal vragen. Daarom bevat het beheerderspaneel een prognosetest: over de volledige opgebouwde geschiedenis voorspelt het platform met terugwerkende kracht elke ochtend — rusthartslag, HRV, Body Battery en slaapscore — en berekent het de gemiddelde absolute fout (MAE): hoeveel eenheden de voorspelling er gemiddeld naast zit.
Dit wordt berekend via walk-forward — «alleen vooruitkijkend»: de ochtendprognose wordt strikt opgebouwd uit de dagen die eraan voorafgingen, en zelfs de belastingscoëfficiënt leert alleen van koppels die op dat moment al hebben plaatsgevonden. Vooruitkijken naar de toekomst om de uitkomst passend te maken is door de opzet simpelweg onmogelijk.
Model
Hoe het voorspelt
Waarom in de tabel
«Zoals gisteren»
morgen heeft dezelfde waarde als vandaag
de naïeve lat: een model dat dit niet overtreft, mag geen model heten
«Eigen basislijn»
het gemiddelde van de gast tijdens het verblijf — hetzelfde als op het ochtendoverzicht staat
laat zien wat personalisatie op zichzelf waard is
«Basislijn + belasting»
eigen basislijn gecorrigeerd voor de overbelasting van gisteren; de coëfficiënt treedt in werking na 8 opgebouwde koppels
het eerste lerende element — de bijdrage hiervan is afzonderlijk zichtbaar
De tabel laat bewust ook het ongemakkelijke zien: bij een korte geschiedenis wint het naïeve «zoals gisteren» het regelmatig van de correcties — en dat is een correct resultaat, geen fout. De norm voor toekomstige modellen wordt door exact deze tabel bepaald: een model komt pas in het product wanneer het op de data van het hotel structureel beter presteert dan het naïeve model, niet wanneer het alleen mooi klinkt.
De roadmap
Nu. Regels over de eigen basislijn; de logboeken voor beslissingen en uitkomsten groeien vanzelf; de voorspellingsfout wordt met één druk op de knop gemeten.
Straks. Voorspellende modellen op basis van het uitkomstenlogboek — zodra er genoeg paren zijn om de naïeve drempelwaarde uit de tabel hierboven betrouwbaar te verslaan. Tot die tijd geen «slimme» termen in de etalage.
Altijd. Automatisch voorschrijven blijft uitsluitend een concept dat de arts ondertekent: zo werkt de ochtendnotitie nu al, en zo zal ook het voorschrijfadvies op basis van het beslissingenlogboek werken.
Vragen en antwoorden
Is dit machine learning of zijn het vaste regels? De kern bestaat uit verklaarbare regels bovenop de eigen basislijn van de gast. Er zijn al lerende elementen — de belastingscoëfficiënt in de voorspelling en het zoeken naar vergelijkbare gevallen in het beslissingenlogboek — en volwaardige modellen volgen op basis van het uitkomstenlogboek, waarbij de kwaliteit nu al wordt gemeten via de foutentabel.
Waarom geen neuraal netwerk? Omdat het behandelplan door een arts wordt ondertekend en verklaarbaarheid een klinische vereiste is, geen kwestie van smaak; omdat de EU AI Act strenger toeziet op ondoorzichtige gezondheidsaanbevelingen dan op vaste regels; en omdat modellen zonder data slechter presteren dan regels — en het platform de benodigde gegevens nog aan het verzamelen is.
Wat belet een gewoon PMS om dit na te bootsen? De Garmin Health API levert wel biometrische gegevens, maar geen doktersvoorschriften en geen voedingslogboek. Het paar «blootstelling → respons» ontstaat alleen waar alle drie de stromen in één gesloten circuit samenkomen — en die dataset blijft in handen van het hotel.
Waar is dit allemaal te vinden? In het dashboard: «Instellingen» → «Assistent» — de kaarten van beide logboeken, de factorwaarnemingen, de knop voor voorspellingscontrole en de JSONL-export (het beheerdersscherm).
Claimt het platform causaliteit? Nee. De gemiddelden «met factor / zonder» worden aangeduid als waarnemingen; causale conclusies vereisen datavolumes en een onderzoeksopzet die een individueel hotel simpelweg niet heeft — en een eerlijke pagina zegt dat ronduit.
