A formal, layered architecture for describing nanoparticle therapeutic systems as structured, reproducible, and regulatory-ready data objects.
This article introduces the Nanomedicine Design Stack — a formal, layered architecture for describing nanoparticle therapeutic systems as SBOL3-compliant data objects. The Stack comprises four layers: Component Definition, encoding the molecular constituents of a nanoparticle system; Formulation Parameters, encoding the process conditions under which a design is realised; Characterisation Assertions, encoding measured physicochemical properties linked to the design and process; and Provenance and Context, encoding the experimental and regulatory context in which a design was generated and assessed. Each layer is defined with reference to the SBOL3 data model, the relevant ontological vocabularies, and the specific parameters that practitioners need to encode for each nanoparticle class. The article provides implementation guidance for lipid nanoparticle, polymeric nanoparticle, and inorganic nanoparticle systems, and discusses integration with existing laboratory informatics infrastructure including Benchling and SynBioHub.
Keywords
1. Why a Stack Architecture
Biology has built extraordinary discovery infrastructure. It has not built design infrastructure. The first article in this series made the case that this gap — between what the science can do and what the documentation system can reliably specify and transfer — is the central bottleneck in nanomedicine. This article provides the technical response: a formal, layered architecture for what design infrastructure in nanomedicine should actually look like.
Biological design frameworks have a tendency toward either over-specification or under-specification. Over-specified frameworks attempt to capture everything and become unwieldy in practice — the parameter space is too large, the ontological commitments too rigid, and the adoption friction too high. Under-specified frameworks capture the obvious and leave the critical details to informal convention, which is precisely the problem they are supposed to solve.
The Nanomedicine Design Stack separates two related questions that are often collapsed into one: what is being designed, and how information about that design is represented computationally. The design architecture comprises five connected levels: L5 — Clinical & Therapeutic Intent; L4 — Biological Interaction; L3 — Delivery Architecture; L2 — Nanomaterial Architecture; and L1 — Manufacturing & Specification. These levels preserve traceability from therapeutic purpose through biological behaviour and delivery requirements to material architecture and measurable manufacturing specifications. Alongside this, the Stack defines four implementation dimensions for representing the resulting design as structured, SBOL3-compliant data: Component Definition, Formulation Parameters, Characterisation Assertions, and Provenance and Context.
This distinction is not arbitrary. The five design levels reflect the causal logic of a nanomedicine: therapeutic intent creates biological requirements; biological requirements shape delivery architecture; delivery requirements constrain nanomaterial architecture; and the material design must ultimately resolve into manufacturable and measurable specifications. The four implementation dimensions then provide the structured data needed to encode the components, process conditions, measured properties, and provenance through which that design is realised and evidenced.
The architecture therefore serves the three primary audiences for nanoparticle design data without reducing the design to a manufacturing record. Researchers need to understand components, functions, biological interactions and evidence; manufacturers need explicit material and process specifications linked to characterisation; and regulators need traceability from therapeutic intent and critical design requirements through to the lots, facilities, measurements and assessment records that support a product.
A complete design description must therefore answer both questions: why is this nanomedicine designed this way, and how is that design represented, manufactured, measured and evidenced?
2. Implementation Dimension 1: Component Definition
2.1 Scope and Purpose
The Component Definition layer encodes the molecular constituents of a nanoparticle system as formal SBOL3 Component objects. Each component is identified by a persistent URI, typed using an appropriate ontological term, and described with the structural and chemical properties relevant to its role in the system.
For lipid nanoparticle systems, the primary components are the ionisable lipid, the phospholipid, cholesterol, and the PEG-lipid. Each is represented as a distinct SBOL3 Component with a type drawn from the Chemical Entities of Biological Interest (ChEBI) ontology where available, or from the NCI Thesaurus for pharmaceutical excipients. The molar fraction of each component in the formulation is encoded as a property of the Component rather than as a free-text annotation.
2.2 Required Parameters by Nanoparticle Class
For lipid nanoparticle systems: ionisable lipid identity (ChEBI or NCI ID); phospholipid identity; cholesterol mole fraction; PEG-lipid identity and PEGylation density; and nucleic acid cargo identity and sequence (for oligonucleotide therapeutics, represented as an SBOL3 Sequence object).
For polymeric nanoparticle systems: polymer identity and molecular weight distribution; block composition and ratio for block copolymers; end group chemistry; and drug or cargo identity. Where the polymer is a defined compound, ChEBI terms apply. Where it is a distribution, the polydispersity index and weight-average molecular weight should be encoded as measured properties with reference to the characterisation method.
For inorganic nanoparticle systems (gold, iron oxide, silica): core material identity; surface ligand chemistry and density; and where applicable, targeting ligand identity, attachment chemistry, and spatial orientation on the particle surface. The SBOL3 Location class can encode surface topology relationships between components with greater precision than is possible in prose.
2.3 SBOL3 Implementation Notes
Each component should be assigned a persistent, globally unique URI at the point of design creation. The SynBioHub repository provides URI minting and version management for SBOL objects. Organisations building internal design libraries should establish a URI namespace — typically based on their domain — and register it with the SBOL community registry.
The SBOL3 Component class supports the encoding of subcomponents through the hasFeature and constraint properties, allowing complex multi-component systems to be represented hierarchically. A lipid nanoparticle system is represented as a top-level Component with four child SubComponent objects (ionisable lipid, phospholipid, cholesterol, PEG-lipid), linked by OrientationConstraint and QuantityConstraint objects that encode their molar relationships.
3. Implementation Dimension 2: Formulation Parameters
3.1 Scope and Purpose
The Formulation Parameters layer encodes the process conditions under which a Component Definition is realised as a physical nanoparticle system. This is the layer most frequently absent from published nanoparticle descriptions, and its absence is the primary cause of irreproducibility in the nanomedicine literature.
Process conditions are not properties of the design in the abstract — they are properties of a specific manufacturing run. The Formulation Parameters layer links a specific set of process conditions to the Component Definition they were used to realise, creating a formal association between design intent and manufacturing execution that is currently absent from most documentation systems.
3.2 Parameters for Microfluidic LNP Formulation
Microfluidic formulation is the dominant method for clinical-grade LNP manufacture. The critical process parameters are: total flow rate; aqueous-to-organic flow rate ratio; lipid concentration in the organic phase; mRNA or nucleic acid concentration in the aqueous phase; mixing chip geometry (encoded as a reference to a chip specification document or a defined vocabulary term); inlet temperature; and post-mixing buffer exchange conditions (dialysis or tangential flow filtration, with membrane type and duration).
Each parameter should be encoded with its nominal value, its acceptable range, and the measurement or control method used to maintain it. The SBOL3 Measure class, combined with units from the Units of Measurement Ontology (UO), provides the formal infrastructure for this encoding. A flow rate of 12 mL/min is encoded not as the string ’12 mL/min’ but as a Measure object with a numerical value of 12, a unit URI from UO for millilitres per minute, and a method reference indicating the flow controller used.
Process conditions are not properties of the design in the abstract. They are properties of a specific manufacturing run — and their formal absence is the primary cause of irreproducibility.
3.3 Parameters for Bulk Mixing and Other Methods
For ethanol injection methods, the critical parameters are lipid-to-aqueous injection volume ratio, injection rate, mixing vessel geometry, and temperature. For thin film hydration methods, the film deposition conditions, hydration buffer composition, and extrusion membrane specifications are required. For polymeric nanoparticle nanoprecipitation, solvent identity, solvent-to-aqueous ratio, addition rate, and stirring conditions should be encoded.
The principle in each case is the same: every parameter that an experienced practitioner would need to reconstruct the manufacturing process should be encoded formally, not described informally. If a parameter is known to affect the outcome but is routinely omitted because it is considered obvious within a specific laboratory context, it should be encoded — precisely because it will not be obvious to the team receiving the design.
4. Implementation Dimension 3: Characterisation Assertions
4.1 Scope and Purpose
The Characterisation Assertions layer encodes the measured physicochemical properties of a nanoparticle system as formal assertions linked to the specific Component Definition and Formulation Parameters that produced them. This linkage is what distinguishes a characterisation assertion from a standalone measurement — it is a claim that a system with a specific composition, produced under specific process conditions, exhibits specific measured properties.
This distinction matters for regulatory purposes. A regulatory submission that reports a hydrodynamic diameter of 100 nm without linking that measurement to a specific lot, produced from a specific formulation, using a specific manufacturing process, provides insufficient information for the agency to assess whether the measurement is representative of the product as it will be manufactured at scale.
4.2 Required Characterisation Parameters
For all nanoparticle classes: hydrodynamic diameter (by dynamic light scattering, with instrument make and model, number of measurements, and statistical treatment); polydispersity index; zeta potential (with measurement buffer and pH); and where applicable, encapsulation efficiency (with assay method — RiboGreen for mRNA, OliGreen for DNA, HPLC or fluorescence for small molecules).
For LNP systems carrying nucleic acid cargo: pKa of the ionisable lipid component (measured by TNS assay, with buffer conditions); mRNA integrity (by capillary electrophoresis or Bioanalyzer, with RIN or DIN equivalent score); and where the system has been used in cellular assays, transfection efficiency with cell line, passage number, and assay conditions.
For targeted nanoparticle systems: ligand density (by appropriate assay — BCA for proteins, HABA for biotin, FRET for nucleic acid aptamers); and receptor binding affinity (Kd by SPR or ITC, with instrument, chip chemistry, and fitting model).
4.3 Linking Assertions to Design Objects
In SBOL3, characterisation assertions are encoded using the Activity class from the PROV-O provenance ontology, which SBOL3 extends. An Activity represents a measurement event with a defined start time, a reference to the agent (instrument or protocol) that performed it, and associations to the entity measured (the nanoparticle lot) and the entity generated (the measurement result). This formal provenance structure is what allows computational systems to trace a measurement back to the design and process that produced it — and forward to the regulatory assessment in which it was cited.
5. Implementation Dimension 4: Provenance and Context
The Provenance and Context layer encodes the institutional, temporal, and regulatory context in which a design was generated and assessed. It is the layer that connects the technical content of the first three layers to the administrative and regulatory systems in which that content is used.
This layer is frequently omitted from academic design descriptions because it has no scientific content. It is not omitted from regulatory submissions — but in current practice it is maintained in separate administrative systems (electronic batch records, LIMS audit trails, document management systems) that are not formally linked to the design data. The Nanomedicine Design Stack makes this linkage explicit and machine-readable.
5.2 Required Provenance Elements
Laboratory of origin: institution, department, and principal investigator, encoded using persistent identifiers (ORCID for individuals, ROR for institutions). Design creation date and version history, using SBOL3’s built-in versioning through persistent URI versioning conventions. Lot or batch identifier for physical instantiations of the design, linked to the formulation parameters and characterisation assertions for that specific lot.
For designs entering regulatory review: IND or CTA number (for clinical-stage materials); GMP status (research grade, GMP-compliant, or GMP-certified); facility identifier (FDA Establishment Identifier or EMA equivalent); and a reference to the relevant CMC module in the regulatory submission dossier.
5.3 Integration with Existing Systems
The most common implementation question is how the Provenance and Context layer integrates with existing document management and ERP systems. The answer is that SBOL3 does not replace these systems — it references them. A provenance record in an SBOL3 design object contains a URI that points to the relevant record in the organisation’s existing system, whether that is a Veeva Vault document, a SAP batch record, or a laboratory notebook entry in Benchling.
The Nanomedicine Design Stack is not a LIMS replacement or a document management system. Its five-level architecture describes the design logic of the nanomedicine, while its SBOL3 implementation dimensions provide a design-centric data layer that holds the formal representation of that system and links outward to the operational and administrative systems that manage execution and documentation. The value is in making design intent, technical relationships and supporting records explicit, persistent and machine-readable — not in absorbing the functions of systems that already exist and work.
6. Implementation: Getting Started
6.1 Minimal Viable Implementation
A minimal implementation does not require every part of the Stack to be encoded at once. A research laboratory can begin by representing the relevant L2 Nanomaterial Architecture and L1 Manufacturing & Specification information using the Component Definition and Characterisation Assertions dimensions. Benchling’s SBOL export functionality can provide part of this foundation by exporting biological design objects and linked measurements into an SBOL-compatible representation.
The principal gaps in a Benchling-native implementation are the structured representation of formulation parameters and the explicit provenance links required to connect design decisions, manufacturing execution and evidence. Formulation parameters commonly remain in notebook entries as free text. A practical first step is therefore to create structured templates that map process values to formal measurement objects so that the information can be exported and connected to the wider design representation.
6.2 CDMO and Regulatory Implementation
For contract development and manufacturing organisations, the immediate priority is usually L1 — Manufacturing & Specification — and its traceable relationship to L2 — Nanomaterial Architecture. The manufacturing process specification should be encoded as structured design data rather than existing only as a PDF procedure, so that process parameters, deviations, versions and resulting characterisation data can remain linked to the material design they implement.
For regulatory submissions, the immediate opportunity is to use the Stack as the internal data model for CMC documentation, even if the regulatory submission itself is still in PDF format. An organisation that maintains its design data in SBOL3 format internally can generate the PDF submission from that data programmatically, ensuring consistency between the design record and the regulatory document — and positioning itself to submit in structured format when the FDA’s structured data programme extends to complex biological products.
7. Conclusion
The Nanomedicine Design Stack is not a finished standard. It is a working framework with two connected parts: a five-level architecture for reasoning from Clinical & Therapeutic Intent through to Manufacturing & Specification, and an SBOL3-oriented implementation model for representing components, formulation parameters, characterisation assertions, provenance and context as structured data.
The value of this architecture is that it can be adopted incrementally. A team can begin at the level where its immediate problem exists — for example, formalising nanomaterial architecture and manufacturing specifications — while preserving the ability to connect those records upward to delivery, biological and therapeutic requirements. The implementation dimensions can likewise be introduced progressively as structured data replaces prose-based documentation.
Each layer adds value independently. All four together constitute a design description that is complete, reproducible, regulatory-ready, and built on open infrastructure that belongs to the whole community. That is what the field needs. The architecture exists. The tools exist. The work now is implementation.
References
- SBOL Community (2023). Synthetic Biology Open Language (SBOL) Version 3.1.0 Specification. Journal of Integrative Bioinformatics, 20(1).
- Beal, J. et al. (2019). Communicating Structure and Function in Synthetic Biology Diagrams. ACS Synthetic Biology, 8(8), 1818–1825.
- Madsen, C., McLaughlin, J.A. et al. (2016). The SBOL Stack: A Platform for Storing, Publishing and Sharing Synthetic Biology Designs. ACS Synthetic Biology, 5(6), 487–497.
- Hastings, J. et al. (2016). ChEBI in 2016: improved services and an expanding collection of metabolites. Nucleic Acids Research, 44(D1), D1214–D1219.
- Sabnis, S. et al. (2018). A novel amino lipid series for mRNA delivery: improved endosomal escape and sustained expression. Molecular Therapy, 26(6), 1509–1519.
- Kulkarni, J. et al. (2018). On the Formation and Morphology of Lipid Nanoparticles Containing Ionizable Cationic Lipids and siRNA. ACS Nano, 12(5), 4787–4795.
- W3C (2013). PROV-O: The PROV Ontology. W3C Recommendation, April 2013.