AI Nutrition & Ingredient Intelligence: Built From Care, Guided by Evidence
A personal project born from caring about the food we eat and the well-being of someone I love. I used conversational AI, thoughtful data engineering, and machine learning to turn everyday observations into better questions for healthcare conversations.
Why I built this: Food should nourish us, bring us joy, and support the people we care about. This project began with a personal goal: helping my wife better understand how meals, ingredients, daily routines, and other experiences might relate to how she feels. We care about ingredient quality and thoughtful food preparation, but even with that attention, it can be difficult to see meaningful patterns across everyday life.
The problem: Food, sleep, activity, and symptoms do not arrive as neat rows in a database. Details get forgotten, observations may be recorded in different places, and several things can change at once. By the time someone sits down with a healthcare professional, weeks of lived experience can be difficult to summarize.
What I built: I created an AI-powered nutrition and life-event intelligence platform that uses conversational logging, clarification before data entry, structured event validation, dbt and BigQuery transformations, and exploratory machine learning. Its purpose is to organize observations and surface questions worth discussing with a qualified professional, not to diagnose conditions or assign causes to individual ingredients.
Why Food, and Why This Project Matters to Me
I have spent my career helping organizations turn complex information into better decisions. That work is deeply important to me, but it was not the reason this project began.
It began at home. I wanted to help someone I love understand her relationship with food and everyday well-being, without making the act of tracking meals and daily experiences another burden. Food is personal. It is part of how we care for ourselves and for one another, and the ingredients and preparation behind a meal matter to me beyond any dashboard or statistical model.
I could bring my analytics experience to that challenge, but I also had to respect what the data could not tell us. The goal was not to turn uncertainty into false confidence. It was to capture observations with greater care, recognize patterns responsibly, and make conversations with healthcare professionals more useful.
The technology is the means. Better understanding and better care are the reason I built it.
12/12 test specs and 410/410 SQLite window parity) measure deterministic software contracts, state transitions, and SQL math on synthetic fixtures - they do not claim clinical efficacy or comprehensive production outcome validation.| Capability Layer | Built in Private Application | Verified in Public Synthetic Suite | Why It Matters for Everyday Use & Review |
|---|---|---|---|
| Omni-Channel Multimodal Capture | Telegram Bot API (text, voice memos, plate photos, barcodes) + React 19 / Firebase Hosting | Runnable offline React 19 workbench + simulated webhook/barcode adapters | Supports quick, conversational capture where users already communicate, designed to reduce repetitive form entry. |
| 3-Stage Gemini Gatekeeper | Live Gemini (T=0.1) router -> T=0.0 JSON extractor -> FatSecret OAuth 2.0 + additive rules | Shared Zod schemas, dietaryRules.js, and state-machine hold specs (0 partial rows persisted in synthetic tests) | Asks one concise follow-up when missing prep, gluten, or dressing context would corrupt downstream ingredient flags. |
| dbt + BigQuery ML Trend Engine | Firestore-to-BigQuery export + dbt Bronze -> Silver -> Gold + BQML XGBoost & ARIMA_PLUS | Sanitized dbt/BQML SQL + deterministic 410/410 row parity against in-memory node:sqlite window SQL | Verifies that operational schemas and rolling 24h/48h lag windows compute identically without temporal leakage. |
| Uncertainty-Aware Guardrails | Chronological splits, uncertainty bounds, collinearity checks + live Semantic Scholar MeSH lookup | Chronological 75/25 holdout, Haldane intervals, abs(r) >= 0.35 warnings + documented offline literature boundary | Frames exploratory model outputs as non-causal questions to review with a clinician, never as automated diagnoses. |
1. Why Is It So Hard to Understand the Relationship Between Food and How We Feel?
For someone preparing to discuss recurring symptoms or changes in well-being with a clinician, three practical challenges stand out:
- Logging takes effort: Traditional forms can ask for so much detail that consistent tracking becomes difficult. A useful product must reduce that friction without losing important context.
- Details are easy to miss: A note such as “I had pasta and salad” may leave out ingredients, dressing, preparation, or timing. When those details matter to the question being investigated, the system should ask a concise follow-up instead of silently guessing.
- Observations are not explanations: A symptom, an ingredient, and a change in sleep may occur near one another without one causing the other. A timeline helps organize the discussion, but interpretation requires attention to timing, repeated observations, alternative explanations, and uncertainty.
I built the platform to make those observations easier to capture and more useful to review, not to replace clinical reasoning.
2. How Does the Platform Bring Food and Daily Life Together for More Useful Conversations?
Meals, Prep & Hidden Additives
Decomposes barcodes, photos, and text into FODMAP polyols, gums, emulsifiers, raw-vs-cooked preparation, gluten checks, and hydration notes.
Activity & Recovery Timing
Records strength training intensity, post-meal walks, and post-dinner recovery spacing intervals alongside meal timestamps.
Sleep Continuity & Daily Stress
Captures bedtime, wake interruptions, daily stressors, and midday energy or clarity notes so food logs are reviewed in context.
Supplements, Regimen & Context
Tracks daily supplement or regimen schedules, chewable or liquid excipient flags, and longitudinal lab context for discussion.
Symptoms & Organized Questions
Summarizes discomfort scores (0-10), motility notes, modeled baseline intervals, exploratory associations, and literature references.
The Decisions Behind the Platform
Building the application meant making tradeoffs between ease of use, data reliability, analytical usefulness, and responsible interpretation. These are the decisions that shaped the product.
| Decision | Approach I chose | Why it matters |
|---|---|---|
| Make logging feel natural | Support conversational text, voice, images, and barcode-assisted inputs | People should not have to become data-entry specialists to record their experiences. |
| Ask before assuming | Use an ambiguity gate and structured clarification when key context is missing | Incomplete or guessed records can undermine downstream analysis. |
| Preserve timing and context | Model food, activity, sleep, regimens, and symptoms along a shared timeline | Relationships worth investigating may depend on when observations occurred. |
| Treat predictions as hypotheses | Include time-aware evaluation, uncertainty, and checks for correlated features | Model importance is not evidence that an ingredient caused an outcome. |
| Protect private information | Keep the real system private and publish a separate synthetic demonstration | Technical proof should never require exposing a household's personal records. |
| Keep a human in the loop | Prepare organized summaries and questions for qualified professionals | The product should inform conversations, not automate medical conclusions. |
These choices reflect how I approach complex problems more generally: start with the person affected, improve the quality of the evidence, challenge what a model appears to say, and only then consider what decision the evidence supports.
3. What full-stack technologies and external APIs power the end-to-end architecture?
| Architecture Layer | Connected Stack & APIs | Production Role | Sanitized Public Repo Adapter |
|---|---|---|---|
| Omni-Channel Client & Messaging | Telegram Bot API, React 19, Vite, Tailwind CSS v4 | Supports quick, conversational capture via text, voice notes, meal photos, and barcodes plus a web timeline and regimen UI | Interactive React 19 SPA (src/ui/App.jsx) with multi-turn preset and live simulation |
| Serverless Cloud & Multi-Tenancy | Firebase Auth, Cloud Firestore, Cloud Functions (Node.js) | Maps authenticated Telegram IDs to Firebase UIDs, holds ephemeral telegram_sessions state, and streams validated logs | Tenant-isolated session store throwing TenantIsolationError on cross-tenant access |
| Multi-Agent LLM Orchestration | Google Gemini GenAI, Zod v4 Contracts | Stage 1 Gatekeeper completeness router (T=0.1) -> Stage 2 strict nested JSON extraction (T=0.0) | MockGeminiOrchestrator + shared CanonicalNutritionEventSchema invariants |
| Nutrition & Additive Intelligence | FatSecret Platform API (OAuth 2.0), Additive Lexicon | Resolves GTIN-13 barcodes, plate images, and food queries into raw ingredients checked against dietary and additive rules | MockNutritionCatalogAdapter + deterministic dietaryRules.js (FDA and Monash rules) |
| Warehouse ELT & In-DB ML | dbt Core, Google BigQuery, BQML (XGBoost & ARIMA_PLUS) | Transforms Firestore exports through Bronze -> Silver -> Gold 24h/48h lag windows; computes exploratory attribution and modeled baseline bands | Sanitized dbt SQL + 410/410 synthetic fixture row parity against node:sqlite + chronological stumps |
| Literature Retrieval Boundary | Semantic Scholar Graph API, Gemini MeSH Builder | Formulates Medical Subject Heading (MeSH) queries from recurring patterns to retrieve peer-reviewed papers for clinician discussions | Documented offline contract (LiteratureSynthesisInterface) - never fabricates mock clinical citations |
4. What This Personal Project Taught Me About Building Useful AI Products
Design Tradeoffs: Conventional Tracking, Unchecked AI, and a Governed Approach
| Dimension | Rigid Form-Based Trackers | Naive Single-Prompt AI Chatbots | Governed Gatekeeper + BigQuery ML Approach |
|---|---|---|---|
| Daily Logging UX | 8-15 manual dropdowns per meal or workout; tedious to sustain | Accepts vague notes without checking whether key context is missing | Conversational voice, photo, barcode, or text; asks 1 follow-up only when missing context matters |
| Multi-Stream Context | Siloed calorie counters | Drops sleep, activity timing, and supplement excipients | Organizes additives, sleep, activity, recovery spacing, and regimens along shared 24h/48h windows |
| Conversation Output | Pages of raw logs that are hard to summarize quickly | Overconfident AI guesses without statistical bounds | Exploratory summaries with modeled baseline intervals, collinearity warnings, and literature links |
Where These Engineering Patterns Can Apply Beyond Nutrition
Although the project was developed for a personal purpose, several design patterns are transferable: conversational clarification when context is missing, structured validation before writing events, consistent data contracts, time-aware feature modeling, and explicit uncertainty in analytical outputs. These patterns may be useful in customer support, operational intake, and internal analytics workflows, subject to each domain's requirements and appropriate review.
1. Customer support and warranty intake
Ask for missing product, environmental, or timing details before creating records used for troubleshooting.
2. Operational event collection
Validate fields and preserve event context before those records enter warehouse reporting and analysis.
3. Internal analytics requests
Clarify ambiguous business questions, required dimensions, and success criteria before generating analysis specifications.
Do not deploy stateful LLM gating for simple 3-button deterministic check-ins, one-off <100-row surveys, or autonomous clinical diagnosis and prescribing where licensed clinical evaluation is mandatory.
5. How Do the Gemini Gatekeeper, Zod Contracts, and Data Models Improve Reliability?
Resolved food entries check ingredient lists against deterministic rules grounded in U.S. FDA Food Additive classifications and Monash University FODMAP polyol standards, while warehouse feature tables use BigQuery RANGE windows in dbt Core ending at 1 PRECEDING.
export const CanonicalNutritionEventSchema = z
.object({
event_id: z.string().min(6),
tenant_id: TenantIdSchema,
event_timestamp: IsoUtcTimestampSchema, // Strict ISO-8601 UTC ending in 'Z'
ingested_at: IsoUtcTimestampSchema,
source_channel: z.enum(['web_console', 'messaging_webhook', 'synthetic_seed']),
input_modality: z.enum(['text', 'voice_transcript', 'image_vision', 'barcode_gtin']),
category: z.enum(['food', 'symptom', 'supplement', 'context']),
raw_input_redacted: z.string().min(1).max(500),
food_metadata: FoodMetadataSchema.nullable().default(null),
symptom_metadata: SymptomMetadataSchema.nullable().default(null),
supplement_metadata: SupplementMetadataSchema.nullable().default(null),
context_metadata: ContextMetadataSchema.nullable().default(null) // Sleep, exercise, recovery & stress
})
.superRefine((val, ctx) => {
if (val.category === 'food' && !val.food_metadata) {
ctx.addIssue({ code: 'custom', message: 'food events require food_metadata', path: ['food_metadata'] });
}
if (val.category === 'symptom' && !val.symptom_metadata) {
ctx.addIssue({ code: 'custom', message: 'symptom events require symptom_metadata', path: ['symptom_metadata'] });
}
});SELECT
event_id,
tenant_id,
event_timestamp,
COALESCE(SUM(has_high_fodmap_polyol) OVER w24, 0) AS prior_polyol_24h,
COALESCE(SUM(has_hydrocolloid_gum) OVER w24, 0) AS prior_gum_24h,
COALESCE(SUM(has_emulsifier_irritant) OVER w24, 0) AS prior_emulsifier_24h,
COALESCE(SUM(has_high_fodmap_polyol) OVER w48, 0) AS prior_polyol_48h,
is_elevated_discomfort
FROM {{ ref('int_events_flattened') }}
WINDOW
w24 AS (
PARTITION BY tenant_id
ORDER BY event_epoch_sec ASC
RANGE BETWEEN 86400 PRECEDING AND 1 PRECEDING
),
w48 AS (
PARTITION BY tenant_id
ORDER BY event_epoch_sec ASC
RANGE BETWEEN 172800 PRECEDING AND 1 PRECEDING
);
6. How does machine learning highlight trends for doctor visits without making false causal claims?
abs(r) >= 0.35 collinearity alerts organizes messy history into qualified questions for a clinician rather than overconfident single-ingredient claims.What the Models Can Show - and What They Cannot
In a 60-day synthetic demonstration, two ingredient categories are intentionally constructed to appear together. A boosted-tree model may assign most of the importance to one feature while assigning little to the other, even though the observed exposure patterns overlap. The synthetic example reports a risk ratio of 7.29x and feature attribution values of 85.3% and 0.0%. These figures demonstrate the interpretation problem within the synthetic dataset; they are not estimates of an ingredient's effects on a real person. The responsible output is a warning about correlated exposures and questions for further review.
Plotting daily symptom scores against a model-derived 95% prediction interval (ARIMA_PLUS / rolling 7-day band) in the synthetic dataset helps distinguish ordinary day-to-day fluctuation from periods that differ from the modeled baseline.
Auditing the private prototype caught an actual implementation bug where nested Gemini arrays (food_metadata.ingredients[].tags) had evolved ahead of legacy flat SQL paths, resolved by enforcing shared Zod contracts and automated node:sqlite parity assertions (410/410 rows in the synthetic test fixture).
In the private system, recurring patterns formulate MeSH queries against the Semantic Scholar Graph API so users can review peer-reviewed papers with a clinician. In the offline public repo, LiteratureSynthesisInterface is documented as an explicit interface rather than mocking simulated medical studies.
A useful model should make its limitations visible. Prediction and feature importance can help prioritize questions, but they do not establish causality. I would rather present a qualified finding that invites careful investigation than an impressive number that implies more certainty than the evidence supports.
How I Would Evaluate Whether This Product Actually Helps
Building sophisticated technology is not the same as creating something useful. I would evaluate the platform on whether it makes daily tracking easier, produces more reliable observations, communicates uncertainty honestly, and helps someone prepare a clearer account of their experiences. The measures below are an evaluation framework, not claims of achieved outcomes.
| Evaluation area | Candidate measure | Why it matters |
|---|---|---|
| Ease of use | Time to complete a log; clarification completion rate | Tests whether conversational input actually reduces friction. |
| Sustained use | Repeat logging frequency and retention over time | Tests whether the experience remains practical beyond the first few days. |
| Input quality | Percentage of records passing schemas; missing-context rate; corrected-entry rate | Separates easy capture from analytically trustworthy capture. |
| Analytical reliability | Chronological holdout performance, baseline comparison, model drift, sample-size coverage | Tests whether models add value over simple summaries. |
| Interpretation quality | Correlation warnings, uncertainty display, limitations communicated | Helps guard against overconfident or causal readings. |
| Human usefulness | User review of summaries and whether they make appointment preparation clearer | Tests whether the product serves its original purpose. |
This is the standard I try to apply to analytical products generally: define what success would mean before celebrating the technology, validate the evidence, and keep the person using the output at the center of the decision.
7. Frequently Asked Technical & Product Questions
How is this platform meant to be used alongside a physician or dietitian?
Instead of scrolling through weeks of raw meal notes during a short visit, a user can share an organized summary showing modeled baseline variation, recurring dietary and daily-life associations (with sample sizes and uncertainty bounds), correlated-ingredient warnings, and literature references.
Does the public showcase contain any real personal health data?
Zero. The public repository was built in a separate directory with no private Git history, no API keys, and 410 deterministic synthetic events verified by automated secret and PNG-metadata checks.
How can engineering reviewers run the demonstration locally?
Clone rudy0903/dbmarketer, navigate to ai-nutrition-intelligence/, run npm install, and execute npm test (12/12 automated node:test specs) and npm run dev offline.
Explore the Project or Start a Conversation
This project began as a personal effort to bring more care and clarity to everyday food and wellness questions, and it reflects how I lead applied AI, product analytics, governed data modeling, and evidence-based decision systems end to end. If you want to inspect the implementation directly, the public repository includes a runnable, zero-credential synthetic demonstration. If you are hiring for analytical leadership or building an applied AI, product analytics, or decision-support capability in your organization, I welcome the conversation.
Start an Applied Analytics or AI Conversation
Inquire about applied AI workflows, product and longitudinal analytics, and evidence-based decision systems - as well as governed dbt/BigQuery architectures, telemetry audits, or principal advisory.
Edition: Canonical Case Study Showcase (November 2026)
Synthetic Verification Scope: The 410/410 SQLite parity checks and 12/12 automated node:test specs validate schema contracts, conversational ambiguity holds, tenant isolation, and rolling SQL window logic on deterministic synthetic fixtures (seed = 20261114). They verify software and analytical logic in the offline showcase and do not establish clinical effectiveness or live production outcome validation.
License: Database Marketer Source-Available Portfolio & Evaluation License (free to view, clone, test, and run locally for hiring and internal technical evaluation; commercial production use reserved).