Chapter 6
Phase 1 of WIA-BIO-021 fixes the shape of a part record, and Phase 2 exposes those records over HTTPS. Phase 3 deals with what happens after a part has been published. A promoter that one laboratory characterized in 2024 may be re-optimized by another team months later. A part may be licensed to academics but not to companies. A record may be requested by a registry that has never heard of its author. The protocol layer therefore defines three things:
Phase 3 must handle a property specific to biological parts: a part is a DNA sequence, and a single changed base can alter behavior in a living cell. A software library can often absorb a small change silently. A genetic circuit that has been assembled, sequenced and characterized cannot. Much of this phase is therefore about making change visible, attributable and reversible in the record, even when it cannot be reversed in the freezer.
Once published, a part record is immutable. An update does not overwrite the old record. It creates a new version with a new identifier. The earlier version is kept, carries a replacedBy link, and receives a deprecation notice. Consumers can therefore always retrieve exactly what a published paper or earlier design referred to.
The version history is a directed acyclic graph, not a flat list. Two groups may edit the same ancestor independently, and the protocol permits such forks. Merging two lines of descent is deliberately not automatic. It follows an explicit-acknowledgement model in which the contributing institutions co-sign the merge. The reasoning is practical. Two sequence edits that each worked in isolation may interact badly, and a merge should record that someone accepted responsibility for the combined result.
A consumer who wants to understand a part's lineage walks the graph from the current version back through its ancestors. Each node says who changed what, when, and whether the underlying sequence differs from its parent.
Parts use MAJOR.MINOR.PATCH, with the meaning of each position tied to the sequence:
| Increment | Trigger | Example from the specification |
|---|---|---|
| MAJOR | Incompatible sequence change | 1.1.0 → 2.0.0, sequence optimization |
| MINOR | Backward-compatible addition | 1.0.0 → 1.1.0, new characterization data |
| PATCH | Bug fix or documentation update | 1.1.0 → 1.1.1, typo fixed in description |
The history entries carry a sequenceHash next to each version. This makes the rule checkable. In the specification's own example, versions 1.0.0 and 1.1.0 share the same hash because only fluorescence data was added, and 2.0.0 has a different hash because the sequence was codon-optimized for mammalian cells. A registry can therefore flag an inconsistent record, such as a MAJOR bump with an unchanged hash or an unchanged MAJOR number with a changed hash. The example below is shortened from the specification:
{
"versionHistory": [
{ "version": "1.0.0", "author": "initial-creator",
"changes": "Initial part submission",
"sequenceHash": "sha256:abc123..." },
{ "version": "1.1.0", "author": "lab-member-2",
"changes": "Added fluorescence characterization",
"sequenceHash": "sha256:abc123..." },
{ "version": "2.0.0", "author": "optimization-team",
"changes": "Codon optimization for mammalian cells",
"sequenceHash": "sha256:def456..." }
]
}The registry ecosystem is split between sites that hold information about parts and sites that hold the physical DNA. The specification models this split in a materialTransfer block, which records whether material is available and from which provider. It also records the provider's catalog number, cost with currency, shipping restrictions, and whether a material transfer agreement is required:
{
"materialTransfer": {
"available": true,
"provider": "Addgene",
"catalogNumber": "12345",
"cost": 65.00,
"currency": "USD",
"shippingRestrictions": ["country:CN", "country:IR"],
"requiresMTA": true
}
}Shipping restrictions are part of the record because moving biological material across borders is regulated, and a researcher should learn that before designing around a part they cannot receive. The licensing model also matters commercially. A part under a restricted licence behaves differently for a startup than for a teaching lab, and the protocol makes that difference explicit at read time rather than leaving it in a PDF.
Parts are rarely wrong in the sense of being invalid. More often a better part appears, for instance one with improved expression. The deprecation block lets the registry say so without removing anything:
{
"deprecation": {
"deprecated": true,
"date": "2024-11-15",
"reason": "Superseded by BBa_K789012 with improved expression",
"replacementPart": "BBa_K789012",
"stillAvailable": true
}
}The stillAvailable flag matters in a laboratory setting. A team midway through a project, with a validated construct already in the freezer, needs the old part's record to remain retrievable even after a better alternative exists. A consumer such as a design tool can use replacementPart to suggest an upgrade while still allowing the original to be resolved.
The design tools named in the provenance protocol (Benchling, SnapGene, Geneious, j5, RAVEN and Cello) are where this metadata gets used day to day. A part that appears in a Cello-generated circuit or a j5 assembly plan carries its version, its history and any deprecation notice with it.
Every part carries licence terms, and the protocol exposes both the licence and the contributor declarations on every read. The specification lists six supported licences:
| Licence | Code | Meaning |
|---|---|---|
| CC-BY-4.0 | CC-BY | Attribution required |
| CC-BY-SA-4.0 | CC-BY-SA | Share-alike required |
| CC0-1.0 | CC0 | Public domain |
| MIT | MIT | Permissive software licence |
| Proprietary | PROP | Custom terms required |
| OpenMTA | OMTA | Open Material Transfer Agreement |
In practice these fall into three families: open use with attribution, open use under copyleft (CC-BY-SA or OpenMTA), and restricted use such as academic-only. The inclusion of OpenMTA reflects a biological reality. Sharing a plasmid is the transfer of a physical object, not only a copy of information, so a material agreement can apply even when the sequence is openly documented. When a commercial user's request intersects a restricted-licence part, the protocol emits a typed licensing.restricted event instead of silently refusing or silently allowing the request.
Access is described at two levels. The coarse level has three tiers:
The fine level is the accessControl object, which assigns roles to four actions:
{
"accessControl": {
"visibility": "public|private|restricted",
"permissions": {
"view": ["public"],
"download": ["registered-users"],
"modify": ["part-owner", "admin"],
"characterize": ["registered-users"]
},
"embargoUntil": "2025-01-01T00:00:00Z",
"requiresAgreement": true,
"agreementUrl": "https://example.com/mta.pdf"
}
}Separating characterize from modify is a deliberate choice for this domain. Registered users can add measurements to a part, which is how a registry accumulates evidence, but only the owner or an administrator can change the part itself. The embargoUntil field supports a common research pattern: a team can register a part before a publication appears and have it become visible only afterwards. Where requiresAgreement is set, the agreementUrl points to the terms a requester must accept first.
Federation lets a search at one registry surface results from peers. The specification names the iGEM Registry, JBEI Public Inventories, Addgene and institutional repositories as examples. A federated result arrives in an envelope that carries four things: the source registry, the source part identifier, the resolution policy (cached copy or live lookup), and the trust class.
The trust class tells a downstream consumer whether it may rely on the record without independent verification. It is derived from four declared properties of the peer:
| Factor | Values |
|---|---|
| Biosecurity screening | Declared support for the IGSC Harmonized Screening Protocol |
| Signing-key custody | HSM-backed, software-only, or shared |
| Audit-log retention | At least 10 years, at least 5 years, at least 1 year, or undeclared |
| Curation-board membership | Member or non-member status |
The first factor links the registry to DNA biosecurity: it asks whether a peer participates in the harmonized approach to screening synthetic sequences. Peers with weaker classes are not rejected. Their records are flagged at retrieval time, and a consumer can decide that a record is good enough for browsing but not for ordering material.
Alongside the version graph, every part keeps a provenance graph describing how it came to exist. For each step it names the design tool, the design parameters, the assembly method (cross-walked in Phase 4 §A.4), the sequencing verification, and the laboratory that performed the work. The responsible institution signs the graph at every step.
The aim is for a downstream user to verify the chain without having to ask. A part that appears in a registry with a sequence trace and a named verifying laboratory carries more evidence than a bare sequence string. A user can also see at a glance whether a sequence was only designed in software or was also confirmed by sequencing.
As more laboratories contribute measurements, disagreement is inevitable. When two contributors submit overlapping characterization data with conflicting headline values, the protocol layer does not average them or let the later one win. It flags the conflict and routes it to the registry curator, who has three options: let one record supersede the other, retain both with annotations, or escalate to the principal investigators of the contributing institutions. The conflict envelope stays in the audit log for later researchers.
The audit log records the actor, the action, the resource identifier, hashes of the state before and after, and an Ed25519 signature made with the actor's institutional key. Each entry includes the previous entry's signature, so tampering is detectable. Retention is bounded by the lower of ten years, the academic provenance norm, or the donor-consent window where a part derives from human or non-public material. Bulk imports are idempotent on the hash of the part-identifier set, and control-plane calls use a 96-bit nonce with a 300-second skew window.
Disputed records, deprecation requests and federation policy changes go to a curation board with rotating, staggered two-year terms. Its decisions are published together with the dissent record, and a ruling can be appealed once to the full board on new evidence.
A synthetic biology registry sits between design software, DNA synthesis and assembly laboratories, and repositories that store physical clones. The part record is the object that ties these together. The design tool reads its sequence and metadata, the assembly lab uses its identifier, and the repository ships the matching material. Phase 3 is the point at which these independent actors begin to share records across organizational boundaries instead of within one site.
BioBrick parts are DNA fragments flanked by a standard prefix and suffix. The prefix carries EcoRI and XbaI sites and the suffix carries SpeI and PstI sites. XbaI and SpeI leave compatible cohesive ends, so two parts can be joined, and the junction is no longer cut by either enzyme. The result is itself a BioBrick that can be composed again. This composability is why the identifier and the sequence must stay stable. A composite part refers to its components, and if a component's sequence were silently replaced, every composite built from it would change meaning. The MAJOR/MINOR/PATCH rules and the sequence hash are the registry's guard against that outcome.
The iGEM competition engages student teams who design, build and test engineered biological systems and contribute new parts to the iGEM Registry. Part identifiers of the form BBa_..., such as the BBa_K789012 used in the deprecation example, descend from this tradition. The competition shows why the protocol needs both licensing and curation. A large number of contributors with varying experience submit parts every year, and later teams rely on the accumulated records. Versioned history, attributable characterization data and a deprecation path let a registry grow without becoming unreliable.
The following Python sketch works on parsed records that use the field names shown earlier in this chapter. It does not call any registry endpoint, and the catalog is a dictionary keyed by part identifier. It follows deprecation links to a current part, checks whether a part can be shipped to a country, and verifies that MAJOR bumps match sequence-hash changes.
from datetime import datetime, timezone
def resolve(catalog, part_id, max_hops=5):
"""Follow replacementPart links from deprecated parts."""
for _ in range(max_hops):
rec = catalog[part_id]
dep = rec.get("deprecation", {})
nxt = dep.get("replacementPart")
if not dep.get("deprecated") or not nxt or nxt not in catalog:
return part_id, rec
part_id = nxt
return part_id, catalog[part_id]
def can_ship(record, country_code):
mt = record.get("materialTransfer", {})
blocked = mt.get("shippingRestrictions", [])
return mt.get("available", False) and ("country:" + country_code) not in blocked
def publicly_visible(record, now=None):
ac = record.get("accessControl", {})
if ac.get("visibility", "private") != "public":
return False
until = ac.get("embargoUntil")
if until:
now = now or datetime.now(timezone.utc)
return now >= datetime.fromisoformat(until.replace("Z", "+00:00"))
return True
def semver_consistent(record):
"""MAJOR bump if and only if the sequence hash changed."""
hist = sorted(record["versionHistory"], key=lambda h: h["date"])
for prev, cur in zip(hist, hist[1:]):
major_up = int(cur["version"].split(".")[0]) != int(prev["version"].split(".")[0])
seq_changed = cur["sequenceHash"] != prev["sequenceHash"]
if major_up != seq_changed:
return False
return TrueApplied to the version history in section 6.3, semver_consistent returns true. Running resolve on a deprecated part whose replacement is present returns the replacement. If the replacement is absent from the local catalog, it returns the original record rather than failing, which matches the intent of stillAvailable. The hop limit in resolve is a local safeguard of this sketch, not a rule from the specification.
Typical uses of registry parts include biosensors, metabolic pathway engineering, logic-gate circuits designed with tools such as Cello, and cell-based therapeutics. The protocol features matter differently in each. A biosensor developer cares about characterization data and whether a newer version changed the sequence. A metabolic engineer working in a new host cares about codon-optimized MAJOR versions. A therapeutics group working with human-derived material is the main reason for the donor-consent bound on audit-log retention and for strict access tiers.
characterize permission from the modify permission, and why might a registry separate them?Phase 3 treats a registry part as a long-lived scientific object, not as a mutable database row. Records are immutable and form a version graph. Semantic versioning is tied to the sequence hash. Deprecation retires parts without erasing them. Licences and access tiers are exposed on every read, and material transfer records carry cost, provider and shipping restrictions. Federation envelopes carry a trust class derived from screening support, key custody, audit retention and curation membership, and a provenance graph signed at each step lets consumers verify how a part was made. Curators resolve conflicts, and the audit log preserves the decisions.
Within the 1.x line, every Phase 1 envelope, Phase 2 endpoint and Phase 3 exchange must stay reachable. Hosts may add optional fields but may not remove existing ones, and breaking changes need a major version bump with a 12-month deprecation window. Phase 4 builds on this foundation by integrating the registry with the surrounding ecosystem. That includes the assembly-method cross-walk that the provenance graph already refers to, and the shared identity and audit services used by other WIA family standards.