Chapter 8
A synthetic biology registry has to answer a practical question: when a lab downloads a part, can it trust that the DNA, the host context and the measurements describe the same thing? WIA-BIO-021 answers it with a part record that bundles identity, sequence, biological context, characterization data, licence and history in one structure. This chapter follows that record from classification to deployment.
WIA-BIO-021 (version 1.0.0, status Active) defines one framework for registering, storing and sharing biological parts. Its stated aim is interoperability between the major registries without losing data integrity or reproducibility. The scope covers:
The terminology is deliberately small. A part is a discrete DNA or RNA sequence with a defined function. A device combines several parts into one integrated function. A BioBrick is a standardized part assembled under RFC10 or RFC25, where an RFC is a "Request for Comments" that defines an assembly standard. SBOL is the Synthetic Biology Open Language. Characterization is experimental data describing how a part behaves.
The foundation has three layers: a typed vocabulary for what a part is, a lifecycle and safety label for how far it can be trusted, and a metadata envelope that carries the sequence and its context.
Parts fall into seven primary categories. Each category has a type code, and most have a naming prefix so that an identifier hints at its role.
| Class | Type | Naming convention | Examples from the standard |
|---|---|---|---|
| Promoter | PRO | BBa_P[number], BBa_J[number] | BBa_J23100 (strong constitutive), BBa_R0011 (LacI-regulated) |
| Ribosome binding site | RBS | BBa_B[number] | BBa_B0034 (medium), BBa_B0030 (strong) |
| Coding sequence | CDS | BBa_C[number], BBa_E[number] | BBa_E0040 (GFP), BBa_E1010 (mRFP1) |
| Terminator | TER | BBa_B[number], BBa_T[number] | BBa_B0015 (double terminator), BBa_B0010 |
| Plasmid backbone | VEC | BBa_pSB[number] | BBa_pSB1C3, BBa_pSB1A3 |
| Composite part | COM | BBa_K[number] | BBa_K123456 (GFP expression device) |
| Regulatory element | REG | none specified | operators, protein binding sites |
Each class has its own property list, and the lists reflect what a bench scientist needs to know. A promoter records strength (in relative fluorescence units), whether it is constitutive or inducible, organism specificity and regulatory mechanism. An RBS records initiation rate, organism compatibility, spacing requirements and secondary structure. A coding sequence records its protein product, molecular weight, activity and codon optimization status. A terminator records efficiency, directionality and context dependency. A backbone records antibiotic resistance, origin of replication, copy number, cloning sites and size. A composite lists its component parts, assembly method, expected function and validation status.
The prefixes are overloaded. B is shared by RBS and terminators, which is why the type field, not the identifier, must be treated as authoritative.
Every part carries a lifecycle status that tells a consumer how much evidence stands behind it.
| Status | Code | Meaning |
|---|---|---|
| Planning | PL | design phase |
| Ordered | OR | DNA synthesis ordered |
| Available | AV | present in the registry |
| Characterized | CH | experimental data available |
| Validated | VA | independently verified |
| Deprecated | DP | superseded or problematic |
| Deleted | DL | removed from the registry |
The sequence from Available to Characterized to Validated separates a sequence someone deposited from one whose behaviour has been measured and then confirmed by a different party. A part with no independent verification is not the same as a part nobody has complained about.
Safety is a separate axis. Parts are tagged with a biosafety level from BSL-1 (minimal risk, such as GFP and standard promoters) through BSL-2 (for example mammalian cell work) and BSL-3 (parts from pathogenic organisms) to BSL-4 (extreme risk, restricted access). The level is a required metadata field. An implementation that rejects a record whose declared level contradicts its content reports error BIO006, "Safety level violation".
Every registered part must carry a core block: partId, partName, type, subtype, status, safetyLevel, author (name, affiliation, email), created, modified, version and license. Sequence information sits in a nested block:
{
"sequence": {
"nucleotides": "ATGCGTAAAGGAGAAGAACTTTTC...",
"length": 1234,
"format": "raw|fasta|genbank|sbol",
"sequenceType": "dna|rna|protein",
"checksum": "sha256:abc123...",
"features": [
{ "type": "promoter", "start": 1, "end": 35, "strand": "+", "name": "J23100" },
{ "type": "RBS", "start": 40, "end": 52, "strand": "+", "name": "B0034" }
]
}
}The feature list is what makes a composite readable. It places the promoter and RBS on coordinates and strand, so a tool can reconstruct the device layout without re-annotating the sequence. The checksum lets two registries confirm that they hold identical DNA, and the version history in section 8.8 reuses it to distinguish a documentation edit from a sequence change.
The biological context block records organism and strain (for example Escherichia coli K12, DH5α). It also records growth conditions (temperature, medium, antibiotics, inducers) and expression details (host, compartment, tags such as His6, fusion partners). A promoter that is strong in one chassis can be weak in another, so a part record without this context cannot be reused reliably. The documentation block adds description, design notes, literature references with DOI, and external links to GenBank and iGEM.
The standard does not publish market sizing. What it does describe is the landscape of repositories that a registry must coexist with, and that landscape is where the standard's practical value lies.
Parts live in many places: the iGEM Registry, Addgene for physical plasmids, SynBioHub for SBOL-native design data, GenBank for sequence accessions, JBEI public inventories, and institutional repositories. The standard maps onto each one:
The protocol-level companion is federation. A query at one registry can surface results from peers. The federation envelope carries the source registry, the source part identifier, a resolution policy (cached copy versus live lookup) and a trust class. The trust class tells a downstream consumer whether it may rely on a federated record or must verify it independently. This matters because a part imported from an unfamiliar repository is only as reliable as the evidence behind it.
The main application of a registry is selecting parts on evidence, and the evidence is characterization data. The quality of that data determines whether registries can support automated design tools.
The standard requires measurements to carry their context. A bare number is not accepted. A condensed fluorescence record looks like this:
{
"type": "fluorescence",
"value": 15000, "unit": "RFU", "stdDev": 1200, "replicates": 3,
"conditions": { "temperature": 37, "timePoint": 6, "timeUnit": "hours", "opticalDensity": 0.6 },
"method": "Plate reader - Tecan Infinite M200",
"performedBy": "Lab Team A",
"date": "2024-08-15"
}Replicates, standard deviation, optical density at the time point, instrument and operator are recorded together. A reader can then judge whether 15,000 RFU in one lab is comparable with a value from another instrument, and can repeat the experiment.
Three further structures round out the characterization model:
Contributions arrive through a measurement envelope: chassis, medium, induction profile, instrument (plate reader, flow cytometer, qPCR or RNA-seq), raw data, the processing pipeline as script plus version, and the derived values. Submissions are checked against the part's declared chassis and reviewed asynchronously. Keeping raw data and the processing script beside the derived number means a disputed value can be recomputed.
For a data format, compliance means that records survive a round trip between tools without silent loss.
The metadata schema is JSON, but the lingua franca of design tools is SBOL, an RDF-based language for describing biological designs. Part retrieval can return application/rdf+xml carrying a ComponentDefinition, and the standard requires compliance with SBOL 2.3. Sequence format may be raw, FASTA, GenBank or SBOL, and the registry converts between them.
A practical consequence is that the same part can be consumed three ways. A web client reads JSON, a sequence editor reads GenBank, and a design-automation tool reads SBOL. The list endpoints return an SBOL fragment plus the metadata block for each match, so a search result is already usable by a design tool.
Three concerns dominate deployment: how change is recorded, who may use a part, and how the service behaves at its edges.
Versioning. Parts use semantic versioning with biological meaning. A MAJOR change is an incompatible sequence change, such as codon optimization for mammalian cells (1.1.0 to 2.0.0). A MINOR change adds backward-compatible information, such as new characterization data (1.0.0 to 1.1.0). A PATCH fixes documentation (1.1.0 to 1.1.1). The version history stores a sequence hash per entry, so readers can see that versions 1.0.0 and 1.1.0 share one hash while 2.0.0 differs.
Published records are immutable. An update creates a new version, and the prior one is kept with a replacedBy link and a deprecation notice. Deprecation records a reason, a replacement part (for instance BBa_K789012) and whether the old part is still available. The history forms a directed acyclic graph. Forks are allowed, and merges need explicit acknowledgement with co-signing by the contributing institutions.
Licensing and access. Supported licences are CC-BY-4.0, CC-BY-SA-4.0, CC0-1.0, MIT, Proprietary and OpenMTA. The last is notable because it governs physical material, not just data. Access tiers are public (read-only, no sign-in), institutional (affiliated members can read and contribute) and private (per-project, the default for in-progress designs). A part can also carry an embargo date and a required agreement. Material transfer records provider, catalogue number, cost, currency, shipping restrictions and whether an MTA is required. When a commercial user intersects a restricted-licence part, the protocol raises a typed licensing.restricted event.
The implementation guidelines use four core operations: POST /api/v1/parts (returns 201 with part ID, version and URL), GET /api/v1/parts/{partId} (with version and format parameters), GET /api/v1/parts/search (filters such as type, organism and strength; responses carry results, total and page) and PATCH /api/v1/parts/{partId}/characterization. The Phase 2 reference uses a /registry/v1 prefix, with sub-resources for sequence, characterisation and composition and cursor-based pagination capped at 100 results. The two prefixes differ, so a deployment should choose one and document it.
The suggested relational schema has three tables: parts, characterization_data (conditions held as JSONB) and version_history. Full-text search covers part ID, name, description, features, author and keywords, and a nested mapping preserves characterization structure. The error codes are:
| Code | Meaning | Remedy |
|---|---|---|
| BIO001 | Invalid part ID format | Fix the ID |
| BIO002 | Part already exists | Choose another ID or update |
| BIO003 | Invalid sequence | Check nucleotide characters |
| BIO004 | Missing required metadata | Add required fields |
| BIO005 | Version conflict | Resolve version history |
| BIO006 | Safety level violation | Review biosafety classification |
| BIO007 | License incompatibility | Update license terms |
| BIO008 | Format conversion failed | Check input format |
Two details of the reference validators deserve attention. The sample ID pattern, ^BBa_[PRBCETKV][0-9]{5,6}$, requires five or six digits. That would reject the standard's own examples BBa_B0034, BBa_E0040 and BBa_R0011, which have four, and it rejects the J prefix and pSB backbone names entirely. Implementers should derive a pattern from the naming table in section 8.2 and test it against every example listed there. Separately, the stored hash column is a 64-character field, while the metadata checksum is written with a sha256: prefix, so one form must be normalized to the other before comparison.
The standard leaves extension room in places a registry operator can see: the REG class has no naming convention yet, and the protein sequence type is declared but has no validator. Pending formal extensions, operators should treat those gaps as local policy and document them.
In practice the ecosystem is a division of labour among repositories. Sequence databases hold accessions, plasmid repositories ship physical DNA, and design hubs store SBOL. A WIA-BIO-021 registry sits between them, and its cross-reference blocks (Addgene, GenBank, iGEM) point to the authoritative holder instead of copying it.
The standard's terminology names two assembly rules, RFC10 and RFC25. Understanding them explains why a part's assembly standard is worth recording.
A BioBrick part is flanked by a prefix and suffix carrying restriction sites. In RFC10 these are EcoRI and XbaI on the prefix side, and SpeI and PstI on the suffix side. XbaI and SpeI leave compatible overhangs. Digesting one part with SpeI and another with XbaI lets them ligate, and the joint destroys both sites. The product is again flanked by the original outer sites and can enter the next round. This is why composite parts can be nested indefinitely.
The price is a scar, a short stretch of leftover sequence between the joined parts. Its length under RFC10 is not a multiple of three, so it shifts the reading frame and is poorly suited to making protein fusions. RFC25, the Freiburg standard, uses different sites to produce a scar that preserves the frame, which suits fusions of coding domains. For a registry the consequence is practical: the assemblyMethod-style information on a composite tells a user whether two parts can be joined in frame, and the sequence checksum ensures that the scar is part of the stored DNA.
iGEM is an annual synthetic biology competition in which student teams design, build and test a project, then document it publicly. Teams are expected to deposit new parts in the iGEM Registry, conventionally in the pSB1C3 backbone (chloramphenicol resistance, high copy). That is why composite identifiers beginning BBa_K recur in the standard's examples and why its metadata includes team and affiliation. The competition supplies a steady stream of new parts, and the standard's characterization and deprecation rules help turn a one-season deposit into a record future teams can reuse.
The example below combines the pieces discussed above: a naming check based on section 8.2, a sequence check using the bounds and character classes from the reference validator, and a client for the search endpoint. The response fields (results, partId, name, strength, relevance) are those shown in the guidelines.
const PREFIXES = {
promoter: ["BBa_P", "BBa_J"],
rbs: ["BBa_B"],
cds: ["BBa_C", "BBa_E"],
terminator: ["BBa_B", "BBa_T"],
vector: ["BBa_pSB"],
composite: ["BBa_K"]
};
function checkPartId(partId, type) {
const ok = (PREFIXES[type] || []).some(p => partId.startsWith(p));
if (!ok) throw new Error("BIO001: ID does not match naming convention for " + type);
}
function checkSequence(seq) {
if (!/^[ATCGNatcgn]+$/.test(seq)) throw new Error("BIO003: invalid DNA sequence");
if (seq.length < 1 || seq.length > 1000000) throw new Error("BIO003: length out of bounds");
}
async function findParts(base, filters) {
const qs = new URLSearchParams(filters); // e.g. type, organism, strength
const res = await fetch(base + "/api/v1/parts/search?" + qs.toString());
if (!res.ok) throw new Error("search failed with HTTP " + res.status);
const body = await res.json();
return body.results.sort((a, b) => b.relevance - a.relevance);
}
// findParts("https://registry.example.org",
// { type: "promoter", organism: "E.coli", strength: "high" })Note that the checks belong on the server as well. A client-side check only saves a round trip, while the registry must remain the authority and return BIO001 or BIO003 itself. Sorting by relevance is a client convenience, and the registry's own ordering is not specified here.
Registry records support the standard application patterns. Reporter devices (promoter, RBS, fluorescent protein, terminator) quantify promoter strength. Inducible systems use regulatory parts such as the LacI-regulated promoter. Production strains pair coding sequences with tuned RBS parts. Each depends on retrieving parts with comparable, context-rich measurements and, where hosts differ, on a MAJOR version for codon-optimized variants.
The questions below can be answered from this chapter alone. Work through them before moving on.
type field authoritative where the identifier prefix is not? Give two classes that share the B prefix.WIA-BIO-021 treats a biological part as a record whose usefulness depends on context. Identity comes from a typed naming scheme, trustworthiness from a lifecycle status that runs from planned to independently validated, and risk from a required biosafety level. Characterization is stored with its conditions, instrument, replicates and processing pipeline, so a number can be reproduced. Immutable versions with semantic meaning, a visible deprecation trail, explicit licences and material-transfer terms govern change and reuse. SBOL 2.3 compliance and the iGEM, Addgene, SynBioHub and GenBank mappings connect the registry to its neighbours. Deployment mostly means careful validation, and the example patterns here need reconciling with the standard's own part names before use.
The record is only as useful as the next step. The sequences, devices and measurements described here feed design, assembly and screening workflows, which the next chapter takes up. There the question changes from how a registry describes a part to how a team's work flow turns registry entries into built constructs, and how the safety labels and licence terms introduced here constrain what may be built and shared.