Chapter 1
A promoter that works well in one laboratory is of little use to anyone else if the only record of it is a freezer tube and a lab-notebook entry. Synthetic biology treats genetic elements as reusable parts, so those parts must be identified, described, measured and shared in a form other people and other software can read. WIA-BIO-021 specifies that record. It defines how a part is named, classified and annotated, how its sequence is stored, how its measured behaviour is attached, and how the record moves between the iGEM, Addgene and SynBioHub registries.
The specification is a framework for registering, storing and sharing biological parts. It aims to keep the registry interoperable with the major existing registries while preserving data integrity and reproducibility. Its scope covers:
The standard states its motivation in the Korean phrase 홍익인간 (弘益人間), "benefit all humanity". Part reuse and open collaboration are the goals, and the technical choices that follow serve them. Six terms recur throughout the chapter:
The specification sorts parts into seven primary types, each with a short type code. Identifiers follow the pattern BBa_[Type][Number], so BBa_K123456 is a composite part.
| Type | Code | Naming convention | Example |
|---|---|---|---|
| Promoter | PRO | BBa_P or BBa_J | BBa_J23100 (strong constitutive), BBa_R0011 (LacI-regulated) |
| Ribosome binding site | RBS | BBa_B | BBa_B0034 (medium), BBa_B0030 (strong) |
| Coding sequence | CDS | BBa_C or BBa_E | BBa_E0040 (GFP), BBa_E1010 (mRFP1) |
| Terminator | TER | BBa_B or BBa_T | BBa_B0015 (double terminator) |
| Plasmid backbone | VEC | BBa_pSB | BBa_pSB1C3, BBa_pSB1A3 |
| Composite part | COM | BBa_K | BBa_K123456 (GFP expression device) |
| Regulatory element | REG | (none given) | operators, protein binding sites |
The prefix letter alone does not identify the type. The letter B is used both for ribosome binding sites such as BBa_B0034 and for terminators such as BBa_B0015, and real registries have long mixed historical series letters. A record therefore carries an explicit type field, and software should read that field rather than parse the identifier.
Each type also has its own property set. A promoter records strength (in relative fluorescence units), whether it is constitutive or inducible, organism specificity and regulatory mechanism. An RBS records translation initiation rate, spacing requirements and secondary structure. A coding sequence records protein product, molecular weight and codon optimization status. A terminator records termination efficiency and directionality. A plasmid backbone records antibiotic resistance, origin of replication, copy number, cloning sites and size. A composite part records its component list, assembly method and validation status.
Every registered part MUST carry a core record. The specification's example, abbreviated here, shows the shape:
{
"partId": "BBa_K123456",
"partName": "Strong GFP Expression Device",
"type": "composite",
"subtype": "reporter",
"status": "available",
"safetyLevel": "BSL-1",
"author": { "name": "Team iGEM 2024", "affiliation": "MIT" },
"version": "1.2.0",
"license": "CC-BY-4.0"
}Beyond the core record, the sequence block stores nucleotides, length, format (raw, fasta, genbank or sbol), sequence type (dna, rna or protein), a checksum, and a list of annotated features. Each feature has a type, start, end, strand and name, so a composite can state that a J23100 promoter occupies positions 1 to 35 and a B0034 RBS follows at 40 to 52. A biological-context block records organism, strain, growth conditions and expression host. A documentation block holds design notes, literature references with DOIs, and external links to GenBank accessions or iGEM part pages.
Each part also moves through a lifecycle encoded in the status field:
| Status | Code | Meaning |
|---|---|---|
| Planning | PL | part design phase |
| Ordered | OR | DNA synthesis ordered |
| Available | AV | part available in the registry |
| Characterized | CH | experimental data available |
| Validated | VA | independently verified |
| Deprecated | DP | superseded or problematic |
| Deleted | DL | removed from the registry |
No single repository holds the world's genetic parts. Three registries named in the specification serve different communities:
Each registry has its own field names and file formats, and a researcher who works across them ends up retyping metadata. WIA-BIO-021 acts as a common layer for this overlap. For iGEM, the import path is a plain HTTP request to the registry's XML interface, GET http://parts.igem.org/xml/part.BBa_K123456. Export converts the record to iGEM XML, maps the metadata fields, and preserves the part ID and version. Addgene is covered by its own plasmid-linking provisions in the interoperability section. The shared identifier and version carried through every mapping are what allow a part to be traced back to its source after it moves.
A part is only reusable if people can predict its behaviour, and that depends on measurement data. The specification requires each measurement to carry its context. A fluorescence reading in RFU depends on the instrument, the strain, the optical density and the time point, so a bare number would mislead. An abbreviated measurement record shows what travels with the value:
{
"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"
}Other characterization structures follow the same pattern. Growth curves store paired time and OD600 points plus a maximum growth rate, so a burdensome construct can be distinguished from a neutral one. Expression data for coding parts separate transcript level (for example by qRT-PCR), protein level and specific activity, each with its own unit and method. A reusability block records how often a part has been used, its success rate, ratings, reviews and citations. This turns community experience into data attached to the part. The status codes CH and VA correspond to a part gaining this evidence, and later independent verification.
The registry MUST support four sequence formats: raw DNA/RNA, FASTA, GenBank and SBOL in RDF/XML. FASTA is the minimal case, with the part ID and a description on the header line:
>BBa_E0040 Green Fluorescent Protein
ATGCGTAAAGGAGAAGAACTTTTCACTGGAGTTGTCCCAATTCTTGTTGAATTAGATGGTGenBank adds a LOCUS line, ACCESSION and VERSION fields, and a FEATURES table with qualifiers such as /product and /translation. SBOL is the richest form and the one recommended for maximum interoperability. Implementations MUST convert bidirectionally between all four formats, so a part imported from a GenBank file can be exported as SBOL without losing the annotated features.
Every sequence also has to pass validation before it is accepted:
The TypeScript SDK (@wia/bio-021) exposes four core functions: registerPart, searchParts, getPartDetails and updatePartCharacterization. A registration call supplies the identifier, name, type, sequence, author, description, safetyLevel and license. The command-line tool, wia-bio-021, offers the same operations plus export and import for SBOL and GenBank files.
Two fields in a registration deserve special care. The first is the license, for example CC-BY-4.0, which tells later users on what terms they may reuse the sequence. The second is the biosafety level. The specification expresses it as BSL-1 to BSL-4:
| Level | Description | Containment |
|---|---|---|
| BSL-1 | Minimal risk (GFP, standard promoters) | Standard lab practices |
| BSL-2 | Moderate risk (mammalian cell work) | Limited access, biosafety cabinet |
| BSL-3 | Serious risk (pathogenic organism parts) | Respiratory protection |
| BSL-4 | Extreme risk | Maximum containment facility, restricted access |
Because the level is a required field on the part itself, a search client can filter by it and a registry can restrict access to the higher levels. Sequence data is not harmless merely because it is digital.
The registry model is meant to grow with its parts. A part's history is tracked through a semantic version field and the DP (deprecated) status, so a superseded promoter can be retired without breaking designs that cite it. The standard's companion integrations (intent-based part discovery, a universal biological API gateway, collaboration features and quantum simulation of biological systems) are named as extension points rather than finished features. How well they work will depend on the same discipline described above: complete metadata, contextualized measurements, and stable identifiers.
Read together, the status codes describe a part's journey. A team plans a design (PL), orders the DNA (OR), and deposits the sequence so it becomes available (AV). Other labs measure it and attach data (CH), and independent verification earns the VA status. A part found to be superseded or problematic is marked DP and stays visible for traceability. Only a removal is recorded as DL. The registry is therefore a living record in which negative results and corrections stay attached to the part.
The people in this ecosystem depend on one another. Authors register parts and supply characterization. Users search, build and report back through reusability metrics. Other registries exchange records through the interoperability layer. The standard's role is to keep identifiers, versions and units consistent so that each handoff preserves meaning.
A BioBrick part is flanked by a standard prefix and suffix, and the assembly standard fixes the restriction sites in them. In RFC10, the prefix carries EcoRI and XbaI sites and the suffix carries SpeI and PstI sites. To join two parts, one is cut at its XbaI-side and the other at its SpeI-side. XbaI and SpeI leave compatible cohesive ends, so the fragments ligate. The junction is a "scar" that neither enzyme recognizes any more, and so the outer prefix and suffix stay intact. The product is itself a BioBrick and can be assembled again, which is why composites can be built up from composites.
The RFC10 scar is eight bases long. Eight is not a multiple of three, so the junction shifts the reading frame and cannot sit between two protein domains without disrupting the fusion. RFC25 was developed to allow in-frame protein fusions, which is why the specification names both standards. Two practical consequences follow for the registry:
The iGEM competition is the source of most BioBrick parts. Student teams design a genetic system, build it, and deposit their new parts in the Registry of Standard Biological Parts, whose records are the starting point for this standard. Teams typically supply their parts in the standard submission backbone, which is why plasmid backbones such as BBa_pSB1C3 (chloramphenicol resistance) appear as their own type. The standard's example metadata ("Team iGEM 2024", with an affiliation and contact) mirrors this authorship model. Team-contributed composites use the K series, as in BBa_K123456. Because the competition renews its teams every year, documentation quality and status codes matter. A good record is what lets later teams build on earlier work without having to contact the original authors.
The following sketch uses only the SDK functions shown in the specification. It searches for high-strength E. coli promoters, fetches each record, and keeps those whose fluorescence measurements were replicated. The search result is assumed here to be a list of records that each expose partId.
import { searchParts, getPartDetails } from '@wia/bio-021';
async function findReplicatedPromoters() {
const results = await searchParts({
type: 'promoter',
organism: 'E. coli',
strength: 'high'
});
const keep = [];
for (const r of results) {
const details = await getPartDetails(r.partId);
const ms = details.characterization?.measurements ?? [];
const good = ms.filter(m => m.type === 'fluorescence' && m.replicates >= 3);
if (good.length > 0) keep.push(r.partId);
}
return keep;
}The same registry can be driven from the shell. These commands come from the CLI reference:
wia-bio-021 search --type promoter --organism "E. coli"
wia-bio-021 get BBa_K123456
wia-bio-021 export --id BBa_K123456 --format sbol --output part.xml
wia-bio-021 import --file plasmid.gb --format genbankThe filter in the sketch only works because the measurement record is structured. If replicate counts were buried in free-text notes, a program could not apply it.
The standard's use cases are shared rather than industrial. The iGEM registry serves as a central repository for competition parts. Research laboratories maintain shared part libraries across institutions. Multiple teams can design collaboratively around the same records. The example parts in the specification show the kinds of devices this supports. A GFP expression device (BBa_K123456) is a reporter whose output can be measured in a plate reader. An inducible protein production system (BBa_K654321) combines regulatory and coding parts, and a LacI-regulated promoter such as BBa_R0011 is a typical building block for it. In each case the registry record is what lets a second laboratory assemble the device with confidence in the parts' behaviour.
Answer the following questions from the record fields described above, without consulting the exchange formats. If an answer needs a field that the core record lacks, that is a signal to look in the sequence, context or characterization blocks.
type field when identifiers already begin with a letter series?WIA-BIO-021 treats a genetic part as a record with several linked layers: a typed identifier, a required metadata core and a lifecycle status, a validated sequence in one of four interconvertible formats, and measurements that carry their own experimental context. A safety level and a license govern who may use the part and how. The BioBrick assembly standards (RFC10 and RFC25) explain why composites are recorded with their components and assembly method. The iGEM competition and the registries around it explain why these records must travel between systems without loss.
The next chapter turns from this overview to the data format itself. It takes the seven-type classification, the metadata blocks and the sequence feature structure field by field, and shows how each should be populated when a part is first registered.