Health Dashboard, 6. deo: meriti stres bez samozavaravanja

U 5. delu redizajn EnergyBank-a ostavio je placeholder: drain = α · active_kcal + β · sustained_hr_load, gde je β = 0 dok per-user validation rubric ne vrati validated. Taj član jednačine — drain od autonomic load — pripada v2.2. I upravo sa njim sam želeo da budem posebno oprezan, jer je „stres“ najviše preobećavana metrika u consumer health-u.

Ovaj deo je o tome šta stres uopšte znači fiziološki, šta moji podaci mogu i ne mogu da kažu o njemu, zašto je očigledna formula bila pogrešna i čemu služi validation rubric.

Šta „stres“ nije

Većina consumer wearables isporučuje „stress score“: Garmin Body Battery, Whoop strain, Fitbit Stress Management. To je praktično, ali, kako kaže Marco Altini — PhD iz fiziologije i autor HRV4Training — to su made-up scores: zatvoreni algoritmi bez peer review-a, sa rezultatima koji lutaju između fiziološki sličnih dana. Literatura o validation-u nosivih uređaja prilično je jednoglasna:

Raw HRV¹ i RHR pokazuju značajnu povezanost sa validiranim merama stresa. Proprietary composite algorithms su netransparentni i nemaju nezavisnu validation. Composite scores daju upitnu dodatnu vrednost u odnosu na raw signals.

Metodološki problem nije u poslovnoj tajni. Problem je u tome što „stres“ nije jedno stanje. To je spektar bioloških signatures sa različitim vremenskim skalama i različitim markerima:

Sabijanje svega toga u jedan broj sakriva koji je proces zaista opterećen. „Stress score 67/100“ mi ne govori da li sam anksiozan, da li se borim sa virusom ili sedim na tri noći lošeg sna. Akcije su u svakom od tih slučajeva različite.

Zato dizajn v2.2 počinje ograničenjem: više signala, više klasifikovanih flags, bez composite score-a. Svaki flag ide u svoje downstream ponašanje.

Šta postoji u podacima, a šta ne

Broj samples u bazi na 2026-05-12:

heart_rate              1 916 248 samples   2015-01-11 → present   high-density (every few min)
respiratory_rate           35 954 samples   2021-09-24 → present   ~daily aggregates
blood_oxygen_saturation    32 830 samples   2020-12-31 → present
heart_rate_variability     13 373 samples   2018-04-29 → present   sparse (~5/day, event-triggered)
wrist_temperature             191 samples   2025-10-08 → present   nightly only, Apple Watch S8+

Tri signala ne postoje:

• EDA / GSR². Apple Watch to ne meri. Fitbit Sense i Whoop 4.0+ mere.
• Kortizol. U 2026. ne postoji neinvazivni consumer wearable način da se meri.
• Continuous HRV. Apple meri HRV u konkretnim događajima: Breathe sessions, posle exercise, ponekad noću. Ali ne izlaže continuous overnight aggregate, iako senzor tehnički ima podatke. Whoop i Oura to rade.

Praktičan zaključak: heart rate je jedini gust continuous signal. Metodologija mora primarno da se oslanja na HR, a HRV, respiratory rate i temperature da koristi kao confirmatory channels kada postoje. Svaki dizajn kom treba mnogo HRV-a jednostavno ne radi na mom dataset-u.

Personal baselines sa variance floor

Ista baseline konvencija iz 5. dela — rolling 30-day, ne čuvati trajno, state machine cold / warmup / steady — prenosi se i ovde. Neočigledan dodatak tiče se variance:

sd_hr_awake[d] = max(MAD-based SD [^mad-sd] of last 30 days, SD_FLOOR_HR)

SD_FLOOR_HR = 3.0 bpm. Bez floor-a, korisnici sa veoma stabilnim dnevnim HR mogu imati MAD-derived SD od samo 1.5–2 bpm. Tada običan malo zauzetiji dan sa +5 bpm izgleda kao z ≈ 2.5 — lažna „anomalija“. Floor od 3 bpm izabran je empirijski na mojim 90-dnevnim podacima; N=1 je dokumentovano ograničenje. Plan je da se to revidira kada metodologija bude radila na kohorti većoj od tri korisnika.

