GutStream Update #10: How GutStream Actually Works

A full technical walkthrough before GutStream opens to the public

Update #9, posted nearly two months ago, ended with a reversal.

NHANES, the dataset this project was originally built around, could not do the one thing I ultimately wanted it to do: tell an individual person what to change. It could describe populations and show associations, but it could not take one person’s situation and turn that information into a clear recommendation for what they should actually try next.

That post ended with a promise that the next one would explain what replaced it.

A lot has happened since then. The project moved from research into a working system, and it finally has a name: GutStream.

This post is the full arc of that transition: what replaced NHANES, how the recommendation engine decides what to suggest, how the system determines whether something actually worked, what happens when it doesn’t, and how all of this fits with the clinicians who will eventually use the data.

I’m writing this for anyone who wants to understand how GutStream was built before trusting it, whether that’s someone dealing with gut symptoms or a clinician treating them.

The difference from what NHANES could have powered comes down to three ideas:

• Individual instead of population average

• Experimental instead of observational

• Safety-gated instead of blind

Part I: The Recommendation Engine

Who it’s for

GutStream will offer a free recommendation tool for people looking for evidence-graded guidance on what to try for their symptoms. The goal isn’t to give someone a list of 30 things they could change. It’s to give them one reasonable place to start, measure what happens, and decide what to do next based on the result.

Two decisions changed everything

The first major change was expanding the outcome set.

The project originally focused on brain fog, mental clarity, energy, and anxiety. Those were interesting outcomes, especially because people with digestive problems frequently report them, but the more I worked on it, the more obvious the limitation became. Someone dealing with gut problems doesn’t experience their symptoms in isolated categories: brain fog can show up alongside bloating, anxiety alongside abdominal pain, and fatigue alongside diarrhea.

Measuring the mental side while ignoring the gut side was only measuring half of the problem. So the system expanded to ten symptoms across both gut and mental health. That one decision made almost everything downstream harder, but it also made the product much closer to what I actually wanted to build.

The second major change was the evidence itself.

NHANES was useful for understanding populations, but it was never going to be enough for recommendations. Take coffee and focus. NHANES might show that people who drink more coffee report better focus, but that doesn’t tell us why. Maybe coffee improves focus, maybe people who are already more focused drink more coffee, or maybe another factor drives both.

A controlled trial gets closer to the question we actually care about. Researchers change one input, compare it with a control, and observe what happens to the outcome. That gives us an estimate of the effect rather than simply an association, which is much closer to what a recommendation system needs.

So the evidence base was rebuilt around experimental literature, study by study.

There is an important distinction here, though. Using trials does not mean every recommendation is proven causal for an individual person. A trial estimates an average effect across a group. When GutStream applies that evidence to one person, it is still testing whether that person responds. The rigor comes from the quality of the evidence and from measuring what happens next, not from pretending that a population-level trial proves what will happen to one individual.

Where the inputs come from

Before GutStream can make a recommendation, it needs to understand where someone is starting. The onboarding takes roughly ten minutes and begins by asking the top symptoms the person wants to focus on. From there, the intake adapts, with someone only receiving the questions that are relevant to their situation.

The point isn’t to collect every possible piece of information. It’s to collect enough to understand the person’s starting point, so the engine isn’t guessing about things like headroom, fit, or safety. Two people can therefore go through different numbers of questions depending on what is actually true for them.

That same principle carries into the safety system. A hard stop only works if the system knows the information needed to trigger it. If someone with compromised kidney function should not receive a particular recommendation, the intake needs to have asked about that risk in the first place

How recommendations are selected

Every possible recommendation goes through two filters before it can even compete for a spot.

1. Safety filter: if the system cannot confirm that an option is safe for that person, it is removed. Missing information counts as a no.

2. Fit filter: this asks whether the recommendation makes practical sense for that person’s situation. Here, missing information counts as a yes.

Those defaults are intentionally different. For safety, uncertainty should make the system more conservative. For fit, uncertainty shouldn’t unnecessarily prevent someone from trying a harmless option.

Once something survives both filters, it gets ranked using three factors:

• Evidence: how strongly the research supports the intervention

• Confidence: how confident we should be in that evidence

• Headroom: how much room this particular person has left to improve

Headroom is especially important. If someone already sleeps eight hours a night, sleep might have excellent evidence behind it, but there isn’t much left to improve. Two people can therefore receive completely different recommendations from the exact same evidence base simply because they are starting from different places.

Why I built a deterministic engine instead of a trained model

For a data scientist building a recommendation system in 2026, the obvious move would be to train a model. I decided on the opposite. GutStream’s recommendation engine is deterministic: the same person, with the same information, gets the same recommendation, and the system can show exactly why.

There are three reasons for that:

