Health Dashboard on Alexey Panfilov — Product, AI, Systems

Health Dashboard, Part 1: A Score I Could Trust

Mon, 18 May 2026 00:00:00 +0000

This is Part 1 of a series about building my self-hosted Health Dashboard. The first version was not a methodology project. It was a pipe: take data from Apple Health, POST it to my server, show a score in the morning.

That sounds clean until the first bad night of data lands in Postgres. A health score is only as trustworthy as the ingestion path underneath it, and the early version of this system was mostly teaching me that lesson the hard way.

Health Dashboard, Part 2: Outgrowing Health Auto Export

Mon, 18 May 2026 00:00:00 +0000

In Part 1 the server learned to accept observations without losing them and to rebuild every derived table from raw data. That was enough to make a dashboard useful. It was not enough to make the data honest.

This part is about the moment a third-party exporter stopped being a sufficient ingestion path on its own, and about the two regressions that followed when I added my own iOS client alongside it. Health Auto Export still runs against the server today. The /health endpoint accepts both producers, and the code path that parses HAE payloads is maintained. The “outgrowing” in the title is about its limits, not its retirement.

Health Dashboard, Part 3: My Wearables Kept Lying by Omission

Mon, 18 May 2026 00:00:00 +0000

After Part 2 the ingestion layer feels clean. The server accepts payloads, a native iOS client cooperates with Health Auto Export, the schema knows about per-segment sleep, the dashboard renders five sleep phases. It looks finished. It is not.

The next class of problem only became visible once the data was technically correct. On any given night I have three devices capable of saying something about my sleep: Apple Watch on my wrist, RingConn¹ on my finger, and the iPhone next to my bed running Apple’s own Sleep Schedule estimate. Each one knows something the others do not. None of them agree about what they measured.

Health Dashboard, Part 4: When Readiness Stopped Being One Number

Mon, 18 May 2026 00:00:00 +0000

In Part 1 I described the original readiness score:

readiness = HRV_score * 0.40 + RHR_score * 0.30 + Sleep_score * 0.30

It was a useful number. It told me, every morning, whether something in last night’s data looked unusual against my personal baseline. It also turned out to be measuring the wrong thing.

This part is the audit that surfaced that, the redesign that came out of it, and the moment Phase 1 closed without producing a single model that beat its naive baseline by the criterion we had set in advance.

Health Dashboard, Part 5: The Energy Bank Problem

Mon, 18 May 2026 00:00:00 +0000

In Part 4 the audit invalidated the readiness formula and surfaced a parallel finding: EnergyBank v1 was wrong-signed against next-day HRV¹ (r=−0.149) and next-day RHR² (r=+0.212) over 387 paired days.

Wrong-signed is a strong claim. It means the concept is intact but the target is mis-specified: what v1 was measuring was probably productive strain, not recovery deficit. The two correlate on many days and diverge precisely on the days that matter, like a quiet but anxious day, an illness, a watch off the wrist.

Health Dashboard, Part 6: Measuring Stress Without Lying to Myself

Mon, 18 May 2026 00:00:00 +0000

In Part 5 the EnergyBank redesign left a placeholder: drain = α · active_kcal + β · sustained_hr_load, with β = 0 until a validation rubric per-user returns validated. That term, the autonomic-load drain, is the v2.2 piece. It is also the one I most wanted to be careful with, because “stress” is the single most over-claimed metric in consumer health products.

This part is about what stress actually means physiologically, what my data can and cannot say about it, why the obvious formula was wrong, and what the rubric is for.

Health Dashboard, Part 7: The App That Stopped Doing the Math

Mon, 18 May 2026 00:00:00 +0000

The first six parts of this series were about the server learning to have opinions. Ingestion gates, source identity, sub-score eligibility, formula-version boundaries, validation rubrics: every piece earned its right to a number. Once that work was done, a new question opened on the other side of the wire. What is the iOS client allowed to do with those numbers?

The answer turned out to be narrower than I expected when I started. The interesting part of building the mobile app was not what got added to it. It was what got removed from it, repeatedly, as the server learned to do each thing better.

Health Dashboard, Part 8: Asking Before Telling

Mon, 18 May 2026 00:00:00 +0000

Part 6 said: subjective input cannot validate the stress formula. That rule stands. A formula that auto-tunes itself against a user’s self-report becomes a closed loop with no external referent. The user rationalises post-hoc, the formula updates toward the rationalisation, and the next round of self-report is biased by the formula’s previous output. The cure for that is to keep the rubric external: next-morning HRV, RHR shift, sleep architecture. Numbers the user is not consciously writing down.