Recipe, blend & formulation optimisation (feed, food, concrete, fuels)

Feed mills, ready-mix plants, food producers and fuel blenders must hit a specification with the cheapest (or lowest-CO2) combination of raw materials whose prices and quality fluctuate daily. Classic linear programming has done this for decades; AI adds ML models that predict real mix properties (digestibility, concrete strength, blend octane), forecast prices and keep the solver continuously re-optimising. Typical benefit: lower raw-material cost at the same quality and a documented CO2 reduction.

Problem & value

• Today: a nutritionist, mix designer or blending planner maintains a matrix of ingredients vs. constraints in a spreadsheet or formulation package and updates it when prices or analyses change. Safety margins ("overformulation") are large because actual raw-material variability is not modelled, so cost and CO2 are left on the table.
• AI value: (1) solver finds the global least-cost mix in seconds across hundreds of ingredients; (2) ML replaces fixed table values with predicted, batch-specific properties (e.g. from NIR scans or curing data) so margins can shrink; (3) price forecasts and what-if analysis drive purchasing; (4) multi-objective trade-offs (cost vs. CO2 vs. quality risk).
• Cost leverage: raw materials dominate compound-feed cost. Industry reports describe ration platforms recalculating continuously as prices and inventory change [2]. Published savings differ widely by plant and baseline; measure your own against a frozen reference formula rather than relying on marketing figures.
• Decarbonisation: cement clinker is the main CO2 driver in concrete, so mix design with supplementary cementitious materials (slag, fly ash, calcined clay, limestone filler) under strength and durability limits is a primary lever for EPD-driven (environmental product declaration) procurement.

Variants

• Animal feed (compound, premix, pet food): least-cost formulation with nutrient matrices, enzyme and amino-acid matrix values, additive limits, pellet quality.
• Human food and beverage: recipe cost optimisation, allergen and label constraints, reformulation (sugar/salt/fat reduction), ingredient substitution during supply shocks. Flavour or texture discovery belongs to SCI-014.
• Ready-mix concrete and asphalt: mix design under EN 206 exposure and strength classes, moisture-corrected batching, CO2-minimised designs.
• Fuels and chemicals blending: refinery and terminal blending (gasoline, diesel, biofuel blend mandates), lubricants, fertiliser blends.

How it works

1. ingredient data (nutrient/property matrix, price, stock, supplier limits) + lab/NIR analyses + production feedback
2. property models (ML: predicted digestibility, strength, viscosity ± uncertainty)
3. constraint model (specs, legal limits, plant limits, inclusion min/max)
4. solver (LP / MILP / robust or chance-constrained; cost, CO2e as objectives)
5. recipe proposal + shadow prices + what-if
6. human release (nutritionist / mix designer / QA)
7. batching system (PLC / dosing)
8. actual-vs-predicted feedback loop

• Core is a solver, not an LLM. Least-cost formulation is a linear program; real constraints (batch sizes, ingredient on/off, minimum inclusion) make it a MILP. ML sits around the solver as property predictor and price forecaster.
• Robust optimisation: instead of a fixed nutrient value, use the distribution of lab results and require the spec to hold with e.g. 95% probability, which allows cheaper margins with controlled risk.
• LLM role (optional): what-if copilot (OPT-018) and supplier-certificate extraction; it never sets the final recipe.
• Human-in-the-loop: a qualified nutritionist or mix designer approves new formulas and constraint changes; automatic re-optimisation is typically limited to approved ingredient sets and tolerance bands.

Data preparation

You need an ingredient matrix (nutrient or property values, prices, stock, supplier limits), recipe and specification history, lab and NIR analyses, and batching records. In an SMB these sit in the ERP, in the formulation software, in Excel sheets of the nutritionist or mix designer, in supplier certificates (often PDFs or paper) and in lab reports. Typical gaps: ingredient names that differ between purchasing, lab and recipe, missing analysis dates, matrix values without version or source, undocumented tolerance rules, and lab values that were never linked to the batch that used the ingredient.

