Ever_Care

Evercare learns your personal baseline on-device, then continuously monitors for what truly matters — delivering emergency alerts only when they count.

Comment

Evercare

On-Device AI That Learns Your Normal, Then Watches Over It

Team ZipCodeBreakers

"Your body has a normal. Evercare learns it — then stands guard, on-device, silent until the moment it matters most."

Inspiration

It started with a pretty simple observation: most of us only get checked on by a doctor once a month, if that. Everything in between — the small warning signs, the slow drift away from what's normal for you — nobody's watching. Wearables exist, sure, but a lot of them lean on the cloud (so no internet, no protection) and use one-size-fits-all thresholds. A heart rate of 110 bpm could be nothing for one person mid-workout, and a real emergency for someone else sitting still.

That's the thing that stuck with us: it's not really about the number. It's about what that number means for the person wearing the device. So we set out to build something that actually gets to know you — quietly, continuously, and without ever needing to phone home.

What it does

Evercare is a little guardian that lives on your wearable and:

  • Reads your vitals continuously — heart rate, HRV, motion, recovery — straight off the sensor.
  • Builds a personal baseline for you specifically, instead of judging you against some population average.
  • Does all of its thinking on-device. No internet required, no health data ever leaves your wrist.
  • Stays out of your way during normal life, and only speaks up when something is a real, meaningful deviation from your normal.
  • Never stops learning — as you get fitter, older, or your routine changes, it adjusts with you.

The short version: the same reading can mean two totally different things for two different people, and Evercare is built to actually know that.

How we built it

Teaching it what "normal" looks like

Rather than checking readings against some fixed threshold, Evercare keeps a running sense of your personal average and how much you naturally fluctuate — updated with every new reading using an exponentially weighted moving average (EWMA). For a new reading \( x_t \) at time \( t \):

$$ \mu_t = \alpha \, x_t + (1 - \alpha)\, \mu_{t-1} $$

$$ \sigma_t^2 = (1 - \alpha)\left(\sigma_{t-1}^2 + \alpha \,(x_t - \mu_{t-1})^2\right) $$

\( \mu_t \) is your running baseline, \( \sigma_t^2 \) is how much you normally vary, and \( \alpha \) controls how fast the model updates its idea of "you" with each new data point.

Letting the model grow up

Early on, we want it to learn fast — it barely knows you yet. Later, we want it to calm down and stop overreacting to noise. So \( \alpha \) shrinks as more data comes in:

$$ \alpha_t = \frac{\alpha_0}{1 + \beta \, n_t} $$

where \( n_t \) is how many readings it's seen so far. In practice this gives Evercare a kind of growing-up curve:

  • Day 1 — Getting to know you: learns fast, forms a rough baseline almost immediately.
  • Week 1 — Settling in: starts being more careful, the baseline gets sharper.
  • Month 1+ — Knows you: stable and confident, but still quietly adjusting as your life changes.

Deciding what actually matters

Every reading gets turned into a personal z-score — basically, "how far is this from what's normal for you, in standard deviations":

$$ z_t = \frac{x_t - \mu_t}{\sigma_t} $$

But we didn't want Evercare to panic over one weird reading (a bad sensor moment, a sneeze, whatever). So an alert only fires when the deviation is both big and sticks around:

$$ \text{Alert}(t) = \begin{cases} 1, & \text{if } |z_t| > k \text{ and } \dfrac{1}{w}\sum_{i=t-w+1}^{t} \mathbb{1}[\,|z_i| > k\,] \geq \tau \\ 0, & \text{otherwise} \end{cases} $$

\( k \) is how far off something has to be to count as unusual (around 3-sigma), \( w \) is a short window of recent readings, and \( \tau \) is how much of that window has to also look unusual before we bother you. This combo — deviation and persistence — is basically how we kept Evercare from crying wolf.

Making it actually run on a tiny device

None of this matters if it can't run on wearable-grade hardware. The nice thing about the baseline update above is that it's \( O(1) \) — constant time, constant memory — because it only ever needs to remember the last mean and variance, not a whole history of readings:

$$ \text{Memory}(t) = O(1), \qquad \text{Compute}(t) = O(1) \text{ per reading} $$

That's what let us keep the whole loop — reading data in, updating the baseline, scoring it, deciding whether to alert — running entirely on-device, offline-capable, with nothing sensitive ever leaving the wearable.

What we used

  • Our own EWMA + anomaly-scoring pipeline, described above, as the core "brain."
  • Lightweight statistics instead of a heavy model — it had to actually fit on the hardware.
  • A privacy-first setup where raw data never leaves the device, only the occasional alert.
  • Three clean layers: sensing, on-device decision-making, and emergency-only notification.

Challenges we ran into

  • Getting the "how fast should it learn" dial right. Too fast, and a real emergency just gets absorbed as "the new normal." Tuning \( \alpha \) and \( \beta \) took a lot of trial and error.
  • False alarms vs. missed ones. Every time we tightened the threshold to cut noise, we risked missing something real — and vice versa. The persistence check was our compromise.
  • Squeezing everything onto tiny hardware. Compute, memory, and battery budgets on wearables are not forgiving.
  • The cold start problem. How do you protect someone on Day 1, before the model actually knows them yet?
  • Designing for silence. Honestly the hardest UX problem wasn't what to show — it was figuring out what not to bug people about, so that when Evercare does say something, it actually means it.

Accomplishments we're proud of

  • Getting a fully on-device, constant-time personalization loop actually working.
  • Moving past "monitoring" into something closer to real understanding — the same number correctly read as normal for one person and urgent for another.
  • Privacy that's baked into the architecture, not bolted on — nothing raw ever has to leave the device.
  • A learning curve (Day 1 → Week 1 → Month 1+) that genuinely mirrors how a person who knows you would come to understand your patterns over time.

What we learned

  • Better health AI isn't about a bigger model — it's about the right reference point. Knowing your baseline beats knowing the population average.
  • Alert fatigue is real and dangerous. A system that cries wolf gets ignored, and getting the persistence logic right taught us just how much work goes into justified silence.
  • Constraints are good for you. Being forced onto tiny hardware pushed us toward simple, explainable statistics — which turned out to be more trustworthy anyway.
  • Building for people managing chronic conditions alone, or elderly folks without constant supervision, kept every decision grounded in "does this actually help someone," not just a metric on a slide.

What's next for Evercare

  • Bringing in more signals beyond heart rate — HRV, motion, sleep, recovery — for a fuller picture of a person.
  • Caregiver-facing summaries that show trends over time without ever exposing raw, continuous data.
  • Exploring ways to improve the adaptation parameters \( \alpha_0 \) and \( \beta \) across users without ever pooling anyone's raw personal data.
  • Actually piloting this with people managing chronic conditions and elderly users living independently, to see how it holds up against real emergencies.
  • Hooking the alert pipeline up directly to caregivers and emergency contacts.
Share this project:

Updates