Tri blocker-a pre nego što β može da postane nenulta

Plan fiksira tri preconditions koje moraju da budu ispunjene pre nego što β počne bilo šta da množi.

1. daily_scores.rhr_avg nije RHR. To je prosek svih heart rate samples za dan, a ne resting baseline. v2.2 ne sme da koristi tu kolonu kao RHR_baseline. Ili se kolona popravlja i računa iz overnight low-HR windows, ili se uvodi poseban baseline_hr_overnight: medijana HR za poslednja 3 sata glavnog sleep segment-a, sa fallback-om 03:00–06:00 samo ako je sleep data imputed ili stale. Treba izabrati jedan put, ne voditi oba paralelno.

2. Awake window mora da se izvodi iz sleep_analysis, a ne iz fiksnih sati. Prva verzija v2.2 koristila je 07:00–22:00 kao stopgap. To se lomi na siesta, night shift, jet lag i kasnim noćima tipa „zaspao u 02:00“. Popravka je algoritam koji uzima najduži continuous asleep segment čiji midpoint upada u ±6 sati od local midnight za datum d, postavlja wake-time na njegov kraj, a sleep-onset na početak sledećeg qualifying segment-a. Fallback na fixed window aktivira se samo ako main sleep nije pronađen, i postavlja flag imputed_awake_window.

Postojeći helper internal/storage/typical_wake.go::GetTypicalWakeTime(days) vraća tipično, prosečno wake time. To je pogrešan oblik za ovaj zadatak; helper legitimno treba za MorningCapTime. Ovde je potreban novi WakeTimeForDate(date).

3. Coverage gate. Dan sa manje od 8 sati HR-covered awake time — sat skinut, na punjaču, sync gap — ne sme da računa sustained_hr_load. Inače se dani kada je sat skinut od 10:00 do 16:00 sistematski under-drain-uju. Gate postavlja flag stale_stress i vraća se na v2.0 kcal-only drain za taj dan.

Svaka od ovih sitnica ne menja headline formula. Ali upravo one određuju da li formula računa ono što tvrdi da računa.

Formula koja je skoro otišla u production

Prvi draft v2.2 predlagao je jednostavno rešenje:

drain_hr = β · ∫ max(0, HR(t) − RHR) dt   # bpm·hours

Integrisati površinu gde je HR iznad RHR. Pomnožiti sa β. Dodati u drain. Sa β ≈ 0.12 u odnosu na bpm·hours³, cilj je bio oko 10–15 drain points tokom „stresnog sedećeg dana“. Izgledalo je čisto. To je upravo varijanta koju bi najverovatnije implementirao neko ko se kreće brzo.

Dana 2026-05-12 uradio sam nešto što ranije nisam radio u ovom projektu. Ubacio sam draft v2.2, kanonski STRESS_MEASUREMENT.md i okolni kontekst u šest različitih LLM-ova zaredom — Gemini Flash, ChatGPT, Manus, Grok, Gemini Pro i GLM 5.1 — i zamolio svaki da uradi nezavisan review. Zatim sam svaki review vratio u svoju uobičajenu Claude Code sesiju i zatražio sintezu: gde se svih šest slaže, gde se razilaze, šta svaka nudi jedinstveno.

Sinteza je bila strukturirana. Šest tačaka u kojima su se svi reviewers složili, bez obzira na model family: daily_scores.rhr_avg je pogrešno nazvana i nesigurna; default awake-window 07:00–22:00 se lomi na shift work i jet lag; illness ne sme da naduva drain; β kao konstanta ima unit mismatch između dva dokumenta; draft i kanonski dokument su u konfliktu; asymptotic restore i bootstrap convergence su jaki i ne treba ih dirati. Zatim se pojavio three-way fork oko same drain formula: različiti reviewers su preferirali raw HR − RHR u bpm·hours (Gemini Flash), daily-averaged z-shift (rani draft STRESS_MEASUREMENT) ili hourly sustained z-load (Manus).