Preparation steps: 1. Build one clean ingredient master with unique IDs and synonyms (PREP-015) and a version history for matrix values. 2. Restructure spreadsheets into tidy tables (PREP-011) and fix units. 3. Extract certificate data from PDFs and scans (PREP-006, DOC-014). 4. Link batches to ingredient lots, lab results and actual-versus-predicted outcomes (PREP-020). 5. Write down constraints and legal limits as explicit rules with owners (PREP-012). 6. Keep a holdout set of past recipes for checks (PREP-018).

A solver needs few records but trustworthy ones; plan 30-40% of effort for cleaning the master data and constraints. See also DATA-003 and GUIDE-003.

Implementation paths

Which path for whom

• smb: A, because mature formulation packages with ERP and batching integration exist at SMB prices and the process (least-cost recipe under specs) is standard.
• enterprise: B, because many plants, custom specs and links to purchasing and ERP data need a solver and property models under own control.
• developer: C, because HiGHS, OR-Tools, Pyomo and BoTorch cover the full stack on a CPU server (HW1).

Path A — Buy (recommended for most SMBs)

• Feed: established formulation and plant-ERP packages such as AFOS, MIXIT, Datacor feed ERP, Format Solutions/Adifo-style packages and nutrition-company platforms (Adisseo, dsm-firmenich and Cargill/Trouw Nutrition offer digital formulation and matrix services; Trouw Nutrition and Adisseo are EU-rooted) [1][2][3]. Newer cloud entrants advertise AI-assisted continuous re-optimisation [3].
• Concrete: batching-plant ERPs (e.g. Command Alkon); EU suppliers often bundle with plant control.
• Fuels/chemicals: blend optimisation within refinery planning suites (AspenTech PIMS, Honeywell and similar LP planners).
• Choose A when: product range is standard, an ERP integration exists, and you lack data-science staff. Ask for: matrix versioning, audit trail, CO2e per recipe, API.

Path B — Build on cloud APIs

• Solver: commercial MILP solvers (Gurobi, FICO Xpress, Hexaly [EU], CPLEX) in cloud runtimes or Google OR-Tools / HiGHS as free engines [4][5].
• ML property models: gradient boosting or Gaussian-process models on lab/process data in a managed ML service in an EU region (Azure ML, AWS SageMaker Frankfurt, Vertex AI EU, or EU providers like OVHcloud, STACKIT, IONOS).
• LLM layer: a frontier model with tool calling for what-if questions that generate and run solver models (OPT-018).
• Choose B when: you need custom specs, many plants, or a link to purchasing and ERP data.

Path C — Self-host (open source)

• Solvers/modelling: HiGHS, OR-Tools (CP-SAT, GLOP), SCIP, Pyomo, PuLP, CVXPY, and BoTorch/Optuna for black-box blend search [4][5].
• ML: scikit-learn, LightGBM, XGBoost, GPyTorch/BoTorch for uncertainty-aware property models.
• Hardware: HW1 (CPU server) is sufficient; solving a feed formula takes seconds. Only add an LLM (HW2) for the copilot layer.

Path D — Custom training

Worthwhile when raw-material variability is large and property predictions drive margin: train site-specific models (NIR spectra to nutrient content, mix composition and age to strength, in-vitro digestibility surrogates). Needs hundreds to thousands of paired samples and a clean validation set. Bayesian optimisation helps when each physical trial is expensive (concrete cylinders, animal trials).

State of the art (2026)

• Hybrid "predict then optimise": ML property models feeding MILP or robust optimisation are the standard pattern; Bayesian optimisation and active learning decide which physical trial to run next.
• Low-carbon concrete: ML-guided SCM designs validated against EN 206; accuracy depends on local material consistency.
• Limits and failure modes: garbage-in (stale nutrient matrices, wrong moisture), extrapolation outside the training range of property models, degenerate LP solutions that jump between near-equivalent recipes (cause plant disruption: add stability penalties), ignoring physical constraints such as pelleting or workability, and interactions (e.g. enzyme effects) that fixed matrix values only approximate.

Shared resources & combinations

• Solver + tabular ML stack shared with OPT-005 (inventory), OPT-002 (production scheduling) and OPT-008 (S&OP); property prediction shares sensor and lab data pipelines with OPT-009 and OPT-038.
• OPT-018 supplies the natural-language modelling layer; SCI-014 and SCI-003 feed new candidate ingredients or formulations discovered by materials/formulation AI.

