Concrete Mixing is a Search Problem: How We Put Open-Source Bayesian Optimization to Work

Cement production accounts for approximately 8 percent of global CO2 emissions, according to the Global Cement and Concrete Association, making it one of the highest-leverage material substitution targets in industrial decarbonization (GCCA, 2023). The problem is not that better mix designs do not exist. The problem is that the industry has almost no practical way to find them. 

Concrete has a feedback loop problem. Mix a new recipe today and you will not know its true strength until you crush a test cylinder 28 days from now. One recipe, one month, one data point. That single constraint quietly governs the whole industry: testing is so slow that producers standardize on a handful of proven designs and stop exploring, even though the space of possible mixes, cement, fly ash, slag, water, admixtures, aggregates, is effectively infinite and almost entirely unmapped. 

Framed that way, concrete is not a materials problem. It is a search problem with an expensive oracle. And search problems with expensive oracles are exactly what Bayesian optimization was built for. This post walks through how we deployed an open source model for concrete mix design, the engineering details that mattered, and one sharp edge worth knowing about if you deploy it yourself. 

The foundation is a Gaussian Process regressor that predicts the full compressive strength curve of a mix, from day 0 to day 28, given its composition. If you have not worked with GPs: they are probabilistic models that come with a principled uncertainty estimate attached to every prediction, which matters enormously here. A point estimate tells you a mix might reach 5,000 psi. A calibrated distribution tells you how confident you should be, and confidence is what you need before you strip formwork out from under a floor people will stand on. 

The model takes nine composition variables (cement, fly ash, slag, water, HRWR admixture, fine and coarse aggregate, material source, temperature) plus curing time. Its training set is modest by deep learning standards, 123 lab verified mixes with strength measured at five curing ages, roughly 500 measurements in total, and that is part of the story: with the right inductive biases, physical problems do not always need internet scale data. Held out accuracy lands around R squared 0.94, with uncertainty bands that widen honestly in regions the data does not cover. 

A second, simpler model handles sustainability: a linear map from composition to embodied carbon, built from per ingredient emission factors. Cement dominates it, at roughly 0.8 tons of CO2 per ton of cement produced, which is why every serious low carbon strategy in this industry comes down to one move: replace clinker with something else without giving up strength.

Here is the deployment lesson we would want any other team to have before running this model. The strength model trains on targets divided by their maximum value, roughly 16,000 psi, so every posterior it returns lives on a zero to one scale. The unscaling contract is real and load bearing, but it is documented in the project's test suite rather than its README. Run the model naively and your predictions come back three orders of magnitude off. Worse, if you wire the optimizer to those raw outputs, it does not crash. It runs happily and optimizes noise, and every downstream chart looks plausible. 

The fix is two lines: multiply posterior means and standard deviations by the scale factor, and divide the optimizer's reference point by it. The lesson is more general than concrete: when you adopt an open model, the contract you must honor is wherever the authors encoded it, and the test suite is often the truest documentation there is.

When you adopt an open model, the contract you must honor is wherever the authors encoded it. The test suite is often the truest documentation there is. 

With fast, trustworthy prediction in place, search becomes affordable. We run multi objective Bayesian optimization, specifically qLog Noisy Expected Hyper volume Improvement over the GP posteriors, hunting for mixes that maximize early strength and 28 day strength while minimizing embodied carbon, all under real production constraints: floors on the water to binder ratio, bounds on every ingredient, batch feasibility. 

The intuition, if the function name is unfamiliar: the optimizer maintains a frontier of the best trade-offs found so far, and each round proposes the candidates most likely to push that frontier outward, using the model's own uncertainty to balance exploring unknown regions against exploiting known good ones. Every proposal costs a second of compute instead of a month of curing. That is the entire trick. The 28 day oracle still exists, but you consult it last, to verify winners, not first, to grope through the dark. 

One optimization run proposed five candidate mixes on the strength versus carbon frontier. The best of them replaces 90 percent of the cement with fly ash and slag, both industrial byproducts: 52 kg of cement, 149 kg of fly ash, 310 kg of slag per cubic meter, at a water to binder ratio of 0.20. Predicted strength is 10,327 psi at 28 days, against roughly 8,400 for a conventional full cement design. Embodied carbon is 106 kg of CO2 per cubic meter, against 387. 

Stronger and 73 percent lower carbon, simultaneously. No compromise between the two. The result sits in a corner of the design space that intuition never visits because each experiment costs a month. 

The interesting question is why nobody pours this mix already, and the answer is that it sits in a corner of the design space that intuition never visits. A human mix designer iterates locally from recipes they trust, because each experiment costs a month. An optimizer with a one second oracle has no such loyalty. It goes where the math points. 

A model that only lives in a notebook changes nothing, so the demonstration surfaces matter as much as the model. We built three. 

A mix designer exposes the raw capability: composition sliders, with the GP re-evaluated live on every change, drawing the predicted strength curve inside its uncertainty band next to a Pareto view of all 123 lab mixes and the AI proposed candidates. 

A live batch monitor moves prediction to production time. As a simulated batch loads ingredient by ingredient, the model re-predicts the strength curve of that specific truckload with every kilogram, and you can watch the forecast resolve from wide uncertainty to a confident curve as the drum fills. The prediction is cheap enough to run continuously, which turns quality control from an after the fact test into a property of the batch itself. 

A narrated Pour Day sequence follows one batch through its life, batch, ticket, pour, and cure, compressing 28 days into 80 seconds. It makes the operational point that numbers alone do not: construction schedules do not wait on concrete, they wait on proof about concrete. Codes default to stripping formwork at day 7 and full confidence at day 28 because nobody knows better sooner. With a verified prediction, the same physics clears the same gates at day 1.5 and day 2.5. Certainty, not chemistry, is where the schedule compression comes from. 

One honest note that belongs in any technical account: a plain full cement mix genuinely develops early strength faster than a high substitution mix. The win is not magic. It is knowing, batch by batch, exactly where you stand on the curve.

Everything above runs inside Hyper, our deployment layer, the same infrastructure we use to run language model systems. Hyper treats a model as a workload: the shell that schedules jobs, serves surfaces, and routes predictions does not care whether the thing behind the API generates tokens or forecasts compressive strength. In this demonstration the model selector simply reads BOxCrete GP where it would otherwise read the name of a language model. 

That is also the point of building on open source. The model and its training data are MIT licensed, and we think that is the future of physical AI: models as open commodities that any organization can own, customize to its own materials and climate, and harden for infrastructure it actually depends on, rather than intelligence rented through an API. 

Concrete makes the case well because concrete is stubbornly local. Aggregates change chemistry quarry by quarry, ash changes with the power plant upwind, curing changes with climate. A frozen recipe from someone else's lab is worth little. An owned search loop, retrained on your materials, is worth a great deal. 

FastAPI serving the models. PyTorch with BoTorch and GPyTorch for the Gaussian Process and the acquisition function. Vanilla JavaScript front end, no framework, no build step. Headless Chrome for verification. The optimization model and dataset are open source under MIT. 

The model, anyone can download. The capability, running it against your materials, your plants, and your constraints is what we build. 

This is a live demonstration built on the Hyper Anthologies ecosystem. If you wish to request one for your business fit, please reach out to us at [email protected], or visit our website. 

CodeNinja · Hyper · System of Real World Context