Sensory Sprout
Designing a system for meals children will actually eat—not just ones they like.
For families navigating selective eating, the challenge isn’t preference—it’s whether a meal can be tolerated at all. Sensory Sprout models sensory tolerance to adapt meals across people and real-world constraints.
Overview
Models sensory tolerance—not just preference—to produce meals that actually work.
Instead of recommending what sounds good, the system selects and transforms meals based on whether they can be tolerated, adapted, and executed.
I designed and built the full system end-to-end: research, conversation design, evaluation, product design, ranking logic, transformation logic, and trust architecture.
Role
PM & AI Practitioner
Team
Solo · 6 participants
Duration
9 weeks
Status
Discovery complete · Evaluation complete · Beta on hold while full flow is completed
The problem
Dinner fails in the last mile.
Most meal tools assume the hard part is choosing what sounds good. For families navigating selective eating, the hard part is whether the meal will actually be eaten once it reaches the table.
Families adapt the same way: multiple meals, shrinking rotations of safe foods, and constant negotiation. Dinner becomes something to manage, not something to share.
I have to make 3 different meals every night… and sometimes they won’t eat more than two bites.
Most tools store broad preferences. Families navigate something much narrower: brand, preparation, texture, predictability, and whether foods can touch.
The issue isn’t preference—it’s sensory tolerance.
Texture, temperature, preparation, and predictability determine whether a food is acceptable at all.
This wasn’t a discovery problem. It was a modeling problem.
Where systems break
What filters capture
Likes chicken.
What families actually navigate
Tyson dino nuggets. Air-fried. From the bag, not the box. No substitutions.
The real decision isn’t “likes chicken.” It’s whether this exact version will be eaten. Generic systems collapse the details that actually determine success.
The reframe
The problem isn’t what to make. It’s whether it will be eaten.
I conducted 6 interviews with parents navigating selective eating across autism, ARFID, ADHD, and sensory processing differences, plus a middle-school perspective.
My initial hypothesis was expanding safe foods. Three interviews killed it. These families weren’t trying to branch out. They were trying to keep dinner from collapsing.
Reframed hypothesis
Families need a system that converts what they already know into meals that are more likely to work—without increasing effort or risk.
Nutrition isn’t the goal. Stability is.
For many families, the immediate goal is that the child eats anything at all. The real need is predictability and less conflict at the table.
Safe foods burn out under repetition.
Families are trapped between two losing strategies: too much repetition burns foods out, but too much novelty risks rejection.
Parents have the data, but not the model.
They know what works in practice, but not always why. The product’s job is to turn lived pattern knowledge into something structured and actionable.
The product
One meal. Multiple outcomes. No backup plan.
Sensory Sprout models what each person can tolerate—then uses that model to select and transform meals that can actually be eaten.
The product only works when capture, ranking, and transformation are aligned.
Assessment
capture constraints
What changes outcomes
Profile
decision model
Facts, rules, patterns, confidence
Ranking
choose viable meals
Structure, branchability, fit
Transformation
make it executable
Workable plates for different eaters
Assessment — capture what changes outcomes
A short conversation captures the signals generic forms miss.
- Mechanism: short, bounded flows capture safe foods, avoidances, sensory rules, and preparation constraints.
- Why it matters: the system gets just enough signal to act without turning intake into work.
Profile — turn inputs into a decision model
The profile exists to influence meals, not just describe preferences.
- Mechanism: facts, rules, patterns, and confidence-weighted signals.
- Why it matters: the system reasons about meal viability—not just preference storage.
Ranking — choose meals that can work
Recipes are ranked by structure and adaptation potential—not similarity alone.
- Mechanism: filter by constraints, then rank by structure, branchability, and adaptation potential.
- Why it matters: results are workable, not just similar.
Original step
Adapted step
Child plate
Family plate
Transformation — make the meal executable
This is where a recommendation becomes a real dinner.
- Mechanism: rewrite recipe steps so one recipe can serve multiple eaters.
- Example: “Toss pasta with sauce” → “Set aside a plain portion before adding sauce.”
Feedback loop — improve without breaking trust
The system evolves without silently changing what it “knows.”
- Mechanism: ratings generate suggested profile updates with user approval.
- Why it matters: the product improves over time without breaking trust.
System design
The system is designed around failure—not features.
Not all errors are equal.
A bad recommendation is recoverable. A missed allergen is not. So each layer is designed with different constraints, not just different logic.
The system only became coherent when built backward from the meal: not “what should we recommend?” but “can this produce a dinner that actually works?”
Each layer handles a different type of risk. The highest-risk layer is the one that cannot fail.
| Layer | Failure | Cost | Design |
|---|---|---|---|
| Retrieval | Allergen shown | Irreversible | Deterministic |
| Ranking + Transformation | Bad execution | Recoverable | AI + rules |
| Assessment | Wrong constraints | Adaptive | AI + routing |
The highest-risk layer is the one that cannot hallucinate.
Different eaters require different conversations.
Each flow uses a distinct questioning strategy—not just different wording.
Profiles are decision inputs, not records.
They exist to shape outcomes, not just store preferences.
Sensory tolerance is a first-class constraint.
Texture, temperature, preparation, and predictability determine whether a meal is acceptable at all.
The system only works end-to-end.
Assessment alone isn’t enough—the full pipeline must produce a meal that can actually be executed.
Evaluation
I evaluated it as a decision system, not a UI.
Because the system is adaptive, polish is not a reliable signal. The question is whether it makes better decisions over time.
Evaluation framework
| Configuration | Pass | Partial | Fail |
|---|---|---|---|
| 4o-mini · old prompt | 6 | 8 | 3 |
| GPT-5.2 · old prompt | 9 | 7 | 1 |
| GPT-5.2 · restructured prompt | 15 | 2 | 0 |
Prompt structure improved outcomes more than a model upgrade alone.
Key findings
Prompt structure mattered more than model upgrades.
Better framing improved outcomes more than switching models.
Failures were structural, not just linguistic.
Issues like flow contamination and inefficient probing only appeared in multi-turn testing.
Architecture solved what iteration could not.
Splitting the system into four flows eliminated entire classes of error.
Outcomes
The outcome was a more defensible product logic—and a clearer path to beta.
The project clarified that reliability depends on system design as much as interface design.
What this produced
A complete operating model: capture constraints, structure them into profiles, rank meals by viability, and transform recipes into executable dinners.
What changed
Product: assistant → system. Evaluation: output quality → decision quality. Beta: staged → end-to-end.
What this enables
A beta that validates the full flow: assessment → profile → ranking → transformation → executable meal.
The system works not because it finds better meals, but because it models what makes meals possible—and makes them executable under real constraints.