Sinteza se svela na tri konkretna problema draft-a v2.2.

Oslanja se na daily_scores.rhr_avg, koja nije RHR. Blocker (1) gore. Formula je skoro počela da koristi kolonu čije je značenje tiho pobeglo od imena.

Meša physical i postural components sa stress signal u jednu raw bpm delta. Stojeći HR je oko 10 bpm viši nego ležeći. Dan u kom čovek više stoji pravi apparent overshoot koji nije autonomic load. Integral ne ume da razlikuje jedno od drugog.

Na daily-average granularity gubi vremensku strukturu dana. Četiri sata sustained shift i jedan sat sharp spike uz narednih 14 normalnih sati daju isti daily-average overshoot. Fiziološki su to različiti događaji.

Draft je sačuvan u repozitorijumu kao ENERGY_BANK_V2_2_DRAFT.md sa banner-om SUPERSEDED. Čuvam takve fajlove iz istog razloga iz kog čuvam Phase 1 feasibility verdicts: formula koju danas odbacim opet će delovati razumno za tri meseca, kada zaboravim konkretan razlog zašto je bila pogrešna.

Posebno o multi-model review-u, jer je iskustvo dovoljno neobično. Posle petog review-a predlozi su počeli da se ponavljaju; šesti — GLM 5.1 — dodao je četiri stvarno nova actionable points, i tu sam stao. Svaki sledeći prolaz dao bi jednu zamerku i mnogo validating text. Pattern je dovoljno stvaran da ga zapišem kao heuristic: 3–4 model reviews su koristan sweep, 5–6 su diminishing returns, više od toga je bikeshedding. Pravi sledeći korak posle diminishing returns je implementation ili domain-expert outreach, ne još jedan model.

Formula koja ju je zamenila

Kanonska formula v2.2 je hourly sustained z-load u odnosu na personal awake baseline:

sustained_hr_load[d] = Σ_h max(0, hr_z_hour[h] − Z_THRESHOLD)
                       for h ∈ awake_window[d]
                       only if hr_coverage_hours ≥ MIN_COVERAGE

hr_z_hour[h] = (hour_hr[h] − baseline_hr_awake[d])
             / sd_hr_awake[d]    # MAD-based, floored

hour_hr[h] = median of 5-min minima within hour h

Svaki deo formule zatvara jedan od tri nalaza review-a.

Medijana 5-minutnih minimuma po satu, ne proseci. Minuti ustajanja i stajanja vide se na maksimumima, pa median of minima čuva autonomic floor svakog sata. Postural noise prestaje da izgleda kao stress.

Z-shift u odnosu na personal baseline, ne raw bpm. Isti bpm znači različite stvari na različitom nivou fitness-a. Z-shift normalizuje absolute baseline, a MAD floor (3 bpm) ne dopušta da z-score eksplodira kod korisnika sa prirodno uskom HR distribution.

Hourly integral, ne daily average. Day-average bi dao isti drain za četiri sata sustained +10 bpm i za jedan kratak spike plus četrnaest normalnih sati. Hourly integral čuva temporal structure: računaju se samo sati koji su zaista odstupili. Početni Z_THRESHOLD = 0.5 je setting (settings.energy.z_threshold), a ne hard-coded constant. Kod cognitively demanding desk work HR može sistematski biti na z = 0.5–0.8 bez autonomic stress-a, i podešavanje tog praga je calibration step, ne promena koda.

Dve vrednosti ulaze u components JSONB radi transparentnosti. Drain koristi samo sustained_hr_load_z, ali audit trail čuva i hr_overshoot_bpm_hours = Σ max(0, hour_hr[h] − baseline_hr_awake) u raw units. Druga vrednost je zgodna za korisničku rečenicu: „HR je bio oko 8 bpm iznad vaše normale oko 4 sata“. Te vrednosti koreliraju, ali nisu duplikati.

