Applied machine learning · Process R&D client

ML-Driven Design of Experiments & Digital Twin

Process and formulation R&D traditionally advances by running batches and seeing what happens. This platform lets engineers plan experiments against a model instead: propose candidate conditions, predict outcomes with quantified uncertainty, and spend physical batches only where the model is genuinely unsure.

The problem

Trial-and-error experimentation is slow and expensive: each batch consumes material, equipment time and operator attention, and the search space of process conditions and formulations is far larger than any experimental budget.

The client needed two things at once — predictive models good enough to trust, and an application disciplined enough to deploy in an industrial setting, with real users, access control and an audit trail.

What I built

  • A standalone Python modelling service (FastAPI) implementing the design-of-experiments and surrogate modelling logic, kept deliberately separate from the application layer so the science can evolve independently.
  • Domain modules on the enterprise AI kernel — schema design, shared types, workflow and authorization integration.
  • The experiment planning and analysis interface in Next.js: candidate design, run tracking, prediction views with uncertainty, and comparison against measured outcomes.
  • The roughly 40-page administration console, and the production-hardening work — retention policies, least-privilege service accounts, deployment and backup.
  • A two-round migration of the legacy standalone application onto the kernel, without losing the modelling behaviour the client already relied on.

Modelling, and honesty about uncertainty

The headline result is a soft sensor for a distillation process — inferring a quantity that is expensive or slow to measure directly from signals that are cheap and continuous.

On three held-out runs it reached an R² of 0.81, 0.80 and 0.67, with mean absolute error between 0.04 and 0.07 mol/mol. The third run is visibly the weakest, and the interface says so rather than hiding it.

Just as important as accuracy is calibration: the 90% prediction intervals covered 94–97% of held-out measurements, so the model is slightly conservative rather than overconfident. For an engineer deciding whether to trust a prediction or run the batch anyway, that is the number that matters.

Outcome

Shipped through production hardening, with the legacy application fully migrated onto the platform. Because it is built on the kernel, every model run, parameter change and prediction inherits the same authorization, audit and observability guarantees as the rest of the client's AI estate.

Stack

Note: this case study is deliberately written without client names, product names or customer data. The model metrics quoted here are logged evaluation results on held-out runs, not estimates.