The system turns food constraints into meals that can actually be cooked, split, and served.
The challenge wasn’t finding recipes. It was making one dinner work across different eaters.
Overview
A system for making dinner reliable for families with selective eaters. Not by finding “better” recipes, but by selecting and adapting meals that can actually work.
I designed the full product and built the AI conversation system underneath it: research, conversation design, evaluation, product design, ranking logic, transformation logic, and trust architecture. Self-initiated.
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 points, not features.
The core insight: not all errors are equal.
A bad recommendation is recoverable. A missed allergen is not. So each layer is designed differently.
The system only became coherent once it was built backward from the meal. Assessment alone wasn’t enough. The real question became: can this produce a dinner that actually works?
| 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 different questioning strategy—not just different wording.
Profiles are decision inputs, not records.
They exist to influence meals.
The system models sensory tolerance as a first-class constraint.
Texture, temperature, preparation, and predictability determine whether a meal is acceptable at all.
The system had to be built end-to-end.
Assessment alone was insufficient—the pipeline had to work as a whole.
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.
Let’s Talk
Let’s build something thoughtful together.
Product leadership, AI strategy, and trust-sensitive systems.
I’m open to roles where I can work closely with engineering and design—especially on ambiguous problems where framing matters as much as execution.