1. Auditability. When a system is making recommendations about someone’s body, “the model decided” isn’t a good enough explanation. Every recommendation needs to trace back to a rule, a piece of evidence, and information the person actually provided.

2. Safety. Hard safety guarantees require hard rules. A trained model can perform extremely well on average and still fail unpredictably at the edges, and people with chronic conditions are often exactly where those edge cases matter most.

3. The data isn’t good enough to justify the complexity. My original NHANES analysis explained roughly 13 to 22 percent of the variation in the outcomes I cared about. Training a sophisticated model on that data might produce impressive-looking predictions, but it would create a level of precision the underlying data doesn’t support. That would be false precision with good branding.

What actually shows up

Open the plan and you don’t get a wall of recommendations. You get one clear place to start for each symptom. Two additional recommendations sit behind the first one, held back intentionally rather than dumped on someone all at once.

The reason is simple: change one thing at a time, and you can actually tell whether it mattered. If someone changes three things and feels better, they don’t know which change helped. So each top recommendation runs for two weeks, long enough to reach a meaningful verdict.

If it works, it stays. If it doesn’t improve the symptom, the next recommendation moves into place and gets its own two-week trial. After trying the top three evidence-backed approaches and six total weeks, if outcomes still haven’t meaningfully moved through the highest-evidence options available, the system doesn’t just keep generating another suggestion. It tells the truth.

At that point, free lifestyle changes have done what they can, and the appropriate next step is a professional. Everything that wasn’t selected remains visible too. Nothing is hidden. Those options are simply labeled differently and sorted by evidence strength rather than personal fit. Some also require a practitioner to act on them, and those are clearly identified.

A good system needs to know where its own advice ends.

The safety layer

Most consumer health tools handle safety with a sentence at the bottom of the page: consult your doctor. I wanted GutStream’s safety system to be structural instead, because a disclaimer after a recommendation doesn’t actually prevent a bad recommendation from being made.

There are three main parts:

Hard stops. Some interventions are reasonable for one person and inappropriate for another. L-glutamine is one example: there is evidence around certain gut symptoms, but it can be inappropriate for someone with compromised kidney function. That’s not something the system should mention in a disclaimer after making the recommendation. The recommendation should never be generated in the first place.

Ongoing checkpoints. A system that measures mood and cognition will eventually be used by someone who is going through a genuinely difficult time. That means safety can’t be handled by one screening question during onboarding. GutStream checks in at intervals over time, with an immediate flag if someone’s initial answers indicate severe symptoms. Crisis resources remain visible on the platform at all times.

No fake gates. This one matters just as much. The system never claims to enforce a protection it cannot actually verify. If there is a safety gap I haven’t solved yet, it is documented internally as unenforced. I’d rather have an imperfect system that admits what it cannot do than a polished system that pretends it has solved something it hasn’t.

What happens when someone has multiple symptoms?

A recommendation engine that works for a textbook patient with one clean symptom isn’t very useful in the real world. Actual people have several things going on at once, so GutStream tracks up to two symptoms simultaneously, to preserve clean attribution, with each one running on its own independent track.

Bloating doesn’t borrow priority from brain fog, and brain fog doesn’t get ranked higher just because another symptom is worse. Each symptom is evaluated using its own evidence, confidence, and headroom.

The two-symptom limit is intentional. Every additional symptom spreads the available signal thinner and makes the daily check-in more burdensome. At some point, collecting more information starts making the system worse rather than better at identifying the true catalyst for change.

Two keeps the data meaningful while keeping the daily interaction short enough that someone will actually still be doing it a month later.

Potential nutrient deficiencies are handled separately. “You may be low in something” is a different kind of recommendation from “this behavior may help your symptoms,” so those recommendations are scored differently, based primarily on the probability of a deficiency rather than behavioral headroom.

One key rule applies across the entire system: Nothing that plausibly helps one symptom gets through if it plausibly worsens the other. The whole person comes before any individual score.

Part II: Measurement and Verdicts

An engine that recommends and never checks itself is an opinion with a database. Deciding what to suggest is half the system. The other half is knowing whether it worked, and what happens next because of it.

How outcomes get measured

Construct-aligned measures, not borrowed instruments. Daily check-ins capture three things:

1. Severity: How bad the symptom was

2. Frequency/Duration: How often or how long it lasted

3. Interference: How much it got in the way of daily life

The wording deliberately mirrors validated research instruments so the data stays interpretable to a clinician, but it does not administer those instruments directly. A questionnaire validated for monthly recall is no longer validated once you ask it every day. Borrowing the phrasing preserves comparability. Borrowing the instrument itself would have been a claim the design can’t support.

Burden matters. A system that exhausts people only produces data about the kind of people who tolerate exhausting systems. Daily check-ins are tiered to capacity, and on a rough day the whole interaction collapses to a single tap.

