Biohacking dashboards are ugly by default

I track too many things. HRV, sleep, kettlebell sessions, batting drills, glucose on and off, sometimes reaction time. Every tool ships with its own opinionated UI and zero interest in playing nicely with others.

I hate context switching visually. Dark mode here, clinical white there, neon gradients in the next tab. It fragments my focus. If I am looking at my nervous system, I want one visual language. Not six.

So I stopped waiting for integrations and themes that never ship. I started forcing every biohacking tool into the same look using one boring but powerful feature: CSS variables.

My constraint: one theme, many weird tools

Here is the practical setup I am working with:

• Garmin and Oura exports piped into a custom dashboard.
• A small web app I built for tracking baseball drills and swing volume.
• A Notion-like notes tool where I keep protocols and experiments.
• Random vendor dashboards in iframes. Because life is pain.

I wanted all of them to feel like one system. Same colors. Same typography. Same sense of hierarchy. If I glance at HRV or at kettlebell volume, my brain should not need a full layout parse.

CSS variables are the glue. I define the design system once, then keep bending UIs around it until they submit.

The core: a tiny design token layer in CSS

I treat CSS variables as the public API of my theme. Colors, spacing, fonts, radii, shadows. If it affects how the interface feels, it becomes a variable.

This is the baseline I use across my biohacking tools:

:root {
  /* core palette */
  --color-bg: #04060a;
  --color-bg-elevated: #0b1018;
  --color-surface: #121927;

  --color-accent: #4fd1c5;        /* "recovered" / good */
  --color-accent-soft: #234e52;

  --color-danger: #f56565;        /* "overreached" / bad */
  --color-warning: #ecc94b;

  --color-text: #f7fafc;
  --color-text-muted: #a0aec0;
  --color-border: #2d3748;

  /* typography */
  --font-sans: system-ui, -apple-system, BlinkMacSystemFont,
               "SF Pro Text", "Segoe UI", sans-serif;
  --font-mono: "JetBrains Mono", ui-monospace, SFMono-Regular, monospace;

  /* spacing scale */
  --space-1: 4px;
  --space-2: 8px;
  --space-3: 12px;
  --space-4: 16px;
  --space-5: 24px;
  --space-6: 32px;

  /* radii */
  --radius-sm: 4px;
  --radius-md: 8px;
  --radius-lg: 16px;

  /* shadows */
  --shadow-soft: 0 10px 30px rgba(0, 0, 0, 0.45);
}

This file is theme.css. Every project imports it. I do not care if it is a Next app, a static dashboard, or something injected via a browser extension.

The exact values are opinionated. Dark, slightly cinematic, a hint of lab equipment. The details matter, because that mood is the mental context for my biohacking work.

Mapping physiology to color and motion

I hate random color choices. If you stare at these dashboards daily, your brain starts building associations whether you like it or not. I would rather decide those intentionally.

For my biohacking stack, I use a very simple mapping:

• Cool greens / teals for recovered, parasympathetic leaning states.
• Ambers for “pay attention” but not panic.
• Warm reds for “do less or you will regret it.”

The CSS side of that looks like this:

:root {
  --state-good: var(--color-accent);
  --state-good-soft: var(--color-accent-soft);
  --state-warning: var(--color-warning);
  --state-bad: var(--color-danger);
}

.badge-good {
  color: var(--state-good);
  background: color-mix(in srgb, var(--state-good-soft) 70%, transparent);
}

.badge-warning {
  color: var(--state-warning);
}

.badge-bad {
  color: var(--state-bad);
}

Now when I wire up a new panel for HRV, sleep debt, or training load, I do not think about exact hex values. I just choose the state variable.

HRV green, sleep debt amber, too many heavy swings deep red. Same palette everywhere. My brain learns it fast, which is the entire point.

A theme object that frameworks can understand

Variables in CSS are nice. Variables in JS are sometimes unavoidable. I want both to agree.

My compromise is to define the tokens in CSS and then mirror them into a tiny JS theme object. I do not maintain two separate systems. I read from CSS:

const cssVar = (name) =>
  getComputedStyle(document.documentElement)
    .getPropertyValue(name)
    .trim();

export const theme = {
  bg: cssVar("--color-bg"),
  accent: cssVar("--color-accent"),
  danger: cssVar("--color-danger"),
};

Now, if I feed values into Vega-Lite charts or some random canvas visualization, I am still using the same colors as the CSS buttons and cards.

I think this is underrated. Most health dashboards look like ten designers disagreed over a period of three years. Keeping everything tied to the CSS variables makes it feel like one tool instead of a playlist of vendor branding.

Switching day and night without a mess

Biohacking is inherently tied to light. Circadian rhythm, blue blockers, light intensity. So my UI respects that. I do not want a retina-burning chart at 23:00.

I only run two themes: dark and night. Yes, both are dark. One is just darker and softer. I do not maintain a light theme. I think that is pointless for this context.

The CSS is simple:

:root[data-theme="dark"] {
  --color-bg: #04060a;
  --color-bg-elevated: #0b1018;
  --color-surface: #121927;
  --color-text: #f7fafc;
  --color-text-muted: #a0aec0;
}

:root[data-theme="night"] {
  --color-bg: #010208;
  --color-bg-elevated: #05060b;
  --color-surface: #0a0c14;
  --color-text: #e2e8f0;
  --color-text-muted: #718096;
}

Theme switching is just an attribute toggle:

const setTheme = (mode) => {
  document.documentElement.setAttribute("data-theme", mode);
  localStorage.setItem("theme", mode);
};

All the charts, tables, inputs, and cards update automatically because they never used literal colors. Only variables.

This is the core benefit. I can keep adjusting how “night mode” feels without touching a single component. I just massage the variables until my eyes are happy.

Hijacking external dashboards with a browser extension

So far I have only talked about stuff I own. Custom apps, small dashboards, things I deploy myself. The more interesting bit is external tools that I cannot control.

Here is how I force them to behave.

Step 1: Global theme injector

I run a user-style extension in the browser (Stylus works fine). It injects a very small stylesheet into matching domains. That stylesheet defines my variables and overrides just enough of the UI to make it feel like my system.

Example for a hypothetical HRV platform:

@-moz-document domain("hrv-vendor.example") {
  :root {
    --color-bg: #04060a !important;
    --color-surface: #121927 !important;
    --color-text: #f7fafc !important;
    --color-accent: #4fd1c5 !important;
  }

  body {
    background: var(--color-bg) !important;
    color: var(--color-text) !important;
    font-family: var(--font-sans, system-ui) !important;
  }

  .btn-primary,
  button.primary {
    background: var(--color-accent) !important;
    border-radius: var(--radius-md, 8px) !important;
    border: none !important;
  }
}

Is it a bit brute force? Yes. Does it work? Also yes.

The idea is not to re-skin their product fully. I only care about aligning the background, text, and accent colors with my variables. That is enough for my brain to treat it as part of the same ecosystem.

Step 2: Dealing with iframes

Iframes are annoying. The host page can be perfectly themed while the embedded analytics widget still screams corporate teal on white.

If the iframe is on the same origin, it is easy. I just inject the same theme.css file into the iframe document. Done.

If it is cross origin, I have two options:

• Live with it and only control the chrome around it.
• Proxy it through my own domain and strip or override its CSS.

For personal tooling, I sometimes go for the proxy. A tiny Next or Cloudflare Worker that fetches the vendor page, rewrites the CSS to variables, and serves it under my domain.

It is hacky and fragile, but for one or two critical dashboards, the trade-off is worth it. My rule is simple. If I look at it daily, it deserves to speak my visual language.

Making charts obey the theme

Charts are where most dashboards fall apart visually. They come pre-styled with awful contrasts and gradients that feel like a marketing deck.

I standardize chart theming around the same variables and keep the configuration close to the CSS.

For example, in a simple D3 or Chart.js setup:

const getTheme = () => ({
  bg: cssVar("--color-bg"),
  surface: cssVar("--color-surface"),
  text: cssVar("--color-text"),
  muted: cssVar("--color-text-muted"),
  good: cssVar("--state-good"),
  warning: cssVar("--state-warning"),
  bad: cssVar("--state-bad"),
});

const t = getTheme();

const hrvSeriesColor = (value) => {
  if (value >= 80) return t.good;
  if (value >= 60) return t.warning;
  return t.bad;
};

Now if I decide that “good” should be less neon and more muted, I touch one variable and the charts, tags, and state badges all shift together.

This is the main reason I like CSS variables for biohacking tools. I change my mind often. One night of bad sleep and I think the entire palette feels wrong. With variables, that is a 10 minute fix, not a refactor.

Connecting UI intensity to physiological load

One thing I started playing with recently: UI intensity that matches how stressed my system is. Not just colors but spacing and density.

A calm body gets a calm UI. A stressed body gets a louder one.

I expose a variable for “tension” and hook it into subtle bits of the interface:

:root {
  --tension: 0; /* 0 = calm, 1 = high tension */
}

.card {
  box-shadow:
    0 0 0 calc(1px + var(--tension) * 1px) rgba(255, 255, 255, 0.03),
    0 12px 30px rgba(0, 0, 0, 0.4 + var(--tension) * 0.2);
}

.hrv-line {
  stroke-width: calc(1.5px + var(--tension) * 0.5px);
}

Then in JS I do something naive first:

const tensionFromHrv = (rmssd) => {
  if (!rmssd) return 0.5;
  if (rmssd >= 80) return 0.1;
  if (rmssd <= 40) return 1;
  return 0.5;
};

const applyTension = (value) => {
  document.documentElement.style.setProperty(
    "--tension",
    String(value)
  );
};

This is subtle, but I feel it. On days where HRV is low or load is high, the dashboard feels slightly “sharper.” More contrast. Slightly thicker lines. It nudges my behavior.

Is this overkill? Maybe. But this is where CSS variables start feeling like a nervous system for the UI. You hook the state of the body into the state of the interface without touching every component manually.

Practical advice if you want to copy this

If you want your own unified biohacking UI, here is the order I would actually do it in.

First, write down three words for how you want the interface to feel. Mine: calm, clinical, focused. That will drive your color and spacing choices more than any palette generator.

Second, build one small theme.css file. Backgrounds, text, accents, spacing, radii, shadows. Nothing fancy. Ship it.

Third, refactor one tool at a time to only use variables. No hex codes in components. No stray rgba inlined in chart configs.

Fourth, add a browser extension stylesheet for the external dashboards you use most often. Fix just the background, text, and primary buttons. Do not try to be their design team.

Finally, once you live with it for a week, start experimenting with state-connected variables like --tension or separate dark and night modes.

The tooling is trivial. The value comes from using CSS variables as a contract. Your body state changes. Your tools change. The contract stays the same.

That is how you keep a messy stack of biohacking apps feeling like one instrument instead of a drawer of mismatched gadgets.

Why I Stopped Letting Big Tech Babysit My Biology

I like data. I like knobs, levers, sliders. I like seeing my HRV respond to a protocol and then wiring that into code.

What I do not like is my health data living on random servers, under vague privacy policies, with “AI insights” that look like a horoscope in gym clothes.

So I built a small, sovereign AI layer for my home biohacking setup. It lives on my hardware. It talks to my devices. It decides when to nudge, when to back off, and it never phones home.

This is not some theoretical “web3 + wellness” pitch. It is a very opinionated, very hacky, very real system running in my house in the Netherlands.

My Smart Home Biohacking Stack, Before AI Got Involved

Before I added AI, the setup looked like this:

• Wearables: Oura Ring, Garmin watch, sometimes a Polar chest strap for honest HR data.
• Environment: Hue lights, smart plugs on red light and PEMF devices, a CO₂ sensor, temperature sensors, cheap smart plugs on fans and a space heater.
• Inputs: Standing desk, under-desk treadmill, a basic indoor air quality sensor, and a very boring but solid mechanical timer for blue light blockers as a backup.
• Software glue: Home Assistant on a small Intel NUC, Node-RED for the ugly flows that would embarrass my younger self, a bunch of MQTT topics yelling at each other.

It worked, sort of. I had automations like:

• Turn office lights warm at 21:30.
• If CO₂ > 900 ppm, turn on fan and notify my phone.
• If it is after 22:00, cut power to standing desk to force myself to stop “just one more thing.”

Nice, but dumb. Completely deterministic. No context about my day, my sleep, my training load, or whether I was traveling.

Why I Wanted a Sovereign AI Layer

Adding a cloud LLM was easy. Call an API, send some metrics, ask “what should I do.” I tried it. It felt wrong.

Three reasons I abandoned that idea fast:

• Data sovereignty. I do not want to ship sleep, HRV, stress, and location data to any third party, no matter how nicely they talk about encryption.
• Fragility. If your core automation depends on a model endpoint and that endpoint changes pricing, limits, or quality, your protocols break overnight.
• Latency and reliability. I want sub-second decisions. If my CO₂ spikes or my HR jumps during sleep, I prefer a local machine to react, not a SaaS platform that decided to reboot.

So I decided the AI brain had to live at home. Fully local if possible. Or at least as local as my threat model demands.

What “Sovereign AI” Means In My House

My working definition is simple.

Sovereign AI means:

• The model runs on hardware I control, on a network I control.
• It can act on the environment without asking a cloud function for permission.
• I can inspect its instructions, training prompts, and logs.
• If every external connection dies, it still works.

I do not pretend I am running a perfectly audited, nation-state-proof setup. This is not that. This is a reasonably private, practical system that makes my house feel like a personal lab instead of a consumer IoT showroom.

The Architecture, From Sensors To AI To Devices

Here is what the current setup looks like.

• Hardware: Intel NUC with 32GB RAM, small Nvidia GPU. On the same VLAN as my smart home gear.
• Home Automation: Home Assistant + MQTT broker.
• AI Runtime: Local LLM via Ollama, plus a small embedding model for “memories.”
• Brain: A Python service that pulls context from Home Assistant, calls the local model, and returns decisions as structured JSON.
• Device control: Home Assistant automations that listen for the AI’s decisions and actually flip switches, change light scenes, or send me a message.

I do not point the model directly at my devices. That feels reckless. It speaks a very limited language instead, something like:

{
  "actions": [
    {"type": "set_light_scene", "target": "office", "scene": "evening_focus"},
    {"type": "toggle_device", "target": "red_light_panel", "state": "on", "duration": 900},
    {"type": "notify", "channel": "mobile", "message": "Walk 5 minutes. HRV is tanking."}
  ]
}

Then Home Assistant translates those into real automations. If the AI says something that does not match the schema, it is ignored and logged.

The Daily Loop: How The AI Runs My Protocols

The core of this system is a loop that runs every few minutes and some specific event-based triggers. Here is the basic flow.

1. Home Assistant aggregates my latest metrics: last night’s sleep score, HRV, RHR, current HR, step count, CO₂ levels, time of day, calendar events, and whether I am in the office or not.
2. The Python service pulls that context. It compresses raw numbers into a short, opinionated summary: “Slept 6h15, HRV -18% vs baseline, high stress yesterday, no morning light yet, 2 calendar calls before noon.”
3. It feeds this summary plus a very explicit system prompt to the local model. The prompt encodes my rules and my personal philosophy. Things like “avoid aggressive protocols after bad sleep” or “prioritize light and movement over supplements.”
4. The model returns a JSON list of actions. No paragraphs. No coaching speech.
5. Home Assistant executes the safe subset of those actions and logs what happened.

That is the skeleton. The interesting bit is what you tell the model it is allowed to care about.

Encoding My Biohacking Philosophy Into The AI

I am not trying to build a doctor replacement. I am building a pushy lab assistant that respects my constraints.

My system prompt reads something like this, heavily summarized:

• Never recommend anything medical. You only orchestrate environment and nudges.
• Respect recovery. If sleep is poor and HRV is low, reduce intensity of any protocol.
• Prioritize natural inputs first: light, movement, temperature, air quality.
• Do not spam. Max 3 proactive interventions per day unless environment is unhealthy.
• Assume the user is a stubborn developer who ignores subtle hints. Be direct but not annoying.

Then I define time windows and goals:

• Morning: light exposure, gentle movement, no extreme cold if sleep was bad.
• Afternoon: productivity and air quality.
• Evening: light management, winding down, strict screens and stimulation cutoff.

This means the AI is not just reacting to numbers. It is following a playbook that I wrote, with room to improvise based on context.

Concrete Scenarios From My House

Here are a few examples that actually run now.

1. The "You Slept Like Trash" Morning Protocol

Input conditions:

• Sleep duration < 6.5h.
• HRV > 15% below baseline.
• First alarm within the last 30 minutes.

The AI usually decides to:

• Set office lights to a soft but bright warm scene instead of harsh cool white.
• Turn off any high-intensity cold exposure recommendation. No cold plunge suggestion, even if the schedule would normally include it.
• Send a short notification: “Recovery compromised. Keep caffeine < 2 cups, walk 10 minutes before work, no heavy training today.”

All of that stays local. No Oura API call leaves the house. The only thing I see is the effects.

2. CO₂, Focus, And The 90-Minute Rule

If I sit in my office too long and CO₂ creeps above 1,000 ppm, my cognitive performance drops. You can feel it. Slow thinking, dumb mistakes.

The old automation just toggled the fan at 900 ppm. The sovereign AI does something smarter:

• Checks if I am in a focus block (calendar tag) or on a meeting.
• Checks whether I have moved in the last 90 minutes.
• If I have been mostly sedentary and CO₂ is high, it does two things: start the fan and cut my office lights to a “break” scene that is obviously not work mode.
• Then it nudges my phone: “Walk outside 5–10 min. CO₂ high, movement low. Your next block will be better if you move now.”

I treat that as a hard recommendation unless I am deep in a build session. And the model learns that too. If I keep ignoring it during build sessions, I tweak the prompt to be less aggressive in those time windows.

3. Evening Shutdown Without Negotiation

I am bad at stopping. Developers know this one. “Just fix this tiny bug” becomes 01:30.

The sovereign AI acts like a grumpy coach here.

