Sensory Sprout / AI meal planning system
A system for designing meals that work for sensory-sensitive families
Most meal tools optimize for variety or inspiration. Sensory Sprout is designed for something simpler: whether a meal will actually be eaten. It learns what each person can tolerate, then adapts meals that can work across the household.
Most meal planning tools are built around choice. This one is built around whether a meal actually 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 for that moment: whether a meal is actually accepted. Results are evaluated against each family member’s constraints, including dietary needs, sensory preferences, and watch-outs, not just the search term.
Most tools help you choose recipes. This system evaluates whether a meal will be eaten. It captures constraints most tools ignore, including texture, temperature, preparation, predictability, and context, and uses them to adapt meals that can work across a household.
I designed and built the system end to end: user research, conversation design, prompt architecture, evaluation framework, ranking logic, transformation logic, and trust architecture.
Recipes assume convergence.
For some families,
divergence is the norm.
Most meal planning tools assume a single outcome: one meal, eaten by everyone.
For families managing sensory sensitivities, that assumption breaks immediately.
The problem is not choosing a meal. It is whether that meal works once it reaches the table.
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.” When those conditions are invisible, meals fail in the last mile: at the table.
“She likes chicken.”
“She likes chicken nuggets. They have to be Tyson dino nuggets and she only likes the ones from the bag, not the box. They have to be air-fried or she won’t eat it. She refuses to eat chicken prepared any other way.”
The specificity gap: what systems store vs what actually determines whether a meal works.
What parents are actually managing
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.
What looks like “picky eating” from the outside often behaves more like constant operational risk. A meal can be technically correct and still fail because one sensory condition changed.
“I have to make 3 different meals... they liked it yesterday but not today.”
Parent community post“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 (interview)This is not just a usability gap. It creates ongoing stress, uncertainty, and failure for families trying to make one meal work under real conditions.
What existing tools miss
The gap is not missing filters. It is a mismatch between what tools store and what actually determines whether a meal is accepted.
Existing tools operate at the level of ingredients and stated preferences. The problem exists at the level of sensory acceptance and execution.
I initially thought the opportunity was to help families expand variety and improve nutrition. Six semi-structured interviews with parents of children with ARFID, autism, sensory processing differences, and selective eating killed that assumption quickly: the real need was not better options. It was getting the child to eat at all.
What meals actually have to satisfy
Across interviews and examples, the pattern was consistent. Families were operating under a small set of needs and constraints that shaped every meal decision.
Needs
- Predictability Meals must feel familiar enough to avoid immediate rejection.
- Variation The system needs enough change to prevent safe food lists from narrowing over time.
Constraints
- Parent effort Meals must be realistic to prepare, adapt, and serve under real conditions.
- Sensory tolerance Texture, preparation, temperature, and predictability determine whether a meal is viable.
- Table dynamics Meals succeed or fail socially, not just nutritionally.
The primary goal wasn’t nutrition.
It was acceptance.
Parents aren’t looking for new recipes. They’re trying to get through the day with something that everyone will actually eat.
The question isn’t “what sounds good?” It’s “will this actually be eaten?”
Most tools optimize for the first question. For families managing sensory sensitivities, that assumption breaks immediately.
A safe food can fail because of how it’s prepared that night. It can fail because the child hasn’t had it in a while, or because they’ve had it too many times in a row. And when a food falls off the safe list, it rarely comes back.
What changed
One meal had to work for everyone at the table.
For families managing sensory sensitivities, “working” isn’t just preference. Texture, preparation, temperature, and predictability can determine whether a meal is accepted at all.
The challenge wasn’t finding a better option for one person. It was making one meal workable across the whole table: a sensory-sensitive child, siblings with their own limits, and parents without time to cook separately.
SUCCESS IS A MEAL THAT WORKS FOR EVERYONE.
This reframes the design problem. It’s not about surfacing better options or expanding what a child will eat. It’s about understanding the sensory conditions under which a meal can succeed, then adapting around them so the whole household can eat something that works.
| Traditional systems | Sensory Sprout |
|---|---|
| Preference and discovery | Tolerance and reliability |
| “What sounds good?” | “Will this work?” |
| Success = meal chosen | Success = meal accepted |
Shift from preference to reliability.
A workable system has to hold two things at once: tonight’s meal has to succeed, and the household can’t keep eating the same three things until even those stop working.
Designing for
reliability at the table
The system is designed to answer one question: will this meal work?
To do that, it captures constraints, structures them into a usable model, evaluates meals against those constraints, and adapts outputs to fit real conditions.
Each step makes implicit factors explicit. It turns 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
From contextual input to evaluated, adapted meals.
From recommendation to execution
Most meal planning tools stop at recommendation. They suggest what to cook, but they leave the hardest part unresolved: making it work at the table.
Sensory Sprout shifts that responsibility into the system.
The output is not a generic recipe. It is a cooking plan already adapted to the household’s constraints.
This is the difference between a meal that looks correct and one that actually works. Adaptation is built into the structure of the meal.
Capturing what actually determines success
Many of the constraints that determine whether a meal works are not known upfront. They emerge through specific experiences, exceptions, and patterns over time.
Captures known constraints
Age, allergies, dietary restrictions, and already-known safe foods
Surfaces implicit rules
“Steamed, not roasted.” “Separate, not mixed.” Examples, edge cases, and preparation conditions
Structures those constraints for evaluation
The system organizes those signals into a model it can evaluate meals against
Turning nuance into a decision model.
Conversation-based assessment
The assessment adapts to what the parent already knows. For parents who can only describe what their child rejects, it stays brief. For those with detailed knowledge of textures, brands, and preparation conditions, it goes deeper and surfaces the implicit rules that wouldn’t emerge from a form.
These signals are aggregated into a working profile. Instead of storing broad preferences, the system captures the conditions under which foods are accepted or rejected, and uses those conditions to evaluate whether a meal can succeed before it is recommended.
Structured profile
What comes out of the conversation isn’t a list. It’s a structured model the system can evaluate meals against. Each constraint is explicit, reviewable, and correctable before it shapes any recommendation.
The architecture follows the cost of getting it wrong.
Not all failures are equal.
A weak recommendation is recoverable. A missed allergen is not.
That distinction shaped the architecture. Instead of treating the product as one continuous AI workflow, I separated it into layers based on the cost of failure and the kind of judgment each layer required.
| 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 |
Architecture follows failure cost.
Why the safety-critical layer is deterministic
Retrieval is the highest-risk layer because it determines what enters the candidate set in the first place. If the system surfaces a recipe containing a known allergen, no later layer can make that safe.
For that reason, retrieval is deliberately non-generative. It depends on a curated recipe source and deterministic filtering so that safety constraints are enforced structurally, not probabilistically.
Where AI is useful
Once the candidate set is safe, the problem changes. The question is no longer whether a recipe is allowed. It is whether it can work.
Ranking and transformation require interpretation: whether a meal can branch cleanly, whether components can stay separate, whether steps should change before serving, and whether the overall structure fits the household’s constraints.
These layers still use rules, but they benefit from model judgment because the failure cost is lower and the task is more contextual.
Why assessment is its own layer
Assessment sits upstream of everything else. If the system misunderstands what a person can tolerate, every downstream decision degrades.
I treated it as a separate layer with its own routing logic, stop conditions, and evaluation criteria. The goal was not just to generate a smooth conversation. It was to produce a usable decision model for the rest of the system.
Trust by structure
This architecture also defines the human-in-the-loop moments: profile review before save, suggested updates instead of silent changes, and outputs that stay legible enough for a parent to judge and correct.
Trust does not come from saying the system is careful. It comes from making the highest-cost failures structurally harder to make, and keeping the rest visible enough for people to stay in control.
Evaluating reliability under real conditions
The system was evaluated on its ability to model constraints accurately and produce outputs that could reliably succeed at the table.
Standard single-response testing was not sufficient. The assessment is multi-turn and stateful, which means errors compound across interactions and often appear acceptable in isolation.
To evaluate it properly, I built a structured test set and measured whether the system could produce a usable profile efficiently, consistently, and with the correct reasoning path.
Evaluation snapshot
Eval Scorecard
Pass / partial / fail count for the strongest configuration
No. of turns
Reduced profile-building from 8–11 turns to 3–5
Synthetic test cases
Covered common eating patterns and edge cases
Upgrading the model improved results slightly. Restructuring the system improved them significantly. The largest gains came from making the system easier to reason with and harder to misuse.
What single-turn testing missed
Multi-turn evaluation surfaced failure patterns that would not have been visible in isolated responses.
What changed because of evaluation
The fix was not additional tuning. It was architectural.
I split one overloaded prompt into four specialized agents with clearer responsibilities, shorter instructions, and explicit stop conditions. This removed entire classes of failure instead of trying to patch them through wording.
The result was a system that was faster, more consistent, and more aligned with the actual goal of the assessment: building a usable model without exhausting the parent.
What drove the biggest gains
The most significant finding wasn’t about model selection. It was about prompt architecture.
Testing the same prompt on a stronger model improved results from 6 passing cases to 9. Restructuring the prompt by replacing prose strategy with a decision tree, adding an explicit output contract, and clarifying stop conditions improved results from 9 to 15. Prompt architecture drove twice as much improvement as the model upgrade.
The most important improvements did not come from model capability alone. They came from structuring the system so that correct behavior was easier to produce and incorrect behavior was harder to reach.
Zoom out before you go deep.
The assessment worked. But I had optimized it before verifying what it was feeding.
When I started working through the product experience end to end, I realized I wasn’t confident the profiles I was building contained what the rest of the system actually needed. So I paused. Instead of continuing to refine the assessment, I took a full household profile with multiple people and different constraints, then played out what adapting a real recipe for that family would look like. Then I worked backwards: what data would I need to make that adaptation happen?
That exercise clarified more about what the assessment should capture than weeks of prompt iteration had. The assessment improved not because the conversation got better, but because I finally knew what it was for.
What still needs to be tested
Variety only works when it’s reliable.
The system has to do two things at once: keep meals acceptable now, and introduce enough variation to keep them workable over time.
That balance still needs to be validated in real-world use. I stopped here intentionally because I wanted feedback on the idea, not noise from an unreliable system.
Variety without reliability fails.
What I’d do differently as a PM
I approached this project primarily as an AI designer and builder, which meant going deep on prototyping and evaluation before validating the idea. That was a deliberate choice for this project, and it produced real artifacts. But on a real engagement, I’d have sought feedback on the hypothesis much earlier, with something faster and lower-cost than a working system. The building came before the market question, and I know it.