Predicting whether a meal will actually work before it reaches the table
For families managing sensory-sensitive eating, the challenge isn't finding another recipe. It's predicting whether a meal will actually be accepted once texture, preparation, brand, and presentation come into play.
The product evolved from a meal-planning concept into a household acceptance model designed to evaluate meal viability, protect trusted foods, and learn only from confirmed outcomes.
Meal discovery to
Acceptance reliability
Protecting safe foods became more important than finding new ones. It was protecting the small set of safe foods that already worked while helping families gradually expand beyond them.
Acceptance became the threshold that every other goal had to clear first.
Families were not struggling to find recipes. They were struggling to predict acceptance.
Families described a recurring cycle of failed meals. A recipe could appear compatible on paper and still fail once it reached the table.
Traditional recipe systems focused on ingredients, dietary preferences, and nutrition. Families evaluated meals using a different set of criteria: texture, preparation method, brand specificity, presentation, temperature, household routines, and emotional context.
One parent explained that broccoli was acceptable when steamed but not roasted. Another described foods that could not touch. Others described children who would only accept specific brands or preparation methods.
A matching ingredient could still fail at dinner
Research: 6 interviews · Parents & children
Acceptance depended on contextual conditions that typical recipe filters could not capture.
Participants described highly specific acceptance rules: broccoli must be steamed, not roasted; peppers must be raw, not cooked; pasta is acceptable only with butter; foods cannot touch; brands are not interchangeable.
“She likes chicken.”
“She likes Tyson dino nuggets, from the bag, air-fried. She refuses chicken prepared any other way.”
The specificity gap became the central design challenge. Broad preferences were too coarse. Viability depended on whether the household conditions around that ingredient stayed intact.
This was not a meal discovery problem. It was a reliability problem.
My initial assumption was that families needed more meal ideas. Research revealed that most households already had a small set of meals that consistently worked.
The challenge wasn’t generating more options. It was predicting whether a new meal was likely to succeed before families invested time, money, and emotional energy.
That shifted the product from meal discovery to acceptance reliability.
Food acceptance wasn’t a preference problem. It was a risk management problem.
Families were not evaluating meals in isolation. They were managing a fragile set of accepted foods. A recommendation only helped if it protected what already worked and introduced change slowly enough to avoid disrupting trust.
Find more meals that might work.
Protect accepted foods while creating low-risk paths to new ones.
Safe foods were reliability assets. Families protected them because failure carried emotional, logistical, and nutritional costs.
The system needed to evaluate fit and protect rotation
Once safe foods became the product’s center of gravity, recommendation quality was not enough. The system had to assess whether a meal would work, preserve what families already relied on, and introduce change carefully.
Acceptance depended on more than the food itself. Preparation, texture, brand, presentation, routine, effort, and recent experience could all change whether the same meal succeeded.
The product model became Evaluate → Protect → Expand.
Recommendations were useful only when families could inspect the reasoning and control what the system learned.
Will this meal work tonight?
Check the meal against household-specific acceptance conditions before the family invests effort.
What already works?
Preserve safe foods, preparation rules, routines, and trusted variations.
What is the lowest-risk next step?
Suggest nearby changes based on familiar, accepted conditions.
The model learned slowly by design
Once the goal became protecting safe foods, the challenge shifted from recommendation quality to trust. Three decisions shaped how the system earned that trust: inspect before committing, learn from real outcomes, and confirm before updating.
Expose why a meal might work before asking families to trust it
Trust comes from inspection, not recommendation. Parents needed to understand the reasoning behind a meal evaluation before investing effort.
Problem: Families needed confidence before investing effort.
Decision: Expose the reasoning behind each meal evaluation.
Tradeoff: The experience became more complex than a simple recommendation feed.
Impact: Families could inspect, challenge, or adapt a meal before cooking.
1
2
3
Inspectable fit before commitment. The interface surfaces household context, recommendation rationale, and acceptance risks before cooking.
Treat real meal outcomes as stronger evidence than prediction logic
Learning should come from evidence, not assumptions. Predicted acceptance and actual acceptance are not the same thing.
Problem: Plausible recommendations could still fail at the table.
Decision: Capture meal outcomes before treating recommendations as household knowledge.
Tradeoff: Learning became slower because the system depended on feedback.
Impact: The model improved from real household experience instead of assumptions.
1
2
3
Outcome capture before learning. The system records what happened at the table before updating future recommendation logic.
Make learning reviewable before it becomes permanent
Learning should be reviewable before it becomes permanent. One successful meal should not automatically become a permanent profile rule.
Problem: One meal outcome should not redefine a household preference.
Decision: Require review before updating household profiles.
Tradeoff: The system learned more slowly.
Impact: Families retained control over what became part of the profile.
1
2
3
Reviewable learning. Proposed updates remain visible and editable before they affect future recommendations.
The architecture followed the trust model
Families set the safety boundary first. AI interpreted nuance inside that boundary. The system recommended or adapted meals only when the reasoning could be inspected and confirmed.
Set household boundaries
Families choose the eating profile and enter allergies, exclusions, dietary needs, and known constraints.
Interpret acceptance nuance
AI asks follow-up questions about texture, preparation, brand specificity, and conditions that forms often miss.
Evaluate meal fit
The system compares a meal against household constraints and explains whether to serve, adapt, or skip.
Confirm before learning
Outcomes can inform the household model only after families review and approve what changed.
Designing for uncertainty meant separating interpretation from commitment
AI could help interpret subjective details such as texture, preparation, and similarity. But decisions involving allergies, exclusions, profile changes, or household safety needed deterministic rules and explicit family confirmation.
This boundary kept AI focused on ambiguity without allowing uncertain interpretations to become household knowledge invisibly.
The architecture clarified where AI should participate. The remaining question was whether the acceptance model could predict household-specific viability reliably enough to support decisions before dinner.
The MVP is testing the open question, not adding more features
The MVP is intentionally narrow because the unresolved risk is not feature coverage. It is whether household-specific meal viability can be predicted reliably enough for families to trust before they cook.
Families need rotation support, not generic meal discovery
Novelty only becomes useful after a meal clears the household’s acceptance threshold.
A narrow Protect → Adapt → Expand workflow
The MVP evaluates meal fit, protects accepted foods, and learns only from confirmed outcomes.
Can household-specific viability be predicted reliably enough to earn trust?
Meal viability depends on preparation, texture, brand, presentation, routine, effort, and recent household experience.
A recommendation is only useful when the family can trust the conditions around it
Sensory Sprout began as a recommendation problem: help families find more meals that might work. Research changed that framing. For these families, a poor recommendation could create stress, wasted effort, conflict, and damage trust in routines that took months to build.
Sensory Sprout changed how I think about recommendation systems. In high-friction contexts, usefulness does not come from generating more possibilities. It comes from helping people understand whether a possibility is safe enough to act on.