Effort, cost & KPIs

• Path A: weeks to a few months (matrix and ERP set-up); licence per plant or user.
• Path B/C: 3-6 months for a first plant; solvers are cheap or free, data work dominates.
• KPIs: raw-material cost per tonne/m3 vs. frozen baseline, CO2e per unit, specification giveaway (overformulation margin), out-of-spec batches, recipe change frequency, forecast error of property models, time to re-formulate after a price shock.

People & change

Involve management for the margin goal, the head of production or nutrition (department-lead) as process owner, and the nutritionists, mix designers and QA staff who release recipes (end-users). Include purchasing and the data owners of the ERP and lab system early, because ingredient master data decide the quality. Legal or compliance staff check feed, food or construction-material law (labelling, declared values); suppliers must deliver certificates in usable form. IT handles ERP and batching links.

Works council: depends. The recipe optimiser itself does not monitor staff, but ERP or batching logs that record who approved which recipe can be objectively suited for monitoring (section 87(1) no. 6 BetrVG, BAG case law). Inform an existing works council in good time under section 90(1) no. 3; for small firms without one, simply talk to the team.

Data protection: mostly no personal data; a DPO check is only needed for user logs. AI literacy: support the specialists with a short training on solver outputs, shadow prices and uncertainty (GUIDE-006). Start with one product line in shadow mode beside the current recipe, then compare cost and quality (GUIDE-009). Typical concern: "the machine overrides my expertise." Address by keeping the expert's release, tolerance bands and a visible reason for each change (GUIDE-008, GUIDE-011).

Risks, regulation & compliance

• EU AI Act: minimal risk. Not an Annex III use; only the AI literacy duty (Art. 4) applies. Becomes safety-relevant mainly when embedded in regulated product control (e.g. fuel quality, structural concrete): then product law, not the AI Act, governs [6].
• GDPR: generally no personal data (material and process data); only user accounts and audit logs.
• Sector rules: EU feed law (Regulation (EC) 767/2009 on marketing and labelling, Regulation (EC) 183/2005 on feed hygiene, additive authorisations and maximum contaminant levels) is a hard constraint set the model must encode; food allergen and labelling rules (Regulation (EU) 1169/2011); EN 206 and national supplements for concrete; EN 228/EN 590 fuel specifications and RED III blending mandates [7].
• Risks: spec breach from wrong data (animal health, structural safety), vendor lock-in on matrices, trade-secret recipes (restrict vendor reuse), over-trust in LLM output.
• Mitigations: hard legal limits as non-relaxable constraints, QA sign-off, version-controlled matrices, continuous actual-vs-predicted monitoring, back-testing before go-live.

Getting started

1. Freeze a baseline: last 3 months of recipes, costs, spec results and giveaway per product.
2. Clean the ingredient matrix: units, moisture basis, version, analysis dates, supplier variability.
3. Reproduce current formulas with an LP solver (HiGHS/OR-Tools or a commercial package); validate against the nutritionist or mix designer.
4. Add variability (robust constraints) and one ML property model where lab data exist; run in shadow mode for a few weeks.
5. Release approved ingredient sets for automatic re-optimisation within tolerance bands; track KPIs monthly.

Sources

1. Engormix — Comparative study on feed formulation software — https://en.engormix.com/feed-machinery/feed-formulation/comparative-study-feed-formulation_a42760/
2. Cattle Daily — New feed technologies for cattle 2026 — https://cattledaily.com/new-feed-technologies-for-cattle/
3. DietForge — AI-powered cloud feed formulation platform — https://www.dietforge.ai/
4. Google OR-Tools — https://developers.google.com/optimization
5. HiGHS open-source solver — https://github.com/ERGO-Code/HiGHS
6. Regulation (EU) 2024/1689 (AI Act) — https://eur-lex.europa.eu/eli/reg/2024/1689/oj
7. Regulation (EC) No 767/2009 on the placing on the market and use of feed — https://eur-lex.europa.eu/eli/reg/2009/767/oj
8. Datacor — ERP & formulation software for animal feed manufacturing — https://www.datacor.com/solutions/animal-feed
9. AFOS — Feed formulation software — https://www.animalfeedsoftware.com/