Stratified flags umesto composite score

Iz z-scored channels nastaje pet flags, svaki pokazuje na drugi fiziološki proces:

acute_stress[d]       = exists window <2h where hr_z_hour > +2
sustained_load[d]     = hr_z_hour > +1 sustained ≥4h consecutive
illness_signature[d]  = (temp_shift > +1) AND (resp_shift > +1) AND (hrv_drop > +1)
recovery_debt[d]      = overnight (hrv_drop > +1) AND (rhr_shift > +0.5)
parasympathetic_rebound[d] = (hr_shift > +1) AND (hrv_drop < −1)

Svaki ide u svoj sloj sistema:

• acute_stress → bez action-a. Transient, nema smisla uznemiravati korisnika.
• sustained_load → hrani EnergyBank drain kroz formulu iznad.
• illness_signature → ne hrani drain. Rast HR koji flag detektuje već je u sustained_hr_load; illness multiplier bi dao double-counting. Flag ide u verdict layer: prepisuje tekst verdict-a — „body fighting infection, rest aligns with this“ — i suppresses sve AI preporuke tipa „push harder“.
• recovery_debt → utiče na next-day readiness baseline, teritorija 4. dela.
• parasympathetic_rebound → samo interpretation flag. HR up i HRV up su stvarna fiziologija: vagal rebound⁴ posle sustained stress ili heavy training. Rast HR bio je stvaran autonomic expenditure i ostaje u drain-u; flag dodaje kontekst u verdict narrative: „autonomic state mixed, HR high, HRV high, likely recovery phase“.

Razdvajanje drain-a i verdict-a je važno. Drain je fiziološka cena dana. Verdict je šta korisnik treba da uradi sutra, uzimajući u obzir tu cenu i trend. Ako se pomešaju, sick days veštački naduvavaju drain: rast HR zbog illness već je uračunat u drain term.

Zašto u validation nema self-report-a

Pravilo koje je na kraju ušlo u dokument — „subjective input cannot validate the stress formula“ — nije došlo kao dekret. Nastalo je kroz otprilike pet minuta back-and-forth.

Prvobitni validation plan v2.2 imao je uski self-report. Kada sam ga prvi put skicirao sa asistentom, logika je bila: slobodan daily score 1–5 biće bučan, ali targeted anchor neće. Jedno dugme u Telegramu za „today was genuinely hard“, drugo za „today was unusually calm“, koristi se nekoliko puta mesečno. Ideja: 5–10 high-confidence anchor points trebalo bi da vredi više u Pearson r nego 28 mlakih trojki iz daily slider-a. Delovalo je kao uredan kompromis između nula self-report-a i bučnog daily diary.

Pročitao sam draft i rekao asistentu otprilike: „Ne sviđa mi se da pitamo korisnika. Ljudi lažu“.

Prva reakcija asistenta bila je da predloži druge anchors, koji ne traže da korisnik nešto unosi: calendar events — flight, interview, doctor; wrist-temperature spikes — confirmed illness; HealthKit-recorded workouts — confirmed training load; next-morning HRV — autonomic residual kojim korisnik ne upravlja svesno; sleep-onset latency — physiological response koji ne može ručno da se uredi. Argument: ako ne možemo verovati ljudima da ocenjuju sebe, koristimo kanale koje podaci već proizvode.

Odgovorio sam da calendar ideja ne radi. Apple Calendar se ne eksportuje kroz HAE, a dodavanje Google Calendar integration samo radi stress calibration je pogrešna dependency za health-data projekat. To je uklonilo dva anchor-a od pet. Preostala tri su ona koja su sada u STRESS_MEASUREMENT.md: next-morning HRV residual kao primary channel, RHR shift kao secondary cross-check, sleep architecture kao tertiary.

