A system that predicts whether a meal will be accepted — and helps fix it when it won’t.
Most meal tools help you choose recipes. This system predicts whether a meal will actually be eaten — based on each person’s constraints — and suggests how to adapt it before you cook.
The system is designed around one question: what happens when a meal fails, and who bears the cost? It prioritizes preventing high-cost failures — meals that get rejected at the table — while keeping everything else visible enough to adjust.
A system for families managing sensory-sensitive eating
The failure point isn’t which recipe you choose. It’s whether anyone will eat it.
Sensory Sprout is designed for that moment. It models the conditions that determine whether a meal will be accepted. It then evaluates meals against those constraints before they reach the table. For example, if a child only eats broccoli when it is steamed, a recipe with roasted broccoli is filtered out before it is ever suggested. Most tools help you choose recipes. This system predicts whether a meal will actually be eaten.
Solving for tonight is only part of the problem. Over time, safe food lists shrink as families rely on the same meals.
The system introduces controlled variation, expanding what can work without breaking what is safe.
I designed and built this system end to end to test whether meal outcomes can be predicted and improved.
In early testing, this reduced rejected meals and shortened conversations from 8–11 turns to 3–5.
Search → Evaluate → Adapt. Each result is scored against the household, not just the query.
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 these families, that outcome is not just unlikely. It is structurally impossible.
What this looks like in practice
The problem is not choosing a meal. It’s whether that meal works once it reaches the table.
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, but about preparation, temperature, texture, and context.
Most tools cannot represent that level of specificity. That is why they fail at the table.
The specificity gap
This creates a mismatch between how systems store data and how decisions actually get made.
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."
Before parents could worry about nutrition, they had to solve for acceptance
I began with a nutrition-centered assumption: parents might need help improving what their child eats over time.
To test this, I conducted six semi-structured interviews with parents of children with sensory sensitivities, ARFID, or autism spectrum diagnoses. Sessions focused on real mealtime behavior: what was served, what was rejected, how meals were adapted, and the cost of failure.
To supplement interviews, I reviewed parent community discussions to identify recurring patterns beyond the participant sample.
The goal was not to validate a solution. It was to understand how meals actually worked, or failed, in practice.
What parents are actually managing
Parents are not just managing logistics. They are managing an unstable system: cooking multiple meals, watching safe foods disappear, and balancing predictability with change.
My two kids are insanely picky. I have to make 3 different meals for the 3 of us every single day. And then sometimes they won't eat more than two bites... I'm losing my mind.
I microwaved her plain Alfredo pasta and the sauce at the edge turned slightly brown. She wouldn't eat it.
Across interviews and community discussions, one pattern was consistent: small differences in texture, temperature, preparation, and presentation determined whether a meal was accepted or rejected.
These decisions were highly specific, often contradictory, and difficult to generalize.
Predictability and variation pull in opposite directions. Meals that are too familiar shrink the safe food list over time. Meals that are too new are rejected immediately.
Across interviews, one pattern became clear: nutrition was not the first problem to solve. Acceptance was.
The most useful data came from the child, not the parent
One participant was an 11-year-old interviewed directly about their own food preferences. Unlike the parents — who were often inferring causes — the child could clearly articulate why foods worked or didn’t: texture, predictability, and control.
I know what's in the frozen burrito. With other burritos, sometimes you order them and you don't know what's in them.
This revealed a gap in the model. Parents track behavior, but children understand the conditions driving it.
It also introduced a new factor — older children are motivated by social contexts (school, friends, public eating) in ways younger children are not.
This shaped the next phase of the system: involve the child directly in building their profile, and support parents in situations where they are not present.
It also shifted the problem framing — from what families should eat to the conditions that make eating possible.
Meals worked only when a small set of forces were in balance
Across interviews, one pattern emerged: meals did not fail because of a lack of options or nutritional value. They failed when key needs and constraints were misaligned.
A meal could be nutritionally complete and still be rejected. Success depended on something more immediate: whether the meal felt acceptable in the moment.
This reframed the problem from meal selection to constraint alignment.
Each family was navigating the same underlying system, even when their strategies looked different on the surface.
What a successful meal must balance
Five competing forces determine whether a meal works. Together, they define the core requirement the system must satisfy.
A meal succeeds only when these forces are in balance:
The design problem was no longer meal discovery. It was ensuring reliability under real conditions.
The primary goal wasn’t nutrition.
It was acceptance
Parents weren’t looking for new recipes. They were trying to get through a meal with something everyone would actually eat.
The core question wasn’t “what sounds good?” It was “will this actually be eaten?”
The problem wasn’t variety.
It was reliability.
Parents weren’t asking for more options.
They were asking for fewer failures.
This reframed the product from recipe discovery into a system designed to reduce failure and improve reliability at the table.
This shift changes how the system is designed and evaluated:
| Traditional systems | Sensory Sprout | |
|---|---|---|
| Preference and discovery | → | Constraints and reliability |
| “What sounds good?” | → | “Will this work?” |
| Success = meal selected | → | Success = meal accepted |
Designing for reliability at the table
This system answers one question: will this meal work at the table?
Existing tools optimize for ingredients, nutrition, or variety. They do not account for the conditions that determine whether a meal is accepted.
To make outcomes predictable, the system models acceptance as constraints: texture, temperature, preparation, context, and predictability. It then evaluates meals against those constraints before they reach the table.
Model conditions, not preferences.
Decision
Model meals using texture, temperature, preparation, context, and predictability instead of broad likes and dislikes.
Tradeoff
Increases modeling complexity, but allows the system to predict whether a meal will actually work.
This shifts the goal. Instead of generating more options, the system reduces failure by recommending meals that are likely to work in real conditions.
This required capturing real-world behavior as structured constraints the system could evaluate and adapt.
Designing for where meals break
Meals fail across a sequence: planning → cooking → serving → acceptance.
| Where meals break | What fails | System response | Pipeline step |
|---|---|---|---|
| Planning | The meal looks viable, but does not reflect real constraints. | Capture brand, texture, preparation, and context signals. | 1 · Signals |
| Cooking | Small preparation changes make the meal unacceptable. | Translate implicit rules into explicit constraints the system can evaluate. | 2 · Constraints |
| Serving | Presentation, separation, temperature, or timing changes acceptance. | Store conditions in a reviewable profile before recommendations are made. | 3 · Profile |
| Acceptance | The meal reaches the table but is rejected in the moment. | Score meals against constraints before surfacing them. | 4 · Viability |
| After the meal | Parents learn what happened, but that learning usually stays in their heads. | Capture outcomes and use confirmed patterns to refine future results. | 5 · Adapted meals + feedback loop |
Design for failure points, not success cases.
Decision
Structure the system around where meals break instead of ideal outcomes.
Tradeoff
Reduces flexibility, but aligns the system with real-world behavior.
Once these conditions are explicit, the problem shifts from capturing preferences to evaluating whether a meal will actually work.
A system for turning food signals into meal decisions
Each step transforms messy input into something the system can evaluate and trust.
In practice, this means a meal only works if these forces align at the same time:
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
↻ Corrections and outcomes refine the profile over time
Viability
Meals are scored against constraints before recommendation
Adapted meals
Results are filtered, adapted, and ranked by likelihood of success
System flow: from input to evaluated, adapted meals.
[Needs title]
Meals are evaluated against constraints before they are surfaced. This avoids suggesting options that fail at the table.
Capturing enough detail without overwhelming the parent
The assessment had to capture enough detail to model constraints—without making onboarding burdensome.
Evolution of the interaction model
Iteration 1
Static survey
Too predefined- Efficient for known inputs
- Required predefined options
- Missed unexpected signals
Iteration 2
Full conversation
Too unbounded- Captured richer nuance
- Made simple inputs effortful
- Produced inconsistent signals
Iteration 3
Hybrid assessment
Structured + adaptive- Captures known inputs efficiently
- Surfaces nuance through conversation
- Builds reviewable constraints
Adapting the assessment to different eating patterns
Early versions showed that signal quality depended less on what was asked, and more on when and how it was asked.
Route inputs before collecting detail.
Decision
Classify eating patterns upfront so the system can ask the right questions from the start.
Tradeoff
Introduces upfront friction, but improves signal quality and reduces downstream correction.
"Which describes how [name] eats?"
Conversation paths
-
Flow A · Broad eaters
Focuses on hard limits. Captures precise exclusions that should never appear in recommendations. -
Flow B · Rule-based eaters
Focuses on what fails. Identifies cross-cutting constraints that filter meals. -
Flow C · Highly restrictive eaters
Focuses on loss and avoidance. Captures rejection patterns and narrowing diets. -
Flow D · Limited context
Starts minimal. The profile improves through use and feedback over time.
Adaptive conversation
1
2
3
“A good day of eating” helps the parent describe normal before surfacing what is difficult.
Food identity, preparation method, cooking state, sauce tolerance, texture context, and hard rules can surface together.
Instead of probing each food individually, the system asks follow-up questions that surface reusable constraints.
Captured signals must become usable system constraints.
Turning messy input into structured, reviewable constraints
Instead of storing preferences as isolated inputs, the system translates responses into reviewable constraints that can be corrected and applied consistently.
Structured profile output
1
2
Once meals can be evaluated against constraints, the next question is where failure matters most.
The architecture follows the cost of getting it wrong
A weak recommendation is recoverable. A missed allergen is not.
The system is structured around this difference. Instead of a single AI workflow, decisions are separated by the cost of getting them wrong and the type of judgment required.
Architecture by failure cost
| Layer | If it fails | Cost | Design response |
|---|---|---|---|
| Recipe retrieval | Suggests an unsafe ingredient | Irreversible | Deterministic filtering |
| Ranking + adaptation | Suggests a poor fit | Recoverable | AI judgment with rules |
| Profile modeling | Misrepresents constraints | Compounding | Human review and correction |
Constrain AI by failure cost.
Decision
Use AI only where errors are recoverable, and rely on deterministic systems where mistakes are irreversible.
Tradeoff
Limits where AI can be applied, but ensures safety is enforced structurally rather than probabilistically.
These decisions determine whether the system can be trusted in real use.
Trust is enforced through system architecture
Trust comes from how each decision is constrained, reviewed, and exposed to the parent.
Safety constraints run before any model judgment occurs. If a family member has a dairy allergy, no recipe containing dairy enters the candidate set.
Every constraint the system surfaces is reviewable and correctable before it shapes recommendations. The parent approves the model, not just the output.
Results show 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.
A structured model still fails if it learns the wrong things.
Learning from outcomes without corrupting the profile
After a recipe is tried, the parent records what happened for each person at the table.
Feedback is stored as outcome history, not automatically applied to the profile. This prevents incorrect assumptions from shaping future recommendations.
Feedback on meals
The system makes its interpretation visible so users can correct it before it matters.
1
2
3
The system surfaces what it believes happened, making its reasoning visible.
Observations are translated into a clear, editable profile rule.
If the system misunderstood, the user can correct, refine, or dismiss the suggestion before it affects future results.
Review before learning
Interpretations are confirmed before updating the profile, preventing incorrect assumptions from compounding.
To keep these guarantees reliable, the first version deliberately limits what the system does.
What the system deliberately excludes
These exclusions kept the first version focused on reducing failure at the table.
| Excluded | Reason | Product decision |
|---|---|---|
| AI recipe generation | Generated recipes require a validation layer to ensure ingredients, preparation, and cooking conditions are correct. Without that layer, outputs can be unsafe or fail in practice. | Use curated, verified recipes as a stable base. Apply adaptation and filtering on top of trusted inputs. |
| Goal-based behavior change | Goals like expanding foods or therapeutic progression require longitudinal data, stronger safeguards, and clearer clinical boundaries. | Focus first on capturing sensory constraints and personalizing meals families can use now. |
| Nutrition information | Nutrition data would pull attention back toward optimization before the acceptance problem is solved. | Do not surface calories, macros, or nutrient gaps in the first version. Add later only if it supports meal acceptance. |
Evaluating reliability under real conditions
A correct response is not enough. The system needs to produce meals that actually work at the table.
Because the experience is multi-turn and stateful, errors compound across interactions and can appear acceptable in isolation.
What success looked like
after 25+ prompt iterations
in early testing
and edge cases
This defined success as both accuracy and usability, not just correctness.
Defining evaluation before building
Before running a single test, I designed a three-tier framework:
- Single-turn validation — correctness of individual responses
- Multi-turn scenarios — behavior across full conversations
- Automated runs — consistency at scale
Test cases were grounded in research archetypes (brand-locked, texture-selective, shrinking safe lists) and stratified across low-, medium-, and high-risk conditions.
This ensured the system was evaluated against meal viability, not just response quality.
What improved in practice
With this framework in place, three improvements mattered most:
- Conversations reduced from 8–11 turns → 3–5, lowering parent effort
- Incorrect or unsafe suggestions dropped to 0 in final test runs
- Flow routing errors (cross-contamination between eater types) were eliminated
- The system consistently exited once enough signal was captured
These changes made the system faster, more predictable, and more likely to produce meals that actually work at the table.
Design evaluation around conversation outcomes, not individual outputs.
Decision
Test full conversations instead of isolated outputs to capture compounding errors across turns.
Tradeoff
Increased testing complexity and setup time.
Impact
Revealed failure modes that single-turn testing missed:
What single-turn testing missed
- 01 Did not know when to stop. Conversations ran 8–11 turns instead of 3–5.
- 02 Logic leaked across eater types. Flows contaminated each other, producing incorrect questions.
- 03 Kept probing after enough signal. Conversations continued instead of exiting cleanly.
Restructuring the prompt drove greater gains than switching models.
What I learned
- Multi-turn systems fail in ways that are invisible in single outputs
- Prompt structure has more impact on behavior than model choice
- Reliability comes from constraining decisions upstream, not improving outputs downstream
The next step is validating whether predicted meal viability holds in real-world use.
These results are based on controlled scenarios; real-world validation is the next critical step.
The system got better when I stopped asking AI to do everything
The system became reliable when decisions moved upstream
Early versions relied on the model to interpret and adapt in real time. This produced inconsistent results.
Moving decisions upstream—into routing, constraints, and evaluation—made the system more reliable. The model performed better when its role was constrained, not expanded.
The assessment is a model, not a form
Midway through the project, the assessment was passing tests and producing smooth conversations. But working backward from a real meal exposed the gap.
The goal was not to collect preferences. It was to produce a decision model the system could trust for ranking, adaptation, and learning.
Value must be proven end-to-end
Testing the assessment alone would only show whether users could complete it.
The real test is whether the system delivers value across the full loop: constraints → adapted meals → outcomes → learning.
That is the level at which this product needs to be validated.
This reframed the product
The initial concept was search-first: find a recipe, then adapt it.
Research showed families already know what works. They don’t need discovery—they need reliability.
This led to two products:
- A Recipe Adapter for immediate value responses
- A coaching system for long-term behavior change
The adapter creates immediate value, but the system only becomes meaningful when it supports decisions over time.
That shift—from one-off answers to ongoing reliability—reframed what the product needed to be.
A simple tool to validate demand. A system to deliver value.
The next phase follows a two-product strategy: validate demand with a simple tool, then expand into a full system.
The Recipe Adapter solves a single problem: a parent finds a recipe and needs to know if it will work. They paste a recipe, the system adapts it to the child’s profile, and returns a version with specific preparation and texture adjustments. No setup. No commitment.
Now: Recipe Adapter
A lightweight tool for adapting a single recipe to a child’s sensory profile.
Next: Sensory Sprout Core
Parents who see results from the adapter become the audience for a coaching system that:
- Plans meals across the week
- Nudges before key moments
- Learns from outcomes over time
Strategy map
Now
Recipe Adapter
In progress- Paste any recipe URL or text
- Personalized recipe output
- Quick-add profile from recipe screen
Next
Sensory Sprout Core
Designed- Weekly rotation planning
- Food chaining strategy layer
- Meal outcome feedback loop
Future
Clinical integration
Concept- Therapist access and sharing
- Child-facing progress view
- Shareable profiles for caregivers
Why sequence it this way
The sequence reduces risk before expanding scope.
The adapter solves an immediate problem while creating the profile required for the full system.
If families ask for more, invest in coaching. If not, it still delivers value and generates insight.