A system for designing meals that work for sensory-sensitive families

The problem isn’t choosing dinner. It’s whether dinner works.

Overview

A system for families managing sensory-sensitive eating

Dinner doesn’t fail at the moment you choose a recipe. 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 eaten based on how it is prepared, served, and experienced.

Most tools help you choose recipes. This system models whether a meal will actually be eaten based on how it is prepared, served, and experienced by the people at the table.

To do that, it captures each family member’s constraints at a level typical tools ignore. Not just ingredients, but texture, temperature, preparation, and predictability. These signals are then used to select and adapt meals that can work across the household.

I designed and built the full system end to end: user research, conversation design, prompt architecture, evaluation framework, product design, ranking logic, transformation logic, and trust architecture. Self-initiated, solo.

Problem

Recipe apps assume convergence.
For some families, divergence is the norm.

Most recipe apps are built for households where everyone wants roughly the same thing. You search, you filter, you cook.

That model assumes the hard part is deciding what sounds good, and that once you decide, everyone at the table will eat it.

For some families, that assumption breaks.

The hard part is not choosing a meal. It is whether that meal will be eaten 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, and never too much. She eats broccoli steamed, never roasted or raw. She will eat red bell peppers raw, but never cooked.

The 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. No filter that captures “steamed but not roasted” or “cold but not melted.” Existing tools have no model for how food is actually experienced.

When those conditions are invisible, meals fail in the last mile, at the table.

What parents carry

In interviews and parent communities, the same pattern surfaced repeatedly.

Parents are not just managing logistics. They are carrying an unstable system entirely in their heads.

Cooking multiple meals every night. Watching safe foods disappear without warning. Trying to balance nutrition, predictability, and emotional stability, with no reliable way to plan.

This is not just a usability gap. It is an ongoing source of stress, uncertainty, and failure.

What existing tools miss

Desktop research confirmed that this is not an edge case.

Selective eating spans a wide range. Some children have mild constraints around preparation or texture. Others have extremely limited and shrinking safe food lists. Most do not have a formal diagnosis, but still operate under the same dynamics.

Across that spectrum, the gap is consistent:

Existing tools operate at the level of ingredients and preferences. The problem exists at the level of sensory acceptance and execution.

The gap is not just missing filters. It is a mismatch between what tools store and what actually determines whether a meal will be accepted.

The specificity gap

This is the specificity gap. Generic filters collapse the details that actually determine whether a meal gets eaten. The problem is not just ingredients. It is preparation, texture, temperature, presentation, and context.

Recipe apps can exclude broccoli. They cannot account for how broccoli must be prepared to be tolerated, or whether the meal structure will work for everyone at the table.

Initial hypothesis

Going in, my assumption was that the opportunity was in expansion.

Help families try new foods. Surface options that might work. Track what had been attempted and what succeeded.

That is what most solutions in this space aim to do.

It turned out to be the wrong problem.

I started by thinking the opportunity was to help families expand variety and improve nutrition. The real need was reliability: meals that felt predictable enough to work.

Reframe

Meals must be designed for sensory realities, not generic preferences

Dinner doesn’t fail when you choose a recipe. 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.

The initial instinct was to expand options: introduce new foods, surface alternatives, and track what worked over time.

That assumes progress comes from increasing variety. In practice, families were not failing because they lacked options. They were failing because meals were unpredictable.

A meal can look right and still fail. A previously safe food can suddenly be rejected. Small changes in preparation, texture, or context can determine whether a meal is accepted or refused.

This is not a discovery problem. It is a reliability problem at the table. A successful meal is not just chosen—it has to balance competing needs and constraints. The system is designed to operate within that tension.

Design requirement

From preference to reliability at the table

From preference to tolerance

Preferences are too coarse to predict behavior. They collapse important differences between “likes,” “sometimes,” and “only if.”

Tolerance is more precise. It captures the boundaries that determine whether a meal succeeds or fails: texture, temperature, preparation method, predictability, and context.

Once those constraints are explicit, meals can be evaluated not by how appealing they sound, but by whether they can actually work.

Design implication

Meal planning becomes a reliability problem.