• After 21:30, if tomorrow’s calendar has early commitments and HRV is already low, it starts winding down lights automatically.
• At 22:15, it cuts power to my standing desk and treadmill, sets the office lights to very warm and dim, and turns on a small bedside red light if I am still in the office.
• If I keep working past 22:30, it sends a blunt message: “You are borrowing tomorrow’s focus. Decide intentionally. Type YES-BORROW to keep working 30 more minutes.”

That last part uses a tiny chat agent that still runs locally. I have to type the phrase in a chat window that sits on my dashboard. It is annoying enough that most days I just stop.

Why Decentralization Actually Matters Here

You can build similar flows with a cloud AI. It will look slick. It will be easier to start.

I still think decentralization matters for three reasons.

• Control. If a vendor decides “no more low-level access, only high-level wellness goals,” you are stuck. With a sovereign setup, you can keep running the last known-good version of your stack.
• Privacy by default. My AI sees everything. Sleep, minor health quirks, stress patterns. I am not interested in negotiating where that data goes in exchange for some convenience.
• Experiment velocity. I change prompts weekly. I wire in new sensors. I break things. Doing that against a cloud API feels brittle and expensive. Locally, it feels like creative play.

There is also something very tangible about the loop fully closing inside your four walls. My body, my sensors, my model, my devices, my logs. That feels healthy and honest.

The Ugly Parts Nobody Markets

This is not a plug-and-play setup. A few rough edges are real.

• LLM weirdness. Even locally, models hallucinate structure. I had runs where it invented actions that do not exist. The only fix is strict JSON schemas and brutal validation.
• Latency. Some smaller models are fast but dumb. Bigger ones are smart but sluggish on modest hardware. You have to decide where you care about instant reactions and where 2–3 seconds is fine.
• Maintenance. Home Assistant updates, model updates, driver updates. If you want an appliance, this is not it. This is more like maintaining a project car.
• Over-automation. It is tempting to let the AI poke at everything. That gets annoying quickly. I had to ruthlessly cut back interventions to the things that demonstrably help.

I still prefer this to polished vendor dashboards that tell me my “Sleep Age” once a week while selling me supplements.

Where I Want To Take This Next

Right now the AI is reactive with a little bit of memory. It remembers recent days, not months.

The next step is a proper local memory layer. Something lightweight that can answer “what usually happens when you train heavy on Wednesdays and sleep badly on Thursdays.” Then adjust protocols ahead of time.

I also want a proper “consent dashboard.” A place where I can see exactly which decisions the AI took, which sensors it used, and where I can revoke powers. For example, maybe it can touch lights and fans, but it cannot ever change bedroom temperature.

And I want to share sanitized configs. No product, just the prompts, schemas, and automations that have worked for me, so other people can adapt them to their weird setups.

If You Want To Try Something Similar

If you are a developer with a few smart devices, you can start very small.

• Pick one protocol. Morning light, or CO₂, or evening shutdown. Not all three.
• Run a local model in the simplest way possible. Even a CPU-only 7B model is fine for structured decisions.
• Define a strict, tiny JSON schema for actions. No freeform text running your life.
• Wire only one device to it. See how it behaves for a week. Keep logs.
• Then iterate. Add a second sensor, or a second action type.

The point is not to build a sci-fi AI butler. The point is to have a sovereign system that knows your body, your habits, your space, and can nudge you in ways that a generic wellness app cannot.

For me, that is the interesting part of AI right now. Not another chat window. A quiet, stubborn, local brain that moves the lights, air, and routines in my little lab so I do not have to think about them all the time.

And if every external service vanished tomorrow, this setup would still work. That feels like real progress.

Stress management that does not wait for the crash

Most stress tools feel like fire alarms. They scream after the fire has already started.

I wanted sprinklers instead. Something that quietly turns on before my brain catches fire.

So I built a small AI-driven stress prediction system for myself. It watches my data, predicts when I am about to get cooked, and triggers specific interventions before I feel terrible.

This is not theory. This is the slightly messy, very real system that now nudges me away from burnout on heavy client days and long baseball weekends.

The core idea: catch the slope, not the point

Most wearables show you stress as a number. HRV score. Resting heart rate. Sleep score. Maybe a graph.

The number itself is nice. But the real story sits in the slope.

Is HRV sliding down faster than usual for a Tuesday? Is my resting heart rate spiking after three days of bad sleep and heavy coding? Is my calendar stacked with back-to-back calls on top of that?

I do not care if my HRV is 65 or 75 in isolation. I care about how fast it is changing relative to my baseline, in context with what my day looks like.

That is what I ask the AI to reason about for me.

The data I actually use

People love huge data stacks. I think that is mostly a distraction. I started with four inputs and only added more when it clearly helped.

Here is the current stack.

1. Physiological baselines

• HRV (Heart Rate Variability) from my wearable. I use it as a proxy for recovery and stress capacity.
• Resting heart rate over the last 7 days. Sudden jumps are usually a bad sign.
• Sleep duration and quality. I track total sleep time and number of wake-ups, not every micro metric.

Everything is normalized around my personal baseline. I do not compare myself to generic “healthy male” charts. I compare me to last month me.

2. Calendar load

• Number of meetings per day.
• Context switches. Different projects or domains back to back.
• Blocks without breaks longer than 2 hours.

Google Calendar is terrible as a stress tool on its own. Feed it to an AI with the right framing though and it turns into a pretty good "future friction" map.

3. Subjective check-ins

I ask myself one short question a few times per day in a quick note:

“How stressed do you feel right now from 1 to 5?”

And I force a sentence of context:

“Why?”

I capture this in plain text. No fancy app. Just a timestamp, a number, and a sentence.

4. Behavioural crumbs

These are rough, noisy, but surprisingly useful:

• Screen time from phone and laptop.
• Late-night browsing past my target bedtime.
• Caffeine count after 14:00.

None of these matter in isolation. Together, they paint a picture of how much I am ignoring my own rules.

My architecture: boring on purpose

I like simple setups that survive busy weeks. If a system requires "just one more script" every two days, I will abandon it.

So the architecture looks like this:

• Data ingress: Wearable exports, Google Calendar API, a tiny endpoint where my check-ins land.
• Storage: A single database table per source, plus one aggregated “day snapshot” table.
• AI layer: A daily and intra-day prompt that gets a structured JSON payload. It outputs a risk score and suggested interventions.
• Notification: Short messages through Telegram and email. No dashboards. No charts.

Every morning at 06:30 a script pulls:

• Last 7 days of physiological data.
• Today and tomorrow’s calendar.
• The last 72 hours of subjective check-ins.

Then it compiles a small JSON blob and sends it to an LLM API with a very specific prompt.

The prompt that made it useful

The first version was too polite. It gave insights, not decisions. That is useless when you are half asleep, scrolling through your morning messages.

I changed the prompt so the model has to do three things, every time:

1. Predict my stress level for the next 12 hours on a 1 to 5 scale.
2. Assign a risk band: low, medium, or high.
3. Return 1 to 3 specific interventions I can realistically do.

The rough structure looks like this:

{
  "physiology": { ... },
  "calendar": { ... },
  "checkins": [ ... ],
  "behaviour": { ... }
}

And the system prompt is very direct. Something like:

You are my stress prediction assistant.

You must:
1. Predict my subjective stress (1-5) for the next 12 hours.
2. Explain your reasoning in 3-5 sentences.
3. Give me 1-3 concrete actions I can realistically do today, each < 140 characters.
4. Output strict JSON.

I also list my personal rules. For example:

• No advice that requires more than 15 minutes during work blocks.
• No vague tips like “relax more”.
• Interventions must be measurable: walk, nap, cancel, reschedule, block time, reduce caffeine, etc.

The result is a daily stress forecast that looks more like a weather report and less like a horoscope.

What the predictions actually look like

Here is a real-ish example, slightly anonymized:

{
  "predicted_stress": 4,
  "risk_band": "high",
  "reasoning": "HRV is 18% below your 30-day baseline and has dropped three days in a row. Resting HR is up 6 bpm. You have 6 meetings with only one 30-minute break and three context switches between client work and deep dev tasks. Your last check-in was a 4/5 with 'feeling rushed, behind on feature X'. This combination strongly suggests you will feel overloaded from 14:00 onward if you keep your current plan.",
  "actions": [
    "Cancel or move one non-critical afternoon meeting to tomorrow.",
    "Schedule a 20-minute walk between 13:30-14:30 and protect it in your calendar.",
    "Limit coffee to 1 cup before 11:00, then switch to water or tea."
  ]
}

The important part is not that the model guessed "4" instead of "3". The value is that it forces my future self to collide with my current calendar in a structured way.

Stress is a lagging indicator

By the time I feel stressed, my body has usually been waving flags for hours.

That is why I care so much about trend plus context.

Three patterns turned out to be extremely predictive for me:

• Three-day HRV slide + bad sleep. If HRV trends down for three days while sleep drops below 6.5 hours, the next day is almost always a stress spike, even if the calendar looks quiet.
• High context switching. Four different projects in a day with calls sprinkled in between. Even with good sleep, I feel frayed by late afternoon.
• Caffeine abuse after lunch. This one is obvious, yet I still mess it up. The AI calling it out early helps more than I expected.

The model does not "discover" new physics here. It just refuses to let me ignore my own patterns.

Proactive interventions that actually happen

Interventions only matter if I repeat them. Fancy protocols are useless if they collapse when life gets slightly weird.

Here is what stuck.

1. Calendar surgery

If the risk band is high, I make one of three cuts:

• Move one meeting.
• Convert a meeting to async updates.
• Block a new 30-minute buffer between two heavy calls.

One change. Not five. One concrete cut buys a surprising amount of breathing room.

2. Micro breaks with rules

I do not trust myself to "just take breaks" when I am in builder mode. So I put rules around the interventions:

• Walks must be outside, no phone, minimum 10 minutes.
• Breathing sessions are 5 minutes max, one track, no apps that invite tinkering.
• Power naps are 20 minutes hard limit with a single alarm.

The AI can then recommend specific things like “10-minute outside walk at 15:00” because it knows what the rules look like.

3. Hard stops on mental load

If the system predicts high stress and my evening is already packed with baseball or family stuff, it pushes me to make earlier tradeoffs:

• Pull a feature from the sprint.
• Drop a non-critical refactor.
• Write a "good enough" version of a deliverable instead of tweaking visuals for an extra hour.

I hate doing less. But I hate being useless at practice with my team even more. That tradeoff keeps me honest.

How accurate is this, really?

I tracked this part manually for four weeks.

At the end of every day I logged one number:

"Actual stress, 1 to 5."

Then I compared it to the AI prediction from that morning.

The rough stats looked like this:

• Within 1 point: about 80 percent of days.
• Exactly right: around 50 percent.
• Completely off (2+ points): 2 or 3 days out of 28.

The misses were interesting. Two patterns:

• Positive surprises. A meeting got cancelled last minute or a tricky feature fell into place early. Stress prediction ended up too high.
• Hidden emotional stuff. The model cannot see arguments, bad news, or random life chaos. Stress prediction ended up too low.

So no, this is not an oracle. I see it more like a weather forecast that nudges my planning. You still bring a jacket sometimes even if the app says 20 percent chance of rain.

Where AI actually helps, and where it does not

I think AI is overrated as a magic planner and underrated as a consistent pattern mirror.

Here is where it helps me:

• It remembers all the little correlations I am too busy to hold in my head.
• It compresses a lot of raw data into one decision: "Should I cut something today or not?"
• It stops me from rationalizing that "this week is special" for the 17th time.

And here is where it does not help at all:

• It cannot feel my body. If my gut says "stop", that beats the model.
• It cannot set my priorities. It only optimizes based on what I feed it.
• It happily optimizes bad goals. If I frame constant output as success, it will push me toward that.

So I treat it like a slightly obsessive assistant. Very good at tracking, mediocre at values.

Building your own version without going insane

If you want to build something similar, I would ignore everything that looks pretty and focus on three boring constraints:

1. Can you update it automatically, every day, without touching anything?
2. Does it end in one concrete message that tells you what to change?
3. Can you ignore it for 24 hours without the system breaking?

That means:

• Start with one wearable, not four.
• Use one LLM endpoint with one prompt, not a zoo of agents.
• Send yourself one message in one channel, not five dashboards.

Once that is stable for a few weeks, then you can get cute with extra signals, nicer visualizations, or more complex models. Most people flip that order and then wonder why they stop using their own tools.

Why I keep this system, even when it is annoying

Some mornings I open the forecast and feel mildly attacked. It tells me exactly what I do not want to hear.

"Your sleep was trash. Move that 16:30 call or you will hate yourself at 21:00."

Past me would have ignored that feeling and pushed through. Then I would be wired at night, useless the next day, and snappy with people who did not deserve it.

Now I get a quiet, data-backed nudge before the spiral. Not perfect. Just earlier.

That is enough to change how my weeks feel.

If you are building your own AI-driven biohacking stack, I would anchor everything on that simple goal: move the moment of awareness forward by a few hours, then make the right choice the easy one.

Fire alarms are loud. Sprinklers are boring. I will take boring, every time.

Why I Started Animating My Sleep

I track my sleep aggressively. Oura, Apple Health, occasional Whoop data exports when I borrow a strap from a friend. The problem is always the same. Nice charts in the app, useless CSV once you export.

I wanted something I could embed on my own site. A visual that actually feels alive. Not another static stacked bar chart screenshot.

So I built a small CSS animation system that turns sleep stages into a moving timeline. Light, deep, REM, awake. All mapped to colors, durations, and subtle motion. The goal was simple: you hit the page and your brain instantly knows whether the night was trash or decent.

The Data I Started With

I am not piping real-time Bluetooth data into the browser. This is not that kind of setup. I work with nightly exports.

For one night the data usually looks like this after I normalize it:

const sleepStages = [
  { stage: 'light', start: '23:10', end: '23:45' },
  { stage: 'deep',  start: '23:45', end: '00:20' },
  { stage: 'rem',   start: '00:20', end: '00:45' },
  { stage: 'light', start: '00:45', end: '01:30' },
  // ...
];

I convert these into relative minutes from sleep start so the browser does not care about clock time. Just total duration in minutes, and the offset for each stage.

On the frontend I end up with something closer to:

const normalized = [
  { stage: 'light', startMin: 0,  durationMin: 35 },
  { stage: 'deep',  startMin: 35, durationMin: 35 },
  { stage: 'rem',   startMin: 70, durationMin: 25 },
  // ...
];

That is all I need for the animation. A start, a duration, and a label.

The Visual Metaphor: A Night As A Line

I tried fancy radial graphs and layered blobs. They looked cool for about 10 seconds, then my brain stopped caring.

The simplest metaphor actually worked best. A horizontal bar that represents one night. Split into segments. Each segment gets a color and a subtle animation that matches the stage.

• Light sleep: soft, slow pulse
• Deep sleep: very stable, barely moving
• REM: more active shimmer, hint of motion
• Awake: sharp, noticeable flicker

I want to be able to glance at a week of these bars and see patterns. Too much REM at the wrong time. Chopped deep sleep. Extended wake between 3 and 4 AM after a late-night coding session.

Building The Timeline Layout With Plain CSS

The layout is just flexbox. Nothing exotic. I like boring layout code for things that should not break.

<div class="sleep-night" data-total-min="430">
  <div class="sleep-stage stage-light" style="--start:0; --duration:35"></div>
  <div class="sleep-stage stage-deep"  style="--start:35; --duration:35"></div>
  <div class="sleep-stage stage-rem"   style="--start:70; --duration:25"></div>
  <!-- etc. -->
</div>

I use CSS custom properties for --start and --duration. That keeps JS stupid simple, and lets CSS handle positioning and animation timing without inline calc spam.

The container defines the total minutes as a property. That gives me a clean way to convert minutes to percentage width.

.sleep-night {
  --total: 430; /* total sleep in minutes */

  position: relative;
  display: flex;
  height: 18px;
  border-radius: 999px;
  overflow: hidden;
  background: #050712;
}

.sleep-stage {
  position: absolute;
  top: 0;
  bottom: 0;
  left: calc(var(--start) / var(--total) * 100%);
  width: calc(var(--duration) / var(--total) * 100%);
}

I prefer absolutely positioned segments over flex children for this. Flex introduces rounding issues across many segments. Absolute keeps control tight and visually clean.

Colors That Actually Read In The Dark

I usually look at this data late at night or early morning. Dark mode first. So color choices matter.

• Light sleep: muted blue
• Deep sleep: dark teal
• REM: violet accent
• Awake: sharp orange