Episodes are logged as events, not averaged away. Brain fog does not arrive as a smooth weekly average. It arrives in episodes. A brutal Tuesday and a wrecked Wednesday can disappear inside a calm-looking weekly score.

Reaching a verdict

This is the part I care most about, and the part that separates this from every tracking app I studied. Trackers log. This reaches a verdict on whether a change worked.

Adherence is measured separately from outcome. If a change was barely followed, the honest conclusion is “this was not really tested,” not “this failed.” There is also an explicit too-early state. Most apps choose not to say it, because uncertainty does not retain users. Lastly, worsening requires more than one signal. A single bad reading never triggers a reversal.

Each outcome is judged on its own scale. Symptoms measured on incommensurable scales are not blended into one composite number, because a composite is only as meaningful as the assumption that the scales are comparable. They are not.

Verdicts are never tuned to feel encouraging. At no point in this build did “will this feel motivating” factor into what the system concludes. This last rule was the most expensive decision in the project. Encouraging verdicts retain users. Honest ones do not always. I took the retention cost, because the entire value of a verdict depends on whether it can be believed.

What a verdict changes

A verdict that doesn’t change anything is just a number. Here, it decides what happens to the plan itself.

If something is working, it stays. It does not get swapped out to make room for the next idea just because time has passed. The next recommendation gets added alongside it instead, so progress that’s real doesn’t get undone in the name of moving forward.

If something isn’t working, it gets replaced, not left in the plan out of momentum.

Every lever added this way tracks its own timeline from the day it started, so when three things are eventually running at once, success and failure never blur into one undifferentiated bundle. There’s still a ceiling, so a working plan can’t quietly turn into a pile of everything that’s ever helped a little.

Each change traces to a logged record: what started, when, against which outcome, and what the verdict was, so the history is auditable rather than remembered.

Part III: Built With Clinicians in Mind

Most of what happens to a patient happens where no practitioner can see it, in the weeks between appointments. That absence shaped decisions throughout this build, not just the ones that show up on a clinician’s screen.

It’s why check-ins happen every day instead of only at appointments. A patient’s best recollection of a rough month is not data, it’s a guess dressed up as a report, and that guess is what most clinicians currently work from. Daily logging replaces the guess with an actual day-by-day account of what happened, which is the only way “between visits” stops being a blind spot.

But daily only works if daily is fast. A check-in that takes real effort gets skipped, and a skipped check-in is worse than no system at all, it’s a gap that looks like data. So the patient side had to stay under ninety seconds, something closer to a glance than a form. The harder problem was making that same minute and a half add up to something a practitioner could actually use, not just a pile of taps. Both sides had to be true at once, or neither one was worth building.

Two rules govern what the clinician actually sees and controls. First, the clinician prescribes and the system measures. When a practitioner directs a specific change, the engine tracks it faithfully and never overrules the human. Second, sustained non-improvement at good adherence is a referral signal, not a retry loop. When someone follows a plan closely and still does not improve, confirmed over time rather than off one data point, the honest move is to say so and route them to get professional assistance, not keep proposing new levers to pull.

From a Data Perspective

The NHANES version of this project was comfortable. Clean, defensible, and genuinely interesting to work through. But comfortable was never the point. Somewhere in that comfort I had to admit what I actually wanted: not a good dataset, a system that helped someone.

What I wanted turned out to have two halves, both from the same place. I know exactly what it feels like to be handed general advice for a specific body. Real experimentation, trying something, tracking it honestly, and adjusting has been the only thing that’s ever worked for me. I wanted to build the tool I wish I’d had: pulling from the best available evidence, handing someone a real place to start, at no cost, because the ability to try shouldn’t be something you have to pay for.

The other half came from the other side of those same appointments. I’ve sat across from clinicians doing their best with almost nothing to work from, because a patient’s memory of the last month is an impression, not data. I wanted to give GI clinicians and dietitians what I never saw them have: a real, day-by-day account of what a patient’s body was actually doing.

Those two halves are why this stopped being a data project and became something that has to earn trust twice, once from the person using it daily and once from the person reading their chart. Hardest and most rewarding thing I’ve built, and a real part of what made it possible in this timeframe was learning to work alongside AI systems. Not just to use them, but to learn where they genuinely speed engineering up and where they quietly cost you if you’re not paying attention.

A few things I didn’t expect to learn:

The instinct to reach for a smarter model is usually a distraction from a harder question: can you defend the answer at all. Determinism isn’t a safety compromise, it’s what lets you stand behind an answer instead of hoping it’s right.

Measurement design isn’t a supporting detail, it’s the ceiling on what you’re even capable of discovering. How you ask a question, how often, at what resolution, quietly decides what truths are reachable later. Get that wrong early and no clever analysis downstream fixes it.

GutStream launches in a few weeks. Next post: what it costs, how the free side works, what it gives clinicians that a practice management tool doesn’t, and how to get in.