Chapter 4
A synthetic biology part is only as useful as the record describing it. A promoter sequence without its chassis, growth conditions, or measured strength cannot be reused with confidence. A name that two registries assign to different sequences is worse than no name. WIA-BIO-021 Phase 1 addresses this with a canonical description of what a registered part is, how it is named and classified, which metadata it carries, and how its sequence is stored and exchanged. Version 1.0.0 was published on 2025-12-26 by the WIA Biotechnology Research Group.
The stated purpose is a unified framework for registering, storing, and sharing parts. It is meant to let the major registries interoperate while preserving data integrity and reproducibility. The scope covers:
This chapter follows the Phase 1 material in the order a registrar meets it: classification, status and safety, metadata, sequences, and SBOL. The wire-level interfaces come in later phases.
The specification fixes a small vocabulary that the rest of the format depends on.
| Term | Meaning in WIA-BIO-021 |
|---|---|
| Part | A discrete DNA/RNA sequence with defined function |
| BioBrick | A standardized genetic part assembled under RFC10 or RFC25 |
| Device | A combination of multiple parts with integrated function |
| SBOL | Synthetic Biology Open Language |
| RFC | Request for Comments, the series in which BioBrick assembly standards are published |
| Characterization | Experimental data describing part behavior |
The BioBrick idea is that parts share a standard prefix and suffix carrying restriction sites. Any two parts can then be joined by digestion and ligation, and the product is itself a standard part that can enter the next round. RFC10 is the original scheme. RFC25 is the variant designed for in-frame protein fusions. The registry does not run assemblies. It records which method produced a composite and which components went into it, so another lab can repeat the construction. The standard also covers non-BioBrick parts, so a part need not follow either RFC to be registered.
Parts fall into seven primary categories, each with a short type code and a set of properties that a record should be able to describe.
| Type | Code | Naming convention | Properties to capture | Examples |
|---|---|---|---|---|
| Promoter | PRO | BBa_P[number] or BBa_J[number] | Strength (relative fluorescence units), inducibility, organism specificity, regulatory mechanism | BBa_J23100 (strong constitutive), BBa_R0011 (LacI-regulated) |
| Ribosome binding site | RBS | BBa_B[number] | Translation initiation rate, organism compatibility, spacing, secondary structure | BBa_B0034 (medium), BBa_B0030 (strong) |
| Coding sequence | CDS | BBa_C[number] or BBa_E[number] | Protein product, molecular weight, activity, expression conditions, codon optimization status | BBa_E0040 (GFP), BBa_E1010 (mRFP1) |
| Terminator | TER | BBa_B[number] or BBa_T[number] | Termination efficiency, directionality, context dependency | BBa_B0015 (double terminator), BBa_B0010 (T1 from E. coli rrnB) |
| Plasmid backbone | VEC | BBa_pSB[number] | Antibiotic resistance, origin of replication, copy number, cloning sites, size in bp | BBa_pSB1C3 (chloramphenicol, high copy), BBa_pSB1A3 (ampicillin, high copy) |
| Composite part | COM | BBa_K[number] | Component list, assembly method, expected function, validation status | BBa_K123456 (GFP expression device) |
| Regulatory element | REG | (none specified) | Binding protein or molecule, regulatory mechanism, affinity or binding constant | Operators, protein binding sites |
The property lists follow the biology. A promoter's strength is meaningful only relative to a reference and a host. A ribosome binding site depends on spacing and local RNA structure. A terminator works differently depending on context and direction. Backbone properties such as copy number and resistance marker are what a bench scientist checks before choosing a vector. Note that BBa_B is shared by ribosome binding sites and terminators. The prefix letter alone does not determine the type, so the type field must be recorded explicitly.
An identifier has three parts: a registry prefix, a unique alphanumeric body, and an optional version suffix. The prefix BBa_ belongs to the iGEM Parts Registry, and WIA_ to WIA-managed registries. The prefix tells a consumer which authority issued the name, which prevents the collision problem described in 4.1.
Versioning has a deliberate twist. A new version of an existing part receives a new identifier, and the older record is preserved with a replacedBy link. A consumer who built on an earlier version can still find that exact record and see where the lineage moved. This reflects the fact that in a wet lab a silent change to a sequence behind an unchanged name breaks experiments. The metadata record also carries a semantic version string such as 1.2.0 for revisions of the record itself.
The 1.x line has a compatibility promise. Hosts may add optional fields and new envelopes but must not remove existing ones, so a record written today stays readable by later 1.x consumers.
Every part has a lifecycle status, which tells a user how much evidence stands behind it.
| Status | Code | Description |
|---|---|---|
| Planning | PL | Part design phase |
| Ordered | OR | DNA synthesis ordered |
| Available | AV | Part available in registry |
| Characterized | CH | Experimental data available |
| Validated | VA | Independently verified |
| Deprecated | DP | Superseded or problematic |
| Deleted | DL | Removed from registry |
The sequence runs from intent (planning, ordered) through physical existence (available) to evidence (characterized, then independently validated). A part that is available but uncharacterized has been built, but nobody has yet said how it behaves. The jump from characterized to validated depends on someone other than the contributor reproducing the result. Deprecated is distinct from deleted. A deprecated part stays visible so people who used it can learn why it was superseded or found problematic.
Parts also carry a safety level on the biosafety scale:
BSL-1: Minimal risk (e.g., GFP, standard promoters)
BSL-2: Moderate risk (e.g., mammalian cell work)
BSL-3: Serious risk (e.g., pathogenic organism parts)
BSL-4: Extreme risk (restricted access)Biosafety levels were originally defined for laboratory containment of organisms and work. Here they are applied as a per-part tag, so a registry can decide who may see a record and what warning accompanies it. The BSL-4 level is explicitly tied to restricted access, which links safety classification to the access-control provisions of the full specification.
Every registered part MUST include a core record. The specification's example is a composite reporter device:
{
"partId": "BBa_K123456",
"partName": "Strong GFP Expression Device",
"type": "composite",
"subtype": "reporter",
"status": "available",
"safetyLevel": "BSL-1",
"author": {
"name": "Team iGEM 2024",
"affiliation": "MIT",
"email": "igem@mit.edu"
},
"created": "2024-06-15T10:30:00Z",
"modified": "2024-08-20T14:45:00Z",
"version": "1.2.0",
"license": "CC-BY-4.0"
}Three points deserve attention. First, the example expresses type and status as lower-case words, while the classification tables define short codes (COM, AV). Implementers should treat the codes and the words as two spellings of the same vocabulary and not invent a mapping beyond the one the tables give. Second, created and modified are separate UTC timestamps, so a record's age and its last edit can be told apart. Third, a license is mandatory. A part that cannot be legally reused is of little value to a shared registry.
Beyond this core, the appendix material describes the provenance a mature registry should keep: design provenance (designer, date, design tool), lab provenance (constructing lab, batch, date), sequencing verification (Sanger or NGS read coverage and variant calls), and characterization context. It also says metadata is signed by the contributing institution's key, so a consumer can check who stood behind the record.
The sequence block holds the nucleotides together with the information needed to verify and interpret them:
{
"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 features array is where a composite part describes its own internals: a promoter spanning positions 1 to 35, then a ribosome binding site from 40 to 52, each with a strand and a name that points back to the component part. The example starts at position 1, matching the 1-based convention used by GenBank locations. sequenceType allows protein as well as DNA and RNA, which accommodates records whose primary description is the product rather than the gene. The checksum carries a SHA-256 value so that any later copy can be compared against the registered one.
The appendix adds descriptors a part envelope may carry: length, GC content, a codon-usage profile where relevant, and the chassis organisms in which the part has been characterised. GC content and codon usage matter in practice because they affect synthesis feasibility and expression in a given host.
A sequence does not behave the same way everywhere, so the format records where it was observed:
{
"organism": "Escherichia coli K12",
"strain": "DH5α",
"growthConditions": {
"temperature": 37,
"medium": "LB",
"antibiotics": ["chloramphenicol"],
"inducers": []
},
"expression": {
"expressionHost": "E. coli",
"compartment": "cytoplasm",
"tags": ["His6"],
"fusionPartners": []
}
}Strain, medium, antibiotic selection, and inducers are exactly the variables that make fluorescence readings differ between labs. Recording expression compartment, purification tags, and fusion partners lets a reader tell whether a measurement was made on the native protein or on a modified version. An empty inducers list in the example is meaningful: it says the part was measured without induction, which is how a constitutive promoter is expected to be run.
The documentation block holds a free-text description and designNotes for engineering considerations. It also holds references (publication type, DOI, title, authors, year) and externalLinks to other databases, such as a GenBank accession or an iGEM part page URL. These links let a record in one registry point to its counterpart in another.
The core specification requires support for four formats, and the appendix extends the list for sequencing data.
| Format | Carries | Notes |
|---|---|---|
| Raw DNA/RNA | Plain nucleotide string | No identifier, no annotation |
| FASTA | Header line plus sequence | Sequence only |
| GenBank | Sequence, features, annotations | Round-trip preservation of comments, dates, and free-text notes is guaranteed |
| SBOL (RDF/XML in the core text) | Structured component data | The interoperability format; SBOL 3.x JSON is also accepted per the appendix |
| FASTQ, BAM/CRAM | Raw and aligned reads | Listed in the appendix for sequencing evidence |
Internal canonical storage normalises to SBOL 3.x, and export endpoints emit any supported format on demand. Implementations MUST convert bidirectionally between the supported formats. Conversion is where information is usually lost: FASTA cannot hold features, and a naive conversion from GenBank to FASTA drops them. That is why the guarantee about preserving comments, dates, and notes is stated for GenBank and SBOL specifically.
The specification's FASTA example uses the header >BBa_E0040 Green Fluorescent Protein, with the identifier first and the description after it. Its GenBank example declares LOCUS BBa_E0040 720 bp DNA linear SYN and a CDS 1..720 feature with /codon_start=1. One detail of that example shows why validation matters. The nucleotides begin ATG CGT AAA GGA GAA GAA CTT TTC, which translates to M-R-K-G-E-E-L-F, yet the example's /translation qualifier begins MSKGEEL. A registry that stored a translation qualifier alongside nucleotides should be able to detect such a mismatch rather than trust either field blindly.
All sequences MUST pass five checks: character validation (valid nucleotide codes such as A, T, C, G, U, N), length validation (minimum 1 bp, maximum 1,000,000 bp), checksum verification, feature consistency (no feature may extend beyond the sequence boundaries), and optional biological validity checks such as forbidden sequences and restriction sites. The last matters for BioBrick work: an internal copy of an assembly-standard restriction site can make a part unusable in that scheme, even though the sequence is otherwise perfectly valid DNA.
The following sketch applies the first four checks to a record shaped like the example in 4.7. It is illustrative. The excerpt does not say exactly what bytes the checksum covers, so hashing the upper-cased nucleotide string is an assumption an implementer must confirm.
import hashlib
VALID = set("ACGTUN") # extend with IUPAC ambiguity codes as needed
def validate(seq):
errors = []
nt = seq["nucleotides"].upper()
if not nt or len(nt) > 1_000_000:
errors.append("length out of range")
if set(nt) - VALID:
errors.append("invalid nucleotide code")
if seq.get("length") != len(nt):
errors.append("declared length mismatch")
algo, _, digest = seq["checksum"].partition(":")
if algo != "sha256" or hashlib.sha256(nt.encode()).hexdigest() != digest:
errors.append("checksum mismatch")
for f in seq.get("features", []):
if f["start"] < 1 or f["end"] > len(nt) or f["start"] > f["end"]:
errors.append("feature outside sequence: " + f["name"])
return errorsPlaceholder values such as ATGCGT... and sha256:abc123... in the specification's examples are abbreviations. They would, of course, fail a real validator.
SBOL is the format through which registries exchange structured designs. The core text requires SBOL 2.3.0 or higher. The appendix states that WIA-conformant registries support both 2.3.0 and 3.x, accept either on import, and export 3.x by default with a compatibility flag for clients still on 2.3.0. The core examples use the SBOL 2 vocabulary, in which each part is a ComponentDefinition:
<sbol:ComponentDefinition rdf:about="http://wiastandards.com/BBa_K123456">
<sbol:displayId>BBa_K123456</sbol:displayId>
<sbol:version>1.2.0</sbol:version>
<dcterms:title>Strong GFP Expression Device</dcterms:title>
<sbol:type rdf:resource="http://www.biopax.org/release/biopax-level3.owl#DnaRegion"/>
<sbol:role rdf:resource="http://identifiers.org/so/SO:0000804"/>
<sbol:sequence rdf:resource="http://wiastandards.com/BBa_K123456_sequence"/>
</sbol:ComponentDefinition>The type says the part is a DNA region. The role is a Sequence Ontology term that says what the DNA does, and the example uses SO:0000804 for an engineered region. A separate Sequence object holds the elements and an encoding, so the same sequence can be referenced rather than duplicated. A composite part must define its hierarchy with Component objects. In the specification's example, a component of BBa_K123456 points through definition to BBa_J23100 and has public access. This is the machine-readable form of the feature list in 4.7.
The appendix lists the required SBOL classes as Component, Sequence, SequenceFeature, and Implementation, and requires subComponent for compositional relationships instead of the deprecated Module. Implementation is the natural home for the physical realisation of a design, such as a built clone. This is the difference between a design and a material that exists in a freezer.
Phase 1 turns the informal habits of parts registries into a checkable record. Seven part types with naming conventions give each part a place in the catalogue. Seven lifecycle states and four safety levels show how much evidence and risk attach to it. A required metadata core, with sequence, chassis, and documentation blocks, makes the record reproducible. Sequence validation guards against corrupted or inconsistent data. Format conversion and SBOL carry the record between tools and registries. Versioning by new identifier plus replacedBy keeps lineage intact, and the 1.x line may only add fields, never remove them.
The format also has gaps that implementers must resolve: two spellings of type and status, an unspecified checksum input, and a core text that names ComponentDefinition while the appendix prefers SBOL 3.x classes. Resolve these against the conformance material before building on them. The next chapter moves from the shape of the record to access: how these envelopes are surfaced over HTTPS so that a client can search, retrieve, and submit parts, including the BioBrick part finder that the iGEM community has long needed.