Chapter 3
Synthetic biology treats DNA as an engineering medium: a promoter, a ribosome binding site, a coding sequence and a terminator are assembled into a device that does something predictable. In practice a part's behavior depends on the host strain, the growth medium, the plasmid it sits on and the parts around it. A bare sequence in a spreadsheet therefore tells a future user very little. They also need to know who built it, how it was measured, which version they are holding, whether they may use it commercially, and what biosafety precautions apply.
WIA-BIO-021 defines a registry record that carries all of this together. The standard covers part classification, a metadata schema, sequence storage and format conversion, characterization data structures, version control, access and licensing, and integration with iGEM, Addgene and SynBioHub. It is written for part reuse across institutions, so the same record can be read by a university lab, a competition team and a commercial developer without losing meaning.
A few terms from the specification are used throughout this chapter:
The classification system groups parts by what they do in a genetic circuit. Each type carries its own expected properties, so a record for a promoter asks different questions than a record for a vector.
| Type | Code | Role | Properties tracked |
|---|---|---|---|
| Promoter | PRO | Initiates transcription | Strength (relative fluorescence units), inducibility, organism specificity, regulatory mechanism |
| Ribosome binding site | RBS | Initiates translation | Initiation rate, organism compatibility, spacing, secondary structure |
| Coding sequence | CDS | Encodes a protein | Protein product, molecular weight, activity, expression conditions, codon optimization status |
| Terminator | TER | Ends transcription | Termination efficiency, directionality, context dependency |
| Plasmid backbone | VEC | Maintains and propagates parts | Antibiotic resistance, origin of replication, copy number, cloning sites, size in bp |
| Composite part | COM | Multi-part assembly | Component list, assembly method, expected function, validation status |
| Regulatory element | REG | Binding sites, operators | Binding protein or molecule, mechanism, affinity or binding constant |
The properties reflect real design concerns. A strong promoter paired with a weak RBS will not yield the expression a designer expects, and a high-copy backbone changes the load a device places on the cell. The registry captures these attributes as structured fields so that searches can filter on them.
Part identifiers follow the BioBrick pattern BBa_ followed by a type letter and a number. Examples from the specification include BBa_J23100 (a strong constitutive promoter from the Anderson collection), BBa_R0011 (a LacI-regulated promoter), BBa_B0034 (a medium-strength RBS), BBa_E0040 (GFP), BBa_B0015 (a double terminator), BBa_pSB1C3 (a chloramphenicol-resistance, high-copy backbone) and BBa_K123456 (a composite part). Promoters use the P or J prefix, coding sequences C or E, terminators B or T, backbones pSB, and composites K.
The prefixes overlap and the specification is not fully consistent. The B letter appears for both RBS and terminators, and the summary table lists BBa_R for RBS while the detailed section lists BBa_B. Implementers should treat the identifier as an opaque unique key and use the separate Type metadata field for classification, rather than inferring type from the letter.
The reference validation rule shows the same tension:
const partIdRegex = /^BBa_[PRBCETKV][0-9]{5,6}$/;
function validatePartId(partId) {
if (!partIdRegex.test(partId)) {
throw new Error('Invalid part ID format');
}
// Check for collisions
if (partExists(partId)) {
throw new Error('Part ID already exists');
}
}Applied literally, this pattern accepts BBa_K123456 but rejects the specification's own examples BBa_J23100 (the J prefix is not in the character class), BBa_B0034 and BBa_E0040 (four digits instead of five or six), and BBa_pSB1C3. A registry that must ingest legacy iGEM parts should widen the pattern before enforcing it, or it will refuse some of the best-known parts in the field.
BioBrick parts are designed so that any two can be joined and the result is itself a BioBrick. The specification names two assembly standards, RFC10 and RFC25. RFC10 is the original method, based on the well-established prefix and suffix restriction sites and the compatible XbaI and SpeI ends. Joining parts this way leaves a short scar sequence at the junction. The scar is harmless between a promoter and an RBS but can matter inside a protein-coding region, which is why RFC25 exists for protein fusions. A composite record should therefore state its assembly method, since the method determines what sits between its components.
Composite parts, in the BBa_K series, carry the following properties in the standard:
The registry exposes this structure through a composition endpoint, GET /registry/v1/parts/{id}/composition, which returns the composite-part subgraph. A consumer can then walk from a device such as a GFP expression cassette down to the promoter, RBS, BBa_E0040 coding sequence and terminator it contains, and check each component's own characterization.
Every part must carry a minimum metadata set:
The metadata is designed to be compatible with SBOL and GenBank. Registration through the TypeScript SDK shows the shape of a submission:
const part = await registerPart({
partId: 'BBa_K123456',
name: 'Strong Constitutive Promoter',
type: 'promoter',
sequence: 'TTGACAGCTAGCTCAGTCCTAGGTATAATGCTAGC',
author: 'Team iGEM 2024',
description: 'High-strength constitutive promoter for E. coli',
safetyLevel: 'BSL-1',
license: 'CC-BY-4.0'
});The sequence in this example contains the familiar -35 hexamer TTGACA and -10 hexamer TATAAT of an E. coli sigma-70 promoter, separated by a spacer. The example also registers a promoter under a BBa_K identifier, which the naming convention reserves for composites. It illustrates why the Type field, not the identifier letter, should drive classification.
The safety field maps to standard biosafety levels:
| Level | Description | Containment |
|---|---|---|
| BSL-1 | Minimal risk | Standard lab practices |
| BSL-2 | Moderate risk | Limited access, biosafety cabinet |
| BSL-3 | Serious or lethal | Respiratory protection required |
| BSL-4 | Life-threatening | Maximum containment facility |
Safety is a required field rather than an afterthought. The error code BIO006, "Safety level violation", exists so that a record whose declared level conflicts with the biosafety classification can be rejected and sent back for review.
The sequence is the core of a record, so the standard supports several representations. Raw sequence can be retrieved as FASTA, GenBank or SBOL from GET /registry/v1/parts/{id}/sequence. The command-line tool imports GenBank files and exports SBOL:
wia-bio-021 export --id BBa_K123456 --format sbol --output part.xml
wia-bio-021 import --file plasmid.gb --format genbankSBOL is the preferred interchange format because it describes more than letters: it records features, components and how they relate. The specification requires SBOL 2.3 compliance for SynBioHub compatibility. A part retrieved in SBOL form comes back as an sbol:ComponentDefinition with content type application/rdf+xml.
The reference sequence validator accepts the IUPAC-style letters A, T, C, G and the ambiguity symbol N for DNA, or A, U, C, G and N for RNA, and bounds the length between 1 and 1,000,000 characters. Two practical points follow. A record that contains N positions is only partly defined, so downstream users should treat it with caution. And the stored sequence_hash (a 64-character value in the recommended schema) lets a registry detect when two records hold identical sequence, or when a sequence has silently changed between versions.
A characterization is a measurement with its experimental context. The standard states that characterization data must include measurement context, because a fluorescence value without temperature, time point and optical density cannot be compared with anyone else's. A fluorescence measurement looks like this:
{
"characterization": {
"measurements": [
{
"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"
}
]
}
}Three companion structures cover other needs. A growthCurve block holds OD600 data points over time, a maximum growth rate with a unit, the strain (for example E. coli DH5α) and the medium, including the antibiotic selection. It records the burden a part places on its host. An expression block, for coding parts, separates transcript level (method such as qRT-PCR), protein level (such as Western blot quantification) and specific activity. A reusability block records how often a part has been used, its success rate, ratings, reviews and citation count, so a newcomer can see which parts other teams have actually made work.
Through the API, a measurement is contributed with POST /registry/v1/characterisation. The envelope names the 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 verified against the part's declared chassis and reviewed asynchronously. Including the raw data and the processing script allows a reviewer to reproduce the derived number rather than trust it.
Each part moves through a lifecycle recorded in the status field:
| Status | Code | Meaning |
|---|---|---|
| Planning | PL | Design phase |
| Ordered | OR | DNA synthesis ordered |
| Available | AV | Available in registry |
| Characterized | CH | Experimental data available |
| Validated | VA | Independently verified |
| Deprecated | DP | Superseded or problematic |
| Deleted | DL | Removed from registry |
Version numbers follow semantic versioning, with rules tied to the biology. A MAJOR change means an incompatible sequence change, a MINOR change means backward-compatible additions such as new characterization data, and a PATCH covers fixes and documentation updates. The specification's examples make this concrete: adding characterization moves 1.0.0 to 1.1.0, codon optimization for mammalian cells moves 1.1.0 to 2.0.0, and fixing a description typo gives 1.1.1. The version history reinforces the rule through the sequence hash:
{
"versionHistory": [
{ "version": "1.0.0", "changes": "Initial part submission",
"sequenceHash": "sha256:abc123..." },
{ "version": "1.1.0", "changes": "Added fluorescence characterization",
"sequenceHash": "sha256:abc123..." },
{ "version": "2.0.0", "changes": "Codon optimization for mammalian cells",
"sequenceHash": "sha256:def456..." }
]
}The hash is identical for 1.0.0 and 1.1.0 and changes only at 2.0.0, so a consumer can verify that a minor update did not touch the sequence. Published records are immutable. An update creates a new version, and the earlier one is kept with a replacedBy link and a deprecation notice. A deprecation record carries the reason, a replacementPart such as BBa_K789012, and a stillAvailable flag, which lets labs that already hold the old physical clone keep working. The version history forms a directed acyclic graph; forks are permitted, and merges require explicit acknowledgement with co-signing by the contributing institutions.
Digital sequence and physical DNA are shared under different legal conditions, and the standard models both. Supported licenses are CC-BY-4.0, CC-BY-SA-4.0, CC0-1.0, MIT, Proprietary and OpenMTA, the Open Material Transfer Agreement. The access model has three tiers: public (read-only, no sign-in), institutional (full read and contribution rights for affiliated members) and private (per project, and the default for in-progress designs).
The accessControl block lets a record set visibility (public, private or restricted), per-action permissions for view, download, modify and characterize, an embargo date, and an agreement URL when an agreement is required. A commercial user who intersects a restricted-licence part receives a typed licensing.restricted event.
Physical availability is a separate materialTransfer block. It names the provider (for example Addgene), a catalogue number, cost and currency, shippingRestrictions by country, and whether an MTA is required. Keeping this apart from the sequence license reflects real practice: a sequence may be freely published while the plasmid is shipped only under agreement.
The interface supports four main tasks: search, fetch, contribute and characterize. The endpoint reference lists:
GET /registry/v1/parts # search parts (paginated)
GET /registry/v1/parts/{id} # fetch part record
POST /registry/v1/parts # contribute new part
GET /registry/v1/parts/{id}/sequence # raw sequence (FASTA/GB/SBOL)
GET /registry/v1/parts/{id}/characterisation # measurement data
POST /registry/v1/characterisation # contribute measurement
GET /registry/v1/parts/{id}/composition # composite-part subgraphThe implementation guidelines describe a second route style under /api/v1/parts, including a search such as GET /api/v1/parts/search?type=promoter&organism=E.coli&strength=high, retrieval with ?version=1.2.0&format=sbol, and PATCH /api/v1/parts/{partId}/characterization. Registration there returns 201 Created with the part ID, version 1.0.0 and a registry URL. The two documents use different path prefixes, so a deployer should pick one consistently and confirm which applies.
Search can filter by chassis, type, length, GC content, free-text function, keyword, design tool, contributing institution and licence. Pagination is cursor-based through ?after=cursor&limit=N with a maximum of 100, and each result carries the SBOL fragment plus the metadata block. The CLI offers the same operations from the shell, such as wia-bio-021 search --type promoter --organism "E. coli".
Failures use eight domain-specific codes, each paired with a corrective action:
| Code | Meaning | Action |
|---|---|---|
| BIO001 | Invalid part ID format | Fix part ID |
| BIO002 | Part already exists | Use different ID or update existing |
| 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 |
A new registry is only useful if it does not strand existing parts. The standard maps its records onto the registries the community already uses.
parts.igem.org, and exports convert to iGEM XML while preserving part ID and version.addgene block with the plasmid ID, URL, availability and price, linking the digital part to a physical plasmid that can be ordered.genbank block cross-references the accession and URL.Federation extends this idea. A query at one registry can surface results from peers such as the iGEM Registry, JBEI Public Inventories, Addgene and institutional repositories. The federation envelope carries the source registry, the source part identifier, a resolution policy (cached or live) and a trust class. The trust class tells a downstream consumer whether a federated record can be relied on without independent verification. This matters for sequence data, where an unverified copy of a part may differ from the physical clone.
This chapter described the standard through the questions a bench scientist actually asks about a part. The seven part types and the BBa_ identifiers say what a part is, though the naming letters and the reference regex need care. The BioBrick assembly standards explain how parts combine into composites. The metadata record, with its mandatory biosafety level, says who made it and how hazardous it is. SBOL, GenBank and FASTA carry the sequence. Characterization blocks say how it behaved, under which conditions and with which instrument. Semantic versioning tied to sequence hashes says which exact sequence a user holds, and licensing and material-transfer blocks say what they may do with it and how to obtain it physically. The API, the BIO001 to BIO008 error codes and the iGEM, Addgene, SynBioHub and GenBank mappings let those records move between systems.
Two practical lessons stand out. First, classify by the Type field rather than by identifier letter, and validate IDs with a pattern broad enough for legacy parts. Second, treat the sequence hash as the arbiter of whether two records are really the same part. The next chapter moves on from how a single part is described to how the registry is deployed and used within the wider ecosystem of tools and workflows around it.