Dakle, no-self-report rule nije bio a priori pozicija. To je rezultat kratkog razgovora koji je počeo sa „hajde da dodamo usko self-report dugme“, a završio se na „hajde da koristimo samo signale koje korisnik svesno ne generiše“. Mehanizam koji je preživeo: četiri objective channels i decision rubric.

Razloge vredi ostaviti eksplicitnim.

Subjective daily stress logs su metodološki otrovani kao calibration signal. Ljudi zaboravljaju. Stavljaju „3“ po default-u. Racionalizuju post-hoc: „danas je bio deadline, znači bio sam pod stresom, staviću 4“. To je textbook confirmation bias, koji naduvava Pearson r⁵ upravo u smeru u kom formula već gleda. Formula auto-tuned na self-report, koji je sam auto-tuned na formulu, jeste closed loop bez external referent.

To pravilo važi za validation fizioloških formula. Ne znači da subjective input nije potreban nigde. Znači da subjective input ne glasa za vrednost β. U 8. delu vraćam se na to gde subjective input stvarno pripada: gating morning report, anchoring habit, marking days for narrative review later. Ništa od toga ne kalibriše formulu. Check-in row i stress-validation rubric žive u istoj bazi, ali se ne gledaju međusobno.

Validation harness koristi samo objektivne signale koji već postoje u bazi. Nema user input path. Četiri kanala, poređana po kvalitetu signala:

1. Next-morning HRV residual — primary. Pearson(sustained_hr_load[d], overnight_HRV[d+1]) na 30-day rolling window. HRV sledećeg jutra ne može se svesno kontrolisati. Na njega utiče ponašanje — alcohol, late training — ali korisnik ne upisuje broj ručno, pa ga post-hoc rationalisation ne savija. Očekivanje: |r| ≥ 0.3 sa negative sign — high stress load → depressed next-morning HRV — da bi formula bila validated za korisnika.
2. Next-morning RHR shift — secondary. Cross-check za channel 1. Caveat: RHR može fiziološki sign-flip. Vagal rebound posle heavy load znači niži next-morning RHR. Zato je ovo agreement check, ne standalone pass criterion.
3. Sleep architecture degradation — tertiary. Daytime autonomic load treba da predviđa longer sleep_onset_latency, više sleep_awake, niži deep_pct u prvoj trećini noći. Tri sub-correlations glasaju po sign agreement.
4. Test-retest stability — sanity. Pokrenuti isti datum kroz formulu na d+1 i d+7. sustained_hr_load treba da se razlikuje ≤1 z-load unit; bank ≤2 points. Veći drift znači da inputs nisu settled ili formula overfits recent context. Ovo je pinned u Go test (TestBankConvergence), da convergence claim ne regresira tiho pri tuning-u.

Channel 3 ima Apple Watch caveat: Apple Watch poznato over-detect-uje deep sleep — meša immobility sa slow-wave sleep. Za noći gde je picked source Apple Watch, deep_pct_first_third je downweighted, a glavni ostaju sleep_onset_latency i sleep_awake. Za RingConn / Oura-style sources taj caveat treba kalibrisati posebno, jer njihov sleep staging bias nije isti.

Rubric i odbijanje tuning-a

Validation rubric se pokreće kroz /api/admin/stress-validation. Nema request body, nema CSV upload. Samo read preko postojećih tabela. Idempotentno.

U toj tabeli važna su tri guard rails.

HRV sparsity preflight. Channel 1 traži minimum sample density. Apple Watch HRV je event-triggered. Korisnik bez daily breathing habit može dati 0–2 overnight samples nedeljno. Ako je count(overnight HRV samples) u 30-day window ispod 15, channel 1 dobija cold, a rubric se vraća na channels 2+3+4 sa zahtevom 2-of-3 agreement. Bez tog guard-a, Pearson r na tri-četiri tačke pravi statistički šum koji rubric prihvati kao signal.

