Sensory Sprout / AI meal planning system
A system for making dinner reliable for families with selective eaters.
A meal planning system designed around what actually gets eaten. Sensory Sprout models what each person can tolerate, then helps turn that understanding into a meal that can be prepared, adapted, and served.
6
Parent interviews across autism, ARFID, ADHD, and sensory processing differences
4
Adaptive conversation flows designed for different eater types
15 / 2 / 0
Pass / Partial / Fail on the strongest prompt configuration
Designed around what actually gets eaten.
This system is built around what reliably works in practice—not what sounds good or looks balanced on paper.
It models what each person can tolerate, then uses that understanding to shape a meal that can actually be accepted, prepared, and served.
Dinner fails long before it reaches the table.
For these families, the hardest part is not choosing a meal—it is whether that meal can hold together once real people, real constraints, and real table dynamics enter the picture.
By the time a meal is served, most outcomes are already determined by tolerance, preparation, and family dynamics.
Parents adapt in consistent ways: cooking multiple meals, negotiating at the table, or rotating through the same safe foods. Most tools store broad preferences, but these families are navigating something much narrower—texture, preparation, predictability, separation, and whether food will be tolerated at all.
“If I change one thing, no one eats. If I don’t change anything, we’re stuck eating the same meals forever.”
1120 × 840 recommended
(4:3 full-width visual)
These families do not need more meal ideas. They need meals that can balance tolerance, variation, effort, and dynamics at the same time.
The problem is not finding meals. It’s making them work.
Early interviews surfaced a consistent pattern: families were not primarily looking for novelty. They were trying to prevent meals from breaking down.
That shifted the focus from meal discovery to meal reliability—and from generic preference matching to designing around real constraints.
The real question was what the system needed to know.
I started by focusing on the assessment: how to capture richer signals about selective eating, especially sensory preferences. But over time I realized I still had not answered a more fundamental question—what information does the system actually need to personalize a meal in a way that works in practice?
Sensory data mattered, but it was not enough on its own. I needed to define what makes a meal viable at the table—preparation, predictability, separation, and how much adaptation a parent can realistically execute—and let that determine what the system should capture.
Defining the right inputs also raised a broader question: what makes a personalized meal successful? It is not just whether it gets eaten. It is whether it holds together at the table—how it is prepared, introduced, adapted when something goes wrong, and how it supports the dynamics between parent and child.
That shift changed the project. The goal was no longer just better intake. It was a clearer decision model for turning what a family can tolerate into a meal that can actually be made, served, and sustained in practice.
Process shift
From richer intake to better inputs
Initial focus
Reframed system
The shift was not just collecting richer data. It was defining which inputs actually mattered for producing a meal that could work in practice.
The system produces one meal that works across multiple eaters.
It models what each person can tolerate, then uses that model to construct a shared meal. Instead of optimizing for preference or variety, it prioritizes whether the meal can actually hold together when prepared and served. The output is not just a recommendation—it is something that can be executed.
System pipeline
From intake → executable meal
Each stage reduces a different type of failure—from unclear inputs to a meal that can actually be served.
One meal that works for everyone.
Sensory Sprout models what each person can tolerate—then uses that model to make a single meal viable across multiple eaters.
The value isn’t just understanding the eater. It’s producing something that can actually be cooked, adapted, and served in practice.
System pipeline
From intake → executable meal
Each stage reduces a different type of failure—from ambiguous inputs to a meal that can actually be cooked and served.
Profile
Turn inputs into a decision model
Constraints, patterns, and execution rules are structured for decision-making—not storage.
The system can treat hard rules differently from softer tendencies.
Ranking
Choose meals that can work
Meals are ranked by viability, not appeal: structure, branchability, adaptability, and familiarity matter more than ingredient match alone.
Confidence
Rank with confidence, not certainty
Strong signals can guide decisions without overcommitting to weak or early inferences.
Make the meal executable.
Recipes are not just selected—they are transformed. The system analyzes each recipe for structure, branch points, and conflicts, then rewrites the execution path so one meal can work across different eaters.
The goal is not just to produce a recommendation, but to produce a meal that can actually be prepared, served, and adjusted in real time without breaking down at the table.
Transformation
From recipe step → executable meal
Branch point: before sauce is added
Original recipe
Single-path instruction
Toss pasta with sauce.
Adapted for this meal
Branch the execution path
Before adding sauce, set aside a plain portion for the child.
Toss sauce with the remaining pasta for everyone else.
Child plate
Plain pasta
(no sauce, separate)
Family plate
Pasta with sauce
(full dish)
The system does not just recommend recipes. It rewrites the execution path so one meal can work across multiple eaters.
Adaptation
Turn structure into action
The system decides where to split the dish, what to keep plain, what to serve separately, and when to introduce a safe anchor.
Example: “Before adding sauce, set aside a plain portion for the child.”
Support
Support the moment, not just the meal
A meal succeeds or fails in how it is introduced and managed. The system can surface lightweight guidance about presentation, separation, and adjustment when something is rejected.
Assessment
Capture what changes outcomes
Focused intake captures the signals that actually determine whether a meal can work.
Evaluated as a decision system.
The question was not whether the interface felt polished. It was whether the system made better decisions under different conditions and profiles.
Structure mattered more than model upgrades
Better prompt and flow structure improved outcomes more than switching models.
Failures were structural, not linguistic
The biggest issues came from reasoning, sequencing, and signal handling—not wording alone.
Architecture resolved whole classes of error
Separating flows and clarifying decision logic removed repeated breakdowns across cases.
A clearer system, and a stronger product logic.
This work clarified how to capture meaningful constraints, structure them into decision inputs, and turn them into meals that are viable in practice.
What this clarified
How to move from intake → profile → ranking → transformation as one coherent decision system.
What changed
The product shifted from assistant → system, and evaluation shifted from output quality → decision quality.
Let’s build systems that hold up in practice.
This project explored reliability in one domain. I’m interested in solving similar problems wherever outcomes depend on real-world conditions.
Product strategy, AI systems, and trust-sensitive design.