.stage-light { background: #2f6fff; }
.stage-deep  { background: #0b8b6d; }
.stage-rem   { background: #9b5bff; }
.stage-awake { background: #ff8a3c; }

None of these are perfect from a scientific standpoint. I am not trying to publish a paper. I want a quick emotional read. Blue-ish calm, violet activity, orange interruption.

Matching Motion To Sleep Stages

The real fun starts when you give each stage its own animation language. This is where CSS actually becomes useful, not just decorative.

I kept one constraint. Animations should communicate state. Not distract from it.

Light Sleep: Gentle Breathing Pulse

Light sleep is where I spend most of the night. It should feel soft, stable, slightly alive.

@keyframes lightBreath {
  0%   { opacity: 0.85; transform: scaleY(1); }
  50%  { opacity: 1;    transform: scaleY(1.04); }
  100% { opacity: 0.85; transform: scaleY(1); }
}

.stage-light {
  animation: lightBreath 6s ease-in-out infinite;
  transform-origin: center;
}

The subtle vertical scale is barely visible, but your eyes register it as a calm breathing rhythm. If it distracts you, you tone it down to 1.02. Tiny tweaks matter with sleep visuals.

Deep Sleep: Almost No Motion

Deep sleep is the prize. When I hit decent deep sleep blocks, I want the bar to look like a solid block of calm.

I keep animation here minimal. Just enough shimmer to avoid dead pixels.

@keyframes deepStill {
  0%, 100% { filter: brightness(0.9); }
  50%      { filter: brightness(1); }
}

.stage-deep {
  animation: deepStill 10s ease-in-out infinite;
}

Ten second cycles feel right. Long, lazy, almost not there. If I speed it up, deep sleep starts to look nervous, which is the opposite of what I want.

REM: Lighter, More Active Motion

REM is where my dreams go weird, and my tracker usually shows more variability. So I let CSS be a bit more expressive here.

@keyframes remShimmer {
  0%   { opacity: 0.7; filter: blur(0); }
  50%  { opacity: 1;   filter: blur(1px); }
  100% { opacity: 0.7; filter: blur(0); }
}

.stage-rem {
  animation: remShimmer 4s ease-in-out infinite;
}

A tiny blur pulse gives REM a dreamy quality without turning the whole bar into a neon mess. If your GPU is crying, you can drop the blur and just modulate opacity.

Awake: Make The Interruptions Loud

Awakenings are the parts I actually want to avoid. So they get the most obvious motion. Short, sharp flicker, not a gentle pulse.

@keyframes awakeFlicker {
  0%, 100% { opacity: 0.4; }
  20%      { opacity: 1; }
  40%      { opacity: 0.4; }
  60%      { opacity: 1; }
  80%      { opacity: 0.4; }
}

.stage-awake {
  animation: awakeFlicker 1.5s steps(4, end) infinite;
}

The steps() timing function gives it that digital heartbeat feel. Not smooth, almost jittery. Which is basically what a 3 AM bathroom trip feels like.

Time-Based Animation, Not Just Decoration

Flat animations are cute. What I actually wanted was to tie animation to time. The bar should tell me when in the night something happened, not just that it existed.

For that I sync animation delays to the position of the stage within the night. Early stages animate earlier, later segments lag behind. It feels like the night plays out on repeat.

.sleep-night {
  --total: 430;
  --night-speed: 60s; /* one loop represents the entire night */
}

.sleep-stage {
  animation-duration: var(--night-speed);
  animation-iteration-count: infinite;
  animation-timing-function: linear;
  animation-delay: calc(var(--start) / var(--total) * var(--night-speed) * -1);
}

I use a negative delay trick. Each stage looks like it started in the past, so the loop always shows the full night flowing. You can scrub the whole thing by changing --night-speed on the container.

This is where CSS custom properties pull their weight. JS only sets minutes. CSS translates that into both position and timing.

Adding Context: Axes Without A Chart Library

A pure animated bar looks cool but slightly abstract. I needed just enough context to make it usable.

So I added a light time axis below each night. Not a full chart component. Just flex children with 1, 2, 3, 4, 5, 6, 7 written under subtle ticks.

<div class="sleep-row">
  <div class="sleep-night">...</div>
  <div class="sleep-axis">
    <span>23:00</span>
    <span>01:00</span>
    <span>03:00</span>
    <span>05:00</span>
    <span>07:00</span>
  </div>
</div>

.sleep-axis {
  display: flex;
  justify-content: space-between;
  font-size: 11px;
  color: #85879c;
  margin-top: 6px;
}

It is not pixel-perfect to the minute, and I do not care. It gives my brain a quick sense of when the REM cluster hit. That is enough.

Handling Multiple Nights Without Melting The GPU

One night looks fine. A month of nights with four stages each, all animated, will start to feel heavy on weaker machines.

I did not want to switch to static images for history, so I added a very simple rule. Only animate the current week by default. Everything else falls back to static bars until you hover.

.sleep-night[data-period="archive"] .sleep-stage {
  animation: none;
}

.sleep-night[data-period="archive"]:hover .sleep-stage {
  animation-play-state: running;
}

.sleep-night .sleep-stage {
  animation-play-state: running;
}

If you really want to go nerd-level on performance, you can prefer-reduced-motion this entire thing.

@media (prefers-reduced-motion: reduce) {
  .sleep-stage {
    animation: none !important;
  }
}

I think any motion-heavy data viz should respect that. People do not expect their sleep page to be the most visually aggressive thing in their browser.

What I Actually Learned From The Animation

The point of all this is not to flex CSS chops. I wanted better feedback loops on my rest experiments.

Once I had a week of animated nights on screen, patterns hit me fast.

• Late caffeine shows up as bright orange awake blocks exactly between 2 and 4 AM.
• Heavy evening strength work shifts my first deep sleep block later, which I do not like.
• Low-stress days produce absurdly clean deep segments with barely any REM jitter early on.

Some of that is visible in standard tracker apps, but the motion layer makes it more visceral. You do not just see that deep sleep was 18 percent. You watch that fragile block get chopped up across the night.

Why CSS And Not A Chart Library

I could have thrown this into D3 or a React charting library. I did not, on purpose.

CSS gives me a few things I like here.

• Animation is declarative. No requestAnimationFrame loops.
• Styling and behavior live in the same layer, which makes iterating on metaphors fast.
• I can drop it into any static page without bundling headaches.

For numeric overlays and complex tooltips a chart library wins. For this kind of high-level, pattern-first, almost ambient visualization, CSS felt cleaner.

Where I Want To Take This Next

This is version one. It already replaced three separate views in my personal dashboard.

Next I want to tie this to HRV and resting heart rate trends. Same bar, second subtle overlay. Maybe a barely visible gradient that creeps upward when my heart rate stays elevated all night.

I also want to auto-generate small embed snippets. That way I can drop my weekly sleep bar into a private note or a client check-in doc when I explain why their Slack messages at midnight are a bad habit.

If you build anything similar, I suggest you skip the fancy visualizations at first. Start with a single bar, four colors, and one simple animation per stage. Wire it straight to your own data. Your nervous system will tell you very quickly if the motion helps or just decorates.

Sovereign AI sounds fun until it touches your blood

I love the idea of sovereign AI. Your own weights. Your own data. No corporate API in the loop. Pure autonomy.

That is all cute until the model starts suggesting you stack two research chemicals that both elongate QT interval while you sit there with an average resting HRV and a family history of heart issues.

Now it is not a cool ML project anymore. It is your heart on the line.

I run a lot of biohacking experiments on myself. Sleep protocols. Supplements. Bloodwork-driven tweaks. I also build tools, so of course I wired AI into that stack. But the first time my “sovereign coach” confidently suggested a combination that no sane human doctor would rubber stamp, I realized I needed proper governance, not vibes.

This post is me writing down the ethical and technical guardrails I actually use to keep autonomous biohacking systems useful without letting them quietly drift into unsafe territory.

The fantasy of fully autonomous biohacking

The fantasy version looks like this.

• You sync wearables, labs, training logs into a local data lake.
• A local model continuously updates your “biological strategy”.
• It spits out protocol changes, supplement stacks, training cycles.
• You just execute, like a robot following a playbook.

As a builder, that picture is intoxicating. Feedback loops. Personalization. Zero marginal cost coaching.

As a human, I think that picture is dangerous. Because the model optimizes what you define, not what you actually care about when something goes wrong.

If you tell the system “optimize HRV” and do not add constraints, it might happily trash your deep work capacity and social life to get there. Or nudge you to combine interventions that each look okay in isolation but interact in messy ways in the real body you live in.

My stance: autonomy is earned, not granted

I treat AI like a very fast, very confident intern that never gets final say on interventions that hit my biology directly. It has to earn scope.

That means a few hard rules:

• No black box control of anything that can hurt me within 24 hours.
• No direct write access to devices that change my physiology.
• No opaque optimization targets. I want to see what it thinks it is doing.

I know some people fantasize about an AI that directly adjusts their smart drug dispenser, sauna, cold plunge, and sleep tech on the fly. Maybe one day. For now, I think that is reckless.

Instead, I structure “sovereign AI” for biohacking as a layered governance system. Permissioned. Observable. Interruptible.

The three-layer governance stack I actually use

When I say “sovereign AI governance”, I do not mean some abstract policy text. I mean specific constraints wired into the system.

Here is the structure that feels sane to me.

1. Data governance: what the model is even allowed to see

Everyone jumps to outputs. I think the inputs are more important.

I split my data into three buckets:

• Ambient data: sleep scores, step counts, HRV, bodyweight, training volume.
• Intervention data: supplements, meds, stacks, dosages, protocols, timestamps.
• Red flag data: arrhythmia notes, weird side effects, family history, diagnosed issues.

The model gets ambient and intervention data by default. Red flag data is only accessible through specific tools with strict prompts around it.

Why separate it like this? Because I want to control when the model is allowed to reason about risk. That sounds backwards at first. Shouldn’t more data always be better?

In practice, I have seen models over-index on scary stuff when you dump everything in at once. They catastrophize. They suggest you stop everything. Or they ignore low-probability but high-impact risks because nothing in the prompt tells them to treat those as special.

So I make risk an explicit mode. If an intervention crosses a certain threshold, the system must open the “red flag” tool and evaluate specifically against that set, not just treat it as background context.

2. Policy governance: hard rules before clever ideas

This is the part that actually feels like “governance”. It is a set of hard-coded rules that sit between the model and any recommendation.

Examples from my own system:

• No multi-drug stack suggestions unless every component has at least one human RCT in healthy adults, or the idea is clearly framed as experimental with a strong warning.
• No dose escalation above current dose without a 7 day washout period at the prior level, and no escalation at all on anything that touches blood pressure or heart rate directly.
• No recommendation that conflicts with an existing medical prescription, even if I “overrule” it in natural language. The system must treat the conflict as a hard block and explain it.
• No binary medical claims. No “this is safe”, only “this appears low risk in population X under conditions Y, with uncertainties Z”. Language is regulated here.

I implement these as validators that inspect the AI’s draft output. If something trips a rule, the system either forces a rewrite or downgrades the suggestion into a question I should ask a human professional.

This is not vibes. It is code that rejects suggestions, just like a failing test in CI.

3. Execution governance: who presses the button

This is where many people get sloppy. They build a fancy reasoning system, then wire it straight into automation.

I separate “decision” from “execution” hard:

• AI can propose interventions.
• AI can schedule reminders in my task system.
• AI cannot directly control anything that doses, zaps, heats, cools, or otherwise manipulates my body.

If I want to start a protocol, I have to explicitly accept it. Usually with friction: typing in the stack, confirming the doses, and setting a review date.

That friction is not a bug. It is a conscious design choice. I want a moment where I can feel my gut say “hold on, this feels dumb” before the system pushes me forward.

Ethics in practice: where I actually say “no”

Ethics sound noble until they collide with something useful. I had to decide where I personally draw the line.

Here are three spots where my system currently refuses to help, even if it could.

1. Cognitive enhancement beyond lifestyle basics

The model will happily talk about sleep, exercise, light exposure, and basic nutrition for cognitive performance. It will not design aggressive nootropic stacks for me.

I think the temptation to stack “just one more” stimulant, cholinergic, or racetam is too high if the AI keeps suggesting options with plausible scientific language attached.

So I hard-limit it. It can explain mechanisms. It can summarize papers. It cannot assemble experimental over-the-counter stacks that look like weak prescription cocktails.

2. Hormonal modulation without a doctor in the loop

This is a big one. Hormones touch everything. Mood, sleep, sex, recovery, metabolism.

My model has access to my labs. It can see testosterone, thyroid markers, cortisol. However, the governance layer blocks any intervention that would materially change hormone levels without an explicit “this must be discussed with an endocrinologist” banner at the top.

No gray area. No “maybe try this herbal extract that might slightly nudge X”. If the intent is hormone modulation, it gets flagged as such and pushed into a “human required” track.

3. Anything that hides uncertainty

The model must expose what it does not know. I bake that into prompts and validators.

Any recommendation above a trivial level of impact must include:

• Which populations the evidence is based on.
• How strong the evidence is, roughly categorized.
• Key unknowns or contested points.

If the system starts speaking with unjustified certainty, that is an error. Not just a style issue.

I would rather get a slightly annoying “here is what we do not know” paragraph than silently inherit overconfidence from a model trained on human text that pretends to know more than it does.

Local, sovereign, but not unsupervised

Everything I described lives locally where possible. Models on my own hardware. Data in my own storage. Tools that call out to third parties are tightly scoped.

So yes, it is “sovereign AI”. It runs under my control. But I do not treat sovereignty as a license to let the system do whatever it wants.

Sovereign to me means three concrete things:

• Inspectable: I can see prompts, logs, and decisions.
• Mutable: I can change policies and rules in code.
• Revocable: I can kill it in one step if it starts behaving oddly.

That last point is important. I have an actual kill switch script that shuts down model servers and tools in one go. It is boring shell code. I test it occasionally.

I do not think you are running sovereign AI if you cannot pull the plug without asking a cloud provider for permission.

Where innovation still fits inside the box

With all these constraints, you might think the system becomes useless. It does not. It just changes what you ask it to do.

Here is where I let it be aggressive and creative.

• Protocol design around sleep hygiene, light, temperature, and behavioral tweaks. These are low downside, high upside, and easy to revert.
• Pattern spotting in my own logs. It is very good at catching subtle patterns between training, caffeine timing, and sleep that I would miss.
• Paper triage. There is no way I am reading every study on every supplement. The AI filters and groups them for me with quality flags.
• Counterfactuals: “What if I move this session here, shift carbs there, and change bed time by 30 minutes.” That sort of simulation is perfect for an AI assistant.

Innovation does not require the model to control hardware. It requires the model to help you see better and think faster, while you keep your hands on the steering wheel.

What I would not trust my future self with

I want to end with a future oriented check. Whenever I design a new feature, I ask one question:

If I was sleep deprived, stressed, and desperate for an edge, would I trust myself to use this feature safely?

If the answer is no, the feature needs more governance. Or it gets cut entirely.

Because that is the real test. Most biohacking disasters do not happen when you are calm, rested, and thinking clearly. They happen when you are on the edge, chasing a quick fix.

Sovereign AI makes it easier to build those quick fixes. It also makes it easier to codify your non-negotiables in a way a tired version of you cannot talk their way around.

I do not want an AI that “optimizes my biology”. I want an AI that respects my constraints more than my impulses.

That is the real governance challenge. Not how clever the model is, but how stubborn your guardrails are when you are tempted to ignore them.

Why I Stopped Trusting Generic Nutrition Advice

Nutrition advice on the internet feels like religion. Keto vs high-carb. Carnivore vs plant-based. Everyone is right, as long as you ignore the people they broke along the way.

I coach baseball, write code, and experiment on myself. My schedule is messy. Double training days, late games, deep work blocks. A fixed “2,000 calories and 150 grams of protein” template never really matched my actual life.

So I decided to wire my diet into a feedback loop. Bloodwork. Wearables. Training logs. Then feed it all into a simple machine learning stack and ask a better question:

Given my body and my schedule, what should I eat today to hit tomorrow feeling dangerous, not wrecked?

This post is not theoretical. I ran this for months. Parts of it sucked. Parts of it were surprisingly effective. I will walk through the exact system, warts included.

The Stack: What I Actually Used

I did not build a fancy neural network from scratch. This is more glue engineering than cutting edge research.

Here is the real stack:

• Data in: Apple Watch, Oura, Cronometer, occasional bloodwork, a Google Sheet for training logs.
• Storage: Postgres for structured data, a folder of CSV exports for sanity checks.
• ML layer: Python with scikit-learn and a bit of XGBoost. Nothing magical.
• AI layer: An LLM that generates actual meal ideas and shopping lists given my macro and micronutrient targets.
• Frontend: A very boring internal web app. Next.js, Tailwind, minimal styling.

I think most biohackers overcomplicate the model and undercomplicate the data. Fancy architecture does not fix trash inputs. I spent more time on logging than on hyperparameters.

The Inputs: Turning My Body Into a Dataset

First, I had to answer a basic question. What signals are strong enough that it is worth feeding them into a model?

I settled on four categories:

• Daily metrics: weight, resting heart rate, HRV, sleep duration and stages, perceived energy.
• Training: type (strength, conditioning, skills), duration, RPE, any soreness notes.
• Food: full macro breakdown plus key micros that I actually care about: omega 3, magnesium, vitamin D, fiber, sodium, potassium.
• Periodic labs: fasting glucose, HbA1c, lipids, CRP, vitamin D, ferritin, B12.

Most of this came from existing tools. Nothing exotic.

• Apple Watch + Oura synced into Apple Health, then exported.
• Cronometer handled nutrition tracking and micronutrients.
• Bloodwork every 3 to 4 months through a standard lab.

The smallest but most annoying part was subjective logging. I built a one-click mobile view that asked three questions each morning:

• “How is your energy?” (1 to 5)
• “Any brain fog?” (yes, neutral, sharp)
• “How do you feel about yesterday’s recovery?” (1 to 5)

Those three fields ended up being more useful than half the fancy metrics. Of course.

The Core Idea: Predict Tomorrow, Eat Today

Most nutrition planning works forward. Set macros, then eat.

I flipped it. I tried to work backward from tomorrow.

Question: Given yesterday’s food and training, how did I feel and perform today?
Goal: Nudge macros and key micronutrients so that future days land in the “high energy, good training, solid sleep” bucket more often.

In practical terms that turned into a simple supervised learning task:

• Features: yesterday’s intake (macros and micros), training load, sleep, current bodyweight, current average HRV.
• Targets: today’s energy score, today’s training performance (scaled 1 to 5), and whether I hit sleep efficiency above a threshold.

I started basic. A gradient boosted model predicting those targets from the features. No deep learning. I wanted decent feature importances and a model that trains in seconds, not hours.

Once the model was semi-reasonable, I asked it a slightly different question through a small optimization loop:

“Given tomorrow is a heavy training day, what macro and micro ranges give me the highest probability of high energy + strong training + decent sleep?”

The output was not a meal plan. It was just numbers:

• Calories: 2,550 to 2,750
• Protein: 165 to 190 grams
• Carbs: 230 to 280 grams
• Fat: 70 to 90 grams
• Fiber: 28 to 36 grams
• Sodium: 3g to 4.5g
• Key micronutrient nudges, like “push magnesium up” or “watch saturated fat”

Good, but not usable yet. I still had to decide what to actually eat.

Where AI Actually Helped: From Numbers To Food

Macros are easy. Meals are hard.

I had this gap between a macro sheet and my fridge. That is where I put the LLM.

The flow looked like this:

1. Model produces target macro and micro ranges for the day.
2. I send that, plus my dietary constraints and what food I have in stock, to the LLM.
3. The LLM generates 3 possible daily meal structures that roughly hit those numbers.

The prompt was very explicit. Stuff like:

Given:
- Target calories: 2600 (+/- 100)
- Protein: 180g (+/- 10g)
- Carbs: 250g (+/- 20g)
- Fat: 80g (+/- 10g)
- Fiber: 30g (+/- 5g)
- Emphasize: magnesium, omega 3, high satiety
- Constraints: no gluten at breakfast, keep prep under 20 minutes on weekdays
- Foods available: chicken breast, eggs, oats, frozen spinach, Greek yogurt, berries, rice, olive oil, potatoes, salmon, etc.

Return:
- 3 daily meal plans
- Each with 3–4 meals and 1 snack
- Include macro estimates for each meal
- Keep instructions short

The first attempts were chaos. The model ignored fiber. It broke calorie budgets. It invented foods not in my pantry. Classic.

After a lot of prompt tightening and some post-processing checks, it got surprisingly useful. I added a validator that recalculated macros using my own food database and flagged any meal plans that were too far off. Those got auto-rejected, and the model had to retry with feedback.

Result: I opened the app in the morning and saw something like:

• Plan A: high carb for evening training.
• Plan B: slightly higher fat and more stable if I had a coding marathon.
• Plan C: lower calories if recovery markers looked rough.

I picked one and hit “send to Cronometer”, which pushed the foods into my tracker through their API. Then I just executed.

Machine Learning That Actually Influenced My Diet

So did the model discover anything interesting? A few patterns kept showing up.

1. My carbs were too random

On heavy training days my carb intake varied wildly. Sometimes 150 grams, sometimes 320. No wonder my sessions felt inconsistent.

The model kept nudging carbs up toward a tighter band on high-load days. Not insanely high, just more predictable. Performance scores improved. RPE for similar loads went down.

2. Magnesium and sleep

I know, everyone talks about magnesium. I thought it was overhyped. Then the feature importances and partial plots basically yelled at me.

Days where magnesium intake tanked correlated with worse sleep efficiency and lower HRV the next morning. I shifted more food-based sources instead of just supplements. Pumpkin seeds, spinach, some dark chocolate. My sleep data looked less noisy after a few weeks.

3. Late fat bombs wrecked my evenings

High fat dinners plus late training meant my sleep latency exploded. I knew this subjectively, but the model reinforced it. The probability of hitting my “good sleep” threshold dropped sharply when calories and fat were both stacked late.

I changed one rule. After 7 pm my plates became lighter on fat and heavier on low fiber carbs and protein. Sleep improved more than any gadget upgrade I tried in the last year.

Where The Whole Thing Broke

Not everything worked. Some parts were annoying enough that I almost trashed the project.

Data quality

Nutrition tracking is rough. Even if you weigh your food there is noise everywhere. Restaurant meals. Wrong database entries. “One large egg” that somehow becomes 90 calories instead of 70.

The model learned some garbage correlations from this. For example, it decided “sushi night” predicted poor sleep. The real problem was that sushi often came with late social evenings and extra alcohol, not the rice or fish.

I had to manually label some “social nights” and add that as a feature before the pattern made sense. Messy human life always leaks into data like that.

Overfitting to short-term signals

My early runs tried to react to every small bump in HRV or energy. That created a weird pendulum effect. One bad night and the macros would swing too hard the next day.

I fixed this with more smoothing. Rolling averages, and fewer sharp tweaks. Instead of “change your macros by 20% today”, the system pushed small adjustments over several days unless things looked really off.

LLM creativity vs accuracy

LLMs like to be creative. Creativity in recipes is fine. Creativity in nutrient math is not.

Without a tight validator, the room-temperature IQ of the meal plans was impressive. Wild calorie gaps. Miscounted protein. I had to treat the LLM as a UI for meal structure, not a source of truth for numbers. All macro math happened in my own code.

How I Use It Now (And What I Stopped Doing)

I no longer run daily model training. The full closed-loop experiment taught me enough that I simplified the system.

Here is the current setup:

• Weekly batch training on recent data.
• The model suggests macro ranges for three categories: heavy training day, light training day, rest day.
• I lock in those targets for the week, then let the LLM handle daily meal variation.

The system still looks at sleep and recovery, but mostly to flag outliers. If HRV and sleep both crash, it suggests a lower-calorie, higher-carb, easy-digesting day with less fat. Nothing extreme.

Things I stopped doing:

• Daily macro micromanagement from the model.
• Monstrous feature sets. I cut half the features that never moved the needle.
• Obsessing about perfect logging on weekends. The model already treats weekend data with suspicion.

The net result feels calmer. The AI is now more like a very data-obsessed nutrition assistant that sets the rails. I still drive.

The Stuff I Would Keep If I Had To Start Over

If I wiped the codebase tomorrow and rebuilt from scratch, I would keep these pieces.

1. One simple question for the model

Trying to predict everything made the model noisy and my life annoying.

Now I use a single core question: “Given the training plan and recent recovery, what macro and micro ranges increase my chances of high energy and solid performance tomorrow?”

That is it. Everything else is secondary.

2. Narrow micronutrient focus

I do not try to optimize every vitamin. That feels like fake precision.

I focus on a few that my data actually supports as levers for me: magnesium, omega 3, fiber, and sodium/potassium balance. The model cares about those. The rest are “nice to have” and mostly handled by eating real food.

3. AI as a UX layer, not an oracle

The LLM is best used as glue. It translates constraints and targets into human-friendly meal ideas. It is not the authority on nutrition science. It is a fast interface.

Macros, feature engineering, and evaluation live in code I can audit. The AI just helps me stick to the plan without wanting to throw my phone at the wall.

Should You Do This? Probably Only If You Enjoy This Kind of Pain

Would I recommend this to everyone? No.

If you hate logging food, do not own a wearable, and do not care about your data, then this system will die in a week. You would get more value from lifting three times a week and walking outside.

But if you already track, and you like building weird internal tools, using machine learning and AI for nutrition can push you out of default mode. It forces you to confront how messy your habits are compared to your theory of your habits.

For me the main win was not “AI discovered a magical macro formula”. It was this:

• My heavy training days feel more predictable.
• My sleep is less random.
• I removed a ton of daily food decisions from my brain.

The code is not special. The model is not special. The feedback loop is.

Hook your body data into something that can learn, add a layer that speaks human (the LLM), and then see what kind of diet falls out the other side. Just keep a hand on the wheel.

You are still the experiment. Not the model.

Why I Care About Brainwave Dashboards

I track my brain a lot. Muse, OpenBCI, random EEG headbands I probably should not trust. I write code, then I look at squiggly lines and pretend I understand my own brain.

Most neurofeedback dashboards I see are a mess. Overloaded charts. Tiny fonts. Panels that jump around when the window resizes. It feels like the UI is stressed out, which is the exact opposite of what I want while training alpha waves.

So I started building my own layouts. I wanted one thing: a stable, intuitive grid that could handle real-time brainwave data without the whole interface wobbling every time the browser width changed.

I stopped reaching for complex JS layout logic and pushed CSS Grid as far as I could. It turned out to be the right hammer.

The Mental Model: Map Your Brain to a Grid

The biggest mistake I see in these dashboards is people thinking in components before they think in structure. They drop a chart library, a sidebar, a couple of cards, and then try to glue it together with flexbox everywhere.

For neurofeedback, I think in three zones first:

• Primary focus zone: one big chart or brainwave strip that matters right now.
• Context zone: band powers, metrics, HRV, session timers.
• Controls zone: protocol selector, thresholds, start/stop, notes.

That maps nicely to a simple grid. One layout to rule the whole thing.

.dashboard {
  display: grid;
  grid-template-columns: minmax(260px, 320px) 2fr 1.3fr;
  grid-template-rows: auto 1fr auto;
  grid-template-areas:
    "sidebar main metrics"
    "sidebar main metrics"
    "controls main metrics";
  gap: 1.2rem;
  height: 100vh;
  padding: 1.2rem;
  box-sizing: border-box;
}

.sidebar   { grid-area: sidebar; }
.main      { grid-area: main; }
.metrics   { grid-area: metrics; }
.controls  { grid-area: controls; }

That grid gives me a stable skeleton. I can swap charts inside .main without changing the layout. I can replace metrics content with something else, but it will still live in the same mental slot.

For neurofeedback, that consistency matters. When your attention is half on your breath and half on the chart, you do not want to keep hunting UI elements.

Why I Use Grid Over Flexbox Here

Flexbox is good at one dimension. It is a row that wraps, or a column that stacks. It does not know that the main chart is conceptually aligned with the controls below it and the metrics on the right.

CSS Grid understands the whole board. Neurofeedback dashboards are boards. They have spatial meaning. Where a tile lives matters.

I started with flex layouts years ago and always ended up writing little JS hacks to fix height mismatches, especially when charts render at different speeds. With Grid I can just say:

.main,
.metrics,
.sidebar,
.controls {
  min-height: 0;
  min-width: 0;
  overflow: hidden;
}

Then I let the grid define the relationships. No resize observers. No window.innerHeight math in React. It is simply: the grid owns the layout, the components own their content.

Real-Time Data Without Layout Jitter

EEG data does not care about your CSS. It comes in when it feels like it. The worst UX is a layout that keeps shifting as labels, values, and legends change size.

I had this problem early on with band power cards. Values like 9.3 looked fine, but then 12.87 showed up and pushed everything sideways. That subtle jitter is surprisingly distracting.

I fixed it with a mix of grid, fixed tracks, and typographic discipline.

.metrics {
  display: grid;
  grid-template-columns: repeat(2, minmax(0, 1fr));
  grid-auto-rows: minmax(80px, auto);
  gap: 0.8rem;
}

.metric-card {
  display: grid;
  grid-template-rows: auto 1fr;
  padding: 0.8rem 1rem;
  background: #080b10;
  border-radius: 8px;
}

.metric-label {
  font-size: 0.8rem;
  letter-spacing: 0.08em;
  text-transform: uppercase;
  opacity: 0.7;
}

.metric-value {
  font-family: system-ui, -apple-system, BlinkMacSystemFont, sans-serif;
  font-variant-numeric: tabular-nums;
  font-size: 1.6rem;
}

font-variant-numeric: tabular-nums is key here. The numbers change, but the width does not dance.

Grid does the rest. Each card gets its own little subgrid. The heights are stable because I am not letting content dictate the outer layout. It sits inside a grid track that already knows its place.

Making the Main Brainwave Strip Actually Readable

The main chart is the thing your eyes hang on. That is the anchor. If you mess this up, the rest does not matter.

I like a wide strip at the top of the main area, then a 2 or 3 column grid below with supporting views. Think: raw EEG, then processed power spectrum, then maybe a reward indicator.

.main {
  display: grid;
  grid-template-rows: minmax(180px, 260px) minmax(0, 1fr);
  gap: 0.8rem;
}

.main-primary-chart {
  background: #05070b;
  border-radius: 8px;
  overflow: hidden;
  display: flex;
}

.main-secondary-grid {
  display: grid;
  grid-template-columns: repeat(3, minmax(0, 1fr));
  gap: 0.8rem;
}

.main-secondary-panel {
  background: #05070b;
  border-radius: 8px;
  overflow: hidden;
}

The grid inside .main separates concerns. The top track is fixed in the layout, so the chart library can re-render a hundred times per minute without causing layout thrash.

The trick is minmax(0, 1fr). Without that, nested grids and chart canvases can overflow in weird ways, especially if the parent has padding and the child tries to be clever with width. I broke this enough times that I now use minmax(0, 1fr) by default inside any dashboard-like grid.

Responsive Without Breaking The Mental Model

Most neurofeedback dashboards I see give up on mobile. They just squash everything or hide half the UI. I think that is lazy.

I want a consistent mental model across sizes. Same zones, different stacking.

Grid template areas let me keep the semantics and just rewire the layout for smaller screens.

.dashboard {
  display: grid;
  grid-template-columns: minmax(260px, 320px) 2fr 1.3fr;
  grid-template-rows: auto 1fr auto;
  grid-template-areas:
    "sidebar main metrics"
    "sidebar main metrics"
    "controls main metrics";
}

@media (max-width: 1100px) {
  .dashboard {
    grid-template-columns: 260px minmax(0, 1fr);
    grid-template-rows: auto 1fr auto;
    grid-template-areas:
      "sidebar main"
      "sidebar main"
      "controls main";
  }

  .metrics {
    grid-column: main;
    grid-row: 2;
    align-self: flex-start;
  }
}

@media (max-width: 768px) {
  .dashboard {
    grid-template-columns: minmax(0, 1fr);
    grid-template-rows: auto auto auto auto;
    grid-template-areas:
      "main"
      "metrics"
      "sidebar"
      "controls";
    height: auto;
  }
}

On desktop you get the full control center. On tablets you lose one column but keep the side anchor. On phones you still see the main chart first, then metrics, then the stuff you do not touch as often.

I am fine with hiding some secondary visual fluff on small screens, but I never move the main chart below the fold. That is a hard rule.

Controls That Do Not Compete With The Data

Controls are important. They are not more important than the data. I put them in their own grid area, but make that area visually quieter.

.controls {
  display: grid;
  grid-template-columns: repeat(3, minmax(0, 1fr));
  gap: 0.8rem;
  align-content: start;
}

.control-group {
  background: #05070b;
  border-radius: 8px;
  padding: 0.8rem 1rem;
}

.control-group h3 {
  font-size: 0.9rem;
  margin: 0 0 0.5rem;
}

@media (max-width: 1100px) {
  .controls {
    grid-template-columns: repeat(2, minmax(0, 1fr));
  }
}

@media (max-width: 768px) {
  .controls {
    grid-template-columns: minmax(0, 1fr);
  }
}

The layout rules keep this from stealing attention from the main strip. I never let the controls area grow taller than it has to. It sits under the main view like a cockpit, not like a second dashboard fighting for focus.

Because it is a grid area, I can also quickly run A/B tests on control placement. Want to move the protocol selector into the sidebar and bring session notes closer to the main chart? That is one CSS change using areas, not a giant JSX refactor.

Handling Multiple Brain Regions Without Visual Chaos

Once you start working with more channels and regions, the UI tends to explode. Fp1, Fp2, C3, C4, O1, O2, and so on. Suddenly you have more panels than screen.

Instead of stacking everything, I partition channels into a grid of small multiples. Same layout, different data. Grid is perfect for that.

.regions-grid {
  display: grid;
  grid-template-columns: repeat(auto-fit, minmax(140px, 1fr));
  gap: 0.6rem;
}

.region-panel {
  background: #05070b;
  border-radius: 6px;
  padding: 0.4rem 0.6rem;
  display: grid;
  grid-template-rows: auto minmax(60px, 1fr);
}

.region-label {
  font-size: 0.75rem;
  opacity: 0.7;
}

.region-chart {
  overflow: hidden;
}

auto-fit plus minmax lets the UI breathe. On a big monitor you see many channels in one glance. On a laptop it shrinks to 2 or 3 per row without you touching any JS.

I tried carousels for this once. Never again. For neurofeedback, visual scanning speed matters more than fancy UI.

Accessibility And Dark Mode In A High-Contrast World

Brainwave UIs usually go dark. Black backgrounds, neon lines, aggressive gradients. It looks cool and murders legibility within 20 minutes.

Using Grid helps here in a subtle way. Because I control layout at the container level, I can keep the visual complexity mostly inside chart canvases. The layout shell stays simple and consistent.

:root {
  color-scheme: dark;

  --bg: #040609;
  --bg-elevated: #060910;
  --border-subtle: rgba(255, 255, 255, 0.03);
  --accent: #4fd1c5;
}

body {
  margin: 0;
  background: radial-gradient(circle at top, #050816, #020308 55%);
  color: #f4f7ff;
  font-family: system-ui, -apple-system, BlinkMacSystemFont, sans-serif;
}

.dashboard > * {
  border: 1px solid var(--border-subtle);
  background: linear-gradient(135deg, var(--bg-elevated), #05070c);
}

Each grid cell effectively becomes a card with predictable contrast. Charts live inside and can be tuned independently. I keep text contrast high, limit accent colors, and let the grid give the whole page structure so my brain is not wasting cycles parsing layout shifts.

Working With Real Hardware Instead Of Placeholder Boxes

This layout only started to make sense once I plugged it into an actual EEG stream. With placeholders everything looks balanced. With noisy data the weak spots show up fast.

Two things broke immediately:

• Latency indicators got buried in the metrics grid.
• Session timer was in the wrong place for my eyes.

Both fixes were layout problems, not component problems.

I pulled latency into the top of the main chart track using subgrid-like thinking.

.main-primary-chart {
  display: grid;
  grid-template-rows: auto minmax(0, 1fr);
}

.latency-bar {
  display: flex;
  justify-content: space-between;
  align-items: center;
  padding: 0.2rem 0.7rem;
  font-size: 0.75rem;
  opacity: 0.8;
}

.raw-chart {
  min-height: 0;
}

Then I moved the session timer into the controls area but aligned it visually with the main chart using grid lines instead of flex shenanigans. That change was one CSS edit to the areas definition, not a React component shuffle.

Working with live data is where Grid really shows its value. The structure holds even when the content gets weird.

Takeaways If You Are Building One Of These

If you are working on a real-time brainwave monitoring app and your UI feels jittery, there is a good chance your layout is trying to be clever at the component level instead of being honest at the grid level.

• Define clear zones first. Sidebar, main, metrics, controls.
• Use grid-template-areas to encode your mental model.
• Use minmax(0, 1fr) and tabular-nums to kill jitter.
• Let charts re-render inside stable grid tracks instead of resizing parents.
• Restructure the layout per breakpoint without breaking zone order.

I treat CSS Grid as the nervous system of the dashboard. The EEG stream can spike and wobble all it wants. The layout stays calm.

That is the whole point of neurofeedback anyway.

Sovereign AI needs a real use case

Every second AI startup pitch ends up with the same slide: "user-owned data", "sovereign AI", "you control your model". It sounds nice. It is usually hand-wavy.

Healthcare records are where this either gets real or falls apart completely. You cannot fake privacy when test results, diagnoses, and genetic data are on the line. People actually get hurt when you screw this up.

So I spent some time sketching a concrete stack: sovereign AI agents sitting on top of decentralized healthcare records, where the patient is actually in charge. Not metaphorically. Cryptographically.

This is not finished product talk. I am walking through the architecture I would build, the tradeoffs I hit, and why I think blockchain is useful here, but only if you keep it narrow and boring.

What I mean by "sovereign AI" here

I am using "sovereign AI" in a very specific way:

• The AI agent runs on compute the patient controls, or at least can verify.
• The training and context data are explicitly permissioned by the patient.
• All external access to the patient's medical history is mediated by that agent.

So if a hospital, insurer, or research lab wants to use your data, they do not pull a dump of your records. They ask your agent a question. Your agent decides how much to reveal, if anything. You approve or pre-approve that policy.

This turns the AI into a programmable privacy firewall around your body data. That is the goal.

Why decentralized records and blockchain actually help here

I am not a "put it on-chain" maximalist. Most data does not belong on a blockchain. Medical records absolutely do not belong on a blockchain.

What does belong on-chain is coordination: identities, permissions, immutable logs of who asked for what, and what you agreed to. The boring stuff.

The healthcare stack I sketched boils down to three layers.

• Data layer: Encrypted records stored off-chain. Think IPFS, S3, Arweave, hospital systems. The raw bits never touch the chain.
• Control layer: A blockchain or similar distributed ledger that stores access policies, consent receipts, and identity bindings.
• Agent layer: Patient-controlled AI that reads from encrypted data, enforces on-chain policies, and answers queries.

The chain is the source of truth for consent, not content. That is the core distinction. If you get that wrong, you get surveillance in the name of decentralization.

Threat model first, tech second

When I started modelling this, I skipped the shiny parts and asked boring questions.

• Who is most likely to abuse access? Insurers and data brokers, not random hackers.
• What do hospitals actually care about? Liability and workflow friction, not ideology.
• What does the patient want? Convenience until something goes wrong, then control.

That last one matters. If the UX punishes patients for caring about privacy, they will override everything and just sign the "share all" checkbox when the nurse is waiting.

So any sovereign AI setup has to do two things at once:

• Default to strict privacy, machine-enforced.
• Make consent and revocation insanely quick, even when the user is stressed or sick.

I think blockchain is good at the first part. It is terrible at the second part unless you design like a pessimist.

How the patient wallet becomes the control center

I started from the wallet, not the hospital. If the patient is sovereign, the wallet is effectively their operating system.

My baseline design:

• Each patient has a DID (decentralized identifier) that represents their health identity.
• The DID is controlled by a wallet with strong recovery options. Social recovery. Hardware keys. Whatever prevents "lost key = lost history".
• Healthcare providers get their own verified DIDs too, issued by trusted medical authorities.

Every piece of medical data is then linked to a patient DID and a provider DID. The data itself is encrypted using the patient's public key. The provider may keep their own copy, obviously, but the canonical consent story lives around that shared reference.

The blockchain stores small permission records. It knows that provider X can access lab result Y from date A to date B for purpose Z, signed by the patient wallet. If that consent is revoked, the chain reflects it. The agent reads from there.

Your AI agent as the bouncer for every request

Here is where the sovereign AI part stops being buzzword and starts doing work.

Instead of direct data pulls, everything routes through the patient's AI agent.

• A hospital wants your full history? The agent checks on-chain consent, fetches only what is allowed, strips identifiers if needed, and returns a tailored bundle.
• A research study wants anonymized statistics? The agent runs queries locally on your encrypted data and returns aggregate outputs, not rows.
• An insurer wants to see if you meet a condition? The agent answers with a yes/no or a score, not the underlying records.

Crucially, the agent logs each request. It signs the response. It anchors a hash of that interaction on-chain or in an append-only log. Later, you can see a clean audit trail of who touched what and why.

This turns the AI into a compliance tool, not just a chatbot in a pretty UI.

Where the model actually runs

The sovereignty story collapses if the model only runs on some random vendor's GPU cluster with a 40-page terms-of-service. So I sketched three deployment modes.

• Local-first: Lightweight models running on a phone, laptop, or home server. Good for queries over your own data.
• Trusted compute: Enclaves or TEEs (SGX, SEV, Nitro) for heavier models. Encrypted data in, encrypted outputs out.
• Hybrid: Policy engine local, heavy inference remote. The local part decides what can leave the device, and in what form.

I like the hybrid model for near-term reality. Phones are getting better, but medical NLP on huge histories is still heavy. The trick is to make sure raw data never leaves without being transformed or anonymized according to the policies your agent enforces.

So you end up with a small, auditable policy model that you can inspect, and a larger foundation model behind an API that never sees your full, raw medical corpus. It sees partial, masked, or synthetic views.

Consent as code, not paperwork

Traditional consent is basically a PDF in a folder. Once you sign, it is a one-way door. No one expects you to read it. No one expects you to remember it.

With a blockchain-backed control layer, you can encode consent like this instead:

• Scope: which data categories, which providers, which date ranges.
• Purpose: treatment, billing, research, product development.
• Duration: fixed term, one-time, or renewable.
• Granularity: raw documents vs derived signals vs aggregated stats.

That ends up as a smart contract or capability token tied to your DID. Your AI agent uses these policies as strict gates, not suggestions.

You could literally say: "Share only my cardiology history from the last 2 years with Clinic X for treatment purposes, and strip identifiers except my age, sex, and city". The agent compiles that into a machine-enforceable rule and writes a small consent record on-chain with a hash of the policy.

Revoke is just another transaction. No printing forms. No faxing requests into the void.

Training on your data without selling your soul

The messy part is training. Everyone wants to train on healthcare data. Most patients probably benefit from better models. The incentives do not line up cleanly.

I think the only honest approach is to separate three levels of "training".

• Personal fine-tuning: Your agent learns your history, preferences, and baselines. This never leaves your sphere of control.
• Federated learning: Your data contributes to global model improvements without leaving your device or enclave. Only gradients or updates leave, under strict privacy accounting.
• Centralized training: Traditional big-batch training on de-identified data stored by a research institution under heavy regulation.

The first one is non-negotiable for real sovereignty. Your agent must get better for you alone. Your weird edge cases, your medication history, your genetics. That is your advantage.

The second one is where blockchain consent can actually shine. You can attach clear terms and potentially compensation. You agree that your device participates in a federated training run for topic X. You get a share of a reward pool. The chain records your participation and constraints. Your agent checks that the training job matches those terms.

The third one will probably exist no matter what. Big hospitals and research labs will keep building central models. The key is to prevent that path from being the only one, by giving patients a real alternative.

What this looks like for an actual patient

Architecture diagrams are fun, but a basic user flow is where this gets honest. So here is one concrete path I walked through on paper.

You show up at a new clinic.

• You scan a QR code with your health wallet.
• The clinic's DID and credential pop up: verified provider, specialty, jurisdiction.
• Your agent suggests a consent pack: share last 5 years of relevant history, allow ongoing updates for treatment, no research use.
• You can expand and tweak. Maybe you hide mental health records for now.
• You approve. The wallet signs a consent transaction. The chain records it.

Behind the scenes, the clinic's system sends a structured query: "treatment history for conditions A, B, C". Your AI agent fetches encrypted documents from storage, applies policy filters, optionally local de-identification, and sends back a bundle.

If the clinic later wants to enroll you in a research trial, that is a separate ask. Different policy. Different on-chain record. You can say yes with strict limits, or flat no.

Where this whole idea can fail

I like this architecture, but I am not naive about the failure modes.

• UX complexity: If the wallet feels like managing firewall rules in 2003, no one will use it correctly. The agent needs good presets and human language explanations.
• Key loss: Patients will lose devices, passwords, everything. Without robust recovery, you just moved lock-in from hospitals to cryptography.
• Regulatory mismatch: Some laws expect data to be deletable, which clashes with immutable logs. You need off-chain storage and careful design.
• Institutional laziness: Hospitals might pretend to support this while keeping their old silos. The incentives need work.

I think the biggest risk is fake sovereignty. Pretty wallets. Nice words about ownership. Under the hood, the same centralized APIs quietly hoover up data, and the blockchain is just marketing.

The only antidote is verifiability. Patients and regulators need to be able to inspect code paths and see that the AI agent cannot bypass on-chain policies, even if the operator wants to.

What I would actually build first

If I had to ship something in this direction tomorrow, I would not start with the whole sovereign AI fantasy. I would pick one narrow slice.

• A patient wallet that can hold a DID, basic credentials, and simple consent policies.
• A small AI policy engine that explains those policies in plain language and simulates outcomes.
• One integration with a forward-thinking clinic that is okay with a parallel workflow.

No massive model yet. No federated training. Just automated, verifiable consent with a bit of intelligence to make it understandable. Then layer in the data access mediation and richer agents once that base is solid.

If the consent story is trash, the rest is lipstick.

Why I think this is worth building

I do not think decentralization is magic. I do not think AI will suddenly fix healthcare. But the combo of programmable consent plus agents that defend users feels like a rare chance to realign incentives.

Instead of turning patients into data exhaust for someone else's model, you give them a bargaining chip. They bring their own history. They bring their own agent. Providers compete on quality of care and compatibility, not data hoarding.

If sovereign AI means anything, it should mean your body data answers to you first, institutions second. Blockchain is just the boring substrate that makes those promises hard to quietly break.

That is a future I would actually like to use as a patient, not just build as a developer.

Why I Stopped Trusting "Scores"

I like toys. Especially toys with sensors.

Oura, Whoop, Apple Watch, a cheap HR strap from Decathlon, even a continuous glucose monitor for a while. All of them tried to tell me how I was doing with one magic number.

Readiness: 82. Sleep score: 91. Strain: 13.2.

Nice. But my body did not care. Some days I had a high readiness score and still felt like a brick. Other days I felt sharp and the app nagged me to “take it easy”.

So I stopped asking: “What is my score?”

I started asking: “What should I do right now?”

That question is where AI actually got useful for biohacking. Not to generate pretty charts, but to make a decision: push, maintain, or back off.

The Goal: Autonomous, Boringly Simple Health Suggestions

I wanted a system that:

• Pulls live data from my wearables automatically.
• Understands my baselines, not population averages.
• Spits out 1–2 concrete suggestions, not a 10-paragraph essay.
• Runs in the background without me having to remember to open an app.

Think tiny health coach in the background. Not a life guru. More like a slightly annoying teammate that pings you with: “Take 10 minutes outside, your HRV tanked after that last call.”

So I wired my wearables to an LLM and tried to make it as autonomous as I could without blowing up my API bill or my sanity.

My Wearable Stack

Right now my core stack looks like this:

• Oura Ring for sleep, HRV, resting HR.
• Apple Watch for heart rate during training, HRV snapshots, and activity.
• Cheap BLE chest strap for kettlebell and conditioning sessions when I care about accuracy.

I tried adding CGM data, but that turned into a distraction. Good for a focused 2-week experiment, not great for permanent background noise. So in this phase I cut it.

Important detail: I stopped trusting each platform’s “readiness” score and focused on raw-ish metrics:

• HRV (rMSSD), nightly average and trend.
• Resting heart rate and how fast it drops after workouts.
• Sleep duration and fragmentation.
• Training load from heart rate and RPE notes.

These are boring numbers. Which is perfect. Boring means predictable. Predictable means an LLM can reason about them without hallucinating some spiritual conclusion out of a 79 sleep score.

The Architecture: From Wrist To Recommendation

This is what I actually built. Not theoretical. Running on my stuff right now.

The system has five pieces:

1. Data collection workers
2. Normalization and feature builder
3. Long-term baseline and history store
4. LLM “coach” prompt layer
5. Notification layer (where it pokes me)

1. Data collection workers

I run small, boring scripts on a cheap VPS.

• A cron job hits the Oura API every 30 minutes in the morning, then every 2 hours during the day for readiness updates.
• Another job pulls Apple Health data via a personal shortcut export every few hours. Not pretty, but it works.
• Workout sessions push data in directly when I finish them, through a tiny web form where I log RPE and what I actually did.

Everything lands in a Postgres database. Timestamps, raw values, the source device, plus some calculated stuff like rolling averages.

2. Normalization and feature builder

Each hour a job runs that:

• Back-fills missing data, or marks gaps clearly instead of pretending it knows.
• Builds “features” for the AI layer: HRV vs 7-day average, sleep vs 14-day average, last hard session delta, and so on.
• Flags notable events. For example: “HRV dropped > 20% below 7-day mean”, or “Sleep < 80% of 14-day avg and two days in a row of heavy training”.

This part matters more than the AI model choice in my opinion. If your inputs are vague and inconsistent, your clever prompt will just generate poetic nonsense.

3. Baseline and history

I keep a rolling 90-day window for most metrics.

HRV especially is very personal. My “good” number might be your “I am dying” number. So the system stores per-user (just me right now) baselines and updates them every week.

That way the AI agent never sees: “HRV = 60”. It sees: “HRV = 60, which is 8% above his 30-day average, and he slept 15% more than usual”. Now it has context.

4. LLM coach layer

This is a small API that wraps the model. I currently use a GPT-4-level model, but the key is the system prompt and how I limit its job.

The system prompt looks roughly like this (shortened here):

You are a pragmatic health coach for a single user.
You must respond with 1-2 concrete actions only.
No more than 120 words. No general wellness advice.
Use only the data given. If data is missing, say so.

User data: <metrics>
User context: <recent training log + calendar notes>

Then I feed in the hourly feature bundle, plus a short snippet from my notes if I tagged something like “travel”, “sick”, or “poor sleep because of kids baseball tournament”.

The output format is strict JSON:

{
  "priority": "push" | "maintain" | "back_off",
  "reason": "short explanation",
  "actions": [
    "action 1",
    "action 2"
  ]
}

No Markdown. No “as an AI language model”. Just a tiny plan for the next few hours.

5. Notification layer

The last piece is the annoying one.

A small worker checks the new JSON and compares it to the previous recommendation. If the priority or actions really changed, it sends me a push notification through a custom iOS shortcut endpoint.

Example message:

• Priority: back_off
• Reason: HRV dropped 22% below 7-day avg after 2 heavy days.
• Actions: 1) Keep training under 30 min, low intensity. 2) In bed by 22:00, no late screens.

If nothing meaningful changed, it stays quiet. Silence is part of the design. I do not want a Tamagotchi, I want a cold friend who only texts when it matters.

What "Real-time" Actually Means Here

People say “real-time” when they mean “not yesterday”. For biohacking I do not need sub-second updates. I need the system to react fast enough that I can still change something.

The cadence that felt right in practice:

• Morning block: 2–3 runs in the first hour after waking, as data from Oura and Apple sync.
• Daytime: Every 2 hours, unless there is a spike or a flagged event.
• Training window: Right after a workout, when I log RPE and type of session.

I tried tighter loops. 15-minute cycles felt like noise. I got more pings during meetings and coding blocks, and I started ignoring them. Which kills the whole point.

So “real-time” in this project became: fast enough to adjust the next block of the day, slow enough that it does not spam me.

Concrete Examples From My Own Data

1. Catching overreach before it hit

Two heavy kettlebell days. Both felt good. My subjective rating: “Let’s keep going.”

The system saw:

• HRV 18% down from 7-day average.
• Resting heart rate up 4 bpm vs 14-day average.
• Sleep time normal, but more wake events.

It flagged back_off and suggested: “Skill work only today, no conditioning. Prioritize 30-minute walk in sunlight.”

I listened. Next day HRV bounced back, and I avoided that familiar 3–4 day fatigue slump. Subjectively it felt like cheating. An invisible adult in the room.

2. Travel days and fake guilt

On travel days my normal apps still shame me. No rings closed. Activity score bad. Readiness confused.

With the AI layer, I tagged my calendar with “travel” and fed that into the context. The system adapted quickly:

• Priority: maintain
• Actions: “Walk 15 minutes between flights. Hydrate aggressively. Bed as early as possible after arrival.”

No comment on my lack of deadlifts. No nonsense about streaks. Just realistic constraints based on my situation, not some perfect training plan.

3. Late-night coding and hidden cost

I did a classic mistake. Pushed a feature late, bright screen, heavy React profiler sessions until midnight.

Next morning the system saw:

• Sleep quantity acceptable, but deep sleep down by ~30% vs 14-day average.
• Heart rate stayed elevated longer into the night.
• Calendar showed “late deploy” tag from my notes.

Response:

• Priority: back_off
• Actions: “Avoid heavy training today. Block 20:30–22:00 for no-screen wind-down. If you work, do offline writing.”

The useful part is not the advice. I already know screens at night are bad. The useful part is timing. It caught it the morning after and forced the tradeoff into my face while I was planning the day.

Where AI Actually Helped (And Where It Did Not)

Helpful things first.

• Pattern stitching. I am decent at looking at HRV or sleep in isolation. The LLM is better at noticing “three medium red flags” that together justify backing off.
• Context awareness. Pulling in calendar tags like “travel”, “kids tournament”, “launch week” made the recommendations far less annoying. Generic apps ignore this.
• Natural language summaries. I could generate the same decisions with hand-coded rules, but the explanation quality from the model made me trust the output more.

Not helpful:

• Generic wellness advice. If you do not clamp the prompt hard, it will start telling you to drink water and meditate. I cut that ruthlessly.
• Creating complex long-term plans. The model is bad at periodization. I still set my weekly and monthly training blocks manually.
• Data cleaning. AI is not magic here. I tried having it infer missing values. It invented too much. Plain scripts with explicit rules won.

Constraints I Put On The System (For My Own Sanity)

Autonomous does not mean “free to be weird”. I added hard constraints.

• No medical claims. The prompt explicitly blocks diagnosis talk. If metrics are extreme, it says: “These values are unusual; talk to a real doctor.”
• Limited authority. The system never gets to cancel my workouts. It can label the day as back_off, but I still choose. This keeps the relationship healthy.
• Strict word cap. Max 120 words. Otherwise it drifts into storytime. I am not reading essays between meetings.
• Data transparency. Every recommendation includes a one-line summary of what it actually saw: “HRV -18% vs 7d, RHR +3 bpm, 2x heavy days.” No black box energy.

If You Want To Build Your Own Version

I am not packaging this as a product, at least not yet. But if you want to wire something similar for yourself, this order worked well for me:

1. Collect first, model later. Spend a few weeks just pulling data into a database. Look at it manually. See what actually matters for you.
2. Define 3–5 triggers. For example: big HRV drop, lack of sleep two days in a row, unusually high heart rate during light activity. Only then bring in AI.
3. Start with a fixed prompt. Do not build a full “agent” that can call tools and write its own rules. Keep the LLM as a reasoning layer on top of clear metrics.
4. Respect your annoyance budget. Tune notification frequency until you barely notice the system exists. If it feels loud, you will ignore it.

I think people overestimate what models can do and underestimate how powerful they are as boring, opinionated summarizers. A little reasoning plus your own data goes a long way.

Where I Want To Take This Next

I see three obvious next steps.

• Stronger integration with training plans. Right now I still plan my cycles manually. I want the system to suggest minor adjustments: “swap heavy day to Thursday, based on recovery.”
• Better short-term HRV snapshots. Continuous or at least scheduled HRV recordings during the day, not just night data, so it can react to work stress spikes too.
• Team mode. I coach baseball. At some point I want a stripped-down version that helps me modulate practice intensity for players based on basic wearable data.

But I am careful. More data and more autonomy are not always better. The sweet spot seems to be:

• Small, opinionated loop.
• Clear question: “What should I do next?”
• Minimal friction to follow the suggestion.

That is how I am using AI for biohacking right now. Not as a guru. As a slightly nerdy mirror that watches my signals and tells me, in plain language, when I am about to be stupid with training or sleep.

That is good enough for me.

Why my biohacking dashboards kept breaking

I track too many things.

HRV, resting heart rate, sleep stages, pitch count from baseball practice, cold plunge time, caffeine intake, sunlight. If I can get it into a CSV or API, it ends up in a dashboard.

The problem: every new metric broke my layout.

On my laptop, it looked fine. On my phone at the gym, labels wrapped badly, cards stretched, and charts felt cramped. Every experiment meant tweaking breakpoints again. I was living inside media queries.

So I stopped trying to perfectly target devices. Instead, I started targeting relationships. Things like:

• How many cards per row feels readable for this density of data?
• How much padding do I need if the user is in bright sunlight?
• What is the minimum tap target I accept for a tired, post-workout brain?

CSS custom properties became the control panel. Not Tailwind classes. Not another utility system. Plain variables.

The core idea: styles as health metrics

For my biohacking dashboards, I treat CSS variables like another layer of metrics. They represent the current “state” of the interface.

Instead of hardcoding everything like this:

.card {
  padding: 1.5rem;
  border-radius: 12px;
  font-size: 0.95rem;
}

.dashboard {
  grid-template-columns: repeat(4, minmax(0, 1fr));
}

I push decisions into custom properties:

:root {
  --dashboard-columns: 4;
  --card-padding: 1.5rem;
  --card-radius: 12px;
  --card-font-size: 0.95rem;
}

.dashboard {
  display: grid;
  grid-template-columns: repeat(var(--dashboard-columns), minmax(0, 1fr));
  gap: var(--dashboard-gap, 1.25rem);
}

.card {
  padding: var(--card-padding);
  border-radius: var(--card-radius);
  font-size: var(--card-font-size);
}

On its own that is not very exciting. The shift happens when you stop thinking “mobile vs desktop” and start thinking “lightweight vs dense vs focus mode” and let those modes rewrite the variables.

Defining “modes” for your body, not your devices

I care more about my mental state than my device type.

If I am half-asleep checking morning HRV, I want big numbers, low noise, and high contrast. If I am at my desk reviewing a week of data, I want density and context.

So I started defining layout modes as CSS variables first, then pairing them with media queries and data- attributes.

:root {
  /* default “desk review” mode */
  --dashboard-columns: 4;
  --card-padding: 1.25rem;
  --card-font-size: 0.95rem;
  --chart-height: 260px;
  --touch-target-size: 36px;
}

/* narrow screens: inherently more “single focus” */
@media (max-width: 900px) {
  :root {
    --dashboard-columns: 2;
    --card-padding: 1rem;
    --card-font-size: 0.98rem;
    --chart-height: 220px;
    --touch-target-size: 44px;
  }
}

/* ultra narrow: pure focus mode */
@media (max-width: 600px) {
  :root {
    --dashboard-columns: 1;
    --card-padding: 1.1rem;
    --card-font-size: 1.05rem;
    --chart-height: 260px;
  }
}

Then I added an explicit focus mode that I can toggle from JavaScript based on context. For example, when I open a “pre-sleep” routine dashboard on my phone.

html[data-mode="focus"] {
  --dashboard-columns: 1;
  --card-padding: 1.5rem;
  --card-font-size: 1.1rem;
  --chart-height: 300px;
  --touch-target-size: 48px;
}

Now the JS is dead simple:

// example: turn on focus mode for “bedtime check-in”
function setMode(mode) {
  document.documentElement.setAttribute('data-mode', mode);
}

setMode('focus');

No component-level overrides. No Tailwind gymnastics. One attribute, all the right knobs turn.

Responsive grids without chasing breakpoints

The dashboard layout is almost always a grid of “cards”. Sleep summary. HRV trend. Training load. Recovery score.

I got tired of guessing how many cards I could fit per row for random device widths. So I stopped being strict about it. I use a variable for “target column width” and let the layout find its own shape.

:root {
  --card-min-width: 260px;
}

.dashboard {
  display: grid;
  grid-template-columns: repeat(
    auto-fit,
    minmax(var(--card-min-width), 1fr)
  );
  gap: var(--dashboard-gap, 1.25rem);
}

Then I let context rewrite --card-min-width instead of hunting down grid definitions.

html[data-mode="focus"] {
  --card-min-width: 320px;
}

@media (max-width: 600px) {
  :root {
    --card-min-width: 100%;
  }
}

This is boring code. That is the point.

When I added a “Travel” dashboard that has smaller, less important stats, I did not need a new layout. I only nudged the knobs.

html[data-dashboard="travel"] {
  --card-min-width: 220px;
  --card-padding: 0.9rem;
}

The same CSS. Three very different layouts. It feels like a design system finally doing its job.

Adaptable charts without 20 config files

The ugly part of biohacking dashboards usually lives around charts. Fonts too small. Lines too thin. Legends unreadable.

I wanted charts to respect the same variables as the rest of the UI. So I pushed chart styling decisions into CSS and let the JS just read them.

Example: I use CSS variables to control stroke width, gridline opacity, and font size. Then the chart library reads from computed styles.

:root {
  --chart-stroke-width: 2;
  --chart-grid-opacity: 0.12;
  --chart-font-size: 0.8rem;
}

html[data-mode="focus"] {
  --chart-stroke-width: 3;
  --chart-grid-opacity: 0.18;
  --chart-font-size: 0.9rem;
}

.chart-container {
  font-size: var(--chart-font-size);
}

function getCssNumber(varName, fallback) {
  const styles = getComputedStyle(document.documentElement);
  const value = styles.getPropertyValue(varName).trim();
  return value ? Number.parseFloat(value) : fallback;
}

const chartStyle = {
  strokeWidth: getCssNumber('--chart-stroke-width', 2),
  gridOpacity: getCssNumber('--chart-grid-opacity', 0.12),
  fontSize: getComputedStyle(
    document.querySelector('.chart-container')
  ).fontSize
};

// pass chartStyle into whatever chart lib you use

Now when I toggle modes, the charts adapt without needing a second config object for “mobile” or “large screen”.

It also matches my mental model better. “Focus mode means thicker lines and higher contrast”. That is a UI statement, not a chart library statement.

Light, dark, and “sunlight” themes driven by variables

My worst decisions happen when I am squinting at a low-contrast UI in bright sun after a workout.

I started with basic light and dark themes, then ended up with a third “sunlight” theme that is basically “dark but more brutal”. Again, the work happens in custom properties.

:root {
  color-scheme: light;

  --bg: #fafafa;
  --bg-alt: #ffffff;
  --surface: #ffffff;
  --text: #111827;
  --muted: #6b7280;
  --accent: #22c55e;
  --danger: #ef4444;
  --border-subtle: #e5e7eb;
}

html[data-theme="dark"] {
  color-scheme: dark;

  --bg: #020617;
  --bg-alt: #030712;
  --surface: #020617;
  --text: #e5e7eb;
  --muted: #6b7280;
  --accent: #22c55e;
  --danger: #f97373;
  --border-subtle: #111827;
}

html[data-theme="sunlight"] {
  color-scheme: dark;

  --bg: #000000;
  --bg-alt: #020617;
  --surface: #020617;
  --text: #f9fafb;
  --muted: #9ca3af;
  --accent: #4ade80;
  --danger: #fb7185;
}

body {
  background: var(--bg);
  color: var(--text);
}

.card {
  background: var(--surface);
  border: 1px solid var(--border-subtle);
}

While building this, I stopped wiring theme switches deep into components. Instead, I just toggle data-theme on html.

function setTheme(theme) {
  document.documentElement.setAttribute('data-theme', theme);
}

// crude heuristic: “sunlight mode” on high ambient light
if ('AmbientLightSensor' in window) {
  const sensor = new AmbientLightSensor();
  sensor.addEventListener('reading', () => {
    if (sensor.illuminance > 25000) setTheme('sunlight');
  });
  sensor.start();
}

On most devices the ambient sensor is not available, so I usually just expose a manual toggle. The point stands. The heavy work happens in CSS variables. JS only flips states.

Scaling typography for late-night and early-morning brains

Health dashboards are not marketing sites. You read them when you are tired. Or stressed. Or distracted.

I treat typography like another variable set, then let time and mode tweak it. I am not precious about perfect modular scales. I care about legibility when my HRV tanked.

:root {
  --font-base-size: 16px;
  --font-scale: 1.15;

  --font-size-xs: calc(var(--font-base-size) / var(--font-scale));
  --font-size-sm: var(--font-base-size);
  --font-size-md: calc(var(--font-base-size) * var(--font-scale));
  --font-size-lg: calc(var(--font-size-md) * var(--font-scale));
  --font-size-xl: calc(var(--font-size-lg) * var(--font-scale));
}

html[data-mode="focus"] {
  --font-base-size: 17px;
}

html[data-time-of-day="night"] {
  --font-base-size: 18px;
  --font-scale: 1.12;
}

body {
  font-size: var(--font-size-sm);
}

.card-title {
  font-size: var(--font-size-lg);
}

.metric-primary {
  font-size: var(--font-size-xl);
}

Then a small bit of JS sets data-time-of-day:

const hour = new Date().getHours();
const timeOfDay = hour >= 20 || hour < 6 ? 'night' : 'day';

document.documentElement.setAttribute(
  'data-time-of-day',
  timeOfDay
);

This is one of those details that feels unnecessary until you use it for a week. Then regular dashboards feel too small and hostile at 23:30.

Container queries plus variables for modular panels

One concrete problem: I wanted to reuse the same “HRV card” component in a full-width view and in a cramped lateral sidebar. Copying layout logic felt lame.

I ended up combining container queries with custom properties. The card owns its own thresholds. The parent only defines its size.

.card {
  container-type: inline-size;
}

.card[data-metric="hrv"] {
  --metric-layout: "compact";
}

@container (min-width: 420px) {
  .card[data-metric="hrv"] {
    --metric-layout: "regular";
  }
}

.hrv-card-root[data-layout="compact"] .trend {
  display: none;
}

.hrv-card-root[data-layout="regular"] .trend {
  display: block;
}

I do not love using strings inside variables, so I usually pair them with attributes:

.card[data-metric="hrv"] {
  --hrv-show-trend: 0;
}

@container (min-width: 420px) {
  .card[data-metric="hrv"] {
    --hrv-show-trend: 1;
  }
}

.hrv-trend {
  display: none;
}

.hrv-card-root {
  /* 0 or 1 */
  --trend-visible: var(--hrv-show-trend);
}

.hrv-card-root[data-trend-visible="1"] .hrv-trend {
  display: block;
}

Or lean into utility classes that read from variables with opacity and pointer-events. The exact pattern is less important than the mindset. The card decides what it can show based on its container. The rest of the dashboard does not care.

Practical pitfalls I hit

This all sounds neat. In practice I hit some annoying problems before the setup became pleasant.

• I over-nested variables at first. I had variables referencing variables referencing variables. That turned debugging into archaeology. Now I keep it to one indirection level most of the time.
• I tried to mirror design tokens perfectly. That made the CSS feel like a generated artifact, not a tool. These days I keep only the tokens that match real decisions: spacing scale, typography, state, density.
• I misused media queries as a “config system”. Throwing every variable change into @media blocks became unreadable. Modes helped. data-mode, data-theme, data-dashboard. Each owns a narrow set of variables.

The golden rule I ended up with: if you cannot describe the variable in one clear English sentence, it is probably too abstract.

“--touch-target-size is the minimum tap target size for the current context.” That is good.

“--ui-scale-factor is a multiplier for all interaction elements depending on mode and viewport size and density.” That is vague nonsense.

Why this beats piling on more JS

I could absolutely drive all of this from JavaScript. Compute breakpoints in code. Inject styles dynamically. Use a heavy design token system.

I do not want to.

CSS custom properties let the browser do what it is good at. They keep responsive decisions in one place. They make “focus mode for pre-sleep check” a styling concern, not a re-render concern.

For biohacking dashboards specifically, the ground keeps moving. You will add a new metric. Swap out a sensor. Change your morning routine. The UI needs to adapt as fast as your experiments.

Variables give you a control panel for that. Not another rewrite. Just a few new knobs.

That is the type of flexibility I want from my health tools. Quiet, boring, predictable. So my energy goes into the experiment, not the CSS.

Why I bother checking numbers before I write a single line of code

I used to treat my body like a hosting plan.

Unlimited everything. It will be fine. Just push one more late night deploy. Then I hit a wall. Brain fog, random injuries, and days where my code reviews looked like they were written by someone throttled to 2G.

So I started tracking stuff. HRV. Resting heart rate. Sleep score. Body weight. The usual biohacker starter pack.

The problem was simple. I had dashboards and zero decisions. Data as decoration.

Now I run a strict 5‑minute biometric check every morning. And every single number has a simple rule attached to it. If X, then I do Y. No vibes. No overthinking.

This post is exactly what I check, the thresholds I use, and how it changes my day as a developer, builder, and baseball coach who still wants to hit the gym without breaking.

The tools on my body and on my desk

This is not a gear flex. You can do a lighter version of this with almost anything. But for context, here is my actual setup right now.

• Oura Ring for HRV, resting HR, and sleep stages.
• Apple Watch as a rough backup for HR and sleep when I travel.
• Withings smart scale for body weight.
• Apple Health as the central pipe.
• Notion for a simple morning check template.

I have used Whoop, Garmin, and other toys in the past. The pattern is the same. I just care about four numbers, and I only care about them at one time: right after I wake up, before coffee, before email, before Slack.

The 5‑minute script: what I check and in what order

I follow the same script every morning.

1. Open Oura and note HRV and resting HR.
2. Check last night’s sleep score and a couple of sub‑scores.
3. Step on the scale.
4. Open my Notion page, log four numbers, apply rules.

The logging part takes 30 seconds. The decisions take 4 minutes. The rest of this post is just those decisions written out.

HRV: my recovery traffic light

HRV is the number I respect the most. Not because it is perfect science, but because it correlates brutally with how my brain feels around 14:00.

My personal baseline HRV sits in a band. I do not care about the absolute value. I care about the trend and deviation.

Here is how I treat it.

If HRV is normal or slightly above baseline

For me this means the rolling 7‑day HRV is within roughly 5 percent of my baseline or slightly above.

What I do:

• Work: I schedule at least one deep focus block of 2 hours. Hard problems. Architecture, performance work, experimental features. No meetings allowed in that slot.
• Training: Green light for a heavier session. This might mean kettlebell swings, squats, or sprint work at baseball practice. I push volume or intensity, not both.
• Caffeine: Normal intake. For me that is two coffees before 11:00, none after.

In short: normal HRV means I stop babying myself. I treat the day like my capacity is actually there.

If HRV is moderately below baseline

This is the most common “warning” state. A drop of 5 to 15 percent from my baseline or a clear negative trend over 3 days.

What I do:

• Work: I shift big creative tasks to earlier in the day. No heroic late afternoon pushes. If something cognitively heavy is not done by 15:00, it moves to tomorrow.
• Training: I keep the session, but I change the intent. Less load, more technique. For example, I will hit skill work on my swing, light kettlebell work, or a walk instead of intervals.
• Caffeine: I cap it at one coffee. I have learned that using caffeine to fight a mild HRV drop just steals energy from the next morning.
• Evening: I set a hard screen cut‑off at 21:30. Blue light filter, no late coding session “just to finish that feature”.

The key here: I do not cancel the day. I just stop pretending I am at 100 percent. It is a tactical retreat, not a rest day.

If HRV is tanked

This is when HRV drops more than ~15 percent, or I see two bad nights in a row.

This usually happens after late baseball games, travel, or a dumb combination of heavy lifting plus mindless Netflix scrolling until midnight. So it is usually my fault.

What I do:

• Work: I deliberately schedule a “maintenance day”. That means bug fixes, refactoring, documentation, admin, or content planning. No high stakes shipping.
• Training: I either skip training or do a 20 to 30 minute easy walk. Zone 2 at most. Heart rate low. I do this even if my brain tries to guilt trip me with streaks.
• Caffeine: I watch it like a hawk. One coffee max, and ideally I push it to after breakfast instead of first thing.
• Sleep: I pre‑commit to an earlier bedtime. For me that means starting wind‑down by 21:00, not starting a movie at 21:00.

Tank HRV days hurt my ego. They save my next three days though. Every time I ignore this number, I pay interest on fatigue for a full week.

Resting heart rate: the infection detector

Resting heart rate pairs nicely with HRV. HRV tells me how my system is balancing stress. Resting HR often tells me if there is an extra invisible load, like an infection or recovery debt.

My resting HR sits lower on days where I am actually recovered. It bumps up when I am fighting something or when alcohol sneaks in.

If resting HR is normal

Normal is boring. That is good. I mostly ignore it if it is within a few beats of my weekly average.

What I do:

• I use it as a sanity check for HRV. If HRV is slightly down but resting HR is fine, I treat it as psychological or just noise.
• No specific change to training or work. Other numbers take priority.

If resting HR is elevated by 5+ bpm

This is where it gets useful. For me, anything more than 5 beats above my baseline resting HR gets attention.

What I do:

• Work: I assume my body is fighting something. I pre‑emptively reduce my ambition for the day. Smaller to‑do list. One key outcome, not three.
• Training: No intense work. No heavy squats. No sprint sessions. I keep movement but switch to walking, mobility, or light throwing at baseball practice.
• Food: I prioritize actual food over snacks. Protein, salt, water. Simple.

I treat a high resting HR as a polite warning from my immune system. It is usually right.

Sleep score: the lie detector for “I feel fine”

Sleep is the most boring topic in health, but it controls almost everything I care about: focus, mood, and whether I throw lazy pitches at practice.

My Oura sleep score is not sacred, but it is a decent lie detector for how I slept compared to how I think I slept.

If sleep score is 85+

For my body, anything 85 and up usually means enough deep and REM sleep, decent latency, and low disturbance.

What I do:

• Work: I front‑load my hardest problem. I aim to ship something that actually matters. Not tweak fonts. Think performance tuning, architecture decisions, or writing longform content.
• Training: If HRV agrees, I treat this as a good day to push skill plus intensity. Heavy lifts, hard batting practice, or sprints.
• Social: I am more selective about late social stuff. Ironically, feeling good is when I am most likely to wreck my next night by staying out too late.

If sleep score is 70‑84

This is my gray zone. The night was okay but not great.

What I do:

• Work: I keep one hard block but I reduce expectations on creative output. I also avoid stacking lots of meetings, because they drain more when sleep is mid.
• Training: I let HRV be the tiebreaker. If HRV is fine, I keep my planned session but cut volume by 20 to 30 percent.
• Evening plan: I explicitly plan a calmer evening. No new series, no scrolling rabbit holes. Book, stretch, maybe a walk.

If sleep score is below 70

This is the red zone. I know people who function like this daily. I do not.

What I do:

• Work: I shift into “ship small things well” mode. Fix a bug. Tighten a UI animation. Write a short post. I avoid starting anything broad or strategically important.
• Training: No intensity. I treat it like jet lag. Walks, mobility flows, maybe some very light kettlebell work if I am restless.
• Caffeine: I schedule my last coffee by 10:00. I know I will be tempted to slam an espresso at 16:00. That one shot alone will trash the next night.

One bad night does not ruin me. Two or three in a row do. The score keeps me honest before I drift into that pattern.

Body weight: the quiet background signal

Weight is the least dramatic metric in my morning routine, but long term it is the most unforgiving.

I weigh myself daily. Not because every day matters, but because the trend does. I care about the 7‑day average, not today’s spike.

If weight is in my target band

I keep a 1 to 1.5 kilo range that I am happy with for performance and aesthetics. If the 7‑day average sits inside that band, life is easy.

What I do:

• No change to food. I keep the same meal template: protein heavy breakfast and lunch, lighter dinner.
• I focus more on performance in the gym and on the field, not the scale.

If weight trend drifts up for 2+ weeks

I do not panic over a weekend spike. But if the 7‑day average creeps up for more than two weeks, I act.

What I do:

• Food rules: I add one simple constraint. For example, no liquid calories during the week, or no snacks after 20:00. Only one rule at a time so I can see cause and effect.
• Training: I keep strength work and increase low intensity movement. More walking, more easy cycling between meetings.
• Weekends: I plan one “higher calorie” day rather than three accidental ones.

If weight trend drifts down when I do not want it to

This has happened during busy shipping phases where I forget to eat properly between deep work and coaching baseball.

What I do:

• Food: I anchor one extra proper meal with 30 to 40 grams of protein. Usually a second breakfast or a bigger lunch.
• Training: I keep intensity but reduce overall volume. Strength needs fuel. If the fuel is not there, I would rather hold the line than push.

Weight moves slowly, which is exactly why I want a daily quick check. It is a guardrail against drift.

Gluing it together: my actual Notion template

I like systems that fit on one screen. So my morning biometric check lives in a tiny Notion page pinned to my “Start” dashboard.

The template looks like this.

Date: [     ]

HRV: [     ]   Trend: [up / flat / down]
RHR: [     ]
Sleep score: [     ]
Weight (7d avg): [     ]

Work focus today:
- [ ] Deep / Creative / Maintenance  (circle one)

Training today:
- [ ] Heavy
- [ ] Moderate
- [ ] Easy / Off

Rules for today:
1) ___________________________
2) ___________________________

I do not write essays in there. I tick one option for work, one for training, then write one or two short rules for the day. Things like:

• “No caffeine after 10:00.”
• “Walking and mobility only.”
• “Ship X feature before lunch.”

That is it. The whole routine fits between brushing my teeth and making coffee.

Why this 5‑minute check beats chasing perfect data

Most people I know who wear rings and watches make the same mistake I made at the start. They collect everything and change nothing.

I do not think better sensors will fix that. I think better rules will.

My rule now is simple. If a metric does not change my plan for the day, I stop tracking it. That is why I care about exactly four in the morning.

• HRV sets my recovery and intensity ceiling.
• Resting HR tells me if there is hidden stress or sickness.
• Sleep score shapes my cognitive load and caffeine plan.
• Body weight keeps my long‑term trend honest.

If those four numbers say “go”, I go hard. If they say “easy”, I listen. Not because I turned into a health monk, but because I like shipping work that does not feel like wading through mud.

I build web experiences, I coach baseball, and I still want energy left to be a human at the end of the day. This 5‑minute biometric routine is how I stack the odds in my favor, one very boring, very practical morning at a time.

Centralized AI wants your data

I like large language models. I use them daily. I also do not trust any of the big AI platforms with my data beyond the absolute minimum I am forced to share.

If a model lives on someone else’s server, behind someone else’s API key, that model ultimately works for them, not for you. You might get nice features. Autocomplete. Chat. Code suggestions. But the real value is in the feedback loop that your data creates for their model.

That is the core problem sovereign AI tries to fix. Not by begging vendors for better terms of service, but by changing who actually runs the model and where your data lives.

What I mean by "sovereign AI"

Sovereign AI gets thrown around as a marketing phrase. I use it in a very narrow, practical way:

• The model runs on hardware you control. That can be your laptop, a home server, or a rented machine where you own the full stack.
• Your data never leaves your control in raw form. No uploads to mystery training pipelines. No hidden logs.
• You can swap, retrain, or fine-tune models without asking a vendor for permission.

It is basically DevOps for your brain extension. You own the infra, not just the prompt.

Personal data sovereignty then becomes a side effect. If the model is physically close to you and you manage it like any other service, your notes, emails, health data, and weird side projects do not become part of somebody else’s training set.

Why I stopped feeding the cloud everything

I used to paste entire documents into various AI tools. Client briefs. Meeting notes. Half-baked startup ideas. I told myself the usual lie: "They say they do not use this for training, so it is fine."

Then I looked at my actual workflow. There were three big problems.

• Trust drift. Policies change. Teams get acquired. Your data is still sitting in logs and backups you never see.
• Context paralysis. I constantly had to think: "Can I send this?" That friction kills flow. I would rather remove the risk entirely.
• Identity leakage. If a significant chunk of your thoughts, plans, and behavior patterns live in someone else’s model, you are training an AI that understands you better than you understand yourself. And you do not own it.

Once I framed it that way, sending more data to closed models started to feel like paying to help someone else build a smarter advertising engine. Or a smarter sales engine. Or a smarter government surveillance tool, depending on the jurisdiction.

I wanted a model that worked for me first.

What decentralized AI actually looks like on my desk

This is where a lot of writing about "decentralized AI" stays vague and fluffy. So here is what I actually run.

On my main machine I have:

• Ollama as the local model runner. It pulls models with a one-line command and gives me a simple HTTP API.
• Several models pulled locally: a small fast one for coding, a slightly bigger one for reasoning and writing, and an embedding model for search.
• A thin Node.js wrapper that exposes these models through a single internal endpoint, with some routing logic based on task type.

I also sync a subset of my notes from my main note-taking system as plain text into a local folder. That folder is indexed with a vector database that also runs locally. No remote sync. No analytics SDKs.

So my "personal AI" is literally a few processes sitting next to my browser and IDE. No external calls once the models are downloaded. If my internet dies, it keeps working.

Why this gives me stronger data sovereignty

Running things locally changes how I think about what I can give the model. Suddenly, I can feed it the stuff I would never send to a third party.

• Private health logs. Sleep data, HRV, weird supplements I am testing.
• Client contracts and pricing experiments.
• Deep personal journals that I would not share with any SaaS platform, no matter how many security badges they display.

The risk profile changes. A breach of my laptop is still bad. But that is a risk I already have, with or without AI. I control the attack surface: full-disk encryption, backups, physical security.

Compare that with giving everything to some opaque AI backend. You are betting your future on their least motivated security engineer and their finance department’s hunger for "data-driven upsell opportunities".

With a sovereign setup, I run my own retention policy. Logs do not leave my machine unless I say so. I can blow away the entire index and retrain from scratch if I feel something is off.

Decentralized does not mean "everyone runs a GPU farm"

I think a lot of developers overcomplicate this. They imagine sovereign AI means they need a rack of RTX cards humming in a closet and a half-baked Kubernetes cluster that occasionally melts down.

That is one end of the spectrum. There is another.

There are at least three levels of sovereignty you can play with.

• Local-only. Everything on your device. Models, index, data. Maximum control, limited by your hardware.
• Self-hosted, single tenant. A small rented server or home box. You still own the stack, but can share it across devices and maybe across a small team.
• Community-hosted. Federated setups where a collective runs infra but with strong guarantees about data isolation and open models.

I mostly stick to local-only for truly personal stuff. For collaborative projects, I lean toward self-hosted. Simple Docker Compose file, Cloudflare tunnel, basic auth, and strict logging. Nothing fancy.

Decentralized here just means we stop assuming "AI = one giant company with a single API". Instead, we accept AI as an application runtime that anyone can run, fork, and remix.

Models are the new personal data vaults

There is a subtle shift when you start treating your model like a personal asset instead of a black box API.

In the old world, your "data vault" was your files. Notes, CSVs, PDFs. Static content.

With sovereign AI, your vault includes:

• The raw data: notes, logs, docs.
• The embeddings and indexes created from that data.
• The fine-tuned weights of any model you adapt for your own patterns.

Those weights are incredibly sensitive. They are not just "some numbers". They reflect your thinking style, your domain knowledge, your trade secrets. In many ways they are more revealing than the original files, because they capture what you focus on and how you connect ideas.

So I store them like I store backups. Encrypted, versioned, and not casually synced through whichever random sync app has the nicest icon.

If you are using models that a vendor can silently swap out, you do not have that option. You cannot freeze your brain. They can. You just receive whatever behavior the latest rollout has decided is acceptable.

How this changes daily workflows

The best part is not the philosophical purity. It is the small, boring wins that add up.

Concrete things that changed for me once I went more sovereign:

• Richer prompts. I stop trimming context to avoid leaking secrets. Instead I can say "Here is the full repo" or "Here is my actual bloodwork" without flinching.
• Longer memory. I let the system build a persistent memory across projects because I know where it lives and how it is stored.
• Honest journaling. My nightly brain dump is blunt and unfiltered. Then I let the model reflect on it. That only works if I trust the runtime.
• Zero-rate limiting. I never hit an API quota while in flow. My GPU fans are the only throttle.

This turns the model from a cute assistant into a serious colleague that actually knows my world. Not just "the internet" plus whatever I am willing to paste into a browser window.

Where I still use centralized AI

I am not a purist. Centralized AI is still incredibly useful.

I use hosted models for:

• Quick one-off questions that are not sensitive.
• Testing new capabilities before they land in local models.
• Large batch jobs where I do not want to tie up my machine for hours.

But I treat those models as external consultants. Helpful, but not allowed into the core of my data or my long-term memory.

If I am shipping something production-facing for a client, I also separate concerns. Public features can use hosted AI. Private internal tooling leans local or self-hosted. Different risk profile, different solution.

Practical constraints and trade-offs

I do not think sovereign AI is free. You trade money and convenience for control and privacy.

Some real drawbacks I hit:

• Hardware cost. A decent GPU is not cheap. Running on CPU works, but it is slower and limits model size.
• Ops overhead. You have to patch, monitor, and occasionally debug your stack. If you hate that, you will resent this setup.
• Model quality gap. Frontier models still outperform most local options on complex tasks. You notice it if you are used to the latest big-name model.

For me, these are acceptable trade-offs. I like tinkering with infra. I like understanding the failure modes. I prefer a slightly dumber but loyal assistant over a genius that reports back to someone else.

If you expect magic with zero maintenance, you will be disappointed. Sovereignty comes with chores, whether we talk about governments, bodies, or AI stacks.

Where I think this is going

I think the interesting future is not "one mega model for everyone". It is millions of half-specialized, half-personalized models that live closer to users.

Your base model might be public and shared. Your fine-tunes and indexes are not. They are bound to your device, your household, your team. You swap base models like you update a library, but you keep your private layer.

We already do this with code. We do not compile the entire internet into one binary. We use shared libraries and then wire them into projects that matter to us. AI should not be special here.

I would love to see:

• Standard formats for exporting and importing personal model state.
• Local-first AI tools that assume no outbound network by default.
• Home servers treated as first-class AI nodes, not an afterthought.

If we get that right, personal data sovereignty stops being a legal slogan and becomes a technical property. You own your weights. You own your indexes. You decide where your intelligence runs.

What I would do if I were starting fresh

If you are still all-in on hosted AI and want to pull some of that gravity back to your side, here is the path I would actually take again.

• Pick one local model runner and stick to it for a while. Ollama, LM Studio, whatever. Do not chase every new tool.
• Move one workflow at a time. For me that was journaling first, then code assistance, then research.
• Keep your data layer boring. Plain text files in a folder beat six clever databases and a mystery SaaS sync.
• Write a tiny script that wraps your local model in a clean API you control. Use that from your editor, your browser, and your scripts.

After a month you will start to feel the difference. Less hesitation about prompts. Fewer "can I paste this" worries. More willingness to let the model see the real mess, not the sanitized version.

That is what sovereignty feels like in practice. Not a manifesto. Just the quiet comfort that your AI works for you, on your machines, with your rules.

The moment you feel that, sending everything you think to some distant cluster will start to feel very strange.

Scroll-snap finally works. Mostly.

I ignored scroll-snap for years. Too many bugs. Too many cross-browser "almost" moments. By 2026, that excuse is gone. The spec is solid, browser support is good, and the roughest edges are sanded down.

I now use scroll-snap in production. On real projects. For real clients. It feels good when I get it right, and completely hostile when I force it into the wrong context. This is the pattern I see over and over.

My rough rule: does the user think in pages or in flow?

I use a simple mental model when I consider scroll-snap.

• If the content is naturally chunked into discrete pages or cards, scroll-snap is usually a good fit.
• If the content is a continuous flow of text or mixed content, scroll-snap almost always feels wrong.

People either think "next card / next slide" or they think "keep scrolling". Scroll-snap works for the first one. It fights the user on the second.

Where scroll-snap feels native

Let me run through the places where scroll-snap has actually stuck in my work. Not experiments. Live stuff.

1. Horizontal carousels that feel like native app sliders

This is the obvious one, but I still see it built with 4,000 lines of JS.

If you have a row of cards that the user swipes through horizontally, scroll-snap is usually perfect. Think feature carousels, product tiles, dashboard widgets, onboarding steps.

The pattern I use:

.carousel {
  scroll-snap-type: x mandatory;
  overflow-x: auto;
  display: flex;
  scroll-behavior: smooth; /* optional, careful with this */
}

.carousel > * {
  scroll-snap-align: start;
  flex: 0 0 100%; /* or clamp(...) based on design */
}

On mobile, this feels like a native view pager. The mental model matches: one card at a time, swipe to the next. The browser handles momentum and snapping. I do not touch scroll events at all.

When it works best:

• Each card is visually distinct and self-contained.
• You have clear pagination indicators or progress.
• You avoid nesting multiple snap carousels inside each other.

I think horizontal carousels are the main place where scroll-snap is absolutely the right tool.

2. Story-style layouts and full-bleed sections

I built a landing page last year with full-viewport sections. Each section was basically a "slide" of the story. Big headline. Illustration. Single CTA.

The client originally wanted fake scroll-jacking: one flick of the wheel, snap to the next full panel. You know the style. Looks like a slide deck disguised as a website. My compromise was scroll-snap.

body {
  scroll-snap-type: y mandatory;
}

section.full-screen {
  scroll-snap-align: start;
  min-height: 100vh;
}

The big difference compared to pure scroll-jacking: the browser still owns scrolling physics. I am not animating scrollTop in JS. I am simply expressing an intention: when a user releases scroll, prefer these resting positions.

This worked surprisingly well on touch devices. It felt like swiping between slides. On desktop, it was a bit more polarizing but still better than intercepting every wheel tick.

When this pattern makes sense:

• You really do have full-screen sections, not half-screen snippets.
• The copy inside each section is short. No one needs to scroll inside a section.
• The layout behaves nicely at different heights. 11-inch laptops and tall monitors both look okay.

If you find yourself adding internal scrolling inside a snap section, that is the first sign you picked the wrong layout for scroll-snap.

3. Onboarding, step flows, and checklists

I built a small web app that walks new users through a setup process. Notifications, integrations, profile, that kind of thing.

Instead of a classic multi-step wizard with "Next" and "Back" buttons, I used a vertical stack of cards and scroll-snap. Each step was one card. User scrolls down, it locks to the next card.

Two nice things happened:

• The user could skim all steps quickly. Scroll velocity still matters.
• Each card felt like a clear decision point, not just another part of a long form.

Pattern looked like this:

.steps {
  scroll-snap-type: y proximity;
  max-height: 100vh;
  overflow-y: auto;
}

.step {
  scroll-snap-align: start;
  padding-block: 3rem;
}

I used proximity instead of mandatory, so snapping only kicks in when you are near a snap point. That gives a bit more control back to the user.

For short, focused flows like this, scroll-snap helps structure the experience without feeling like a trap.

4. Media rails and galleries

Photo galleries. Video rails. Collections of thumbnails. Scroll-snap fits here if you keep it simple.

I usually keep the main page scroll normal, and only add scroll-snap to horizontal media rails. This avoids messing with the core reading flow while still giving that "one card per stop" feel for visual content.

It is tempting to build fancy cinematic galleries that lock the viewport tightly. I tried that, then watched users repeatedly fight the scroll because they just wanted to browse. Now I think of scroll-snap here as a hint, not a constraint.

Where scroll-snap fights the user

Now the painful part. Places where scroll-snap seemed clever in Figma but felt terrible in reality.

1. Long-form reading and articles

I tried scroll-snap on a personal writing experiment. Full-screen sections, big typography, split into "chapters". It looked slick. It read badly.

People do not read text like cards. They skim, bounce, scroll back a bit, stop mid-paragraph, continue later. Scroll-snap breaks this rhythm.

Two things went wrong:

• Stopping mid-section became annoying. You scroll a tiny bit to re-read a line and it yanks you to the top of the section.
• The viewport breakpoints cut paragraphs in odd places at various screen heights.

I removed scroll-snap and it instantly felt more natural, even though I lost that fake "presentation" vibe.

My rule now is strict: no scroll-snap for primarily text-based content. Blogs, documentation, long release notes. It always feels like the UI is more important than the reading.

2. Accessibility: keyboard, screen readers, and reduced motion

The spec and implementations are better now, but scroll-snap still introduces friction if you do not think about input methods beyond trackpads.

Edge cases I hit:

• Keyboard users: PageDown or spacebar trying to move by viewport height but snap yanking them back to a card boundary.
• Focus management: elements getting scrolled somewhere between snaps, then the layout jumping when the user tries to tab.
• Reduced motion users: scroll-behavior: smooth combined with snap producing long, animated scrolls that are exhausting.

I now treat scroll-behavior: smooth as something that should usually respect prefers-reduced-motion. If I use it next to scroll-snap, I wrap it:

@media (prefers-reduced-motion: no-preference) {
  .carousel {
    scroll-behavior: smooth;
  }
}

Also, when I build scroll-snap experiences that are more than a simple carousel, I test with just keyboard on a laptop. If I feel like I am fighting the layout, I back off.

3. Nested scroll containers

Nesting scrollable areas is already tricky. Throw scroll-snap into the mix and tiny differences in momentum handling across browsers turn into visible bugs.

I had a dashboard layout with a vertical scrollable page. Inside that, a horizontal snap carousel with cards. Inside one card, a small vertical scroll area.

On Safari this felt mostly acceptable. On Chrome, touch gestures sometimes locked onto the wrong axis and flicked the outer container instead of sliding the inner carousel.

Technically nothing was broken. It just felt random.

My approach now:

• Avoid vertical scroll inside vertical-snap parents.
• Avoid diagonal gesture ambiguity. Pick one primary axis per region.
• Accept that deeply nested scroll-snap is going to behave differently between engines.

If your layout needs three nested scrollables, scroll-snap probably is not the problem. The layout is.

4. Fake carousels built on body scroll

One pattern I see a lot: a designer wants a "carousel" feel, but the implementation uses the main page scroll instead of a dedicated container.

So you get a long page of full-width panels, and snap on body or html. Each wheel tick tries to pull you to the next full-screen card.

This sounds minimal. No extra wrappers. Nice and pure. In practice, though, it creates weird interactions with browser UI, address bars on mobile, and anchored navigation. You also lose the ability to scroll the page freely while leaving other stuff (headers, sidebars) fixed.

I think scroll-snap works better when scoped to a clear component: a carousel, a story rail, an onboarding stack. Once you snap the whole document, you are overriding one of the most basic browser behaviors we have.

Choosing between mandatory, proximity, and not using it at all

I use scroll-snap aggressively in prototypes, then usually downgrade it in production. There are three states I move between.

Hard snap: scroll-snap-type: mandatory

I use this only when I want very strong opinions. Full-screen sections, strictly one-card-per-view carousels, or kiosk-style experiences.

If you do not control the environment (monitor size, device type, touch vs wheel), mandatory can feel brutal. That is fine for installations or marketing microsites where spectacle is the product. Not great for a dashboard someone lives in eight hours a day.

Soft snap: scroll-snap-type: proximity

This is the default I reach for now. It behaves like "snap when it feels natural, but do not fight the user".

You can scroll through multiple cards with a fast fling. You can stop between them. When you land near a snap point, the browser gently pulls you in. For many use cases this is the sweet spot.

No snap: regular scrolling

I prototype a layout, add scroll-snap, then actually use it for a few minutes. If I ever feel annoyed, I remove it.

Most of the time that happens on long-form layouts, mixed-content pages, or anything with sidebars and lots of interactive elements. Regular scrolling wins.

Scroll-snap plus JS: when to mix them

I prefer scroll-snap as the primary mechanic and JavaScript as an enhancement or backstop, not the other way around.

Two patterns that worked for me.

1. Programmatic "go to card" without custom physics

If I build a carousel with scroll-snap, and the design wants Next / Previous arrows or dot navigation, I hook into it with scrollTo and let snap finish the job.

function scrollToCard(container, index) {
  const card = container.children[index];
  if (!card) return;

  const left = card.offsetLeft;
  container.scrollTo({ left, behavior: 'smooth' });
}

Snap ensures the resting position is consistent, even if the math is slightly off. The browser still manages momentum and any platform-specific quirks.

2. Syncing state with scroll position

Sometimes I want to update a progress bar or highlight an active nav item as the user scrolls a snap container.

I use IntersectionObserver on the snap children, not raw scroll events. That way, I piggyback on the snap behavior instead of fighting it.

const observer = new IntersectionObserver(entries => {
  for (const entry of entries) {
    if (entry.isIntersecting) {
      setActiveStep(entry.target.dataset.stepId);
    }
  }
}, {
  root: document.querySelector('.steps'),
  threshold: 0.6
});

for (const step of document.querySelectorAll('.step')) {
  observer.observe(step);
}

The user scrolls, scroll-snap does its thing, and the JS just listens for "which card is mostly in view". No constant tug-of-war.

Practical checklist: should you use scroll-snap here?

This is the quick checklist I run through now.

• Is the content naturally paged? Cards, slides, steps, photos. Good candidate.
• Does the user need fine-grained scroll control? Reading, code, long specs. Skip scroll-snap.
• Is there nested scrolling? If yes, be very suspicious. Try to simplify.
• Have you tested keyboard and reduced-motion? If not, you are not done.
• Are you using mandatory just because it feels "clean"? Try proximity first.
• Does the layout still work if scroll-snap is disabled? If not, your UX is too dependent on a single behavior.

Scroll-snap in 2026: stable, but not neutral

Scroll-snap is not experimental anymore. It is a sharp tool. Sharp tools are great when you use them for the right job and they are brutal when you grab them just because they look cool.

I now think of scroll-snap as a way to express structure, not as a way to show off motion. If the structure is already there in the content model, scroll-snap usually feels natural. If I am trying to hide a messy layout behind clever snapping, users notice.

So I keep it scoped, test it on real devices, and remove it the moment it starts winning arguments against the user.

Why I Treat GEO As An Engineering Problem

I do local SEO like I do frontend architecture. Systems first, vibes second.

Most small businesses that reach out to me want the same thing. "Rank for my service + my city and get more calls." They usually have a five-page WordPress site from 2017, a half-filled Google Business Profile, and a bunch of junk citations from directories they never asked for.

So I stopped improvising. I built a repeatable GEO strategy. Same skeleton every time. Then I tweak per niche.

Here is the process I actually use with clients. Timeline, steps, what I look at, and where AI and llms.txt fit in.

My calendar looks perfect. For about 6 hours.

I love clean time blocks. Color-coded. Edges aligned to the half hour. A neat little life in 2D.

Reality does not care.

I coach baseball. I build weird web experiences. I write. I have a family. I also like sleeping and not being a wreck by Thursday.

So this is what I actually do. Not the Instagram version of time blocking. The version that gets punched in the face by kids, clients, and Dutch weather, and still mostly works.

The fake perfect week I wanted

When I started taking time blocking seriously, I tried to design the ideal builder-coach-writer week.

On paper, it looked like this:

• 07:00 – 08:30: Deep work (writing)
• 09:00 – 12:00: Dev work (client or product)
• 13:00 – 16:00: Dev work (focus blocks)
• 16:30 – 18:30: Coaching (training or games)
• 20:00 – 21:00: Light admin, planning next day

Sprinkle in lunch, a walk, some mobility, and an enlightened look on my face. Perfect.

That calendar survived about one week. Kind of. Then reality sent some feedback:

• Morning writing often collided with late games or travel the night before.
• Client calls landed right in the middle of "sacred" deep work.
• Rain rescheduled practices. Games moved. Whole evenings disappeared.
• Kids have zero respect for my notion of context switching.

I kept trying to force life into that ideal template. I was exhausted by the second month.

The mental shift: blocks are bets, not promises

The week started working when I changed how I think about blocks.

I used to treat a time block like a contract. "Tuesday 9 to 12 is deep work, non-negotiable." Guess what. Life negotiates.

Now I treat blocks like bets.

• I bet that if nothing explodes, I will use this time for X.
• If something explodes, the block moves or shrinks, but the energy type stays the same.

That energy-type idea is important. I care less about whether I wrote a blog or coded a feature. I care more that I used deep-focus energy for something that deserved it.

This is how I group the week now:

• Deep build time: no meetings, no Slack, high-energy work.
• Shallow work: email, comments, tickets, light coding.
• Coaching time: physical, social, high-output.
• Recovery time: walks, reading, stretching, being offline.

Then I lay blocks for those energy types first. Exact tasks come later.

The real weekly structure I use now

I will walk you through a real pattern I fall back on. This is my baseline. Every Sunday I copy this into the next week, then adapt.

Monday: protect the runway

Monday used to be my "let's catch up" day. Which is a nice way to say "let's scatter my brain." Now I use it to set the runway for the week.

• 07:30 – 08:30: Walk + notes. No laptop. Just a short walk and notes on my phone. I brain dump everything I think I "have" to do.
• 09:00 – 10:00: Weekly planning. Calendar open. Task manager open. I assign work to days. I also block out coaching slots first, because those are fixed.
• 10:00 – 12:00: Deep build block. Usually architecture decisions, prototypes, or anything that needs a fresh brain.
• 13:30 – 15:30: Client or product work. Still deep, but I allow one call if needed.
• Evening: Free or recovery. Never hard commitments if I can avoid it.

Key rule for Monday: I refuse to start the week already behind.

I say no to Monday morning meetings whenever I can. I want the first big block of the week to be me making progress on my work, not reacting to other people.

Tuesday & Wednesday: heavy build days

These are my brutalist days. I front-load as much cognitive load as possible into 48 hours.

• 08:30 – 11:30: Deep work block. Usually coding. Sometimes design and UX flows. I aim for one clear objective per block. Ship a thing. Remove a blocker. Finish a chunk of infrastructure.
• 11:30 – 12:00: Admin sprint. Inbox, messages, quick replies. I run a 25-minute timer and process aggressively.
• 13:30 – 15:30: Second build block. Slightly lighter. Code reviews, refactors, tests, content edits.
• Late afternoon / evening: Coaching. Training sessions, drills, planning lineups.

The reality check part:

• If a game gets rescheduled to midweek, the evening coaching block stretches or moves earlier. I don't fight it. Coaching is not optional.
• If a client insists on a meeting here, I trade. That means I protect a different deep block later and mark it as untouchable.

This is where time blocking breaks for a lot of people. They try to defend every single block equally. I do not. I defend two deep blocks per week like my life depends on it. The others are flexible.

Thursday: context switch and writing

By Thursday my brain is a bit fried from heavy build work and coaching. I lean into that instead of pretending I am still fresh.

• 08:30 – 10:00: Writing block. Blog posts like this, docs, outlines, marketing copy. I treat it like coding. One small outcome.
• 10:00 – 12:00: Shallow work. Tickets, comments, light UI tweaks, bug triage.
• 14:00 – 16:00: Second writing or creative block. Sometimes I script a small interactive demo. Sometimes I just freewrite about something I shipped.
• Evening: Games or training if scheduled. If not, family and recovery.

I stopped trying to write in the "perfect" conditions. My reality is that by Thursday I have a lot of context in my head. That is perfect material for writing as long as I do not aim for poetry, just clarity.

I also noticed something specific. If I push another heavy coding block on Thursday afternoon, I will be useless on Friday. So I stay under my capacity here on purpose.

Friday: maintenance and future-proofing

Friday is anti-heroic. That is by design.

• 08:30 – 10:30: Loose build block. Finish any near-done feature. Merge, clean up, document.
• 11:00 – 12:00: Weekly review. I walk through my calendar, see what actually happened, and compare it to the plan.
• 13:30 – 15:00: Learning or sandbox. I test some weird CSS thing. Play with a new API. Draft ideas for future posts.
• Afternoon / evening: Coaching or early shutdown, depending on the schedule.

I treat Friday as my safety buffer.

Anything that slipped from earlier in the week can land here. If the week went cleanly, I use this time to set up next week. If the week was chaos, Friday is where I put everything back into some kind of order.

The calendar after reality hits

If you look at my calendar at the start of the week and at the end, you would think two different people made them.

Here is what usually changes:

• Blocks get resized: A 3-hour deep work block becomes 90 minutes. I cut the scope, not the block.
• Tasks move inside blocks: The energy type stays, but the actual task changes. Maybe I write instead of code, but I still treat it as deep focus.
• Coaching expands: Weather, travel, extra planning. If the field time grows, something else shrinks that day.
• Evenings get reclaimed: If a day gets wrecked, I do not immediately steal from sleep to compensate. I prefer to slip a task to Friday or kill it.

The important part is this. I am not trying to defend my exact schedule. I am defending my energy budget.

I want roughly:

• 3 to 4 deep build blocks per week.
• 2 writing blocks.
• 1 solid planning session.
• Enough slack so that coaching does not destroy me.

As long as I hit those numbers, I do not care if a block moved by 90 minutes or traded days.

The constraints that keep me from burning out

Time blocking is easy. Not torching yourself is where it gets tricky.

I follow a few hard constraints. They are non-negotiable, because I learned the hard way.

1. No heroic late nights after games

Coaching is intense. I am on my feet, talking, deciding, moving. If I get back late and then decide to "catch up" for two hours, I pay for it for three days.

So I have a simple rule. If there is a night game or late training, that evening has zero cognitively important work. I can stretch, read, or stare at the wall. That is it.

2. One overloaded day max

Sometimes everything lands at once. Deadline, travel, game, family thing. Old me would turn three days into overloaded fire drills.

Now I accept that sometimes one day will be stupid. Packed, messy, too much.

But I force the days around it to be lighter. If Thursday looks insane, I carve down Wednesday and Friday on purpose. Fewer tasks. Smaller scope.

3. Deep work is a quota, not a fantasy

A lot of productivity content pretends you can run four deep work blocks every day if you "optimize" hard enough. I think that is nonsense for most humans with families, clients, and external commitments.

My quota is simple:

• Two deep work blocks are mandatory.
• Three is a good week.
• Four is rare and I do not plan for it.

If a week is heavy with coaching, I am happy with two solid blocks and no guilt. That is the tradeoff for standing on a field and actually working with players instead of staying in a chair.

4. Planning is work, not overhead

The weekly review and planning on Friday and Monday used to feel like "not real work." I would skip them when I felt behind.

That was stupid. Skipping planning is how you end up behind in the first place.

Now I treat planning as its own block with one outcome. My goal is to leave that session with:

• Three concrete build goals for the week.
• Two writing topics picked.
• Coaching sessions and games locked on the calendar.
• At least one afternoon that is intentionally light.

I do not need every hour planned. I just need the big rocks pinned, and I need to see where the week will be heavy.

Tools I actually use

Nothing fancy here. I do not think tools solve this for you. They just make the pain slightly smaller.

• Google Calendar for hard calendar events and high-level blocks.
• A task manager (I rotate, but the pattern is the same) for daily lists broken down from those blocks.
• Plain text notes for weekly reviews and "what actually happened" logs.

The log is underrated. Every Friday I write three bullets:

• What I planned.
• What really happened.
• Why it changed.

Over a few months, patterns appear. Certain days always blow up. Certain clients always push last-minute. Certain coaching periods are heavier.

Then I adjust the baseline week for that season instead of pretending next week will somehow be different.

The honest tradeoffs

I cannot do everything every week. Neither can you. Time blocking does not magically bend time around that fact.

What it does for me:

• It forces me to see the actual tradeoffs between coaching, building, and writing.
• It gives me a default week I can distort without completely losing structure.
• It keeps my deep work quota realistic, which keeps me from burning out.

My calendar still looks perfect on Sunday night.

By Friday afternoon it looks like a crime scene. Blocks moved, resized, scratched out, colors everywhere.

But if I hit my deep work quota, got my players better, shipped a couple of things, and still want to show up again next week, then the system did its job.

The goal is not a clean calendar. The goal is a life you can keep running without grinding yourself into the ground.