Why we are building biology as code
Biosimulant is an attempt to make biological computation portable, inspectable, and composable without forcing every model into one standard.
On this page
Biology already has an extraordinary amount of executable knowledge. It lives in pathway models, neural models, cell models, learned representations, molecular tools, notebooks, native simulators, and scripts written for one experiment.
The problem is not an absence of models. It is the distance between finding a model and using it as a dependable part of new work.
We are building Biosimulant to shorten that distance.
Biological software should keep its specialization
Standards matter. SBML, CellML, NeuroML, ONNX, and domain-specific file formats make scientific work portable inside their communities. But no single standard describes every relevant computation.
Biosimulant does not ask an SBML pathway to become an ONNX graph, or a learned structure model to pretend it is a differential equation. Instead, each model keeps its native implementation and joins a shared runtime contract at the boundary.
That boundary names inputs and outputs, declares units, defines how time advances, and records artifacts. The model remains specialized. The experiment becomes composable.
specialized model
│
▼
typed ports + runtime lifecycle + artifacts
│
▼
composable labCode is a medium for scientific accountability
“Biology as code” is not a claim that biology is simple or fully reducible to software. It is a commitment to properties that software engineering has learned to make practical:
- versioned inputs and dependencies;
- explicit interfaces;
- automated tests;
- reviewable changes;
- repeatable execution;
- structured outputs;
- traceable failures.
Those properties are valuable precisely because biological models are heterogeneous and provisional. A hypothesis can change. A solver can improve. A new benchmark can reveal that a model is outside its useful domain. Code gives those changes a history.
Local work should remain first-class
The biosimulant Python runtime and CLI are open source under the MIT license.
They run on a local machine, in CI, or anywhere the required Python environment
can run.
The hosted platform adds durable managed jobs, GPU execution, artifacts, provenance, sharing, and webhooks. It does not redefine the scientific contract, and local execution does not silently move to the cloud.
This separation matters. A researcher should be able to inspect the runtime, write a module, and run a lab without depending on a hosted account. A team should also be able to take that same work into managed infrastructure when scale, collaboration, or accelerators require it.
Humans and agents need the same legible system
Scientific software is increasingly written and operated with coding agents. That makes explicit contracts more, not less, important.
An agent can only safely modify a workflow when it can discover:
- which models exist;
- which ports and units they expose;
- which package versions are in use;
- which tests define acceptable behavior;
- which artifacts prove what happened.
A human reviewer needs the same information. The interface that makes a model agent-operable is also the interface that makes it easier to inspect.
A lab is the unit of explanation
Individual models remain important, but many useful questions live in the connections between them. Biosimulant represents those connections as a lab: a versionable graph of model instances, parameters, wiring, runtime settings, and external inputs and outputs.
The lab is both executable and explanatory. It can show which model produced a signal, which downstream model consumed it, and which configuration controlled the run.
Nested labs allow a reviewed subgraph to become a reusable component with its own external ports. This is how larger simulations can grow without turning every connection into global wiring.
Open infrastructure creates room for many kinds of biology
We do not expect one team to implement every useful biological model. The runtime is deliberately small so domain packages can evolve independently:
- molecular and structural models;
- systems-biology pathways;
- physiological and organ models;
- neural and cellular simulations;
- ecological and population dynamics;
- custom models that do not fit an existing category.
The long-term value comes from a model being runnable, inspectable, and connectable even when its implementation comes from somewhere else.
That is why we are building Biosimulant: not as one definitive model of life, but as infrastructure for making more of biological computation usable together.
