somnia

somnia is an AI powered watchdog through the night for seizure-like patterns in heart rate, movement, and variability; working for a safer night for all

Comment

Inspiration

A friend was diagnosed with epilepsy. Shortly after that, he was diagnosed with a neurological disorder that carries a risk of unpredictable seizures during sleep. The night is the hard part. He can be asleep, a turn in bed can look like something worse, and the person nearby may not know anything happened until morning.

That is what somnia is for. It is a night watch for one person: notice a seizure-like pattern, ask if they are okay, and show a caregiver when the alarm is still waiting. It does not diagnose a seizure, and it does not replace medical care.

What it does

somnia is a scalable service for wearable sleep data, the same kind of readings an Apple Watch already records: heart rate, movement, and heart-rate variability. Each night of those readings is scanned for seizure-like activity. The phone is the surface. Vultr is the scan. Vultr Cloud Compute stores every night: the wearable readings, the alarms, the log, and the notes. Vultr Serverless Inference compiles the published ranges for nocturnal seizures into the lines that night is compared against. Those ranges are a heart-rate rise of about 20–70% from rest, a wrist-accelerometer finding that strong rhythmic movement has to continue rather than a single turn, and a reported fall in heart-rate variability, measured as RMSSD. On the live service the compiled estimates are a motion line at 3.8 m/s², a heart-rate line at 83.7 bpm, and a variability line at 20 ms. Strong movement together with a heart rate over the compiled line opens an alarm. A heart-rate rise without that movement is saved as an observation. A turn stays under the motion line and is logged. The variability line is drawn on the second graph. Read more shows that Vultr compiled these lines from the study ranges. A machine-learning score sits beside those lines. An Isolation Forest measures how unusual each window is from heart rate and motion. A higher score means more unusual. Variability is shown on the graph and on the log, next to that score. Inference then writes the night. It writes the Insights summary from the saved counts and the cutoff note, and the "likely" line on each log entry from the heart rate, variability, and motion already stored: a seizure-like pattern, a heart-rate change, or a turn. The log says the line was compiled by a Vultr model. The alarm fills the phone. Sound and haptics play while that screen is open. "I'm okay" records that the person is safe, and the night stays in the profile. The phone then asks what was happening: turning over, awake, or not sure, with an optional note saved on the event. While an alarm is still waiting, the caregiver can see it. The caregiver has two tabs. Home shows the waiting alarm and the recent anomalies, each with the likely line Vultr wrote. Plan holds the rest of that night. Vultr writes a sentence for the person nearby. Under it is the plan: the summary, the action, and the usual hour. Share this night sends the brief, the plan, and the recent log lines. Ask about this night is a text box. Vultr answers from the saved night, the log, the notes, and the plan, and the answer appears on the page. What accumulates is a neurological profile. Night after night, the wearable metrics, the unusual windows, the label Vultr wrote, and a note the person can leave stay together for a physician to read. The note is saved with the event. Quiet sleep stays on the graph. A turn, a heart-rate change, and a seizure-like pattern enter the log and the profile.

How we built it

Vultr is the center. Cloud Compute runs FastAPI, Postgres, and Caddy, and it is where a night of wearable readings is stored and judged. The service takes those nights from many people, each night a stream of heart rate, movement, and heart-rate variability. Serverless Inference, using qwen3.8-flash-next, is the compiler and the writer. Inference runs on Vultr. The phone talks only to the Somnia service. The server sends the study notes and the resting heart rate, and Inference returns the motion line, the heart-rate rise, the variability line, and a one-sentence note. Those numbers are clamped so a turn still sits under the motion line and the sustained pattern still crosses it. The alarm, the log, and both graphs use them. The summary, the log, the caregiver brief, and the caregiver answer are further calls to the same API. The summary receives the night's counts plus the cutoff note. The log receives one anomaly's measurements and that same note. The caregiver brief receives whether an alarm is waiting, the counts, the usual hour, and the log labels. The question receives that same night plus the words the caregiver typed. Each reply is JSON. The service retries once. If a body is empty or the JSON cannot be trusted, the night keeps the previous lines and a fixed sentence, labeled on the card, so the phone still shows a complete night. The Isolation Forest is fit on quiet sleep and scores heart rate, the change from a resting baseline, motion, and motion variance. SwiftUI is the surface: Home, Insights, the log, Profile, and the caregiver tabs. The dashed lines on the graphs are the lines Inference compiled. The question box sits at the bottom of the caregiver Plan tab.

Challenges we ran into

Inference was the fragile piece. Some replies came back empty, or as a long reasoning trace with no JSON. A correct label with a trailing period was rejected. A safety check that banned the word "seizure" also banned the honest phrase "seizure-like." The service now retries once, accepts only a real JSON object, and keeps a complete night on the card when the model cannot be trusted. The lines, the alarm, and the sentences had to be one compile. A motion line, a heart-rate line, and a variability line only help if the graphs, the alarm, the log, the caregiver brief, and the answer all read what Vultr just wrote. The question box had to be a real text field. Inside the scrolling card, the page took the tap. It now sits pinned to the bottom of the Plan tab, so the caregiver can type and send. The logo had a smaller version of that problem. Redrawing the two crescents in SwiftUI filled them in and turned the mark into overlapping blobs. The screen inside the app now uses the same artwork as the home-screen icon.

Accomplishments that we're proud of

The iPhone, Vultr Cloud Compute, and Vultr Serverless Inference are one path from wearable readings to a night a caregiver can act on and a physician can read. The phone sends every window to the service. FastAPI stores it in Postgres, and Home, Insights, the log, and both caregiver tabs read that same night. Inference is in the middle of that path. It compiles the study ranges into the lines the alarm uses and both graphs draw. It writes the Insights summary, the likely line on each log entry, the sentence on the caregiver plan, and the answer to a question. The machine-learning score measures how unusual each window is beside those lines. A bad reply stays on that same path, so the phone still gets a complete night. That night is a neurological profile: the metrics, the label, a note saved for a physician, a plan, and a share the caregiver can send on. The night separates quiet sleep, a turn, a heart-rate change, and a seizure-like pattern, and the caregiver can see an alarm that is still waiting.

What we learned

A number and a sentence do different jobs, and both belong in the profile. The forest says how unusual a window is. Vultr writes what the night likely was, from measurements the service already saved, and it writes the answer a caregiver asks for from that same night. When Inference cannot answer, the card keeps a labeled sentence and the night stays intact. The study ranges are wide on purpose. Inference estimates a line inside them, and the screen shows that the lines were compiled from those ranges. Wearable readings go in, Vultr compiles and writes, an alarm reaches a caregiver, and the nights stay as a record a physician can read.

What's next for somnia

The next step is a more personal, more actionable profile. A medication tracker would record what was taken and when, so the night can sit next to that person's actual routine. A calorimeter, and other day-to-day measures like it, would add energy, meals, and the ordinary changes that sit beside a night. Missed doses, a different schedule, or a hard day could then show up in the same record as the wearable scan, and in the answers a caregiver asks for. That record is what a physician reviews, and what the person uses for a clearer plan: what to watch tonight, and what to bring to the visit.

Built With

Share this project:

Updates

Submission history