Home Chef: meal planning as a multidimensional optimisation

A household describes itself in plain language; Home Chef returns a week of meals that hits a grocery budget, meets everyone’s calories, respects allergies, stays varied, and wastes little — all at once.

AAIC built the engine; the interface in these recordings is a technical demonstrator of it, not a production UI. A number of functions have been hidden under agreement with the customer. The data in the demonstrator — product catalogues, prices, recipes — is placeholder material; the production system connects to the customer’s own data infrastructure.

The problem

Feeding a family well and cheaply is an optimisation problem that most people solve by hand, badly. The constraints pull against each other: cheaper baskets drift toward the same few starches; hitting everyone’s calories invites waste; an allergy removes whole shelves of the shop; variety fights ingredient reuse, and reuse fights variety. Most tools fix one dimension and let the others slide. Home Chef treats the week as one problem and balances every objective together.

The intake

A household writes freely — how many adults and children, who has an allergy, who eats lunch at school on weekdays, a weekly grocery budget, a leaning toward certain cuisines, a calorie target. Each message is parsed into structured constraints; Home Chef asks only for what is still missing. Nothing is a form field.

Fig. 1The intake conversation. Plain-language answers are parsed into structured constraints — household composition, allergies, school-lunch days, cuisine preferences, budget, and calorie target. The optimiser recomputes in the background as each answer arrives.

The data

The demonstrator runs on placeholder data: a synthetic catalogue of 63 products modelled loosely on a Yerevan supermarket, each with a package size, a dram price, energy and protein density, and allergens; and 40 recipes across six cuisines, each mapping its ingredients back to those products. The production system connects to the customer’s own product database and recipe library, which are considerably larger and structured differently. The principle — that ingredients resolve to purchasable packages so the plan can be costed exactly and its waste measured, not estimated — is the same in both.

How the plan is scored

A plan assigns one recipe to every meal eaten at home across the week. Five objectives — cost, nutrition, cook time, variety, and waste — are each expressed as a normalised score, and the solver minimises their weighted sum. The weights come from the conversation: a stated budget raises the cost weight; a calorie target raises nutrition. The five are traded continuously against one another, so no single objective is ever simply ignored. The production system uses a richer objective function with additional terms not shown here.

Portions are not fixed. Each meal is scaled so the servings cooked meet each diner’s calorie share for that slot — an adult is served more than a child, a lighter dish is cooked in greater quantity than a rich one. This is what lets nutrition be met exactly, and it moves the real lever onto cost: how to deliver those calories as cheaply as possible, in whole purchasable packages, with as little left over as possible. Nutritional modelling in the production system goes beyond simple calorie counting.

Allergies, dietary restrictions, cuisine category, and who is home for each meal are hard constraints — a recipe that violates any of them is never a candidate. The five objectives are soft, traded against one another by the weighted sum.

Fig. 2The plan across five dimensions. A radar of the five objective scores, the basket by food category in dram, the calorie curve against target, cuisine spread, kitchen time, package efficiency, and the household’s constraint grid — the state of the plan on every axis at once.

The algorithm

The demonstrator uses a greedy construction followed by coordinate-descent refinement: the week is filled slot by slot, each time choosing the recipe with the lowest marginal weighted score given what is already in the plan, then each slot is revisited in turn until no single swap improves the total. Marginal scoring is what makes the basket cheap — an ingredient already bought for one meal is close to free in the next, so reuse emerges without being explicitly required. The production solver uses a more involved search strategy not described here.

Because every candidate is scored on the same contributions, any single decision can be read: why this recipe was chosen, and how the runners-up compare on each axis.

Fig. 3Watching the solver. The objective score falls across construction and settles through refinement, with each swap named. Adjusting an objective’s weight re-solves the whole week live; shifting the budget weight trades variety and waste, and the plan reorders visibly against a before/after readout.

The plan

The output is a week as a calendar — breakfast, lunch and dinner per day, sized to who is home for each meal, with school-lunch days left open. Each entry opens to its recipe, per-serving nutrition and cost, and the scoring that selected it over the alternatives. The grocery list is aggregated into whole packages with a single dram total, ready to shop from.

A full week re-solves in milliseconds. This is what allows the objective weights to be dragged interactively and the plan to re-form in place, with no perceptible delay.

Fig. 4The week and its reasoning. The seven-day calendar and a package-level shopping list. Opening a meal reveals the candidate matrix — every alternative scored on the five objectives, the chosen recipe marked, the losers’ weak axes visible in the colour.