A system that predicts whether a meal will be accepted before it reaches the table.
Meals must work across constraints — not just preferences.
Read the case study
Meal planning breaks when preferences diverge
Tools optimize for choosing meals
Most meal tools optimize for discovery, assuming one good option will work. They help families browse recipes, filter ingredients, and choose what to cook. But in households with multiple constraints, choosing a meal is not the hardest part. A meal that looks viable can still fail when preparation, texture, or context does not match what each person can accept.
Meals succeed or fail based on conditions
For many families, preferences are conditional and highly specific. A child may eat broccoli steamed but not roasted, or cheese melted but not cold. These decisions are not about ingredients. They depend on preparation, texture, temperature, and context.
Most systems cannot represent this level of specificity, so they make the wrong decision before the meal is ever made.
The specificity gap
What tools store
"She likes chicken."
What actually determines whether a meal works
"She likes chicken nuggets. They have to be Tyson dino nuggets, from the bag, air-fried. She refuses to eat chicken prepared any other way."
Most systems cannot represent this level of specificity, so they make the wrong decision before the meal is ever made.
Before parents could worry about nutrition, they had to solve for acceptance
Meals don't fail at selection.
They fail at the table.
Parents weren't struggling to find meals. They were struggling to get through them.
Small differences in texture, temperature, preparation, and presentation determined whether a meal was accepted or rejected.
Acceptance is driven by conditions, not preferences
Parents described preferences as inconsistent or contradictory. The same food could be accepted one day and rejected the next.
What mattered was not the ingredient, but how it was prepared, presented, and experienced in context.
Children could explain what made meals feel safe (or not)
Parents inferred patterns from behavior. The child participant could clearly describe what made food feel predictable, safe, or unacceptable.
This shifted the work from cataloging preferences to identifying the conditions that make eating possible.
Research method
6 parent interviews · 1 child interview · community discussion review
I microwaved her plain Alfredo pasta and the sauce at the edge turned slightly brown. She wouldn't eat it.
Parent of a child with ARFID
I know what's in the frozen burrito. With other burritos, sometimes you don't know what's in them.
11-year-old participant
These patterns revealed how meals succeed or fail.
Research takeaway
Meal acceptance depends on conditions such as texture, preparation, temperature, and context — not broad preferences.
Meals worked only when five forces stayed in balance
The system needed to balance competing needs: enough familiarity to avoid rejection, enough variation to prevent safe foods from narrowing, and enough constraint to keep meals realistic.
The goal was not discovery.
It was acceptance.
Families needed meals to work under real conditions, using what they already knew was safe.
Before
Discovery
Systems optimize for preference and choice, assuming one good option will work.
After
Reliability
The system evaluates whether a meal will work for a specific household before it’s shown.
Implication
Design shift
The product must operate as a decision system—evaluating meals against constraints before selection and learning only from confirmed outcomes.
Designing for reliability at the table
To support this shift, the system evaluates meals against household constraints before they are shown and learns only from confirmed outcomes.
Meals are chosen before the system knows they will work
If the goal is to predict whether a meal will work, evaluation cannot happen after selection.
Evaluate meals before discovery
1
2
3
Evaluating meals earlier improves reliability, but it raises a new problem: what exactly is being evaluated?
Preferences are too vague to predict acceptance
Preferences are too coarse to predict whether a meal will be accepted. Small differences in preparation, texture, and context determine whether a meal actually works.
Model constraints instead of inferred preferences
| Pipeline step | Stage | What fails | System response |
|---|---|---|---|
| 1. Signals | Planning | Meals appear viable but ignore real household constraints | Capture signals: brand, texture, preparation, and context conditions |
| 2. Constraints | Cooking | Small preparation changes make meals unacceptable | Translate implicit rules into explicit, testable constraints |
| 3. Profile | Serving | Presentation, temperature, or timing shifts acceptance | Store structured conditions in a reviewable, editable profile |
| 4. Viability | Acceptance | Meals reach the table but fail in the moment | Score meals against constraints before surfacing them |
| 5. Feedback | After the meal | Outcomes are observed but rarely captured or reused | Capture outcomes and learn only from confirmed patterns |
But once evaluation is structured this way, another issue appears: not every outcome reflects a stable pattern.
Noisy outcomes can reinforce the wrong patterns
Not all outcomes reflect stable patterns. Learning from every result risks reinforcing incorrect assumptions.
Confirm outcomes before updating the profile
1
2
3
This keeps the system stable — but it does not guarantee it works in practice.
Evaluating reliability under real conditions
Reliability had to be measured across full conversations, not isolated responses. So before testing, I defined what success would look like.
Success criteria
Success meant the system could:
- Capture enough signal in 3–5 turns
- Route the conversation correctly based on eater type
- Stop once enough information was collected
- Produce responses that were accurate and usable
Final results (after 25+ prompt iterations)
The biggest gains came from restructuring the prompt, not switching models. This showed that system behavior depended more on constraint design than model capability.
Designing evaluation to reflect real-world use
To reflect real-world usage, I evaluated the system at three levels:
- Single-turn validation: whether individual responses were correct
- Multi-turn scenarios: whether the system behaved reliably across full conversations
- Automated runs: whether performance stayed consistent at scale
Test cases were grounded in realistic household scenarios such as brand-locked, texture-selective, and shrinking safe lists. This ensured the system was evaluated against meal viability, not just response quality.
What broke under multi-turn testing
- 01 Stopping logic was weak. Conversations ran 8–11 turns instead of 3–5.
- 02 Logic leaked across eater types. Flows contaminated each other.
- 03 The system kept probing after enough signal. It failed to exit cleanly.
Evaluate prompt behavior across full conversations, not isolated responses
Full-conversation testing revealed where the system broke down across routing, stopping logic, and state management.
What improved in practice
After evaluating behavior at the conversation level:
- Conversations reduced from 8–11 turns to 3–5, lowering parent effort
- Flow routing errors were eliminated
- The system consistently exited once enough signal was captured
These changes made the system faster, more predictable, and more likely to produce meals that work at the table.
What I learned
- Multi-turn systems fail in ways that are invisible in single outputs
- Prompt structure shapes behavior more than model choice
- Reliability comes from constraining decisions upstream, not refining outputs downstream
These results are based on controlled scenarios. Real-world validation is the next critical step.
The system became reliable when I constrained where decisions happen
Move decisions upstream
Early versions relied on the model to interpret and adapt in real time. This produced inconsistent results.
Moving decisions upstream into routing, constraints, and evaluation made behavior predictable. The model performed better when its role was constrained, not expanded.
Collecting signals isn’t building a decision model
The assessment was structured, but not around the right end state. It collected useful food signals, but those signals needed to map to a decision model for ranking, adaptation, and learning.
Value must be proven end-to-end
Testing individual steps only showed whether users could complete them. The real test was whether the system delivered value across the full loop:
constraints → adapted meals → outcomes → learningThat is the level at which this product needs to be validated.
Reliability didn’t come from improving outputs. It came from deciding where decisions should happen, then constraining them there.
Proving reliability in real households
The next phase focuses on validating reliability outside controlled testing and expanding the system’s ability to learn from real-world use.
The sequencing reduces risk by proving core assumptions before increasing system complexity.
Now
Validate real-world reliability
- Test whether constrained decisions hold across different household profiles
- Measure acceptance and repeat meal success
- Identify where predicted viability breaks in practice
Next
Improve constraint modeling
- Expand how texture, preparation, and context are represented
- Refine how constraints interact across household members
- Reduce false positives in edge cases
Future
Learn over time
- Build profiles that evolve from confirmed outcomes
- Balance short-term acceptance with long-term expansion
- Close the loop between outcomes and future recommendations