Chapter 8
Where the WIA-BIO-016 data model stops, what the newer modalities need from it, and how to evolve the specification, SDK and CLI without breaking the records people have already stored.
The previous seven chapters worked inside the boundary that WIA-BIO-016 v1.0 draws for itself: monoclonal antibodies and their fragments, antibody-drug conjugates, Fc-fusion proteins, recombinant proteins and vaccines, all described through the TypeScript type model in types.ts, computed through BiopharmaSDK and the wia-bio-016 shell tool, and organised around a development workflow that ends in a regulatory dossier. This last chapter looks outward. Biologics development has moved on in directions that a flat record such as DrugCandidate cannot express, and the standard itself carries defects that earlier chapters had to teach around. Both facts point to the same job: deciding what the next version of the standard should contain.
The chapter is deliberately conservative. It does not forecast markets or predict which modality will win; it names concrete gaps in the published types, shows what a field-level fix would look like, and explains how to ship those fixes under semantic versioning so that a record written against v1.0 still means the same thing after an upgrade. Every schema fragment below is a proposal made for discussion, not part of the normative v1.0 text.
types.ts does not have.
The v1.0 model has two ways of saying what a product is. DrugClass gives the broad category (monoclonal-antibody, antibody-fragment, fusion-protein, cytokine, enzyme, vaccine, antibody-drug-conjugate, peptide, recombinant-protein), and AntibodyFormat refines antibodies into full-igg, fab, scfv, diabody, bite, nanobody and dart. That is enough to label a product. It is not enough to describe one, because nothing else in the model changes when the label changes: a nanobody and a full IgG share the same DrugCandidate record, the same molecular-weight check and the same quality attributes. The sections below take each under-covered modality in turn and ask what a record would need to hold.
The only bispecific formats in the enumeration are bite and dart, both small fragment-based constructs. Since those formats appeared, a large family of IgG-like bispecifics has been developed, in which two different heavy chains are forced to pair by engineering the Fc interface (the "knobs-into-holes" approach is the best known) and light-chain mispairing is avoided by a common light chain or by domain crossover. Emicizumab, which bridges coagulation factors IXa and X, is an approved example of a full-length bispecific IgG. Beyond two specificities, trispecific and other multispecific constructs are in development.
For a data model, the important point is that a bispecific is not one binding event but several. The v1.0 BindingAffinity record holds one antibody, one antigen and one complex concentration; DrugCandidate holds exactly one target string and one targetAffinity. A bispecific T-cell engager needs at least two affinities (tumour antigen and CD3), and its developers often deliberately tune the two to be very different. Chain-pairing variants also become a new class of product-related impurity: a mispaired molecule is not an aggregate, not a fragment and not a charge variant, so none of the fields in QualityAttributes can hold it.
There is also a validation trap. validateDrugCandidate() warns whenever a monoclonal-antibody falls outside 145–155 kDa. Many IgG-like bispecifics sit near 150 kDa and pass, but formats with appended domains do not, and they will draw a warning that says nothing useful about them. The check is a reasonable guard for conventional IgGs and a misleading one for everything else, which is an argument for making format-specific rules explicit rather than keying them off the drug class.
nanobody is already in AntibodyFormat. Single-domain antibodies are derived from the variable domain (VHH) of camelid heavy-chain-only antibodies; a single VHH is roughly a tenth of the mass of an IgG, and constructs are frequently built by linking two or more domains, sometimes including one that binds serum albumin to extend half-life. Caplacizumab, an anti-von Willebrand factor product, is an approved example.
What the model lacks is any way to record that construction: how many domains, which of them bind which targets, what linkers join them and whether a half-life extension module is present. Without those fields, two nanobody products with completely different pharmacokinetic behaviour look identical in a v1.0 record. The consequence shows up in Chapter 4's PK functions: calculatePharmacokinetics() will happily compute a half-life from whatever clearance and volume it is given, but the record gives a reviewer no clue why one nanobody clears in hours and another persists for much longer.
In v1.0, viral vectors appear only as a VaccineType value (viral-vector), and the specification lists adenovirus, AAV and lentivirus as vaccine vectors in §2.4.2. In current practice the same vector families are also used as the therapeutic product itself: AAV-based gene therapies deliver a transgene in vivo, and lentiviral vectors are used ex vivo to modify a patient's own cells, as in CAR-T therapies. None of these fits DrugClass, and none of the model's quality attributes are the ones that matter for them.
This book stays at the level of data structure. The attributes that regulators and developers discuss for these products are well known in outline: for vector products, a measure of dose expressed as vector genomes, the ratio of full to empty capsids, identity of the transgene and potency; for cell products, identity, viability, the fraction of cells carrying the modification, and chain-of-identity information that links a manufactured batch to the individual patient it came from and must return to. The last item has no analogue anywhere in v1.0. The standard's product model assumes that one batch serves many patients; an autologous product inverts that assumption, and the data model must carry a patient-to-batch link with the same care it gives any other identifier.
Because these products are regulated under their own frameworks (in the EU as advanced therapy medicinal products), the most honest v2 approach is not to stretch DrugClass but to add a separate, clearly scoped profile that can reuse the common parts of the model (RegulatorySubmission, StabilityResult) while defining its own attribute set.
The model treats mRNA only as a vaccine type. Therapeutic uses of mRNA outside vaccination, such as producing a missing protein or delivering the components of a gene-editing system, are under clinical investigation. Whatever the application, the product is a nucleic acid in a lipid nanoparticle, and its critical attributes are different from a protein's: RNA integrity, capping efficiency, poly(A) tail length, encapsulation efficiency, particle size and lipid composition. None of these can be recorded in ProteinCharacterization, whose fields (sequence, pI, extinction coefficient, glycosylation sites, disulfide bonds) presuppose a protein.
The practical lesson is that "vaccine" is a use, while "mRNA-LNP" is a product architecture. v1.0 conflates the two. A v2 model is easier to maintain if it separates what the molecule is (protein, conjugate, nucleic acid-LNP, vector, cell) from what it is for (therapy, prophylaxis), so that attribute sets attach to the former and indications to the latter.
The table gathers the gaps discussed in this section and in 8.2. The "proposed type" column names interfaces that do not exist in v1.0; they are sketched later in this chapter and would need review before adoption.
| Modality | What v1.0 has | Missing fields | Proposed type |
|---|---|---|---|
| IgG-like bispecific / multispecific | AntibodyFormat: bite, dart | List of binding arms with target and Kd each; Fc-pairing strategy; chain-mispairing variants (%) | BindingArm[], MultispecificAttributes |
| Single-domain antibody | AntibodyFormat: nanobody | Number of domains, linker, half-life extension module | DomainArchitecture |
| Antibody-drug conjugate | DrugClass: antibody-drug-conjugate | Mean DAR, DAR distribution, conjugation site strategy, linker type, payload class, free payload, unconjugated antibody | ConjugateAttributes |
| AAV / lentiviral product | VaccineType: viral-vector only | Vector genome titre, full/empty ratio, transgene identity, potency | Separate VectorProductProfile |
| Autologous cell therapy | None | Chain of identity (patient ↔ batch), viability, transduced fraction, identity | Separate CellProductProfile |
| Therapeutic mRNA-LNP | VaccineType: mrna | RNA integrity, capping, poly(A) length, encapsulation efficiency, particle size | NucleicAcidLNPAttributes |
The specification introduces ADCs in §2.2 as antibody + linker + cytotoxic drug and defines the drug-to-antibody ratio as total drug molecules divided by total antibody molecules, typically between 2 and 8, with "optimal DAR = 3–4 for most ADCs". Chapter 1 used that framing to explain the anatomy. The type model, however, stops at the label: DrugClass contains antibody-drug-conjugate, and there is not a single field for DAR, linker or payload anywhere in types.ts. An ADC stored under v1.0 is indistinguishable from its naked antibody.
Early ADCs were made by conjugating to native lysines or to cysteines released by partial reduction of interchain disulfide bonds. Both approaches give a mixture: lysine conjugation can place the drug at many possible positions, and cysteine conjugation produces species carrying 0, 2, 4, 6 or 8 drugs. Site-specific methods (engineered cysteines, non-natural amino acids, enzymatic tagging, and remodelling of the Fc glycan) aim to fix both the number and the location of the drug. The motivation is not tidiness; species with different drug loads can differ in clearance, potency and tolerability, so the distribution itself is a quality attribute.
This is why a single "mean DAR" number is inadequate as a record. Two lots with the same mean can have different distributions, and a lot with a large unconjugated fraction dilutes efficacy while a lot with a large high-DAR fraction can clear faster. Analytical practice reflects this: hydrophobic-interaction chromatography resolves drug-load species for cysteine-linked ADCs, mass spectrometry measures load directly, and free (unconjugated) payload is measured separately because it is a potent impurity.
The spec's "optimal 3–4" should therefore be read as historical guidance rather than a rule. Some later ADCs deliberately use higher drug loads together with more hydrophilic linker-payloads, and the right DAR is a property of the whole construct, not a universal constant. A v2 text should state the definition and require the distribution to be reported, and drop the single optimum.
Linkers are broadly cleavable (for example, protease-sensitive peptide linkers, acid-labile hydrazones, reducible disulfides) or non-cleavable (the drug is released only after the antibody is degraded in the lysosome). Payloads fall into a few mechanistic families: microtubule inhibitors such as auristatins and maytansinoids, topoisomerase I inhibitors, and DNA-damaging agents. Linker and payload together determine whether released drug can diffuse into neighbouring cells, what the dominant toxicities are and which impurities must be controlled. None of that needs to be encoded in detail in a data standard, but a record should say which class the product belongs to so that downstream tools can apply the right checks.
ConjugateAttributes typeThe fragment below shows one way to add ADC data without disturbing existing records. Everything is optional at the top level of the product, so a v1.0 record remains valid. The distribution is an array of load/abundance pairs whose abundances should sum to about 100; the mean can be computed from it, which gives a built-in consistency check.
// PROPOSAL for WIA-BIO-016 v1.1 — not part of v1.0
export type ConjugationStrategy =
| 'lysine' | 'interchain-cysteine' | 'engineered-cysteine'
| 'non-natural-amino-acid' | 'enzymatic' | 'glycan-remodelling';
export type LinkerType = 'cleavable-peptide' | 'cleavable-hydrazone'
| 'cleavable-disulfide' | 'non-cleavable' | 'other';
export type PayloadClass = 'microtubule-inhibitor'
| 'topoisomerase-i-inhibitor' | 'dna-damaging' | 'other';
export interface DarSpecies {
drugLoad: number; // drugs per antibody, e.g. 0, 2, 4, 6, 8
abundance: number; // % of total antibody species
}
export interface ConjugateAttributes {
conjugation: ConjugationStrategy;
linker: LinkerType;
payloadClass: PayloadClass;
meanDar: number; // reported value
darDistribution?: DarSpecies[]; // HIC or MS result
unconjugatedAntibody?: number; // % (DAR 0 species)
freePayload?: number; // amount per mg of conjugate; unit stated in method
darMethod?: 'hic' | 'rp-lc' | 'lc-ms' | 'uv';
}
// Consistency check a validator could apply
export function darFromDistribution(d: DarSpecies[]): number {
const total = d.reduce((s, x) => s + x.abundance, 0);
return d.reduce((s, x) => s + x.drugLoad * x.abundance, 0) / total;
}
For example, a hypothetical cysteine-linked lot with abundances of 5 % (DAR 0), 25 % (DAR 2), 40 % (DAR 4), 20 % (DAR 6) and 10 % (DAR 8) gives a weighted mean of (0×5 + 2×25 + 4×40 + 6×20 + 8×10)/100 = 4.1. If the lot certificate reported a mean DAR of 3.5 alongside that distribution, a validator should flag the discrepancy rather than accept either number. Under v1.0 no such check is possible: validateDrugCandidate() would accept the product without comment, because nothing in the record tells it that the antibody is conjugated. That silence is the gap.
{
"drugType": "antibody-drug-conjugate",
"target": "EXAMPLE-ANTIGEN",
"conjugate": {
"conjugation": "interchain-cysteine",
"linker": "cleavable-peptide",
"payloadClass": "microtubule-inhibitor",
"meanDar": 4.1,
"darDistribution": [
{ "drugLoad": 0, "abundance": 5 },
{ "drugLoad": 2, "abundance": 25 },
{ "drugLoad": 4, "abundance": 40 },
{ "drugLoad": 6, "abundance": 20 },
{ "drugLoad": 8, "abundance": 10 }
],
"unconjugatedAntibody": 5,
"darMethod": "hic"
}
}All values in this record are illustrative. The target name is a placeholder, and the distribution was chosen to make the arithmetic easy to follow, not to resemble any marketed product.
The manufacturing types of v1.0 describe a batch process as a summary. CellCultureParams holds one productivity figure, one culture duration, one viability and one cell density; PurificationProcess holds a list of steps with a yield and purity each, an overall yield and a total duration. That fits a fed-batch culture followed by a fixed chain of chromatography columns, which Chapter 6 used to compute overall yield as the product of step yields. It fits less well where the industry is heading.
In a perfusion bioreactor, cells are retained while medium flows continuously, and product is harvested over an extended period rather than once at the end. Downstream, periodic counter-current chromatography and other continuous or connected steps process that stream without large hold tanks. ICH Q13 addresses continuous manufacturing of drug substances and drug products, including how a "batch" is defined when material flows continuously — for example by time, quantity or throughput.
For a data standard this changes the shape of the record. A single viability or productivity number is replaced by a time series; a batch is no longer a physical vessel but a defined interval; and traceability requires that a given vial can be traced back to the period of operation in which its material was produced. v1.0 has no time dimension in any manufacturing field, and no field for batch definition. A v2 profile for continuous processing would need both, and it would need them without forcing batch manufacturers to fill them in.
Process analytical technology (PAT) is the practice of measuring critical process parameters and quality attributes during manufacturing, often with in-line or at-line spectroscopic methods, so that the process can be controlled rather than merely inspected afterwards. ICH Q8(R2) describes real-time release testing as the ability to evaluate and ensure product quality on the basis of process data, which can include a combination of measured material attributes and process controls. For biologics, where many release assays are slow biological tests, the full vision is still developing; but partial use of process data is increasingly part of control strategies.
The implication for WIA-BIO-016 is structural. QualityAttributes today is a set of end-product numbers: purity, monomer, aggregates, fragments, charge variants, potency, endotoxin, HCP and residual DNA. A PAT-aware model must also record where a value came from: an off-line release assay, an in-line sensor, or a model prediction calibrated against reference assays. Without a provenance field, a number from a soft sensor and a number from a validated SEC run look identical, and that is exactly the confusion a standard should prevent.
A digital twin of a bioprocess couples a mechanistic or data-driven model of the process to live plant data, and is used to explore operating conditions, predict deviations or support control. The idea is compelling, and it is easy to overstate. From the standard's point of view, a twin is simply another producer of predicted values, and its outputs should be recorded with the model identity, the model version and the input data window. The SDK is a small illustration of the same principle: predictShelfLife() is a model (Arrhenius extrapolation), and Chapter 5 showed how its unit assumptions — the rate constant is treated as per second, days are converted to "months" of 30 days — change the answer. A twin is that problem at a far larger scale.
| Concern | v1.0 representation | What a continuous/PAT profile would need |
|---|---|---|
| Culture performance | Single values in CellCultureParams | Time-stamped series with units; sampling method |
| Batch identity | Implicit (one record = one batch) | Explicit batch definition (time, quantity or throughput) as in ICH Q13 |
| Purification | Ordered steps with yield and purity | Connected/continuous unit operations; residence time; cycle counts |
| Quality values | End-product numbers in QualityAttributes | Provenance per value: off-line assay, in-line sensor, or model prediction |
| Model outputs | Only SDK functions, unversioned per result | Model identity, version, input window, calibration reference |
Machine learning now plays a role at several points of biologics discovery: predicting protein structure, proposing sequence variants, and screening candidates for developability liabilities such as aggregation propensity, high viscosity at formulation concentration, non-specific binding or chemical hot spots (deamidation and oxidation motifs, discussed as PTMs in Chapter 2). Used well, these tools narrow the set of molecules that need to be made and tested. Used carelessly, they generate numbers that look like measurements.
Consider how a prediction would enter v1.0 today. DrugCandidate.targetAffinity is documented as "Kd in M". DrugCandidate.stability is a score between 0 and 1. immunogenicityRisk is low, moderate or high. None of these fields says how the value was obtained. If a team writes a predicted affinity into targetAffinity, validateDrugCandidate() will treat it exactly as it treats an SPR result and produce the same warnings, errors and feasibility rating. The candidate may pass the gate of Chapter 6 on the strength of a model that has never seen that target class.
The same reasoning applies to immunogenicity. Chapter 5 was explicit that the WIA Immunogenicity Risk Score is a triage heuristic without validated calibration; an in-silico T-cell epitope score is likewise a screening signal. Feeding one heuristic into another and storing the result in a field that downstream tools treat as fact compounds uncertainty while hiding it.
A simple remedy is to allow any numeric attribute to be wrapped with its source. The proposal below keeps plain numbers valid (so v1.0 records still parse) and adds an object form for values whose origin matters.
// PROPOSAL for WIA-BIO-016 v1.1 — not part of v1.0
export type ValueSource = 'measured' | 'predicted' | 'literature' | 'assumed';
export interface SourcedValue {
value: number;
unit: string; // e.g. 'M', '%', 'mg/L'
source: ValueSource;
method?: string; // 'spr', 'bli', 'sec', or a model name
methodVersion?: string; // assay SOP or model version
uncertainty?: { low: number; high: number };
recordedAt?: string; // ISO 8601 timestamp
}
// v1.x: accept either form
export type Numeric = number | SourcedValue;
// A gate that refuses to pass a candidate on predictions alone
export function requireMeasured(v: Numeric, name: string): number {
if (typeof v === 'number') return v; // legacy v1.0 value
if (v.source !== 'measured') {
throw new Error(`${name} is ${v.source}; gate requires a measured value`);
}
return v.value;
}With this in place, a discovery tool can store predicted affinities alongside measured ones and a validator can decide, per gate, what it will accept. Early triage might accept predictions; the candidate-selection gate of Chapter 6 should not. The legacy branch that accepts a bare number is a compromise: it keeps old data usable, but a v2 could require the object form for gate-relevant fields.
No prediction replaces the assays described in Chapters 2 to 5. A model can prioritise which variants to express; it cannot supply the intact mass, the glycan profile, the SEC result or the stability data that a quality dossier needs. The standard should make it easy to record predictions and hard to confuse them with evidence. That is a narrower ambition than "AI-driven development", and a more useful one.
Regulation moves more slowly than science, and a data standard should follow it rather than anticipate it. Three directions are relevant to how WIA-BIO-016 may evolve. The summaries below are deliberately general; readers should consult the current texts from the agencies concerned before relying on any of them.
Chapter 6 described the classical biosimilar package: extensive analytical similarity, a comparative PK study with a 90 % confidence interval for the geometric mean ratio within 80–125 %, and often a comparative efficacy study. As analytical methods have become more sensitive, regulators including FDA and EMA have published documents discussing when a comparative efficacy study adds little to a well-characterized product and may be waived or reduced. The direction is to let analytical and PK evidence carry more of the weight.
For WIA-BIO-016 this raises the stakes on the analytical data model rather than lowering them. If the case for similarity rests more heavily on attribute-by-attribute comparison, then the way assessBiosimilarity() scores that comparison matters more. Chapter 6 showed that its per-attribute formula (similarity = 100 − |Δ|/reference × 100), its thresholds and its 50/35/15 tier weights are WIA heuristics and do not reproduce regulatory practice, which relies on approaches such as quality ranges and equivalence testing on multiple lots. A future version should either implement those approaches or label its score even more clearly as an internal screening index.
In the United States, an interchangeable biosimilar may be substituted at the pharmacy without the prescriber's intervention, subject to state law. Historically, switching studies alternating between reference and biosimilar were expected to support that designation; FDA has since issued draft recommendations indicating that such studies may generally not be needed. Other jurisdictions handle substitution through their own mechanisms. The v1.0 BiosimilarAssessment has analyticalSimilarity, pkSimilarity and clinicalSimilarity flags, but no field for interchangeability or for the jurisdiction a conclusion applies to. Since the same analytical package can support different conclusions in different regions, a jurisdiction field is the minimum addition.
ICH Q2(R2) (validation of analytical procedures) and ICH Q14 (analytical procedure development) together treat an analytical method as something that has a lifecycle: it is developed against an intended purpose, validated, monitored and changed under control. USP general chapter <1220> describes the same lifecycle idea; as noted in Chapter 7, the v1.0 reference list mislabels it as a chapter on monoclonal-antibody procedures, and that entry should be corrected.
The data-model consequence is familiar by now: a result is only interpretable if its method is identified and versioned. v1.0 has a method field in BindingAffinity and KineticParameters (SPR, BLI and so on) but none in QualityAttributes, where a purity value could have come from SEC, CE-SDS or a reversed-phase method. The SourcedValue wrapper from 8.4.2, with method and methodVersion, meets this need too; the same mechanism serves both machine-learning provenance and analytical lifecycle management.
The earlier chapters found concrete defects in the specification, the SDK, the CLI and the accompanying documents. None of them is exotic; most are the ordinary consequence of writing formulas, code and prose in parallel without a shared test suite. Collecting them in one place turns a list of complaints into a release plan.
| Where | Defect | Proposed fix | Release |
|---|---|---|---|
calculatePharmacodynamics() | Receptor occupancy computed as C/(EC50 + C), although occupancy is defined by Kd (spec §5.2.2); EC50 and Kd need not coincide | Add optional kd to PDParameters; use it when present, otherwise return the EC50-based value with a warning | v1.1 (minor) |
calculatePharmacodynamics() | therapeuticRange fixed at 0.5–9 × EC50 without basis | Label as heuristic in docs; make the multipliers parameters | v1.1 |
BIOPHARMA_CONSTANTS | GAS_CONSTANT is 1.987 (cal/mol·K) while predictShelfLife() uses 8.314 J/mol·K internally | Publish both with explicit unit names; make the function use the constant | v1.0.x (patch) |
predictShelfLife() | Assumes the rate constant is per second and a month is 30 days, undocumented | Take a unit argument; document the conversion | v1.1 |
convertConcentration() | ConcentrationUnit includes mg/mL and μg/mL, but mass conversions throw BIO007; molecularWeight parameter is unused | Implement molar ↔ mass using molecular weight | v1.1 |
wia-bio-016 CLI | bc cannot parse 1e-9; default arguments and README examples fail with a syntax error | Do arithmetic and comparisons that may see an exponent in awk instead of bc (Chapter 7) | v1.0.x |
| README | Imports a non-existent simulatePharmacokinetics; describes an npm package and repository path that were not verified | Align examples with exported functions; state distribution status plainly | v1.0.x |
| Spec Appendix A.1 | Kd = 1.01 nM interpreted as "high affinity", contradicting §4.1.2 and SDK thresholds | Correct to "moderate" | v1.0.x (editorial) |
| Spec §7.3.1 | "Optimal pH = pI ± 1" points the wrong way | Formulate away from pI (Chapter 5) | v1.0.x (editorial) |
| Spec §10 | USP <1220> mislabelled; §10.2 numbering starts at 2 | Correct title and numbering | v1.0.x (editorial) |
spec/PHASE-1..4 | Carry the ID WIA-BIO-015 and generic template text | Replace with real BIO-016 phase documents | v1.1 |
DrugCandidate.developmentStage | Stops at approved while ClinicalPhase includes phase4 | Reuse ClinicalPhase plus discovery/approved values | v2 (breaking) |
| Characterization types | PTM union lacks deamidation, isomerization, pyroglutamate, C-terminal lysine and glycation; positions carry no chain or numbering scheme; no record for higher-order structure (Tm, CD) (Chapters 1–3) | Widen the union, add optional chain and numbering, add an HOS record (see PTMExt in 3.7.4) | v1.1 |
| Input validation | assessImmunogenicity() accepts a zero or negative tolerance or duration factor; validateDrugCandidate() accepts NaN and never throws; calculateKinetics() hard-codes method and temperature (Chapters 4–6) | Reject invalid inputs with BIO007; let the caller supply assay metadata | v1.1 (behaviour change, noted in release notes) |
| Type model | No ADC, multispecific, nucleic-acid or provenance fields | ConjugateAttributes, BindingArm[], SourcedValue; separate profiles for vector and cell products | v1.x additive, v2 for profiles |
The SDK, the CLI and the specification all declare version 1.0.0. Semantic Versioning (MAJOR.MINOR.PATCH) gives a clear rule for what each fix may do: a PATCH release fixes behaviour without changing the interface, a MINOR release adds capability in a backward-compatible way, and a MAJOR release is required whenever a change breaks existing consumers.
The subtle case is a bug fix that changes a number. Correcting the occupancy formula does not alter any type signature, yet a stored PDResult computed under v1.0 will disagree with one computed after the fix. For a scientific standard, that is not a cosmetic difference. The proposal here is to make the occupancy fix a MINOR release, because it adds a new optional input (kd), and to keep the old behaviour when kd is absent, adding a warning. Records then carry the calculation version, so that a reader can tell which formula produced a stored value:
// PROPOSAL for v1.1: occupancy from Kd when available
export interface PDParameters {
concentration: number; // mg/L in v1.0; molar input recommended when kd is given
emax: number;
ec50: number;
hillCoefficient?: number;
baseline?: number;
kd?: number; // NEW (optional): same unit as concentration
}
export interface PDResult {
/* ...v1.0 fields unchanged... */
occupancyBasis: 'kd' | 'ec50-legacy'; // NEW
calculationVersion: string; // NEW, e.g. '1.1.0'
warnings?: string[]; // NEW
}
const basis = params.kd !== undefined ? params.kd : params.ec50;
const receptorOccupancy = params.concentration / (basis + params.concentration);
const occupancyBasis = params.kd !== undefined ? 'kd' : 'ec50-legacy';
if (occupancyBasis === 'ec50-legacy') {
warnings.push('Occupancy estimated from EC50; supply kd for a binding-based value');
}
As a worked example, take a free concentration equal to 2 nM, an EC50 of 10 nM and a Kd of 0.5 nM (all illustrative). The legacy computation gives 2/(10 + 2) ≈ 0.17; the Kd-based computation gives 2/(0.5 + 2) = 0.80. The two numbers describe different things, and a record that carries occupancyBasis makes that visible instead of letting the lower figure pass as "receptor occupancy".
By contrast, changing developmentStage to reuse ClinicalPhase alters the set of allowed values in a stored field. Some v1.0 records would no longer validate. That belongs in a MAJOR release with a documented migration, and it is a good reason to gather breaking changes together rather than scatter them.
v1.0.x editorial + patch
├─ spec corrections: A.1 interpretation, §7.3.1 pH, §10 references
├─ CLI: awk in place of bc for exponent-bearing values
├─ constants: unit-qualified gas constant
└─ README aligned with actual exports
v1.1 additive, backward compatible
├─ PDParameters.kd + occupancyBasis + calculationVersion
├─ ConjugateAttributes, BindingArm[], NucleicAcidLNPAttributes
├─ SourcedValue (plain numbers still accepted)
├─ PTM union widened, chain-qualified positions, HOS record
├─ BIO007 validation for unchecked inputs
├─ convertConcentration mass <-> molar
└─ real BIO-016 phase documents replace PHASE-1..4 template
v2.0 breaking, with migration guide
├─ product architecture separated from indication
├─ developmentStage aligned with ClinicalPhase
├─ SourcedValue required on gate-relevant fields
└─ separate profiles: vector products, cell products, continuous processingThe ordering is a proposal, and its only firm principle is that each step should be accompanied by the golden test vectors described in Chapter 7. A fix without a test that exercises it is a claim, not a fix.
It helps to see the gaps in historical order. Each generation of biologics added a kind of product that the previous data habits did not describe well; the v1.0 model covers the first three bands in the sketch below reasonably, the fourth partially, and the last hardly at all.
1970s hybridoma technology — monoclonal antibodies become possible
1980s first recombinant protein and first monoclonal antibody therapeutics
1990s- chimeric, humanised, then human antibodies; Fc-fusion proteins
2000s first antibody-drug conjugates; biosimilar pathways established
2010s bispecific formats, single-domain antibodies, CAR-T and AAV products
2020s mRNA-LNP vaccines at scale; site-specific ADCs; continuous processing
coverage in WIA-BIO-016 v1.0:
proteins / mAbs / Fc-fusion ........ modelled
ADCs .............................. labelled only (no DAR / linker / payload)
bispecifics, nanobodies ........... labelled only (one target, one Kd)
mRNA .............................. vaccine type only
cell and gene therapy ............. not modelledThe decade labels are approximate and are there only to order the bands; the point of the diagram is the coverage column, not the chronology.
The specification closes its introduction with 弘益人間, "benefit all humanity", and states an aim of accelerating safe, effective and accessible biopharmaceuticals. A data standard can contribute to that aim in a modest and real way. Biosimilars, for instance, depend on analytical comparison; a well-defined, openly available model for recording and comparing quality attributes lowers the cost of doing that comparison carefully. Open reference code lets small laboratories and academic groups use the same calculations as larger organisations, and makes errors visible, as the defects catalogued in this book show.
What a data standard cannot do is make a product safe, effective or approved. A WIA conformance claim, as Chapter 7 stressed, is a statement about an implementation's behaviour against defined test vectors. It is not a regulatory decision, not a GMP certificate and not clinical validation. Holding that line is itself part of the purpose: the fastest way to lose the trust that makes a standard useful is to let it be read as more than it is.
Chapter summary
target and targetAffinity in DrugCandidate fail to represent a bispecific T-cell engager? What fields would you add?SourcedValue keeps them apart.