AI + Biology · Field note

Digital Twins for Biological Cultivation

By Orr Biologicals · August 9, 2026

A twin is not a dashboard. It is a forward simulation of the biology you control — and on a $9 microcontroller, that changes what automation is allowed to do.

Key facts
  • A digital twin is a model of the living system that can be simulated forward in time
  • The twin is explicit: named equations with learned parameters, not an unreadable black box
  • Every proposed control action is simulated before it is applied; predicted harm blocks it
  • Twins are calibrated per device and per strain — defaults are starting points, not truth

The term digital twin has been attached to everything from building dashboards to industrial fantasy. Strip the marketing away and a digital twin is one specific thing: a model of a physical system that you can simulate forward in time, fast enough to ask "what happens if I do X?" before doing it. In biological cultivation that question is worth asking constantly, because the system is alive, the answer changes every hour, and the cost of a wrong answer is a culture.

In AlgaePhyte's photobioreactor, the twin is built from biology that has been studied for decades. Growth is modeled as the product of independent factors, each with a published form: Droop's cell-quota kinetics for nutrient uptake, Steele's curve for the light response with its photoinhibition penalty above the optimum, Beer-Lambert attenuation for self-shading in a dense culture, bell-shaped temperature and pH responses, and a dissolved-oxygen inhibition term for the supersaturated conditions a bright reactor creates. Multiply the factors, and the twin produces a growth-rate forecast — not a number a spreadsheet could guess, but a consequence of the biology.

In Mycophyte's chamber, the same idea wears different clothes. The dynamics there are hygrometric and thermal rather than photosynthetic: humidity decays toward ambient air, fans strip moisture and CO₂ together, foggers add the first while doing nothing for the second. The twin models those couplings — dew point, ventilation exchange rates, the temperature drop that evaporation causes — and uses them to answer the chamber's actual question: if I run the fan for ninety seconds, do I crash humidity past the dew point at dawn?

The design rule we hold to is that the twin must be explicit. Its equations have names you can look up and parameters you can inspect. That is a deliberate rejection of the "throw a neural net at it" approach to control. A black-box model can be right and still be useless, because when it is wrong there is no way to know which term is lying. An explicit twin is debuggable: if the forecast is bad, you can isolate whether the humidity decay rate or the COâ‚‚ respiration term is off, correct it, and move on.

None of this needs a data center. The twin runs on a Raspberry Pi Zero in the reactor and on an RP2040-class board in the chamber, stepping the simulation every few seconds against fresh sensor readings. The models are small by design — a few hundred kilobytes — which is what makes federated learning over MQTT practical, because the thing that travels between devices is the twin's tuned parameters, not anyone's raw data.

The honest caveat: a twin is a model, and a model is a simplification. The open simulations on the AlgaePhyte and Mycophyte pages run these same equations so you can feel how they respond — but a simulation is not a validation. The only validation is the culture itself, which is why every device logs everything and publishes nothing without permission.

All articles See the architecture