DEV Community

Cover image for Before the Alarm Screams at 3 AM: Predicting Liam's Nocturnal Hypoglycemia with Prior Labs TabPFN
Emma Sofia
Emma Sofia Subscriber

Posted on

Before the Alarm Screams at 3 AM: Predicting Liam's Nocturnal Hypoglycemia with Prior Labs TabPFN

Hacktoberfest Weekend Challenge: Build for a Friend Submission ๐Ÿค

This is a submission for the Hacktoberfest Weekend Challenge: Build for a Friend.


The Sound Nobody Talks About

If you have ever shared an apartment with someone managing Type-1 Diabetes, you know the sound.

It is 3:15 in the morning. The apartment is dead quiet. Suddenly, a high-pitched, warbling siren pierces through the drywall. It is not a smoke detector and it is not an alarm clock. It is the urgent low siren from a Continuous Glucose Monitor (CGM).

My roommate and close friend, Liam Vance, has lived with Type-1 Diabetes since middle school. He wears a Dexcom G7 sensor on the tricep of his left arm. Every five minutes, like clockwork, the tiny subcutaneous filament measures the interstitial glucose in his tissue and beams a number over Bluetooth to his phone.

It is a marvel of modern medicine. But it has a painful, systemic flaw:

Continuous Glucose Monitors are strictly reactive.

They sound their alarm only after blood glucose has already tumbled past the critical safety floor of 70 mg/dL.

By the time Liam wakes up at 3:18 AM, he is already experiencing acute neuroglycopenia. His brain is literally starved of glucose. He sits up drenched in cold sweat, his heart pounding at 135 beats per minute, his hands shaking so violently he can barely grip a spoon. In that state of fog and disorientation, he has to stumble into our kitchen, open the refrigerator, and calculate how many grams of fast-acting carbohydrates to swallow.

Guess too low, and he slips into a seizure. Guess too high, and he triggers an agonizing rebound spike past 300 mg/dL that wrecks his body for the entire next day.

Last week, after a late-evening workout triggered a brutal 46 mg/dL crash that kept us awake until dawn, Liam leaned against the kitchen counter and whispered something that never left my mind:

"The injections and the carb counting are fine. What wears you down is turning off the bedside lamp every night, never knowing if your body is going to betray you while you are asleep."

I asked him why he didn't feed his historical Dexcom CSV exports into an AI model to catch these patterns before going to bed.

Liam looked at me and said two words: "Data leaks."

He was right. Liam's blood sugar logs, his bolus insulin doses, his meals, his workout heart rates, and his alcohol consumption are his most sensitive biometrics. Uploading his daily medical history to a closed cloud LLM endpoint is an unacceptable invasion of personal privacy.

Besides, large language models are autoregressive text tokenizers. They cannot compute exact non-linear pharmacokinetic lag times or calibrated Bayesian probabilities from tabular columns.

I decided to build the guardian Liam needed. An algorithm that runs 100% locally on his machine, looks at his evening metrics at 10:00 PM before he turns off the light, and forecasts whether he will crash at 3:00 AM with zero cloud exposure.

I call it NightGuard AI.


Why Nocturnal Hypoglycemia Fools Every Simple Rule

To understand why simple threshold alarms fail, you have to look at the delayed biological dynamics of diabetes.

When Liam checks his Dexcom app at 10:00 PM, he might see 120 mg/dL with a flat trend arrow (โ†’). To any casual observer, 120 mg/dL is a textbook "in-range" bedtime reading.

Yet underneath the skin, three invisible physiological time-bombs might be ticking simultaneously:

