A compiler for biological engineering. Describe experiments, check protocols, and create beautiful documents, in Python or Lab.
Lab helps scientists describe the biological result they want, the constraints that must hold, and the evidence needed to accept it. Checking a protocol and producing a clear document for someone to read, share, and use at the bench are central goals. Where automation is useful, the compiler can also prepare supported work for available equipment.
The compiler accepts an experiment in two forms, and both produce the same checked module, so neither is a wrapper over the other and nothing downstream can tell them apart.
Python is where most work starts, because it is the language a laboratory already has code in. Typed lab.sbol builders keep biological designs separate from explicit build and buy declarations, materialize and validate ordinary pySBOL3 documents during compilation, and compose with LOICA genetic networks. The lab package adds what neither standard has a vocabulary for: artifact provenance, the acceptance claims a build is judged on, and the durable workflows that carry it out.
Lab is the native language, the one the checker's vocabulary is built around. It states the same designs, claims, and workflows in the fewest words, and it is what the language documentation teaches.
SBOL is not a third way in. It is the vocabulary designs are written and exchanged in, which both frontends speak: roles carry ontology terms, so a design can arrive from a registry and leave for one.
Lab is working toward a world in which laboratory work is portable, inspectable, and reliable across manual benches, automation, and cloud labs.
Today, protocols commonly entangle scientific intent with site-specific procedures. Lab separates them. A program describes biological designs, physical materials, workflows, and acceptance criteria. The compiler checks their relationships; document generation presents the work clearly to a human reader. Facility planning and automation optionally specialize that description against the capabilities, policies, inventory, and hardware of a selected laboratory.
One biological program should be adaptable to many valid execution environments without erasing what the scientist meant.
Lab treats protocol checking, document generation, and automation as related uses of one scientific description:
- the type system models biological artifacts, physical materials, durable effects, and evidence;
- two frontends, Python and Lab, lower to one checked module, which is the portable boundary nothing downstream reaches behind;
- LAIR, the Lab Automation Intermediate Representation, preserves meaning as programs are progressively lowered from portable intent to method-selected procedures and facility-bound device operations;
- the compiler checks types, action contracts, and material ownership while keeping specialization decisions inspectable;
- document generation separates content from typography; current facility builds produce typeset operator documents and manual run sheets as editable Typst sources and PDFs;
- a reviewed runtime validates frozen facility plans, narrates them in dry-run, executes them in simulation or supported live modes, resumes from a plan-bound ledger, and writes resulting inventory provenance.
Modeling these ideas in a type system, rather than in a library's conventions, lets the toolchain reason about concerns that ordinary APIs tend to hide: sample identity and custody, consumable materials, non-repeatable actions, probabilistic results, and evidence-backed acceptance. Writing in Python does not give any of that up, because the Python frontend is checked by the same compiler rather than layered over it.
Lab is an early prototype. The current toolchain accepts both frontends, parses and checks representative biological designs and workflows, emits typed portable module IR, verifies action contracts and affine material flow, refines scientific intent into canonical Procedures, selects Methods and exact facility resources together, and applies the result to verifier-valid Allocated LAIR. Concrete adapters project immutable invocations and schedules into reviewed device and operator documents, while the runtime validates and replays the frozen facility plan.
The language, LAIR, facility model, adapters, and runtime are still evolving. Dry-run and simulation exercise reviewed plans without hardware, and live executors exist only for explicitly supported run formats. Generated instructions and live execution paths require facility-specific review, calibration, and qualification before physical or biological work; software equivalence is not hardware qualification. General reactive workflow execution and broader device coverage remain unfinished.
- Documentation
- Python SDK — typed SBOL designs, circuits in LOICA
- Write pipetting Methods in Python: typed liquid operations, portable catalogs, and Rust validation
- Contribution boundaries: scientific packages, Methods, profiles, and adapters
- Language design
- Golden Gate example
- Golden Gate in Python — the same checked program through the typed Python frontend
- Golden Gate, extended — the same laboratory with most of the language in it
- LAIR internals
- Facility planning internals
- Adapter implementation internals