SIAL Innovation Selection 2026
Equipment & Technology · SIAL Paris, 17–21 October 2026
Evidence-based, AI-powered recipe design
Design food to a nutritional standard — and prove it before production.
Recipe Design is MEDI.SOLA’s AI engine that reformulates a recipe until it satisfies every condition of a clinically authored nutritional standard — all of them at once, in seconds. Nothing is cooked until the design already complies.
6–8 months of expert trial-and-error2–3 months with RD
100,000+
Verified nutrition data points
200+
Standardized ingredient blocks
15+
Disease & life-stage standards
25,000+
Clinical trial meals
The process
How the process runs, end to end
Inside a manufacturer, recipe design is a shared process with a clear owner at each stage — laboratory, R&D and marketing teams own the stages on either side, and RD’s engine performs the conversion at the centre. It is not a one-way pipeline: the last stage feeds the first.
The two inputs
Nutri-Standard
Clinically authored conditions
Verified data
MFDS · USDA · Canada · own lab
RD Core · EliteRecipe
A genetic algorithm searches ingredient proportions for the formulation that best fits the standard.
Cook it, and taste it
A trial batch is produced to the exact weights. A sensory panel judges appearance, smell, texture and taste — every verdict recorded against it.
An accredited lab
The request is raised from the recipe itself, bound to its exact version. Measured values are judged against the standard automatically.
The gap is the asset
Predicted versus measured is stored for every nutrient, every analysis — correcting the database and sharpening the engine that uses it.
Stage 5 feeds stage 1 — every analysis makes the next design more accurate
The short version
Plain EnglishThree ideas explain the whole system
No nutrition background needed. If you read only one part of this page, read this one — the rest of this page is the same story, in detail, on the real screens.
A nutrition standard is a set of windows a dish has to land inside
Doctors and clinical nutritionists write the rules: how many calories a serving may carry, how much of its energy may come from fat, how little sodium it may contain. Each rule is a range, not a target.
The example followed on this page carries eight such rules. A kidney-care meal or a diabetes-care meal carries its own set.
A standard — four of its eight rules
The blue band is the allowed window. The dish has to land inside every one of them — not on average, and not most of them.
Fix one number and another one breaks
Every ingredient carries dozens of nutrients at once, and most rules are written as a share of total energy. Add pasta and you add energy — so every share recalculates, including the ones you were happy with.
That is the whole difficulty. With eight rules pulling against each other, there is no order of single adjustments that lands them all. A nutritionist can spend a day on this and still miss.
The cook's first draft
Calories and protein are both a little low.
Add 10 g of pasta to fix the calories
marks where each value sat before. Calories fixed — but protein slipped from 17.27 to 17.21 — further out, and nobody touched the protein.
So the engine solves every rule at the same time — and then we prove it
Instead of adjusting one ingredient at a time, the engine builds thousands of versions of the same dish at once, scores each one against all eight rules together, keeps the best and recombines them — until a version satisfies every rule.
It also scores how far each version has drifted from what the cook actually designed, so the answer is still a dish someone meant to make rather than a spreadsheet solution.
Then a real batch is cooked, tasted by a panel, and measured by an independent laboratory — and the difference between prediction and measurement makes the next design more accurate.
What the engine returns
Same six ingredients, same dish — only the weights moved. All eight rules satisfied at once, in seconds.
Every gap between what was predicted and what the laboratory measured is stored, and corrects the data the next design draws on.
That is the whole idea. Everything below is the same story in detail — on the real production screens, with the numbers shown.
See it on the real systemOverview
Where Recipe Design sits
RD is one link in a chain that runs from clinical evidence to a finished product. It does not invent nutrition targets — it makes them buildable, turning a clinically authored standard into a manufacturable formulation.
01
Clinical Evidence
Physicians and clinical-nutrition specialists establish and prove each standard.
02
Nutri-Standard (NS)
Encodes it as machine-readable, person- and condition-specific criteria.
03
RD Core
Designs, converts and predicts recipes against a cross-verified database.
04
Nutri-Solution
Turns the result into real food, meals and products.
Hitting a nutritional target has always been slow, and expert-dependent
For three years MEDI.SOLA developed nutrition-tailored products the conventional way, and hit the same four walls every time.
Across three years of building nutrition-tailored products before RD
50–70% faster per product, with up to 80% fewer trial-and-error cycles.
Manual, expertise-dependent design
Quality rides on one person's skill and intuition, and is hard to reproduce.
Long development cycles
Each new product takes months of trial batches before anything can launch.
Deviation from the target
Static food tables ignore what changes during cooking, so finished products drift from their standard.
Hard to scale or personalize
Every variation restarts the manual effort, and know-how stays locked inside specific experts.
The engine
In detailInside EliteRecipe
This is the step no amount of spreadsheet work performs reliably. EliteRecipe is a genetic algorithm operating on ingredient proportions: from the cook’s own recipe it breeds thousands of weight variations, scores every one against every rule at once, keeps the best, and recombines them — generation after generation, until a formulation satisfies the whole standard.
It starts from the designer's recipe
The engine improves an intentional formulation rather than generating one from nothing, so the result stays a dish someone meant to make.
It searches the weight space, not the ingredient space
The ingredient set is fixed by the designer; the proportions are the free variables.
It optimizes all constraints jointly
A candidate scores 100.00 only when every criterion is satisfied at once. Partial solutions rank below.
It returns a set, not a point
Five near-equivalent candidates leave the final call to human judgement on taste, cost and manufacturability.
It returns production-ready weights
Rounded to 0.5 g rather than left as arbitrary decimals, so a prototype can be produced exactly.
The scoring function — why the dish still tastes like itself
A genetic algorithm will find a solution to eight simultaneous constraints. Whether that solution is still a dish anyone wants to eat depends entirely on how candidates are scored. This is where RD’s engine differs from a generic optimizer — and it is a deliberate design decision, not a side effect.
Term 1
Compliance
How completely the candidate satisfies every condition of the standard — each criterion contributing, with the size of any shortfall penalised.
Term 2
Fidelity to the original
How far the candidate has drifted from the designer's Genesis recipe. Large departures in the proportion of any ingredient are penalised even when they are nutritionally harmless.
The space of possible formulations
A compliance-only optimizer would return whichever point it reached first — often one that doubled a sauce or stripped out the ingredient carrying the dish’s character. Scoring fidelity alongside compliance picks the nearest compliant formulation instead.
The consequence is the point
For a standard with eight conditions there are typically many formulations that comply. By scoring fidelity alongside compliance, RD selects — among all compliant solutions — the one that stays closest to what the chef actually designed.
The practical test is the tasting panel: a formulation that passes on the first prototype, rather than one that complies on paper and fails on the palate.
Why the outcome is auditable
Every criterion carries an explicit numeric shortfall and every ingredient carries a verified nutrient profile, so each weight the engine changes can be attributed to the constraint that drove it. The engine is not a black box producing a number a nutritionist must take on trust — its output can be checked line by line, which is what makes it usable in a regulated food-manufacturing context.
Why this is hard to replicate
The optimizer alone is not the barrier to entry — any competent engineering team could build a solver. What cannot be assembled quickly is the layer beneath it: clinically authored standards, an ingredient database verified across four sources and corrected for cooking, and eight years of hospital evidence establishing that the standards are the right ones. The engine is only as useful as the constraints it is given, and those constraints are the research asset.
Patents filed
Real-Time Action Based Personalized Care System Adaptable to Any Prescription
US 19/549,277 · filed 02-2026
Platform-Based Method and Apparatus for Patient-Customized Nutritional Status Management
KR 10-2024-0113844 · filed 08-2024
How it works
In detailThe five steps, on the real production screens
For the operator, everything so far is one guided workflow. This section follows each step on the actual system. The first three design the recipe; the last two prove it — first on the palate, then in an accredited laboratory.
An illustrative example, not a commercial product. The recipe followed below was created solely to demonstrate how the system behaves. No commercial recipe, client formulation or proprietary ingredient data is disclosed. The ingredients, weights and nutritional figures shown are genuine outputs of the live production system operating on an illustrative input — a pasta dish designed to a Mediterranean-style standard carrying eight criteria.
A standard is machine-readable clinical criteria — not a guideline sheet
Every design begins with a standard, so it is worth seeing how one is made. A Nutri-Standard (NS) is a set of conditions authored by physicians and clinical-nutrition specialists, each traceable to the evidence that justifies it. Every row defines a measurement basis, a nutrient and a range.
Why the measurement basis matters
The dropdown that opens each row is easy to overlook and central to the whole system. These eight conditions use three different bases at once.
Per recipe
Calories, omega-3, ω3:ω6 ratio, sodium
What one serving delivers to the person eating it
% of calories
Carbohydrate, protein, fat
Macronutrient balance, independent of portion size
Per 100 g of food
Sugars
How labelling and regulatory limits are written
These bases are not interchangeable. A recipe can satisfy a per-serving limit and breach a per-100 g limit at the same time, and moving any ingredient weight changes all three at once. RD evaluates every basis against a single formulation simultaneously.
A standard is a logical expression, not a target list
Conditions combine with explicit AND / OR operators. Low Cholesterol requires cholesterol ≤ 20 mg per 100 g and saturated fat ≤ 1.5 g per 100 g and saturated fat ≤ 10 % of calories — all three must hold. High Protein is satisfied by any one of three alternatives, each on a different measurement basis. Real nutritional regulation is written this way; a system storing only simple thresholds cannot express it.
Most of the time, no authoring is needed
Standards accumulate into an asset — disease care, life stage, export regulation, product line. Each is a reusable, versioned object rather than a document, so a clinical revision is made once and propagates to every recipe that references it. A card reading “used in 6 recipes” tells the author exactly what a change would affect, and 15+ standards already carry the evidence base — so a new product usually starts by selecting rather than authoring.
Add ingredients and weights. The system judges the draft immediately
Six ingredients have been entered against the selected standard. As each weight is typed, RD recalculates the full nutritional profile and re-evaluates every criterion — the verdict is always on screen.
The row of cards is the important part. Each criterion reports not just pass or fail but by how much: calories are low by 3.61, protein by 0.23, omega-3 by 0.06 — so the designer knows exactly what has to move.
The data underneath
100,000+
verified nutrition data points
RD does not compute from a generic food table. Every ingredient record is cross-verified across four independent sources before the engine is allowed to use it.
Those points are standardized into 200+ pre-characterized ingredient blocks the engine assembles from, and each record carries a preparation state — the Type column on the screen above. Boiled, toasted and steamed are separate data points, not variants of one raw ingredient. Nutrient content changes substantially during cooking, and a design built on raw-ingredient tables drifts from the finished product no matter how good the optimizer is.
Nothing has been cooked yet
This verdict is produced at the design stage, from that verified database — before a sample is made, before any laboratory analysis, at no material cost.
Conventionally, the same finding arrives only after a trial batch.
Set the target calories and press Search. The engine returns scored candidates
Fixing the draft by hand is the step that consumes a nutritionist’s day. Raising protein changes the energy total, which shifts every criterion expressed as a percentage of energy — so each manual correction undoes another. With eight simultaneous conditions there is no sequence of single adjustments that reliably converges.
EliteRecipe solves them together. It takes a human recipe and a Nutri-Standard and returns formulations that satisfy every condition at once — automatically, in seconds.
The chef chooses — the engine does not
EliteRecipe returns a set of candidates, not a single answer, and RD does not auto-accept the highest score. The chef compares them on what a score cannot express — cost, sourcing, texture, how the dish will look on a plate — and selects the one to be made. The decision to build a prototype stays with the human; the engine only guarantees that every option already complies.
What the engine changed
No ingredient was added, removed or substituted. Only the weights moved.
| Ingredient | Step 2 | Step 3 | Change |
|---|---|---|---|
| Pasta | 100.0 g | 109.5 g | +9.5 % |
| Walnut | 3.5 g | 4.5 g | +28.6 % |
| Bolognese sauce | 29.5 g | 33.0 g | +11.9 % |
| Roasted red bell pepper | 19.5 g | 21.0 g | +7.7 % |
| Cranberry meatballs | 16.5 g | 16.5 g | unchanged |
| Cream sauce | 82.5 g | 90.0 g | +9.1 % |
| Total | 251.5 g | 274.5 g | +9.1 % |
The pattern is traceable rather than proportional. Omega-3 was the binding shortfall — 0.44 g against a 0.5 g minimum — and walnut is by far the recipe’s densest omega-3 source, so it rose 28.6 %, while the meatballs, carrying the heaviest saturated-fat load per gram, were held still. Each weight the engine chose can be traced to the constraint it was serving.
Why the panel's words are stored, not just its verdict
Appearance, smell, texture and taste are captured separately rather than as a single score, because they fail differently and are corrected differently. A low-sodium design that reads flat is a seasoning problem; one that reads watery is a formulation problem.
Every tasting record stays attached to the recipe version that produced it. Over hundreds of trials this becomes a body of evidence linking formulation decisions to sensory outcomes — sensory knowledge that would otherwise live in individual memory becomes an asset the organisation keeps.
Everything up to this point is prediction. The lab tests it
The final step tests the prediction against physical measurement by an independent accredited laboratory. The request is raised from the recipe itself, with an auto-generated code bound to the exact version — so a measured value can never be attached to the wrong recipe, a routine source of error when analysis is managed by spreadsheet and email.
When results arrive, the operator does not interpret them. Each measured value is checked against the condition it corresponds to, the source standard is named on every row, and the system issues a verdict. In this example, eight conditions are measured and eight pass.
A system that gets more accurate the more it is used
The more valuable output is the difference between what RD predicted and what the laboratory measured — recorded for every nutrient, on every analysis.
Read one recipe at a time, a deviation is noise. Read across hundreds, it is a signal about the database itself: an ingredient whose published composition is consistently off, a cooking loss the reference tables understate. Each finding is a correction made once and applied to every future design.
Conventional development treats laboratory analysis as a gate — pass and ship, fail and reformulate. RD treats it additionally as measurement of its own predictive accuracy.
Results & impact
Moving verification to the design stage changes the economics
Because nutrition is predicted and verified before anything is manufactured, the gains are practical and measurable — across speed, accuracy, cost and scale.
Development time for one product
50–70% faster per product, with up to 80% fewer trial-and-error cycles — measured across MEDI.SOLA’s own product development, before and after RD.
| Conventional | With Recipe Design | |
|---|---|---|
| When nutrition is known | After production and analysis | At the design stage |
| Correcting a miss | A new trial batch | A re-solve, in seconds |
| Development time | 6–8 months per product | 2–3 months |
| Trial-and-error cycles | Baseline | Up to 80 % fewer |
| Cost & material waste | Repeated trial batches and wasted ingredients | Fewer iterations; shortages, allergens and cost absorbed without breaking the design |
| Quality consistency | Depends on the individual expert | Same standard, same result — whoever operates it |
| A new variation | Restarts the manual effort | A re-solve against a new target |
| Working conditions | Repetitive, cognitively heavy manual calculation | Routine formulation work automated |
The compound effect matters more than any single row. Because a variation costs a re-solve rather than a fresh development project, product ranges that manual development could never justify — condition-specific, life-stage-specific, market-specific — become economically ordinary.
In the market
RD is not a prototype. It designs products on sale today
MEDI.SOLA is a food company, not a software vendor. RD was built because we needed it — and it is used every day to turn a nutrition standard into a finished product.
Medical-grade nutrition, out of the hospital and onto an everyday plate
MEDI.SOLA uses RD to design, develop and sell meal-type foods for people managing specific conditions — diabetes care, kidney care, dialysis, cancer care and hypertension care. They are designed to Korea’s MFDS meal-type standard for special medical purposes, and they are on sale to consumers today.
The same engine that designs to a clinical standard also produces everyday retail products
RD has powered nutrition-targeted product development for major clients including Starbucks and Samsung Welstory — designing recipes to defined nutritional targets and delivering them quickly, at commercial scale. That an engine built to a clinical standard also serves the country’s largest food and retail customers is the clearest evidence it has reached field-deployed maturity.
Validation & track record
8+ years
Of clinical trials with university hospital teams
25,000+
Clinical trial meals
37
Research papers published
9
Patents and utility models
17
Tailored meal plans
330
Menus in operation
Intervention trials with university hospital teams in Korea, across dyslipidemia, breast cancer, chronic kidney disease and hypertriglyceridemia — each reporting statistically significant improvement in its primary markers.
Explorations
The same engine, pointed at other problems
Everything above describes RD as we run it in production. Alongside it we build small prototypes to test where else the engine is useful — who else could design to a standard, and what the interface would have to look like for them.
These are proof-of-concept builds, not products. They are internal experiments used to test an idea, and they have changed substantially since these recordings were made. Nothing here is on sale, and nothing here should be read as a commitment to ship.
What comes next
Nutri-Solution
RD Core answers the question “does this recipe meet this standard?” Nutri-Solution answers the harder one: “build me food that meets these nutrient conditions, whatever they are.” Instead of selecting a pre-existing standard, the user combines individual nutrient criteria and the system transforms an ordinary recipe to fit them.
Design around any nutrient or condition
High-protein, low-sugar, low-sodium and disease-specific targets are all first-class design inputs — not presets someone has to have authored first.
Convert real recipes, not just calculate
An ordinary kimbap becomes a balanced high-protein version; a black-bean rice bowl is redesigned for diabetes care — by target and by nutrient, not by recipe.
Commercialize in one line
Manufacturing know-how is built into the design, so a Nutri-Solution recipe carries straight through to a real product, menu or meal plan.
Where we are
RD’s core engine is complete and in production today — it designs the products on sale above. Nutri-Solution extends it to design directly from nutrient criteria, and the full capability is scheduled for launch in October 2026.
In research
Today RD Core optimizes the proportions of an ingredient set the designer has chosen. The ongoing work is to let it also reason about the ingredient set itself — proposing substitutions and recommending candidates that would satisfy a standard the current set cannot reach. That turns the engine from one that refines a designer’s idea into one that helps form it.
Why we built it
Our vision has never been only about disease-specific diets. It is nutritional equality — health and wellbeing realized for people everywhere, not just those who can afford a dietitian or happen to be treated at a hospital that offers one.
Eight years of work with university hospitals, and 25,000+ clinical trial meals, proved that nutrition designed this precisely changes health outcomes. What remained unproven was whether that standard of care could ever be supplied — at the scale equality actually requires. Recipe Design is the answer to that question.
Contact
Talk to the team that built it
Recipe Design is in production at MEDI.SOLA today. If you develop food to a nutritional target — as a manufacturer, a caterer, a retailer or a clinical team — we would like to hear what you are working on.
In person
Meet us at SIAL Paris 2026, Paris Nord Villepinte, 17–21 October 2026, where Recipe Design is shown as a SIAL Innovation Selection 2026 in the Equipment & Technology category.