CulinAI

The Problem with Traditional Meal Planning

• Static plans ignore reality — schedule changes, cravings shift, pantry runs out
• Decision fatigue peaks when you're hungry and tired — exactly when apps abandon you
• Scrolling through DoorDash/Uber Eats wastes 15+ minutes comparing options
• Macro tracking requires mental math across scattered nutrition databases
• No unified system decides whether you should order OR cook based on your constraints

CulinAI's Core Innovation

A real-time decision engine that learns your preferences, understands your constraints, and makes one optimized choice instantly: Order from a specific restaurant OR cook a specific recipe. No scrolling. No planning. Just eating.

Data Sources & Integration Strategy

• USDA FoodData Central — 400K+ foods with comprehensive macro/micronutrient profiles
• Recipe datasets (Spoonacular, Edamam APIs) — 2M+ recipes with ingredient lists, prep times, cooking instructions
• Restaurant menu data (OpenMenu API + custom scrapers) — real-time menu items from DoorDash, Uber Eats, Grubhub with macro estimates
• Patient diet logs — personalized eating history: meals eaten, times, ratings, macro adherence
• Clinical nutrition papers (PubMed embeddings) — evidence-based dietary guidelines for chronic conditions

Ingestion Pipeline Architecture

• Python ETL pipelines with per-source adapters — normalized schema across all data formats
• Schema validation + data cleaning: deduplication, unit conversion (cups → grams), outlier removal
• Incremental updates via cron jobs — restaurant menus refresh daily, USDA quarterly, recipes weekly
• Change detection logic preserves historical data while surfacing new items

Storage Stack

• Postgres (Supabase) — structured data with Row Level Security for HIPAA compliance
• QDrant vector DB — semantic embeddings across all nutrition layers with namespace isolation
• AWS S3 — raw data archives, recipe images, and document snapshots for debugging
• Redis — hot cache for frequently accessed nutrition profiles and menu items

Layer 1 — Nutrition Database Search

• Semantic query against USDA + recipe + restaurant menu embeddings in QDrant
• Hard constraints filter: allergies (e.g., exclude shellfish), macro limits (e.g., <30g carbs), budget ceiling
• Soft ranking: taste preference embeddings upweight preferred cuisines/ingredients
• Returns: 50 macro-matched candidates (recipes or restaurant dishes) sorted by semantic relevance

Layer 2 — Personal History Filter

• Re-rank Layer 1 candidates using patient-specific signals: past meal ratings, recent eating patterns, macro adherence trends
• Variety enforcement: penalize foods eaten in last 3 days to prevent repetition fatigue
• Time-of-day alignment: breakfast foods prioritized in AM, heavier meals in PM
• Returns: Top 15 personalized candidates that fit both nutritional needs and behavioral patterns

Layer 3 — Research Evidence Augmentation

• For patients with dietary goals (e.g., diabetes management, weight loss), retrieve relevant clinical guidelines from PubMed embeddings
• Evidence snippets injected into LLM context to justify recommendations (e.g., 'High-fiber legumes improve glycemic control per Smith et al. 2023')
• Used for patient education, not filtering — all Layer 2 candidates pass through

LLM Synthesis & Final Ranking

• GPT-4 receives: user query, top 15 candidates with full nutritional profiles, patient context, research evidence
• Task: rank candidates 1-5 with reasoning, select absolute best match
• Custom prompt engineering: emphasizes constraint satisfaction > novelty, clear rationale for top choice
• Output: Single recommended meal with macro breakdown and preparation/ordering instructions

Why This Architecture Works

Separating retrieval into layers prevents information overload in the LLM context window. Early filtering (Layer 1) handles hard constraints cheaply, Layer 2 applies personalization at scale, and only the top candidates reach expensive GPT-4 reasoning. This design achieves <3s P95 latency even with 2M+ recipe corpus.

Input Signals

• Macro targets — remaining calories, protein, carbs, fat for the day
• Time constraint — 'need food in 20 minutes' vs 'have an hour to cook'
• Budget — meal budget ceiling from weekly spending plan
• Location — nearby restaurants within delivery radius (Google Places API)
• Pantry inventory — what's available to cook with (user-maintained or smart-scanned via receipt OCR)
• Taste preferences — cuisine embeddings learned from meal rating history

Decision Logic: Order OR Cook

• Step 1: Retrieve top recipes and restaurant dishes from RAG engine (separate queries for each pathway)
• Step 2: Score each pathway on: time-to-eat (delivery ETA vs cook time), cost (restaurant price vs grocery cost), macro fit (exact target vs estimate), taste likelihood (preference score)
• Step 3: Binary decision via weighted optimization: if time is critical → bias toward fastest option, if budget tight → bias toward cooking, if pantry sparse → bias toward ordering
• Step 4: Surface winner with full action plan

Output Formats

• Order Pathway → specific restaurant name, dish recommendation, macro estimate, delivery ETA, total cost, one-click order link (DoorDash deep link)
• Cook Pathway → recipe with ingredients, auto-generated grocery cart (Instacart API integration), prep time, cooking instructions, exact macro calculation per serving
• Reasoning summary — 'Recommended cooking because you have 45 minutes and [chicken, rice, broccoli] in pantry. Ordering would cost $18 vs $6 to cook.'

Performance

