Chapter 7
Phases 1 to 3 of WIA-BIO-021 define how a biological part is described, how it is exposed over HTTPS, and how registries exchange it. Phase 4 is where the registry meets the laboratory's actual toolchain. A part such as the Anderson promoter J23100 only matters if a designer can pull it into a plasmid editor, an assembly planner or a genetic-circuit compiler. The submitting lab must also be able to show that the sequence passed synthesis-order screening, and a partner registry must be able to trust that statement.
The Phase 4 material rests on four integration concerns:
Nothing here changes the Phase 1 envelope. Phase 4 explains how that envelope is consumed and where it must agree with the outside world.
Every adapter described later starts from one object: the canonical part envelope. The specification's complete example registers the promoter BBa_J23100. Its main blocks are summarized below.
| Block | Content in the example |
|---|---|
| Identity and class | partId, partName, type = promoter, subtype = constitutive, status = characterized, safetyLevel = BSL-1 |
| Sequence | nucleotides, length (35), format = raw, sequenceType = dna, and a checksum prefixed with sha256: |
| Biological context | organism (Escherichia coli), expressionHost (E. coli K12), compartment = genomic |
| Characterization | A measurements list. Each entry has type, value, unit, stdDev, replicates and method |
| Provenance | author, version, license (CC-BY-4.0), created, modified, references |
The measurement entry in the example is the part's strength: 1791, in RPU (relative promoter units), standard deviation 85, eight replicates, measured by a fluorescence assay with a GFP reporter. A bare number would be nearly useless to a downstream tool. Carrying unit, replicate count and method with it lets a designer judge whether two promoters measured in different labs are comparable.
The specification shows two shapes for the sequence. The registration request in the REST section abbreviates it as a plain string, while the full appendix record uses an object. An adapter should therefore be tested against the canonical object form and should tolerate the shorthand only where the host documents it.
The specification gives concrete validation snippets. The part-ID pattern is ^BBa_[PRBCETKV][0-9]{5,6}$. The sequence check accepts the letters A, T, C, G and N in either case for DNA, with a parallel pattern that substitutes U for RNA. It also rejects sequences shorter than 1 or longer than 1,000,000 characters.
Integrators should read these rules carefully, because they have two edge effects. First, the specification's own example ID, BBa_J23100, starts with the letter J, which is not in the pattern's letter class, and the pattern requires five or six digits. Read literally, the shipped pattern would reject the flagship example. A host that must carry legacy iGEM identifiers should confirm which pattern its deployment enforces rather than copying the snippet blindly. Second, the sequence function applies its character check only when the type is dna. The RNA pattern is defined but not used in the snippet, so an RNA-typed part needs its own check.
The accepted alphabet also includes N, an ambiguous base. Ambiguity codes are fine for storage, but an assembly planner cannot design primers across an N. Adapters should warn about N rather than pass the sequence through silently.
Phase 4 names the reference consumers of the registry. Benchling combines commercial design with an electronic lab notebook. SnapGene and Geneious are commercial sequence-design applications. j5 is open-source assembly automation, RAVEN is an open-source assembly tool, and Cello synthesizes genetic circuits.
The mix of commercial and open-source tools shapes the registry's role. A lab rarely works inside one program: it may sketch constructs in a commercial editor, hand the assembly plan to an open-source planner, and track samples in a notebook. A registry that spoke only one tool's format would lock its users in. By publishing one envelope and leaving the translation to adapters, the specification keeps the registry neutral. Each tool maintainer writes one adapter, and each lab keeps its preferred tool.
The specification states an important boundary here: adapters live outside the conformance scope, but the envelope they consume is conformance-tested. A tool vendor can ship an adapter without certification, yet it can rely on the envelope staying stable.
Each adapter takes the canonical part envelope as input and emits the analysis envelope that its design tool expects. Three typical flows illustrate this.
GET /api/v1/parts/{partId}?version=1.2.0&format=sbol. The response is RDF/XML containing an SBOL ComponentDefinition, which design software can import as an annotated feature with its sequence.characterization block earns its value, since a compiler can only rank promoters whose strength was recorded with a unit and method.Because the retrieval endpoint accepts an explicit version, a design can pin the exact revision of each part it used. Re-running the design months later then yields the same constructs even if a part has since been re-characterized.
The specification's Phase 4 appendix maps each concern to an external standard. Compliance for a registry is largely a question of which fields must stay consistent with these references.
| Concern | Standard |
|---|---|
| SBOL conformance | SBOL 2.3.0, SBOL 3.x |
| Sequence format | NCBI GenBank, FASTA, FASTQ |
| Aligned reads | SAM/BAM/CRAM (samtools spec) |
| Open material transfer | OpenMTA (BioBricks Foundation) |
| Biosafety risk groups | NIH Guidelines, WHO LBM4 |
| Dual-use research | WHO Framework for Responsible Life Sciences |
| Sequence sharing (security) | IGSC Harmonized Screening Protocol |
| Personal data | EU GDPR, US HIPAA (where human samples) |
Some of these rows bear directly on stored data. The safetyLevel field (BSL-1 in the example) is the registry's expression of a biosafety risk group, and error BIO006 (safety level violation) is raised when a part's classification conflicts with review. The license field connects to OpenMTA, which exists so that physical material can be shared under standard terms instead of one-off agreements. The personal-data row applies only when a part's records involve human samples. The reference list also cites ISO/IEC 17025 for the competence of testing laboratories, which is the usual yardstick for whoever produces the characterization measurements.
The recommended relational schema separates three concerns. A parts table holds identity, status, safety_level, the sequence, a 64-character sequence_hash, version, timestamps, author and license. A characterization_data table holds one row per measurement, with a numeric value, a unit, and the experimental conditions as JSONB. A version_history table records each version with a change description and the sequence hash at that moment.
Storing the hash in both parts and version_history makes one distinction cheap. The characterization update endpoint (PATCH /api/v1/parts/{partId}/characterization) returns a new version, 1.1.0 in the specification's example, without any change to the DNA. Comparing hashes across versions tells a consumer whether a revision altered the sequence or only added data. For a designer that is the difference between rebuilding a construct and merely reading new numbers.
For search, the specification calls for full-text indexing of part ID, name, description, sequence features, author and tags. Its Elasticsearch example maps partId and type as keywords, name and description as text, sequence with a custom dna_analyzer, and characterization as a nested object. The nested mapping matters because it keeps each measurement's type, value and unit together. A query for a promoter with strength in a given range then cannot accidentally match a value from one measurement and a unit from another. The search endpoint returns results with a relevance score, plus total and page.
Biosecurity is where Phase 4 differs most from a plain data catalogue. Contributing labs are expected to screen synthesis orders against the IGSC Harmonized Screening Protocol or an equivalent. The registry exposes a screening.passed flag on each part, together with the screening provider, the screening date and a hash of the screening receipt. The receipt hash lets a reviewer verify later that the flag corresponds to a real screening event. Federated registries are expected to honour the same flag, and a peer that does not is subject to a trust-class downgrade.
Failures surface through the registry's own error codes:
| Code | Meaning | Typical adapter response |
|---|---|---|
| BIO001 | Invalid part ID format | Correct the identifier before resubmitting |
| BIO003 | Invalid sequence | Check nucleotide characters |
| BIO004 | Missing required metadata | Add the required fields |
| BIO005 | Version conflict | Resolve the version history |
| BIO006 | Safety level violation | Review the biosafety classification |
| BIO008 | Format conversion failed | Check the input format |
Operationally, a team starts from the reference container, which ships every Phase 2 endpoint with mock data, and runs the conformance suite against it. It then replaces the mock backend one endpoint at a time. Within the 1.x line, hosts may add optional fields but must not remove existing ones, so adapters written today keep working.
The cross-walk already names two SBOL generations, 2.3.0 and 3.x, which signals that representation standards will keep moving. Adapters that isolate format translation from the canonical envelope are the part most likely to change, and the registry core the least. Screening is also likely to tighten. The flag, provider, date and receipt hash give a federation a common vocabulary for stronger checks later, without reshaping part records. Breaking changes are reserved for a major version, with a 12-month deprecation window.
No single registry holds every part. Labs, consortia and national repositories each keep their own collections, and Phase 3 defines how they exchange envelopes. Phase 4 adds the integration question of what a receiving registry should believe about a part from a peer. The screening flag is the clearest example: a registry that imports parts but ignores their screening status would let sequences bypass the checks that the originating lab performed. Hence the downgrade rule for peers that do not honour the flag.
Federation also depends on identity coherence. The IDs, hashes and version numbers in section 7.7 let two registries recognize that they hold the same sequence under the same version, or detect that they hold diverging ones. A part with the same ID but a different sequence_hash is a conflict, which is exactly what BIO005 exists to surface.
A registry entry describes DNA, but the lab must physically join it, and each joining method imposes constraints on what a part may contain. The specification cross-references the methods and their sources:
| Method | Reference | Working principle |
|---|---|---|
| BioBrick Assembly (RFC10) | Knight 2003 | Restriction sites in a standard prefix and suffix; parts join through compatible cut ends |
| Gibson Assembly | Gibson 2009 | One-pot joining of fragments with overlapping ends |
| Golden Gate / MoClo | Engler 2008 / Weber 2011 / RFC1000 | Type IIS enzymes cut outside their recognition site; MoClo layers parts into hierarchical levels |
| iBrick Assembly | RFC43 | Standard-part assembly using homing endonuclease sites |
| LCR (Ligase Cycling) | de Kok 2014 | Ligase-driven joining of oligonucleotide-bridged fragments |
| SLIC | Li 2007 | Sequence- and ligase-independent cloning |
| CPEC | Quan 2009 | Circular polymerase extension of overlapping fragments |
The practical consequence is that a part's compatibility depends on its internal sequence. For the original BioBrick standard, the part must not contain the restriction sites that the standard reserves for assembly. A sequence that is perfectly valid in the registry can still be unusable for one method while working for another. For that reason a planner adapter should scan the nucleotides against the chosen method before proposing an assembly, and should report conflicts as design warnings, not registry errors.
The identifier prefix BBa_ comes from the iGEM Registry of Standard Biological Parts. iGEM, the International Genetically Engineered Machine competition, asks student teams to design, build and test biological systems and to deposit the new parts they create into that shared collection. The specification lists the iGEM Registry Parts standard among its references, and the identifier pattern carries the same prefix, so teams' submissions fit its model. Competition entries come with documentation of how each part behaves, and that is what the characterization block formalizes. The registry therefore inherits both a naming habit and a documentation culture. What the WIA specification adds is machine-checkable structure: units, replicate counts, versions, safety level and screening evidence.
The following sketch combines the documented search endpoint with the documented retrieval endpoint. It searches for strong E. coli promoters, ranks them by the returned relevance, and fetches the best match in SBOL form. The ID check mirrors the specification's regex, so it inherits the edge case from section 7.3.
const BASE = 'https://registry.wiastandards.com/api/v1';
const partIdRegex = /^BBa_[PRBCETKV][0-9]{5,6}$/;
async function findParts({ type, organism, strength }) {
const qs = new URLSearchParams({ type, organism, strength });
const res = await fetch(`${BASE}/parts/search?${qs}`);
if (!res.ok) throw new Error(`Search failed: HTTP ${res.status}`);
const body = await res.json(); // { results, total, page }
return body.results.sort((a, b) => b.relevance - a.relevance);
}
async function fetchSbol(partId, version) {
// Note: legacy IDs such as BBa_J23100 do not match the shipped regex;
// enforce it only if your host does.
if (!partIdRegex.test(partId)) {
console.warn(`ID ${partId} does not match the documented pattern`);
}
const url = `${BASE}/parts/${partId}?version=${version}&format=sbol`;
const res = await fetch(url);
if (!res.ok) throw new Error(`Retrieval failed: HTTP ${res.status}`);
return res.text(); // application/rdf+xml
}
(async () => {
const hits = await findParts({
type: 'promoter', organism: 'E.coli', strength: 'high'
});
if (hits.length === 0) return;
const best = hits[0]; // e.g. BBa_J23100
console.log(best.partId, best.name, best.strength);
const sbol = await fetchSbol(best.partId, '1.2.0');
console.log(sbol.slice(0, 120));
})();
A production finder should also read the screening flag and the safety level before presenting a part. Filtering on strength alone would ignore half of what the registry knows about a part.
The same envelope serves different kinds of work. A metabolic-engineering group looks for promoters and ribosome-binding elements with documented strength in a given host, so it queries by organism and type. A biosensor team cares about the biological context and the compartment, and about the conditions under which the response was measured. A circuit designer relies on quantitative characterization so that a compiler can pick parts. Teaching labs and competition teams mostly need clear licensing and an unambiguous safety classification. In each case the value lies in uniform fields: the same unit, method and version semantics are present whichever registry or tool supplied the record.
sequence_hash between two versions tell a designer after a characterization update?screening.passed flag, and what happens to a federated peer that does not honour it?BBa_J23100 and rejects it with BIO001. Using the validation rules, explain the likely cause and decide how to fix the host rather than the part.Phase 4 connects the registry to the surrounding ecosystem without changing the part model. The canonical envelope, with its sequence, context, characterization and provenance blocks, feeds adapters for Benchling, SnapGene, Geneious, j5, RAVEN and Cello. A cross-walk ties the registry's fields to SBOL, GenBank, OpenMTA, NIH and WHO biosafety guidance, and the IGSC screening protocol. The assembly-method table reminds designers that a valid record may still be unusable for a particular joining chemistry. Screening evidence, carried as a flag with provider, date and receipt hash, becomes part of what federated registries must honour. We also found two places where the shipped snippets deserve care: the part-ID pattern versus legacy identifiers, and the unused RNA check.
With integration defined, the remaining work is operational. The next chapter picks up from here by asking what it takes to run these adapters and federation links as a service, starting from the reference container and the stepwise path of replacing mock data with real backends.