A meal can look right and still fail. A previously safe food can suddenly be rejected. Small changes in preparation, texture, or context can determine whether a meal is accepted or refused.

Product

Designing for reliability at the table

That requirement shaped the product directly. If meals have to stay acceptable while allowing controlled variation, the system cannot operate like a standard meal planner.

Instead of helping families choose what sounds good, it has to model what each person can actually tolerate, use that model to evaluate whether a meal can work, and adapt the output into something that can realistically be prepared and served.

The product therefore operates as a system: capturing constraints, structuring them into usable models, evaluating meals against those constraints, and adapting them into plans that can actually work at the table.

A hybrid assessment: structure first, nuance second

Not all inputs are equally complex. Some information is known and stable: age, allergies, dietary restrictions, and other explicit constraints.

What actually determines whether a meal works is often more specific. It emerges through examples, exceptions, and lived experience: steamed but not roasted, separate but not mixed, one brand but not another.

The assessment is staged accordingly. It begins with structured inputs for what is already known, then shifts into guided conversation to surface the conditions that fixed forms miss.

Capturing constraints through conversation

Parents build a food profile for each family member through a short, guided conversation.

The goal is not to capture preferences in broad terms. It is to capture the specific conditions that determine whether a food is acceptable at all.

Many of the constraints that determine whether a meal works are not known upfront. They emerge through specific experiences: a rejected texture, a tolerated preparation, a brand that consistently works.

Instead of relying on fixed inputs or filters, the system uses conversation to surface these micro-conditions over time.

Parents review and approve what is captured before anything is saved. The profile is not a record. It is a decision model.

Building a profile that can be used

These signals are aggregated into a working profile. Instead of storing broad preferences, the profile captures the conditions under which foods are accepted or rejected.

The profile is transparent and editable. Users can review interpretations, correct inaccuracies, and refine constraints as new patterns emerge.

Evaluating meals against real conditions

Meals are evaluated before they are selected.

The system does not rank options by popularity or similarity. It evaluates whether they can realistically succeed under the household’s actual constraints.

Meals that hold together under variation, allow flexible assembly, and can be adapted without breaking rise to the top. Meals that look good on paper but fail at the table do not.

A recipe that is already adapted

Instead of presenting a standard recipe with notes or substitutions, the system produces a cooking plan that is already adapted to the household.

Adaptation is not an afterthought. It is built into the structure of the meal.

Alongside these structural changes, the system can surface practical guidance that supports how meals are experienced over time: pairing something familiar with something new, involving a child in a manageable step, or avoiding approaches that erode trust.

A system that learns with you

After a meal, parents can rate how it went for each person.

Those ratings do not silently update the system. Instead, they generate suggested changes to the food profile, which the parent reviews and approves. The model improves over time, but remains visible and controlled.

This keeps the system aligned with reality as it changes, because in these households, what works is rarely stable.

Supporting different levels of restriction

For families with moderate selectivity, the goal is straightforward: make dinner more reliable and less stressful.

For families dealing with more acute restriction, including shrinking safe food lists, the stakes are different. Every lost food may not come back.

The same system supports both because it operates at the level where meals succeed or fail: tolerance, preparation, and predictability.

In one case, that means finding a meal that works tonight. In another, it means introducing just enough variation to keep the system from narrowing further without triggering rejection.

How the system works

The value is not better recommendations. It is making dinner more likely to work.

System Design

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 system as one continuous AI workflow, I separated it into layers based on the cost of failure and the kind of judgment each layer required.

Why the safety-critical layer is deterministic

Recipe 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 database 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.

That is where AI becomes useful. Ranking and transformation require interpretation: whether a meal is branchable, whether components can stay separate, whether a step should be adapted 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 to generate a friendly 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 recipe reasoning that stays legible to the parent.

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 judge.

Key Design Decisions

Small decisions that determined whether the system worked.

The overall architecture matters, but the system only becomes reliable when the details are right. These were the decisions that had the biggest impact on whether it worked in practice.

Evaluation

Prompt structure mattered more than model choice.

Standard testing was not enough for this system. The assessment is adaptive, multi-turn, and stateful, which means errors compound across turns and are often invisible in single-response evaluation.

