CareCuisine

CareCuisine helps caregivers of patients with clinical conditions plan a week of food the patient will enjoy using the Qloo Taste Graph to match their heritage and culture.

Comment

About CareCuisine

Inspiration

This started with a frustration I kept hearing about: renal and diabetic diets don't usually fail because people don't understand them. They fail on adherence. The diet sheet says "low sodium, watch potassium," and what the patient actually hears is "you can't eat your own food anymore." So meals get skipped — and a skipped meal doesn't help anyone's labs.

A caregiver is stuck reconciling three things at once: what the patient will actually eat (their heritage, their taste, the place they come from), what's clinically safe, and whether it fits the day. Most food apps do one of these. They either recommend food with no safety model at all, or they enforce safety rules with no idea what this particular person likes.

I kept coming back to one line that became the whole design: affinity is not a clinician. Qloo is brilliant at knowing what someone will love. But Qloo's own safe-use policy is explicit that you must not infer health from affinity — and I think that's exactly right. So I built the two halves to never touch each other.

What it does

CareCuisine drafts a week of dinners — home-cooked first — for a caregiver to take to the patient's dietitian.

  • Qloo decides the mix. You enter the patient's heritage cuisines and what they love outside food — a musician, a film, their home region. Each one gets resolved to a Qloo entity, and the Taste Graph scores every nearby place and cuisine against it. Cuisines they love more get more dinners. A cuisine adjacent to their heritage can join the week if Qloo scores it high — e.g. Frank Sinatra + Roman Holiday nudges Italian into a Mediterranean week.
  • Home cooking is the plan, restaurants are the extra. 55 heritage recipes across 9 cuisines, each with gram quantities and steps, each with sodium / potassium / phosphorus / carbs / protein computed from USDA FoodData Central (every ingredient pinned to a clickable USDA id). 0–3 meals out per week — the caregiver chooses — come from restaurants that passed the venue screen.
  • A deterministic gate owns safety. Three independent layers run on every candidate: a policy blocklist, a clinical constraint matrix with thresholds audited against KDIGO 2024 / ADA 2026 / ESPEN / AHA–ACC, and the caregiver's own constraints (soft foods, accessibility, sodium). It can approve, reject, or say "needs review" — and it refuses when it doesn't have the data to rule.
  • The dietitian decides. The dietitian can enter per-meal limits that override the guideline defaults, and the plan ends with an explicit list of what it's leaving to them.
  • Every item carries a receipt. Which Qloo call and taste signal shaped it, which USDA entries its numbers came from, which rule gated it — and, crucially, what it does not establish.

How I built it

  • Backend: FastAPI (Python 3.12), a vanilla-JS front end, no build step.
  • Qloo Taste Graph is the source of truth for culture and affinity:
    • /search resolves music / films / regions to entities.
    • /v2/insights does the real ranking — one call per cuisine + city, then one call per taste signal via signal.interests.entities, so Qloo scores every place against what the patient loves.
    • /v2/trending down-weights signals that are cooling: a signal's affinity is multiplied by its velocity_fold_change, floored at 0.6. Rising signals aren't boosted.
    • /v2/audiences is shown as context only; /v2/tags is used by the outing agent.
  • How a venue is scored. The taste score is the mean, over the taste signals, of (Qloo affinity for that signal $\times$ its trend factor):

$$ \text{taste} = \frac{1}{n}\sum_{i=1}^{n} a_i \cdot \min!\big(1,\, \text{fold}_i\big) \quad\text{with } \text{fold}_i \ge 0.6 $$

and the final rank blends taste with the clinical score:

$$ \text{rank} = 0.55 \cdot \text{taste} + 0.45 \cdot \text{clinical} $$

among only the venues that passed the gate.

  • Nutrition for home recipes is computed from a bundled USDA SR Legacy extract. Venue figures are clearly labelled as screening-level estimates.
  • The safety gate is fully deterministic — no LLM picks meals or decides safety. The only LLM in the loop is a tool-calling agent that searches for the one weekend outing, and its trace is shown separately and labelled as such.
  • Privacy is architectural, not a promise. No patient name, no clinical condition, and no symptom text ever reach Qloo — only taste concepts, the city, and specialty nouns like "rheumatologist."
  • Runs offline in mock mode (invented sample venues, every card labelled sample data) so anyone can try it with zero credentials.

Challenges I ran into

The hardest part wasn't the code — it was discipline about honesty. It would have been easy to claim Qloo "knows" a restaurant's sodium. It doesn't; Qloo publishes places, not nutrient panels. So every venue nutrition figure is an inferred estimate, and I made the UI say so on every single card, with a method and a confidence.

Keeping taste and safety genuinely separate took real architectural work — the clinical layer never sees the taste data and the Taste Graph never sees a diagnosis, and I had to resist every shortcut that would have blurred that.

I also had to be honest that live Qloo scoring couldn't be exercised from my development machine, so the ranking in offline mode runs the same code against a hand-written sample affinity table, clearly labelled. The live path follows the verified /v2/insights and /v2/trending parameter shapes.

And one clinical nuance mattered: KDIGO 2024 says potassium "should be individualized" and isn't routinely restricted — so CKD potassium is a flag for dietitian review, not an automatic rejection. Getting that right meant reading the guidelines, not just coding limits.

Accomplishments that I'm proud of

  • The two-brain architecture actually holds: Qloo grounds taste, a deterministic auditable layer owns safety, and they never get confused.
  • Every clinical threshold declares its basis — guideline, derived (a cited daily target $\div\,4$, with the arithmetic shown), or product_decision (a conservative number I chose, labelled as mine).
  • A full "what this does not establish" section, volunteered up front — because a clinician, patient, or judge shouldn't have to go find the caveats.
  • It runs with one command, no signup wall, and the test suite can't accidentally make a billed Qloo / LLM call.

What I learned

That the responsible-AI constraint and the good-product decision were the same decision. Treating Qloo as a taste engine and not a health oracle didn't limit the product — it's what made it trustworthy enough to hand to a dietitian. I also learned a lot about reading clinical guidelines precisely enough to encode them without overstating what they say.

What's next for CareCuisine

  • Replace the hand-set venue nutrition baselines with a real nutrition data source so venue estimates get sharper.
  • Model cooking losses (e.g. potassium leaching when boiling) so recipe numbers get even closer to reality.
  • A dietitian-facing review mode and shareable plan links.
  • Broader condition coverage and IDDSI texture levels beyond the current set.

Built With

Share this project:

Updates

Submission history