Every chassis design program involves a set of judgment calls that don't reduce cleanly to a protocol. Which deletions are worth making? How much characterization is enough before you transfer the strain? What does "modular" actually mean in the context of a specific genetic background? Over the past several months of early characterization work, our team has converged on a set of principles that guide these decisions. They're not rules — engineering programs are too context-dependent for rules to be universal — but they are durable enough that we apply them reflexively now, and specific enough that they actually constrain choices rather than just sounding good.
These principles apply specifically to chassis development for partner programs — the context where another biology team will be loading a heterologous pathway into the chassis we deliver. Some of them would apply differently if we were building a chassis purely for internal production use.
Principle 1: Minimize before you add
The instinct in strain engineering is often additive: install this regulator, overexpress that pathway enzyme, add a selection marker. We've found that the more productive instinct for chassis development is subtractive first. Before any heterologous elements are introduced, we ask: what in the genome is working against the program's requirements? What will compete for the precursor pools this pathway needs? What regulatory circuits will interfere with the expression systems we plan to use?
Genome reduction in the context of a partner program is not about minimizing genome size as an end in itself. It's about removing specific genetic elements whose presence creates predictable problems: mobile genetic elements and insertion sequences that cause chromosomal rearrangements during extended fermentation; cryptic prophage regions that can trigger under stress conditions and introduce heterogeneity across a production culture; endogenous biosynthetic pathways that drain the same precursor pools as the partner's target pathway. Each deletion we make is justified by a specific functional prediction about what it prevents — not by a general theory that smaller genomes are better.
The practical discipline this imposes is that every proposed modification requires a stated functional rationale that we write down before the experiment. That documentation practice matters more than the specific deletions; it forces us to distinguish between deletions we believe are beneficial based on evidence and deletions we are making because they seem reasonable. We've reversed proposed modifications more than once after the writing process revealed that our stated rationale was weaker than we'd assumed.
Principle 2: Characterize what you deliver
A chassis delivered without adequate characterization data is not really a chassis — it's a strain with a hopeful label. We're specific about what "adequate" means for our partner programs: at minimum, a verified genomic sequence (whole-genome sequencing with no ambiguous positions at any modified locus), growth kinetics under the production-relevant conditions specified by the partner (not just under standard laboratory conditions), a quantitative metabolic flux profile by ¹³C-MFA for the key precursor nodes, plasmid maintenance stability data over at least twenty generations under both selective and nonselective conditions, and a protease/proteasome activity profile relevant to the partner's expressed protein class if applicable.
That list is demanding to generate. It requires roughly four to eight weeks of dedicated analytical work per chassis variant. We haven't found a way to compress it without losing data that later turns out to matter. What we have found is that generating this data early — during chassis development rather than as a final delivery step — substantially changes the design process, because the data reveals things about the chassis that change which modifications are worth making. The characterization is not a QC check at the end of development; it is part of the development loop.
We're not saying every chassis program needs the same depth of characterization. A research chassis used for initial pathway screening in a model organism can work with shallower data. But a chassis delivered as infrastructure for a program that a partner team will build on for two or three years needs to be characterized at a level that gives them confidence in decisions they haven't made yet. That's a different standard, and it requires being honest with yourself about the difference.
Principle 3: Design for host-compatibility, not just yield
Yield — titer of target compound per unit of carbon input — is the metric that biosynthesis programs ultimately care about. It's not, however, the right metric to optimize during chassis development. The reason is that yield is a property of the complete system (chassis plus pathway plus process conditions), and optimizing the chassis for yield in isolation either requires running the full pathway (which defeats the purpose of providing a chassis before pathway installation) or making assumptions about the pathway that may not hold.
The metric we optimize during chassis development is host-compatibility: the chassis's ability to support a wide range of heterologous pathway architectures without imposing unexpected constraints on expression, cofactor balance, or growth physiology. Concretely, this means we test the chassis against a panel of synthetic genetic circuits representing different expression logic, different codon usage profiles, and different metabolic load levels — before any partner-specific pathway is involved. A chassis that maintains predictable growth and expression behavior across this panel will generally be more useful to a partner program than one optimized for maximum titer under a specific pathway/condition combination that wasn't tested under realistic production conditions.
The Voigt lab's work on genetic part characterization and the Church lab's contributions to large-scale genomic recoding have both influenced how we think about this principle. The goal is orthogonality: the chassis should behave predictably when new elements are introduced, without those elements triggering unexpected changes in host physiology. Perfect orthogonality isn't achievable, but it's the right target to design toward.
Principle 4: Build modularity in from the start
A chassis built for one program will inevitably be asked to serve a slightly different program. Partners' requirements evolve; the target compound changes; the expression system gets redesigned. A chassis with modularity built in at the genetic architecture level accommodates these changes without requiring full reconstruction. One that was designed as a monolithic optimized system for one specific configuration requires rework that is often more expensive than building a new chassis from scratch.
In practice, this means we design integration sites and expression cassette landing pads into the chassis during initial construction — using well-defined genomic safe harbor loci rather than random integration. It means we use modular cloning frameworks (MoClo or the Golden Gate assembly standard) for all construct assembly, which preserves compatibility across the library of parts we accumulate across programs. It means we verify CRISPR tool compatibility in the chassis background as part of the initial characterization — specifically that the Cas9 or Cas12 system the partner plans to use for subsequent modifications doesn't have off-target effects in our chassis background that it wouldn't have in a wild-type strain.
The 2026 trend toward multi-organism platform strategies — programs that want the same logical pathway operable in both a bacterial and a yeast chassis, or in a eukaryotic cell line and an industrial Pseudomonad — makes this principle increasingly important. Modular architecture that was designed for one organism with future porting in mind is substantially easier to transfer than an organism-optimized design that was never intended to move. We're investing now in building that cross-organism modularity into our chassis design conventions, even though most of our current work is in single-organism programs.
Principle 5: Documentation is part of the chassis
The least glamorous of our five principles is the most practically important for partner programs. A chassis is not fully transferred until the knowledge required to work with it intelligently is also transferred. That knowledge includes: every genomic modification made, with the experimental rationale, the specific method used, and the verification data confirming the modification is present and correct; every characterization experiment performed, with raw data, the analytical conditions, and an honest assessment of data quality including any experiments that produced ambiguous results; and a functional model of the chassis that explains the expected behavior of key metabolic nodes under production conditions.
This documentation standard is not what most strain transfer agreements require. It is, however, what a partner team actually needs to make intelligent decisions about whether to make additional modifications, how to interpret their own pathway performance data, and what conditions to avoid. We've found that the most common failure mode in chassis handoff is not that the strain doesn't work — it's that the receiving team can't tell whether the strain is working as expected or is showing anomalous behavior, because they don't have enough baseline information to distinguish between the two.
We generate this documentation as we go — not as a delivery deadline exercise — which means the quality of the documentation is much higher than it would be if we tried to reconstruct the rationale for each modification after the fact. The cost is ongoing discipline about recording decisions and data at the time they're made. We consider it non-negotiable, not because regulators require it at this stage, but because intellectual honesty about what we've done and why is the foundation that everything else in a chassis program is built on.