To evaluate it properly, I built a three-tier framework that tested the system at the level that mattered: whether it could produce a usable food profile efficiently, consistently, and with the right reasoning path.

Upgrading the model improved results. Restructuring the prompt improved them more.

Moving from GPT-4o-mini to GPT-5.2 improved pass rates by 3 cases. Reworking the prompt architecture improved them by 6 more. The biggest gains did not come from model quality alone. They came from making the system easier to reason with and harder to misuse.

What single-turn testing missed

Multi-turn testing surfaced failure patterns that would have looked acceptable in isolated responses.

What changed because of evaluation

The fix was not more polishing. It was architectural.

I split one long, overloaded prompt into four smaller, specialized agents with clearer responsibilities, shorter instructions, and stronger stop conditions. That change eliminated entire classes of error structurally rather than trying to patch them through prompt wording alone.

The result was a system that was faster, more consistent, and more aligned with the actual job of the assessment: building a usable model without exhausting the parent.

Outcomes

The system worked. The product needed to change.

By the end of the project, the core system was functional and validated. The assessment could build usable profiles, the ranking layer could surface viable meals, and the transformation layer could adapt recipes into plans that could realistically work at the table.

Evaluation showed consistent improvement across prompt iterations, with the strongest configuration reaching 15 pass, 2 partial, and 0 fail across the test set. Conversations became shorter, more targeted, and more reliable.

What worked

The system successfully reframed meal planning as a reliability problem and proved that tolerance-based modeling is both feasible and useful. It could capture constraints at the level families actually experience them and use those constraints to make better decisions.

Separating deterministic safety layers from AI-driven reasoning also held up in practice. High-risk failures were structurally prevented, while lower-risk decisions benefited from model flexibility.

Where it broke down

The system worked, but the product experience did not fully translate to the context it was designed for.

In live scenarios, latency and interaction overhead disrupted the flow of cooking and decision-making. Waiting even a few seconds for responses, or navigating multiple steps mid-task, created friction at the exact moment families needed the system to feel lightweight and dependable.

This exposed a gap between what the system could do and when it could be used effectively.

Resulting decision

Rather than pushing toward a full, real-time product, I paused development and reframed the opportunity.

The most valuable part of the system is not live interaction during dinner. It is the ability to build a reliable model ahead of time and use it to plan meals that are more likely to succeed.

This suggests a different product direction: one that emphasizes pre-planning, lightweight reuse, and faster execution over real-time guidance.

The system proved the concept. The next step is aligning the experience with the realities of how families actually cook and decide.

Reflection

Designing AI systems means designing how they fail.

This project started as an exploration of how to use AI to generate better meal recommendations. It ended as an exercise in designing for reliability under real-world constraints.

The most important shift was realizing that capability is not the limiting factor. The system could generate recipes, adapt them, and reason about constraints. What mattered was whether those capabilities could be used in a way that felt dependable.

Reliability matters more than intelligence

A system that is occasionally impressive but often unpredictable is not useful in high-stakes, everyday contexts like feeding a family. The goal is not to produce the best possible answer. It is to produce an answer that can be trusted to work.

That reframed the entire design. Instead of optimizing for variety or novelty, the system prioritizes meals that are most likely to succeed, even if they are less interesting.

Structure matters more than model choice

Early iterations focused on testing different models and prompt variations. While model quality had some impact, the largest improvements came from restructuring the system itself.

Breaking a single prompt into smaller, specialized agents with clearer responsibilities made the system more predictable, easier to evaluate, and easier to improve. The architecture did more to determine performance than the model alone.

Context determines usability

The system performed well in isolation, but struggled in the moment it was intended to support. Cooking is time-sensitive, interrupt-driven, and cognitively loaded. Even small delays or extra steps become meaningful friction.

That reinforced that designing the system is not enough. It has to fit the context in which it will be used. A technically correct solution can still fail if it does not align with how people actually behave.

What I would do next

The next iteration would focus less on expanding capability and more on refining where and how the system shows up. That likely means shifting further toward pre-planning, faster reuse of known profiles, and minimizing interaction during time-sensitive moments.

The core system is strong. The opportunity now is to make it feel effortless to use in the moments that matter.