• <3s P95 latency end-to-end (includes dual RAG queries, restaurant search, decision scoring, response formatting)
• Auto-scaling FastAPI workers handle meal-time traffic spikes (12pm and 6pm peaks)
• Cache hit rate: 65% for restaurant menus (Redis TTL 24h), 42% for recipe recommendations (user-specific cache)

Restaurant & Delivery Integrations

• OpenMenu API — structured menu data for 50K+ US restaurants
• DoorDash, Uber Eats, Grubhub (custom scrapers + unofficial APIs) — real-time menu availability, pricing, delivery times
• Deep links — one-click handoff from CulinAI recommendation to pre-filled cart in delivery app
• Google Places API — location-based restaurant discovery within user's delivery radius

Grocery & Recipe Integrations

• Instacart API — auto-generated grocery cart with exact ingredients from recommended recipe
• Spoonacular & Edamam — recipe databases with normalized ingredient lists and instructions
• USDA FoodData Central — ground-truth macro calculations for every ingredient
• Receipt OCR (experimental) — scan grocery receipts to auto-update pantry inventory

Nutrition Tracking Integrations

• MyFitnessPal import — sync existing macro targets and meal history
• Apple Health & Google Fit — pull activity data to adjust calorie targets dynamically
• Two-way sync: CulinAI logs meals back to tracking apps automatically after confirmation

Clinical Integrations (UCSD Pilot)

• EHR API (Epic FHIR) — read patient dietary restrictions, allergies, chronic conditions
• Nutritionist dashboard — clinicians can review patient meal decisions and override recommendations
• HIPAA-compliant audit logs — every recommendation stored with reasoning for clinical review

Signal Collection

• Acceptance rate — did user follow the recommendation (binary yes/no)
• Macro deviation — actual macros logged vs recommended (from tracking app sync)
• Explicit feedback — 1-5 star rating + optional text comment
• Time-to-eat — minutes from recommendation to meal log (proxy for decision confidence)
• Substitutions — if user modified recipe or ordered different dish, what changed

Weekly Retraining Pipeline

• Aggregate signals per user and across cohort (200+ patients)
• Accepted meals → increase embedding similarity weight for those ingredients/cuisines
• Rejected meals → decrease ranking score for similar patterns
• High macro deviation → flag data source inaccuracies (e.g., restaurant menu estimate was off)
• Update QDrant preference embeddings and retrain ranking layer (LightGBM model)

Result

Recommendation accuracy improved 22% vs baseline GPT-4 after 6 months of pilot operation. Acceptance rate increased from 58% in month 1 to 74% in month 6. System learns both individual preferences and cohort patterns (e.g., Tuesday night cravings, post-workout meal timing).

Service Architecture

• FastAPI backend — async request handling with Uvicorn workers, auto-scaling based on CPU/memory
• Next.js frontend — patient-facing decision interface with real-time updates (WebSocket for order status)
• Celery task queue — background jobs for data ingestion, embedding generation, weekly retraining
• Redis — session state, hot cache for menus/recipes, pub-sub for real-time notifications

Data Security & Compliance

• Supabase Postgres with Row Level Security (RLS) — patient data isolated at database level, queries auto-filtered by user context
• End-to-end encryption — PHI encrypted at rest (AES-256) and in transit (TLS 1.3)
• Audit logging — every recommendation, data access, and admin action logged for HIPAA compliance review
• BAA signed with all third-party services (Supabase, AWS, OpenAI under HIPAA-compliant tier)

Deployment & Monitoring

• Docker containers deployed on AWS ECS + App Runner — auto-scaling, zero-downtime deployments
• CloudWatch dashboards — latency (P50/P95/P99), error rates, inference throughput, cache hit rates
• Sentry error tracking — real-time alerting for API failures, model inference errors
• Weekly performance reviews — latency trends, accuracy metrics, user feedback analysis

Performance Metrics

• <3s P95 latency across all recommendation requests (target: sub-5s)
• 99.2% uptime over 6 months (target: 99%+)
• Zero PHI breaches or security incidents
• Peak load: 120 concurrent users during lunch rush (12-1pm), handled without degradation

Key Insights from the UCSD Pilot

• Decision fatigue is real — users with 2+ meal options had 31% lower adherence than single-recommendation group
• Time constraints dominate — 68% of decisions prioritized speed over cost or nutrition when time-stressed
• Pantry sync is critical — users who maintained pantry inventory had 40% higher cooking recommendation acceptance
• Context matters more than preferences — same user wants different things at 8am (fast breakfast) vs 7pm (relaxed dinner)
• Feedback loops require friction — 5-star rating worked better than binary thumbs up/down (richer signal)

Technical Challenges Solved

• Cold start problem — new users have no history, solved with cohort-based collaborative filtering + onboarding survey
• Menu data staleness — restaurants change menus without notice, implemented daily refresh + crowdsourced corrections
• Macro estimate accuracy — restaurant estimates unreliable, built confidence scores and flagged low-confidence recs
• Latency vs accuracy tradeoff — 3s felt instant to users, 5s felt slow; optimized to stay under 3s P95

What's Next

• Voice interface — 'Hey Culin, what should I eat?' → instant audio response
• Social eating — group decision mode for families/roommates with divergent preferences
• Meal prep optimizer — weekly grocery shopping list optimized across 7 days of meal decisions
• Expanded integrations — Chipotle, Sweetgreen, meal kit services (HelloFresh, Blue Apron)