BitFitness Metabolic Research Pilot
From Raw Data to Better Personal Recommendations — Without Requiring CGM
The BitFitness Metabolic Research Pilot studies how everyday behaviors — meals, sleep, training, hunger, cravings, weight changes, and recovery — connect into repeatable patterns that can later improve personalized recommendations inside the app.
Why We Are Running This Pilot
Most fitness and wellness apps collect useful data: meals, workouts, sleep, weight, steps, and subjective feelings. But many recommendations still feel generic.
BitFitness is working toward a more personalized model.
The goal of this pilot is to understand how real behavior affects real outcomes. We are looking at chains such as:
Meal choice → glucose response → hunger → cravings → next meal behavior
Sleep quality → recovery → hunger → training performance → weight trend
Workout timing → glucose stability → recovery → next-day energy
Post-meal walking → glucose stability → hunger control
The purpose is not to create a glucose app. The purpose is to learn which behavioral patterns are repeatable enough to become useful recommendations for everyday users.
What We Are Studying
In this pilot, we are observing how daily lifestyle behaviors connect to short-term and longer-term outcomes.
We are especially interested in patterns such as:
Which meals create stronger glucose responses.
Which meals appear to support better satiety.
Whether certain meals are followed by delayed hunger or cravings.
How sleep and recovery affect food choices the next day.
How training affects glucose stability, hunger, recovery, and weight trends.
Whether post-meal movement improves glucose stability.
Whether certain patterns repeat across different days, contexts, and testers.
The important word is repeatable.
One unusual day does not create a conclusion. A single glucose spike does not create a recommendation. A pattern becomes interesting only when it appears more than once, in a similar direction, and cannot be explained only by missing data, logging errors, or sensor gaps.
How The Pilot Works
The pilot combines several types of data.
1. User-Entered Data
This includes information manually entered by testers:
Meals
Hunger
Cravings
Weight
Subjective feelings
Notes and context
This is the primary behavioral source of truth because BitFitness must ultimately work from user behavior, not from medical sensors.
2. Measured Data
This includes data collected from devices:
Libre glucose data
Apple Watch sleep
Heart rate
Activity
Steps
Workouts
Measured data helps us understand what may be happening physiologically after specific behaviors.
3. Estimated Data
This includes scores and model-based signals:
Recovery score
Physiological strain
Cardio score
Metabolic stress indicators
These signals are useful, but they are treated differently from directly measured data. We always separate measured, estimated, and user-entered information during analysis.
The Role of Libre CGM in This Research
Libre sensors are used during the pilot as an observational research tool. They help us understand glucose responses behind daily behaviors, but they are not a required part of the future BitFitness product.
During the pilot, testers wear Libre sensors so we can observe how glucose changes after meals, workouts, poor sleep, alcohol, stress, or post-meal movement.
This helps answer questions like:
Did a meal produce a large glucose response?
Did glucose stay elevated for a long time?
Did a walk after eating improve stability?
Did poor sleep change the next day’s hunger or cravings?
Did a workout improve or worsen next-day recovery?
However, CGM data is not the final product dependency. The long-term goal is to use CGM temporarily during research, discover reliable behavioral patterns, and then translate those patterns into app recommendations that work for users who do not wear glucose sensors.
Pilot Testers
Tester 01 wearing a Libre sensor during the pilot. Participant identity and personal health data are kept confidential.
Tester 02 wearing a Libre sensor during the pilot. The sensor helps enrich behavioral analysis during research but is not required for future BitFitness users.
The current pilot includes two testers. Each tester provides app logs, wearable data, glucose data, and baseline context.
Participant privacy is central to the research process. Public updates will focus on patterns, methods, data quality, and product learnings — not personal medical interpretation.
Research Workflow
The pilot follows a four-week structure: first validating data quality, then identifying early reactions, then detecting repeatable patterns, and finally validating patterns before turning them into future alert concepts.
The pilot follows four main stages.
Week 1 — Validate Data Quality
The first week is about building a reliable foundation. Before looking for patterns, we need to make sure the data is complete, synchronized, and usable.
This includes checking:
Whether all data sources are connected.
Whether meal, hunger, weight, and feeling logs are being captured.
Whether Libre glucose data is available.
Whether Apple Watch sleep, heart rate, activity, and workout data are present.
Whether there are sync gaps or stale payloads.
Whether missing data could affect interpretation.
The main output of Week 1 is not insight. It is data integrity.
Week 2 — Identify Early Metabolic Reactions
The second week focuses on early signal discovery.
At this stage, we merge behavioral data with glucose and wearable data to generate enriched reports:
Meal chains merged with glucose response.
Training chains merged with glucose stability and recovery.
Feeling chains merged with sleep, hunger, cravings, and outcomes.
The goal is to identify early candidate patterns. These are hypotheses, not conclusions.
For example, we may observe that a certain type of meal is followed by stronger hunger, or that a walk after eating appears to improve glucose stability. But in Week 2, these findings are still only early signals.
Week 3 — Detect Repeatable Patterns
The third week focuses on repetition.
We look across multiple days, contexts, and behaviors to see whether early signals repeat. A candidate pattern becomes more interesting if it appears several times and points in the same direction.
This stage includes:
Cross-day analysis.
Cross-context analysis.
Pattern frequency checks.
Pattern strength scoring.
Review of possible data quality issues.
Selection of the strongest candidates for validation.
The goal is to separate signal from noise.
Week 4 — Validate Patterns and Build Future Alert Ideas
The fourth week is about validation.
Selected candidate patterns are intentionally re-tested. We look for patterns that can be reproduced with multiple data points and are not explained by missing logs, sensor gaps, or one-off circumstances.
Only validated patterns can become future alert ideas.
For example, a future BitFitness alert might eventually say something like:
“Late high-carb dinner combined with poor sleep may increase next-morning hunger risk.”
But this type of alert can only be considered after the pattern is reproduced, documented, and translated into a non-CGM logic that can work for normal app users.
Week 1 Update — From Data Quality to First Candidate Patterns
Status: Completed
Dates covered: 6–13 June 2026
Pilot stage: Week 1 / Foundation and first candidate pattern discovery
Week 1 of the BitFitness Metabolic Research Pilot is now complete.
The first goal was not to make conclusions. The first goal was to confirm whether the research pipeline can reliably connect daily behavior, wearable data, Libre glucose data, hunger signals, recovery, training, and weight trends into useful analysis chains.
This is important because weak data can easily create false patterns. Before any recommendation model can improve, we need to know whether the underlying behavioral and physiological data can be trusted.
Week 1 focused on building the research pipeline: app exports, Libre data, Eating Episodes, training sessions, hunger timing, recovery, weight, and candidate pattern discovery.
What We Processed in Week 1
During Week 1, we combined several layers of evidence:
BitFitness app exports
Meal logs
Hunger events
Training logs
Daily feeling and recovery data
Weight entries
Libre glucose data
Apple Watch-based sleep, recovery, activity, and training context
Baseline participant context
One important improvement was the introduction of Eating Episodes.
Instead of treating every food row as a separate meal, food and drink entries logged close together are grouped into one Eating Episode for physiological analysis. This prevents misleading glucose-response calculations when a tester logs several items from the same meal separately.
We also separated behavioral-only data from CGM-covered data.
This matters because some valid behavior happened before the first Libre readings were available. Those events are still useful behavioral evidence, but they are not used for glucose-response calculations.
What Changed in the Analysis Method
Week 1 also helped us improve the research logic.
We now separate:
hunger before a meal,
hunger logged around the meal time,
and true post-meal hunger after a short buffer.
This is important because hunger logged almost at the same time as a meal does not necessarily mean the meal failed to provide satiety. It may simply mean the person was already hungry when they started eating.
We also improved training analysis.
Short workout fragments can now be grouped into training sessions, so the research looks at real training behavior instead of over-interpreting short workout fragments.
Repeated food, drink, or alcohol entries are also no longer treated as automatic duplicates. BitFitness allows users to copy logged items, so repeated entries may represent real quantity — for example, two copied glasses of wine may mean two glasses consumed.
Week 1 improved the research method: Eating Episodes, CGM coverage separation, hunger-at-meal-time detection, training session grouping, and repeated food rows interpreted as quantity rather than errors.
First Candidate Signals
Week 1 produced early candidate signals, but these are not validated patterns.
The most interesting early signal is related to satiety.
Some light, low-protein, or drink-like eating episodes appeared to be followed by shorter satiety or stronger hunger later. This does not mean those foods are “bad.” It means they may not always be enough to keep a person full in a specific context.
Another important finding is methodological: glucose response alone does not explain hunger well enough.
Some higher glucose responses were not followed by strong hunger, while some hunger-related episodes were not explained by glucose alone. This supports the core BitFitness research idea: future recommendations should be based on complete behavioral chains, not on glucose peaks alone.
A more useful chain may look like this:
Meal composition → satiety duration → hunger return → next eating behavior
or:
Sleep / recovery → hunger → food choices → training quality → weight trend
Glucose can help explain part of the chain, but it is not the main outcome.
Week 1 did not validate patterns, but it identified candidate chains to retest: short satiety after low-adequacy meals, meal-time hunger vs true post-meal hunger, training and post-workout hunger, alcohol and next-day recovery, and recovery as an interaction factor.
Week 1 Candidate Pattern Directions
The strongest Week 1 candidate directions are:
Short satiety after low-adequacy meals
Some light, low-protein, carb-forward, or drink-like eating episodes may be followed by faster hunger return.Meal-time hunger and post-meal hunger are different signals
Hunger logged near the meal time should not be treated the same as hunger that returns later.Meal adequacy may predict hunger better than glucose alone
Meal size, protein, fat, fiber, timing, and prior hunger may explain satiety better than glucose response alone.Training needs to be analyzed as sessions, not fragments
Post-workout hunger may depend on how well the person was fueled before training.Alcohol requires next-day chain analysis
Alcohol should be studied through sleep, recovery, hunger, cravings, food behavior, glucose context, and weight trend — not as a simple glucose event.Recovery may be an interaction factor
Recovery alone may not explain hunger, but recovery combined with meal timing, sleep, alcohol, or training may matter.
What Comes Next
Week 2 will focus on retesting these candidate patterns.
The goal is to see whether Week 1 signals repeat in similar contexts. If a signal repeats, it becomes more interesting. If it disappears or contradicts itself, it may be noise.
The next stage is not about finding more “glucose patterns.” It is about discovering which behavioral chains are reproducible enough to become useful future BitFitness recommendations for users who do not wear CGM sensors.
Week 1 built the foundation.
Week 2 has now tested the first candidate patterns against more data.
The research is moving from early signal discovery toward repeatability testing: which behavioral chains appear again, which become weaker, and which should be treated as noise.
Week 2 Update — Retesting Early Candidate Patterns
Status: Completed
Dates covered: 14–20 June 2026
Pilot stage: Week 2 / Candidate pattern retesting and method refinement
Week 2 of the BitFitness Metabolic Research Pilot is now complete.
The goal of Week 2 was not to prove final conclusions. The goal was to take the first candidate signals from Week 1 and test whether they still looked meaningful when more data was added.
This is an important step. Early signals can be exciting, but they can also be misleading. A single unusual day, a single glucose response, or one isolated hunger event is not enough to build a useful recommendation model. Week 2 helped us separate stronger candidate chains from weaker signals, possible noise, and likely false positives.
What We Processed in Week 2
Across two internal testers, Week 2 analysis included:
81 Eating Episodes
60 clean glucose-response eligible meal windows
21 contaminated glucose windows that required caution
23 training sessions
15 alcohol-chain candidates
14 daily feeling / recovery rows
14 true post-meal strong hunger signals after the 30-minute buffer
12 short-satiety signals under 120 minutes
The important point is not the size of the dataset alone. The important point is that each signal was interpreted as part of a behavioral chain.
For example:
Meal structure
→ satiety duration
→ hunger return
→ next eating behavior
or:
Training session
→ pre-workout fueling
→ post-workout hunger
→ next meal timing
or:
Alcohol episode
→ sleep / recovery
→ next-day appetite
→ food behavior
→ weight trend
Glucose data helped explain some possible mechanisms, but it was not treated as the main outcome.
What Became Stronger in Week 2
Week 2 strengthened several Week 1 candidate directions.
The strongest methodological finding was that meal-time hunger and true post-meal hunger must be separated.
If someone logs hunger around the same time as a meal, that does not automatically mean the meal failed to provide satiety. It may simply mean the person was already hungry when they started eating.
For this reason, BitFitness now separates:
hunger before a meal,
hunger around meal time,
and true post-meal hunger after a short buffer.
This helps prevent false conclusions and makes future recommendations more precise.
Meal Adequacy Looked More Useful Than Glucose Alone
Week 2 also strengthened an important product hypothesis:
Meal adequacy may explain hunger and satiety better than glucose response alone.
Some higher glucose responses were not followed by strong hunger. In other cases, hunger-related outcomes were better explained by meal size, protein, food form, timing, previous hunger, or training context.
This supports the core BitFitness direction:
The future recommendation model should not be built around glucose spikes alone.
A more useful model looks at complete behavioral chains:
Meal size
protein / carbs / fat balance
liquid vs solid food format
time since last meal
prior hunger
training context
→ satiety / hunger outcome
Glucose remains useful during research, but only as a mechanism layer.
Short Satiety Remains a Candidate Pattern
Week 1 suggested that some light, low-protein, drink-like, or low-adequacy meals may be followed by shorter satiety or stronger hunger later.
Week 2 partly strengthened this candidate pattern, especially for one tester.
However, the signal was not identical across both testers. This is exactly why the research must continue. The product goal is not to create one generic rule for everyone. The goal is to learn which patterns repeat for a specific user and under which conditions.
The Week 2 refinement is important:
Meal adequacy should not be reduced to protein alone.
A meal may need to be evaluated by:
total energy,
protein,
carbohydrate and fat balance,
whether it is liquid or solid,
whether it is mostly coffee, sweet, or snack-like,
time since the previous Eating Episode,
prior hunger,
and whether training happened before or after.
This makes the future model more personal and less simplistic.
Training and Post-Workout Hunger Need More Context
Week 2 also strengthened the idea that post-workout hunger should be analyzed at the training-session level, not from isolated workout fragments.
The emerging chain is:
Pre-workout fueling
→ training duration / load / type
→ delay to next adequate meal
→ post-workout hunger
→ later eating behavior
One important Week 2 refinement is that very immediate hunger after training may need a short transition buffer. Hunger logged within a few minutes of a workout ending may reflect timing overlap rather than a true post-workout appetite effect.
This will be tested more carefully in Week 3.
Alcohol Remains a Candidate Chain, Not a Conclusion
Week 2 included multiple alcohol-chain candidates across both testers.
But Week 2 did not prove a simple rule such as “alcohol causes next-day hunger.”
That would be too simplistic.
Instead, alcohol remains a candidate chain that must be tested through the full next-day context:
Alcohol
→ sleep
→ recovery
→ hunger / cravings
→ food behavior
→ weight trend
Repeated alcohol rows are also not treated as automatic duplicates. In BitFitness, copied rows may represent real quantity, such as multiple glasses.
The goal is to avoid overreacting to a single alcohol entry and instead look for repeatable personal patterns.
Recovery Looks Like an Interaction Factor
Week 2 also refined how we interpret recovery.
Recovery alone did not behave like a simple standalone predictor of hunger. Instead, recovery appears more useful as an interaction factor.
That means recovery may matter more when combined with:
poor sleep,
long gaps between meals,
low-adequacy meals,
alcohol,
training load,
or prior hunger.
This is important for product design. A future BitFitness recommendation should not simply say “low recovery means you will be hungry.” A better recommendation would consider the full context around the user’s day.
Glucose Quality Still Matters
Week 2 also identified a data-quality issue for one tester: low CGM readings require classification before interpretation.
Low readings may be meaningful in some cases, but they can also be related to sensor context, nighttime readings, or compression effects. For this reason, low CGM readings are treated as a quality-classification task before they are used as evidence.
This reinforces the broader principle of the pilot:
CGM can help explain mechanisms, but it does not define the final recommendation logic.
What Week 2 Did Not Prove
To keep the research honest, Week 2 did not validate any final pattern.
We are not claiming that:
one meal type is universally good or bad,
glucose response alone predicts hunger,
alcohol automatically causes next-day appetite changes,
protein alone prevents hunger,
recovery alone predicts food behavior,
or that one tester’s pattern applies to everyone.
Week 2 helped us improve the model logic, but it did not produce validated recommendations.
Candidate Pattern Status After Week 2
The current candidate pattern status is:
Short satiety after low-adequacy meals
Strengthened, but participant-specific. Needs more repeatability testing.Meal-time hunger and true post-meal hunger are different signals
Strongly strengthened. This is now a core analysis rule.Meal adequacy may predict hunger better than glucose alone
Strengthened. Glucose-only logic looks too weak for future alerts.Post-workout hunger depends on fueling and next-meal timing
Strengthened, but the model needs more context.Alcohol should be analyzed through next-day recovery and appetite chains
Still active, but evidence is insufficient for a directional conclusion.Recovery is an interaction factor
Strengthened. Recovery should not be used as a standalone appetite predictor.Low CGM readings require quality classification
Strengthened for one tester. These readings must be classified before interpretation.
What Comes Next in Week 3
Week 3 will focus on repeatability.
The main question is no longer:
“Can we find interesting signals?”
The better question is:
“Which signals repeat often enough, in similar contexts, to become useful product logic?”
Week 3 will focus on:
retesting the same candidate patterns,
building a stronger meal adequacy model,
checking whether hunger patterns repeat across days,
improving post-workout hunger logic,
testing alcohol only as a full next-day chain,
treating recovery as an interaction factor,
classifying low CGM readings before interpretation,
and identifying which signals may be noise or false positives.
The strongest future BitFitness recommendations will likely come from behavioral chains that can be detected without CGM.
That is the long-term product goal:
Use temporary CGM research to build better non-CGM recommendations for everyday users.
Week 3 Update — Separating Repeatable Signals From Noise
Status: Completed
Dates covered: 21–27 June 2026
Pilot stage: Week 3 / Repeatability testing and false-positive filtering
Week 3 of the BitFitness Metabolic Research Pilot is now complete.
The goal of Week 3 was not to create final conclusions. The goal was to test whether the candidate patterns from Week 1 and Week 2 repeated when more data was added, and to identify which signals looked stronger, weaker, participant-specific, or likely to be noise.
This is an important stage in product research. A recommendation engine should not react to one unusual meal, one glucose spike, one workout, or one bad night of sleep. It should learn which behavioral chains repeat in a similar direction and which signals should be ignored because they are too weak, too context-dependent, or caused by data quality issues.
What We Processed in Week 3
Across two internal testers, Week 3 analysis included:
* 72 Eating Episodes
* 54 clean glucose-response eligible meal windows
* 17 contaminated glucose windows that required caution
* 23 training sessions
* 13 alcohol-chain candidates
* 14 daily feeling / recovery rows
* 15 true post-meal strong hunger signals after the 30-minute buffer
* 6 short-satiety signals under 120 minutes
As in earlier weeks, the important point is not just the dataset size. The important point is how each signal was interpreted.
BitFitness continued to analyze complete behavioral chains:
Meal structure
→ satiety duration
→ hunger return
→ next eating behavior
Training session
→ pre-workout fueling
→ post-workout hunger
→ next meal timing
Alcohol episode
→ sleep / recovery
→ next-day hunger or cravings
→ food behavior
→ weight trend
Glucose data was used only as a mechanism layer. It helped explain what may have happened physiologically, but it did not define the pattern by itself.
Week 3 Strengthened One Core Research Rule
The strongest Week 3 finding was methodological:
Meal-time hunger and true post-meal hunger must remain separate.
If someone logs hunger around the same time as a meal, that does not automatically mean the meal failed. It may simply mean the person was already hungry when they started eating.
For this reason, BitFitness separates:
* hunger before a meal,
* hunger around meal time,
* and true post-meal hunger after a short buffer.
In Week 3, this separation helped prevent false conclusions. Some hunger signals happened close to meal timing and needed to be treated as context, not as failed satiety. This improves the quality of future recommendation logic because it reduces the risk of blaming the wrong meal.
Short Satiety Became More Clearly Personal
Week 1 and Week 2 suggested that some light, low-protein, drink-like, carb-forward, or low-adequacy eating episodes may be followed by shorter satiety or stronger hunger later.
Week 3 made this signal more precise.
For one tester, the pattern became stronger. Several lighter or lower-adequacy episodes were followed by true post-meal strong hunger or shorter satiety. This suggests that meal adequacy may matter for that person’s hunger control.
For the second tester, the same universal rule did not hold. During Week 3, this tester had no true post-meal strong hunger after the 30-minute buffer and no short-satiety signals under 120 minutes.
This is one of the most useful findings so far.
It shows why BitFitness should not build generic food rules. A meal pattern that appears risky for one person may not create the same outcome for another person. The product goal is not to say “this food is good” or “this food is bad.” The product goal is to learn which meal structures work for a specific user, in a specific context.
Meal Adequacy Still Looks More Useful Than Glucose Alone
Week 3 also strengthened an important product direction:
Glucose response alone is not enough to predict hunger.
Some higher glucose-response episodes were not followed by true post-meal strong hunger. In other cases, hunger appeared to be better explained by meal size, food form, timing, prior hunger, training context, or next meal timing.
This supports the broader BitFitness model:
A better recommendation should look at the full chain, not only at glucose.
A more useful model may consider:
* total meal adequacy,
* protein, carbohydrate, and fat balance,
* whether the meal is solid, drink-like, sweet, or snack-like,
* time since the previous meal,
* prior hunger,
* recent or upcoming training,
* sleep and recovery context,
* and delay to the next adequate meal.
Glucose remains useful during research, but it should not become the main product dependency.
Training and Post-Workout Hunger Need Timing Context
Week 3 also improved the post-workout hunger model.
The research continues to show that training should be analyzed as real training sessions, not as isolated workout fragments. Very short workout fragments can create misleading signals if they are overinterpreted.
For one tester, post-workout hunger appeared often enough to remain an active candidate pattern. But the signal still needs context.
The emerging chain is:
Pre-workout fueling
→ training duration / load / type
→ short transition buffer after workout
→ delay to next adequate meal
→ post-workout hunger
→ later eating behavior
One important refinement is the post-workout transition buffer. Hunger logged immediately after a workout may reflect timing overlap rather than a true post-workout appetite effect. Week 4 will test this more carefully by using a 10–15 minute buffer after workout end.
Alcohol Still Needs Full Next-Day Chain Analysis
Week 3 included several alcohol-chain candidates, but it did not prove a simple rule such as “alcohol causes hunger.”
That would be too simplistic.
Alcohol remains an active candidate only when analyzed through the full next-day chain:
Alcohol
→ sleep
→ recovery
→ hunger / cravings
→ food behavior
→ weight trend
This matters because alcohol may affect behavior indirectly. The product should not overreact to a single alcohol entry. It should look for repeatable personal patterns involving sleep quality, recovery, cravings, food choices, and next-day outcomes.
Repeated alcohol rows were also treated as logged quantity, not automatic duplicates. In BitFitness, users may copy food or drink entries, so repeated rows may represent multiple servings.
Recovery Looks Like Context, Not a Standalone Trigger
Week 3 supported another Week 2 refinement:
Recovery alone should not be treated as a simple appetite predictor.
A low recovery score by itself is not enough to say that hunger or cravings will increase. Recovery may become useful when it interacts with other factors, such as:
* poor sleep,
* low-adequacy meals,
* long gaps between meals,
* alcohol,
* training load,
* or prior hunger.
This is important for future alert design. BitFitness should not say something simplistic like “low recovery means you will be hungry.” A better recommendation would consider what else is happening in the user’s day.
Glucose Quality Remains Important
Week 3 also reinforced the importance of data quality.
One tester had many low CGM readings below the internal research threshold. These readings cannot be interpreted automatically. They may be related to nighttime readings, sensor context, compression effects, or other data-quality issues.
For this reason, low CGM readings are treated as a classification task before they are used as evidence.
This reinforces the core principle of the pilot:
CGM helps us understand mechanisms during research, but it does not define the final recommendation logic.
What Week 3 Did Not Prove
To keep the research honest, Week 3 did not validate any final pattern.
We are not claiming that:
* low-adequacy meals always cause short satiety,
* glucose response alone predicts hunger,
* alcohol automatically causes next-day appetite changes,
* protein alone prevents hunger,
* recovery alone predicts food behavior,
* or one tester’s pattern applies to everyone.
Week 3 helped us improve the model logic, but it did not produce final user-facing recommendations.
Candidate Pattern Status After Week 3
The current candidate pattern status is:
1. Short satiety after low-adequacy meals
Strengthened for one tester, but not universal. This remains a personalized candidate pattern.
2. Meal-time hunger and true post-meal hunger are different signals
Strongly strengthened again. This is now one of the most important analysis rules.
3. Meal adequacy may predict hunger better than glucose alone
Strengthened. Glucose-only hunger prediction looks too weak for future alerts.
4. Post-workout hunger depends on fueling and next-meal timing
Strengthened for one tester, but it needs session-level analysis, a transition buffer, and next-meal context.
5. Alcohol should be analyzed through next-day recovery and appetite chains
Still active, but evidence is insufficient for a directional conclusion.
6. Recovery is an interaction factor
Strengthened. Recovery should not be used as a standalone appetite predictor.
7. Low CGM readings require quality classification
Strengthened as an internal data-quality rule for one tester.
What Comes Next in Week 4
Week 4 will focus on validation.
The main question is no longer:
“Can we find interesting signals?”
The better question is:
“Which signals are reproducible enough to become safe, useful, and personalized recommendation logic?”
Week 4 will focus on:
* validating meal-time hunger separation,
* testing personalized meal adequacy models,
* comparing behavioral meal context against glucose-only prediction,
* improving post-workout hunger logic with a transition buffer,
* analyzing alcohol only as a full next-day chain,
* treating recovery only as interaction context,
* classifying low CGM readings before interpretation,
* and deciding which signals should move toward validation, rejection, or future alert design.
The strongest future BitFitness recommendations will likely come from behavioral chains that can be detected without CGM.
That remains the long-term product goal:
Use temporary CGM research to build better non-CGM recommendations for everyday users.
What We Will Not Claim
To keep the research honest, we will not overstate what this pilot can prove.
We will not claim that:
BitFitness diagnoses medical conditions.
BitFitness replaces a doctor, dietitian, or medical device.
CGM is required to use BitFitness.
One glucose response proves whether a meal is “good” or “bad.”
A single tester result applies to everyone.
A candidate pattern is valid before it is reproduced.
Missing data means an event did not happen.
Estimated scores are the same as measured physiological data.
This pilot is about careful product learning. Trust comes from being transparent about both findings and limitations.
Data Quality Principles
High-quality recommendations require high-quality data.
Throughout the pilot, we track possible issues such as:
Missing meal logs.
Missing hunger or craving logs.
Missing weight entries.
Libre sensor gaps.
Apple Watch sleep gaps.
Sync issues.
Partial-day glucose coverage.
Stale data payloads.
Day-level mismatch between app data and sensor data.
Unclear timing between meals, workouts, and symptoms.
If data exists but freshness or quality is uncertain, we classify it as requiring verification rather than calling it missing.
This prevents false conclusions and helps us avoid building recommendations on weak evidence.
Privacy and Participant Protection
The pilot uses data from internal testers only.
Public updates will not disclose private medical details, personal identities, or raw sensitive datasets. Photos may show sensors or anonymized tester context, but the article will focus on methodology, product learning, and aggregated insights.
The purpose of the pilot is to improve the quality of BitFitness recommendations while respecting participant privacy and data confidentiality.
Important Disclaimer
This is a BitFitness product research pilot, not a medical study, clinical trial, diagnostic tool, diabetes application, or treatment program.
BitFitness is not using this pilot to diagnose, treat, prevent, or manage any medical condition. The glucose sensors used during the pilot are research tools that help us observe how behavior may influence glucose response, hunger, energy, recovery, training, and weight trends.
The final BitFitness product is designed to work without requiring CGM data. CGM is used only during this pilot to better understand physiological mechanisms behind behavioral patterns.
All observations shared in this article are preliminary, educational, and product-development focused. They should not be interpreted as medical advice. Users should not change medication, diet, or treatment plans based on this article and should consult a qualified healthcare professional for medical questions.