Predicting whether a meal will actually work before it reaches the table
For families managing sensory-sensitive eating, every meal depends on predicting acceptance across texture, preparation, brand, and presentation.
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
The product’s responsibility became protecting the small set of foods families already relied on while creating careful paths toward expansion.
Acceptance became the threshold that every other goal had to clear first.
Families needed a way to predict acceptance before a meal reached the table.
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: 5 adult interviews · 1 child interview
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.
Families needed confidence that a meal would work before investing in it.
My initial assumption was that families needed more meal ideas. Research showed that most households already had a small set of meals that consistently worked.
Their harder problem was deciding whether an unfamiliar meal was likely to succeed before spending time, money, and emotional energy on it.
That made acceptance reliability the product’s first threshold.
Protect what already works before expanding what might work next
Predicting acceptance made the product more useful, but it did not address the larger risk: safe foods could disappear from rotation through repetition, burnout, or small changes in preparation.
The product needed to protect what already worked before recommending what might work next.
Predict whether a meal is likely to work.
Protect reliable foods while creating low-risk paths to new ones.
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.
View the early prototypeExpose 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 work surfaced a larger question: whether prediction alone was the right center of the product, or whether families needed a broader system for preserving reliable meals over time.
The prototype clarified the product direction—and the limits of the original concept
Sensory Sprout established a stronger model for evaluating meal viability, protecting reliable foods, and introducing change carefully. It also showed that the original product concept would need to change substantially before moving into meaningful validation.
Families needed support for reliability and rotation, not generic meal discovery
The research reframed the problem around household-specific acceptance, protecting trusted foods, and expanding only through low-risk changes.
A working concept for Evaluate → Protect → Expand
The prototype explored meal-fit evaluation, inspectable recommendation reasoning, outcome capture, and reviewable profile learning.
The strategic reframe pointed beyond the product that had already been designed
Continuing to test the existing interface would have validated a concept that no longer fully matched the problem revealed by the research. The next version would require a more substantial product rethink rather than another round of feature refinement.
Can a product support reliable meal rotation without increasing family effort?
The core opportunity remains open: helping families preserve workable meals, notice when rotation is narrowing, and introduce change without destabilizing what already works.
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 comes from helping people understand whether a possibility is safe enough to act on.