The problem isn’t choosing dinner. It’s whether dinner works.
OverviewA system for families managing sensory-sensitive eating
Dinner doesn’t fail when a recipe is chosen. It fails at the table.
Sensory Sprout is designed around that moment. Instead of helping families decide what to cook, it models whether a meal will actually be accepted based on how it is prepared, served, and experienced.
To do that, it captures constraints most meal-planning tools ignore: texture, temperature, preparation method, predictability, and context. Those signals are then used to evaluate and adapt meals that can work across the household.
I designed and built the system end to end: user research, conversation design, prompt architecture, evaluation framework, product design, ranking logic, transformation logic, and trust architecture.
Meal planning breaks down at the moment it matters most
Most meal planning tools optimize for discovery: surfacing recipes, filtering options, and expanding variety.
For families managing sensory sensitivities, the breakdown happens at the table. A meal can be chosen successfully and still fail when it is served.
Small differences in texture, temperature, preparation, or presentation determine whether a meal is accepted or refused. Traditional systems rarely capture those conditions.
What this looks like in practice
My daughter likes shredded cheese cold, straight from the refrigerator. She will eat melted cheese, but only in certain situations. She eats broccoli steamed, never roasted or raw. She will eat red bell peppers raw, but never cooked.
These rules are conditional, contradictory, and highly specific. They are not about ingredients. They are about preparation, temperature, texture, and context.
There is no way to search for that level of specificity. No filter captures “steamed but not roasted” or “cold but not melted.”
What parents carry
Parents are not just managing logistics. They are carrying an unstable system entirely in their heads—cooking multiple meals, watching safe foods disappear, and balancing nutrition with predictability.
“I have to make 3 different meals… they liked it yesterday but not today.”
Parent community post“I’ve given up and just make him a pb&j.”
Parent community postThis is not just a usability gap. It creates ongoing stress, uncertainty, and failure.
What existing tools miss
The gap is not missing filters. It is a mismatch between what tools store and what determines whether a meal is accepted.
Generic preference data flattens the details that actually determine whether a meal gets eaten. The issue is not just ingredients, but preparation, texture, temperature, and context.
I initially thought the opportunity was to help families expand variety and improve nutrition. The real need was reliability: meals that felt predictable enough to work.
Meals must be designed for sensory realities, not generic preferences
The issue is not finding meals that sound appealing. It is predicting whether a meal will actually be accepted when served.
What families need is not more options. They need meals that can succeed under real conditions—given constraints around texture, preparation, predictability, and context.
This reframes the problem from discovery to reliability.
Design requirement
A workable system has to hold two truths at once: meals must stay acceptable now, but the household cannot get stuck in an ever-shrinking set of safe foods.
Meals must stay acceptable while allowing controlled variation
The system has to preserve reliability first, then introduce change in ways that do not break acceptance.
-
Predictability
Meals must feel familiar enough to avoid immediate rejection. -
Variation
The system still needs enough change to prevent safe food lists from narrowing further.
-
Parent effort
The meal has to be realistic to prepare, adapt, and serve. -
Sensory tolerance
Texture, preparation, temperature, and predictability determine whether a meal is viable at all. -
Table dynamics
Meals succeed or fail socially, not just nutritionally.
This reframes meal planning from selecting appealing recipes to constructing meals that can reliably work under real conditions.
What changes
This changes what the system must do. Instead of filtering recipes by ingredients or stated preferences, it must evaluate whether a meal will work under specific conditions.
Assumes the goal is finding meals that sound appealing. Success is measured by variety, novelty, or nutritional balance.
Assumes the goal is determining whether a meal will actually work. Success is measured by whether it can be prepared, adapted, and accepted in context.
A system for evaluating what will actually work
The product is designed as a system, not a meal-planning interface with added personalization. It captures constraints, structures them into a usable model, evaluates meals against that model, and adapts outputs to real conditions.
Each step makes implicit factors explicit—turning context-dependent behavior into something the system can reason about.
Signals
Structured inputs plus conversational nuance around texture, preparation, and context
Constraints
AI surfaces implicit rules as explicit, reviewable constraints
Profile
Conditions are structured into a usable decision model
Viability
Meals are scored against constraints before recommendation
Adapted meals
Results are filtered, adapted, and ranked by likelihood of success
Contextual input becomes explicit constraints, which the system uses to evaluate and adapt meals for reliable outcomes.
Assessment
The system starts with known constraints, then uses guided conversation to surface implicit rules that structured inputs miss.
Structured input
Captures known constraints
Age, allergies, dietary restrictions, and already-known safe foods
Guided conversation
Surfaces implicit rules
“Steamed, not roasted.” “Separate, not mixed.” Examples, edge cases, and preparation conditions
Decision model
Structures those constraints for evaluation
The system organizes those signals into a model it can evaluate meals against
Structured inputs and conversational signals are combined into a model the system can evaluate against.
From conversation to a usable model
Constraints are not stored as preferences. They are structured into a decision model the system evaluates against.
Not just “likes chicken”
Which version, prepared how, at what temperature, with what texture, and under what conditions.
These details are stored as structured constraints, not loose preferences, so the system can reason from them.
Parents review and approve what is captured before anything is saved. The profile is not a record. It is a decision model.
Micro-conditions emerge through conversation, not selection.
The model captures the conditions under which foods are accepted or rejected while remaining transparent and editable.
Evaluating meals against real conditions
Meals are evaluated before selection, prioritizing what can succeed under real household constraints.
Does this match what the family likes?
Optimizes for ingredient fit, similarity, or general appeal.
Can this meal survive contact with this household?
Optimizes for whether the meal can actually be prepared, adapted, and accepted in context.
Ranking prioritizes meals that can be prepared, adapted, and accepted in context, not just those that seem appealing.
Adapting output to the household
Output is a plan adapted to the household, not a generic recipe. Adaptation is built into the structure of the meal.
Standard recipe instruction
“Toss pasta with sauce.”
Household-adapted instruction
“Set aside a plain portion for Emma before adding sauce.”
The output is not just a recommendation. It is a cooking plan already shaped around the household’s constraints.
Learning
The system learns from outcomes, but not silently. Updates are suggested, visible, and controlled.
The system learns from outcomes, but not invisibly. Parents review suggested updates before the profile changes, preserving both accuracy and trust.
The value is not better recommendations. It is making dinner more likely to succeed.
Designing for legibility, alignment, and control
Outputs are treated as proposals shaped by constraints, not answers.
Assumptions are visible and correctable. Corrections update the model over time and improve future evaluations.
The system prioritizes consistency and trust over novelty.
It has to be understandable enough for users to correct.
The architecture follows the cost of getting it wrong
Failures are not equal. A missed allergen is irreversible. A poor recommendation is recoverable.
That distinction shaped the architecture. The system separates safety-critical decisions from interpretation-heavy ones.
| Layer | If it fails | Cost | Design |
|---|---|---|---|
| Recipe retrieval | Suggests an allergen | Irreversible | Deterministic |
| Ranking + transformation | Suggests a bad meal | Recoverable | AI + rules |
| Assessment | Asks the wrong question | Adaptive | AI + routing |
High-risk failures are structurally constrained, while interpretation layers use model judgment where context matters.
Small decisions that determined whether the system worked
The first question determines the rest
Broad openers produced vague answers and long conversations. A targeted opening question reduced turns and improved signal quality.
Profiles are decision models, not stored preferences
Structuring inputs as constraints and rules made the system better at handling edge cases and contradictions.
Updates are suggested, not applied automatically
Surfacing changes for review preserved trust and reduced profile drift.
Structure mattered more than model choice
Reworking prompt architecture produced bigger gains than swapping models alone.
Evaluating reliability under real conditions
The system was evaluated on its ability to produce outcomes that could succeed in context.
Participants recognized and corrected their profiles, improving alignment and trust.
Success was measured by reliability, not variety.
The main shift was increased confidence in outcomes.
The system worked. The product needed to change.
The system could build usable profiles, surface viable meals, and adapt recipes into plans that could realistically work at the table.
What broke down was not the underlying logic, but the experience of using it in live cooking contexts. Latency and interaction overhead created friction in the moments that mattered most.
That revealed a different product direction: less real-time interaction during dinner, more support in planning and reuse before the meal begins.
What this clarified about designing systems
Many product problems are framed too early as discovery problems. The harder challenge is modeling what makes something work.
Designing for reliability requires systems that model nuance, make decisions visible, and stay legible enough for users to correct.
It also reinforced that capability is not the same as usability. A technically capable system can still fail if it does not fit the context in which people need it.