Disagreement override. Channel 1 sam po sebi nije dovoljan. Ako channel 1 kaže r ≤ −0.3, ali channel 2 (RHR) i channel 3 (sleep architecture) oba disagree in sign, verdict pada na weak bez obzira na magnitude r. Single-channel result sa dva contradicting cross-checks je verovatnije overfitting ili artefact nego prava fiziologija.

Wrong-direction suppression. r > 0 se tumači kao „formula meri pogrešnu stvar za ovog korisnika“, a ne kao „tune harder dok r ne postane negativan“. Wrong-direction case ide u manual review.

Poenta rubric-a je da sistem odbija da se kalibriše tiho kada je signal slab ili kontradiktoran. Default behaviour je β_effective = 0, dok se sustained_hr_load_z ipak zapisuje u components za audit. Prebacivanje settings.energy.stress_drain_enabled = true dešava se samo posle validated.

Šta components JSONB omogućava da se dokaže kasnije

Dizajn v2.2 upisuje dve vrednosti u components, iako drain čita samo jednu: sustained_hr_load_z — kanonski input — i hr_overshoot_bpm_hours — input iz odbačenog draft-a, sačuvan za human-readable audit i cohort comparison. Obe ostaju dok cohort validation ne pokaže da je jedna dovoljna.

Za šest meseci, kada treći ili četvrti tenant bude radio dovoljno dugo da ima usable distribution, pitanje „da li je kanonski signal trebalo da bude z-shift ili bpm·hours?“ moći će da se odgovori na osnovu podataka koji već leže na disku. Trenutna arhitektura se ne zaklinje u taj odgovor. Zaklinje se u to da oba broja ostanu poštena.

To u praksi znači „no opaque score“. Nije poenta da nema broja na dashboard-u. Broj postoji i menja se. Poenta je da iza svakog broja postoji audit trail koji drugi čovek može da preračuna.

Šta nedostaje ovoj priči

Dve nedovršene stvari bolje je imenovati nego gurnuti pod tepih.

Observability formule u production-u. Dokumenti opisuju kako se računa sustained_hr_load, kako se validira i gate-uje, ali skoro ništa ne govore o tome šta se prati kada β postane nenulta. Bez counters za coverage-gate skips, per-channel calibration states, last rubric-run Pearson r i flag-fired distribution ne može se razlikovati „formula ispravno ćuti jer korisnik nije imao stress days“ od „formula tiho odbacuje većinu dana na coverage gate-u“. Spec je u backlog-u kao posebna stavka i još nije u production-u, jer β još nije uključena ni za koga.

Domain-expert outreach. Ovaj tekst citira Marca Altinija — HRV4Training — kao fiziologa čija kritika podržava stav „no opaque scores“. Prirodan sledeći korak posle six-LLM review-a jeste poslati kanonsku formulu pravom fiziologu sa oštrim pitanjem: ima li hourly z-load u odnosu na MAD-based personal awake baseline smisla kao drain proxy uz dostupne signale? Imam Todoist zadatak da to uradim, ali ga još nisam uradio. Razlog je delom kukavičluk, delom to što će pitanje biti preciznije kada β bude provisional calibrated na stvarnim podacima.

Prava lekcija

Stress je metrika koja najčešće greši u consumer wearable svetu, i baš nju najviše želim da ispravno uradim u ovom projektu. Redizajn postoji da odbije tri česta failure modes: sabiti fiziološki spektar u jedan score, tuning-ovati se na self-report i samouvereno prikazivati broj kada inputs nedostaju.

Prethodni članak bio je o poverenju u ćutanje formule. Ovaj je o poverenju u verdict. Treba znati šta svaki flag znači, gde se routed i na koje dokaze sistem ima pravo da se pozove.

Do sada je serija bila o tome kako server uči da ima mišljenja: o ingestion-u, kolonama, targets, formulama i verdicts koje te formule imaju pravo da proizvode. Sledeći članak uzima pitanje koje iz toga sledi. Kada server zasluži pravo na svoja mišljenja, šta je dozvoljeno iOS klijentu? Kratak odgovor: manje nego što bismo želeli.