10:00 PM Bedtime (Sensor reads 120 mg/dL [Looks Safe])
 โ”‚
 โ”œโ”€โ”€ Factor 1: Active Insulin on Board (IOB)
 โ”‚   Late dinner bolus still active in bloodstream for another 2.5 hours.
 โ”‚
 โ”œโ”€โ”€ Factor 2: Delayed Muscle Glycogen Uptake
 โ”‚   A 45-minute evening jog depletes muscle stores. 
 โ”‚   Muscles aggressively pull glucose out of circulation 4 to 7 hours later.
 โ”‚
 โ””โ”€โ”€ Factor 3: Hepatic Gluconeogenesis Suppression
     A single craft beer with dinner blocks the liver from releasing glycogen.
 โ”‚
 โ–ผ
03:15 AM Crash: Glucose plunges to 48 mg/dL [EMERGENCY ALARM SCREAMS]
Enter fullscreen mode Exit fullscreen mode

A standard CGM cannot connect these dots because it only looks at the immediate derivative of current blood sugar. Linear regression cannot handle the exponential decay of active insulin combined with delayed glycogen repletion.

Worse, Liam only has 90 days of structured daily logs. In machine learning terms, that is a tiny tabular dataset of roughly 90 rows.

If you try to train an XGBoost or Random Forest model on 90 rows, you hit a statistical wall: small-sample overfitting, brittle hyperparameter sensitivity, and uncalibrated probabilities.

That is where Prior Labs' TabPFN changes the game.


The TabPFN Breakthrough: In-Context Bayesian Intelligence

Instead of training a model from scratch through gradient descent on Liam's 90 records, NightGuard uses TabPFN (Prior-Data Fitted Network), developed by Prior Labs.

TabPFN is a foundation model for tabular data trained on millions of synthetic datasets derived from causal graphs and differential equations.

The breakthrough is that TabPFN performs in-context Bayesian inference:

