Before we write a single line for the site, we design the voice system like we would an API. Clear rules, reusable, testable.
Phase 1: Voice System Design (No writing yet)
1. Core Voice Identity
We define the “speaker”:
AI Recipe Voice =
- knowledgeable home cook
- understands food and real-life use (sport, family, timing)
- practical, not academic
- confident, not absolute
- sounds like someone who has fed people before they had to go do something
2. Hard Rules (Non-negotiable)
These are constraints your AI must obey:
- ❌ no “but”
- ❌ no clinical phrasing first (“this dish provides…”)
- ❌ no negative framing (“too heavy”, “not ideal”)
- ❌ no over-explaining
- ❌ no fake authority (“perfect for athletes”)
- ✅ lead with purpose
- ✅ keep sentences tight
- ✅ sound spoken, not written-for-a-paper
- ✅ focus on usefulness
- ✅ neutral-positive tone
3. Output Structure Template
Every generated “use-case” should follow a predictable shape:
[Context] → [Timing] → [Why it works] → [Optional practical cue]
Example structure (NOT final wording):
- situation (pre-game, recovery, quick dinner)
- when to eat
- what it gives you (carbs, protein, minerals)
- small real-world hint
This becomes your formatting contract for the AI.
4. Use-Case Categories (Core Feature)
We define reusable tags your system can generate:
Performance
- pre-game fuel
- recovery meal
- endurance support
Daily Life
- quick breakfast
- family dinner
- slow weekend meal
Nutrient Highlights
- protein-forward
- iron-supportive
- vitamin-rich
- balanced meal
Timing-Based
- early day energy
- mid-day steady meal
- evening lighter option
These categories power:
- search
- filters
- AI generation consistency
5. Nutrition Interpretation Layer
Instead of raw numbers → we map:
ingredients → nutrients → meaning
Example pipeline:
- eggs → protein, B12
- beans → fiber, iron
- tomatoes → vitamin C
Then convert into:
- “protein support”
- “iron-supportive”
- “steady energy”
This avoids:
- overwhelming numbers
- fragile accuracy issues
6. Multi-Agent Shape (Simple Version)
Here’s your first clean architecture:
Agent 1: Ingredient Analyzer
- parses ingredients
- maps to nutrient signals
Agent 2: Nutrition Interpreter
-
turns signals into:
- protein-forward
- iron-supportive
- carb-rich
- etc.
Agent 3: Use-Case Generator (Voice Controlled)
- applies your voice rules
-
generates:
- activity context
- timing
- practical phrasing
Agent 4: Formatter
- outputs clean blocks for your site
7. Example Data Schema (v1)
Before coding, we lock structure:
{
"dish": "English Breakfast",
"ingredients": ["eggs", "sausages", "beans", "toast", "tomatoes"],
"nutrition_signals": {
"protein": "high",
"carbs": "moderate-high",
"iron": "moderate",
"vitamins": ["B12", "C"]
},
"use_cases": [
{
"type": "pre_activity",
"activity": "hockey",
"timing": "2-3 hours before",
"note": "generated by voice system"
}
]
}
8. Success Criteria (Very Important)
We test outputs against:
- does it sound like a real person?
- would a coach / parent actually say this?
- is it useful in 3 seconds?
- does it avoid “AI tone”?
- is it consistent across recipes?
Next Step (Your Call)
We’re ready to move to Phase 2: Implementation Plan
I will:
- design repo structure
- define prompts for each agent
- create first working pipeline (likely Node or Python)
- include test cases with your voice rules
New chat detected.. initialising new project mode.
Yes — this is a solid starting base, and your updated direction is much clearer now.
The important shift is this: the current course app is really a calorie chatbot with food guardrails. Your project wants to become a recipe intelligence system with nutrition, culture, and use-case guidance. That is a genuine project, not just a prompt edit.
And your new sports angle is useful because it gives the site a practical dimension:
not “count the calories,”
more “what kind of fuel is this meal, and when does it make sense?”
Also, your instinct about the “traditional mound of pasta” is good. That should become part of the concept model, not just a content idea. In other words, the system should learn that “sport fuel” is a category with multiple expressions, not one cliché plate of pasta.
I would reshape the project around four top-level lenses:
1. Dish identity
What is it? Where is it from? What kind of meal is it?
2. Nutrition identity
Protein sources, carb profile, key vitamins/minerals, overall balance.
3. Use-case identity
Family dinner, recovery meal, steady-energy lunch, before sport, after sport, colder-weather comfort, quick morning start.
4. Variation identity
What are the alternatives in the same role?
That is where your pasta thought becomes powerful.
For example, instead of teaching the system:
“pasta = sports meal”
you teach:
“for training fuel, common base options include pasta, rice, potatoes, oats, bread, couscous, noodles, wraps, and regional grain dishes.”
That gives your international recipes site a real advantage. It lets you say, in effect:
there are many ways to build a performance-friendly meal, depending on cuisine, timing, appetite, and preference.
So yes — Sports should absolutely become a first-class category in the project map. Not the only one, but a real one.
I would define it like this:
Sports / Activity
- before sport
- after sport
- steady energy
- carb-forward meals
- protein-forward recovery meals
- lighter pre-activity options
- bigger refuel meals
That is better than centering everything on hockey specifically, while still allowing hockey as a use-case example.
On the code side, your Chainlit app is a good base because it already has:
- agent orchestration
- memory
- retrieval
- login
- a UI loop
- a place to test voice and behavior quickly
What should change is the architecture goal.
Right now, the agent set is something like:
- calorie calculator
- breakfast planner
- price checker
That is fine for the course, but not for your site.
I would replace that with something closer to:
Recommended v1 agents
-
Recipe Identity Agent
identifies cuisine, meal type, core ingredients, and dish style -
Nutrition Signals Agent
extracts likely protein sources, carb density, vitamins, minerals, fiber, richness -
Use-Case Agent
maps dish to contexts like before sport, recovery, family meal, weekend brunch, quick lunch -
Variation Agent
suggests equivalent meal bases or culturally varied alternatives
this is where the “not always pasta” idea lives -
Voice / Editorial Agent
turns the structured analysis into site-ready text in your chosen tone
That is a clean multi-agent shape without becoming overcomplicated.
The biggest technical redesign is the data layer.
Your current Chroma setup is built around calories.csv. That is too narrow for the new goal. You do not just need “nutrition facts.” You need recipe metadata with interpretation potential.
So your next dataset should move toward fields like:
- dish name
- cuisine / region
- ingredients
- meal type
- protein sources
- carb sources
- fats
- vitamins/minerals of note
- preparation style
- meal timing tags
- sports/use-case tags
- substitution or variation tags
That means the vector store stops being “look up calories” and becomes “retrieve recipe and nutrition context.”
The good news is that you do not have to solve perfect nutrition science in v1. You can build a strong first version around signals rather than exact precision.
For example:
- protein: low / moderate / strong
- carbs: light / steady / fuel-forward
- iron: notable / not prominent
- vitamin C: notable / present / low emphasis
That is far more robust for a recipe site than pretending every generated answer is laboratory exact.
As for the branch, yes — I would absolutely make this official now.
A sensible branch name would be:
feature/international-recipe-intelligence
or, if you want the sports layer named explicitly:
feature/recipe-intelligence-sports-nutrition
I would not keep the word “calorie” in the branch name, because that is no longer the center of gravity.
The immediate project plan I would use is:
Phase 1 — Refactor the concept
Convert the current app from calorie-first to recipe-intelligence-first.
Phase 2 — Replace the agent roles
Drop or sideline calorie calculator and breakfast planner. Introduce recipe identity, nutrition signals, use-case, and variation roles.
Phase 3 — Replace the dataset
Move from calories.csv to a richer recipe metadata source.
Phase 4 — Build category logic
Add first-class categories such as:
International, Breakfast, Protein, Vitamins & Minerals, Sports / Activity, Family Meals, Quick Meals, Recovery Meals.
Phase 5 — Tune the voice
Only after the structured outputs are good.
That order matters. Voice should come after structure.
One more important thing: your pasta idea suggests a feature I think is worth building early.
Call it something like:
“More ways to fuel”
or internally,
performance meal alternatives
This feature would answer questions like:
- what are alternatives to pasta for pre-game fuel?
- what meals from other cuisines fit the same role?
- what gives a similar carb base with different texture or timing?
- what options suit smaller appetite vs bigger appetite?
That could become one of the most distinctive parts of the whole site.
So my judgment is:
your course project base is usable,
your direction is now strong,
and the missing piece is no longer “can this be a project?”
It already is one.
The next thing we should do is define the new project skeleton:
repo layout, agent definitions, data schema, and the first structured output contract for recipes.
We are building quantum computers. If you think you can help, click here.