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 AI systems optimize for better recommendations. This one optimizes for recommendations families can act on — by making the highest-cost failures structurally impossible and keeping everything else visible enough to correct.
A 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 — capturing the constraints that determine whether a meal will be accepted before it ever reaches the table.
Most tools help you choose recipes. This system evaluates whether a meal will be eaten. It captures constraints most tools ignore — 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.
Search results. Evaluated against each family member's profile — not just the search term.
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.
What tools store
"She likes chicken."
What actually determines whether a meal works
"She likes chicken nuggets. They have to be Tyson dino nuggets, from the bag, air-fried. She refuses to eat chicken prepared any other way."
Six interviews. One assumption killed. A clearer problem.
I conducted six semi-structured interviews with parents of children with sensory sensitivities, ARFID, or autism spectrum diagnoses.
Participants were recruited through online communities and personal networks. Sessions were 45–60 minutes and focused on a typical mealtime week: what they served, what got rejected, how they adapted, and what the emotional cost was. Interviews were not designed to validate a solution — they were designed to understand the actual shape of the problem.
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.
"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)I initially thought the opportunity was to help families expand variety and improve nutrition. The interviews killed that assumption quickly: the real need was not better options. It was getting the child to eat at all.
Research redefined what "success" means.
Reframing success as acceptance rather than discovery changed what the system optimizes for, what it surfaces, and how it communicates outcomes to parents. A system designed for variety would have been built entirely differently. This is where the architecture starts.
Predictability and variation pull in opposite directions. A meal that's too familiar narrows the safe food list over time. A meal that's too new gets rejected at the table. The system has to hold both.
Synthesis
The diagram below maps what emerged: two competing needs pulling in opposite directions, three structural constraints any solution would have to respect, and a single design requirement that had to hold all of it.
What a successful meal must balance. Five competing forces define what any successful meal must balance for these families — and what the system has to hold in tension at once.
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.
The problem wasn't variety. It was reliability.
Parents weren't asking for better options. They were asking for fewer failures.
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.
| Traditional systems | Sensory Sprout | |
|---|---|---|
| Preference and discovery | → | Tolerance and reliability |
| "What sounds good?" | → | "Will this work?" |
| Success = meal chosen | → | Success = meal accepted |
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 — 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
System flow. From contextual input to evaluated, adapted meals — each step makes implicit factors explicit.
How each step works
Conversation design: three iterations
Getting parents to articulate implicit food rules required the right format — one that met them where they were rather than asking them to think abstractly. Three versions before the approach worked.
Four conversation flows, deterministically routed
The biggest single improvement to the assessment wasn't a prompt change. It was a product decision: ask one question before the conversation starts.
"Which describes how [name] eats?"
Routing is deterministic — an If-Else based on the user's selection, not LLM inference. This eliminated the biggest failure mode in multi-turn testing: a single overloaded prompt trying to manage four different conversation strategies simultaneously.
Deterministic routing over probabilistic inference.
Because wrong flow means wrong questions means a useless profile. Early versions let the AI infer eater type mid-conversation — it guessed wrong, asked misaligned questions, and conversations ran twice as long. Moving classification to a single pre-conversation UI choice made routing 100% reliable.
Conversation-based assessment
1
2
3
Structured profile output
4
5
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.
Architecture by failure cost
| 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 |
Choosing not to use AI in the safety-critical layer is itself a design decision.
The recipe retrieval layer is deliberately non-generative. A missed allergen is irreversible — no later layer can undo it. The design question wasn't "how do we make AI safe here?" It was "should AI be involved at all?" Deterministic filtering enforces safety structurally, not through model instruction.
Trust isn't a feature. It's a set of decisions made across every layer.
For families whose child has severe allergies or ARFID, the cost of a wrong recommendation isn't inconvenience — it's a failed meal, a lost safe food, or a medical risk.
Trust has to be earned structurally, not promised in copy. Three mechanisms work together across the system to do that.
One human-in-the-loop moment, placed deliberately.
Profile review happens before any recommendation is generated — the only moment of structured oversight in the flow. This placement was intentional: where the cost of a misunderstanding is lowest and the parent's ability to correct it is highest. The parent approves the model, not just the output.
Trust mechanisms — each addressing a different failure risk
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 to correct.
The recipe layer is non-generative by design. Safety constraints run before any model judgment occurs — if a family member has a dairy allergy, no recipe containing dairy enters the candidate set. Because a missed allergen is irreversible, the architecture doesn't ask AI to be careful here. It removes AI from this layer entirely.
Every constraint the system surfaces is reviewable and correctable at the profile step, before it shapes any result. This is the only human-in-the-loop moment before recommendations are generated. The parent approves the model — not just the output.
The search results screen shows exactly what the system is evaluating against for each family member — before the parent commits to a recipe. A parent can disagree with the reasoning and adjust the profile, not just accept or reject the output.
Evaluating reliability under real conditions
Standard single-response testing was not sufficient. The assessment is multi-turn and stateful — errors compound across interactions and often appear acceptable in isolation.
Before running a single test, I designed a three-tier framework. Tier 1: 40 single-turn synthetic queries to validate first-response behavior. Tier 2: three multi-turn scenarios plus four edge cases. Tier 3: planned automated runs at scale using Langfuse observability.
The 40 test cases were built from 10 archetypes grounded in interview data — brand-locked, texture-selective, shrinking safe list, smell-reactive — difficulty-stratified across easy, medium, and hard. Hard cases meant emotional content, near-zero input, or a diagnosis mention where the wrong response could damage trust.
The evaluation framework was a design artifact.
It defined what "good" looked like before any prompt was written. 40 synthetic test cases built from research archetypes, difficulty-stratified across easy, medium, and hard. This wasn't QA — it was a specification. The framework had to exist before the prompt, because without it there was no way to know what the prompt was supposed to do.
What single-turn testing missed
Running isolated single-turn tests made individual responses look acceptable. Multi-turn testing revealed a different picture — failures that only became visible across a full conversation.
- 01 The system did not know when to stop. Conversations ran for 8–11 turns when they should have completed in 3–5, adding friction without improving the profile.
- 02 Logic leaked across eater types. Rules designed for one flow appeared in another, producing incorrect questions and weaker models.
- 03 The system kept probing after it had enough signal. Even after identifying a useful pattern, the conversation often continued instead of exiting cleanly.
Three things I learned about designing AI systems — not just about this one.
In high-specificity, trust-sensitive domains, abstract questions produce abstract answers. The harder problem isn't getting AI to ask better questions — it's removing the ambiguity that makes good questions impossible in the first place. Every time I moved a decision upstream and made it structural, the AI's performance in the remaining space improved. Reducing the model's responsibility in one place consistently freed it to do better work everywhere else.
Midway through the project I was ready to move to beta. The assessment was working — 25+ prompt iterations, a structured eval framework, passing test cases. Then I stopped and asked a question I hadn't asked rigorously enough: was the assessment capturing what the rest of the system actually needed?
Instead of moving forward, I took a full household profile — multiple people, different constraints — and worked through what adapting a real recipe for that family would require. Then I worked backwards: what data would make that adaptation possible? The gaps were immediate and specific. The conversation design got better as a consequence — because I finally understood what the assessment was for, not just whether it was producing smooth conversations.
Catching that before beta, not after, was the right call. On a real engagement I'd ask that question earlier — before building evaluation infrastructure, not after.
Recipe search, ranking, and transformation logic are designed but not yet built. The project is paused while I complete other portfolio work. I stopped here intentionally: I wanted feedback on whether the core system holds up, not noise from a half-finished product.
What I'd do differently
On a real engagement, the sequence would be different. I approached this primarily as an AI designer and builder — going deep on prototyping and evaluation before validating the core hypothesis with real families. A moderated session with two or three families and a rough prototype would have answered the market question faster and cheaper than a working system. The building came before the market question, and I know it.
The data the system already collects is the data food therapy needs.
The sensory dimensions the assessment captures — texture, temperature, preparation method, brand specificity, predictability — are exactly the dimensions food chaining uses to identify safe next steps toward new foods.
Food chaining is a clinically-established therapeutic approach: start with a food a child already accepts, then introduce small sensory variations to bridge toward a new food. McDonald's fries → homemade fries → different-shaped fries → roast potato. The SOS (Sequential Oral Sensory) Approach breaks food introduction into 32 gradual steps, starting with tolerating a food in the same room and progressing toward tasting and eating. Both depend on knowing a child's sensory profile at the level the assessment already captures.
- Sensory assessment
- Profile building
- Recipe search
- Ranking + adaptation
- Trust architecture
- Meal outcome logging
- Safe food history
- Profile refinement
- Food introduction log
- Child meal involvement
- Therapist access
- Food chaining plans
- SOS exposure tracking
- Progress sharing
- Therapist revenue model
The assessment wasn't just built to find tonight's dinner. The data it captures is the same data a food therapist would use to plan a therapeutic progression. Solving the daily operations problem first wasn't a detour — it was the foundation the clinical layer needs to exist.