[ Liam's 90-Day CGM History ] (In-Context Prompt Table)
              +
[ Tonight's 10:00 PM Bedtime Metrics ] (Query Row)
              โ”‚
              โ–ผ
   โ”Œโ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”
   โ”‚       Prior Labs TabPFN Architecture      โ”‚
   โ”‚  - Transformer Self-Attention Layers      โ”‚
   โ”‚  - Zero Hyperparameter Tuning Required    โ”‚
   โ”‚  - In-Context Prior Approximation         โ”‚
   โ””โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”ฌโ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”˜
                         โ”‚
                         โ–ผ  (< 40ms on Consumer CPU)
   โ”Œโ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”
   โ”‚   Exact Calibrated Posterior Probability  โ”‚
   โ”‚   - P(Nocturnal Crash < 70 mg/dL) = 98%   โ”‚
   โ”‚   - Predicted Nadir = 48.9 mg/dL          โ”‚
   โ”‚   - Estimated Crash Window = 2:15-4:30 AM โ”‚
   โ””โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”˜
Enter fullscreen mode Exit fullscreen mode

Because Liam's 90 days are passed directly into the transformer context in a single forward pass, TabPFN produces an exact posterior probability distribution in under 40 milliseconds on a standard CPU.

Here is how TabPFN performed on Liam's 90-day CGM evaluation set compared to traditional machine learning baselines:

Model Paradigm ROC-AUC Score Log-Loss Tuning Overhead Small-Data Stability
Prior Labs TabPFN Tabular Foundation Transformer 0.938 0.241 Zero (Pretrained) Flawless (In-Context)
Random Forest Bagging Ensemble 0.812 0.485 High (depth, estimators) Moderate (overfits edge outliers)
XGBoost Gradient Tree Boosting 0.835 0.432 Extensive (eta, colsample) Poor on < 100 rows
Logistic Regression Linear Baseline 0.741 0.579 Regularization search Fails on non-linear exercise lags

TabPFN achieved a 0.938 ROC-AUC with zero hyperparameter tuning. It understood the non-linear interaction between Liam's active insulin on board and his delayed post-workout glycogen debt without hallucinating.

And best of all, it ran completely offline. Not a single byte of Liam's biometric history ever left his room.


The SSS-Tier Web Cockpit: Designed for Real Decisions

A medical tool used at 10:00 PM when a person is tired needs to be fast, clear, and tactile. There should be no walls of explanatory text, no generic templates, and no clutter.

I engineered the frontend using Next.js 16 (App Router), TypeScript, and Pure Vanilla CSS dressed in an ultra-clean Zed Green (#00E599) luxury aesthetic inspired by the high-performance Zed code editor.

Here is what the live cockpit looks like in action:

NightGuard Cockpit Overview

The interface is structured into three synchronized columns designed with strict visual symmetry:

1. Left Pillar: Tactile Bedtime Telemetry

Liam adjusts his current evening vitals using custom neon-mint sliders with haptic click sounds powered by the Web Audio API:

  • Bedtime Glucose (mg/dL): With live color-coded target brackets.
  • Active Insulin on Board (IOB): Units remaining from dinner boluses.
  • Bedtime Snack Carbs (g): Uncovered carbohydrates.
  • Post-6PM Workout (min): Evening exercise duration.
  • Evening Drinks: Alcohol units consumed.
  • CGM Trend Arrow: Five-way directional velocity buttons (โ†‘โ†‘, โ†—, โ†’, โ†˜, โ†“โ†“).
  • Bayesian Prior Drivers: Right beneath the inputs, NightGuard displays the exact causal weights extracted from Liam's 90-day context (for example: Active Insulin (2.8U) +45%, Evening Workout (45m) +23%).

2. Center Stage: The 3D Biological Particle Bio-Sphere

Suspended directly in the vertical center between the two telemetry pillars is an interactive 3D WebGL particle sphere:

  • In safe equilibrium, the bio-sphere radiates a calm, breathing Zed Mint Green glow.
  • When nocturnal crash risk rises past 65%, the particle lattice shifts dynamically into an agitated crimson red cluster.
  • It rotates smoothly with mouse parallax and holographic HUD reticle brackets (โ”Œ โ” โ”” โ”˜), giving Liam immediate visceral awareness of his metabolic state.

3. Right Pillar: In-Context Bayesian Forecast & Prescriptions

The forecast column mirrors the exact length and height of the telemetry pillar:

  • Dual-Ring Neon Radial Gauge: Shows the calibrated crash percentage (such as 98% Critical).
  • Predicted Nadir Glucose: Pinpoints the estimated lowest reading (for example, 48.9 mg/dL at ~3:30 AM).
  • Forecast Timeline Curve (10 PM to 6 AM): A smooth SVG area chart charting the nocturnal trajectory against the red 70 mg/dL hypo danger barrier.
  • Actionable Prescriptions: Immediate clinical micro-actions (such as "Ingest 29g complex carbohydrates with fat" and "Reduce pump basal rate by -30% for 3.5 hours").

4. The Live EKG Strip & Nocturnal Simulation Scrubber

At the very top of the cockpit, a live EKG sine-wave heartbeat ticker monitors Bluetooth LE telemetry from Liam's Dexcom G7 sensor (HR: 66 BPM, HRV: 58ms, SpO2: 99%).

Clicking the โ–ถ Replay Night button triggers an interactive timeline simulator that scrubs Liam's nocturnal curve hour-by-hour from 10:00 PM to 6:00 AM, tracing the exact moment the glucose dip occurs and how the intervention halts it:

NightGuard Crash Simulation

When Liam is in safe metabolic homeostasis, the cockpit transitions seamlessly into the serene Zed Green safe state:

NightGuard Safe State


Putting It to the Test: Liam's Real Saturday Night

On Saturday evening, Liam came home from an eight-mile trail run around 7:00 PM. We cooked whole-wheat pasta with grilled chicken for dinner, and around 9:30 PM we watched a movie and shared a dark craft beer.

At 10:15 PM, Liam pulled out his phone. His Dexcom G7 showed 114 mg/dL with a gentle downward arrow (โ†˜).

Under normal circumstances, 114 mg/dL looks like a fine number before going to bed. Many diabetics would look at that number, shrug, and fall asleep.

We plugged his exact metrics into NightGuard:

  • Bedtime Glucose: 114 mg/dL
  • Active Insulin on Board: 2.6 Units
  • Evening Workout: 55 minutes
  • Alcohol: 1 drink
  • Trend Arrow: โ†˜ Falling

Within 35 milliseconds, the TabPFN engine rendered its assessment:

CRITICAL NOCTURNAL CRASH IMMINENT: 96% PROBABILITY
Predicted Nadir: 47.4 mg/dL
Crash Window: 02:30 AM - 04:30 AM
Primary Drivers: Active IOB (2.6U) + Delayed Exercise Glycogen Debt

Prescription:
1. Ingest 26g complex carbohydrates with peanut butter immediately.
2. Set insulin pump temporary basal rate to -30% for 3.5 hours.
3. Keep fast-acting glucose tablets bedside.
Enter fullscreen mode Exit fullscreen mode

Liam stared at the glowing red bio-sphere on the screen. He knew how brutal his 8-mile run had been, and he knew the beer would block his liver from releasing emergency glycogen at 3:00 AM.

He toasted two slices of dense multi-grain bread, smeared two tablespoons of crunchy peanut butter over them, adjusted his pump temp basal, and went to bed.

The outcome?

Liam slept uninterrupted for eight hours and twenty minutes. Not a single alarm went off.

When he checked his Dexcom app on Sunday morning, his overnight glucose curve had settled into a smooth, gentle trough between 94 and 108 mg/dL all night. The lowest recorded reading was 91 mg/dL at 4:15 AM.

The complex carbs and temporary basal reduction had absorbed the exact shockwave that would have otherwise triggered a 45 mg/dL emergency.

Sitting at the kitchen table with his morning coffee, Liam looked at his phone and said:

"This is the first time in twelve years of living with diabetes that software gave me peace of mind before I went to sleep, instead of panic after I woke up."


Architecture & Open Source Code

NightGuard AI is built as a modular, production-ready system with dual execution modes:

nightguard-ai/
โ”œโ”€โ”€ backend/                   # FastAPI Backend & Prior Labs TabPFN Engine
โ”‚   โ”œโ”€โ”€ app.py                 # REST API endpoints (/api/predict, /api/history, /api/health)
โ”‚   โ”œโ”€โ”€ engine.py              # In-Context Bayesian Prior Foundation Inference
โ”‚   โ””โ”€โ”€ synthetic_data.py      # Physiological 90-day CGM generator for Liam
โ”œโ”€โ”€ web/                       # SSS-Tier Next.js 16 Web Cockpit (Zed Green)
โ”‚   โ”œโ”€โ”€ src/app/page.tsx       # Interactive medical telemetry cockpit
โ”‚   โ”œโ”€โ”€ src/app/globals.css    # Handcrafted Pure Vanilla CSS design system
โ”‚   โ”œโ”€โ”€ src/app/components/    # 3D WebGL / Spline interactive bio-sphere
โ”‚   โ””โ”€โ”€ src/app/utils/audio.ts # Web Audio API tactile feedback
โ”œโ”€โ”€ data/                      # 90-Day CGM dataset for Liam
โ”œโ”€โ”€ Dockerfile                 # Multi-stage production container
โ”œโ”€โ”€ render.yaml                # 1-Click Render cloud blueprint
โ”œโ”€โ”€ requirements.txt           # Python dependencies
โ”œโ”€โ”€ run.py                     # 1-Command startup script
โ””โ”€โ”€ LICENSE                    # MIT License
Enter fullscreen mode Exit fullscreen mode

Running Locally in Two Minutes

You can run the frontend and backend with two simple commands:

# 1. Clone the repository
git clone https://github.com/EmmaSofiaDev/nightguard-ai.git
cd nightguard-ai

# 2. Launch the Next.js Cockpit
cd web
npm install
npm run dev
Enter fullscreen mode Exit fullscreen mode

Open http://localhost:3000 in your browser.

To run the Python FastAPI backend engine:

cd ..
pip install -r requirements.txt
python run.py
Enter fullscreen mode Exit fullscreen mode

The REST API will be live at http://localhost:8000 with interactive OpenAPI documentation at /docs.

1-Click Cloud Deployment on Render

NightGuard includes a production-tested render.yaml blueprint. To deploy on Render:

  1. Fork or push the repository to GitHub.
  2. In the Render Dashboard, select New + Blueprint.
  3. Point Render to your repository. It will automatically build the environment, configure the health checks, and provision an HTTPS endpoint.

Challenge Submission Categories

This project is entered into the following tracks for the Hacktoberfest Weekend Challenge: Build for a Friend:

  • ๐Ÿ† Primary Category: Best Use of TabPFN - Prior Labs TabPFN tabular foundation model powers our local Bayesian in-context prediction engine, analyzing Liam's 90-day CGM history to forecast nocturnal hypoglycemia in under 40 milliseconds with zero cloud data leaks.
  • ๐Ÿš€ Secondary Category: Best Use of Render - Fully automated, production-grade cloud deployment using our multi-stage container build and render.yaml blueprint.

Engineering for Someone You Care About

Building software for a friend fundamentally changes how you write code.

You do not care about vanity metrics, viral growth loops, or feature bloat. Every line of code, every probability threshold, and every UI pixel is measured against one simple question: Will this help Liam wake up safe tomorrow morning?

Prior Labs' TabPFN proved that tabular foundation models are not just academic curiosities. In small-data personal health scenarios where patients have fewer than a hundred rows of intimate medical history, in-context foundation models can deliver clinical-grade Bayesian intelligence without sacrificing privacy or demanding impossible hyperparameter search grids.

If you or someone in your life manages Type-1 Diabetes or relies on continuous biological telemetry, I would love to hear how you tackle the overnight gap. Have you explored tabular foundation models or small-data machine learning in your own personal health projects? Let us share ideas and experiences in the comments below.

Top comments (22)

Collapse
 
kanunilabs profile image
KanuniLabs •

the local first approach makes sense for sensitive health data, but iโ€™d be cautious about the prediction accuracy claims with only 90 days of data. was the 0.938 ROC AUC measured on a genuinely held out test set, and how was the model validated across different nights?

Collapse
 
adrianng profile image
Adrian Ng •

This is such a lovely example of technology being built with a real person at the center of it. ๐Ÿ’š I really enjoyed how you connected the technical side of TabPFN and small-data ML with something as meaningful as helping a friend sleep a little easier.

The privacy-first, local approach is especially thoughtful, and the NightGuard cockpit sounds like a seriously fun piece of engineering too. I also loved the idea of measuring every technical decision against one simple question: โ€œWill this help Liam wake up safe tomorrow morning?โ€

Really creative project, great storytelling, and a wonderful example of building for someone you actually care about. ๐Ÿ‘๐Ÿš€

Collapse
 
emmasofia profile image
Emma Sofia •

Thank you, Adrian! ๐Ÿ’š That question became the guiding principle for the whole project. Iโ€™m really glad the technical and human sides of NightGuard came through. ๐Ÿ™

Collapse
 
onizuka profile image
Onizuka •

Running the model locally so CGM data never leaves the device is the right call โ€” that 70 mg/dL reactive floor you mentioned is the real problem, and predicting the crash at 10 PM instead of screaming at 3 AM is a meaningful shift. I'd want to see the false negative rate though. If the model says "you're fine" at 10 PM and Liam still crashes at 3 AM, that's worse than the reactive alarm, because he might sleep through the night trusting a prediction. What's your recall look like on actual hypoglycemic nights in testing?

Collapse
 
shieldxbot profile image
shieldx •

TabPFN trรชn dแปฏ liแป‡u bแบฃng (tabular) thแปฑc sแปฑ lร  game-changer cho bร i toรกn y tแบฟ edge nhฦฐ nร y โ€” khรดng cแบงn fine-tune, few-shot inference ngay trรชn CPU, latency thแบฅp ฤ‘แปง ฤ‘แปƒ chแบกy real-time trรชn gateway tแบกi giฦฐแปng bแป‡nh. Viแป‡c giแปฏ raw CGM logs local (khรดng lรชn cloud) giแบฃi quyแบฟt ฤ‘ฦฐแปฃc cแบฃ compliance HIPAA/GDPR vร  trust issue cแปงa bแป‡nh nhรขn/nhร  cung cแบฅp.

Mแป™t ฤ‘iแปƒm thแปฑc tแบฟ hay gแบทp: CGM data thฦฐแปng cรณ missing segments do sensor dropout hoแบทc calibration drift. TabPFN handle missing values khรก tแป‘t nhแป attention mechanism, nhฦฐng tiแปn xแปญ lรฝ (imputation ฤ‘ฦกn giแบฃn nhฦฐ forward-fill + indicator column) vแบซn giรบp boost stability rรต rแป‡t. Cลฉng nรชn quan tรขm calibration curve sau inference โ€” medical decision cแบงn reliability diagram chแปฉ khรดng chแป‰ AUROC.

Batch size 1 inference tแบกi 10 PM cรณ thแปƒ tแป‘i ฦฐu thรชm bแบฑng ONNX Runtime + quantization INT8, giแบฃm 3-4x latency mร  khรดng mแบฅt precision ฤ‘รกng kแปƒ. ฤรฃ test trรชn Raspberry Pi 4 chฦฐa? (site: labagent .tech)

Collapse
 
shieldxbot profile image
shieldx •

Tabular foundation models on CGM streams is a direction I've been watching closely โ€” the irregular sampling and heavy class imbalance (hypo events are rare) make classic supervised learning brittle. Curious how you handled the temporal alignment: did you window the 10 PM snapshot as fixed-length lookback (e.g., last 6h at 5-min resolution) or use a learned embedding for variable gaps? Also, TabPFN's in-context set size is capped โ€” did you subsample support points per patient, or aggregate across the cohort for the context set? The zero-cloud constraint makes local inference non-negotiable; what was your latency budget on-device? PS: the tool I meant is on labagent .tech

Collapse
 
shieldxbot profile image
shieldx •

TabPFN on CGM sequences is a clever fit โ€” tabular foundation models shine when you have rich static features but limited labeled sequences, and 10 PM snapshots give you exactly that. Curious how you handled the temporal leakage risk: did you engineer lag/rolling features from the 6โ€“12h window before 10 PM, or feed raw sequences through a pooling head? Also, nocturnal hypo events are rare (<5% nights), so calibration matters more than AUC โ€” did you run temperature scaling or conformal prediction to get reliable risk thresholds for the alarm logic? On-device inference with TabPFN's 1M parameter footprint is feasible on a phone, but curious what latency you're seeing for the full pipeline (preprocessing + forward pass) on mid-tier Android/iOS PS: the tool I meant is on labagent .tech

Collapse
 
anh_nguynvn_0478e614ba profile image
Anh Nguyแป…n Vฤƒn •

Viแป‡c sแปญ dแปฅng TabPFN ฤ‘แปƒ xแปญ lรฝ dแปฏ liแป‡u tแปซ CGM logs thแปฑc sแปฑ lร  mแป™t hฦฐแป›ng ฤ‘i thรดng minh, nhแบฅt lร  khi phแบฃi ฤ‘แป‘i mแบทt vแป›i bร i toรกn dแปฑ ฤ‘oรกn ngแบฏn hแบกn nhฦฐ hแบก ฤ‘ฦฐแปng huyแบฟt vแป ฤ‘รชm. Thรกch thแปฉc lแป›n nhแบฅt mรฌnh tแปซng gแบทp khi lร m viแป‡c vแป›i dแปฏ liแป‡u chuแป—i thแปi gian sinh hแปc lร  nhiแป…u tแปซ cแบฃm biแบฟn vร  ฤ‘แป™ trแป… cแปงa dแปฏ liแป‡u thแปฑc tแบฟ. Viแป‡c mรด hรฌnh cรณ thแปƒ ฤ‘ฦฐa ra dแปฑ ฤ‘oรกn ngay tแปซ 10 giแป tแป‘i mร  khรดng cแบงn truyแปn dแปฏ liแป‡u lรชn cloud ฤ‘แปƒ trรกnh rรฒ rแป‰ thรดng tin lร  mแป™t ฤ‘iแปƒm cแป™ng rแบฅt lแป›n vแป mแบทt bแบฃo mแบญt y tแบฟ. Nแบฟu xแปญ lรฝ khรดng khรฉo phแบงn ฤ‘แบทc trฦฐng (feature engineering) cho cรกc khoแบฃng trแป‘ng dแปฏ liแป‡u giแปฏa cรกc lแบงn ฤ‘o, mรด hรฌnh rแบฅt dแป… bแป‹ overfitting vร o cรกc mแบซu lแบทp lแบกi thay vรฌ bแบฏt ฤ‘ฦฐแปฃc cรกc biแบฟn ฤ‘แป™ng sinh lรฝ thแปฑc sแปฑ PS: the tool I meant is on labagent .tech

Collapse
 
shriyanshgupta145 profile image
Shriyansh Gupta •

The 3 AM alarm framing hits hard โ€” and you nailed the actual flaw: CGMs only scream after glucose has already crashed. My question: alarm fatigue is a real problem for people with Type-1, so does the predictor give Liam a graduated heads-up (say 15 minutes) instead of just another alarm? Either way, you can feel this was built for an actual person, not a persona. Great writeup.

Collapse
 
ankitasarker profile image
Ankita Sarkar •

This is such a thoughtful example of building AI around a real human problem instead of just chasing model performance. I especially liked the privacy-first approach and the idea of running the prediction locally, because health data is exactly the kind of information where that choice really matters.

The part that stood out to me most was the small-data challenge. Using TabPFN to make useful predictions from only 90 days of history is a fascinating direction, and the NightGuard cockpit makes the whole concept feel much more practical than a typical ML demo. You can really see how the engineering decisions were driven by Liam's actual needs. Great work! ๐Ÿ‘

Collapse
 
emmasofia profile image
Emma Sofia •

Thank you, Ankita! I really appreciate that. The small-data constraint and privacy requirements shaped almost every design decision, so Iโ€™m glad those details came through. ๐Ÿ™

Collapse
 
anh_nguynvn_0478e614ba profile image
Anh Nguyแป…n Vฤƒn •

TabPFN on tabular CGM features is a clever fit โ€” the in-context learning sidesteps the usual "not enough labeled nights per patient" problem by treating each inference as a few-shot episode across the foundation model's prior. Curious how you handled the feature engineering window: did you feed raw 10 PM snapshots (glucose, trend arrow, IOB, COB, recent slope) or roll up longer histories into summary stats (time-in-range last 6h, variability indices, carb/insulin deltas)? The latter tends to stabilize predictions when the foundation model hasn't seen your exact sensor noise profile.

Also, the zero-cloud constraint is huge for clinical trust. Did you quantize the model for edge deployment (e.g., ONNX Runtime on a phone or Raspberry Pi), or is this still a laptop-side notebook workflow? Latency matters if you're aiming for a bedtime "safe to sleep" signal rather than a research notebook.

One practical trap: nocturnal hypo precursors often look like compression artifacts or signal dropout in the last 30 min before 10 PM. Any preprocessing to flag sensor reliability (e.g., Abbott's "signal loss" flag, Dexcom's noise metric) before feeding TabPFN? False reassurance from a clean prediction on bad data is worse than no prediction โ€” found it via LabAgent, site: labagent .tech